Self-RAG과 Corrective RAG — Agent가 자기 검색을 평가하는 법

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의 핵심 아이디어입니다.