26. RAG 평가, 검색 근거와 생성 답변을 따로 살펴보기
복습 음성 · 38분 13초 · RAG 평가 개념과 예제 코드 흐름 · 18장 · 파일에 1.1배속 적용
검색 결과에 정답 근거가 들어 있어도 답변에서 조건 하나가 빠질 수 있다. 문서에는 “예약자가 없을 때 연장 가능”이라고 적혀 있는데 챗봇이 “연장할 수 있습니다”라고만 답하는 경우다. 답변을 고치려면 검색한 문서와 모델이 실제로 한 말을 함께 확인해야 한다.
LLM-as-a-Judge(LLM 평가자)는 모델에 답변의 평가를 맡기는 방식이다. G-Eval은 채점 기준과 절차를 구체화하고 RAGAS의 네 지표는 질문·답변·검색 문맥의 관계를 서로 다른 기준으로 계산한다.
음성은 개념과 첨부 실습의 데이터 흐름을 설명하고, PER·파리·블랙홀 예제의 저장 출력을 읽는 법을 다룬다. 본문은 같은 개념을 가상 도서관 규정으로 풀어쓴 공부 기록이다. 음성 파일에 1.1배속을 적용했으므로 플레이어는 1.0배속으로 두면 된다.
1. 답변을 평가할 때 무엇을 확인할까
Retrieval(검색)은 질문에 필요한 근거를 찾고, Generation(생성)은 그 근거를 사용해 답변을 만든다. 검색과 생성을 연결하는 RAG(Retrieval-Augmented Generation, 검색 증강 생성)의 평가는 두 단계의 관계를 함께 본다.
설명에 사용할 가상 도서관 규정은 다음과 같다.
책의 기본 대출 기간은 14일이다. 예약자가 없을 때 한 번에 한해 7일 연장할 수 있다. 열람실은 오후 9시까지 운영한다.
질문은 “책은 며칠 빌릴 수 있고, 연장 조건은 무엇인가요?”다. 모델이 대출 기간만 답했다면 검색 결과부터 펼쳐본다. 연장 조건 문서를 찾지 못했는지, 찾았는데 답변에서 빠뜨렸는지에 따라 다음 수정 위치가 달라진다.
앞선 검색 실험의 Hit@3(상위 3개 검색 적중률)은 정답 근거가 상위 세 결과에 있는지 확인했다. 생성 모델이 그 근거를 정확하게 사용했는지는 별도로 평가한다. 하나의 점수로 모든 과정을 설명하기보다 점수가 답하는 질문을 먼저 정해두면 해석하기 쉽다.
2. BLEU와 ROUGE 그리고 벤치마크의 범위
BLEU와 ROUGE는 기준 문장과 생성 문장의 표현이 얼마나 겹치는지 활용하는 전통적인 지표다. 세부 계산은 다르지만 N-gram(연속된 단어 묶음) 등의 겹침이 중요한 단서다.
“대출 기간은 14일이다”와 “책은 2주 동안 빌릴 수 있다”는 표현이 달라도 비슷한 뜻을 전한다. 단어의 겹침만으로는 이런 관계를 충분히 읽기 어렵다. 반대로 숫자와 단어가 많이 겹쳐도 연장 조건을 반대로 썼다면 사용자가 잘못 행동할 수 있다. 빠르고 일정한 비교 기준으로 기존 지표를 활용하면서 의미와 근거를 보는 평가를 보완한다.
Benchmark(벤치마크)는 모델을 비교할 문제 모음이다. 다루는 범위가 서로 다르다.
| 자료의 예 | 주로 살펴보는 범위 | RAG에서 추가로 확인할 것 |
|---|---|---|
| MMLU, HellaSwag, HumanEval, GSM8K | 여러 분야의 지식, 상식 추론, 코드, 수학 | 우리 문서의 최신 내용과 조건을 활용하는가 |
| Flan, Self-Instruct, Super-NaturalInstructions | 지시를 따르는 학습·평가 자료 | 실제 요청의 형식과 제약을 지키는가 |
| CoQA, OpenAssistant 등의 대화 자료 | 이어지는 질문과 대화 데이터 | 대화 맥락에서 사용자의 의도를 해결하는가 |
이 자료들은 목적과 구성부터 다르다. 모두 같은 성격의 시험이라고 묶으면 비교가 흐려진다. 서비스 평가에는 실제 문서와 사용자 질문을 대표하는 별도 사례가 필요하다.
3. LLM을 평가자로 쓰는 세 가지 방법
답변을 만드는 모델과 채점하는 모델을 역할로 구분한다. Judge LLM(평가용 LLM)은 답변과 채점 기준을 입력받아 점수나 선호를 반환한다.
| 방식 | 입력과 판단 | 도서관 예제 |
|---|---|---|
| Pairwise Comparison(쌍대 비교) | 같은 질문에 대한 두 답변을 비교 | 기간만 설명한 답변과 연장 조건까지 설명한 답변 비교 |
| Single-answer Grading(단일 답변 채점) | 답변 하나를 정해진 기준으로 채점 | 기간·횟수·조건이 모두 들어갔는지 평가 |
| Reference-guided Grading(참조 기반 채점) | 기준 답변이나 풀이를 함께 제공 | 검토한 규정 설명과 생성 답변을 대조 |
참조 기반 채점은 앞의 두 방식과 조합할 수 있다. 두 답변을 비교할 때도 기준 답변을 제공할 수 있고, 답변 하나의 점수를 매길 때도 같은 기준을 사용할 수 있다.
비교 대상이 n개이고 모든 쌍을 한 번씩 비교하면 n × (n - 1) / 2번의 비교가 필요하다. 대상이 3개면 3쌍, 4개면 6쌍, 5개면 10쌍이다. 비교 횟수는 대략 제곱으로 늘어난다. 실험 목적에 따라 기준 시스템과 각 후보만 비교하는 구성도 가능하다.
LLM 평가자는 많은 답변을 같은 절차로 살펴보는 데 도움이 된다. 그 판단이 사람의 평가와 얼마나 맞는지는 별도로 확인한다. MT-Bench 연구진도 위치·길이·자기 선호와 추론 능력의 한계를 함께 다뤘다. LMSYS의 MT-Bench와 LLM 평가자 설명
4. G-Eval에서 평가 기준을 구체화하는 과정
G-Eval은 평가할 항목을 정의하고, 판단할 단계를 구체화한 뒤, 정해진 형식으로 채점하는 프레임워크다. CoT(단계별 추론)를 활용해 기준과 판단 절차를 연결한다.
관련성을 채점한다면 “좋은 답변인지 평가하라”보다 검사할 대상을 구체적으로 적는다. 이 글의 가상 사례에서는 질문이 요구한 대출 기간과 연장 조건을 확인하고, 답변에서 각각을 찾고, 무관한 내용이 섞였는지 살필 수 있다. 이 절차는 개념을 이해하기 위해 새로 만든 예시다.
원 논문의 과업별 평가 항목은 아래처럼 구분된다.
| 과업 | 항목 | 살펴보는 내용 |
|---|---|---|
| 요약 | Coherence(응집도), Consistency(일관성) | 글의 구성·흐름, 원문에 비춘 사실 관계 |
| 요약 | Fluency(유창성), Relevance(관련성) | 문장 표현, 중요한 정보의 선택 |
| 대화 | Naturalness(자연스러움), Coherence(응집도) | 자연스러운 응답, 대화의 연결 |
| 대화 | Engagingness(참여 유도성), Groundedness(근거성) | 대화를 이어가게 하는 정도, 주어진 지식과의 관계 |
점수 척도는 항목별 기준을 따른다. 모든 지표를 언제나 같은 1~5점으로 채점하는 방식으로 고정해서 이해하지 않는다. 점수 토큰의 확률을 가중 평균에 사용하는 방법도 제안됐다. 연구에서 관찰한 사람 평가와의 상관관계를 모든 과업의 보장으로 확대해서 읽지 않는다. G-Eval 논문
5. 평가자의 편향과 사람이 확인할 부분
Position Bias(위치 편향)는 답변을 보여주는 순서가 판단에 영향을 주는 현상이다. A·B 순서와 B·A 순서로 평가해서 결과가 뒤집히는지 확인할 수 있다. 서로 다른 선택이 나왔다면 평가 규칙에 따라 동점이나 재검토 대상으로 처리한다.
Verbosity Bias(장황함 편향)는 내용의 질과 별개로 긴 답변을 선호하는 경향이다. Self-enhancement Bias(자기고양 편향)는 자기 자신이나 같은 계열이 만든 답변을 선호하는 현상이다. 평가자도 수학·추론 문제를 잘못 판단할 수 있다.
순서를 바꾸고, 기준 답변과 구체적인 채점표를 제공하고, 대표 사례를 사람이 읽는 방법으로 영향을 줄여본다. 이런 조치를 했다는 사실만으로 편향이 사라졌다고 보기는 어렵다. 모델·프롬프트·데이터를 바꿨다면 평가자의 판단도 다시 살펴본다. LLM 평가자의 한계와 완화 방법
temperature=0은 무작위성을 줄이는 설정이다. 점수가 매번 완전히 같다는 보장으로 해석하지 않는다. 작은 차이로 개선을 주장하려면 여러 질문에서 같은 경향이 나타나는지, 사람이 읽어도 차이를 설명할 수 있는지 확인한다.
6. 데이터 준비부터 답변 생성까지 남는 문제
| 단계 | 생길 수 있는 문제 | 확인할 자료 |
|---|---|---|
| 원자료 수집 | 오래되거나 적용 대상이 다른 규정 | 문서 날짜와 출처, 적용 범위 |
| 정보 추출·OCR(광학 문자 인식) | 표의 행·열 혼합, 숫자·부정 표현 오인식 | 추출 텍스트와 원문 |
| Chunking(청킹) | 기간과 조건이 서로 다른 조각으로 분리 | 청크 경계와 제목 |
| Embedding(임베딩) | 도메인 용어와 다른 표현을 잘 연결하지 못함 | 질문·문서 표현과 검색 결과 |
| 질문 처리·검색 | 모호한 질문, 필요한 청크 누락 | 실제 질문과 검색 순위 |
| 문맥 전달 | 길이 제한에 따른 절단, 중복, 순서 변경 | 답변 모델에 실제 전달한 문맥 |
| 답변 생성 | 조건 누락, 근거 없는 숫자 추가 | 최종 답변과 근거 문서 |
평가 데이터의 문맥은 답변 모델이 실제로 받은 자료와 맞춘다. 검색 후보 20개 중 3개만 모델에 전달했다면, 후보 목록과 전달 목록을 구분해 기록하는 편이 좋다. 전달하지 않은 문서를 평가에 섞으면 생성 답변의 근거를 잘못 해석할 수 있다.
자료 자체가 틀리면 그 자료를 충실히 따라 쓴 답변도 실제 안내로는 틀릴 수 있다. 그래서 문서 품질과 RAG 지표를 함께 본다.
7. 평가 데이터 한 행에 들어가는 네 가지 자료
| 열 | 내용 | 자료형 |
|---|---|---|
user_input |
사용자 질문 | 문자열 |
response |
생성 모델이 만든 답변 | 문자열 |
retrieved_contexts |
답변에 사용한 검색 문맥 | 문자열의 리스트 |
reference |
검토한 기준 답변 | 문자열 |
Reference(기준 답변)는 Ground Truth(정답 기준)라고 부르기도 한다. 사람이 작성하거나 모델이 초안을 만들 수 있지만, 문서와 질문에 맞는지 검토해야 한다.
질문과 문맥의 관계는 검색의 관련성을, 문맥과 답변의 관계는 근거성을, 질문과 답변의 관계는 답변 관련성을 보여준다. TruLens는 이 세 관계를 RAG Triad(래그 평가의 세 축)로 설명한다. RAGAS 지표를 이해할 때도 도움이 되는 관점이며, 지표마다 계산법을 확인한다. TruLens RAG Triad
8. Faithfulness는 생성 답변의 주장을 검사한다
Faithfulness(충실성)는 답변의 주장이 제공된 문맥으로 뒷받침되는 정도다. 답변을 주장으로 나누고, 각 주장이 문맥에서 도출되는지 확인한다. 문맥과 똑같은 문장을 써야 한다는 뜻은 아니다. RAGAS Faithfulness
충실성 = 문맥이 지지하는 생성 답변의 주장 수 / 생성 답변의 전체 주장 수
문맥에 “대출은 14일”만 있고 답변이 “대출은 14일이며 연장 비용은 무료”라고 하자. 설명을 위해 사람이 두 주장으로 나누면 기간에는 근거가 있고 비용에는 근거가 없다. 수작업 라벨에 따른 계산은 1 / 2 = 0.5다.
실제 LLM 평가는 주장을 어떻게 나누는지와 지지 여부를 어떻게 판단하는지에 따라 값이 달라질 수 있다. 이 손계산을 그대로 RAGAS의 확정 출력으로 기대하지 않는다.
무료라는 내용이 실제 규정과 맞더라도 지금 제공한 문맥에서 확인되지 않을 수 있다. 반대로 오래된 문서의 잘못된 숫자를 충실히 옮기면 충실성은 높을 수 있다. 현실의 사실 관계와 제공 문맥에 대한 충실성은 확인 대상이 다르다.
9. Answer Relevancy는 질문의 의도를 확인한다
Answer Relevancy(답변 관련성)는 답변이 원래 질문을 얼마나 잘 다루는지 살펴본다. 예제 방식은 답변에서 가상의 질문을 만들고, 원래 질문과 생성한 질문 사이의 임베딩 코사인 유사도를 평균한다. 사실의 정확성을 직접 채점하는 지표와는 구분해서 읽는다. RAGAS Response Relevancy
생성 답변 → 가능한 질문들을 역으로 생성
원래 질문과 생성 질문들을 같은 임베딩 모델로 벡터화
→ 질문 사이의 코사인 유사도를 평균
“책은 14일 빌릴 수 있다”는 답변에서 “대출 기간은 얼마인가요?”라는 질문을 만들 수 있다. 원래 질문이 연장 조건까지 요구했다면 답변이 질문의 전체 범위를 충분히 담았는지 살펴볼 여지가 생긴다.
여기에는 두 종류의 모델이 쓰인다. 평가용 LLM은 질문을 만들고, 임베딩 모델은 질문 사이의 의미 유사도를 계산한다. answer_relevancy=0.6을 정답률 60%라고 읽으면 계산의 의미가 달라진다.
10. Context Precision은 유용한 청크의 순위를 반영한다
Context Precision(문맥 정밀도)은 유용한 청크가 검색 결과 앞쪽에 놓였는지 살핀다. 여기서 다루는 순위 기반 계산은 유용한 청크가 나온 위치의 Precision@k(상위 k개 정밀도)를 평균한다. RAGAS Context Precision
관련성이 [1, 0, 1]이라고 사람이 표시한 결과를 생각해보자. 첫째와 셋째 청크가 유용하다는 뜻이다.
| 관련성 순서 | 유용한 청크 위치의 정밀도 | 평균 |
|---|---|---|
[1, 0, 1] |
1위에서 1/1, 3위에서 2/3 |
약 0.8333 |
[0, 1, 1] |
2위에서 1/2, 3위에서 2/3 |
약 0.5833 |
[1, 1, 0] |
1위에서 1/1, 2위에서 2/2 |
1.0000 |
세 경우 모두 유용한 자료는 두 개다. 위치가 달라져 점수가 달라진다. 마지막 경우처럼 무관한 자료가 뒤에 있어도 이 계산은 1이 될 수 있으므로, 만점이라는 이유만으로 검색 결과에 잡음이 전혀 없다고 해석하지 않는다.
분모는 검색된 상위 결과 안의 유용한 청크 수다. 저장소 전체에서 필요한 자료를 얼마나 놓쳤는지는 재현율 관점에서 따로 확인한다.
참조 기반 방식은 기준 답변과 청크를 비교한다. 생성 답변을 비교 대상으로 사용하는 참조 없는 방식도 있으므로, “문맥 정밀도에는 항상 사람이 쓴 정답이 필수”라고 일반화하지 않는다. 사용한 클래스와 입력에 따라 점수의 의미를 읽는다. 참조 유무에 따른 문맥 정밀도 방식
11. Context Recall은 기준 답변에 필요한 근거를 검사한다
Context Recall(문맥 재현율)의 LLM 기반 방식은 기준 답변을 주장으로 나누고, 각 주장을 검색 문맥으로 뒷받침할 수 있는지 확인한다. RAGAS Context Recall
문맥 재현율 = 문맥이 지지하는 기준 답변의 주장 수 / 기준 답변의 전체 주장 수
설명을 위해 기준 답변을 “14일 대출”과 “예약자가 없으면 한 번 7일 연장”이라는 두 검사 단위로 나눈다. 첫 내용만 검색했다면 수작업 라벨에 따른 계산은 1 / 2 = 0.5다. 실제 LLM이 더 세밀하게 주장을 나누면 분모도 달라질 수 있다.
| 상황 | 충실성 관점 | 문맥 재현율 관점 |
|---|---|---|
| 기간만 검색하고 기간만 답함 | 말한 내용은 모두 지지될 수 있음 | 기준 답변에 필요한 연장 근거가 빠짐 |
| 필요한 규정을 모두 검색했지만 무료라는 말을 추가함 | 추가 주장에 근거가 부족함 | 기준 답변의 근거는 모두 있을 수 있음 |
| 오래된 규정을 검색하고 그대로 답함 | 문맥에 충실할 수 있음 | 최신 기준 답변과는 어긋날 수 있음 |
검색 개수를 늘리거나 질문을 확장하면 필요한 근거를 더 찾을 가능성이 생긴다. 무관한 문서도 늘 수 있으므로 같은 질문으로 정밀도와 재현율을 함께 측정한다. 개선 기법을 적용했다는 사실 자체가 점수 상승의 증거는 아니다.
12. RAGAS 예제의 코드 흐름 읽기
첨부 실습은 RAGAS 0.4.*와 LangChain 0.3.* 계열을 지정하고, 기존 evaluate()·ragas.metrics API를 사용한다. 현재 공식 문서는 새 사용 방식과 마이그레이션을 안내한다. 아래 코드는 첨부 실습의 입력 구조와 호출 흐름을 설명하는 버전 의존 예시다. 이번 글 작성에서는 유료 평가 호출을 실행하지 않았으며, 설치·실행 호환성을 새로 확인한 코드는 아니다. RAGAS 0.4 마이그레이션 안내
먼저 평가할 데이터를 만든다. 아래 문장은 공개 글을 위해 새로 쓴 가상 규정이다.
data = {
"user_input": ["책은 며칠 빌릴 수 있고, 연장 조건은 무엇인가요?"],
"response": [
"14일 빌릴 수 있고, 예약자가 없으면 한 번 7일 연장할 수 있습니다."
],
"retrieved_contexts": [[
"기본 대출 기간은 14일이다.",
"예약자가 없으면 한 번에 한해 7일 연장할 수 있다.",
]],
"reference": [
"대출 기간은 14일이며, 예약자가 없을 때 한 번 7일 연장할 수 있다."
],
}
from datasets import Dataset
dataset = Dataset.from_dict(data)
바깥 리스트는 평가 행을 나타낸다. retrieved_contexts는 질문마다 여러 문자열을 가질 수 있어 리스트가 한 겹 더 들어간다. 네 열의 같은 위치가 같은 질문에 대응해야 한다.
파이썬에서 쉼표 없이 나란히 적은 문자열 리터럴은 하나로 이어진다. [["문장 A" "문장 B"]]에는 청크가 하나이고, [["문장 A", "문장 B"]]에는 두 개다. 여러 줄에 적혀 있다는 화면상의 모양보다 실제 리스트 항목 수를 확인한다.
이 코드의 response는 이미 준비된 문자열이다. 데이터셋으로 변환하는 단계에서 검색이나 답변 생성이 새로 실행되는 것은 아니다. 실제 RAG에 연결할 때는 시스템이 검색한 문맥과 생성한 답변을 각 행에 저장한다.
import os
from getpass import getpass
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from ragas import evaluate
from ragas.metrics import (
faithfulness, answer_relevancy, context_precision, context_recall,
)
os.environ["OPENAI_API_KEY"] = getpass("OpenAI API 키: ")
evaluator_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
evaluator_embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
# 실행하면 외부 API에 평가 데이터가 전달되고 사용 요금이 발생할 수 있다.
result = evaluate(
dataset=dataset,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
llm=evaluator_llm,
embeddings=evaluator_embeddings,
raise_exceptions=False,
)
df = result.to_pandas()
evaluator_llm은 주장 추출과 판정, 가상 질문 생성 등에 쓰인다. evaluator_embeddings는 답변 관련성에서 질문을 벡터로 비교하는 데 쓰인다. 모델을 지정해두면 평가 조건을 기록하기 쉽다. 임베딩을 생략했을 때의 동작은 버전과 설정에 따라 확인한다.
getpass는 입력을 가려준다. 키를 다른 셀에서 출력하거나 파일에 저장하지 않도록 하고, 공유 전에는 출력도 확인한다. Colab에서는 시크릿에 저장한 값을 읽어올 수 있다.
raise_exceptions=False는 일부 오류가 나도 평가를 계속하도록 하는 설정이다. 완료된 결과에 NaN(계산되지 않은 값)이 섞일 수 있으므로 성공 건수와 오류를 함께 확인한다. NaN을 품질 점수 0으로 치환해서 평균 내면 해석이 달라진다.
설치 중 의존성 충돌과 사용 중단 예정 경고도 구분한다. 경고 색상만으로 무시할지를 정하기보다 어떤 패키지와 기능에 영향을 주는지 읽는다. 노트북에서 이미 불러온 라이브러리를 다른 버전으로 설치했다면 런타임 재시작이 필요할 수 있다.
13. 저장된 점수와 예상한 점수가 다른 경우
첨부 실습의 첫 예제는 PER을 설명하는 질문이다. 저장된 출력에는 문맥 정밀도와 재현율이 각각 1, 충실성이 0.8, 답변 관련성이 약 0.6075로 남아 있다. 파일에 저장된 관찰이며 이 글에서 새로 실행한 측정값은 아니다.
두 번째 예제는 필요한 문맥을 넣은 파리 질문과, 구체적인 설명 근거를 일부러 부족하게 구성한 블랙홀 질문을 비교한다. 저장 출력의 일부를 읽으면 단순히 좋은 예제는 모두 만점이라고 기대하기 어렵다.
| 저장된 예제 | 충실성 | 문맥 정밀도 | 문맥 재현율 |
|---|---|---|---|
| 파리와 미술관 | 0.5 | 0.5 | 1.0 |
| 블랙홀의 사건의 지평선 | 약 0.6667 | 1.0 | 0.0 |
이 숫자만으로 원인을 확정할 수는 없다. 생성 답변의 주장 분해, 각 문맥의 유용성 판정, 기준 답변의 지원 여부를 확인해야 한다. 저장 로그에는 요청한 생성 개수보다 적은 결과로 진행했다는 경고도 남아 있어 평가 조건을 살필 단서가 된다.
현실에서 참인 내용도 제공된 문맥에 근거가 부족할 수 있다. 또 정밀도와 재현율은 다른 기준을 사용한다. 기대와 다른 행을 만나면 입력 문장과 지표 정의, 중간 판정을 연결해서 읽는다.
14. 모델 호출 없이 계산 구조를 연습하기
아래 코드는 사람이 미리 정한 관련성·주장 지지 라벨로 산술 계산만 한다. 라벨을 자동으로 판단하는 RAGAS 실행 결과와 구분한다. 빈 라벨은 검사할 대상이 없으므로 None으로 두고, 청크가 있어도 유용한 것이 하나도 없는 경우의 정밀도는 0으로 계산한다.
def ranked_precision(labels):
if not labels:
return None
relevant = sum(labels)
if relevant == 0:
return 0.0
hits = 0
total = 0.0
for rank, useful in enumerate(labels, start=1):
hits += useful
if useful:
total += hits / rank
return total / relevant
def supported_fraction(labels):
return sum(labels) / len(labels) if labels else None
for order in ([1, 0, 1], [0, 1, 1], [1, 1, 0]):
print(f"{order}: {ranked_precision(order):.4f}")
print("faithfulness:", supported_fraction([1, 0]))
print("context_recall:", supported_fraction([1, 1]))
[1, 0, 1]: 0.8333
[0, 1, 1]: 0.5833
[1, 1, 0]: 1.0000
faithfulness: 0.5
context_recall: 1.0
위 출력은 Python 표준 라이브러리 환경에서 직접 확인했다. 답변 관련성에 필요한 질문 생성과 임베딩 계산은 이 예제에 포함하지 않았다. 손계산 예제 내려받기
15. 개선 전후의 평가와 테스트셋 생성
청크 크기나 검색 방식을 바꿀 때는 기준 시스템과 같은 질문으로 비교한다. 문서 버전, 기준 답변, 평가 모델과 프롬프트를 맞추고, 질문별 검색 문맥과 생성 답변을 저장한다. 평균을 비교한 뒤 좋아진 행과 나빠진 행을 읽어 원인을 찾는다.
질문이 적거나 서로 비슷하면 평균이 실제 사용 범위를 충분히 대표하기 어렵다. 용어 설명, 숫자와 조건 확인, 여러 근거 결합, 문서로 답할 수 없는 질문을 구분해 구성할 수 있다. 개발 중 반복해서 본 질문과 최종 확인용 질문도 가능하면 나누어둔다.
지표 평균이 0.6에서 0.7로 바뀌었다면 차이는 0.1점이다. 퍼센트 척도로 표현하면 10퍼센트포인트이고 상대 증가율은 약 16.7%다. 이를 그대로 답변 정확도가 그만큼 상승했다고 바꾸어 부르지 않는다. 응답 시간, 입력 길이, 평가 비용도 함께 기록하면 실제 선택에 도움이 된다.
기준 답변이 부족할 때는 Testset Generation(평가 데이터셋 생성)으로 문서에서 예상 질문과 기준 답변의 초안을 만들 수 있다. 질문이 문서로 답할 수 있는지, 답변에 근거가 있는지, 실제 사용자 질문과 닮았는지 사람이 검토한다. 자동 생성이라는 이유로 정답의 정확성이나 질문의 다양성이 보장되지는 않는다. RAGAS Testset Generation
질문 생성과 답변 생성, 평가를 같은 모델에 맡기면 그 모델에 익숙한 표현이 반복될 수 있다. 사람이 쓴 질문이나 실제 사용 사례를 함께 살펴보고, 평가 세트에 버전을 남긴다. 다른 평가 세트에서 얻은 점수끼리 비교할 때는 조건의 차이를 먼저 확인한다.
프라이빗 RAG에서도 평가 단계의 데이터 이동을 확인한다. 검색과 생성이 내부에서 이루어져도 외부 평가자에게 질문·문맥·답변을 보내면 그 부분은 외부 처리다. 테스트셋 생성 역시 사용하는 모델과 전달 문서의 범위에 포함한다.
16. 네 지표를 한 행에서 다시 읽기
충실성은 생성 답변의 주장을, 문맥 재현율은 기준 답변의 주장을 문맥과 대조한다. 문맥 정밀도는 유용한 청크의 순위를, 답변 관련성은 질문과 답변의 관계를 살핀다.
평가 결과 옆에 질문과 검색 문맥, 답변을 놓고 읽으면 점수가 가리키는 문제를 찾기 쉬워진다. 계산에 실패한 행을 따로 확인하고, 바꾼 조건을 기록하고, 대표 사례를 사람이 읽는 과정까지 평가에 포함한다.
이 글에서 실행한 코드는 수작업 라벨의 비율과 순위 계산 예제다. RAGAS 평가·임베딩 API와 자동 테스트셋 생성은 실행하지 않았다. 개념 설명에는 개인 학습 자료를 참고했으며, 공개 예제와 해설은 새로 작성했다. 주요 동작과 보완 설명의 근거는 각 절의 공식 문서와 논문 링크에 연결했다.