ml-mlops-deploymentlisted

# 部署与监控纪律 — 上线不是终点，是分布开始漂移的起点 ## R — 原文 (Reading) > （转述）Sculley 等在分析真实 ML 系统的技术债时指出：机器学习代码在真实系统中只占一小部分，包围它的是配置、数据抽取、特征计算与服务的复杂胶合；其中最隐蔽的债务是"管道偏差（pipeline skew）"——离线训练用的特征计算逻辑与在线服务时的��现不一致，训练时表现良好而上线即劣化，且这种偏差往往无声无息。 > > — David Sculley 等, "Hidden Technical Debt in Machine Learning Systems" (NeurIPS 2015) > （转述）Google MLOps 工程共识：模型上线只是生命周期的开始——生产环境的数据分布会随时间偏离训练分布，模型性能随之衰减；成熟系统以三层监控应对（基础设施健康、输入/预测分布漂移、下游业务指标），并预先定义再训练触发条件与回滚机制，而不是等事故发生临时救火。 > > — Google Cloud MLOps 白皮书与《Rules of Machine Learning》的通行工程共识 --- ## I — 方法论骨架 (Interpretation) **从模型文件到线上服务之间隔着一道鸿沟**，主因是 training-serving skew——同一特征两套实现：训练时用离线表里的"昨日活跃天数"，线上却实时现算且口径不同（时区/边界/空值处理差异）；离线评估消费的是干净的历史数据，线上面对的是带噪声的实时流。西瓜书的一切评估都默认"测试集=未来样本同分布同口径"，skew 打破的正是这个隐含契约。 **部署三策略按风险递进**： - **影子模式 (shadow)**: 新模型并行接收真实流量但不返回结果，只记录——零风险观察"如果用它决策会怎样"，适合首次上线与重大换版； - **金丝雀 (canary)**: 先放 1%-5% 流量给新模型，出问题爆炸半径小，逐级放量； - **A/B 测试**: 对照实验同时验证业务指标，是"模型更好"的最终裁决（协议设计衔接 `ml-evaluation-design`）。三者常串联：影子→金丝雀→A/B 全量。 **监控三层缺一不可**：①基础设施层（延迟/错误率/资源）——保证服务活着；②预测层（输入特征分布漂移 PSI、预测输出分布变化）——最早的退化信号；③业务层（转化率/投诉率/人工复核率）——真正的目的层。关键陷阱在②与③之间的时间差：**业务指标滞后数周才反映模型退化**（欺诈损失月结、留存要观察期），只盯业务层的系统等于裸奔；PSI 类分布监控的价值就是把发现提前到数小时级。 **再训练触发条件必须预定义**，三种模式各有位置：定期重训（简单、兜底）、性能衰减触发（代理标签到位后最直接）、漂移报警触发（分布变化超阈值即预警，不等性能塌了才动）。**回滚预案**是最后防线：上一版模型的制品与特征管道保持随时可恢复，回滚演练过才算有预案——纸面上的回滚等于没有。 --- ## A1 — 文献中的经典应用 (Past Application) *（本批主题超出西瓜书覆盖范围，A1 改引业界公认的经典案例与公开记录）* ### 案例 1: "CACE 原则"——改动任何东西都会影响一切 - **问题**: 大型 ML 系统里多个模型互相供食（模型 A 的输出是模型 B 的输入），一个团队单独优化上游模型，下游模型的表现莫名劣化；团队间各自为政的迭代让系统行