Pooled Leaderboards Hide System-Specific Winners: A Reporting-Protocol Audit of Offline Root-Cause Analysis Benchmarks
AI 深度解读
背景
根因分析（Root-Cause Analysis, RCA）是运维领域的核心任务——当分布式系统出现故障时，工程师需要快速定位引发告警的真正源头。近年来，随着越来越多离线 RCA 基准测试（offline RCA benchmarks）被提出，研究社区和工业界逐渐形成了一种常见做法：将多个子系统（subsystems）上的评测结果混合在一起，计算一个全局的 top-1 准确率，然后据此排出一个"总榜"（pooled leaderboard）。工程师在实际选型时，往往直接参考这个总榜的优胜者，认为它在自己的子系统上也会表现最好。
这种做法隐含了一个强假设：不同子系统之间的最优方法是可交换的（exchangeable）——即总榜冠军在任何一个具体子系统上也应该是最优或至少接近最优的。然而，这一假设从未被系统性地验证过。
核心内容
本文对上述"总榜直觉"进行了首次审计（audit）。作者在三个公开 RCA 基准测试家族——OpenRCA、RCAEval 和 PetShop——上展开实验，共覆盖 11 个子系统和 778 个匹配评分单元（matched scoring units）。
为保证比较的公平性，作者在分析中只保留了四个在所有子系统上均有完整覆盖的方法（comparators），分别是：
- BARO
- CD-1min adapter
- max-|Z|
- per-service alert-count
随后，作者对这四组方法进行了全部六组两两比较（pairwise comparisons），并得出以下核心发现：
-
子系统层面的效应方向不一致：全部六组比较中，子系统级别的效应（subsystem-level effects）均呈现正负双向——即在部分子系统上方法 A 优于方法 B，在另一部分子系统上则反转。这意味着不存在一个"放之四海而皆优"的通用赢家。
-
随机效应预测区间跨越零点：所有六组比较中，随机效应模型（random-effects model）的 95% 预测区间（prediction interval）均跨越零。这表明，如果随机抽取一个新的子系统，两种方法的优劣关系无法确定，总榜排名无法可靠外推。
-
可交换性假设被拒绝：在案例级别（case-level）的交互效应检验（interaction tests）中，六组比较中有五组拒绝了可交换性假设（exchangeability rejected）。这意味着不同子系统之间的表现差异并非随机噪声，而是存在系统性的、不可忽略的结构性差异。
-
留一系统选择的遗憾巨大：在"留一系统交叉验证"（leave-one-system-out selection）实验中，当用总榜排名来为被留出的子系统选择方法时，最多在 11 个子系统中有 5 个选到了实际表现更差的方法。在最严重的案例中（RCAEval / Sock-Shop），遗憾值（regret）高达 24.8 个百分点（pp）——即因为盲信总榜而错选方法，导致准确率损失接近四分之一。
-
审计工具开源：作者发布了一个 320 行的审计模块（audit module），输入任意匹配的 RCA 基准评分表，即可在复现全局得分的同时，自动计算每个子系统层面的稳定性检查指标。
关键要点
- 总榜 ≠ 子系统最优：pooled top-1 accuracy 的排名不能直接迁移到单个子系统，二者之间存在不可忽视的 gap。
- 效应方向是双向的：不存在"方法 A 在所有子系统上都优于方法 B"的简单关系，优劣关系随子系统翻转。
- 可交换性假设不成立：案例级别交互检验在 5/6 的比较中拒绝了可交换性，说明子系统间的差异是结构性的，而非随机波动。
- 遗憾值可能非常大：在 RCAEval/Sock-Shop 上，盲信总榜导致的准确率损失可达 24.8 pp，这对实际运维决策而言是不可接受的。
- 审计工具可复用：作者提供的 320 行模块可嵌入任意 RCA 基准评测流程，帮助研究者在发布总榜的同时报告子系统级别的稳定性证据。
- 覆盖范围：实验横跨 OpenRCA、RCAEval、PetShop 三个基准家族、11 个子系统和 778 个匹配评分单元，结论具有较好的泛化支撑。
意义与影响
本文的贡献不仅是方法论层面的警示，更直接触及了 RCA 基准评测的报告规范（reporting protocol）问题。
首先，对于基准测试的设计者而言，本文证明仅报告 pooled accuracy 是不够的。一个负责任的基准评测应当同时披露子系统级别的效应分布、预测区间以及可交换性检验结果，否则总榜的参考价值将大打折扣。
其次，对于实际工程师而言，本文提供了一个反直觉但重要的选型原则：不要直接照搬总榜冠军。在为自己的子系统选择 RCA 方法时，应当优先考虑在该子系统或同类子系统上有验证结果的方法，而非全局排名最高的方法。
第三，从研究社区治理的角度看，本文提出的 330 行审计模块为建立更严格的 RCA 评测报告标准提供了可行工具。未来基准论文在投稿时，或许应当像报告置信区间一样，常规性地附上子系统稳定性审计结果。
最后，本文的方法论——通过留一系统交叉验证量化"盲信总榜的遗憾"——并不局限于 RCA 领域。任何涉及多数据集、多任务、多领域混合排名的基准评测（如多语言 NLP 基准、多场景推荐系统基准等）都可能面临类似的可交换性挑战，本文的审计框架具有迁移参考价值。