论文实验执行 ★ 必读

AIDE: AI-Driven Exploration in the Space of Code

AIDE:把机器学习工程变成代码空间里的树搜索

Zhengyao Jiang, Dominik Schmidt, Dhruv Srikanth, et al. (Weco AI) · Weco AI · arXiv · 2025-02 · 被引 178

一句话Weco AI 把"跑 ML 实验"形式化为代码空间的优化问题,用起草(draft)-调试(debug)-改进(improve)三种操作做贪心树搜索;在 OpenAI MLE-bench 上以 o1-preview 拿到 16.9% 的奖牌率(同模型下约为 OpenHands 的 2 倍),长期是 ML 实验 agent 的最强基线和事实上的脚手架标准。

这是什么

AIDE(AI-Driven Exploration)是 Weco AI 开发的机器学习工程 agent。它的出发点是:ML 工程的大部分时间花在试错上,而传统 AutoML/NAS/超参优化都需要人先定义好搜索空间,搜索本身也偏暴力。LLM 会写代码之后,可以直接在"代码空间"里搜索——每个候选解就是一个完整的单文件 Python 脚本,由验证集指标打分。

与 ReACT 式 agent 把全部历史塞进 context、当成一个长程 POMDP 来解不同,AIDE 把问题建模成 stateless 的优化:argmax h(s),s 是脚本,h 是验证指标。所有历史解组织成一棵 solution tree,每次让 LLM 基于某个节点提出一次改动,硬编码的搜索策略负责在树上积累这些增量改进。这个"把长程任务拆成原子改动+树搜索"的设计后来被大量工作继承。

值得注意的时间线:代码 2024 年 4 月就开源了(仓库创建于 2024-04-03),初步 Kaggle 报告也在当时发布;2024 年 10 月 OpenAI 的 MLE-bench 和 11 月 METR 的 RE-Bench 都拿它当被测 agent 并测出 SOTA,这篇 2025 年 2 月的论文实际上是事后把方法形式化、并汇总自家 Weco-Kaggle 评测与两个第三方评测的结果。

MLE-bench Lite 上 o1-preview 裸模型 vs 加 AIDE 脚手架的对比:有效提交率 63.6%→92.4%,超人类中位数 13.6%→59.1%,金牌率 6.1%→21.2%,总奖牌率 7.6%→36.4%。同一个模型,套上树搜索脚手架奖牌率翻近 5 倍——这张图是"scaffold 本身就是巨大变量"的最直接证据。

机制与做法

核心抽象:solution tree + 四个组件

AIDE 由四个组件构成:solution tree T(节点是脚本、边是一次改进尝试)、评估器 h(执行代码、返回标量分数)、搜索策略 π(T)(选哪个节点作为下一次改进的基底)、编码算子 f(s, Σ(T))(生成新脚本)。外加一个摘要算子 Σ(T),从树里抽取各次尝试的思路和指标,避免把全部历史日志塞进 prompt。

主循环极简(论文 Algorithm 1):每步用 f 基于当前基底节点生成新解 → 执行并打分 → 挂到树上 → π 重新选基底,循环 N 步后返回全树最优节点。默认配置 agent.steps=20、num_drafts=5。

METR RE-Bench 上 AIDE+o1-preview(粉)与人类专家(黑)的平均归一化分数随时间变化。AIDE 前 4 小时靠迭代速度快速拉开差距,但 5 小时后曲线走平(贪心策略陷入局部最优),约 6.5 小时被人类追上、8 小时被明显反超。引用"AIDE 超过人类研究员"时必须带上这个时间窗口。

搜索策略:硬编码的 draft / debug / improve 规则

π 不是学出来的,就是三条 if:初始草稿数不够就 drafting(从空解 s0 起草多个多样化方案);存在未超过 debug 深度上限的 buggy 节点就 debugging;否则 improving——贪心地选当前最优的非 buggy 节点改进。Meta AIRA 论文把它精确刻画为:以 1-ε 概率选 argmax F(v)、以小概率 ε 选 buggy 节点的贪心策略。

三种操作各有专用 prompt:draft 先让 LLM 写简短 plan 再输出单文件程序;debug 看报错日志和 traceback 修 bug 但保持方案不变;improve 每次只提"一个原子改动"(比如换 optimizer、加正则),保证每条边的效果可直接归因。prompt 里还固定塞一小段 data preview(行数、列名、划分),代替完整 EDA。

自建 Weco-Kaggle 全量 63 个比赛上 AIDE 的"超过百分之多少人类参赛者"分布(按任务排序)。均值 48.23%,但方差极大:少数任务接近 100%,尾部任务只有个位数——说明它在部分领域很强,整体表现高度依赖任务类型。

为什么它比"线性" agent 强

MLE-bench 里 MLAB、OpenHands 这类通用 agent 常常提前终止、或在长 context 里迷失;AIDE 的每次 LLM 调用只面对一个局部问题(修一个 bug/提一个改动),prompt 不随历史膨胀,坏解不会污染后续,失败分支被树结构自然隔离。代价是:评估必须是自动的标量指标,任务要能被单文件脚本表达。

成本上论文附录给了数据:Weco-Kaggle 上用 GPT-4 Turbo,每个任务的 LLM 开销大多在 1.5 美元以下,最贵约 2.5 美元(2024 年初定价);生成代码的复杂度(LOC/Volume/MI 聚合)随步数稳定上升,说明它确实在持续往方案里叠功能而不是原地打转。

三组评测

Weco-Kaggle(自建):63 个 Kaggle 比赛,均值"超过 48.23% 的人类参赛者";16 个低复杂度表格任务的 Lite 子集上,AIDE+GPT-4 Turbo 平均超过 51.38% 的人类、50% 任务超中位数,明显好于 H2O AutoML(35.34%)、AutoGPT(32.34%)和"人+ChatGPT"(41.17%)。

MLE-bench(OpenAI,75 个真实 Kaggle 赛,第三方):AIDE+o1-preview 奖牌率 16.9%±1.1(pass@1),同用 GPT-4o 时 AIDE 8.7% vs OpenHands 4.4% vs MLAB 0.8%;在 Lite 子集上,o1-preview 裸模型 vs 加 AIDE:奖牌率 7.6%→36.4%,有效提交率 63.6%→92.4%。

RE-Bench(METR,7 个 AI R&D 任务,第三方):AIDE+o1-preview 靠更快的迭代在 6 小时内超过顶级人类研究员的平均分,在 Optimize a Kernel 任务上写出的 Triton kernel 超过全部 9 位人类专家 64 小时的成绩;但 6 小时后分数平台化,8 小时时人类(0.66)反超 AIDE(0.37)。

关键结果

MLE-bench pass@1:AIDE+o1-preview 奖牌率 16.9%±1.1、有效提交率 82.8%;同为 GPT-4o 时 AIDE 8.7% vs OpenHands 4.4%(2 倍)、vs MLAB 0.8%。
MLE-bench Lite 消融:o1-preview 加 AIDE 后奖牌率 7.6%→36.4%(近 5 倍)、金牌率 6.1%→21.2%、超人类中位数比例 13.6%→59.1%,全部 p<0.01。
pass@k 扩展性好:GPT-4o 和 o1-preview 从 pass@1 到 pass@6 奖牌数接近翻倍——树搜索天然吃"多跑几遍"的算力。
RE-Bench:6 小时窗口内 AIDE 平均分超过顶级人类研究员;Triton kernel 优化任务上超过所有人类专家 64 小时的最好成绩;但贪心策略导致 6 小时后陷入局部最优,8 小时人类反超(0.66 vs 0.37)。
自建 Weco-Kaggle Lite(16 个表格任务):平均超过 51.38% 人类参赛者,好于 H2O AutoML(35.34%)和 AutoGPT(32.34%);全量 63 赛上为 48.23%,方差很大(单任务从 13% 到 92%)。
成本:GPT-4 Turbo 跑一个 Kaggle 任务的 LLM 开销大多 <$1.5,最高约 $2.5(2024 年初定价)。
后续影响:Sakana AI-Scientist-v2、Meta AIRA/llm-speedrunner、SJTU ML-Master 都直接构建在 AIDE 框架或其树搜索思想上;S2 引用 178 次,repo 1496 stars 且到 2026-08 仍在维护。

实证核查

扎实核心战绩(MLE-bench、RE-Bench)本身就是 OpenAI 和 METR 做的第三方评测,可信度高;代码开源且持续维护,被多家机构复用为脚手架。水分主要在 README 的 "4×" 表述和自建基准的取样,另外代码里长期存在过一个会静默反转整个搜索方向的 bug,值得复用者注意。

README 宣称 MLE-bench 发现 AIDE 的树搜索"wins 4× more medals"于最好的线性 agent(OpenHands)。

MLE-bench 原表(论文 Table 2 转载)同模型对比是 GPT-4o:AIDE 8.7% vs OpenHands 4.4%,约 2 倍;4 倍来自拿 AIDE+o1-preview(16.9%)去比 OpenHands+GPT-4o(4.4%),跨模型比较。论文正文自己写的是 "twice the number of medals...when both use GPT-4o",README 的 4× 属于营销口径。

论文把 tree search 描述为 AIDE 性能的关键来源。

Meta AIRA(arXiv 2507.02554,NeurIPS 2025)在统一环境 AIRA-dojo 里做了系统消融:用 AIDE 原版算子换上 MCTS/进化搜索,相对贪心策略没有显著提升——瓶颈在 draft/debug/improve 算子的 prompt 设计而非搜索策略;换成改进算子集 O_AIRA 后,MLE-bench Lite 奖牌率从 AIDE 基线 39.6% 提到 47.7%。同一论文还指出这类 agent 用验证分数选终解存在明显的 validation-test 泛化差距。即 AIDE 框架好用,但其"贪心 vs 更聪明搜索"的叙事被后续工作部分修正。

实现层面:evaluator 由 feedback LLM 判断指标方向(lower_is_better)并据此选最优节点。

这是实际翻过车的设计:issue #57 报告 LLM 对同一 run 内各节点给出不一致的方向判断导致崩溃;#91 修了崩溃但 #92 进一步指出 aide/journal.py 的方向归一化是 first-writer-wins——第一个节点的 LLM 判断如果错了,后续所有正确判断都会被"归一化"成错误方向,get_best_node() 返回最差解、贪心策略一路往最差节点上扩,整个 run 无报错静默跑完。相关修复 2025-2026 年才陆续合入(#91/#93)。用 AIDE 做基线的同学应显式传入指标方向而不是依赖 LLM 猜。

"与 Google DeepMind、Anthropic、OpenAI 等机构的顶级人类 AI 科学家相当"(RE-Bench 部分)。

严格看 METR 原图(论文 Figure 4):只在 ≤6 小时预算内成立,靠的是迭代速度;8 小时时人类 0.66 vs AIDE 0.37,且 AIDE 曲线 5 小时后基本走平。论文正文对此是诚实的,明确归因于贪心策略陷入局部最优、以及不擅长需要多步交互/大代码库的任务(如 Agent for Rust CodeContests 反复打局部补丁)。引用这个战绩时要带时间窗口。

自家评测:Weco-Kaggle 上平均超过约半数人类参赛者。

该基准是自建的(63 个比赛),主推的 Lite 子集是刻意挑的 16 个"低复杂度、CPU 可跑"表格任务;holdout 划分是自己按 Kaggle 参数手工模拟的,与官方 private test 不完全一致;论文也承认存在训练数据污染风险、且没有提交到 live 比赛验证。这部分数字(51.38%)可信度低于 MLE-bench 部分,好在结论方向与第三方评测一致。

开源可复现、作为社区基础设施。

属实且是其最大价值:pip 包 aideml、MIT 协议、含 CLI/webui/树可视化;repo 到 2026-08-17 仍有 push(1496 stars)。OpenAI MLE-bench 和 METR RE-Bench 官方仓库直接集成 AIDE 作为被测 agent;Sakana AI-Scientist-v2 的"agentic tree search"、Meta aira-dojo、SJTU ML-Master 均在 README 列表中且各自论文可查。issues 里没有系统性的"复现不出论文结果"的帖子,多为工程 bug(#35 超时失控、#40/#69 解析错误)。

与我们方向的关系

对做 autoresearch 实验执行环节的同学,AIDE 是绕不开的参照系:它定义了"draft/debug/improve 原子操作 + 验证指标驱动的树搜索"这套范式,MLE-bench 上的对比基线、AI-Scientist-v2 的实验模块、AIRA 和 ML-Master 的改进都以它为起点。想快速搭一个 ML 实验 agent,直接 pip install aideml 改 prompt 和搜索策略是成本最低的路径。

两条可直接借鉴的经验:一是 stateless 化——把长程任务拆成"基于单个节点的原子改动",用树结构而不是不断增长的 context 来承载历史,这是它比 ReACT 式 agent 能多迭代几十步的根本原因;二是 AIRA 的教训——在这套框架上花力气改进算子(prompt 的复杂度自适应、scoped memory)比换更花哨的搜索算法收益大,且要警惕验证集过拟合(终解选择的泛化差距)和指标方向这类"静默失败"点。

阅读笔记

读代码时注意:论文的形式化(Section 3)和实际实现有距离,例如 π 的 ε 概率选 buggy 节点、feedback LLM 判定 metric 方向等细节只在代码里。复用作基线时建议:显式指定指标方向(避开 #92 的坑)、检查 interpreter 超时处理(#35/#88)、o1/推理模型需要 num_drafts 和 steps 调参。Weco 公司产品(weco.ai)是这套算法的商业化,README 里的导流链接与开源版功能有差异。