加了Query改写，准确率从71%提到89%
Query改写，是提升RAG系统准确率的关键一步。说白了，就是从客户那些模糊不清的提问里，精准识别出他们真正想问什么。这篇文章，我们重点聊三个话题：Query改写的重要性与常见误区，三种Query改写方法的对比与应用场景，以及意图识别Prompt模板与实战案例。
有一个客户问题，印象特别深。"这个保险能退吗？"把这句话原样扔进知识库搜索，你猜搜出来什么？退保流程。第一步登录APP，第二步我的保单，第三步选择保单……完完整整的退保操作指南。客户真正想问的是什么？"退了我能拿回多少钱。"一个字——"退"——让整个检索跑偏了。这就是RAG最被低估的一环：Query改写。
客户说的话，不等于他想问的事。
RAG链条上最沉默的瓶颈
做RAG的人，注意力通常在这三个地方：Embedding模型（用哪个？bge还是m3e？）、分块策略（上篇讲了）、Prompt（怎么让大模型用对上下文）。很少有人在Query上花时间。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次尝试的机会。实测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改写。
