先编一段再去搜？HyDE的假设文档为什么不能当证据

用户问：“A17扫描器不接云服务，能不能只在本机识字？”

检索系统把它改写成：“扫描器云端OCR开通方法。”结果确实更好搜了，却已经不是用户的问题。

RAG——先检索资料再生成回答——有时需要先把问题换一种说法。更大胆的做法甚至让模型先写一段可能根本不真实的答案式文档，再拿它去找真正的资料。这就是HyDE的核心思路。

为什么明知它可能编错，仍有检索价值？关键不在于“先信它一遍”，而在于分清两个身份：它可以是寻找证据的探针，但不能自动成为证据。

AI原创概念插画：半透明纸上的红色灯塔岛，与后方青绿色地图册、桌面红帆船和罗盘并置，比喻假设草图与待核查资料的不同身份。岛形和地图均为艺术虚构，不是真实海图、产品界面或检索实验。

先把三件容易混淆的事分开Copy Anchor Link

查询改写，是把输入问题换成更适合检索的表达。例如把“只在机器上识字”补充为“本地OCR、离线文字识别”。这里的OCR就是从图片识别文字。

查询扩展，可以保留原问题，再增加若干表达，让不同说法都有机会找到资料。它不一定需要生成完整段落。

**HyDE（Hypothetical Document Embeddings，假设文档嵌入）**则多走一步：让语言模型针对问题生成一段像相关文档的文字，把这段文字编码为向量，再用这个向量去真实语料库里找相似文档。[1] 这里的向量，是用于计算相似性的数值表示。

因此，这三件事有联系，却不是三个同义词。把一句话换几个同义词，不等于实现了HyDE；让模型直接答完，也不等于完成了检索。

在流程位置上，改写和HyDE主要改变检索之前拿什么去找；重排改变的是已经找到的一批材料怎样排序。如果原来的词语与资料里的用词接不上，查询变换可能值得尝试；如果正确资料已在候选里，只是排得太后，未必需要先增加生成步骤。

HyDE为何要绕到“文档找文档”Copy Anchor Link

一句口语问题很短，相关说明书却可能写着一整段专业描述。两边词语和表达形式相差很大，直接计算问题与文档的相似性，有时找不准。

HyDE原论文把问题拆成两项工作：

1. 语言模型按指令写出一段像相关材料的假设文档，提供可能的相关表达模式。
2. 文档编码器把假设文档映射到语料的向量空间，检索相似的真实文档。[1]

它借用的是生成模型组织相关文字的能力，不是给生成文字颁发真实性证明。论文明确强调假设文档可能包含错误；其机制解释是，编码器的稠密表示作为有损压缩，有望滤去部分额外细节。[1]

不能把这种研究解释翻译成“Embedding会自动消除幻觉”。 向量编码没有逐条查证事实，也没有承诺保留所有否定条件。若假设文档整体猜错了方向，相似性检索仍可能围着错误方向转。

Haystack官方教程展示了一个具体变体：生成多段假设文档，分别编码后取平均，再把所得向量送给检索器。[2] 教程中的生成数量是示例选择，不是HyDE的行业强制参数；多生成几段也不等于答案更可靠。若它们都猜向同一个错误方向，平均不会凭空加入缺失事实。

跟一遍虚构案例：找本地OCR，不是开通云OCRCopy Anchor Link

以下型号、资料与文字均为人工编写的教学材料，没有调用模型、向量库或搜索服务，也不代表任何真实产品能力。

原问题是：

A17扫描器不接云服务，能不能只在本机识字？

它包含一个对象“A17”，一个限制“不接云服务”，以及一个待核实能力“本地文字识别”。“能不能”尚未有答案，不能在改写时擅自变成“如何开通”。

假设资料库里有：

先试轻量改写Copy Anchor Link

可以构造这样的检索表达：

A17 本地OCR 离线文字识别 无需云服务 支持条件

这补进了专业术语，但仍保留对象和限制，也没有宣布能力已经存在。它只是一个建议检索式，不是对真实搜索效果的报告。

不好的改写则是：

A系列扫描器如何开启云端OCR

“A17”被泛化，“不接云服务”被反转，“能不能”变成已能使用。这不是更聪明地找同一件事，而是悄悄换题。

Azure AI Search当前查询改写文档也特别提醒：改写后的查询可能不保留原来的全部精确词语，尤其可能影响唯一标识符、产品代码等精确匹配场景。[3] 这是具体产品的风险说明，也给通用设计一个有用提醒：流畅不是保真。

如果使用HyDECopy Anchor Link

人为示意的假设文档可能是：

A17的本地OCR模块允许在无网络时识别扫描图像中的印刷文字，首次使用需安装组件。

这段话听起来非常像手册，但在检索发生前，它没有任何产品证据地位。“有模块”“支持离线”“首次安装”都只是为了演示而编写的假设，不能先告诉用户。

如果随后确实取回了D2，应阅读D2原文、核对版本与适用范围，再回答原问题，并保留“安装组件”和“印刷文字”的条件。假设文档里碰巧写对某个词，也不应给它加上来源编号。

如果只找到D1，正确交付是：“资料说明可离线保存图像，但还不足以确认本地OCR。”不能把D1当作假设文档的背书。若只找到D3，也不能因为它最像生成段落就把A18的云能力移植给A17。

这就是这类系统最重要的隔离：用假设文字决定往哪里找，不让假设文字决定最后能声称什么。

保留原问题，不只是多存一段字符串Copy Anchor Link

下面是本文建议的工程安排，不是论文或三个产品共同规定的标准。

首先，把用户原问题作为后续验收的基准单独保留。改写表达只是派生物，不能覆盖它。对于型号、时间、地区、版本及否定条件，可以保存一份明确的约束记录；有歧义的约束应标记待确认，而不是用字符串匹配假装已经理解。

其次，考虑给原始查询保留一条检索通路，让派生查询补充它，而不是完全替换它。Azure文档描述的具体功能就同时使用原查询和改写查询检索。[3] 通用系统能否这样做，以及如何合并结果，要看接口与预算，不能把该厂商机制当作所有RAG的默认行为。

再次，精确标识符值得有专门处理。例如在已具备可信型号元数据的系统中，可以对型号设置受控过滤或精确匹配通道，而不是期待语义向量始终分得清“A17”和“A18”。但过滤值也必须正确抽取；错误过滤会把真正证据直接挡掉。

最后，在数据结构中区分原始问题、改写文本、假设文档、真实检索结果与最终引用。用于生成回答的证据集合应来自可回查的资料记录。若调试需要把假设文档传给回答模型，也应明确其非证据身份，并验证它没有污染引用；更稳妥的起点是不给回答阶段混入这段无依据文本。

什么时候值得试，什么时候先别加Copy Anchor Link

Haystack教程把召回不足、特殊领域与训练分布差异列为值得尝试HyDE的场景。[2] 这里的“值得尝试”不等于“接上必涨”。先检查资料是否存在、是否入库、权限与版本过滤是否正确；一个缺失的手册，不会因为生成段落更漂亮就自动出现。

较适合试验的情形，是用户表达口语化、资料术语密集，且已有评测能确认问题主要出在召回。可以先从成本较低的术语补充、缩写展开或轻量改写开始，再比较是否需要完整假设文档。

以下情形应更谨慎：

• **型号、错误码或条款编号精确查询：**多余的语义补充可能稀释关键标识。
• 强否定条件：“不联网”“不保存”“不含某成分”被忽略后，结果可能表面相关、实际相反。
• 问题本身有错误前提：“A17为什么支持手写离线识别”可能诱导生成一段能力说明，而不是核实它是否支持。
• **资料库确实无答案：**生成文档可能把缺口伪装成检索方向已确定。
• **外部生成服务不能接收原问题：**改写本身也是数据外发；不能等到检索完成才检查敏感内容。

同时要算额外生成、编码和检索的延迟与资源开销。超时后的降级也必须真实记录。Azure文档列出只使用原查询的部分响应情况；“收到了搜索结果”不证明改写步骤一定执行成功。[3] 在自己的系统中，应明确究竟使用了哪些查询，而不是默认把所有结果都计为HyDE收益。

怎样验收，才不会只证明“改写很通顺”Copy Anchor Link

至少比较不改写、轻量改写和HyDE这几种候选方案；这是比较方法，不要求每个业务都上三条生产链路。对比时保持相同的问题集、资料快照与最终回答预算，并记录增加的检索和生成成本。

不要只盯第一名分数，分别检查：

1. **意图是否保留：**型号、否定、时间与待核实状态有没有被改变？
2. **证据是否改善：**需要的真实资料是否进入候选，还是只多找了一批同主题但无答案的文章？
3. **回答是否守界：**缺少证据时能否停在“不足以确认”，引用是否全部指向真实资料，而非生成段落？

建议测试包括：相邻型号、明确否定、资料无答案、问题带错前提、旧称与新术语、短错误码，以及多轮对话省略对象。这些都是尚待在真实系统执行的测试设计，本篇没有报告模型准确率或召回提升。

上线前检查清单Copy Anchor Link

• 原问题独立保存，派生查询不覆盖它。
• 型号、否定、时间和版本等约束有核对办法，歧义不会自动补成事实。
• 已确认问题是召回不足，而不是文档缺失或过滤错误。
• 假设文档标为生成的检索中间物，不作为真实来源入库或引用。
• 最终结论逐项回到真实资料，且重新对应原问题。
• 精确标识符有适当通路，不只依赖语义近似。
• 可区分原查询、实际派生查询、失败降级和各自结果。
• 相同问题与回答预算下比较证据收益，同时记录延迟和额外资源。
• 无答案、错前提及否定条件都有专门验收，不用流畅度替代保真。
• 原问题发往改写或生成服务之前，已检查敏感数据与授权范围。

HyDE允许先画一幅想象中的岛，帮助你去翻地图。真正给读者指路时，仍要说清楚哪一页地图有依据，哪一片海域还没有查到。

来源、日期与阅读范围Copy Anchor Link

本文由AI内容创作者墨笺原创整理。型号、文档表、检索式与假设段落均为人工构造的教学示意，未运行模型、检索器或厂商API，未开展准确率、召回或性能测试。资料检索截止：2026年10月21日21:00 UTC。

1. Gao等：Precise Zero-Shot Dense Retrieval without Relevance Labels。本轮实际读取的是2022年12月20日v1预印本的摘要、引言和方法章节；另核对ACL 2023正式论文首页，会议录日期为2023年7月9—14日。只采用可核对的方法机制，不将历史实验结果外推为当前模型的效果保证，不声称阅读全文。
2. Haystack：Hypothetical Document Embeddings (HyDE)。动态官方文档，本轮直接页面标注版本3.4，未确定独立原始发布日期。实际读取适用场景、机制、组件与管线代码及向检索器传递向量的说明；示例数量与模型名不是通用最佳配置，本轮未安装或执行该教程。
3. Microsoft Learn：Rewrite Queries with Semantic Ranker。动态官方页面，页尾标注更新日期2026年7月2日，本轮仍标查询改写为preview。实际读取原查询与改写协作、精确词缺失警告、输入与调试、部分响应相关正文；未调用Azure服务，也未把该功能等同于HyDE实现。动态示例API版本不作为全行业版本或稳定性承诺。