Workflow와 평가 전략
* 지난 글
: LLM System Design: 엔터프라이즈 규모에서 고려해야 할 핵심 요소들
https://brunch.co.kr/@dr-jenna/12
대규모 언어 모델(LLM)을 활용한 챗봇과 어시스턴트는 엔터프라이즈 환경에서 빠르게 확산되고 있다. 그러나 단순히 LLM 하나만 배포하는 것으로는 정확도, 확장성, 응답 지연(latency) 같은 요구사항을 만족시키기 어렵다. 특히 RAG(Retrieval-Augmented Generation) 기반 챗봇을 설계할 때는 검색 인프라와 모델 추론이 긴밀히 결합되어야 한다. 이번 글에서는 RAG 기반 챗봇 시스템의 전체 워크플로우와 고려해야 할 핵심 요소들을 정리해본다.
RAG 기반 챗봇에서 가장 중요한 비기능 요구사항은 다음과 같다.
지연 시간(latency): 실시간 대화 응답은 1~2초 이내여야 한다.
처리량(throughput): 수천 명의 동시 사용자를 지원할 수 있어야 한다.
정확도(accuracy): 검색된 문서와 최종 답변의 일관성과 신뢰성이 높아야 한다.
확장성(scalability): 수십만~수백만 건의 문서를 안정적으로 검색할 수 있는 인프라가 필요하다.
사용자 쿼리 입력
쿼리 리라이트 및 키워드 분석(Query rewrite & keyword analysis)
의도 분석(Intention analysis): chit-chat, 일반 질의, 도메인 특화 RAG 중 라우팅
임베딩(Embedding): bi-encoder로 rewritten query 임베딩
하이브리드 검색(Hybrid search): BM25 + kNN(Euclidean distance) 기반 Elasticsearch 벡터 검색
리랭킹(Reranker): cross-encoder로 후보 문서 재정렬 → precision 향상
필터링(LLM filtering): 불필요하거나 무관한 문서 제거
검증(LLM verification): 검색 문서와 쿼리 일관성 확인
생성(LLM generation): LLM을 통한 최종 응답 생성
반영(LLM reflection): self-check를 통해 품질 보정
폴백(Fallback): 실패 시 rewritten query로 재시도 (최대 N회)
모델: vLLM 기반 LLM, OpenAI-compatible API 지원
서비스: FastAPI App Server
데이터 파이프라인: Datalake/S3 → Airflow → 전처리/Chunking → Elasticsearch 인덱싱
모니터링: MLflow로 retrieval 성능과 generation 성능을 추적
Retrieval 성능: Recall, MRR, Hit@K (ground truth 기반)
Generation 성능: LLM-as-a-judge (groundedness, relevance, correctness, coverage) + Human benchmark
임베딩(bi-encoder): O(d·L)
kNN 검색(Euclidean distance, 근사탐색): O(log N)
리랭킹(cross-encoder): O(K·(Lq+Lp))
검색 단계 최적화: HNSW 파라미터 튜닝(ef_search), 상위 후보 축소 후 리랭킹, 자주 쓰는 인덱스 메모리 티어링.
배치 처리: vLLM의 연속 배칭(in-flight batching), 동적 배칭(dynamic batching)으로 GPU 활용 극대화.
캐시 전략: 세맨틱 캐시(유사 쿼리 재사용), retrieval 결과 캐시, KV 캐시 공유.
모델 최적화: FlashAttention, speculative decoding, 양자화(INT8/4).
운영 측면: Kubernetes HPA 기반 GPU 오토스케일링, 멀티 리전 배포로 전 세계 사용자 대응.