查询改写Query2Doc与HyDE

可视化演示

查询改写基础

想象餐厅里那位迷茫的顾客：“我想吃点热乎的。”这句话信息量太少——是汤？是面？是炖菜？推荐系统的“菜单”（文档库）里，每道菜都有固定的名字（词表），而顾客用的是生活语言。查询改写要做的，就是在这个中间架一座桥：把顾客口语化的、含混的、带指代的表达，翻译成菜单世界里能对号入座的语言。

查询改写通常出现在三类场景：第一，用户输入过于简短，缺少关键词，如输入“手机”但想找“防水安卓手机评测”；第二，口语与书面语不匹配，用户说“好用吗”而文档里写的是“用户体验良好”；第三，多轮对话中含有指代，比如“它怎么样”中的“它”到底指哪款产品。这些场景共同的特点是：原始查询与目标文档之间存在巨大的词汇鸿沟（lexical gap）。

完整的查询改写流程是一个三段式管道：改写（Rewrite）→ 增强（Expand）→ 检索（Retrieve）。先由大模型根据指令与原始查询生成改写结果，再将改写结果与原查询拼接或融合，最后用融合后的查询向量去文档库中检索。这一流程可以用一个简洁的公式概括：

回到餐厅的比喻：改写指令就像服务员培训手册里“如何引导顾客描述菜品”的话术，大模型是那位训练有素的服务员，而 q' 就是最终写下单子上的那行文字——既保留了顾客的意图，又让后厨能立即执行。

Query2Doc原理

既然顾客说不清想吃什么，不如先让他描述“这道菜端上桌时应该是什么样”。Query2Doc 正是这个思路：它让大模型基于一个简短的查询，生成一段“很像文档”的文字（称为伪文档），再把这段伪文档与原始查询拼接在一起，作为最终检索的输入。这段伪文档不需要很准确，只需要在主题上“靠近”真实文档，就能显著缩小查询与文档之间的语义鸿沟。

Query2Doc 的核心思想是“以文档补查询”。它基于一个直觉：如果查询本身是一段完整的文档，那么它与文档库中任何一篇文档的向量相似度都会更稳定、更有区分度。具体做法是：将原始查询 $q$ 输入 LLM，用 prompt 引导其生成一段长度为 150-300 词的文档，记为 $d_{\text{gen}}$；然后将 $q$ 与 $d_{\text{gen}}$ 拼接，得到融合查询 $q_f$；最后用 $q_f$ 的 embedding 执行稠密检索。

$$\displaystyle q_f = q \oplus d_{\text{gen}}$$

1. 拼接符号 $\oplus$：表示将两段文本按顺序连接，$q \oplus d_{\text{gen}}$ 就是“原始查询在前，生成文档在后”的新文本。

$$\displaystyle q_f = \text{concat}(q,\ d_{\text{gen}})$$

2. 原始查询 $q$：保留用户的原始意图，避免生成文档的偏差带偏检索方向。

$$\displaystyle q = \text{原始查询文本}$$

3. 生成文档 $d_{\text{gen}}$：由 LLM 基于 q 生成的伪文档，充当查询与文档库之间的“翻译中间人”。

$$\displaystyle d_{\text{gen}} = \operatorname{LLM}\left(\text{"请写一段文档"};\ q\right)$$

Query2Doc 最吸引人的地方是零样本（zero-shot）：不需要任何标注数据、不需要微调检索模型，只需调用一次现成的 LLM 就能拿到检索增益。在 BEIR 等标准基准上，Query2Doc 相比直接查询通常能带来 3-5 个百分点的 Recall@K 提升。回到餐厅：顾客描述“这道菜应该有一碗热汤、几片牛肉、一把面条”，服务员把这段话连同“想吃热乎的”一起递给后厨——后厨立刻明白，这碗“伪描述”比那句含糊的话靠谱得多。

HyDE原理

如果 Query2Doc 是让顾客描述“菜的样子”，那么 HyDE（Hypothetical Document Embeddings，假想文档嵌入）就是让顾客直接描述“吃完之后的感觉”。HyDE 的思路更加激进：让 LLM 针对查询 $q$ 直接生成一段“假想答案”（hypothetical document），然后用这段假想答案的向量去文档库中检索近邻，而不是用查询本身的向量。

HyDE 的关键洞察在于：生成式模型比判别式模型更擅长把握“答案长什么样”。虽然假想答案的细节可能是错的，但它的语句结构、词汇分布与真实文档高度相似，因此它的向量通常落在真实相关文档附近。这一步用公式表达非常简洁：

HyDE 同样无需微调、无需标注数据，但它对 LLM 的生成质量更敏感：如果假想答案偏离了真实文档的风格，检索效果可能反而不如原始查询。这就像让顾客描述“吃完之后的感受”，如果顾客想象力太丰富，说出“像是坐在云端”这种抽象的话，后厨依然无从下手。因此在文档风格稳定、主题集中的领域（如法律条文、医疗指南），HyDE 往往表现出色。

双法对比

两位“翻译高手”各有绝活。Query2Doc 像一位稳重的服务员：它把原话连同补充描述一起交给后厨，绝不偏离顾客本意，因此效果稳健、翻车概率低。HyDE 则像一位大胆的品酒师：它凭一句“这酒有橡木桶的味道”直接去酒窖里找酒，找对了惊艳全场，找错了南辕北辙。

从实现机制上看，两者的差异可以概括为三点：第一，Query2Doc 改写的是查询侧的文本，检索时使用“查询+伪文档”的拼接向量；HyDE 则直接放弃原查询向量，只用假想文档的向量做近邻搜索。第二，Query2Doc 对 LLM 输出质量的要求较低——即便伪文档质量一般，拼接后的查询仍保留原始信息；HyDE 则完全押注在假想答案的向量质量上。第三，从召回表现来看，Query2Doc 在大多数通用数据集上表现更稳定，而 HyDE 在主题高度集中的垂直领域有更高的上限，但方差也更大。

选型建议可以归纳为一个简单的判断标准：如果文档库的主题分散、风格多样（如通用网页搜索），优先选择 Query2Doc；如果文档库主题集中、格式规范（如法律法规、论文库），值得尝试 HyDE，并做严格评测对比。两者并非互斥——在工程实践中，完全可以同时运行两种改写，分别检索后取并集，把“谁说得准”交给下游重排模型去裁决。这就像让沉稳的服务员和大胆的品酒师分别推荐一道菜，把两道候选都端到评审（重排模型）面前，让专家定夺。

工程实现

纸上谈兵容易，真把“改写-检索”部署到线上系统时，工程细节决定成败。首先是最关键的 Prompt 设计。Query2Doc 的 prompt 通常类似：“你是一个搜索助手，请根据以下查询写一段相关的文档，用于提高检索效果。”而 HyDE 的 prompt 则强调生成“假设性答案”：“请直接回答以下问题，假设你拥有所有背景知识：……”。prompt 中应明确要求的文档长度、语气风格和包含的关键要素，这些都会显著影响改写质量。

向量化环节同样不可忽视。为了让检索质量稳定，改写后的查询与文档库中的文档应使用同一个编码器（如 GTR、Contriever），否则会出现“查询向量空间与文档向量空间不一致”的问题。此外，要区分编码器的输入上限：Query2Doc 拼接后的文本较长，需要确认编码器支持最大序列长度（通常 512 token），超长部分要做截断或分段池化。

检索融合是最后一道工序。最常见的做法是“改写查询检索结果 ∪ 原始查询检索结果”的召回归并——因为改写有时会引入噪音，保留原始结果相当于上一道保险。融合后的候选集交由重排模型（如 cross-encoder）精排。工程上还要设计好缓存与降级策略：改写有额外延迟（一次 LLM 调用），可对高频查询做缓存；当 LLM 服务超时或 fail 时，应优雅降级到原始查询检索。这些看似琐碎的细节，恰恰是线上检索系统稳定性的基石。

评估体系

如何判断这位“翻译服务员”干得好不好？不能只听他说“我翻译得很准”，要看顾客是否真正满意——在检索系统里，就是看检索结果是否真的把相关文档捞了上来。评估查询改写最常用的离线指标是 Recall@K（前 K 个结果中包含相关文档的比例）和 MRR（第一个相关结果的倒数排名）。前者关注“有没有捞到”，后者关注“排得够不够靠前”。

为了标准化对比，学术界常用 TREC 系列数据集与 BEIR 基准。BEIR 涵盖了 18 个异构检索任务，包括生物医学、金融、新闻等，是衡量查询改写方法泛化能力的黄金标准。一个值得注意的细节是：不同数据集上 Query2Doc 与 HyDE 的表现排名可能截然不同，因此实验结论必须注明测试集与配置，不能笼统地说“方法 A 优于方法 B”。

消融实验是评估的另一半。要分别验证三个问题：改写的 prompt 中哪些内容真正起作用；拼接查询中原始查询与生成文档各自贡献了多少（尝试只使用生成文档、只使用原始查询、两者拼接三种设定）；检索编码器更换后增益是否依旧成立。一个好的消融实验能帮你判断：性能提升到底是“改写”这个操作带来的，还是仅仅因为输入变长、信息变多。这就像餐厅试菜时要分别测试“换了主厨”和“换了食材”到底哪个让菜品变好吃的。

应用实战

理论落地时，查询改写在 RAG 与搜索场景中各有经典打法。在 RAG 场景中，用户提问往往口语化且信息稀疏，直接检索经常召回不相关片段。工程上通常把 Query2Doc 放在检索前：先将用户问题改写成一段“背景介绍”，再与原始问题拼接后检索，最后用生成器基于召回片段作答。例如面向企业知识库的问答系统，用户问“报销流程咋走”，Query2Doc 会生成“企业费用报销的流程包括提交申请、主管审批、财务审核……”的伪文档，从而精准命中知识库中的《报销管理制度》。

电商搜索是另一个高频落地场景。长尾商品查询如“适合送男友的生日礼物”包含大量主观描述，而商品标题是“机械键盘 青轴 电竞”。HyDE 在此类场景中生成“送男友的礼物应该体现科技感与实用性，比如机械键盘……”的假想答案，向量更贴近商品标题的语义空间。实际部署时还要注意多路召回：改写结果只是其中一路，要与同义词扩展、类目预测等传统信号并联，用重排模型统一打分。

应用中的常见坑点有三：一是改写结果过度自信——LLM 可能生成与事实不符的伪文档，污染检索向量，因此必须保留原始查询作为兜底；二是延迟预算失控——每条查询增加一次 LLM 调用会显著抬高 P99 延迟，需要缓存与异步化；三是不做端到端评估——只盯着改写结果的文本相似度，而忽略最终生成答案的准确率。每一项坑点都是“翻译服务员”在实际餐厅中可能犯的错，需要靠完善的监控与评测体系来兜底。

趋势展望

查询改写技术正沿着三个方向演进。第一个方向是与 RAG 深度协同：不再把改写当作独立的前置模块，而是让 LLM 在生成时“感知”检索结果，根据召回情况动态调整改写策略——就像服务员端上第一道菜后，根据顾客的反馈再决定是否需要重新推荐。

第二个方向是自适应改写。不同查询对改写的需求差异巨大：有的查询本身就很精确，改写反而引入噪音；有的查询极度模糊，必须大幅扩展。未来的系统会用一个小型分类器（或 LLM 自身）判断查询的“模糊度”，动态决定是否改写、用 Query2Doc 还是 HyDE、生成多长的伪文档。这相当于给服务员配备了一份“顾客表情解读手册”，不再对所有客人使用同一套话术。

第三个方向是多模态查询改写。随着多模态大模型的发展，查询不再局限于文本——用户可能上传一张图片问“这件衣服有没有其他颜色”，或者输入一段语音描述需求。多模态改写将把图像、语音等线索融入检索查询中，这超出了传统文本改写的边界。虽然这些方向尚未完全成熟，但底层逻辑依然清晰：改写的本质，永远是缩小用户表达与文档表达之间的鸿沟，只是鸿沟的两岸正在变得越来越宽。

AI 应用场景

Python 演示

import mathimport reimport heapq DOCS = [    "查询改写是RAG系统的关键组件,用于弥合用户表达与文档词汇之间的差距",    "HyDE通过大语言模型生成假想文档,再用假文档的向量执行最近邻检索",    "Query2Doc让LLM基于查询生成一段文档,拼接原查询后一起编码检索",    "向量检索常用余弦相似度衡量查询与文档的语义距离",    "RAG检索阶段的质量直接影响生成答案的事实准确性",    "零样本查询改写无需微调,仅依赖LLM的指令跟随能力",    "评估查询改写需要同时关注召回率与排序质量的提升",    "多轮对话中的指代消解是查询改写的重要应用场景",] def tokenize(text):    return re.findall(r"[\w\u4e00-\u9fa5]+", text.lower()) def build_index(corpus):    vocab = {}    dfs = {}    doc_vecs = []    for doc in corpus:        toks = tokenize(doc)        vec = {}        for t in toks:            vec[t] = vec.get(t, 0) + 1            dfs[t] = dfs.get(t, 0) + 1        doc_vecs.append(vec)    for t in dfs:        vocab[t] = len(vocab)    return vocab, dfs, doc_vecs def tfidf_vec(text, vocab, dfs, n):    toks = tokenize(text)    vec = [0.0] * len(vocab)    tf = {}    for t in toks:        tf[t] = tf.get(t, 0) + 1    for t, c in tf.items():        if t in vocab:            idf = math.log((n + 1) / (dfs.get(t, 0) + 1)) + 1.0            vec[vocab[t]] = c * idf    return vec def cos_sim(a, b):    dot = sum(x * y for x, y in zip(a, b))    na = math.sqrt(sum(x * x for x in a)) or 1.0    nb = math.sqrt(sum(y * y for y in b)) or 1.0    return dot / (na * nb) def search(query_text, corpus, k=3):    vocab, dfs, doc_vecs = build_index(corpus)    qvec = tfidf_vec(query_text, vocab, dfs, len(corpus))    scored = [(cos_sim(qvec, dvec), i) for i, dvec in enumerate(doc_vecs)]    return heapq.nlargest(k, scored) def query2doc_fake_llm(query):    return "该文档阐述了" + query + "的核心思想,包括方法定义、实现流程与典型应用。" def hyde_fake_llm(query):    return "这个问题的答案重点介绍" + query + ",具体步骤是定义问题、改写扩展、向量检索与融合排序。" def main():    q = "RAG查询改写怎么做"    print("原始查询:", q)    print("Top:", [DOCS[i] for _, i in search(q, DOCS)])    q_q2d = q + " " + query2doc_fake_llm(q)    print("Query2Doc Top:", [DOCS[i] for _, i in search(q_q2d, DOCS)])    h = hyde_fake_llm(q)    print("HyDE Top:", [DOCS[i] for _, i in search(h, DOCS)]) if __name__ == "__main__":    main()

1. def tfidf_vec(text, vocab, dfs, n):将文本转为 TF-IDF 权重向量，模拟真实场景中的稠密向量编码器
2. idf = math.log((n + 1) / (dfs.get(t, 0) + 1)) + 1.0稀有词获得更高权重，让改写后的长文本更突出主题词
3. def cos_sim(a, b):计算两个向量的余弦相似度，作为检索打分的核心依据
4. return heapq.nlargest(k, scored)取出相似度最高的 k 篇文档，模拟 Top-k 召回
5. def query2doc_fake_llm(query):模拟大模型生成一段“文档风格”的伪文本，代替真实 LLM 调用
6. q_q2d = q + " " + query2doc_fake_llm(q)执行 Query2Doc 的拼接操作，这是它与 HyDE 最本质的区别
7. h = hyde_fake_llm(q)生成 HyDE 的假想答案，后续直接用 h 检索而非原始查询

常见误区

面试题