AI 인사이트 목록
RAG2026년 8월 19일

검색 전에 질문부터 고쳐 쓰는 RAG

사용자 질문을 검색에 맞게 고쳐 쓰는 재작성 단계를 검색 앞에 추가하면 RAG 성능이 일관되게 개선됩니다. Rewrite-Retrieve-Read 프레임워크를 제안한 이 논문은 소형 재작성 모델을 LLM 리더의 피드백으로 강화학습해, 검색기와 생성기를 그대로 둔 채 QA 성능을 끌어올렸습니다.

원문 논문 보기쿼리 재작성 · 질의 확장 · 강화학습 · 검색 최적화

RAG의 실패는 종종 검색기가 아니라 질문 자체에서 시작됩니다. 사용자가 입력한 문장과 문서에 실제로 쓰인 표현 사이에 간극이 있으면 아무리 좋은 검색기도 엉뚱한 문서를 가져옵니다.

문제 배경

기존 파이프라인은 사용자 질문을 그대로 검색어로 씁니다. 그러나 복합 질문을 통째로 검색하면 오히려 성능이 떨어지기도 합니다. 실제로 이 논문의 실험에서 HotpotQA는 검색을 붙인 구성(EM 30.47)이 검색 없는 직접 답변(32.36)보다 나빴습니다. 잘못된 검색어가 잘못된 문맥을 불러와 답을 흐린 것입니다. 또한 리더로 쓰이는 강력한 LLM은 API 뒤의 블랙박스라 내부를 학습시킬 수 없으므로, 개선 여지는 입력 쪽에 있습니다.

방법

Ma 등(2023)은 검색 후 읽기라는 기존 순서 앞에 재작성 단계를 놓은 Rewrite-Retrieve-Read 프레임워크를 제안했습니다. 핵심은 재작성기를 학습 가능하게 만든 부분입니다. T5-large를 재작성기로 두고, 먼저 지도학습으로 워밍업한 뒤 최종 답을 생성하는 LLM 리더의 정답 여부를 보상 삼아 강화학습으로 훈련합니다. 검색기는 Bing 검색 엔진, 리더는 ChatGPT와 Vicuna-13B를 그대로 두고 질의만 바꾸는 것입니다.

Rewrite-Retrieve-Read 프레임워크의 구성

결과

개방형 QA 세 데이터셋에서 재작성 단계가 일관된 개선을 보였습니다.

구성 (EM)HotpotQAAmbigNQPopQA
직접 답변32.3642.1041.94
검색 후 읽기30.4745.8043.20
LLM 재작성32.8046.4046.00
학습된 재작성기34.3847.8045.72

검색이 오히려 해가 되던 HotpotQA에서도 재작성을 거치면 개선으로 돌아섰습니다. 학습된 T5 재작성기는 두 데이터셋에서 LLM 재작성보다 나았고, 소형 모델로도 재작성 역할을 충분히 감당할 수 있음을 보였습니다.

한계와 주의점

저자들이 밝힌 한계로, 재작성기를 특정 과제에 학습시키면 다른 과제로의 직접 전이가 어려워지는 일반화와 특화 사이의 상충이 있습니다. PopQA에서는 학습된 재작성기가 LLM 재작성보다 낮았듯 이득이 데이터셋마다 균일하지 않습니다. 강화학습 파이프라인의 구축과 보상 설계 비용도 실무 도입 시 고려해야 합니다.

기업 적용 관점

현업 사용자는 "작년 그 계약 위약금 조건"처럼 생략과 사내 은어가 섞인 질의를 던집니다. 이를 문서의 언어로 번역하는 재작성 계층은 검색기 교체보다 훨씬 적은 비용으로 체감 품질을 올립니다. 무거운 구성 요소를 건드리지 않고 앞단의 작은 모듈만 학습시킨다는 이 논문의 구조는, 검색 엔진이나 LLM을 바꾸기 어려운 기업 환경에 그대로 옮겨집니다. 코텍시스는 질의 로그 분석으로 재작성 규칙과 모델을 함께 설계합니다.

코텍시스 AI사업부는 sLLM 최적화, Advanced RAG, AI Agent 개발을 수행합니다. 이런 기법의 도입을 검토 중이라면 문의를 남겨주세요.

AI 개발 문의