1. 课程导论：模型漂移的定义、为什么需要监控、Spark ML在监控中的优势
1.1 模型漂移的定义与本质
模型漂移（Model Drift）是指已部署的机器学习模型在真实生产环境中，其预测性能随时间推移而逐渐下降的现象。这种性能退化并非模型本身结构发生变化，而是由于模型所依赖的数据分布、特征关系或业务环境发生了改变。
核心公式： 模型漂移 = 训练时数据分布 ≠ 推理时数据分布 → 预测误差增大 → 业务决策质量下降
根据漂移发生的对象，模型漂移主要分为以下三类：
| 漂移类型 | 定义 | 典型场景 | 检测指标 |
|---|---|---|---|
| 数据漂移（Data Drift） | 输入特征 P(X) 的分布发生变化 |
用户年龄分布从 20-30 岁变为 40-50 岁 | PSI、KS、KL 散度 |
| 概念漂移（Concept Drift） | 特征与标签的关系 P(Y|X) 发生变化 |
“点击率”与“广告位置”的关联规则改变 | 准确率、AUC 衰减 |
| 标签漂移（Label Drift） | 标签 P(Y) 的边缘分布发生变化 |
正样本比例从 5% 骤升至 20% | 标签分布统计量 |
实践要点： 在金融风控场景中，数据漂移通常先于概念漂移发生。建议将数据漂移检测作为第一道防线，概念漂移检测作为第二道防线。
1.2 为什么需要监控模型漂移
在 MLOps 实践中，模型部署上线只是生命周期的起点，而非终点。缺乏监控的模型如同“盲飞”，其风险体现在多个层面：
- 业务损失： 信贷审批模型漂移可能导致坏账率上升 2-5 个百分点，直接造成千万级资金损失。
- 合规风险： 金融、医疗等强监管行业要求模型行为可解释、可追溯，漂移导致的不公平决策可能引发法律诉讼。
- 运维成本： 被动发现模型失效时，往往已造成大量错误预测，回滚和修复成本远高于主动监控。
- 用户信任： 推荐系统漂移导致用户体验下降，用户流失率在 1-2 周内可能上升 15%。
常见误区： 很多团队只监控模型准确率等离线指标，忽略了数据分布的变化。实际上，数据漂移往往比准确率下降早 1-3 周出现，是更敏感的预警信号。
1.3 Spark ML 在监控中的核心优势
传统模型监控方案（如 Python 单机脚本、数据库触发器）在面对大规模生产数据时存在性能瓶颈。Apache Spark ML 凭借其分布式计算和统一批流架构，成为模型漂移监控的理想引擎。
| 能力维度 | 传统方案（Python 单机） | Spark ML 方案 | 优势说明 |
|---|---|---|---|
| 数据规模 | 受限于单机内存（通常 < 100GB） | 分布式处理 PB 级数据 | 支持全量数据监控而非采样 |
| 计算引擎 | Pandas/NumPy 单线程 | Spark SQL + MLlib 分布式计算 | PSI、KS 等指标计算速度提升 10-50 倍 |
| 特征工程 | 需手动编写特征统计逻辑 | 内置 VectorAssembler、Bucketizer 等 Transformer |
复用训练流水线，减少重复开发 |
| 流式监控 | 需额外集成 Kafka/Flink | Structured Streaming 原生支持 | 批流一体，统一代码库 |
| 模型存储 | Pickle/Joblib 文件 | MLflow + Spark Model Export | 版本管理与回滚无缝集成 |
1.4 典型监控流程
基于 Spark ML 的模型漂移监控通常遵循以下步骤：
- 数据采集： 通过 Structured Streaming 消费实时预测日志，或定期读取离线批数据。
- 特征对齐： 使用与训练时相同的
PipelineModel对输入数据进行特征变换，确保分布统计口径一致。 - 分布计算： 调用 Spark MLlib 的
Statistics工具或自定义 UDAF 计算 PSI、KS、KL 散度等指标。 - 阈值判定： 将计算指标与预设阈值（如 PSI > 0.1）比较，触发告警条件。
- 告警推送： 通过 Spark 的
foreachBatch或外部消息队列发送告警通知。
最佳实践： 建议将监控逻辑封装为 Spark Application，通过 Airflow 或 Cron 定时调度。对于高时效性场景，使用 Structured Streaming 实现秒级监控。