做RAG系统做的久了你会发现一个很有意思的现象Embedding模型换了、Chunk切分调了、Top-K也试了好几个值检索效果始终卡在一个瓶颈上不去。用户换个问法比如把“怎么提高日志检索速度”说成“查日志好卡怎么搞”原来好用的检索就哑火了。问题多半不在向量化而在查询本身——你拿着用户那句口语化的、带着指代和省略的原话直接去和精心组织的文档内容做语义匹配这中间的鸿沟只能靠查询重写来填。查询重写Query Rewriting不是可有可无的锦上添花它是RAG系统里成本最低、见效最明显的优化点之一。不用动索引结构、不用重新训练Embedding模型只需要在检索之前加一道“翻译”工序把用户的原始输入改写成一个或多个更适合检索的查询召回质量就能上一个台阶。这篇文章我把自己在几个项目里落地查询重写的经验整理出来从方法分类到具体实现再到踩坑实录给正在折腾RAG检索效果的你一个可直接参考的路线。1. 为什么检索结果总找不到北用户提问和文档表述之间的鸿沟1.1 用户怎么问文档怎么写的根本不是一回事做RAG的人经常会陷入一个误区觉得只要Embedding模型够强语义相似度就能扛住一切。但实际上Embedding模型擅长捕捉“话题相近”不代表能处理好“表述方式极端不同”的场景。用户来问问题用的是口语、省略句、模糊指代而知识库里的文档写的是书面语、完整句式、专业术语。我给你举个实际例子。某内部运维知识库里有一篇文档标题是《基于Prometheus的告警规则配置指南》里面详细讲了如何设置CPU使用率阈值、如何配置告警通知渠道。用户跑来问的是“服务器CPU动不动就告警这个能调吗在哪里改”如果你直接用这句话去做向量检索很可能召回到一堆关于“服务器CPU性能优化”的文章而不是那篇告警规则配置文档。为什么因为“调告警阈值”和“告警规则配置”之间的语义距离并没有你想象的那么近。用户脑子里想的是“动一下设置”文档里写的是“修改rule文件”这种表达方式的错位靠向量相似度很难跨越。查询重写要做的就是把这个鸿沟填平识别用户的真实意图把问题转化成和文档表述风格更接近的形式。1.2 查询重写在RAG管线中的位置和价值从RAG的完整流程来看查询重写处于“用户输入”和“检索器”之间。它可以是一段独立代码也可以内嵌到Agent的推理流程里。它的核心价值体现在三个方面。第一是提升召回率。原始查询太短、太模糊检索器拿到的信息量不足召回的候选集就不完整。重写后补充了同义词、上位词、相关术语候选集更丰富真正相关的文档更容易进入Top-K。第二是缩小语义偏差。用户口语化的表达和文档书面化的描述之间存在系统性偏差重写相当于做了一次“方言到普通话”的转换。第三是支持复杂查询。多跳问题、对比问题、带约束条件的问题需要拆分成多个子查询分别检索最后再融合结果这一步必须在检索之前完成。需要注意的是查询重写不是一个“必须做”的环节。我在后面的章节会详细说什么时候该做、什么时候不该做。但从优化ROI的角度看这个环节的性价比极高——你不需要重新训练任何模型只需要调好Prompt和策略组合就能显著改善检索效果。2. 查询重写的主流方法从简单到复杂选适合你的那一档2.1 查询扩展用同义词和相关词把查询“喂胖”最朴素的查询重写方法就是查询扩展Query Expansion。核心思路是在原始查询的基础上补充一些同义词、上下位词、相关概念让检索器有更多线索可抓。这里有一个关键点要注意不是无脑加词。加得太多会引入噪声反而降低检索精度。我在实践中的经验是扩展后的查询长度控制在原始查询的2到3倍比较合适。具体实现有两种常见路径。一种是基于统计和词表的扩展提前维护一个领域同义词表比如“告警”对应“报警”、“阈值”对应“界限值”、“卡顿”对应“性能瓶颈”命中就替换成文档常用词。另一种是基于Embedding的扩展用LLM或词向量模型找出和查询中关键实体相关的词再拼接到原查询后面。举个例子。原始查询是“服务器CPU告警怎么调”扩展后变成“服务器CPU告警怎么调 阈值设置 告警规则 报警配置 Prometheus rule”。这样即使文档里没用“怎么调”这种表述也能通过“告警规则”“阈值设置”这些词匹配上。我在实际项目里测试过简单查询用这个方法命中率能提升10到15个百分点。但查询扩展也有一个副作用如果你的检索器用的是稀疏检索比如BM25扩展词会直接参与词频统计效果明显如果用的是稠密向量检索扩展词需要重新编码进查询向量效果就会打折扣这时候可以考虑把扩展后的多个查询分别向量化再做结果融合。2.2 查询分解把复杂问题拆成多个“好回答的”子问题用户的问题一旦涉及多个实体或步骤比如“先A再B最后C对D有什么影响”直接拿整句话去检索结果往往是哪个都不靠。查询分解Query Decomposition就是解决这类问题的用LLM把复杂问题拆成多个逻辑上独立的子问题每个子问题单独检索最后把检索结果融合起来。举例来说问题“那个第三方登录模块升级之后之前做的数据同步脚本还能不能用”拆解后可能是两个子查询“第三方登录模块升级的变更内容”、“数据同步脚本依赖的接口和配置”。每个子查询的检索目标都更聚焦召回质量自然更高。实现分解的方式有很多。最简单的是写一个Prompt要求LLM“将用户问题拆解为2到3个与原问题等价、相互独立的子问题”然后对每个子问题分别执行检索。进阶一点的做法是让LLM输出JSON格式包含子问题和检索意图方便后续程序化处理。这里有一个值得注意的权衡查询分解会显著增加检索次数和LLM调用次数延迟和成本都会上升。我只推荐把它用在那些确实复杂的问题上——实际操作中可以用一个前置判断对少于15个字的简单查询直接走单路检索只有检测到多个实体或连词时才触发分解。2.3 HyDE先“编一个答案”再拿答案去检索HyDEHypothetical Document Embeddings是个挺巧妙的思路。它的核心逻辑是先让LLM针对用户问题生成一段“假设性的回答文档”这段文档虽然是模型基于常识生成的不一定准确但它的表述风格更接近知识库里的文档。然后拿这段假设文档去做向量检索而不是拿原始查询。为什么这招有效因为向量检索的本质是“文档到文档”的匹配而不是“查询到文档”的匹配。用户查询和文档之间的表述差异远大于两篇同主题文档之间的表述差异。HyDE相当于先把查询“文档化”把匹配问题拉回到模型更擅长的轨道上。我在一个项目里测试过HyDE的效果用户的线上提问多为口语短句而知识库是标准的技术文档。直接用原查询检索时Top-5命中率只有53%改用HyDE后命中率提升到71%。代价是每次查询需要多一次LLM生成延迟增加了大约300毫秒。但HyDE不是银弹。如果知识库里的文档本身就是零散的FAQ条目风格和LLM生成的假设文档差异大效果反而会下降。而且HyDE对LLM的生成质量要求很高如果LLM生成的假设文档偏离了正确答案检索结果会被带偏。我在实践中会给HyDE加一道保险把原始查询和HyDE生成的文档分别检索再做结果融合防止“偏了就是全偏了”。2.4 Step-Back Prompting往后退一步先问更抽象的问题Step-Back Prompting是另一种值得尝试的思路。它和HyDE有相似之处但方向相反HyDE是生成一个具体的假设答案Step-Back是生成一个更抽象的“元问题”。举个例子。用户的原始问题是“这个Hadoop集群的NameNode频繁重启是什么原因”Step-Back的问题可能是“Hadoop NameNode重启的常见原因有哪些”你看前者带着具体环境信息“这个集群”后者是更通用的领域问题。检索器对后者往往更容易找到高质量的相关文档因为知识库里关于通用原因的文档通常比针对某个具体集群的文档更多、更完整。实际落地时Step-Back可以替换原始查询也可以和原始查询并行检索再融合。我在一个案例里用Step-Back配合原查询做双路召回在文档覆盖度测试中涨了6个点。但要注意Step-Back更适合那些涉及特定场景的问题。如果用户问题本身就足够专业、抽象比如“Transformer的位置编码有哪几种”Step-Back反而会把问题变得过度笼统检索结果反而下降。2.5 LLM直接重写最朴素也最容易被低估的方法上面说的几种方法底层大多依赖LLM。其实最基础的做法就是直接让LLM把用户查询改写一遍要求“保持原意不变改写为更适合检索的查询”。我见过很多团队跳过这一步去追求复杂方案结果发现直接重写才是性价比最高的。关键在于Prompt要写清楚。我常用的模板是这样的告诉LLM“你是检索系统的查询优化器用户的问题将用于检索技术文档。请将用户的问题改写为更正式、包含关键术语、适合向量检索的形式。保留所有约束条件。只输出改写后的查询不要解释。”就这么简单效果却很稳。不过直接重写需要控制一个风险LLM可能自作主张添加知识库不存在的假设性细节导致检索方向偏掉。我会在Prompt里加一句“只能基于用户问题中已有的信息改写不得添加新的假设”并在代码里做一道校验——用重写前后查询的向量相似度设定阈值如果重写后的查询与原查询语义距离过远就自动放弃重写结果使用原查询。这个保护机制在真实场景里救了我好多次。2.6 各方法横向对比哪些场景选哪种策略方法核心思路适用场景主要开销风险点查询扩展补充同义词和相关词查询过短、关键词不匹配低一次词表查询扩展过度引入噪声查询分解拆分为多个子查询多实体、多跳问题中LLM调用多次检索拆分成碎块丢失上下文HyDE生成假设文档再检索口语查询vs书面文档中高一次LLM生成生成质量差导致检索偏航Step-Back生成抽象元问题具体场景追问通用规律中一次LLM调用过度抽象丢失细节LLM直接重写改写为检索友好形式绝大多数场景的默认选项低一次LLM调用LLM添加未提供的信息3. 动手实现一个查询重写模块架构、代码与实践3.1 整体架构先判断要不要重写再决定用什么策略基于前面的分析我在自己的RAG项目中最终落成了一个分层的查询重写模块。它不是一个“所有查询一律套同一个Prompt”的傻瓜模块而是先做判断、再选策略的组合式设计。第一层是意图判断。用一条轻量规则查询词数少于8个字、或包含明确的实体直接走原查询检索。因为这个体量的查询已经有了足够的检索目标重写反而可能引入偏差。第二层是策略选择。超过词数阈值的问题再根据问题特征分配策略包含“和、与、以及、然后、之后”等多实体标志词的走查询分解包含“为什么、原因是什么”等归因类问题的走Step-Back其他普通问题走LLM直接重写或HyDE组合。第三层是结果融合。重写后生成的多条查询可能包括原查询分别检索用RRFReciprocal Rank Fusion融合排序。这个架构的好处是灵活。你可以只启用其中一部分比如先上直接重写跑通后再加查询分解也可以全部启用按请求量动态调整策略比例。我自己的项目里最开始只做了直接重写后续才逐步补齐了其他策略。3.2 核心代码一个可配置的查询重写器下面这段代码是我在项目里的QueryRewriter核心实现去掉业务细节后大概长这样。它把策略放进一个字典里通过配置决定启用哪些策略。# query_rewriter.py from typing import Dict, List, Optional class QueryRewriter: def __init__(self, llm_client, enabled_strategies: List[str]): :param llm_client: 统一的LLM调用接口支持 chat(messages) - str :param enabled_strategies: 启用的策略列表 可选: direct, decompose, hyde, stepback, expand self.llm llm_client self.strategies { direct: self._direct_rewrite, decompose: self._decompose, hyde: self._hyde, stepback: self._stepback, expand: self._expand, } self.enabled [s for s in enabled_strategies if s in self.strategies] def rewrite(self, query: str, strategy: Optional[str] None) - Dict[str, List[str]]: 重写入口返回 {strategy_name: [query1, query2, ...]} 如果 strategy 为 None则对所有启用策略各自执行重写 if strategy is not None: assert strategy in self.strategies, funknown strategy: {strategy} return {strategy: self.strategies[strategy](query)} result {} for s in self.enabled: # 这里加上异常兜底避免单个策略报错影响主流程 try: result[s] self.strategies[s](query) except Exception as e: print(f[QueryRewriter] strategy {s} failed: {e}) result[s] [query] # 失败时回退到原查询 return result def _direct_rewrite(self, query: str) - List[str]: prompt 你是RAG系统的查询优化器。 用户的问题将用于检索技术文档。请将用户的问题改写为更正式、 包含关键术语、适合向量检索的形式。 要求 1. 保持原意不变只能利用原问题中的信息不得添加新的假设或细节。 2. 保留所有约束条件和限定词如时间、版本、环境名称。 3. 只输出改写后的查询本身不要解释不要加引号。 用户问题{query}.format(queryquery) rewritten self.llm.chat(prompt) # 基本清洗去掉可能的引号和多余空白 return [rewritten.strip().strip(\)] def _decompose(self, query: str) - List[str]: prompt 将下面的问题拆解成2到3个子问题。 要求 1. 子问题合在一起能覆盖原问题的全部信息。 2. 每个子问题应该聚焦于一个实体或一个方面便于检索。 3. 只输出JSON数组例如子问题1,子问题2。不要输出其他内容。 问题{query}.format(queryquery) raw self.llm.chat(prompt) # 这里简单用逗号切分实际项目建议用json解析器 parts [p.strip() for p in raw.strip().strip([]).split(,) if p.strip()] return parts if parts else [query] def _hyde(self, query: str) - List[str]: prompt 请根据以下问题用一段话模拟一个可能的回答文档片段。 文档风格要求书面、正式、包含相关技术术语。 注意这是一个假设性文档目的是用于检索匹配不需要完全准确。 问题{query}.format(queryquery) hyde_doc self.llm.chat(prompt) return [query, hyde_doc] # 返回原查询和假设文档便于后续融合 def _stepback(self, query: str) - List[str]: prompt 你擅长将具体问题抽象为更通用的元问题。 给定用户问题请生成一个更抽象、更通用的检索问题用于在知识库中找到基础原理或通用方案。 只输出抽象后的问题不要解释。 用户问题{query}.format(queryquery) stepback_q self.llm.chat(prompt) return [query, stepback_q] def _expand(self, query: str, max_terms: int 5) - List[str]: prompt 根据用户问题生成{max_terms}个与该问题主题紧密相关的检索词或同义词。 只输出用逗号分隔的词列表不要解释。 用户问题{query}.format(max_termsmax_terms, queryquery) raw self.llm.chat(prompt) terms [t.strip() for t in raw.strip().split(,) if t.strip()] # 扩展后的查询 原查询 关键扩展词同时保留一份纯扩展词列表 return [query .join(terms[:max_terms])]3.3 集成到RAG管线多路召回与RRF融合重写模块本身只是第一步更关键的是怎么把重写后生成的多个查询真正用起来。我的方案是“多路召回 RRF融合”。具体来说对于原始查询和重写生成的每一个查询都分别调用检索器得到各自的Top-K结果列表。然后对这些结果列表做RRF融合。RRF的计算方式不复杂对第r位的结果给它加一个分数1/(60 r)60是一个经验常数同样的文档如果在多个结果列表里出现分数就累加最后按总分排序。# fusion.py from collections import defaultdict def rrf_fusion(result_lists: List[List[str]], k: int 60) - List[str]: result_lists: 每个元素是[doc_id1, doc_id2, ...]按相关性降序 scores defaultdict(float) for doc_list in result_lists: for rank, doc_id in enumerate(doc_list): scores[doc_id] 1.0 / (k rank 1) ranked sorted(scores.items(), keylambda x: x[1], reverseTrue) return [doc_id for doc_id, _ in ranked]使用融合策略有两个好处。一是重写策略即使偶尔跑偏只要原查询还在召回列表里结果不会完全崩掉。二是不同策略召回的文档往往互补融合后整体覆盖度会更高。我在测试里发现单一策略重写后召回的Top-10文档和原查询召回的Top-10文档重叠度通常只有50%左右融合之后相当于把两个候选集合并了。3.4 评估方法别说“感觉好了”用数字说话查询重写到底有没有用、哪个策略更适合你的知识库要靠评估来给出答案。我把评估分成了离线指标和线上AB两个层面。离线层面最简单的做法是准备一组“问题-gold文档”的标注对。具体步骤是从你的知识库里挑出50到100个常见问题人工标注出每个问题对应的正确答案来源文档可以是多个。然后分别用原查询和重写后的查询跑检索看Top-5、Top-10里gold文档的命中率。这个指标叫RecallK重点关注Recall5因为RAG系统最终提交给LLM的上下文通常只有前5到10个文档。线上层面可以做更轻量的验证在真实请求日志里抽样把重写前和重写后的查询各跑一遍检索对比两边的平均相关性评分。如果没有人工评分也可以用最终回答是否被用户点赞、采纳来做代理指标。我自己的经验是组内自建的标注问题集涨了6到10个点线上收益才会肉眼可见如果离线只涨两三个点线上大概率是噪音。4. 实测案例查询重写在三组典型场景下的效果4.1 场景一口语化模糊查询某业务团队在系统里接入了RAG问答助手用户提问风格相当随意。比如有用户问“那个报表怎么每次刷新都特别慢是不是数据太多了啊”这个查询直接拿去检索向量匹配到的文档五花八门——“报表导出功能优化”、“数据库索引实践”、“前端性能优化”实际对应的《报表查询性能分析与优化》那篇文档反而排到了第11位进不了Top-10。用LLM直接重写后查询变成了“报表刷新速度慢的原因分析 数据量大对查询性能的影响 优化方案”这次《报表查询性能分析与优化》排到了第2位。关键原因就是重写把口语化的“特别慢”翻译成了“性能分析”把“数据太多”扩展成了“数据量大对查询性能的影响”和文档标题里的关键词对上了。这类场景是查询重写最典型的应用收益也最明显。4.2 场景二多跳复杂问题另一个来自开发者社区的案例问题涉及跨文档推理“那个消息推送模块之前说要改成异步架构那现在跑着的定时任务还得单独改不”这个问题里有两个实体“消息推送模块的异步架构”和“定时任务的适配”两者关联来自上下文中的“之间关系”。直接检索时向量模型把注意力分散到“消息推送”、“异步架构”、“定时任务”多个主题上Top-10里两份相关文档各出现一次但排位都在5名开外。用查询分解后拆出两个子查询“消息推送模块异步架构改造方案”、“异步架构下定时任务的兼容性调整”。分别检索后第一份文档排进子查询1的Top-1第二份文档排进子查询2的Top-2。融合后两个相关文档都进入最终Top-3。这个案例很好地体现了查询分解的价值——与其让一个模糊的大查询碰运气不如把问题拆成两个精准的小查询逐一击破。4.3 场景三术语不一致还有一个常见场景是术语不统一。如果你维护过一段时间知识库就会知道同名概念在不同文档里可能有完全不同的叫法。比如一个平台内部叫“契约服务”对外文档里却叫“接口协议服务”。用户问题里的术语和文档里的术语不一致时向量检索的表现很不稳定。我处理过一个具体案例。用户问的是“契约服务超时了怎么办”但知识库里相关的文档标题叫《接口协议服务超时排查指南》。两个查询里的核心实体词“契约服务”和“接口协议服务”在语义空间里的距离并不近。直接用原查询检索相关文档排在第7位。用查询扩展后我在同义词表里补充了“契约服务”对应“接口协议服务”重写为“契约服务(接口协议服务)超时了怎么办”相关文档直接跳到第1位。这个案例里最简单有效的方法反而是查询扩展而不是更复杂的HyDE或Step-Back。因为问题本身并不复杂只是术语需要对齐。这也是我强调“先判断、再选策略”的原因——方法没有绝对的高下之分只有是否适合当前场景。5. 容易踩的坑查询重写实战中的问题排查5.1 重写后效果反而变差语义漂移查询重写最常见的坑就是语义漂移——LLM重写后生成了一个和原问题“看起来相关但实际指向不同”的查询。有一次我们的线上检索在重写后召回率反而下降了3个点追踪到具体案例后发现LLM把用户问题里的一个环境名错误地理解成了另一个术语导致检索全部跑偏。排查这类问题我建议在重写模块里加一道语义相似度护栏。具体操作是用Embedding模型分别计算原查询和重写后查询的向量然后算余弦相似度。如果相似度低于某个阈值实践中我会先设为0.7再根据业务调优说明重写可能发生了语义漂移此时应丢弃重写结果回退到原查询。这个保护机制成本很低但能有效防止最坏情况的发生。另一个排查方向是检查Prompt是不是给了LLM“自由发挥”的空间。Prompt里如果没说“只能利用原问题中的信息”LLM很容易补上一些自己“脑补”的细节。我在3.2节的代码里特意强调了这一点不是随便写的是踩过坑之后的教训。5.2 延迟和成本失控不是所有请求都要重写查询重写每一路都要调LLM如果每个用户请求都走全套策略延迟会从100毫秒飙到800毫秒甚至更高成本也跟着上涨。在我负责的一个项目里最开始无差别全量重写线上P99延迟直接翻了一倍运营同学立刻来抱怨“太慢了”。解决办法是分层在3.1节里已经提到过先用低成本规则判断查询复杂度只有判断为“需要重写”的请求才进入LLM重写流程。具体的判断规则我推荐两条一是查询长度中文少于15个字符、英文少于10个token的查询通常信息密度已经足够直接检索即可二是关键词覆盖查询里如果已经出现了知识库索引里的高权重实体词也可以跳过重写。我在线上把重写覆盖率从100%降到了大约35%延迟回落到了原来的1.2倍而总体召回率只下降了不到1个点。另外可以给同一类查询加缓存。用户问的问题往往高度重复用一个简单的Redis缓存key用查询内容和重写结果的哈希值命中时直接返回省掉LLM调用。实测缓存命中率高的时候整体成本能再降30%。5.3 多路召回结果冲突融合顺序和权重怎么调用多路召回之后会面临一个新问题不同重写策略召回的Top结果不一样甚至互相矛盾。比如查询分解的子查询召回了一份文档而Step-Back召回的另一份文档到底该信谁我在实践中用RRF融合解决大部分冲突因为它同时考虑了“文档出现在多少个结果列表里”和“在每个列表里的排名位置”本质上是让多个策略互相投票。但有几种特殊情况要额外处理如果某一路召回的文档和查询的向量相似度明显低于其他路说明这路检索可能跑偏要在融合前先过滤掉相关性分数低于阈值的文档如果多个子查询召回同一份文档说明这份文档确实重要RRF会给它叠加高分这符合直觉。最后的兜底手段是把融合后的结果再交给一个“结果路由器”用一个轻量级分类模型或者一套规则判断哪些文档真正与用户问题相关。这一步在大多数场景下可以不做但如果你的知识库覆盖领域特别宽不同主题的文档可能互相干扰就有必要加。5.4 什么时候不建议做查询重写说了这么多查询重写的优势也得说说它的边界。有几类场景下查询重写不仅没用还可能帮倒忙。第一类是你的知识库本身就是FAQ风格问题和答案都已经足够口语化、短小精悍用户查询和知识库问题之间的表述差距很小重写的空间和收益都很低。这时候更应该花时间去优化检索器和Embedding模型而不是在查询上做文章。第二类是强事实型查询比如“某某接口的返回码是多少”“某某配置的默认值是什么”。这类查询的关键信息是精确的实体词和参数名重写时LLM很可能画蛇添足把精确的术语替换成了模糊的通用词导致检索失败。对这类查询我通常会在意图判断层加一条规则检测到代码、参数名、版本号、接口名等模式时直接跳过重写。第三类是低延迟场景比如实时客服交互用户等待时间要求不超过200毫秒。这种情况下一次LLM重写调用就可能超时宁可通过同义词表做轻量级的查询扩展也不要做完整的重写流程。最后分享一点我的实际体会做了这么多查询重写的项目我最大的感受是别把它当成一个“加个Prompt就完事”的功能。决定查询重写效果上限的是你能不能设计出一套合适的判断机制和评估体系。判断机制决定了哪些请求该重写、哪些不该重写避免把简单问题复杂化评估体系决定了你能不能持续迭代策略避免靠感觉调参。如果你现在正遇到“检索结果还行但不稳定”的困境我的建议是先从最简单的LLM直接重写做起加上语义相似度护栏和RRF融合跑一两周观察线上指标。等积累了足够多的失败案例再针对性地引入查询分解和HyDE。这条路走通之后你会发现RAG系统的检索瓶颈很多时候不在模型而在查询到文档之间的那层“翻译”。把这一层做扎实了其他环节的优化才能真正发挥价值。