|专访ACL2020最佳论文二作：全新NLP模型评测方法论，思路也适用于CV

本文插图

作者 | 陈大鑫
编辑 | 丛末
现在， ACL2020各个奖项都已悉数公布，对此AI科技评论做了详细报道。其中，最受人瞩目的当属最佳论文奖，今年该奖项由微软团队的《Beyond Accuracy: Behavioral Testing of NLP Models with CheckList》一举拿下。
小编看到论文题目的第一眼就觉得哪些有些不对，于是赶紧通读了一下文章，嗯~确实不太对，这貌似和之前我们熟悉的NLP“大力出奇迹”的模型套路不太一样啊？
那么这篇论文到底讲了什么呢，又何以摘得桂冠呢？
论文解读以外，我们进一步对论文的第二作者吴彤霜进行了专访，以更深入地了解最佳论文团队背后的工作。

本文插图

1
论文方法一览
我们从论文的题目入手来了解一下这篇论文在讲什么。
首先是''Beyond Accuracy''：这是在说要超越Accuracy ，这里Accuracy说的是NLP模型在各大数据集和任务上跑出的准确率，也即是性能的一种度量。
那既然要超越它总要有一个理由:
1.评估所用的训练-验证-测试划分集来估计模型的准确性时保留的数据集往往不全面。
2.测试集中往往包含与训练数据相同的偏差，这种方式可能高估了模型在真实世界的性能
3.通过Accuracy一刀切的方式很难找出模型失败在哪里，以及如何修复它。
对此本文提出的Beyond 方式又是如何呢？
Behavioral Testing of NLP Models with CheckList！也即用CheckList对NLP模型做行为测试。

本文插图

上图是论文一作Marco Tulio Ribeiro在大会上做的展示，我们以此展开对CheckList的介绍。
1、We should test NLP models
训练NLP模型的主要目标之一是泛化，虽然Accuracy是评价泛化的主要方法，但它往往高估了NLP模型的性能，用于评估模型的替代方法要么侧重于单个任务，要么侧重于特定的行为， benchmark的准确性不足以评估NLP模型。
除此之外许多额外的评估方法已经被提出来了，例如评估对噪声或对抗性变化的鲁棒性、公平性、逻辑一致性、可解释、诊断数据集和交互式错误分析。然而，这些方法要么侧重于单个任务，如问答或自然语言推理，要么侧重于一些能力（如鲁棒性），因此没有提供关于如何评估模型的全面指导。
因此在这这篇论文中，作者提出了CheckList(检查表) ，一种新的评估方法和配套工具，用于NLP模型的综合行为测试。
2、Software engineering->NLP
软件工程研究提出了测试复杂软件系统的各种范式和工具。特别是“行为测试”（黑盒测试）是指在不了解内部结构的情况下，通过验证输入输出行为来测试系统的不同能力。虽然有明显的相似之处，但软件工程的许多见解还没有应用到NLP模型中。
作者借鉴软件工程中行为测试的原理提出了CheckList：一种和模型、任务都无关的测试方法，它使用三种不同的测试类型来测试模型的各个功能。
作者用三个任务的测试来说明检查表的效用，识别商业和SOTA模型中的关键错误。在一项用户研究中，一个负责商业情绪分析模型的团队在一个经过广泛测试的模型中发现了新的、可操作的bug 。在另一个用户研究中，使用CheckList的NLP实践者创建了两倍多的测试，发现的bug几乎是没有检查表的用户的三倍。

本文插图

图1
3、What is CheckList
CheckList包括一个通用语言能力和测试类型的矩阵，有助于全面的测试构思，以及一个快速生成大量不同测试用例的软件工具。从概念上讲，用户通过填写矩阵中的单元格来“检查”模型（图1），每个单元格可能包含多个测试。 CheckList应用了“测试与实现脱钩”的行为测试原则，即将模型视为一个黑盒，允许对不同数据上训练的不同模型进行比较，或者对不允许访问训练数据或模型结构的第三方模型进行比较。
4、What to test：capabilities
CheckList通过提供适用于大多数任务的语言能力列表，指导用户测试什么。 CheckList引入了不同的测试类型，比如在某些干扰下的预测不变性，或者一组“健全性检查”的性能。
虽然测试单个组件是软件工程中的常见实践，但现代NLP模型很少一次只构建一个组件。相反， CheckList鼓励用户考虑如何在手头的任务上表现出不同的自然语言能力，并创建测试来评估这些能力的模型。例如，词汇+POS能力取决于一个模型是否具有必要的词汇，以及它是否能够恰当地处理具有不同词性的单词对任务的影响。对于情绪，我们可能需要检查模型是否能够识别带有积极、消极或中性情绪的单词，方法是验证它在“这是一次很好的飞行”等示例上的行为。
基于此，作者建议用户至少考虑以下性能（capabilities）：

词汇+POS（任务的重要单词或单词类型）
Taxonomy（同义词、反义词等）
健壮性（对拼写错误、无关更改等）
NER（正确理解命名实体）
公平性
时态（理解事件顺序）
否定
共指（Coreference），
语义角色标记（理解诸如agent、object等角色）
逻辑（处理对称性、一致性和连词的能力）。

通过以上， CheckList实现包括多个抽象，帮助用户轻松生成大量测试用例，例如模板、词典、通用扰动、可视化和上下文感知建议。然而此功能列表并非详尽无遗，而是用户的一个起点，用户还应提供特定于其任务或域的附加功能。
5、How to test
作者提示用户使用三种不同的测试类型来评估每个功能：最小功能测试、不变性和定向期望测试（矩阵中的列）。
1）最小功能测试（MFT）:它是受软件工程中单元测试的启发的一组简单的示例（和标签）的集合，用于检查功能中的行为。 MFT类似于创建小而集中的测试数据集，尤其适用于在模型使用快捷方式处理复杂输入而不实际掌握功能的情况下进行检测。

本文插图

2）不变性测试（INV）：当对输入应用保留标签的扰动并期望模型预测保持不变时。不同的功能需要不同的扰动函数，例如，更改NER情感功能的位置名称，或者引入输入错误来测试健壮性能力。

本文插图

3）定向期望测试（DIR）：与不变性测试类似，只是标签会以某种方式发生变化。例如，我们预计，如果我们在针对某家航空公司的推文末尾添加“You are lame.”（图1C），情绪不会变得更积极。

本文插图

6、可视化效果
调用test.visual_summary

本文插图

在代码中调用suite.summary（与test.summary相同）或suite.visual_summary_table 显示测试结果如下：

本文插图

模型保存和加载：精简至极！

本文插图

7、更方便的大规模生成测试用例
用户可以从头开始创建测试用例，也可以通过扰动现有的数据集来创建测试用例。从头开始可以更容易地为原始数据集中可能未充分表示或混淆的特定现象创建少量高质量测试用例。然而，从头开始编写需要大量的创造力和努力，这通常会导致测试覆盖率低或者生成成本高、耗时长。扰动函数很难编写，但同时生成许多测试用例。为了支持这两种情况，作者提供了各种抽象，从零开始扩展测试创建，并使扰动更容易处理。
8、使用CheckList测试SOTA模型
作者通过付费API 检查了以下商业情绪分析模型：微软的文本分析、谷歌云的自然语言和亚马逊的Constract 。我们还检查了在SST-23（acc:92.7%和94.8%）和QQP数据集（acc:91.1%和91.3%）上微调的BERT base和RoBERTa base 。对于MC ，作者使用了一个经过预训练的大BERT 微调阵容，达到93.2 F1 。

本文插图

9、测试商业系统
作者联系了负责微软服务销售的通用情绪分析模型的团队（表1中的q）。由于它是一个面向公众的系统，模型的评估过程比研究系统更全面，包括公开可用的基准数据集以及内部构建的重点基准（例如否定、emojis）。此外，由于该服务已经成熟，拥有广泛的客户群，因此它经历了许多错误发现（内部或通过客户）和后续修复的周期，之后在基准测试中添加了新的示例。
作者的目标是验证检查表是否会增加价值，即使在这样的情况下，模型已经用当前的实践进行了广泛的测试。
作者邀请小组参加了一个持续约5小时的检查表会议。该团队集思广益地进行了大约30个测试，涵盖了所有功能。
从质量上讲，该小组称检查表非常有用：
（1）他们测试了他们没有考虑过的能力；
（2）他们测试了他们考虑过但不在benchmark中的能力；
（3）甚至他们有基准的能力（例如否定）也用检查表进行了更彻底和系统的测试。
他们发现了许多以前未知的错误，他们计划在下一个模型迭代中修复这些错误。最后，他们表示，他们肯定会将检查表纳入他们的开发周期，并要求访问我们的实现。
10、用户研究
作者进行了一项用户研究，以在一个更可控的环境中进一步评估检查表的不同子集，并验证即使是没有任务经验的用户也能获得洞察并发现模型中的错误。
尽管用户在使用CheckList时不得不解析更多的指令和学习新的工具，但他们同时为模型创建了更多的测试。
在实验结束时，作者要求用户评估他们在每个特定测试中观察到的失败的严重程度，研究结果令人鼓舞：有了检查表的子集，没有经验的用户能够在2小时内发现SOTA模型中的重大缺陷。此外，当被要求对检查表的不同方面进行评分时（1-5分），用户表示，测试环节有助于他们进一步了解模型，功能帮助他们更彻底地测试模型，模板也是如此。
评估特定语言能力的一种方法是创建挑战性数据集。我们的目标不是让检查表取代挑战或基准数据集，而是对它们进行补充。 CheckList保留了挑战集的许多优点，同时也减轻了它们的缺点：用模板从头开始编写示例提供了系统控制，而基于扰动的INV和DIR测试允许在未标记的自然发生的数据中测试行为。
最后用户研究表明， CheckList可以轻松有效地用于各种任务：用户在一天内创建了一个完整的测试套件进行情绪分析，两个小时内创建了的MFTs ，这两个都揭示了之前未知的严重错误。
2
专访吴彤霜：最佳论文何以花落此家
到这里我们大概明白了这篇论文到底在讲什么，但是我们还是心存疑惑，何以它能获得最佳论文殊荣？
我们在Twitter上看到了本篇论文的第二作者吴彤霜在论文获奖后的祝贺，之后我们第一时间联系到了吴彤霜同学。

本文插图

本文插图

（据吴同学称，上图的狗子为校狗，档期很满，一年才能见上一次）
吴彤霜本科就读于香港科技大学，曾在苹果和微软工作过，目前在华盛顿大学就读博士。

本文插图

https://www.linkedin.com/in/tongshuangwu/
以下为专访实录：
AI 科技评论：首先恭喜您和您的团队斩获ACL2020最佳论文！我们想先了解一下这项工作的完成大概花了多长时间，把软件测试带入NLP模型检测的想法是最近才有的吗还是说之前就有了最近才实现？
吴彤霜：这个项目最早是一作快博士毕业时我们开始合作的，中间因为各种原因搁置了一段时间，实际做大概一年吧。引用软件测试应该可以算是一个新的想法。以前有很多nlp模型分析的论文本质上也可以说是我们论文里提到的那种“行为测试” (behavioral testing) ，比如各种NLI challenge set 。只不过这些工作大部分是针对某一个任务在做某个特定种类的分析，每次都要从头开始。我们工作其中的一个主要的一个贡献就是把这些分析做归一化，提供一个测试框架+开源系统。
AI 科技评论：这项测试系统是不是可以理解为对抗扰动系统啊？或者相比有什么优势呢？
吴彤霜：不变性测试 (INVariant test) 可以相当于扰动，就是模型在预测一个句子s和经修改后的版本s'时结果类似。 CheckList还支持别的测试类别 (test type)：定向测试 (DIRectional test) 是用来测试预测结果的特定变化，最小功能测试 (Min Func Test) 不需要有配对的例子，只要一个能生成单个测试例句的模板就可以了。
只和INV（不变性测试）相比而言，现在NLP的大部分对抗句经常是在改拼写或者会产生乱码，比较难保证句子的连贯性，而能保证句子连贯性的居多是改近义词 (it's a good movie -> it's a great movie) 。 CheckList因为允许自定义改写函数 (perturbation function) ，所以可以更多样地测试模型的性能，比如看情感分析模型是否能辨认虚拟语气 (it's a bad movie -> it would have been a good movie) 。这种测试也更系统化，因为可以生成很多对改写方法类似的句子/测试用例 (test case) 。
当然相应的checklist的自动化就比较差，需要人来定义这些测试 :)
AI 科技评论：请问你们团队成员之前有过软件测试的经验吗，在CheckList的设计环节有什么亮点以及代码实现过程中有什么难点？
吴彤霜：应该不算有经验，没有在工业界实战过，顶多就是在软工课写单元测试，所以最开始其实也认真学习了一下软工 :)
设计上我觉得最大的亮点是对于性能 (capability) 的定义。我们遇到一个瓶颈就是试图给每个NLP task设计需要测试的不同方面，但这样就非常繁琐，也失去了可拓展性。直到后来我们和其他researcher聊的时候意识到其实大部分的模型需要测试的“capability”基本比较稳定，只是不同任务里对标签的影响会有区别，比如[改主语]对NLI影响会比对情感分析要大。这样一个稳定的capability集合就让整个框架干净了很多。
开源上，其实NLP部分还是比较整洁的，但是为了让大家能比较流畅地在notebook里浏览和回顾test集，我们下了很大功夫研究怎们做交互插件，是一个大坑，但是最终效果还挺好看的，可以到readme里看看preview感受一下，哈哈。
写作上，因为marco在微软，我们很幸运能近水楼台找微软情感分析的工程组来做用户研究，让我们真的看到了CheckList在已经被认为是大规模测试过的模型仍然很有用。
AI 科技评论：很开心你们把这项工作开源，我想这项工作只是一个开始对吗？（大家都可以在你们开源的代码上进行哪些尝试和改进呢，比如自定义测试模板之类）
吴彤霜：最重要的是希望能看到大家提出的测试实例！其实比起很多NLP模型， CheckList是一个比较依靠人的力量的项目，测试者仔细设计实例才能用它最大程度暴露模型可能存在的缺陷。我们考虑的一个想法是希望可以做一个类似模型排行榜的测试榜，大家可以上传分享自己的测试集，甚至是顶或者踩别人的测试，最终让每个任务都能有一个比较稳定的测试集，也方便模型间的比较。
其次，我们也很期待看到大家会不会有关于如何让CheckList更自动化的想法，实现一键测试这个终极目标 :)
以及更研究向的：
我个人对于设计更稳定的测试也很感兴趣。 CheckList对具体实例比较敏感，不同人在测试同一个模型性能时，如果实例设计不同，最终测试结果可能会有一些偏差。有没有什么交互手段能帮助测试者尽量穷尽一个性能所有的相关改写？甚至还有没有什么办法能慢慢形成一些自动的测试拓展？这个可能也和上面提到的自动化有一些关系。
最后测试带来的一个恒久不变的问题：so what？一个模型有问题之后，应该用什么样的标准来决定一个模型是不是可以被公开部署 (比如可能公平性测试的容错率可能远低于拼写错误)？应该如何改进它？
AI 科技评论：请问软件测试的思想只适用于NLP领域吗，在CV领域可行吗，应该怎么去设计测试系统？
吴彤霜：我相信是可行的！抽象来讲，本文图1的这种框架似乎能直接套用在CV上。
比如说一个最简单的狗和狼的分类，这个模型首先得能辨认有动物出现 (MFT) ，然后改变图片的背景应该不影响预测 (INV) ，但改变动物的头的形状应该是要影响的 (DIR) 。 vision里的“改写”效果其实比NLP好很多，也许更好用也说不定 :)
对设计系统而言，我觉得比较重要的是抽取基本组件。在NLP版本的CheckList里有一个重要组件就是写生成template/模板；也许在vision里则是需要提供一些基础像素之类的。
当然也可以考虑除了行为和单元测试之外的测试思想，比如如果是pipeline模型，考虑如何设计集成测试也许也会很有用 :)
AI 科技评论：可以简单介绍一下你们的团队成员吗，以及你们的近期工作、未来研究方向？
吴彤霜：隆重介绍一下没有出镜的一作吧， marco也是华大的博士， 2018年毕业以后就加入了微软研究院，主要在做模型可解释性和分析，之前很有名的LIME（一种解释机器学习模型的方法——Local Interpretable Model-Agnostic Explanations）就是出自他手。除了CheckList ，他今年在CVPR上也有一篇合作论文，是分析vqa model的稳定性的。现在主要在做vision模型的错误分析以及模型比较。
我们现在也在合作一个新工作，这项工作更多是关于如何人去探索模型的可解释性。虽然现在主要做的都是人如何检查模型，但是我们对于模型如何能反过来规范人或者帮助人也很感兴趣 :) 三四作Carlos和Sameer都是marco的导师，分别是ML和NLP的大佬。
3
总结
虽然CheckList目前也有一些不足比如CheckList不能直接用于非行为问题，例如数据版本控制问题、标记错误、注释器偏差、最坏情况下的安全问题或缺乏可解释性。
但是不可否认的是，使用CheckList创建的测试可以应用于任何模型，这使得它很容易被纳入当前的基准测试或评估pipeline中。用户研究表明， CheckList很容易学习和使用，对已经对模型进行了长时间测试的专家用户以及在任务中缺乏经验的实践者都很有帮助。
另外对吴同学的专访，我们相信，本篇论文工作确实开创地把软件测试系统引入NLP模型的测试之中并且提供了完善的测试工具。这将会给社区和企业带来很大的商业价值，比如CheckList测试工具将会节省很大的人力成本。
最后，我们相信，这种系统引进软件测试的思想也将会在CV乃至整个AI领域大有作为。
对代码有兴趣的同学可以尽情pull和issue：https://github.com/marcotcr/checklist
若还有进一步的学术交流和项目合作可联系吴同学的邮箱：wtshuang@cs.washington.edu
感谢吴同学的用心回答，祝吴同学一路优秀下去，心想事成~天天开心！