一、先聊聊这个让人又爱又恨的HyDE
大家做检索增强生成（RAG）的时候，肯定都听说过HyDE这个名字。它的全称是Hypothetical Document Embeddings，意思就是"假设文档嵌入"。说白了，它的思路很直白：当你问一个问题时，不是直接拿这个问题去向量库里找相似内容，而是先让大模型凭空"编"一篇假文档出来，然后用这篇假文档的向量去检索真实文档。
听起来是不是挺聪明的？确实，在很多场景下，HyDE能带来不错的提升，尤其是当你的问题写得很口语化、很简短，而库里的文档又特别长、特别正式的时候。比如你问"最近服务器老卡怎么办"，直接拿这句话去匹配，可能匹配到一堆无关的"服务器性能指标"之类的技术文档。但如果你让大模型先假装写一篇"服务器卡顿排查手册"，里面包含了具体的现象、原因、解决步骤，那再去匹配，命中率就高了很多。
但是，理想很丰满，现实很骨感。很多小伙伴在实际项目里发现，HyDE的效果并不稳定。有时候它表现神勇，有时候却还不如直接用普通向量检索。这是为什么？我们得把它的底层逻辑拆开看。
1.1 HyDE到底在干什么
为了让你看清楚，咱们用大白话举个例子。假设你是一个菜鸟运维，遇到一个问题："凌晨三点CPU突然飙到100%，重启又好了，怎么回事？"
如果直接用这句话去数据库里搜，数据库里的文档可能是这样写的："当系统负载过高时，建议查看top命令输出，分析进程消耗"。这俩的向量距离可能很远，因为你的问题是一个具体事件，而文档是一句通用建议。
如果用了HyDE，大模型会先根据你的问题，模拟生成一篇“假设文档”，大概是这么个东西：“本文档记录了某服务器在凌晨三点出现CPU占用率100%的现象，重启后恢复正常，可能的原因是：夜间定时任务冲突、内存泄漏导致频繁GC、或者冷启动时的资源争抢，建议排查crontab、查看GC日志、监控系统启动项……”
然后拿这篇假文档去向量库搜索，结果就很容易匹配到那些讲"CPU飙高排查""定时任务优化""GC日志分析"的真实文章。因为假文档里的“语义指纹”和真实文档更接近。
这就是HyDE的核心：你不必问得专业，大模型帮你把问题“翻译”成文档语言。
1.2 为什么效果会不稳定
既然是"翻译"，那就难免出错。如果大模型“翻译”出来的假文档偏离了真实文档的表述习惯，那检索效果反而会变差。比如你的问题本身就很模糊：“系统有点慢”，大模型可能生成一篇泛泛而谈的“系统优化指南”，结果搜出来一堆无关内容。
另外，HyDE非常依赖大模型本身的质量。如果你用的模型比较小，或者指令理解能力弱，它生成的假文档可能逻辑混乱、术语错乱，这就等于“用错误答案去搜索正确答案”，效果自然一言难尽。
还有一个被很多人忽略的问题：当你的向量库本身已经存在和问题高度相似的文档时，HyDE反而会“画蛇添足”。因为假文档是凭空生成的，它不一定能捕捉到你库里特有的术语和写法。比如你的数据库里全是英文资料，但你的问题是中文的，HyDE生成的中文假文档去匹配英文文档，效果就会大打折扣。
二、动手实验：从一次真实故障说起
纸上谈兵没意思，咱们直接上代码。假设你现在要做一个客服问答系统，内部知识库里存放了大量产品手册和售后记录。你发现用普通向量检索时，用户问“设备充电没反应”这种问题，老是匹配到“电池保养注意事项”，而不是真正解决充电问题的“充电器故障排查”。于是你决定用HyDE来试一把。
2.1 基础环境搭建
这一整篇我们都用Python + LlamaIndex来演示，版本是0.10.x。别担心，代码不多，核心逻辑都在注释里。
# 技术栈：Python 3.10 + LlamaIndex 0.10.x + OpenAI API
# 先安装依赖库：
# pip install llama-index-core llama-index-readers-file llama-index-embeddings-openai
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.core.retrievers import BaseRetriever
from llama_index.core.schema import TextNode, NodeWithScore
from llama_index.core.llms import ChatMessage, MessageRole
from llama_index.core.embeddings import resolve_embed_model
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.llms.openai import OpenAI
import asyncio
# 初始化嵌入模型和Llm
embed_model = OpenAIEmbedding(model="text-embedding-3-small")
llm = OpenAI(model="gpt-4o-mini", temperature=0.3)
# 假设我们有一个很小的知识库，里面就三条文档
fake_docs = [
"如果充电器损坏或接触不良，设备会显示充电图标但电量不增加。建议更换原装充电器并检查充电口是否有灰尘。",
"锂电池在温度低于0度时，充电速度会显著降低。若环境温度过低，请将设备移至温暖处充电。",
"客服处理退货时，需要用户提供购买凭证和故障视频，审核通过后方可退款。"
]
# 把文档切成节点并建立索引
nodes = []
for i, doc in enumerate(fake_docs):
nodes.append(TextNode(text=doc, id_=f"node_{i}"))
index = VectorStoreIndex(nodes, embed_model=embed_model)
代码很简单，三条文档代表三种情况：充电器坏了、温度低、退货流程。现在我们写一个普通检索和一个HyDE检索来对比。
2.2 实现普通检索
# 普通检索器：直接查询，不做任何加工
def normal_retrieve(query: str, top_k: int = 2):
retriever = index.as_retriever(similarity_top_k=top_k)
result = retriever.retrieve(query)
for item in result:
print(f"score={item.score:.4f} | text={item.node.get_content()[:45]}...")
return result
print("=====普通检索=====")
normal_retrieve("手机掉电很快怎么办")
输出大概是这样（每次运行可能略有差异）：
score=0.6743 | text=锂电池在温度低于0度时，充电速度会显著降低...
score=0.5921 | text=如果充电器损坏或接触不良，设备会显示充电图标...
你看，它把温度低的那条文档排在最前面，因为“掉电快”和“温度低”在语义上确实有点关联。但实际上用户真正想要的可能是充电器问题。这就是普通检索的局限。
2.3 实现一个简单版HyDE
接下来我们写一个HyDE检索器。它做的事情分三步：
- 调用大模型，根据用户问题生成一篇假文档。
- 把假文档向量化。
- 用这个向量去检索真实文档。
# HyDE检索器：采用“生成-编码-检索”三步走
class HyDERetriever(BaseRetriever):
def __init__(self, index, llm, embed_model, top_k=2):
self._index = index
self._llm = llm
self._embed_model = embed_model
self._top_k = top_k
async def _aretrieve(self, query: str):
# 1. 生成假设文档
hyde_prompt = f"""你是技术文档撰写专家。请根据用户的查询，模拟生成一篇可能存在于知识库中的、能解决该问题的技术文档片段。
要求：语气客观、包含具体现象和排查步骤，不要把文档写成回答，而是写成“一篇文档的开头部分”。
用户查询：{query}
请直接输出文档内容，不要解释："""
resp = await self._llm.acomplete(hyde_prompt)
hypo_doc = resp.text.strip()
print(f"\n[HyDE] 生成的假设文档：\n{hypo_doc}\n")
# 2. 对假文档进行向量化
hypo_embedding = self._embed_model.get_text_embedding(hypo_doc)
# 3. 用假文档的向量与库中所有真实文档的向量做相似度计算
# 注意：我们这里简化处理，直接用索引的向量存储来手动算相似度。
# 真实项目里可以使用向量检索接口，但原理一样。
node_ids = list(self._index._index_struct.nodes_dict.keys())
results = []
for nid in node_ids:
node = self._index.docstore.get_node(nid)
real_embedding = self._embed_model.get_text_embedding(node.text)
# 计算余弦相似度
dot = sum(a*b for a, b in zip(hypo_embedding, real_embedding))
norm_hypo = sum(a*a for a in hypo_embedding) ** 0.5
norm_real = sum(b*b for b in real_embedding) ** 0.5
score = dot / (norm_hypo * norm_real) if norm_hypo != 0 and norm_real != 0 else 0.0
results.append(NodeWithScore(node=node, score=score))
results.sort(key=lambda x: x.score, reverse=True)
return results[:self._top_k]
def _retrieve(self, query: str):
return asyncio.run(self._aretrieve(query))
# 使用HyDE检索
print("=====HyDE检索=====")
hyde_retriever = HyDERetriever(index, llm, embed_model, top_k=2)
result = hyde_retriever.retrieve("手机掉电很快怎么办")
for item in result:
print(f"score={item.score:.4f} | text={item.node.get_content()[:45]}...")
运行后你可能会看到类似输出：
[HyDE] 生成的假设文档：
当用户反馈手机掉电快时，首先检查是否启用了高耗电应用，然后检查充电器是否支持快充协议，最后检查电池健康度或是否存在后台持续唤醒进程。若充电器接触不良，也会导致充电不满且快速耗电。
=====HyDE检索=====
score=0.8921 | text=如果充电器损坏或接触不良，设备会显示充电图标...
score=0.7145 | text=锂电池在温度低于0度时，充电速度会显著降低...
很好，这次充电器文档排在了第一位。因为假文档里提到了“充电器接触不良”，跟第一条真实文档的语义高度重合。这就是HyDE的威力。
三、深入剖析：效果不稳定的根本原因
从上面的例子里你看出了什么？HyDE能不能发挥作用，主要看假文档“押题”准不准。如果假文档里提到的关键词和真实文档重合度低，那分数就会很难看。我们总结一下几个常见翻车场景。
3.1 场景一：问题本身太宽泛
比如用户问“我的设备坏了”，大模型生成的假文档可能是这样的：“设备故障一般分为硬件故障、软件故障和网络故障，需要逐步排查……”这种话放在任何文档里都适用，但它没有任何具体细节，跟任何一篇真实文档的相似度都差不多，检索出来的结果自然没着落。
3.2 场景二：知识库语言风格极度特殊
假设你的知识库全是内部缩写术语，比如“CMD-2模块”“RB切换失败”之类的。大模型不知道这些术语，它生成的假文档会使用大众措辞，比如“控制模块”“交互切换”。那么假文档的向量就会往“大众语义”方向偏，而你库里的文档全在“内部语义”区域，两者对不上。
3.3 场景三：假文档过于发散或过于简略
大模型的temperature参数设置不当，可能会让它“创造出”一些库里根本没有的细节。比如用户问“屏幕闪烁”，它生成假文档提到了“显卡驱动版本不兼容”，但你的库里根本没有显卡相关的文章，那检索结果就会跑到最相似的“显示器刷新率设置”上面去了。反过来，如果temperature太低，假文档又可能变成问题本身的重写，完全失去扩充信息的作用。
3.4 场景四：嵌入模型对假文档不友好
有些嵌入模型对“生成式文本”的向量化效果比对“自然问题”的向量化更稳定，而有些则相反。你没法随便用一款模型就默认效果好。特别是当你用开源嵌入模型（比如BGE、M3E）时，它对长文本和短文本的区分度可能不一样，而假文档通常比问题长，这就会引入偏差。
四、LlamaIndex里的高级优化策略
现在我们知道了问题出在哪，是时候动手优化了。LlamaIndex本身提供了不少工具，我们不用完全从零写HyDE。不过官方内置的HyDE实现比较简单，我们可以在它基础上做几个关键改动。
4.1 使用内置HyDE并调整提示词
LlamaIndex有一个HyDEQueryTransform，可以直接拿过来用。但我们不推荐直接用默认提示词，因为它太笼统。我们把它替换成更适合自己业务的中文提示词。
# 技术栈：Python 3.10 + LlamaIndex 0.10.x
from llama_index.core.query_transform import HyDEQueryTransform
from llama_index.core.llms import ChatMessage, MessageRole
from llama_index.core import PromptTemplate
# 自定义HyDE提示词（在LlamaIndex中，HyDE使用HyDEQueryTransform的pipeline）
# 旧版API是HyDEQueryTransform(llm=llm, include_original=True)，但为了灵活性我们直接改造。
from llama_index.core.indices.query.query_transform.base import (
HyDEQueryTransform as BaseHyDE,
)
class CustomHyDE(BaseHyDE):
def __init__(self, llm, sim_threshold=0.7, include_original=False):
super().__init__(llm=llm, include_original=include_original)
self.sim_threshold = sim_threshold
async def _aget_query_transform(self, query_bundle):
# 重写生成提示词，强调“要包含具体现象排查步骤”
prompt = (
"你是知识库检索助手。请根据用户的查询语句 {query_str}，"
"模拟生成一篇官方技术文档摘要。文档中必须包含："
"可能的原因、典型现象描述、排查动作。"
"只输出文档内容，不要输出任何前言后语。"
)
fmt_prompt = prompt.format(query_str=query_bundle.query_str)
resp = await self._llm.acomplete(fmt_prompt)
# 注意：这里的返回类型要符合基类预期，我们简化处理
return resp.text.strip()
# 实际使用中，我们可以直接构造HyDEQueryTransform并传入自定义prompt模板
from llama_index.core.prompts import PromptTemplate
custom_prompt = PromptTemplate(
"你是知识库检索助手。请根据用户的查询语句 {query_str}，"
"模拟生成一篇官方技术文档摘要。文档中必须包含："
"可能的原因、典型现象描述、排查动作。"
"只输出文档内容，不要输出任何前言后语。"
)
# LlamaIndex允许我们传prompt给HyDEQueryTransform的构造器
# 注意：这里采用兼容写法，不同版本API略有差异，建议查看官方文档
hyde = HyDEQueryTransform(llm=llm, include_original=False) # 替换为自定义prompt
不过你可能会发现，有些版本改起来比较麻烦。更简单的方式是绕开内置类，直接像我们在2.3节写的那样自己控制prompt。这样改动成本最低，而且完全可控。
4.2 引入“假设文档验证”机制
既然假文档可能“跑偏”，那我们可以在检索之后加一道“验证”工序。怎么做？让大模型看一遍检索出来的真实文档，判断它们是否真的能回答用户的问题。这种方法能有效过滤HyDE带来的“幻觉匹配”。
我们把它做成一个完整的检索流程：先用HyDE召回top10候选，然后让大模型对这些候选打“相关分”，再取分数最高的两个。
# 技术栈：Python 3.10 + LlamaIndex 0.10.x + OpenAI
from typing import List, Tuple
class VerifiedHyDERetriever:
def __init__(self, index, embed_model, llm, hyde_top_k=5, final_top_k=2):
self.index = index
self.embed_model = embed_model
self.llm = llm
self.hyde_top_k = hyde_top_k
self.final_top_k = final_top_k
def _generate_hypo_doc(self, query: str) -> str:
prompt = (
"请根据下面的用户问题，生成一篇可能存在于技术知识库中的文档片段。"
"要求：文档要包含具体的故障现象、可能原因和排查步骤。"
"直接输出文档内容：\n问题：" + query
)
resp = self.llm.complete(prompt)
return resp.text.strip()
def _embed_text(self, text: str) -> List[float]:
return self.embed_model.get_text_embedding(text)
def _cosine_sim(self, a: List[float], b: List[float]) -> float:
dot = sum(x*y for x, y in zip(a, b))
na = sum(x*x for x in a) ** 0.5
nb = sum(y*y for y in b) ** 0.5
return dot / (na * nb) if na > 0 and nb > 0 else 0.0
def retrieve(self, query: str):
hypo_doc = self._generate_hypo_doc(query)
hypo_emb = self._embed_text(hypo_doc)
# 收集所有文档及其相似度
node_list = list(self.index._index_struct.nodes_dict.keys())
candidates = []
for nid in node_list:
node = self.index.docstore.get_node(nid)
real_emb = self._embed_text(node.text)
score = self._cosine_sim(hypo_emb, real_emb)
candidates.append((node, score))
# 按相似度降序，取前hyde_top_k
candidates.sort(key=lambda x: x[1], reverse=True)
top_candidates = candidates[:self.hyde_top_k]
# 验证阶段：用LLM判断每个候选与用户问题的相关性
verified = []
for node, score in top_candidates:
prompt = (
"用户问题：{q}\n"
"候选文档：{doc}\n"
"请判断候选文档是否能有效回答用户问题。只回答‘相关’或‘不相关’。"
).format(q=query, doc=node.text)
resp = self.llm.complete(prompt).text.strip()
is_rel = "相关" in resp # 简单判断
verified.append((node, score, is_rel))
# 过滤掉不相关的，再按分数取final_top_k
filtered = [t for t in verified if t[2]]
if not filtered: # 如果全部不相关，那就返回原结果，但降低分数
filtered = verified
result = [(node, score) for node, score, _ in filtered[:self.final_top_k]]
return result
# 测试一下
retriever = VerifiedHyDERetriever(index, embed_model, llm)
result = retriever.retrieve("手机掉电很快怎么办")
for node, score in result:
print(f"score={score:.4f} | text={node.get_content()[:50]}")
这个流程多花了一次大模型调用，但能明显减少“HyDE幻觉”带来的错误召回。
4.3 混合检索：取长补短
另一个非常实用的优化方案是“混合检索”。把普通检索和HyDE检索的结果合在一起，然后做重排。这样即使HyDE跑偏了，普通检索也能把正确的文档捞回来。我们使用LlamaIndex的QueryFusion或者简单的加权合并。
# 技术栈：Python 3.10 + LlamaIndex 0.10.x
# 简单实现加权融合检索，不依赖额外插件
def hybrid_retrieve(query: str, weight_normal: float = 0.5, weight_hyde: float = 0.5, top_k: int = 2):
# 获取普通检索结果
normal_retriever = index.as_retriever(similarity_top_k=top_k*2)
normal_result = normal_retriever.retrieve(query)
# 获取HyDE检索结果（使用2.3节定义的HyDERetriever）
hyde_result = hyde_retriever.retrieve(query)
# 把两个结果合并成一个score字典
from collections import defaultdict
scores = defaultdict(float)
# 归一到0~1区间，这里我们直接用原始score，只是做个权重线性组合
for item in normal_result:
scores[item.node.node_id] += weight_normal * item.score
for item in hyde_result:
scores[item.node.node_id] += weight_hyde * item.score
# 按总分数排序，取top_k
sorted_ids = sorted(scores.items(), key=lambda x: x[1], reverse=True)[:top_k]
# 返回节点信息
final = []
for nid, score in sorted_ids:
node = index.docstore.get_node(nid)
final.append((node, score))
return final
# 运行融合检索
print("=====混合检索=====")
hybrid = hybrid_retrieve("手机掉电很快怎么办", weight_normal=0.4, weight_hyde=0.6)
for node, score in hybrid:
print(f"score={score:.4f} | text={node.get_content()[:50]}")
这里解释一下：权重是可以调的。HyDE的权重高，代表你更相信大模型生成的文档；普通检索权重高，代表你更相信原始问题。一般建议先用小样本数据调一下，找出最佳配比。
4.4 动态决定是否启用HyDE
我们还可以更聪明一点：不要对所有问题都用HyDE。有些问题本身就很具体，比如“查询订单编号A1001的物流状态”，直接用普通检索就行，因为订单号是唯一的，HyDE生成假文档反而会稀释这个明确信息。我们设定一个“问题明确度”判断，如果问题里包含具体实体（比如订单号、产品型号、人名），就直接用普通检索；否则用HyDE。
# 技术栈：Python 3.10 + 正则表达式
import re
def is_specific_query(query: str) -> bool:
"""判断问题是否包含高明确性的实体关键词"""
# 常见订单号/型号/编号模式
patterns = [
r"[A-Z]{2,}\d{4,}", # 例如 AB1234
r"\d{5,}", # 长数字
r"[A-Z]-?\d{3,}", # 例如 A-123
]
for pat in patterns:
if re.search(pat, query):
return True
return False
# 在检索入口处做决策
def smart_retrieve(query: str):
if is_specific_query(query):
print("检测到具体实体，使用普通检索")
return normal_retrieve(query)
else:
print("问题较模糊，使用HyDE检索")
return hyde_retriever.retrieve(query)
smart_retrieve("订单AB20240915一直显示待发货")
smart_retrieve("充电设备出问题了")
这里的例子比较简单，实际项目中你还可以用分类器或者大模型来判断。动态选择能最大化发挥两种检索的优势，同时避免HyDE的副作用。
五、实操中的注意事项与调参指导
光有代码还不够，你还需要一套调试方法论。以下是我踩过坑之后总结出来的重点。
5.1 注意你的知识库长度分布
HyDE生成的“假文档”通常有几百字，但如果你知识库里的文档特别短（比如一句话问答），假文档和真实文档的长度差异会导致嵌入表示不匹配。解决方法是：在生成假文档时，强制限制输出长度。比如在prompt里写“请生成不超过50字的文档”，或者把检索阶段改为“用假文档的摘要向量”而不是全文向量。
5.2 监控相似度分数分布
当HyDE检索出来的所有分数都偏低（比如全部低于0.6）时，说明假文档很可能跑偏了。你可以在代码里加一个弹性回退机制：如果最高分低于某个阈值，就自动改用普通检索。
# 技术栈：Python 3.10
def robust_retrieve(query: str, threshold: float = 0.65):
hyde_result = hyde_retriever.retrieve(query)
if not hyde_result or hyde_result[0].score < threshold:
print("HyDE置信度过低，回退到普通检索")
return normal_retrieve(query)
return hyde_result
这里的阈值需要根据你的嵌入模型和知识库内容来调整。观测方法很简单：跑一批已知正确结果的测试集，统计HyDE正确结果的平均分数，把阈值设为那个平均分的0.8左右。
5.3 调temperature别拍脑袋
HyDE生成器的temperature对结果影响很大。我试过多个值，经验是：
- temperature处于0.2~0.4之间时，假文档既不过于单调，也不会太发散。
- 如果设为0，生成的假文档过于保守，基本只是改写问题本身。
- 如果设为0.7以上，容易编造出库里不存在的具体细节。
你可以写一个循环来测试不同temperature对检索准确率的影响，但注意OpenAI的调用成本，用小样本数据集即可。
5.4 别忘了嵌入模型的对齐
HyDE的效果好坏，很大程度取决于嵌入模型对“描述性文本”与“问题文本”的语义空间对齐程度。建议使用专门为RAG优化的嵌入模型，例如text-embedding-3-large或开源的BGE-M3。如果你用中文知识库，优先选中文语料微调过的模型。注意：嵌入模型和检索向量库的模型必须是同一个，否则余弦相似度没有意义。
六、从实验到生产：一个完整的优化案例
为了让你看到整套策略的协同效果，我模拟一个客服工单系统。用户会提交各种口语化问题，我们要从售后知识库中找到最合适的处理流程。
6.1 构建一个小型测试集
# 技术栈：Python 3.10
test_queries = [
"手机在冬天户外自动关机了",
"充电器插上后手机没反应",
"退货退款流程怎么走",
"订单号SD20231108查不到物流",
"屏幕亮度调到最高还是暗",
]
# 对应的正确文档索引（假设0=充电器故障, 1=低温电池, 2=退货流程）
# 这里我们对3条文档，只能近似设定标签
correct_labels = {
"手机在冬天户外自动关机了": 1,
"充电器插上后手机没反应": 0,
"退货退款流程怎么走": 2,
"订单号SD20231108查不到物流": 2, # 库里没有，期望是退货相关，但实际可能无解
"屏幕亮度调到最高还是暗": 0, # 库里没有，期望可能是硬件故障，先不深究
}
我们接下来对比三种策略的命中率。
6.2 运行对比实验
# 技术栈：Python 3.10
def evaluate(strategy):
hit_count = 0
for q in test_queries:
result = strategy(q)
# 这里取返回的第一个节点，判断其ID是否符合正确标签
if result:
first_node = result[0].node if hasattr(result[0], 'node') else result[0][0]
# 简化：打印结果即可，人工判断
print(f"问题: {q} -> 第一个结果: {first_node.get_content()[:20]}")
print("-"*40)
print("普通检索:")
evaluate(normal_retrieve)
print("HyDE检索:")
evaluate(hyde_retriever.retrieve)
print("混合检索:")
# 由于我们函数定义在不同地方，这里偷个懒，直接定义混合包装
def hybrid_wrapper(q):
return hybrid_retrieve(q, weight_normal=0.5, weight_hyde=0.5)
evaluate(hybrid_wrapper)
因为我们的例子很小，命中率参考意义有限，但你会在真实数据中发现：单一HyDE的准确率往往不如混合检索稳定。混合检索就像是双保险，你的系统不至于因为HyDE“抽风”而完全崩溃。
6.3 加入重排序模块
还有一招很管用：在融合之后，用交叉编码器（cross-encoder）做最终重排。交叉编码器能把“问题-文档”拼接起来计算相关度，比双编码器（向量检索）更准确，但速度慢。我们可以只对融合后top20文档做重排，选top2，这样兼顾速度和准确率。
# 技术栈：Python 3.10 + sentence-transformers
# 先安装：pip install sentence-transformers
from sentence_transformers import CrossEncoder
# 加载一个中文交叉编码模型（也可以用你喜欢的）
reranker = CrossEncoder('BAAI/bge-reranker-base')
def rerank(query, candidates):
"""candidates是(node, score)列表，返回重排后的列表"""
pairs = [(query, node.get_content()) for node, _ in candidates]
# 模型输出相关分数，分数越高越相关
scores = reranker.predict(pairs)
# 结合原始分数和重排分数，这里简单按重排分数排序
combined = [(node, score) for (node, _), score in zip(candidates, scores)]
combined.sort(key=lambda x: x[1], reverse=True)
return combined
def enhanced_retrieve(query):
# 用混合检索得到top10
initial = hybrid_retrieve(query, weight_normal=0.5, weight_hyde=0.5, top_k=10)
return rerank(query, initial)[:2]
# 测试
print("增强检索:")
evaluate(enhanced_retrieve)
注意：交叉编码器比较重，如果你线上环境性能有限，可以换成轻量级的MiniLM类模型。另外，模型对中文的支持也需要验证。
七、技术优缺点和适用场景总结
优点方面，HyDE最大的好处是能弥补用户提问口语化与文档正式化之间的语义鸿沟。它相当于在检索前增加了一轮“语义归一化”。在很多长尾问题上，它能明显提升召回率。第二个优点是它不需要额外训练，直接就靠大模型通用能力来产出假设文档，部署成本很低。
缺点方面，第一是延迟和成本。每次检索都要调用大模型生成一次文本，如果是异步并发，还得考虑OpenAI限流问题。第二是稳定性差，对大模型能力高度敏感。小模型、弱模型、中文能力差的模型，很容易生成垃圾假文档。第三是调试困难。因为假文档是黑盒生成，你很难预判它到底会产生什么方向。需要监控相似度分数，观察假文档的内容，才能慢慢调整到最佳状态。
适用场景包括：用户问题短而意图模糊、知识库文档规范且较长的场景。比如客服问答、故障诊断、合规查询等。不适用场景包括：查询词是明确实体（如人名、地址、订单号）、知识库内容极其碎片化（每篇只有一句话）、对大模型推理能力要求过高的专业领域（如某些医学、法律术语，大模型生成的假文档可能不严谨）。
注意事项有几点：一定要评估好大模型调用的成本，可以用小模型来替代，但质量会下降。另外，生产环境建议加上缓存，对相同的用户问题缓存HyDE生成的假文档，避免重复调用。最后，不要盲目把HyDE应用在所有检索上，动态选择会更理性。
八、文章总结
今天咱们从HyDE效果不稳定这一现象入手，一步步拆解了问题原因，然后给出了四种优化策略：自定义提示词、验证过滤、混合检索、动态选择。这些策略不是互相孤立的，你可以组合使用，比如“动态选择 + 混合检索 + 重排序”就是一个非常鲁棒的生产级方案。
重要的是记住一句话：HyDE不是银弹，它是对原始检索的一种补充。正确的使用方式是把HyDE当作检索管道中的一个可选增强器，而不是默认逻辑。加上适当的回退机制和观测工具，你就能让它发挥出最大价值。
最后建议你多准备一些真实业务的测试查询，建立一个评测集，每次改动HyDE相关参数时，都跑一遍评测集，用准确率、召回率、平均倒数排名这些指标来量化效果。千万不要靠感觉调优，这样你才能在“不稳定的HyDE”里找到稳定。
Comments