프로덕션 RAG 시스템의 전체 아키텍처와 핵심 설계 결정 포인트.
청킹은 RAG 품질의 기초. 전략에 따라 검색 정확도가 20~40% 달라집니다.
| 전략 | 작동 방식 | 최적 크기 | 정밀도 | 재현율 | 구현 복잡도 | 추천 용도 |
|---|---|---|---|---|---|---|
Fixed-size |
고정 토큰 수 + overlap | 256~512 tok | ●●●○ | ●●●○ | 낮음 | MVP, 빠른 프로토타입 |
Recursive |
구분자 계층으로 재귀 분할 | 512 tok | ●●●● | ●●●● | 낮음 | 범용 추천 (기본값) |
Semantic |
임베딩 유사도 변화점에서 분할 | 가변 | ●●●○ | ●●●● | 중간 | 다주제 문서, 대화록 |
Parent-Child |
작은 청크 검색 → 큰 청크 반환 | 128 / 512 | ●●●● | ●●●● | 높음 | 긴 보고서, 기술 문서 |
Document Summary |
문서 요약으로 검색 → 원문 반환 | 요약 200 tok | ●●●● | ●●●○ | 높음 | 글로벌 질문, 요약형 답변 |
각 청크에 문서 수준 맥락을 접두사로 추가한 뒤 임베딩합니다. LLM이 자동으로 맥락 문장을 생성합니다.
"매출은 전년 대비 15% 증가했다."
"[2024년 3분기 실적보고서, 영업이익 섹션] 매출은 전년 대비 15% 증가했다."
기존: 먼저 자르고 → 각각 임베딩 (문맥 손실). Late Chunking: 전체 문서를 먼저 임베딩 → 토큰 벡터에서 청크 추출. 긴 컨텍스트 모델(8K+ tokens)의 어텐션이 문서 전체를 보기 때문에, 각 청크가 주변 맥락을 자연스럽게 반영합니다.
문서 → [청크1, 청크2, 청크3] → [embed(청크1), embed(청크2), embed(청크3)]
문서 → embed(전체 문서) → 토큰 벡터 → [pool(토큰1~50), pool(토큰51~100), ...]
LLM Agent가 문서 특성을 분석해서 청킹 전략 자체를 동적으로 결정합니다. 연구 논문 → Semantic Chunking, 재무 보고서 → 페이지 단위, 코드 파일 → 함수 단위. 고정 전략의 한계를 근본적으로 해결하지만 인제스팅 비용이 증가합니다.
청크 간 10~20% overlap 권장. 문맥 단절을 방지. 50% 이상은 중복 노이즈 발생.
AST 기반 분할이 가장 효과적. 함수/클래스 단위로 자른 뒤 시그니처를 접두사로 추가.
표는 Markdown/HTML로 변환 후 통째로 하나의 청크로. 행 단위 분할은 의미 파괴.
Contextual Retrieval은 LLM 비용 발생하지만 모든 임베딩 모델에 적용 가능. Late Chunking은 무비용이지만 호환 모델 필요. 둘 다 적용 가능하면 결합이 최선.
임베딩 모델 선택이 검색 품질의 50% 이상을 결정합니다. 도메인 벤치마크가 핵심.
| Model | Dim | Max Tokens | MTEB Avg | 다국어 | 특징 |
|---|---|---|---|---|---|
Cohere embed-v4 |
1024 | 128K | 65.2 | 100+언어 | MTEB 1위, 멀티모달, 압축 지원 |
OpenAI text-embedding-3-large |
3072 | 8191 | 64.6 | 다국어 | Matryoshka (차원 축소 가능) |
Voyage-3-large |
1024 | 32K | 64.8 | 다국어 | 코드 특화 모델 별도 제공 |
BGE-M3 |
1024 | 8192 | 62.1 | 100+언어 | Dense+Sparse+ColBERT 동시 출력 |
Jina-embeddings-v3 |
1024 | 8192 | 61.5 | 89언어 | Task-specific LoRA, 오픈소스 |
E5-Mistral-7B |
4096 | 32K | 61.8 | 영어 중심 | LLM 기반, 지시문 지원 |
한국어 성능이 중요. BGE-M3는 오픈소스로 self-host 가능. Cohere는 API 품질 최고.
코드 특화 모델 필수. 일반 임베딩 모델은 코드 의미 이해에 취약.
PDF 스캔, 차트, 다이어그램 포함 문서. 텍스트 추출 없이 직접 임베딩.
차원을 3072 → 256으로 축소해도 성능 5%만 감소. 스토리지 12x 절약.
검색 품질이 전체 RAG 성능의 상한선을 결정합니다. 같은 LLM에서 검색만 개선해도 50%+ 향상.
원본 질문을 3~5개 관점에서 재작성 후 각각 검색. 결과를 RRF로 결합.
LLM이 가상 답변을 생성 → 답변의 임베딩으로 검색. 질문보다 답변이 문서와 더 유사하다는 통찰.
구체적 질문에서 한 단계 추상화된 질문을 생성해서 더 넓은 범위로 검색.
복합 질문을 하위 질문으로 분해. 각각 독립적으로 검색 후 종합.
Multi-Query + Reciprocal Rank Fusion. 다중 쿼리 결과를 순위 기반으로 결합.
score(d) = Σ 1 / (k + rank_i(d)) // k = 60 (일반적)
score(d) = α · dense_score(d) + (1-α) · sparse_score(d) // α ∈ [0, 1]
토큰별 임베딩을 저장하고, MaxSim(Maximum Similarity) 연산으로 유사도를 계산합니다. 각 쿼리 토큰과 가장 유사한 문서 토큰의 점수를 합산.
검색 후 재순위화. 가장 적은 노력으로 가장 큰 품질 향상을 주는 단계.
| Model | 방식 | 레이턴시 | NDCG@10 | 비용 | 특징 |
|---|---|---|---|---|---|
Cohere Rerank 3.5 |
Cross-Encoder | ~80ms | ●●●● | $2/1K req | API, 다국어, 프로덕션 검증 |
bge-reranker-v2-m3 |
Cross-Encoder | ~60ms | ●●●● | Self-host | 오픈소스, 다국어, GPU 필요 |
Jina-reranker-v2 |
Cross-Encoder | ~50ms | ●●●○ | API/$0.02 | 경량, 다국어 |
FlashRank |
Cross-Encoder | ~15ms | ●●●○ | Free/Self | 초경량, CPU 구동, 빠른 추론 |
RankGPT / LLM Reranker |
LLM Listwise | ~500ms+ | ●●●● | LLM API 비용 | 최고 정확도, 높은 비용/레이턴시 |
Top-100 (벡터검색) → Top-20 (BM25 필터) → Top-5 (Reranker). 넓게 검색하고 점점 좁히기.
FlashRank로 Top-100→Top-20, Cohere로 Top-20→Top-5. 2단계 리랭킹으로 비용/정확도 최적화.
검색된 컨텍스트를 LLM에 효과적으로 전달하고, 충실한 응답을 생성하는 전략.
응답의 각 주장에 [1], [2] 형식 출처 표기를 강제. 할루시네이션 감소 + 검증 가능성 확보.
LLM은 컨텍스트 처음과 끝을 잘 기억하고 중간은 잘 못 봄. 가장 관련 높은 문서를 맨 앞에 배치.
검색된 문서를 그대로 넣지 말고 관련 문장만 추출. 토큰 절약 + 노이즈 감소.
검색된 각 문서에 대해 "이 문서가 질문에 관련 있는가?"를 메모한 뒤 종합. 노이즈 문서 필터링.
단순 파이프라인을 넘어 자율적으로 검색-판단-반복하는 에이전트 패턴.
4가지 Reflection Token으로 자기 판단:
[Retrieve]
검색이 필요한가? Yes/No/Continue
[IsRel]
검색된 문서가 관련 있는가? Relevant/Irrelevant
[IsSup]
응답이 문서에 근거하는가? Fully/Partially/No
[IsUse]
최종 응답이 유용한가? 1~5 등급
검색 결과를 경량 평가기로 Correct / Incorrect / Ambiguous 분류 후 보정 경로 선택:
경량 분류기가 질문 복잡도를 판단해서 최적 전략을 선택합니다:
RAG와 파인튜닝을 결합하는 학습 레시피. 훈련 시 관련 문서 + 방해 문서(Distractor)를 함께 주고, 모델이 방해 문서를 무시하도록 학습합니다. 의료·법률 등 전문 도메인에서 단순 RAG보다 높은 정확도. 도메인 데이터가 충분할 때 고려.
비라벨 코퍼스에서 LLM이 자체적으로 QA 쌍을 생성하고, 품질 필터링 후 self-training. 라벨링 비용 없이 도메인 특화 RAG 성능을 올리는 방법. 11개 데이터셋, 3개 도메인에서 검증.
"RAG"라는 좁은 패턴을 넘어, LLM에 전달하는 전체 컨텍스트를 체계적으로 설계하는 엔지니어링 분야. RAG(정적 지식 검색) + Memory(동적 대화 이력) + MCP(도구/서비스 연결)를 통합하는 "Knowledge Runtime" 개념으로 확장.
Model Context Protocol (MCP)은 AI 모델과 외부 데이터/도구를 연결하는 오픈 표준. 기존에는 도구마다 커스텀 코드가 필요했지만, MCP로 벡터 DB · SQL DB · 웹 검색 · API를 통합 인터페이스로 연결합니다. Agentic RAG의 도구 선택이 동적이고 확장 가능해집니다.
측정 없이 개선 없음. 검색과 생성을 분리 평가하고, 프로덕션에서 지속 모니터링.
검색된 문서 중 관련 있는 비율. 관련 문서 / 전체 검색 문서
필요한 정보가 검색에 포함된 비율. 검색된 관련 문서 / 전체 관련 문서
첫 번째 관련 문서의 평균 순위. 검색 순서 품질 측정.
응답이 검색 문서에 충실한가. 지어낸 내용 비율 측정. 가장 중요한 메트릭.
응답이 질문에 적절한가. 관련 없는 내용이 포함되지 않았는지.
정답과 비교한 사실적 정확도. Ground truth 필요.
오픈소스 자동 평가. 별도 ground truth 없이 LLM 기반 평가 가능. CI/CD 통합 가능.
pytest 스타일 RAG 유닛 테스트. assert_test로 회귀 방지. 빌드 파이프라인 통합.
강력한 LLM으로 약한 LLM의 출력을 평가. Pairwise 비교, Pointwise 채점, Reference-based.
실시간 트레이싱, 피드백 함수 기반 품질 추적. 사용자 피드백 루프 구축.
RAG를 프로덕션에서 안정적으로 운영하기 위한 실전 체크리스트.
유사 질문 임베딩 비교 → 캐시 히트 시 검색/LLM 스킵. 20~40% 비용 절감. Redis + 코사인 유사도 > 0.95.
3072d → 256d로 차원 축소. 스토리지 12x 절약, 검색 속도 3x 향상. 정확도 5%만 감소.
단순 질문은 검색 없이 LLM 직접 답변. 30~50% 검색 비용 절감. 경량 분류기로 구현.
컨텍스트를 LLMLingua로 압축. 토큰 50~70% 절약. LLM API 비용 직접 절감.