openrca2-lite-v4

该数据集包含两个版本（openrca2-lite-v4和dataset_v3_500_2026-05-03），主要用于根因分析（RCA）评估。数据集包含500个精选案例，每个案例包含服务图、推理结果和标签等信息。数据来源包括AegisLab的detector_success系统（ts、hs、otel-demo）和FSE/openrca2。数据集采用分层布局，包含manifest.jsonl和多个案例目录，每个案例目录包含injection.json、causal_graph.json、result.json、label.txt等文件。v3版本相比v2版本采用了新的基于清单的路径构建器，显著减少了候选路径数量，并优化了服务图结构。数据集包含多种混沌家族（如Network*、Pod*、HTTP*等）和不同长度的传播路径（longest_path从2到7不等）。选择规则包括系统上限、家族上限、根服务上限等硬性过滤器，以及混合与叶子节点的软性约束比例。

原始信息汇总

数据集概述：openrca2-lite-v4

基本信息

• 数据集名称：openrca2-lite-v4
• 来源地址：https://huggingface.co/datasets/anon-ops/openrca2-lite-v4
• 版本说明：基于 openrca2-lite-v3 的 500 个案例选择与目录结构，使用 rcabench-platform 提交 9b6661dac80ac3f16dc87c9b777c91f981e02637 的 v4 推理输出刷新了每个案例的 causal_graph.json、result.json 和 label.txt 文件。
• 导出审计结果：500/500 案例成功生成了 causal_graph.json、500/500 生成了 result.json、500/500 的 label=attributed，无硬导出错误，无未知根节点。注入时间窗口包含 5 秒的下游预窗口宽限以吸收时间戳桶抖动。

数据布局

数据集目录结构如下：

openrca2-lite-v4/ ├── manifest.jsonl ├── README.md └── cases/ └── <case-name>/ ├── injection.json ├── causal_graph.json # v4 图 ├── result.json # v4 推理结果 ├── label.txt # v4 标签 ├── env.json └── *.parquet

底层数据集：dataset_v3_500_2026-05-03

构建背景

• 构建日期：2026-05-03
• 构建方式：使用清单驱动的因果图推理器（rcabench-platform PR #370 / forge-rework）重建。
• 原始池：与 v1/v2 相同的 1464 个案例池（_pool_v1_2026-05-02），数据来源为 FSE/openrca2 和 AegisLab detector_success 最近 48 小时数据。
• 关键变化：每个案例的地面真实因果图由新的故障种类清单扩展生成，而非传统的仅规则传播器。

v3 与 v2 的对比

对比项	v2	v3	变化
推理器	规则后过滤	清单驱动层扩展	—
平均最长路径	3.64	3.18	−0.46
平均边数	5.62	4.06	−1.56
平均服务数	4.61	3.97	−0.64
最大最长路径	9	7	−2
最长路径 ≥ 4 的案例	130 (26%)	194 (39%)	+64
最长路径 = 2 的案例	125 (25%)	210 (42%)	+85
最长路径 = 3 的案例	194 (39%)	96 (19%)	−98
两版本共有案例	—	263	—
替换案例	—	237	—

v3 中间层（最长路径=3）缩小，深层（最长路径≥4）和浅层（最长路径=2）均增长。这是清单驱动推理器在入口签名仅匹配一个节点时，能够深入推理或立即终止的结果——减少了中间“软3跳”猜测。

最终组成（500 案例）

来源 × 系统分布

	ts	hs	otel-demo	总计
旧（FSE/openrca2）	0	0	0	0
新（AegisLab detector_success）	320	142	38	500
总计	320	142	38	500

otel-demo 从 v2 的 64 个减少至 38 个，因为清单推理器只保留了 64 个中的 43 个（其余出现循环或最长路径≤1）；ts 和 hs 填补了空缺。

混沌家族分布

家族	数量	占比
hybrid_clean	150	30.0%
Network*	97	19.4%
Pod*	82	16.4%
hybrid_kill	67	13.4%
HTTP*	60	12.0%
*Stress	24	4.8%
JVM*	19	3.8%
DNS	1	0.2%

hybrid_clean 达到 150 上限。JVM*/*Stress 家族数量较 v2（分别为 35/43）明显减少，因为这两个家族的清单入口签名更严格（JVM CPU/GC 持续阈值），导致许多池案例在到达第一层前即变为无路径。

混合与叶节点划分 hybrid:leaf = 217:283 (43.4% : 56.6%)，处于 v1/v2 使用的 [40:60, 60:40] 范围内，无需人工比例强制。

最长路径直方图

最长路径	数量
7	1
6	23
5	57
4	113
3	96
2	210

选择规则

• 系统容量上限：ts 320、hs 180、otel-demo 150
• 家族容量上限：150
• 根节点容量上限：30（任何单根服务在所有家族中）
• 硬过滤条件：丢弃循环服务图、丢弃最长路径 ≤ 1（单服务爆破，无传播）、丢弃前端注入（loadgen / ts-ui-dashboard / frontend / frontend-proxy）、丢弃缺失或格式错误的 injection.json / engine_config
• 排序规则：按最长路径降序、边数降序、服务数降序、名称升序排序
• 约束条件：hybrid:leaf ∈ [40:60, 60:40] 的比例守卫作为软约束保留，仅在选择 200 个案例后生效；两轮选择器在 Pass 1 不足 500 时放宽约束以填满剩余名额。

底层数据集布局

dataset_v3_500_2026-05-03/ ├── manifest.jsonl # 500 行，每行一个 JSON 案例 ├── README.md └── cases/ └── <case-name>/ # 符号链接 → 原始案例目录 ├── injection.json # 地面真实（engine_config + display_config） ├── causal_graph.json # 清单驱动的服务图（本次重建） ├── env.json ├── result.json ├── label.txt └── .parquet # 12 个 parquet 文件：abnormal_ + normal_*

manifest.jsonl 每行结构示例： json { "name": "ts0-ts-order-service-exception-l2bqm5", "source": "old|new", "system": "ts|hs|otel-demo", "longest_path": 7, "n_svc": 13, "n_edge": 21, "n_alarm_svc": 2, "root_services": ["ts-order-service"], "chaos_family": "JVM*|HTTP*|Network*|Pod*|*Stress|DNS|Time|hybrid_clean|hybrid_kill", "primary_kind": "<chaos_type or hybrid>", "subtypes": ["<sorted unique chaos_types>"], "hybrid": false, "has_kill_leg": false, "src_path": "/abs/path/to/original/case/dir" }

可复现性步骤

1. 从 /dataset/rca/、/detector_success_last13h_2026-05-02/、/detector_success_last48h_gap_2026-05-02/ 创建 1464 个案例池的符号链接包装到 _pool_v1_2026-05-02/<case>/converted/，并为每个案例添加 <case>/.valid 标记。

2. 使用清单驱动推理器（rcabench-platform 提交 a130d11 或之后，PR #370 合并后）运行推理批处理： bash ./cli/reason.py reason batch --data-base-dir _pool_v1_2026-05-02 --max-workers 12 --max-hops 15 --force

3. 将 pool/<case>/converted/{causal_graph,result,label,no_*.*} 同步回原始源案例目录。

4. 运行筛选脚本（构建会话中 /tmp/curate_v3.py），使用上述容量上限和硬过滤条件。

搜集汇总

数据集介绍

构建方式

OpenRCA2-Lite-V4数据集是基于V3版本选定的500个故障案例构建而成，其核心更新在于利用rcabench-platform平台特定提交（9b6661d）的V4推理引擎，重新生成了每个案例的因果图、推理结果和标签文件。该数据集的构建过程首先从包含1464个原始案例的池中，通过基于清单的因果图推理器（manifest-driven causal graph reasoner）而非传统的纯规则传播器，重新生成每个案例的地面真值因果图。随后，依据严格筛选规则（剔除循环服务图、最长路径≤1的案例及前端注入案例）和排序策略（按最长路径降序、边数降序、服务数降序、名称升序），结合系统容量上限（如TS系统320例、HS系统142例）和家族上限（150例），最终精选出500个案例。数据集的目录结构延续V3布局，每个案例文件夹包含注入配置、因果图、推理结果、标签、环境配置及Parquet时序数据文件，并配有manifest.jsonl索引文件。

使用方法

使用该数据集时，研究者首先需从HuggingFace下载完整仓库，其标准目录结构可直接用于评估因果图推理和根因定位算法。典型的使用流程包括：通过manifest.jsonl文件遍历所有案例，读取每个案例文件夹下的causal_graph.json进行图结构分析，利用label.txt获取地面真值标签，并以result.json中的V4推理输出作为基线对比。对于需要重新生成结果的研究，可依据README中的复现步骤，先构建1464案例池，运行rcabench-platform的推理批处理命令（设定最大工作线程为12、最大跳数为15），然后通过提供的筛选脚本（/tmp/curate_v3.py）复现精选过程。该数据集特别适合用于测试和对比基于故障清单的因果图推理方法与传统规则方法在根因定位上的性能差异，其中41例循环服务图的案例提供了独特的评估场景，其图F1指标标记为不适用，需注意在总体评分中排除。

背景与挑战

背景概述

OpenRCA2-Lite-V4数据集由AegisLab团队于2026年构建，面向云原生微服务系统中的根因分析（Root Cause Analysis, RCA）评估。该数据集聚焦于通过有向无环因果图来表征故障传播路径，旨在解决微服务拓扑中故障定位的基准缺失问题。作为OpenRCA2系列的精简评估集，它从1464个原始案例中精选500个实例，覆盖了ts、hs、otel-demo三种微服务系统和Network、Pod、HTTP等多种混沌故障族。其核心研究问题在于构建一个由故障清单驱动、消除过度假设的因果图生成范式，以更精确地反映故障合约定义的传播逻辑。该数据集在RCA领域具有里程碑意义，为因果图推理器的准确性和鲁棒性提供了标准化的评估框架，推动了微服务可观测性与自治诊断技术的发展。

当前挑战

该数据集面临的核心挑战在于解决微服务根因分析中因果图稀疏性与噪声的平衡问题。具体而言，传统规则级联传播器在每个案例中平均生成463条候选路径，导致高密度的假阳性边和幻觉节点，而新方法虽将平均边数降至4.06，但可能遗漏弱信号的传播路径，形成召回率损失。构建过程中，41个案例因服务图出现循环而在新推理器下被标记为图F1不适用，另有10个案例因最长路径不足2跳而被剔除，这暴露了现有注入设计在复杂拓扑下的因果完备性缺陷。此外，维持混沌故障族（如hybrid_clean的150个上限）与根服务分布（单根上限30）的多样性，在剔除无效案例后需重新调优选择策略，增加了数据集的版本迭代成本。

常用场景

经典使用场景

openrca2-lite-v4是面向微服务架构下异常根因定位（Root Cause Analysis）任务的核心评估数据集。该数据集由AegisLab精心构建，涵盖ts、hs及otel-demo等三类典型微服务系统，共包含500个经过严格筛选的故障注入案例。每个案例均配备完整的因果图谱（causal_graph.json）、精确的根因标签（label.txt）以及推理结果（result.json），为研究者提供了标准化的基准测试环境。其经典使用场景包括：评估根因定位算法在因果关系图谱构建中的准确性、验证跨服务故障传播路径的追踪能力，以及比较不同推理范式（如规则驱动与清单驱动）在真实微服务拓扑中的诊断效能。通过丰富的故障类型覆盖（涵盖网络、Pod、HTTP、JVM等7大类混沌工程家族），该数据集能够全面考察根因分析系统在复杂服务依赖关系下的鲁棒性和精确度。

解决学术问题

该数据集旨在解决微服务根因定位研究中长期存在的基准不一致与因果图质量参差问题。相较于传统的v2版本，openrca2-lite-v4通过引入清单驱动的因果路径构建器替代旧有的规则后置过滤方法，显著降低了因果图谱中的假阳性边与幻觉节点数量（平均边数从5.62降至4.06），同时提升了长路径（lp≥4）案例的占比至39%。这一革新直接回应了学术界对于因果推断基准真实性的迫切需求——过去大量研究因使用过度膨胀的候选路径（v2平均每案例463条）而导致评估结果的偏倚。通过标准化500个精选案例的因果结构与标签，该数据集使得不同根因定位方法（如图神经网络、反事实推理）的横向对比成为可能，有效推动了该领域从定性分析向可复现的定量评估范式转型。

实际应用

在实际运维场景中，openrca2-lite-v4为工业级根因定位系统的开发与迭代提供了关键支撑。基于该数据集，运维团队能够对故障定位平台进行严格的压力测试与效能评估，例如验证新一代清单驱动推理引擎（如rcabench-platform）在真实混合故障（hybrid_clean/hybrid_kill）场景下的诊断准确率。其包含的41个循环服务图案例更模拟了实际生产环境中常见的服务循环依赖困境，促使根因定位系统必须具备处理复杂拓扑的容错能力。此外，该数据集支持离线批量推理与在线增量评估双模式，已被集成到多个开源可观测性工具链中，帮助SRE工程师快速筛选最优的告警收敛策略与故障注入验证方案，显著缩短了从日志采集到根因定位的MTTR（平均修复时间）。

数据集最近研究

最新研究方向

面向云原生微服务系统的因果图溯源推理前沿——以OpenRCA2-Lite-v4数据集为例，该数据集作为根因分析（RCA）评估基准的最新迭代，其核心革新在于从传统的规则驱动后过滤范式跃迁至基于故障清单的逐层扩展推理机制。这一转变根植于云原生领域对故障传播路径精准建模的迫切需求，尤其呼应了近期业界关于可观测性数据质量与因果图保真度的热点讨论。通过将因果图生成逻辑从穷举路径的启发式剪枝，重塑为故障契约本身定义的传播语义，数据集有效抑制了图结构的虚假膨胀（平均边数从5.62降至4.06），并系统性暴露了41例循环服务依赖等先前被忽略的拓扑异常。此举不仅为后续基于图神经网络的根因定位研究提供了更清洁的基准，更推动了智能运维（AIOps）领域从信号驱动的关联分析向契约驱动的因果推理的转型，对构建高可信度的自愈系统具有里程碑意义。