MLOps 全生命周期实践：从实验到生产闭环

引言

把一个模型训练出来只完成了 10% 的工作。剩下 90% 是：数据怎么版本化、实验怎么复现、模型怎么注册、上线怎么灰度、效果怎么监控、衰减了怎么重训、出问题怎么回滚、合规怎么审计。这一整套工程与流程体系就是 MLOps（Machine Learning Operations）。

MLOps 的独特之处在于它同时管理三样会变的东西：代码、数据、模型。传统 DevOps 只管代码，而机器学习里数据一换、模型就变，模型一换、线上行为就变。本文给出从实验到生产的完整闭环设计。

前置：模型部署与在线服务的细节见 /ml-model-deployment/；实验跟踪与模型注册表见 /ml-experiment-tracking/。

目录

• 1. MLOps 成熟度分级
• 2. 全生命周期七大阶段
• 3. 版本化与可复现
• 4. CI/CD/CT 流水线
• 5. 编排工具选型
• 6. 部署模式与发布策略
• 7. 监控、告警与回滚
• 8. 治理与模型卡
• 9. 组织与协作
• 10. 常见坑与检查清单
• 11. 总结

1. MLOps 成熟度分级

业界常用三级模型描述团队所处阶段：

判断自己处在哪一级，看一个问题：当数据更新后，模型多久能自动重新上线？ Level 0 是「等有人想起来手动跑」；Level 1 是「定时任务自动跑」；Level 2 是「数据漂移触发即自动验证并发布」。

不要一步跳到 Level 2。多数团队的正确路径是先补齐 Level 1 的版本化与自动化，再谈全自动。盲目上全自动流水线，只会把混乱自动化。

2. 全生命周期七大阶段

数据 → 实验 → 训练 → 注册 → 部署 → 监控 → 重训
 ↑                                          │
 └──────────────── 反馈闭环 ────────────────┘

2.1 数据阶段

数据采集、清洗、标注、版本化。产出是带版本号的数据集。核心要求是：任何一次训练都能追溯到确切的数据快照。

2.2 实验阶段

特征工程、模型选型、超参搜索。产出是实验记录（参数、指标、产物）。核心要求是：实验可比较、可复现。

2.3 训练阶段

把选定配置跑成最终模型，做完整评估（含分组评估、压力测试）。产出是候选模型 + 评估报告。

2.4 注册阶段

候选模型进入模型注册表（Model Registry），带上版本、血缘、指标、审批状态。注册表是 MLOps 的中枢——它连接训练与部署。

2.5 部署阶段

打包、上线、灰度。产出是可服务的推理端点。

2.6 监控阶段

跟踪线上指标、数据漂移、系统健康。产出是告警与数据，驱动重训决策。

2.7 重训阶段

按定时或漂移触发重新训练、验证、发布。闭环回到部署。

每个阶段的产物都要带版本、带血缘、可回溯，这是整个体系的地基。

3. 版本化与可复现

3.1 三样都要版本化

一个可复现的实验需要四者齐备。缺任何一个，别人都跑不出同样的结果。

# 用 DVC 把数据纳入版本控制
dvc init
dvc add data/train_v3.parquet
git add data/train_v3.parquet.dvc data/.gitignore
git commit -m "data: train v3"

# 复现历史实验
git checkout <experiment-commit>
dvc checkout
python train.py --config configs/best.yaml

3.2 环境锁定

「在我机器上能跑」是 MLOps 头号故障。用容器锁定整个环境：

FROM python:3.11-slim
WORKDIR /app
COPY requirements.lock .
RUN pip install --no-cache-dir -r requirements.lock
COPY src/ ./src/
CMD ["python", "-m", "src.serve"]

requirements.lock 必须是完全固定的版本（pip freeze 产物），而不是 requirements.txt 里的宽松约束。容器化的深入实践可延伸阅读 Docker 专题 。

4. CI/CD/CT 流水线

MLOps 的流水线比传统 CI/CD 多一个 CT（Continuous Training，持续训练）。

4.1 三种触发方式

4.2 CI 阶段要测什么

机器学习 CI 不只是跑单元测试，还要测数据与模型：

# .github/workflows/ci.yml（示意）
name: ml-ci
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 单元测试
        run: pytest tests/unit -q
      - name: 数据 schema 校验
        run: python -m src.validate_data --data data/sample.parquet
      - name: 训练冒烟测试
        run: python -m src.train --smoke --epochs 1
      - name: 模型质量门禁
        run: python -m src.eval_gate --min-auc 0.80

质量门禁（Quality Gate） 是关键：模型 AUC 低于阈值就阻断流水线，不让劣质模型上线。

4.3 CD 阶段的发布门禁

CD 不是「注册即上线」，而是分级放行：

注册 → 预发环境验证 → 影子流量 → 金丝雀 5% → 逐步放量 → 全量
         │失败            │失败        │失败
         └────────────── 自动回滚 ──────────────┘

5. 编排工具选型

选择原则：已有 K8s 就用 Kubeflow/Argo；以数据管道为主用 Airflow/Dagster；小团队快速起步用 Metaflow + MLflow。数据侧的编排实践可延伸阅读 数据工程专题 。

# Metaflow 风格：用装饰器描述流水线步骤
from metaflow import FlowSpec, step

class TrainFlow(FlowSpec):
    @step
    def start(self):
        self.raw = load_data()
        self.next(self.featurize)

    @step
    def featurize(self):
        self.X, self.y = build_features(self.raw)
        self.next(self.train)

    @step
    def train(self):
        self.model = fit(self.X, self.y)
        self.next(self.end)

    @step
    def end(self):
        print("训练完成")

if __name__ == "__main__":
    TrainFlow()

6. 部署模式与发布策略

6.1 三种推理模式

6.2 发布策略

• 影子部署（Shadow）：新模型并行接收流量但不返回结果，只记录预测，用于比对而不影响用户。
• 金丝雀（Canary）：新模型接 1~5% 流量，观察指标正常再逐步放量。
• A/B 测试：按用户分流，比较业务指标，统计显著性后再全量。
• 蓝绿（Blue-Green）：新旧两套环境，一键切换，回滚最快。

影子:   100% 流量 → 旧模型（返回） + 新模型（只记录）
金丝雀: 95% → 旧模型,  5% → 新模型
A/B:    50% → A,       50% → B（按用户哈希固定）
蓝绿:   全量 → 蓝环境；验证通过 → 切到绿环境

分流的确定性哈希实现与 A/B 分析方法属于模型部署的核心内容。

7. 监控、告警与回滚

7.1 监控四层

模型层与业务层才是 ML 特有。系统层健康不代表模型有效——服务正常但预测全错的情况很常见。

7.2 漂移告警

数据漂移用 PSI、KS 等指标量化，设动态基线阈值。核心原则是：告警要能驱动行动，不能只报「PSI 上升」而不给出「该重训」的结论。漂移检测的完整方法见 /ml-model-monitoring-drift/。

import numpy as np

def psi(expected, actual, bins=10):
    """群体稳定性指数：<0.1 稳定，0.1~0.25 需关注，>0.25 显著漂移"""
    breakpoints = np.percentile(expected, np.linspace(0, 100, bins + 1))
    breakpoints[0], breakpoints[-1] = -np.inf, np.inf
    e = np.histogram(expected, breakpoints)[0] / len(expected)
    a = np.histogram(actual, breakpoints)[0] / len(actual)
    e, a = np.clip(e, 1e-6, None), np.clip(a, 1e-6, None)
    return np.sum((a - e) * np.log(a / e))

rng = np.random.default_rng(0)
train = rng.normal(0, 1, 10000)
live = rng.normal(0.3, 1.2, 10000)
print("PSI:", round(psi(train, live), 4))

7.3 回滚

回滚必须一键且快速。前提是模型注册表里保留着上一个稳定版本，且部署系统支持按版本切换。

告警触发 → 确认异常 → 切回上一稳定版本 → 排查根因 → 修复后重新发布
目标：从发现到回滚 < 15 分钟

8. 治理与模型卡

8.1 模型卡（Model Card）

每个上线的模型都应有一张模型卡，记录：

模型卡让模型从「某个人的黑盒」变成「团队的资产」。

8.2 审批与审计

高风险模型（信贷、医疗、招聘）需要人工审批门禁：模型不能自动上线，必须经负责人确认评估报告。所有上线、回滚、重训操作都要留审计日志，满足合规要求。

代码提交 → CI 通过 → 模型注册 → 评估报告生成 → 人工审批 → 部署
                                                    │
                                              审计日志留痕

9. 组织与协作

9.1 角色分工

小团队常一人多角，但上线审批与开发应尽量分离，避免「自己训练自己上线」的治理漏洞。

9.2 平台还是工具

早期用现成工具（MLflow + Airflow + Docker）拼装即可；当模型数量超过 2030 个、团队超过 510 人时，再考虑自建平台。过早自建平台是常见陷阱——维护成本高，而团队真正的瓶颈往往是数据质量而非平台能力。

10. 常见坑与检查清单

上线前检查清单：数据/代码/模型是否都已版本化；是否通过质量门禁；是否做过分组评估；是否有灰度计划；监控是否覆盖数据与模型层；回滚是否演练过；是否有模型卡与审批记录。

11. 总结

11.1 核心要点

• MLOps 的独特挑战是同时管理代码、数据、模型三样会变的东西。
• 成熟度分级提醒：先把版本化与自动化做扎实，再谈全自动。
• 全生命周期七阶段中，模型注册表是连接训练与部署的中枢。
• 流水线比 DevOps 多一个 CT（持续训练），由定时或漂移触发。
• 部署要分级放行：影子 → 金丝雀 → A/B → 全量。
• 监控必须覆盖数据层与模型层，回滚要能在分钟级完成。
• 治理靠模型卡 + 审批 + 审计日志，让模型成为团队资产。

11.2 与相邻实践的衔接

部署实现见 /ml-model-deployment/，特征一致性见 /ml-feature-store/，基础设施可结合 Kubernetes 专题 。