在本文中，我们将研究独立于任何工具的核心 MLOps 指南，以设计强大且可扩展的生产 ML 系统和架构：

1. 自动化或操作化
2. 版本控制
3. 实验追踪
4. 测试
5. 监控
6. 可重复性

让我们首先研究自动化（操作化）的基础。

#1. 自动化或操作化

为了采用 MLOps，大多数应用程序需要逐步构建三个核心层，从手动处理到完全自动化：

• 手动流程：在开发 ML 应用程序的早期阶段，该流程是实验性的和迭代的。数据科学家手动执行每个流程步骤，例如数据准备和验证、模型训练和测试。此时，他们通常使用 Jupyter Notebook 来训练他们的模型。此阶段的输出是用于准备数据和训练模型的代码。
• 持续 训练 (CT)：下一个级别涉及自动化模型训练。这称为持续训练 (CT)，它会在需要时触发模型重新训练。此时，您通常会自动化数据和模型验证步骤。此步骤通常由编排工具（例如 ZenML）完成，该工具将所有代码粘合在一起并在特定触发器上运行。最常见的触发器是按计划执行的，例如每天或当特定事件发生时，例如当上传新数据或监控系统检测到性能下降时，这为您提供了适应各种触发器的灵活性。
• CI/CD：在最后阶段，您将实施 CI/CD 管道，以便快速可靠地将 ML 代码部署到生产中。此阶段的关键进步是自动构建、测试和部署数据、ML 模型和训练管道组件。CI/CD 用于快速将新代码推送到各种环境（例如暂存或生产），确保高效可靠的部署。

当我们使用 FTI 架构构建 LLM 系统时，我们可以快速从手动流程转向 CI/CD/CT。在图 1 中，我们可以观察到 CT 流程可以由各种事件触发，例如监控管道检测到的性能下降或一批新数据刚刚到达。

此外，图 1 分为两个主要部分；第一部分重点介绍自动化流程，而在底部，我们可以观察数据科学团队在尝试各种数据处理方法和模型时执行的手动流程。

一旦他们通过调整数据处理方式或模型架构来改进模型，他们就会将代码推送到代码存储库，从而触发 CI/CD 管道来构建、测试、打包和部署对 FTI 管道的新更改。

总而言之，CT 自动化了 FTI 管道，而 CI/CD 构建、测试并将新版本的 FTI 管道代码推送到生产中。

#2. 版本控制

现在，我们知道，如果代码、模型或数据发生变化，整个 ML 系统就会发生变化。因此，单独跟踪和版本控制这三个元素至关重要。但是，我们可以采用哪些策略来分别跟踪代码、模型和数据呢？

代码由 git 跟踪，这有助于我们在代码库中添加的每项更改上创建新的提交（代码快照）。此外，基于 git 的工具通常允许我们发布版本，这些版本通常包含多项功能和错误修复。

虽然提交包含人类无法解释的唯一标识符，但发布遵循基于其主要版本、次要版本和补丁版本的更常见的约定。

例如，在版本“v1.2.3”中，1 是主要版本，2 是次要版本，3 是修补程序版本。流行的工具是 GitHub 和 GitLab。

要对模型进行版本控制，您可以利用模型注册表来存储、共享和版本控制系统中使用的所有模型。它通常遵循代码版本中使用的相同版本控制约定，定义为语义版本控制，它与主要版本、次要版本和补丁版本一起，还支持用于发出应用程序信号的 alpha 和 beta 版本。

此时，您还可以利用 ML 元数据存储将信息附加到存储的模型，例如它基于哪些数据进行训练、其架构、性能、延迟以及与您的特定用例相关的其他任何信息。这样做可以创建一个清晰的模型目录，可以轻松地在您的团队和公司中导航。

对数据进行版本控制并不像对代码和模型进行版本控制那么简单，因为它取决于您拥有的数据类型（结构化或非结构化）和数据规模（大或小）。

例如，对于结构化数据，您可以利用带有版本列的 SQL 数据库来帮助您跟踪数据集中的更改。但是，其他流行的解决方案基于类似 git 的系统（例如 DVC），该系统可跟踪对数据集所做的每项更改。

其他流行的解决方案基于类似于模型注册表的工件，该工件允许您向数据集添加虚拟层，跟踪并为每个对数据所做的更改创建新版本。 Comet ML、W&B 和 ZenML 提供了强大的工件功能。对于这两种解决方案，您都必须将数据存储在本地或云对象存储解决方案（例如 AWS S3）中。这些工具提供的功能允许您构造数据集、版本、跟踪和访问它们。

#3. 实验追踪

训练 ML 模型是一个完全迭代和实验的过程。与传统软件开发不同，它涉及运行多个并行实验，根据一组预定义的指标对它们进行比较，并决定哪个应该投入生产。

实验跟踪工具可让您记录所有必要的信息，例如模型预测的指标和视觉表示，以便比较所有实验并轻松选择最佳模型。常用的工具有 Comet ML、W&B、MLFlow 和 Neptune。

#4. 测试

测试 ML 系统时也遵循同样的趋势。因此，我们必须从数据、模型和代码这三个维度测试我们的应用程序。我们还必须确保特征、训练和推理管道与特征存储等外部服务很好地集成，并作为一个系统协同工作。

使用 Python 时，编写测试的最常用工具是 pytest，我们也推荐它。

测试类型

在开发周期中，不同阶段通常采用五种主要类型的测试：

• 单元测试：这些测试专注于具有单一职责的各个组件，例如添加两个张量的函数或在列表中查找元素的函数。
• 集成测试：这些测试评估系统内集成组件或单元之间的交互，例如数据评估管道或特征工程管道，以及它们如何与数据仓库和特征存储集成。
• 系统测试：系统测试在开发周期中起着至关重要的作用，因为它们会检查整个系统，包括完整和集成的应用程序。这些测试严格评估系统的端到端功能，包括性能、安全性和整体用户体验。例如，测试整个机器学习流程，从数据提取到模型训练和推理，确保系统针对给定的输入产生正确的输出。
• 验收测试：这些测试通常称为用户验收测试 (UAT)，旨在确认系统满足指定要求，确保已准备好部署。
• 回归测试：这些测试检查先前发现的错误，以确保新的更改不会重新引入这些错误。
• 压力测试：这些测试评估系统在极端条件下（例如高负载或资源有限）的性能和稳定性。它们旨在确定临界点并确保系统能够处理意外的需求高峰或不利情况而不会失败。

我们测试什么？

在编写大多数测试时，您会将组件视为黑盒。因此，您可以控制的是输入和输出。您需要测试是否获得了给定输入的预期输出。请记住这一点，以下是您通常应该测试的一些想法：

• 输入：数据类型、格式、长度、边缘情况（最小/最大、小/大等）；
• 输出：数据类型、格式、异常、中间和最终输出。

测试示例

测试代码时，您可以利用经典软件工程的标准。以下是编写单元测试时的一些代码测试示例，以便更好地了解我们此时想要测试的内容。例如，您想检查一个句子是否按预期清理。此外，您可以查看分块算法，并通过使用各种句子和块大小来断言它正常工作。

当我们谈论数据测试时，我们主要指的是数据有效性。数据有效性代码通常在从数据仓库提取原始数据时或计算特征后运行。它是功能管道的一部分。因此，通过为功能管道编写集成或系统测试，您可以检查系统是否正确响应有效和无效数据。

测试数据有效性在很大程度上取决于您的应用程序和数据类型。例如，处理表格数据时，您可以检查非空值、分类变量是否仅包含预期值或浮点值是否始终为正值。处理文本等非结构化数据时，您可以检查长度、字符编码、语言、特殊字符和语法错误。

模型测试是最棘手的，因为模型训练是 ML 系统中最不确定的过程。然而，与传统软件不同，ML 系统可以成功完成而不会出现任何错误。然而，真正的问题是它们会产生错误的结果，这些结果只能在评估或测试期间观察到。一些标准的模型测试技术正在检查：

• 输入和模型输出张量的形状；
• 经过一批（或更多批）训练后，损失会减少；
• 在小批量上过度拟合，损失趋近于 0；
• 您的训练流程可以在所有受支持的设备（例如 CPU 和 GPU）上运行；
• 您的早期停止和检查点逻辑有效。

所有测试都在 CI 管道内部触发。如果某些测试成本较高，例如模型测试，则可以仅在特殊情况下执行它们，例如在修改模型代码时。

另一方面，您还可以对模型执行行为测试，该测试尝试采用代码测试中的策略，并将模型视为黑盒，同时仅查看输入数据和预期输出。这使得行为测试方法与模型无关。

该领域的一篇基础论文是“超越准确性：使用 CheckList 对 NLP 模型进行行为测试”，如果您想深入了解该主题，我们推荐您阅读该论文。但是，作为快速概述，该论文建议您针对三种类型的测试来测试您的模型。我们使用一个从句子中提取主要主题的模型作为示例：

• 不变性：输入的变化不应影响输出。例如，下面是一个基于同义词注入的示例：

模型（文本 = “人工智能的进步正在迅速改变世界。”）
# 输出：ai

模型（文本 = “人工智能的进步正在迅速改变世界。”）
# 输出：ai

• 方向性：输入的变化应该影响输出。例如，下面是一个示例，我们知道输出应该根据提供的输入而改变：

模型（文本 = “用于情绪分析的深度学习。”）
# 输出：深度学习

模型（文本 = “用于对象检测的深度学习。”）
# 输出：深度学习

模型（文本 = “用于情绪分析的 RNN。”）
# 输出：rnn

• 最小功能：输入和预期输出的最简单组合。例如，下面是一个包含一组简单示例的示例，我们期望模型始终正确：

模型（文本 = “NLP 是机器学习的下一个浪潮。”）
# 输出：nlp

模型（文本 = “MLOps 是机器学习的下一个浪潮。”）
# 输出：mlops

模型（文本 = “这是关于图神经网络的。”）
# 输出：gnn

有关测试的更多信息，我们建议阅读Goku Mohandas 的《测试机器学习系统：代码、数据和模型》 。

#5. 监控

对于任何投入生产的 ML 系统来说，监控都至关重要。传统软件系统是基于规则和确定性的。因此，一旦构建完成，它就会始终按照定义运行。不幸的是，ML 系统并非如此。

在实施 ML 模型时，我们并未明确描述它们应如何工作。我们使用数据来编译概率解决方案，这意味着我们的 ML 模型将不断面临一定程度的退化。发生这种情况的原因是生产数据可能与模型训练所依据的数据不同。因此，交付的模型不知道如何处理这些情况是很自然的。

我们不应该试图避免这些情况，而应该制定策略来及时发现和修复这些错误。直观地说，监控可以检测到模型的性能下降，从而触发警报，发出信号，提示应手动、自动或两者结合重新训练模型。

为什么要重新训练模型？由于训练数据集和生产输入的偏差导致模型性能下降，唯一的解决方案是在捕获生产中所有新场景的新数据集上调整或重新训练模型。

由于训练是一项成本高昂的操作，因此您可以采取一些技巧来避免重新训练，但在描述这些技巧之前，让我们快速了解我们可以监控什么来了解我们的 ML 系统的健康状况。

日志

记录的方法很简单，就是捕获所有内容，例如：

• 记录系统配置。
• 记录查询、结果和任何中间输出。
• 记录组件的开始、结束、崩溃等时间。
• 确保每个日志条目都经过标记和识别，以明确其在系统内的来源。

虽然捕获所有活动可以迅速增加日志量，但您可以利用多种工具进行自动日志分析和异常检测，利用人工智能有效地扫描所有日志，让您有信心有效地管理日志。

指标

要量化应用程序的健康状况，您必须定义一组指标。每个指标衡量应用程序的不同方面，例如基础架构、数据和模型。

系统指标

系统指标基于监控服务级别指标（延迟、吞吐量、错误率）和基础设施健康状况（CPU/GPU、内存）。这些指标既用于传统软件，也用于机器学习，因为它们对于了解基础设施是否运行良好以及系统是否按预期运行以向最终用户提供良好的用户体验至关重要。

模型指标

仅仅监控系统的健康状况不足以识别模型中更深层次的问题。因此，关注模型性能的下一层指标至关重要。这包括准确率、精确度和 F1 分数等定量评估指标，以及受模型影响的重要业务指标，例如投资回报率和点击率。

分析整个部署期间的累积性能指标通常是无效的。相反，评估与我们的应用程序相关的时间间隔（例如每小时）的性能是必不可少的。因此，在实践中，您可以对输入进行窗口化，并在窗口级别计算和汇总指标。这些滑动指标可以更清楚地反映系统的健康状况，使我们能够更迅速地发现问题，而不会被历史数据所掩盖。

我们可能并不总是能够获得真实结果来评估模型在生产数据上的表现。当存在严重延迟或真实数据需要注释时，这尤其具有挑战性。

为了解决这个问题，我们可以开发一个近似信号来估计模型的性能，或者标记一小部分实时数据集来评估性能。在谈到机器学习监控时，近似信号也称为代理指标，通常由漂移检测方法实现，这将在下一节中讨论。

漂移

漂移是一种代理指标，可帮助我们及时发现生产模型的潜在问题，而无需任何基本事实/标签。表 1 显示了三种类型的漂移。

监控与可观察性

监控涉及数据的收集和可视化，而可观察性则通过检查系统的输入和输出来提供对系统健康状况的洞察。例如，监控使我们能够跟踪特定指标以检测潜在问题。

另一方面，如果系统生成有关其内部状态的有意义的数据，则该系统被视为可观察的，这对于诊断根本原因至关重要。

警报

一旦定义了监控指标，我们就需要一种接收通知的方法。最常见的方法是在以下情况下发送警报：

• 指标超过静态阈值。例如，当分类器的准确率低于 0.8 时，发送警报。
• 调整检查漂移的统计测试的 p 值。较低的 p 值意味着生产分布与参考分布不同的置信度较高。

这些阈值和 p 值取决于您的应用。但是，找到正确的值至关重要，因为您不希望警报系统充斥着误报。在这种情况下，您的警报系统将不值得信赖，并且您会对系统中的问题反应过度或根本不做出反应。

向利益相关者发送警报的一些常见渠道是 Slack、Discord、您的电子邮件和 PagerDuty。系统的利益相关者可以是核心工程师、经理或任何对系统感兴趣的人。

根据警报的性质，您必须采取不同的反应。但在采取任何行动之前，您应该能够检查它并了解其原因。您应该检查触发警报的指标、值是多少、发生的时间以及对您的应用程序有意义的任何其他信息。

当模型的性能下降时，第一个想法就是重新训练它。但这是一个代价高昂的操作。因此，您首先必须检查数据是否有效、模式是否没有改变以及数据点是否不是孤立的异常值。如果两者都不正确，您应该触发训练管道并在新移位的数据集上训练模型以解决漂移问题。

#6. 可重复性

可重复性意味着机器学习系统中的每个流程在给定相同输入的情况下都应产生相同的结果。这主要有两个方面。

第一个是您应该始终知道输入是什么。例如，在训练模型时，您可以使用大量的超参数。因此，您需要一种方法来始终跟踪用于生成新资产的资产，例如用于训练模型的数据集版本和配置。

第二个方面是基于机器学习过程的非确定性。例如，当从头开始训练模型时，所有权重最初都是随机初始化的。

因此，即使使用相同的数据集和超参数，最终得到的模型也可能性能不同。这个问题可以通过在生成随机数之前始终使用种子来解决，因为在现实中，我们无法以数字方式创建随机性，只能创建伪随机数。

因此，通过提供种子，我们可以确保始终生成相同的伪随机数轨迹。如果我们用随机值估算值或随机删除数据或标签，这也可能发生在特征工程步骤中。

但作为一般的经验法则，始终尝试使您的流程尽可能确定性，并且如果您必须引入随机性，请始终提供您可以控制的种子。

结论

本文探讨了 MLOps 核心的 6 个 MLOps 原则，无论您使用什么工具，都应在任何生产级 AI 系统中实施这些原则。