MLOps的概念、原则和实践

MLOps

什么是MLOps

MLOps（Machine Learning Operations）是一组用于数据科学家和运维人员之间协作和沟通的最佳实践。应用这些实践可以提高质量，简化管理流程，并在大规模生产环境中自动部署机器学习和深度学习模型，使模型与业务需求以及规则要求保持一致变得更加容易。

MLOps的概念本身也在发展之中，不同的公司对他的描述也不一样,但基本都是沿用DevOps的思路来定义。

Google：MLOps是一种机器学习工程文化和做法，旨在统一机器学习系统开发（Dev）和机器学习系统运维（Ops）。实施MLOps意味着您将在机器学习系统构建流程的所有步骤（包括集成、测试、发布、部署和基础架构管理）中实现自动化和监控。
Microsoft：MLOps是基于可提高工作流效率的DevOps原理和做法。目标是更快试验和开发模型，更快地将模型部署到生产环境，质量保证和端到端世系跟踪。
Amazon：ML考虑了AI/ML项目在项目管理、CI/CD和质量保证方面的独特方面，帮助客户缩短交付时间，减少缺陷并提高数据科学家的工作效率。

MLOps
机器学习、数据工程和 DevOps 都在这个领域融合在一起。换句话说，它将机器学习与设计，构建和维护系统的任务联系起来。

MLOps=ML+Dev+Ops
MLOps是一套方法架构，一套可持续、可问责、可重现的、可非同步合作的机器学习开发运行方法。
数据科学界普遍认为，它是围绕机器学习的最佳实践和指导原则的总称，而不是单一的技术解决方案。
广义来说，是企业更有系统性地去运用数据的方法，MLOps是落地AI策略的基本功。

为什么需要MLOps

MLOps的目标是减少技术摩擦，使模型在尽可能短的时间内将想法投入生产，同时尽可能降低风险。

生产环境中机器学习模型的使用是很困难的。机器学习生命周期由许多复杂的组件组成，例如数据引入、数据准备、模型训练、模型调优、模型部署、模型监视、可解释性等等。它还需要跨团队的协作和交接，从数据工程到数据科学再到ML工程。当然，它需要严格的操作严谨性，以保持所有这些流程的同步和协同工作。MLOps包括机器学习生命周期的试验、迭代和持续改进。

Google于2015年在NIPS上发表了《Hidden Technical Debt in Machine Learning Systems》。论文作者提出，如今大量机器学习库和框架方便易用，但由于缺乏系统化的理论指导导致形成了大量技术债务，在生成环境中面临高昂的维护成本。

业务实践过程中可以看到，很多同学过分关注在算法的优化上，似乎只求在‘正常’的情况下稳定工作即可，对整个系统的问题视而不见。

真实的机器学习系统

AI产业化时代，机器学习技术越来越多应用到各个领域，如何构建一个稳定可靠的机器学习系统变得至关重要。

MLOps Vs DevOps

DevOps是指将软件开发的开发，测试和运维结合在一起。MLOps从DevOps中获取了许多原则，DevOps是首先被提出，并被引入到简化机器学习生命周期的方法。

相似之处

DevOps和MLOps都是关于简化流程的。DevOps将软件开发的开发、测试和运维结合在一起。它旨在将这些孤立的流程转变为组织内一组连续的内聚步骤。同样，MLOps是用于从头到尾简化机器学习生命周期的方法。它旨在弥合设计，模型开发和运维之间的差距，以缩短ML开发中的周转时间。
DevOps和MLOps是关于沟通的。对于DevOps而言，清晰的沟通对于流程自动化、持续交付和反馈循环至关重要，因为它依赖于部门之间的顺利合作以及一组以可见方式巩固和促进这些流程的工具（例如，CI/CD 系统）。对于 MLOps 而言，沟通是系统管理员、数据科学团队和整个组织中其他部门之间协作的基础，从而对如何开发和维护生产模型达成共识。

差异之处

版本控制：通过 DevOps，代码版本控制可用于确保有关对正在开发的软件所做的任何更改或调整的清晰文档。然而，对于机器学习，代码并不是唯一不断变化的输入。数据是需要管理的另一个关键输入，参数、元数据、日志以及最后的模型也是如此。
所需硬件：训练机器学习模型，尤其是深度学习，往往是非常计算密集型的。对于大多数软件项目来说，构建时间是完全无关紧要的，因此完成构建的硬件也是无关紧要的。然而，较大的模型可能需要数小时到数周的时间来训练，即使在云供应商提供的大多数GPU机器上也是如此，这意味着MLOps设置需要更复杂地管理哪种机器。
持续监控：监控也是良好 DevOps 实践的一部分。在过去几年中，站点可靠性工程（SRE）风靡一时，凸显了监控在软件开发中的重要性。DevOps和MLOps中的监控之间的区别在于，软件不会降级，而机器学习模型会降级。将模型部署到生产环境后，它开始从现实世界接收的新数据生成预测。这些数据将随着业务环境的变化和调整而继续变化和调整，从而导致模型退化。MLOps 提供了促进持续监视和重新训练的过程，以便算法可以继续在生产中使用。

随着机器学习成为许多软件产品的标准部分，DevOps和MLOps可能会合并，数据版本控制和持续训练管道等内容被添加到现有的技术堆栈中。
MLOps概念可能会建立在DevOps堆栈之上

Model-centric VS Data-centric

吴恩达老师21年3月开了一个直播讲： A Chat with Andrew on MLOps: From Model-centric to Data-centric AI。吴恩达认为在一个AI 系统中，数据质量要比模型本身更重要，与其更强调调优模型，不如尽可能地清理数据。在钢板缺陷检测任务当中，baseline准确率为76.2%，各种换模型调参数之后，对准确率几乎没有提升。但是对数据集的优化却将准确率提升了16.9%，其它项目的经验也证明了这点。
improving the code vs the data

Model-centric: 以调整模型代码、调优模型超参数为主的系统调优策略，在这种策略下，可以认为数据集是固定的。
Data-centric: 与Model-centric相对，以调整数据集为主的系统调优策略，在这种策略下，可以认为模型是固定的（只对数据集作适应性调整）
Making it systematic: MLOps

机器学习工作流

机器学习项目的目标是通过使用收集的数据并对其应用机器学习算法来构建统计模型。因此，每个基于 ML 的软件都包含三个主要组件：数据、模型和代码。与这些组件相对应，典型的机器学习工作流由三个主要阶段组成：

数据工程（Data Engineering）：数据采集和数据准备
模型工程（Model Engineering）：ML模型训练和服务
代码工程（Code Engineering）：将ML模型集成到最终产品中

数据工程Data

任何数据科学工作流的初始步骤都是获取和准备要分析的数据，通常，数据是从各种数据源集成的，并且具有不同的格式。数据准备是一个迭代和敏捷的过程，用于探索，组合，清理原始数据并将其转换为建模需要的数据集，用于数据集成，数据科学，数据发现和分析/商业智能（BI）等场景。尽管数据准备只是一个中间阶段，但该阶段在资源和时间方面的投入是最大的。数据准备是数据科学工作流中的一个关键活动，因为这一阶段的错误会传播到下一阶段，导致从数据中挖掘出错误的知识。

数据工程管道包括对可用数据的一系列操作，这些操作导致为机器学习算法提供训练和测试数据集：

数据摄取：使用各种框架和格式（如 Spark、HDFS、CSV 等）收集数据。此步骤还可能包括综合数据生成或数据扩充。
探索和验证：包括数据探查，以获取有关数据内容和结构的信息。此步骤的输出是一组元数据，例如最大值、最小值、平均值。数据验证操作是用户定义的错误检测函数，用于扫描数据集以发现某些错误。
数据清理：重新格式化特定属性和更正数据中的错误（如缺失值插补）的过程。
数据标记：数据工程管道的操作，其中每个数据点都分配给特定类别。
数据拆分：将数据拆分为训练、验证和测试数据集，以便在核心机器学习阶段使用以生成ML模型。

模型工程Model

机器学习工作流的核心是编写和执行机器学习算法以获取机器学习模型的阶段。“模型工程”管道包括许多生成最终模型的操作：

模型训练：对训练数据应用机器学习算法以训练 ML 模型的过程。它还包括特征工程和模型训练活动的超参数调优。
模型评估：验证训练的模型，以确保其满足原始编纂的目标，然后再将生产中的 ML 模型提供给最终用户。
模型测试：使用保留测试数据集执行最终的“模型验收测试”。
模型打包：将最终 ML 模型导出为特定格式（例如 PMML、PFA 或 ONNX）的过程，用于描述模型，以便业务应用程序使用。

代码工程Code

一旦我们训练了机器学习模型，我们就需要将其部署为业务应用程序（如移动或桌面应用程序）的一部分。机器学习模型需要各种数据点（特征向量）来生成预测。机器学习工作流程的最后阶段是将以前设计的机器学习模型集成到现有软件中。此阶段包括以下操作：

模型服务：在生产环境中处理机器学习模型组件的过程。
模型性能监视：根据实时和以前未见过的数据（如预测或建议）观察模型性能的过程。特别是，我们对ML特定的信号感兴趣，例如预测与先前模型性能的偏差。这些信号可以用作模型重新训练的触发器。
模型性能日志记录：每个推理请求都会生成日志记录。

流水线Pipeline

在任何机器学习项目中，定义业务用例并确定成功标准后，将机器学习模型交付给生产环境的过程涉及以下步骤。
这些步骤可以手动完成，也可以由自动流水线完成。
机器学习工作流

数据提取：为机器学习任务选择和集成来自各种数据源的相关数据。
数据分析：执行探索性数据分析 (EDA) 以了解可用于构建机器学习模型的数据。此过程将产生以下结果：1）了解模型预期的数据架构和特性，2）识别模型所需的数据准备和特征工程。
数据准备：为机器学习任务准备数据。此准备工作涉及数据清理，即将数据拆分为训练集、验证集和测试集。还可以将数据转换和特征工程应用于解决目标任务的模型。此步骤的输出是准备格式的数据分片。
模型训练：数据科学家使用准备好的数据实现不同的算法，以训练各种机器学习模型。此外，还需要对实现的算法进行超参数调节，以获得最佳机器学习模型。此步骤的输出是经过训练的模型。
模型评估：在保留测试集上评估模型，以评估模型质量。此步骤的输出是一组用于评估模型质量的指标。
模型验证：模型已确定适合部署 - 它的预测性能优于特定基准。
提供模型：经过验证的模型会部署到目标环境以提供预测。此部署可以是以下其中一项：1）具有 REST API 的微服务，可用于提供在线预测。2）边缘设备或移动设备的嵌入式模型。3）批量预测系统的一部分。
模型监控：监控模型预测性能，以便在机器学习过程中潜在调用新的迭代。

这些步骤的自动化级别决定了机器学习过程的成熟度，成熟度反映了使用新数据训练新模型或者使用新实现训练新模型的速度。以下部分介绍了三个级别的 MLOps，从最常见的级别（该级别不涉及自动化）开始，一直到自动执行机器学习和 CI/CD 流水线。

MLOps的成熟度级别

MLOps级别 0：手动过程

许多团队都有数据科学家和机器学习研究人员，他们可以构建领先的模型，但他们构建和部署机器学习模型的过程完全是手动的。这样的级别被视为基本成熟度级别（级别 0）。

下图展示了此过程的工作流。
将模型用作预测服务的手动机器学习步骤

特性

Pipeline中每个步骤（包括数据分析、数据准备、模型训练和验证）都是交互式手动的过程，一般是指在jupyter中编写和执行的实验性代码驱动，直到生成有效的模型为止。
创建模型的数据科学家和将模型用作预测服务的工程师是分开的，数据科学家将训练好的模型交付给工程团队，以便在其API基础架构上进行部署，这可能会导致训练-应用偏差。
不频繁发布迭代，模型一年仅部署几次。
因为模型基本不做更改，因此无CI/CD。
部署指的是预测服务，而不是整个机器学习系统。
没有记录模型预测的数据，缺少模型性能下降和其他模型行为偏移检测所必要的信息，缺少主动性能监控

挑战
MLOps 级别 0 在许多开始将机器学习应用于其用例的企业中很常见。如果难得更改或训练模型，则由数据科学家驱动的此手动过程可能就足够了。实际上，在现实环境中部署模型时，模型通常会失效。模型无法适应环境的动态变化或描述环境的数据的变化。如需战胜这些挑战并保持模型在生产环境中的准确性，您需要执行以下操作：

在生产环境中主动监控模型的质量
频繁地重新训练生产模型
不断尝试新的实现以生成模型

为了战胜此手动过程的挑战，CI/CD 和 CT 的 MLOps 做法很有用。通过部署机器学习训练流水线，您可以启用CT，并且可以设置 CI/CD 系统以快速测试、构建和部署机器学习流水线的新实现。

MLOps级别 1：ML 流水线自动化

级别1的目标是通过自动执行机器学习流水线来持续训练模型；这样可以持续交付模型预测服务。如需自动执行在生产环境中使用新数据重新训练模型的过程，您需要在流水线中引入自动化数据和模型验证步骤，以及流水线触发器和元数据管理。

下图是针对 CT 的自动化机器学习流水线的示意图。
针对 CT 的机器学习流水线自动化

特性

机器学习pipeline中的各个步骤都被编排过，步骤之间的转换是自动执行的，可以快速迭代实验。
实验环境测试好的pipeline，可以在生产环境中根据实时pipeline触发器使用新数据自动训练模型，可以实现生产环境中模型的CT。
实验环境中使用的pipeline实现会在预生产和生产环境中使用，实验与运维之间具有一致性。
机器学习pipeline中各个组件是可重复使用、可组合、并且可能可以跨pipeline共享，pipeline是被组件化的。
生成环境的模型训练可以例行化的执行，修改过的pipeline可以自动基于最新版的数据进行训练并持续交付。
部署的不仅仅是把预测服务部署到生产环境，而且包括把整个训练pipeline部署生产环境。

实现CT需要依赖的组件

数据和模型验证：开始训练之前，需要检查是否存在数据结构偏差或者数据值的偏差；训练结束之后，需要在验证集上进行模型评估，上线过程要走灰度发布并走AB测试。
Feature Store：一个集中式存储区，可以在其中对特征的定义、存储和访问进行标准化处理，以方便训练和提供服务。需要为特征值提供高吞吐量批量服务和低延时实时服务的API，以及支持训练和服务工作负载。
元数据管理：记录有关机器学习流水线每次执行情况的信息，以帮助实现数据和组件沿袭、可重现性以及比较。
pipeline任务调度：可以自动执行机器学习pipeline，根据场景使用最新数据进行模型训练。可以手动触发也可以定时触发，或者其他条件触发新模型训练。

挑战
假设pipeline的新实现不经常部署，并且我们只管理几个管道，那么通常需要手动测试和部署pipeline及其组件。此外，还需要将pipeline的测试源代码提交给IT团队，以部署到目标环境，这种设置适用于基于新数据（而不是基于新的ML想法）部署新模型的情况。

但是，您需要尝试新的ML想法并快速部署ML组件的新实现。如果在生产环境中管理多个ML管道，则需要CI/CD设置来自动执行pipeline的生成、测试和部署。

MLOps级别 2：CI/CD 流水线自动化

如果需要在生产环境中快速、可靠的更新pipeline，那么我们就需要一个可靠的自动化CI/CD系统，让数据科学家可以快速探索有关特征工程、模型架构和超参数的新想法。数据科学家可以实现这些想法，并自动构建、测试新的pipeline组件并将其部署在目标环境。

下图显示了使用 CI/CD 的机器学习流水线的实现，它具有自动化机器学习流水线设置的特性以及自动化 CI/CD 例程。
CI/CD 和自动化机器学习流水线。

为了MLOps级别2的水平，需要依赖以下组件：

源代码控制
测试和构建服务
部署服务
模型注册表
特征存储区
机器学习元数据存储区
机器学习流水线任务调度器

特性

下图展示了机器学习 CI/CD 自动化流水线的各个阶段：

流水线包括以下阶段：

开发和实验：在已经编排好机器学习各个步骤的流水线上，反复尝试新的机器学习算法和新的建模方案。这个阶段的输出是机器学习流水线各个步骤的的源代码，最后都会被统一推送到源代码库中。
流水线持续集成：构建源代码并运行各种测试。这个阶段的输出是要在后续阶段部署的流水线组件（软件包、可执行文件和工件）。
流水线持续交付：可以将CI阶段生成的组件部署到目标环境。此阶段的输出是已部署的流水线，其中包含模型的新实现。
自动触发：流水线会根据时间表或响应触发器而自动在生产环境中执行。此阶段的输出是已推送到模型注册表并且经过训练的模型。
模型持续交付：您可以将经过训练的模型用作预测服务。此阶段的输出是已部署的模型预测服务。
监控：可以实时收集模型性能的统计信息。此阶段的输出是用于执行流水线或执行新实验周期的触发器。

在流水线开始实验的新迭代之前，数据分析步骤仍然是数据科学家手动执行的过程。模型分析步骤也是手动执行的过程。

MLOps的原则

自动化Automation

在整个workflow中所有可以自动化的环节，我们都应该进行自动化，从数据的接入到最后的部署上线。
automated ML pipeline with CI/CD routines

持续化Continuous X

一说起DevOps，大家就很容易联想到CI/CD，也从侧面印证这条原则的重要性。MLOps在持续集成，持续部署，持续监控的基础上，还增加了持续训练的概念，即模型在线上运行过程中可以持续得到自动化的训练与更新。我们在设计开发机器学习系统时，要持续思考各个组件对“持续”性的支持，包括流程中用到的各种artifacts，他们的版本管理和编排串联等。

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

持续集成Continuous Integration (CI)：不仅仅是对代码（Code），还包括对数据（Data）和模型的持续测试和验证。
持续交付Continuous Delivery (CD)：不仅仅对软件包进行持续部署，还包括对预测服务的持续部署和更新（因为更新预测服务有时候是只更新模型，有时候是模型和数据一起更新，并不更新代码）
持续训练Continuous Training (CT)：这是机器学习所特有的，需要对模型进行自动的持续训练
持续监控Continuous Monitoring (CM)：不只是监控服务的可用性，还需要监控预测服务的准确性、召回率等性能指标，如果有下降可能触发持续训练。

版本控制Versioning

版本化管理也是DevOps的重要最佳实践之一，在MLOps领域，除了pipeline代码的版本管理，数据，模型的版本管理属于新涌现的需求点，也对底层infra提出了新的挑战。
数据版本控制工具

实验追踪Experiment Tracking

实验管理可以理解为version control中commit message的增强。对于涉及模型构建相关的代码改动，我们都应该能记录当时对应的数据，代码版本，以及对应的模型artifacts存档，作为后续分析模型，选择具体上线的版本的重要依据。

测试Testing

机器学习系统中主要涉及到3种不同的pipeline，分别是数据pipeline，模型pipeline和应用pipeline（类似于模型与应用系统的集成）。针对这3个pipeline，需要构建对应的数据特征测试，模型测试以及应用infra测试，确保整体系统的输出与预期的业务目标相符，达到将数据insights转化为业务价值的目的。

这方面Google的ML test score是一个很好的参考。《The ML Test Score:A Rubric for ML Production Readiness and Technical Debt Reduction》
传统的系统测试和监控 VS 基于ML的系统测试和监控

Google Data/Model/Infra/Monitor监控列表

监控Monitoring

监控也是一项软件工程的传统最佳实践。上面提到的ML test score中也有一部分是与监控相关。除了传统的系统监控，例如日志，系统资源等方面外，机器学习系统还需要对输入输出数据，模型相关指标进行监控，确保预测的质量和效率，并在出现异常情况时自动触发一些应对机制，例如数据或模型的降级，模型的重新训练与部署等。

下图显示可以通过跟踪模型预测的精度、召回率和 F1-score 以及时间来实现模型监控。精度、召回率和 F1 分数的降低会触发模型重新训练，从而使模型恢复之前的效果。
监控Monitoring

可复现Reproducibility

与传统软件系统的确定性行为不同，机器学习中带有不少“随机化”的成分，这对各种问题的排查，版本回滚，输出效果的确定性都提出了一定的挑战。因此我们在开发过程中也需要时刻将可复现原则放在心上，设计相应的最佳实践（如设定随机数种子，运行环境等各类依赖的版本化等）。

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

MLOps实践

机器学习框架
离线框架
离线关键问题:快速迭代，高效开发

业务/模型分离
逻辑/工具分离

离线框架方向

灵活支持多个APP
快速、灵活支持数据、特征迭代

模型平台
模型平台关键问题:大数据量，快速尝试新模型

分布式机器学习平台

模型平台发展方向

高效
快速支持新模型迭代对业务透明

在线排序
在线关键问题:可拓展，高性能

可配置的特征抽取模块
支持多业务线的方案

在线计算平台方向

作为一种资源，对应用透明
高效可依赖(高并发、短时延)

管道和流程的自动化

能够快速部署，稳定工作流程（触发训练、部署以及运行等工作）快速运行。

在调度过程中，定义两个组件Job和Flow，抽象工作流的各个步骤和依赖关系
Job：机器学习流水线的一个步骤

<?xml version="1.0"?>

<configuration xmlns:xi="http://www.w3.org/2001/XInclude">

  <xi:include href="../application.xml"/>

  <property>
    <name>flow.job.name</name>
    <value>feature.ad</value>
  </property>

  <property>
    <name>job.name</name>
    <value>${application.package}.${flow.job.name}: ${bizdate}</value>
  </property>

  <property>
    <name>inputs.dir</name>
    <value>${application.output}/${raw.ad.version}/${bizdate}/raw/ad</value>
  </property>

  <property>
    <name>output.dir</name>
    <value>${application.output}/${feature.ad.version}/${bizdate}/feature/ad</value>
  </property>

</configuration>

Flow：各个步骤之间的依赖关系。

<?xml version="1.0"?>

<flow name="feature">

  <node>
    <name>raw.ad</name>
  </node>

  <node>
    <name>feature.ad</name>
    <dependencies>raw.ad</dependencies>
  </node>

</flow>

数据和模型版本管理

在机器学习项目中，数据科学家不断致力于开发模型，这个过程需要尝试不同的数据、参数和算法组合。一个可以新旧实验中来回进行的环境是非常重要的，可以做有效对比。

通过路径区分版本
Version：配置当前flow的各个步骤

<?xml version="1.0"?>
<configuration>

  <property>
    <name>application.version</name>
    <value>v1</value>
  </property>

  <property>
    <name>raw.ad.version</name>
    <value>${application.version}</value>
  </property>

  <property>
    <name>feature.ad.version</name>
    <value>${application.version}</value>
  </property>

</configuration>

用于机器学习的CI/CD

MLOps = ML + DEV + OPS

持续集成（CI）
ML中的持续集成意味着每次更新代码或数据时，ML管道都会重新运行，这是以所有内容都是版本化和可重现的方式完成的，因此可以跨项目和团队共享代码库。每次重新运行都可能包括训练、测试或生成报告，从而更容易在生产环境中其他版本之间进行比较。

持续部署（CD）
持续部署是一种将新版本自动部署到生产环境或任何环境的方法。这种做法更容易接收用户的反馈，因为变换更快、更稳定，以及用于再训练或新模型的新数据。

实践：统一线上线下的特征抽取模块：
线上线下公用一套特征抽取模块，线上server定期加载模型，离线训练好的模型+配置+特征抽取的so一起推送到线上的服务器。

代码的一致性(即处理流程一致性)：不同语言即使是相同的代码逻辑和运算方法，也可能存在语义上的不一致性，所以必须在Online和Offline使用同一套代码。我们使用C++将特征抽取的代码封装在一个so中，Online编译时链接这个so，Offline使用Java的JNI技术调用so中的代码。
配置的一致性：要实现灵活的特征抽取而不是每次都去修改代码，就需要将特征抽取的过程做成可配置化的，我们首先在代码内部建立字母代号和特征抽取的映射关系，这样单特征我们用字母表示，组合特征的配置就可以直接使用多个字母的组合表示，使得整个特征抽取的逻辑可配置度非常高。
数据的一致性：输入数据的结构也需要Online和Offline一致，我们将特征抽取的输入定义成一个Protobuf的格式，线上线下都向同一个protobuf填充数据。