RAG는 hallucination을 줄이지만 없애지는 못한다. “모델이 외운 지식으로 답하지 말고 retrieval한 문서를 근거로 답하라”는 제약을 걸면 틀린 답은 분명히 줄지만, 검색이 빗나가거나 모델이 가져온 문서를 잘못 읽는 순간 hallucination은 자리만 옮겨 다시 나타난다[1].
RAG를 production에 붙여본 사람이면 겪는 장면이 있다. 답이 틀렸는데 어디서 틀렸는지를 모른다. retriever가 필요한 문서를 못 가져온 건지, 가져왔는데 모델이 안 쓰거나 잘못 읽은 건지. 정답 여부 하나로만 보면 이 둘이 한 덩어리로 뭉개진다. RAG를 “검색만 잘하면 끝나는 스위치”로 생각하면 이 지점에서 막힌다. 나는 RAG를 retrieval → generation → verification 으로 이어지는 파이프라인으로 보고, 각 단계에서 hallucination이 어떻게 생기고 어디서 막히는지를 따로 떼어 정리했다.
왜 RAG를 붙여도 hallucination이 생기나
RAG가 완벽한 해법이 아닌 이유는 크게 세 가지다.
| 원인 | 무슨 일이 일어나나 |
|---|---|
| retrieval 실패 | 엉뚱한 문서가 걸리거나, 정작 필요한 문서가 빠진다 |
| context 과부하 | 문서를 한꺼번에 너무 많이 넣어 모델이 핵심을 놓친다 |
| generation 단계 오류 | 올바른 문서를 줬는데 모델이 잘못 읽거나 변형한다 |
세 줄이 한 결론으로 모인다. retrieval을 잘해도 그다음이 남는다. 검색된 문서를 모델이 어떻게 다루는지까지 설계해야 답이 근거 위에 선다.
실패를 네 가지 유형으로 나눠보면
채점할 때 “틀렸다” 한마디로 끝내면 고칠 자리가 안 보인다. 나는 RAG hallucination을 네 가지로 갈라 본다.
유형 1 — fabrication(소스 미참조): retrieval한 문서에 없는 정보를 모델이 지어낸다. 가장 위험하다. 검색 결과에 가격이 없는데 그럴듯한 숫자를 답에 박아 넣는 식이다.
유형 2 — misattribution(소스 왜곡): 가져온 문서를 잘못 해석하거나 서로 다른 소스의 정보를 섞는다. 한 출처의 수치를 다른 맥락에 붙여 엉뚱한 결론을 낸다.
유형 3 — context drift(맥락 이탈): 문서 자체는 맞지만 질문 맥락과 무관한 부분을 인용한다. “올해 가격”을 물었는데 몇 년 전 데이터를 끌어다 쓴다.
유형 4 — over-generalization(과도한 일반화): 특정 조건에서만 성립하는 사실을 보편 진리처럼 내민다. 한 업종에 한정된 결론을 산업 전체로 늘린다. hallucination survey들은 이 유형이 모델과 도메인을 가리지 않고 반복된다고 짚는다[2].
네 가지가 각각 다른 단계에서 생긴다는 게 핵심이다. fabrication은 generation 단계에서, context drift는 retrieval이 애매할 때, over-generalization은 모델의 서술 습관에서 온다. 유형을 갈라 두면 “답이 틀렸다”가 “어느 단계를 고쳐야 한다”로 바뀐다.
방어는 한 겹이 아니다
막는 법도 단계별로 겹을 쌓는다.
1. retrieval 품질부터
올바른 문서가 검색되게 만드는 게 첫 겹이다. 질문을 검색에 맞게 바꾸는 query rewriting, keyword search와 semantic search를 같이 쓰는 hybrid search, relevance score threshold로 걸러내는 filtering이 기본 도구다.
2. 소스를 신뢰도로 계층화
모든 소스를 동등하게 두면 안 된다. E-E-A-T와 비슷하게 소스에 tier를 매긴다.
| Tier | 정의 | 예시 |
|---|---|---|
| Tier 1 | 공식 문서, 학술 논문 | 공식 가이드 문서, 학술 논문 |
| Tier 2 | 업계 미디어, 리서치 기관 | 전문 매체, 리서치 리포트 |
| Tier 3 | 커뮤니티, 개인 블로그 | 커뮤니티 글, 개인 사이트 |
Tier 1을 먼저 인용하고 Tier 3은 보조 참고로만 쓰라고 prompt에 박아 둔다. 근거와 출처를 구조화해 분명히 드러낸 페이지일수록 신뢰할 소스로 분류되기 쉽다[3].
3. generation 뒤 검증
모델이 답을 낸 뒤 별도 검증 단계를 둔다.
| 검증 항목 | 방법 |
|---|---|
| 수치 정확성 | 답의 숫자를 소스 문서와 대조 |
| 인용 일치 | 각주로 인용한 내용이 실제 그 출처에 있는지 확인 |
| 시점 일관성 | 답의 시점이 소스 문서의 시점과 맞는지 확인 |
| 논리 일관성 | 답 안의 주장들끼리 모순이 없는지 확인 |
4. grounding prompt
“retrieval한 문서에 없으면 답하지 마라”를 명시적으로 지시하는 것도 중요한 방어선이다.
규칙:
1. 제공된 소스 문서에 근거가 있는 정보만 사용한다
2. 소스에 없는 수치나 데이터를 지어내지 않는다
3. 확실하지 않은 정보는 "확인되지 않은 정보"라고 표시한다
4. 여러 소스가 상충하면 Tier가 높은 소스를 우선한다
5. 불확실성 표시 강제
확신이 낮은 답에는 모델이 불확실성을 드러내게 한다. “…로 알려져 있다”, “…일 수 있다” 같은 표현을 쓰게 하면 사용자가 사실과 추정을 가른다.
파이프라인 어디에 검증을 끼우나
AI로 초안을 만드는 파이프라인이라면 검증을 이 순서로 넣는 게 실무적이다.
- AI가 초안을 생성한다.
- inline citation과 참고 자료를 대조한다.
- 수치·통계가 원본 소스에 실제로 있는지 확인한다.
- Tier 1 소스가 최소 한두 개 들어갔는지 본다.
검증 자동화가 멈추는 자리
검증을 전부 자동화할 수는 없다. 자동화 가능 범위를 나눠 보면 선이 분명하다.
| 항목 | 자동화 |
|---|---|
| 수치 대조 | 소스 문서 검색 + 비교로 가능 |
| 인용 형식 | regex 검증으로 가능 |
| 논리 일관성 | 기본 모순 탐지는 가능, 미묘한 오류는 사람 필요 |
| 맥락 적합성 | 전문가 검토 필요 |
| 최신성 확인 | 날짜 비교는 가능하지만 맥락 판단은 사람 필요 |
자동 검증이 기본 오류를 걸러내고 사람이 맥락 판단을 보태는 hybrid가 가장 현실적이다.
내가 RAG를 짠다면
여기부터는 내 결론이다. RAG를 붙일 때 나는 세 가지를 먼저 정한다.
첫째, 정답 여부 하나로 채점하지 않는다. 답과 함께 근거(어느 문서·어느 줄)를 내게 하면 retriever 실패와 reader 실패가 갈라져서 어느 쪽을 고칠지가 보인다. lab에서 한 번 맞히는 것과 매일 돌아가는 것의 차이는 늘 이 지점에서 난다.
둘째, retrieval을 generation보다 먼저 의심한다. 모델을 더 좋은 걸로 바꾸는 건 reading 쪽을 만지는 일인데, 필요한 문서가 애초에 안 들어왔으면 답의 상한선은 그 앞에서 이미 잘려 있다. multi-fact 질문이 많은 도메인이면 모델 교체보다 recall부터 올리는 게 더 움직인다.
셋째, 사람 검토를 없애는 게 아니라 둘 자리를 정한다. 수치·인용 형식은 자동으로 거르고 맥락 적합성과 미묘한 논리는 사람이 본다. 자동화의 목적은 사람을 빼는 게 아니라 사람이 봐야 할 것만 남기는 거다.
RAG는 hallucination을 크게 줄이는 좋은 출발점이지만 출발점일 뿐이다. retrieval·generation·verification을 한 파이프라인으로 설계했을 때에야 믿고 쓸 수 있는 답이 나온다.
