Hugging Face 上的 SWE-bench Verified：9 条自报成绩超过官方榜首，6 个仓库包揽 78 行中的 16 行

Dev.to ML 2026-11-05T08:36:41+08:00

TL;DR 2026 年 11 月 5 日，Hugging Face 的 SWE-bench Verified 榜单列出 68 个仓库的 78 行。51 行来自仍处于开放状态的拉取请求，27 行位于仓库主分支，0 行经过验证。有 9 行高于 79.2，即 swebench.com 上 Verified 表的最高条目（数据文件最后更新于 2026 年 2 月 26 日）。这 9 行全部是自报结果。排名第 1 的行（86.0）只在模型卡脚注里提到其评测框架，榜单行本身没有备注。6 个仓库占了 78 行中的 16 行。一个 gpt-oss 仓库以三种推理强度出现三次，而 20B 模型这几行跨度达 23.3 分。一个 Nemotron 模型及其重新上传版本带有相同的三个评测框架分数，所以 6 行其实只是 3 次测量。有 3 行引用“SWE-Bench official evaluation”，并且与 swebench.com 上 2026 年 2 月 17 日的 mini-SWE-agent 运行结果完全一致。其中一个仓库 GLM-5，在榜上还有厂商自己的 77.8 分，比它高 5.0 分、高 19 个名次。有一个任务只值 0.2 分，而单次 80% 运行的 95% 区间约为上下各 3.5 分。第 6 到第 9 名（80.6 到 80.2）只差 2 个任务。橙色柱表示其 YAML 文件只存在于一个开放拉取请求中的行。蓝色柱表示已经在模型仓库主分支上的行。坐标轴从 74 开始，所以柱长夸大了差距；请看数字。Hugging Face 上的 SWE-bench Verified 榜单包含什么？SWE-bench Verified 是来自流行 Python 仓库的 500 个 issue 与拉取请求配对、经过人工验证的子集。评测会用代理生成的补丁运行仓库的单元测试。Hugging Face 将其列为一个基准数据集，因此模型仓库可以在 .eval_results/*.yaml 中发布结果，而该数据集的榜单会收集它。我在 2026 年 11 月 5 日（KST）从排行榜视图背后的 JSON 拉取了该榜单。它有 78 行。该数据集自己的 eval.yaml 定义了两个任务 id：swe_bench_%_resolved 和 swe_bench_average_cost，并指名 swe-bench 评测框架。它没有指明代理、脚手架、尝试次数或上下文长度。这一点很重要，因为对这个基准来说，脚手架本身就是测量的一部分。

光有模型并不能改动代码仓库，还需要智能体循环（agent loop），而每个团队用的循环都不一样。78 条记录的 notes 字段中，有 54 条是空的。9 条注明了评测框架（harness）或官方运行。也就是说，大多数行根本没告诉读者这个数字是怎么来的，唯一能查的地方就是每行背后的模型卡（model card）。榜单上有任何一条经过验证吗？没有。78 条的 verified 字段全是 false。

我查了每个带 pull request 编号的行背后的讨论。

51 个 pull request 全部处于开放状态。最早的一个开于 2026 年 2 月 16 日，距我拉取数据已过去 262 天；中位年龄 153 天，51 个里有 36 个超过 90 天。榜首那行就是其中之一：Ornith-1.5-397B（86.0）来自 2026 年 8 月 19 日由 Hugging Face 账号提交的 PR，而非模型所有者本人。

我不是在批评这个设计。拿模型卡上的结果开 PR，是给榜单起步的合理方式，而且每个文件都标了来源。代价是排名把所有者认可的结果和别人转录的结果混在了一起，而 rank 列里没有任何东西能把两者区分开。前十名中有五行在 main 分支上，五行是开放 PR。

为什么有九行能超过官方榜单的最好成绩？swebench.com 网站有自己的 Verified 表。背后的数据文件有 180 条记录，最新日期为 2026 年 2 月 26 日，最高值 79.2，由两个 2025 年 12 月的智能体提交并列持有（Sonar Foundation Agent 配 Claude Opus 4.5，以及 live-SWE-agent 配 Claude Opus 4.5）。两者都没有标记为已核验。使用该网站仅 bash 工具版 mini-SWE-agent 的运行中，最高记录是 76.8（Claude Opus 4.5，2026 年 2 月 17 日）。而在 Hugging Face 榜单上，有 9 行超过 79.2，18 行超过 76.8。

这并不能证明哪里出了问题。新模型更强，而官网的表从二月起就没更新过。但两张表衡量的并不是同一件事。官网的 mini-SWE-agent 运行给每个模型配的是同一个最小智能体，只有一个 bash 工具。

榜单上的每一行，用的是各团队自己的 harness（测试框架），只要点开模型卡片就能看到具体配置：

排名第一的卡片里那些反作弊措施值得肯定，但也说明这个分数只属于某个特定环境。在能看清配置的高排名条目中，出现了两种不同的智能体循环（OpenHands 和 Claude Code），而官方站点用的都不是这两种。

那么，同一个模型换个 harness，分数会差多少？榜单本身就能回答这个问题——有些仓库提交了多行结果。

NVIDIA 的 Nemotron-3-Super-120B 卡片，针对同一套权重报告了三个 SWE-bench Verified 结果：用 OpenHands harness 是 60.47，用 OpenCode 是 59.20，用 Codex 是 53.73。不同 harness 之间相差 6.74 分，约合 34 道题。榜单上分别排在第 60、63、68 位。RedHatAI 里同名的仓库也带了同样的三行，来源 URL 指向 NVIDIA 的卡片，排在第 61、64、69 位。六行、三组测量、两个仓库。

gpt-oss 系列则换了另一个维度。OpenAI 的模型卡给出了低、中、高三档推理强度，榜单把三档全列了出来。gpt-oss-120b 分别是 47.9、52.6、62.4，排在第 75、72、56 位；gpt-oss-20b 是 37.4、53.2、60.7，排在第 77、70、59 位。大模型跨度 14.5 分，小模型跨度 23.3 分。这里没人虚报——推理强度就写在文件名里。但读者如果去查 gpt-oss-20b，落在三行中的哪一行，得到的答案就不一样，最好和最差的两行相差 18 个名次。

openPangu-2.0-Flash 的情况类似，只是数字更小：思考模式 63.1，非思考模式 57.6，差距 5.5 个点。

GLM-5 是最典型的例子。它的 YAML 文件里只有两条记录：一条是 72.8，来源标注为 swebench.com，备注写着「高推理强度，官方数据」；另一条是 77.8，来源标注为模型卡，备注写着「Z.ai 自报数据」。榜单上 77.8 排在第 15 名，72.8 排在第 34 名，中间隔了 19 个名次、25 个任务。72.8 与 swebench.com 的数据文件完全吻合：mini-SWE-agent v2.0.0 搭配 glm-5，高推理强度，日期为 2026 年 2 月 17 日。MiniMax-M2.5（75.8）和 Kimi-K2.5（70.8）也是同样的情况。也就是说，榜单上只有这三行能追溯到我可查证的、在统一测试框架下进行的运行记录；而对 GLM-5 来说，这次运行的得分比厂商自己报告的数字低了 5.0 分。厂商的数字完全可能来自更好的脚手架，我也没有尝试复现其中任何一个。问题在于，榜单把两者放在了同一把尺子上。

榜单上的行都是不同的模型吗？并非总是如此。还有两个例子。第 2 名和第 3 名分别是 Macaron-V1-Venti（在 main 分支上）和 Macaron-V1-Coding-Venti（nielsr 提交的一个开放拉取请求），均为 85.6。我没有核实这两个仓库是否存放了相同的权重。如果相同，那前三名里就有两个名次是同一个结果；如果不同，这个一模一样的数值就是个值得加脚注的巧合。

第 46 名和第 50 名分别是 poolside/Laguna-XS.2（69.9）和 MuVeraAI/Laguna-XS.2（68.2）。第二个仓库的 YAML 把 poolside 的模型卡列为数据来源。那张卡片的表格目前写的是 69.9，4 次运行的平均 pass@1，上下文长度 262,144 token。而 MuVeraAI 仓库里存的是这张卡的一个副本，最后修改于 2026 年 4 月 28 日，上下文长度 131,072 token，同一张表里写的是 68.2。该仓库的下载量字段显示 16，而 poolside 仓库是 905,143。所以 68.2 看起来像是一张卡片被更新之前的旧版本，被复制到了另一个仓库，还单独占了一个名次。我能看到来源链接和数字对不上，但看不出这个副本存在的理由。

500 个任务能把这些行区分开吗？这个基准测试有 500 个任务，所以一个任务就是 0.2 分。下面的算术是针对固定任务集上单次运行的抽样计算。

提示词和测试框架带来的波动更大，Nemotron 那几行就能说明问题。

第 8 名和第 9 名并列 80.2 分，第 6 名只比它们高 2 道题。在同一批 500 道题上做配对比较，置信区间会比我现在展示的独立区间更窄，但这需要每道题的结果，而排行榜的一行数据并不包含这些信息。所以前 14 行从 86.0 到 78.0，其中只有少数几个差距我认为大于噪声，而且没有一个是通过已验证运行确立的。

那基准测试本身呢？

2026 年 2 月，OpenAI 表示不再把 SWE-bench Verified 当作衡量前沿编码能力的标准。Pebblous、Decrypt 等第三方对该声明的总结称，在审核的 138 道难题中，59.4% 存在测试或题目描述缺陷，其中 35.5% 源于测试范围过窄，还有一些题目显示出训练数据泄漏的迹象。OpenAI 的页面给我的抓取工具返回了 HTTP 403，所以我只能转述这些总结，没有读到原文；引用这些百分比之前请先核实。当时 OpenAI 推荐用 SWE-bench Pro 作为替代。我在本系列之前的一篇文章中看过 Pro 排行榜，它也有自己的混杂问题。

对看排行榜的人来说，结论很实际。Verified 上 80 或 86 左右的分数，来自一个主要早期采用者已经质疑其评分方式的基准。它仍能大致给模型排序，排行榜作为各种声称的索引也仍有价值。但用它来做采购决策，或者声称某个开源模型比另一个强两个点，依据就很薄弱了。

我怎么自己拉取排行榜并验证？

脚本只用标准库。它按来源统计行数，找出有多行的仓库，并把排行榜与 swebench.com 的数据文件做对比。

import json, math, urllib.request, collections

def get(url):
    req = urllib.request.

Request ( url , headers = { " User-Agent " : " Mozilla/5.0 " })
    return json . load ( urllib . request . urlopen ( req , timeout = 120 ))

rows = get ( " https://huggingface.co/api/datasets/SWE-bench/SWE-bench_Verified/leaderboard " )
repos = collections . Counter ( r [ " modelId " ] for r in rows )
multi = { k : v for k , v in repos . items () if v > 1 }

authors = collections . Counter ()
for r in rows :
    pr = r . get ( " pullRequest " )
    if pr :
        d = get ( f " https://huggingface.co/api/models/ { r [ ' modelId ' ] } /discussions/ { pr } " )
        authors [( d [ " status " ], d [ " author " ][ " name " ])] += 1

print ( " rows: " , len ( rows ), " | repos: " , len ( repos ), " | verified: " , sum ( bool ( r [ " verified " ]) for r in rows ))
print ( " open/merged PR rows by author: " , dict ( authors ), " | main-branch rows: " , sum ( not r . get ( " pullRequest " ) for r in rows ))
print ( " repos with 2+ rows: " , len ( multi ), " carrying " , sum ( multi . values ()), " rows " )
print ( " empty notes: " , sum ( not ( r . get ( " notes " ) or "" ). strip () for r in rows ))

n = 500
print ( " one task = %.1f points " % ( 100 / n ))
for acc in ( 0.70 , 0.80 , 0.86 ):
    print ( " accuracy %.2f: 95%% half-width = %.2f points (illustrative, independent runs) " % ( acc , 1.96 * math . sqrt ( acc * ( 1 - acc ) / n ) * 100 ))

lb = json . load ( urllib . request . urlopen ( urllib . request . Request ( " https://raw.githubusercontent.com/swe-bench/swe-bench.github.io/master/data/leaderboards.json " , headers = { " User-Agent " : " Mozilla/5.0 " }), timeout = 120 ))
ver = next ( l for l in lb [ " leaderboards " ] if l [ " name " ] == " Verified " )[ " results " ]
top = max ( v [ " resolved " ] for v in ver )
print ( " swebench.com Verified table: %d entries, max %.1f, newest %s " % ( len ( ver ), top , max ( v [ " date " ] for v in ver )))
print ( " HF rows above that max: " , sum ( r [ " value " ] > top for r in rows ))

2026 年 11 月 5 日，它打印出：rows: 78 | repos: 68 | verified: 0

按作者统计的开放/已合并 PR 行数：{('open', 'SaylorTwift'): 28, ('open', 'nielsr'): 23} | 主分支行数：27

拥有 2 行及以上数据的仓库：6 个仓库共承载 16 行

空注释条目：54 条

一个任务 = 0.2 分

准确率 0.70：95% 半宽 = 4.02 分（示例性数据，独立多次运行）

准确率 0.80：95% 半宽 = 3.51 分（示例性数据，独立多次运行）

准确率 0.86：95% 半宽 = 3.04 分（示例性数据，独立多次运行）

swebench.com Verified 表格：180 条记录，最高 79.2，最新日期 2026-02-26

HF 上超过该上限的行数：9

这个榜单接口没有公开文档，字段名可能会变。想核对某一行，就打开它的 pullRequest 讨论，读一读 YAML，再看源模型卡的脚注。明确写出评测框架（harness）的注释很少见，通常要到模型卡里找。

阅读 Verified 分数时的检查清单

• 这一行是已验证的，还是来自一个尚未合并的 pull request？看徽章，不要看排名。
• 用的是哪个评测框架？跑了几次？如果 YAML 注释是空的，去看模型卡脚注。
• 同一个仓库是否出现了不止一次？挑那个你实际会跑的配置所在的行。
• 这个数字是不是某个副本或重新上传，借用了别人的成绩？顺着来源链接比对一下。
• 分差是否大于几道题，并且大于评测框架之间的波动？在这个榜上，同仓库内的分差在 5 到 23 分之间。
• 这个基准还撑得起这么重的分量吗？读读它自己的维护者，以及它最大的早期采用者，对测试说过什么。

常见问题

Hugging Face 的 SWE-bench Verified 排行榜上有多少个模型？

截至 2026 年 11 月 5 日，榜上有来自 68 个仓库的 78 行。有 6 个仓库占了多行，合计 16 行。

Hugging Face 的 SWE-bench Verified 排行榜经过验证吗？

没有任何一行的 verified 字段被设为 true。51 行来自开放的 pull request，由两个 Hugging Face 员工账号提交；另外 27 行位于模型仓库的主分支上。

为什么 Hugging Face 的榜上分数比 swebench.com 高？

有 9 行超过了该站点 Verified 数据文件里的最高值 79.2，该文件最后更新于 2026 年 2 月 26 日。榜上的行是各团队用自己的评测框架自行上报的，而站点上的 mini-SWE-agent 跑法只用了一个极简的、仅依赖 bash 的 agent。不同的评测框架会让分数相差好几分，Nemotron 的三行就是例子。

评测框架会改变 SWE-bench Verified 的分数吗？

会。NVIDIA 的 Nemotron-3-Super-120B 模型卡给出：用 OpenHands 是 60.47，用 OpenCode 是 59.20，用 Codex 是 53.73。GLM-5 由自家给出 77.8，而 swebench.com 用 mini-SWE-agent 跑出来是 72.8。

我还应该用 SWE-bench Verified 来比较编程模型吗？

当作粗略的参考指标，可以。当作做决定的那一个数字，不行。

Hugging Face 上的 SWE-bench Verified：9 条自报成绩高于官方榜单最佳成绩，6 个仓库占 78 行中的 16 行

OpenAI 在 2026 年 2 月表示，已不再把这项基准当作衡量前沿能力的标准；而 Hugging Face 榜单上还混着不同的测试框架（harness）、不同的推理投入程度，以及同一模型的多个副本。想要了解真实水平，还是得在自己的任务上、自己的 agent 里跑一遍。

延伸阅读：

• Hugging Face 上的 GSM8K：前 12 行中有 4 行展示的其实是同一系列另一个模型检查点（checkpoint）的成绩，28 行里有 20 行是尚未合并的 PR
• SWE-Bench Pro 有两个版本：Hugging Face 榜单的 47 行到底混了哪些内容

TL;DR：截至 2026 年 11 月 5 日，Hugging Face 上的 SWE-bench Verified 榜单共有来自 68 个代码仓库的 78 条记录。其中 51 条来自尚未合并的拉取请求（PR），27 条位于仓库主分支，0 条经过验证。有 9 条记录的成绩高于 79.2，而 79.2 正是 swebench.com 上 Verified 榜单的最高成绩（该数据文件最后更新于 2026 年 2 月 26 日）。这 9 条全是自行上报的结果。排名第一的记录成绩为 86.0，但它只在模型卡（model card）的脚注里提到所用的评测框架（harness），榜单行本身没有任何说明。6 个仓库包揽了 78 条记录中的 16 条。

查看原文