一篇读懂查询改写：检索质量的上限，常常在查询不在检索器

**一句话结论：很多 RAG 系统的检索质量瓶颈不在检索器，而在送进检索器的查询——查询改写（query rewriting）就是在「用户怎么问」和「索引怎么查」之间架一层翻译。**它有三代技术：传统搜索的查询扩展、LLM 时代的多查询改写与融合、以及生成式检索的 HyDE。理解这三代，你就能诊断大多数「向量检索不准」的问题其实是「查询没翻译好」。

先看问题：两种语言的对不上

用户的问题和索引里的内容，天然隔着一层：

词汇错位：用户问「服务器老是半夜崩」，文档里写的是「生产环境凌晨定时任务内存泄漏」——关键词对不上，BM25 没辙；向量检索虽然懂点语义，但对专业行话、缩写、口语转述的鲁棒性也有限。
问的是关系，查的是词：「A 和 B 哪个更适合我们的场景」这种比较型问题，直接拿去检索，往往召回一堆各自提到 A、B 但没做比较的段落。
多轮对话的指代：第二轮的「那第二个的报价呢？」脱离上下文什么都查不到——它压根不是一个自包含的问题。

本站《一篇读懂 BM25》讲过稀疏检索的机制，《混合检索与重排序》讲过三段式架构——它们都默认查询是「对的」。查询改写解决的是更上游的一层。

第一代：查询扩展——传统 IR 的老手艺

搜索引擎时代就有答案：别用用户的原词查，把它扩成一簇相关的词再查。同义词典、伪相关反馈（拿第一轮召回的 top 结果里高频词反哺查询，经典实现如 RM3）都是这一路。它的假设是：相关文档之间用词相近，所以「扩展后的查询」和「目标文档」的词汇重叠概率更大。

BM25 时代的查询扩展便宜、快、无需模型，但天花板明显：它只能扩「词形」，扩不出「意图」——用户问「服务器半夜崩」，扩展出来的还是「服务器崩溃半夜故障」，走不到「定时任务内存泄漏」。

第二代：多查询改写与融合——LLM 当翻译

LLM 进场后，查询改写从「扩词」升级成「改写意图」：

多角度改写：让模型把一个问题改写成 N 个不同表述/不同检索目标的查询（细节追问、关键词版、同义换说法），各自检索后融合去重。直觉是：一个问题有多个「可检索面」，单次检索只赌中一个面，多查询是对冲。
对话改写：多轮场景下，先让模型结合历史把「那第二个的报价呢？」改写成自包含的「B 方案的报价是多少？」，再送检索。这是对话式 RAG（AI 搜索的问答框、客服机器人）的标配中间层。
抽象化改写：Google 的 Step-Back Prompting（arXiv:2310.06117，ICLR 2024）展示了「先抽象再具体」的价值——先从具体问题提炼高层概念与第一性原理，再以此指导推理，在多跳问答上拿到显著提升（PaLM-2L 在 TimeQA 上 +27%）。用到检索上同理：先问「这个细节问题属于哪个大主题」，再从主题和细节两个粒度分别检索。

第三代：HyDE——先生成一份「假答案」再去查

最反直觉的一代是 HyDE（Hypothetical Document Embeddings，arXiv:2212.10496，Gao et al.）：让 LLM 先凭空写一份「假设的答案文档」，拿这份假文档的向量去检索真文档。

为什么拿假东西反而查得准？因为对比学习训练出的稠密检索器，比较的是文档对文档的相似度——「答案」和「答案」长得像，「问题」和「答案」隔着一层模态差。假设文档哪怕细节是编的（幻觉），编码器的稠密瓶颈也会滤掉错误内容、保留主题与风格的骨架，把它「落」回真实语料。论文实测：零样本场景下显著优于当时无监督最优的 Contriever，能媲美微调过的检索器，且在多语言任务上同样成立。

flowchart LR
    Q[用户问题] --> R[改写层]
    R -->|多查询| Q1[查询 × N] --> S[检索]
    R -->|对话改写| Q2[自包含查询] --> S
    R -->|HyDE| Q3[假设文档] --> E[向量编码] --> S
    S --> F[融合 / 去重 / 重排序]

按场景选型

场景	首选方法	理由
关键词/缩写多的专业查询	多查询改写 + 关键词版查询	术语错位靠扩写弥合，BM25 通道吃关键词版
多轮对话（AI 搜索框、客服）	对话改写（自包含化）	指代不消解，检索必然空转
零标注、冷启动的领域	HyDE	无需训练数据，直接借 LLM 的领域直觉
比较/多跳类问题	抽象化改写（Step-Back 式）	拆出子问题分头检索再合并
延迟敏感的在线路径	第一代查询扩展或干脆不改写	改写层每次调用都是一次 LLM 往返

两个必须盯住的坑

延迟与成本：每个改写动作都是一次模型调用。多查询 ×3 意味着检索量 ×3、且前面多一跳 LLM 延迟——在线系统要在收益和代价之间做预算，HyDE 的「先写一篇文档」在长文档上尤其贵。
查询漂移（query drift）：改写引入的不是信息，是模型的猜测——猜错方向，检索会系统性地错到同一个地方去，而且比不改写更自信。所以改写层必须进评测：本站《RAG 评测入门》里「检索层单独打分」的方法，就应该把「原始查询 vs 改写查询」作为对照实验跑。

小结

查询改写的本质是承认一件事：**检索系统的输入不是用户的问题，而是问题的可用检索表示。**这层翻译做得好，中等的检索器也能给出好结果；做得潦草，再强的向量模型也只是精确地查错了地方。在 AI 搜索把「答案质量」变成竞争主战场的今天，改写层已经从可选优化变成了标准件。

参考资料

Gao et al., Precise Zero-Shot Dense Retrieval without Relevance Labels（HyDE，arXiv:2212.10496）（2022-12，假设文档嵌入）
Zheng et al., Take a Step Back: Evoking Reasoning via Abstraction in LLMs（arXiv:2310.06117）（ICLR 2024，抽象化提示与多跳推理）
Abdul-Jaleel et al., UMass at TREC 2004: Novelty and HARD（TREC 2004，RM3 伪相关反馈的经典出处）