網上有很多關于pos機測試工作流程,用 CheckList 對 NLP 模型進行行為測試的知識，也有很多人為大家解答關于pos機測試工作流程的問題，今天pos機之家(www.www690aa.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機測試工作流程的知識，希望能夠幫助到大家！
