PlanRAG：面向决策型大语言模型的“规划-检索”增强生成技术

论文：PlanRAG: A Plan-then-Retrieval Augmented Generation for Generative Large Language Models as Decision Makers、项目代码

时间：2024.06.18

本文针对决策问题，提出了DQA数据集，并构建了PlanRAG。PLanRAG重新构建流程“规划→检索→重规划→决策”，再检索之前先生成计划，当初始计划不足以解决决策问题时，进行重规划。

一、论文动机

在商业、工业等领域，决策制定需经历“规划分析方向→检索关键数据→基于数据决策”三步流程，但传统决策支持系统仅能辅助后两步，核心的“规划”环节仍依赖人类。随着大语言模型（LLMs）发展，研究人员希望通过LLMs实现全流程自动化决策，为此提出以下核心目标：

1. 定义新的决策任务范式“Decision QA”，解决“给定决策问题Q、业务规则R、数据库D，输出最优决策d_best的问题。
2. 构建可用于评估Decision QA的基准数据集DQA，避免真实商业数据难以获取的问题。
3. 提出适配Decision QA的PlanRAG，弥补现有RAG在“决策规划”环节的不足。

二、问题定义

1. Decision QA任务定义

• 输入：结构化数据库D（关系型数据库RDB/图数据库GDB）、业务规则R（含公式文本描述）、决策问题Q（含用户目标，如“最大化某国贸易利润”）。
• 输出：最优决策d_best，需通过数据检索与规则计算得出。
• 关键约束：数据库D规模过大，无法一次性输入LLM，需通过“数据分析查询”分步骤检索。

2. DQA基准数据集详情

（1）场景设计

DQA基于两款模拟真实商业逻辑的策略游戏（《欧陆风云IV》《维多利亚3》）构建，包含两个核心场景，覆盖“选择决策对象”和“确定决策程度”两类典型决策问题：

场景名称	核心任务	业务规则示例	数据规模（单场景）
Locating（定位）	选择最优贸易节点部署商人，最大化目标国在本土节点的利润	1. 贸易权力占比TPR=某国在节点的贸易权力/节点总贸易权力 2. 利润=（本土节点本地价值+流入价值）×TPR	- 200组<Q,D>对 - RDB表均行数2038.8行 - GDB平均边数1432.3条
Building（建设）	选择最优工厂升级，最小化目标商品的市场价格	1. 总需求TD=人口需求+所有工厂最大需求之和 2. 商品现价=基准价×[1+0.75×(需求-供给)/max(需求,供给)]	- 101组<Q,D>对 - RDB表均行数579.0行 - GDB平均边数374.7条

（2）数据特性

• 数据库双版本：每个<Q,D>对同时提供RDB（用SQL查询）和GDB（用Cypher查询）版本，共602个数据库。
• 标注方式：开发游戏模拟器，通过模拟所有决策候选的结果（如“在A节点部署商人的利润增量”），生成确定性标注，避免游戏随机性影响。

三、论文方法

1. 技术痛点：现有RAG的不足

现有RAG（含迭代式RAG）聚焦“知识问答”，缺乏决策所需的“规划能力”：

• 单轮RAG：仅单次检索数据，无法处理多步骤决策（如Building场景需多轮计算供需关系）。
• 迭代式RAG：虽支持多轮检索，但无明确规划，检索方向零散（如Locating场景中可能误检索本土节点数据，而非上游节点）。

2. PlanRAG核心流程

PlanRAG在迭代式RAG基础上新增“规划”与“重规划”环节，通过单LLM实现“规划→检索→重规划→决策”闭环，流程如下：

环节	输入	输出	核心作用
规划（Planning）	Q（决策问题）、S（数据库 schema）、R（业务规则）	初始分析计划（如“Step1：找到本土节点的上游贸易节点；Step2：计算各上游节点部署商人的利润增量”）	基于PlanRAG的语言模型首先生成决策计划，描述为决策所需执行的一系列数据分析任务
检索与分析（Retrieving & Answering）	初始计划+Q+S+R	数据分析查询（SQL/Cypher）+查询结果	语言模型不仅接收问题、业务规则和数据库模式，还接收初始计划作为输入，生成用于决策的数据分析查询，并从数据库中检索数据
重规划（Re-planning）	当前计划+查询结果+Q+S+R	新计划（或“无需重规划”）	当初始计划不足以解决决策问题时，进行重新规划。语言模型根据每次检索步骤的结果评估当前计划，并生成新的计划以进行进一步分析
决策（Answering）	所有检索结果+规则计算	最优决策dbest	基于完整数据与规则，输出最终决策

3. 关键设计：重规划策略

当查询结果与计划预期不符（如“计划查上游节点数据，却返回本土节点数据”），LLM通过以下策略调整计划：

• 步骤增删：如新增“检查节点是否为内陆”的检索步骤。
• 目标修正：如将“计算商品当前需求”修正为“计算商品人口需求”。
• 步骤拆分：如将“计算供需关系”拆分为“计算需求”“计算供给”两个子步骤。

四、实验结果

1. 实验设置

• 对比模型：单轮RAG-LM、迭代式RAG-LM（SOTA）、PlanRAG-LM、PlanRAG-LM（无重规划）。
• 基础模型：GPT-4（零温度，避免随机性），用LangChain实现检索接口，数据库用MySQL（RDB）和Neo4j（GDB）。
• 评估标准：答案与标注语义一致则视为正确（如“Doab节点”与标注一致）。

2. 核心结果

（1）整体性能

模型	Locating场景准确率（%）	Building场景准确率（%）
单轮RAG-LM	30.5（RDB+GDB平均）	2.5（RDB+GDB平均）
迭代式RAG-LM（SOTA）	48.5	37.6
PlanRAG-LM（无重规划）	37.7（比PlanRAG-LM低10.8%）	36.7（比PlanRAG-LM低0.9%）
PlanRAG-LM	64.3（比SOTA高15.8%）	45.0（比SOTA高7.4%）

• 差异原因：Locating场景规划难度低（仅需单跳检索上游节点），PlanRAG优势更明显；Building场景需多跳检索（如“工厂→商品供给→总供给→价格”），规划难度高，优势相对缩小。

（2）按问题难度分析：单检索和多检索

将问题分为“单检索（SR）”和“多检索（MR）”两类（SR指迭代式RAG仅用1次检索尝试解决的问题）：

• SR问题：PlanRAG-LM在Locating场景准确率61.9%，远超迭代式RAG-LM的20.2%——原因是部分SR问题实际需多轮检索，迭代式RAG低估难度，而PlanRAG通过规划识别真实难度。
• MR问题：PlanRAG-LM仍优于迭代式RAG-LM（Locating场景49.4% vs 43.9%），因PlanRAG检索更系统。

（3）按数据库类型分析：GDB与RDB

GDB场景：Building场景中PlanRAG-LM准确率49.5%（RDB为40.6%），因Building场景需多跳图遍历（如“工厂→供给→商品→需求”），PlanRAG的规划能明确遍历路径，而RDB需多表连接，规划优势被削弱。

（4）关键数据遗漏率

衡量“未检索/计算关键值（如Locating的IV流入价值、Building的CO当前产出）”的比例：

模型	Locating关键数据遗漏率（%）	Building关键数据遗漏率（%）
迭代式RAG-LM	3.3	33.2
PlanRAG-LM	1.3	21.8

五、优缺点

1. 主要贡献

1. 定义新任务：提出Decision QA任务，首次将“决策规划”纳入LLM任务范畴，区别于传统知识问答。
2. 构建基准数据集：DQA覆盖两类典型决策场景，提供双数据库版本与确定性标注，填补Decision QA评估空白。
3. 提出新方法：PlanRAG通过“规划-重规划”增强LLM的决策能力，在DQA上显著超越SOTA。

2. 局限性

1. 数据库类型局限：仅支持RDB和GDB，未覆盖混合数据库（如“向量数据库+关系库”）。
2. 低阶优化缺失：未针对“Cypher/SQL生成”进行模型微调，聚焦高阶流程设计。
3. 单LLM框架：未探索多LLM分工（如“专用规划LLM+专用检索LLM”）的效果。