检索很廉价，给我看代码：面向检索增强生成的可执行多跳推理

# 检索很廉价，给我看代码：面向检索增强生成的可执行多跳推理  
来源：https://arxiv.org/html/2605.12975  

孙嘉烁\*![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)石金梦\*![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)谢宜轩![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)王赛灼![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/hkust_logo.png)Jash Rajesh Parekh![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png) 蒋鹏程![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)石志义![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)范嘉俊![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)郑庆龙![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)李沛然![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/tamu_logo.png) 王少文![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)刘戈![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)韩家炜![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)  

![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/uiuc_logo.png)伊利诺伊大学厄巴纳-香槟分校  
![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/hkust_logo.png)香港科技大学  
![[无标题图片]](https://arxiv.org/html/2605.12975v1/figures/tamu_logo.png)德克萨斯农工大学  

![[无标题图片]](https://arxiv.org/html/2605.12975v1/x1.png)GitHub (https://github.com/GasolSun36/PyRAG)  
![[无标题图片]](https://arxiv.org/html/2605.12975v1/x2.png)项目页面 (https://gasolsun36.github.io/PyRAG/)  
![[无标题图片]](https://arxiv.org/html/2605.12975v1/x3.png)模型 (https://huggingface.co/gasolsun/PyRAG-7b)  

###### 摘要  

检索增强生成（RAG）已成为知识密集型问答的标准方法，但现有系统在多跳问题上仍然脆弱——解决这类任务需要串联多个检索和推理步骤。关键挑战在于：当前方法通过自由形式的自然语言表示推理，中间状态是隐式的，检索查询可能偏离目标实体，错误检测由产生该错误的同一模型完成，导致自我反思成为一种不可靠、无基础支撑的信号。我们观察到，多跳问答是一种典型的逐步计算形式，并且这种结构化过程与代码专用语言模型所训练的操作方式高度一致。受此启发，我们提出了PyRAG，一个将多跳RAG重新表述为程序合成与执行的框架。PyRAG不再使用自由形式的推理轨迹，而是将推理过程表示为可执行的Python程序，通过检索和QA工具操作，将中间状态暴露为变量，通过执行产生确定性反馈，并生成整个推理过程的可检查迹。这种形式化方法进一步支持了基于编译器的自我修复和由执行驱动的自适应检索，无需额外训练。在五个QA基准（PopQA、HotpotQA、2WikiMultihopQA、MuSiQue和Bamboogle）上的实验表明，PyRAG在免训练和强化学习训练两种设置下均持续优于强基线，在组合式多跳数据集上尤其显著。我们的代码、数据和模型已公开发布于：https://github.com/GasolSun36/PyRAG。

## 1 引言  

检索增强生成（RAG）[8, 23]已成为知识密集型问答的基础范式，使大型语言模型（LLM）能够将输出植根于外部证据，产生更事实性的回答[6, 11]。虽然标准RAG在单跳查询上表现良好，但许多现实问题需要多跳推理[12, 48, 43, 30, 34]，例如必须通过串联多个来源的证据来组装答案。例如，回答“谁更年长，Jed Hoyer还是John William Henry II？”需要检索两个出生日期，将它们作为中间结果保留，并通过显式比较来合成。这类问题在开放域问答中普遍存在，考验系统规划、迭代检索和跨步骤聚合证据的能力。图1展示了三种典型范式——标准RAG、搜索智能体以及我们的PyRAG——如何处理该问题，突显了各自在维护中间状态和组合证据方面的结构性差异。

现有的多跳RAG方法通常通过自由形式的自然语言推理来实现，包括思维链提示[45]、迭代检索与推理循环[44, 49, 31, 34]，以及最近的强化学习训练的搜索智能体[17, 36, 50, 2]。虽然这些方法引入了分解和迭代，但推理状态仍然隐含在文本中：中间结果嵌入在叙述形式中，而非作为离散对象维护；检索查询可能偏离目标实体（例如，当问题涉及“John William Henry II”时却查询“英格兰的亨利二世”）；错误由产生它们的同一LLM检测，使自我反思成为不可靠、无基础支撑的信号。因此，推理轨迹难以控制、验证和调试。

尽管并行的工作线——程序引导推理[7, 3, 4, 25, 27, 28]——确实利用了可执行代码，但它们假设推理所需证据事先存在于自包含输入中，如表或封闭语料库。这一假设在开放域多跳QA中不成立，因为中间答案在合成时是未知的，后续查询必须依赖于早期检索的结果。表1总结了这些推理范式在五个关键维度上的差异：多跳能力、可解释性、结构化规划、反思和可执行接口，从而启发了PyRAG作为支持所有五个维度的范式设计。

![参见标题]()

图1：标准RAG、搜索智能体与PyRAG（我们的）的比较。给定多跳问题“谁更年长，Jed Hoyer还是John William Henry II？”，(a) 标准RAG执行单次检索，容易得到不完整或噪声证据；(b) 搜索智能体遵循非结构化的迭代轨迹，模糊查询和实体漂移（例如，检索到“英格兰的亨利二世”而非“John William Henry II”）导致错误在步骤间累积；(c) PyRAG将问题分解为原子子查询，生成可执行程序，通过显式变量检索、回答和合成中间结果，产生可控、可检查且准确的推理过程。

我们认为，这些限制的根本原因是任务结构与推理表示之间的不匹配。多跳问答本质上是一种逐步计算的形式：它将问题分解为子问题，计算中间结果，并通过显式依赖关系组合它们。这一过程镜像了程序构建和执行的方式——一系列对命名变量的操作，通过数据流连接。然而，当前方法只是将这种结构化计算编码为无结构的自然语言，迫使LLM同时进行规划、维护状态和推理。我们还观察到，代码专用语言模型被显式训练用于这种确切的行为模式：维护中间变量、强制执行控制流以及生成逐步的结构化程序[14]。这暗示了一种自然的重新表述：如果将多跳推理表示为程序合成而非自由形式生成，我们可以直接利用代码模型的归纳偏差，同时获得显式状态、执行的确定性反馈以及推理过程的可检查迹。

基于这一观察，我们提出了PyRAG，一个为多跳RAG提供可验证执行接口的框架。PyRAG将多跳推理演化为Python程序的合成与执行，该程序使用少量工具API：`retrieve(query)` 和 `answer(query, docs)`，其中每一步检索证据、计算中间答案并将结果存储为可在下游复用的变量。该框架包含三个专门的智能体：**分解智能体**将输入问题分解为原子子查询，**规划智能体**将子查询翻译为可执行程序，**答案智能体**从检索到的证据中生成简短答案。关键在于，可执行的表述自然产生了两种无需额外训练的改进机制：**基于编译器的自我修复循环**中，运行时异常为规划智能体提供确定性信号以修改程序；**由执行驱动的自适应检索**机制，当中间答案表明证据不足时，选择性地增加检索范围。这两种机制直接源自程序执行接口，而非依赖LLM自我反思。

我们在五个开放域QA基准（PopQA、HotpotQA、2WikiMultihopQA、MuSiQue、Bamboogle）上评估了PyRAG，涵盖免训练和RL训练设置。我们的贡献如下：

- • 我们识别出多跳推理与其在现有RAG系统中表示之间的结构性不匹配，并将多跳QA重新表述为一个**可执行的**逐步过程。
- • 我们提出了PyRAG，一个提供可验证执行接口的框架，具有显式状态、确定性编译器反馈和可检查的推理迹，并配备了执行引导的自我修复和自适应检索。
- • 我们展示了代码专用模型的优势是任务相关的：它仅在程序合成接口下显现，突显了模型能力与推理接口必须协同设计。
- • 实验上，PyRAG在标准RAG基础上平均EM提升+11.8（免训练，7B），在Bamboogle上提升+25.5，而PyRAG-RL在7B规模RL训练方法中取得了最高平均EM，并在Qwen3-4B和LLaMA-3.1-8B骨干网络上具有泛化能力。

表1：推理范式比较。搜索智能体在结构化规划上标记为部分支持，因为其规划是隐式的，在思维轨迹中反应性地展开，而非作为显式、可检查的产物物化；在反思上标记为部分支持，因为错误信号来自LLM自身的自我判断，而非有基础的外部反馈。它们完全缺乏可执行接口，因为推理轨迹是自然语言，没有变量、数据流或确定性执行。我们的PyRAG通过将多跳推理过程表示为可执行程序，解决了所有三个限制。

| 范式 | 多跳能力 | 可解释性 | 结构化规划 | 反思 | 可执行接口 |
|------|----------|----------|------------|------|------------|
| 标准RAG（单次） | ✗ | ✗ | ✗ | ✗ | ✗ |
| 搜索智能体（自由形式） | ✓ | ✓ | △ | △ | ✗ |
| **PyRAG（可执行程序）** | ✓ | ✓ | ✓ | ✓ | ✓ |

✓：支持 △：部分支持 ✗：不支持

![参见标题]()

图2：PyRAG框架。给定一个多跳问题，PyRAG分为三个阶段：(1) 分解：LLM将问题分解为原子、可独立回答的子查询；(2) 规划：代码专用LLM合成一个可执行Python程序，使用两个工具原语 `retrieve(query, topk)` 和 `answer(query, docs)`，中间结果绑定到变量并通过显式数据依赖组合；(3) 执行：程序在Python解释器中逐步运行，产生可检查的迹和基于基础支撑的最终答案。两种执行引导的改进机制优化此流程：(A) 基于编译器的自我修复，利用运行时异常（如 `SyntaxError`, `NameError`）作为确定性信号，让规划者修改并重新执行程序；(B) 由执行驱动的自适应检索，对于其答案表明证据不足的子步骤，增加 `top-k` 检索预算。两种机制均无需训练，且依赖于有基础支撑的执行反馈而非LLM自我反思。

## 2 方法

### 2.1 概述

我们提出PyRAG，一个为多跳RAG引入可执行接口的框架，如图2所示。PyRAG不再将推理表示为自由形式的自然语言，而是将问题分解为一系列结构化步骤，并通过程序执行它们。给定问题 \( q \)，PyRAG包含三个组件：(1) **分解智能体**将 \( q \) 分解为原子子查询；(2) **规划智能体**生成描述推理过程的可执行程序；(3) **答案智能体**基于检索到的证据生成答案。在推理时，生成的程序逐步执行，每一步对应一次检索或问答操作。因此，我们将多跳推理从不透明的叙述转变为显式、可控且可验证的执行过程。

### 2.2 动机：多跳QA作为逐步计算

我们认为，多跳问答可以自然地视为一种逐步计算的形式。解决多跳查询需要系统地将问题分解为组成子问题，计算中间结果，并最终将这些发现合成为最终答案[44, 49, 31, 45]。这一结构化过程与程序化执行的基本原则高度一致：程序定义一系列功能操作，维护中间变量，并强制步骤间的依赖关系[14]。代码专用语言模型被显式训练用于此类行为。它们被优化以生成结构化程序，分解任务，通过变量维护状态，并执行一致的逐步计算。因此，它们为多跳QA处理提供了强大的归纳偏差。受此观察启发，我们将多跳RAG视为一个程序合成问题，其中推理