ITBench-AA 评估企业 IT 代理性能

关键信息

ITBench-AA 的首个版本包含 59 个 SRE 任务，其中 40 个公开任务、19 个留出任务。每个任务都提供 Kubernetes 事故快照，包含告警、事件、链路、指标、日志和拓扑信息，模型必须在 100 轮上限内使用 Stirrup 执行环境找出最小的根因 Kubernetes 实体集合。

资讯摘要

Artificial Analysis 和 IBM Software Innovation Lab 发布了 ITBench-AA，并将其称为首个面向企业 IT 代理任务的基准系列。首个版本聚焦站点可靠性工程（SRE），也就是 Kubernetes 事故响应，要求模型通过阅读日志、追踪依赖关系、识别事故背后的根因实体来完成诊断。底层的 ITBench 数据集由 IBM 开发，Artificial Analysis 在过去 6 个月里将其改造成面向前沿 AI 模型的评测框架。此次 SRE 版本共包含 59 个任务，其中 40 个为公开任务，19 个为留出任务。每个任务都提供一份事故快照，包含告警、事件、链路、指标、日志和应用拓扑，模型需要输出结构化 JSON，标明相关的 Kubernetes 实体，例如 Deployment、Service 或 Pod。

基准覆盖了常见的 SRE 故障模式，包括资源配额耗尽、发布失败、连接池耗尽、网络分区，以及基础设施、服务、应用和混沌注入类事故。所有模型都在同一个开源 Stirrup 参考执行环境中运行，拥有沙箱文件系统的 shell 访问权限，每个任务最多 100 轮，并重复 3 次。评分方式采用“完全召回下的平均精度”：如果模型在一次重复中漏掉任何一个真实根因，就会得到 0 分；只有找全所有真实根因后，才按精度计分。结果显示，Claude Opus 4.7 以 47% 领先，其次是 GPT-5.5 的 46% 和 Qwen3.7 Max 的 42%，但所有前沿模型都没有超过 50%。报告还指出，调查轮次更多并不一定意味着更准确，因为一些模型会过度排查，把上游故障注入机制或伴随症状误判为根因。

资讯正文

ITBench-AA：首个面向代理式企业 IT 任务的基准中，前沿模型得分低于 50% —— 由 Artificial Analysis 与 IBM 联合推出

Artificial Analysis 和 IBM Software Innovation Lab 正在推出 ITBench-AA，这是一个全新系列基准中的首个基准，用于评估模型在代理式企业 IT 任务上的表现；首批任务聚焦站点可靠性工程（Site Reliability Engineering，SRE）任务，而前沿模型的得分低于 50%。

ITBench-AA 的 SRE 任务基准用于衡量模型在 Kubernetes 事故响应中的表现，在这类任务中，模型和智能体必须通过阅读日志、追踪依赖关系，并在复杂基础设施中识别根因实体来诊断实时系统。其底层 ITBench 数据集由 IBM 开发，借助了其在企业 IT 运维方面的深厚经验。

过去 6 个月里，Artificial Analysis 一直与 IBM 密切合作，开发该数据集面向前沿 AI 评估的实现版本，起步于站点可靠性工程（SRE），并计划随着时间推移扩展到财务运营（FinOps）和首席信息安全官（CISO）任务。

- Claude Opus 4.7（Adaptive Reasoning，Max Effort）以 47% 领先，其后是 GPT-5.5（xhigh）的 46% 和 Qwen3.7 Max 的 42%。

- 所有前沿模型的得分都低于 50%，使得 ITBench-AA SRE 成为我们套件中饱和度最低的代理式基准之一。作为对比，前沿模型在 Terminal-Bench 上的得分要高得多。

- 轮次次数差异接近 3 倍，而更长的推理轨迹并不会转化为更高的准确率。GPT-5.5（xhigh）在得分 46% 时，平均每个任务进行 31 轮；Gemini 3.1 Pro Preview 在得分 30% 时，平均每个任务进行 83 轮。过度调查的模型往往会把上游故障注入机制或同时出现的症状误判为假阳性。

- GLM-5.1（Reasoning）在开放权重模型中以 40% 领先，实际上与 Gemini 3.5 Flash（high）并列。DeepSeek V4 Pro（Reasoning，Max Effort）以 38% 紧随其后，Gemma 4 31B（Reasoning）以 37% 位列其后，领先于得分 30% 的 Gemini 3.1 Pro Preview。

- SRE 任务总计 59 个：40 个公开任务和 19 个全新的留出任务。

- 每个任务都提供一个 Kubernetes 事故快照，其中包含告警、事件、追踪、指标、日志以及应用拓扑。模型必须识别出导致该事故的、彼此独立的最小根因 Kubernetes 实体集合。

- 故障覆盖了典型的 SRE 失效模式，包括基础设施、服务、应用以及由混沌注入的事故，例如资源配额耗尽、发布失败、连接池耗尽和网络分区。方法细节：

- 代理式执行框架：每个任务都由模型在我们开源的 Stirrup 参考框架中完成，框架提供对包含相关日志和快照的沙箱文件系统的 shell 访问。每个任务最多 100 轮，且每个任务重复 3 次。

- 模型和智能体提交它们认为导致事故的根因实体列表（Kubernetes Deployments、Services、Pods 等）。每次提交都会与 IBM 提供的根因真实集进行比对。

评分采用在完全召回下的平均精确率：如果模型遗漏了任何真实根因，那么该次重复的得分就是 0.0。若它识别出了全部真实根因，则其得分等于精确率——也就是其提交实体中实际属于根因的比例，即真正例 /（真正例 + 假正例）。标题分数是 59 个任务 × 3 次重复的平均值。

评测框架（Stirrup）在所有被评估的模型之间保持不变，从而可以进行真正的同类对比。

这些任务要求代理通过 shell 命令调查 Kubernetes 事故快照，并提交一份结构化 JSON 诊断，识别负责的根因实体。在一个公开的 SRE 任务中，代理会看到前端路径上的用户可见故障。它使用 shell 命令检查离线快照：查看告警可以了解到事故窗口，然后 traces/logs 将故障范围缩小到前端流量。拓扑图确定了受影响的服务，而 Kubernetes manifests 则揭示了一个阻止前端的网络策略。成功的诊断会识别出负责的根因实体：otel-demo/NetworkPolicy/frontend-block-all-ports。

更多轮次并不意味着更好的答案。那些除了真实根因之外还提交了额外相关实体的模型会被扣分：即便识别出了正确根因，但又加上了上游机制（例如 chaos-mesh controller）或同时出现的症状，在这种召回门控精确率下都算作假正例。这也是为什么一些轨迹很长的模型反而不如更简洁的模型：Gemini 3.1 Pro Preview 平均 83 轮，得分 30%，而 Gemma 4 31B（Reasoning）平均 58 轮，得分 37%。

更多信息请参见：arXiv 上的 ITBench 论文：https://arxiv.org/abs/2502.05352

GitHub：https://github.com/itbench-hub/ITBench

ITBench-AA 排行榜：https://artificialanalysis.ai/evaluations/itbench-aa

ITBench-AA HuggingFace 仓库：https://huggingface.co/datasets/ArtificialAnalysis/ITBench-AA/tree/main/sre

来源与参考

1. 原始链接
2. ITBench-AA: Frontier Models Score Below 50% on the First Benchmark for Agentic Enterprise IT Tasks — by Artificial Analysis and IBM