💻 computer science

Benchmarking Code Improvement with Progressive, Adaptive, and Interactive Feedback

本文介绍了 PAIR-Bench，这是一个渐进式且具有自适应性的基准测试，它通过衡量大型语言模型通过结构化、多层级反馈来优化程序的能力，而非仅仅依赖于二元的通过或失败结果，来评估其代码改进能力。

原作者： Cuong Chi Le, Aashish Yadavally, Minh Le-Anh, Tien N. Nguyen

发布于 2026-07-03

📖 1 分钟阅读☕ 轻松阅读

原作者： Cuong Chi Le, Aashish Yadavally, Minh Le-Anh, Tien N. Nguyen

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在教一个机器人如何修理一台坏掉的面包机。

旧方法（二元通过/失败制）：
过去，研究人员会给机器人一个坏掉的面包机和一份测试清单（例如：“它能烤面包吗？”、“它能弹起来吗？”）。如果机器人完美地修好了面包机，它会得到一颗金星。如果它哪怕只在一个测试中失败了，就会得到零分。

问题在于： 这就像是在给一个数学考试得了 99 分的学生打分，因为他漏掉了一个微小的细节，就直接给了他“不及格”。相反，一个靠运气猜对答案的学生也会得到“优秀”，即便他根本不理解为什么是对的。这种方法忽略了学习的过程，也忽略了机器人可能已经解决了 90% 的问题，只是在最后 10% 上卡住了这一事实。

新方法 (PAIR-BENCH)：
该论文的作者 Cuong Chi Le 及其同事创造了一种测试机器人（具体指大型语言模型或 LLM）的新方法，称为 PAIR-BENCH。与其仅仅看最终结果，他们还会观察机器人学习修复代码的整个过程。

把 PAIR-BENCH 想象成一个带有贴心教练的视频游戏，而不是一场最终考试。

它是如何工作的：两个“旋钮”

该系统使用一个“教练”（反馈模型）来引导“玩家”（尝试修复代码的机器人）。这个教练有两个特殊的旋钮来控制提示信息：

“在哪里”旋钮（故障区域控制）：
想象一下，坏掉的面包机有三个问题：一根烧焦的电线、一个卡住的弹簧和一个松动的插头。
- 旧方法： 教练可能会随机大喊：“坏了！”但并不说明哪里坏了。
- 新方法： 教练会先挑选一个特定的问题进行重点关注，比如“让我们来看看这根烧焦的电线”。一旦机器人修复了那个问题，教练才会转向下一个问题。这确保了机器人是在解决具体的问题，而不是在瞎猜。
“程度多少”旋钮（提示深度控制）：
这就像是调整对机器人的帮助程度，类似于老师辅导学生。
- 等级 1（症状）： “面包机在冒烟。”（非常模糊）。
- 等级 2 (模式)： “放入厚面包时会冒烟。”（稍好一些）。
- 等级 3 (状态)： “你没有追踪面包在里面停留了多久。”（接近答案了）。
- 等级 6 (方向)： “修改计时逻辑，使用秒数计数而不是循环。”（几乎就是答案了）。
- 神奇之处在于： 如果机器人仅凭等级 1 的提示就能解决问题，那它是个天才。如果它需要等级 6 的提示才能解决问题，说明它很吃力。系统会衡量机器人成功解决问题时到底需要多少帮助。

他们的发现

作者使用真实的编程问题，在几个顶尖的 AI 模型（如 DeepSeek、Gemini 和 GPT-4o-mini）上测试了这个新系统。以下是他们的发现，用简单的术语表达如下：

有些模型是“自主启动型”： 一个模型（DeepSeek）通常可以通过非常模糊的提示（等级 1 或 2）来解决问题。它不需要教练手把手地教导。
有些模型需要“手把手教导”： 其他模型最终虽然能解决问题，但它们需要非常具体、详细的指令（等级 5 或 6）。它们无法靠自己摸索出来。
稳定性很重要： 有些模型修复了代码的一部分，却不小心破坏了另一部分原本已经修好的代码。新系统捕捉到了这种“回归”（即倒退）现象，而旧的“通过/失败”系统却漏掉了这一点。
一致性： 当他们多次运行测试时，新系统给出了非常一致的结果。旧的方法就像掷骰子；有时模型因为得到了模糊的提示而走运，有时则因为运气不好而失败。新系统更加公平且稳定。

核心总结

该论文认为，我们不应该只问：“机器人修好代码了吗？”我们应该问：

“它需要多少帮助？”
“它是否在某一点上卡住了并忽略了其他部分？”
“它在修复问题的同时，有没有破坏原本正常工作的部分？”

通过衡量过程（轨迹）而非仅仅是终点（最终的通过/失败），PAIR-BENCH 为我们提供了一个更清晰、更公平的视角，去观察这些 AI 模型在改进代码方面的真实智能水平和能力。这就像是区分了“他通过了考试”与“他掌握了知识，在难点处需要一点点启发，并且没有忘记已学过的知识”。

技术摘要：通过渐进式、自适应与交互式反馈进行代码改进基准测试

1. 问题陈述

当前针对代码生成和自动化程序修复（APR）的大型语言模型（LLM）评估严重依赖于由测试套件决定的二元通过/失败指标。作者认为这种方法过于粗糙且具有误导性，原因如下：

信息稀疏性： 二元结果忽略了部分进展，将修复了一个边缘情况的方案与未能修复所有测试的方案视为同等对待。
性能虚高： 薄弱的测试套件可能允许模型通过进行浅层修改来通过测试，这些修改虽然修复了报告的失败，但引入了微妙的回归。
忽视精炼轨迹： 在模型根据反馈（编译器错误、执行追踪或诊断信息）进行迭代优化的工作流中，评估通常只考虑最终结果。这无法捕捉模型是否有效地利用了反馈、是否实现了修复的泛化，或是否维持了先前正确的行为。
受控反馈的可变性： 现有的交互式基准测试缺乏对所提供反馈的控制。反馈的信息量（例如，揭示根本原因还是仅提供模糊的症状）在不同运行之间可能存在巨大差异，从而难以区分模型能力与反馈质量。

本文认为，通过衡量模型通过反馈引导的精炼过程做出进展的能力，比衡量静态的通过/失败率能提供更细粒度且更真实的现实应用价值衡量。

2. 方法论：PAIR-BENCH

为了解决这些局限性，作者引入了 PAIR-BENCH，一个用于评估代码改进的渐进式且自适应的基准测试。其核心创新在于一个**渐进式提示（Progressive Hinting）**协议，该协议从两个维度控制反馈：

A. 核心组件

场景构建器（失败区域控制）：
- 将隐藏的失败测试用例根据“失败特征”分组为失败场景，该特征包括：
  - 参考执行追踪（被执行的源代码行）。
  - 预期输出形态（结构形式）。
  - 候选失败类型（例如，超时、错误值）。
- 这类分组了相关的错误行为，使基准测试能够针对失败空间的特定区域，而非任意的测试用例。
提示生成器（提示深度控制）：
- 受项目反应理论（IRT）和教育支架理论的启发，提示按六个级别生成，信息量递增：
  - L1（症状）： 仅显示观察到的错误行为。
  - L2（输入模式）： 暴露失败的输入条件。
  - L3（状态追踪）： 方案未能保留的缺失状态或逻辑。
  - L4（故障位置）： 可疑的代码区域。
  - L5（概念修正）： 缺失的不变量或推理。
  - L6（修复方向）： 不含代码的具体实现指导。
- 一个反馈模型（独立于候选模型）生成受限于这些级别的提示，以防止信息泄露。
自适应策略：
- 渐进式： 基准测试遍历不同的失败场景，优先处理覆盖失败测试数量最高的场景。
- 自适应： 提示深度根据模型的表现进行调整。如果模型使用浅层提示修复了场景，则下一个场景将从较弱的提示开始（褪去辅助）。如果模型失败，则增加提示深度（升级引导）。
轨迹评估器：
- 基准测试不使用单一的二元分数，而是追踪跨回合的修复轨迹，在每一步都测量进展。

B. 评估指标

本文提出了一个以进展为中心的指标套件：

初始修复率： 无辅助下的修复能力。
目标修复成功率 (TRS)： 修复由提示所描述的特定场景的能力。
更广泛的修复增益 (BRG)： 将修复推广到其他未经提示的失败情况的能力。
行为保持 (BP)： 避免在先前通过的测试中引入回归的能力。
进展单调性率 (PMR)： 跨回合中非递减通过率出现的频率。
提示效率 (HE)： 关闭一个场景所需的提示级别（较低的级别表示更强的诊断能力）。
差距闭合： 剩余修复机会中被关闭的比例。
修复回合数： 成功修复实例中的收敛速度。

3. 实证评估

作者使用源自 Codeforces Python 提交（具体为“错误答案/Wrong Answer”判决）的 440 个代码改进实例实例化了 PAIR-BENCH。他们使用受控反馈模型（GPT-OSS 120B）评估了八种最先进的 LLM（包括 DeepSeek V3.2、Gemini 2.5 Flash Lite、Qwen3、GPT-4o-mini、Llama 3.3 等）。

主要发现

模型区分度： 二元指标往往无法有效区分模型。PAIR-BENCH 揭示了模型利用反馈方式的显著差异。DeepSeek V3.2 脱颖而出，在大多数指标中排名第一，包括高初始修复率、目标修复成功率和提示效率。
反馈效用： 模型显著受益于受控提示。例如，Gemini 2.5 Flash Lite 的最终修复率从 ~78%（无提示多轮对话）提高到 ~95%（受控反馈），证明其收益是由与修复相关的提示驱动的，而非仅仅是重复提示。
诊断型 vs 依赖型修复： 更强的模型（如 DeepSeek）通常使用浅层提示（L1–L2）解决场景，表明其具备强大的诊断能力。较弱的模型则需要更深的提示（L5–L6）或无法解决场景，凸显了其对显式引导的依赖。
稳定性： 与“原生（Vanilla）”反馈（不受控）相比，受控反馈产生了显著更稳定的评估结果。使用受控协议时，修复率和最终修复率的标准差降低了约 78–84%，且排名稳定性（Kendall's $\tau$ ）从 0.905 提高到 0.982。
权衡： 高提示效率（需要较少帮助）并不总是与高最终修复率或稳定性相关。例如，Qwen 展示了较强的保持能力和单调性，但与 Gemini 相比，其收敛所需的回合数更多。

4. 核心贡献

PAIR-BENCH： 一种新的用于评估代码改进的渐进式且自适应的基准测试范式，提供数据与代码。
以进展为中心的指标： 一套旨在衡量超越最终正确性的交互式代码改进的指标，捕捉了轨迹、稳定性和泛化性。
受控交互式反馈协议： 引入了渐进式提示，这是一个通过（通过场景分组）控制失败区域和（通过 6 级量表）控制提示深度的结构化协议，旨在将反馈难度与模型能力进行校准。
实证研究： 对多种 SOTA LLM 进行了全面评估，证明了模型的排名和能力会根据所测量的代码改进维度的不同而发生显著变化。

5. 意义与主张

本文声称，PAIR-BENCH 通过超越稀疏的二元结果，提供了对 LLM 代码改进能力的更真实评估。其意义在于：

揭示隐藏能力： 它区分了那些仅通过浅层编辑实现“通过”的模型，以及那些展示出真正的诊断推理和稳定精炼能力的模型。
标准化反馈： 通过控制失败区域和提示深度，它消除了非结构化反馈的可变性，从而实现了更公平的模型推理能力比较。
捕捉精炼轨迹： 它承认代码改进是一个迭代过程，不仅测量终点（最终通过），还测量路径（进展、稳定性与效率）。

作者总结道，有效的交互式修复取决于多个维度——最终正确性、目标修复、渐进式改进、稳定性以及提示效率——并且 PAIR-BENCH 对于全面评估这些维度是必要的。未来的工作包括将自适应过程扩展到问题层面（改变问题难度）。