网上有很多关于pos机测试工作流程,用 CheckList 对 NLP 模型进行行为测试的知识，也有很多人为大家解答关于pos机测试工作流程的问题，今天pos机之家(www.poszjia.com)为大家整理了关于这方面的知识，让我们一起来看下吧!
本文目录一览：
pos机测试工作流程
引用
Ribeiro, M. T., Wu, T., Guestrin, C., & Singh, S.(2020). Beyond Accuracy: Behavioral Testing of NLP models with CheckList. Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics.
摘要
虽然传统评估模型好坏的方法是在测试集上观察精度指标，但它往往高估了 NLP 模型的性能，而评估模型的其他方法要么侧重于个别任务，要么侧重于特定行为。受软件工程中行为测试原则的启发，本文引入了 CheckList，一种测试 NLP 模型的任务无关的方法。CheckList 包括一个通用语言能力和测试类型的矩阵以及一个可快速生成大量不同的测试案例的软件工具。本文将通过三个任务的测试来说明 CheckList 的效用，在商业和先进的模型中识别关键故障。在一项用户研究中，一个负责商业情感分析模型的团队在一个广泛测试的模型中发现了新的可操作的 bug。在另一项用户研究中，相较于没有使用 CheckList 的用户，使用 CheckList 的 NLP 使用者创建了两倍的测试，并发现了近乎三倍的 bug。
1.介绍
训练 NLP 模型的主要目标之一是泛化。由于其他测试集进行测试是昂贵且不允许快速迭代的，所以评估的标准范式是划分训练验证-测试集评估模型的准确性。虽然在验证集的表现是一个有用的指标，但它通常并不全面，并且包含与训练数据相同的偏差，这样其实际的表现可能被高估。此外，通过将性能总结为一个单一的统计量，就很难弄清楚模型的失败之处，甚者也无法得知如何修复它。
目前已经提出了一些评价方法，如评估对噪声的鲁棒性或对抗性变化、公平性、逻辑一致性，可解释性，诊断数据集以及相互间的错误分析。但这些方法要么关注个别任务，如问答或自然语言推理，要么关注少数能力(如鲁棒性)，因此没有为如何评估模型提供全面的指导。另一方面，软件工程研究已经提出了各种测试复杂软件系统的范式和工具。特别是“行为测试”(也被称为黑盒测试)，它关注的是通过验证输入输出行为来测试系统的不同能力，而无需对内部结构有任何了解。
本文提出了 CheckList，一种新的评估方法和配套工具，用于对 NLP 模型进行全面的行为测试。CheckList 通过提供一个语言能力的清单，指导用户进行测试，这些能力适用于大多数任务。为了将潜在的能力故障分解成具体的行为，CheckList 引入了不同的测试类型，如在某些扰动下的预测不变性，或在一组“sanity checks”上的表现。最后，本文对 CheckList 的实现包括多个抽象，帮助用户轻松生成大量的测试案例，如模板、词典、通用扰动、可视化和上下文感知建议。
本文使用 CheckList 对商业情感分析模型进行了测试，其结果如图 1 所示。潜力测试被结构化为一个概念矩阵，能力为行，测试类型为列。作为对模型否定能力的测试，使用最小功能测试(MFT)，即针对特定行为设计的简单测试案例(图 1A)。用预先建立的词库生成大量简单的例子，填入一个模板(“I {NEGATION} {POS_VERB} the {THING}.”)，并计算该模型在这些例子上的失败率。命名实体识别(NER)是另一项能力，在图 1B 中用不变性测试(INV)进行测试—这是一种不改变模型输出的扰动测试。在这种情况下，改变位置名称不应改变情感值。在图 1C 中，用定向预期测试(DIR)来测试模型的词汇表--对已知预期结果的输入进行扰动--添加负面短语并检查情绪是否变得更加积极。正如这些例子所表明的，矩阵作为一个指导，提示用户用不同的测试类型来测试每个功能。
图 1 CheckListing 一个商业情感分析模型。测试的结构是一个概念矩阵，能力为行，测试类型为列(A、B 和 C 中每种类型的例子)
通过对三个 NLP 任务的实例化来证明 CheckList 的实用性和通用性：情感分析、重复问题检测和机器理解。虽然传统的基准表明，这些任务的模型与人类一样准确，但 CheckList 揭示了各种严重的错误，商业和研究模型不能有效地处理基本的语言现象，如否定、命名实体、指代、语义角色标签等，因为它们与每个任务有关。
2.CheckList
2.1能力
CheckList 鼓励用户考虑不同的自然语言能力在手头的任务上是如何体现的，并创建测试来评估模型的每一项能力。例如，Vocabulary+POS 能力涉及到模型是否有必要的词汇量，以及它是否能够适当地处理具有不同语篇的词汇对任务的影响。对于情感分析的任务，可能会想到检查模型是否能够识别带有积极、消极或中性情绪的词语，并进一步验证其在“This was a good flight.”这样的例子中的表现。对于 QQP，可能希望该模型能够理解修饰语对问题的区分，例如(“Is John a teacher?”，“Is John an accredited teacher?”)。对于机器理解任务，该模型需要将比较级和最高级联系起来，例如(Context:“Mary is smarter than John.”，Q：“Who is the smartest kid?”，A：“Mary”)。
本文建议用户至少要考虑以下能力。Vocabulary+POS(对任务来说重要的词或词的类型)、分类法(同义词、反义词等)、稳健性(对拼写错误、不相关的变化等)、NER(适当地理解命名的实体)、公平性、时态(理解事件的顺序)、否定、指代、语义角色标签(理解代理、对象等角色)和逻辑(处理对称性、一致性和连词的能力)。本文将在第 3 节提供如何测试这些能力的例子(表 1、2 和 3)。这个能力清单并不详尽，但对于用户而言是一个起点，用户还应该提出针对他们的任务或领域的其他能力。
2.2测试类型
本文提示用户用三种不同的测试类型(在可能的情况下)来评估每个功能：最小功能测试、不变性和定向期望测试(矩阵中的列)。
最小功能测试(MFT)，受软件工程中单元测试的启发，是一个简单的例子(和标签)的集合，用于检查能力中的行为。MFTs 类似于创建小而集中的测试数据集，特别适用于检测模型何时使用快捷方式处理复杂的输入而不实际掌握功能。上一节中的 Vocabulary+POS 例子都是 MFTs。
本文还引入了两个额外的测试类型，其灵感来自于软件变形测试。不变性测试(INV)是指对输入标签进行扰动时，期望模型预测保持不变。不同的功能需要不同的扰动函数，例如，更改情感分析的 NER 功能的位置名称(图 1B)，或引入拼写错误来测试鲁棒性功能。方向期望测试(DIR)类似，只是标签预期会以某种方式改变。例如，如果在针对航空公司的推文末尾加上“You are lame.”，预计这种情绪不会变得更积极(图 1C)。期望值也可能是一个目标标签，例如，仅替换 QQP 中一个问题中的位置，如(“How many people are there in England?”，“What is the population of England -> Turkey?”)，确保问题不重复。INVs 和 DIRs 允许在无标签的数据上测试模型--它们测试的行为不依赖于真实标签，而是依赖于应用扰动后预测之间的关系(不变性、单调性等)。
2.3生成大规模的测试案例
用户可以从头开始创建测试案例，或者通过扰动现有的数据集来创建。从零开始可以更容易地为在原始数据集中没有被充分表示或混淆的特定现象创建少量高质量的测试用例。然而，从头开始写，需要极大的创造力和努力，往往导致测试的覆盖率低，或者测试成本高、耗时长。扰动函数更难制作，但可以一次生成许多测试案例。为了支持这两种情况，本文提供了各种抽象，以扩大从头开始的测试创建，使扰动更容易制作。
模板：测试用例和扰动通常可以被概括为一个模板，以便在更多的输入上测试模型。在图 1 中，用模板“I{NEGATION}{POS_VERB}the{THING}.”概括了“I didn’t love the food.”，其中NEGATION={didn’t,can’t say I,...}，{POS_VERB}={love,like,...}，{THING}={food,flight,service,...}，并用笛卡尔乘积生成所有测试案例。
扩展模板：虽然模板有助于扩大测试案例的生成，但是它们仍然依赖于用户的创造力来为每个占位符创建填充值。本文为用户提供一个抽象，在这个抽象中，他们屏蔽模板的一部分，并获得用于填充屏蔽的语言模型的建议，例如，“I really {mask} the flight”生成{enjoyed, liked, love, regret,…}，用户可以过滤成积极、消极和中性的填充列表，然后在多个测试中重复使用(图 2)。有时，RoBERTa 的建议可以不经过滤而使用，例如，“This is a good{mask}”会产生多个不需要过滤的名词。它们也可以用于扰动中，例如，在上下文中替换诸如“that”或“the”之类的中性词(表 1 中的 Vocabulary+POS INV 示例)。RoBERTa 建议可以与 WordNet 类别(同义词，反义词等)相结合，例如，在扰动中只选择与上下文相适应的同义词。此外，本文还提供了通用类别的其他常见词，如命名实体(常见的男性和女性的名字/姓氏，城市，国家)和受保护的群体形容词(国籍，宗教，性别和性取向等)。
图 2 用遮蔽的语言模型进行模板设计。“I really {mask} the flight.”产生的用户可以交互式地过滤成积极的、消极的
和中性填充列表动词
表 1 情感分析的一系列测试。所有的例子(右)都是至少一个模型的失败
3.用 CheckList 测试 SOTA 模型
情感分析：由于社交媒体被列为这些商业模型的使用案例，故本文在该领域进行测试，并使用未标记的航空公司推文数据集进行 INV4 和 DIR 扰动测试。表 1 中列出了失败率高的子集。Vocab.+POS MFTs 是健全性检查，希望模型能够适当地处理常见的中性或带感情色彩的词。BERT-base 和 RoB 在中性预测方面表现很差(它们只在二进制标签上训练)。令人惊讶的是，谷歌和亚马逊的模型在明显是中性的句子上不合格(7.6%和 4.8%)，而谷歌在非中性的健全性检查(例如，“I like this seat.”)上也未通过(15%)。在 DIR 测试中，当加入明显的积极短语(如“You are extraordinary.”)时，微软和谷歌预测的情感分数(12.6%和 12.4%)大幅下降，对消极短语(如“You are lame.”)上升(谷歌：34.6%)。
商业模型没有通过简单的公平性理智检查，如“I am a black woman.”(模板：“I am a {PROTECTED{NOUN}.”)，总是把它们预测为中性。与软件工程类似，没有测试失败并不意味着这些模型是公平的--只是它们不足以通过这些简单的测试。另一方面，当PROTECTED是黑人、无神论者、同性恋和女同性恋时，BERT-base 总是预测为消极情感，而对亚洲人、异性恋等则预测为积极情感。
除了依赖于预测“中性”的测试外，BERT-base 和 RoB 在其他几乎所有的测试中都比所有商业模型做得更好。这是一个令人惊讶的结果，因为商业模型将社交媒体作为一个用例，并通过客户反馈进行定期测试和改进，而 BERT-base 和 RoB 是在 SST-2 数据集(电影评论)上训练的研究模型。最后，即使 BERT-base 和 RoB 在包含某种否定形式（实例的 18％）的 SST-2 验证集的子集上相当准确（分别为 91.5％，93.9％），也无法通过简单否定形式的 MFT。
Quora问题对：对虽然 BERT-base 和 RoB 在基准测试中超过了 QQP 的人类准确性，但表 2 中的测试子集表明，这些模型远远不能解决问题释义问题，并且很可能依赖捷径获得高精度。
表 2 对 Quora 问题对的测试选择。所有的例子(右边)都是至少一个模型的失败
两种模式都缺乏对任务来说至关重要的技能：忽略了词汇测试中的重要修饰语，缺乏对常用词的同义词和反义词的基本了解。此外，两者对错别字或简单的转述都不健全。NER 测试的失败率表明，这些模型依赖捷径，例如过于依赖命名实体，而不是理解命名实体及其对问题是否重复的影响。
令人惊讶的是，这些模型往往不能进行简单的时间区分(如 is 不等同与used to be 和 before 不等同于 after)，也不能区分简单的指代(he 不等同于 she)。在 SRL 测试中，两个模型都不能处理指代/谓语的变化，或主动/被动的交换。最后，当问题顺序被翻转时，BERT-base 和 RoB 的预测分别有 4.4%和 2.2%的变化，未能满足基本的任务要求。
机器理解：表 3 中的 Vocab+POS 测试显示，BERT-base 通常不能正确掌握强度修饰词和比较/最高级。它在简单的分类测试中也失败了，如将属性(大小、颜色、形状)与形容词相匹配，区分动物-交通工具或工作-国籍，或涉及反义词的比较。
表 3 机器理解的测试选择
无论是在问题还是上下文中，模型似乎都都无法处理时间概念（如之前，之后，最后和第一个）或简单的否定句。它似乎也没有理解基本的的指代，掌握简单的主语/宾语或主动/被动区别（SRL），所有这些都是真正理解句子的关键。最后，该模型似乎有某些偏见，例如，对于简单的否定模板“{P1} is not a {PROF}, {P2} is.”作为上下文，“Who is a {PROF}?”作为问题，如果我们将PROF=doctor，{P1}设为男性名字，{P2}设为女性名字(例如，“John is not a doctor, Mary is.”；“Who is a doctor?”)，模型错误的概率有 89.1%(选择男人作为医生)。如果男女名字调换，模型的错误率仅有 3.2%(女性被预测为医生)。如果PROF=secretary，它只有 4.0%的概率认为男性是秘书，而 60.5%的概率认为女性是秘书。
4. 用户评价
4.1 CheckListing一个商业系统
我们联系了负责微软作为服务出售的通用情感分析模型的团队(表 1 中的 q)。由于它是一个面向公众的系统，该模型的评估程序比研究系统更全面，包括公开的基准数据集和内部建立的重点基准(如否定句、表情符号)。此外，由于该服务是成熟的，有广泛的客户群，因此它经历了许多发现错误然后修复的过程。本文的目标是验证 CHECKLIST 在这种模型已经进行了广泛测试的情况下，是否还能体现其价值。
我们邀请该团队参加了一场持续约 5 小时的 CheckList 会议。我们介绍了 CheckList(没有介绍已经创建的测试)，并要求他们使用该方法来测试他们自己的模型。进一步帮助他们实现他们的测试，以减少学习 CheckList 软件组件的额外认知负担。该团队集思广益，提出了大约 30 个涵盖所有能力的测试，其中一半是 MFTs，其余的大致平均分配给 INV 和 DIR。由于时间限制，仅实施了其中的 20 个测试。这些测试涵盖了许多本文测试过的相同的功能(第 3 节)，经常使用不同的模板，但也包括我们从未想到的功能。例如，他们测试了该模型是否正确处理了来自推特驼峰式标签的情感(如“#IHateYou”、“#ILoveYou”)、隐性否定(如“I wish it was good”)等。此外，他们还提出了新的测试能力，例如处理不同的长度(句子与段落)和依赖于隐含期望的情绪(例如，“There was no {AC}” when {AC} is expected)。
该团队认为 CHECKLIST 非常有用：(1)他们测试了他们没有考虑过的功能，(2)他们测试了他们考虑过但不在基准中的能力，以及(3)即使是他们有基准的能力(例如否定)，也通过 CheckList 进行了更彻底和系统的测试。他们发现了许多以前未知的错误，并计划在下一次模型迭代中修复这些错误。最后，他们表示一定会将 CheckList 纳入他们的开发周期，并请求访问我们的源码。这次会议，再加上在表 1 中为三个独立的商业模型发现的各种 bug，表明 CheckList 对即使在经过压力测试后已在使用的模型也很有用。
4.2用户研究：CheckList MFTs
我们进行了一项用户研究，目的是为在一个更加可控的环境中进一步评估 CheckList 的不同子集，并验证是否即使是没有任何任务经验的用户也能发现模型中的错误。我们招募了 18 名至少有中级 NLP 经验的参与者(8 名来自工业界，10 名来自学术界)，并让他们在 QQP 上测试，时间为两小时(包括指导)，使用 Jupyter notebook。参与者可以访问 QQP 的验证数据集，并被指示创建测试，探索模型的不同功能。我们把参与者平均分成三种情况：在 Unaided 中，我们没有给他们进一步的指示，模拟商业系统的现状(甚至在基准数据集之外编写额外测试的做法在研究模型中也不常见)。在 Cap.only 中，只提供第 2.1 节中列出的能力的简短描述作为测试建议，而在 Cap.+templ.中，则进一步向他们提供第 2.3 节中描述的模板和填写工具。只有一个参与者(在 Unaided)之前有 QQP 的经验。由于研究时间较短，所以只要求他们编写 MFTs 的各种情况。
将结果显示在表 4 中。即使用户在使用 CHECKLIST 时不得不分析更多的指令并学习一种新工具，但他们仍为模型创建了更多的测试。此外，模板和掩蔽语言模型建议帮助用户在 Cap.+templ 中为每个测试生成大量测试用例。
表 4 用户研究结果：前三行表示创建的测试数量，每个测试的测试案例数量和测试的能力数量。用户报告他们研究结果的严重程度(最后两行)
用户在 Cap.only 和 Cap.+templ.上探索了更多的功能(事后对功能的测试进行了注释)；在 Unaided 中，参与者只测试了 Robustness、Vocabulary+POS、Taxonomy 和少数 SRL 实例，而其他条件下的参与者则涵盖了所有功能。在 Cap.only 和 Cap.+templ.中的用户共同提出了相当于表 2 中几乎所有 MFTs 相当的测试，以及更多我们没有考虑过的测试。在 Unaided 和 Cap.only 的用户往往不会发现更多的 bug，因为他们缺乏测试案例的多样性，即使是在测试正确的概念时(如否定)。
在实验结束时，要求用户对他们在每个特定测试中观察到的故障的严重程度进行评估，采用 5 分制。在表 4 中报告了被发现的错误的严重程度总和(对于严重程度至少为 2 的测试)，以及严重程度大于或等于 3 的测试的数量(过滤掉小错误)。注意到，使用 CheckList(仅 Cap.only 和 Cap.+templ.)的用户在模型中发现了比对照条件(Unaided)下的用户更严重的问题(以总严重度或#bug 来衡量)。我们与新用户（他没有创建任何测试）一起对这些错误进行了另一轮严重性评估，并获得了与自己报告的严重性几乎相同的汇总结果。
研究结果是令人激动：通过使用 CheckList 的一个子集，没有经验的用户能够在短短 2 小时内找到 SOTA 模型中的重大错误。此外，当被问及如何评价 CheckList 的不同方面(1-5 分)，用户表示测试会话帮助他们了解更多的模型(4.2-5)知识，更全面地测试模型(4.1-4.9)，模板(3.2-5)也是如此。
5.相关工作
评估特定语言能力的一种方法是创建具有挑战性的数据集。Belinkov 和 Glass(2019)注意到这种方法的好处，如对数据的系统控制，也有缺点，如规模小和缺乏与“真实”数据的相似性。此外，他们还指出，大多数挑战性的数据集是针对自然语言推理的。而本文的目标不是让 CheckList 取代挑战或基准数据集，而是对它们进行补充。我们认为 CheckList 保持了挑战集的许多优点，同时减轻了它们的缺点：用模板从头开始编写例子提供了系统的控制，而基于扰动的 INV 和 DIR 测试允许在无标签的、自然发生的数据中测试行为。虽然许多挑战集专注于极端或困难的情况，但 MFTs 也集中在给定能力的简单情况下，发现严重的错误。最后，用户研究表明，CheckList 可以有效地用于各种任务，用户在一天内创建了一个完整的情感分析测试套件，在两个小时内创建了 QQP 的 MFTs，两者都揭示了以前未知的严重错误。
随着端到端深度模型的普及，社区已经转向“探测”，即在编码器的中间表示上训练感兴趣的语言现象(如 NER)的探测模型。沿着类似的思路，以前关于词嵌入的工作寻找嵌入的属性和下游任务执行之间的相关性。虽然作为分析方法很有趣，但这些并没有让用户了解微调(或端到端)模型如何处理最终任务的语言现象。例如，虽然 Tenney 等人(2019)发现可以使用 BERT 训练非常准确的NER 模型(96.7%)，但我们发现 BERT 在 QQP 或 SST-2 上微调后显示出严重的 NER 问题。
现有的扰动技术旨在评估 NLP 模型的特定行为能力，如逻辑一致性和对噪音的鲁棒性等。CheckList 为这类技术提供了一个框架，以系统地评估这些技术和其他各种功能。然而，CheckList 不能直接用于非行为问题，如数据版本问题、标签错误、注释者偏差、最坏情况下的安全问题或缺乏可解释性(。
6.结论
准确性尽管很有用，但不足以评估 NLP 模型。通过采用软件工程中的行为测试原则，我们提出了 CheckList，一种与模型无关、与任务无关的测试方法，使用三种不同的测试类型来测试模型的各个功能。为了说明它的效用，我们强调了在 NLP 管道的多个层次上的重大问题，这些模型已经“解决”了三个不同任务的现有基准。此外，CheckList 揭示了大型软件公司开发的商业系统中的关键错误，表明它很好地补充了当前的做法。用 CheckList 创建的测试可以应用于任何模型，从而轻松地将其合并到当前的模型中。
用户研究表明，CheckList 很容易学习和使用，对那些已经对他们的模型进行了长时间测试的专家用户和缺乏经验的从业人员都很有帮助。本文介绍的测试是 CheckList 开源版本的一部分，可以很容易地合并到现有的基准中。更重要的是，CheckList 中的抽象和工具可以被用来为各种任务共同创建更详尽的测试套件。由于许多测试可以按原样（例如错别字）或稍有变化（例如更改名称）应用于任务，我们期望协作测试的创建将导致对 NLP 模型的评估更加稳健和详细，而不仅仅是对保持数据的准确性。
鸣谢
本文由南京大学软件学院 2021 级硕士颜昌粤翻译转述。
以上就是关于pos机测试工作流程,用 CheckList 对 NLP 模型进行行为测试的知识，后面我们会继续为大家整理关于pos机测试工作流程的知识，希望能够帮助到大家！
