patchbench

PatchBench是一个多语言基准测试数据集，专为评估大语言模型（LLM）修复代码缺陷的能力而设计，要求模型生成的补丁既能修复原有bug，又不引入新的错误。数据集包含约1500至2000个样本，每个样本均由一个真实的issue报告和约500至1500行的大型代码上下文组成。样本覆盖Python、JavaScript、TypeScript、Go、Java和Rust六种编程语言，来源包括真实世界中的bug修复合并请求（PR）以及通过自动化工具注入的合成bug。每个样本的字段包括唯一标识、语言、来源（real或synthetic）、原始数据集、GitHub仓库、buggy状态的基准提交、issue文本、上下文文件列表（包含路径和内容）、预期需要修改的文件路径、测试文件列表、测试命令、环境设置命令、预修复时必须失败且修复后必须通过的测试列表、修复后必须保持通过的测试列表（即回归检查），以及作为参考的标准补丁。数据集采用严格的验证合同：确保预修复时所有fail_to_pass测试失败且所有pass_to_pass测试通过；应用标准补丁后所有测试通过；每个检查运行两次以排除不稳定测试；并验证issue文本不直接泄露需要修改的函数或行。模型的修复结果评分标准为：若所有fail_to_pass测试通过且所有pass_to_pass测试仍然通过，则视为解决。数据集还记录每个测试的详细结果，便于分析部分修复行为（例如修复成功但破坏了其他功能）。PatchBench的上下文扩展是独创贡献，通过生成仓库在基准提交下的状态，计算失败测试的依赖闭包，并切片模块以确保行数在500-1500行范围内。测试框架采用语言原生运行器，无需Docker，支持缓存加速。数据集适用于代码修复、自动化调试、LLM代码生成等任务的评估。

原始信息汇总

PatchBench 数据集概述

简介

PatchBench 是一个多语言基准测试，用于评估 LLM 能否正确地修复 bug 且不引入新 bug。每一行数据包含一份真实 issue 报告以及大段代码上下文（约 500–1500 行）；被测模型生成一个补丁，随后逐行测试套件检查：(a) 之前失败的测试现在通过，(b) 其余测试套件保持绿色。

状态：v0 规范。数据行正在构建中。

数据行结构（Row schema）

字段	类型	是否在 tasks 配置中	描述
id	string	✅	patchbench-{lang}-{source}-{nnnn}
language	string	✅	python
source	string	✅	real（挖掘的 bug 修复 PR）
origin	string	✅	来源数据集，例如 swe-bench-live-multilang、swesmith-go
repo	string	✅	代码来源的 GitHub 仓库
base_commit	string	✅	buggy 状态所取自的 commit
issue_text	string	✅	模型必须据此诊断的 issue/PR 报告
context_files	{path, content} 列表	✅	总计约 500–1500 行，含 buggy 文件、调用方及相关模块
buggy_files	string 列表	✅	预期修复会触及的路径
test_files	{path, content} 列表	✅	以文件形式物化的测试补丁
test_cmds	string 列表	✅	运行该行测试的命令（语言原生）
env_setup_cmds	string 列表	❌（仅 harness）	test_cmds 之前所需的安装/构建命令
fail_to_pass	string 列表	❌	修复前必须失败、修复后必须通过的测试
pass_to_pass	string 列表	❌	修复后必须保持通过的测试（回归检查）
gold_patch	string	❌	参考修复，仅用于 harness/自评估

配置划分（防泄漏）

两个配置用于防止泄漏：

• tasks（公开评估面）：agent 可见的一切——issue、上下文、测试。
• gold（仅 harness）：fail_to_pass、pass_to_pass、gold_patch、env_setup_cmds。

验证契约（每个发布的数据行）

1. 修复前： 在 base_commit 将 test_files 应用到仓库 → 每个 fail_to_pass 测试失败；每个 pass_to_pass 测试通过。
2. 修复后： 应用 gold_patch → 每个 fail_to_pass 和 pass_to_pass 测试通过。
3. 确定性： 每项检查运行两次；任何存在不稳定测试的数据行被丢弃。
4. 无泄漏检查： issue 文本不得点名要修改的具体函数/行（自动筛查 + 人工抽查）。

评分方式

模型修复被评为 resolved 当且仅当所有 fail_to_pass 通过且所有 pass_to_pass 仍然通过。数据行还记录逐测试结果，因此可看到部分行为（修复有效但破坏了某些东西）——这就是“引入新 bug”的信号。

来源计划（目标约 1,500–2,000 行）

语言	真实来源	合成补充	目标
Python	SWE-Gym + SWE-bench Verified/train	SWE-smith-py	~550
Rust	SWE-bench-Live rust + rustbench	SWE-smith-rs	~300
Java	SWE-bench-Live java + Multi-SWE-bench java	SWE-smith-java	~300
Go	SWE-bench-Live go + Multi-SWE-bench go	SWE-smith-go	~250
JS/TS	SWE-bench-Live js+ts + Multi-SWE-bench	SWE-smith-js/ts	~400

上下文扩展是 PatchBench 自身的贡献：没有任何上游数据集提供切片好的 500–1500 行窗口。方法是在 base_commit 物化仓库，计算失败测试的依赖闭包，并对闭包内的模块进行切片，过滤掉闭包超出窗口的数据行。

Harness

语言原生 runner（无需 Docker，改编自 SWE-bench 评分循环 + microsoft/RepoLaunch 的各语言构建/测试配方）：在 base_commit clone → env_setup_cmds → 应用 test_files（+ 候选补丁）→ 运行 test_cmds → 解析逐测试结果 → 依据 F2P/P2P 评分。按仓库的环境缓存使验证可行。

许可证审计

上游数据集许可证：SWE-bench-Live（MIT）、SWE-Gym（MIT）、SWE-smith（MIT）。Multi-SWE-bench / PrimeIntellect 行采用 CC0/“other”（ByteDance 社区条款）——这些行在纳入前会从原始宽松许可的仓库重新验证，否则排除。

搜集汇总

数据集介绍

构建方式

在代码智能与自动化程序修复研究领域，构建兼具真实性与可控性的评测基准是推动大模型能力边界的关键。PatchBench以真实缺陷修复拉取请求与合成注入缺陷为双源，采集Python、JavaScript、TypeScript、Go、Java、Rust六种语言的缺陷报告及对应修复补丁；通过检出基准提交处的代码仓库、计算失败测试的依赖闭包并切分500至1500行上下文窗口，再经预修复与后修复双重验证、确定性重复运行及无泄漏自动筛查，最终形成约1500至2000条可复现的评测行。

特点

该数据集的核心特质在于其多维度的严谨性：每条样本均附带真实问题报告与大跨度代码上下文，要求模型在诊断缺陷的同时避免引入新错误；归入tasks与gold的双配置设计将评测面与答案面严格隔离，从机制上杜绝信息泄漏；而fail_to_pass与pass_to_pass两组测试列表则分别承载了缺陷修复与回归检查的双重信号，使部分修复或引入新缺陷的情形得以显式暴露，为评估模型的鲁棒性提供了细粒度依据。

使用方法

使用PatchBench时，评测者从tasks配置中读取问题描述、代码上下文与测试信息，驱动被测模型生成候选补丁；随后在基准提交处克隆代码仓库，依次执行环境配置与测试命令，并将候选补丁与测试补丁一并应用，通过解析逐条测试结果与fail_to_pass及pass_to_pass清单比对，判定该补丁是否完全修复缺陷且未破坏既有功能。语言原生运行器与逐仓库环境缓存保障了验证流程的可操作性与执行效率。

背景与挑战

背景概述

随着大语言模型在代码生成领域的深入应用，自动修复软件缺陷成为评估其真实工程能力的关键试金石。PatchBench诞生于这一学术前沿，由研究社区基于SWE-bench等既有基准的局限而构建，旨在系统评估模型能否在真实多语言代码库中正确修复缺陷且不引发回归。该基准汇聚Python、JavaScript、TypeScript、Go、Java和Rust六种语言，从真实缺陷修复PR与合成注入缺陷中采集约1500至2000条任务，要求模型基于问题报告与500至1500行代码上下文生成补丁，通过逐项测试验证修复与回归双重目标。其核心研究问题在于弥补现有基准对回归检测与多语言覆盖的不足，对推动可信赖的自动化程序修复研究具有重要影响力。

当前挑战

PatchBench所应对的领域问题超越了传统缺陷定位与修复的单一目标，其核心挑战在于同时确保修复正确性与无回归性，即模型必须在使失败测试转为通过的同时，保持原有用例全部通过，这对模型的全局代码理解与副作用控制提出了严苛要求。构建过程中，挑战同样多维：跨六种语言的构建与测试环境配置极为复杂，需为每行任务提供语言原生执行命令与依赖安装流程；代码上下文需从仓库中精准切片，依赖闭包的提取与窗口裁剪须兼顾信息完整性与规模约束；合成缺陷的注入须保证语义合理且测试可判别；此外，防止数据泄漏、过滤不稳定测试、审计上游许可证，均需在自动化流程与人工复核之间取得平衡。

常用场景

经典使用场景

在软件工程自动化与智能编程辅助领域，PatchBench 构筑了一个多语言缺陷修复的基准测试平台，其核心使用场景在于系统性评估大语言模型能否针对真实或合成缺陷报告生成正确补丁，且不引入新的回归错误。每一行数据呈现一份真实缺陷报告与约500至1500行的代码上下文，模型据此产生补丁，随后由逐行测试套件进行双重验证：既确认既往失败测试转为通过，亦确保其余测试维持绿色。此种设计精妙地模拟了现实开发中修复缺陷的复杂语境，涵盖了缺陷定位、上下文理解与补丁生成的完整链条，成为衡量代码智能体综合能力的试金石。

解决学术问题

该数据集直面学术研究中长期存在的几项关键难题：其一，如何量化评估模型修复缺陷时对代码库整体稳定性的影响，避免“修复一处、破坏多处”的困境；其二，如何构建跨语言、跨项目的统一评测框架，以克服单一语言基准的局限性；其三，如何防止数据泄漏，确保评测结果真实反映模型的泛化能力。PatchBench 通过引入“失败转通过”与“通过保持通过”的双重验证契约，以及严格的确定性与无泄漏筛查，为缺陷修复研究提供了可复现、可比较的学术标尺，推动了代码大模型在正确性与鲁棒性维度上的深入探索。

衍生相关工作

PatchBench 的构建汲取了SWE-bench、SWE-Gym、SWE-smith、Multi-SWE-bench及SWE-bench-Live等先驱数据集的精华，并在此基础上作出了独创性贡献：其一是上下文扩展策略，通过计算失败测试依赖闭包并切分500至1500行的模块窗口，弥补了上游数据集缺乏精细化代码切片的空白；其二是多语言合成与真实缺陷的融合 sourcing 方案，覆盖六种语言并设定约1500至2000行的目标规模。这些衍生工作不仅丰富了缺陷修复基准的生态，也为后续研究如跨语言迁移学习、补丁正确性形式化验证以及回归感知的模型训练提供了坚实的数据基石与方法论启示。