MLOps（深度工作流）

MLOps 将 研究速度 与 生产可靠性 相连接：对 数据、代码 和 制品（artifacts） 进行统一版本管理；在部署后持续监控模型的 行为。

何时提供该工作流

触发条件：

• 首个投入生产的模型；支持批处理或在线服务
• 出现数据漂移（drift）、偏差（bias）或延迟超出 SLO
• 合规性要求，例如可追溯性（lineage）与可解释性（explainability）

初始建议方案：

采用 六个阶段：（1）问题定义与风险分类，（2）数据管理与可复现性，（3）训练与评估，（4）打包与部署，（5）监控与反馈，（6）治理与回滚。需明确确认为批处理还是实时模式，并确定监管等级（regulatory tier）。

阶段 1：问题定义与风险分类

目标：将机器学习任务与决策风险对齐（例如信贷审批、医疗诊断 vs 推荐系统）。

退出条件：离线与在线的成功指标均已明确定义。

阶段 2：数据管理与可复现性

目标：对训练数据进行快照存档；构建确定性（deterministic）的数据流水线；妥善处理 PII（个人身份信息）。

实践要点

• 特征存储（feature store）非必需，但对保障一致性极具价值
• 密钥（secrets）不得硬编码于 notebook 中；应通过编排任务（orchestrated jobs）统一管理

退出条件：给定 run id 可在约定误差范围内复现对应制品（artifact）的哈希值。

阶段 3：训练与评估

目标：确保训练/验证/测试集无数据泄露；时间序列场景下需谨慎设计数据切分方式。

实践要点

• 使用模型卡片（model card）明确标注能力边界与核心指标
• 在政策有明确要求的场景中，开展公平性切片分析（fairness slices）

阶段 4：打包与部署

目标：生成不可变制品（immutable artifacts）；上线前执行金丝雀发布（canary）或影子流量（shadow）验证。

实践要点

• 模型与其预处理代码需绑定同一版本号共同管理

退出条件：已明确记录回滚至前一制品 ID（artifact id）的具体操作路径。

阶段 5：监控与反馈

目标：监测数据漂移（data drift）、概念漂移（concept drift）及服务延迟；将业务 KPI 与模型决策结果建立关联。

实践要点

• 在必要时，为低置信度预测结果设置人工审核队列（human review queue）

阶段 6：治理与回滚

目标：对模型重训练与部署操作实施审批机制；保留完整审计日志（audit trail）；针对重大变更启用 A/B 测试。

最终评审检查清单

• 离线指标与业务风险对齐
• 数据与代码具备可复现性
• 制品已打包并实现版本化管理与回滚能力
• 已建立线上监控体系与漂移应对策略
• 治理机制与审批流程已就绪

高效指导建议

• 训练-服务偏差（training-serving skew）是最常见缺陷之一——建议通过特征一致性测试（feature parity tests）提前识别。
• 离线准确率 ≠ 线上实际业务效果。
• 公平性评估需依赖显式定义的切片维度（explicit slices），而非仅依赖单一汇总指标（headline number）。

异常情况处理

• LLM 密集型产品：优先采用评估框架（eval harnesses）与提示词版本管理（prompt versioning）（参见 llm-evaluation）。
• 小型团队：可先从制品注册中心（artifact registry）与基础监控看板（dashboards）起步，暂不急于构建完整特征存储（feature store）。