在过去几年中，人工智能和机器学习（ ML ）在主流企业中的角色发生了变化。一旦研究或高级开发活动，它们现在为生产系统提供了重要的基础。
随着越来越多的企业寻求用人工智能和 ML 改造业务，越来越多的人在谈论 MLOps 。如果你一直在听这些对话，你可能会发现几乎所有参与的人都同意你需要一个 MLOps 战略来将 ML 投入生产。
本文简要概述了企业 MLOps 。要了解更多信息，请与我一起参加 NVIDIA GTC 2023 的 Enterprise MLOps 101 ，这是对企业 MLOps 环境的介绍。我将与我的同事迈克尔·巴林特一起介绍会议。
为什么 MLOps 令人困惑
MLOps 对话令人困惑，主要原因如下。
MLOps 范围广泛
MLOps 是一个宽泛的术语，描述了使组织能够设计、开发和维持生产 ML 系统的技术、流程和文化。几乎任何与常规软件开发、数据管理或与生产 ML 系统相关的商业智能 could be 相关的工具或系统。
由于 MLOps 是一个热门话题，因此许多与生产 ML 系统相关的此类工具和系统已重新命名，以强调其与 MLOps 的联系。
MLOps 是多样化的
机器学习系统是复杂的软件系统。不同的组织和从业者将采取不同的方法来管理这种复杂性，就像他们管理构建和维护传统软件系统的复杂性一样。
然而，由于组织在构建传统软件的过程中并没有构建生产 ML 系统，因此标准化方法尚未建立。用于描述这些系统的语言以及评估这些系统的标准也缺乏标准化。
当不同的人谈论 MLOps 时，可能会感到困惑，因为他们可能在描述问题空间的不同部分。例如，对其用例、行业或组织流程和工具最重要的部分。
MLOps 很复杂
MLOps 非常复杂。然而，由于经验丰富的 MLOps 从业者和组织专注于其特定方法和工具的细节，他们倾向于强调其复杂性。问题的一部分是，在生产机器学习这样的不断发展的领域中，很难弄清楚如何区分偶然复杂性和本质复杂性，以便呈现复杂问题的简单视图。
克服困惑
开始接近 MLOps 的一个更好的方法是思考您的组织今天在机器学习方面正在做什么，您希望在未来做什么，以及您将因此在机器学习系统方面面临哪些挑战。
需要解决哪些问题？
不同的 ML 问题对 ML 系统提出了不同类型的要求。涉及非结构化数据的问题，如理解视频、音频或自然语言，与涉及表格业务数据的问题相比，需要付出更多的努力（包括人工努力）来标记训练示例，在表格业务数据中，标记工作通常是微不足道的或自动化的。
一些问题得益于只需要从单一来源立即获得的数据的模型，而其他方法和问题则取决于将来自多个来源的历史数据和聚合数据与新的观测结果联合起来进行预测。 ML 的新应用程序可能受益于对实验性和探索性开发的更好支持，而成熟系统可能受益于开发过程自动化。
最后，为了验证其适用性和安全性，需要在一系列条件下（包括不太可能或对抗性场景）模拟自动化可能影响人类生命、控制危险机器或管理金融投资组合的关键决策的系统。如果您正在处理包含特殊需求的问题，请确保您找到了能够帮助您满足这些需求的 MLOps 解决方案。
需要考虑哪些因素？
类似地，一些应用领域和业务需求对机器学习系统提出了技术要求。受监管行业的应用程序通常受益于能够复制和解释历史结果，例如解释金融承销讨论或显示用户的个人数据未用于培训模型。
对延迟敏感的应用程序，如搜索、媒体推荐和广告定位，可以从支持低延迟预测的基础设施中受益，并从更多和更少复杂模型的集合中提供结果，以改善最坏情况下的响应时间。许多感知问题将受益于转移学习的基础设施和能够处理和优化大型复杂模型的服务框架。
今天的 ML 和数据团队是什么样子的？
正如整个 ML 环境不断发展一样，数据团队的角色和角色也在不断发展。在 2010 年代早期，“数据科学家”是一个全面的角色，承担着大量的数据工程和软件开发责任，同时也具有一定的统计复杂性。如今，数据科学家的专业化程度要高得多。团队现在通常包括以下角色：
数据科学家 专注于设计和执行实验，以识别和利用数据中的模式，使用基本摘要和聚合、应用统计和机器学习等工具。
数据工程师 使数据（无论是结构化的还是非结构化的、静态的还是动态的）可以大规模使用，并解决了编目、治理和访问控制方面的问题。
业务分析师 使用结构化联邦数据集上的查询处理来理解业务问题的特征。
应用开发者 通过基于数据科学家的实验开发成熟和健壮的服务，与数据工程师维护的数据服务集成，以及开发传统应用程序组件和与企业中间件的集成来构建生产系统。
机器学习工程师 的职责涉及多个角色，但特别关注开发、维护和优化生产基础设施。
思考您的数据团队中目前有哪些人参与，以及您将来希望有哪些人参加，这是评估 MLOps 工具、系统和解决方案的一个重要方面。这个评估告诉你什么对你的团队很重要，谁是给定解决方案的受众。
评估环境并为团队设计解决方案
在考虑了您试图解决的问题和数据团队的组成后，您准备根据您和您的组织需要的解决方案来评估和了解 MLOps 环境。您的目标是支持您自己的机器学习计划，而不是根据供应商和影响者对 MLOps 的看法来理解 MLOps 环境。
以工作流为中心的方法
由于 MLOps 生态系统正在快速发展，许多产品类别并非相互排斥，且界限模糊。这意味着，您不一定希望将 MLOps 解决方案视为功能清单或互补产品的组合，它们像构建块一样组合在一起。这种方法将使您对不断变化的环境有一个特定的看法。
相反，想想人们如何共同构建机器学习系统，以及不同类型的工具和系统如何支持它们。
图 1 显示了一个典型的机器学习发现工作流。该工作流具有七个人工流程，每个流程通知下一个流程。每个阶段涉及的人物角色都需要注意：数据科学家和业务分析师人物角色通常不关心计算基础设施的细节，而工程师和应用程序开发人员则直接与基础设施进行交互，这是他们工作的一部分。
因为人类总是有不完整的信息（并且经常犯错误），所以在任何时候都有可能回到早期的工作流阶段，并根据新的见解重新审视早期的决策。您的组织如何谈论 ML 工作流可能涉及稍微不同的术语或不同的阶段，但在任何情况下都应该可以遵循。
在 ML 工作流中支持您的团队
MLOps 工具如何支持 ML 工作流？图 2 描述了各种重叠的产品类别以及它们如何支持 ML 工作流的各个方面。工作流上方描绘了与底层计算基础设施无关或隔离的人物角色和产品类别，而工作流下方描绘了依赖于与底层计算结构直接交互的人物角色与产品。
图 2 中最顶级的类别 end-to-end, 包括 ML 平台产品，这些产品包含控制平面和对多个生命周期阶段的支持。需要注意的是，术语“端到端”不是价值判断或完整性声明。这一类别的成员资格仅表明特定产品涵盖了生命周期的一大部分，并设计为自行运营。
图 2 中的第二类结合了 data wrangling 产品，其中包括数据探索、可视化和高级联合功能、传统商业智能和分析产品，以及非结构化数据的标签产品。您正在解决的问题类型将表明这些类型的服务中的哪些与您的工作流程最相关。
交互开发 产品提供了一个控制平面，使数据科学和 ML 从业者能够访问按需计算资源。这些工具通常提供管理开发环境的工具，并与外部版本控制系统、桌面 IDE 和其他独立开发工具集成。它们提供了内部部署和公共云基础设施的统一视图，并使团队更容易在项目上进行协作。
体验管理 产品提供了一种跟踪各种模型配置（以及版本化的代码和数据）结果的方法，以了解建模性能随时间的变化。 AutoML 系统建立在实验管理的基础上，自动搜索给定技术的可能技术和超参数的空间，以产生具有最小从业者输入的训练模型。
数据管理 产品支持数据仓库、数据版本控制、摄取和访问控制。从 ML 系统的角度来看，数据版本控制通常是关键部分。可复制的工作取决于能够识别模型所基于的数据。
功能管理 产品结合了 feature stores 来跟踪衍生、聚合或昂贵的开发和生产计算功能。这些还可以支持某些组织中围绕特征工程方法的协作。
管道管理 产品提供了一种协调和监控探索和生产工作流中涉及的多个软件组件的方法，例如预处理、培训和推理。
模型操作 产品解决了将模型发布为可部署服务、部署这些预测服务、管理和路由到预测服务集合、事后解释预测、跟踪来自预测的反馈以及监控模型输入和输出的概念漂移等问题。
基础设施管理 提供了在底层硬件或云资源上调度计算作业和服务的接口。从机器学习系统的角度来看，这一领域的产品通常很有趣，如果它们为加速硬件、组调度和其他 ML 特定问题提供了特殊支持。
了解更多信息
这是一个令人兴奋的时间来思考和构建 ML 系统。 Register for NVIDIA GTC 2023 for free ，并于 3 月 20 日至 23 日与我们一起参加 Enterprise MLOps 101 ，介绍企业的 MLOps 环境，以及许多其他相关会议。
