Cao Jiahao

Master’s student in Software Engineering at HUST, focusing on multimodal LLMs, AIGC, computer vision, and AI applications. Passionate about sharing knowledge and building open-source projects.

目录

  1. 概述
  2. 数据漂移与概念漂移
  3. 训练-服务偏差
  4. 静默回归
  5. 部署策略
  6. 监控与告警
  7. 事件响应与复盘
  8. 实践建议
  9. 参考文献

1. 概述

传统软件的失败模式是显式的——崩溃、报错、超时。ML 系统的失败往往是静默的：模型不会崩溃，但预测质量会逐渐下降，输出会逐渐偏移，直到业务指标显著恶化才被发现。ML 可靠性工程关注如何预防、检测和恢复这些静默故障。

ML 系统的不确定性来源：

  • 数据变化：输入数据分布随时间变化（季节性、趋势、突发事件）。
  • 模型退化：模型在静态数据上训练，但世界在变化。
  • 工程故障：特征管道延迟、数据版本错误、依赖更新。
  • 反馈循环：模型预测影响用户行为，用户行为又改变训练数据。

2. 数据漂移与概念漂移

2.1 数据漂移（Data Drift / Covariate Shift）

输入特征分布 $P(X)$ 发生变化，但 $P(Y X)$ 不变：
\[P_{\text{train}}(X) \neq P_{\text{serve}}(X), \quad P(Y|X) \text{ 不变}\]

示例：用户群体从一线城市扩展到全国，年龄/地域分布改变，但点击行为与特征的关系不变。

检测方法：

  • 统计检验：KS 检验、PSI（Population Stability Index）、Wasserstein 距离。
  • 分布可视化：特征直方图、箱线图对比训练 vs 线上。
  • 嵌入漂移：用 embedding 距离（MMD、余弦距离）检测整体分布变化。
  • PSI 阈值：PSI < 0.1 稳定，0.1-0.25 轻微漂移，> 0.25 显著漂移。

2.2 概念漂移（Concept Drift）

特征与标签的关系 $P(Y X)$ 发生变化：
\[P_{\text{train}}(Y|X) \neq P_{\text{serve}}(Y|X)\]

示例：疫情后购物习惯改变、新政策发布后用户偏好变化、竞争对手推出新产品。

概念漂移更难检测，因为需要标签（可能延迟获取）：

  • 性能监控：跟踪准确率、AUC、F1 等指标随时间变化。
  • 预测分布偏移：模型预测分布（如正例比例）发生显著变化。
  • 校准监控：预测概率与实际频率的偏差（reliability diagram）。

2.3 漂移类型

| 类型 | 特征 | |——|——| | 突变（Sudden） | 分布在短时间内剧变（如疫情、政策变化） | | 渐进（Gradual） | 新分布逐渐取代旧分布 | | 增量（Incremental） | 分布持续缓慢变化 | | 周期（Recurring） | 周期性变化（季节性、节假日） |

  • 不同漂移类型需要不同应对策略：突变触发快速重训，周期变化可预先准备多版本模型。

3. 训练-服务偏差

3.1 什么是 Training-Serving Skew

训练-服务偏差（Training-Serving Skew）是指训练时使用的特征处理逻辑与线上服务时不一致，导致模型表现退化。这是最常见但最容易被忽视的生产问题。

3.2 常见来源

  • 特征计算不一致：训练用 Spark 批处理计算，线上用 Java 实时计算，舍入或逻辑不同。
  • 数据新鲜度：训练用 T+1 数据，线上用实时数据，统计窗口不同。
  • 编码不一致：训练时的 Categorical Encoding 映射表未同步到线上。
  • 缺失值处理：训练和线上的缺失值填充策略不同。
  • 时间泄露：训练时使用了未来信息（如用当天总收入预测当天下午行为）。
  • 依赖版本：训练和线上的特征处理库版本不同。

3.3 预防策略

  • 特征即代码：特征定义和转换逻辑在训练和服务间共享同一套代码库。
  • 特征仓库（Feature Store）：统一离线和在线特征存储，确保一致性（Feast、Tecton、Michelangelo）。
  • 服务前验证：模型上线前，用线上管道重新计算一批训练样本的特征，与训练特征对比。
  • 影子部署：新模型在线上接收真实流量但不影响用户，对比预测结果。
  • 日志校验：定期将线上特征日志与训练特征做分布对比。

4. 静默回归

4.1 什么是静默回归

模型没有报错、服务正常运行，但预测质量下降且没有触发任何告警。常见原因：

  • 上游数据管道静默改变字段格式或单位（如金额从元变为分）。
  • 特征数据源的表结构变更，某列全为默认值。
  • 模型重新训练时数据过滤条件误改，训练数据分布变化。
  • 依赖库更新导致数值计算差异。
  • 模型文件加载错误但未抛出异常。

4.2 检测策略

  • 输入验证：对每个特征做范围、类型、空值率校验，异常时告警。
  • 输出分布监控：监控预测值分布、置信度分布、正例比例的突变。
  • 金丝雀数据集：用一组固定的”金丝雀”输入持续测试模型，输出变化超阈值即告警。
  • 成对比较：新旧模型对相同输入的预测差异监控。
  • 业务指标看板：CTR、转化率、用户留存等下游指标的持续监控。

4.3 金丝雀测试

在模型服务中嵌入一组已知输入和期望输出，定期自动运行：

金丝雀输入 1 → 模型 → 输出与参考对比 → 偏差超阈值 → 告警
金丝雀输入 2 → 模型 → 输出与参考对比 → 偏差超阈值 → 告警

金丝雀测试可检测模型文件损坏、依赖变更、特征管道故障等静默问题。

5. 部署策略

5.1 影子部署（Shadow Deployment）

新模型与生产模型并行运行，接收相同输入，但新模型的输出不返回用户，仅记录和对比：

  • 零风险验证新模型在真实流量上的表现。
  • 可发现训练-服务偏差和性能问题。
  • 需要双倍计算资源。

5.2 Canary 发布

先将 1%-5% 流量导向新模型，观察核心指标：

  • 指标正常 → 逐步扩大流量比例。
  • 指标异常 → 自动回滚到旧模型。
  • 按用户 ID 或请求属性做流量切分，确保一致性。

5.3 A/B 测试

新旧模型同时服务不同用户群，统计显著性对比业务指标：

  • 需要足够样本量和测试时间（通常 1-2 周）。
  • 注意新奇效应（Novelty Effect）——新模型初期指标提升可能来自用户好奇。
  • 避免同时运行多个相互干扰的实验。

5.4 蓝绿部署

准备两套完全相同的生产环境（蓝/绿），切换流量实现零停机发布：

  • 蓝环境运行旧模型，绿环境部署新模型并验证。
  • 验证通过后将流量从蓝切到绿。
  • 出问题快速切回蓝环境。

6. 监控与告警

6.1 监控分层

层级 监控内容
基础设施 CPU/GPU 利用率、内存、磁盘、网络
服务 QPS、延迟 P95/P99、错误率、超时率
数据 特征空值率、分布漂移、数据新鲜度
模型 预测分布、置信度、校准度
业务 CTR、转化率、留存、收入

6.2 告警原则

  • 可操作性：每个告警都应有人知道如何处理，避免告警疲劳。
  • 分级：P0（立即响应）、P1（工作时间处理）、P2（排查优化）。
  • 动态阈值：使用环比/同比和异常检测算法，而非固定阈值。
  • 避免误报：告警阈值应留出缓冲，短暂波动不触发。

6.3 数据质量监控

  • 完整性：记录数、字段缺失率。
  • 时效性：数据到达延迟，分区是否按时生成。
  • 一致性：跨表/跨系统的数值一致性。
  • 合法性：数值范围、枚举值、格式校验。

常用工具：Great Expectations、Deequ、Monte Carlo、dbt tests。

7. 事件响应与复盘

7.1 事件分级

  • SEV-1：核心功能完全不可用或严重影响用户，立即响应（如推荐全部返回空结果）。
  • SEV-2：部分功能受损或指标显著下降，1 小时内响应（如某类特征缺失导致相关性下降）。
  • SEV-3：局部问题，工作时间处理（如非核心指标漂移）。

7.2 响应流程

  1. 检测：告警触发，值班人员确认。
  2. 缓解：回滚到上一稳定版本，或切换到备用模型/规则。
  3. 定位：分析日志、指标和变更记录，找到根因。
  4. 修复：修复问题并验证。
  5. 恢复：重新部署，持续观察。
  6. 复盘：编写 Postmortem，总结教训和改进项。

7.3 无指责复盘（Blameless Postmortem）

复盘聚焦”系统为什么允许错误发生”而非”谁犯了错”：

  • 时间线：事件从发生到恢复的完整时间线。
  • 根因分析：5 Whys 或鱼骨图追溯根本原因。
  • 影响评估：受影响用户数、持续时间、业务损失。
  • 改进项：明确的 Action Item、负责人和截止时间。
  • 经验教训：如何在未来预防类似问题。

7.4 回滚策略

  • 模型回滚：保留前 N 个模型版本，支持秒级切换。
  • 数据回滚：特征数据和训练数据保留版本，可恢复到指定时间点。
  • 配置回滚：超参数、阈值、特征开关纳入版本控制。
  • 代码回滚：蓝绿部署或滚动回滚。

8. 实践建议

  • 模型上线不等于项目结束——生产 ML 系统需要持续运维和监控。
  • 从第一天起建立数据质量和模型监控，不要等出了事故才补。
  • 特征仓库（Feature Store）是解决训练-服务偏差的最有效工具。
  • 每个模型都应有”紧急回退”方案（如上一版本模型或规则兜底）。
  • 定期进行故障演练：主动 kill 服务、注入异常数据，验证监控和恢复流程。
  • 将每次事故转化为自动化检测和预防措施——同样的问题不应发生两次。
  • ML 系统的可靠性不仅是工程问题，也是流程问题：代码审查、变更管理、值班制度同样重要。

9. 参考文献

[1] D. Sculley, G. Holt, D. Golovin, et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS, 2015.

[2] A. Ng, What Is ML Ops and Why It Matters, DeepLearning.AI, 2022.

[3] S. Gupta, D. Ramachandra, et al., Monitoring and Detecting Causes of Decision Drift in Machine Learning Models, IBM Journal, 2022.

[4] J. Gama, I. Žliobaitė, A. Bifet, et al., A Survey on Concept Drift Adaptation, ACM Computing Surveys, 2014.

[5] Google Cloud, Machine Learning in Production: ML Engineering Best Practices, 2023.

[6] C. Ashmore, et al., Machine Learning in Production: A Survey of MLOps, arXiv preprint, 2022.

[7] D. Baylor, E. Breck, H.-T. Cheng, et al., TFX: A TensorFlow-Based Production-Scale Machine Learning Platform, KDD, 2017.

[8] M. Zaharia, A. Chen, A. Davidson, et al., Accelerating the Machine Learning Lifecycle with MLflow, IEEE Data Engineering Bulletin, 2018.

[9] C. Huyen, Designing Machine Learning Systems, O’Reilly, 2022.

[10] A. Burkov, Machine Learning Engineering, 2020.

留下评论