检索资料之前，先让模型写一段可能的答案，这一步靠谱吗？资料还没找到，答案凭什么成立？查过 HyDE 原始论文和 Haystack 的实现文档后，可以把这一步的用途说清楚。生成的文字只负责帮助搜索，最终仍要找回真实文档。
HyDE 的中文可称为假设文档嵌入。2022 年的原始论文研究零样本稠密检索，面对的是缺少相关性标注的情况。普通查询往往很短，保存下来的资料却是完整段落，两者的表达距离可能很大。作者让指令模型先根据问题写一份假设文档，再将这份文字转换成向量，用它寻找语料中相似的真实文档。
论文明确承认，假设文档并不真实，里面可能有错误细节。这句话决定了整个方法的使用边界。系统可以借它接近相关主题，但不能把生成的型号、数字或人名直接写进最终答案，更不能给这些细节配上一个看起来像来源的链接。
中间那段文字怎样参与搜索
原始方法用经过无监督对比学习的编码器处理假设文档，示例包括 Contriever。编码器输出向量以后，搜索对象仍是已有语料。作者希望编码过程保留与相关性有关的表达，减少虚构细节带来的干扰。这个机制解释了为什么值得试验，也提醒人不能把它理解成自动纠错保证。
Haystack 文档给出了更具体的流程。示例对一个问题生成五份假设文本，分别编码后计算平均向量，再把这个向量交给检索器。这里的五份是文档展示的配置，实际工程需要单独测试生成数量。多生成几份会多一次选择，也会增加处理工作，不能只记住数量而忘记验收。
这份示例运行到最后只得到一个向量，后面还要接文档检索。找到资料以后，才轮到回答生成器读取原文，工程人员若在这之前就把中间结果显示成答案，检索辅助文本与事实依据会混到一起。排查时应当能分别看到原始问题、假设文本，以及最终命中的真实段落。
哪种问题值得花这一步
Haystack 将领域差异较大、检索召回不足列为适合试验的情况。我更愿意从已经查明的漏检问题入手。先确认资料确实存在，人工能指出应该命中哪一段，再比较直接查询与 HyDE 的结果。资料根本没有收录时，生成更多文字也补不出可引用的证据。
验收要留住原来的检索方案。用同一组问题跑两遍，观察正确资料是否进入候选，再检查错命中的资料。一个方法把候选扩得很宽，可能找回原来遗漏的段落，也可能让后面的排序更难。最终答案看起来更长，不能单独证明检索更好。
对需要迅速返回的问答，还要把生成假设文档的等待时间算进去。建议把这一项与检索本身的耗时分开记录，才知道代价花在哪里。若试验没有改善实际漏检，就保留较简单的流程。若改善稳定，产品里显示的引用仍应指向真实文档，中间那段假设文本留给排查人员查看就够了。