搜索框里输入“帮我看看那个啥 自动能聊天的东西怎么用”，检索系统大概率会返回一堆不相关的结果。问题不在搜索引擎本身，而在于用户输入与系统理解之间存在着天然的鸿沟。查询重写就是在两者之间架起的一座桥梁：把口语化、碎片化、带错别字的原始输入，转化为规范、明确、信息充分的查询表达。这项技术在传统搜索引擎里已经应用了二十多年，如今在大模型驱动的RAG（检索增强生成）系统中，它的重要性更是被推到了新的高度。
为什么原始用户输入需要重写
用户输入的质量参差不齐是所有查询系统的常态。统计各类搜索日志可以发现，相当比例的查询存在拼写错误、缩写、方言化表达或者缺少必要限定词的问题。比如用户想查“Python列表去重”，实际输入的可能是“python list 去掉重复的”，甚至只有“pyhton 去重”。直接拿这样的字符串去做向量检索或者关键词匹配，召回质量可想而知。
另一个典型场景是多轮对话。用户第一轮问“GPT-4的上下文窗口多大”，第二轮接着问“那3.5呢”。单独看第二轮输入，“那3.5呢”几乎无法检索到任何有用信息，必须结合上一轮的语境把它重写成“GPT-3.5的上下文窗口大小是多少”，检索才能正常工作。这种指代消解和省略补全，是对话式RAG系统里查询重写最核心的职责之一。
此外，检索模型和生成模型之间存在语义空间的错位。用户的提问往往是一段自然问句，而知识库中的文档则是陈述性描述。用问句去检索陈述句，即使语义相近，向量相似度也可能偏低。查询重写可以把问句改写为更接近文档风格的表达，显著提升召回命中率。
常见的查询重写策略
工程实践中，查询重写大致可以分为四个层次，从简单到复杂依次是：纠错规范化、上下文补全、查询扩展和多查询生成。每种策略解决的问题不同，成本也差异巨大，实际系统往往组合使用。
纠错与规范化
这是最基础的一层，包括拼写纠错、同义词归一、大小写与全半角处理、繁简转换等。传统做法依赖词典和编辑距离算法，现在更多直接交给大模型处理。这一层成本最低，收益却很稳定，几乎是所有重写流水线的标配。
上下文补全
针对多轮对话场景，把历史轮次的信息融入当前查询，生成一个独立完整的新查询。这个新查询应该脱离对话历史也能被正确理解，因此也叫“查询独立化”。
查询扩展与分解
当一个复杂问题难以用单一查询覆盖时，可以将其分解为多个子查询分别检索，再把结果合并。比如“对比Redis和Memcached的性能”可以拆成“Redis性能基准测试”和“Memcached性能基准测试”两个查询。反过来，对于过于简短的查询，也可以通过扩展补充相关术语来提高召回。
下面这段Python代码展示了如何用大语言模型实现一个融合上下文补全与改写的重写函数：
from openai import OpenAI
client = OpenAI()
def rewrite_query(history: list, current_query: str) -> str:
"""结合对话历史重写用户查询，使其语义完整独立"""
# 拼接历史对话，保留最近三轮即可
history_text = "\n".join(
[f"{m['role']}: {m['content']}" for m in history[-3:]]
)
prompt = f"""你是一个查询重写助手。请根据对话历史，将用户的最新提问改写为一个语义完整、可以独立理解的查询。
只输出改写后的查询，不要任何解释。
对话历史：
{history_text}
用户最新提问：{current_query}
改写后的查询："""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
temperature=0
)
return resp.choices[0].message.content.strip()
# 使用示例：第二轮输入经过重写后变成完整查询
history = [
{"role": "user", "content": "GPT-4的上下文窗口是多大"},
{"role": "assistant", "content": "GPT-4 Turbo支持128K tokens的上下文窗口。"}
]
print(rewrite_query(history, "那3.5呢"))
# 输出类似：GPT-3.5的上下文窗口大小是多少
值得注意的是，重写时的temperature参数建议设为0，因为重写追求的是确定性和一致性，而不是创造性。同时历史轮次不宜带太多，最近两到三轮通常足够，过长的历史反而会引入噪声。
HyDE与多查询生成：两种进阶思路
除了直接改写用户输入，还有两种在RAG社区广泛讨论的进阶技术：HyDE和多查询生成，它们本质上都是查询重写的变体。
HyDE：假设性文档嵌入
HyDE（Hypothetical Document Embeddings）的思路非常巧妙：既然用户的问句和文档之间的语义空间不一致，那就干脆让大模型先根据问题“编造”一篇假设性的答案文档，再拿这篇假文档的向量去检索真文档。假文档虽然内容可能不准确，但它的语言风格、术语使用和真实文档高度相似，因此向量检索的命中率往往比直接用问句检索高出不少。
HyDE的代价是每次检索前都要额外调用一次大模型生成假设文档，延迟和成本都会上升。它更适合知识库文档风格统一、查询偏专业的场景，比如企业内部技术文档检索；对于通用闲聊类查询，收益就不明显了。
多查询生成
多查询生成的做法是让大模型把原始查询从不同角度改写出多个版本，全部送去检索，最后对结果做去重和融合（通常配合RRF，即倒数排序融合算法）。这种方案权衡了召回率和成本，是LangChain等框架中RAG模板的标准组件之一。
def multi_query_expand(question: str, n: int = 4) -> list:
"""将一个查询扩展为n个不同角度的查询"""
prompt = f"""针对下面的问题，从不同角度生成{ n }个语义等价但表达不同的检索查询，
每行一个，不要编号：
原始问题：{question}"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
temperature=0.7 # 扩展需要多样性，适当调高温度
)
queries = [q.strip() for q in resp.choices[0].message.content.split("\n") if q.strip()]
return [question] + queries[:n - 1]
# 示例输出：
# 原始：如何优化MySQL慢查询
# 扩展：MySQL慢SQL排查方法、数据库查询性能调优实践、
# MySQL慢查询日志分析、索引优化提升查询速度
可以看到，扩展查询时温度参数反而要调高一些，因为多查询生成追求的是覆盖面的多样性。而后续的RRF融合可以简单实现：对每个查询的检索结果列表，按排名计算倒数分数并累加，最终按融合分数重新排序，去重后取前K条。
工程落地中的成本与效果权衡
查询重写虽好，但每一次重写都意味着一次额外的模型调用，这在延迟敏感的线上系统里是不可忽视的代价。实际落地时需要从三个维度做权衡。
第一是模型选择。重写任务不需要顶级的推理能力，用轻量级模型（比如各类mini版本或开源7B模型）完全够用，成本可以压到旗舰模型的十分之一以下。很多团队还会对重写模型做微调，用业务日志中“原始查询-理想重写”的配对数据训练，效果和稳定性都会显著提升。
第二是触发条件。并非所有查询都需要重写，可以先跑一个轻量分类器判断输入是否存在拼写问题、指代省略或过于简短等特征，命中才走重写链路，其余查询直通检索模块。这种按需触发的设计能把整体额外延迟控制在很低的水平。
第三是效果评估。重写模块的评估不能只看改写文本“顺不顺眼”，要建立端到端的评测闭环：对比开启和关闭重写时，下游检索的召回率、MRR指标以及最终回答的准确率。一个实用的技巧是把重写前后的查询对和对应检索结果缓存下来，形成可持续扩充的评测集，用数据驱动迭代。
最后还要警惕过度重写的问题。模型有时会把原本简洁明确的查询改得冗长跑偏，反而稀释了关键信息。给重写模型加上“如果原始查询已经清晰完整，原样返回”的指令，并在prompt中明确改写的边界，是避免这类问题的有效手段。查询重写的本质是桥接用户语言与系统语言，而不是替用户重新提问，把握好这个度，才能让它在检索链路中发挥真正的价值。
查询重写Query RewritingRAG检索优化修改时间：2026-09-15 10:40:58