微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 当AI写代码的"评分卷子"本身不靠谱时,我们该怎么办?——新加坡管理大学等机构对三大代码优化基准测试的全面审计

当AI写代码的"评分卷子"本身不靠谱时,我们该怎么办?——新加坡管理大学等机构对三大代码优化基准测试的全面审计

2026-07-10 08:16
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-07-10 08:16 科技行者

这项研究由新加坡管理大学和上海交通大学的研究团队联合完成,于2026年7月以预印本形式发布,论文编号为arXiv:2607.01211v1,分类归属于计算机科学软件工程方向(cs.SE)。感兴趣的读者可通过该编号在arXiv平台查阅完整论文。

**故事从一道考题说起**

每次期末考试,老师出的题目本身必须是靠谱的——如果答案卷上的标准答案有一半是错的,或者同一道题在不同考场判分方式完全不同,那这场考试就算不上公平,它测出来的分数也就没什么意义。

现在,AI领域正在发生类似的事情。

近几年,有一类人工智能程序变得非常热门,叫做"代码智能体"——简单说,就是能够自动阅读一段程序代码、找出让它运行更快的方法、然后写出改进方案的AI。各大科技公司纷纷宣称自己的AI在这件事上越来越厉害,数字一个比一个好看。但这些数字是从哪儿来的?它们是通过"基准测试"打出来的成绩,也就是专门设计出来衡量AI能力的"考试卷"。

问题在于:这些"考试卷"本身够不够可靠?

新加坡管理大学和上海交通大学的研究团队决定认真审查一下这个问题。他们选取了目前最具代表性的三套代码性能优化基准测试——GSO、SWE-Perf和SWE-fficiency——对这三套"考卷"从头到尾做了一次深度审查,结论相当发人深省。

---

**一、我们在考什么?先搞清楚这三套"考卷"**

要理解研究团队发现了什么问题,首先得知道这三套基准测试是干什么用的。

你可以把一个代码智能体理解成一个专门负责"加速程序"的工程师。给它一段代码和一项任务,它需要找出代码里跑得慢的地方,然后改写代码让程序运行得更快,同时保证程序的功能不出错。这比简单地写代码要难得多——就像不只是要求你做一道菜,还要求你在保持口味不变的前提下把烹饪时间缩短一半。

三套基准测试的共同框架是这样的:每道题都对应一个真实的开源代码仓库,题目里有一段"原始代码"(基线)和一段"参考优化代码"(官方标准答案),还配有专门用来测量运行速度的"计时程序"。AI提交的改动会被跑一遍,然后把跑出来的速度和"基线"以及"标准答案"做比较,据此打分。

三套测试的具体规模和风格各有不同。GSO来自NeurIPS 2025,包含102道题,涉及10个代码仓库,它用的是专门生成的性能测试用例;SWE-Perf来自ICML 2026,包含140道题,涉及9个仓库,用的是从仓库源码中筛选出来的单元测试;SWE-fficiency同样来自ICML 2026,规模最大,498道题,涉及9个仓库,配有专门标注过的工作负载脚本。三套测试的打分方式也各不相同,后面会详细说到这一点。

---

**二、换一台机器,"标准答案"还算数吗?**

研究团队提出的第一个核心问题是:这些"标准答案"(也就是每道题配套的参考优化代码)在不同的计算机上运行,还能稳定地展现出应有的加速效果吗?

这个问题乍一听可能有点奇怪。但想想看:一道性能优化题的"标准答案"不是数学公式,它只是一段改动了的代码。代码跑多快,会受到机器硬件的影响——就像同样一辆自行车,在平路上骑和在山路上骑,速度自然不同。如果"标准答案"只在某一种特定机器上跑得快,换一台就未必如此,那这道题的评判标准从根源上就不稳定了。

为了检验这一点,研究团队选取了谷歌云上四种不同配置的服务器——两款英特尔芯片和两款AMD芯片,横跨2019年到2025年的不同产品世代——每种配置都保持同样的64核心、256GB内存。每道题的"标准答案"在每台机器上各跑三轮,加起来一共跑了12轮,然后用每个基准测试自己原本的评判标准来衡量结果是否合格。

结果出来,研究团队用了两把"尺子"来量。第一把是宽松的:只要"标准答案"在所有机器所有轮次里都比原始代码跑得更快,就算通过。第二把是严格的:要求结果满足每套测试当初设定的完整有效性规则,比如GSO要求速度提升至少1.2倍,SWE-Perf要求统计显著性检验通过且增益系数高于0.05,SWE-fficiency要求均值差异超过标准差的两倍。

用宽松标准衡量时,GSO有91道题通过(102道里),SWE-Perf有48道通过(140道里),SWE-fficiency有470道通过(498道里)。这个结果已经不太理想,但更严格的规则下情况更糟糕——GSO仅剩39道,SWE-Perf仅剩11道,SWE-fficiency剩下411道。

换句话说,SWE-Perf的140道题里,只有11道"标准答案"在所有机器上都能稳定地满足题目原本的有效性要求。这个比例仅有8%。

为什么SWE-Perf这么惨?研究团队进一步分析了原因。他们把每道题"标准答案"的加速幅度换算成一个通用指标——"运行时间变化百分比",负数表示跑得更快,正数表示跑得更慢。结果发现,SWE-Perf里绝大多数题目的"标准答案"实际上几乎没有让程序变快多少:138道可运行的题目中,有101道的中位运行时间变化在零附近正负5个百分点以内,而整体中位数仅仅是-0.03%,基本等于没变化。

这就像一位厨师声称自己改进了菜谱,但品尝员发现味道几乎和原来一模一样——微弱到根本分不清是真的改进了,还是只是今天厨师的手抖了一下。这种情况下,当测试环境换了一台机器,哪怕机器噪声只变动了1到2个百分点,就足以让原本"勉强通过"的结果变成"不通过"。

相比之下,GSO和SWE-fficiency的"标准答案"通常有更大的加速幅度(中位数分别是-54.2%和-56.0%),所以就算机器之间有些差异,结论也基本不会翻转。这让它们相对更稳定。

---

**三、同样的AI表现,不同的打分规则,排名大翻车**

即便"考卷"的标准答案是可靠的,还有另一个关键问题:怎么把一道道题的成绩汇总成最终排名?这个"加权算法"的选择,对最终谁排第一、谁排末尾有多大影响?

研究团队发现,GSO和SWE-fficiency虽然都是测代码优化能力的,但它们的打分方式截然不同。

GSO用的是一个简单直接的规则:对于每道题,AI提交的改动要么"成功"要么"失败"。判定成功的标准是:代码功能正确,且速度提升幅度达到或超过"标准答案"。所有102道题里,成功的数量除以102再乘以100,就是最终得分。每道题贡献相同的分量,一道题的成功就是0.98分,没有部分分。

SWE-fficiency则用了一个完全不同的数学工具,叫做"调和平均数"。对于每道题,它先算出一个"速度比"——AI提交版本的速度相对于"标准答案"速度的比值。如果比值等于1,说明和标准答案一样快;大于1说明超过了标准答案;小于1说明没达到。然后用所有498道题的这个比值取调和平均。

调和平均数有一个非常特别的性质:它对"极低值"非常敏感,极低值会急剧拉低最终得分。SWE-fficiency为了防止除以零,给比值设了一个下限0.001——这意味着一道非常糟糕的题(比如AI提交的代码完全无法运行,或者反而把程序拖慢了100倍)会产生一个高达1000的分母贡献,而正常完成一道题的分母贡献只有1。换句话说,一道"极差题"的权重是一道"正常题"的1000倍。

研究团队找到了八个同时出现在GSO和SWE-fficiency排行榜上的AI提交记录,然后对比这两套测试给出的排名。结果发现,两套测试对28对两两比较中有9对意见相左——这意味着大约三分之一的"谁比谁强"的判断,在两套测试里答案是相反的。其中,一个以GPT-5为基础模型的提交在GSO排名第7,但在SWE-fficiency排名第2,整整跳了5位。

这种不一致从哪里来?部分原因是两套测试考的题目不同,但另一个重要原因就是打分方式本身。研究团队做了一个实验:把SWE-fficiency的任务结果,用GSO的二元成功率来重新计算,两套测试的排名一致性就从斯皮尔曼相关系数0.452提升到了0.762,不一致的对数从9对降到6对。这说明打分规则本身确实在左右结果。

---

**四、一道"烂题"能把整个排名拖垮**

调和平均数的"极端敏感"到底会造成多大的实际影响?研究团队专门测量了每道题对最终得分的贡献权重,然后找出每个AI提交记录里权重最高的那些题。

结果令人震惊:在SWE-fficiency的8个公开提交记录里,权重最高的1道题,在不同AI提交里占到了该AI总分分母的6.3%到33.6%。最高的是Claude Opus 4.5这个提交——仅仅一道题的"速度比"为0.00134(比标准答案慢了将近750倍),就占了它整个总分分母的33.6%。

换句话说,这一道题的分量,相当于其他164道正常完成的题目加在一起的一半多。

如果把最差的10道题加在一起看,它们占到所有8个AI提交记录总分分母的58.5%到82.8%。这意味着,在一个498道题的测试里,最差的10道题控制了超过一半的评分权重,其余488道题加在一起还没这10道题重要。

研究团队想知道,如果把这种"极端惩罚"给一个合理的上限,排名会发生什么变化。他们提出了一个"有界惩罚"方案:把每道题的惩罚上限设为1(就是下限从0.001改成0.5),这样最差的一道题对分母的额外贡献最多只有1,和一道普通题处于同一量级。

这个改动导致8个提交记录中有6个排名发生变化,28对两两比较中有8对结果翻转。Claude Opus 4.6和GPT-5.2分别上升了2名,GPT-5下降了3名,Claude Opus 4.5下降了2名。这不是在说哪个方案"更好"——只是说明,当你换一种合理的惩罚设计时,整个排行榜就会重新洗牌。

---

**五、剩下没解决的题,其实已经被解决了大半**

现在来到最后一个问题:在那些"标准答案"经过跨机器测试仍然可靠的题目里(研究团队称之为"回放有效任务"),当前最好的AI提交记录到底能解决多少?

研究团队把视角稍微调宽了一点:不是问"某一个AI提交能解决多少题",而是问"在10个公开提交记录里,至少有一个能解决的题有多少"。这更接近实际使用场景——毕竟在实际工程里,工程师可以挑选多个AI系统的建议,选最好的那个用。

在经过严格筛选的450道回放有效题目里(39道来自GSO,411道来自SWE-fficiency),情况如下:全部450道题都至少有一个AI提交记录能给出功能正确的代码改动;449道题里至少有一个正确改动比原始代码跑得更快;而至少有一个提交达到或超过"标准答案"速度的有384道,占85.3%。

剩下66道题,没有任何一个公开提交记录能达到"标准答案"的速度。但这是否意味着这66道题都是无从下手的难题?

研究团队进一步检查了这66道题里每道题表现最好的那个AI提交。结果是:全部66道题都有正确的AI代码改动;65道题里最好的AI改动比原始代码更快;只有1道题的最好AI改动虽然代码正确但速度没有提升。

所以这66道题基本上不是因为AI完全没有头绪。它们更像是厨师做了一道不错的菜,但还没达到米其林三星的水准:GSO里这66道题的最佳AI改动中位数达到了"标准答案"速度的85.3%,SWE-fficiency里则是87.9%。其中27道SWE-fficiency题已经达到了90%以上,距离标准答案只差最后一口气。

研究团队还想搞清楚:这最后的差距是因为AI走错了方向(用了完全不同的优化策略),还是因为方向对了但做得不够深?他们请另一个AI模型(GPT-5.5)对这66道题的"标准答案"和每道题最好的AI改动各自打上优化策略标签,分成算法优化、数据结构优化、内存优化、代码结构优化等类别。

32道题里,最好的AI改动和"标准答案"用了同一大类优化策略;另34道题里策略不同。有趣的是,用了相同策略的32道题,中位速度比达到了"标准答案"的89.8%,差一点;但用了不同策略的32道题里,居然有11道达到了90%以上。策略是否相同,并不能很好地预测最终差距有多大。

研究团队的解读是:这些AI通常已经找到了正确的优化方向,但在细化实现的时候做得不够彻底——比如找到了应该优化循环,但只优化了一处,没有把相关的所有地方都改到位。

---

**说到底,这些发现意味着什么?**

归根结底,这篇论文想说的是:当我们看到一个AI在某个代码优化排行榜上拿了高分,这个分数并不像我们以为的那么直截了当。

首先,分数依赖于"标准答案"是否稳定——而研究表明,相当多的"标准答案"在换一台机器后就失去了应有的加速效果,尤其是SWE-Perf里的绝大多数题目。其次,分数还取决于打分规则的设计——SWE-fficiency的调和平均数打法会让几道表现极差的题主宰整个评分,换一种同样合理的打分方式,排名就会大幅改变。第三,当我们把视野从"单个AI提交"扩大到"多个公开提交里取最优"时,很多原本看似未解决的题目其实已经有了不错的解法,真正的差距往往只是最后一段优化深度的距离。

对于想用这些测试结果来判断AI进步的人来说,这意味着光看排行榜分数是不够的:需要知道哪些题目的基准信号是可靠的,每道题对最终得分的贡献权重是多少,以及不同打分规则下排名的变化情况。对于开发AI系统的工程师来说,这些发现提示他们,在现有的"回放有效"题目里,绝大多数任务已经能被至少一个公开AI系统相当好地完成,真正的挑战是那最后一步从"比原版快"到"和最优方案一样快"的距离。对于下一代基准测试的设计者来说,这些发现指出了一个更难但更真实的方向:不是给AI一段代码和一个已知的计时测试,而是给AI一份性能画像或火焰图,让它自己判断哪里是瓶颈、选择优化目标、验证优化效果,同时兼顾速度、内存、延迟等多个维度。

这项研究的价值不在于否定已有的测试工具,而在于帮助大家更准确地读懂这些工具说的话——就像校准一把尺子,不是要扔掉它,而是要知道它的误差范围在哪里。

有兴趣深入了解具体方法和数据的读者,可以通过arXiv编号2607.01211v1查阅完整论文。

---

Q&A

Q1:SWE-Perf基准测试为什么跨机器稳定性特别差?

A:SWE-Perf的核心问题不是机器噪声太大,而是"标准答案"本身的加速幅度太小。140道题里绝大多数题目的参考优化代码,运行时间变化中位数仅为-0.03%,几乎等于没有优化。这么微弱的信号,稍微换一台机器或换一轮测试,就可能从"比原版快"变成"差不多"甚至"更慢",导致该题目在统计检验下失效。相比之下,GSO和SWE-fficiency的标准答案通常有超过50%的加速幅度,所以机器间差异很难改变结论。

Q2:SWE-fficiency的调和平均打分方式有什么问题?

A:调和平均数对极低值极度敏感。SWE-fficiency允许每道题的速度比最低降到0.001,这意味着一道极差的题在分母里贡献1000,而一道正常完成的题只贡献1。在498道题的测试里,最差的10道题可以占到总分分母的58.5%至82.8%,让排名主要由少数极端失败案例决定,而不是整体表现。把惩罚上限从1000压到1,就会导致6个AI提交排名发生变化,28对两两比较中有8对结果翻转。

Q3:代码优化基准测试里剩下的"未解决"题目,AI真的完全没有解法吗?

A:并非如此。研究团队发现,在66道没有任何公开提交达到标准答案速度的题目里,全部66道都有正确的AI代码改动,65道的最佳AI改动比原始代码更快,只是没达到标准答案的速度。这些题目的最佳AI改动中位数已达到标准答案速度的85%至88%左右,27道题甚至达到了90%以上。问题通常不是AI找错了方向,而是优化做得不够彻底,没有把改进贯彻到代码里所有相关的位置。

分享至
0赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-