1.3　ML的工程挑战与MLOps解决方案

在实际ML工程实践场景中，我们发现大量的工作停留在数据科学家/ML工程师的个人电脑中，自动化程度几乎为零，团队协作也是一团糟，生产涉及的管道是用自制的及脆弱的脚本组合起来的。当需要将模型从开发环节通过部署和中心化处理过渡到生产环节时，可视化操作和模型的运维管理几乎不存在，持续集成和持续部署在很多从业者的技术栈中也极少涉及，模型版本化、数据版本化及服务版本化对许多企业来说甚至难以定义，严格的模型健康和性能监测也极为罕见，这样的例子还有很多。

在传统软件工程领域，软件工程团队的所有最佳实践都集中在代码上。同样，ML工程师也需要处理大型代码库，但除此之外，他们还需要处理数据和模型。ML团队面临着类似的问题，在Jupyter Notebook中运行的概念验证（Proof of Concept，PoC）脚本与在生产环境中运行的解决方案之间存在巨大的差异。具体来说，他们必须考虑：

●　存储和跟踪模型：跟踪模型的训练过程和输出用于比较的模型参数，对训练好的模型来说需要进行持久化存储，这些都属于ML工程的范畴，而在标准的软件开发中通常不会涉及。

●　大型且快速变化的数据集：虽然大多数软件通过数据库或其他来源与数据集成，但ML解决方案通常需要做更多的数据清洗和预处理，而且是在经常更新的“实时”数据集上。ML工程师需要一个系统或模块来监控和执行一系列相互关联的处理步骤，并通知相关人员进行相应的迭代工作。这正是MLOps擅长的地方，研究团队倾向于关注ML代码而不是周围的基础设施。随着协作、共享结果和在大型数据集上完成工作的需求不断增加，研究团队很快就遇到了瓶颈。MLOps解决了这些问题，并为研究团队实现他们的目标提供了必要的基础设施支持，尽管处理大型数据集、代码和ML模型很复杂。

ML是一个全新的且令人兴奋的学科，其工具和实践正在快速发展。随着ML从研究到应用业务方案的成熟，我们也需要提高ML运维流程的成熟度，以实现ML应用的闭环及快速迭代。

1.3.1　MLOps的定义

MLOps是一种ML工程文化和实践，旨在于生产中统一ML模型开发（Dev）和ML模型运维（Ops）。

DevOps是一组有助于可靠地构建、集成、测试和部署软件的实践。它可用于在开发领域以最小的部署开销实现持续集成和交付。DevOps的成功实践可以应用于ML，以构建强大的ML系统。不同的是，MLOps还需要数据工程，因为数据是构建ML的基石。数据采集、验证和特征工程等都是数据工程的关键组成部分。

通过借鉴DevOps的成功实践经验并将其应用于ML系统，MLOps的理念和方法可优化整个ML生命周期的管理，减少ML价值流中的摩擦和延迟，以缩短将业务需求转化为ML服务所需的时间，确保ML算法和系统在生产中运行良好。

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

MLOps的核心理念在于，促进模型在生产中的快速迭代，完整的反馈回路是其基本要求，以根据从部署的模型中捕获的行为来及时调整系统。由于所有活动都联系在了一起，MLOps还为人工智能的透明度和可解释性提供了基础。

需要注意的是，MLOps是一种文化和实践，类似于我们都知道的DevOps实践，而不是具体的工具。一个常见的错误是，直接进入MLOps工具领域，这是一个很容易迷失方向的领域。总之，工具应该支持实践，反之则不成立。

1.3.2　MLOps与其他Ops的区别

在传统软件开发的世界里，一套被称为DevOps的工程实践使得在几分钟内将软件部署到生产中并保持其可靠运行成为可能。DevOps依靠工具、自动化和工作流程来抽象出软件工程的复杂性，让开发人员专注于需要解决的实际问题。这种方法如今已经非常成熟，在软件开发领域已经基本成为“标配”，那么为什么这套方法论或经验不能直接应用到ML领域？

其原因在于，ML的跨领域特性延伸出了新的维度，比如，增加了一个额外的数据维度，而这个维度区分了ML和传统软件，也给开发和运维过程带来了全新的挑战。对于传统软件，几乎可以即时体现代码变化对结果的影响；但在ML中，想要看到代码变化对结果的影响需要重新训练模型。若考虑额外数据维度的影响，情况会变得更复杂，数据维度的引入不仅改变了代码在开发过程中的工作方式，而且数据本身也是在时刻变化的。

在传统软件开发中，一个版本的代码产生一个版本的软件，代码的版本决定了软件的版本。在版本控制系统的辅助下，我们可以在任何时候创建应用程序的任意变体。而ML则不是这样的，在ML中，开发的结果不是代码而是模型，而这个模型又是由创建和训练模型的代码版本及其所使用的数据产生的。一个版本的代码和一个版本的数据结合在一起产生了一个版本的ML模型。代码和数据分别处在两个平行的平面上，它们之间共享时间维度，但在所有的其他方面都是独立的。这种处在不同平面的关系也给具体的开发和应用带来了挑战，任何试图将ML模型成功投入生产的从业者都会面临这些挑战。

●　在ML项目中，除了要保存不同版本的代码，还需要一个地方来保存不同版本的数据和模型工件。ML涉及大量的实验。数据科学家使用各种数据集训练模型，并生成不同的输出。因此，除了借鉴DevOps的代码版本控制方案，MLOps还需要特定的工具来保存不同版本数据、模型工件和涉及的元数据信息，以方便后续的管理和运维。

●　与代码不同，模型性能会随着时间的推移而衰退，这就需要监控。在将训练好的模型部署到生产环境后，便开始从真实数据中产生预测。在一个稳定的环境中，模型的性能不会下降。但是，真实世界时刻在变化，我们的模型接收的实时数据也在变化，这导致的直接后果就是所谓的“模型衰退”（有时候也被称作训练服务偏移）。换句话说，它的预测的准确率可能会随着时间的推移而下降。为了防止模型性能动态衰退，我们需要持续地监测模型，这在DevOps实践中很少见。

●　训练永远不会结束。一旦发现模型性能下降，就需要用新的数据重新训练模型，并在再次投入生产前进行验证。在MLOps实践中，这种持续的训练和验证在一定程度上可以看作DevOps实践中的持续测试。

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

MLOps与DataOps

DataOps（数据运维）与MLOps的概念几乎是同时出现的，并且DataOps也从DevOps实践中借鉴了很多经验，但DataOps的核心应用对象是数据应用。DataOps涵盖了数据生命周期内的所有步骤，从数据收集、处理到分析和报告，并尽可能地将其过程自动化。它的目标是提高数据的质量和可靠性，同时尽量缩短提供数据应用所需的时间。

这种方法对处理大型数据集和复杂数据工程管道的业务场景特别有帮助。DataOps也可以在一定程度上辅助ML项目，但只是在辅助的层面上，因为它不提供管理模型生命周期的解决方案，所以可以认为MLOps是DataOps的延伸。

MLOps与AIOps

作为Ops中比较另类的一个，从字面上理解，AIOps与MLOps很相似，这其实是误解。2017年Gartner首次提出了该术语，AIOps被定义为结合大数据和ML技术实现IT运维流程的自动化方案。

从本质上讲，AIOps的目标是自动发现日常IT运维中的问题，并利用AI主动做出智能反应和预警。简单地说，AIOps是AI在Ops领域中的应用，应用的主体是Ops；而MLOps则是Ops在ML领域中的应用，应用的主体是ML。

最后，表1-1总结了MLOps的主要实践及与DevOps和DataOps实践的关系，由于AIOps是将AI技术应用于运维领域的方案，不属于严格意义上的Ops，所以表1-1中的对比仅涉及MLOps与DevOps和DataOps实践的关系。

接下来的内容将回到我们的核心主题，将更详细地探讨MLOps的基础概念。

1.3.3　谁在关注MLOps

在笔者与许多从业者交流时，发现对MLOps感兴趣的人员来自非常不同的群体。

第一类是传统企业的中高层管理人员。通常情况下，他们几乎没有ML经验，因为在许多公司内ML（甚至是大数据）仍然是相对较新的概念。他们并不完全了解什么是ML模型，以及数据科学家要做什么。但他们有着丰富的管理经验且精通业务，积极思考和应对当前的业务瓶颈，对数字化转型有着浓厚的兴趣，同时又对数字化转型是否能够帮助企业走出困境抱有疑问。他们希望能够快速PoC，以尽可能少的成本进行快速验证。

第二类对MLOps感兴趣的群体是IT技术人员和运维人员。他们的工作职责本身就属于Ops的范畴：ML模型的生产化和运维管理。IT技术人员日常工作的KPI是以他们支持的业务和在确定的预算内顺利运行系统的能力来衡量的。ML模型是一种新型的IT资产，需要特定的部署和监控程序。由于IT技术人员和运维团队还没有适当的管理和监控ML模型的经验，因此他们正在积极寻找新的和强大的方法论来解决ML模型的管理和监控问题。

最后一类群体，也是MLOps的直接受益群体，是由数据科学家、ML工程师和数据工程师组成的。当他们开发创新模型时，他们希望确保他们的工作成果能成为有价值的商业资产。数据科学家是人工智能和算法方面的专家，但他们的软件开发能力通常不太深厚，他们希望利用一种方法或工具来促进从构思到部署阶段的迭代进程。不过，随着企业对ML生产化越来越重视，数据科学家也开始被要求精通基本的软件工程技能，如代码模块化、复用、测试和版本管理等。仅让模型在本地离线的建模环境中正常运行是不够的，这也是为什么许多互联网公司在招聘时会强调工程技能，并且务实的公司更倾向于聘用ML工程师。在许多情况下，ML工程师的工作实际上也是MLOps要实现并尽量自动化的内容。

近年来，MLOps方法在行业中越来越受到重视，笔者也看到很多不同行业的公司都在积极研究和布局MLOps。虽然不同行业在实践MLOps时关注点不同，但共同点是，他们都面临着某种ML运维的挑战，他们都希望从可复制的流程中受益，以支持他们的ML项目。

在ML社区中，人们对MLOps的兴趣也越来越大。一方面，ML从业者正在寻找一个可复制的流程来自动化他们的工作。另一方面，业务线管理者和决策者希望从人工智能获益，并迅速将ML用于业务用例。在开源社区日益流行的今天，有很多开源的工具可以帮助团队快速搭建MLOps，但在考虑使用任何技术之前，重要的是退一步，先充分了解团队试图解决的问题。

1.3.4　为什么需要MLOps

在传统意义上，ML是从单个科学实验的角度来处理的，这些实验主要是由数据科学家独立执行的。然而，随着ML模型成为现实业务场景中解决方案的一部分，并对业务产生价值，我们将不得不转变视角，在强调科学原理重要性的同时，使ML模型更容易落地（投产），并支持可重复性和多方协作。

2020年5月，Valohai公司调研了330名来自业内不同公司的数据科学家、ML工程师和管理人员，了解了他们未来3个月对ML领域的关注点及面临的主要障碍。虽然20%的受访者表示他们仍然更关注ML实验和学习阶段，但50%的受访者表示他们专注于开发生产用的模型，超过40%的受访者表示他们将部署生产可用的ML模型。

对于大多数受访者来说，他们在生产中还没有实现模型的自动化持续训练、部署和模型在生产中的持续监控，这说明生产中的ML对大多数人来说相对较新。然而，从搜索引擎的搜索量和新闻报道可以看出，近年来MLOps的热度在稳步上升，说明MLOps在实践中变得越来越重要。生产模型带来了新的挑战，不仅对数据科学家，还对工程师、产品经理和运维人员组成的扩展团队提出了新的挑战，这些挑战需要这些不同团队的协作来应对，而MLOps给这种协作提供了可行的方案。

在实际应用中，底层数据不断变化，需要重新训练模型，甚至需要重建整个ML管道以解决数据变化带来的模型漂移问题，数据变化可能是业务或用户行为的变化导致的。对于ML模型的搭建，以实现根据输入数据输出预测结果，做到这一点很容易。但是，搭建一个可靠、快速、可迭代且可供大量用户使用的ML模型却很困难。而这恰恰是MLOps擅长的，MLOps是关于模型产品化的，帮助从业者将模型从研究环境部署到生产环境。进一步地，我们把搭建MLOps（平台/框架）的必要性总结如下。

●　对于一个典型的ML项目，其开发过程是从数据工程开始的，包括数据采集、清洗、预处理，紧接着需要进行特征提取，这是一个迭代过程，为了高效和安全地完成这个过程，需要有可重复使用的管道和断点检查。

●　下一步是建立模型，这需要进行实验。随着实验的进行，有必要跟踪实验中模型的参数、评估指标和超参数，这有助于我们进一步调整参数。

●　一旦模型开发完成，就需要被部署到某个环境（如开发环境）中，在其中可以进行模型验证。

●　如果验证成功，模型将会被部署到生产环境中，在其中需要监控模型性能，以及数据漂移、模型漂移等情况。

1.3.5　MLOps给企业带来的增益

MLOps对企业能提供什么帮助呢？在20世纪90年代初期，软件工程是孤立的和低效的。在那个年代，软件的发布需要几个月的时间，且主要由手动完成。而现在，随着DevOps技术的不断发展和实践，软件可以在分钟级（甚至秒级）内发布，这是因为涉及的步骤是模块化和自动化的。当前，对于很多企业，尤其是传统企业来说，他们使用ML的情况与20世纪90年代的软件类似：模型的创建是孤立的、低效的，需要几个月的时间才能投入生产，并且涉及大量人工参与的步骤。最近几年，随着业界对人工智能关注度逐步提高（尤其是大量传统企业开始在数字化转型上大举投资），软件工程的DevOps所带来的便利也开始被借鉴到ML的应用中，MLOps有助于为那些希望从数字化转型中获得更多价值的企业降低转型的门槛。

●　为数据科学家节省更多的时间来开发新模型。对于很多企业，为了实现ML模型的落地，通常需要ML工程师或数据科学家配合其他团队来实现模型的生产化。而有了MLOps后，ML模型的生产化过程更像流水线，数据科学家在使用MLOps工具开发模型后会自动流转到下一个环节，然后像车间流水线一样一个环节扣着一个环节，直至模型进入生产环境。MLOps辅助实现ML工程化的环节，而数据科学家可以专注于他们的核心算法任务。

●　缩短ML模型的上市时间。MLOps方案会将模型训练和持续训练过程自动化，将持续集成和持续部署功能模块化，用于部署和更新ML流水线。因此，基于MLOps的解决方案可以将ML模型更快地投入生产。

●　更好的用户体验。由于MLOps实践，如持续训练和模型监控，由ML驱动的应用可以得到及时更新，加快策略的迭代优化，可以有效提高客户满意度。

●　预测的质量更高。MLOps的模型监控功能负责数据和模型的验证，评估模型在生产中的性能，并为持续训练及时发送信号。这将有助于消除建模时的错误理解和模型衰退产生的风险，并确保可以充分信任迭代后的模型所产生的结果。

MLOps可以成功应用于商业，由于数据科学家一般不具备工程师的专业知识来实现模型投产过程中的工程部分，使用MLOps可以降低数据科学家的工作难度，这在实际项目中会有很大的意义，为数据科学家节省大量的时间。在科研领域MLOps也可以同样发挥价值，如实现学术上的结果可重复性便是一个痛点。举个例子，某学者在期刊杂志上发表的文章的实证部分公开了数据和算法细节，但在使用文章中的信息自行实现时，读者会发现，结果与文章中给出的结果相差甚远，这种情况可能是作者在运算时做了大量的实验但并未记录每次实验的信息，提交到文章中的结果可能是这些实验中表现较好的那次实验的结果。如果使用MLOps的实验跟踪功能，这个问题便可迎刃而解。

1.3.6　MLOps的工作流程

如图1-5所示，MLOps的工作流程是由一系列ML管道（有时候也叫流水线）组成的，ML管道是处理数据集时所涉及步骤的序列。管道由步骤组成，每个步骤都是一个独立的实体，每个实体都会接收输入并在进行相应的处理后产生输出，该输出由执行顺序决定是否作为下一个步骤的输入。

第一步，ML管道的工作通常从数据准备开始，然后将准备好的数据存储到相应的存储设备上。

第二步，在接下来的特征工程步骤中，将会从数据存储设备中获取准备好的数据，进行缺失数据填补、特征提取、特征转换、降维、样本分割等工程操作。

第三步，特征工程完成后会流转到模型开发步骤，即将特征工程步骤输出的特征“喂给”模型来进行开发和训练。

第四步，进行模型部署，向业务系统或第三方提供推理服务（通常以REST API的形式提供）。这里的服务指的是通过将模型部署为在线服务来接收实时请求并返回预测结果，模型投产从这一步骤开始。

第五步，这也是ML项目周期的最后一步，在模型部署并上线发布后，将进入模型监控步骤，该步骤会对生产中的模型性能进行评估，在模型衰退到性能的预设阈值时，会触发模型重新训练作业，然后开始新的周期。

在实践中，通常会将模型的训练和部署过程分开操作，在MLOps工作流程里，模型开发训练及之前的步骤属于“ML”的范畴，模型部署及之后的步骤属于“Ops”的范畴。

当我们在生产中部署一个模型时，通常会部署训练阶段产生的结果。比如，特征工程沉淀下来的规则及训练好的模型，有时候还需要对实时特征与存量特征进行合并和计算。当数据分布发生偏移或生产中的模型性能下降到一定程度时，我们还需要收集最新数据来进行模型的更新，生产中通常的做法是对训练管道进行离线更新，在模型部署环节则需要热部署，即需要在工程上实现不停机的情况下更新模型服务。模型投产后还需要对数据分布、模型性能及服务状态等方面进行监控，具体细节在后面的章节中会详细介绍。

1.3.7　MLOps工程师需要具备的技能

与传统软件开发工程师的技能要求相比，MLOps工程师除了需要具备坚实的编程能力，还需要具备ML专业知识，包括使用Scikit-Learn、TensorFlow、Keras等ML框架的经验。

此外，MLOps工程师也要有ML管道的创建、扩展及将ML模型生产化的经验，还要有帮助企业落实架构、系统等的能力，以确保ML模型的顺利部署。

要成功部署ML模型，很大程度上取决于代码和数据这两个关键因素。MLOps工程师需要了解这两者的关系。数据是来自真实世界的信息，会不断变化；代码则是在受控的环境中开发出来的架构与系统，而融合数据和代码生产出对业务有价值的模型是ML流程的重要挑战。

另外，企业的ML应用是为了满足业务需求，因此MLOps工程师也需要注意业务相关的KPI，需要密切跟踪这类KPI，并优化ML模型，确保对ML的投资能带来足够高的回报。

接下来，从职责描述和技能要求的角度给出一些参考。

（1）职责描述

●　为ML模型的开发、训练、部署、监控、测试和评估提供基础设施和平台。

●　设计和研发ML实验跟踪、模型注册、模型一键部署等功能模块。

●　为模型性能跟踪提供监控、预警、仪表盘和日志等功能。

●　ML基础设施的管理、监控及故障排查。

（2）技能要求

●　有架构、部署和维护生产型ML系统的经验。

●　有云平台上的ML开发经验。

●　了解现代软件开发技术，如敏捷方法论和DevOps。

●　有现代深度学习架构模型的设计和开发经验。

●　对API架构和容器编排（如Kubernetes）有深刻的理解。

●　有自动扩展ML系统和大数据系统的经验。

1.3.8　什么时候真正需要MLOps

MLOps在模型开发和生产部署之间搭起了重要的桥梁，但这并不意味着数字化企业必须大量投资来将所有步骤拼接在一起并使其每项任务自动化。谷歌给出了MLOps建设三个级别的标准参考，不同级别对应不同的建设要求，投资策略的选择取决于企业数字化规模和需要运行ML模型的数量。企业可以根据当前的ML应用阶段进行决策和投资。

●　初级，该阶段表明公司已经开始使用ML，甚至已经雇用了能构建和部署模型的内部数据科学家，但是ML的工作流程还是手动的。该阶段适合企业数字化转型初期或对模型构建和模型迭代非常谨慎的金融类公司，这类公司的ML应用特点是用于验证可行性或不需要频繁迭代模型。

●　中级，该阶段开始使用持续训练的ML管道，数据和模型会自动验证，每当模型性能下降或新样本到位时都会自动触发重新训练信号。该阶段适合企业数字化已经进展到稳定时期，会不间断地推出新ML项目，但ML项目的新增频率不会很高。

●　高级，当ML模型的自动训练和自动部署开始叠加CI/CD能力时，MLOps的高级阶段就出现了。该阶段适合营销科技类公司，他们必须每天（甚至每小时或在更小的时间粒度内）重新训练模型，需要在分钟级的时间内更新模型，并同时管理数百甚至更多的模型及服务。处在该阶段的公司将会重度依赖端到端的MLOps，该阶段的MLOps功能更全面、自动化程度也更高。

综上所述，只有适合公司需求和发展阶段的MLOps策略才能产生预期的成果。