人工智能测试：关于无人车测试的案例研究

雷锋网(公众号：雷锋网)新智驾按：近日，清华大学自动化系系统工程研究所副教授李力作为第一作者以及林懿伦，郑南宁，王飞跃，刘跃虎，曹东璞，王坤峰，黄武陵发表了一篇关于人工智能测试和无人车测试的英文论文《Artificial intelligence test: a case study of intelligent vehicles》，集中探讨了人工智能应用领域中关于智能性的测试和设计方法。文章认为，智能性测试和机器学习的过程类似，两者如同一个硬币的两面，“终生测试”将是一场持久战。文章最后还提出了虚实结合的平行测试方法。

以下是人工智能测试与无人车测试的中文版介绍，经李力副教授授权发布。另，文末附上英文版论文的下载链接，欢迎查阅。

1. 概述

本篇文章主要是讲述在人工智能应用领域对智能性的测试，基于场景和任务的测试体系的描述，以及介绍了如何设计智能性测试中基于仿真的测试及其测试指标，并在智能车这一典型人工智能领域举例说明。

2. 无人驾驶和人工智能

人工智能（AI）通常是指机器表现出来的和人类类似的智能。现如今，人工智能已经极大的改变了我们的生活，大到自动驾驶汽车，小到扫地机器人，都是人工智能的应用领域。我们坚信，人工智能将会在未来的20年内进一步的改变我们生活包括健康，教育，娱乐，安全等各个领域。在享受人工智能的带来的各种便利的同时，也带来一些疑问：如何保证人工智能机器按照人类设计的思路来正确运行？无人驾驶车辆是否会在某些极端环境中失控照成事故？厨房机器人是否会把房子点燃？基于以上，我们迫切的需要对人工智能的可靠性进行规范的测试和衡量。

为了回答以上问题，我们需要思索一下人工智能的定义：维基百科对于人工智能的定义：机器所展现出来的智能；我们对其进行扩展，给出的定义：人工智能是指机器（在同样的任务中）表现出（和人类似的、或一样的、甚至是超过人类的）智能，明斯基（Minsky 1968）对人工智能给出过类似的定义“ [AI] is the science of making machines capable of performing tasks that would require intelligence if done by [humans]”. 明斯基的定义更加注重对完成任务的所需要的智能（原因导向），而本文的定义则更加倾向于所完成的任务所表现的智能（结果导向）。

同时必须注意到的是，为测试智能性所选择的任务也是有特定针对性的，不同的任务测试不同方面的智能性，例如，一个文盲可能能成为一个很好的司机，但是一个眼盲的饱学之士却无法开车。

图灵测试是迄今为止我们所知的最早的针对智能性的测试。图灵测试是图灵对于人工智能的睿智思考，其核心思想是：要求计算机在没有直接物理接触的情况下，尽可能把自己伪装成人类回答人类的询问。但是，图灵测试在无人车智能性测试方面也无法全盘套用。

当今，智能性测试有越来越多的应用领域，那么我们到底应该用何种方法来测试智能性呢？我们所提出的基于任务的智能性测试方法又有哪些优越性呢？接下来，我们将会列举智能性测试的难点，以及我们提出测试方法如何解决这些难点，以及如何更好的设计基于“任务”的测试用例。

3. 无人驾驶智能的设计和测试

3.1. 智能性测试的困境

3.1.1. 任务的定义/描述

第一个困境是如何来更好的定义智能性测试中的任务：

图灵测试中最大的短板就是任务的描述。需要指出的是，当今的无人驾驶车辆智能测试和中文屋等早期图灵测试已经有了很大差别：其一，早期图灵测试并未明确的规定测试任务以及何种答案可以视为正确，这导致一些试图通过图灵测试的机器经常采用摸棱两可的方式来试图避免直接回答。而当今的无人驾驶车辆智能测试都对任务进行了明确的界定；其二，早期图灵测试有人来判定测试结果，而为了检验无人驾驶车辆的识别算法是否通过各种可能场景的测试，我们必须使用机器来帮助判定数以万记的测试任务是否通过。

总之，我们需要建立一系列的可以量化的测试任务，这是智能性测试最根本的基础。

3.1.2. 任务的验证

第二个困境是：如何保证被测智能机器在所遇到的所有场景中表现出其行为的一致性。因此需要保证任务测试的枚举性/覆盖性。

通俗的讲，我们可以把任务看作是对智能机器测试的输入，如果完成该任务，输出“是”，反之输出“否”。对于一些相对简单的智能性测试，通过枚举所有可能的任务组合，我们可以穷尽可能的交通场景。如果车辆能通过所有这些场景，则车辆将足够智能。但由于任务空间的时空连续性，枚举是不可能完成的。因此，必须依赖虚拟采样测试来加大如何合理采样，在降低场景生成复杂度的同时，提升测试覆盖性成为测试的关键技术。通过记录受试车辆和其他车辆的轨迹，我们可以定量刻画车辆的智能水平(驾驶性能)。

3.1.3. 仿真测试的设计

为了在有限的时间和财力内尽量解决任务覆盖问题，现在的研究者多采取仿真测试来弥补实地测试的不足[4]。由此出发，研究者进一步研究了如下诸多衍生问题：

1）如何保证虚拟测试中虚拟物行为的真实性；

2）如何保证虚拟测试中虚拟物表现的丰富性；

3）如何保证虚拟测试中场景和任务的覆盖性；

4）如何实现虚拟测试中机器判定的正确性。

例如在仿真测试方面，目前的无人驾驶车辆研究者考虑了如何从现实采集的2D图像数据中提取物体的3D属性，并在3D引擎中重新渲染并产生新的2D虚拟测试数据。而另外一些研究者则考虑了如何基于生成式对抗网络来直接从2D实测图像数据来生成新的2D虚拟测试数据。

再者，测试标准的设定也是研究者探讨的热点之一。对于驾驶这类典型的多目标问题，如何评价不同算法的优劣并设计适应不同用户要求的测试标准尚有很大的难度。

3.1.4. 测试指标的设定

测试指标的设定的方法有几种，第一种是要求智能机器做出类似人的行为表现。这种方法里首先需要确定人在完成该任务时会如何表现，然后再根据智能机器在完成该任务的过程中的表现和人的表现的区别来做判定。

第二种测试指标设定方式是要求智能机器有最好的表现。比如，在设计针对围棋的人工智能机器时，我们要求其能够一直胜利，而不是像一个人类选手的方式去下棋。对于这一类目标相对简单的情况下，这种方式更加合适。在智能车测试中，目标往往比较复杂，不能像围棋一样以赢得棋局为目标，需要考虑行驶安全性，速度，燃油效率等其他复杂的因素。以不同的因素为目标会导致完全不同的设计。例如在2016，2017年的中国无人车未来挑战赛中，智能车通过设定的10个特定场景任务的时间被作为评价指标之一，如果发生了碰撞，压线，闯红灯，也会扣去相应的分数。当人的感受被纳入考察因素的时候，考虑到每个人对于同一件事物的感受都会有一定的区别，测试指标的设定会变的更加艰难。

3.2. 智能车的智能性测试

我们这里以智能车的智能性测试为例，来说明我们的观点：

3.3.1. 智能性测试中测试任务的设定

传统的无人驾驶车辆智能测试主要分为两大流派：场景测试流派和功能测试流派。

1) 场景测试

往往是指处在特定时空中的测试系统。例如，交通场景一般指的是由众多交通参与者和特定道路环境共同构成的交通系统。如果受试车辆能够自主行驶通过该交通系统，则称为通过该特定场景的驾驶测试。例如DARPA 2005 年无人车挑战赛便选取了212 公里的沙漠道路作为测试场景(其实2004年也是选择了沙漠作为测试场景，但是“全军覆没”，相比之下，2005年则是一段光辉岁月)(Grand Challenge 2005)。DARPA 2007 年无人车挑战赛则选取了96 公里的城市道路作为测试场景(Urban Challenge 2007)。

2) 功能测试

功能测试更加侧重无人驾驶的单项或多项功能实现。依据人类智能的功能归类方式，可将驾驶智能划分成信息感知、分析决策、动作执行等较为概括的三大类能力。例如路径规划就属于分析决策类的单项智能。该定义方式强调的是实现这些单项智能的方法和技术上的共性。但由于不能与具体的交通场景以及无人驾驶测试任务联系起来，在衡量无人驾驶的智能水平方面有所不足。功能测试的隐含假设是，如果无人驾驶通过某种功能的一次或几次测试，那么，以后需要使用该功能时也可以顺利执行。这一假设看似合乎逻辑，但事实证明，也过于乐观。此外，目前的功能测试还存在其它问题：

• 单一功能测试较多，综合测试涉及较少，无法检验多项功能之间的协同配合能力

• 缺少完备、公平、公开的Benchmark集。

我们认为，无人驾驶车辆的智能可以用广义的语义网络来定义。

语义网络是一种采用网络形式表示人类知识的方法，如今已在人工智能领域中得到了比较广泛的应用。语义网络用有向图来表达复杂的概念及其之间的相互关系。图中的顶点表示概念，而边则表示这些概念间的语义关系。

针对无人驾驶智能的广义语义网络分为场景、任务、单项能力和综合能力四类节点。其中任务将场景和能力打通并连接起来，应该是无人驾驶智能研究的核心，参见下图。

*图1. 无人驾驶智能定义的语义关系图释

场景一词源于戏剧，是指在一定的时间、空间(主要是空间)内发生的一定的任务行动或因人物关系所构成的具体人事片段。在系统学研究中，场景多被定义为处于特定时空中的特定系统。交通场景一般指的是由众多交通参与者和特定道路环境共同构成的特定交通系统。

任务原指交派的工作。驾驶任务既可以指跟驰、换道、停车等某类一般性的驾驶工作，亦可指特定环境中的某项特定驾驶工作。如果受试车辆能够自主行驶完成某项特定任务，则称为通过该特定任务的驾驶测试。相对于驾驶场景而言，驾驶任务更为具体，时空范围更为明确。一个特定的驾驶场景通常包含多个驾驶任务。近两年，中国智能车未来挑战赛注意到了任务测试的重要性，精心设计了任务库，测试无人驾驶车辆的特定能力。

不过，这里还存在一个问题：通过测试任务，仍然不能说明被测系统具备了无人驾驶智能和驾驶能力。驾驶能力一般指的是完成某种特定驾驶行为的能力。完成一个特定的驾驶任务通常需要受试车辆具有多种驾驶能力。不同于场景和任务，每项驾驶能力可以被量化评估。进一步将各个能力进行汇总，即可定量评估整个无人驾驶车辆的驾驶能力。

在图1所示的语义网络中，沿着场景、任务直到能力之间的正向连接，我们可以从驾驶场景中梳理出具体驾驶能力，将能够量化的驾驶能力指标进行细分和标准化，以便建立完备的测试体系。

而沿着从能力、任务直到场景之间的反向连接，我们可以根据功能测试需求，自动产生合理的驾驶任务乃至驾驶场景，解决测试配套的驾驶环境自动设计问题。待驾驶场景确定之后，便可以自动化虚拟生成配套驾驶环境，用于无人驾驶智能的仿真测试和实路测试。

3.3.2. 智能性测试中测试场景的生成

基于图1，场景测试位于该语义网络的左端，而功能测试位于该语义网络的右端。我们提出的无人驾驶智能体系，实际上是将已有的两种无人驾驶智能定义方式融为一体，相辅相成。基于上述定义，我们可以进一步生成特定的测试场景。

生成测试场景，第一个要考虑的因素是，如何确定场景中所含有的任务，并确定这一系列任务的出现和需要完成的时间—空间位置。下图2描述了一个非常简单场景中，受试车辆A的若干不同任务在任务时空图中是如何排布的。受试车辆需要在每个任务需要完成的截止时间和截止空间前完成该任务。同时下图3描述了从抽象的测试场景到具体测试实例的转换过程。

每个场景中的任务数目和时空排列决定了该测试场景的难易程度。任务数据越多越难，需要同时处理的任务数量越多越难。

*图2. a) 一种典型的城市驾驶场景; b) 分配任务的时空排列; c) 随时间变化的相应计算开销

 

*图3. 一个驾驶任务逐级细化的过程也就是对于任务空间的抽样过程，包括逐级确定分配任务的时空排列和创建实例

3.3.3. 智能车智能性测试框架

在传统汽车测试开发中我们经常使用V字型开发方法。如下图所示，在这种方法中，人们在开发阶段就定义了相应级别的测试用例。

 

*图4. 传统汽车测试V字形开发流程

V模型的第一阶段是整体需求确认阶段，在该阶段与整体需求对应的测试用例也会提前定义。第二阶段，第三阶段分别是系统级别（High-Level-Design）以及子系统级别（Low-Level-Design）的设计和对应测试用力的书写。在这两个阶段系统的功能会被分解细化，软件中的各种类，以及类间关系会被定义。同时，也需要在这两个阶段书写同样级别的测试用例。第四阶段是模块设计，在这个阶段，子系统会进一步分解成为小的模块，对应的对于模块的测试用例也会在这个阶段定义完成。

如果把我们提出的测试方法和V模型一一对应，就能得到如下的Λ-V模型：不断学习新示例，举一反三，逐步完善任务描述。

*图5. Λ-V模型测试框架

V模型对于传统汽车研发这一类系统性和可推导性比较强的系统工程有较好的效果，但是由于我们需要在具体的编程之前就设计好所有的测试用例，这使得该模型在较为复杂的人工智能系统开发中很难直接套用。

我们认为，在开发智能系统过程中，机器学习和测试如同一个硬币的两面，智能性测试应该和机器学习有着类似的流程。

（a）

（b）

*图6. 智能车测试框架

在平行学习的框架下，首先要解决的问题是如何获取新的数据用来学习，该阶段我们称为描述性学习阶段；在第二阶段，会从第一阶段中提取特定的数据有针对性的进行学习，从而获得“小知识”，该阶段我们称为特定数据学习阶段；第三阶段是预测性学习阶段，在该阶段，会把前两阶段得来的数据和知识一一对应，这种联系也会被记录下来。最后，所有的新数据会在第三阶段已有联系的基础上找到对应的“小知识”。

与此类似的，如图6（b）所示，智能车的智能性测试也有着类似的流程。第一阶段是创建新的测试任务。在这个过程中，在场景中的测试任务都会被逐步分解成为细化的功能。第二阶段是在第一阶段创建的测试任务中选取有挑战性的部分（测试取样）。最后一个阶段是测试的执行，也就是在前两个阶段创建的任务中观察智能车的表现。在这个阶段，我们需要从测试结果中得到两类关联信息，第一类是车辆智能性和其在我们搭建的测试环境中的表现的关联，这种关联对于我们在新的测试任务中取样有很大的帮助；第二种关联是测试本身和测试环境的关联，我们需要从不同的测试环境中学习到如何更好的创建测试任务。

我们提出了以上的智能性测试框架是基于以下考虑：

1) 如果不进行测试，我们无法预知智能车的行为表现。所以，在没有测试之前，我们也无法确认哪些测试任务更加的具有挑战性。所以我们需要通过不断的测试，取样，执行，分析这样一个循环来达到最优的测试效果。

2) 测试本身就是一个自我标定的自循环过程，我们必须根据测试结果来判定车辆的智能性。

3) 如果测试要覆盖所有的智能车的功能所需要的资源是巨大无比的，所以，我们需要一些更优的方法和工具来缩短这个过程。

3.3. 平行测试

3.3.1. 传统虚拟仿真

目前很多研究人员都把更多的精力放在视觉领域的虚拟仿真，当然，也有人开始注意到驾驶员行为的重要性。在视觉领域的仿真中，有以下几种图像注入方式：1.采集真实的2D数据，然后基于该数据建立3D模型，再在此3D模型的基础上上投影成2D的图像注入智能车的感知系统；2.使用对抗式网络生成新的2D模型注入； 3.基于以上两种方法尽可能多的图像注入。

3.3.2. 平行测试方法

我们这里提出一种新型的虚实结合的智能车平行测试方法。如图7所示，车辆智能性测试可以分为三步：测试环境，测试规划和测试执行。同样，我们在虚拟世界里也能够建立一一映射的测试流程。

  

*图7. 平行测试方法

1) 首先在真实环境下建立有多种交通元素（十字路口，交通灯）的场景，对应的在虚拟空间内，根据不同的测试目标，可以把该场景细分成不同的任务，功能团，单个功能；

2) 基于这种分解模式，可以建立相应的测试计划来有针对性的测试不同的功能。例如假设我们要测试交通标示识别和变道这两个功能团，很容易发现，交通标示识别重要性没有那么高，而测试变道能更好的提升车辆的可靠性。在测算了场景中包含的任务，以及任务中包含的功能团之后，我们能选出包含更多的变道的任务来在真实环境中进行测试，而包含更多交通标志识别的任务可以在仿真环境中进行测试；

3) 一旦制订了在真实和虚拟环境中的测试计划，按照计划执行之后对测试结果可信度以及功能重要性进行加权就能得到相应的加权分数。同时，在真实环境中得到的测试数据又能注入仿真环境，通过这种方式，仿真环境能够不断更新加强。真实环境和虚拟环境中的测试是异步的，我们可以在真实环境进行某一项测试的同时，在虚拟环境中进行多项测试。

和传动的仿真测试环境相比，平行测试体系有如下两个不同。

1. 平行的虚拟环境不仅仅是真实环境的一一映射，同时也和真实环境在状态上存在交互，真实环境会影响虚拟环境，虚拟环境也会影响真实环境，这样就形成了一个自我不断增强系统；

2.平行系统是一种自我学习的系统，一些在虚拟环境中的关键元素是数据驱动型，这使得平行系统比那些基于随机模型的系统要更加自动化，可信度也更高。

3.3.3. 平行测试实际应用

在江苏省常熟市，这样一个平行测试系统已经建立起来，并且很好的支持了2017年中国智能车未来挑战赛。如图8所示，我们先在虚拟环境中找到最具挑战性的测试任务然后再在真实环境中进行测试。 

*图8. 平行测试实际应用

4. 智能性测试的相关讨论

4.1. 伦理道德问题

包括图灵在内的大部分研究者都认为人能够按照自己的经验做出正确的决定，而智能机器也应该和人类一样来完成这些决定，因此我们的工作就简化成为在智能测试中去判断智能机器是否完成了和人类一样的决定。

但是在某些情况下，哪怕是人类也很难确定什么是正确的，例如著名的铁轨问题：你是一辆刹车失灵的火车司机，在你前面的铁轨上有5个人被绑在轨道上，你可以选择切换到另外轨道，另外那条轨道上只有1个人绑在铁轨上，那么请问你会选择撞死5个人还是切换轨道撞死1个人？对于这个问题本文中不做更多的讨论，即使是人类，在这个问题上都很难做出“正确的”决定，更何况智能机器？所以在本文中我们不去讨论这些问题，我们也不会为伦理问题设置智能性测试。

4.2. 测试结果的自动实时分析

图灵测试和现在很多新的智能测试的区别在于，图灵测试用人来做判定，而新的智能测试使用的是机器来做判定。之所以这么做的原因在于我们清晰的定义了任务，同时很多情况下没有机器的帮助人很难完成正确的判定。

以智能车测试为例，为了节约成本，我们往往在某一条测试路线上设置了多个测试任务，车辆需要不停歇的完成多个测试任务。例如在中国智能车未来挑战赛中就设置了14个测试任务，分别是U-Turn，通过T字型路口，通过十字路口，避让作业车，隧道，停止标志，避让行人，右转，乡村道路，避让自行车，施工区域，限速，停车。车辆需要连续通过这些任务点，为了能够自动测评，我们需要使用V2X设备连接车辆上的传感器和数据中心，上传车辆数据到数据中心来完成自动测评。

*图9. 智能车比赛测试项

青岛慧拓智能机器有限公司联合清华大学一起开发了自动测评系统并成功应用于此次比赛中。如图10所示，左边展示的是正在比赛中的5辆车的实时轨迹和实时排名，右边屏幕里是实时的视频回传数据，展示着裁判车数据，比赛车辆数据，以及场边摄像头数据。这些数据通过V2X或者4G的方式传回数据中心。

在2009年-2015年的比赛中，比赛由裁判来人工打分，这种方式比较主观，也非常耗时。在2017年比赛中，大部分的任务可以通过回传过来的数据实现自动打分。我们同样能够通过深度学习的方式用视觉的方式来检查车辆是否有压线，来实现自动打分，如图11所示。

 

*图10. 智能车比赛实时评测

 

*图11. 实时压线检测

4.3. 驾驶员在环测试

按照上文中说到，我们最终的目的是让机器代替人来评价智能性测试结果。但是目前阶段，这种情况却难以完全实现。

首先，测试任务的描述需要由人类专家来完成。所有的任务描述都是使用人类语言，目前也并没有一种计算机语言能够更好的完成该任务。机器的智能水平往往受限于它的设计者，所以我们最终总是还是需要用人类的智慧来在衡量测试结果的基础上提升机器的智能性水平。

其次，人类专家能够按照自己的经验更好的帮助机器设计那些极限的测试任务。

最后，人类是智能性测试的最后决策者，往往由机器做出的判断还要由人类来检查。就像在2017年中国智能车未来挑战赛中视频回传系统就是方便人类专家随时能够监督智能车的表现，这能够让人类和自动打分系统同时以对方的判断为基础改善自己的评判能力。

4.4. 用测试来进行智能水平分级

SAE把汽车自动化水平分为从无自动化到完全自动化六个级别，但是在该分级体系中并没有给出明确的需要完成的任务。现在有更多人认为，只有明确了分级系统中的测试任务，才能更好的对汽车智能性水平进行分级。

智能机器在特定的领域越来越智能，甚至在某些领域（比如围棋领域的阿法狗，射击领域的Top Gun）已经超过了人类。也许在未来的某一天，机器能够取代人成为智能性水平的最终定义者。

4.5. 可释性测试

如同图灵测试一样，我们现在更多的关注智能机器的外在表现多于机器内部的运行机制。如果某智能机器通过了所有的测试任务，我们就承认了其在该领域的智能性。但是我们很难知道怎样的外在表现是最优的。

当今的智能机器越来越复杂，我们很难完全搞懂其内部的算法（例如复杂的深度学习算法），这就类似于一个“黑盒子”。并且我们基于传统可释性逻辑制造出来的机器很难和这种“黑盒子”媲美，距今为止，很少有人能找出一种“内外兼修”的测试方法，这将是未来一个很重要的研究方向。

4.6. 智能性测试在智能机器软件开发中的必要性

鉴于目前大部分AI的程序都是在电脑中通过编程完成，所以测试实现AI的软件显得尤为重要，所以我们需要建立一套完善的对这些软件的测试体系。例如测试驱动型开发（TDD）就在当今工业界被广为接受：TDD最基础的思路是首先把需求分解转换成相应的测试用例，然后不停的优化软件让其通过这些测试。在这种研发思路中，我们能很好的保证软件的质量并能让软件有更好的可读性。

目前在该领域最缺乏的是良好的测试和调试工具，这种对于AI软件的测试工具市面上非常少。

4.7. 终生测试

就像前文所述的，现在有越来越多的方法来测试智能性，但是这些测试方法的落地还需要很长一段时间。我们把这一落地过程称之为“终生测试”（Life-long Testing）。我们应该把AI机器的研发和测试当作一个整体来考虑，随着测试的不断深入，机器的智能性也会因此而提升。

在当今工业界，我们更多的是把多种“低级别”的简单机器进行组合来制造“高级别”机器。很难想象，我们400年前只能制造一些很小的玩具，而如今我们却有着十分复杂的GPU，CPU等。同样的，我们相信在AI领域，也会是如此，会有更多的“高智能性”机器从“低智能性”机器中衍生而来，我们可以一起见证这一时刻的到来。

4.8. 测试的商业化

目前的AI革命正在极大的改变我们的生活，有很多人类的工作正在或者在不就的将来就会被机器代替。同时，新的AI领域也催生了一大批新的工作，智能性测试当然也在其中之列，例如我们现在需要非常多的人来标定视频数据来训练我们的深度学习模型。

5. 结论

本文主要讨论了智能性测试的难点，并以此为基础提出了智能性测试方法：智能性测试和机器学习的过程类似，两者如同一个硬币的两面。并且我们提出了虚实结合的平行测试方法：首先在虚拟环境中描述测试任务，然后进行取样，最后执行测试，通过这个流程我们能够找到其中最难的测试任务；另外，虚拟测试需要平行的去执行，这样可以帮助我们更好的找到更“真实”更“丰富”的测试数据集，这将极大的改善测试的效率和经济性。

但是，“终生测试”将是一场持久战，目前我们还没有能够找到一个脱离人能够自己运行的虚实结合的平行测试系统，我们相信，这一天迟早会到来。

附：

《Artificial intelligence test: a case study of intelligent vehicles》

下载地址：

https://link.springer.com/article/10.1007/s10462-018-9631-5

。