프로덕션 환경의 대부분의 RAG 앱은 당당하게 틀린 답을 내놓는데, 아무도 이 문제를 충분히 다루지 않음
Most RAG apps in production are confidently wrong and nobody talks about this enough
핵심 요약
RAG 시스템이 버전이 다른 문서를 혼동해 자신 있게 오답을 생성하는 문제를 지적하고, 이를 해결할 아키텍처 개선 방안을 제시합니다.
- RAG의 한계 — 검색된 문서의 버전 차이를 구분하지 못하고 자신 있게 잘못된 답변을 생성함
- 아키텍처 개선 — 라우팅 레이어와 검색 점수 평가를 통해 불필요한 호출을 줄이고 정확도를 높임
- 환각 방지 — 생성된 답변과 검색된 문서를 대조하는 검증 단계를 추가하여 신뢰성을 확보함
- 재시도 루프 — 사용자의 질문을 임베딩 모델에 맞게 재구성하여 검색 성공률을 높임
사내 툴, 고객 지원 봇, 문서 Q&A, 계약서 검색 같은 데 RAG 도입하는 팀들 몇 군데랑 같이 일해봤는데, 튜토리얼 따라 할 땐 아무도 말 안 해주는 똑같은 문제에 계속 부딪히네.
기본적인 '검색 후 생성(retrieve-then-generate)' 파이프라인은 데모 볼 땐 멀쩡해 보이지. 질문 깔끔하고, 문서 깔끔하고, 답변도 깔끔하니까. 근데 실제 사용자들 들어오면 상황이 달라짐.
제일 골 때리는 실패 유형이 이거임. 시스템이 같은 정책 문서의 서로 다른 버전에서 청크를 긁어오는데, 이게 버전이 다른 건지 구분할 방법이 없으니까 그냥 다 섞어버림. 그러고는 아주 자신만만하게 답변을 내뱉어. 주의 사항도 없고, "잘 모르겠다"는 말도 없음. 그냥 유창하게 개소리를 하는 거지.
더 근본적인 문제는 표준 RAG에는 불확실성을 처리하는 메커니즘이 아예 없다는 거야. 그냥 검색하고, 생성하고, 다음으로 넘어감. 정답을 맞혔든 그럴싸한 거짓말을 지어냈든 자신감 수치는 똑같음.
이걸 해결하는 방법(내가 작업해 본 시스템 기준)은 모델 바꾸는 게 아님. 아키텍처를 손봐야 함.
라우팅 레이어: 호출하기 전에 검색이 진짜 필요한지부터 결정해. 어떤 질문은 검색할 필요도 없는데 토큰만 낭비하는 꼴이니까.
검색 스코어링: 모델한테 넘기기 전에 검색된 결과가 쓸만한지 평가해. 문맥 점수가 낮으면 그냥 쓰레기 같은 답변 내놓지 말고, 질문을 다시 다듬어서 재시도해야지.
환각 체크: 생성된 답변이랑 검색된 문서를 같이 읽고, 모든 주장이 근거가 있는지 확인하는 LLM 호출을 한 번 더 거쳐. 대부분 팀이 이거 안 하던데, 아마 이게 투자 대비 효과(ROI) 제일 확실할 거다.
특히 재시도 루프가 우리한텐 진짜 도움 됐음. 사용자들이 임베딩 모델이 기대하는 방식으로 질문을 안 하거든. 시스템이 알아서 질문을 다시 다듬어서 재시도하면, 사용자는 뒤에서 무슨 일이 일어났는지도 모름.
이거 다 별거 아님. 파이프라인에 결정 지점 몇 개 추가하는 것뿐이야. 근데 지금 프로덕션에서 그냥 쌩 RAG 돌리면서 왜 사용자들이 자꾸 신뢰를 잃는지 의문이라면, 십중팔구 원인은 이거임.
혹시 버전 관리나 문맥 섞이는 문제 겪어본 사람 또 있나? 이거 생각보다 언급이 너무 안 되는 것 같아서 궁금하네.
