환각(Hallucination) 다루기

환각(hallucination)은 LLM을 다룰 때 늘 따라오는 걱정이고, 잘 설계된 RAG도 여전히 환각을 낸다. 그래서 환각을 탐지·감소시키고 출처를 정확히 인용하게 만드는 일이 RAG 파이프라인에서 가장 중요한 부분이다. 이번 편은 그 방법들을 정리한다.

 

 

1. 환각은 어떻게 일어나는가

온라인 쇼핑몰의 고객 응대 챗봇을 상상해 보자. 사용자가 "학생 할인 있나요?"라고 묻는다. retriever는 시니어·신규 고객 10% 할인 정보를 찾아 오고, 시스템 프롬프트는 LLM에게 "고객에게 친절하라"고 한다. 이 요인들이 겹쳐 LLM은 "물론이죠, 학생증만 있으면 10% 할인됩니다"라고 답한다. 문제는 — 학생 할인은 존재하지 않는다. LLM이 지어낸 것이다.

그림 1. 환각 예시 — retriever·시스템 프롬프트의 영향으로 LLM이 없는 학생 할인을 지어낸다.

 

이유를 기억해야 한다. LLM은 확률 높은 텍스트 시퀀스를 (약간의 무작위와 함께) 생성하도록 설계됐다. 확률 높은 문장이 대개 사실이지만 항상은 아니다. 언어 모델은 참/거짓을 구분하도록 만들어지지 않았다 — 그저 그럴듯함/그럴듯하지 않음을 구분할 뿐이다.

그림 2. LLM은 "확률 높은 텍스트"를 만들 뿐, 참·거짓을 구분하도록 설계되지 않았다.

 

 

 

2. 왜 문제인가

환각이 문제인 이유는 셋이다. 첫째, 당연히 부정확한 정보를 사용자에게 주면 안 된다. 둘째, 환각은 거의 정의상 그럴듯하게 들려서 완전한 헛소리보다 오히려 탐지가 어렵다. 셋째, 대부분의 내용이 정확해도 가끔의 환각이 시간이 지나며 시스템에 대한 신뢰를 무너뜨린다. RAG를 만드는 큰 이유 자체가 환각을 줄이기 위함이다 — 검색된 정보가 답을 근거화하고 학습에 없던 정보를 보완한다. 그래도 RAG는 환각을 완전히 막지 못하므로 추가 조치가 필요하다.

그림 3. 환각은 부정확하고 그럴듯해 탐지가 어렵고 신뢰를 깎는다. RAG가 도움이 되지만 완전하진 않다.

 

 

 

3. 환각의 유형

환각은 크기·종류가 다양하다. 할인 예시로 보면 — 실제 시니어 할인을 정확히 설명하되 10%를 5%로 잘못 말하거나(작은 오류), 더 심하게는 있는 시니어 할인을 없다고 하거나, 앞서처럼 없는 할인을 완전히 지어낼 수 있다. 그래서 정확도를 확신하려면 LLM 출력을 여러 수준에서 평가해야 한다.

그림 4. 환각 유형 — 세부 오류, 사실 부정, 완전한 날조. 여러 수준에서 평가가 필요하다.

 

 

 

4. 완벽한 해법은 없다 — self-consistency

냉정한 진실은, 현재로선 환각에 완벽한 해법이 없다. 다만 RAG는 지금 쓸 수 있는 최선의 접근 중 하나이고, 빈도를 더 낮출 방법들이 있다. 우선 knowledge base가 없다면 어떻게 탐지할지 생각해 보자 — 비교할 신뢰 가능한 외부 진실이 없으면 선택지가 적다. 한 방법이 self-consistency(자기 일관성) 체크다 — 같은 프롬프트로 여러 번 생성해 담긴 사실이 일관되는지 본다. 환각이면 비일관적으로 나올 것이라는 발상이다. 실제로는 비싸고 신뢰성이 낮다.

그림 5. 환각에 완벽한 해법은 (아직) 없다 — 그래도 RAG가 가장 효과적인 출발점이다.

그림 6. Self-consistency — 같은 프롬프트를 반복 생성해 사실 불일치를 탐지(비싸고 불안정).

 

 

 

5. 근거화 — 검색 정보에 답을 묶기

RAG에는 knowledge base가 있으므로, 환각을 줄이는 최선은 응답을 검색된 정보에 근거화(grounding)하는 것이다. 예를 들어 시스템 프롬프트를 고쳐 "검색된 정보에 근거해서만 사실 주장을 하라"고 명시할 수 있다.

그림 7. 근거화 — 시스템 프롬프트로 "검색 정보에 근거해서만 답하라"고 강제하면 환각이 줄어든다.

 

 

 

6. 출처 인용 (Citation)

더 확신하고 싶으면 LLM에게 출처를 인용하게 한다. 문장·문단 끝마다 출처를 달게 하는 것만으로도 응답을 검색 문서에 근거화할 가능성이 높아지고, 독자가 주장을 검증하기도 쉬워진다. 다만 위험은 LLM이 인용마저 지어낼 수 있다는 것 — 인용용으로 파인튜닝된 모델은 유효 인용을 더 안정적으로 낸다.

그림 8. 출처 인용 — 근거화·검증을 돕지만, 모델이 인용 자체를 환각할 위험이 있다.

 

인용을 더 신뢰하려면 외부 시스템이 필요하다. 예로 ContextCite는 응답이 출처에 얼마나 근거하는지 점수화한다 — 응답을 문장 단위로 처리해 각 문장을 검색된 문서 중 하나에 귀속시키고 태그를 단다. 뒷받침 근거가 없으면 no source로 표시하고, 문장↔출처 유사도 점수를 주기도 한다. 이 태그는 최종 출력의 인용 생성에도, "얼마나 자주 근거화하는지" 평가에도 쓸 수 있다.

그림 9. ContextCite — 문장 단위로 출처 문서에 귀속·태깅하고, 근거 없으면 no source로 표시한다.

 

 

 

7. 인용 품질 평가 — ALCE

최근에는 ALCE 벤치마크처럼 시스템이 출처를 얼마나 잘 참조·인용하는지 측정하려는 노력도 있다. 미리 구성된 knowledge base와 예시 질문을 제공하고, 내 RAG로 그 프롬프트에 답하게 한 뒤 ALCE가 응답을 평가한다. fluency(유창성)·correctness(정확성)·citation quality(인용 품질) 세 지표로 점수를 낸다 — 텍스트가 얼마나 명료한지, 사실이 얼마나 맞는지, 인용이 올바른 출처와 얼마나 정합하는지다. 이런 벤치마크가 프로덕션의 환각을 직접 막진 못하지만, 시스템이 얼마나 잘 환각을 피하고 인용하는지 감을 준다.

그림 10. ALCE — fluency·correctness·citation quality로 인용·근거화 품질을 평가한다.

 

접근 정리. ① RAG를 만드는 것 자체가 환각을 줄이는 가장 효과적인 한 걸음이다. ② 그다음 시스템 프롬프트를 다듬어 답을 검색 정보에 근거화한다. ③ 마지막으로 환각 중심 벤치마크로 근거화·인용 품질을 테스트한다. 이 조합이 환각을 크게 줄이고 신뢰할 수 있는 시스템을 만든다.

 

다음 글에서는 LLM 단계의 성능을 정량적으로 재는 법 — RAGAS 기반 LLM 평가(Response Relevancy·Faithfulness 등) — 를 다룬다.