⏶52
ACES：谁来测试测试程序？代码生成的留一法 AUC 一致性研究
发表
由 
Hui Sun 提交
Hui Sun 提交作者: Hui Sun, Yun-Ji Zhang, Zheng Xie, 
Ren-Biao Liu, Yali Du, Xin-Ye Li, Ming Li
Hui Sun, Yun-Ji Zhang, Zheng Xie, Ren-Biao Liu, Yali Du, Xin-Ye Li, Ming Li摘要
AI 生成总结
研究人员通过开发 ACES 解决了从大语言模型生成的输出中选择正确备选代码的挑战。该方法通过留一法评估和 AUC 一致性评分，根据测试区分正确与错误代码的能力对测试进行排序。使用 LLM 生成的测试用例来筛选 LLM 生成的代码候选方案极具挑战性，因为测试用例本身可能不正确。现有方法要么平等对待所有测试，要么依靠权宜的启发式规则来过滤不可靠的测试。然而，确定测试的正确性需要已知哪些代码是正确的，这产生了一个循环依赖。我们的核心见解是，我们根本不需要确定测试的正确性：测试投票应该是排序，而不仅仅是计数。重要的不是有多少代码通过了测试，而是该测试是否能区分正确代码和错误代码。我们通过“留一法”评估打破了循环依赖：留出一个测试，根据代码在所有剩余测试中的总分进行排序，并测量被留出的测试的通过/失败模式是否与此排序一致。我们将这种一致性形式化为留一 AUC（LOO-AUC），并证明预期 LOO-AUC 与每个测试分离正确/错误代码的能力成正比。基于此，我们提出了 ACES（AUC 一致性评分），包含两个互补的变体：ACES-C 提供闭式权重，在对平均测试质量的一个温和假设下，证明可以在期望上逼近 Oracle（真值）；ACES-O 则抛弃这一假设，迭代优化可微分的 LOO-AUC 目标。两者都仅在二进制通过矩阵（pass matrix）上运行，开销极小，并在多个代码生成基准上实现了最先进的 Pass@k。
评论
Mishig DavaadorjACES：谁来测试测试题？代码生成的留一法 AUC 一致性研究
目前的代码生成基准测试依赖测试套件来判断方案的正确性，但这些测试套件本身的质量却鲜受审视。ACES 引入了一种原则性的“留一法”（leave-one-out）方法论，用于衡量并提升基准测试中排名代码生成模型时所用测试套件的可靠性，确保基准测试结果反映的是真实的性能差异，而非薄弱测试导致的偏差。
核心思想
ACES 通过每次移除一个测试用例并检查产生的模型排名是否保持稳定来评估测试套件的质量。如果移除某个特定的测试从未改变任何模型的排名，则该测试被视为低质量——它没有提供区分能力。通过将此量化为 AUC 一致性，ACES 提供了一个标量，用于衡量每个独立测试对可靠评估的贡献程度。
方法/路径
该框架计算整个测试套件中模型两两比较的曲线下面积 (AUC)，然后系统地重新计算排除每个测试后的 AUC。移除后导致 AUC 偏移微乎其微的测试被标记为冗余或无信息。随后，ACES 将测试套件过滤为一个精简且高一致性的子集，该子集能够保留——甚至强化——原始的排名信号。
结果
由 ACES 生成的过滤后的测试套件规模大幅减小，但在各种代码生成模型中产生了更稳定且可复现的排名。这表明现有的许多基准测试都是冗余或有噪声的，而针对性的过滤可以使代码生成评估既更具成本效益又更可信。
使用 LLM 生成的测试来筛选 LLM 生成的代码候选者具有挑战性，因为测试本身可能是不正确的。现有方法要么平等对待所有测试，要么依赖权宜的启发式方法来过滤不可靠的测试。然而，确定测试的正确性需要已知哪些代码是正确的，这形成了一个循环依赖。我们的核心见解是，我们根本不需要确定测试的正确性：测试投票应该进行排名，而不仅仅是计数。重要的不是有多少代码通过了测试，而是该测试是否能区分正确与错误的代码。我们通过留一法评估（leave-one-out evaluation）打破了循环依赖：留出一个测试，根据代码在所有剩余测试中的总分进行排名，并衡量被留出的测试的通过/失败模式是否与该排名一致。我们将这种一致性正式定义为留一法 AUC (LOO-AUC)，并证明预期的 LOO-AUC 与每个测试区分正确代码和错误代码的能力成正比。基于此，我们提出了 ACES（AUC 一致性评分），它包含两个互补的变体：ACES-C 提供了闭式解权重，在对平均测试质量的温和假设下，可证明其在期望上接近预言机（oracle）；ACES-O 则去掉了这一假设，并迭代优化一个可微的 LOO-AUC 目标。两者都仅在二进制通过矩阵（binary pass matrix）上运行，开销极小，并在多个代码生成基准上实现了最先进的 Pass@$$k$$ 性能。