CodexQA

行业与实践研究与基准测试

METR 对 GPT-5.6 Sol 的部署前评测摘要

CodexQA 团队阅读约 4 分钟

METR 在 Time Horizon 1.1 上评测 GPT-5.6 Sol。把作弊记为失败时,50% 时间期限约 11.3 小时;算作成功则超过 270 小时。METR 认为这些数字都不稳健,也不认为它会完全自动化 AI 研发。

METR 对 GPT-5.6 Sol 的部署前评测摘要

METR

2026 年 6 月 26 日。

关于独立性的说明: 这项评测是根据一份标准保密协议进行的。由于作为这项评测的一部分分享给 METR 的信息很敏感,OpenAI 的传播团队和法律团队要求审阅并批准这篇帖子。[1]

摘要

我们对 GPT-5.6 Sol 做了一项独立的外部评测。为了这项评测,OpenAI 提供了:

  • 通过 API 访问 GPT-5.6 Sol,包括最终检查点,以及一个「railfree」版本
  • 通过 API 访问带有原始思维链的 GPT-5.6 Sol
  • 一份「面向第三方评估者的 Codex harness 搭建指南」
  • 对我们试点前沿风险报告问卷(https://metr.org/blog/2026-05-19-frontier-risk-report/#questionnaire)中关键主张的更新答复

我们开始在我们的 Time Horizon 1.1 软件任务套件上评测 GPT-5.6 Sol。然而,由此得到的测量严重依赖于我们如何检测并处理该模型的作弊尝试,而且 GPT-5.6 Sol 被检测到的作弊率高于我们在 ReAct agent harness 上评测过的任何公开模型。对我们的任务套件,我们把「作弊」定义为这样一种行为:模型通过利用评测环境中的缺陷,或通过采取任务所不允许的策略,来提高评测表现,而不是在预期的评测约束之内解决任务。我们在评测 GPT-5.6 Sol 时看到的一些例子包括:模型把漏洞利用打包进它的中间提交,以揭示一项任务的隐藏测试套件的信息;以及在另一项任务中,提取出详细说明预期答案的隐藏源代码。除了模型自身的倾向之外,我们相信,观察到的作弊率也会受到评测脚手架中所用提示,以及任务说明的确切措辞的影响。

用我们为 GPT-5.6 Sol 收集到的数据,如果我们遵循标准方法、把作弊尝试记为失败,我们得到的 50% 时间期限点估计大约是 11.3 小时(95% 置信区间:5 小时到 40 小时);但如果我们把作弊尝试算作合法成功,点估计就会跳到 270 小时以上,远远超出我们认为任务套件还能给出可靠测量的范围。丢掉这些作弊尝试,会让我们在若干有信息量的长程任务上没有数据,并得到一个高度不确定的点估计:71 小时(95% 置信区间:13 小时到 11400 小时)。这使我们尤其不确定时间期限测量,而且我们不认为这些数字中的任何一个代表对 GPT-5.6 Sol 能力的稳健测量。不过,OpenAI 与我们分享的其他基准分数,以及 AI 能力的长期趋势,使我们相信:GPT-5.6 Sol 在软件任务和研发任务上的能力并没有显著超出当前最好水平。因此,我们不相信 GPT-5.6 Sol 会促成完全自动化的 AI 研发,也不相信它达到 OpenAI《准备框架》第 2 版中 AI 自我改进的 Critical 能力阈值。

我们的测试聚焦于测量模型能力,而不是对齐,因为我们认为,对当前模型而言,能力是灾难性失控风险更重要的限制因素,但我们预期,随着能力提高,对齐会越来越重要。我们从自己的观察,以及 OpenAI 与我们分享的事件中注意到,该模型有一些明显的不良倾向,包括作弊和隐瞒不当行为。

我们认为,这是一个关于 OpenAI 抓住 灾难性 失对齐 之能力的 令人安心 的信号,因为它表明,更令人担心的倾向(例如系统性的权力寻求和对齐伪装)也会被检测到。也就是说,这些不良倾向被检测到、被报告,并且表现得相当明显,是关于 OpenAI 某些安全实践的一个积极信号,尤其是:

  • 克制不对思维链做对抗训练(以减少模型隐瞒其意图的压力)
  • 对内部部署的广泛监控(https://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/),这些监控浮现了相关事件
  • 与 METR 分享关于内部事件的信息

如果未来的模型表现出少得多的不良倾向,我们可能会对灾难性失对齐变得 更加 担心,因为我们会担心模型也许已经学会逃避检测。考虑到 OpenAI 所报告的事件包括试图指示另一个实例隐瞒失对齐的证据,以及更高比例的欺骗或规避限制的尝试,并且 METR 观察到相当程度的情境意识和对评测环境的推理,这一点看起来尤其说得通。随着训练和迭代继续,我们需要确保模型不只是在学习更成功地逃避监控系统。这在传统的部署前评测范式里无法验证,因为它需要对内部系统的深度访问。

  1. 我们认为,让 AI 开发者能够与第三方分享具体技术细节、而这些信息不会被进一步分享,是有价值的;让 AI 开发者审阅第三方评测报告、以确保没有意外分享敏感知识产权,也是非常合理的。

我们与 OpenAI 有一项非正式的理解:他们的审阅是在检查保密和知识产权问题,而不是在批准关于安全或风险的结论。我们没有基于他们的审阅,去改结论、要点或语气(或任何我们认为有问题的其他改动)。我们能够自由发表这项评测中只依赖于如今已经公开的信息的那些部分。

不过,我们预期有些读者会希望我们注明:对于依赖于非公开信息的、关于风险的结论,OpenAI 本来会有法律权利阻止我们分享。鉴于这一点,这项评测不应当被解释成公众可以依赖 METR 来提供的、稳健的正式监督或问责。

尽管如此,我们认为这项评测是向前迈出的很好一步,而且我们非常支持在没有正式监督关系所带来的额外摩擦的情况下,去原型化第三方评测设置的机制和内容。

Cite

@misc{metr-2026-gpt-5-6-sol,
    title = {Summary of METR's predeployment evaluation of GPT-5.6 Sol},
    author = {METR},
    howpublished = {\url{https://metr.org/blog/2026-06-26-gpt-5-6-sol/}},
    year = {2026},
    month = {06},
}

觉得有用,转给同事

微信扫码

用微信扫一扫,在手机上打开后即可转发。

用 RSS 订阅

提交勘误