MLOps 堆栈画布-CFANZ编程社区

机器学习操作(MLOps) 定义了与语言、框架、平台和基础设施无关的实践来设计、开发和维护机器学习应用程序。然而，在生产中使用 ML 意味着许多相互作用的组件。此外，随着当前 MLOps 平台和框架数量的爆炸式增长，跟上发展步伐具有挑战性。ML 采用者的主要问题之一是技术集成和兼容性。

根据目前的调查，49% 的组织在集成其 ML 工具、框架和语言技术堆栈时遇到了挑战。这一挑战的原因是 ML 技术仍在发展并处于早期阶段。此外，MLOps 工具的开发速度很快，使得采用这种快速发展的基础设施难以将 ML 系统可持续地投入生产。

要为机器学习操作指定架构和基础设施堆栈，我们建议使用通用的 MLOps 堆栈画布框架，该框架设计为应用程序和行业无关。 我们与CRISP-ML(Q) 模型保持一致，描述 MLOps 堆栈的 11 个组件，并将它们与 ML 生命周期和“AI就绪”级别对齐，以选择适量的 MLOps 流程和技术组件。

MLOps 堆栈画布

CRISP-ML(Q) 提供了一个流程——我们将在机器学习开发生命周期中执行的一组步骤。ML 开发的另一个方面是基础设施组件，例如成功的 ML 模型操作所需的工具、平台和框架（参见图 1）。

MLOps 堆栈画布_数据

图 1. 将 CRISP-ML(Q) 流程模型映射到 MLOps 堆栈。

因此，为 MLOps 构建基础架构堆栈是 ML 项目的下一个重要部分。然而，鉴于 ML 开发过程模型和操作缺乏标准化以及工具数量不断增加，对于许多有抱负的 ML 团队来说，创建基础设施堆栈是一项艰巨的任务。鉴于围绕 MLOps 工具的炒作，拥有少量数据的小型团队得到的印象是 MLOps 解决方案需要大量基础设施投资。

根据Algorithmia工资最近进行的一项调查^[1]，“ML 的第二大挑战是技术集成和兼容性”，这表明许多组织仍处于 ML 生命周期的初期。为了支持你理解对 ML 系统的要求和基础设施组件的审计过程，我们建议使用MLOps 堆栈画图框架（参见图 2）。

我们设想 MLOps 堆栈画图框架有助于构建 ML 系统。与规范的商业模型画布类似，我们的画布将 ML 应用程序的整个技术堆栈的主要元素浓缩到一个页面中。该框架通过 MLOps 构建块指导开发团队，让他们回答与 MLOps 基础设施相关的问题并确定必要的工具链。

MLOps 堆栈画布的目的是帮助您为 ML 项目中的 MLOps 堆栈构建工作流、架构和基础架构组件。MLOps 堆栈画图框架的范围如下：

确保 ML 模型解决方案具有（业务）影响。
通过考虑三个主要方面来规划 MLOps 堆栈的基础架构组件的成本：

数据和代码管理
机器学习模型管理，以及
元数据管理

通过考虑规划 ML 系统的编排成本以管理其生命周期和可维护性
机器学习资产的持续集成/训练/交付
监控以确保 ML 实现业务目标
报警处理模型故障。
设计 ML 系统以实现：
可复现性：版本控制、特征存储和流水线，
可靠性：模型应该很少中断和安全的故障转移，并且
效率：模型预测快速且尽可能具有成本效益。

通常，MLOps 堆栈画布^[2]由三个主要区域组成：数据和代码管理、模型管理和元数据管理。这些区域中的每一个都包含自己的构建块。

MLOps 堆栈画布_堆栈_02

图 2：用于识别基础架构组件的 MLOps 堆栈画布。

请注意，您可能会以 Miro 板的形式访问 MLOps 堆栈画布，并且它是根据知识共享署名-相同方式共享 4.0 国际许可获得许可的。

在下文中，我们将解释这些块中的每一个。

价值主张

MLOps 堆栈画布的核心组件是价值主张。一般来说，价值主张是一种陈述，概述了客户为什么会从使用我们的软件或服务中受益。我们建立对痛点的认识，问题正在得到解决。ML 系统生成的预测是以后决定提高生产力或改善用户体验的基础。因此，机器学习系统应该为最终用户创造价值。价值主张部分总结了构成软件产品的关键要素以及最终用户应该使用它的原因。目标是专注于解决真正的问题。要创建有效的价值主张声明，我们可以使用 Geoffrey Moore 的价值定位声明模板：

“对于（需要或潜在）的（目标客户），我们的（产品/服务名称）能够（产品类别）带来（利益）。”

我们建议在 CRISP-ML(Q) 过程的初始阶段应用机器学习画布^[3]，以实现 ML 系统的高级原型并指定价值主张。然后可以在MLOps 堆栈画布中重新使用这个价值主张。指定价值主张的另一个实用工具是价值主张画布^[4]。一般来说，要制定 ML 项目的价值主张，我们应该回答以下问题：

我们试图为最终用户做什么？
问题是什么？
为什么这是一个重要的问题？
我们的角色是谁？（ML 工程师、数据科学家、运维/业务用户）
谁拥有生产中的模型？

数据源和数据版本控制

数据是机器学习的基础部分。因此，在阐明价值主张中的业务问题之后，下一个组成部分是“数据源和数据版本控制”。总体目标是估计数据获取、存储和处理的成本，这是 CRISP-ML(Q) 的业务和数据理解以及数据准备阶段的主要活动。数据集开发及其对 ML 算法的进一步处理，例如为未标记的数据点分配标签，可能成本很高。由于我们将 ML 模型和数据视为“一等公民”，因此每次有新数据可用时，可能需要实施数据版本控制来分析模型性能。

此外，数据版本控制可能是解释每个版本的学习模型的预测的监管要求。一般来说，我们区分三个级别的数据版本，如A.Burkov 在“机器学习工程”中描述的：1）数据在训练时被版本化为快照；2) 将数据和代码作为一项资产进行版本控制；3) 使用专门的数据版本控制系统。

应在“数据源和数据版本控制”组件中考虑以下因素：

此数据版本控制是可选的还是强制性的？例如，数据版本控制是否像监管要求一样是系统要求？
有哪些数据源可用？（例如，拥有的、公共的、赚取的、付费的数据）
上述数据的存储空间是什么？（例如，数据湖、DWH）
是否需要手动标注？我们有人力资源吗？
如何为每个经过训练的模型对数据进行版本化？
哪些工具可用于数据流水线/工作流？

除了当前的 MLOps 堆栈画布，我们建议使用Data Landscape Canvas^[5]来创建 ML 项目可用、可访问和所需数据源的概览。

数据分析和实验管理

如 CRISP-ML(Q) 中所述，项目的初始阶段涉及将业务目标转换为 ML 任务、收集和理解数据以及评估项目可行性的任务。为了完成这些任务，我们进行了实验并实施了概念验证。“数据分析和实验管理”模块的重点是机器学习技术对特定业务目标和数据准备的适用性。在这里，我们应该回答以下有关工具的问题：

使用什么编程语言进行分析？（R、Python、Scala、Julia。或者 SQL 是否足以进行分析？）
模型训练是否有任何基础架构要求？
需要计算哪些 ML 特定和业务评估指标？
可复现性：收集了哪些关于 ML 实验的元数据？（数据集、超参数）
有哪些 ML Framework 专业知识？

特征存储和工作流程

作为机器学习中的一项重要活动，特征工程是在模型训练和预测之前将原始输入数据转换为适合机器学习算法的输入格式的特征向量的过程。

“特征存储”的动机，作为 MLOps 堆栈中的一个新组件，需要跨 ML 项目和各种数据科学团队对功能进行管理、可再现性、发现和重用。

特征存储被定义为数据工程和 ML 模型工程之间的接口，用于将特征工程与 CRISP-ML(Q) 模型开发过程分开。特征存储承诺加快 ML 模型的开发和操作化。但是，作为一个高级组件，特征存储可能会增加复杂性，并且每个 ML 项目都需要认真考虑其实现：

这是可选的还是强制性的？我们是否有一个数据治理流程，使得特征工程必须是可重现的？
在训练和预测阶段如何计算特征（工作流程）？
特征工程的基础设施要求是什么？
特征存储“买还是做”？
特征存储涉及哪些数据库？
我们是否为特征工程设计 API？

基础（反映 DevOps）

与 ML 生命周期的几乎每个阶段相关，MLOps 堆栈画布的下一个部分是关于可用 DevOps 基础设施的清单，并提高对 ML 项目中当前 DevOps 原则的认识。这项活动背后的直觉是，我们可以将 DevOps 最佳实践外推到 MLOps 活动中。但是，假设在传统的 DevOps 实践中存在差距。

在这种情况下，我们应该先改进它们，然后再开始更复杂的活动，例如模型和数据版本控制、持续模型训练或特征存储。因此，我们遵循Accelerate State of DevOps 报告的指导方针，并通过回答以下问题对软件交付性能进行自我评估：

我们如何维护代码？使用什么源代码版本控制系统？
我们如何监控系统性能？
我们需要对Notebook进行版本控制吗？
是否有基于主干的开发？
部署和测试自动化：代码库的 CI/CD 流水线是什么？使用什么工具？
我们是否跟踪部署频率、更改的前置时间、平均恢复时间和更改故障率指标？

遵循 DevOps 原则对软件交付性能有直接影响。由于 MLOps 建立在 DevOps 之上，因此为软件项目建立稳定的 DevOps 文化是机器学习项目成功的先决条件。

持续集成、训练和部署：ML 流水线编排

在之前的文章中，我们回顾了用于软件交付的现有 CI/CD 流水线。由于核心软件和 ML 模型可能有不同的发布周期，我们在此块中检查 ML 模型发布的持续集成例程。此外，我们引入了一种新的做法，例如持续训练 (CT)。

通常，持续集成表示数据和模型流水线的构建、测试和打包。持续训练是一个新属性，它是 ML 系统独有的，涉及自动重新训练 ML 模型。我们利用流水线模式，一种软件设计模式，它实现了一系列操作的构建和执行。通常，数据和 ML 流水线包括数据验证、特征和数据选择、数据清洗、特征工程和模型训练等操作。这组无环流水线构造了一个有向无环图 (DAG) 并表示整个工作流作业。

根据成熟度级别，我们可能希望自动化数据和模型训练流水线工作流以操作模型。只要有新数据可用或流水线的源代码发生更改，我们就会触发数据准备和模型训练流水线。在 MLOps 堆栈画布的这个块中，我们应该阐明 CRISP-ML(Q) 模型工程阶段中 CI/CT 的流程和工具链：

预计多久重新训练一次模型？它的触发器是什么（计划的、基于事件的或临时的）？
这发生在哪里（本地或云上）？
ML 流水线的正式工作流程是什么？（例如，数据准备 -> 模型训练 -> 模型评估和验证）使用什么技术堆栈？
需要分布式模型训练吗？我们有分布式训练的基础设施吗？
CI 流水线的工作流程是什么？使用什么工具？
ML 模型的非功能性要求是什么（效率、公平性、稳健性、可解释性等）？他们是如何测试的？这些测试是否集成到 CI/CT 工作流程中？

模型注册和模型版本控制

MLOps 堆栈画布的下一个块涉及 ML 模型注册和版本控制组件，这是 CRISP-ML(Q) 过程中模型评估阶段的重要基础设施部分。机器学习模型与数据和软件代码一样是必不可少的资产。与传统软件工程中的代码版本控制类似，建立模型和数据版本控制实践是机器学习可再现性的基础。根据您的用例，代码或数据的更改可能会触发模型重新训练。

机器学习模型更新的常见原因是“模型衰减”，即随着新数据的到来，模型性能会随着时间的推移而下降。所有 ML 模型都应在健康、金融或军事等受监管行业中进行版本控制和协议化。同时，可能需要通过回滚以前构建的模型来确保向后兼容性。此外，通过跟踪 ML 模型的多个版本，可以通过分析最新训练模型的性能改进来实施不同的部署策略，例如“金丝雀”或“影子”部署。因此，在此类别中，我们回答以下问题：

这是可选的还是强制性的？如果您在生产中有多个模型并且需要跟踪所有模型，则模型注册表可能是强制性的。再现性要求可能是您需要模型版本控制的原因。
应该在哪里存储和跟踪新的 ML 模型？
使用了哪些版本控制标准？（例如，语义版本控制）

请注意，作为高级组件，ML 模型注册和版本控制在 ML 项目的后期阶段可能是合理的。

模型部署

在训练和评估之后，我们进入 CRISP-ML(Q) 的下一阶段并部署 ML 模型。部署 ML 模型表示使其在目标环境中可用以接收预测请求。持续部署 (CD) 是基于预先确定的评估指标将 ML 模型自动部署到目标环境中。在 MLOps 堆栈画布的这一部分中，我们通过回答以下问题来指定 CD 的所有模型公开策略和基础架构方面：

模型的交付格式是什么？
更改的预期时间是多少？（从提交到生产的时间）
预测服务的目标环境是什么？
你们的模型发布政策是什么？是否需要 A/B 测试或多臂老虎机测试？（例如，用于衡量新模型在业务指标上的有效性并决定应该将哪种模型推送到生产环境中）
你的部署策略是什么？（例如需要影子/金丝雀部署？）

预测服务

MLOps 堆栈画布的这个块处理 ML 模型，作为将机器学习模型应用于新输入数据的过程。通常，我们区分预测服务的在线和批量模式。

它们可以使用五种模式来实现，以将 ML 模型投入生产：模型即服务、模型即依赖、预计算、按需模型和混合服务。这些模式中的每一种都需要不同的基础架构设置。例如，模型即服务通过 REST API 实现了一个模型作为分布式服务，用于输入请求，并暗示预测响应的按需模式。同时，预计算模式意味着预测方式是批量的，模型预测是预先计算并存储在关系数据库中的。

为了确定模型服务的环境，我们应该在 MLOps 堆栈画布的预测服务块中回答以下问题：

服务模式是什么？（批量或在线）
是否需要分布式模型服务？
是否需要多模型预测服务？
是否实现了输入数据的预断言？
对模型输出不足（断言后）实施了哪些后备方法？（我们有启发式基准吗？）
您是否需要 ML 推理加速器 (TPU)？
每月或每小时的预期目标预测量是多少？

机器学习模型、数据和系统监控

部署 ML 模型后，必须对其进行持续监控以确保模型质量，这意味着模型服务会产生正确的结果。MLOps 堆栈画布的这一块阐明了在生产中运行 ML 系统的监控部分，并与 CRISP-ML(Q) 流程的第六阶段相关：

这是可选的还是强制性的？例如，您是否需要在预测服务期间评估模型的有效性？您是否需要监控模型的性能下降并在模型开始表现不佳时触发警报？模型是否基于数据或概念漂移等事件进行再训练？
收集了哪些 ML 指标？
收集哪些特定领域的指标？
如何检测模型性能衰减？（数据监控）
如何检测数据倾斜？（数据监控）
需要监控哪些操作方面？（例如，模型预测延迟、CPU/RAM 使用率）
什么是警报策略？（阈值）
是什么触发了模型重新训练？（临时的、基于事件的或计划的）

元数据存储

最后，我们应该指定一个重叠区域，例如元数据管理。元数据管理是对有关每次执行实验、数据和模型流水线的信息的管理，以提供数据和制品沿袭、再现性和调试错误。

元数据存储是一个跨领域组件，涵盖了 MLOps 基础架构堆栈的所有先前元素。根据您的组织和法规要求，您可能需要实施 ML 模型治理流程。这个过程将主要依赖于 ML 元数据。因此，ML 治理的需求是 ML 元数据存储组件。在 MLOps Stack 画布的最后一块中，我们回答了以下问题：

需要收集哪些代码、数据和模型管理中的元数据？（例如，流水线运行 ID、触发器、执行的步骤、开始/结束时间戳、训练/测试数据集划分、超参数、模型对象、各种统计/分析等）
MLOps 生命周期中是否包含任何 ML 治理流程？需要哪些元数据？
什么是文档策略：我们是否将文档视为代码？（示例：数据集的数据表和模型报告的模型卡）
需要收集哪些运营指标？例如，恢复时间、更改失败百分比。

MLOps 的三个困境

MLOps 也有组织方面，属于关于构建 ML 项目基础架构的一般性讨论。

工具：我们应该为任何 MLOps 组件购买、使用现有的开源工具还是构建内部工具？每个决策的风险、权衡和影响是什么？
平台：我们应该就一个 MLOps 平台达成一致还是创建一个混合解决方案？每个决策的风险、权衡和影响是什么？
技能：获得或教育我们自己的机器学习工程人才的成本是多少？

MLOps 堆栈画布范围是帮助您确定 ML 项目中 MLOps 堆栈的工作流、架构和基础架构组件。在此画布中回答问题应该可以让您很好地估计 ML 项目在每个阶段的成本。

MLOps 架构文档化

记录 MLOps 架构的有效方法之一是使用架构决策记录(ARD) 构造。例如，一个 ARD 可以显示 MLOps 堆栈画布中的每个构建块。简化的 ARD 格式由三个基本组成部分组成：

ARD：架构决策的简要描述。
上下文：问题的简短描述。
决策：在这里，我们用详细的解释来描述实际的架构决策。
后果：本节提供架构决策的任何含义。本节也是讨论任何架构权衡的好地方。

以下是此类 ARD 的简化示例。

ARD：数据集版本控制。
上下文：根据监管要求，ML 模型的每次再训练都应与数据集中的变化同步。
决定：每当收集到一批新的数据点时，都应该重新训练 ML 模型。因此，我们决定使用 DVC 来跟踪数据集和 ML 模型。另一种解决方案是 LakeFS。
后果：我们需要将数据存储转移到 DVC 支持的存储机制。此外，还需要提升我们团队成员的技能。

MLOps 成熟度级别

对于许多组织来说，机器学习仍然是一项新技术。推出基于 ML 的软件解决方案会经历“AI 就绪”的三个阶段，这表明公司在将 AI 融入业务方面已经成熟。成熟度可以分为三个阶段：战术阶段、战略阶段和转型阶段（参见图 3）。

MLOps 堆栈画布_堆栈_03

图 3：AI 就绪阶段。

初始阶段称为战术，表示组织探索 ML/AI 技术的能力。合理的方法是从非关键用例和短期项目开始。在构建概念证明时，我们会就机器学习的适用性提出意见。这一阶段的重点显然是学习和理解 ML 可能产生的价值。此外，所有流程主要是手动的，因为几乎没有 MLOps 基础设施，并且正在开发 ML 技能。

下一阶段，称为战略，意味着业务目标协调 ML 用例的数量，并且部分流程是自动化的。通常，团队中有基本的 ML 技能和将 ML 模型投入生产的基本基础设施。与前一阶段的主要区别是利用流水线进行数据准备和模型训练。此外，ML 系统提供端点，例如 REST API，将 ML 模型暴露给目标应用程序。基本的 ML 监控和警报功能也已到位。

在转型阶段，组织使用机器学习来刺激创新。在这个阶段，机器学习被生产为一个完全自动化的过程，这意味着一个复杂的数据平台、广泛采用的机器学习开发通用模式以及 CI/CT/CD 实践。通常，ML 专业知识是维护生产模型的跨职能团队的一部分。此外，组织利用高级 MLOps 组件，例如特征存储、ML 模型和数据版本控制以及模型监控和警报来触发模型重新训练。

一般来说，MLOps 实践和基础设施组件的数量将取决于“AI 就绪”框架中描述的组织的 ML 成熟度。 建议的 MLOps 堆栈画布可能与组织的“AI 就绪”成熟度级别保持一致。从第二阶段“战略”开始应用 MLOps 画布是合理的，其中 AI 用例与业务核心领域保持一致，团队开始利用流水线、实验工作流和专用 API 来公开 ML 模型。

结论

在生产中获取 ML 模型涉及许多相互作用的组件。随着当前 MLOps 平台和框架数量的爆炸式增长，要跟上行业的发展步伐并为 ML 项目创建合适的技术环境是一项挑战。为了指定机器学习操作的架构和基础架构堆栈，我们审查了 CRISP-ML(Q) 开发生命周期并建议了一个应用程序和行业中立的MLOps 堆栈画布。此 Canvas 有助于识别 ML 项目中 MLOps 堆栈的工作流、架构和基础架构组件。在画布中回答问题应该可以合理估计 ML 项目中所需的组件及其成本。