MLOps-工程指南-全-

MLOps 工程指南（全）

原文：annas-archive.org/md5/c0519d92859e86c99b606931513a3258

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

MLOps 是一种系统化的方法，用于构建、部署和监控机器学习（ML）解决方案。它是一种可以应用于各个行业和用例的工程学科。本书通过结合现实世界案例，提供了对 MLOps 的全面见解，帮助你编写程序、训练健壮且可扩展的机器学习模型，并构建机器学习管道，以安全地在生产中训练和部署模型。

你将从熟悉 MLOps 工作流程开始，并开始编写训练机器学习模型的程序。然后，你将探索训练后序列化和打包机器学习模型以在生产中部署并促进机器学习推理的选项。接下来，你将学习如何使用可解释的监控框架监控机器学习模型和系统性能。最后，你将应用所学知识来构建现实世界项目。

在阅读完这本机器学习书籍之后，你将获得 MLOps 的全方位视角，并准备好在你的组织中实施 MLOps。

本书面向的对象

这本 MLOps 书籍是为数据科学家、软件工程师、DevOps 工程师、机器学习工程师以及希望使用 MLOps 原则和技术在生产中构建、部署和维护机器学习系统的商业和技术领导者所写。为了开始阅读本书，需要具备基本的机器学习知识。

本书涵盖的内容

第一章，MLOps 工作流程基础，通过强调传统软件开发如何转变为促进机器学习，概述了不断变化的软件开发领域。我们将突出组织内部使用传统方法的一些日常问题，展示为什么需要思维和实施的转变。随后，将介绍系统化机器学习的重要性，接着是一些机器学习和 DevOps 的概念，并将它们融合到 MLOps 中。本章以一个通用的工作流程提案结束，该工作流程可以用于解决几乎任何机器学习问题。

第二章，描述你的机器学习问题，为你提供了对生产中可能的机器学习解决方案类型的广泛视角。你将学习如何对解决方案进行分类，制定开发和部署解决方案的路线图，以及获取开始开发机器学习解决方案所需的数据、工具或基础设施，采用系统化的方法。

第三章，代码与数据相遇，开始了我们动手实践的业务用例——开发机器学习解决方案的实施。我们讨论了机器学习源代码管理的高效方法，针对业务用例的数据处理，并制定了一个机器学习训练和部署的数据治理策略和流程。

第四章, 机器学习管道, 深入探讨了构建用于解决方案的机器学习管道。我们探讨了特征工程、算法选择、超参数优化以及稳健机器学习管道的其他方面的关键要素。

第五章, 模型评估和打包, 深入探讨了在训练后序列化和打包机器学习模型以在运行时部署它们的选项，以促进机器学习推理、模型互操作性和端到端模型可追溯性。您将获得关于可用选项和最先进发展的广泛视角，以及如何打包和为生产环境提供机器学习模型以实现高效、稳健和可扩展的服务。

第六章, 部署您的 ML 系统的关键原则，介绍了在各种设置中在生产环境中实施持续集成和部署的概念。您将学习如何选择正确的选项、工具和基础设施，以促进机器学习解决方案的部署。您将了解机器学习推理选项和部署目标，并了解机器学习的 CI/CD 管道。

第七章, 构建稳健的 CI/CD 管道, 涵盖了不同的 CI/CD 管道组件，如触发器、发布、作业等。它还将为您提供创建自己定制的 CI/CD 管道以用于机器学习解决方案的知识。我们将为商业用例构建一个机器学习解决方案的 CI/CD 管道。我们构建的管道将端到端可追溯，因为它们将作为模型部署和监控的中介。

第八章, API 和微服务管理, 讨论了 ML 推理的 API 和微服务设计原则。将鼓励实践学习的方法。我们将通过使用 FastAPI 和 Docker 等工具来设计和开发一个 ML 模型的 API 和微服务的实际操作实现。您将学习设计稳健和可扩展的微服务和 API 的关键原则、挑战和技巧，以适应测试和生产环境。

第九章, 测试和保障您的 ML 解决方案, 介绍了在测试环境中执行测试的核心原则，以测试我们之前开发的微服务或 API 的稳健性和可扩展性。我们将对部署的 ML 解决方案进行实际的手动负载测试。本章提供了一个测试清单，在将微服务投入生产发布之前需要完成。

第十章，生产发布要素，解释了如何使用之前设计的强大且可扩展的 CI/CD 管道将机器学习服务部署到生产环境中。我们将重点关注生产环境中的部署、监控和管理服务。关键学习内容包括使用 Python、Docker 和 Kubernetes 等工具在无服务器和服务器环境中进行部署。

第十一章，监控您的机器学习系统的关键原则，探讨了在生产环境中监控机器学习系统的关键原则和方面，以确保其稳健、安全和可扩展的性能。作为关键成果，读者将获得一个具体的可解释监控框架和清单，用于设置和配置其机器学习解决方案的生产监控框架。

第十二章，模型服务和监控，解释了向用户提供服务模型和为机器学习解决方案定义指标，特别是在算法效率、准确性和生产性能方面。我们将深入探讨实际操作和真实案例，包括监控数据漂移、模型漂移和应用性能。

第十三章，持续学习中的机器学习系统治理，反思了在机器学习解决方案中持续学习的必要性。我们将探讨成功治理机器学习系统以实现商业效益所需的内容。使用可解释监控框架，我们将制定治理策略，并深入探讨错误处理、配置警报和操作的实战实施。本章将为您提供自动化和治理 MLOps 的关键技能。

要充分利用这本书

您应该能够访问 Microsoft Azure 订阅以及用于构建 CI/CD 管道的基于 DevOps 的基本软件。拥有一台运行 Linux 或 macOS 的个人电脑或笔记本电脑将是一个加分项。

如果您正在使用这本书的数字版，我们建议您亲自输入代码或通过 GitHub 仓库（下一节中提供链接）访问代码。这样做将帮助您避免与代码复制粘贴相关的任何潜在错误。

下载示例代码文件

您可以从 GitHub 下载本书的示例代码文件：github.com/PacktPublishing/EngineeringMLOps。如果代码有更新，它将在现有的 GitHub 仓库中更新。我们还有其他丰富的图书和视频的代码包，可在github.com/PacktPublishing/找到。请查看它们！

下载彩色图像

我们还提供了一份包含本书中使用的截图/图表彩色图像的 PDF 文件。您可以从这里下载：static.packt-cdn.com/downloads/9781800562882_ColorImages.pdf。

使用的约定

本书使用了多种文本约定。

文本中的代码: 表示文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 昵称。以下是一个示例：“使用.get_by_name()函数导入预处理后的数据集。”

代码块按照以下方式设置：

uri = workspace.get_mlflow_tracking_uri( )
mlflow.set_tracking_uri(uri)

当我们希望您注意代码块中的特定部分时，相关的行或项目将以粗体显示：

# Importing pre-processed dataset
dataset = Dataset.get_by_name (workspace, name='processed_weather_data_portofTurku')

任何命令行输入或输出都按照以下方式编写：

python3 test_inference.py

粗体: 表示新术语、重要单词或您在屏幕上看到的单词。例如，菜单或对话框中的单词在文本中显示如下。以下是一个示例：“转到计算选项，点击创建按钮以探索云上可用的计算选项。”

小贴士或重要注意事项

显示如下。

联系我们

我们欢迎读者的反馈。

customercare@packtpub.com.

勘误表: 尽管我们已经尽最大努力确保内容的准确性，但错误仍然可能发生。如果您在这本书中发现了错误，我们将非常感激您能向我们报告。请访问www.packtpub.com/support/errata，选择您的书籍，点击勘误表提交表单链接，并输入详细信息。

copyright@packt.com 并附有材料链接。

如果您有兴趣成为作者: 如果您在某个主题上具有专业知识，并且您有兴趣撰写或为书籍做出贡献，请访问 authors.packtpub.com。

评论

请留下评论。一旦您阅读并使用了这本书，为什么不在这里购买它的网站上留下评论呢？潜在读者可以查看并使用您的客观意见来做出购买决定，Packt 可以了解您对我们产品的看法，我们的作者也可以看到他们对书籍的反馈。谢谢！

如需了解 Packt 的更多信息，请访问packt.com。

第一部分：构建机器学习模型的框架

本部分将为读者提供 MLOps 和工作流程的基础，帮助他们描述机器学习问题，为构建稳健且可扩展的机器学习管道提供清晰的路线图。这将通过使用提出的方法和工具（Azure 机器学习服务或 MLflow）的实际实施来实现，采用边做边学的方法。

本节包括以下章节：

• 第一章, MLOps 工作流程基础

• 第二章, 描述你的机器学习问题

• 第三章, 代码与数据相遇

• 第四章, 机器学习管道

• 第五章, 模型评估和打包

第一章：MLOps 工作流程的基础

机器学习（ML）正从研究走向应用商业解决方案。然而，残酷的现实是，只有 2%使用机器学习的企业成功地将模型部署到生产环境中以增强其业务流程，这是由 DeepLearning.AI 报告的（info.deeplearning.ai/the-batch-companies-slipping-on-ai-goals-self-training-for-better-vision-muppets-and-models-china-vs-us-only-the-best-examples-proliferating-patents）。这为什么会如此困难？我们还需要做什么来改善这种情况？

为了对这个问题及其解决方案有一个扎实的理解，在本章中，我们将深入探讨软件开发与机器学习（ML）的演变和交汇。我们将从传统的瀑布模型开始，反思传统软件开发的一些趋势，到敏捷开发再到 DevOps 实践，以及这些实践如何演变以实现以机器学习为中心的应用的工业化。您将了解到使用机器学习操作（MLOps）实现 AI 运营的系统方法。到本章结束时，您将对 MLOps 有一个扎实的理解，并准备好实施一个通用的 MLOps 工作流程，该工作流程可用于构建、部署和监控各种机器学习应用。

在本章中，我们将涵盖以下主要主题：

• 基础设施和软件开发的发展

• 传统软件开发挑战

• 软件开发中机器学习采用的趋势

• 理解 MLOps

• MLOps 的概念和工作流程

基础设施和软件开发的发展

随着现代互联网时代的起源（大约在 1995 年），我们见证了软件应用的兴起，从 Windows 95 这样的操作系统到 Linux 操作系统，再到 Google 和 Amazon 等网站，这些网站已经为世界（在线）服务了二十多年。这导致了通过收集、存储和处理来自用户交互的大量数据来不断改进服务的文化。这些发展正在塑造 IT 基础设施和软件开发的发展。

自本世纪初以来，IT 基础设施的转型步伐加快。从那时起，企业越来越多地采用云计算，因为它为企业在外包 IT 基础设施维护的同时，提供了必要的 IT 资源，如存储和计算资源以及运行和扩展其运营所需的服务。

云计算提供了按需提供和 IT 资源（如数据存储和计算资源）的可用性，无需用户对 IT 资源进行主动管理。例如，提供计算和存储资源的公司无需直接管理这些资源，也不负责保持它们运行——维护工作外包给了云服务提供商。

使用云计算的企业可以从中获益，因为它们无需购买和维护 IT 资源；这使它们在 IT 资源维护方面的内部专业知识需求减少，从而允许企业优化成本和资源。云计算使按需扩展成为可能，用户按资源使用量付费。因此，我们看到许多公司已经开始将云计算作为其业务和 IT 基础设施的一部分。

从 2006 年开始，云计算在业界变得流行，当时太阳微系统公司在 2006 年 3 月推出了 Sun Grid。这是一个硬件和数据资源共享服务。这项服务被甲骨文公司收购，后来更名为 Sun Cloud。同时，在同年（2006 年），亚马逊推出了另一项名为弹性计算云（Elastic Compute Cloud）的云计算服务。这为企业在按需提供计算、存储和扩展能力方面开辟了新的可能性。从那时起，各行业向采用云计算的转变已经是有机发生的。

在过去十年中，许多全球和区域性的公司推动了云转型，例如谷歌、IBM、微软、UpCloud、阿里巴巴等公司都在云计算服务的研发上进行了大量投资。因此，由于强大的可扩展云服务的可用性，从本地化计算（公司拥有自己的服务器和数据中心）向按需计算转变已经发生。现在，企业和组织能够在云上按需提供资源，以满足他们的数据处理需求。

随着这些发展，我们见证了摩尔定律在发挥作用，该定律指出，每两年微芯片上的晶体管数量翻一番——尽管计算机的成本减半，但这至今一直如此。随后，一些趋势正在如下发展。

机器学习和深度学习的兴起

在过去十年中，我们见证了机器学习在日常生活中的应用。不仅限于像Dota或AlphaGo这样的专业应用，机器学习也进入了相当标准的应用，如机器翻译、图像处理和语音识别。

这种采用得益于基础设施的发展，特别是在计算能力的利用方面。它释放了深度学习和机器学习的潜力。我们可以从图 1.1（来源：OpenAI：openai.com/blog/ai-and-compute）中观察到与计算发展相关的深度学习突破：

图 1.1 – 随时间推移由计算支持的深度学习需求

深度学习领域的这些突破得益于计算能力的指数级增长，大约每 18 个月增长 35 倍。展望未来，面对这样的需求，我们可能会在扩大 CPU、GPU 或 TPU 的中心计算规模方面遇到瓶颈。这迫使我们考虑替代方案，例如分布式学习，其中数据处理计算分布在多个计算节点上。我们已经看到了分布式学习的一些突破，例如联邦学习和边缘计算方法。分布式学习有望满足深度学习不断增长的需求。

摩尔定律的终结

在 2012 年之前，AI 的结果与摩尔定律紧密相关，计算能力每两年翻一番。2012 年之后，计算能力每 3.4 个月翻一番（来源：2019 年 AI 指数 – hai.stanford.edu/research/ai-index-2019）。从图 1.1中我们可以观察到，深度学习和高性能计算（HPC）的需求正以每 18 个月约 35 倍的速度呈指数增长，而摩尔定律似乎已经落后（每 18 个月翻一番）。摩尔定律仍然适用于 CPU（单核性能）的情况，但不适用于 GPU 和 TPU 等新的硬件架构。这使得摩尔定律在当前需求和趋势面前变得过时和落后。

以 AI 为中心的应用程序

应用程序正变得越来越以 AI 为中心——我们在多个行业中都能看到这一点。几乎每个应用程序都开始使用 AI，并且这些应用程序正在分布式工作负载上分别运行，如图图 1.2所示：高性能计算（HPC）、微服务和大数据：

图 1.2 – 在分布式工作负载上运行的应用程序

通过结合高性能计算（HPC）和人工智能（AI），我们可以实现训练深度学习（deep learning）和机器学习（ML）模型所需的计算优势。随着大数据和 AI 的融合，我们可以利用大规模提取所需数据来训练 AI 模型，并且随着微服务（microservices）和 AI 的融合，我们可以为推理服务 AI 模型，以增强业务运营和影响。这样，分布式应用已成为新的常态。在规模上开发以 AI 为中心的应用需要分布式应用（HPC、微服务和大数据）的协同作用，为此，需要一种新的软件开发方式。

软件开发演变

软件开发与基础设施的发展同步演变，以促进使用该基础设施高效地开发应用程序。传统上，软件开发从瀑布模型开始，开发是线性的，从收集需求到设计和开发。瀑布模型有许多局限性，这导致了多年来软件开发以敏捷方法（Agile methodologies）和 DevOps 方法的形式演变，如图图 1.3所示：

图 1.3 – 软件开发演变

瀑布模型

瀑布模型从互联网时代开始（约 1995 年）就被用来开发软件。这是一种非迭代的软件开发方式。它以单向的方式交付。每个阶段都是预先组织和执行的，从需求收集到软件设计、开发和测试。当需求明确、具体且不随时间变化时，瀑布模型是可行且合适的。因此，它不适合需求会变化和根据用户需求演变的动态项目。在这种情况下，如果存在持续的修改，就不能使用瀑布模型来开发软件。这些都是瀑布开发方法的主要缺点：

• 在开始开发之前必须给出整个需求集；在项目开发期间或之后修改它们是不可能的。

• 很少有机会创建或实现可重用的组件。

• 测试只能在开发完成后进行。测试不是可迭代的；一旦完成，就无法回去修复任何东西。此外，客户验收测试经常引入变化，导致交付延迟和成本高昂。这种开发和测试方式可能会对项目交付时间表和成本产生负面影响。

• 大多数情况下，系统的用户都是基于开发者的理解来配置的，这种系统不是以用户为中心的，可能无法满足他们的需求。

敏捷方法

敏捷方法促进了软件开发的迭代和渐进式方法。与瀑布方法不同，敏捷方法精确且以用户为中心。该方法是双向的，通常涉及最终用户或客户参与开发和测试过程，以便他们在项目开发过程和阶段中有机会测试、提供反馈和提出改进建议。敏捷方法相对于瀑布方法有以下几个优点：

• 在开始开发之前定义需求，但它们可以在任何时候进行修改。

• 有可能创建或实现可重用组件。

• 解决方案或项目可以通过将项目划分为不同的模块并定期交付来模块化。

• 用户或客户可以通过定期测试和评估开发解决方案模块来共同创造，以确保满足业务需求。这样的以用户为中心的过程确保了关注满足客户和业务需求的质量结果。

下面的图表显示了瀑布和敏捷方法之间的差异：

![图 1.4 – 瀑布模型与敏捷方法之间的差异

![img/B16572_01_004.jpg]

图 1.4 – 瀑布模型与敏捷方法之间的差异

DevOps 方法

DevOps 方法通过进一步简化软件变更在构建、测试、部署和交付阶段之间的流动，扩展了敏捷开发实践。DevOps 赋予跨职能团队执行由持续集成、持续部署和持续交付驱动的软件应用的自主权。它鼓励软件开发人员和 IT 操作人员之间的协作、集成和自动化，以提高以客户为中心的软件交付的效率、速度和质量。DevOps 为设计、测试、部署和监控生产环境中的系统提供了一个简化的软件开发框架。DevOps 使得软件能够在几分钟内发布到生产环境，并保持其稳定运行。

传统软件开发挑战

在上一节中，我们观察了传统软件开发从瀑布模型向敏捷和 DevOps 实践的转变。敏捷和 DevOps 实践使公司能够可靠地发布软件。DevOps 使得软件能够在几分钟内发布到生产环境，并保持其稳定运行。这种方法如此成功，以至于许多公司已经开始采用它，那么为什么我们不能继续为机器学习应用做同样的事情呢？

主要原因是机器学习开发与传统软件开发之间存在根本性的差异：机器学习不仅仅是代码；它是代码加上数据。一个机器学习模型是通过应用算法（通过代码）来拟合数据，从而生成一个机器学习模型，如图1.5所示：

![图 1.5 – 机器学习 = 数据 + 代码

![img/B16572_01_005.jpg]

图 1.5 – 机器学习 = 数据 + 代码

在开发环境中，代码被精心制作，而数据则来自多个来源，用于训练、测试和推理。数据在体积、速度、真实性和多样性方面随着时间的推移而变得强大且不断变化。为了跟上数据的发展，代码也会随着时间的推移而演变。为了有更直观的了解，它们之间的关系可以观察为代码和数据生活在不同的平面上，这些平面共享时间维度，但在所有其他方面都是独立的。ML 开发过程的挑战在于以受控的方式在这两个平面之间建立桥梁：

图 1.6 – 随时间推移的数据和代码进展

随着时间的推移，数据和代码最终走向两个方向，目标都是构建和维护一个强大且可扩展的 ML 系统。这种脱节导致了许多挑战，任何试图将 ML 模型投入生产的人都必须解决这些挑战。它带来了诸如缓慢、脆弱、碎片化和不一致的部署，以及缺乏可重复性和可追溯性的挑战。

为了克服这些挑战，MLOps 通过在时间进程中将数据和代码结合起来，提供了一种系统性的方法。这是解决传统软件开发方法在 ML 应用方面所提出的挑战的解决方案。使用 MLOps 方法，数据和代码随着时间的推移在一个方向上进步，目标是构建和维护一个强大且可扩展的 ML 系统：

图 1.7 – MLOps – 数据和代码共同进步

MLOps 通过一种简化和系统化的方法促进 ML 模型的发展、部署和监控。它使数据科学和 IT 团队能够协作、验证和治理他们的操作。团队执行的所有操作都被记录或审计，端到端可追溯且可重复。在接下来的章节中，我们将学习 MLOps 如何使数据科学和 IT 团队能够构建和维护强大且可扩展的 ML 系统。

软件开发中机器学习采用的趋势

在我们深入探讨 MLOps 方法和工作流程之前，了解 MLOps 在全球范围内如何颠覆以及其大图景和趋势是有益的。由于许多应用正变得以 AI 为中心，软件开发正在演变以促进 ML。ML 将越来越多地成为软件开发的一部分，主要原因如下：

• 投资：2019 年，全球私人人工智能投资超过 700 亿美元，其中与人工智能相关的初创企业投资超过 370 亿美元，并购投资 340 亿美元，首次公开募股（IPO）50 亿美元，以及约 20 亿美元的少数股权。全球人工智能的市场价值预测显示，随着 2018 年人工智能达到 95 亿美元，预计到 2025 年将达到 1180 亿美元。据评估，到 2030 年，由人工智能引发的经济活动增长将具有很高的价值和意义。目前，美国吸引了约 50%的全球风险投资（VC），中国约 39%，11%流向欧洲。

• 大数据：数据在量、速度、真实性和多样性方面呈指数级增长。例如，观察表明，在欧洲，数据量每年增长 61%，预计到 2025 年，将比现在多出四倍的数据。数据是开发人工智能的必需原材料。

• 基础设施发展和采用：摩尔定律一直被密切关注，并在 2012 年之前得以实现。2012 年之后，计算能力每 3.4 个月翻一番。

• 研发增长：人工智能研究在质量和数量上都在蓬勃发展。从 1998 年到 2018 年，同行评审的人工智能论文数量增长了 300%，总计占已发表会议论文的 9%和同行评审期刊发表的 3%。

• 产业：根据一份调查报告，47%的大公司报告称至少在一个职能或业务单元中采用了人工智能。到 2019 年，这一比例上升至 58%，预计还将继续增长。

  信息

  这些观点来源于对可信赖人工智能的政策和投资建议——欧洲委员会(ec.europa.eu/digital-single-market/en/news/policy-and-investment-recommendations-trustworthy-artificial-intelligence)和 AI 指数 2019(hai.stanford.edu/research/ai-index-2019)。

所有这些发展都表明，人工智能的工业化进程正在加速，这是通过连接产业和研究实现的。MLOps 将在人工智能的工业化中扮演关键角色。如果你投资学习这种方法，它将使你在公司或团队中领先一步，你可能会成为实现机器学习和工业化的催化剂。

到目前为止，我们已经了解了 IT、软件开发和人工智能的一些挑战和发展。接下来，我们将从概念上深入了解 MLOps，并详细学习一个通用的 MLOps 工作流程，该流程可以用于任何用例。这些基础知识将帮助你牢固掌握 MLOps。

理解 MLOps

软件开发是跨学科的，并且正在不断发展以促进机器学习。MLOps 是一种新兴的方法，通过整合多个领域（MLOps 结合了机器学习、DevOps 和数据工程），将机器学习与软件开发融合，旨在在生产环境中可靠且高效地构建、部署和维护机器学习系统。因此，MLOps 可以通过这种交叉点来阐述。

图 1.8 – MLOps 交叉点

为了使这个交叉点（MLOps）能够运行，我遵循了 Wieringa 提出的系统化设计科学方法(doi.org/10.1007/978-3-662-43839-8)设计了一个模块化框架，以开发一个工作流程，将这三个领域（数据工程、机器学习和 DevOps）结合起来。设计科学伴随着将设计应用于问题和情境。在这个案例中，工件是 MLOps 工作流程，它是通过迭代与问题情境（AI 应用案例的行业用例）交互而设计的。设计科学是在情境中对工件的设计和研究。在这个案例中，工件是 MLOps 工作流程，它是通过迭代与问题情境（AI 应用的行业用例）交互而设计的：

图 1.9 – 设计科学工作流程

采用结构化和迭代的方法，通过迭代对 MLOps 工作流程设计进行了定性和定量分析，包括两个周期（设计周期和经验周期）。这些周期导致开发并验证了一个 MLOps 工作流程，通过将其应用于多个问题情境，即跨多个行业的数十个机器学习用例（例如，异常检测、实时交易、预测性维护、推荐系统、虚拟助手等）。我已经在多个行业的多个项目中成功应用并验证了这个 MLOps 工作流程，以实施机器学习。在下一节中，我们将探讨设计科学过程的结果所设计的 MLOps 工作流程的概念。

MLOps 的概念和工作流程

在本节中，我们将了解一个通用的 MLOps 工作流程；它是通过前述章节中讨论的许多设计周期迭代的结果。它以简化的方式将数据工程、机器学习和 DevOps 结合起来。图 1.10 是一个通用的 MLOps 工作流程；它是模块化和灵活的，可用于构建概念验证或在任何商业或行业中实施机器学习解决方案：

图 1.10 – MLOps 工作流程

此工作流程分为两个模块：

• MLOps 管道（构建、部署和监控）– 上层

• 驱动因素：数据、代码、工件、中间件和基础设施 – 中下层

上层是 MLOps 管道（构建、部署和监控），它由数据、代码、工件、中间件和基础设施等驱动程序启用。MLOps 管道由一系列服务、驱动程序、中间件和基础设施提供动力，并构建 ML 驱动的解决方案。通过使用此管道，企业或个人可以快速进行原型设计、测试和验证，并以经济高效的方式将模型（s）部署到生产环境中。

为了理解 MLOps 工作流程的运作和实现，我们将通过一个比喻性的商业案例来查看每一层和每一步的实现。

讨论用例

在这个用例中，我们需要将（原型设计和部署到生产环境）一个图像分类服务进行运营，以对位于西班牙巴塞罗那的宠物公园中的猫和狗进行分类。该服务将实时从安装在宠物公园的监控摄像头中获取的推理数据中识别猫和狗。

宠物公园为您提供访问数据和基础设施的权限，以实现服务的运营：

• 数据: 宠物公园已经为您提供了访问其数据湖的权限，其中包含 10 万张标记好的猫和狗的图片，我们将使用这些图片来训练模型。

• 基础设施: 公共云（IaaS）。

这个用例类似于实际生活中的 ML 运营用例，用于解释 MLOps 工作流程的运作和实现。请记住，在每个 MLOps 工作流程的每个部分和步骤中寻找对这个用例实现的解释。现在，让我们详细查看每一层和每一步的运作。

MLOps 管道

MLOps 管道是上层，执行构建、部署和监控等操作，这些操作以模块化方式相互同步。让我们深入了解每个模块的功能。

构建

构建模块包含核心 ML 管道，这纯粹是为了训练、打包和版本控制 ML 模型。它由运行 ML 训练和管道所需的计算资源（例如，云或分布式计算中的 CPU 或 GPU）提供动力：

图 1.11 – MLOps – 构建管道

管道从左到右工作。让我们详细查看每一步的功能：

• 数据摄取: 这一步是 ML 管道的触发步骤。它通过从各种数据源（例如，数据库、数据仓库或数据湖）提取数据，并摄取模型训练步骤所需的必要数据来处理数据的量、速度、真实性和多样性。连接到多个数据源的健壮数据管道能够执行提取、转换和加载（ETL）操作，为 ML 训练提供必要的数据。在这一步中，我们可以根据所需格式（例如，训练集或测试集）对数据进行拆分和版本控制。因此，任何实验（即模型训练）都可以进行审计，并且可以回溯。

  为了更好地理解数据摄取步骤，以下是之前描述的用例实现：

  用例实现

  由于你有访问宠物公园数据湖的权限，你现在可以获取数据以开始。使用数据管道（数据摄取步骤的一部分），你执行以下操作：

  1. 提取、转换并加载 10 万张猫和狗的图片。

  2. 将这些数据分割并版本化为训练集和测试集（80%和 20%的分割）。

  对数据进行版本控制将使训练的模型实现端到端的可追溯性。

  恭喜——现在你已准备好开始使用这些数据训练和测试机器学习模型。

• 模型训练：在上一步骤中获取了用于机器学习模型训练所需的数据后，这一步骤将启用模型训练；它包含模块化脚本或代码，执行机器学习中的所有传统步骤，例如在训练或重新训练任何模型之前进行数据预处理、特征工程和特征缩放。随后，在执行超参数调整以使模型适应数据集（训练集）的过程中进行机器学习模型的训练。这一步骤可以手动完成，但存在如网格搜索或随机搜索等高效且自动的解决方案。因此，所有重要的机器学习模型训练步骤都通过这一步骤以机器学习模型作为输出执行。

  用例实现

  在这一步骤中，我们实现了训练图像分类模型的所有重要步骤。目标是训练一个机器学习模型来对猫和狗进行分类。为此案例，我们为图像分类服务训练了一个卷积神经网络（CNN – towardsdatascience.com/wtf-is-image-classification-8e78a8235acb）。以下步骤得到实现：训练前的数据预处理、特征工程和特征缩放，随后通过超参数调整训练模型。结果，我们得到了一个 97%准确率的 CNN 模型来对猫和狗进行分类。

• 模型测试：在这一步骤中，我们评估训练的模型在分离的数据点集（测试数据，在数据摄取步骤中分割并版本化）上的性能。根据用例选择指标评估训练模型的推理。这一步骤的输出是关于训练模型性能的报告。

  用例实现

  我们在测试数据上测试训练的模型（我们在数据摄取步骤中较早分割了数据）以评估训练模型的性能。在这种情况下，我们寻找精确率和召回率来验证模型在分类猫和狗时的性能，以评估假阳性和真阳性，从而对模型性能有一个现实的理解。如果我们对结果满意，我们可以进入下一步，否则重复之前的步骤以获得一个适合宠物公园图像分类服务的良好性能模型。

• 模型打包：在前面步骤中对训练好的模型进行测试后，模型可以被序列化到文件或容器化（使用 Docker）以导出到生产环境。

  用例实现

  在前面的步骤中训练和测试的模型被序列化为 ONNX 文件，并准备好在生产环境中部署。

• 模型注册：在这个步骤中，前面步骤中序列化或容器化的模型被注册并存储在模型注册表中。一个注册的模型是一个逻辑集合或包，它组装、表示和执行你的机器学习模型。例如，多个文件可以注册为一个模型。例如，一个分类模型可以由一个向量器、模型权重和序列化模型文件组成。所有这些文件都可以注册为一个单一模型。注册后，模型（所有文件或单个文件）可以根据需要下载和部署。

  用例实现

  在前面的步骤中序列化的模型已在模型注册表中注册，并可用于快速部署到宠物公园生产环境。

  通过实施前面的步骤，我们成功执行了为我们的用例设计的机器学习流程。因此，我们在模型注册表中训练了模型，准备在生产设置中部署。接下来，我们将探讨部署流程的工作原理。

部署

部署模块使我们能够将前面模块（构建）中开发的机器学习模型进行操作化。在这个模块中，我们在生产环境或类似生产环境（测试）中对模型性能和行为进行测试，以确保机器学习模型在生产使用中的鲁棒性和可扩展性。图 1.12 描述了部署流程，该流程有两个组件 – 生产测试和生产发布 – 并且部署流程通过连接开发到生产环境的简化 CI/CD 管道来实现：

![Figure 1.12 – MLOps – deploy pipeline

![img/B16572_01_12.jpg]

图 1.12 – MLOps – 部署流程

它从左到右工作。让我们详细看看每个步骤的功能：

• 应用测试：在将机器学习模型部署到生产环境之前，通过测试来检验其鲁棒性和性能至关重要。因此，我们有一个“应用测试”阶段，在这个阶段，我们严格测试所有训练好的模型在类似生产环境的测试环境中对鲁棒性和性能。在应用测试阶段，我们在测试环境（预生产）中部署模型，该环境复制了生产环境。

  测试用的机器学习模型作为 API 或流式服务部署在测试环境中的部署目标，如 Kubernetes 集群、容器实例、可扩展的虚拟机或边缘设备，具体取决于需求和用例。在模型部署用于测试后，我们使用测试数据（这些数据未用于训练模型；测试数据是从生产环境中的样本数据）对部署的模型进行预测，在此期间对测试环境中部署的模型进行批量或定期推理以测试其鲁棒性和性能。

  性能结果由质量保证专家自动或手动审查。当机器学习模型的性能达到标准时，则批准其在生产环境中部署，在该环境中模型将被用于批量或实时推理以做出业务决策。

  用例实现

  我们将模型作为 API 服务部署在宠物公园的本地计算机上，该计算机是为测试目的而设置的。该计算机连接到公园的 CCTV 摄像头，以获取实时推理数据来预测视频帧中的猫或狗。模型部署由 CI/CD 管道启用。在此步骤中，我们在类似生产的环境中测试模型的鲁棒性，即模型是否始终如一地进行推理，以及准确性、公平性和错误分析。在此步骤结束时，如果模型符合标准，则质量保证专家对模型进行认证。

• 生产发布：之前测试和批准的模型部署在生产环境中进行模型推理以生成业务或运营价值。此生产发布由 CI/CD 管道部署到生产环境。

  用例实现

  我们将之前经过测试和批准的模型（由质量保证专家进行）作为 API 服务部署在连接到宠物公园 CCTV 的计算机上（生产环境）。该部署模型对来自宠物公园 CCTV 摄像头的实时视频数据进行机器学习推理，以实时分类猫或狗。

监控

监控模块与部署模块同步工作。使用可解释监控（将在第十一章，监控您的机器学习系统的关键原则）中详细讨论），我们可以监控、分析和治理部署的机器学习应用程序（机器学习模型和应用程序）。首先，我们可以监控机器学习模型（使用预定义的指标）和部署的应用程序（使用遥测数据）。其次，可以使用预定义的可解释性框架分析模型性能，最后，可以使用基于模型的质量保证和控制警报和操作来治理机器学习应用程序。这确保了生产系统的强大监控机制：

![图 1.13 – MLOps – 监控管道

图 1.13 – MLOps – 监控管道

让我们详细看看监控模块的每个能力：

• 监控：监控模块捕获关键信息以监控数据完整性、模型漂移和应用性能。可以使用遥测数据来监控应用性能。它描绘了生产系统在一段时间内的设备性能。通过加速度计、陀螺仪、湿度、磁力计、压力和温度等遥测数据，我们可以监控生产系统的性能、健康和寿命。

  用例实现

  在实时监控中，我们将监控公园计算机上部署的 API 服务的三个关键指标——数据完整性、模型漂移和应用性能。如准确性、F1 分数、精确率和召回率等指标被跟踪以评估数据完整性和模型漂移。我们通过跟踪运行部署的机器学习模型的生产系统（公园中的本地计算机）的遥测数据来监控应用性能，以确保生产系统的正常运行。遥测数据被监控以预见任何异常或潜在的故障，并提前修复。遥测数据被记录，可以用来评估生产系统性能随时间的变化，以检查其健康和寿命。

• 分析：分析在生产系统中部署的机器学习模型的性能对于确保与业务决策或影响相关的最佳性能和治理至关重要。我们使用模型可解释性技术来实时衡量模型性能。利用这一点，我们评估模型公平性、可信度、偏差、透明度和错误分析等重要方面，目的是改善与业务相关的模型。

  随着时间的推移，我们试图预测的目标变量的统计特性可能会以不可预见的方式发生变化。这种变化被称为“模型漂移”，例如，在我们部署推荐系统模型以向用户推荐合适的项目的情况下。由于无法观察到用于训练模型的历史数据中的不可预见趋势，用户行为可能会发生变化。考虑到这些不可预见因素，确保部署的模型提供最佳和最相关的业务价值至关重要。当观察到模型漂移时，应执行以下任何一项操作：

  a) 产品负责人或质量保证专家需要被通知。

  b) 需要切换或更新模型。

  c) 应触发管道的重新训练，以便根据最新的数据或需求重新训练和更新模型。

  用例实现

  我们监控在生产系统中部署的模型的表现（一个连接到宠物公园 CCTV 的电脑）。我们将定期（每天一次）分析模型的准确率、精确率和召回率，以确保模型的表现不会低于阈值。当模型的表现低于阈值时，我们将启动系统治理机制（例如，触发重新训练模型）。

• 治理：监控和分析是为了治理部署的应用程序，以驱动业务（或机器学习系统的目的）的最佳性能。在监控和分析生产数据后，我们可以生成某些警报和行动来治理系统。例如，当模型的表现低于预先定义的阈值（例如，低准确率、高偏差等）时，产品负责人或质量保证专家会收到警报。产品负责人启动一个触发器来重新训练和部署替代模型。最后，治理的一个重要方面是“合规”与当地和全球的法律和规则。为了合规，模型的可解释性和透明度至关重要。为此，进行模型审计和报告，以提供生产模型端到端的可追溯性和可解释性。

  用例实现

  我们监控和分析在生产系统中部署的模型的表现（一个连接到宠物公园 CCTV 的电脑）。基于对部署模型准确率、精确率和召回率的分析，定期（每天一次），当模型的表现低于预先定义的阈值时，会生成警报。公园的产品负责人会采取行动，这些行动基于警报。例如，生成一个警报通知产品负责人，生产模型检测狗比猫的偏差高达 30%。然后，产品负责人触发模型重新训练流程，使用最新数据更新模型以减少偏差，从而在生产中实现公平且稳健的模型。这样，巴塞罗那宠物公园的机器学习系统得到了良好的治理，以满足业务需求。

这就带我们来到了 MLOps 管道的尽头。所有使用 MLOps 方法训练、部署和监控的模型都是端到端可追溯的，并且它们的血缘记录在案，以便追踪模型的起源，包括模型用于训练的源代码、用于训练和测试模型的数据以及用于收敛模型的参数。完整的血缘记录对于审计操作或复制模型非常有用，或者在遇到阻塞时，记录的 ML 模型血缘记录有助于回溯模型的起源或观察和调试阻塞的原因。由于机器学习模型在推理过程中在生产中生成数据，这些数据可以与模型训练和部署血缘记录相关联，以确保端到端血缘记录，这对于某些合规性要求非常重要。接下来，我们将探讨使 MLOps 管道得以实现的关键驱动因素。

驱动因素

这些是 MLOps 管道的驱动因素：数据、代码、工件、中间件和基础设施。让我们深入了解每个驱动因素，以了解它们如何使 MLOps 管道得以实现：

![图 1.14 – MLOps 驱动因素

图 1.14 – MLOps 驱动因素

MLOps 管道的关键驱动因素如下定义：

• 数据：数据可以以多种形式存在，例如文本、音频、视频和图像。在传统的软件应用中，数据往往是有结构的，而对于机器学习应用来说，它可以是结构化的或非结构化的。为了管理机器学习应用中的数据，数据在这些步骤中处理：数据采集、数据标注、数据编目、数据准备、数据质量检查、数据抽样和数据增强。每个步骤都涉及它自己的生命周期。这使得为机器学习应用需要一套全新的流程和工具。为了使机器学习管道高效运行，数据被分割和版本化为训练数据、测试数据和监控数据（例如在生产中收集的模型输入、输出和遥测数据）。这些数据操作是 MLOps 管道的一部分。

• 代码：推动 MLOps 管道的三个基本代码模块是：训练代码、测试代码和应用代码。这些脚本或代码通过 CI/CD 和数据管道执行，以确保 MLOps 管道的稳健运行。源代码管理系统（例如，使用 Git 或 Mercurial）将启用编排，并在管理和无缝集成 CI、CD 和数据管道中发挥关键作用。所有代码都在源代码管理设置中阶段化和版本化（例如，Git）。

• 工件：MLOps 管道生成诸如数据、序列化模型、代码片段、系统日志、机器学习模型训练和测试指标信息等工件。所有这些工件都对 MLOps 管道的成功运行非常有用，确保其可追溯性和可持续性。这些工件通过使用中间件服务（如模型注册、工作区、日志服务、源代码管理服务、数据库等）进行管理。

• 中间件：中间件是向软件应用程序提供比操作系统提供的更多服务的计算机软件。中间件服务确保多个应用程序自动化和编排 MLOps 管道的过程。我们可以根据用例使用各种中间件软件和服务，例如，Git 用于源代码管理，VNets 用于启用所需的网络配置，Docker 用于将我们的模型容器化，以及 Kubernetes 用于容器编排以自动化应用程序的部署、扩展和管理。

• 基础设施：为了确保 MLOps 管道的成功运行，我们需要必要的计算和存储资源来训练和部署机器学习模型。计算资源使我们能够训练、部署和监控我们的机器学习模型。有两种类型的存储资源可以促进机器学习操作，即中心存储和特征存储。中心存储存储日志、工件、训练、测试和监控数据。特征存储是可选的，与中心存储互补。它使用特征管道提取、转换和存储机器学习模型训练和推理所需的特征。在基础设施方面，有多种选择，例如本地资源或基础设施即服务（IaaS），即云服务。如今，有许多云服务提供商提供 IaaS，例如亚马逊、微软、谷歌、阿里巴巴等。为您的用例选择合适的基础设施将使您的团队和公司能够进行稳健、高效和节约的操作。

  通过智能优化和所有这些驱动因素与 MLOps 管道的协同作用，可以实现完全自动化的工作流程。实施自动化 MLOps 工作流程的一些直接优势是提高 IT 团队的效率（通过减少数据科学家和开发人员在日常和重复性任务上的时间）和资源的优化，从而降低成本，这对任何企业来说都是非常好的。

摘要

在本章中，我们了解了软件开发和基础设施的演变，以促进机器学习的发展。我们深入探讨了 MLOps 的概念，随后熟悉了一个通用的 MLOps 工作流程，该工作流程可以应用于多个行业中的广泛机器学习解决方案。

在下一章中，你将学习如何将任何机器学习问题转化为由 MLOps 驱动的解决方案，并开始使用 MLOps 工作流程来开发它。

第二章：描述你的机器学习问题

在本章中，你将获得对可用于生产的各种类型机器学习（ML）解决方案的基本理解，并将学会根据你组织的商业和技术需求对相关操作进行分类。你将学习如何制定实现路线图以使机器学习解决方案投入运营，然后获取任何给定问题的必要工具和基础设施。到本章结束时，你将牢固地理解如何构建稳健且可扩展的机器学习解决方案，并获取实施这些解决方案所需的数据和工具。

机器学习运维（MLOps）旨在利用最先进的工程原理将学术界与工业界连接起来，我们将探讨来自学术界和工业界的不同元素，以获得对可能性的全面理解和认识。在开始构建你的 MLOps 解决方案之前，了解解决面向商业问题的各种可能性、设置、问题、解决方案和方法论是很重要的。为了达到这种理解，我们将在本章中涵盖以下主要主题：

• 机器学习解决方案开发过程

• 机器学习模型类型

• 描述你的 MLOps

• 解决方案的实现路线图

• 获取必要的数据、工具和基础设施

• 介绍一个现实生活中的商业问题

不再拖延，让我们深入探讨机器学习解决方案开发过程，并检查不同类型的机器学习模型以解决商业问题所提供的可能性。

机器学习解决方案开发过程

机器学习提供了许多增强和自动化业务的可能性。为了从机器学习中获得最佳效果，参与机器学习驱动的业务转型的团队和个人需要理解机器学习本身以及业务本身。有效的业务转型始于对业务的初步了解，包括价值链分析、用例识别、数据映射和业务模拟以验证业务转型。图 2.1 展示了开发机器学习解决方案以增强或自动化业务运营的过程：

图 2.1 – 机器学习解决方案开发过程

商业理解是开发机器学习解决方案的起点。在具备良好的商业理解之后，我们进入数据分析阶段，在此阶段获取、版本控制和存储正确的数据。使用数据管道消耗数据以进行机器学习建模，其中进行特征工程以获取训练模型所需的正确特征。我们评估训练好的模型并将它们打包以供部署。部署和监控使用利用持续集成/持续部署（CI/CD）功能的管道进行，这些功能使实时和持续部署成为可能，以便将训练好的机器学习模型服务于用户。此过程确保了稳健和可扩展的机器学习解决方案。

机器学习模型的类型

由于有选择性的机器学习和深度学习模型可以解决相同的企业问题，因此为了进行有效的算法选择，了解机器学习模型的全景至关重要。大约有 15 种机器学习技术，这些技术被分为 4 个类别，即学习模型、混合模型、统计模型和人机交互（HITL）模型，如以下矩阵所示（其中每个网格方格反映这些类别之一）在图 2.2中。值得注意的是，还有其他可能的分类机器学习模型的方法，并且它们都不是完全完整的，因此这些分类在某些场景中是合适的，而在其他场景中则不合适。以下是我们的推荐分类，用于查看机器学习模型：

图 2.2 – 机器学习模型的类型

学习模型

首先，我们将探讨两种标准学习模型，监督学习和无监督学习：

图 2.3 – 监督学习与无监督学习对比

监督学习

监督学习模型或算法是基于标记数据进行训练的。在训练数据中，输入的结果是标记或已知的。因此，模型被训练来预测当给定输入时基于其学习的标记数据的结果，并且你告诉系统哪个输出与系统中的给定输入相对应。

监督学习模型在窄人工智能案例和定义明确的任务上非常有效，但只能在有足够和全面标记数据的情况下发挥作用。我们可以在图 2.3中看到，在监督学习的情况下，模型已经学会了预测和分类输入。

考虑一个图像分类模型的例子，该模型用于对猫和狗的图像进行分类。一个监督学习模型在包含数千张正确标记的猫和狗图像的标记数据上训练。训练好的模型随后学会将给定的输入图像分类为包含狗或猫。

无监督学习

无监督学习与机器在没有人类监督的情况下四处运行并执行事情无关。无监督学习模型或算法从未标记的数据中学习。无监督学习可以用于从未标记数据中挖掘见解和识别模式。无监督算法广泛用于聚类或异常检测，而不依赖于任何标签。这些算法可以是模式发现算法；当数据被输入到这样的算法中时，它将识别模式，并将这些模式转化为一个新数据输入的配方，无需标签，并对其应用正确的标签。

无监督学习主要用于分析，尽管你也可以用它进行自动化和机器学习。由于这些算法的动态性质，它们会在每个训练周期中改变输出，因此建议不要在生产中使用这些算法。然而，它们可以用于自动化某些过程，例如分割传入数据或在实时中识别异常。

让我们讨论一个将新闻文章聚类到相关组中的例子。假设你拥有数千篇没有标签的新闻文章，而你希望识别文章的类型或类别。要对这些文章执行无监督学习，我们可以将一系列文章输入到算法中，并使其收敛到将相似事物组合在一起（即聚类）的四个组中。然后，我们查看这些聚类，发现相似的文章已经被分组到政治、体育、科学和健康等类别中。这是在数据中挖掘模式的一种方式。

混合模型

通过结合传统方法开发混合模型来解决各种商业和研究问题，机器学习（ML）已经取得了快速发展。让我们了解一下一些混合模型及其工作原理。图 2.4 展示了各种混合模型：

图 2.4 – 混合模型类型

半监督学习

半监督学习是监督学习和无监督学习的一种混合，用于只有少量样本被标记而大量样本未被标记的情况。半监督学习使得对可用数据进行有效利用（尽管并非所有数据都被标记）成为可能，包括未标记的数据。例如，文本文档分类器是半监督学习程序的一个典型例子。在这种情况下，很难找到大量标记的文本文档，因此半监督学习是理想的。这是因为让某人阅读整个文本文档只是为了分配一个基本的分类是不高效的。因此，半监督学习使得算法能够从有限数量的标记文本文档中学习，同时分类训练数据中存在的大量未标记文本文档。

自监督学习

自监督学习问题是无监督学习问题，其中数据未标记；这些问题被转换为监督学习问题，以便应用监督学习算法来持续解决它们。通常，自监督算法用于解决一个替代任务，在这个任务中它们自我监督以解决问题或生成输出。自监督学习的一个例子是生成对抗网络（GANs）；这些通常通过在标记和/或未标记数据上训练来生成合成数据。经过适当的训练，GAN 模型可以以自监督的方式生成相关输出。例如，一个 GAN 可以根据文本描述输入生成人脸，例如性别：男性，年龄：30，颜色：棕色等等。

多实例学习

多实例学习是一个监督学习问题，其中数据不是由单个数据样本标记，而是在类别或类别中累积标记。与典型的监督学习相比，其中每个数据样本都会进行标记，例如新闻文章被标记在政治、科学和体育等类别中，而在多实例学习中，标记是按类别进行的。在这种情况下，单个样本在多个类别中集体标记，并且通过使用监督学习算法，我们可以进行预测。

多任务学习

多任务学习是监督学习的一种体现，涉及在一个数据集上训练模型，并使用该模型来解决多个任务或问题。例如，对于自然语言处理，我们使用词嵌入或双向编码器表示从转换器（BERT）嵌入模型，这些模型在一个大型数据语料库上进行了训练。（BERT 是一个预训练模型，在大型文本语料库上进行了训练。该模型对给定的人类语言如何工作有深刻的理解。）这些模型可以用于解决许多监督学习任务，如文本分类、关键词提取、情感分析等。

强化学习

强化学习是一种学习类型，其中代理，如机器人系统，学习在定义的环境中操作以执行顺序决策任务或实现预定义的目标。同时，代理根据从环境中持续评估的反馈和奖励进行学习。反馈和奖励都用于塑造代理的学习，如图图 2.5所示。一个例子是谷歌的 AlphaGo，它最近击败了世界顶尖的围棋选手。经过 40 天的自我训练，使用反馈和奖励，AlphaGo 能够击败世界上最优秀的围棋选手：

图 2.5 – 强化学习

集成学习

集成学习是一种混合模型，涉及在相同数据上训练的两个或多个模型。使用每个模型单独进行预测，并通过结合所有输出并平均它们来确定最终结果或预测来做出集体预测。这种方法的例子是随机森林算法，它是一种用于分类或回归任务的集成学习方法。它在训练过程中组合多个决策树，并通过平均所有决策树的预测来创建输出预测。

迁移学习

我们人类天生具有将知识从一个人转移到另一个人的能力。这个相同的原理被应用到机器学习中，其中模型被训练来执行一个任务，并将其作为训练或微调以执行另一个任务的起点转移到另一个模型。这种学习在深度学习中很受欢迎，其中使用预训练模型通过微调或使用预训练模型进行训练来解决计算机视觉或自然语言处理问题。从预训练模型中学习可以提供一个巨大的起点，因为模型不需要从头开始训练，从而节省了大量训练数据。例如，我们可以使用仅包含少量标记数据样本的训练数据来训练一个情感分类器模型。这是通过使用预训练的 BERT 模型（在大量标记数据语料库上训练）进行迁移学习来实现的。这使得将学习从一个模型转移到另一个模型成为可能。

联邦学习

联邦学习是一种以协作方式执行机器学习（云与边缘之间的协同）的方法。训练过程分布在多个设备上，只存储数据的本地样本。数据既不在设备之间也不在设备与云之间交换或传输，以维护数据隐私和安全。不是共享数据，而是共享本地训练的模型，以便相互学习以训练全局模型。让我们讨论一个医院中的联邦学习示例（如图 图 2.6 所示），其中患者数据是保密的，不能与第三方共享。在这种情况下，机器学习训练是在医院（边缘）本地进行的，全局模型是在中心（云上）集中训练的，而不共享数据。本地训练的模型经过微调以产生全局模型。不是在中心机器学习管道中摄取数据，而是摄取本地训练的模型。全局模型通过调整其参数从本地模型中学习，以收敛到最佳性能，连接本地模型的 学习：

图 2.6 – 联邦学习架构

统计模型

在某些情况下，统计模型在做出决策方面非常高效。了解统计模型在何处使用可以获得最佳价值或决策至关重要。统计模型主要有三种类型：归纳学习、演绎学习和迁移学习。图 2.7展示了这些类型之间的相互关系：

图 2.7 – 三种统计模型之间的关系

归纳学习是一种从训练数据中的具体例子进行推广的统计方法，使用这些证据来确定最可能的输出。它涉及通过例子学习的过程，其中系统试图从一组观察到的实例中推广一个通用函数或规则。例如，当我们拟合一个机器学习模型时，这是一个归纳的过程。机器学习模型是对训练数据集中具体例子的推广。例如，在将线性回归模型拟合到训练数据时，通过函数Y = a + bX推广了训练数据中的具体例子。这种推广是在归纳学习中进行的。

演绎学习是指使用通用规则来确定特定结果。演绎学习的输出是确定性和具体的，而归纳推理的结论则是概率性的或概括性的。从某种意义上说，演绎是归纳的反面。如果归纳是从具体到一般，那么演绎就是从一般到具体。

迁移学习是一种基于特定训练数据样本（在训练数据集中）推理结果的方法。这种方法与归纳学习不同，归纳学习是对训练数据进行推广的预测。在迁移学习中，将训练数据中的具体或相似数据样本进行比较，以推理或预测结果。例如，在k最近邻算法的案例中，它使用具体的数据样本来基于其结果，而不是推广结果或使用训练数据进行建模。

HITL 模型

有两种类型的HITL模型：以人为中心的强化学习模型和主动学习模型。在这些模型中，人机协作使算法能够模仿类似人类的行为和结果。这些机器学习解决方案的关键驱动因素是人机交互（因此称为 HITL）。人类验证、标记和重新训练模型以保持模型的准确性：

图 2.8 – 以人为中心的强化学习的工作流程

以人为中心的强化学习是强化学习的一种混合形式，因为它涉及人类在循环中监控代理的学习并提供评估反馈以塑造代理的学习。以人为中心的强化学习也被称为交互式强化学习。每次代理采取行动时，观察的人类专家都可以提供评估反馈，描述代理根据人类专家的知识所采取的选定行动的质量，如图图 2.8所示。

根据从任务环境和人类专家那里收到的反馈，代理增强其行为和行动。在代理必须学习或模仿人类行为的环境中，人类强化学习非常高效。想了解更多信息，请阅读论文以人为中心的强化学习：综述(ieeexplore.ieee.org/abstract/document/8708686)。

主动学习是一种方法，其中训练好的模型在推理过程中可以向 HITL（人类用户）查询，以解决学习过程中的不确定性。例如，这可能是一个问答聊天机器人通过提出是或否的问题来请求人类用户的验证。

这些是在生产中可以构建的 ML 解决方案的类型，以解决现实世界中的问题。现在您已经了解了构建 ML 解决方案的可能性，作为下一步，根据您的业务和技术需求对您的 MLOps 进行分类至关重要。您能够识别出支持您的业务和 MLOps 所需的要求、工具、方法和基础设施非常重要，因此我们将在下一节中探讨 MLOps 的结构。

构建您的 MLOps 结构

MLOps 的主要目标是使组织或一组个人能够高效协作，构建数据驱动和机器学习驱动的资产来解决他们的业务问题。因此，整体性能和透明度得到提升。在孤岛中工作或重复开发功能可能会非常昂贵且耗时。

在本节中，我们将探讨如何在组织中构建 MLOps 的结构。正确实施 MLOps 流程至关重要。通过选择适合您 MLOps 的正确流程和工具，您和您的团队就准备好实施一个强大、可扩展、节俭且可持续的 MLOps 流程。例如，我最近帮助一位来自医疗行业的客户构建和优化他们的 MLOps，这比他们之前传统的运营降低了 76%的成本（针对存储和计算资源）。

客户的数据科学家团队见证了 30%的时间从日常和重复的任务中解放出来（例如，数据整理、机器学习管道和超参数调整）——这可能是高效 MLOps 流程的影响。通过实施高效的 MLOps，您的团队可以确保效率、高性能和出色的协作，这些协作在组织内部是可重复和可追踪的。

MLOps 可以分为小数据操作、大数据操作、大规模 MLOps和混合 MLOps（这种分类基于作者的经验，是团队和组织推荐的方法来处理 MLOps）：

图 2.9 – MLOps 的类别

如图 2.9所示，根据团队规模、机器学习应用、商业模式、数据规模、执行操作所使用的工具和基础设施，组织内的 MLOps 可以大致分为四个不同的类别。在数据方面，许多场景不需要大数据（任何超过 1 TB 的数据）操作，因为简单的操作对于小型或中型数据是有效的。数据规模之间的差异如下：

• 大数据：无法适应单个典型计算机内存的数据量；例如，> 1 TB

• 中型数据：可以适应单个服务器内存的数据量；例如，从 10 GB 到 1 TB

• 小规模数据：可以轻松适应笔记本电脑或 PC 内存的数据量；例如，< 10 GB

考虑到这些因素，让我们来看看 MLOps 类别，以确定适合您业务问题或组织的实施 MLOps 的过程和规模。

小数据操作

一个由数据科学家组成的初创团队，寻求为狭窄和定义明确的问题构建机器学习模型，可以灵活且高度协作。通常，在这种情况下，机器学习模型是在各自的数据科学家计算机上本地训练的，然后被遗忘，或者扩展并部署到云上进行推理。在这些场景中，可能会出现一些一般性的陷阱，例如团队缺乏用于部署模型的简化 CI/CD 方法。然而，他们可能设法拥有由团队精心管理的中心或分布式数据源，并且训练代码可以在中心仓库中进行版本控制和维护。当操作开始扩展时，这样的团队容易遇到以下情况：

• 遇到许多工作被多个人重复进行的情况，包括诸如制作数据、执行相同工作的机器学习管道或训练类似类型的机器学习模型等任务。

• 在孤岛中工作，对队友的并行工作了解最少。这导致透明度较低。

• 由于日常和重复的工作，造成巨大的成本或高于预期的成本。

• 代码和数据开始独立增长。

• 由于未经审计，因此工件不可重复。

任何这些问题都可能对团队造成高昂的成本和不可持续的影响。如果你在一个团队中工作或拥有以下设置，你可以将你的操作归类为小数据操作：

• 团队仅由数据科学家组成。

• 你只使用 Python 环境，并在 Python 框架中管理一切。选择 Python 可能是由于有许多机器学习库和工具可以快速原型设计和构建解决方案。例如，与 Python 相比，Java 等语言的机器学习库数量要少得多。

• 由于数据科学家使用的是小数据（<10 GB），因此几乎不需要大数据处理。

• 快速的机器学习模型开发从本地计算机开始，然后扩展到云端以获取大量的计算资源。

• 对于任何类型的机器学习，从经典学习到深度、监督和无监督学习，开源技术如 PyTorch、TensorFlow 和 scikit-learn 的支持要求很高。

大数据操作

这可能是一个由经验丰富的数据科学家和工程师组成的团队，他们在初创公司或中小企业工作，需要大规模的大数据处理来执行机器学习训练或推理。他们使用如Kafka、Spark或Hadoop等大数据工具来构建和编排他们的数据处理流程。在这种情况下，使用高性能处理器如 GPU 或 TPU 来加速数据处理和机器学习训练。机器学习模型的开发由数据科学家领导，模型的部署由数据/软件工程师编排。在模型开发上给予了强烈的关注，而对模型监控的重要性则相对较低。随着他们继续进行操作，这类团队容易出现以下问题：

• 对于模型训练和监控缺乏可追溯性。

• 缺乏可重复的成果物。

• 由于日常和重复性的工作，产生巨大的成本或超出预期的成本。

• 代码和数据开始独立增长。

任何这些问题都可能对团队造成高昂的成本和不可持续的影响。

如果你在一个团队中工作或拥有以下描述的设置，你可以将你的操作归类为大数据操作：

• 团队由数据科学家/工程师组成。

• 对大数据处理能力的要求很高。

• Databricks 是一个关键的框架，用于团队内部和组织之间的共享和协作。

• 机器学习模型开发通过利用许多机器学习工作流程管理工具之一，如Spark MLlib，在云端进行。

• 对于深度学习等开源技术如 PyTorch 和 TensorFlow 的支持要求较低。

混合 MLOps

混合团队由经验丰富的数据科学家、数据工程师和 DevOps 工程师组成，并利用机器学习能力来支持他们的业务运营。他们在实施 MLOps 方面比其他团队更先进。他们使用大数据和开源软件工具，如 PyTorch、TensorFlow 和 scikit-learn，因此需要高效的协作。他们通常通过实施稳健和可扩展的软件工程实践来解决定义明确的问题。然而，这个团队仍然容易遇到以下挑战：

• 由于数据科学家需要进行的日常和重复性工作，如重复数据清洗或特征工程，导致产生巨大的成本，或超出预期。

• 不高效的模型监控和重新训练机制。

这些操作中的任何一项都可能对团队造成高昂的成本，且不可持续。

如果你在一个团队工作，或者拥有以下所述的设置，你可以将你的操作归类为混合操作：

• 团队由数据科学家、数据工程师和 DevOps 工程师组成。

• 对高效和有效协作的高要求。

• 对大数据处理能力的高要求。

• 对开源技术，如 PyTorch、TensorFlow 和 scikit-learn 的高支持要求，用于任何类型的机器学习，从经典到深度学习，从监督学习到无监督学习。

大规模 MLOps

在大型公司中，大规模操作很常见，这些公司拥有由数据科学家、数据工程师和 DevOps 工程师组成的大型或中型工程团队。他们拥有大数据规模的数据操作，或者在不同规模、真实性和速度上的各种类型的数据。通常，他们的团队需要管理多个遗留系统来支持他们的业务运营。这样的团队或组织容易遇到以下问题：

• 由于日常和重复性工作，导致产生巨大的成本，或超出预期。

• 代码和数据开始独立增长。

• 拥有官僚和高度规范化的流程和质量检查。

• 高度纠缠的系统和处理过程——当一件事情出错时，一切都会出错。

这些操作中的任何一项都可能对团队造成高昂的成本，且不可持续。

如果你在一个团队工作，或者拥有以下所述的设置，你可以将你的操作归类为大规模操作：

• 团队由数据科学家、数据工程师和 DevOps 工程师组成。

• 大规模推理和操作。

• 大数据操作。

• 在多个资源上管理机器学习模型。

• 大型或多个团队。

• 多个用例和模型。

一旦根据你的商业和技术需求对 MLOps 进行了特征化，一个稳固的实施路线图确保了组织开发和管理一个鲁棒且可扩展的 MLOps 解决方案的顺利实施。例如，一个每天处理 0-1,000 笔交易量的金融科技初创公司需要小规模的数据操作，而一个需要大规模 MLOps 的大型金融机构则不同。这种分类使团队或组织更加高效和稳健。

你的解决方案的实施路线图

拥有一个明确的方法和里程碑确保了所需 ML 解决方案（使用 MLOps 方法）的成功交付。在本节中，我们将详细讨论一个通用的实施路线图，该路线图可以促进任何 ML 问题的 MLOps。这个路线图的目标是使用正确的解决方案解决问题：

![Figure 2.10 – Implementation roadmap for an MLOps-based solution]

![img/B16572_02_10.jpg]

图 2.10 – 基于 MLOps 解决方案的实施路线图

使用前面的路线图，我们可以通过这三个阶段清晰地实现 MLOps 的实施，从而从 ML 开发过渡到 MLOps。现在，让我们更详细地看看这个路线图的这三个阶段。值得注意的是，在接下来的理论部分之后，我们将进入路线图的实际实施，并针对一个真实世界的商业用例进行工作。

第一阶段 – ML 开发

这是为你的问题实施 MLOps 框架的起点；在开始实施需求之前，问题和解决方案必须清晰明确。在这个阶段，我们考虑系统需求来设计和实施一个鲁棒且可扩展的 MLOps 框架。我们首先选择实施 MLOps 所需的正确工具和基础设施（存储、计算等）。

当基础设施设置好时，我们应该配备必要的 workspace 和开发及测试环境来执行 ML 实验（训练和测试）。我们使用开发环境训练 ML 模型，并根据工作流程或需求，使用开发或测试环境中的测试数据来测试模型的功能和性能。当基础设施设置好，并且第一个 ML 模型被训练、测试、序列化和打包后，你的 MLOps 框架的第一阶段就设置好了，并且经过了鲁棒性的验证。序列化和容器化是一个重要的过程，用于标准化模型并使其准备好部署。

接下来，我们进入实施第二阶段。

第二阶段 – 转向运营

第二阶段是关于过渡到运营阶段，这包括将第一阶段训练好的模型进行序列化和容器化，并使其准备好部署。这可以实现标准化、高效的部署。模型以 API 或独立工件的形式提供批量推理服务。当一个模型打包并准备好提供服务时，它将通过经过质量保证检查的简化 CI/CD 管道在生产环境中部署。到第二阶段结束时，你将拥有打包好的模型，这些模型在生产环境中实时执行推理并部署。

第三阶段 – 运营

第三阶段是第二阶段部署模型的运营核心阶段。在这个阶段，我们根据模型漂移、偏差或其他指标（我们将在接下来的章节中深入探讨这些术语和指标）来监控部署模型的性能。根据模型的表现，我们可以通过定期重新训练模型来实现持续学习，并启用警报和操作。同时，我们监控生产环境的遥测数据中的日志，以检测任何可能的错误，并即时解决它们，以确保生产系统的连续运行。我们还即时管理数据管道、机器学习平台和安全。通过成功实施这一阶段，我们可以以健壮、可扩展和安全的 manner 监控部署的模型并重新训练它们。

在大多数情况下，需要实现所有三个阶段以支持你的机器学习解决方案，但在某些情况下，仅第一阶段和第二阶段就足够了；例如，当机器学习模型进行批量推理且不需要实时推理时。通过实现这些里程碑并实施所有三个阶段，我们系统地、可持续地建立了一个健壮且可扩展的机器学习生命周期。

获取数据、需求和工具

实施成功的 MLOps 取决于某些因素，例如获取适当的训练数据，并拥有高标准、适当的需求、工具和基础设施。

在本节中，我们将深入探讨这些使 MLOps 健壮和可扩展的因素。

数据

我曾经认为，了解数据意味着掌握 Python、SQL 和回归等工具。工具的好坏取决于使用它的人及其对周围环境的理解。环境和领域很重要，从数据清洗到建模到解释。世界上最好的工具也无法修复一个糟糕的问题定义（或缺乏定义）。知道要解决什么问题是一个非常具体和业务依赖的决定。一旦你意识到问题和环境，它就能帮助你辨别解决问题所需的正确训练数据。

训练数据是机器学习系统的重要组成部分。与传统的软件系统相比，它在开发机器学习系统中起着至关重要的作用。正如我们在上一章中看到的，代码和训练数据并行工作以开发和维护机器学习系统。这不仅仅是关于算法，也是关于数据。有两个方面可以确保你有适合算法训练的正确数据，即提供正确数量和质量的数据：

• 数据数量：数据科学家们对他们的模型提出了一个常见的论点，即模型性能不佳是因为他们得到的数据量不足以产生良好的模型性能。如果他们有更多的数据，性能会更好——你熟悉这样的论点吗？在大多数情况下，更多的数据可能真的不会有所帮助，因为质量也是一个重要因素。例如，如果你为每个类别有更多的样本，你的模型可以从你的数据中学习到更多的见解和特征。例如，如果你分析数据中的许多样本的异常金融交易，你将发现更多类型的异常交易。如果只有一个异常案例，那么机器学习就不再有用。

  机器学习项目的数据需求不应仅仅关注数据数量本身，而应同时关注数据质量，这意味着关注点不应在于数据样本的数量，而应在于数据样本的多样性。然而，在某些情况下，由于某些问题的数据可用性受到限制，数据数量上可能存在约束。例如，假设我们正在为一家保险公司预测客户流失率的工作模型。在这种情况下，由于数据在一定时间段内的可用性，我们可能只能考虑有限时间段内的数据或使用有限数量的样本；例如，5 年（而保险公司可能已经运营了 50 年）。目标是获取尽可能多和高质量的数据来训练表现最佳的机器学习模型。

• 数据质量：数据质量是训练机器学习模型的重要因素；它影响模型性能。数据的全面性或质量越高，机器学习模型或应用的表现就越好。因此，在训练之前的过程很重要：数据清洗、增强和缩放。需要考虑一些重要的数据质量维度，例如一致性、正确性和完整性。

  数据一致性指的是数据样本在整个数据集中的对应性和连贯性。数据正确性是指数据的准确性以及你可以依赖数据真实反映事件的程度。数据正确性取决于数据是如何收集的。每个特征的数据稀疏性（例如，数据是否覆盖了反映事件的可能值的全面范围）反映了数据的完整性。

  在拥有适当数量高质量数据的情况下，您可以确信您的机器学习模型和应用将超出所需标准的表现。因此，拥有正确的标准对于应用以最有效的方式执行和解决业务问题至关重要。

需求

产品或业务/技术问题所有者通过识别需求并根据数据范围、数据收集和所需数据格式进行定制，在高效构建健壮的机器学习系统方面发挥着关键作用。这些需求对于机器学习系统的开发者，如数据科学家或机器学习工程师，来说是至关重要的输入，他们可以根据需求分析并关联给定的数据集来开始设计解决方案以解决问题。机器学习解决方案的需求应包括全面的数据需求。数据需求规范包括有关数据质量和数量的信息。需求可以更广泛；例如，它们可以包含关于预期或预期预测性能的估计，这些性能指标是在需求分析和收集过程中确定的。

可以制定细致的规范，例如，对训练数据上预期或预期的性能进行规范，因为这些规范可以在模型训练过程之后迅速得到验证。而基于训练性能，推理或运行时（包括在生产环境和运营中）的性能可以在运营期间进行评估。产品所有者或业务所有者提出的需求应考虑重要因素，如伦理和可解释性因素。歧视或偏见（如预测或分类的对象）对于应用至关重要，以及哪些属性应作为数据隐私的一部分被保留（例如，某些属性不应用于预测或分类，如种族、年龄或性别）。必须明确考虑可解释性需求，以向系统用户解释机器学习解决方案或系统的情境和决策。最后，需求必须规定有关数据使用和验证机器学习系统做出的决策的法规和限制。以下表格显示了确保您构建一个健壮且可扩展的机器学习解决方案需要考虑的一些需求：

图 2.11 – 机器学习解决方案的需求映射

图 2.11中的表格说明了需求特征化过程的流程，从收集到分析，再到规范，以及系统的验证和验证。这个过程确保获取最佳资源来构建和部署高效的机器学习系统以解决您的问题。当需求定义良好时，选择支持既定流程并确保满足标准的正确工具和基础设施至关重要。

工具和基础设施

过去两年中，MLOps 领域发展迅速；许多工具和框架作为基础设施提供的一部分得到了发展。您可以访问landscape.lfai.foundation/查看已经开发了多少主流选项来编排机器学习、深度学习、强化学习、开发环境、数据管道、模型管理、可解释人工智能、安全和分布式计算。

流行云服务提供商如微软、AWS 和谷歌提供的服务激增，这些服务由 Airflow、Databricks 和 Data Lake 等数据处理工具补充。这些工具旨在使机器学习和深度学习成为可能，为此，有许多优秀的框架可用，如 scikit-learn、Spark MLlib、PyTorch、TensorFlow、MXNet 和 CNTK 等。工具和框架众多，但获取正确的工具是选择的问题，以及你的 ML 解决方案和操作设置的环境。拥有正确的工具将确保你的 MLOps 工作流程具有高效率和自动化。选项很多，天高任鸟飞，但我们必须从某个地方开始，才能达到天空的高度。因此，我们将从现在开始为您提供一些实际操作经验。从现实生活中的问题中学习总是更好的，我们将通过使用下一节中描述的现实生活中的商业问题来实现这一点。

讨论现实生活中的商业问题

我们将实施以下商业问题以获得实际操作经验。我建议您多次阅读本节，以便更好地理解商业问题；这有助于更容易地实现它。

重要提示

问题背景：

你在芬兰图尔库港口的一家货运公司的小团队中担任数据科学家，与另外三名数据科学家一起工作。90%的进入芬兰的商品都是通过全国各港口的货轮运输的。对于货运来说，港口的天气条件和物流有时可能会很具挑战性。雨天可能会扭曲港口的操作和物流，从而影响供应链操作。提前预测雨天条件为优化港口供应链操作的人力资源、物流和运输资源提供了可能性。从商业角度来看，提前预测雨天条件可以使港口通过有效规划和调度人力资源、物流和运输资源来降低运营成本，最多可达 20%。

任务：

作为数据科学家，你被分配开发一个 ML 驱动的解决方案，以提前 4 小时预测芬兰图尔库港的天气状况。这将使港口能够优化其资源，从而实现高达 20%的成本节约。为了开始，你将获得一个覆盖 10 年时间的图尔库港历史天气数据集（数据集将在下一章中提供）。你的任务是构建一个持续学习驱动的 ML 解决方案，以优化图尔库港的运营。

为了解决这个问题，我们将使用微软 Azure，这是最广泛使用的云服务之一，以及开源 ML 开发工具 MLflow，以亲身体验使用资源。这样，我们将获得在云上和开源软件上工作的经验。在下一章开始动手实施之前，请确保完成以下操作：

1. 从azure.microsoft.com/（仅需 5 分钟）创建一个免费的 Azure 订阅。

2. 创建一个名为MLOps_WS的 Azure 机器学习服务应用。这可以通过点击 Azure 门户中的搜索字段中的Machine Learning并选择MLOps_WS来完成。

现在，有了这些，你们都准备好动手实现一个针对先前商业问题的 MLOps 框架了。

摘要

在本章中，我们学习了 ML 解决方案的开发过程，如何识别适合问题的 ML 解决方案，以及如何对操作进行分类以实现合适的 MLOps。我们了解了一般的实施路线图，并看到了一些获取基本要素（如工具、数据和基础设施）以实现您的 ML 应用的技巧。最后，我们通过实施 MLOps 工作流程（在第第一章，MLOps 工作流程基础)来了解下一章要解决的商业问题，这将让我们在 MLOps 中获得一些实践经验。

在下一章中，我们将从理论转向实际实施。当我们开始设置 Azure 上的 MLOps 工具并开始编写代码来清理数据以解决商业问题并获得大量实践经验时，这一章将变得实用。

第三章：代码遇见数据

在本章中，我们将通过解决一个业务问题来开始动手实践MLOps的实施，我们将在前一章讨论的 MLOps 工作流程中学习。我们还将讨论机器学习（ML）的源代码管理有效方法，探索数据质量特性，并分析和塑造数据以适应 ML 解决方案。

我们从对业务问题进行分类开始，以编制最适合的 MLOps 解决方案。在此之后，我们将设置实施解决方案所需的资源和工具。讨论了 10 个关于 ML 源代码管理的指导原则，以应用干净的代码实践。我们将讨论构成 ML 高质量数据的内容，以及更多内容，然后处理与业务问题相关的数据集，并将其摄入和版本控制到 ML 工作区。本章的大部分内容都是实践性的，旨在让你对 MLOps 有一个良好的理解和经验。为此，我们将在本章中涵盖以下主要主题：

• 业务问题分析和问题分类

• 设置资源和工具

• 机器学习源代码管理的 10 个原则

• 适合机器学习的好数据

• 数据预处理

• 数据注册和版本控制

• 向 ML 管道迈进

不再拖延，让我们直接进入揭秘业务问题并使用 MLOps 方法实施解决方案。

业务问题分析和问题分类

在前一章中，我们研究了以下业务问题陈述。在本节中，我们将通过使用原则对问题进行分类，以编制实施路线图来揭秘问题陈述。我们将快速查看我们用于解决业务问题的数据集，并决定哪种 ML 模型能够高效地解决业务问题。最后，我们将对实施稳健和可扩展的 ML 操作进行分类，并决定实施所需的工具。

这是问题陈述：

你作为数据科学家，在一个位于芬兰的货运公司的小型数据科学家团队中工作。90%的货物通过货运进入芬兰。你被分配的任务是在芬兰图尔库港的货运操作中节省 20%的成本。这可以通过开发一个预测港口 4 小时后天气状况的 ML 解决方案来实现。你需要监测可能出现的雨天，这可能会因为人力资源和交通而扭曲港口的运营，进而影响港口的供应链运营。你的 ML 解决方案将帮助港口当局提前 4 小时预测可能的降雨；这将节省 20%的成本，并使港口的供应链运营更加顺畅。

解决问题的第一步是使用适当的方法对其进行简化和分类。在前一章中，我们讨论了如何将商业问题分类以使用机器学习来解决它。现在，让我们将这些原则应用到制定其实施的清晰路线图。

首先，我们将查看我们将训练哪种类型的模型以产生最大的商业价值。其次，我们将确定我们 MLOps 实现的正确方法。

为了决定要训练的模型类型，我们可以先浏览 GitHub 上可用的数据集：github.com/PacktPublishing/EngineeringMLOps。

在 图 3.1 中，这是一个 weather_dataset_raw.csv 数据集的快照。文件大小为 10.7 MB，行数为 96,453，文件格式为 CSV：

图 3.1 – 数据集快照

通过评估数据，我们可以将商业问题分类如下：

• 天气状况 列描述了一个事件是否记录了雨、雪或晴朗的条件。这可以被框架化或重新标记为 rain 或 no rain 并用于执行二元分类。因此，使用监督学习方法解决商业问题很简单。

• MLOps 方法：通过观察问题陈述和数据，以下是事实：

  (a) 数据：训练数据大小为 10.7 MB。数据量相对较小（不能算作大数据）。

  (b) 操作：我们需要训练、测试、部署和监控一个机器学习模型，以预测图尔库港每小时的天气情况（新数据记录时提前 4 小时）。

  (c) 团队规模：一个小/中型数据科学家团队，没有 DevOps 工程师。

根据上述事实，我们可以将操作分类为 小型团队操作；不需要大数据处理，团队规模小且敏捷。现在，我们将探讨一些适合的工具来实施解决当前业务问题所需的操作。

为了让我们对 MLOps 实施有一个全面的理解，我们将同时使用两种不同的工具来实施业务问题：

• Azure Machine Learning（微软 Azure）

• MLflow（一个开源的云和平台无关的工具）

我们使用这两个工具来查看纯基于云的方法和开源/云无关的方法是如何工作的。所有代码和 CI/CD 操作都将使用 Azure DevOps 进行管理和编排，如图 图 3.2 所示：

图 3.2 – 解决方案中的 MLOps 工具

现在，我们将设置实施商业问题解决方案所需的工具和资源。由于我们将使用 Python 作为主要的编程语言，因此需要在您的 Mac、Linux 或 Windows 操作系统中安装 Python 3。

设置资源和工具

如果你已经在你的 PC 上安装并设置了这些工具，请随意跳过此部分；否则，请按照详细的说明来启动它们。

安装 MLflow

我们首先安装 MLflow，它是一个开源平台，用于管理 ML 生命周期，包括实验、可重复性、部署和中央模型注册。

要安装 MLflow，请转到你的终端并执行以下命令：

pip3 install mlflow

安装成功后，通过执行以下命令来测试安装，以启动mlflow跟踪 UI：

mlflow ui

运行mlflow跟踪 UI 时，你将在你的机器上运行一个监听端口5000的服务器，并输出如下信息：

[2021-03-11 14:34:23 +0200] [43819] [INFO] Starting gunicorn 20.0.4
[2021-03-11 14:34:23 +0200] [43819] [INFO] Listening at: http://127.0.0.1:5000 (43819)
[2021-03-11 14:34:23 +0200] [43819] [INFO] Using worker: sync
[2021-03-11 14:34:23 +0200] [43821] [INFO] Booting worker with pid: 43821

你可以在http://localhost:5000访问和查看mlflow UI。当你成功安装mlflow并运行跟踪 UI 时，你就可以安装下一个工具了。

Azure 机器学习

Azure 机器学习提供了一个基于云的 ML 平台，用于训练、部署和管理 ML 模型。此服务可在 Microsoft Azure 上使用，因此先决条件是拥有一个 Microsoft Azure 的免费订阅。请创建一个大约有 170 美元信用额的免费账户，这足以实现解决方案，请在此处创建：azure.microsoft.com/。

当你拥有 Azure 的访问/订阅时，继续下一部分以启动 Azure 机器学习。

创建资源组

资源组是一组与 Azure 解决方案相关的相关资源的集合。它是一个容器，将所有与某个服务或解决方案相关的资源捆绑在一起。创建资源组可以方便地访问和管理解决方案。让我们从创建自己的资源组开始：

1. 打开 Azure 门户。

2. 访问门户菜单（如果你默认不在主页上，请转到门户的主页），将鼠标悬停在导航部分中的资源组图标上。将出现一个创建按钮；点击它以创建一个新的资源组：![图 3.3 – 创建资源组

   ![img/B16572_03_03.jpg]

   图 3.3 – 创建资源组

3. 创建一个名为你选择的资源组（推荐使用Learn_MLOps），如图 3.3 所示。

4. 选择一个靠近你的区域以获得最佳性能和定价。例如，在图 3.3 中，一个名为Learn MLOps且区域为（欧洲）北欧的资源组已准备好创建。在点击审查 + 创建按钮并 Azure 验证请求后，将出现最终的创建按钮。应该按下最终的创建按钮来创建新的资源组。

当资源组经过审查并创建后，你可以在该资源组中设置和管理所有与 ML 解决方案相关的服务。新创建的资源组将列在资源组列表中。

创建 Azure 机器学习工作区

ML 工作区是跟踪和管理您的 ML 训练、部署和监控实验的中心枢纽。要创建 Azure Machine Learning 工作区，请转到 Azure 门户菜单，点击 Machine Learning 并选择它。您将看到以下屏幕：

图 3.4 – 创建 Azure Machine Learning 工作区

使用您选择的名称命名工作区（例如，我们在 图 3.4 中将其命名为 MLOps_WS）。选择您之前创建的资源组以将此 ML 服务与其关联（图 3.4 中选择的是 Learn_MLOps）。最后，点击 Review + create 按钮，您将被带到一个新的屏幕，其中包含最终的 Create 按钮。按下最终的 Create 按钮以创建您的 Azure Machine Learning 工作区。

创建 Azure Machine Learning 工作区（Learn_MLOps）后，Azure 平台将部署此服务所需的所有资源。与 Azure Machine Learning 实例（Learn_MLOps）一起部署的资源，如 Blob 存储、密钥保管库和应用洞察，将配置并关联到工作区。这些资源将通过工作区和 SDK 进行消耗或使用。

您可以在以下位置找到创建 Azure Machine Learning 实例的详细说明：docs.microsoft.com/en-us/azure/machine-learning/how-to-manage-workspace。

安装 Azure Machine Learning SDK

在您的 PC 的终端或命令行中，安装 Azure Machine Learning SDK，该 SDK 将在代码中广泛用于编排实验。要安装它，请运行以下命令：

pip3 install --upgrade azureml-sdk

您可以在以下位置找到详细说明：docs.microsoft.com/en-us/python/api/overview/azure/ml/install?view=azure-ml-py。

Azure DevOps

所有源代码和 CI/CD 相关的操作都将通过 Azure DevOps 进行管理和编排。我们在 Azure DevOps 仓库中管理的代码将用于通过 CI/CD 管道训练、部署和监控 ML 模型。让我们先创建一个 Azure DevOps 订阅：

1. 在 dev.azure.com 上创建一个免费账户。您可以使用现有的 Microsoft 或 GitHub 账户创建一个免费账户。

2. 创建一个名为 Learn_MLOps 的项目（根据您的偏好将其设置为公开或私有）。

3. 转到 repos 部分。在 Import a repository 部分中，点击 Import 按钮。

4. 从此仓库导入公共 GitHub 项目的仓库：github.com/PacktPublishing/EngineeringMLOps（如 图 3.5 所示）：

图 3.5 – 将 GitHub 仓库导入到 Azure DevOps 项目中

导入 GitHub 仓库后，将显示导入仓库的文件。

JupyterHub

最后，我们需要一个交互式数据分析和可视化工具来使用我们的代码处理数据。为此，我们使用JupyterHub。这是一个常用的数据科学工具，被数据科学家广泛用于处理数据、可视化数据和训练机器学习模型。要安装它，请遵循以下两个简单步骤：

1. 在您的 PC 上通过命令行安装 JupyterHub：

   python3 -m pip install jupyterhub
   

   您可以在此处找到详细说明：jupyterhub.readthedocs.io/en/stable/quickstart.html。

2. 安装 Anaconda。

   Anaconda 是必需的，因为它安装依赖项、设置环境和支持 JupyterHub 的服务。根据以下详细说明下载并安装 Anaconda：docs.anaconda.com/anaconda/install/。

   现在我们已经为动手实现做好了准备，让我们看看管理良好代码和数据需要什么。

机器学习源代码管理的 10 个原则

这里有一些原则可以应用于你的代码，以确保代码的质量、健壮性和可扩展性：

• 模块化：拥有模块化代码比拥有一个大块代码更好。模块化鼓励重用并便于通过替换所需组件进行升级。为了避免不必要的复杂性和重复，请遵循以下黄金法则：

  两个或多个机器学习组件只有在其中一个使用另一个时才应配对。如果它们都不使用对方，则应避免配对。

  与其环境紧密配对的机器学习组件比紧密配对的组件更容易修改或替换。

• 单一任务专用函数：函数是管道和系统的基本构建块，它们是用于执行特定任务的代码小段。函数的目的是避免命令重复并使代码可重用。它们可以很容易地变成一组复杂的命令以方便任务。为了使代码可读和可重用，最好有一个专门用于单一任务的函数，而不是多个任务。拥有多个函数比一个长而复杂的函数更好。

• 错误 300。对代码块进行结构化并尝试限制函数和类的最大缩进级别可以提高代码的可读性。

• 清洁代码：如果你必须解释代码，那么它就不是很好。清洁代码是自我解释的。它侧重于高可读性、最佳模块化、可重用性、非重复性和最佳性能。清洁代码降低了维护和升级你的机器学习管道的成本。它使团队能够高效地工作，并且可以扩展到其他开发者。

  要深入了解这一点，请阅读罗伯特·马丁的《Clean Code: A Handbook of Agile Software Craftsmanship》。

• 测试： 确保系统的健壮性至关重要，而测试在这一过程中发挥着重要作用。一般来说，测试包括单元测试和验收测试。单元测试是一种通过强制数据和使用方法测试源代码组件的健壮性的方法，以确定该组件是否适合生产系统。验收测试是为了测试整个系统，以确保系统实现了用户需求；在实时场景中验证端到端业务流程。测试对于确保代码的高效运行至关重要：“如果未经测试，它就是有缺陷的。”

要了解更多关于单元测试实现的信息，请阅读此文档：docs.python.org/3/library/unittest.html。

• 版本控制（代码、数据和模型）： 在机器学习系统中，Git 用于代码的版本控制。版本控制的目的确保所有参与系统开发的团队成员都能访问最新的代码，并且在硬件故障时代码不会丢失。与 Git 一起工作的一个规则应该是不要破坏主分支（分支）。这意味着当你有一个在仓库中的工作代码，并且添加新功能或进行改进时，你应该在一个功能分支中这样做，当代码工作并且经过审查后，将其合并到主分支。分支应该有一个简短且描述性的名称，例如 feature/label-encoder。分支命名和审批指南应该与团队进行适当的沟通和同意，以避免任何复杂性和不必要的冲突。代码审查是通过向代码仓库提交拉取请求来完成的。通常，最好以小于 400 行的代码块进行审查。在实践中，这通常意味着一次一个模块或子模块。

  数据版本化对于机器学习系统至关重要，因为它帮助我们追踪特定版本的代码所使用的数据。数据版本化可以使得模型的可复现性以及满足商业需求和法律法规成为可能。我们可以随时回溯并查看机器学习系统采取某些行动的原因。同样，模型（工件）的版本化对于追踪哪个版本的模型生成了机器学习系统的特定结果或行动也很重要。我们还可以追踪或记录用于训练模型特定版本的参数。这样，我们可以实现模型工件、数据和代码的端到端可追溯性。代码、数据和模型的版本控制可以增强机器学习系统的透明度和效率，这对于开发和维护它的人来说是非常有益的。

• print语句对于测试和调试很有用，但不适合生产环境。日志记录器包含的信息，尤其是系统信息、警告和错误，对于监控生产系统非常有用。

• 错误处理：错误处理对于处理边缘情况至关重要，特别是那些难以预测的情况。即使你认为不需要，也建议捕获和处理异常，因为预防胜于治疗。将日志记录与异常处理结合起来可以是一种处理边缘情况的有效方法。

• 可读性：代码可读性有助于信息传递、代码效率和代码可维护性。可以通过遵循行业标准的编码实践，如 PEP-8 (www.python.org/dev/peps/pep-0008/) 或 JavaScript 标准风格（取决于你使用的语言）来实现。使用文档字符串也可以提高可读性。文档字符串是在例如函数开头编写的文本，描述它做什么以及可能需要什么输入。在某些情况下，一行解释就足够了，例如：

  def swap(a,b):
  """Swaps the variables a and b. Returns the swapped variables""" 
  return b, a
  

  对于更复杂的函数，需要更长的文档字符串。解释参数和返回值是一个好主意：

  def function_with_types_in_docstring(param1, param2): """Example function with types documented in the docstring.
  `PEP 484`_ type annotations are supported. If attribute, parameter, and
  return types are annotated according to `PEP 484`_, they do not need to be
  included in the docstring:
  Args:
      param1 (int): The first parameter. 
      param2 (str): The second parameter.
  Returns:
       bool: The return value. True for success, False otherwise.
                                """
  

注释和文档化：注释和文档对于维护可持续的代码至关重要。并非总是能够清晰地解释代码。在这种情况下，注释可以有用，以防止混淆并解释代码。注释可以传达诸如版权信息、意图、代码澄清、可能的警告和代码详细说明等信息。对系统和模块的详细文档可以使团队高效地工作，并且代码和资产可以扩展给其他开发者。对于文档，有开源工具可用于文档化 API，例如 Swagger (swagger.io) 和 Read the Docs (readthedocs.org)。使用正确的工具进行文档化可以提高效率并标准化开发者的知识。

什么是有用的机器学习数据？

良好的机器学习模型是训练在高质量数据上的结果。在进行机器学习训练之前，一个先决条件是拥有高质量的数据。因此，我们需要处理数据以提高其质量。所以，确定数据的质量是至关重要的。以下五个特征将使我们能够辨别数据的质量：

• 准确性：准确性是数据质量的关键特征，因为不准确的数据可能导致机器学习模型性能不佳，并在现实生活中产生后果。为了检查数据的准确性，确认信息是否代表现实生活中的情况。

• 完整性：在大多数情况下，不完整的信息是不可用的，如果机器学习模型基于它进行训练，可能会导致错误的输出。检查数据的完整性至关重要。

• 可靠性：数据中的矛盾或重复可能导致数据不可靠。可靠性是一个关键特性；信任数据至关重要，尤其是在使用机器学习做出现实生活中的决策时。在一定程度上，我们可以通过检查偏差和分布来评估数据的可靠性。在任何极端情况下，数据可能不适合用于机器学习训练，或者可能携带偏差。

• 相关性：数据的相关性在确定是否收集了不相关信息以及进行上下文化中起着至关重要的作用。拥有相关数据可以使得在现实生活场景中使用机器学习做出适当的决策。

• 及时性：过时或陈旧的信息会耗费企业的时间和金钱；在某些情况下，拥有最新信息至关重要，并且可以提高数据质量。使用过时数据通过机器学习做出的决策可能代价高昂，并可能导致错误决策。

当这五个特性最大化时，将确保数据质量达到最高。带着这些原则，让我们深入到实现中，即代码与数据的结合。

首先，让我们评估数据并对其进行处理，以便为机器学习训练做好准备。要开始，请将您导入的存储库克隆到您的 Azure DevOps 项目中（从 GitHub）：

git clone https://xxxxxxxxx@dev.azure.com/xxxxx/Learn_MLOps/_git/Learn_MLOps

接下来，打开您的终端，访问克隆存储库的文件夹，并启动用于数据处理的 JupyterLab 服务器。为此，请在终端中输入以下命令：

jupyter lab

这将自动在您的浏览器中打开一个窗口，地址为 http://localhost:8888，您可以在其中使用 JupyterLab 界面进行编码和执行代码。在 Code_meets_data_c3 文件夹中，有一个 Python 脚本 (dataprocessing.py) 和一个 .ipynb 笔记本 (dataprocessing.ipynb)；您可以随意运行这些文件中的任何一个，或者创建一个新的笔记本，并按照接下来的步骤操作。

我们将执行如图 3.6 所述的任务的计算。数据处理将在您的 PC 上进行，随后在云中的计算目标上进行机器学习训练、部署和监控。这是为了获得在多种设置中实现模型的经验。在本章的剩余部分，我们将进行数据处理（本地），以便将数据质量提升到最佳，以便进行机器学习训练（在下一章中描述的云中进行）。

![图 3.6 – 数据和机器学习任务的计算位置]

![img/B16572_03_06.jpg]

图 3.6 – 数据和机器学习任务的计算位置

为了处理原始数据并将其准备好用于机器学习，您将在您的本地 PC 上进行计算和数据处理。我们首先安装和导入所需的包，并导入原始数据集（如 dataprocessing.ipynb 和 .py 脚本中所示）。笔记本中的 Python 指令必须在现有的笔记本中执行：

%matplotlib inline
import pandas as pd
import numpy as np
from matplotlib import pyplot as plt
from matplotlib.pyplot import figure
import seaborn as sns
from azureml.core import Workspace, Dataset
#import dataset
df = pd.read_csv('Dataset/weather_dataset_raw.csv')

通过这种方式，您已经将数据集导入了一个 pandas DataFrame，名为 df，以便进行进一步的处理。

数据预处理

原始数据不能直接用于训练机器学习模型。在训练机器学习模型之前，我们必须对数据进行精炼或预处理。为了进一步分析导入的数据，我们将执行一系列步骤，将数据预处理成适合机器学习训练的形状。我们首先评估数据的质量，以检查准确性、完整性、可靠性、相关性和时效性。在此之后，我们将校准所需数据并将文本编码为数值数据，这对于机器学习训练是理想的。最后，我们将分析相关性和时间序列，并过滤掉与训练机器学习模型无关的数据。

数据质量评估

为了评估数据的质量，我们寻找准确性、完整性、可靠性、相关性和时效性。首先，让我们检查数据是否完整和可靠，通过评估格式、累积统计和异常，如缺失数据。我们使用以下 pandas 函数：

df.describe()

通过使用 describe 函数，我们可以在输出中观察到以下描述性统计：

图 3.7 – DataFrame 的描述性统计

可以进行一些观察，以得出数据是一致的、相关的结论，因为它描述了现实生活中的统计数据，如平均温度约为 ~11 摄氏度和风速约为 ~10 公里/小时。芬兰的最低温度通常达到约 ~-21 摄氏度，平均能见度为 10 公里。这样的事实描述了数据的关联性和数据来源条件。现在，让我们观察列格式：

df.dtypes

这里是每列的格式：

• S_No                                           int64

• Timestamp                                object

• Location                                     object

• Temperature_C                         float64

• Apparent_Temperature_C      float64

• Humidity                                    float64

• Wind_speed_kmph                  float64

• Wind_bearing_degrees           int64

• Visibility_km                              float64

• Pressure_millibars                    float64

• Weather_conditions                object

• dtype:                                         object

大多数列都是数值型（float 和 int），正如预期的那样。Timestamp 列是 object 格式，需要将其更改为 DateTime 格式：

df['Timestamp'] = pd.to_datetime(df['Timestamp'])

使用 pandas 的 to_datetime 函数，我们将 Timestamp 转换为 DateTime 格式。接下来，让我们看看是否存在任何空值。我们使用 pandas 的 isnull 函数来检查这一点：

df.isnull().values.any()

在检查任何空值后，如果发现空值，则作为下一步，校准缺失数据至关重要。

校准缺失数据

数据中存在缺失值并不理想，因为这表明数据质量较差。可以使用各种技术来替换缺失数据或值，而不会影响数据的正确性和可靠性。在检查我们所工作的数据后，我们发现了一些缺失值。我们使用前向填充方法来处理缺失数据：

df['Weather_conditions'].fillna(method='ffill', inplace=True, axis=0)

NaN或空值仅在Weather_conditions列中观察到。我们使用 pandas 的fillna()方法和前向填充（ffill）方法来替换NaN值。由于天气是渐进的，数据中可能会复制上一个事件。因此，我们使用前向填充方法，该方法复制最后一个观察到的非空值，直到遇到另一个非空值。

标签编码

由于机器不理解人类语言或文本，所有文本都必须转换为数字。在那之前，让我们处理文本。我们有一个包含文本值或标签的Weather_conditions列，例如rain、snow和clear。这些值是通过 pandas 的value_counts()函数找到的，如下所示：

df['Weather_conditions'].value_counts()

Weather_conditions可以通过将列标签分类为两个标签rain或no_rain来简化。在这两个类别中进行预测将使我们能够解决货运公司的业务问题：

df['Weather_conditions'].replace({"snow": "no_rain",  "clear": "no_rain"}, inplace=True)

这将用no_rain替换snow和clear值，因为这两种条件都意味着港口没有降雨。现在标签已经处理完毕，我们可以使用rain和no_rain将Weather_conditions列转换为机器可读的形式或数字。标签编码可以很有效，因为它将这些值转换为 0 和 1。如果有超过两个值，独热编码是一个不错的选择，因为将增量数字分配给分类变量可以在训练期间赋予变量更高的优先级或数值偏差。独热编码防止对任何变量的偏差或更高的偏好，确保对分类变量的每个值都给予中立的特权。在我们的案例中，因为我们只有两个分类变量，所以我们使用 scikit-learn 执行标签编码，如下所示：

from sklearn.preprocessing import LabelEncoder
le = LabelEncoder()
y = df['Weather_conditions']
y = le.fit_transform(y)

在这里，我们导入LabelEncoder()函数，该函数将使用fit_transform()方法将Weather_conditions列编码为 0 和 1。我们可以通过以下方式用标签编码或机器可读的形式替换之前的文本列到Weather_condition列：

y = pd.DataFrame(data=y, columns=["Weather_condition"])
df = pd.concat([df,y], axis=1)
df.drop(['Weather_conditions'], axis=1, inplace=True)

在这里，我们将我们的新标签编码或机器可读的Weather_condition列连接到 DataFrame 中，并删除之前的非机器可读或文本形式的Weather_conditions列。数据现在以机器可读的形式存在，并准备好进行进一步处理。您可以在笔记本中执行df.head()来检查转换后的数据（可选）。

新功能 – 未来天气状况

我们的任务是预测 4 小时后的天气状况，因此我们通过将Current_weather_condition向右移动四行来创建一个名为Future_weather_condition的新特征，因为每一行记录的时间间隔为一个小时。Future_weather_condition是 4 小时后未来天气状况的标签。我们将使用这个新特征作为依赖变量，使用机器学习进行预测：

df['Future_weather_condition'] = df.Current_weather_condition.shift(4, axis = 0) 
df.dropna(inplace=True)

我们将在 DataFrame 上使用 pandas 的dropna()函数来丢弃或删除空值，因为一些行由于移动到新列而会有空值。

数据相关性和过滤

现在数据已经完全机器可读，我们可以使用皮尔逊相关系数来观察每一列与其他列之间的关系。在机器学习模型训练之前，数据与特征的相关性分析是特征选择的重要步骤，尤其是在特征是连续的，如我们案例中那样。皮尔逊相关系数是每个变量（X和y）之间的统计线性相关，产生一个介于+1和-1之间的值。+1表示正线性相关，-1表示负线性相关，而0表示没有线性相关。它可以用来理解连续变量之间的关系，但值得注意的是，皮尔逊相关系数并不意味着因果关系。我们可以使用 pandas 来观察我们数据中的皮尔逊相关系数，如下所示：

df.corr(method="pearson")
# Visualizing using heatmap
corrMatrix = df.corr()
sn.heatmap(corrMatrix, annot=True)
plt.show()

这是Pearson相关系数热图：

图 3.8 – 相关系数热图

从图 3.8中的热图中，我们可以看到Temperature和Apparent_Temperature_C的系数为0.99。S_No（序列号）是一个连续值，它大致相当于 DataFrame 的增量索引，可以丢弃或过滤掉，因为它并不提供很大的价值。因此，Apparent_Temperature和S_No都被丢弃或过滤掉了。现在让我们观察我们的依赖变量Future_weather_condition及其与其他自变量之间的相关性：

图 3.9 – Future_weather_condition的皮尔逊相关系数

任何介于 0.5 和 1.0 之间的值都有正相关，任何介于-0.5 和-1.0 之间的值都有负相关。从图中可以看出，与Current_weather_condition有正相关，Temperature_C也与Future_weather_c正相关。

时间序列分析

由于温度是一个连续变量，观察其随时间的变化趋势是很有意义的。我们可以使用 matplotlib 可视化时间序列图，如下所示：

time = df['Timestamp]
temp = df['Temperature_C']
# plot graph
plt.plot(time, temp)
plt.show()

这是生成的图表：

图 3.10 – 温度随时间的变化趋势图

在评估 3.10 图中温度的时间序列进展后，我们可以看到它描绘了一个平稳模式，因为均值、方差和协方差在时间上观察到是平稳的。平稳行为可以是趋势、周期、随机游走或这三种的结合。这是有意义的，因为温度随季节变化并遵循季节性模式。这使我们到达数据分析和处理阶段的尾声；我们现在准备好在训练机器学习模型之前将处理后的数据注册到工作区。

数据注册和版本控制

在开始机器学习训练之前，注册和版本控制工作区中的数据至关重要，因为它使我们能够回溯我们的实验或机器学习模型到用于训练模型的数据源。版本化数据的目的是在任何时间点回溯，以复制模型的训练，或根据推理或测试数据解释模型的工作原理。出于这些原因，我们将注册处理后的数据并将其版本化，以便用于我们的机器学习管道。我们将使用 Azure 机器学习 SDK 将处理后的数据注册和版本化到 Azure 机器学习工作区，如下所示：

subscription_id = '---insert your subscription ID here----'
resource_group = 'Learn_MLOps'
workspace_name = 'MLOps_WS' 
workspace = Workspace(subscription_id, resource_group, workspace_name)

从 Azure 机器学习门户获取您的 subscription ID、resource_group 和 workspace_name，如图 3.11 所示：

![Figure 3.11 – Workspace credentials (Resource group, Subscription ID, and Workspace name)]

![img/B16572_03_11.jpg]

![Figure 3.11 – Workspace credentials (Resource group, Subscription ID, and Workspace name)]

通过请求工作区凭据，将获得一个工作区对象。当运行 Workspace() 函数时，您的笔记本将连接到 Azure 平台。您将被提示点击一个身份验证链接，并提供一个随机代码和 Azure 账户详情。之后，脚本将确认身份验证。使用工作区对象，我们访问默认数据存储并将所需的数据文件上传到与工作区连接的 Azure Blob Storage 上的数据存储：

# get the default datastore linked to upload prepared data
datastore = workspace.get_default_datastore()
#upload the local file from src_dir to target_path in datastore
datastore.upload(src_dir='Dataset', target_path='data')
dataset =  /
Dataset.Tablular.from_delimited_files(datastore.path('data/weather_dataset_processed.csv'))

Tabular.from_delimited_files() 函数可能在未安装 .NET Core 2.1 的 Linux 或 MacOS 机器上导致失败。为了正确安装此依赖项，请按照以下说明操作：docs.microsoft.com/en-us/dotnet/core/install/linux。成功执行上述命令后，您将上传数据文件到数据存储，并看到如图 3.12 所示的结果。您可以通过以下方式从数据存储预览数据集：

# preview the first 3 rows of the dataset from the datastore
dataset.take(3).to_pandas_dataframe()

当数据上传到数据存储时，我们将按照以下方式将数据集注册到工作区并对其进行版本控制：

weather_ds = dataset.register(workspace=workspace, name=weather_ds_portofTurku, description='processed weather data')

register(...) 函数将数据集注册到工作区，如图 3.12 所示。有关详细文档，请访问 https://docs.microsoft.com/en-us/azure/machine-learning/how-to-create-register-datasets#register-datasets:

![图 3.12 – 已注册在 ML 工作区中的处理数据集]

![img/B16572_03_12.jpg]

图 3.12 – 已注册在 ML 工作区中的处理数据集

面向 ML 管道

到目前为止，我们已经通过处理不规则性（如缺失数据）、通过观察相关性选择特征、创建新特征，最后将处理后的数据导入并版本化管理到机器学习工作区。在机器学习管道中，有两种方式可以加载数据以用于 ML 模型训练。一种是从中央存储（存储所有原始数据的地方）加载，第二种方式是使用特征存储。因为知识就是力量，在我们进入机器学习管道之前，让我们先了解特征存储的使用。

特征存储

特征存储通过存储重要特征并使其可用于训练或推理来补充中央存储。特征存储是一个将原始数据转换为 ML 模型可以直接用于训练和推理以做出预测的有用特征的存储库。原始数据通常来自各种数据源，这些数据源可以是结构化、非结构化、流式、批量或实时的。所有这些都需要被拉取、转换（使用特征管道）并存储在某处，而那个地方可以是特征存储。然后特征存储将数据提供给消费。数据科学家倾向于重复工作（尤其是数据处理）。如果我们有一个集中的特征存储，就可以避免这种情况。特征存储允许数据科学家与其他团队高效地共享和重用特征，从而提高他们的生产力，因为他们不必从头开始预处理特征。

![图 3.13：特征存储工作流程]

![img/B16572_03_13.jpg]

图 3.13：特征存储工作流程

如图 3.13所示，特征存储使用一个连接到中央存储（存储来自多个来源的数据）的特征管道来转换和存储原始数据，使其成为 ML 训练的有用特征。存储在特征存储中的特征可以用于训练、服务或发现洞察或趋势。以下是使用特征存储的一些好处：

• 为训练数据进行高效的特征工程

• 避免在训练前进行不必要的预处理

• 避免重复的特征工程

• 可用于快速推理（测试）的特征

• 系统支持特征服务

• 通过特征存储进行探索性数据分析

• 重新使用模型特征的机会

• 对特征进行快速查询

• 训练数据集的可重复性

• 监控生产中的特征漂移（我们将在第十二章，模型服务和监控)中学习特征漂移）

• 可用于数据漂移监控的功能

了解特征存储的优势是好的，因为它可以为机器学习管道（尤其是数据摄取步骤）提供动力，但并不适用于所有情况。这取决于你的用例。对于我们的用例实现，我们不会使用特征存储，而是直接从中央存储中联络数据，在那里我们已经预处理并注册了我们用于训练和测试的数据集。有了摄取和版本化的数据，你就可以开始构建你的机器学习管道了。机器学习管道将使进一步的特性工程、特性缩放、整理训练和测试数据集成为可能，这些数据集将被用于训练机器学习模型和调整机器学习训练的超参数。机器学习管道和功能将在云计算资源上执行，而不是像本章中我们在本地计算机上所做的那样。它将是纯云基础的。

摘要

在本章中，我们学习了如何识别适合商业问题的机器学习解决方案，并将操作分类以实施合适的 MLOps。我们设置了我们的工具、资源和开发环境。讨论了 10 个源代码管理的原则，随后是数据质量特性。恭喜！到目前为止，你已经实现了 MLOps 工作流程的关键构建块——数据处理和将处理后的数据注册到工作区。最后，我们简要了解了机器学习管道的基本要素。

在下一章，你将进行 MLOps 中最激动人心的部分：构建机器学习管道。让我们继续前进！

第四章：机器学习管道

在本章中，我们将通过使用 MLOps 方法通过实际示例探索和实现 机器学习（ML）管道。我们将通过解决我们在 第三章 中一直在工作的业务问题，即 代码遇见数据，来学习更多。这种理论与实践相结合的学习方法将确保您将全面了解为您的或您公司的问题构建和实现 ML 管道的知识。ML 管道具有模块化脚本或代码，执行所有传统的 ML 步骤，例如在训练或重新训练任何模型之前进行数据预处理、特征工程和特征缩放。

我们从本章开始，通过执行特征工程和缩放，将我们在上一章中处理过的预处理数据摄取进来，以便为 ML 训练做好准备。我们将发现 ML 管道的原理，并在业务问题中实现它们。接下来，我们将探讨 ML 模型训练、超参数调整和训练模型的测试。最后，我们将学习如何打包模型及其所需工件。我们将注册模型以进行进一步评估，并将部署 ML 模型。在本章中，我们将涵盖以下主要主题：

• 掌握 ML 管道的基础知识

• 数据摄取和特征工程

• ML 训练和超参数优化

• 模型测试和定义指标

• 模型打包

• 注册模型和生产工件

掌握 ML 管道的基础知识

在我们开始实现 ML 管道之前，让我们先掌握基础知识。我们将反思 ML 管道，并为 ML 管道实现设置所需资源，然后我们将开始数据摄取。让我们通过反思 第一章 中 MLOps 工作流程基础 的 图 14 中讨论的 ML 管道来揭开 ML 管道的神秘面纱。

图 4.1 – 机器学习管道

如 图 4.1 所示，一个全面的 ML 管道包括以下步骤：

1. 数据摄取

2. 模型训练

3. 模型测试

4. 模型打包

5. 模型注册

为了获得不同的视角，我们将同时使用基于云的 Azure ML 服务和开源的 MLflow 来实现管道的所有这些步骤。Azure ML 和 MLflow 是 MLOps 的强大组合：它们展示了 表 4.1 中显示的功能。从以下表格中我们可以看到，它们在功能上也是独特的。

表 4.2 – MLflow 与 Azure ML 服务比较

为了实现机器学习管道，我们需要为我们的数据集提供存储资源，并为我们的机器学习模型提供计算资源。如前所述，在第二章“描述您的机器学习问题”中，我们将执行实现机器学习管道和业务问题的计算，如图图 4.2所示。

我们在本地计算机或 PC 上处理数据以开始，并预处理数据以进行机器学习训练。对于机器学习训练和管道实现，我们使用云上配置的计算资源（Microsoft Azure）。尽管管道的机器学习训练可以在您的本地计算机上进行，但我们将使用云上的计算资源来学习如何配置和使用所需的计算资源以实现机器学习管道。

![图 4.3 – 数据和机器学习任务的计算位置

![img/B16572_04_002.jpg]

图 4.3 – 数据和机器学习任务的计算位置

不再拖延，让我们按照以下步骤配置所需的机器学习管道计算资源：

1. 前往您的机器学习工作空间。![图 4.4 – Azure 机器学习工作空间

   ]

   图 4.4 – Azure 机器学习工作空间

2. 前往计算选项，点击创建按钮以探索云上可用的计算选项。

3. 选择适合机器学习模型训练的最佳和高效的计算选项。

   根据您的训练需求和成本限制选择合适的计算选项，并为其命名。例如，在图 4.4中，为实验unique_code-ml-compute1选择了计算或虚拟机。图 4.4中选择的计算选项是成本最低的计算选项之一，这足以实现业务问题的机器学习管道。为了更快地实现和训练机器学习模型，建议使用STANDARD_DS11_V2（2 核，14 GB RAM）虚拟机大小。使用此选项，训练一个模型将大约需要 12 分钟。

4. 配置之前创建的计算资源。在命名并创建所需的计算资源后，您的计算资源已配置、就绪并运行在云上，如图图 4.5所示。

![图 4.6 – AzureML 工作空间中的配置计算

![img/B16572_04_005.jpg]

图 4.6 – AzureML 工作空间中的配置计算

在配置完成后，选择JupyterLab选项。JupyterLab 是一个开源的基于 Web 的用户界面。它集成了文本编辑器、代码编辑器、终端和可扩展方式集成的自定义组件等功能。我们将使用它作为连接到配置的计算资源以训练机器学习模型的编程接口。

现在，我们将开始实际实现机器学习管道。按照以下步骤实现机器学习管道：

1. 要开始实施，克隆您已导入到 Azure DevOps 项目的仓库。要克隆仓库，请从 仓库 菜单的右上角点击 克隆 按钮，然后点击 生成 Git 凭据 按钮。将创建一个哈希密码。

   图 4.7 – 克隆 Azure DevOps Git 仓库（生成 Git 凭据）

2. 从 命令行 部分复制 HTTPS 链接以获取 Azure DevOps 仓库链接，如下所示：

   https://xxxxxxxxx@dev.azure.com/xxxxx/Learn_MLOps/_git/Learn_MLOps
   

3. 复制从 步骤 1 生成的密码，并将其添加到 步骤 2 中的链接，方法是在 @ 字符之前用 : 分隔的第一个用户名之后添加密码。然后就可以使用以下 git clone 命令而不会出现权限错误：

   git clone https://user:password_hash@dev.azure.com/user/repo_created
   

4. 一旦启动了 JupyterLab，我们将访问终端以将仓库克隆到 Azure 计算中。要访问终端，您必须从 启动器 选项卡中选择 终端 选项。另一种直接访问终端的方法是使用 Azure ML 工作区中计算实例列表中的应用程序 URI 列表中的 终端 链接。转到 JupyterLab 的 终端 选项并执行以下操作（如图 4.7 所示）：

   git clone https://xxxxxxxxx@dev.azure.com/xxxxx/Learn_MLOps/_git/Learn_MLOps
   

   这是输出：

   

   图 4.8 – 在 Azure 计算上克隆 Azure DevOps Git 仓库

5. 进入 04_MLpipelines 文件夹，并按照克隆仓库中的 ML-pipeline.ipynb 文件中的实施步骤进行操作。所有以下步骤都在 ML-pipeline.ipynb 中实现。建议遵循文件说明以更好地理解实施，并按照您的设置在新的文件中自行执行代码。

   到目前为止，我们已经配置了计算资源并在计算中克隆了 GitHub 仓库。

6. 接下来，我们通过导入所需的库开始实施 ML-pipeline.ipynb 文件，例如 pandas、numpy、azureml、pickle、mlflow 等，如下面的代码块所示：

   import pandas as pd
   import numpy as np
   import warnings
   from math import sqrt
   warnings.filterwarnings('ignore')
   from azureml.core.run import Run
   from azureml.core.experiment import Experiment
   from azureml.core.workspace import Workspace
   from azureml.core.model import Model
   from azureml.core.authentication import ServicePrincipalAuthentication
   from azureml.train.automl import AutoMLConfig
   import pickle
   from matplotlib import pyplot as plt
   from matplotlib.pyplot import figure
   import mlflow
   

7. 接下来，我们使用 setup MLflow（用于跟踪实验）。使用 get_mlflow_tracking_url() 函数获取 MLflow 实验和工件应记录的位置的跟踪 ID（在这种情况下，我们获取已配置的训练计算的跟踪 ID）。然后使用 set_tracking_uri() 函数连接到已配置训练计算的跟踪 URI（特定资源的统一资源标识符）。跟踪 URI 可以是远程服务器、数据库连接字符串或本地目录中记录数据的本地路径。在我们的情况下，我们默认将跟踪 URI 指向本地路径（在已配置的训练计算上）：

   uri = workspace.mlruns folder where MLflow artifacts and logs will be saved for experiments. 
   

通过设置 MLflow 实验的跟踪 URI，您已为 MLflow 设置保存其工件和日志的mlruns文件夹（在您配置的计算上）的位置。在执行这些命令后，检查当前路径。您将找到mlruns文件夹。

数据摄入和特征工程

数据对于训练机器学习模型至关重要；没有数据，就没有机器学习。数据摄入是机器学习管道的触发步骤。它通过从各种数据源提取数据并摄入模型训练所需的数据来处理数据的量、速度、真实性和多样性。

机器学习管道通过摄入用于训练机器学习模型的正确数据来启动。我们将从上一章中注册的预处理数据开始。按照以下步骤访问和导入预处理数据，使其为机器学习训练做好准备：

1. 使用 Azure ML SDK 中的Workspace()函数，如下访问机器学习工作区中的数据存储：

   from azureml.core import Workspace, Dataset
   subscription_id = 'xxxxxx-xxxxxx-xxxxxxx-xxxxxxx'
   resource_group = 'Learn_MLOps'
   workspace_name = 'MLOps_WS'
   workspace = subscription_id, resource_group, and workspace_name and initiate a workspace object using these credentials. When these instructions are successfully executed in the JupyterLab, you can run the remaining blocks of code in the next cells.
   

2. 导入上一章中准备好的预处理数据集。使用 Azureml SDK 中的Dataset函数的.get_by_name()函数导入预处理数据集，并使用该函数检索所需的数据集：

   # Importing pre-processed dataset
   dataset = Dataset.get_by_name (workspace, name='processed_weather_data_portofTurku')
   print(dataset.name, dataset.version)
   

3. 在成功检索或挂载数据集后，可以通过打印dataset.name和dataset.version来确认，应打印processed_weather_data_portofTurku 1或您之前给数据集命名的名称。

4. 在检索到预处理数据后，将其分为训练集和验证集至关重要，以便在训练阶段和后续阶段训练机器学习模型并进行测试或评估。因此，我们将其分为 80%（训练集）和 20%（测试集）的分割比，如下所示：

   df_training = df.iloc[:77160]
   df_test = df.drop(df_training.index)
   df_training.to_csv('Data/training_data.csv',index=False)
   df_test.to_csv('Data/test_data.csv',index=False)
   

5. 在成功分割数据后，这两个数据集被存储并注册到数据存储（连接到 Azure ML 工作区）中，如下所示：

   datastore = workspace.get_default_datastore()
   datastore.upload(src_dir='Data', target_path='data')
   training_dataset = /
   Dataset.Tabular.from_delimited_files(datastore.path('data/training_data.csv'))
   validation_dataset = /
   Dataset.Tabular.from_delimited_files(datastore.path('data/validation_data.csv'))
   training_ds = training_dataset.register(workspace=workspace, name='training_dataset',
   description='Dataset to use for ML training')
   test_ds = validation_dataset.register(workspace=workspace,
                                    name='test_dataset',
   description='Dataset for validation ML models')
   

通过使用register()函数，我们能够注册训练集和测试集，这些数据集可以在以后从数据存储中导入。

接下来，我们将导入训练数据并将其摄入到机器学习管道中，并使用测试数据集来测试模型在生产中对未见数据的性能或用于模型分析。

数据摄入（训练数据集）

要将训练数据摄入到机器学习管道中，我们首先使用get_by_name()函数导入它，然后使用to_pandas_dataframe()函数将其转换为 pandas 数据框：

dataset = Dataset.get_by_name (workspace, name='training_dataset')
print(dataset.name, dataset.version)
df = dataset.to_pandas_dataframe ( )

现在已检索到训练数据集，并将用于进一步训练机器学习模型。目标是训练分类模型以预测是否会下雨。因此，选择Temperature（温度）、Humidity（湿度）、Wind_speed（风速）、Wind_bearing（风向）、Visibility（能见度）、Pressure（气压）和Current_weather_conditions（当前天气状况）特征来训练二元分类模型，以预测未来的天气状况（4 小时后）。

按照以下步骤选择特征并进行缩放：

1. 在训练机器学习模型之前，选择正确的特征和缩放数据是至关重要的。因此，我们按照以下方式选择特征。变量X中的值代表自变量，而变量Y是因变量（预测的天气）：

   X = df[['Temperature_C', 'Humidity', 'Wind_speed_kmph', 'Wind_bearing_degrees', 'Visibility_km', 'Pressure_millibars', 'Current_weather_condition']].values
   y = df['Future_weather_condition'].values
   

2. 使用sklearn中的train_test_split()函数将训练数据分割成训练集和测试集（用于训练后的验证）。为了通过保持与先前实验相同配置的样本来重现训练会话，需要固定随机种子（random_state）。因此，我们将使用random_state=1：

   # Splitting the Training dataset into Train and Test set for ML training
   from sklearn.model_selection import train_test_split
   X_train, X_val,  y_train, y_val = train_test_split(X, y, test_size=0.2, random_state=1)
   

   在 80%（训练数据）和 20%（测试数据）的分割下，训练集和测试集现在已准备好进行特征缩放和机器学习模型训练。

3. 为了使机器学习模型训练达到最佳和高效，数据需要在同一尺度上。因此，我们使用sklearn中的StandardScaler()对数据进行缩放，以校准数据中的所有数值到同一尺度：

   from sklearn.preprocessing import StandardScaler
   sc = StandardScaler()
   X_train = sc.fit_transform(X_train)
   X_val = sc.transform(X_val)
   

   在这一步中，使用StandardScaler对训练数据的数值进行缩放，并将所有值转换到基于X_train值的-1到1的范围内。现在我们已准备好训练机器学习模型（有趣的部分）！

机器学习训练和超参数优化

我们已经准备好进行有趣的部分，即训练机器学习模型！这一步使模型训练成为可能；它包含模块化脚本或代码，执行所有传统的机器学习训练步骤，例如拟合和转换数据以训练模型，以及超参数调整以收敛到最佳模型。这一步骤的输出是一个训练好的机器学习模型。

为了解决业务问题，我们将使用支持向量机分类器和随机森林分类器训练两个著名的模型。这些模型的选择基于它们的流行度和结果的一致性；你可以自由选择你喜欢的模型——在这个步骤中没有限制。首先，我们将训练支持向量机分类器，然后是随机森林分类器。

支持向量机

支持向量机（SVM）是一种流行的监督学习算法（用于分类和回归）。数据点在 N 维空间中使用超平面进行分类。它以较少的计算能力产生显著的准确性而闻名。建议在理论上了解 SVM，以便更好地理解实践中的模型训练。了解更多关于 SVM 的信息，请访问：www.kdnuggets.com/2017/02/yhat-support-vector-machine.html。

让我们开始训练 SVM 分类器：

1. 我们首先使用 Azure SDK 中的Experiment()函数启动训练或实验。此函数的目的是在 Azure ML 工作区中启动一个训练运行或实验，以便监控和记录模型训练性能：

   myexperiment = Experiment(workspace, "support-vector-machine")
   

2. 同样，MLflow 实验也被启动，以观察不同的视角：

   mlflow.set_experiment("mlflow-support-vector-machine")
   

   现在，我们在 Azure ML 工作区和 MLflow 中启动了实验。以下训练步骤将被监控和记录。

3. 接下来，我们进行超参数调整，以找到收敛最佳模型的最佳参数。这可以手动完成，但更高效和自动的解决方案，如 Grid Search 或 Random Search 存在。对于训练，SVM 分类器使用以下 Grid Search。我们通过使用SVC()和GridSearchCV()函数从sklearn中，并在 Azure ML 和 MLflow 上记录运行来继续操作：

   from sklearn.svm import SVC
   from sklearn import svm 
   from sklearn.model_selection import GridSearchCV
   parameters = {'kernel':('linear', 'rbf'), 'C':[1, 10]}
   svc = svm.STANDARD_DS11_V2 (2 cores, 14 GB RAM) compute machine). The result or the output of the Grid Search suggests the best performing parameters to be C=1 and the kernel as rbf. Using run.log(), we have logged the dataset used to train the model (the training set) and keep track of the experiment. This data is logged to the Azure ML workspace and the MLflow experiments. 
   

4. 最后，使用最佳参数，以下是用C=1和kernel='rbf '训练新模型的步骤：

   svc = SVC(C=svc_grid.get_params(deep=True)['estimator__C'], kernel=svc_grid.get_params(deep=True)['estimator__kernel'])
   svc.fit(X_train, y_train)
   # Logging training parameters to AzureML and MLFlow experiments
   run.log("C", svc_grid.get_params(deep=True)['estimator__C'])
   run.log("Kernel", svc_grid.get_params(deep=True)['estimator__kernel'])
   After training the SVC classifier, the following output is shown:
   SVC(C=1.0, cache_size=200, class_weight=None, coef0=0.0,
     decision_function_shape='ovr', degree=3, gamma='auto_deprecated',
     kernel='rbf', max_iter=-1, probability=False, random_state=None,
     shrinking=True, tol=0.001, verbose=False)
   

   通过这种方式，我们已经训练了 SVM 模型！现在我们将训练随机森林分类器模型。

随机森林分类器

随机森林是另一种流行的监督学习模型（用于分类和回归）。随机森林是一种集成学习方法，它使用多个决策树。在执行模型训练之前，建议了解随机森林模型的理论工作原理。要了解更多关于随机森林模型的信息，请访问www.kdnuggets.com/2020/01/random-forest-powerful-ensemble-learning-algorithm.html。

1. 要开始训练随机森林分类器，按照以下方式在 Azure ML 工作区和 MLflow 实验中初始化实验：

   myexperiment = Experiment(workspace, "support-vector-machine")
   mlflow.set_experiment("mlflow-support-vector-machine")
   

2. 实验成功启动后，可以通过从sklearn.ensemble导入RandomForestClassifier()函数并使用所需参数来启动训练，如下所示。这些参数是随机选择的（没有进行Grid Search）。可以使用Grid Search或RandomizedSearch来确定最佳参数并优化算法：

   from sklearn.ensemble import RandomForestClassifier
   rf = RandomForestClassifier (max_depth=10, random_state=0, n_estimators=100)
   

3. 模型训练是通过传递训练数据到fit(X_train, y_train)函数来完成的。训练数据集和参数如下记录到 Azure ML 和 MLflow 实验中：

   # initialize runs in Azureml and mlflow
   run = myexperiment.start_logging()
   mlflow.start_run()
   # Log dataset used 
   run.log("dataset name", dataset.name)
   run.log("dataset Version", dataset.version)
   rf.fit(X_train, y_train)
   # Logging training parameters to AzureML and MLFlow experiments
   run.log("max_depth", 10)
   run.log("random_state", 0)
   run.log("n_estimators", 100)
   

4. 训练后，输出如下所示：

   RandomForestClassifier(bootstrap=True, class_weight=None, criterion='gini',
   max_depth=10, max_features='auto', max_leaf_nodes=None,
   min_impurity_decrease=0.0, min_impurity_split=None,
   min_samples_leaf=1, min_samples_split=2,
   min_weight_fraction_leaf=0.0, n_estimators=100, n_jobs=None,
   oob_score=False, random_state=0, verbose=0, warm_start=False)
   

   这是完成随机森林模型训练后的预期结果。通过这种方式，你已经成功完成了随机森林模型的训练，总共训练了两个机器学习模型：SVM 分类器和随机森林分类器。

   训练后，从准确度和其他指标方面测试模型性能至关重要，以了解模型是否足够适合生产或测试环境。

接下来，我们将测试在训练模型之前分割的测试数据的训练模型的性能。

模型测试和定义指标

在这一步，我们将评估训练好的模型在单独的数据点集上的性能，这些数据点被称为测试数据（在数据摄入步骤中提前分割和版本化）。根据用例选择的指标评估训练模型的推断。这一步的输出是关于训练模型性能的报告。

为了全面分析模型性能，我们将测量准确率、精确率、召回率和 F 分数。这在业务问题背景下的实际含义如下：

• 准确率：正确预测的数据测试样本总数与预测总数之比。

• 精确率：精确率衡量的是正确预测为正例的正例的比例。精确率 = 真正例 / (真正例 + 假正例)

• 召回率：召回率衡量的是正确识别的实际正例的比例。召回率 = 真正例 / (真正例 + 假负例)

• F 分数：在计算 F 分数时，既考虑了精确率也考虑了召回率。它是精确率和召回率的调和平均（平均值）。F1 Score = 2(Recall * Precision) / (Recall + Precision)*。

我们将在验证数据集上测量这些指标。让我们看看 SVM 分类器和随机森林分类器的结果。

测试 SVM 分类器

使用 sklearn.metrics，我们计算模型在测试数据样本上的性能指标 accuracy、f1_score、precision 和 recall，并使用 run.log() 函数将它们记录到 Azure ML 工作区和 MLflow 实验，如下所示。

从 sklearn.metrics 中导入 accuracy_score、f1_score、precision_score 和 recall_score：

predicted_svc = svc.predict(X_test)
acc = accuracy_score(y_test, predicted_svc)
fscore = f1_score(y_test, predicted_svc, average="macro")
precision = precision_score(y_test, predicted_svc, average="macro")
recall = recall_score(y_test, predicted_svc, average="macro")
run.log("Test_accuracy", acc)
run.log("Precision", precision)
run.log("Recall", recall)
run.log("F-Score", fscore)
run.log("Git-sha", sha)

根据实验，测试数据指标的输出已记录在 Azure ML 工作区。您可以在注册模型（我们将在 注册模型和生产工件 中注册模型）后稍后读取这些日志。

测试随机森林分类器

与我们为 SVM 分类器模型所做的工作类似，使用 sklearn.metrics 我们计算 accuracy、f1_score、precision 和 recall：

acc = accuracy_score(y_test, predicted_rf)
fscore = f1_score(y_test, predicted_rf, average="macro")
precision = precision_score(y_test, predicted_rf, average="macro")
recall = recall_score(y_test, predicted_rf, average="macro")
run.log("Test_accuracy", acc)
run.log("Precision", precision)
run.log("Recall", recall)
run.log("F-Score", fscore)
run.log("Git-sha", sha)

使用 run.log() 函数，将模型在测试数据样本上的性能指标输出记录到 Azure ML 工作区和 MLflow 实验。

模型打包

在上一步测试了训练好的模型之后，可以将模型序列化为文件以导出到测试或生产环境。序列化文件可能会遇到兼容性挑战，例如模型互操作性，如果操作不当。模型互操作性是一个挑战，尤其是在使用不同框架训练模型时。例如，如果模型 1 使用 sklearn 训练，而模型 2 使用 TensorFlow 训练，那么模型 1 就不能使用 TensorFlow 导入或导出以进行进一步的模型微调或模型推理。

为了避免这个问题，ONNX 提供了一个模型互操作性的开放标准。ONNX 代表 Open Neural Network Exchange。它为导入和导出模型提供了一个序列化标准。我们将使用 ONNX 格式序列化模型，以避免兼容性和互操作性问题的出现。

使用 ONNX，通过 skl2onnx 库将训练好的模型序列化。模型以 svc.onnx 文件的形式序列化，以便进一步将模型导出和导入到测试和生产环境：

# Convert into SVC model into ONNX format file
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
initial_type = [('float_input', FloatTensorType([None, 6]))]
onx = convert_sklearn(svc, initial_types=initial_type)
with open("outputs/svc.onnx", "wb") as f:
    f.write(onx.SerializeToString())

此代码的输出是一个序列化的 svc.onnx 文件。同样，使用 ONNX，我们将随机森林模型转换为名为 rf.onnx 的序列化文件，以便进一步将模型导出和导入到测试和生产环境：

# Convert into RF model into ONNX format file
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
initial_type = [('float_input', FloatTensorType([None, 6]))]
onx = convert_sklearn(rf, initial_types=initial_type)
with open("outputs/rf.onnx", "wb") as f:
    f.write(onx.SerializeToString())

此代码的输出是一个序列化的 rf.onnx 文件。接下来，我们将这些序列化模型注册到模型注册表中。

注册模型和生产工件

在这一步，之前步骤中已序列化或容器化的模型被注册并存储在模型注册表中。一个注册的模型被编译为一个逻辑容器，用于一个或多个作为模型功能使用的文件。例如，由多个文件组成的模型可以注册为模型注册表中的单个模型。通过下载注册的模型，可以接收所有文件。注册的模型可以按需部署和使用进行推理。

让我们使用 Azure ML SDK 中的 model.register() 函数，将上一节中序列化的模型注册。通过使用此函数，序列化的 ONNX 文件被注册到工作区，以便进一步使用和部署到测试和生产环境。现在，让我们注册序列化的 SVM 分类器模型（svc.onnx）：

# Register Model on AzureML WS
model = Model.register (model_path = './outputs/svc.onnx', # this points to a local file 
                       model_name = "support-vector-classifier", 
                       tags = {'dataset': dataset.name, 'version': dataset.version, 'hyparameter-C': '1', 'testdata-accuracy': '0.9519'}, 
                       model_framework='pandas==0.23.4',
                       description = "Support vector classifier to predict weather at port of Turku",
                       workspace = workspace)
print('Name:', model.name)
print('Version:', model.version)

模型通过命名和标记模型以符合需求进行注册。我们可以通过检查注册的模型名称和版本来确认模型注册成功。输出将反映您在注册时使用的模型名称（例如，support-vector-classifier）并显示模型版本为 1。同样，让我们注册序列化的随机森林分类器模型（rf.onnx）：

# Register Model on AzureML WS
model = Model.register (model_path = './outputs/rf.onnx', # this points to a local file 
                       model_name = "random-forest-classifier", 
                       tags = {'dataset': dataset.name, 'version': dataset.version, 'hyparameter-C': '1', 'testdata-accuracy': '0.9548'}, 
                       model_framework='pandas==0.23.4',
                       description = "Random forest classifier to predict weather at port of Turku",
                       workspace = workspace)
print('Name:', model.name)
print('Version:', model.version)

模型注册成功后，print 函数的输出将反映您在注册时使用的模型名称（例如，random-forest-classifier）并显示模型版本为 1。最后，我们将注册用于推理的生产工件。现在，您可以在 Azure ML 工作区的 模型 部分中看到这两个模型，如图 4.8 所示：

图 4.9 – 已注册的 SVM 模型（含测试指标）

这样，您可以可视化并分析在 Azure ML 工作区中训练和测试的每个模型的训练和测试日志。它提供了对模型训练和测试的鸟瞰图，同时为注册的模型提供了可追溯性。

注册生产工件

为了在实时模型推理中缩放输入数据，需要一个标量来将数据缩放到与 ML 训练时数据缩放相同的尺度。我们将使用用于scaling X_train的相同缩放函数，并将这个变量序列化到一个pickle文件中。最后，我们将这个pickle文件注册到工作区，以便后续检索和使用（特别是对于测试和生产环境中的模型推理）。使用pickle，可以通过以下方式使用pickle.dump()函数将缩放变量sc写入一个pickle文件。

使用import pickle as open('./outputs/scaler.pkl', 'wb') as scaler_pkl导入pickle：

    pickle.dump(sc, scaler_pkl)

代码的输出将保存一个名为scaler.pkl的序列化pickle文件，用于缩放器。接下来，我们将此文件注册到模型注册表中，以便以后与我们的模型一起下载和部署以进行推理。缩放器是通过以下model.register()函数注册的：

# Register Model on AzureML WS
scaler = Model.register(model_path = './outputs/scaler.pkl', # this points to a local file 
                       model_name = "scaler", # this is the name the model is registered as
                       tags = {'dataset': dataset.name, 'version': dataset.version}, 
                       model_framework='pandas==0.23.4',
                       description = "Scaler used for scaling incoming inference data",
                       workspace = workspace)
print('Name:', scaler.name)
print('Version:', scaler.version)

在保存和注册缩放对象后，可以在 Azure ML 工作区中找到已注册的对象。同样，已注册的模型也可以跟踪，如图图 4.8所示：

![图 4.10 – 已注册的模型

图 4.10 – 已注册的模型

恭喜！SVM 分类器和随机森林分类器，以及序列化的缩放器，都已注册到模型注册表中。这些模型可以在以后下载和部署。这标志着 ML 管道的成功实施！

摘要

在本章中，我们介绍了 ML 管道的理论，并通过构建用于商业问题的 ML 管道来实践。我们为训练这些 ML 模型设置了工具、资源和开发环境。我们从数据摄取步骤开始，接着是模型训练步骤、测试步骤、打包步骤，最后完成了注册步骤。恭喜！到目前为止，你已经实现了 MLOps 工作流程的关键构建块。

在下一章中，我们将探讨评估和打包生产模型。

第五章：模型评估和打包

在本章中，我们将详细了解机器学习模型的评估和可解释性指标。这将使我们能够在训练模型后全面了解其性能。我们还将学习如何打包模型并将它们部署以供进一步使用（例如在生产系统中）。我们将详细研究我们在上一章中如何评估和打包模型，并探索评估和解释模型的新方法，以确保对训练模型及其在生产系统中潜在可用性的全面理解。

我们从学习各种测量、评估和解释模型性能的方法开始本章。我们探讨测试模型以用于生产以及打包机器学习模型以用于生产和推理的多种方式。随着你将获得一个评估任何类型机器学习模型并将其打包用于生产的框架，我们将对机器学习模型的评估进行深入研究。准备好在评估方面打下坚实的基础，并使机器学习模型为生产做好准备。为此，我们将在本章中涵盖以下主要内容：

• 模型评估和可解释性指标

• 生产测试方法

• 为什么需要打包机器学习模型？

• 如何打包机器学习模型

• 可推理模型

模型评估和可解释性指标

获取数据和训练机器学习模型是创造商业价值的好起点。在训练模型后，衡量模型性能并理解模型为何以及如何以某种方式预测或表现至关重要。因此，模型评估和可解释性是 MLOps 工作流程中的关键部分。它们使我们能够理解和验证机器学习模型，以确定它们将产生的商业价值。由于存在多种类型的机器学习模型，因此有大量的评估技术。

回顾第二章，“描述你的机器学习问题”，其中我们研究了被归类为学习模型、混合模型、统计模型和HITL（人机交互）模型的各种类型的模型，我们现在将讨论评估这些模型的不同指标。以下是图 5.1中显示的一些关键模型评估和可解释性技术。这些已成为研究和工业界评估模型性能和证明模型性能的标准：

图 5.1 – 模型评估和解释分类法

（当谨慎导航、选择和执行时，此分类法中的技术几乎可以应用于任何商业问题。）

学习模型指标

学习模型分为两种类型 – 监督学习（监督学习模型或算法基于标记数据进行训练）和无监督学习（无监督学习模型或算法可以从未标记的数据中学习）。

正如我们在前面的章节中所研究的，监督学习算法的例子包括分类（随机森林、支持向量机等）和回归（线性回归、逻辑回归等）算法。另一方面，无监督学习的例子包括聚类（k 均值、DBSCAN、高斯混合模型等）和降维（PCA、随机森林、前向和后向特征消除等）算法。为了有效地衡量这些算法，以下是一些常用且高效的指标示例。

监督学习模型

监督学习模型在标记数据上训练。在训练数据中，输入的结果被标记或已知。因此，模型被训练来学习根据标记数据预测输入的结果。在训练模型后，评估模型潜力和性能是很重要的。以下是一些评估监督模型的指标。

交叉验证

评估机器学习模型对于理解其行为至关重要，这可能会很棘手。通常，数据集被分成两个子集：训练集和测试集。首先，使用训练集来训练模型，然后使用测试集来测试模型。之后，评估模型的表现以确定错误，可以使用如模型在测试数据上的准确率百分比等指标。

这种方法并不可靠也不全面，因为一个测试集的准确性可能不同于另一个测试集。为了避免这个问题，交叉验证通过将数据集分割成多个折（片段）并提供解决方案，确保每个折在某个时刻被用作测试集，如图 图 5.2 所示：

图 5.2 – K 折交叉验证

存在多种交叉验证方法，包括分层交叉验证、留一法交叉验证和 K 折交叉验证。K 折交叉验证被广泛使用，并且值得注意，因为这种技术涉及将数据集分割成 k 折/片段，然后在连续迭代中使用每个折作为测试集。这个过程很有用，因为每个迭代都有一个独特的测试集，用于测量准确性。然后，使用每个迭代的准确性来找到平均测试结果（通过简单地取所有测试结果的平均值来计算）。

通过交叉验证获得的平均准确度比传统的准确度度量更可靠和全面。例如，在图 5.2中，我们可以看到五个迭代。这些迭代中的每一个都有一个独特的测试集，通过测试每个迭代的准确度并平均所有准确度，我们得到使用 K 折交叉验证的模型平均准确度。值得注意的是，如果你有一个非常大的训练数据集，或者模型需要大量的时间、CPU 和/或 GPU 处理，那么 K 折可能不是一个好的选择。

精确度

当一个分类器被训练时，精确度可以是一个在量化分类器做出的实际属于正类的正确正类预测中的关键指标。精确度量化了正确预测的正例数量。

例如，假设我们训练了一个分类器，用于从图像中预测猫和狗。在将训练好的模型应用于测试图像后，该模型用于从图像中预测/检测狗（换句话说，狗是正类）。在这种情况下，精确度量化了正确预测狗的数量（正类预测）。

精确度是正确预测的正例数量与预测的正例总数之比。

精确度 = 真正例 / (真正例 + 假正例)

精确度专注于最小化误报。精确度范围从 0 到 1，它与低误报率相关。精确度越高，越好；例如，一个预测癌症患者是否需要化疗治疗的图像分类器模型。如果模型预测患者应该接受化疗，而实际上并不需要，这可能会非常有害，因为化疗在不必要的情况下可能会产生有害的副作用。这种情况是一个危险的误报。高精确度得分将导致误报数量减少，而低精确度得分将导致误报数量增加。因此，关于化疗治疗，预测模型应该有一个高精确度得分。

召回率

当一个分类器被训练时，召回率可以用来量化从数据集中所有正例总数中建立的正类预测。召回率衡量的是在可能做出的所有正类预测中，正确预测的数量。与仅告诉我们总预测中正确预测数量的精确度不同，召回率提供了遗漏正类预测的证据。

例如，考虑之前讨论过的相同例子，我们训练了一个分类器从图像中预测猫和狗。在将训练好的模型应用于测试图像后，该模型用于从图像中预测/检测狗（换句话说，狗是正类）。在这种情况下，召回率量化了遗漏的狗预测数量（正预测）。

以这种方式，召回率提供了对正类覆盖率的经验性指示。

召回率 = 真阳性 / (真阳性 + 假阴性)

召回率关注的是最小化假阴性。高召回率与低假阴性率相关。召回率越高，越好。例如，一个分析机场乘客个人资料的模型试图预测该乘客是否是潜在的恐怖分子。在这种情况下，有假阳性比有假阴性更安全。如果模型预测一个无辜的人是恐怖分子，这可以通过更深入的调查来检查。但如果恐怖分子通过了，许多生命可能会处于危险之中。在这种情况下，有假阴性比有假阳性更安全，因为可以通过深入的调查研究来检查假阴性。召回率应该很高，以避免假阴性。在这种情况下，高召回率比高精确率更重要。

F-score

在我们需要避免高假阳性和高假阴性的情况下，f-score 是一个有用的度量，可以帮助我们达到这种状态。F-measure 提供了一种将精确度和召回率合并为单一指标的方法，该指标反映了这两个属性。

精确度和召回率都不能完全描述整个情况。

我们可以拥有最好的精确度，但召回率却很糟糕，或者换句话说，F-measure 同时表达了精确度和召回率。它是根据以下公式来衡量的：

F-Measure = (2 * Precision * Recall) / (Precision + Recall)

精确度和召回率的调和平均值是 F-measure。在大多数情况下，你必须在这两者之间做出选择。如果你优化你的分类器以偏向一方而忽视另一方，调和平均值会迅速下降。当精确度和召回率相似时，它处于最佳状态；例如，一个通过输入患者的图像和血液检查来预测癌症早期的模型。在这个真实场景中，如果模型输出大量假阳性，可能会给医院带来很多不必要的成本，并可能对患者的健康造成伤害。另一方面，如果模型未能检测到真正的癌症患者，许多生命就会处于危险之中。在这种情况下，我们需要避免高假阳性和高假阴性，而在这里，f-score 是一个避免高假阳性和假阴性的有用度量。F-score 的值在 0 到 1 之间。f-score 越高，越好。我们可以期待在 f-score 较高的情况下，假阳性和假阴性的数量会更少。

混淆矩阵

混淆矩阵是一个指标，它报告了分类模型在一系列已知预测值的测试数据样本上的性能。它是一个矩阵形式的指标，其中混淆矩阵是一个 N X N 矩阵，N 是预测的类别数量。例如，假设我们有两个类别要预测（二元分类），那么 N=2，因此我们将有一个 2 X 2 的矩阵，就像这里在图 5.3中所示：

图 5.3 – 二元分类的混淆矩阵

图 5.3是糖尿病和非糖尿病患者之间二元分类混淆矩阵的一个例子。有 181 个测试数据样本，对这些样本进行了预测，以将患者数据样本分类为糖尿病和非糖尿病类别。使用混淆矩阵，你可以获得对模型性能的深入见解。例如，一眼就能看出有多少预测是真实的，有多少是假阳性。这种见解在许多情况下对解释模型性能非常有价值。以下是在混淆矩阵的上下文中这些术语的含义：

• 真阳性（TP）：这些案例预测为是，并且根据测试数据样本实际上也是是。

• 真阴性（TN）：这些案例预测为无，并且根据测试数据样本实际上也是无。

• 假阳性（FP）：模型预测是，但根据测试数据样本实际上是否。这种错误被称为I 型错误。

• 假阴性（FN）：模型预测否，但根据测试数据样本实际上是是。这种错误被称为II 型错误。

在图 5.3中，以下适用：

• x轴代表由机器学习模型做出的预测。

• y轴代表实际的标签。

• 矩阵中的第一和第四个方框（对角线方框）描述了正确预测的图像。

• 矩阵中的第二和第三个方框代表假预测。

• 在第一个方框中，（非糖尿病 x 非糖尿病），108 个数据样本（真阴性 – TN）被预测为非糖尿病（正确预测）。

• 在第四个方框中，（糖尿病 x 糖尿病），36 个数据样本（真阳性 – TP）被正确预测。

• 第二个方框（猫 x 狗）中的其余图片，11 张是假阳性。

• 第三个方框（狗 x 猫），包含 26 张图片，包含假阴性。

混淆矩阵可以提供对测试数据样本上做出的预测的整体图景，这种见解在解释模型性能方面具有重要意义。混淆矩阵是分类问题的事实上的错误分析指标，因为大多数其他指标都是从这个指标派生出来的。

AUC-ROC

对于观察模型性能的不同视角可以使我们能够解释模型性能并微调它以获得更好的结果。ROC 和 AUC 曲线可以提供这样的洞察。让我们看看受试者工作特征（ROC）曲线如何帮助我们解释模型性能。ROC 曲线是一个图表，展示了分类模型在所有分类阈值下的性能。该图表使用两个参数来描述模型性能：真正例率（TPR=TP/TP+FN）和假正例率（FPR=FP/FP+TN）。

以下图表显示了一个典型的 ROC 曲线：

图 5.4 – ROC-AUC 曲线

ROC 曲线描述了不同分类阈值下的 TPR 与 FPR。降低分类阈值可以使更多项目被分类为阳性，这反过来又增加了假正例和真正例。曲线下面积（AUC）是一个用于量化分类器区分类别有效性和能力的指标，并用于总结 ROC 曲线。

AUC 值从0到1不等，如果 AUC 值为1，则分类器能够正确地区分所有正类和负类样本点；如果 AUC 值为0，则分类器无法正确地区分所有正类和负类样本点。当 AUC 值为0.5（未手动设置阈值）时，则这是一个随机分类器。

AUC 帮助我们根据预测的准确性对预测进行排序，但它不提供绝对值。因此，它是无尺度的。此外，AUC 与分类阈值无关。选择的分类阈值在使用 AUC 时并不重要，因为 AUC 估计模型预测的质量，而不考虑选择的分类阈值。

马修斯相关系数

布莱恩·马修斯于 1975 年开发了马修斯相关系数（MCC）作为模型评估的方法。它计算实际值和预期值之间的差异。它是将混淆矩阵结果扩展到衡量分类器无效性的一个方法。TP、TN、FP 和 FN 是混淆矩阵中的四个条目。这些条目被纳入系数中：

这个度量仅在预测返回所有这四个类别的良好比率时才会产生高分数。MCC 得分范围从-1到+1：

• 1是实际值和预测值之间最佳的一致性。

• 当得分为0时，这意味着实际值和预测值之间没有任何一致性。预测相对于实际值是随机的。

例如，MCC 得分为0.12表明分类器非常随机。如果它是0.93，这表明分类器很好。MCC 是一个有用的指标，有助于衡量分类器的无效性。

无监督学习模型

无监督学习模型或算法可以从未标记的数据中学习。无监督学习可以用于从未标记的数据中挖掘见解和识别模式。无监督算法广泛用于聚类或异常检测，而不依赖于任何标签。以下是评估无监督学习算法性能的一些指标。

兰德指数

兰德指数是评估聚类技术质量的指标。它描述了簇之间的相似度。兰德指数衡量正确决策的百分比。决策将一对数据点（例如，文档）分配到同一个簇。

如果存在 N 个数据点，决策的总数等于 N(N-1)/2，这表示参与决策的数据点对。

兰德指数 = TP + TN / TP + FP + FN + TN

纯度

1，不良聚类的纯度值接近 0。图 5.5 是计算 纯度 的示例的视觉表示，如下所述：

图 5.5 – 聚类后的簇

纯度是关于簇质量的外部评估标准。在 图 5.5 中，三个簇的多数类及其成员数量如下：绿色滴点 x 5（簇 1），红色点 x 5（簇 2），交叉 x 4（簇 3）。因此，纯度为 (1/17) x (5 + 5 + 3) = ~0.76。

轮廓系数

对于聚类算法，确定簇的质量是很重要的。为了确定簇的质量或好坏，使用轮廓分数或轮廓系数作为指标。其值范围从 -1 到 1。当簇之间明显可区分或彼此远离时，轮廓分数为 1。相反，-1 表示簇分配错误，0 表示簇彼此之间没有区别。这就是计算轮廓分数的方法：

轮廓分数 = (b-a)/max(a,b)

a = 簇内每个点之间的平均距离（平均簇内距离）。

b = 所有簇之间的平均距离（平均簇间距离）。

混合模型的指标

通过结合传统方法开发混合方法来解决各种商业和研究问题，机器学习（ML）已经取得了快速发展。混合模型包括半监督、自监督、多实例、多任务、强化、集成、迁移和联邦学习模型。为了评估和验证这些模型，根据用例和模型类型使用一系列指标。了解这些指标对于能够根据您未来将开发和评估的模型使用正确的指标是有好处的。以下是评估混合模型的指标：

人类与机器测试

在训练和测试机器学习和深度学习模型时，渴望达到人类水平的表现是非常常见的。为了验证模型并得出结论，即模型已达到或超过了人类水平的表现，会在任务上执行人机对比实验。使用机器学习模型实现相同任务，并将人类的表现与机器学习模型的表现进行评估。根据上下文和任务，有各种评估人机表现的指标。以下是一些例子：

• 双语评估辅助工具（BLEU）是一种评估机器翻译从一种语言到另一种语言任务文本质量的方法。机器翻译算法生成的文本质量与人类输出进行比较。评估的目的是观察机器翻译与专业人类翻译的接近程度。

• 基于检索的摘要评估辅助工具（ROUGE）是一种人机性能评估指标，用于评估自动摘要和机器翻译等任务。此指标比较自动生成的摘要或翻译与人类生成的摘要/翻译。

图灵测试

图灵测试是由著名的艾伦·图灵设计的。他在 1950 年代将其称为模仿游戏。图灵测试是评估机器展现与人类类似智能行为能力的测试。从另一个角度来看，图灵测试也是评估机器欺骗人类，使人类相信机器完成的任务类似于人类或由人类完成的测试。例如，我们可以在 图 5.6 中看到图灵测试的操作，其中人类审问者 X 与计算机或机器受试者（Bob）以及人类受试者（Alice）之间正在进行基于文本的交互：

图 5.6 – 图灵测试

在图灵测试中，人类审问者 X 进行一系列交互，包括与 Bob（计算机）和 Alice（人类）的交互，目的是正确地区分人类和机器。如果审问者无法正确区分它们，或者错误地将机器误认为是人类（Bob 误认为是 Alice），则机器通过图灵测试。

每次返回的奖励

强化学习模型是混合模型，涉及代理和操作环境之间的连续学习机制，以实现预定义的目标。代理根据达到目标的有效或最优步骤所获得的奖励进行学习。当目标是最佳控制时，你将希望根据代理在任务中的表现来衡量它。为了量化代理执行任务的好坏，可以使用奖励的聚合度量，如每集的总奖励（也称为“回报”）或每时间步的平均奖励，来评估和优化代理相对于环境和目标的控制。

后悔

后悔是用于强化学习等混合模型的一个常用指标。在每一步，你计算最优决策的奖励与你的算法所采取的决策之间的差异。然后通过累加这些差异来计算累积后悔。最优策略下的最小后悔为 0。后悔越小，算法的表现越好。

后悔使代理的行动能够根据如图 5.7 所示的代理最佳性能的最佳策略进行评估。红色阴影区域是后悔：

图 5.7 – 强化学习的后悔

SHapley Additive exPlanations (SHAP)

模型可解释性和解释模型为何做出某些决策或预测在许多商业问题或行业中至关重要。使用前面讨论的技术，我们可以解释模型的表现，但仍有一些灰色区域，例如深度学习模型，这些是黑盒模型。一般来说，这些模型可以在测试数据上训练以实现很好的结果或准确性，但很难解释原因。在这种情况下，SHapley Additive exPlanations（SHAP）可以用来解码预测结果中发生的事情以及哪些特征预测与最重要的特征相关。SHAP 在本文（NIPS 会议）中提出：papers.nips.cc/paper/7062-a-unified-approach-to-interpreting-model-predictions。

SHAP 适用于分类和回归模型。SHAP 的主要目标是通过对每个特征的贡献进行计算来解释模型输出预测。SHAP 解释方法使用 Shapley 值来解释模型输出或预测的特征重要性。Shapley 值来自合作博弈论，这些值介于-1到1之间。Shapley 值描述了模型输出在特征之间的分布，如图 5.8 所示：

图 5.8 – 描述特征重要性的 Shapley 值条形图

有几种 SHAP 解释器技术，例如 SHAP 树解释器、SHAP 深度解释器、SHAP 线性解释器和 SHAP 内核解释器。根据用例，这些解释器可以为模型预测提供有用的信息，帮助我们理解黑盒模型。更多信息请参阅：christophm.github.io/interpretable-ml-book/shap.html

MIMIC 解释器

Mimic 解释器是一种通过训练一个可解释的全局代理模型来模仿黑盒模型的方法。这些训练好的全局代理模型是可解释模型，旨在尽可能准确地近似任何黑盒模型的预测。通过使用代理模型，可以对黑盒模型进行评估或解释，如下所示。

以下步骤用于训练代理模型：

1. 要训练一个代理模型，首先选择一个数据集 X。这个数据集可以是用于训练黑盒模型的同一个数据集，也可以是另一个具有相似分布的数据集，具体取决于用例。

2. 获取所选数据集 X 的黑盒模型预测。

3. 选择一个可解释模型类型（线性模型、决策树、随机森林等）。

4. 使用数据集 X 和其预测结果来训练可解释模型。

5. 现在你已经训练了一个代理模型。恭喜！

6. 评估代理模型再现黑盒模型预测的能力，例如，使用 R 平方或 F 分数。

7. 通过解释代理模型来理解黑盒模型的预测。

以下可解释模型可以用作代理模型：轻梯度提升模型（LightGBM）、线性回归、随机梯度下降或随机森林和决策树。

代理模型可以使机器学习解决方案开发者评估和理解黑盒模型的表现。

置换特征重要性解释器（PFI）

置换特征重要性（PFI）是一种用于解释分类和回归模型的技术。这项技术对于解释和理解特征与模型输出或预测的相关性非常有用。PFI 是 SHAP 的替代方案。它通过随机评估整个数据集中的一次特征，并计算性能评估指标的变化来实现。对每个特征的性能指标变化进行评估；变化越显著，该特征就越重要。

PFI 可以描述任何模型的整体行为，但并不解释模型的单个预测。PFI 是 SHAP 的替代方案，但两者仍有很大不同，因为 PFI 基于模型性能的下降，而 SHAP 基于特征归因的幅度。

统计模型指标

如我们在第二章“描述你的机器学习问题”中学习到的，存在三种类型的统计模型：归纳学习、演绎学习和转换学习。统计模型提供了良好的可解释性。

均值

均值，或平均值，是数据集的中心值。它是通过将所有值相加，然后除以值的数量来计算的：

均值 = x1 + x2 + x3 + ... + xn / n

标准差

标准差衡量数据集中值的分散程度。标准差越低，数据点就越接近均值。分布广泛的数据集会有更高的标准差。

偏差

偏差衡量了映射函数（自变量和因变量之间的映射）的强度（或刚性）。模型对映射函数功能形式的假设越强，偏差就越大。

当基础的真实（但未知）模型与映射函数的假设具有匹配属性时，高偏差是有帮助的。然而，如果基础模型没有表现出与映射功能形式相似的属性，你可能会完全偏离轨道。例如，当变量之间实际上具有高度非线性关系时，假设变量之间存在线性关系会导致不良拟合：

• 低偏差：对输入到输出映射的功能形式有弱假设

• 高偏差：对输入到输出映射的功能形式有强假设

偏差始终是正值。以下是一个关于机器学习偏差的更多学习资源的链接：kourentzes.com/forecasting/2014/12/17/the-bias-coefficient-a-new-metric-for-forecast-bias/。

方差

模型的方差是模型在拟合不同训练数据时的性能变化的程度。模型的具体影响通过方差来捕捉。

高方差模型会对训练数据集的微小变化产生很大变化。另一方面，低方差模型即使在训练数据集发生较大变化时也不会有太大变化。方差始终为正值。

R-squared

R-squared，也称为确定系数，衡量模型可以解释的因变量的变化。它是通过解释变异除以总变异来计算的。简单来说，R-squared 衡量数据点与拟合回归线之间的接近程度。

R-squared 的值介于0和1之间。R-squared 值低表示响应变量的大部分变化不是由模型解释的，而是由未包含在内的其他因素解释的。通常，你应该追求更高的 R-squared 值，因为这表明模型更好地拟合数据。

RMSE

均方根误差（RMSE）衡量模型预测值与观测（真实）值之间的差异。

选项很多，你需要选择正确的指标来对现实世界的生产场景进行有充分理由的评价；例如，为什么数据科学家或数据科学团队可能想要选择一个评估指标而不是另一个，例如，对于回归问题，选择 R-squared 而不是平均数。这取决于用例和数据类型。

HITL 模型指标

有两种类型的HITL模型——人类强化学习模型和主动学习模型。在这些模型中，人机协作促进算法模仿人类的行为和结果。这些机器学习解决方案的关键驱动因素是人在回路中。人类验证、标记和重新训练模型以保持模型的准确性。

人类偏差

就像人脑一样，机器学习系统也受到认知偏差的影响。人类的认知偏差是干扰你的决策和推理能力的过程，最终导致错误。人类的偏差包括刻板印象、选择性感知、从众效应、启动效应、确认偏误、观察选择偏差和投机者的错误观念。在许多情况下，为了避免这些偏差对于机器学习系统来说至关重要，以便做出理性和最优的决策。如果我们能够推断出人类的偏差并纠正它，这将使机器学习系统比人类更实用。这将在基于 HITL 的系统中将特别有用。使用偏差测试，可以识别并解决三种类型的人类偏差，以保持机器学习系统的决策不受人类偏差的影响。以下三种人类偏差如下：

交互偏差

当一个机器学习系统被喂入包含特定类型条目的数据集时，会引入一个交互偏差，这阻止算法识别任何其他类型的条目。这种偏差可以在训练模型的推理测试中识别出来。SHAP 和 PFI 等方法在识别特征偏差方面可能很有用。

潜在偏差

当训练集中有多个示例具有突出特征时，会体验到潜在偏差。然后，没有这种特征的示例未能被算法识别。例如，最近，亚马逊人力资源算法在根据公司内部角色的申请选择人员时，对女性存在偏见，原因是潜在偏差。

选择偏差

当分析数据的选择没有适当随机化时，算法中会引入选择偏差。例如，在设计高性能的人脸识别系统时，包括所有可能的面部结构和形状，以及来自所有种族和地理样本的数据至关重要，以避免选择偏差。可以通过 SHAP 或 PFI 等方法识别选择偏差，以观察模型特征偏差。

最佳策略

在人类强化学习的情况下，系统的目标是最大化当前状态的动作奖励。为了最大化动作的奖励，可以使用最佳策略作为衡量系统的指标。最佳策略是在当前状态下选择最大化奖励/回报的动作的策略。最佳策略是系统表现最佳的理想指标或状态。在基于人类强化学习的系统中，操作员或教师将最佳策略设置为系统的目标，即达到人类水平的表现。

自动化率

自动化是通过使用机器人或算法自动生产商品或完成任务的过程，无需直接人工辅助。

可以使用总任务的自动化率来计算 ML 系统的自动化程度。这基本上是系统完全自动化的任务百分比，这些任务不需要任何人工辅助。它显示了所有任务中完全自动化的任务百分比。例如，DeepMind 的 AlphaGo 实现了 100%的自动化，可以独立运行以击败人类世界冠军选手。

风险率

ML 模型执行错误的概率称为错误率。错误率是基于模型在生产系统中的性能计算的。错误率越低，对 ML 系统越好。人在回路的目标是降低错误率，并教会 ML 模型以最佳状态运行。

生产测试方法

由于运营着各种不同的企业，因此服务于这些企业的生产系统类型也各不相同。在本节中，我们将探讨常用的不同类型的生产系统或配置，以及如何测试它们。

批量测试

批量测试通过在一个与训练环境不同的环境中进行测试来验证您的模型。批量测试是在一组数据样本上进行的，以使用选择的指标（如准确率、RMSE 或 f1 分数）测试模型推理。批量测试可以在各种计算环境中进行，例如在云端、远程服务器或测试服务器上。模型通常以序列化文件的形式提供，文件被加载为对象并在测试数据上进行推理。

A/B 测试

你肯定遇到过 A/B 测试。它常用于服务设计（网站、移动应用等）和评估营销活动。例如，它用于评估特定的设计更改或针对特定受众定制内容是否对业务指标（如用户参与度、点击率或销售率）产生积极影响。类似的技术在 A/B 测试中测试机器学习模型时也得到应用。当使用 A/B 测试测试模型时，测试将回答以下重要问题：

• 新模型 B 在生产中是否比当前模型 A 工作得更好？

• 两个模型候选者中哪一个在产品中工作得更好，可以推动积极的业务指标？

为了评估 A/B 测试的结果，根据业务或操作使用统计技术来确定哪个模型在生产中表现更好。A/B 测试通常以这种方式进行，实时或实时数据被分割成两个集合，集合 A 和集合 B。集合 A 的数据被路由到旧模型，而集合 B 的数据被路由到新模型。为了评估新模型（模型 B）是否比旧模型（模型 A）表现更好，可以使用各种统计技术来评估模型性能（例如，准确率、精确率、召回率、f 分数和 RMSE），具体取决于业务用例或操作。根据模型性能与业务指标的相关性统计分析（业务指标的正向变化），做出决定，用旧模型替换新模型或确定哪个模型更好。

A/B 测试是通过统计假设检验有系统地进行的，这个假设验证了硬币的两面——零假设和备择假设。零假设断言新模型不会增加监控业务指标的平均值。备择假设断言新模型提高了监控业务指标的平均值。最终，A/B 测试用于评估新模型是否显著提升了特定的业务指标。根据业务用例和操作，A/B 测试有多种类型，例如Z-test、G-test（我建议了解这些以及其他类型），等等。选择正确的 A/B 测试和评估指标可以为您的业务和机器学习操作带来双赢。

阶段性测试或影子测试

在将模型部署到生产环境之前，这将导致做出业务决策，复制类似生产环境（预发布环境）以测试模型的性能可能是有价值的。这对于测试模型的鲁棒性和评估其在实时数据上的性能尤为重要。可以通过在预发布服务器上部署开发分支或待测试模型，并推断与生产流水线相同的数据来实现。唯一的缺点是最终用户将看不到开发分支的结果，或者在预发布服务器上不会做出业务决策。预发布环境的结果将使用合适的指标（例如，准确率、精确率、召回率、F 分数和 RMSE）进行统计评估，以确定模型与业务指标相关的鲁棒性和性能。

CI/CD 中的测试

将测试作为 CI/CD 流水线的一部分实施可以在自动化和评估（基于设定的标准）模型性能方面带来回报。CI/CD 流水线可以根据现有的操作和架构以多种方式设置，例如：

• 在成功运行机器学习流水线后，CI/CD 流水线可以在预发布环境中触发新模型的 A/B 测试。

• 当训练新模型时，将数据集与测试集分开以测量其对合适指标的绩效是有益的，并且这一步骤可以完全自动化。

• CI/CD 流水线可以定期在一天中的特定时间触发机器学习流水线，以训练新模型，该模型使用实时或实时数据来训练新模型或微调现有模型。

• CI/CD 流水线可以监控生产环境中部署的机器学习模型的性能，并且这可以通过基于时间的触发器或手动触发器（由负责质量保证的团队成员发起）来触发或管理。

• CI/CD 流水线可以为执行 A/B 测试在独特的数据集上提供两个或更多预发布环境，以进行更多样化和全面的测试。

这些是各种场景，根据需求，CI/CD 流水线提供各种工作流程和操作，以满足业务和技术需求。选择高效的架构和 CI/CD 流程可以增强技术操作和团队的整体表现。CI/CD 测试可以极大地增强和自动化测试。

为什么需要打包机器学习模型？

MLOps 使训练和评估模型的方法系统化。在模型训练和评估之后，下一步是将它们部署到生产环境中。众所周知，机器学习（ML）不像传统的软件工程那样是确定性的，在软件工程中，一段代码或模块被导入现有系统并运行。工程化机器学习解决方案是非确定性的，涉及提供机器学习模型进行预测或分析数据。

为了提供服务，它们需要被打包成软件工件，以便发送到测试或生产环境。通常，这些软件工件被打包成一个文件或一组文件或容器。这使得软件与环境无关，与部署无关。机器学习模型需要打包的原因如下：

可移植性

将机器学习模型打包成软件工件使它们能够从一个环境运输或传输到另一个环境。这可以通过发送一个文件或一组文件或一个容器来完成。无论哪种方式，我们都可以传输工件并在各种设置中复制模型。例如，打包的模型可以部署在虚拟机或无服务器设置中。

推理

机器学习推理是一个涉及使用机器学习模型处理实时数据以计算输出（例如，预测或数值分数）的过程。打包机器学习模型的目的在于能够实时提供服务以进行机器学习推理。有效的机器学习模型打包（例如，序列化模型或容器）可以促进部署，并将模型用于实时或批量预测和分析数据。

互操作性

机器学习模型的互操作性是指两个或多个模型或组件交换信息，并使用交换的信息相互学习或微调，以及以高效的方式执行操作的能力。交换的信息可以是数据或软件工件或模型参数。此类信息使模型能够根据其他软件工件的经验进行微调、重新训练或适应各种环境，以执行操作并提高效率。将机器学习模型打包是使机器学习模型互操作性的基础。

部署无关性

将机器学习模型打包成软件工件，如序列化文件或容器，使模型能够在各种运行时环境中运输和部署，例如在虚拟机、容器化无服务器环境、流服务、微服务或批量服务中。这为使用机器学习模型打包的相同软件工件提供了可移植性和部署无关性的机会。

如何打包机器学习模型

根据业务和技术需求以及机器学习的操作，机器学习模型可以以多种方式打包。机器学习模型可以通过以下子节中讨论的三种方式打包和发货。

序列化文件

序列化是打包机器学习模型的一个关键过程，因为它使得模型具有可移植性、互操作性以及模型推理能力。序列化是将对象或数据结构（例如，变量、数组和元组）转换为可存储的工件的方法，例如，转换为文件或内存缓冲区，可以传输或传输（跨计算机网络）。序列化的主要目的是在不同的环境中将序列化的文件重新构建为其之前的数据结构（例如，将序列化文件转换为机器学习模型变量）。这样，一个新训练的机器学习模型可以被序列化到一个文件中，并导出到新的环境中，在那里它可以反序列化为机器学习模型变量或数据结构，用于机器学习推理。序列化文件不保存或包含任何之前关联的方法或实现。它只保存数据结构在可存储的工件（如文件）中的状态。

下面是图 5.1中的一些流行的序列化格式：

表 5.1 – 流行的机器学习模型序列化格式

所有这些序列化格式（除了 ONNX）都存在一个共同问题，即互操作性问题。为了解决这个问题，ONNX 被开发为一个由微软、百度、亚马逊等大公司支持的开源项目。这使得一个模型可以使用一个框架（例如，在 scikit-learn 中）进行训练，然后再次使用 TensorFlow 进行重新训练。这对于工业化的 AI 来说是一个变革性的进步，因为模型可以变得可互操作和框架无关。

ONNX 解锁了新的途径，如联邦学习和迁移学习。序列化模型使得在不同环境中具有可移植性，并支持批量推理（批量推理或离线推理是在一组数据点或样本上生成预测的方法）。

数据打包或容器化

我们经常遇到各种生产系统的环境。在部署机器学习模型时，每个环境都会面临不同的挑战，包括兼容性、鲁棒性和可扩展性。通过标准化某些流程或模块，可以避免这些挑战，容器化是标准化机器学习模型和软件模块的绝佳方式。

容器是由代码及其所有依赖项组成的软件标准单元。它使得应用程序能够快速且可靠地在不同的计算环境中运行。它使得软件与环境无关、部署无关。容器由 Docker 管理和编排。Docker 已经成为开发和编排容器的行业标准。

Docker 是一个开源(opensource.com/resources/what-open-source)工具。它被开发出来，使得使用容器构建、部署和运行应用程序变得方便。通过使用容器，开发者可以将应用程序及其组件和模块（如文件、库和其他依赖项）打包成一个包，并部署它。容器是使用具有自定义设置的 Linux OS 运行应用程序的可靠方式。Docker 容器是通过 Dockerfile 构建的，Dockerfile 用于容器化应用程序。在构建 Docker 镜像后，会构建一个 Docker 容器。Docker 容器是一个以开发者编排的方式运行具有自定义设置的应用程序。图 5.8展示了从 Dockerfile 构建和运行 Docker 容器的过程。Dockerfile 被构建成一个 Docker 镜像，然后作为 Docker 容器运行：


图 5.9 – Docker 工件

Dockerfile、Docker 镜像和 Docker 容器是构建和运行容器的基石组件。这些组件的描述如下：

• Dockerfile：Dockerfile 是一个文本文件，其中包含了一组按开发者顺序排列的 Docker 命令，用于构建 Docker 镜像。Docker 能够读取 Dockerfile 并构建 Docker 镜像。

• Docker 镜像：这是在容器运行时在容器内的根文件系统中使用的一系列执行参数的有序集合。Docker 镜像就像是容器的快照。容器是由 Docker 镜像构建的。

• Docker 容器：容器是由 Docker 镜像构建的。容器是 Docker 镜像的运行时实例。

ML 模型可以在 Docker 容器中提供服务，以实现健壮性、可扩展性和部署无关性。在后续章节中，我们将使用 Docker 部署 ML 模型以获得实践经验，因此，了解这个工具是很重要的。

微服务的生成和部署

微服务使得独立部署的服务集合成为可能。这些服务每个都易于维护、测试和松散耦合。微服务通过围绕业务能力组织的架构进行编排，以使系统能够满足业务需求。例如，Spotify 已经从单体复杂系统过渡到基于微服务的系统。这是通过将复杂系统拆分为碎片化服务来实现的，具体目标包括搜索引擎、内容标记、内容分类、推荐引擎的用户行为分析以及自动生成的播放列表。碎片化的微服务现在由专门的团队开发。每个微服务都是隔离的，相互之间依赖较少。这样，开发和维护变得更加容易。公司可以保持客户服务的连贯性，并持续改进，而无需中断服务。

通常，通过将序列化文件定制为容器化的 Docker 镜像来生成微服务。这些 Docker 镜像可以随后部署并编排到任何支持 Docker 的环境中。可以使用容器管理工具，如 Kubernetes，来部署和管理 Docker 镜像。Docker 实现了极端的可移植性和互操作性，Docker 镜像可以轻松部署到任何流行的云服务，例如 Google Cloud、Azure 或 AWS。只要支持 Docker，Docker 镜像就可以部署和管理到任何 Docker 企业服务器或数据中心或实时环境中。

微服务可以以 REST API 格式提供服务，这是提供机器学习模型的一种流行方式。一些 Python 框架，如 Flask、Django 和 FastAPI，已成为使机器学习模型作为 REST API 微服务提供服务的流行选择。为了促进稳健和可扩展的系统操作，软件开发人员可以通过 REST API 与 Docker 化的微服务同步。为了在 Kubernetes 支持的基础设施上编排基于 Docker 的微服务部署，Kubeflow 是一个好的选择。它是云无关的，可以在本地或本地机器上运行。除此之外，Kubeflow 基于 Kubernetes，但将 Kubernetes 的细节和困难封装在一个盒子里。Kubeflow 是提供模型的一种稳健方式。这是一个值得探索的工具：www.kubeflow.org/docs/started/kubeflow-overview/。

准备好的推理模型

我们之前曾针对一个业务问题进行过预测港口天气的工作。为了解决这个业务问题，我们进行了数据处理和机器学习模型训练，然后序列化模型。现在，在本节中，我们将探讨如何在序列化模型上执行推理。本节的代码可在书籍 GitHub 仓库中对应章节的文件夹中附带的 Jupyter 笔记本中找到。以下是运行代码的说明：

1. 再次登录到 Azure 门户。

2. 从 MLOps_WS 工作区，然后点击 MLOps_WS 工作区。

3. 在 管理 部分，点击 计算 部分，然后选择在 第四章 中创建的机器，机器学习管道。点击 启动 按钮以启动实例。当虚拟机准备就绪时，点击 JupyterLab 链接。

4. 现在，在 JupyterLab 中，导航到章节对应的文件夹（05_model_evaluation_packaging）并打开笔记本（model_evaluation_packaging.ipynb）。

连接到工作区并导入模型工件

首先，我们导入必要的包，使用Workspace()函数连接到 ML 工作区，然后下载序列化的缩放器和模型以进行预测。Scaler将用于将输入数据缩放到与模型训练所使用的数据相同的尺度。Model文件以 ONNX 格式序列化。Scaler和Model文件都使用Model()函数导入：

import pandas as pd
import numpy as np
import warnings
import pickle
from math import sqrt
warnings.filterwarnings('ignore')
from azureml.core.run import Run
from azureml.core.experiment import Experiment
from azureml.core.workspace import Workspace
from azureml.core.model import Model
# Connect to Workspace
ws = Workspace.from_config()
print(ws)
# Load Scaler and model to test
scaler = Model(ws,'scaler').download(exist_ok=True)
svc_model = Model(ws,'support-vector-classifier').download(exist_ok=True)

运行此代码后，你将在 JupyterLab 窗口的左侧面板中看到下载的新文件。

加载推理模型工件

我们将Scaler和Model文件打开并加载到变量中，以便用于 ML 模型推理。Scaler使用 pickle 读取并加载到变量中，并使用InferenceSession()加载 ONNX 文件，以便进行 ML 模型预测，如下所示：

with open('scaler.pkl', 'rb') as file:
    scaler = pickle.load(file)
# Compute the prediction with ONNX Runtime
import onnxruntime as rt
import numpy
sess = rt.InferenceSession("svc.onnx")
input_name = sess.get_inputs()[0].name
label_name = sess.get_outputs()[0].name

ML 模型推理

要进行 ML 模型推理，使用fit_transform()方法缩放测试数据并设置推理。现在，使用 ONNX 会话对测试数据进行推理，通过传递输入数据test_data，以float 32格式运行sess.run()。最后，打印模型推理的结果：

test_data = np.array([34.927778, 0.24, 7.3899, 83, 16.1000, 1])
test_data = scaler.fit_transform(test_data.reshape(1, 6))
# Inference 
pred_onx = sess.run([label_name], {input_name: test_data.astype(numpy.float32)})[0]
print(pred_onx[0])

通过这些步骤，我们已经成功下载了序列化的模型，将其加载到变量中，并在测试数据样本上进行了推理。代码块预期的结果是值1。

摘要

在本章中，我们探讨了评估和解释 ML 模型的多种方法。我们学习了生产测试方法以及打包模型的重要性，为什么以及如何打包模型，以及用于生产中 ML 模型推理的打包模型的实用性和工具。最后，为了理解打包和解包序列化模型以进行推理的工作原理，我们通过在测试数据上使用序列化模型进行了 ML 模型推理的动手实现。

在下一章中，我们将学习更多关于部署您的 ML 模型的知识。系好安全带，准备好将您的模型部署到生产环境中！

第二部分：大规模部署机器学习模型

本节将解释机器学习模型部署的选项、方法和格局。我们将深入探讨由持续集成、交付和部署方法所支持的某些生产部署的基本方面。你还将获得设计和发展健壮且可扩展的微服务和 API 以服务于你的机器学习解决方案的见解。

本节包括以下章节：

• 第六章，部署你的机器学习系统关键原则

• 第七章，构建健壮的 CI/CD 管道

• 第八章，API 和微服务管理

• 第九章，测试和保障你的机器学习解决方案

• 第十章，生产发布要素

第六章：部署您的机器学习系统的主要原则

在本章中，您将学习在生产中部署 机器学习（ML）模型的基本原则，并实施针对我们一直在研究的业务问题的机器学习模型的实际部署。为了获得全面的理解和第一手经验，我们将使用 Azure ML 服务在两个不同的部署目标上部署之前训练和打包的机器学习模型（在 第四章，机器学习管道，和 第五章，模型评估和打包)。

我们还将学习如何使用我们之前已经使用过的开源框架 MLflow 来部署机器学习模型。这将使您能够了解如何使用两种不同的工具（Azure ML 服务和 MLflow）将机器学习模型作为 REST API 端点部署到不同的部署目标。这将使您具备在云上部署任何给定场景的机器学习模型所需的技能。

在本章中，我们首先探讨研究生产和实施机器学习（ML）的不同之处，并继续探讨以下主题：

• 研究与生产中的机器学习

• 理解生产中机器学习推理的类型

• 通过映射您的解决方案的基础设施

• 实际部署（针对业务问题）

• 理解持续集成和持续部署的需求

研究与生产中的机器学习

研究中的机器学习具有特定的目标和优先级，旨在提高该领域的最先进水平，而生产中的机器学习的目的是优化、自动化或增强某个场景或业务。

为了理解机器学习模型的部署，让我们首先比较研究生产和实施（在工业界）中机器学习的实现方式。如 表 6.1 所列出的多个因素，例如性能、优先级、数据、公平性和可解释性，描述了部署和机器学习在研究和生产中的不同之处：

表 6.1 – 研究与生产中的机器学习

数据

通常情况下，研究项目中的数据是静态的，因为数据科学家或统计学家正在处理一个固定的数据集，并试图超越当前的最先进模型。例如，最近在自然语言处理模型方面取得了许多突破，例如谷歌的 BERT 或百度的 XLNet。为了训练这些模型，数据被抓取并编译成静态数据集。在研究界，为了评估或基准测试模型的性能，使用静态数据集来评估性能，如 表 6.2 所示（来源：arxiv.org/abs/1906.08237)：

表 6.2 – BERT 与 XLNet 在研究中的性能比较

例如，我们可以通过比较两个模型在名为 SQUAD（10,000+ QnA）版本 1.1 的流行数据集上的性能来比较它们的性能，在这个数据集上 BERT 的准确率为 92.8%，XLNET 的准确率为 94.0%。同样，用于研究和训练、评估模型的数据是静态的，而生产或工业用例中的数据是动态的，并且根据环境、操作、业务或用户不断变化。

公平性

在现实生活中，有偏见的模型可能会造成高昂的代价。不公平或偏见的决策会导致商业和运营的糟糕选择。对于生产中的机器学习模型，确保做出的决策尽可能公平是非常重要的。如果生产中的模型不公平，这可能会给企业带来高昂的成本。例如，最近，亚马逊推出了一款基于求职者适合其申请工作的程度进行筛选的人力资源筛选软件。亚马逊的机器学习专家发现，男性候选人比女性候选人更受青睐（来源：www.businessinsider.com/amazon-ai-biased-against-women-no-surprise-sandra-wachter-2018-10）。这种系统偏见可能会造成高昂的代价，因为在亚马逊的案例中，由于偏见可能会错失一些杰出的人才。因此，在生产中拥有公平的模型至关重要，并且应该持续监控。在研究中，公平的模型也很重要，但不如生产或现实生活中那么关键，而且公平性不像在生产中那样受到严格的监控。研究的目标是超越现有技术，而模型公平性是一个次要目标。

可解释性

在生产中，模型的可解释性至关重要，以便理解机器学习模型的决策与其对运营或业务影响之间的相关性或因果关系，从而优化、增强或自动化业务或手头的任务。在研究中并非如此，研究的目标是挑战或超越最先进的结果，这里的重点是更好的性能（如准确度或其他指标）。在研究的情况下，机器学习模型的可解释性是好的，但不是强制性的。通常，机器学习项目更关注预测结果，而不是理解因果关系。机器学习模型擅长在数据中找到相关性，但不是因果关系。我们努力避免在我们的项目中将关联等同于原因。由于这个问题，我们依赖机器学习的能力受到了严重阻碍。这个问题严重限制了我们的能力，使我们无法使用机器学习来做出决策。我们需要能够理解数据之间因果关系的资源，并构建可以从业务角度很好地泛化的机器学习解决方案。拥有正确的模型可解释性机制可以增强我们对因果关系的理解，并使我们能够制定出泛化良好且能够处理以前未见数据的机器学习解决方案。因此，我们可以使用机器学习做出更可靠和透明的决策。

在生产（在商业用例中）的情况下，完全不推荐缺乏可解释性。让我们看看一个假设的案例。假设你患有癌症，需要选择一位外科医生进行手术。有两位外科医生可供选择，一位是人类（治愈率为 80%），另一位是 AI 黑盒模型（治愈率为 90%），该模型无法被解释或解释其工作原理，但它有很高的治愈率。你会选择哪个？AI 还是外科医生来治愈癌症？如果模型不是黑盒模型，用 AI 替换外科医生会更容易。尽管 AI 比外科医生更好，但没有理解模型，决策、信任和合规就会成为问题。模型的可解释性对于做出法律决策至关重要。因此，对于生产中的机器学习来说，拥有模型的可解释性至关重要。我们将在后面的章节中了解更多关于这方面的内容。

性能

当涉及到机器学习模型的性能时，研究中的重点是改进最先进的模型，而在生产中，重点是构建比简单模型更好的模型，以满足业务需求（最先进的模型不是重点）。

优先级

在研究中，优先级是更快、更好地训练模型，而在生产中，优先级是更快地进行推理，因为重点是实时做出决策并满足业务需求。

理解生产中机器学习推理的类型

在上一节中，我们看到了机器学习在研究和生产中的优先级。为了在生产中满足业务需求，根据需要使用各种部署目标来推断机器学习模型。使用机器学习模型进行预测或做出决策称为机器学习模型推理。让我们探讨在不同部署目标上部署机器学习模型的方法，以根据业务需求促进机器学习推理。

部署目标

在本节中，我们将探讨不同的部署目标类型，以及为什么以及如何在这些部署目标上为推理服务机器学习模型。让我们首先看看虚拟机或本地服务器。

虚拟机

虚拟机可以是云上的，也可以是本地的，这取决于企业或组织的 IT 配置。在虚拟机上服务机器学习模型相当常见。机器学习模型以网络服务的形式在虚拟机上提供服务。运行在虚拟机上的网络服务接收包含输入数据的用户请求（作为 HTTP 请求）。在接收到输入数据后，网络服务将其预处理为所需的格式，以推断网络服务中的机器学习模型。在机器学习模型做出预测或执行任务后，输出被转换并以用户可读的格式呈现。通常为JavaScript 对象表示法（JSON）或可扩展标记语言字符串（XML）。通常，网络服务以 REST API 的形式提供服务。可以使用多种工具开发 REST API 网络服务；例如，可以使用 Python 或 Java 中的 Spring Boot 或 R 中的 Plumber 开发 REST API 网络服务，具体取决于需求。使用虚拟机的组合并行使用以扩展和维持网络服务的健壮性。

为了编排流量并扩展机器，使用负载均衡器将传入的请求调度到虚拟机以进行机器学习模型推理。这样，机器学习模型被部署在云或本地的虚拟机上，以满足业务需求，如下面的图所示：

![图 6.1 – 虚拟机上的部署![图 6.1 – 虚拟机上的部署图 6.1 – 虚拟机上的部署### 容器容器是使用 Linux 操作系统并带有自定义设置来运行应用程序的可靠方式。容器是由开发者编排的应用程序，运行时具有自定义设置。与虚拟机相比，容器是服务模型的一种替代方案，并且更节省资源。容器像虚拟机一样运行，因为它们拥有自己的运行时环境，该环境是隔离的，并且限制在内存、文件系统和进程内。开发者可以自定义容器，将它们限制在所需的资源上，如内存、文件系统和处理过程，而虚拟机则限于这些自定义。它们更灵活，以模块化方式操作，因此提供更高的资源效率和优化。它们允许扩展到零，因为容器可以减少到零副本，并在请求时运行备份。这样，与在虚拟机上运行 Web 服务相比，可以实现更低的计算能力消耗。由于这种较低的计算能力消耗，在云上可以实现成本节约。容器具有许多优点；然而，一个缺点可能是与容器一起工作的复杂性，因为它需要专业知识。容器和虚拟机在操作方式上存在一些差异。例如，虚拟机内部可以运行多个容器，这些容器与虚拟机共享操作系统和资源，但虚拟机运行自己的资源和操作系统。容器可以模块化操作，而虚拟机则以单一单元操作。Docker 用于构建和部署容器；然而，还有其他替代方案，如 Mesos 和 CoreOS rkt。容器通常与 ML 模型和 Web 服务打包在一起，以方便 ML 推理，类似于我们在虚拟机中用 Web 服务包装 ML 模型来提供服务。容器需要被编排才能被用户使用。容器的编排意味着部署、管理、扩展和网络自动化的自动化。容器使用容器编排系统（如 Kubernetes）进行编排。在以下图中，我们可以看到具有自动扩展（基于请求流量）的容器编排：

图 6.2 – 容器部署

无服务器

无服务器计算，正如其名所示，不涉及虚拟机或容器。它消除了基础设施管理任务，如操作系统管理、服务器管理、容量配置和磁盘管理。无服务器计算使开发者和组织能够专注于核心产品，而不是管理服务器等日常任务，无论是在云上还是在本地。无服务器计算通过使用云原生服务来实现。

例如，Microsoft Azure 使用 Azure Functions，AWS 使用 Lambda 函数来部署无服务器应用程序。无服务器应用程序的部署涉及提交一组文件（以.zip文件的形式）以运行机器学习应用程序。通常，.zip 存档包含一个特定的函数或方法来执行。该存档通过云服务上传到云平台，并作为无服务器应用程序部署。部署的应用程序作为 API 端点，用于向提供机器学习模型的无服务器应用程序提交输入。

使用无服务器应用程序部署机器学习模型可以带来许多优势：无需安装或升级依赖项，也无需维护或升级系统。无服务器应用程序按需自动扩展，并且在整体性能上非常稳健。无服务器函数同时支持同步操作（执行在一个序列中依次发生，A->B->C->D）和异步操作（并行或基于优先级执行，不按顺序：A->C->D->B 或 A 和 B 并行，C 和 D 并行）。然而，也存在一些缺点，例如云资源可用性，如 RAM 或磁盘空间或 GPU 不可用，这对于运行深度学习或强化学习等重型模型可能是关键要求。例如，如果我们没有使用无服务器操作部署模型，我们可能会遇到资源限制的瓶颈。部署的模型或应用程序不会自动扩展，从而限制可用的计算能力。如果用户对模型或应用程序的推理超过了限制，我们将遇到资源不可用的障碍。在以下图中，我们可以看到传统应用程序和无服务器应用程序的开发方式：

图 6.3：传统与无服务器部署对比

要开发无服务器应用程序，开发者只需关注应用程序的逻辑，无需担心后端或安全代码，这些在部署无服务器应用程序时由云服务负责处理。

模型流

模型流是一种用于处理流数据的模型服务方法。流数据没有开始或结束。每秒钟，都有来自数千个来源的数据产生，并且必须尽快进行处理和分析。例如，谷歌搜索结果必须实时处理。模型流是部署机器学习模型（ML）的另一种方式。它相较于其他模型服务技术，如 REST API 或批量处理方法，有两个主要优势。第一个优势是异步性（一次处理多个请求）。REST API 机器学习应用稳健且可扩展，但它们有一个限制，即同步性（它们根据客户请求的先后顺序处理请求），这可能导致高延迟和资源利用率。为了应对这一限制，流处理是可用的。它本质上是异步的，因为用户或客户不需要协调或等待系统处理请求。

流处理能够异步处理并即时为用户提供服务。为了做到这一点，流处理使用消息代理来接收来自用户或客户端的消息。消息代理允许数据即时到达，并将处理分散到时间上。消息代理解耦了传入的请求，并促进了用户或客户端与服务之间的通信，而无需了解彼此的操作，如图 5.4 所示。对于消息流代理有几个选项，例如 Apache Storm、Apache Kafka、Apache Spark、Apache Flint、Amazon Kinesis 和 StreamSQL。您选择的工具取决于 IT 设置和架构。

![图 6.4 – 模型流过程

]

图 6.4 – 模型流过程

流处理的第二个优势在于，当在机器学习系统中进行多个模型推断时。对于单模型或双模型处理，REST API 非常出色，但当需要推断多个模型时，它们会产生延迟并使用大量的计算资源，而且它们还限于同步推断。

在多个模型的情况下，流处理是一个好的选择，因为所有运行 ML 系统所需的模型和工件（代码和文件）都可以打包在一起，并部署在流处理引擎上（它在自己的机器集群上运行并管理数据处理的资源分配）。

例如，让我们看看智能电子邮件助手的使用案例，该助手的任务是自动化客户服务，如图 5.4 所示。为了自动化回复以服务其用户，电子邮件助手系统使用多个模型进行多次预测：

• 预测电子邮件的类别，例如垃圾邮件或账户或续订

• 意图识别

• 情感预测

• 回答/文本生成

在 REST API 端点部署的这四个模型将产生高延迟和维护成本，而流式服务是一个很好的替代方案，因为它可以将多个模型打包为一个进程，并以流的形式持续服务用户请求。因此，在这种情况下，建议使用流式服务而不是 REST API 端点。

映射我们的解决方案的基础设施

在本节中，我们映射基础设施需求以及部署目标，以解决多样化的业务需求，如表 6.3所示：

![Table 6.3 – Mapping the infrastructure for ML solutions

![img/Table_6.3.jpg]

表 6.3 – 映射 ML 解决方案的基础设施

根据您的用例，建议选择合适的基础设施和部署目标，以服务于 ML 模型，以产生业务或运营影响。

手动部署（针对业务问题）

在本节中，我们将学习如何部署我们一直在工作的业务问题的解决方案。到目前为止，我们已经完成了数据处理、ML 模型训练、序列化模型并将它们注册到 Azure ML 工作区。在本节中，我们将探讨如何在容器和自动扩展集群上对序列化模型进行推理。这些部署将为您提供广泛的理解，并为您未来的任务做好准备。

我们将使用 Python 作为主要的编程语言，并使用 Docker 和 Kubernetes 来构建和部署容器。我们将从在 Azure 容器实例上部署 REST API 服务开始，使用 Azure ML。接下来，我们将使用 Kubernetes（用于容器编排）在自动扩展集群上部署 REST API 服务，并使用 Azure ML，最后，我们将使用 MLflow 和开源 ML 框架在 Azure 容器实例上部署；这样，我们将学习如何使用多个工具并在云（Azure）上部署 ML 模型。让我们从Azure 容器实例（ACI）的部署开始。

在 ACI 上部署模型

要开始部署，请访问之前在 Azure DevOps 上克隆的 GitHub 存储库（在第三章，代码与数据），访问名为06_ModelDeployment的文件夹，并按照01_Deploy_model_ACI.ipynb笔记本中的实现步骤进行操作：

1. 我们首先导入所需的包，并检查 Azure ML SDK 的版本，如下面的代码所示：

   %matplotlib inline
   import numpy as np
   import matplotlib.pyplot as plt
   import azureml.core
   from azureml.core import Workspace
   from azureml.core.model import Model
   # display the core SDK version number
   print("Azure ML SDK Version: ", azureml.core.VERSION)
   

   上述代码将打印出 Azure ML SDK 的版本（例如，1.10.0；您的版本可能不同）。

2. 接下来，使用 Azure ML SDK 中的workspace函数，我们连接到 ML 工作区，并使用工作区的Model函数下载之前训练的所需序列化文件和模型。序列化的scaler和model用于执行推理或预测。Scaler将用于将输入数据缩小到与模型训练中使用的数据相同的规模，而model文件用于对传入的数据进行预测：

   ws = Workspace.from_config()
   print(ws.name, ws.resource_group, ws.location, sep = '\n')
   scaler = Model(ws,'scaler').download(exist_ok=True)
   model = Model(ws,'support-vector-classifier').download(exist_ok=True)
   

3. 在下载了 scaler 和 model 文件之后，下一步是准备 scoring 文件。scoring 文件用于在 Azure 容器实例和 Kubernetes 集群中部署的 ML 服务中推断 ML 模型。scoring 脚本接受用户传入的输入，推断预测用的 ML 模型，然后将预测结果以服务的形式提供给用户。它包含两个主要函数，init() 和 run()。我们首先导入所需的库，然后定义 init() 和 run() 函数：

   %%writefile score.py
   import json
   import numpy as np
   import os
   import pickle
   import joblib
   import onnxruntime
   import time
   from azureml.core.model import Model
   

   %%writefile score.py 将此代码写入名为 score.py 的文件中，该文件随后作为 ML 服务的一部分打包到容器中，以执行 ML 模型推理。

4. 我们定义了 init() 函数；它下载所需的模型并将它们反序列化到变量中，以便用于预测：

   def onnxruntime we can deserialize the support vector classifier model. The InferenceSession() function is used for deserializing and serving the model for inference, and the input_name and label_name variables are loaded from the deserialized model.  
   

5. 简而言之，init() 函数加载文件（model 和 scaler），反序列化并提供用于预测所需的模型和工件文件，这些文件由 run() 函数如下使用：

   def run() function takes raw incoming data as the argument, performs ML model inference, and returns the predicted result as the output. When called, the run() function receives the incoming data, which is sanitized and loaded into a variable for scaling. The incoming data is scaled using the scaler loaded previously in the init() function. Next, the model inference step, which is the key step, is performed by inferencing scaled data to the model, as shown previously. The prediction inferred from the model is then returned as the output. This way, the scoring file is written into score.py to be used for deployment.
   

6. 接下来，我们将继续部署服务到 Azure 容器实例的关键部分。为此，我们通过创建环境 myenv.yml 来定义部署环境，如下所示。使用 CondaDependencies() 函数，我们列出需要在作为 ML 服务部署的 Docker 容器中安装的所有 pip 包。例如，numpy、onnxruntime、joblib、azureml-core、azureml-defaults 和 scikit-learn 等包在触发环境文件时会在容器中安装：

   from azureml.core.conda_dependencies import CondaDependencies 
   myenv = CondaDependencies.create(pip_packages=["numpy", "onnxruntime", "joblib", "azureml-core", "azureml-defaults", "scikit-learn==0.20.3"])
   with open("myenv.yml","w") as f:
       f.write(myenv.serialize_to_string())
   

7. 接下来，我们使用 InferenceConfig() 函数定义推理配置，该函数在被调用时以 score.py 和环境文件作为参数。然后，我们调用 AciWebservice() 函数在 aciconfig 变量中初始化计算配置（cpu_cores 和 memory），如下所示：

   from azureml.core.model import InferenceConfig
   from azureml.core.environment import Environment
   myenv = Environment.from_conda_specification(name="myenv", file_path="myenv.yml")
   inference_config = InferenceConfig(entry_script="score.py", environment=myenv)
   from azureml.core.webservice import AciWebservice
   aciconfig = AciWebservice.deploy_configuration(cpu_cores=1, 
   memory_gb=1, 
   tags={"data": "weather"}, 
   description='weather-prediction')
   

8. 现在我们已经准备好在 ACI 上部署 ML 或 Web 服务了。我们将使用 score.py、环境文件（myenv.yml）、inference_config 和 aci_config 来部署 ML 或 Web 服务。我们需要指向要部署的模型或工件。为此，我们使用 Model() 函数从工作区加载 scaler 和 model 文件，并准备好它们以供部署：

   %%time
   from azureml.core.webservice import Webservice
   from azureml.core.model import InferenceConfig
   from azureml.core.environment import Environment
   from azureml.core import Workspace
   from azureml.core.model import Model
   ws = Workspace.from_config()
   model1 = Model(ws, 'support-vector-classifier')
   model2 = Model(ws, 'scaler')
   service = Model.deploy(workspace=ws, 
                          name='weatherprediction', 
                          models=[model1, model2], 
                          inference_config=inference_config, 
                          deployment_config=aciconfig)
   service.wait_for_deployment(show_output=True)
   

9. 在将模型挂载到变量 model1 和 model2 之后，我们继续将它们作为 Web 服务部署。我们使用 deploy() 函数在 ACI 上部署挂载的模型，如前述代码所示。这个过程大约需要 8 分钟，所以拿好爆米花，享受服务部署的过程吧。你会看到如下信息：

   Running..............................................................................
   Succeeded
   ACI service creation operation finished, operation "Succeeded"
   CPU times: user 610 ms, sys: 103 ms, total: 713 ms
   Wall time: 7min 57s
   

   恭喜！你已经成功使用 MLOps 部署了你的第一个 ML 服务。

10. 让我们检查已部署服务的运行机制和鲁棒性。查看服务 URL 和 Swagger URL，如下面的代码所示。您可以使用这些 URL 实时对您选择的输入数据进行 ML 模型推断：

    print(service.scoring_uri)
    print(service.swagger_uri)
    

11. 在 Azure ML 工作区中检查已部署的服务。

12. 现在，我们可以通过使用 Azure ML SDK 的service.run()函数并传递一些输入数据来测试该服务，如下所示：

    import json
    test_sample = json.dumps({'data': [[34.927778, 0.24, 7.3899, 83, 16.1000, 1016.51, 1]]})
    test_sample = bytes(test_sample,encoding = 'utf8')
    prediction = Temperature_C, Humidity, Wind_speed_kmph, Wind_bearing_degrees, Visibility_km, Pressure_millibars, and Current_weather_condition. Encode the input data in UTF-8 for smooth inference. Upon inferring the model using service.run(), the model returns a prediction of 0 or 1. 0 means a clear sky and 1 means it will rain. Using this service, we can make weather predictions at the port of Turku as tasked in the business problem.
    

13. 我们部署的服务是一个 REST API 网络服务，我们可以通过以下 HTTP 请求进行推断：

    import requests
    headers = {'Content-Type': 'application/json', 'Accept': 'application/json'}
    if service.auth_enabled:
        headers['Authorization'] = 'Bearer '+ service.get_keys()[0]
    elif service.token_auth_enabled:
        headers['Authorization'] = 'Bearer '+ service.get_token()[0]
    scoring_uri = service.scoring_uri
    print(scoring_uri)
    response = requests.post(scoring_uri, data=test_sample, headers=headers)
    print(response.status_code)
    print(response.elapsed)
    print(response.json())
    

    当通过传递输入数据发出POST请求时，服务以0或1的形式返回模型预测。当你得到这样的预测时，你的服务正在运行，并且足够鲁棒，足以满足生产需求。

    接下来，我们将该服务部署在自动扩展的集群上；这对于生产场景来说非常理想，因为部署的服务可以自动扩展并满足用户需求。

在 Azure Kubernetes Service (AKS)上部署模型

要开始部署，请转到 Azure DevOps 上克隆的 Git 仓库中的第三章，代码与数据相遇，访问06_ModelDeployment文件夹，并按照02_Deploy_model_AKS.ipynb笔记本中的实现步骤进行操作：

1. 如前一小节所述，首先导入所需的包，例如matplotlib、numpy和azureml.core，以及从azureml.core导入的所需函数，例如Workspace和Model，如下面的代码块所示：

   %matplotlib inline
   import numpy as np
   import matplotlib.pyplot as plt
   
   import azureml.core
   from azureml.core import Workspace
   from azureml.core.model import Model
   # display the core SDK version number
   print("Azure ML SDK Version: ", azureml.core.VERSION)
   

2. 打印 Azure ML SDK 的版本并检查版本（例如，它将打印1.10.0；您的版本可能不同）。使用配置文件和Workspace函数连接到您的空间，如下面的代码块所示：

   ws = Workspace.from_config()
   print(ws.name, ws.resource_group, ws.location, sep = '\n')
   scaler = Model(ws,'scaler').download(exist_ok=True)
   model = Model(ws,'support-vector-classifier').download(exist_ok=True)
   

3. 下载model和scaler文件，就像我们之前做的那样。在下载了model和scaler文件之后，下一步是准备scoring文件，该文件用于推断与 ML 服务一起部署的容器中的 ML 模型。scoring脚本接受用户传递的输入，推断用于预测的 ML 模型，然后将预测结果以输出形式提供给用户。我们将首先导入所需的库，如下面的代码块所示：

   %%writefile score.py
   import json
   import numpy as np
   import os
   import pickle
   import joblib
   import onnxruntime
   import time
   from azureml.core.model import Model
   

4. 如我们之前为 ACI 部署创建score.py一样，我们将使用相同的文件。它包含两个主要函数，init()和run()。我们定义init()函数；它下载所需的模型并将它们反序列化为用于预测的变量：

   def init():
       global model, scaler, input_name, label_name
       scaler_path = os.path.join(os.getenv('AZUREML_MODEL_DIR'), 'scaler/2/scaler.pkl')
       # deserialize the model file back into a sklearn model
       scaler = joblib.load(scaler_path)
   
       model_onnx = os.path.join(os.getenv('AZUREML_MODEL_DIR'), 'support-vector-classifier/2/svc.onnx')
       model = onnxruntime.InferenceSession(model_onnx, None)
       input_name = model.get_inputs()[0].name
       label_name = model.get_outputs()[0].name
   

5. 正如我们在上一节关于 ACI 部署中做的那样，通过使用onnxruntime包函数，我们可以反序列化支持向量机分类器模型。《InferenceSession()函数用于反序列化和为推理提供模型，input_name和label_name变量从反序列化的模型中加载。简而言之，init()函数加载文件（model和scaler），并反序列化和提供用于预测的模型和工件文件，这些文件由run()`函数使用：

   def run(raw_data):
                   try: 
                       data = np.array(json.loads(raw_data)['data']).astype('float32')
                       data = scaler.fit_transform(data.reshape(1, 7))
                       # make prediction
                       model_prediction = model.run([label_name], {input_name: data.astype(np.float32)})[0]
                       # you can return any data type as long as it is JSON-serializable
   
                   except Exception as e:   
                       model_prediction = 'error'
   
                   return model_prediction
   

   我们将使用之前在在 ACI 上部署模型部分中使用的相同的run()函数进行 AKS 部署。这样我们就可以继续在 AKS 上部署服务。

6. 接下来，我们将进行部署服务在CondaDependencies()函数中的关键部分。我们将提及需要在部署为机器学习服务的 Docker 容器中安装的所有pip和conda包。例如numpy、onnxruntime、joblib、azureml-core、azureml-defaults和scikit-learn在触发environment文件时在容器中安装。接下来，使用 Microsoft Container Registry 中公开可用的容器，无需任何身份验证。该容器将安装您的环境，并配置为部署到您的目标 AKS：

   from azureml.core import Environment
   from azureml.core.conda_dependencies import CondaDependencies 
   conda_deps = CondaDependencies.create(conda_packages=['numpy','scikit-learn==0.19.1','scipy'], pip_packages=["numpy", "onnxruntime", "joblib", "azureml-core", "azureml-defaults", "scikit-learn==0.20.3"])
   myenv = Environment(name='myenv')
   myenv.python.conda_dependencies = conda_deps
   # use an image available in public Container Registry without authentication
   myenv.docker.base_image = "mcr.microsoft.com/azureml/o16n-sample-user-base/ubuntu-miniconda"
   

7. 现在，通过使用InferenceConfig()函数定义推理配置，该函数在被调用时接受score.py和环境变量作为参数：

   from azureml.core.model import InferenceConfig
   inf_config = InferenceConfig(entry_script='score.py', environment=myenv)
   

8. 现在我们已经准备好在 Azure Kubernetes Service（自动扩展集群）上部署机器学习或 Web 服务。为了做到这一点，我们需要创建一个 AKS 集群并将其附加到 Azure ML 工作区。为您的集群选择一个名称，并使用ComputeTarget()函数检查它是否存在。如果不存在，将使用ComputeTarget.create()函数创建或配置一个集群。创建集群需要以下参数：工作区对象ws；服务名称；以及用于创建集群的配置文件。我们使用默认参数创建默认集群：

   %%time
   from azureml.core.compute import ComputeTarget
   from azureml.core.compute_target import ComputeTargetException
   from azureml.core.compute import AksCompute, ComputeTarget
   # Choose a name for your AKS cluster
   aks_name = 'port-aks' 
   # Verify that cluster does not exist already
   try:
       aks_target = aks_name = port-aks) already exists, a new cluster will not be created. Rather, the existing cluster (named port-aks here) will be attached to the workspace for further deployments.
   

9. 接下来，我们进行部署机器学习服务在 Kubernetes 集群中的关键任务。为了部署，我们需要一些先决条件，例如将模型挂载到部署中。我们使用Model()函数将scaler和model文件从工作区加载，并准备好它们以供部署，如下面的代码所示：

   from azureml.core.webservice import Webservice, 
   AksWebservice
   # Set the web service configuration (using default here)
   aks_config = AksWebservice.deploy_configuration()
   %%time
   from azureml.core.webservice import Webservice
   from azureml.core.model import InferenceConfig
   from azureml.core.environment import Environment
   from azureml.core import Workspace
   from azureml.core.model import Model
   ws = Workspace.from_config()
   model1 = Model(ws, 'support-vector-classifier')
   model2 = Model(ws, 'scaler')
   

10. 现在我们已经准备好在 AKS 上部署服务。我们使用 Azure ML SDK 中的Model.deploy()函数来部署服务，该函数在被调用时接受工作区对象ws；service_name；models；inference_config；deployment_config；和deployment_target作为参数：

    %%time
    aks_service_name ='weatherpred-aks'
    aks_service = Model.deploy (workspace=ws,
                               name=aks_service_name,
                               models=[model1, model2],
                               inference_config=inf_config,
                               deployment_config=aks_config,
                               deployment_target=aks_target)
    aks_service.wait_for_deployment(show_output = True)
    print(aks_service.state)
    

    部署该服务大约需要 10 分钟左右。部署机器学习服务后，你将收到如下消息：

    Running........................ Succeeded AKS service creation operation finished, operation "Succeeded"
    

    恭喜！现在您已经在 AKS 上部署了一个机器学习服务。让我们使用 Azure ML SDK 来测试它。

11. 我们使用 service.run() 函数将数据传递到服务并获取预测，如下所示：

    import json
    test_sample = json.dumps({'data': [[34.927778, 0.24, 7.3899, 83, 16.1000, 1016.51, 1]]})
    test_sample = bytes(test_sample,encoding = 'utf8')
    prediction = service.run(input_data=test_sample)
    

12. 部署的服务是一个 REST API 网络服务，可以通过以下 HTTP 请求进行访问：

    import requests
    headers = {'Content-Type': 'application/json', 'Accept': 'application/json'}
    if service.auth_enabled:
        headers['Authorization'] = 'Bearer '+ service.get_keys()[0]
    elif service.token_auth_enabled:
        headers['Authorization'] = 'Bearer '+ service.get_token()[0]
    scoring_uri = service.scoring_uri
    print(scoring_uri)
    response = requests.post(scoring_uri, data=test_sample, headers=headers)
    print(response.status_code)
    print(response.elapsed)
    print(response.json())
    

    当通过传递输入数据发出 POST 请求时，服务以 0 或 1 的形式返回模型预测。当您获得这样的预测时，您的服务正在运行，并且能够稳健地满足生产需求。服务根据用户的请求流量从 0 缩放到所需的容器副本数。

使用 MLflow 部署服务

最后，让我们使用 MLflow 在部署目标（ACI）上部署一个机器学习服务，以获得使用开源框架的实际操作经验。要开始，请访问之前在 Azure DevOps 上克隆的 Git 仓库（在 第三章，代码遇见数据），访问名为 06_ModelDeployment 的文件夹，并按照 02_Deploy_model_MLflow.ipynb 笔记本中的实现步骤进行操作。在实施之前，建议阅读此文档以了解 mlflow.azureml SDK 背后的概念：docs.microsoft.com/en-us/azure/machine-learning/how-to-use-mlflow#deploy-and-register-mlflow-models。

1. 我们首先导入所需的包，并检查 Azure ML SDK 的版本，如下面的代码块所示：

   import numpy as np
   import mlflow.azureml 
   import azureml.core
   # display the core SDK version number
   print("Azure ML SDK Version: ", azureml.core.VERSION)
   

2. 接下来，使用 Azure ML SDK 中的 workspace 函数，我们连接到机器学习工作区，并使用 set_tracking_uri 设置工作区的跟踪 URI：

   from azureml.core import Workspace
   from azureml.core.model import Model
   ws = Workspace.from_config()
   print(ws.name, ws.resource_group, ws.location, sep = '\n')
   mlflow.set_tracking_uri(ws.get_mlflow_tracking_uri())
   

3. 现在，请转到工作区，从 models 或 experiments 部分获取 mlflow 模型的路径并设置该路径：

   from azureml.core.webservice import AciWebservice, Webservice
   # Set the model path to the model folder created by your run 
   model_path = "model path"
   

4. 现在，我们已经准备好使用 mlflow 和 azureml SDK 将模型部署到 ACI。使用 deploy_configuration 函数配置 ACI 部署目标，并使用 mlflow.azureml.deploy 函数将模型部署到 ACI。deploy 函数在被调用时接受 model_uri、workspace、model_name、service_name、deployment_config 和自定义标签作为参数：

   # Configure 
   aci_config = AciWebservice.deploy_configuration
   (cpu_cores=1, 
   memory_gb=1, 
   tags={'method' : 'mlflow'}, 
   description='weather pred model',
   location='eastus2')
   # Deploy on ACI
   (webservice,model) = mlflow.azureml.deploy(model_uri=
   'runs:/{}/{}'.format(run.id, model_path), workspace=ws, 
   model_name='svc-mlflow', service_name='port-weather-pred', deployment_config=aci_config, tags=None, mlflow_home=None, synchronous=True)
   webservice.wait_for_deployment(show_output=True)
   

部署成功后，您将收到一条部署成功的消息。有关 MLflow 部署的更多详细信息，请参考以下示例：docs.microsoft.com/en-us/azure/machine-learning/how-to-use-mlflow#deploy-and-register-mlflow-models。

恭喜！您已使用 azureml 和 mlflow 在多种部署目标上部署了机器学习模型，例如 ACI 和 AKS。

接下来，我们将专注于通过持续集成和持续部署将 MLOps 的全部功能呈现出来，以便在生产中拥有一个强大且动态发展的系统。

理解持续集成和持续部署的需求

持续集成（CI）和持续部署（CD）使 ML 服务能够实现持续交付。目标是维护和版本控制用于模型训练的源代码，启用触发器以并行执行必要的作业，构建工件，并将它们发布以部署到 ML 服务。几个云服务提供商提供了 DevOps 服务，可用于监控 ML 服务、生产中的 ML 模型，以及与云中其他服务的编排。

使用 CI 和 CD，我们可以实现持续学习，这对于 ML 系统的成功至关重要。没有持续学习，ML 系统注定会以失败的PoC（概念验证）告终。我们将在下一章深入探讨 CI/CD 的概念，并实施动手的 CI 和 CD 管道，以看到 MLOps 的实际应用。

摘要

在本章中，我们学习了在生产中部署 ML 模型的关键原则。我们探讨了各种部署方法和目标及其需求。为了全面理解和动手实践，我们实现了部署，以了解 ML 模型是如何在多种部署目标上部署的，例如虚拟机、容器和自动扩展集群。有了这些，你就可以应对任何类型的部署挑战。

在下一章中，我们将深入探讨利用 CI（持续集成）和 CD（持续部署）构建、部署和维护健壮的 ML（机器学习）服务的秘诀。这将实现 MLOps（机器学习运维）的潜力！让我们深入探讨。

第七章：构建健壮的 CI/CD 管道

在本章中，你将了解 MLOps 管道中的持续操作。本章中你将学习的原则对于在业务环境中推动持续部署至关重要。为了获得全面的理解和第一手经验，我们将同时探讨概念和动手实施。在学习持续集成（CI）和持续部署（CD）、管道测试以及发布和触发器类型的同时，我们将为测试环境设置 CI/CD 管道。这将使你具备在云上为任何给定场景自动部署具有持续学习能力机器学习（ML）模型所需的技能，并与业务保持一致。让我们首先看看为什么我们需要在 MLOps 中使用 CI/CD。接下来，我们将继续探讨以下其他主题：

• MLOps 中的持续集成、交付和部署

• 设置 CI/CD 管道和测试环境（使用 Azure DevOps）

• 管道执行和测试

• 管道执行触发器

MLOps 中的持续集成、交付和部署

自动化是 MLOps 工作流程中 CI/CD 的主要原因。启用持续向 ML 服务交付的目标是维护模型的数据和源代码版本，启用触发器并行执行必要的作业，构建工件，并发布生产部署。一些云服务提供商正在推广 DevOps 服务以监控生产中的 ML 服务和模型，以及与云上的其他服务进行编排。使用 CI 和 CD，我们可以启用持续学习，这对于 ML 系统的成功至关重要。没有持续学习，ML 系统被认为最终会以失败的概念验证（PoC）告终。

只有部署了持续学习能力模型的模型才能带来商业价值。

为了学习如何使用持续学习能力在生产中部署模型，我们将探索 CI、CD 和持续交付方法。

如你在图 7.1中看到的，CI 是 CD 和持续交付的关键。让我们看看这三个是如何相互关联的：

图 7.1 – 持续集成、交付和部署管道

持续集成

CI（持续集成）旨在实时同步应用程序（机器学习管道和应用程序）与开发者。开发者在提交或合并中的更改将通过创建应用程序构建和针对构建执行自动化测试来得到验证。CI 强调自动化测试，重点关注在将新提交合并到主分支或主分支时检查应用程序的健壮性（如果它没有损坏或出现错误）。每当向主分支提交新的提交时，就会创建一个新的构建版本，并使用自动化测试对其进行健壮性测试。通过自动化此过程，我们可以避免软件延迟交付和其他可能导致用户等待数天的集成挑战。自动化和测试是 CI 的核心。

持续交付

持续交付从 CI 扩展，以确保新的更改或发布被部署并高效地带给用户；这通过自动化测试和发布流程来实现。自动化测试和发布流程使开发者和产品经理能够通过一键操作部署更改，并在过程的任何阶段实现无缝控制和监督能力。在持续交付过程中，通常会有一个人工代理（来自质量保证团队）参与批准构建（通过或失败），在将其部署到生产环境中之前（如图 7.1 所示，在持续交付管道中）。在一个典型的持续交付管道中，构建在部署到预发布阶段之前会经过初步的验收测试，在这个阶段，人工代理会使用烟雾测试和其他合适的测试来监督性能。

一旦通过了烟雾测试，人工代理会将构建版本传递到生产环境中部署。自动化构建和发布流程，并让人工代理参与其中，可以确保生产质量，我们还可以避免一些在完全自动化管道中可能被忽视的陷阱。使用持续交付，企业可以对其发布流程拥有完全的控制权，并可以分批次（在出现阻塞或错误时易于调试）发布新的构建版本，或者在一个必要的时间框架内（每日、每周或每月）进行完整发布。

持续部署

CD（持续部署）实现了完全自动化，并且比持续交付更进一步。将构建和发布到生产环境的所有阶段都完全自动化，没有任何人工干预，这与持续交付不同。在这样的自动化管道中，只有失败的测试才能阻止新的更改部署到生产环境中。持续部署减轻了团队维护发布管道的压力，并加速了直接向客户部署，通过客户反馈循环实现持续学习。

通过这样的自动化，开发者不再有发布日。这减轻了他们的压力，他们可以专注于构建软件，而无需担心测试和发布管理。开发者可以在方便的时候构建、测试和部署软件，可以在几分钟内上线，而不是等待发布日或人工审批，这可能会延迟软件向用户发布几天甚至几周。持续部署确保了部署和服务的完全自动化，向用户提供强大且可扩展的软件。

设置 CI/CD 管道和测试环境（使用 Azure DevOps）

在上一节中，我们介绍了 CI、持续交付和持续部署的理论，现在是时候看到它在实践中是如何应用的。使用 Azure DevOps，我们将为之前一直在工作的业务问题（天气预测）设置一个简单的 CI/CD 管道，我们之前在 第六章 的“关键部署原则”部分（针对业务问题）中已经讨论过。

Azure DevOps 是由微软提供的一项服务，它简化了源代码管理（版本控制）、项目管理、CI（持续集成）、持续交付和持续部署（自动化构建、测试和发布功能）。它还使软件应用程序的生命周期管理成为可能。我们将使用 Azure DevOps 进行实战培训，因为它与 Azure ML 服务无缝集成，我们之前在 第六章 中已经使用过。您将体验这两种服务的集成和同步，以便轻松进行部署。让我们开始吧。

前往您的 Azure DevOps 项目，Learn_MLOps。进入克隆的仓库并访问 07_CICD_Pipeline 文件夹。我们将使用这些文件（在名为 07_CICD_Pipeline 的文件夹中）作为驱动程序来构建发布管道：

Learn_MLOps
├──07_CICD_Pipeline
│   ├── AciDeploymentconfig.yml
    ├── AksDeploymentconfig.yml
    └── InferenceConfig.yml
    └── myenv.yml
    └── score.py

我们将在两个部署目标上部署之前训练的 ML 模型（来自 第四章，机器学习管道），一个是 AciDeployment.yml 文件包含 ACI 部署目标的配置，另一个是 AksDeployment.yml 文件包含 AKS 集群的配置。InferenceConfig.yml 指向推理工件，如 score.py 和 myenv.yml。

在 score.py 中定义的函数将用于预处理传入的数据，并使用 ML 模型推断预处理后的数据以进行预测。myenv.yml 文件是推理环境的配置，例如，环境中的 Python 版本和要安装的包。这些文件将用作驱动程序，以简化发布管道。现在您已经熟悉了这些文件，让我们开始通过使用服务主体连接 Azure ML 服务和 Azure DevOps 项目。

创建服务主体

我们需要同步 Azure ML 服务和 Azure DevOps，以便在两者之间方便地进行 CI。之前（在 第四章，机器学习管道）我们使用 Azure ML 服务开发和管理工作流模型，并使用了 Learn_MLOps 工作区。现在，我们将使用服务主体将 Azure ML 工作区（命名为 Learn_MLOps）与 Azure DevOps 项目（命名为 Learn_MLOps）连接起来。

服务主体是为应用程序间通信创建的标识；它是访问 Azure 资源的连接自动化工具。服务主体还负责应用程序的网络和连接方面。执行以下步骤来设置用于管道的服务主体：

1. 前往项目设置（位于屏幕左下角）并选择服务连接。点击新建服务连接选项/按钮以显示新建服务连接窗口，如图 图 7.2 所示：![图 7.2 – 新的服务主体连接

   ![img/B16572_07_02.jpg]

   图 7.2 – 新的服务主体连接

2. 选择Azure 资源管理器作为连接类型，然后点击下一步。选择服务主体（自动）并继续创建服务主体的最后一步。

3. 您将提示创建新的服务连接。将范围设置为机器学习工作区并指向订阅、资源组和机器学习工作区，如图 图 7.3 所示：![图 7.3 – 创建服务主体的最后一步

   ![img/B16572_07_03.jpg]

   图 7.3 – 创建服务主体的最后一步

4. 在 mlops_sp 中命名服务主体，如图 图 7.3 所示）。最后，勾选复选框（授予所有管道访问权限）并点击保存以创建服务主体。

这样，具有给定名称（例如，mlops_sp）的服务主体就准备好用于编排 CI/CD 管道。接下来，我们将安装用于管道的扩展。

安装扩展以连接到 Azure ML 工作区

微软开发了一个名为 Machine Learning 的扩展。它在 Azure DevOps 市场 place 中可用。它用于编排我们所需的 Azure ML 工作区中的模型和工件。它允许我们将工作区中的模型部署到我们想要的部署目标，如 ACI 或 AKS。我们将安装 ML 扩展并使用它来编排 CI/CD 管道。执行以下步骤来安装扩展：

1. 前往市场以查找机器学习扩展。要进入市场，点击屏幕右上角的购物袋图标，如图 图 7.4 所示：![图 7.4 – 查找 Azure DevOps 市场 place

   ![img/B16572_07_04.jpg]

   图 7.4 – 查找 Azure DevOps 市场 place

   进入市场后，您将看到多个扩展选项，可以添加到您的 Azure DevOps 项目中。接下来，我们将搜索机器学习扩展。

2. 搜索机器学习扩展，免费安装扩展。点击免费获取按钮，如图图 7.5所示安装扩展：

![图 7.5 – 安装机器学习扩展

图 7.5 – 安装机器学习扩展

点击免费获取按钮后，将安装机器学习扩展。安装成功后，您可以使用机器学习扩展在 CI/CD 管道中编排作业。具备这些先决条件后，您就可以配置持续部署或持续交付管道。

为测试环境设置持续集成和部署管道

在本节中，我们将为预发布环境（也称为测试环境）配置 CI/CD 管道。我们将使用此管道促进持续学习和自动化部署。让我们按照图 7.6所示，通过管道>>发布开始操作：

![图 7.6 – 设置您的 CI/CD 管道

图 7.6 – 设置您的 CI/CD 管道

在Port Weather ML Pipeline中创建一个新的管道。接下来，我们将开始连接必要的工件以启用管道，例如包含代码的仓库和包含要部署的模型的 Azure ML 工作区。

将工件连接到管道

连接到您的 Azure DevOps 仓库。Azure DevOps 仓库作为中央代码仓库，用于在 Azure DevOps 上协调部署和操作。因此，让我们将仓库（Learn_MLOps）连接到发布管道：

1. 如图 7.7所示，转到Learn_MLOps以连接到发布管道：![图 7.7 – 将 Azure DevOps 仓库作为工件连接

   图 7.7 – 将 Azure DevOps 仓库作为工件连接

2. 在工件部分选择默认分支（例如，Learn_MLOps）和图标。

3. 连接到您的 Azure ML 工作区。要将您的 Azure ML 工作区连接到发布管道，请转到之前在第四章中注册的scaler工件，机器学习管道，以使用标准缩放传入数据：![图 7.8 – 将缩放器作为工件连接

   图 7.8 – 将缩放器作为工件连接

4. 在选择model_scaler工件后，通过点击model_scaler工件将其添加到发布管道中，你将能够在support_vector_classifier模型中看到模型名称（model_scaler）和模型图标。首先点击mlops_sp并选择在第四章，机器学习流水线中训练的support_vector_classifier模型。通过点击添加按钮将模型工件添加到管道中：

![图 7.9 – 连接的工件

![img/B16572_07_09.jpg]

图 7.9 – 连接的工件

在添加support_vector_classifier模型后，你将在工件部分看到模型名称（support_vector_classifier）和模型图标，如图图 7.9所示。

恭喜！我们已经将三个所需的工件（Learn_MLOps、scaler和support_vector_classifier）连接到发布管道中。我们可以使用这些工件来编排管道中的部署。接下来，准备好配置 Staging/TEST 环境！

设置测试环境

让我们在管道中为 TEST 环境设置一个持续集成和持续部署流水线。在这个阶段，我们测试服务的鲁棒性并执行各种测试以验证服务对生产的准备情况：

1. 要开始，点击DEV TEST。我们将该阶段命名为DEV TEST，因为这将是我们的开发和测试环境。理想情况下，DEV 和 TEST 是不同的阶段，但为了简单和避免重复实现，我们将它们合并。请参阅以下图 7.10：![图 7.10 – 设置 DEV TEST 阶段

   ![img/B16572_07_10.jpg]

   图 7.10 – 设置 DEV TEST 阶段

2. 在命名阶段后，通过点击顶部的保存按钮保存阶段。每个阶段都是由一系列步骤或作业组成的，用于检查阶段的鲁棒性。接下来，我们将配置DEV TEST阶段内的作业。简单来说，CI/CD 作业是一个执行或测试部署（例如，在 Kubernetes 集群上部署模型的作业）的过程或脚本。要配置作业，点击DEV TEST阶段中的1 作业，0 任务链接，如图图 7.11所示：![图 7.11 – 配置 DEV TEST 作业

   ![img/B16572_07_11.jpg]

   图 7.11 – 配置 DEV TEST 作业

   在点击DEV TEST阶段的1 作业，0 任务链接后，你必须添加代理作业。

3. 通过点击AzureML 模型部署将任务添加到代理作业中，如图图 7.12所示：![图 7.12 – 添加作业 – AzureML 模型部署

   ![img/B16572_07_12.jpg]

   图 7.12 – 添加作业 – AzureML 模型部署

   添加inferenceconfig文件后。

4. 接下来，您将被提示输入部署信息。如图 图 7.13 所示，指向您的 Azure ML 工作区（例如，mlops_ws）并将 模型源 选项设置为 模型工件（因为我们正在使用之前在训练和打包模型时生成的模型工件）：

图 7.13 – 添加作业 – Azure ML 模型部署

接下来，我们将查看 inferenceConfig 文件及其功能。以下代码片段来自 inferenceConfig.yml（在仓库中）。以下是 inferenceConfig.yml 的快照：

inferenceConfig.yml

entryScript: score.py
runtime: python
condaFile: myenv.yml

它表示我们将部署模型的自定义环境的设置。它指向 score.py 文件（在 第六章，部署您的 ML 系统的关键原则）和 conda 文件 myenv.yml，该文件定义了 conda 环境（要安装的包和依赖项）。以下是 myenv.yml 的快照：

myenv.yml

name: project_environment
dependencies:
  # The python interpreter version.
  # Currently Azure ML only supports 3.5.2 and later.
- python=3.6.2
- pip:
  - numpy
  - onnxruntime
  - joblib
  - azureml-core~=1.10.0
  - azureml-defaults~=1.10.0
  - scikit-learn==0.20.3
  - inference-schema
  - inference-schema[numpy-support]
  - azureml-monitoring
channels:
- anaconda
- conda-forge

score.py 和 myenv.yml 文件都与 inferenceConfig.yml 文件相关联，以简化机器学习模型的部署和推理。按照图 图 7.14 所示，选择您的推理配置文件（inferenceConfig.yml）：

图 7.14 – 选择您的推理配置文件

在您的 Azure DevOps 仓库中指向 inferenceConfig.yml 文件后，您的部署基本配置已完成。最后，我们将通过指向 AciDeploymentConfig.yml) 为 ACI 配置部署信息：

AciDeploymentConfig.yml

computeType: ACI
containerResourceRequirements:
    cpu: 1
    memoryInGB: 1
authEnabled: False
sslEnabled: False
appInsightsEnabled: True

它包含为部署提供所需计算的基础设施定义，例如 CPU 单位、内存（以 GB 计）以及其他身份验证或安全定义。让我们选择此部署配置文件以设置预发布环境的发布管道，如图 图 7.15 所示：

图 7.15 – 添加部署信息

添加部署配置文件后，通过点击屏幕右上角的 保存 按钮保存作业，然后转到 管道 >> 发布（位于您的屏幕左侧）以查看您的管道成功设置。让我们从这里继续测试管道。

管道执行和测试

现在，是时候测试您的管道了。为此，我们将创建一个发布版本并验证管道发布是否成功执行。以下步骤将帮助您测试您的管道：

1. 点击 创建发布 按钮以执行管道上配置的作业。屏幕右侧将出现一个弹出窗口（如图 图 7.16 所示），用于查看和选择在预发布环境中部署的工件。

2. 选择工件（_scaler和_support-vector-classifier）并选择它们的版本。为了简单起见，推荐两个都使用版本 1。

   如果你想选择模型或缩放器的另一个版本，请确保在score.py文件中更改你的模型和缩放器的路径（即在scaler和model路径model-scaler/{版本号}/modelscaler.pkl和support-vector-classifier/{版本号}/svc.onnx中插入适当的版本号。如果你选择版本 1，你不需要担心更改score.py文件中的代码，因为路径包含版本 1。

3. 在选择工件和所需版本（推荐版本 1）后，点击创建按钮以创建所选工件的发布：

   图 7.16 – 创建发布

4. 现在，发布管道（CI/CD 管道）被触发执行。管道中定义的所有步骤都将执行，例如下载工件、为部署提供 ACI 计算实例以及部署 Web 服务。在成功执行后，你将在发布上收到一个绿色的勾号通知，如图 7.17 所示：

   图 7.17 – 监控发布

5. 你可以在scaler和_support-vector-classifier中监控所有你的发布，它们已作为 Web 服务部署在 ACI 上，如图 7.18 所示：

   图 7.18 – 发布中的成功作业（测试环境）

6. 最后，前往检查你的 Azure ML 工作区（从端点部分），查看已部署的 Web 服务，如图 7.19 所示：

图 7.19 – 部署在 Azure ML 工作区的 Web 服务

我们已在测试环境中成功部署了一个 Web 服务。我们可以看到 REST 端点和服务名称devtest-webservice。这标志着测试环境的 CI/CD 管道构建和测试的成功完成。管道可以通过触发器驱动，在下一节中，我们将探讨触发器的类型以及如何使用它们构建最优的 CI/CD 管道。

管道执行触发器

在一个有效的 CI/CD 管道中，通过多种事件或触发器执行流程应该是可能的。只有通过常规事件（如代码仓库或推送或拉取请求）触发管道的选项可能会成为系统的障碍或限制。通过使用多个事件触发管道流程的选项可以增强 CI/CD 管道的灵活性和功能性。让我们看看一些可以增加 CI/CD 管道流程价值的触发器类型：

• Artifactory 触发器

  在管道和开发过程的各个阶段都会生成工件。生成的工件，如训练好的模型、元数据、上传的 Docker 镜像或任何已上传的文件，都可以触发在 CI/CD 管道中执行某个过程。拥有这样的选项可以为 CI/CD 管道提供极大的灵活性和功能性。

• Docker Hub 触发器

  每当你将新的 Docker 镜像推送到你选择的 Docker Hub 仓库时，CI/CD 管道中的触发器可以按照需求执行。例如，当你将新的 Docker 镜像上传到 Docker Hub（或 Azure 容器注册表）时，管道被触发以部署 Docker 镜像作为 Web 服务。

• 计划触发器

  管道过程可以按照特定的时间表触发。这种类型的触发器对于计划清理、cron 作业或任何需要按时间间隔运行的流程非常有用；例如，每天中午 12:00 重新训练 ML 模型的触发器。

• 在开发者的平台上进行 retrain，管道可以被触发以重新训练现有的已部署模型。这些触发器是通过 API 调用来实现的。

• Git 触发器

  Git 触发器通常用于触发管道执行，例如当新代码提交到分支或创建新的拉取请求时。当对仓库进行更改时，可以根据需求在管道中触发某些过程。

Azure DevOps 提供了多种触发选项（以上所有选项）。现在，让我们基于对仓库提交的 Git 提交来设置一个 Git 触发器：

1. 前往屏幕右上角的 编辑（Edit）来编辑现有的管道。

2. 点击仓库工件（命名为 _Learn_MLOps），如图 图 7.20 所示，并通过点击切换开关启用（启用）持续部署触发器。

3. 通过包含 develop 分支添加分支过滤器。这将触发管道在仓库的 develop 分支上发生更改或提交时执行。对于测试或预发布阶段，只为 develop 分支配置 Git 触发器（而不是 master 或其他分支）。对于生产，我们可以为 master 分支配置 Git 触发器。这样，我们可以为测试和生产阶段分离 Git 触发器分支：![图 7.20 – 启用测试环境的 Git 触发器

   ![img/B16572_07_20.jpg]

   图 7.20 – 启用测试环境的 Git 触发器

4. 点击顶部的 保存 按钮来配置 Git 触发器。恭喜！您已成功为测试环境设置了一个持续部署 Git 触发器。每当仓库的 develop 分支有更改时，管道将被触发以在测试（DEV TEST）环境中部署 Web 服务。

摘要

在本章中，我们学习了 MLOps 中持续操作的关键原则，主要是持续集成、交付和部署。我们通过在 Azure DevOps 上设置 CI/CD 管道和测试环境的实际操作来学习这一点。我们测试了管道的执行稳健性，并最终探讨了增强管道功能的一些触发器，并为测试环境设置了 Git 触发器。本章是 MLOps 持续操作的基础，并为您提供了在云上自动化部署任何给定场景的 ML 模型部署管道的技能，这些技能与您的业务持续学习能力相匹配。

在下一章中，我们将探讨 API、微服务和它们为基于 MLOps 的解决方案提供的功能。

第八章：API 和微服务管理

在本章中，你将了解 API 和微服务管理。到目前为止，我们已经部署了作为 API 提供服务的 ML 应用程序。现在我们将探讨如何开发、组织、管理和提供 API。你将学习 API 和微服务设计的原理，以便你可以设计自己的定制 ML 解决方案。

在本章中，我们将通过构建使用 FastAPI 和 Docker 的微服务并将其作为 API 提供服务来实践学习。为此，我们将学习设计用于之前训练的 ML 模型（在第四章，机器学习管道）的 API 和微服务的基础知识。最后，我们将反思一些关键原则、挑战和技巧，以设计一个健壮且可扩展的微服务和 API，用于测试和生产环境。本章将涵盖以下主题：

• API 和微服务的介绍

• ML 对微服务的需求

• 旧的是金子 - 基于 REST API 的微服务

• 实践实现将 ML 模型作为 API 提供服务

• 使用 Docker 开发微服务

• 测试 API 服务

API 和微服务的介绍

API 和微服务是强大的工具，有助于使你的ML（ML）模型在生产或遗留系统中变得有用，用于提供模型或与系统的其他组件进行通信。使用 API 和微服务，你可以设计一个健壮且可扩展的 ML 解决方案，以满足你的业务需求。让我们看看 API 和微服务是什么，以及它们如何实现你的模型在现实世界中的潜力。

什么是应用程序编程接口（API）？

API是开发者与应用程序通信的网关。API 使开发者能够实现两件事：

• 访问应用程序的数据

• 使用应用程序的功能

通过访问和与应用程序数据和功能进行通信，API 已经使世界的电子设备、应用程序和网页能够相互通信，以便共同完成以业务或运营为中心的任务。

![图 8.1 – API 的工作原理

![img/B16572_08_01.jpg]

图 8.1 – API 的工作原理

在图 8.1中，我们可以看到 API 的作用，它使得访问应用程序数据（来自数据库）以及与第三方或其他应用程序（如移动应用程序[为移动用户]，天气应用程序[在移动或网页上]，电动汽车等）进行通信成为可能。API 自计算机诞生以来一直在运行，旨在实现应用程序间的通信。随着时间的推移，我们在 21 世纪初看到了开发者就简单对象访问协议（SOAP）和表示状态转换（REST）等协议达成共识。近年来，一代新的 API 协议类型被开发出来，如远程过程调用（RPC）和 GraphQL，如下表所示：

表 8.1 – API 协议比较

如果你是应用开发者（托管在云端或与其他服务进行通信），了解主流的 API 协议是非常有价值的。这有助于你根据你的业务或功能需求来设计你的 API。作为一名程序员，你应该感到幸运，因为现在你有许多 API 协议可供选择，而在 20 年前，只有 SOAP 和 REST 可用。现在，根据你的需求，你可以选择各种协议，例如 GraphQL、Thrift 和 JSON-RPC。这些协议各有优缺点，使得找到最适合你情况的协议变得容易。

微服务

微服务是一种现代的设计和部署应用程序以运行服务的方式。微服务使分布式应用程序成为可能，而不是一个大的单体应用程序，其中功能被分解成更小的片段（称为微服务）。微服务是微服务架构中的一个独立应用程序。这与集中式或单体架构相反，在集中式或单体架构中，所有功能都绑定在一个大应用程序中。由于面向服务的架构（SOA）的出现，微服务因其作为传统单体（单一且自给自足）应用程序的替代方案而越来越受欢迎。

微服务因其使开发者能够轻松地开发、集成和维护应用程序而得到了广泛的应用。最终，这归结于这样一个事实：单个功能被独立对待，最初允许你逐步开发服务的一个单独功能。最后，它允许你在整合整个系统以协调服务的同时，独立地工作在每个功能上。这样，你可以添加、改进或修复它，而不会风险破坏整个应用程序。对于大型公司来说，微服务非常有价值，因为它们允许团队在没有复杂组织的情况下独立工作。在图 8.2中，我们可以看到单体和微服务之间的区别。与单体（非分布式应用程序）相比，微服务使分布式应用程序成为可能：

图 8.2 – 微服务与单体架构

软件开发团队被赋予了独立工作和在明确的服务责任范围内工作的能力。基于微服务的架构鼓励软件开发团队对其服务或模块负责。基于微服务的架构的一个可能的缺点是，如果你将应用程序分解成部分，那么这些部分之间需要有效地沟通，以便保持服务的运行。

API 与微服务之间的关系非常有趣，因为它有两个方面。由于基于微服务的架构，API 是你在应用程序中实施该架构的直接结果。同时，API 是微服务架构中服务之间高效通信的必要工具。让我们看看下一节，我们将浏览一些机器学习应用的示例。

机器学习对微服务的需求

为了了解基于微服务的架构对于机器学习应用的需求，让我们看看一个假设用例，并探讨开发该用例的机器学习应用的各个阶段。

假设用例

一个大型汽车维修设施需要一个解决方案来估计设施中的汽车数量及其准确位置。在维修站安装了一堆 IP 摄像头以监控设施。设计一个机器学习系统来监控和管理汽车维修设施。

第 1 阶段 – 概念验证（单体）

在典型情况下，通过使用可用数据点和应用机器学习来展示和验证用例，并向业务利益相关者证明机器学习可以解决他们的问题或改善他们的业务，快速开发了一个 PoC。

在我们的假设用例中，开发了一个单体 Python 应用程序，执行以下操作：

• 从所有摄像头获取流

• 从每个摄像头确定汽车的位置（头部或尾部）

• 将所有估计汇总到设施状态估计器

我们可以在图 8.3中看到，应用程序已经容器化并部署到服务器上：

![图 8.3 – 单体机器学习应用（假设用例的 PoC）

![图 8.3 – 单体机器学习应用（假设用例的 PoC）所有摄像头都通过本地网络连接到这台服务器。汽车位置估计算法和设施状态估计器正在工作，但需要进一步改进，总体上 PoC 是有效的。由于摄像头、本地网络和其他错误的不稳定性，这个单体应用程序非常容易崩溃。微服务可以更好地处理这种不稳定性。让我们在第二阶段看看实际情况。## 第 2 阶段 – 生产（微服务）在这个阶段，一个不太容易崩溃的应用程序对于持续运行汽车维修设施的监控操作至关重要。因此，将单体应用程序替换为如图 8.4所示基于微服务的架构：![图 8.4 – 微服务（假设用例的生产就绪应用程序）

图 8.4 – 微服务（假设用例的生产就绪应用程序）

应用程序以下列方式分解为多个服务：

• 视频流收集器。

• 图像处理器：此处理器汇总图像 – 它接收、处理和缓存图像，并为进一步处理生成数据包。

• 位置分类器：估计停放在维修设施中的汽车的位置（头部或尾部）。

• 设施设置估算器：它异步接收汽车位置估算并校准设施设置，然后将实时数据发送到云端。

• 云使用 MQTT（一种标准轻量级、发布/订阅网络协议，用于在设备之间传输消息）收集和存储数据。数据在仪表板上呈现，供汽车设施操作员分析操作。

所有微服务之间的通信都通过 API 进行。微服务架构的优势在于，如果任何服务崩溃或发生错误，将启动特定的微服务来替换失败的服务，以保持整个服务的运行。其次，每个微服务都可以由一个专门的团队（数据科学家、开发人员和 DevOps 工程师）持续维护和改进，而不是协调团队来工作于一个单体系统。

旧的就是好的 – 基于 REST API 的微服务

旧的就是好的。此外，最好从有各种 API 协议的地方开始。多年来，表示状态转移（REST）协议已成为许多应用的黄金标准，对于今天的机器学习应用来说也并不那么不同。大多数公司更倾向于基于 REST API 协议开发他们的机器学习应用。

REST API 或 RESTful API 基于 REST，这是一种用于主要是 Web 服务开发的架构方法。

RESTful API 被广泛使用；例如，亚马逊、谷歌、领英和推特等公司都在使用它们。通过 RESTful API 提供我们的机器学习模型有许多好处，例如以下：

• 为多个用户提供即时预测服务。

• 向负载均衡器后面的应用程序添加更多实例以进行扩展。

• 可能需要使用不同的 API 端点来组合多个模型。

• 将我们的模型操作环境与用户界面环境分开。

• 启用基于微服务的架构。因此，团队可以独立工作以开发和增强服务。

RESTful API 使用由 RFC 2616 协议定义的现有 HTTP 方法。表 8.2总结了 HTTP 方法及其在机器学习应用中的 CRUD 操作和目的。

表 8.2 – REST API HTTP 方法

基本的 HTTP 方法有GET、POST、PUT、PATCH和DELETE。这些方法对应于创建、读取、更新和删除。使用这些方法，我们可以开发 RESTful API 来服务机器学习模型。由于 OpenAPI 等驱动因素，RESTful API 得到了广泛的应用。OpenAPI 规范是一种标准化的 REST API 描述格式。它已成为人类和机器的标准格式；它使 REST API 易于理解，并提供了扩展的工具，如 API 验证、测试和交互式文档生成器。在实践中，OpenAPI 文件使您能够描述整个 API，包括以下关键信息：

• 可用端点（/names）以及每个端点的操作（GET /names，POST /names）

• 每个操作的输入和输出（操作参数）

• 认证方法

• 开发者文档

• 使用条款、许可和其他信息

您可以在此网站上了解更多关于 OpenAPI 的信息：swagger.io/specification/.

在下一节中，我们将开发一个 RESTful API 来提供 ML 模型，并使用基于 OpenAPI 的界面 Swagger UI 进行测试。

实践操作：将 ML 模型作为 API 提供服务

在本节中，我们将应用之前学到的 API 和微服务原则（在API 和微服务简介部分中），并开发一个 RESTful API 服务来提供 ML 模型。我们将提供的 ML 模型是之前我们工作的业务问题（使用 ML 进行天气预测）。我们将使用 FastAPI 框架将模型作为 API 提供服务，并使用 Docker 将 API 服务容器化为微服务。

FastAPI 是一个用于部署 ML 模型的框架。它易于编码且速度快，具有异步调用和数据完整性检查等特性，可实现高性能。FastAPI 易于使用，遵循 OpenAPI 规范，使其易于测试和验证 API。更多关于 FastAPI 的信息请访问：fastapi.tiangolo.com/.

API 设计和开发

我们将开发 API 服务并在本地计算机上运行它。（这也可以在我们在 Azure 机器学习工作区中创建的虚拟机上开发。为了学习，建议在本地练习以便于操作。）

要开始，请在您的 PC 或笔记本电脑上克隆本书的仓库，并转到08_API_Microservices文件夹。我们将使用这些文件来构建 API 服务：

Learn_MLOps
├──08_API_Microservices
│   ├── Dockerfile
    ├── app
            └── variables.py
            └── weather_api.py
            └── requirements.txt
            └── artifacts
                       └── model-scaler.pkl
                       └── svc.onnx

文件夹08_API_Microservices中的目录树列出的文件包括一个 Dockerfile（用于从FASTAPI服务构建 Docker 镜像和容器）和一个名为app的文件夹。app文件夹包含weather_api.py文件（包含 API 端点定义的代码），variables.py文件（包含输入变量定义），以及requirements.txt文件（包含运行 API 服务所需的 Python 包），以及包含模型工件（如用于缩放传入数据的模型缩放器）和序列化模型文件（svc.onnx）的文件夹。

模型之前已在模型训练和评估阶段进行了序列化，如第五章中所述，“模型评估和打包”。模型从 Azure 机器学习工作区（Learn_MLOps）中的模型注册表中下载并放置在文件夹中，如图图 8.3所示：

图 8.5 – 下载序列化的模型文件

您可以将 svc.onnx 和 model-scalar.pkl 文件替换为您在 Azure Machine learning 工作区中训练的文件，或者继续使用这些文件进行快速实验。现在我们将查看每个文件中的代码。让我们从 variables.py 开始。

variables.py

我们仅使用一个包来定义输入变量。我们使用的包名为 pydantic；它是一个使用 Python 类型注解进行数据验证和设置管理的包。使用 pydantic，我们将在用于 fastAPI 服务的名为 WeatherVariables 的类中定义输入变量：

from pydantic import BaseModel
class WeatherVariables(BaseModel):
                        temp_c: float 
                        humidity: float 
                        wind_speed_kmph: float 
                        wind_bearing_degree: float
                        visibility_km: float 
                        pressure_millibars: float 
                        current_weather_condition: float

在 WeatherVariables 类中，定义变量及其类型，如前述代码所示。用于训练模型相同的变量将用于推理。我们在这里定义这些输入变量为 temp_c、humidity、wind_speed_kmph、wind_bearing_degree、visibility_km、pressure_millibars 和 current_weather_condition。这些变量的数据类型定义为 float。我们将导入 WeatherVariables 类并在 fastAPI 服务中使用定义的输入变量。让我们看看如何使用 WeatherVariables 类中定义的变量在 fastAPI 服务中使用 Weather_api.py 文件。

Weather_api.py

此文件用于定义 fastAPI 服务。所需的模型工件被导入并用于提供 API 端点以推理模型，用于实时或生产中的预测：

1. 我们首先按照以下方式导入所需的包：

   import uvicorn
   from fastapi import FastAPI
   from variables import WeatherVariables
   import numpy
   import pickle
   import pandas as pd
   import onnxruntime as rt
   

   我们导入了所需的包，例如 uvicorn（一个 ASGI 服务器实现包）、fastapi、numpy、pickle、pandas 和 onnxruntime（用于反序列化和推理 onnx 模型）。

   注意

   我们之前在 variables.py 文件中导入了 WeatherVariables 类。我们将使用此文件中定义的变量为 fastAPI 服务获取输入数据。

2. 接下来，我们创建一个 app 对象。您将注意到 fastAPI 与 Flask 网络框架（如果您曾经使用过 Flask）在语法上有一些相似之处。

   例如，在下一步中，我们使用 FastAPI() 函数创建 app 对象。创建 app 对象的方式类似于我们在 Flask 示例中做的那样：从 Flask 导入 Flask，然后使用 Flask 函数以 app = Flask() 的方式创建 app 对象。您将会注意到我们在使用 fastAPI 构建 API 端点时存在这样的相似性：

   app = FastAPI()
   # Load model scalar
   pickle_in = open("artifacts/model-scaler.pkl", "rb")
   scaler = pickle.load(pickle_in)
   # Load the model
   sess = rt.InferenceSession("artifacts/svc.onnx")
   input_name = sess.get_inputs()[0].name
   label_name = sess.get_outputs()[0].name
   

3. 在创建 app 对象后，我们将导入在端点中进行推理所需的必要模型工件。使用 Pickle 反序列化数据缩放文件 model-scaler.pkl。此文件用于训练模型（在 第四章，机器学习管道），现在我们将使用它来在模型推理之前缩放传入的数据。我们将使用之前训练的支持向量机分类器模型，该模型被序列化到名为 scv.onnx 的文件中（我们可以像 图 8.3 所示那样访问和下载该文件）。

4. 使用 ONNX 运行时将序列化的模型加载到推理会话（input_name 和 label_name）中，以进行机器学习模型的预测。接下来，我们可以转向定义 API 端点的核心部分，以推断机器学习模型。首先，我们使用包装函数 @app.get('/') 向索引路由发出一个 GET 请求：

   @app.get('/')
   def index():
       return {'Hello': 'Welcome to weather prediction service, access the api     docs and test the API at http://0.0.0.0/docs.'}
   

   为索引路由定义了一个名为 index() 的函数。它返回指向文档链接的欢迎信息。此信息旨在指导用户访问和测试 API 端点。

5. 接下来，我们将定义核心 API 端点 /predict，该端点用于推断机器学习模型。使用包装函数 @app.post('/predict') 发出 POST 请求：

   @app.post('/predict')
   def predict_weather(data: WeatherVariables):
       data = data.dict()
       # fetch input data using data varaibles
       temp_c = data['temp_c']
       humidity = data['humidity']
       wind_speed_kmph = data['wind_speed_kmph']
       wind_bearing_degree = data['wind_bearing_degree']
       visibility_km = data['visibility_km']
       pressure_millibars = data['pressure_millibars']
       current_weather_condition = data['current_weather_condition']
   

   为 /predict 端点启动了一个名为 predict_weather() 的函数。在函数内部，我们创建了一个名为 data 的变量，该变量将捕获输入数据；这个变量捕获通过 POST 请求获取的 JSON 数据，并指向 WeatherVariables。一旦我们发出 POST 请求，传入数据中的所有变量都将映射到 variables.py 文件中的 WeatherVariables 类中的变量。

6. 接下来，我们将数据转换为字典，从字典中获取每个输入变量，并将它们压缩成一个名为 data_to_pred 的 numpy 数组变量。我们将使用这个变量来缩放数据并推断机器学习模型：

       data_to_pred = numpy.array([[temp_c, humidity, wind_speed_kmph,         
   wind_bearing_degree,visibility_km, pressure_millibars, 
   current_weather_condition]])
       # Scale input data
       data_to_pred = scaler.fit_transform(data_to_pred.reshape(1, 7))
     # Model inference
       prediction = sess.run(
           [label_name], {input_name: data_to_pred.astype(numpy.float32)})[0]
   

   使用之前加载的缩放器通过 fit_transform() 函数对数据 (data_to_pred) 进行重塑和缩放。

7. 接下来，执行模型推理步骤，这是关键步骤，通过将缩放数据推断到模型中完成，如前面的代码所示。从模型推断出的预测随后作为输出返回到 prediction 变量：

   if(prediction[0] > 0.5):
           prediction = "Rain"
       else:
           prediction = "No_Rain"
       return {
           'prediction': prediction
       }    
   

   最后，我们将模型推理转换为人类可读的格式，根据机器学习模型的预测建议 rain 或 no_rain，并将 prediction 返回给 /predict 端点的 POST 调用。这标志着 weather_api.py 文件的结束。当通过传递输入数据发出 POST 请求时，服务以 0 或 1 的形式返回模型预测。根据模型预测，服务将返回 rain 或 not_rain。当你得到这样的预测时，你的服务正在运行，并且足够健壮，可以满足生产需求。

Requirement.txt

此文本文件包含运行 fastAPI 服务所需的所有软件包：

numpy
fastapi
uvicorn
scikit-learn==0.20.3
pandas
onnx
onnxruntime

这些软件包应该安装在你希望运行 API 服务的环境中。我们将使用 numpy、fastapi（一个用于创建健壮 API 的机器学习框架）、uvicorn（一个 ASGI 服务器）、scikit-learn、pandas、onnx 和 onnxruntime（用于反序列化和推理 onnx 模型）来运行 FastAPI 服务。为了以标准化的方式部署和运行 API 服务，我们将使用 Docker 在 Docker 容器中运行 FastAPI 服务。

接下来，让我们看看如何为服务创建 Dockerfile。

使用 Docker 开发微服务

在本节中，我们将使用 Docker 以标准化的方式打包 FastAPI 服务。这样，我们可以在大约 5 分钟内将 Docker 镜像或容器部署到您选择的部署目标。

Docker 有许多优点，例如可复制性、安全性、开发简单性等。我们可以使用 Docker Hub 上的官方 fastAPI 镜像（tiangolo/uvicorn-gunicorn-fastapi）。以下是 Dockerfile 的一个片段：

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.7
COPY ./app /app
RUN pip install -r requirements.txt
EXPOSE 80
CMD ["uvicorn", "weather_api:app", "--host", "0.0.0.0", "--port", "80"]

首先，我们使用 Docker Hub 上的官方 fastAPI Docker 镜像，通过使用 FROM 命令并指向镜像 – tiangolo/uvicorn-gunicorn-fastapi:python3.7。该镜像使用 Python 3.7，与 fastAPI 兼容。接下来，我们将 app 文件夹复制到 Docker 镜像/容器内的 app 目录中。在将文件夹 app 复制到 Docker 镜像/容器内之后，我们将使用 RUN 命令安装文件 requirements.txt 中列出的必要软件包。

由于 uvicorn 服务器（ASGI 服务器）默认使用端口 80，我们将为 Docker 镜像/容器 EXPOSE 端口 80。最后，我们将使用命令 CMD "uvicorn weather_api:app –host 0.0.0.0 –port 80" 在 Docker 镜像/容器内启动服务器。此命令指向 weather_api.py 文件以访问服务的 fastAPI 应用程序对象，并在镜像/容器的端口 80 上托管。

恭喜，你几乎完成了。现在我们将测试微服务的就绪状态，并查看它是否以及如何工作。

测试 API

要测试 API 的就绪状态，我们将执行以下步骤：

1. 让我们从构建 Docker 镜像开始。为此，先决条件是安装 Docker。转到您的终端或命令提示符，将存储库克隆到您希望的位置，并访问文件夹 08_API_Microservices。执行以下 Docker 命令以构建 Docker 镜像：

   build command will start building the Docker image following the steps listed in the Dockerfile. The image is tagged with the name fastapi. After successful execution of the build command, you can validate whether the image is built and tagged successfully or not using the docker images command. It will output the information as follows, after successfully building the image:
   
   

   (base) 用户 ~ docker images

   REPOSITORY   标签       镜像 ID       创建时间          大小

   fastapi      latest    1745e964f57f   56 秒前   1.31GB

2. 在本地运行 Docker 容器。现在，我们可以从之前创建的 Docker 镜像启动一个正在运行的 Docker 容器。要运行 Docker 容器，我们使用 RUN 命令：

   fastapi Docker image. The name of the running container is weathercontainer and its port 80 is mapped to port 80 of the local computer. The container will run in the background as we have used -d in the RUN command. Upon successfully running a container, a container ID is output on the terminal, for example, 2729ff7a385b0a255c63cf03ec9b0e1411ce4426c9c49e8db 4883e0cf0fde567.
   

3. 使用样本数据测试 API 服务。我们将检查容器是否成功运行。要检查这一点，请使用以下命令：

   fastapi is mapped and successfully running on port 80 of the local machine. We can access the service and test it from the browser on our local machine at the address 0.0.0.0:80.NoteIf you have no response or errors when you run or test your API service, you may have to disable CORS validation from browsers such as Chrome, Firefox, and Brave or add an extension (for example, go to the Chrome Web Store and search for one) that will disable CORS validation for running and testing APIs locally. By default, you don't need to disable CORS; do it only if required.You will see the message that follows:![Figure 8.6 – FastAPI service running on local port 80    ](https://github.com/OpenDocCN/freelearn-ml-zh/raw/master/docs/engi-mlops/img/B16572_08_06.jpg)Figure 8.6 – FastAPI service running on local port 80FastAPI uses the OpenAPI (read more: [`www.openapis.org/`](https://www.openapis.org/), [`swagger.io/specification/`](https://swagger.io/specification/)) Specification to serve the model. The `0.0.0.0:80/docs` and it will direct you to a Swagger-based UI (it uses the OAS) to test your API. 
   

4. 现在，使用您选择的数据测试 /predict 端点（通过选择端点并点击尝试它按钮），如图 图 8.6 所示：![图 8.7 – FastAPI 服务的请求体输入

   图 8.7 – FastAPI 服务的请求体输入

5. 点击POST调用并测试端点。输入由服务中的模型推断，模型预测Rain或No_Rain是POST调用的输出，如图 图 8.7 所示：

![图 8.8 – POST 调用（/predict 端点）的输出

图 8.8 – POST 调用的输出（/predict 端点）

/predict API 的POST调用成功执行将导致输出模型预测，如图 图 8.6 所示。运行在 Docker 容器中的模型在POST调用中将天气条件输出为Rain。恭喜你，你已经成功启动了一个fastAPI容器并对其进行了测试。这个练习应该已经让你具备了构建、部署和测试基于 ML 的 API 服务以供你使用的能力。

摘要

在本章中，我们学习了 API 设计和生产中微服务部署的关键原则。我们简要介绍了 API 设计方法的基础，并了解了 FastAPI。对于我们的业务问题，我们在动手实现将 ML 模型作为 API 提供服务部分通过 FastAPI 和 Docker 进行了实际实施。利用本章获得的实际知识，你可以设计和开发健壮的 API 服务来服务于你的 ML 模型。为 ML 模型开发 API 服务是将 ML 模型推向生产的一个步骤。

在下一章中，我们将深入探讨测试和安全性的概念。我们将使用 Locust 实现一种测试方法来测试 API 服务的健壮性。让我们开始吧！

第九章：测试和确保你的机器学习解决方案安全

在本章中，我们将深入探讨机器学习（ML）解决方案的测试和安全方面。您可以期待获得关于测试您机器学习解决方案的鲁棒性和可扩展性的各种测试类型的入门知识，以及确保您的机器学习解决方案所需的知识。我们将探讨对机器学习解决方案的多种攻击以及防御您的机器学习解决方案的方法。

在本章中，我们将通过执行我们之前一直在工作的天气预测业务用例的负载测试和安全测试来通过示例学习。我们将从反思测试和确保你的机器学习解决方案的需求开始，然后继续探索本章中的其他以下主题：

• 理解测试和确保你的机器学习应用程序的需求

• 通过设计测试你的机器学习解决方案

• 通过设计确保你的机器学习解决方案安全

理解测试和确保你的机器学习应用程序的需求

数据驱动和基于机器学习的解决方案的日益普及导致企业必须处理不断增长的工作负载，使它们面临额外的复杂性和漏洞。

网络安全是 AI 开发者和采用者面临的最令人担忧的风险。根据德勤发布的调查（www2.deloitte.com/us/en/insights/focus/cognitive-technologies/state-of-ai-and-intelligent-automation-in-business-survey.html），2020 年 7 月，62%的采用者认为网络安全风险是一个重大或极端威胁，但只有 39%的人表示他们认为自己有准备应对这些风险。

在本节中，我们将探讨确保基于机器学习的系统和解决方案安全的需求。我们将反思一些机器学习系统更广泛面临的挑战，如偏差、伦理和可解释性。我们还将研究在机器学习生命周期的每个阶段与机密性、完整性和可用性相关的挑战，这些挑战将使用机器学习测试和设计安全的指南来研究。

通过设计测试你的机器学习解决方案

除了执行常规的软件开发测试，如单元测试、集成测试、系统测试和验收测试之外，机器学习解决方案还需要额外的测试，因为数据与机器学习模型都随时间动态变化。以下是一些设计测试的概念；将这些概念应用于您的用例可以确保产生健壮的机器学习解决方案。

数据测试

测试数据的目的是确保数据对于机器学习模型训练来说质量足够高。数据质量越好，为给定任务训练的模型就越好。那么我们如何评估数据的质量呢？可以通过检查以下五个数据因素来完成：

• 准确性

• 完整性（无缺失值）

• 一致性（在预期的数据格式和数量方面）

• 相关性（数据应满足预期的需求和需求）

• 及时性（最新或最新数据）

基于这些因素，如果一家公司能够在接收或创建每个数据集时管理其数据质量，则数据质量得到保证。以下是一些您的团队或公司可以用来作为数据质量保证措施的数据步骤：

1. 细致的数据目录和输入数据的控制：数据目录（以所需格式或模式记录和存储数据）和控制功能的组合可以确保输入数据的高质量。数据目录和控制可以通过监控数据因素，如数据格式和模式、值分布和异常、完整性和一致性来实现，这有助于提供良好的输入数据质量。

2. 精心管理数据管道以避免重复数据：当重复数据由相同的数据源生成，并且由不同的人使用相同的逻辑时，管理血缘、真实性和数据完整性可能会变得复杂。这可能会在多个系统或数据库中产生级联效应。尽可能避免重复数据会更好。

3. 强制执行数据治理的完整性：在当今世界，维护数据完整性变得至关重要。没有强制执行数据完整性的心态可能会对一个组织造成损失。数据最终可能会变得不完整、延迟或过时，导致严重的数据质量问题。

4. 维护端到端的可追溯性和血缘关系：通过智能使用元数据和数据本身，可以实现数据血缘和可追溯性。使用两者，我们可以记录关键信息，如每个数据集的唯一键、为每条记录添加时间戳以及记录数据变更。确保数据血缘和端到端可追溯性被启用，可以给我们提供重现模型和调试错误和管道的可能性。

模型测试

模型测试需要涵盖以下服务器问题：

• 评估机器学习模型的准确性或关键指标

• 在随机数据点上测试

• 测试任务的可接受损失或性能

• 使用真实数据进行模型鲁棒性的单元测试

这些测试可以分为两个阶段：预训练和后训练。在流程中实施这些测试可以产生适合生产的稳健模型。让我们看看预先设计和后训练测试可以做什么。

预训练测试

在我们进入训练阶段之前，可以通过测试来捕捉缺陷。这些缺陷可能存在于数据、管道或参数中。图 9.1建议将预训练和后训练测试作为开发高质量模型所提出的流程的一部分：

图 9.1 – 开发高质量模型所提出的流程

这里有一些使用预训练测试来检测和避免预训练缺陷的方法：

• 通过处理任何数据泄漏、边缘情况和优化以使管道时间效率和资源效率来消除数据管道债务

• 确保您的模型输出形状与数据集中的标签匹配

• 检查输出范围以确保它们符合我们的预期（例如，检查分类模型的输出是一个分布，其类概率之和为 1）

• 检查您的训练和验证数据集是否存在标签泄漏

• 确保 ETL 管道以所需格式输出或获取数据

预训练测试不需要参数运行，但它们在运行模型训练之前捕捉错误非常有用。

训练后测试

训练后测试使我们能够调查模型性能和模型预测背后的逻辑，并在将模型部署到生产之前预见模型中可能存在的任何缺陷。训练后测试使我们能够检测模型性能和功能中的缺陷。训练后测试包括模型性能评估测试、不变性测试和最小功能测试。以下是一篇推荐的阅读材料，以了解更多关于训练后测试的信息：超越准确性：使用 CheckList 对 NLP 模型进行行为测试 (homes.cs.washington.edu/~marcotcr/acl20_checklist.pdf)

部署和推理测试

部署测试包括测试持续集成/持续交付（CI/CD）管道交付、集成测试以及测试部署是否成功。测试已部署的模型至关重要，这就是推理测试介入以压力或负载测试已部署模型并测试其在实时数据上的性能的原因。

在下一节中，我们将对之前部署的模型进行负载测试（针对一个用例）。

实践部署和推理测试（一个业务用例）

当您的服务（无论是 API 还是 ML）准备就绪，您即将向用户提供服务，但您对它实际上可以处理多少用户以及当许多用户同时访问时它将如何反应没有任何头绪时，这就是负载测试有用之处，可以基准测试您的服务可以服务多少用户，并验证该服务是否能够满足业务需求。

我们将对之前部署的服务进行负载测试（在第七章，构建健壮的 CI 和 CD 管道）。将使用Locust.io进行负载测试。locust.io是一个开源的负载测试工具。为此，我们将使用pip安装locust，并使用 locust.io SDK 编写一个 Python 脚本来测试一个端点。让我们从安装locust开始：

1. 安装locust：转到您的终端并执行以下命令：

   pip, locust will be installed – it takes around a minute to install. After installation is successful it's time to curate the Python script using the locust.io SDK to test an endpoint.
   

2. 精炼 load_test.py 脚本：前往您的首选 IDE 并开始精炼脚本，或者遵循预先制作脚本中的步骤。要访问预先制作的脚本，请前往之前克隆的 Engineering MLOps 仓库，访问 09_Testing_Security 文件夹，然后转到 load_test.py 文件。让我们揭开 load_test.py 中的代码之谜——首先，所需的库如下导入：

   import time
   import json
   from locust import HttpUser, task, between
   

   我们导入了 time、json 和 locust 库，然后从 locust 中导入了以下所需的功能：HttpUser（一个可以访问不同端点的用户代理）、task 和 between。

3. 创建一个 test_data 变量，包含用于负载测试中推断机器学习模型的样本测试数据。定义我们将在负载测试中使用的 headers：

   test_data = json.dumps({"data": [[8.75, 0.83, 70, 259, 15.82, 1016.51, 1.0]]})
   headers = {'Content-Type': 'application/json'}
   

4. 接下来，我们将通过扩展 HttpUser 来实现负载测试的核心功能，作为 MLServiceUser 类（您可以取任何名字）的一部分。HttpUser 是一个用户代理，可以访问不同的端点：

   class MLServiceUser(HttpUser):
       wait_time = between(1, 5)
       @task
       def test_weather_predictions(self):
           self.client.post("", data=test_data, headers=headers)
   

   我们使用 between() 函数创建了一个 wait_time 变量，该变量指定了完成测试一个端点后切换到测试下一个端点所需的时间。因此，我们在 between(1,5) 函数中将 wait_time 指定为 1 到 5 秒。下一个部分是定义测试端点的任务的核心。

   对于此，我们使用 @task 包装器或装饰器来开始定义我们的任务，以使用自定义函数测试我们选择的端点。定义一个自定义函数 def test_weather_predictions()，并使用之前定义的 test_data 和 headers 向端点发送 post 请求。现在，我们已经准备好运行负载测试了！

5. 运行 locust.io 服务器：前往您的终端并切换到您有 load_test.py 文件的位置（例如，在本书中使用的克隆仓库的 09_Testing_Security 文件夹中），然后运行以下命令来启动一个 locust.io 服务器：

   Locust -f load_test-py
   

   执行上一条命令将在端口 8089 启动 locust 服务器。我们可以在由 locust.io 渲染的 Web 界面上执行负载测试。要访问 Web 服务，打开您选择的浏览器并访问以下 Web 地址：http://0.0.0.0:8089/，如图 图 9.2 所示：

   

   图 9.2 – 访问 Locust.io Web 服务

6. 运行负载测试：打开 Web 服务将提示您指定选项，如用户数量、生成速率和主机（要测试的端点）。根据您的需求指定要模拟的用户数量和生成速率（每秒将生成多少用户），以验证您的端点是否能够满足您的业务/用户需求，例如，50 个用户和 50 的生成速率。

7. 最后，输入您想要进行负载测试的端点或主机，并点击开始 swarming以开始执行负载测试。在第七章 构建健壮的 CI/CD 管道中，我们部署了一个端点。建议测试已部署的端点。

8. 前往您的 Azure ML 工作区，访问端点部分，访问名为dev-webservice的已部署端点，并将端点 Web 地址复制并粘贴到主机文本框中。

9. 接下来，点击开始 swarming以开始对端点进行负载测试。这将启动负载测试并打开一个新页面，您可以在其中实时监控您的负载测试，如图图 9.3所示：

   图 9.3 – 实时监控负载测试

10. 分析负载测试结果：您可以在实时监控统计数据、图表、故障和异常。例如，在图 9.3中，我们正在监控带有测试数据的POST请求的负载测试。监控的项目包括请求数量（77459）、失败次数（0）、平均响应时间（75ms）以及其他信息。检查是否存在故障以及平均响应时间是否在满足您的业务/用户需求的有效范围内或没有速度瓶颈是很重要的。

    如果您没有失败的请求，并且平均响应时间在所需范围内，则您的端点已通过负载测试并准备好供用户使用。在负载测试之后或期间，您可以通过图表查看负载测试性能，包括每秒总请求数、响应时间和随时间推移的用户数量等关键信息。我们可以在图 9.4和图 9.5中实时查看这些信息：

图 9.4 – 显示每秒总请求数和响应时间的图表

在图 9.4中，我们可以注意到，当locust.io的模拟用户发起请求时，每秒请求数量在 18-22 之间，某些情况下响应时间在 70 到 500 毫秒之间变化，最小和最大响应时间之间的差异为 430 毫秒。平均请求时间为 75 毫秒（如图图 9.3所示）。

请注意，这种性能可能或可能不适合特定的用例，这取决于您的业务或用户需求。更稳定的响应时间更可取；例如，最小和最大响应时间之间的响应时间变化不超过 50ms 可能更适合稳定性能。为了实现这种性能，建议根据需要部署到高端基础设施上，例如 GPU 或高端 CPU，而不是在 Azure 容器实例上的 CPU 上部署。同样，在图 9.5中，我们可以看到响应时间与用户数量的关系：

![图 9.5 – 显示每秒总请求次数和用户数量的图表

![img/B16572_09_05.jpg]

图 9.5 – 显示每秒总请求次数和用户数量的图表

我们可以看到，每秒产生的用户数量为 50，如（图 9.2）中所述。随着时间的推移，产生率保持恒定，响应时间在 70-500ms 之间变化，平均响应时间为 75ms。

1. 文档或下载结果：负载测试成功执行后，您可以使用测试报告记录或向相关利益相关者（QA/产品经理）展示负载测试的结果。要下载或访问测试报告，请访问如图图 9.6所示的.csv文件：

![图 9.6 – 下载测试结果

![img/B16572_09_06.jpg]

图 9.6 – 下载测试结果

根据您的需求下载所需的统计数据或故障报告，并请注意，您可以通过点击下载报告来访问完整的测试报告，如图图 9.7所示：

![图 9.7 – 下载测试结果

![img/B16572_09_07.jpg]

图 9.7 – 下载测试结果

提供了包含关键信息的全面测试报告，例如端点推断的平均请求时间和最小/最大请求时间，这些信息也以可视化的图表形式呈现，如图图 9.7所示。您还可以下载此完整报告以向您的相关利益相关者展示。

恭喜您，您已经进行了手动负载测试以验证您的端点，并检查您的机器学习服务是否能够以高效的方式满足您的业务或用户需求。

通过设计确保机器学习解决方案的安全

由于人工智能在提供智能应用方面的日益普及，确保您的机器学习应用安全比以往任何时候都更重要。在设计和发展机器学习系统时，如果不考虑安全性，可能会因暴露系统给黑客而造成损失，导致操纵、数据泄露和不合规。鲁棒性和安全性在确保人工智能系统值得信赖方面发挥着重要作用。为了构建值得信赖的机器学习应用，考虑安全性是至关重要的，以确保不留任何遗漏。

图 9.8 展示了一个通过设计创建安全机器学习应用的框架。该框架针对机器学习生命周期的关键区域，确保在这些特定阶段中的机密性、完整性和可用性。让我们反思机器学习生命周期的每个区域，并针对每个区域解决机密性、完整性和可用性问题：

![图 9.8 – 通过设计确保机器学习生命周期的框架

![img/B16572_09_08.jpg]

图 9.8 – 通过设计确保机器学习生命周期的框架

在查看不同类型的攻击的同时，让我们反思机器学习生命周期的每个区域，并解决每个区域的机密性、完整性和可用性问题。

攻击类型

我们将探讨一些最常见针对机器学习系统的攻击。从高层次来看，黑客的攻击可以分为四个类别：中毒、输入攻击和规避、逆向工程和后门攻击。让我们看看攻击者是如何通过这些攻击渗透机器学习系统的。

中毒

在中毒攻击中，黑客或攻击者试图破坏 AI 模型。中毒攻击可以在任何阶段发生（训练、部署或实时推理）。它们通常发生在训练和推理阶段。让我们看看中毒攻击是如何以三种典型方式实施的：

• 数据集中毒：训练数据集包含模型训练所依据的知识。攻击者可以通过渗透训练数据集来操纵这种知识。在这里，攻击者将错误标记或错误的数据引入训练数据集，从而扭曲整个学习过程。这是直接中毒模型的一种方式。训练数据集可以在数据收集和整理阶段中毒，由于训练数据集可能来自多个来源，可能很大，而且攻击者可以在数据分布中渗透，因此可能很难注意到或检测到它。

• 算法中毒发生在攻击者干预用于训练模型的算法时。这可以简单到渗透超参数或篡改算法架构。例如，让我们以联邦学习（旨在保护个人数据的隐私）为例，在多个私有数据子集（如来自多家医院的医疗数据，同时保护患者的机密信息）上完成模型训练。从每个子集中衍生出多个模型，然后组合成一个最终模型。在这个过程中，攻击者可以操纵任何数据子集并影响最终生成的模型。攻击者还可以从伪造数据创建一个假模型，并将其与从多个私有数据子集的训练中产生的模型连接起来，以生成一个偏离高效执行任务或服务于攻击者动机的最终模型。

• 模型中毒发生在攻击者用替代模型替换已部署模型时。这种攻击与典型的网络攻击相同，其中包含模型的电子文件可能被修改或替换。

输入攻击和规避

当攻击者以某种方式修改输入到机器学习系统，导致系统故障（或给出错误预测）时，就会发生输入或规避攻击。这些扰动或变化可能很难检测，因为这些变化非常微妙或微小。

例如，输入攻击在计算机视觉算法中很受欢迎。这可以通过仅更改输入图像中的几个像素来实现。结果，系统可能会以它不应该的方式识别图像，或者做出错误的预测。这种微小的变化可以有效地操纵预测，导致系统采取错误的行为。因此，ML 系统表现得像它应该的那样，而输出被操纵。

ML 系统高度容易受到输入攻击。因此，拥有一个异常检测器来监控传入数据可以非常方便，以避免传入数据中的这种扰动。无论输入数据如何，大多数分类模型都会从它们的训练中选择一个有效类别。保护 ML 系统的另一种方法是在将图像发送到最终图像分类器之前，使用代理二进制模型对输入进行预处理，该模型告诉你，例如，输入图像是人的图像还是动物的图像。

逆向工程

对于一个 AI 系统的用户来说，它可能是一个黑盒或是不透明的。在 AI 系统中，接受输入以生成输出而不透露内部情况（无论是逻辑还是算法）是很常见的。训练数据集，它实际上包含了所有训练系统的知识，通常也保持机密。从理论上讲，这使得外部人士无法预测特定输出产生的原因或 AI 系统在算法、训练数据或逻辑方面的内部情况。然而，在某些情况下，这些系统可能容易受到逆向工程的影响。逆向工程攻击的攻击者或黑客的目标是复制作为服务部署的原始模型，并利用它为自己谋利。

在一篇题为《针对循环神经网络的后门提取攻击》的论文中（arxiv.org/pdf/2002.00123.pdf），该论文于 2020 年 2 月发表，研究人员对使用公开可用的学术数据集训练的 RNN 和 LSTM 进行了模型提取攻击实验。研究人员通过模型提取攻击有效地复制了 ML 系统的功能。他们证明，高精度的模型提取攻击可以有效地提取，主要是通过复制或配置目标模型中的损失函数或架构。

在另一个例子中，2018 年，马克斯·普朗克信息学研究所的研究人员展示了他们如何通过一系列输入-输出查询从不可见模型中推断信息。

后门攻击

在后门攻击中，攻击者可以在训练或推理阶段将他们选择的模式嵌入到模型中，并使用预先准备好的输入来推断部署的模型，从而产生意外的输出或触发 ML 系统。因此，后门攻击可以在训练和推理阶段发生，而逃避和中毒攻击可以在训练或推理的单个阶段发生。

毒化攻击可以用作后门攻击的一部分，在某些情况下，学生模型可以通过迁移学习从教师模型中学习到一些后门。

后门攻击可能会引起完整性挑战，尤其是在训练阶段，如果攻击者成功利用毒化攻击渗透训练数据并触发模型或系统的更新。此外，后门攻击可能旨在降低性能，耗尽或重定向可能导致系统故障的资源，或者尝试从人工智能系统中引入特殊的行为和输出。

摘要

在本章中，我们通过设计测试和安全性的关键原则进行了学习。我们探讨了测试机器学习解决方案的各种方法以确保其安全性。为了获得全面的理解和动手经验，我们实施了对之前部署的机器学习模型（来自第七章，构建健壮的 CI/CD 管道）进行负载测试，以预测天气。有了这个，您就准备好应对各种测试和安全场景，这些场景将会出现在您的面前。

在下一章中，我们将深入探讨在生产环境中部署和维护健壮的机器学习服务的秘密。这将使您能够在生产环境中部署健壮的机器学习解决方案。让我们深入探讨。

第十章：生产发布的基本要素

在本章中，您将了解持续集成和持续交付（CI/CD）管道、生产环境的基本要素以及如何设置生产环境以向最终用户提供之前测试和批准的机器学习（ML）模型。我们将为 CI/CD 管道的生产环境设置所需的基础设施，配置生产部署的过程，配置管道执行触发器以实现完全自动化，并学习如何管理生产发布。本章将涵盖 CI/CD 管道和生产环境的基本要素，因为管道是产品，而不是模型。

通过了解 CI/CD 管道的基础知识，您将能够为您的用例或业务开发、测试和配置自动化的 CI/CD 管道。我们将涵盖与生产部署相关的一系列主题，然后深入探讨在生产环境中监控机器学习模型的基础知识。

在本章中，我们将涵盖以下主题：

• 设置生产基础设施

• 在 CI/CD 管道中设置我们的生产环境

• 测试我们的生产就绪管道

• 配置管道触发器以实现自动化

• 管道发布管理

• 向持续监控服务迈进

让我们从设置构建 CI/CD 管道所需的基础设施开始。

设置生产基础设施

在本节中，我们将设置所需的基础设施以服务于我们的业务用例（预测天气条件——图尔库港是否下雨，以规划和优化港口资源）。我们将设置一个自动扩展的 Kubernetes 集群，以将我们的 ML 模型以 Web 服务的形式部署。Kubernetes 是一个开源的容器编排系统，用于自动化软件应用程序的部署、扩展和管理。许多云服务提供商提供基于 Kubernetes 的基础设施即服务。同样，Microsoft Azure 提供了一个名为 Azure Kubernetes Service（AKS）的基于 Kubernetes 的基础设施即服务。我们将使用 AKS 来编排我们的基础设施。

在 Azure 上部署自动扩展的 Kubernetes 集群有多种方式。我们将探讨以下两种方式，以了解基础设施部署的不同视角：

• Azure 机器学习工作区门户

• Azure SDK

让我们先看看最简单的方法；那就是使用 Azure 机器学习工作区为生产部署 Azure Kubernetes 集群。

Azure 机器学习工作区

在本节中，我们将使用 Azure 机器学习工作区提供 Azure Kubernetes 集群。请执行以下步骤：

1. 前往 Azure 机器学习工作区，然后转到计算部分，该部分提供了创建不同类型计算选项。选择推理集群并点击创建，如下截图所示：![图 10.1 – 部署推理集群

   图 10.1 – 部署推理集群

2. 点击创建按钮将显示您可以使用来创建 Kubernetes 服务的各种计算选项。您将被提示选择一个区域，这是您的计算将被部署的位置，以及一些配置，以便您可以根据核心、RAM 和存储来部署。选择一个合适的选项（建议您选择Standard_D2_v4作为此实验的成本最优选择），如下截图所示：![图 10.2 – 选择合适的计算选项

   图 10.2 – 选择合适的计算选项

3. 选择合适的计算选项后，您将被提示输入'prod-aks'（意味着生产 Azure Kubernetes 服务），将集群用途设置为生产（因为我们正在为生产设置），选择集群的节点数量，并选择网络配置的基本选项。为了简单起见，省略启用 SSL 配置。然而，根据您的需求，建议在生产中启用 SSL 连接，以提高安全性：![图 10.3 - 配置设置

   图 10.3 - 配置设置

4. 点击创建按钮以部署用于生产的 Kubernetes 集群。创建和部署用于生产的计算大约需要 15 分钟：![图 10.4 – 部署的 Kubernetes 集群

   图 10.4 – 部署的 Kubernetes 集群

5. 一旦您的 AKS 集群已部署，您将看到一个运行中的 Kubernetes 集群，其名称与您为计算提供的名称（例如，prod-aks）相匹配，如前一个截图所示。

Azure 机器学习 SDK

在 Azure 上创建和部署 Kubernetes 集群的另一种方法是使用 Azure 机器学习 SDK。您可以使用名为create_aks_cluster.py的预置脚本，该脚本位于10_Production_Release文件夹中。运行create_aks_cluster.py脚本的前提是您的 Azure 机器学习工作区的config.json（可以从 Azure 机器学习工作区下载）文件，如下截图所示：

![图 10.5 – 从您的 Azure 机器学习工作区获取配置文件

图 10.5 – 从您的 Azure 机器学习工作区获取配置文件

前往您的 Azure 机器学习工作区，并点击与create_aks_cluster.py文件相同的目录（10_Production_Release）中的config.json文件，如下所示：

├──10_Production_Release
├── create_aks_cluster.py
├── config.json

通过这种方式，您现在可以运行脚本 (create_aks_cluster.py) 来创建用于生产部署的 AKS 计算资源。让我们看看 create_aks_cluster.py 脚本：

1. 从 azureml.core SDK 或库中导入必要的函数。例如 Workspace、Model、ComputeTarget、AksCompute 等函数将用于配置您的 AKS 集群：

   from azureml.core import Workspace
   from azureml.core.model import Model
   from azureml.core.compute import ComputeTarget
   from azureml.core.compute_target import ComputeTargetException
   from azureml.core.compute import AksCompute, ComputeTarget
   

2. 通过导入必要的函数，您可以通过连接到您的 Azure Machine Learning 工作区并创建 ws 对象来开始使用它们。这样做是通过使用 Workspace 函数并将它指向您的 config.json 文件来完成的，如下所示：

   ws = Workspace.from_config()
   print(ws.name, ws.resource_group, ws.location, sep = '\n')
   

3. 默认情况下，from_config() 函数会在您执行 create_aks.py 文件相同的目录中查找 config.json 文件。如果您的 config.json 文件在其他位置，请在 from_config() 函数中指定该文件的位置。在成功执行 workspace.from_config() 函数后，您将看到工作区的名称、资源组和位置被打印出来。

4. 接下来，我们将为生产部署创建一个 AKS Kubernetes 集群。首先为您的 AKS 集群选择一个名称（将其引用到 aks_name 变量），例如 prod-aks。脚本将检查是否已存在具有所选名称的集群。我们可以使用 try 语句通过 ComputeTarget() 函数检查是否已存在具有所选名称的 AKS 目标。它接受 workspace 对象和 aks_name 作为参数。如果找到具有所选名称的集群，它将打印找到的集群并停止执行。否则，将使用 ComputeTarget.create() 函数创建一个新的集群，该函数接受具有默认配置的 provisioning 配置：

   # Choose a name for your AKS cluster
   aks_name = 'prod-aks' 
   # Verify that cluster does not exist already
   try:
       aks_target = ComputeTarget(workspace=ws, name=aks_name)
       print('Found existing cluster, use it.')
   except ComputeTargetException:
       # Use the default configuration (can also provide parameters to customize)
       prov_config = AksCompute.provisioning_configuration()
       # Create the cluster
       aks_target = ComputeTarget.create(workspace = ws, 
                                       name = aks_name, 
   provisioning_configuration = prov_config)
   if aks_target.get_status() != "Succeeded":
       aks_target.wait_for_completion(show_output=True)
   

在成功执行前面的代码后，将创建一个具有所选名称的新集群（即 prod-aks）。通常，创建新集群需要大约 15 分钟。一旦集群创建完成，您可以在 Azure Machine Learning 工作区中找到它，正如我们在 图 10.4 中所看到的。现在我们已经为增强生产环境 CI/CD 管道设置了先决条件，让我们开始设置它！

在 CI/CD 管道中设置我们的生产环境

执行以下步骤以在 CI/CD 管道中设置生产环境：

1. 前往您之前工作的 Azure DevOps 项目，并重新访问 Pipelines | Releases 部分，以查看您的 Port Weather ML Pipeline。我们将通过创建生产阶段来增强此管道。

2. 点击 编辑 按钮开始，然后在 DEV TEST 阶段下点击 添加，如图所示：![Figure 10.6 – 添加新阶段

   Figure 10.6 – 添加新阶段

3. 点击 production 或 PROD 并保存，如图所示：![Figure 10.7 – 添加并保存生产阶段 (PROD)

   Figure 10.7 – 添加并保存生产阶段 (PROD)

4. 将创建一个新的名为PROD的生产阶段。现在，你可以在生产阶段配置作业和流程。要为PROD配置作业，点击PROD阶段中的 1 个作业，0 个任务链接（如前述截图所示，在PROD阶段），你将被导向任务部分，你可以在这里将作业添加到PROD阶段。在这个阶段，我们将从我们的 Azure 机器学习工作区部署模型，因此我们将使用我们在第七章，构建健壮的 CI 和 CD 流水线中之前使用的 AzureML 模型部署模板来连接它。点击代理作业部分右侧的+号来添加一个任务，如下所示：![图 10.8 – 添加 AzureML 模型部署任务

   ![图片 B16572_10_08.jpg]

   图 10.8 – 添加 AzureML 模型部署任务

5. 搜索mlops_ws并指向模型工件作为你的模型源。我们这样做是因为我们将使用我们在第四章，机器学习流水线中训练的模型工件。

6. 接下来，从 Azure DevOps 仓库指向你的推理配置文件，如下截图所示。推理配置文件代表用于部署的定制环境的配置设置。我们将使用与inferenceConfig.yml文件相同的推理Config.yml文件。

7. 接下来，我们将配置prod-aks），命名你的部署或网络服务（例如，prod-webservice），并从与流水线连接的 Azure DevOps 仓库中选择部署配置文件，如下所示：![图 10.10 – 配置你的部署信息

   ![图片 B16572_10_10.jpg]

   AksDeploymentConfig.yml
   computeType: AKS
   autoScaler:
       autoscaleEnabled: True
       minReplicas: 1
       maxReplicas: 3
       refreshPeriodInSeconds: 10
       targetUtilization: 70
   authEnabled: True
   containerResourceRequirements:
       cpu: 1
       memoryInGB: 1
   appInsightsEnabled: False
   scoringTimeoutMs: 1000
   maxConcurrentRequestsPerContainer: 2
   maxQueueWaitMs: 1000
   sslEnabled: False
   

8. 选择AksDeploymentConfig.yml文件作为我们的部署配置文件。现在，点击保存按钮来设置PROD环境。

通过这些，你已经成功设置了生产环境并将其与你的 CI/CD 流水线集成以实现自动化。现在，让我们通过执行它来测试流水线。

测试我们的生产就绪流水线

恭喜你成功设置了生产流水线！接下来，我们将测试其鲁棒性。一种很好的方法是创建一个新的版本，观察并研究生产流水线是否成功将模型部署到生产环境（包含流水线的生产 Kubernetes 集群设置）。按照以下步骤测试流水线：

1. 首先，创建一个新的版本，转到流水线 | 发布部分，选择你之前创建的流水线（例如，Port Weather ML 流水线），然后点击屏幕右上角的创建发布按钮以启动一个新的发布，如下所示：![图 10.11 – 创建一个新的发布

   ![图片 B16572_10_11.jpg]

   图 10.11 – 创建一个新的发布

2. 在屏幕右上角选择你想要在流水线中部署的工件（例如，Learn_MLOps repo，_scaler和support-vector-classifier模型，并选择它们的版本。建议第一次测试 PROD 部署时使用版本 1），然后点击屏幕右上角的创建按钮，如图所示。完成此操作后，将启动一个新的版本，如图所示：![Figure 10.12 – New release’s execution

   ![img/B16572_10_12.jpg]

   图 10.12 – 新版本执行

3. 在执行流水线后，DEV TEST和PROD阶段将被部署（例如，Release-5，如图所示）。在流水线发布进行中时，你可以通过监控任何阶段（DEV TEST 或 PROD）的每个步骤的日志来检查每个阶段的每个步骤，直到流水线成功部署。你还可以检查以前版本的日志。

4. 在成功完成版本发布后，DEV TEST和PROD阶段将分别使用 CI 和 CD 进行部署。你必须确保流水线是健壮的。接下来，我们可以通过添加自定义触发器进一步自定义流水线，这些触发器将自动化流水线而无需人工监督。在没有人工监督的情况下自动化 CI/CD 流水线可能会有风险，但可能具有优势，例如实时持续学习（监控和重新训练模型）和更快的部署。了解如何在没有人工监督的情况下自动化 CI/CD 流水线是很有用的。请注意，在许多情况下并不推荐这样做，因为错误的空间很大。在某些情况下，它可能是有用的——这完全取决于你的用例和机器学习系统目标。现在，让我们看看全自动化触发器。

配置流水线触发器以实现自动化

在本节中，我们将基于我们已经连接到流水线的工件配置三个触发器。我们将设置的触发器如下：

• Git 触发器：用于对 master 分支进行代码更改。

• Artifactory 触发器：用于创建或训练新模型或工件时。

• 计划触发器：每周周期性触发。

让我们详细看看这些流水线触发器。

设置 Git 触发器

在团队中，当代码库中某个分支发生代码更改时，通常会设置一个部署触发器。例如，当对master分支或develop分支进行代码更改时，CI/CD 流水线会被触发，分别将应用程序部署到 PROD 或 DEV TEST 环境。当向master或develop分支提交合并请求时，QA 专家或产品经理会接受合并请求以与相应的分支合并。在 master 或 develop 分支上做出代码更改后，会生成一个触发器以在流水线中创建一个新的版本。按照以下步骤为实验的 master 分支创建触发器，如图所示：

1. 进入 管道 | 发布 部分，选择您的管道（例如，Port Weather ML 管道）。然后，点击 编辑：![图 10.13 – 设置持续部署触发器（Git 触发器）

   图 10.13 – 设置持续部署触发器（Git 触发器）

   您将被引导到一个门户，您可以在其中编辑您的管道（例如，Port Weather ML 管道），以便您可以为您的工件配置持续部署触发器。

2. 要为 master 分支设置 Git 触发器（当 master 分支发生更改时，将触发新发布），点击 触发器 图标（雷声图标）并将开关按钮从禁用状态移动到启用状态。这将启用持续部署触发器。

3. 最后，添加一个分支过滤器并指向您想要设置触发器的分支 – 在这种情况下，是 master 分支 – 如前图所示。保存您的更改以设置 Git 触发器。

通过实施这些步骤，您已设置了一个持续部署触发器，以便在 master 分支发生更改时启动新发布。

设置 Artifactory 触发器

对于机器学习应用程序，Artifactory 触发器非常有用。当团队中的数据科学家训练了新的模型或工件（文件）时，将那些模型部署到测试环境，并在有希望或优于先前模型或触发器的情况下最终部署到生产环境是有用的。按照以下步骤设置一个持续部署触发器，以便在训练新模型时为管道创建新发布，如图中所示：

1. 进入 管道 | 发布 部分，选择您的管道（例如，Port Weather ML 管道）。然后，点击 编辑：![图 10.14 – 为工件触发器设置 CD（SVC 模型）

   图 10.14 – 为工件触发器设置 CD（SVC 模型）

   点击 编辑 按钮后，您将被引导到一个门户，您可以在其中编辑您的管道，如图中所示。

2. 要为您的模型设置工件触发器，点击您选择模型，例如 支持向量机分类器（SVC），并启用 持续部署触发器。在前面的截图，已为模型（SVC）启用了一个触发器。每当在连接到您的 Azure Machine Learning 工作区的模型注册表中训练并注册新的 SVC 模型时，将通过管道触发新发布以部署新模型。

3. 最后，保存您的更改以设置 SVC 模型的工件触发器。您已设置了一个持续部署触发器，以便在您的 Azure Machine Learning 工作区上训练并注册新的 SVC 模型时启动新发布。该管道将检索新模型并将其部署到开发测试和产品环境中。

通过实施这些步骤，您已设置了一个持续部署触发器，当在您的 Azure Machine Learning 工作区中创建或注册新工件时，将启动新的管道发布。

设置计划触发器

现在，我们将为管道设置一个特定时间的时间触发计划。这种触发器对于通过定期的新发布保持系统健康和更新非常有用。计划触发器在设定的时间间隔创建新发布。我们将为每周星期一上午 11:00 设置一个计划触发器。在此时间，将触发一个新发布，将 SVC 模型的最新版本部署到开发测试和 PROD 环境。按照以下步骤设置计划触发器：

1. 前往管道 | 发布部分并选择您的管道（例如，Port Weather ML 管道）。然后，点击编辑，如图所示：![图 10.15 – 设置计划触发器

   图 10.15 – 设置计划触发器

   点击编辑按钮后，您将被引导到一个门户，您可以在那里编辑您的管道。

2. 要为管道设置计划触发器，请点击计划设置并启用计划发布触发器。然后，选择您希望触发发布的日期和时间。例如，在先前的屏幕截图中，每周星期一上午 11:00 已启用触发器。

3. 最后，保存您的更改以设置管道的计划触发器。

通过实施这些步骤，您已设置了一个持续部署触发器，在设定的时间间隔内启动新的管道发布。

恭喜您设置 Git、工件和计划触发器。这些触发器使管道实现完全自动化。管道已设置，现在可以成功测试和部署模型。您还可以选择通过添加人工或质量保证（QA）专家来部分自动化管道，以在每个管道阶段获得批准。例如，在测试阶段之后，QA 专家可以进行批准，以便在测试阶段一切顺利时开始生产部署。作为 QA 专家，监控您的 CI/CD 管道至关重要。在下一节中，我们将探讨在管理管道发布时的最佳实践。

管道发布管理

CI/CD 管道中的发布允许您的团队完全自动化，并以更快的速度、更低的风险向客户交付软件。发布允许您在生产的多个阶段测试和交付软件，或设置带有批准和按需部署的半自动化流程。监控和管理这些发布至关重要。我们可以通过从管道 | 发布访问管道并选择我们的 CI/CD 管道（例如，Port Weather ML Pipeline）来管理发布，如图所示：

![图 10.16 – 管道发布管理

图 10.16 – 管道发布管理

在这里，您可以跟踪所有版本及其历史记录，并对每个版本执行操作，例如重新部署、放弃、检查日志等。您可以看到以下截图中的版本。通过点击单个版本（例如，版本 4），我们可以检查在版本中部署了哪些模型和工件以及版本是如何触发的（手动或使用自动触发器）。它提供了管道的端到端可追溯性。这些信息对于 ML 系统的治理和合规至关重要：

![图 10.17 – 检查版本

![img/B16572_10_17.jpg]

图 10.17 – 检查版本

预防胜于治疗。正如我们在失败后进行事件审查一样，在部署新服务或模型后进行发布后审查有助于通过预防可能的失败。对部署后的发布进行彻底分析可以使我们理解以下关键问题的答案：

• 在发布过程中，哪些是有效的，哪些是无效的？

• 发布过程中是否遇到了任何障碍？

• 是否存在可以解决并使下一个版本更具可解释性的不明确流程？

在发布后彻底理解这些问题可以帮助您改进和迭代您的策略，并发展更好的发布管理实践。

向持续监控迈进

通过这样，我们已经建立了一个完全自动化且稳健的流程。到目前为止，我们已经成功地在 MLOps 工作流中实现了部署部分或模块（正如我们在第一章，MLOps 工作流基础中讨论的那样）。实时监控已部署的 ML 模型和服务对于理解系统的性能至关重要，因为这有助于最大化其商业影响。ML 项目未能为业务带来价值的一个原因是因为它们在决策过程中缺乏信任和透明度。在当今时代，将信任融入 AI 系统至关重要，尤其是如果我们希望适应不断变化的环境、监管框架和动态的客户需求。持续的监控将使我们能够监控 ML 系统的性能，并将信任融入 AI，以最大化我们的商业价值。在下一章中，我们将学习 MLOps 工作流中的监控模块以及它是如何促进持续监控的。

摘要

在本章中，我们介绍了 CI/CD 管道和生成环境的基本要素。我们进行了一些实际操作来搭建生产基础设施，然后在管道的生产环境中设置了流程以进行生产部署。我们测试了准备就绪的生产管道以检验其鲁棒性。为了将事情提升到下一个层次，我们使用各种触发器完全自动化了 CI/CD 管道。最后，我们探讨了发布管理实践和能力，并讨论了持续监控 ML 系统的必要性。一个关键的观点是管道是产品，而不是模型。比起构建最佳模型，更应专注于构建一个强大且高效的管道。

在下一章中，我们将探讨 MLOps 工作流程监控模块，并深入了解这个颠覆性的可解释监控框架。

第三部分：生产环境中监控机器学习模型

在本部分，读者将了解生产环境中监控机器学习系统的原理和流程。这将使他们能够构建 CI/CD 管道以监控部署，并使他们能够设置和促进机器学习模型的持续交付和持续监控。

本节包含以下章节：

• 第十一章, 监控您的 ML 系统的关键原则

• 第十二章, 模型服务和监控

• 第十三章, 持续学习的 ML 系统治理

第十一章：监控你的 ML 系统的关键原则

在本章中，我们将学习那些对于在生产环境中监控你的机器学习（ML）模型至关重要的基本原理。你将学习如何使用可解释监控框架构建可信赖且可解释的人工智能解决方案。可解释监控框架可用于构建功能监控管道，以便你在生产环境中监控 ML 模型，分析应用程序和模型性能，并治理 ML 系统。监控 ML 系统的目标是实现信任、透明度和可解释性，以增加业务影响。我们将通过观察一些现实世界的例子来了解这一点。

理解本章中提到的原则将使你具备构建针对你的用例或公司的端到端监控系统的知识。这将帮助你参与业务、技术以及公众（客户和法律）利益相关者，以便你能够高效地实现你的业务目标。这还将帮助你获得优势，并采用系统的方法来治理你的 ML 系统。使用本章中的框架，你可以为你的利益相关者和 ML 系统启用信任、透明度和可解释性。

在本章中，我们将涵盖以下主要内容：

• 理解监控 ML 系统的关键原则

• 在 MLOps 工作流程中的监控

• 理解可解释监控框架

• 启用服务的持续监控

让我们开始吧！

理解监控 ML 系统的关键原则

在当今数据驱动产品日益增长的需求以及适应不断变化的环境和监管框架的背景下，将信任融入 AI 系统至关重要。ML 项目未能为业务带来价值的一个原因就是决策过程中缺乏信任和透明度。许多黑盒模型擅长达到高精度，但在解释已做决策背后的原因时却变得过时。在撰写本文时，有关信任和可解释性的担忧的新闻正在浮出水面，如下图所示：

![图 11.1 – 模型信任和可解释性的组成部分]

![img/image001.jpg]

图 11.1 – 模型信任和可解释性的组成部分

这张图片展示了现实生活中重要领域的担忧。让我们通过一些现实生活中的例子来探讨这些担忧如何转化为模型可解释性的关键方面，例如模型漂移、模型偏差、模型透明度和模型合规性。

模型漂移

我们生活在一个动态变化的世界。因此，机器学习模型执行任务或进行预测的环境和数据也在不断演变，考虑这种变化是至关重要的。例如，COVID-19 大流行给我们带来了一个意想不到的现实。许多商业运营已经转向虚拟，这场大流行给我们带来了一个许多人都认为的新常态。许多小企业已经破产，由于失业率的上升，个人面临着极端的财务短缺。这些人（小企业主和个人）以前从未如此大规模地向银行和机构申请过贷款和财务救济。银行和机构已经部署并使用的欺诈检测算法在贷款和财务救济申请方面没有看到这种速度和真实性。

所有这些特征的变化（例如申请人的收入、他们的信用历史、申请人的位置、他们请求的金额等），由于一个原本有资格贷款但之前没有申请过贷款的申请人失去了工作，可能会扭曲模型的权重/感知（或混淆模型）。这对模型来说是一个重要的挑战。为了处理这种动态变化的环境，考虑模型漂移并持续从中学习至关重要。

Drift 与环境的改变相关，指的是预测机器学习模型性能的下降以及变量之间关系的退化。以下是与模型和数据相关的四种模型变化类型：

• 数据漂移：这是指独立变量的属性发生变化。例如，在先前的例子中，由于季节性、新产品或为满足消费者需求而进行的更改，数据发生变化，如 COVID-19 大流行。

• 特征漂移：这是指特征（的）属性随时间变化。例如，温度随着季节的变化而变化。在冬天，温度比夏天或秋天的温度要低。

• 模型漂移：这是指依赖变量的属性发生变化。例如，在上面的例子中，这是欺诈检测分类发生变化的地方。

• 上游数据变化：这是指数据管道经历操作数据变化时的情况，例如当某个特征不再生成时，导致缺失值。一个例子是客户薪资价值的变化（从美元到欧元），其中美元价值不再生成。

为了更清晰地说明，我们将在下一章中学习更多关于 drift 的知识，并开发 drift 监控器（第十二章，模型服务和监控）。

模型偏差

无论你是否喜欢，机器学习已经影响了你生活中的许多决策，比如获得下一份工作的短名单或从银行获得抵押贷款批准。甚至执法机构也在使用它来缩小潜在的犯罪嫌疑人以预防犯罪。ProPublica 是一个新闻机构（使用机器学习预测未来的罪犯 - www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing）。2016 年，ProPublica 的机器学习显示了一些案例，其中模型倾向于将黑人女性预测为比白人男性风险更高，而所有之前的记录都显示并非如此。这类案例可能代价高昂，并具有破坏性的社会影响，因此需要避免。在另一个案例中，亚马逊构建了一个用于招聘人员的 AI，但由于它歧视女性（据《华盛顿邮报》报道），不得不关闭它。这类偏见可能代价高昂且不道德。为了避免这些，需要监控人工智能系统，以便我们能够对其建立信任。

模型偏差是一种由于数据集（用于模型训练）中某些特征比其他特征更频繁地表示和/或加权而产生的错误。一个失真或有偏差的数据集可能导致模型用例的结果偏差、低准确度水平和分析错误。换句话说，这是由于机器学习算法做出不正确假设而产生的错误。高偏差可能导致预测不准确，并可能导致模型错过特征与预测的目标变量之间的相关关系。一个例子是上述由亚马逊构建的用于招聘人员的 AI，但它对女性存在偏见。我们将在“可解释监控框架”部分了解更多关于模型偏差的内容，我们将探讨“偏差和威胁检测”。

模型透明度

人工智能在本质上是非确定性的。特别是机器学习在其生命周期中持续演变、更新和重新训练。人工智能几乎影响着所有行业和领域。随着其日益普及和重要决策使用机器学习，建立与确定性系统相同的信任水平变得至关重要。毕竟，数字系统只有在它们能够被信任执行其任务时才有用。模型透明度有明确的需求——许多首席执行官和商业领袖都在鼓励我们了解人工智能的商业决策及其商业影响。最近，TikTok 的首席执行官发表声明称：

"我们相信所有公司都应该向监管机构披露他们的算法、审核政策和数据流"（来源：TikTok）。

公司这样的开放和透明度可以建立我们作为社会对人工智能的信任，并使采用和合规更加顺畅。

模型透明性是建立对人工智能系统信任的追求，以确保公平性、减少或消除偏差、提供问责制（审计系统推导结果的端到端过程），以及证明模型输出和系统决策的合理性。

模型合规性

模型合规性已成为重要议题，因为不遵守政府和社会的规定可能造成巨大的成本。以下标题是由《华盛顿邮报》报道的：

"摩根大通就联邦抵押贷款歧视诉讼达成 5500 万美元和解"

不合规对摩根大通来说变成了一笔昂贵的交易。将监管合规性付诸实践越来越重要，以避免不必要的罚款和对社会的损害。以下是一些在公司内实现模型合规性的驱动因素：

• 问责文化：对机器学习系统进行端到端审计对于监控合规性至关重要。MLOps 可以在促进审计和编辑使用人工智能做出的运营和业务决策中发挥关键作用。

• 伦理优先：构建对社会有价值并赢得我们信任的负责任的人工智能系统需要人工智能预测具有包容性、公平性和伦理性。拥有一个伦理框架可以帮助公司将其客户与他们的价值观和原则联系起来，并确保人工智能决策是按照伦理做出的。欧洲委员会在这方面做得很好，提出了可信赖人工智能的伦理和指南。您可以在以下链接找到这些指南：ec.europa.eu/digital-single-market/en/news/ethics-guidelines-trustworthy-ai。

• 合规性管道：拥有满足商业和政府规定的合规性管道可以为寻求确保实时合规性、审计和编辑的组织带来回报。MLOps 可以通过跟踪所有机器学习模型的库存来促进这一点，从而让利益相关者了解它们的工作方式，并以可视化的方式解释它们是如何工作的。这种方式的工作使人类能够监控、编辑并解释与法规的相关性，这对于业务利益相关者、数据科学家和监管者携手合作确保他们有透明和可解释的运营是高效的。

可解释人工智能

在理想情况下，企业应将模型透明度和合规性置于首位，以便业务能够动态适应不断变化的环境，如模型漂移，并在过程中处理偏差。所有这些都需要一个框架，使所有业务利益相关者（IT 和业务领导者、监管者、业务用户等）与人工智能模型保持联系，以便理解模型所做的决策，同时专注于提高模型透明度和合规性。这样的框架可以通过将可解释人工智能作为 MLOps 的一部分来实现。可解释人工智能使机器学习易于人类理解。

模型透明度和可解释性是两种使可解释人工智能成为可能的方法。机器学习模型基于它们训练的数据形成模式或规则。可解释人工智能可以帮助人类或业务利益相关者理解模型发现的这些规则或模式，并帮助验证由机器学习模型做出的业务决策。理想情况下，可解释人工智能应该能够服务于多个业务利益相关者，如下面的图所示：

![图 11.2 – 以业务驱动的可解释人工智能]

图 11.2 – 以业务驱动的可解释人工智能

黑盒模型在预测上可以达到高精度，但一旦它们无法解释为什么做出这些决策，就会变得过时。大多数黑盒模型不提供对模型性能的可见性，没有监控来捕捉潜在的偏差或漂移，也没有对模型行为的可解释性。为了解决这个问题，大量研究和开发正在进行中，以提供可解释人工智能方法，以提供模型透明度和模型可解释性。

将 MLOps 与可解释人工智能方法相结合可以使几乎所有的业务利益相关者理解和验证人工智能做出的业务决策，并帮助向内部和外部利益相关者解释它们。可解释人工智能没有一劳永逸的解决方案，因为每个用例都需要自己的可解释人工智能方法。有各种方法正在变得越来越受欢迎。我们将在以下小节中查看一些示例。

特征归因方法

特征归因方法显示了模型中的每个特征对每个实例预测的贡献程度。当你请求解释时，你会得到预测，以及特征归因信息。以下是一些特征归因方法：

• SHapley Additive exPlanations（SHAP）：一种解释任何机器学习模型输出的方法。它基于博弈论方法，解释任何机器学习模型的输出。特别是，它解释了每个特征对推动模型输出的贡献。

• 集成梯度：一种旨在通过模型特征来解释模型预测之间关系的技巧。它在论文《深度网络的公理化归因》中提出。它可以通过识别偏斜数据来解释特征重要性，并有助于调试模型性能。

• Local Interpretable Model-Agnostic Explanation（LIME）：这是一种模型无关的方法，用于解释预测。它侧重于局部解释；也就是说，解释反映了模型对预测数据实例的行为。例如，LIME 可以建议哪些因素或特征对模型预测结果很重要。这可以在以下图中看到：

![图 11.3 – 使用 LIME 解释单个预测]

图 11.3 – 使用 LIME 解释单个预测

在前面的图中，模型预测患者患有糖尿病。LIME 解释器突出了与糖尿病相关的症状，如干燥的皮肤、过多的尿液和模糊的视力，这些症状有助于“糖尿病”预测，而“无疲劳”则是反对的证据。使用解释器，医生可以从模型的预测中做出决定并得出结论，并为患者提供适当的治疗。

你可以在cloud.google.com/ai-platform/prediction/docs/ai-explanations/overview了解更多关于 AI 解释的信息。

非特征归因方法

非特征归因方法不关注特征如何影响你的模型预测。相反，它们关注模型推理中输入数据和输出数据之间的关系。以下是一些非特征归因方法：

• Deeplift：这是通过比较每个神经元的激活与其参考激活并根据差异分配贡献分数来评估神经网络的。Deeplift 揭示了相关性和贡献。例如，假设我们正在使用猫和狗图像分类器来对猫和狗之间的图像进行分类。假设分类器使用 deeplift 方法预测输入图像是狗。在这里，我们可以将图像分类器神经网络中激活的神经元反向传播到它们的参考激活，然后根据差异为每个特征分配贡献分数。

• 自然语言解释（NLE）：NLE 旨在通过融合部分依赖函数、梯度分析、上下文编码、个体条件期望、累积局部效应等技术，捕捉文本解释的输入输出关系。这些技术在解释分类或生成文本的语言模型方面非常有用。NLE 为用户提供易于理解和有用的理由，以决定是否信任模型的决策并采取行动。例如，你可能希望根据模型的推荐和解释购买产品。可以使用如 Microsoft Power BI 和 Qlik Sense 等工具来插入并研究 NLE。这些工具需要根据你的需求或用例进行定制。

除了前面提到的那些方法之外，还有其他方法。这个领域是 AI 领域研究的热点。许多研究人员和商业领袖都在追求解决可解释 AI 问题，向内部和外部利益相关者解释模型决策。为多个商业利益相关者提供可解释 AI 驱动的界面可以帮助他们回答关键的商业问题。例如，一位商业领袖需要能够回答“这些模型决策如何影响业务？”而对于 IT 和运营来说，了解“我如何监控和调试？”的答案至关重要。

为多个商业利益相关者回答这些问题，使员工和企业能够适应人工智能，并通过确保模型透明度和合规性，在优化模型偏差和漂移的同时适应不断变化的环境，从而最大化从人工智能中获得的价值。

可解释人工智能 = 模型透明度和可解释性

由于机器学习模型正成为一等公民，为了监控模型在这些领域的性能，我们可以使用可解释监控，它允许我们通过监控和解释其决策来分析和治理生产中的机器学习系统，使用的是可解释人工智能方法。可解释监控是可解释人工智能的混合体；它在生产中融合了操作（Ops）的可解释人工智能方法。可解释监控正成为 MLOps 工作流程的一个组成部分。我们将在下一节中探讨可解释监控如何为 MLOps 工作流程带来价值。

MLOps 工作流程中的监控

我们在第一章《MLOps 工作流程基础》中了解了 MLOps 工作流程。如图所示，监控模块是 MLOps 工作流程的一个组成部分，用于评估生产中机器学习模型的性能和衡量机器学习系统的商业价值。只有当我们从透明度和可解释性的角度理解模型的决策时，我们才能做到这两者（衡量由机器学习模型产生的性能和商业价值），以便向利益相关者和客户解释这些决策。

可解释监控使透明度和可解释性得以治理机器学习系统，从而驱动最佳商业价值：

![图 11.4 – MLOps 工作流程 – 监控

图 11.4 – MLOps 工作流程 – 监控

在实践中，可解释监控使我们能够监控、分析和治理机器学习系统，并且它与其他 MLOps 工作流程组件一起形成一个连续的循环。它还赋予人类参与循环的机会，以理解模型决策并即时教导模型（通过标记数据和重新训练模型）。可解释监控实现了持续学习，并且从长远来看，对一家公司来说可能非常有价值。以下图中可以看到，使用可解释监控实现的人机交互的持续学习流程：

![图 11.5 – 由可解释监控实现的持续学习

图 11.5 – 由可解释监控实现的持续学习

持续学习是系统在变化的环境中持续学习的能力，同时建立之前学到的知识。为了促进持续学习，数据和建模必须携手合作，并得到人工的辅助（通常是一个 QA 分析师或系统管理员，如数据科学家或 ML 工程师）。可解释监控在持续学习系统中发挥着至关重要的作用，以增加收入、保持合规和负责任地构建 ML 系统。毕竟，只有具备持续学习能力并部署的模型才能带来商业价值。

理解可解释监控框架

在本节中，我们将详细探讨可解释监控框架（如图所示）以了解和了解可解释监控如何增强 MLOps 工作流程和 ML 系统本身：

图 11.6 – 可解释监控框架

可解释监控框架是一个模块化框架，用于监控、分析和治理 ML 系统，同时实现持续学习。所有模块协同工作，以实现透明和可解释的监控。让我们看看每个模块是如何工作的，以了解它们在框架中的贡献和功能。首先，让我们看看监控模块（前图中第一个面板）。

监控

监控模块专注于监控生产中的应用程序（服务 ML 模型）。在 ML 系统中存在多个因素，例如应用程序性能（遥测数据、吞吐量、服务器请求时间、失败的请求、错误处理等）、数据完整性和模型漂移，以及不断变化的环境。监控模块应从生产系统日志中捕获关键信息，以跟踪 ML 系统的鲁棒性。让我们看看监控模块三个功能的重要性及其功能：数据完整性、模型漂移和应用性能。

数据完整性

确保 ML 应用程序的数据完整性包括检查输入（ML 模型的输入数据）和输出（ML 模型预测）数据，以确保 ML 系统的完整性和鲁棒性。监控模块通过检查数据的量、种类、真实性和速度来确保数据完整性，以检测异常值或异常。检测异常值或异常可以防止 ML 系统性能不佳并容易受到安全攻击（例如，对抗性攻击）。数据完整性与高效的审计相结合，可以促进 ML 系统达到预期的性能，从而产生商业价值。

模型漂移

如果不测量模型漂移，模型的性能可能会很容易变得低于标准，并可能因不良的决策和客户服务而损害业务。例如，在类似 COVID-19 的黑天鹅事件期间，很难预见数据的变化或趋势。以下是一些登上头条的新闻：

• 由于购物习惯的巨大变化，Instacart 模型预测项在商店的可访问性准确性从 93%下降到 61%(fortune.com/2020/06/09/instacart-coronavirus-artificial-intelligence/)。

• 银行家们怀疑，那些在好时光下训练的信用模型是否能够准确应对压力情景（www.americanbanker.com/opinion/ai-models-could-struggle-to-handle-the-market-downturn）。

• 针对市场不确定性，交易算法失误。某些基金下降了 21%(www.wired.com/story/best-ai-models-no-match-coronavirus)。

• 在 COVID-19 大流行之后，图像分类模型难以适应“新常态”：一个家庭在家前使用笔记本电脑现在可能意味着“工作”，而不是“休闲”。(techcrunch.com/2020/08/02/ai-is-struggling-to-adjust-to-2020/)。

因此，监控模型漂移至关重要，无论是数据漂移、概念漂移还是任何上游数据的变化，以便适应不断变化的环境，并以最相关的方式服务于企业和客户，从而产生最大的商业价值。

应用性能

监控应用性能以预见和预防任何潜在故障至关重要，因为这确保了机器学习系统的鲁棒性。在这里，我们可以监控生产部署目标（例如，Kubernetes 或本地服务器）的关键系统日志和遥测数据。监控应用性能可以实时提供关键洞察，例如服务器的吞吐量、延迟、服务器请求时间、失败请求的数量或控制流错误等。监控应用没有固定的方法，而且根据你的业务用例，你的应用性能机制可以被定制和监控，以保持系统运行并产生商业价值。

在监控组件方面，我们监控了数据完整性、模型漂移和应用性能。在下一节中，我们将分析如何监控模型和应用程序的数据。

分析

在生产环境中实时分析你的机器学习系统对于理解你的机器学习系统的性能和确保其鲁棒性至关重要。人类在分析模型性能和检测细微异常和威胁方面发挥着关键作用。因此，在机器学习系统中引入人类可以极大地提高透明度和可解释性。我们可以分析模型性能以检测任何偏差或威胁，并了解为什么模型以某种模式做出决策。我们可以通过应用高级技术，如数据切片、对抗攻击预防技术，或通过理解局部和全局解释来实现这一点。让我们看看我们如何在实践中做到这一点。

数据切片

在机器学习（ML）改善商业和一般生活方面有许多成功的案例。然而，仍有改进数据工具以调试和解释模型的空间。一个关键的改进领域是理解为什么模型在某些数据部分或切片上表现不佳，以及我们如何平衡它们的整体性能。切片是数据集的一部分或子集。数据切片可以帮助我们了解模型在不同类型的子数据集上的表现。我们可以将数据集分成多个切片或子集，并研究模型在它们上的行为。

例如，让我们考虑一个假设的情况，我们训练了一个随机森林模型来分类一个人的收入是否高于或低于 50,000 美元。该模型是在 UCI 人口普查数据上训练的 (archive.ics.uci.edu/ml/datasets/Census-Income+%28KDD%29)。模型对数据切片（或子集）的结果可以在下表中看到。这张表表明，整体指标可能是可接受的，因为所有数据的整体对数损失都很低（见 All 行）。这是二分类问题中广泛使用的损失指标，表示预测概率与实际/真实值之间的接近程度；在二分类的情况下，它为 0 或 1。预测概率与实际值偏差越大，对数损失值就越高。然而，各个切片讲述了一个不同的故事：

![表 11.1 – UCI 人口普查数据切片

表 11.1 – UCI 人口普查数据切片

通过查看前表，我们可以得出结论，该模型的表现尚可。然而，如果我们比较男性和女性的表现，我们会看到模型仅在女性受试者上表现良好，其日志损失低于男性受试者的日志损失。另一方面，如果你查看教授-专业职业，你会看到净表现与男性受试者的表现相当，其日志损失分别为 0.45 和 0.41，而教授-专业的影响量则明显较小。对于学士、硕士和博士，模型表现不佳，因为其日志损失分别为 0.44、0.49 和 0.59。还应注意，如果一个切片及其对应项的日志损失低于可接受水平，这表明模型整体表现不佳，而不仅仅是特定数据切片。

数据切片使我们能够看到微妙的偏差和未见过的相关性，以了解为什么模型可能在数据子集上表现不佳。我们可以通过使用代表所有数据切片的平衡数据集（例如，使用合成数据或通过欠采样等）或调整模型的超参数以减少整体偏差来避免这些偏差并提高模型的整体性能。数据切片可以为机器学习系统提供模型公平性和性能的概述，并帮助组织优化数据和机器学习模型以达到最佳性能和合理的公平性阈值。数据切片可以通过提供数据和模型性能的透明度和可解释性来帮助建立对人工智能系统的信任。

备注

要全面了解数据切片和自动化数据切片方法，请参阅自动化数据切片用于模型验证：大数据-人工智能集成方法，链接为arxiv.org/pdf/1807.06068.pdf。

偏差和威胁检测

为了确保使用机器学习模型做出稳健和道德的决定，我们需要确保模型是公平和安全的。任何偏差和威胁都需要被监控和缓解，以避免不道德或偏颇的决定，这些决定可能有利于任何特定一方，以符合商业价值观和法律。

存在着不同类型的偏差，例如选择偏差（用于训练模型的训练数据不代表人口，例如少数群体）、框架偏差（用于收集数据的问题或调查是以某种观点或偏见为框架的）、系统性偏差（重复或一致的错误）、响应偏差（参与者由于跟随他们的主观偏见而回答错误的数据）或确认偏差（收集数据以验证自己的先入之见）。为了避免这些偏差并减轻它们，可以根据具体情况应用数据切片、基于切片的学习或平衡偏差-方差权衡等技术。

机器学习系统面临着需要监控和缓解的安全威胁。我们在第九章“测试和保障您的机器学习解决方案”中讨论了一些常见的威胁和威胁预防技术，包括对抗攻击、投毒攻击、隐私攻击或后门攻击等。

局部和全局解释

局部和全局解释提供了对模型性能的不同视角。局部解释为特定或单个输入的模型预测提供依据，而全局解释则提供了对模型预测过程的洞察，不受任何特定输入的影响。例如，让我们看看一个假设的案例，即使用循环神经网络（RNN）模型对客户评论进行情感分析。以下图表显示了使用 RNNVis 工具对 RNN 模型情感分析的全局解释（整个过程）：

图 11.7 – 使用 RNNVis 对 RNN 模型的整体解释（理解隐藏状态、层等如何影响模型输出和预测过程）

来源：blog.acolyer.org/2019/02/25/understanding-hidden-memories-of-recurrent-neural-networks/

例如，这里共聚类可视化显示了具有积极和消极情感的单词云。使用全局解释，我们可以模拟模型的预测过程，并理解与参数或模型架构（例如隐藏状态和层）相关的相关性。全局解释提供了可解释性的两个视角：高级模型过程和预测解释。另一方面，局部解释提供了对单个预测的洞察。如果我们希望全面理解模型的表现并验证它，这两种解释都是有价值的。

在分析组件中，我们可以使用我们探索的技术来分析模型的表现，例如数据切片、偏差和威胁检测以及局部和全局解释。在下一节中，我们将学习如何管理和控制机器学习系统，以有效地引导它实现运营或业务目标。

管理

机器学习系统的有效性取决于其治理方式，以实现最大化的商业价值。系统治理的很大一部分涉及质量保证和控制，以及模型审计和报告，以确保其具有端到端的可追踪性并符合法规。基于对模型性能的监控和分析，我们可以控制和治理机器学习系统。治理是通过智能警报和行动来最大化商业价值的。让我们来看看警报和行动、模型质量保证和控制以及模型审计和报告是如何协调机器学习系统治理的。

警报和行动

治理机器学习系统涉及监控和分析机器学习应用。在这里，系统开发者可以被告知系统何时表现出异常行为，如失败请求、缓慢的服务器响应时间、服务器异常、错误或高延迟。向系统开发者或管理员发出警报可以确保质量保证并防止系统故障。有两种不同类型的警报：系统性能警报和基于模型性能的警报。以下是一些系统性能警报的示例：

• 基于阈值的基于规则的针对失败请求的警报

• 基于阈值的基于规则的针对服务器响应时间的警报

• 基于阈值的基于规则的针对服务器异常的警报

• 基于阈值的基于规则的针对可用性的警报

当模型经历漂移或异常特征分布或偏差时，会生成模型性能警报。当记录此类事件时，系统管理员或开发者会通过电子邮件、短信、推送通知和语音警报被提醒。这些警报操作（自动化或半自动化）可以用来减轻系统性能下降。根据具体情况和需求，可以采取一些可能的行动，例如以下内容：

• 在经历高模型漂移时部署替代模型

• 重新训练一个模型

• 训练一个新的模型

• 重新启动机器学习系统

• 重新部署机器学习系统

模型质量保证和控制

对于使用机器学习系统的用户来说，一个模型的质量保证和控制机制可以非常有益，如果我们希望防止许多可能的事故，并确保机器学习系统的定期和健康监控和功能。建议有一个模型质量保证和控制框架或机制。为此，以下图所示的机器学习系统质量保证框架可以为您组织启用该机制。它是一个模块化框架，用于监控机器学习系统的三个重要方面：

![图 11.8 – 模型质量保证框架

图 11.8 – 模型质量保证框架

质量保证专家可以帮助您的公司或组织实施测试机制，以验证用于训练的数据是否已清理，确保用于模型推断的数据不含有对那个机器学习系统的威胁，并监控数据漂移以理解和验证不断变化的环境。通过以下方式，质量保证或测试工程师，连同产品经理一起，可以监控和测试数据：

• 理解和验证训练、测试和推断数据中的统计关系（例如，平均值、中位数、众数等）。

• 开发测试来验证上述统计和关系（使用脚本）。

• 使用特征选择、降维等技术评估特征分布。

• 重新训练并审查所有模型的性能。

• 定期使用新的数据集监控所有模型的性能。

• 如果模型库存中的另一个模型（性能）比现有模型更准确，则发出警报。

• 定期进行测试。

模型审计和报告

如果您希望为监管机构和法律合规性提供足够的信息，则模型审计和报告至关重要。对模型进行端到端可追溯性确保了极大的透明度和可解释性，这可以为组织或公司带来透明的治理机制。模型审计和报告的目标是评估模型性能，并据此实现机器学习系统治理。在以下图表中，我们可以看到从审计和报告中生成的模型透明度图表的整体概述：

![图 11.9 – 模型 QA 框架

图 11.9 – 模型透明度图表

基于审计和报告的模型评估将确保组织拥有健康、透明和稳健的治理机制，并使他们能够实现端到端可追溯性，以符合监管机构的要求。拥有这样的机制将帮助组织节省大量时间和资源，并使与监管机构的互动更加高效。

启用服务的持续监控

如果我们希望在生产中监控机器学习系统，则可解释性监控框架非常有用。在下一章中，我们将为我们在前几章中工作的业务用例启用可解释性监控框架。我们将为已部署的系统启用持续监控。然后，我们将监控已部署到生产的机器学习应用程序，分析传入数据和模型性能，以治理机器学习系统，为用例产生最大的商业价值。

摘要

在本章中，我们学习了监控机器学习系统的关键原则。我们探讨了常见的监控方法以及可解释监控框架（包括监控、分析和治理阶段）。然后，我们深入探讨了可解释监控的概念。

在下一章中，我们将深入探讨可解释监控框架的实战应用。利用这个框架，我们将构建一个监控管道，以便持续监控生产环境中的机器学习系统，用于业务场景（例如预测图尔库港的天气）。

下一章非常注重实践，所以请系好安全带，做好准备！

第十二章：模型服务和监控

在本章中，我们将反思在生产环境中服务和监控机器学习（ML）模型的需求，并探讨为模型用户或消费者提供不同服务 ML 模型的方法。然后，我们将重新审视第十一章中讨论的可解释监控框架，即监控您的 ML 系统的主要原则，并将其应用于我们使用 MLOps 预测天气的业务用例中。可解释监控框架的实施是实践性的。我们将推断部署的 API，并使用漂移（如数据漂移、特征漂移和模型漂移）来监控和分析推理数据，以衡量 ML 系统的性能。最后，我们将探讨一些概念，以管理 ML 系统，确保 ML 系统的稳健性能，以驱动持续学习和交付。

让我们从反思在生产环境中监控 ML 的需求开始。然后，我们将继续在本章中探讨以下主题：

• 在生产环境中服务、监控和维护模型

• 探索服务机器学习模型的不同模式

• 实施解释监控框架

• 管理您的 ML 系统

在生产环境中服务、监控和维护模型

部署一个模型或 ML 系统而不监控它是没有意义的。监控性能是 ML 系统最重要的方面之一。监控使我们能够以定性和定量的方式分析和绘制 ML 系统对利益相关者的业务影响。为了实现最大的业务影响，ML 系统的用户需要以最方便的方式提供服务。之后，他们可以消费 ML 系统并产生价值。在前几章中，我们开发和部署了一个 ML 模型来预测港口的天气条件，这是我们一直在解决的实际实施业务用例的一部分。在本章中，我们将重新审视我们在第十一章中讨论的可解释监控框架，即监控您的 ML 系统的主要原则，并将其应用于我们的业务用例中。在图 12.1中，我们可以看到可解释监控框架及其一些组件，如绿色高亮所示：

图 12.1 – 要实施的解释监控框架的组件

我们将为以下领域实现可解释监控：数据完整性、模型漂移、应用性能、偏差和威胁检测、局部和全局解释、警报和操作、模型 QA 和控制以及模型审计和报告。这些组件在我们使用案例中是最重要的，以理解可解释监控的实施。我们将省略数据切片，因为我们数据中的人口统计或样本（例如，性别、年龄组等）没有太多多样性。通过使用其他组件的信息，我们可以评估模型的表现及其公平性。在本章中，我们将实现监控和分析模块的组件：数据完整性、模型漂移、应用性能、偏差和威胁检测以及局部和全局解释。其余组件的实现将在第十三章中介绍，持续学习的 ML 系统治理。在我们继续到实现过程之前，让我们看看模型如何为用户消费提供服务。

探索 ML 模型的不同服务模式

在本节中，我们将考虑如何为用户（无论是人类还是机器）提供模型以高效地消费 ML 服务。模型服务是一个关键领域，ML 系统需要成功实现以发挥其商业影响，因为在这个领域的任何延迟或错误都可能对服务用户造成高昂的成本。鲁棒性、可用性和便利性是在提供服务模型时需要考虑的关键因素。让我们看看 ML 模型可以以哪些方式提供服务：这可以是批量服务或按需模式（例如，当需要查询以获取预测时）。在按需模式下，模型可以服务于机器或人类用户。以下是将模型提供给用户的示例：

图 12.2 – 向用户提供服务模型

在典型场景（按需模式）中，模型作为服务提供给用户消费，如图图 12.2所示。然后，机器上的外部应用程序或人类使用他们的数据向预测或机器学习服务发出查询。机器学习服务在收到请求后，使用负载均衡器将请求路由到机器学习应用程序内的可用资源（如容器或应用程序）。负载均衡器还管理机器学习服务内的资源，以按需编排和生成新的容器或资源。负载均衡器将查询从用户重定向到机器学习应用程序内运行的容器中的模型以获取预测。获取预测后，负载均衡器将返回到机器上的外部应用程序，或请求查询的人类，或模型预测内的查询。这样，机器学习服务能够为其用户提供服务。机器学习系统与模型存储或注册表协同工作，以保持其与最新或性能最佳的模型同步，以便以最佳方式为用户提供服务。与用户进行查询的典型场景相比，还有另一种用例，即模型作为批量服务提供。

将模型作为批量服务提供

批量处理或服务应用于大量或批次的输入数据（即不是单个观察值，而是成组的观察值）。在存在大量数据需要推断的情况下，模型通常以批量模式提供服务。一个例子是当模型一次性处理产品或服务的所有消费者或用户的数据。或者，工厂在固定时间线上的数据批次可能需要被处理以检测机器中的异常。与按需模式相比，批量模式更节省资源，通常在可以承受一定延迟的情况下使用：

图 12.3 – 批量推断

批量处理的一个关键优势是，与基于 REST API 的服务不同，批量服务可能需要更轻量或更少的基础设施。对于数据科学家来说，编写批量作业比部署在线 REST 服务更容易。这是因为数据科学家只需要在机器上训练一个模型或反序列化一个训练好的模型，并对一批数据进行批量推理。批量推理的结果可以存储在数据库中，而不是发送响应给用户或消费者。然而，一个主要的缺点是高延迟且不是实时。通常，批量服务可以一次处理数百或数千个特征。可以使用一系列测试来确定最佳批量大小，以达到可接受的延迟。典型的批量大小可以是 32、64、128 或 2 的 518 次方。批量推理可以定期安排，并可以服务于许多延迟不是问题的用例。以下将讨论一个这样的例子。

一个现实世界的例子

一个现实世界的例子是银行从一批文本文档中提取信息。银行每天从其合作伙伴机构接收数千份文件。人类代理不可能阅读所有这些文件并突出显示文档中列出的操作中的任何红旗。批量推理用于一次性从银行接收的所有文档中提取命名实体和红旗。然后，批量推理或服务的成果存储在数据库中。

将模型提供给人类用户

在处理来自人类用户的请求之前，检查用户是否有足够的权限使用模型至关重要。此外，在大多数情况下，了解请求的上下文也很有帮助。收集请求的上下文将使模型能够产生更好的预测。收集上下文后，我们可以将其转换为模型可读的输入，并推断模型以获得预测。

在实践中，以下是向人类用户提供按需模型的关键步骤：

1. 验证或授权请求。

2. 分析和收集上下文信息（例如，历史数据、用户体验数据或任何其他用户个人数据）。

3. 将任何上下文信息转换为模型可读的输入或模式。

4. 使用输入数据（包括请求和上下文信息）推断模型以做出预测或获取输出。

5. 根据上下文解释输出结果。

6. 将输出传递给用户。

   一个现实世界的例子

   考虑一个聊天机器人服务于人类客户预订机票。它执行上下文推理以服务于人类用户。

将模型提供给机器

我们可以根据用例使用REST API 或基于流的服务的机器或外部应用程序。通常，机器推理数据需求要么是预先确定的，要么在标准模式内。一个定义良好的拓扑和数据模式，无论是 REST API 还是流式服务，都将有效。对机器或人类的需求式服务因情况而异，因为在某些场景中，需求可能会变化（例如，在一天中的特定时间，用户服务的需求可能很高，如下午）。为了处理服务的高需求，自动扩展（在云上）可以帮助按需生成更多资源，并杀死任何空闲资源以释放更多资源。然而，自动扩展不是缩放的万能解决方案，因为它不能单独处理需求上的突然或特殊峰值：

![图 12.4 – 需求式服务的消息代理

图 12.4 – 需求式服务的消息代理

如图 12.4所示的方法在处理高量需求峰值时资源效率高。为了处理突然的峰值，可以使用如 Apache Kafka 或 Spark 这样的消息代理。消息代理运行进程以向队列写入和从队列读取：一个进程用于在队列中写入消息，另一个进程用于从该队列读取。服务模型定期连接到消息代理以处理队列中的输入数据批次，并对批次中的每个元素进行预测。在处理输入数据批次并生成预测后，预测被写入输出队列，然后根据用户请求推送给用户。

一个现实世界的例子

考虑一个拥有数百万用户的社交媒体公司。该公司使用单个或公共机器学习模型作为推荐系统，向用户推荐新闻文章或帖子。由于请求量很大，为了服务众多用户，它不能依赖于基于 REST API 的机器学习系统（因为它同步）。流式解决方案更好，因为它为公司提供异步推理，以便实时服务其用户。当用户登录到其机器上的应用程序或账户（例如社交媒体公司服务器上的应用程序）时，运行在其机器上的应用程序通过流式服务推断机器学习模型（即推荐系统），以提供用户新闻源的推荐。同样，成千上万的用户同时登录。流式服务可以无缝地服务所有这些用户。请注意，这不可能通过 REST API 服务实现。通过为推荐系统模型使用流式服务，社交媒体公司能够实时服务其大量用户，避免出现重大延迟。

实施可解释监控框架

要实现可解释监控框架，回顾一下到目前为止所讨论的内容，特别是关于实现假设用例的内容是值得的。以下是关于我们用例实现回顾，包括问题和解决方案：

• 问题背景：您在芬兰图尔库港的一家货运公司的小团队中担任数据科学家，与另外三名数据科学家一起工作。90% 的进入芬兰的商品通过货运在国家的各个港口抵达。对于货运来说，天气条件和物流有时可能具有挑战性。雨天可能会扭曲港口的运营和物流，从而影响供应链运营。提前预测雨天条件可以使我们优化人力资源、物流和运输资源，以实现港口供应链运营的高效。从业务角度来看，提前预测雨天条件可以使港口通过高效规划和调度人力资源、物流和运输资源，将运营成本降低约 20%。

• 任务或解决方案：作为数据科学家，您被要求开发一个机器学习驱动的解决方案，以提前 4 小时预测芬兰图尔库港的天气状况。这将使港口能够优化其资源，从而实现高达 20% 的成本节约。为了开始，您将获得一个包含 10 年时间线的图尔库港历史天气数据集（数据集可通过本书的 Git 仓库访问）。您的任务是构建一个持续学习驱动的机器学习解决方案，以优化图尔库港的运营。

到目前为止，我们已经开发了机器学习模型并将它们作为 REST API 端点部署在 Kubernetes 集群中，地址为 20.82.202.164:80/api/v1/service/weather-prod-service/score（您的端点地址将不同）。

接下来，我们将为该端点复制一个真实的推断场景。为此，我们将使用我们在 第四章 的 机器学习管道 部分中分割并注册的测试数据集。前往您的 Azure ML 工作区，从 数据集 部分或与您的工作区连接的 Blob 存储下载 test_data.csv 数据集（该数据集已注册为 test_dataset），如图 12.5 所示：

![图 12.5 – 下载验证数据集（之前已分割并注册）

![img/image0051.jpg]

图 12.5 – 下载验证数据集（之前已分割并注册）

准备使用 REST API 端点或机器学习服务推断 test_data.csv 数据。前往 12_Model_Serving_Monitoring 文件夹，并将下载的数据集 (test_data.csv) 放入文件夹中。接下来，访问 inference. py 文件：

import json
import requests
import pandas as pd
data = pd.read_csv('test_data.csv')
data = data.drop(columns=['Timestamp', 'Location', 'Future_weather_condition'])

url = 'http://20.82.202.164:80/api/v1/service/weather-prod-service/score'
headers = {'Content-Type':'application/json'}

for I in range(len(data)):
            inference_data = data.values[i].tolist()
            inference_data = json.dumps(""dat"": [inference_data]})
            r = requests.post(url, data=inference_data, headers=headers)
            print(str(i)+str(r.content))

在前面的代码中，我们执行以下步骤：

1. 在 inference.py 文件中，首先导入必要的库，例如 json、requests 和 pandas。

2. 接下来，导入用于与端点推断的 test_data.csv 数据集。

3. 删除推理中不必要的列，如 Timestamp、Location 和 Future_weather_condition（我们将通过查询端点来预测这个最终列）。

4. 下一步，指向端点的 URL（您可以通过导航到 Azure ML 工作区 | 端点 | Weather-prod-service | 消费）来。为了简单起见，因为我们没有为该服务设置身份验证或密钥，所以我们有 application/JSON 的标题，没有密钥或身份验证。

5. 最后，我们将通过端点推断数组中的每个元素来遍历数据数组。要运行脚本，只需将 'url' 替换为您的端点，然后在终端（从文件夹位置）运行以下命令以执行脚本：

   >> python3 inference.py
   

运行脚本将花费大约 10-15 分钟来推断推理数据中的所有元素。之后，我们可以监控推理并分析推断数据的结果。让我们从数据完整性开始监控和分析。

监控您的机器学习系统

监控模块专门用于监控生产中的应用（即，提供机器学习模型）。动作监控模块具有以下三个功能：

• 数据完整性：

  • 注册目标数据集

  • 创建数据漂移监控器

  • 执行数据漂移分析

  • 执行特征漂移分析

• 模型漂移

• 应用性能

让我们更详细地查看这些功能。

数据完整性

要监控推理数据的数据完整性，我们需要监控数据漂移和特征漂移，以查看是否有任何异常变化或任何新的模式：

• 数据漂移：这是指独立变量的属性发生变化的情况。例如，由于季节性或新产品的添加、消费者需求或习惯的变化，数据可能会发生变化，就像在 COVID-19 大流行期间所发生的那样。

• 特征漂移：这是指特征（的）属性随时间变化的情况。例如，由于季节变化或季节性，温度在夏季比冬季或秋季的温度要暖和。

要监控漂移，我们将测量基线数据集与目标数据集之间的差异。第一步是定义基线数据集和目标数据集。这取决于用例；我们将使用以下数据集作为基线数据集和目标数据集：

• 基线数据集：这是训练数据集。

• 目标数据集：这是推理数据集。

我们将使用之前用于训练模型的训练数据集作为基线数据集。这是因为用于推理的模型非常了解训练数据集中的模式。训练数据集非常适合比较推理数据随时间的变化。我们将收集推理过程中收集的所有推理数据并将其编译到推理数据集中，并将这两个数据集（即基线数据集和目标数据集）进行比较，以评估目标数据集的数据和特征漂移。

注册目标数据集

训练数据集已在第四章的机器学习管道部分注册，在数据摄取和特征工程部分。我们需要在 Azure ML 工作区的数据集部分内注册推理数据集。

推理数据是使用 azureml.monitoring SDK（modelDataCollector 函数）收集的结果。通过在评分文件（在 score.py 中，正如我们在第六章的部署您的 ML 系统的关键原则中做的那样）中使用 modelDataCollector 函数启用监控功能，我们将推理数据以时间序列数据集的形式存储在 Blob 存储中。在连接到您的 Azure ML 工作区的 Blob 存储中，推理数据存储在 modeldata 容器中。在 modeldata 容器中，推理数据（包括输入和输出）以 CSV 文件的形式存储，这些文件被分在文件夹内。这些文件按照年份、月份和日期（在生产中记录推理数据时）进行结构化。在分区文件夹内，推理数据存储在名为 inputs.csv 和 outputs.csv 的 CSV 文件中。我们需要注册这些 input.csv 文件以监控数据漂移和特征漂移。按照以下步骤注册 input.csv 文件：

1. 前往数据集部分，点击创建数据集。然后，选择从数据存储选项，如图 12.6 所示：![图 12.6 – 注册推理数据集

   图 12.6 – 注册推理数据集

2. 为数据集命名（例如，Inputs-Inference-Dataset），选择数据集类型为表格型，并在描述字段中写入适当的描述，描述数据集的目的。点击下一步以指定数据存储选择。选择modeldata数据存储，如图 12.7 所示：![图 12.7 – 数据存储选择（输入-推理数据注册）

   图 12.7 – 数据存储选择（输入-推理数据注册）

3. 在选择 input.csv 文件后。您可以在您的 support vectorclassifier 模型 文件夹中找到它，该文件夹位于您的服务名称（例如，prod-webservice）文件夹内。然后，进入子文件夹（默认、inputs 以及按日期结构化的文件夹），并进入您当前日期的文件夹以找到 input.csv 文件。选择 input.csv 文件，如图 12.8 所示：![图 12.8 – 选择 input.csv 文件的路径（输入-推理数据注册）

   图 12.8 – 选择 input.csv 文件的路径（输入-推理数据注册）

4. 在选择 input.csv 文件后，点击 /**/inputs*.csv（如图 12.9 所示）。这是一个重要的步骤，将动态引用 inputs 文件夹中的所有 input.csv 文件。如果不引用所有 input.csv 文件，我们将路径限制为仅一个 input.csv 文件（如图 12.8 所示之前已选择）。通过引用所有 input.csv 文件，我们将所有输入数据（inputs.csv 文件）编译到目标数据集中（例如，Inputs-Inference-Data）：![图 12.9 – 引用路径以动态访问所有 input.csv 文件

   图 12.9 – 引用路径以动态访问所有 input.csv 文件

5. 点击下一步按钮进入设置和预览：![图 12.10 – 设置和预览（推理数据集注册）]

   

   图 12.10 – 设置和预览（推理数据集注册）

   如图 12.10 所示，我们可以配置设置并预览数据集。通过选择 列标题 下拉菜单并选择 从所有文件合并标题 来指向正确的列名。检查正确的列名（例如，Temperature_C 和 Humidity）。在选择了适当的列名后，点击 下一步 按钮进入下一个窗口。通过选择您想要监控的所有列及其数据类型，选择正确的模式，如图 12.11 所示：

   ![图 12.11 – 模式选择（推理数据集注册）]

   

   图 12.11 – 模式选择（推理数据集注册）

   确保你在 $aml_dc_scoring_timestamp 列中选择 时间戳 和 日期 属性，因为这些属性包含推理的时间戳。这一步很重要。只有时间序列格式的数据集才能用于计算漂移（通过 Azure 漂移模型）；否则，我们无法计算漂移。通过选择所有列来选择正确的模式后，点击 下一步 以确认所有必要的详细信息（例如数据集名称、数据集版本、其路径等）。

6. 点击创建按钮以创建数据集。当您的数据集创建成功后，您可以从 Azure ML 工作区的数据集部分查看数据集。转到数据集部分以确认您的数据集已创建。识别并点击您创建的数据集。点击后，您将能够查看您已注册的推理数据集的详细信息，如图图 12.12所示：

![图 12.12 – 查看已注册的推理数据集

图 12.12 – 查看已注册的推理数据集

您可以在图 12.12中看到您已注册数据集的所有基本属性。需要注意的是，相对路径是动态的，它指向引用所有的input.csv文件。所有输入文件的引用结果将显示在input.csv文件中，随着在 Blob 存储的数据存储中每天创建新的input.csv文件，这些文件的数量将持续增加。恭喜您注册了推理数据。接下来，我们将配置数据漂移监控器。

创建数据漂移监控器

为了监控数据漂移和特征漂移，我们将使用 Azure ML 工作区内置的漂移监控功能，作为我们 Azure ML 工作区上的Data Drift Monitor功能的一部分：

1. 前往您的 workspace 并访问数据集部分。然后，选择数据集监控器（目前处于预览模式，因为此功能仍在测试中）。点击创建，如图图 12.13所示：![图 12.13 – 创建数据漂移监控器

   图 12.13 – 创建数据漂移监控器

2. 在选择创建按钮后，系统将提示您创建一个新的数据漂移监控器。选择您所需的靶数据集。

3. 在注册靶数据集部分，我们将inputs.csv文件注册为Input-InferenceData。选择您的推理数据集作为靶数据集，如图图 12.14所示：![图 12.14 – 选择靶数据集

   图 12.14 – 选择靶数据集

4. 在选择您的靶数据集后，系统将提示您指向您的基线数据集，这应该是您的训练数据集（它被用来训练您的已部署 ML 模型）。选择您的基线数据集，如图图 12.15所示：![图 12.15 – 选择基线数据集和配置监控设置

   图 12.15 – 选择基线数据集和配置监控设置

5. 在选择基线数据集后，系统将提示您设置监控设置，例如数据漂移监控器的名称（例如，weather-Data-Drift）、运行数据漂移作业的计算目标、数据漂移作业的频率（例如，每天一次）以及监控漂移的阈值（例如，60）。您还将被要求提供一个电子邮件地址，以便在数据漂移超过设定的阈值时接收通知。

6. 在配置设置后，创建一个数据漂移监控器。转到您新创建的数据漂移（在数据集部分，点击数据集监控器以查看您的漂移监控器），如图图 12.16所示：![Figure 12.16 – 数据漂移概述（目前为空）

   ![img/image016.jpg]

   图 12.16 – 数据漂移概述（目前为空）

   当您访问您的数据漂移监控器时，您会看到没有数据。这是因为我们还没有计算任何漂移。为了计算漂移，我们需要一个计算资源。

7. 转到计算部分，访问计算集群选项卡，创建一个新的计算资源（例如，drift-compute – Standard_DS_V2 machine），如图图 12.17所示：![Figure 12.17 – Creating a compute cluster to compute data drift

   ![img/image0171.jpg]

   图 12.17 – 创建计算集群以计算数据漂移

8. 在创建计算集群后，返回您的数据漂移监控器（例如，Weather-Data-Drift）。接下来，我们将计算数据漂移。

9. 点击分析现有数据并提交一个运行以分析任何现有推断数据，如图图 12.18所示：![Figure 12.18 – Submitting run to analyze any data drift

   ![img/image018.jpg]

   图 12.18 – 提交运行以分析任何数据漂移

10. 选择开始和结束日期以及计算目标（即之前创建的，即drift-compute）。然后，点击提交以运行漂移计算。通常需要大约 10 分钟来分析和计算数据漂移。您可以在 Azure ML 工作区的实验部分跟踪您运行的进度。

    数据漂移分析：在成功完成运行后，数据漂移已经被计算。使用如图图 12.19所示的漂移概述，我们可以监控和分析您的 ML 模型在生产中的性能。我们可以通过特征查看数据漂移幅度和漂移分布：

![Figure 12.19 – Data Drift magnitude trend

![img/image019.jpg]

图 12.19 – 数据漂移幅度趋势

Azure ML 服务测量模型漂移的方式是使用一个独立的漂移模型（由 Azure 维护），该模型查看基线并比较推断数据。这种比较结果是一个简单的百分比或数据变化的程度。

在图 12.19中，漂移幅度趋势表明我们对模型进行了 3 天的推断（即03/23/21，04/03/21，和04/04/21）。

分析显示，这三次的数据漂移低于 70%的阈值（这是红线，表示阈值）。03/23/21的数据漂移大约为 50%；04/03/21大约为 44%；04/04/21为 40%。这给我们提供了一个关于模型接收到的推断数据变化趋势的线索。同样，我们可以监控特征漂移。

• 特征漂移分析：你可以通过滚动到特征详情部分并选择一个你喜欢的特征来评估单个特征及其漂移。例如，我们可以看到Temperature_C随时间分布的特征，如图图 12.20所示：

![图 12.20 – 特征漂移趋势（Temperature_C）

图 12.20 – 特征漂移趋势（Temperature_C）

为了监控特征随时间的变化，我们可以选择一些我们喜欢的特征指标。例如，平均值、最小值、最大值、欧几里得距离或Wasserstein 距离，这些指标可用于分析特征漂移。选择一个你喜欢的指标（例如，平均值）。我们选择了平均值指标来评估温度漂移，如图图 12.20所示。平均值指标从 14 变为 8，随着时间的推移发生了变化；这显示了Temperature_C特征漂移的变化。这种变化是预期的，因为季节性变化会导致温度的变化。我们还可以监控特征分布的变化，如图图 12.21所示：

![图 12.21 – 特征分布趋势

图 12.21 – 特征分布趋势

如果漂移剧烈或异常，我们需要检查被推断到系统中的输入数据的质量。对特征漂移的了解使我们能够理解周围不断变化的数据和世界。同样，我们可以监控模型漂移，以了解模型性能随数据和世界的变化。

模型漂移

监控模型漂移使我们能够监控我们的模型在生产中的性能。模型漂移是依赖变量属性发生变化的地方。例如，在我们的案例中，这是天气（即下雨或不下雨）的分类结果。正如我们在创建数据漂移监控器部分设置数据漂移一样，我们也可以设置模型漂移监控器来监控模型输出。以下是设置模型漂移的高级步骤：

1. 注册一个新的数据集（例如，Outputs.csv文件。输出数据集可以从数据集部分创建。在创建输出推理数据集时，选择重要的列（例如，未来天气条件）并将数据集转换为表格和时间序列格式（漂移只能在时间序列数据中计算）通过选择带有时间戳的列。

2. 从数据集部分创建一个新的监控器（例如，模型漂移监控器），然后点击数据集监控器。选择要监控的特征（例如，未来天气条件）并设置你想要监控的阈值。

3. 在概述中分析模型漂移（如图图 12.22所示）：

![图 12.22 – 提交运行以分析数据漂移

图 12.22 – 提交运行以分析数据漂移

如果您的模型漂移超过了设定的阈值，那么这可能是一个迹象，表明您应该重新训练或训练模型比较结果，这可以简单地表示为数据变化的百分比或程度。当数据漂移超过阈值（例如，70%）时，我们可以通过电子邮件通知管理员或产品所有者，或者采取部署另一个模型或重新训练现有模型等行动。使用智能操作，我们可以管理机器学习系统以产生最大价值。我们将在下一章中探讨管理机器学习系统的方法（第十三章，持续学习的机器学习系统管理）。到目前为止，我们已经实现了数据漂移、特征漂移和模型漂移的设置。接下来，让我们监控机器学习系统的应用程序性能。

应用性能

您已将机器学习服务以 REST API 端点形式部署，用户可以消费这些端点。我们可以使用 Azure Application Insights（由 Azure Monitor 启用）来监控这些端点。为了监控应用程序性能，访问应用洞察仪表板，如图 图 12.23 所示。转到您的 Azure ML 服务工作区中的 端点 部分，并选择您的机器学习模型部署在其上的 REST API 端点。点击 Application Insights url 以访问与您的 REST API 端点连接的应用洞察端点：

图 12.23 – 应用洞察概览

从 应用洞察概览 部分中，我们可以监控和分析您的机器学习服务的关键应用性能信息。此外，我们还可以从 概览 部分监控失败请求、服务器响应时间、服务器请求和可用性等信息，如图 图 12.24 所示：

图 12.24 – 应用洞察概览

基于这些指标和这些信息，我们可以监控应用性能。理想情况下，我们不应该有任何失败请求或长的服务器响应时间。为了更深入地了解应用性能，我们可以访问应用仪表板（通过点击屏幕顶部的按钮），如图 图 12.25 所示：

图 12.25 – 具有更详细性能评估的应用仪表板

从应用程序仪表板中，我们可以更详细地监控应用程序的性能。例如，我们可以监控应用程序的使用情况、可靠性和其他信息。在用途方面，唯一会话和用户是监控应用程序能够服务的唯一用户数量的关键信息。此外，平均可用性信息有助于评估服务对我们用户的可用性。有了这些信息，如果需要更多资源来服务用户，我们可以做出扩展决策。

我们可以通过评估诸如失败请求的数量、服务器异常和依赖性故障等信息来监控应用程序的可靠性。我们可以使用诸如平均服务器响应时间和 CPU 利用率等信息来监控响应性。理想情况下，应用程序不应有任何故障，如果有任何故障，我们可以通过访问事务搜索或日志，如图12.26所示，进行更深入的检查：

![Figure 12.26 – Accessing the logs to understand any errors or failures

![img/image026.jpg]

图 12.26 – 访问日志以了解任何错误或故障

我们可以更仔细地查看应用程序的日志，以了解任何故障或错误，以便调试应用程序并维护应用程序的健康运行。一个功能性的机器学习应用程序会导致用户满意和最大的商业影响。因此，监控应用程序可以揭示潜在的故障并维护应用程序，以便以最有效的方式为用户提供服务。

分析您的机器学习系统

在生产环境中实时监控和分析您的机器学习系统对于理解机器学习系统的性能和确保其稳健性以产生最大化的商业价值至关重要。人类在分析模型性能和检测细微异常和威胁中扮演着关键角色。我们可以通过应用高级技术，如数据切片、对抗攻击预防技术，或通过理解局部和全局解释来分析模型性能，以检测任何偏差或威胁，并理解模型为何以某种模式做出决策。

数据切片

对于我们的用例，我们将省略数据切片，因为我们没有太多关于人口统计学或数据样本（例如，性别、年龄组等）的多样性。为了衡量模型的公平性，我们将专注于偏差检测。

偏差和威胁检测

为了确定生产中的模型偏差，我们可以使用偏差-方差权衡方法。这使得监控和分析模型偏差或任何可能的威胁变得简单。不言而喻，可能存在更好的方法来监控偏差，但这里的想法是保持简单，因为有时简单更好、更高效。

我们模型平均预测值与我们试图预测的正确值之间的差异是偏差。方差是模型对给定数据点或值的估计的变异性，它告诉我们我们的数据分布。分析部署模型的推理数据的偏差和方差揭示了偏差为 20.1，方差为 1.23（你可以在machinelearningmastery.com/calculate-the-bias-variance-trade-off/上了解更多关于偏差和方差分析的内容）。这意味着我们的模型具有高偏差和低方差；因此，使用推理数据训练或重新训练我们的模型以平衡偏差-方差可能是一个好主意。

本地解释和全局解释

本地解释和全局解释提供了对模型性能的不同视角。本地解释为特定或单个输入的模型预测提供了合理性，而全局解释则提供了对模型预测过程的洞察，不受任何特定输入的影响。我们在探索图 12.19中的监控漂移时，之前已经研究了全局解释。我们可以进一步调查特征分布，如图图 12.21所示，以详细了解本地解释。

分析你的 ML 系统以公平性、偏差以及本地和全局解释，为我们提供了对模型性能的关键洞察，我们可以利用这些信息来治理我们的 ML 系统。

管理你的 ML 系统

系统治理的大部分工作涉及质量保证和控制、模型审计以及报告，以确保端到端的可追踪性和符合法规。ML 系统的有效性（即其产生预期或意图结果的能力）取决于其治理方式，以实现最大商业价值。到目前为止，我们已经监控并分析了我们的部署模型用于推理数据：

图 12.27 – 管理你的 ML 系统的组件

ML 系统的有效性可以通过基于监控和警报采取的智能行动来确定。在下一章中，我们将探讨 ML 系统治理，包括警报和行动、模型 QA 和控制以及模型审计和报告。

摘要

在本章中，我们学习了向用户提供服务 ML 模型以及监控它们以实现最大商业价值的关键原则。我们探讨了为模型用户或消费者提供 ML 模型的不同方式，并为一个假设的商业用例实现了可解释监控框架并部署了一个模型。我们进行了可解释监控框架的动手实现，以衡量 ML 系统的性能。最后，我们讨论了治理 ML 系统的必要性，以确保 ML 系统的稳健性能。

我们将在下一章和最后一章进一步探讨 ML 系统的治理和持续学习概念！

第十三章：治理持续学习的机器学习系统

在本章中，我们将反思机器学习（ML）解决方案中持续学习的必要性。适应是机器智能的核心。适应得越好，系统就越好。持续学习专注于外部环境并适应它。为机器学习系统启用持续学习可以带来巨大的好处。我们将探讨在探索持续学习和研究可解释监控框架的治理组件时，成功治理机器学习系统所需的内容，该框架帮助我们控制和治理机器学习系统以实现最大价值。

我们将深入探讨通过启用警报和操作功能来实现治理的实战实施。接下来，我们将探讨确保模型质量和控制部署的方法，以及我们将学习生成模型审计和报告的最佳实践。最后，我们将了解使模型重新训练和维护 CI/CD 管道的方法。

让我们先反思一下持续学习的必要性，然后继续探讨本章中的以下主题：

• 理解持续学习的必要性

• 使用可解释监控来治理机器学习系统

• 启用模型重新训练

• 维护 CI/CD 管道

理解持续学习的必要性

当我们在第一章，“MLOps 工作流程基础”中开始时，我们了解到为什么人工智能在组织中的采用受到阻碍。其中一个原因是机器学习系统中缺乏持续学习。是的，持续学习！我们将在本章中解决这个挑战，并确保我们能够在本章结束时学会如何启用这种功能。现在，让我们来看看持续学习。

持续学习

持续学习建立在持续从数据、人类专家和外部环境中学习的原则之上。持续学习使终身学习成为可能，其核心是适应。它使机器学习系统能够随着时间的推移变得智能，以适应手头的任务。它是通过监控和学习环境和协助机器学习系统的人类专家来做到这一点的。持续学习可以是一个强大的机器学习系统附加功能。它可以让你随着时间的推移实现人工智能系统的最大潜力。持续学习非常值得推荐。让我们来看一个例子：

![图 13.1 – 贷款发放官员 – 传统系统与由人类辅助的机器学习系统

图 13.1 – 贷款发放场景 – 传统系统与由人类辅助的机器学习系统

与组织中的传统流程（完全依赖人类员工）相比，部署一个模型（由持续学习驱动）具有几个优势。例如，在前面的图表中，我们可以看到银行贷款审批流程的两个案例。第一种场景是由人类专家（例如在传统银行设置中）驱动的。第二种场景是使用机器学习系统自动化或增强流程，以筛选申请、谈判、提供贷款申请最终审批（在此过程中，人类专家审查机器学习系统的决策并批准或拒绝它），以及批准贷款。传统设置的审批时间为一周，而机器学习系统（与人类专家合作）的审批时间为 6 小时。

由于机器学习系统在人类助理的帮助下持续学习和改进，因此它对银行来说更快且更具可持续性。人类员工在公司或工作中有固定的雇佣期限。当他们离开时，他们的领域专业知识也随之消失，培训新员工或为同一任务招聘新员工是昂贵的。另一方面，随着时间推移，与人类专家合作或由人类专家辅助的机器学习模型能够随着时间的推移不断学习并保留知识（就时间而言）。与传统的、人类员工不断变化的方法相比，机器学习系统（与人类专家一起）获得的持续学习可以永久保留。从长远来看，持续学习可以为机器学习系统和业务释放巨大价值。

持续学习的需求

以下图表展示了为什么需要持续学习以及它如何增强您的机器学习系统以最大化您的商业价值：

![图 13.2 – 持续学习的益处

图 13.2 – 持续学习的益处

让我们详细探讨持续学习的益处：

• 适应性：在大多数直接应用中，数据漂移可能随着数据的持续流入而保持不变。然而，许多应用具有动态变化的数据漂移，例如推荐系统或异常检测系统，其中数据持续流动。在这些情况下，持续学习对于适应和准确预测至关重要。因此，适应数据和环境的不断变化性质是很重要的。

• 可扩展性：由 IDC 发布的白皮书（www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf）指出，到 2025 年，数据生成的速度将增长到每年 160 ZB，我们将无法存储所有这些数据。该论文预测，我们只能存储 3%到 12%的数据。数据需要即时处理；否则，由于存储基础设施无法跟上产生的数据，数据将会丢失。这里的诀窍是只处理一次传入的数据，只存储必要的信息，然后丢弃其余部分。

• 相关性：ML 系统的预测需要具有相关性并适应不断变化的环境。持续学习是保持 ML 系统在变化的环境和环境中高度相关和有价值的必要条件。

• 性能：持续学习将使 ML 系统具有高性能，因为它通过适应不断变化的数据和环境来使 ML 系统保持相关性。换句话说，更具相关性将提高 ML 系统的性能，例如，在准确性或其他指标方面，通过提供更有意义或更有价值的预测。

由于这些原因，在 ML 系统中需要持续学习，否则我们无法达到 ML 系统所能提供的最大价值。换句话说，项目注定会失败。持续学习是 AI 项目成功的关键。作为可解释监控的一部分，有效的治理策略可以促进持续学习。持续学习的一个重要部分是模型重新训练，这样我们才能应对不断变化的数据并做出相关决策。为此，我们可以将可解释监控和模型重新训练结合起来，以实现持续学习：

可解释监控 + 模型重新训练 = 持续学习

接下来，我们将深入探讨持续学习的应用。现在，让我们探讨如何将有效的管理制度引入 ML 系统。

可解释的监控 – 管理制度

在本节中，我们将实现我们在第十一章“监控您的 ML 系统的关键原则”中学习到的治理机制，应用于我们一直在工作的业务案例。我们将深入研究管理 ML 系统的三个组成部分，如下面的图所示：

图 13.3 – 管理您的 ML 系统的组件

机器学习系统的有效性取决于它们如何被管理以最大化商业价值。为了实现端到端的可追踪性和符合法规，系统治理需要质量保证和监控、模型审计和报告。我们可以通过监控和分析模型输出来规范和规则机器学习系统。智能警告和行为指导治理以优化商业价值。让我们看看机器学习系统的治理是如何通过警告和行为、模型质量保证和控制、模型审计和报告来编排的。

警报和操作

警报是通过执行计划检查来检测条件生成的。一旦满足条件，就会生成警报。基于生成的警报，我们可以执行操作。在本节中，我们将了解这些元素以及它们是如何编排来管理机器学习系统的。

什么是警报？

警报是一个在后台运行的计划任务，用于监控应用程序以检查是否检测到特定条件。警报由以下三个因素驱动：

• 计划：我们应该多久检查一次条件？

• 条件：需要检测什么？

• 操作：当检测到条件时，我们应该做什么？

我们可以根据应用程序性能创建警报来监控以下方面：

• 基于阈值的可用性警报

• 基于阈值的失败请求警报

• 基于阈值的响应时间警报

• 基于阈值的服务器异常警报

• 基于数据漂移阈值的警报

• 基于模型漂移阈值的警报

• 基于错误或异常的警报

管理机器学习系统的一个重要领域是处理错误，因此让我们将注意力转向错误处理。

处理错误

在应用程序中，潜在的错误总是可能的。我们可以通过解决我们机器学习应用程序的所有可能的边缘情况来预见它们。使用以下图表中显示的框架，我们可以解决这些错误。这个框架的目的是识别边缘情况和自动调试方法来处理可能的错误。这将使机器学习服务保持运行：

图 13.4 – 调试和调查错误的框架

如前图所示，我们首先识别可能存在错误的地方，并选择一个资源来处理该错误。选择资源后，我们通过检查资源的高利用率以及资源饱和度（资源饱和是指其容量已完全利用或超过设定的阈值）来检查错误。在出现任何问题的情况下，我们通过检查日志和制定解决方案来处理任何错误。最终，我们通过使用预先编写的脚本来处理任何问题（例如，通过重启资源或重新加载一个函数或文件，以使资源在健康状态下运行）来自动化调试。

通过解决所有可能的边缘情况并制定自动错误处理或调试，我们可以使我们的应用程序无故障，以服务于我们的用户。拥有无故障的应用程序可以确保用户在使用机器学习应用程序时获得无缝的体验和价值。一旦你识别出错误，通过调查或创建自动调试过程来解决它。毕竟，预防胜于治疗。因此，检查所有可能的边缘情况并在事先解决它们是有益的。

我们可以通过使用异常处理功能来处理潜在的错误。异常处理是一种编程技术，用于处理需要特殊关注的情况。在 Python 中，实现广泛的错误类型的异常处理很容易。我们可以使用 try、except、else 和 finally 功能来处理错误和异常，如下图所示：

![图 13.5 – 处理异常和边缘情况

图 13.5 – 处理异常和边缘情况

在 try 子句中遇到异常之前，所有语句都会被执行。在 try 子句中找到的异常会被 except 块捕获和处理。else 块允许你编写只有在 try 子句中没有异常时才能运行的代码。使用 finally，无论之前是否遇到过异常，都可以运行应该始终运行的代码部分。

这里列出了一些可能常见的异常或错误，需要注意：

这些边缘情况或错误很常见，可以通过在应用程序中使用 try 和 exception 技术来解决。策略是减轻用户可能会觉得你的机器学习系统非常基础或天真的情况；例如，一个在聊天中发送错误信息的聊天机器人。在这种情况下，错误的代价很高，用户可能会失去对机器学习系统的信任。

我们将为我们一直在实施的业务用例实现一些自定义异常和错误处理，并根据生成的警报执行操作。让我们开始吧：

1. 在您的 Azure DevOps 项目中，前往我们的 13_Govenance_Continual_Learning。从那里，访问 score.py 文件。我们将首先导入所需的库。这次，我们将使用 applicationinsights 库来跟踪与端点连接的 Application Insights 的自定义事件或异常：

   import json
   import numpy as np
   import os
   import pickle
   import joblib
   import onnxruntime
   import logging
   import time
   from azureml.core.model import Model
   from applicationinsights import TelemetryClient
   from azureml.monitoring import ModelDataCollector
   from inference_schema.schema_decorators import input_schema, output_schema
   from inference_schema.parameter_types.numpy_parameter_type import NumpyParameterType
   

   如前述代码所示，我们已经从 applicationinsights 库中导入了 TelemetryClient 函数。我们将使用 TelemetryClient 函数来访问连接到我们端点的 Application Insights。将 Application Insights 的仪表化密钥提供给 TelemetryClient 函数。

2. 此 Instrumentation Key 可从您的 Application Insights 访问，它应连接到机器学习应用程序，如下面的截图所示：

   图 13.6 – 从 Application Insights 获取仪表化密钥

3. 在获取您的 TelemetryClient 函数后，如下述代码所示。在这里，我们在 tc 变量中创建了一个 TelemetryClient 对象，用于跟踪自定义事件：

   def init():
       global model, scaler, input_name, label_name, inputs_dc, prediction_dc, tc
           init function to monitor whether a FileNotFound error occurs when we load the scaler and model artifacts. If a file is not found, the tc.track_events() function will log the error message that's generated by the exception and tag the custom code 101. 
   

4. 同样，我们将在 run 函数中实现一些其他自定义事件 – 即，ValueNotFound、OutofBoundsException 和 InferenceError –：

   @input_schema('data', NumpyParameterType(np.array([[34.927778, 0.24, 7.3899, 83, 16.1000, 1016.51, 1]])))
   @output_schema(NumpyParameterType(np.array([0])))
   def run(data):
               try:              
                   inputs_dc.collect(data)
               except Exception as e:
                   try and except to collect incoming data using the model data collector function. This collects the incoming data and stores it in the blob storage connected to the Azure ML service. If the incoming data contains some anomalous data or a missing value, an exception is raised. We will raise a ValueNotFound error using the track_event function so that we can log the exception message and custom code (in this case, a random or custom number of 201 is given to track the error). After collecting the incoming data, we will attempt to scale the data before inference:
   
   

   try:

   缩放传入数据

   data = scaler.transform(data)

   except Exception as e:

   在此情况下，try 和 except 可能很有用，因为我们正在尝试使用在 init 函数中加载的缩放器文件来缩放数据。如果缩放数据不成功，则会引发异常。在这里，我们使用 track_event 函数在 Application Insights 上跟踪异常。如果生成异常，我们将生成一个名为 ScalingError 的自定义事件。在 Application Insights 上记录一个异常消息和错误代码 301。同样，处理评分文件的最重要步骤 – 模型推理 – 需要细致入微地进行。现在，我们将再次使用 try 和 except 来确保推理成功且没有任何异常。让我们看看我们如何处理这种情况下的异常。请注意，我们正在访问 model.run 函数的元素编号 2。这导致模型推理时出现错误，因为我们正在引用列表中的错误或不存在的元素：

               try:        
                   # model inference
                   result = model.run([label_name], {input_name: 
   data.astype(np.float32)})[2]
   # this call is saving model output data into Azure Blob
                   prediction_dc.collect(result)
                   if result == 0:
                       output = "Rain"                 
                   else: 
                       output = "No Rain"
                   return output
               except Exception as e:
   track_event() function to generate a custom event called InferenceError. This will be logged on Application Insights with an error message and a custom error code of 401. This way, we can log custom errors and exceptions on Application Insights and generate actions based on these errors and exceptions. 
   

现在，让我们看看如何使用错误日志在 Application Insights 中调查这些错误并为其生成操作。

设置操作

我们可以根据之前创建的异常事件（在 处理错误 部分中）设置警报和操作。在本节中，我们将根据我们生成的警报设置一个电子邮件通知形式的操作。每当在 Application Insights 中生成异常或警报时，我们都会通过电子邮件收到通知。然后，我们可以进行调查并解决它。

通过访问应用洞察（Application Insights），我们可以设置一个动作（电子邮件）来接收警报，该应用洞察应连接到您的机器学习系统端点。您可以通过 Azure ML 工作区访问应用洞察。让我们开始吧：

1. 前往端点并检查应用洞察。一旦您访问了应用洞察仪表板，点击事务搜索，如下面的截图所示，以检查您的自定义事件日志（例如，推理异常）：![图 13.7 – 检查自定义事件日志

   图 13.7 – 检查自定义事件日志

2. 您可以通过日志检查在异常和错误发生时生成的自定义事件，然后为这些自定义事件设置警报和动作。要设置警报和动作，请转到监控 > 警报部分并点击新建警报规则，如下面的截图所示：![图 13.8 – 设置新的警报规则

   图 13.8 – 设置新的警报规则

3. 在这里，您可以根据警报创建动作的条件。要设置条件，请点击添加条件。您将看到一个可以用来创建条件的信号或日志事件的列表。选择InferenceError，如下面的截图所示：![图 13.9 – 配置条件

   图 13.9 – 配置条件

4. 选择您选择的信号或事件后，您将可以配置其条件逻辑，如下面的截图所示。通过设置一个阈值来配置条件。在这种情况下，我们将提供一个阈值为400，因为错误会引发一个值为401（因为我们为InferenceError事件提供了一个自定义的值为401）。当发生推理异常时，它会引发一个值高于400的InferenceError（确切地说是401）：![图 13.10 – 配置条件逻辑和阈值

   图 13.10 – 配置条件逻辑和阈值

5. 设置阈值后，您将需要配置其他动作，例如运行自动化运行手册、Azure Function、逻辑应用或安全 Webhook，如下面的截图所示。目前，我们不会提示这些动作，但了解我们有这些动作是好的，因为我们可以运行一些脚本或应用程序作为备份机制来自动化错误调试：![图 13.11 – 自动化调试的动作（可选）

   图 13.11 – 自动化调试的动作（可选）

   这样，我们就可以通过预先配置的脚本或应用程序来自动化调试，以防发生错误或防止错误。毕竟，预防胜于治疗！

6. 最后，我们将创建一个条件。点击审查和创建以创建条件，如前面的截图所示。一旦创建了此条件，您将在创建警报规则面板中看到它，如下面的截图所示。接下来，通过点击添加动作组然后创建动作组来设置一个动作：![图 13.12 – 创建动作组

   图 13.12 – 创建动作组

7. 提供一个电子邮件地址，以便您可以接收通知，如下面的截图所示。在这里，您可以在警报规则名称字段中命名您的通知，并提供设置电子邮件警报动作所需的信息：![图 13.13 – 配置电子邮件通知

   图 13.13 – 配置电子邮件通知

   在提供所有必要信息，包括电子邮件后，点击审查 + 创建按钮来配置动作（基于错误的电子邮件）。最后，提供如警报规则名称、描述和严重性之类的警报规则详细信息，如下面的截图所示：

   ![图 13.14 – 配置电子邮件通知

   图 13.14 – 配置电子邮件通知

8. 点击InferenceError)。有了这个，您已经创建了一个警报，现在是时候测试它了。转到13_Govenance_Continual_Learning文件夹，访问test_inference.py脚本（将 URL 替换为您的端点链接）。然后，通过运行以下命令来运行脚本：

   python3 test_inference.py
   

9. 运行脚本将输出错误。在执行一些推理后停止脚本。在错误发生后的 5-10 分钟内，您将通过电子邮件收到错误通知，如下面的截图所示：

![图 13.15 – 生产中的错误电子邮件通知

图 13.15 – 生产中的错误电子邮件通知

恭喜您 – 您已成功设置了一个错误的电子邮件动作警报！这样，您就可以在发现错误时进行调查，以便解决它并使系统恢复正常运行。

接下来，让我们看看如何确保我们有模型的质量保证，并且可以控制它们以最大化商业价值。

模型问答和控制

数据的演变或动态变化导致预测错误率增加。这可能是由于业务和外部环境的变化导致的数据漂移，或者可能是由于数据中毒攻击。预测错误率的增加导致在重新训练（手动或自动）时必须重新评估机器学习模型，从而发现比之前更准确的新算法。以下是一些使用新数据测试机器学习模型的指南：

• 通过重新训练模型并评估其性能来启用持续学习。

• 在定期间隔内评估所有模型在新的数据集上的性能。

• 当替代模型开始提供比现有模型更好的性能或更高的准确性时，发出警报。

• 维护包含最新性能细节和报告的模型注册表。

• 维护所有模型的端到端血缘，以便重现它们或向利益相关者解释其性能。

模型审计和报告

建立 MLOps 的定期审计和报告系统是一种良好的做法，因为它使组织能够端到端地跟踪其运营，并遵守法律，在需要时向利益相关者解释其运营。我们可以确保机器学习系统符合在社会和政府层面已经建立和审议的惯例。为了审计和报告 MLOps，建议审计员检查以下图像所示的审计基础：

![Figure 13.16 – ML Operations 审计报告的基本要素]

![img/B16572_13_016.jpg]

Figure 13.16 – ML Operations 审计报告的基本要素

数据审计

数据是驱动许多机器学习系统决策的因素。因此，审计员在审计和报告中需要考虑数据，检查训练数据，测试数据，推断数据，并监控数据。这是至关重要的，并且对于 MLOps 来说，拥有端到端的可追溯性以跟踪数据的使用（例如，哪个数据集用于训练哪个模型）是必要的。拥有类似“数据 Git”的机制，可以对数据进行版本控制，可以使得审计员能够引用、检查和记录数据。

模型审计（公平性和性能）

机器学习系统的审计员需要具备黑客心态，以识别模型可能失败的不同方式以及无法给出公平预测的情况。首先，审计员会检查训练数据，并使用可解释人工智能技术将其与推理数据进行比较。这有助于审计员对每个模型及其每个预测在个体层面上做出公平的判断。为了对每个模型进行公平性和性能评估，我们可以使用数据切片技术，这可以揭示对评估有价值的宝贵信息。因此，审计员请求所需人口统计数据和数据切片的数据切片结果是有价值的。为了进行集体评估，我们可以比较模型并评估其性能。这可以揭示关于公平性和性能评估的另一个信息角度。

如果进行模型审计，它将评估模型的输入（训练数据）、模型本身及其输出。需要评估数据的一致性和训练数据中可能存在的偏差。例如，如果简历筛选模型是在候选人收到工作邀请和工人晋升的先前或历史决策上训练的，我们想确保训练数据没有受到过去招聘人员和经理的隐含偏见的影响。与竞争模型进行基准测试、执行统计测试以确保模型从训练推广到未知结果，以及使用最先进的技术以允许模型可解释性，都是模型评估过程的一部分。

项目和治理审计

审计算法是否需要深入了解 AI 模型？当然不是。对 AI 系统进展的审计就像项目管理审计一样。是否有明确的期望成果目标？如果政府实体在特定环境中实施了 AI，这是一个很好的、直接的问题。此外，如果外部开发者被应用于 AI 系统，在开发者离开后，是否有可行的框架来管理模型？为了减少对专业知识的需要，公司必须对概念创建有广泛的文档记录，并拥有熟悉该模型的员工。因此，审计开发和治理实践从长远来看是有益的。

审计数据考虑因素、模型公平性和性能，以及 ML 系统的项目管理与治理，可以提供一个全面的 MLOps 视图。使用错误警报和操作，我们可以及时调查错误，使系统恢复正常运行，在某些情况下，我们甚至可以进行自动化调试以自动化错误解决和 MLOps。最后，通过进行模型质量保证、控制和审计，我们可以确保 MLOps 的有效治理。接下来，我们将探讨如何启用模型重新训练，以便我们的 ML 系统具有持续学习的能力。

启用模型重新训练

到目前为止，我们已经讨论了什么是模型漂移以及如何识别它。那么，问题来了，我们应该如何应对它？如果一个模型的预测性能由于环境变化而下降，解决方案是使用代表当前情况的新训练集重新训练模型。你的模型应该重新训练多少次？你如何选择你的新训练计划？以下图表显示了基于模型重新训练功能触发的构建模块，该模块基于监控模块的结果。有两种方式可以触发模型重新训练功能。一种是通过手动操作，另一种是通过自动化模型重新训练功能。让我们看看我们如何启用这两种方式：

![图 13.17 – 在 MLOps 工作流程中启用模型重新训练

![img/B16572_13_017.jpg]

图 13.17 – 在 MLOps 工作流程中启用模型重新训练

手动模型重新训练

产品负责人或质量保证经理有责任确保手动模型重新训练成功。手动模型触发步骤包括评估模型漂移，如果它超过了一个阈值（你需要确定一个漂移阈值，以触发模型重新训练），那么他们必须通过使用新的数据集（这可以是之前的训练数据集和最新的推理数据）来训练模型来触发模型训练过程。这样，产品负责人或质量保证经理对整个过程有完全的控制权，并且知道何时以及如何触发模型重新训练，以从机器学习系统中获得最大价值。

自动化模型重新训练

如果你想要完全自动化 MLOps 管道，自动化模型漂移管理可以是一个重新训练生产模型的理想方法。自动化模型漂移管理是通过配置监控应用程序诊断和模型性能的批量作业来完成的。然后，你必须激活模型重新训练。自动化模型漂移管理的关键部分是设置将自动触发重新训练模型功能的阈值。如果漂移监控阈值设置得太低，你可能会面临需要频繁重新训练的风险，这会导致高昂的计算成本。如果阈值设置得太高，你可能会面临不够频繁地重新训练的风险，导致生产模型次优。确定正确的阈值比看起来要复杂，因为你必须确定你需要多少额外的训练数据来反映这一新现实。即使环境已经改变，用一个非常小的训练集替换现有模型也是没有意义的。一旦你确定了阈值，你就可以有作业（例如，作为 CI/CD 管道的一部分）定期比较实时数据集的特征分布与训练数据上的特征分布（正如我们在第十二章，模型服务和监控中所做的那样）。当检测到大的偏差（或超过定义的阈值）时，系统可以安排模型重新训练并自动部署新模型。这可以通过使用工作调度程序（例如，Jenkins 或 Kubernetes 作业或 CI/CD 管道 cron 作业）来完成。这样，你可以完全自动化 MLOps 管道和模型重新训练部分。

注意，在数据流入量低或你偶尔进行批量推理（例如，每 6 个月一次）的情况下重新训练模型是没有意义的。你可以在推理之前或在你需要的时候定期训练模型。

维护 CI/CD 管道

如您所忆，在第十章“生产发布要素”中，我们提到模型不是产品；管道才是产品。因此，在设置自动化或半自动化 CI/CD 管道后，监控我们管道的性能至关重要。我们可以通过检查 Azure DevOps 中的发布来实现这一点，如下面的截图所示：

![图 13.18 – 维护 CI/CD 管道发布

![img/B16572_13_018.jpg]

图 13.18 – 维护 CI/CD 管道发布

检查的目标是保持 CI/CD 管道处于健康和稳健的状态。以下是一些保持 CI/CD 管道健康和稳健的指南：

• 如果构建失败，团队应实施立即修复的政策。

• 集成自动化验收测试。

• 需要提交拉取请求。

• 对每个故事或功能进行同行代码审查。

• 定期审计系统日志和事件（建议）。

• 定期向所有团队成员公开报告指标（例如，通过 slackbot 或电子邮件通知）。

通过实施这些实践，我们可以避免高失败率，并使 CI/CD 管道对所有团队成员来说都稳健、可扩展和透明。

摘要

在本章中，我们学习了 ML 解决方案持续学习的核心原则。我们通过实际错误处理和配置使用电子邮件通知提醒开发者的操作，学习了可解释监控（治理组件）。最后，我们探讨了启用模型重新训练以及维护 CI/CD 管道的方法。这样，您已经具备了自动化和治理 MLOps 的关键技能，以应对您的用例。

恭喜您完成这本书！MLOps 的世界正在不断进化，变得越来越好。您现在已经准备好利用 MLOps 来帮助您的业务繁荣。希望您在完成动手实践 MLOps 实现的过程中享受阅读和学习。走出舒适区，成为您希望看到的改变。祝您在 MLOps 的努力中一切顺利！