MLOps成熟度的5个级别
介绍
建立稳定的ML系统基础设施非常重要。它需要确保ML应用程序的开发和部署是有组织和可靠的。但是，每个公司的基础设施需求都是不同的。这取决于他们拥有多少ML应用程序，需要多快部署，或者需要处理多少请求。
例如，如果公司只有一个模型在生产中，部署过程可以手动处理。另一方面，像Netflix或Uber这样在生产中拥有数百个模型的公司需要高度专业化的基础设施来支持它们。
现在，您可能会问自己一个问题：您的公司在这个范围内属于哪个级别？
谷歌和微软分享的MLOps成熟度水平可以帮助您。它们基于行业最佳实践描述了ML基础设施的先进性和复杂性。
本博客旨在综合并吸收谷歌和微软的最佳实践。首先，我们将分析五个成熟度级别，并展示从手动过程到高级自动化基础设施的进展。然后，在最后一节中，我们将论述不应盲目遵循微软和谷歌提出的一些观点，而是应根据您的需求进行调整。这应该可以帮助您更加清楚地了解自己的基础设施状况，并找到潜在的改进领域。
好的，让我们开始吧！
什么是MLOps？
MLOps是一组实践，旨在建立标准化和可重复的流程，用于管理整个ML生命周期，从数据准备、模型训练、部署和监控开始。它借鉴了软件工程中广泛采用的DevOps实践，旨在为团队提供快速和持续迭代的方法来发布软件应用程序。
但是，DevOps工具并不足以支持ML世界，并在几个方面有所不同：
- MLOps需要一个具备多种技能的跨学科团队。该团队包括负责数据收集和存储的数据工程师，开发模型的数据科学家，部署模型的机器学习工程师(MLE)以及将其与产品整合的软件工程师。
- 数据科学本质上是实验性的，允许通过探索不同的模型、数据分析、训练技术和超参数配置进行持续改进。支持MLOps的基础设施应包括跟踪和评估成功和不成功的方法。
- 即使模型在生产中运行良好，由于输入数据的变化，它仍可能失败。这称为静默模型失败，由数据和概念漂移引起。因此，ML基础设施需要一个监控系统，不断检查模型的性能和数据，以预防此问题。
现在让我们探索MLOps基础设施的各种成熟度级别。
1级 — 手动
在此级别，数据处理、实验和模型部署过程完全手动。微软将其称为“无MLOps”，因为ML生命周期难以重复和自动化。
整个工作流程严重依赖技能娴熟的数据科学家，有时需要数据工程师准备数据，软件工程师将模型与产品/业务流程集成。
这种方法在以下情况下非常有效：
- 早期创业公司和概念验证项目 —— 重点是实验和资源有限。在扩大运营之前，开发和部署ML模型是主要问题。
- 小规模ML应用程序 —— 对于范围有限或用户基数较小的ML应用程序，手动方法可能足够，例如小型在线时装店。在最小的数据依赖和实时要求下，数据科学家可以手动处理数据处理、实验和部署过程。
- 特定的ML任务 —— 在特定的情况下，如市场营销活动，一次性ML任务或分析可能不需要完整的MLOps实施。
根据谷歌和微软的说法，这种方法也面临着几个限制，包括：
- 缺乏监控系统——模型的表现没有可见性。如果模型下降，将会对商业产生负面影响。此外，在部署后需要进行数据科学，以了解模型在生产中的行为。
- 生产模型没有经常重新训练——模型无法适应最新的趋势或模式。
- 发布是痛苦和不频繁的——由于是手动进行的，模型的发布每年只会发生几次。
- 没有集中跟踪模型性能，这使得难以比较不同模型的性能、重复结果或更新模型。
- 文档受限且没有版本控制——在风险引入意外更改的风险、回滚到工作版本的能力受限以及缺乏可重复性方面存在一些挑战。
第二级——可重复
接下来，我们通过将实验转换为源代码并使用像 Git 这样的版本控制系统将其存储在源代码库中，引入了 DevOps 方面的基础架构。
微软建议通过添加以下内容来改变数据收集过程：
- 数据管道——允许从不同的源提取数据并将它们组合在一起。然后，使用清理、聚合或过滤操作转换数据。它使基础架构比手动更可扩展、高效和准确。
- 数据目录——一个集中的存储库，包括数据源、数据类型、数据格式、所有者、用途和血统等信息。它有助于以可扩展和高效的方式组织、管理和维护大量数据。
为了升级基础架构，我们必须引入一些自动化测试和版本控制。这意味着使用像单元测试、集成测试或回归测试这样的实践。这些将帮助我们更快地部署，通过确保我们的代码更改不会导致错误或漏洞，使事情更加可靠。
有了所有这些变化，我们可以重复数据收集和部署过程。然而，我们仍然需要一个适当的监控系统。微软简要提到了它，说“模型在生产中的表现情况反馈受限”，但他们没有详细说明。
第三级——可再现
可再现性至关重要的两个原因是故障排除和协作。想象一种情况，当你最近部署的模型的性能下降时，导致预测不准确。在这种情况下，您需要记录以前版本的数据和模型，以回滚到模型的其他版本，直到找到潜在问题的根本原因。
此外，可再现性使不同的团队成员更容易理解其他人在做什么，并建立在彼此的工作基础上。这种协作方法和知识共享可以促进更快的创新和更好的模型。
为了实现可再现性，我们必须通过四种方式升级体系结构：
- 自动化培训流水线——处理从数据准备到模型评估的训练模型的端到端过程。
- 元数据存储——数据库是跟踪和管理元数据的一种方式，包括数据源、模型配置、超参数、训练运行、评估指标和所有实验数据。
- 模型注册表——是存储 ML 模型及其版本和部署所需的工件的存储库，有助于在需要时检索精确版本。
- 特征存储——它可以帮助数据科学家和机器学习工程师更高效地开发、测试和部署机器学习模型，提供了集中存储、管理和提供特征的位置。它还可以用于跟踪特征随时间的演变，并根据需要预处理和转换特征。
在这个阶段，监控服务可用，可以提供模型性能的实时反馈。然而，除了确认它存在，微软和谷歌都没有提供任何额外的信息。
第四级 — 自动化
这个自动化级别帮助数据科学家通过自动化机器学习流程，包括构建、测试和部署，高效地探索特征工程、模型架构和超参数的新想法。为了实现这一点，微软建议加入两个额外的组件：
- CI/CD —— 持续集成（CI）确保来自不同团队成员的代码更改被集成到共享存储库中，而持续部署（CD）自动化验证代码部署到生产环境。这允许快速部署模型更新、改进和错误修复。
- 模型的A/B测试 —— 这种模型验证方法涉及比较现有模型和候选模型之间的预测和用户反馈，以确定哪个更好。
第五级 — 持续改进
在这个阶段，模型会根据监控系统的触发自动重新训练。这个重新训练的过程也被称为持续学习。持续学习的目标是：
- 对抗突发数据漂移，确保模型即使面对数据的意外变化仍然有效。
- 适应罕见事件，例如黑色星期五，在这种情况下，数据中的模式和趋势可能会显著偏离正常。
- 克服冷启动问题，当模型需要对缺乏历史数据的新用户进行预测时出现。
推进自动化
微软和谷歌是云计算市场的主要参与者，Azure占有22%的市场份额，谷歌占有10%。它们提供广泛的服务，包括计算、存储和开发工具，是构建先进的ML基础设施的必要组成部分。
像任何企业一样，它们的主要目标是通过销售这些服务来产生收入。这部分原因是它们的博客强调进步和自动化。然而，更高的成熟度并不保证您的业务获得更好的结果。最优解决方案是与您公司具体需求和正确的技术栈相符的方案。
虽然成熟度水平可以帮助确定当前的进展，但不应盲目遵循，因为微软和谷歌的主要动机是出售它们的服务。一个例子是它们特别推进的自动重新训练。这个过程需要大量计算，但通常是不必要或有害的。重新训练应在需要时进行。对于您的基础设施来说，更重要的是拥有可靠的监控系统和有效的根本原因分析过程。
监控应从手动级别开始
在所描述的成熟度水平中，有一个有限的监控系统出现在第2级。实际上，应该在基于模型输出做出业务决策之后立即监控模型，而不考虑成熟度水平。这可以让您减少失败的风险，并了解模型在实现您的业务目标方面的表现。
监控的初始步骤可能仅是将模型的预测与实际值进行比较。这种基本比较是模型性能的基线评估，也是模型失败时进一步分析的好起点。此外，考虑评估数据科学工作的价值，包括衡量投资回报率（ROI）。这意味着评估数据科学技术和算法为业务带来的价值。了解这些努力在产生业务价值方面的有效性非常重要。
评估ROI可以为您提供洞见和信息，帮助您做出更好的决策，包括分配资源和规划未来投资。随着基础设施的发展，监控系统可以变得更加复杂，具有额外的功能和能力。然而，在成熟度的第一级别上应用基本的监控设置仍然很重要。
重新训练的风险
在第五级的描述中，我们列出了在生产中自动重新训练的好处。但在将其添加到您的基础架构之前，您应考虑与之相关的风险：
- 延迟数据上的重新训练
在某些实际情况下，例如贷款违约预测，标签可能会延迟数月甚至数年。真相仍在到来，但您正在使用旧数据重新训练模型，这可能无法很好地代表当前现实。
2. 未能确定问题的根本原因
如果模型的性能下降，这并不总是意味着它需要更多数据。模型失败可能有各种原因，例如下游业务流程的变化、训练-服务偏差或数据泄漏。您应首先调查以找到潜在问题，然后在必要时重新训练模型。
3. 更高的失败风险
重新训练会放大模型失败的风险。除了它增加了基础设施的复杂性外，更新的频率越高，模型失败的机会就越多。数据收集或预处理中出现的任何未检测到的问题都将传播到模型，导致在有缺陷的数据上重新训练模型。
4. 更高的成本
重新训练不是一个无成本的过程。它涉及到以下费用：
- 存储和验证重新训练数据
- 计算资源来重新训练模型
- 测试新模型以确定其是否比当前模型表现更好
总结
机器学习系统很复杂。以可重复和可持续的方式构建和部署模型很困难。在本博客文章中，我们根据谷歌和微软在行业中的最佳实践，探讨了五个MLOps成熟度级别。我们讨论了从手动部署到自动化基础架构的演变，突出了每个级别带来的好处。但是，重要的是要了解这些实践不应盲目遵循。相反，它们的适应应基于您公司的具体需求和要求。
