paint-brush
最详细的 MLOps 指南:第 1 部分经过@winner2023
2,547 讀數
2,547 讀數

最详细的 MLOps 指南:第 1 部分

经过 Lera Demiyanuk18m2023/10/06
Read on Terminal Reader

太長; 讀書

在本文中,我将详细讨论 MLOps 的概念。此外,我会通过三种方式来做到这一点。首先,理论上 - 通过最合理的 MLOps 方案。然后,从概念上讲,通过该方法中嵌入的工件。最后,通过将 MLOps 理解为一个信息系统。
featured image - 最详细的 MLOps 指南:第 1 部分
Lera Demiyanuk HackerNoon profile picture
0-item

嗨,黑客努恩!在本文中,我将详细讨论 MLOps 的概念。此外,我会通过三种方式来做到这一点。首先,理论上 - 通过最合理的 MLOps 方案。然后,从概念上讲,通过该方法中嵌入的工件。最后,通过将 MLOps 理解为一个信息系统。


那么,让我们开始吧。

什么是 MLOps?


MLOps 抽象分解

这个问题长期以来一直困扰着许多机器学习系统开发团队。通过本文中的这样一个系统,我将了解一个信息系统,其中的一个或多个组件包含一个经过训练的模型,该模型执行整体业务逻辑的某些部分。


与系统的任何其他组件一样,这部分业务逻辑需要更新,以满足不断变化的业务和客户期望。 MLOps 就是这个定期更新的全部内容。

MLOps 定义和解释

MLOps 尚未有一个单一且一致的定义。许多作者都试图给出它,但同时找到清晰且系统的描述是具有挑战性的。


一个可以被认为是这样的:


MLOps 是一门工程学科,旨在统一 ML 系统开发 (dev) 和 ML 系统部署 (ops),以标准化和简化生产中高性能模型的持续交付。


让我们重点介绍 MLOps 定义的关键部分:


  • 工程学科
  • 旨在统一机器学习系统的开发和部署流程
  • 标准化和优化新版本的持续交付
  • 高性能型号


因此,MLOps 是一种针对 ML 模型的 DevOps。

MLOps 出现的历史

人们很容易相信这样的工程学科起源于一家大型 IT 公司。因此,我们可以相信 MLOps 作为一种有意义的方法起源于 Google 的理论,当时 D. Sculley 试图从将 ML 模型输出到扩展的平凡任务中节省精力和时间。 D. Sculley 现在被广泛称为“MLOps 教父”——在网上很容易找到同名的播客


D. Sculley 开始从团队技术债务的角度考虑模型工作。是的,可以快速发布新版本的模型,但支持最终系统的成本将对公司的预算产生重大影响。


他的工作成果是论文“机器学习系统中隐藏的技术债务》于2015年在NeurIPS会议上发表。这篇文章的发表日期可以认为是MLOps存在的起点。

MLOps 成熟度级别:最著名的模型

与大多数 IT 流程一样,MLOps 也有成熟度级别。它们帮助公司了解他们现在所处的位置以及如何进入下一个水平(如果有这样的目标)。此外,普遍接受的成熟度确定方法可以让您确定您在竞争对手中的位置。

GigaOm MLOps 成熟度模型

描述最全面且基本上易于理解的模型来自分析公司GigaOm 。它最接近所有模型中的能力成熟度模型集成(CMMI)。这是一套改进组织流程的方法论,同样由 0 到 4 5 个级别组成。


GigaOm 的 MLOps 成熟度模型


GigaOm 的模型将每个成熟度级别分为 5 个类别:策略、架构、建模、流程和治理。


在构建机器学习系统的早期阶段,以此模型为指导,您可以提前考虑重要方面并减少失败的机会。从一个成熟度级别转向更高的成熟度级别给团队带来了他们以前可能没有意识到的新挑战。

Google MLOps 成熟度模型

值得注意的是,Google 也有其MLOps 成熟度级别模型。它是最早出现的之一。它很简洁,由 3 个级别组成:


  • 0级:手动过程
  • 第 1 级:机器学习管道自动化
  • 2 级:CI/CD 管道自动化


人们很难不认为这个模型类似于画猫头鹰的指导手册。首先,手动完成所有操作,组装 ML 管道,并最终确定 MLOps。也就是说,描述得很好。

Azure MLOps 成熟度模型

如今,许多使用机器学习的大公司已经编制了自己的成熟度模型。 天蓝色,它使用类似的方法来区分级别,包括在内。然而,它们比谷歌的还要多:


  • 0 级:无 MLOps
  • 第 1 级:DevOps,但没有 MLOps
  • 第 2 级:自动化培训
  • 第 3 级:自动化模型部署
  • 第 4 级:完全 MLOps 自动化操作


所有突出显示的模型都集中在大约一件事上。在零级别,他们没有任何机器学习实践。在最后一级,他们实现了 MLOps 流程的自动化。中间总是有一些与增量流程自动化相关的不同内容。 Azure 具有训练过程和模型部署的自动化。

MLOps 概念框架

您如何描述与 MLOps 概念相关的所有流程?令人惊讶的是,三名德国人 - 文章的作者“机器学习操作 (MLOps):概述、定义和架构” - 甚至设法将它们封装在一张图表中。他们进行了一项实际研究并详细描述了 MLOps 的概念。


具有功能组件和角色的端到端 MLOps 架构和工作流程


它可能会令人生畏,因为它有许多相互作用的元素。然而,上面提到的成熟度级别的许多特征都可以在其中找到。至少自动化管道、CI/CD、监控、模型注册表、工作流编排和服务组件。


让我们讨论一下这张图并更详细地讨论每一个图。

MLOps 核心流程

该方案的主要部分是水平块,其中描述了 MLOps 的程序方面(它们被分配了字母 A、B、C 和 D)。它们中的每一个都是为了在确保公司机器学习服务顺利运行的框架内解决特定任务而设计的。为了便于理解该方案,最好不按顺序开始。

实验

如果一家公司提供机器学习服务,那么员工就在 Jupyter 中工作。在许多公司中,这是所有机器学习开发流程都集中的工具。这是大多数需要实施 MLOps 实践的任务开始的地方。


让我们考虑一个例子。 A公司需要利用机器学习来自动化部分流程(假设有相应的部门和专家)。解决任务的方法不太可能预先知道。因此,执行者需要研究问题陈述并测试其可能的实现方式。


为此,机器学习工程师/机器学习开发人员为各种任务实现编写代码,并评估通过目标指标获得的结果。所有这些几乎总是在 Jupyter Lab 中完成。在这种形式下,需要手动捕获大量重要信息,然后比较它们之间的实现。


这种活动称为实验。这意味着获得一个有效的机器学习模型,可以进一步用于解决相关问题。


图中所示的块 C 描述了进行 ML 实验的过程。


端到端 MLOps 架构中的 ML 实验区

分析任务范围内可用的数据

机器学习开发中的许多决策都是基于分析公司可用的数据而做出的。不可能在低质量数据或不存在的数据上训练具有目标质量指标的模型。


因此,弄清楚我们获得了哪些数据以及我们可以用这些数据做什么非常重要。例如,为此,我们可以:


  • 使用 Jupyter 或 Superset 进行 ADHoc 研究
  • 标准 EDA(探索性数据分析)


只有与语义和结构分析相结合才能更好地理解数据。


然而,只有有时候,数据准备是在项目团队的控制范围内的。在这种情况下,必然会带来额外的困难。有时在这个阶段,很明显没有必要进一步开发项目,因为数据不适合工作。

质量数据集的形成

当对可用数据有信心时,有必要考虑预处理规则。即使有大量合适的数据,也不能保证它不包含遗漏、扭曲的值等。应该提到术语“输入数据质量”和众所周知的短语“垃圾输入 - 垃圾输出”这里。


无论模型使用得多么好,它在低质量数据上都会产生糟糕的结果。在实践中,许多项目资源都花费在创建高质量的数据集上。

ML 模型训练和验证

经过前一阶段之后,在进行实验时考虑训练模型的指标是有意义的。在所考虑的块的框架内,实验包括将机器学习模型的训练和验证联系起来。


该实验包括使用在准备的数据集上选定的一组超参数来训练所需版本的模型的经典方案。为此,数据集本身分为训练样本、测试样本和验证样本:


  • 前两个用于选择最佳的超参数集
  • 第三个是最终验证和确认,在选定的超参数集上训练的模型在未参与超参数选择和训练过程的未知数据上表现良好


您可以阅读有关验证示例的更多信息本文

将代码和超参数保存在存储库中

如果模型学习指标良好,则模型代码和所选参数将存储在公司存储库中。


实验过程的基本目标是模型工程,这意味着选择最佳算法和最佳超参数调整。


进行实验的困难在于开发人员需要检查 ML 模型操作参数的许多组合。我们并不是在谈论所使用的数学仪器的不同变体。


一般来说,这需要工作。如果在模型参数组合的框架内没有达到所需的指标该怎么办?

特征工程

如果无法实现 ML 模型操作所需的指标,您可以尝试使用新特征扩展数据集对象的特征描述。由于它们,模型的上下文将会扩展,因此,所需的指标可能会得到改善。


新功能可能包括:


  • 对于表格数据:现有对象属性的任意转换 - 例如,X^2、SQRT(X)、Log(x)、X1*X2 等。
  • 基于主题领域:体重指数、一年逾期贷款还款次数等。


端到端 MLOps 架构中的数据工程专区


让我们看一下图中与特征工程相关的部分。


块 B1 旨在形成一组用于转换可用源数据并从中获取特征的要求。组件本身的计算是根据机器学习开发人员输入的“公式”从这些经过预处理和清理的数据中执行的。


必须指出的是,使用特性是迭代的。应用一组功能,可能会想到一个新想法,并在另一组功能中实现,如此循环往复。这在图中明确显示为反馈循环。


块 B2 描述了向数据添加新特征的直接过程。


连接和检索数据源是非常复杂的技术操作。为了简单起见,我将假设团队可以访问多个源,并且有工具可以从这些源(至少是 Python 脚本)卸载数据。


数据清理和转换。此阶段几乎与实验块 (C) 中的类似步骤相同 - 数据准备。在第一个实验中,我们已经了解了训练 ML 模型需要哪些数据以及采用什么格式。剩下的就是正确生成和测试新功能,但为此目的的数据准备过程应尽可能自动化。


新特征的计算。如上所述,这些操作可以包括简单地转换数据元组的一些元素。另一种选择是运行单独的大型处理管道以将单个功能添加到同一数据元组。无论哪种方式,都会有一组按顺序执行的操作。


添加结果。先前操作的结果将添加到数据集中。大多数情况下,特征会批量添加到数据集中以减少数据库负载。但有时需要即时执行(流式传输)以加快业务任务的执行速度。


尽可能有效地使用获得的特征至关重要:在公司其他 ML 开发人员的任务中保存并重用它们。该方案有一个用于此目的的特征存储。它应该在公司内部可用,单独管理,并对其中的所有功能进行版本控制。特征存储有 2 部分:在线(用于流式脚本)和离线(用于批处理脚本)。

自动化机器学习工作流程

在文章开头,我指出,机器学习系统是指一个信息系统,其中的一个或多个组件包含经过训练的模型,该模型执行整体业务逻辑的某些部分。由于开发而获得的ML模型越好,其运行效果就越大。经过训练的模型会处理传入的请求流并提供一些响应预测,从而自动执行分析或决策过程的某些部分。


使用模型生成预测的过程称为推理,训练模型称为训练。可以从 Gartner 借用对两者之间差异的清晰解释。在这里,我将在猫身上练习。


ML 模型的训练和推理数据输入之间的差异


为了生产机器学习系统的高效运行,密切关注模型的推理指标至关重要。一旦它们开始下降,就应该重新训练模型或用新模型替换。大多数情况下,它是由于输入数据的变化(数据漂移)而发生的。例如,有一个业务问题,模型可以识别照片中的纸杯蛋糕,并将其作为输入。示例中的吉娃娃狗是为了保持平衡:


带有纸杯蛋糕和吉娃娃狗的验证码示例


原始数据集中的模型对吉娃娃狗一无所知,因此预测不正确。因此,有必要更改数据集并进行新的实验。新车型应该尽快投入生产。没有人禁止用户上传吉娃娃狗的图片,但他们会得到错误的结果。


现在来看更多现实世界的例子。让我们考虑一下市场推荐系统的开发


根据用户的购买历史、类似用户的购买以及其他参数,模型或模型集合会生成带有推荐的块。它包含定期计算和跟踪购买收入的产品。


发生一些事情,客户的需求发生变化。因此,他们的建议不再相关。对推荐产品的需求下降。所有这些都会导致收入减少。


接下来的经理们尖叫着要求明天之前恢复一切,但结果却毫无结果。为什么?没有足够的新客户偏好数据,因此你甚至无法制作新模型。您可以采用一些推荐生成的基本算法(基于项目的协同过滤)并将其添加到生产中。这样,建议就会以某种方式起作用,但这只是一个临时的解决方法。


理想情况下,该流程的设置方式应该是根据指标开始重新训练或试验不同模型的过程,而无需经理告诉他们这样做。最好的产品最终将取代目前生产的产品。在图中,这是自动化 ML 工作流管道(块 D),它由某些编排工具中的触发器启动。


端到端 MLOps 架构中的 ML Production Zone


这是该方案中负载最重的部分。 D区块的运行涉及到几个关键的第三方组件:


  • 工作流协调器组件,负责按指定的计划或事件启动管道
  • 特征存储,从中获取模型必要特征的数据
  • 模型注册表和 ML 元数据存储,其中放置在启动 Pipeline 工作后获得的模型及其指标


该块本身的结构结合了实验和功能开发 (B2) 块的阶段。考虑到这些都是需要自动化的流程,这并不奇怪。主要区别在于最后两个阶段:


  • 出口型号
  • 推送到模型注册表


其余步骤与上述相同。


另外,我想提及编排器运行模型再训练管道所需的服务工件。这是存储在存储库中并在选定服务器上运行的代码。它的版本控制和升级遵循软件开发的所有规则。该代码实现了模型重新训练管道,结果取决于其正确性。


通常,各种机器学习工具会在代码中运行,其中会执行管道步骤,例如:


  • 气流编排器运行代码来执行管道的各个阶段
  • Feast 根据命令卸载有关数据集中特征的数据
  • 然后,ClearML 创建一个新数据集,并使用从其自己的存储库中获取的一组必要的模型性能指标运行实验
  • 调查完成后,ClearML 将模型及其性能指标保存到存储中


这里值得注意的是,一般不可能实现实验的自动化。当然,可以将 AutoML 概念添加到流程中。然而,目前还没有公认的解决方案可以对任何实验对象产生相同的结果。


一般情况下,AutoML 的工作原理如下:


  1. 以某种方式生成一组模型操作参数的多种组合
  2. 对每个结果组合运行实验。修复每个实验的指标,根据这些指标选择最佳模型
  3. AutoML 可以完成初级/中级数据科学家在或多或少的标准任务中所做的所有操作


自动化已经得到了一些处理。接下来,我们需要组织将新版本的模型交付到生产中。

服务和监控模型

需要 ML 模型来生成预测。但机器学习模型本身是一个文件,无法如此快速地生成它们。你经常可以在互联网上找到这样的解决方案:一个团队采用 FastAPI 并围绕模型编写一个 Python 包装器,以便你可以“遵循谓词”。


从收到 ML 模型文件的那一刻起,事情可以通过多种方式展开。团队可以去:


  • 编写构建 RESTfull 服务的所有代码
  • 实现所有围绕它的环绕
  • 将其全部构建到 Docker 镜像中
  • 然后从该图像的某个地方,您将构建一个容器
  • 以某种方式扩展它
  • 组织指标收集
  • 设置警报
  • 设置推出模型新版本的规则
  • 还有很多其他的事情


对所有模型执行此操作并在将来维护整个代码库是一项劳动密集型任务。为了使其更容易,出现了特殊的服务工具,其中引入了 3 个新实体:


  • 推理实例/服务
  • 推理服务器
  • 服务引擎


推理实例或推理服务是一种特定的 ML 模型,准备接收查询并生成响应预测。这样的实体可以代表 Kubernetes 集群中的一个子节点,其中包含一个容器,该容器具有必要的 ML 模型和运行它的技术工具。


推理服务器是推理实例/服务的创建者。推理服务器有多种实现。每个框架都可以与特定的机器学习框架配合使用,将其中训练的模型转换为即用型模型,用于处理输入查询和生成预测。


服务引擎执行主要管理功能。它确定将使用哪个推理服务器、应启动生成的推理实例的多少副本以及如何扩展它们。


在正在考虑的方案中,没有模型服务组件的此类详细信息,但概述了类似的方面:


  • CI/CD组件,部署准备在生产中运行的模型(可以将其视为Serving Engine的版本之一)
  • 模型服务在可用的基础设施内,组织 ML 模型的预测生成方案,适用于流式处理和批处理场景(可以将其视为推理服务器的版本之一)


ML生产区的CI/CD组件


对于 Serving 的完整堆栈示例,我们可以参考 Seldon 的堆栈:


  • Seldon Core 是服务引擎
  • Seldon ML Server 是推理服务器,它准备通过 REST 或 gRPC 访问模型
  • Seldon MLServer Custom Runtime 是推理实例,是任何需要运行示例以生成预测的 ML 模型的 shell 实例。


甚至还有一个用于实现服务的标准化协议,所有此类工具实际上都强制支持该协议。它被称为 V2 推理协议,由几个著名的市场参与者 - KServe、Seldon 和 Nvidia Triton 开发。

服务与部署

在各种文章中,您可能会找到对作为单个实体进行服务和部署的工具的引用。但是,了解两者目的的差异至关重要。这是一个有争议的问题,但本文将这样阐述:


  • 服务 - 创建 API 模型以及从中获得预测的可能性。最后,您将获得一个内部包含模型的服务实例。
  • 部署 - 分发必要数量的服务实例来处理传入请求(可以表示为 Kubernetes 部署中的副本集)。


许多策略可用于部署模型,但这些策略不是特定于 ML 的。顺便说一句,Seldon 的付费版本支持多种策略,因此您只需选择此堆栈即可享受一切的运作方式。


请记住,必须跟踪模型性能指标。否则,你将无法及时解决问题。如何准确跟踪指标是一个大问题。 Arize AI在此基础上建立了整个业务,但没有人取消 Grafana 和 VictoriaMetrics。

计划启动

鉴于上面写的所有内容,事实证明 ML 命令:


  • 生成数据集
  • 在 ML 模型上对它们进行实验
  • 开发新功能以扩展数据集并提高模型质量
  • 将最佳模型保存在模型注册表中以供将来重用
  • 定制模型的服务和部署
  • 定制生产中模型的监控以及当前模型的自动重新训练或创建新模型


它看起来代价高昂,而且有时只是合理的。因此,图中有一个单独的 MLOps 项目启动 (A) 块,负责合理的目标设定。


端到端 MLOps 架构中的 MLOps 项目启动区


IT主管的推理示例可以说明这里的思维方式。一位受到启发的项目经理找到他,要求安装一个新平台来构建机器学习系统。如果两者的行为都符合公司的最佳利益,IT 总监将澄清以下问题:


  • 您打算使用新的机器学习系统解决什么业务问题?
  • 您为什么决定新的机器学习系统应该解决这个问题?
  • 改变流程或雇用更多技术支持人员会更容易、更便宜吗?
  • 您在哪里可以看到构成您当前选择基础的机器学习系统组件的比较分析?
  • 所选的机器学习系统架构将如何帮助解决业务问题?
  • 您确定机器学习具有解决已识别问题所需的数学工具吗?
  • 解决方案的问题陈述是什么?
  • 您从哪里获取数据来训练模型?您知道准备模型需要哪些数据吗?
  • 您已经检查过可用数据了吗?
  • 数据质量是否足以解决模型问题?


IT主管会被贬为大学老师,但会节省公司的钱。如果所有问题都得到解答,那么就确实需要机器学习系统。

下一个问题:我需要在其中进行 MLOps 吗?

取决于问题。如果您需要找到一次性解决方案,例如 PoC(概念验证),则不需要 MLOps。如果必须处理许多传入请求,则需要 MLOps。从本质上讲,该方法类似于优化任何公司流程。


为了向管理层证明 MLOps 的必要性,您需要准备以下问题的答案:


  • 什么情况会好转?
  • 我们会节省多少钱?
  • 我们是否需要扩大人员?
  • 我们需要买什么?
  • 从哪里获得专业知识?


接下来要做的就是重新参加IT总监考试。


挑战仍然存在,因为团队还必须确信需要改变他们的工作流程和技术堆栈。有时,这比向管理层索要预算更困难。


为了说服团队,有必要准备以下问题的答案:


  • 为什么旧的工作方式不再可行?
  • 改变的目的是什么?
  • 技术栈会是什么?
  • 向谁学习什么?
  • 公司将如何协助实施变革?
  • 需要多长时间才能做出改变?
  • 那些没能成功的人会怎样?


正如您所看到的,这个过程并不简单。

小结论

到这里我就完成了对 MLOps 方案的详细研究。然而,这些只是理论上的方面。实际的实施总是会揭示出可以改变很多事情的额外细节。


在下一篇文章中,我将讨论:


  • MLOps 伪影
  • MLOps 作为信息系统
  • MLOps 开源:Kubeflow vs. MLflow vs. Pachyderm


感谢您的关注!