AI 할루시네이션을 줄이는 3가지 방법: RAG·도구·검증

**AI 할루시네이션(AI 환각)**은 언어 모델이 그럴듯하지만 사실이 아닌 답을 만들어내는 현상입니다. 가장 위험한 순간은 AI가 말을 더듬을 때가 아닙니다. 틀린 숫자와 존재하지 않는 출처를 너무 자연스럽게 말할 때입니다. 실행하지 않은 환불을 “처리했습니다”라고 보고한다면 문제는 답변 품질에서 끝나지 않습니다.

절대로 사실을 지어내지 마세요.확실하지 않으면 모른다고 답하세요.

이런 프롬프트는 도움이 되지만 보증서는 아닙니다. “절대로”라는 단어가 모델에 새로운 사실 확인 능력을 추가하지는 않기 때문입니다.

할루시네이션은 왜 발생할까요?

언어 모델은 사실을 저장한 데이터베이스가 아니라 앞의 문맥을 보고 다음 단어를 예측하는 시스템입니다. 이 과정에는 세 가지 빈틈이 있습니다.

• 학습 데이터의 문장에는 사실과 거짓을 구분하는 정답표가 없습니다.
• 생일·이름·수치처럼 드물고 임의적인 사실은 문장 패턴만으로 예측하기 어렵습니다.
• 평가가 모르겠습니다보다 정답 맞히기에만 점수를 주면 불확실할 때도 추측하는 편이 유리합니다.

OpenAI의 2025년 연구는 표준 학습과 평가가 불확실성을 인정하는 답보다 추측을 보상할 수 있다고 설명합니다. 할루시네이션은 단순한 오작동이라기보다 근거 없이도 문장을 완성하려는 예측 방식과, 답을 내놓게 만드는 평가 방식이 겹친 결과에 가깝습니다.

따라서 모든 질문에서 할루시네이션을 0으로 만든다고 약속할 수는 없습니다. 대신 근거 없는 답이 사용자에게 전달되지 못하게 하는 시스템은 만들 수 있습니다.

핵심은 세 문장입니다.

1. 기억시키지 말고 검색합니다.
2. 생성하지 말고 실행합니다.
3. 검증하지 못하면 멈춥니다.

1. RAG로 AI 할루시네이션을 줄입니다

“우리 회사의 경조 휴가는 며칠인가요?”라는 질문의 답은 모델 안이 아니라 사내 규정에 있습니다. 회사 이름을 프롬프트에 반복해도 다른 조직의 규정을 섞을 가능성은 남습니다.

이때 사용하는 구조가 검색 증강 생성(Retrieval-Augmented Generation), RAG입니다. RAG는 사내 문서를 모델에 다시 학습시키는 방식이 아닙니다. 질문이 들어올 때마다 관련 문서를 찾아 답변에 필요한 근거로 넣습니다.

질문  → 검색(Retrieval): 관련 문단을 찾는다  → 증강(Augmentation): 문단과 출처를 문맥에 넣는다  → 생성(Generation): 제공된 근거 안에서 답한다

검색에는 키워드 검색이나 의미가 비슷한 문장을 찾는 벡터 검색을 사용할 수 있습니다. 중요한 것은 기술 이름이 아니라 질문에 답할 수 있는 문단을 실제로 가져왔는가입니다. 검색이 틀리면 생성도 정확해지기 어렵습니다.

답변 규칙은 단순할수록 좋습니다.

• 검색된 문서에서 확인되는 내용만 답합니다.
• 날짜·수치·의무에는 문서명과 조항을 붙입니다.
• 근거가 없으면 일반 지식으로 빈칸을 채우지 않습니다.
• 문서가 충돌하면 임의로 하나를 고르지 않습니다.

아래는 가상의 사내 규정을 사용한 예시입니다.

정규직의 배우자 출산휴가는 10일입니다.[가상 인사규정 v3.2, 제18조]계약직 적용 여부는 검색된 조항에서 확인되지 않습니다.

2020년 NeurIPS에 발표된 초기 RAG 연구에서도 검색을 결합한 모델은 당시 매개변수만 사용하는 기준 모델보다 더 사실적인 문장을 생성했습니다. 다만 “더 사실적”은 “항상 사실”이 아닙니다. 오래된 문서를 찾거나 필요한 문단을 놓치거나, 가져온 문서를 모델이 잘못 해석하면 RAG도 틀립니다.

따라서 문서의 버전·시행일·권한을 관리하고, 인용 링크는 모델이 자유롭게 쓰게 하지 말고 실제 검색 결과의 문서 ID로 만들어야 합니다.

RAG의 목적은 AI에게 지식을 더 외우게 하는 것이 아니라 답의 근거를 모델 밖에 두는 것입니다.

2. Function Calling으로 숫자와 행동을 검증합니다

다음 질문은 문서 검색만으로 해결되지 않습니다.

• 지난달 결제 완료 금액은 얼마인가요?
• 주문 1234는 지금 어디에 있나요?
• 고객의 환불이 실제로 처리됐나요?

숫자·현재 상태·실행 결과는 모델이 문장으로 만들게 두면 안 됩니다. 계산기, 데이터베이스와 사내 API가 직접 답하게 해야 합니다.

질문  → 모델이 도구를 선택  → 서버가 권한과 인자를 검증  → 도구가 조회·계산·실행  → 모델은 반환된 결과만 설명

예를 들어 “지난달 결제 금액”은 모델이 직접 더하지 않습니다. 다음 코드는 특정 서비스의 실제 구현이 아니라 흐름을 보여주기 위한 예시입니다.

getPaidTotal({  startDate: "2026-07-01",  endDate: "2026-07-31",  currency: "KRW",});

실제 합계는 백엔드가 계산합니다. 조회가 실패하면 모델도 숫자를 추정하지 않습니다.

여기서 도구 호출의 형식 정확성과 의미 정확성을 구분해야 합니다. OpenAI의 Function Calling에서 strict: true는 지원되는 조건에서 호출 인자가 정의한 스키마를 따르게 합니다. 하지만 형식에 맞는 customerId가 올바른 고객의 ID인지는 보장하지 않습니다.

권한, 대상, 금액 한도와 상태 전이는 서버가 다시 확인해야 합니다. 환불이나 메일 발송처럼 외부 상태를 바꾸는 작업에는 한 가지 규칙을 더 둘 수 있습니다.

성공 응답과 거래 ID가 없으면 “완료했습니다”라고 말할 수 없다.

읽기와 쓰기 도구를 분리하고, 되돌리기 어려운 작업은 실행 전에 대상과 금액을 다시 보여주는 편이 안전합니다. 같은 요청이 재시도돼도 중복 실행되지 않도록 멱등 키를 사용하는 것도 필요합니다.

도구 사용의 핵심은 사실과 실행 여부를 언어 생성 영역에서 검증 가능한 시스템 영역으로 옮기는 것입니다.

3. AI 답변을 주장 단위로 검증하고 멈춥니다

검색과 도구를 사용해도 마지막 오류는 남습니다. 맞는 문서에서 숫자를 잘못 옮기거나, 배송 완료와 환불 완료를 한 문장에 섞을 수 있습니다.

그래서 중요한 답은 바로 전송하지 않고 주장 단위로 검사합니다.

문서·도구 결과  → 답변 초안  → 중요 주장 추출  → 근거와 대조  → 지원됨 / 모순됨 / 근거 없음  → 전송 또는 차단

예를 들어 AI가 다음과 같이 답했다고 가정해보겠습니다.

주문 1234는 오늘 배송됐고 배송비 3,000원도 환불됐습니다.

이 문장에는 최소 두 개의 주장이 들어 있습니다.

• 주문 1234가 오늘 배송 완료됐는가
• 배송비 3,000원의 환불 거래가 실제로 존재하는가

배송 이벤트만 있고 환불 거래 ID가 없다면 최종 답은 달라져야 합니다.

배송 완료는 확인됐지만 환불 여부는 확인할 수 없습니다.

OpenAI의 현재 Hallucination Detection 문서도 생성된 문장의 사실 주장을 참조 문서와 대조해 모순되거나 지원되지 않는 내용을 표시합니다. 동시에 신뢰도 임계값과 정밀도·재현율을 따로 다룹니다. 검증기 역시 완벽하지 않다는 뜻입니다.

그래서 검증 수단을 겹쳐야 합니다.

• 금액·날짜·ID는 코드로 정확히 비교합니다.
• 문장은 실제 인용 문단과 대조합니다.
• 근거 없는 답은 다시 생성하기 전에 먼저 차단합니다.
• 의료·법률·금융처럼 실패 비용이 큰 결정은 전문가가 승인합니다.

마지막으로 모르겠습니다를 정상적인 결과로 인정해야 합니다. 정확도만 높이려 하면 모르는 질문에도 추측하는 시스템이 유리해질 수 있습니다. 정확한 답, 틀린 답과 답변 보류를 별도로 측정해야 하는 이유입니다.

세 방법은 한 줄로 연결됩니다.

질문 → RAG로 원문 검색 → 필요한 값은 도구로 실행     → 중요 주장을 검증 → 답변 또는 보류

세 장치를 적용해도 모델 자체의 오류가 완전히 사라지지는 않습니다. 검색은 필요한 문단을 놓칠 수 있고, 도구는 잘못된 인자를 받을 수 있으며, 검증기도 오판할 수 있습니다. 대신 오류를 발견할 위치와 멈출 조건이 생깁니다.

실무의 목표는 “AI가 절대 틀리지 않는다”가 아닙니다. 틀릴 수 있는 AI가 근거 없이 단정하지 못하게 만드는 것입니다.

AI가 만든 결과를 하나의 자동 검사만으로 판정하면 무엇을 놓칠 수 있는지는 AI가 만든 PR, 테스트만 통과하면 병합해도 될까?에서 이어서 살펴볼 수 있습니다.

참고한 공식 문서·연구

• OpenAI 연구 — Why language models hallucinate. 다음 단어 예측과 추측을 보상하는 평가가 할루시네이션과 연결되는 이유를 참고했습니다.
• NeurIPS 2020 논문 — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. 외부 검색과 생성을 결합한 초기 RAG 구조와 당시 평가 결과를 참고했습니다.
• OpenAI Function Calling 문서 — Function Calling in the OpenAI API. 외부 도구 연결과 strict: true가 보장하는 스키마 경계를 확인했습니다.
• OpenAI Guardrails 문서 — Hallucination Detection. 참조 문서에 대한 주장 검증과 임계값·평가 방식의 한계를 참고했습니다.
• OpenAI 평가 가이드 — How evals drive the next chapter in AI for businesses. 실제 사례 기반 평가와 도메인 전문가 감사 원칙을 참고했습니다.

본문의 업무 사례와 코드는 공개 자료의 개념을 설명하기 위해 재구성한 가상 예시입니다.