Query改写（查询重写）是提升RAG（检索增强生成）系统准确率的关键环节。简单来说，就是从用户模糊、口语化的提问中，精准识别出他们真正想要了解的信息。本文将重点探讨三个核心话题：Query改写的重要性与常见误区、三种Query改写方法的对比与适用场景，以及意图识别Prompt模板与实战案例。
有一个客户问题，令我印象特别深刻。"这个保险能退吗？"把这句话原封不动地输入知识库搜索，你猜会得到什么结果？退保流程。第一步登录APP，第二步我的保单，第三步选择保单……一份完整的退保操作指南。客户真正想问的是什么？"退了我能拿回多少钱。"仅仅一个"退"字，就让整个检索偏离了方向。这就是RAG中最容易被低估的一环：Query改写。
客户说出来的话，并不等于他们真正想询问的问题。
RAG链条上最容易被忽视的瓶颈
从事RAG开发的人，注意力通常集中在以下三个环节：Embedding模型（选择哪个？bge还是m3e？）、分块策略（上篇文章已讲解）、Prompt（如何让大模型正确利用上下文）。很少有人会在Query上投入精力。用户输入后，直接原样送入搜索引擎，搜到什么就是什么。然而，真实世界的客户提问往往是这样的：
| 客户实际说的 | 客户真正想问的 |
| "这个保险能退吗" | 退保能退多少钱 |
| "那个红的和蓝的有什么区别" | 产品A和产品B的保障范围对比 |
| "上次你说的那个" | 历史对话中提到的某条具体信息 |
| "我身体不太好" | 有既往病史能不能投保 |
| "划不划算" | 产品的IRR或现金价值测算 |
表格中每一行左侧的提问，如果直接搜索都会偏离目标。这并非Embedding模型的问题，而是Query本身未能清晰表达意图。将模糊的问题送入再优秀的搜索引擎，得到的答案也必然是模糊的。
Query改写的三种主流方法
从实际应用角度来看，有三种方法可以覆盖80%以上的场景。以下按实现成本从低到高排列。
方法一：同义词扩展（10分钟即可上线）
这是最直接的方法。维护一个同义词词典，在搜索前自动展开同义词。
{ "退": ["退保", "退费", "退款", "解除合同", "取消保单"], "交钱": ["缴费", "续费", "保费", "扣款", "支付"], "赔": ["理赔", "赔付", "报销", "索赔", "出险"], "改": ["变更", "修改", "更新", "调整", "更换"] }
当客户搜索"怎么退"时，系统自动扩展为「退保 OR 退费 OR 退款」。这种方法覆盖率和精度都较好，但局限性在于只能解决"说法不同"的问题，无法处理"意图不同"的情况。客户问"这个保险能退吗"和"怎么退保"在关键词层面相似，但意图完全不同。
方法二：意图识别 + 改写Prompt（核心方法）
这才是真正解决问题的关键步骤。思路是：在检索之前，先让大模型将客户的原始口语表达"翻译"成搜索引擎能够理解的标准查询。
Prompt模板：
你是一个保险客服的查询理解助手。客户会用口语化的方式提问，你的任务是把客户的话改写成适合知识库搜索的标准查询。规则：1. 识别客户真正的意图（是问流程？问价格？问规则？还是比较？）2. 补全省略的信息（"这个保险"→具体产品名，如果上下文有的话）3. 把口语化表达转成书面表达4. 输出1-3个不同角度的搜索查询5. 不要编造客户没问的信息。客户原话：{user_input}。输出格式：意图类型：[流程咨询/费用查询/规则解释/产品对比/其他]改写查询：1. xxx 2. xxx 3. xxx
使用这个Prompt，客户问「这个保险能退吗」→意图类型：费用查询；改写查询：1. 退保能退多少钱 现金价值计算 2. 退保条件 犹豫期退保 正常退保 3. 退保需要什么材料 退保流程。第1条和第2条直接命中了正确的知识库条目，而不是像原问题那样搜出退保操作指南。
方法三：多轮对话上下文（进阶方案）
这是用来处理「上次你说的那个」「和刚才那个有什么区别」这类模糊指代问题的。核心思路：将对话历史传递给Query改写步骤，让大模型理解"那个"具体指代什么。
对话历史：用户：分红型终身寿险有哪些？客服：目前主要有A款和B款两种...用户：这两个有什么区别？
改写后的Query：A款分红型终身寿险 和 B款分红型终身寿险 保障范围 收益方式 区别对比
三种方法可以组合使用：同义词扩展打底 + Prompt改写作为核心 + 多轮上下文作为进阶。实际实施顺序也建议按照这个步骤推进。
实测数据：100个真实问题，改写前后对比
我们将同一批100个真实客户问题，分别采用"原样搜索"和"Prompt改写后搜索"各执行一次。使用同一套知识库（1200条客服Q&A）、同一个Embedding模型、同一个分块配置。
| 指标 | 无Query改写 | 有Query改写 | 提升 |
| Top-1命中率 | 46% | 71% | +25pp |
| Top-3命中率 | 71% | 89% | +18pp |
| 平均回复相关度 | 3.1/5 | 4.4/5 | +1.3 |
| 完全答非所问率 | 18% | 4% | -14pp |
"完全答非所问"的比例从18%降至4%。这个数字最为关键，因为答非所问对用户信任的伤害远超"未搜到"的结果。进一步分析发现，Query改写效果最好的三类问题分别是：口语化问题（"这玩意能退不"→改写为"退保条件+退保金额"）：命中率从38%提升至82%；模糊指代（"那个红的"→结合上下文改写为"XX产品"）：命中率从25%提升至76%；多意图混合（"能不能换人+换了之后保费变不变"→拆分为两个独立查询）：命中率从52%提升至91%。效果最差的一类是：客户自己都不清楚到底想问什么的问题，比如「我就是想了解一下」。这类问题占测试集的6%，即使Query改写也难以解决，只能依靠多轮对话逐步引导。
一个Prompt模板，覆盖80%的场景
上述Prompt可以直接投入使用。但要发挥最大效果，需要注意以下细节：
细节一：务必输出多个改写查询，而非仅一个。原因在于，单个改写方向可能正确但措辞不够精准，而3个不同角度的查询相当于给搜索引擎三次尝试机会。实测数据显示，3个查询的命中率比1个高出14个百分点。
细节二：意图类型应当与知识库的分类体系保持一致。如果你使用LlamaIndex，可以将意图类型映射到metadata filter，在检索时添加过滤条件。例如，意图为"费用查询"时，优先检索费用相关的文档。
细节三：不要将Query改写视为独立的"预处理步骤"。建议将其嵌入检索流程，改写与搜索交替进行：改写Query→搜索→若结果置信度不足→利用搜索结果再次改写→再次搜索。此循环最多执行两次，几乎不增加成本，但效果可再提升3-5个百分点。
三个常见陷阱
陷阱一：改写得"过于聪明"。如果Prompt写得过于详细，大模型可能会编造客户未提及的条件。例如客户问"这个能退吗"，改写后变成"某分红型终身寿险犹豫期内退保现金价值计算"——产品名和"犹豫期"都是大模型自行添加的。解决方案：在Prompt中明确要求"不要添加客户未说过的具体信息"。
陷阱二：改写延迟过长。Query改写步骤本身需要调用一次大模型API，增加0.5-2秒的延迟。如果每次搜索都等待这个延迟，交互体验会变差。解决方案：采用流式处理。改写与搜索并行——先用原始Query搜索一版结果并展示，同时后台进行改写，改写完成后用第二版结果替换。用户几乎感知不到延迟。
陷阱三：多轮对话的改写越改越偏。对话超过5轮后，上下文过长，大模型开始"猜测"客户意图，导致偏差。解决方案：限制上下文窗口为最近3轮对话，超出3轮的旧信息不传递给改写Prompt。
总结
Query改写是RAG中成本最低、见效最快的优化手段。无需更换Embedding模型，无需重建索引，也无需调整分块策略。只需添加一个Prompt模板，修改几行代码即可。客户所说的话与系统搜索到的内容之间，差距不仅仅是一个同义词词典，更缺少一个"理解客户真正想询问什么"的环节。而这个环节，正是Query改写。