将介绍传统软件开发的测试外观，测试机器学习系统为何会有所不同的原因，并讨论为机器学习系统编写有效测试的一些策略。我们还将阐明在模型开发过程中，评估和测试的紧密相关角色之间的区别。在本博客文章的结尾，我希望您对有效测试机器学习系统所需的额外工作以及完成这些工作的价值深信不疑。
测试机器学习系统有什么不同？
在传统软件系统中，人们编写与数据交互以产生所需行为的逻辑。我们的软件测试有助于确保此书面逻辑符合实际的预期行为。



但是，在机器学习系统中，人类在训练期间会提供所需的行为作为示例，并且模型优化过程会产生系统的逻辑。我们如何确保这种学到的逻辑能够始终如一地产生我们期望的行为？

让我们从测试传统软件系统和开发高质量软件的最佳实践开始。

典型的软件测试套件将包括：

单元测试可对代码库的基本部分进行操作，并且可以在开发过程中快速运行，
回归测试会复制我们先前遇到和修复的错误，
集成测试，通常是运行时间较长的测试，它们观察到利用代码库中多个组件的更高级别的行为，
并遵循以下约定：

除非所有测试都通过，否则不要合并代码，
在贡献代码时，总是为新引入的逻辑编写测试，
在提供错误修复程序时，请确保编写测试以捕获该错误并防止将来发生退化。



当针对新代码运行测试套件时，我们将获得有关编写测试的特定行为的报告，并验证我们的代码更改不会影响系统的预期行为。如果测试失败，我们将知道哪种特定行为不再符合我们的预期输出。我们还可以查看此测试报告，通过查看诸如代码覆盖率之类的指标来了解我们的测试范围。



让我们将此与用于开发机器学习系统的典型工作流进行对比。在训练了新模型之后，我们通常会生成评估报告，其中包括：

在验证数据集上建立指标的效果，
诸如精确调用曲线，
运算统计资料，例如推理速度，
该模型最有可能是错误的示例
并遵循以下约定：

保存用于训练模型的所有超参数，
仅推广在同一数据集上进行评估时可对现有模型（或基准）进行改进的模型。


在审查新的机器学习模型时，我们将检查指标和绘图，这些数据和绘图总结了验证数据集上的模型性能。我们能够比较多个模型之间的性能并做出相关判断，但是我们无法立即表征特定模型的行为。例如，找出其中的模型通常没有需要额外的调查工作; 一种常见的做法是浏览验证数据集上最严重的模型错误的列表，然后手动对这些故障模式进行分类。

假设我们为模型编写行为测试（下面讨论），还有一个问题，就是我们是否有足够的测试！尽管传统的软件测试具有度量标准，例如运行测试时覆盖的代码行，但是当您将应用程序逻辑从代码行转换为机器学习模型的参数时，这变得更加难以量化。我们是否要量化关于输入数据分布的测试范围？还是模型内部可能的激活？

Odena等。引入一种可能的覆盖率指标，在其中我们跟踪所有测试示例的模型logit并量化这些激活向量周围的径向邻域覆盖的面积。但是，我的看法是，作为一个行业，我们在这里没有公认的惯例。实际上，感觉机器学习系统的测试还处于早期阶段，因此很多人并没有真正问到这个测试覆盖率问题。

模型测试和模型评估之间有什么区别？
虽然报告评估指标当然是在模型开发过程中进行质量保证的良好做法，但我认为这还不够。没有具体行为的详尽报告，如果我们切换到新模型，我们将无法立即了解行为可能会如何变化的细微差别。此外，我们将无法跟踪（并防止）先前已解决的特定故障模式的行为回归。

这对于机器学习系统而言尤其危险，因为经常会无声地发生故障。例如，您可能会改善总体评估指标，但会对关键数据子集引入回归。或者，您可能会在不知不觉中通过在训练过程中包含新的数据集来向模型添加性别偏见。我们需要更多细致的模型行为报告来识别此类情况，这正是模型测试可以提供帮助的地方。

对于机器学习系统，我们应该并行运行模型评估和模型测试。

模型评估涵盖度量和绘图，这些度量和绘图总结了验证或测试数据集的性能。
模型测试涉及对我们期望模型遵循的行为的显式检查。
这两种观点都有助于建立高质量的模型。

在实践中，大多数人都将两者结合起来，即自动计算评估指标，并通过错误分析（即对故障模式进行分类）手动完成某种级别的模型“测试” 。为机器学习系统开发模型测试可以为错误分析提供系统的方法。

您如何编写模型测试？
我认为，我们将要编写两类通用的模型测试。

培训前的 测试使我们能够及早发现一些错误并缩短培训工作。
训练后测试使用训练有素的模型工件来检查我们定义的各种重要场景的行为。
训练前测试
我们可以进行一些测试，而无需训练有素的参数。这些测试包括：

检查模型输出的形状，并确保其与数据集中的标签对齐
检查输出范围并确保其符合我们的期望（例如，分类模型的输出应为类别概率总和为1的分布）
确保对一批数据执行单个梯度步骤可以减少损失
对数据集进行断言
检查训练和验证数据集之间的标签泄漏
这里的主要目标是及早发现一些错误，以便我们避免浪费培训工作。

训练后测试
但是，为了使我们能够理解模型行为，我们需要针对训练有素的模型工件进行测试。这些测试旨在询问在训练中学习到的逻辑，并向我们提供模型性能的行为报告。

论文重点：超越准确性：使用CheckList对NLP模型进行行为测试
https://homes.cs.washington.edu/~marcotcr/acl20_checklist.pdf
以上论文的作者介绍了三种可用于了解行为属性的模型测试。

不变性检验

不变性检验使我们能够描述在不影响模型输出的情况下应该对输入进行的一组扰动。我们可以使用这些扰动来生成输入示例对（原始的和扰动的），并检查模型预测中的一致性。这与数据扩充的概念密切相关，在训练过程中，我们将扰动应用于输入并保留原始标签。

例如，假设对以下两个句子运行情感分析模型：

马克是一位了不起的教练。
萨曼莎（Samantha）是一位出色的教练。
我们希望仅更改主题名称不会影响模型预测。

定向期望测验

另一方面，方向期望测试使我们可以定义一组对输入的扰动，这些扰动应对模型输出产生可预测的影响。

例如，如果我们有一个房价预测模型，我们可以断言：

增加浴室的数量（保持所有其他功能不变）不会导致价格下降。
降低房屋的平方英尺（保持所有其他特征不变）不应导致价格上涨。
让我们考虑一个模型在第二次测试中失败的情况-从我们的验证数据集中随机抽取一行，并降低特征house_sq_ft量会产生比原始标签更高的预测价格。这令人惊讶，因为它不符合我们的直觉，因此我们决定进一步研究。我们意识到，在没有房屋的邻里/位置特征的情况下，我们的模型已经了解到，较小的单元往往更昂贵；这是由于以下事实：我们数据集中的较小单位在价格通常较高的城市中更为普遍。在这种情况下，我们数据集的选择以意想不到的方式影响了模型的逻辑-这不是我们仅通过检查验证数据集的性能就能识别出的。

最低功能测试（又称数据单元测试）

就像软件单元测试旨在隔离和测试代码库中的原子组件一样，数据单元测试使我们能够针对数据中发现的特定案例量化模型性能。

这使您能够确定预测错误导致严重后果的关键方案。您还可以决定针对错误分析期间发现的故障模式编写数据单元测试。这使您可以“自动”搜索将来模型中的此类错误。

Snorkel还通过其切片功能的概念引入了一种非常相似的方法。这些是程序功能，可让我们识别出满足某些条件的数据集子集。例如，您可以编写一个切片函数以识别少于5个单词的句子，以评估模型在短文本上的表现。

组织测试
在传统的软件测试中，我们通常组织测试以反映代码存储库的结构。但是，这种方法不能很好地转换为机器学习模型，因为我们的逻辑是由模型的参数构成的。

上面链接的CheckList论文的作者建议围绕我们期望模型在学习执行给定任务时获得的“技能”构建测试。

例如，可能需要一种情绪分析模型来了解以下方面：

词汇和词性，
抗噪声能力强，
识别命名实体，
时间关系，
和否定词。
对于图像识别模型，我们可能希望模型学习以下概念：

对象旋转
部分遮挡
视角转变
光照条件
天气文物（雨，雪，雾），
和相机伪像（ISO噪点，运动模糊）。
模型开发流程
综上所述，我们可以修改模型开发过程图，以包括训练前和训练后的测试。这些测试输出可以与模型评估报告一起显示，以便在管道的最后一步中进行审查。根据模型训练的性质，您可以选择自动批准模型，只要它们符合某些指定条件。




结论
由于我们并未明确编写系统逻辑，因此机器学习系统的测试难度更大。但是，自动化测试仍然是开发高质量软件系统的重要工具。这些测试可以为我们提供训练有素的模型的行为报告，可以作为错误分析的系统方法。

在整个博客文章中，我已经将“传统软件开发”和“机器学习模型开发”作为两个独立的概念进行了介绍。这种简化使得讨论与测试机器学习系统相关的独特挑战变得更加容易。不幸的是，现实世界更加混乱。开发机器学习模型还依赖于大量的“传统软件开发”来处理数据输入，创建特征表示，执行数据扩充，编排模型训练，向外部系统公开接口等等。因此，对机器学习系统的有效测试既需要传统的软件测试套件（用于模型开发基础结构），又需要模型测试套件（用于经过训练的模型）。