在实践中为您的深度学习管道构建 QA 流程

2024-03-31   出处: stackoverflow  作/译者:Tobias Kupek/Mint

深度学习模型仍然需要测试,但是许多常见的测试方法并不适用于此。而如果使用正确的方法,您就可以确保您的管道产生良好的结果。

软件是复杂的,作为开发人员,我们都了解构建一个良好的质量保证(QA)过程的必要性。然而,训练深度学习模型并在生产中实施这些模型会给测试质量带来新的挑战。许多众所周知的测试方法并不直接适用于深度学习模型。本博文将为您提供一些关于完整深度学习管道的QA流程的实用见解。

QA在深度学习中是与众不同的

在一般的软件QA中,您可以在软件崩溃时发现故障,然后通过断点和打印语句慢慢地将错误逼到死角。深度学习模型会悄无声息地发生故障。由于有许多候选故障点,因此很难确定确切的故障点。次优学习率或错误标记的样本不会引发堆栈跟踪;它只会使结果恶化,直至变得毫无用处。在这个过程中,我们很难按部就班地进行分步调试。

您是否曾经尝试过了解 ResNet50 模型 2,500 万个参数中的一个参数的影响?由于深度学习模型过于复杂,无法理解其中的依赖关系。只有当训练和推理管道中的所有元素都按预期工作时,黑盒(模型)才能正确解决问题。算法越复杂,对部署的软件影响越大,就越需要进行质量检查。因此,一个可靠的QA流程对于深度学习项目的长期成功至关重要。

一个标准的深度学习管道如下图:

数据作为算法的一部分

请记住,训练数据的作用与传统算法中数据的作用(即与数据库中的客户数据相比)截然不同。数据不仅会被算法被动处理,还会通过影响模型训练来主动塑造解决方案。没有合适的数据,任何深度学习管道都无法取得良好的效果。训练数据QA流程的难点在于我们必须处理的样本量。对整个数据集进行人工检查和测试几乎是不可能的,而且成本很高。

为了解决这个问题,我们需要定义一些重要的指标,如样本的最低质量、不同类别的平衡要求或样本的相似度分数。最好先对一小部分数据进行人工抽查,以便了解数据集的情况和可能出现的问题。当我们知道要查找什么时,就可以使用统计方法来深入了解整个数据集。与我们的代码一样,数据集也会在开发过程中发生变化,因此需要自动化统计过程并反复收集数据集的元数据。这有助于我们跟踪和了解质量随时间的变化。

除了原始数据方面的挑战,在预处理过程中也可能会出错。为了测试数据准备是否正确、有用,请编写单元测试。对于某些操作,可以检查该过程是否可以正确还原(图像的归一化)。在将数据输入到下一步之前,验证整个数据管道。没有有用的数据,就无法训练出有用的模型。

数据质量清单:

  • 定义重要指标
  • 抽查数据子集
  • 自动计算数据集,统计数据并跟踪变化
  • 验证从抓取、标记到预处理的整个数据管道

正确开展培训

老实说,目前我们已经发布了数百种很酷的训练方法、调整算法和实验参数,这让深度学习模型的实验变得非常有意思。但是,在开发过程的一开始就实施所有最新的研究成果,往往不会产生更好的模型,反而会浪费资源、浪费时间,让人失望。同时,一次性实施太多未经测试的功能会使调试变得非常困难。即使结果不错,谁又知道它们是否是给定输入的最优结果呢?

一个基本的模型架构和安全的默认参数可以在开始时提供帮助。自动化系统测试,检查诸如减少损失、有效输出和成功更新权重等基本情况。在此基础上,可以增加架构的复杂度,调整超参数,并添加更多花哨的算法。要特别注意指标的正确计算,因为未来的决策和模型选择都将基于这些指标。如果模型中有自定义部分(即非标准层或损失函数),进行单元测试可能是一个好办法。

为了从一组训练迭代中选出最佳模型,我们会对性能指标进行分析。但是,独立的烟雾测试有助于我们发现缺陷,让我们对结果更有信心,并改进模型的正则化。尽可能使这一验证步骤独立于训练过程(例如,使用单独的推理管道),有助于我们识别可能存在的bug。为此,我们应使用人工创建的离散测试集,其中包括边缘情况和困难样本。

模型训练清单:

  • 从基本模型设置开始,逐步增加复杂性
  • 包括额外的指标测试
  • 对模型的自定义部分进行单元测试
  • 用精心设计的测试集验证最终模型,以获得信心

避免部署过程中的失败

为了解决实际问题,部署模型是非常有必要的。在通常情况下,推理环境和引擎的外观和行为可能与训练设置大相径庭。已部署的系统可能会对输入进行不同的预处理,导致结果无法使用或略有恶化。此外,一些硬件可能会削减输出或以不同的精度进行计算,所以我们应针对每种用例进行单独测试。同时,我们应该定期部署以便快速发现问题,因此我们(再次)需要自动化。为了在生产中实施模型,我们可以采用持续集成和部署(CI/CD)的标准软件工程原则。

测试部署清单:

  • 自动导出模型并包含推理所需的参数
  • 对所有设备类型和配置进行集成测试
  • 频繁部署,尽早在单独的预生产环境中部署

测试管道

为确保解决方案真正解决问题,建议使用从真实世界中精选的数据样本进行最终的端到端测试。该最终测试应该针对问题陈述进行高度针对性的测试,并应不断检查整个管道是否按预期工作。对于目标跟踪,可以标记一小部分视频,然后在测试目标设备上测试计数或跟踪精确度。对于文本情感分析,使用真实世界的评论进行测试可以显示出潜在的缺陷。另一种方法是定性调查,可以询问系统用户他们认为的标准场景是什么。

最终质量检查:

  • 使用目标平台上的真实数据执行端到端的测试
  • 优先考虑实际用例,而不是合成数据和人为场景
  • 跟踪不同软件版本的测试准确性
  • 包括边缘情况的测试(例如意外输入)

使用管道和迭代

最后,对代码和数据都使用版本控制。这有助于记录更改和调试可能出现的问题。不建议同时更改数据和算法,因为这样做的效果无法追溯。

既然流程已经建立,测试和验证也已到位,一切都已自动化,那么现在就该增加实验次数了。尝试新的方法,找到最佳解决方案。我们现在可以很有信心地做到这一点,因为我们可以在流程的早期识别故障并正确验证结果。切记定期测试和部署,并在适当的地方添加新的测试。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
171° /1714 人阅读/0 条评论 发表评论

登录 后发表评论