Self-RAG과 Corrective RAG — Agent가 자기 검색을 평가하는 법
Self-RAG의 reflection token 메커니즘과 CRAG의 품질 기반 폴백 전략을 구현합니다. LangGraph conditional edge로 retry/fallback 로직 구성.
Self-RAG과 Corrective RAG — Agent가 자기 검색을 평가하는 법
Part 1에서 Query Routing으로 "어디서 검색할지"를 해결했습니다. 하지만 가져온 문서가 쓸모없으면요? Naive RAG의 가장 큰 문제는 검색 품질을 평가하지 않는다는 겁니다. 검색 결과를 그대로 LLM에 던지고, LLM이 알아서 잘 답하길 기도하는 구조입니다. 이번 글에서는 Agent가 스스로 검색 결과를 평가하고, 품질이 낮으면 다른 전략으로 전환하는 두 가지 핵심 패턴을 다룹니다.
시리즈: Part 1: Query Routing | Part 2 (이 글) | Part 3: 프로덕션 파이프라인
라우팅 이후의 문제
Query Routing이 완벽하게 작동해서 올바른 데이터소스를 선택했다고 합시다. 그래도 다음 세 가지 실패 모드가 남아 있습니다.
1. 문서가 아예 관련 없음 (Irrelevant) — "LangGraph의 conditional edge 사용법"을 질문했는데, 검색된 문서가 "LangChain의 LCEL 체이닝"에 관한 내용인 경우입니다. 키워드가 비슷해서 벡터 유사도는 높지만, 실질적으로 답을 만들 수 없는 문서가 반환됩니다. LLM은 이런 문서를 조합해 그럴듯한 환각을 생성합니다.
2. 부분적으로만 관련 (Partially Relevant) — 문서 10개 중 3개만 관련 있고 나머지 7개는 노이즈인 경우입니다. 관련 정보가 노이즈 속에 묻히면 LLM이 초점 흐려진 답변을 생성합니다.
3. 문서끼리 상충 (Conflicting Sources) — "Python 3.12의 GIL 변경 사항"에 대해 하나는 "GIL이 제거되었다", 다른 하나는 "선택적 비활성화가 가능해졌다"라고 주장하는 경우입니다. 판단 없이 둘 다 컨텍스트에 넣으면 모순된 답변이 나옵니다.
RAG Evaluation에서 측정한 Faithfulness 점수가 낮은 원인이 바로 이것입니다. 검색 품질을 통제하지 않으면, 아무리 좋은 LLM을 써도 답변 품질이 들쭉날쭉합니다.
이 문제들을 해결하려면 검색과 생성 사이에 평가 단계를 끼워 넣어야 합니다. 이것이 바로 Self-RAG과 CRAG의 핵심 아이디어입니다.
관련 포스트
TurboQuant vLLM, A100 한 장에서 실측 — 8B 모델에서 프리셋 4개의 용량·속도·정확도
vLLM 0.28, Qwen3-8B bf16, A100 80GB: bf16·fp8·TurboQuant 프리셋 4개의 KV 용량, 배치 처리량, 32K 디코드, needle-in-haystack, GSM8K를 직접 쟀습니다. vLLM 연구가 다루지 않은 8B 크기입니다.
TurboQuant를 실제 KV 텐서 위에서 밑바닥부터 — 3비트의 진짜 비용, 그리고 포크가 논문 레이아웃을 이기는 이유
PolarQuant를 PyTorch 60줄로 구현해 Llama-3.2-1B·Qwen3-8B의 실제 KV에 적용. 3비트는 +10%, k8v4는 +0.2%, QJL은 저비트에서만 유효, 블록-32 레이아웃이 포크 우위의 절반을 설명합니다.
TurboQuant llama.cpp CUDA 포크, A100에서 실측 — turbo4는 q4_0급, turbo3는 긴 컨텍스트에서 무너진다
Qwen3-8B Q4_K_M, A100 한 장, KV 타입 6종: perplexity·프리필·깊이별 디코드·VRAM 실측. turbo4는 q4_0과 품질 동급에 깊은 컨텍스트에선 q8_0보다 2.5배 빠르고, turbo3는 32K에서 PPL이 세 배로 뜁니다.