WhatWorkedBench: 为 AI Agents 的实验理解建立基准

TL;DR WhatWorkedBench 提出首个评测 AI 智能体实验理解的基准：在预算内探查代码后预测组件变化对结果的影响，并证明共享推理（如 GP）可显著提升效果恢复精度。

问题

问题背景

AI 研究 agent 越来越多地执行自动化实验，例如调整 ML pipeline 的组件、修改代码或数据预处理方案。这类 agent 不仅要找到最优配置，还必须理解每个组件变化如何影响最终指标，才能形成可迁移的实验知识。

现有方法局限

当前评估主要关注优化成功率或端到端任务得分：benchmark 只记录 agent 是否找到高分数配置，却忽略它对组件级效应的预测是否准确。此外，缺少统一的响应面数据集，agent 的预测难以与可重复的参照组对比。已有工作通常只测单一变化、线性主效应，无法刻画条件效应和组件间交互；agent 可能在某个任务上“撞”到好配置，但换一个数据源或工作流就完全失效。

为什么这个问题难且重要

实验理解难在三点：1) 组件组合空间巨大，预算内只能测量少量配置；2) 真实任务存在条件结构——同一组件在不同 pipeline 上下文下效果可能反转；3) 需要从稀疏、带噪的观测中恢复数值效果，且必须区分优化成功与真正理解干预效应。该能力是 AI 自主科研、pipeline 自动调优和因果归因的基础。WhatWorkedBench 通过 36 个任务、8 类工作流和 1248 条配置记录，强制 agent 提交完整响应面预测，并用穷举 CPU 执行生成参照效应，填补了这一评估空白。

行业类比

就像 AutoML 平台不仅要给出最优模型，还要能回答“改变数据采样策略对 AUC 的影响量是多少”，工程师才会信任并复用这些实验结论。

核心洞察

• WhatWorkedBench 提出以响应面预测作为核心评估对象，将实验理解从单纯优化成功率中分离。现有 agent 基准多关注最终结果是否最优，而该基准要求智能体基于预算内测量，对组件配置空间的完整分数表做出准确预测。这种评估更接近科学实验中的因果推断：不仅要找到好配置，还要理解每个组件改变对结果的独立与交互影响，从而暴露智能体在知识建模上的真实能力。
• 共享推断与程序结构编码能显著提升实验证据的利用率。在相同智能体观测下，采用 Gaussian process 拟合可将效应恢复准确率从 0.632 提升至 0.698；进一步编码代码等效性（行为相同的配置）时，GP 恢复从 0.248 跃升至 0.462。这表明，相比增加采样次数，利用领域知识（如代码等价关系）进行结构化推断，是实验设计中更具性价比的路径，为自适应实验设计提供了新方向。

方法

方法：WhatWorkedBench 的实验理解基准

输入：AI agent 接收一个任务实现代码、一组可配置组件（如模型架构、数据预处理、超参数）及其离散选项，以及一个测量预算。agent 需要理解改变每个组件如何影响最终分数。

关键模块：

• 参考效应生成：通过穷举 CPU 执行每个单一组件变化（其他固定），产生 ground-truth 效应集合，覆盖 36 个任务、30 个数据源、8 个工作流类型，共 1248 个配置记录。
• 响应面提交：agent 执行测量后，提交一个响应面表，预测所有组件设置组合的分数。
• 数值推理与共享推断：评估框架使用 pair-effect ridge 选择最优配置，拟合 Gaussian process (GP) 到 agent 的观测以提升效应恢复，并编码程序等价（相同行为的配置）以利用代码结构。这些共享推断方法在有限测量下提取更多价值。

输出：核心指标包括效应恢复（预测效应与真实效应幅度的相关性）、family-macro recovery 和优化成功。

与传统 agent 基准只评估最终性能或单点最优不同，WhatWorkedBench 要求 agent 建模完整的组件响应面，从机制上评估实验理解能力。

实验

实验设计

WhatWorkedBench 构建了 36 个任务、30 个数据源、8 种工作流类型，共 1248 条配置记录。智能体在预算内检查代码、选择测量，并提交 response surface。基准通过穷举 CPU 执行获得每个组件变化的参考效应。核心评估包含 4,206 条数值控制记录和 108 个智能体 episode。评估协议强调优化成功与干预知识是不同目标，并使用 pair-effect ridge、Gaussian process (GP)、代码等价编码等数值推断方法。

关键发现

• 在 22 个源上的 8 次新测量中，pair-effect ridge 在 15 个源上选出最优配置，并在 3 个源上将每个效应误差限制在分数范围的 10% 以内。
• 对相同智能体观察拟合 GP 后，效应恢复准确率从 0.632 提升到 0.698（原始 Flash 队列），额外队列从 0.621 提升到 0.720。
• 在 6 个完成的 beat-detection 和 graph 提交上，GP 将 family-macro recovery 从 0.303 提升到 0.455。
• 在 6 个工作流、20 次新测量中，编码代码等价性（行为相同的配置）将 GP recovery 从 0.248 提升到 0.462。

与基线对比

基线是智能体直接预测的效应恢复准确率。使用共享推断（GP 拟合）显著提高了对真实效应幅度的还原能力，表明智能体获取的观测数据中存在未充分利用的结构信息。代码等价性编码进一步利用程序结构，将恢复率提升近一倍（0.248 → 0.462），说明领域知识可以大幅增强数值推断。该 benchmark 表明实验理解不仅取决于优化结果，还取决于对组件因果效应的准确建模，为后续研究提供了可扩展的评估平台。

行业影响

落地场景

WhatWorkedBench 针对 AI agent 的实验理解能力 进行评测，即 agent 在有限实验预算内预测组件变化对结果的影响。该能力直接对应以下实际场景：

• AutoML 与超参数优化：自动化机器学习平台需要智能 agent 决定下一步试验哪些配置，以减少计算开销。
• MLOps 持续调优：线上服务定期重训模型时，agent 需快速判断哪些数据/特征/超参改动值得投入资源。
• AI 辅助实验设计：科研或工程中，agent 辅助设计消融实验、解读组件贡献。

商业价值

• 降低实验成本：更准确的效应预测可减少无效实验次数，节省 GPU/CPU 算力与工程师时间。
• 缩短迭代周期：快速定位有效配置，加快模型版本上线，间接提升业务指标（如推荐点击率、风控准确率）。
• 辅助选型与评估：企业可用该基准横向比较不同实验 agent 的性能，选择最适合自身工作流的方案，避免盲目采购或自研。

与现有产品/工作流的接口

• 集成到 MLOps 平台：可作为 MLflow、Kubeflow 等实验管理工具的评估插件，或作为自定义 agent 的评测套件。
• 增强优化器：文中提出的 pair-effect ridge、Gaussian process 等推断方法可直接融入现有贝叶斯优化、主动学习框架，提升 agent 对响应面的建模能力。
• 代码结构感知：利用程序等价性（code equivalences）编码，可优化 agent 对配置空间的探索效率。

具体落地 use case

• 电商推荐系统调参：电商推荐团队使用自动化调参 agent 搜索排序模型的特征权重、召回策略组合。基于 WhatWorkedBench 评估的 agent 能在预算内准确预测各参数对点击率的影响，降低线上 A/B 测试的试错成本。
• 内容平台算法优化：短视频或新闻推荐平台的内容分发涉及多组件（召回、排序、多样性控制）。具备实验理解能力的 agent 可快速定位影响用户留存的关键设置，避免多轮全量实验。

局限

• **评估范围与任务设计存在局限**：基准仅覆盖 36 个任务、8 种 workflow 类型和 30 个数据源，且参考效应由 CPU 执行生成，未涉及 GPU 密集型或更复杂的真实实验设置。任务重点放在数值控制和配置预测上，与科研中非数值因素（如代码可读性、科学直觉、跨领域迁移）关联较弱，可能无法完整反映 agent 的实验理解能力。此外，响应面预测要求 agent 输出所有配置组合的分数，但预算受限时许多组合不可观测，导致评估噪声大、指标波动明显，可能降低基准的可靠性和区分度。
• **agent 表现与任务难度之间存在张力**：从摘要数据看，原始 agent 的 effect recovery 在 0.6 左右，GP 后处理才能提升至 0.7 以上，说明任务本身的难度较高，可能让部分 agent 无法展示有意义的能力，甚至出现地板效应。基准设计虽然引入了 code equivalences、GP 等后验方法提升测量价值，但 agent 自身的测量策略和推理能力是否被公平评估仍有疑问。预算固定时，agent 需要在探索与利用之间平衡，不同策略的表现差异可能掩盖真实的理解水平，且后处理方法不完全在 agent 控制之下，削弱了对 agent 原始能力的直接评价。
• **与同类工作对比的生态和可解释性弱点**：相比其他研究实验 design 或 attribution 的基准，WhatWorkedBench 更侧重事后预测而非交互式实验闭环，缺少与真实实验环境的实时反馈。评分指标（如 effect recovery、pair-effect ridge、family-macro recovery）多样但关系复杂，不同指标间的权重和选择依据未充分说明，可能导致结果解读困难。此外，项目 GitHub 星数仅有 2，社区采用度和生态建设尚未起步，短期内难以形成广泛共识，也缺乏与既有 benchmark 的详细横向对比，可能限制其作为标准评估工具的推广价值。