사용자의 원문 프롬프트를 Retriever에 그대로 전달하는 것을 멈추세요

사용자가 RAG 시스템에 질문을 입력합니다. 무언가가 검색(retrieval)되기 전에, _실제로 어떤 문자열로 검색할지_를 결정해야 합니다. 많은 시스템에서 이는 의도적으로 결정되지 않습니다. 원문 프롬프트(raw prompt)가 Retriever로 바로 전달되며, 이것이 제대로 작동할지는 운에 맡겨집니다.

모두가 시도하는 것

쿼리 재작성 (Query rewriting): LLM이 질문을 더 나은 검색 문자열로 확장하거나 재구성하도록 합니다. 이는 현재 표준이며, 어휘 차이(vocabulary gaps)를 해결하는 데 진정으로 도움이 됩니다. 예를 들어, 사용자는 "로그인 안 됨"이라고 말하고 문서는 "인증 실패(authentication failure)"라고 되어 있을 때, 재작성이 이 둘 사이를 연결해 줍니다.

왜 완벽하게 작동하지 않는가

검색 성능을 향상시키는 재작성이 질문을 은밀하게 변경할 수도 있습니다. 사용자는 한 가지를 물었지만, 재작성된 쿼리는 약간 다른 것에 대한 훌륭한 문서들을 검색해 옵니다. 답변은 유창하고 근거가 확실하지만, 사용자가 물어본 내용이 아닙니다. 검색 지표(retrieval metrics)는 개선되었기 때문에 아무도 눈치채지 못하지만, 재현율(Recall)은 올라가고 충실도(Fidelity)는 떨어지게 됩니다.

진짜 문제는 현장에 두 개의 언어가 존재한다는 점입니다. 즉, 사용자의 작업 언어(task language)와 코퍼스(corpus) 저자의 언어입니다. 그리고 Retriever는 그 경계에 앉아 있습니다. 이를 단순히 "쿼리를 재작성하는 것"으로 취급하는 것은, 당신이 결과에 영향을 미치는 번역 결정(translation decision)을 내리고 있다는 사실을 숨기는 것입니다.

단 하나의 전환

사용자 질문과 검색 쿼리 사이의 간극을 숨겨진 전처리 단계가 아닌, 명시적인 인터페이스 경계(interface boundary)로 취급하세요. 의도적으로 결정해야 합니다: Retriever가 무엇을 검색할 것인가? 사용자의 언어와 문서의 언어를 어떻게 조화시킬 것인가? 재작성된 쿼리가 여전히 질문에 대한 답을 제공하는가? 번역 과정을 가시화하고 확인할 수 있게 만들어, "쿼리를 재작성했다"는 말이 "우리는 다른 질문에 답했다"로 소리 없이 변하지 않도록 하세요.

이것이 바로 쿼리 경계(query boundary)이며, 프로덕션 RAG가 실패하는 세 가지 지점 중 하나입니다. 전체 버전은 제 블로그에 있습니다. 프로덕션 RAG를 디버깅하는 팀을 위한 세 가지 경계 모두에 대한 진단 질문은 RAG Failure Diagnosis Kit에 포함되어 있습니다. 원문 포스트의 링크를 확인하세요.