RAG가 등장한 이유
LLM은 학습 시점 이후의 정보나, 학습 데이터에 없던 사내 문서를 알지 못합니다. 매번 모델을 재학습(fine-tuning)하는 대신, 필요한 정보를 실시간으로 "검색"해서 프롬프트에 함께 넣어주는 방식이 RAG(Retrieval-Augmented Generation)입니다.
기본 파이프라인 3단계
RAG는 크게 추출(Extraction) → 검색(Retrieval) → 생성(Generation) 3단계로 동작합니다.
- 추출/색인: 문서를 잘게 나눈(chunking) 뒤 임베딩 모델로 벡터화해 벡터DB에 저장
- 검색: 사용자 질문도 같은 방식으로 벡터화해, 벡터DB에서 의미적으로 가장 유사한 문서 조각을 찾음
- 생성: 검색된 문서 조각을 프롬프트에 함께 넣어 LLM이 그 내용을 근거로 답변 생성
왜 파인튜닝보다 RAG를 먼저 고려하나
파인튜닝은 비용과 시간이 많이 들고, 문서가 바뀔 때마다 재학습이 필요합니다. RAG는 벡터DB의 문서만 갱신하면 되므로 최신 정보 반영이 훨씬 빠르고 저렴합니다.
핵심 구성 요소
- 임베딩 모델: 텍스트를 벡터로 변환
- 벡터 데이터베이스: 임베딩을 저장하고 유사도 검색 수행 (예: Milvus, pgvector, Weaviate)
- 리트리버(Retriever): 질문에 맞는 문서 조각을 찾아내는 검색 로직
- LLM: 검색된 문맥을 바탕으로 최종 답변 생성
한계
검색이 부정확하면(엉뚱한 문서를 가져오면) LLM도 잘못된 근거로 답변하게 됩니다. 청킹 전략과 임베딩 품질이 RAG 전체 정확도를 좌우합니다.