加了Query改写，准确率从71%提到89%

Query改写是提升RAG系统准确率的关键一步，从客户模糊提问中精准识别真实意图。

核心内容：
Query改写的重要性与常见误区
三种Query改写方法对比与应用场景
意图识别Prompt模板与实战案例

客户问"怎么退"不再答非所问 | 知识库系列续篇② 客经AI实战派 | 2026年7月

加了Query改写，准确率从71%提到89%

图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本身就没表达清楚意图。把模糊的问题扔进再好的搜索引擎，出来的结果也是模糊的。

加了Query改写，准确率从71%提到89%

图2 RAG全链路：Query改写是最被低估的一环 Query改写的三种方法我实际用下来，有三种方法覆盖了80%以上的场景。按实现成本从低到高排列。

加了Query改写，准确率从71%提到89%

图3 三种Query改写方法对比方法一：同义词扩展（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改写做核心 + 多轮上下文做进阶。实现顺序也是这个顺序。

加了Query改写，准确率从71%提到89%

图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

加了Query改写，准确率从71%提到89%

图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.asretriever( similaritytop_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% 内容](javascript:void (0);)

大模型rag技术rag 检索增强生成rag实践

加了Query改写，准确率从71%提到89%