Ml Mlops Deployment

部署与监控纪律 — 上线不是终点，是分布开始漂移的起点

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 的输入），一个团队单独优化上游模型，下游模型的表现莫名劣化；团队间各自为政的迭代让系统行为不可预测。
• 方法论的使用: Sculley 等把这类耦合命名为级联失败源，提出 CACE 原则（Changing Anything Changes Everything），处方包括：切断不必要的深度耦合、版本化上游输出、为下游建立对上游变更的检测哨兵。
• 结论: ML 系统的稳定性不来自单模型质量，来自对模型间依赖关系的治理——监控与版本化是架构问题而非运维细节。
• 结果: 该论文成为 ML 技术债领域的奠基引用，工业界据此普遍建立了模型依赖图与上游变更通知机制；本 skill 的"预测层监控+制品版本化"纪律直接源于此脉络。

案例 2: 《Rules of ML》第 37-40 条附近的上线教训浓缩

• 问题: 团队反复遇到"离线指标变好、上线后业务没变化甚至变差"，且事后排查发现原因五花八门（特征实现不一致、反馈回路污染、指标选错）。
• 方法论的使用: Google 的规则手册把上线环节的教训固化成可执行条款——确保训练与服务特征管线一致并做一致性测试、用留出日数据检验、警惕两个指标此消彼长时被掩盖的真实退化、模型集成前先确认单模型收益真实。
• 结论: 线上线下差距的大多数根因是工程性而非算法性——一致性测试的价值高于更聪明的模型。
• 结果: 这些条款成为业界上线 checklist 的通用蓝本；本 skill E 段的"skew 一致性检查"步骤即按此精神构造。

案例 3: COVID 冲击下的模型集体失效 (2020)

• 问题: 疫情爆发后全球大量已上线模型同时失灵——信用风险模型面对从未见过的失业率、需求预测模型面对断裂的消费模式、反作弊模型面对行为剧变。
• 方法论的使用: 有监控体系的团队靠特征分布报警在数天内确认"世界变了"而非"系统坏了"，紧急切换到人工规则兜底并加速重训；无监控的系统则在数周后从财务报表上才得知出了问题。
• 结论: 极端分布漂移无法预防，但"发现速度"完全取决于监控设计；漂移报警 + 回滚/兜底预案是把黑天鹅从事故降级为事件的关键。
• 结果: 该事件成为 MLOps 教育的标准案例，推动"drift monitoring"从可选项变成行业默认项。

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

1. 用户的模型在 notebook 里调好了，第一次面对"怎么上线"：打包成什么、流量怎么切、要不要灰度——部署策略空白。
2. 用户上线几个月后效果悄悄下滑：指标慢慢掉、坏例增多、没人说得清哪天开始的——典型静默退化。
3. 用户听说要做漂移监控："PSI 是什么？阈值设多少？监控哪些特征？"
4. 用户纠结再训练节奏："多久重训一次？""自动重训会不会越训越差？"
5. 用户的线下评估很好但线上表现差，泄漏也排除了——training-serving skew 嫌疑浮出水面。
6. 用户被要求写"模型上线方案/应急预案"，不知道该包含什么。

语言信号 (用户的话里出现这些就应激活)

• "上线/部署/deployment/MLOps"/"notebook 到生产"/"模型怎么 serve"
• "影子模式/shadow/灰度/金丝雀/canary/A/B 上线"
• "数据漂移/data drift/concept drift/分布变了/PSI 阈值"
• "模型退化/效果越来越差/performance degradation/什么时候重训/retrain"
• "回滚/rollback/预案/线上出事怎么办"
• "线下好线上差"（且 ml-leakage-defense 已排除）/"training serving skew"

与相邻 skill 的区分

• 与 ml-experiment-tracking 的区别: tracking 管实验期的可复现记账（种子/配置/环境/checkpoint）；本 skill 管上线后的生命周期（部署/监控/重训/回滚）。那边 B 段明言"已上线系统的监控告警超出账本边界"，移交点就在这里。制品版本化的习惯两边共享。
• 与 ml-leakage-defense 的区别: leakage 是训练期的信息穿越（测试集信息漏进训练过程，线下虚高）；skew 是线上线下环境差异（两套实现的口径不一致，线下没有作弊）。症状相似（线下好线上崩），病因与处方完全不同：先走 leakage 排查，排除后再来本 skill 查 skew。
• 与 ml-pitfall-audit 的区别: audit 是上线前的六问前提总审（一次性闸门）；本 skill 是上线后的持续纪律。正常顺序：audit 通过 → 本 skill 接管生命周期；线上出事后回溯归因时两者都会被调用。
• 与 ml-evaluation-design 的区别: 那提供比较协议与统计检验原则；本 skill 把它们特化到线上场景（A/B 协议、业务指标的滞后结构、监控阈值的意义解释）。

E — 可执行步骤 (Execution)

当 skill 被激活后, agent 应按以下步骤执行:

1. 上线形态判定

   • 确认现状：从未上线（首发）/已有旧版（换版）/线上异常（救火）？
   • 完成标准: 定位明确；判停条件: "线下好线上差"且未做过泄漏排查 → 先移交 ml-leakage-defense，排除后回来；救火场景直接跳步骤 6 回滚评估，其余按序执行。

2. Skew 一致性检查（上线前的第一道关）

   • 逐个特征核对离线/在线两套实现：计算逻辑、时间边界、空值语义、单位与精度是否严格一致；能共享代码就共享代码。
   • 完成标准: 特征清单核对表全部打勾，含至少一条端到端比对证据（同一条请求离线在线各算一遍数值一致）。
   • 判停条件: 存在无法对齐的特征实现（历史包袱改不动）→ 该特征移出模型或加转换适配层，带已知 skew 上线等于埋雷，禁止放行。

3. 部署策略选择

   • 首发 → 影子模式跑满一个业务周期；换版 → 金丝雀 1%-5% 起步逐级放量；需证明业务价值 → 叠加 A/B（协议与样本量走 ml-evaluation-design）。
   • 完成标准: 放量计划表（阶段/流量比例/晋级条件/中止条件）落盘。
   • 判停条件: 业务不允许任何分流（全量强依赖）→ 降级为"影子+人工抽检"并书面记录风险；用户要求跳过灰度直接全量 → 记录分歧与回滚前提后执行。

4. 三层监控布防

   • 基础设施（延迟/QPS/错误率）→ 预测层（核心特征 PSI + 预测分布）→ 业务层（滞后周期明确的北极星指标）；每层定告警阈值与负责人。
   • 完成标准: 监控面板可用且有已知误报率的告警规则；PSI 阈值说明依据（行业惯例 0.1/0.25 分界须按特征基数校准，禁止照抄数字）。
   • 判停条件: 预测层数据不可得（无特征日志管道）→ 先补日志再上线；业务层指标观察周期过长时显式标注"该层告警有 X 周盲区"。

5. 再训练与回滚预案

   • 写明触发组合（定期兜底 + 性能衰减线 + 漂移报警），以及自动重训的安全阀（新模型须通过固定验收集才能替换）；回滚要求：旧版制品/特征管道/配置保持热备，回滚流程演练过至少一次。
   • 完成标准: 触发矩阵文档 + 一次成功的回滚演练记录；未演练 → 标注"预案未经演练"并限期补。
   • 判停条件: 旧版制品已不存在且无法重建 → 禁止新版上线，先补齐可回滚性。

6. 退化响应流程

   • 收到退化信号后的固定动作序列：①分清"系统坏了/世界变了/对手变了"（基础设施告警→特征 PSI→外部事件）②定位到层（预测分布动了但业务没动 = 观察；业务动了 = 行动）③行动选项排序：阈值调整/规则兜底 → 回滚旧版 → 紧急重训。
   • 完成标准: 本次响应有事后复盘记录（信号到定位耗时、哪个监控起了作用/缺席）。
   • 判停条件: 复盘显示监控盲区是根因 → 把补盲区列为最高优先级改进项，未补前该类信号保持人工巡检。

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

• 纯软件工程问题（容器编排、网关配置、数据库扩容）: 这是 DevOps/SRE 的领地；本 skill 只管"ML 特有"的那部分（skew/漂移/模型制品）。
• 实验还没做完就想上线的赶工冲动: 评估设计与 pitfall-audit 未过的模型不该进入部署讨论——先把闸门过了。
• 单次批处理式预测任务（无持续服务）: 无线上流量就没有影子/金丝雀可言，其"部署"主要是调度与数据新鲜度管理，本 skill 仅监控与重训章节适用。
• 在线学习/强化学习的持续自更新系统: 其更新安全问题是另一个专门领域，本 skill 的"离线训练+受控发布"范式不完全适用。

文献反复警告的失败模式

• 静默失败比崩溃更危险: 服务报错会有人修，分数从 0.82 缓慢滑到 0.71 没有任何报警——多数团队的模型死于慢性病而非猝死；没有预测层监控的系统对退化天然失明。
• 业务指标滞后数周才反映退化: 只看月度坏账率/季度留存，发现问题已是几周前的事故；分布监控的存在意义就是把时钟拨快。
• 训练-服务偏移的无声杀伤: 两套特征实现各自都对、合起来不一致，离线评估永远发现不了——一致性测试是唯一防线，code review 目测不出来。
• 自动重训的死亡螺旋: 漂移后无人审查地自动重训，新模型拟合了异常期的脏数据甚至反馈回路噪声，越训越差；重训必须过固定验收闸门。
• 回滚是纸面功夫: 旧模型制品已被覆盖/特征管道 schema 已升级不兼容，真出事时回不去；未演练过的回滚不算预案。
• 监控指标本身漂移: PSI 阈值抄行业数字不看特征基数与季节性，要么天天狼来了要么真狼来了没叫。

作者盲点 / 时代局限（本批为外推补全）

• 必须声明: 本 skill 主题超出西瓜书覆盖范围——BOOK_OVERVIEW 批判节明确指出全书不讲线上-线下一致性、A/B 上线等落地环节，"评估止步于离线指标"；本 skill 是对该盲点的补全，素材为 2015-2023 业界公开共识转述，方法论仍在快速演化（LLM 应用的监控维度、特征平台标准化、可观测性工具链均在快速迭代），执行时应核对当前实践。
• "分布漂移"至今缺乏统一分类学: 数据漂移/概念漂移/标签漂移的边界在不同文献中定义不一，本 skill 采用操作化划分（看得到输入变化 vs 只有标签才能确认），使用时注意术语语境。
• PSI 不是万能探针: 它对低基数字段、强相关特征组的敏感度有限，且只能看到"输入变了"，看不到"关系变了"（后者需要标签回流）；监控体系要承认盲区。
• 西瓜书 i.i.d. 假设的失效正是本 skill 存在的理由: 书中评估体系默认未来=过去，而线上世界的第一条定律就是未来≠过去——这是合集内最深的一条时代边界。

容易混淆的邻近方法论

• Training-serving skew ≠ 数据漂移: 前者是两套实现的静态 bug（修一次就好），后者是世界变化的持续过程（需要持续监控）；都表现为"线上不如线下"，诊断手段完全不同。
• 模型监控 ≠ 数据监控: 只盯上游数据质量（空值/延迟）看不到模型行为的退化；预测分布与输出校准是模型专属的仪表盘。
• A/B 测试 ≠ 金丝雀: 金丝雀求稳（快速止血能力），A/B 求证（统计显著性）；混用会导致"A/B 还没显著就因为小故障回滚"或"金丝雀放太久失去止损意义"。
• 再训练 ≠ 模型更新: 重训解决"分布变了"，改特征/改架构解决"表达能力不够"；退化时先归因再动手，重训不是万能药。
• MLOps ≠ 实验 tracking ≠ DevOps: 三者管三段（上线后生命周期 / 实验期记账 / 基础设施通用工程），岗位与工具链都不相同。

相关 skills

• depends-on: ml-methodology-router（总入口）, ml-pitfall-audit（上线前闸门，通过后才进入本 skill 辖区）
• contrasts-with: ml-experiment-tracking（实验期账本 vs 上线后生命周期）, ml-leakage-defense（训练期信息穿越 vs 线上线下环境差异）
• composes-with: ml-evaluation-design（线上 A/B 协议与统计检验）, ml-diagnosis（退化信号的归因入口）

审计信息

• 来源性质: 扩充批E·交叉学科——主题超出西瓜书(2016)覆盖范围，R 段为公认文献与业界白皮书的转述表述（均已标注"（转述）"）
• 验证通过: 待流水线三重验证复核
• 测试通过率: 待阶段 4 测试 (详见 test-prompts.json)
• skill_version: 0.0.1
• 蒸馏时间: 2026-08-24