不存在的单一质量指标

在你公司的某个地方，有一张幻灯片上写着一个数字。“AI 质量：87”。上个季度这个数字是 85，所以幻灯片是绿色的。与此同时，你的值班频道里塞满了截图，显示助手正在自信地为你的最大企业客户捏造退款政策。这两件事同时发生，而撒谎的是那张幻灯片。

这张幻灯片背后的管理层需求完全合情合理：给我一个可以追踪的分数，让我知道这玩意儿是在变好还是变坏。这在收入和可用性上行得通，但在 AI 功能上行不通。因为 AI 功能的质量不是一个标量 —— 它是在输入、用户和时间维度上的分布。将这种分布平均成一个数字并不能起到总结作用，反而精准地破坏了决策者所需的信息。

这篇文章讨论的是这两个事实之间的差距：为什么你的评估套件（eval suite）的平均值隐藏了那些真正伤害你的回归（regressions），你应该汇报什么，以及如何向董事会报告的受众展示一个本质上存在波动的指标，且不会在指标下降的第一周就毁掉你的信誉。

平均值是回归问题的藏身之处

先从算术说起。假设你的评估套件有 1,000 个案例，总通过率为 87%。你发布了一个新提示词（prompt），重新运行套件，得到了 88%。该发布了吧？

得到这个结果的一种可能性是：新提示词在简单的、高频的案例上提升了 3 个百分点，但却让“涉及部分退单的多步退款”这一细分领域 —— 40 个案例 —— 从 75% 跌到了 40%。套件层面的平均值上升了。而你的支持团队升级处理最多的那个细分领域却彻底崩盘了。那个单一的数字不仅没能捕捉到回归，反而主动将其汇报为一项改进。

这不是刻意制造的极端情况 —— 它是对异质数据进行平均时的默认行为。7.5/10 的平均分与 20% 的案例得 2/10 是完全兼容的，而那些处于末尾五分位数的案例就是你的生产事故。研究模型失效的实践者不断发现：失效总是聚集在特定的输入模式周围，而在失效中识别出一个模式，比平均值提升一个百分点更有价值。

统计学家多次为这个陷阱命名。辛普森悖论（Simpson's paradox）—— 即聚合数据中显示的趋势在每个子组中都会发生反转 —— 不仅出现在教科书中，也出现在真实的深度学习系统中。一项深度学习竞赛的复盘发现，一旦将结果拆解，模型的总排名就会发生倒置。安斯康姆四重奏（Anscombe's quartet）则通过视觉方式说明了这一点：四个数据集的平均值、方差和相关性完全相同，但在绘图时却看起来完全不同。监控社区在十年前就吸取了这个教训。AI 产品社区现在正在重新学习。

这种结构性原因值得挑明了说，因为它告诉了你解决方法。平均值对每个评估案例的权重是相等的。但你的业务并非如此。来自顶层客户 4% 流量的回归，比 40% 只是随便逛逛的流量的提升更重要。任何没有编码这些权重的单一数字，都会在关键时刻出错 —— 而任何编码了这些权重的单一数字就不再是质量指标，而是固化成公式的业务优先级协商。

你的基础架构团队已经解决了这个问题

如果这听起来很熟悉，那是由于网站可靠性工程师（SRE）多年前就在延迟（latency）问题上打过同样的仗，并且打赢了。现在没有哪个靠谱的人会汇报平均延迟。右偏延迟分布的平均值会被大量快速请求拉低，从而完全掩盖尾部 —— 你的平均值可能是 50ms，但百分之一的用户却等待了三秒钟然后直接关闭页面。因此，这个学科在百分位数上实现了标准化：p50 代表典型体验，p95 代表缓慢但常见的尾部，p99 代表痛苦的极端情况。

这里的核心洞察是文化层面的，而非数学层面的：管理层学会了如何解读百分位数。“p99 延迟”出现在任何严肃的基础架构公司的董事会报告中，而且没人会听得一头雾水。之所以能做到这一点，是因为工程师不再将百分位数作为统计数据呈现，而是将其作为用户群体呈现：p99 是 “每一百个请求中就有一个”，而在你的流量规模下，这意味着每天有一万一千次充满愤怒的会话。

AI 质量报告应该完全借鉴这一做法：

• 汇报底线，而非中间值。 评估中相当于 p99 的指标是你得分最低的细分领域分数，或者是末尾十分位数的案例得分。“我们最薄弱的细分领域分数为 61%”比“我们的平均分为 87%”对决策更有参考意义。
• 永远不要为了平均而抹杀结构。 SRE 明白你不能对来自不同服务器的百分位数取平均值 —— 你必须聚合底层的直方图。评估版本：永远不要在不同发布版本之间将细分领域分数合并为一个混合数字；要进行细分领域对细分领域的对比。
• 以客户为单位描述尾部情况。 “表现最差的 5% 交互”如果表述为“每天大约 400 场对话，且集中在账单争议上”，会更有冲击力。

延迟的类比也为指标的表现设定了正确的预期：p99 在每周之间是有波动的，大家都知道这一点，没有人会因为一次微小的起伏而感到恐慌。这正是你希望管理层与评估分数之间建立的关系。

即使什么都没变，数字也会变动

单一质量得分还有第二个更棘手的问题：即使你没动任何东西，它也会变动。LLM 的输出具有随机性，而“LLM 作为裁判”的评估方式会将裁判的非确定性叠加在产品的随机性之上。有团队记录过，在代码完全没变的情况下，同一个 eval 评估套件一天的得分是 77%，第二天就变成了 63% —— 模型提供商侧的偏差、裁判漂移和采样噪声共同导致了 14 个百分点的剧烈波动。

如果你一直只汇报一个数字，信任就会在此崩塌。分数下降了 4 个点，高管会问哪里出问题了，而诚实的回答是“没出问题，这在噪声范围内”。从此以后，该指标的每一次波动 —— 包括真正的退行 (regressions) —— 都会被视为噪声。你实际上造了一个会随机拉响的烟雾报警器，最后大家都会学会无视它。

加载中…