随着机器学习和人工智能在软件产品和服务中的传播，我们需要建立最佳实践和工具来测试、部署、管理和监控实际生产中的机器学习模型。简而言之，通过 MLOps，我们努力避免机器学习应用程序中的“技术债务”。
SIG MLOps 将“最佳 MLOps 体验定义为一种机器学习资产与 CI/CD 环境中的所有其他软件资产一致处理的体验。机器学习模型可以与包装它们的服务和使用它们的服务一起部署，作为统一发布过程的一部分。”
通过编写这些实践，我们希望加速 ML/AI 在软件系统中的采用和智能软件的快速交付。在下文中，我们描述了 MLOps 中的一组重要概念，例如迭代增量开发、自动化、持续部署、版本控制、测试、可复现性和监控。
1 MLOps 中的迭代增量过程
完整的 MLOps 流程包括“设计 ML 驱动的应用程序”、“ML 实验和开发”和“ML 运维”三个主要阶段。
第一阶段致力于业务理解、数据理解和设计机器学习驱动的软件。在这个阶段，我们确定潜在用户，设计机器学习解决方案来解决问题，并评估项目的进一步发展。大多数情况下，我们会针对两类问题采取行动——要么提高用户的工作效率，要么提高应用程序的交互性。
最初，我们定义 ML 用例并对其进行优先级排序。ML 项目的最佳实践是一次处理一个 ML 用例。此外，设计阶段旨在检查训练我们的模型所需的可用数据，并指定我们的 ML 模型的功能和非功能要求。我们应该使用这些需求来设计 ML 应用程序的架构，建立服务策略，并为未来的 ML 模型创建一个测试套件。
随后的“ML 实验和开发”阶段致力于通过实现ML模型的概念证明来验证 ML 对我们问题的适用性。在这里，我们迭代地运行不同的步骤，例如为我们的问题、数据工程和模型工程识别或完善合适的 ML 算法。此阶段的主要目标是交付我们将在生产中运行的质量稳定的 ML 模型。
“ML 运维”阶段的主要重点是通过使用已建立的 DevOps 实践（例如测试、版本控制、持续交付和监控）在生产中交付先前开发的 ML 模型。
这三个阶段相互关联，相互影响。例如，设计阶段的设计决策将传播到实验阶段，并最终影响最终运维阶段的部署选项。
2 自动化
数据、机器学习模型和代码流水线的自动化水平决定了机器学习过程的成熟度。随着成熟度的提高，新模型的训练速度也随之提高。MLOps 团队的目标是将 ML 模型自动部署到核心软件系统或作为服务组件。这意味着，无需任何人工干预即可自动执行完整的 ML 工作流程步骤。自动模型训练和部署的触发器可以是日历事件、消息传递、监控事件以及数据、模型训练代码和应用程序代码的更改。
自动化测试有助于在早期阶段快速发现问题。这样可以快速修复错误并从错误中学习。
为了采用 MLOps，我们看到自动化的三个层次，从训练和部署的初始级别手动模型开始，到自动运行 ML 和 CI/CD 流水线。
- 手动过程。 这是一个典型的数据科学过程，在实施机器学习之初就执行。该级别具有实验性和迭代性。每个流水线中的每个步骤，例如数据准备和验证、模型训练和测试，都是手动执行的。处理的常用方法是使用快速应用程序开发 (RAD) 工具，例如 Jupyter Notebooks。
- ML 流水线自动化。 下一个级别包括自动执行模型训练。我们在这里介绍模型的持续训练。每当有新数据可用时，就会触发模型重新训练的过程。这一级别的自动化还包括数据和模型验证步骤。
- CI/CD 流水线自动化。 在最后阶段，我们引入了 CI/CD 系统，以在生产中执行快速可靠的 ML 模型部署。与上一步的核心区别在于，我们现在自动构建、测试和部署数据、ML 模型和 ML 训练流水线组件。
下图显示了带有 CI/CD 过程的自动化 ML 流水线：
图来自“MLOps：机器学习中的持续交付和自动化流水线”
下表解释了反映 ML 流水线自动化过程的 MLOps 阶段：
MLOps 阶段 | 阶段执行的输出 |
开发与实验（机器学习算法、新机器学习模型） | 流水线源代码：数据抽取、验证、准备、模型训练、模型评估、模型测试 |
流水线持续集成（构建源代码并运行测试） | 要部署的流水线组件：包和可执行文件。 |
流水线持续交付（将流水线部署到目标环境） | 使用模型的新实现部署流水线。 |
自动触发（流水线在生产中自动执行。使用计划或触发器） | 存储在模型注册表中的训练模型。 |
模型持续交付（模型服务于预测） | 部署模型预测服务（例如模型暴露为 REST API） |
监控（在实时数据上收集有关模型性能的数据） | 触发以执行流水线或开始新的实验周期。 |
在分析 MLOps 阶段之后，我们可能会注意到 MLOps 设置需要安装或准备几个组件。下表列出了这些组件：
MLOps 设置组件 | 描述 |
源代码控制 | 对代码、数据和 ML 模型制品进行版本控制。 |
测试和构建服务 | 将 CI 工具用于 (1) 所有 ML 制品的质量保证，以及 (2) 为流水线构建包和可执行文件。 |
部署服务 | 使用 CD 工具将流水线部署到目标环境。 |
模型注册表 | 用于存储已训练的 ML 模型的注册表。 |
特征存储 | 将输入数据预处理为要在模型训练流水线和模型服务期间使用的特征。 |
机器学习元数据存储 | 跟踪模型训练的元数据，例如模型名称、参数、训练数据、测试数据和指标结果。 |
机器学习流水线编排器 | 自动化机器学习实验的步骤。 |
进一步阅读：“MLOps：机器学习中的持续交付和自动化流水线”
3 持续 X
为了理解模型部署，我们首先将“机器学习资产”指定为机器学习模型、模型参数和超参数、训练脚本、训练和测试数据。我们对这些 ML 制品的身份、组件、版本控制和依赖关系感兴趣。ML 制品的目标目的地可能是（微）服务或一些基础设施组件。部署服务提供编排、日志记录、监控和通知，以确保 ML 模型、代码和数据制品是稳定的。
MLOps 是一种机器学习工程文化，包括以下实践：
- 持续集成 (CI)通过添加测试和验证数据和模型来扩展测试和验证代码和组件。
- 持续交付 (CD)涉及交付自动部署另一个 ML 模型预测服务的 ML 训练流水线。
- 持续训练 (CT)是 ML 系统属性所独有的，它会自动重新训练 ML 模型以进行重新部署。
- 持续监控 (CM)关注与业务指标绑定的生产数据和模型性能指标的监控。
4 版本控制
版本控制的目标是通过使用版本控制系统跟踪 ML 模型和数据集，将用于模型训练的 ML 训练脚本、ML 模型和数据集视为 DevOps 流程中的一等公民。ML 模型和数据发生变化（根据SIG MLOps）的常见原因如下：
- 可以根据新的训练数据重新训练 ML 模型。
- 模型可以基于新的训练方法进行再训练。
- 模型可能是自学习的。
- 模型可能会随着时间的推移而退化。
- 模型可以部署在新的应用程序中。
- 模型可能会受到攻击并需要修改。
- 模型可以快速回滚到以前的服务版本。
- 企业或政府合规性可能需要对 ML 模型或数据进行审计或调查，因此我们需要访问生产系统中ML 模型的所有版本。
- 数据可能驻留在多个系统中。
- 数据可能只能驻留在受限制的司法管辖区。
- 数据存储可能不是一成不变的。
- 数据所有权可能是一个因素。
与开发可靠软件系统的最佳实践类似，每个 ML 模型规范（创建 ML 模型的 ML 训练代码）都应经过代码审查阶段。此外，每个 ML 模型规范都应在版本控制软件中进行版本控制，以使 ML 模型的训练可审计和可复现。
进一步阅读：我们如何管理 ML 模型？模型管理框架：https://www.inovex.de/blog/machine-learning-model-management/
5 实验跟踪
机器学习开发是一个高度迭代和以研究为中心的过程。与传统的软件开发过程相比，在机器学习开发中，可以并行执行多个模型训练实验，然后再决定将什么模型推送到生产环境。
ML 开发期间的实验可能有以下场景：跟踪多个实验的一种方法是使用不同的Git分支，每个分支都专用于单独的实验。每个分支的输出都是经过训练的模型。根据所选指标，将训练好的 ML 模型相互比较并选择合适的模型。
这种低摩擦分支完全由工具DVC支持，它是Git的扩展，也是机器学习项目的开源版本控制系统。另一个流行的机器学习实验跟踪工具是权重和偏差 (wandb)库，它自动跟踪实验的超参数和指标。
6 测试
图来源：E.Breck 等人“ML 测试分数：ML 生产准备和技术债务减少的标准”。
完整的开发流水线包括三个基本组件，数据流水线、ML 模型流水线和应用程序流水线。根据这种分离，我们区分了 ML 系统中测试的三个范围：特征和数据测试、模型开发测试和ML 基础设施测试。
功能和数据测试
- 数据验证：自动检查数据和特征模式/域。
- 行动：为了构建模式（域值），从训练数据中计算统计数据。此模式可用作训练和服务阶段输入数据的期望定义或语义角色。
- 特征重要性测试以了解新特征是否增加了预测能力。
行动：计算特征列的相关系数。
行动：训练具有一两个特征的模型。
行动：使用特征的子集，例如K留出法训练一组不同的模型。
测量每个特征的数据依赖性、推理延迟和 RAM 使用情况。将其与新增特征的预测能力进行比较。
从您的基础架构中删除未使用/已弃用的特征并记录下来。
特征和数据流水线应符合政策（例如 GDPR）。应在开发和生产环境中以编程方式检查这些要求。
特征创建代码应通过单元测试进行测试（以捕获特征中的错误）。
可靠模型开发的测试
我们需要为检测特定于 ML 的错误提供特定的测试支持。
- 测试 ML 训练应包括例程，以验证算法做出的决策是否与业务目标一致。这意味着 ML 算法损失指标（MSE、日志损失等）应与业务影响指标（收入、用户参与度等）相关联
- 行动：损失指标 - 影响指标关系，可以使用故意降级模型在小规模 A/B 测试中进行测量。
- 进一步阅读：选择正确的指标来评估机器学习模型。这里 1 ,这里 2
- 模型陈旧性测试。如果经过训练的模型不包含最新数据和/或不满足业务影响要求，则该模型被定义为陈旧。陈旧的模型会影响智能软件中的预测质量。
行动：对旧型号进行 A/B 实验。包括生成年龄与预测质量 曲线的年龄范围，以帮助了解应该多久训练一次 ML 模型。
评估更复杂的机器学习模型的成本。
行动：ML 模型的性能应该与简单的基线 ML 模型（例如线性模型与神经网络）进行比较。
验证模型的性能。
建议将收集训练和测试数据的团队和程序分开，以消除依赖关系，避免错误的方法论从训练集传播到测试集（来源）。
行动：使用一个额外的测试集，它与训练集和验证集不相交。仅将此测试集用于最终评估。
ML 模型性能的公平/偏差/包含测试。
行动：收集更多数据，包括可能代表性不足的类别。
行动：检查输入特征是否与受保护的用户类别相关。
延伸阅读：“不平衡分类的数据采样方法之旅”
用于任何特征创建、ML 模型规范代码（训练）和测试的常规单元测试。
模型治理测试（即将推出）
机器学习基础设施测试
- 训练 ML 模型应该是可复现的，这意味着在相同数据上训练 ML 模型应该产生相同的 ML 模型。
- ML 模型的差异测试依赖于确定性训练，由于 ML 算法的非凸性、随机种子生成或分布式 ML 模型训练，这很难实现。
- 行动：确定模型训练代码库中的非确定性部分，并尽量减少非确定性。
- 测试 ML API 的使用。压力测试。
行动：单元测试以随机生成输入数据并为单个优化步骤（例如梯度下降）训练模型。
行动：模型训练的碰撞测试。ML 模型应该在训练中崩溃后从检查点恢复。
测试算法的正确性。
行动：单元测试它不是为了完成 ML 模型训练，而是为了训练几次迭代，并确保训练时损失减少。
避免：与以前构建的 ML 模型进行差异测试，因为这样的测试很难维护。
集成测试：应该对完整的 ML 流水线进行集成测试。
行动：创建一个定期触发整个 ML 流水线的全自动测试。测试应验证数据和代码是否成功完成了训练的每个阶段，并且生成的 ML 模型按预期执行。
所有集成测试都应在 ML 模型到达生产环境之前运行。
在服务之前验证 ML 模型。
行动：设置阈值并测试验证集上许多版本的模型质量缓慢下降。
行动：在新版本的 ML 模型中设置阈值并测试性能突然下降。
ML 模型在服务之前是金丝雀部署。
行动：测试 ML 模型是否成功加载到生产服务中，并按预期生成对真实数据的预测。
测试训练环境中的模型与服务环境中的模型给出相同的分数。
行动：留出数据和“次日”数据的表现之间的差异。总会存在一些差异。注意留出数据和“次日”数据在性能上的巨大差异，因为这可能表明某些时间敏感的特征会导致 ML 模型退化。
行动：避免训练和服务环境之间的结果差异。将模型应用于训练数据中的样本和服务中的相同样本应该会产生相同的预测。此处的差异表明存在工程错误。
7 监控
部署机器学习模型后，需要对其进行监控以确保模型按预期执行。以下生产中模型监控的检查表来自E.Breck 等人2017年的文章“ML 测试分数：ML 生产准备和技术债务减少的标准”。：
- 监控整个流水线中的依赖项更改，如发生则发生通知。
- 数据版本变更。
- 源系统的变化。
- 依赖升级。
- 监控训练和服务输入中的数据不变量：如果数据与在训练步骤中指定的模式不匹配，则发出警报。
行动：调整警报阈值以确保警报仍然有用且不会误导。
监控训练和服务功能是否计算相同的值。
由于训练和服务特性的生成可能发生在物理上分离的位置，我们必须仔细测试这些不同的代码路径在逻辑上是否相同。
行动：（1）记录服务流量的样本。(2) 计算训练特征和采样服务特征的分布统计数据（最小值、最大值、平均值、缺失值百分比等），并确保它们匹配。
监控 ML 模型的数值稳定性。
行动：触发任何 NaN 或无穷大发生的警报。
监控 ML 系统的计算性能。应通知计算性能的剧烈和缓慢泄漏回归。
行动：通过预先设置警报阈值来衡量代码、数据和模型的版本和组件的性能。
行动：收集系统使用指标，如 GPU 内存分配、网络流量和磁盘使用情况。这些指标对于云成本估算很有用。
监控生产中系统的陈旧程度。
测量模型的年龄。较旧的 ML 模型往往会降低性能。
行动：模型监控是一个持续的过程，因此在投入生产之前确定监控要素并制定模型监控策略非常重要。
监控特征生成过程，因为它们对模型有影响。
行动：频繁地重新运行特征生成。
监控 ML 模型对服务数据的预测质量的下降。应通知预测质量的戏剧性和缓慢泄漏回归。
由于数据的变化或不同的代码路径等可能会发生降级。
行动：测量预测中的统计偏差（数据切片中的预测平均值）。模型的偏差应该几乎为零。
行动：如果在做出预测后立即有标签可用，我们可以实时衡量预测的质量并识别问题。
下图显示可以通过跟踪模型预测的精度、召回率和 F1分数随时间的变化来实现模型监控。精度、召回率和 F1 分数的降低会触发模型重新训练，从而导致模型恢复。
8 “机器学习测试评分”系统
机器学习测试评分衡量 ML 系统的整体生产准备情况。最终的ML 测试分数计算如下：
- 对于每个测试，手动执行测试将获得0.5分，并记录和分发结果。
- 如果有一个系统可以重复自动运行该测试，则将获得满分。
- 分别对四个部分的分数求和：数据测试、模型测试、ML 基础设施测试和监控。
- 最终的ML 测试分数是通过取每个部分的最低分数来计算的：数据测试、模型测试、ML 基础设施测试和监控。
在计算机器学习测试分数后，我们可以推断 ML 系统是否已准备好投入生产。下表提供了解释范围：
分数 | 描述 |
0 | 更多的是一个研究项目而不是生产系统。 |
(0,1] | 并非完全未经测试，但值得考虑的是可靠性存在严重漏洞的可能性。 |
(1,2] | 基本生产已经通过，但可能需要额外投资。 |
(2,3] | 经过合理测试，但有可能更多的测试和程序可以自动化。 |
(3,5] | 强大的自动化测试和监控水平。 |
>5 | 卓越的自动化测试和监控水平。 |
资料来源：“ML 测试分数：ML 生产准备和技术债务减少的标准”。E.Breck 等人, 2017
9 可复现性
机器学习工作流程中的可复现性意味着数据处理、ML 模型训练和 ML 模型部署的每个阶段都应该在给定相同输入的情况下产生相同的结果。
阶段 | 挑战 | 如何确保可复现性 |
收集数据 | 无法重现训练数据的生成（例如，由于数据库不断更改或数据加载是随机的） | 1) 始终备份您的数据。 |
特征工程 | 场景： | 1) 特征生成代码应受版本控制。 |
模型训练/模型构建 | 非决定论 | 1) 确保特征的顺序始终相同。 |
模型部署 | 1) 已使用与生产环境不同的软件版本对 ML 模型进行了训练 | 1) 软件版本和依赖关系应与生产环境相匹配。 |
10 松耦合架构（模块化）
根据 Gene Kim 等人在他们的《Accelerate》一书中的说法，“只要系统——以及构建和维护它们的团队——松耦合，所有类型的系统都可以实现 [软件交付] 的高性能。这一关键的架构属性使团队能够轻松地测试和部署单个组件或服务，即使组织及其运行的系统数量不断增长——也就是说，它允许组织随着规模的扩大而提高生产力。”
此外，Gene Kim 等人建议“使用松耦合的架构，这会影响团队可以按需测试和部署其应用程序的程度，而无需与其他服务进行编排。拥有松耦合的架构可以让您的团队独立工作，而无需依赖其他团队的支持和服务，这反过来又使他们能够快速工作并为组织创造价值。”
对于基于 ML 的软件系统，实现机器学习组件之间的松耦合可能比传统软件组件更难。ML 系统在几个方面具有薄弱的组件边界。例如，ML 模型的输出可以用作另一个 ML 模型的输入，并且这种交错的依赖关系可能会在训练和测试期间相互影响。
基本的模块化可以通过构建机器学习项目来实现。要设置标准项目结构，我们建议使用专用模板，例如
- Cookiecutter 数据科学项目模板：https://drivendata.github.io/cookiecutter-data-science/
- 数据科学生命周期过程模板：https://github.com/dslp/dslp-repo-template
- PyScaffold：https://github.com/pyscaffold/pyscaffold
11 基于机器学习的软件交付指标（来自 Accelerate的 4 个指标）
在一份关于DevOps 状态的最新研究（https://services.google.com/fh/files/misc/state-of-devops-2019.pdf）中，作者强调了4个关键指标，这些指标可以衡量精英/高性能组织的软件开发和交付的有效性：部署频率、变更准备时间、平均恢复时间和变更失败率。已发现这些指标可用于衡量和改进基于 ML 的软件交付。在下表中，我们给出了每个指标的定义并建立了与 MLOps 的联系。
指标 | DevOps | MLOps |
部署频率 | 你的组织多久将代码部署到生产环境或将其发布给最终用户？ | ML 模型部署频率取决于 |
变更准备时间 | 从提交的代码到在生产中成功运行的代码需要多长时间？ | ML 模型变更的前置时间取决于 |
平均恢复时间 (MTTR) | 当发生影响用户的服务事件或缺陷（例如，计划外中断或服务受损）时，通常需要多长时间才能恢复服务？ | ML 模型 MTTR 取决于手动执行模型调试的次数和持续时间，以及模型部署步骤。如果应该重新训练 ML 模型，则 MTTR 还取决于 ML 模型训练的持续时间。或者，MTTR 是指 ML 模型回滚到先前版本的持续时间。 |
更改失败率 | 对生产或发布给用户的更改有多少百分比会导致服务降级（例如，导致服务受损或服务中断）并随后需要修复（例如，需要修补程序、回滚、向前修复、修补程序）？ | ML 模型更改失败率可以表示为当前部署的 ML 模型性能指标与之前模型的指标的差异，例如 Precision、Recall、F-1、accuracy、AUC、ROC、false positives 等。ML 模型更改失败率也与 A/B 测试有关。 |
为了提高 ML 开发和交付过程的有效性，应该衡量上述四个关键指标。实现这种有效性的一个实用方法是首先实施 CI/CD 流水线，并对数据、ML 模型和软件代码流水线采用测试驱动的开发。
12 MLOps 原则和最佳实践总结
完整的机器学习开发流水线包括三个可能发生变化的层次：数据、机器学习模型和代码。这意味着在基于机器学习的系统中，构建的触发器可能是代码更改、数据更改或模型更改的组合。下表总结了构建基于机器学习的软件的 MLOps 原则：
MLOps 原则 | 数据 | 机器学习模型 | 代码 |
版本控制 | 1) 数据准备流水线 | 1) ML 模型训练流水线 | 1) 应用代码 |
测试 | 1) 数据验证（错误检测） | 1) 模型规范经过单元测试 | 1) 单元测试 |
自动化 | 1) 数据转换 | 1) 数据工程流水线 | 1) 使用 CI/CD 部署 ML 模型 |
可复现性 | 1）备份数据 | 1) 开发和生产之间的超参数调优相同 | 1) dev 和 prod 中所有依赖项的版本相同 |
部署 | 1) 特征存储用于开发和生产环境 | 1) ML 堆栈的容器化 | 1) 本地、云或边缘 |
监控 | 1) 数据分布变化（训练与服务数据） | 1) ML 模型衰减 | 1) 应用程序对服务数据的预测质量 |
除了 MLOps 原则，遵循一组最佳实践应该有助于减少 ML 项目的“技术债务”：
MLOps 最佳实践 | 数据 | 机器学习模型 | 代码 |
文档 | 1) 数据源 | 1) 模型选择标准 | 1) 部署过程 |
项目结构 | 1) 原始数据和处理后数据的数据文件夹 | 1) 包含训练模型的文件夹 | 1) 用于 bash/shell 脚本的文件夹 |
https://ml-ops.org/content/mlops-principles
