数据漂移与持续监控：分布变化何时真的伤害系统

“用户说法变了”“退款资格规则变了”“模型答错变多”看起来都是系统出状况，但发生在完全不同的层次上，处理方式也不同。数据漂移监控的第一步就是把它们拆开，因为只有知道变化发生在哪一层，才知道该看什么指标、该修什么东西。按概率分布所处的位置，可以把变化分为四类：协变量漂移、标签漂移、概念漂移和性能漂移。

协变量漂移是输入分布 P(x) 变了。用户的表达习惯随时间演变，比如描述商品问题的词从“破损”变成了新口语“翻车货”，于是模型收到的输入构成不再和训练时一样。注意这类漂移只说输入变了，至于输出规则有没有变、模型会不会因此答错，它不直接回答。

标签漂移是标签分布 P(y) 变了。例如节日促销刚结束时，退款请求里符合退款资格的订单占比明显上升，模型需要预测的 y 的比例结构发生了整体移动。这时即便每个输入对应的正确答案规则不变，训练时的类别平衡假设也已经失效。

概念漂移是条件关系 P(y|x) 变了，即“同样的输入现在应该得到不同的答案”。典型例子是政策调整：质量问题退款窗口从下单后 30 天延长到 45 天。此时输入分布表面上看可能完全没变，同一条订单数据照样进来，但旧模型学到的决策边界已经不再成立。这一点最关键：P(y|x) 的变化可以在 P(x) 外观稳定的情况下悄悄发生，所以只监控输入字段永远不够。

性能漂移则是直接观测任务表现：正确率、风险指标或校准程度实际下降了。前三种漂移描述的是分布的哪个部分在移动，性能漂移描述的是模型做得还对不对。两者不能互相替代。

把四种变化分开之后，一个自然的因果顺序是：先观察“什么变了”，判断变化落在输入、标签还是条件关系上；再验证“是否真的影响任务”，因为并非所有分布变化都会伤害模型——例如用户从 iOS 换到 Android，只要任务只依赖订单日期，设备字段的漂移就是无关的；最后才决定“该修什么”，是补数据、改规则、重训模型，还是排查管道。

漂移分类的输入是过去与当前的 x、y、条件关系以及任务指标，输出是对协变量、标签、概念或性能漂移的诊断。P(x) 变意味着输入构成变，P(y) 变意味着标签比例变，P(y|x) 变意味着同样输入的正确答案规则变，而性能是否下降还要直接观察任务指标。分类的价值在于定位变化发生在哪一层，而不是下结论：单凭输入分布变化就断言模型已经变差，是越过了这一步能给出的证据范围。

漂移检测的本质是比较：把当前的观测分布和一个参照分布放在一起，看差异是否超出预期。于是第一个问题就是“和谁比”——当前流量应该和训练集比、和上周比，还是和去年同期比？答案取决于你想发现什么问题，不同的监控目标对应不同的基线。

训练集或冻结的评测集回答的是“我们是否已经离开了能力证据所覆盖的范围”。模型的能力只在训练分布上有证据，一旦生产流量离开这个分布，任何表现承诺都只是外推。但它的误判方向也很明显：训练分布本来就不等于生产分布，把两者之间的常态差异当成漂移，会持续产生虚假告警。

最近稳定窗口回答的是“是否发生了突发异常”。它最适合捕捉管道故障、攻击注入这类瞬间改变，但如果把窗口做成不断滚动的“最近 N 天”，基线就会跟着流量走——慢性漂移会被基线自己吞掉，永远比较不出异常。

季节同期（比如去年同期）回答的是“这个变化是不是正常的周期现象”。它适合节假日和周期性模式，但当产品和政策本身已经改变时，和去年同期相比的差异可能是两个不同系统的差异，而不是退化。

控制组或旧版本回答的是“这次新发布带来了什么增量影响”。它适合评估灰度发布，但如果分流不是随机的，或者新旧版本流量互相污染，对比结果就不可信。

选基线时还要记住一个前提：每个基线都必须绑定版本——应用、模型、提示词、索引、政策和埋点都算版本的一部分。如果基线对应的模型版本和当前线上不同，一次正常发布也会被误报成漂移。比较之前先确认这些版本一致，否则检测到的差异里混入了发布本身的噪音。

窗口长度同样影响结论：窗口太短，噪声会淹没信号；窗口太长，突变又被平滑稀释。实践中常见的做法是同时维护两个窗口——一个快速窗口负责短时间内的突发告警，一个慢速窗口负责观察长期趋势。快速窗口发现突变，慢速窗口识别趋势，季节同期则用来压掉周期性误报。

基线设计的输入是监控问题本身、应用与模型版本、季节性假设和时间窗口选择，输出是训练集、最近稳定期、去年同期或控制组这样的带版本参照。不同的基线适合发现不同的变化，也各有各的典型误判，因此没有哪一个基线是永恒正确的参照；选错基线或者让基线悄悄跟着当前流量走，会让整个监控系统在不知不觉中失明。

确定基线和当前窗口之后，下一个问题是如何衡量“差多少”。如果特征是一组离散类别——比如用户输入的词类、地区、支付方式——最常用的压缩方式是 Population Stability Index，简称 PSI。

设基线中每个桶的比例为 eᵢ，当前窗口中同组桶的比例为 aᵢ。PSI 的计算分三步：对每个桶 i，先算当前比例与基线比例的差 (aᵢ − eᵢ)，再乘上两者的对数比 ln(aᵢ/eᵢ)，最后对所有桶求和：

PSI = Σᵢ (aᵢ − eᵢ) × ln(aᵢ/eᵢ)

这个结构有两个值得注意的性质。第一，当两个分布完全相同时，每个桶的 aᵢ 都等于 eᵢ，差值项为零，PSI 也为零；分布差异越大，数值通常越高。第二，单个桶的贡献同时被两个因子放大：该桶比例实际偏离了多少 (aᵢ − eᵢ)，以及这个偏离相对于基线规模有多大（对数比）。因此一个小比例桶从 0.1% 涨到 0.5% 也能产生显著贡献，而不会被大桶的体量淹没。PSI 的输入是同一组离散桶在基线期和当前期的比例，输出是各桶的贡献以及总和。

但 PSI 的数值远没有看上去那么“客观”。它依赖分桶方式：桶的边界怎么切、桶数多少，直接改变结果。某些桶在当前窗口可能比例为零，ln(0/eᵢ) 无定义，必须先做平滑处理。行业里流传的 0.1、0.25 之类的告警阈值只是经验规则，不是统计定律。若特征是连续变量，可以用 KS 距离衡量累积分布的最大差异；若是类别与预期频数的符合度问题，可以用卡方检验；若比较的是完整概率分布而非抽样比例，可以用 JS 散度或 KL 散度；面对高维嵌入这类无法直接分桶的表示，可以用分类器二样本检验或聚类监控。无论选哪种距离，最终都必须能连接到任务影响——距离本身不说明损失。

大规模流量还会带来一个陷阱：当请求量达到数百万级时，极小的分布差异也可能在统计上显著，告警系统会被噪声淹没。因此告警条件不应只看距离数值，还应同时要求效应量、持续时间以及业务相关性：差异不仅要存在，还要足够大、持续足够久、并且落在影响任务的位置上。

PSI 的正确定位是一个需要调查的效应信号。它的数值受分桶、平滑和样本量的影响，只能说明“基线和当前窗口的类别构成出现了值得注意的差异”，不能直接充当“模型变差、需要自动重训”的结论。

把 PSI 放到一个具体场景里手算一遍，公式的含义会更清楚。某退款系统的退款原因原来大致是“不想要”占 50%、“尺寸”占 30%、“质量”占 20%，新政策上线后变成了 30%/30%/40%。问题：漂移主要来自哪里？

按公式 PSI = Σᵢ (aᵢ − eᵢ) × ln(aᵢ/eᵢ) 逐桶计算，基线比例记为 e，当前比例记为 a：

“不想要”桶：a − e = 0.30 − 0.50 = −0.20，对数比为 ln(0.30/0.50) = ln(0.6)，贡献为 (−0.20) × ln(0.6) ≈ 0.102。

“尺寸”桶：a = e = 0.30，差值项为零，贡献为 0。

“质量”桶：a − e = 0.40 − 0.20 = 0.20，对数比为 ln(0.40/0.20) = ln(2)，贡献为 0.20 × ln(2) ≈ 0.139。

三项相加，PSI ≈ 0.102 + 0 + 0.139 ≈ 0.241。如果分桶里还有一个“其他”桶从 0.10 降到 0.04，它的贡献约为 (0.04 − 0.10) × ln(0.04/0.10) ≈ 0.055，完整分桶下的总值约为 0.296。这里的每一步都在强调：PSI 是各桶贡献之和，而不是一个和具体分桶无关的绝对量——图例中给出的 0.358 对应的是另一种平滑和分桶方式，数值无法脱离分桶方案复现，这也正是 PSI 只能作为信号、不能作为绝对结论的原因之一。

比总数更重要的是逐桶贡献。手算结果中最大的贡献来自“质量”桶：质量原因的占比从 20% 翻倍到 40%。而此刻真正需要回答的业务问题是：新上线的政策把质量问题退款窗口延长到了 45 天，旧的资格判断逻辑很可能会漏判这些新进窗口的订单。这个例子完整展示了图 1 的流程：漂移告警（PSI 告诉我们分布变了）只是起点，接下来要等真实标签成熟——退款是否真的被批准、订单是否真的符合新政策——再确认这次变化是否伤害了系统。统计量只负责回答“分布变没变”，政策和成熟标签才负责回答“这次变化伤不伤害系统”。

退款是否真的正确，要等 14 天标签成熟后才知道——用户可能之后撤销退款，或者人工复核改判。但监控不能等 14 天，那今天怎么预警？答案是把即时可见的代理信号和延迟到达的真值分开处理，并且绝不把代理当成结论。

即时可见的早期信号包括：输入中新词的出现率、检索返回空结果的频率、模型低置信或拒答的比例、用户反复追问的次数、转人工接管的次数、工具调用错误、规则冲突以及版本变更。它们和最终正确性之间没有必然对应。接管率上升，可能是模型变差了，也可能是新的审核政策本来就要求更多人工介入；置信度分布稳定也不代表安全，模型完全可能在新分布上自信地犯错。因此每个代理信号只能提出一个待验证的假设，而不能直接作为“模型退化”的证据。

与此同时要建立标签成熟队列。每次预测都保存事件时间、切片信息和模型版本；14 天后回填真实结果——退款是否被撤销、人工是否改判——再计算准确率、风险、校准和选择性覆盖。这里有一个必须避免的错误：把“尚未观察到失败”当成正确。标签还没成熟的样本不能提前记为正确，否则会让准确率虚高、把慢性退化藏起来。

几组典型代理与它们等待的真值可以列成对应关系。检索空结果增多，可能的根因是新词涌入、索引故障或权限过滤变化，但要等真值确认的是“必要的政策证据到底存不存在”。转人工率上升，可能来自难度变化、阈值调整或容量变化，真正要等的是人工最终是否改判以及原因。用户重问增多，可能是回答不清或界面变化，真正要等的是任务最终有没有解决。置信分布稳定，可能意味着一切正常，也可能意味着模型已经失准，需要按置信桶回看实际正确率来分辨。

延迟标签监控的输入因此有两类：一是检索空结果、重问、人工接管、置信度这些即时代理，二是稍后回填的真实业务结果；输出也有两层：当下的早期预警，以及标签成熟后的真实性能。代理的作用是提出假设并触发调查，只有成熟标签才能把假设变成结论。

总体准确率仍然显示 90%，一切看起来正常——但中文质量问题用户的准确率可能已经从 85% 掉到了 55%。平均数为什么能同时容纳这两种事实？因为总体表现是各切片表现的加权和：

Qoverall = Σₖ wₖ × qₖ

其中 wₖ 是切片 k 的流量权重，qₖ 是该切片的表现。如果受伤害的切片只占总流量的 3%，其余 97% 的流量从 90.2% 微升到 91.1%，加权后总体几乎纹丝不动地停在 90% 附近。少数群体的急剧退化被大多数群体的微小改善在权重上抵消了。平均稳定不等于没有伤害，它只是把伤害稀释了。

所以切片监控不能只看总体。需要按语言、地区、产品、渠道、输入长度、风险等级和政策版本切开观察，同时处理两个统计问题：多重比较——切片越多，纯随机波动越容易在某片产生“显著”告警；小样本噪声——某片只有几例时，波动本身就很大。对小切片，正确做法是报告分子/分母和置信区间，使用更长的窗口累积样本，或者用层级收缩把切片估计向整体收缩。既不能因为 2/3 失败就永久告警，也不能因为样本少就忽略高损失群体。对高风险切片可以采用事件计数与零容忍门槛：只要出现一起严重错误就触发，而不是等总体指标显著。

切片分析还要区分两种看起来相同的变化：构成变化和切片内性能变化。构成变化指困难案例的比例升高——比如质量问题订单在总流量中的占比上升，此时该群体的性能本身没变，是流量结构变了；切片内性能变化则是指同样类型的任务上，模型或系统做得更差了。前者更可能靠调整流量、规则或数据解决，后者才更直接指向模型退化。把两者混为一谈，会把流量结构问题误当成模型问题去重训，或者反过来。

切片监控的输入是每个切片的流量权重 wₖ、切片表现 qₖ、样本量和风险等级，输出是总体表现 Qoverall 与各切片的表现区间。总体是加权和这个事实本身就意味着：权重变化可以掩盖少数群体的退化，因此监控必须同时比较构成变化和切片内变化，并给小切片足够长的时间窗口和区间报告，而不是用“总体稳定”四个字关掉所有告警。

漂移告警触发的第一个冲动往往是“重新训练模型”。这是一条危险的捷径，因为告警只说明某处变了，没说明变的是什么。直接把新流量倒进训练集，等于在还不知道原因的情况下修改系统，而且可能把异常甚至攻击注入训练数据。正确的做法是沿着一条调查树逐层排查，每层排除一类可能，直到找到可验证的根因候选，再选择修复方式。

第一层是验证信号本身。埋点是否改动过？解析逻辑、时区处理、去重规则、采样策略有没有变化？基线版本是否被人换过？很多“漂移”其实是监控信号自己的漂移，排查这些能省掉后续所有工作。

第二层是定位切片。把告警分解到具体维度：哪些输入模式、哪个模型版本、哪些地区、哪些风险等级的贡献最大。这一步把“总体漂移”变成“谁在漂移”。

第三层是检查外因。政策是否变更、产品入口是否改版、是否有营销活动引入了新流量、是否遭受攻击、上游服务是否异常。这些外部事件常常是分布变化的真正来源，而且修复它们不需要动模型。

第四层是回放评测。把新旧系统放在同一批证据上比较，使用 oracle 证据和冻结的工具响应，判断差异究竟来自模型、提示、检索还是管道。

只有走到这里，才谈得上选择修复：修埋点、更新规则或检索、改提示词、收紧阈值，训练模型排在最后。如果最终决定发布，也要走渐进发布——先影子运行、再金丝雀验证，并保留旧版本以便回滚。

投毒风险是这条调查树必须严防的最后一环。把异常生产输入自动加入训练，等于给攻击者开了一条通过漂移通道改写模型的路径：攻击者持续制造某种输入模式，系统检测到“漂移”，自动重训，模型就按攻击者的意图被塑造。因此任何准备进入训练的生产样本都必须去标识、去重，并审核来源和标签。

调查树的输入是一次漂移告警以及版本和切片证据，输出是经验证的根因候选与修复选择。它要回答的始终是同一个问题：检测到漂移之后，是否应该自动重训——而沿着树走完就会发现，大多数告警的正确终点根本不是重训。

如果监控屏上每天亮起几十个红灯却没有人处理，失败的不是模型，而是监控系统本身：告警没有和行动连接起来。一条有价值的告警必须回答三个问题——这次越线有多严重、谁来处理、允许做什么。

为此，每一项监控指标都要在运行手册里写明完整参数：基线是什么、窗口多长、最小样本量多少、效应阈值多少、严重度如何分级、负责人是谁、诊断入口在哪里、以及触发后允许执行哪些动作。只有把告警和可执行动作绑定，红灯才有意义。

告警的升级策略应当分级。单点越线通常只进入观察状态；连续多个窗口持续越线，或者错误预算被快速耗尽，才升级为呼叫真人处理。错误预算在这里扮演的是“还剩多少犯错额度”的角色：预算消耗越快，问题越严重。而安全类事件是例外，一旦确认可以立即阻断，不必等待窗口积累。

处置手段远比“重训模型”丰富：冻结自动退款、提高转人工阈值、回滚索引、切换回旧政策，都是合法的处置。恢复之后要更新评测集和基线，但保留旧基线用于识别慢性漂移；同时记录这次告警是否真阳性、处置带来了什么收益，并定期删除那些长期没有行动价值的噪声指标——一个从不触发有效行动的指标只是在制造噪音。

最后必须接受一个不对称的事实：没有检测到漂移不等于没有退化。监控只覆盖你选定的特征，遗漏变量、标签错误以及模型内部的变化仍然可能造成伤害，而且它们恰好发生在监控的视线之外。告警运行手册的输入是基线、窗口、最小样本、效应阈值、错误预算、负责人和允许动作，输出是观察、呼叫、阻断、回滚或转人工这些具体处置；未检测到漂移只说明已监控特征没有越线，不能证明系统健康。

把前面各环节串起来，数据漂移监控的完整因果链由六个动作组成，每个动作的产出都是下一个动作的输入。

第一步，冻结带版本的多重基线。训练集、最近稳定窗口、季节同期、控制组各自回答不同的问题，并且都必须绑定应用、模型、提示、索引、政策和埋点版本。没有这一步，后面所有比较都没有参照。

第二步，持续采集脱敏特征与代理。分布统计需要输入特征，早期预警需要新词率、检索空结果、重问、接管率、置信度这些即时代理，标签成熟队列则需要保存事件时间、切片和版本。采集从第一天起就要脱敏，否则样本永远无法合法地进入任何后续分析或训练。

第三步，按窗口与切片量化变化。用 PSI 或其他距离把基线与当前的差异压成可比较的数值，同时把总体拆成切片。只有切片才能暴露“平均稳定、局部崩坏”的情况。

第四步，验证埋点并定位贡献来源。埋点、解析、时区、去重、采样本身可能出错，先排除信号错误；再按输入、版本、地区、风险定位哪些切片贡献最大，并检查政策、产品、营销、攻击等外部原因。

第五步，等待成熟标签确认任务影响。统计量只回答“分布变了没有”，政策和成熟标签才回答“这次变化是否真的伤害系统”。14 天标签回填之后，才能把代理信号提出的假设变成结论。

第六步，渐进修复并更新评测与基线。修复可能是修埋点、改规则、换提示、回滚索引或切换政策，训练排在最后；发布走影子与金丝雀验证并保留回滚。恢复后更新评测集和基线，但保留旧基线以识别慢性漂移，同时记录告警的真阳性和处置收益，让监控系统本身也在迭代。

这条链的每一环都在约束上一环的结论：基线给比较以参照，切片给总体以分辨率，埋点验证给信号以可信度，成熟标签给代理以证据。缺任何一环，剩下的都只是没有因果依据的告警。