标准回答
要解决的问题（独占一行）
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 按首轮召回质量动态判断是否改写、如何改写，实现按需迭代，但要控制轮次以免延迟失控。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。
🛠️ AI 工具
- LangChain
最流行的 LLM 应用开发框架，137K+ stars。提供链式编排、RAG 检索增强生成、Agent 构建等核心能力，覆盖 Python 和 JavaScript 双语言生态，是构建 LLM 应用的基础设施
- LlamaIndex
文档 Agent 和 OCR 平台，48,716+ stars。领先的 RAG 框架，提供文档索引、数据检索、Agent 编排等完整能力，支持多模态文档理解和智能问答