Query改写是提升RAG系统准确率的关键一步，从客户模糊提问中精准识别真实意图。
核心内容：
1. Query改写的重要性与常见误区
2. 三种Query改写方法对比与应用场景
3. 意图识别Prompt模板与实战案例

客户问"怎么退"不再答非所问 | 知识库系列续篇②客经AI实战派 | 2026年7月图1  Query改写：把客户说的话，翻译成搜索引擎能理解的话私信「改写」获取 Query改写Prompt模板 + 意图词典JSON 有一个客户问题，我记到现在。"这个保险能退吗？"把这句话原样扔进知识库搜索。你猜搜出来什么？退保流程。第一步登录APP，第二步我的保单，第三步选择保单……完完整整的退保操作指南。客户真正想问的是什么？"退了我能拿回多少钱。"一个字——"退"——让整个检索跑偏了。这就是RAG最被低估的一环：Query改写。 客户说的话，不等于他想问的事。 RAG链条上最沉默的瓶颈做RAG的人，注意力通常在这三个地方：1. Embedding模型（用哪个？bge还是m3e？）2. 分块策略（上篇讲了）3. Prompt（怎么让大模型用对上下文）很少有人在Query上花时间。Query进来了，原样扔给搜索引擎。搜到什么算什么。但真实世界的客户提问是这样的：表1  客户说的话 vs 客户想问的事

客户实际说的	客户真正想问的
"这个保险能退吗"	退保能退多少钱
"那个红的和蓝的有什么区别"	产品A和产品B的保障范围对比
"上次你说的那个"	历史对话中提到的某条具体信息
"我身体不太好"	有既往病史能不能投保
"划不划算"	产品的IRR或现金价值测算

 每一行的左边，直接搜索都会跑偏。这不是Embedding模型的问题。是Query本身就没表达清楚意图。把模糊的问题扔进再好的搜索引擎，出来的结果也是模糊的。图2  RAG全链路：Query改写是最被低估的一环 Query改写的三种方法我实际用下来，有三种方法覆盖了80%以上的场景。按实现成本从低到高排列。图3  三种Query改写方法对比方法一：同义词扩展（10分钟可上线）最直接的方法。维护一个同义词词典，搜索前自动扩展。{  "退": ["退保", "退费", "退款", "解除合同", "取消保单"],  "交钱": ["缴费", "续费", "保费", "扣款", "支付"],  "赔": ["理赔", "赔付", "报销", "索赔", "出险"],  "改": ["变更", "修改", "更新", "调整", "更换"]}客户搜"怎么退"，系统自动扩展成「退保 OR 退费 OR 退款」。覆盖率和精度都不错。局限：只能解决"说法不同"的问题。解决不了"意图不同"的问题。客户说"这个保险能退吗"和"怎么退保"在关键词层面差不多——但意图完全不同。方法二：意图识别 + 改写Prompt（核心方法）这才是真正解决问题的那一步。思路：检索之前，先让大模型把客户的原话"翻译"成搜索引擎能理解的标准查询。Prompt模板：你是一个保险客服的查询理解助手。客户会用口语化的方式提问，你的任务是把客户的话改写成适合知识库搜索的标准查询。 规则：1. 识别客户真正的意图（是问流程？问价格？问规则？还是比较？）2. 补全省略的信息（"这个保险"→具体产品名，如果上下文有的话）3. 把口语化表达转成书面表达4. 输出1-3个不同角度的搜索查询5. 不要编造客户没问的信息 客户原话：{user_input} 输出格式：意图类型：[流程咨询/费用查询/规则解释/产品对比/其他]改写查询：1. xxx2. xxx3. xxx用这个Prompt，客户问「这个保险能退吗」→意图类型：费用查询改写查询：1. 退保能退多少钱 现金价值计算2. 退保条件 犹豫期退保 正常退保3. 退保需要什么材料 退保流程第1条和第2条直接命中正确的知识库条目。而不是像原问题那样搜出退保操作指南。方法三：多轮对话上下文（进阶）这是处理「上次你说的那个」「和刚才那个有什么区别」这类问题的。思路：把对话历史传给Query改写步骤，让它理解"那个"指什么。对话历史：用户：分红型终身寿险有哪些？客服：目前主要有A款和B款两种...用户：这两个有什么区别？ 改写后的Query：A款分红型终身寿险 和 B款分红型终身寿险 保障范围 收益方式 区别对比三种方法可以组合使用：同义词扩展打底 + Prompt改写做核心 + 多轮上下文做进阶。 实现顺序也是这个顺序。图4  Query改写工作流程：从客户原话到标准查询 实测数据：100个问题，改之前和改之后我把同一批100个真实客户问题，分别用"原样搜索"和"Prompt改写后搜索"各跑了一遍。同一套知识库（1200条客服Q&A），同一个Embedding模型，同一个分块配置。表2  Query改写前后效果对比

指标	无Query改写	有Query改写	提升
Top-1命中率	46%	71%	+25pp
Top-3命中率	71%	89%	+18pp
平均回复相关度	3.1/5	4.4/5	+1.3
完全答非所问率	18%	4%	-14pp

 图5  四项核心指标改写前后对比"完全答非所问"从18%降到4%。 这个数字最关键。因为答非所问是最伤害用户信任的——比"没搜到"更糟糕。我拆开看了一下，Query改写效果最好的三类问题：1. 口语化问题（"这玩意能退不"→改写为"退保条件+退保金额"）：命中率 38%→82%2. 模糊指代（"那个红的"→结合上下文改写为"XX产品"）：命中率 25%→76%3. 多意图混合（"能不能换人+换了之后保费变不变"→拆成两个独立查询）：命中率 52%→91%效果最差的一类：客户自己都不知道想问什么的问题。 比如「我就是想了解一下」。这类问题占测试集的6%，Query改写也救不了——只能用多轮对话慢慢引导。 一个Prompt模板，覆盖80%的场景上面的Prompt可以直接用。但要发挥最大效果，有几个细节：细节一：一定要输出多个改写查询，不是只输出一个原因是：一个改写可能方向对了但措辞不对。3个不同角度的查询，相当于给了搜索引擎3次尝试的机会。实测3个查询的命中率比1个高14个百分点。细节二：意图类型要包含在你的知识库分类体系里如果你用的是LlamaIndex，可以把意图类型映射到metadata filter，在检索时加过滤条件：# 如果意图是"费用查询"，优先检索费用相关的文档if intent == "费用查询":    retriever = index.as_retriever(        similarity_top_k=5,        filters={"category": "费用"}    )这相当于给搜索引擎加了导航——不仅告诉它搜什么，还告诉它去哪搜。细节三：不要把Query改写当成独立的"预处理步骤"把它嵌在检索流程里，改写和搜索交替进行：改写Query→搜索→如果结果置信度不够→用搜索结果再改写→再搜索。这个来回最多两次，成本几乎不增加，但效果能再提3-5个点。 三个常见的坑坑一：改写得"太聪明"Prompt写得过于详细，大模型开始编造客户没问的条件。比如客户问"这个能退吗"，改写后变成"某分红型终身寿险犹豫期内退保现金价值计算"——产品名和"犹豫期"都是大模型自己加上去的。解法：Prompt里明确要求"不要添加客户没说过的具体信息"。坑二：改写延迟太长Query改写步骤本身需要调用一次大模型API，增加0.5-2秒延迟。如果每次搜索都等这个延迟，交互体验很差。解法：流式处理。改写和搜索并行——先用原Query搜一版结果展示，同时后台跑改写，改写完成后再搜第二版替换。用户感知不到延迟。坑三：多轮对话的改写越改越偏对话超过5轮后，上下文太长，大模型开始"猜"客户的意图，越猜越歪。解法：限制上下文窗口为最近3轮对话。超过3轮的旧信息不传给改写Prompt。 总结Query改写是RAG里成本最低、效果最快的优化手段。不用改Embedding模型，不用重建索引，不用调整分块。加一个Prompt模板，改几行代码。客户说的话和系统搜的东西之间，差的不只是一个同义词词典。差的是一个"理解客户真正想问什么"的步骤。这个步骤，就是Query改写。

登录查看剩余 70% 内容