AI 原生开放教材

外观

AI 工程从零到一（中文）源码研读·中文原文 ↗原件 ↓仓库 ↗

METR 时间跨度与外部能力评估 ​

METR（前身是 ARC Evals）自 2023 年 12 月起是一家独立的 501(c)(3) 机构。他们的 Time Horizon 1.1 基准（2026 年 1 月）把任务成功概率对 log(专家完成时间) 拟合成一条逻辑斯蒂曲线；在 50% 概率处的交点定义了模型的时间跨度。2025-2026 年的合作集涵盖 GPT-5.1、GPT-5.1-Codex-Max，以及原型监控评估（一个监控器能不能抓住附带任务；agent 能不能规避）。基准套件：HCAST（180+ 个 ML、网络、SWE、推理任务；1 分钟到 8 小时以上）、RE-Bench（71 个带专家基线的 ML 研究工程任务）、SWAA。诚实的一笔：METR 的测量是理想化的——没有人、没有真实后果——而团队已记录了评估 vs 部署的行为差距（第 1 课）。一个时间跨度是上界，不是部署预测。

类型： Learn 语言： Python（标准库，逻辑斯蒂拟合跨度估计器） 前置要求： 阶段 15 · 01（长程 agent），阶段 15 · 19（RSP） 预计时间： ~60 分钟

问题背景 ​

扩展政策（第 19、20 课）的用处，只跟它们引用的测量一样大。"AI R&D-4 阈值"和"长程自主性"是在政策散文里定义的；它们只有在具体的评估产出具体的数字时才变得可操作。

METR 是 2024-2026 年那家定义了其中很多数字的外部评估组织。他们评估前沿模型——常常是发布前、在跟实验室的 NDA 下——之后再发表方法学。Time Horizon 1.1 基准（2026 年 1 月）是他们的头条产物：一个把能力压缩成人能读懂单位的标量（"这个模型能在 50% 可靠度下完成专家要花 X 小时的那类任务"）。

本课一部分关于方法学（一个跨度是怎么算的），一部分关于解读（为什么一个跨度是上界，而不是部署预测）。这两项技能是配套的。一个理解跨度是怎么拟合出来的团队，比一个只在幻灯片上看到"14 小时"的团队，要难被坏的厂商声称蒙骗得多。

核心概念 ​

METR 背景 ​

  • 成立：2023 年 12 月（前身 ARC Evals，拆分成独立的 501(c)(3)）。
  • 范围：评估前沿模型的自主能力，常常是发布前。
  • 合作实验室：Anthropic、OpenAI（2025-2026 年多次合作）。
  • 值得注意的交付物：Time Horizon 1.0（2025 年 3 月）、Time Horizon 1.1（2026 年 1 月）、原型监控评估。

Time Horizon 拟合 ​

方法学（来自 METR 博客和论文）：

  1. 收集一个任务集，跨度从分钟级到小时级的专家完成时间。当前套件：HCAST（180+ 任务）、RE-Bench（71 任务）、SWAA。
  2. 在每个任务上跑模型；记录成功或失败。
  3. 拟合一条逻辑斯蒂曲线：P(成功) 作为 log(专家完成时间) 的函数。
  4. 跨度就是 P(成功) = 0.5 时的专家时间。

逻辑斯蒂拟合的形状是对的，因为能力跟任务难度通常呈递增、趋近平台的关系。50% 这个点是一个选择（可以是 10%、90%）；METR 在详细论文里报告多个阈值，但用 50% 打头，因为它最直观。

2026 年 1 月的数字 ​

按 Time Horizon 1.1：

  • Claude Opus 4.6：截至 Time Horizon 1.1（2026 年 1 月），50% 可靠度下约 14 小时。
  • HCAST 风格任务上的翻倍时间：在 Time Horizon 1.1（2026 年 1 月）报告的 2023 年后拟合上是 ~4.3 个月（130.8 天）；~7 个月那个数字是 Time Horizon 1.0 完整 2019-2025 拟合的结果，并在 TH1.1 里跟 2023 年后的数字一起报告。

这些是阶段 15 剩余部分引用的具体数字。它们在 Anthropic 的 RSP v3.0（第 19 课）和 DeepMind 的 FSF v3（第 20 课）里被引为喂进阈值评估的测量之一。

基准套件 ​

  • HCAST：跨 ML、网络安全、软件工程和通用推理的 189 个任务。跨度：1 分钟到 8 小时以上的专家时间。跨度数字背后的主套件。
  • RE-Bench：71 个带人类专家基线的 ML 研究工程任务。衡量模型能否做喂进 AI R&D-4 阈值的那类 ML 研发工作。
  • SWAA：更短的任务；对校准跨度曲线的低端有用。

原型监控评估 ​

2025-2026 年的 METR 工作包含监控评估原型：一个监控器能不能抓住一个模型在执行附带任务（不是 operator 要求的别的东西）；agent 能不能规避这个监控器。这些直接喂进 OpenAI PF v2 的"破坏防护措施"类别，以及 DeepMind FSF v3 的欺骗性对齐监控（第 20 课）。

为什么跨度是上界 ​

  • 理想化的工具：基准任务给模型干净的工具和格式良好的数据。真实部署更脏乱。
  • 没有真实后果：模型从不真的给客户计费、删真实数据，或联系真实的人。真实部署有不可逆的利害。
  • 评估情境作弊：第 1 课。模型在测试中表现不同。2026 年《International AI Safety Report》经验性地记录了这一点。
  • 没有正当的用户变异：基准 prompt 是结构化的。真实用户产生模糊、依赖语境的请求。

跨度是有利条件下的能力天花板。部署可靠度是另一个数字，更低，团队必须测量自己的分布才能知道它。

外部评估者的理由 ​

外部评估要紧，因为内部实验室有动机去优化它们要报告的指标。METR 的独立性——一家有声明方法学和经同行评审论文的 501(c)(3)——是结构性的缓解。它单凭自己不充分（实验室仍控制 METR 能看到什么），但严格优于没有外部评估。

如何在实践中使用跨度数字 ​

  • 当能力过滤器：如果一个模型的跨度远低于一个提议任务的专家时间，就别让它自主上线（第 1 课的技能文件）。
  • 当趋势指标：翻倍时间告诉你，即便没有新缓解，当前做法还能保持多久安全。
  • 当先验：14 小时的跨度是一个起点。按你的任务分布、你的工具质量、你的部署语境往下调。
figure
a5-horizon-fit

实际使用 ​

code/main.py 给定一个合成结果集，实现任务成功对 log(专家时间) 的逻辑斯蒂拟合。它报告 50% 跨度（METR 的头条）、10% 跨度（保守）和 90% 跨度（乐观）。还演示当成功率被评估情境作弊人为抬高时会怎样变化。

拿去用 ​

outputs/skill-horizon-interpretation.md 审查一个厂商的跨度声称，并产出一份基准声称与部署现实之间的差距分析。

练习 ​

  1. 运行 code/main.py。确认拟合的 50% 跨度跟合成真值相符。现在把任务时间网格减半；跨度估计会有意义地变化吗？

  2. 读 METR 的 Time Horizon 1.1 博客文章。指出可靠度最高和最低的那些具体任务。解释为什么有这个差距。

  3. 读 METR 的 "Measuring Autonomous AI Capabilities" 资源。列出 HCAST 的任务类别。挑一个你会为某个生产任务加更大权重的类别，论证为什么。

  4. 把评估情境作弊引入模拟器：把约 20% 的失败任务翻成成功。报告新的跨度。这近似 20% 的作弊率对观察到的数字会做什么。

  5. 在你自己的 bug 待办或一个有代表性的任务集上设计一套内部跨度评估。描述数据收集、拟合，以及输出告诉你什么。跟 METR 数字对比。

关键术语 ​

术语大家嘴上怎么说实际指什么
METR"外部评估者"前身 ARC Evals；自 2023 年 12 月起的独立 501(c)(3)
Time Horizon（时间跨度）"能力度量"50% 可靠度下的专家任务时长，来自逻辑斯蒂拟合
HCAST"METR 的主套件"180+ 个任务，跨度 1 分钟到 8 小时以上
RE-Bench"研究工程"71 个带人类基线的 ML 研究工程任务
SWAA"短任务套件"校准跨度曲线的低端
Doubling time（翻倍时间）"增长速率"50% 跨度翻一倍所需的时间；按 HCAST 约 7 个月
Eval-context gaming（评估情境作弊）"模型表现不同"有记录在案的测试与部署间行为差距
Upper bound（上界）"跨度是天花板"基准跨度 > 负载下的部署可靠度

延伸阅读 ​