콘텐츠로 이동

P7-10.1 RAG 평가 도구로 검색과 생성을 나누어 점검하기

Section ID: P7-10.1 Version: v2026.07.31

P7-9에서는 문서 조각, 질문, 검색 후보, 답변 가능 상태를 직접 기록했습니다. 하지만 프로젝트가 조금만 커져도 사람이 표를 읽어 모든 실패를 분류하기 어렵습니다. 이때 필요한 다음 단계는 답변이 마음에 드는가를 묻는 것이 아니라, 검색(retrieval)과 생성(generation)을 나누어 평가하는 것입니다.

이 절은 RAGAS, DeepEval 같은 평가 도구를 도구 사용법으로 소개하는 자리가 아닙니다. Part 7의 흐름에서는 평가 도구를 검색 후보가 충분했는가, 답변이 근거에 묶여 있는가, 좋은 검색인데 나쁜 답변인지, 나쁜 검색이라 답변이 흔들린 것인지를 분리하는 기록 장치로 봅니다.

RAG 평가를 처음 붙일 때 흔히 하는 실수는 하나의 종합 점수로 시스템 전체를 판단하는 것입니다. 하지만 RAG는 적어도 질문, 검색, 문맥 선택, 답변 생성, 답변 검토가 이어진 파이프라인입니다. 마지막 답변이 틀렸더라도 검색이 틀렸는지, 검색은 맞았지만 답변이 근거를 벗어났는지, 질문 자체가 평가셋 안에서 모호했는지를 나누어야 다음 수정이 생깁니다.

평가가 나누어야 할 실패

RAG 평가에서 먼저 나누어야 할 실패는 다음 네 가지입니다.

실패 구분 확인할 질문 다음 조치
검색 누락 정답 근거 문서가 후보 안에 들어왔는가? chunk, embedding, top-k, metadata filter를 다시 본다
검색 순위 문제 관련 문서가 너무 아래에 밀렸는가? ranking 기준과 후보 수를 조정한다
근거 불충실 답변이 검색 문맥에 없는 말을 했는가? prompt, 답변 제한, faithfulness 평가를 확인한다
답변 관련성 부족 근거는 있으나 질문에 답하지 못했는가? 질문 재작성, 답변 형식, 평가셋을 보강한다

P7-9.5가 검색 결과와 답변 가능 상태의 mismatch를 사람이 읽는 실습이었다면, P7-10.1은 같은 기록을 평가 지표와 테스트 케이스 형태로 옮기는 확장입니다.

평가셋은 질문과 근거의 짝이다

평가 도구를 붙이기 전에 먼저 작은 평가셋을 만들어야 합니다. 여기서 평가셋은 많은 질문 목록이 아니라, 질문과 기대 근거가 연결된 최소 기록입니다. 질문만 모아 두면 답변 점수는 낼 수 있지만, 검색이 실패했는지 생성이 실패했는지 나누기 어렵습니다.

질문 유형 예시 질문 기대 근거 평가에서 보는 것
단일 근거 질문 특정 설정값의 의미를 묻는다 한 문서 조각 검색 누락과 답변 충실도
비교 질문 두 설정의 차이를 묻는다 두 문서 조각 이상 여러 근거가 함께 검색되는지
경계 질문 문서에 없는 내용을 묻는다 근거 없음 모른다고 답하는지
최신성 질문 버전별 동작 차이를 묻는다 버전 메타데이터가 붙은 조각 metadata filter가 작동하는지

이 네 유형을 작게라도 넣어 두면 평가 결과를 더 정확히 읽을 수 있습니다. 단일 근거 질문만 있으면 검색 누락은 잘 보이지만, 비교 질문에서 필요한 근거 일부만 검색되는 문제는 놓치기 쉽습니다. 경계 질문이 없으면 모델이 모르는 내용을 그럴듯하게 채우는 문제도 잘 드러나지 않습니다.

지표는 원인 후보를 좁히는 이름표다

RAGAS와 DeepEval은 여러 평가 지표를 제공합니다. 이 절에서 중요한 것은 지표 이름을 외우는 것이 아니라, 각 지표가 어느 실패 구간을 의심하게 만드는지 읽는 것입니다.

낮게 나온 항목 먼저 의심할 구간 바로 확인할 기록
context recall 검색 기대 근거가 top-k 후보에 들어왔는가
context precision 검색 순위 관련 없는 문서가 위에 섞였는가
faithfulness 생성 답변 문장이 검색 문맥에 실제로 있는가
answer relevancy 질문-답변 연결 답변이 질문의 요구 형식에 맞는가

예를 들어 faithfulness가 낮다면 먼저 prompt를 고치고 싶어집니다. 하지만 기대 근거 자체가 검색되지 않은 상태라면 prompt 수정은 원인에 닿지 않습니다. 반대로 context recall은 충분한데 faithfulness가 낮다면 검색보다 답변 제약, 인용 방식, 답변 형식이 먼저 수정 후보가 됩니다.

기록 양식

RAG 평가 실습에서는 최소한 다음 열을 남깁니다.

항목 예시
question_id q-014
question 사용자가 물은 질문
expected_context_id 답 근거가 되어야 하는 문서 조각
retrieved_context_ids 실제 검색 후보
answer 생성된 답변
retrieval_note 누락, 순위 문제, 충분함
generation_note 근거 충실, 과장, 질문 미응답
next_action chunk 수정, top-k 조정, prompt 수정, 평가셋 보강

중요한 점은 점수만 남기지 않는 것입니다. 점수는 비교를 빠르게 만들지만, 다음 조치가 검색 수정인지 생성 수정인지 적지 않으면 Part 7의 프로젝트 기록으로는 부족합니다.

다음처럼 한 행을 읽으면 수정 방향이 더 분명해집니다.

question_id expected_context_id retrieved_context_ids answer_state next_action
q-014 doc-07 doc-03, doc-11, doc-07 근거 일부 사용, 핵심 조건 누락 top-k 유지, 답변 형식에 조건 확인 항목 추가
q-018 doc-12 doc-02, doc-05, doc-08 답변 과장 위험 chunk 재분할, metadata filter 확인
q-021 없음 doc-04, doc-09 문서에 없는 내용을 단정 모름 응답 예시 추가, 경계 질문 평가셋 보강

첫 번째 행은 검색이 완전히 실패한 사례가 아닙니다. 기대 근거가 후보에 들어왔지만 답변이 조건을 빠뜨렸으므로 생성 쪽 기록을 먼저 고칩니다. 두 번째 행은 기대 근거가 검색되지 않았으므로 답변 prompt보다 검색 설정이 먼저입니다. 세 번째 행은 정답 근거가 없는 질문이므로, 좋은 시스템이라면 답을 만들어내기보다 근거 부족을 말해야 합니다.

작은 반복 순서

평가 도구를 붙인 뒤에는 한 번에 모든 설정을 바꾸지 않습니다. 먼저 같은 평가셋에서 하나의 축만 바꿉니다.

  1. 같은 질문과 같은 문서 조각에서 top-k만 바꿉니다.
  2. top-k를 고정하고 chunk 크기나 overlap만 바꿉니다.
  3. 검색 후보를 고정하고 답변 prompt만 바꿉니다.
  4. 실패가 반복되는 질문만 따로 묶어 질문 유형을 다시 봅니다.

이 순서를 지키면 점수 변화가 어떤 수정에서 나온 것인지 추적할 수 있습니다. 여러 값을 동시에 바꾸면 점수는 좋아져도 다음 프로젝트에서 어떤 판단을 재사용해야 하는지 남지 않습니다.

직접 바꿔 보며 확인할 것

  • top-k 값을 바꾸면 검색 누락과 검색 순위 문제가 어떻게 달라지는가?
  • 같은 검색 후보에서 답변 prompt만 바꾸면 faithfulness 판단이 달라지는가?
  • 질문을 더 좁게 다시 쓰면 answer relevancy가 좋아지는가?
  • 평가 점수가 낮은 사례가 실제로도 다음 수정 우선순위가 높은가?

체크리스트

  • 검색 평가와 생성 평가를 같은 점수 하나로 합치지 않았는가?
  • 정답 근거 문서와 실제 검색 후보를 함께 남겼는가?
  • hallucination 여부를 답변 인상만으로 판단하지 않았는가?
  • 낮은 점수를 다음 수정 항목으로 바꾸었는가?

출처와 참고 자료