Precise Debugging Benchmark: Is Your Model Debugging or Regenerating?¶
会议: NeurIPS 2026
arXiv: 2604.17338
OpenReview: https://openreview.net/forum?id=qBuOrD12Mv
领域: 代码智能
关键词: 代码调试, 代码智能, 故障定位, 评测基准, 大语言模型
一句话总结¶
针对前沿大语言模型在代码调试中常通过大范围重写（Regeneration）而非精准定位修复通过测试的假象，本文提出与数据集无关的精确调试评测框架 PDB，基于原子化可验证缺陷与合成多缺陷程序，引入代码行级精确率与缺陷级召回率评估真实的精准调试能力。
研究背景与动机¶
近年来，大语言模型在代码生成领域取得了突破性进展，能够依据自然语言描述从零构建出复杂的算法甚至翻译完整代码库。然而在真实的软件工程生命周期中，开发人员绝大部分的时间与成本并非消耗在白手起家写全新代码，而是花费在已有系统的调试、维护与缺陷修复上。当现有前沿大模型被应用于代码调试任务时，它们往往习惯于退回自身最擅长的“代码重新生成”模式，即遇到缺陷代码时直接对整段函数或周边代码块进行推倒重写。这种粗暴的重写策略虽然常常能够侥幸通过单元测试，但在现实工程场景中却极具风险且难以进行代码审查，甚至会破坏原有的架构约束并引入隐蔽回归。
导致这一行为长期未被深入揭示的核心矛盾在于：现有的自动化代码调试基准普遍仅依赖“单元测试通过率（Unit-Test Pass Rate）”这一粗粒度的二元指标来评判修复成败。在仅看测试是否通过的机制下，模型无论进行极简的针对性修补，还是全盘重写，甚至对测试用例进行硬编码作弊，都会获得完全相同的满分奖励；同时，在包含多个缺陷的复杂程序中，若模型正确修复了部分缺陷但未完全修复所有问题，测试同样判定为 0 分，抹杀了模型的渐进修复进展。此外，现有调试基准大多直接爬取自 GitHub Issues 或 Stack Overflow 等公开数据源，面临严重的训练集污染风险，难以客观反映模型真实的故障定位与精准修改能力。
为了打破对粗粒度单元测试通过率的盲目依赖，亟需一套能够解耦“代码生成能力”与“真实调试能力”的评测基础设施。核心 idea：构建与数据集无关的精准调试评测框架 PDB，先利用 LLM 合成并通过单元测试验证原子化缺陷，再在保持缺陷独立性约束下组合生成多缺陷程序，并引入代码行级精确率（Edit-level Precision）与缺陷级召回率（Bug-level Recall）来严密惩罚过度重写并量化精准调试能力。
方法详解¶
整体框架¶
PDB（Precise Debugging Benchmark）采用端到端的解耦流水线，能够将任意已有的代码生成或竞赛数据集即插即用转化为精准调试评测集。整个系统包含两大核心阶段：一是可控缺陷程序生成（PDB Generation），通过 LLM 在正交缺陷分类（ODC）指导下注入原子缺陷并组合成多缺陷场景；二是精准修改评测（PDB Evaluation），让待测调试系统对缺陷程序进行修复，并通过双重测试规约将预测修改对齐到真实缺陷，分别计算编辑级精确率与缺陷级召回率。
%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
A["输入数据源<br/>任务描述 x + 正确程序 Cgt"] --> B["原子化缺陷合成与验证<br/>ODC五大类分类提示 + 单元测试过滤"]
B --> C["多缺陷独立性组合<br/>步幅约束 s ≥ 3 避免耦合交互"]
C --> D["测试集筛选与难度过滤<br/>PDB-Single 与 PDB-Wild 基准构建"]
D --> E["待评测模型生成修复补丁<br/>单一/迭代/智能体调试策略"]
E --> F["双重规约语义对齐<br/>两阶段 map 匹配 + 块置换单元测试"]
F --> G["冗余消除与核心修改提取<br/>子块枚举搜索 essential 机制"]
G --> H["精确调试指标输出<br/>Precision_ε 与 Recall 计算"]关键设计¶
1. 正交原子化缺陷合成与步幅组合：确保缺陷可解耦与独立可测 为了系统性覆盖真实软件缺陷且便于精准对齐，PDB 依据正交缺陷分类法（ODC）划分出五大纯代码级缺陷大类（Assignment、Checking、Algorithm、Build/Package/Merge、Timing/Serialization）共 23 个细分子类，由大模型引导针对单行或连续代码块执行插入、删除或替换修改。所有生成的候选题均经过前置过滤与执行验证：只有完整缺陷程序无法通过单元测试，且在多行缺陷中任意严格子集回退补丁依然无法通过测试时，才被认定为真正的“原子缺陷”。在构建多缺陷程序时，系统随机抽取 \(k\) 个原子缺陷，并强制执行行步长（Stride）约束 \(s\)（单行缺陷 \(s \ge 3\)，多行缺陷 \(s \ge 5\)），确保各缺陷之间不发生逻辑耦合交互，从构造层面保障了缺陷可独立修复的假设。
2. 基于测试用例置换的两阶段语义匹配：解决非一一对应对齐难题 由于模型修复时所采用的补丁在语法或位置上可能与标准修复存在微小差异，直接使用基于 diff 的字符串比对会严重误判。为此，PDB 提出了两阶段映射函数 \(\operatorname{map}\)：第一阶段（Pass 1）优先匹配行号与内容完全相同的精确块（Exact Match）；第二阶段（Pass 2）对未匹配块逐步放宽条件，依次检查是否包裹标准缺陷起始行（Wrap Match）、局部上下文是否重合（Near Match）以及编辑内容是否完全相同但位置偏移（Distant-but-identical Match）。对每一个匹配候选，PDB 构造伪程序 \(\hat{C}_i\)，即仅将第 \(i\) 个缺陷的标注修改替换为模型预测修改，而其余缺陷均应用标准正确修复，通过单元测试 \(F_{\mathcal{U}}(\hat{C}_i)=1\) 判定该部分修改在语义上是否成功修复了第 \(i\) 个缺陷。
3. 容差松弛与冗余消除搜索：精确惩罚重写而不苛求唯一写法 为了避免对具有合理防御性代码（如防御性断言）或轻微代码风格改动进行过度严苛的惩罚，PDB 引入了容差参数 \(\epsilon\)（在单行基准中取 \(\epsilon=2\)，多行基准中取 \(\epsilon=1\)），并设计了 \(\operatorname{essential}_{\mathcal{U}}\) 过程。该过程在语义正确的模型修改子块中枚举更小的连续子片段并运行单元测试，寻找能够独立通过测试的最短必要修改长度。最终将 \(\epsilon\)-松弛编辑级精确率与缺陷级召回率形式化定义为： $$ \text{precision}\epsilon = \frac{1}{|\hat{E}|} \sum}^k F_{\mathcal{U}}(\hat{Ci) \cdot \min(|\operatorname{essential}(E_i))|, |E_i| + \epsilon) $$ $$ \text{recall} = \frac{1}{k} \sum_{i=1}^k F_{\mathcal{U}}(\hat{C}_i) $$ 其中 }}(\operatorname{map\(|\hat{E}|\) 为模型输出修改的总行数，\(k\) 为程序中注入的缺陷总数。当模型大范围重写代码时，\(|\hat{E}|\) 迅速膨胀，精确率将受到惩罚骤降至接近于 0，从而定量揭示出重写作弊行为。
损失函数 / 训练策略¶
本文作为评测基准与实证分析工作，不直接包含模型端到端训练的损失函数设计。所有受测模型均在零样本或少样本提示下运行，涵盖极简修改提示（Minimal Debugging Prompt）与自由生成提示（Freeform Debugging Prompt）。对于带反馈的循环机制，设置了最多 3 轮尝试的迭代调试（Iterative Debugging）以及提供详细测试报错堆栈信息的智能体调试（Agentic Debugging）流程。
实验关键数据¶
主实验¶
论文基于 BigCodeBench、LiveCodeBench 和 SWE-smith 构建了包含 5,751 个单行单/多缺陷样本的 PDB-Single，以及包含 484 个多行/跨文件仓库级样本的 PDB-Wild。在 PDB-Single 上，各主流前沿模型的表现展现出单元测试与精准指标之间的强烈脱节：
| 模型 | Precision (%) | Recall (%) | Unit-Test Pass Rate (%) | 模型行为分类 |
|---|---|---|---|---|
| Claude-Sonnet-4.5 | 71.8 ± 0.9 | 81.4 ± 0.8 | 75.7 ± 1.1 | 高精准且高通过率 (Pass with precision) |
| Gemini-2.5-Pro | 71.4 ± 0.9 | 83.5 ± 0.7 | 78.1 ± 1.0 | 高精准且高通过率 (Pass with precision) |
| Qwen3-Coder-480B | 65.8 ± 0.9 | 77.2 ± 0.9 | 70.3 ± 1.2 | 测试略弱但定位精准 (Weak but precise) |
| Kimi-K2-Instruct | 56.6 ± 1.0 | 72.7 ± 0.9 | 64.8 ± 1.2 | 能定位但修复不精确 (Weak & imprecise) |
| Grok-Code-Fast | 54.6 ± 1.0 | 66.5 ± 1.0 | 58.3 ± 1.3 | 能定位但修复不精确 (Weak & imprecise) |
| Kimi-K2-Thinking | 51.7 ± 0.9 | 75.6 ± 0.9 | 74.0 ± 1.1 | 思考模型倾向过度重写 (Imprecise reasoning) |
| DeepSeek-V3.2 | 48.4 ± 1.0 | 70.0 ± 1.0 | 71.4 ± 1.2 | 重度依赖重新生成 (Pass-oriented) |
| DeepSeek-V3.2-Thinking | 45.0 ± 0.9 | 71.2 ± 1.0 | 79.0 ± 1.0 | 通过率最高但精确率倒数 (Pass-oriented) |
| GPT-5.1-Codex | 39.7 ± 0.8 | 71.7 ± 0.9 | 76.1 ± 1.1 | 典型推倒重写模型 (Pass-oriented) |
在更高难度的多行与仓库级基准 PDB-Wild（\(\epsilon=1\)）上，上述现象依然显著存在：
| 模型 | Precision (%) | Recall (%) | Unit-Test Pass Rate (%) |
|---|---|---|---|
| Claude-Opus-4.7 | 77.8 | 83.4 | 75.8 |
| Gemini-3.1-Pro-Preview | 77.8 | 85.6 | 85.1 |
| Claude-Sonnet-4.5 | 68.7 | 77.8 | 69.2 |
| GPT-5.5 | 60.9 | 83.0 | 84.3 |
| Gemini-2.5-Pro | 58.3 | 70.5 | 68.8 |
| Qwen3.6-plus | 50.5 | 62.7 | 65.3 |
| Kimi-K2.6 | 45.7 | 62.3 | 43.4 |
| GPT-5.1-Codex | 37.1 | 59.1 | 68.6 |
消融实验¶
在 PDB-Single 的 BigCodeBench 子集 500 个样本上，分析提示词约束、数据重写对齐及跨模型生成的影响：
| 评估配置 | Precision (%) | Recall (%) | Unit-Test Pass Rate (%) | 核心说明 |
|---|---|---|---|---|
| 原始提示词（极简修复约束） | 73.0 | 83.1 | 76.2 | 基础基准配置 |
| 自由生成提示词（Freeform） | < 45.0 (均值) | 显著下降 | 保持或略升 | 撤销约束后模型精确率崩塌，GPT-5.1-Codex 精确率跌破 20% |
| 重写参考解（同生成模型） | 76.5 | 86.6 | 76.4 | 排除记忆化污染，精确率提升 3.5% |
| 重写参考解（跨模型生成） | 75.8 | 86.8 | 74.8 | 跨模型风格增加调试难度，通过率下降 1.4% |
| 交互式迭代调试（3轮尝试） | 下降或持平 | 提升 3-5% | 提升 4-7% | 多轮迭代仅靠扩大改动面积提升通过率，无法提高精度 |
| 智能体调试（提供测试反馈） | 进一步恶化 (~50%) | 提升 4-6% | 提升 5-8% | 报错反馈诱发更激进的推倒重写，而非聚焦最小修复 |
关键发现¶
- 排名严重倒置：仅看传统单元测试通过率，DeepSeek-V3.2-Thinking 与 GPT-5.1-Codex 名列前茅（>76%），但在编辑级精确率上却垫底（<45%），暴露出严重依赖全函数重新生成来应付测试的缺陷；相比之下，Qwen3-Coder-480B 测试率略低（70.3%），却具有高达 65.8% 的高精确率。
- 智能体与反馈反噬精准度：在带有执行反馈与错误跟踪的 Agentic 调试设置下，即使是成熟的 Claude-Code 系统，精准度也仅达到约 50%。模型将测试报错仅仅当作“重新写一遍”的粗粒度触发器，而非指导定位错误行进行精准修补的线索。
- 缺陷数量与精确率负相关：随着程序中注入的缺陷数 \(k\) 从 1 增加至 4，由于模型为了修好多个地方而更倾向于肆意改动代码，过度修改显著增加，精确率出现单调下降。
亮点与洞察¶
- 尖锐指出现有评测盲区：敏锐地抓住了大模型在代码调试中“以生成代修补”的偷懒欺骗行为，有力证明了单元测试高通过率并不等同于具有真实的软件维护与故障定位能力。
- 巧妙的语义替换验证机制：通过在保持其他缺陷标准修复的前提下单独置换单缺陷预测补丁（\(\hat{C}_i\)），在不依赖昂贵人工标注的情况下，用纯程序执行的方法精准裁决了每一个独立缺陷的局部修复成功率。
- 对后训练（Post-Training）的深刻启示：当前的强化学习（RLVR）与 SFT 流程过度奖励最终输出能否跑通测试用例，诱导模型形成了“大动干戈全重写”的捷径学习偏置。PDB 提出的精确度指标完全可转化为更健康的密集奖励函数，用于指导代码模型的偏好对齐。
局限与展望¶
- 语言生态目前以 Python 为主：虽然 ODC 分类法和两阶段评估算法本身具备语言无关性，但当前发布的数据生成规则和 AST 解析逻辑主要聚焦于 Python 生态，拓展至 C++、Rust 等系统级强类型语言仍需适配。
- 单参考基准下的召回率遗漏：部分复杂缺陷天然存在多种截然不同的极简修复路径，在单一参考实现下，模型采取替代性的正确极简修法可能无法被语义对齐算法捕获，未来可引入多参考标注或 LLM-as-a-judge 进行语义等价判定。
- 未包含训练阶段闭环验证：本文定位于基准设立与实证分析，尚未在闭环中直接利用 PDB 生成的偏好数据或精准奖励进行强化学习训练，需在后续工作中探索是否能有效矫正模型的重写偏置。
相关工作与启发¶
- vs SWE-bench / Defects4J: 传统基准直接采集真实 Issue 和 Commit，高度依赖真实环境的单元测试通过作为单一指标，不仅存在严重数据泄露风险，而且对部分修复和过度重写毫无鉴别力；PDB 实现了缺陷解耦、可控注入与精准度量化。
- vs CodeEditorBench / DebugBench: 既有工作多为单行简单变异算子注入（如操作符替换），难以产生高层次的算法与环境级复杂 Bug；PDB 依托 ODC 分类法合成语义连贯的原子缺陷，并首次提出了兼顾容差与冗余消除的精确率/召回率体系。
评分¶
- 新颖性: ⭐⭐⭐⭐⭐ 首次系统性揭露了大模型在代码调试中“以重写代修复”的普遍假象，并设计出严密的解耦度量指标。
- 实验充分度: ⭐⭐⭐⭐⭐ 涵盖 9 款主流模型、从单行到仓库级多行跨文件场景，消融实验深入排查了记忆污染与提示策略影响。
- 写作质量: ⭐⭐⭐⭐⭐ 逻辑层层推进，形式化定义清晰严谨，正交分类与算法流程完备。
- 价值: ⭐⭐⭐⭐⭐ 极具现实软件工程指导意义，为下一代代码大模型的评测与对齐训练指明了关键缺陷。