CODS 2025 AssetOpsBench 挑战赛结果及回顾性分析

# CODS 2025 AssetOpsBench 挑战赛结果与回顾分析

来源: https://arxiv.org/html/2605.08518
Dhaval Patel<sup>1</sup> Chathurangi Shyalika<sup>2</sup> Suryanarayana Reddy Yarrabothula<sup>3,4</sup> Ling Yue<sup>5</sup> Shuxin Lin<sup>1</sup> Nianjun Zhou<sup>1</sup> James Rayfield<sup>1</sup>
<sup>1</sup>IBM <sup>2</sup>南卡罗来纳大学人工智能研究所 <sup>3</sup>印度钢铁管理局 <sup>4</sup>印度理工学院，比莱 <sup>5</sup>伦斯勒理工学院

###### 摘要

我们提出了对 CODS 2025 AssetOpsBench 挑战赛的回顾性分析。该挑战在隐藏场景和隐私保护条件下，评估了多智能体 AI 系统在长周期工业 4.0 任务中的表现。参赛智能体通过完整的“感知 → 推理 → 执行”流水线进行操作，其中单独的比赛赛道分别隔离了规划和执行能力。尽管该领域通常需要具备专业专家知识，但注册记录显示 149 支队伍共有 349 个声明的成员名额，服务器日志记录了 300 次提交尝试，其中 234 次达到了“完成（Finished）”状态。参赛者主要来自本科生团队和初创公司。我们从五个互补维度分析了提交作品集，这些维度是单纯聚合排行榜排名所无法解决的：参与度、提交行为、排名稳健性、计算成本和策略归因。分析揭示了复合指标设计、公开与隐藏排名对齐以及排名稳定性方面的具体弱点。最引人注目的是，公开执行得分与隐藏执行得分之间缺乏相关性（$\rho=-0.13, n=13, p=0.71$），表明公开排名无法预测隐藏的稳健性。挑战赛后发布的“可信基准检查清单”独立验证了我们大部分基础设施的设计，并准确指出了我们提出的评分器稳健性差距。我们发布了场景和评分追踪数据，并将分析提炼为可供未来智能体基准测试使用的便携式诊断工具。

## 1 引言

基于大语言模型（LLM）的智能体的最新进展，已经产生了能够通过推理、工具使用和多智能体协调来完成复杂多步骤工业任务的系统。然而，将这些系统从实验室环境转移到实际部署，使得**评估本身**成为一个核心科学挑战。这种挑战因基准式评估的局限性而被放大，后者倾向于狭窄指定且易于优化的任务，从而可能歪曲现实世界的能力 \[7, 18\]。在部署中最重要的行为最难测量，例如工具使用的稳健性、隐私保护的执行以及多步骤编排，这些难以廉价地进行基准测试，难以公开发布，且对指标设计高度敏感。指标设计不当的比赛可能会奖励肤浅的提示工程，而忽略更难的问题。

> **图 1：CODS 2025 AssetOpsBench 比赛框架。** 提交作品在规划和执行赛道上针对多模态工业数据的四个领域智能体进行评估。蓝色星号标记了从公开开发阶段到隐藏评估阶段的过渡。

基于比赛的评估提供了一种原则性的替代方案。通过结合盲提交、隐藏测试集和大规模参与，比赛暴露了静态基准所遗漏的故障模式，包括仅在迭代评估下才会出现的渐进式推理失败和适应性策略 \[13\]。最近的由比赛驱动的基准表明，评估设计至关重要，它实现了可靠性感知数据集 \[8\]、大规模压力测试 \[14\] 和抗污染协议 \[6\]。最近邻搜索 \[23\]、定理证明 \[24\]、电力系统 \[19, 28\]、系统神经科学 \[25\] 和安全 \[13\] 等领域的先前回顾研究表明，最有价值的比赛论文解释的是排行榜衡量了什么，而不仅仅是谁获得了第一名。

我们遵循这一原则，分析了一个在工业环境下的大规模智能体 AI 比赛，探讨这种评估设计衡量了什么，未能衡量什么，以及其激励机制如何塑造了提交的系统。据我们所知，CODS 2025 AssetOpsBench 挑战赛是第一个结合智能体评估、工业物理资产领域和隐私约束部署的比赛轨道基准。它在亚洲顶级数据科学会议之一——数据科学与管理会议（CODS-COMAD）\[1\] 上举办。该挑战赛基于两项先前工作：AssetOpsBench，这是一个跨越预测性维护、故障诊断、工单生成和物理资产（如冷水机组和空气处理机组）根本原因分析的工业基准 \[21\]；以及 AssetOpsBench-Live，它通过将基准部署为具有六维度“LLM-as-judge”评分和聚类故障模式反馈的隐私保护 Codabench 比赛来扩展该基准 \[9, 22\]。

图 1 展示了比赛框架，突出了四个领域特定智能体（即 IoT、FMSR、时间序列、工单）和端到端评估时间线。该比赛托管在 Codabench \[27\] 上，本文分析的组织者工件包括 149 个注册团队、349 个声明的成员名额，以及横跨两个赛道（规划和执行）的 300 行提交尝试日志。开发阶段的最佳入选作品随后在隐藏工业场景下进行了盲评估。Codabench 在其年度通讯中将其指定为焦点比赛 \[10\]，反映了评估基础设施的可靠性和规模。因此，我们将该挑战赛视为一次比赛回顾，而不仅仅是排行榜报告。

我们的分析结合了最终排名表、300 次尝试的服务器日志、149 个团队的注册表、最佳提交导出、评分追踪以及可用的顶级提交工件。这些工件支持以下四项具体观察：
1.  公开规划排行榜饱和于 72.73%。
2.  公开和隐藏执行得分未能产生相关性（$\rho=-0.13, n=13, p=0.71$），因此公开信号无法预测隐藏稳健性。
3.  发布的 $t$-match 项对每个赛道的贡献最多为 0.05 分，因为它在不同的数值尺度上组合。
4.  最强的执行系统是护栏工程师，而非架构创新者——他们改进了响应选择、清理、回退和上下文控制，而不是引入新的智能体架构。

本文的其余部分描述了比赛设置、由此产生的排行榜行为，以及这些结果为未来智能体比赛提出的设计教训。

## 2 比赛概览

### 2.1 挑战赛设计与赛道

本节描述图 1 所示比赛框架的关键构建模块。公开 AssetOpsBench 基准包含 141 个工业场景，涵盖 99 个单智能体和 42 个多智能体案例 \[21\]。这些场景托管在 Hugging Face \[5\] 上，并作为所有提交的共享评估集。四个领域特定智能体（IoT、FMSR、TSFM 和 WO）及其相关的多模态数据集被打包在 Docker 容器中 \[3\]，确保每个参与者无论本地基础设施如何，都在相同的受控环境中执行。

比赛托管在 Codabench \[11\] 上，技术文档和预构建的 Docker 镜像通过公开起始仓库发布 \[4\]。此设置支持长时间运行的智能体执行，同时将工业数据和隐藏场景保留在评估环境内。两个赛道在这个共享环境中创造了互补的受控实验。

*   **赛道 1（Track 1）** 固定执行器，要求参与者改进计划。编辑仅限于 `track1_planning.py` 中的提示构建和智能体格式化区域。核心假设是更好的提示会产生更高质量的领域智能体有向无环图（DAGs），而更高质量的 DAGs 会提高下游执行效果，无论单个智能体能力如何。
*   **赛道 2（Track 2）** 固定计划，要求参与者改进执行器。编辑仅限于 `track2_execution.py` 中的工作流执行逻辑，其中基线 `SequentialWorkflow` 可以被支持并行执行路径、每任务多智能体协作、跨任务上下文聚合和容错回退的 `DynamicWorkflow` 替换。领域智能体、基础模型和规划提示保持冻结。

图 2 显示了每个赛道的确切可编辑和冻结区域。

> **图 2：每个赛道的可编辑 TODO 区域，镜像发布的起始模板**
>
> **赛道 1** `track1_planning.py`
> *   可编辑 – TODO 区域
>     ```python
>     def format_agent_info(agents):
>         ...
>     def build_planning_prompt(scenario, agents):
>         ...
>     ```
> *   冻结 – 不要修改
>     ```python
>     def run_agent(prompt):
>         return executor.run(prompt)
>     ```
>
> **赛道 2** `track2_execution.py`
> *   可编辑 – TODO 区域
>     ```python
>     class DynamicWorkflow(SequentialWorkflow):
>         def run(self, tasks, context):
>             result = executor.run(tasks)
>             result = cleanup(result)
>             if not valid(result):
>                 result = fallback(result)
>             return result
>     ```
> *   冻结 – 不要修改
>     ```python
>     def build_planning_prompt(scenario):
>         return default_prompt(scenario)
>     ```

通过设计，赛道 1 中的可编辑表面将参与者控制的变体集中在提示和规划代码中，而赛道 2 则集中在工作流执行和上下文处理上。这种分离是比赛的一个核心方法论特征，尽管来自打包选择、提交实践和评分器细节的残留变异仍然可能出现。

所有提交都使用固定的 LLaMA-3-70B 模型，并通过三个评估阶段：在 2-3 个场景上进行可选的本地预热以验证流水线，阶段 1（开发）在从 141 个公共池中提取的 11 个场景上进行，以及阶段 2（评估）在来自未见资产类别的 11 个新场景上进行泛化测试。

每赛道的（$C_{t\_t}$）得分结合了公共组件、隐藏组件和语义 $t$-match 信号：

$$ C_t = 0.6 \, S^{\text{pub}}_t + 0.3 \, S^{\text{priv}}_t + 0.1 \, \tau_t, \quad F = 0.4 \, C_{\text{plan}} + 0.6 \, C_{\text{exec}}, \quad \Delta = S_{\text{priv}} - S_{\text{pub}} \quad (1) $$

其中 $t \in \{\text{plan}, \text{exec}\}$，语义 $t$-match 得分（$\tau_t$），$F$ 是最终排名得分，$\Delta$ 表示公共得分与隐藏得分之间的差异。执行（$C_{\text{exec}}$）的权重（60%）高于规划（$C_{\text{plan}}$）（40%），反映了组织者认为在真实工具使用条件下进行稳健执行是更困难且更相关于部署的挑战。我们将在第 3.2 节回到这两个设计选择，其中评分公式对 $t$-match 尺度的敏感性变得相关。

组织者选择每个团队在每个赛道的最高分公共排行榜提交作为留出评估的标准条目。评估场景的完整细节见附录 D.2。

### 2.2 工件、分析数据与计数惯例

比赛产生了六个相互关联的工件类别，共同重建了每个阶段。这些包括注册、提交、得分、团队选择和解决方案代码。**参与数据**涵盖 149 个团队，注册表记录了团队组成和机构隶属关系。**提交记录**包含一个 300 行的服务器日志，带有时间戳、状态、公共得分、智能体轨迹以及与团队身份链接的用户名。**评分数据**包括最佳提交导出和官方排名工作簿，其中揭示了隐藏得分、$t$-match 值和聚合公式。来自组织者获奖报告的**定性证据**为顶级团队的选择提供了背景。**平台文档**，涵盖公开挑战页面和起始套件指南，为关于允许编辑的所有主张奠定了参与者收到指示的基础。**代码级证据**提供了顶级团队实现内容的真相。

电子表格需要少量清理。我们规范化大小写变体（例如，Infinity/infinity），删除空白行，保留每个团队的最新注册表，并通过保留较高的公共得分来解决来自同一团队的重复规划条目。

##### 计数惯例
我们在整篇论文中保持不同的分母分开：
*   **声明的成员名额** 是注册表上的人员级别条目；
*   **注册团队** 是保留每个团队最新表单后的 149 个团队记录；
*   **平台参与者** 是仅在跨比赛规模比较中使用的公共 Codabench 级别元数据。
*   **提交尝试** 是 300 行服务器日志中的一行，而 **已完成提交** 是完成平台评估的 234 次尝试之一。
*   排行榜和留出分析使用选定的最佳团队-赛道提交，而非所有尝试。
*   方法分类学使用 331 个可访问的源代码级工件，这些是可用于策略分析的代码工件，不被视为额外的服务器日志尝试。
*   成本和失败分析在轨迹文件上运行，其中一个文件记录每个场景的执行痕迹。

## 3 比赛结果与回顾分析

### 3.1 参与漏斗、平台现实与最终排行榜

**表 1：参与漏斗统计数据**

| 统计量 | 值 |
| :--- | :--- |
| 注册团队 | 149 |
| 声明的成员名额 | 349 |
| 本科生 | 45.8% |
| 行业专业人士 | 27.8% |
| 硕士/博士 | 22.3% |
| 其他 | 4.0% |
| 多用户名团队 | 78/149 (52.3%) |
| 记录在案的尝试 | 300 |
| ✔ 完成 | 234 (78.0%) |
| ✗ 失败 | 53 (17.7%) |
| ❍ 取消 | 9 (3.0%) |
| ◼ 进行中 | 4 (1.3%) |
| 非零公共得分团队 | 24 + 1 匿名 |
| 完全排名团队 | 11 |
| 跨赛道账户 | 4/11 |

比赛注册和排名需要通过三个独立的阈值：提交注册表、产生有效的已评分提交以及填充两个赛道。如表 1 所示，在 149 个注册团队中，24 个通过了第二个阈值，11 个通过了第三个阈值。这种流失模式并非偶然；它是实践中平台中介智能体评估成本的一项直接实证度量。

##### 漏斗与摩擦
注册需要两个步骤：用于团队元数据的 Google 表单和每个成员的个人 Codabench 注册。在七个半星期内（2025...