基础 RAG 擅长回答“这个产品支持蓝牙 5.0 吗？”这类单事实、单步检索的问题。但真实场景中，用户经常会提出需要组合多个信息片段、分步推理、对比分析才能回答的复杂问题。例如：“去年销量最高的产品线，与今年上半年的毛利率变化趋势是否一致？”——这个问题无法通过一次检索直接得到答案，需要先查出“去年销量最高的产品线是什么”，再调取该产品线今年上半年的毛利率数据，最后进行比较判断。
规划推理型 RAG 正是在基础检索-生成流水线上增加了“思考与规划”能力，让系统能够自主拆解复杂问题、执行多步检索、进行分步推理，最终整合出完整的答案。它是 RAG 从“问答工具”迈向“分析助手”的关键一步。
20.3.1 为什么基础 RAG 不够用
基础 RAG 的典型做法是：将用户问题一次性向量化，检索 top-k 个片段，然后直接生成答案。这种“单步检索、一次生成”的模式面临明显瓶颈：
- 长问题信息密度低：一个包含多个子问题的大段提问，经向量化后可能只与部分子问题相关，其他关键信息检索不到。
- 跨文档推理无法完成：答案分散在多个文档中，且需要经过“取出 A 文档的某数据 → 用这个数据去查 B 文档”这样的链条，单步检索无法串联。
- 显性推理步骤被跳过：比如需要先计算、后对比的问题，模型需要看到中间结果才能给出最终结论，而不是凭感觉跳步回答。
规划推理型 RAG 的解法是：让模型自己决定“我需要先知道什么、去哪里找、找到后再做什么”，相当于给 RAG 加上了一个会分解问题、会调用检索工具的决策中枢。
20.3.2 核心思路：问题拆解 + 多步检索 + 分步推理
这种系统的运行逻辑通常包含三个紧密协作的环节：
1. 问题拆解
系统收到复杂问题后，首先由一个“规划器”（可以是大模型自身，或一个专门训练的模块）将原问题分解为若干个可独立执行的子问题，并确定执行顺序。拆解可以遵循从易到难、从事实到分析的原则。例如：
- 原问题：“比较过去十二个月中，A 产品与 B 产品的退货率变化趋势。”
- 拆解结果：
- 检索 A 产品过去十二个月的每月退货率。
- 检索 B 产品过去十二个月的每月退货率。
- 总结两者的变化趋势，并给出对比。
每个子问题都是一次相对独立的检索或计算任务，可由后续模块逐一处理。
2. 多步检索
对于每个子问题，系统执行专门的检索。与基础 RAG 不同，这里的检索可以是上下文关联的：后续子问题可以利用前面子问题的检索结果，甚至用已获取的数据构造新的查询语句。实现方式有：
- 工具调用式检索：规划器调用不同的检索函数（如“数据库查询”、“文档搜索”、“API 获取实时数据”），每一步的结果作为下一轮的输入。
- 迭代式检索：第一个检索结果返回后，系统判断信息是否足够，如果不够，自动生成更精准的补充查询再检索一次，直到收集齐所有必要信息。
3. 分步推理与整合
收集到所有子问题的答案后，系统进行最终的分析与整合。这一步往往需要利用大模型的推理能力，将分步获取的事实串联起来，完成比较、计算、归纳等思维过程，并形成连贯的最终回答。在这个过程中，模型还可以根据需要识别出逻辑漏洞，发起补充检索。
整个流程形成一个观察-思考-行动（Observe-Think-Act）的循环，直到问题得到完整回答。
20.3.3 典型实现框架
目前工程中实现规划推理型 RAG 的常见方式有两种：
- 基于 Agent 的框架（如 ReAct）
ReAct（Reasoning + Acting）模式让模型交替进行“思考”和“行动”。模型在每一轮中会输出一个思考过程（例如“我需要先知道去年的销售总额”），然后决定调用检索工具，拿到结果后继续思考下一步，直到得出最终答案。这种模式非常自然地实现了多步检索和分步推理。代码实现上，可以利用 LangChain、LlamaIndex 等框架中的 Agent 模块，只需为模型绑定一个检索工具和必要的计算工具（如数学计算、数据库查询），就能让系统自主完成复杂的多步任务。
- 流程编排式（Plan-and-Execute）
这种模式分为两个阶段：先由规划器生成一个详细的执行计划（步骤清单），然后由一个执行器按照计划逐步调用工具并收集结果，最后汇总生成答案。它的优点是步骤清晰、易于调试，尤其适合步骤可预见的分析类问题。计划一旦生成，执行过程可以高度自动化，甚至支持并行执行没有依赖关系的子任务，提升效率。
20.3.4 一个真实的推理型 RAG 案例
某电商公司的数据运营团队搭建了一个基于 Agent 的 RAG 分析助手。用户提问：“上周哪个地区的投诉率最高？和上月同期相比如何？”
系统的工作过程如下：
- 思考 1：需要获取上周和上月同期的按地区投诉率数据。
- 行动 1：调用内部 BI 数据库查询工具，传入日期和指标参数，返回表格数据：「地区A: 1.2%，地区B: 1.8%，地区C: 0.9%」「上月同期：A: 1.1%，B: 1.5%，C: 0.8%」。
- 思考 2：已获得两周的数据，需要比较找出投诉率最高的地区，并计算变化。
- 推理：地区B在上周的投诉率1.8%最高；上月同期为1.5%，上升了0.3个百分点。
- 最终回答：“上周投诉率最高的地区是 B，为 1.8%；与上月同期相比上升了 0.3 个百分点。其余两个地区变化幅度较小。”
- 系统还会在回答中附带检索到的数据表格截图（或原文链接），供人工核对。
这个过程中，系统以规划为引导，有序地调用了数据库工具、进行了数值比较，最终呈现了分析结论而非仅仅返回原始数据片段。
20.3.5 实用建议与注意事项
- 从简单任务开始逐步复杂：不要一上来就设计过于通用的推理型系统。建议先针对几类已知的复杂查询模式设计固定的子任务流程，效果稳定后再引入 Agent 自主规划。
- 设计好工具的边界：为 Agent 绑定的检索工具应该足够明确，例如“根据日期和区域查询投诉率”，而非一个万能搜索框。明确的工具接口能大幅提高规划成功率。
- 加入验证与纠错机制：多步推理容易在中间步骤引入错误。可以让系统在每一步执行后进行一次简单的自我验证（例如检查数值是否在合理范围内），或设置一个监控模块，当最终答案与检索结果严重矛盾时触发人工复核。
- 保持可追溯性：分步推理可能经过多个环节，输出最终答案时最好能展示简要的推理路径（如“步骤一：查询上周数据；步骤二：查询上月数据；步骤三：对比分析”），既方便调试，也能增加用户信任。
规划推理型 RAG 将大模型从“信息转述者”升级为“会思考的分析师”，在面对需要跨文档、跨数据源的复杂业务问题时，展现出了远超基础 RAG 的实用价值。尽管实现复杂度有所增加，但在数据分析、竞品监控、合规审计等高价值场景中，这种提升是完全值得的。