논문 분석 · 2026
모든 검색어가 재작성될 필요는 없다: LLM 쿼리 재작성이 밀집 검색에 도움이 될 때와 해가 될 때
Not All Queries Need Rewriting: When Prompt-Only LLM Refinement Helps and Hurts Dense Retrieval
Varun Kotte · Adobe · arXiv 2026
ABSTRACT
LLM이 검색어를 자동으로 다듬는 '쿼리 재작성'이 실제 검색 성능을 도메인에 따라 최대 9% 낮출 수도, 5% 높일 수도 있음을 실증적으로 밝혔습니다. "재작성은 항상 도움이 된다"는 현장의 암묵적 전제를 처음으로 체계적으로 검증한 연구입니다.
핵심 기여
| 01 |
재작성이 오히려 성능을 떨어뜨린다는 사실을 도메인별로 처음 실증했습니다. 금융 Q&A(FiQA) 도메인에서는 평균 9% 성능 하락이 통계적으로 유의미하게 확인되었습니다. |
| 02 |
VOR(어휘 중복 비율)와 CTF(코퍼스 용어 빈도 비율)라는 두 가지 진단 지표를 도입해 재작성이 왜 도움이 되고 왜 해가 되는지의 메커니즘을 규명했습니다. |
| 03 |
선택적 재작성(해로울 것 같은 쿼리만 걸러내는 방식)은 "아예 재작성하지 않는 것"보다 유의미하게 낫지 않으며, 도메인 특화 추가 학습이 더 안전한 대안임을 보였습니다. |
CONTENTS
용어 설명
밀집 검색 (Dense Retrieval)
검색어와 문서를 모두 수백 차원의 숫자 벡터로 변환한 뒤, 그 벡터 사이의 거리(유사도)를 계산해 가장 관련성 높은 문서를 찾아내는 검색 방식입니다. "단어가 똑같이 들어있는가"가 아니라 "의미가 얼마나 비슷한가"를 기준으로 판단하기 때문에, 표현은 다르지만 의미가 같은 문서도 잘 찾을 수 있습니다. 이때 벡터로 변환하는 역할을 하는 AI 모델을 검색기(retriever)라고 부릅니다.
손님이 "따뜻하고 배부른 것"이라고 막연하게 말해도 홀 직원이 메뉴 중 된장찌개를 골라내듯, 단어가 달라도 의미로 찾아주는 방식입니다.
쿼리 재작성 (Query Rewriting)
사용자가 입력한 검색어를 LLM(대규모 언어 모델)이 자동으로 다듬어 더 나은 검색어로 바꿔주는 과정입니다. 이 논문에서 다루는 방식은 특히 프롬프트만 사용하는 단일 단계 재작성으로, 검색 결과를 미리 보거나 피드백을 받지 않고 검색어 하나만 보고 즉시 고쳐 씁니다.
손님이 주문서를 건네기 전, 홀 직원이 "더 잘 전달될 것 같다"며 주문 내용을 임의로 고쳐 주방에 넘기는 것과 같습니다.
RAG (Retrieval-Augmented Generation)
AI가 답변을 생성하기 전에 먼저 관련 문서를 검색해 참고하도록 만든 방식입니다. 챗봇이 아무 근거 없이 답을 꾸며내는 문제(환각)를 줄이고, 최신 정보나 도메인 전문 지식이 담긴 문서를 실시간으로 참조할 수 있게 해줍니다. 쿼리 재작성은 바로 이 RAG 파이프라인의 첫 단계인 검색 품질을 높이기 위해 사용됩니다.
요리사가 요리하기 전에 냉장고에서 재료를 꺼내 확인하는 과정이 포함된 시스템으로, 냉장고 재료를 잘 찾아야 맛있는 요리가 나옵니다.
VOR — 어휘 중복 비율 (Vocabulary Overlap Ratio)
검색어에 포함된 단어들 중에서, 정답 문서에도 실제로 등장하는 단어의 비율을 나타내는 지표입니다. 예를 들어 검색어에 단어가 5개 있고 그 중 4개가 정답 문서에도 나온다면 VOR은 0.8이 됩니다. VOR이 높을수록 검색어와 문서가 같은 단어를 공유하고 있어 검색이 잘 될 가능성이 높습니다. 단, 이 지표는 정답 문서가 어떤 것인지 미리 알아야 계산할 수 있어 사후 분석 용도로만 쓸 수 있습니다.
손님 주문서에 적힌 단어 중에서 주방 재료 목록에도 같은 이름으로 올라있는 항목의 비율이라 할 수 있습니다. 주문서 단어가 재료 목록과 많이 겹칠수록 주방이 재료를 빠르게 찾습니다.
CTF — 코퍼스 용어 빈도 비율 (Corpus Term Frequency ratio)
재작성 과정에서 교체된 단어가 전체 문서 모음(코퍼스)에서 더 자주 쓰이는 단어로 바뀌었는지를 측정하는 지표입니다. 새로 들어온 단어의 출현 빈도를 기존 단어의 출현 빈도로 나눈 값으로, 1보다 크면 더 흔한 단어로 대체된 것(표준화), 1보다 작으면 더 생소한 단어로 대체된 것(이탈)을 뜻합니다.
손님이 "2019-nCOV"라는 낯선 식재료명을 주문서에 적었을 때, 홀 직원이 주방에서 더 흔하게 쓰는 이름인 "COVID-19"로 고쳐줬다면 CTF가 1 이상인 경우입니다.
nDCG@10 — 검색 성능 지표
검색 결과 상위 10개가 얼마나 정확하게 관련 문서를 포함하는지 평가하는 점수입니다. 단순히 관련 문서가 포함되어 있는지만 보는 게 아니라, 더 앞 순위에 나올수록 더 높은 점수를 부여합니다. 최솟값은 0, 최댓값은 1이며 값이 높을수록 검색 성능이 좋은 것입니다.
주방이 내놓은 요리 10가지 중에서 손님이 원했던 요리가 앞쪽에 배치될수록 높은 점수를 받는 채점표입니다.
연구 배경 및 문제 의식
요즘 기업들이 구축하는 AI 챗봇과 검색 시스템에는 대부분 RAG 구조가 쓰입니다. 그리고 이 RAG 파이프라인 앞단에 "LLM이 검색어를 한 번 고쳐주는 단계"가 사실상 표준처럼 자리를 잡았습니다. 검색어가 더 정교해지면 당연히 검색도 잘 될 것이라는 직관적인 기대 때문입니다. 그런데 이 기대가 정말 맞는지 체계적으로 검증한 연구는 놀랍게도 거의 없었습니다.
기존 연구들은 주로 "애매하거나 대화체로 쓰인 검색어"를 고치는 데 집중했습니다. 이런 쿼리는 재작성의 혜택을 받기 쉽습니다. 그러나 금융·의학·법률처럼 전문 도메인에서 사용하는 검색어는 이미 잘 다듬어진 경우가 많고, 검색 엔진도 그 도메인에 맞게 최적화되어 있을 수 있습니다. 이런 환경에서도 재작성이 도움이 되는지는 전혀 확인되지 않은 채 시스템에 도입되고 있었습니다.
연구가 던지는 핵심 질문
전문 도메인에서 이미 잘 구성된 검색어에 LLM이 손을 댔을 때, 검색 성능은 오히려 나빠지지 않을까? 그리고 만약 나빠진다면, 언제 나빠지고 언제 좋아지는지를 설명할 수 있는 메커니즘이 있을까?
연구 방법
연구팀은 성격이 서로 다른 세 가지 데이터셋을 골라 실험을 설계했습니다. FiQA는 금융 Q&A 데이터로, 전문 용어가 안정적이고 잘 정제된 질문들로 구성되어 있습니다. SciFact는 과학자들이 직접 작성한 연구 주장들의 집합입니다. TREC-COVID는 코로나19 팬데믹 초기 자료로, 같은 개념을 "2019-nCOV", "SARS-CoV-2", "COVID-19" 등 제각각 다른 이름으로 부르는 명칭 혼란이 심한 데이터셋입니다. 이 세 가지를 고른 이유는 "잘 최적화된 도메인"과 "혼란스러운 도메인"을 함께 비교하기 위해서입니다.
실험 파이프라인 — 쿼리 재작성의 영향 측정 흐름
재작성에는 Ministral 8B라는 LLM을 사용했고, "원래 의도는 유지하면서 명확하게, 관련 맥락을 추가하라"는 일반적인 프롬프트를 주었습니다. 검색기는 MPNet과 BGE, 두 가지를 썼으며 각각 기본 모델과 FiQA 데이터로 추가 학습한 모델로 나누어 총 네 가지 설정에서 실험했습니다. 재작성된 검색어로 검색한 결과를 원본 검색어로 검색한 결과와 nDCG@10으로 비교하는 방식으로 성능 차이를 측정했습니다.
성능 차이의 원인을 규명하기 위해 두 가지 지표를 추가로 도입했습니다. VOR은 재작성 전후로 검색어와 정답 문서 사이의 단어 공유율이 어떻게 변했는지를 측정합니다. CTF는 재작성 과정에서 교체된 단어가 문서 모음 전체에서 더 흔한 단어였는지, 아니면 더 생소한 단어였는지를 측정합니다. 두 지표를 함께 보면 재작성이 검색어를 "올바른 방향"으로 고쳤는지 "엉뚱한 방향"으로 고쳤는지를 사후적으로 판단할 수 있습니다.
수식 (1) — VOR (어휘 중복 비율)
검색어 q에 포함된 고유 단어들의 집합 W(q)와 정답 문서들에 포함된 고유 단어들의 집합 W(Dq)의 교집합 크기를, 검색어 단어 집합의 크기로 나눈 값입니다. 재작성 전후 VOR 변화량(∆VOR)이 음수라면 재작성이 검색어와 문서 사이의 단어 일치도를 떨어뜨린 것을 의미합니다.
홀 직원이 주문서를 고쳐 썼더니 주방 재료 목록과 겹치는 단어가 줄어든 정도입니다. 공통 단어가 줄어들수록 주방이 원하는 재료를 찾기 어려워집니다.
실험 및 결과
실험 설정
| 항목 | 내용 |
| 데이터셋 | FiQA (금융 Q&A, 648개 쿼리) · SciFact (과학 주장, 300개 쿼리) · TREC-COVID (팬데믹, 50개 쿼리) |
| 평가지표 | nDCG@10 (상위 10개 결과의 관련성 점수) |
| 검색기 | MPNet, BGE (각각 기본 모델 + FiQA 추가 학습 모델) |
| 재작성 모델 | Ministral 8B (추가로 GPT-4o-mini로 강건성 검증) |
가장 충격적인 결과는 FiQA에서의 일관된 성능 하락입니다. 네 가지 모델 설정 모두에서 재작성 후 nDCG@10이 6~11% 하락했으며, 이는 통계적으로 매우 유의미한 결과였습니다(p < 0.001). 반면 TREC-COVID에서는 세 개 설정에서 성능이 올랐고, SciFact에서는 유의미한 변화가 없었습니다. 같은 LLM, 같은 프롬프트인데 도메인에 따라 결과가 완전히 달라진 것입니다.
도메인별 쿼리 재작성 효과 (MPNet Base 기준)
|
FiQA (금융)
원본: 0.500
재작성: 0.448 ↓ −10.3%
성능 하락 (유의미) |
SciFact (과학)
원본: 0.656
재작성: 0.655 − 0.0%
변화 없음 (유의미하지 않음) |
TREC-COVID
원본: 0.513
재작성: 0.559 ↑ +8.9%
성능 향상 |
같은 LLM, 같은 프롬프트로 재작성했을 때 도메인에 따라 결과가 완전히 달라집니다
왜 이런 차이가 생기는지를 파고들었더니 핵심 메커니즘이 드러났습니다. FiQA에서 성능이 하락한 쿼리들을 분석해 보면 네 가지 실패 패턴이 반복됐습니다. "transfer"(이체)라는 단어를 "rollover"(롤오버)로 바꿨더니 정답 문서가 "transfer"를 쓰고 있어서 찾지 못하게 되는 용어 이탈, e-commerce 같은 엉뚱한 문맥을 덧붙이는 맥락 오주입, 넓은 개념을 너무 좁게 한정하는 과도한 특정화, 구어체를 격식체로 바꾸다가 문서 속 표현과 달라지는 과도한 형식화가 그것입니다.
"transfer(이체)로 주문했더니 홀 직원이 rollover(롤오버)로 고쳐 주방에 넘겼고, 재료 창고에는 transfer라는 라벨이 붙어 있어서 아무것도 못 찾아온 것"과 같은 상황입니다.
반면 TREC-COVID에서는 재작성이 도움이 됐는데, 이유는 정반대였습니다. 코로나 초기 자료에는 같은 바이러스를 "2019-nCOV", "SARS-CoV-2", "COVID-19" 등 다양하게 불렀기 때문에, LLM이 이를 문서 모음에서 가장 자주 쓰이는 "COVID-19"로 통일해 주면서 검색이 잘 되었습니다. CTF를 보면 성능이 향상된 쿼리에서는 교체된 단어가 평균 1,153배 더 흔한 단어였습니다.
흥미로운 점은 VOR 분석에서 드러납니다. 재작성 후 어떤 단어가 교체됐는지는 거의 모든 쿼리(95%)에서 동일하게 일어났습니다. 즉, 단어를 교체하는 행위 자체는 성능 차이를 만들지 않습니다. 단어가 코퍼스에서 더 흔한 방향으로 교체됐느냐, 아니냐가 결과를 갈랐습니다.
토론 및 한계
연구팀은 "그렇다면 해로운 재작성만 걸러낼 수 있지 않을까?"라는 현실적인 질문에도 답했습니다. VOR 변화량, 새로 추가된 단어 비율, 길이 변화를 특징으로 삼아 분류 모델을 훈련했지만 AUC가 0.593에 그쳤습니다. 해로운 재작성을 어느 정도 걸러내긴 해도 오탐(잘못 거른 것)도 많고, 결정적으로 "아예 재작성하지 않는 것"보다 유의미하게 나은 성능을 내지 못했습니다. 심지어 정답 레이블을 미리 알고 있는 이상적인 오라클 분석에서도 최대 이득이 3%p에 불과했습니다.
홀 직원이 주문서를 고칠지 말지를 판단하는 기준표를 만들어도, 그 기준표가 너무 부정확해서 멀쩡한 주문서도 잔뜩 걸러낸 채 결과는 그냥 원본대로 내는 것과 별 차이가 없는 상황입니다.
저자들은 대안으로 도메인 특화 추가 학습(post-training)을 권장합니다. FiQA 데이터로 추가 학습한 검색기는 재작성 없이도 성능이 1.4~4.3% 향상되었으며, 재작성처럼 성능을 급격히 낮추는 위험이 없었습니다. 재작성은 명칭 불일치가 심한 도메인이나 레이블 데이터가 전혀 없는 상황에서만 제한적으로 쓰는 것이 적절하다고 결론 내립니다.
|
한계 1 — 작은 데이터셋 TREC-COVID는 쿼리가 50개에 불과해 통계적 신뢰도가 낮습니다. 보정 후에는 TREC-COVID 결과가 통계적 유의미성 기준을 간신히 넘는 수준(p=0.024)이 됩니다. |
|
한계 2 — 분석 지표의 사후성 VOR과 CTF는 정답 레이블과 코퍼스를 알아야 계산할 수 있어 실시간 운용 환경에서 직접 사용하기 어렵습니다. 대리 지표 개발이 필요합니다. |
|
한계 3 — 제한된 쿼리 유형 이 연구의 데이터셋은 정제된 쿼리들로 구성됩니다. 실제 서비스에서 흔한 대화체·불완전한 쿼리에서 재작성이 어떤 영향을 미치는지는 별도로 검증해야 합니다. |
내용 정리
| 항목 | 결론 |
| 재작성의 효과 | 도메인에 따라 크게 다름 — 잘 최적화된 도메인에선 오히려 해로울 수 있음 |
| 핵심 메커니즘 | 단어 교체 자체가 아니라 교체 방향(코퍼스 친화적이냐 아니냐)이 결과를 결정 |
| 선택적 재작성 | 현실적으로 구현하기 어려우며, 아예 재작성하지 않는 것보다 유의미하게 낫지 않음 |
| 권장 대안 | 레이블이 있으면 도메인 추가 학습, 없으면 명칭 혼란이 있는 경우에만 재작성 활용 |
인사이트
"더 많이 손댈수록 더 좋아진다"는 전제를 의심해야 합니다
이 연구는 AI 시스템 설계에서 흔히 빠지는 함정을 정확하게 짚습니다. 현장에서는 "LLM이 고쳐주면 더 좋아지겠지"라는 직관 때문에 추가 단계를 거의 검증 없이 도입하는 경우가 많습니다. 그러나 이미 잘 돌아가고 있는 파이프라인에 개입할수록, 오히려 기존에 잘 맞춰진 균형을 무너뜨릴 위험이 생깁니다.
도메인이 다르면 전략도 달라야 합니다
용어가 안정적이고 잘 정제된 금융·법률 도메인과, 신조어·혼용이 많은 바이오·의학 도메인은 재작성의 효과가 정반대로 나타났습니다. RAG 파이프라인을 구축할 때 재작성 여부를 도메인 특성에 따라 결정해야 한다는 실용적인 지침을 제시한다는 점에서 이 연구의 가치가 큽니다.
실무 적용 지침
전문 도메인에서 안정적인 용어를 쓰는 경우라면 재작성을 기본 옵션으로 켜두지 마세요. 명칭이 혼란스럽거나 쿼리 품질이 고르지 않은 환경이라면 재작성이 도움이 될 수 있습니다. 레이블 데이터가 있다면 재작성보다 추가 학습이 더 안전한 투자입니다.
추가로 알면 좋은 것들
이 논문은 쿼리 재작성 분야 연구들 위에 놓여 있습니다. 비슷한 맥락에서 읽으면 좋은 주요 연구들을 소개합니다.
| 연구 | 핵심 아이디어 |
| HyDE (Gao et al., 2023) | 검색어 대신 "이런 답변이 있을 것 같다"는 가상의 문서를 LLM으로 생성해 검색에 쓰는 방법 |
| Self-RAG (Asai et al., 2024) | LLM이 검색 결과를 보고 스스로 반성하며 재검색 여부를 결정하는 피드백 루프 방식 |
| Query2Doc (Wang et al., 2023) | LLM으로 짧은 가상 문서를 만들어 원래 검색어에 붙여 확장하는 방법 |
| BEIR 벤치마크 (Thakur et al., 2021) | 다양한 도메인에 걸쳐 검색 모델의 제로샷 성능을 비교할 수 있는 표준 벤치마크 모음 |
이 연구와의 차이점
HyDE, Self-RAG, Query2Doc은 모두 검색 결과를 피드백으로 활용하거나 문서를 생성하는 방식으로, 이 논문에서 다루는 "피드백 없이 쿼리만 보고 한 번에 고쳐쓰는" 방식과는 메커니즘이 다릅니다. 이 논문은 그중에서도 실무에서 가장 단순하고 흔하게 쓰이는 방식이 실제로는 안전하지 않을 수 있다는 점을 지적합니다.
WRAP UP
LLM이 검색어를 자동으로 고쳐주는 방식은 RAG 파이프라인의 표준 레시피처럼 자리 잡았지만, 이 논문은 그 레시피가 이미 잘 돌아가는 주방에서는 오히려 음식을 망칠 수 있다는 것을 처음으로 체계적으로 보여줬습니다. 단어가 교체되는 행위 자체가 아니라 어떤 방향으로 교체되느냐가 결과를 가르며, 해로운 재작성만 골라내는 실용적인 방법도 아직은 충분히 신뢰하기 어렵습니다. 전문 도메인에서 검색 파이프라인을 설계할 때 "재작성을 기본으로 켜두는 것"이 정말 옳은지 한 번 더 따져보게 만드는 연구입니다.