Google MLOps 白皮书（下）|MLOps 过程的深入研究
MLOps工程实践 独家授权转载
Google MLOps 白皮书（上）｜MLOps 生命周期及核心能力
01 MLOps过程的深入研究
本节详细描述了MLOps的每个核心流程。它描述了关键任务以及任务之间的控制流、任务创建的关键工件，以及任务与其他上下游流程的关系。在本节中，您将了解任务的具体细节，如运行持续训练流程、部署模型以及监控模型的预测性能。
MLOps过程在集成的机器学习（ML）平台上进行，该平台具有所需的开发和运维能力（稍后描述）。基础设施工程师可以使用配置管理和基础设施即代码（IaC）工具（如Terraform）在不同的环境（如开发环境、测试环境、模拟环境和生产环境）中提供这种类型的平台。每种环境都配置有一组拥有所需要的计算资源、数据访问和MLOps功能的服务子集。
02 ML开发
实验是ML开发的核心活动，您的数据科学家可以在实验中快速尝试几种数据准备和ML建模的方法。当ML用例定义良好时实验开始，意味着以下问题已经被解答：
- 任务是什么？
- 如何衡量业务影响？
- 什么是评估指标？
- 相关数据是什么？
- 训练和服务要求是什么？
图5 ML开发过程
实验旨在为手头的ML用例获得一个有效的原型模型。除实验外，数据科学家还需要确保其ML训练程序可用于正式生产，这一点通过实施端到端的pipeline来实现，以便程序可以在生产中运行。图5显示了ML开发的过程。
在实验期间，数据科学家通常执行以下步骤：
- 数据发现、选择和探索；
- 通过使用交互式数据处理工具，进行数据准备和特征工程；
- 模型原型开发和验证。
执行这些迭代步骤可以使数据科学家完善问题的定义。例如，您的数据科学家或研究人员可能会将任务从回归改为分类，或者他们可能会选择另一个评估指标。
开发数据的主要来源是数据集和特征仓库。这个仓库包含着精选数据资产（在实体特征级别或完整数据集级别下管理的）。
通常该过程的最成功方面是实验追踪、再现性和协作。例如，当您的数据科学家开始研究ML用例时，如果他们能够找到先前实验（这些实验具有类似用例并可以重现这些实验结果），则可以节省时间；然后，数据科学家可以根据手头的任务调整这些实验。此外，数据科学家需要能够比较各种实验，并比较同一实验的不同运行情况，以便了解导致模型预测行为改变和性能改进的因素。
为了能够复现实验，您的数据科学团队需要跟踪每个实验的配置，包括以下内容：
- 指向版本控制系统中训练代码版本的指针；
- 使用的模型架构和预训练模块；
- 超参数，包括自动超参数调整和模型选择试验；
- 关于使用的训练、验证和测试数据比例的信息；
- 模型评估指标和使用的验证程序。
如果不需要定期对模型进行再训练，则在实验结束时将生成的模型提交给模型注册中心。然后，该模型就可以被审查、批准并部署到目标服务环境中。此外，在模型开发期间生成的所有相关元数据和工件都在元数据追踪仓库中进行追踪。
然而，在大多数情况下，当有新的数据或代码更改时，需要定期重新训练ML模型。在这种情况下，ML开发过程的输出不是在生产中部署模型，相反，输出是实现部署到目标环境的持续训练pipeline。无论您使用code-first，low-code还是no-code工具来构建持续训练的pipeline，开发工件（包括源代码和配置）都必须进行版本控制（例如，使用基于Git的源代码控制系统）。这使您可以将标准软件工程实践应用于代码审查、代码分析和自动化测试，它还允许您构建持续集成/持续部署（CI/CD）工作流，以将持续训练pipeline部署到目标环境。
实验活动通常产生新的特征和数据集。如果新的数据资产可在其他ML和分析用例中重用，则可以通过数据工程pipeline将其集成到功能和数据集仓库中。因此，实验阶段的一个常见输出是对上游数据工程pipeline的要求（见图1）。
图1 数据工程、ML工程和应用工程的关系
总结来看，在ML开发这一过程中产生的典型资产包括：
- 用于实验和可视化的笔记本
- 实验的元数据和工件
- 数据模式
- 训练数据的查询脚本
- 数据验证和转换的源代码和配置
- 用于创建、训练和评估模型的源代码和配置
- 训练pipeline工作流的源代码和配置
- 单元测试和集成测试的源代码
涉及的核心MLOps功能：
- 数据集和特征库
- 数据处理
- 实验
- 模型训练
- 模型注册
- ML元数据和工件仓库
03 训练运维化
训练运维化（Training operationalization）是构建和测试可重复的ML训练pipeline，然后将其部署到目标执行环境的过程。对于MLOps，ML工程师应该能够使用配置来部署ML pipeline。这些配置指定了目标部署环境（开发、测试、模拟环境等）、在每个环境中执行期间要访问的数据源以及用于运行计算工作负载的服务帐户等变量。图6显示了训练pipeline方法的各个阶段。
图6 训练运维化过程
一个pipeline在投入生产前通常要经历一系列测试和模拟线上环境的检验。测试和模拟线上环境的数量因给定组织中建立的标准而异。大多数组织在生产前至少有一个测试环境；有些有更多。
pipeline部署过程的细节取决于用于实施pipeline的技术。对于一些no-code的解决方案，数据科学家和ML工程师无法处理甚至无法看到细节。
或者，如果您使用code-first技术来更灵活地控制ML pipeline，ML工程师可以使用标准CI/CD流程和工具部署pipeline。这种方法就是上图所描述的，该图显示了标准CI/CD工作流，该工作流由以下阶段组成：
- 在CI阶段，对源代码进行单元测试，并构建训练pipeline且对其进行集成测试。构建创建的任何工件都存储在工件仓库中。
- 在CD阶段，已测试的训练pipeline工件被部署到目标环境，在目标环境中，pipeline在发布到生产环境之前经过端到端测试。通常，pipeline在非生产环境中对生产数据子集进行测试，而全面训练仅在生产环境中进行。
- 对新部署的训练pipeline进行冒烟测试(smoke-tested)。如果新pipeline无法生成可部署模型，模型服务系统可以返回到当前训练pipeline生成的模型。
总结来看，训练运维化这一阶段产生的典型资产包括：
- 训练pipeline可执行组件（例如，存储在容器注册表中的容器图像）
- 训练pipeline运行时表示，它引用工件仓库中存储的组件
核心MLOps能力：
- ML pipeline
04 持续训练
持续训练流程是关于协调和自动化训练pipeline的执行。您重新训练模型的频率取决于您的用例以及这样做的业务价值和成本。
例如，如果您使用的ML模型在图像分类方面表现良好，并且如果生成和收集图像的环境没有变化，那么每天根据新数据重新训练模型可能没有什么好处。
另一方面，如果您运营一个具有推荐系统的购物网站，用户行为会不断变化，并且经常对新数据进行再训练，以捕捉新的趋势和模式。这种对再训练的投资可能导致更高的点击率，从而导致潜在的额外购买。
pipeline的每次运行可通过多种方式触发，包括以下方式：
- 基于您配置的任务安排运行；
- 事件驱动运行，例如当新数据在某个阈值以上可用时，或当连续监测过程检测到模型失效时；
- 基于手动调用的特殊运行。
图7 持续训练流程
图7展示了一个典型的pipeline的流程。典型的ML训练pipeline的工作流包括以下内容：
- 数据摄取 使用过滤准则（如最近更新的日期和时间）从源数据集和特征库中提取训练数据。
- 数据验证 对提取的训练数据进行验证，以确保模型未使用分布明显偏移的或损坏的数据。
- 数据转换 数据被拆分，通常分为训练集、验证集和测试集。然后转换数据，并按照模型的预期设计特征。
- 模型训练和调整 训练ML模型，并使用训练集和验证集数据来调整超参数，以产生最佳可能的模型。
- 模型评价 根据测试数据对模型进行验证，以使用数据的不同分区上的各种评估度量来评估模型的性能。
- 模型验证 验证模型评估的结果，以确保模型满足预期性能指标。
- 模型注册 验证的模型与其元数据一起存储在模型注册表中。
如图7所示，持续训练pipeline基于再训练触发器运行。当pipeline启动时，它从数据集和特征库中提取新的训练数据集，执行ML工作流中的步骤，并将训练模型提交给模型注册表。在元数据和工件存储库中追踪整个pipeline运行过程中生成的所有运行信息和工件。
一个精心设计和自动化的训练pipeline反映了在ML开发阶段运行的典型数据科学过程的步骤。然而，自动化pipeline有一些不同。在自动化pipeline中，数据验证和模型验证在实验过程中没有发挥关键作用；这些步骤是整个ML训练过程的守门员。自动pipeline的运行无人值守。因此，随着运行的执行，训练和验证数据会演变，演变的结果可能会导致pipeline执行的数据处理和训练过程不再是最优的，并且可能不再有效。
数据验证步骤可以检测何时开始出现数据异常。这些异常可能包括新特征、新特征域、已消失的特征以及特征分布的剧烈变化。数据验证步骤通过将新的训练数据与预期的数据模式和参考统计数据进行比较来工作。
当观察到候选新模型的性能缺乏改进甚至退化时，模型验证阶段会检测异常。pipeline可在此步骤中应用复杂的验证逻辑，包括若干评估指标、基于特定输入的敏感性分析、校准和公平性指标。
因此，持续训练的一个重要方面是追踪。pipeline运行必须追踪生成的元数据和工件，以实现调试、再现性和谱系分析。
谱系分析意味着能够将经过训练的模型追踪回用于训练该模型的数据集，并链接所有中间工件和元数据。
谱系分析支持以下功能：
- 检索训练期间使用的超参数；
- 检索pipeline执行的所有评估；
- 如果可行，在转换步骤后检索已处理的数据快照。
- 检索数据摘要，如描述性统计、模式和特征分布。
当pipeline运行完成且模型已验证时，pipeline可以在模型注册表中注册模型候选。
自动化的pipeline可以包括部署步骤，有效地充当统一的端到端训练和部署pipeline。在一些用例中，模型每天训练和部署几次（例如每小时一次），训练和部署可以在单个pipeline中实现和简化。在这些情况下，额外的验证被内置到pipeline中，例如模型大小验证、服务运行时有效性（对于依赖项和加速器）以及服务延迟评估。
然而，创建这样一个完整的pipeline可能并不适用于所有组织。例如，在一些组织中，模型训练和模型部署是不同团队的职责。因此，大多数训练pipeline的范围都以注册已训练和已验证的模型为目的，而不是以将其部署到生产环境上为目的。
该过程中产生的典型资产包括：
- 存储在模型注册表中的已被训练和验证的模型；
- 存储在ML元数据和工件仓库中的训练元数据和工件，包括pipeline执行参数、数据统计、数据验证结果、转换数据文件、评估指标、模型验证结果以及训练检查点和日志。
总结来看，持续训练所需要的核心MLOps能力：
- 数据集和特征库
- ML元数据和工件仓库
- 数据处理
- 模型训练
- 模型评估
- ML pipeline
- 模型注册器
05 模型部署
模型经过训练、验证并添加到模型注册中心后，就可以部署了。在模型部署过程中，模型被打包、测试并部署到目标服务环境。与训练运维化阶段一样，模型部署过程可能涉及许多测试步骤和测试环境。在允许将模型部署到目标环境之前，该模型可能需要经过模型治理过程。
下图8显示了模型部署过程的高级视图。
图8 模型部署和渐进交付工作流
当您使用no-code或low-code解决方案时，模型部署过程将从数据科学家和ML工程师的角度进行简化和抽象。通常您指向模型注册中的模型条目，然后使用为该模型存储的元数据和工件自动部署模型。但是，在其他场景中，您可能需要对模型部署过程进行更多控制，因此该过程需要复杂的CI/CD例程。在这种情况下，CI/CD系统从源仓库读取模型服务组件的源代码，并从模型注册表获取模型。系统集成、构建、测试和验证模型serving-service功能，然后通过渐进的交付过程部署服务。图9显示了这个过程。
图9 模型部署过程的复杂CI/CD系统
在模型部署的CI阶段，测试可能包括测试模型接口，以查看其是否接受预期输入格式，以及是否生成预期输出。您还可以验证模型与目标基础结构的兼容性，例如检查所需的包和加速器。在此阶段，您还可以检查模型的延迟是否可接受。
在模型部署的CD阶段，模型逐步交付。金丝雀部署、蓝绿部署和影子部署通常用于执行冒烟测试，冒烟测试通常侧重于模型服务效率，如延迟、吞吐量以及服务错误。在您从技术角度验证模型有效后，您将通过逐渐将其与现有模型一起使用并运行在线实验来测试模型在生产中的有效性，这意味着使用实时流量在生产中测试新功能。
在线实验在ML环境中尤为重要。与部署其他软件资产相比，决定新的候选模型是否应替代目前生产中使用的这个模型版本是一项更为复杂和多维的任务。
在渐进交付方法中，新的候选模型不会立即替换先前的版本。相反，在新模型部署到生产环境后，它将与以前的版本并行运行。根据在线实验，一部分用户分阶段重定向到新模型。实验的结果是决定该模型是否可以完全发布并替代先前版本的最终标准。A/B测试和多臂老虎机（MAB）测试是常见的在线实验技术，可用于量化新模型对应用程序级目标的影响。金丝雀部署和影子部署方法可以促进此类在线实验。
总结来看，模型部署过程中产生的典型资产包括：
- 模型服务可执行应用程序（例如存储在容器注册表或存储在工件仓库中的Java包）
- 存储在ML元数据和工件仓库中的在线实验评估指标
核心MLOps能力：
- 模型服务
- 模型注册
- 在线实验
- ML元数据和工件仓库
06 预测服务
在预测服务过程中，模型部署到其目标环境后，模型服务开始接受预测请求（服务数据），并使用预测服务响应。图10显示了预测服务的元素。
图10 预测服务流程的要素
服务引擎可以下列形式向消费者提供预测：
- 使用REST或gRPC等接口，对高频单次请求（或小批量请求）进行近实时在线推理；
- 近实时的流式推理，例如通过事件处理pipeline；
- 批量数据评分的离线批量推理，通常与提取、转换和加载（ETL）过程集成；
- 嵌入式推理作为嵌入式系统或边缘设备的一部分。
在预测服务的某些场景中，服务引擎可能需要查找与请求相关的特征值。例如，您可能有一个模型，在给定一组客户和产品特征的情况下，预测客户购买特定产品的倾向。但是，请求仅包括客户和产品标识符。因此，服务引擎使用这些标识符从特征库中提取客户和产品特征值，然后将其输入模型以生成预测。
对ML系统有信心的一个重要部分是其能够解释模型并为其预测提供解释。解释应提供对预测基本原理的洞察，例如，通过为给定预测生成特征属性。特征属性以分数的形式表示每个特征对预测的贡献程度。
推理日志和其他服务度量被存储用于持续监控和分析。
总结来看，预测服务这一过程中产生的典型资产包括：
- 服务日志存储中存储的请求响应有效载荷；
- 预测的特征属性。
核心MLOps能力：
- 数据集和特征库
- 模型服务
07 持续监控
持续监控是在生产中监控模型的有效性和效率的过程，这是MLOps的一个关键领域。定期和主动地验证模型性能是非常重要的。随着生产环境中的数据随时间变化，其属性开始偏离用于训练和评估模型的数据属性，这可能会导致模型的有效性能下降。此外，产生预测请求的上游系统中的变化或错误可能导致数据属性的变化，从而从模型中产生错误的预测。
监控引擎使用推理日志来识别异常（偏差和异常值），如图11所示。
图11 持续监控过程
典型的持续监控过程包括以下步骤：
- 捕获请求响应有效载荷的样本并将其存储在服务日志存储中。
- 监控引擎定期加载最新的推理日志，生成数据库，并计算服务数据的统计量。
- 监控引擎将生成的数据库与参考数据库进行比较，以识别数据库偏差，并将计算的统计与基线统计进行比较以确定分布偏差。
- 如果服务数据的真实标签（ground truth）可用，那么事后监控引擎使用它来评估模型在服务数据上的预测有效性。
- 如果发现异常，或者模型的性能正在衰退，可以通过各种渠道（例如电子邮件或聊天）发送警报，通知所有者检查模型或触发新的再训练。
有效的性能监控旨在检测模型衰减。模型衰减通常根据数据和概念漂移来定义。数据漂移描述了用于训练、调试和评估模型的数据集与实际生产环境中的数据之间的偏差。概念漂移指的是“输入”和“目标变量”之间的关系随着时间的流逝而产生变化的现象。
数据漂移可能涉及两种类型的偏差：
- 当训练数据和服务数据不符合同一数据库结构时，会出现数据库结构扭曲。
- 当训练数据的特征值分布与服务数据的分布显著不同时，会出现分布偏斜。
除了识别数据库结构和分布偏差外，检测数据和概念漂移的其他技术包括新颖性（novelty）和outlier检测，以及特征属性变化。
在某些情况下，您的系统能够存储服务数据的真实情况。例如，您可以捕获客户是否购买了模型推荐的产品，或者与模型预测的需求相比，您计算了一周结束时特定产品的实际需求。您可以将此信息用作服务数据的真实标签，并且可以从数据集和特征仓库中存储和检索这些信息，以进行连续评估和改进进一步的模型训练周期。
除了监控模型有效性外，监控模型服务效率还关注以下指标：
- 资源利用率，包括CPU、GPU和内存；
- 延迟，这是在线和流式部署中表示模型服务健康状况的关键指标；
- 吞吐量，这是所有部署中的一个关键指标；
- 错误率，测量这些指标不仅有助于维护和改进系统性能，而且有助于预测和管理成本。
总结来看，持续监控这一过程中产生的典型资产包括：
- 漂移检测期间服务数据中检测到的异常；
- 持续评估产生的评估指标。
核心MLOps能力：
- 数据集和特征库
- 模型监测
- ML元数据和工件仓库
08 数据和模型管理
前面概述的六个过程的核心是数据和模型管理。这是管理ML工件的中心功能，以支持可审计性、可追踪性和合规性，以及ML资产的可共享性、可复用性和可发现性。
数据集和特征管理
数据科学和ML的关键挑战之一是创建、维护和复用用于训练的高质量数据。数据科学家将大量ML开发时间用于数据分析、数据准备和数据转换。然而，其他团队可能已经为类似的用例准备了相同的数据集，但没有共享和复用它们的方法。这种情况不仅会浪费时间重新创建数据集，还会导致相同数据实体的定义和实例不一致。
此外，在预测服务期间，常见的挑战是服务数据和训练数据之间的差异，这被称为训练服务偏差，这可能会发生。因为在训练和服务期间，数据以不同的形式从不同的来源提取。训练服务偏差影响模型在生产中的性能。
数据集和功能管理通过为ML功能和数据集提供统一的仓库，帮助缓解此类问题。图12显示了功能和数据集仓库如何为MLOps环境中的多种用途提供相同的数据实体集。
图12 使用数据集和特征仓库为多种用途提供实体
如图所示，特征和数据集在不同的实验中被创建、发现和复用。数据的批量服务用于实验、持续训练和批量预测，而数据的在线服务用于实时预测用例。
特征管理
特征是基于标准业务规则聚合、派生等清理和准备的业务实体的属性。实体的示例包括产品、客户、位置和促销。您可以在集中式仓库中管理数据实体，以标准化其定义、存储和访问，以便进行训练和服务。
特征仓库可帮助数据科学家和研究人员完成以下工作：
- 发现并复用其实体的可用特征集，而不是重新创建实体以创建自己的数据集；
- 建立特征的中心定义；
- 通过使用特征库作为实验、持续训练和在线服务的数据源，避免训练服务偏差；
- 提供特征仓库中的最新特征值；
- 提供定义和共享新实体和功能的方法；
- 通过共享功能改善数据科学和研究团队之间的协作。
在批处理ETL系统中，训练pipeline可以将特征作为训练任务的批处理进行检索。对于在线服务，服务引擎可以获取与请求实体相关的特征值，可以从批处理ETL或流系统获取对特征仓库的更新。除了这些更新之外，监控服务还可以更新这些特征的统计数据和度量。
数据集管理
特征可以在多个ML任务和用例的许多数据集中使用，而数据集只能用于特定的ML任务或用例。更准确地说，特征仓库通常不包括标记的数据实例（具有可预测目标的实例）。
相反，它们包括各种实体的可复用特征值。为了创建数据集，可以将不同实体的特征与包含标签的其他事务数据组合并连接。例如，特征仓库可能包含一个客户实体，该客户实体包括描述客户人口统计、购买行为、社交媒体交互、情绪得分、第三方财务标志等的功能。
客户实体可用于多个任务，如客户流失预测、点击率预测、客户生命周期价值估计、客户细分和推荐。每个任务都有自己的数据集，其中包含与任务相关的实体的客户特征和其他特征。此外，对于监督学习任务，每个数据集都有自己的标签。
数据集管理有助于实现以下功能：
- 维护用于创建数据集和拆分的脚本，以便在不同环境（开发、测试、生产等）中创建数据集。
- 在团队内维护单个数据集定义和实现，以用于各种模型实现和超参数。该数据集包括拆分（训练、验证、测试等）和过滤条件。
- 维护元数据和注释，这些元数据和注释对于在同一数据集和任务上协作的团队成员非常有用。
- 提供再现性和族系跟踪。
模型管理
随着组织规模不断增加，生产中的模型数量越来越多，手动追踪所有模型变得越来越困难。组织需要控制，以管理风险和实施ML模型责任，并保持法规遵从性。
为了帮助完成这项任务，组织需要建立稳健的模型管理。模型管理是一个贯穿各领域的过程，是MLOps的核心。它需要ML元数据追踪和模型治理。
在ML生命周期中进行模型管理有助于确保：
- 正在收集且用于模型训练和评估的数据是准确、无偏的，并且使用得当，没有侵犯任何数据隐私；
- 根据有效性质量度量和公平性指标对模型进行评估和验证，以便适合在生产中部署；
- 模型是可解释的，其结果是可以解释的（如果需要）；
- 使用持续评估监测已部署模型的性能，并追踪和报告模型的性能指标；
- 模型训练或预测服务中的潜在问题是可追踪、可调试和可复现的。
机器学习元数据跟踪
图13 元数据跟踪
ML元数据追踪通常与不同的MLOps过程集成在一起。其他流程生成的工件通常与有关流程执行的信息一起自动存储在ML工件库中。捕获的ML元数据可以包括pipeline运行ID、触发器、流程类型、步骤、开始和结束日期、时间、状态、环境配置和输入参数值。存储的工件示例包括已处理的数据拆分、数据库结构、统计、超参数、模型和评估度量或自定义工件。图13显示了元数据追踪。
ML元数据追踪使数据科学家和ML工程师能够追踪实验参数和pipeline配置，以确保复现性和追踪的沿袭性。此外，ML元数据追踪允许用户搜索、发现和导出现有的ML模型和工件。
数据科学家和ML工程师可以使用ML元数据追踪向被追踪的ML实验和运行过程添加和更新注释。此外，ML元数据追踪提供了分析、比较和可视化不同实验和ML pipeline运行的元数据和工件的工具。这有助于数据科学家和ML工程师了解pipeline的行为并调试ML问题。
模型治理
模型治理是关于注册、审查、验证和批准部署模型的。根据团队、模型的监管要求和特定用例，模型治理过程可能有所不同。该过程可以是自动化、半自动化或全自动化的（在所有情况下都有多个发布标准），以确定ML模型是否准备好投入生产。此外，模型治理应支持报告已部署的模型性能。
图14 模型治理中涉及的任务
模型治理可以使用ML元数据和模型注册表中的信息执行以下任务：
- 存储 添加或更新模型属性，并追踪模型版本和属性更改。模型注册表可以存储来自实验和持续训练阶段的许多模型版本，这使数据科学家能够轻松地复制重要模型。
- 评估 不仅查看评估指标（准确性、准确性、召回率、特异度等），而且查看在线实验收集的业务KPI，将新的有竞争力的模型与已部署的模型进行比较。此外，模型所有者需要能够理解和解释模型预测，例如通过使用特征属性方法。这确保了在生产中部署的模型的质量。
- 检查 审查、请求更改和批准模型，以帮助控制风险，如业务、财务、法律、安全、隐私、声誉和道德问题。
- 发布 调用模型部署过程用于上线模型。这控制了模型发布的类型（例如，金丝雀或蓝绿）和指向它的流量拆分。
- 报告 汇总、可视化和突出显示从持续评估过程中收集的模型性能指标。这确保了模型在生产中的质量。
在决策自动化的情况下，可解释性尤为重要。该过程还应使他们能够根据组织的道德和法律责任审查决策。
总结
通过ML交付业务价值不仅仅是为手头的用例构建最佳ML模型。实现这一价值还涉及构建一个持续运行的集成的ML系统，以适应业务环境动态变化。这种ML系统涉及收集、处理和管理ML数据集和特征；在规模上训练和评估模型；为模型提供预测服务；监测模型在生产中的性能；以及追踪模型元数据和工件。
在本文档中，我们讨论了构建和操作ML系统的核心能力，并描述了一个全面的MLOps流程，以简化从开发到生产的工作流程。这可以帮助企业缩短产品上市时间，同时提高其ML系统的可靠性、性能、可扩展性和安全性。
图15 端到端的MLOps工作流
END
本文翻译自Google MLOps白皮书：MLOps实践者指南
欢迎关注公众号，获取最新的MLOps信息
