FML-bench: A Benchmark for Automatic ML Research Agents Highlighting the Importance of Exploration Breadth
这是什么
现有的 ML agent 基准(MLE-Bench、MLAgentBench、DSBench 等)多为 Kaggle 式应用任务,只看最终性能和算力成本。这篇工作认为这是'工程视角',测不出 agent 做科研的能力:科研的核心是围绕基础问题反复提假设、做实验,过程本身也应该被度量。
FML-bench 因此选了 8 个基础 ML 研究问题——generalization(ColoredMNIST+ERM)、data efficiency(Mini-ImageNet+ProtoNet)、representation learning(CIFAR-10+MoCo)、continual learning(splitMNIST+SI)、causality(IHDP+DragonNet)、robustness(投毒 MNIST+dp-instahide)、privacy(CIFAR-10 上抗 membership inference)、fairness(COMPAS+Adversarial Debiasing)。每个任务基于真实开源仓库,给 agent 提供 baseline 代码、任务描述、实验命令列表和受保护的评测文件,要求在 100 步预算内迭代改进 baseline。
注意版本演化:入库的是 2025-10 的 v1(arXiv 2510.10472),只评了 3 个 agent。仓库 main 分支已是 2026 年大改版(arXiv 2605.17373,题目改成了 'A Controlled Study of AI Research Agent Strategies from the Perspective of Search Dynamics'),扩到 18 个任务配置、7 个 agent(含作者自己的 AdaptiveSearch),v1 内容退到 legacy 分支。本笔记以 v1 论文为主、兼顾现仓库状态。
机制与做法
统一输入输出接口:让 agent 直面真实仓库
与手工整理 starter code 的基准不同,FML-bench 直接用 DomainBed、CausalML、Opacus、AIF360 这类学界公认仓库当任务底座。为了兼容各仓库五花八门的脚本名和多阶段 pipeline,它把'完整执行序列(训练+评测命令列表)'作为单一输入单元交给 agent,输出侧用后处理模块把各仓库不同格式的结果统一成标准指标。
输入包含 7 件套:任务描述、完整仓库代码、建议修改的文件、禁止修改的受保护文件(评测代码只读,防作弊)、实验命令列表、baseline 成绩、目标指标。agent 每步提一个 hypothesis,落成 code modification,跑实验拿反馈,进入下一轮。
过程指标:Exploration Diversity 是核心卖点
除了 Performance(全程最优测试成绩)和 Cost(token/时间),论文提出三个过程指标。Exploration Diversity:用 GraphCodeBERT 给每步的代码快照算嵌入,取所有嵌入到质心的平均 L2 距离——方差越大说明尝试的实现方案越发散。GraphCodeBERT 用数据流图而非表面 token,改个变量名不会被当成新想法。
另两个是可靠性指标:Step Success Rate(实验无错跑出有效结果的迭代占比)和 Step Completion Rate(实际执行步数/分配步数,抓提前摆烂)。新版仓库把这套扩成了 5 维 12 个过程指标(Exploration/Generalization/Reliability/Efficiency/Cost),由 compute_agent_metrics.py 一键计算。
实验设计:三种搜索策略对打
v1 选了三个策略截然不同的 agent:TheAIScientist(并行广撒网,broad & shallow)、AIDE(树搜索,medium/medium,实际用的是其商业云版本 Weco)、Claude Code(被 prompt 成线性深挖,narrow & deep,只能用 Opus-4.1)。前两者各配 GPT-5 和 Gemini-2.5-Pro,共 5 个配置,每个跑 3 轮取最优。
主结果:TheAIScientist+Gemini-2.5-Pro 在 8 任务中拿 4 个第一,AIDE+Gemini 拿 2 个;Claude Code 的 Exploration Diversity 只有 8.75(TheAIScientist 24.66、AIDE 23.50),整体成绩也最弱。论文由此得出'探索广度比深挖单一想法更有效'。
关键结果
- TheAIScientist+Gemini-2.5-Pro 最强:8 任务拿 4 个 best(如 continual learning 0.271→0.781,privacy 攻击 AUC 0.811→0.175);AIDE+Gemini 拿 2 个;Claude Code 仅在 generalization 上并列第一(0.504)。
- LLM 固定时,diversity 高的 agent 性能更好;agent 固定换 LLM 时 diversity 不再是决定因素——说明探索策略和模型能力是两个独立变量。
- Exploration Diversity 与性能的相关:5/8 任务为正,但仅 data efficiency(r=0.63, p=0.012)和 continual learning(r=0.84, p=0.0002)达到 p<0.05;causality、robustness、privacy 三个任务相关为负。
- 可靠性差异巨大:TheAIScientist 的 Step Completion Rate 为 1.00,AIDE(Weco 云端故障)0.54-0.69,Claude Code 只有 0.07——100 步预算平均只跑约 7 步就自行终止。
- Claude Code 作为通用 agent 反而最烧 token:总消耗 9.06M vs TheAIScientist 的 5.45-6.04M(AIDE 无法记录),单步高达 3.10M。
- AIDE 的已知短板:只支持改单个文件,在多文件真实仓库上会生成从未被调用的新类,generalization 和 data efficiency 两任务完全没能改进 baseline。
实证核查
与我们方向的关系
对做自动研究 agent 的同学,这篇的直接价值有二:一是 Exploration Diversity 这个指标可以直接搬走——用 GraphCodeBERT 嵌入方差量化 agent 的搜索广度,成本低、与代码语义对齐,适合作为 agent 搜索策略消融的诊断量;二是它提供了一套现成的、基于真实仓库(DomainBed、Opacus、AIF360 等)的 harness,18 个任务 + 7 个已接入的 agent(含 AI Scientist v1/v2、AIDE、OpenEvolve),接自己的 agent 只需加一个 config,还有 8 任务的 Lite 子集省算力。
但引用它的结论时要小心:'广度优于深度'在 v1 里证据不足,作者在 v2 已改口为更中性的 search dynamics 受控研究。更稳妥的读法是:在无记忆、无先验的迭代改代码设定下,提前终止和单文件编辑这类工程可靠性问题对结果的影响,可能不亚于搜索策略本身——设计 agent 时先保证跑满预算(completion rate),再谈探索策略。建议后续直接跟进 v2(2605.17373)和其 AdaptiveSearch agent。