Amazon SageMaker ML 模型的测试方法

由柏拉图重新发布

关注： 0

这篇文章是与 Intuit 机器学习平台的软件工程经理 Tobias Wenzel 共同撰写的。

例如，在使用自动驾驶或与 Alexa 交互时，我们都明白高质量和可靠的机器学习 (ML) 模型的重要性。 ML 模型还以不太明显的方式发挥着重要作用——它们被商业应用程序、医疗保健、金融机构、amazon.com、TurboTax 等使用。

随着支持 ML 的应用程序成为许多企业的核心，模型需要遵循与软件应用程序相同的活力和纪律。 MLOps 的一个重要方面是通过使用已建立的 DevOps 实践（例如测试、版本控制、持续交付和监控）在生产中交付先前开发的 ML 模型的新版本。

有几个规定性的有关 MLOps 的指南，这篇文章概述了您可以遵循的过程以及用于测试的工具。这是基于双方的合作意会和 AWS。我们一直在共同努力，在实践中大规模实施本文中解释的建议。 Intuit 的目标是成为人工智能驱动的专家平台很大程度上依赖于提高初始模型开发速度以及测试新版本的策略。

岗位要求

以下是部署新模型版本时需要考虑的主要方面：

模型精度性能 – 重要的是跟踪模型评估指标，如准确度、精度和召回率，并确保客观指标保持相对相同或随着模型的新版本而改进。在大多数情况下，如果最终用户的体验没有得到改善，那么部署新版本的模型是没有意义的。
测试数据质量 – 非生产环境中的数据，无论是模拟的还是时间点副本，都应该代表模型在完全部署时将接收到的数据，无论是数量还是分布。否则，您的测试过程将不具有代表性，并且您的模型在生产中的行为可能会有所不同。
特征重要性和奇偶性 – 新版本模型中的特征重要性应与旧模型相对比较，尽管可能会引入新特征。这是为了确保模型不会出现偏差。
业务流程测试 – 重要的是，新版本的模型可以在可接受的参数范围内实现您所需的业务目标。例如，其中一个业务指标可以是任何服务的端到端延迟不得超过 100 毫秒，或者托管和重新训练特定模型的成本每年不得超过 10,000 美元。
价格 – 一种简单的测试方法是将整个生产环境复制为测试环境。这是软件开发中的常见做法。但是，对于 ML 模型，这种方法可能不会产生正确的 ROI，具体取决于数据的大小，并且可能会影响模型解决的业务问题。
安保行业 – 通常期望测试环境具有样本数据而不是真实的客户数据，因此，数据处理和合规性规则可能不那么严格。就像成本一样，如果您只是将生产环境复制到测试环境中，您可能会引入安全和合规风险。
功能存储可扩展性 – 如果组织由于成本或安全原因决定不创建单独的测试功能存储，则需要在生产功能存储上进行模型测试，这可能会导致可扩展性问题，因为在测试期间流量会增加一倍。
在线模型性能 – 在线评估与离线评估不同，在某些情况下（如推荐模型）可能很重要，因为它们实时衡量用户满意度而不是感知满意度。由于季节性或其他用户行为，在非生产环境中很难模拟真实的流量模式，因此在线模型性能只能在生产环境中完成。
经营业绩 – 随着模型变得越来越大，并且越来越多地以分散方式部署在不同的硬件上，测试模型以获得所需的操作性能（如延迟、错误率等）非常重要。

大多数 ML 团队都有多管齐下的模型测试方法。在以下部分中，我们提供了在不同测试阶段应对这些挑战的方法。

离线模型测试

此测试阶段的目标是从准确性的角度验证现有模型的新版本。这应该以离线方式完成，以免影响生产系统中提供实时预测的任何预测。通过确保新模型在适用的评估指标上表现更好，该测试解决了挑战 1（模型准确度性能）。此外，通过使用正确的数据集，此测试可以解决挑战 2 和 3（测试数据质量、特征重要性和奇偶性），以及解决挑战 5（成本）的额外好处。

此阶段在暂存环境中完成。

您应该捕获生产流量，您可以使用这些流量在离线回测中重放。最好使用过去的生产流量而不是合成数据。这 Amazon SageMaker模型监控器捕获数据功能允许您捕获托管模型的生产流量亚马逊SageMaker. 这允许模型开发人员使用高峰工作日或其他重要事件的数据来测试他们的模型。然后使用新模型版本以批处理方式重放捕获的数据 Sagemaker 批量转换. 这意味着批处理转换运行可以在短短几个小时内使用数周或数月收集的数据进行测试。与并行运行两个或多个版本的实时模型并向每个端点发送重复的预测请求相比，这可以显着加快模型评估过程。除了更快地找到性能更好的版本之外，这种方法还可以在更短的时间内使用计算资源，从而降低总体成本。

这种测试方法的一个挑战是功能集会从一个模型版本更改为另一个模型版本。在这种情况下，我们建议为两个版本创建一个具有超集功能的功能集，以便可以一次查询所有功能并通过数据捕获进行记录。然后，每个预测调用只能处理当前模型版本所需的那些特征。

作为额外的奖励，通过整合亚马逊SageMaker澄清在您的离线模型测试中，您可以检查新版本的模型是否存在偏差，还可以将特征归因与模型的先前版本进行比较。使用管道，您可以编排整个工作流程，以便在训练后进行质量检查步骤，以执行模型指标和特征重要性的分析。这些指标存储在 SageMaker模型注册表以便在下一次训练中进行比较。

集成和性能测试

需要集成测试来从功能和运行时性能的角度验证端到端业务流程。在这个过程中，应该测试整个管道，包括在特征存储中获取和计算特征以及运行 ML 应用程序。这应该使用各种不同的有效负载来完成，以覆盖各种场景和请求，并实现所有可能的代码运行的高覆盖率。这解决了挑战 4 和 9（业务流程测试和运营绩效），以确保新版本的模型不会破坏任何业务流程。

此测试应在暂存环境中完成。

集成测试和性能测试都需要由各个团队使用他们的 MLOps 管道来实施。对于集成测试，我们建议采用久经考验的方法来维护功能等效的预生产环境并使用一些不同的有效负载进行测试。测试工作流程可以自动化，如图所示这个工作坊. 对于性能测试，您可以使用 Amazon SageMaker 推理推荐器，它提供了一个很好的起点来确定要使用哪种实例类型以及这些实例的数量。为此，您需要使用负载生成器工具，例如开源项目 perfsizesagemaker 回复和性能大小 Intuit 开发的。 Perfsizesagemaker 允许您使用各种有效负载、响应时间和每秒峰值事务要求自动测试模型端点配置。它生成比较不同模型版本的详细测试结果。 Perfsize 是一个配套工具，它只在给定每秒事务峰值和预期响应时间的情况下尝试不同的配置。

A / B测试

在许多需要用户对模型的即时输出做出反应的情况下，例如电子商务应用程序，离线模型功能评估是不够的。在这些场景中，您需要在做出更新模型的决定之前在生产环境中对模型进行 A/B 测试。 A/B 测试也有其风险，因为可能会对客户产生真正的影响。此测试方法用作最终的 ML 性能验证，即轻量级工程健全性检查。该方法还解决了挑战 8 和 9（在线模型性能和卓越运营）。

A/B 测试应该在生产环境中进行。

使用 SageMaker，您可以通过运行轻松地对 ML 模型执行 A/B 测试多种生产变体在一个端点上。流量可以增量路由到新版本，以降低行为不良模型可能对生产造成的风险。如果 A/B 测试的结果看起来不错，则将流量路由到新版本，最终占据 100% 以上的流量。我们建议使用部署护栏从模型 A 过渡到 B。有关 A/B 测试的更完整讨论，使用亚马逊个性化以模型为例，参考使用A / B测试来衡量Amazon Personalize生成的建议的有效性.

在线模型测试

在这种情况下，模型的新版本与已经在生产中提供实时流量的模型存在显着差异，因此离线测试方法不再适合确定新模型版本的功效。最突出的原因是生成预测所需的特征发生了变化，因此以前记录的交易不能用于测试模型。在这种情况下，我们建议使用影子部署。影子部署提供了部署影子（或 挑战者) 模型旁边的生产（或冠军) 当前提供预测的模型。这使您可以评估影子模型在生产流量中的表现。影子模型的预测不提供给请求的应用程序；他们被记录下来进行离线评估。通过影子测试方法，我们解决了挑战 4、5、6 和 7（业务流程测试、成本、安全性和功能存储可扩展性）。

在线模型测试应在暂存或生产环境中进行。

如果无法使用所有其他方法，则应将这种测试新模型版本的方法用作最后的手段。我们推荐它作为最后的手段，因为对多个模型的双工调用会在生产中的所有下游服务上产生额外的负载，这可能会导致性能瓶颈以及生产成本的增加。最明显的影响是对特征服务层。对于从公共物理数据池共享功能的用例，我们需要能够模拟多个用例同时访问同一个数据表，以确保在过渡到生产之前不存在资源争用。在可能的情况下，应避免对特征存储的重复查询，并且应将模型的两个版本所需的特征重用于第二次推理。特色商店基于 Amazon DynamoDB，正如 Intuit 构建的那样，可以实现 Amazon DynamoDB 加速器(DAX) 来缓存并避免数据库的 I/O 加倍。这些和其他缓存选项可以缓解挑战 7（功能存储可扩展性）。

为了解决挑战 5（成本）和挑战 7，我们建议使用影子部署对传入流量进行采样。这为模型所有者提供了另一层控制，以最大限度地减少对生产系统的影响。

影子部署应该加入到模型监视器就像常规的生产部署一样，以观察挑战者版本的改进。