总结之 RAG向量检索：从查询转换到智能检索（二）

目录

1. 查询重写 / 重构检索 (Query Rewriting)
2. 子问题拆解 / 并行查询检索 (Question Decomposition)
3. 退一步检索 (Step-Back Prompting)
4. 假设性文档嵌入 (HyDE)
5. 混合检索 (Hybrid Search)
6. 父子文档检索 (Parent Document Retriever)
7. 迭代检索 / Agentic RAG
8. 七种策略横向对比总表
9. 行业成熟体系建议：L0-L4 分层架构
10. 总结与展望

---

一、查询重写 / 重构检索 (Query Rewriting)

1.1 详细原理说明

查询重写的核心在于语义标准化。它利用大语言模型（LLM）或专用小模型，在检索发生前对用户输入的原始自然语言进行"去口语化"和"指代消解"。其本质是将一个依赖上下文的非标问句映射为一个自包含的检索查询向量。

工作流程如下：

用户原始查询 → [LLM 改写模块] → 标准化查询 → 向量检索 → 返回结果
     ↓
(口语化/含指代)        (书面化/自包含)

1.2 为什么诞生（背景）

用户的真实提问往往充满"噪音"：

• 指代不明：“它怎么收费？”（"它"指代不明）
• 嵌套逻辑：“除了A之外，B和C哪个更适合？”
• 缺乏上下文：多轮对话中，后续问题往往省略主语
• 口语化表达：“怎么弄那个？”、“那个东西怎么用？”

直接将这些句子进行 Embedding，会导致生成的向量在语义空间中偏离真实意图，检索到的文档往往是字面相似但意图无关的内容。

1.3 解决了什么问题

• 指代消解：将"它"、"这个"还原为具体实体名称
• 意图聚焦：剥离"你好"、“请问”、"我想了解"等无意义前缀，降低长句带来的语义稀释
• 标准化：将口语转化为书面检索语，提升与知识库文档的语义对齐度

1.4 具体缺点

• 延迟增加：额外增加一次 LLM 调用，通常增加 200ms~800ms 延迟
• 意图漂移风险：若 LLM 理解错误，改写后的查询可能完全偏离用户原意，且这种错误难以被用户察觉
• 过度处理：对于"Python 列表推导式"这种已经非常精准的短句，重写反而可能引入噪声或改变关键词

1.5 行业成熟方案

• De-contextualization（去上下文依赖）：在 Prompt 中明确要求"将问题改写为独立句子，不依赖历史对话"
• 规则+模型混合：对高频业务术语使用同义词映射表或微调的 BERT 分类模型进行快速改写，仅对复杂长句调用通用 LLM
• 置信度过滤：若 LLM 改写后的查询与原始查询的向量相似度低于阈值，则回退使用原始查询

1.6 简单示例

原始问题	重写后查询	优化点
“它上面的功能怎么收费？”	“XX产品的功能定价方案是什么？”	消除指代词"它"，补全实体
“这个和那个有什么区别？”	“向量数据库 Milvus 和 Pinecone 的区别是什么？”	补全具体对比对象
“怎么弄那个？”	“如何配置 Kubernetes Ingress 资源？”	结合上下文补全操作对象
“它支持中文吗？”	“BGE-Reranker 模型是否支持中文文本重排序？”	消除指代，明确主体

---

二、子问题拆解 / 并行查询检索 (Question Decomposition)

2.1 详细原理说明

利用 LLM 的规划能力，将一个复合查询拆解为 N 个原子查询。系统并行（Fan-Out）执行 N 次向量检索，最后通过融合算法（如 RRF）将多路结果合并，去重后作为上下文。

工作流程：

复合查询 → [LLM 拆解] → [子查询1, 子查询2, ..., 子查询N]
                                    ↓ (并行)
                            [检索1] [检索2] ... [检索N]
                                    ↓ (合并)
                            [RRF 融合去重] → Top-K 结果

2.2 为什么诞生（背景）

向量空间具有语义压缩特性。当查询包含多个独立意图时（例如：“推荐一本适合初中生阅读的宇宙探索中文科普书”），Embedding 模型会试图在单一向量中同时表达"初中生"、“宇宙探索”、“中文”、"科普书"四个维度。这会导致向量漂移，检索结果可能只满足其中 2-3 个条件，或者在语义空间中迷失，无法精准命中同时满足所有条件的文档。

2.3 解决了什么问题

• 多意图覆盖：确保每个子需求都有独立的检索通道，避免"顾此失彼"
• 语义聚焦：每个子查询的向量更纯粹，检索精度更高
• 并行加速：利用现代向量数据库的并发能力，总耗时 ≈ 单次检索耗时 + 合并开销

2.4 具体缺点

• Token 消耗大：拆解和合并都需要 LLM 参与，成本随子问题数量线性增长
• 合并难题：多路结果的排序融合（Rank Fusion）如果处理不好，会导致高相关文档被低相关文档挤掉
• 拆解幻觉：LLM 可能拆解出知识库中根本不存在的问题，导致无效检索

2.5 行业成熟方案

• Fan-Out + RRF：标准范式。拆解 3~5 个子查询，并行检索 Top-20，使用 RRF 公式 Score(d) = Σ 1/(k + rank_i(d)) 进行融合，k 通常取 60
• 动态拆解：先让 LLM 判断是否需要拆解。若查询简单，直接走单路检索；若复杂，才触发拆解流程

2.6 简单示例

原始问题： “我想了解2024年AI领域的投资趋势，包括大模型、自动驾驶和AI芯片三个方向，各推荐一家头部公司并说明理由。”

拆解执行：

子查询 ID	拆解后问题	检索 Top-3 结果
Sub-1	“2024年大模型领域的投资趋势和头部公司有哪些？”	[Doc-A, Doc-B, Doc-C]
Sub-2	“2024年自动驾驶领域的投资趋势和头部公司有哪些？”	[Doc-D, Doc-E, Doc-A]
Sub-3	“2024年AI芯片领域的投资趋势和头部公司有哪些？”	[Doc-F, Doc-G, Doc-H]

最终结果： RRF 融合后，Doc-A（大模型+自动驾驶交叉领域）排名上升，Doc-F（芯片）独立保留，覆盖全部需求。

---

三、退一步检索 (Step-Back Prompting)

3.1 详细原理说明

受人类认知心理学启发：当遇到具体难题时，先思考其背后的基本原理或宏观背景。在 RAG 中，即生成一个比原始问题更抽象、更宽泛的 Step-Back Query，用其检索背景知识，再与原始问题的具体检索结果合并，共同喂给 LLM。

工作流程：

原始问题 → [LLM 抽象化] → Step-Back Query（抽象问题）
         → 同时 →        原始 Query（具体问题）
                              ↓ (并行检索)
                    [背景知识检索] + [具体事实检索]
                              ↓ (合并)
                        LLM 综合生成答案

3.2 为什么诞生（背景）

许多具体问题在知识库中没有直接对应的文档，但相关的原理性文档很多。

例如：“2024年诺贝尔物理学奖得主的具体贡献是什么？”

向量库可能没有这篇新闻，但有《诺贝尔物理学奖评选标准》或《近年量子物理研究方向综述》。直接检索具体问题可能返回 0 结果或低质结果，但检索"评选标准"能帮 LLM 建立推理框架。

3.3 解决了什么问题

• 冷启动/长尾问题：在缺乏具体事实文档时，利用背景知识辅助推理
• 推理幻觉：提供宏观约束，防止 LLM 在细节上"一本正经胡说八道"
• 知识缺口：用"原理"补全"事实"的缺失

3.4 具体缺点

• 粒度难控：退得太远（如"什么是物理？“）会引入海量噪声；退得不够（如"2024年诺贝尔奖是谁？”）等于没退
• 上下文窗口压力：背景文档通常较长，容易挤占具体事实文档的空间
• 依赖 LLM 抽象能力：若 LLM 无法生成恰当的抽象问题，策略失效

3.5 行业成熟方案

• Few-Shot 引导：在 Prompt 中提供 3-5 个"具体→抽象"的示例，隐式约束 LLM 的抽象粒度
• 双路召回：Final_Context = Retrieve(Original_Query) ∪ Retrieve(StepBack_Query)，通常 Step-Back 结果限制在 Top-3，避免淹没主答案

3.6 简单示例

• 原始问题：“2024年诺贝尔物理学奖得主的具体贡献是什么？”
• Step-Back 问题：“诺贝尔物理学奖的评选标准和近年研究方向有哪些？”
• 执行逻辑：
  1. 检索"评选标准" → 得到《诺贝尔奖章程》、《2020-2023年获奖领域综述》
  2. 检索"2024年得主" → 可能得到 0 结果或仅新闻标题
  3. LLM 综合：基于章程中的"重大发现"标准，结合新闻标题，推理出最可能的贡献方向，并诚实说明"具体细节需查阅官方公告"

---

四、假设性文档嵌入 (HyDE - Hypothetical Document Embeddings)

4.1 详细原理说明

核心洞察：用户查询（Query）和答案文档（Document）在语义空间中存在不对称性：

• Query 是"问"，短小、抽象
• Doc 是"答"，详实、具体

HyDE 先让 LLM 针对 Query 生成一段"假设性答案"（哪怕内容是错的），再对这段假设文档做 Embedding，去向量库检索真实文档。

工作流程：

用户查询 → [LLM 生成假设文档] → 假设性文档文本
                                    ↓ (Embedding)
                            假设文档向量 → 向量库检索
                                    ↓
                            返回相似的真实文档

4.2 为什么诞生（背景）

在嵌入空间中，“怎么做红烧肉？” 和 “红烧肉的做法是：1. 切块 2. 焯水…” 的距离，往往不如 “红烧肉的做法是…” 和 “糖醋排骨的做法是…” 的距离近。Query-Doc 的语义鸿沟是纯向量检索的痛点。

4.3 解决了什么问题

• 语义对齐：将 Query 映射到 Document 的语义空间，显著提升召回率
• 短查询增强：对于"K8s 报错"这种极短查询，HyDE 能自动补全"Kubernetes Pod CrashLoopBackOff 常见原因及排查步骤"等丰富语义

4.4 具体缺点

• 双重延迟：生成假设文档 + 向量检索，延迟翻倍
• 事实幻觉干扰：如果 LLM 生成的假设文档包含错误事实（如错误的参数名），向量检索可能会精准命中包含该错误事实的文档，导致"错上加错"
• 成本：生成 Token 消耗

4.5 行业成熟方案

• HyDE + Original Query 混合召回：不要只用 HyDE 结果。Results = Retrieve(HyDE_Doc) ∪ Retrieve(Original_Query)，利用原始查询的精确匹配兜底
• 场景限制：仅用于冷启动、极短查询或高难度语义匹配场景，常规查询不启用

4.6 简单示例

• 用户查询：“怎么做红烧肉？”
• HyDE 生成：“红烧肉是一道经典中式菜肴，主要食材为五花肉，烹饪步骤包括：1. 五花肉切块焯水；2. 锅中放油加冰糖炒糖色；3. 加入五花肉翻炒上色；4. 加入葱姜八角等调料；5. 小火慢炖1-2小时至软烂。”
• 检索动作：对这段 100 字的假设文本做 Embedding，在向量库中检索
• 结果：成功召回《中华菜谱大全-红烧肉篇》，因为假设文本与真实文档在句式结构、关键词分布上高度一致

---

五、混合检索 (Hybrid Search)

5.1 详细原理说明

同时执行两路检索：

1. 稀疏检索 (Sparse)：基于 BM25/TF-IDF，擅长精确匹配（专有名词、型号、代码）
2. 密集检索 (Dense)：基于向量相似度，擅长语义理解（同义词、概念、意图）

最后通过 RRF 或 Cross-Encoder 对两路结果进行融合排序。

5.2 为什么诞生（背景）

• 纯向量检索：用户搜 “iPhone 15 Pro Max”，可能召回 “Apple 最新旗舰手机”，因为语义近，但丢失了精确型号
• 纯关键词检索：用户搜 “手机发烫怎么办”，可能召回 0 结果，因为文档里写的是 “设备过热解决方案”，字面不匹配

成年人不做选择，全都要。

5.3 解决了什么问题

• 精确 vs 语义：兼顾"字面匹配"的准确性和"语义匹配"的泛化性
• 长尾词/专有名词：解决向量模型对生僻词、内部代号不敏感的问题

5.4 具体缺点

• 分数不可比：BM25 分数范围是 0~∞，向量分数是 0~1，绝对不能直接相加
• 工程复杂度：需要维护两套索引，融合排序逻辑需调优
• 资源消耗：存储和计算成本接近翻倍

5.5 行业成熟方案

• RRF 融合：Score(d) = Σ 1/(k + rank_i(d))，k=60。无需归一化，对异常值鲁棒，工业界事实标准
• Cross-Encoder 重排：BM25 Top-50 + Dense Top-50 → 取并集 Top-100 → Cross-Encoder 精排 → Top-5。这是精度天花板方案

5.6 简单示例

检索方式	查询：“K8s 1.28 变更日志”	查询：“容器编排太复杂了”
纯 BM25	✅ 精准命中《K8s 1.28 Changelog》	❌ 召回 0 结果
纯 Dense	⚠️ 召回《K8s 新版本特性》（语义近但非精确）	✅ 召回《K8s 架构简化指南》
Hybrid + RRF	✅ Top-1: 《K8s 1.28 Changelog》	✅ Top-1: 《K8s 架构简化指南》

---

六、父子文档检索 (Parent Document Retriever)

6.1 详细原理说明

索引阶段：

• 父文档 (Parent)：按语义或固定长度（如 1000 token）切分的大块，保留完整上下文
• 子块 (Child)：将父文档进一步切分为小块（如 200 token），用于精准检索
• 绑定：在向量库中，每个 Child 的 Metadata 记录其 Parent 的 ID

检索阶段：

• 用 Query 检索 Child，命中 Top-K 个 Child
• 通过 Metadata 找到对应的 Parent ID
• 去重 Parent，返回 Parent 文档内容给 LLM

6.2 为什么诞生（背景）

• 切分太细：检索精准，但 LLM 看到"第二步是初始化 master 节点"，不知道第一步是什么，上下文断裂
• 切分太粗：上下文完整，但向量被"平均化"，检索不到具体细节，召回率低

既要检索的"针"，又要上下文的" haystack"。

6.3 解决了什么问题

• 上下文完整性：确保 LLM 拿到的永远是逻辑完整的段落/章节
• 检索颗粒度：允许用极细的粒度（句子级）去匹配用户问题

6.4 具体缺点

• 存储膨胀：Parent 和 Child 都要存，元数据管理复杂
• 切分逻辑：如果原文档结构混乱（如 PDF 乱码），父子关系可能绑定错误
• Token 浪费：一个 Parent 可能包含 5 个 Child，但只有 1 个相关，其余 4 个无关内容也喂给了 LLM

6.5 行业成熟方案

• LangChain/LlamaIndex：内置 ParentDocumentRetriever，自动处理切分和元数据绑定
• 动态窗口：命中 Child 后，不返回整个 Parent，而是返回 Child ± 2 个邻居块，平衡上下文与 Token 成本

6.6 简单示例

• 原文档 (Parent)：《K8s 部署指南》（2000字，含 10 个步骤）
• 切分 (Child)：
  • Child-01: “第一步：安装 containerd…” (200字)
  • Child-02: “第二步：初始化 master 节点…” (200字)
• 用户问：“如何初始化 master 节点？”
• 检索：精准命中 Child-02
• 返回：通过 Parent_ID 找到《K8s 部署指南》，返回完整 2000 字（或 Child-02 ± 邻居块），LLM 可看到前置条件"安装 containerd"，回答更严谨

---

七、迭代检索 / Agentic RAG

7.1 详细原理说明

将 RAG 从线性流水线升级为有状态循环：

1. Plan：LLM 分析查询，生成初始检索计划
2. Act：执行检索
3. Observe：LLM 评估检索结果：“信息够吗？有矛盾吗？需要补充吗？”
4. Reflect：若不够，改写查询或新增子查询，回到 Step 2
5. Final Answer：信息充足，生成答案

7.2 为什么诞生（背景）

现实世界的问题往往是多跳 (Multi-Hop) 或条件依赖的。

“特斯拉 2024 营收中，汽车和能源各占多少？”

• 第一次检索"特斯拉 2024 营收" → 只得到总数
• 系统必须意识到"缺少分项数据"，并主动发起第二次检索

传统 RAG 是"瞎子摸象"，摸到什么算什么；Agentic RAG 是"侦探破案"，缺什么找什么。

7.3 解决了什么问题

• 多跳推理：A→B→C 的链条式问题
• 自我纠错：检索到错误文档时，能识别并重新检索
• 信息补全：自动发现并填补信息缺口

7.4 具体缺点

• 延迟爆炸：每多一轮迭代，延迟 +1~3 秒，Token 成本 ×2
• 死循环风险：若 LLM 判断逻辑有误，可能陷入"检索→不够→检索→不够"的死循环
• 落地难：生产环境对 SLA 要求严格，难以容忍 5-10 秒的响应时间

7.5 行业成熟方案

• 最大迭代次数限制：Hard Code max_iterations=3，防止死循环
• 前置优化：90% 的问题通过 Query Rewriting + 子问题拆解 解决，不要轻易上 Agentic RAG
• 异步/流式反馈：在等待检索时，向用户流式输出"正在分析汽车业务数据…"，降低体感延迟

7.6 简单示例

• 用户问：“特斯拉 2024 营收中，汽车业务和能源业务各占多少？”

Iter-1：

• Query: “特斯拉 2024 营收”
• Result: “总营收 970 亿美元”
• Self-Critique: “只有总数，缺分项，需补充。”

Iter-2：

• Query: “特斯拉 2024 汽车业务营收” & “特斯拉 2024 能源业务营收”
• Result: “汽车 800 亿，能源 100 亿”
• Self-Critique: “数据充足，可计算占比。”

Final： “汽车占 82.5%，能源占 10.3%…”

---

八、七种策略横向对比总表

8.1 核心特性对比

策略名称	所属阶段	是否需要 LLM	延迟影响	工程复杂度	适用场景	核心优势	核心劣势
查询重写	检索前 (Pre-retrieval)	是	中 (200-800ms)	低	口语化/含指代的查询	低成本提升检索准确率	可能意图漂移
子问题拆解	检索前 (Pre-retrieval)	是	高 (拆解+并行)	中	多意图复合查询	全面覆盖多需求	Token 消耗大
退一步检索	检索前 (Pre-retrieval)	是	中 (额外一次检索)	低	具体事实+背景知识结合	解决冷启动/长尾问题	粒度难把控
HyDE	检索前 (Pre-retrieval)	是	高 (生成+检索)	中	短查询/语义鸿沟大	弥合 Query-Doc 语义差距	延迟翻倍，幻觉风险
混合检索	检索中 (Retrieval)	否	低 (双路并行)	中	所有场景（基础标配）	精确+语义双覆盖	分数不可比
父子文档	索引/检索 (Indexing)	否	低	中高	长文档检索	兼顾检索精度+上下文	存储翻倍
Agentic RAG	检索中/后 (Retrieval+Post)	是	极高 (多轮循环)	高	多跳推理/极端复杂问题	自主纠错+信息补全	延迟爆炸，落地难

8.2 成本-效果矩阵

策略	实施成本	效果提升	推荐优先级
混合检索 (BM25+Dense+RRF)	低	高	⭐ 第一优先
查询重写	低	中	⭐ 第二优先
父子文档检索	中	中	⭐ 第三优先
Cross-Encoder Rerank	中	高	⭐ 第三优先
退一步检索	中	中	按需启用
HyDE	高	中	按需启用
子问题拆解	高	高	按需启用
Agentic RAG	极高	极高	极端场景

---

九、行业成熟体系建议：L0-L4 分层架构

在工程落地中，不要试图用一种策略解决所有问题。建议采用分层架构，按需升级：

L0 基础线：混合检索 + RRF

• 核心策略：BM25 + Dense 双路召回 Top-50 → RRF 融合 → Top-10
• 适用场景：80% 的常规问答、文档搜索
• 预期效果：解决精确匹配与语义泛化的基本矛盾，性价比最高
• 成本/延迟：⭐⭐（低）

L1 体验优化：查询重写 + 父子文档

• 核心策略：在 L0 基础上，加入 Query Rewriting 处理口语化提问，加入 Parent Document 解决上下文断裂
• 适用场景：口语化提问、多轮对话、长文档检索
• 预期效果：显著提升用户体感，回答连贯性大幅提升
• 成本/延迟：⭐⭐⭐（中）

L2 精度提升：Cross-Encoder Rerank

• 核心策略：在 RRF 之后接入 Cross-Encoder（如 BGE-Reranker）对 Top-30 进行精排，选出 Top-5 喂给 LLM
• 适用场景：对准确率要求极高的场景（如法律、医疗、金融合规）
• 预期效果：在 L0/L1 基础上，ROI 最高的精度提升一步
• 成本/延迟：⭐⭐⭐（中，需 GPU）

L3 复杂场景：子问题拆解 + Step-Back

• 核心策略：针对特定的复杂长尾问题，按需引入子问题拆解或 Step-Back
• 适用场景：多意图查询、冷启动/长尾问题、需要背景知识辅助推理的场景
• 预期效果：解决 L0-L2 无法覆盖的复杂场景
• 成本/延迟：⭐⭐⭐⭐（高，需审慎启用）

L4 智能体探索：Agentic RAG

• 核心策略：仅在单跳/多跳检索均无法满足的极端场景下，尝试 Agentic RAG 的闭环设计
• 适用场景：多跳推理、需要自我纠错的极端复杂问题
• 预期效果：理论上最强，但工程落地难度大
• 成本/延迟：⭐⭐⭐⭐⭐（极高，谨慎使用）

分层架构总览

层级	核心策略组合	解决的核心问题	建议启用条件
L0	Hybrid Search + RRF	精确匹配 vs 语义泛化	所有系统必选
L1	L0 + Query Rewriting + Parent Doc	口语化/指代/上下文断裂	有对话场景或长文档时启用
L2	L1 + Cross-Encoder Rerank	最终答案精度不够	对准确率有硬性要求时启用
L3	L2 + Fan-Out + Step-Back	多意图/冷启动/长尾问题	常规方案无法满足时按需启用
L4	L3 + Agentic RAG	多跳推理/自我纠错	极端场景，SLA 宽松时尝试

---

十、总结与展望

10.1 核心要点回顾

策略	一句话总结	最佳使用时机
查询重写	把"人话"翻译成"检索语言"	多轮对话、口语化提问
子问题拆解	一个变多个，并行打天下	复合意图查询
退一步检索	先退一步看全局，再回到细节	具体事实+背景知识结合
HyDE	用"假设答案"弥合语义鸿沟	短查询、冷启动
混合检索	精确+语义，全都要	所有系统的基线方案
父子文档	细粒度检索+粗粒度上下文	长文档知识库
Agentic RAG	让系统学会"自我纠错"	极端复杂的多跳推理

10.2 工业界最佳实践

1. 从 L0 起步：先跑通 Hybrid Search + RRF，这能解决 80% 的问题
2. 渐进式升级：不要一次性上所有策略，按 L0→L1→L2→L3→L4 逐步演进
3. 监控与评估：建立检索准确率（Precision@K）、召回率（Recall@K）、MRR 等指标，用数据驱动策略选择
4. 成本控制：对简单查询走快速路径（L0），对复杂查询走完整路径（L2/L3），避免"杀鸡用牛刀"
5. 缓存优化：对高频查询在 RRF 层之后加 Redis 缓存，避免重复计算

10.3 未来趋势

• 端到端检索优化：不再手动组合各策略，而是通过强化学习自动优化检索策略
• 多模态检索：同时支持文本、图片、音频、视频的跨模态检索
• 实时学习：基于用户反馈实时调整检索策略和排序权重
• 轻量化：更小的 Embedding 模型和 Reranker 模型，降低部署成本

---

本文档基于向量检索技术的系统学习整理，涵盖从基础概念到工业级落地的完整知识体系。建议结合实践项目加深理解，逐步从 L0 演进到 L3/L4 级别。