一、研究背景与问题定义1. 研究背景检索增强生成RAG能有效缓解大语言模型LLM的幻觉问题通过引入外部知识提升回答质量。现有 RAG 系统在简单问答和多跳问答上表现良好但在探索性推理问题ERP上存在明显不足。2. 探索性推理问题ERP的特点高不确定性与模糊性推理路径不清晰子问题之间依赖关系复杂。检索噪声与错误累积传统链式或迭代式 RAG 容易因顺序执行而累积误差。缺乏全局规划现有方法缺少端到端的查询规划机制难以优化子查询的执行顺序和结构。二、核心贡献提出 PlanRAG 框架受数据库查询规划启发将 ERP 建模为逻辑查询树LQT实现全局规划与结构化执行。提出 LQT 构建方法通过动态规划Selinger DP与多维成本模型将自然语言 ERP 分解为原子查询并组织成最优 LQT弥合结构化 SQL 与非结构化 NL 之间的鸿沟。构建并发布 WikiWeb‑ERP 数据集专为 ERP 设计的 RAG 基准包含 3,536 个查询和 53,682 个文档来源包括 Wikipedia 和真实网页。三、方法框架PlanRAG 三大阶段阶段 1原子查询生成Query Parsing使用 LLM 将原始 ERP 分解为原子查询每个对应一个关系三元组主语‑谓语‑宾语。保证每个原子查询不可再分、无指代歧义、可直接检索。阶段 2逻辑查询树构建Logical Optimization关系预处理提前识别原子查询间的三种关系亲子、兄弟、无关系缓存“无关系”对以减少 LLM 调用。动态规划Selinger DP枚举所有可能的树结构选择成本最低的 LQT。循环预防保证 LQT 为有向无环图DAG。上下文感知合并利用部分构建的树指导局部合并决策保持语义一致性。多维成本模型公式 3正向指标树大小节点数、结构密度边数负向指标树深度、树不平衡度对齐指标语义相似度BGE 编码与原始查询的相似度引入缩放因子 α最优值为 10平衡结构与语义。阶段 3LQT 执行Physical Execution自底向上并行执行叶节点直接检索 生成答案。非叶节点聚合子节点答案 → 重写当前查询 → 检索 → 生成。多线程并发同一层的独立节点并行处理提升效率。复杂度DP 枚举为指数级但通过关系预处理降至 O(n²) 次 LLM 调用执行时间取决于树深度最好 O(log n)最坏 O(n)。四、实验设置1. 数据集WikiWeb‑ERP自建3,536 个查询53,682 个文档来自 BrowseComp、GAIA 等现有数据集 WebSailor 生成扩展。2. 基线方法直接 / 朴素 RAGDirectLLM、NaiveRAG迭代式RetGen、GenGround、DualRAG、KiRAG图式ChainRAG、HopRAG、LEGO‑GraphRAG3. 评估指标准确率Acc、精确匹配EM、令牌级 F1、LLM 评估的语义准确率4. 实现细节基础 LLMLLaMA‑3‑8B及其他多种模型检索器BM25及 BGE、Contriever、ColBERT规划相关 LLMGPT‑4o‑mini五、主要实验结果1. 主实验表 3PlanRAG w/ Ret 在全部指标上显著优于所有基线Acc 26.43% vs 次优 25.48%。即使不带检索w/o Ret也超过 NaiveRAG 和部分迭代方法证明规划机制本身带来的提升。2. 消融实验表 4去除循环预防或上下文感知合并导致明显性能下降。去除语义相似度维度影响最大说明语义锚定对 ERP 规划至关重要。3. 泛化性实验不同基础模型Llama‑2/3、Qwen‑2.57B~72BPlanRAG 均稳定提升对小模型提升更显著。不同检索器BGE、Contriever、ColBERTPlanRAG 始终优于 NaiveRAG。多跳 QA 基准HotpotQA、MuSiQue、2Wiki、StrategyQA在 StrategyQA 上取得最佳其他数据集表现有竞争力。4. 效率分析表 7关系预处理LLM 调用次数从 63.6 降至 10.4时间从 82.8s 降至 8.4s。并行执行执行时间从 18.7s 降至 7.3s加速比 2.56 倍。六、进一步分析与讨论1. 成本模型敏感性αα10 时性能最优过大或过小均会降低准确率证明其平衡结构与语义的作用。2. 查询复杂度分析随原子查询数增加所有方法性能下降但 PlanRAG 下降最慢成本token、时间、GPU 内存呈近似线性增长说明其可扩展性良好。3. LQT 质量评估表 9人类和 LLM 评估均显示 PlanRAG 生成的 LQT 质量优于 LLM 直接生成3.52 vs 3.22。移除语义相似度后质量明显下降。4. 细粒度分析表 10原子查询生成准确率98.5%原子查询覆盖率94.2%线性退化率退化为链仅 3.2%关系分类准确率无关系 96.4%亲子 83.1%兄弟 87.9%5. 鲁棒性分析表 11在原子查询、关系、执行三个阶段注入噪声10%~30%性能平滑下降而非崩溃证明结构化规划具有抗错能力。6. 错误分析主要错误来源规划错误36%、检索错误32%、推理一致性19%、生成合成13%。七、局限性与未来工作对简单查询可能过度规划。成本模型为启发式非严格物理代价估计。当前依赖 GPT‑4o‑mini 进行规划未来计划用轻量开源模型LLaMA/Qwen微调替代。未来将探索物理查询计划与缓存机制等系统级优化。PlanRAG 是首个将数据库查询规划思想系统性地引入 RAG 处理探索性推理问题的框架。通过将自然语言查询转化为逻辑查询树并结合动态规划与多维成本模型它实现了全局结构优化、并行高效执行、语义准确对齐在新建的 WikiWeb‑ERP 基准上显著超越现有迭代式与图式 RAG 方法为复杂 NL 查询优化提供了全新范式。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示摘要检索增强生成RAG有效地将大语言模型LLM扎根于外部知识中但在处理探索性推理问题ERP时面临困难这类问题涉及具有高度不确定性和模糊性的复杂查询。解决ERP需要推理路径不清晰的复杂推理这往往导致检索噪声和错误累积。此外端到端规划机制的缺失使得为ERP生成有效的执行轨迹变得困难。受数据库查询规划的启发我们提出了PlanRAG这是一个将自然语言的ERP建模为逻辑查询树LQT的RAG框架。然而由于结构化SQL与非结构化自然语言之间在表示和优化上存在差距将ERP转化为LQT并非易事这使得构建高质量的LQT极具挑战性。为解决这些问题我们首先将ERP分解为原子查询然后使用由包含多个互补维度的成本模型指导的动态规划将它们组织成LQT。最后我们在LQT上迭代执行聚合、重写、检索和生成并发处理节点并将中间结果向上传播并通过多线程进一步并行化以提高效率。我们的实验结果表明在我们新构建的数据集WikiWeb-ERP上PlanRAG优于最先进的基于迭代和基于图的RAG系统从而为优化自然语言查询提供了一种新的范式。我们的源代码和数据集可在 https://anonymous.4open.science/r/PlanRAG-mainB2C8/ 获取。结果表明在我们新构建的数据集WikiWeb-ERP上PlanRAG优于最先进的基于迭代和基于图的RAG系统从而为优化自然语言查询提供了一种新的范式。关键词检索增强生成查询规划逻辑查询树大语言模型1 引言检索增强生成RAG将大语言模型LLM与外部文档库相结合使模型回复基于检索到的文档而非仅依赖参数化记忆从而有效缓解了LLM的幻觉问题[9, 18]。由于其能够结合检索与生成RAG在需要事实依据和基于证据推理的知识密集型任务上展现出了强大的性能。然而现有的RAG系统在很大程度上忽视了本文称为探索性推理问题ERP的复杂查询如图1(a)所示。ERP的特点是具有高不确定性和难以简化性其中实体以模糊和涌现的方式耦合在一起[20, 24]。ERP的内在复杂性给当前的RAG系统带来了根本性的挑战。如图1(a)所示与具有明确指定且可分解链的传统多跳查询不同ERP缺乏显式的中间结构使得人们不清楚应该检索什么信息、以何种顺序检索以及如何连贯地聚合这些信息。更重要的是ERP代表了一类更广泛的场景这些场景需要在不确定性下进行长周期推理和全局规划其中子任务通过复杂的隐式依赖关系耦合在一起。这些特性使得使用现有方法设计有效的规划策略或分解方案本身就很困难突显了处理ERP的根本重要性。因此现有的RAG系统在处理ERP时常常面临以下三个相互关联的问题。(i)检索噪声激增由于ERP的不确定性和模糊性检索过程常常返回大量不相关的文档用虚假证据淹没LLM [20]。(ii)错误累积基于迭代的RAG方法顺序处理子查询早期的检索或生成错误会传播到后续步骤导致幻觉叠加和推理不稳定[9]。(iii)缺乏端到端规划更重要的是现有的规划方法依赖于人工标注的轨迹或分解规则缺乏用于查询优化的端到端机制[20, 35]。我们观察到确定性的全局规划机制不仅能够协调子查询之间的执行顺序和依赖关系还能有效减少检索噪声和错误累积[20]。值得注意的是这一局限性即缺乏协调检索与生成的端到端规划在结构上类似于数据库系统中查询规划所解决的核心挑战在数据库系统中操作的顺序和依赖关系必须在执行前进行优化。这种类比促使我们探索规划机制是否能够通过引入结构化路径和减少检索中的模糊性来惠及自然语言查询。如图1(b)所示受数据库查询规划的启发其中SQL查询被编译为逻辑查询树LQT并通过基于成本的策略进行优化[29]我们提出从ERP的自然语言查询中构建LQT从而实现高效且可解释的规划。然而由于结构化SQL与非结构化自然语言之间存在两个根本性差距将这一想法转化到自然语言并非易事。(i)表示差距SQL查询基于显式的关系模式这些模式预先定义了关系原子如何通过明确定义的键和关系进行连接为LQT表示提供了清晰的蓝图。相比之下自然语言查询是非结构化的其中的语义单元及其之间的潜在依赖关系是隐式且模糊的。没有预定义的模式来规定这些单元应如何组织成LQT这使得自动推导结构健壮且语义合理的LQT成为一个核心挑战。(ii)优化差距数据库优化器使用基于定义良好的模式和统计信息来估计物理执行成本I/O、CPU和内存的成本模型来评估SQL中的候选LQT。相比之下在自然语言中优化LQT不能依赖这种物理指标。因此成本必须反映新颖的视角如语义和结构这就需要一种为概念性查询规划量身定制的多维成本模型。为弥合这些差距我们引入了一个端到端的RAG框架PlanRAG它将ERP建模为LQT从而减轻检索噪声和错误累积。PlanRAG的整体流程包括三个主要阶段这与经典的数据库查询规划相对应查询解析、逻辑优化和物理执行。首先在查询解析阶段为解决表示差距我们将ERP分解为原子查询每个原子查询对应于一个最小语义单元即单个关系三元组从而能够精确表示中间依赖关系。这些原子查询展现出语义关系包括亲子、兄弟和无关系。其次在逻辑优化阶段我们利用Selinger动态规划DP通过语义关系将这些原子查询分层组织成一个最优的LQT。在DP之前我们引入了关系预处理以减少评估潜在节点合并所需的LLM调用次数。在DP过程中我们提出了循环预防机制以保持LQT的有向无环图DAG结构并提出了上下文感知合并以确保每次局部合并都与树结构保持一致。为解决优化差距并指导高质量LQT的构建我们设计了一个从五个互补维度评估的成本模型即树大小节点数、结构密度边数、树深度、树平衡度和语义相似度确保LQT在结构上健壮且在语义上合理。最后在物理执行阶段我们以迭代方式在LQT上执行聚合、重写、检索和生成其中节点被并发处理中间结果递归向上传播直至根节点产生最终答案。为了减少延迟并实现高效推理我们通过使用多线程调度独立节点来进一步并行化执行。为了评估PlanRAG在ERP上的性能我们构建并发布了一个RAG数据集名为WikiWeb-ERP其中包含从现有数据集收集的一些查询以及遵循WebSailor [20]方法构建的查询并附有从维基百科和实时网页中检索到的相应文档。我们的实验证明了我们的框架在某些最先进的基线上的优越性以及其在处理ERP方面的潜力。本文的主要贡献包括遵循数据库查询规划的范式我们提出了一个用于解决ERP的RAG框架PlanRAG它提高了复杂检索任务的规划能力并为优化自然语言查询提供了一种新的范式。为了弥合结构化SQL与非结构化自然语言查询之间的差距我们提出了一种有效的方法通过由多维成本模型指导的动态规划为ERP构建LQT这在RAG范式内实现了高效且可解释的规划并为数据库查询优化技术展示了一个新的应用场景。为了系统性地评估我们的PlanRAG在ERP上的性能我们进一步发布了一个新的数据集WikiWeb-ERP作为一个复杂的RAG基准。我们的实验结果表明在WikiWeb-ERP上PlanRAG相较于现有的基于迭代和基于图的RAG系统取得了最先进的性能突显了我们规划机制的关键优势。2 相关工作2.1 检索增强生成检索增强生成RAG将大语言模型LLM的生成能力与外部知识检索相结合使得在推理过程中能够动态访问外部知识源[14, 18, 26]。这种结合显著增强了模型在需要外部知识检索和推理的任务上的性能如问答[19]、事实验证[40]和知识驱动的对话[5]。RAG的核心思想是使用检索器从大规模语料库中识别与给定查询相关的文档或证据段落并让生成器基于检索到的证据产生有根据的回复。因此RAG有效缓解了LLM参数化知识的局限性并将其适用性扩展到需要实时信息访问、广泛知识覆盖和跨文档推理的任务[15]。2.2 面向多跳问答的RAG多跳问答QA要求模型执行一系列相互依赖的推理步骤从而构建一个导向最终答案的推理链[27, 28]。多跳QA是评估RAG系统的一个有说服力的测试平台因为它对知识检索器和答案生成器都提出了严格的要求[17, 43]。基于图的方法通过构建文档/推理图并沿图路径检索证据显式地对多跳依赖关系进行建模从而增强了连贯性和可解释性[2, 23]。基于迭代的RAG方法使模型能够在推理过程中反复访问外部知识逐步构建连贯的推理链从而有效应对多跳推理中的挑战[30, 31]。与按简单链顺序执行子查询的基于迭代的方法不同本文研究的ERP涉及具有高不确定性和难以简化的问题[34]。ERP无法通过简单的顺序推理得到充分解决相反它们需要精心设计的查询规划以优化子查询的执行顺序和查询结构中的依赖关系。2.3 信息寻求智能体信息寻求智能体[10, 21, 22, 25, 36, 37]旨在开发能够通过顺序决策发出搜索查询、导航网页并提取相关证据的自主网络系统。近期研究表明这些智能体在ERP[20, 32, 35]上表现良好ERP涉及复杂、长周期的信息寻求任务。此类智能体通常依赖大量高质量的交互轨迹进行监督利用强化学习或模仿学习来提升性能。从根本上说信息寻求智能体在动作序列搜索空间上执行在线优化其中规划和执行紧密交织决策基于中间观察结果逐步优化。这种在线范式虽然灵活但通常训练成本高且在推理过程中方差较大。相比之下PlanRAG采用离线规划即在执行前优化规划。PlanRAG不是搜索动作序列而是直接从自然语言查询中探索树状结构搜索空间即LQT。这种转变使得无需依赖轨迹监督或在线策略学习即可实现全局结构优化。因此我们的方法无需训练也不需要人工标注的轨迹在不同领域提供了更高的实用性和可扩展性。图2我们提出的PlanRAG的流程图。表1从图2中的ERP派生的原子查询。3 预备知识3.1 查询规划在数据库系统中SQL查询首先被解析为抽象语法树然后转换为逻辑查询树LQTLQT以关系代数的形式捕获查询的语义[42]。基于逻辑表示查询优化器通过等价保持变换如算子重排序和分解系统地探索替代查询计划。候选计划使用估计执行效率的成本模型进行评估优化后的逻辑计划随后被转换为物理查询计划以供执行。这种规划过程使数据库能够在访问实际数据之前对查询执行进行全局推理。3.2 逻辑查询树如图1(b)左侧所示逻辑查询树LQT在数据库系统中通常被定义为源自结构化查询如SQL的层次化逻辑计划其中节点对应关系代数算子如选择、投影和连接边表示算子之间的数据流[1]。这些树基于定义良好的模式和等价规则确保确定的语义并支持基于成本的优化以实现高效的查询执行。在本文中我们将LQT重新定义为捕获自然语言查询组合语义的层次化表示。形式上LQT被建模为一个有向无环图DAGT(V,E)其中V是节点集E是边集。每个节点v∈V代表原子查询如表1所示这些原子查询派生自原始ERP。每条边e(vi,vj)∈E编码了原子查询之间的语义依赖关系叶节点对应于可直接执行的原子查询。LQT的执行遵循自底向上的过程节点被并发处理中间结果递归向上传播直到根节点产生最终答案。与数据库中基于关系和具有严格语义的代数算子的LQT不同本文中的LQT是由自然语言查询构建的语义组合树。这种适应性使得我们的LQT能够捕获ERP中固有的组合结构为RAG提供了一个灵活且可解释的系统。3.3 Selinger动态规划Selinger动态规划DP是数据库查询规划中用于从一组原子查询生成优化LQT的经典方法[3, 29]。该算法的输入是一组原子查询每个原子查询代表从原始查询派生的一个不可分割的基本操作输出是一个优化的LQT T(V,E))其中节点VV对应于原子或中间子查询边EE编码子查询之间的语义依赖关系。该算法遵循自底向上的策略首先计算每个原子查询的执行成本然后递归地将较小的子计划组合成较大的子计划逐步处理原子查询的更大子集在每一步选择成本最低的组合。4.2 原子查询生成为了精确表示中间依赖关系我们采用精心设计的提示技术利用LLM将复杂查询分解为多个原子查询详细提示见附录A。具体来说我们在提示中提供了原子查询的明确定义以及示例说明引导LLM以主语谓语宾语的形式构建每个原子查询。在本文中每个原子查询都是不可分割的并对应于一个单一的关系三元组。例如从图2中的ERP派生的原子查询“早期的基督教赞美诗有哪些”对应于三元组早期的基督教赞美诗是。这种严格的一一映射确保了分解结果的语义原子性以及原子查询与三元组之间的自然映射从而保留了原始查询的逻辑结构并能够精确检索支持文档。这些原子查询可以根据三种语义关系类型组织成LQTi亲子关系一个原子查询是父节点另一个是子节点子节点在语义上依赖于或细化父节点。ii兄弟关系两个查询在语义上独立作为LQT同一层的兄弟节点。iii无关系两个查询没有有意义的语义联系在LQT中不共享任何亲子或兄弟关系。选择成本最小的组合。3.4 BGE模型BGE [38] 是一个为语义相似度估计和检索任务设计的预训练稠密嵌入模型。它将输入文本映射到一个稠密向量空间使得语义相似的文本在空间中彼此靠近。形式上给定两个文本序列 x 和 yBGE通过编码器 E(⋅) 将它们编码为稠密表示它们的相似度计算为sin(x,y)⟨E(x),E(y)⟩,(2)其中 ⟨⋅,⋅⟩表示内积。在本文中我们使用BGE对原始查询和文本化的逻辑查询树进行编码。得到的相似度分数衡量了构建的逻辑查询树与原始查询之间的语义对齐程度并在我们的成本模型中作为关键信号第4.3节。4 方法论4.1 概述我们提出的PlanRAG的流程图如图2所示它为ERP实现了全局规划。我们首先将每个ERP分解为原子查询即最小语义单元原子查询生成。类似于数据库查询规划中的LQT构建我们随后通过由多维成本模型指导的动态规划将这些原子查询组织成最优的LQTLQT构建。为确保效率我们在LQT上执行自底向上和并行的执行策略涉及迭代的聚合、重写、检索和生成直到根节点产生最终结果LQT执行。值得注意的是对应于数据库查询处理流程我们PlanRAG的三个阶段分别是查询解析原子查询生成、逻辑优化LQT构建和物理执行LQT执行。我们的方法主要关注逻辑优化而物理优化如缓存机制则留给未来的研究。4.2 原子查询生成为了精确表示中间依赖关系我们采用精心设计的提示技术利用LLM将复杂查询分解为多个原子查询详细提示见附录A。具体来说我们在提示中提供了原子查询的明确定义以及示例说明引导LLM以主语谓语宾语的形式构建每个原子查询。在本文中每个原子查询都是不可分割的并对应于一个单一的关系三元组。例如从图2中的ERP派生的原子查询“早期的基督教赞美诗有哪些”对应于三元组早期的基督教赞美诗是。这种严格的一一映射确保了分解结果的语义原子性以及原子查询与三元组之间的自然映射从而保留了原始查询的逻辑结构并能够精确检索支持文档。这些原子查询可以根据三种语义关系类型组织成LQTi亲子关系一个原子查询是父节点另一个是子节点子节点在语义上依赖于或细化父节点。ii兄弟关系两个查询在语义上独立作为LQT同一层的兄弟节点。iii无关系两个查询没有有意义的语义联系在LQT中不共享任何亲子或兄弟关系。4.3 逻辑查询树构建类似于数据库查询规划中的LQT构建我们扩展了Selinger动态规划DP范式[29]来将这些原子查询组织成LQT。在DP之前我们加入了关系预处理以减少LLM调用次数。在DP过程中我们提出了循环预防机制以确保被视为有向无环图DAG的LQT保持无环并提出了上下文感知合并以保持全局语义一致性确保每次局部合并都与树结构对齐。在整个过程中我们使用多维成本模型评估所有候选树以优化LQT。LQT构建过程的伪代码列于附录B。关系预处理。为减少DP过程中评估潜在节点合并所需的LLM调用次数我们在DP之前引入了关系预处理。在我们的框架中原子查询之间的无关系是在关系预处理阶段确定的而非在DP过程中。给定一个ERP我们利用LLM对所有原子查询对 (qi,qj) 进行语义评估并将其分类为三种关系类型“无关系”、“兄弟关系”和“亲子关系”。具体来说“无关系”查询对的概念以及代表性示例被纳入LLM提示中以指导模型识别无关的原子查询对。识别出的关系在此阶段被缓存。如图2所示我们标记了原子查询之间的无关系。通过观察大量样本我们发现LLM能够准确识别无关的查询对第6.4节。因此所有标记为“无关系”的查询对在DP期间被立即剪枝无需调用LLM。用于确定原子查询之间关系的详细提示见附录A。虽然成本函数是手动设计的但每个维度例如树大小、结构密度都是基于对LQT和错误传播的直观理解选择的作为一种可解释的结构性归纳偏置引导LQT构建向健壮的结构发展。循环预防。为保持LQT的DAG结构算法在DP期间首先检查合并两个节点是否会引入环。如果是则禁止该合并。上下文感知合并。为确保每次局部节点合并都与树结构对齐我们引入了上下文感知合并来确定两个节点之间是否存在“亲子”关系。其关键思想是将部分构建的LQT纳入LLM提示中从而能够评估候选节点的语义兼容性。因此该技术通过将每次节点合并置于不断发展的上下文中提高了最终LQT的质量。成本模型。与基于定义良好的模式和统计信息估计物理执行成本I/O、CPU和内存的传统数据库成本模型不同我们提出的成本模型旨在从结构和语义两个角度评估LQT的质量。它从结构合理性和派生质量方面评估LQT同时将语义一致性和与原始查询的对齐作为优化目标纳入考量。具体而言候选树的成本从以下五个方面进行评估树大小 (ts):即LQT中的节点数。较大的树大小鼓励包含尽可能多的原子查询从而防止丢失基本语义单元并确保推理链保持完整。结构密度 (sd):即LQT中的边数。足够密集的结构反映了原子查询之间丰富的语义依赖关系有助于保持它们的相互关联性。树深度 (td):即从根节点到任何叶节点的最大距离。控制深度可防止树退化为一个长链这会导致顺序瓶颈并加剧错误传播。树平衡度 (tb):树的平衡度通过子树高度差来衡量。平衡的树结构有助于进一步提高并行效率同时防止树退化为过深的链。语义相似度 (ss):我们将LQT转换为自然语言并使用BGE [38] 衡量其与原始查询的相似度。该维度通过强制与原始查询意图对齐来指导优化器将构建的树锚定到原始查询并确保规划在语义上保持准确。完整提示见附录A。总体而言与依赖于定义良好的统计信息和物理成本指标的数据库查询优化不同我们方法中的“最优LQT”仅在启发式和LLM驱动的函数下是最优的。因此我们的方法更好地被视为一种结构化搜索策略而非传统的基于成本的优化。由于成本估计的启发式性质数据库查询优化中的DP最优性保证不能直接应用于我们的LQT设置。尽管如此PlanRAG仍然是一种结构化的、受数据库启发的规划方法有效地指导了语义组合但并未声称具有同等的理论保证。4.4 逻辑查询树上的执行策略在获得优化的LQT后我们在LQT上迭代执行自底向上的聚合、重写、检索和生成。在LQT中每个节点 vv 代表一个原子查询。叶节点和非叶节点的处理方式不同。叶节点直接从语料库中检索并生成答案4.5 提示交互与编排我们的框架在不同阶段涉及多个LLM提示它们在一个结构化的流程中交互。具体而言每个阶段的输出作为后续步骤的输入形成连贯的信息流。(1) 在原子查询生成阶段LLM使用图2中的提示1将ERP分解为原子查询。(2) 在关系预处理阶段应用图2中的提示2来确定原子查询之间的语义关系并将识别出的无关对缓存以便在LQT构建期间进行后续剪枝。(3) 在LQT构建期间进一步调用LLM进行上下文感知合并此时部分构建的树被整合到提示中图2中的提示3以指导局部决策。(4) 在成本建模阶段我们提示图2中的提示4LLM将候选LQT转换为自然语言查询然后与原始查询进行比较以估计语义对齐程度。(5) 在执行阶段我们使用LLM图5中的提示5聚合子节点的查询和答案作为上下文并使用该上下文重写原子查询以进行后续检索和答案生成。这种分阶段设计确保了中间表示原子查询、关系和部分LQT在提示之间显式传递从而使得整个流程中的步骤能够协调进行。4.6 复杂度分析LQT构建的时间复杂度。我们的方法侧重于使用Selinger动态规划算法构建LQT。尽管该算法具有指数级的理论时间复杂度经典上界为 O(n2n)但根据我们的统计在实际ERP场景中单个查询很少被分解为超过15个原子查询。超过15个原子查询的案例极为罕见而大多数查询涉及的原子查询数量较少使得搜索空间可以接受。即使在涉及超过20个原子查询的更复杂场景中我们的方法在保持计划质量和执行效率方面仍然是可行的。ERP中的主要成本并非来自规划本身而是来自LLM调用。冗余的规划步骤可能会引入冗余的检索和在规划期间不必要的LLM调用。相比之下DP的搜索时间与下游成本相比可以忽略不计。因此在规划期间确定更好的执行结构具有实际效益它减少了不必要的LLM调用提高了检索效率并控制了整体系统成本。在DP期间任何标记为“无关系”的对都会被立即剪枝无需调用LLM。设 p0 为检测“无关系”对的准确率则DP期间的预期LLM调用次数可以近似为4.7 WikiWeb-ERP据我们所知目前没有专门为ERP设计的专用基准。如表2所示现有数据集中ERP的比例相对较低。为了全面评估我们的PlanRAG在ERP上的性能我们构建并发布了一个专为RAG系统定制的高质量数据集WikiWebERP。WikiWeb-ERP的构建过程如下。首先我们从两个互补方面收集ERP以确保多样性和代表性。具体来说(i) 数据集采样我们从几个现有数据集BrowseComp [34]、BrowseComp-Plus [4]、BrowseComp Long Context [34] 和 GAIA [24]中选择了问答对以保证数据可靠性和跨数据集可比性。(ii) 生成式扩展我们采用WebSailor [20] 提出的查询生成方法来进一步扩展这些问答对该方法模拟了实际开放领域场景中的真实互联网信息流。类似地我们从两个来源构建文档集合。首先我们结合稠密和稀疏检索技术从与每个查询相关的维基百科转储中检索候选文档作为第一个文档来源。其次我们使用WebSailor [20] 中的网页收集方法为每个查询从互联网上抓取真实网页形成第二个文档来源。这些网页捕捉了现实世界知识的分布和开放领域信息中固有的噪声。这两类文档共同构成了WikiWeb-ERP的文档集合确保了检索来源的真实性和多样性。总体而言WikiWeb-ERP包含3536个查询和53682个文档。其中2405个查询来自现有数据集1131个是通过WebSailor [20] 生成的。在文档方面24050个来自维基百科转储29632个来自真实网页抓取。查询和文档的平均长度分别为93.48个词和121.09个词。表2不同数据集中ERP的比例。BC、BCPlus和BC-LC分别是BrowseComp [34]、BrowseComp-Plus [4] 和 BrowseComp Long Context [34] 的缩写。5 实验5.1 评估指标遵循先前关于RAG和多跳QA的工作[6]我们使用四个互补指标评估模型性能准确率Acc、精确匹配EM、令牌级F1F1和语义准确率Acc。这些指标共同评估事实正确性、词汇重叠和语义一致性这对于ERP尤其重要。(i) Acc衡量生成答案是否充分捕捉了标准答案的关键内容。(ii) EM衡量生成答案与标准答案之间的精确匹配程度。(iii) F1评估生成答案与标准答案之间的令牌级相似度。(iv) 我们还使用 gpt-3.5-turbo-instruct 计算Acc以进行更全面的评估其中LLM以标准答案为参考评估生成答案的正确性。5.2 基线方法为确保全面评估我们将我们的PlanRAG与DirectLLM和NaiveRAG [18] 以及两大主流高级RAG系统进行了比较。基于迭代的方法包括RetGen [30]、GenGround [31]、DualRAG [6] 和KiRAG [8]它们沿着顺序推理链迭代执行检索和生成。相比之下基于图的方法包括ChainRAG [41]、HopRAG [23] 和 LEGO-GraphRAG [2]它们构建文档/推理图以捕获多跳依赖关系并沿图路径检索证据。DirectLLM 不检索外部知识直接生成答案。NaiveRAG 检索一次文档并基于检索到的文档生成答案。RetGen 通过迭代的检索-生成协同策略增强LLM以回答多跳问题。GenGround 通过检索到的证据迭代生成和验证答案以改进多跳问答。DualRAG 使用多视角相关性评分联合对查询和文档进行排序。KiRAG 通过使用知识三元组构建推理链来增强迭代检索增强生成。ChainRAG 通过句子图迭代重写子问题并检索句子以解决多跳QA中的缺失实体问题。HopRAG 使用伪查询构建段落图并通过“检索-推理-剪枝”机制执行多跳推理。LEGO-GraphRAG 将GraphRAG检索模块化为子图提取和路径检索模块以实现灵活构建和实例的系统评估。5.3 实现细节我们在三块NVIDIA A800 80GB GPU上进行所有实验。在本文中我们使用BM25作为检索器并为所有方法使用LLaMA-3-8B作为基础模型。鉴于WikiWeb-ERP数据集中的文档本身简洁长度始终低于10000个令牌的标准分块大小我们将每个完整文档视为一个单独的段落不再进行进一步分割。此外我们将线程数动态设置为可用核心数与当前层独立节点数之间的较小值通常在4到7之间这有助于在最大化并发性的同时避免线程切换开销。在整个流程中我们使用GPT-40-mini进行原子查询生成、关系预处理、上下文感知合并和查询重写。我们通过网格搜索将公式3中的缩放因子alpha设置为10以避免语义偏差。对于ChainRAG、DualRAG、KiRAG和LEGO-GraphRAG我们使用原始作者发布的标准实现在我们的数据集WikiWeb-ERP上重现了结果。对于ChainRAG我们采用了利用子问题检索到的上下文来生成答案的上下文集成设置[41]。对于RetGen、GenGround和HopRAG我们按照其论文中报告的参数设置在我们的数据集上复现了实验。对于LEGO-GraphRAG我们在检索前通过Microsoft GraphRAG [7] 从语料库构建图。5.4 主要结果如表3所示我们的方法PlanRAG w/ Ret在我们的WikiWeb-ERP数据集上取得了最先进的性能最佳结果以粗体突出显示次优结果以下划线标出其中w/ Ret和w/o Ret分别表示在PlanRAG框架中启用和未启用外部检索。结果表明与DirectLLM和NaiveRAG相比PlanRAG w/ Ret取得了显著的性能提升证明了我们的框架在处理ERP方面的有效性。PlanRAG w/ Ret也优于几种先进的基于迭代的RAG方法包括RetGen、GenGround、DualRAG和KiRAG这些方法通常遵循分解、检索和生成的链式过程。然而这种迭代机制通常缺乏检索和生成之间的全局规划导致不相关的文档检索和错误累积。相比之下我们的框架在生成之前执行全局规划通过动态规划优化LQT并确保检索与生成之间更好的对齐。此外我们的框架超越了基于图的RAG方法ChainRAG、LEGO-GraphRAG和HopRAG这些方法利用图结构来检索逻辑连接的信息以进行多跳QA。虽然这些方法通过探索图邻域提高了检索召回率但它们通常引入了图构建和遍历的计算开销并且可能仍然通过虚假连接传播错误。PlanRAG中的全局规划机制通过动态规划直接优化了检索路径从而带来了更健壮的性能。最后PlanRAG w/ Ret和PlanRAG w/o Ret均优于NaiveRAG和RetGen这证实了性能改进归功于我们的规划机制而不仅仅是检索本身。5.5 消融研究我们在LQT构建上进行消融研究以验证我们提出方法的有效性。如表4所示我们去除了关系预处理、循环预防和上下文感知合并以评估它们对PlanRAG整体性能的影响。值得注意的是去除关系预处理w/o rp并未导致显著的性能下降因为关系预处理主要降低系统成本如运行时间、令牌成本和LLM调用次数而非直接提高生成质量。去除循环预防w/o cp导致显著的性能下降表明该机制对于维护LQT结构和防止循环引起的逻辑错误至关重要。类似地禁用上下文感知合并w/o ca导致性能下降突显了部分构建的树在维持整个规划过程中语义连贯性的重要性。为评估成本模型在指导LQT构建方面的有效性我们还评估了PlanRAG在去除成本模型中每个维度后的变体性能。表4中的结果一致表明去除任何单一维度都会导致整体性能下降表明每个维度都对优化目标有所贡献。这些表3在我们的WikiWeb-ERP上比较的检索方法的性能。发现突显了将所有五个维度结合起来以实现LQT构建中结构健壮性和语义合理性的重要性。值得注意的是排除语义相似度w/o ss导致最显著的性能下降。虽然成本模型中的结构性正则化项例如树深度或平衡度调节执行效率但语义相似度作为一个全局对齐信号防止LQT偏离原始意图表明有效的ERP规划需要语义锚定。5.6 跨不同基础模型和检索器的鲁棒性基础模型。为了验证我们的框架在不同LLM上的泛化能力我们还使用多种LLM作为基础模型进行了实验包括Llama-3-70B、Llama-27B/13B/70B和Qwen-2.57B/14B/72B。对于每个基础模型我们比较了NaiveRAG、PlanRAG w/o Ret和PlanRAG w/ Ret的性能。如表5所示PlanRAG w/ Ret在所有模型规模和基础模型上均一致地带来了性能提升表明我们框架的有效性与模型无关。值得注意的是对于参数规模较小的模型例如7B和13B改进更为显著这表明我们的规划策略补偿了它们有限的参数化知识和能力。这一观察突显了我们的方法即使在有限的计算预算下也有潜力增强RAG系统。检索器。除了改变基础模型外我们还在不同的检索器上进一步评估了我们的框架包括BGE-small [38]5.7 效率分析关系预处理对LQT构建效率的影响。为了验证关系预处理对LQT构建的影响我们比较了启用和禁用该组件时的时间、令牌成本和LLM调用次数。表7报告了从WikiWeb-ERP中采样的100个查询的结果。显然启用关系预处理将LQT构建的平均时间从82.8秒减少到8.4秒LLM调用次数从63.6次减少到10.4次令牌成本从3454.4降低到1265.2。结合表4的结果这种优化显著降低了计算成本同时未牺牲生成质量。并行执行对LQT执行效率的影响。为了验证并行执行对LQT执行的影响我们在从WikiWeb-ERP随机采样的100个查询上比较了单线程顺序执行w/o parallel和多线程并行执行w/ parallel的LQT执行。表7显示并行执行将平均执行时间从18.7秒减少到7.3秒实现了 2.56× 的加速。这种改进源于LQT的结构特性允许节点并行执行。值得注意的是并行执行主要减少了执行时间但并未减少LLM调用次数或令牌成本。总体而言这些发现表明并行执行在提高效率方面是有效的使PlanRAG能够在实际部署中实现高准确率的同时满足实时性能需求。系统成本比较。为更好地评估PlanRAG的效率我们将其系统成本与各种基线方法进行了比较分别报告了100个样本上的平均令牌成本、运行时间和峰值GPU内存使用量。图3清晰地展示了不同RAG系统在系统成本上的差异。这些基于迭代的基线依赖于多轮检索和生成其中累积的错误通常触发额外的LLM调用增加了令牌消耗。它们固有的顺序工作流程阻碍了并行执行进一步增加了总体运行时间。基于图的基线在图构建和遍历方面引入了大量开销。随着图的增长冗余节点和不相关边迅速累积从而膨胀了资源使用。与这些基线相比PlanRAG采用全局规划机制来减少冗余检索和不必要的推理。这使得执行更加聚焦且易于并行化。虽然规划引入了初始成本但整体工作流程变得更加简化从而在系统成本和性能方面实现了优越的成本-效益权衡。5.8 多跳问答的结果为了进一步验证PlanRAG在ERP之外的通用的生成能力我们在四个广泛使用的多跳QA基准上评估了我们的方法包括HotpotQA [39]、MuSiQue [33]、2WikiMultiHopQA [12] 和 StrategyQA [11]。如表8所示PlanRAG在大多数数据集上取得了有竞争力的性能并在StrategyQA上获得了最佳结果展示了其在ERP之外的泛化能力。特别是PlanRAG在HotpotQA和MuSiQue上的表现与基于图的基线相当但在2WikiMultiHopQA上存在差距后者推理链更明确因此更适合基于图的检索方法。相比之下PlanRAG主要针对依赖关系模糊的ERP设计而我们的方法可以执行显式的查询规划以有效提高性能。6 进一步分析与讨论6.1 缩放因子 αα 的敏感性分析为了进一步验证成本模型中缩放因子 αα 的有效性我们进行了敏感性分析。具体而言我们在 [1, 20] 范围内变化 α并评估最终准确率。图4(a)显示性能随着 α 的增加先提升后稳定在 α10 时达到最高准确率进一步增加 α 带来的收益有限或略有下降。从缩放角度来看结构项树深度或平衡度随节点数量增长而语义相似度项在 [0, 1] 范围内归一化导致尺度不匹配。引入 α 旨在对齐它们的贡献。这些结果表明α 不是一个任意的调优参数而是在平衡结构正则化和语义对齐方面起着关键作用其最优值对应于两者之间良好校准的权衡。6.2 跨查询复杂度的性能和成本比较跨查询复杂度的性能比较。为了进一步检验PlanRAG在不同查询复杂度下的鲁棒性我们根据原子查询的数量将查询分为 {5,6,7,8,9,9} 的桶并报告每个桶内的平均准确率。这种设置反映了原子查询数量越多通常意味着依赖链越深的直觉。图4(b)中的结果显示PlanRAG在所有桶中均一致优于基线。值得注意的是虽然所有方法都随着原子查询数量的增加而表现出性能下降但PlanRAG的下降速度明显更慢。PlanRAG显式编码依赖关系并执行全局结构优化从而局部化错误并及早剪枝次优计划。此外其成本模型中的结构正则化项例如树深度和平衡度防止规划退化为长链从而在高复杂度下实现更稳定的性能。总体而言这些结果强调了PlanRAG在扩展至传统RAG流程之外的高复杂度查询方面的有效性。跨查询复杂度的系统成本比较。为评估PlanRAG在查询复杂度增加时的系统成本我们分析了系统成本作为原子查询数量 nn 的函数。我们将WikiWeb-ERP中的ERP按照 n∈{5,6,7,8,9,9} 进行分桶并测量四个指标(a) 令牌成本(b) 运行时间(c) 峰值GPU内存以及 (d) LLM调用次数。如图5所示所有四个指标的值都随着原子查询数量 n 的增加而增加。具体而言令牌成本和LLM调用次数随 n 近似线性增长反映了随着LQT规模增大中间步骤的扩展。运行时间也随 nn 增加而峰值GPU内存从 n5 时的约9.0 GB上升到 n9 时的近12 GB这是由于执行期间KV缓存和中间结果的累积。总体而言这些结果表明PlanRAG在查询复杂度增加时表现出可预测的系统成本增长证实了其对于复杂查询的可扩展性。6.3 LQT质量评估为检验我们LQT构建方法的有效性我们对我们的方法生成的LQT与LLM直接生成的LQT进行了比较评估。LLM的评估提示见附录A它衡量LQT是否表现出结构健壮性和语义合理性。每个LQT的质量由人工评估者和LLM评判员分别使用以下4分制1~4分顺序量表进行评估。4 - 优秀LQT展现出良好形成且稳定的结构原子查询之间具有明确定义的依赖关系同时在整个树中保持与原始查询意图的强语义对齐。3 - 良好LQT在结构上基本连贯且在语义上基本一致存在轻微的结构缺陷或细微的语义模糊性但不会损害整体过程。2 - 一般LQT显示出明显的结构弱点例如缺失或不正确的依赖关系或语义不一致部分影响了工作流的正确性。1 - 差LQT缺乏结构健壮性和语义合理性表现出无组织的依赖关系和显著的语义偏离。最终得分 SS 计算为所有30个生成的LQT的平均得分其中 si 表示分配给第 ii 个LQT的得分。表9报告了人类评估和LLM评判的结果。结果表明我们的方法构建的LQT质量优于LLM直接生成的LQT。此外我们通过从成本模型中移除语义相似度构建了一个消融变体并评估了生成的LQT。质量明显下降表明语义相似度在维持LQT的语义对齐方面起着关键作用。具体来说一个强大的LLM可以在单步中直接生成一个计划。然而这种方法通常缺乏稳定的结构约束不同的调用可能会产生不一致或违反依赖关系的计划。相比之下我们首先将复杂查询分解为原子查询然后通过显式的结构约束构建LQT确保清晰的依赖关系和可执行的推理。LLM有时生成的线性图对于ERP并非最优。在许多情况下一些原子查询在语义上是独立的可以并行执行。例如在图1中识别候选作者及其去世年份和检索候选年表在很大程度上是独立的任务可以在通过“年表的最后一年与作者去世年份匹配”这一约束对齐之前分别执行。因此LQT将这些查询组织成一棵树而非严格的线性链减少了顺序依赖和错误传播。值得注意的是Claude生成的线性结构类似于ReTGen和GenGround等基线中使用的顺序推理策略而PlanRAG在表3中显著优于它们突显了树状结构规划的优势。6.4 LQT构建的细粒度分析为了更全面地评估LQT构建我们从四个关键方面进一步分析了100个随机采样的查询原子查询生成、原子查询覆盖率、线性退化率和关系分类准确率。评估结果列于表10。原子查询生成。为评估原子查询生成的准确率我们对100个随机采样的查询进行了人工评估。评估结果表明LLM生成的原子查询达到了 98.5% 的准确率。报告的 98.5% 准确率是通过对生成的原子查询及其对应三元组进行人工标注获得的多个标注者根据预定义标准独立评估每个三元组的正确性。具体而言标注者间一致性使用Fleiss kappa评估达到 k0.82表明标注者之间具有强一致性。这表明我们的分解方法能够从原始ERP中提取最小语义单元从而为后续的LQT构建提供了可靠的基础。原子查询覆盖率。为验证LQT具有高原子查询覆盖率我们系统地统计了所有生成的LQT中的原子查询数量。结果显示在 94.2% 的情况下PlanRAG实现了所有原子查询的完全覆盖。这表明我们的规划机制能够整合绝大多数原子查询从而支持基于完整原子查询链的执行。线性退化率。鉴于ERP具有固有的高不确定性和难以简化的特点我们的规划机制通过LQT的结构显式地组织依赖关系。在理想情况下原子查询之间的语义关系清晰且易于区分PlanRAG构建出结构良好的LQT。然而在最坏情况下即原子查询在很大程度上是语义独立的LQT可能退化为近似线性的链状结构。为量化这种情况发生的频率我们对生成的LQT进行了结构分析。结果显示仅有 3.2% 的查询表现出近线性结构而绝大多数查询超过 96%保持着显式的树状依赖关系。关系分类。正如第4节所强调的我们利用LLM在关系预处理中识别无关系。为评估分类的可靠性我们人工验证了预测的语义关系并测量了其分类准确率。结果显示LLM在识别无关系方面的分类准确率达到 96.4%而亲子关系和兄弟关系的准确率分别为 83.1% 和 87.9%。无关系的高准确率表明关系预处理可以提高LQT构建的效率。6.5 阶段级鲁棒性分析为分析阶段级鲁棒性我们进行了受控扰动实验以检查错误如何通过PlanRAG流程传播结果见表11。我们从数据集中随机采样100个查询并在三个阶段注入噪声噪声级别为 10%、20% 和 30%。1原子查询生成我们随机移除原子查询以模拟不完整或有噪声的分解。2关系分类我们随机选择边并将其关系替换为随机选择的标签亲子、兄弟或无关系从而扰动树结构。3LQT执行我们将检索到的内容替换为不相关的文本以模拟检索和推理错误。对于每个阶段我们在保持其他阶段不变的情况下改变噪声水平并评估对最终答案准确率的影响。结果显示性能随噪声增加而逐渐下降表明错误确实在各个阶段之间传播。然而下降是平滑的而非灾难性的这表明PlanRAG对上游错误具有鲁棒性这主要归功于其结构化的规划。6.6 错误分析为评估PlanRAG在ERP上的可信度我们将查询中的错误分为四类(i) 规划错误 (36%)(36%) 主要源于未能充分识别原子查询之间的依赖关系导致LQT无法准确捕获基础逻辑顺序从而损害整体性能。这些错误通常由模糊的关系或低置信度的合并决策引起突显了更准确的关系分类的必要性。(ii) 检索错误 (32%) 发生在检索器仅获取部分相关但最终不相关的信息或未能检索到关键证据段落时从而削弱了对后续步骤的支持。这些错误通常由实体不匹配或查询重写不充分引起表明可以通过混合检索和优化的查询重写来提高检索鲁棒性。(iii) 推理一致性错误 (19%) 发生在各个原子查询的答案是正确的但它们整合到全局推理结果中时偏离了事实结论反映了全局一致性的局限性。(iv) 生成与综合错误 (13%) 在最终答案聚合阶段观察到表现为实体指代歧义或输出格式混乱通常由长推理链上结构化表示的不稳定性引起。总体而言我们的PlanRAG的主要瓶颈在于规划和检索进一步的性能提升需要强化自适应规划机制和鲁棒的检索策略。7 结论在本文中我们提出了PlanRAG一个受数据库查询规划启发的、为ERP设计的端到端RAG框架。PlanRAG首先将ERP分解为原子查询。然后这些原子查询通过动态规划组织成优化的LQT以建模语义依赖关系从而减轻检索噪声和错误累积。基于优化的LQTPlanRAG以自底向上和并行的方式迭代执行聚合、重写、检索和生成递归传播中间结果以高效地产生最终答案。在新发布的WikiWeb-ERP数据集上的广泛实验表明相较于基于迭代和基于图的RAG基线PlanRAG取得了持续的性能提升进一步的分析证实了我们提出的规划机制的高效性、有效性和可解释性。文本[[85, 659, 481, 894], [517, 107, 912, 177]]我们承认我们的方法存在一些局限性。首先PlanRAG难以泛化到简单问题场景因为其规划机制对于直接查询可能是不必要的。其次对于逻辑复杂度低或具有清晰逐步路径的查询该方法可能退化为标准的多跳QA分解范式。此外我们的成本模型是一个简化的抽象并未基于文档长度或任务复杂度等因素显式地归一化成本。其目标不是精确估计每个语义查询的真实执行成本而是提供一个轻量级的启发式方法来指导计划选择。虽然不同的子计划可能具有相同的建模成本但实际执行开销可能不同检索和推理成本的变化部分通过语义相似度和结构项反映这有助于优先选择更连贯和高效的方案。此外我们计划纳入微调策略以减少对LLM在原子查询生成、关系预处理和查询重写等组件中的依赖例如用轻量级开源模型如LLaMA和Qwen系列替代GPT-4o-mini。最后我们将探索如何将LQT映射到物理查询计划并结合系统级优化如缓存机制以提供更完整的系统级优化方案。 PlanRAG：When RAG Meets Query Planning: Logical Query Trees for Resolving Exploratory Reasoning Probl
一、研究背景与问题定义1. 研究背景检索增强生成RAG能有效缓解大语言模型LLM的幻觉问题通过引入外部知识提升回答质量。现有 RAG 系统在简单问答和多跳问答上表现良好但在探索性推理问题ERP上存在明显不足。2. 探索性推理问题ERP的特点高不确定性与模糊性推理路径不清晰子问题之间依赖关系复杂。检索噪声与错误累积传统链式或迭代式 RAG 容易因顺序执行而累积误差。缺乏全局规划现有方法缺少端到端的查询规划机制难以优化子查询的执行顺序和结构。二、核心贡献提出 PlanRAG 框架受数据库查询规划启发将 ERP 建模为逻辑查询树LQT实现全局规划与结构化执行。提出 LQT 构建方法通过动态规划Selinger DP与多维成本模型将自然语言 ERP 分解为原子查询并组织成最优 LQT弥合结构化 SQL 与非结构化 NL 之间的鸿沟。构建并发布 WikiWeb‑ERP 数据集专为 ERP 设计的 RAG 基准包含 3,536 个查询和 53,682 个文档来源包括 Wikipedia 和真实网页。三、方法框架PlanRAG 三大阶段阶段 1原子查询生成Query Parsing使用 LLM 将原始 ERP 分解为原子查询每个对应一个关系三元组主语‑谓语‑宾语。保证每个原子查询不可再分、无指代歧义、可直接检索。阶段 2逻辑查询树构建Logical Optimization关系预处理提前识别原子查询间的三种关系亲子、兄弟、无关系缓存“无关系”对以减少 LLM 调用。动态规划Selinger DP枚举所有可能的树结构选择成本最低的 LQT。循环预防保证 LQT 为有向无环图DAG。上下文感知合并利用部分构建的树指导局部合并决策保持语义一致性。多维成本模型公式 3正向指标树大小节点数、结构密度边数负向指标树深度、树不平衡度对齐指标语义相似度BGE 编码与原始查询的相似度引入缩放因子 α最优值为 10平衡结构与语义。阶段 3LQT 执行Physical Execution自底向上并行执行叶节点直接检索 生成答案。非叶节点聚合子节点答案 → 重写当前查询 → 检索 → 生成。多线程并发同一层的独立节点并行处理提升效率。复杂度DP 枚举为指数级但通过关系预处理降至 O(n²) 次 LLM 调用执行时间取决于树深度最好 O(log n)最坏 O(n)。四、实验设置1. 数据集WikiWeb‑ERP自建3,536 个查询53,682 个文档来自 BrowseComp、GAIA 等现有数据集 WebSailor 生成扩展。2. 基线方法直接 / 朴素 RAGDirectLLM、NaiveRAG迭代式RetGen、GenGround、DualRAG、KiRAG图式ChainRAG、HopRAG、LEGO‑GraphRAG3. 评估指标准确率Acc、精确匹配EM、令牌级 F1、LLM 评估的语义准确率4. 实现细节基础 LLMLLaMA‑3‑8B及其他多种模型检索器BM25及 BGE、Contriever、ColBERT规划相关 LLMGPT‑4o‑mini五、主要实验结果1. 主实验表 3PlanRAG w/ Ret 在全部指标上显著优于所有基线Acc 26.43% vs 次优 25.48%。即使不带检索w/o Ret也超过 NaiveRAG 和部分迭代方法证明规划机制本身带来的提升。2. 消融实验表 4去除循环预防或上下文感知合并导致明显性能下降。去除语义相似度维度影响最大说明语义锚定对 ERP 规划至关重要。3. 泛化性实验不同基础模型Llama‑2/3、Qwen‑2.57B~72BPlanRAG 均稳定提升对小模型提升更显著。不同检索器BGE、Contriever、ColBERTPlanRAG 始终优于 NaiveRAG。多跳 QA 基准HotpotQA、MuSiQue、2Wiki、StrategyQA在 StrategyQA 上取得最佳其他数据集表现有竞争力。4. 效率分析表 7关系预处理LLM 调用次数从 63.6 降至 10.4时间从 82.8s 降至 8.4s。并行执行执行时间从 18.7s 降至 7.3s加速比 2.56 倍。六、进一步分析与讨论1. 成本模型敏感性αα10 时性能最优过大或过小均会降低准确率证明其平衡结构与语义的作用。2. 查询复杂度分析随原子查询数增加所有方法性能下降但 PlanRAG 下降最慢成本token、时间、GPU 内存呈近似线性增长说明其可扩展性良好。3. LQT 质量评估表 9人类和 LLM 评估均显示 PlanRAG 生成的 LQT 质量优于 LLM 直接生成3.52 vs 3.22。移除语义相似度后质量明显下降。4. 细粒度分析表 10原子查询生成准确率98.5%原子查询覆盖率94.2%线性退化率退化为链仅 3.2%关系分类准确率无关系 96.4%亲子 83.1%兄弟 87.9%5. 鲁棒性分析表 11在原子查询、关系、执行三个阶段注入噪声10%~30%性能平滑下降而非崩溃证明结构化规划具有抗错能力。6. 错误分析主要错误来源规划错误36%、检索错误32%、推理一致性19%、生成合成13%。七、局限性与未来工作对简单查询可能过度规划。成本模型为启发式非严格物理代价估计。当前依赖 GPT‑4o‑mini 进行规划未来计划用轻量开源模型LLaMA/Qwen微调替代。未来将探索物理查询计划与缓存机制等系统级优化。PlanRAG 是首个将数据库查询规划思想系统性地引入 RAG 处理探索性推理问题的框架。通过将自然语言查询转化为逻辑查询树并结合动态规划与多维成本模型它实现了全局结构优化、并行高效执行、语义准确对齐在新建的 WikiWeb‑ERP 基准上显著超越现有迭代式与图式 RAG 方法为复杂 NL 查询优化提供了全新范式。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示摘要检索增强生成RAG有效地将大语言模型LLM扎根于外部知识中但在处理探索性推理问题ERP时面临困难这类问题涉及具有高度不确定性和模糊性的复杂查询。解决ERP需要推理路径不清晰的复杂推理这往往导致检索噪声和错误累积。此外端到端规划机制的缺失使得为ERP生成有效的执行轨迹变得困难。受数据库查询规划的启发我们提出了PlanRAG这是一个将自然语言的ERP建模为逻辑查询树LQT的RAG框架。然而由于结构化SQL与非结构化自然语言之间在表示和优化上存在差距将ERP转化为LQT并非易事这使得构建高质量的LQT极具挑战性。为解决这些问题我们首先将ERP分解为原子查询然后使用由包含多个互补维度的成本模型指导的动态规划将它们组织成LQT。最后我们在LQT上迭代执行聚合、重写、检索和生成并发处理节点并将中间结果向上传播并通过多线程进一步并行化以提高效率。我们的实验结果表明在我们新构建的数据集WikiWeb-ERP上PlanRAG优于最先进的基于迭代和基于图的RAG系统从而为优化自然语言查询提供了一种新的范式。我们的源代码和数据集可在 https://anonymous.4open.science/r/PlanRAG-mainB2C8/ 获取。结果表明在我们新构建的数据集WikiWeb-ERP上PlanRAG优于最先进的基于迭代和基于图的RAG系统从而为优化自然语言查询提供了一种新的范式。关键词检索增强生成查询规划逻辑查询树大语言模型1 引言检索增强生成RAG将大语言模型LLM与外部文档库相结合使模型回复基于检索到的文档而非仅依赖参数化记忆从而有效缓解了LLM的幻觉问题[9, 18]。由于其能够结合检索与生成RAG在需要事实依据和基于证据推理的知识密集型任务上展现出了强大的性能。然而现有的RAG系统在很大程度上忽视了本文称为探索性推理问题ERP的复杂查询如图1(a)所示。ERP的特点是具有高不确定性和难以简化性其中实体以模糊和涌现的方式耦合在一起[20, 24]。ERP的内在复杂性给当前的RAG系统带来了根本性的挑战。如图1(a)所示与具有明确指定且可分解链的传统多跳查询不同ERP缺乏显式的中间结构使得人们不清楚应该检索什么信息、以何种顺序检索以及如何连贯地聚合这些信息。更重要的是ERP代表了一类更广泛的场景这些场景需要在不确定性下进行长周期推理和全局规划其中子任务通过复杂的隐式依赖关系耦合在一起。这些特性使得使用现有方法设计有效的规划策略或分解方案本身就很困难突显了处理ERP的根本重要性。因此现有的RAG系统在处理ERP时常常面临以下三个相互关联的问题。(i)检索噪声激增由于ERP的不确定性和模糊性检索过程常常返回大量不相关的文档用虚假证据淹没LLM [20]。(ii)错误累积基于迭代的RAG方法顺序处理子查询早期的检索或生成错误会传播到后续步骤导致幻觉叠加和推理不稳定[9]。(iii)缺乏端到端规划更重要的是现有的规划方法依赖于人工标注的轨迹或分解规则缺乏用于查询优化的端到端机制[20, 35]。我们观察到确定性的全局规划机制不仅能够协调子查询之间的执行顺序和依赖关系还能有效减少检索噪声和错误累积[20]。值得注意的是这一局限性即缺乏协调检索与生成的端到端规划在结构上类似于数据库系统中查询规划所解决的核心挑战在数据库系统中操作的顺序和依赖关系必须在执行前进行优化。这种类比促使我们探索规划机制是否能够通过引入结构化路径和减少检索中的模糊性来惠及自然语言查询。如图1(b)所示受数据库查询规划的启发其中SQL查询被编译为逻辑查询树LQT并通过基于成本的策略进行优化[29]我们提出从ERP的自然语言查询中构建LQT从而实现高效且可解释的规划。然而由于结构化SQL与非结构化自然语言之间存在两个根本性差距将这一想法转化到自然语言并非易事。(i)表示差距SQL查询基于显式的关系模式这些模式预先定义了关系原子如何通过明确定义的键和关系进行连接为LQT表示提供了清晰的蓝图。相比之下自然语言查询是非结构化的其中的语义单元及其之间的潜在依赖关系是隐式且模糊的。没有预定义的模式来规定这些单元应如何组织成LQT这使得自动推导结构健壮且语义合理的LQT成为一个核心挑战。(ii)优化差距数据库优化器使用基于定义良好的模式和统计信息来估计物理执行成本I/O、CPU和内存的成本模型来评估SQL中的候选LQT。相比之下在自然语言中优化LQT不能依赖这种物理指标。因此成本必须反映新颖的视角如语义和结构这就需要一种为概念性查询规划量身定制的多维成本模型。为弥合这些差距我们引入了一个端到端的RAG框架PlanRAG它将ERP建模为LQT从而减轻检索噪声和错误累积。PlanRAG的整体流程包括三个主要阶段这与经典的数据库查询规划相对应查询解析、逻辑优化和物理执行。首先在查询解析阶段为解决表示差距我们将ERP分解为原子查询每个原子查询对应于一个最小语义单元即单个关系三元组从而能够精确表示中间依赖关系。这些原子查询展现出语义关系包括亲子、兄弟和无关系。其次在逻辑优化阶段我们利用Selinger动态规划DP通过语义关系将这些原子查询分层组织成一个最优的LQT。在DP之前我们引入了关系预处理以减少评估潜在节点合并所需的LLM调用次数。在DP过程中我们提出了循环预防机制以保持LQT的有向无环图DAG结构并提出了上下文感知合并以确保每次局部合并都与树结构保持一致。为解决优化差距并指导高质量LQT的构建我们设计了一个从五个互补维度评估的成本模型即树大小节点数、结构密度边数、树深度、树平衡度和语义相似度确保LQT在结构上健壮且在语义上合理。最后在物理执行阶段我们以迭代方式在LQT上执行聚合、重写、检索和生成其中节点被并发处理中间结果递归向上传播直至根节点产生最终答案。为了减少延迟并实现高效推理我们通过使用多线程调度独立节点来进一步并行化执行。为了评估PlanRAG在ERP上的性能我们构建并发布了一个RAG数据集名为WikiWeb-ERP其中包含从现有数据集收集的一些查询以及遵循WebSailor [20]方法构建的查询并附有从维基百科和实时网页中检索到的相应文档。我们的实验证明了我们的框架在某些最先进的基线上的优越性以及其在处理ERP方面的潜力。本文的主要贡献包括遵循数据库查询规划的范式我们提出了一个用于解决ERP的RAG框架PlanRAG它提高了复杂检索任务的规划能力并为优化自然语言查询提供了一种新的范式。为了弥合结构化SQL与非结构化自然语言查询之间的差距我们提出了一种有效的方法通过由多维成本模型指导的动态规划为ERP构建LQT这在RAG范式内实现了高效且可解释的规划并为数据库查询优化技术展示了一个新的应用场景。为了系统性地评估我们的PlanRAG在ERP上的性能我们进一步发布了一个新的数据集WikiWeb-ERP作为一个复杂的RAG基准。我们的实验结果表明在WikiWeb-ERP上PlanRAG相较于现有的基于迭代和基于图的RAG系统取得了最先进的性能突显了我们规划机制的关键优势。2 相关工作2.1 检索增强生成检索增强生成RAG将大语言模型LLM的生成能力与外部知识检索相结合使得在推理过程中能够动态访问外部知识源[14, 18, 26]。这种结合显著增强了模型在需要外部知识检索和推理的任务上的性能如问答[19]、事实验证[40]和知识驱动的对话[5]。RAG的核心思想是使用检索器从大规模语料库中识别与给定查询相关的文档或证据段落并让生成器基于检索到的证据产生有根据的回复。因此RAG有效缓解了LLM参数化知识的局限性并将其适用性扩展到需要实时信息访问、广泛知识覆盖和跨文档推理的任务[15]。2.2 面向多跳问答的RAG多跳问答QA要求模型执行一系列相互依赖的推理步骤从而构建一个导向最终答案的推理链[27, 28]。多跳QA是评估RAG系统的一个有说服力的测试平台因为它对知识检索器和答案生成器都提出了严格的要求[17, 43]。基于图的方法通过构建文档/推理图并沿图路径检索证据显式地对多跳依赖关系进行建模从而增强了连贯性和可解释性[2, 23]。基于迭代的RAG方法使模型能够在推理过程中反复访问外部知识逐步构建连贯的推理链从而有效应对多跳推理中的挑战[30, 31]。与按简单链顺序执行子查询的基于迭代的方法不同本文研究的ERP涉及具有高不确定性和难以简化的问题[34]。ERP无法通过简单的顺序推理得到充分解决相反它们需要精心设计的查询规划以优化子查询的执行顺序和查询结构中的依赖关系。2.3 信息寻求智能体信息寻求智能体[10, 21, 22, 25, 36, 37]旨在开发能够通过顺序决策发出搜索查询、导航网页并提取相关证据的自主网络系统。近期研究表明这些智能体在ERP[20, 32, 35]上表现良好ERP涉及复杂、长周期的信息寻求任务。此类智能体通常依赖大量高质量的交互轨迹进行监督利用强化学习或模仿学习来提升性能。从根本上说信息寻求智能体在动作序列搜索空间上执行在线优化其中规划和执行紧密交织决策基于中间观察结果逐步优化。这种在线范式虽然灵活但通常训练成本高且在推理过程中方差较大。相比之下PlanRAG采用离线规划即在执行前优化规划。PlanRAG不是搜索动作序列而是直接从自然语言查询中探索树状结构搜索空间即LQT。这种转变使得无需依赖轨迹监督或在线策略学习即可实现全局结构优化。因此我们的方法无需训练也不需要人工标注的轨迹在不同领域提供了更高的实用性和可扩展性。图2我们提出的PlanRAG的流程图。表1从图2中的ERP派生的原子查询。3 预备知识3.1 查询规划在数据库系统中SQL查询首先被解析为抽象语法树然后转换为逻辑查询树LQTLQT以关系代数的形式捕获查询的语义[42]。基于逻辑表示查询优化器通过等价保持变换如算子重排序和分解系统地探索替代查询计划。候选计划使用估计执行效率的成本模型进行评估优化后的逻辑计划随后被转换为物理查询计划以供执行。这种规划过程使数据库能够在访问实际数据之前对查询执行进行全局推理。3.2 逻辑查询树如图1(b)左侧所示逻辑查询树LQT在数据库系统中通常被定义为源自结构化查询如SQL的层次化逻辑计划其中节点对应关系代数算子如选择、投影和连接边表示算子之间的数据流[1]。这些树基于定义良好的模式和等价规则确保确定的语义并支持基于成本的优化以实现高效的查询执行。在本文中我们将LQT重新定义为捕获自然语言查询组合语义的层次化表示。形式上LQT被建模为一个有向无环图DAGT(V,E)其中V是节点集E是边集。每个节点v∈V代表原子查询如表1所示这些原子查询派生自原始ERP。每条边e(vi,vj)∈E编码了原子查询之间的语义依赖关系叶节点对应于可直接执行的原子查询。LQT的执行遵循自底向上的过程节点被并发处理中间结果递归向上传播直到根节点产生最终答案。与数据库中基于关系和具有严格语义的代数算子的LQT不同本文中的LQT是由自然语言查询构建的语义组合树。这种适应性使得我们的LQT能够捕获ERP中固有的组合结构为RAG提供了一个灵活且可解释的系统。3.3 Selinger动态规划Selinger动态规划DP是数据库查询规划中用于从一组原子查询生成优化LQT的经典方法[3, 29]。该算法的输入是一组原子查询每个原子查询代表从原始查询派生的一个不可分割的基本操作输出是一个优化的LQT T(V,E))其中节点VV对应于原子或中间子查询边EE编码子查询之间的语义依赖关系。该算法遵循自底向上的策略首先计算每个原子查询的执行成本然后递归地将较小的子计划组合成较大的子计划逐步处理原子查询的更大子集在每一步选择成本最低的组合。4.2 原子查询生成为了精确表示中间依赖关系我们采用精心设计的提示技术利用LLM将复杂查询分解为多个原子查询详细提示见附录A。具体来说我们在提示中提供了原子查询的明确定义以及示例说明引导LLM以主语谓语宾语的形式构建每个原子查询。在本文中每个原子查询都是不可分割的并对应于一个单一的关系三元组。例如从图2中的ERP派生的原子查询“早期的基督教赞美诗有哪些”对应于三元组早期的基督教赞美诗是。这种严格的一一映射确保了分解结果的语义原子性以及原子查询与三元组之间的自然映射从而保留了原始查询的逻辑结构并能够精确检索支持文档。这些原子查询可以根据三种语义关系类型组织成LQTi亲子关系一个原子查询是父节点另一个是子节点子节点在语义上依赖于或细化父节点。ii兄弟关系两个查询在语义上独立作为LQT同一层的兄弟节点。iii无关系两个查询没有有意义的语义联系在LQT中不共享任何亲子或兄弟关系。选择成本最小的组合。3.4 BGE模型BGE [38] 是一个为语义相似度估计和检索任务设计的预训练稠密嵌入模型。它将输入文本映射到一个稠密向量空间使得语义相似的文本在空间中彼此靠近。形式上给定两个文本序列 x 和 yBGE通过编码器 E(⋅) 将它们编码为稠密表示它们的相似度计算为sin(x,y)⟨E(x),E(y)⟩,(2)其中 ⟨⋅,⋅⟩表示内积。在本文中我们使用BGE对原始查询和文本化的逻辑查询树进行编码。得到的相似度分数衡量了构建的逻辑查询树与原始查询之间的语义对齐程度并在我们的成本模型中作为关键信号第4.3节。4 方法论4.1 概述我们提出的PlanRAG的流程图如图2所示它为ERP实现了全局规划。我们首先将每个ERP分解为原子查询即最小语义单元原子查询生成。类似于数据库查询规划中的LQT构建我们随后通过由多维成本模型指导的动态规划将这些原子查询组织成最优的LQTLQT构建。为确保效率我们在LQT上执行自底向上和并行的执行策略涉及迭代的聚合、重写、检索和生成直到根节点产生最终结果LQT执行。值得注意的是对应于数据库查询处理流程我们PlanRAG的三个阶段分别是查询解析原子查询生成、逻辑优化LQT构建和物理执行LQT执行。我们的方法主要关注逻辑优化而物理优化如缓存机制则留给未来的研究。4.2 原子查询生成为了精确表示中间依赖关系我们采用精心设计的提示技术利用LLM将复杂查询分解为多个原子查询详细提示见附录A。具体来说我们在提示中提供了原子查询的明确定义以及示例说明引导LLM以主语谓语宾语的形式构建每个原子查询。在本文中每个原子查询都是不可分割的并对应于一个单一的关系三元组。例如从图2中的ERP派生的原子查询“早期的基督教赞美诗有哪些”对应于三元组早期的基督教赞美诗是。这种严格的一一映射确保了分解结果的语义原子性以及原子查询与三元组之间的自然映射从而保留了原始查询的逻辑结构并能够精确检索支持文档。这些原子查询可以根据三种语义关系类型组织成LQTi亲子关系一个原子查询是父节点另一个是子节点子节点在语义上依赖于或细化父节点。ii兄弟关系两个查询在语义上独立作为LQT同一层的兄弟节点。iii无关系两个查询没有有意义的语义联系在LQT中不共享任何亲子或兄弟关系。4.3 逻辑查询树构建类似于数据库查询规划中的LQT构建我们扩展了Selinger动态规划DP范式[29]来将这些原子查询组织成LQT。在DP之前我们加入了关系预处理以减少LLM调用次数。在DP过程中我们提出了循环预防机制以确保被视为有向无环图DAG的LQT保持无环并提出了上下文感知合并以保持全局语义一致性确保每次局部合并都与树结构对齐。在整个过程中我们使用多维成本模型评估所有候选树以优化LQT。LQT构建过程的伪代码列于附录B。关系预处理。为减少DP过程中评估潜在节点合并所需的LLM调用次数我们在DP之前引入了关系预处理。在我们的框架中原子查询之间的无关系是在关系预处理阶段确定的而非在DP过程中。给定一个ERP我们利用LLM对所有原子查询对 (qi,qj) 进行语义评估并将其分类为三种关系类型“无关系”、“兄弟关系”和“亲子关系”。具体来说“无关系”查询对的概念以及代表性示例被纳入LLM提示中以指导模型识别无关的原子查询对。识别出的关系在此阶段被缓存。如图2所示我们标记了原子查询之间的无关系。通过观察大量样本我们发现LLM能够准确识别无关的查询对第6.4节。因此所有标记为“无关系”的查询对在DP期间被立即剪枝无需调用LLM。用于确定原子查询之间关系的详细提示见附录A。虽然成本函数是手动设计的但每个维度例如树大小、结构密度都是基于对LQT和错误传播的直观理解选择的作为一种可解释的结构性归纳偏置引导LQT构建向健壮的结构发展。循环预防。为保持LQT的DAG结构算法在DP期间首先检查合并两个节点是否会引入环。如果是则禁止该合并。上下文感知合并。为确保每次局部节点合并都与树结构对齐我们引入了上下文感知合并来确定两个节点之间是否存在“亲子”关系。其关键思想是将部分构建的LQT纳入LLM提示中从而能够评估候选节点的语义兼容性。因此该技术通过将每次节点合并置于不断发展的上下文中提高了最终LQT的质量。成本模型。与基于定义良好的模式和统计信息估计物理执行成本I/O、CPU和内存的传统数据库成本模型不同我们提出的成本模型旨在从结构和语义两个角度评估LQT的质量。它从结构合理性和派生质量方面评估LQT同时将语义一致性和与原始查询的对齐作为优化目标纳入考量。具体而言候选树的成本从以下五个方面进行评估树大小 (ts):即LQT中的节点数。较大的树大小鼓励包含尽可能多的原子查询从而防止丢失基本语义单元并确保推理链保持完整。结构密度 (sd):即LQT中的边数。足够密集的结构反映了原子查询之间丰富的语义依赖关系有助于保持它们的相互关联性。树深度 (td):即从根节点到任何叶节点的最大距离。控制深度可防止树退化为一个长链这会导致顺序瓶颈并加剧错误传播。树平衡度 (tb):树的平衡度通过子树高度差来衡量。平衡的树结构有助于进一步提高并行效率同时防止树退化为过深的链。语义相似度 (ss):我们将LQT转换为自然语言并使用BGE [38] 衡量其与原始查询的相似度。该维度通过强制与原始查询意图对齐来指导优化器将构建的树锚定到原始查询并确保规划在语义上保持准确。完整提示见附录A。总体而言与依赖于定义良好的统计信息和物理成本指标的数据库查询优化不同我们方法中的“最优LQT”仅在启发式和LLM驱动的函数下是最优的。因此我们的方法更好地被视为一种结构化搜索策略而非传统的基于成本的优化。由于成本估计的启发式性质数据库查询优化中的DP最优性保证不能直接应用于我们的LQT设置。尽管如此PlanRAG仍然是一种结构化的、受数据库启发的规划方法有效地指导了语义组合但并未声称具有同等的理论保证。4.4 逻辑查询树上的执行策略在获得优化的LQT后我们在LQT上迭代执行自底向上的聚合、重写、检索和生成。在LQT中每个节点 vv 代表一个原子查询。叶节点和非叶节点的处理方式不同。叶节点直接从语料库中检索并生成答案4.5 提示交互与编排我们的框架在不同阶段涉及多个LLM提示它们在一个结构化的流程中交互。具体而言每个阶段的输出作为后续步骤的输入形成连贯的信息流。(1) 在原子查询生成阶段LLM使用图2中的提示1将ERP分解为原子查询。(2) 在关系预处理阶段应用图2中的提示2来确定原子查询之间的语义关系并将识别出的无关对缓存以便在LQT构建期间进行后续剪枝。(3) 在LQT构建期间进一步调用LLM进行上下文感知合并此时部分构建的树被整合到提示中图2中的提示3以指导局部决策。(4) 在成本建模阶段我们提示图2中的提示4LLM将候选LQT转换为自然语言查询然后与原始查询进行比较以估计语义对齐程度。(5) 在执行阶段我们使用LLM图5中的提示5聚合子节点的查询和答案作为上下文并使用该上下文重写原子查询以进行后续检索和答案生成。这种分阶段设计确保了中间表示原子查询、关系和部分LQT在提示之间显式传递从而使得整个流程中的步骤能够协调进行。4.6 复杂度分析LQT构建的时间复杂度。我们的方法侧重于使用Selinger动态规划算法构建LQT。尽管该算法具有指数级的理论时间复杂度经典上界为 O(n2n)但根据我们的统计在实际ERP场景中单个查询很少被分解为超过15个原子查询。超过15个原子查询的案例极为罕见而大多数查询涉及的原子查询数量较少使得搜索空间可以接受。即使在涉及超过20个原子查询的更复杂场景中我们的方法在保持计划质量和执行效率方面仍然是可行的。ERP中的主要成本并非来自规划本身而是来自LLM调用。冗余的规划步骤可能会引入冗余的检索和在规划期间不必要的LLM调用。相比之下DP的搜索时间与下游成本相比可以忽略不计。因此在规划期间确定更好的执行结构具有实际效益它减少了不必要的LLM调用提高了检索效率并控制了整体系统成本。在DP期间任何标记为“无关系”的对都会被立即剪枝无需调用LLM。设 p0 为检测“无关系”对的准确率则DP期间的预期LLM调用次数可以近似为4.7 WikiWeb-ERP据我们所知目前没有专门为ERP设计的专用基准。如表2所示现有数据集中ERP的比例相对较低。为了全面评估我们的PlanRAG在ERP上的性能我们构建并发布了一个专为RAG系统定制的高质量数据集WikiWebERP。WikiWeb-ERP的构建过程如下。首先我们从两个互补方面收集ERP以确保多样性和代表性。具体来说(i) 数据集采样我们从几个现有数据集BrowseComp [34]、BrowseComp-Plus [4]、BrowseComp Long Context [34] 和 GAIA [24]中选择了问答对以保证数据可靠性和跨数据集可比性。(ii) 生成式扩展我们采用WebSailor [20] 提出的查询生成方法来进一步扩展这些问答对该方法模拟了实际开放领域场景中的真实互联网信息流。类似地我们从两个来源构建文档集合。首先我们结合稠密和稀疏检索技术从与每个查询相关的维基百科转储中检索候选文档作为第一个文档来源。其次我们使用WebSailor [20] 中的网页收集方法为每个查询从互联网上抓取真实网页形成第二个文档来源。这些网页捕捉了现实世界知识的分布和开放领域信息中固有的噪声。这两类文档共同构成了WikiWeb-ERP的文档集合确保了检索来源的真实性和多样性。总体而言WikiWeb-ERP包含3536个查询和53682个文档。其中2405个查询来自现有数据集1131个是通过WebSailor [20] 生成的。在文档方面24050个来自维基百科转储29632个来自真实网页抓取。查询和文档的平均长度分别为93.48个词和121.09个词。表2不同数据集中ERP的比例。BC、BCPlus和BC-LC分别是BrowseComp [34]、BrowseComp-Plus [4] 和 BrowseComp Long Context [34] 的缩写。5 实验5.1 评估指标遵循先前关于RAG和多跳QA的工作[6]我们使用四个互补指标评估模型性能准确率Acc、精确匹配EM、令牌级F1F1和语义准确率Acc。这些指标共同评估事实正确性、词汇重叠和语义一致性这对于ERP尤其重要。(i) Acc衡量生成答案是否充分捕捉了标准答案的关键内容。(ii) EM衡量生成答案与标准答案之间的精确匹配程度。(iii) F1评估生成答案与标准答案之间的令牌级相似度。(iv) 我们还使用 gpt-3.5-turbo-instruct 计算Acc以进行更全面的评估其中LLM以标准答案为参考评估生成答案的正确性。5.2 基线方法为确保全面评估我们将我们的PlanRAG与DirectLLM和NaiveRAG [18] 以及两大主流高级RAG系统进行了比较。基于迭代的方法包括RetGen [30]、GenGround [31]、DualRAG [6] 和KiRAG [8]它们沿着顺序推理链迭代执行检索和生成。相比之下基于图的方法包括ChainRAG [41]、HopRAG [23] 和 LEGO-GraphRAG [2]它们构建文档/推理图以捕获多跳依赖关系并沿图路径检索证据。DirectLLM 不检索外部知识直接生成答案。NaiveRAG 检索一次文档并基于检索到的文档生成答案。RetGen 通过迭代的检索-生成协同策略增强LLM以回答多跳问题。GenGround 通过检索到的证据迭代生成和验证答案以改进多跳问答。DualRAG 使用多视角相关性评分联合对查询和文档进行排序。KiRAG 通过使用知识三元组构建推理链来增强迭代检索增强生成。ChainRAG 通过句子图迭代重写子问题并检索句子以解决多跳QA中的缺失实体问题。HopRAG 使用伪查询构建段落图并通过“检索-推理-剪枝”机制执行多跳推理。LEGO-GraphRAG 将GraphRAG检索模块化为子图提取和路径检索模块以实现灵活构建和实例的系统评估。5.3 实现细节我们在三块NVIDIA A800 80GB GPU上进行所有实验。在本文中我们使用BM25作为检索器并为所有方法使用LLaMA-3-8B作为基础模型。鉴于WikiWeb-ERP数据集中的文档本身简洁长度始终低于10000个令牌的标准分块大小我们将每个完整文档视为一个单独的段落不再进行进一步分割。此外我们将线程数动态设置为可用核心数与当前层独立节点数之间的较小值通常在4到7之间这有助于在最大化并发性的同时避免线程切换开销。在整个流程中我们使用GPT-40-mini进行原子查询生成、关系预处理、上下文感知合并和查询重写。我们通过网格搜索将公式3中的缩放因子alpha设置为10以避免语义偏差。对于ChainRAG、DualRAG、KiRAG和LEGO-GraphRAG我们使用原始作者发布的标准实现在我们的数据集WikiWeb-ERP上重现了结果。对于ChainRAG我们采用了利用子问题检索到的上下文来生成答案的上下文集成设置[41]。对于RetGen、GenGround和HopRAG我们按照其论文中报告的参数设置在我们的数据集上复现了实验。对于LEGO-GraphRAG我们在检索前通过Microsoft GraphRAG [7] 从语料库构建图。5.4 主要结果如表3所示我们的方法PlanRAG w/ Ret在我们的WikiWeb-ERP数据集上取得了最先进的性能最佳结果以粗体突出显示次优结果以下划线标出其中w/ Ret和w/o Ret分别表示在PlanRAG框架中启用和未启用外部检索。结果表明与DirectLLM和NaiveRAG相比PlanRAG w/ Ret取得了显著的性能提升证明了我们的框架在处理ERP方面的有效性。PlanRAG w/ Ret也优于几种先进的基于迭代的RAG方法包括RetGen、GenGround、DualRAG和KiRAG这些方法通常遵循分解、检索和生成的链式过程。然而这种迭代机制通常缺乏检索和生成之间的全局规划导致不相关的文档检索和错误累积。相比之下我们的框架在生成之前执行全局规划通过动态规划优化LQT并确保检索与生成之间更好的对齐。此外我们的框架超越了基于图的RAG方法ChainRAG、LEGO-GraphRAG和HopRAG这些方法利用图结构来检索逻辑连接的信息以进行多跳QA。虽然这些方法通过探索图邻域提高了检索召回率但它们通常引入了图构建和遍历的计算开销并且可能仍然通过虚假连接传播错误。PlanRAG中的全局规划机制通过动态规划直接优化了检索路径从而带来了更健壮的性能。最后PlanRAG w/ Ret和PlanRAG w/o Ret均优于NaiveRAG和RetGen这证实了性能改进归功于我们的规划机制而不仅仅是检索本身。5.5 消融研究我们在LQT构建上进行消融研究以验证我们提出方法的有效性。如表4所示我们去除了关系预处理、循环预防和上下文感知合并以评估它们对PlanRAG整体性能的影响。值得注意的是去除关系预处理w/o rp并未导致显著的性能下降因为关系预处理主要降低系统成本如运行时间、令牌成本和LLM调用次数而非直接提高生成质量。去除循环预防w/o cp导致显著的性能下降表明该机制对于维护LQT结构和防止循环引起的逻辑错误至关重要。类似地禁用上下文感知合并w/o ca导致性能下降突显了部分构建的树在维持整个规划过程中语义连贯性的重要性。为评估成本模型在指导LQT构建方面的有效性我们还评估了PlanRAG在去除成本模型中每个维度后的变体性能。表4中的结果一致表明去除任何单一维度都会导致整体性能下降表明每个维度都对优化目标有所贡献。这些表3在我们的WikiWeb-ERP上比较的检索方法的性能。发现突显了将所有五个维度结合起来以实现LQT构建中结构健壮性和语义合理性的重要性。值得注意的是排除语义相似度w/o ss导致最显著的性能下降。虽然成本模型中的结构性正则化项例如树深度或平衡度调节执行效率但语义相似度作为一个全局对齐信号防止LQT偏离原始意图表明有效的ERP规划需要语义锚定。5.6 跨不同基础模型和检索器的鲁棒性基础模型。为了验证我们的框架在不同LLM上的泛化能力我们还使用多种LLM作为基础模型进行了实验包括Llama-3-70B、Llama-27B/13B/70B和Qwen-2.57B/14B/72B。对于每个基础模型我们比较了NaiveRAG、PlanRAG w/o Ret和PlanRAG w/ Ret的性能。如表5所示PlanRAG w/ Ret在所有模型规模和基础模型上均一致地带来了性能提升表明我们框架的有效性与模型无关。值得注意的是对于参数规模较小的模型例如7B和13B改进更为显著这表明我们的规划策略补偿了它们有限的参数化知识和能力。这一观察突显了我们的方法即使在有限的计算预算下也有潜力增强RAG系统。检索器。除了改变基础模型外我们还在不同的检索器上进一步评估了我们的框架包括BGE-small [38]5.7 效率分析关系预处理对LQT构建效率的影响。为了验证关系预处理对LQT构建的影响我们比较了启用和禁用该组件时的时间、令牌成本和LLM调用次数。表7报告了从WikiWeb-ERP中采样的100个查询的结果。显然启用关系预处理将LQT构建的平均时间从82.8秒减少到8.4秒LLM调用次数从63.6次减少到10.4次令牌成本从3454.4降低到1265.2。结合表4的结果这种优化显著降低了计算成本同时未牺牲生成质量。并行执行对LQT执行效率的影响。为了验证并行执行对LQT执行的影响我们在从WikiWeb-ERP随机采样的100个查询上比较了单线程顺序执行w/o parallel和多线程并行执行w/ parallel的LQT执行。表7显示并行执行将平均执行时间从18.7秒减少到7.3秒实现了 2.56× 的加速。这种改进源于LQT的结构特性允许节点并行执行。值得注意的是并行执行主要减少了执行时间但并未减少LLM调用次数或令牌成本。总体而言这些发现表明并行执行在提高效率方面是有效的使PlanRAG能够在实际部署中实现高准确率的同时满足实时性能需求。系统成本比较。为更好地评估PlanRAG的效率我们将其系统成本与各种基线方法进行了比较分别报告了100个样本上的平均令牌成本、运行时间和峰值GPU内存使用量。图3清晰地展示了不同RAG系统在系统成本上的差异。这些基于迭代的基线依赖于多轮检索和生成其中累积的错误通常触发额外的LLM调用增加了令牌消耗。它们固有的顺序工作流程阻碍了并行执行进一步增加了总体运行时间。基于图的基线在图构建和遍历方面引入了大量开销。随着图的增长冗余节点和不相关边迅速累积从而膨胀了资源使用。与这些基线相比PlanRAG采用全局规划机制来减少冗余检索和不必要的推理。这使得执行更加聚焦且易于并行化。虽然规划引入了初始成本但整体工作流程变得更加简化从而在系统成本和性能方面实现了优越的成本-效益权衡。5.8 多跳问答的结果为了进一步验证PlanRAG在ERP之外的通用的生成能力我们在四个广泛使用的多跳QA基准上评估了我们的方法包括HotpotQA [39]、MuSiQue [33]、2WikiMultiHopQA [12] 和 StrategyQA [11]。如表8所示PlanRAG在大多数数据集上取得了有竞争力的性能并在StrategyQA上获得了最佳结果展示了其在ERP之外的泛化能力。特别是PlanRAG在HotpotQA和MuSiQue上的表现与基于图的基线相当但在2WikiMultiHopQA上存在差距后者推理链更明确因此更适合基于图的检索方法。相比之下PlanRAG主要针对依赖关系模糊的ERP设计而我们的方法可以执行显式的查询规划以有效提高性能。6 进一步分析与讨论6.1 缩放因子 αα 的敏感性分析为了进一步验证成本模型中缩放因子 αα 的有效性我们进行了敏感性分析。具体而言我们在 [1, 20] 范围内变化 α并评估最终准确率。图4(a)显示性能随着 α 的增加先提升后稳定在 α10 时达到最高准确率进一步增加 α 带来的收益有限或略有下降。从缩放角度来看结构项树深度或平衡度随节点数量增长而语义相似度项在 [0, 1] 范围内归一化导致尺度不匹配。引入 α 旨在对齐它们的贡献。这些结果表明α 不是一个任意的调优参数而是在平衡结构正则化和语义对齐方面起着关键作用其最优值对应于两者之间良好校准的权衡。6.2 跨查询复杂度的性能和成本比较跨查询复杂度的性能比较。为了进一步检验PlanRAG在不同查询复杂度下的鲁棒性我们根据原子查询的数量将查询分为 {5,6,7,8,9,9} 的桶并报告每个桶内的平均准确率。这种设置反映了原子查询数量越多通常意味着依赖链越深的直觉。图4(b)中的结果显示PlanRAG在所有桶中均一致优于基线。值得注意的是虽然所有方法都随着原子查询数量的增加而表现出性能下降但PlanRAG的下降速度明显更慢。PlanRAG显式编码依赖关系并执行全局结构优化从而局部化错误并及早剪枝次优计划。此外其成本模型中的结构正则化项例如树深度和平衡度防止规划退化为长链从而在高复杂度下实现更稳定的性能。总体而言这些结果强调了PlanRAG在扩展至传统RAG流程之外的高复杂度查询方面的有效性。跨查询复杂度的系统成本比较。为评估PlanRAG在查询复杂度增加时的系统成本我们分析了系统成本作为原子查询数量 nn 的函数。我们将WikiWeb-ERP中的ERP按照 n∈{5,6,7,8,9,9} 进行分桶并测量四个指标(a) 令牌成本(b) 运行时间(c) 峰值GPU内存以及 (d) LLM调用次数。如图5所示所有四个指标的值都随着原子查询数量 n 的增加而增加。具体而言令牌成本和LLM调用次数随 n 近似线性增长反映了随着LQT规模增大中间步骤的扩展。运行时间也随 nn 增加而峰值GPU内存从 n5 时的约9.0 GB上升到 n9 时的近12 GB这是由于执行期间KV缓存和中间结果的累积。总体而言这些结果表明PlanRAG在查询复杂度增加时表现出可预测的系统成本增长证实了其对于复杂查询的可扩展性。6.3 LQT质量评估为检验我们LQT构建方法的有效性我们对我们的方法生成的LQT与LLM直接生成的LQT进行了比较评估。LLM的评估提示见附录A它衡量LQT是否表现出结构健壮性和语义合理性。每个LQT的质量由人工评估者和LLM评判员分别使用以下4分制1~4分顺序量表进行评估。4 - 优秀LQT展现出良好形成且稳定的结构原子查询之间具有明确定义的依赖关系同时在整个树中保持与原始查询意图的强语义对齐。3 - 良好LQT在结构上基本连贯且在语义上基本一致存在轻微的结构缺陷或细微的语义模糊性但不会损害整体过程。2 - 一般LQT显示出明显的结构弱点例如缺失或不正确的依赖关系或语义不一致部分影响了工作流的正确性。1 - 差LQT缺乏结构健壮性和语义合理性表现出无组织的依赖关系和显著的语义偏离。最终得分 SS 计算为所有30个生成的LQT的平均得分其中 si 表示分配给第 ii 个LQT的得分。表9报告了人类评估和LLM评判的结果。结果表明我们的方法构建的LQT质量优于LLM直接生成的LQT。此外我们通过从成本模型中移除语义相似度构建了一个消融变体并评估了生成的LQT。质量明显下降表明语义相似度在维持LQT的语义对齐方面起着关键作用。具体来说一个强大的LLM可以在单步中直接生成一个计划。然而这种方法通常缺乏稳定的结构约束不同的调用可能会产生不一致或违反依赖关系的计划。相比之下我们首先将复杂查询分解为原子查询然后通过显式的结构约束构建LQT确保清晰的依赖关系和可执行的推理。LLM有时生成的线性图对于ERP并非最优。在许多情况下一些原子查询在语义上是独立的可以并行执行。例如在图1中识别候选作者及其去世年份和检索候选年表在很大程度上是独立的任务可以在通过“年表的最后一年与作者去世年份匹配”这一约束对齐之前分别执行。因此LQT将这些查询组织成一棵树而非严格的线性链减少了顺序依赖和错误传播。值得注意的是Claude生成的线性结构类似于ReTGen和GenGround等基线中使用的顺序推理策略而PlanRAG在表3中显著优于它们突显了树状结构规划的优势。6.4 LQT构建的细粒度分析为了更全面地评估LQT构建我们从四个关键方面进一步分析了100个随机采样的查询原子查询生成、原子查询覆盖率、线性退化率和关系分类准确率。评估结果列于表10。原子查询生成。为评估原子查询生成的准确率我们对100个随机采样的查询进行了人工评估。评估结果表明LLM生成的原子查询达到了 98.5% 的准确率。报告的 98.5% 准确率是通过对生成的原子查询及其对应三元组进行人工标注获得的多个标注者根据预定义标准独立评估每个三元组的正确性。具体而言标注者间一致性使用Fleiss kappa评估达到 k0.82表明标注者之间具有强一致性。这表明我们的分解方法能够从原始ERP中提取最小语义单元从而为后续的LQT构建提供了可靠的基础。原子查询覆盖率。为验证LQT具有高原子查询覆盖率我们系统地统计了所有生成的LQT中的原子查询数量。结果显示在 94.2% 的情况下PlanRAG实现了所有原子查询的完全覆盖。这表明我们的规划机制能够整合绝大多数原子查询从而支持基于完整原子查询链的执行。线性退化率。鉴于ERP具有固有的高不确定性和难以简化的特点我们的规划机制通过LQT的结构显式地组织依赖关系。在理想情况下原子查询之间的语义关系清晰且易于区分PlanRAG构建出结构良好的LQT。然而在最坏情况下即原子查询在很大程度上是语义独立的LQT可能退化为近似线性的链状结构。为量化这种情况发生的频率我们对生成的LQT进行了结构分析。结果显示仅有 3.2% 的查询表现出近线性结构而绝大多数查询超过 96%保持着显式的树状依赖关系。关系分类。正如第4节所强调的我们利用LLM在关系预处理中识别无关系。为评估分类的可靠性我们人工验证了预测的语义关系并测量了其分类准确率。结果显示LLM在识别无关系方面的分类准确率达到 96.4%而亲子关系和兄弟关系的准确率分别为 83.1% 和 87.9%。无关系的高准确率表明关系预处理可以提高LQT构建的效率。6.5 阶段级鲁棒性分析为分析阶段级鲁棒性我们进行了受控扰动实验以检查错误如何通过PlanRAG流程传播结果见表11。我们从数据集中随机采样100个查询并在三个阶段注入噪声噪声级别为 10%、20% 和 30%。1原子查询生成我们随机移除原子查询以模拟不完整或有噪声的分解。2关系分类我们随机选择边并将其关系替换为随机选择的标签亲子、兄弟或无关系从而扰动树结构。3LQT执行我们将检索到的内容替换为不相关的文本以模拟检索和推理错误。对于每个阶段我们在保持其他阶段不变的情况下改变噪声水平并评估对最终答案准确率的影响。结果显示性能随噪声增加而逐渐下降表明错误确实在各个阶段之间传播。然而下降是平滑的而非灾难性的这表明PlanRAG对上游错误具有鲁棒性这主要归功于其结构化的规划。6.6 错误分析为评估PlanRAG在ERP上的可信度我们将查询中的错误分为四类(i) 规划错误 (36%)(36%) 主要源于未能充分识别原子查询之间的依赖关系导致LQT无法准确捕获基础逻辑顺序从而损害整体性能。这些错误通常由模糊的关系或低置信度的合并决策引起突显了更准确的关系分类的必要性。(ii) 检索错误 (32%) 发生在检索器仅获取部分相关但最终不相关的信息或未能检索到关键证据段落时从而削弱了对后续步骤的支持。这些错误通常由实体不匹配或查询重写不充分引起表明可以通过混合检索和优化的查询重写来提高检索鲁棒性。(iii) 推理一致性错误 (19%) 发生在各个原子查询的答案是正确的但它们整合到全局推理结果中时偏离了事实结论反映了全局一致性的局限性。(iv) 生成与综合错误 (13%) 在最终答案聚合阶段观察到表现为实体指代歧义或输出格式混乱通常由长推理链上结构化表示的不稳定性引起。总体而言我们的PlanRAG的主要瓶颈在于规划和检索进一步的性能提升需要强化自适应规划机制和鲁棒的检索策略。7 结论在本文中我们提出了PlanRAG一个受数据库查询规划启发的、为ERP设计的端到端RAG框架。PlanRAG首先将ERP分解为原子查询。然后这些原子查询通过动态规划组织成优化的LQT以建模语义依赖关系从而减轻检索噪声和错误累积。基于优化的LQTPlanRAG以自底向上和并行的方式迭代执行聚合、重写、检索和生成递归传播中间结果以高效地产生最终答案。在新发布的WikiWeb-ERP数据集上的广泛实验表明相较于基于迭代和基于图的RAG基线PlanRAG取得了持续的性能提升进一步的分析证实了我们提出的规划机制的高效性、有效性和可解释性。文本[[85, 659, 481, 894], [517, 107, 912, 177]]我们承认我们的方法存在一些局限性。首先PlanRAG难以泛化到简单问题场景因为其规划机制对于直接查询可能是不必要的。其次对于逻辑复杂度低或具有清晰逐步路径的查询该方法可能退化为标准的多跳QA分解范式。此外我们的成本模型是一个简化的抽象并未基于文档长度或任务复杂度等因素显式地归一化成本。其目标不是精确估计每个语义查询的真实执行成本而是提供一个轻量级的启发式方法来指导计划选择。虽然不同的子计划可能具有相同的建模成本但实际执行开销可能不同检索和推理成本的变化部分通过语义相似度和结构项反映这有助于优先选择更连贯和高效的方案。此外我们计划纳入微调策略以减少对LLM在原子查询生成、关系预处理和查询重写等组件中的依赖例如用轻量级开源模型如LLaMA和Qwen系列替代GPT-4o-mini。最后我们将探索如何将LQT映射到物理查询计划并结合系统级优化如缓存机制以提供更完整的系统级优化方案。