内置 FAIL TO PASS 测试能衡量正确补丁的运行性能吗？

正确性测试不衡量运行开销

SWE-bench 这类仓库级问题解决基准主要看提交的补丁能否通过正确性测试，尤其是 FAIL TO PASS（F2P）测试。F2P 测试在未修复的仓库上失败，只有在修复之后才通过，因此它编码的正是修复应当改变的行为。基准并不要求补丁采用开发者原本的实现，这意味着多个确实不同的补丁可以同时通过同一组 F2P 测试，却在执行开销上相差很大。

这一缺口正是论文的出发点。通过测试并不能说明补丁运行得是否高效，而基准本身也没有提供性能工作负载。为每个实例单独设计工作负载成本很高，因此作者提出一个问题：每个实例中已有的 F2P 测试，能否被改用作一种免费的性能工作负载。

F2P 测试可作为近似工作负载

支持复用的理由是，F2P 测试恰好执行了修复所触及的代码路径。在插桩条件下反复运行它，就能为每个补丁得到执行指标，而无需额外产物。作者也指出一个前提：F2P 测试通常把数据准备、对被测行为的调用以及断言放在同一个函数体里，其中只有调用部分对补丁敏感。如果数据准备和断言对每个解法的开销相同，它们就会把所有解法的开销整体平移同样的量，从而稀释测得的差异，但不会偏向任何一个补丁。

运行间的噪声靠重复执行来消解，而不是依赖单次读数。论文指出，当差异在统计上显著时，各解法之间的排序仍然可信；噪声只会干扰开销彼此接近的解法。PASS TO PASS 回归测试套件被有意排除：这些测试数量远多于 F2P 测试，大多不执行被修复的代码路径，纳入它们会成倍增加成本，却对性能分析帮助很小。

筛选把基准缩小到可测量案例

并非每个实例都支持这种测量。作者设定了三项约束：F2P 字段必须只包含一个测试，这样每个实例只产生一个可比较的读数；该测试必须能在同一进程内反复执行，以抑制噪声；它必须不含输入输出操作，因为这类操作的波动会淹没测量所依赖的 CPU 层面信号。第一项约束用一条静态规则处理，后两项用动态探测处理，最终保留 339 个实例。

四个前沿模型——Claude Opus 5、GPT 5.6、DeepSeek V4 Pro 和 Qwen 3.8 Max——与 SWE-agent 配合，求解来自 SWE-bench 和 SWE-bench-Live 已验证划分的这份筛选后语料。合并之后，有 262 个案例包含至少两个确实不同的正确解法，其中包括开发者的标准答案补丁。每个解法都在原生 F2P 测试上按指令数和实际耗时（wall-clock time）测量。

Welch ANOVA 区分真实差距与噪声

测量在每个实例的 Docker 环境中分两层循环进行。内层循环在同一进程内把 F2P 测试函数重复 N 次，把信号抬升到噪声水平之上；N 按案例校准，使最快的解法耗时落在 4 到 8 秒之间。校准后的 N 在整个语料上平均为每案例 6.8×10^5 次调用，中位数为 1.6×10^4。外层循环把整个过程重复 G = 5 次，作为相互独立的重复实验，每次都在新进程中运行，这五次测量构成案例层面的样本。

在统计方法上，作者用 Welch ANOVA 取代此前工作使用的相对标准差（RSD），因为前者同时考虑解法之间和解法内部的变异。这是论文自述的方法贡献：一个能标出正确补丁之间真实运行差异的判据，而不是把普通波动当成信号。结果是，最多 42% 的案例中，不同的正确补丁之间存在统计上可区分的差异。

解决率与运行性能给出不同排序

核心比较针对这四个模型。在四个模型共同解决的 211 个案例子集上，相对标准答案的加速比按各案例比值的几何平均聚合，数值低于 1 表示模型补丁更快。GPT 和 DeepSeek 领先，Claude 落后于两者但仍快于标准答案，Qwen 整体上比标准答案更慢。运行性能排序大致为 GPT ≈ DeepSeek > Claude ≫ Qwen。

这一排序与解决率排序相差很远，论文报告的解决率排序为 Claude ≫ Qwen > GPT ≈ DeepSeek。两个维度几乎相反。作者据此认为，仅凭解决率不足以刻画模型在仓库级问题解决上的能力。在两种指标下，模型排序在全集和可区分子集之间都保持一致，而且差距在可区分子集上进一步拉大，作者把这视为可区分子集可以代表全语料的证据。

开发者补丁没有系统性速度优势

把每个模型与标准答案在各自解决的案例上比较，GPT、DeepSeek 和 Claude 总体上都快于开发者补丁，而 Qwen 始终更慢。胜负案例数让总体结果更复杂：Claude 输掉的案例多于赢下的案例，但总体仍然更快，说明它赢下的案例提速幅度大于输掉案例的减速幅度。Qwen 的胜负案例数大致相当，说明它输掉案例的减速幅度大于赢下案例的提速幅度。

论文的解释是，不能假定标准答案就是最高效的解法；它只是与其他解法地位相同的其中一个解。这也是作者偏好几何平均、而非相关工作在对照固定专家参考时使用的调和平均的原因。几何平均在分子分母互换时保持比较稳定，因此成对比较的方向可以互换。

性能分析揭示架构层面的回退

案例研究补充了一个正确性评估无法给出的定性结果。针对同一个问题，三种修复策略的性能相差两倍以上，其中两种开销较高的策略悄悄重新引入了开发者刻意移除的重型依赖。它们的正确性测试全部通过；只有运行测量才揭示出这次修复推翻了原有的架构决策。

这是论文支持测量补丁、而不只是给补丁打分的最有力论据。一个通过全部 F2P 测试的补丁，仍可能带有基准从未看到的开销；在这个案例中，该开销源于设计选择，而不是偶然的额外负担。

测量在何处失去区分力

该方法有论文自述的局限。筛选条件较为严格，不过作者称其是确定性的、可复现的。两个基准都取自 Python 仓库，作者计划扩展到对性能更敏感的语言，例如 C 和 C++。所有解法都来自同一个 SWE-agent 框架，因此补丁的多样性主要来自模型而非智能体；人工编写的标准答案补丁拓宽了比较范围，作者还计划纳入 OpenHands 等更多框架。

还有一层测量层面的限制：当测试的前几次重复完成了与修复相关的工作，后续重复只是读取遗留状态时，测量值会退化为难以区分的极小值，解法之间的区分度随之下降。作者承认这一点。实际后果是，Welch ANOVA 结果不显著应当理解为该测试未能区分补丁，而不是证明这些补丁性能相同。

把运行性能与解决率一并报告

论文的优先主张很具体：仓库级问题解决的评估应当在解决率之外报告补丁的运行性能，因为两种排序几乎相反，任何一方都不能替代另一方。对单个案例采取行动的具体门槛是 Welch ANOVA 的判定——只有可区分案例（262 个中最多 42%）才支持“某个正确补丁比另一个更快”的结论。

对比较模型的读者来说，可操作的划分在于全集与可区分子集之间：模型排序在两者中都成立，但剔除无区分度的案例后差距会拉大，因此忽略可区分子集的比较会低估真实差异。对判断单个补丁的读者来说，案例研究设定的标准高于通过测试：一个重新引入已移除重型依赖的补丁能通过正确性测试，但相对更精简的修复会损失一半以上的速度。

本文引用的文献