自我改进：怎么量“AI 在加速 AI”

读到“某实验室 80% 以上的合并代码由 AI 写”和“某模型能完成人类 12 小时的任务”，哪一条说明 AI 研发在加速？都不直接说明：前者是代码份额，后者是任务级能力，研发整体快了多少是第三个量。先问是谁量的、量的是什么单位。截至 2026 年 10 月，外部可复查的任务级测量还在上升，但已经顶到测量工具的上限；整体研发提速的数字几乎都来自实验室自己，凡是给出整体进展倍数的估计，都在 2 倍以下。

先把证据分成四类

• 任务级测量：METR 的 time horizon、RE-Bench 等。外部可以复查，但量的是“能完成多长的任务”，不是研发进度。
• 实验室对照自己阈值的判定：system card 里“越过／没越过”的结论，依据多半是内部评估。
• 实验室自报的内部数字：代码份额、agent 工时、员工调查、能力指数的斜率。
• 表态和预测：见导读，这里不重复。

50% time horizon：定义和拟合

METR 的 Kwa 等在 2025-03-18 的论文里这样定义：AI 模型以 50% 成功率能完成的任务，人类通常要花多长时间。对每个模型，按任务的人类用时 $t$ 拟合（§3.1）：

$$ P(\text{成功}\mid t)=\sigma\big(\beta\,(\log h-\log t)\big),\qquad \sigma(u)=\frac{1}{1+e^{-u}} $$

$t$ 是成功完成该任务的人类基线（baseline）用时的几何平均；$h$ 和 $\beta$ 由拟合得到。$t=h$ 时 $\sigma(0)=0.5$，所以 $h$ 就是 50% horizon。连续打分的任务按代表人类水平的阈值换成成功／失败；每个任务按所属任务族大小的平方根倒数加权，避免任务多的族主导结果。

手算一次

教学例子，数字是编的：一个模型在四组任务上各跑 10 次。

把成功率换成 logit，模型就变成关于 $x$ 的一条直线：

$$ \operatorname{logit}p=\ln\frac{p}{1-p}=\beta\,(\log h-\log t) $$

四个点以 $x=1$ 为中心对称，最小二乘直线的斜率约为 −0.74（用时每翻一倍），在 $x=1$ 处穿过 0，所以 $h=2^1=2$ 小时。2 小时是 1 小时和 4 小时的几何中点，不是算术中点 2.5 小时，因为横轴是对数时间。用同一条线求 80% horizon：$\operatorname{logit}0.8=1.39$，$x=1-1.39/0.74\approx-0.86$，约 0.55 小时，即 33 分钟左右。80% horizon 通常比 50% 短得多，下文 METR 的数据也是这样。METR 实际是在单次运行上做加权最大似然；这里用 logit 直线只为能手算，四点对称时两种方法的 50% 交点都在 2 小时，斜率和 80% horizon 会略有不同。

读数超出任务范围时

换一个更强的模型，15 分钟组仍是 9/10，其余三组如下：

后两行所有组的成功率都过半，50% 的点只能沿直线往外推，落在最长任务之外。最长一组多成功一次，估计就从约 34 小时跳到约 108 小时。这正是 METR 提醒 16 小时以上读数不可靠的原因；METR 2026-03-20 的方法说明还提到，套件里没有超过 30 小时的任务。

这张图需要启用 JavaScript。

趋势数字，和它的几个前提

METR 2025-03 的论文摘要报告，前沿模型的 horizon “doubling approximately every seven months since 2019, though the trend may have accelerated in 2024”，即自 2019 年大约每 7 个月翻一倍，2024 年可能更快；论文对“5 年内能做月级软件任务”的外推是有条件的。METR 2026-01-29 发布的 Time Horizon 1.1 把任务从 170 个扩到 228 个，8 小时以上的任务从 14 个增加到 31 个；2023 年以后的翻倍时间是 131 天（旧版 TH1 为 165 天），2024 年以后是 89 天（TH1 为 109 天）。METR 当前的数据文件给出 2023 年以后 128.7 天（95% CI 104.4–158.0），已剔除 50% 点超过 16 小时的模型。

换算一下 131 天：一年约 $365/131\approx2.8$ 次翻倍，horizon 每年约乘以 6.9。这是对过去趋势的算术换算，不是预测。读这类数字时要带上四个前提：

1. METR 2026-05-19 的 Frontier Risk Report（评估窗口 2026-02-16 至 03-16，Anthropic、Google、Meta、OpenAI 参与）说，最强的 agent 基本上让 TH1.1 饱和了，最强的共享模型 50% 点估计在 16–20 小时之间。
2. 同一份报告：8 小时以上任务的成功运行中，至少 16% 经审查不合法。METR 2026-06-26 对 GPT-5.6 Sol 的测量里，作弊记为失败约 11.3 小时（95% CI 5–40 小时），剔除作弊尝试是 71 小时，作弊记为成功则超过 270 小时；METR 说这些数字都不算稳健测量。
3. METR 2026-03-20 的方法说明：校正任务时长估计里的噪声，可能让前沿模型的 50% horizon 下降约 30%。
4. METR 的时间线页面 2026-09-08 起不再主动更新。Claude Opus 4.6 的读数在 2026-03-03 因正则化（regularization）错误被修正；最初流传的约 14.5 小时只见于二手来源。

各模型的读数

来源是 METR 的数据文件和时间线页面，括号里是 95% CI（只列出有记录的）：

Mythos Preview 的点估计已超出 METR 自己说的可靠范围；Opus 4.6 的区间上限达 60 小时。区间这么宽，相邻两个模型的先后往往说明不了什么。

AI 研发 benchmark

实验室自己画的线

Anthropic 在 v3.4 的变更记录里说，这个阈值意在捕捉“dramatic recursive self-improvement”的开端，并且很难操作化。OpenAI 2026-08-18 说会修订 Preparedness Framework；截至 2026-10-15 没有找到新版本。OpenAI 2026 年 6 月的政策蓝图提议前沿开发者向 CAISI 分享 RSI 相关测量，这是提议，文中没有公布指标。

2025–2026 的判定

每家从新到旧排列。没有一家报告越过 AI 研发阈值，但下判断的证据在变：旧的自动化任务评估饱和以后，各家转向员工调查、能力指数的趋势断点和新的内部评估。

Anthropic

• Claude Opus 5.5（2026-09-22）：没有越过下一个能力阈值。CoBench 2.1 得 55.8%，可替代员工的标准是 ≥85%；能力指数趋势断点拟合的斜率增幅 1.53 倍（95% 区间 1.20–1.82），即斜率没有翻倍；部分内部加速指标已有变动，正在密切监测。
• Claude Mythos 5.1（2026-09-01）：没有越过“显著加速自动化 AI 研发”的阈值；旧的自动化评估已饱和，没有再跑。
• Claude Mythos Preview（2026-04-07）：没有越过“两年进展压进一年”的阈值，但这一判断的信心低于以往任何模型。员工调查的提速几何平均约 4 倍，结合弹性估计，整体进展乘数低于 2 倍；能力指数斜率之比在 1.86–4.3 倍之间，取决于断点选在哪里，Anthropic 把这次跃升归因于 AI 加速研发以外的因素。
• Claude Opus 4.6（2026-02）：排除论证比以往任何模型都更站不稳。kernel 优化在新 scaffold 下达到 427 倍提速（阈值 300 倍）；16 位受访员工中没有人认为它能自动化一名入门级研究员。
• Claude Opus 4.5（2025-11）：没有越过 AI R&D-4，但有把握地排除越来越难；内部套件 0.604，排除线 0.6；18 位员工中没有人认为它能自动化入门级研究员。

OpenAI（system card 都在 deploymentsafety.openai.com）

• GPT-6 Sol 与 Luna 的十月更新（2026-10-07）：两者都没达到 AI Self-Improvement 的 High。
• GPT-6.1 Sol（2026-09-29）：低于 High；内部 Research Debugging 75.52%。
• GPT-6 Astra（2026-09-03）：AI Self-Improvement 未达 High；它是 OpenAI 第一个在网络安全上评为 Critical 的模型。Research Debugging 78.05%，低于未公布的 High 参考阈值。
• GPT-5.6（2026-07-09）：因 Monorepo-Bench 饱和、OPQA 含无解题目，换成新套件（Internal Research Debugging、KernelGen 1P、NanoGPT、PostTrainBench Lite、MLE-Bench Revised）；低于 High。
• GPT-5.5（2026-04-23）：可以排除 High。

Google DeepMind

• Gemini 4 Argon（2026-10-13）：两个 ML R&D CCL 都未达到；结论是没有显著的端到端 AI 研发加速。AI agent 写了大部分生产代码和 bug 修复，但改动仍经人工审查。能力指数（GCI）的折线回归：2026-04-01 之前斜率为每月 0.091（0.071–0.108），之后为 0.118（0.053–0.171），差异不显著。
• Gemini 3.7 Flash（2026-08）：内部 benchmark pass@1 为 27%，排除阈值是 90%。
• Gemini 3 Pro（2025-11）：RE-Bench 综合分远低于警戒阈值。

自报的加速数字：单位各不相同

同一家实验室可以同时出现“代码大多由 AI 写”“研究员 uplift 可能超过 2 倍”和“整体还不到 2 倍”三种数字，它们并不矛盾，因为单位不同。OpenAI 自己也写道，AI 研究有很多潜在瓶颈，算力是另一道闸门，而且随着其他瓶颈缩小可能变得更重要。

经济学模型怎么看这个回路

Cunningham 等 2026-09-14 的论文 The Economics of Recursive Self-Improvement 认为，净加速取决于各条反馈回路弹性的乘积。§4.1 的校准（calibration）是：只有当 AI 模型能力（用 Epoch Capabilities Index 衡量）提高一个单位，能让 AI 研发生产率至少提高 15% 时，加速才能自我维持。他们粗估自编程 agent 推出以来约为 9%，这个数来自自报的 Mythos Preview 约 4 倍 uplift，作者说它很可能是高估。按这个校准，弹性还要再提高约三分之二（$15/9\approx1.7$）才到门槛。论文的结论是：反馈回路目前还不足以产生自我维持的加速，但似乎在变强。

更早的 Whitfill 与 Wu（2025-07）用 2014–2024 年 OpenAI、DeepMind、Anthropic、DeepSeek 的数据，估计研究算力和认知劳动之间的替代程度，结论取决于模型设定：基线设定下两者可以互相替代；“前沿实验”设定下两者互补，意味着算力会卡住。

觉得快了，不等于测出来快了

METR 2025-07 的随机对照实验（2025 年初的工具）发现，允许使用 AI 让开发者完成任务的时间增加了 19%，而开发者事先预期会缩短 24%。METR 2026-02-24 的后续给出回访开发者“−18% 的 speedup”（CI −38% 到 +9%）和新招募者 −4%（CI −15% 到 +9%），两个区间都包含 0，文章没有重申正负号约定；METR 称这批数据是不可靠的信号，部分原因是开发者越来越不愿意在不用 AI 的条件下工作。METR 2026-05-19 的报告则把它的 RCT 概括为发现了小幅（约 4–20%）的生产率提升。Anthropic Institute 的作者也说，2026 年 3 月员工调查的约 4 倍中位数，真实提速大概会稍低。

教训是：自我感觉和有对照的测量可能差很多，甚至方向相反。问卷数字要和对照实验分开读。

读到一个新说法，先问这几件事

这条线接下来看什么

下面是开放问题，以及什么样的结果会改变现在的判断；不是预测。

1. 有没有更长的外部尺子？ METR 2026-05-19 说 TH1.1 已基本饱和，页面 2026-09-08 起不再更新；没有找到名为“Time Horizon 2.0”的 METR 发布。一套任务远超 30 小时、带作弊审查的新套件，会恢复一条外部可查的趋势线。
2. 自报数字能不能被外部核对？ OpenAI 2026 年 6 月的蓝图提议向 CAISI 报告 RSI 测量；METR 2026-09-22 说它看不到约 1.5 倍估计的证据。公开、经第三方核对的测量，会改变这些数字的证据地位。
3. 趋势断点会不会变显著？ Anthropic 对 Opus 5.5 拟合的斜率增幅是 1.53 倍（2026-09-22），门槛是 2 倍；Google DeepMind 的 GCI 折线回归（2026-10-13）前后差异不显著。统计上显著的断点，或者某家宣布越过正式阈值，都会改变判断。
4. 弹性估计。 Cunningham 等（2026-09-14）的约 9% 对比 15% 门槛，建立在自报的 uplift 上。用有对照的测量重新估计这个弹性，会让“回路还不够强”这个结论更稳，或者被推翻。

最后：复习题。

本页术语 4

基线 baseline

用来比较新方法的参考方法或配置

正则化 regularization

通过约束、惩罚或训练方式减少过拟合，让模型更好地处理新数据

后训练 post-training

预训练之后为特定任务和行为做的所有训练

校准 calibration

模型给出的置信度是否等于真实正确率