标准回答
一、要解决的问题
RAG 召回不准，常源于「查询-文档表达鸿沟」：用户问句往往简短、口语、含指代或缺少关键词，而知识库里是完整、书面、术语化的文档，两者在向量空间中并不靠近，导致语义检索召回低。
二、HyDE（Hypothetical Document Embeddings）
先用 LLM 针对用户问题生成一段「假设的答案/文档」，再对这段假设文本做 embedding 去向量库检索。由于假设答案与真实文档在用词、长度、风格上更接近，召回的相关性显著提升——本质是用生成把查询「拉进」文档的分布。
三、其他常见改写
包括查询扩写与消歧、指代消解、Multi-Query（生成多个改写并合并去重召回）、复杂问题拆成子问题分别检索。可与 ReAct 式多轮检索结合。
四、代价
每次改写多一次 LLM 调用，增加延迟与成本；HyDE 的假设答案可能含幻觉，需配合 rerank 和混合检索控制噪声。
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：HyDE 不要求假设答案事实正确——它只用于改善向量匹配，最终答案仍来自检索到的真实文档；误以为「假设答案错了就用错了」是常见理解偏差。
追问
追问 1：HyDE 在专业/低资源领域可能失效，为什么？
若 LLM 对该领域知识不足，生成的假设答案会偏离真实文档甚至误导检索。此时可改用关键词扩写、混合检索（稀疏+稠密）或先用领域语料微调嵌入模型，而非依赖生成式假设。
追问 2：Multi-Query 改写后如何合并多路召回结果？
对各查询的召回做并集去重，再用 reranker 统一重排取 Top-K；也可用 RRF（倒数排名融合）按各路排名加权合并，兼顾稳定性与覆盖面。
追问 3：查询改写应放在检索前还是交给 Agent 动态决定？
简单管线可固定前置改写；复杂场景更适合让 Agent 按首轮召回质量动态判断是否改写、如何改写，实现按需迭代，但要控制轮次以免延迟失控。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习