Confidence-Aware RAG는 RAG 시스템이 근거가 부족한 상황에서 그럴듯한 답변을 생성하지 않고, 명시적으로 답변을 보류하도록 만드는 설계 패턴이다. 핵심은 생성 단계 이전과 이후에 신뢰도 체크포인트를 넣어 “검색된 문서가 정말 충분한가”와 “답변이 실제 근거에 묶여 있는가”를 검증하는 것이다.
왜 필요한가
표준 RAG는 질문과 가장 가까운 문서를 찾은 뒤 LLM에 전달한다. 문제는 “가장 가까운 문서”가 “답을 담은 문서”가 아닐 수 있다는 점이다. 예를 들어 계약직 육아휴직 정책을 물었는데 정규직 정책 문서만 검색되면, 모델은 근거 없는 답을 자신 있게 생성할 수 있다.
이 실패는 일반 환각보다 위험하다. 사용자는 답변에 출처가 붙어 있다는 이유로 더 쉽게 믿기 때문이다.
3계층 방어
| 계층 | 역할 | 비용 |
|---|---|---|
| 검색 신뢰도 점수 | 리랭커 점수나 유사도 점수가 낮은 검색 결과를 생성 단계 전에 차단 | 낮음 |
| 인용 검증 | 답변의 모든 사실 주장에 실제 검색 문서의 출처가 붙었는지 검사 | 낮음 |
| LLM 기반 abstention judge | 별도 LLM 호출로 답변이 컨텍스트에 충분히 지지되는지 판정 | 중간 |
첫 번째 계층은 “검색부터 실패한 질문”을 막는다. 두 번째 계층은 모델이 없는 근거를 만들어내는 경우를 막는다. 세 번째 계층은 인용 형식은 맞지만 내용이 부분적이거나 과잉 해석된 경우를 잡는다.
구현 포인트
Azure AI Search처럼 semantic reranker score를 제공하는 검색 엔진을 쓰면, 임계값 이하 문서는 생성 컨텍스트에서 제외할 수 있다. Microsoft 예시는 0~4 범위의 @search.rerankerScore에서 1.5를 시작점으로 제안한다. 이 값은 고정 정답이 아니라 도메인별 평가셋으로 조정해야 한다.
인용 검증은 단순 정규식으로도 시작할 수 있다. LLM에게 [Source: 문서 제목] 형식을 강제하고, 응답에 등장한 출처명이 실제 검색 결과 목록에 있는지 검사한다. 없거나 인용이 하나도 없으면 답변을 숨기고 “관련 정보는 찾았지만 신뢰할 수 있는 답변을 제공할 수 없다”고 응답한다.
언제 써야 하나
- 기업 내부 규정 검색처럼 잘못된 답변의 비용이 큰 경우
- 지식 베이스가 부서별로 불균등하게 채워진 경우
- 사용자가 도메인 전문가가 아니어서 오류를 알아채기 어려운 경우
- 감사 추적, 규제 대응, 근거 문서 보존이 필요한 경우
관련 문서
- rag — 검색 증강 생성 기술 개요
- rag-tips-production — 프로덕션 RAG 운영 설계
- gemini-file-search — 관리형 파일 검색 기반 RAG
- llm-guardrails — LLM 출력 안전장치와 정책 제어
참고 자료
- Confidence-Aware RAG: Teaching Your AI Pipeline to Acknowledge Uncertainty — Microsoft Community Hub (2026-05-19)