毫无疑问，我们正处于人工智能（AI）/机器学习（ML）运营化的蓬勃发展时期。根据Gartner的一篇文章《IT预算在增长。资金流向何处》，AI/ML在技术列表中名列前茅，几乎一半的首席信息官（CIO）表示，他们目前已在使用AI/ML或计划在未来12个月内开始使用。O’Reilly的《2020年企业AI采纳》报告也证实了这一统计数据，并进一步指出，AI/ML的采纳在许多行业中普遍存在，如金融服务、教育、医疗保健、制造业、零售等。
最大化AI/ML投资的投资回报率（ROI）并缩短实现价值的时间是组织的重要目标。实现这些目标的一个关键因素是有效实施MLOps。虽然对MLOps有一个扎实的理解是一个好的起点，但将这种理解转化为成功的实施可能是具有挑战性的。
与任何技术采纳类似，成功的MLOps采纳需要一种系统的方法和一套策略，以管理MLOps特有的细微差别，以及需要考虑的众多因素。
本章将首先概述一个高层次的策略，并强调组织在确保成功采纳MLOps时需要考虑的一些重要维度。之后，它将提供几种使MLOps成为现实的方法，并分享每种方法的一些优缺点。
对于那些考虑采纳或处于早期采纳阶段的组织，本章希望能为调整其当前的采纳方法或为其在坚实的基础上开启旅程提供帮助。
许多大型成功公司，特别是那些在互联网时代或不久之后诞生的公司，都经历了构建其MLOps基础设施的过程。本章最后部分将介绍几个成功的MLOps采纳案例研究。
让旅程开始吧！
采纳策略
根据《AI基础设施生态系统2022》报告，只有26%的受访者对他们当前的AI/ML基础设施非常满意。作为一个行业，这表明还有很大的改进空间。这项调查反映了一个事实：确定并组建适合特定组织需求的AI/ML基础设施是一项非常具有挑战性的任务。然而，同一项调查也指出了好消息，大多数组织能够在两年或更短的时间内迅速从AI/ML基础设施投资中获得回报。
采用AI/ML的组织需要一个MLOps基础设施，也称为AI/ML基础设施或ML平台。我们需要迅速提醒自己，MLOps的目标是帮助组织一致、有效且高效地运营ML，以便他们能够利用AI/ML的力量提升竞争优势、增加收入和/或利润，并更重要的是从ML项目投资中获得回报。
与之前的技术进步类似，没有一种统一的技术采纳策略可以解决每个公司的独特性和各种需求。此外，一个组织的MLOps采纳成功标准很可能与另一个组织不同。
在决定构建MLOps基础设施的方法之前，组织或领导团队应该考虑以下两个关键方面：
- 业务目标与MLOps基础设施目标的一致性
- 对MLOps具体需求的评估
目标一致性
业务目标与MLOps基础设施目标的一致性是显而易见的，但不能掉以轻心。重要的是要记住，MLOps基础设施是实现利用AI/ML力量为业务目标增值并从ML项目投资中获得回报的手段。
一致性的好处包括：
- 了解业务目标及其优先级将有助于影响MLOps基础设施的构建顺序，并识别哪些领域需要更多关注。
- 由于所有人对业务目标及其优先级达成一致，MLOps基础设施的采纳讨论将变得更加顺利。
- 以清晰的业务目标回报为基础，获取人才资金和购买供应商解决方案的理由将更容易证明。
可以理解，由于各种因素，业务目标会随时间演变，MLOps基础设施目标也必须相应调整。如果MLOps基础设施目标无法跟上不断变化的业务需求，基础设施可能会被视为成本中心，而非有价值的资产。
MLOps需求评估
第一章中描述的MLOps标准堆栈提供了典型MLOps基础设施所需各种基本组件的全面概述。虽然这一堆栈作为理解涉及组件的有用蓝图，但简单地按顺序实现每个组件可能不足以实现成功。必须仔细考虑几个关键维度。
组织在业务领域、规模、与支持ML项目相关的技术现状和成熟度、数据科学和MLOps基础设施团队的规模和人才，以及公司文化等方面存在差异。这些因素影响组织在MLOps基础设施和实施方面的独特需求和能力。
接下来的部分将深入探讨这些领域，并重点说明它们如何影响MLOps基础设施的构建顺序、每个组件需要的重视程度以及其他考虑因素。
用例
AI/ML由于其解决多种决策相关业务问题的能力，是企业的强大工具。
组织需要解决的各种ML用例类型主要由其所在业务领域驱动，用例的数量主要受公司规模和业务功能数量的影响。
下表2-1列出了几个业务领域中的一些知名ML用例示例。
表2-1 业务领域和ML用例示例
| 业务领域 | ML用例 |
|---|---|
| 医疗 | 医学诊断、患者监测 |
| 市场营销 | 个性化广告、情感分析 |
| 安全 | 面部识别、入侵检测 |
| 运输 | 路线优化、自动驾驶 |
| 财务 | 贷款批准、欺诈检测、信用评分 |
| 电信 | 客户流失预测、精准营销、网络优化 |
| 能源 | 预测性维护、需求预测 |
| 社交媒体 | 个性化推荐、广告优化 |
| 零售 | 需求预测、价格优化 |
让我们选择几个用例来讨论它们的具体需求，以及这些需求如何影响MLOps基础设施的构建方法。
欺诈检测
第一个要讨论的用例是来自财务业务领域的欺诈检测，这个用例对于信用卡持有者来说很容易理解。在理想情况下，金融机构希望在欺诈活动发生之前加以防范，但这并不总是可行。下一个最佳希望是尽快检测这些活动，以便及时缓解并最小化损害。
为了实现这一目标，需要能够进行在线/实时预测或推断，并且可能需要大规模实现。从MLOps基础设施的角度来看，它需要提供一个可扩展、低延迟和高度可靠的预测服务。这并不意味着MLOps堆栈的其他部分不重要，而是这个用例表明在线预测服务在MLOps基础设施构建策略中应优先考虑。
流失预测
另一个有趣的用例是来自电信业务领域的流失预测，这是一个竞争激烈的市场。流失预测用例需要对客户、其档案、趋势、活动等有全面的了解。这个ML用例通常需要来自多个数据源的客户数据，这意味着与数据相关的出错机会相当大。对于任何中型到大型电信公司来说，可能会有多个ML模型。每周和每月的客户流失率受到业务领导的高度监控和跟踪。
对于这个用例，易于监控和调试模型性能下降是非常重要的。从MLOps基础设施的角度来看，除了ML管道的自动化外，还需要提供相当全面的ML可观测性能力，以便数据科学家和业务领域专家能够进行ML模型跟踪，并轻松可视化漂移，以了解情况并比较基线和生产模型的性能。
贷款批准和信用评分
在高度监管的行业（如医疗、金融和运输）中，遵守相关法规至关重要。这突显了这些行业中强大ML治理的重要性，这涉及到实施流程和机制，以确保ML系统公平、透明和负责任。
对于像贷款批准和信用评分这样的用例，任何对受保护类别的偏见的感知展示都可能引发政府机构的调查。MLOps涉及以系统化和可重复的方式开发和部署ML模型，是ML治理的关键组成部分。
注：ML治理
ML模型治理不是一种技术，而是一种借鉴公司治理并针对ML模型量身定制的过程。一般原则仍然适用，例如访问控制和活动跟踪。根据DataRobot的文章《什么是模型治理？》，ML模型治理是组织控制访问、实施政策和跟踪模型及其结果活动的整体过程。
MLOps基础设施需要提供的具体能力可能包括生产中所有模型的访问控制管理、模型历史记录跟踪、模型及其预测的监控等。
通过了解组织的核心ML用例及其优先级，并从其需求出发，提取的见解将有助于确定MLOps基础设施中哪些部分更重要，以及在构建MLOps标准堆栈时的合理起点。
技术
MLOps基础设施只是有效ML开发生态系统中的一部分。其他两个重要的基础设施部分是DevOps和DataOps。DevOps基础设施是自动化和简化的工具和流程集合，促进协作软件开发和部署，为高效ML开发提供基础。DataOps基础设施通过自动化工具在整个数据生命周期中简化协作数据管理，涉及特征工程，特别是与机器学习工作流中的特征工程相关。三者基础设施之间的相互作用如图2-1所示。
行动呼吁
我们需要评估当前DevOps和DataOps的成熟度，强调MLOps对它们的依赖，并倡导在识别到的差距对ML开发生命周期产生可衡量影响的情况下进行改进。
另两个对有效ML开发生态系统有重大影响的重要基础设施是计算基础设施和实验基础设施。
计算基础设施
计算基础设施是支持组织扩展其ML项目的关键因素，包括生成大量特征、训练大型和复杂的模型，以及可扩展的模型推理。它提供了针对机器学习工作流独特需求的几个具体功能。其可扩展性确保了动态资源分配，优化了性能和响应能力。GPU加速支持更快的模型训练，特别是对于复杂的深度学习模型。容器化和编排工具使ML模型的一致打包和部署成为可能，而并行处理则提高了如超参数调优等任务的效率。计算基础设施还促进了高效的模型服务和资源监控，实现了成本效益和资源的最优利用。
对于最终将集成到组织在线产品和服务中的ML模型，快速迭代这些模型将导致更快的生产部署时间。在迭代ML模型以找出最佳表现模型时，需要能够通过A/B测试进行实验、测试和验证模型性能。因此，能够快速轻松地运行A/B测试并提供易于直观分析实验结果的实验基础设施对于MLOps基础设施的成功及ML项目投资的成功至关重要。
行动呼吁
我们需要评估这些支持基础设施的成熟度，识别差距或ML开发速度的障碍，并对此进行倡导。
人员
成功的MLOps采纳并不是在真空中发生的。这是一个涉及MLOps基础设施团队、内部客户、利益相关者和关键决策者的协作努力。如果没有这种跨职能的协同，即使是最好的MLOps基础设施也不足以以期望的速度实现ML模型的运营。
对于较小的组织，可能足以从一个由数据工程、DevOps和数据科学团队成员组成的虚拟团队开始。然而，随着在生产中部署和扩展ML模型的需求增加，尤其是将它们集成到核心在线产品和服务中以提供业务价值时，可能需要一个专门的MLOps团队。这个团队应该由能够开发、维护和支持组织MLOps基础设施的优秀人员组成，并建立和执行标准和最佳实践。
识别和对齐内部客户、利益相关者和关键决策者是成功采纳MLOps的关键组成部分。第一步是清楚了解MLOps基础设施的客户和利益相关者。下一步是与这些个人建立持续的双向沟通，涉及他们在MLOps基础设施战略和路线图中，征求他们的反馈和需求，更重要的是，预见他们的需求。
文化
公平地说，大多数组织对AI/ML可以为其业务带来的价值有相当的理解，即使是那些不是数字化出生的组织。对于那些AI/ML项目面临着强大文化和组织障碍的组织，重要的是要有来自高层的积极计划来解决和降低这些障碍。
在本节中讨论的文化挑战是基于假设AI/ML采纳是组织中的主要倡议之一。
公司文化指的是指导公司员工和管理层互动的信念和行为，并帮助定义其身份。成功的MLOps采纳需要将文化元素作为方程式的一部分进行考虑，特别是在以下几个方面：风险承受能力、执行速度、决策过程和协作风格。
风险承受能力
在构建MLOps基础设施的过程中，毫无疑问会遇到涉及风险的情况，例如评估和采纳商业供应商解决方案、探索新的开源技术等。
了解组织文化的风险承受能力水平至关重要，无论是保守的还是适中的。这将影响控制风险所需的努力和时间，以及在风险评估和对齐阶段与更广泛受众沟通的量。
例如，如果发现了一种相对新的开源技术，已证明能够提高模型训练速度。由于这种技术相对较新，因此在处理某些场景时会有未知风险。组织的风险承受能力水平将对获取采纳的绿灯产生重大影响。MLOps基础设施团队需要考虑在验证技术和说服其他人方面投资适当的时间。
执行速度
组织的执行速度通常与其生命周期的当前状态相关。处于生命周期早期的小型组织通常需要快速执行，以完成其产品创意的概念验证或实现产品市场适配。
组织的执行速度将对MLOps基础设施的采纳速度以及对MLOps基础设施需要多快展示对其他组织的影响的期望水平产生重大影响。对于快速发展的组织，MLOps基础设施团队需要优先考虑并以稳定的步伐展示增量进展，而不是追求完美。
最终，MLOps基础设施团队需要以其客户和利益相关者的步伐来运营，以贡献组织的AI/ML目标并使他们满意。
决策过程
大多数成功的组织在重要决策上有相当健康的决策过程，无论是咨询式还是协作式。
在构建MLOps基础设施的过程中，毫无疑问会有许多重要决策需要做出，例如技术和供应商解决方案采纳、模型部署过程、模型访问控制的严格程度等。
了解组织的决策过程将帮助MLOps基础设施团队了解在推动特定决策时需要多少时间和努力，以及涉及正确的决策者和影响者。
协作风格
ML项目通常涉及多个利益相关者，包括数据工程师、数据科学家、ML工程师和MLOps基础设施团队。有效的协作对成功采纳MLOps至关重要。如果协作状态不健康，MLOps基础设施团队应优先加强它。这可能需要分配额外的时间和资源来主动协作，例如建立清晰的沟通渠道、定义角色和责任，以及培养协作和信任的文化。
通过优先考虑健康的协作，MLOps基础设施团队可以帮助确保所有利益相关者朝着共同目标努力，并使MLOps采纳过程顺利有效。
一项关于构建ML驱动软件的社会技术方面的定性实证研究识别了导致ML项目问题的三个主要领域：管理层的领导真空、组织孤岛以及组织内部的沟通。这些方面中一些受到组织文化的重大影响，因此，MLOps基础设施团队需要意识到这些挑战并采取主动措施克服或最小化它们。
成熟度水平
与其他技术采纳类似，MLOps采纳不是一次性事件，而是一个持续改进的旅程，以满足组织从探索和原型化AI/ML项目到在多个业务职能中构建先进AI解决方案的不断变化的需求。
MLOps成熟度水平用于跟踪MLOps基础设施的进展和复杂性。它最好作为评估工具，了解组织中MLOps基础设施的当前状态，确定下一步是什么，以及距离先进成熟度水平有多远。
作为一个行业，已达成建立MLOps成熟度模型的共识；然而，对标准成熟度水平的意见不一致。两个广为人知且常被引用的成熟度模型分别来自Google Cloud和Microsoft Azure，如图2-2和图2-3所示。这两个成熟度模型的每个级别的具体细节可以通过快速的互联网搜索轻松找到。
这两个成熟度模型的共同主题是倡导自动化，这直接提高了从模型开发到模型部署到生产的速度，同时确保了适当的版本控制和可重复性。
采用特定的成熟度模型是有益的，但不要让它让你夜不能寐，思考哪个模型是正确的。决定组织应处于哪个级别以及从一个级别推进到另一个级别的速度，需要充分理解其ML用例的具体需求以及MLOps标准堆栈中各种支持基础设施和组件的成熟度。
可以公平地说，实现完全自动化或达到最高水平将使组织能够更快地利用AI/ML的力量创造业务价值，并最大化看到AI/ML投资回报的机会。
Josh Poduska，Domino Data Lab的首席数据科学家，在他的博客《MLOps成熟度的七个阶段》中提供了一种基于MLOps能力和业务价值的成熟度模型。读者可以在Josh的博客上获取关于每个成熟度级别及其相关价值的更多详细信息。
他博客的最后一部分建议每个组织评估自己的MLOps历程，以了解其在成熟度曲线上的位置，并制定计划以推进到下一个级别。然后强调，超越价值拐点的关键是以数据科学为中心的方式紧密集成所有能力。
组织能够推进到更高的成熟度水平时，他们的MLOps基础设施可以更好地帮助提高数据科学团队的效率、生产力和输出，从而带来强劲的AI/ML投资回报。
MLOps基础设施的选择方案
当组织考虑采用技术或基础设施时，例如数据基础设施、IT系统和DevOps基础设施，他们通常会考虑以下三种方法：自建、购买端到端解决方案和最佳实践组合。前两种方法涵盖了极端情况，而第三种则处于中间地带。这些方法同样适用于构建MLOps基础设施。
在讨论这些方法的优缺点之前，我们首先需要明确组织何时最需要并从MLOps基础设施中受益。
一方面，一些刚刚开始进行小规模实验或原型的组织，或仅将AI/ML用于少量简单、非关键用例（例如分析少量客户数据以预测未来的购买模式），对于这些情况，这些组织可以通过笔记本电脑或使用云计算实例（如Jupyter notebook、Pandas、Python和易用的scikit-learn或TensorFlow Lite ML库）来完成这些ML项目。此时不必急于投资构建MLOps基础设施。
另一方面，对于那些ML用例数量超过几十个、存在复杂需求（如使用PB级的大数据进行训练、具有数百万参数的深度学习模型如BERT或GPT，或对在线预测有严格要求，如单数字毫秒级的低延迟和高QPS）的组织，投资MLOps基础设施就显得尤为重要。一些具有类似要求的知名公司包括FAAMG家族中的公司，以及特斯拉和Waymo等自动驾驶汽车公司。处于这一端的公司通常在运营ML模型方面表现出色，因为他们是早期采纳者，并拥有充足的财力和人才资源。这些公司很可能投资资源和人才建设自己的内部MLOps基础设施，其中包括开源工具、自研工具以及少量的供应商解决方案，以满足他们的具体需求。
注：在撰写本章时，OpenAI的ChatGPT在AI/ML新闻中占据了主导地位。ChatGPT代表了聊天生成预训练变换器（Chat Generative Pre-trained Transformer），由OpenAI于2022年11月创建和发布。通俗来说，它是一个相当智能的聊天机器人，经过训练和设计以进行自然对话。与ChatGPT的互动主要通过对话形式进行，用户可以提交各种问题，让ChatGPT撰写简短的报告、总结段落、生成特定主题的课程计划、编写开发网站的代码、制定短途旅行计划或景点推荐等。有关ChatGPT的更多信息，请访问 OpenAI博客。
有大量公司处于中间区域，他们可能会或可能不会建立自己的MLOps基础设施，这取决于他们在采用ML的过程中所处的位置和ML熟练程度，这些都需要时间和经验。博客《ML和MLOps在合理规模下》中提到的“合理规模”一词代表了这一组公司。图2-5中的椭圆形代表了“合理规模”的公司，这些公司可能是ML熟练程度较低的后期采纳者，或是ML熟练程度合理且ML用例较少的数字原生AI初创公司。
随着公司在ML投资和项目的规模扩大，并提升ML能力，他们很可能会考虑建立一个包含一定量的云服务提供商、专门商业供应商解决方案和开源社区工具的MLOps基础设施。组织在选择所需的方法时，不应将其视为一次性事件；明智的组织通常会定期重新审视他们的决策，以查看是否需要进行任何必要的调整。
决定采用何种方法的一个重要因素是MLOps领域的成熟度。MLOps仍处于早期阶段，开源社区的创新和新兴技术以快速的速度出现。在供应商解决方案方面，有众多选项可供选择，这些选项也在快速开发、增强和演变。对于MLOps堆栈的某些部分，市场上有相对明确的领导者，而对于其他部分则有一系列潜在的选择。
以下部分将强调每种选择的一些重要注意事项，并分享一些建议。这些建议适用于刚开始MLOps采纳之旅的公司以及那些处于中期阶段的公司。
自建
这种方法指的是从零开始构建整个MLOps基础设施（MLOps标准堆栈）。这种方式的复杂性相当高，需要大量的工程资源和人才投资。此外，长期维护和技术债务也需要作为评估和决策过程的一部分加以考虑。
高科技公司和早期采纳AI/ML的公司，例如Google、Netflix、Meta、Uber、LinkedIn、Tesla等，通常是从零开始构建自己的MLOps基础设施，这主要是由于需求的迫切性以及他们独特的需求和要求。在五年或更早之前，市场上没有商业供应商解决方案，并且MLOps基础设施中的开源技术非常有限。出于必要性，这些公司会自行构建基础设施，并在过程中进行创新以满足他们的需求。
这些公司大多有大量的ML用例，并跨越多个团队，因此投资构建一个集中式的MLOps基础设施是比较容易的。领导团队较容易理解“一次构建，多团队使用”的模式。
另一个需要自建的理由是他们的独特需求，其中之一是由于其庞大的客户基础（数亿人）而需要在规模上运营。
近年来，一些公司已经开始调整策略，利用成熟的开源技术和商业产品来补充他们的基础设施，以利用新能力或降低维护成本。例如，实验跟踪和ML可观测性就是这种转变的例子。
根据《AI基础设施报告》的一项调查，只有20%的公司在内部构建了他们的基础设施。可以合理预测，随着越来越多的创新来自开源社区和MLOps商业供应商，这一比例将随着时间的推移而下降。
对于处于合理规模范围内的公司，除非他们有一些非常独特的要求或特殊需求，例如严格的治理或合规性，或者ML已成为他们竞争优势的重要组成部分，并且他们的工程团队变得更加先进和熟练，否则强烈建议避免采用这种方法。
购买
这种方法指的是购买并采用一个统一的端到端MLOps基础设施来满足组织的所有需求。上述的自建方法处于光谱的一端，而这种方法则处于另一端。
这种方法对于某些组织来说似乎具有吸引力，具体取决于他们的运营风格、ML/AI采纳的进展、用例的数量等。然而，有几个重要方面需要注意。
这种方法适合以下情况的组织：
- 在ML/AI旅程的早期阶段，并正在进行一些ML/AI的概念验证（POC）。利用云供应商提供的端到端MLOps基础设施将大大加快他们的目标实现并提升ML能力。
- 数字原生初创公司，团队小、带宽和资源有限。利用端到端MLOps基础设施可以使他们专注于ML用例，而不会因为构建基础设施而受到瓶颈。
- 其业务的核心竞争优势不在于MLOps基础设施。例如，房地产、零售、教育、建筑等领域的组织，MLOps基础设施可能不是他们的主要关注点，倾向于依赖托管服务更为合理。
在决定采用端到端MLOps基础设施之前，组织需要考虑几个重要因素：MLOps的成熟度和广度与深度。
对于MLOps来说，仍处于早期阶段，创新层出不穷，新兴技术的引入速度非常快。根据Gartner的数据科学和机器学习技术的炒作周期，MLOps目前正处于“过度期望的巅峰”。
在撰写本章时，MLOps正处于炒作周期的第二阶段的尾端。在端到端MLOps基础设施的背景下，没有一个单一的解决方案或全能平台能够满足ML开发生命周期中的所有需求，包括构建、训练、部署和监控ML模型。
虽然存在许多尝试，但一些知名的云供应商，如Amazon AWS、Google Cloud和Microsoft Azure，正在定位自己为这些全能平台的提供商，并且他们在不断扩展平台功能。随着时间的推移，这些平台无疑将变得高度成熟，能够覆盖组织选择的广泛需求。
在此之前，这些平台在能力方面的扩展趋势很明显，但每个主要组件的具体功能可能较为浅显。换句话说，目前的重点是广度而非深度，这对于满足客户评估的需求来说并不是一个坏策略。缺乏深度的例子包括高度可扩展的模型服务引擎和先进的监控、解释和可观测性。
不同的ML用例类型有着略微不同的需求。处理视频、图像或声音的ML用例与结构化数据用例（例如标记或注释）有不同的需求。如果一个组织的ML用例大多数不是结构化数据，那么值得仔细检查端到端MLOps基础设施在支持这些用例需求方面的能力。
在端到端MLOps基础设施中尚无明确的领导者，并且MLOps的成熟度在炒作周期中还未进一步发展之前，最好不要期望一个能够满足所有用例的完整、统一和端到端的MLOps基础设施。
混合
这种方法指的是为MLOps基础设施的某些部分购买解决方案，而对于其余部分，则选择在内部构建或利用开源解决方案。
随着合理规模范围内的组织在AI/ML采纳旅程中前进，他们的需求将随着时间的推移而变化和发展，具体取决于他们需要处理的ML用例类型、需要支持和扩展的ML用例数量以及ML能力的提升。混合方法为这些组织提供了最大的灵活性来构建MLOps基础设施。然而，灵活性也带来了额外的责任。
这种方法提供的灵活性表现为模块化和自由。
对于MLOps基础设施中常见的或在主要用例类型中变化不大的部分，组织可能希望依赖一两个供应商解决方案。例如，数据处理、管道编排、版本控制和实验跟踪等部分可以视为MLOps基础设施的核心。
对于其他部分，组织可以依赖供应商解决方案或开源解决方案。对于特定需求，如果供应商解决方案在这些领域中处于领先地位并能够满足这些需求，选择供应商解决方案是合理的。这些特定需求包括合成数据生成、高度定制的模型治理和先进的ML可观测性及解释能力。
另一方面，这种方法带来的灵活性也要求在将这些专业解决方案与核心部分集成时付出一些努力。如果这些解决方案具有清晰、良好记录的API和集成点，那么整合负担可以减轻。
灵活性还带来了成本和支持两个方面的问题。购买和集成多个解决方案无疑会产生相关成本，这需要与其他两种方法进行权衡。成本的多少取决于需要集成到核心部分中的专业解决方案的数量和复杂性。
第二个方面是支持。使用多个供应商解决方案时，无法获得“一个脖子可抓”的杠杆作用，组织需要额外投入精力来管理这些开销。
构建MLOps基础设施无疑是一项挑战，因为组织的特定需求、基础设施的运营方式、用例类型和数量、ML能力等因素都需要考虑。在三种方法中，混合方法提供了模块化和灵活性，可能是构建和发展MLOps基础设施以满足当前和未来需求的最有效方法。
在介绍几个值得注意的MLOps基础设施案例研究之前，让我们总结本节的要点。
虽然这可能显而易见，但仍然重要且值得重复。不论组织决定采用哪种方案，强烈建议从对当前和近期未来需要解决的ML用例的良好理解和清单开始。
确保在MLOps基础设施决策过程中，纳入对当前MLOps成熟度的认识，并理解未来会有更好和更创新的解决方案。
将本节提到的建议视为经验法则，而非绝对真理。
让我们以一条相关的推文结束本节，来自Better.com的前CTO Erik Bernhardsson：“有趣的是，CTO最重要的工作之一是供应商/产品选择，而这一点每年都变得越来越重要，因为工具/基础设施领域的发展速度太快了。”
MLOps领域概况
毫无疑问，过去7年中，MLOps领域已经爆炸性增长。数十亿美元已投资于众多与MLOps相关的公司。商业供应商和开源社区的创新层出不穷。学术界对MLOps产生了兴趣，并在其交叉点研究系统和ML，从而成立了MLSys会议以推动这一领域的发展。
任何尝试捕捉MLOps的爆炸性增长都很快会过时，但了解其规模是有用的。Chip Huyen的《机器学习工具景观v2》博客提到，截至2020年12月，有大约300种MLOps工具，并提供了一个良好的可视化图表来探索各种类别。ML可观测性领域也出现了许多创新。“MLOps现状”网站收集了这一证据，并在Airtable中共享，显示约有50家公司专注于提供这方面的解决方案。
作为整体，ML从业者社区在通过博客、书籍、会议等渠道变得更加教育化，并通过共享最佳实践变得更加成熟。
对于任何寻求构建MLOps基础设施或评估当前MLOps基础设施效果的组织来说，了解当前的领域格局以及谁是领域中的关键推动者将是有益的。
平台与工具
无论组织选择哪种方法，清楚理解端到端平台与专业工具之间的区别都是重要的。
专业工具旨在支持ML开发生命周期中的特定部分或子集。例如，Arize用于监控和可观测性，MLFlow和MetaFlow用于ML项目框架。
端到端平台旨在支持整个ML开发生命周期——特征开发、模型开发和训练、模型服务和模型监控。本质上，端到端平台由一组设计为协同工作的专业工具组成。
端到端平台的例子包括AWS SageMaker、Google Vertex AI和Microsoft Azure。
从高层次来看，端到端平台和专业工具在通用性和专业化的光谱上，如图2-6所示。
位于左下角的专业工具旨在支持特征开发和模型训练。位于右下角的工具则专注于模型部署和监控。靠近三角形顶端的工具，例如云服务提供商的平台，属于端到端平台。
一些专业工具最初只专注于ML开发的某一领域，但随着时间的推移，其功能范围扩展至支持相邻领域。换句话说，它们在多个领域中具备专业能力。
在平台方面，来自云供应商的工具，例如AWS、Google Cloud和Microsoft Azure，在能力方面似乎处于领先地位；一些其他平台也紧随其后。了解平台之间差异的一个很好的资源是ThoughWorks提供的MLOps平台比较矩阵。
类似于MLOps技术浪潮之前出现的技术浪潮，随着这一浪潮向炒作周期的后期发展，毫无疑问将会有整合现象出现，专业工具和平台领域都将出现明确的领导者。五年或十年后，这一领域的变化将会非常值得期待。
案例研究
自2010年甚至更早以来，大多数大型互联网公司早早认识到ML/AI的强大潜力，并重金投入将这一力量融入其在线产品中，包括Amazon、Google、Meta、Netflix、Uber、LinkedIn、Twitter、Tesla等。一些知名的在线产品例子包括Netflix的流媒体平台背后的著名推荐引擎和Amazon的电子商务市场。
这些公司拥有庞大的客户基础、大量的ML用例和多样化的ML模型。因此，他们需要一种高效、大规模地将这些ML模型投入实际应用的方法，并且在“MLops”一词被提出之前，他们已经重金投入构建自己的ML基础设施。作为这一努力的一部分，他们接触到MLOps领域并非出于选择，而是出于必要。
对MLOps的最早了解可以追溯到Google在2015年发布的开创性论文《机器学习系统中的隐性技术债务》，该论文强调了ML代码只是现实世界ML系统的一个小部分，周围的基础设施是庞大而复杂的，如图2-7所示。
以下部分将展示两个成功且广为人知的ML平台：Uber Michelangelo和Meta FBLearner。这两个平台旨在支持大规模的ML运营，并由大团队支持。这里的目标不是完全复制它们，而是借鉴它们的最佳实践并了解从中得到的教训。
Uber Michelangelo
Uber Michelangelo 是一个备受宣传且广为人知的ML平台。其发展历程可以在互联网上轻松找到。在Uber的网约车市场业务和Uber Eats的食品配送业务中，有许多重要的ML用例在其业务中发挥了关键作用，如调度、动态定价、需求预测、预计到达时间、餐厅准备时间、欺诈检测等。任何时候生产中的ML模型数量都在数千个以上。
在Uber历史上爆炸性增长的时期，大约在2015年，Uber并没有集中式的方式来开发和部署ML模型，这导致了以下问题：
- 碎片化：多个团队各自构建自己的解决方案，结果造成了大量的重复工作。
- 缺乏杠杆和标准化：各自为政的ML系统不利于团队之间的协作和共享。
- 缺乏最佳实践：导致花费更多时间来解决类似的挑战。ML模型的不可重现性使得在新数据上迭代现有模型变得困难。
- 有限的规模：简单的方法无法随着数据量的增加而轻松扩展，并且资源消耗效率低下。与大数据生态系统没有紧密集成。
大约在2015年，Uber认识到上述挑战拖慢了其业务进展，开始重金投入解决这些问题，构建一个集中式的ML平台，以帮助实现ML的生产化。这项大型工作包括建立一个由产品经理和工程组织组成的集中团队，致力于将Uber Michelangelo打造成Uber内部的一流产品。
根据Michelangelo团队的前工程师Achal Shah的说法，他们采取的应对上述挑战并在Uber实现ML民主化的措施包括：
- 构建和提供标准化的工作流和工具，以提供良好的开箱即用体验和灵活性。
- 提供一套标准化且高效的ML算法实现。
- 提供可扩展的端到端ML工作流，以满足各种大规模ML用例。
- 通过简化使用来民主化和加速ML。
在几年的时间里，Michelangelo团队成功实现了大部分目标，建立了一个全面且集中的平台，涵盖了从数据准备到在线和离线预测以及监控的端到端ML工作流，如图2-8所示。从高层次来看，Michelangelo平台结合了开源和内部开发的解决方案，并与Uber的数据计算基础设施紧密集成。
Michelangelo团队所采用的关键原则之一是将ML开发视同于软件开发。这意味着将ML工件视为代码，如特征管道、模型训练管道、模型开发和部署元数据等。这些工件遵循软件工程最佳实践，包括版本控制、代码审查和严格测试。一个具体的例子是，在将ML模型部署到生产环境之前，会对其进行持出集的评估，以确保其性能与离线评估中的表现差异不大。
主要收获和经验教训
从零开始构建一个支持大规模和多样化用例的ML平台，对于Uber这样的大型ML实践者社区来说，是一项巨大的投资，并且需要一个专门的团队来构建、迭代和支持。其带来的好处也非常显著，因为ML在其在线市场中发挥了关键作用，推动业务发展、提升客户体验和降低成本。
毫无疑问，关键的收获之一是工具和基础设施在推动高效率、提高ML开发过程的速度和降低进入门槛与实验成本方面发挥了重要作用。
在“Michelangelo - Machine Learning @Uber”演讲中，Michelangelo团队负责人Jeremy Hermann分享了他们在构建Michelangelo过程中获得的一些经验教训：
- 提高ML开发速度：让ML实践者使用他们想用或最舒适的工具，同时通过自动化或工具减少复杂迭代工作流每一步的摩擦。
- 数据是ML的氧气：确保提供必要的工具和基础设施，使ML实践者能够轻松快速地访问、计算和分析数据。
- 赋予ML实践者端到端的模型所有权。
- 提供可视化工具来理解数据和模型，并通过隐藏UI中的细节使部署过程快速简便。
- ML平台，如Michelangelo，是一个大型复杂的项目。拥有长期愿景是一方面，但基于用户反馈进行迭代开发将大大增加成功的机会。
Meta FBLearner
Meta（前称Facebook）是将ML应用于为其在Facebook、Instagram、Messenger和WhatsApp平台上的大量用户提供独特和个性化体验的先驱之一。他们多样化的用例包括个性化新闻提要故事、过滤有害内容、搜索结果排序、每天翻译超过20亿条故事以便用户可以使用任何语言进行连接、广告推荐和服务、语音识别、内容理解等。
Meta构建自身ML基础设施的方法与大多数其他公司非常独特，主要由于其操作的大规模以及拥有非常大和多样化的用例。然而，他们实现成熟ML基础设施的过程与其他公司的过程并没有太大偏差。
有效的机器学习高度依赖数据，而Meta从其庞大的用户基础中收集了大量数据，这些用户定期在其平台上互动。每天，从数十亿个故事和数亿张上传的图像中生成数个PB的数据。从基础设施的角度来看，他们认识到需要构建一个巨大的基础设施，以高效存储、移动和计算大量数据，以便他们的研究人员、数据科学家和工程师能够轻松快速地访问数据，以每日为ML模型进行训练。由于Meta操作的数据量和规模庞大，如图2-9所示，面临的挑战是巨大的，需要大量投资、人力和独特且创新的方法。
除了设计和运营自己遍布全球的数据中心外，Meta还设计了专门的硬件来支持各种与ML相关的工作负载，包括模型训练、模型评估、在线推理等。
在Meta，构建ML基础设施的主要目标之一是实现ML的民主化，使得没有强大ML背景的工程师也能快速迭代现有ML模型，以提高其准确性，并快速、轻松地将这些模型部署到生产环境中，同时设置必要的保护措施。推动这一目标的主要动力是，他们庞大的产品领域可以从ML中受益，而他们的工程师人数远远超过数据科学家；换句话说，数据科学家的数量不足以满足ML应用的需求。
2014年底，他们的ML基础设施之旅始于FBLearner的建设，以提供一个支持公司内部构建、训练、部署和服务ML模型的通用平台，如图2-10所示。Feature Store组件提供了存储和访问特征的便捷方式，Flow组件提供了开发和训练ML模型的设施，而Predictor组件则提供了大规模的在线预测。
在Meta，广泛适用于许多ML用例的核心ML工作流是由一小组工作流作者开发的。FBLearner Flow平台的设计考虑到了这一点，旨在从根本上重新定义Meta的机器学习，并将最先进的AI和ML算法置于每位Meta工程师的指尖。其目标是简化工作流的重用和扩展，运行数千个同时进行的自定义实验，并轻松管理ML实验。FBLearner Flow平台作为工作流管理系统，包含三个核心组件：用于分布式工作流的创作和执行环境、用于启动和分析实验的实验管理UI，以及一组预定义的ML管道，用作训练Meta最常用的ML算法的起点。
为了实现这些目标，FBLearner Flow团队采纳了以下指导原则：可重用性、易用性和可扩展性。
可重用性原则通过提供可以以可重用方式组合的构建块来实现，这些构建块包括工作流、操作符和通道。每个工作流实例被称为管道，它是为特定的ML用例创建的，由一组特定于ML的任务组成，如训练和评估特定的ML模型。每个任务通过可以串联在一起并且可以并行执行的操作符定义。操作符是执行的最小单位。每个管道通常需要一些输入来喂给模型训练，管道输出则被持久化到某个地方，输入和输出被表示为通道。
生产力原则通过强大且灵活的实验管理组件的UI来实现，该UI用于自定义、启动和可视化ML管道。该组件设计用于以通用方式解释工作流定义及其输入和输出，并提供插件系统以便进一步定制，以满足各种团队的需求，并与Meta内部系统轻松集成。
全面性原则通过提供一致且严格的工作流验证以及支持各种ML库需求的工具集来实现。
因此，FBLearner Flow获得了广泛采用，超过25%的Meta工程师使用它为Meta的大量用户群体提供个性化体验，并训练了超过一百万个模型。
关键经验和教训
Meta自2014年开始构建FBLearner平台的旅程已被证明是一种有效且可扩展的ML民主化方式。然而，这仅仅是开始，还需要额外和持续的努力和投资来完成剩余的部分，以应对整个ML开发周期，并完全采用MLOps最佳实践，以提高应用ML的速度。
Aditya Kalro，Meta的高级软件工程经理，在2020年由Sam Charrington在TWIML举办的“Facebook的机器学习演变”网络研讨会上分享了以下学习经验：
- 将ML开发视作软件开发的经验教训。ML模型开发和生产化与软件开发有类似的需求，例如流畅且高效的构建和发布流程，使得重新训练模型变得容易，模型监控和调试在模型对用户体验有重大贡献时非常重要。
- ML生命周期包括许多阶段，这些阶段都需要基础设施和工具来提高整体ML开发生命周期的速度和效率。在开始时，FBLearner平台的特征存储组件仅提供了存储和访问特征的支持，特征工程的开发留给了工程师。对于处理非结构化数据的ML用例，如图像分类和语音识别，它们可以极大地受益于标记数据，以使ML算法学习模式并做出准确预测。帮助加速数据标记过程的基础设施或工具将加速ML开发生命周期。
总结
成功的MLOps采纳需要策略和深思熟虑的方法。本章开始时提醒，MLOps采纳策略需要根据每个组织的独特性和各种需求进行定制。然后，强调了组织需要解决的两个关键方面：
- 业务目标与MLOps基础设施目标之间的对齐
- 评估具体的MLOps需求
一个组织的MLOps需求很可能与下一个组织大相径庭。评估需求的一种方法是收集关于以下方面的详细信息：ML用例、MLOps所依赖的技术的当前状态和成熟度、与数据科学和MLOps基础设施相关的组织当前规模和人才，最重要的是他们的文化。
一旦确定了MLOps需求，下一步是确定最合适的方法使MLOps成为现实。三种常见的方法是购买、构建和混合。考虑到MLOps领域中众多的商业供应商解决方案和开源创新，大多数组织可能倾向于购买或混合方法。然而，MLOps的格局正在迅速发展和演变，组织需要仔细评估商业供应商解决方案的成熟度，并清楚了解特定解决方案在端到端平台和专业工具谱系中的位置。
本章以展示两个成功且广为人知的ML平台：Uber Michaelangelo和Meta FBLearner作为结尾。这两个平台旨在支持大规模的ML运营化，并由一个大型团队构建和支持。它们的最佳实践和一些经验教训是组织在踏上MLOps采纳之旅时需要考虑的宝贵见解。
