部署基于嵌入的机器学习模型的通用模式，以推荐和搜索为例

本文主要是介绍部署基于嵌入的机器学习模型的通用模式，以推荐和搜索为例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

点击上方“AI公园”，关注公众号，选择加“星标“或“置顶”

作者：Robbe Sneyders

编译：ronghuaiyang

导读

机器学习模型的部署一般会比较麻烦，基于嵌入的模型的部署会更加麻烦，这里以推荐和搜索系统为例，给大家介绍一下基于嵌入的模型的部署模式。

大量的机器学习的研究，使得模型性能在过去几年里有了显著的提高。虽然这些改进的模型开辟了新的可能性，但是它们只有在可以部署到生产应用中的时候才开始提供真正的价值。这是机器学习社区目前面临的主要挑战之一。

部署机器学习应用通常比部署传统软件更复杂，因为引入了一个额外的变化维度。典型的软件通常需要更改其代码和数据，机器学习应用也需要对模型进行更新。模型更新的速度甚至可以非常高，因为模型需要定期地根据最新的数据进行再训练。

本文会描述一种更加复杂的机器学习系统的一般部署模式，这些系统是围绕基于嵌入模型构建的。要理解为什么这些系统特别难以部署，我们首先要看看基于嵌入的模型是如何工作的。

基于嵌入的模型

基于嵌入的模型正在所有机器学习领域中出现。它们最近在NLP领域掀起了一场革命，是大多数现代推荐引擎的核心。谷歌使用嵌入来为你的搜索查询找到最佳结果，而Spotify使用嵌入来生成个性化的音乐推荐。

简单地说，这些模型将它们的输入投射或嵌入到向量表示或嵌入中。视觉模型嵌入图像，语言模型嵌入单词或句子，而推荐系统对用户和项目也做同样的事情。

生成的嵌入非常强大，因为它们可以以相对低的维数描述数据集的结构。在得到的向量空间中，相似的输入记录被紧密地映射在一起，而不同的物品被映射到相聚很远的地方。这使得比较复杂的对象成为可能，这在原始数据空间中是不可能的。

这些嵌入可以在不同数据域的模型之间共享，并且可以在它们之上构建解决新问题的新模型。不难想象，这样一个完整的机器学习模型系统会有多大的价值。

基于嵌入的系统

不幸的是，一个嵌入本身并不是很有用，只有与其他嵌入进行比较才会变得强大。由于每次都重新计算所有嵌入项是不可行的，而且常常是不可取的，所以它们通常是预先计算好的，并保存在实时数据存储中以供比较。

这正是这些系统难以部署的原因。每次模型更新时，都需要重新计算所有的嵌入。对于具有数百万条记录的系统，这可能需要很长时间，在此期间，活动系统的正常操作不会受到影响。即使在较小的系统中，这样的更新也不是即时的，如果管理不当，可能会导致不一致的结果。

我们将研究两个基于嵌入式的系统，搜索引擎和推荐系统，并定义一个适用于这两个系统的通用部署策略。虽然这些系统是相似的，但它们的差异足以为广泛的基于嵌入式的系统提供泛化。

搜索引擎（左），推荐系统（中），通用嵌入系统（右）

搜索引擎

搜索引擎的目标是为搜索查询找到最匹配的文档。它由三个组件组成：应用程序、模型和嵌入数据库。当应用程序接收到搜索查询时，它调用模型将查询转换为嵌入，然后使用该模型在数据库中的文档嵌入执行相似性搜索。

不停机部署新模型

当对模型进行再训练或微调时，数据在嵌入空间中表示的方式将发生变化。为了获得一致的结果，嵌入生成器返回的嵌入和存储在嵌入服务器中的嵌入应该由相同的模型版本生成。

准备新模型部署的第一步是使用新模型重新计算系统中所有记录的嵌入，并将它们存储在新的数据存储中。最直接的方法是批量计算，与实际系统分离。重新计算所有嵌入后，新的嵌入生成器和服务器就可以部署到活动系统中。

一种简单的方法可能是尝试同时部署新的嵌入生成器和服务器。但是，即使它们都可以完全同步地切换到新版本，这在实践中很难实现，这种方法仍然不足以保证一致的结果。来自旧的嵌入生成器的过时的嵌入可能已经在运行中，并且只有在更新之后才能到达嵌入服务器，从而导致相似度搜索不匹配。

嵌入生成器和服务器的新版本都与旧版本部署在一起，因此应用程序可以轻松切换。

很明显，为了确保连续性，从单个应用调用的角度来看，更新应该是原子性的。当应用从生成器获取嵌入时，它应该始终在具有匹配版本的嵌入服务器中执行相似度搜索。为了实现这一点，两个组件的新旧版本至少需要同时部署，在此期间，两个版本之间的切换可以在应用程序调用级别进行。之后，旧版本可以简单地删除。

上图显示了如何以这种方式将连续的应用程序调用切换到新版本，而不会导致任何停机或不一致。

进行流处理

现代系统通常比我们最初引入的简单系统更复杂，因为它们处理的数据需要不断更新。新文件需要添加到我们的搜索引擎，或现有的文件可能得到更新。新用户可以订阅我们的推荐系统或更新他们的资料，而新的项目可以定期添加到目录。

有些系统可能可以通过批计算进行这些更改，并定期用新的数据存储替换旧的数据存储，但是这样做会在系统中出现新的或更新的记录之前增加很大的延迟。随着流更新成为越来越多系统的需求，需要一种流的本地部署策略。为了得到这个策略，我们将首先重新引入我们的搜索引擎和推荐系统作为流式系统。

加载流更新到搜索引擎

为流更新升级我们的搜索引擎是没什么大不了的，因为它已经托管了一个在线嵌入计算模型，可以在数据加载期间重用该模型进行流推理。系统中引入了一个新的数据加载器组件，用于传入的文档的更新。它首先使用在线模型得到传入的文档的嵌入，并将生成的嵌入写入到嵌入数据存储中。

升级我们的推荐系统需要更多的工作，因为流更新需要一个在线模型，这以前不是系统的一部分。在添加了在线模型和数据加载组件之后，数据加载流相当于搜索引擎的数据加载流。数据加载器首先调用在线模型来对物体和用户进行嵌入，并将生成的嵌入写入相应的数据存储。

由于两个系统是等价的，为了简单起见，我们将使用搜索引擎演示流模型的部署。

流模型的部署

在流模型部署期间，新版本将执行批量加载，而两个版本都将持续接收流更新

我们现在将把它集成到流系统本身中，而不是在批处理中单独预先计算新版本的所有嵌入。作为第一步，模型的新版本和新的数据存储将与原始版本一起部署。为了确保在加载期间没有流更新丢失，它们被定向到两个版本。然后启动系统中的大容量负载，并仅将其路由到模型和数据存储的新版本。

当批量加载完成时，两个版本包含相同的数据记录，但是使用各自的模型计算嵌入。这种状态与我们讨论的批处理系统的状态相同，就像之前应用程序可以轻松地将流量切换到新版本一样。一旦切换完成，就可以删除旧版本。

这种方法的另一个优点是，流计算和批量负载计算都使用相同的组件，从而始终得到一致的结果。对于搜索引擎，同样的模型组件也用于在线搜索嵌入，以防止在线计算和预计算嵌入之间的不匹配。

模型的A/B测试

流量可以逐步转移到一个新版本，通过冻结一定的比例的迁移，可以对新模型进行a /B测试。

对于部署在生产环境中的系统，很有可能活动版本的组件已经进行了扩展以处理传入的负载。版本之间的硬切换可能会给新版本带来太多的负载。由于两个版本应该是同时可用的，所以流量可以逐渐地转移到新版本，使其有时间根据需要进行扩展。这也减少了在部署新版本时可能出现的问题的影响，因为如果需要，可以停止或进行逆转换。

同样的机制可以用于A/B测试新模型，以固定的百分比冻结转移。然后可以评估新模型并与活动模型进行比较，然后再决定是否应该完成部署或回滚部署。由于加载完整的数据集可能很昂贵，因此自动测试可以在加载期间使用相同的机制在有限的生产数据集上对新模型进行基准测试。