用大模型的“生成力”弥补检索的“语义缺口”
在RAG系统中，用户的原始查询往往存在“简短、模糊、信息不全”等问题（如“合同纠纷怎么办”“线程池优化”），直接用于检索可能导致召回率低（漏检关键信息）或精度差（召回无关内容）。而**“多步骤查询改写”和“假设文档增强检索（HyDE）”** 两种技术，均通过大模型的生成能力扩充查询的语义信息，让检索更精准——前者通过“拆分细化”生成子问题，后者通过“生成假设答案”构建语义锚点，最终殊途同归提升RAG效果。
一、多步骤查询改写：将“模糊问题”拆分为“精准子问题”
当用户查询涉及多维度信息（如“分析某技术方案的优缺点”“拆解合同的风险点”），单一查询往往无法覆盖所有关键信息。多步骤查询改写的核心是：用大模型将原始查询拆解为多个逻辑连贯的子问题，通过子问题的联合检索覆盖更多信息维度。
原理：用大模型的“逻辑拆解能力”补全信息缺口
用户的模糊查询本质是“信息需求未明确拆分”。例如，“如何处理劳动合同违约”实际包含3个核心问题：
- 劳动合同违约的常见情形有哪些？
- 违约后法律规定的责任是什么（赔偿/继续履行）？
- 举证时需要准备哪些材料？
大模型可基于对领域知识的理解，自动识别这些隐藏的信息维度，生成结构化的子问题。每个子问题聚焦一个具体点，检索时能分别召回对应信息，避免因单一查询“贪多求全”导致的漏检。
实施步骤（以法律RAG为例）：
- 原始查询输入：用户问“劳动合同违约怎么处理？”
- 大模型生成子问题：
prompt = f"将查询拆分为3-5个具体子问题，覆盖核心信息：{原始查询}" sub_queries = llm.generate(prompt) # 输出：["劳动合同违约的情形有哪些？", "违约后的法律责任是什么？", "如何举证对方违约？"] - 子问题检索：用每个子问题的向量检索相关文档片段（如法条、案例），得到多组检索结果。
- 结果整合：将子问题对应的检索结果汇总，作为大模型生成最终回答的上下文。
适用场景：
- 复杂多维度查询（如“技术方案评估”“多条款合同分析”）；
- 需要分步骤推理的问题（如“故障排查”“流程优化”）；
- 原始查询包含隐含信息（如用户未明说但必要的前提条件）。
二、假设文档增强检索（HyDE）：用“虚拟答案”锚定真实信息
HyDE（Hypothetical Document Embeddings）的核心思路是：与其直接用简短查询检索，不如先让大模型基于查询生成一个“假设的理想答案”（虚拟文档），再用这个虚拟文档的向量去检索真实文档。因为虚拟文档往往包含更丰富的语义细节（如专业术语、逻辑关联），其向量与真实文档的匹配度更高。
原理：用“虚拟答案”的语义特征提升检索匹配度
用户的简短查询（如“线程池参数调优”）可能只包含核心词，但真实的技术文档会详细描述“核心参数（corePoolSize/maximumPoolSize）、调优场景（高并发/低延迟）、常见误区”等信息。此时，直接用“线程池参数调优”的向量检索，可能错过包含“核心参数设置”的文档；而大模型生成的虚拟文档（如“线程池调优需关注corePoolSize与任务类型的匹配，IO密集型任务建议设置较大值……”），其向量与真实技术文档的向量更相似，检索召回更精准。
实施步骤（以技术RAG为例）：
- 原始查询输入：用户问“线程池参数怎么调优？”
- 大模型生成假设文档：
prompt = f"基于查询生成一个详细的假设答案（无需真实依据，模拟理想回答）：{原始查询}" hypothetical_doc = llm.generate(prompt) # 输出："线程池参数调优需考虑任务类型：IO密集型任务（如网络请求）建议corePoolSize设为CPU核心数*2，计算密集型任务设为CPU核心数+1；maximumPoolSize需避免过大导致线程切换开销……" - 用假设文档向量检索：将虚拟文档转为向量，替代原始查询向量，在向量库中检索真实文档（如技术手册、博客）。
- 生成最终回答：用检索到的真实文档作为上下文，生成准确回答。
适用场景：
- 简短、模糊的查询（如“合同纠纷”“代码优化”）；
- 领域术语密集的场景（如法律、医疗、技术，虚拟文档能补充专业词汇）；
- 原始查询与目标文档的表述差异大（如用户说“怎么让程序跑快点”，文档说“性能优化策略包括缓存、异步处理”）。
三、两种方法的核心差异与协同
| 维度 | 多步骤查询改写 | HyDE（假设文档增强） |
|---|---|---|
| 核心逻辑 | 拆分查询为子问题，扩大检索覆盖范围 | 生成虚拟答案，用其语义锚定真实文档 |
| 信息扩充方式 | 横向扩展（覆盖多维度） | 纵向深化（补充细节与专业术语） |
| 检索对象 | 多个子问题向量分别检索 | 单个虚拟文档向量检索 |
| 适用查询类型 | 复杂、多维度查询（如“分析/拆解”类） | 简短、模糊查询（如“怎么办/是什么”类） |
协同使用：对于“复杂且模糊”的查询（如“如何优化分布式系统的性能问题”），可先通过多步骤改写拆分为“网络延迟优化”“缓存策略”“负载均衡”等子问题，再对每个子问题用HyDE生成虚拟文档，双重增强检索效果。
总结：用大模型的“生成力”弥补检索的“语义缺口”
用户查询与真实文档之间的“语义鸿沟”是RAG检索精度的核心障碍——多步骤查询改写和HyDE均通过大模型的生成能力填补这一缺口：前者通过“拆分”确保信息维度不遗漏，后者通过“虚拟答案”强化语义匹配度。在实际应用中，需根据查询复杂度和模糊程度选择方法，最终目标是让检索系统“读懂”用户的真实需求，召回更精准的信息，为大模型生成高质量回答奠定基础。