机器学习测试：使用模拟器测试训练好的功能的见解和经验_

作者 | Martin Karsberg

译者 | 王强

策划 | Tina

要点

测试机器学习（ML) 应用程序的思路就像是测试黑盒，就算你看过模型的内部结构，也很难理解和解释训练出来的模型功能所做出的决策。
训练和测试数据集的分布定义了模型的功能；你可以对数据分区，以表示所有已定义的有效测试场景以及功能所定义的场景。
你可以使用运行设计域（ODD）来定义 ML 功能的需求。当发现程序行为与你的期望不符时，你必须弄清楚自己是在 ODD 之内还是之外。
例如，模拟器通过识别和分离训练数据中一幅图像中的对象来支持注释能力。模拟器是一种工具驱动的辅助工具，用于测试那些我们无法生成“真实世界”数据的场景，并且可以通过控制环境（交通、天气、基础设施等）变量来加快测试执行速度。
在使用 ML 应用程序时，丛传统代码测试中获得的知识和经验非常有价值。在测试这些应用程序时，了解黑盒测试技术和相关的领域知识是非常有用的。

当新技术出现时，我们必须搞明白该怎样测试这些新东西。我对训练好的模型和机器学习功能的验证和认证过程做了很多研究，并将研究成果应用到了测试环节，从而在机器学习应用程序测试方面获得了很多见解和经验，并将在本文中分享它们。

对于机器学习应用程序来说，代码本身没什么意思。机器学习应用程序不是由复杂且庞大的代码库所构建的功能或函数，而是由几行代码组成，通过权重数据点组成的复杂网络来实现的应用。训练中使用的数据定义了最终的应用功能，也是你发现问题和错误的去处。数据是所有训练好的模型功能的关键所在。

在测试机器学习系统时，我们必须换一种方式来应用现有的测试流程和方法。测试应该是独立的，并且对任何代码或功能都采用全新的方法。我们还需要创建独立的测试集，而不是依赖训练过程中的验证部分来对付过去。

我们必须解决版本处理的问题。机器学习中有着名为 CACE（Change Anything，Change Everything）的概念和原理。机器学习程序的功能被认为是不透明的，因此在某种程度上，它是一个黑匣子。

这就意味着测试过程至少是非常耗时的，并且我们很难准确理解程序的结果是如何出来的。它可以追溯到训练数据和训练时使用的权重的分布，以及网络的类型上。从测试人员的角度来看，最好将这种功能视为超级黑匣子。这也意味着，如果我们出于某种原因决定重新训练，那么将新模型视为 2.0 而不是 1.2 版本是更合理的。

测试机器学习功能

在测试机器学习 (ML) 时，模型的功能并不是那么有趣。代码变得有点无关紧要。对于老派测试人员来说，代码和函数就是“路子”。而对于机器学习来说，你验证或测试的功能很大程度上是基于训练数据的。当我们将焦点从代码转移到训练数据时，单元测试或“接近代码”的方法最后会变成测试那些用来训练功能的数据，而不是测试单个代码语句或函数。

继续往上走过各个传统的测试级别时，模拟器等工具可以帮助我们测试或验证程序功能。但是我们在这里（在模拟器中）或在生产中（你启动的系统或自动驾驶车辆之类）发现的任何问题都需要以某种结构化方式更改训练数据来解决。

在测试训练好的功能时，了解训练数据每次都是重点。对训练数据的分布和组成做检查可以代替单元测试。审查发行版（静态测试）可以被视为早期测试，就像审查需求的代码审查流程一样。尽早检查你的数据集以识别不需要的分布或偏差，这样就可以避免在后期阶段遇到功能表现不佳的问题。

在运行和测试训练好的功能时，它与“传统”代码和测试活动的另一点区别在于，每次更改或错误修复都会为你提供一个新功能。它与传统测试不同，在传统测试中，你可以把修复隔离开来并重新测试，并在附近的功能区域做一些回归。你需要将这个新功能视为该功能的全新版本，并且可能需要对它完整运行你的测试套件。当然，你可以通过巧妙的风险管理等办法来加快流程，并且在工具和模拟器的帮助下，这一流程可以更加高效。

定义或设计机器学习系统

在定义机器学习系统时，我们首先想到的一件事情就是需求。描述和指定需求的传统方法对于训练好的功能来说效果不怎么样。在我从事的项目中，我们使用操作设计域（ODD）来定义模型应有功能的上下文。

你可以将 ODD 视为定义 ML 功能需求的一种方式。以自动驾驶为例，我们可以分成几个类别：

场景

路口
农村或城市
公路 / 越野

动态

天气（雨、雾……）
照明（白天、夜晚......）

环境

交通（行人、汽车、自行车......）
你的汽车或者你在对应场景中开发的功能

当你发现程序行为与你的期望不符时，你必须弄清楚自己是在 ODD 之内还是之外。如果你发现该行为发生在外部，你可能需要将其视为错误或异常以做进一步调查。

训练数据的分布决定了训练好的功能的大部分性能。考虑到这一点，“错误修复”实际上指的是改变训练数据分布，而不是改变代码行。

数据是关键所在

训练和测试数据集的分布是非常重要的。程序的功能差不多就是在这里被定义的。那么，我们如何测试，并确认自己拥有所有重要的数据元素来训练具有正确性能的 ML 模型呢？

当然，我们需要考虑分布情况。这里比较困难的一个部分是背景（例如文化或国家差异）和偏见。作为独立参与者，QA 在这里就可以发挥他们的作用，提出对训练数据或其他数据集的担忧。外部视角是一件好事。对数据进行分区以确保它们能够代表所有的有效场景可能是一个好的开始。如果我们要训练一个分类器，那就需要表示所有的有效类（可能还有几个无效类）。这里我的习惯是确保所有等效分区均得到表示，要么有效要么无效。

拿一个水果分类器来说，我们必须涵盖苹果、梨、香蕉等类别。我们还需要考虑不同的水果熟度和形状。对于预训练的模型来说，独立训练集的重要性就更突出了。这里我们可以应用一个无偏见层来验证模型。做这种测试时，将任何已定义的 ODD 保留在循环中是非常重要的。ODD 将成为我们正在测试的边界，并帮助我们评判功能的正确性或识别不需要的行为。

另一个挑战是注释；如果注释都是主观的，这可能会成为一个大问题。这取决于你的模型的用途以及训练和验证数据的精确度，但准确是非常重要的，例如图像中道路的结束位置和人行道的开始位置。

假设你想使用计算机视觉模型来扫描或分类文档，那么区分瑞典字母表中的 Å 和 Ä 就会非常重要。训练模型时，我们必须在注释里写清楚 A 上方是否有一个或两个点。

我们考虑一下与自动驾驶相关的一个功能所处的交通场景。这里的图像需要注释，以便我们可以区分行人、道路、其他车辆等。

带注释的图像，其中所有对象均按颜色或对比度来分割。

从模拟器中获取的图像

来源：用于验证和认证基于机器学习的系统的数据合成

模拟器在注释方面很有帮助，无论是创建训练数据还是测试过程它都很好用。它们是一种工具驱动的辅助工具，用于生成那些我们无法生成“真实世界”数据和自动注释的场景。例如，我可能需要创造雨、雾、雪等气象来测试自动驾驶场景，模拟器可以在这些方面帮助我们。

如果需要，模拟器还可以在注释中为我们提供基本事实，以帮助加快测试速度。带注释的基本事实为我们提供了参照：图片中的哪些部分是天空，哪些是草地，图片的哪一部分是行人，等等。

大多数用于测试计算机视觉或自动驾驶的模拟器都有各种过滤器或模式。它们会自动注释你的场景，为不同组件提供基本事实或参照。使用除摄像头之外的其他传感器（例如雷达或激光雷达）来测试时，模拟器可以为你提供点云或语义信息以用作测试基础。

使用模拟器还可以帮助你更有效地寻找极端情况。例如，我们可以矢量化很多场景，然后自动搜索模型失败的场景。通过一些简单的自动化操作，我们可以为模拟器设定一个基本场景，然后对于每次测试稍微改变一下雨量或白天的光照量，以逐渐寻找各种变量条件的组合，找出导致模型做出错误预测的情况。在模拟器中，这样的流程很容易自动化；但到了真实的大街上就很难做到了。

测试机器学习的研究项目

本文提到的见解和经验来自多个研究项目。这些项目研究了如何测试机器学习程序的功能。欧盟委员会和瑞典政府为这些项目提供了资助。

与我合作的团队参加了三项主要研究，它们都与对训练好的功能的验证和认证有关系。