RAG 평가와 고급 패턴: 검색 지표 · 충실도 · GraphRAG · 에이전틱 RAG

RAG 평가와 고급 패턴: 검색 지표 · 충실도 · GraphRAG · 에이전틱 RAG

RAG를 만들었다면 다음 질문은 "얼마나 잘 되나, 어디서 틀리나"입니다. RAG는 검색기와 생성기 두 부품 이 이어진 시스템이라, 답이 틀렸을 때 어느 쪽 탓인지 따로 재야 고칠 수 있습니다. 이 수업은 검색 지표(recall@k · MRR · nDCG), 생성 지표(충실도 · 답변 관련성 · 문맥 관련성), 실제 RAG에서 자주 보고되는 실패 유형을 정리한 뒤, 기본 RAG의 한계를 넘으려는 고급 패턴 — 스스로 검색을 판단하는 RAG, 교정 RAG, 트리 · 그래프 RAG, 에이전틱 RAG, 긴 문맥과의 비교 — 를 한 장의 지도로 묶습니다.

들어가기 전에

• 검색의 기초: TF-IDF · BM25 · 벡터 검색 · 검색 평가 지표 — recall@k · MRR · nDCG의 정의.
• RAG 파이프라인 설계 — 평가할 대상(청킹 · 하이브리드 · 리랭킹).
• 직접 해 보기: 작은 RAG 만들기 — 검색 지표를 코드로 재 본 실습.

한눈에 보기

• RAG 평가를 "검색 품질"과 "생성 품질" 두 층으로 나눠 설계할 수 있습니다.
• 충실도 · 답변 관련성 · 문맥 관련성을 Ragas 방식대로 손으로 계산해 봅니다.
• 실제 RAG 시스템 사례에서 보고된 7가지 실패 지점을 증상으로 구분합니다.
• Self-RAG · CRAG · RAPTOR · GraphRAG · 에이전틱 RAG가 각각 기본 RAG의 어떤 약점을 겨냥하는지 압니다.
• "긴 문맥에 다 넣기"와 RAG 사이의 선택 기준을 압니다.

1. 두 층으로 평가하기

12345678flowchart LR
  Q[평가 질문] --> R[검색기]
  R --> C[검색된 문맥]
  C --> G[생성기 LLM]
  G --> A[답변]
  C -.->|검색 지표<br/>recall@k · MRR · nDCG<br/>문맥 관련성| E1[검색 평가]
  A -.->|충실도: 답이 문맥에 근거했나| E2[생성 평가]
  Q -.->|답변 관련성: 질문에 맞는 답인가| E2

왜 나눠 재나. 최종 답만 보면 "틀렸다"는 것만 알 수 있습니다. 정답 문서가 애초에 검색되지 않았다면 프롬프트를 아무리 고쳐도 소용없고, 정답 문서가 들어갔는데 틀렸다면 검색을 고쳐도 소용없습니다. 두 층을 따로 재야 고칠 곳 이 보입니다.

2. 검색 지표 복습

검색 기초 에서 정의한 지표를 RAG 관점에서 다시 봅니다.

숫자로 해 보기(해설용). 상위 3개의 관련 여부가 (아님, 관련, 관련)이고 관련 문서가 전부 2개라면

• $\mathrm{DCG@3}=\frac{0}{\log_2 2}+\frac{1}{\log_2 3}+\frac{1}{\log_2 4}=0+0.631+0.5=1.131$
• 이상적 순서 (관련, 관련, 아님)의 $\mathrm{IDCG@3}=1+0.631=1.631$
• $\mathrm{nDCG@3}=1.131/1.631\approx0.693$

recall@3은 1.0(둘 다 들어옴)이지만 nDCG는 0.693입니다. "다 찾았지만 맨 위가 틀렸다"는 차이를 nDCG가 잡아냅니다.

정답 근거 표시가 없으면? 평가 세트를 만들 때 질문마다 정답 청크를 사람이 표시하는 것이 가장 정확합니다. 여의치 않으면 아래 Ragas처럼 LLM으로 근사하는 방법을 씁니다.

3. 생성 지표: Ragas의 세 가지

Ragas(Es 외 2023)는 사람이 쓴 정답 없이(reference-free) RAG를 평가하는 틀입니다. 세 가지 품질 측면을 정의하고, 각각을 LLM 프롬프트로 계산합니다.

① 충실도(faithfulness). 답의 주장들이 주어진 문맥으로 뒷받침되는가.

1. LLM이 답을 짧은 진술 여러 개로 나눕니다.
2. 진술마다 "문맥에서 추론할 수 있는가"를 LLM이 판정합니다.
3. 점수 $F = |V|/|S|$ — 지지된 진술 수 ÷ 전체 진술 수.

② 답변 관련성(answer relevance). 답이 질문에 직접, 적절하게 답하는가(사실 여부는 따지지 않고, 불완전하거나 군더더기가 많으면 감점).

1. LLM이 답만 보고 "이 답을 낳았을 질문" $n$ 개를 만듭니다.
2. 원래 질문 $q$ 와 각 생성 질문 $q_i$ 의 임베딩 코사인 유사도를 잽니다(논문은 OpenAI text-embedding-ada-002를 썼습니다).
3. 점수 $AR=\frac1n\sum_{i=1}^{n}\mathrm{sim}(q,q_i)$.

③ 문맥 관련성(context relevance). 검색된 문맥이 답에 필요한 정보만 담고 있는가.

1. LLM이 문맥에서 질문에 답하는 데 꼭 필요한 문장만 뽑습니다.
2. 점수 $CR=$ 뽑힌 문장 수 ÷ 문맥 전체 문장 수.

숫자로 해 보기(해설용).

• 답을 진술 4개로 나눴더니 3개가 문맥으로 뒷받침됨 → $F=3/4=0.75$. 나머지 1개는 문맥에 없는 내용, 즉 환각 후보입니다.
• 답에서 만든 질문 3개와 원 질문의 유사도가 0.9, 0.8, 0.7 → $AR=0.8$.
• 문맥 8문장 중 2문장만 필요 → $CR=0.25$. 검색이 관련 없는 문장을 많이 끌어왔다는 신호입니다.

사람과 얼마나 맞나. 논문은 위키백과 기반으로 직접 만든 WikiEval 데이터에서 두 사람의 쌍대 비교 판정과의 일치율을 보고했습니다.

충실도는 사람과 잘 맞지만, 문맥 관련성은 상대적으로 어렵다는 것을 보여 줍니다. 현재 Ragas 라이브러리는 논문 이후 지표 이름과 종류가 늘어났으므로, 실제로 쓸 때는 공식 문서의 정의를 확인해야 합니다.

LLM으로 평가할 때 주의할 점. 심판 LLM도 틀립니다. MT-Bench 논문(Zheng 외 2023)은 답이 놓인 순서, 답의 길이, 자기가 쓴 답에 따라 판정이 기우는 위치 · 장황함 · 자기 강화 편향을 보고했습니다(LLM 평가 수업 참고). 그래서 (1) 소수 표본은 사람이 직접 확인해 심판의 판정과 비교하고 (2) 심판 프롬프트 · 모델을 고정해 버전 간 비교에만 쓰는 것이 안전합니다.

4. 실패 유형: 어디서 틀리나

Barnett 외(2024)는 연구 · 교육 · 바이오의학 세 분야의 RAG 구축 경험에서 7가지 실패 지점(failure point, FP)을 정리했습니다.

이 논문의 두 가지 핵심 교훈은 ① RAG의 검증은 실제 운영 중에야 제대로 가능하고 ② 견고함은 처음에 설계로 다 정해지는 것이 아니라 운영하며 진화한다 는 것입니다. 평가 세트를 한 번 만들고 끝내지 말고, 운영 로그의 실패 사례를 계속 평가 세트에 더해야 한다는 뜻입니다.

5. 고급 패턴 지도

기본 RAG는 "항상 한 번 검색 → 상위 K개 → 생성"입니다. 고급 패턴들은 이 고정된 흐름의 약점을 하나씩 겨냥합니다.

에이전틱 RAG를 조금 더. "작년 매출 1위 제품의 올해 불량률은?" 같은 질문은 1위 제품을 먼저 찾아야 다음 검색어가 정해집니다. 고정된 한 번 검색으로는 풀 수 없고, LLM이 도구 호출로 검색 함수를 여러 번 부르며 중간 결과를 보고 다음 검색어를 정해야 합니다. 대가는 호출 횟수(지연 · 비용)와, 루프가 엉뚱하게 길어질 위험입니다. 그래서 최대 단계 수와 단계별 로그를 꼭 둡니다.

무엇부터 시도하나(해설용 권장). 기본 RAG + 하이브리드 검색 + 리랭킹 + 평가 세트를 먼저 갖추고, 실패 사례가 특정 유형에 몰릴 때 그 유형을 겨냥한 패턴을 더합니다. 전역 요약 질문이 많으면 GraphRAG · RAPTOR, 다단계 질문이 많으면 에이전틱 RAG, 엉뚱한 문서를 믿는 경우가 많으면 CRAG식 검색 평가 단계를 고려합니다.

6. 긴 문맥에 다 넣으면 RAG가 필요 없을까

문맥 창이 수십만 토큰까지 커지면서 "그냥 다 넣으면 되지 않나"라는 질문이 나옵니다. 판단 재료는 세 가지입니다.

• 규모: Anthropic의 맥락 검색 글은 지식 베이스가 20만 토큰(약 500쪽) 미만이면 전체를 프롬프트에 넣는 것을 고려하라고 권합니다. 이보다 크면 검색이 필요합니다.
• 활용 품질: 중간에서 길을 잃다 는 관련 정보가 입력의 처음이나 끝에 있을 때 성능이 가장 좋고, 긴 문맥 한가운데에 있으면 크게 떨어지는 U자형 곡선을 보고했습니다. 길게 넣는다고 다 활용하는 것은 아닙니다.
• 비용 · 지연: 질문마다 전체를 넣으면 입력 토큰 비용과 응답 시간이 커집니다(프롬프트 캐싱으로 일부 줄일 수 있습니다).

결론적으로 둘은 경쟁 관계라기보다 조합 관계입니다. 작은 자료는 통째로, 큰 자료는 검색으로 좁힌 뒤 긴 문맥에 넉넉히 넣는 식입니다.

연습 문제

1. 답을 진술 5개로 나눴고 문맥이 2개만 뒷받침한다면 충실도는? 이 답을 어떻게 해석하나요?
   • 풀이: $F=2/5=0.4$ 입니다. 진술 절반 이상이 문맥 밖에서 왔으므로 환각 가능성이 높고, 검색 실패(FP2) 또는 모델이 문맥을 무시한 경우를 의심합니다.
2. 관련 여부가 (관련, 아님, 아님)이고 관련 문서가 1개뿐이면 nDCG@3은?
   • 풀이: DCG $=1$, IDCG $=1$ 이므로 1.0입니다.
3. 질문 3개의 첫 정답 순위가 1위, 3위, 못 찾음이면 MRR은?
   • 풀이: $(1+1/3+0)/3\approx0.444$ 입니다.
4. "올해 사내 공지 전체에서 가장 자주 나온 불만은?"이라는 질문에 기본 RAG가 약한 이유와 대안은?
   • 풀이: 답이 특정 청크가 아니라 자료 전체에 흩어진 전역 질문이라, 상위 K 청크만으로는 전체를 볼 수 없습니다. GraphRAG의 커뮤니티 요약이나 RAPTOR의 요약 트리 같은 전역 요약 구조가 대안입니다.

스스로 점검

1. 충실도와 답변 관련성의 차이는?
   • 답: 충실도는 답이 문맥에 근거했는지, 답변 관련성은 답이 질문에 맞는지 를 봅니다. 문맥에 충실하지만 질문과 동떨어진 답, 질문에 맞지만 근거 없는 답이 각각 가능합니다.
2. 운영 중인 RAG에서 "자료에 없는 질문에 그럴듯하게 답한다"는 신고가 왔다면 어떤 실패 지점이고 무엇을 하나요?
   • 답: FP1(내용 없음)입니다. 모르면 모른다고 답하라는 지시를 강화하고, 자료에 없는 질문을 평가 세트에 넣어 거절 비율을 잽니다.
3. 에이전틱 RAG의 장점과 대가는?
   • 답: 중간 결과를 보며 검색을 여러 번 해 다단계 질문을 풀 수 있지만, 호출 횟수 증가로 지연 · 비용이 늘고 루프가 길어질 위험이 있습니다.

용어 정리

더 깊이 보려면

• Self-RAG: 검색 · 생성 · 자기 비평을 함께 학습
• 교정 검색 증강 생성 (Corrective RAG)
• RAPTOR: 트리 구조로 요약해 검색하기
• 지역에서 전역으로: 그래프 RAG (GraphRAG)
• 환각: 왜 생기고 어떻게 줄이나 — 충실도가 낮을 때 함께 볼 수업

다음에 볼 것

• REALM: 검색을 더한 언어 모델 사전학습 — 여기서부터는 검색을 모델 학습 안에 넣는 연구 흐름을 원 논문으로 따라갑니다
• 중간 점검: RAG · 검색 — 트랙 전체 복습 문제

라이선스

본문은 KAITABASE 자체 해설입니다. 숫자 예는 이 수업을 위해 만든 해설용 예이며 파이썬으로 검산했습니다. 논문 수치는 각 원문에서 확인한 것만 옮겼습니다.

출처

• Es 외, Ragas: Automated Evaluation of Retrieval Augmented Generation (2023): arxiv.org/abs/2309.15217
• Barnett 외, Seven Failure Points When Engineering a Retrieval Augmented Generation System (2024): arxiv.org/abs/2401.05856
• Asai 외, Self-RAG (2023): arxiv.org/abs/2310.11511
• Yan 외, Corrective Retrieval Augmented Generation (2024): arxiv.org/abs/2401.15884
• Sarthi 외, RAPTOR (2024): arxiv.org/abs/2401.18059
• Edge 외, From Local to Global: A GraphRAG Approach to Query-Focused Summarization (2024): arxiv.org/abs/2404.16130
• Liu 외, Lost in the Middle (2023): arxiv.org/abs/2307.03172
• Anthropic, Introducing Contextual Retrieval (2024-09-19): anthropic.com/news/contextual-retrieval
• Zheng 외, Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (2023): arxiv.org/abs/2306.05685
• Ragas 문서: docs.ragas.io