STEP 11 - 답변 품질을 측정하는 방법

RAG 시스템 평가하기 - 답변 품질을 측정하는 방법

지난 글에서 Reranking으로 검색 정확도를 끌어올리는 방법을 다뤘습니다. 그런데 검색과 답변 생성 단계를 아무리 잘 구축해도, "지금 이 RAG 시스템이 실제로 잘 동작하고 있는가"를 객관적으로 판단할 방법이 없다면 개선 방향을 잡기 어렵습니다. 이번 글에서는 RAG 시스템을 정량적으로 평가하는 방법을 정리합니다.

1. 왜 RAG는 평가가 특히 어려운가

일반적인 분류 모델은 "정답이 맞았는가 틀렸는가"로 명확하게 평가할 수 있습니다. 하지만 RAG는 평가해야 할 지점이 여러 단계로 나뉘어 있습니다.

질문 → [검색 단계] 관련 문서를 잘 찾아왔는가?
     → [생성 단계] 찾아온 문서를 바탕으로 답변을 잘 만들었는가?

검색은 잘했는데 답변 생성에서 문서를 제대로 반영하지 못할 수도 있고, 반대로 검색 자체가 엉뚱한 문서를 가져와서 애초에 좋은 답변이 나올 수 없는 경우도 있습니다. 그래서 RAG는 검색 품질과 생성 품질을 각각 나눠서 평가해야 원인을 정확히 짚을 수 있습니다.

2. 검색 단계 평가 지표

Context Precision (정밀도)

검색된 문서 중 실제로 질문과 관련 있는 문서의 비율입니다.

검색된 문서 5건 중 실제 관련 문서가 3건
→ Context Precision = 3/5 = 0.6

관련 없는 문서가 많이 섞여 있으면 이 값이 낮아집니다. 앞서 다룬 Reranking은 이 지표를 개선하는 데 직접적으로 기여합니다.

Context Recall (재현율)

정답을 만드는 데 필요한 문서 중, 실제로 검색된 문서의 비율입니다.

정답을 위해 필요한 문서가 총 4건인데, 검색 결과에는 그중 2건만 포함됨
→ Context Recall = 2/4 = 0.5

이 값이 낮으면 애초에 벡터 DB에 필요한 문서가 없거나, 청킹이 잘못돼서 필요한 정보가 검색 후보에서 아예 빠졌을 가능성을 의심해봐야 합니다.

3. 생성 단계 평가 지표

Faithfulness (충실도)

생성된 답변이 검색된 문서 내용에 얼마나 근거하고 있는지를 나타냅니다. 문서에 없는 내용을 답변이 지어냈다면 이 값이 낮아집니다.

검색 문서: "재택근무는 팀장 승인 하에 주 2회까지 가능합니다."
답변: "재택근무는 주 3회까지 가능하며 별도 승인이 필요 없습니다."
→ 문서 내용과 불일치, Faithfulness 낮음 (Hallucination 발생)

RAG를 도입하는 가장 큰 이유가 Hallucination을 줄이기 위함이었던 만큼, 이 지표가 가장 핵심적인 평가 기준입니다.

Answer Relevancy (답변 관련성)

생성된 답변이 실제로 질문의 의도에 맞게 답하고 있는지를 측정합니다. 문서 내용은 정확히 인용했지만 질문의 핵심을 비껴간 답변이라면 이 값이 낮아집니다.

4. RAGAS로 평가 자동화하기

이런 지표들을 사람이 매번 수작업으로 판단하기는 어렵기 때문에, LLM을 평가자로 활용해 자동으로 채점하는 RAGAS 같은 오픈소스 프레임워크를 사용합니다.

pip install ragas

from ragas import evaluate
from ragas.metrics import (
    context_precision,
    context_recall,
    faithfulness,
    answer_relevancy,
)
from datasets import Dataset

eval_data = {
    "question": ["재택근무 승인은 누가 하나요?"],
    "answer": ["재택근무는 팀장 승인 하에 가능합니다."],
    "contexts": [["재택근무는 팀장 승인 하에 주 2회까지 가능합니다."]],
    "ground_truth": ["재택근무는 팀장 승인이 필요합니다."],
}

dataset = Dataset.from_dict(eval_data)

result = evaluate(
    dataset,
    metrics=[context_precision, context_recall, faithfulness, answer_relevancy],
)

print(result)

[출력 예시]
{'context_precision': 0.92, 'context_recall': 0.85,
 'faithfulness': 0.95, 'answer_relevancy': 0.88}

내부적으로는 별도의 LLM(주로 GPT 계열)이 "이 답변이 문서에 충실한가", "검색된 문서가 질문과 관련 있는가"를 판단해서 점수를 매기는 방식입니다. 사람이 일일이 채점하는 대신, 질문-답변-검색문서 세트만 준비하면 지표를 자동으로 뽑아낼 수 있습니다.

5. 평가 데이터셋은 어떻게 만드는가

RAGAS를 돌리려면 질문, 정답, 검색된 문서로 이루어진 평가용 데이터셋이 필요합니다. 실무에서는 보통 두 가지 방식을 함께 씁니다.

• 실사용 로그 기반: 실제 사용자가 던진 질문과, 사람이 검수해서 확정한 정답을 축적해 데이터셋으로 사용합니다.
• LLM으로 질문 자동 생성: 원본 문서를 LLM에 넣고 "이 문서로 답할 수 있는 질문을 만들어줘"라고 요청해서 초기 평가셋을 빠르게 확보합니다.

prompt = f"""
다음 문서를 읽고, 이 문서만으로 답변 가능한 질문 3개와 각각의 정답을 만들어줘.

문서: {document_text}
"""

서비스 초기에는 LLM으로 빠르게 평가셋을 만들어 방향을 잡고, 운영하면서 쌓이는 실사용 로그로 점차 데이터셋을 정교하게 다듬어가는 흐름이 일반적입니다.

6. 지표가 낮게 나왔을 때 무엇을 고칠지

각 지표가 어느 단계 문제인지 알면, 개선 지점도 자연스럽게 정해집니다.

지표	낮게 나오면 의심할 부분
Context Precision	Reranking 도입 검토, 검색 K값 조정
Context Recall	청킹 전략 재검토, 벡터 DB에 누락된 문서 확인
Faithfulness	프롬프트에 "문서에 없으면 모른다고 답해" 지침 강화
Answer Relevancy	프롬프트 템플릿 수정, 질문 의도 파악 로직 보강

지표를 하나의 숫자로만 보지 않고, 각 지표가 파이프라인의 어느 단계와 연결되는지 짚어가며 개선하는 것이 핵심입니다.

7. 정리

• RAG는 검색 단계와 생성 단계를 나눠서 평가해야 문제의 원인을 정확히 짚을 수 있습니다.
• Context Precision·Recall은 검색 품질을, Faithfulness·Answer Relevancy는 생성 품질을 나타내는 핵심 지표입니다.
• RAGAS 같은 프레임워크를 활용하면 LLM을 평가자로 사용해 이 지표들을 자동으로 측정할 수 있습니다.

지금까지 이론부터 구축, 검색 정확도 개선, 평가까지 RAG의 전체 사이클을 한 바퀴 돌아봤습니다. 다음 글에서는 이 모든 걸 실제 서비스에 붙일 때 필요한 프롬프트 엔지니어링 기법을 다뤄보겠습니다.