这个想法很反直觉
HyDE 的全名是 Hypothetical Document Embeddings。第一次看名字时，我以为它只是 query rewriting 的另一种说法。读完以后发现不是。
普通 query rewriting 是把问题改写得更清楚。HyDE 是让语言模型根据问题先生成一篇“可能回答这个问题的假想文档”，然后把这篇假想文档编码成向量，再去真实语料库里检索相似文档。
它真正改写的不是 query，而是 query 的形态：从一句问题，变成一段像文档一样的语义样本。
为什么要绕这么一圈
稠密检索的难点在于 query-document relevance modeling。用户问题通常很短，表达方式也不一定接近文档内容。直接拿 query 做 embedding，有时候向量相似度并不能很好捕捉“哪些文档能回答它”。
HyDE 的做法是利用 LLM 生成能力：先写一段假想相关文档。这个文档不要求真实，甚至允许包含错误细节。重要的是，它要捕捉相关文档可能出现的语义模式。
然后无监督对比学习编码器会把这段假想文档映射到文档 embedding 空间。源笔记里有一句我觉得很关键：编码器的稠密瓶颈会过滤掉一部分幻觉细节。它保留的是语义邻域，而不是逐字事实。
它适合什么场景
HyDE 很适合没有相关性标注、又希望快速上线 zero-shot dense retrieval 的场景。
如果你刚接入一批文档，没有训练检索器的数据，直接 BM25 召回不够，普通向量检索又抓不住问题表达，HyDE 是一个很实用的增强方法。
但它并不一定提升效率。多了一次 LLM 生成，延迟和成本都会增加。更适合低频、复杂、召回质量重要的查询，而不是每个搜索请求都默认使用。
容易误会的地方
HyDE 不是让模型先回答，再相信它的回答。假想文档只是检索桥梁，最后要回到真实语料库。
这点很重要。如果工程系统把假想文档直接当证据，那就会把幻觉写进答案。正确用法是：假想文档负责把 query 带到更好的向量区域，真实文档才是生成答案的依据。
另一个风险是精确实体和私有领域。比如用户问一个非常具体的人名、编号、内部项目名，生成模型如果没见过，很可能写出看似相关但方向错误的假想文档。这个时候 HyDE 可能会把检索带偏。
和 RAG 系统的关系
我现在会把 HyDE 看成 RAG 的 query transformation 模块，而不是完整 RAG 系统。
它可以和 BM25、hybrid search、reranker、metadata filter 一起使用。比较稳妥的做法是保留原 query 检索结果，同时并行跑 HyDE 检索，再融合或重排。不要让一个生成出来的假想文档完全接管召回。
小结
HyDE 的核心是：短 query 和长文档之间有表达鸿沟，LLM 可以先生成一个语义桥梁。
这个桥梁可以有错，因为它不是最终证据。只要检索器能把它压缩到正确语义邻域，再从真实文档里取证，HyDE 就有价值。工程上要控制的，是成本、精确实体风险，以及不要把假想文档误当事实来源。