MLOps 作为管理数据基础设施的一类新工具出现，专门针对 ML 用例，主要假设是 ML 具有独特的需求。
几年后，随着炒作消失，很明显，MLOps 与数据工程的重叠比大多数人认为的要多。让我们看看为什么以及这对 MLOps 生态系统意味着什么。
机器学习的快速发展激发了 MLOps 作为一个类别的创建。随着围绕 ML 的创新步伐加快，团队和公司开始遇到跟不上的问题。
构建和运营 ML 产品开始给数据和 ML 工程团队带来很大压力，哪里有痛苦，哪里就有机会！
越来越多的人开始看到将新产品推向市场的机会，并承诺将每家拥有任何数据的公司转变为人工智能驱动的组织。
MLOps 供应商可以分为多个产品类别。
- 模型的部署和服务，即 OctoML
- 模型质量和监控，即权重和偏差
- 模型训练，即AWS Sagemaker
- 特色商店，即 Tecton
这里需要提一下，上面的类在很多情况下是互补的，比如你使用Feature Store，你还需要一个模型训练的服务。
模型的部署和服务：这是数据工程和软件工程中常见的操作。在 ML 成为现实之前，人们一直在部署管道甚至更好，部署各种复杂方式的应用程序。
模型质量和监控：这是 ML 独有的问题。监控模型质量的方式与监控软件项目或数据管道的方式不同。但这只是质量问题的一部分，我们稍后会看到。
模型训练： 这是 ML 独有的，但构建模型并不是什么新鲜事，问题是过去五年发生了什么变化需要完全不同的范式来做呢？
特征存储： 这是 MLOps 最有趣的产品之一，对于外行来说，首先想到的是某种专门的数据库，但特征存储实际上不止于此。它们是一个完整的数据基础架构，被提出并尝试产品化。它与经典的数据基础设施架构有何不同？我们会看到。
模型的部署和服务
在我看来，这是 MLOps 最有趣的方面之一。主要是因为这是 ML 工程师所做工作的结果达到可以从中产生具体价值的部分。
推荐器可以向用户提供推荐，并且可以实时应用欺诈检测。
但这里有趣的是，这个过程与 ML 没有太大关系，工程问题更多地与产品工程相关。
我们可以将模型视为需要一些输入并生成一些输出的函数。为了通过此功能提供价值，我们需要一种方法将其添加为我们提供的产品体验的一部分。
在工程术语中，这意味着我们必须使用干净的 API 将模型包装为服务，并将其公开给产品工程师。
然后我们需要以可扩展和可预测的方式部署此服务，就像我们为我们的产品部署任何其他服务一样。
之后，我们需要运行该服务并确保根据需求为其提供所需的资源。
我们还需要监控服务是否存在问题，并尽快修复它们。
最后，我们希望有某种持续部署——集成过程来部署对服务的更新。就像我们处理我们产品的任何其他服务一样。
正如我们所见，上述过程几乎与管理任何其他软件组件的发布周期相同，而它主要是作为利益相关者参与的产品工程。
毕竟，他们必须确保模型提供的新功能以正确的方式集成到产品中，而不会中断其操作。
由于必须使用 ML 模型，工程和运营团队有一个特定的需求，这与监控模型本身的性能有关，但我们稍后会详细讨论。
这里的问题是，如果将模型集成到我们的产品中与我们发布的关于该产品的任何其他功能没有区别，就发布和平台工程和运营而言，为什么我们需要一个全新的产品类别？
我的观点是，业界正试图通过构建全新的平台来解决将模型转化为服务的独特挑战，但这并不是最佳选择。
这里真正需要的是开发人员工具，它们将丰富现有的和经过验证的平台和方法，用于大规模发布和操作软件，以便将 ML 模型作为基础软件工件来实现。
我们不需要 MLOps 工程师，我们需要允许 ML 工程师以平台和发布工程师能够使用和生成产品工程师集成到产品中所需的工件的方式打包他们的工作的工具。
我看到的一个反复出现的模式是试图成为类别创建者的供应商试图定义一种新型工程师。
在大多数情况下，这是现有角色之间的交叉，即分析工程师，你有一个主要是分析师但也做一些数据工程工作的人，例如创建管道。
这可能是一个明智的营销举措，但世界并非如此。出现了新角色，并且不能由供应商强制执行。
为什么我们希望 ML 工程师承担发布或平台工程师的职责？为什么我们希望将前者引入一种全新的工具类别，这听起来与他们的实践很陌生？
关注点分离在软件架构和组织设计中都是一件好事。
模型质量和监控
这是事情变得非常有趣的地方。质量保证、控制和监控是软件工程中的一个重要话题。在某种程度上，有些夸张地说，这些是将软件工程转变为……工程的要素。
软件质量相关任务有许多最佳实践和成熟平台。问题是，ML 模型可以轻松挑战这些。
您可能听说过数据基础设施的质量很难，而且确实如此。我们不仅要监控质量的软件，还要监控数据。在应用质量概念时，数据是另一种野兽。
在 ML 中，情况更糟。您几乎已经生成了一个黑盒系统，您需要通过仅根据其在生产中获得的输入观察其输出来监控其性能。
因此，模型质量和监控通常与模型漂移等术语一起提及。如果模型随着时间的推移根据其“预测”性能进行监控，并且如果它下降到阈值以下，我们知道我们需要用新数据重新训练它。
这有道理，对吧？随着我们的产品变化和客户行为的变化，模型需要重新训练以考虑这些变化。
我在这里有两个主要论点：
首先是，漂移等模型质量指标的可观察性与任何产品相关监控有何不同？在产品中，我们不断监控我们功能的性能，人们是否以我们期望的方式与他们互动？如果发生变化并且参与度下降，我们应该解决这个问题，对吗？
这些都是通常被称为产品实验基础设施的一部分，其中很大一部分需要存在正确的数据基础设施和数据工程。
无论 ML 模型多么独特，最后我们将观察一项服务——关于它如何执行与我们的用户交互的功能，并根据我们收集的数据，确定是否需要采取行动。
我的感觉是，ML 可观察性和组织为产品实验构建的数据基础设施工程基础之间存在很多重叠。
我的另一个论点是关于一般的数据质量。ML 模型建立在数据之上，它们的质量直接反映了用于构建它们的数据的质量。
这是一个数据工程一直在与之抗争的严重问题，我看不出这个过程的复制如何以任何方式帮助解决这个问题。
数据工程师是从数据捕获到 ML 工程师可以使用它的过程中监控数据的人员。他们可以访问整个数据供应链，并且可以在该链的任何一点进行监控和添加控制。
添加另一个与数据工程和产品工程质量控制重叠的平台并不能解决问题，在最坏的情况下，它可能会使情况变得更糟。
同样，这里的解决方案是工程工具来丰富现有的架构和解决方案。找出数据质量需要什么并装备工作人员是为了确保数据和产品质量，以将他们的影响力也扩展到 ML 模型中。
模型训练
老实说，这是一个简短的。模型训练与云计算的关系比其他任何事情都大，在我看来，这是当今大型云提供商主要提供价值的领域。主要原因是需要硬件来进行实际培训。
但在一般情况下，模型训练无非就是一个数据管道。数据从多个来源读取，并通过应用训练算法进行转换。如果这发生在 CPU 或 GPU 中并不重要。
这是数据工程的基础，工具已经存在，我在这里看到的主要区别是云计算抽象，无论如何我们正在谈论完全不同类别的基础设施。
大规模模型训练应该成为数据工程学科的一部分，因为他们已经拥有工具，他们对所需数据的 SLA 负责，并且他们可以更好地控制发布生命周期。
机器学习人员是否为这些操作烦恼？我不明白为什么要说实话。我相信他们更愿意花更多的时间来构建新模型，而不是处理大规模数据处理的操作。
我在这一点上感到无聊，但同样，我们不需要新平台。我们只需要为 DE 提供正确的工具，以便与 ML 和生产工程师进行有效沟通，并将模型训练添加为他们的 ETL 管道中的另一个步骤。
特征存储
我故意将特征存储放在最后，因为它们是与数据工程重叠的一个很好的例子，而它们的受欢迎程度很好地表明数据基础设施的当前状态有些不对劲。
Tecton 提出的特征存储架构，Tecton 是最早也是最受欢迎的特征存储供应商之一：
- 流数据源
- 批量数据源
- 转换
- 贮存
- 服务
- 模型服务和培训
特征存储类似于需要流处理和批处理功能的公司使用的典型数据基础架构。但是，他们专门通过仅服务于一种类型的数据消费者（ML 模型）来支持机器学习功能。
供应商将特征存储架构打包到产品中，这引起了一些混乱。有些人可能会质疑是否需要另一个 Spark 或 Flink 集群来进行实时特征生成，尤其是当他们已经在使用这些工具进行 ETL 作业时。然而，特征存储很有用，因为它们描述了需要添加到现有数据基础架构中以有效地生产机器学习的内容。
作为一种产品，特征存储应该专注于为数据、ML 和产品工程师构建工具和实践，以更有效地协同工作。应仔细评估任何额外的开销和复杂性，以确保使用特征存储的好处大于成本。
供应商应专注于提供有用的工具来支持这一点，而不是复制现有的数据基础设施。