如果你曾经尝试过从 GitHub 仓库复现机器学习论文的结果，你就知道这有多痛苦。过程通常是这样的: 你克隆了仓库，安装了依赖项，然后立刻遇到 ModuleNotFoundError。你修复了这个问题，把三个包降级，接着又遇到了 CUDA 版本不匹配的问题。三个小时过去了，你甚至还没开始运行训练脚本。

随着大型语言模型 (LLMs) 在编写代码方面变得越来越熟练，一个诱人的问题出现了: 我们能否利用 AI 智能体 (Agent) 来自动化这个混乱且令人沮丧的过程?

LLM 能否自主克隆研究仓库，搞定那些缺失文档说明的依赖项，配置数据加载器，并复现论文结果？这正是艾伦人工智能研究所 (Allen Institute for AI) 和华盛顿大学的研究人员在他们的新论文 SUPER 中试图解决的问题。

在这篇文章中，我们将深入探讨“现实场景中 (in-the-wild) ”的研究代码所面临的挑战，探索 SUPER 基准测试的独特架构，并分析为什么即使像 GPT-4 这样强大的模型也很难完成这些任务。

问题所在: 研究代码是“狂野”的

以往的 AI 编程智能体基准测试 (如 HumanEval 或 ML-Bench) 通常侧重于定义明确的问题或流行的、维护良好的库。如果你要求智能体“使用 PyTorch 训练一个 ResNet”，它在预训练阶段见过成千上万个关于该主题的教程。

然而，真正的研究代码是完全不同的。它们通常:

  • 低关注度 (Low-profile) : 仓库可能只有很少的 Star，且社区支持极少。
  • 缺乏文档 (Undocumented) : requirements.txt 文件经常缺失或过时。
  • 复杂: 运行实验需要修改多个文件，处理数据路径，并管理截然不同的“设置”和“执行”阶段。

研究人员发现，复现实验最困难的部分不仅仅是编写代码，而是搭建环境并执行任务 。

Figure 1: An illustration of a research task and some of the steps an agent would need to complete it.

如图 1 所示，一个成功的智能体不能仅仅运行脚本。它必须:

  1. 设置 (Set up) : 安装依赖项并下载数据集 (通常来自 Google Drive 或不起眼的链接) 。
  2. 解决问题 (Resolve Issues) : 处理版本冲突 (例如，代码依赖于旧版本的 transformers 但并未说明) 。
  3. 执行与报告 (Execute & Report) : 运行训练，解析日志，并报告特定指标。

为了测试这种能力，作者推出了 SUPER (Setting UP and Executing tasks from Research repositories，即“从研究仓库设置并执行任务”) 。

SUPER 基准测试的结构

SUPER 不仅仅是一组编程题；它是对研究生日常工作的模拟。该基准测试分为三个不同的集合，每个集合在评估智能体时都有不同的用途。

Table 2: The different sets of SUPER.

1. 专家集 (The Expert Set)

这是“期末考试”。它包含 45 个端到端的问题，均由人工从 2021 年或之后发表的研究论文中精心挑选而来。

  • 来源: 在 “Papers With Code” 上找到的仓库。
  • 条件: 这些是“现实场景中”的仓库，意味着它们不是那些每个人都在用的、打磨完美的库。
  • 任务: 给智能体一个高层目标 (例如，“在 MRPC 数据集上训练此模型并报告 F1 分数”) 。
  • 黄金标准: 人类专家 (自由职业开发者) 实际解决了这些任务，以确保它们是可解的，并提供评估的基本真值 (Ground Truth) 。

2. 掩码集 (The Masked Set)

评估端到端任务是很残酷的。如果一个智能体正确完成了 90% 的工作，但在最后执行时失败了，它得到的分数就是零。为了理解智能体失败在哪里，研究人员创建了掩码集 。

他们提取了专家解决方案，并“掩码” (移除) 了特定的代码块，从而创建了 152 个子问题。这类似于语言学中的“完形填空测试” (cloze test) ，但针对的是仓库执行。

Figure 3: An abstract demonstration of how sub-problems are extracted.

如图 3 所示，一个掩码问题为智能体提供了一个“预执行”的环境 (例如，依赖项已经安装好) ，并要求它解决剩下的特定障碍，例如:

  • 依赖配置: 修复版本冲突。
  • 数据配置: 为新的 CSV 文件更新数据加载器。
  • 问题解决: 修复运行时 Bug。

这使得研究人员能够隔离特定的能力。智能体到底是代码写得烂，还是仅仅不擅长安装库？

3. 自动生成集 (The Auto Set)

最后，由于人工筛选既昂贵又费时，研究人员使用 GPT-4 自动生成了另外 604 个任务。虽然这些任务没有经过人类验证的“黄金”解决方案，但它们可以作为大规模训练和开发的演练场。

这些集合的构建流程如下图所示:

Figure 2: An overview of the construction pipeline for the Expert and Masked sets.

评估: 我们如何给 AI 研究员打分？

给代码生成打分通常使用单元测试。但是，你很难对一个混乱的研究仓库进行单元测试。因此，SUPER 使用了两个主要指标:

  1. 准确率 (基于解决方案) : 智能体必须报告一个特定指标 (例如，“Accuracy: 0.27”) 。如果报告的数字与黄金解决方案匹配 (在误差范围内) ，则任务成功。这是最严格的指标。
  2. 里程碑 (Landmarks) : 这是一个部分得分系统。研究人员在输出日志中识别了特定的字符串，这些字符串表明取得了进展 (例如，“Loading data… 100%” 或 “ *** training completed ***”) 。即使最终数字是错的，达到里程碑也表明智能体走在正确的轨道上。

智能体 (Agents)

论文评估了几种智能体架构，但最有趣的对比是在 ReAct 和 ReAct-SUPER (以及第三个外部基线 SWE-Agent )之间。

智能体在 Jupyter Notebook 环境中运行。这是一个关键的设计选择。与简单的终端不同，Notebook 允许智能体在单元格 (Cells) 之间保持状态 (变量) ，并混合使用 Shell 命令 (!pip install) 和 Python 代码。

  • ReAct: 一个标准的智能体，具备思考、行动和观察的能力。它使用基本的 Bash 命令。
  • ReAct-SUPER: 研究人员通过给标准智能体配备一个编辑工具对其进行了改进。标准智能体很难使用像 sed 这样的命令行工具来编辑文件。编辑工具允许智能体可靠地替换文件中的特定代码行，模拟人类使用 IDE 的方式。

实验结果: 现实检验

那么，GPT-4 能复现你的研究吗？简短的回答是: 还不行。

在专家集 (完整的端到端任务) 上的结果令人不容乐观。

Table 4: Results on Expert, with GPT-4o numbers averaged across 3 seeds.

如表 4 所示:

  • GPT-4o (SOTA) : 表现最好的智能体 (使用 GPT-4o 的 SWE-Agent) 仅解决了 16.3% 的任务。
  • 开源模型: Llama 3.1 和 Mixtral 表现非常挣扎，准确率仅为个位数。
  • 里程碑: 里程碑得分较高 (30-40%) ，这表明智能体通常能搭建好环境或开始训练，但未能冲过终点线得到正确结果。

子问题上的表现 (掩码集)

当我们把任务分解为掩码集子问题时，表现有所提升，但也暴露了具体的弱点。

Table 6: Results of our baselines on SUPER (Masked) with different underlying LLMs.

表 6 显示，在专注的子问题上，最佳智能体的成功率跃升至 46.1% 。 这证实了端到端任务巨大的篇幅和复杂性是一个主要的失败点。当智能体只需要专注于一件事 (比如修复一个 Bug) 时，它做得好多了。

错误分析的主要发现:

  1. 工具很重要: ReAct-SUPER 智能体胜过标准 ReAct 智能体，很大程度上归功于编辑工具。没有可靠文件编辑方式的智能体会被复杂的 sed 命令卡住，进而破坏代码。
  2. 错误类型: 智能体在修复显式崩溃 (例如，“RuntimeError: size mismatch”) 方面出奇地好。但它们在“静默失败”或配置任务上表现糟糕。例如，如果被要求“加载前 10 个样本”，智能体可能会为一个不存在的函数臆造一个 n_examples=10 参数，而不是深入代码去寻找正确的数据加载器类。
  3. 反思 (Reflection) 帮助不大: 研究人员尝试使用了“Reflexion”机制，即要求智能体反思为什么失败并重试。如下表 7 所示，这仅略微提高了准确率 (从 41.6% 提升到 45.4%) 。如果模型缺乏理解仓库结构的基本推理能力，思考再久也不一定能解决问题。

Table 7: Results of the ReAct-SUPER agent (using GPT-4o) with and without Reflexion on the Masked set.

为什么这个基准测试很重要？

要理解 SUPER 为何如此具有挑战性，我们必须看看它使用的仓库。这些不是其他基准测试中使用的那些无菌的、优化过的仓库。

Table 8: Details of the 45 repositories used in SUPER along with GitHub link and star information.

表 8 列出了所使用的仓库。注意 Star 数量 (第 3 列) 。许多仓库只有不到 20 个 Star。这些是“科研级”仓库——通常由一名研究生为某篇特定论文编写，之后可能再也没更新过。

这就是科学复现的真实世界 。

结论

SUPER 基准测试是对下一代 AI 智能体的一次严格的压力测试。它表明，虽然 LLM 擅长从零开始编写新代码，但它们在理解、调试和执行现有的、混乱的代码库所需的细致分析工作方面仍然很吃力。

对于学生和研究人员来说，这篇论文凸显了一个巨大的机会。目前 16.3% (SOTA) 与 100% 之间的差距，代表了一个有用的聊天机器人与一个真正的 AI 研究助手之间的差距。

未来的进步可能需要智能体在以下方面做得更好:

  1. 仓库级探索: 在行动之前阅读并理解文件结构。
  2. 工具使用: 特别是稳健的文件编辑和调试工具。
  3. 处理歧义: 当文档说的是一套，但代码做的是另一套时，知道该怎么办。

在此之前，看来我们还得自己去修复那些 ModuleNotFoundError。