使用MLflow和AWS Sagemaker为企业AI场景持续交付基于深度变压器的NLP模型

视频记录

-欢迎参加我们的会议。我叫刘勇。与我的同事Andrew Brooks一起，我们非常高兴地分享我们使用MLflow和AWS Sagemaker为企业AI场景开发深度、基于变压器的NLP模型的持续交付的经验。

这是我们的报告大纲，有四个部分。让我们从介绍和背景的第一部分开始。

你可能听说过，也可能没听说过我们工作的这家公司。Outreach是排名第一的销售参与平台，雇用了4000多名客户，并且还在不断增长。bob体育客户端下载这些客户包括许多知名的初创企业和跨国公司。那么什么是销售参与平台呢?bob体育客户端下载

销售参与平台(SEP)bob体育客户端下载

销售参与平台将销售活动(如电子邮件、电bob体育客户端下载话和会议等)编码并自动化到工作流中。例如，左边的这张图显示了一个工作流，你可以在第一天发送电子邮件和打电话，然后在第三天安排LinkedIn消息，然后在第五天发送另一封电子邮件和打另一个电话。由于这种自动化，销售代表的业绩和效率可以通过更有效的一对一个性化外联大幅提高10倍。

除了自动化之外，我们还将智能添加到销售参与平台中。bob体育客户端下载这就是机器学习NLP和人工智能发挥作用的地方。

企业销售场景中的ML/NLP/AI角色

那么机器学习如何帮助NLP呢?通过使用我们的产品，销售代表产生了大量的数据，如电子邮件、电话脚本和参与日志等等。然后，我们利用机器学习NLP从这些数据中进行持续学习，并与知识相结合，为代表的持续成功提供预测、推荐和指导。这就成为了左侧所示的(模糊的)车轮。持续学习的原因是由于各种原因导致销售流程的变化。我们已经注意到COVID-19改变了销售代表使用内容的方式，这就是为什么支持持续学习和指导非常重要。我们在这次演讲中强调的一个特殊用例将是引导参与，我们将在后面讨论。然而，在我们真正享受机器学习NLP和AI的好处之前，我们还有一些障碍需要克服。现在让Andrew继续讨论。-所以现在，为了做好准备，激励我们实施了什么以及为什么，我们将讨论我们在外联面临的一些实施挑战。

实施挑战:数字鸿沟纲要

虽然我们是在我们的经验范围内讨论这个问题，但我们希望其他企业机器学习团队能够共享其中的许多挑战。

挑战1:开发与产品的分歧

首先，挑战一，dev和prod的区别。如果你曾经觉得自己是一个模型开发人员，把一个模型扔给一个运维团队，这是你最后一次看到它，或者一个运维团队捕捉一个需求和接口不清楚的黑盒模型，这幅漫画可能会告诉你。当模型开发人员被隔离时，当他们不能看到或使用来自产品化环境的代码时，他们就不能在实时数据上测试实际为产品或应用程序中的模型提供数据流的数据流。为什么这是个问题?因此，这通常会导致错误指定的模型管道，从而产生糟糕的预测，进而引起用户甚至付费客户的抱怨。当模型开发人员无法重现那些报告的错误或问题时，这种抱怨就更加复杂了。补救措施可能涉及手动区分开发人员和产品管道，以了解路由原因。我们已经经历过了。成本高，效率低，毫无乐趣，也没有必要。最后，当在prod中开发的生产级机器学习工具不能用于未来的模型部署(抱歉，是模型开发)时，这也是一种浪费。 This is a scenario where a V1 model has been trained, correctionized, and shipped, but V2 model training is restricted to the early iterations of notebook and ad hock code used to develop V1 model.

挑战2:开发者与产品的差异

挑战二，发展差异。在这些情况下，开发和产品管道之间的差异是不可避免的，有时是可取的，这是好的差异。一个常见的区别是用于模型训练和模型评分和生产的数据源通常是不同的。用于培训的数据通常来自持久数据存储，在组织内部使用分析数据来构建模型和报告，而不会有直接修改面向客户的数据或给校正应用程序增加负载的危险。用于评分的Prod数据通常是流的，而不是静态的，是面向客户的数据，并且在培训期间可能已经禁止模型开发人员使用。这些数据源通常需要不同的预处理管道。第二个不同之处在于，它包含了产品特定的或业务逻辑，这些逻辑是为产品、模型评分所需要的，而不是在培训期间。例如，prod中的评分管道可能希望在模型不自信的情况下抑制预测，但对于训练管道来说，没有这样的过滤器是可取的，甚至不存在。

挑战3:任意唯一性

挑战三，任意唯一性。如果没有一个编写通用设计模式的框架，组件就会倾向于单独强大，但在与管道或系统中的其他组件连接时，整体上不理想，甚至适得其反。在这种情况下，整体并不大于各部分的总和，尽管这些部分具有独特性和伟大性。这种情况可能发生在部署每个新模型时，感觉就像一个特殊的情况，并且为大多数已经存在的组件重新发明轮子。

这不仅涉及大量额外的开发，而且通常会产生非自文档化的管道。例如，如果管道的门和部署机制没有一致地定义，那么如何运行管道就不清楚了。跨项目和模型重用以及在更大的系统中集成的能力是有限的。自然，管道的维护和扩展是痛苦和低效的，在新工程师或开发人员入职时更是如此。

挑战4:出处

最后一个挑战，挑战四，来源，特别是源代码和源数据模型的来源。我们为什么需要这个?如果我们不知道prod中正在运行什么，我们就不能重现用户报告的问题和错误，正如我们在挑战一中讨论的那样。

第二个负面影响是模型管道变更可能会使团队对交付改进感到恐惧，而不是兴奋。当我们不确信存在一种机制能够始终准确地确定prod中运行的是什么，它是如何到达那里的，如何复制它，或推广一个新模型来取代它时，就会出现这种情况。缺乏来源也会影响使用模型预测的历史和时间分析。如果发布的模型不是版本，这可能会损害基准测试或历史分析，这些分析掩盖了真实世界的行为变化，而这些行为变化实际上是由未记录的模型变化引起的。

SS循环实施

因此，鉴于这些痛点和挑战，我们将讨论如何在Outreach的实际用例中克服其中一些问题。之后，我们还将分享我们继续面临的一些挑战，以及在未来工作中应对这些挑战的想法。

用例:引导参与

我们要讲的用例是外联引导参与功能。这是一种基于收件箱的智能体验，由底层的密集分类模型提供支持。当销售代表收到来自潜在客户、现有客户或未来客户的回复时，Outreach会预测并显示潜在客户电子邮件的意图。或许正面，前景是愿意满足的。或者在这种情况下，反对，前景已经有了解决方案。基于预测的意图，相关内容被推荐给销售代表，为了简单起见，我们的讨论将只关注意图预测组件，文本分类，而不是内容推荐组件。

六个阶段

当我们讨论我们的用例和痛点时，我们将参考我们在机器学习完整模型生命周期中的位置。

在这次演讲中，我们将重点关注中间阶段，从模型开发开始。这是我们离线运行许多实验的地方，以快速迭代和开发我们想要摆脱的获胜模型的模型对象。在预开发阶段，我们成熟并将获胜的模型逻辑打包到软件中，然后发布用于生产。对于我们的用例，这将发布一个docker映像和经过训练的模型工件。我们将讨论的最后两个阶段，模型登台和模型prod是模型托管的地方，为外延暴露端点，我们的产品应用程序要调用。

=模型开发和离线实验MLFlow跟踪服务器记录所有离线实验

因此，从我们用例的模型开发阶段开始，我们的大部分开发都是在Databricks或Jupiter notebook中进行的，代码存储库仅用于脱机开发模型逻辑和运行脱机实验。尽管我们不打算发布此代码，但我们确实利用MLflow跟踪将实验与结果联系起来。这个来源避免了不必要的重复实验多次，并为获胜的模型提供了联系和基线。我们的模型开发通常包括许多建模框架和技术，每种框架和技术都有不同的api。对于这个特殊的模型，我们使用Scikit Learn、fastText和Flair来探索svm。最终，我们选择了huggingface transformer库，因为它的统一API是最先进的深度变压器架构和预训练语言模型。在这个领域，技术水平是一个快速变化的目标，所以一个拥有活跃社区的项目可以迅速缩小已发表研究成果之间的差距，这对我们来说很重要。

创建一个转换器风味模型

虽然势头强劲，但huggingface变形金刚库是一个相对年轻的项目，还不是原生MLflow风格。通过扩展MLflow并编写自己的MLflow风格(允许我们插入MLflow框架的其余部分)，我们避免了任意唯一性。这意味着什么呢?这意味着我们编写了一个小的包装器类，如左侧所示，它映射huggingface transformer库，该库本身将大量强大的体系结构和模型包装到标准MLflow模型的API。

这能得到什么呢?除此之外，这为我们购买了一个用于模型序列化的标准机制，包括保存和加载。我们还编写了一个与Scikit Learn管道兼容的变压器分类器类。因此，我们可以将转换模型与预处理和后处理步骤连接起来。为什么我们需要这个?因此，当我们遇到像挑战三那样的场景时，我们就需要这样做，因为数据源不同，培训和刺激平台需要不同，或者有不同的业务逻辑，希望用于生产而不是培训。bob体育客户端下载我们场景中的一个例子是从生产评分中过滤电子邮件自动回复，但不是在模型训练中。

这里我们有一个例子

保存和加载Iransformet文物

从MLflow跟踪服务器API保存的转换器模型，只有MLflow跟踪服务器及其相关工件，如左侧所示。右边的代码片段只显示了记录或加载模型的几行代码。这绕过了手动处理Python的pickle或其他序列化协议所涉及的任意唯一性，这些协议可能会很挑剔，并将负担传递给模型的消费者。

产品化代码和Git回购

在pre prod中，我们有意地重写代码，并将其从开发笔记本重构为实际运行在生产中的软件。我们采用了MLflow的MLproject模式。MLproject是一个相当轻量级的层，它集中了入口点，并在环境定义管理中标准化了它们的配置。同样，通过为管道提供一个自文档框架来避免与任意唯一性相关的痛苦的廉价方法。

从工作流的角度来看，我们发现MLproject运行远程代码和在远程集群上执行的灵活性实际上也加速了我们的开发，并加强了我们的一些测试和代码审查，比如重新生成模型结果。

通过引用要运行的代码，通过引用GitHub发布标签或(不清楚)显示在红色的代码来运行，我们能够为自己购买改进的出处，将源代码直接绑定到模型工件和MLflow跟踪的结果。从工作流的角度来看，这也避免了手动克隆和运行本地代码的麻烦。

引用远程执行环境，如绿色所示，允许我们在选择的ide中开发Databrick笔记本电脑之外的代码，同时还利用Databricks运行时的执行能力和强大的基于GPU的集群。

为了支持特定于部署的逻辑和环境，我们逐步创建了三种模型

-现在，假设我们有一个生产级训练过的NLP模型，用于电子邮件的意图分类。这是否意味着我们可以部署到生产环境?其实没那么快。这是因为在部署环境的逻辑方面存在不可避免的差异，我们已经在挑战部分讨论过了。这就是为什么我们要创建三个逐步演进的模型，以便在主机环境中进行最终部署。在我们的例子中，这是Sagemaker。首先，我们创建一个经过微调的训练好的变压器分类器，然后我们用预处理和后处理步骤包装同一个分类器，我们称之为pre-score和post-score过滤器。这整个包裹的管道变成了一个圆形的管道。这基本上就是图中间所示的管道。

我们需要一些预先评分过滤器的原因是，我们需要额外的逻辑，例如，是传递电子邮件只获取当前的回复消息体，还是获取完整的电子邮件线程。或者如果电子邮件说它太大了，我们可能会决定根本不打分。或者，当电子邮件内容完全相同时，我们可能想使用一些缓存机制。我们可以只返回预测的缓存结果。

因此，对于后期处理部分，即后期评分过滤器，我们还可以在响应中添加额外的模型元数据，以便我们可以从调用方跟踪来源。注意，分类器本身没有模型逻辑变化，但是有了第二个模型管道就灵活多了。最后，在生产环境中，我们不希望模型访问我们的私有GitHub，因为访问私有GitHub需要一个GitHub令牌或访问密钥，这是企业生产环境中的安全问题。因此，我们创建了第三个模型，它将所有私有Python依赖项打包到prod wheels中，然后将它们刻录到docker映像中，以便在部署时，模型可以引用它们，而无需访问私有GitHub。

通过CircleCl进行持续集成

所以现在我们已经准备好通过CICD工具完全自动化部署了。对于CI部分，即持续交付部分，或持续集成部分，我们使用CircleCI。CircleCI管道不仅执行单元测试和样式强制，而且还运行整个链，测试、封装和部署，一直到Sagemaker端点。使用训练数据的子集，这可以保护任何代码检查。注意，离开CircleCI的几个步骤在我们前面讨论的同一个MLproject入口点中被重用。

这还允许我们甚至打破开发-prod的界限，因为我们也可以使用相同的CI管道来运行一些实验性代码或模型更改，而无需重复工作。

现在对于CD产品，那是连续的交付和回滚，我们在外联使用Concourse。这个管道有两个明确定义的人门。首先，对于模型构建，一个指定的人需要启动整个管道，一旦它通过了回归测试，并确保我们得到的模型不会比前一个模型更差，那么第二个人门也需要一个人来将模型提升到生产端点。在这里，最后一步我们展示了我们可以部署到Sagemaker美国东部和美国西部地区。

跟踪已部署模型来源的模型注册中心

因此，在CICD自动化中，我们不仅锁定模型，而且使用MLflow模型注册表注册模型。从模型注册表中，我们可以清楚地看到模型的哪个版本处于生产阶段，哪个版本处于登台阶段。如果你对模型的更多细节感兴趣，你可以点击版本链接，你可以找到模型的providence信息。

现在我们已经完成了四个生命周期的实现。我们如何应对我们在开头谈到的四个挑战?我们觉得在来源追踪方面，我们在这四个阶段都做得很好。

除了模型开发阶段，我们还很好地克服了其他三个挑战。特别地，我们觉得我们在模型预刺激过程中很好地接受了dev-prod划分和任意唯一性，在这里我们编写了生产代码和发布的转换器风格模型，使模型代码和部署过程可重用和可重复。然而，我们不太满意的一个方面是在模型登台期间，我们没有真正使用生产实时流通信进行测试，在我们将模型推广到生产之前，本可以通过一些AB测试机制来完成。这是我们将来要解决的问题。因此，在总结中，我们强调了四个典型的企业AI实现挑战，以及我们如何使用ML流、Sagemaker和CICD工具解决这些挑战。我们指导交战的意图分类模型已经使用该框架部署在生产和操作中。

我们接下来的步骤，除了我们提到的使用AB测试机制对模型进行测试阶段之外，我们还将解决以下问题。首先，将生产中的模型反馈循环纳入注释和模型开发周期。其次，我们正在进一步改进注释管道，以实现无缝的人在循环中主动学习和模型验证。最后，我们要感谢Outreach数据科学小组的每一位为这个项目做出贡献和支持的人。如果您有兴趣了解更多关于我们的经验和外展平台的详细信息，请通过屏幕所示的电子邮件地址与我们联系。bob体育客户端下载

非常感谢。