[바미] RAG가 틀렸을 때 RAG의 문제일까? LLM의 문제일까?

들어가기 전에

앞선 글에서는 Precision@K, Recall@K, MRR, NDCG와 같은 정보 검색 평가 지표를 살펴봤습니다.

이 지표들을 사용하면 RAG가 정답 문서를 얼마나 잘 찾았는지, 관련 문서를 상위에 얼마나 잘 배치했는지를 수치로 확인할 수 있습니다.

 

그런데 RAG 시스템에서 사용자가 마주하는 것은 검색 결과가 아니라 최종 답변입니다.

 

RAG가 관련 문서를 정확히 찾았더라도 LLM이 문서 내용을 잘못 해석하면 틀린 답변이 나올 수 있습니다. 반대로 검색된 문서가 충분하지 않았는데도 LLM이 사전 학습 과정에서 배운 지식을 활용해 그럴듯한 정답을 만들 수도 있습니다. 최종 답변만 놓고 보면 두 경우를 구분하기 어렵습니다.

 

예를 들어 RAG가 틀린 답변을 생성했을 때 임베딩 모델부터 교체했는데 실제 원인은 LLM이 검색된 근거를 무시한 것이었다면 RAG 를 아무리 개선해도 문제가 해결되지 않습니다.

 

반대로 LLM이나 프롬프트를 계속 변경했는데, 애초에 정답 문서가 검색되지 않았다면 생성 단계를 개선해도 정답을 만들 근거가 없습니다.

 

따라서 RAG를 평가할 때는 단순히 답변이 맞는지만 보는 것이 아니라 검색 단계와 생성 단계를 나눠서 살펴봐야 합니다.

이번 글에서는 RAG Evaluation과 Retrieval Evaluation의 차이를 알아보고 Context Precision, Context Recall, Faithfulness, Answer Relevancy, Groundedness를 통해 검색 실패와 생성 실패를 구분하는 방법을 정리해보겠습니다.

RAG는 하나의 모델이 아니라 파이프라인입니다

RAG를 하나의 질문 답변 모델처럼 생각하면 평가할 때도 최종 답변만 확인하기 쉽습니다.

 

하지만 실제 RAG는 여러 단계가 연결된 파이프라인입니다.

사용자 질문
    ↓
질문을 벡터로 변환
    ↓
관련 문서 검색
    ↓
검색 결과 정렬 및 선별
    ↓
선택된 문서를 LLM에 전달
    ↓
최종 답변 생성

각 단계는 서로 다른 역할을 담당합니다.

 

Retriever는 사용자의 질문과 관련 있는 문서를 찾습니다. Reranker가 있다면 검색된 후보 문서의 순서를 다시 조정합니다.

마지막으로 LLM은 전달받은 문서를 바탕으로 답변을 생성합니다.

 

이 구조에서는 최종 답변이 틀리는 이유도 하나가 아닙니다.

정답 문서가 검색되지 않았을 수 있습니다.

관련 없는 문서가 너무 많이 검색되었을 수 있습니다.

정답 문서가 검색되었지만 상위 결과에서 밀렸을 수 있습니다.

정답 근거가 LLM에 전달되었지만 모델이 이를 사용하지 않았을 수 있습니다.

LLM이 문서에 없는 내용을 추가했을 수 있습니다.

근거에는 충실하지만 질문과 동떨어진 답변을 했을 수 있습니다.

이처럼 RAG의 실패 원인은 검색 단계와 생성 단계에 걸쳐 있습니다.

그래서 전체 파이프라인을 하나의 점수로만 평가하면 어디를 고쳐야 하는지 알기 어렵습니다.

Retrieval Evaluation과 RAG Evaluation은 무엇이 다를까요?

Retrieval Evaluation은 검색 단계의 품질을 평가합니다.

 

핵심 질문은 다음과 같습니다.

RAG가 답변에 필요한 문서를 제대로 찾아왔는가?

 

앞선 글에서 살펴본 Precision@K, Recall@K, MRR, NDCG가 대표적인 Retrieval Evaluation 지표입니다.

반면 RAG Evaluation은 검색 결과를 전달받은 LLM이 최종 답변을 얼마나 잘 생성했는지까지 평가합니다.

 

여기서는 다음과 같은 질문을 확인합니다.

검색된 문서가 질문에 적절했는가?

LLM은 검색된 문서를 근거로 답변했는가?

답변은 사용자의 질문을 제대로 해결했는가?

답변에 근거가 없는 내용이 추가되지는 않았는가?

 

두 평가의 차이를 정리하면 다음과 같습니다.

구분	평가 대상	핵심 질문
Retrieval Evaluation	검색된 문서 또는 청크	필요한 문서를 제대로 찾았는가?
Generation Evaluation	LLM이 생성한 답변	전달된 근거를 올바르게 사용했는가?
RAG Evaluation	검색부터 생성까지 전체 과정	적절한 근거를 찾아 신뢰할 수 있는 답변을 만들었는가?

 

RAG Evaluation은 Retrieval Evaluation을 포함하는 더 넓은 개념으로 볼 수 있습니다.

다만 실제 평가에서는 전체 점수 하나를 만드는 것보다 검색과 생성을 분리해서 확인하는 것이 중요합니다.

같은 오답이라도 원인은 다릅니다

예시를 하나 살펴보겠습니다. 사용자가 다음과 같이 질문했습니다.

질문: A사의 2025년 2분기 영업이익은 얼마인가요?

지식 베이스에는 다음 내용이 들어 있습니다.

A사의 2025년 2분기 영업이익은 35억 원입니다.

그런데 RAG가 다음과 같이 답변했습니다.

A사의 2025년 2분기 영업이익은 53억 원입니다.

최종 답변만 보면 단순히 숫자를 틀린 것처럼 보입니다. 하지만 파이프라인을 확인하면 원인은 여러 가지일 수 있습니다.

RAG가 다른 문서를 가져온 경우

검색 문서:
A사의 2024년 2분기 영업이익은 53억 원입니다.

LLM은 검색된 문서를 그대로 사용했습니다.

 

이 경우 LLM은 주어진 근거에 충실하게 답했지만 RAG가 잘못된 기간의 문서를 가져왔습니다. 문제의 중심은 Retriever나 메타데이터 필터에 있습니다.

정답 문서를 가져왔지만 LLM이 숫자를 바꾼 경우

검색 문서:
A사의 2025년 2분기 영업이익은 35억 원입니다.

생성 답변:
A사의 2025년 2분기 영업이익은 53억 원입니다.

이번에는 검색이 정상적으로 동작했습니다.

 

하지만 LLM이 검색 문서의 숫자를 잘못 사용했습니다. 이 경우에는 생성 모델, 프롬프트 또는 숫자 처리 방식이 문제입니다.

관련 문서를 가져왔지만 답이 없는 경우

검색 문서:
A사는 2025년 2분기에 신규 사업 투자를 확대했습니다.

문서가 A사의 2025년 2분기와 관련은 있지만 영업이익 수치는 포함하고 있지 않습니다.

 

주제상으로는 관련된 문서이지만 질문에 답할 수 있는 충분한 근거는 아닙니다.

이처럼 검색 결과가 질문과 같은 주제를 다룬다는 사실과 실제 정답을 포함한다는 것은 다릅니다.

근거 없이 정답을 맞힌 경우

검색 문서:
A사의 2025년 2분기 매출은 450억 원입니다.

생성 답변:
A사의 2025년 2분기 영업이익은 35억 원입니다.

 

최종 답변은 맞았습니다.

 

하지만 검색 문서에는 35억 원이라는 근거가 없습니다. LLM이 사전 학습 과정에서 해당 정보를 알고 있었거나 우연히 맞혔을 가능성이 있습니다.

 

답변 정확도만 평가하면 성공으로 처리되지만, RAG 시스템의 관점에서는 신뢰하기 어려운 결과입니다.

다른 질문에서도 같은 방식으로 맞힐 것이라고 보장할 수 없기 때문입니다.

 

이 사례가 보여주는 핵심은 다음과 같습니다.

정답과 일치하는 답변이 항상 근거에 충실한 답변은 아니며, 근거에 충실한 답변이 항상 정답인 것도 아닙니다.

검색된 문서의 품질을 보는 Context Precision

Context Precision은 검색된 컨텍스트 중 실제로 질문에 답하는 데 유용한 컨텍스트가 얼마나 포함되어 있는지를 평가합니다.

쉽게 말하면 다음 질문에 답하는 지표입니다.

검색 결과에 불필요한 문서가 얼마나 섞여 있는가?

 

사용자가 A사의 영업이익을 질문했고 다음 다섯 개의 문서가 검색되었다고 가정해보겠습니다.

1. A사의 2025년 2분기 영업이익 자료
2. A사의 2025년 2분기 손익계산서
3. A사의 사옥 이전 안내
4. B사의 2025년 2분기 영업이익 자료
5. A사의 채용 공고

 

이 중 질문에 답하는 데 직접 도움이 되는 문서는 1번과 2번입니다. 나머지 문서도 일부 키워드는 겹치지만 영업이익 질문에는 필요하지 않습니다.

 

Context Precision이 낮다는 것은 검색 결과에 이런 불필요한 문서가 많이 섞였다는 의미입니다.

관련 없는 컨텍스트가 많으면 다음과 같은 문제가 생깁니다.

LLM의 입력 토큰이 불필요하게 증가합니다.

중요한 근거가 다른 정보 사이에 묻힐 수 있습니다.

서로 다른 문서의 내용을 혼합할 가능성이 커집니다.

답변에 불필요한 내용이 추가될 수 있습니다.

Context Precision이 낮을 때는 다음 부분을 살펴볼 수 있습니다.

Retriever가 유사한 키워드만 보고 문서를 검색하지는 않았는가?

검색 결과의 top_k가 지나치게 크지는 않은가?

메타데이터 필터가 제대로 적용되었는가?

Reranker가 관련 없는 문서를 제거하지 못했는가?

청크가 너무 커서 무관한 내용까지 포함하고 있지는 않은가?

Context Precision은 이전 글에서 살펴본 검색 Precision과 비슷해 보입니다. 다만 평가 프레임워크에 따라 계산 방식에는 차이가 있습니다. 정답 문서 레이블을 기준으로 계산할 수도 있고, LLM Judge가 검색된 각 컨텍스트가 질문이나 기준 답변에 유용한지 판단하도록 만들 수도 있습니다.

 

그래서 같은 이름의 지표라도 어떤 입력과 평가 방식을 사용하는지 함께 확인해야 합니다.

필요한 근거를 빠짐없이 찾았는지 보는 Context Recall

Context Recall은 정답을 만드는 데 필요한 정보가 검색된 컨텍스트에 얼마나 포함되어 있는지를 평가합니다.

핵심 질문은 다음과 같습니다.

답변에 필요한 근거를 RAG가 놓치지 않았는가?

 

사용자가 다음과 같이 질문했다고 가정해보겠습니다.

A사의 2025년 2분기 매출과 영업이익을 알려주세요.

정답을 위해서는 두 가지 정보가 필요합니다.

매출: 450억 원
영업이익: 35억 원

그런데 검색 결과에 매출 자료만 있고 영업이익 자료가 없다면 질문과 관련된 문서를 검색하기는 했지만 필요한 정보를 모두 가져오지는 못했습니다.

 

이 경우 Context Precision은 높을 수 있습니다. 검색된 문서가 모두 질문과 관련 있기 때문입니다.

하지만 Context Recall은 낮습니다. 정답에 필요한 근거 중 일부가 빠졌기 때문입니다.

 

Context Recall이 낮은 원인은 다양합니다.

정답이 여러 청크로 나뉘어 있을 수 있습니다.

검색 후보 수가 너무 적을 수 있습니다.

질문의 일부 조건만 임베딩에 반영되었을 수 있습니다.

표나 이미지 안의 정보가 색인되지 않았을 수 있습니다.

서로 다른 문서의 내용을 조합해야 하는 질문일 수 있습니다.

문서 자체가 지식 베이스에 없을 수 있습니다.

Context Recall이 낮을 때는 다음과 같은 개선 방법을 검토할 수 있습니다.

검색 top_k 늘리기

Multi-query Retrieval 적용하기

BM25와 벡터 검색 결합하기

Parent-Child Retrieval 사용하기

청크 크기와 overlap 조정하기

표와 이미지 전용 파싱 추가하기

지식 베이스의 문서 누락 확인하기

Context Precision과 Context Recall은 서로 다른 문제를 보여줍니다.

Context Precision이 낮음
→ 관련 없는 문서를 너무 많이 가져옴

Context Recall이 낮음
→ 필요한 문서를 충분히 가져오지 못함

Precision만 높이기 위해 검색 결과를 지나치게 줄이면 Recall이 떨어질 수 있고, Recall을 높이기 위해 문서를 많이 가져오면 Precision이 떨어질 수 있습니다. 그래서 두 지표를 함께 확인해야 합니다.

LLM이 근거를 지켰는지 보는 Faithfulness

RAG가 좋은 문서를 가져왔다고 해서 LLM이 항상 그 내용을 올바르게 사용하는 것은 아닙니다.

Faithfulness는 생성된 답변의 내용이 제공된 컨텍스트로 뒷받침되는지를 평가합니다.

 

쉽게 말하면 다음 질문을 확인합니다.

답변에 포함된 주장들이 검색 문서 안에서 확인되는가?

 

검색 문서가 다음과 같다고 가정해보겠습니다.

A사의 2025년 2분기 영업이익은 35억 원으로,
전년 동기 대비 8% 증가했습니다.

LLM이 다음과 같이 답변했다면 검색 문서로 뒷받침할 수 있습니다.

A사의 2025년 2분기 영업이익은 35억 원이며,
전년 동기 대비 8% 증가했습니다.

하지만 다음 답변은 어떨까요?

A사의 2025년 2분기 영업이익은 35억 원이며,
신규 해외 사업의 성장으로 전년 동기 대비 8% 증가했습니다.

영업이익과 증가율은 검색 문서에 있습니다. 하지만 증가 원인이 신규 해외 사업이라는 내용은 검색 문서에 없습니다.

문장 전체가 자연스럽고 일부 내용이 맞더라도 근거에 없는 원인을 추가했기 때문에 Faithfulness가 낮아질 수 있습니다.

 

Faithfulness를 평가할 때는 보통 답변을 여러 개의 주장으로 나누고 각 주장을 컨텍스트가 뒷받침하는지 확인합니다.

주장 1: 영업이익은 35억 원이다.
→ 컨텍스트에서 확인 가능

주장 2: 전년 동기 대비 8% 증가했다.
→ 컨텍스트에서 확인 가능

주장 3: 신규 해외 사업이 증가 원인이다.
→ 컨텍스트에서 확인 불가

Faithfulness가 낮다면 검색보다 생성 단계의 문제일 가능성이 큽니다.

 

이 때는 다음을 살펴볼 수 있습니다.

프롬프트에 문서에 없는 내용을 추측하지 말라는 지시가 있는가?

근거가 부족할 때 답변을 거부하도록 했는가?

LLM에 너무 많은 문서를 전달하고 있지는 않은가?

서로 모순되는 문서가 함께 전달되지는 않았는가?

인용과 출처 표시를 강제하고 있는가?

사용 중인 생성 모델이 지시를 잘 따르는가?

여기서 주의할 점이 있습니다. Faithfulness는 일반적으로 답변이 컨텍스트에 충실한지를 평가하지, 답변이 현실 세계에서 사실인지를 직접 보장하지는 않습니다.

 

검색 문서 자체가 잘못되었다면 LLM이 그 문서를 그대로 사용한 답변은 Faithfulness가 높을 수 있습니다.

따라서 Faithfulness와 사실 정확성은 별도로 생각해야 합니다.

질문에 제대로 답했는지 보는 Answer Relevancy

Faithfulness가 높다고 해서 좋은 답변인 것은 아닙니다.

 

사용자의 질문과 관계없는 내용을 컨텍스트에서 그대로 가져온 답변도 근거에는 충실할 수 있기 때문입니다.

Answer Relevancy는 생성된 답변이 사용자의 질문 의도에 얼마나 직접적으로 부합하는지를 평가합니다.

 

다음 질문을 예로 들어보겠습니다.

질문:
A사의 2025년 2분기 영업이익은 얼마인가요?

답변이 다음과 같다면 근거에는 있을 수 있지만 질문에 직접 답하지 못합니다.

A사는 2025년 2분기에 신규 사업을 시작했습니다.
매출은 전년 대비 증가했으며 여러 비용 절감 활동도 진행했습니다.

이 답변은 A사의 2025년 2분기를 이야기하고 있지만 사용자가 요청한 영업이익 금액을 제공하지 않습니다.

 

반대로 다음 답변은 질문에 직접 답합니다.

A사의 2025년 2분기 영업이익은 35억 원입니다.

Answer Relevancy가 낮아지는 대표적인 경우는 다음과 같습니다.

질문의 핵심을 빼고 주변 정보만 설명한 경우

질문의 일부에만 답한 경우

필요 이상으로 장황하게 답한 경우

다른 시점이나 다른 대상을 기준으로 답한 경우

사용자가 요청하지 않은 정보를 중심으로 답한 경우

Answer Relevancy가 낮을 때는 다음 부분을 점검할 수 있습니다.

질문을 제대로 해석하고 있는가?

대화형 질문을 독립적인 질문으로 재작성했는가?

여러 요구사항이 있는 질문을 모두 반영했는가?

프롬프트가 먼저 직접적인 답부터 제시하도록 구성되어 있는가?

검색 결과의 내용에 끌려가 질문의 핵심을 놓치고 있지는 않은가?

Answer Relevancy는 답변의 사실 여부와는 다른 관점입니다.

 

질문에 정확히 대응하는 문장이라도 내용이 틀릴 수 있고 내용이 모두 사실이어도 질문에 답하지 않을 수 있습니다.

Groundedness는 Faithfulness와 무엇이 다를까요?

Groundedness 역시 답변이 제공된 근거에 기반하고 있는지를 평가합니다. 그래서 Faithfulness와 매우 비슷하게 느껴질 수 있습니다. 실제로 평가 도구나 문서에 따라 두 용어를 거의 같은 의미로 사용하기도 하고 조금 다르게 정의하기도 합니다.

 

따라서 이름만 보고 구분하기보다 사용하는 평가 프레임워크의 정의를 확인하는 것이 중요합니다. 보편적인 관점에서 Groundedness는 다음 질문을 확인합니다.

생성된 답변이 주어진 컨텍스트와 일치하며, 근거 없이 만들어낸 내용을 포함하지 않는가?

 

예를 들어 컨텍스트가 다음과 같다고 하겠습니다.

A사의 영업이익은 35억 원입니다.

다음 답변은 Groundedness가 높습니다.

A사의 영업이익은 35억 원입니다.

반면 다음 답변은 컨텍스트가 뒷받침하지 못하는 내용을 포함합니다.

A사의 영업이익은 35억 원이며,
이는 업계에서 가장 높은 수준입니다.

업계에서 가장 높은 수준이라는 내용은 제공된 근거에서 확인할 수 없습니다. Faithfulness와 Groundedness 모두 이런 근거 없는 생성을 탐지하려는 목적을 가집니다.

 

다만 도구에 따라 Faithfulness는 답변을 개별 주장으로 나눈 뒤 각 주장이 컨텍스트에서 추론 가능한지를 평가하는 지표로 정의되기도 합니다.

 

Groundedness는 최종 응답이 컨텍스트와 전반적으로 얼마나 일치하는지를 LLM Judge가 점수화하는 형태로 구현되기도 합니다.

 

이를 간단하게 정리하면 다음과 같습니다.

Faithfulness
→ 답변의 각 주장이 컨텍스트로 뒷받침되는지 확인

Groundedness
→ 답변 전체가 주어진 근거 안에서 생성되었는지 확인

하지만 이것이 모든 프레임워크에 공통으로 적용되는 절대적인 구분은 아닙니다.

 

Ragas, Microsoft Foundry, TruLens 등은 각각 사용하는 용어와 계산 방식이 다릅니다. 한 프로젝트 안에서는 특정 프레임워크의 정의를 기준으로 지표를 일관되게 사용하는 것이 좋습니다.

다섯 지표를 함께 보면 실패 지점을 찾을 수 있습니다

각 지표는 서로 다른 질문에 답합니다.

Context Precision
→ 검색된 문서 중 불필요한 문서가 얼마나 적은가?

Context Recall
→ 답변에 필요한 근거를 빠짐없이 찾았는가?

Faithfulness
→ 답변의 주장이 검색된 근거로 뒷받침되는가?

Answer Relevancy
→ 답변이 사용자의 질문에 직접 대응하는가?

Groundedness
→ 답변이 주어진 컨텍스트 범위 안에서 생성되었는가?

지표를 조합하면 어느 단계에서 문제가 발생했는지 추정할 수 있습니다.

Context Recall이 낮고 Faithfulness가 높은 경우

검색된 문서:
일부 근거만 포함

생성된 답변:
검색된 근거 안에서만 답변

LLM은 주어진 문서를 충실하게 사용했지만 Retriever가 필요한 정보를 모두 찾지 못한 경우입니다.

검색 단계가 주요 병목일 가능성이 큽니다.

개선 대상:
청킹
임베딩 모델
검색 top_k
하이브리드 검색
Query Expansion
문서 색인 범위

Context Precision이 낮고 Faithfulness도 낮은 경우

검색 결과에 관련 없는 문서가 많이 포함되어 있고, LLM이 이 정보를 섞어 근거 없는 답변을 만든 경우입니다.

검색과 생성 단계 모두 문제가 있을 수 있습니다.

개선 대상:
Reranker
메타데이터 필터
컨텍스트 수 제한
중복 문서 제거
프롬프트
생성 모델

Context Precision과 Recall은 높지만 Faithfulness가 낮은 경우

RAG는 필요한 문서를 잘 가져왔습니다.

그런데 LLM이 문서에 없는 내용을 추가하거나 숫자를 잘못 사용했습니다.

 

이 경우 RAG를 변경하기보다 생성 단계를 먼저 살펴봐야 합니다.

개선 대상:
생성 프롬프트
모델 교체
인용 강제
답변 검증
Temperature
구조화된 출력

Faithfulness는 높지만 Answer Relevancy가 낮은 경우

LLM은 검색 문서의 내용만 사용했지만 사용자가 실제로 물어본 것에 답하지 않았습니다.

검색 결과가 질문의 주변 정보에 치우쳤거나, LLM이 질문의 핵심보다 문서 내용 요약에 집중했을 수 있습니다.

개선 대상:
Query Rewriting
질문 의도 분석
답변 프롬프트
불필요한 컨텍스트 제거
질문의 요구사항 분해

모든 지표가 높은데 사용자는 만족하지 않는 경우

자동 평가 지표가 높더라도 사용자가 원하는 형식이나 수준을 충족하지 못할 수 있습니다.

예를 들어 답변은 정확하고 근거에도 충실하지만 너무 길거나, 전문 용어가 많거나, 사용자가 요청한 표 형식을 따르지 않았을 수 있습니다.

 

이 경우에는 다음 항목도 별도로 평가해야 합니다.

답변의 간결성

문체와 난이도

형식 준수 여부

인용의 가독성

응답 속도

사용자 피드백

RAG 평가 지표는 시스템 품질을 보여주는 중요한 신호지만, 사용자 경험 전체를 하나의 점수로 대신할 수는 없습니다.

코드로 평가 데이터 구조 만들어보기

RAG 평가를 하려면 최소한 질문, 검색된 컨텍스트, 생성된 답변을 함께 저장해야 합니다.

정답 답변까지 있다면 Context Recall이나 Answer Correctness처럼 기준 답변이 필요한 평가도 수행할 수 있습니다.

evaluation_sample = {
    "user_input": "A사의 2025년 2분기 영업이익은 얼마인가요?",
    "retrieved_contexts": [
        "A사의 2025년 2분기 영업이익은 35억 원입니다.",
        "A사는 2025년 2분기에 신규 사업 투자를 확대했습니다.",
        "B사의 2025년 2분기 영업이익은 41억 원입니다."
    ],
    "response": "A사의 2025년 2분기 영업이익은 35억 원입니다.",
    "reference": "A사의 2025년 2분기 영업이익은 35억 원입니다."
}

각 필드의 역할은 다음과 같습니다.

user_input
→ 사용자의 질문

retrieved_contexts
→ Retriever가 가져온 문서 또는 청크

response
→ LLM이 생성한 최종 답변

reference
→ 평가 기준이 되는 기대 답변

이 데이터를 기준으로 각 지표는 서로 다른 값을 비교합니다.

지표	주로 비교하는 대상
Context Precision	질문·기준 답변과 검색 컨텍스트
Context Recall	기준 답변과 검색 컨텍스트
Faithfulness	사용자 질문과 생성 답변
Groundedness	생성 답변과 검색 컨텍스트

 

실제 도구별로 요구하는 필드 이름과 계산 방식은 다를 수 있습니다. 중요한 것은 평가 도구를 선택하기 전에 각 단계의 입력과 출력을 빠짐없이 기록하는 것입니다.

 

최종 답변만 저장해두면 나중에 검색 실패인지 생성 실패인지 다시 분석하기 어렵습니다.

평가 로그에는 무엇을 남겨야 할까요?

RAG를 운영하면서 병목을 분석하려면 다음 데이터를 함께 기록하는 것이 좋습니다.

rag_trace = {
    "query": "A사의 2025년 2분기 영업이익은 얼마인가요?",
    "rewritten_query": "A사 2025년 2분기 영업이익",
    "retrieved_documents": [
        {
            "document_id": "financial-report-2025-q2",
            "chunk_id": "chunk-17",
            "retrieval_score": 0.91,
            "rerank_score": 0.97,
            "content": "A사의 2025년 2분기 영업이익은 35억 원입니다."
        }
    ],
    "final_context": [
        "A사의 2025년 2분기 영업이익은 35억 원입니다."
    ],
    "response": "A사의 2025년 2분기 영업이익은 35억 원입니다.",
    "latency_ms": {
        "retrieval": 120,
        "reranking": 240,
        "generation": 830
    }
}

검색 결과만 저장하는 것이 아니라 다음 항목까지 연결해서 남기는 것입니다.

원본 질문

변환된 검색어

검색된 문서와 점수

Reranking 전후 순위

실제로 LLM에 전달한 컨텍스트

생성된 답변

각 단계의 처리 시간

이 정보가 있어야 평가 점수가 낮은 사례를 다시 확인하고 어느 단계에서 정보가 사라졌는지 추적할 수 있습니다.

 

예를 들어 정답 문서가 처음 검색 결과에는 있었지만 Reranking 이후 제외되었다면 Retriever가 아니라 Reranker의 문제입니다.

정답 문서가 최종 컨텍스트에 포함되어 있는데 답변에서 잘못된 수치를 사용했다면 생성 단계의 문제입니다.

 

평가는 점수를 계산하는 작업이면서 동시에 RAG 파이프라인을 관찰할 수 있도록 만드는 작업입니다.

LLM Judge의 점수를 그대로 믿어도 될까요?

Context Precision, Faithfulness, Answer Relevancy와 같은 지표는 LLM을 평가자로 사용하는 경우가 많습니다.

이를 LLM Judge라고 합니다.

 

사람이 모든 질문과 답변을 직접 읽고 평가하지 않아도 되기 때문에 많은 데이터를 빠르게 평가할 수 있다는 장점이 있습니다.

하지만 LLM Judge의 점수도 절대적인 정답은 아닙니다.

평가 모델에 따라 점수가 달라질 수 있습니다.

프롬프트 표현에 따라 판단이 달라질 수 있습니다.

긴 컨텍스트에서 중요한 내용을 놓칠 수 있습니다.

전문 도메인의 내용을 잘못 판단할 수 있습니다.

같은 입력에도 평가 결과가 달라질 수 있습니다.

Faithfulness와 정확성을 혼동할 수 있습니다.

따라서 자동 평가를 도입할 때는 먼저 소규모 데이터에 사람이 직접 점수를 매기고, LLM Judge의 결과가 사람의 판단과 어느 정도 일치하는지 확인하는 것이 좋습니다.

 

예를 들어 100개의 평가 샘플을 준비했다면 다음과 같은 흐름으로 검증할 수 있습니다.

1. 도메인 전문가가 직접 평가합니다.

2. 같은 데이터에 LLM Judge 평가를 실행합니다.

3. 사람과 LLM의 평가 결과가 다른 사례를 확인합니다.

4. 평가 프롬프트와 기준을 조정합니다.

5. 일치도가 충분히 높아진 뒤 전체 데이터에 적용합니다.

특히 금융, 의료, 법률처럼 작은 오류의 영향이 큰 분야에서는 자동 평가 점수만으로 배포 여부를 결정하지 않는 것이 안전합니다.

중간 정리

 

평가	지표 평가	단계 확인하는 내용	낮을 때 의심할 부분
Context Precision	검색	검색 결과에 불필요한 문서가 적은가	Retriever, Reranker, top_k, 필터
Context Recall	검색	필요한 근거를 빠짐없이 찾았는가	청킹, 임베딩, 색인, 검색 범위
Faithfulness	생성	답변의 주장이 컨텍스트로 뒷받침되는가	프롬프트, 생성 모델, 컨텍스트 충돌
Answer Relevancy	생성	답변이 사용자의 질문에 직접 대응하는가	질문 해석, Query Rewriting, 답변 형식
Groundedness	생성·전체	답변이 제공된 근거 범위 안에 있는가	환각 방지 지시, 인용, 생성 검증

 

이 다섯 지표는 하나의 사이클로 연결됩니다.

Context Precision과 Context Recall
→ RAG가 좋은 근거를 제공했는지 확인

Faithfulness와 Groundedness
→ LLM이 제공된 근거 안에서 답변했는지 확인

Answer Relevancy
→ 최종 답변이 사용자의 질문을 해결했는지 확인

어느 한 지표만으로 RAG 전체 품질을 판단할 수는 없습니다.

 

RAG가 정답 문서를 찾았더라도 LLM이 잘못 사용할 수 있고 답변이 근거에 충실하더라도 사용자의 질문에는 제대로 답하지 못할 수 있기 때문입니다.

마치며

RAG가 틀린 답변을 생성했다고 해서 항상 LLM의 환각으로만 볼 수는 없습니다.

정답 문서가 검색되지 않았거나 필요한 정보 중 일부가 누락되었거나, 관련 없는 문서가 컨텍스트를 차지한 것이 원인일 수 있습니다.

 

반대로 검색 결과가 완벽하더라도 LLM이 문서에 없는 내용을 추가하거나 질문과 동떨어진 답변을 만들 수 있습니다.

그래서 RAG 평가는 다음 두 질문에서 시작해야 합니다.

RAG는 답변에 필요한 근거를 제대로 찾았는가?

LLM은 그 근거를 올바르게 사용했는가?

Context Precision과 Context Recall은 첫 번째 질문에 답합니다.

 

Faithfulness, Groundedness, Answer Relevancy는 두 번째 질문을 여러 관점에서 확인합니다.

이 지표들을 분리해서 살펴보면 단순히 “RAG 정확도가 낮다”는 결론에서 벗어나 다음처럼 구체적인 진단을 내릴 수 있습니다.

필요한 문서가 검색되지 않았습니다.

검색은 성공했지만 불필요한 문서가 너무 많습니다.

정답 근거는 전달되었지만 LLM이 사용하지 않았습니다.

답변은 근거에 충실하지만 질문에 직접 답하지 않았습니다.

문서에 없는 내용을 답변에 추가했습니다.

문제의 위치가 명확해지면 개선 방향도 달라집니다.

 

검색 실패라면 청킹, 임베딩, 검색 방식, Reranking을 살펴봐야 합니다. 생성 실패라면 프롬프트, 컨텍스트 구성, 생성 모델, 답변 검증 방식을 개선해야 합니다.

 

결국 RAG Evaluation의 목적은 점수를 높이는 것만이 아닙니다. 검색부터 생성까지 이어지는 파이프라인에서 어디가 병목인지 찾아내고, 변경해야 할 부분을 정확히 선택하는 데 있습니다.

참고 자료

• RAGAs: Automated Evaluation of Retrieval Augmented Generation
• Ragas 공식 문서 - Context Precision
• Ragas 공식 문서 - Context Recall
• Ragas 공식 문서 - Faithfulness
• Ragas 공식 문서 - Response Relevancy
• Microsoft Foundry 공식 문서 - RAG Evaluators
• TruLens 공식 문서 - RAG Triad