1 机器学习运维定义

1.1 MLOps定义

MLOps（Machine Learning Operations），是一种通过整合数据科学家和运维团队的合作和协同，旨在统一机器学习系统开发（Dev）和机器学习系统部署（Ops）的最佳实践。

DevOps 是一组有助于可靠地构建、集成、测试和部署软件的实践。它可用于在开发领域以最小的部署开销实现持续集成和交付。DevOps 的成功实践可以应用于ML，以构建强大的ML系统。不同的是，MLOps还需要数据工程，因为数据是构建ML的基石。数据采集、验证和特征工程等都是数据工程的关键组成部分。通过借鉴 DevOps 的成功实践经验并将其应用于ML系统，MLOps的理念和方法可优化整个ML生命周期的管理，其目标是通过标准化过程来生产高性能模型，并以持续交付的方式，将这些模型自动部署到生产环境中。MLOps将机器学习与设计、构建和维护系统的任务相结合，以使企业更有系统性地应用数据，提高数据科学家的工作效率，并确保模型与业务需求和规则保持一致。这是一种基于DevOps思想的机器学习工程文化和实践，涉及到自动化、监控、质量保证、持续集成和部署，以满足不断增长的机器学习应用需求。

有了成熟的MLOps，团队就能更好地支持整个 ML 生命周期，涉及从业务需求和目标可行性到模型实验和生产的方方面面。一个 MLOps 流程有助于消除手动的、容易出错的节点，并打破团队之间的“流程壁垒”，确保所部署的模型及数据在随时间演变的过程中保持准确。随着 MLOps 实践在企业中的应用逐渐成熟，其自动化程度也越来越高，比如，建立机制来自动执行流水线，并以此持续构建、测试和部署 ML 管道。此外，ML 模型的性能监测不仅可以触发新的部署管道，而且还可以产生新的实验。MLOps帮助企业将机器学习落地到业务中的关键方法，使模型开发、部署和维护更加高效和可持续。

1.2 DevOps定义

DevOps是一种软件开发和运维的方法论，其目标是通过加强开发团队和运维团队之间的协作和自动化，以实现更快速、更可靠、更频繁的软件交付和部署。DevOps是"Development"（开发）和"Operations"（运维）这两个词的结合，强调了在整个软件生命周期中将开发和运维过程无缝集成的重要性。

DevOps的关键原则和实践包括：

1. 自动化：自动化是DevOps的核心。它包括自动化软件构建、测试、部署和监控等过程，以减少手动操作，提高效率，减少错误。
2. 持续集成（CI）：持续集成是一种实践，开发人员频繁地将代码合并到共享的代码仓库，并进行自动化测试，以确保代码的质量。这有助于及早发现和解决问题。
3. 持续交付（CD）：持续交付是一种实践，将经过持续集成测试的代码自动部署到生产环境中。这意味着新功能和改进可以更快地交付给用户。
4. 协作：DevOps强调开发人员、运维人员和其他相关团队之间的紧密协作。这有助于消除沟通障碍，确保所有团队成员都能了解和支持项目的目标。
5. 监控和反馈：持续监控应用程序的性能和可用性是DevOps的一部分，以及时发现问题并采取纠正措施，使团队能够改进不断改进流程和质量。

1.3 MLOps和其他Ops的区别

1.3.1 MLOps与DevOps

在传统软件开发的世界里，一套被称为 DevOps 的工程实践使得在几分钟内将软件部署到生产中并保持其可靠运行成为可能。DevOps 依靠工具、自动化和工作流程来抽象出软件工程的复杂性，让开发人员专注于需要解决的实际问题。这种方法如今已经非常成熟，在软件开发领域已经基本成为“标配”，那么为什么这套方法论或经验不能直接应用到 ML 领域? 其原因在于，ML 的跨领域特性延伸出了新的维度，比如，增加了一个额外的数据维度，而这个维度区分了 ML 和传统软件，也给开发和运维过程带来了全新的挑战。对于传统软件，几乎可以即时体现代码变化对结果的影响;但在ML中，想要看到代码变化对结果的影响需要重新训练模型。若考虑额外数据维度的影响，情况会变得更复杂，数据维度的引入不仅改变了代码在开发过程中的工作方式，而且数据本身也是在时刻变化的。在传统软件开发中，一个版本的代码产生一个版本的软件，代码的版本决定了软件的版本。在版本控制系统的辅助下，我们可以在任何时候创建应用程序的任意变体。而 ML 则不是这样的，在 ML 中，开发的结果不是代码而是模型，而这个模型又是由创建和训练模型的代码版本及其所使用的数据产生的。一个版本的代码和一个版本的数据结合在一起产生了一个版本的 ML 模型。代码和数据分别处在两个平行的平面上，它们之间共享时间维度，但在所有的其他方面都是独立的。这种处在不同平面的关系也给具体的开发和应用带来了挑战，任何试图将ML模型成功投入生产的从业者都会面临这些挑战。

1. 在ML 项目中，除了要保存不同版本的代码，还需要一个地方来保存不同版本的数据和模型工件。ML 涉及大量的实验。数据科学家使用各种数据集训练模型，并生成不同的输出。因此，除了借鉴 DevOps 的代码版本控制方案，MLOps 还需要特定的工具来保存不同版本数据、模型工件和涉及的元数据信息，以方便后续的管理和运维。
2. 与代码不同，模型性能会随着时间的推移而衰退，这就需要监控。在将训练好的模型部署到生产环境后，便开始从真实数据中产生预测。在一个稳定的环境中，模型的性能不会下降。但是，真实世界时刻在变化，我们的模型接收的实时数据也在变化,这导致的直接后果就是所谓的“模型衰退(有时候也被称作训练服务偏移)。换句话说，它的预测准确率可能会随着时间的推移而下降。为了防止模型性能动态衰退，我们需要持续地监测模型，这在DevOps实践中很少见。
3. 训练永远不会结束。一旦发现模型性能下降，就需要用新的数据重新训练模型，并在再次投入生产前进行验证。在MLOps实践中，这种持续的训练和验证在一定程度上可以看作 DevOps 实践中的持续测试。

为了应对这些挑战，我们可以借鉴来自 DevOps 和数据工程的经验，增加一些 MLOps 特有的方案，以一种可控的方式在代码和数据平面之间建立一座桥梁。

1.3.2 MLOps与DataOps

DataOps（数据运维）与MLOps 的概念几乎是同时出现的，并且 DataOps也从 DevOps 实践中借鉴了很多经验，但 DataOps的核心应用对象是数据应用DataOps涵盖了数据生命周期内的所有步骤，从数据收集、处理到分析和报告,并尽可能地将其过程自动化。它的目标是提高数据的质量和可靠性，同时尽量缩短提供数据应用所需的时间。这种方法对处理大型数据集和复杂数据工程管道的业务场景特别有帮助，DataOps也可以在一定程度上辅助 ML 项目，但只是在辅助的层面上，因为它不提供管理模型生命周期的解决方案，所以可以认为 MLOps 是 DataOps 的延伸。

1.3.3 MLOps与AIOps

作为 Ops 中比较另类的一个，从字面上理解，AIOps 与 MLOps 很相似，这其实是误解。2017 年 Gartner 首次提出了该术语，AIOps 被定义为结合大数据和ML技术实现IT运维流程的自动化方案。从本质上讲，AIOps 的目标是自动发现日常 IT 运维中的问题，并利用AI主动做出智能反应和预警。简单地说，AIOps 是 AI在 Ops 领域中的应用，应用的主体是Ops，而MLOps 则是 Ops在ML领域中的应用，应用的主体是ML。

1.4 MLOps的工作流程

MLOps的工作流程是由一系列ML管道（有时候也叫流水线）组成的，ML管道是处理数据集时所涉及步骤的序列。管道由步骤组成，每个步骤都是一个独立的实体,每个实体都会接收输入并在进行相应的处理后产生输出，该输出由执行顺序决定是否作为下一个步骤的输入。第一步，ML管道的工作通常从数据准备开始，然后将准备好的数据存储到相应的存储设备上。第二步，在接下来的特征工程步骤中，将会从数据存储设备中获取准备好的数据，进行缺失数据填补、特征提取、特征转换、降维、样本分割等工程操作。第三步，特征工程完成后会流转到模型开发步骤，即将特征工程步骤输出的特征“喂给”模型来进行开发和训练。第四步，进行模型部署,向业务系统或第三方提供推理服务(通常以RESTAPI的形式提供)。这里的服务指的是通过将模型部署为在线服务来接收实时请求并返回预测结果，模型投产从这一步骤开始。第五步，这也是 ML 项目周期的最后一步，在模型部署并上线发布后，将进入模型监控步骤，该步骤会对生产中的模型性能进行评估，在模型衰退到性能的预设阈值时，会触发模型重新训练作业，然后开始新的周期。

在实践中，通常会将模型的训练和部署过程分开操作，在 MLOps 工作流程里，模型开发训练及之前的步骤属于“ML”的范畴，模型部署及之后的步骤属于Ops”的范畴。当我们在生产中部署一个模型时，通常会部署训练阶段产生的结果。比如，特征工程沉淀下来的规则及训练好的模型，有时候还需要对实时特征与存量特征进行合并和计算。当数据分布发生偏移或生产中的模型性能下降到一定程度时，我们还需要收集最新数据来进行模型的更新，生产中通常的做法是对训练管道进行离线更新，在模型部署环节则需要热部署，即需要在工程上实现不停机的情况下更新模型服务。模型投产后还需要对数据分布、模型性能及服务状态等方面进行监控。

2 常见名词解释

2.1 原始数据、输入数据、特征与特征工程

数据是任何 ML 项目的核心“原材料”，原始数据指的是从业务系统直接或间接获取的信息，数值属性的原始数据通常可以直接输入ML模型，但很多时候原始数据在输入模型之前需要进行某种数据预处理，比如原始数据为图片、文本等时。这里的数据预处理属于特征工程的范畴，特征工程是对原始数据或中间特征进行一系列工程化的处理，目标是找到将原始数据或中间数据（已被预处理过的数据）映射为一个更适合建模的新的表示形式，以降低原始数据的噪声和冗余，在提炼出原始数据中，尽可能多信息的同时还能更高效地刻画原始数据与目标的关系。

最终用于模型训练的数据被称为输入数据，输入数据的集合被称为输入空间，通常每个具体的输入称为一个实例，称实例的表示为特征向量，所有特征向量的集合存在于一个空间，即特征空间，特征空间的每一维就是一个特征。

2.2 训练样本及预留样本

我们谈论的样本集，通常是指在进行监督学习模型构建时用于训练、验证和测试 ML 模型的数据。其中用于训练模型的样本被称作训练样本，用于验证和测试模型的样本被统称为预留样本。在实际操作中，通常会将大部分数据随机地分配给训练样本；在训练过程中输入模型数据，用于在训练过程中生成模型参数验证数据用于评估模型在该数据上的表现，根据模型在验证数据上的性能来决定何时停止训练运行，以及选择合适的超参数。测试数据是完全没有在训练过程中使用过的数据，用于评估训练后模型的泛化能力。原则上，ML 模型性能的离线评估必须在独立的测试数据上计算，而不是在训练或验证集上。同样重要的是，三个样本集 （训练集、验证集和测试集）都需要是同分布的，且使用相同的特征及特征工程逻辑。

2.3 参数与超参数

参数通常表示为学习算法所训练的模型各变量的权重。参数是由学习算法根据训练数据直接拟合而成的。学习的目标是找到这样的参数值，使模型在一定意义上达到最优。超参数则是学习算法或管道的输入，会影响模型的性能，但不属于训练数据，不能从训练数据中学习。对于初学者来说，经常会将模型超参数与模型参数混淆，这里提供一个简单的判断方法：如果一个参数是从业者必须手动指定的，那么它可能就是模型超参数。

2.4 参数模型、非参数模型、极大似然估计

前面定义的数据、特征、参数等概念都是学习的组成部分，学习的本质是找到一个输入到输出之间的映射，这里的映射通常用模型来表示，学习就是要训练出最优模型，训练的过程通常被称为拟合，模型拟合本身是一个优化问题，所以我们需要指定一个要优化的目标函数（也被称作损失函数）。在定义目标函数之前，需要设计模型框架，设计模型框架要考虑的因素之一是选择参数化或非参数化的方法。参数化方法，即参数模型的假设是，数据分布具有一定的函数形式，数据由固定数量的参数的分布生成。此时模型的拟合即为分布的估计，也就是指定或选择模型的参数 ，使得该分布模型可以最佳地拟合观测到的数据。

非参数化方法，即非参数模型的假设是参数的数量可以动态变化。在一些方法中，每一个数据点都可以看作一个参数，最常用的非参数化方法之一是最近邻（K-Nearest Neighbors，KNN）算法，其思想是，根据特征空间中距离最近数据样本所对应的响应值来估计特征向量的响应变量的值。非参数化方法的缺点是，数据维度越大数据空间就越稀疏，每次预测的时候都需要对局部观测值进行计算，不能像参数模型那样通过训练集来概括观测到的模式。

极大似然函数是ML的核心概念。我们假设观测到的数据独立同分布于数据分布 ，每个数据样本 都可以被解释为因素 导致输出 的产生，目标函数则可以被定义为给定参数向量时的概率密度函数，观测到的响应变量的概率是已知的：

函数被称为似然函数，它是在假设数据来自参数为 的模型所指定的分布的情况下观察到数据的概率。在实际应用中，通常为了方便分析和计算，会对似然函数取对数，记作对数似然 (Log-Likehood)估计，简称 。具体的公式如（式1-1）所示。

极大似然估计的目标是找到能使（式1-1）最大化的参数向量，如（式1-2）所示。

2.5 ML 管道

首先，让我们明确管道的概念，在软件开发领域，“管道”一词源于 CICD 的 DevOps 原则，它是一组自动化流程，允许开发人员和 DevOps 专业人员将他们的代码可靠、高效地编译和部署到生产计算平台。可以认为这些流程是模块化和可组合的代码块，在整个预制的序列中执行特定的任务。数据工程的核心概念之一是数据管道，数据管道是应用于其输入和目标之间的一系列数据转换。它们通常被定义为一个图，其中每个节点都是一个转换，边代表依赖关系和执行顺序。有许多专门的工具可以帮助创建、管理和运行这些管道。有时候，也可以称数据管道为 ETL (提取、转换和加载)管道。ML 模型通常需要进行一系列不同类型的数据转换，这些转换一般是通过脚本甚至Jupyter 中的单元来实现的，这使得它们难以进行可靠的管理和运行。而适当的数据管道方案在代码复用、运行时可见性、可管理性及可扩展性等方面都表现出了优势。同样，ML 管道是一种对 ML 的工作流程进行编码和自动化的技术，以生成用于生产的 ML 模型，本质上ML 管道涉及的内容也属于数据转换的范畴。很多数据管道中也会使用 ML 模型进行转换，但最终都服务于 ML 任务。大多数 ML模型都需要两个版本的管道:一个用于训练，另一个用于服务。这是因为用于训练和用于服务的数据格式、访问方式及运行时都有差别，特别是对于实时请求中提供服务的模型。ML 管道是一个纯代码的工件或脚本，独立于特定的数据实例。这意味着可以在源代码控制中跟踪其版本并使用常规的 CICD 进行管道的自动部署，这也是MLOps 的核心实践，这让我们能够以结构化和自动化的方式连接代码和数据平面，具体如图所示。

需要注意的是，这里把ML 管道分成了训练和服务两个相对独立的管道。它们的共同点是，需要使用相同的逻辑执行数据转换以生成可用特征，但它们的具体实现方式可能是非常不同的。例如，训练管道通常运行在包含所有特征的批处理文件上或从数据库中导出的数据框上，而服务管道通常是在线运行的并接收实时请求的特征，其余的离线特征从数据库中检索。

在实际应用中，不同模型的 ML 管道所涉及的节点具有相似性，因此应尽可能对管道中涉及的节点进行抽象，尝试复用代码和数据。例如：特征存储：统一提供用于训练管道的历史特征和用于服务管道的实时特征；训练过程各节点模块化：将模型训练过程中涉及的节点进行模块化，有利于训练管道的快速组合；模型即服务：将服务管道封装成通用的模型服务接口，并能够一键生成模型服务。ML 管道的概念给 ML 工作带来的转变是，建模团队不再只负责构建和维护ML 模型，而是要将整个管道作为产品进行集中化开发和维护，这确保了迭代周期的完成效率并提供了更高的扩展性。

2.6 模型选择与性能权衡

ML创建的模型本身可以视为一个程序，模型创建的过程会涉及以下常用概念：

模型选择：我们可以将配置和训练模型视为模型选择的过程，甚至 ML算法的选择也是模型选择过程的一部分，每次迭代都会产生一个新模型，对于迭代出来的这些模型，我们可以选择使用或继续迭代。当选择了要使用的模型时，该模型相对应的训练样本和算法配置也随之确定。归纳偏差：偏差是对所选模型施加的限制，所有模型都会有偏差，偏差会在模型中引入错误，并且根据定义，所有模型都可能有错误(因为模型是对观测值的概括)。ML 方法可以创建具有低偏差或高偏差的模型，并且可以使用策略来降低模型的偏差。模型方差：方差体现了模型对训练数据的敏感程度，在数据集上创建模型时ML 方法可以具有高方差或低方差。降低模型方差的一种策略是，在具有不同初始条件的数据集上多次运行模型训练过程，并将平均准确率作为模型性能。偏差与方差权衡：模型选择本质上可以被认为是对偏差和方差进行权衡的过程。低偏差模型将具有高方差，需要经过长时间或多次训练才能获得可用模型。高偏差模型将具有低方差并且可以快速训练，但模型性能通常不佳。

3 机器学习运维方法总结

MLOps研究方向的发展：

3.1 Quality-Assured Machine Learning Process Model

机器学习已经成为工业和学术界中一种已经建立且频繁使用的技术，但仍然缺乏一种标准的过程模型来提高机器学习应用的成功和效率。项目组织和机器学习从业者需要在整个机器学习应用的生命周期中获得指导，以满足业务期望。因此，这里提出了一种机器学习应用开发的过程模型，涵盖了从定义范围到维护已部署的机器学习应用的六个阶段。第一个阶段将业务理解和数据理解结合在一起，因为数据可用性通常会影响项目的可行性。第六阶段涵盖了监控和维护机器学习应用的最新方法，因为在不断变化的环境中，模型降级的风险是显著的。在模型开发的每个任务中，这里提出了适用于解决机器学习开发中风险挑战的质量保证方法。这一方法基于实际经验和科学文献，已被证明具有普适性和稳定性。该过程模型是CRISP-DM的扩展，CRISP-DM是一个享有工业界强烈支持的数据挖掘过程模型，但缺乏处理机器学习特定任务的能力。本工作提出了一个面向机器学习应用的、行业和应用中立的过程模型，重点关注质量保证的技术任务。

Quality-Assured Machine Learning Process Model^[1]. Studer Stefan, Bui Thanh Binh, Drescher Christian, Hanuschkin Alexander, Winkler Ludwig, Peters Steven, Mueller Klaus-Robert. arXiv 2020.

3.2 Building a Reproducible Machine Learning Pipeline

建模的可重复性是机器学习从业者不论是在工业界还是学术界都面临的问题。一个不可重复的模型即结果无法被复制，可能导致重大的财务成本、时间浪费，甚至可能损害个人声誉。本文首先讨论了在构建各种机器学习模型时遇到的问题，然后描述了我们构建的用于解决模型可重复性问题的框架。该框架由四个主要组成部分，即由数据、特征、评分和评估层组成，这些组成部分本身由明确定义的转换组成。这使这里不仅能够精确复制一个模型，还能够在不同模型之间重复使用这些转换。因此，该平台显著提高了离线和在线实验的速度，同时确保了模型的可重复性。

Building a Reproducible Machine Learning Pipeline^[2]. Peter Sugimura Tala, Florian Hartl Tala. CoRR 2018.

3.3 Reproducibility in ML Production from a Systemic View

在生产环境中部署的机器学习模型和流程的可重现性要求捕获当前和历史状态。由于典型生产部署的固有特性，捕获机器学习流程的状态是复杂的。这里提出了一个系统，从系统角度解决了这些问题，使机器学习专家能够跟踪和复制在生产中的机器学习模型和流程。这有助于快速诊断在生产环境中发生的问题。

A Systems Perspective to Reproducibility in Production Machine Learning Domain^[3]. Sindhu Ghanta, Lior Khermosh, Sriram Subramanian, Vinay Sridhar, Swaminathan Sundararaman, Dulcardo Arteaga, Qianmei Luo, Drew Roselli, Dhananjoy Das, Nisha Talagala. ICML 2018 Workshop.

3.4 Hidden Technical Debt in Machine Learning Systems

机器学习提供了一个极其强大的工具包，可以快速构建复杂而有用的预测系统。本文指出：将这些快速获得的成果视为免费的是危险的。运用技术债务的软件工程框架，本文发现在实际的机器学习系统中，通常会产生巨大的持续维护成本。这里探讨了几种在系统设计中需要考虑的机器学习特定风险因素，包括边界侵蚀、纠缠、隐藏的反馈循环、未声明的消费者、数据依赖性、配置问题、外部世界的变化，以及各种系统级反模式。

Hidden Technical Debt in Machine Learning Systems^[4]. D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-François Crespo, Dan Dennison. NIPS 2015.

3.5 A MLaaS to expand Machine Learning

机器学习即服务（MLaaS）对于许多公司成功获取大数据的商业智能至关重要。为了为关键任务和实时应用构建可扩展的MLaaS，面临着巨大的挑战。本文介绍了我们为Uber全球运营建立的可扩展MLaaS。这里重点关注了几个可扩展性方面的挑战。首先，如何为多种机器学习用例扩展特征计算。其次，如何利用全局数据构建准确的模型，考虑到各个城市或地区的特性。第三，如何实现可扩展的模型部署和跨多个数据中心的实时服务，以支持数十万个模型。这里的技术解决方案包括可扩展的特征计算引擎和特征存储的设计和实现，一个管理和训练多个模型层次结构作为单一逻辑实体的框架，以及一个自动化的一键部署系统和可扩展的实时服务。

Scaling Machine Learning as a Service^[5]. Li Erran Li, Eric Chen, Jeremy Hermann, Pusheng Zhang, Luming Wang. PMLR 2017.

3.6 A rubric for ML production systems

在真实的生产系统中使用机器学习面临着许多在小型示例或大规模离线研究实验中找不到的问题。测试和监控是评估机器学习系统是否适用于生产的关键考虑因素。但需要进行多少测试和监控才足够呢？本文提出了一个基于一组可行测试的ML测试评分规则，以帮助量化这些问题。这有助于在实际部署机器学习系统时更好地评估其质量和性能。

What's your ML Test Score? A rubric for ML production systems^[6]. Eric Breck, Shanqing Cai, Eric Nielsen, Michael Salib, D. Sculley. NIPS 2016.

3.7 Data Platform for Machine Learning

本文介绍了一种专门为所有机器学习（ML）数据集设计的数据管理系统MLdp。ML应用程序提出了一些不同于常规数据处理应用程序的独特要求，包括但不限于：数据谱系和来源跟踪、丰富的数据语义和格式、与各种ML框架和访问模式的集成、基于试验和错误的数据探索和演化、快速实验、模型训练的可重现性、严格的合规性和隐私法规等。当前的ML系统/服务通常关注ML算法，但没有集成的数据管理系统。相反，它们要求用户自行提供数据并自行管理数据，存储在Blob存储或文件系统中。数据管理任务的负担，如版本管理和访问控制，由用户承担，而不是所有的合规性特性，如使用条款、隐私措施和审计，都是可用的。MLdp为各种数据提供了一个简洁而灵活的数据模型，强大的版本管理以确保ML实验的可重复性，并与主要的ML框架集成。MLdp还维护数据来源，以帮助用户跟踪其ML流程中数据版本和模型之间的谱系和依赖关系。除了一些基本功能，如安全性、可用性和可伸缩性，MLdp的内部设计选择受到了支持快速ML实验迭代的目标的强烈影响，这些迭代包括数据发现、数据探索、特征工程、模型训练、模型评估和数据发现。

Data Platform for Machine Learning^[7]. Pulkit Agrawal, Rajat Arya, Aanchal Bindal, Sandeep Bhatia, Anupriya Gagneja, Joseph Godlewski, Yucheng Low, Timothy Muss, Mudit Manu Paliwal, Sethu Raman, Vishrut Shah, Bochao Shen, Laura Sugden, Kaiyu Zhao, Ming-Chuan Wu∗. SIGMOD 2019.

3.8 AI Reliability and Trust through ModelOps

本文提出了一个基于云的框架和平台，用于端到端开发和生命周期管理人工智能（AI）应用程序。这里基于我们先前在云管理深度学习服务的平台级支持工作，并展示了如何利用软件生命周期管理的原则，以实现AI管道的自动化、信任、可靠性、可追溯性、质量控制和可重复性的扩展。通过讨论使用案例和当前挑战，本文描述了管理AI应用程序生命周期及其关键组件的框架。同时，本文还展示了具体示例，说明了这一框架如何使管理和执行模型训练和持续学习管道与可信AI原则相结合。

ModelOps: Cloud-based Lifecycle Management for Reliable and Trusted AI^[8]. Waldemar Hummer, Vinod Muthusamy, Thomas Rausch, Parijat Dube, Kaoutar El Maghraoui. IC2E 2019.

3.9 MLOps from a Data Quality Perspective

开发机器学习模型可以看作是类似于传统软件开发已建立的过程。两者之间的一个关键区别在于机器学习模型的质量与用于训练或执行评估的数据质量之间存在密切依赖关系。这项工作演示了数据质量的不同方面如何在机器学习开发的各个阶段传播。通过对已知数据质量维度和下游机器学习流程影响的联合分析，本文展示了典型MLOps管道的不同组件可以进行高效设计，提供了技术和理论视角。

A Data Quality-Driven View of MLOps^[9]. Cedric Renggli, Luka Rimanic, Nezihe Merve Gürel, Bojan Karlaš, Wentao Wu, Ce Zhang. IEEE Data Engineering Bulletin 2023.

3.10 A Survey to study the Significance of MLOps in Data Scientists' Work

遵循持续软件工程实践，对快速部署机器学习（ML）特征，即MLOps，产生了越来越大的兴趣。研究人员在本文中研究了MLOps在数据科学家日常活动中的重要性，基于一项调查，在该调查中，研究人员收集了来自ML领域63个不同国家的331名专业人员的回应，回应显示他们在过去三个月内的工作重点。根据结果，高达40%的受访者表示他们同时处理模型和基础架构；大部分工作集中在关系型和时间序列数据；需要解决的问题的最大类别包括预测分析、时间序列数据和计算机视觉。最大的问题涉及数据，尽管也有一些意识到与将模型部署到生产环境和相关流程有关的问题。研究人员假设，根据调查中的组织可以分为三类：(i)弄清如何最好地使用数据；(ii)专注于构建第一个模型并将其投入生产；(iii)管理多个模型、它们的版本和训练数据集，以及重新训练和频繁部署重新训练的模型。根据结果，大多数受访者属于第一类或第二类，专注于数据和模型；然而，MLOps的好处只有在第三类中才能显现，那里需要频繁的重新训练和部署。因此，当组织从ML作为概念验证转向ML作为正常活动的一部分时，建立MLOps流程是自然的一步。

Who Needs MLOps: What Data Scientists Seek to Accomplish and How Can MLOps Help?^[10]. Sasu Mäkinen, Henrik Skogström, Eero Laaksonen, Tommi Mikkonen. WAIN 2021.

3.11 Definitions, Tools, and Challenges of MLOps

本文是机器学习操作（MLOps）领域的概述。研究人员的目标是通过强调当前的问题和趋势，定义这种系统的运作和组件。在这个背景下，研究人员介绍不同的工具及其实用性，以提供相应的指导方针。此外，还识别了MLOps和AutoML（自动化机器学习）之间的关联，并提出了这种组合的工作方式。

MLOps -Definitions, Tools and Challenges^[11]. G. Symeonidis, E. Nerantzis, A. Kazakis, G. A. Papakostas. CCWC 2022.

3.12 An overview of the necessary principles, components, and roles

所有工业机器学习（ML）项目的最终目标是开发ML产品并快速投入生产。然而，自动化和运营ML产品具有极高的挑战性，因此许多ML项目未能达到预期的效果。机器学习操作（MLOps）范式应对了这一问题。MLOps包括许多方面，如最佳实践、概念集和开发文化。然而，MLOps仍然是一个模糊的术语，对于研究人员和专业人员而言其影响尚不明确。为填补这一差距，研究人员进行了混合方法研究，包括文献综述、工具审查和专家访谈。通过这些调查，研究人员提供了MLOps所需原则、组件和角色的综合概述，以及相关的架构和工作流程。此外，研究人员提供了MLOps的定义，并突出了该领域的开放性挑战。最后，本研究为希望使用一组指定的技术自动化和运营其ML产品的ML研究人员和从业者提供了指导。

Machine Learning Operations (MLOps): Overview, Definition, and Architecture^[12]. Dominik Kreuzberger, Niklas Kühl, Sebastian Hirschl. IEEE Access 2023.