LLM을 실제로 써 보면 가장 불편한 순간 중 하나는 아주 그럴듯하게 말하지만 사실은 틀린 답을 할 때입니다. 이 현상을 보통 hallucination이라고 부릅니다.
문제는 이런 답이 틀렸다는 티를 덜 낼 때가 많다는 점입니다. 그래서 AI를 제품이나 업무 흐름에 넣으려면 hallucination을 어떻게 줄일지가 매우 중요해집니다.
이 글에서는 아래 내용을 정리합니다.
- hallucination이 왜 생기는지
- 어떤 방식으로 줄일 수 있는지
- 프롬프트, RAG, 검증이 각각 어떤 역할을 하는지
핵심은 hallucination은 완전히 없애기보다, 근거를 더 붙이고 출력 범위를 좁히고 검증 단계를 넣어서 줄이는 문제가 더 많다는 점입니다.
AI hallucination 이란 무엇인가
hallucination은 모델이 사실과 다른 내용을 그럴듯하게 생성하는 현상을 말합니다. 완전히 엉뚱한 내용일 수도 있고, 일부는 맞고 일부만 틀릴 수도 있습니다.
특히 아래 상황에서 더 문제처럼 보입니다.
- 존재하지 않는 출처를 말한다
- 내부 문서를 안 봤는데 본 것처럼 답한다
- 최신 정보가 아닌데 최신인 것처럼 답한다
즉, hallucination은 단순 오타보다 “근거 없는 자신감 있는 출력” 쪽에 더 가깝습니다.
왜 hallucination이 생길까
LLM은 본질적으로 다음 토큰을 예측하는 생성 모델입니다. 그래서 모르면 멈추는 대신, 문맥상 그럴듯한 답을 이어 갈 수 있습니다.
특히 아래 상황에서 잘 나타납니다.
- 질문이 모호하다
- 필요한 정보가 모델 안에 없다
- 외부 근거 없이 답해야 한다
- 출력 형식 제약이 약하다
즉, “모를 때 안전하게 멈추기”보다 “그럴듯하게 이어가기” 쪽이 기본 동작에 더 가깝기 때문에 생기는 문제입니다.
hallucination 을 줄이는 가장 기본적인 방법
1. 프롬프트에서 추측 금지 조건 넣기
예:
- 모르면 모른다고 말하라
- 제공된 문서에 없는 내용은 추측하지 마라
- 확실하지 않으면 불확실하다고 표시하라
이런 제약은 완벽하지 않지만 기본 안전장치로 유용합니다.
2. RAG로 근거 문서 붙이기
외부 문서를 함께 주면 모델이 완전히 기억에만 의존하지 않아도 됩니다. 그래서 hallucination을 줄이는 가장 흔한 구조적 방법 중 하나가 RAG입니다.
3. 출력 형식을 좁히기
자유 서술보다:
- 표
- JSON
- 선택지
- 근거 포함 응답
같이 형식을 제한하면 답변이 더 통제되기 쉽습니다.
4. 후처리 검증 넣기
중요한 시스템에서는 생성 직후 결과를:
- 규칙 검증
- 스키마 검증
- 출처 유무 확인
- human review
같은 단계로 다시 확인하기도 합니다.
RAG가 왜 특히 자주 언급될까
hallucination의 많은 경우는 “모델이 필요한 근거 없이 대답해야 하는 상황”에서 커집니다. RAG는 관련 문서를 먼저 찾아 넣기 때문에 이 문제를 꽤 직접적으로 완화합니다.
즉, hallucination을 줄이는 실무적 접근에서는:
- 프롬프트
- RAG
- 출력 검증
세 가지가 자주 함께 나옵니다.
완전히 없앨 수는 있을까
대부분의 경우 완전히 없애기보다 허용 가능한 수준으로 줄이는 목표가 더 현실적입니다.
그래서 실제 시스템에서는:
- 중요도 높은 질문만 별도 검토
- 근거 없는 응답은 차단
- 고위험 영역은 human-in-the-loop
같은 안전장치를 조합합니다.
자주 하는 오해
1. temperature를 낮추면 hallucination이 완전히 사라진다
줄어들 수는 있지만, 근거 부족 문제 자체가 사라지는 것은 아닙니다.
2. 모델이 크면 hallucination이 없다
큰 모델도 여전히 그럴듯한 잘못된 출력을 만들 수 있습니다.
3. 프롬프트 한 줄로 해결할 수 있다
일부 도움은 되지만, 구조적 문제는 RAG나 검증 계층이 더 중요할 수 있습니다.
FAQ
Q. hallucination이 심하면 무조건 파인튜닝해야 하나요?
그렇지 않습니다. 많은 경우 RAG와 검증 구조가 먼저일 수 있습니다.
Q. 근거를 항상 함께 보여주면 도움이 되나요?
대체로 그렇습니다. 사용자도 답의 신뢰도를 더 판단하기 쉬워집니다.
Q. 작은 프로젝트도 hallucination을 신경 써야 하나요?
질문 성격에 따라 다르지만, 사용자에게 사실처럼 보이는 출력이라면 초반부터 의식하는 편이 좋습니다.
Read Next
- 근거 문서를 붙이는 구조는 RAG 가이드를 같이 보세요.
- 어떤 문제를 RAG로 풀고 어떤 문제를 파인튜닝으로 볼지는 파인튜닝 vs RAG 가이드에서 이어집니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.