[V2] 챗봇 2차 설계 - 100-hours-a-week/6-nemo-ai GitHub Wiki
RAG 기반 챗봇 설계 문서
🎯 문서 목적
이 문서는 사용자의 자유 입력 텍스트 또는 선택형 질문 응답을 바탕으로 모임을 추천하는 RAG 기반 챗봇 시스템의 구조, 흐름, API 역할, 기술 분담 및 요구 스택을 정리한 문서입니다.
모든 AI 처리 (LLM 추론, 세션 관리, 벡터 검색)는 AI 서버 내부에서 수행되며, 백엔드는 요청 프록시 역할만 합니다.
🧠 시스템 요약
| 항목 |
설명 |
| 모델 |
Gemma 3B or 4B (4bit, GPU L4 기반) |
| 벡터 검색 |
ChromaDB (로컬 persist 구조) |
| 프론트 ↔ AI 연결 |
SSE 기반 (서버-전송 이벤트) |
| 흐름 제어 |
Lite Autogen 스타일 |
🧩 추천 방식 정리
| 방식 |
설명 |
엔드포인트 |
| MCQ (선택지 기반) |
유저가 선택한 응답을 Redis에 저장해 다음 질문 생성 → 마지막 질문 이후 RAG 추천 |
/ai/v2/chatbot/questions, /answers |
| Freeform (자유입력) |
사용자의 설명을 임베딩해 유사 모임 벡터 검색 후 context + 추천 생성 |
/ai/v2/chatbot/freeform |
🔁 챗봇 처리 흐름
선택지 기반 (Lite Autogen)
/questions 호출 → 첫 질문 생성/answers 호출 → Redis에 누적- 마지막 질문 응답 → context + 모임 추천 + Redis 세션 삭제
자유입력 기반
/freeform 호출 → 임베딩 + Chroma 검색- context + 추천 문장 생성
🧠 AI 서버 내부 처리 (책임 범위)
- FastAPI 라우터 구성
- 질문 흐름 유지 (Redis 세션 키 관리)
- ChromaDB 벡터 검색
- Gemma 3 4B 모델 추론
- context 및 추천 결과 생성
- SSE로 실시간 응답 전달
📁 딕셔너리 히스토리 구조
- Key:
user:{uuid}:mcq_history
- Value 예시:
[
{ "question": "모임에서 더 중요한 건?", "selected_option": "사람" },
{ "question": "처음 보는 사람 앞에서는?", "selected_option": "조용해지는 편" }
]
- TTL: 600초 (10분)
- 추천 이후:
redis.delete(key)
📌 예시 흐름
/questions 호출 시:
{
"question": "모임에서 더 중요한 건?",
"options": ["사람", "주제", "장소"]
}
/answers 호출 시:
{
"question": "모임에서 더 중요한 건?",
"selected_option": "사람"
}
→ Redis에 히스토리 누적 후 다음 질문 생성
- 마지막 질문 후:
{
"context": "사람 중심의 네트워킹 모임을 선호하시는 것 같아요.",
"results": [
{ "group_id": "abc123", "name": "성장형 네트워킹 소모임" },
{ "group_id": "def456", "name": "스터디&대화 중심 개발 모임" }
]
}
📦 기술 스택별 요구 사항
✅ AI 서버
| 항목 |
기술 |
설명 |
| API 서버 |
FastAPI |
/questions, /answers, /freeform 및 SSE 응답 처리 |
| LLM 추론 |
transformers |
GPU 기반 추론, 4bit 모델 |
| 벡터 검색 |
ChromaDB |
persist 디렉토리로 구성 |
| SSE |
FastAPI StreamingResponse |
LLM 생성 결과 스트리밍 전송 |
| 시스템 |
Python 3.13.3 |
단일 GCP VM에서 실행 |
⚙️ 백엔드 (다른 팀원)
| 항목 |
기술 |
설명 |
| API 중계 |
FastAPI |
프론트에서 AI 서버로 요청 전달 (proxy) |
| 인증 처리 |
JWT, OAuth 등 |
유저 인증 (AI 서버는 사용자 ID만 받음) |
| DB 관리 |
MySQL, etc. |
유저 정보 및 모임 DB 관리 |
| 장애 처리 |
Retry, Timeout 처리 |
AI 서버가 느릴 경우 대비 |
💻 프론트엔드
| 항목 |
기술 |
설명 |
| 프레임워크 |
Next.js |
사용자 인터페이스 구현 |
| 질문 흐름 |
local state or Context |
MCQ 상태 저장, 선택 추적 |
| SSE 수신 |
EventSource API |
실시간 context / 추천 결과 표시 |
| 에러 처리 |
Timeout, 연결 오류 fallback |
AI 서버 SSE 오류 대비 |
☁️ DevOps (GCP 인프라 기준)
| 항목 |
내용 |
| 플랫폼 |
GCP Compute Engine |
| GPU |
L4 (24GB VRAM) |
| CPU |
8 vCPU 이상 |
| 메모리 |
32GB 이상 |
| Chroma |
로컬 persist 디렉토리 (/app/chroma/) (이미 코드상 설정 완료) |
| 모델 디렉토리 |
HuggingFace 모델 로컬 경로 |
| 배포 |
systemd |
| 모니터링 |
SigNoz / Sentry |
🔐 기술 분담표
| 파트 |
구현 책임 |
주요 내용 |
| 프론트엔드 |
(Next 등) |
UI/UX, SSE 수신, 질문/선택 인터페이스 |
| 백엔드 |
(FastAPI 등) |
유저 인증, 챗봇 API 게이트웨이, 요청 프록시 |
| AI 서버 |
FastAPI |
|
| Chroma 검색 |
|
|
| 추론 생성 |
모든 RAG 처리, 질문 흐름, context 생성, SSE 전송 |
|
🧠 히스토리 기반 질문 제어 (Lite Autogen 스타일)
- Redis에 질문 흐름 저장
- 다음 질문은 이전 응답 기반으로 동적으로 결정
- 최종 상태 도달 시 context 생성 + 벡터 검색 + 추천 응답
💡 Freeform 처리
- Stateless 구조
- Redis 사용하지 않음
/freeform 입력 → 임베딩 → Chroma 검색 → LLM 문장 생성
🔚 정리 요약
- 모든 세션 흐름, 벡터 검색, 모델 추론은 AI 서버 내부에서 단독 처리
- 백엔드는 AI 서버와의 연결만 관리하며 로직에 관여하지 않음
- 프론트는 SSE 기반 실시간 응답 수신 및 질문 UI 상태를 담당
- Redis는 AI 서버 내장으로 사용되며, 별도 인스턴스로 분리할 필요 없음 (단일 서버 기준)