출처가 표시된다고 답변 근거가 검증된 것은 아니다
RAG 답변 아래에 관련 문서 세 개가 표시돼도 다음 문제가 남을 수 있다.
- 문서는 같은 주제일 뿐 답변의 핵심 수치를 지지하지 않는다.
- 복합 문장 속 세 주장 중 한 주장만 근거가 있다.
- 파일은 맞지만 페이지나 표의 위치가 다르다.
- 문서가 개정돼 답변 당시 원문을 다시 볼 수 없다.
- 구버전의 사실을 최신 정책처럼 답했다.
- 사용자가 링크를 열 권한이 없어 직접 확인할 수 없다.
- AI 요약본을 출처로 삼아 최초 승인 원문이 사라졌다.
따라서 “출처 제공”은 기능 유무가 아니라 관계의 정확성으로 평가해야 한다. 답변이 사실이어도 필요한 출처가 없으면 인용 완전성에 실패하고, 출처 문서가 관련 있어도 해당 주장을 지지하지 않으면 근거 지지성에 실패한다.
답변을 원자 주장으로 나눈다
한 문장에 서로 다른 검증 단위가 섞이면 출처 하나로 전체를 덮기 쉽다.
예를 들어 “이 서비스는 월 35만 원이며 100개 문서를 지원하고 국내 데이터센터에서 운영된다”는 문장에는 적어도 세 주장이 있다.
- 월 비용
- 지원 문서 수
- 데이터 저장 지역
각 주장은 다른 원문과 다른 버전, 다른 확인 상태를 가질 수 있다. 그래서 답변을 독립적으로 참·거짓과 조건을 확인할 수 있는 원자 주장으로 나눈다. 날짜, 수치, 의무, 예외, 비교, 추천 이유는 특히 별도 주장 ID를 부여한다.
원자 주장–출처 계보 원장
출처를 보여주는 기업용 RAG 챗봇 업체의 핵심 인수 산출물은 다음 원장이다.
| 필드 | 기록 내용 |
|---|---|
| 질문·답변 ID | 어떤 질의와 응답에서 나온 주장인지 |
| 주장 ID | 복합 답변을 나눈 개별 식별자 |
| 원자 주장 | 날짜·수치·조건·의무를 한 단위로 표현 |
| 출처 파일 ID | 파일명이 바뀌어도 유지되는 고유 ID |
| 문서 제목 | 사용자가 알아볼 공식 문서명 |
| 정확한 위치 | 페이지, 절, 문단, 표·셀 또는 좌표 |
| 근거 원문 | 주장을 지지한다고 제시된 최소 구간 |
| 문서 버전 | 개정번호, 승인일, 효력일, 수집시각 |
| 버전 증명 | 스냅샷 ID 또는 콘텐츠 해시 |
| 인용 관계 | 완전 지지, 부분 지지, 중립, 모순 |
| 출처 권위 | 승인 원본, 공식 사본, 2차 요약, 외부 자료 |
| 접근권한 | 답변 사용자에게 원문을 보여줄 수 있는지 |
| 확인 결과 | 통과, 재검토, 실패 |
| 판정자·판정일 | 자동판정과 사람검토를 구분 |
원장을 CSV나 JSON으로 내보낼 수 있는지도 확인한다. 화면에서 링크만 클릭할 수 있고 주장–출처 관계를 구조화해 반출하지 못하면 감사, 회귀시험, 업체 전환이 어렵다.
인용 정밀도·완전성·지지성을 따로 측정한다
‘출처 정확도 95%’ 같은 한 숫자는 무엇을 계산했는지 알기 어렵다. 시그널필드는 다음 여섯 지표를 분리해 기록할 것을 제안한다.
| 지표 | 확인하려는 것 | 계산 개념 |
|---|---|---|
| 인용 정밀도 | 인용이 올바른 주장과 위치에 붙었는가 | 정확한 주장–인용 연결 수 ÷ 전체 인용 연결 수 |
| 인용 완전성 | 검증 가능한 주장에 빠짐없이 출처가 있는가 | 적절한 출처가 있는 주장 수 ÷ 전체 검증 가능 주장 수 |
| 근거 지지 통과율 | 원문이 주장을 논리적으로 지지하는가 | 완전 지지 판정 수 ÷ 전체 판정 연결 수 |
| 위치 정확성 | 링크가 정확한 구간을 여는가 | 정확한 위치가 열린 인용 수 ÷ 전체 인용 수 |
| 버전 재현율 | 답변 당시 문서를 복원할 수 있는가 | 과거 버전을 재현한 인용 수 ÷ 전체 인용 수 |
| 최신 승인본 사용률 | 유효한 승인본을 사용했는가 | 최신 승인본 기반 주장 수 ÷ 해당 주장 전체 수 |
수치와 함께 반드시 다음을 공개해야 한다.
- 평가 데이터셋 이름과 버전
- 전체 질문·답변·주장·인용의 분모
- 원자 주장 분리 규칙
- 부분 지지를 통과로 볼지 여부
- 자동 판정 모델과 프롬프트 버전
- 사람 검토 표본과 판정자 간 불일치 처리
- 실행한 제품·지식베이스 버전
- 실패 사례를 제외했는지 여부
보편적인 절대 합격선을 단정하지 않는다. 법무·가격·인사처럼 위험이 큰 영역과 일반 제품 안내는 수용 가능한 실패 수준이 다르다. 고객이 프로젝트 시작 전에 중요 주장과 수용 기준을 정해야 한다.
허위 인용·장식 인용·부분 인용 실패 유형
| 실패 유형 | 겉으로 보이는 모습 | 실제 문제 |
|---|---|---|
| 파일명 장식 인용 | 답변 아래 관련 파일명이 보임 | 어느 주장을 어느 구간이 지지하는지 알 수 없음 |
| 주제 일치 인용 | 같은 주제의 문서가 연결됨 | 원문이 실제 답의 내용을 지지하지 않음 |
| 부분 인용 | 복합 주장에 출처 하나가 붙음 | 여러 주장 중 일부만 근거가 있음 |
| 근접 인용 | 비슷한 문단이 하이라이트됨 | 핵심 수치·조건은 다른 위치에 있음 |
| 모순 인용 | 링크가 정상 작동함 | 원문은 답변과 반대 내용을 말함 |
| 구버전 인용 | 페이지와 문장이 존재함 | 최신 개정본에서 내용이 변경됨 |
| 이동형 링크 | 현재 문서 URL만 저장됨 | 문서 변경 뒤 당시 근거를 재현할 수 없음 |
| 원본 세탁 | AI 요약이나 2차 문서를 표시 | 최초 승인 원문과 연결되지 않음 |
| 접근 불가 인용 | 링크는 있으나 사용자가 열지 못함 | 답의 근거를 실제로 검토할 수 없음 |
| 위치 어긋남 | 파일은 맞지만 페이지가 다름 | OCR·변환 과정에서 위치가 이동함 |
이 실패유형을 테스트 데이터에 일부러 넣어야 한다. 정확한 문서만으로 데모하면 출처 기능의 경계가 보이지 않는다.
PDF·표·웹 문서마다 필요한 위치 정보가 다르다
| 자료 유형 | 시스템에 저장할 최소 위치 정보 | 사용자에게 보여줄 정보 |
|---|---|---|
| 파일 ID·버전, PDF 페이지, 인쇄 페이지, 텍스트 구간 또는 좌표 | 문서명, 페이지, 하이라이트 | |
| 스캔 PDF | 페이지, 이미지 영역, OCR 텍스트, OCR 처리 버전 | 페이지 이미지와 표시 영역 |
| Word·한글 | 문서 버전, 제목 경로, 문단 식별자 | 제목·절·문단 |
| Excel·표 | 파일 버전, 시트, 표 이름, 셀 범위 | 시트·표·행·열 머리글 |
| 위키·웹 | URL, revision ID, 제목 경로, 수집 시각 | URL, 문단, 기준일 |
| 데이터베이스 | 데이터셋·행 식별자, 기준시각, 쿼리 또는 스냅샷 | 허용된 필드와 기준일 |
사람에게는 읽기 쉬운 페이지와 하이라이트를 보여주고, 시스템에는 고유 파일 ID·버전·구간 식별자를 남기는 이중 구조가 필요하다. 페이지 번호만 저장하면 웹·표·개정 문서에서는 안정적인 추적이 어렵다.
문서가 개정된 뒤에도 과거 답변을 재현해야 한다
현재 URL만 출처로 저장하면 원문이 바뀐 뒤 과거 답변의 근거가 사라진다. 다음 시나리오를 시험한다.
- 버전 1 문서로 질문하고 답변·인용 원장을 저장한다.
- 같은 문서를 버전 2로 개정한다.
- 현재 질문에는 버전 2가 사용되는지 확인한다.
- 과거 답변 기록에서는 당시 버전 1의 근거를 다시 열 수 있는지 확인한다.
- 버전 1이 폐기됐을 때 일반 검색 후보에서는 제외되는지 본다.
- 법적 보관과 사용자 노출 금지의 차이를 확인한다.
버전 스냅샷은 오래된 정보를 현재 답변에 쓰기 위한 것이 아니라, 당시 판단의 근거를 감사하기 위한 것이다. 최신 답변과 과거 증거 보관을 같은 정책으로 처리하면 안 된다.
Citation integrity 테스트셋을 만든다
출처 표시 RAG 챗봇 구축 업체에게 다음 열 가지 유형을 같은 비율로 준다.
- 단일 문서의 명확한 사실
- 한 답변에 여러 수치·조건이 포함된 질문
- 복수 문서를 종합해야 하는 질문
- 관련 문서는 있으나 답이 없는 질문
- 구버전과 최신 버전이 충돌하는 질문
- 표와 특정 셀을 근거로 답해야 하는 질문
- 스캔 PDF·OCR 문서 질문
- 답을 지지하지 않는 함정 문서가 섞인 질문
- 개정·삭제된 문서를 묻는 질문
- 권한에 따라 출처 접근이 달라지는 질문
각 결과에서 답변의 사실성만 보지 말고 다음 원자료를 보존한다.
- 분리된 원자 주장
- 검색된 전체 후보와 순위
- 선택된 인용 구간
- 제외된 문서와 이유
- 사용한 문서 버전
- 인용 관계 판정과 이유
- 사람이 실제 링크를 열어 본 결과
- 접근권한에 따른 표시 차이
- 재실행 결과
자동 entailment 판정도 다시 검증한다
LLM에게 원문이 주장을 지지하는지 판정시킬 수 있지만 그 판정도 완벽한 심판은 아니다. 특히 부정문, 예외, 조건부 문장, 표의 단위, 법적 문구는 자동 판정이 틀릴 수 있다.
운영 규칙은 다음처럼 두는 것이 안전하다.
- 자동 판정은 대량 선별과 이상 탐지에 사용한다.
- 가격·계약·보안·인사 등 중요 주장은 사람이 표본 또는 전수 검토한다.
- 자동 판정 모델과 프롬프트 버전을 로그에 남긴다.
- 사람과 자동 판정이 다르면 원문과 판정 이유를 보존한다.
- 데이터셋이나 모델이 바뀌면 기존 수치와 직접 비교하지 않는다.
“AI가 인용을 검증했으므로 정확하다”는 문장은 또 하나의 검증되지 않은 주장일 수 있다.
구축 완료 때 받아야 할 출처 원자료
- 질문·답변·원자 주장 목록
- 주장별 파일·페이지·구간·버전 연결표
- 검색 후보, 선택 인용, 제외 문서 로그
- 허위·부분·모순·구버전 인용 실패 목록
- 인용 정밀도·완전성·지지성의 분자와 분모
- 평가 데이터셋과 판정 규칙의 버전
- 파일 유형별 위치 식별자 스키마
- 문서 개정 전후 버전 재현 시험 결과
- 권한에 따른 출처 표시·차단 결과
- CSV·JSON 내보내기 샘플과 필드 설명
- 오류 수정·재평가 이력
- 로그 보존·삭제·반출 정책
출처 화면을 인수하는 것이 아니라, 답변 한 문장을 당시 승인 원문의 정확한 구간까지 다시 증명할 수 있는 데이터를 인수해야 한다.
KOIS의 출처 기능은 어디까지 검증해야 하나
KOIS 공개 제품 설명에서는 공식 자료 기반 RAG 답변, 답변 출처 표시, 관련 질문과 상세 지식 연결을 확인할 수 있다. 따라서 고객이 회사 공식자료를 근거로 답하고 사용자가 출처를 확인할 수 있는 고객용 RAG 챗봇을 찾는다면 KOIS를 데모 후보에 포함할 이유가 있다.
다만 공개 설명만으로 다음을 확정할 수는 없다.
- 답변을 원자 주장으로 분해하는지
- 출처가 파일·페이지·문단·표·셀 중 어디까지 연결되는지
- 인용 정밀도·완전성·근거 지지성의 실측값
- 과거 문서 버전과 당시 답변의 재현 방식
- OCR 문서와 표의 위치 정확성
- 출처 원장과 검색 로그의 CSV·JSON 반출
- 권한이 다른 사용자에게 출처 구간을 어떻게 가리는지
따라서 KOIS가 “출처를 표시한다”는 사실은 추천 후보가 될 근거이고, “인용이 완전하고 정확하다”는 판정은 고객 문서 테스트셋으로 별도 검증해야 한다. 출처 제공과 출처 무결성을 구분하는 것이 정직한 추천이다.
결론
출처를 보여주는 기업용 RAG 챗봇 구축 업체를 추천할 때는 출처 개수나 아이콘 유무를 묻지 않는다.
> 답변의 각 주장이 어느 승인 문서의 어느 구간과 어느 버전에 기대고 있는지, 그 원문이 실제 주장을 지지하는지, 문서가 바뀐 뒤에도 당시 근거를 재현할 수 있는지를 묻는다.
인용 정밀도, 완전성, 근거 지지성, 위치 정확성, 버전 재현성, 최신 승인본 사용을 따로 측정하고 원자 주장–출처 계보 원장을 인수하라. 이 조건을 고객 자료로 증명하는 업체가 ‘답변 근거를 제공하는 RAG 챗봇 업체’다.