MLOps 概述，定义和架构

摘要

 所有工业机器学习（ML）项目的最终目标是开发ML产品并迅速投入生产。然而，自动化和操作化是一项极具挑战性的工作，ML产品和许多ML工作者努力也未能实现其期望目标。机器学习操作的范例（MLOps）解决了这个问题。MLOps包括几个方面，例如最佳实践、概念集和开发文化。然而，MLOps仍然是一个模糊的术语，其结果导致研究人员和专业人士的意见不明确。为了解决这一差距，我们进行了混合方法研究，包括文献综述，工具审查和专家访谈。基于这些调查中，我们提供了必要的原则、组件和角色，以及相关的架构和工作流。此外，我们提供了一个MLOps的定义并强调该领域的开放性挑战。最后，这项工作为ML研究人员和从业人员提供了指导，他们希望通过设计的一套技术集能够自动的操作他们的ML产品。

KEYWORDS
CI/CD, DevOps, Machine Learning, MLOps, Operations,Workflow Orchestration

1 引言

机器学习（ML）已成为一项重要的技术利用数据的潜力，让商业有更多创新[1]，高效[13]和可持续[22]。但是许多生产性的ML应用程序在现实环境中的成功没有达到预期[21]。大量的带有许多机器学习的概念证明的ML项目失败了，并从来没有发布到生产[30]。从研究的角度来看，这并不是令人惊讶的是，机器学习社区广泛关注建立ML模型，但不是构建（a）生产ML产品和（b）提供必要的协调结果，通常是复杂的ML系统组件和基础架构，包括自动化和操作ML系统所需的角色在现实世界中[35]的设定。例如，在许多工业中应用程序，很大程度上，数据科学家仍然手动管理ML工作流程，这导致了在ML解决方案的操作层面出现了很多问题。

为了解决这些问题，这项工作的目标是研究如何使手动的ML流程可以自动化和操作化，以便更多的ML概念证明可以投入生产。在这个工作，我们探索新兴的ML工程实践“机器学习操作”-MLOPs，简言之，精确的强调了设计和维护生产性ML的问题整体观点，以获得共同的理解，这涉及组件，原则，角色和体系结构。虽然现有的研究揭示了MLOps，一个整体的概念化，泛化的，并能对ML系统设计进行清晰的说明仍然是缺失的。不同“MLOP”一词的观点和概念可能导致误解和沟通不畅反过来又会导致整个ML系统整体建设中的错误。因此，我们提出了这些研究问题：

RQ：什么是MLOP？
为了回答这个问题，我们进行了混合方法研究努力（a）确定MLOPs的重要原则，（b）开拓
功能核心组件，（c）突出强调能够成功实现MLOPs的必要的角色，并且（d）推导出一般ML系统设计的通用架构。综合起来，这些见解引导出MLOPs的定义，这有助于对该术语和相关概念的共同理解。
通过这样做，我们希望在学术和实践讨论时通过对专家和负有确切责任的研究人员提供明确的指导方针产生积极的影响。这些见解可以帮助更多的概念证明通过减少系统中的错误将其投入生产设计，最后，在现实世界的环境中实现更强大的预测。

接下来，我们将概述所使用的方法，包括文献回顾、工具回顾和访谈研究。 然后，我们展示了从该方法的应用中得出的见解，并通过提供统一的定义来概念化这些见解。 我们以简短的总结、局限性和展望来结束本文。

2 DevOps的基础

过去，不同的软件过程模型和开发软件工程领域出现了方法论。突出的例子包括瀑布[37]和敏捷方法[5]. 这些方法有类似的目标，即交付生产就绪的软件产品。一个叫做“DevOps”的概念出现在2008/2009年，旨在减少软件开发过程中的问题[9,31]。DevOps不仅仅是一个纯粹的方法论，而是代表一种解决社会问题和技术问题的范式在从事软件的组织中的开发过程中。它的目标是消除开发和运营两者之间的差距，强调合作，沟通和知识共享。它确保自动化持续整合，持续交付和持续部署（CI/CD），从而允许快速、频繁和可靠发布。此外，它旨在确保连续测试，质量保证，持续监控，记录和反馈闭环。由于DEVOPS的商业化，许多DEVOPS工具正在出现，可以分为六类[23,28]：协作和知识共享（例如，Slack，Trello，GitLab wiki），源代码管理（例如GitHub，GitLab），构建过程（例如Maven），连续集成（例如Jenkins，GitLab CI），自动化部署（例如Kubernetes，Docker），监控和日志记录（例如，Prometheus，Logstash）。云环境越来越多地配备现成的DevOps专为云使用而设计的工具，有助于提高效率价值的产生[38]。随着这种向DevOps的新转变，开发人员需要关心他们开发的内容，因为他们也需要操作它。正如实证结果所示，DevOps确保更好的软件质量[34]。行业人员，或者研究学者，通过使用DevOps进行工程化在软件方面获得了丰富的经验。这种经验现在已经习惯性的用于自动化并运作ML。

3 方法论

为了从学术知识库中获得见解，同时也利用该领域从业者的专业知识，我们采用了混合方法，如图1所示。作为第一个步骤，我们进行结构化文献综述[20,43]以获得相关研究概述。此外，我们审查相关在MLOP领域使用工具支撑可以更好地了解涉及的技术组件。最后，我们与来自不同领域的专家进行半结构化访谈[33,39]。在此基础上，我们将术语“MLOps”概念化，并在下一章（“结果”）中通过综合文献和访谈来详细说明我们的发现。

 3.1文献综述
为了确保我们的结果基于科学知识，我们根据Webster和Watson[43]以及Kitchenham等[20]人的方法进行系统的文献综述。经过一个初始探索性搜索，我们将搜索查询定义如下：
（（（“DevOps”或“CICD”或“持续集成”或“持续交付”或“持续部署”）和“机器学习”）或“MLOP”或“CD4ML”）。我们查询Google Scholar，Web of Science，Science的科学数据库Direct，Scopus和信息系统协会文库。应该提到的是，将DevOps用于ML，MLOPs和与ML结合的持续实践是学术领域相对较新的一个概念。因此，在本研究时，只有少数同行评审研究可用。然而，为了获得这方面的经验，搜索包括非同行评审的文献也是如此。搜索是在2021年5月，共检索到1864篇文章。其中，我们详细筛选了194篇论文。从该组中，有27篇文章根据我们的纳入和排除标准（例如，术语
MLOps或DevOps和CI/CD与ML结合使用详细描述，文章用英文等书写）。全部27篇这些文章经过同行评审。

3.2工具审查
经过浏览这27篇文章，并进行8次访谈后，开源工具，框架和商业云上的ML服务被确定下来。对这些工具，框架和ML服务的审查，是为了解它们的技术组成。描述了已确定工具的概述在附录的表1中。

3.3 访谈研究
为了从实践中得到见解来回答研究问题，我们根据迈尔斯和纽曼[33]的说法进行了半结构化的专家访谈。研究设计这些专家访谈的一个主要方面正是选择合适的样本量[8]。我们应用理论抽样方法[12]，这使我们能够选择经验丰富的面试合作伙伴以获取高质量的数据。这样的数据可以提供有限数量的有意义的见解采访。获得足够的样本组和可靠见解，我们使用LinkedIn-专业人士的社交网络确定经验丰富的机器学习专业人员，他们在全球范围内具有深刻的MLOps知识。为了从各层面获得见解和观点，我们选择不同的面试伙伴组织和行业，不同的国家和民族，以及不同的性别。采访一直进行到在数据分析中没有新出现的类别和概念。总的来说，我们与专家（α-θ）进行了八次访谈，详细信息如下：如附录表2所示。根据格拉泽施特劳斯[5，p.61]的说法，这个阶段被称为“理论饱和度”。所有访谈于2021年6月至8月进行。

关于面试设计，我们准备了一个半结构化指南，其中包含几个问题，记录为面试脚本[33]。在采访中，“软梯形”是与“如何”和“为什么”问题一起使用以探究受访者的“表示末端链”[39]。这种有条不紊的方法使我们能够获得进一步了解受访者的经历。所有采访都被记录下来，然后转录。到评估面试记录，我们使用一个开放的编码方案[8].

4 结论

我们应用所描述的方法论，结构化洞察结果，使重要原则，它们的结果实例化为组件，必要角色的描述，如以及对体系结构和工作流程的建议结合这些方面展现出来。最后，我们推导出该术语的概念化并提供MLOPs的定义。

4.1原则
原则被视为通用的或基本真理，价值或行为指南。在MLOPs的背景下，原则是指导在MLOP中应该如何实现并且密切相关专业部门的“最佳实践”一词。基于在概述的方法论中，我们确定了9条原则，来实现MLOPs。图2提供了这些原则的说明并将它们链接到与它们相关的组件。

P1 CI/CD自动化。CI/CD自动化提供持续集成，持续交付和持续部署。它执行构建，测试，交付和部署步骤。它提供了向开发人员快速反馈有关成功或失败的信息的某些步骤，从而提高整体生产力
[15,17,26,27,35,42,46] [α, β, θ].

P2工作流程编排。工作流程编排根据有向无环图（DAG）协调ML工作流管道的任务。DAG定义任务执行通过考虑关系和依赖关系来排序[14,17,26,32,40,41] [α, β, γ, δ, ζ, η].

P3重现性。再现性是进行ML实验，得到完全相同的结果[14,32,40,46][α, β, δ, ε, η]再现的能力.
P4版本控制。版本控制确保数据的版本控制，模型和代码，不仅可以重现，而且可追溯性（出于合规和审计原因）[14,32,40,46][α，β, δ, ε, η].
P5合作。合作确保了在数据，模型和代码上协同工作上的可能性。除了技术方面，这一原则强调协作和旨在减少不同的角色在[14,26,40][α，δ，θ]交际工作文化的领域孤岛。
P6持续的ML模型训练和评估。持续模型训练意味着基于新的ML模型的定期再训练特征数据。通过支持持续训练监控组件，形成反馈回路和自动ML工作流管道。持续训练总是包括一个评估运行以评估模型质量的变化[10,17,19,46][β, δ, η, θ].
P7 ML元数据跟踪/记录。在每个编排的ML工作流程任务中元数据会被跟踪和记录。元数据跟踪
并且每次训练作业迭代都需要记录（例如，训练日期和时间，耗时等），包括特定型号元数据-例如，使用的参数和结果性能度量标准，模型谱系：用于确保完整的数据和代码实验运行的可追溯性[26,27,29,32,35][α，β，δ，ε，ζ，η，θ]。
P8持续监测。持续监测意味着定期评估数据，模型，代码，基础设施资源和模型服务性能（例如，预测准确性），以检测潜在的错误或变化，影响产品质量[4,7,10,27,29,42,46][α，β，γ，δ，ε，ζ，η]。
P9反馈回路。需要多个反馈回路来将质量评估步骤中的见解整合到开发或工程过程（例如，来自
实验模型工程阶段到预先的特征工程阶段）。需要另一个反馈回路监控组件（例如，观察模型服务
性能），以启用再训练[4,6,7,17,27,46] [α, β, δ, ζ, η, θ]。

4.2技术组件
在确定了需要纳入的原则之后我们现在详细说明精确的组件和它们在ML系统设计中具体的实现。在下文中组件以通用方式罗列、描述基本功能。括号中的引用参考了正在实施的技术组件的各自原则。
C1 CI/CD组件（P1，P6，P9）。CI/CD组件确保持续集成，持续交付和持续部署。它负责构建，测试，交付和部署步骤。它为开发人员提供有关某些步骤的成功或失败反馈，从而提升整体生产率[10,15,17,26,35,46][α，β，γ，ε，ζ，η]。例子是Jenkins[17,26]and GitHub 的行为（η）。

C2 源代码库（P4，P5）。源代码存储库确保代码存储和版本控制。它允许多个开发者提交并合并他们的代码[17,25,42,44,46][α，β，γ, ζ, θ]. 示例包括Bitbucket[11][ζ]、GitLab[11,17][ζ]，GitHub[25][ζ，η]和Gitea[46]。

C3工作流编排组件（P2、P3、P6）。这个工作流编排组件提供了通过有向无环图（DAG）的ML工作流。这些图表示工作流[26,32,35,40,41,46][α，β，γ，δ，ε，ζ，η]中的单个步骤的执行顺序和工件使用情况。示例包括Apache Airflow[α，ζ]、Kubeflow Pipelines[ζ]、Luigi[ζ]、AWS
SageMaker Pipelines[β]和Azure Pipelines[ε]。

C4特征存储系统（P3、P4）。特征存储系统确保常用特征在中央服务器上存储。它有两个配置的数据库：一个数据库作为脱机特征存储提供具有正常实验延迟的特征，以及一个数据库作为一个在线存储，以低延迟为生产中的预测[10,14][α，β，ζ，ε，θ]提供特征服务。示例包括Google Feast[ζ]，亚马逊AWS Feature Store[β，ζ]，Tecton.ai和Hopswork.ai[ζ]。这是训练ML模型的大部分数据的来源。此外，数据也可以直接从其他任何类型的数据存储中获取到。

C5 模型训练基础设施 (P6)。 模型训练基础设施提供基础计算资源，例如，CPU、RAM 和 GPU。 提供的基础设施可以是分布式或非分布式。 一般来说，建议使用一个可扩展且分布式的基础架构 [7,10,24–26,29,40,45,46] [δ, ζ, η, θ]。 示例包括本地机器（不是可扩展）或云计算 [7] [η, θ]，以及非分布式或分布式计算（几个工作节点）[25,27]。支持计算的框架是 Kubernetes [η, θ] 和RedHat OpenShift [γ]。

C6 模型注册表（P3、P4）。模型注册表集中存储了训练的 ML 模型及其元数据。它有两个主要功能：存储 ML 工件和存储 ML元数据（见 C7）[4,6,14,17,26,27] [α, β, γ, ε, ζ, η, θ]。先进的存储示例包括 MLflow [α, η, ζ]、AWS SageMaker模型注册表 [ζ]、Microsoft Azure ML 模型注册表 [ζ] 和
Neptune.ai [α]。简单的存储示例包括 Microsoft Azure存储、谷歌云存储和亚马逊 AWS S3 [17]。

C7 ML 元数据存储（P4、P7）。 ML 元数据存储允许用于跟踪各种元数据，例如，对于每个编排的 ML 工作流管道任务。另一个元数据存储可以在模型注册表中进行配置以进行跟踪和记录每个训练作业的元数据（例如，训练日期和时间、持续时间等），包括模型特定的元数据——例如，使用的参数和产生的性能指标，模型lineage：使用的数据和代码 [14,25–27,32] [α, β, δ, ζ, θ]。例子
包括具有内置元数据存储的协调器，跟踪实验管道 [α] 的每个步骤，例如 Kubeflow Pipelines [α,ζ]，AWS SageMaker Pipelines [α,ζ]、Azure ML 和 IBM Watson Studio [γ]。 MLflow 提供了一个高级元数据存储与模型注册表相结合 [32,35]的存储方法。        

C8 模型服务组件 (P1)。服务的模型组件可以针对不同的目的进行配置。例如像实时预测的在线推理或批量推理使用大量输入数据进行预测。服务可以是提供，例如，通过 REST API。作为基础设施层，推荐使用一个可扩展的分布式模型服务基础设施 [7,11,25,40,45,46] [α, β, δ, ζ, η, θ]。模型服务组件配置的一个案例是使用 Kubernetes和 Docker 技术来容器化 ML 模型，以及利用 Python Web 应用程序框架，如 Flask [17]带有用于服务 [α] 的 API。其他支持 Kubernetes的框架是Kubeflow [α] 的 KServing、TensorFlow Serving、和 Seldion.io 服务 [40]。推理也可以通过用于批量预测的 Apache Spark [θ]。云服务示例包括 Microsoft Azure ML REST API [ε]、AWS SageMaker端点 [α, β]、IBM Watson Studio [γ] 和 Google Vertex AI预测服务 [δ]。

C9 监控组件（P8、P9）。 监测组件负责模型服务性能的持续监控（例如，预测准确性）。 此外
对 ML 基础架构、CI/CD 和编排的监控是需要 [7,10,17,26,29,36,46] [α, ζ, η, θ]。 例子包括
Prometheus 与 Grafana [η, ζ]，ELK 堆栈（Elasticsearch，Logstash 和 Kibana) [α, η, ζ]，以及简单的 TensorBoard [θ]。具有内置监控功能的示例是 Kubeflow [θ]，MLflow [η] 和 AWS SageMaker 模型监控器或云监控器[ζ]。

4.3 角色
在描述了原理及其产生的实例化之后组件，我们确定必要的角色，以如下方式实现MLOps。 MLOps 在生产中管理、自动化和操作机器学习系统层面是一个跨学科小组过程，不同角色的相互作用对设计至关重要。在里面接下来，简要介绍每个角色、其目的和相关任务描述：
R1 业务利益相关者（类似角色：产品负责人、专案经理）。业务利益相关者定义业务使用 ML 实现的目标并负责沟通业务方面，例如使用 ML 产品 [17,24,26] [α, β, δ, θ] 生成的展示投资回报率 (ROI)。
R2 Solution 架构师（类似角色：IT 架构师）。这解决方案架构师设计架构并定义经过全面评估 [17,27] [α,ζ]。
R3 数据科学家（类似角色：ML 专家、ML开发者）。数据科学家将业务问题转化为一个 ML 问题并负责模型工程，包括选择性能最佳的算法和超参数[7,14,26,29] [α, β, γ, δ, ε, ζ, η, θ]。
R4 数据工程师（类似角色：DataOps 工程师）。数据工程师建立和管理数据和特征工程管道。此外，此角色可确保将正确的数据提取到特征存储系统的数据库 [14,29,41] [α, β, γ, δ, ε, ζ, η,θ]。

R5 软件工程师。 软件工程师应运软件设计模式，广泛接受编码指南，以及将原始 ML 问题转化为精心设计的最佳实践产品 [29] [α, γ]。
R6 开发运维工程师。 DevOps 工程师弥补了在开发和运营之间的鸿沟，并确保适当的 CI/CD自动化、ML 工作流程编排、模型部署到生产和监测 [14–16,26] [α, β, γ, ε, ζ, η, θ]。
R7 ML 工程师/MLOps 工程师。 ML 工程师或MLOps 工程师结合了多个角色的各个方面，因此具有跨领域知识。 这个角色融合了来自数据科学家、数据工程师、软件工程师、DevOps 工程师、
和后端工程师（见图 3）技能。 这个跨域角色建立和运营了机器学习基础设施，管理自动化 ML 工作流管道并将模型部署到生产，同时监控模型和机器学习基础设施[14,17,26,29] [α, β, γ, δ, ε, ζ, η, θ]。

5 架构和工作流程

基于确定的原则、组成部分和角色的基础上，我们推导出一个通用的 MLOps 端到端架构，以提供 ML研究人员和从业人员的正确指导。 它描绘在图 4. 此外，我们描述了工作流程，即其中不同的任务在不同的阶段执行的顺序。 这个制程被设计为与技术无关。 因此，机器学习研究人员和从业者可以选择最合适的技术和框架来满足他们的需求。
如图 4 所示，我们通过从 MLOps 项目启动到模型服务说明了一个端到端的过程。 它包括（A）
MLOps 项目启动步骤； (B)特征工程管道，包括特征存储的数据摄取； (C)实验； (D) 自动化 ML 工作流管道到模型服务。

(A) MLOps 项目启动。 (1) 业务利益相关者(R1) 分析业务并识别潜在业务可以使用 ML 解决的问题。 (2) 解决方案架构师(R2) 定义整个 ML 系统的架构设计，并且，在全面评估后决定要使用的技术。(3) 数据科学家 (R3) 从业务目标推导出一个机器学习问题——例如应该使用回归还是分类。 (4) 数据工程师 (R4) 和数据科学家 (R3)共同努力，以了解需要哪些数据解决这个问题。 (5) 答案明确后，数据工程师 (R4) 和数据科学家 (R3) 合作定位原始数据用于初始数据分析的数据源。他们检查数据分布和数据质量，以及执行验证检查。此外，它们确保来自数据源的数据被标记，意味着目标属性是已知的，因为这是监督机器学习的强制性要求。在这个例子中，数据源已经有标记数据可用作在上游过程中的标记步骤被覆盖。

(B1) 特征工程流水线的要求。这特征是模型训练所需的相关属性。初步了解原始数据和初始数据后分析，特征工程的基本要求管道定义如下： (6) 数据工程师 (R4) 定义数据转换规则（规范化、聚合）和清理规则以将数据转换为可用格式。 (7) 资料科学家 (R3) 和数据工程师 (R4) 共同定义特征工程规则，如新的计算等基于其他功能的高级功能。这些最初定义规则必须由数据科学家 (R3) 反复调整基于来自实验模型的反馈工程阶段或从监控组件观察模型性能。
(B2) 特征工程管道。最初定义的特征工程管道的要求由数据工程师（R4）和软件工程师（R5）作为起点建立特征工程管道的原型。这最初定义的要求和规则根据来自实验模型的迭代反馈工程阶段或从监控组件观察模型在生产中的表现。作为一项基本要求，数据工程师 (R4) 定义 CI/CD (C1) 所需的代码和编排组件（C3），以确保任务编排的特征工程管道。这个角色还定义了底层基础设施资源配置。 (8) 首先，特征工程管道连接到原始数据，可以是（例如）流数据、静态批处理数据或来自任何云储存。 (9) 数据将从数据源中提取。(10) 数据预处理过程从数据转换，数据清洗任务开始。在需求收集阶段中定义的转换规则工件用作此任务的输入，并且此任务的主要目的是将数据转换为可用格式。这些转换规则基于反馈不断完善。 (11) 特征工程任务基于其他特征计算更多更高阶的特征。 预定义的特征工程规则用作此任务的输入。 这些特征工程规则根据反馈不断改进。(12) 最后，数据提取作业将批量或流式数据加载到特征存储系统（C4）。 目标可以是离线的，也可以是在线数据库（或任何类型的数据存储）。

(C) 实验。 实验阶段的大部分任务由数据科学家 (R3) 领导。 数据科学家会由软件工程师（R5）支持他的工作。 (13) 数据科学家 (R3) 连接到用于数据分析的特征存储系统（C4）。 （或者，数据科学家 (R3) 还可以连接到原始数据以进行初始分析。）在任何需要数据调整的情况下，数据科学家 (R3) 将所需的更改，报告回数据工程区（反馈回路）。

(14) 然后需要对从特征存储系统中获取的数据进行准备和验证。该任务还包括训练和测试拆分数据集的创建。 (15) 数据科学家 (R3)估计性能最佳的算法和超参数，然后使用训练数据（C5）触发模型训练。软件工程师 (R5) 支持数据科学家 (R3)创建精心设计的模型训练代码。 (16) 不同模型参数在几轮模型训练过程中以交互方式进行测试和验证。一旦性能指标表示好的结果，迭代训练停止。性能最佳的模型参数是通过参数调整来确定的。然后将模型训练任务和模型验证任务反复重复；这些任务一起可以称为“模型工程”。模型工程旨在确定模型的最佳性能算法和超参数。 (17)数据科学家 (R3) 导出模型并将代码提交给存储库。

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

(D) 自动 ML 工作流管道。 DevOps 工程师(R6) 和 ML 工程师 (R7) 负责管理自动化 ML 工作流管道。他们还管理硬件形式的底层模型训练基础设施支持计算的资源和框架，例如Kubernetes (C5)。工作流编排组件 (C3)编排自动化 ML 工作流管道的任务。为了每个任务，所需的工件（例如，图像）都是从工件存储库（例如，图像注册表）拉取。每个任务都可以通过隔离环境（例如容器）执行。最后，工作流程编排组件 (C3) 为每个任务以日志、完成时间等形式收集元数据。
        一旦触发了自动化 ML 工作流管道，每个以下任务是自动管理的：(18) 自动的从功能存储系统中提取版本化功能（数据提取）。根据用例，提取来自离线或在线数据库（或任何类型的数据存储）的特征。(19) 自动化的数据准备和验证；除此之外训练和测试拆分是自动定义的。 (20)基于新的看不见的数据（版本化特征）进行最终的模型训练。算法和超参数已经基于前一个实验阶段的设置预先定义好了。模型是再训练和微调。 (21) 如果需要，执行自动模型评估和迭代的超参数更新。一旦性能指标表明结果良好，自动化迭代训练停止。自动化模型训练任务和自动模型验证任务可以迭代重复，直到取得了良好的效果。 (22) 训练好的模型被导出并 (23) 推送到模型注册表 (C6)，它同例如代码或与其相关联的容器化配置和环境文件一同被存储。

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

一旦一个表现良好的模型的状态从暂存到生产，它会自动移交给用于模型部署的 DevOps 工程师或 ML 工程师。从在那里，(24) CI/CD 组件 (C1) 触发连续部署管道。生产就绪的 ML 模型和模型服务代码被拉取（最初由软件准备工程师 (R5))。持续部署管道执行ML 模型的构建和测试步骤以及服务代码和部署生产服务模式。 (25) 模型服务组件（C8）对即将到来的来自特征存储系统（C4）的新的、看不见的数据进行预测。这个组件可以由软件工程师 (R5) 设计为用于实时预测的在线推理或用于预测的批量推理大量的输入数据。对于实时预测，特征必须来自在线数据库（低延迟），而对于批量预测，可以从离线数据库中提供特征（正常延迟）。模型服务应用程序经常被配置在容器内，预测请求通过 REST 处理API。作为一项基本要求，ML 工程师 (R7)管理模型服务计算基础设施。 (26)监控组件 (C9) 持续实时观察模型服务性能和基础设施。一旦某个达到阈值，例如检测到低预测精度，信息通过反馈回路转发。  (27)反馈回路连接到监控组件（C9）和确保快速和直接的反馈允许更强大和改进的预测。 它支持持续训练、再训练、和改进。 在反馈回路的支持下，信息从模型监控组件传输到几个上游接收点，例如实验阶段，数据工程区和调度器（触发器）。 反馈给实验阶段由数据科学家推进进一步的模型改进。 对数据工程域的反馈允许对特征存储系统中的特征进行调整。 此外，检测概念的漂移作为一种反馈机制，可以实现 (28) 持续训练。 例如，一旦模型监控组件 (C9) 检测到数据漂移[3]，信息转发给调度程序，然后触发自动化的ML工作流程管道进行重新训练（持续训练）。 部署模型的充分性变化可以使用分布比较来检测以识别漂移。统计时不仅会自动触发重新训练达到阈值； 当新特征数据可利用时，它也可以触发，或者可以安排定期执行。

6 概念化

随着手头的发现，我们概念化了文献和访谈。很明显，MLOPS已定位在机器学习，软件工程的交集中，DevOps和数据工程（请参阅附录中的图5）。我们定义MLOPS如下：MLOP（机器学习操作）是一个范式，包括最佳实践，一组概念等方面开发文化在端到端概念化，实施，监视，部署和机器学习产品的可伸缩性。最重要的是，这是一个利用三个贡献学科的工程实践：机器学习，软件工程（尤其是DevOps）和数据工程。 MLOPs旨在通过弥合开发（DEV）和操作（OPS）之间的差距落地机器学习系统。本质上，MLOP旨在促进通过利用这些原则来创建机器学习产品：CI/CD自动化，工作流编排，可重复性；数据，模型和代码的版本控制；合作; 持续的ML训练和评估； ML元数据跟踪和记录；持续监控和反馈回路。

7 开放挑战

在进行文献综述，工具审查和访谈之后学习后已经确定了采用MLOP时的几个挑战。这些开放的挑战已经组织到组织化的类别中，诸如ML系统和运营类别挑战。

组织挑战。数据的科学实践的文化和思想是组织环境中的典型挑战[2]。正如我们从学术和访谈所展示的见解，成功开发和运行ML产品，需要有一种从模型驱动的机器学习到面向产品的学科[γ]的文化转移。以数据为中心AI的最新趋势也解决了通过将更多专注于与数据相关的方面进行在ML模型建设之前放置。特别是角色与这些活动相关的应该有针对产品的设计ML产品[γ]时的透视图。大量的MLOP（β）需要技能和个体角色。作为我们的确定的消息来源指出，缺乏高技能的专家对于这些角色，尤其是关于架构师，数据工程师，ML工程师和DevOps工程师[29,41,44] [α，ε]。这是与未来专业人员的必要教育有关MLOP通常不是数据科学教育的一部分[7] [γ]。Posoldova（2020）[35]进一步强调了这一方面学生不仅应该了解创建模型，而且还必须了解建造功能性ML产品所需的技术和组件。
仅仅数据科学家无法实现MLOP的目标。需要一个多学科团队[14]，因此MLOP需要成为一个小组有个过程[α]。这通常是因为团队在工作中而受到阻碍而不是合作性的建设[α]。另外，不同知识水平和专业术语使得沟通变困难。为更富有成果的基础奠定基础设施，各自的决策者需要确信MLOP的成熟度增加和以产品为中心的理念将产生明确的业务改进[γ]。

ML系统挑战。关于MLOPS系统正在为需求波动而设计，尤其是在与ML训练过程有关[7]。这源于
潜在的大量和变化的数据[10]，这使得它难以精确估计必要的基础设施资源（CPU，RAM和GPU），并且需要高水平的可伸缩性的灵活性基础设施[7,26] [δ]。

操作挑战。 在生产环境中，是由于手动操作ML的挑战来源于软件和硬件组件及其相互作用的不同的技术栈。 所以，需要强大的自动化[7,17]。 另外，恒定的新数据流输入迫使再训练功能的强化。 这是重复的，需要高水平的自动化[18] [θ]。这些重复的任务产生了大量需要的工件，具备强大的治理[24,29,40]能力以及数据，模型，模型，和代码以确保鲁棒性和可重复性[11,27,29]。最后，解决潜在的支持请求是一项挑战（例如通过找到根本原因），因为许多各方和组件都涉及其中。 失败是会伴随者ML基础架构和软件[26]的现象。

8 总结

随着数据可用性和分析功能的增加，加上恒定的创新压力，比以往任何时候更多的机器学习产品被开发出来。但是，只有一个这些概念证明中的少数进展到部署和生产。此外，学术空间已集中强烈地建立机器学习模型和基准测试，但是在操作复杂的机器学习系统上有太少真实的场景。在现实世界中，我们观察到数据科学家仍然在很大程度上手动管理ML工作流程。机器学习操作范式（MLOP）设法解决这些挑战。在这项工作中，我们对MLOPS有了更多的启示。经过进行的一项混合方法研究，分析现有文献和工具以及采访了该领域的八名专家，我们发现MLOP的四个主要方面：其原理，组成部分，角色和架构。从这些方面，我们推断出一个整体定义。结论支持对MLOP该术语及其相关的概念的共同理解，并希望将来能协助研究人员和专业人士建立成功的ML项目。