作者 | 陳大鑫

編輯 | 叢 末

現在，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）：

1. 詞彙+POS（任務的重要單詞或單詞類型）

2. Taxonomy（同義詞、反義詞等）

3. 健壯性（對拼寫錯誤、無關更改等）

4. NER（正確理解命名實體）

5. 公平性

6. 時態（理解事件順序）

7. 否定

8. 共指（Coreference），

9. 語義角色標記（理解諸如agent、object等角色）

10. 邏輯（處理對稱性、一致性和連詞的能力）。

通過以上，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

若還有進一步的學術交流和項目合作可聯繫吳同學的郵箱：[email protected]

感謝吳同學的用心回答，祝吳同學一路優秀下去，心想事成~天天開心！