在范围之内移动的分布

一句话总结

漂移不是违反契约——即使值全部在允许范围内，分布也可能发生移动，而要抓住它，需要的不是范围检查，而是比较分布的指标。

为什么需要它

前一个模块里做出的数据契约很强大，却有一件事抓不住。使用时长的平均值从 38 小时移到了 55 小时，这些值依然在“0–400”这个范围之内。契约通过了，训练也正常，也没有告警。可是模型所学到的关系是建立在旧分布之上的，预测会一点点开始偏离。

再叠加标签不会马上到来的问题。如果是流失预测，那个客户到底有没有流失，要一个月之后才知道。要靠准确率察觉异常，就得等一个月，而输入分布 现在就能测量。所以漂移监控，是在等待标签的期间使用的早期信号。

工作原理

TFX 的文档把数据验证分成三种来讲。基于 schema 的验证、训练-服务偏差（training-serving skew）检测，以及把一系列数据连起来看、找出漂移（TensorFlow Data Validation）。第三种是这个模块的主题，要点在于它和前两种是 另外一项检查。

最简单的形式，是先记住基准数据的平均值和标准差，再看新数据的平均值移动了几个 sigma。总体标准差用标准库就能直接算出来（statistics）。

shift_sigma = (새 데이터의 평균 − 기준의 평균) ÷ 기준의 모집단 표준편차

|shift_sigma| 0.1 정도   잡음 범위
|shift_sigma| 1.0 이상   기준 분포에서 확실히 벗어남 → 경보

并不是只用一个 sigma 就能测量一切。类别型特征没有平均值，而在分布严重偏向一侧的值上，平均值的移动看起来会比实际的变化小。所以在实际工作中，会同时使用分桶后测量比例之差的方法，或者分位数比较。无论哪种方法，共同点都一样——必须把基准分布存在某个地方，而且这份存储物也要像模型一样有版本。

接下来要决定的，是拿什么作基准。如果固定为训练所用的数据，测的就是与“模型所学到的世界”的距离；如果以上周的线上数据为基准，测的就是“是不是突然变了”。这是两个不同的问题，所以通常两者都设。

做成指标之后，接下来就是监控系统的事了。每个特征输出一个值，超过阈值时触发告警。指标的命名，遵循给名称加上单位后缀、使用基本单位的惯例，以后读起来更容易（Metric and label naming）。也可以把告警直接连到重新训练的触发上，但在那之前必须有晋级门禁——因为不能保证仅仅因为分布变了而重新训练出来的模型就更好。

测量漂移，并不意味着要立刻更换模型。监控的首要目的是 不要大吃一惊。知道分布正在移动，一个月后准确率下降时，就不必从头去找原因。反过来，如果什么都没测，那一个月就整个成了猜测。

在现场相遇的样子

最常见的失败，是告警太多。对一个有 200 个特征的模型，给每个特征都设阈值，每天总有几个会超。过几天就没有人看了。所以实际上，会只监控模型依赖很大的前几个特征，或者把各个特征的值折叠成一个汇总值再设告警。

第二是把漂移直接读作事故。改版资费套餐，使用时长分布自然会变。那不是数据坏了，而是世界变了，需要的应对不是回滚，而是重新训练。反过来，如果是上游流水线把单位从分钟改成了小时，需要的就不是重新训练，而是修正。指标不会区分这两种情况，所以告警里始终要附带“该确认什么”。

第三是把告警直接连到自动重新训练上。没有任何地方保证，仅仅因为分布移动了而重新训练出来的模型就更好，甚至可能把已经坏掉的数据原样学进去。所以在告警和重新训练之间要有数据契约验证，在重新训练和部署之间要各有晋级门禁。

第四是不更新基准。如果通过重新训练换了 champion，那么漂移的基准也得移到新的训练数据上，漏了这一步，告警就会永远亮着。

第四是只看一个特征就断定原因。使用时长升高，究竟是用户行为真的变了，还是收集方式变了，还是某个客户群大量涌入，光凭这一个数字是分不开的。所以告警旁边始终要有同一时期的样本数和高位分位数。只看平均值，就分不清是样本增加到了十倍，还是值发生了移动。

后续测验将确认什么

确认契约验证和漂移检测各自抓什么，在标签来得晚的情况下测量输入分布的原因是什么，以及把漂移告警直接连到重新训练时还需要什么。