标题：Machine Learning Operations (MLOps): Overview, Definition, and Architecture

作者：Dominik Kreuzberger, Niklas Kühl, Sebastian Hirschl

来源：https://arxiv.org/abs/2205.02302

时间：2022年5月

摘要

所有工业级的机器学习 (ML) 项目的最终目标是开发 ML 产品并快速将其投入生产。然而，机器学习产品的自动化和实施极具挑战性，因此许多机器学习的努力未能达到他们预期的回报。MLOps(Machine Learning Operations) 的范式解决了这个问题。 MLOps包括几个方面，例如最佳实践、概念集和开发文化。然而，MLOps 仍然是一个模糊的术语，它对研究人员和专业人士的影响是模棱两可的。为了弥补这一差距，我们进行了混合方法研究，包括文献回顾、工具回顾和专家访谈。作为这些调查的结果，我们对必要的原则、组件和角色以及相关的架构和工作流程进行了汇总概述。此外，我们提供了 MLOps 的定义，并强调了该领域的开放挑战。最后，这项工作为希望使用一组指定的技术自动化和运维其机器学习产品的 ML 研究人员和从业者提供了指导。

一、简介

机器学习 (ML) 已成为利用数据潜力的重要技术，并使企业更具创新性、高效和可持续发展。然而，许多投入生产的机器学习应用在现实环境中的成功并未达到预期。大量 ML 项目失败了——许多 ML 概念从未进展到生产。从研究的角度来看，这并不令人意外，因为 ML 社区广泛关注 ML 模型的构建，而不是构建可量产的机器学习产品以及复杂的机器学习系统组件和基础设施，包括在现实环境中能使ML系统自动化以及运维ML 系统。例如，在许多工业应用中，数据科学家仍然在很大程度上手动管理 ML 工作流，从而导致在各个 ML 解决方案的操作过程中出现许多问题。

为了解决这些问题，这项工作的目标是研究如何将手动 ML 流程自动化以及可运维，以便将更多的 ML 概念证明投入生产。在这项工作中，我们探索了新兴的 ML 工程实践“Machine Learning Operations”——简称 MLOps（机器学习运维）——精确地解决了设计和维护高效 ML 的问题。我们从整体的角度来获得对所涉及的组件、原则、角色和架构的共识。虽然现有研究对 MLOps 的各个特定方面有所讲述，但仍然缺少对 ML 系统设计的整体概念化、概括和澄清。对“MLOps”一词的不同观点和概念可能会导致误解和沟通不畅，进而导致整个 ML 系统的整体设置出现错误。因此，我们提出研究问题：

RQ：什么是 MLOps？

为了回答这个问题，我们进行了一项混合方法研究，用于：

(a) 确定 MLOps 的重要原则，

(b) 划分功能核心组件，

(c) 强调成功实施 MLOps 所必需的角色，

(d) 推导出一个ML 系统设计的通用架构。

结合起来，这些见解导致了 MLOps 的定义，这有助于对该术语和相关概念的共同理解。

通过这样做，我们希望为专业人士和研究人员提供明确的指导方针，对学术和实践讨论产生积极影响，并承担明确的责任。这些见解可以通过减少系统设计中的错误，并最终在现实世界环境中实现更可靠的预测，从而有助于将更多的概念证明投入生产。

这篇文章的其余部分结构如下：我们将首先详细阐述该领域的必要基础和相关工作；接下来，我们将概述所使用的方法，包括文献回顾、工具回顾和访谈研究；然后，我们展示了从该方法的应用中得出的见解，并通过提供统一的定义来概念化这些见解；我们以简短的总结、局限性和展望来结束本文。

二、DevOps的基础

过去，软件工程领域出现了不同的软件开发过程模型和开发方法。突出的例子包括瀑布模型和敏捷宣言。这些方法具有相似的目标，即交付可量产的软件产品。 2008/2009 年出现了一个名为“DevOps”的概念，旨在减少软件开发中的问题。DevOps 不仅仅是一种纯粹的方法，而是代表了解决从事软件开发的组织中的社会和技术问题的范式。它的目标是消除开发和运维之间的差距，并强调协作、沟通和知识共享。它通过持续集成、持续交付和持续部署 (CI/CD) 确保自动化，从而实现快速、频繁和可靠地发布。此外，它旨在确保持续测试、质量保证、持续监控、日志记录和反馈循环。

由于 DevOps 的商业化，许多 DevOps 工具不断涌现，可分为六类：协作和知识共享（例如 Slack、Trello、GitLab wiki）、源代码管理（例如 GitHub、GitLab )、构建过程（例如 Maven）、持续集成（例如 Jenkins、GitLab CI）、部署自动化（例如 Kubernetes、Docker）、监控和日志记录（例如 Prometheus、Logstash）。云环境越来越多地配备了专为云使用而设计的即用型 DevOps 工具，从而促进了价值的高效生成 [38]。随着向DevOps这种新颖范式的转变，开发人员需要关心他们开发的内容，因为他们也需要操作它。正如实证结果所表明的那样，DevOps 确保了更好的软件质量。业内人士以及学术界人士通过使用 DevOps获得了丰富的软件工程方面的经验。这种经验现在被用于ML自动化和运维。

三、方法论

为了从学术知识库中获得见解，同时也利用该领域从业者的专业知识，我们采用混合方法方法，如图 1 所示。作为第一步，我们进行结构化文献综述以获得相关研究的概述。此外，我们回顾了 MLOps 领域的相关工具支持，以更好地了解所涉及的技术组件。最后，我们与来自不同领域的专家进行半结构式访谈（半结构式访谈：事先有一定的题目和假设，但实际问题没有具体化。其优缺点介于结构式访谈和非结构式访谈之间）。在此基础上，我们将“MLOps”一词概念化，并在下一节（“结果”）中通过综合文献和访谈来详细说明我们的发现。

图1 研究方法综述

3.1 文献回顾

为确保我们的结果基于科学知识，我们根据Webster 和Watson，以及Kitchenham 等人的方法进行了系统的文献回顾。我们查询 Google Scholar、Web of Science、Science Direct、Scopus 和信息系统电子图书馆协会的科学数据库。值得一提的是，将 DevOps 用于 ML，MLOps 以及与 ML 相结合的持续实践是学术文献中一个相对较新的领域。因此，在本研究进行时，只有少数同行评议的研究可用。然而，为了获得这方面的经验，搜索也包括了非同行评审的文献。搜索于 2021 年 5 月进行，共检索到 1,864 篇文章。其中，我们详细筛选了 194 篇论文。从该组中，根据我们的纳入和排除标准选择了 27 篇文章（例如，详细描述了 MLOps 或 DevOps 和 CI/CD 与 ML 相结合的术语，文章是用英文写的等）。所有 27 篇文章均经过同行评审。

3.2 工具回顾

经过 27 篇文章和 8 次采访，确定了各种开源工具、框架和商业云 ML 服务。审查了这些工具、框架和 ML 服务，以了解它们所包含的技术组件。已识别工具的概述在下表中进行了描述。

技术名称描述

开源示例TensorFlow 扩展TensorFlow Extended (TFX) 是一个配置框架，为端到端 ML 流程的每个任务提供库。示例包括数据验证、数据分布检查、模型训练和模型服务。

AirflowAirflow 是一个任务和工作流编排工具，也可以用于 ML 工作流编排。它还用于编排数据工程作业。任务根据有向无环图 (DAG) 执行。

KubeflowKubeflow 是一个基于 Kubernetes 的端到端机器学习平台。每个 Kubeflow 组件都包装在一个容器中，并由 Kubernetes 进行编排。此外，ML 工作流的每个任务都由一个容器处理。

机器学习流MLflow 是一个允许端到端管理 ML 生命周期的 ML 平台。它提供了高级实验跟踪功能、模型注册表和模型服务组件。

商业示例Databricks 管理的 MLflowDatabricks 平台提供基于其他云提供商基础设施的托管服务，例如托管 MLflow。

亚马逊代码管道Amazon CodePipeline 是一种 CI/CD 自动化工具，用于促进构建、测试和交付步骤。它还允许人们安排和管理 ML 管道的不同阶段。

亚马逊 SageMaker借助 SageMaker，Amazon AWS 提供了一个端到端的 ML 平台。它提供开箱即用的功能存储、使用 SageMaker Pipelines 进行编排以及使用 SageMaker 端点提供模型服务。

Azure DevOps 管道Azure DevOps Pipelines 是一种 CI/CD 自动化工具，用于促进构建、测试和交付步骤。它还允许人们安排和管理 ML 管道的不同阶段。

Azure 机器学习Microsoft Azure 结合 Azure DevOps Pipelines 和 Azure ML 提供了一个端到端的 ML 平台。

GCP - 顶点人工智能GCP 与 Vertex AI 一起提供了一个完全托管的端到端平台。此外，他们还提供了一个托管 Kubernetes 集群，其中包含 Kubeflow 即服务。

IBM Cloud Pak for Data(IBM Watson

Studio)

IBM Cloud Pak for Data 将一系列软件组合在一个包中，提供数据和 ML 功能。

3.3 访谈研究

为了从实践中获得洞察力来回答研究问题，我们进行了半结构式的专家访谈。我们应用了一种理论抽样方法，这使我们能够选择有经验的采访伙伴来获得高质量的数据。这些数据可以通过有限数量的访谈提供有意义的见解。为了获得足够的样本组和可靠的见解，我们使用 LinkedIn（一个面向专业人士的社交网络）来识别在全球范围内具有深厚 MLOps 知识的经验丰富的 ML 专业人士。为了从不同的角度获得见解，我们选择了来自不同组织和行业、不同国家和民族以及不同性别的面试伙伴。进行访谈，直到在数据分析中没有出现新的类别和概念。

四、结果

我们应用了可描述的方法并将由此得到的见解构建为：重要原则的介绍、组件的实例化、必要角色的描述，以及对这些方面组合产生的架构和工作流程的建议。最后，我们推导了该术语的概念化并提供了 MLOps 的定义。

4.1 原则

原则被视为普遍或基本的真理、价值或行为指南。在 MLOps 的背景下，原则是如何在 MLOps 中实现事物的指南，并且与专业领域的“最佳实践”一词密切相关。根据概述的方法，我们确定了实现 MLOps 所需的九项原则。图 2 提供了这些原则的说明，并将它们链接到与其相关联的组件。

图 2. 技术组件中原则的实施

原则1：CI/CD 自动化

CI/CD 自动化地提供持续集成、持续交付和持续部署。它执行构建、测试、交付和部署步骤。它向开发人员提供有关某些步骤的成功或失败的快速反馈，从而提高整体生产力。

原则2：工作流程编排

工作流编排根据有向无环图 (DAG) 协调 ML 工作流管道的任务。 DAG 通过考虑关系和依赖关系来定义任务执行顺序。

原则3：可复现性

可复现性是重现 ML 实验并获得完全相同结果的能力。

原则4：版本控制

版本控制确保数据、模型和代码的版本控制不仅可以实现可复现性，还可以实现可追溯性（出于合规性和审计原因）。

原则5：协作

协作确保了在数据、模型和代码上进行协作的可能性。除了技术方面，该原则强调协作和交流的工作文化，旨在减少不同角色之间的领域孤岛。

原则6：持续 ML 训练和评估

持续训练意味着基于新的特征数据定期重新训练 ML 模型。通过监控组件、反馈循环和自动化 ML 工作流的支持，可以实现持续训练。持续训练的过程总是会伴随着评估的运行，以评估模型质量的变化。

原则7：ML 元数据跟踪/记录

为每个编排的 ML 工作流任务跟踪和记录元数据。每次训练迭代都需要元数据跟踪和记录（例如训练日期和时间、持续时间等），包括模型特定的元数据——例如，使用的参数和产生的性能指标、模型沿袭：用于的数据和代码确保实验运行的完全可追溯性。

原则8：持续监测

持续监控意味着对数据、模型、代码、基础设施资源和模型服务性能（例如预测准确性）进行定期评估，以检测影响产品质量的潜在错误或变化。

原则9：反馈回路

需要多个反馈循环来将来自质量评估步骤的见解整合到开发或工程过程中（例如，从实验模型工程阶段到前一个特征工程阶段的反馈循环）。从监控组件（例如，观察模型服务性能）到调度程序需要另一个反馈循环，以启用再训练。

4.2 技术组件

在确定需要纳入 MLOps 的原则之后，我们现在详细说明精确的组件并在 ML 系统设计中实现它们。在下文中，以通用方式列出并描述了这些组件及其基本功能。

组件1：CI/CD 组件（原则1、6、9）

CI/CD 组件确保持续集成、持续交付和持续部署。它负责构建、测试、交付和部署步骤。它向开发人员提供有关某些步骤的成功或失败的快速反馈，从而提高整体生产力。例如 GitHub Actions。

组件2：源代码仓库（原则4、5）

源代码仓库确保代码存储和版本控制。它允许多个开发人员提交以及合并代码，示例包括 Bitbucket、GitLab、GitHub和 Gitea。

组件3：工作流程编排组件（原则2、3、6）

工作流编排组件通过有向无环图 (DAG) 提供 ML 工作流的任务编排。这些图表示工作流的单个步骤的执行顺序和工件使用情况，示例包括 Apache Airflow、 Kubeflow Pipelines、Luigi、AWS SageMaker Pipelines和 Azure Pipelines。

组件4：特征平台系统（原则3、4）

特征平台（feature store）系统确保常用特征的集中存储。它配置了两个数据库：一个数据库作为离线特征存储，为实验提供具有正常延迟的特征，一个数据库作为在线存储，为生产中的预测提供低延迟的特征。示例包括 Google Feast、Amazon AWS Feature Store、Tecton.ai 和 Hopswork.ai。这是用于训练 ML 模型的大部分数据的来源。此外，数据也可以直接来自任何类型的数据存储。

组件5：模型训练基础设施 (原则6)

模型训练基础设施提供基础计算资源，例如 CPU、RAM 和 GPU。提供的基础设施可以是分布式的或非分布式的。一般来说，建议使用可扩展的分布式基础设施。示例包括本地机器（不可扩展）或云计算，以及非分布式或分布式计算（多个工作节点）。支持计算的框架是 Kubernetes和 Red Hat OpenShift。

组件6：模型注册表（原则3、4）

模型注册表集中存储经过训练的 ML 模型及其元数据。它有两个主要功能：存储 ML 工件和存储 ML 元数据（参见 组件7）。高级存储示例包括 MLflow、AWS SageMaker 模型注册表、Microsoft Azure ML 模型注册表和Neptune.ai。简单的存储示例包括 Microsoft Azure Storage、Google Cloud Storage 和 Amazon AWS S3。

组件7：ML 元数据存储（P4、P7）

ML 元数据存储允许跟踪各种元数据，例如，针对每个编排的 ML 工作流任务。可以在模型注册表中配置另一个元数据存储，用于跟踪和记录每个训练工作的元数据（例如，训练日期和时间、持续时间等），包括模型特定的元数据——例如，使用的参数和生成的性能指标，模型沿袭：使用的数据和代码。示例包括具有内置元数据存储的编排器，可跟踪实验流程的每个步骤，例如 Kubeflow Pipelines、AWS SageMaker Pipelines、Azure ML 和 IBM Watson Studio。MLflow 结合模型注册表提供了高级元数据存储。

组件8：模型服务组件 (原则1)

模型服务组件可以针对不同的目的进行配置。例如用于实时预测的在线推理或使用大量输入数据进行预测的批量推理。作为基础设施层，推荐使用可扩展的分布式模型服务基础设施。模型服务组件配置的一个示例是使用 Kubernetes 和 Docker 技术来容器化 ML 模型，并利用 Python Web 应用程序框架（如 Flask）和用于服务的 API。其他 Kubernetes支持的框架是 Kubeflow的 KServing、TensorFlow Serving 和 Seldion.io 服务。推理也可以使用 Apache Spark 来实现，用于批量预测。云服务的示例包括 Microsoft Azure ML REST API、AWS SageMaker Endpoints、IBM Watson Studio和 Google Vertex AI 预测服务。

组件9：监控组件（原则8、9）

监控组件负责持续监控模型服务性能（例如预测准确性）。此外，还需要监控 ML 基础设施、CI/CD 和编制。示例包括带有 Grafana的 Prometheus、ELK 堆栈（Elasticsearch、Logstash 和 Kibana）和简单的TensorBoard。具有内置监控功能的示例包括 Kubeflow、MLflow和 AWS SageMaker模型监控器或云观察。

4.3 角色

在描述了组件的原理及其产生的实例化之后，我们确定了必要的角色，以便接下来实现 MLOps。 MLOps 是一个跨学科的小组过程，不同角色的相互作用对于在生产中设计、管理、自动化以及运维ML 系统至关重要。下面简要介绍每个角色及其目的和相关任务：

角色1：业务利益相关者（类似角色：产品负责人、项目经理）

业务利益相关者定义了要使用 ML 实现的业务目标，并负责业务层面的沟通，例如展示 ML 产品产生的投资回报 (ROI)。

角色2：解决方案架构师（类似角色：IT 架构师）

解决方案架构师设计架构，并经过全面评估定义要使用的技术。

角色3：数据科学家（类似角色：ML 专家、ML 开发人员）

数据科学家将业务问题转换为 ML 问题并负责模型工程，包括选择性能最佳的算法和超参数。

角色4：数据工程师（类似角色：DataOps工程师）

数据工程师建立并管理数据及特征工程管道。此外，此角色可确保将正确的数据存储到特征凭条系统的数据库中。

角色5：软件工程师

软件工程师应用软件设计模式、广泛接受的编码指南和最佳实践将原始 ML 问题转化为设计良好的产品。

角色6：开发运维工程师

DevOps工程师弥补了开发和运维之间的差距，并确保适当的 CI/CD 自动化、ML 工作流编排、模型部署到生产和监控。

角色7：ML 工程师/MLOps 工程师

ML 工程师或 MLOps 工程师结合了多个角色的各个方面，因此具有具备跨领域的知识。该角色融合了数据科学家、数据工程师、软件工程师、DevOps工程师和后端工程师的技能（参见图 3）。这个跨领域的角色建立和运营 ML 基础设施，管理自动化的ML工作流和模型部署到生产，并监控模型和 ML 基础设施。

图 3. MLOps 范式的角色及其交叉点

五、架构和工作流程

在确定的原则、组件和角色的基础上，我们推导出一个通用的 MLOps 端到端架构，为 ML 研究人员和从业者提供适当的指导，如图 4 所示。此外，我们还描述了工作流，即不同任务在不同阶段执行的顺序。因此，机器学习研究人员和从业者可以选择最适合他们需求的技术和框架。

如图 4 所示，我们展示了从 MLOps 项目启动到模型服务的端到端流程。它包括：

(A) MLOps项目启动步骤；

(B) 特征工程流水线，包括特征平台的数据摄取；

(C) 实验；

(D) 到模型服务的自动化的 ML 工作流。

(A) MLOps项目启动

(1) 业务利益相关者(角色1)分析业务并确定可以使用 ML 解决的潜在业务问题；

(2) 解决方案架构师(角色2)定义整个 ML 系统的架构设计，并在全面评估后决定要使用的技术；

(3) 数据科学家(角色3)从业务目标推导出 ML 问题，例如是否应该使用回归或分类模型；

(4) 数据工程师(角色4)和数据科学家(角色3)齐心协力，梳理解决这个问题需要哪些数据； (5) 明确答案后，数据工程师(角色4)和数据科学家(角色3)将协作定位原始数据源，以进行初始数据分析。他们检查数据的分布和质量，并执行验证检查。此外，他们确保来自数据源的数据被打上标签，这意味着目标属性是已知的，因为这是监督机器学习的强制性要求。在此示例中，数据源已经具有可用的标记数据，因为标记步骤在上游过程中被覆盖。

(B1) 特征工程流水线的要求

特征是模型训练所需的相关属性。在初步了解原始数据和初步数据分析后，定义特征工程流水线的基本要求如下：

(6) 数据工程师(角色4)定义数据转换规则（规范化、聚合）和清洗规则，将数据转换为可用的格式；

(7) 数据科学家(角色3)和数据工程师(角色4)共同定义特征工程规则，例如基于其他特征计算新的和更高级的特征。这些最初定义的规则必须由数据科学家(角色3)根据来自实验模型工程阶段的反馈或来自观察模型性能的监控组件的反馈进行迭代调整。

(B2) 特征工程流水线

数据工程师(角色4)和软件工程师(角色5)以最初定义的特征工程流水线需求为起点，构建特征工程流水线的原型。最初定义的要求和规则根据来自实验模型工程阶段或来自观察模型在生产中的性能的监控组件的迭代反馈进行更新。作为一项基本要求，数据工程师(角色4)定义了 CI/CD (组件1)和编排组件(组件3)所需的代码，以确保特征工程流水线的任务编排。此角色还定义了底层基础架构资源配置。

(8) 首先，特征工程流水线连接到原始数据，例如可以是流数据、静态批处理数据或来自任何云存储的数据；

(9) 数据将从数据源中提取；

(10) 数据预处理从数据转换和清洗任务开始。在需求收集阶段定义的转换规则工件用作此任务的输入，此任务的主要目的是将数据转换为可用格式。这些转换规则会根据反馈不断改进；

图 4. 具有功能组件和角色的端到端 MLOps 架构和工作流

(11) 特征工程任务基于其他特征计算新的和更高级的特征。预定义的特征工程规则用作此任务的输入。这些特征工程规则会根据反馈不断改进；

(12) 最后，将批量或流式数据加载到特征平台系统(组件4)中。目标是离线或在线数据库（或任何类型的数据存储）。

（C）实验

实验阶段的大多数任务由数据科学家(角色3)领导。数据科学家由软件工程师(角色5)提供支持。

(13) 数据科学家(角色3)通过特征平台系统(组件4)进行数据分析。或者，数据科学家也可以通过原始数据进行初步分析。如果需要进行任何数据调整，数据科学家会将所需的更改报告回数据工程区（反馈循环）；

(14) 然后，需要对来自特征平台系统的数据进行准备和验证。此任务还包括创建训练和测试数据集；

(15) 数据科学家(角色3)估计性能最佳的算法和超参数，然后用训练数据(组件5)触发模型训练。软件工程师(角色5)支持数据科学家(角色3)创建精心设计的模型训练代码；

(16) 在多轮模型训练中，对不同的模型参数进行交叉测试和验证。一旦性能指标表明结果良好，迭代训练就会停止。性能最佳的模型参数是通过参数调整来确定的。然后重复迭代模型训练任务和模型验证任务；这些任务一起可以称为“模型工程”。模型工程旨在确定模型的最佳性能算法和超参数；

(17) 数据科学家(角色3)导出模型并将代码提交到仓库。

作为一项基本要求，DevOps工程师或 ML工程师定义自动化 ML工作流的代码并将其提交到仓库。一旦数据科学家提交新的 ML 模型，或者 DevOps 工程师和 ML工程师将新的 ML 工作流代码提交到仓库，CI/CD 组件就会检测到更新的代码并自动触发 CI/CD流程执行构建、测试和交付步骤。构建步骤包含 ML模型和 ML工作流的任务的工件。测试步骤验证 ML 模型和 ML 工作流代码。交付步骤将版本化的工件（例如图像）推送到工件存储（例如，图像注册表）。

（D）自动化 ML工作流

DevOps工程师和 ML工程师负责管理自动化的 ML 工作流。他们还以硬件资源和支持计算框架（如 Kubernetes）的形式管理底层模型训练基础设施。工作流编排组件编排自动化 ML 工作流的任务。对于每个任务，从工件存储（例如图像注册表）中提取所需的工件（例如图像）。每个任务都可以通过一个隔离的环境（例如容器）执行。最后，工作流编排组件以日志、完成时间等形式为每个任务收集元数据。

一旦触发了自动化 ML 工作流，就会自动管理以下每个任务：

(18) 从特征平台系统中自动提取版本化的特征（数据提取）。根据用例，从离线或在线数据库（或任何类型的数据存储）中提取特征；

(19) 自动化数据准备和验证；此外，训练集和测试集的拆分是被自动定义；

(20) 对新的未遇见过的数据进行自动模型训练。算法和超参数已经根据前一个实验阶段的设置进行了预定义。这样，模型就被重新训练和改进了；

(21) 如果需要，执行自动化的模型评估和超参数的迭代调整。一旦性能指标表明结果良好，自动迭代训练就会停止。自动化模型训练任务和自动化模型验证任务可以反复重复，直到取得良好的结果；

(22) 然后，训练后的模型被导出并推送到模型注册表，在那里它被存储为代码或与其相关的配置和环境文件一起容器化。

对于所有训练任务迭代，ML元数据存储记录元数据，例如用于训练模型的参数和生成的性能指标。这还包括跟踪和记录训练任务ID、训练日期和时间、持续时间以及工件来源。此外，为每个新注册的模型跟踪模型特定元数据（也称为“模型沿袭”），该元数据结合了数据和代码的沿袭，这包括用于训练模型的特征数据和模型训练代码的来源和版本。此外，还会记录模型版本和状态（例如暂存或生产就绪）。

一旦一个表现良好的模型从暂存状态切换到生产状态，它就会自动移交给 DevOps工程师或 ML工程师进行模型部署。从那里，CI/CD 组件触发持续部署流程。生产就绪的 ML模型和模型服务代码被拉取（最初由软件工程师准备）。持续部署流程执行 ML模型和服务代码的构建和测试步骤，并将模型部署到生产服务；

(23) 模型服务组件对来自特征平台系统的新的、没遇见过的数据进行预测。该组件可由软件工程师设计为用于实时预测的在线推理或用于大量输入数据的预测的批量推理。对于实时预测，特征必须来自在线数据库（低延迟），而对于批量预测，特征可以来自离线数据库（正常延迟）。模型服务应用程序通常在容器中配置，预测请求通过 REST API 处理。作为一项基本要求，ML工程师管理模型服务计算基础设施；

(26) 监控组件 (组件9) 持续实时观察模型服务性能和基础设施。一旦达到某个阈值，例如检测到预测精度较低，信息就会通过反馈回路转发。反馈回路连接到监控组件并确保快速和直接的反馈，从而实现更稳健和更好的预测。它支持持续训练、重新训练和改进。在反馈回路的支持下，信息从模型监控组件传递到多个上游接收点，例如实验阶段、数据工程区和调度器（触发器）。

数据科学家将反馈到实验阶段，以进一步改进模型。对数据工程区的反馈允许调整为特征平台系统准备的特征。此外，作为反馈机制，模型漂移的检测可以实现持续训练（模型漂移指的是旧的模型随着时间的改变,在最新特征下模型的效果会越来越差）。例如，一旦模型监控组件检测到数据中的模型漂移，信息就会被转发到调度程序，然后调度程序触发自动化ML工作流进行重训练（持续训练）。可以使用分布比较的方法检测已部署的模型的充分变化，进而识别漂移现象是否发生。重新训练不仅会在达到统计阈值时自动触发；它也可以在有新的特征数据可用时触发，也可以被定期安排。

六、概念化

很明显，MLOps是机器学习、软件工程、DevOps 和数据工程的交叉领域（参见图 5）。

图 5. MLOps 范式的学科交叉

我们将 MLOps 定义如下：

MLOps（机器学习运维）是一种范式，包括：最佳实践，概念集，端到端概念化、实施、监控、部署等方面的开发文化，以及机器学习产品的可扩展性。最重要的是，它是一种利用3个学科的工程实践：机器学习、软件工程（尤其是 DevOps）和数据工程。MLOps旨在通过弥合开发(Dev)和运维(Ops)之间的差距来构建机器学习系统。从本质上讲，MLOps旨在通过利用以下原则促进机器学习产品的生产：CI/CD 自动化、工作流编排、可重复性；数据、模型和代码的版本控制；合作；持续的机器学习训练和评估；ML元数据跟踪和记录；持续监控；反馈回路。

七、开放挑战

MLOps的几个挑战被分成组织上的、机器学习系统的和运维的挑战。

（1）组织挑战

数据科学实践的思维方式和文化是组织机构环境中的典型挑战。正如我们从文献和采访中获得的见解所表明的那样，要成功开发和运维ML产品，就需要从模型驱动的机器学习转向以产品为导向的行为准则。最近，以数据为中心的 AI 的趋势通过“更多地关注在 ML 模型构建之前的数据”在解决这一方面的问题，尤其是与这些活动相关的角色在设计 ML 产品时应该具有以产品为中心的视角。MLOps需要大量的技能和个人角色，正如我们所指出的那样，这些角色缺乏高技能的专家——尤其是在架构师、数据工程师、ML工程师和 DevOps工程师方面。这与未来专业人员的必要教育有关——因为 MLOps 通常不是数据科学教育的一部分。也就是说，机器学习工程师不仅应该学习模型创建，还必须了解构建功能性 ML 产品所需的技术和组件。单靠数据科学家无法实现 MLOps 的目标。需要一个多学科的团队，因此 MLOps 需要一个小组团队才能完成。这通常会受到阻碍，因为团队在孤岛中工作而不是在合作中工作。此外，不同的知识水平和专业术语使交流变得困难。为了给更富有成效的设置奠定基础，各自的决策者需要确信提高 MLOps 成熟度和以产品为中心的思维方式将产生明显的业务改进。

（2）机器学习系统挑战

MLOps系统的一个主要挑战是针对波动的需求进行设计，特别是与 ML 训练过程相关的。这源于潜在的大量和变化的数据，这使得精确估计必要的基础设施资源（CPU、RAM 和 GPU）变得困难，并且在基础设施的可扩展性方面需要高度的灵活性。

（3）运营挑战

在生产环境中，由于软硬件组件的不同堆栈及其相互作用，手动运维ML具有挑战性。因此，需要强大的自动化能力。此外，源源不断的新数据流会高度依赖重新训练能力。这是一项重复性任务，同样需要高度自动化。这些重复性任务产生大量工件，需要强大的治理以及数据、模型和代码的版本控制，以确保稳健性和可重复性。最后，解决潜在的支持请求（例如通过查找根本原因）具有挑战性，因为涉及到许多部分和组件，故障可能是 ML 基础设施和软件的组合。

八、结论

随着数据可用性和分析能力的提升，以及不断创新的压力，比以往更多的机器学习产品正在被源源不断的开发出来。但是，这些概念证明中只有一小部分会进入部署和生产阶段。此外，学术领域专注于机器学习模型的构建和基准测试，但在现实世界场景中操作复杂的机器学习系统方面却很少。在现实世界中，我们观察到数据科学家仍在很大程度上手动管理 ML工作流。机器学习运维MLOps的范式解决了这些挑战。在这项工作中，我们更加了解了 MLOps。通过对现有文献和工具进行混合方法研究，并采访该领域的专家，我们发现了 MLOps的4主要方面：原理、组件、角色和架构。基于此，我们给出了MLOps的定义，希望可以帮助大家在未来搭建成功的ML项目。