2021-05-14

31个检查不同水平的机器学习操作成熟度的只标

本文来自Bruce H. Cottman博士，为读者的机器学习操作（MLOps）工作提供了一份备忘录。

以下为作者自述：

作为人工智能1.0浪潮（1983-1987）的一部分，我觉得人工智能要有实际用途，就必须进行分发。从那以后，我一直在构建分布式操作系统。

我承认，我在2016年遇到Kubernetes时就停了下来，因为从软件架构师和工程师的角度来看，我可以添加的内容很少。

是的，我认为Kubernetes是一个很好的分布式操作系统体系结构，适用于从云虚拟机（vm）到Rasberry Pis。

大约九年前，在AI 2.0激增（2012年至今）期间，我回到了机器学习领域。

注：AI 2.0运动在2012年之前就开始了，但我在2012年开始将R应用于机器学习应用程序时使用了它。

2016年，我开始专注于构建并推出基于手动机器学习的应用程序。

在过去的五年中，我看到了培训和将机器学习应用程序（ML应用程序）部署到生产中。在这段时间里。我目睹了从手工制作的一次性ML应用程序到使用自动化工具和流程部署的自动化服务的巨大转变。

我四处寻找机器学习操作（MLOPs）过程的清单。一开始，我使用十二要素应用程序作为MLOps成熟度检查表。

我逐渐扩展了我的MLOPs成熟度（或推出）清单，现在我将与大家分享。

我的MLOps清单

MLOps是一组过程和工具，有助于确保机器学习模型在生产中的表现符合构建模型的人的期望。-Craig Wiley，谷歌云人工智能服务的首席产品经理，曾在亚马逊担任SageMaker负责人。

我知道我已经提到库伯内特斯了。为我辩护，我对机器学习应用程序所做的一切都在Kubernetes上。

在大多数情况下，如果您使用Kubernetes以外的东西作为分布式操作系统，那么清单仍然适用。

我不认为Kubernetes是MLOps工具。在这篇博客文章中，我尽量不提及特定的MLOps工具或解决方案。有时这是无法避免的。

所有MLOps检查清单项目按顺序编号，并除以五个MLOps成熟度级别。每一个成熟度等级都概述了我与该等级相关的症状。

我使用的成熟度级别大致遵循Microsoft机器学习操作成熟度模型。

我（有争议地）认为苹果、谷歌、IBM和微软已经达到了MLOps成熟度4级。

如果你想推荐其他候选人，请把他们留在评论部分。

MLOps成熟度级别0

症状是：

开发、测试、安全、系统操作和其他角色分为同质筒仓；

代码不受版本控制；

手动构建和部署；

代码的手工测试；

还有更多。

你应该做什么（1项检查清单）：

1.为每个MLOps过程步骤选择一个工具；

在每个MLOps成熟度级别上尽可能多地使用。在接下来的几年里，你应该预料到MLOP会非常混乱和混乱。

注：IMHO。不要在MLOps治理研究上花费x百万美元。我知道，这很难避免，因为治理研究是在xEO级别上进行的。智能手机的企业治理研究是什么时候完成的？我希望智能手机治理研究不是最初完成的，而是随着智能手机渗透到整个组织，各级员工都获得了使用智能手机的经验。

我概述了机器学习操作（MLOps）的一般步骤。您的组织可能有更多和/或不同的步骤。

数据提取；

数据挖掘；

数据版本控制；

模型训练；

模型试验；

（模型调试）；

训练模型版本控制；

模型部署；

日志模型部署

部署安全监控；

模型测井；

模型偏差监控。

模型数据漂移监测；

模型负载、资源使用和成本监控；

模型安全监控；

其他类型的监控。

在任何计算操作（Ops）中，我都把额外的精力放在测试和监控上。为什么？因为在我从事软件工程的这几年里，测试已经到了软件过程生命周期成熟的末期。

机器学习已经有十多年的历史了。似曾相识！仅在过去几年中，监测和测试才是MLOP成熟的一部分。

NeurIPS研讨会在2020年发表的一篇调查文章详细介绍了将机器学习应用到生产中的步骤。

MLOps成熟度级别1

可能是：

从数据提取到ML应用程序部署的所有步骤都不存在版本控制；

你应该做什么（5项检查清单）：

2.每个服务使用一个共享代码库。

3.所有代码，包括配置文件，都是版本控制的。

4.自动代码生成。

5.自动代码单元测试。

6.建立完整的DevOps流程。

MLOps成熟度等级2

症状可能是：

该项目从一个成熟的开发运营（DevOps）开始。DevOps是一个很好的症状，也是MLOps过程的一个很好的基础。

ML应用程序管道的大多数步骤都是手动的；

人工优化ML模型；

人工培训、测试和验证ML模型；

没有对ML模型训练、测试和性能验证的集中跟踪；

无法再现或难以再现ML模型结果。

人工测试ML模型和ML应用；

ML模型训练的有限跟踪、监视和记录；

MLOps成熟度级别3的解决方案有（8个检查表项）：

7.给定一个固定的随机种子，所有的学术服务输出都是可复制的。

8.从数据提取到模型验证的模型训练管道是可重复的，几乎完全自动化。

9.ML模型训练的跟踪、监视和记录。

10.跟踪模型训练优化；

11.跟踪模型培训、测试和验证指标；

12.数据集受版本控制。

我有时称之为数据操作（DataOps）。DataOps工具已经足够成熟了，我建议购买而不是构建。

13.所有的学习模型版本，甚至还在开发中的模型，都是版本控制的。

有关于模型店的报纸。模型店有开源项目，商业模型店产品也出现了。

14.数据（元数据）的特性受版本控制(（可选）

最好使用功能存储库（repository）

如果你有大量不同的数据；

或者有许多使用不同数据子集的ML模型；

或者数据集随时间而变化；

或者从ML模型到数据集的再现性和审计跟踪需要它。

有一个为功能商店开发的标准。有一个功能商店的开源项目，商业功能商店产品已经出现。

MLOps成熟度等级3

3级症状需要解决：

ML模型团队负责从数据提取到ML模型验证的ML模型步骤。ML模型随后被“扔到墙上”，由其他团队投入生产；

从数据提取到生产ML应用没有或有限的审计跟踪；

对生产应用程序的监控有限或没有；

未检测到数据漂移。

ML应用程序不跨计算资源分布；

ML应用程序的部署是手动的，不被跟踪；

从部署到原始数据没有完全的可追溯性（审计跟踪）

MLOps成熟度级别3的解决方案是（11个检查表项）：

15.自动构建和部署生产ML应用程序。

16.将计算资源抽象到虚拟机（VM）中。

计算资源可以包括但不限于cpu、内存、存储器、操作系统和IP地址。

将物理机引擎转换为虚拟机可以抽象出独立于操作系统的机器资源。

17.将计算逻辑抽象为虚拟服务（VSs）。

将任何工具、应用程序、服务或微服务及其依赖项放入软件容器中。

在过去的六年里，我在本地的开发人员机器上使用了VM和VS容器（Docker），避免了名称空间的冲突。

没有VM和VS容器，具有多个组件的分布式操作系统就无法扩展。

18.显式声明和隔离代码、ML模型和基础设施依赖关系；

19.如果可能，将单片应用程序转换为服务，将服务转换为微服务。

20.为分布式计算资源网络使用分布式操作系统。

21.将应用程序作为一个或多个无状态进程执行(（可选）

22.利用复制的虚拟服务实现可伸缩性。

23.使用可恢复的虚拟服务实现容错。

24.通过端口绑定导出服务。

端口绑定再次成为编码最佳实践。在Kubernetes中，端口绑定称为端点，很少显式处理端点。

在某个时候，我可能会从我的MLOps清单中删除这个项目。

25.基础结构代码和基础结构环境变量在版本控制中。

MLOps成熟度级别4

你可能想进入第四级，希望降低成本，完全自动化，以及更多的控制感。

然而，当您达到MLOps成熟度级别3时，您就进入了当今企业的前1%。

注：统计数据是根据我的经验估计的。我还没有在一个组织是在MLOps成熟度级别3。我读过一些文章或看到一些开源代码，这些文章或代码使我相信一些组织处于MLOps成熟度级别3或MLOps成熟度级别4。

那些每周有许多用户或几个部署的组织需要达到MLOps成熟度级别4。

MLOps成熟度级别4的解决方案有（6个检查表项）：

26.企业MLOPS治理研究开始了。

27.最小化开发和生产代码阶段之间的差异。

28.将日志视为事件流。

除了事件流之外，您没有其他选择来实现日志。您可以选择无序或有序的多进程日志事件流。

在某个时候，我可能会从我的MLOps清单中删除这个项目。

29.使用声明性语句解析器（格式）实现更改管理自动化。

30.在MLOP下扩展组件，而不需要对工具、架构或开发实践进行重大更改。

31.通过在云平台上部署来优化成本。

减少本地服务器和系统管理人员的工作量应该证明是一种高成本和省时的做法。

摘要

我随意地将清单项目划分为MLOps成熟度级别。上面的MLOps指南并不是为了在进入下一个之前达到一个MLOps成熟度级别。

相反，您可能会发现您可以在不同的MLOps成熟度级别检查各种“to-dos”，其中一些“to-dos”是不必要的，或者不是您当前需要的优先事项。