DevOps、DataOps和MLOps：操作化的三波浪潮
在产品中使用机器学习模型很困难。大多数公司未能从这些模型中提取价值，因为它们不能正确地操作模型。
我们已经擅长创建模型并对其进行迭代，但大多数公司仍然没有很好地使用它们。你可以使用的性能可以接受的模式比你不能使用的优秀模式要好。那么，为什么公司在利用它们时会遇到这么多问题呢？
在这篇博客文章中，我们展示了一些挑战类似于DevOps之前的挑战。我们还将展示其他人在开发和操作过程中引入了一个新的层次，需要一个新的堆栈。
这里的经验来自于在Twitter、NVIDIA、Cloudera、Google等公司构建ML产品和平台。这些公司投入巨资构建其内部ML平台或用于各种场景的外部产品。
二十年前，软件开发是痛苦的。开发人员和操作员是竖井，做出任何更改都是一种冒险。DevOps通过一个简单的思维转变帮助我们解决了这个问题：开发人员应该端到端地拥有他们的软件，而运营商应该支持他们。运营商可以专注于构建强大的IT基础设施，而不是单独处理每个应用程序。同时，开发人员可以根据他们的产品需求使用这些工具来加快他们的开发实践。这一变化是操作化的第一波浪潮，它改变了我们做软件的方式。
大约在同一时间，数据开始通过分析变得更加相关。我们的目标是了解公司可以获得的数据。看到DevOps的成功，分析专业人士与他们的运营商合作创建了DataOps。在这种情况下，分析师可以将重点放在他们的业务用例上，而操作员可以使他们的使用变得可靠。
今天，机器学习面临着类似的挑战。ML的目标是帮助产品在现场做出决策。例如，从搜索查询中显示哪些消息。这些应用程序专注于积极改进业务，而不仅仅是提供见解。然而，这些更复杂的应用程序也有我们从未见过的要求，运营界才刚刚开始调整。
对于模型开发人员，我们现在面临着我们以前在软件开发中遇到的类似挑战：
数据科学家并不拥有他们端到端的工作。取而代之的是，他们将他们的模型发送给软件开发人员和数据工程师，以便在个案的基础上构建机器。
数据科学家对满足操作所需的流程视而不见，直到为时已晚。在这种情况下，工作将被放弃或重新完成。
在产品中使用ML模型是其价值的一次巨大飞跃，每一次这样的重大变化都伴随着范式的转变。不仅MLOP对自己很苛刻，而且大多数公司如果做得太天真，今天也不准备这么做。采用MLOPS的挑战归结为：
模型在它们的需求中有更多的维度，并且在每个权衡中操作的范围更广；
您需要为目前不具备开发人员的操作技能的数据科学家提供一个自助式生态系统；
公司使用ML的过程必须从他们今天所在的地方开始，并随着他们使用的进步而适应；
今天，软件开发和模型开发拥有相当成熟的生态系统，并不断快速改进。然而，这些生态系统大多是孤立的。考虑一下基础设施的一个核心部分：工作流系统。软件工程师很可能会使用Jenkins、GitLab、CircleCI或任何类似的工具。但是，数据科学家使用Airflow、Kubeflow和其他以ML为目标的工作流系统。这两个生态系统可能最终会结合在一起，但这可能需要数年时间和大量的努力。相反，我们需要在他们今天所在的地方与他们会面。
从数据科学家的角度来看，他们需要可靠的基础设施。它应该几乎总是以他们想要的方式工作，并提供他们想要使用而不是开发的所有功能。研究人员并不关心哪些工具可以实现这一目标，只要它与他们当前的解决方案一起工作即可。
另一方面，IT提供了一个充满活力的生产力工具生态系统，但它们要求应用程序以特定的方式运行。运营商今天面临的数据科学挑战是，使所有这些实践适应ML生态系统既困难又耗时。因此，他们需要ML应用程序看起来像他们已经支持的应用程序。
这个黄金标准是很难达到的。因此，大多数公司最终都会实施多年的迁移项目，从而同时改变每个人的工作方式。正如您可以想象的那样，这些项目在大多数情况下都会失败。相反，我们需要弄清楚如何让这两个角色首先协作，并从对方那里获得价值。
在现代软件开发中，系统的需求通常很窄，所以工具可以更集中。模型不仅有更多的维度，而且解决方案的放置也更加模糊。
这些只是所考虑的标准维度的几个例子，它决不是一个详尽的列表。请注意，软件通常位于频谱中的清晰点上。例如，您知道应用程序是提供HTTP端点还是在用户的设备上运行。不足为奇的是，对于模特来说，情况通常并非如此。在模型的生命周期中，从构思到在产品中使用，同一模型可能处于需求平衡的不同位置。在使用相同的示例时，由于速度问题，我们可能不会使用终端设备来计算我们的测试指标，而是使用模型作为库。
大多数公司通过为特定案例构建解决方案而忽略其他案例来开始部署模型。然后，他们对其进行一些修补，以适应另一个模型或同一模型的另一个用例。再一次，直到他们最终得到一个难以使用、更改和维护的系统。
在这种情况下，新用户可能会认为从头开始为他们的用例构建自己的用例更容易。这就是有多少公司，包括大型科技公司，如果一不小心，最终会拥有多个内部ML平台。牢记需求的多样性，即使在单个项目中也是如此，这是一项基本但具有挑战性的工作。
DevOps的核心原则之一是开发人员应该端到端地拥有他们的应用程序。要正确做到这一点，运营商需要为其用户提供自助服务机制。它允许IT扩展到多个客户，并消除了等待其他人提供某些工具的延迟。
上图涵盖了大多数公司将在其自助服务平台中拥有的一些功能。它为核心功能提供工具和流程，侧重于提供坚实的基础。同时，开发人员在平台之上定义定制，或者为他们的特定应用程序执行集成。多年来，公司一直在缩小开发人员和操作员之间的距离，从而允许使用较低级别的构造。然而，这对研究人员来说是不够的。
正如我们以前说过的，数据科学家目前的技能集与在生产中提出和操作他们的模型是非常不同的。因此，为研究人员提供的平台需要比为软件开发人员提供的平台更高。例如，开发人员知道如何定义他们的系统行为，以确保其满足特定的SLA。但数据科学家希望明确这些SLA是什么，并依靠一个平台来处理复杂性来实现这一点。
值得庆幸的是，该行业也开始为软件工程师提供更高级别的构造。正如任何人都会怀疑的那样，操作低级定义是一项相当大的开销。但是，您离细节越远，需要在平台中嵌入的领域知识就越多。不幸的是，并不是每个运营团队手头都有这方面的知识来支持ML应用程序。
每个大型软件公司都有一套软件开发流程。这些过程花费了数年时间和多次迭代才能正确开发，其中可能包括代价高昂的错误。当考虑在生产中使用模型时，团队经常面临从头开始构建这些流程的挑战。
然而，在ML之旅的开始阶段，大多数操作约束看起来都类似于进行软件工程。在首先尽可能地调整其当前流程的地方，将ML运营化会取得更高的成功。一旦他们有了初始版本，团队就会在确定与新应用程序域或新产品需求相关的改进时迭代该过程。
流程的这种发展意味着平台和基础设施必须能够与其团队一起适应。随着新法规和客户要求的发展，对模型开发和执行的要求和限制也会随之发展。每次发生这种情况时都要切换到新的系统，这是昂贵的。但依赖外部强制很容易出现错位失败。因此，生产ML需要满足用户当前的需求，在支持其ML方法发展的同时带来即时价值。
对于MLOP来说，这可能是最被低估的挑战：添加模型会为操作堆栈创建一个全新的层。以一种简化的方式，操作堆栈的每个级别涵盖计算单元、事物如何通信，以及它们如何确保它们谈论的是同一件事。
下图显示了众所周知的物理层和分布层。在物理方面，我们主要集中在具体的元素上。我们现在谈论的是具有网线并通过数据包进行通信的机器。主要的故障模式包括数据包丢失、机器停机和路由错误等。但这一层为构建更复杂的系统提供了足够的灵活性。
下一次是当我们有许多服务彼此解耦并随着时间的推移而变化时。人们关注的是这些作品的结构和它们的交流。请注意，堆栈的两个级别并不是相互排斥的；您可以采用部分解决方案并混合它们。但是当你下降一级的时候，你就会失去一些功能。
近年来，随着微服务生态系统变得更加成熟，我们看到这第二层有了相当大的增长。您拥有健壮的服务网格和容器编排，并且您可以使用版本和向后兼容性来设计API，以防止出现其他版本。这种抽象带来了足够的好处，使得Kubernetes、特使和GRPC等工具成为现代基础设施堆栈的核心。
现在，我们的ML应用程序进入了一个新的水平。关注的是结构之上的一个级别：数据的内容本身是至关重要的。我们不仅关心服务器和客户端API是否匹配，而且还关心它们的数据分布是否兼容。众所周知，ML模型在其训练数据的某些范围内运行良好，但在外部运行不佳。输入中的错误数据分布可能与不可用服务一样灾难性(如果我们甚至可以监控它的话)。
这个新的层意味着我们需要一个全新的工具集来覆盖我们今天已经拥有的工具集。导致在物理和分布式级别上开发一般功能的相同操作顾虑推动了在数据级别上进行观察的需要。将此应用层设置为集成状态对于使ML成为产品的另一个组件至关重要。
在Verta，我们正在搭建一个平台，帮助公司以灵活和自动化的方式从他们的模型中提取价值。
正如我们已经强调的，能够与现有解决方案集成对于MLOPS引导至关重要。我们平台的每个组件都可以通过其全面的API集成到现有解决方案中。
我们目前正在与科技公司合作，并与其他公司密切合作，使他们的ML目标成为现实。如果您的团队面临类似的挑战，并且对合作感兴趣，我们很乐意与您交谈！
随着需求的增加，我们也在不断地寻找人才加入我们。如果您想致力于具有挑战性的项目，并处于使ML在产品中成为现实的边缘，请查看我们的招聘页面！