18. 환각을 줄이는 법

4부는 "좋은 프롬프트인지 어떻게 아는가"를 다룹니다. 2·3부가 원하는 결과를 끌어내는 법이었다면, 4부는 그 결과를 믿을 수 있게 만드는 법입니다.

환각이란

모델이 사실이 아닌 내용을, 그것도 그럴듯하고 자신 있게 만들어내는 현상을 환각이라 부릅니다. 존재하지 않는 논문을 인용하거나, 틀린 날짜·수치를 단정하거나, 없는 기능을 설명하는 식입니다. 가장 위험한 점은 틀렸다는 티가 안 난다는 것입니다.

왜 환각이 생기나 — 원리

2장으로 돌아갑시다. 모델은 "다음에 올 가장 그럴듯한 말"을 잇습니다. 여기서 핵심은 "그럴듯한"이지 "사실인"이 아니라는 것입니다.

모델에게 "사실 여부"는 별도의 검증 단계가 아니라, 그저 학습 데이터에서 그 말이 얼마나 자주, 자연스럽게 이어졌는가의 문제입니다. 그래서 진짜 정보가 없는 빈칸을 만나면, 모델은 "모른다"고 멈추는 대신 그럴듯하게 이어지는 말로 빈칸을 채웁니다. 사람으로 치면, 모르는 걸 모른다고 하기보다 매끄럽게 둘러대는 것에 가깝습니다.

flowchart TB
    q["질문"] --> have{"관련 정보가<br/>충분한가?"}
    have -->|예| ground["근거 있는 답"]
    have -->|아니오| fill["그럴듯한 말로<br/>빈칸을 채움 = 환각"]

    classDef dec fill:#fef9c3,stroke:#eab308,color:#713f12
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    classDef bad fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    class have dec
    class ground good
    class fill bad

📌 핵심: 환각은 모델의 "버그"라기보다, "그럴듯함을 잇는다"는 본질의 부작용입니다. 그러니 대응의 핵심은 두 가지 — 빈칸이 생기지 않게 정보를 주고(예방), "모르면 모른다"고 할 길을 열어주는 것(허용)입니다.

대응 1순위: 근거 자료를 준다 (예방)

환각을 줄이는 가장 강력한 방법은, 16장에서 다룬 근거 자료 제공입니다. 빈칸이 없으면 채울 일도 없습니다. 모델이 추론으로 메워야 할 영역을 줄일수록 환각도 줄어듭니다.

환각 유발 ❌
"우리 회사 환불 정책 알려줘"
(모델은 우리 회사 정책을 모름 → 일반적인 정책을 지어냄)

근거 제공 ✅
"<규정>...실제 환불 규정...</규정>
이 규정에 근거해서만 환불 정책을 설명해줘."

대응 2순위: "모르면 모른다"를 허용한다

모델은 기본적으로 "도움이 되려" 빈칸을 채우는 경향이 있습니다. 그러니 모른다고 말해도 된다는 것을 명시적으로 허용하세요. 이것만으로도 자신 있는 거짓이 크게 줍니다.

✅
"자료에 근거가 없는 내용은 추측하지 말고
'주어진 정보로는 알 수 없습니다'라고 답해."

💡 팁: 10장의 교훈을 떠올리세요 — "추측하지 마"라는 포괄적 금지는 정당한 추론까지 막을 수 있습니다. 그러니 "자료에 없으면 모른다고 해"처럼 범위를 자료로 한정하는 형태가 안전합니다. "절대 추론하지 마"가 아니라 "자료 밖 사실은 지어내지 마"입니다.

대응 3순위: 근거를 표시하게 한다 (검증 가능화)

16장 원칙 3과 연결됩니다. "각 주장의 근거를 자료에서 인용하라"고 요구하면, 모델이 근거 없는 주장을 만들기 어려워집니다. 동시에 사람이 검증하기도 쉬워집니다.

✅
"각 사실 진술 뒤에 근거가 된 자료 문장을 인용해줘.
인용할 근거가 없으면 그 진술을 빼."

"근거를 못 대면 빼라"는 한 줄이, 모델 스스로 검열하게 만드는 장치입니다.

대응 4순위: 검증 질문을 덧붙인다

답을 낸 뒤 모델에게 자기 답을 점검하게 하는 방법입니다(5부 자기 비판과 연결). 완벽하진 않지만, 명백한 오류를 걸러내는 데 도움이 됩니다.

✅
"답을 작성한 뒤, 각 주장이 자료로 뒷받침되는지 스스로 점검하고
근거가 약한 부분을 표시해줘."

⚠️ 흔한 실수·미신: "모델에게 한 번 더 확인시키면 환각이 사라진다"는 과신입니다. 모델은 자기 환각을 자신 있게 재확인할 수도 있습니다(틀린 전제 위에서 점검하므로). 자기 점검은 보조 수단이지 최종 보증이 아닙니다.

특히 환각이 잦은 영역 — 경계하기

🧪 직접 검증법: 모델이 인용·수치를 댈 때, 그것이 진짜인지 독립적으로 확인하세요. 특히 "OO 연구에 따르면", "통계청 자료에 의하면" 같은 권위 있는 표현일수록 더 의심하세요. 그럴듯한 포장이 곧 사실은 아닙니다.

환각은 0이 되지 않는다 — 검증으로 대비

냉정한 현실: 위 기법들은 환각의 빈도를 낮추지만 완전히 없애지는 못합니다. "그럴듯함을 잇는다"는 본질에서 오는 현상이라, 프롬프트만으로 0%를 보장할 수 없습니다.

그러니 결과를 검증하는 절차를 설계의 일부로 두세요. 특히 틀리면 손해가 큰 작업(법률·의료·금융·공개 발행물)에서는 사람의 검토나 외부 도구 확인을 반드시 거치게 하세요.

🔧 개발자 노트: 시스템 레벨에서는 여러 방어선을 겹칩니다 — ① RAG로 근거 자료 제공(16장), ② 출력에서 인용을 강제하고 인용이 실제 원문과 일치하는지 자동 대조, ③ 사실 주장을 외부 도구·검색으로 교차 확인(5부 도구 결합), ④ 위험 도메인은 사람 검토(human-in-the-loop). 어느 하나도 단독으로 완벽하지 않으므로 겹쳐 쓰는 것이 핵심입니다. 또한 환각률은 모델·작업마다 다르니, 4부 마지막의 평가(eval)로 측정하며 관리하세요.

이 장에서 배운 것

• 환각은 모델이 사실이 아닌 내용을 그럴듯하고 자신 있게 만드는 현상으로, "그럴듯함을 잇는다"는 본질의 부작용이다.
• 대응 우선순위: ① 근거 자료 제공(빈칸 없애기), ② "모르면 모른다" 허용, ③ 근거 인용 요구, ④ 자기 점검(보조 수단).
• "모른다 허용"은 포괄적 금지가 아니라 "자료 밖 사실은 지어내지 마"처럼 범위를 한정한 형태가 안전하다.
• 수치·인용·최신 사실·전문 정보 영역은 특히 환각이 잦으니 독립 검증한다.
• 환각은 0이 되지 않으므로 검증 절차를 설계에 포함하고, 위험 작업은 사람·도구 확인을 거친다.

✍️ 확인 문제

1. 모델이 존재하지 않는 논문을 그럴듯하게 인용하는 이유를, 2장의 "다음 토큰 예측"과 이 장의 "빈칸 채우기"로 설명해보세요.

1. "절대 틀리지 마, 모르는 건 없어"라는 지시가 환각을 줄이기는커녕 늘릴 수 있는 이유를 설명하고, 더 나은 지시로 바꿔보세요.

1. (실습) 사내 규정으로 직원 질문에 답하는 봇에서 환각을 줄이려 합니다. 이 장의 대응 1~3순위를 모두 반영한 프롬프트를 작성하고, 그래도 남는 위험을 어떻게 검증할지 적어보세요.

다음 → 19. 모호함과 과잉생성 다루기
이전 ← 17. 컨텍스트 엔지니어링 실전 사고법 · 목차