基准评测基准

AI4AI-Bench: Benchmarking LLM Agents in Algorithmic Design for Recursive Self-Improvement

AI4AI-Bench:LLM agent 到底会不会改训练算法?

Yizhe Chi, Wenyi Li, Deyao Hong, et al. · Einsia Lab(含清华背景团队) · arXiv · 2026-08 · 被引 0

一句话10 个冻结科研仓库、10 个训练算法家族,agent 有 4 小时在一块 B300 上重写训练算法,补丁在全新环境从零重跑最多 12 小时、由冻结评测器打分。6 个系统 29 种配置共 290 个 cell,平均分 0.166(0.1 = 仓库自带算法,1.0 = 任务最优):最强的 Claude Opus 5 也只有 0.250,而且 263 份有效提交里 141 份根本没碰学习机制。

这是什么

递归自我改进(RSI)的核心问题是:AI 能不能改进'生产 AI 的过程'——也就是训练算法本身。一个更好的目标函数或更新规则会改善之后每一次训练的算力-能力兑换率,包括训练下一代 agent 的那次。但现有 agent 基准(MLE-bench、RE-Bench 一类)大多可以靠堆数据或调超参取胜,分不清'改了这次 run 的执行方式'和'改了模型学习的方式'。AI4AI-Bench 就是为隔离后者而设计的。

任务形式化为五元组 (C, a0, q, m, d):冻结仓库源码 C、起始模型 a0、探索期可无限查询的廉价 proxy 指标 q、以及 agent 永远见不到的最终指标 m。agent 提交的既不是数字也不是模型,而是改过的源码 C';C' 在全新容器里从零重跑,取最近 3 个 checkpoint 里最好的一个,由事先冻结、与 agent 环境完全隔离的评测器打分。基线是同一仓库自带算法在完全相同流程下的得分——赢了只能归因于代码改动本身。

10 个任务覆盖 SFT、多轮 agentic RL(RAGEN/Sokoban GRPO)、on-policy 蒸馏、Bradley-Terry reward modeling、DPO、diffusion RL(DDPO)、machine unlearning(NPO)、离散图扩散(DiGress)、weight averaging(Model Soup)和 one-shot pruning(OWL/Wanda)。10 个指标不可通约,所以统一映射到一个 ladder:0 = 无信息模型,0.1 = 仓库自带算法,1.0 = 任务最优(perplexity 类先取 -log 再线性映射)。

整体流程与 10 个任务一览。上排是四阶段 pipeline:冻结任务 → agent 4 小时探索(只有 source patch 能带出去)→ 全新容器 12 小时 formal 重跑 → 冻结评测器对至多 3 个 checkpoint 打分。下方是 10 个任务卡片,每张标了最终评测指标(如 OpenR1 用 LiveCodeBench pass@1、RAGEN 用 512 局 Sokoban 解题率、OWL 用 70% 稀疏度下的 WikiText-2 perplexity)。

机制与做法

Explore / Formal 两阶段隔离

探索期 4 小时,agent 在一块 B300 上随便读代码、改代码、自己跑训练、无限查 proxy;时间一到,只有一个 source patch 能跨过边界——训好的权重、缓存、给自己留的笔记全部作废。Formal 阶段在全新容器里 apply patch 后从零训练最多 12 小时,产出至多 3 个 checkpoint 交给冻结的 validation + 评测器。两个不训练的任务(weight averaging、pruning)直接执行一次产出模型再打分。

论文对隔离边界的表述很诚实:这是 access and timing 上的隔离,不是样本不相交——有些任务的 proxy 就取自最终评测同一语料(否则探索预算跑不起完整评测)。保证的是'没有 agent 能用决定成绩的那个指标去筛选候选',而不是'agent 从没见过评测会读的数据'。

6 个系统 × reasoning effort 的平均分,虚线 0.1 = 仓库自带算法。所有 29 个配置都挤在 0.06-0.29 之间,即全部不到量表的三分之一;GPT-5.6 系随 effort 大致上升,Claude Opus 5 却在 medium(0.29)见顶后 high 档掉到 0.19——effort 与得分并不单调。

被测对象是 system,不是 model

作者把 model + harness + reasoning effort 的组合称为一个 system。6 个系统:GPT-5.6 三档(Sol/Terra/Luna)跑 Codex 全部 6 个 effort 级,Claude Opus 5 / Sonnet 5 跑 Claude Code 的 5 级,Kimi K3 跑 Claude Code 最高级——共 29 个配置 × 10 任务 = 290 个 cell。整个探索阶段 API 花费 $5,334(不含 12 小时重跑的 GPU 和评测算力)。

八个 patch family:改 run 还是改学习?

每份提交的 diff 由另一个 LLM 按定义归入 8 个 family,分两侧:4 个改'这次 run 怎么跑'(训练时长/存档频率、超参、选哪个 checkpoint、adapter 容量与位置),4 个改'模型怎么学'(loss 项、监督信号、更新规则、训练数据)。280 份提交中 17 份无可归类改动;剩下 263 份里 141 份完全停留在 run 侧,只有 122 份碰了学习机制——而任务说明白纸黑字写着'improve this training algorithm'。

碰了学习机制的平均 0.226,没碰的 0.126(gap 0.100,SE 0.022),去掉被 imitation learning 抬高的 agentic RL 任务后仍是 0.182 vs 0.128。reasoning effort 买到的主要是'敢下去改'的胆量:碰学习机制的比例从最低档的 8% 升到最高档的 64%,均分从 0.094 到 0.196——effort 让 agent 更愿意去改真正值钱的那一层,而不是让改动本身更好。

少数真改了算法的提交长什么样

论文精读了三个案例:(1) one-shot pruning 任务被一份提交改成三阶段 pipeline(新的权重选择/更新规则 + layerwise 蒸馏 + masked KD 微调),perplexity 从 53.4 降到 13 出头;(2) weight averaging 任务上,一份提交先给自己造了个快 500 倍的评测 rig(72 个模型的张量打包成 GPU 上一个矩阵,单次打分从 ~190s 降到 0.38s),再在上面比较 5 种合并方法,greedy soup 0.7025 胜出;(3) agentic RL 任务上拿满分的提交干脆把 GRPO 换成了模仿学习(生成棋盘 + 标最优解 + SFT,一份还加了 DAgger)。共性是:动手前先造出可测量的东西——而这正是 263 份提交里绝大多数缺的能力。

关键结果

290 个 cell 平均分 0.166,最强系统 Claude Opus 5 平均 0.250,单个最佳配置(Opus 5 medium effort)0.288——最强者也只走完'仓库自带算法到最优'距离的不到 1/5。
124/290(超过 2/5)的 cell 得分低于 0.1,即改完比仓库原来的算法还差。
系统排序:Opus 5 (0.250) > GPT-5.6 Sol (0.191) > Kimi K3 (0.174) > Sonnet 5 (0.145) > Terra (0.135) > Luna (0.117),整个区间都在量表最低四分之一以内。
花钱多不等于分高:Sol 中位配置成本 $434,Opus 5 只用 $181 却领先全场;Sonnet 5 花 Luna 约两倍的钱只多 0.028 分。
263 份有效提交里 141 份只改 run 侧(超参/时长/checkpoint 选择等),122 份碰了学习机制;后者平均 0.226 vs 前者 0.126。
reasoning effort 从最低到最高:碰学习机制的提交占比 8% → 64%,均分 0.094 → 0.196,Codex 网格内逐级单调上升;19 个零分 cell 中 12 个集中在最低两档。
effort 与得分并非处处单调:Opus 5 在 medium(0.29)之后 high 档反而掉到 0.19(见 fig02)。

实证核查

扎实代码、任务、290 条轨迹均可查证,与论文声称一致;论文对自身隔离边界的局限写得异常坦白。主要保留:发布仅 10 天、无第三方复现,官方盲评服务尚不存在,自评结果只能算非官方。

论文声称发布 10 个冻结研究仓库、覆盖 10 个训练算法家族的任务套件与评测器。

GitHub Einsia/AI4AI-Bench 的 tasks/ 下确有 10 个任务目录(ddpo_sd15_aesthetic、digress_qm9_graph_diffusion、dpo_preference_alignment、model_soup_clip_imagenetv2、opd_math_1p5b、openr1_code_livecodebench、openunlearning_tofu_npo_llama3p2_1b、owl_wanda_opt6p7b_70pct、ragen_sokoban_grpo、ultrafeedback_bt_rm_rewardbench),与论文 Table 1 一一对应;orchestrator/、tools/(prepare_assets、smoke test、check_setup)齐全,Apache-2.0,Docker 镜像发布在 hub.docker.com/r/chiyizhe/ai4ai。

'We release every scored submission'——290 条轨迹全部公开。

lab.einsia.ai/ai4ai/trajectories/ 确实可按 (task, model, harness, effort) 浏览全部 290 个配置,每个 case 含 baseline、candidate 算法描述、proxy 证据、formal replay、checkpoint 与 audit 记录。但页面自述这是 'a redacted English release, not a raw log dump'——是经过整理脱敏的英文摘要版,原始日志并未原样倾倒。

评测由'事先冻结、agent 不可见'的评测器完成,测量可复现。

仓库 README 和 tools/docs/evaluation.md 明确承认 'the current absence of a blind evaluation service':第三方自跑的评测默认打上 non-official local results 标签(warn receipts)。也就是说协议是公开可复跑的,但目前没有官方盲评通道,榜上数字只能信作者自己跑的。另外仓库发布 10 天时 0 issues、1 fork、31 stars,尚无任何第三方复现记录。

proxy 与最终指标严格隔离,agent 无法在最终指标上过拟合。

论文 §2.3 自己写明隔离是 access and timing 而非 sample disjointness:部分任务的 proxy 与最终评测取自同一语料。这一点作者主动披露,属于诚实的设计权衡而非隐瞒;但意味着'没在最终指标上调过'不等于'没见过评测数据'。

基线与提交在完全相同的规约下比较。

tex 源码 2_benchmark.tex 第 115-119 行留有一条未删的作者注释:agent 取 3 个 checkpoint 的最优,而基线是否用同样的 reduction 规则'必须写明——早期草稿两者规则不同时,pooled rate 差了约 30 个点'。正文最终未明确交代这一点,复现或引用 win rate 类数字时需要自己找 mapped_table.csv 核对。

与我们方向的关系

这是目前唯一把'改训练算法本身'从'跑实验/调超参'里隔离出来的 RSI 基准,直接回答课题组关心的问题:当前最强 agent 距离能自我改进的那一层还有多远——答案是连仓库自带算法到最优的 1/5 都走不完,且大多数提交根本不去碰学习机制。'effort 买的是胆量而非能力'(8%→64% 的提交敢改算法,分数只翻倍)这个分解方式值得借鉴:评 agent 时把'是否到达关键层'和'到达后做得多好'拆开看。

两个可直接复用的设计:(1) explore/formal 边界——只允许 source patch 跨过、从零重跑再打分,是防 agent 在评测指标上过拟合的干净做法,任何自改进闭环实验都可以套用;(2) 0/0.1/1.0 三点 ladder 把不可通约指标映成稠密分数,论文明说这是为将来用 RL 训练 agent 准备的 dense reward——如果课题组要在类似环境上做 RL,这个 scoring 可以直接拿来。三个成功案例(先造 500 倍速评测 rig 再搜索、把 RL 任务重构成 IL)也提示:自改进 agent 的关键瓶颈可能是'先建测量工具'这一步。

阅读笔记

复现门槛不低:官方配置是单块 B300,4h 探索 + 12h 重跑,290 个 cell 光探索期 API 就花了 $5,334,还不含 GPU。tex 源码里留了不少作者工作注释(包括 §4 提到 per-task figure 和 patch family 小节曾被 park),读起来像仍在打磨中的 v1;引用具体 win rate 前建议对照仓库 build/lark/mapped_table.csv。DDPO 任务的高分提交(aesthetic score 从基线冲到 17.67)本质是把 RL 换成对 reward 的直接可微优化,某种程度上是合规的 reward over-optimization,解读该任务分数时要留意。