BlastRadiusBench

BlastRadiusBench是一个用于评估AI模型重构故障链能力的基准测试数据集。它包含多个场景，模拟了生产环境中的级联故障，提供遥测数据（如跟踪、指标、日志、Kubernetes事件）和服务依赖图，要求模型识别故障的起源、传播路径、根本原因和影响范围。BlastRadiusBench is a benchmark dataset for evaluating the capability of AI models to reconstruct failure chains. It comprises multiple scenarios that simulate cascading failures in production environments, providing telemetry data such as traces, metrics, logs, and Kubernetes events, as well as service dependency graphs. This setup requires models to identify the origin, propagation paths, root causes, and impact scope of failures.

原始信息汇总

数据集概述

BlastRadiusBench 是一个用于评估前沿大语言模型（LLM）在分布式系统故障中推理因果链能力的开放基准测试。其核心任务是让模型从 traces、metrics、logs、k8s events 和服务依赖图中，识别出故障的根因服务、传播路径（有向的边）以及爆炸半径（受影响的受害者），并抵抗“最响警报”的误导。

核心评估指标

模型需生成 /workdir/failure_chain.json 文件，包含：

• origin_service: 最先失败的服务。
• propagation_path: 故障传播的有向边列表。
• root_cause: 根本故障原因。
• blast_radius: 受故障影响的下游服务列表。

主要奖励（二值化）：

• origin_service 正确，且 propagation_path 中恢复的有向因果边数量达到场景阈值（默认 0.6）。

次要指标（仅打印，不影响评分）：

• 爆炸半径重叠度。
• 根因关键词匹配（识别故障本身而非症状）。
• 反向因果计数：模型将下游受害者误判为上游服务的原因的边数，这是最典型的诊断错误。

运行机制

• 基于外部 Harbor 框架和 Terminal-Bench 任务格式运行，使用默认 terminus-2 agent。
• 每个场景是一个沙盒化的 Docker 容器，挂载遥测数据到 /workdir，提供 jq、grep、awk、python3 等 CLI 工具。
• 模型通过 OpenRouter 进行切换，确保对比公平。
• 结果由 pytest grader 自动评分。
• 如果使用 Edge Delta 产品查询遥测数据，需使用 CQL（如 severity_text:"ERROR"、@latency_ms > 1000），沙盒中则直接 grep/jq 原始文件。

任务格式

每个场景位于 datasets/blastradiusbench/<scenario>/ 目录下，包含：

• task.toml：任务配置文件。
• instruction.md：指令文件。
• environment/：Dockerfile 和工作目录数据。
• solution/solve.sh：标准答案脚本。
• tests/：评分器与隐藏的真实答案。

结构详情见 数据集 README。

难度等级与场景

共 10 个场景，前 3 个为合成微服务级联故障，后 7 个为真实生产事故的重构（服务名、日志签名等均为虚构替代，但故障类真实）。部分场景及难度：

场景	难度	原因
shared-postgres-saturation	medium	边缘网关警报最响但为最后受害者，级联扩散成树状。
retry-storm-amplification	hard	重试放大导致调用者负载飙升，真实起源为下游慢速服务，经典反向因果陷阱。
noisy-neighbor-node	hard	三个无关服务同时失败，唯一联系为共享节点，仅基础设施事件可见。
fdb-tso-flink-cascade	hard	Flink 作业不健康警报为最后受害者，起源为上游四个跳的 TSO FDB 超时。
backend-connectivity-cascade	hard	边缘网关延迟/5xx 最响，真实起源为后端写分片容量丢失。
shared-kafka-saturation	medium	边缘网关流量激增，实为下游慢速消费者背压导致，反向因果陷阱。
disk-pressure-noisy-neighbor	hard	三个命名空间中无关服务同时被驱逐，唯一联系为共享节点，每个受害者均有干扰线索。
shared-redis-eviction	medium	被依赖服务 5xx 最响，起源因探针配置错误被 kubelet 杀死。
memory-pressure-eviction-cascade	hard	查询失败 5xx 最响，链始于节点驱逐某服务的 Pod。
shared-dynamodb-throttle	medium	重试放大使调用者看起来像震中，起源为被节流的 DynamoDB 内存存储。

排行榜（节选）

固定运行：17 个场景 × 17 个模型 × 3 次尝试 = 867 次实验。Harbor terminus-2 over OpenRouter，2026 年 6 月 30 日至 7 月 2 日。Pass 率为场景评分器的布尔判决。完整结果见 benchmark-results/。

模型	通过率	easy	medium	hard
glm-5.2	63%	100%	83%	53%
gpt-5.4	62%	100%	92%	49%
gpt-5.5	59%	100%	100%	42%
gemini-3.1-pro-preview	55%	100%	64%	49%
claude-sonnet-4.6	49%	100%	58%	42%
claude-opus-4.8	48%	100%	75%	34%
gemini-3.5-flash	47%	67%	75%	36%
deepseek-v4-flash	47%	100%	83%	31%
kimi-k2.5	46%	100%	75%	31%
gpt-5.4-mini	45%	67%	67%	36%
gemini-3.1-flash-lite	45%	100%	67%	33%
kimi-k2-thinking	42%	67%	50%	37%
qwen3-235b-a22b-2507	41%	67%	50%	36%
claude-haiku-4.5	27%	100%	17%	25%
gpt-oss-120b	25%	33%	17%	28%
qwen3-32b	20%	33%	17%	19%
gpt-oss-20b	6%	0%	25%	0%

场景生成方法

• 原始 3 个场景：对真实微服务应用（如 OpenTelemetry Astronomy Shop）进行故障注入。
• 其余 7 个场景：基于真实生产事故重构，服务名、日志签名等为虚构替代，但故障类型真实（如 FoundationDB/TSO 超时、OLAP 存储后端连接丢失、SQS 队列积压、节点 DiskPressure/MemoryPressure 驱逐、探针配置错误 CrashLoopBackOff、DynamoDB 写入节流）。
• 生成步骤：
  1. 在稳定负载下运行微服务演示。
  2. 固定每个服务的 git 提交，选择其中一个作为罪魁祸首并注入故障（如缩容 DB 连接池、添加无边界内存批处理、减少 co-located 任务的内存限制）。
  3. 记录级联发展过程（约 10-15 分钟遥测窗口，覆盖基线→爆发→升级）。
  4. 降采样至几 KB，保留被干扰掩盖的初期信号。
  5. 组装上下文：真实提交列表（罪魁祸首+干扰项）、部署事件（包含无干扰部署以惩罚“归咎于最近变更”）、功能标志变更（诱饵）。
  6. 手动标注 ground_truth.json（起源、有向边、根因+罪魁祸首 sha、爆炸半径），并将其排除在 agent 的容器之外。

构建自定义场景

使用工具生成模板，再替换真实遥测窗口数据：

bash uv run tools/generate_scenario.py my-scenario --services api,web,svc,db --origin svc --difficulty hard --distractors 4

许可协议

Apache-2.0。版权所有 Edge Delta, Inc。

搜集汇总

数据集介绍

构建方式

BlastRadiusBench的构建遵循了严谨的故障注入与事故重建双轨方法论。前三个场景基于真实微服务应用（如OpenTelemetry Astronomy Shop）进行受控故障注入，在稳定负载下锁定服务提交版本，选定一个提交作为罪魁祸首并注入代码变更相关的现实故障（如缩小数据库连接池、增加无界内存批处理或移除容器内存限制），待级联效应充分发展后记录约10至15分钟的遥测窗口，覆盖基线、发生与升级的全过程，随后降采样至可读体量以保留隐藏于无干扰信号中的首个微弱征兆。其余七个场景则来源于代表性生产事故的重建，其服务名、日志签名、队列名称、节点标识及提交哈希均为虚构替身，但故障类别真实可靠——涵盖FoundationDB事务超时、后端存储连接丢失、节点磁盘与内存压力驱逐、探针配置错误导致的崩溃回退以及DynamoDB写入容量节流。每个场景均组装完整的上下文物件：包含罪魁祸首与干扰项的提交列表、在事故发生时刻部署的无辜变更（用以惩罚‘归咎最新变更’的倾向）以及功能开关改造作为诱饵。最终由人工精确标注ground_truth.json，记录根源服务、方向性传播边、根因描述、罪魁祸首SHA及爆炸半径，该文件严格存放于智能体容器之外。

特点

该基准测试的核心特性在于其对因果推理能力的深度探测与多维度量化评价。它要求模型不仅识别出最先失败的服务和最终的受害者集合，更需重建故障沿服务间调用的有向传播路径，而传播方向与请求流向恰好相反——慢速的被调用者会阻塞其调用者，因此因果箭头从下游指向上游。测评输出为JSON格式结果，包含起源服务、传播边列表、根因描述与爆炸半径。主要奖励为二元判定：起源服务正确且传播边的有向召回率达到每个场景预设阈值（默认0.6）。副指标则提供更丰富的诊断信息——爆炸半径与真相的重叠度、根因关键词匹配检测（分辨模型是准确指出故障还是仅描述症状），以及最重要的反转因果计数，即模型将下游受害者错误地归因为上游服务故障的边数，这是事故推理中最具诊断价值的错误类型。十组场景分为容易、中等与困难三个难度层级，困难场景特意设置了反转因果陷阱、共享节点故障（无调用边但共享同一物理节点）以及不同故障模式间的耦合干扰，全面考验模型抵抗‘最响亮告警引力’的能力。所有场景的运行均基于Harbor框架和Terminal-Bench任务格式，模型通过OpenRouter统一接入，确保数据与工具完全一致，仅测评推理能力之差。

使用方法

使用者可通过简单的命令行流程完成全链条复现。首先克隆仓库并设置环境变量，在.env文件中填入OpenRouter API密钥。烟雾测试使用单模型单场景快速验证系统运行：执行source .env && uv run harbor run -c configs/smoke-docker.yaml。全面评测则运行configs/all-models-docker.yaml配置，系统将自动对所有场景进行多模型多次数（如17个模型×3次尝试）的交叉测试。运行后通过的脚本uv run scripts/process_results.py jobs/<timestamp>可将结果汇总为Markdown格式排行榜。每个场景均以沙盒化Docker容器的形式呈现，遥测数据挂载于/workdir目录，容器内标配jq、grep、awk、python3等CLI工具，智能体通过Terminus-2代理自主排查并生成failure_chain.json。该基准测试还提供了场景生成器：通过uv run tools/generate_scenario.py命令指定服务列表、起源服务、难度等级及干扰项数量，即可快速搭建一个完全通过自身预言机验证的新场景，用户仅需替换environment/workdir目录下的遥测数据即可复用全部框架。此外，任何支持CLI的智能体（如Claude Code、Codex、Cursor）均可直接指向场景容器的/workdir目录完成推理。

背景与挑战

背景概述

在分布式系统日益复杂的当下，故障的传播往往如涟漪般层层扩散，而准确识别根因与影响范围始终是运维领域悬而未决的难题。BlastRadiusBench由Edge Delta于2025年创建，旨在系统性地评测前沿大语言模型在因果推理上的边界。该基准通过构建10个涵盖合成微服务与真实生产故障重演的场景，要求模型从遥测数据中分离根因與故障辐射范围，并还原故障传递的有向路径。其核心研究问题在于：模型能否抵御“最响亮警报”的引力，避免倒置因果箭头？这一基准的开源发布，为分布式系统可观测性领域注入了客观的认知标尺，推动模型从模式匹配向真正的因果推理演进。

当前挑战

BlastRadiusBench所直面的核心挑战，在于破解分布式系统中因果推理的多重困境。首先，故障传播方向通常与请求流向相反——缓慢的下游服务会阻塞上游调用者，但监控往往将流量激增误判为源头，形成经典的因果倒置陷阱。其次，共享基础设施故障（如节点内存耗尽）可同时击垮多个无调用关系的服务，其唯一边际隐匿于基础设施事件中，极易被模型忽略。在基准构建中，挑战同样艰巨：需在有限遥测窗口内埋设“无辜部署”与特性标记作为干扰项，平衡信号稀疏性与场景逼真度，同时确保每个场景都保留可被人类专家解读的故障链线索，避免沦为统计噪声的堆砌。

常用场景

经典使用场景

在微服务架构日益复杂、故障传播路径扑朔迷离的运维场景中，BlastRadiusBench致力于评估前沿大语言模型对分布式系统级联故障的因果推理能力。该数据集提供了十个精心设计的故障场景，包括合成微服务故障和生产级事故重构，如共享数据库连接池耗尽、重试风暴放大、节点资源争抢等。每个场景都封装在独立的沙箱容器中，包含真实的遥测数据（如链路追踪、指标、日志、Kubernetes事件及服务依赖图）。研究人员可驱动智能体在隔离环境中自主探查数据，最终输出故障链的根因服务、传播路径、根因描述及爆炸半径，以检验模型从蛛丝马迹中还原因果顺序的经典能力。

衍生相关工作

BlastRadiusBench的发布催生了一系列围绕大语言模型因果推理能力的衍生研究。该数据集直接支撑了面向开源模型（如Qwen系列、GLM系列）的对比排行榜，揭示了不同参数量级模型在复杂故障场景下的显著能力差异。其场景生成工具（generate_scenario.py）被社区用于自动化构建定制化故障注入环境，推动了分布式系统可观测性数据的合成与评估方法学发展。此外，该工作所定义的“倒置因果边计数”等诊断指标，已被后续研究采纳为评估智能体逻辑一致性的重要维度。围绕数据集中共享PostgreSQL饱和、重试风暴放大等经典场景，研究者进一步探索了基于思维链提示的故障推理增强技术，形成了从基准测试到方法论创新的完整研究链条。

数据集最近研究

最新研究方向

面向分布式系统故障根因因果链重建的大语言模型推理能力评估