대부분의 프로덕션 RAG 앱은 자신 있게 틀린 답을 내놓는데, 아무도 이 문제를 충분히 다루지 않음
Most RAG apps in production are confidently wrong and nobody talks about this enough
핵심 요약
RAG 시스템의 환각과 버전 관리 문제를 해결하기 위해 라우팅, 검색 점수 산정, 환각 체크 등 아키텍처 개선이 필수적임.
- RAG 실패 모드 — 버전이 다른 문서를 구분하지 못하고 혼합하여 자신 있게 잘못된 답변을 생성함.
- 라우팅 레이어 — 검색이 필요한 질문인지 먼저 판단하여 불필요한 토큰 낭비를 방지함.
- 검색 점수 산정 — 모델에 전달하기 전 컨텍스트 품질을 평가하여 저품질 데이터 생성을 차단함.
- 환각 체크 — 생성된 답변과 원본 문서를 비교하여 사실 여부를 검증하는 추가 LLM 호출이 필요함.
내부 도구, 지원 봇, 문서 Q&A, 계약서 검색 등에 RAG를 통합하는 여러 팀과 작업해 왔는데, 튜토리얼을 따라 할 때는 아무도 경고해주지 않는 똑같은 문제에 계속 부딪히고 있습니다.
기본적인 검색 후 생성(retrieve-then-generate) 파이프라인은 데모에서는 괜찮아 보입니다. 깔끔한 질문, 깔끔한 문서, 깔끔한 답변이죠. 그러다 실제 사용자들이 나타납니다.
저를 괴롭히는 실패 모드는 이겁니다: 시스템이 동일한 정책 문서의 다른 버전에서 청크를 가져오는데, 그것들이 다른 버전이라는 것을 알 방법이 없어서 그냥 섞어버리고는 아주 자신 있게 답변을 내놓습니다. 주의 사항도 없고, "잘 모르겠어요"라는 말도 없습니다. 그냥 유창하게 틀린 답을 내놓는 거죠.
더 깊은 문제는 표준 RAG에는 불확실성을 처리할 메커니즘이 없다는 것입니다. 검색하고, 생성하고, 그냥 넘어갑니다. 정답을 맞혔든 완전히 그럴듯한 거짓말을 지어냈든 똑같은 자신감 수준을 보이죠.
실제로 문제를 해결하는 것은(적어도 제가 작업한 시스템에서는) 모델을 바꾸는 게 아닙니다. 아키텍처를 바꾸는 거죠.
A routing layer — 호출을 하기 전에 검색이 정말 필요한지 결정하세요. 어떤 질문은 검색이 필요 없는데 토큰만 낭비하고 있는 겁니다.
Retrieval scoring — 모델에 전달하기 전에 검색된 내용을 평가하세요. 컨텍스트 점수가 낮으면 그냥 쓰레기 같은 답변을 생성하는 대신, 질문을 재구성하고 다시 시도하세요.
A hallucination check — 생성된 답변과 검색된 문서를 모두 읽고 모든 주장이 실제로 근거가 있는지 확인하는 두 번째 LLM 호출을 하세요. 대부분의 팀이 이걸 안 하고 있는데, 아마 가장 높은 ROI를 가져다줄 추가 작업일 겁니다.
재시도 루프는 특히 도움이 됐는데, 사용자는 임베딩 모델이 예상하는 방식으로 질문하지 않기 때문입니다. 시스템이 조용히 질문을 재구성하고 다시 시도하면, 사용자는 그런 일이 일어났는지조차 모릅니다.
이런 것들은 전혀 특별한 게 아닙니다. 파이프라인에 몇 가지 결정 지점을 추가하는 것뿐이죠. 하지만 만약 여러분이 프로덕션에서 일반 RAG를 돌리고 있는데 왜 사용자들이 신뢰를 잃어가는지 궁금하다면, 거의 확실히 이 이유 때문일 겁니다.
혹시 버전 관리나 컨텍스트 혼합 문제에 대해 구체적으로 겪어본 분 계신가요? 그 부분은 잘 알려지지 않은 것 같아서요.
