那些你团队的人员已悄然停止阅读的标注队列

你的评估流水线每周会产生 800 条 trace 供人工审核。你的标注人员每周大约有 90 分钟的预算来处理这些数据。他们打开队列，对前三条进行打分，再将其余几条标记为“跳过”，然后就关闭了标签页。你在周一早上盯着看的排行榜，现在只是反映了哪些 trace 碰巧排在了列表顶部，而不是对系统质量的真实衡量。

这不是一个标注问题。这是一个披着质量问题外衣的吞吐量问题，也是评估项目退化最隐蔽的方式之一。Trace 仍在流动。仪表板仍在渲染。数值仍在变动。你没看到的是，你的“人工评分评估得分”的分母已经悄然缩减到了寥寥几项，而这些项是由一个没人刻意设计的排序函数挑选出来的。

任何曾负责过超出可持续负荷的 on-call 轮值的人，对这种模式都不会感到陌生。传呼机不断鸣响。工程师们不断点击确认。只有那些碰巧发生在风平浪静的工作日上班时间的事件，才会得到真正的复盘（postmortem）。其他所有事件都只得到一行简短的备注和一个绿色的复选框。从团队拥有的每一项指标来看，系统都很健康。而指标本身就是失败所在。

标注人员的吞吐量是瓶颈，且不会随流量增长而扩展

首先要内化的一点是，人工评分能力是一个硬性的、增长缓慢的上限。一个受过训练的审核员每小时可以仔细评分 30 到 100 条 trace，具体取决于任务的复杂程度以及他们在案例之间需要重新加载多少上下文。一个由三名审核员组成的兼职团队，每人每周投入 4 小时，每周最多只能完成约 1200 次仔细的评分。一个严肃的评估流水线在一个下午就能产生这么多 trace。

这种不对称性并不是一个可以通过再发一份招聘启事来解决的招聘问题。领域专家标注员正是那些日程表已经饱和的人，因为他们正是产品赖以生存的判断力的来源——工程师、律师、临床医生和支持主管。当问题在于某个特定的工具调用在特定客户的账户中是否是正确的操作时，聘请普通的标注员是没有任何帮助的。

因此，预算是固定的。相比之下，生产流量是呈指数级增长的。一旦你的应用每天的请求量突破几千次，产生的 trace 与人类实际阅读的 trace 之间的差距就会超过三个数量级。从那时起，每增加一个单位的流量，差距就会拉大。增加更多的审核员只能带来常数级的提升。评估流水线持续呈几何倍数增长。随着产品的成功，这个比例只会变得更糟，而不是更好。

队列顺序是没人选择的无声采样器

当产生的 trace 远多于人类能评分的数量时，你产生的 trace 与你评分的 trace 之间的差集就变成了一个样本。每个样本都有一个采样函数。如果你没有设计一个，默认值就是你的队列恰好使用的任何排序方式：时间戳、插入顺序、trace ID 哈希，或者是仪表板查询恰好命中的某个连接键（join key）。

这种默认排序几乎永远不是正确的答案，而且它很少是随机的。近期偏见（Recency bias）意味着最近的 trace 会占据主导。审核员在处理过程中会感到疲劳，导致队列末端的评分系统性不足。如果你的队列是按任何与输入相关的因素（用户 ID、请求大小、延迟）排序的，那么你的“人工评分得分”衡量的只是该排序方式呈现出的切片，而该排序方式隐藏的切片则是不可见的。

危险之处在于，这看起来像是一个信号。数值之所以每周保持稳定，是因为采样偏见是稳定的。因为它具有一致性，所以感觉像是一个真实的衡量。当系统改变时，数值会变动，因为某些变化确实出现在了被评分的切片中。但这都不意味着它具有泛化性。你可能花了一个季度去追踪团队甚至不知道存在的流量子集上的回归（regressions），又花了一个季度发布那些影响不可见的修复补丁，因为这些补丁改善的是没人阅读的切片。

四种采样策略及其适用场景

标注队列工具已经收敛到了几种采样策略。它们是不可互换的。每一个都回答了不同的问题，并产生了不同的偏见。

**随机采样（Random sampling）**为你提供整体质量的无偏视图。如果你想追踪系统在总体上是变好还是变坏，这是唯一无需修正就能给出答案的采样机制。代价是随机采样几乎将所有预算都花在了中位数案例上，而在尾部案例上几乎没有投入，而回归往往就发生在那里。

**分层采样（Stratified sampling）**将流量划分为不同的细分领域（segments）——用户级别、功能、请求类型、对话长度、语言——并在每个细分领域内进行采样。当系统针对不同人群的表现不同，且你需要在不被其他十个细分领域稀释的情况下检测出某个细分领域的回归时，这就是你需要的。分层将单一的汇总数字转变为一组细分级别的数字面板，其中每一个都真实地反映了其对应的人群。

加载中…