← 블로그 목록
40 자동화·AI

운영 전 RAG 평가 설계: 검색 실패와 생성 실패를 분리하는 기준

RAG를 운영에 넣기 전 질문 세트와 근거 정답을 설계하고 검색·생성 실패를 분리해 출시 기준과 복구 루프까지 기록하는 실무 평가 가이드입니다. 운영자가 재현 가능한 평가표 작성법도 담았습니다.

운영 전 RAG 평가 설계: 검색 실패와 생성 실패를 분리하는 기준 대표 이미지

RAG를 운영에 넣기 전에는 모델 이름보다 평가 설계가 먼저입니다. 질문마다 기대하는 근거 문서와 답변의 경계를 정하고, 검색 실패와 생성 실패를 분리해 측정해야 출시 여부를 설명할 수 있습니다. 최소한 대표 질문 세트, 근거 정답, 실패 태그, 재평가 기록을 남기세요.

NIST AI RMF는 AI 위험을 맥락에 맞게 식별하고 측정·관리하도록 안내합니다.

출시 전 평가가 답해야 할 네 가지 질문

첫째, 실제 사용자가 묻는 질문이 평가 세트에 포함됐는가입니다. 자주 묻는 질문만 모으면 쉬운 문제만 남으므로 권한, 최신성, 모호한 표현, 답이 없는 질문을 섞습니다. 질문의 출처와 수집 시점을 함께 기록해 나중에 대표성 논쟁을 줄입니다.

둘째, 정답을 문장 하나가 아니라 근거 범위로 정의했는가입니다. 문서 ID, 버전, 단락 위치를 기대 근거로 저장하면 검색기가 관련 문서를 놓쳤는지, 모델이 근거를 무시했는지 나눠 볼 수 있습니다.

셋째, 측정 결과가 행동 기준으로 이어지는가입니다. 평균 점수만 보고 통과시키지 말고 보안·법무·금액 질문처럼 한 번의 오류도 허용하기 어려운 그룹에 별도 중단 조건을 둡니다.

넷째, 실패 후 다시 같은 문제를 찾을 수 있는가입니다. 프롬프트와 인덱스 버전, 검색 결과, 모델 응답, 평가자 판정을 한 실행 ID로 묶어야 수정 뒤 회귀를 확인할 수 있습니다.

검색 계층과 생성 계층의 실패를 분리해 기록하는 평가표

평가 세트를 만드는 입력 기준

입력은 로그에서 그대로 복사하지 말고 개인정보를 제거한 뒤 의도를 보존합니다. 질문 옆에 업무 목적, 허용된 답변 범위, 최신성 요구, 금지된 추론을 적으면 평가자가 서로 다른 기준으로 점수를 주는 일을 줄일 수 있습니다.

  • 질문·업무 목적·수집 날짜를 함께 저장한다.

  • 기대 근거 문서와 문서 버전을 고정한다.

  • 답이 없어야 하는 질문과 권한 밖 질문을 포함한다.

  • 각 케이스에 위험 등급과 재평가 담당자를 지정한다.

평가 데이터는 한 번 만든 정답지가 아니라 변경되는 운영 자산입니다. 문서가 개정되면 기존 기대 근거가 더 이상 맞는지 확인하고, 질문이 실제 업무를 대표하지 않게 되면 제외 사유를 남깁니다. 이런 버전 관리가 없으면 점수 상승이 시스템 개선인지 테스트 완화인지 구분되지 않습니다.

검색과 생성의 측정 경계를 나누기

검색 단계에서는 기대 근거가 top-k 결과에 들어왔는지, 최신 버전이 우선됐는지, 권한 필터가 적용됐는지를 확인합니다. 검색 결과가 틀렸다면 좋은 프롬프트로 감출 문제가 아니라 청킹·메타데이터·필터의 문제로 분류합니다.

생성 단계에서는 검색 결과만 사용했는지, 답변이 질문에 필요한 범위를 넘지 않는지, 인용이 실제 문장을 지지하는지 확인합니다. 근거가 없을 때 모른다고 말하거나 사람에게 넘기는지도 별도 판정 항목으로 둡니다.

OpenAI Evals 문서는 테스트 케이스와 평가 기준을 반복 실행해 모델 동작을 비교하는 방식을 설명합니다.

평가 실패를 원인 태그와 재평가로 되돌리는 복구 루프

예시: 사내 규정 질문 한 건을 끝까지 추적하기

예시의 입력은 “출장비 영수증이 없을 때 얼마까지 인정되는가?”입니다. 결정은 최신 출장 규정 문서만 근거로 답하고, 금액 기준이 없으면 보류하는 것으로 정합니다. 중간 산출물은 실행 ID, 검색된 문서 ID·버전·단락, 모델 답변, 평가자 판정이 들어간 JSON 기록입니다.

기대 결과는 최신 규정의 해당 단락을 인용한 답변과 “영수증 예외 기준이 문서에 없어 담당자 확인이 필요하다”는 보류 문구입니다. 구버전 문서가 검색되거나 금액을 추정하면 각각 검색 실패와 생성 경계 위반으로 태깅합니다.

이 한 건을 기준으로 검색 top-k를 바꾸면 검색 판정만 다시 보고, 프롬프트를 바꾸면 생성 판정만 다시 봅니다. 변경 전후의 실행 ID를 비교하면 어느 조치가 어떤 실패를 줄였는지 설명할 수 있습니다.

반례와 복구: 점수 평균이 좋아도 출시를 멈출 때

반례는 100개 중 99개가 일반 안내 질문이고 한 개가 개인정보 조회 질문인 평가 세트입니다. 평균 점수는 높아도 권한 밖 문서를 인용한 한 건은 출시를 막아야 합니다. 위험 그룹별 최소 기준과 즉시 중단 태그를 따로 두지 않은 것이 실패 원인입니다.

복구는 해당 그룹을 별도 회귀 세트로 고정하고, 검색 권한 필터와 보류 응답을 먼저 수정한 뒤 전체 세트를 재실행하는 순서입니다. 수정 전후 원본 결과를 덮어쓰지 말고 새 실행 ID로 보관해 개선 폭과 부작용을 함께 확인합니다.

완료 조건과 재평가 주기

  1. 대표성·위험 등급·기대 근거가 모든 케이스에 채워져 있다.

  2. 검색·생성·권한·최신성 판정이 별도 필드로 남는다.

  3. 실패 태그마다 담당 수정안과 재실행 ID가 연결된다.

  4. 중요 위험 그룹이 기준을 통과하고 오너가 출시를 승인한다.

완료는 점수표가 만들어진 시점이 아니라 위 기록을 다른 운영자가 재현할 수 있을 때입니다. 문서 인덱스, 프롬프트, 모델 또는 정책이 바뀌면 전체 세트가 아니라도 영향을 받는 그룹을 지정해 재평가하고, 기준 미달이면 자동으로 출시 보류 상태로 되돌립니다. 이 상태 전환과 승인자까지 기록되면 다음 배포에서도 같은 판단을 반복할 수 있습니다.