ChurnWatch 实战：用 AWS 搭建 MLOps 数据漂移监控

模型训练完成并不意味着万事大吉。当真实世界的数据随时间变化，输入模型的数据可能逐渐偏离训练时的分布——这就是数据漂移（Data Drift）。一个在训练集上表现优异的模型，可能因为数据漂移而在生产环境中悄悄失效。

ChurnWatch 正是针对这一问题的 MLOps 小项目：它利用 AWS 生态搭建了一套从模型训练到漂移检测、再到指标监控的完整流程，用最小的成本展示了数据漂移监控的核心思路。

数据漂移为什么值得关注

设想一家公司用历史客户数据训练了一个流失预测模型，判断哪些客户可能退订服务。模型本身没有问题，但随着时间推移，客户的消费金额可能整体上移或下移，客服呼叫的平均次数可能变化，整体客户画像也会随之改变。

这意味着：即便模型文件一行未改，流入它的数据已经不再像训练时那样。模型可靠性因此受损，而团队往往毫不知情。ChurnWatch 的目标就是让这种变化变得可见、可量化、可监控。

项目的整体流程非常清晰：训练模型 → 比较新数据与训练数据 → 检测漂移 → 监控结果。

数据漂移通常还可以进一步细分为几类：协变量漂移（Covariate Shift），指输入特征 X 的分布 P(X) 发生变化而条件分布 P(Y|X) 不变；标签漂移（Label Shift / Prior Shift），指类别先验 P(Y) 改变；以及概念漂移（Concept Drift），指 P(Y|X) 本身发生改变，即同样的输入在不同时间对应的真实标签不再一致。ChurnWatch 用 PSI 检测的主要是前两类，因为 PSI 只看特征分布，不涉及标签。区分这些类型有助于选择合适的应对策略：协变量漂移可通过重采样或重新加权缓解，概念漂移往往必须重新训练模型，而标签漂移则需要调整输出阈值或类别先验。

ChurnWatch 的技术架构

这个项目的设计尽量克制，每个环节只用了最合适的 AWS 服务：

• Amazon S3：存储训练数据集，作为数据管理的基础层
• Amazon SageMaker：使用历史客户数据训练流失预测模型
• Python 漂移检测脚本：用群体稳定性指标（PSI）比较基线训练数据与模拟生产数据
• Amazon CloudWatch：接收漂移指标，提供持续监控能力

数据集被有意拆分为两部分：基线/训练数据集与模拟生产数据集。生产数据集被刻意构造出不同的特征分布，从而让监控系统有真实的漂移场景可以检测。这不是一个空转的演示，而是带对抗性质的完整验证。

从训练到检测：PSI 如何量化漂移

训练环节相对标准：训练数据存放在 S3，SageMaker 读取历史客户数据完成模型训练。真正有意思的是漂移检测这一步。

ChurnWatch 选择 Population Stability Index（PSI） 作为核心指标。PSI 通过比较某个特征在基线数据集与新数据集中的分布差异，给出一个可解释的数值。一个简化的判读标准是：

• PSI < 0.10：几乎没有显著变化
• PSI 达到 0.20：存在显著漂移

在实验中，生产数据被故意生成为不同分布。检测脚本对选定特征逐一计算 PSI，并找出其中最大的漂移值。输出结果类似：最大 PSI 为某个具体数值，阈值设定为 0.2，判定结果为「检测到漂移」。实际数值取决于生成的生产数据集。

PSI 的价值在于：它不依赖模型本身，只关心数据分布，因此可以在模型推理之前就发出预警。

PSI 的计算方式是把连续特征分箱（通常 10 个区间），统计每个区间在基线数据集与新数据集中的样本占比，再对每个箱求 (实际占比 − 期望占比) × ln(实际占比 / 期望占比) 并求和。数学上它类似于对称化的 KL 散度，对分布的相对变化较为敏感。几点实践注意：分箱边界必须沿用基线数据的边界，否则结果不可比；每个箱内样本量不宜过小，否则比例估计噪声会放大 PSI 值；PSI 对零占比箱需要加平滑项，避免对数发散。此外，PSI 只处理数值型或分箱后的类别特征，对高维稀疏或文本特征需要先做降维或嵌入聚合。

用 CloudWatch 把漂移变成可监控指标

漂移计算完成后，结果被发布到 Amazon CloudWatch。这一步把一个一次性的脚本输出，变成了持续可观测的指标。

相比每次手动跑脚本检查漂移，CloudWatch 带来的改变是运维层面的：漂移值作为一条时间序列指标存在，可以被查看、被对比，也能进一步接入告警。ML 工作流从此有了和传统服务监控类似的观测能力。

这也是 ChurnWatch 想传达的关键点之一——ML 系统需要的不只是训练脚本，还需要与生产运维对齐的监控层。

CloudWatch 的自定义指标通过 PutMetricData API 写入，每个数据点包含命名空间、指标名、维度（Dimension）、时间戳与数值。把 PSI 作为指标发布时，建议用「特征名」「数据集版本」「模型版本」作为维度，这样可以在控制台按维度过滤和聚合，也便于后续配置 CloudWatch Alarm。告警可以通过 SNS 触发邮件、Lambda 或 PagerDuty 等下游动作，实现「漂移超阈值即通知」的闭环。相比在脚本里写 if-else 打印日志，指标化的好处是天然保留了时间序列历史，可以画趋势图、做同比环比，也能与其他服务指标放在同一看板上对比。

从「建模型」到「运营模型」的认知转变

这个项目最有价值的产出，其实是作者在实践后总结出的一个认知差异：构建 ML 模型和运营 ML 系统是两回事。

训练模型只是生命周期中的一环。一旦模型进入真实数据环境，需要被监控的对象就变成了数据本身。ChurnWatch 用一套很小的流程覆盖了完整链路：S3 做数据集管理，SageMaker 做模型训练，PSI 做数据漂移检测，CloudWatch 做指标监控。

核心结论可以浓缩成一句话：模型可以保持不变，但它周围的数据会变。监控这种变化，是维持生产环境机器学习系统健康运转的必要工作。

对于刚接触 MLOps 的开发者来说，ChurnWatch 提供了一个低成本、可复现的入门范本——不需要复杂的平台，几个 AWS 服务加上一个 PSI 脚本，就能把数据漂移从抽象概念变成看得见的指标。

MLOps 的典型生命周期通常被划分为数据准备、实验、训练、部署、监控与再训练等阶段，ChurnWatch 覆盖了其中训练与监控两端，省略了 CI/CD、特征存储、模型注册表等重型组件。这种「最小可行 MLOps」思路的价值在于降低学习门槛：先跑通链路，再按需补齐。若后续要扩展，可以引入 Amazon SageMaker Model Monitor 自动做漂移检测、用 SageMaker Pipelines 编排再训练流程、用 Feature Store 统一特征口径，从而把「检测到漂移」进一步连接到「自动触发重训」的闭环，让监控从观测走向自愈。