一个客服系统提取订单详情的总体准确率 96%。管理层批准上线。下一个季度升级量飙升 40%。数据提取团队调查发现：退款金额准确率 82%。客户姓名准确率 99%。平均值好看是因为简单、高频的字段把它撑起来了，而难的、高影响的字段在拖后腿。
这就是聚合准确率掩盖故障。每个用单一数字报告异构类别的系统都会发生这种事。
掩盖机制
聚合准确率是加权平均。量大的类别对这个数字贡献更多。当简单、高频类别表现好而困难、低频类别表现差时，平均值看起来没问题，但真实用户在经历真实的失败。
发票处理的具体例子：
| 发票类型 | 占比 | 准确率 |
|---|---|---|
| 打印件 | 70% | 99% |
| 扫描 PDF | 20% | 95% |
| 手写 | 10% | 72% |
| 聚合 | 100% | 97% |
97% 的聚合值通过任何合理的质量门控。但手写发票有 28% 的错误率——差不多每 3 张错 1 张。财务团队每周手动更正约 30 张发票，几乎都是手写的。他们的投诉被驳回，因为”系统准确率 97%”。
这个模式跨领域重复：
- 工单分类：总体 96%，但 5% 的升级类别可能只有 50%，而 99% 的账单类别撑起了平均值。
- 代码审查：总体 94%，但风格问题 99%（高频）掩盖了安全漏洞 60%（低频、高影响）。
- 科研提取：总体 95%，但摘要（40% 的数据、结构化格式）99% 的准确率掩盖了方法论章节（15%、复杂语言）远低的准确率。
部署前先拆解
修复并不复杂：在做部署决策之前把数字拆开。
一个数据提取系统报告 97% 的字段准确率。在扩展到退款处理之前，团队应该按字段验证：
| 字段 | 准确率 | 占比 |
|---|---|---|
| 客户姓名 | 99% | 40% |
| 订单号 | 98% | 30% |
| 优惠码 | 94% | 15% |
| 退款金额 | 82% | 15% |
| 聚合 | 96% | 100% |
退款处理依赖正确的订单号和精确的退款金额。订单号 98% 很稳。退款金额 82% 不行——18% 的退款会处理错误的金额。96% 的聚合值本来会批准这个上线。
跑更大的测试集没用。在 50,000 条消息而非 10,000 条上确认 96% 只是缩窄了错误数字的置信区间。聚合值不是不精确——它是误导性的。更多数据让误导性的数字在统计上更稳健。
按维度验证
对于有多个维度（语言、问题类型、严重等级）的系统，完全交叉验证不现实。一个代码审查代理有 4 种语言 × 4 种问题类型 × 3 种严重等级 = 48 种组合。很多罕见组合（Rust × 性能 × 次要）样本太少无法可靠度量。
务实的做法：独立验证每个维度。
- 4 个语言检查：Python、JavaScript、Go、Rust
- 4 个问题类型检查：bug、安全、性能、风格
- 3 个严重等级检查：关键、重要、次要
- 共 11 项检查，不是 48 项
这能捕获”Go 准确率差”或”安全检测弱”这样的故障，不需要每个单元格不切实际的样本量。关键维度（安全、关键严重等级）应该有比低风险维度更高的阈值，反映故障的实际代价。
只验证最常见的 5 种组合是另一个陷阱。罕见但关键的组合（Go × 安全 × 关键）未被验证，尽管它是最高风险的类别。
生产中的按类别监控
拆解不是一次性的。特定类别的准确率可以随时间独立退化——一次框架更新可能打坏安全测试推荐而其他一切保持稳定。
一个 90% 的聚合监控阈值会漏掉这个：
| 场景 | 安全 | 其他类别 | 聚合 |
|---|---|---|---|
| 基线 | 90% | 94% | 93% |
| 框架更新后 | 70% | 94% | 91% |
聚合从 93% 降到 91%——仍然在 90% 以上，不触发告警。而安全测试准确率崩了 20 个百分点。
带独立阈值的按类别监控能立即捕获这个。安全从 90% 降到 70% 时，它的专属告警触发，不管聚合怎么样。
按类别质量门控
整个系统用单一聚合阈值对单个类别没有约束力。一个处理合同（91%）、发票（98%）和收据（96%）的流水线报告总体 95.3%——通过 95% 的门控而合同在 91%。
正确设计：按文档类型设质量门控，阈值校准到每个类别的错误代价。合同需要比收据更高的准确率，因为合同错误有更大的法律和财务后果。
按类型报告准确率但在聚合阈值旁边只是半措施。门控本身必须是按类型的才有约束力。否则一个类别可以靠平均值蒙混过关。
升级断层
当用户在好看的聚合数字下投诉时，第一反应是驳回投诉。“系统准确率 96%“感觉像一个决定性的反驳。不是。
一个总体 96% 但退款金额 82% 的支持系统在一个季度内升级量增加了 40%。调查发现 85% 的升级涉及错误的退款金额——一个表现不佳的字段到可度量的客户影响之间的直接因果链。96% 的聚合是真的，客户的痛苦也是真的。两者同时成立，因为聚合掩盖了错误聚集在哪里。
当投诉集中在特定类别或字段时，正确的响应是拆解，而不是拿聚合值当系统正常运作的证据。
提高聚合修不了类别
一个 CI/CD 代码审查代理总体 92%，漏了一个 SQL 注入漏洞。直觉：“我们需要把准确率提高到 98%。“但如果安全问题占审查量的 8%，即使安全检测做到完美也只把聚合从 92% 提到大约 92.6%。安全的改善在聚合中不可见，而提高聚合 6 个百分点的努力会聚焦在高频类别上——小改善在那里对数字影响最大。
修复必须针对具体类别。先拆解，找到差距，然后投入到表现不佳的具体维度上。聚合会跟着涨——但它是一个错误的优化目标。
一句话总结： 做决策前永远按类别拆解聚合准确率——96% 的平均值可以掩盖最重要字段上 82% 的失败。