在 RAG 系统中，检索质量直接影响最终回答的准确性。然而，用户的实际提问往往存在表述模糊、指代不明、过于口语化或信息不完整等问题。如果直接把原始问题丢给向量数据库进行相似度检索，很可能因为“词不达意”而错过正确的文档片段。
查询改写（Query Rewriting） 正是为了解决这一痛点而生。它的核心思路是：利用大语言模型本身的语言理解和生成能力，在检索前自动对用户的原始问题进行优化和扩展，使其更利于召回相关文档。
1. 为什么需要查询改写
用户提问的典型“不友好”表现包括：
- 过于简略：“那个政策怎么说的？”——缺乏具体政策名称，检索无法定位。
- 口语化或非正式：“这玩意儿坏了咋整？”——与知识库中“故障排除步骤”等正式写法差距大。
- 指代模糊：“上次提到的那个方案，现在还能用吗？”——缺乏上下文，不知道“上次”指什么。
- 一次性多问：“年假多少天？怎么申请？过期能折现吗？”——多个问题混杂，检索主题分散。
这些问题都会导致向量检索得分最高的片段并非真正所需的答案，从而影响最终生成质量。查询改写可以在保留用户原始意图的前提下，将问题转化为更适合检索的形态。
2. 改写的常见策略
大模型在查询改写中通常承担以下几种角色，可以单独或组合使用：
- 补全与澄清
如果问题中缺少必要信息，模型可以根据常识或历史对话补全上下文。例如将“那个政策怎么说的”改写为“2024年差旅费用报销政策的具体规定是怎样的”。
- 去口语化与规范化
将口语化表达转为正式、接近于知识库文本风格的措辞。例如“这玩意儿坏了咋整”改写为“XX设备常见故障的排查与修复方法”。
- 拆分复杂问题
当一个句子中包含多个独立问题时，将其拆分为多个子查询，分别进行检索，再将检索结果合并。例如将“年假多少天？怎么申请？过期能折现吗？”拆分为三个独立检索词：“年假天数规定”“年假申请流程”“未休年假折现政策”。
- 生成假设答案（HyDE）
这是一种更主动的改写方式：让大模型先假设出一个理想的回答（即使不百分百准确），再以这个假设回答作为检索词。因为假设回答与真实文档在表达方式上更接近，往往能召回更精准的片段。
- 多视角查询
对同一个问题生成多个不同表述的版本，分别检索后取并集，提高召回率。例如原问题是“笔记本开机慢”，可以生成“加快笔记本电脑启动速度的方法”“笔记本电脑启动慢的原因及解决方案”等多个并行查询。
3. 一个对比明显的案例
用户原始提问：“我买的那个笔记本电脑，最近开机要等好几分钟，之前不是这样的，怎么搞？”
- 未改写，直接检索
向量检索可能被“买的”“怎么搞”等不关键词语干扰，召回的结果可能是“笔记本电脑购买指南”“保修政策”等无关内容，回答质量差。
- 经大模型改写后
改写引擎输出：“笔记本电脑开机速度慢，启动时间长的解决方法。”
这个查询清晰、专业，与知识库中的《常见故障排除手册》高度匹配，成功召回相关段落，最终生成有效的解决步骤。
4. 实现方式与注意事项
查询改写可以作为 RAG 流水线中的一个独立预处理步骤，非常易于集成：
- 用户提问到达系统。
- 调用 LLM（可使用与最终生成相同的模型，也可使用更轻量的模型以节约成本）执行改写，提示词可以设计为：“请将以下用户问题改写为更适合检索的专业表述，保持原意不变：{原始问题}”
- 用改写后的查询（或生成的多个查询）进行向量检索。
- 将检索结果与原始问题一并送给生成模型。
需要注意的地方：
- 保持意图一致：改写不能扭曲用户原意。提示词中应强调“保持原意不变”，避免过度解读。
- 控制成本与延迟：查询改写引入了一次额外的 LLM 调用，会增加少量时间和成本。对于简单、清晰的问题，可以设置规则跳过改写步骤（例如问题长度足够、无明显口语化特征时直接检索）。
- 结合历史对话：在多轮对话场景中，改写时需要将历史提问一并提供，使指代消解和补全更准确。
5. 实际收益
引入查询改写通常能带来 10%~30% 的检索命中率提升，尤其在用户提问风格差异大、知识库文本相对正式的系统中效果更为显著。它让 RAG 系统对各种输入变得更加“宽容”，用户无需学习如何提问，就能获得高质量的答案，显著优化了端到端的用户体验。
查询改写看似简单，却是连接“人类随意提问”与“机器精准检索”之间最务实的桥梁，是构建稳健 RAG 系统时性价比极高的一项增强手段。