本文主要介绍以及翻译一篇 ACL2020 Best Paper Beyond Accuracy:Behavioral Testing of NLP Models with Checklist
Abstract
尽管传统评估模型好坏的方法是在测试集上观察 accuracy 指标，然而这个指标常常高估了 NLP 模型的真实表现，而另外一些评估模型的方法要么关注单个任务，要么关注一些特殊的行为。受软件测试的启发，我们提出了一种测试不确定任务的 NLP 模型的方法——CHECKLIST。CHECKLIST 包含一个通用语言能力和测试类型的矩阵，以及一个可以快速生成大量不同测试样例的软件工具。我们在三个任务上测试了 CHECKLIST 的能力，识别商业模型和最新模型中的一些关键故障。在一项用户案例中，一个负责商业情感分析模型的团队在一次测试中发现了新的、可执行的 bug。在另一个用户案例中，使用 CHECKLIST 的用户创建了两倍多的测试集，并且发现的 bug 是不使用 CHECKLIST 用户的几乎三倍
1 Introduction
训练 NLP 模型的目标之一是为了泛化。由于使用其它测试集进行测试非常昂贵且无法快速收敛，因此常规测试模型效果的方法是划分训练 - 验证集来估计模型的准确度。虽然在验证集上的表现是一个有用的指标，但是验证集往往不够全面，而且还包含有和训练集相同的 "偏见"（译者注："bias" 在这里可以理解为 "领域"），因此实际表现可能被高估。此外，由于将性能表现总结为单一的统计量，所以很难找出模型的问题，更不用提如何修复它
目前也有许多其它测试模型的方法，例如评估对噪声的鲁棒性、adversarial changes（暂时不知道如何翻译）、fairness、逻辑一致性、可解释性、诊断数据集以及相互之间的误差分析（译者注：这里的许多方法，建议直接谷歌搜英文查看具体内容）。然而，这些方法要么关注单个任务，例如问答或自然语言推理；要么关注与一些能力（例如鲁棒性），因此没有提供关于如何全面评估模型的方法。另一方面，软件工程的研究为测试复杂软件系统提出了各种范例和工具。特别地，"行为测试"（也称黑盒测试）是通过验证输入 - 输出行为来测试系统的不同功能，而不需要了解系统的内部结构。虽然有明显的相似之处，但是软件工程的许多见解还没有应用到 NLP 模型中
我们推出了一种新的方法，以及工具——CHECKLIST，该方法用于对 NLP 模型进行全面的行为测试。CHECKLIST 通过提供适用于大多数任务的语言能力列表，指导用户测试哪些内容。为了将潜在的问题分解为特定的行为，CHECKLIST 引入了不同的测试类型，例如，测试存在某些干扰时的预测不变性，或者测试一组 "sanity checks" 上的性能。最后，我们对 CHECKLIST 的实现包括多种 abstractions，这些 abstractions 可以帮助用户轻松生成大量的测试用例，比如模板、词典、通用的噪声、可视化和上下文感知的建议
我们使用 CHECKLIST 对商业情感分析模型进行了测试，结果如图 1 所示。测试的结果是一个矩阵，功能为行，测试类型为列。作为对模型否定能力的测试，我们使用最小功能测试 (MFT)，即设计为针对特定行为的简单测试用例（图 1A）。我们在模板中生成了大量的简单样例（“I {NEGATION} {POS_VERB} the {THING}.”），利用预先构建的词典，计算模型对此类样例的错误率。命名实体识别（NER）是另一种功能，在图 1B 中用不变性测试（INV）——这是一种不改变模型输出的扰动测试，在这个例子（INV）中，改变地点名称不应该改变情感值。在图 1C 中，我们用定向期望测试（DIR）来测试模型的词汇表——对已知预期结果的输入进行干扰的测试——添加消极的短语并检查情绪是否会变得更积极。正如这些例子所表明的，该矩阵可以作为一个指导，促使用户使用不同的测试类型来测试每个功能
我们展示了使用 CHECKLIST 在三个 NLP 任务上的实用性以及通用性，这三个任务分别是：情感分析、重复问题检测以及机器理解。尽管各种任务的传统基线准确率和人类差不多，但是 CHECKLIST 却揭露了各种各样的 bug，即商业和研究模型不能有效地处理基本的语言现象，如否定、命名实体、指代、语义角色标记等，因为它们与每个任务相关。CHECKLIST 非常容易上手并且提供的价值很高——在一个用户的案例中，负责商业情感分析模型的团队发现了许多新的、可执行的 bug，尽管这个模型经过许多测试并且已被用户所使用。在一个另外的用户案例中，CHECKLIST 的使用者生成了超过两倍的测试集（每个测试包含一个数量级以上的例子），并且相比于那些不使用 CHECKLIST 的用户，他们发现了几乎三倍的 bug
2 CHECKLIST
从概念上讲，用户通过在矩阵中填写单元格来 "检查" 模型，每个单元格潜藏多个测试集。本节我们更多的了解行（功能）和列（测试类型）的细节，以及如何填写单元格。CHECKLIST 通过将模型视为黑盒的方式，来应用将测试与实现解耦的行为测试原则，这种黑盒测试的方式允许比较在不同数据上训练的不同模型，或者在不授予访问训练数据或模型结构权限的第三方模型之间进行比较
2.1 Capabilities
虽然测试单个组件在软件工程中很常见，但是现在流行的 NLP 模型很少一次构建一个组件。相反，CHECKLIST 鼓励用户考虑不同的自然语言能力是如何体现在手头的任务上的，并创建测试来评估各种能力的模型。例如，词汇 POS 能力涉及到模型是否熟练掌握任务相关的词汇，是否能恰当处理不同词性的词语对任务的影响。对于情感分析任务来说，我们想检查模型是否有能力区分每个词表示的积极，消极或中性情感，例如，验证 "This was a good flight" 这句话的情感。对于重复问题检测任务，我们可能想让模型理解修饰词何时区分问题，例如（John 是一个老师吗？，John 是一个合格的老师吗？）。对于机器理解任务，模型需要能够将比较级和最高级联系起来，例如（语境：Mary 比 John 聪明。问：谁是最聪明的孩子？答：Mary）
我们建议用户至少考虑以下功能：词汇 POS 任务（重要单词或单词类型）、分类（同义词、反义词等）、鲁棒性（拼写错误，无关紧要的变化等）、命名实体识别（适当地理解命名实体）、Fairness、时间（了解事件的顺序）、否定、指代、语义角色标注（理解角色，如代理，对象等)，逻辑（能够处理对称、一致性和连词）。我们将会在第三节提供一些例子，说明这些功能是如何测试的。此功能列表并不详尽，但对于用户来说是一个起点，用户还应该提供特定于其任务或领域的附加功能
2.2 Test Types
我们提示用户使用三种不同的测试类型 (如果可能的话) 来评估每种能力，这三种测试类型分别是：最小功能测试、不变性测试和定向期望测试（矩阵中的每列）
最小功能测试，受到软件工程中的单元测试的启发，是一个简单示例（和标签）的集合，用于检查功能中的行为。MFTs 类似于创建小的、集中的测试数据集，对于检测模型在没有真正掌握功能的情况下使用 shorcut 方法处理复杂输入时特别有用。在之前几节中，词汇 POS 的例子都属于 MFTs
我们还介绍了蜕变测试启发的另外两种测试类型。不变性检验是当我们对输入标签进行扰动时，期望模型预测保持不变。不同的功能需要不同的干扰功能，例如为情感分析的 NER 功能更改地点名称（图 1B），或引入拼写来测试鲁棒性。定向期望测试与此类似，只是样本需要以某种方式改变。例如，在一句话的结尾加入 "你是瘸子"（图 1C），我们期望这句话的情感不会变得更积极。期望也可能是目标标签，例如，在 QQP 中只替换其中一个问题的地点，如（"在英国有多少人？"，"土耳其的人口是多少？"），以确保问题不是重复的。INVs 和 DIRs 允许我们在未标记数据上测试模型——它们测试的行为不依赖于真实标签，而是应用扰动后预测之间的关系（不变性、单调性等）
2.3 Generating Test Cases at Scale
用户可以从零开始创建测试用例，或者通过打乱现有的数据集。从零开始可以更容易地为在原始数据集中没有被充分表示或混淆的特定现象创建少量高质量的测试用例。然而，从零开始编写，需要大量的创造力和努力，通常会导致测试覆盖率低，或者产生昂贵且耗时的测试。打乱函数很难编写，但是一次可以生成许多测试用例。为了支持所有这些情况，我们提供了各种各样的 abstractions，可以从零开始扩展测试创建，并使打乱函数更容易编写
模板 测试样例和干扰通常可以归纳为一个模板，以便在一组更加多样化的输入上测试模型。图 1 中，我们将句子 "I didn't love the food"归纳为模板"I {NEGATION} {POS_VERB} the {THING}."，其中 {NEGATION} = {didn't, can't say I,...}，{POS_VERB} = {love, like,...}，{THING} = {food, filght, service,...}，用笛卡尔积生成所有的测试用例。当一小组测试用例可能遗漏问题时，更多样化的输入集特别有用，例如，模型适用于某些否定形式，但不适用于其他形式
扩展模板 虽然模板有助于扩大测试用例的生成，但是它们仍然依赖于用户的创造力来为每个占位符创建填充值。我们为用户提供 abstraction，在这个 abstraction 中，用户屏蔽掉模板的一部分，并获得用于填充屏蔽的语言模型的建议，例如，"I really {mask} the flight" 生成 {enjoyed, liked, love, regret,...}，用户可以将其过滤成积极，消极和中性的填充列表，然后在多个测试中重复使用（图 2）。有时 RoBERTa 的建议可以在不过滤的情况下使用，例如，"This is a good {mask}" 生成多个不需要过滤的名词。他们也可以用于打乱，例如，在上下文中替换诸如 "that" 或 "the" 之类的中性词（表 1 词汇 POS 不变性测试）。RoBERTa 的建议可以和 WordNet（同义词，反义词）组合在一起，例如在干扰中只选择与上下文相关的同义词。我们还为通用类别提供了额外的常见词，如命名实体（常见的男性和女性的姓、城市、国家）和受保护的群体形容词（国籍、宗教、性别和性取向等）
开源 我们在 https://github.com/marcotcr/CheckList 上发布了 CheckList 的实现。除了模板特性和掩蔽语言模型的建议，它还包含各种可视化，用于编写测试期望值（例如单调性）和扰动的抽象，保存 / 共享测试以及测试套件，以便可以在不同的模型和不同的团队中重复使用测试，以及通用扰动，例如字符交换（模拟拼写错误），缩写，名称和位置更改（用于 NER 测试）等
3 Testing SOTA models with CheckList
我们通过以下的付费 API 测试了商业情绪分析模型：Microsoft’s Text Analytics，Google Cloud’s Natural Language 以及 Amazon’s Comprehend。我们同时还在 QQP 数据集上检查了 BERT-base 和在 SST-2 上微调的 RoBERTa-base 模型。对于机器理解任务，我们使用了预训练的 BERT-large 模型，使用的数据集是 SQuAD，达到了 93.2 的（F1）成绩。此处介绍的所有测试都是开源版本的一部分，可以轻松复制并应用于新模型
情感分析 由于社交媒体数据是这些商业模型的训练数据集，所以我们在该领域进行测试，并使用未标记的航空公司 tweet 数据集进行 INV 和 DIR 扰动测试。我们针对广泛的功能创建测试，并在表 1 中显示具有高错误率的子集。词汇表 POS MFT 是健全性检查，我们希望模型能够适当地处理常见的中性或充满情感的单词。BERT 和 RoBERTa 在中性预测上表现很差（它们仅在二进制标签上进行过训练）。令人惊讶的是，谷歌和亚马逊的模型在明显中立的句子上不合格（分别为 7.6% 和 4.8%），而谷歌在非中立的健全性检查（如，"我喜欢这个座位"）也未通过（15%）。在 DIR 测试中，微软和谷歌预测的情绪分数（12.6% 和 12.4%）在明显积极的短语（例如 “你很特别”）被加进去的时候会大幅下降，而消极的短语（例如 “你很差劲”）会上升（谷歌: 34.6%）
所有模型都对随机添加（而非对抗性）的短 URL 或 Twitter 句柄以及名称更改，例如地点或人名很敏感。没有一个模型在时间、否定和 SRL 能力的测试中表现得很好。在 "食物不差" 这样简单的否定句上出错尤为值得关注，如，谷歌（54.2%），亚马逊（29.4%）。当否定句出现在句子结尾（例如，我以为这架飞机很糟糕，但其实并不是），或者在否定和充满感情的词语之间有中立的内容时，所有商业模型的错误率几乎都接近 100%
商业模型不会通过简单的公平理智检查，比如 "我是黑人女性"（模板："I am a {PROTECTED} {NOUN}"），它总是会将这些句子预测为中性。与软件工程类似，没有测试失败并不意味着这些模型是公平的，只是它们并不足以使这些简单的测试失败。另一方面，当 {PROTECTED} 是 black, gay 以及 lesbian 这些词时，BERT 总是会将它们预测为消极情感，而遇到 Asian, straight 等词的时候，BERT 又总是预测为积极情感
除了依赖于预测 “中性” 的测试外，BERT 和 RoBERTa 在几乎所有其他测试中的表现都优于所有商业模型。这个结果非常令人惊讶，因为商业模型使用的是社交媒体数据，并根据客户反馈进行定期测试和改进，而 BERT 和 RoB 是在 SST-2(电影评论)数据集上训练的模型。最终，即使 BERT 和 RoB 在包含某种否定形式（实例的 18％）的 SST-2 验证集的子集上相当准确（分别为 91.5％，93.9％），也无法通过简单否定形式的 MFT。我们的测试能够更精确地评估性能，而原始数据集上的性能表现可能更具有误导性
Quora Question Pair 尽管 BERT 和 RoB 在 QQP 数据集上的准确率超越了人类，但表 2 中的测试子集表明，这些模型远远不能解决问题释义的问题，而且很可能依赖于 shortcut 方法来获得较高的准确性
两种模型似乎都缺乏解决任务所需的关键技能：忽略单词表中重要的修饰词。缺乏对常用词的同义词和反义词的基本了解。此外，对于错别字和简单的复述都没有鲁棒性。在 NER 测试上的错误率揭示了这些模型过于依赖 shortcut，例如对命名实体的锚定，而不是理解命名实体及其对问题是否重复的影响
令人惊讶的是，这些模型通常无法对简单的时间进行区分，也无法对简单的指代进行区分。在 SRL 测试中，两种模型都无法处理指代 / 谓语更改，或主动 / 被动交换。最后，当问题顺序被颠倒时，BERT 和 RoB 有 4.4% 和 2.2% 的几率会发生变化，从而无法满足基本的任务需求。它们的预测也不符合逻辑，例如传递性
机器理解 表 3 的 Vocab POS 测试表明，BERT 经常无法正确地把握强度修饰符和比较 / 最高级。它在简单的分类问题中也失败了，例如将属性（大小，颜色，形状）与形容词进行匹配，在动物 - 交通工具，工作 - 国籍之间进行区分，或涉及反义词的比较中，它也失败了
无论是在问题还是上下文中，模型似乎都都无法处理时间概念（如之前，之后，最后和第一个）或简单的否定句。它似乎也没有理解基本的的指代，掌握简单的主语 / 宾语或主动 / 被动区别（SRL），所有这些对于真正理解一个句子都是非常重要的。最后，模型似乎带有某些特殊的偏见，例如，将一个简单的否定模板句 "{P1} is not a {PROF}, {P2} is." 作为上下文，"Who is a {PROF}?" 作为提问，如果我们设置 {PROF} 为医生，{P1}为男性的名字，{P2}为女性的名字（例如，"John is not a doctor, Mary is."; "Who is a doctor?"），模型错误的概率有 89.1%（错认为男性是医生）。如果男女名字调换，模型的错误率仅有 3.2%（错认为女性是医生）。如果 {PROF} 为秘书，模型错认为男性是秘书的概率仅有 4%，错认为女性是秘书的概率有 60.5%
讨论 我们将相同的过程应用于非常不同的任务，并发现这些测试揭示了与任务相关的各种语言能力有趣的失败。虽然有些测试仅针对特定任务（例如，积极的形容词），但能力和测试类型是一般性的；许多可以跨任务应用，例如，测试拼写错误的鲁棒性，或轻微的变化（根据任务的不同，改变命名实体会产生不同的期望）。这一小部分测试说明了除了标准评估之外，系统测试的好处。根据基本的准确性结果，这些任务可能被视为 "已解决"，但测试强调了各个方面的改进，尤其是当前任务中未能展示，而实际需要的基本技能（例如，基本否定，主体 / 对象区分等）。即使有些问题已经被其他人所发现了，例如，拼写错误，改变名字的影响，我们相信，社区并不了解其中的大多数，而全面的、结构化的测试将使得这些任务和其他任务得到改进
4 User Evaluation
上一节中发现的问题，证明 CHECKLIST 实用以及灵活。本节，我们进一步验证 CHECKLIST 是否可以为已经仔细测试过模型的用户，或对工作几乎没有经验的用户提供见解
4.1 CHECKLISTing a Commercial System
我们联系了负责通用情感分析模型的团队，该模型被微软作为一项服务出售（见表 1）。由于该模型是面向公众的系统，因此与研究型系统相比，该模型的评估程序更为全面，包括公开可用的基准数据集以及内部建立的重点基准（例如，否定，表情符号）。此外，由于该服务已经成熟，拥有广泛的客户基础，因此它经历了许多发现错误然后修复的过程。我们的目标是验证 CHECKLIST 在这种模型已经进行了广泛测试的情况下，是否还能体现其价值
我们邀请一个团队来参加大约 5 个小时的 CHECKLIST 会话。我们提供 CHECKLIST（不提供我们已经创建好的测试），然后要求他们使用该工具来测试他们自己的模型。我们帮助他们实施了测试，以降低因学习 CHECKLIST 的软件组件而带来的额外认知负担。这个团队头脑风暴了大约 30 项测试，涵盖了所有的功能，其中一半是 MFTs，其余的由 INVs 和 DIRs 平分。由于时间的限制，我们仅实施了大约 20 项测试。测试涵盖了我们自己测试过的许多相同功能（第 3 节），但也包括我们从未想到的功能。例如，他们测试了该模型是否正确处理了来自推特驼峰式标签的情感（例如 “#IHateYou”，“#ILoveYou”），隐式否定（例如 “我希望它很好”）等。此外，他们还提出了新的测试功能，例如处理不同长度的句子与段落，以及依赖于隐含期望的情绪（例如，"There was no {AC}" when {AC} is expected）
定性地说，该团队认为 CHECKLIST 非常有用：（1）他们测试了没有考虑到的功能（2）他们测试了考虑过但不在 benchmark 中的功能（3）即使是 benchmark 有的功能（例如否定），也可以使用 CHECKLIST 进行更彻底和系统的测试。他们发现了许多之前不知道的 bug，并且准备在下个版本中修复这些 bug。最后，他们表示一定会将 CHECKLIST 纳入他们的开发周期，并请求访问我们的源码。这次会话，加上我们在表 1 中为三个独立的商业模型发现的各种 bug，表明 CHECKLIST 对即使在经过压力测试后已在使用的模型也很有用
4.2 User Study: CHECKLIST MFTs
我们进行了一项用户研究，目的是为了在一个更受控制的环境中进一步评估 CHECKLIST 的不同子集，并验证即使没有任何工作经验的用户也能发现模型中的错误。我们招募了至少具有中级 NLP 经验的 18 名参与者（工业界 8 名，学术界 10 名），并要求他们使用 Jupyter notebook 测试在 QQP 上微调的 BERT。参与者可以访问 QQP 验证数据集，并被要求创建测试以探索模型的不同功能。我们将参与者平等地分成三种情况：In Unaided，我们没有为他们提供进一步的说明，而是模拟当前商业系统的状态（即使在研究模型之外，编写超出基准数据集的其他测试的做法也不常见）。In Cap. only，我们提供了 2.1 节中有关能力的简短描述。而对于 Cap. templ.，我们还额外提供了 2.3 节中的模板和一些填充用的工具。在 Unaided 组中，仅有一位参与者之前使用过 QQP 数据集。由于才刚刚入门，所以我们仅要求他们（in Unaided）编写 MFTs 的各种情况
我们将结果列在表 4 中。即使用户在使用 CHECKLIST 时不得不分析更多的指令并学习一种新工具，但他们仍然为模型创建了更多的测试。除此之外，在 Cap. templ 组中，模板和 mask language model 的建议也帮助他们生成了大量测试样例。虽然用户可以使用任意的 Python 代码而不用手工编写示例，但只有一位用户在没有帮助的情况下这样做了（并且只有一个测试）
用户在 Cap. only 和 Cap. templ. 探索了更多功能。 Unaided 的参与者仅测试了鲁棒性、词汇 POS，分类法和少量的 SRL 实例，而其他条件下的参与者则涵盖了所有功能。Cap. only 和 Cap. templ. 中的用户共同提出了与表 2 中几乎所有 MFTs 相当的测试，甚至还有我们没有考虑到的测试。Unaided 和 Cap. only 中的用户通常不会发现更多的 bug，因为他们缺乏测试用例的多样性，即使在测试正确的概念时也是如此
在实验结束时，我们要求用户以 5 分制来评估他们在每个特定测试中观察到的问题的严重性。 尽管没有 "ground truth"，但这些严重性等级可让每个用户对发现的漏洞的数量有一个了解。我们在表 4 中报告了发现的问题的严重性总和（针对严重性至少为 2 的测试），以及严重性大于或等于 3 的测试数量（可过滤掉较小的错误）。我们注意到，使用 CHECKLIST（Cap. only 和 Cap. templ.）的用户发现模型中的严重问题（以总严重性或错误数衡量）比处于控制条件（Unaided）的用户严重得多。我们与新用户（他没有创建任何测试）一起对这些错误进行了另一轮严重性评估，并获得了与自己报告的严重性几乎相同的汇总结果。
研究的结果非常令人激动：通过使用 CHECKLIST 的子集，没有经验的用户就可以在 2 小时内发现 SOTA 模型中的重大问题。此外，当被要求对 CHECKLIST 的不同方面进行评分（1-5 分）时，用户表示测试会话帮助他们了解了更多有关模型的知识，能力帮助他们更加全面地测试了模型，模板也是如此。
5 Related Work
评估特定语言能力的一种方法是创建具有挑战性的数据集。Belinkov and Glass(2019)指出了这种方法的优点，如对数据的系统控制，以及缺点，如规模小，与 “真实” 数据缺乏相似性。此外，他们注意到大多数具有挑战性的数据集都是针对于自然语言推理设计的。我们的目的不是为了取代挑战或基准数据集，而是补充它们。我们相信 CHECKLIST 保留了挑战集的许多好处，同时减轻了它们的缺点：使用模板从头开始编写示例可提供系统控制，而基于扰动的 INV 和 DIR 测试则允许测试未标记的自然数据中的行为。虽然许多挑战集关注的是极端或困难的案例，但 MFTs 还关注在给定功能的情况下容易的情况，以发现严重的 bug。最后，用户研究表明 CHECKLIST 可以轻松有效地用于各种任务。用户一天之内就可以创建完整的测试套件以进行情感分析，而两个小时内就可以为 QQP 创建 MFTs，两者都可以揭示以前未知的严重漏洞。
随着端到端深度模型的流行，大家关注的焦点开始转向 “probes”，其中针对感兴趣的语言现象（例如 NER）的 probing model 在编码器的中间表示上进行了训练。同样，关于词嵌入的先前工作也在寻找嵌入属性与下游任务执行之间的相关性。尽管作为分析方法很有趣，但这些方法不能让用户理解一个经过微调的（或端到端）模型如何为最终任务处理语言现象。例如，Tenney et al.(2019) 发现使用 BERT(96.7%)可以训练非常精确的 NER 模型，但我们发现在 QQP 或 SST-2 上的 BERT finetuned 有严重的 NER 问题。
现有的干扰技术旨在评估 NLP 模型的特定行为能力，例如逻辑一致性和抗噪声能力等。CheckList 为此类技术提供了一个框架，以便系统地评估这些技术以及各种其他功能。但是，CHECKLIST 不能直接用于非行为问题，例如数据版本控制问题，标签错误，注释者偏见，最坏情况下的安全问题或缺乏可解释性
6 Conclusion
准确性尽管很有用，但不足以评估 NLP 模型。 根据软件工程中行为测试的原理，我们提出 CHECKLIST，这是一种与模型和任务无关的测试方法，可以使用三种不同的测试类型来测试模型的各个功能。为了说明其效用，我们重点介绍了在 NLP pipeline 中多个重大问题，这些问题已 "解决" 了三个不同任务的现有 benchmarks。 此外，CHECKLIST 揭示了大型软件公司开发的商业系统中的关键错误，表明它很好地补充了当前的做法。 使用 CHECKLIST 创建的测试可以应用于任何模型，从而轻松地将其合并到当前的模型中。
我们的用户研究表明 CHECKLIST 易于学习和使用，即使是对于经过长时间测试的模型，无论是专家用户还是缺乏经验的从业人员都非常有用。本文介绍的测试是 CHECKLIST 的一部分开源版本，可以轻松地合并到现有 benchmark 中。 更重要的是，CHECKLIST 中的 abstractions 和工具可用为各种任务创建更详尽的测试套件。 由于许多测试可以按原样（例如错别字）或稍有变化（例如更改名称）应用于任务，因此，我们期望协作测试将导致 NLP 模型的评估更加健壮和详细，而不仅仅是保留现有数据的准确性。 CHECKLIST 是开源的，可从 marcotcr/checklist 获得
