주요 기사 요약
ICLR 2025에 발표된 최신 연구에 따르면, RAG를 도입한 시스템도 여전히 35-62%의 확률로 틀린 답변을 제공하고 있다. 더 충격적인 것은 RAG를 적용하면 오히려 LLM의 “모르겠습니다”라는 기권율이 감소한다는 사실이다. Claude 3.5 Sonnet은 RAG 없이 84.1%를 기권했지만, RAG 적용 후 52%로 떨어졌다. 구글 연구팀은 이 문제를 “충분한 맥락(Sufficient Context)”과 “선택적 생성(Selective Generation)” 개념으로 해결하려 하고 있다. 많은 개발자들이 RAG가 hallucination을 완벽히 해결할 것으로 기대했지만, 실제로는 새로운 형태의 hallucination을 만들어낸다는 게 명확해졌다.
RAG를 도입했는데도 거짓말을 한다
처음에 이 문제를 발견했을 때 충격이 컸다.
우리는 RAG를 도입하면서 확신했다. “이제 hallucination 문제는 해결될 거야.”
논리는 단순했다.
“벡터 DB에서 정답을 검색해서 전달하면, LLM은 그 정보를 기반으로 답변할 테니까.”
마치 학생에게 참고자료를 주고 시험을 보도록 하면 틀릴 확률이 줄어들 것처럼.
하지만 현실은 달랐다.
테스트 결과, 우리의 RAG 시스템은 벡터 DB에 정답이 분명히 있는데도 틀린 답변을 생성했다.
예를 들어:
사용자: “우리 회사의 2024년 4분기 매출은?” 벡터 DB: “Q4 2024: $125M revenue, up 20% YoY” (명확한 정보) LLM: “2024년 4분기 매출은 약 150만 달러 정도로 추정됩니다” (완전한 거짓)
정보가 있는데 왜 다른 답변을 만들어낼까?
처음엔 “프롬프트가 잘못됐나?” “청킹이 문제인가?” “임베딩 모델이 약한 건가?”라고 생각했다.
하지만 ICLR 2025 연구를 읽으니 진짜 문제가 뭔지 알게 됐다.
우리가 RAG를 잘못 이해했다는 뜻이었다.
RAG는 “정보 전달”이지, “hallucination 완벽 해결”이 아니다
먼저 수치를 정확히 이해해야 한다.
연구팀이 분석한 결과:
GPT-4o:
- 정보 충분: 34.4% 기권 → RAG 적용 후 31.2% 기권 (2.2% 개선)
- 하지만 틀린 답변은 35-40% 정도
Claude 3.5 Sonnet:
- 정보 충분: 84.1% 기권 → RAG 적용 후 52% 기권 (32.1% 감소)
- 이건 “개선”이 아니라 “폭탄”이다
Gemini 1.5 Pro:
- 정보 충분: 100% 기권 → RAG 적용 후 18.6% 기권 (81.4% 감소)
- 거의 모든 경우 답변을 시도한다는 뜻
여기서 핵심은 이거다.
“RAG를 적용하니까 LLM이 더 자신감 있게 말하기 시작했다. 비록 틀린 말이더라도.”
RAG가 오히려 hallucination을 악화시키는 이유
1. “정보가 있다”는 착각
LLM 입장에서 보면, 벡터 DB에서 검색된 텍스트가 컨텍스트에 들어오는 순간 “아, 이 정보는 근거가 있는 정보다”라고 인식한다.
그런데 여기서 미묘한 문제가 생긴다.
검색된 정보가 50% 정확하거나 부분적이라도, LLM은 그걸 “충분한 정보”로 본다.
예:
- 벡터 DB: “Q4 매출 성장률이 높았다” (정보 불완전)
- LLM의 생각: “좋아, 성장 정보가 있네. 그럼 구체적인 숫자를 추론해볼까”
- 결과: 아예 근거 없는 숫자를 생성
2. 검색 결과 오해석
RAG는 “정보를 가져온다”는 건 잘하지만, “그 정보를 제대로 이해한다”는 보장은 없다.
예:
- 검색된 문서: “매출은 Q3 150M에서 Q4 170M으로 증가했다”
- LLM의 이해: “아, Q4가 170이구나. 그럼 다른 분기도 비슷한 수준이겠지?”
- 결과: Q1, Q2도 170M 정도라고 주장 (완전한 거짓)
3. 컨텍스트 윈도우의 덫
현대 LLM들은 엄청나게 긴 컨텍스트를 처리할 수 있다. Claude 3.5라면 200K 토큰도 가능하다.
그래서 우리는 생각했다. “그럼 더 많은 문서를 전달하면 정확도가 올라가겠지?”
현실: 많을수록 더 헷갈린다.
벡터 DB에서 10개의 문서를 검색했는데, 7개는 관련 있고, 3개는 약간 다른 주제라면?
LLM은 그 9번째 문서에서만 정답이 있다는 걸 어떻게 알겠는가?
결국 중간중간 모순되는 정보들을 자신의 “상상”으로 채우기 시작한다.
4. “모르겠습니다”라는 선택지 제거
가장 충격적인 발견이다.
RAG가 없을 때: LLM은 “저는 이 정보를 모릅니다”라고 기권하는 경향이 높다 RAG를 적용할 때: LLM은 “아, 정보가 있네. 그럼 답변을 만들어야지”라고 생각한다
결과적으로 정확한 기권이 줄어들고, 부정확한 답변이 늘어난다.
이건 “개선”이 아니라 “다른 형태의 악화”다.
내가 놓친 RAG의 5가지 한계
1. 검색어 생성이 완벽하지 않다
사용자: “최근 한국 영화의 경향은?” LLM의 검색어: “한국 영화” (너무 일반적) 결과: 영화 역사만 검색, 최신 경향은 못 찾음
이건 LLM의 이해력 부족 때문이다.
2. 임베딩 모델의 신뢰도
벡터 DB는 임베딩 모델에 전적으로 의존한다.
한국어의 경우, 대부분의 임베딩 모델의 신뢰도가 높지 않다고 알려져 있다.
“유사도를 고려하여 벡터를 잘 배치했는가?”라는 기준으로 평가할 때, 현재 한국어 임베딩 성능은 여전히 부족하다.
3. 청킹 방식의 영향
문서를 어떻게 나누느냐가 중요하다.
512 토큰으로 나누면 너무 작아서 맥락이 끊기고, 2000 토큰으로 나누면 너무 커서 노이즈가 많다.
우리는 이 최적점을 찾기 위해 6개월을 보냈다.
4. K 값의 딜레마
상위 K개의 문서를 검색한다고 할 때, K=3이면 정답이 없을 수 있고, K=20이면 노이즈가 많다.
이 사이의 균형을 찾기는 정말 어렵다.
5. 프롬프트 엔지니어링의 한계
아무리 좋은 프롬프트를 쓰더라도, LLM이 “제공된 정보만 사용하세요”라는 지시를 100% 따르지는 않는다.
특히 검색 결과가 불완전할 때, LLM은 자신의 학습 데이터로 “보충”하려 한다.
그럼 hallucination을 줄이려면?
1단계: 기대치를 조정하자
RAG가 hallucination을 “완벽히 해결”한다고 생각하지 말자.
RAG는 기껏해야 10-15% 정도만 개선한다는 게 현실이다.
2단계: Reranking을 추가하자
임베딩만으로는 부족하다. 검색 결과를 다시 한 번 평가하는 과정이 필요하다.
Cohere의 rerank 모델 같은 걸 사용하면, BM25 같은 키워드 매칭과 함께 스코어를 매길 수 있다.
실제로 reranking을 추가하니까 정확도가 15% 정도 올라갔다.
3단계: Self-Verification을 구현하자
LLM 자신이 생성한 답변이 신뢰할 만한지 검증하도록 한다.
방법은 간단하다. 답변을 생성한 후 다시 한번 묻는다.
“당신의 답변에서 언급한 매출 수치 170M이 어디서 나온 정보인가요?”
만약 LLM이 “벡터 DB 문서 #7에서”라고 명확히 답할 수 있다면, 그 답변은 신뢰도가 높다.
만약 “음… 일반적인 시장 추세로 봤을 때”라고 답한다면, hallucination 가능성이 높다.
4단계: Agentic RAG 고려
단순히 “문서 검색 → LLM 생성”이 아니라, 여러 번 왕복하는 방식도 있다.
첫 번째 검색 결과를 본 후 “추가로 이 정보도 필요해”라고 판단하면, 다시 검색한다.
이렇게 하면 맥락이 점차 정확해진다.
5단계: 위험도에 따른 대응
금융 정보처럼 정확성이 극도로 중요한 경우, hallucination을 “예방”하는 게 아니라 “탐지”해야 한다.
LLM의 답변과 벡터 DB의 정보를 자동으로 비교하는 단계를 넣어야 한다.
“매출 170M”이라는 답변이 나오면, 벡터 DB에 정말 그런 정보가 있는지 확인하는 거다.
결론: RAG는 은탄환이 아니다
RAG는 훌륭한 기술이다. 최신 정보를 반영할 수 있고, 출처를 명시할 수 있다.
하지만 hallucination을 “완벽히 해결”하는 기술은 아니다.
오히려 RAG를 잘못 이해하고 사용하면, 더 교활한 hallucination을 만들 수 있다.
“정보가 있으니까 답변이 맞을 거야”라는 착각이 그렇다.
우리가 배운 교훈:
- RAG는 “정보 전달 도구”다. “hallucination 제거 도구”가 아니다
- 검색이 정확해도, LLM의 이해가 정확하지 않으면 소용없다
- “모르겠습니다”라는 기권도 때론 정답이다
- Reranking, Self-Verification, Agentic RAG 등 추가 기법이 필수다
- 100% 정확도는 불가능하다. 현실적인 목표치는 85% 정도다
다음번 RAG 프로젝트를 할 때는, 더 현실적인 기대를 가지고 시작할 것 같다.