4.1 MLOps 全景：从数据到生产的端到端闭环

4.1 MLOps 全景：从数据到生产的端到端闭环

DevOps 让代码从提交到上线变成自动化流水线；MLOps 要做同样的事，但管理对象从「代码」扩展到「代码 + 数据 + 模型」三件套——这是它比 DevOps 复杂一个量级的根本原因。

4.1.1 MLOps 的核心定义与七大组件

MLOps（Machine Learning Operations） 是 DevOps 思想在机器学习领域的延伸，目标是让 ML 模型的开发、部署、运维像传统软件一样自动化、可复现、可监控、可持续。

一个完整的 MLOps 系统由七大组件构成，覆盖从数据到生产的全链路：

这七大组件的职责分工：

💡 判读：MLOps 的复杂性在于这七大组件不是孤立的，而是「数据流」贯穿的闭环——上游数据变了，下游模型效果就变；模型上线后监控发现漂移，要回到训练环节再训练。这种闭环特性要求每个组件都要有版本管理与可追溯能力。

4.1.2 MLOps vs DevOps：多出来的复杂度

把 MLOps 与 DevOps 放在一起对比，能清楚看到 ML 系统的额外复杂度：

最关键的差异是 「数据变了模型效果就变」。传统软件只要代码不变，线上行为就稳定；但 ML 系统即使代码不动，只要线上数据分布发生变化（数据漂移），模型效果就会衰退。这要求 MLOps 必须有「持续监控 + 自动再训练」能力，这是 DevOps 完全没有的维度。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 880 320" font-family="sans-serif" font-size="13">
  <text x="440" y="24" text-anchor="middle" font-size="15" font-weight="bold">DevOps 单向流水线 vs MLOps 闭环</text>

  <!-- DevOps -->
  <rect x="20" y="50" width="840" height="100" rx="8" fill="#dbeafe" stroke="#2563eb"/>
  <text x="40" y="75" font-weight="bold" fill="#1e40af">DevOps：单向（代码 → 部署）</text>
  <g font-size="12" fill="#1e3a8a">
    <rect x="40"  y="90" width="120" height="40" rx="4" fill="#fff" stroke="#2563eb"/>
    <text x="100" y="115" text-anchor="middle">代码提交</text>
    <rect x="200" y="90" width="120" height="40" rx="4" fill="#fff" stroke="#2563eb"/>
    <text x="260" y="115" text-anchor="middle">CI 构建</text>
    <rect x="360" y="90" width="120" height="40" rx="4" fill="#fff" stroke="#2563eb"/>
    <text x="420" y="115" text-anchor="middle">CD 部署</text>
    <rect x="520" y="90" width="120" height="40" rx="4" fill="#fff" stroke="#2563eb"/>
    <text x="580" y="115" text-anchor="middle">监控</text>
    <line x1="160" y1="110" x2="200" y2="110" stroke="#2563eb" marker-end="url(#arr4)"/>
    <line x1="320" y1="110" x2="360" y2="110" stroke="#2563eb" marker-end="url(#arr4)"/>
    <line x1="480" y1="110" x2="520" y2="110" stroke="#2563eb" marker-end="url(#arr4)"/>
  </g>

  <!-- MLOps -->
  <rect x="20" y="170" width="840" height="130" rx="8" fill="#dcfce7" stroke="#16a34a"/>
  <text x="40" y="195" font-weight="bold" fill="#15803d">MLOps：闭环（数据/代码 → 模型 → 部署 → 监控 → 再训练）</text>
  <g font-size="12" fill="#14532d">
    <rect x="40"  y="210" width="100" height="40" rx="4" fill="#fff" stroke="#16a34a"/>
    <text x="90"  y="235" text-anchor="middle">数据/代码</text>
    <rect x="170" y="210" width="100" height="40" rx="4" fill="#fff" stroke="#16a34a"/>
    <text x="220" y="235" text-anchor="middle">特征/训练</text>
    <rect x="300" y="210" width="100" height="40" rx="4" fill="#fff" stroke="#16a34a"/>
    <text x="350" y="235" text-anchor="middle">评估</text>
    <rect x="430" y="210" width="100" height="40" rx="4" fill="#fff" stroke="#16a34a"/>
    <text x="480" y="235" text-anchor="middle">注册/部署</text>
    <rect x="560" y="210" width="100" height="40" rx="4" fill="#fff" stroke="#16a34a"/>
    <text x="610" y="235" text-anchor="middle">监控</text>
    <line x1="140" y1="230" x2="170" y2="230" stroke="#16a34a" marker-end="url(#arr4)"/>
    <line x1="270" y1="230" x2="300" y2="230" stroke="#16a34a" marker-end="url(#arr4)"/>
    <line x1="400" y1="230" x2="430" y2="230" stroke="#16a34a" marker-end="url(#arr4)"/>
    <line x1="530" y1="230" x2="560" y2="230" stroke="#16a34a" marker-end="url(#arr4)"/>
    <path d="M 610 250 Q 610 285 90 285 Q 90 270 90 250" fill="none" stroke="#16a34a" stroke-dasharray="5,3" marker-end="url(#arr4)"/>
    <text x="350" y="298" text-anchor="middle" font-style="italic" font-size="11">— 漂移/反馈触发再训练，形成闭环</text>
  </g>

  <defs>
    <marker id="arr4" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto">
      <path d="M0,0 L8,3 L0,6 z" fill="#475569"/>
    </marker>
  </defs>
</svg>
​

4.1.3 Google MLOps 成熟度模型：三级跃迁

Google 在 MLOps 白皮书中提出了著名的三级成熟度模型，是评估团队 MLOps 现状的标准尺子。我们在第 1 章 03 节已经简要提过，这里展开讲每一级的特征与跃迁路径。

第 0 级：手工流程（Manual Process）

最常见的状态。数据科学家在 Jupyter Notebook 里完成全流程：

• 数据分析与特征工程手工写。
• 模型训练手工启动，超参数手工调。
• 训练完成后手工导出模型文件。
• 把模型文件交给工程团队，由他们手工部署。

第 0 级的特征：

• 全程无自动化、无版本管理。
• 训练与部署是两个独立系统，由不同团队用不同节奏完成。
• 模型上线后无监控，效果衰退只能靠用户投诉发现。
• 可复现性极差，三个月前的模型无法重建。

第 1 级：训练流水线自动化（ML Pipeline Automation）

训练流程被封装成可重复执行的流水线（Pipeline）：

• 数据处理、特征工程、训练、评估被组织成 DAG（有向无环图）。
• 流水线由触发器自动执行：数据更新、定时任务、手工触发。
• 实验被记录：每次训练的超参、数据版本、指标自动归档。
• 训练结果可复现：同一份代码 + 数据 + 超参能跑出相同结果。

第 1 级的特征：

• 训练自动化，但部署仍半手工。
• 实验可追踪、可复现。
• 模型开始进入注册中心，但晋升靠人工评审。

第 2 级：CI/CD 流水线自动化（CI/CD Pipeline Automation）

训练与部署都进入 CI/CD 闭环：

• 代码、数据、配置的变更自动触发训练。
• 评估达标的模型自动晋升到 Staging、Production。
• 部署支持灰度、A/B、自动回滚。
• 监控发现漂移自动触发再训练（CT，Continuous Training）。

第 2 级的特征：

• 全流程自动化，模型成为持续交付的产物。
• 训练-部署-监控形成闭环。
• 多环境（Dev/Staging/Prod）的模型晋升有门禁。

💡 判读：大多数团队的真实状态是「0.5 级」或「1.2 级」——介于两级之间。MLOps 的演进不是一蹴而就的，而是逐级提升自动化范围。从 0 到 1 的关键是「训练流水线化 + 实验追踪」，从 1 到 2 的关键是「CI/CD + 自动化部署 + 监控闭环」。

4.1.4 七大组件在云原生栈中的落点

把七大组件映射到云原生栈，看每个组件用什么项目实现：

可以看到，开源生态已经覆盖了 MLOps 的全部七大组件，且大多数都能跑在 K8s 上。这是云原生 AI 的成熟度标志——MLOps 不再是少数大厂的专利，而是任何团队都可以搭建的基础设施。

4.1.5 团队成熟度自评清单

给读者一个实用的自评清单，判断自己团队处于哪一级：

第 0 级特征（每符合一项 +1）：

• 训练在 notebook 里手工启动。
• 训练数据没有版本管理。
• 模型导出是手工的。
• 上线后没有模型质量监控。
• 三个月前的模型无法复现。

第 1 级特征（每符合一项 +1）：

• 训练被组织成 Pipeline，可一键重跑。
• 实验有自动追踪（MLflow/W&B）。
• 数据有版本管理（DVC/LakeFS）。
• 特征有集中存储（Feast/特征平台）。
• 训练-评估-注册能自动跑完。

第 2 级特征（每符合一项 +1）：

• 代码/数据变更自动触发训练。
• 评估达标的模型自动晋升到 Staging。
• 部署支持灰度/A/B/自动回滚。
• 监控能检测漂移并触发再训练。
• 多环境（Dev/Staging/Prod）有自动化门禁。

⚠️ 现实提醒：第 2 级是 MLOps 的「北极星」，但盲目追求 2 级可能过度工程化。一个用 LLM API 做应用的小团队，第 1 级就够了；一个有几十个模型在生产的金融团队，才需要完整的第 2 级。成熟度要与业务规模匹配，而不是越高级越好。

4.1.6 MLOps 实施的常见误区

最后总结几个常见误区，帮助读者避坑：

1. 重训练、轻数据：许多团队花大力气搭训练流水线，却忽视数据版本与质量。结果是「训练很快、数据很乱」，模型效果不可控。
2. 重工具、轻流程：买一堆 MLOps 工具（MLflow、Feast、Kubeflow），但没有配套的流程规范，工具沦为摆设。
3. 重离线、轻在线：离线指标好就上线，结果线上效果差（training-serving skew），却找不到原因。
4. 重部署、轻监控：模型上线后没有质量监控，等到用户投诉才发现效果衰退。
5. 重单点、轻闭环：每个组件都有，但没有形成闭环（监控发现问题不能自动回到训练），失去了 MLOps 的精髓。

这五个误区的解法，分别对应本章后续的四节内容（特征存储、实验跟踪、模型注册、监控闭环）。

本节小结

• MLOps = DevOps + 数据/模型三件套，比 DevOps 多了「数据版本、模型版本、漂移监控」三个维度。
• MLOps 七大组件：数据管理、特征工程、模型训练、模型评估、模型注册、模型服务、监控反馈，形成闭环。
• MLOps vs DevOps 的最关键差异是「数据变了模型效果就变」，要求持续监控与自动再训练。
• Google 0/1/2 级成熟度是评估团队现状的标准尺子：第 0 级手工、第 1 级训练流水线、第 2 级 CI/CD 闭环。
• 多数团队处于 0.5-1.2 级，演进是逐级提升自动化范围，不是一蹴而就。
• 七大组件在云原生栈中都有开源实现，MLOps 已非少数大厂专利。
• 五个常见误区：重训练轻数据、重工具轻流程、重离线轻在线、重部署轻监控、重单点轻闭环。

下一节《4.2 特征存储：离线训练与在线服务的一致性》将深入 MLOps 中最容易踩坑的「特征一致性」问题。