By 赛吉塔，大数据工程和数据科学专家.

交会建筑 由 Ted Dunning 和 Ellen Friedman 在他们关于 机器学习物流 是我为我正在处理的特定架构问题找到的绝妙解决方案。 我一直在寻找一种久经考验的设计模式或架构模式，以帮助我以可维护和可支持的方式一起运行 Challenger 和 Champion 模型。 集合点架构在大数据世界中更为有用，因为您正在处理大量数据和大型管道。

在所有数据上同时运行 Challenger 和 Champion 模型的能力是机器学习中的一个非常真实的需求，其中模型性能会随着时间的推移而漂移，并且您希望不断改进模型的性能以达到更好的水平。

所以，在我深入研究这个架构之前，我想澄清一些我在上面使用的术语。 什么是冠军模型？ 什么是挑战者模型？ 什么是模型漂移，为什么会发生？ 然后，我们可以看看会合架构本身以及它解决的问题。

模型漂移

一旦您将模型投入生产，假设它总是表现良好是错误的。 事实上，据说——”将模型投入生产的那一刻，它就开始退化“（请注意，最常见的是 '性能' 在 ML 中用于表示统计性能——无论是准确度、精确度、召回率、灵敏度、特异性还是任何适合您用例的适当指标).

为什么会发生这种情况？ 该模型是根据一些过去的数据进行训练的。 对于具有相同特征的任何数据，它都表现出色。 但是，随着时间的推移，实际数据特征会不断变化，而模型根本不知道这些变化。 这会导致模型漂移，即模型性能下降。

例如，您训练了一个模型来检测垃圾邮件与非垃圾邮件。 该模型在部署时表现良好。 随着时间的推移，垃圾邮件的类型不断变化，因此预测的准确性下降。 这就是所谓的 模型漂移.

模型漂移可能是由于 概念漂移 或者 数据漂移。 我今天不讨论这些，所以我们只要明白模型的性能不会保持不变就足够了。 因此，我们需要持续监控模型的性能。 大多数情况下，最好更频繁地或可能基于性能下降的阈值级别使用更新的数据重新训练模型。

有时，即使重新训练模型也不会进一步提高性能。 这意味着您可能必须了解问题特征的变化，并使用更合适的模型来完成数据分析、特征创建和模型构​​建的整个过程。

如果您可以使用 Challenger 模型，即使我们目前有一个模型在生产，这个周期也可以缩短。 这是机器学习的持续改进过程，非常需要。

冠军挑战者模型

通常，生产中的模型称为 冠军 模型。 任何其他似乎在您的小型试验中运行良好并准备投入生产的模型都是 “挑战者” 模型。 提出这些 Challenger 模型是因为我们假设它们有可能比 Champion 模型表现更好。 但是我们如何证明呢？

Champion 模型通常在所有传入数据上运行以提供预测。 然而，挑战者模型运行在哪些数据上？

有两种方法可以测试挑战者模型。 理想的情况是在所有数据上并行运行 Challenger 模型和 Champion 模型并比较结果。 这将真正证明挑战者模型可以表现得更好与否。 然而，这似乎令人望而却步，尤其是在大数据世界中，因此挑战者总是在传入数据的一个子集上进行试验。 一旦它看起来表现良好，它就会逐渐推广到越来越多的数据，几乎就像 alpha-beta 测试一样。

您可能知道，在 alpha-beta 测试中，一小部分用户或传入数据（在这种情况下）通过新的测试或 Challenger 管道发送，其余全部通过原始 Champion 管道发送。 这种 alpha-beta 测试适用于某些应用程序，但在机器学习领域显然不是很令人印象深刻。 您不是在相同数据上比较模型，因此很少可以自信地说一个模型比另一个更好。 一旦你为所有数据推出它，可能会有潜在的惊喜，并且模型漂移可能比预期的更早开始。

典型的 alpha-beta 管道如下所示：

数据根据某些标准（如产品类别）在两个管道之间拆分。 随着对 Challenger 模型性能的信心增加，这种数据拆分不断向 Challenger 增加。

从数据科学家的角度来看，这并不理想。 理想的情况是能够并行运行 Challenger 模型 所有数据 与冠军模型一起。 正如我之前所说，这是非常昂贵的。

考虑最坏的情况。 如果希望它们并行运行，则必须设置两个独立运行所有步骤的数据管道。

它看起来像这样：

这具有巨大的工程意义，因此对上市时间有影响。 随着时间的推移，这样做的成本可能会令人望而却步。

一些最重要的影响是在不确定挑战者模型是否确实会按预期执行的情况下一遍又一遍地构建这些管道所需的时间和精力。 CI/CD 流程、部署、监控、身份验证机制等仅举几例。 此外，另一个成本是围绕必须双重配置的基础设施。

考虑到这些管道是否是大数据管道，它变得更加重要。 很快，您就会意识到这不是一个可扩展的模型。 我们当然必须看看我们如何才能摆脱并行管道，甚至摆脱 alpha-beta 测试方法。

作为推论，最好的情况是我们可以重用大部分数据管道。 这个想法是最大限度地减少开发和再次部署到生产中的数量。 这也将确保优化基础设施的使用。 这是关于如何优化的一种思路。

更好的是能够 插入挑战者模型， 而管道的其余部分就好像什么都没有改变一样。 那不是很棒吗？ 而这正是通过 交会建筑。

交会建筑

正如书中所写，Rendezvous 架构倾向于使用较小数据的 ML。 我对其进行了调整以满足大数据世界和相关管道的需求，如下图所示： （对本书和另一篇文章的参考在下面的参考部分中给出）

现在让我逐节解释这个架构。

部分1：

这包括用于接收传入数据、清理数据、准备数据和创建所需功能的标准数据管道。 对于要部署的每个模型，这应该只是一个管道。 准备好的数据应维护一个标准接口，该接口具有该域中可能需要的所有功能，而与手头的模型无关。 (我知道这并不总是可行的，随着时间的推移可能需要逐步调整。 但是我们可以在需要时单独处理那部分。)

部分2：

这是一个像 Kafka 这样的消息传递基础设施，它通过引入异步感而发挥作用。 作为特征准备的数据被发布到消息总线上。 现在，每个模型都会侦听此消息总线并触发，并使用准备好的数据执行自身。 该消息总线是实现即插即用架构的原因。

部分3：

这是所有模型一一部署的部分。 可以部署新的 Challenger 模型并使其侦听消息总线，并且随着数据流入，它可以执行。 这里可以部署任意数量的模型，而不仅仅是一个 Challenger 模型！ 此外，基础设施要求仅适用于要运行的额外模型。 模型前管道和模型后管道都不需要单独开发或部署。

正如您在图中所见，您可以拥有许多挑战者模型，只要数据科学家认为它们足够成熟，可以针对真实数据进行测试。

此外，还有一种特殊模型，称为诱饵模型。 为了保证每个模型进程都没有被持久化的负担，准备好的数据也被一个叫做 诱饵模型， 其唯一的工作是读取准备好的数据并持久化。 这有助于在需要时进行审计、跟踪和调试。

部分4：

所有这些模型再次将它们的预测或分数输出到另一个消息总线中，因此它们之间不会产生任何依赖性。 此外，这在确保模型的可插拔性而不破坏管道中的任何其他内容方面再次发挥重要作用。

如第 5 部分所述，集合过程从那里获取分数并决定需要做什么。

部分5：

这就是新概念的地方 会合流程 介绍，它有两个重要的子过程。 一个直接子进程负责从消费者收到的许多分数中为消费者从管道中流出正确的输出，另一个进程是保留所有模型的输出以供进一步比较和分析。

所以，我们在这里实现了两件事：

1. 最好的输出被提供给消费者。
2. 所有数据都经过了所有模型，因此它们在类似情况下的性能完全具有可比性。

它如何决定应该发送哪个模型的输出？ 这可以基于多个标准，例如数据子集应始终来自 Challenger，另一个子集应始终来自 Champion。 这几乎就像实现了 alpha-beta 测试。 然而，这里的优势在于，虽然对于消费者来说听起来像是 alpha-beta 测试，但对于数据科学家来说，所有数据都经过了这两个模型，因此他们可以比较两个输出并了解哪个表现更好。

另一个标准可能是输出应基于模型性能。 在这种情况下，集合进程等待所有模型完成并发布到消息总线。 然后，它会寻找最佳性能指标并将其作为结果发送出去。

是的，另一个标准可以是时间或延迟。 例如，如果我们需要在不到 5 秒的时间内获得结果，则该过程会等待来自模型的所有结果，最多 5 秒，仅比较那些结果，并返回最佳数据。 即使另一个可能表现更好的模型在第 6 秒返回，但由于它不符合延迟标准而被忽略。

但是这个过程如何知道哪些数据或模型遵循的标准是什么？ 这可以作为输入数据的一部分放入第 2 部分中的消息总线中。请注意，Rendezvous 进程也在侦听这些消息并了解如何处理与输入对应的输出。 也可能有其他聪明的方法，但这是提出的方法之一。

结论

通过通过消息总线引入异步性，引入了一定程度的解耦，将即插即用模型引入原本僵化的数据管道中。

通过引入集合过程，引入了在各种模型输出之间进行选择、保留它们、比较它们的能力。 有了这个，现在为同一数据集引入或支持任何数量的新模型似乎并不是一项艰巨的任务。

总结

集合点架构在各个级别提供了极大的灵活性。

1. 可以使用多种标准来决定可以从预测过程中发送什么分数、输出或预测。 这些标准可以是基于延迟的、基于模型性能的或简单的基于时间的。
2. 它提供了通过集合过程动态定义和更改这些标准的能力。 您可以通过在此处引入规则引擎将其提升到另一个级别。
3. 它提供了使所有数据通过所有管道或仅选择一个子集通过许多管道的能力。 例如，如果您有要预测的杂货和一般商品，杂货可以通过自己的 Champion 和 Challenger 模型，而一般商品（通常是慢卖家）可以有自己的管道。
4. 它还提供了一次运行多个模型的能力，而无需重新开发或重新部署大数据管道的大部分。 除了节省精力和时间之外，还优化了基础设施成本。

参考资料

1. 机器学习物流 作者：泰德·邓宁； Ellen Friedman – 关于“机器学习的集合架构”的第 3 章
2. 上一篇文章 endingdatascience.com“生产中数据科学的集合架构” 扬·泰希曼

原版。 经许可重新发布。

简介： 赛吉塔 (@saigeethamn) 是一位架构师，在创建战略路线图和基于企业需求和领先技术进行创新方面具有丰富的经验。 一位拥有数据科学知识的大数据专家，可以弥合两个世界之间的差距，并为您企业中的任何大数据计划带来成功。

相关新闻：

• 再见大数据。 你好，海量数据！
• 模型再培训的终极指南
• 人工智能和大数据的隐藏风险