分布式系统出故障时,定位根因往往比修复更耗时。微服务调用链一拉就是十几层,日志散落在几十个节点,告警风暴里真正有用的信号可能只有一条。AIOps 和 AI Agent 被寄予厚望,但"这个 Agent 到底行不行"一直缺少一把公平的尺子——各家自报准确率,数据集不公开,评估协议各搞各的。
阿里云联合信通院、中科院软件所 / 计算机网络信息中心、清华大学、复旦大学、南开大学等机构,正式发布了 RCA Benchmark:业界首个从体系层面解决 AI Agent 分布式系统故障诊断能力评估的开源基准项目。它不只丢出一堆测试数据,而是把"考题、评分标准、考场规则"一起定义清楚。
为什么需要体系化的 RCA 评估基准
现有 AIOps 评估存在三个结构性问题:
- 数据集碎片化——不同团队用不同系统生成的故障数据,场景覆盖面窄,难以横向比较。
- 评估协议缺失——有的只看最终根因是否命中,有的看中间推理步骤,有的看定位耗时,指标定义不一致。
- Agent 行为不可复现——同一个 Agent 在不同环境、不同提示词下表现差异巨大,但没有标准化的"考场"来控制变量。
RCA Benchmark 的核心思路是:把评估当成一个完整的实验设计问题,而不是只提供一个答案集合。
数据集与评估协议:考题和评分标准一起给
RCA Benchmark 提供的不是一个扁平的 JSON 文件,而是一套分层结构:
| 层级 | 内容 | 作用 |
|---|---|---|
| 场景层 | 微服务、容器编排、网络、存储等典型分布式拓扑 | 定义"考哪类系统" |
| 故事层 | 每个故障场景的注入方式、传播路径、时间线 | 定义"考哪类故障" |
| 观测层 | 对应的 metrics、traces、logs 数据切片 | 定义"给考生什么线索" |
| 评判层 | 根因节点、推理链、可接受答案范围 | 定义"怎么判分" |
这套分层意味着你不仅能测"Agent 最终答对了吗",还能测"它推理到第几步就跑偏了"、"它是否过度依赖日志而忽略了 trace 数据"。
评估协议覆盖了多个维度:
- 根因定位准确率(Accuracy):最终答案是否落在可接受范围内
- 推理链完整度(Reasoning Chain Coverage):中间步骤与真实传播路径的匹配程度
- 诊断效率(Time / Step Efficiency):达到正确结论所需的交互轮次或推理步数
- 鲁棒性(Robustness):在噪声注入、数据缺失等干扰条件下的表现衰减率
实际上手:跑一次 RCA 评估
项目开源后,最直接的用法是把你的 Agent 放进标准考场跑一轮。以下是一个基于项目仓库典型结构的实践示例——假设你有一个基于 LLM 的 RCA Agent,想用 Benchmark 评估它在微服务故障场景上的表现。
1. 克隆仓库并准备环境
git clone https://github.com/alibaba/rca-benchmark.git
cd rca-benchmark
# 安装依赖(项目基于 Python 3.10+)
pip install -r requirements.txt
# 验证数据集完整性
python scripts/verify_dataset.py --check-all
2. 配置评估场景
# eval_config.yaml — 选择你要评估的场景和维度
benchmark:
scenario_type: microservice # 微服务 / container / network / storage
difficulty: hard # easy / medium / hard
noise_level: 0.1 # 0~1,模拟观测数据噪声比例
missing_data_ratio: 0.05 # 模拟部分数据缺失
evaluation:
metrics:
- accuracy # 根因定位准确率
- reasoning_chain_coverage # 推理链完整度
- step_efficiency # 诊断效率
- robustness # 鲁棒性(需搭配 noise_level > 0)
acceptable_answer_range: 2 # 根因节点允许 ±2 跳的偏差
agent:
type: llm_based
model: your-model-name
api_endpoint: https://your-api-endpoint/v1/chat/completions
max_interaction_rounds: 10 # Agent 最多交互轮次
3. 编写 Agent 适配器
Benchmark 不限定 Agent 实现,但要求你提供一个标准接口适配器:
# agent_adapter.py — 把你的 Agent 包装成 Benchmark 能调用的接口
from rca_benchmark.adapter import BaseAgentAdapter
from rca_benchmark.schema import Observation, DiagnosisResult
class MyRCAAgentAdapter(BaseAgentAdapter):
"""适配你的 LLM-based RCA Agent 到 Benchmark 评估协议"""
def __init__(self, model_endpoint: str, max_rounds: int = 10):
self.endpoint = model_endpoint
self.max_rounds = max_rounds
def diagnose(self, observation: Observation) -> DiagnosisResult:
"""
接收标准化的观测数据,返回诊断结果。
observation 包含:metrics, traces, logs, alert_events
"""
# 构造给 LLM 的提示词——这里是你自己的设计
prompt = self._build_prompt(observation)
# 多轮交互:Agent 可以主动请求更多数据
reasoning_chain = []
for round_idx in range(self.max_rounds):
response = self._call_llm(prompt, reasoning_chain)
step = self._parse_step(response)
reasoning_chain.append(step)
if step.is_conclusive:
# Agent 给出了最终根因判断
return DiagnosisResult(
root_cause_node=step.root_cause,
reasoning_chain=reasoning_chain,
confidence=step.confidence,
rounds_used=round_idx + 1,
)
# Agent 请求补充观测数据
if step.requested_data:
extra = observation.get_supplement(step.requested_data)
prompt = self._update_prompt(prompt, extra)
# 超过最大轮次仍未定位
return DiagnosisResult(
root_cause_node=None,
reasoning_chain=reasoning_chain,
confidence=0.0,
rounds_used=self.max_rounds,
timed_out=True,
)
def _build_prompt(self, obs: Observation) -> str:
# 将 metrics/traces/logs 格式化为 LLM 可理解的文本
# 这部分是你 Agent 的核心设计,Benchmark 不限定格式
parts = []
if obs.metrics:
parts.append(f"## Metrics\n{obs.metrics.to_dataframe().to_string()}")
if obs.traces:
parts.append(f"## Traces\n{obs.traces.to_summary_string()}")
if obs.logs:
parts.append(f"## Logs (recent)\n{obs.logs.tail(50).to_string()}")
if obs.alerts:
parts.append(f"## Alerts\n{obs.alerts.to_string()}")
return (
"你是一名分布式系统故障诊断专家。"
"根据以下观测数据,逐步推理故障根因。\n\n"
+ "\n\n".join(parts)
)
# _call_llm, _parse_step, _update_prompt 按你的实际实现补充
4. 运行评估并查看报告
# 单场景评估
python run_eval.py \
--config eval_config.yaml \
--adapter agent_adapter.py \
--output results/microservice_hard/
# 批量评估(遍历所有微服务场景)
python run_eval.py \
--config eval_config.yaml \
--adapter agent_adapter.py \
--scenario-filter microservice \
--output results/microservice_all/
# 生成对比报告
python scripts/generate_report.py \
--input results/microservice_all/ \
--format markdown \
--output report.md
报告会按评估协议的四个维度输出量化结果,并标注每个场景的推理链偏差位置——你可以据此定位 Agent 在哪类故障模式上系统性薄弱。
注意:以上代码结构基于开源基准项目的典型设计模式。具体 API 名称、配置字段可能随版本迭代调整,运行前请对照仓库最新 README 和
examples/目录确认。
落地之前想清楚几件事
先选场景再调 Agent。 Benchmark 覆盖了多种分布式系统拓扑,但你的 Agent 大概率只在某类场景上表现好。先锁定你实际运维的系统类型(微服务?K8s 编排?网络?),在对应子集上跑评估,再逐步扩展。
推理链比最终答案更重要。 一个"猜对"根因但推理过程完全跑偏的 Agent,在生产环境中不可信赖。重点关注 reasoning_chain_coverage 指标——它告诉你 Agent 是否真的在"诊断",而不是在"掷骰子"。
鲁棒性测试不要跳过。 生产环境的观测数据永远有噪声和缺失。设置 noise_level: 0.2、missing_data_ratio: 0.1 再跑一轮,看准确率衰减多少。衰减超过 20% 就意味着 Agent 对数据质量过度敏感,需要加固。
评估不是一次性动作。 每次改动 Agent 的提示词策略、增加新的工具调用、切换底层模型,都应该重新跑 Benchmark。把它当成 CI 流水线里的一个 stage:
# .github/workflows/rca-eval.yml 示例片段
name: RCA Agent Eval
on:
push:
paths: ["agent/**", "prompts/**"]
jobs:
evaluate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run RCA Benchmark
run: |
python run_eval.py \
--config eval_config.yaml \
--adapter agent_adapter.py \
--output results/${{ github.sha }}/
- name: Check accuracy threshold
run: |
python scripts/check_threshold.py \
--input results/${{ github.sha }}/ \
--min-accuracy 0.7 \
--min-chain-coverage 0.6
把准确率和推理链覆盖度的最低阈值写进 CI,低于阈值就阻断合并——这比人工看日志判断"好像还行"要靠谱得多。
RCA Benchmark 解决的不是"我的 Agent 能不能答对一道题",而是"我的 Agent 在标准化考场里,能不能稳定地、可复现地、有理有据地诊断故障"。开源意味着考场对所有人开放——接下来要看的是,各家 Agent 进场之后,分数到底怎么样。