RAG 평가셋과 지표 설계: 검색과 답변을 분리해 측정하는 법

30초 답변

RAG를 최종 답변 점수 하나로 평가하면 실패 원인을 알 수 없다. 먼저 retriever가 정답 문서·청크를 상위 후보에 넣었는지 평가하고, 그다음 고정된 근거를 받은 생성 모델이 정확하고 근거 있게 답했는지 평가해야 한다. 평가셋에는 답이 있는 질문뿐 아니라 말뭉치에 답이 없는 질문, 권한상 답을 볼 수 없는 질문, 최신 문서와 폐기 문서가 충돌하는 질문을 반드시 넣는다.

최소 평가 단위는 다음과 같다.

질문 + 말뭉치 스냅샷 + 사용자 권한 + 정답 문서 라벨 + 기대 답변/필수 사실 + 답변 가능 여부 + 검색·모델·프롬프트 버전

이 글의 핵심

• retrieval과 answer generation을 분리해야 검색 실패와 생성 실패를 구별할 수 있다.
• 평가셋은 실제 사용자 질문 분포를 중심으로 만들고, 합성 질문은 빈 구간을 보완하는 용도로 사용한다.
• Recall@k·MRR·nDCG는 검색을, correctness·groundedness·completeness·citation은 답변을 본다.
• no-answer는 예외가 아니라 독립 품질 항목이다. 근거가 없을 때 추측하지 않고 적절히 보류하는지 측정한다.
• LLM judge는 확장 수단이지 정답 원천이 아니다. 사람 라벨과의 일치도를 먼저 확인한다.

왜 최종 답변 점수 하나로는 부족한가

RAG에는 적어도 두 개의 서로 다른 시스템이 있다.

1. 질문에 필요한 문서를 찾는 검색 시스템
2. 검색된 근거를 읽고 답을 구성하는 생성 시스템

다음 두 실패는 사용자에게는 모두 “오답”으로 보이지만 수정 지점이 다르다.

• 정답 문서가 검색되지 않아 모델이 관련 없는 근거로 답했다.
• 정답 문서는 검색됐지만 모델이 예외 조항을 누락하거나 숫자를 잘못 옮겼다.

반대 사례도 있다. 검색이 틀렸는데 모델의 사전 지식으로 우연히 맞는 답을 만들 수 있다. 이 답은 말뭉치가 바뀌면 재현되지 않고 출처도 검증할 수 없다. 따라서 최종 정답률만 보면 취약한 검색기를 좋은 시스템으로 오판할 수 있다.

Microsoft의 RAG 평가기 문서는 정답 문서 라벨을 이용하는 document retrieval 평가를 process evaluation으로, groundedness·relevance·completeness 같은 최종 응답 평가를 system evaluation으로 구분한다. 도구를 사용하지 않더라도 이 분리는 평가 설계의 출발점이 된다.

평가셋의 기본 스키마

질문 문자열과 모범 답안만 저장하면 검색 실험을 재현하기 어렵다. 권장 필드는 다음과 같다.

{
  "case_id": "hr-leave-014",
  "query": "배우자 출산휴가는 며칠까지 쓸 수 있나요?",
  "query_type": "policy_fact",
  "language_variant": "colloquial_ko",
  "answerability": "answerable",
  "user_context": {"tenant_id": "corp-a", "groups": ["all-employees"]},
  "corpus_snapshot": "policy-index-2026-07-15",
  "retrieval_ground_truth": [
    {"document_id": "leave-policy-v5", "chunk_id": "section-4-2", "grade": 3},
    {"document_id": "benefit-faq-v2", "chunk_id": "q-18", "grade": 1}
  ],
  "reference_answer": "...",
  "required_facts": ["기간", "신청 기한", "예외 조건"],
  "forbidden_claims": ["폐기된 v4 기준"],
  "source_citations": ["leave-policy-v5#section-4-2"],
  "review": {"reviewer_role": "HR policy owner", "reviewed_at": "2026-07-16"}
}

grade는 완전한 정답 근거, 보조 근거, 관련 없음처럼 관련도를 단계화할 때 사용한다. 모든 질문에 세밀한 등급을 붙일 여력이 없다면 우선 relevant/not relevant 이진 라벨로 시작할 수 있다. 중요한 것은 라벨 기준을 문서로 남겨 검수자마다 판단이 달라지지 않게 하는 것이다.

평가셋이 가리키는 말뭉치 스냅샷을 고정한다. 정답 문서가 업데이트되거나 삭제됐는데 옛 라벨로 새 인덱스를 평가하면 검색기 문제가 아닌 데이터 변경을 회귀로 오판한다.

평가 질문은 어디서 수집할까

1. 실제 사용자 로그를 중심으로 시작한다

실제 질문은 약어, 생략, 오탈자, 여러 의도가 섞인 표현을 포함한다. 개인정보·기밀을 비식별화하고, 검색 실패·낮은 만족도·상담원 전환 사례를 우선 검토한다. 동일 질문이 자주 반복되면 운영 분포에 맞게 가중치를 둘 수 있지만, 빈도가 낮아도 위험이 큰 보안·법무 질문은 별도 핵심 슬라이스로 유지한다.

2. 도메인 전문가가 정답 근거를 라벨링한다

질문 작성자와 정답 검수자가 같을 필요는 없다. 현업 전문가는 모범 문장보다 “반드시 포함할 사실”, “허용 가능한 표현”, “사용하면 안 되는 폐기 근거”를 표시하는 데 집중하면 유지보수가 쉽다. 의견이 갈리는 질문은 정답을 억지로 하나로 만들지 말고 ambiguous로 표시해 재질문 동작을 평가한다.

3. 합성 데이터는 빠진 유형을 보완한다

문서에서 모델로 질문을 생성하면 규모를 늘릴 수 있지만, 문서 표현을 그대로 복사한 쉬운 질문에 치우치기 쉽다. 구어체, 부정형, 여러 조건, 한영 혼용, 오탈자, 모호한 대명사 변형을 만들고 사람이 표본 검수한다. 합성 질문만으로 운영 품질을 대표하지 않는다.

OpenAI의 평가 모범 사례는 실제 분포를 반영하는 task-specific eval, 개발 단계별 평가, 로그 축적, 자동 평가와 사람 판단의 보정을 권장하며 typical·edge·adversarial 사례를 함께 포함하라고 안내한다.

4. 데이터 누수를 막아 분할한다

같은 규정 문서에서 표현만 바꾼 질문을 train·tuning·test에 나눠 넣으면 과도하게 좋은 점수가 나올 수 있다. 가능하면 원본 문서, 부서, 시기 단위로 분할하고, 최종 승인용 holdout은 튜닝 과정에서 보지 않는다. 운영 중 발견된 새 실패는 회귀셋에 추가하되 기존 점수를 소급 비교할 때 평가셋 버전을 명시한다.

retrieval 평가: 정답 후보를 찾았는가

검색기는 동일한 질문, 동일한 말뭉치와 권한 조건에서 비교한다. 모델 생성 없이 문서 ID와 순위만 저장하면 빠르고 재현 가능한 파라미터 비교가 가능하다.

Recall@k는 “top-k 안에 정답이 하나라도 있음”과 다르다. 한 질문에 필수 근거가 세 개라면 그중 하나만 찾고도 성공으로 처리하지 않도록 문서 단위 recall과 질문 성공 규칙을 함께 정의한다. 표의 헤더와 본문 값처럼 두 청크가 동시에 필요한 질문은 required evidence set을 별도로 둔다.

검색 평가 로그에는 질의 원문, 재작성 질의, 필터, 각 검색 경로의 순위와 점수, 융합 순위, 리랭킹 점수, 인덱스 버전을 저장한다. 그래야 Recall이 떨어졌을 때 ACL, 필터, 임베딩, 리랭커 중 어느 단계가 정답을 제거했는지 알 수 있다.

answer 평가: 찾은 근거를 올바르게 사용했는가

생성 모델을 평가할 때는 두 가지 세트를 분리한다.

Oracle-context 평가

사람이 확정한 정답 근거를 모델에 직접 제공한다. 이 평가가 낮으면 검색기가 아니라 프롬프트, 모델, 컨텍스트 구성, 출력 후처리 문제다.

End-to-end 평가

실제 retriever 결과를 모델에 제공한다. 이 결과와 oracle-context 결과의 차이는 검색 단계가 전체 품질에 미치는 영향을 보여준다.

답변 지표는 다음처럼 정의할 수 있다.

• Correctness: 기준 답과 사실적으로 일치하는가?
• Groundedness: 답변의 각 주장이 제공된 근거로 뒷받침되는가?
• Completeness: required_facts를 빠뜨리지 않았는가?
• Relevance: 질문에 필요한 내용에 집중하는가?
• Citation correctness: 인용한 문서·구간이 실제 주장을 지지하는가?
• Instruction compliance: 답변 형식, 보류 규칙, 민감정보 제한을 지키는가?

이 지표들은 하나로 평균 내기 전에 각각 본다. 짧고 근거 있는 답은 completeness가 낮을 수 있고, 긴 답은 필수 사실을 담았지만 근거 없는 부연이 많을 수 있다. 서비스 위험에 따라 groundedness 또는 권한 준수를 배포 차단 조건으로 둘 수 있다.

no-answer 테스트: 모르는 것을 모른다고 말하는가

답이 없는 질문을 단순히 랜덤한 외부 상식 질문으로 만들면 실무 보류 능력을 충분히 검증하지 못한다. 최소 다섯 유형을 포함한다.

1. 말뭉치 부재: 질문 주제와 비슷한 문서는 있지만 요청한 사실은 없다.
2. 권한 부재: 정답 문서는 존재하지만 테스트 사용자는 접근할 수 없다.
3. 시간 부재: 최신 규정이 아직 반영되지 않아 특정 기준일 답을 확정할 수 없다.
4. 모호성: 제품명·대상자·기간이 없어 여러 답이 가능하다.
5. 충돌: 유효한 두 문서가 서로 다르며 우선순위를 결정할 메타데이터가 없다.

기대 동작도 유형별로 다르다. 말뭉치 부재에서는 근거가 없다고 알리고, 모호성에서는 필요한 정보를 재질문하며, 권한 부재에서는 비공개 문서의 존재나 제목을 누설하지 않은 채 접근 가능한 자료에서 답을 찾지 못했다고 안내한다. 충돌에서는 임의로 하나를 선택하지 않고 문서 날짜·상태를 제시하거나 담당자 확인을 요청한다.

no-answer 지표는 다음 두 오류를 모두 본다.

• 거짓 답변(false answer): 답할 수 없는데 답을 만들어 냄
• 과도한 거부(false refusal): 충분한 근거가 있는데 답변을 보류함

한쪽만 줄이면 다른 쪽이 늘 수 있으므로 업무 위험에 맞게 균형을 정한다. 법무·안전처럼 잘못된 답의 비용이 큰 분야와 일반 FAQ는 같은 기준을 쓸 필요가 없다.

자동 평가와 사람 평가를 조합한다

문서 ID 일치, 숫자·날짜, JSON 스키마, 인용 ID 존재 여부는 코드 기반 평가가 우선이다. 의미적 정답성이나 설명 품질은 규칙만으로 판단하기 어려워 사람 평가 또는 LLM judge를 보조적으로 사용할 수 있다.

LLM judge에는 질문, 근거, 기준 답, 명확한 루브릭을 제공하고 pass/fail 또는 쌍대 비교를 우선 검토한다. 답변 순서를 바꾼 반복 평가로 위치 편향을 확인하고, 긴 답을 선호하는 편향도 감시한다. OpenAI의 공식 가이드도 모델 평가자를 사람 라벨과 먼저 비교해 일치도를 검증하고, position bias와 verbosity bias를 주의하라고 설명한다.

사람 검수는 무작위·블라인드 비교가 좋다. 검색 구성이나 모델 이름을 숨기고, 의견 불일치가 큰 항목은 루브릭 예시를 보강한다. 자동 평가 점수의 상승이 현업 만족도 상승과 연결되는지 정기적으로 재검증한다.

배포 게이트와 지속 평가

전체 평균 하나만 배포 기준으로 사용하면 빈도가 높은 쉬운 FAQ가 위험한 실패를 가린다. 질문 유형, 부서, 언어 변형, 문서 형식, answerability, 권한 수준별로 슬라이스를 나눈다. 각 슬라이스에 최소 표본과 실패 허용 기준을 정하되, 임의의 업계 숫자를 복사하지 말고 현재 베이스라인과 업무 위험에서 출발한다.

변경마다 다음 정보를 결과와 묶는다.

• 말뭉치·인덱스 버전
• 파서·청킹·임베딩 버전
• 검색 방식, 필터, top-k, 리랭커 버전
• 프롬프트·모델·생성 파라미터
• 평가셋·루브릭·judge 버전
• 품질 지표, P50/P95 지연, 질의당 비용

NIST AI Risk Management Framework는 AI 제품과 시스템의 설계·개발·사용·평가 전반에 신뢰성 고려를 통합하는 자발적 프레임워크다. RAG에서도 평가는 출시 직전 점검표가 아니라 변경을 추적하고 위험을 측정하는 지속 운영 절차로 두는 편이 적합하다.

사용자 경험과 실패 시나리오

“데모 질문은 다 맞는데 실제 사용자는 만족하지 않습니다”

평가 질문이 문서 제목을 그대로 사용하거나 개발자가 예상한 완전한 문장만 포함했을 수 있다. 실제 로그의 짧은 질문, 오탈자, 부서 약어, 후속 질문을 별도 슬라이스로 추가한다. 만족도 버튼만 보지 말고 사용자가 원문을 다시 검색했는지, 질문을 반복했는지 같은 행동 신호도 검토한다.

“Recall은 올랐는데 답변 품질은 떨어졌습니다”

후보를 늘리면서 관련 없는 청크가 컨텍스트에 섞였을 수 있다. retrieval Recall과 Precision, 컨텍스트 중복, answer groundedness를 함께 본다. 검색 후보 수와 LLM 전달 근거 수를 분리해 리랭킹·중복 제거 효과를 실험한다.

“LLM judge 점수는 높은데 전문가가 틀렸다고 합니다”

judge가 도메인 예외를 모르거나 긴 답을 선호했을 수 있다. 불일치 항목을 모아 루브릭과 기준 근거를 수정하고, judge 버전별 사람 일치도를 기록한다. 전문가 판단을 단순 노이즈로 제거하지 않는다.

“문서를 업데이트하자 회귀 테스트가 대량 실패했습니다”

시스템이 나빠진 것이 아니라 정답 라벨이 옛 버전을 가리킬 수 있다. 말뭉치 스냅샷과 qrels의 유효기간을 확인하고, 새 문서 소유자가 정답 근거를 승인한 후 새 평가셋 버전을 만든다. 과거 결과와 비교할 때는 같은 스냅샷에서 재실행한다.

실무 체크리스트

• retrieval과 answer generation 평가를 별도 실행하는가?
• 각 사례에 말뭉치 스냅샷과 사용자 권한이 고정되어 있는가?
• 정답 문서·청크 라벨과 관련도 기준이 있는가?
• 실제 로그, 전문가 질문, 합성 edge case를 구분해 관리하는가?
• 문서 단위 분할로 평가 데이터 누수를 줄였는가?
• Recall@k, MRR 또는 nDCG와 검색 실패율을 함께 보는가?
• oracle-context와 end-to-end 답변 결과를 비교하는가?
• correctness, groundedness, completeness, citation을 분리 측정하는가?
• 말뭉치 부재·권한 부재·모호성·충돌 no-answer 사례가 있는가?
• 거짓 답변과 과도한 거부를 모두 측정하는가?
• 코드 기반 평가를 가능한 항목에 우선 사용하는가?
• LLM judge를 사람 라벨로 보정하고 버전을 기록하는가?
• 전체 평균 외에 질문 유형·부서·권한별 회귀 기준이 있는가?
• 품질, 지연, 비용을 동일 실행에서 기록하는가?
• 운영 실패 사례가 평가셋으로 돌아오는 담당·절차가 있는가?

자주 묻는 질문

Q1. RAG 평가셋은 몇 개면 충분한가요?

보편적인 정답은 없다. 질문 유형과 위험 슬라이스가 실제로 포함되는지가 단순 개수보다 중요하다. 작은 핵심 회귀셋으로 자주 실행하고, 더 큰 대표 셋으로 정기 검증하는 이중 구조가 실용적이다. 새 실패가 발견될 때 사례를 추가하되 중복 질문만 늘어나지 않게 분포를 관리한다.

Q2. 모범 답변이 없으면 평가할 수 없나요?

검색 평가는 정답 문서 라벨만으로도 가능하다. 답변도 완성 문장 대신 required facts, 금지 주장, 인용 근거, pass/fail 루브릭으로 평가할 수 있다. 모범 문장 하나와 표현이 다르다는 이유로 좋은 답을 오답 처리하지 않는 장점이 있다.

Q3. 사용자 만족도만 보면 안 되나요?

만족도는 중요하지만 친절한 오답도 높은 평가를 받을 수 있고 응답 속도나 UI의 영향을 함께 받는다. 만족도는 correctness·groundedness·검색 지표와 결합해 본다. 낮은 만족 사례는 평가셋 후보로 활용하되 버튼을 누르지 않은 다수 사용자의 행동도 함께 분석한다.

근거 자료

• Microsoft Learn, 생성형 AI용 RAG 평가기
• Microsoft Learn, RAG 솔루션의 LLM 평가 단계
• OpenAI Developers, Evaluation best practices
• OpenAI Developers, Working with evals
• NIST, AI Risk Management Framework
• NIST, AI Resource Center와 TEVV 자료