机器学习运维（MLOps）简介

机器学习（ML）已经证明是一种非常强大的工具，可以从数据中学习并提取模式。过去十年中，生成、存储和处理大量数据的能力以及轻松访问计算能力的进步，促成了机器学习领域的许多进展，如图像识别、语言翻译和大型语言模型（LLMs），例如BERT、DALLE、ChatGPT等。

机器学习终于从学术实验室毕业，并被商业世界广泛接受，用于解决现实世界的商业问题和变革行业，如提高客户体验、降低成本、提升业务效率并最终增加其竞争优势。根据麦肯锡2021年的《人工智能现状》报告，调查结果表明，AI/ML的采用在全球许多公司的稳步上升。AI对企业底线的影响是这种增长的一个原因。

如今，AI/ML能否为各行业的组织提供商业价值已经不再是一个问题。对AI/ML领导团队来说，一个更迫切的问题是，如何才能最有效地将AI/ML集成到他们的业务流程或产品中，以提供这种价值。为此，他们需要以迭代、一致、有效、安全和可预测的方式实现ML的运作。

来自Gartner和VentureBeat等各种来源的ML项目失败数量数据显示，实现ML运作是一项复杂的任务，需要一套标准化的流程和技术能力来高效快速地构建、部署和运作ML模型。欢迎进入机器学习运维（MLOps）的世界！

MLOps 概述

软件工程项目旨在为公司、组织或团队带来价值。只有当开发的软件工件成功部署到生产环境中时，这种预期的价值才会开始实现。越早实现这一点越好。世界各地的公司都采用了DevOps方法，通过最小化开发和运维之间的差距，促进协作、沟通和知识共享，从而可靠地开发和部署大规模软件到生产环境。DevOps在业界广泛采用，因为它通过强调持续集成、持续交付和持续部署的自动化，帮助实现快速、频繁和可靠的软件发布。

类似地，机器学习（ML）项目旨在为公司、组织或团队增加一定的价值。只有当ML工件，即ML模型和特征，被部署到生产环境并得到适当监控时，ML项目的投资回报率（ROI）才会开始实现。ML项目的ROI实现可能因项目的复杂性、数据质量和具体目标等因素而有所不同。组织在部署的早期阶段可能会开始看到初步回报，特别是如果ML模型解决了特定的痛点，如减少客户订阅流失。通常，当模型成功集成到运营流程中，提供持续且可衡量的价值时，才会实现全面的ROI。这通常需要时间，因为模型可能需要改进、优化和持续监控以适应变化的条件。

ML项目与软件工程项目有何不同？ML项目有哪些独特之处？DevOps方法是否能帮助ML项目？让我们来探讨这些问题，以深入了解MLOps及其提供的好处。

注：

DevOps 已在许多开发软件的组织中广泛采用，作为一种方法论来提高软件质量和可靠性，同时缩短软件工程项目的上市时间。它既是解决从事软件开发的组织中的社会和技术问题的范式转变，也是贯穿整个软件开发过程的自动化持续过程。

DevOps 的基石是一个持续的过程，包括持续开发、集成、部署和监控，旨在实现快速、频繁和可靠的软件发布。

DevOps 的思维模式要求软件工程师不仅关心他们开发的内容，还关心软件的部署和运维。

ML项目

与软件工程项目类似，机器学习（ML）项目也有其自身的开发生命周期。然而，由于ML模型训练过程的科学性质，其生命周期是高度迭代的，这需要实验，并且在很大程度上依赖于用于训练ML算法的数据质量。因此，ML开发过程并不是像标准软件工程开发生命周期那样是线性的，而是循环的，要求反复迭代、调整和改进，如图1-1所示。

ML项目通常旨在帮助实现某些业务或产品目标，并具有可衡量的结果。作为ML项目的第一步，在按顺时针顺序进行其他步骤之前，明确问题并设定清晰的目标和任务是非常重要的。数据科学家需要回到之前的步骤，例如收集更多的数据或改变特征生成方式，这种情况并不罕见，反而是预期且必要的。如果模型评估步骤表明ML模型的表现未达到预期水平，或者实验结果让数据科学家决定改变当前方法或继续微调当前方法。

成功的ML项目是那些数据科学家能够在ML开发生命周期中尽快取得进展，并能够根据需要多次循环开发过程，以应用之前实验中的见解来微调他们的方法、所需的数据，并最终产生最优的ML模型。最终目标是生成最优的ML模型，能够以满足业务目标或任务的精度水平对新数据进行预测。

尽管ML开发生命周期是循环的，看起来很复杂，但可以简化为五个阶段：

1. 数据收集和准备
2. 特征工程
3. 模型训练
4. 模型部署
5. 模型监控

ML项目的输入和工件

在传统的软件工程项目中，软件工程师编写代码以开发逻辑或算法来满足给定的规格，从而根据输入生成输出，如图1-2所示。

在ML项目中，数据科学家花费大量时间和精力在两个主要活动上：特征工程和模型开发。以下段落简要描述了这两项活动，并重点说明了ML项目的输入和工件。

ML特征的数量和质量对ML模型的性能有着巨大的影响。数据科学家通常会花费大量时间来收集和分析数据，然后编写代码将数据转换为ML特征，用于训练ML模型，如图1-3所示。

当数据科学家对生成的ML特征感到满意时，他们便进行ML模型训练步骤。这涉及编写代码以使用生成的特征、ML算法和一组调优参数来训练ML模型。这一步通常需要探索和实验，以评估、微调和迭代ML模型以提高其性能。如果模型评估结果不理想，数据科学家可能需要返回特征工程步骤，收集更多或不同的数据集，或选择不同的ML算法等。

上述活动的主要ML工件如下：

• 用于生成特征的数据
• 从收集数据生成特征的逻辑
• 用于训练ML算法的代码和参数
• 生成的ML模型

ML模型通常需要重新训练，因为可能会出现新的业务需求，或者有新的数据源或ML库可用，或者ML模型的性能开始下降等。因此，重要的是对之前列出的ML工件进行版本控制或管理，如图1-4所示。

ML项目不同于传统的软件工程项目，呈现出许多独特的挑战，总结如下：

• 模型训练需要历史数据：因此，ML项目涉及更多与数据相关的活动，例如数据收集和标注，以及分析和可视化输入数据，以更好地理解其统计特征。
• 模型开发是一个高度迭代的过程：这需要探索和实验。
• 模型性能可能会随着时间的推移而下降：因为新数据的统计特征相对于历史数据的统计特征可能会漂移或变化。
• ML项目通常需要更多的协作：数据科学家、数据工程师、ML工程师和领域专家之间的协作尤为重要，因为项目的成功往往依赖于技术专长和领域知识的结合。

人们常说，MLOps之于机器学习，就像DevOps之于软件工程。MLOps的主要目标是通过围绕技术和非技术要素制定一套最佳实践，帮助全球各地的公司以可重复、一致和高效的方式加速其ML项目进入生产环境。

MLOps：缺失的元素

随着世界上越来越多的公司认识到AI/ML的力量并拨出预算来投资于应用AI/ML以增加商业价值、提升竞争力等，他们理所当然地希望看到他们在ML项目中的投资回报率（ROI）。只有当ML模型部署到生产环境并集成到他们的产品或业务流程中时，他们的ROI才会开始。那么，究竟是什么能够有效、快速地将ML模型带入生产环境？从集体智慧和经验中，ML从业者社区和行业找到了答案，那就是MLOps。

在本节中，我们将探讨一些在实现ML项目运营化过程中常见的挑战和陷阱，然后从高层次上讨论MLOps如何帮助解决这些问题，以提高ML项目的成功率。

ML项目运营化的挑战

据Gartners和NewVantage Partners的多项调查报告显示，许多组织在快速、高效且一致地将ML模型运营化方面未能达到预期，从而导致他们在ML项目投资中未能实现理想的ROI。根据NewVantage Partners在2020年进行的一项调查，只有大约15%的领先组织在任何规模上部署了AI能力。

可以公平地说，大多数组织现在都理解到实现ML项目运营化具有挑战性，这与实现传统软件项目运营化不同。

本节将强调ML项目中的一些常见挑战，并解释这些挑战的产生原因。我们相信，这些挑战是导致ML项目失败的一部分原因。围绕人才缺乏或业务目标不明确的挑战不在本书讨论范围之内。

应用机器学习

在实际的ML项目中，人们普遍理解这些项目的核心是应用ML来实现数据驱动的决策和产品。

ML作为一门学科，与典型的软件工程相比，其本质上是高度实验性和迭代性的。

应用ML涉及在数据集上训练模型，然后在同一数据集以及一个独立的数据集上评估其性能。很少有第一版模型能达到预期的性能，因此，这个过程可能会重复多次，每次迭代可能使用不同的ML算法或架构、超参数设置和特征工程技术。

在应用ML的初期，很难确切知道上述部分的哪种组合会导致性能良好的ML模型。因此，探索、实验和迭代是找到最佳组合并迅速剔除不良组合的必要部分。

与其他科学事业类似，ML实验和迭代需要能够记录实验输入、方法、结果等。这将有助于通过比较多个实验运行来分析结果并确定下一步。

此外，ML仍然是一个不断发展的领域，新的技术、方法和ML库不断涌现。因此，ML从业者必须愿意尝试并利用这些新变化来提高ML模型的性能。

这里的关键是速度。如果ML从业者由于缺乏流程或工具而无法轻松快速地进行探索、实验和迭代，那么将ML模型投入生产可能是不切实际的，或者需要很长时间才能实现ML项目投资的ROI。

垃圾进，垃圾出

计算中的经典说法"垃圾进，垃圾出"指的是问题输入数据会产生问题输出，这在ML中尤其相关，因为模型训练过程高度依赖于输入数据的质量。

ML模型训练是将标记的训练数据输入到ML算法中以学习其模式的过程。众所周知，ML模型的性能只和数据质量一样好。一些著名的ML从业者最近开始倡导数据中心AI方法，以进一步强调高质量训练数据的好处。有关此方法的更多详细信息，请参见下文注释。

除了数据质量外，其他对ML模型性能有较大影响的数据相关方面还有数据新鲜度和数据统计属性的变化。

如果缺乏数据基础设施、数据工程严格性和人员支持，那么这些数据相关方面将对ML模型性能产生负面影响，最终减慢将ML模型投入生产的进程。

注：模型中心AI与数据中心AI------相同目标，不同方法

模型中心AI是一种通过调整超参数或改变模型架构或算法来提高ML模型性能的方法和思维方式。这种方法是传统上行业一直在实践的。

数据中心AI与模型中心AI有相同的目标，但采用了不同的方法，通过固定超参数和模型架构及算法，应用基于错误分析的数据迭代来提高模型性能。正式地，数据中心AI被定义为系统性地工程用于构建AI系统的数据的学科，根据数据中心AI资源中心网站。这个方法由Andrew Ng在他的视频"A Chat w/ Andrew on MLOps: From Model-centric to Data-centric AI"中介绍并倡导。

在开始时

传统上，ML是从单个科学实验的角度来进行的，这些实验主要由数据科学家单独进行。数据科学家在ML领域有知识和培训，主要负责与模型训练相关的任务。

因此，数据科学家往往较少关注与ML模型训练领域周边的领域，如花时间自动化数据管道、专注于开发稳健且高质量的代码、自动化端到端模型训练管道以及将ML模型集成到生产中的数据驱动产品。

企业ML项目不是一次性实验和开发ML模型然后转向其他项目；它们要求这些软件工程相关活动自动化、版本控制、监控、可重复等。

如果数据科学家不转向更以软件工程为中心的思维，或缺乏必要的工具、基础设施或流程来支持数据科学家进行这些软件工程相关活动，那么这将对在组织中实现ML运营化产生负面影响。此外，组织层面需要向产品导向的思维方式转变。

团队合作

开发ML模型并将其纳入数据驱动决策产品的端到端过程是一个复杂且跨学科的过程，如数据工程、机器学习、软件工程和开发运维。毫无疑问，这是一个团队合作，因此职责和所有权需要明确，跨团队的协作是确保这些产品稳定、保持更新，更重要的是继续为业务增加价值的关键。

典型的团队合作包括角色和职责，既然实现ML生产化被称为团队合作，那么让我们来了解一下ML开发生命周期中各种活动的典型角色和职责。

表1-1旨在捕捉ML开发活动的核心集，而不是全面的。

活动	角色
数据准备	数据工程师
特征工程	数据科学家
模型训练	数据科学家
模型部署	ML工程师
模型监控	ML工程师

一些企业可能会在ML运营化过程中包括其他角色，如业务利益相关者或数据治理官。

对于中大型企业，这些角色中的每一个可能由一个或多个人员承担。对于小型企业或初创企业，两个或多个或所有这些角色可能由一个人承担。

来自"Machine Learning Operation (MLOps): Overview, Definition and Architecture"论文的图1-5更详细地描绘了各种角色的交叉点。

要在团队运动中成为获胜的团队，需要具备所有必要的人员和明确的职责分工，以及清晰的沟通和协调协议。同样，企业要在实现ML运营化方面取得成功，需要具备一个由多学科人才组成的团队来履行这些角色，并且需要有标准化的流程、清晰的沟通协议以及明确的职责和所有权边界，使所有参与的团队都能达成一致并保持协调，按时完成预期的交付物并进行适当的交接。

挑战总结

可以合理地说，一贯、高效且大规模地成功实现ML运营化并非易事，但它是可行的，并且结果是值得的。

ML已经被证明是一种颠覆性技术，可以帮助愿意投资的企业降低成本、提高运营效率并增加业务利润。

本节总结了上述挑战，并将其归纳为以下三个关键维度，MLOps旨在解决这些问题，并将在"承诺"部分进行描述：自动化、可重复性和监控。

自动化

如"应用机器学习"一节中所述，这是一种高度实验性和迭代性的过程。这意味着在应用ML的过程中，大多数（如果不是全部的话）活动都可以从自动化中受益。手动过程存在许多挑战，包括容易出错、耗时、不一致且不易重复。

自动化可以提高速度，因为这些活动可以轻松且一致地重复进行，使数据科学家能够更快地完成开发生命周期。

如"垃圾进，垃圾出"一节所述，与数据相关的活动对ML模型性能非常重要。自动化与数据相关的活动（如运行和监控数据管道以确保数据质量和新鲜度）最终将有助于实现最佳的ML模型性能。

可重复性

复杂的ML项目通常需要多个数据科学家之间的合作，以讨论他们的假设并验证ML模型训练实验。为了有效地进行这些工作，他们需要能够轻松地重复实验，这需要以前实验中使用的工件能够随时获取和访问。

数据科学家通常会在现有ML模型的基础上进行迭代以创建新模型。导致新ML模型迭代的常见原因包括业务需求的变化、新的训练数据源的出现、客户行为的变化等。能够重复以前ML模型版本中已经完成的大部分工作，将大大加快新迭代的速度。

监控

人们常说，将ML模型部署到生产环境中只是战斗的一半，持续维护其性能才是另一半。这是因为ML模型在生产环境中的性能可能会下降，并且通常会对客户或企业产生负面影响。

这种性能下降可能由多种原因引起，例如用于预测的ML特征的质量问题、用户行为的变化、环境的变化（如COVID疫情）等。因此，必须持续监控部署的ML模型的性能，并在性能低于某个阈值时提醒数据科学家。

同样的严格标准和持续监控也应该应用于生成训练数据或预测时使用的特征数据管道。

通过主动监控数据、特征和ML模型的性能，数据科学家和ML工程师可以及早发现问题并采取适当行动，以维持模型在长时间内的有效性。

MLOps：承诺

现在，我们对ML项目的开发生命周期、输入和工件以及实现ML模型运营化的常见挑战有了一个高层次的理解，让我们来看看什么是MLOps，以及它如何在上述三个维度的背景下帮助解决这些挑战。

通过在互联网进行快速搜索，可以发现许多对MLOps的稍有不同的解释和定义。然而，它们都趋向于一个共同的目标和一组主题。

为了理解MLOps的本质，我们将逐层剖析它的内涵，就像剥洋葱一样。MLOps由三个基本层次组成：范式、工程学科和原则。每一层都为MLOps的最终目标做出了贡献，并将详细探讨。通过分别和整体地研究每一层，我们将全面了解支撑MLOps的原则和实践，以及它在实现整个机器学习生命周期的高效和有效管理中的重要性。MLOps的洋葱图如图1-6所示。

范式

MLOps 代表了一种组织在处理机器学习方面的范式转变。这种范式认识到，机器学习不仅仅是一个研究或实验活动，而是业务运营的关键组成部分，必须以与其他技术系统相同的严格和纪律进行管理。

那些在成功的ML项目中获得最大收益的组织，是那些接受了这种范式和思维方式，将ML模型和工件视为一流的软件组件。这些组织还采用了运营ML的思维方式，设计、构建和管理ML系统，注重可靠性、可扩展性和效率，并遵循MLOps的原则。

MLOps范式包括一套最佳实践、概念和开发文化。这些方面将在"工程学科"和"原则"部分进行描述。

工程学科

随着全球许多组织将ML应用于业务问题，MLOps 作为一门新的工程学科应运而生，它结合了三种现有学科的工程最佳实践和原则，即机器学习、数据工程和开发运维，如图1-7所示。

MLOps 工程学科涉及将工程原理和实践应用于机器学习模型的开发、部署、监控和维护。其主要目标是使组织能够以高效、高速度、可扩展且易于维护的方式将机器学习模型投入运营。换句话说，就是减少从构想到生产阶段的摩擦，并尽可能以最低风险与软件系统集成。

数据工程

众所周知，数据是AI/ML的命脉，数据的数量和质量将决定机器学习模型能够达到的性能水平。

数据工程学科对 MLOps 学科的主要贡献包括：

• 为训练机器学习模型准备数据打下基础。
• 处理、存储和使用来自不同数据源的各种格式的数据框架和基础设施。
• 通过自动化、高效、经过测试和监控的数据管道，确保用于训练机器学习模型的数据符合质量标准和新鲜度要求。

机器学习

在企业业务问题中应用机器学习的核心是机器学习技术的实践和应用。

机器学习学科对 MLOps 学科的主要贡献包括：

• 分析并从准备好的数据中提取洞察，以确定数据的统计特性，确保机器学习模型训练数据的正确代表性和公平性。
• 确定并选择最合适的机器学习算法和调优参数组合，以生产在新数据上表现良好的机器学习模型。
• 发展对机器学习模型性能的直觉，以迭代和优化机器学习模型性能，使其在部署到生产之前达到业务成功指标。

DevOps

MLOps 借鉴了许多来自知名且受信赖的 DevOps 学科的最佳实践。MLOps 中的工件比 DevOps 更多，这些附加的工件增加了复杂性和挑战，必须在 DevOps 的背景下适当处理。

DevOps 学科对 MLOps 学科的主要贡献包括：

• 促进协作、沟通和知识共享，弥合开发和运营之间的差距。鉴于 MLOps 比 DevOps 涉及更多团队成员，这一贡献对 MLOps 的成功至关重要。
• 确保通过持续集成、交付和持续部署实现自动化，以推动快速、频繁和可靠的机器学习模型发布。这将有助于加快从构想到生产中的机器学习模型的时间，并在必要时通过重新训练机器学习模型来维持其预期性能。
• 确保持续测试、质量保证、持续监控、日志记录和反馈循环。由于机器学习模型性能在很大程度上依赖于训练数据和用于预测的新数据，并且数据不断变化，因此持续监控数据统计特性和模型性能对于确保机器学习模型按预期执行并最大限度地减少影响用户体验或其他负面影响的风险至关重要。

数据工程、机器学习和 DevOps 三个工程学科的最佳实践是一个很好的起点；然而，由于其独特且高度迭代和实验的性质、涉及更多团队成员的特点，以及包含数据、代码和模型的工件，这些都带来了额外的挑战和管理需求，因此需要在 MLOps 中进行一些调整和补充。以下是一些值得注意的事项：

• 机器学习项目中的测试比传统软件系统的测试更加复杂。除了单元和集成测试之外，还需要进行数据验证、训练模型质量评估和模型验证。
• 部署机器学习模型涉及一个多步骤的管道，包括自动重新训练和部署模型，以及定期将特征部署到在线特征存储中。
• 由于模型性能自然会下降，因此必须对生产中的机器学习模型进行监控。这需要定期和主动跟踪用于预测的数据的总结统计数据和在线模型性能。

原则

在上述"工程学科"部分，讨论了 MLOps 所依赖的三个学科的一些最佳实践。本节旨在将其中的一些实践和额外的实践编码为一组原则，任何 MLOps 采用都应考虑这些原则。

这些原则旨在指导组织内的 MLOps 实践。至于每个原则的严格程度或关注点，将取决于该组织的 AI 策略、目标、用例和文化。

自动化

自动化指的是尽可能地去除手动流程和人为干预，投资于流程和工具来执行机器学习开发生命周期中的关键步骤。这包括执行、构建、测试、训练和部署数据、代码和机器学习模型等工件。

一些机器学习开发活动需要在一定的节奏上反复运行，例如数据管道、特征生成管道、模型训练管道等。这些活动将最能受益于自动化。

随着以下情况的发生，自动化的需求增加：

• 机器学习模型的数量达到手动管理变得不切实际和资源密集的地步。
• 团队成员（数据科学家、数据工程师、机器学习工程师）的数量达到手动协调和沟通变得更加具有挑战性的程度，例如 10 人或更多。
• 组织越来越依赖机器学习模型为业务带来的价值。

自动化为机器学习项目开发的参与者提供了快速反馈，从而提高了整体生产力和协作性。

版本控制

机器学习项目中的主要工件是数据、代码和机器学习模型。MLOps 的最佳实践是将这些工件视为一流公民，例如在 DevOps 学科中的代码，使用版本控制系统。

类似于开发软件系统的最佳实践，机器学习模型训练代码应经过代码审查过程，除了版本控制之外，还使模型训练过程可审计和可复现。

ML 从业者社区中的一个老故事是，由于原始模型作者离开公司且训练代码和元数据从未被记录到版本控制系统中，导致无法复现或重新训练机器学习模型。这一最佳实践应能帮助解决这一问题。

对训练数据进行版本控制的一个挑战在于其大小。

实验跟踪

正如之前所提到的，机器学习开发是一种高度迭代和实验性的科学活动。支持这一机器学习的独特方面，使数据科学家能够快速实验、评估和比较结果，并与其他数据科学家协作，将需要一种简便的方法来跟踪实验的元数据，例如使用的参数、性能结果指标、模型谱系、数据和代码。

这种方法不仅有助于可复现性，更重要的是可追溯性。此外，机器学习模型的探索和迭代既耗费金钱又耗费时间。因此，任何能够减少时间和金钱的措施都将为组织带来效率。

可复现性

这一原则指的是在机器学习开发生命周期的主要步骤中，给定相同的输入能够复现结果的能力，包括特征生成、机器学习模型训练和实验、以及模型部署。

对于传统软件开发，使用版本控制通常就足以满足可复现性原则。对于机器学习项目，需要更多努力来跟踪各种管道、特征生成和模型训练代码、超参数，特别是数据和模型训练环境。

这一原则带来的好处是多方面的且至关重要，例如在一个数据科学家离开公司或转到另一个项目时，或者在由于负面业务影响或监管要求而需要调试一个重要的生产问题时。

测试

可以预期，在数据工程师、数据科学家、机器学习工程师等人员中，测试原则的实践应受到最少的阻力。然而，由于机器学习项目的动态性质和多种类型的输入和工件，测试更加具有挑战性，也更加重要。

有效的机器学习项目测试需要多种类型的测试。以下部分重点介绍了两个重要的机器学习工件：数据和模型。

与数据相关的测试

数据质量和统计特性直接影响机器学习模型在训练和预测阶段的性能。以下是一些重要的测试类型：

• 检测空值、异常统计分布和特征相关性。
• 在二元或多类分类任务中，验证目标标签分布的假设。
• 单元测试特征生成代码。

与模型相关的测试

• 使用离线数据验证模型性能，确保其达到预期的性能指标（如准确性）以及操作指标（如推理延迟或模型大小）。
• 生成特征重要性以了解每个特征对模型性能的影响。
• 通过使用少量实时生产数据比较新模型或版本与简单基线模型或当前生产模型的性能，进行模型冒烟测试。
• 针对模型性能进行公正性、偏差和包容性测试。

持续的机器学习训练、评估和部署

随着组织希望扩大其 AI/ML 投资和机器学习项目，强烈建议投资于这一原则，以通过持续调整机器学习模型来适应我们生活中的动态世界，从而不断获得机器学习项目的投资回报。

机器学习从业者社区广为人知的事实是，模型性能随着时间的推移会因多种原因下降。对于电影推荐等机器学习用例，由于输入数据因用户行为变化而变化得非常快，至关重要的是通过持续的机器学习训练和评估保持这些模型的最新状态，以维持和提高其性能。

以高效、有效和安全的方式实践这一学科需要以下支持：

• 能够在模型性能开始下降到低于某个可接受阈值时进行监控、检测和警报，这基于业务成功指标。
• 基于数据变化或性能下降触发的自动化机器学习训练和评估管道。
• 在安全的方式中推广和部署更新的模型版本的自动化部署过程。

并非所有机器学习用例都需要持续的机器学习训练和评估。然而，那些需要的用例将大大受益于这一原则，从而在长期内为机器学习项目投资带来丰厚的回报。

持续监控

变化是生活中唯一不变的东西。 ------希腊哲学家赫拉克利特

机器学习的另一个独特方面是模型性能需要持续监控，以在性能下降到某个可接受阈值以下或开始产生对用户体验、业务价值或组织形象产生负面影响的错误预测时，保护其下行风险。

这一原则倡导对所有机器学习工件（数据、模型、代码、数据管道、模型训练管道等）进行定期和主动的评估，以检测潜在错误。

在各种需要持续监控的领域中，最具挑战性的是与机器学习相关的模型漂移，因为随着时间的推移，这种漂移会悄悄地进入模型并对业务结果产生不利影响。模型漂移现象是指模型的预测随着时间的推移，由于机器学习模型预测和输入训练数据之间的关系变化而发生的漂移。以下部分将分享更多详细信息和示例以使这一点清晰。

模型漂移分为概念漂移和数据漂移两种类型。

概念漂移

在机器学习术语中，它指的是模型输入和输出之间的功能关系在某个时间段发生变化。

这种漂移的早期指标是模型性能下降，而用于预测的输入特征的统计分布保持不变。

一个有趣的漂移示例是，在 COVID-19 大流行初期训练的杂货商品需求预测模型。由于大流行期间对卫生纸和洗手液等商品需求的突然激增，模型对需求的预测将变得越来越不准确。

数据漂移

在机器学习术语中，它指的是模型输入（输入训练数据或特征）的统计特性在某个时间段发生变化。

这种漂移的早期指标是模型性能在与用于预测的输入特征的统计分布变化相关的情况下下降。

一个有趣的漂移示例是，在 COVID-19 大流行之前训练的旅行时间预测模型。由于大流行期间街道上的车辆减少，该模型在预测旅行时间方面不再有效。

除了监控模型的有效性外，还需要监控与模型服务相关的其他操作指标，例如：

• 模型服务延迟：一个关键指标，用于在线机器学习用例，指示模型服务系统的健康状况。
• 资源利用率：例如内存、CPU、GPU的使用量。过度使用这些资源表明系统不稳定。
• 模型预测吞吐量。
• 错误率。

注释

DataOps vs. ModelOps vs. AIOps 有几个术语以 Ops 结尾，其起源有些不明确。以下简要定义来自 Gartner 网站的术语表部分。

DataOps 是一种协作数据管理实践，专注于改进数据生产者和消费者之间在整个组织中的通信、集成和数据流自动化。 ModelOps 主要关注各种操作化机器学习模型的治理和生命周期管理。 AIOps 结合大数据和机器学习来自动化 IT 操作流程，包括事件关联、异常检测和因果关系确定。

MLOps 典型技术栈

除了 MLOps 工程实践和原则之外，我们还需要基础技术栈和组件，以提供可扩展且高效的方式来自动化和扩展机器学习模型的开发、部署、管理和监控，以及将机器学习模型与产品软件系统集成。

本节将讨论 MLOps 典型技术栈，旨在为希望构建 MLOps 基础设施以实现其机器学习项目的组织提供蓝图。典型技术栈及其组件和核心功能将从工程的角度进行描述，而不是机器学习的角度，并以通用和技术中立的方式进行介绍。

各组织需要自行决定最适合其需求的开源和商业化技术和框架，以及采用策略，以最大限度地提高成功的可能性。大部分的采用策略和技术方面的细节将在后续章节中讨论。

MLOps 蓝图

图 1-8 中的蓝图是对 AI Infrastructure Alliance 网站发布的《2022 年 AI 基础设施生态系统》报告中的蓝图的改编。其蓝图是 MLOps 核心能力的浓缩版，而此版本结合了最近出现的一些附加内容。MLOps 特定的能力以灰色框表示。

MLOps 典型技术栈

除了 MLOps 工程实践和原则之外，我们还需要基础技术栈和组件，以提供可扩展且高效的方式来自动化和扩展机器学习模型的开发、部署、管理和监控，以及将机器学习模型与产品软件系统集成。

本节将讨论 MLOps 典型技术栈，旨在为希望构建 MLOps 基础设施以实现其机器学习项目的组织提供蓝图。典型技术栈及其组件和核心功能将从工程的角度进行描述，而不是机器学习的角度，并以通用和技术中立的方式进行介绍。

各组织需要自行决定最适合其需求的开源和商业化技术和框架，以及采用策略，以最大限度地提高成功的可能性。大部分的采用策略和技术方面的细节将在后续章节中讨论。

MLOps 蓝图

图 1-8 中的蓝图是对 AI Infrastructure Alliance 网站发布的《2022 年 AI 基础设施生态系统》报告中的蓝图的改编。其蓝图是 MLOps 核心能力的浓缩版，而此版本结合了最近出现的一些附加内容。MLOps 特定的能力以灰色框表示。

MLOps 堆栈广泛且复杂

一个敏锐的读者会认识到，MLOps 堆栈是广泛且复杂的，并且它对公司的基础基础设施有许多依赖性。其中一个 MLOps 堆栈具有关键依赖性的具体基础设施是数据平台基础设施。如果没有存储、访问和处理数据的能力，那么在任何组织中成功地实现 ML 项目运营几乎是不可能的，除非这些 ML 项目只是实验性和小规模的项目。

MLOps 蓝图描绘了旨在支持 ML 开发生命周期和上述 MLOps 原则的核心能力。

MLOps 组件

为了更深入地了解 MLOps 蓝图中组件所代表的能力以及每个灰色框（组件）如何支持 ML 开发生命周期和 MLOps 原则，本节将提供有关每个组件的更多信息。

特征工程

ML 开发生命周期中的第一步之一是特征工程，涉及选择相关特征、创建新特征以及对其进行缩放和转换，以使其适合 ML 算法。这个步骤对于 ML 项目的成功至关重要，数据科学家通常会花费大量时间在这上面。

为了加速这一步骤，抽象底层的复杂性和系统相关的挑战是有帮助的，这样数据科学家就可以专注于创建特征的逻辑。换句话说，数据科学家应该能够定义生成特征的逻辑，而支持的基础设施应该负责以简单、可靠和可扩展的方式实现这一逻辑。

对于以下情况的组织，支持的基础设施可能不太重要：

• 处于应用 ML 的早期阶段并在实验阶段。
• 只有少数 ML 项目。
• 特征数量较少。

这种能力支持自动化原则，并且对于希望扩大 ML 项目数量的组织来说是必须的。

特征存储

特征存储本质上是一个集中式的特征存储库，提供特征管理，包括特征注册和特征发现，以了解特征的来源、计算逻辑、质量和当前状态。这使得跨多个应用 ML 的团队能够重用和共享特征。

一个完整的特征存储为离线和在线使用场景提供存储和访问。由于在线模型预测请求路径中的低延迟访问要求，在线使用场景更具挑战性。

对于处于 ML 采用旅程早期的公司，可以从一个简单的具有有限功能的特征存储开始，例如使用 S3 存储桶。

这种能力对于扩展 AI 项目并通过特征重用和共享高效运营是必须的。 这种能力支持的原则包括持续版本控制、可重复性、ML 训练、评估和部署。

笔记本服务

在 ML 项目的早期阶段，数据科学家通常花费大量时间进行探索和实验，以获得他们试图解决的问题或分析收集到的数据的洞察。他们可能会尝试不同的 ML 算法和超参数，以建立基线模型。笔记本服务已成为数据科学家常用的工具，提供了一个基于网络的沉浸式工作界面。

一个具有数据访问和计算资源用于模型训练的集中式笔记本服务可以大大提高数据科学家的生产力。开源的笔记本服务如 JupyterLab 已经使数据科学家能够轻松启动本地实例，但集中服务可以提供额外的好处，如协作、版本控制和与其他工具和服务的集成。

这种能力只有在组织开始扩展其 ML 项目和投资时才会开始见效。 笔记本服务支持 MLOps 的几个关键原则，如自动化、版本控制、实验跟踪和可重复性。通过为数据科学家提供集中平台，笔记本服务可以促进这些原则，并支持更高效和有效的 ML 开发过程。

模型训练

与特征工程能力类似，此组件的目标是使数据科学家能够轻松高效地训练其机器学习模型，无论其在特征数量、模型架构和计算资源需求方面的复杂性如何。

为了实现这些目标，此组件应提供以下功能：

• 让数据科学家以简明易懂的方式简洁地编写模型训练步骤所需的抽象。
• 能够使用所需的计算资源（如 CPU、GPU 或 TPU）训练其模型。
• 持续的 ML 训练。
• 能够遵循可重复性和一致性的方法。

以下部分将深入探讨每个功能的具体细节。

抽象

理解模型训练是一个互动过程，数据科学家通常具有丰富的知识和技能，能够选择合适的特征、ML 模型算法和一组超参数，最终为手头的业务问题产生一个最佳的 ML 模型。

他们需要一种抽象来表达模型训练过程中需要完成的工作，并尽量减少代码行数以：

• 拆分样本并拆分训练集。
• 指定 ML 模型算法和超参数。
• 评估和跟踪模型性能指标。
• 访问完成模型训练所需的计算资源，以尽可能缩短时间。

这种抽象通常由一个用 Python 编写的库提供，作为其他现有库的包装，并用于访问公司基础设施，如日志记录或监控。

技术不断发展。抽象化减轻了升级依赖库的新版本或切换到提供更好功能的新库或访问新提供的基础设施的痛苦。

计算资源

随着组织扩大其 ML 项目，毫无疑问，其用例将变得更复杂，因此可能需要使用大量特征进行模型训练，并使用越来越复杂的 ML 算法架构。

能够在规模上访问所需的计算资源，以便训练大型和复杂的 ML 模型，或者将模型训练时间从几天减少到几个小时或几分钟，这将大大加快迭代模型训练过程，并最终缩短将 ML 模型推向生产的时间。

启动和管理昂贵的计算资源无论是在云端还是本地，通常都是一项工程任务。最好尽量减少数据科学家学习如何执行此任务的需求。在管理计算资源方面，如启动、关闭和成本归属，最好由模型训练基础设施完成。

持续训练

一个有趣的软件开发者时刻是"它在我的电脑上运行"。类似地，组织不希望部署到生产中的 ML 模型成为重要业务决策流程的一部分，如批准或拒绝贷款申请，如果它是在数据科学家的笔记本电脑上训练的。

理想情况下，任何生产中的 ML 模型都应该通过一种系统化的方法进行训练，该方法基于经过代码审查并签入版本控制系统的训练代码。

这种系统化的方法通常被设计为持续集成和部署管道中的一步，并集成到版本控制系统中。

这可以确保训练的 ML 模型是在受控和可追溯的方式下完成的，具有审计跟踪和可追溯性，并且应该是相当可重复的。

一致性和可重复性

随着组织对机器学习的投资增加并承担更多项目，数据科学家的数量通常会增加，导致协作增加，以及数据科学家可能接手以前由其他数据科学家处理的项目的情况，后者已转向其他项目或离开公司。在这些情况下，确保机器学习模型训练过程的一致性和可重复性至关重要。

如果模型训练代码通过代码审查以高质量方式编写，并且在版本控制系统中易于访问供他人查看或学习，这将极大地提高组织内数据科学家的协作和生产力。

开发模型训练代码的铺平之路将使数据科学家非常容易地重复以前训练的模型，以便在新版本上进行迭代或调试意外的生产问题。

最终，一致性和可重复性将提高数据科学家的生产力并保持其理智。

模型训练基础设施在使组织扩大其 ML 投资和项目方面起着至关重要的作用。

实验

实验是数据科学学科的科学部分，是 ML 模型训练过程中不可或缺的一部分。实验是为了找到最佳模型架构、特征和调优参数组合，以产生最佳性能的模型来满足业务需求。它需要迭代并跟踪所有实验工件，类似于在大学化学课程中进行化学实验。

这个组件不是关于如何进行实验，而是关于启用与实验相关的所有活动和跟踪。

此组件需要提供的基本功能包括：

• 提供一种简便的方法将实验信息发送到集中位置。
• 以持久可靠的方式存储实验信息。
• 通过 API 或用户界面提供易于访问实验信息的方法。
• 提供一种直观的方法比较两个或多个实验，以便数据科学家可以轻松理解哪些因素导致了变化。

此组件支持的原则主要是可重复性。

模型存储

在训练完 ML 模型后，需要将其存储在一个中央存储库中。从那里，它将经历其生命周期，包括部署到各种环境，如预生产、测试和生产。一个中央模型存储库作为所有训练模型的单一真实来源，促进数据科学家和其他利益相关者之间的轻松访问、版本控制和协作。它还使组织能够管理其模型的完整生命周期，跟踪其性能，并就部署哪些模型以及何时部署做出明智的决策。

随着组织的机器学习组合增加到包括更多模型，通常大约 20 个或更多，集中模型存储的需求变得越来越明显，以克服模型管理和版本控制的挑战。

模型存储为 ML 项目带来了以下好处：

• 有效管理 ML 模型及其生命周期。
• 模型可追溯性和可重复性。
• 模型治理：使组织能够建立管理模型生命周期的政策和流程，促进合规性，并减轻与模型性能或行为相关的风险。
• 安全性：为模型提供安全存储和访问控制，防止未经授权的访问或篡改。

模型存储作为 ML 开发阶段和 ML 生产阶段之间的桥梁，如图 1-9 所示。

管理 ML 模型及其生命周期

一旦 ML 模型正式训练完毕并成为部署候选者，它们就应存储在模型存储库中并由其管理。作为中央模型存储库，模型存储库提供这些 ML 模型的可见性、可发现性、可审计性和管理。

对于一些公司，模型生命周期简单，仅有几个阶段。对于其他公司，由于监管合规性，其公司的政策规定了复杂的模型生命周期。拥有一个能够管理符合公司需求的定义生命周期的模型存储库，是确保一致性和满足合规性的关键。

模型可追溯性和可重复性

除了通过存储模型工件和元数据简化 ML 模型的生产转移外，模型存储库还可以帮助捕获有关部署信息的审计记录，如谁部署了模型、何时部署的，以及任何部署注释。

可追溯性对于那些希望在模型审查、模型部署批准和部署方面具有强大治理和安全性的公司特别有用和重要。

在通过模型存储库注册模型以准备部署的过程中，应该捕获并存储有关 ML 模型和训练数据的信息。如果需要再现某个特定模型，所有相关信息都可以轻松获取。

此组件支持的原则是版本控制和可重复性。

模型部署

在 DevOps 世界中，组织能够自动化地每日多次部署其软件。

在 ML 世界中，类似地，模型部署是一个将训练好的 ML 模型部署到生产环境或回滚已部署模型的工作流程。

模型部署工作流程通常与模型存储库交互，以检索 ML 模型工件，将它们打包成可由模型服务组件消费的方式，并使用审计记录更新模型生命周期状态。

模型部署工作流程的第二部分是将模型工件交给模型服务组件，并触发任何必要的更改，以使新部署的模型能够开始根据传入请求执行预测。

图 1-10 描绘了模型部署、模型存储库和模型服务之间的交互。

一旦 ML 模型正式训练完毕并成为部署候选者，就应存储在模型存储库中并由其管理。作为中央模型存储库，模型存储库提供这些 ML 模型的可见性、可发现性、可审计性和管理。

对于一些公司，模型生命周期简单，仅有几个阶段。对于其他公司，由于监管合规性，其公司的政策规定了复杂的模型生命周期。拥有一个能够管理符合公司需求的定义生命周期的模型存储库，是确保一致性和满足合规性的关键。

模型可追溯性和可重复性

除了通过存储模型工件和元数据简化 ML 模型的生产转移外，模型存储库还可以帮助捕获有关部署信息的审计记录，如谁部署了模型、何时部署的，以及任何部署注释。

可追溯性对于那些希望在模型审查、模型部署批准和部署方面具有强大治理和安全性的公司特别有用和重要。

在通过模型存储库注册模型以准备部署的过程中，应该捕获并存储有关 ML 模型和训练数据的信息。如果需要再现某个特定模型，所有相关信息都可以轻松获取。

此组件支持的原则是版本控制和可重复性。

模型部署

在 DevOps 世界中，组织能够自动化地每日多次部署其软件。

在 ML 世界中，类似地，模型部署是一个将训练好的 ML 模型部署到生产环境或回滚已部署模型的工作流程。

模型部署工作流程通常与模型存储库交互，以检索 ML 模型工件，将它们打包成可由模型服务组件消费的方式，并使用审计记录更新模型生命周期状态。

模型部署工作流程的第二部分是将模型工件交给模型服务组件，并触发任何必要的更改，以使新部署的模型能够开始根据传入请求执行预测。

图 1-10 描绘了模型部署、模型存储库和模型服务之间的交互。

模型服务

模型服务是将 ML 训练模型用于生产或未见数据以生成预测的地方。根据特定用例，预测要么在离线（也称为批处理）期间生成，要么在线生成。以下说明了批处理预测和在线预测的区别，这通常与模型服务密切相关。

批处理预测 vs. 在线预测

当提到预测时，常见的后续问题是该预测的上下文。是批处理预测还是在线预测？

批处理预测是定期或按需生成的，以批处理方式生成成千上万甚至数百万个预测。这种方法适用于数据以批处理形式提供的情况，例如基于历史数据进行预测或在一段时间内收集模型输入时。例如，一家电子商务公司可能会基于过去的购买历史生成客户推荐的批处理预测，为每个客户生成一组推荐，用于营销活动。预测结果存储在如 SQL 表或 S3 桶等存储系统中，稍后可能会转移到快速在线系统（如内存和分布式存储引擎）以便在线请求消费。许多在线推荐引擎使用这种模式，如 Netflix 电影推荐器。批处理预测也称为异步预测。

在线预测是基于传入的按需请求生成的。每个请求通常会生成一个到数千个预测，但不太可能达到百万级。预测结果立即返回给请求者。这就是为什么在线预测也称为同步预测。

模型服务组件用于在线预测用例，其主要职责是以在线服务的形式托管 ML 模型，可能支持如 HTTP/HTTPS、REST 或 gRPC 等协议，然后根据传入的预测请求使用这些模型生成预测。基本上，模型服务公开一个服务端点，以便其他服务可以从托管的 ML 模型获取预测。

模型服务将 ML 和微服务结合起来，使远程服务能够以 ML 预测的形式利用 ML 功能。因此，模型服务组件的关键能力是典型微服务和 ML 模型需求的结合，例如：

• 低延迟、可扩展、可靠
• 与 ML 框架无关或支持常用的框架
• 支持 CPU、GPU、TPU 或其他 AI 加速硬件
• 支持模型影子
• 与 A/B 实验平台集成
• 代表客户端支持在线特征获取
• 支持预测请求（特征、模型 ID/版本、预测结果等）的日志记录

当组织开始将 ML 集成到其在线产品中以服务于在线客户请求（如推荐、搜索和排名、欺诈检测、语言翻译、自动完成功能等）时，模型服务组件是 MLOps 堆栈中最关键的组件之一。

此组件支持的原则是自动化和持续部署。

预测存储

预测存储是一个新兴组件，与其他组件相比，受到的关注和讨论较少。它充当在线预测用例的预测日志的中央存储库。预测日志通常包含用于生成预测的输入特征、生成预测的模型以及其他元数据和操作指标。

这些信息对于数据科学家非常有价值：

• 调试 ML 模型生产问题
• 评估影子模式下 ML 模型的性能
• 用作现有模型下一版本的训练数据

数据科学家需要能够以简单、高效和可扩展的方式访问、分析和处理这些预测日志。

此组件支持的原则是可重复性和持续监控。

注 Josh Tobin 是一家名为 Gantry 的初创公司的联合创始人，他倡导一种称为评估存储的组件。在他的演讲《ML 基础设施堆栈中的缺失环节》中，评估存储被定义为"一个存储和查询在线和离线真实数据及近似模型质量指标的中央位置。"

除了支持上述预测存储的功能外，评估存储还存储训练阶段的预测和评估阶段的 ML 模型指标，使 ML 实践者能够更自信地部署 ML 模型并更快地发现生产问题。

ML 可观察性

ML 可观察性在保护 ML 模型部署到生产环境并集成到组织的在线产品中的负面影响方面发挥了重要作用。换句话说，它能够检测和防止对 ML 模型旨在改善的业务结果的负面影响。

更重要的是，它在确保团队在将 ML 模型部署到生产环境后不会"盲目飞行"并能够通过分析模型退化情况快速迭代和改进其模型方面发挥了重要作用，还可以轻松地进行生产中模型相关问题的根本原因分析。

ML 可观察性作为 MLOps 的一个组件，涵盖了几个关键方面，包括监控、可观察性和可解释性。这些方面对于确保机器学习系统按预期运行以及帮助团队诊断和解决出现的问题至关重要。

监控

监控是通过跟踪、测量和记录系统操作指标和 ML 相关指标（如准确性、漂移、预测失败和错误等）来回答出错问题的内容和时间。

可观察性

可观察性旨在提供更多关于 ML 模型行为和性能的上下文或见解，使团队能够在问题出现时快速识别和调试。例如，如果模型性能开始下降，ML 团队应该能够轻松快速地确定根本原因，例如生产特征数据的变化、导致特征过时的特征数据管道故障、最近模型部署引入的错误，或底层基础设施或环境的问题。

可解释性

可解释性试图帮助人们理解模型为何做出特定预测或哪些因素对预测结果影响较大。这些信息对业务团队或非数据科学团队非常有帮助，使他们对 ML 模型的性能充满信心，并直观地了解这些模型的行为，同时帮助在验证阶段或生产中发现潜在问题。

为了满足上述三个领域的需求，此组件需要提供的关键方面是：

• 轻松设置各种 ML 相关指标的监控，如模型和特征漂移、模型性能指标，以及设置触发警报的阈值以提醒值班的 ML 工程师或数据科学家进行调查
• 轻松可视化各种模型性能指标，以便了解情况并轻松分析指标，使数据科学家能够快速找出问题所在
• 轻松查看哪些特征在影响预测结果方面起着重要作用
• 轻松分析每个 ML 模型的性能指标

总之，借助 ML 可观察性，数据科学家将能够轻松快速地洞察模型性能问题，理解 ML 模型如何做出预测，并能够回答非数据科学团队关于其 ML 模型行为的问题。

注 此组件在很大程度上依赖于预测存储，以访问和计算预测日志数据的各种聚合。

此组件支持的原则是自动化和持续监控。

MLOps 支柱

图 1-8 中描绘了众多组件，上一节也描述了它们的详细信息。通过略微缩小视野并将这些组件逻辑分组到更广泛的领域中，即所谓的支柱，可以更好地从整体上了解 MLOps 堆栈。这些支柱捕捉了 MLOps 堆栈的关键方面，便于与其他团队共享和解释，以及在组织推进 MLOps 的生产化过程中跟踪其进展和成熟度。每个支柱的范围和影响都足够广泛，且边界合理划定。因此，很容易证明每个支柱都需要一个团队来开发和支持。

我倡导的四个支柱是特征工程、模型训练和管理、模型服务和 ML 可观察性，如图 1-11 所示。

特征工程

该支柱负责所有支持特征生成、特征管理和特征库相关活动和流程所需的基础设施。

模型训练和管理

该支柱负责所有支持模型训练、模型库和模型生命周期管理相关活动和流程所需的基础设施。

模型服务

该支柱负责所有支持模型服务和预测库相关活动和流程所需的基础设施。

ML 可观察性

该支柱负责所有支持 ML 监控、可观察性和可解释性相关活动和流程所需的基础设施。

注：ML 治理 ML 治理包括一套用于管理 ML 模型生命周期的政策、流程和控制，解决与伦理、合规和风险管理相关的问题。MLOps 支柱更多是关于加速 ML 开发过程所需的基础设施。因此，本节不讨论 ML 治理话题。

总结

本章从高层次阐述了 MLOps 兴起的原因以及将 ML 项目投入生产的一些挑战。它提到了 ML 项目的一些独特方面，以及它们与标准软件项目的不同之处，例如 ML 的迭代和实验性质。认识到这些差异是理解 MLOps 的第一步。

接下来，它强调了 MLOps 作为一种工程学科，结合了其他三种工程学科（DevOps、数据工程和机器学习）的最佳实践和技术。

然后，它剖析了 MLOps 工程学科，通过讨论三个主要层次（范式、工程学科和原则）深入理解 MLOps。值得重复的是，成功采用 MLOps 的第一步和关键步骤是将 ML 工件视为 ML 项目开发中的一等公民。通过标准化和实践 MLOps 原则，组织可以开始扩展其 ML 项目，并从其 ML 投资中获得更大收益。

在讨论 MLOps 工程实践和原则之后，章节描述了支撑技术栈及其组件，从工程的角度而不是 ML 的角度。经典栈旨在提供一种可扩展和高效的方法，以自动化和扩展 ML 模型的开发、部署、管理和监控。

最后，它提出了一种逻辑分组组件的方法，将其分为支柱，使理解 MLOps 的布局以及每个支柱的范围和边界变得更加容易。

一旦组织了解了 MLOps 的最佳实践、学科和经典栈，它应该如何采用 MLOps 并将其整合到大型生态系统中？应遵循哪些策略和方法以获得成功的最大机会？可能会出现哪些潜在挑战？第2章将讨论这些重要问题，并分享一些可能对希望采用 MLOps 或在采用 MLOps 时面临挑战的组织有帮助的建议。