MLOps：真实世界的模型部署

部署机器学习/人工智能/数据科学产品并非易事。大多数情况下，机器学习算法的输出结果会被编译成需要纳入现有生产工作流或服务的工件。有时，用于开发这些模型的语言和技术与用于构建实际服务的语言和技术不同。
在本文中，我们将重点讨论数据科学管道中的模型部署部分。随着数据科学团队和流程的成熟，团队需要处理复杂的场景，因此简单的模型部署机制无法扩展。在本文中，我们将从深度操作的角度介绍部署数据科学模型的方法。

作为部署实体的数据科学模型

与代码一样，模型也将部署到现实世界中。因此，我们不称之为 DevOps（开发人员运营），而称之为 ML Ops（机器学习运营）。如今，它们可以互换使用。
很多数据科学术语都将模型视为机器学习方法的工件，但这限制了其性质，使其过于局限。出现这种情况的主要原因是数据科学家各自为政，只是将最终模型作为适合部署的工件进行共享。然而，如果深入研究数据科学家在构建模型时的工作流程，他们通常会从简单的工作开始。

算法复杂度O() 之于编码，验证和评估之于数据科学模型。 在首次应用机器学习技术时

当第一次将机器学习应用于问题时，你最大的改进通常来自于实现任何解决方案，而不一定是最优解决方案（验证和评估）。当我们第一次尝试暴力方法，然后根据性能进行优化（Big-O）时，这在代码方面是类似的。在这种情况下，我认为模型是超参数和算法方法的结合，但不是参数（取决于数据，如下所述）。我们可能希望逐步提高模型的准确性或应用领域。因此，模型像代码一样不断发展，应该以这种方式对待。

模型部署场景

不同的建模方法具有不同的特性和局限性。回归模型是可消费的，但神经网络可能更难理解。因此，当我们考虑我们的系统影响哪些下游需求时，我们对模型的选择可能会产生与用于训练它们的数据无关的影响。

模型（包括超参数）的选择从来都不是一个单一的决定。

它导致了模型部署的不同场景。

A/B测试模型

由于模型是超参数和算法方法的结合，团队可能希望尝试随着时间的推移或同时检查不同解决方案的有效性。这样做可以真正了解哪种模型在生产中表现更好。这里增加的复杂性来自于所需的基础设施和路由规则，以确保流量被重定向到正确的模型，并且您需要收集足够的数据来做出具有统计意义的决策，这可能需要一些时间。这种方法被称为“多武装土匪实验”。对于AWS，这被解释为实时多变量优化。对于Azure，这可以使用Azure Personalizer来实现。

金丝雀模型

Netflix使用Isthamus来引入ELB中断的恢复能力。同样的架构也被用来分流Netflix内部新的金丝雀构建和发布的流量。其概念是，他们没有完全淘汰产品的某些部分，而是部署了产品的新部分，并慢慢分流流量。金丝雀释放的做法已经采用了一段时间。有时，它被称为分阶段卷展栏或增量卷展栏。在ML世界中，将有一个现有的模型和一个新的更新模型。我们希望慢慢地从旧型号逐步淘汰到新型号，而不是立即切换到新型号。这样做是为了在完全切换到新模型之前逐步收集有关新模型的数据和指标。无论推理和方法如何变化，我们都可以使用前面方法中描述的相同技术。

实时学习模型

在某些场景中，模型使用的算法和技术可以随着新数据的出现而不断提高其性能。他们在生产中不断学习。前两个场景可以应用于所有类型的模型，因为它们是改进模型本身的产品和交付的方法。然而，在这种情况下，模型本身的性质与离线学习视角和更新的在线学习视角不同。这些模型的例子包括为社会实验部署的模型（Instagram上的每个“赞”都可以决定向你提供的帖子的不同结果），或者基于图形的场景，在这些场景中，模型仍然无法查看整个图形，并在新的领域变得可见时做出决定。在这里，我们必须将这些模型视为代码，这与我们将基础设施视为代码的原因相同。此外，我们不仅需要修改训练数据，还需要修改将影响模型性能的生产数据。

复合模型（模型集合）

有时有多个型号为一个产品/功能提供动力。想象一下，有一个产品会分配信用评分或评级。在该产品中，可能会有一个API调用来获取特定分数，该分数可以作为事件传递给用户/客户配置文件。在幕后，可以使用多个模型来获得累积分数。每个模型都可以在测试环境或生产环境中使用以上不同的方法进行实验。我们对应用程序和不同模型的关注点分离得越多，就越能增加灵活性和扩展能力。

建议

为了支持更复杂的部署场景，流程和基础设施需要灵活。随着产品/应用程序的扩展，可能需要更多的基础设施来为更多的用户和客户提供服务。因此，如果支持不同的模型部署场景，它将直接影响系统的可扩展性和可靠性。Neptune.ai解释了使用tfx和Kubeflow生产的ML模型。这是将上述所有部署场景付诸实践的方法之一。机器学习产品是模型、数据和代码的融合。我们越是支持不同的场景，其中每个场景都可能随着时间的推移而改变（因为它们会改变），我们就越有机会使ML产品成功。