用于通过 Azure 机器学习提升机器学习生命周期的机器学习操作 (MLOps) 框架

此客户项目帮助一家财富 500 强食品公司改进了其需求预测。 该公司将产品直接运送到多个零售店。 这一改进帮助他们优化了他们在美国多个区域不同商店的产品库存。 为实现此目的，Microsoft 的商业软件工程 (CSE) 团队与客户的数据科学家合作进行了一项试点研究，为选定区域开发定制机器学习模型。 该模型考虑了：

• 购物者人口统计数据
• 历史和预测天气数据
• 过去的装运数据
• 产品退货
• 特殊事件

优化库存这一目标是该项目的主要组成部分，客户在早期现场试验中实现了显著的销售提升。 此外，与历史平均基线模型相比，团队发现预测平均绝对百分比误差 (MAPE) 降低了 40%。

项目的一个关键部分在于弄清如何将数据科学工作流从试点研究扩展到生产级别。 此生产级别工作流要求 CSE 团队执行以下操作：

• 为多个区域开发模型。
• 持续更新和监视模型性能。
• 促进数据与工程团队之间的协作。

相比生产工作流，如今的典型数据科学工作流更接近于一次性实验室环境。 数据科学家的环境必须适合他们：

• 准备数据。
• 利用不同的模型进行试验。
• 优化超参数。
• 创建“构建-测试-评估-优化”周期。

用于这些任务的大部分工具都有特定的用途，并且不适合自动化。 在生产级别机器学习操作中，必须更多地考虑到应用程序生命周期管理和 DevOps。

CSE 团队帮助客户将操作扩展到了生产级别。 他们实现了持续集成 (CI)/持续交付 (CD) 功能的各个方面，并且解决了可观测性以及与 Azure 功能的集成等问题。 在实现过程中，该团队发现了现有 MLOps 指南中的空白。 需要填补这些空白，以便更好地理解和大规模应用 MLOps。

了解 MLOps 实践有助于组织确保系统生成的机器学习模型就是提高业务绩效的生产质量模型。 实现 MLOps 时，组织无需再将尽可能多的时间用于低级别信息，这些信息与为生产级别操作开发和运行机器学习模型所需的基础结构和工程工作相关。 实现 MLOps 还有助于数据科学和软件工程社区了解如何协同工作，以提供生产就绪的系统。

CSE 团队利用这个项目来解决机器学习社区的需求，处理开发 MLOps 成熟度模型等问题。 这些工作的目标在于，通过了解 MLOps 进程中关键参与者的典型挑战来提高 MLOps 采用率。

参与和技术方案

参与方案介绍了 CSE 团队必须解决的实际挑战。 技术方案定义了创建 MLOps 生命周期的要求，该生命周期与既定 DevOps 生命周期一样可靠。

参与方案

客户按定期计划将产品直接交付到零售市场点。 每个零售店的产品使用模式各不相同，因此每周交付时的产品库存需求也各有区别。 客户使用需求预测方法的目标在于，最大程度提高销售，同时尽量减少产品退货、损失销售机会。 此项目侧重于使用机器学习来改进预测。

CSE 团队将项目分为两个阶段。 阶段 1 重点介绍开发机器学习模型，以支持对选定销售区域内的机器学习预测有效性进行基于现场的试点研究。 阶段 1 成功后即可进入阶段 2，在此阶段中，团队将初步试点研究从支持单个地理区域的最小模型组扩展到所有客户销售区域的一组可持续生产级别模型。 扩展解决方案需要重点考虑一个问题，即解决大量地理区域及其本地零售店的需求。 团队将机器学习模型专用于各个区域中的大型和小型零售店。

通过阶段 1 试点研究确定，专用于一个区域零售店的模型可以使用本地销售历史记录、本地人口统计、天气和特殊事件来优化该区域销售点的需求预测。 四个系综机器学习预测模型为单个区域内的市场网点提供服务。 模型会每周批处理数据。 此外，该团队通过对比历史数据，开发了两个基线模型。

对于第一个版本的扩展阶段 2 解决方案，CSE 团队选择了 14 个地理区域参与其中，包括小型和大型市场网点。 使用了 50 多个机器学习预测模型。 团队需要进一步促进系统增长，并持续优化机器学习模型。 我们很快就会发现，只有当团队遵循机器学习环境的 DevOps 最佳做法原则时，这种大规模机器学习解决方案才可持续。

MLOps 进程为扩展系统提供了一个框架，用于处理机器学习模型的整个生命周期。 该框架包括开发、测试、部署、操作和监视。 它满足经典 CI/CD 过程的需要。 然而，由于相比 DevOps 而言并不成熟，现有 MLOps 指南明显存在差距。 项目团队努力填补其中一些差距。 他们希望提供可确保扩展机器学习解决方案可行性的功能流程模型。

根据此项目开发的 MLOps 进程取得显著的实质改进，提高了 MLOps 的成熟度和可行性。 新进程直接适用于其他机器学习项目。 CSE 团队利用学习成果构建了一个 MLOps 成熟度模型草案，任何人都可以将其用于其他机器学习项目。

技术方案

MLOps 也称为机器学习 DevOps，是一个概括性术语，涵盖了与在生产环境中实现机器学习生命周期相关的理念、实践和技术。 但仍然是一个相对较新的概念。 已经有很多次关于什么是 MLOps 的定义尝试，并且很多人质疑 MLOps 是否可以涵盖从数据科学家如何准备数据到他们最终如何交付、监视和评估机器学习结果的一切内容。 尽管 DevOps 多年来发展了一套基本做法，但 MLOps 仍处于发展初期。 随着它的不断发展，我们发现在融合两个学科的过程中仍然充满挑战，因为两者的技能组和优先级不同，分别侧重于软件/运维工程和数据科学。

要在实际生产环境中实现 MLOps，我们必须克服独特挑战。 团队可以使用 Azure 来支持 MLOps 模式。 Azure 还可为客户提供资产管理和业务流程服务，用于有效管理机器学习生命周期。 Azure 服务是本文中描述的 MLOps 解决方案的基础。

机器学习模型要求

阶段 1 试点现场研究过程中的大部分工作是创建机器学习模型，CSE 团队会将这些模型应用于单个区域中的大型和小型零售商店。 对模型的重要要求包括：

• 使用 Azure 机器学习服务。

• 在 Jupyter Notebook 中开发并在 Python 中实现的初始试验模型。

  注意

  团队会对大型和小型商店使用相同的机器学习方法，但训练和评分数据会因商店的规模而有所不同。

• 需要准备模型消耗量的数据。

• 按批处理而不是实时处理的数据。

• 每当代码或数据发生更改，或者模型过时时，都要进行模型重新训练。

• 在 Power BI 仪表板中查看模型性能。

• 与历史平均基线模型比较，如果 MAPE <= 45%，则模型性能在评分中视为显著。

MLOps 要求

团队必须满足几个关键要求，以从阶段 1 试点现场研究扩展解决方案，在此阶段中，仅为单个销售区域开发了几个模型。 阶段 2 为多个区域实现了自定义机器学习模型。 实现包括：

• 对每个区域内的大型和小型商店进行每周批处理，以使用新数据集重新训练模型。

• 持续改进机器学习模型。

• 在类似 DevOps 的处理环境中，为 MLOps 集成 CI/CD 中常见的开发/测试/打包/测试/部署流程。

  注意

  这表示数据科学家和数据工程师过去常见工作方式的转变。

• 基于商店历史记录、人口统计信息和其他关键变量，代表每个区域中大型和小型商店的唯一模型。 模型必须处理整个数据集，以最大程度地降低处理错误的风险。

• 能够初步扩展以支持 14 个销售区域，并计划进一步扩展。

• 计划为各区域和其他店群额外提供更长期预测模型。

机器学习模型解决方案

机器学习生命周期（也称为数据科学生命周期）大致符合以下高级流程：

此处的部署模型可表示对已验证机器学习模型的任何操作使用。 与 DevOps 相比，MLOps 带来了有关如何将机器学习生命周期集成到典型 CI/CD 过程的其他挑战。

数据科学生命周期未遵循典型的软件开发生命周期。 它包括使用 Azure 机器学习来训练模型和对模型评分，因此这些步骤必须包含在 CI/CD 自动化中。

数据的批处理是体系结构的基础。 两个 Azure 机器学习管道是进程核心，一个用于训练，另一个用于评分。 此图显示了在客户项目初始阶段使用的数据科学方法：

团队测试了几种算法。 他们最终选择了 LASSO 线性回归模型系综和具有分类嵌入的神经网络的集成设计。 团队采用了相同模型，该模型由客户可以在现场存储（大型和小型商店）的产品水平定义。 团队进一步将模型细分为快消品和慢消品。

当团队发布新代码和新数据可用时，数据科学家会训练机器学习模型。 训练通常每周开展一次。 因此，每次处理运行都涉及大量数据。 由于团队会从许多不同格式的源中收集数据，因此，需要调节数据，将其转换为可使用的格式之后，数据科学家才能进行处理。 数据调节需要大量手动操作，并且 CSE 团队将其标识为自动化的首要候选项。

如前所述，数据科学家在阶段 1 试点现场研究中对单一销售区域开发并应用了试验性 Azure 机器学习模型，以评估此预测方法的有用性。 CSE 团队认为试点研究中的商店实现了显著的销售提升。 这一成功证明将解决方案从 14 个地理区域和数千家商店应用于阶段 2 中的整个生产级别是合理的。 然后，团队可以采用相同模式来添加其他区域。

试点模型作为扩展解决方案的基础，但 CSE 团队知道，模型还需要进一步完善以提高其性能。

MLOps 解决方案

随着 MLOps 概念的成熟，团队通常会发现在将数据科学与 DevOps 学科整合在一起的过程中充满挑战。 原因在于学科的主要参与者、软件工程师和数据科学家采用不同的技能组和优先级进行操作。

但也有相似之处可供借鉴。 与 DevOps 一样，MLOps 是由工具链实现的开发流程。 MLOps 工具链包括如下内容：

• 版本控制
• 代码分析
• 生成自动化
• 持续集成
• 测试框架和自动化
• 集成到 CI/CD 管道中的合规性策略
• 部署自动化
• 监视
• 灾难恢复和高可用性
• 包和容器管理

如上所述，该解决方案利用现有 DevOps 指南，但通过强化创建更成熟的 MLOps 实现，从而满足客户和数据科学社区需求。 MLOps 以 DevOps 指南为基础，但具有以下附加要求：

• 数据和模型版本控制与代码版本控制不同：架构和源数据发生更改时，必须对数据集进行版本控制。
• 数字审计线索要求：在处理代码和客户端数据时跟踪所有更改。
• 泛化：模型不同于可重用代码，因为数据科学家必须基于输入数据和方案调整模型。 要为新方案重用模型，你可能需要对其进行微调/传输/学习。 需要训练管道。
• 过时模型：模型通常会随着时间推移而衰减，你需要能够根据需要重新训练它们，以确保它们在生产中保持相关性。

MLOps 的挑战

不成熟的 MLOps 标准

MLOps 的标准模式仍在不断发展。 解决方案通常是从头开始构建，并通过调整以满足特定客户或用户需求。 CSE 团队认识到了这一缺口，并试图在此项目中使用 DevOps 最佳做法。 为满足 MLOps 的其他要求，他们强化了 DevOps 流程。 团队开发的流程是一个可行示例，展示 MLOps 标准模式应该呈现的外观。

技能组中的差异

软件工程师和数据科学家为团队带来了独特的技能组。 鉴于这些不同的技能组，可能难以寻找适合每个人需求的解决方案。 构建一个易于理解的模型交付（从试验到生产）工作流，这一点非常重要。 团队成员必须了解如何在不中断 MLOps 进程的情况下将更改集成到系统中。

管理多个模型

通常需要多个模型来解决困难的机器学习方案。 MLOps 的难题之一是管理这些模型，其中包括：

• 具有一致的版本控制方案。
• 持续评估和监视所有模型。

还需要可跟踪代码和数据世系，才能诊断模型问题并创建可重现的模型。 自定义仪表板可以了解部署模型的执行情况并指示何时进行干预。 团队为此项目创建了此类仪表板。

需要进行数据调节

在这些模型中使用的数据来自多个专用和公共源。 由于原始数据杂乱无章，因此机器学习模型无法按原始状态使用数据。 数据科学家必须将数据调节为可供机器学习模型使用的标准格式。

许多试点现场测试侧重于调节原始数据，以方便机器学习模型处理数据。 在 MLOps 系统中，团队应自动执行此流程并跟踪输出。

MLOps 成熟度模型

MLOps 成熟度模型的目的在于阐明原则和做法，并确定 MLOps 实现中的差距。 这也是一种向客户展示如何逐步提高其 MLOps 能力而不是尝试一次性实现此目的的方法。 客户应将其用作以下操作的指南：

• 估计项目的工作范围。
• 制定成功标准。
• 确定可交付结果。

MLOps 成熟度模型定义五个技术能力级别：

有关 MLOps 成熟度模型的当前版本，请参阅 MLOps 成熟度模型一文。

MLOps 进程定义

MLOps 包括从获取原始数据到提供模型输出（也称为评分）的所有活动：

• 数据调节
• 模型训练
• 模型测试和评估
• 生成定义和管道
• 发布管道
• 部署
• 计分

基本机器学习流程

基本机器学习流程与传统软件开发类似，但也存在显著差异。 此图说明了机器学习流程中的主要步骤：

试验阶段是数据科学生命周期独有的，它反映了数据科学家的传统工作方式。 它与代码开发人员的工作方式不同。 下图更详细地说明了此生命周期。

将此数据开发过程集成到 MLOps 并非易事。 在这里，你将看到团队用于将进程集成到 MLOps 可支持的窗体的模式：

MLOps 的作用是创建协调过程，以有效地支持生产级别系统中常见的大规模 CI/CD 环境。 从概念上讲，MLOps 模型必须包含从试验到评分的所有进程要求。

CSE 团队优化了 MLOps 进程，以满足客户的特定需求。 最值得注意的需求是批处理，而不是实时处理。 在团队开发扩展系统时，他们发现并解决了一些缺陷。 其中最严重的缺陷导致在 Azure 数据工厂和 Azure 机器学习之间搭建桥梁，该团队通过使用 Azure 数据工厂中的内置连接器来实现此目的。 他们创建此组件集以促进触发和状态监测，这是实现流程自动化的必要条件。

另一个根本变化是，数据科学家需要能够将试验性代码从 Jupyter Notebook 导出到 MLOps 部署流程，而不是直接触发训练和评分。

以下是最终的 MLOps 进程模型概念：

MLOps 进程流

下图介绍如何将 CI/CD 开发和发布工作流应用于机器学习生命周期：

• 从功能分支创建拉取请求 (PR) 时，管道将运行代码验证测试，从而通过单元测试和代码质量测试来验证代码质量。 为了验证上游质量，管道还会运行基本模型验证测试，使用一组示例模拟数据验证端到端训练和评分步骤。
• 当 PR 合并到主分支中时，CI 管道将运行相同的代码验证测试和增加时期的基本模型验证测试。 然后，管道将打包项目（包括代码和二进制文件）以在机器学习环境中运行。
• 项目可用后，系统将触发模型验证 CD 管道。 它在开发机器学习环境中运行端到端验证。 将发布评分机制。 对于批量评分方案，将对机器学习环境发布评分管道，并触发管道以生成结果。 如果要使用实时评分方案，则可以发布 Web 应用或部署容器。
• 创建里程碑并合并到发布分支后，就会触发相同的 CI 管道和模型验证 CD 管道。 此时，它们针对发布分支中的代码运行。

可以将上面所示的 MLOps 进程数据流视为做出类似体系结构选择的项目的原型框架。

代码验证测试

机器学习的代码验证测试侧重于验证代码库的质量。 这与任何具有代码质量测试 (linting)、单元测试和代码覆盖率度量的工程项目的概念相同。

基本模型验证测试

模型验证通常是指验证生成有效的机器学习模型所需的完整端到端流程步骤。 它包括如下步骤：

• 数据验证：确保输入数据有效。
• 训练验证：确保可以成功训练模型。
• 评分验证：确保团队能够成功使用经过训练的模型对输入数据进行评分。

在机器学习环境中运行这组完整的步骤昂贵且耗时。 因此，团队在开发计算机上本地进行了基本模型验证测试。 它运行上述步骤，并使用以下各项：

• 本地测试数据集：一种小型数据集，通常是一种模糊处理、签入存储库并用作输入数据源的数据集。
• 本地标志：模型代码中的一个标志或参数，指示代码计划让数据集在本地运行。 该标志告知代码绕过对机器学习环境的任何调用。

这些验证测试的目标不是评估已训练模型的性能。 相反，它是验证端到端流程的代码是否质量良好。 它可确保向上游推送的代码的质量，比如在 PR 和 CI 生成中加入模型验证测试。 此外，它还支持工程师和数据科学家在代码中放入断点，以便进行调试。

模型验证 CD 管道

模型验证管道的目标是使用实际数据验证机器学习环境的端到端模型训练和评分步骤。 生成的任何已训练模型都将被添加到模型注册表中，进行标记，以等待在验证完成后升级。 对于批量预测，升级可以是发布一个使用此版本模型的评分管道。 对于实时评分，可以标记模型以指示该模型已推广。

评分 CD 管道

评分 CD 管道适用于批量推理方案，其中用于模型验证的相同模型业务流程协调程序会触发已发布的评分管道。

开发与生产环境

将开发 (dev) 环境和生产 (prod) 环境隔离是一种良好做法。 隔离允许系统在不同时间触发模型验证 CD 管道和评分 CD 管道。 对于所述的 MLOps 流，面向主分支的管道将在开发环境中运行，面向发布分支的管道将在生产环境中运行。

代码更改与数据更改

前面的部分主要讨论了如何处理从开发到发布的代码更改。 但是，数据更改应遵循与代码更改相同的严格程序，以在生产中提供相同的验证质量和一致性。 通过数据更改触发器或计时器触发器，系统可从模型业务流程协调程序触发模型验证 CD 管道和评分 CD 管道，以运行在发布分支生产环境中为代码更改运行的相同流程。

MLOps 角色

任何 MLOps 进程的一个关键要求是，需要满足该进程的许多用户的需求。 出于设计目的，这些用户被视为单个角色。 在此项目中，团队标识了以下角色：

• 数据科学家：创建机器学习模型及其算法。
• 工程师
  • 数据工程师：处理数据调节。
  • 软件工程师：处理与资产包和 CI/CD 工作流的模型集成。
• 运营或 IT：监督系统操作。
• 业务利益干系人：关注机器学习模型的预测以及这些预测如何帮助业务。
• 数据最终用户：以有助于做出业务决策的某种方式使用模型输出。

团队必须解决角色研究中的三个关键发现：

• 数据科学家和工程师的工作方法与技能不匹配。 使数据科学家和工程师能够轻松协作是 MLOps 进程流设计的主要考虑因素。 它需要所有团队成员获取新技能。
• 需要在不疏远任何人的情况下统一所有主要角色。 一种实现途径是：
  • 确保他们了解 MLOps 的概念模型。
  • 就将要一起工作的团队成员达成一致。
  • 制定实现共同目标的工作指南。
• 如果业务利益干系人和数据最终用户需要一种方法来与模型输出的数据进行交互，则标准解决方案是用户友好型 UI。

其他团队在扩展以用于生产用途时，当然也会在其他机器学习项目中遇到类似问题。

MLOps 解决方案体系结构

逻辑体系结构

数据来自多种不同格式的多个源，因此在将其插入数据湖之前需要先对其进行调节。 使用作为 Azure Functions 运行的微服务来完成调节。 客户根据数据源自定义微服务，并将其转换为训练和评分管道使用的标准化 csv 格式。

系统体系结构

批处理体系结构

该团队设计了支持批量数据处理方案的体系结构设计。 具有替代方案，但使用的所有方案都必须支持 MLOps 进程。 根据设计要求，需要充分使用可用的 Azure 服务。 下图说明了此体系结构：

解决方案概述

Azure 数据工厂执行以下操作：

• 触发 Azure 函数以开始引入数据和运行 Azure 机器学习管道。
• 启动 Durable Function，轮询 Azure 机器学习管道的完成情况。

Power BI 中自定义仪表板显示结果。 通过 OpenCensus Python SDK 连接 SQL Azure、Azure Monitor 和 App Insights 的其他 Azure 仪表板可跟踪 Azure 资源。 这些仪表板提供有关机器学习系统运行状况的信息。 它们还生成客户用于产品订单预测的数据。

模型业务流程

模型业务流程遵循以下步骤：

1. 提交 PR 时，DevOps 会触发代码验证管道。
2. 管道运行单元测试、代码质量测试和模型验证测试。
3. 合并到主分支时，将运行相同的代码验证测试，DevOps 将项目打包。
4. DevOps 项目收集触发 Azure 机器学习执行以下操作：
   1. 数据验证。
   2. 训练验证。
   3. 评分验证。
5. 验证完成后，将运行最终评分管道。
6. 更改数据并提交新的 PR 会再次触发验证管道，然后触发最终评分管道。

启用试验

如前所述，如果未经修改，传统的数据科学机器学习生命周期不支持 MLOps 进程。 它使用不同类型的手动工具和试验、验证、打包和模型切换，这些工具无法轻松扩展以实现有效的 CI/CD 过程。 MLOps 需要高级别的过程自动化。 无论是开发新机器学习模型还是修改旧机器学习模型，都需要自动执行机器学习模型的生命周期。 在阶段 2 项目中，团队使用 Azure DevOps 来协调并重新发布 Azure 机器学习的训练任务管道。 长期运行的主分支执行模型的基本测试，并通过长期运行的发布分支推送稳定版本。

源代码管理成为此过程的重要组成部分。 Git 是用于跟踪笔记本和模型代码的版本控制系统。 它还支持过程自动化。 为源代码管理实现的基本工作流遵循以下原则：

• 对代码和数据集使用正式版本控制。
• 在完全开发和验证代码之前，对新代码开发使用分支。
• 验证新代码后，可以将其合并到主分支中。
• 对于发布，创建一个独立于主分支的永久版本控制分支。
• 对出于训练或使用目的而调节的数据集使用版本和源代码管理，以便保持每个数据集的完整性。
• 使用源代码管理跟踪 Jupyter Notebook 试验。

与数据源集成

数据科学家使用许多原始数据源和已处理的数据集来试验不同的机器学习模型。 生产环境中的数据量可能非常巨大。 数据科学家需要使用 Azure Data Lake 等管理工具来试验不同的模型。 正式标识和版本控制的要求适用于所有原始数据、准备就绪的数据集和机器学习模型。

在项目中，数据科学家对以下数据进行了调节，以便输入到模型中：

• 自 2017 年 1 月以来的历史每周发货数据
• 每个邮政编码的历史和预测每日天气数据
• 每个商店 ID 的购物者数据

与源代码管理集成

为了让数据科学家应用工程最佳做法，有必要将他们使用的工具与源代码管理系统（如 GitHub）轻松集成。 这种做法允许机器学习模型版本控制、团队成员之间的协作，以及团队遇到数据丢失或系统中断时的灾难恢复。

模型组合支持

此项目中的模型设计是一个组合模型。 也就是说，数据科学家在最终模型设计中使用了许多算法。 在这种情况下，模型使用相同的基本算法设计。 唯一的区别在于，它们使用不同的训练数据和评分数据。 这些模型将 LASSO 线性回归算法和神经网络结合使用。

团队探索了（但未实现）一种将该过程向前推进的选项，以支持在生产中为给定请求运行许多实时模型。 此选项支持在 A/B 测试和交错试验中使用组合模型。

最终用户界面

该团队为可观测性、监视和检测开发了最终用户 UI。 如前文所述，仪表板会以可视化方式显示机器学习模型数据。 这些仪表板以用户友好的格式显示以下数据：

• 管道步骤，包括预处理输入数据。
• 监视机器学习模型处理的运行状况：
  • 从已部署模型中收集了哪些指标？
    • MAPE：平均绝对百分比误差，它是跟踪总体性能的关键指标。 （将每个模型的 MAPE 值设为 <= 0.45。）
    • RMSE 0：当实际目标值 = 0 时的均方根误差 (RMSE)。
    • RMSE All：整个数据集上的 RMSE。
  • 如何评估模型在生产中的表现是否符合预期？
  • 是否有办法判断生产数据是否与预期值与偏差太大？
  • 模型在生产中的表现是否很差？
  • 你是否有故障转移状态？
• 跟踪已处理数据的质量。
• 显示机器学习模型产生的评分/预测。

应用程序根据数据性质及其处理和分析数据的方式来填充仪表板。 因此，团队必须为每个用例设计精确的仪表板布局。 下面是两个示例仪表板：

这些仪表板旨在为机器学习模型预测的最终用户提供易于使用的信息。

组件

• Azure 机器学习
  • Azure 机器学习计算
  • Azure 机器学习管道
  • Azure 机器学习模型注册表
• Azure Blob 存储
• Azure Data Lake 存储
• Azure Pipelines
• Azure 数据工厂
• 适用于 Python 的 Azure Functions
• Azure Monitor
  • 日志
  • Application Insights
• Azure SQL 数据库
• Azure 仪表板
• Power BI

注意事项

可在此处找到要浏览的注意事项列表。 它们基于 CSE 团队在项目中获得的经验。

环境注意事项

• 数据科学家使用 Python 开发大多数机器学习模型，通常从 Jupyter Notebook 开始。 可能难以将这些笔记本作为生产代码实现。 Jupyter Notebook 更像一个试验性工具，而 Python 脚本更适合生产。 团队经常需要花时间将模型创建代码重构为 Python 脚本。
• 让不熟悉 DevOps 和机器学习的客户知道，试验和生产的严格性要求不同，因此最好将两者分开。
• Azure 机器学习可视化设计器或 AutoML 之类的工具可以有效地从根本上构建基本模型，同时，客户可以加强要应用于解决方案的其余部分的标准 DevOps 实践。
• Azure DevOps 具有可与 Azure 机器学习集成的插件，有助于触发管道步骤。 MLOpsPython 存储库包含几个此类管道示例。
• 机器学习通常需要功能强大的 GPU 计算机进行训练。 如果客户尚未提供此类硬件，Azure 机器学习计算群集可以提供一个有效的路径，用于快速预配具有成本效益且可自动缩放的强大硬件。 如果客户具有高级安全或监视需求，则还有其他选项，如标准 VM、Databricks 或本地计算。
• 客户要想取得成功，其模型构建团队（数据科学家）和部署团队（DevOps 工程师）需要强大的沟通渠道。 他们可以通过每日站会或正式的在线聊天服务完成此项工作。 这两种方法都有助于将其开发工作集成到 MLOps 框架中。

数据准备注意事项

• 使用 Azure 机器学习的最简单解决方案是将数据存储在受支持的数据存储解决方案中。 Azure 数据工厂等工具可以有效地将数据按计划输送到这些地方。

• 对于客户而言，必须频繁捕获其他重新训练的数据，使其模型保持最新状态。 如果他们还没有数据管道，则创建一个数据管道将是整个解决方案的重要环节。 在 Azure 机器学习中使用 Datasets 等解决方案可用于对数据进行版本控制，有助于增强模型的可跟踪性。

模型训练和评估注意事项

• 如果客户刚刚开始了解机器学习，则尝试实现完整的 MLOps 管道会很困难。 如有必要，他们可以通过使用 Azure 机器学习跟踪试验运行并将 Azure 机器学习计算用作训练目标来渐入佳境。 这些选项可能会降低入门解决方案的门槛，以便开始集成 Azure 服务。

• 很多数据科学家选择从笔记本试验到可重复的脚本的更粗放过渡。 你越早让他们使用 Python 脚本编写训练代码，他们就越容易开始对训练代码进行版本控制并启用再训练。

  这并不是唯一可行的方法。 Databricks 支持将笔记本计划为作业。 但根据当前的客户体验，由于测试限制，很难使用完整 DevOps 做法来检测此方法。

• 还必须了解要使用哪些指标来评估模型是否成功。 单凭准确性通常不足以确定一个模型与另一个模型的总体性能。

计算注意事项

• 客户应考虑使用容器对其计算环境进行标准化。 几乎所有 Azure 机器学习计算目标都支持使用 Docker。 让容器处理依赖项可以显著减少摩擦，尤其是在团队使用多个计算目标时。

模型服务注意事项

• Azure 机器学习 SDK 提供了一个选项，用于从已注册的模型直接部署到 Azure Kubernetes 服务，从而限制现有安全性/指标。 可以尝试为客户找到更简单的解决方案来测试模型，但最好是为生产工作负载开发出更可靠的 AKS 部署。

后续步骤

• 详细了解 MLOps
• Azure 上的 MLOps
• Azure Monitor 可视化效果
• 机器学习生命周期
• Azure DevOps 机器学习扩展
• Azure 机器学习 CLI
• 基于 Azure 机器学习事件触发应用程序、进程或 CI/CD 工作流
• 使用 Azure DevOps 设置模型训练和部署

相关资源

• MLOps 成熟度模型
• 使用 Databricks Notebook 协调 Azure Databricks 上的 MLOps
• 适用于 Python 模型的 MLOps（使用 Azure 机器学习）
• 使用 Azure Databricks 进行数据科学和机器学习
• 通过 Power Platform 平台驯化 AI
• 在本地和边缘部署 AI 和机器学习计算