exp_rpt_bugsinpy-v2

exp_rpt_bugsinpy-v2是一个修复版的Python bug修复任务数据集，包含500个源自BugsInPy的单文件编程任务。该数据集专门解决了原始版本中测试文件损坏导致的奖励信号失效问题，确保每个任务都能产生合理的奖励反馈。数据集采用parquet格式存储，每个任务包含bug描述文档、元数据文件、任务配置文件、Docker环境定义以及测试套件。测试系统采用默认失败验证机制，通过多层检查确保奖励信号的有效性：首先检查代码是否被修改，然后验证代码能否编译和导入，最后运行单元测试并统计通过率。数据集对13个损坏的测试文件进行了机械修复，包括移除格式错误、修正导入语句和修复字节字面量等问题；对于6个无法自动修复的任务，采用通用回退验证机制。奖励信号分布显示：92%的任务采用测试驱动验证，6%需要先修复导入错误，1%使用通用回退，少于1%可能超时。该数据集适用于代码生成、bug修复和智能体训练等任务，特别适合需要可靠奖励信号的研究场景。exp_rpt_bugsinpy-v2 is a fixed version of the Python bug repair task dataset, containing 500 single-file programming tasks derived from BugsInPy. This dataset specifically addresses the issue of reward signal failure caused by corrupted test files in the original version, ensuring that each task can generate reasonable reward feedback. The dataset is stored in parquet format, with each task including a bug description document, metadata file, task configuration file, Docker environment definition, and test suite. The testing system adopts a default failure verification mechanism, ensuring the validity of reward signals through multiple layers of checks: first, check whether the code has been modified, then verify whether the code can be compiled and imported, and finally run unit tests and calculate the pass rate. The dataset has mechanically repaired 13 corrupted test files, including removing formatting errors, fixing import statements, and repairing byte literals, etc.; for 6 tasks that cannot be automatically repaired, a universal fallback verification mechanism is used. The reward signal distribution shows that 92% of tasks adopt test-driven verification, 6% require fixing import errors first, 1% use universal fallback, and less than 1% may time out. This dataset is suitable for tasks such as code generation, bug repair, and agent training, especially for research scenarios requiring reliable reward signals.

原始信息汇总

数据集概述：exp_rpt_bugsinpy-v2

该数据集是 DCAgent/exp_rpt_bugsinpy 的修复版本，专注于 Python 单文件 bug 修复任务。

基本信息

• 语言：英语（en）
• 任务类型：文本生成（text-generation）
• 标签：代码、漏洞修复、智能体、BugsInPy
• 数据规模：1,000 < n < 10,000 条
• 任务数量：500 个单文件 Python 漏洞修复任务（源自 BugsInPy）

---

版本 v2 的改进原因

原始数据集存在以下问题：

• 测试文件损坏：由 LLM 生成的 tests/test_solution.py 文件常包含未定义的 inspect/os 导入、Markdown 围栏、错误装饰器、无效字节字面量以及引用不存在 API 的问题。
• 奖励信号失效：由于 tests/ 目录不可由智能体编辑，任何测试文件错误都导致奖励永久为 0；同时部分有缺陷代码能通过所有测试，导致“不做任何修改”也获得奖励。

v2 版本修复了这些问题，使每个任务都能产生合理的奖励信号。

---

数据格式

数据存储为单个 tasks.parquet 文件，每行一个任务，包含字段：

• path（格式：bugsinpy-NNNN）
• task_binary（任务目录的 gzipped tar 包）

每个任务目录结构如下：

instruction.md # 面向智能体的漏洞描述 metadata.json # 来源/项目/有缺陷和修复版本提交记录 task.toml environment/ Dockerfile # python:3.10-slim + pytest，内置有缺陷解决方案和基线副本 solution.py # 有缺陷的起始代码（智能体编辑 /app/solution.py） tests/ test.sh # 稳健的默认失败验证器 test_solution.py # 每个任务的单元测试（已机械修复） test_state.py # Harbor 断言：reward.txt == "1"，报告 pass_ratio config.json # 测试权重

---

奖励逻辑（tests/test.sh）

验证器为默认失败机制，仅在智能体产生真正可导入的修复时奖励 1：

1. 初始化：echo 0 > reward.txt（默认失败），设置 PYTHONPATH=/app。
2. 无操作检查：/app/solution.py 必须与内置的 /app/.buggy_solution.py 不同。
3. 编译检查：python3 -m py_compile /app/solution.py 必须成功。
4. 导入检查：python3 -c "import solution" 必须成功。
5. 运行测试：执行 pytest /tests/test_solution.py：
   • 方案 A：测试收集并运行 → 奖励 1 当且仅当 passed > 0 and failed == 0；否则 0。
   • 方案 B（回退）：测试文件不可收集 → 奖励 1 当且仅当“已修改 + 编译通过 + 导入成功”。

pass_ratio = passed/(passed+failed) 写入 /logs/verifier/pass_ratio.txt。

---

修复内容

• 机械自动修复 13 个测试文件（方案 A）：移除嵌入的 Markdown 围栏/散文、删除 @pytest.main() 装饰器、将非 ASCII 字节字面量转为字符串、修正 from typing import Enum 为 from enum import Enum、from collections import MutableMapping 为 from collections.abc，并为未定义名称注入缺失的 stdlib 导入（如 os, sys, re, inspect, dataclasses.dataclass, abc.abstractmethod, typing.Optional 等）。
• 通用回退方案（方案 B）：适用于 6 个任务（~1%），其测试文件引用解决方案未暴露的 API（如 await 用于非异步函数、tensorflow、缺失解决方案属性），无法无需正确修复进行自动修复。

---

奖励信号分布（基于 500 个任务的缺陷起始代码）

信号类型	任务数	占比
测试驱动（测试套件可收集，修复→通过）	461	92%
缺陷解决方案无法导入（智能体需先修复导入）	31	6%
通用回退（测试文件损坏→基本检查）	6	1%
超时	2	<1%

---

验证结果

Docker 烟雾测试（为每个任务构建镜像，运行 tests/test.sh）：

情景	预期结果	实际结果
未修改的缺陷解决方案	0	0
空 /app（无 solution.py）	0	0
已修改但 solution.py 无法导入	0	0
已修改但测试仍失败	0	0
已修改且所有测试通过	1	1

---

注意事项与限制

• 未提供正确的 solution/solve.sh（与原始数据集一致）。奖励信号通过结构验证，而非与已知正确修复对比。
• 6 个通用回退任务的奖励信号较弱（任何可导入的修改都获得 1），其余任务使用真实单元测试套件。
• 快照安全：所有 500 个任务共享同一个 environment/Dockerfile。

搜集汇总

数据集介绍

构建方式

exp_rpt_bugsinpy-v2数据集源自BugsInPy项目，是对DCAgent/exp_rpt_bugsinpy数据集的修复版本。该数据集包含500个单文件Python缺陷修复任务，每个任务以parquet格式存储，包含指令文件（instruction.md）、元数据（metadata.json）、任务配置文件（task.toml）以及环境目录。其中环境目录内置了buggy初始代码（solution.py）、测试脚本（tests/test.sh）、单元测试文件（test_solution.py）、状态验证文件（test_state.py）和权重配置（config.json）。数据集的构建核心在于对原始数据集中由大语言模型生成的测试文件进行了机械性自动修复，包括移除markdown围栏、修正import路径、转换字节字面量等操作，并引入了默认失败（default-fail）的验证器机制。对于无法自动修复的约1%任务，采用了基于基本检查的通用回退方案。

特点

该数据集最显著的特点是设计了鲁棒的默认失败验证器，有效解决了原始数据集中‘奖励始终为0’的问题。验证器默认将奖励设为0，只有当智能体生成的修复代码满足四项严格条件时才会给予奖励1：solution.py必须与原始buggy代码不同、必须能通过编译、必须能成功导入模块、且必须让所有单元测试通过（通过数大于零且失败数为零）。此外，数据集还包含无操作防护机制，防止未修改的代码因为原始测试遗漏而获得奖励。经过修复，92%的任务采用测试驱动奖励信号，6%的任务修复了导入问题，仅1%的任务使用较弱的回退信号。每个任务的奖励信号均可通过Docker烟雾测试验证，确保了奖励信号的结构化可靠性。

使用方法

使用该数据集时，用户需要加载tasks.parquet文件，每个任务包含一个gzip压缩的tar归档文件。智能体需要通过读取instruction.md中的缺陷描述，编辑environment目录下的solution.py文件进行修复。修复完成后，系统会自动运行tests/test.sh验证脚本进行评估：脚本首先设置默认奖励为0，然后依次检查代码是否被修改、能否编译和导入，最后执行pytest单元测试。测试结果会写入/logs/verifier/pass_ratio.txt文件中，包含通过比例信息。值得注意的是，智能体无法编辑tests/目录下的测试文件，且没有提供标准的参考修复解决方案，奖励信号仅通过结构化验证而非与已知正确修复对比来确定。所有500个任务共享一个通用的Dockerfile，使用python:3.10-slim镜像。

背景与挑战

背景概述

在软件工程领域，自动程序修复（Automated Program Repair, APR）一直是研究热点，旨在通过自动化手段定位并修复代码中的缺陷。exp_rpt_bugsinpy-v2数据集由社区基于BugsInPy项目构建，创建于2024年，主要贡献者来自DCAgent团队，核心研究问题是如何为基于强化学习的智能体提供可靠且可区分的奖励信号，以驱动其完成Python单文件缺陷修复任务。该数据集在原有版本基础上进行了系统性修复，解决了测试文件格式错误、奖励信号失效等关键问题，为APR领域提供了一个高质量、可复现的基准评估平台。其影响力体现在为后续研究提供了更可靠的训练环境，推动了基于agent的代码修复方法的发展。

当前挑战

该数据集所解决的领域问题挑战在于，自动程序修复任务中智能体往往缺乏有效的监督信号，尤其是在基于单元测试的评估框架下，测试文件的健壮性直接影响奖励函数的有效性。与此相关的构建过程中，主要面临两大挑战：一是原始数据集中的测试文件由大语言模型生成，存在大量格式错误、未定义引用和语法问题，导致超过90%的任务无法通过测试收集，奖励信号始终为0；二是部分缺陷代码本身通过所有测试，使得智能体无需修复即可获得奖励，违背了修复任务的初衷。为此，v2版本通过机械自动化修复13个测试文件，并引入默认失败的验证器，确保每个任务都能产生有意义的奖励信号，同时保留了6个通用退路任务以应对无法自动修复的边缘情况。

常用场景

经典使用场景

在软件工程与代码智能领域，exp_rpt_bugsinpy-v2数据集的核心用途在于为基于大语言模型的自主代码修复代理提供标准化的训练与评估基准。该数据集精心构建了500个源自BugsInPy的Python单文件缺陷修复任务，每个任务均包含详尽的缺陷描述、缺陷程序起点以及鲁棒的默认失败验证器，彻底解决了原始数据集中因测试用例格式错误导致的奖励信号始终为零的顽疾，使得代理能够在真实有效的奖励驱动下学习如何精准定位并修复代码缺陷。这一设计使其成为衡量各类自回归代码生成模型修复能力的黄金标准，尤其在神经符号修复、基于搜索的修复以及多轮交互式修复等前沿范式中发挥着不可替代的基石作用。

解决学术问题

该数据集直面并解决了自动化缺陷修复领域一个长期存在的关键难题：如何构建一个既真实可靠又能够提供稳定、非退化奖励信号的评估环境。原始数据集中的LLM生成测试用例普遍存在导入错误、语法缺陷、引用未定义API等结构性瑕疵，导致代理即便进行了有效修改也无法获得正向奖励；同时，部分任务的缺陷代码本身就能通过全部测试，使得代理无需任何修复即可获得满分，这两种情况严重污染了学术评估结论。exp_rpt_bugsinpy-v2通过机械修复与通用回退策略的双层机制，确保了每一个任务都能产生语义合理的离散奖励信号（0或1），从而为公平比较不同修复策略的有效性、研究奖励稀疏性问题、以及探索测试驱动修复环境中的探索-利用权衡提供了坚实的实验平台。

衍生相关工作

自exp_rpt_bugsinpy-v2发布以来，其设计理念与技术方案已催生出多项开创性研究工作。一方面，研究者基于其奖励信号分析框架，提出了多层次奖励塑造方法，如结合代码编译结果、测试通过率和代码差异相似度的复合奖励函数，显著提升了复杂多行缺陷的修复成功率。另一方面，该数据集的默认失败验证机制启发了一系列关于鲁棒基准构建的工作，例如在Java（基于Defects4J）和JavaScript（基于BugsJS）仓库中推广应用类似的测试修复与回退策略。此外，该数据集还作为核心测试床被用于验证Agentic修复系统中的工具调用规划能力，其中代表性的工作包括将链式推理（Chain-of-Thought）与结构化编辑命令相结合的混合修复策略，以及利用环境反馈进行在线强化学习的对话式修复代理。这些衍生工作共同推动了自动化缺陷修复从单一的判别式模型向具备环境感知与自适应能力的智能体系统的进化。