一段良好的验证运行后总会伴随着一种静谧的氛围。屏幕上显示的数字，AUC达到0.91，在早上的会议上所有人都点头称是，因为这一次，没人有理由提出后续问题。相信我，这是一种很好的感觉。但我也学会了不要太过依赖或信任它。模型终于在那个星期五上线了。没什么戏剧性，不需要战情室，也不用熬夜。就像之前的十几个部署一样，看起来毫无不同。到了星期二，事情出错了，但这种错误隐藏得很深，甚至很难被察觉。被标记案例的精确度悄悄下降了，但这并没有显示为任何错误。没有崩溃，没有警报，没有任何人真正关注的仪表盘上的红线。它就那样静静地变得更糟，直到有一个下游团队因为审查队列中充满了无用的标记而烦躁不安，终于问了起来。这就是它被发现的方式。不是系统自我检测，而是一个足够 annoyed 的人主动去寻找。而这部分仍然让我感到困扰：代码中什么都没改变。模型和管道与前天完全一样。改变的是它们下面的世界。几天前刚刚推出了一个新的定价层，处于该层的客户交易更频繁，每次交易金额较低。我逐一检查了一个个特征，都没看出什么问题：交易金额处于正常范围，交易频率也一样。只有当我把这两个放在一起看时，数据才清晰地变成了另外一种形式，而管道中并没有任何检查能够捕捉到这种情况。我之前已经设置了漂移监控，并且我真的以为我已经做到了万无漏洞。可事实证明，我并没有。我所设置的检查正好按照我要求它的那样工作，逐一监控每个特征，就像我设计的那样，它会在整个过程中报告绿色。说实话，这是一件令人难以接受的事情。监控并没有坏。也不是懒惰或不完整的。它只是回答了一个比实际重要的问题还要狭窄的问题。悄悄出错的那部分就是这个 narrower 问题，包括我当时在内的大多数漂移监控都在问的那个问题。某个单一特征的分布是否发生了偏移？把本周的值和训练时的值放在一起，画成直方图，然后得出一个数字。在纸上看，这并不是一个坏主意。只是不完整。它在一定程度上是有效的，直到失败不在于任何单一特征，而在于两个特征如何一起变化，这是一种比大多数报告所承认的更容易出现的数据破坏方式。定价层的例子非常典型，因为它在孤立状态下看起来一点也不错。单独对 avg_transaction_value 运行 PSI，没问题。单独对 num_transactions_30d 运行 PSI，也没问题。这两个之间的关系发生了反转，而 PSI 本质上从来不会同时查看两列。它不能。这不是指标本身的缺陷，而是它从未被设计用来跨越的边界。因此问题就变成了：如何检查一个关系而不是一个分布？答案并不是什么稀奇古怪的统计方法，你还需要去学习。它只是让一个模型帮你注意到这一点。让一个分类器去注意到的技巧有一个名字，叫做对抗验证，它听起来比实际更高级。将训练行标记为 0，将一批新的生产行标记为 1，然后训练一个分类器来区分它们。如果这两批数据确实来自相同的分布，那么它无法做得比猜测更好，AUC接近0.5。如果它能将它们分开，说明某些东西发生了变化，因为分类器同时获得了所有特征，因此它能够捕捉到恰好是这种类型的联合变化。