HyDE 假设文档嵌入：RAG 语义检索从“匹配关键词”到“理解意图”的实战解析

做过检索增强生成（Retrieval-Augmented Generation，RAG）的朋友大概都有这种体会：用户提了一个很合理的问题，可检索环节偏偏漏掉了最相关的信息。传统 RAG Pipeline 本身不弱，但它太依赖查询和文档分块之间的直接相似度匹配。一旦用户的措辞和文档里的写法存在差异，这套机制就容易失灵。

Hypothetical Document Embeddings（HyDE） 走了一条不同的路。它不是在“搜索文档”，而是让系统在正式开始检索之前，先想清楚一个理想的答案大致长什么样。

传统检索的痛点

绝大多数 RAG 系统的流程很直接：

Query → Embedding → Vector Search → Retrieved Chunks → LLM Response

向量数据库按照语义相似度做检索，但相似并不直接等于相关。来看一个例子：

Query:
"How can LangSmith help monitor LLM applications?"

如果存储的分块里从来没有出现过 “monitor”、“tracking” 或 “observability” 这类词，哪怕文档里其实有相关答案，检索质量也会明显下降。这带来了三类典型问题：对未见过的查询效果差、在领域专有术语上表现乏力、以及不相关的上下文被送进 LLM。检索一旦崩溃，生成环节通常也很难撑住。

HyDE 的设计思路

HyDE 是 Luyu Gao 提出的一种检索技术，核心构想是这样的：在向量检索之前，先让模型生成一份假设的答案文档。

不去直接把用户查询转换成 Embedding，而是走下面这几步：

User Query
      ↓
LLM generates hypothetical answer/document
      ↓
Create embedding of that hypothetical document
      ↓
Search vector database using this richer embedding
      ↓
Retrieve better context

这个想法的巧妙之处在于：生成的假设文档比简短的原始查询承载了更丰富的语义。检索系统据此搜索的是“上下文意图”，而不仅仅是停留在关键词层面的相似度上。

HyDE 的内部运行机制

完整流程如下。

1、用户提交查询，例如：

"What is LangSmith and why do we need it?"

2、LLM 根据查询生成一份假设文档。模型会写出一段可能回答该问题的合成文本，例如：

"LangSmith helps developers monitor, debug, and evaluate LLM applications..."

这份文档不追求事实完全准确，它表达的是“一个有用答案大致长什么样”。

3、将假设文档转为向量。这个向量通常比直接对原始查询做 Embedding 所获得的信息密度高得多。

4、用这个 Embedding 在向量数据库里执行相似度搜索：

Hypothetical Embedding → Similarity Search → Relevant Documents

检索关注的是概念层面的相关性，而非浅层的关键词匹配。

5、检索到的文档进入 RAG 的生成阶段，最终产出更准确、更贴合上下文的回答。

这套设计最大的好处是无需重新训练检索模型。仅仅改变查询的表达方式，就能带来检索质量的改善。

LangChain 中的实现

HyDE 能流行起来，其中一个原因是 LangChain 提供了现成的实现，可以直接拿来用。

from langchain.embeddings import OpenAIEmbeddings
from langchain.chat_models import ChatOpenAI
from langchain.chains.hyde.base import HypotheticalDocumentEmbedder

llm = ChatOpenAI(
    temperature=0
)

base_embeddings = OpenAIEmbeddings()

hyde_embeddings = HypotheticalDocumentEmbedder.from_llm(
    llm=llm,
    base_embeddings=base_embeddings,
    prompt_key="web_search"
)

query = "What is LangSmith and why do we need it?"

embedding = hyde_embeddings.embed_query(query)

LLM 生成假设答案，答案被转成 Embedding，随后 Embedding 被用于检索。代码改动量很小，但检索效果却可能有不小的提升。

总结

在那些文档很长、术语与用户表述差异大或者检索质量不稳定的 RAG 应用里，HyDE 尤其有用。传统 RAG 搜索的是“与查询相似的文档”，而 HyDE 搜索的是“与理想答案相似的文档”。就这么一个小小的视角切换，让检索变得聪明了不少。

在 云栈社区 的技术讨论中，这类围绕 RAG 和语义检索的优化实践一直是大家关注的热点话题，也欢迎入圈深入交流。

---

by Mangesh Jadhav