对于火热的MLOps的一些冷静观察-CFANZ编程社区

作为AI工程化的重要内容，MLOps已走入AI新兴技术的舞台中央，国内外头部科技企业和创业型企业已纷纷推出MLOps平台或工具。

火热的MLOps市场，在备受追捧的同时，是否也需要一些冷静的声音和观察呢？

本期IDP Inspiration我们为大家分享的是来自亚马逊 Alxea 团队的资深数据科学家Mihail Eric的MLOps is a mess but that's to be expected。

但请不要因为文章标题而感到担忧，Mihail Eric为我们客观分析了MLOps目前相对混乱的发展现状，但对其前景仍保持乐观，也为想要采用MLOps的组织和机构提出了中肯的建议。

以下是译文，Enjoy!

现在，机器学习仍然是最受关注和吹捧、且有望彻底改变社会每一个角落的技术潮流之一。

然而，机器学习的生态却相对混乱野蛮，如图1是风险投资人 Matt Turck 2021年对ML和数据的回顾。

对于火热的MLOps的一些冷静观察_运维

ML领域每周都有新的基础科学进步出现。初创公司和企业经将新的开发者工具投入市场，试图在许多人投机的市场中占据一席之地。到2025年，该市场的价值在400-1200亿美元之间[1]。

事情发展快速迅猛。

然而，如果你仅仅只是加入讨论，你如何理解这一切？

在这篇文章中，我们想重点讨论机器学习运维的现状，现在处于什么阶段，未来又将如何发展。

作为一名曾在Amazon Alexa等AI前沿组织工作，现在经营一家机器学习咨询公司[2]的从业者，我亲身经历了将ML带入现实世界的考验和磨难。我确实认为，机器学习有很多值得乐观对待的地方，但这条路并非没有减速带。

从谷歌分析（Google Analytics）可以看出，大约87%的读者会看完这段介绍之后离开，因此，我先在这里提供给忙碌读者一份TLDR（Tool Long; Didn't Read）。

TLDR：今天的MLOps在工具、实践和标准方面处于非常混乱的状态。然而，可预测的是，我们仍处于企业更广泛采用机器学习的早期阶段。这种转变在未来几年持续进行后，希望最终由ML驱动的价值创造可以变得更加普遍。

让我们开始详细内容吧。

MLOps包含什么

首先，让我们从一些定义入手。

MLOps是指在生产中用于部署和可靠维护的一系列实践和工具。简而言之，MLOps是机器学习进入并存在于现实世界中的媒介。

这是一个多学科领域，存在于DevOps、数据科学和软件工程的交叉点。

对于火热的MLOps的一些冷静观察_机器学习_02

尽管AI研究仍不断有令人激动的新突破，但今天机器学习已经由实验室研究进入到应用落地的阶段了。

在Gartner技术成熟度曲线中，MLOps正逐渐进入复苏期（Slop of Enlightment），我们已经经历过了对AGI（通用人工智能）的恐惧，也看过《她》[3]的预示，各组织和机构正在探寻如何最大化机器学习收益的重要运维问题。

对于火热的MLOps的一些冷静观察_机器学习_03

MLOps发展现状

如今的MLOps处于野蛮生长的状态，工具种类之丰富甚至超过亚马逊雨林。

举个大多数从业者都会认同的例子：在生产中监控你的机器学习模型是维护一个健壮的高性能架构的关键部分。

然而，当你开始选择供应商时，我甚至随口就能说出6个不同的厂商名字：Fiddler、Arize、Evidently、Whylabs、Gantry、Arthur等。我们甚至还没提到纯数据监控工具。

不要误会我的意思：有的可选很好，但是，这些监控工具真的与众不同，以至于我们需要6个以上吗？即使你选择了监控工具，你仍然必须知道要跟踪哪些指标，这些指标通常高度依赖于上下文。

这进一步引出了一个问题，监控市场真的如此之大，以至于这些厂商都是数十亿美元的公司吗？

至少在监控方面，这些公司对于自己试图拥有的机器学习生命周期的确切部分已达成公式，不过没有明确地理解和接受机器学习技术栈的其他部分。

为了说明这一点，在公司之间，越来越流行将它们为MLOps堆栈构建的每一个新工具都变成某种商店，我们从模型商店（model stores）[4]开始，随后应运而生feature stores[5]。现在我们也有metric stores[6]，以及eval（MLOps Amoeba™)。

对于火热的MLOps的一些冷静观察_数据_04

我们知道了很多正确的部分，但对于真正的关注点的区分(尤其是各环节之间的边界），仍在发展之中。

因此，MLOps工具公司倾向于进入特定的细分市场，然后不可避免地开始将变形虫式管理方式扩展到周围的架构职责中。

我相信，这种不断转移工具职责和不同环节工具之间持续变化的边界线，对于该领域的新手来说尤其困难，迈出MLOps的第一步是一段相当艰难的时期。

我将如今的MLOps比作现代Web开发的状态，新工具不断出现在市场上，大约有300中不同的框架组合，可以用来构建一个简单的Hello World Webapp。

在这些情况下，我对新手的建议是：

聘请更有经验的人来帮助你考虑项目，思考不同的技术，并构建对“愚蠢”问题的开放讨论文化。
仔细思考你需要解决的问题以及解决它所需要的基本方法[11]，而不是被闪亮的工具或平台分心。
花大量时间构建真实系统，以便你可以亲身体验不同工具解决的痛点。

并认识到没有人拥有所有答案，我们都还在寻找正确的做事方法。

你可以以合理的规模开始ML

另一件不值一提的事情是，人们很容易觉得企业中机器学习的复杂性非常高。

根据我和与我交谈过的其他从业者的经验，企业中机器学习应用的成熟度远比我们基于工具和融资环境所认为的要保守得多。

事实是，只有少数超级复杂的AI先行企业（AI-first enterprises）拥有强大的机器学习基础设施来处理他们的PB级数据。

大多数公司没有那么大的数据规模，因此也没有这些类型的ML需求，AI先行企业最终定义了工具和标准。

但实际上，仍有大量优秀的公司仍在制定他们的机器学习战略。

这些“合理规模的ML（ML at reasonable scale）”公司（使用Jacopo的术语[12]）本身就是出色的企业（在自动化、时尚等不同的垂直领域），它们拥有大量专有数据集（数百GB到TB级），这些数据集仍处于采用机器学习的早期阶段。

对于火热的MLOps的一些冷静观察_运维_05

这些公司通过ML获得他们第一场胜利，并且通常有相当容易实现的目标[13]，他们甚至不一定需要这些超先进的亚毫秒级延迟超实时基础设施来开始升级他们的机器学习。

我相信未来10年MLOps面临的一大挑战将是帮助这些类别的企业升级他们的ML。

这将需要构建对缺少ML工程师的团队友好的工具，改进尚未为高级数据工作做好准备的内部基础设施，并获得关键业务利益相关者的文化认同。

这些年来，MLOps 从 DevOps 中学到了什么？

为了帮助我们了解我们在MLOps进程中所处的位置和未来的发展方向，考虑DevOps发展的类比是很有用的。

在企业中采用DevOps实践是一个长达数十年的转型，在引入DevOps之前的很长一段时间里，软件工程和IT（或者说是Ops）团队作为功能独立的实体运作。这种孤立的组织在产品发布和更新方面效率极低。

Google是最早认识到这种低效率的组织之一，并在2003年引入了站点可靠性工程师这一角色，以帮助弥合开发人员和运维人员之间的间隙。

在2009年John Allspaw和Paul Hammond的一次演讲[14]中，DevOps的原则得到了进一步的阐述，他们认为企业应该雇佣“向开发人员一样思考的运维人员”和“像运维人员一样思考的开发人员”。

多年来，随着DevOps的成熟，我们引入了持续集成（和部署）等概念以及已经被全球开发团队广泛采用的的新工具。

好吧，先把这些往事放在一边，让我们回到MLOps的问题。

DevOps是一个用于理解MLOps的有趣案例研究，原因有很多：

DevOps的发展历程强调了新理念被企业采用是一个长期的转型过程，不是一蹴而就的。
它展现了DevOps的推广，同时需要工具的进步和组织中文化观念的转变，两者必须携手共进。
DevOps强调了对具有跨职能技能和专业知识[15]的从业者的需求。孤岛并不受欢迎。

今天的MLOps处于疲惫和混沌的状态，但这是在预期之内的。目前，对于如何围绕基础设施、开发和数据等对MLOps进行清晰的抽象定义，业界还没有统一、清晰的定论。

随着时间的发展，我们将采用新的实践和方法论。新的工具层出不穷，兴起又过时。虽然MLOps仍有很多问题，但关注者和参与者们正在积极提出解决方案。总体而言，MLOps运动仍处于早期阶段。

一些关于MLOps的预测

既然我们已经讨论了MLOps所处的状态，不妨花些时间来描述一些值得期待的事情。

这些趋势的总结，来源于我自己的观察，以及和众多ML从业者的探讨。

从技术和基础架构的角度来看，未来对MLOps的投入将重点集中在以下方面：

机器学习系统的闭环。目前，许多机器学习系统在很大程度上仍然坚持使用从数据源到预测的单项信息流，但这会导致pipeline的崩溃。我们需要达成闭环，使pipeline变得更加智能和灵活。实现这一目标的第一步就是拥有一个良好的监控系统。虽然我在这篇文章的前面部分对监控系统做了一些批评，但我认为我们应该继续考虑在建模层和更上游的数据层对系统进行监控。针对这一话题，Shreya[16]写了很多好文章。
机器学习的声明系统。近年来，随着PyTorch[17]等AI框架和HF Transformers[18]等高级库的出现，ML建模工具已经开始变得大众化。这是一个受欢迎的发展方向，但是我相信在降低工具使用门槛方面，我们还能做更多，比如，在开发设计中为下游用户隐藏一些不必要的实现细节。声明式机器学习[19]是最令人激动的建模发展趋势，它能让新一代的业务领域专家将ML应用到他们的实际问题上。未来的ML工具解决问题的方式将类似于Webflow[20]和其他人为Web开发所制作的工具。
实时机器学习。ML系统在设计理念上是数据驱动的，因此大多数具有最新数据的应用程序，可以进行更准确的预测。实时ML可能带来很多改变，但总得来说，最显著的变化是会带来更新、更快迭代的模型。未来几年，我们会持续在这一领域看到继续看到投资，因为构建实时系统是一项艰巨的基础设施挑战。我应该补充一点，我不相信会有许多公司（尤其是上述“合理规模”的公司）需要实时ML来获得首胜。但最终我们会意识到，一开始就将实时机器学习系统集成到产品中，并不是一项格外巨大的挑战。Chip[21]在这方面做的非常好。
更好的数据管理。数据是每个机器学习系统的命脉，在未来，企业的绝大多数功能都需要ML来驱动，数据将成为每个组织的命脉。然而，对于涵盖数据源、属于筛选与预处理、数据标注和分析在内的全生命周期管理数据的工具，我认为我们还有很长的路要走。我们需要进一步思考，如何才能让数据从业者可以轻松快速回答以下问题：他们拥有什么数据，可以用数据来做些什么，以及他们还需要什么？数据探索性分析工具(Data Discovery Tools)[22]是解决这些问题的早期工具。但根据我的经验，当我们处理非结构化数据时，这些工具的缺陷尤其明显。
将业务洞察（business insight）工具与数据科学/机器学习工作流相结合。业务洞察相关工具一直比数据科学工具更加成熟[23]。造成这种情况的原因与业务分析师的产出往往更容易呈现给业务领导者这一事实有关。因此，普遍的看法是，BI工具投资对组织的下限更加关键。随着大家逐渐认识到，数据科学产出能更直接地为组织带来价值，我相信我们将会看到两个技术栈（指业务洞察工具和数据分析/ML工作流）之间的协同作用越来越大。总而言之，机器学习是一种可以实现更高效运维、指标改进和更佳产品的工具。这样一来，他的目标和BI的目标并没有太大的不同。

现在走出技术，以下是我们看到的一些元趋势(Meta trends)：

人才短缺依然严重。如今，许多组织很难吸引到高素质的机器学习人才。当大型科技公司将AI人才的年薪中位数提高到33万美元[24]时，可以想象招聘领域的竞争是何等激烈。供应端需要数年才能与需求端正常匹配。与此同时，这种短缺继续证明公司对MLOps工具的投资是合理的：如果你无法聘请机器学习工程师，请尝试替换他们！
端到端平台的进一步整合。三大云提供商（AWS、GCP、Azure）和其他专业参与者（DataRobot、Databricks、Dataiku）都在积极尝试为从业者提供端到端的ML工作流。虽然我认为任何端到端解决方案都尚未准备好，但这些公司会做一些事来完善E2E解决方案：1）用大量资本收购较小参与者，2）端到端的使用便利性是以牺牲灵活性和高溢价为代价的，以及3）品牌惰性（即“没有人因购买IBM而丢掉工作”的典型表型）。
机器学习思维的文化培养。随着我们继续获得更先进的工具，组织将围绕其产品和团队采用机器学习的思维方式。在许多方面，这也呼应了随着DevOps原则[25]被采用而发生的文化转变。我们期待看到更全面的系统思维（打破孤岛），增加产品中的反馈循环，以及培养不断尝试和学习的心态。

这是一篇很长的文章，感谢你仍阅读到这里。

虽然如今MLOps仍处在野蛮生长状态，但我对机器学习承诺为社会带来的价值一如既往的乐观。

ML应用的各方面都在有序进行：不断发展、用于构建更好系统的工具链，用于帮助培养下一批从业者的教育[26]产品[27]，以及对于有意识地投资ML对组织至关重要的广泛公式。

未来是光明的。

感谢Goku Mohandas[28]、Shreya Shankar[29]、Eugene Yan[30]、Demetrios Brinkmann[31]和Sarah Catanzaro[32]对本文早期版本的深刻而周到的反馈。好东西是他们的，任何坏笑话都是我的。