什么是 MLOps？团队如何构建、部署和监控机器学习系统

MLOps 是一种工程与治理学科，旨在可重复地构建、部署、监控和更新生产环境中的机器学习系统。

MLOps 需要精确定义，因为它的名称指代特定的信息流、训练选择、运行时机制或治理边界。将其等同于“高级 AI”会导致无法检验的主张。本指南将从概念的输入与假设出发，追踪其可观察的结果，并检验最易与之混淆的快捷方式。

MLOps: 定义、边界与目的

MLOps 是一种工程与治理学科，旨在可重复地构建、部署、监控和更新生产环境中的机器学习系统。该定义包含三个实际承诺: 即存在可识别的输入、MLOps 特有的转换或决策，以及可依据既定目标进行评估的结果。如果缺少其中任何要素，该标签可能仅描述一种愿景，而非已实现的机制。

统计学习将有限样本转化为对未来数据的推断。因此，划分、优化、正则化、度量和监控都是同一泛化问题的一部分，而非孤立的教材技术。对于 MLOps 来说，这种系统视角至关重要，因为即使底层模型保持不变，性能也会受到周围数据、接口、硬件、权限和人员的影响。因而，一个有用的解释应当将模型的学习行为与决定何时、何地以及以何种授权使用该行为的产品区分开来。

最常见的误导性简化是仅在 API 上应用 DevOps 而忽视数据和模型生命周期。它可能与 MLOps 共享某些表面特征，但会改变因果链: 不同的证据决定成功与否、不同的资源主导成本、不同的控制防止危害。因此，这一边界是运营层面的，而非术语层面的。

MLOps 的五阶段运营图

该图是 MLOps 的紧凑因果图，并不意味着每种实现都使用五个软件组件。有些系统会合并阶段，有些则循环重复。它仍然有用，因为它要求信息或权限的每次变化都有负责人、输入、输出和测试。

1. 版本化数据、代码、环境和模型: MLOps 中的输入与假设

在 MLOps 的此阶段，系统必须对数据、代码、环境和模型进行版本管理。关键问题不仅是该操作是否发生，而是它使用了哪些信息、改变了哪些状态，以及哪些证据证明该变更有效。审阅者应能够将此操作与仅在 API 上应用、忽视数据和模型生命周期的 DevOps 区分开来，并在相同条件下复现其结果。

进入此 MLOps 阶段的交接应从既定目标开始，并以能够支持自动化训练和验证流水线的结果结束。记录不确定性、被拒的备选方案、资源使用以及边界上任何人工或软件控制。这一追踪能够帮助团队发现，若未在门控中编码真实的接受标准，自动化可能会更快地发布错误数据或模型。

2. 自动化训练和验证流水线: MLOps 中的表示或决策

在 MLOps 的此阶段，系统必须自动化训练和验证流水线。关键问题不仅是该操作是否发生，而是它使用了哪些信息、改变了哪些状态，以及哪些证据证明该变更有效。审阅者应能够将此操作与仅在 API 上应用、忽视数据和模型生命周期的 DevOps 区分开来，并在相同条件下复现其结果。

进入此 MLOps 阶段的交接应从版本化数据、代码、环境和模型开始，并以能够支持注册已批准的制品与血缘的结果结束。记录不确定性、被拒的备选方案、资源使用以及边界上任何人工或软件控制。这一追踪能够帮助团队发现，若未在门控中编码真实的接受标准，自动化可能会更快地发布错误数据或模型。

3. 注册已批准的制品与血缘: MLOps 中的独特转换

在 MLOps 的此阶段，系统必须注册已批准的制品与血缘。关键问题不仅是该操作是否发生，而是它使用了哪些信息、改变了哪些状态，以及哪些证据证明该变更有效。审阅者应能够将此操作与仅在 API 上应用、忽视数据和模型生命周期的 DevOps 区分开来，并在相同条件下复现其结果。

进入此 MLOps 阶段的交接应从自动化训练和验证流水线开始，并以能够支持回滚并分阶段发布的结果结束。记录不确定性、被拒的备选方案、资源使用以及边界上任何人工或软件控制。这一追踪能够帮助团队发现，若未在门控中编码真实的接受标准，自动化可能会更快地发布错误数据或模型。

4. 回滚并分阶段发布: MLOps 中的约束与验证边界

在 MLOps 的此阶段，系统必须回滚并分阶段发布。关键问题不仅是该操作是否发生，而是它使用了哪些信息、改变了哪些状态，以及哪些证据证明该变更有效。审阅者应能够将此操作与仅在 API 上应用、忽视数据和模型生命周期的 DevOps 区分开来，并在相同条件下复现其结果。

进入此 MLOps 阶段的交接应从注册已批准的制品与血缘开始，并以能够支持监控服务、数据和模型行为的结果结束。记录不确定性、被拒的备选方案、资源使用以及边界上任何人工或软件控制。这一追踪能够帮助团队发现，若未在门控中编码真实的接受标准，自动化可能会更快地发布错误数据或模型。

5. 监控服务、数据与模型行为: MLOps 中的输出、反馈与停止规则

在 MLOps 的此阶段，系统必须监控服务、数据与模型行为。关键问题不仅是该操作是否发生，而是它使用了哪些信息、改变了哪些状态，以及哪些证据证明该变更有效。审阅者应能够将此操作与仅在 API 上应用、忽视数据和模型生命周期的 DevOps 区分开来，并在相同条件下复现其结果。

进入此 MLOps 阶段的交接应从回滚并分阶段发布开始，并以能够支持监控或最终决策的结果结束。记录不确定性、被拒的备选方案、资源使用以及边界上任何人工或软件控制。这一追踪能够帮助团队发现，若未在门控中编码真实的接受标准，自动化可能会更快地发布错误数据或模型。

阅读 MLOps 图的正向可帮助理解生产，逆向则用于诊断失败。正向分析询问一个阶段如何为下一个阶段提供输入。逆向分析从错误、缓慢、昂贵或不安全的结果出发，追溯是哪一早期假设导致的。逆向路径往往是团队发现决定性错误发生在模型产生任何输出之前的地方。

MLOps 实例演示

需求预测可以每月重新训练，经过数据和性能检查后，以金丝雀方式部署，并在出现漂移时回滚。

该示例具有信息价值，因为 MLOps 可以与可观察的输入、中间状态和结果相绑定，而不是通过华丽的演示来评判。严格的测试应围绕该情景构建普通、困难和故意误导的案例，保留未使用该技术的基线，并记录平均性能以及各个失败的严重程度。

在 MLOps 示例中更改一个假设并重复分析。去除必需的输入、引入冲突信号、限制计算、改变用户群体或强制系统弃权。仅在一次精心安排的演示中成功的机制，并未证明其能够在实际运行环境中泛化。

MLOps 与最常见的简化方式对比

MLOps 常被简化为仅在 API 上应用、忽视数据和模型生命周期的 DevOps。此简化剥夺了定义概念的核心边界，可能导致买家比较不相干的产品，研究者夸大实验展示的意义，运营者在部署后监控错误的信号。

比较还应明确分析单位。关于 MLOps 的论文可能只研究一个模型或算法，而已部署的服务还包括检索、路由、缓存、策略、身份、用户界面和监控。两个产品可能使用相同的标题术语，却实现技术栈的不同部分。应追问哪个组件完成定义性的转换，以及报告的结果还依赖哪些组件。

为什么 MLOps 在当前 AI 系统中重要

MLOps 之所以重要，是因为 AI 系统正被赋予更大的上下文、更丰富的模态、更强的运行时计算、更广的工具访问以及与组织决策的更深连接。在这种情况下，曾经看似研究细节的东西可能决定延迟、安全性、可访问性、环境成本、产品质量或法律责任。

关键的衡量标准不是 MLOps 能否产生一次令人印象深刻的结果，而是该技术是否在具代表性的条件下提升了重要的结果，并且比更简单的基线更有效。应报告分布、失败类别、尾部延迟、资源使用以及受影响的子群体，而不是把所有结果压缩为单一平均值。

应根据数据结构和决策成本选择流程。保留群体和时间维度，量化不确定性，检查切片，锁定最终测试，并验证离线收益在部署后是否仍然有效。专门针对 MLOps，这一纪律使证据具备可迁移性: 其他团队可以判断声称的收益是否可能在不同模型、语言、硬件平台、数据集、用户群体或风险容忍度下仍然成立。

MLOps 能带来的收益

使用 MLOps 的最有力理由是它可以直接解决其预期的瓶颈。根据具体实现，收益可能表现为更好的基础、更加忠实的表示、改进的泛化、更低的延迟、减少的内存移动、更清晰的问责，或在模型提议与实际行动之间建立更安全的边界。

收益应以决策和度量的形式表达。“更智能”并不是 MLOps 的接受标准。可行的目标可能规定在困难案例上的错误率、在冲突证据后的恢复能力、在流量某一分位数上的成本、人审时间、校准程度，或在定义的授权限制内保持的行动比例。

定义 MLOps 的失效模式

核心限制在于，除非在门控中编码真实的接受标准，否则自动化可能更快发布错误数据或模型。此失效并非开发完成后才列出的事后考虑，而应从一开始就影响数据收集、架构、权限、评估、发布门控以及 MLOps 的监控。

MLOps 控制只有在昂贵或不可逆的后果发生前采取行动才有用。找出最早可观察到的故障前兆，设定阈值或规则，指定责任人，并测试恢复过程。根据用例，恢复可能意味着拒绝回答、退回到更简单的系统、要求更多证据、升级给人工处理、回滚模型或彻底停止操作。

MLOps 的评估方案

评估 MLOps 时，首先写明证据必须支持的决策。界定运行人群、错误结果的后果、决策时真正可用的信息，以及最简单可信的替代方案。这样可以避免仅仅因为基准易于运行就把它本身变成目标。

使用未动过的测试集进行受控比较，然后在分阶段运行环境中验证 MLOps。离线评估让不同方案可以比较；影子模式、金丝雀发布、速率限制或审批关卡则揭示真实流量、反馈回路和人员如何改变行为。部署阶段应有明确的停止条件，而不是假定每项改进都值得全面上线。

对复现 MLOps 所需的输入进行版本管理：源数据、预处理、分词器或编码器、模型权重、配置、提示词或策略、检索索引、评估集、硬件假设以及适用的服务代码。没有来源记录，团队就无法判断结果变化是来自技术、环境还是未被发现的流水线改动。

最后，应追问什么发现能够证伪 MLOps 有效的主张。如果没有任何结果会改变采用决定，那么评估只是营销。预先承诺的验收阈值和保留的确认集，才能把这项工作变成证据。

采用 MLOps 前应提问的事项

• 目标: MLOps 旨在解决哪一可衡量的瓶颈？
• 机制: 五个阶段中哪一个包含独特的转换？
• 基线: 与仅在 API 上应用、忽视数据和模型生命周期的 DevOps 或其他更简易的方案相比如何？
• 证据: 测试了哪些普通、困难、对抗性以及子群体的案例？
• 运营: 在规模化时会出现哪些延迟、内存、计算、能耗、维护和审查成本？
• 风险: 团队将如何检测到若未在门控中编码真实接受标准，自动化可能更快发布错误数据或模型？
• 恢复: 系统是否能在造成危害前选择弃权、回退、回滚或升级？

学习 MLOps 的主要来源

关于 MLOps 所在 AI 技术栈的权威入门包括 scikit-learn 模型选择指南、Google 机器学习规则、NIST AI 风险管理框架。请结合具体模型、数据集、硬件和适用司法管辖区的文档一起阅读。通用来源可以定义机制，但只有部署特定的证据才能确认某一实现是否合适。

关于 MLOps 的关键记忆点

MLOps 是更大社会技术系统中的已定义机制。其价值来源于在明确条件下改进特定结果，而非标签本身。五阶段图使其信息流可视化，对比帮助识别其非属性，控制路径展示负责的运营者可以介入的环节。

MLOps 的实用规则是：明确目标、与可信基线对比、测试最关键的失效，并保留监控变化所需的证据。拥有这些要素后，该概念成为可评估的工程与治理选择。缺少这些要素，它仍然是一个附着在未知运营风险上的有前景的名称。