构建端到端 MLOps 管道以进行边缘视觉质量检查 – 第 1 部分 | 亚马逊网络服务

构建端到端 MLOps 管道以进行边缘视觉质量检查 – 第 1 部分 | 亚马逊网络服务

时间戳记：2年2023月12日下午31:XNUMX

在生产环境中成功部署机器学习 (ML) 模型在很大程度上依赖于端到端 ML 管道。 尽管开发这样的管道可能具有挑战性，但在处理 边缘机器学习用例。 边缘机器学习这一概念将在本地运行机器学习模型的能力引入边缘设备。 为了在边缘部署、监控和维护这些模型，需要强大的 MLOps 管道。 MLOps 管道可以实现从数据标记到模型训练和部署的整个 ML 生命周期的自动化。

在边缘实施 MLOps 管道会带来额外的复杂性，由于涉及的运营开销增加，使得自动化、集成和维护流程更具挑战性。 但是，使用专门构建的服务，例如 亚马逊SageMaker 和 AWS IoT Greengrass 可以让您显着减少这项工作。 在本系列中，我们将引导您完成使用 SageMaker、AWS IoT Greengrass 和 AWS云开发套件 (AWS CDK)。

这篇文章的重点是设计整体 MLOps 管道架构； 部分2 和 部分3 本系列的重点是各个组件的实现。 我们在随附的文件中提供了示例实现 GitHub存储库 供您亲自尝试。 如果您刚刚开始在 AWS 边缘使用 MLOps，请参阅 使用 Amazon SageMaker Edge Manager 和 AWS IoT Greengrass 在边缘进行 MLOps 了解概述和参考架构。

用例：检查金属标签的质量

作为一名机器学习工程师，了解您正在处理的业务案例非常重要。 因此，在深入研究 MLOps 管道架构之前，让我们先看一下本文的示例用例。 想象一下一家制造商的生产线，该生产线雕刻金属标签以创建定制的行李标签。 质量保证过程成本高昂，因为需要手动检查原始金属标签是否有划痕等缺陷。 为了使这个过程更加高效，我们使用机器学习来在此过程的早期检测出错误的标签。 这有助于避免生产过程后期出现代价高昂的缺陷。 该模型应该近乎实时地识别可能的缺陷（例如划痕）并对其进行标记。 在制造车间环境中，您通常必须应对无连接或带宽受限以及延迟增加的问题。 因此，我们希望实现一种用于视觉质量检查的边缘机器学习解决方案，该解决方案可以在车间本地运行推理并降低对连接的要求。 为了让我们的示例简单明了，我们训练了一个模型，用边界框标记检测到的划痕。 下图是我们数据集中的标签示例，标记了三个划痕。

金属标签有划痕

定义管道架构

现在，我们已经清楚地了解了我们的用例和我们旨在解决的特定机器学习问题，该问题围绕边缘的对象检测。 现在是时候为我们的 MLOps 管道起草架构了。 在这个阶段，我们还没有关注技术或特定服务，而是关注管道的高级组件。 为了快速重新训练和部署，我们需要自动化整个端到端流程：从数据标记，到训练，再到推理。 然而，存在一些挑战使得为边缘情况设置管道特别困难：

  • 构建此过程的不同部分需要不同的技能。 例如，数据标记和培训非常注重数据科学，边缘部署需要物联网 (IoT) 专家，而整个过程的自动化通常由具有 DevOps 技能的人员来完成。
  • 根据您的组织，整个过程甚至可能由多个团队实施。 对于我们的用例，我们假设不同的团队负责标签、培训和部署。
  • 更多的角色和技能组合意味着对工具和流程的不同要求。 例如，数据科学家可能希望监控和使用他们熟悉的笔记本电脑环境。 MLOps 工程师希望使用基础设施即代码 (IaC) 工具进行工作，并且可能更熟悉 AWS管理控制台.

这对我们的管道架构意味着什么？

首先，明确定义端到端系统的主要组件非常重要，这样不同的团队才能独立工作。 其次，必须定义团队之间明确的接口，以提高协作效率。 这些接口有助于最大限度地减少团队之间的干扰，使他们能够根据需要修改内部流程，只要他们遵守定义的接口。 下图说明了我们的计算机视觉管道的样子。

MLOps 管道涂鸦

让我们详细研究一下 MLOps 管道的整体架构：

  1. 该过程首先收集金属标签的原始图像，这些图像是在生产环境中使用边缘摄像头设备捕获的，以形成初始训练数据集。
  2. 下一步涉及标记这些图像并使用边界框标记缺陷。 对标记数据集进行版本控制至关重要，以确保所使用的训练数据的可追溯性和责任性。
  3. 获得标记数据集后，我们可以继续训练、微调、评估和版本控制我们的模型。
  4. 当我们对模型性能感到满意时，我们可以将模型部署到边缘设备并在边缘运行实时推理。
  5. 当模型在生产中运行时，边缘摄像头设备会生成有价值的图像数据，其中包含以前未见过的缺陷和边缘情况。 我们可以使用这些数据来进一步提高模型的性能。 为了实现这一目标，我们保存模型预测置信度较低或做出错误预测的图像。 然后将这些图像添加回我们的原始数据集，再次启动整个过程。

值得注意的是，原始图像数据、标记数据集和训练模型充当不同管​​道之间明确定义的接口。 MLOps 工程师和数据科学家可以灵活地选择其管道中的技术，只要他们始终如一地生成这些工件。 最重要的是，我们建立了一个封闭的反馈循环。 生产中做出的错误或低置信度预测可用于定期扩充我们的数据集并自动重新训练和增强模型。

目标架构

现在高层架构已经建立，是时候更深入地了解如何使用 AWS 服务来构建它了。 请注意，本文中显示的架构假设您想要完全控制整个数据科学过程。 但是，如果您刚刚开始进行边缘质量检查，我们建议 亚马逊Lookout for Vision。 它提供了一种训练您自己的质量检查模型的方法，而无需构建、维护或理解 ML 代码。 欲了解更多信息，请参阅 Amazon Lookout for Vision 现在支持在边缘对产品缺陷进行目视检查.

但是，如果您想完全控制，下图显示了架构的外观。

MLOps 管道架构

与之前类似，让我们逐步完成工作流程并确定哪些 AWS 服务适合我们的要求：

  1. 亚马逊简单存储服务 （Amazon S3）用于存储原始图像数据，因为它为我们提供了低成本的存储解决方案。
  2. 标签工作流程是使用 AWS步骤功能，一个无服务器工作流程引擎，可以轻松编排标签工作流程的步骤。 作为此工作流程的一部分，我们使用 亚马逊SageMaker地面真相 使用标签作业和受管理的劳动力来完全自动化标签。 AWS Lambda 用于准备数据、启动标记作业并将标签存储在 Amazon SageMaker功能商店.
  3. SageMaker Feature Store 存储标签。 它使我们能够集中管理和共享我们的功能，并为我们提供内置的数据版本控制功能，这使我们的管道更加强大。
  4. 我们使用以下方法来协调模型构建和训练流程 Amazon SageMaker管道。 它通过内置步骤与所需的其他 SageMaker 功能集成。 SageMaker 培训职位 用于自动化模型训练，以及 SageMaker 处理作业 用于准备数据并评估模型性能。 在此示例中，我们使用 Ultralytics YOLOv8 Python 包和模型架构，用于训练对象检测模型并将其导出到 昂尼克斯 ML 模型格式的可移植性。
  5. 如果性能可以接受，则将训练好的模型注册到 Amazon SageMaker 模型注册表 附有增量版本号。 它充当模型训练和边缘部署步骤之间的接口。 我们还在这里管理模型的批准状态。 与使用的其他服务类似，它是完全托管的，因此我们不必负责运行我们自己的基础设施。
  6. 边缘部署工作流程使用 Step Functions 实现自动化，类似于标记工作流程。 我们可以使用 Step Functions 的 API 集成轻松调用各种所需的 AWS 服务 API（例如 AWS IoT Greengrass）来创建新的模型组件，然后将组件部署到边缘设备。
  7. AWS IoT Greengrass 用作边缘设备运行时环境。 它管理边缘模型和推理组件的部署生命周期。 它使我们能够使用简单的 API 调用轻松部署新版本的模型和推理组件。 此外，边缘的机器学习模型通常不会孤立运行； 我们可以使用各种 AWS 和 社体的一部分 提供了 AWS IoT Greengrass 组件来连接到其他服务。

概述的架构类似于我们之前显示的高级架构。 Amazon S3、SageMaker Feature Store 和 SageMaker Model Registration 充当不同管​​道之间的接口。 为了最大限度地减少运行和操作解决方案的工作量，我们尽可能使用托管和无服务器服务。

合并到强大的 CI/CD 系统中

数据标记、模型训练和边缘部署步骤是我们解决方案的核心。 因此，与任何这些部分中的底层代码或数据相关的任何更改都应该触发整个编排过程的新运行。 为了实现这一目标，我们需要将此管道集成到 CI/CD 系统中，该系统允许我们自动将代码和基础架构更改从版本化代码存储库部署到生产中。 与之前的架构类似，团队自治是这里的一个重要方面。 下图显示了使用 AWS 服务时的情况。

CI/CD 管道

让我们看一下 CI/CD 架构：

  1. AWS 代码提交 充当我们的 Git 存储库。 为了简单起见，在我们提供的示例中，我们通过单个 git 存储库中的子文件夹分隔了不同的部分（标签、模型训练、边缘部署）。 在现实场景中，每个团队可能会为每个部分使用不同的存储库。
  2. 基础设施部署使用 AWS CDK 实现自动化，每个部分（标签、训练和边缘）都有自己的 AWS CDK 应用程序以允许独立部署。
  3. AWS CDK 管道功能使用 AWS 代码管道 自动化基础设施和代码部署。
  4. AWS CDK 为每个步骤部署两个代码管道：资产管道和工作流管道。 我们将工作流程与资产部署分开，以便在没有资产更改的情况下（例如，当有新图像可用于训练时）单独启动工作流程。
    • 资产代码管道部署工作流成功运行所需的所有基础设施，例如 AWS身份和访问管理 训练期间使用的 (IAM) 角色、Lambda 函数和容器映像。
    • 工作流代码管道运行实际的标记、训练或边缘部署工作流。
  5. 资产管道在提交时以及先前的工作流程管道完成时自动触发。
  6. 整个过程是按计划触发的 亚马逊EventBridge 定期再培训的规则。

通过 CI/CD 集成，整个端到端链现已完全自动化。 每当 git 存储库中的代码发生更改以及按计划适应数据更改时，都会触发管道。

往前想

所描述的解决方案架构代表了在边缘构建端到端 MLOps 管道的基本组件。 但是，根据您的要求，您可能会考虑添加其他功能。 以下是一些示例：

结论

在这篇文章中，我们概述了使用 AWS 服务构建端到端 MLOps 管道以在边缘进行视觉质量检查的架构。 该架构简化了整个流程，包括数据标记、模型开发和边缘部署，使我们能够快速可靠地训练和实施新版本的模型。 借助无服务器和托管服务，我们可以将重点放在提供业务价值而不是管理基础设施上。

In 部分2 在本系列中，我们将更深入地研究这个架构的实现，特别是标签和模型构建。 如果您想直接跳到代码，您可以查看随附的 GitHub回购.

关于作者

迈克尔·罗斯迈克尔·罗斯 是 AWS 的高级解决方案架构师，支持德国的制造业客户通过 AWS 技术解决他们的业务挑战。 除了工作和家庭之外，他还对跑车感兴趣并喜欢意大利咖啡。

约尔格·沃尔勒约尔格·沃尔勒 是 AWS 的解决方案架构师，与德国的制造客户合作。 Joerg 对自动化充满热情，在加入 AWS 之前曾担任过软件开发人员、DevOps 工程师和站点可靠性工程师。 除了云之外，他还是一位雄心勃勃的跑步者，享受与家人在一起的美好时光。 因此，如果您面临 DevOps 挑战或想要尝试一下：请告诉他。

约翰内斯·兰格约翰内斯·兰格 是 AWS 的高级解决方案架构师，与德国的企业客户合作。 Johannes 热衷于应用机器学习来解决实际的业务问题。 在个人生活中，约翰内斯喜欢从事家居装修项目并与家人一起在户外度过时光。

时间戳记：

更多来自 AWS机器学习