加州大学伯克利分校博士候选人Rolando Garcia最近在Union.ai首席营销官Martin Stein主持的与行业专家和从业者的小组讨论中介绍了其团队的“操作机器学习：访谈研究”研究论文的发现。主讲嘉宾包括来自Lyft、Recognition、Stripe、Woven Planet和Striveworks等公司的机器学习、软件工程和数据科学专业人士。
讨论的重点是基础设施在机器学习生产中的作用；常见的MLOps实践；挑战和痛点；以及MLOP的工具建议。对话的亮点是该论文发现，“成功的MLOps实践围绕着高速、早期验证和维护多个版本以最小化生产停机时间。”
一项探索ML工程师流程和痛苦的研究
由Rolando和另一位博士候选人Shrya Shankar领导的加州大学伯克利分校学者团队对18名从事聊天机器人、自动驾驶汽车和金融应用的ML工程师进行了半结构化的民族志访谈，以概述成功的MLOps的常见做法，讨论痛点并强调工具设计的意义。
考虑到ML工程的实验性质，本文将MLOps定义为“一组旨在在生产中可靠高效地部署和维护ML模型的实践”。DevOps是软件开发人员和运营团队的结合，MLOps将DevOps原理应用于机器学习。
访谈发现，ML工程师通常执行四项常规任务：
- 数据收集和标记
- 改进ML性能的模型实验
- 通过多阶段部署过程进行模型评估
- ML管道监控生产中的性能下降
访谈还揭示了“决定生产ML部署成功的三个变量：Velocity、Validation和Versioning。”本文对这些变量的定义如下：
- 速度（Velocity）：快速原型设计和迭代想法，例如快速更改管道以应对错误
- 验证（Validation）：早期主动监测管道中的漏洞
- 版本控制（Versioning）：存储和管理生产模型和数据集的多个版本，以记录每一个更改
典型的MLOps痛点源于这三个Vs之间的紧张关系和协同作用。示例包括：
- 开发和生产环境之间的不匹配（速度与验证）
- 数据错误（验证与版本控制）
- 让GPU保持温暖（高速与版本控制）
其他有问题的行为源于行业课堂的不匹配，大多数学习都发生在工作中，以及当开发人员在没有留下适当文档的情况下更换工作（和公司）时，未记录的部落知识成为问题。
在分析MLOps工具时，Rolando等人注意到，工程师们更喜欢增加三个Vs之一的工具，例如提高迭代速度（速度）的实验跟踪工具，以及帮助基于历史版本功能（版本控制）调试模型的功能存储。
本文的关键发现可以总结为成功的MLOps实践，这些实践旨在实现高速、早期验证和维护多个模型版本，以最大限度地减少生产停机时间。
小组讨论
在网络研讨会上，Rolando将他的采访结果与小组特邀发言人的反馈进行了比较，他们通常使用ML工作流协调器Flyte作为基础设施工具，但用于不同的用例。
小组成员包括：
- Varsha Parthasarathy，Woven Planet软件工程师
- DJ Rich，Lyft高级数据科学家
- Brian Tang，Stripe基础设施工程师
- Michael Lujan，软件工程师，Striveworks
- Fabio Gratz，博士，高级软件工程师/ML，Recogni
主持人Martin Stein首先提出了一个重要问题：
我们是否低估了基础设施在ML生产中的作用？
作为致力于地面实况感知的感知工程团队的一员，Varsha的团队将Flyte用于Woven Planet的DAG，并认为：“是的，基础设施被低估了……infra和MLOps是齐头并进的。”
Varsha解释说，ML工程师专注于迭代和实验，而基础设施反过来又为迭代和实验提供了便利——作为一家初创公司，保持GPU的温度并不总是可行的。为了有效地处理宝贵的计算资源，提供缓存的工具将使团队不必重新运行整个模型，因为他们只能重新运行更新的部分。
类似地，支持抽象的模型和数据集的版本控制工具可以有效地重新运行和重新训练模型，这将消除GPU预热时间中不必要的步骤。
在过去的三年里，DJ一直在Lyft开发一个因果预测系统，该系统预测三个月内的预算和定价。预测需要与实验相匹配，并需要整合来自不同团队的模型。Lyft使用的基础设施虽然计算量不大，但必须组合并同步不同的输入。
Brian说，在Stripe，团队将其ML基础设施分解为多个部分，通过培训和笔记预订专注于探索；这反过来又增加了速度。为了提高ML产量，Stripe选择了Flyte，因为它提供了这样的速度，进一步加强了基础设施在ML生产中的作用。
Michael描述了Striveworks如何创建一个内部MLOps平台Chariot，该平台专注于模型的生命周期。它可以上传和注释数据集，根据特定参数对其进行训练，对模型进行编目和服务，并检测模型漂移。
作为一名DevOps工程师，Michael指出Flyte帮助了Striveworks“专注于模型开发部分，而不考虑我们将如何将其产品化。”由于Striveworks使用的Jupyter笔记本电脑不是模型的产品化版本，因此模型生命周期的调度部分可以在不占用GPU的情况下进行。因为Striveworks为政府承包商处理高度敏感的数据，因此需要部署整个平台耶德一气呵成，一个任务Flyte也方便。
Fabio最后描述了他在Recognition的工作，为自动驾驶汽车制造定制加速器。他与一个软件工程团队合作，该团队为感知团队提供了一个MLOps平台，该平台反过来对驾驶汽车的行程进行建模。Fabio说，他们“利用Kubernetes和Flyte等工具来加快实验速度，帮助（我们）跟踪正在进行的实验，并能够复制它们”。
Fabio还描述了为一家ML解决方案提供商组建MLOps团队的情况，该团队构建了一个内部开发平台。他说，有了这个平台，工程师们可以以自助的方式提供培训、开发或生产模型所需的基础设施。他强调了能够“抽象掉通常涉及的工具的复杂性……（因为）不是每个人都能成为基础设施专家，大多数工程师都不想”管理基础设施的重要性。
团队在基础设施方面的投资有多深？
然后，讨论转向了访谈研究中的三点：
- 人们将大量时间花在ML不那么迷人的方面，比如维护和监控ML管道
- ML调试创伤引发焦虑
- 高速行驶有淹没在版本海洋中的风险
Martin请Rolando将为其研究采访的小组的回答与小组成员讲述的经历进行比较。Rolando是否有想要进一步探索的特定领域？
Rolando援引小组成员对基础设施的投资指出，在小公司，工程师通常负责整个MLOps工作流程。当基础设施开发人员离开时，他们的更换通常会转移到“撕裂并更换”整个系统，这可能需要长达一年的ML改进和升级。
然而，他预测，大型公司将“最终融合到他们信任并长期存在的基础设施中。”根据公司文化，该基础设施可能有利于高速或简化版本。
Rolando表示，ML工程师通常将一半的时间用于构建基础设施，另一半则用于执行其研究中列举的四项常规任务：数据收集/标记、实验、评估和监测。如果他们可以避免构建基础设施，只使用开箱即用的MLOps解决方案呢？
基础设施服务是如何外包给第三方的，以及如何将其纳入工作流程？
据Michael介绍，Striveworks的数据科学家和软件工程师经常在整个模型生命周期中标记团队，然后转向创建MLOps平台。他说，这将有助于数据科学家“不必担心这个模型开发生命周期，包括版本控制和调度以及实际服务模型”。
我们需要真正投资，使其在某些用例中更简单，并控制不同的选项。我不想担心我会占用多少资源。
然后你会看到事情的另一端，我是一名数据科学家，我希望能够……在这些模型上进行实验。一旦我们发现这个模型有效，我们可能只需要用新的数据来重新训练这个模型。
作为一名数据科学家，你的发现之旅是什么？你花了什么痛苦才确定了基础设施解决方案？
DJ说，在使用现有工具的同时，他很难转换到新工具。他回忆道：“有趣的是，我一开始就抵制Flyte，因为我对此一无所知。”。“我们在Airflow上，所以我们有工作模型，但我们身边有一位福音传道者，‘你必须使用Flyte’，然后这就容易多了。
UI让我大吃一惊，因为气流太复杂了。Flyte只是把它放在任务上，这让它变得容易多了。此外，[Flyte非常不懂Python…这几乎就像一个产品，因为你只需发送工作的链接，就可以将数据科学家和软件工程师指向数据。
你是如何让ML工程师和数据科学家加入的？
Varsha表示，Woven Planet的数据收集方法在新冠肺炎大流行开始时发生了变化。在新冠肺炎之前，工程师或车辆专家会开车为工程师获取数据，但由于这变得不可行，他们转向了数据驱动的方法：团队会选择一个场景，例如雨天或结冰的道路。预测或规划团队将提供数据，这些数据可以被整理成ML模型可以理解的信息，然后进行模型训练；验证（通过回归测试）；最后，分析。
Woven Planet的ML工程师对其中许多步骤都是用Flyte抽象出来的印象深刻；再加上在Flyte上添加的集成，他们只需要编写自己的代码部分，就可以节省时间和精力。
另一个吸引ML工程师的Flyte功能是：基于内部命名的版本控制和在整个生产过程中的持久性，这有助于模型artifactory。
Varsha表示，“我们对基础设施的投资越多，就越能帮助我们的工程师尽快让自动驾驶汽车上路。”
你在构建运营框架，然后用模型进行快速迭代方面有什么经验？
和Lyft的DJ一样，Brian说Stripe从Airflow DAG转到Flyte引起了一些焦虑。
在Stripe，ML团队负责基础设施，然后由数据科学家或ML工程师处理产品生成和模型。他们成功的关键之一是“尽早（与数据科学家和ML工程师）合作；了解他们想要更好的方法；能够训练他们的模型并生成数据无疑是第一步。下一步是，‘我们将选择哪个平台？’”
Flyte在其功能集和对快速迭代的支持方面击败了入围名单上的其他候选人。此外，“Jupyter笔记本电脑是‘从用户开始就与用户对话’的关键。”与其他平台所需的特设笔记本电脑接口不同，Flyte允许用户通过将代码库导入Flyte DAG进行无缝提取，直接在笔记本电脑上迭代。
Fabio回忆起DAG组织自动化预处理、培训和评估之前的日子，当时MLflow项目需要手动编排。“一旦你的笔记关闭，吊舱就不见了，工作也没了，没有人知道它发生了……我们意识到，我们无法重现六个月前的运行情况，因为我们没有记录所有的超参数。”
Fabio说，为了解决这些限制，Recognition开始将不同的任务链接在一起，然后意识到他们需要自动化流程。他们寻找协调人的依据是四个关键要求：
- 针对不同资源的不同任务
- 不同镜像的不同任务
- 使用Pytorch或Tensorflow进行分布式训练
- Spark集成
Fabio说：“我们访问了Medium上的数据科学家和其他博客，查看了MLOps的前十大编排框架，并试图用我们发现的工具构建一个原型。”。“我们非常沮丧……（然后）我们发现了Flyte。
“它正是做这些事情，”他说。Recognition团队可以在任务级别而不是工作流级别指定资源，在顶层注册，并使用不同的图像运行工作流的不同部分。
当你专注于任务时，工作流程和任务的分离是你真正受益的地方。你有粒度，你可以实际利用你的资源。但我们也知道，笔记本不仅仅是一项任务，它们可能更多。
“Flyte大大提高了我们的生产力，”Fabio补充道。工程师可以根据Recognition的最佳实践配置平台，这样团队就可以将其作为“一种自助服务……而无需为每个团队配备ML工程师或软件工程师。”
你对笔记本和真正实用的、任务驱动的机器学习方法有什么看法？
DJ说，作为一名数据科学家，他认为笔记本是一种必要的邪恶：它们不可靠，也不存在最终版本的代码。然而，人与人之间的互动很重要，尤其是因为很多人已经习惯了使用它们。DJ还认为，笔记本电脑“在版本控制方面对你不利，因为笔记本电脑不断变化……GitHub最近才添加了一个集成，可以让你很好地检查它们……（它们）在状态和调试以及跟踪错误方面不是很有主见。”
DJ描述的问题之一是提取笔记本电脑使用导致的过时数据，并导出过时的代码。然而，“如果你想获得模型开发人员友好的环境，你必须使用笔记本电脑。”
你会给MLOps从业者什么建议？你有什么具体的建议来优化三个Vs：提高速度、尽早验证和一致的版本吗？
Brian说Stripe团队很难测量速度。“我们现在采取了一种非常天真的方式，即查看运行的实验数量，因此拥有一个可以更快迭代的基础设施，可以添加更多的实验。”他说，迁移到Flyte有助于Stripe快速迭代。
Varsha的建议：
对所有内容进行版本化，并确保版本始终是持久的。拥有自己的GPU和工作站：当你进入生产阶段时，情况会大不相同。
她描述了Flyte如何使Woven Planet能够在运行与生产环境相同的GPU云工作站上本地测试模型。
Michael建议创建一个强大的测试用例，“这样你就可以说，‘这是我们试图训练的模型的黄金标准’，然后确保你能够保持最快的时间来创建模型，而用户的痛苦最小。”
他说，Striveworks最初专注于创建不同的组件，但没有那么关注模型本身的质量。
我们有非常强大的数据科学家，他们可以创建自己的模型，我们可以为他们服务，他们了解这个平台。但我们也在研究另一部分，你不是数据科学家，但知道模型是如何工作的，你需要添加排列。您知道您的数据集以及该模型体系结构应该如何工作，并且需要在模型完成后对其进行测试。
DJ表示，Lyft团队在引入和优化指标之前，最初甚至根据多个利益相关者的意见构建了最简单的管道。
我认为我们犯了一个错误。很容易创建一个实际上不在构建最终管道的路径上的管道。”相反，“完整的基础设施需要在管道的第一个版本中表现出来……第一次迭代的一条建议是真正地示意整个过程。这个设计阶段非常重要——我们必须在一年后回到整个过程中，并重做很大一部分。”。
Fabio回忆起三年前他与五名ML工程师组成的团队围绕机器学习服务建立公司的努力。他们没有使用Docker或计算引擎，而是试图让这些部分与Python和他们自己的容器编排器协同工作。
我的提示是，“不要那样做。”有一个行业标准。学习Kubernetes。这个平台的工具种类繁多，数量惊人。学习这个平台，很多悲伤就会消失…只要使用多年来开发的伟大工具。
最终调查结果
Rolando总结了一些精彩的观察：
“从学术角度来看，我们有在真空中评估事物的习惯。这有点像DJ所说的：我们建立了这个模型训练管道，然后我们试图找到一个包装它的应用程序，这是一个错误。”。
“我认为产品验证才是最重要的。如果你开始考虑收入和关键绩效指标等产品指标，那么这将自然而然地推动你与其他利益相关者合作。
“我还认为，在机器学习中，一旦你达到了一定的性能阈值，那么如果你要迭代，对应用程序或软件进行迭代更有意义——也许是启发式或过滤器，而不是机器学习本身。
因此，在开始机器学习之前，先构建应用程序基础设施，然后查看它在全局方案中的位置，然后对模型进行迭代。
工具书类
在YouTube上观看完整的小组讨论：
