【MLops】MLOps原则

随着机器学习和人工智能在软件产品和服务中的传播，我们需要建立最佳实践和工具来测试、部署、管理和监控现实世界生产中的ML模型。简而言之，通过MLOps，我们努力避免机器学习应用程序中的“技术债务”。

SIG MLOps将“最佳MLOps体验定义为在CI/CD环境中，机器学习资产与所有其他软件资产得到一致处理。作为统一发布过程的一部分，机器学习模型可以与包装它们的服务和使用它们的服务一起部署。”，我们希望加快ML/AI在软件系统中的应用，并快速交付智能软件。在下文中，我们描述了MLOps中的一组重要概念，如迭代增量开发、自动化、连续部署、版本控制、测试、再现性和监控。

MLOps中的迭代增量过程

完整的MLOps过程包括三个广泛的阶段：“设计ML驱动的应用程序”、“ML实验和开发”和“ML操作”。

 

第一阶段致力于业务理解、数据理解和ML驱动软件的设计。在这个阶段，我们确定我们的潜在用户，设计机器学习解决方案来解决其问题，并评估项目的进一步发展。大多数情况下，我们会处理两类问题——要么提高用户的生产力，要么提高应用程序的交互性。

 

最初，我们定义ML用例并对它们进行优先级排序。ML项目的最佳实践是一次处理一个ML用例。此外，设计阶段旨在检查训练我们的模型所需的可用数据，并指定ML模型的功能和非功能需求。我们应该使用这些需求来设计ML应用程序的体系结构，建立服务策略，并为未来的ML模型创建一个测试套件。

 

后续阶段“ML实验和开发”致力于通过实现ML模型的概念证明来验证ML对我们的问题的适用性。在这里，我们迭代地运行不同的步骤，例如为我们的问题、数据工程和模型工程确定或完善合适的ML算法。这个阶段的主要目标是提供一个稳定质量的ML模型，我们将在生产中运行。

 

“ML操作”阶段的主要重点是通过使用已建立的DevOps实践（如测试、版本控制、连续交付和监控），在生产中交付先前开发的ML模型。

 

这三个阶段相互关联，相互影响。例如，设计阶段的设计决策将传播到实验阶段，并最终影响最终操作阶段的部署选项。

 

自动化

数据、ML模型和代码管道的自动化程度决定了ML过程的成熟度。随着成熟度的提高，新模型的训练速度也在提高。MLOps团队的目标是将ML模型自动部署到核心软件系统或作为服务组件。这意味着，在没有任何手动干预的情况下，自动化整个ML工作流步骤。自动化模型培训和部署的触发器可以是日历事件、消息传递、监视事件，以及数据、模型培训代码和应用程序代码的更改。

 

自动化测试有助于在早期快速发现问题。这使得能够快速修复错误并从错误中学习。

 

为了采用MLOps，我们看到了三个自动化级别，从手动模型训练和部署的初始级别开始，到自动运行ML和CI/CD管道。

 

• 手动过程。这是一个典型的数据科学过程，在实现ML之初执行。这个级别具有实验性和迭代性。每个管道中的每个步骤，如数据准备和验证、模型训练和测试，都是手动执行的。常见的处理方式是使用快速应用程序开发（RAD）工具，如Jupyter Notebooks。
• ML管道自动化。下一个级别包括自动执行模型训练。我们在这里介绍模型的持续训练。只要有新的数据可用，就会触发模型再训练过程。这种自动化水平还包括数据和模型验证步骤。
• CI/CD管道自动化。在最后阶段，我们引入了一个CI/CD系统，以在生产中执行快速可靠的ML模型部署。与前一步的核心区别在于，我们现在自动构建、测试和部署数据、ML模型和ML训练管道组件。

下图显示了带有CI/CD例程的自动化ML管道：

Figure adopted from “MLOps: Continuous delivery and automation pipelines in machine learning”

下表解释了反映ML管道自动化过程的MLOps阶段：

MLOps Stage	Output of the Stage Execution
开发与实验（ML算法、新的ML模型）	管道源代码：数据提取、验证、准备、模型训练、模型评估、模型测试
管道持续集成（构建源代码并运行测试）	要部署的管道组件：包和可执行文件。
管道连续交付（将管道部署到目标环境）	部署了具有新模型实现的管道。
自动触发（流水线在生产中自动执行。使用计划或触发器）	存储在模型注册表中的经过训练的模型。
模型连续交付（用于预测的模型）	已部署的模型预测服务（例如，作为REST API公开的模型）
监控（在实时数据上收集有关模型性能的数据）	触发以执行管道或开始新的实验循环。

在分析了MLOps阶段之后，我们可能会注意到MLOps设置需要安装或准备几个组件。下表列出了这些组件：

MLOps Setup Components	Description
Source Control	对代码、数据和ML模型工件进行版本控制。
Test & Build Services	使用CI工具（1）确保所有ML工件的质量，以及（2）构建管道的包和可执行文件。
Deployment Services	使用CD工具将管道部署到目标环境。
Model Registry	用于存储已训练的ML模型的注册表。
Feature Store	将输入数据预处理为要在模型训练管道中和模型服务期间使用的特征。
ML Metadata Store	跟踪模型训练的元数据，例如模型名称、参数、训练数据、测试数据和度量结果。
ML Pipeline Orchestrator	使ML实验的步骤自动化。

“MLOps: Continuous delivery and automation pipelines

 in machine learning”

连续X

为了理解模型部署，我们首先将“ML资产”指定为ML模型、其参数和超参数、训练脚本、训练和测试数据。我们对这些ML工件的身份、组件、版本控制和依赖性很感兴趣。ML工件的目标目的地可能是（微）服务或一些基础设施组件。部署服务提供编排、日志记录、监视和通知，以确保ML模型、代码和数据工件是稳定的。

 

MLOps是一种ML工程文化，包括以下实践：

 

• 连续集成（CI）通过添加测试和验证数据和模型来扩展测试和验证代码和组件。
• 连续交付（CD）涉及ML训练管道的交付，该管道自动部署另一个ML模型预测服务。
• 连续训练（CT）是ML系统属性所独有的，它可以自动重新训练ML模型以进行重新部署。
• 持续监控（CM）关注的是监控生产数据和模型性能指标，这些指标与业务指标绑定。

版本控制

版本控制的目标是通过使用版本控制系统跟踪ML模型和数据集，将用于模型训练的ML训练脚本、ML模型和数据库集视为DevOps过程中的一流公民。ML模型和数据发生变化（根据SIG MLOps）的常见原因如下：

 

• ML模型可以基于新的训练数据进行再训练。
• 模型可以基于新的训练方法进行再训练。
• 模型可能是自学习的。
• 模型可能会随着时间的推移而退化。
• 模型可以部署在新的应用程序中。
• 模型可能会受到攻击，需要修改。
• 模型可以快速回滚到以前的服务版本。
• 企业或政府合规性可能需要对ML模型或数据进行审计或调查，因此我们需要访问产品化ML模型的所有版本。
• 数据可能存在于多个系统中。
• 数据可能只能驻留在受限制的司法管辖区内。
• 数据存储可能不是一成不变的。
• 数据所有权可能是一个因素。

与开发可靠软件系统的最佳实践类似，每个ML模型规范（创建ML模型的ML训练代码）都应该经过代码审查阶段。此外，每个ML模型规范都应该在VCS中进行版本化，以使ML模型的训练可审计且可重复。

 

进一步阅读：我们如何管理ML模型？模型管理框架

 

实验跟踪

机器学习开发是一个高度迭代和以研究为中心的过程。与传统的软件开发过程不同，在ML开发中，在决定将什么模型推广到生产之前，可以并行执行多个模型训练实验。

 

ML开发过程中的实验可能有以下场景：跟踪多个实验的一种方法是使用不同的（Git-）分支，每个分支专门用于单独的实验。每个分支的输出都是经过训练的模型。根据所选择的度量，将训练的ML模型相互比较，并选择适当的模型。这种低摩擦分支得到了工具DVC的充分支持，DVC是Git的扩展，也是机器学习项目的开源版本控制系统。另一个流行的ML实验跟踪工具是权重和偏差（wandb）库，它可以自动跟踪实验的超参数和度量。

 

测试

Figure source: “The ML Test Score: A Rubric for ML Production Readiness 

and Technical Debt Reduction” by E.Breck et al. 2017

完整的开发管道包括三个基本组件，数据管道、ML模型管道和应用程序管道。根据这种分离，我们区分了ML系统中的三个测试范围：特性和数据测试、模型开发测试和ML基础设施测试。

 

特性和数据测试

• 数据验证：自动检查数据和功能架构/域。
  • 操作：为了构建模式（域值），请根据训练数据计算统计信息。该模式可以在训练和服务阶段用作输入数据的期望定义或语义角色。
• 功能重要性测试，以了解新功能是否增加了预测能力。
  • 操作：计算要素列的相关系数。
  • 动作：训练具有一个或两个功能的模型。
  • 操作：使用特征的子集“k中的一个”，并训练一组不同的模型。
  • 测量每个新功能的数据依赖性、推理延迟和RAM使用情况。将其与新增功能的预测能力进行比较。
  • 从基础结构中删除未使用/不推荐使用的功能，并将其记录下来。
• 功能和数据管道应符合政策（如GDPR）。这些需求应该在开发和生产环境中以编程方式进行检查。
• 功能创建代码应该通过单元测试进行测试（以捕获功能中的bug）。

可靠模型开发测试

我们需要为检测特定于ML的错误提供特定的测试支持。

 

• 测试ML训练应该包括例程，这些例程验证算法做出的决策是否与业务目标一致。这意味着ML算法损失指标（MSE、日志损失等）应与业务影响指标（收入、用户参与度等）相关
  • 措施：损失指标-影响指标的关系，可以在使用故意降级模型的小规模A/B测试中进行测量。
    • 进一步阅读：选择用于评估机器学习模型的正确度量。这里1，这里2
• 模型老化试验。如果经过训练的模型不包括最新数据和/或不满足业务影响要求，则该模型被定义为过时模型。过时的模型会影响智能软件的预测质量。
  • 操作：A/B对旧型号进行实验。包括生成年龄与预测质量曲线的年龄范围，以便于理解ML模型应该多久训练一次。
• 评估更复杂的ML模型的成本。
  • 措施：应将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模型退化。
  • 行动：避免训练和服务环境之间的结果差异。将模型应用于训练数据中的示例和服务时的相同示例应产生相同的预测。此处的差异表示工程错误。

监控

一旦部署了ML模型，就需要对其进行监控，以确保ML模型按预期执行。以下生产中模型监测活动的检查表来自E.Breck等人2017年的“ML测试分数：ML生产准备和技术债务减少的准则”：

• 在整个管道中监视依赖关系的更改会导致通知。
  • 数据版本更改。
  • 源系统中的更改。
  • 依赖项升级。
• 监视训练和服务输入中的数据不变量：如果数据与训练步骤中指定的模式不匹配，则发出警报。
  • 措施：调整警报阈值，以确保警报仍然有用且不会产生误导。
• 监控训练和服务功能是否计算出相同的值。
  • 由于训练和服务功能的生成可能发生在物理上分离的位置，我们必须仔细测试这些不同的代码路径在逻辑上是否相同。
  • 操作：（1）记录服务流量的样本。（2） 计算训练特征和采样服务特征的分布统计信息（最小值、最大值、平均值、值、缺失值的百分比等），并确保它们匹配。
• 监测ML模型的数值稳定性。
  • 操作：在出现任何NaN或无穷大时触发警报。
• 监控ML系统的计算性能。应通知计算性能中的急剧和缓慢泄漏回归。
  • 操作：通过预先设置警报阈值来衡量代码、数据和模型的版本和组件的性能。
  • 操作：收集系统使用指标，如GPU内存分配、网络流量和磁盘使用情况。这些指标对于云成本估计非常有用。
• 监控系统在生产中的陈旧程度。
  • 测量模型的使用年限。较旧的ML模型的性能往往会下降。
  • 行动：模型监控是一个连续的过程，因此在投入生产之前确定监控要素并制定模型监控策略非常重要。
• 监控特征生成过程对模型的影响。
  • 操作：经常重新运行功能生成。
• 监测ML模型在服务数据上的预测质量下降。应通知预测质量的急剧和缓慢泄漏回归。
  • 降级可能由于数据的更改或不同的代码路径等原因而发生。
  • 措施：测量预测中的统计偏差（一段数据中预测的平均值）。模型应该具有几乎为零的偏差。
  • 措施：如果在做出预测后立即提供标签，我们可以实时测量预测的质量并识别问题。

下图显示，可以通过跟踪模型预测的精度、召回率和F1分数随时间的变化来实现模型监测。精确度、召回率和F1分数的降低触发了模型再训练，从而导致模型恢复。

 

“ML测试分数”系统

“ML测试分数”衡量ML系统的总体生产准备情况。最终ML测试分数计算如下：

• 对于每项测试，手动执行测试将获得半分，并记录和分发测试结果。
• 如果有系统可以重复自动运行该测试，则可获得满分。
• 分别对四个部分的得分求和：数据测试、模型测试、ML基础设施测试和监控。
• 最终的ML测试分数是通过取每个部分的最小分数来计算的：数据测试、模型测试、ML基础设施测试和监控。

在计算ML测试分数后，我们可以推断ML系统的生产准备情况。下表提供了解释范围：

Points	Description
0	更多的是研究项目，而不是生产系统。
(0,1]	并非完全未经测试，但值得考虑可靠性存在严重漏洞的可能性。
(1,2]	在基本的生产化方面已经有了第一次通过，但可能需要额外的投资。
(2,3]	经过合理测试，但可能会有更多的测试和程序实现自动化。
(3,5]	强大的自动化测试和监控水平。
>5	卓越的自动化测试和监控水平。

Source: “The ML Test Score: A Rubric for ML Production Readiness and 

Technical Debt Reduction” by E.Breck et al. 2017

再现性

机器学习工作流程中的可再现性意味着，在给定相同输入的情况下，数据处理、ML模型训练和ML模型部署的每个阶段都应该产生相同的结果。

Phase	Challenges	How to Ensure Reproducibility
Collecting Data	训练数据的生成无法再现（例如，由于数据库不断变化或数据加载是随机的）	1） 始终备份您的数据。 2） 保存数据集的快照（例如在云存储上）。 3） 数据源应设计有时间戳，以便可以检索任何点的数据视图。 4） 数据版本控制。
Feature Engineering	情节： 1） 缺失值用随机值或平均值估算。 2） 根据观察百分比删除标签。 3） 非确定性特征提取方法。	1） 功能生成代码应处于版本控制之下。 2） 要求前一步骤“收集数据”的再现性
Model Training / Model Build	Non-determinism	1） 确保功能的顺序始终相同。 2） 记录并自动化特征转换，如规范化。 3） 记录并自动化超参数 selection. 4） 对于集成学习：对ML模型的组合进行文档化和自动化。
Model Deployment	1） 已经使用不同于生产环境的软件版本来执行ML模型的训练。 2） 生产环境中缺少ML模型所需的输入数据。	1） 软件版本和依赖关系应与生产环境相匹配。 2） 使用容器（Docker）并记录其规范，例如图像版本。 3） 理想情况下，相同的编程语言用于培训和部署。

松散耦合体系结构（模块化）

根据Gene Kim等人在《加速》一书中的说法，“高性能（软件交付）只要系统以及构建和维护它们的团队是松散耦合的，那么所有类型的系统都是可能的。这一关键的体系结构特性使团队能够轻松地测试和部署单个组件或服务，即使组织及其运行的系统数量在增长——也就是说，它允许组织在扩展时提高生产力。”

此外Gene Kim等人。，推荐给“使用松散耦合的体系结构。这会影响团队在多大程度上可以按需测试和部署应用程序，而不需要与其他服务协调。使用松散耦合体系结构可以让团队独立工作，而不依赖其他团队提供支持和服务，这反过来又使他们能够快速工作并为组织带来价值。”

关于基于ML的软件系统，与传统的软件组件相比，实现机器学习组件之间的松散耦合可能更困难。ML系统在几个方面具有弱组件边界。例如，ML模型的输出可以用作另一个ML模型的输入，并且这种交织的依赖关系可能在训练和测试期间相互影响。

基本的模块化可以通过构建机器学习项目来实现。要设置标准的项目结构，我们建议使用专用模板，如

• Cookiecutter Data Science Project Template
• The Data Science Lifecycle Process Template
• PyScaffold

基于ML的软件交付度量（“加速”中的4个度量）

在最近关于DevOps状态的研究中，作者强调了四个关键指标，这些指标反映了精英/高绩效组织的软件开发和交付的有效性：部署频率、变更交付周期、平均恢复时间和变更失败百分比。已经发现这些度量对于测量和改进基于ML的软件交付非常有用。在下表中，我们给出了每个度量的定义，并将其连接到MLOps。

Metric	DevOps	MLOps
部署频率	您的组织多长时间将代码部署到生产环境或发布给最终用户？	ML模型部署频率取决于 1） 模型再培训要求（从不太频繁到在线培训）。模型再培训有两个方面至关重要 1.1）模型衰减度量。 1.2）新数据可用性。 2） 部署过程的自动化程度，可能介于*手动部署*和*完全自动化的CI/CD管道*之间。
变更的交付周期	从提交代码到在生产中成功运行代码需要多长时间？	ML模型变更的交付周期取决于 1） 数据科学探索阶段的持续时间，以最终确定部署/服务的ML模型。 2） ML模型训练的持续时间。 3） 部署过程中手动步骤的数量和持续时间。
平均恢复时间（MTTR）	当发生服务事故或影响用户的缺陷（例如，计划外停机或服务损坏）时，恢复服务通常需要多长时间？	ML模型MTTR取决于手动执行的模型调试和模型部署步骤的数量和持续时间。在这种情况下，当ML模型应该重新训练时，MTTR也取决于ML模型训练的持续时间。或者，MTTR是指ML模型回滚到以前版本的持续时间。
更改失败率	生产更改或发布给用户的更改导致服务降级（例如，导致服务损坏或服务中断）并随后需要补救（例如，需要修补程序、回滚、前向修复、修补）的百分比是多少？	ML模型变化失败率可以表示为当前部署的ML模型性能指标与先前模型的指标的差异，如精度、召回率、F-1、准确性、AUC、ROC、假阳性等。ML模型变化故障率也与A/B测试有关。

为了提高ML开发和交付过程的有效性，应该衡量以上四个关键指标。实现这种有效性的一种实用方法是首先实现CI/CD管道，并采用数据、ML模型和软件代码管道的测试驱动开发。

MLOps原则和最佳实践概述

完整的ML开发管道包括三个可能发生更改的级别：数据、ML模型和代码。这意味着，在基于机器学习的系统中，构建的触发因素可能是代码更改、数据更改或模型更改的组合。下表总结了构建基于ML的软件的MLOps原则：

MLOps 原则	Data	ML Model	Code
版本控制	1） 数据准备管道 2） 功能存储 3） 数据集 4） 元数据	1） ML模型训练管道 2） ML模型（对象） 3） 超参数 4） 实验跟踪	1） 应用程序代码 2） 配置
测试	1） 数据验证（错误检测） 2） 功能创建单元测试	1） 型号规格经过单元测试 2） ML模型训练管道经过集成测试 3） ML模型在投入使用前经过验证 4） ML模型老化测试（在生产中） 5） 测试ML模型的相关性和正确性 6） 测试非功能性需求（安全性、公平性、可解释性）	1） 单元测试 2） 端到端管道的集成测试
自动化	1） 数据转换 2） 特征创建和操作	1） 数据工程管道 2） ML模型训练管道 3） 超参数/参数选择	1） 使用CI/CD的ML模型部署 2） 应用程序构建
再现性	1） 备份数据 2） 数据版本控制 3） 提取元数据 4） 功能工程的版本控制	1） 开发和生产之间的超参数调整是相同的 2） 功能的顺序相同 3） 集成学习：ML模型的组合是相同的 4） 模型伪代码已记录在案	1） dev和prod中所有依赖项的版本都是相同的 2） 开发和生产环境的技术堆栈相同 3） 通过提供容器映像或虚拟机再现结果
部署	1） 功能存储用于开发和生产环境	1） ML堆栈的容器化 2） REST API 3） 内部部署、云或边缘	1） 内部部署、云或边缘
监视	1） 数据分布变化（培训与服务数据） 2） 训练与服务功能	1） ML模型衰变 2） 数值稳定性 3） ML模型的计算性能	1） 服务数据应用程序的预测质量

除了MLOps原则外，遵循一套最佳实践应有助于减少ML项目的“技术债务”：

MLOps最佳实践	Data	ML Model	Code
文档	1） 数据源 2） 决策，如何/在哪里获取数据 3） 标签方法	1） 型号选择标准 2） 实验设计 3） 模型伪代码	1） 部署过程 2） 如何在本地运行
项目结构	1） 原始数据和已处理数据的数据文件夹 2） 数据工程管道的文件夹 3） 数据工程方法的测试文件夹	1） 包含训练模型的文件夹 2） 笔记本的文件夹 3） 用于功能工程的文件夹 4） ML模型工程文件夹	1） bash/shell脚本的文件夹 2） 用于测试的文件夹 3） 部署文件的文件夹（例如Docker文件）