返回评测
代码生成 代码-科学计算 未饱和 模态 · 代码 任务 · 代码生成 未获取到

SWE-bench Science v1

119 个来自 98 个科研仓库的任务,公开诊断测试 + 隐藏验证器双镜像设计,最强智能体 pass@1 不足 50%

OpenMOSS(复旦大学) ·

考察能力

科学软件修复 领域知识应用 仓库级探索 物理不变量保持 系统集成

构建信息

数据规模
119 tasks / 98 repositories / 20 科学领域
构建方式
三种范式构造:52 issue-driven、49 expert-exploratory、18 engineering-integration;公开环境镜像 + 独立隐藏验证器镜像
评测方式
双容器镜像:环境镜像含代码/依赖/可自测的诊断检查,验证器镜像含参考补丁、私有测试与 grader,仅在提交后运行
核心指标
pass@1(首次尝试完整解决率);公开测试通过率 / 私有测试通过率

模型效果排行

🥇 Claude Code + Opus 5 (max)
47.9% pass@1(公开测试 96.6% / 私有测试 75.1%) 2026-08

为什么重要

科学软件的失败代价与 Web 应用不同。当一个科学计算程序出错,它损害的不只是程序行为,还有支撑科学结论的证据本身。

但现有编码智能体评测几乎只看”最终补丁是否通过测试”这一个聚合数字,无法回答一个更重要的问题:智能体在修复科学软件时,究竟为什么失败。

SWE-bench Science 的贡献有两层:

  1. 它把评分测试彻底藏起来。公开发布物里没有参考补丁、没有私有测试、没有 grader、没有智能体轨迹。这是对 SWE-bench Verified 所受批评的直接回应——OpenAI 自己在推出 Verified 时就承认存在测试过于具体、任务描述欠充分、环境不稳定等问题,后续分析更发现约七分之一的 Verified 任务是拿一个不匹配的补丁来评分的。
  2. 它的隐藏测试检查的是物理与数学不变量。论文举的例子是 FFT 网格奇偶性、k 点排序、晶胞几何、MDF 积分。这些断言不是代码风格检查,而是软件为了保持正确所必须守住的约束——你完全可以在让所有可见测试保持绿色的时候,悄悄破坏倒空间里点的排序。对普通测试套件来说这是成功,对物理学家来说这是一颗会污染下游所有结果的 bug。

构建方式

任务构成

119 个任务来自 98 个 GitHub 仓库,横跨 20 个科学领域,按三种范式组织:

范式数量含义
Issue-driven52从真实 issue 出发的修复任务
Expert-exploratory49由领域专家构造的探索性任务
Engineering-integration18跨模块的系统集成任务

双镜像抗污染架构

这是整个设计里最关键的一笔。每个任务拆成两个容器镜像:

  • 环境镜像:代码、依赖,以及一个智能体在工作时可以随时运行的诊断检查。智能体用它判断症状是否消失。
  • 验证器镜像:真正的测试与 grader。它只在提交之后才运行。

结果是,没有任何人能在构建解决方案时看到自己将被如何评分。这把”针对测试拟合解法”这条路堵死了。

需要说明的是,这是一阶设计声明而非经过审计的安全保证:保留测试的质量取决于维护者的纪律,而任何隐藏基准都会随着提交累积和结果讨论而缓慢泄漏。作者对此并不回避。

关键发现

1. 公开与私有测试之间存在巨大鸿沟

排行榜榜首的成绩是公开测试通过 96.6%,私有测试通过 75.1%,而首次尝试完整解决只有 47.9%。

同一个系统能让你看得见的检查通过 97%,却完成不了半数的工作。这两个数字之间的落差就是这份基准的全部意义:可见的诊断检查只告诉你”症状消失了没有”,隐藏的验证器问的是”这个修复本身对不对”。类比很直白——一个是背熟了练习题的学生,一个是理解了材料的学生,在练习题上他们一模一样,换掉数字就只剩后者活下来。

2. 最强智能体 Claude Code + Opus 5 (max) 的 pass@1 仍低于 50%

论文明确指出,即便表现最好的智能体,pass@1 也不到 50%。作为参照,同期通用 SWE-bench Verified 的头部成绩已在 95% 以上。通用仓库修复能力与科学仓库修复能力之间的落差,比大多数人以为的要大得多。

3. 四类反复出现的失败机制

失败审计给出四种模式,比一个分数本身更有诊断价值:

  1. 科学知识或抽象能力缺失:缺少正确的领域概念框架。
  2. 探索方向错误或只做表面修复:治标不治本。
  3. 修复覆盖不完整或系统集成缺失:修好了一个调用点,漏掉系统其余部分。
  4. 无法把科学原理泛化到未见过的情形。

关键在于,这四类全都是知识失败,而不是编码失败——这恰恰印证了那个判断:写 Python 从来不是科学软件里最难的部分。

4. 一个反直觉的消融:科学上下文并非总是有用

作者在 91 个任务上做了配对消融——保留仓库和可执行工程上下文,只抽掉显式的科学指导。结果是科学知识并非 uniformly 有益:

  • 对一个模型,补充科学信息略微提高了公开与私有测试分数,却降低了首次尝试成功率(同时减少了 token 消耗)。
  • 对另一个模型,三项指标都改善了,但 token 成本上升。

作者的解读是:科学上下文在扎实对齐时能帮助约束修复方向,在错位时反而会把智能体锚定到错误的框架上。所以你没法简单地塞给模型一本教科书就指望差距收窄——配错上下文会让一个自信的智能体自信地犯错。

局限性与展望

  • 一阶自评:这是作者对自己基准的评估,双镜像防御是设计声明而非经过第三方审计的结论。
  • 隐藏测试终将泄漏:随着提交累积和结果被公开讨论,held-out 测试的有效性会衰减。
  • 规模偏小:119 个任务分布在 20 个领域,平均每个领域不足 6 个任务,分领域统计的置信区间会很宽。
  • 早期关注度有限:论文在 Hugging Face 上的页面显示关注度尚不高,社区复现与第三方验证还不足。

关联基准

参考链接

科学软件 编码智能体 隐藏测试集 抗污染 仓库级 OpenMOSS