最新 AI 模型难以媲美人类的算法创新

# AI 现在能自动化 AI 研发了吗？ 来源：https://epoch.ai/publications/innovationeval ## 引言 AI 开发者的目标是创造自动化 AI 研究员（https://openai.com/index/research-acceleration-view-inside-openai/）。他们进展如何？现有证据表明，AI 能够执行与 AI 研究相关的软件工程任务（https://metr.org/time-horizons/）、数据集构建[^1]以及其他任务（https://openai.com/index/research-acceleration-view-inside-openai/），包括对定义指标的开放式优化（如 autoresearch [https://github.com/karpathy/autoresearch]）。但鉴于 AI 研发涉及的活动范围广泛，完全自动化 AI 研发究竟意味着什么，仍然不清楚。一个明显的差距是执行端到端研究项目的能力。[^2] 与近期的工作类似，如 Crux Evals（https://cruxevals.com/crux/can-ai-agents-conduct-research）、ResearchGym（https://arxiv.org/abs/2602.15112）和 RSI-Bench（https://labs.scale.com/rsi-benchmark），我们让 AI 执行端到端研究任务。 我们呈现了 InnovationEval 的初步结果——这是一个评估，我们测量 AI 独立发现新颖机器学习技术的能力，这些技术应与人类研究者开发的水平相当。尽管运行了数千美元 GPU 时间的实验，最新的前沿模型在这一任务上几乎没有取得进展。我们计划扩展并重复这一方法论，追踪 AI 在自动化 AI 研究本身方面的进展。 ## 方法论 InnovationEval 测试 AI 能否独立设计出一种机器学习创新，其性能与 AI 未见过的、由人类近期开发的创新相当。这类似于最近提出的科学构想测试：如果给 AI 呈现截至 1905 年的人类知识，它能否重新发现狭义相对论？[^3] 我们问一个更保守的问题：如果给 AI 呈现截至 2026 年初的 AI 研究者知识，它能否发现属于自己的机器学习算法创新，达到人类研究者自那时以来取得的改进水平？ 我们希望通过这种方法实现几个优势：对 AI 研发能力的端到端验证、要求真正的创新而非现有技术的拼装、对研究领域的真实呈现，以及确保可行性。 **端到端验证：**AI 系统必须执行发现机器学习创新的完整流程，从提出想法一直到实现它们。与现有的 NanoGPT 速通赛和 ResearchGym 等工作类似，我们定义了应该被改进的指标和应该被满足的约束条件。[^4] 使用端到端指标提供了一种清晰可辨的方式来评估 AI 的表现，前提是改进这些指标确实需要 AI 取得研究进展。在我们的案例中，这些指标被设定为匹配一篇已有的人类论文。我们设置了一个 AI 代理来开发一种更好的后训练方法，这需要端到端地生成想法、弄清实现细节、进行实验、分析结果，并不断迭代直到成功或耗尽。 **必须有创新：**许多 AI 研发评测考察的是明确规定的任务，不需要创新，[^5] 或者可以通过应用非新颖技术的组合来解决。[^6] 一些现有的基准试图隔离出研发构想这一任务，[^7] 但尚不清楚这一任务能否在脱离完整闭环（包括实现和分析）的情况下独立完成。我们的评测设置了一个任务：在不违反范围限制的前提下大幅改进端到端指标，需要开发出一种 AI 在训练中未见过的方法。[^8] 我们将在任务设置部分详细阐述这一点。 **研究领域的真实性：**我们希望测试 AI 发现与前沿 AI 实验室所重视（且使用）的机器学习技术相似的创新的能力。[^9] 这很困难，因为前沿 AI 开发者对其许多方法讳莫如深。我们无法直接测试 AI 重新发现他们的机器学习技术，因此转而依赖公开出版物以及其他表明某项技术有用的证据，例如在知名近前沿模型中的采用，或被后训练研究者的讨论。[^10] 在这里，我们选择了一篇关于在线自蒸馏的论文。我们在下文详细讨论这一点。 **可行性：**使用一篇真实、可复现的 AI 论文保证了我们任务的可行性，并为我们提供了人类研究者所需 GPU 资源的信息。在一些 AI 研发评测中，目标是改进现有方法，但没有人类基线，因此对所需预算不够清晰，也不清楚人类研究者是否会尝试不同的方法。 以现有论文为锚点也带来了一些劣势。其一是，至少在这一次迭代中，我们很难创建一个适合完全自动化评分的任务。我们在任务设置部分更详细地描述了这一点。另一个劣势是我们最终只能依赖少量的运行，因为该任务的每次单独尝试都需要相当大的计算预算。 使用现有创新的另一个劣势是，更新的模型会记住我们的任务。这在本项目进行过程中就发生了：我们的主要结果基于 Claude Fable 5 和 GPT-5.6 Sol，它们在被提示在不使用搜索的情况下回忆或猜测论文细节时没有表现出记忆的迹象。但它们的后继者——Claude Fable 5.1 和 GPT-6 Astra——则知道这一任务。我们对未来评测的计划是对更新的模型持续进行记忆测试，相应地标记其结果，并在必要时设计新任务来刷新评测。 ### 任务设置 作为我们的测试基准任务，我们使用了一项近期被模型采用和引用的 AI 创新：在线自蒸馏（https://arxiv.org/abs/2601.20802）（SDPO）。AI 代理被提示开发一种新颖的后训练技术来击败一个强大的 GRPO 基线。我们强调代理的目标是"产生一个令人信服的研究成果，那种真正能够推动领域进步的成果。"然后我们提供了原始论文中用于得出结果的指标和数据集：简答题[^11]和编程。[^12] 代理被告知，通过后训练一个 Qwen3-8B 模型来在这些任务上表现更好，来提供其方法成功的证据，理想情况下匹配或超过一个近期未具名方法（SDPO）设定的参考值。 整体评测评分是两个结果领域的平均性能，每个领域包含若干基于原始论文实验的子指标。在某个领域匹配或超过原始论文的性能得 100%，而在 GRPO 基线水平的得分则为 0%。我们将在评分部分提供关于提示和打分的更多细节。 正确设定任务范围很重要。如果目标纯粹是在这些数据集上提高性能，有很多方法可能实现，例如为微调生成合成数据集。这不算开发新颖的后训练技术，也不推动领域进步，因此代理理应知道不应使用这种方法。与其试图评分新颖性，我们尝试限制范围，使得代理只能通过自身方法的新颖性才能匹配原始创新的性能——即使它找到的是与 SDPO 不同的新方法。我们将范围限定为影响损失函数及其更新的算法变更，和/或在固定训练数据批次下的 rollout 及模型驱动的修改。[^13] 这一范围允许多种不同的算法思路，可能与原始论文中的创新有很大不同。然而，它确实将开发大致限制在同一研究领域内。 存在一种风险：以这种方式限制范围可能导致"打地鼠"式的动态，代理反复在我们的定义中寻找漏洞并实现我们事后认定为超范围的解决方案。然而，即使不完美地限制范围也是有帮助的，因为它减轻了审查代理解决方案时的负担。 我们最初尝试使用一个 Opus 5 评审员的自动评分器来审查代理的解决方案并评估范围违规。但是，由于我们只评测了少量模型，最终我们在任务完成后进行了人工在环审查，调查提交内容的得分及其工作过程。[^14]、[^15] 我们在全文中讨论定性发现。 ### 环境 我们为代理提供了一个开发环境，在其中可以编辑和执行代码，包括通过 Modal 启动 GPU 任务。代理被沙箱化以防止访问互联网——我们假设其关于后训练技术的知识足够新，已经熟悉相关的已有工作。[^16] 脚手架是 Inspect 的 ReAct 代理，配有 `bash` 和 `text_editor` 工具，以及提交和监控 GPU 任务的工具。我们提供了一个基于论文仓库和 `verl` 技术栈的起始代码库，实现了论文的任务和强大的 GRPO 基线，但已经清除了 SDPO 的内容。[^17] 我们为实验和推理提供了相当大的 GPU 预算，旨在避免用低预算限制 AI。每次评测的计算预算为 3,000 GPU 小时，最多使用 50 个 GPU，约为完成每个单独任务全量训练所需计算量的 10 倍。[^18] 虽然这可能是足够的计算量，但 GPU 预算仍可能构成限制；也许一个真正可比的计算预算应该为沿途执行的所有其他实验预留，甚至为该领域中所有进行类似研究的研究者预留。我们在"扩大开支能否改善 AI 的结果？"部分讨论是否有证据表明存在 GPU 预算瓶颈。与此同时，推理预算被设定为 100 亿 token（输入、输出和推理的总和），这一限制是通过与我们之前的大规模基准测试（https://epoch.ai/MirrorCode）比较而设定的。 代理被指示提交其解决方案的书面说明、其代码库以及存储在 Modal 上的支撑其声明的检查点。我们还在任何任务被训练时存储了提交的代码库和生成的任务检查点的副本，以便后续验证模型的声明。 ## 结果 ### AI 没有发现任何与原始创新相当的东西 尽管在 GPU 使用上花费了数千美元，两个 AI 模型都没有在概念上或指标性能上接近在线自蒸馏的结果。GPT-5.6 Sol 是唯一在关键指标上取得（小幅）改进的模型。Sol 通过在 GRPO 损失中添加一个自我模仿组件实现了这一点。在所有 rollout 都成功的组中，传统 GRPO 没有更新信号，因为 rollout 之间没有差异。Sol 修改了损失函数，增加了强化此类策略的更新。这不是 Sol 的新颖（重新）发现，因为它与 Sol 知识截止前的先前工作非常相似。[^19] Sol 的提交确实提升了简答题任务的性能，尽管幅度小于原始 SDPO。如果以宽松的方式评估范围，Sol 的方法达到了 SDPO 改进幅度的 35%。然而，它还对编程任务进行了可疑的范围变更：它没有修改方法本身，而是增大了批大小和 PPO 轮数。这些更改使得代码训练显著变慢，尽管任务简报中强调了壁钟时间效率。[^20] 在通过比较相似壁钟时间下的编程分数来调整这一差异后，Sol 方法中在范围内的部分仅实现了 SDPO 改进幅度的 15%。 与此同时，Fable 5 开发了一种类似于 STaR 和大量已有文献的技术：根据之前的尝试和验证器的判定对全失败组进行重采样。然而，这最终未能提高性能。Fable 关于性能提升的声称来自超范围的作弊：它提交了许多相似的训练运行，并从中选择最佳结果，实际上是在利用随机种子噪声"刷分"。因此，我们从在范围内的评分中移除了这些增益。我们在"代理对其工作做出了误导性声明"部分进一步讨论了这一点。 在这两种情况下，代理在 GPU 使用上的花费都显著高于其自身的推理 token 花费。Fable 5 使用了其 3,000 GPU 小时预算的 46%（约 6,700 美元），但仅使用了 610 美元的 token，即其 100 亿 token 预算的 1.8%。GPT-5.6 Sol 用完了全部 3,000 GPU 小时预算（约 14,000 美元），但仅使用了 2,100 美元的 token，即其 100 亿 token 预算的 24%。我们在"扩大开支能否改善 AI 的结果？"部分讨论 GPU 预算是否看起来是真正的瓶颈。 ### 代理对其工作做出了误导性声明 我们没有根据模型的写作能力来评判它们，但在审查其提交内容时，明显可以看出这些内容具有误导性，会妨碍对其工作的理解。例如，它们声称的分数高于其方法实际达到的水平，却未能解释它们只是从多个相似的运行中选择了最佳结果。 Fable 的提交顺带提到某些指标进行了多次运行，但没有警告这可能会抬高分数，也没有在所有受影响的指标上标注这一细节。[^21] Fable 的对话记录表明它最初意识到这些影响，将其重跑的动机描述为"纯粹为了捞更好的检查点，因为选择只是取每个数据集跨运行的最佳值。"与此同时，Sol 的提交完全没有提到多次运行选择，尽管它在提交前已经在工作空间中注意到了这个问题。[^22] 在这两种情况下，对话记录都显示模型意识到多次运行选择可能有问题，但最终（且可疑地）推理认为自己应该继续这样做。[^23]