项目链接：https: //github.com/myeon9h/PlanRAG    

论文标题：PlanRAG: A Plan-then-Retrieval Augmented Generation for Generative Large Language Models as Decision Makers

论文链接：https://arxiv.org/pdf/2406.12430

在许多商业情境中，决策制定对组织的成功至关重要。决策制定涉及数据分析，最终选择最合适的方案以达成特定目标。例如，假设制药公司“辉瑞”的目标之一是在保持从工厂到客户准时交付的同时，最小化药品分销网络中的生产成本，且生产成本与工厂的运营时间和员工数量成正比。那么，辉瑞可能面临以下决策问题：(P1) 应运营或关闭哪座工厂，以及 (P2) 每座工厂应雇佣多少员工。  

通常，决策任务需要执行以下三个步骤：(1) 制定计划，确定决策所需的分析类型；(2) 使用查询检索必要的数据；(3) 基于数据做出决策（即回答）。为了简化步骤 (2) 和 (3)，过去几十年中开发并应用了许多决策支持系统。然而，人类仍然负责最困难的部分，即步骤 (1)。本研究的目标是探讨使用大型语言模型(LLM)替代人类角色的可能性，使其不仅执行步骤 (2) 和 (3)，还包括步骤 (1)，即实现所有步骤的端到端执行。

为实现这一目标，论文提出了“决策QA”，一种针对语言模型的新决策任务。决策QA被定义为一种问答式任务，它接受数据库D、业务规则R和决策问题Q的输入对，并生成最佳决策作为输出。图1展示了在《Europa Universalis IV》游戏中，各国在探索时代竞争贸易的一个决策QA示例。每个国家决定在哪个贸易城市（即节点）上安置商人，以最大化其主要（即本国）贸易节点的利润。该示例表明，决策型LLM在分析了有关国际贸易的数据库后，决定在Doab安置商人，以最大化国家BAH的本国贸易节点Deccan的利润。

接下来，论文提出一个名为DQA的决策QA基准，它包含以下两种场景：定位和构建。前者场景包括决策问题，例如应该在哪个交易节点上安置商人？”（类似于辉瑞的P1问题）；另一类是“我应该向工厂供应多少木材？”（类似于辉瑞的P2问题）。由于使用真实商业数据构建DQA的难度，论文通过从两款视频游戏《欧陆风云IV》和《维多利亚3》中提取涉及301个特定情境的游戏数据来构建基准，这两款游戏很好地模拟了真实的商业环境。为了消除游戏的随机性并发布论文的基准，论文开发了游戏模拟器，记录了301种情境下的决策结果，并将其作为DQA问题的标注。    

现有的基于RAG的方法主要关注知识型问答任务，但并未聚焦于决策问答任务。因此，根据论文的观察，它们在处理步骤（1），即制定决策计划方面表现不佳。例如，在图1中，用于决策的语言模型应该推理出为了最大化Deccan的利润需要进行哪些分析。然而，现有方法仅尝试识别，例如，Deccan是什么。    

为了解决这一限制，论文提出了迭代规划后检索增强生成技术，即PlanRAG，该技术扩展了用于决策QA的迭代RAG技术。基于PlanRAG的语言模型首先通过检查数据模式和问题来制定所需的分析类型（规划步骤）。接下来，它通过生成和提出查询来检索分析所需的数据片段（检索步骤）。最后，它评估是否需要为更深入的分析制定新计划，并重复规划和检索步骤（重新规划步骤），或者根据数据做出决策（回答步骤）。

               
图2：建筑场景示例。红色、绿色和蓝色圆圈分别表示家具、木材和硬木。论文假设目标是降低家具价格，通过决定在B1和B2工厂之间扩展以增加其生产    

规划：在此步骤中，LM 接收 (Q, S, R) 作为输入，并生成数据分析的初始计划。该初始计划描述了为决策所需执行的一系列数据分析任务，这些任务需要在检索步骤中完成。图 4(b) 中的红色框展示了其示例。

检索与回答：与之前的 RAG 技术不同，LM 不仅接收 (Q, S, R) 还接收初始计划作为输入。因此，它能比之前的 RAG 更有效地生成用于决策的数据分析查询。图 4 展示了基于 PlanRAG 的 LM 如何与之前的 RAG 不同地生成查询。这些查询实际上通过 RAG 接口如 LangChain 和 Llamalndex 使用 SQL 或 Cypher 语言执行于数据库。查询结果被迭代用于推理，以判断是否需要重新规划或仅需进一步检索以优化决策。通过反向链接至规划过程，规划和检索过程被迭代执行，直到 LM 确定不再需要进一步分析来做出决策。

重新规划：当初始计划不足以解决决策问题时，进行重新规划。为了使 LM 能够决定是否需要重新规划，论文通过一些指令提示 LM，根据每次检索步骤的结果评估当前计划。因此，LM 不仅接收 (Q, S, R)，还接收当前计划和查询结果作为输入，生成新的计划以进行进一步分析，或调整之前分析的方向。

(1) 基于单轮 RAG 的 SingleRAG-LM，(2) 基于迭代 RAG 的 IterRAG-LM，

(3) 基于 PlanRAG 的 PlanRAG-LM，

(4) 无重新规划的 PlanRAG-LM（即 PlanRAG 不包含重新规划）。    

   

PlanRAG在定位场景中相对更有效的原因是，建筑场景需要比定位场景更长的遍历，使得规划比定位更困难。

SingleRAG-LM在建筑场景中的准确度非常低，这是因为建筑场景需要生成一个非常复杂的查询，难以一次性推理。SingleRAG-LM在超过60%的定位问题和95%的建筑问题中未能从数据库检索到任何结果。

表4还显示，PlanRAG中不进行重新规划会导致准确度下降，特别是在定位场景中下降10.8%，在建筑场景中下降0.9%。这一结果表明，重新规划过程对PlanRAG技术中决策制定任务的决策者LM是有帮助且重要的。

分析单次检索（SR）和多次检索（MR）：在DQA中，问题存在难易之分。为了检验PlanRAG根据问题难度的有效性，论文将DQA问题分为两种不同类型：(1) 单次检索（SR）问题，以及(2) 多次检索（MR）问题。在此，SR指的是IterRAG-LM为解答问题从D中进行单次检索的情况，而MR则指为解答问题进行多次检索的情况。SR共有84对（问题，文档）组合，MR则有518对。论文比较了IterRAG-LM和PlanRAG-LM在SR和MR上的准确率，结果展示在图5中。              
             
图5：IterRAG-LM和PlanRAG-LM在简单问题（SR）和中等问题（MR）上的准确率（%)。    

结果显示，PlanRAG-LM在SR问题上的表现远超IterRAG-LM，而在MR问题上也有显著优势。这是因为SR问题在许多情况下并不简单，它们是IterRAG-LM试图仅通过一次检索解决的问题。也就是说，其中一些问题是IterRAG-LM低估了其难度，但实际上是需要多次检索的相对较难的问题。

相比之下，PlanRAG-LM通过规划步骤减少了理解问题难度的可能性，并根据计划执行多次检索。因此，它能够显著提高准确率。对于MR情况，PlanRAG-LM仍然比IterRAG-LM更有效，因为前者根据计划相对系统地执行数据检索，而后者则像图4（a）所示相对无序地进行检索。

对RDB和GDB的分析：表5展示了在数据查询分析（DQA）中，针对两种不同数据库（RDB和GDB）的LMs的准确率。结果显示，无论数据库类型如何，PlanRAG-LM在两种情况下都比其他LMs更有效。论文注意到，在建筑场景中，PlanRAG-LM在GDB上的效果比在RDB上更好。这是因为建筑场景比定位场景更难，需要在GDB中进行更长的遍历（或在RDB中进行更多的连接）来回答问题。例如，定位场景中的问题只需要从源节点到家庭节点的单跳遍历，而建筑场景中的问题则需要如图2所示的多跳遍历来找到高供应商品。    

(1) CAN，表示LM未能通过考虑不当的候选者（例如图1中的Dec-can的dest）来解决问题并回答它们；

(2) MIS，遗漏数据分析；

(3) DEEP，不当使用检索到的数据或方程；    

(4) QUR，查询生成错误；

(5) OTH，其他错误（例如超过token长度限制）。例如，论文将4(a)分类为DEEP，因为LM错误地使用了一些方程，从而低估了Doab的利润。论文在图6中基于这些类别比较了IterRAG-LM和PlanRAG-LM处理的失败案例。