MLOps-入门指南-全-

MLOps 入门指南（全）

原文：zh.annas-archive.org/md5/6f18924049921c44972a0a8441e20e59

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

我们已经到达了机器学习故事中的一个转折点，技术已经从理论和学术领域进入了“现实世界”——也就是说，各种业务为全球人们提供各种服务和产品。尽管这种转变令人兴奋，但也充满挑战，因为它将机器学习模型的复杂性与现代组织的复杂性结合在一起。

当组织从机器学习的实验阶段转向在生产环境中扩展时，一个困难是维护。公司如何从管理单一模型转向管理数十、数百甚至数千个模型？这不仅是 MLOps 发挥作用的地方，也是前述的技术和商业复杂性出现的地方。本书将向读者介绍当前面临的挑战，并提供关于开发 MLOps 能力的实际见解和解决方案。

本书适合的读者

我们专门为分析和 IT 运营团队经理撰写了本书，也就是说，直接面对在生产环境中扩展机器学习（ML）任务的人员。考虑到 MLOps 是一个新领域，我们编写本书作为创建成功的 MLOps 环境的指南，从组织到涉及的技术挑战。

本书的组织结构

本书分为三个部分。第一部分是 MLOps 主题的介绍，深入探讨了它作为一门学科的发展方式（以及为何发展）、成功执行 MLOps 所需的参与者以及所需的组件。

第二部分大致遵循机器学习模型的生命周期，包括开发模型、准备生产、部署到生产、监控和治理的章节。这些章节不仅涵盖了一般考虑因素，还详细介绍了生命周期各阶段的 MLOps 考虑事项，提供了有关第三章中提到的主要 MLOps 特性的更多细节。

最后一部分提供了实际例子，展示了 MLOps 在当今公司中的实际运用情况，使读者能够了解设置和实践中的影响。尽管公司名称是虚构的，但这些故事基于真实公司在 MLOps 和规模化模型管理方面的经验。

本书使用的约定

本书使用以下排版约定：

斜体

表示新术语、URL、电子邮件地址、文件名和文件扩展名。

等宽字体

用于程序列表，以及在段落内引用程序元素，例如变量或函数名称、数据库、数据类型、环境变量、语句和关键字。

等宽粗体

显示用户应该逐字输入的命令或其他文本。

等宽斜体

显示用户应替换为用户提供的值或由上下文确定的值的文本。

致谢

我们要感谢整个 Dataiku 团队在本书的开发过程中对我们的支持，从构思到完成。这是一次真正的团队努力，与 Dataiku 大多数项目一样，根植于无数人和团队之间的基本合作。

感谢那些从一开始就支持我们与 O’Reilly 撰写本书的人。感谢那些加入到写作和编辑中来帮助的人。感谢那些提供真诚反馈的人（即使这意味着更多的写作、重写和再重写）。感谢那些内部的啦啦队员们，当然也感谢那些帮助我们向世界推广成品的人。

第一部分： MLOps: 什么是 MLOps，以及为什么需要它

第一章：为何现在及挑战

机器学习运维（MLOps）迅速成为企业中成功部署数据科学项目的关键组成部分 (图 1-1)。这是一个帮助组织和业务领导者产生长期价值并降低与数据科学、机器学习和人工智能倡议相关风险的过程。然而，这是一个相对较新的概念；那么为什么它似乎一夜之间飙升到数据科学词汇中呢？本章介绍 MLOps 在高层次上的概述，它的挑战，为何它对企业成功的数据科学战略至关重要，以及为何现在成为前沿。

图 1-1. MLOps 指数增长的表现（而非“模型运维”术语的平行增长）

定义 MLOps 及其挑战

MLOps 的核心是标准化和优化机器学习生命周期管理（图 1-2）。但退一步想，为什么需要优化机器学习生命周期呢？从表面上看，仅仅从业务问题到机器学习模型的步骤在非常高的层面上似乎是直观的。

对于大多数传统组织而言，多个机器学习模型的开发和在生产环境中的部署相对较新。直到最近，模型数量可能在小规模范围内是可管理的，或者公司范围内对了解这些模型及其依赖关系的兴趣很少。随着决策自动化的增加（即决策在没有人类干预的情况下进行的增加），模型变得更加关键，与此同时，在公司层面管理模型风险变得更加重要。

在企业设置中，机器学习生命周期的现实要复杂得多，涉及需求和工具的复杂性 (图 1-3)。

图 1-2. 机器学习模型生命周期的简单表示，通常低估了与图 1-3 相比 MLOps 的需求。

管理大规模机器学习生命周期面临三个主要挑战的原因有三点：

• 存在许多依赖关系。数据不仅在不断变化，业务需求也在变化。必须持续向业务反馈结果，以确保生产环境中的模型现实与生产数据的预期一致，并且至关重要地解决原始问题或实现原始目标。

• 并非每个人都说同样的语言。尽管机器学习生命周期涉及来自业务、数据科学和 IT 团队的人员，但这些群体没有人使用相同的工具，甚至在许多情况下，也没有分享相同的基本技能以作为沟通的基础。

• 数据科学家不是软件工程师。大多数人专注于模型构建和评估，并不一定擅长编写应用程序。虽然随着一些数据科学家逐渐成为部署或运营方面的专家，这种情况可能会发生变化，但目前许多数据科学家发现自己不得不承担许多角色，这让他们难以彻底完成任何一项工作。当需要管理越来越多的模型时，数据科学家的压力会随着规模的扩大而变得尤为棘手。考虑到数据团队人员的流动性，数据科学家突然间不得不管理他们没有创建的模型，这种复杂性变得非常庞杂。

图 1-3。今天平均组织内的机器学习模型生命周期的现实图景，其中涉及许多拥有完全不同技能集的人，他们通常使用完全不同的工具。

如果定义（或者甚至是名称 MLOps）听起来很熟悉，那是因为它很大程度上借鉴了 DevOps 的概念，它简化了软件变更和更新的实践。事实上，这两者有很多共同点。例如，它们都围绕着：

• 坚固的自动化和团队之间的信任

• 协作和团队间增加的沟通概念

• 端到端的服务生命周期（构建、测试、发布）

• 优先考虑持续交付和高质量

然而，MLOps 与 DevOps 之间有一个关键差异，使得后者不能立即转移到数据科学团队：将软件代码部署到生产环境与将机器学习模型部署到生产环境根本是两回事。尽管软件代码相对静态（“相对”是因为许多现代软件即服务 [SaaS] 公司确实有 DevOps 团队，可以很快迭代并多次每天在生产环境中部署），但数据始终在变化，这意味着机器学习模型在不断学习和适应——或者不适应，这取决于情况——新的输入。这种环境的复杂性，包括机器学习模型由代码和数据组成的事实，使 MLOps 成为一门新颖和独特的学科。

就像 DevOps 和后来的 DataOps 一样，直到最近，团队们大多数时候可以在没有定义和集中化流程的情况下进行。因为在企业级别，他们没有将机器学习模型部署到足够大规模的生产环境中。现在，情况已经发生了变化，团队们越来越寻求方法来规范多阶段、多学科、多阶段过程，以及具有异构环境和 MLOps 最佳实践框架，这绝非易事。本书的第二部分，“MLOps：如何”，将提供这一指导。

MLOps 以缓解风险

对于任何一个在生产中有模型的团队来说，MLOps 都非常重要，因为根据模型的不同，持续的性能监控和调整至关重要。通过确保安全和可靠的运行，MLOps 是减少使用 ML 模型引发的风险的关键。然而，MLOps 实践确实会有成本，因此应该为每个用例进行适当的成本效益评估。

风险评估

当涉及到机器学习模型时，风险变化很大。例如，对于一个每月仅用于决定向客户发送哪些营销优惠的推荐引擎，风险要低得多，而对于一个旅行网站，其定价和收入依赖于机器学习模型，则风险要高得多。因此，在将 MLOps 视为减少风险的一种方式时，分析应该包括以下内容：

• 模型在某一段时间内不可用的风险

• 模型在给定样本上返回错误预测的风险

• 模型准确性或公平性随时间下降的风险

• 维护模型所需技能（即数据科学人才）流失的风险

针对广泛部署并且在组织外使用的模型，通常风险较大。如图 1-4，风险评估通常基于两个指标：不良事件的概率和影响。缓解措施通常基于两者的组合，即模型的严重性。风险评估应在每个项目开始时进行，并定期重新评估，因为模型可能以未预见的方式使用。

图 1-4. 一张表格，帮助决策者进行定量风险分析

风险缓解

MLOps 在风险缓解方面真正发挥了关键作用，特别是当一个集中化团队（其活动有独特的报告方式，这意味着在任何给定企业中可能存在多个这样的团队）拥有超过少数运行模型时。此时，如果没有标准化，很难全面了解这些模型的状态，而这种标准化可以采取适当的缓解措施来处理每一个模型（参见“匹配治理与风险水平”）。

在没有 MLOps 基础设施的情况下将机器学习模型推入生产环境存在许多风险，首要的原因是因为完全评估机器学习模型的性能通常只能在生产环境中完成。为什么？因为预测模型的表现只能和它们训练所用的数据一样好，这意味着训练数据必须很好地反映在生产环境中遇到的数据。如果生产环境发生变化，那么模型的性能可能会迅速下降（详情请参见第五章）。

另一个主要的风险因素是机器学习模型的性能通常对其运行的生产环境非常敏感，包括正在使用的软件和操作系统的版本。它们不太可能以经典软件意义上的错误为特征，因为大多数不是手工编写的，而是机器生成的。问题在于它们通常是构建在一堆开源软件之上（例如，像 scikit-learn、Python 或 Linux 这样的库），因此在生产环境中使用与验证模型时相匹配的这些软件版本非常重要。

推动模型投入生产并不是机器学习生命周期的最终步骤——远非如此。通常这只是开始监控其性能并确保其按预期行事的开端。随着越来越多的数据科学家开始将更多的机器学习模型推入生产环境，MLOps 在减轻潜在风险方面变得至关重要，如果出现问题，这些风险（取决于模型）可能对业务造成灾难性影响。监控同样至关重要，以便组织准确了解每个模型的广泛使用情况。

负责任的 AI 运营

机器学习的负责任使用（更常被称为负责任 AI）涵盖两个主要方面：

故意性

确保模型设计和行为与其目的一致。这包括确保用于人工智能项目的数据来自符合法规且无偏见的来源，以及在 AI 项目中采用协作方法，确保对潜在模型偏差进行多重检查和平衡。故意性还包括可解释性，即 AI 系统的结果应该可以由人类解释（理想情况下，不仅仅是创建系统的人类）。

责任制

集中控制、管理和审计企业 AI 工作——无阴影 IT！责任制是关于全面了解哪些团队正在使用什么数据、如何使用以及在哪些模型中使用的整体视角。它还包括对数据可靠性的信任以及根据法规收集数据的需要，以及对用于哪些业务流程的模型的集中了解。这与可追溯性密切相关：如果出现问题，很容易找到出问题的管道的位置。

这些原则可能显而易见，但重要的是要考虑到机器学习模型缺乏传统命令式代码的透明度。换句话说，很难理解用于确定预测的特征是什么，这反过来又会使得很难证明模型符合必要的监管或内部治理要求。

实际上，通过引入自动化与机器学习模型相比，将责任的基本重点从层次结构的底部转移到顶部。也就是说，以前由个体贡献者在一定指导原则下（例如，一个给定产品的价格应该是多少，或者是否应该接受一个人的贷款申请）可能做出的决策，现在是由模型做出的。对于该模型的自动化决策负责的人可能是数据团队经理甚至是高管，这更加突显了负责任的 AI 的概念。

鉴于前面讨论的风险以及这些特定的挑战和原则，可以很容易地看出 MLOps 与负责任的 AI 之间的相互作用。团队必须有良好的 MLOps 原则来实践负责任的 AI，而负责任的 AI 则需要 MLOps 策略。考虑到这个话题的重要性，我们将在本书的多个阶段回顾它，探讨如何在 ML 模型的生命周期的每个阶段都要解决这个问题。

MLOps 的规模化

MLOps 之所以重要不仅因为它有助于减少生产中机器学习模型的风险，而且它也是大规模部署机器学习工作的重要组成部分（从而从相应的规模经济中受益）。从生产中的一个或少数几个模型到对业务有积极影响的数十、数百甚至数千个模型的过渡，都需要 MLOps 的纪律。

良好的 MLOps 实践至少会帮助团队：

• 特别是在设计阶段进行实验时，要跟踪版本控制

• 理解重新训练的模型是否优于之前的版本（并推广性能更好的模型到生产环境）

• 确保（在每天、每月等定义的周期内）模型在生产中的性能没有下降

结语

在第三章中将详细讨论关键特性，但这里要指出的是，这些不是可选的实践。它们是不仅有效地在企业级别扩展数据科学和机器学习的基础上，而且以不会给企业带来风险的方式进行的基本任务。试图在没有适当的 MLOps 实践的情况下部署数据科学的团队将面临模型质量和连续性的问题，甚至更糟的是，他们将引入对公司影响不利的真实负面影响的模型（例如，偏见预测）。

MLOps 在更高层次上，也是机器学习透明策略的关键部分。高层管理和 C 级管理人员应该能够像数据科学家一样理解哪些机器学习模型被部署到生产环境中，以及它们对业务的影响。除此之外，他们可能还应该能够深入了解支持这些机器学习模型的整个数据流水线（即从原始数据到最终输出的步骤）。本书描述的 MLOps 能够提供这种透明度和责任感。

第二章：MLOps 的人员

尽管机器学习模型主要由数据科学家构建，但有一种误解认为只有数据科学家才能从强大的 MLOps 过程和系统中受益。事实上，MLOps 是企业 AI 战略的重要组成部分，影响着参与机器学习模型生命周期的所有人或从中受益的人。

本章介绍每个人在机器学习生命周期中扮演的角色，他们在顶级 MLOps 程序下应理想地如何连接并共同工作，以从机器学习工作中获得最佳可能的结果，以及他们可能有的 MLOps 要求。

值得注意的是，这个领域在不断发展，带来了许多新的职称，可能未在此列出，并在 MLOps 职责中带来新的挑战（或重叠）。

在深入讨论详情之前，让我们先看一下以下表格，它提供了一个概述：

角色	机器学习模型生命周期中的角色	MLOps 要求
专业领域专家

• 提供围绕 ML 模型应该构建的业务问题、目标或关键绩效指标。

• 持续评估并确保模型性能与初始需求一致或得到解决。

|

• 以业务术语轻松理解已部署模型的性能。

• 用于标记与业务预期不符的模型结果的机制或反馈循环。

|

数据科学家

• 构建能够解决专业领域专家提出的业务问题或需求的模型。

• 提供可操作化的模型，以便在生产环境中正确使用并处理生产数据。

• 与专业领域专家一起评估模型质量（包括原始模型和测试），确保其能够回答最初的业务问题或需求。

|

• 为快速且安全地将模型打包和部署到生产环境提供自动化的模型交付。

• 能够开发测试来评估部署模型的质量，并进行持续改进。

• 从一个中心位置查看所有已部署模型的性能（包括测试中的并置）。

• 能够调查每个模型的数据流水线，快速评估和调整，无论最初是谁构建了模型。

|

数据工程师

• 优化数据的检索和使用，以支持 ML 模型。

|

• 查看所有部署模型的性能可见性。

• 能够查看单个数据流水线的全部细节，以解决底层数据管道问题。

|

软件工程师

• 将 ML 模型集成到公司的应用程序和系统中。

• 确保 ML 模型与其他非基于机器学习的应用无缝协作。

|

• 版本控制和自动化测试。

• 能够并行在同一应用程序上工作。

|

DevOps

• 构建和管理操作系统及测试安全性、性能和可用性。

• 连续集成/连续交付（CI/CD）管道管理。

|

• 将 MLOps 无缝集成到企业更大的 DevOps 战略中。

• 无缝部署管道。

|

模型风险经理/审计员

• 减少因 ML 模型在生产中带来的公司整体风险。

• 在将 ML 模型推向生产之前确保符合内部和外部要求的合规性。

|

• 强大且可能自动化的报告工具覆盖所有模型（当前或曾经处于生产中），包括数据血统。

|

机器学习架构师

• 确保从设计到开发和监控的 ML 模型管道具备可扩展和灵活的环境。

• 在适当时引入新技术，以提高生产中的 ML 模型性能。

|

• 模型及其消耗资源的高级概述。

• 能够深入数据管道以评估和调整基础设施需求。

|

主题专家

在 MLOps 工作中首先考虑的是主题专家（SMEs），毕竟 ML 模型生命周期的起点和终点都是他们。尽管数据导向的角色（数据科学家、工程师、架构师等）在许多领域都有专业知识，但他们往往缺乏对业务以及使用机器学习解决的问题或问題的深刻理解。

主题专家通常会带着明确定义的目标、业务问题和/或关键绩效指标（KPI），或者至少应该带着这些内容来参与讨论。在某些情况下，这些可能会非常明确（例如，“为了完成本季度的指标，我们需要将客户流失率降低 10%”或“由于未预定的维护，我们每季度损失 N 美元；如何更好地预测停机时间？”）。在其他情况下，目标和问题可能不太明确（例如，“我们的服务人员需要更好地了解客户以便提升销售”或“如何让人们购买更多小部件？”）。

在具备健康流程的组织中，将机器学习模型生命周期的开始与更明确的业务问题联系起来并不总是强制性的，甚至不一定是理想的情况。以较不明确的业务目标开始工作可以为主题专家与数据科学家直接合作提供良好的机会，从而更好地界定问题并在开始任何数据探索或模型实验之前进行可能的解决方案头脑风暴。

如果没有主题专家提供的这一关键起点，其他数据专业人士（特别是数据科学家）在开始机器学习生命周期过程时，可能会试图解决并不符合更大业务需求的问题或提供解决方案。最终，这不仅对需要与数据科学家和其他数据专家合作构建解决方案的主题专家本身不利，也对数据科学家本身不利，他们可能难以提供更大的价值。

当 SME 在 ML 生命周期中不参与时，另一个负面结果是，由于缺乏真实的业务结果，数据团队随后会努力获得推动力和额外的预算或支持来继续推进高级分析倡议。最终，这对数据团队、SME 和整体业务都是不利的。

为了在 SME 参与中增加更多结构，可以应用业务决策建模方法来正式化待解决的业务问题，并框定机器学习在解决方案中的角色。

主题专家不仅在 ML 模型生命周期的开始阶段有作用，而且在生产后也是如此。通常，为了了解 ML 模型是否表现良好或符合预期，数据科学家需要主题专家来关闭反馈循环，因为传统的度量标准（准确率、精确率、召回率等）是不够的。

例如，数据科学家可以构建一个简单的客户流失预测模型，在生产环境中具有非常高的准确性；然而，市场营销未能阻止任何人流失。从业务角度来看，这意味着模型没有起作用，这是需要反馈给建模人员的重要信息，以便他们可以寻找另一个可能的解决方案，例如引入提升建模，帮助市场营销更好地针对可能接受营销消息的潜在流失客户。

考虑到 SME 在 ML 模型生命周期中的角色，建立 MLOps 流程时，重要的是让他们能够以业务术语理解部署模型的性能。也就是说，他们需要理解的不仅仅是模型的准确率、精确率和召回率，还有模型在事先确定的业务流程中的结果或影响。此外，当性能出现意外变化时，主题专家需要通过 MLOps 流程一种可扩展的方式来标记与业务预期不一致的模型结果。

除了这些显式的反馈机制之外，更普遍地说，MLOps 应该以一种增加主题专家透明度的方式构建。也就是说，他们应该能够使用 MLOps 流程作为探索模型背后数据流水线的起点，理解正在使用的数据、它如何被转换和增强，以及正在应用的机器学习技术的种类。

对于同样关注机器学习模型与内部或外部法规合规性的主题专家来说，MLOps 作为一种额外的方式来透明化和理解这些过程。这包括能够深入研究模型作出的每个决策，以理解为何模型做出了这样的决策。这应该是统计和汇总反馈的补充。

最终，MLOps 对于主题专家来说最重要的是作为一个反馈机制和与数据科学家沟通他们正在构建的模型的平台。然而，还有其他 MLOps 需求——特别是与负责任人工智能相关的透明度——这些对主题专家来说同样重要，并使其成为 MLOps 中不可或缺的一部分。

数据科学家们

在制定 MLOps 战略时，考虑数据科学家的需求是最关键的。毫无疑问，他们有很多可以获益的地方；如今，在大多数组织中，数据科学家们通常需要处理隔离的数据、流程和工具，这使得他们难以有效扩展他们的工作。MLOps 有很好的机会改变这一现状。

尽管大多数人认为数据科学家在机器学习模型生命周期中的角色仅限于模型构建部分，实际上——或者至少应该如此——它要广泛得多。从一开始，数据科学家就需要与主题专家一起工作，理解并帮助界定业务问题，以便能够构建可行的机器学习解决方案。

现实情况是，机器学习模型生命周期中的这一第一步往往是最艰难的。对于数据科学家来说，这是一个特别具有挑战性的阶段，因为这并不是他们接受过训练的领域。无论是大学里的正式还是非正式的数据科学课程，都大量强调技术技能，而不一定是与来自业务方面并不熟悉机器学习技术的主题专家有效沟通的技能。再次强调，业务决策建模技术可以在这方面提供帮助。

这也是一个挑战，因为这需要时间。对于那些希望深入了解并亲自动手的数据科学家来说，在开始解决问题之前花费数周来界定和概述问题可能会很痛苦。更糟糕的是，数据科学家们通常与业务核心和主题专家（无论是在物理上、文化上还是两者都有）相隔离，因此他们无法轻松获取有助于各方协作的组织基础设施。强大的 MLOps 系统可以帮助解决其中的一些挑战。

克服了第一个障碍之后，根据组织的不同，项目可能会移交给数据工程师或分析师进行一些初始数据收集、准备和探索工作。在某些情况下，数据科学家们自己管理机器学习模型生命周期的这些部分。但无论如何，当建立、测试、强化和部署模型的时候，数据科学家们会再次介入。

在部署后，数据科学家的角色包括不断评估模型质量，以确保其在生产环境中的运行是否能够回答最初的业务问题或需求。许多组织中的根本问题通常是数据科学家是否仅监控他们参与构建的模型，或者是否有一人负责所有监控。在前一种情况下，当人员变动时会发生什么？在后一种情况下，建立良好的 MLOps 实践至关重要，因为负责监控的人员还需要能够迅速介入并采取行动，以应对模型漂移并开始对业务产生负面影响的情况。如果他们不是模型的构建者，MLOps 如何使这一过程无缝？

前一节中所有问题直接导致这里：数据科学家在涉及 MLOps 时的需求。从流程的末尾开始向后工作，MLOps 必须为数据科学家提供对所有已部署模型以及任何正在进行 A/B 测试的模型的性能可见性。但更进一步，这不仅仅是监控问题，还涉及行动问题。一流的 MLOps 应允许数据科学家灵活选择测试中的优胜模型并轻松部署它们。

透明度是 MLOps 中的一个主题，因此对数据科学家来说，它也是一个关键需求。能够深入数据管道并快速评估和调整（无论最初由谁构建模型）的能力至关重要。自动化模型打包和交付，以便快速且安全地部署到生产环境，是透明度的另一个重要方面，特别是将数据科学家与软件工程师和 DevOps 团队汇聚到一个信任的地方，这是 MLOps 的关键组成部分。

除了透明度，掌握 MLOps 的另一个主题——尤其是在满足数据科学家需求方面——是纯效率。在企业设置中，敏捷性和速度很重要。对于 DevOps 来说是如此，对于 MLOps 的故事也是如此。当然，数据科学家可以以临时方式部署、测试和监控模型。但是他们将花费大量时间重新发明每个单独的 ML 模型的轮子，这永远不会为组织带来可扩展的 ML 流程。

数据工程师

数据管道是机器学习模型生命周期的核心，数据工程师又是数据管道的核心。由于数据管道可以是抽象且复杂的，数据工程师可以从 MLOps 中获得许多效率提升。

在大型组织中，管理数据流动除了应用 ML 模型外，也是一个全职工作。根据企业的技术堆栈和组织结构，数据工程师可能更专注于数据库本身，而不是管道（特别是如果公司正在利用数据科学和 ML 平台，这些平台可以通过其他数据从业者如业务分析师视觉化地构建管道）。

尽管组织对角色的这些轻微变化，数据工程师在生命周期中的角色是优化数据的检索和使用，最终为 ML 模型提供动力。一般来说，这意味着与业务团队密切合作，特别是主题专家，以确定适合当前项目的正确数据，并可能为其做准备。另一方面，他们与数据科学家密切合作，解决可能导致模型在生产中行为不良的任何数据管道问题。

鉴于数据工程师在 ML 模型生命周期中的核心角色，支撑建设和监控部分，MLOps 可以带来显著的效率提升。数据工程师不仅需要了解在生产中部署的所有模型的性能，还需要进一步深入直接研究各个数据管道，以解决任何潜在问题。

理想情况下，为了最大化数据工程师（以及包括数据科学家在内的其他人员）的效率，MLOps 不能仅仅是简单的监控，而是要成为调查和调整 ML 模型底层系统的桥梁。

软件工程师

从更广泛的组织视角来看，容易忽视传统软件工程师在 MLOps 中的考虑，但考虑到他们在构建整合企业范围的机器学习策略中的需求至关重要。

软件工程师通常不构建 ML 模型，但另一方面，大多数组织不仅仅生产 ML 模型，还有传统的软件和应用程序。因此，软件工程师和数据科学家共同努力确保更大系统的功能正常运行非常重要。毕竟，ML 模型不仅仅是独立的实验；机器学习代码、训练、测试和部署必须与其余软件使用的持续集成/持续交付（CI/CD）管道相匹配。

举例来说，考虑一个零售公司，他们为他们的网站建立了基于 ML 的推荐引擎。ML 模型由数据科学家构建，但要将其整合到网站的更大功能中，软件工程师将必须参与其中。同样，软件工程师负责整个网站的维护工作，其中很大一部分包括生产中 ML 模型的功能。

考虑到这种相互作用，软件工程师需要 MLOps 作为企业软件应用性能整体图景的一部分，为他们提供模型性能详细信息。MLOps 是数据科学家和软件工程师沟通的一种方式，使他们在企业的各个孤岛中部署的不同模型如何在生产环境中协同工作具有相同的基础理解。

软件工程师的其他重要特性包括版本控制，以确保他们当前正在处理的内容；自动化测试，以尽可能确保他们当前正在处理的内容正常工作；以及能够在同一个应用程序上并行工作的能力（这要归功于像 Git 这样允许分支和合并的系统）。

DevOps

MLOps 是从 DevOps 原则中诞生的，但这并不意味着它们可以作为完全独立和隔离的系统并行运行。

DevOps 团队在 ML 模型生命周期中有两个主要角色。首先，他们是进行和构建操作系统以及测试的人，以确保 ML 模型的安全性、性能和可用性。其次，他们负责 CI/CD 管道管理。这两种角色都需要与数据科学家、数据工程师和数据架构师紧密合作。紧密合作当然说起来容易做起来难，但这正是 MLOps 可以增加价值的地方。

对于 DevOps 团队来说，MLOps 需要整合到企业更大的 DevOps 策略中，弥合传统的 CI/CD 和现代 ML 之间的差距。这意味着系统在基本上是互补的，并允许 DevOps 团队像为传统软件自动化测试一样为 ML 进行自动化测试。

模型风险管理/审计员

在某些行业（特别是金融服务行业），模型风险管理（MRM）功能对于监管合规至关重要。但不仅高度监管的行业应关注或应该具有类似功能；MRM 可以保护任何行业的公司免受由性能不佳的机器学习模型引入的灾难性损失。此外，审计在许多行业中起着重要作用，并且可能非常耗时，这就是 MLOps 出现的背景。

在 ML 模型生命周期中，模型风险管理者扮演着关键角色，不仅分析模型结果，还分析 ML 模型试图解决的初衷和业务问题，以最小化公司的整体风险。他们应该在生命周期的最初阶段与主题专家一起参与，以确保自动化的基于 ML 的方法本身不会带来风险。

当然，他们在监控中也有一定的角色——在模型生命周期中更传统的位置——以确保模型投入生产后风险得以控制。在构思和监控之间，MRM 还是模型开发后和投产前的一个因素，确保初期遵守内部和外部的要求。

MRM 专业人士和团队在 MLOps 中能够获益良多，因为他们的工作通常是繁琐且需要手工操作。由于 MRM 和相关团队使用的工具经常不同，标准化可以大大提高审计和风险管理的速度。

在具体的 MLOps 需求方面，所有模型的强大报告工具（无论其当前是否处于生产状态或曾经处于生产状态）是主要需求。这些报告不仅应包括性能细节，还应具备查看数据来源的能力。自动报告为 MRM 和审计团队在 MLOps 系统和流程中增加了额外的效率层级。

机器学习架构师

传统的数据架构师负责理解整体企业架构，并确保其满足业务各方的数据需求。通常，他们在定义数据的存储和消费方式方面发挥作用。

如今，对架构师的要求更高，他们不仅需要精通数据存储和消费的方方面面，还需了解机器学习模型如何协同工作。这使得他们的角色更加复杂，并增加了他们在 MLOps 生命周期中的责任。因此，在本节中，我们将其称为机器学习架构师，而不是传统的“数据架构师”称号。

机器学习架构师在机器学习模型生命周期中扮演着至关重要的角色，确保模型管道的可伸缩性和灵活性环境。此外，数据团队需要他们的专业知识，以在生产环境中引入新技术（在适当时）。正因如此，单凭数据架构师的头衔是不够的；他们需要对机器学习有深入的理解，而不仅仅是企业架构，才能在机器学习模型生命周期中发挥关键作用。

该角色需要在企业内部各方面（从数据科学家和工程师到 DevOps 和软件工程师）进行协作。若无法完全理解每个人和团队的需求，机器学习架构师将无法适当地分配资源，以确保 ML 模型在生产中的最佳性能。

在 MLOps 领域，机器学习架构师的角色在于拥有资源分配的集中视图。由于他们具有战略和战术角色，他们需要全面了解当前情况，以识别瓶颈并利用这些信息找到长期改进的方法。他们的角色是确定可能的新技术或基础设施投资，而不是仅仅进行不解决系统可扩展性核心问题的操作性快速修复。

总结思路

MLOps 不仅适用于数据科学家；组织中各种专家团队在 ML 模型生命周期以及 MLOps 战略中都发挥了作用。事实上，每个人——从业务方面的主题专家到技术最精通的机器学习架构师——在 ML 模型生产维护中都起着至关重要的作用。这对于确保从 ML 模型中获得尽可能好的结果（良好的结果通常会增加对基于 ML 系统的信任，同时增加用于构建更多的预算），以及更加直接地保护企业免受第一章中概述的风险至关重要。

¹ 决策需求模型基于决策模型与符号化，这是一个改善流程、有效管理业务规则项目、构建预测分析工作、确保决策支持系统和仪表板以行动为导向的框架。

第三章：MLOps 的关键特性

Mark Treveil

MLOps 影响组织中许多不同的角色，反过来又影响机器学习生命周期的许多部分。本章以高层次介绍 MLOps 的五个关键组成部分（开发、部署、监控、迭代和治理），作为第四章至第八章的基础，这些章节深入探讨了这些组成部分的技术细节和要求。

机器学习入门

要理解 MLOps 的关键特性，首先必须了解机器学习的工作原理，并熟悉其特定性。尽管作为 MLOps 的一部分经常被忽视，但算法选择（或者说机器学习模型的构建方式）最终可以直接影响 MLOps 的流程。

机器学习的核心是计算机算法的科学，这些算法能够从经验中自动学习和改进，而不是被明确地程序化。这些算法分析样本数据（称为训练数据），构建能够进行预测的软件模型。

例如，图像识别模型可以通过搜索图像中区分每种电表的关键模式来识别电表类型。另一个例子是保险推荐模型，它可能根据类似客户的先前行为，建议现有特定客户最有可能购买的附加保险产品。

面对未见数据，无论是照片还是客户，ML 模型利用其从先前数据学到的知识进行预测，假设未见数据与先前数据有某种关联，以此做出最佳预测。

ML 算法使用各种数学技术，模型可以采用多种不同的形式，从简单的决策树到逻辑回归算法，再到更复杂的深度学习模型（详情见“什么是机器学习模型？”）。

模型开发

让我们更深入地了解整个 ML 模型开发过程，以便更全面地理解其各个组成部分，所有这些部分在部署后都可能对 MLOps 产生影响。

建立业务目标

开发机器学习模型的过程通常从业务目标开始，可以简单到将欺诈交易降低到小于 0.1%，或者具备识别社交媒体照片上人物面部的能力。业务目标自然伴随着性能目标、技术基础设施要求和成本约束；所有这些因素都可以作为关键绩效指标（KPI），最终能够监控在生产中模型的业务表现。

重要的是要认识到，机器学习项目不是孤立进行的。它们通常是更大项目的一部分，反过来又影响技术、流程和人员。这意味着建立目标的一部分还包括变更管理，这甚至可能为如何构建机器学习模型提供一些指导。例如，所需的透明度程度将强烈影响算法选择，并可能推动提供预测及解释的需要，以便将预测转化为业务层面的有价值决策。

数据来源与探索性数据分析

在明确业务目标的情况下，是时候邀请领域专家和数据科学家一起开始开发机器学习模型的旅程了。这从寻找合适的输入数据开始。寻找数据听起来简单，但在实践中，这可能是旅程中最艰难的部分。

寻找构建机器学习模型所需数据的关键问题包括：

• 有哪些相关数据集可用？

• 这些数据是否足够准确可靠？

• 利益相关者如何获取这些数据？

• 通过结合多个数据源，可以获取哪些数据属性（称为特征）？

• 这些数据是否可以实时获取？

• 是否需要使用“地面真实性”标记一些数据，或者无监督学习是否合理？如果是，这将在时间和资源方面造成多大成本？

• 应该使用什么平台？

• 模型部署后数据如何更新？

• 模型本身的使用是否会降低数据的代表性？

• 与业务目标一起建立的关键绩效指标（KPI），如何进行度量？

数据治理的限制带来了更多问题，包括：

• 选定的数据集能否用于此目的？

• 使用条款是什么？

• 是否有必要对必须被删除或匿名化的个人身份信息（PII）进行处理？

• 是否有法律上不能在此业务背景下使用的特征，比如性别？

• 少数族群的代表性是否足够，使模型在每个群体上表现等效？

由于数据是驱动机器学习算法的基本成分，因此在尝试训练模型之前，建立对数据模式的理解总是有帮助的。探索性数据分析（EDA）技术可以帮助建立关于数据的假设，识别数据清理需求，并指导选择可能重要的特征的过程。EDA 可以通过可视化进行直观洞察，如果需要更严谨，则可以进行统计分析。

特征工程与选择

EDA 自然地引导到特征工程和特征选择。特征工程是将来自选定数据集的原始数据转化为更好地代表待解决问题的“特征”的过程。“特征”是固定大小的数字数组，因为这是 ML 算法唯一理解的对象。特征工程包括数据清洗，这可能是 ML 项目中时间消耗最大的部分。详情请参阅“特征工程与选择”。

训练与评估

在通过特征工程和选择准备数据之后，下一步是训练。训练和优化新的 ML 模型的过程是迭代的；可以测试多种算法，可以自动生成特征，可以调整特征选择，可以调整算法超参数。除了或者说正是因为其迭代的性质，训练也是 ML 模型生命周期中在计算能力方面最为密集的步骤。

在迭代过程中跟踪每个实验的结果变得非常复杂。对数据科学家来说，没有能力重新创建最佳结果是非常令人沮丧的，因为他们无法记住精确的配置。实验跟踪工具可以极大简化记忆数据、特征选择和模型参数以及性能指标的过程。这些使得可以并列比较实验，突显性能上的差异。

决定最佳解决方案需要定量标准（如准确率或平均误差）和关于算法可解释性或部署易用性的定性标准。

可重复性

虽然许多实验可能是短暂的，但模型的重要版本需要保存以备可能的后续使用。这里的挑战是可重复性，这是实验科学中一个重要的概念。在机器学习中，目标是保存关于模型开发环境的足够信息，以便可以从头开始复制模型并得到相同的结果。

没有可重复性，数据科学家很难自信地迭代模型，更糟糕的是，他们不太可能将模型交给 DevOps，看看实验室中创建的内容是否能够在生产中忠实地复制。真正的可重复性需要对所有涉及的资产和参数进行版本控制，包括用于训练和评估模型的数据，以及软件环境的记录（详见“版本管理与可重复性”）。

负责任的 AI

能够复现模型只是操作化挑战的一部分；DevOps 团队还需要理解如何验证模型（即模型的作用是什么，如何进行测试，预期结果是什么？）。那些处于高度监管行业的人可能需要记录更多的细节，包括模型的构建过程和调优过程。在关键情况下，模型可能会被独立重新编码和重建。

文档仍然是解决这种沟通挑战的标准方案。自动化模型文档生成，即工具自动创建与任何训练模型相关的文档，可以减少工作负担。但在几乎所有情况下，仍需手工编写一些文档来解释所做的选择。

ML 模型由于其统计性质的基本特性，难以理解是其一个基本结果。虽然模型算法配备了标准性能指标来评估其效果，但这些指标并不能解释预测是如何做出的。理解“如何”对于检查模型或帮助更好地设计特征非常重要，并且可能需要确保已满足公平性要求（例如性别、年龄或种族等特征）。这是解释性的领域，与负责任的人工智能（如第一章所讨论的那样），并将在第四章中进一步详细讨论。

随着全球对无限制 AI 影响的关注增加，解释性技术变得越来越重要。它们提供了减少不确定性和帮助预防意外后果的方法。目前最常用的技术包括：

• 部分依赖图，研究特征对预测结果的边际影响。

• 子群体分析，即分析模型如何处理特定子群体的分析，这是许多公平性分析的基础。

• 个体模型预测，例如Shapley 值，解释每个特征值如何影响特定预测。

• 假设分析，帮助 ML 模型用户理解预测对其输入的敏感性。

正如我们在本节中所见，即使模型开发非常早期，仍然是一个重要的地方来融合 MLOps 实践。在模型开发阶段进行的任何 MLOps 工作将使模型在后续更易管理（特别是推向生产时）。

生产化和部署

将模型推向生产并部署是 MLOps 的关键组成部分，它面临与开发模型完全不同的一组技术挑战。这是软件工程师和 DevOps 团队的领域，管理数据科学家与这些团队之间信息交流的组织挑战不容小觑。正如在第一章中提到的，如果团队之间缺乏有效的协作，推迟或部署失败是不可避免的。

模型部署类型和内容

要了解这些阶段中发生了什么，有助于退后一步并问一问：究竟要投入生产的是什么，模型由什么组成？通常有两种类型的模型部署：

模型即服务，或实时评分模型

通常模型会部署到一个简单的框架中，以提供 REST API 端点（API 访问资源所需执行任务的方式），实时响应请求。

嵌入式模型

在这里，模型被打包成一个应用程序，然后发布。一个常见的例子是提供批处理请求的应用程序。

被部署的模型包含的内容取决于所选择的技术，但通常包括一组代码（通常是 Python、R 或 Java）和数据工件。其中任何一个都可能对运行时和软件包有版本依赖性，需要与生产环境中匹配，因为使用不同版本可能会导致模型预测不同。

降低对生产环境依赖的一种方法是将模型导出为便携格式，如 PMML、PFA、ONNX 或 POJO。这些旨在提高系统间模型的可移植性并简化部署。然而，它们也带来了一些成本：每种格式只支持有限的算法范围，有时便携模型的行为与原始模型略有不同。是否使用便携格式应基于对技术和业务背景的深入理解做出选择。

模型部署要求

那么在完成模型开发和物理部署之间的生产过程中，需要解决哪些问题呢？有一件事是确定的：快速、自动化的部署始终优于繁重的过程。

对于短寿命周期、自助式应用，通常不需要太担心测试和验证。如果可以通过诸如 Linux cgroups 之类的技术安全地限制模型的最大资源需求，那么完全自动化的单步推送至生产环境可能完全足够。在使用这种轻量级部署模式时，甚至可以通过像 Flask 这样的框架处理简单的用户界面。除了集成数据科学和机器学习平台外，一些业务规则管理系统也可能允许基本 ML 模型的某种自主部署。

在面向客户、任务关键的使用案例中，需要一个更强大的 CI/CD 流水线。这通常包括：

1. 确保所有编码、文档和签署标准都得到满足

2. 在接近生产环境中重新创建模型

3. 重新验证模型的准确性

4. 执行可解释性检查

5. 确保满足所有治理要求

6. 检查任何数据工件的质量

7. 在负载下测试资源使用情况

8. 嵌入到更复杂的应用程序中，包括集成测试

在严格管制的行业（例如金融和制药业），治理和监管检查将会非常严格，并且可能需要手动干预。MLOps 的愿望与 DevOps 一样，就是尽可能地自动化 CI/CD 流水线。这不仅加快了部署过程，还能进行更广泛的回归测试，并减少部署中出错的可能性。

监控

一旦模型部署到生产环境中，它能够持续良好地运行至关重要。但良好的性能对不同的人意味着不同的事情，特别是对 DevOps 团队、数据科学家和业务而言。

DevOps 的关注点

DevOps 团队的关注点非常熟悉，包括诸如：

• 模型是否能够快速完成工作？

• 它是否在合理的内存和处理时间范围内运行？

这是传统的 IT 性能监控，而 DevOps 团队已经知道如何做得很好了。在这方面，ML 模型的资源需求与传统软件并没有太大的不同。

计算资源的可扩展性可能是一个重要考虑因素，例如，如果你正在生产环境中重新训练模型。深度学习模型比简单的决策树具有更高的资源需求。但总体而言，DevOps 团队在监控和管理资源方面的现有专业知识可以轻松应用于 ML 模型。

数据科学家的关注点

数据科学家对监控 ML 模型感兴趣是出于一个更具挑战性的原因：它们可能会随时间而退化，因为 ML 模型实际上是对它们训练数据的模型。这不是传统软件面临的问题，但它是机器学习固有的。ML 数学建立了对训练数据中重要模式的简明表达，希望这能很好地反映现实世界。如果训练数据很好地反映了现实世界，那么模型应该是准确的，因此是有用的。

但现实世界并不停留。六个月前用于构建欺诈检测模型的训练数据不会反映出最近三个月开始出现的新类型欺诈行为。如果某个网站开始吸引越来越年轻的用户群体，那么生成广告的模型可能会生成越来越不相关的广告。在某一点上，性能将变得不可接受，需要重新训练模型。模型需要多快重新训练取决于现实世界的变化速度以及模型需要多准确，但同样重要的是，取决于构建和部署更好模型的难易程度。

但首先，数据科学家如何判断模型的性能正在恶化呢？这并不总是容易。有两种常见方法，一种基于真相，另一种基于输入漂移。

真相

真相（ground truth），简而言之，是模型被要求解决的问题的正确答案，例如，“这笔信用卡交易实际上是欺诈的吗？” 通过了解模型所做预测的所有真相，可以评估该模型的表现如何。

有时候，在预测之后可以迅速获取真相，例如，在决定向用户展示哪些广告的模型中。用户可能在几秒钟内点击广告，或者根本不点击。然而，在许多用例中，获取真相要慢得多。如果一个模型预测某笔交易是欺诈的，如何确认这一点？在某些情况下，确认可能只需要几分钟，例如给持卡人打电话。但是，如果模型认为交易正常，实际上并非如此怎么办？最好的希望是当持卡人查看他们的月度交易记录时，他们会报告这些问题，但这可能会延迟一个月或完全不发生。

在欺诈的例子中，真相不能让数据科学团队每天准确监测性能。如果情况需要快速反馈，那么输入漂移可能是一个更好的方法。

输入漂移

输入漂移基于一个原则，即如果模型训练的数据准确反映了现实世界，模型才能准确预测。因此，如果最近请求与部署模型的训练数据之间的比较显示出明显差异，那么模型的性能可能会受到损害。这就是输入漂移监测的基础。这种方法的美妙之处在于，用于此测试的所有数据已经存在，因此无需等待真相或任何其他信息。

识别漂移是可适应的 MLOps 策略中最重要的组成部分之一，也是能够为组织的企业 AI 努力带来敏捷性的组成部分。第七章 将更深入地探讨数据科学家在模型监控方面的关注点。

业务关注点

业务对监控有全面的观点，其中一些关注点可能包括以下问题：

• 模型为企业带来了价值吗？

• 模型的益处是否超过开发和部署它的成本？（如何衡量这一点？）

原始业务目标确定的关键绩效指标是这一过程的一部分。在可能的情况下，这些应该自动监控，但这很少是微不足道的。在我们之前的示例中，将欺诈率降低到交易的 0.1%以下的目标取决于建立基础事实。但即使是这样监控，也无法回答一个问题：业务的净收益是多少美元？

这是软件的古老挑战，随着对机器学习支出的不断增加，数据科学家展示价值的压力只会增加。在缺乏“美元计量器”的情况下，有效监控业务关键绩效指标是最佳选择（参见“设计和管理实验”）。在这里选择基线很重要，理想情况下应允许区分 ML 子项目的价值，而不是全局项目的价值。例如，可以通过基于主题专业知识的基于规则的决策模型评估 ML 性能，以区分决策自动化和 ML 本身的贡献。

迭代与生命周期

开发和部署改进版本的模型是 MLOps 生命周期中必不可少的部分，也是更具挑战性的部分之一。有各种原因可以开发新的模型版本，其中之一是由于模型漂移导致模型性能下降，正如前一节所讨论的。有时需要反映精炼的业务目标和关键绩效指标，而其他时候，只是数据科学家提出了更好的设计模型的方法。

迭代

在某些快速变化的业务环境中，每天都会有新的训练数据可用。通常会自动化每日重新训练和重新部署模型，以确保模型尽可能准确地反映最近的经验。

重新使用最新训练数据重新训练现有模型是迭代新模型版本的最简单情况。但即使没有特征选择或算法变化，仍然存在许多陷阱。特别是：

• 新的训练数据看起来如预期吗？通过预定义的指标和检查自动验证新数据至关重要。

• 数据完整且一致吗？

• 特征的分布是否与先前训练集中的分布大致相似？请记住，目标是优化模型，而不是根本性地改变它。

构建新模型版本后的下一步是将指标与当前的实时模型版本进行比较。为此，需要在相同的开发数据集上评估两个模型，无论是先前版本还是最新版本。如果指标和检查表明两个模型之间存在较大差异，则不应重新部署自动化脚本，并应寻求手动干预。

即使在“简单”的自动化重新训练场景中使用新的训练数据，也需要基于评分数据协调（在可用时与真实情况一致）、数据清理和验证、先前的模型版本以及一系列经过深思熟虑的检查来创建多个开发数据集。在其他情景下重新训练可能会更加复杂，从而使自动化部署变得不太可能。

举例来说，考虑到由于重要的输入漂移而进行的重新训练。如何改进模型？如果有新的训练数据可用，那么使用这些数据进行重新训练是具有最高成本效益比的行动，而且可能足够了。然而，在获取真实情况速度较慢的环境中，可能没有太多新的标记数据。

本案例需要数据科学家的直接干预，他们需要理解漂移的原因，并找出如何调整现有的训练数据以更准确地反映最新的输入数据。评估通过这些更改生成的模型是困难的。数据科学家必须花时间评估情况——这段时间随着建模债务的增加而增加——并估计对性能的潜在影响，并设计定制的缓解措施。例如，去除特定特征或对现有的训练数据行进行抽样可能会导致调整更好的模型。

反馈循环

在大型企业中，DevOps 最佳实践通常规定，实时模型评分环境和模型重新训练环境是分开的。因此，在重新训练环境中评估新模型版本可能会受到影响。

缓解这种不确定性的一种方法是影子测试，其中新模型版本与现有模型一起部署到实时环境中。所有实时评分由现任模型版本处理，但每个新请求将由新模型版本再次评分并记录结果，但不返回给请求者。一旦足够的请求由两个版本评分，结果就可以进行统计比较。影子评分还为 SME（专家小组成员）提供了更多关于模型未来版本的可见性，因此可能允许更平稳的过渡。

在先前讨论的广告生成模型中，无法确定模型选择的广告是好是坏，除非允许最终用户点击它们。在这种情况下，影子测试的好处有限，而 A/B 测试更为常见。

在 A/B 测试中，两个模型都部署到实时环境中，但输入请求被分配到两个模型之间。每个请求只由其中一个模型处理，而不是两个都处理。两个模型的结果被记录以供分析（但不是针对同一请求）。从 A/B 测试中得出统计上显著的结论需要仔细规划测试过程。

第七章将更详细地介绍 A/B 测试的操作方法，但预览时，最简单形式的 A/B 测试通常被称为固定时间段测试。这是因为在寻找统计上显著的结论时，必须等到测试了事先精心确定的样本数量。在测试完成之前窥视结果是不可靠的。然而，如果测试在商业环境中实时运行，每一个糟糕的预测都可能花费金钱，因此不能早期停止测试可能会很昂贵。

贝叶斯，特别是多臂老丨虎丨机测试，越来越受欢迎，作为“频率主义者”固定时间段测试的替代方案，旨在更快地得出结论。多臂老丨虎丨机测试是自适应的：决定模型之间分配的算法根据实时结果进行调整，并减少表现不佳模型的工作负载。虽然多臂老丨虎丨机测试更复杂，但可以降低将流量发送到表现不佳模型的业务成本。

治理

治理是对企业施加的一系列控制措施，以确保其履行对所有利益相关者的责任，从股东和员工到公众和国家政府。这些责任包括财务、法律和道德义务。这三者的基础是公平原则。

法律义务是最容易理解的。在机器学习出现之前，企业就受到法规的约束。许多法规针对特定行业；例如，金融法规旨在保护公众和更广泛的经济免受金融管理和欺诈的危害，而制药行业必须遵守规则以保障公众健康。商业实践受到更广泛的立法影响，以保护社会中的弱势群体，并确保在性别、种族、年龄或宗教等标准上的公平竞争。

最近，全球各国政府已经实施了保护公众免受企业使用个人数据影响的法规。2016 年的欧盟通用数据保护条例（GDPR）和 2018 年的加州消费者隐私法案（CCPA）代表了这一趋势，它们对完全依赖数据的机器学习的影响巨大。例如，GDPR 试图保护个人数据免受工业滥用，并旨在限制可能对个人造成的歧视。

现在，各国政府开始特别关注机器学习，希望减少其使用可能带来的负面影响。欧盟正在领先，计划制定法律来定义各种形式人工智能的可接受使用方式。这并不一定意味着减少使用；例如，可能会推动面部识别技术的有益应用，目前受数据隐私法规限制。但显然的是，企业在应用机器学习时将不得不注意更多的监管。

企业是否关心超越法定法规的对社会的道德责任？答案越来越是肯定的，如当前环境、社会和治理（ESG）绩效指标的发展所示。信任对消费者至关重要，缺乏信任对业务不利。随着公众在这一议题上的活跃参与增加，企业正在探讨负责任人工智能的理念，即道德、透明和可问责的人工智能技术应用。股东也重视信任，机器学习风险的全面披露正在逐步实现。

将良好的治理应用于 MLOps 是具有挑战性的。这些过程复杂，技术不透明，对数据的依赖性是基础性的。MLOps 中的治理倡议大体上可以分为两类：

数据治理

确保适当使用和管理数据的框架

过程治理

使用明确定义的流程确保在模型生命周期的正确阶段处理所有治理考虑，并且保持完整和准确的记录

数据治理

数据治理关注正在使用的数据，特别是模型训练的数据，并且可以解决如下问题：

• 数据的来源是什么？

• 原始数据是如何收集的，使用条款是什么？

• 数据是否准确且更新？

• 是否存在个人身份信息（PII）或其他敏感数据不应使用？

机器学习项目通常涉及大量的流水线，包括数据清洗、组合和转换步骤。理解数据衍生线在特征级别尤为复杂，但对于遵守类似 GDPR 的法规却是必不可少的。团队——乃至更广泛的组织，因为这对其顶层也很重要——如何确保没有使用个人身份信息来训练给定模型？对数据进行匿名化或伪匿名化并非总是管理个人信息的充分解决方案。如果这些过程执行不正确，仍然可能单独识别出个人及其数据，与 GDPR 的要求相违背。³

尽管数据科学家的初衷最好，模型中可能会意外地产生不恰当的偏见。一个机器学习招聘模型曾因识别某些全女子学校在公司高层管理中代表性不足而著名，这反映了该组织历史上男性的主导地位。⁴ 关键在于基于经验进行预测是一种强大的技术，但有时其后果不仅是适得其反，还可能违法。

目前能够解决这些问题的数据治理工具还处于初期阶段。大多数工具集中在回答数据衍生线的两个问题上：

• 这个数据集的信息来源是什么，以及这告诉我如何使用它？

• 这个数据集如何使用，如果我对其进行某些更改，对下游有何影响？

在真实世界的数据准备流水线中，两个问题都不容易全面准确地回答。例如，如果数据科学家编写了一个 Python 函数来处理多个输入数据集并输出一个单一数据集，那么如何确保新数据集中每个单元格的信息来源？

流程治理

流程治理专注于规范 MLOps 流程中的步骤，并与之相关联的行动。通常这些行动包括审查、签字以及文档等支持材料的获取。其目的有两个：

• 确保每个与治理相关的考虑在正确的时间做出并得到正确执行。例如，模型在所有验证检查都通过之前不应部署到生产环境。

• 以便从严格的 MLOps 流程之外进行监督。审计员、风险管理人员、合规官员以及整个业务都有兴趣能够在后期跟踪进展和审查决策。

流程治理的有效实施是困难的：

• 机器学习生命周期的正式流程很少能准确定义。对整个过程的理解通常分散在参与其中的多个团队之间，往往没有一个人能全面理解整体。

• 要成功应用这一流程，每个团队都必须全力采纳。

• 如果某些用例中的流程过于繁重，团队们肯定会绕过它，很多好处也将会丧失。

如今，流程治理在传统上具有繁重的监管和合规负担的组织中最为普遍，如金融领域。在这些领域之外，这种情况则比较罕见。随着机器学习渗透到商业活动的各个领域，并且对负责任的 AI 日益关注，我们将需要针对所有企业可行的新的和创新的解决方案来解决这个问题。

总结思考

通过对 MLOps 所需功能和受影响流程的概述，显然这不是数据团队——甚至整个数据驱动组织可以忽视的事情。这也不是一个勾掉清单上项目的事项（“是的，我们在做 MLOps！”），而是技术、流程和人员之间复杂的相互作用，需要纪律和时间才能正确执行。

后续章节将深入探讨 MLOps 中每个 ML 模型生命周期组件的作用，展示每个组件如何实现以更接近理想的 MLOps 实施。

¹ 描述蓝绿部署技术需要比我们这里提供的空间更多。更多信息请参阅Martin Fowler 的博客。

² 深入了解GDPR 和 CCPA 之间的区别。

³ 关于匿名化、伪匿名化以及它们为何不能解决所有数据隐私问题的更多信息，请参阅数据隐私合规数据项目实施指南 by Dataiku。

⁴ 2018 年，亚马逊因其针对女性的偏见而声名狼藉地废除了一款 AI 招聘工具。

第二部分： MLOps：如何

第四章：模型开发

阿德里安·拉瓦约特

任何希望认真对待 MLOps 的人都需要对模型开发过程有至少粗略的了解，这在图 4-1 中作为更大的 ML 项目生命周期的一个元素呈现。根据情况，模型开发过程可以从非常简单到极其复杂不等，并且它决定了后续使用、监控和维护模型的约束条件。

图 4-1. 模型开发在 ML 项目生命周期的更大背景中突出显示

数据收集过程对模型余生的影响非常直接，人们很容易看到模型如何变得陈旧。对于模型的其他部分，影响可能不那么明显。

例如，考虑特征创建，向模型提供日期与指示该日期是否为公共假日的标志可能会在性能上产生很大差异，但在更新模型时也伴随着显著不同的约束条件。或者考虑评估和比较模型所使用的指标如何在需要时实现自动切换到最佳版本。

因此，本章重点介绍了模型开发的基础知识，特别是在 MLOps 的背景下，即如何以使 MLOps 考虑更容易实施的方式构建和开发模型。

什么是机器学习模型？

机器学习模型在学术界和实际世界（即商业环境）中都得到了利用，因此区分它们在理论上代表什么与在实践中如何实现是非常重要的。让我们深入探讨这两者，基于我们在第三章中已经看到的内容。

在理论上

机器学习模型是现实的投射；也就是说，它是某个真实事物或过程的部分和近似表示。所表示的方面通常取决于可用和有用的内容。一旦训练完成，机器学习模型将简化为一个数学公式，在输入某些数据时产生结果——例如，某事件发生的概率估计或原始数字的估计值。

机器学习模型基于统计理论，机器学习算法是从训练数据中构建模型的工具。它们的目标是找到数据的综合表示，而这些数据代表了收集时的世界。因此，当未来看起来像过去时，机器学习模型可以用于进行预测，因为它们的综合表示仍然有效。

机器学习模型如何预测和泛化的一个常用例子是房屋价格。当然，房屋的销售价格取决于太多因素，这些因素过于复杂，无法精确建模，但足够接近以便有用并非难事。该模型的输入数据可能是房屋固有的事物，如房屋面积、卧室和浴室数量、建造年份、地理位置等，还可能包括其他更具上下文信息的内容，例如销售时的住房市场状况、卖方是否急于出售等。有了足够完整的历史数据，并且市场条件没有发生太大变化的情况下，算法可以计算出一个能够提供合理估计的公式。

另一个常见的例子是健康诊断或预测某人在特定时间内将会发展某种疾病。这种分类模型通常会输出某些事件发生的概率，有时还会附带置信区间。

在实践中

一个模型是重建和应用公式所需的参数集。它通常是无状态和确定性的（即，相同的输入始终产生相同的输出，但也有一些例外情况；参见“在线学习”）。

这包括最终公式本身的参数，但也包括从输入数据到将要产生值的最终公式的所有转换，以及可能的派生数据（例如分类或决策）。在实际操作中，给定这种描述，模型是否基于机器学习通常并不重要：它只是应用于输入数据的可计算数学函数，一次处理一行。

例如，在房价案例中，可能无法实际收集到足够的定价数据以获得在所有目标位置上足够准确的模型。因此，也许会用某些被认为对价格影响最大的派生输入替换邮政编码——比如平均收入、人口密度或接近某些便利设施的情况。但由于最终用户将继续输入邮政编码而不是这些派生输入，出于所有目的而言，所有这些转换也是定价模型的一部分。

输出也可以比一个单一数字更丰富。例如，一个检测欺诈的系统通常会提供某种概率（有时还可能是置信区间），而不是一个二元答案。根据欺诈的可接受程度以及后续验证或交易拒绝的成本，系统可能会设置为仅对概率达到一定精细调节阈值的欺诈实例进行分类。有些模型甚至包括建议或决策，例如为了最大化支出而向访客展示哪种产品，或者哪种治疗方法提供最可能的康复。

所有这些转换和相关数据在某种程度上都是模型的一部分；然而，这并不意味着它们总是捆绑在一个单一的、编译在一起的整体包中。这可能很快变得难以管理，此外，这些信息的某些部分还带有各种约束条件（不同的刷新率、外部来源等）。

所需的组件

构建机器学习模型需要许多组件，如表 4-1 中所述。

表 4-1. 机器学习模型的必要组件

机器学习组件	描述
训练数据	训练数据通常是标记为预测案例的，例如所建模的例子（监督学习）。这听起来很明显，但重要的是要有良好的训练数据。一个说明性的例子是二战期间受损飞机的数据，这些数据受到幸存者偏见的影响，因此不适合作为训练数据。 (链接)
性能指标	性能指标是正在开发的模型寻求优化的内容。应谨慎选择，以避免意外后果，如眼镜蛇效应（以一则著名轶事命名，奖励杀死眼镜蛇导致一些人开始饲养它们）。例如，如果数据中有 95% 的数据属于类 A，优化原始准确率可能会导致模型总是预测 A 并且准确率达到 95%。
机器学习算法	有各种工作方式和不同优缺点的模型。需要注意的是，一些算法更适合特定任务，但其选择还取决于需要优先考虑的因素：性能、稳定性、可解释性、计算成本等等。
超参数	超参数是 ML 算法的配置。算法包含基本的公式，它学习的参数是构成该特定预测任务的操作和操作数，而超参数是算法为了找到这些参数可能采取的方式。例如，在决策树中（数据根据在达到此路径的子集中看起来是最佳预测器的内容分割），一个超参数是树的深度（即分割的次数）。
评估数据集	在使用标记数据时，需要一个与训练集不同的评估数据集来评估模型在未见数据上的表现（即它能够进行泛化的程度）。

每个组件的数量和复杂性正是使得优秀的 MLOps 成为一项具有挑战性的任务的一部分。但是复杂性并不止于此，算法选择也是难题的另一部分。

不同的 ML 算法，不同的 MLOps 挑战

机器学习算法的共同特点是它们模拟过去数据中的模式以进行推断，而这种经验的质量和相关性是它们有效性的关键因素。它们的区别在于每种算法风格具有特定特征，并在 MLOps 中提出了不同的挑战（详见表 4-2）。

表 4-2. 算法类型的 MLOps 考虑因素

算法类型	名称	MLOps 考虑因素
线性	线性回归	存在过拟合的倾向。
	逻辑回归	存在过拟合的倾向。
基于树的	决策树	可能不稳定——数据的微小变化可能导致最优决策树结构的大变化。
随机森林	预测结果可能难以理解，这在负责任的人工智能视角下是个挑战。随机森林模型还可能相对缓慢地输出预测结果，这对应用程序构成了挑战。
梯度提升	像随机森林一样，预测结果可能难以理解。此外，特征或训练集的微小变化可能会导致模型发生根本性变化。
深度学习	神经网络	就可解释性而言，深度学习模型几乎是不可能理解的。深度学习算法（包括神经网络）训练速度极慢，需要大量资源（和数据）。资源值得投入吗？还是简单模型同样有效？

某些机器学习算法可以最好地支持特定用例，但治理考虑因素也可能影响算法选择。特别是在高度规管的环境中，必须解释决策的地方（例如金融服务），不能使用像神经网络这样的不透明算法；相反，它们必须偏向于像决策树这样的简单技术。在许多用例中，问题不在于性能的权衡，而在于成本的权衡。简单技术通常需要更昂贵的手工特征工程才能达到与更复杂技术相同的性能水平。

数据探索

当数据科学家或分析师考虑数据源来训练模型时，他们首先需要了解数据的实际情况。即使使用最有效的算法训练的模型，其好坏也取决于训练数据。在这个阶段，许多问题可能会导致数据全部或部分无用，包括不完整性、不准确性、不一致性等。

此类流程的示例包括：

• 记录数据收集方式及已经做出的假设

• 查看数据的总结统计：每列的域是什么？是否有缺失值的行？显而易见的错误？奇怪的异常值？或者根本没有异常值？

• 更详细地查看数据的分布情况

• 数据清洗、填充、重塑、过滤、剪切、采样等

• 检查不同列之间的相关性，对一些子群体进行统计检验，拟合分布曲线。

• 将该数据与文献中的其他数据或模型进行比较：是否存在某些常见信息似乎缺失？这些数据是否分布相当？

当然，在此探索过程中需要领域知识来做出明智的决策。一些异常可能很难在没有特定见解的情况下发现，而且所做的假设可能会对未经训练的人产生不明显的后果。工业传感器数据是一个很好的例子：除非数据科学家也是机械工程师或者设备专家，否则他们可能不知道对于特定机器来说什么是正常的、什么是奇怪的异常值。

特征工程和选择

特征是将数据呈现给模型的方式，帮助模型了解它本身无法推断出的事物。以下表格提供了特征工程的一些示例：

特征工程类别	描述
派生	从现有信息推断新信息，例如，这个日期是星期几？
丰富化	添加新的外部信息，例如，今天是否是公共假日？
编码	以不同方式呈现相同的信息，例如，工作日或周末中的星期几。
组合	将特征链接在一起，例如，积压的大小可能需要根据其中不同项目的复杂性进行加权。

例如，试图估计当前积压下的业务流程潜在持续时间时，如果输入之一是日期，则通常会推导出该日期对应的星期几或者距离下一个公共假日还有多久。如果企业服务的多个位置遵循不同的业务日历，这些信息也可能很重要。

另一个例子是继续上一节中的房屋定价场景，可以使用平均收入和人口密度，这样模型可以更好地泛化和训练更多样化的数据，而不是尝试按地区（即邮政编码）分割。

特征工程技术

有一个整个市场专门提供这种补充数据，远远超出了公共机构和公司分享的开放数据。一些服务提供直接的丰富化，可以节省大量时间和精力。

然而，有许多情况是数据科学家所需的信息并不可得。在这种情况下，有一些技术，比如影响编码，数据科学家通过替换模态值为该模态的目标平均值，使模型能够从类似范围的数据中受益（尽管会有一些信息损失）。

最终，大多数机器学习算法需要以数字表格的形式作为输入，每一行代表一个样本，所有样本来自同一数据集。当输入数据不是表格时，数据科学家可以使用其他技巧来转换它。

最常见的是独热编码。例如，一个可以取三个值的特征（例如，Raspberry、Blueberry 和 Strawberry）被转换为三个只能取两个值的特征—是或否（例如，Raspberry 是/否，Blueberry 是/否，Strawberry 是/否）。

另一方面，文本或图像输入需要更复杂的工程技术。深度学习最近通过提供将图像和文本转换为可供机器学习算法使用的数字表的模型彻底改变了这一领域。这些表被称为嵌入，它们使数据科学家能够进行迁移学习，因为它们可以在未经过培训的领域中使用。

特征选择如何影响 MLOps 策略

在特征的创建和选择方面，经常会出现如何在什么程度上及何时停止的问题。增加更多的特征可能会产生更准确的模型，在将数据分割为更精确组别时实现更多的公平性，或弥补其他有用的缺失信息。然而，这也伴随着一些不利因素，所有这些因素都可能对 MLOps 策略产生重大影响。

• 计算模型可能变得越来越昂贵。

• 更多的特征需要更多的输入和未来的维护。

• 更多的特征意味着某些稳定性的损失。

• 特征数量的增加可能引发隐私问题。

自动化特征选择可以通过使用启发式方法来估计某些特征对模型预测性能的关键性有所帮助。例如，可以查看与目标变量的相关性或快速在数据的代表性子集上训练一个简单模型，然后查看哪些特征是最强的预测因子。

如何选择使用哪些输入，如何对它们进行编码，它们如何相互作用或干扰—这些决策需要对机器学习算法的内部工作有一定的理解。好消息是，其中一些可以部分自动化，例如使用诸如 Auto-sklearn 或 AutoML 应用程序这样的工具，这些工具会将特征与给定目标进行交叉引用，以估计哪些特征、导数或组合可能会产生最佳结果，避免使用那些可能不会产生太大影响的特征。

其他选择仍然需要人工干预，例如决定是否尝试收集可能改进模型的附加信息。花时间构建业务友好的特征通常会提高最终性能，并简化最终用户的采用，因为模型解释可能更简单。这也可以减少建模债务，帮助数据科学家理解主要的预测驱动因素，并确保它们的稳健性。当然，在理解模型所需时间的成本与预期价值之间，以及与模型使用相关的风险之间需要权衡考虑。

底线是，在构建模型时，工程和选择特征的过程，就像许多其他 ML 模型组件一样，是在考虑 MLOps 组件和性能之间的微妙平衡。

实验

实验发生在整个模型开发过程中，通常每个重要决策或假设都至少伴随着一些实验或先前的研究来加以证明。实验可以采用多种形式，从构建成熟的预测 ML 模型到进行统计测试或绘制数据。实验的目标包括：

• 评估在表 4-1 中概述的元素给定的模型有多有用或多好。（下一节将更详细地讨论模型评估和比较。）

• 找到最佳的建模参数（算法、超参数、特征预处理等）。

• 调整偏差/方差权衡以适应给定训练成本的“最佳”定义。

• 找到模型改进和改进的计算成本之间的平衡。（由于总是有改进的空间，那么好有多好？）

在进行实验时，数据科学家需要能够快速迭代地尝试表 4-1 中每个模型构建模块的所有可能性。幸运的是，有工具可以半自动化地完成所有这些，您只需要定义应该测试的内容（可能性的空间），这取决于先前的知识（什么是有意义的）和约束条件（例如计算预算）。

一些工具甚至允许更多自动化，例如通过提供分层模型训练。例如，假设企业希望预测产品的顾客需求以优化库存，但各店的行为差异很大。分层建模包括为每个店铺训练一个模型，可以更好地针对每个店铺进行优化，而不是一个试图在所有店铺中进行预测的模型。

尝试所有可能的超参数组合、特征处理等，很快就变得无法追踪。因此，定义实验的时间和/或计算预算以及模型实用性的可接受阈值（更多关于该概念的内容将在下一节讨论）非常有用。

值得注意的是，这个过程的全部或部分可能需要在任何情况变化时重复（包括数据和/或问题约束发生重大变化时；参见“实践中的漂移检测”）。最终，这意味着所有为数据科学家们在模型到达最终决策时所做的实验以及沿途所有的假设和结论都可能需要重新运行和重新审视。

幸运的是，越来越多的数据科学和机器学习平台不仅允许在第一次运行时自动化这些工作流程，而且还可以保留所有处理操作以便重复使用。有些还允许使用版本控制和实验分支派生来测试理论，然后合并、丢弃或保留它们（参见“版本管理与可重复性”）。

评估和比较模型

二十世纪英国统计学家乔治·E·P·博克斯曾经说过，所有模型都是错误的，但有些是有用的。换句话说，模型不应该追求完美，而是应该达到“足够好以便有用”的标准，同时要注意神秘谷效应——通常是一个看起来做得很好的模型，但在特定情况下（比如，少数群体）却表现糟糕（甚至灾难性）。

因此，重要的是在上下文中评估模型，并具备一定的能力将其与之前的模型或基于规则的过程进行比较，以了解如果当前模型或决策过程被新模型取代，结果将会如何。

一个技术上可以被认为是令人失望的绝对表现的模型，仍然有可能改善现有情况。例如，对某种产品或服务的需求有稍微更精确的预测可能会导致巨大的成本节约。

相反，得分完美的模型是可疑的，因为大多数问题的数据中存在噪声，这些噪声至少在某种程度上很难预测。完美或接近完美的得分可能表明数据中存在泄漏（即被预测的目标也在输入数据中，或者输入特征与目标非常相关，但在实际中只有在目标已知时才可用），或者模型过度拟合训练数据，无法很好地泛化。

选择评估指标

为了评估和比较不同模型的适当指标，针对给定问题选择适当的度量标准可能导致非常不同的模型（可以想象一下表 4-1 中提到的眼镜蛇效应）。一个简单的例子：对于自动分类问题，通常使用准确率，但当类别不平衡时（即一个结果比另一个结果发生的可能性非常小），准确率很少是最佳选择。在一个二元分类问题中，正类（即有趣的预测类，因为其预测会触发某种行动）很少见，例如发生的 5%的情况，一个总是预测负类的模型因此准确率为 95%，但同时也是毫无用处的。

不幸的是，并不存在一种适合所有的指标。你需要选择一个与手头问题匹配的指标，这意味着理解指标的限制和权衡（数学方面）以及它们对模型优化的影响（业务方面）。

为了了解模型的泛化能力如何，该指标应在未用于模型训练的数据部分上进行评估（保留数据集），这种方法称为交叉测试。可能有多个步骤，在这些步骤中，一些数据被保留用于评估，其余数据则用于训练或优化，如度量评估或超参数优化。还有不同的策略，不一定只是简单的分割。例如，在k-折交叉验证中，数据科学家多次轮换保留用于评估和训练的部分。这增加了训练时间，但能够提供指标稳定性的想法。

在简单分割中，保留数据集可以包含最近的记录，而不是随机选择的记录。实际上，由于模型通常用于未来预测，因此评估它们就像在最新数据上进行预测一样，可以得出更真实的估计。此外，这还可以评估数据在训练和保留数据集之间是否发生漂移（有关更多详细信息，请参阅“实际中的漂移检测”）。

例如，图 4-2 展示了一种方案，其中测试数据集是保留的（灰色），以执行评估。其余数据分为三部分，通过在每个蓝色数据集上使用给定组合训练模型三次，并在各自的绿色数据集上验证其性能，来找到最佳超参数组合。灰色数据集仅在最佳超参数组合下使用一次，而其他数据集则与所有组合一起使用。

图 4-2. 模型评估的数据集分割示例

通常，数据科学家希望定期使用相同的算法、超参数、特征等对模型进行重新训练，但使用更新的数据。自然而然地，下一步是比较两个模型，看看新版本的表现如何。但同样重要的是确保所有先前的假设仍然成立：问题没有根本性转变，先前做出的建模选择仍然适合数据等。这更具体地属于性能和漂移监控的一部分（在第七章中可以找到更多详细信息）。

检查模型行为

在评估模型时，除了原始指标外，了解其行为方式至关重要。根据模型预测、决策或分类的影响，可能需要更深入或更浅显的理解。例如，数据科学家应该采取合理步骤（尊重该影响），以确保模型不会造成实质性伤害：例如，预测所有患者都需要由医生检查的模型，在原始预防方面可能得分很高，但在现实资源分配方面则可能不那么理想。

这些合理步骤的示例包括：

• 交叉检查不同的度量（而不仅仅是模型最初优化的那些）

• 检查模型对不同输入的反应方式，例如，绘制某些输入值的平均预测（或分类模型的概率），看看是否存在异常或极端变化情况。

• 分割一个特定维度并检查不同子群体间行为和度量的差异，例如，男性和女性的错误率是否相同？

这些全局分析不应被理解为因果关系，而只是相关性。它们并不一定暗示某些变量与结果之间的特定因果关系；它们仅仅展示了模型如何看待这种关系。换句话说，应谨慎使用模型进行假设分析。如果一个特征值发生了变化，那么如果这个新特征值在训练数据集中从未见过，或者从未与该数据集中其他特征的值组合过，模型的预测可能会是错误的。

当比较模型时，这些不同的方面应该对数据科学家可见，他们需要能够深入了解而不仅仅是单一的度量标准。这意味着完整的环境（交互式工具、数据等）应该对所有模型都可用，理想情况下允许从所有角度和所有组件之间进行比较。例如，对于漂移，比较可能会使用相同的设置但不同的数据，而对于建模性能，则可能使用相同的数据但不同的设置。

负责任的人工智能对建模的影响

根据情况（有时也取决于行业或企业部门），除了对模型行为的一般理解之外，数据科学家还可能需要模型的单独预测是可解释的，包括对推动预测朝某个方向的具体特征有所了解。有时，特定记录的预测可能与平均值非常不同。计算单独预测解释的流行方法包括夏普利值（特征值在所有可能联盟中的平均边际贡献）和个体条件期望（ICE）计算，这些方法显示了目标函数与感兴趣特征之间的依赖关系。

例如，特定激素的测量水平通常会促使模型预测某人存在健康问题，但对于怀孕的女性来说，该水平使模型推断她没有这种风险。某些法律框架要求对模型做出的对人类有后果的决定提供某种程度的可解释性，例如推荐拒绝贷款。“元素 2：偏见”详细讨论了这个主题。

注意，可解释性的概念有几个方面。特别是，深度学习网络有时被称为黑匣子模型，因为它们的复杂性（尽管在阅读模型系数时，一个模型是完全指定的，通常是一个概念上非常简单的公式，但是一个非常庞大的公式，变得不可能直观理解）。相反，全局和局部解释工具——如部分依赖图或沙普利值计算——提供了一些洞见，但可以说并没有使模型变得直观。要真正传达对模型正在做什么的严格而直观的理解，需要限制模型的复杂性。

公平性要求还可能对模型开发产生尺寸约束。考虑这个理论例子以更好地理解偏见问题的重要性：一个总部位于美国的组织定期雇佣从事相同类型工作的人员。数据科学家可以训练一个模型来预测员工的绩效，根据各种特征，然后人们将根据他们成为高绩效员工的概率被聘用。

尽管这个问题看起来很简单，不幸的是，它充满了陷阱。为了使这个问题完全假设化，并将其与现实世界的复杂性和问题分离开来，让我们假设工作人口中的每个人都属于两个群体之一：韦奎人或托格鲁塔人。

对于这个假设性的例子，让我们假设韦奎人中有更大比例的人上大学。从一开始，韦奎人会因此而受到偏见的影响（因为他们通过多年的经验发展了他们的技能）。

结果是，申请者池中不仅会有更多的韦奎人而不是托格鲁塔人，而且韦奎人的申请者往往更有资格。雇主在未来一个月需要招聘 10 人。它应该怎么做？

• 作为一个平等机会的雇主，它应该确保招聘过程的公平性，因为它控制着这一过程。这意味着在数学术语中，对于每个申请者，一切条件相等的情况下，被录用（或不被录用）不应取决于他们所属的群体（在本例中为韦奎人或托格鲁塔人）。然而，这本身会导致偏见，因为韦奎人更有资格。注意，“一切条件相等”可以有多种解释，但通常的解释是，该组织可能不会被认为对其不控制的过程负责。

• 雇主可能还需要避免不平等影响，即就业实践对一个受保护特征群体的不利影响大于对另一个群体的影响。不平等影响是针对亚群体进行评估的，而不是针对个人；实际上，它评估的是公司是否与韦奎人和托格鲁塔族的比例一样多地雇佣了人。再次强调，目标比例可能是申请者的比例或总体人口的比例，尽管前者更有可能，因为组织无法对其控制之外的过程中的偏见负责。

这两个目标是互斥的。在这种情况下，平等机会会导致招聘 60%（或更多）的韦奎人和 40%（或更少）的托格鲁塔族。因此，这个过程对这两个群体产生了不平等影响，因为招聘率不同。

相反，如果过程经过修正，以使得被雇佣的人中有 40%是托格鲁塔族，以避免不平等影响，这意味着一些被拒绝的韦奎人申请者被预测为比一些被接受的托格鲁塔族申请者更合格（这与平等机会的声明相矛盾）。

需要进行权衡——有时法律称之为 80%法则。在这个例子中，这意味着托格鲁塔族的雇佣率应等于或大于韦奎人雇佣率的 80%。在这个例子中，这意味着可以雇佣高达 65%的韦奎人。

这里的重点在于，定义这些目标不能仅由数据科学家决定。但即使一旦定义了这些目标，实施本身也可能存在问题：

• 没有任何迹象的话，数据科学家自然会尝试构建平等机会的模型，因为这些模型符合世界的实际情况。大多数数据科学家使用的工具也试图实现这一目标，因为这是最符合数学原理的选择。然而，有些实现这一目标的方式可能是非法的。例如，数据科学家可以选择实施两个独立的模型：一个用于韦奎人，一个用于托格鲁塔族。这可能是解决由训练数据集中韦奎人过度代表性引起的偏见的一种合理方式，但这会导致对这两个群体的不平等对待，可能被认为是歧视性的。

• 为了让数据科学家按照工具设计的方式使用它们（即模拟实际世界），他们可以决定对预测结果进行后处理，使其符合组织对世界应该是什么样的愿景。最简单的做法是为韦奎人选择一个比托格鲁塔族更高的阈值。它们之间的差距将调整“平等机会”和“平等影响”之间的权衡，但由于不平等对待的原因，这仍可能被认为是歧视性的。

在这个问题上，数据科学家可能无法独自解决问题（请参阅“负责任人工智能的关键要素”以获取更广泛的视角）。这个简单的例子说明了这个主题的复杂性，考虑到可能存在许多受保护的属性，以及偏见既是业务问题也是技术问题。

因此，解决方案在很大程度上取决于上下文。例如，Weequay 和 Togruta 的这个示例代表了使用户获得权限的过程。如果该过程对用户有负面影响（如导致交易被拒绝的欺诈预测）或者是中立的（如疾病预测），情况就不同了。

版本管理和可复现性

讨论模型的评估和比较（如前文所述的公平性，以及许多其他因素）必然会提出版本控制和不同模型版本的可复现性的概念。由于数据科学家正在构建、测试和迭代多个模型版本，他们需要能够清楚地保持所有版本。

版本管理和可复现性解决了两个不同的需求：

• 在实验阶段，数据科学家可能会在不同的决策之间来回摆动，尝试不同的组合，并在产生不理想结果时回退。这意味着能够回到不同的实验“分支”的能力——例如，在实验过程中恢复项目的先前状态，当时的实验过程导致了死胡同。

• 几年后，数据科学家或其他人（审计员、经理等）可能需要重放导致模型部署的计算，这些计算是在首次进行实验几年后进行的。

当一切都基于代码时，版本控制技术已经在某种程度上得到了解决。现代数据处理平台通常为数据转换管道、模型配置等提供类似的能力。当然，合并几个部分没有合并分歧的代码那么简单，但基本需求是能够回到某个特定实验，即使只是为了能够复制其设置以在另一个分支中复制它们。

模型的另一个非常重要的属性是可复现性。经过许多实验和调整后，数据科学家可能会得到一个符合要求的模型。但在此之后，运行模型需要在另一个环境中重现模型，可能还需要从不同的起始点开始。可重复性也使得调试变得更加容易（有时甚至只是可能）。为此，模型的所有方面都需要进行文档化和可重复使用，包括：

假设

当数据科学家在做出关于手头问题、其范围、数据等的决策和假设时，所有这些都应该是明确的并且记录下来，以便随时与任何新信息进行对比。

随机性

许多机器学习算法和过程（例如采样）使用伪随机数。能够精确地重现实验，如用于调试，意味着要控制这种伪随机性，通常是通过控制生成器的“种子”（即使用相同种子初始化的相同生成器将产生相同的伪随机数序列）。

数据

要实现重复性，必须有相同的数据可用。这有时可能会有些棘手，因为版本化数据所需的存储容量可能会因更新速度和数量而受到限制。此外，与代码分支不同，数据分支尚未拥有如此丰富的工具生态系统。

设置

这是一个已知的事实：所有已完成的处理必须在相同的设置下可再现。

结果

开发人员使用合并工具来比较和合并不同的文本文件版本，而数据科学家需要能够比较从混淆矩阵到偏依赖图的深度模型分析，以获得满足要求的模型。

实施

同一模型的微小不同实现实际上可能会产生不同的模型，足以改变某些接近调用的预测。并且模型越复杂，这些差异发生的可能性就越高。另一方面，批量使用模型对数据集进行评分与在 API 中实时评分单个记录具有不同的约束条件，因此有时可能需要为同一模型进行不同的实现。但在调试和比较时，数据科学家需要记住可能的差异。

环境

考虑到本章涵盖的所有步骤，显然一个模型不仅仅是其算法和参数。从数据准备到评分实现，包括特征选择、特征编码、丰富化等，这些步骤运行的环境可能更多或更少地与结果隐含相关。例如，一个在某一步骤中涉及的 Python 包的稍有不同版本可能以难以预测的方式改变结果。最好，数据科学家应确保运行时环境也是可重复的。鉴于机器学习的发展速度，这可能需要冻结计算环境的技术。

幸运的是，与版本和可再现性相关的底层文档任务的一部分可以自动化，并且使用集成平台进行设计和部署可以通过确保结构化信息传输大大降低可再现性成本。

显然，虽然可能不是模型开发中最吸引人的部分，但版本管理和可重现性对于在现实世界的组织环境中构建机器学习工作至关重要，其中包括治理和审计在内。

结语

模型开发是 MLOps 中最关键和最具影响力的步骤之一。在这个阶段必须回答许多技术问题，这些问题对模型的整个生命周期中的所有方面都有重大影响。因此，暴露、透明度和协作对长期成功至关重要。

模型开发阶段也是数据科学家等个人经常实践的阶段，在 MLOps 之前的世界中，这通常代表整个机器学习工作，生成的模型将会按原样使用（带有其所有的后果和局限性）。

¹ CycleGAN 是由 Jun-Yan Zhu、Taesung Park、Phillip Isola 和 Alexei A. Efros 的最新研究实现的。

第五章：准备生产

Joachim Zentici

确认某些东西在实验室中运行良好从来不是它在真实世界中运行良好的确切标志，机器学习模型也不例外。生产环境通常与开发环境大不相同，而与生产中模型相关的商业风险则更大。重要的是要理解和测试生产过渡的复杂性，并充分减轻潜在风险。

本章探讨了为生产做好准备所需的步骤（在整个生命周期的背景下突出显示在图 5-1 中）。目标是通过扩展来说明必须考虑的用于强大 MLOps 系统的元素。

图 5-1。在 ML 项目生命周期的更大背景下突出显示的准备生产

运行时环境

将模型部署到生产环境的第一步是确保技术上可行。正如在第三章中讨论的那样，理想的 MLOps 系统更倾向于快速、自动化的部署，而不是繁琐的流程，运行时环境可能会极大地影响哪种方法更为主流。

生产环境采用多种形式：定制服务、数据科学平台、像 TensorFlow Serving 这样的专用服务、低级基础设施如 Kubernetes 集群、嵌入式系统上的 JVM 等等。更复杂的是，考虑到某些组织中存在多个异构的生产环境并存。

理想情况下，运行在开发环境中的模型可以直接验证并如同原样送到生产环境；这样可以最小化适应工作量，并提高模型在生产中表现与开发中一致的机会。不幸的是，这种理想情况并不总是可能的，有时团队在长期项目完成后却发现无法投入生产。

从开发到生产环境的适应

在适应工作方面，从开发到生产平台的两端可能来自同一供应商或者可互操作，开发模型可以在生产中无需任何修改即可运行。在这种情况下，将模型推送到生产所需的技术步骤被简化为几次点击或命令，所有的努力都可以集中在验证上。

另一方面，有些情况下需要从头开始重新实现模型，可能是由另一个团队完成，可能是用另一种编程语言。考虑到所需的资源和时间，今天有很少的情况适合这种方法。然而，在许多组织中，这仍然是现实，并且往往是由于缺乏合适的工具和流程。事实上，将模型交给另一个团队重新实现并适应生产环境意味着该模型可能需要数月（甚至数年）才能投入生产，如果能投入的话。

在这两种极端情况之间，可以对模型或与其环境的交互执行许多转换。在所有情况下，至关重要的是在尽可能接近生产环境的环境中进行验证，而不是在开发环境中进行验证。

工具考虑

发送到生产环境所需的格式应该早早考虑，因为它可能对模型本身和生产工作的数量产生重大影响。例如，当使用 scikit-learn（Python）开发模型，而生产环境是期望输入 PMML 或 ONNX 的基于 Java 的环境时，显然需要进行转换。

在这种情况下，团队应在开发模型时设置工具链，最好在第一个版本完成甚至开始之前。如果未能提前创建此流程，将会阻塞验证过程（当然，最终验证不应该在 scikit-learn 模型上执行，因为它不是将投入生产的模型）。

性能考虑

另一个常见的转换需求是出于性能考虑。例如，Python 模型通常在对单个记录进行评分时的延迟要高于其转换为 C++ 的等效模型。由此产生的模型可能会快几十倍（尽管显然这取决于许多因素，结果也可能是速度慢几十倍的模型）。

当生产模型必须在低功耗设备上运行时，性能也是一个考虑因素。例如，在深度神经网络的特定情况下，训练模型可能会变得极其庞大，拥有数十亿或数百亿个参数。在小设备上运行它们简直是不可能的，而在标准服务器上运行它们可能会慢且昂贵。

对于这些模型，仅优化运行时是不够的。为了获得更好的性能，必须优化模型定义。一种解决方案是使用压缩技术：

• 通过量化，模型可以使用 32 位浮点数进行训练，并以较低精度进行推断，从而减少模型的内存需求并提高速度，同时基本保持精度。

• 通过修剪，可以简单地从神经网络中移除权重（甚至整个层）。这是一个相当激进的方法，但一些方法可以保持精度。

• 使用蒸馏，可以训练一个更小的“学生”网络来模仿一个更大、更强大的网络。如果操作得当，这可以比直接从数据训练更小的网络得到更好的模型。

如果初始模型在训练时减少信息损失，这些方法就会非常有效，因此这些操作不仅仅是事后将训练好的模型进行转换，而是调整模型训练方式的方向。这些方法虽然很新，也很先进，但在预训练的自然语言处理（NLP）模型中已经广泛应用。

在验证和投入生产之前获取数据访问权限

另一个需要在验证和投入生产之前解决的技术问题是数据访问。例如，评估公寓价格的模型可能会使用邮政编码区域的市场平均价格；然而，请求评分的用户或系统可能不会提供这个平均值，而只会提供邮政编码，这意味着需要查找以获取平均值。

在某些情况下，数据可以被冻结并与模型捆绑。但当这不可能时（例如，数据集太大或丰富数据需要始终保持最新状态），生产环境应该访问数据库，因此必须安装适当的网络连接、库或驱动程序以与数据存储通信，并存储在某种形式的生产配置中的认证凭据。

在实践中管理这种设置和配置可能非常复杂，因为它需要适当的工具和协作（特别是在扩展到超过几十个模型时）。在使用外部数据访问时，在与生产紧密匹配的情况下进行模型验证尤为关键，因为技术连接常常是生产故障的常见源头。

对运行时环境的最终思考

训练模型通常是最耗费计算资源的过程，需要高级软件技术、海量数据和配置强大的 GPU 高端机器。但在模型的整个生命周期中，大部分计算资源很可能都会在推理时消耗（即使这种计算比训练简单和快得多）。这是因为模型只需训练一次，就可以用于数十亿次推理。

在复杂模型上扩展推理可能非常昂贵，并且具有显著的能源和环境影响。降低模型复杂性或压缩极其复杂的模型可以降低操作机器学习模型的基础设施成本。

重要的是要记住，并非所有应用程序都需要深度学习，事实上，并非所有应用程序都需要机器学习。在生产中控制复杂性的一种有价值的实践是仅开发复杂模型以提供看似可行的基准。然后，投入生产的可以是一个更简单的模型，具有降低操作风险、提高计算性能和降低功耗的优点。如果简单模型接近高复杂性基准，那么它可能是更为理想的解决方案。

模型风险评估

在探讨在理想的 MLOps 系统中如何进行验证之前，重要的是考虑验证的目的。如第四章所述，模型试图模拟现实，但它们是不完美的；它们的实施可能存在错误，环境也可能存在问题。模型在生产中可能产生的间接实际影响从未确定，看似微不足道的零件故障可能在复杂系统中造成巨大后果。

模型验证的目的

在某种程度上，预见在生产中模型的风险并设计和验证以尽量减少这些风险是可能的（更不用说绝对必要的）。随着组织变得越来越复杂，了解机器学习在企业中的大多数应用中无意故障或恶意攻击潜在威胁的重要性至关重要，这不仅限于金融或与安全相关的应用。

在将模型投入生产之前（事实上，从机器学习项目开始的时候就应该如此），团队应该问一些不舒服的问题：

• 如果模型以最坏的可能方式行事会发生什么？

• 如果用户成功提取了训练数据或模型的内部逻辑会发生什么？

• 金融、商业、法律、安全和声誉风险是什么？

对于高风险应用程序，整个团队（特别是负责验证的工程师）充分了解这些风险至关重要，以便他们可以适当地设计验证流程，并应用适合风险程度的严格性和复杂性。

在许多方面，机器学习风险管理涵盖了许多行业（如银行和保险业）中已经建立的模型风险管理实践。然而，机器学习引入了新类型的风险和责任，随着数据科学的普及化，涉及到许多没有传统模型风险管理经验的新组织或团队。

ML 模型风险的起源

由于数学原因，机器学习模型可能带来的风险大小难以建模，同时风险的具体化是通过真实世界的后果而来。机器学习指标，特别是成本矩阵，允许团队评估在其“标准”情况下运行模型的平均成本，即在其交叉验证数据上，与运行完美的魔法模型相比。

尽管计算预期成本非常重要，但是事情出了意外的范围远远超出了预期成本。在某些应用中，风险可能是财务上无限的责任，个人的安全问题，或者对组织的生存威胁。机器学习模型的风险主要源自：

• 在设计、训练或评估模型（包括数据准备）中的错误或缺陷

• 运行框架中的错误，模型后处理/转换中的错误，或者模型与其运行时之间的隐藏不兼容性。

• 训练数据质量低

• 生产数据与训练数据之间的高差异

• 预期错误率，但是失败的后果比预期更严重

• 模型的误用或其输出的误解

• 对抗性攻击

• 法律风险，特别是来自版权侵权或对模型输出的责任

• 由于偏见、机器学习的不道德使用等而引起的声誉风险。

风险的具体化概率及其大小可能会被以下因素放大：

• 模型的广泛应用

• 环境快速变化

• 模型之间复杂的交互作用

以下部分详细介绍了这些威胁及其如何减轻，这应该是组织实施的任何 MLOps 系统的最终目标。

机器学习的质量保证

软件工程已经为质量保证（QA）开发了一套成熟的工具和方法，但是数据和模型的等效物仍处于初级阶段，这使得将其纳入 MLOps 流程变得具有挑战性。统计方法以及文档编写的最佳实践是众所周知的，但在规模上实施并不常见。

尽管本章在为生产准备的一部分中进行了覆盖，但要明确的是，机器学习的质量保证并不仅限于最终验证阶段；相反，它应伴随模型开发的所有阶段进行。其目的是确保符合流程以及机器学习和计算性能要求，并且其详细程度与风险水平成比例。

如果负责验证的人员不是开发模型的人员，他们足够了解机器学习并理解风险非常重要，以便设计适当的验证或检测开发团队提出的验证中的漏洞。组织的结构和文化赋予他们适当报告问题和促进持续改进或阻止投入生产的权威同样至关重要，如果风险水平合理，必须有权利行使它。

强大的 MLOps 实践规定，在发送到生产之前进行 QA 不仅仅是技术验证。这也是创造文档和根据组织指南验证模型的机会。特别是，这意味着所有输入数据集、预训练模型或其他资产的来源都应该是已知的，因为它们可能受到法规或版权的约束。出于这个原因（特别是出于计算机安全原因），一些组织选择只允许白名单依赖项。虽然这可能会显著影响数据科学家快速创新的能力，尽管依赖项列表可以部分自动报告和检查，但也可以提供额外的安全性。

主要测试考虑因素

显然，模型测试将包括将模型应用于精心筛选的数据，并根据要求验证测量。数据的选择或生成方式以及所需的数据量至关重要，但这将取决于模型处理的问题。

有一些情况下，测试数据不应总是与“真实世界”数据匹配。例如，准备一定数量的场景可能是一个好主意，其中一些场景应该与现实情况相匹配，其他数据应特别生成以可能引发问题的方式（例如，极端值、缺失值）。

必须收集统计（准确性、精度、召回率等）以及计算（平均延迟、第 95 百分位延迟等）方面的度量，并且如果对它们的一些假设未经验证，则测试场景应该失败。例如，如果模型的准确性低于 90％、平均推断时间超过 100 毫秒或超过 5％的推断时间超过 200 毫秒，则测试应该失败。这些假设也可以称为期望、检查或断言，就像传统软件工程中一样。

对结果进行统计测试也是可能的，但通常用于子群体。能够比较模型与其先前版本也很重要。它可以实施冠军/挑战者方法（详细描述在“冠军/挑战者”）或检查指标是否突然下降。

除了验证机器学习和计算性能指标之外，模型稳定性是一个重要的测试属性需要考虑。当略微改变一个特征时，预期结果会有轻微变化。尽管这并非总是正确的，但通常是一个期望的模型属性。一个非常不稳定的模型会引入很多复杂性和漏洞，同时即使具有良好的性能，模型也可能感觉不可靠，这会带来令人沮丧的体验。关于模型稳定性没有单一的答案，但一般来说，更简单或更规范化的模型表现出更好的稳定性。

可复现性和可审计性

在 MLOps 中，可复现性与学术界并不具有相同的意义。在学术界，可复现性基本上意味着实验的发现描述得足够好，以至于另一位胜任的人士仅凭解释就能复制实验，如果该人没有任何错误，他们将得出相同的结论。

一般而言，在 MLOps 中，可复现性还包括轻松重新运行完全相同的实验的能力。这意味着模型配备了详细的文档、用于训练和测试的数据，并且具有捆绑模型实现以及运行环境完整规范的工件（参见“版本管理和可复现性”）。可复现性对证明模型发现至关重要，同时也有助于调试或在先前实验基础上进行构建。

可审计性与可复现性有关，但它增加了一些要求。要使模型可审计，必须能够从中心和可靠的存储访问整个 ML 管道的完整历史，并轻松获取所有模型版本的元数据，包括：

• 全面的文档

• 一个工件，允许在其精确的初始环境中运行模型

• 测试结果，包括模型解释和公平性报告

• 详细的模型日志和监控元数据

可审计性在某些高度监管的应用程序中可能是一种义务，但对所有组织都有益处，因为它可以促进模型调试、持续改进，并跟踪行动和责任（这是负责任地应用机器学习的治理的重要组成部分，详细讨论见第八章）。用于机器学习和因此 MLOps 过程的完整 QA 工具链应该提供对模型性能符合要求的清晰视图，同时也促进可审计性。

即使在 MLOps 框架允许数据科学家（或其他人员）找到具有所有元数据的模型时，理解模型本身仍然可能具有挑战性（详见“负责任人工智能对建模的影响”进行详细讨论）。

要在实践中产生强大的影响，审计必须允许直观地理解系统的所有部分及其版本历史。这并不改变理解机器学习模型（甚至是相对简单的模型）需要适当的培训的事实，但根据应用的关键性，更广泛的受众可能需要能够理解模型细节。因此，全面的审计性需要付出一定的成本，这应该与模型本身的关键性取得平衡。

机器学习安全

作为一款软件，部署在其服务框架中的模型可能存在多个安全问题，从低级别的故障到社会工程学。机器学习引入了一系列潜在威胁，攻击者提供恶意数据，旨在使模型出错。

有许多潜在攻击案例。例如，垃圾邮件过滤器是机器学习的早期应用，基本上是基于对字典中的单词进行打分。垃圾邮件创作者避免检测的一种方法是避免使用这些确切的单词，同时仍然使其消息对人类读者易于理解（例如，使用异国情调的 Unicode 字符，故意引入拼写错误或使用图像）。

对抗攻击

一个更现代但相当类似的例子是机器学习模型安全问题中的对抗攻击，特别是针对深度神经网络的对抗攻击，其中对人眼来说可能看起来微小甚至不可能察觉的图像修改可以导致模型显著改变其预测。其核心思想在数学上相对简单：由于深度学习推理本质上是矩阵乘法，精心选择的小扰动系数可以导致输出数字的大幅变化。

这个例子是，小贴纸粘在路标上可以迷惑自动驾驶汽车的计算机视觉系统，使得标志对系统来说看不见或者分类错误，但对人类来说仍然是完全可见和理解的。攻击者对系统了解越多，就越有可能找到能够迷惑它的例子。

人类可以使用理性来找到这些例子（特别是对于简单模型）。然而，对于更复杂的深度学习模型，攻击者可能需要执行许多查询，要么使用蛮力测试尽可能多的组合，要么使用模型搜索问题示例。随着模型复杂性和其可用性的增加，对抗措施的难度也在增加。像逻辑回归这样的简单模型基本上是免疫的，而开源预训练深度神经网络即使配备先进的内置攻击检测器也基本上是脆弱的。

对抗攻击不一定发生在推断时。如果攻击者能够部分获取训练数据，那么他们就控制了系统。这种攻击通常被称为计算机安全中的“毒化攻击”。

一个著名的例子是微软在 2016 年发布的Twitter 聊天机器人。发布几小时后，该机器人开始生成非常冒犯性的推文。这是由于机器人适应其输入；当意识到一些用户提交了大量冒犯性内容时，机器人开始复制。理论上，毒化攻击可以由入侵或甚至更复杂地通过预训练模型引起。但实际上，大多数情况下应关注来自易于操纵的数据源收集的数据。发送给特定账户的推文是一个特别明显的例子。

其他漏洞

一些模式并非利用机器学习漏洞本身，但它们确实以导致不良情况的方式使用机器学习模型。一个例子是信用评分：对于一定金额的贷款，灵活性较低的借款人倾向于选择较长的还款期以降低月供，而不太担心还款能力的借款人可能选择较短的还款期以降低总成本。销售人员可能建议那些信用评分不够好的人缩短还款期。这增加了借款人和银行的风险，并不是一个有意义的行动。相关性不等于因果关系！

模型也可以通过多种方式泄露数据。由于机器学习模型基本上可以被视为对其训练数据的总结，它们可以泄漏更多或更少精确的训练数据信息，有时甚至泄漏整个训练集。例如，假设一个模型使用最近邻算法预测某人的收入。如果知道某人注册在服务上的邮政编码、年龄和职业，那么获取该人的确切收入就非常容易。有各种攻击方式可以从模型中提取信息。

除了技术强化和审计之外，治理在安全中起着至关重要的作用。责任必须明确分配，并确保在安全与执行能力之间达到适当的平衡。建立反馈机制也非常重要，员工和用户应该有一个便捷的渠道来报告违规行为（包括潜在的“漏洞赏金计划”来奖励漏洞报告）。此外，建立系统安全网以减少风险也是可能且必要的。

机器学习安全与一般计算机系统安全有许多共同特征，其中一个主要观点是安全不是系统的额外独立特性；换句话说，通常不能保护一个本身设计不安全的系统，组织的流程必须从一开始就考虑到威胁的本质。强大的 MLOps 流程，包括本章描述的所有准备生产的步骤，可以帮助实现这种方法。

模型风险缓解

一般来说，如在第一章详细讨论的那样，模型部署越广泛，风险就越大。当风险影响足够大时，控制新版本的部署至关重要，这就是严格控制的 MLOps 流程特别重要的地方。渐进式或金丝雀发布应该是常规做法，首先将新模型版本提供给组织或客户群体的一小部分，并逐步增加比例，同时监控行为并在必要时获取人类反馈。

变化的环境

急速变化的环境也会增加风险，正如本章前文所述。输入的变化是一个相关且被充分认识的风险，第七章深入探讨了这些挑战及其详细解决方法。但需要注意的是，变化的速度可以根据应用放大风险。变化可能如此之快，以至于在监控系统发送警报之前就已经产生后果。也就是说，即使有高效的监控系统和重新训练模型的程序，应对所需的时间可能是一个关键威胁，尤其是如果仅仅在新数据上重新训练模型不足以应对，还需开发新模型。在此期间，生产系统的失控可能会给组织造成巨大损失。

为了控制这种风险，通过 MLOps 进行的监控应该足够灵活反应（通常每周警报分布可能不够），并且该程序应考虑到修复所需的时段。例如，除了重新训练或部署策略外，该程序可能定义触发系统降级模式的阈值。降级模式可能只是向最终用户显示警告消息，但也可能会像关闭有问题的系统那样极端，以避免损害，直到能够部署稳定的解决方案为止。

经常发生的较少戏剧性问题也可能造成难以控制的伤害。如果环境经常变化，即使没有及时的修复，模型也可能总是有些偏差，从未在其名义情况下运行，并且操作成本可能难以评估。这只能通过专门的 MLOps 检测到，包括相对长期的监控和重新评估模型操作成本。

在许多情况下，对更多数据重新训练模型将逐渐改善模型，这个问题最终会消失，但这可能需要时间。在此收敛之前，一种解决方案可能是使用较少复杂的模型，该模型可能在频繁变化的环境中具有较低的评估性能，可能更加一致。

模型之间的相互作用

模型之间复杂的相互作用可能是最具挑战性的风险来源。随着机器学习模型的普及，这类问题将成为一个越来越重要的关注点，也是 MLOps 系统的一个重要潜在领域。显然，增加模型往往会给组织增加复杂性，但这种复杂性并不一定与模型数量成比例地线性增长；有两个模型比它们的总和更复杂理解，因为它们之间可能存在潜在的相互作用。

此外，总体复杂性很大程度上由局部尺度上的模型相互作用设计和组织尺度上的治理所决定。在链式使用模型（一个模型使用另一个模型的输入）时，可能会产生显著的额外复杂性以及完全意想不到的结果，而在独立并行处理链中使用模型，每个链尽可能简短和可解释，是设计大规模机器学习部署的更可持续方式。

首先，模型之间明显缺乏交互作用会使复杂性接近线性增长（尽管实际上很少见，因为即使模型不连接，现实世界中总是可能存在交互作用）。此外，使用冗余处理链中的模型可以避免错误——即，如果决策基于几个独立的处理链，其方法尽可能不同，可能更加稳健。

最后，一般而言，模型越复杂，其与其他系统的交互可能越复杂，因为它可能有许多边界情况，在某些领域中的稳定性较差，对上游模型的变化反应过度，或者混淆敏感的下游模型等等。在这里，我们再次看到模型复杂性具有成本，而且可能是高度不可预测的成本。

模型的错误行为

可以采取多种措施来避免模型的误行为，包括实时检查其输入和输出。在训练模型时，可以通过检查模型训练和验证的区间来确定其适用领域。如果推理时某个特征值超出了范围，系统可以触发适当的措施（例如拒绝样本或发送警告消息）。

控制特征值区间是一种有用且简单的技术，但可能不足以解决问题。例如，当训练评估汽车价格的算法时，数据可能提供了最近的轻型汽车和旧重型汽车的示例，但没有最近的重型汽车。这些情况下，对于复杂模型的性能是不可预测的。当特征数量很大时，由于维数灾难的存在，即特征组合的数量相对于特征数量呈指数增长，这个问题变得不可避免。

在这些情况下，可以使用更复杂的方法，包括异常检测来识别模型在其应用领域之外使用的记录。在评分之后，可以在确认推理之前检查模型的输出。对于分类问题，许多算法除了提供预测外还提供确信度分数，可以设定一个阈值来接受推理输出。请注意，即使这些确信度分数在模型中以此方式命名，它们通常不会转化为概率。

合一预测 是一组技术，有助于校准这些得分，以获得正确性概率的准确估计。对于回归问题，可以将预测值与预定区间进行检查。例如，如果模型预测汽车价格为$50 或$500,000，您可能不希望根据此预测做任何业务承诺。实施技术的复杂性应与风险水平相关联：高度复杂且高度关键的模型将需要更严格的保护措施。

总结思考

在实际操作中，准备模型投入生产的工作从开发阶段开始；也就是说，在开发模型时应考虑到生产部署的需求、安全影响以及风险缓解方面。MLOps 包括在将模型送入生产之前进行明确的验证步骤，成功准备模型投入生产的关键思想包括：

• 明确识别风险的性质及其大小

• 理解模型复杂性及其在多个层面上的影响，包括增加的延迟、增加的内存和功耗、在生产中解释推理的能力降低以及更难控制的风险

• 提供简单而清晰的质量标准，确保团队接受了适当的培训，并且组织结构允许快速可靠的验证流程

• 自动化所有可以自动化的验证，以确保它被正确且一致地执行，同时保持快速部署的能力

第六章：部署到生产环境

Joachim Zentici

业务领导者认为将新系统快速部署到生产环境是最大化业务价值的关键。但前提是部署必须顺利进行且风险低（近年来，为解决这一固有冲突，软件部署流程已变得更加自动化和严格）。本章深入探讨了将机器学习模型部署到生产环境时的概念和考虑因素，这些因素影响并驱动着 MLOps 部署流程的建立（图 6-1 在更大生命周期的背景下展示了此阶段）。

图 6-1。在 ML 项目生命周期的更大背景下突出显示的生产部署

CI/CD 管道

CI/CD 是连续集成和连续交付（或更简单地说，部署）的常见缩写。这两者构成了敏捷软件开发的现代理念，是一组实践和工具，能够更频繁、更快地发布应用程序，同时更好地控制质量和风险。

虽然这些思想已有几十年历史，并且已被软件工程师在各种程度上广泛使用，但不同的人和组织对某些术语的使用方式差异很大。在深入讨论 CI/CD 如何应用于机器学习工作流程之前，有一点很重要，那就是这些概念应该是服务于快速交付高质量的工具，并且第一步始终是识别组织中存在的具体风险。换句话说，CI/CD 方法论应根据团队的需求和业务的性质进行调整。

CI/CD 的概念不仅适用于传统软件工程，而且同样适用于机器学习系统，并且是 MLOps 战略的关键部分。成功开发模型后，数据科学家应将代码、元数据和文档推送到中央存储库并触发 CI/CD 管道。这种管道的一个示例可能是：

1. 构建模型

   1. 构建模型工件

   2. 将工件发送到长期存储

   3. 运行基本检查（烟雾测试/合理性检查）

   4. 生成公平性和可解释性报告

2. 部署到测试环境

   1. 运行测试以验证 ML 性能、计算性能

   2. 手动验证

3. 部署到生产环境

   1. 将模型部署为金丝雀

   2. 全面部署模型

可能存在多种场景，这些场景取决于应用程序、系统需要保护的风险以及组织选择运作的方式。一般来说，偏好于增量构建 CI/CD 管道的方法：一个团队可以迭代的简单甚至是天真的工作流程通常比从头开始构建复杂基础设施要好得多。

起始项目没有技术巨头的基础设施要求，并且很难事先知道部署将提出哪些挑战。有一些常见的工具和最佳实践，但没有一种大小适合所有的 CI/CD 方法论。这意味着最佳路径是从一个简单（但完全功能的）CI/CD 工作流开始，并在质量或扩展挑战出现时逐步引入额外或更复杂的步骤。

构建 ML 构件

持续集成流水线的目标是避免合并来自多个贡献者的工作的不必要的工作量，尽早检测错误或开发冲突。第一步是使用集中式版本控制系统（不幸的是，在仅存储在笔记本电脑上的代码上工作几周仍然相当常见）。

最常见的版本控制系统是 Git，这是一个开源软件，最初开发用于管理 Linux 内核的源代码。全世界的大多数软件工程师已经在使用 Git，并且它越来越多地被科学计算和数据科学所采用。它允许保持清晰的变更历史记录，安全地回滚到代码的先前版本，多个贡献者可以在他们自己的项目分支上工作，然后合并到主分支，等等。

虽然 Git 适用于代码，但它并非设计用于存储数据科学工作流中常见的其他类型的资产，如大型二进制文件（例如，训练模型权重），或者对数据本身进行版本控制。数据版本控制是一个更复杂的话题，有许多解决方案，包括 Git 扩展、文件格式、数据库等。

ML 构件中包含什么？

一旦代码和数据位于集中存储库中，项目必须构建一个可测试和可部署的包。在 CI/CD 的背景下，这些包通常称为构件。每个以下元素都需要打包成一个通过测试流水线的构件，并可供部署到生产环境使用：

• 模型及其预处理的代码

• 超参数和配置。

• 训练和验证数据

• 可运行形式的训练模型。

• 包括具有特定版本、环境变量等的环境。

• 文档

• 用于测试场景的代码和数据

测试流水线

如在第五章中所述，测试流水线可以验证构件中包含的模型的各种属性。测试的一个重要操作方面是，在验证与需求的一致性之外，良好的测试应尽可能地简化故障排除时的问题源定位。

为此，命名测试非常重要，并且精心选择一些数据集来验证模型的方法可能会很有价值。例如：

• 可以首先执行一个固定数据集（不自动更新）、具有简单数据和不太严格的性能阈值的测试，并称之为“基准案例”。如果测试报告显示此测试失败，那么模型严重偏离的可能性很大，原因可能是编程错误或模型的误用等。

• 然后，可以使用多个具有特定异常（缺失值、极端值等）的数据集，并适当命名这些测试，以便测试报告立即显示可能使模型失败的数据类型。这些数据集可以代表现实但显著的案例，但生成预计不会在生产中出现的合成数据也可能很有用。这可能会保护模型免受尚未遇到的新情况的影响，但更重要的是，这可能会保护模型免受系统查询故障或对抗性示例（如在“机器学习安全性”中讨论的）。

• 模型验证的一个重要部分是在最新的生产数据上进行测试。应使用一个或多个数据集，从不同时间窗口提取并适当命名。这类测试应在模型已经部署到生产环境时进行并自动分析。第七章提供了更详细的关于如何执行的细节。

尽可能自动化这些测试至关重要，实际上是高效 MLOps 的关键组成部分。缺乏自动化或速度会浪费时间，但更重要的是，它会使开发团队不愿意经常进行测试和部署，这可能会延迟发现导致无法部署到生产的错误或设计选择。

在极端情况下，开发团队可以将一个长达数月的项目交给部署团队，但因为不满足生产基础设施的要求而被简单拒绝。此外，较少频繁的部署意味着较大的增量，这些增量更难以管理；当系统出现多个更改同时部署且表现不如预期时，问题来源的隔离将更加耗时。

软件工程持续集成中最常见的工具是 Jenkins，这是一个非常灵活的构建系统，允许构建无论使用哪种编程语言、测试框架等的 CI/CD 流水线。Jenkins 可用于数据科学中的 CI/CD 流水线编排，尽管还有许多其他选择。

部署策略

要理解部署流水线的细节，重要的是要区分那些经常不一致或可互换使用的概念。

集成

合并贡献到中央仓库的过程（通常是将 Git 特性分支合并到主分支）并执行更多或更少复杂的测试。

交付

在持续交付（CD）的部分中，构建完整打包和验证的模型版本，以便部署到生产环境。

部署

在目标基础设施上运行新模型版本的过程。完全自动化部署并非始终切实可行或理想，这是一项商业决策，同样也是技术决策，而持续交付则是开发团队提高生产力和质量以及更可靠地衡量进展的工具。持续交付是持续部署所必需的，但即使在没有持续部署的情况下，它也能提供巨大的价值。

发布

原则上，发布是另一个步骤，因为部署模型版本（即使是到生产基础设施）并不一定意味着生产工作负载会指向新版本。正如我们将看到的那样，多个模型版本可以同时在生产基础设施上运行。

确保 MLOps 过程中每个人对这些概念的理解达成一致，并了解其应用方式，将有助于技术和业务两方面的流程更加顺畅。

模型部署的分类

除了不同的部署策略外，还有两种方法可以进行模型部署：

• 批量评分，即使用模型处理整个数据集，例如每日定期作业。

• 实时评分，其中一个或少数记录得分，例如在网站上显示广告并且模型根据用户会话决定显示什么。

在这两种方法之间存在一种连续性，实际上，在某些系统中，对一个记录进行评分在技术上与请求一个批次的一样。在这两种情况下，可以部署多个模型实例以增加吞吐量并可能降低延迟。

部署许多实时评分系统在概念上更简单，因为要得分的记录可以分配到多台机器之间（例如使用负载均衡器）。批量评分也可以并行化，例如使用像 Apache Spark 这样的并行处理运行时，还可以通过分割数据集（通常称为分区或分片）并独立对分区进行评分。请注意，这两个数据和计算分割的概念可以结合起来，因为它们可以解决不同的问题。

将模型发送到生产时的考虑事项

在将新模型版本发送到生产时，首要考虑通常是避免停机时间，特别是对于实时评分。基本思想是，与其关闭系统、升级它，然后重新上线，不如在稳定系统旁边设置一个新系统，在其功能正常后将工作负载指向新部署的版本（如果保持健康，则关闭旧版本）。这种部署策略称为蓝绿部署，有时也称为红黑部署。有许多变体和框架（如 Kubernetes）可以本地处理这些。

另一个更高级的减轻风险的解决方案是拥有金丝雀发布（也称为金丝雀部署）。其想法是将模型的稳定版本保留在生产中，但将一定比例的工作负载重定向到新模型，并监控结果。这种策略通常用于实时评分，但也可以考虑用于批处理。

可以执行一些计算性能和统计测试来决定是否完全切换到新模型，可能分几个工作负载百分比递增。这样，故障可能只会影响到工作负载的一小部分。

金丝雀发布适用于生产系统，因此任何故障都是事故，但这里的想法是限制影响范围。请注意，由金丝雀模型处理的评分查询应该谨慎选择，因为否则可能会忽略一些问题。例如，如果在模型全球完全发布之前，金丝雀模型只服务于某个地区或国家的一小部分用户，这可能是因为（出于机器学习或基础设施原因）该模型在其他地区的表现不如预期。

一个更加稳健的方法是随机选择服务于新模型的用户部分，但通常为了用户体验，实现一个亲和机制是有必要的，这样同一用户始终使用相同版本的模型。

金丝雀测试可用于进行 A/B 测试，这是一个比较应用程序两个版本的业务性能指标的过程。这两个概念是相关的，但并不相同，因为它们不在同一抽象级别上运行。A/B 测试可以通过金丝雀发布来实现，但也可以直接编码为应用程序的单个版本中的逻辑。第七章提供了有关建立 A/B 测试的统计方面更多细节。

总的来说，金丝雀发布是一个强大的工具，但需要一定的先进工具来管理部署、收集指标、指定和运行计算、显示结果以及分发和处理警报。

生产环境下的维护

一旦模型发布，就必须进行维护。在高层面上，有三项维护措施：

资源监控

与在服务器上运行的任何应用程序一样，收集 CPU、内存、磁盘或网络使用等 IT 指标可以帮助检测和排除问题。

健康检查

为了检查模型是否在线并分析其延迟，通常会实现一个健康检查机制，该机制简单地查询模型，查询间隔固定（大约一分钟），并记录结果。

ML 指标监控

这是关于分析模型的准确性，并与另一个版本进行比较或检测其是否过时的过程。由于可能需要大量计算资源，这通常是低频操作，但像往常一样，这将取决于应用程序；通常每周执行一次。第七章详细介绍了如何实现此反馈循环。

最后，当检测到故障时，可能需要回滚到之前的版本。有必要准备回滚流程，并尽可能自动化；定期测试可以确保其确实可用。

容器化

正如前文所述，管理模型的版本远不止将其代码保存到版本控制系统中。特别是需要提供环境的精确描述（包括所有使用的 Python 库及其版本，需要安装的系统依赖项等）。

但仅仅存储这些元数据是不够的。将其部署到生产环境应该自动且可靠地在目标机器上重建此环境。此外，目标机器通常会同时运行多个模型，而两个模型可能具有不兼容的依赖版本。最后，同一台机器上运行的多个模型可能会竞争资源，一个表现不佳的模型可能会影响多个共存模型的性能。

容器技术越来越多地用于解决这些挑战。这些工具将应用程序与其所有相关的配置文件、库和依赖项捆绑在一起，以便在不同的操作环境中运行。与虚拟机（VM）不同，容器不复制完整的操作系统；多个容器共享一个公共操作系统，因此资源效率更高。

最知名的容器技术是开源平台 Docker。自 2014 年发布以来，它已成为事实上的标准。它允许将应用程序打包发送到服务器（Docker 主机），并在与其他应用程序隔离的环境中运行其所有依赖项。

构建一个可以容纳多个模型的模型服务环境的基础，每个模型可能运行多个副本，可能需要多个 Docker 主机。在部署模型时，框架应该解决一些问题：

• 哪些 Docker 主机应接收该容器？

• 当一个模型部署在多个副本中时，如何平衡工作负载？

• 如果模型变得无响应，例如，如果托管它的机器失败了会发生什么？如何检测到并重新提供容器？

• 如何升级在多台机器上运行的模型，并确保旧版本和新版本的切换以及负载均衡器更新正确的顺序？

Kubernetes 是一个开源平台，在过去几年中获得了很多关注，并且正在成为容器编排的标准。它极大地简化了这些问题以及许多其他问题。它提供了一个强大的声明式 API 来在一组 Docker 主机中运行应用程序，称为 Kubernetes 集群。声明式的含义是，用户不需要试图用代码表达设置、监视、升级、停止和连接容器的步骤（这可能会很复杂且容易出错），而是在配置文件中指定所需的状态，Kubernetes 将实现并维护它。

例如，用户只需告诉 Kubernetes“确保始终运行四个此容器的实例”，Kubernetes 将分配主机、启动容器、监视它们，并在其中一个失败时启动新实例。最后，主要的云服务提供商都提供托管的 Kubernetes 服务；用户甚至不必安装和维护 Kubernetes 本身。如果应用程序或模型被打包为 Docker 容器，用户可以直接提交它，服务将为运行一个或多个容器实例而配置所需的机器。

Docker 与 Kubernetes 结合可以提供强大的基础设施来托管应用程序，包括 ML 模型。利用这些产品极大地简化了部署策略的实施，比如蓝绿部署或金丝雀发布，尽管它们并不了解部署的应用程序的特性，因此无法本地管理 ML 性能分析。这种类型基础设施的另一个主要优势是轻松扩展模型的部署。

扩展部署

随着 ML 的采纳增长，组织面临两种类型的增长挑战：

• 能够在高规模数据环境中将模型用于生产

• 能够训练更多和更多的模型

对于实时评分处理更多数据，像 Kubernetes 这样的框架大大简化了工作。由于大多数时间训练好的模型本质上是公式，它们可以在集群中复制成任意数量的副本。在 Kubernetes 的自动扩展功能下，新增机器的配置和负载均衡都完全由框架处理，建立具有巨大扩展能力的系统现在相对简单。主要的困难可能是处理大量监控数据；第七章提供了关于这一挑战的一些细节。

对于批量评分，情况可能更复杂。当数据量变得过大时，基本上有两种分布计算的策略：

• 使用本地处理分布式计算的框架，特别是 Spark。Spark 是一个开源的分布式计算框架。重要的是要理解 Spark 和 Kubernetes 不扮演相似的角色，并且可以结合使用。Kubernetes 编排容器，但 Kubernetes 不知道容器实际在做什么；对于 Kubernetes 来说，它们只是在特定主机上运行应用程序的容器。特别是，Kubernetes 没有数据处理的概念，因为它可用于运行任何类型的应用程序。Spark 是一个可以将数据和计算分配到其节点的计算框架。使用 Spark 的现代方式是通过 Kubernetes。要运行 Spark 作业，Kubernetes 启动所需数量的 Spark 容器；一旦启动，它们可以通信完成计算，然后销毁容器并释放资源供其他应用程序使用，包括可能具有不同 Spark 版本或依赖项的其他 Spark 作业。

• 另一种分发批处理的方法是对数据进行分区。有许多实现方法，但总体思路是评分通常是逐行操作（逐行评分），数据可以以某种方式分割，以便多台机器每台读取数据的子集并评分部分行。

就计算而言，增加模型数量相对较简单。关键是增加计算能力并确保监控基础设施能够处理工作负载。但在治理和流程方面，这是最具挑战性的情况。

特别是，增加模型数量意味着 CI/CD 流水线必须能够处理大量的部署。随着模型数量的增加，自动化和治理的需求也增长，因为人工验证不能保证系统性或一致性。

在某些应用中，如果通过自动化验证、金丝雀发布和自动化金丝雀分析有效控制了风险，完全可以依赖于全自动化持续部署。由于训练、模型构建、测试数据验证等工作都需要在集群上进行而非单台机器上进行，可能会面临许多基础设施挑战。此外，随着模型数量的增加，每个模型的持续集成/持续部署（CI/CD）流水线可能差异很大，如果不加处理，每个团队都必须为每个模型开发自己的 CI/CD 流水线。

从效率和治理的角度来看，这是不够理想的。虽然某些模型可能需要高度特定的验证流水线，但大多数项目可能可以使用少量通用模式。此外，由于可能不实用实施新的系统验证步骤，比如流水线不一定共享通用结构，因此维护变得更加复杂，甚至在程序化方面也难以安全地更新。分享实践和标准化的流水线可以帮助限制复杂性。还可以使用专门的工具来管理大量流水线；例如，Netflix 发布了 Spinnaker，这是一个开源的持续部署和基础设施管理平台。

需求和挑战

在部署模型时，存在几种可能的情况：

• 一个模型部署在一个服务器上

• 一个模型部署在多个服务器上

• 多个模型的多个版本部署在一个服务器上

• 一个模型的多个版本部署在多个服务器上

• 多个模型的多个版本部署在多个服务器上

一个有效的日志记录系统应该能够生成中心化的数据集，这些数据集可以被模型设计师或 ML 工程师利用，通常是在生产环境之外。具体来说，它应该涵盖以下所有情况：

• 系统可以访问并从多个服务器检索评分日志，无论是实时评分用例还是批处理评分用例。

• 当一个模型部署在多个服务器上时，系统可以处理每个模型在服务器上的映射和聚合所有信息。

• 当不同版本的模型部署时，系统可以处理每个模型版本在服务器上的映射和聚合所有信息。

就挑战而言，对于大规模机器学习应用程序来说，如果没有预处理步骤来过滤和聚合数据，生成的原始事件日志数量可能是一个问题。对于实时评分的用例，记录流式数据需要设置一整套新的工具，这需要大量的工程努力来维护。然而，在这两种情况下，因为监控的目标通常是估计聚合指标，所以只保存预测的一个子集可能是可以接受的。

总结思考

将模型部署到生产环境是 MLOps 的关键组成部分，正如本章所分析的，拥有正确的流程和工具可以确保快速部署。好消息是，许多成功的要素，特别是 CI/CD 的最佳实践，并不是新的。一旦团队了解如何将其应用于机器学习模型，组织将拥有一个良好的基础，可以随着业务的扩展而扩展 MLOps。

第七章：监控与反馈循环

杜凡

当一个机器学习模型部署到生产环境中时，它可能会迅速降低质量，而且没有警告，直到为时已晚（即它对业务可能造成负面影响）。这就是为什么模型监控是机器学习模型生命周期中至关重要的一步，也是 MLOps 的关键部分（如 图 7-1 所示，作为整体生命周期的一部分）。

图 7-1. 在机器学习项目生命周期的更大背景下突出显示的监控和反馈循环

机器学习模型需要在两个层面进行监控：

• 在资源层面上，包括确保模型在生产环境中正常运行。关键问题包括：系统是否正常？CPU、RAM、网络使用情况和磁盘空间是否符合预期？请求是否以预期速率处理？

• 在性能层面上，这意味着随着时间的推移监控模型的相关性。关键问题包括：模型是否仍然准确地反映了新进数据的模式？它在设计阶段的表现是否良好？

第一个层面是传统的 DevOps 主题，在文献中已广泛讨论过（并已在 第六章 中进行了涵盖）。然而，后者则更为复杂。为什么？因为模型的表现如何反映了用于训练它的数据；特别是训练数据与实时请求数据的代表性有多高。随着世界的不断变化，静态模型无法跟上不断出现和演变的新模式。虽然可以检测到单个预测的大偏差（见 第五章），但对评分行数据集中的较小但仍显著的偏差必须在统计上检测，无论有无基础真相。

模型性能监控旨在追踪这种退化，并在适当时机触发使用更具代表性数据重新训练模型。本章详细探讨了数据团队应如何处理监控及随后的重新训练。

模型应该多久重新训练一次？

关于监控和重新训练，团队经常提出的一个关键问题是：模型应该多久重新训练一次？不幸的是，这个问题没有简单的答案，因为它取决于许多因素，包括：

领域

在像网络安全或实时交易这样的领域，模型需要定期更新以跟上这些领域固有的不断变化。物理模型，如语音识别，通常更稳定，因为模式不会突然改变。然而，即使是更稳定的物理模型也需要适应变化：如果一个语音识别模型遇到人咳嗽导致声音音调变化会发生什么？

成本

组织需要考虑重新训练的成本是否值得性能的提升。例如，如果运行整个数据流水线和重新训练模型需要一周时间，那么获得 1%的提升是否值得？

模型性能

在某些情况下，模型性能受到训练样本数量的限制，因此重新训练的决定取决于收集足够的新数据。

无论在哪个领域，获得基本事实的延迟是定义重新训练周期下界的关键。当可能出现预测模型漂移速度快于预测时间和获得基本事实的间隔时，使用预测模型是非常冒险的。在这种情况下，如果漂移过于显著，模型可能会开始给出糟糕的结果，除了撤销模型之外，没有其他措施。实际上，这意味着一年延迟的模型重新训练频率不太可能超过几次。

基于同样的原因，不太可能在比此延迟更短的数据集上训练模型。重新训练也不会在更短的周期内进行。换句话说，如果模型重新训练的频率远高于延迟时间，那么重新训练对模型性能的影响几乎为零。

在重新训练频率时，还需考虑两个组织界限：

一个上界

最好每年进行一次重新训练，以确保负责团队具备这方面的技能（尽管可能发生人员流动，即重新训练模型的人员并非创建模型的人员），并且计算工具链仍然有效。

一个下界

例如，考虑一个具有几乎即时反馈的模型，例如推荐引擎，在预测后用户几秒钟内点击产品。高级部署方案将涉及阴影测试或 A/B 测试，以确保模型的性能符合预期。由于这是统计验证，需要一些时间来收集所需信息。这必然为重新训练周期设定了一个下界。即使是简单的部署过程，也可能允许一些人工验证或手动回滚的可能性，这意味着重新训练不太可能每天发生一次。

因此，重新训练的频率可能在每天至每年一次之间。最简单的解决方案是在与原始训练方式和环境相同的情况下进行重新训练，这是可接受的。一些关键情况可能需要在生产环境中重新训练，即使最初的训练是在设计环境中进行的，但重新训练的方法通常与训练方法相同，以限制总体复杂度。正如常规的规则一样，总是有例外：在线学习。

无论如何，某种程度的模型重新训练肯定是必要的 —— 这不是一个是否的问题，而是一个何时的问题。部署机器学习模型而不考虑重新训练，就像在巴黎向正确的方向发射一架无人机，希望它能够安全地在不需要进一步控制的情况下降落在纽约市一样。

好消息是，如果第一次能够收集足够的数据来训练模型，那么大多数重新训练的解决方案已经可用（可能有交叉训练模型的例外情况，这些模型在不同的上下文中使用，例如，用一个国家的数据训练，但在另一个国家使用）。因此，组织必须通过建立一个允许轻松监控和通知的过程来清楚地了解部署模型的漂移和准确性，这一点至关重要。理想的情况是一个能够自动触发模型性能退化检查的流水线。

需要注意的是，通知的目标不一定是启动自动化的重新训练、验证和部署过程。模型性能可能因各种原因而变化，重新训练并不总是解决方案。重点是通知数据科学家发生了变化；该人员随后可以诊断问题并评估下一步行动。

因此，在 MLOps 和 ML 模型生命周期的一部分，数据科学家及其经理和整个组织（最终必须处理模型性能下降和任何后续更改的业务后果的实体）必须理解模型退化的重要性。实际上，每个部署的模型都应该配备监控度量和相应的警告阈值，以尽快检测到业务绩效的显著下降。以下几节重点介绍了理解这些度量以便为特定模型定义它们的方法。

理解模型退化

一旦机器学习模型在生产环境中训练并部署，有两种方法可以监控其性能退化：地面真实评估和输入漂移检测。理解这些方法背后的理论和局限性对于确定最佳策略至关重要。

地面真实评估

地面真实重新训练需要等待标签事件。例如，在欺诈检测模型中，地面真实是特定交易是否真的欺诈。对于推荐引擎，则是客户是否点击或最终购买了推荐的产品之一。

收集了新的地面真实数据后，下一步是根据地面真实数据计算模型的性能，并将其与训练阶段的注册度量进行比较。当差异超过阈值时，可以认定模型已过时，应该重新训练。

要监控的度量标准可以分为两种类型：

• 像准确度，ROC AUC，对数损失等统计指标。由于模型设计者可能已经选择了其中一个指标来选择最佳模型，因此它是监控的首选候选。对于更复杂的模型，如果平均性能不够，可能需要查看由子群体计算的指标。

• 业务指标，例如成本效益评估。例如，信用评分业务已经开发了自己的特定指标。

第一种指标的主要优势在于它是领域无关的，因此数据科学家可能会对设置阈值感到舒适。为了能够获得最早的有意义警告，甚至可以计算p值来评估观察到的下降不是由于随机波动引起的概率。

缺点在于，下降可能在统计上显著，而没有任何显著影响。或者更糟的是，重新训练的成本和重新部署所带来的风险可能高于预期的收益。业务指标更有趣，因为它们通常具有货币价值，使主题专家能够更好地处理重新训练决策的成本效益权衡。

在可用时，地面真相监控是最佳解决方案。但是，这可能会带来问题。存在三个主要挑战：

• 地面真相通常不是立即，甚至不是紧急可得的。对于某些类型的模型，团队需要等待几个月（甚至更长时间）以获取地面真相标签，如果模型快速退化，这可能导致重大经济损失。如前所述，部署一个漂移速度快于滞后的模型是有风险的。然而，根据定义，漂移是无法预测的，因此具有长滞后的模型需要采取缓解措施。

• 地面真相与预测是解耦的。为了计算部署模型在新数据上的性能，必须能够将地面真相与相应的观察结果进行匹配。在许多生产环境中，这是一项具有挑战性的任务，因为这两个信息片段生成和存储在不同系统和不同时间戳。对于低成本或短寿命的模型来说，可能没有自动地面真相收集的价值。请注意，这种做法相当短视，因为迟早，模型将需要重新训练。

• 地面真相仅部分可得。在某些情况下，检索所有观察结果的地面真相成本极高，这意味着需要选择哪些样本进行标记，从而无意中引入系统偏见。

对于最后一个挑战，欺诈检测提出了一个明确的用例。考虑到每笔交易都需要手动检查且过程耗时，仅为疑似案例（即模型高概率判定为欺诈的案例）建立地面真相是否有意义？乍看之下，这种方法似乎是合理的；然而，有批判性思维的人会理解，这会产生一个反馈循环，放大模型的缺陷。模型从未捕获的欺诈模式（即根据模型具有低欺诈概率的模式）将不会在重新训练过程中考虑进去。

解决此挑战的一种方法可能是随机标记，为除了那些被标记为可疑的事务之外的子样本建立一个地面真相。另一种解决方案可能是重新加权偏倚样本，使其特征更接近总体人群。例如，如果系统很少向低收入人群发放信用，那么模型应根据他们在申请人，甚至总体人群中的重要性进行重新加权。

无论采取什么样的缓解措施，标记的样本子集必须涵盖所有可能的未来预测，以确保训练模型在任何样本上都能做出良好的预测；这有时意味着出于检查模型是否继续良好泛化而做出次优决策。

解决了重新训练的问题后，解决方案（重新加权、随机抽样）可以用于监控。输入漂移检测是这种方法的补充，因为它需要确保提供覆盖新的、未开发领域的地面真相以供重新训练模型使用。

输入漂移检测

鉴于前一节中提出的地面真相重新训练的挑战和限制，一个更实际的方法可能是输入漂移检测。本节简要探讨了漂移背后的逻辑，并呈现了可能导致模型和数据漂移的不同场景。

假设目标是使用UCI 葡萄酒质量数据集作为训练数据来预测波尔多葡萄酒的质量，该数据集包含关于葡萄牙葡萄酒维诺维尔德的红色和白色变种以及在 0 到 10 之间变化的质量评分。

每种葡萄酒提供以下特征：类型、固定酸度、挥发性酸度、柠檬酸、残留糖、氯化物、游离二氧化硫、总二氧化硫、密度、pH 值、硫酸盐和酒精度。

为了简化建模问题，假设一个好的葡萄酒是质量评分等于或大于 7 的葡萄酒。因此，目标是构建一个二元模型，从葡萄酒的属性预测这一标签。

为了演示数据漂移，我们明确将原始数据集分为两部分：

• wine_alcohol_above_11，包含所有酒精度为 11%及以上的葡萄酒

• wine_alcohol_below_11 包含所有酒精含量低于 11% 的葡萄酒

我们将 wine_alcohol_above_11 数据集拆分为训练和评分用途，而第二个数据集 wine_alcohol_below_11 则被视为需要在模型部署后进行评分的新进数据。

我们人为地创造了一个大问题：很难认为葡萄酒的质量与酒精含量无关。更糟糕的是，两个数据集中的酒精含量可能与其他特征的相关性不同。因此，在一个数据集上学到的知识（“如果残余糖低，pH 值高，则葡萄酒好的概率很高”）在另一个数据集上可能是错误的，因为例如，当酒精含量高时，残余糖就不再重要了。

从数学角度来看，每个数据集的样本不能假设是从相同分布中抽取的（即它们不是“同分布的”）。确保 ML 算法按预期执行需要另一个数学属性：独立性。如果数据集中的样本重复或者可以预测“下一个”样本，则该属性被破坏，例如。

假设尽管存在明显的问题，我们仍在第一个数据集上训练算法，然后将其部署在第二个数据集上。由此产生的分布偏移称为漂移。如果酒精含量是 ML 模型使用的特征之一（或者酒精含量与模型使用的其他特征相关），则称为特征漂移；如果不是，则称为概念漂移。

实践中的漂移检测

如前所述，为了能够及时反应，应仅基于传入数据的特征值监控模型行为，而不必等待地面真相的出现。

逻辑是，如果数据分布（例如，均值、标准差、特征之间的相关性）在训练和测试阶段¹与开发阶段之间出现分歧，这是模型性能不同的强烈信号。这并非是完美的缓解措施，因为在漂移数据集上重新训练不是一个选项，但可以作为缓解措施的一部分（例如，返回到更简单的模型，重新加权）。

数据漂移的示例原因

数据漂移有两个常见的根本原因：

• 样本选择偏差，即训练样本不代表总体。例如，建立一个评估折扣计划效果的模型，如果最佳折扣仅为最好的客户提供，那么会存在偏差。选择偏差通常源自数据采集管道本身。在葡萄酒的例子中，原始数据集中酒精含量超过 11%的样本肯定不代表所有葡萄酒的总体——这是样本选择的最佳实践。如果一些酒精含量超过 11%的样本被保留，并根据在部署模型时预期的比例进行重新加权，那么可以减轻这种偏差。需要注意的是，这在实际生活中要做到比说起来更难，因为问题特征通常是未知的，甚至可能根本不可得。

• 非稳态环境，即从源群体收集的训练数据不代表目标群体。这通常发生在依赖时间的任务中，例如具有强季节性影响的预测用例，学习一个在某个月份的模型无法推广到另一个月份。回到葡萄酒的例子：可以想象一种情况，原始数据集样本仅包括特定年份的葡萄酒，这可能代表一个特别好（或坏）的年份。基于这些数据训练的模型可能无法推广到其他年份。

输入漂移检测技术

在理解可能引起不同漂移类型的可能情况后，下一个逻辑问题是：如何检测漂移？本节介绍了两种常见的方法。选择哪种方法取决于期望的可解释性水平。

需要经过验证且可解释的方法的组织应优先选择单变量统计测试。如果预期涉及同时涉及多个特征的复杂漂移，或者数据科学家希望重用已知的内容，假设组织不怕黑盒效应，则领域分类器方法也可能是一个不错的选择。

单变量统计测试

此方法要求对每个特征从源分布和目标分布的数据应用统计检验。当这些检验的结果显著时，将发出警告。

关于假设检验的选择已在文献中广泛研究，但基本方法依赖于这两个测试：

• 对于连续特征，Kolmogorov-Smirnov 检验是一种非参数假设检验，用于检查两个样本是否来自同一分布。它测量了经验分布函数之间的距离。

• 对于分类特征，卡方检验是一个实用的选择，用于检查目标数据中分类特征的观察频率是否与源数据中的预期频率匹配。

p 值的主要优势在于它们帮助尽快检测漂移。主要缺点在于它们检测到一个效果，但不量化效果的程度（即在大型数据集上，它们检测到非常小的变化，这些变化可能完全没有影响）。因此，如果开发数据集非常大，就必须用商业重要的度量补充 p 值。例如，在足够大的数据集上，平均年龄可能从统计角度显著漂移，但如果漂移仅为几个月，对许多业务用例来说可能是无关紧要的值。

领域分类器

在这种方法中，数据科学家训练一个模型，试图区分原始数据集（输入特征和可选的预测目标）和开发数据集。换句话说，他们堆叠两个数据集，并训练一个分类器，旨在预测数据的来源。模型的性能（例如准确性）可以被视为漂移水平的度量标准。

如果这个模型在其任务中取得成功，并且具有较高的漂移分数，这意味着在训练时使用的数据和新数据可以被区分开来，因此可以说新数据已经发生了漂移。为了获得更多的见解，特别是为了识别导致漂移的特征，可以使用训练模型的特征重要性。

结果的解释

领域分类器和单变量统计测试都指出了解释漂移的特征或目标的重要性。需要识别归因于目标的漂移，因为它通常直接影响业务的底线。（例如，信用评分：如果整体评分较低，可能获得贷款的数量也较少，因此收入将较低。）归因于特征的漂移有助于减少漂移的影响，因为它可能暗示着需要：

• 根据这个特征进行重新加权（例如，如果 60 岁以上的顾客现在占用户的 60%，但在训练集中只占 30%，则加倍其权重并重新训练模型）

• 移除该特征并训练一个不包含它的新模型

在所有情况下，如果检测到漂移，自动操作几乎不可能存在。只有在重新训练模型成本高昂时才可能发生这种情况：只有在基于地面真实数据的性能下降或检测到显著漂移时，才会重新对新数据进行训练。在这种特殊情况下，确实可以利用新数据来减轻漂移。

反馈循环

所有有效的机器学习项目都实施一种形式的数据反馈循环；即，来自生产环境的信息流回模型原型环境以进一步改进。

在图 7-2 中可以看到，监控和反馈循环中收集的数据被发送到模型开发阶段（有关这些数据的详细信息在第六章中介绍）。从那里，系统分析模型是否按预期运行。如果是，则无需采取任何行动。如果模型的性能下降，则数据科学家将会自动或手动触发更新。实际上，正如本章开头所述，这通常意味着使用新标记数据重新训练模型或开发具有附加特征的新模型。

图 7-2. 端到端机器学习过程的持续交付

无论哪种情况，目标都是能够捕捉新兴模式，并确保业务不会受到负面影响。这种基础设施由三个主要组件组成，除了本章第一部分讨论的概念外，还对稳健的 MLOps 能力至关重要：

• 一个从几个生产服务器收集数据的日志系统

• 一个进行模型版本控制和评估的模型评估存储库

• 在生产环境中进行模型比较的在线系统，无论是使用阴影评分（冠军/挑战者）设置还是 A/B 测试

后续章节将分别讨论每个组件，包括它们的目的、主要特点和挑战。

日志记录

监控生产系统，无论是否带有机器学习组件，意味着收集和聚合关于其状态的数据。如今，随着生产基础设施变得越来越复杂，同时在多个服务器上部署多个模型，一个有效的日志系统比以往任何时候都更加重要。

这些环境中的数据需要集中存储以便自动或手动分析和监控。这将促使机器学习系统的持续改进。机器学习系统的事件日志是带有时间戳和以下信息的记录。

模型元数据

模型及其版本的识别。

模型输入

新观测的特征值，这些值允许验证新进数据是否符合模型的预期，并因此允许检测数据漂移（如前一节所述）。

模型输出

模型的预测结果，随后与后续收集的真实数据相结合，能够清楚地展示模型在生产环境中的表现。

系统操作

模型预测很少作为机器学习应用的最终产品；更常见的情况是系统根据此预测采取行动。例如，在欺诈检测用例中，当模型给出高概率时，系统可以选择要么阻止交易，要么向银行发送警告。这类信息很重要，因为它影响用户的反应，从而间接影响反馈数据。

模型解释。

在某些高度受监管的领域，如金融或医疗保健，预测必须附带解释（即哪些特征对预测影响最大）。这种信息通常通过 Shapley 值计算等技术来计算，并应记录以识别模型可能存在的问题（例如偏差、过拟合）。

模型评估。

一旦日志系统就位，它定期从生产环境中获取数据进行监控。一切顺利，直到某天触发数据漂移警报：传入数据的分布与训练数据的分布偏离。可能是模型性能正在下降。

审查后，数据科学家决定通过重新训练模型来改进它，使用本章前面描述的技术。在有了多个训练好的候选模型后，下一步是将它们与部署模型进行比较。实际上，这意味着对同一数据集评估所有模型（候选模型和部署模型）。如果其中一个候选模型的表现优于部署模型，则有两种继续的方式：要么在生产环境中更新模型，要么转移到通过冠军/挑战者或 A/B 测试设置进行在线评估。

简而言之，这是模型存储的概念。它是一种结构，允许数据科学家：

• 比较多个新训练的模型版本与现有部署版本。

• 在标记数据上比较完全新的模型与其他模型版本。

• 跟踪模型随时间的表现。

形式上，模型评估存储作为一个结构，集中存储与模型生命周期相关的数据，以便进行比较（尽管需要注意，仅当模型解决相同问题时，比较才有意义）。从定义上来看，所有这些比较都归结为逻辑模型的大伞下。

逻辑模型。

构建机器学习应用是一个迭代的过程，从部署到生产，监控性能，检索数据，并寻找改进系统解决目标问题的方法。有许多迭代的方式，其中一些已经在本章讨论过，包括：

• 使用相同数据对同一模型进行再训练。

• 向模型添加新特征。

• 开发新算法。

出于这些原因，机器学习模型本身不是静态的对象；它随着时间不断变化。因此，对于推理机器学习应用程序，具有更高抽象级别是有帮助的，这被称为逻辑模型。

逻辑模型是解决业务问题的模型模板及其版本的集合。通过在给定数据集上训练模型模板可以获得模型版本。同一逻辑模型的所有模型模板版本通常可以在相同类型的数据集上进行评估（即在具有相同特征定义和/或架构的数据集上）。但是，如果问题没有改变但用于解决问题的特征发生了变化，则可能不会如此。模型版本可以使用完全不同的技术实现，甚至可以有几种实现同一模型版本的方式（例如 Python、SQL、Java 等）。然而，如果给定相同的输入，它们应该会给出相同的预测。

让我们回到本章前面介绍的葡萄酒例子。在部署后的三个月里，关于低酒精葡萄酒的新数据出现了。我们可以在新数据上重新训练我们的模型，从而使用相同的模型模板获得新的模型版本。在调查结果时，我们发现新的模式正在出现。我们可以决定创建捕捉这些信息的新特征并将其添加到模型中，或者我们可以决定使用其他 ML 算法（如深度学习）而不是 XGBoost。这将导致一个新的模型模板。

因此，我们的模型有两个模型模板和三个版本：

• 第一个版本已经在生产环境中上线，基于原始的模型模板。

• 第二个版本基于原始模板，但是在新数据上进行了训练。

• 第三个版本采用基于深度学习的模板，具有额外的功能，并且是在第二个版本相同的数据上训练的。

这些版本在各种数据集上的评估信息（包括训练时使用的测试数据集以及可能在训练后进行评分的开发数据集）随后存储在模型评估存储中。

模型评估存储

作为提醒，模型评估存储是结构，用于集中与模型生命周期相关的数据，以便进行比较。模型评估存储的两个主要任务是：

• 通过时间对逻辑模型的演变进行版本控制。每个记录的逻辑模型版本必须包含关于其训练阶段的所有必要信息，包括：

  • 使用的特征列表

  • 应用于每个特征的预处理技术

  • 使用的算法以及选择的超参数

  • 训练数据集

  • 用于评估训练模型的测试数据集（这对于版本比较阶段是必要的）

  • 评估指标

• 比较逻辑模型不同版本之间的性能。要决定部署哪个逻辑模型版本，必须对它们（候选模型和已部署模型）在相同数据集上进行评估。

选择评估数据集至关重要。如果有足够的新标记数据可以可靠地评估模型的性能，那么这是首选，因为它最接近我们预期在生产环境中接收到的数据。否则，我们可以使用已部署模型的原始测试数据集。假设数据没有漂移，这给我们提供了一个关于候选模型性能与原始模型比较的具体想法。

在确定最佳候选模型之后，工作还没有结束。实际上，模型的离线和在线表现经常存在显著差异。因此，将测试环境转移到生产环境至关重要。这种在线评估能够最真实地反映候选模型在面对真实数据时的表现。

在线评估

从业务角度看，生产环境中的模型在线评估至关重要，但从技术角度来看可能具有挑战性。在线评估主要有两种模式：

• 冠军/挑战者（又称影子测试），其中候选模型跟随已部署模型并对相同的实时请求进行评分

• A/B 测试，其中候选模型评分部分实时请求，而已部署的模型评分其他请求

两种情况都需要基本事实支持，因此评估时间肯定比预测与基本事实之间的时间差要长。此外，如果可能进行影子测试，应优先使用它而不是 A/B 测试，因为它更简单理解和设置，并能更快地检测出差异。

冠军/挑战者

冠军/挑战者涉及将一个或多个额外模型（挑战者）部署到生产环境中。这些模型接收并评分与活跃模型（冠军）相同的输入请求。然而，它们不会向系统返回任何响应或预测：这仍然是旧模型的任务。预测结果仅被记录以便进一步分析。这也是为什么这种方法被称为“影子测试”或“暗发布”。

此设置允许两件事情：

• 确认新模型的性能优于或至少不逊于旧模型。由于两个模型在相同数据上进行评分，因此可以直接比较它们在生产环境中的准确性。注意，这也可以通过使用新请求数据集上的新模型与冠军模型的离线比较来完成。

• 测量新模型如何处理现实负载。由于新模型可能具有新功能、新的预处理技术，甚至是新的算法，因此对请求的预测时间与原始模型不同，了解这种变化是非常重要的。当然，这是在线执行的主要优势。

这种部署方案的另一个优势是数据科学家或机器学习工程师向其他利益相关者展示了未来冠军模型的可见性：挑战者模型的结果不再局限于数据科学环境，而是向业务领导展示，这降低了切换到新模型的感知风险。

为了能够比较冠军和挑战者模型，必须为两者记录相同的信息，包括输入数据、输出数据、处理时间等。这意味着更新记录系统以便能够区分这两个数据源。

在清楚哪个模型比另一个更好之前，应部署多长时间？应部署足够长的时间，以便随机性引起的度量波动得以抑制，因为已经进行了足够的预测。可以通过图形方式评估这一点，检查度量估计是否不再波动，或者通过进行适当的统计检验（因为大多数指标是行分数的平均值，最常见的测试是配对样本 T 检验），该检验能够给出一个概率，即一个指标高于另一个指标的观察是否由这些随机波动引起。度量差异越大，确保差异显著所需的预测次数就越少。

根据使用案例和冠军/挑战者系统的实施方式，服务器性能可能是一个问题。如果同时调用两个内存密集型模型，它们可能会使系统变慢。这不仅会对用户体验产生负面影响，还会损坏关于模型运行情况的收集数据。

另一个关注点是与外部系统的通信。如果两个模型使用外部 API 来丰富其特性，这将导致向这些服务的请求数量加倍，从而使成本加倍。如果该 API 有一个缓存系统，那么第二个请求将比第一个请求处理得更快，这可能会在比较两个模型的总预测时间时产生偏差。需要注意的是，挑战者模型可能仅用于随机子集的传入请求，这将减轻负载，但增加了在得出结论之前所需的时间。

最后，在实施挑战者模型时，重要的是确保它不会对系统的行动产生任何影响。这意味着有两种情况：

• 当挑战者模型遇到意外问题并失败时，生产环境不会在响应时间方面出现任何中断或降级。

• 系统采取的行动仅依赖于冠军模型的预测，并且只发生一次。例如，在欺诈检测用例中，想象一下如果错误地将挑战者模型直接插入系统中，每笔交易会被收取两次—这是一个灾难性的情况。

通常情况下，需要花费一些精力在日志记录、监控和服务系统上，以确保生产环境正常运行，并且不受来自挑战者模型的任何问题的影响。

A/B 测试

A/B 测试（一种随机实验，测试两种变体 A 和 B）是网站优化中广泛使用的技术。对于 ML 模型，仅当无法使用冠军/挑战者时才应使用它。这可能发生在以下情况下：

• 对于两种模型，无法评估真实情况。例如，对于推荐引擎，预测会给出客户可能点击的商品列表，如果它们被呈现给客户。因此，无法确定如果没有呈现商品，客户是否会点击。在这种情况下，需要进行某种形式的 A/B 测试，其中一些客户将看到模型 A 的推荐，另一些客户将看到模型 B 的推荐。同样地，对于欺诈检测模型，因为需要大量工作来获取真实情况，可能无法对两个模型的正面预测进行评估；这将增加工作量太多，因为一些欺诈仅被一个模型检测到。因此，随机应用仅 B 模型到一小部分请求将使工作量保持恒定。

• 优化的目标仅间接与预测性能相关。想象一下基于 ML 模型的广告引擎，它预测用户是否会点击广告。现在想象一下，它是根据购买率来评估的，即用户是否购买了产品或服务。再次地，无法记录用户对两种不同模型的反应，因此在这种情况下，A/B 测试是唯一的方式。

有些书籍专门讨论 A/B 测试，因此本节只介绍其主要思想和简单步骤。与冠军/挑战者框架不同，使用 A/B 测试时，候选模型为某些请求返回预测，原始模型处理其他请求。测试期结束后，统计测试比较两个模型的性能，团队可以根据这些测试的统计显著性做出决策。

在 MLOps 环境中，需要考虑一些因素。这些考虑因素的详细介绍在 表 7-1 中提供。

表 7-1. MLOps 中进行 A/B 测试的考虑因素

阶段	MLOps 考虑因素
A/B 测试之前	确定一个明确的目标：需要优化的量化业务指标，如点击率。定义精确的人群：仔细选择测试的细分及分组策略，以确保群组之间没有偏见。（这就是被药物研究推广的实验设计或随机对照试验。）这可能是一个随机分割，也可能更复杂。例如，情况可能要求特定客户的所有请求由同一个模型处理。定义统计协议：使用统计测试比较结果指标，并接受或拒绝零假设。为了使结论更加健壮，团队需要事先定义所需的最小效果大小的样本量，即两个模型性能指标之间的最小差异。团队还必须固定测试持续时间（或者采用处理多个测试的方法）。请注意，与冠军/挑战者相似的样本大小将无法使用成对样本测试来检测有意义的差异，因为必须使用未配对样本测试。（通常情况下，不可能将每个由模型 B 评分的请求与模型 A 评分的请求配对，而冠军/挑战者则很简单。）
在 A/B 测试期间	很重要的一点是在测试时间结束之前不要停止实验，即使统计测试开始显示显著的指标差异。这种做法（也称为 p-hacking）由于挑选期望的结果而产生不可靠和有偏见的结果。
A/B 测试后	一旦测试时间结束，检查收集的数据确保质量良好。从这里开始，运行统计测试；如果指标差异在倾向于候选模型的统计学意义上显著，则可以用新版本替换原模型。

总结思考

普通软件被构建来满足规范。一旦应用部署，其完成目标的能力不会降低。相比之下，机器学习模型的目标是根据其在给定数据集上的性能统计性定义的。因此，当数据的统计特性发生变化时，它们的性能通常会变差。

除了普通软件维护需求（错误修正，发布升级等），必须仔细监控性能漂移。我们已经看到，基于实际情况的性能监控是基石，而漂移监控可以提供早期警告信号。在可能的漂移缓解措施中，主要的工作马是在新数据上重新训练，而模型修改则是一个选项。一旦新模型准备部署，可以通过阴影评分或作为第二选择的 A/B 测试验证其改进的性能。这使得证明新模型更好以提高系统性能成为可能。

¹ 在评估训练数据集和测试数据集之间的偏移时，特别是当测试数据集在训练数据集之后时，评估漂移是明智的。详细信息请参见“选择评估指标”。

第八章：模型治理

马克·特雷维尔

我们探讨了治理作为 第三章 中对企业施加的一组控制的概念。这些目标旨在确保企业履行其对所有利益相关者的责任，从股东和员工到公众和国家政府。这些责任包括财务、法律和道德责任，所有这些都以对公平的渴望为基础。

本章深入探讨了这些主题，从它们的重要性到组织如何将它们作为其 MLOps 策略的一部分进行整合。

谁来决定组织需要什么样的治理？

国家法规是社会公平框架的重要组成部分。但是，这些法规需要相当长的时间才能达成一致并实施；它们始终反映了对公平性稍有历史性的理解及其面临的挑战。就像机器学习模型一样，过去并不能总是预见未来发展中的问题。

大多数企业从治理中想要的是保护股东投资，并确保适当的投资回报率，现在和未来都是如此。这意味着企业必须有效、有利可图且可持续地运营。股东需要清楚地看到顾客、员工和监管机构满意，并希望确认已经采取适当的措施来检测和管理可能在未来发生的任何困难。

当然，这些都不是新闻，也不是仅限于 MLOps。ML 的不同之处在于，它是一种新的并且经常不透明的技术，带来许多风险，但却正在迅速嵌入影响我们生活方方面面的决策系统中。机器学习系统通过大量数据创造自己的统计驱动决策过程，这些过程通常极其难以理解，数据被认为代表现实世界。很容易看出会出现哪些问题！

或许对 ML 治理方向影响最大的是公众舆论，它比正式法规演变得快得多。它不遵循任何正式的程序或礼仪。它无需基于事实或理性。公众舆论决定人们购买什么产品，投资到哪里，以及政府制定哪些规则和法规。公众舆论决定什么是公平的，什么不是。

例如，开发转基因作物的农业生物技术公司在上世纪九十年代深切感受到了公众舆论的力量。在关于是否存在健康风险的争论中，欧洲的公众舆论反对基因改造，许多欧洲国家禁止了这些作物。与机器学习的类似之处显而易见：机器学习为所有人提供了好处，但也带来了需要管理的风险，如果公众不信任它，这些好处将无法充分实现。

公众需要被保证机器学习是公平的。什么被认为是“公平”的并未在规则书中定义，也不是固定的；它会根据事件而波动，并且在世界各地不会始终相同。目前，公众对机器学习的看法处于平衡状态。大多数人喜欢得到合理定位的广告，他们喜欢汽车能够读取限速标志，而改进欺诈检测最终也为他们节省了金钱。

但也有一些广为人知的丑闻动摇了公众对这项技术的接受。例如，Facebook 和剑桥分析公司的事件，这两家公司利用机器学习的力量在社交媒体上操纵公众舆论，震惊了世界。这看起来像是带有明确恶意意图的机器学习。同样令人担忧的是完全无意造成的伤害，例如在刑事评估系统和招聘工具中，机器学习的黑匣子判决被证明在种族或性别等标准上存在不可接受和非法的偏见。

如果企业和政府希望获得机器学习的好处，他们必须保护公众对其的信任，并积极应对相关风险。对于企业而言，这意味着需要建立强大的 MLOps 流程治理。他们必须评估风险，确定自己的公平价值观，并实施必要的流程来管理这些风险。其中大部分工作仅仅是关于良好的管理，并且专注于减轻机器学习固有的风险，涉及数据溯源、透明度、偏见、性能管理和可复现性等话题。

将治理与风险水平匹配

治理并非免费午餐；它需要投入精力、纪律和时间。

从业务利益相关者的角度来看，治理很可能会减慢新模型的交付速度，这可能会给企业带来成本。对于数据科学家而言，这可能看起来是许多官僚主义，侵蚀了他们完成任务的能力。相比之下，负责管理风险和负责部署的 DevOps 团队会主张，应该强制执行全面的严格治理。

负责 MLOps 的人必须管理不同用户配置文件之间固有的紧张关系，找到在高效完成工作与全面保护各种可能威胁之间的平衡。通过评估每个项目的具体风险，并将治理过程与该风险水平匹配，可以找到这种平衡。在评估风险时，需要考虑几个维度，包括：

• 模型的受众

• 模型寿命及其结果

• 结果的影响

这种评估不仅应确定所应用的治理措施，还应推动完整的 MLOps 开发和部署工具链。

例如，自助式分析（SSA）项目（只面向小范围内部观众，并且通常由业务分析师构建）需要相对轻量级的治理。相反，部署到公众网站并影响人们生活或公司财务决策的模型则需要非常彻底的流程。此流程将考虑业务选择的 KPI 类型、所需可解释性的模型构建算法类型、使用的编码工具、文档和可重复性的水平、自动化测试的水平、硬件平台的弹性以及实施的监控类型。

但业务风险并非总是如此清晰。一个做出具有长期影响决策的 SSA 项目也可能存在高风险，并且可以证明需要更强的治理措施。因此，跨团队需要深思熟虑、定期审查的 MLOps 风险评估策略（参见图 8-1 关于项目重要性和操作化方法的详细说明）。

图 8-1. 根据项目的重要性选择适当的操作化模型和 MLOps 特性

当前推动 MLOps 治理的法规

当今世界范围内针对机器学习和人工智能的具体法规很少。然而，许多现有法规对机器学习治理产生了重大影响。这些法规有两种形式：

• 行业特定的法规。这在金融和制药领域尤为重要。

• 广谱法规，特别是数据隐私方面的处理。

以下几节概述了一些最相关的法规。它们与 MLOps 治理挑战的相关性显著，并且这些法规很好地指示了行业广泛需要建立和维护对机器学习信任的治理措施。

即使对于那些没有具体法规的行业工作人员，以下几个部分可以简要说明，无论行业如何，全球组织未来可能在机器学习控制的具体性水平上面临的问题。

美国的药品监管：GxP

GxP 是由美国食品药品监督管理局（FDA）制定的一系列质量指南（例如良好临床实践指南，简称 GCP 指南）和法规，旨在确保生物和制药产品的安全。

GxP 指南侧重于：

• 可追溯性，即重新创建药物或医疗设备开发历史的能力。

• 账户责任，即谁在何时为药物开发做出了何种贡献。

• 数据完整性（DI），即开发和测试中使用的数据的可靠性。这基于 ALCOA 原则：可归属性、易读性、时效性、原始性和准确性，考虑因素包括风险识别和缓解策略。

金融模型风险管理规定。

在金融中，模型风险是在决定可交易资产的模型证明不准确时产生损失的风险。这些模型（如 Black–Scholes 模型）早在机器学习出现之前就已存在。

模型风险管理（MRM）法规是由于特殊事件（如金融崩溃）的影响经验推动的，如果遭受严重损失可能对公众和更广泛的经济造成损害。自 2007-2008 年金融危机以来，已经引入了大量额外的法规以强制执行良好的 MRM 实践（参见图 8-2）。

英国审慎监管局（PRA）的规定，例如，为良好的 MRM 定义了四个原则：

模型定义。

定义模型并在库存中记录这些模型。

风险治理。

建立模型风险治理框架、政策、流程和控制。

生命周期管理。

创建健壮的模型开发、实施和使用流程。

有效挑战。

进行适当的模型验证和独立审查。

图 8-2。模型风险管理（MRM）法规的历史。

GDPR 和 CCPA 数据隐私法规。

欧盟普通数据保护条例（GDPR）于 2018 年首次实施，为从居住在欧盟的个人收集和处理个人信息设定了指导方针。然而，它是针对互联网时代而制定的，因此实际上适用于任何地方的欧盟访客，无论该网站位于何处。由于很少有网站希望排除欧盟访客，全球各地的网站都被迫满足这些要求，使 GDPR 成为数据保护的事实标准。该法规旨在让人们控制 IT 系统收集的个人数据，包括以下权利：

• 被告知收集或处理的数据。

• 访问收集的数据并了解其处理方式。

• 纠正不准确的数据。

• 被遗忘（即数据被移除）。

• 限制个人数据的处理。

• 获取收集的数据并在其他地方重新使用。

• 反对自动化决策。

加利福尼亚消费者隐私法（CCPA）在受保护对象和内容方面与 GDPR 非常相似，尽管其范围、地域覆盖和财务处罚都更为有限。

AI 特定法规的新浪潮。

全球范围内，针对 AI 应用（因此也包括所有 ML 应用）的新一波法规和指南正在兴起。欧盟在制定建立可信 AI 框架方面处于领先地位。

在人工智能白皮书中，欧盟强调 AI 对各行各业的潜在益处。同样，它指出围绕 AI 滥用的丑闻以及对 AI 潜力进步可能带来危险的警告并没有被忽视。欧盟认为基于其基本价值的监管框架“将使其能够在数据经济及其应用方面成为全球创新领导者。”

欧盟确定了 AI 应用必须遵守的七项关键要求，以被视为可信任：

• 人类代理和监督

• 技术鲁棒性和安全性

• 隐私和数据治理

• 透明度

• 多样性、非歧视和公平性

• 社会和环境福祉

• 问责制

欧盟的方法并非一刀切：它主要影响特定的高风险行业，包括医疗保健、交通运输、能源和部分公共部门。其他行业预计可以选择是否遵守这些规定。

就像 GDPR 一样，欧盟的方法可能会对全球产生影响。许多大型组织可能会选择加入，考虑到公众对 AI 使用的信任对其业务的重要性。即使不选择加入，这一框架也可能建立起一种 AI 治理思维，并影响其处理方式。

表格 8-1 概述了全球 AI 治理倡议的一些状态。尽管各个国家的规定程度有所不同，但都在明显类似的路线上前进，反映了其传统上不同的监管方法。

表格 8-1. 全球 AI 治理倡议的状态

地区和组织	阶段	焦点	即将到来
经合组织	指导

• 42 个签署国

• AI 可信任管理的五大原则：包容性增长、以人为本和公平性、透明度和可解释性、鲁棒性以及问责制度

• 国家政策的建议

欧盟

• 对高风险活动（X 部门影响）具有约束力，对其他人可选择性，有可能标记

• 特别针对模型的公平性、鲁棒性和可审计性，结合政策和控制措施，整合环境和社会影响的强烈伦理考量

|

• 指令将于 2020 年底/2021 年初出台

• 将翻译为国家制度

|

新加坡	指导

• 正面、非制裁性的方法，重点放在在组织级别实施 AI 治理的实际步骤上

• 最佳实践中心，在经济论坛层面支持 AI 治理工作

|

• 到 2020 年底/2021 年初实施的法规

|

美国	指导、沟通和监管

• 联邦指导方针发布以为行业特定指导方针或法规铺平道路

• 着眼于公众信任和公平性；没有更广泛的道德考虑

英国

澳大利亚

负责任 AI 的出现

随着全球数据科学、机器学习和人工智能的普及，AI 思想家之间形成了一种松散的共识。这种共识的最常见表述是负责任 AI：即开发机器学习系统应对负责、可持续和可管理的理念。简而言之，AI 系统应该按预期运行，随时间可靠，受到良好控制并可审计。

负责任 AI 没有严格的定义或用于界定其术语，但人们对其总体考虑和大部分交付需求有共识（见表格 8-2 的组成部分）。尽管没有单一机构主导这一运动，负责任 AI 已经在集体思维中产生了显著影响，特别是在欧盟可信 AI 监管者中。

表格 8-2. 负责任 AI 的组成部分，这是 MLOps 中越来越关键的一部分

故意性	账户管理

| 必须具备：

• 确保模型设计和行为与其目的一致

• 确保用于 AI 项目的数据来自符合规定且无偏见的来源，同时通过协作方法确保对潜在模型偏见进行多重检查和平衡

• 故意性还包括可解释性，这意味着 AI 系统的结果应该能够被人类解释（理想情况下不仅仅是创建系统的人类）

| 必须具备：

• 集中控制、管理企业 AI 工作的能力以及审计（不允许影子 IT！）

• 综合考虑哪些团队正在使用哪些数据、如何使用以及使用哪些模型

• 信任数据可靠性，按照法规收集数据，并集中理解哪些模型用于哪些业务流程。这与可追溯性密切相关——一旦出现问题，能否轻松找到问题发生在管道的哪个环节？

|

以人为中心的方法
向人们提供工具和培训，使其能意识到并执行这两个组件

负责任 AI 的关键要素

负责任 AI 关乎数据从业者的责任，而非 AI 本身是否负责：这是一个非常重要的区别。另一个重要区别是，根据 Dataiku 的 Kurt Muemel 所说，“这并不一定是有意的伤害，而是意外的伤害。”

本节介绍了负责任 AI 思维中的五个关键要素——数据、偏见、包容性、规模化模型管理和治理，以及每个要素的 MLOps 考虑。

要素 1：数据

对数据的依赖是机器学习和传统软件开发之间的基本区别。使用的数据质量将对模型的准确性产生最大影响。一些现实考虑如下：

• 证据来源至关重要。了解数据的收集方式及其使用过程。

• 把数据从桌面上移出来。数据必须是可管理的、安全的，并且可以追溯的。个人数据必须严格管理。

• 随时间推移数据的质量：一致性、完整性和所有权。

• 垃圾进，垃圾出。偏倚的输入数据很容易且无意中发生。

元素 2：偏差

机器学习预测建模是关于建立一个系统来识别和利用现实世界中的趋势。某些类型的汽车，由某些类型的人驾驶，在某些地方更可能对保险公司造成更高的费用。但是，匹配模式是否总是被认为是道德的？这种模式匹配何时是成比例的，何时是不公平的？

确定什么是公平的并不清晰。甚至使用流失模型为更有可能离开的客户提供折扣可能被认为是不公平的，因为冬眠客户会为相同的产品支付更多。法规是开始寻找的地方，但正如已经讨论过的那样，观点不是普遍的，也不是固定的。即使对工作向妇女学校有偏见的招聘系统的开发人员了解到了模型如何适应忽略“女性”等词语，他们发现即使简历中的语气也反映了作者的性别，并导致对女性的不良偏见。解决这些偏见对即将建立的机器学习模型有深远的影响（参见“负责任人工智能对建模的影响”以获取详细示例）。

退一步看，这些偏差问题并不新鲜；例如，招聘歧视一直都是一个问题。新的是，由于 IT 革命的推动，用于评估偏差的数据更加丰富。此外，由于机器学习决策的自动化，可以在不经过主观决策者的筛选的情况下改变行为。

关键是偏差不仅仅是统计上的。应该在治理框架中整合偏差检查，以便尽早发现问题，因为这些问题确实有可能使数据科学和机器学习项目偏离轨道。

并非一切都是坏消息：有许多潜在的统计偏差来源（即世界上的实际情况），可以由数据科学家解决：

• 偏差是否编码到训练数据中？原材料是否存在偏差？数据准备、抽样或拆分是否引入了偏差？

• 问题是否正确地框定了？

• • 所有子群体是否都有正确的目标？注意许多变量可能高度相关。
• • 反馈循环数据是否因 UI 中选择顺序等因素而存在偏见？

• 防止偏见引发的问题非常复杂，目前大部分焦点在于在其造成伤害之前检测偏见。机器学习可解释性是偏见检测的主要支柱，通过一套技术工具分析模型，带来对机器学习模型的理解，包括：

• • 预测理解：为什么模型做出了特定的预测？
• • 子群体分析：子群体中是否存在偏见？
• • 依赖理解：个体特征做出了什么贡献？

• 在开发过程中利用尽可能广泛的人类专业知识来应对偏见是一种非常不同但互补的方法。这是责任人工智能中包容性理念的一个方面。

- 元素 3：包容性

人在循环中（HITL）方法旨在将人类智能的优势与机器智能的优势结合起来。机器擅长从大量数据集中做出智能决策，而人类在信息较少时做出决策更为优秀。人类判断尤其有效，可用于道德和有害相关的判断。

• 该概念可以应用于模型在生产中的使用方式，同样重要的是模型构建的方式。例如，通过签署流程来正式化 MLOps 中的人类责任可能很简单，但效果非常显著。

包容性原则将人工智能与人类协作的理念推进到更深的层次：尽可能将多样化的人类专业知识引入机器学习生命周期，可以减少严重盲点和遗漏的风险。建造机器学习的群体越不包容，风险就越大。

• 业务分析师、主题专家、数据科学家、数据工程师、风险经理和技术架构师的观点都不同。所有这些观点共同为管理模型开发和部署带来更大的清晰度，远胜于依赖任何单一用户档案，并有效促进这些用户档案的协作是降低风险并提高任何组织中 MLOps 表现的关键因素。参见第二章，以了解不同档案协作改善 MLOps 性能的明确示例。

• 完全的包容性甚至可以通过焦点群体测试将消费者引入到过程中。包容性的目标是将适当的人类专业知识引入到过程中，不论其来源。将机器学习交给数据科学家并不是管理风险的答案。

- 元素 4：规模化模型管理

当在生产中仅有少数模型时，管理与机器学习相关的风险可以很大程度上手动化。但随着部署量的增加，挑战迅速增加。以下是在规模化机器学习管理时需要考虑的一些关键因素：

• 可扩展的模型生命周期需要在很大程度上自动化和简化。

• 错误，例如数据集的一个子集中的错误，将迅速广泛地传播出去。

• 现有的软件工程技术可以帮助规模化机器学习。

• 决策必须能够解释、可审计和可追溯。

• 可复现性是理解出了什么问题、谁或什么负责以及谁应确保纠正的关键。

• 模型性能会随时间而降低：监控、漂移管理、重新训练和重建必须纳入流程。

• 技术正在迅速发展；需要一种整合新技术的方法。

元素 5：治理

负责任的 AI 将强大的治理视为实现公平性和可信度的关键。这种方法建立在传统治理技术的基础上：

• 在流程开始时确定意图

• 正式引入人类参与

• 明确确定责任人（图 8-3）

• 整合定义和构建流程的目标

• 建立和传达流程和规则

• 定义可测量的指标并监控偏差

• 将多个检查项集成到与总体目标对齐的 MLOps 流程中。

• 通过教育赋能人们

• 教导构建者以及决策者如何预防伤害

因此，治理既是 MLOps 倡议的基础，也是其粘合剂。然而，重要的是要认识到，它超越了传统数据治理的边界。

图 8-3. 组织不同层级对负责任 AI 过程不同部分的负责人的表示

MLOps 治理模板

在探讨通过法规措施和负责任 AI 运动应对 MLOps 治理的关键主题后，现在是时候制定如何实施稳健的 MLOps 治理框架的地图了。

在企业中不存在一刀切的解决方案，企业内不同的用例需要不同层次的管理，但所概述的逐步方法可以应用于任何组织，以指导实施过程。

这个过程有八个步骤：

1. 理解和分类分析用例。

2. 建立伦理立场。

3. 确定责任。

4. 确定治理政策。

5. 将政策整合到 MLOps 流程中。

6. 选择集中治理管理的工具。

7. 参与并教育。

8. 监控和优化。

本节将详细介绍每个步骤，包括简单的定义以及实施步骤的具体方法。

第一步：理解和分类分析用例

此步骤涉及定义分析使用情况的不同类别及随后每个类别的治理需求。

考虑以下问题的答案，用于代表性的分析使用情况的横截面。识别不同使用情况的关键区别特征，并对这些特征进行分类。在合适的情况下合并类别。通常，每个使用情况都需要与多个类别关联，以完整描述它。

• 每种使用情况受哪些法规约束，以及其影响是什么？行业特定法规，区域性法规，个人身份信息保护？

• 谁消费模型的结果？公众？内部的众多用户之一？

• 部署模型的可用性要求是什么？24/7 实时评分，定期批处理评分，自助运行（自助分析）？

• 任何错误和缺陷的影响是什么？法律、财务、个人、公众信任？

• 发布的节奏和紧急性如何？

• 模型的寿命和其决策影响的寿命是多少？

• 模型质量衰退的可能速率是多少？

• 对解释性和透明性有何需求？

第二步：确立伦理立场

我们确定公平和伦理考虑是有效治理的重要动因，企业在其伦理立场上有选择的权利，并且这影响公众的认知和信任。企业采取的立场是在实施成本和公众认知之间的权衡。负责任的立场即使在长期回报可能为正面的情况下，也很少是零短期财务成本。

任何 MLOps 治理框架都需要反映公司的伦理立场。虽然立场通常影响模型的行为和方式，但 MLOps 治理流程需要确保部署的模型符合选择的伦理立场。这种立场很可能广泛影响治理流程，包括选择和验证新模型以及意外伤害的可接受概率。

考虑以下伦理问题：

• 社会福祉的哪些方面至关重要？例如，平等、隐私、人权与尊严、就业、民主、偏见？

• 是否应考虑对人类心理的潜在影响？例如，人与人或人与 AI 的关系，欺骗，操纵，剥削

• 是否需要对财务影响的立场？例如，市场操纵

• 决策制定应该有多透明？

• 企业希望对基于 AI 的错误承担何种责任？

第三步：确定责任

确定负责监督 MLOps 治理的人员群体及其角色。

• 全面动员整个组织，跨部门，从管理层的顶层到底层。

• 彼得·德鲁克著名的一句话“文化吞噬战略的早餐”强调了广泛参与和共享信念的力量。

• 避免创建全新的治理结构。看看已有的结构，并尝试将 MLOps 治理纳入其中。

• 获得高级管理层对治理过程的赞助。

• 以责任的不同层次来思考：

  • 战略：明确愿景

  • 战术：实施和执行愿景

  • 运营：日常执行

• 考虑为完整的 MLOps 流程建立 RACI 矩阵（参见 图 8-4）。RACI 代表负责、负责、咨询、知情，突出了整个 MLOps 流程中不同利益相关者的角色。很可能您在此阶段创建的任何矩阵都需要在流程的后续阶段进行完善。

图 8-4. MLOps 典型 RACI 矩阵

第四步：确定治理政策

现在已经确定了治理的范围和目标，并且吸引了负责的治理领导的参与，是时候考虑 MLOps 流程的核心政策了。这不是一项小任务，不太可能在一次迭代中完成。专注于建立政策的广泛领域，并接受经验将有助于进一步完善细节。

考虑从第一步开始的各项计划分类。团队或组织在每种情况下需要哪些治理措施？

在关注风险或法规合规性较少的计划中，可能适合采用更轻量级、更廉价的措施。例如，“假如”计算以确定不同类型的飞行餐食量并没有太大影响——毕竟，即使在引入机器学习之前，食物的混合也从未合适过。即使是这样一个看似微不足道的用例，可能也存在伦理影响，因为餐食选择可能与宗教或性别相关，这在许多国家都是受保护的属性。另一方面，计算飞机燃料加注量的影响则具有更大的风险。

治理考虑可以广泛分为 表 8-3 中的各个标题下。针对每个类别，都有一系列要考虑的措施。

表 8-3. MLOps 治理考虑

治理考虑	示例措施
可复现性和可追溯性	完整的虚拟机和数据快照，以便精确和快速地重新实例化模型， 或 能够重新创建环境并使用数据样本重新训练， 或 仅记录部署模型的指标？
审计与文档	开发过程中所有更改的完整日志，包括运行的实验和选择原因 或 仅部署模型的自动化文档 或 完全没有文档
人工参与确认	每次环境移动（开发、QA、预生产、生产）的多重确认
预生产验证	通过手工编码模型并比较结果 或 在类似生产环境中重新创建完整自动化测试管道，包括广泛的单元测试和端到端测试 或 对数据库、软件版本和命名标准进行自动检查
透明性和可解释性	使用手工编码的决策树以达到最大可解释性 或 使用回归算法的可解释性工具如 Shapely 值 或 接受如神经网络这样的不透明算法
偏见和伤害测试	使用多种工具和攻击向量进行“红队”对抗手动测试 或 对特定子人群进行自动偏见检查
生产部署模式	将容器化部署到弹性可扩展的高可用性多节点配置中，并在部署前进行自动化的压力/负载测试 或 单个生产服务器
生产监控	实时错误警报，动态多臂赌博模型平衡，自动化夜间重新训练，模型评估和重新部署 或 每周输入漂移监控和手动重新训练 或 基本基础设施警报，无监控，无基于反馈的重新训练
数据质量和合规性	包括匿名化的 PII 考虑 和 对列级别的血统进行记录和审查，以了解数据的来源、质量和适当性 和 自动化数据质量检查以检测异常

最终确定的治理政策应包括：

• 确定任何分析倡议分类的流程。这可以作为一个检查表或风险评估应用来实施。

• 倡议分类与治理考虑之间的矩阵，每个单元格标识所需的措施。

第五步：将政策整合到 MLOps 流程中

一旦确定了不同倡议类别的治理政策，需要将实施这些政策的措施纳入 MLOps 流程，并指定负责执行这些措施的责任人。

尽管大多数企业都有现有的 MLOps 流程，但很可能这些流程并没有明确定义，而是根据个体需求演变而来。现在是重新审视、增强和记录流程的时候了。只有清晰地沟通并获得每个利益相关者组的认可，治理流程才能成功采纳。

通过采访负责人了解现有流程中的所有步骤。在没有现有正式流程的情况下，这通常比听起来更难，因为流程步骤通常没有明确定义，所有权也不明确。

将政策驱动的治理措施映射到流程理解中，可以快速识别流程中的问题。一个企业内可能存在各种不同风格的项目和治理需求，例如：

• 一次性自助分析

• 内部消费模型

• 公共网站中嵌入的模型

• 部署到物联网设备的模型

在这些情况下，某些流程之间的差异可能如此之大，最好考虑几个并行流程。最终，每个用例的每个治理措施都应与一个流程步骤和一个最终负责的团队相关联，如此所示：

流程步骤	示例活动和治理考虑事项
业务范围界定	记录目标，定义关键绩效指标，并记录签字：用于内部治理考虑
构思	数据发现：数据质量和监管合规性约束算法选择：受可解释性要求影响
开发	数据准备：考虑个人身份信息合规性、法律区域范围分离，避免输入偏差模型开发：考虑模型可复现性和可审计性模型测试和验证：偏见和伤害测试，可解释性
预生产	使用生产数据验证性能/偏差生产准备测试：验证可扩展性
部署	部署策略：由操作级别驱动的部署验证测试在生产中使用阴影挑战者或 A/B 测试技术进行验证
监控和反馈	性能指标和警报预测日志分析以检测输入漂移并进行警报

第六步：选择集中治理管理工具

MLOps 治理流程影响整个 ML 生命周期以及组织中的许多团队。每个步骤都需要执行特定顺序的操作和检查。模型开发和治理活动执行的可追溯性是一个复杂的挑战。

大多数组织仍然将流程管理看作是“纸质表单”的思维方式，即填写、流转、签署和归档表单。表单可能是文本文档，通过电子邮件流转，并以电子形式归档，但纸质的限制仍然存在。难以追踪进展，关联文物，同时审查多个项目，提示行动，并提醒团队履行责任。事件的完整记录通常分布在多个系统中，并由各个团队拥有，从而使得有效概述分析项目变得几乎不可能。

尽管团队始终会有特定于其角色的工具，但如果从一个系统管理和跟踪整体流程，那么 MLOps 治理将更加有效。这个系统应该：

• 集中定义每类分析用例的治理流程流程

• 启用对完整治理流程的跟踪和执行

• 提供一个单一的参考点，用于发现分析项目

• 促进团队之间的协作，特别是工作转移之间的协作

• 与用于项目执行的现有工具集成

当前的工作流程、项目管理和 MLOps 工具只能部分支持这些目标。新的 ML 治理工具类别正在兴起，直接更全面地支持这一需求。这些新工具专注于 ML 治理的具体挑战，包括：

• 查看所有模型状态的单一视图（也称为模型注册表）。

• 配备签署机制的流程门，以便轻松追溯决策历史。

• 能够跟踪模型的所有版本。

• 能够链接到工件存储、指标快照和文档。

• 能够为每类分析用例专门定制流程。

• 能够集成来自生产系统的健康监控，并跟踪模型在原始业务 KPIs 上的表现。

第七步：参与和教育

没有参与监督和执行治理流程的团队的参与和培训计划，其部分采纳的可能性很小。必须传达 MLOps 治理对业务的重要性，以及每个团队贡献的必要性。在此基础上建立理解，每个个人都需要学习他们必须何时以及如何做。这项工作将需要大量文档编制、培训，尤其是时间。

首先，向业务通信 MLOps 治理的广泛愿景。强调现状的危险，概述一个流程，并详细说明其如何适应各种用例范围。

直接与每个涉及的团队合作，并与他们直接建立培训计划。不要害怕利用他们的经验来不仅塑造培训，还塑造他们治理责任的详细实施。结果将更强的认同感和更有效的治理。

第八步：监控和优化

新实施的治理是否有效？是否实施了规定的步骤，并是否达到了目标？如果情况不佳应采取哪些措施？如何衡量今天的现实与业务需求的差距？

衡量成功需要指标和检查。需要有人负责监控，并找出解决问题的方法。治理流程及其实施方式将根据经验教训和不断变化的要求（包括本章前文讨论的不断发展的监管要求）进行定期改进。

过程成功的一个重要因素将是负责过程中各个措施的个人的勤奋程度，激励他们至关重要。

监控治理流程始于对关键绩效指标和目标的清晰理解——治理的关键绩效指标。这些指标旨在衡量流程是否得以执行以及是否实现了目标。监控和审计可能会耗费时间，因此尽可能自动化指标，并鼓励各个团队负责监控与其职责领域相关的指标。

让人们执行那些看似对做工作的人没有具体好处的任务是很难的。解决这个问题的一种流行策略是引入游戏化。这不是要让一切都像电子游戏一样，而是为人们执行那些主要由其他人受益的任务引入激励措施。

尝试通过简单的方式将治理流程引入游戏化：广泛发布 KPI 结果是最简单的起点。仅仅能够看到目标得到实现本身就是一种满足感和动力的来源。无论是团队级别还是个人级别的排行榜，都可以增加一些建设性的竞争元素。例如，那些工作始终能够一次通过合规检查或者按时完成任务的人，应该能感觉到他们的努力是可见的。

然而，过度的竞争可能会造成混乱和缺乏动力。必须保持平衡，最好的方法是逐步增加游戏化元素。从最少竞争导向开始，逐步添加新元素，评估其有效性后再添加下一个。

监控治理环境的变化至关重要。这可能涉及法规，也可能涉及公众意见。负责战略愿景的人必须继续监控，并确保有评估潜在变化的流程。

最后，如果不采取措施解决问题，对流程的所有监控都是徒劳的。建立一个关于协商变更并实施变更的流程。这可能会导致重新审视政策、流程、工具、责任、教育和监控！必须进行迭代和改进，但效率与效果之间的平衡难以找到；许多教训只能通过艰难的方式学到。建立一种文化，让人们把迭代和改进视为成功流程的衡量标准，而不是失败的流程。

总结思考

不可能将 MLOps 与其治理分开。要成功管理模型生命周期、减轻风险并在规模上提供价值，没有治理是不可能的。治理影响一切，从企业如何合理利用 ML 到可用的数据和算法，再到运营化、监控和再培训的风格。

大规模 MLOps 处于初期阶段。很少有企业在进行，甚至更少有企业做得很好。尽管治理是提高 MLOps 效果的关键，但今天直接解决这一挑战的工具很少，只有零散的建议。

ML 的公众信任面临风险。即使是欧盟这样行动缓慢的组织也意识到了这一点。如果失去了信任，那么从 ML 中获得的许多好处也将丧失。尽管正在准备额外的立法，但即使没有这些，企业也需要担心由不慎造成的有害模型可能对其公众形象造成的潜在损害。

当计划扩展 MLOps 时，请从治理开始，并利用它来推动流程。不要等到最后再加上它。深思熟虑政策；考虑使用工具来提供集中视图；在整个组织中进行参与。这需要时间和迭代，但最终企业将能够回顾并为认真对待其责任而感到自豪。

第三部分： MLOps：现实世界的例子

第九章：实践中的 MLOps：消费者信贷风险管理

在本书的最后几章中，我们探讨了三个 MLOps 在实践中可能的例子。我们明确选择了这三个例子，因为它们代表了机器学习的根本不同的用例，并展示了 MLOps 方法论如何根据业务需求和其机器学习模型生命周期实践的不同而不同。

背景：业务用例

当消费者申请贷款时，信贷机构必须决定是否批准贷款。根据具体情况，流程中的自动化程度可能有所不同。然而，决策很可能是基于估计贷款是否按预期偿还的分数而作出的。

分数通常在流程的不同阶段被常规使用：

• 在预筛选阶段，使用少量特征计算的分数允许机构快速丢弃一些申请。

• 在承保阶段，使用所有必要信息计算的分数为决策提供了更精确的依据。

• 在承保阶段，分数可以用来评估贷款组合中的风险。

几十年来，分析方法已被用来计算这些概率。例如，FICO 分数自 1995 年起在美国被广泛使用。考虑到它们直接影响机构的收入和客户的生活，这些预测模型一直受到严格审视。因此，流程、方法和技能已经被正式纳入高度监管的环境中，以确保模型的可持续性表现。

无论模型是基于专家制定的规则、传统统计模型，还是更近期的机器学习算法，它们都必须遵守类似的法规。因此，消费者信贷风险管理可以被视为 MLOps 的先驱：可以基于此用例分析与其他用例及最佳实践的类似之处。

在做出信贷决策时，通常可以获取客户历史和当前情况的信息。客户持有多少信贷？客户是否曾经未能偿还贷款（在信贷行话中，客户是否有逾期情况）？在一些国家，称为信用局的组织收集这些信息，并直接或通过分数的形式向债权人提供。

被预测的目标定义更加复杂。在信用风险建模中，顾客未如预期般偿还被视为“坏”结果。理论上，应该等到完全偿还才确定“好”结果，并等到损失核销确定“坏”结果。然而，获取这些最终数据可能需要很长时间，并且等待它们可能会阻碍对变化条件的反应。因此，通常会根据各种指标进行权衡，以在损失确凿之前宣布“坏”结果。

模型开发

历史上，信用风险建模基于一套规则（在现代机器学习术语中称为“手动特征工程”）和逻辑回归的混合。专家知识对于创建一个良好的模型至关重要。建立适应性客户分割以及研究每个变量及其之间的相互影响需要大量的时间和精力。结合像两阶段模型与偏移、基于 Tweedie 分布的高级广义线性模型或单调性约束等先进技术，以及金融风险管理技术，这使得该领域成为精算师的乐园。

梯度提升算法如 XGBoost 已经降低了构建良好模型的成本。然而，由于黑箱效应，验证它们变得更加复杂：很难感受到这些模型无论输入什么数据都能给出合理的结果。尽管如此，信用风险建模者已经学会使用和验证这些新型模型。他们已经开发了基于个体解释（如 Shapley 值）的新验证方法，以建立对模型的信任，这是 MLOps 的关键组成部分，正如我们在本书中所探讨的。

模型偏差考虑

模型构建者还必须考虑选择偏差，因为该模型不可避免地用于拒绝申请者。因此，贷款授予的人群并不代表申请人群。

通过在先前模型版本选择的人群上训练模型版本，数据科学家可能会使模型无法准确预测被拒绝的人群，因为这些人群在训练数据集中没有被充分代表，而这正是模型期望的情况。这种效应被称为樱桃拣选。因此，必须使用特殊方法，如基于申请人群的重新加权或基于外部数据校准模型。

用于风险评估而不仅仅是决定贷款授予的模型必须产生概率，而不仅仅是是/否结果。通常情况下，预测模型直接生成的概率并不准确。如果数据科学家应用阈值处理以获取二元分类，这不是问题，但他们通常需要一个称为校准的单调转换来恢复基于历史数据评估的“真实”概率。

对于这种用例，模型验证通常包括：

• 在训练数据集之后（或在某些情况下，甚至在之前），在样本外数据集上测试其性能。

• 不仅对整体性能进行调查，还对亚群体进行调查。亚群体通常基于收入进行客户细分，并随着负责任 AI 的兴起，根据当地法规的保护属性进行其他分段变量的分析，如性别或任何受保护属性。不这样做可能会导致严重的损害，就像苹果在 2019 年学到的那样，当其信用卡据称对申请信贷的女性“存在性别歧视”。

准备生产环境

鉴于信用风险模型的重大影响，其验证过程涉及对生命周期建模部分的重要工作，并包括以下内容的完整文档：

• 使用的数据

• 建模和构建模型所做的假设

• 验证方法和验证结果

• 监控方法

在这种情况下，监控方法是双重的：数据漂移和性能漂移。由于预测与获得实际结果之间的延迟较长（通常为贷款期限加上几个月以考虑逾期付款），仅监控模型性能是不够的：还必须仔细监控数据漂移。

例如，如果发生经济衰退或商业政策改变，申请人群体可能会发生变化，使得模型的性能无法在没有进一步验证的情况下得到保证。数据漂移通常通过客户细分进行，使用通用统计指标来测量概率分布之间的距离（如 Kolmogorov-Smirnov 或 Wasserstein 距离），以及金融服务专用的指标，如人口稳定指数和特征稳定指数来进行监测。性能漂移也经常使用通用指标（AUC）或特定指标（Kolmogorov-Smirnov、Gini） 对亚群体进行评估。

模型文档通常由 MRM 团队进行非常正式和独立的审查流程。这种独立审查是确保向模型开发团队提出正确问题的良好实践。在某些关键情况下，验证团队可能根据文档重新构建模型。在某些情况下，第二次实施采用替代技术，以确立对模型文档理解的信心，并突出原始工具集中未见的错误。

复杂且耗时的模型验证过程对整个 MLOps 生命周期有重要影响。这样漫长的质量保证过程不可能通过快速修复和迅速的模型迭代来解决，导致 MLOps 生命周期非常缓慢而审慎。

部署到生产环境

在典型的大型金融服务组织中，生产环境不仅与设计环境分离，而且可能基于不同的技术栈。用于关键操作（如交易验证，也可能是贷款验证）的技术栈将始终缓慢演变。

从历史上看，生产环境主要支持规则和线性模型，如逻辑回归。有些可以处理更复杂的模型，如 PMML 或 JAR 文件。对于较不关键的用例，可能可以通过 Docker 部署或通过集成的数据科学和机器学习平台进行部署。因此，模型的操作化可能涉及从点击按钮到根据 Microsoft Word 文档编写公式的操作。

部署模型的活动日志对于监控此类高价值用例中的模型性能至关重要。根据监控频率的不同，反馈循环可能是自动化的，也可能不是。例如，如果任务仅需每年一两次执行，并且大部分时间用于对数据提问，那么自动化可能是不必要的。另一方面，如果评估每周进行，如几个月的短期贷款可能的情况，自动化可能是至关重要的。

总结思考

多年来，金融服务业一直在开发预测模型验证和监控方案。他们能够不断适应像梯度提升方法这样的新建模技术。鉴于其重要影响，围绕这些模型的生命周期管理流程被良好形式化，甚至被整合到许多法规中。因此，它们可以成为其他领域 MLOps 最佳实践的源泉，尽管需要在其他业务中权衡健壮性与成本效益、价值时间以及团队沮丧之间的权衡。

第十章：MLOps 实践：营销推荐引擎

Makoto Miyazaki

推荐引擎在过去 20 年里变得非常流行，从亚马逊的第一本书推荐到今天在数字商店、广告和音乐视频流媒体中的普遍应用。我们都已经习惯了它们。然而，多年来，这些推荐引擎背后的技术已经发展和演变。

本章涵盖了一个使用案例，说明了在快节奏和快速变化的机器学习模型生命周期中，MLOps 策略的适应和需求。

推荐引擎的崛起

历史上，营销推荐是由人工构建的。基于定性和定量营销研究，营销大亨们会制定静态定义印象（即广告展示视图）的规则，发送给具有特定特征的顾客。这种技术催生了营销数据挖掘的都市传说，即一家杂货连锁店发现，周四和周六购买尿布的男性更有可能购买啤酒，因此将这两种商品摆放在一起将增加啤酒的销量。

总体而言，手动创建的推荐引擎呈现了许多瓶颈，导致大量资金浪费：由于规则创建过程是手动的，很难基于许多不同的顾客特征制定规则；很难设置实验来测试多种不同的印象；当顾客行为发生变化时，更新规则也很困难。

机器学习的角色

机器学习的兴起为推荐引擎带来了新的范式，允许消除基于人类洞察力的规则。一种称为协同过滤的新类算法主导了这一领域。这种算法能够分析数以百万计的顾客和成千上万种产品的购买数据，进行推荐，而无需任何先前的营销知识。通过有效地识别像当前顾客购买过的顾客，营销人员可以依赖于优于传统方法的自动化策略，无论是在成本还是效率上。

由于策略构建的自动化过程，可以定期更新它们，并使用 A/B 测试或影子评分方案进行比较（包括在所有可能性中选择印象的方式）。请注意，这些算法可以与更经典的业务规则结合使用，出于各种原因——例如，避免过滤泡泡，在特定地理区域内不销售产品，或防止使用某些统计上显著但不道德的关联（比如向戒酒者推荐酒精制品），等等。

推送还是拉动？

在实施推荐引擎时，重要的是要记住其结构将取决于推送或拉取推荐。推送通道最易处理；例如，可以包括发送电子邮件或进行外呼。

推荐引擎可以定期以批处理模式运行（通常是每天一次到每月一次），并且可以轻松地将客户数据集分成几部分，以在健全的实验设计中进行分析。该过程的规律性允许定期审查和优化策略。

拉取通道通常更有效，因为它们在客户需要时提供信息，例如在线搜索或打电话给客服。可以利用会话中的具体信息（例如用户搜索了什么）来精确地定制推荐。例如，音乐流媒体平台为播放列表提供了拉取通道推荐。

推荐可以预先计算，就像本章的深入示例中所说明的那样，也可以实时生成。在后一种情况下，必须设置特殊的架构来动态计算推荐。

在拉取上下文中比较策略更具挑战性。首先，在给定渠道上打进电话的客户可能与普通客户不同。在简单情况下，可以随机选择每个推荐所使用的策略，但也可能需要在给定客户的特定期间内一致使用某种策略。这通常导致使用每种策略生成的推荐比例不平衡，这使得决定哪种策略最好的统计处理更复杂。然而，一旦建立了良好的框架，这允许非常快速的改进周期，因为可以实时测试许多策略。

数据准备

推荐引擎通常可以访问的客户数据包括以下内容：

• 关于客户的结构信息（例如年龄、性别、地点）

• 关于历史活动的信息（例如，过去的浏览、购买、搜索）

• 当前上下文（例如当前搜索、浏览的产品）

无论使用何种技术，所有客户信息都必须聚合为特征向量（固定大小的列表）。例如，可以从历史活动中提取以下特征：

• 在最近一周或一个月内的购买金额

• 在过去一段时间内的浏览次数

• 在过去一个月内支出或浏览量的增加

• 先前看到的印象和客户的响应

除了客户数据外，推荐的上下文还可以考虑。例如，对于季节性产品如地面游泳池，可以考虑到夏季的天数，或者到每月发薪日的天数，因为一些客户会因现金流问题延迟购买。

一旦客户和上下文数据格式化完成，定义一组可能的推荐内容是非常重要的，而且有很多选择要做。同一产品可能以不同的方式呈现，可以用不同的方式进行传播。

必须铭记“不推荐任何内容”选项的重要性。事实上，我们大多数人都有这样的个人经历，不是所有的推荐都有积极的影响。有时，不显示任何内容可能比其他选择更好。还要考虑到，某些客户可能没有资格看到某些推荐内容，例如取决于其地理来源。

设计和管理实验

为了利用推荐引擎的持续改进潜力，有必要在一个健全的框架内尝试不同的策略。在设计推荐引擎的预测模型时，数据科学家可能会专注于一种简单的策略，如预测给定客户点击给定推荐的概率。

与尝试收集关于客户是否购买产品及是否将此次购买归因于某个推荐的更精确方法相比，这可能看起来是一个合理的妥协。然而，从商业角度来看，这并不足够，因为可能会发生像自相残杀这样的现象（即通过向客户展示低毛利产品，可能会阻止其购买高毛利产品）。因此，即使预测准确且导致销售量增加，总体收入可能会减少。

另一方面，直接推广组织的利益而不是客户的利益，长期来看也可能带来不利后果。应谨慎选择用于评估特定战略是否带来更好结果的最重要 KPI，以及评估的时间段。选择推荐后两周内的收入作为主要 KPI 是常见做法。

为了尽可能接近实验设置，也称为 A/B 测试，必须仔细选择对照组和实验组。理想情况下，在实验开始前通过随机分割客户群体来定义这些组。如果可能，客户最近不应参与其他实验，以免其历史数据受到其影响的污染。然而，在许多新客户涌入的情况下，这可能不可行。在这种情况下，分组分配可以动态决定。组的大小以及实验的持续时间取决于预期的 KPI 差异的大小：预期效果越大，组大小越小，实验持续时间越短。

实验也可以分两步进行：首先，在第一步中，可以选择两组相等但有限的规模。如果实验结果积极，可以从新策略上开始部署 10%的比例，这一比例可以逐步提高，如果结果符合预期的话。

模型训练和部署

为了更好地说明针对这种用例的 MLOps 过程，以下几节重点介绍一个假想公司部署自动化流水线来训练和部署推荐引擎的具体示例。该公司是一家全球软件公司（我们称之为 MarketCloud），总部位于硅谷。

MarketCloud 的产品之一是一个名为 SalesCore 的软件即服务（SaaS）平台。SalesCore 是一款面向企业的 B2B 产品，允许用户（企业）通过跟踪交易、清理繁琐的行政任务，并为每个客户创建定制产品报价来简单地推动销售（见图 10-1）。

有时，MarketCloud 的客户在与客户通话时使用基于云的 SalesCore，通过查看与客户的过去互动以及由 SalesCore 建议的产品报价和折扣，调整其销售策略。

MarketCloud 是一家年收入约 2 亿美元、员工数以千计的中型公司。从酿酒公司的销售人员到电信实体的人员，MarketCloud 的客户代表了各种类型的企业。

图 10-1. SalesCore 平台的示意图，本节示例的理论公司的基础

MarketCloud 希望能够自动向 SalesCore 的销售人员显示产品建议，以帮助他们向客户销售产品。建议将基于客户的信息以及他们与销售人员的过去互动记录进行，因此每个客户的建议将是定制的。换句话说，SalesCore 基于推荐引擎，在拉（入站电话）或推（出站电话）的情境中使用。销售人员可以在与客户通话时将建议产品纳入其销售策略中。

为了实现这一想法，MarketCloud 需要构建一个推荐引擎并将其嵌入到 SalesCore 平台中，从模型训练和部署的角度来看，这提出了几个挑战。我们将在本节中介绍这些挑战，而在下一节中，我们将展示 MLOps 策略，使公司能够处理每一个挑战。

可扩展性和可定制性

MarketCloud 的商业模式（为客户公司销售软件，帮助它们销售自己的产品）呈现了一个有趣的情况。每家客户公司都有自己的数据集，主要是关于其产品和客户，而且不希望与其他公司共享这些数据。

如果 MarketCloud 有大约四千个客户在使用 SalesCore，这意味着与为所有客户创建一个通用的推荐系统相比，它需要创建四千个不同的系统。MarketCloud 需要想出一种方法，以尽可能高效的方式建立四千个推荐系统，因为无法一一手工制作那么多系统。

监控和重新训练策略

四千个推荐引擎中的每一个都将根据相应客户的客户数据进行训练。因此，它们中的每一个都将是一个不同的模型，产生不同的性能结果，并且几乎不可能手动监控所有四千个。例如，饮料行业客户 A 的推荐引擎可能会持续给出良好的产品建议，而电信行业客户 B 的引擎则很少提供良好的建议。MarketCloud 需要想出一种方法，自动化监控和随后的模型重新训练策略，以防性能下降。

实时评分

在许多情况下，MarketCloud 的客户在电话沟通时使用 SalesCore。销售谈判在通话期间每一分钟都在发展，销售人员需要在与客户互动过程中调整策略，因此推荐引擎必须能够响应实时请求。

例如，想象一下你作为销售人员与客户通话，以销售电信设备为例。客户告诉您他的办公室的情况，办公室现有的基础设施，比如光纤、WiFi 网络类型等等。在 SalesCore 中输入这些信息后，您希望平台能即时为您推荐客户可能购买的产品。平台的响应需要是实时的，而不是在通话结束后 10 分钟后或第二天。

可以打开和关闭推荐功能

负责任的 AI 原则承认保留人类参与的重要性。这可以通过人类在命令设计中实现，¹即应该有可能不使用 AI。此外，如果用户不能覆盖 AI 建议，采用可能会很低。一些客户重视使用他们自己的直觉来推荐产品给他们的客户。因此，MarketCloud 希望为其客户提供完全控制权，可以随时打开和关闭推荐引擎，以便客户在需要时使用推荐。

管道结构和部署策略

为了高效构建四千个推荐引擎，MarketCloud 决定创建一个数据流水线原型，并将其复制四千次。这个原型流水线包括必要的数据预处理步骤和一个单一的推荐引擎，建立在示例数据集上。所有四千个流水线中使用的推荐引擎算法是相同的，但它们将根据每个客户的特定数据进行训练（见 图 10-2）。

图 10-2. MarketCloud 推荐引擎项目的数据流水线结构图像

这样一来，MarketCloud 可以高效地启动四千个推荐系统。用户仍然保留一定的定制空间，因为引擎是使用他们自己的数据训练的，每个算法将使用不同的参数——即适应每个客户和产品信息。

能够将单一流水线扩展为四千个流水线的关键在于数据集的通用模式。如果客户 A 的数据集有 100 列，而客户 B 只有 50 列，或者客户 A 的“购买商品数量”列是整数，而客户 B 的同一列是字符串，它们需要经过不同的预处理流水线。

尽管每个客户具有不同的客户和产品数据，但在这些数据被注册到 SalesCore 时，每列获得相同的列数和相同的数据类型。这简化了事务，因为 MarketCloud 只需复制一条流水线四千次。

嵌入在四千个流水线中的每个推荐系统将具有不同的 API 终点。表面上看，当用户点击“显示产品推荐”按钮时，SalesCore 显示建议产品列表。但实际上，通过点击按钮，用户是触发了与特定客户的排名产品列表相关联的特定 API 终点。

监控与反馈

维护四千个推荐系统并非易事，虽然在此之前已经考虑了许多 MLOps 问题，但这可能是最复杂的部分。每个系统的性能需要根据需要进行监控和更新。为了在大规模上实施这一监控策略，MarketCloud 可以自动化重新训练和更新模型的情景。

重新训练模型

客户获取新客户，一些客户流失，每隔一段时间就会向其目录添加新产品或删除产品；底线是客户和产品数据不断变化，推荐系统必须反映最新数据。这是它们保持推荐质量的唯一方式，更重要的是，避免出现推荐过时且不再支持的 WiFi 路由器等情况。

为了反映最新的数据，团队可以编写一个方案自动更新数据库，使用最新的客户和产品数据，每天午夜重新训练模型。这种自动化方案然后可以在所有四千个数据管道中实施。

重新训练的频率可以根据使用情况而有所不同。在这种情况下，由于高度自动化，每晚重新训练是可能的。在其他情境中，重新训练可能会受到各种信号的触发（例如新信息的显著量或客户行为的漂移，无论是非周期性的还是季节性的）。

此外，必须考虑推荐与其效果评估的时间间隔。如果仅在几个月后才知道影响，每天重新训练显然是不够的。事实上，如果行为变化如此迅速，每天重新训练是必要的，那么在训练数据中最新数据几个月后使用模型做推荐时，模型很可能已经完全过时。

更新模型

更新模型也是规模化自动化策略的关键特性之一。在这种情况下，对于四千条管道中的每一条，重新训练的模型必须与现有模型进行比较。可以使用诸如 RMSE（均方根误差）之类的指标比较它们的性能，只有当重新训练的模型的性能优于先前的模型时，重新训练的模型才会被部署到 SalesCore。

晚间运行，白天休眠

尽管模型每天重新训练，用户并不直接与模型互动。使用更新后的模型，平台实际上在夜间完成为所有客户计算产品排名列表。在第二天，当用户点击“显示产品推荐”按钮时，平台只需查看客户 ID，并返回特定客户的产品排名列表。

对用户来说，推荐引擎看起来是实时运行的。然而实际上，一切都是在夜间准备好的，白天引擎处于休眠状态。这样可以实现即时推荐，没有任何停机时间。

手动控制模型的选项

尽管模型的监控、重新训练和更新是完全自动化的，MarketCloud 仍然为其客户留有关闭和打开模型的空间。更确切地说，MarketCloud 允许用户从三个选项中选择与模型互动的方式：

• 打开以基于最新数据集获取推荐

• 冻结以停止使用新数据进行重新训练，但继续使用相同的模型

• 关闭以完全停止使用 SalesCore 的推荐功能

机器学习算法试图将实际知识转化为有意义的算法，以自动化处理任务。然而，让用户依赖他们的领域知识仍然是良好的实践，因为他们被认为能够更好地识别、表达和展示日常业务过程中的问题。

第二个选项很重要，因为它允许用户保持当前推荐的质量，而无需推荐引擎使用更新的数据。当前模型是否被重新训练取决于基于诸如 RMSE 之类的度量标准的数学评估。然而，如果用户觉得 SalesCore 上的产品推荐已经有效促进销售，他们可以选择不冒险改变推荐质量。

自动控制模型的选项

对于那些不想手动处理模型的人，平台也可以提出 A/B 测试，以便在完全切换之前测试新版本的影响。多臂赌博算法（一种允许最大化用户面对多个老丨虎丨机的收入的算法，每个老丨虎丨机的赢取概率和平均返还的钱的比例都不同）用于此目的。

假设有多个模型版本可用。目标是使用最有效的一个，但要做到这一点，算法显然必须首先学习哪个是最有效的。因此，它平衡这两个目标：有时它尝试可能不是最有效的算法来学习它们是否有效（探索），有时它使用可能是最有效的版本来最大化收入（利用）。此外，它会忘记过去的信息，因为算法知道今天最有效的可能明天就不是最有效的了。

最先进的选项是为不同的 KPI（点击、购买、预期收入等）训练不同的模型。然后，受集成模型启发的方法将允许解决模型之间的冲突。

性能监控

当销售人员建议客户购买 SalesCore 推荐的产品时，记录客户与推荐产品的互动以及客户是否购买了这些产品。然后可以使用这些记录来跟踪推荐系统的性能，将这些记录覆盖客户和产品数据集，以在重新训练模型时提供最新的信息。

由于这种地面真实记录过程，可以向用户展示显示模型性能的仪表板，包括来自 A/B 测试的性能比较。由于地面真实很快就可以获得，数据漂移监控是次要的。模型的一个版本每晚训练一次，但由于冻结机制，用户可以根据定量信息选择活跃版本。在这些性能指标难以捕捉决策背后完整背景的高影响决策中，保持人类参与是惯例。

在 A/B 测试的情况下，重要的是一次只对一组客户进行一个实验；无法简单地加总组合策略的影响。考虑到这些因素，可以建立一个坚实的基线来进行反事实分析，并推导出与新策略相关的增加收入和/或减少流失。

除此之外，MarketCloud 还可以通过检查多少客户冻结或关闭推荐系统来监控算法的宏观性能。如果许多客户关闭了推荐系统，这表明他们对推荐质量不满意的强烈指示。

总结思考

这个用例在某种意义上很特别，因为 MarketCloud 建立了一个销售平台，许多其他公司用来销售产品，其中数据的所有权归每家公司所有，不能在公司之间共享。这带来了一个具有挑战性的情况，即 MarketCloud 必须为每个用户创建不同的推荐系统，而不是汇集所有数据创建一个通用推荐引擎。

MarketCloud 可以通过创建一个单一的管道来克服这个障碍，将来自许多不同公司的数据输入其中。通过让数据经过自动化推荐引擎训练场景，MarketCloud 创建了许多针对不同数据集训练的推荐引擎。良好的 MLOps 流程使公司能够在规模上做到这一点。

值得注意的是，尽管这个用例是虚构的，但它基于现实。类似项目的真实团队花了大约三个月的时间完成。团队利用数据科学和机器学习平台编排复制单一管道到四千个副本，并自动化流程，将相应数据集输入到每个管道并训练模型。必要时，他们在推荐质量和可扩展性之间接受了权衡，以高效地推出产品。如果团队精心为这四千个管道中的每一个定制了推荐引擎，例如为每个客户选择最佳算法，推荐引擎将会质量更高，但他们将永远无法在如此短的时间内用如此小的团队完成这个项目。

¹ 人类控制设计的解释，请参见Karen Yeung，“责任与人工智能”（欧洲理事会研究，DGI(2019)05），第 64 页，脚注 229。

第十一章：实践中的 MLOps：消费预测

Nicolas Omont

预测在不同时间和地理尺度上对电网运行至关重要。它们允许模拟系统可能的未来状态，并确保其可以安全运行。本章将介绍消费预测的机器学习模型生命周期和 MLOps 使用案例，包括业务考虑因素、数据收集和实施决策。尽管此特定章节专注于电力网格，但消费预测的考虑因素和特殊情况可以推广到其他使用消费预测的工业案例。

电力系统

大电力系统是电网的支柱。也称为输电网络，它们构成了保持灯火通明的系统核心。这些系统主要由线路和变压器组成，通过分布网络间接连接到大多数生产者和消费者，后者负责最后几公里的传输。正如在图 11-1 中所示，只有最大的生产者和消费者直接连接到大系统。

图 11-1. 一个示例的大电力系统，只有最大的生产者和消费者直接连接

传输距离越长、能量体积越大，使用的电压越高：在低端，几十千伏用于几十兆瓦在几十公里上的传输；在高端，数百万伏用于数千兆瓦在数千公里上的传输。（一条容量为一兆瓦的线路可以为欧洲约一千名居民提供电力。）传输系统的运行一直需要大量的通信和计算，因为其特性如下：

无能量储存

网络存储的能量微不足道——在电网中不到一秒的消耗量，而在交流发电机和电动机中最多可达 30 秒。相比之下，天然气网络在其管道中存储了数小时的消耗量。因此，必须迅速采取行动来平衡生产和消费，避免停电。

弱流量控制

在电信网络上，拥塞通过丢包或不建立呼叫来处理。在电网中不存在类似的机制，这意味着网格元素上的电力流量可能高于其运行极限。根据技术和严重程度，几秒钟到几小时的超载后必须采取行动。尽管存在流量控制技术，但在流量控制和即时平衡之间存在权衡：电力必须找到从发电到消费的路径。

由于这两个属性，电网操作员必须始终预测突发情况：如果此电网元素故障，剩余元素的过载是否仍然可接受？预期是在几个时间尺度上进行的，从接下来的五分钟到接下来的五十年。需要采取的行动取决于时间跨度。例如：

• 少于五分钟：无法进行人工操作。自动操作应该已经定义完善。

• 从五分钟到几小时之间：生产时间表和电网拓扑的调整（开断路器和其他流控技术的应用）。

• 几天前：维护时间表的调整。

• 几个季节前：维护时间表的调整，与生产者或消费者签订合同，以保证电力容量或限制电力产生或消耗。

• 从 5 到 50 年之间：投资电网元素。线路和变压器的标准寿命可达数十年；实际上，预计某些电网元素将超过一百年。

另一个问题是在不同地理尺度上的预期。尽管某些事故只对电网的一小部分产生影响，但某些事故可能会对整个大陆产生影响，并可能需要多个国家协调行动以减轻其影响。因此，运行电网需要：

1. 在时间紧迫的情况下，收集广域的数据。

2. 处理数据以便预测并相应行动。

数据采集

收集过去的数据是制作预测的第一步。数据主要来自两个独立的来源：SCADA（监控与数据采集）系统和计量系统。根据预测用例，可能会使用其中之一。

SCADA 系统实时收集数据，为操作员提供系统的最新视图。它还允许向网络设备发送命令，例如打开和关闭断路器。系统的最出色表现是大多数控制室中常见的综合显示屏，如图 11-2 所示。

图 11-2。SCADA 系统通常每 10 秒或更短时间刷新数千次有关电网流动、消耗和发电的测量数据。

有些测量是有意冗余的，比如功率损耗的测量。如果在线路的每一端测量功率流，则它们之间的差等于该线路上的损耗。这些损耗可以通过物理估计来处理，以便在一个测量缺失的情况下处理，检测异常或改进估计的精度。

使用冗余以生成网络状态的过程称为状态估计，并且每隔几分钟运行一次。当操作限制条件不满足时，SCADA 系统会发出警报。但是，如果网格元素中的任何一个失效，SCADA 无法发出警报。

对由状态估计产生的一致状态进行网络元素损失仿真（N-1 仿真）是定期进行的，而 SCADA 数据的值迅速消退；因此，在历史化时，它不会被整合；通常不输入缺失值，通常也不纠正异常。状态估计被各种过程使用，因此通常会在几个月到几年的时间内被历史化。

用于计费的计量系统不需要像 SCADA 系统那样具有反应性，但应精确。它侧重于发电和消费，而不是流动。它不是监视瞬时功率，而是记录在几分钟到一小时之间的一段时间内抽取或注入的能量。

它收集的信息之前需延迟一天或更长时间才能获取。较新的系统使信息在几分钟内可用。然而，当存在缺失测量或异常时通常需要整合和验证，以便最终数据通常在几个工作日内仍然可用。这些数据有很好的历史记录。

问题定义：机器学习，还是不是机器学习？

并非所有的使用案例都适合机器学习。有些情况可以通过其他方式更轻松、更便宜地解决。用于这类使用案例的预测技术在这三种情况下不同，如表 11-1 所示。

表 11-1. 案例使用的预测技术

使用案例	预测技术
预测不确定性来自操作员无法改变的系统的一部分。	从实际上来说，改变天气是不可能的。因此，风能和光伏（PV）发电以及供暖和空调可以安全地被视为外生变量。这使它们成为直接进行机器学习预测的良好候选。这些预测可以利用气象预测或气候场景，具体取决于时间跨度。气象预测通常仅提前几天，尽管一些模型现在可以预测未来几个月的趋势。
预测不确定性来自操作员可以在某种程度上影响的系统的一部分。	例如，严格来说，不应该预测消费，而是需求。消费与需求的区别在于，消费在操作员手中，可以选择关闭消费者不满足需求。出于同样的原因，应预测光伏和风能生产潜力，而不是实际生产。
预测的不确定性来自系统的一部分，其他行动者可以控制并预测。	例如，对于可调度的电力单元，操作员可以将其打开或关闭，最好要求操作员提供时间表。如果不可能，复制时间表的方式可能更好，例如，如果电价高于电厂燃料成本，操作员可以启动电厂。在这种情况下，预测可能依赖于诸如基于代理模型的建模技术。大型工厂可能根据其操作生产计划有消耗计划。配电网拓扑结构也可能需要提前计划，因为维护操作需要提前规划。在所有这些情况下，通常最好要求提供时间表，而不是使用机器学习来预测。

空间和时间分辨率

由于大数定律，当消费在空间或时间上聚合时，预测的不确定性会减少。尽管预测个体家庭每小时的消耗很难，因为人们不是机器，但对几百万人口的人群来说却相当容易，对这样的人群每月消耗的预测也相对容易。

因此，预测系统通常是分层的，具有几个层次的预测，这些预测通过约束条件连接在一起。也就是说，区域预测应该总结到全国范围内的预测，小时预测应该总结到每日预测。

让我们举一个引人注目的例子来说明这一点。电力牵引列车对电网运营商来说具有令人担忧的消耗模式，因为它们移动，典型的列车线路每 10 到 50 公里由不同的变电站供电。因此，操作员每隔大约 10 分钟就会看到几兆瓦的消耗在不同的变电站之间切换。这造成了几个问题：

• 在线路层面上预测相对较容易，因为列车总是在某处消耗，并且列车通常在固定的时间行驶。因此，机器学习方法可能会有效。

• 在给定变电站长时间内所撤出的能量的预测也相对较简单，因为列车将通过线路的相应部分。

• 但是由于操作员希望知道列车在行驶时是否会造成过载，因此需要一套一致的预测：

  • 列车应该一次只在一个位置吸取电力。

  • 每个变电站应该在某个时间点看到消耗的急剧增加，因此需要细粒度的时间分辨率。

因此，解决方案取决于预测的目标：

• 日常基础上，将列车消耗分配到所有变电站的平均解决方案是不可接受的，因为可能会错过潜在的过载情况。将列车消耗分配到所有变电站的最坏情况解决方案可能更可接受，尽管它会预期到虚假过载，因为总体消耗将太大。

• 然而，为了安排喂养该地区的一条线路的维护，消费的确切位置可能不会产生影响，只要不重复计数。

在设计预测系统时，将不得不做出权衡，因为完美系统不太可能存在。如果系统有很大的余量，则预计几乎没有或没有过载，因此预测系统可以粗糙。但是，如果电网接近其极限运行，则必须小心制定系统。

实施

数据一旦由 SCADA 系统或计量系统收集，就必须进行历史化。除了存储原始数据外，还需要进行一些处理：

• 时间聚合，例如在五分钟内：保留平均值或高分位数值。平均值代表该时段内消耗的能量，高分位数有助于评估是否发生约束。

• 分解：当只测量到取出量时，需要分别估计生产和消费。通常，在去除分布式发电（风能、光伏等）的最佳估计后，消费量是剩余的部分。机器学习可以用来进行这些估计。

• 空间聚合：由于系统平衡，可以通过计算本地生产与与邻近地区的交换之差来计算区域的消费量。这在历史上非常有用，因为生产易于监控，因为只有少量非常大的发电单元和少量与邻国的线路。如今，随着分布式发电的普及，这变得更加复杂。

• 缺失值插补：可能会出现测量值缺失的情况。在 SCADA 系统中，存在规则用于实时用老数据或者典型值替换缺失值。在计量系统中，插补是一个重要的过程，因为它会直接反映在客户的账单上。

数据然后存储在不同的数据库中。用于短期关键过程的数据存储在高可用系统中，冗余性允许从数据中心丢失中快速恢复。用于长期过程（开票、报告、ML 模型训练）的数据存储在普通的 IT 数据库中。总体而言，按照今天的标准，受监控的电网元素数量将在 1,000 到 100,000 之间波动。这意味着它们产生了合理量的数据。扩展性也不是问题，因为发达国家的大型电网已不再增长。

建模

一旦数据准备完成，数据科学家通常可以访问几百个不同电网提取点的生产和消费时间序列。他们必须开发方法来预测其中一些在不同的时间范围内。他们通常专注于风能、光伏发电以及间歇性水力发电的生产潜力和需求。尽管风能和光伏主要依赖气象因素，但需求主要受经济活动驱动，但部分也依赖于气象条件（例如供暖和制冷）。

根据不同的视角，建模可能看起来非常不同：

• 短期：在未来几天内，最后已知的数值对于进行预测非常重要。此外，出于同样的原因，气象预报是可用的。因此，方法将利用这些信息。在这种情况下，确定性预测是合理的。

• 中期：在几天到几年之间，气象是未知的，但气候是已知的。基于过去年度趋势的统计外推是有意义的，除非发生经济危机。因此，可以制定场景以获得关于未来消费的统计指标（平均值、置信区间、分位数等）。

• 长期：投资决策需要对未来几十年的预测。在这个视角上，对当前趋势的统计外推不足以应对社会经济和气候变化，尤其是全球变暖。因此，统计方法必须与基于使用的自底向上方法和关于未来的多样化专家制定的场景相结合。

机器学习和 MLOps 主要涉及短期和中期预测。在这种情况下，中期模型更容易开始：在几年的数据基础上，目标是根据：

• 日历，具有日常、周常和年度周期的叠加。银行假日和学校假期也会产生重大影响，此外还有夏令时。

• 气象变量（温度、风、阳光）。由于建筑物具有非常大的热惯性，可能需要过去至少两天到三周的温度数据。

尽管可以使用任何类型的机器学习算法，但预测曲线的平滑性很重要，因为预测不是单独使用的，而是作为每日、每周或每年的场景。许多算法在其度量标准中不考虑平滑性，因为它们依赖于假设数据是独立同分布的，而在我们的情况下，这是不正确的，因为给定日的消费通常与前一日和前一周的消费相关联。

广义可加模型（GAM）通常是一个很好的起点：它们基于样条，因此保证了平滑性。事实上，消费预测是它们开发的用例之一。结合气候场景，机器学习模型可以生成年度消费场景。

短期预测更为复杂。最简单的方法是从最近的历史数据中减去中期预测，然后使用标准时间序列技术（如 ARIMA（自回归积分移动平均）或指数平滑）处理残差。这允许生成几天的预测。一个基于多年数据训练的集成短期模型可能比这种简单方法有潜在优势。

例如，中期模型是基于实现的气象数据训练的，而不是基于气象预测。因此，它过于重视气象预测，即使它们可能是错误的。基于气象预测训练的短期模型将解决这个问题。然而，虽然新算法（如长短期记忆（LSTM）神经网络）很有前途，但很难找到一种方法，以一致的方式同时预测几个时间范围内的任何时间点。

当分辨率达到使随机性过大而无法进行有意义预测时，最好是在时间序列或空间上进行聚合，然后使用非机器学习的启发式方法来分割聚合的预测：

• 在空间聚合情况下，基于过去观察的共享密钥

• 在临时聚合情况下，基于过去观察的平均配置文件

由于网络在不断发展，新的注入和提取可能会出现，而没有历史数据可用，并且消费模式可能会出现断裂，因此过去的数据不再相关。预测方法必须考虑这些边缘情况。断裂可以使用异常检测方法来发现。一旦识别到断裂，可以使用简化模型，直到有足够的历史数据为止。

再次，神经网络可能成为一个吸引人的替代方案，承诺只需为所有消费训练一个模型，而不是使用标准方法为每个消费训练一个模型。事实上，只有一个模型，即使消费的历史数据较少，也可以进行预测，前提是其模式看起来类似于现有模式。

部署

现在，这些模型很可能是由数据科学家在 R、Python 或 MATLAB 脚本中进行原型设计的。原型能够准备数据，在一个数据集上训练模型，并在另一个数据集上评分。其操作化可能会遵循几条路径：

• 原型完全重写。这种方式成本高，不够灵活，但在需要嵌入运营技术（OT）系统时可能是必要的。

• 只有数据准备和评分被重新编写，这允许根据不同的时间表进行培训。如果培训每年进行一次或更频繁，这是有道理的，因为定期进行模型审查以确保其良好运行，并且具备维护所需的技能是一个良好的实践。

• 数据科学和机器学习平台可用于将原型操作化。这些平台灵活且允许将原型转移到保证安全性和可扩展性的生产环境中。大多数消费预测模型将定期以批处理模式运行。对于更具体的用例，这些平台能够将训练好的模型导出为 JAR 文件、SQL、PMML、PFA 和 ONNX，以便能够灵活地集成到任何类型的应用程序中。

监控

本节主要讨论短期预测。事实上，中期和长期预测通常受漂移影响，因为过去看起来从未像未来，所以在使用之前几乎总是重新训练。对于短期预测，除了 IT 监控以在预测未能按时产生时引发警报，并对可能导致错过截止日期的事件发出警告外，模型本身也应该受到监控。

第一种监控类型是漂移监控。对于电力消费，漂移监控与模型部署在一起是至关重要的。异常检测和断裂检测允许团队确保可以使用训练好的模型。如果不能使用，则应使用基于浅层历史数据或多个消费预测的规范分解的备用模型。这种第一层将在线检测到显著的漂移。

尽管数据科学家会尝试设计适应消费水平（如 ARIMA）的模型，但检测到某些消费水平比培训期间低或高可能很有用。这可能是慢慢发生的，因此在线未能检测到。例如，如果每天计算第二天的预测，那么离线分析预测，例如每月一次，可以检测到这些慢漂移。在这些情况下，如果没有额外的基准数据可用，将这些消费切换到备用模型是有意义的。

最后，在操作之后，可以通过各种指标如平均绝对百分比误差（MAPE）评估预测性能。如果在显著时间段内（例如一个月）检测到性能下降，可以考虑重新训练相应的模型，因为有新数据可用，重新训练的模型可能会提高性能。

这要求设计和生产环境与 CI/CD 流程（在第六章详细讨论过）紧密集成。如果能够每年手动处理一次新模型的部署，那么每个月进行一次则通常成本过高。通过先进的数据科学和机器学习平台，还可以在将其用于预测之前，对新模型进行几天的影子评分。

总结思考

在本章中，我们看到如何使数据发挥作用，以协助运行输电电网。各种机器学习和非机器学习技术可用于为从分钟到数十年的时间尺度上的数千次消费提供预测。

由于 MLOps 的作用，设计、部署和监控流程已在多个行业间标准化，并开发了支持此流程的数据科学和机器学习平台。消费预测系统的设计者可以利用这些标准流程和平台，从成本、质量或时间价值的角度改善这些系统的效率。

回顾全局视角，很明显，不同行业在定义问题、建模、推向生产等方面存在各种各样的机器学习用例，每个用例都有其独特的复杂性，正如本书所覆盖的一切。但无论是哪个行业或用例，MLOps 流程始终是一个纽带，使数据团队（甚至整个组织）能够扩展其机器学习工作。