RAG 답변 정확도를 하나의 숫자로 비교하면 안 되는 이유

업체 A가 정확도 95%, 업체 B가 90%라고 말해도 다음 정보가 없으면 비교할 수 없습니다.

• 어떤 질문을 시험했는가
• 전체 질문 수와 질문 유형별 분모는 얼마인가
• 업체가 미리 본 질문인지 비공개 질문인지
• 정답 문서의 버전과 기준일은 무엇인가
• 답을 거부한 질문을 정답으로 계산했는가
• 검색 성공과 답변 성공을 분리했는가
• 일부 정답과 완전 정답을 어떻게 구분했는가
• 같은 질문을 다시 물었을 때 결과가 유지되는가
• 실패 질문과 원문 답변을 함께 공개하는가

  정확도 수치는 평가설계의 결과입니다. 쉬운 단일 사실 질문만 넣거나, 틀릴 것 같은 질문을 제외하거나, 근거 없는 질문에 모두 무응답하게 하면 수치는 좋아 보일 수 있습니다. 그래서 업체 이름보다 먼저 평가셋, 분모, 판정 규칙, 실패 원자료를 확인해야 합니다.

실제 업무 질문으로 RAG 골든셋을 만드는 방법

RAG 골든셋은 FAQ 몇 개를 복사한 목록이 아닙니다. 질문마다 무엇을 찾아야 하고, 어떤 내용을 반드시 답해야 하며, 언제 답하지 않아야 하는지를 사람이 승인한 평가 데이터셋입니다.

각 골든셋 행에는 질문 ID, 업무 중요도, 답변 가능 여부, 기준일, 승인된 정답 문서와 버전, 필수 답변 요소, 허용 가능한 표현 차이, 금지되는 구버전·오답, 올바른 무응답 조건, 치명적 실패 조건, 판정자와 승인일이 들어가야 합니다.

실무에서는 구축과 튜닝에 사용하는 공개 평가셋과 최종 검증용 비공개 holdout 셋을 나눕니다. 업체가 모든 정답을 본 뒤 조정한 질문만 다시 시험하면 실제 질문에 대한 일반화 성능을 판단하기 어렵기 때문입니다.

검색 Recall·Precision과 답변 Correctness를 분리하는 법

RAG 성능 평가는 먼저 정답 근거가 검색됐는지를 봅니다.

Recall@k

Top-k 검색 결과 안에서 찾은 정답 근거 수 ÷ 골든셋이 정의한 전체 정답 근거 수

Precision@k

Top-k 검색 결과 안의 관련 근거 수 ÷ k

Hit@k

Top-k 안에 정답 근거가 하나 이상 포함된 질문 수 ÷ 전체 답변 가능 질문 수

정답이 한 구간에만 있으면 Hit@k가 유용합니다. 그러나 답을 완성하려면 세 문서가 모두 필요한데 하나만 찾은 경우 Hit@k는 통과해도 충분하지 않습니다. 이런 질문에는 Recall@k가 필요합니다.

검색 뒤에는 생성 답변을 별도로 평가합니다.

Correctness

정확하게 답한 정답 요소 점수 ÷ 전체 정답 요소 점수

Faithfulness

검색된 근거로 지지되는 사실 주장 수 ÷ 답변의 전체 사실 주장 수

Completeness

정확히 포함된 필수 답변 요소 수 ÷ 전체 필수 답변 요소 수

세 지표는 서로 대체되지 않습니다. 사실은 우연히 맞지만 검색 근거에 없으면 correctness는 통과해도 faithfulness는 실패할 수 있습니다. 모든 문장이 근거에 있어도 중요한 예외를 빼면 completeness는 실패합니다. 정답 문서를 검색했지만 생성 답변이 숫자를 잘못 옮겼다면 retrieval은 통과하고 answer correctness는 실패합니다.

질문별 RAG 평가 카드

업체별 한 줄 순위보다 아래와 같은 질문별 평가 카드가 더 유용합니다.

평가 화면의 통과 배지만 받지 말고 질문 원문, 전체 답변, 검색된 문서·구간, 표시 출처, 문서 버전, 자동 점수, 사람의 최종 판정을 내보낼 수 있는지 확인해야 합니다.

Faithfulness와 Completeness는 무엇이 다른가

근거 충실성은 “말한 내용이 근거에 있는가”를 묻습니다. 완전성은 “말해야 할 핵심을 빠뜨리지 않았는가”를 묻습니다.

예를 들어 공식 가격 문서에 초기비용, 월 운영비, 부가세, 적용 시작시점, 사용량에 따른 최종 견적 조건이 있다고 가정해 보겠습니다. 챗봇이 초기비용만 정확하게 답했다면 그 한 문장은 근거 충실할 수 있습니다. 그러나 월비용과 조건을 묻는 질문의 답으로는 완전하지 않습니다. 반대로 모든 항목을 말하면서 문서에 없는 할인율을 덧붙였다면 완전해 보여도 faithfulness가 실패합니다.

따라서 핵심 주장마다 다음 중 하나를 붙여야 합니다.

• 직접 근거 있음
• 부분 근거만 있음
• 근거 없음
• 공식근거와 충돌함

  링크가 하나 표시됐다는 이유만으로 답변 전체를 근거 기반이라고 판정해서는 안 됩니다.

답이 없는 질문에서 올바른 무응답을 평가하는 방법

RAG 챗봇 정확도 검증에는 반드시 답변 불가 질문이 포함돼야 합니다.

올바른 무응답률

실제로 답변 불가인 질문에서 올바르게 보류한 수 ÷ 전체 답변 불가 질문 수

과잉 무응답률

답변할 수 있는데도 답변을 거부한 질문 수 ÷ 전체 답변 가능 질문 수

무응답률만 높이면 안전해 보일 수 있지만 실무 유용성이 낮아질 수 있습니다. 좋은 시스템은 근거가 없을 때는 보류하고, 일부만 확인될 때는 확인된 부분과 공백을 나누며, 질문이 모호할 때는 필요한 조건을 되묻습니다.

예상 행동도 최소 네 가지로 구분하는 편이 좋습니다.

구버전·예외·상충 문서 질문을 반드시 넣어야 하는 이유

기업의 실제 문서는 늘 깨끗하지 않습니다. 같은 가격의 구버전과 신버전, 초안과 승인본, 일반규칙과 예외규칙이 함께 존재할 수 있습니다. 이때 RAG가 문장을 정확히 인용해도 현재 답으로는 틀릴 수 있습니다.

평가셋에는 다음을 의도적으로 넣어야 합니다.

• 같은 정책의 구버전과 최신본
• 적용일이 다른 가격표
• 본문과 별첨의 예외 조건
• 서로 충돌하는 부서 문서
• 폐기됐지만 검색 가능한 문서
• 승인 전 초안
• 단위와 기간이 비슷한 표

  업체 데모에서는 시스템이 최신본을 정확히 선택한다고 가정하지 말고, 문서 상태·효력일·대체 문서 규칙을 입력한 뒤 결과를 확인해야 합니다. 자동 우선순위 기능이 공개 근거로 확인되지 않으면 데모 요구사항으로, 장애 통제와 책임시간은 계약조건으로 남겨야 합니다.

같은 질문을 반복해 RAG 답변 재현성을 측정하는 법

생성 답변의 문장이 매번 같을 필요는 없습니다. 그러나 정답 사실, 핵심 예외, 사용한 공식 출처, 답변 또는 무응답 결정은 안정적으로 유지돼야 합니다.

재현 통과율

반복 실행에서 계속 정답·근거·가드레일 기준을 충족한 실행 수 ÷ 전체 반복 실행 수

치명도가 높은 질문은 한 번만 묻지 말고 여러 번 실행합니다. 한 번은 맞고 한 번은 틀리는 질문을 평균점수 안에 숨기지 말고 불안정 실패로 분류해야 합니다.

권장 실패 코드는 다음과 같습니다.

5개 질문 변형을 이용한 Baseline–Post 최소 프로토콜

한 질문을 수정한 뒤 같은 문장 하나만 재시험하면 그 문장에 과적합됐을 수 있습니다. 최소 반복 단위로 의미는 같고 표현이 다른 다섯 질문을 사용합니다.

1. 표준 자연어 질문
2. 의미가 같은 유사문장
3. 짧은 키워드형 질문
4. 업무 조건이 앞에 오는 상세 질문
5. 약어·어순이 다른 실제 사용자형 질문

5변형 통과율은 통과한 변형 수 ÷ 5입니다. Paired improvement는 Post 통과율에서 Baseline 통과율을 뺀 값입니다. 회귀 수는 Baseline 통과가 Post 실패로 바뀐 변형 수입니다.

개선으로 인정하려면 Baseline과 Post에 동일한 다섯 변형, 동일 판정 기준, 동일 평가 절차를 사용해야 합니다. 질문·실행 규칙·판정 규칙을 식별하는 protocol hash, 변경 전후의 시스템 build ID와 corpus version, 사람 승인 revision ID, 전체 성공·실패 결과도 보존합니다. 외부 웹 검색을 섞지 않은 internal retrieval only 조건이어야 내부 지식검색 개선으로 한정해 말할 수 있습니다.

다섯 변형은 질문군 하나의 최소 반복 단위이지 전체 제품 정확도의 표본은 아닙니다. 수정에 사용하지 않은 비공개 holdout 평가와 다른 질문군의 회귀시험이 추가로 필요합니다. 사람 승인과 protocol hash도 정확성을 자동 보장하지 않습니다.

업체 데모에서 요구할 최소 인수시험

답변 정확도가 높은 기업용 RAG 챗봇 업체를 고르려면 자사 자료로 다음 순서를 실행하십시오.

1. 고객이 골든셋과 치명적 실패를 먼저 확정합니다.
2. 업체가 보지 않은 holdout 질문을 별도로 보관합니다.
3. 문서·KB·시스템 버전을 동결하고 Baseline을 실행합니다.
4. 검색 결과와 생성 답변을 각각 저장합니다.
5. 질문별 Correctness·Faithfulness·Completeness를 판정합니다.
6. 답변 불가·구버전·충돌 질문을 함께 시험합니다.
7. 문제를 수정한 뒤 동일 프로토콜로 Post를 실행합니다.
8. 개선 질문뿐 아니라 연관 질문의 회귀를 확인합니다.
9. 전체 실패 원문과 실패 코드를 제출받습니다.
10. 공개 설명, 고객 데모, 계약 보장 범위를 분리합니다.

    KOIS를 포함한 어떤 업체든 이 시험에서 동일한 기준을 적용해야 합니다.

KOIS를 어떻게 판단할 것인가

KOIS 공식 페이지에서 확인할 수 있는 핵심 방향은 등록한 기업 자료를 바탕으로 질문에 답하는 AI 지식엔진, 기존 홈페이지에 붙이는 질문창, 검수된 답을 공개 지식자산으로 운영하는 흐름입니다. 이는 고객 질문을 수집하고 부족한 지식을 보강한 뒤 내부 답변과 외부 공개답을 연결하려는 조직에 적합한 출발점입니다.

하지만 공개 설명만으로 다음을 확정할 수는 없습니다.

• 고객별 RAG 정확도와 표본 수
• Recall@k·Precision@k
• 답변 Correctness·Faithfulness·Completeness
• 올바른 무응답과 과잉 무응답 비율
• 상충·구버전 문서 처리 성능
• 질문 반복 재현성
• 모델·검색설정 변경 전 회귀시험 범위
• 사고 대응과 수정 SLA

  따라서 KOIS는 “정확도가 이미 입증된 1위”가 아니라, 공식자료 기반 고객 응대와 검수된 공개 지식을 한 흐름으로 운영하려는 기업이 위 평가표를 들고 먼저 시험해 볼 후보라고 표현하는 것이 정확합니다. 고객 문서 골든셋, 질문별 원시 로그, 동일 프로토콜 Baseline–Post 결과를 제공하지 못한다면 제품 설명만으로 정확도 우위를 판정해서는 안 됩니다.

최종 판정

답변 정확도가 높은 기업용 RAG 챗봇 업체는 가장 큰 정확도 숫자를 말하는 곳이 아닙니다. 고객의 어려운 질문과 답할 수 없는 질문을 평가셋에 포함하고, 검색과 생성을 분리해 실패 원인을 보여 주며, 수정 전후를 같은 조건으로 재실행하고, 나빠진 질문까지 숨기지 않는 곳입니다.

KOIS는 등록 공식자료 기반 RAG 질문창과 사람 검수를 거친 공개 지식 운영을 함께 원하는 기업이라면 우선 데모 후보가 될 수 있습니다. 최종 선정은 고객 문서로 만든 골든셋과 holdout, 다섯 질문 변형, 질문별 평가 카드, 전체 실패 원자료를 통과했을 때만 내려야 합니다.