通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

机器学习操作

  • 项目

本文介绍用于机器学习运营的三个 Azure 体系结构，这些体系结构具有端到端持续集成和持续交付 (CI/CD) 管道和重新训练管道。 这些体系结构适用于以下 AI 应用程序：

  • 经典机器学习
  • 计算机视觉 (CV)
  • 自然语言处理

这些体系结构是 MLOps v2 项目的产物。 它们结合了在开发多个机器学习解决方案的过程中的解决方案架构师确定的最佳做法。 结果为可部署、可重复且可维护的模式。 所有三个体系结构都使用 Azure 机器学习服务。

有关包含 MLOps v2 的示例部署模板的实现，请参阅 Azure MLOps v2 解决方案加速器。

可能的用例

  • 经典机器学习：表格结构化数据的时序预测、回归和分类是此类别中最常见的用例。 示例包括：

    • 二进制和多标签分类。

    • 线性、多项式、岭回归、套索、分位数和贝叶斯回归。

    • ARIMA、自动回归、SARIMA、VAR、SES、LSTM。

  • CV：本文中的 MLOps 框架主要侧重于分段和图像分类的 CV 用例。

  • 自然语言处理：可以使用此 MLOps 框架来实现：

    • 命名实体识别：

    • 文本分类

    • 文本生成

    • 情绪分析

    • 翻译

    • 问答

    • 汇总

    • 句子检测程序

    • 语言检测

    • 词性标记

本文未介绍 AI 模拟、深度强化学习和其他形式的 AI。

体系结构

MLOps v2 体系结构模式具有 MLOps 生命周期的四个主要模块化组件或阶段：

  • 数据资产
  • 管理和设置
  • 模型开发或内部循环阶段
  • 模型部署，或外循环阶段

上述组件、它们之间的连接和涉及的典型角色都是所有 MLOps v2 方案体系结构的标准。 每个组成部分的细节变化取决于具体情况

机器学习 MLOps v2 的基本体系结构是针对表格数据的经典机器学习方案。 CV 和 NLP 体系结构基于此基础体系结构进行构建和修改。

MLOps v2 介绍了本文中所述的以下体系结构：

经典机器学习体系结构

经典机器学习体系结构图。

下载此体系结构的 Visio 文件。

经典机器学习体系结构的工作流

  1. 数据资产

    此组件说明了组织的数据资产，以及数据科学项目的潜在数据源和目标。 数据工程师是 MLOps v2 生命周期中此组件的主要所有者。 此图中的 Azure 数据平台既不详尽也不具有规范性。 根据客户用例表示推荐最佳做法的数据源和目标由绿色复选标记指示。

  2. 管理和设置

    此组件是 MLOps v2 加速器部署的第一步。 它包含与创建和管理与项目关联的资源和角色相关的所有任务。 例如，基础结构团队可能：

    1. 创建项目源代码存储库。
    2. 使用 Bicep 或 Terraform 创建机器学习工作区。
    3. 创建或修改数据集和计算资源，以便进行模型开发和部署。
    4. 定义项目团队用户、其角色和对其他资源的访问控制。
    5. 创建 CI/CD 管道。
    6. 创建监视组件来收集和创建模型和基础结构指标的警报。

    与此阶段关联的主要角色是基础结构团队，但组织也可能存在数据工程师、机器学习工程师和数据科学家。

  3. 模型开发（内部循环阶段）

    内部循环阶段由迭代数据科学工作流组成，该工作流在专用的安全 Azure 机器学习工作区中运行。 上图显示了典型的工作流。 该过程从数据引入开始，通过探索性数据分析、试验、模型开发和评估进行移动，然后注册模型以供生产使用。 MLOps v2 加速器中实现的此模组件与数据科学团队用于开发模型的过程无关，但是也可适应该过程。

    与此阶段相关的角色包括数据科学家和机器学习工程师。

  4. Azure 机器学习注册表

    在数据科学团队开发了一个可用于部署到生产环境的模型之后，他们会在 Azure 机器学习工作区注册表中注册该模型。 通过模型注册或封闭的人工循环审批自动触发的 CI 管道，将模型和其他任何模型依赖项提升到模型部署阶段。

    与此阶段关联的角色通常是机器学习工程师。

  5. 模型部署（外部循环阶段）

    模型部署或外部循环阶段包括预生产暂存和测试、生产部署以及模型、数据和基础结构的监视。 当模型满足适合组织和用例的条件时，CD 管道通过生产、监视和潜在的再培训来提升模型和相关资产。

    与此阶段关联的角色主要是机器学习工程师。

  6. 暂存和测试

    过渡阶段和测试阶段因客户做法而异。 该阶段包括对生产数据的模型候选项进行重新训练和测试、终结点性能测试测试部署、数据质量检查、单元测试以及对模型和数据偏差负责的 AI 检查等操作。 此阶段发生在一个或多个专用、安全的 Azure 机器学习工作区中。

  7. 生产部署

    模型通过暂存和测试阶段后，机器学习工程师可以使用人工循环封闭审批将其提升到生产环境。 模型部署选项包括用于批处理方案的托管批处理终结点，或者使用 Azure Arc 进行在线、近乎实时方案的托管联机终结点或 Kubernetes 部署。 生产通常发生在一个或多个专用、安全的 Azure 机器学习工作区中。

  8. 监视

    机器学习工程师监视暂存、测试和生产中的组件，以收集与模型、数据和基础设施性能变化相关的指标。 他们可以使用这些指标采取措施。 模型和数据监视可以包括检查模型和数据偏移、新数据的模型性能以及负责任的 AI 问题。 基础结构监视可能会发现终结点响应速度缓慢、计算容量不足或网络问题。

  9. 数据和模型监视：事件和操作

    根据有关指标阈值或计划等模型和数据标准，自动化触发器和通知可以实现要采取的适当操作。 例如，触发器可以重新训练模型以使用新的生产数据，然后环回模型以暂存和测试预生产评估。 或者，一个模型或数据问题可能会触发一项操作，需要循坏回模型开发阶段，在此阶段数据科学家可以调查问题并可能研发出新模型。

  10. 基础结构监视：事件和操作

    根据有关的基础结构问题的标准（例如终结点响应滞后或部署计算不足），自动化触发器和通知可以执行要采取的适当操作。 自动触发器和通知可能会触发到设置和管理阶段的环回，此时基础结构团队可以调查问题并可能重新配置计算和网络资源。

Azure 机器学习 CV 体系结构

计算机视觉架构图。

下载此体系结构的 Visio 文件。

CV 体系结构的工作流

Azure 机器学习 CV 体系结构基于经典机器学习体系结构，但它专门修改了受监督的 CV 方案。

  1. 数据资产

    此组件展示了组织的数据资产，以及数据科学项目的潜在数据源和目标。 数据工程师是 MLOps v2 生命周期中此组件的主要所有者。 此图中的 Azure 数据平台既不详尽也不具有规范性。 CV 方案的映像可能来自各种数据源。 为提高使用 Azure 机器学习开发和部署 CV 模型的效率，我们建议使用 Azure Blob 存储和 Azure Data Lake Storage。

  2. 管理和设置

    此组件是 MLOps v2 加速器部署的第一步。 它包含与创建和管理与项目关联的资源和角色相关的所有任务。 对于 CV 场景，MLOps v2 环境的管理和设置与传统机器学习大致相同，但包含额外的步骤。 基础结构团队使用机器学习的标记功能或其他工具来创建图像标记和批注项目。

  3. 模型开发（内部循环阶段）

    内部循环阶段由迭代数据科学工作流组成，该工作流在专用的安全 Azure 机器学习工作区中运行。 此工作流与经典机器学习方案的主要区别在于图像标记和批注是此开发循环的关键组件。

  4. Azure 机器学习注册表

    在数据科学团队开发了一个可用于部署到生产环境的模型之后，他们会在 Azure 机器学习工作区注册表中注册该模型。 通过模型注册或封闭的人工循环审批自动触发的 CI 管道，将模型和其他任何模型依赖项提升到模型部署阶段。

  5. 模型部署（外部循环阶段）

    模型部署或外部循环阶段包括预生产暂存和测试、生产部署以及模型、数据和基础结构的监视。 当模型满足适合组织和用例的条件时，CD 管道通过生产、监视和潜在的再培训来提升模型和相关资产。

  6. 暂存和测试

    过渡阶段和测试阶段因客户做法而异。 该阶段通常包括终结点性能测试部署、数据质量检查、单元测试以及对模型和数据偏差负责的 AI 检查等操作。 对于 CV 场景，由于资源和时间限制，机器学习工程师不需要在生产数据上重新训练候选模型。 数据科学团队可以改用生产数据进行模型开发。 从开发循环中注册的候选模型将接受生产评估。 此阶段发生在一个或多个专用、安全的 Azure 机器学习工作区中。

  7. 生产部署

    模型通过暂存和测试阶段后，机器学习工程师可以使用人工循环封闭审批将其提升到生产环境。 模型部署选项包括用于批处理方案的托管批处理终结点，或者使用 Azure Arc 进行在线、近乎实时方案的托管联机终结点或 Kubernetes 部署。 生产通常发生在一个或多个专用、安全的 Azure 机器学习工作区中。

  8. 监视

    机器学习工程师监视暂存、测试和生产中的组件，以收集与模型、数据和基础设施性能变化相关的指标。 他们可以使用这些指标采取措施。 模型和数据监视可以包括检查新图像上的模型性能。 基础结构监视可能会发现终结点响应速度缓慢、计算容量不足或网络问题。

  9. 数据和模型监视：事件和操作

    用于自然语言处理的 MLOps 的数据和模型监控以及事件和操作阶段是经典机器学习的主要区别。 检测到新图像上的模型性能降级时，通常不会在 CV 方案中自动重新训练。 在这种情况下，模型执行不佳的新文本数据有必要通过人工循环过程审查和批注。 下一步操作通常是返回到模型开发循环，以使用新的图像更新模型。

  10. 基础结构监视：事件和操作

    根据有关的基础结构问题的标准（例如终结点响应滞后或部署计算不足），自动化触发器和通知可以执行要采取的适当操作。 自动触发器和通知可能会触发到设置和管理阶段的环回，此时基础结构团队可以调查问题并可能重新配置环境、计算和网络资源。

机器学习自然语言处理体系结构

自然语言处理体系结构的关系图。

下载此体系结构的 Visio 文件。

自然语言处理体系结构的工作流

机器学习自然语言处理体系结构基于经典机器学习体系结构，但它专门修改了 NLP 方案。

  1. 数据资产

    此组件展示了组织的数据资产，以及数据科学项目的潜在数据源和目标。 数据工程师是 MLOps v2 生命周期中此组件的主要所有者。 此图中的 Azure 数据平台既不详尽也不具有规范性。 绿色复选标记表示代表基于客户用例的推荐最佳实践的来源和目标。

  2. 管理和设置

    此组件是 MLOps v2 加速器部署的第一步。 它包含与创建和管理与项目关联的资源和角色相关的所有任务。 对于自然语言处理场景，MLOps v2 环境的管理和设置与经典机器学习大致相同，但还有一个额外步骤：使用 Azure 机器学习或其他工具的标记功能创建图像标记和批注项目。

  3. 模型开发（内部循环阶段）

    内部循环阶段由迭代数据科学工作流组成，该工作流在专用的安全 Azure 机器学习工作区中运行。 典型的 NLP 模型开发循环与经典机器学习场景不同，此场景的典型开发步骤包括句子注释器和文本数据的标记化、规范化和嵌入。

  4. Azure 机器学习注册表

    在数据科学团队开发了一个可用于部署到生产环境的模型之后，他们会在 Azure 机器学习工作区注册表中注册该模型。 通过模型注册或封闭的人工循环审批自动触发的 CI 管道，将模型和其他任何模型依赖项提升到模型部署阶段。

  5. 模型部署（外部循环阶段）

    模型部署或外部循环阶段包括预生产暂存和测试、生产部署以及模型、数据和基础结构的监视。 当模型满足适合组织和用例的条件时，CD 管道通过生产、监视和潜在的再培训来提升模型和相关资产。

  6. 暂存和测试

    过渡阶段和测试阶段因客户做法而异。 该阶段包括对生产数据的模型候选项进行重新训练和测试、终结点性能测试测试部署、数据质量检查、单元测试以及对模型和数据偏差负责的 AI 检查等操作。 此阶段发生在一个或多个专用、安全的 Azure 机器学习工作区中。

  7. 生产部署

    模型通过暂存和测试阶段后，机器学习工程师可以使用人工循环封闭审批将其提升到生产环境。 模型部署选项包括用于批处理方案的托管批处理终结点，或者使用 Azure Arc 进行在线、近乎实时方案的托管联机终结点或 Kubernetes 部署。 生产通常发生在一个或多个专用、安全的 Azure 机器学习工作区中。

  8. 监视

    机器学习工程师监视暂存、测试和生产中的组件，以收集与模型、数据和基础设施性能变化相关的指标。 他们可以使用这些指标采取措施。 模型和数据监视可以包括检查模型和数据偏移、新数据的模型性能以及负责任的 AI 问题。 基础结构监视可能会发现终结点响应缓慢、计算容量不足或网络问题。

  9. 数据和模型监视：事件和操作

    与 CV 体系结构一样，自然语言处理的 MLOps 的数据和模型监控以及事件和操作阶段是经典机器学习的主要区别。 检测到新文本的模型性能降低时，通常不会在自然语言处理场景中执行自动重新训练。 在这种情况下，模型执行不佳的新文本数据有必要通过人工循环过程审查和批注。 下一步操作通常是返回到模型开发循环，以使用新的文本数据更新模型。

  10. 基础结构监视：事件和操作

    根据有关的基础结构问题的标准（例如终结点响应滞后或部署计算不足），自动化触发器和通知可以执行要采取的适当操作。 自动触发器和通知可能会触发到设置和管理阶段的环回，此时基础结构团队可以调查问题并可能重新配置计算和网络资源。

组件

  • 机器学习服务是一项云服务，可用于大规模训练、评分、部署和管理机器学习模型。

  • Azure Pipelines 是一个基于 Azure DevOps的生成和测试系统，用于生成和发布管道。 Azure Pipelines 将这些管道分解为逻辑步骤，称为任务。

  • GitHub 是用于版本控制、协作和 CI/CD 工作流的代码托管平台。

  • Azure Arc 是一个使用 Azure 资源管理器来管理 Azure 资源和本地资源的平台。 这些资源可以包括虚拟机、Kubernetes 群集和数据库。

  • Kubernetes 是一个开源系统，您可将其用于自动化容器化应用程序的部署、缩放和管理。

  • Azure Data Lake Storage 是与 Hadoop 兼容的文件系统。 具有集成的分层命名空间，以及 Azure Blob 存储的大规模和经济性。

  • Azure Synapse Analytics 是一种无限制的分析服务，它将数据集成、企业数据仓库和大数据分析结合在一起。

  • Azure 事件中心是一项引入客户端应用程序生成的数据流的服务。 随后会引入并存储流数据，从而保留接收事件的序列。 使用者可以连接到中心终结点，以检索要处理的消息。 此体系结构使用 Data Lake Storage 集成。

其他注意事项

前面的 MLOps v2 体系结构模式具有多个关键组件，包括与业务利益干系人、高效包管理和可靠的监视机制保持一致的基于角色的访问控制 (RBAC)。 这些组件共同有助于成功实现和管理机器学习工作流。

基于角色的 RBAC

管理对机器学习数据和资源的访问至关重要。 RBAC 提供了一个可靠的框架，可帮助您管理谁可以执行特定操作并访问解决方案中的特定区域。 设计标识分段策略，使其符合机器学习中机器学习模型的生命周期以及流程中包含的角色。 每个角色都有一组特定的职责，这些职责反映在其 RBAC 角色和组成员身份中。

示例角色

若要在机器学习工作负荷中支持适当的分段，请考虑以下常见角色，告知基于标识的 RBAC 组设计。

数据科学家和机器学习工程师

数据科学家和机器学习工程师在项目的软件开发生命周期内执行各种机器学习和数据科学活动。 其职责包括探索数据分析和数据预处理。 数据科学家和机器学习工程师负责训练、评估和部署模型。 这些角色的职责还包括机器学习模型、包和数据的中断修复活动。 这些职责不适用于平台的技术支持团队。

类型：人员
特定项目：是

数据分析师

数据分析师为数据科学活动提供必要的输入，例如为商业智能运行 SQL 查询。 此角色的职责包括处理数据、执行数据分析以及支持模型开发和模型部署。

类型：人员
特定项目：是

模型测试人员

模型测试人员在测试和过渡环境中进行测试。 此角色提供与 CI/CD 进程的功能隔离。

类型：人员
特定项目：是

业务利益干系人

业务利益干系人（如营销经理）与项目相关联。

类型：人员
特定项目：是

项目主管或数据科学主管

数据科学主管是机器学习工作区的项目管理角色。 此角色还会对机器学习模型和包执行中断修复活动。

类型：人员
特定项目：是

项目或产品所有者（业务所有者）

业务利益干系人根据数据所有权负责机器学习工作区。

类型：人员
特定项目：是

平台技术支持

平台技术支持是负责跨平台中断修复活动的技术支持人员。 此角色涵盖基础结构或服务，但不包括机器学习模型、包或数据。 这些组件仍担任数据科学家或机器学习工程师角色，并且是项目主管的责任。

类型：人员
特定项目：否

模型终端用户

模型终端用户是机器学习模型的最终用户。

类型：人员或进程
特定项目：是

CI/CD 进程

CI/CD 处理跨平台环境的发布或回滚更改。

类型：进程
特定项目：否

机器学习工作区

机器学习工作区使用托管标识与 Azure 的其他部分进行交互。 此角色表示构成机器学习实现的各种服务。 这些服务与平台的其他部分（例如与开发数据存储连接的开发工作区）进行交互。

类型：进程
特定项目：否

监视过程

监视进程是基于平台活动进行监视和发出警报的计算进程。

类型：进程
特定项目：否

数据治理流程

数据管理过程会扫描机器学习项目和数据存储，以便进行数据管理。

类型：进程
特定项目：否

Microsoft Entra 组成员身份

实现 RBAC 时，Microsoft Entra 组提供了一种灵活且可缩放的方式来管理不同角色之间的访问权限。 您可以使用 Microsoft Entra 组用于管理用户，这些用户需要对资源（例如可能受限的应用和服务）具有相同的访问权限和权限。 无需向单个用户添加特殊权限，而是创建一个组，并将特殊权限应用于该组的每个成员。

在此体系结构模式中，您可以将这些组与机器学习工作区设置（如项目、团队或部门）耦合。 您可以将用户与特定组相关联，以定义细化访问策略。 策略根据作业功能、项目要求或其他条件授予或限制对各种机器学习工作区的权限。 例如，您可以建立一个组，授予所有数据科学家访问特定用例的开发工作区的权限。

标识 RBAC

请考虑如何使用以下内置 Azure RBAC 角色将 RBAC 应用到生产和预生产环境。 对于本文中的体系结构，生产环境包括过渡、测试和生产环境。 预生产环境包括开发环境。 以下 RBAC 角色基于本文前面所述的角色。

标准角色

特定于组件的角色

这些 Azure RBAC 角色缩写与下表相对应。

生产环境
Persona 机器学习工作区 Azure Key Vault 容器注册表 Azure 存储帐户 Azure DevOps Azure Artifacts Log Analytics 工作区 Azure Monitor
数据科学家 R LAR MR
数据分析师
模型测试人员
业务利益干系人 MR
项目主管（数据科学主管） R R、KVR R LAR MR
项目/产品所有者 MR
平台技术支持 O O、KVA DOPCA O O O
模型终端用户
CI/CD 进程 O O、KVA AcrPush DOPCA O O O
机器学习工作区 R C C
监视过程 R LAR MR
数据治理流程 R R R R R
预生产环境
Persona 机器学习工作区 密钥保管库 容器注册表 存储帐户 Azure DevOps Azure Artifacts Log Analytics 工作区 Azure Monitor
数据科学家 ADS R、KVA C C C C LAC MC
数据分析师 R C LAR MC
模型测试人员 R R、KVR R R R R LAR MR
业务利益干系人 R R R R R
项目主管（数据科学主管） C C、KVA C C C C LAC MC
项目/产品所有者 R R MR
平台技术支持 O O、KVA O O DOPCA O O O
模型终端用户
CI/CD 进程 O O、KVA AcrPush O DOPCA O O O
机器学习工作区 R、KVR C C
监视过程 R R R R R R LAC
数据治理流程 R R R

注意

除平台技术支持（具有临时或实时 Microsoft Entra Privileged Identity Management (PIM) 访问权限）外，每个角色都会保留项目的持续时间访问权限。

RBAC 在保护和简化 MLOps 工作流方面发挥着重要作用。 RBAC 基于分配的角色限制访问，并防止未经授权的用户访问敏感数据，从而降低安全风险。 敏感数据包括训练数据或模型以及关键基础结构，例如生产管道。 您可以使用 RBAC 来确保符合数据隐私法规。 RBAC 还提供清晰的访问和权限记录，这简化了审核工作，使用户能够轻松识别安全漏洞并跟踪用户活动。

包管理

在 MLOps 生命周期中，对各种包、库和二进制文件的依赖关系很常见。 这些依赖关系通常由社区开发并快速演变，需要主题专家知识才能正确使用和理解。 您必须确保适当的人员能够安全地访问各种资产，例如包和库，但还必须防止漏洞。 数据科学家在为机器学习解决方案组装专用构建基块时遇到此问题。 传统的软件管理方法成本高昂且效率低下。 其他方法可提供更多价值。

若要管理这些依赖项，可以根据隔离模式使用安全的自助服务包管理过程。 您可以设计将此过程，允许数据科学家从精心策划的包列表中自行提供服务，并确保包安全且符合组织标准。

此方法包括安全列出三个行业标准机器学习包存储库：Microsoft 工件注册表、Python 包索引 (PyPI) 和 Conda。 安全列表支持单个机器学习工作区的自助服务。 然后在部署过程中使用自动化测试过程扫描生成的解决方案容器。 失败雅地退出部署过程并删除容器。 下图和流程演示了此过程：

显示安全机器学习包方法的关系图。

处理流程

  1. 在具有网络配置的机器学习工作区中工作的数据科学家可以从机器学习包存储库按需自助服务机器学习包。 使用专用存储模式（使用集中式函数进行种子设定和维护）的其他所有操作都需要例外程序。

  2. 机器学习将机器学习解决方案作为 Docker 容器提供。 开发这些解决方案后，它们被将上传到容器注册表。 Microsoft Defender for Containers 为容器映像生成漏洞评估。

  3. 解决方案部署通过 CI/CD 过程进行。 Microsoft Defender for DevOps 在整个堆栈中使用，以提供安全态势管理和威胁防护。

  4. 仅当解决方案容器通过每个安全进程时，才会部署该容器。 如果解决方案容器未能通过安全过程，部署将失败并显示错误通知和完整的审核线索。 解决方案容器将被丢弃。

前面的进程流为数据科学家提供了安全的、自助服务的包管理过程，并确保包安全且符合组织标准。 为了平衡创新和安全性，可以向数据科学家授予对预生产环境中的常见机器学习包、库和二进制文件的自助服务访问权限。 对不常用的软件包规定例外情况。 此策略可确保数据科学家在开发期间保持高效，从而防止交付过程中出现重大瓶颈。

为了简化发布过程，可将用于生产环境的环境容器化。 通过漏洞扫描，容器化环境可减少工作量，并确保持续安全。 此过程流提供了一种可重复的方法，可在用例中使用直至交付时间。 它降低了在企业中生成和部署机器学习解决方案的总体成本。

监视

在 MLOps 中，监视对于维护机器学习系统的运行状况和性能、确保模型保持有效且符合业务目标至关重要。 监视支持内部循环阶段的治理、安全性和成本控制。 在外部循环阶段部署解决方案时，它提供性能、模型降级和使用情况的可观测性。 监视活动适用于数据科学家、业务利益干系人、项目主管、项目所有者、平台技术支持、CI/CD 流程和监视流程等角色。

根据机器学习工作区设置（例如项目、团队或部门）选择监视和验证平台。

模型性能

监视模型性能，以尽早检测模型问题和性能下降。 跟踪性能，确保模型保持准确、可靠且符合业务目标。

数据偏移

数据偏移将模型输入数据与模型的训练数据或最近的生产数据进行比较，从而跟踪其分布的变化。 这些更改是由市场动态变化、特征转换更改或上游数据更改的结果。 此类更改可能会降低模型性能，因此请务必监视偏移以确保及时修正。 执行比较，数据偏移重构需要最近的生产数据集和输出。

环境：生产
Azure facilitation： 机器学习 - 模型监控

预测偏移

预测偏移通过将模型的预测输出与验证数据、测试标记数据或最近的生产数据进行比较来跟踪模型预测输出分布的变化。 执行比较，数据偏移重构需要最近的生产数据集和输出。

环境：生产
Azure facilitation： 机器学习 - 模型监控

资源

使用多个提供终结点指标的模型来指示质量和性能，例如 CPU 或内存使用情况。 此方法可帮助您从生产中吸取教训，有助于推动未来的投资或改变。

环境：全部
Azure 便利化： 监视 - 联机终结点指标

使用情况指标

监视终结点的使用，以确保满足组织特定的或特定于工作负荷的关键绩效指标，跟踪使用模式，并诊断和修正用户遇到的问题。

客户端请求

跟踪对模型终结点的客户端请求数，以了解终结点的活动使用情况配置文件，这可能会影响缩放或成本优化工作。

环境：生产
Azure 便利化： 监视 - 联机终结点指标，例如 RequestsPerMinute。 注意：

  • 您可以将可接受的阈值与根据工作负荷需求定制的 T 恤大小调整或异常情况保持一致。
  • 停用不再在生产环境中使用的模型。
限制延迟

限制延迟是数据传输的请求和响应速度变慢。 限制发生在资源管理器级别和服务级别中。 跟踪两个级别的指标。

环境：生产
Azure 便利化：

  • Monitor - 资源管理器、RequestThrottlingDelayMs、ResponseThrottlingDelayMs 的总和。
  • 机器学习 - 若要检查终结点请求的相关信息，可以启用联机终结点流量日志。 您可以使用 Log Analytics 工作区来处理日志。

注意：将可接受的阈值与工作负荷的服务级别目标 (SLO) 或服务级别协议 (SLA) 以及解决方案的非功能要求 (NFR) 保持一致。

生成的错误

跟踪响应代码错误，以帮助衡量服务可靠性，并确保提前检测服务问题。 例如，500 个服务器错误响应突然增加可能表明存在需要立即注意的关键问题。

环境：生产
Azure 便利化：机器学习 - 启用联机终结点流量日志以检查有关请求的信息。 例如，您可以使用 ModelStatusCode 或 ModelStatusReason 检查 XRequestId 的计数。 您可以使用 Log Analytics 工作区来处理日志。
注意：

  • 400 和 500 范围中的所有 HTTP 响应代码都归类为错误。

成本优化

云环境中的成本管理和优化至关重要，因为它们有助于工作负荷控制费用、高效分配资源，并从云服务中最大化价值。

工作区计算

当每月运营费用达到或超过预定义金额时，根据工作区设置边界生成警报，以通知相关利益干系人，例如项目主管或项目所有者。 您可以根据项目、团队或部门相关的边界确定工作区设置。

环境：全部
Azure 便利化： Microsoft 成本管理 - 预算警报
注意：

  • 根据初始 NFR 和成本估算设置预算阈值。
  • 使用多个阈值层。 多个阈值层可确保利益干系人在超出预算之前收到适当的警告。 这些利益干系人可能包括业务主管、项目所有者或项目潜在顾客，具体取决于组织或工作负荷。
  • 持续的预算警报也可能成为重构的触发因素，以支持更大的需求。
工作区过期

如果机器学习工作区未根据预期用例的关联计算使用情况显示活动使用的迹象，当给定项目不再需要工作区时，则项目所有者可能会停用工作区。

环境：预生产
Azure 便利化：

注意：

  • 活动核心应等于零，计数聚合。
  • 将日期阈值与项目计划保持一致。

安全性

监视以检测与适当的安全控制和基线之间的偏差，以确保机器学习工作区符合组织的安全策略。 您可以使用预定义策略和自定义策略的组合。

环境：全部
Azure 便利化：用于机器学习的 Azure Policy

终结点安全性

若要深入了解业务关键 API，请对所有机器学习终结点实施有针对性的安全监视。 可以调查和改善 API 安全状况、确定漏洞修复的优先顺序，并快速检测活动实时威胁。

环境：生产
Azure 便利化： Microsoft Defender for API 为 API 提供广泛的生命周期保护、检测和响应覆盖。 注意：Defender for API 目前为 Azure API Management 中发布的 API 提供安全性。 您可以在 Microsoft Defender for Cloud 门户中或 Azure 门户的 API Management 实例中加入 Defender for API。 您必须将机器学习联机终结点与API 管理集成。

部署 监视

部署监视可确保创建的任何终结点都遵循工作负荷或组织策略，并且不受漏洞影响。 此过程要求在部署前后对 Azure 资源强制实施合规性策略，通过漏洞扫描提供持续的安全性，并确保服务在操作过程中满足 SLO。

标准和治理

监视以检测与适当标准的偏差，并确保工作负荷遵守防护措施。

环境：全部
Azure 便利化：

注意：有关详细信息，请参阅机器学习合规性的 Azure 指南。

安全扫描

在自动化集成和部署过程中实现自动安全扫描。

环境：全部
Azure 便利化：Defender for DevOps
注意：您可以使用 Azure Marketplac中的应用为非 Microsoft 安全测试模块扩展此过程。

正在进行的服务

监视 API 的持续服务，以优化性能、安全性和资源使用情况。 确保及时检测错误、高效故障排除和符合标准。

环境：生产
Azure 便利化：

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

若要查看非公开领英个人资料，请登录领英。

后续步骤