RAG 완전 정복: 개념부터 프로덕션 배포까지 (2025)

RAG란 무엇인가?

RAG(Retrieval-Augmented Generation)는 LLM의 가장 큰 약점인 지식 한계를 해결하는 핵심 기법입니다. LLM은 학습 데이터 이후의 정보를 모르고, 사내 문서나 개인 데이터를 알 수 없습니다. RAG는 이 문제를 "먼저 관련 문서를 검색한 뒤, 그 내용을 컨텍스트로 제공"하는 방식으로 해결합니다.

기본 흐름:

1. 문서를 청크(chunk)로 나눠 임베딩 벡터로 변환
2. 벡터 DB에 저장
3. 사용자 질문이 들어오면 → 질문도 임베딩 변환
4. 유사도 검색으로 관련 청크 추출
5. LLM에게 "이 문서를 참고해서 답해줘"와 함께 전달

임베딩 모델 선택

한국어 문서를 다룬다면 BGE-M3를 강력히 추천합니다. 로컬에서 무료로 실행 가능하고 한국어 성능이 OpenAI 대비 확연히 좋습니다.

벡터 DB 선택

PostgreSQL을 이미 쓰고 있다면 pgvector가 인프라 추가 없이 시작할 수 있어 가장 현실적입니다.

청크 전략 — 가장 많이 틀리는 부분

청크 크기는 RAG 성능에 직결됩니다.

청크 크기별 특성:

• 너무 작음(100토큰 이하): 컨텍스트 부족, 답변 불완전
• 최적(256~512토큰): 대부분 태스크에서 균형점
• 너무 큼(1024토큰 이상): 관련없는 내용 포함, 비용 증가

실전 팁:

# 문단 기반 분할 (단순 고정 크기보다 훨씬 효과적)
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,  # 문맥 유지를 위한 오버랩
    separators=["

", "
", "。", ".", " "]
)

청크 간 overlap을 50~100토큰 두면 문맥이 잘리는 문제를 줄일 수 있습니다.

Hybrid Search — 정확도를 높이는 핵심

순수 벡터 검색만으로는 키워드가 정확히 일치해야 하는 케이스(모델명, 버전, 고유명사)를 놓칩니다. Hybrid Search는 벡터 유사도 + BM25 키워드 검색을 결합합니다.

# 벡터 검색 결과와 BM25 결과를 RRF(Reciprocal Rank Fusion)로 결합
def hybrid_search(query, vector_results, bm25_results, alpha=0.5):
    # alpha: 벡터 검색 비중 (0.5 = 50:50)
    combined = rrf_merge(vector_results, bm25_results)
    return combined[:top_k]

pgvector + PostgreSQL의 전문검색(tsvector)을 함께 쓰면 별도 인프라 없이 hybrid search 구현이 가능합니다.

프로덕션 체크리스트RAG를 실제 서비스에 배포하기 전 확인사항:

• 재랭킹(Reranking): Cross-encoder 모델로 검색 결과를 한 번 더 정렬 (Cohere Rerank, bge-reranker 등)
• 쿼리 확장: 사용자 질문을 LLM으로 변환해서 검색 품질 향상
• 메타데이터 필터링: 날짜, 카테고리 등으로 검색 범위 제한
• 할루시네이션 방지: "문서에 없는 내용은 답하지 마세요" 프롬프트 추가
• 평가 파이프라인: RAGAS, TruLens 등으로 답변 품질 정량 측정

결론

RAG는 LLM을 실무에 도입할 때 가장 많이 쓰이는 패턴입니다. 핵심을 정리하면:

1. 한국어라면 임베딩은 BGE-M3
2. PostgreSQL 이미 있으면 pgvector부터 시작
3. 청크 크기 512토큰, overlap 50토큰이 무난한 시작점
4. Hybrid Search로 키워드 검색과 결합
5. 프로덕션 전 반드시 평가 파이프라인 구축

ai.zip 리더보드에서 실제 LLM 성능을 비교하면서 RAG에 맞는 모델을 선택하세요.