遇见数据集

RootCauseBench

收藏
github2026-07-02 更新2026-07-04 收录
官方服务:

资源简介:

一个开源基准测试,将前沿大型语言模型置于冻结的生产事件中——包括警报、日志、指标、追踪、模式以及完整的变更上下文(提交、部署、功能标志)——并询问唯一关键问题:哪个提交导致了此问题?它通过终端基准任务运行,提供任务和数据集,用于评估模型在识别根因提交方面的能力。

An open-source benchmark that subjects state-of-the-art large language models to frozen production incidents—including alerts, logs, metrics, traces, patterns, and full change context (commits, deployments, feature flags)—and poses the sole critical question: Which commit caused this incident? Operating via terminal-based benchmark tasks, it provides task definitions and datasets to evaluate models' ability to identify the root-cause commit.

创建时间:
2026-06-26
原始信息汇总

数据集概述

RootCauseBench 是一个开源基准测试,旨在评估前沿大语言模型(LLM)在生产事故根因分析中的表现。其核心任务是:给定一个冻结的生产事故场景(包含告警、日志、指标、链路追踪、模式以及完整的变更上下文),模型必须找出导致事故的那一笔提交(commit)

核心评估指标

模型需要输出一个 JSON 格式的结果,包含以下字段:

json { "root_cause_commit": "<sha>", "first_failing_service": "<service>", "blast_radius": ["<svc>", "..."], "remediation": "rollback" | "roll-forward" | "config-revert" | "scale" | "feature-flag-disable" }

  • 主要奖励(唯一决定通过/失败的标准): root_cause_commit 是否精确匹配真实罪魁祸首的 SHA。
  • 次要信号(仅输出,不影响通过/失败): 首次故障服务正确性、爆炸半径与真实值的 Jaccard 重叠度、修复方案匹配度,以及模型是否被“无辜部署”所迷惑。

数据集构成

该基准测试包含 24 个冻结的事故场景,分为两类:

  • 真实罪魁祸首(17 个): 单一提交导致回归,模型必须通过阅读 diff 来命名其 SHA(提交信息已被中和,不会描述故障)。包含误导性结构,例如:跨服务/共享库罪魁祸首(故障服务未更改)、高分贝服务上的表面匹配诱饵、以及延时发作故障。
  • 无代码原因(7 个): 没有罪魁祸首提交,触发原因是操作/外部因素(上游提供商故障、云区域受损、DNS 降级、流量激增、嘈杂邻居节点、过期 TLS 证书、毒化数据记录),并植入了无辜提交作为诱饵。正确答案是 "none"

难度等级

等级 难点描述
简单 一个明显的罪魁祸首,清晰的失败特征(如 panic 堆栈跟踪),干扰项少。
中等 罪魁祸首埋在大约 40 个提交中,且一个无辜部署在事故附近出现作为诱饵。
困难 延时发作(错误部署在数分钟后爆发),多个无辜部署在事故附近,并在同一窗口内发生功能开关切换。

技术实现

  • 运行框架: RootCauseBench 是一组基于 Harbor 框架的 Terminal-Bench 任务,使用默认的 terminus-2 代理。
  • 运行流程: 每个任务启动一个 Docker 容器,将冻结的遥测数据放入 /workdir/data/,向模型提供一个包含 jq/grep/python3 的 shell 环境,并评估模型写入 /workdir/root_cause.json 的 JSON 结果。
  • 查询语言: 使用 EdgeDelta 的 CQL,支持字段相等性、布尔 AND/OR/否定、数值比较(如 @duration_ms > 3000)。

场景生成方式

场景是通过对真实微服务应用(GCP 的 microservices-demo / "Online Boutique" 的分支)进行故障注入,或对虚构平台上的代表性生产事故类别进行重构而生成的。生成步骤包括:

  1. 在稳定合成负载下运行应用。
  2. 编写一个引入真实回归类别的提交,并在同一窗口内配以数十个无辜提交。
  3. 部署罪魁祸首,同时部署一个或多个无辜变更并翻转功能开关。
  4. 捕获遥测窗口和变更上下文,冻结为小型的、内部时间一致的测试夹具。
  5. 输出 ground_truth.json

排行榜(部分结果)

以下为部分模型在 24 个场景 x 3 次尝试下的通过率(Pass rate):

模型 总体通过率 简单 中等 困难 无代码原因
glm-5.2 100% 100% 100% 100% 100%
claude-sonnet-4.6 99% 100% 100% 97% 95%
gemini-3.5-flash 99% 100% 100% 97% 95%
gpt-5.5 96% 100% 100% 91% 90%
gpt-5.4 96% 100% 100% 91% 90%
gemini-3.1-pro-preview 94% 100% 96% 91% 86%
claude-opus-4.8 93% 83% 92% 97% 100%
deepseek-v4-flash 92% 100% 96% 86% 76%
gpt-5.4-mini 90% 100% 96% 85% 100%
kimi-k2.5 85% 83% 100% 70% 71%
kimi-k2-thinking 85% 100% 92% 73% 71%
qwen3-235b-a22b-2507 72% 89% 70% 69% 71%
gpt-oss-120b 58% 83% 62% 48% 43%
gemini-3.1-flash-lite 56% 100% 62% 36% 14%
qwen3-32b 44% 89% 37% 39% 33%
claude-haiku-4.5 35% 67% 21% 36% 10%
gpt-oss-20b 28% 67% 29% 21% 52%

其他信息

  • 许可协议: Apache-2.0
  • 所属机构: Edge Delta, Inc.
  • 构建目的: 根因分析是事故处理中最慢、成本最高的环节,RootCauseBench 旨在中立地衡量 LLM 在此类跨信号推理任务上的真实能力。
搜集汇总
数据集介绍
RootCauseBench 数据集图片
构建方式
在故障注入与生产级微服务应用(Google Cloud的Online Boutique分支)的基础上,RootCauseBench构建了24个冻结的生产事件场景。每个场景通过以下步骤生成:在稳态负载下向单一服务注入真实回归类缺陷(如N+1查询、连接池耗尽),并行部署多个无辜变更与特征标记作为干扰项;捕获包含日志、指标、链路追踪及模式聚类的遥测窗口与变更上下文快照,确保故障爆发时间严格晚于恶意提交。最终将场景封装为Docker容器,附带完整的元数据、指令、环境文件及验证脚本,并显式标记凶手提交SHA、首个故障服务、爆炸半径与修复措施作为基准真相。
使用方法
研究人员可通过Harbor框架(uv tool install harbor)获取并运行该基准测试。所有任务基于Terminal-Bench标准,启动Docker容器后模型在受限shell环境中访问冻结的遥测数据(目录为/workdir/data/),使用jq/grep/python3等工具进行跨信号推理,最终将结果写入/workdir/root_cause.json的JSON文件中。评分系统严格以凶手提交SHA精确匹配作为通过条件,同时输出首个故障服务准确率、爆炸半径Jaccard重叠度、修复措施匹配度及是否被无辜部署诱饵误导等辅助指标。支持单场次测试与完整模型对比运行,并通过脚本生成按模型与难度分层的可复现排行表。
背景与挑战
背景概述
RootCauseBench是由Edge Delta团队于2026年创建的开源基准测试,旨在系统性评估大型语言模型在生产环境中定位引发故障提交的归因能力。核心研究问题在于:当深夜告警触发,面对数十个提交、多次部署与特征标志变更的复杂背景,模型能否从日志、指标、链路追踪与变更上下文中精确识别出罪魁祸首。该基准包含24个真实生产场景的复现,涵盖由代码变更引发的故障与无代码原因的运营事故,不仅要求模型辨别症状,更需跨越干扰项、延迟爆发与无辜部署的迷雾,最终输出确切的根因提交哈希。RootCauseBench填补了当前AI运维评测领域中缺乏严格因果推理协议的空白,推动语言模型从工具辅助者向事故分析核心决策者的角色跃迁。
当前挑战
数据集面临的核心挑战首先在于领域问题的复杂性:根因定位需同时处理多源信号(日志、指标、链路)之间的时间错位与语义鸿沟,尤其是延迟爆发故障中提交与告警间隔数分钟,模型需具备时间因果推理能力。构建过程中,团队面临合成场景的真实性难题——通过故障注入生成的微服务应用虽能控制变量,但虚构的服务名与日志签名必须足够逼真以避免模型学习到虚假关联;同时,干扰项的设计需精心平衡难度,无代码原因场景中植入的无辜提交作为诱饵,必须被模型正确识别并输出‘无根因提交’以测试其放弃推断的理性。此外,跨服务与共享库的根因场景要求模型理解并非故障服务自身变更引发的间接效应,这远超传统日志分类任务的能力边界。
常用场景
经典使用场景
在站点可靠性工程与智能运维的交叉领域中,RootCauseBench被设计为一项严苛的模型推理基准,其核心场景是将前沿大语言模型置于冻结的生产事故情境中,赋予其完整的遥测数据(告警、日志、指标、链路追踪、聚类模式)及变更上下文(提交记录、部署历史、功能开关),要求模型在仅凭命令行工具的条件下,精准定位导致服务降级的罪魁祸首提交。该基准通过分级难度设计——从单一明显故障源到埋藏于四十余次提交中的隐蔽缺陷,再到伴有延迟发作与无辜部署混淆的高阶场景——系统性地评估模型在嘈杂信息中辨析因果、抵制虚假关联的推理能力。
解决学术问题
RootCauseBench直面了人工智能在可观测性领域中长期悬而未决的核心悖论:大语言模型能否从海量异构信号中剥离表象、抵达根因。它解决了学术界在根因分析研究中的两个关键痛点——一是缺乏标准化、可复现的评估框架,二是现有基准多聚焦于症状识别而非提交级因果溯源。通过引入无辜部署诱饵、跨服务隐式故障源、以及延迟发作机制等精妙设计,该基准迫使模型不得不在“归咎最新部署”这一认知捷径与真正的因果链条之间做出抉择。其意义在于为智能运维领域树立了一个难以取巧的衡量标尺,促进了从症状匹配到因果推演的范式跃迁。
实际应用
在实际生产环境中,RootCauseBench所模拟的场景直击运维工程师最痛苦的时刻——凌晨三点,监控告警炸响,P99延迟飙升二十倍,数十次提交与多次部署交织缠绕。该基准指引下的模型能够将事故响应时间从数十分钟压缩至分钟级别,通过自动解析变更上下文与遥测信号的交集,准确输出根因提交哈希、首个故障服务、影响范围以及修复策略。尤其值得注意的是,基准中无代码原因场景的设计赋予了模型在缺乏明确代码缺陷时主动“弃权”的能力,这一特质在真实运维中至关重要,有效避免了错误归因导致的无效回滚与次生故障。
数据集最近研究
最新研究方向
当前前沿研究方向聚焦于利用大语言模型进行生产环境根因定位的自动化推理能力评估,特别是在复杂微服务架构下从海量遥测数据(告警、日志、指标、链路追踪)与变更上下文(提交记录、部署事件、特性开关)中精准识别引发故障的单一代码提交。该基准测试通过设计延迟发作、无辜部署诱饵、特性开关干扰等困难场景,系统性衡量模型区分因果与关联、抵抗诱饵、以及在无代码原因时正确弃权的能力。相关热点事件包括AI驱动运维自动化与LLM在故障排查中的可靠性争议,而RootCauseBench通过标准化的无偏评估框架揭露了主流模型在复杂根因分析中的能力边界,推动了大模型在可观测性领域的可信应用与改进方向。
以上内容由遇见数据集搜集并总结生成
二维码
社区交流群
二维码
科研交流群
商业服务