如何正確地做誤差分析,NLP研究人員們需要學習一下
雷鋒網
(公眾號:雷鋒網) AI 科技評論按:嘗試分析機器學習模型在什麼時候、以什麼方式、由於什麼原因失效,我們把這稱為「誤差分析(error analysis)」。對科研人員來說,他們需要透過誤差分析選擇後續的改進方向;模型的實際使用者們也需要根據誤差分析來確定模型部署的許多細節。由於誤差分析對後續的行動方向有顯著的影響,如果誤差分析中出現了偏倚,或者誤差分析不完整,很可能會帶來我們不想看到的後果。
NLP 任務誤差分析的現狀
但是人們目前都是怎麼做誤差分析的呢?如果你翻翻自然語言處理頂級學術會議 ACL 的接收論文,你基本上會看到這樣的敘述:
-
我們針對 100 個樣本問題進行了誤差分析……
-
我們隨機選擇了 50 個回答不正確的問題並把它們分為了 6 類……
-
我們找出了 100 個不正確的預測結果並嘗試尋找共同的誤差類別……
-
……
顯然,這個領域內的研究人員們都不約而同地採用了這種做法:「我們隨機選擇了 50 到 100 個回答不正確的問題並把它們大致分為了 N 組」。(史丹佛大學 NLP 組負責人 Christopher Manning 的畫外音:問答任務的論文裡選 100 個樣本做錯誤分析的慣例恐怕出自我這裡 —— 最初我們想做 200 個的,但我一直沒有做分給我的那一半)
選擇一部分錯誤樣本做分析,看起來好像還有那麼點道理對不對?但其實這種做法有很大問題。比如,50 到 100 的樣本數量太小了,一般來說只佔到誤差總量的 5%。這麼小的取樣數量很難代表真正的誤差分佈。如果拿來做誤差分析的取樣樣本里剛好沒有體現出某個關鍵的模型問題(比如聊天助理機器人會對某些特定的語句給出不當的回答),然後就這麼把沒有得到修復的模型實際部署了,結果肯定會非常可怕。
這還沒完,樣本數量小才僅僅是常見做法中出現的第一個問題而已。在 ACL 2019 論文《 》中,作者們詳細列舉了 NLP 誤差分析中的許多個關鍵挑戰,也提出了三個原則,希望大家能夠把誤差分析做得更準確,也具備更好的可重複、可擴充、可測試性。作者們還設計了 Errudite,這是一個實踐了這些原則的互動式工具,它也可以逐個應對發現的問題。
論文作者們也撰寫了一篇介紹部落格,根據透過一個具體的錯誤分析流程來說明當前基於一小批樣本的手工、主觀誤差分析為什麼容易得出模稜兩可的、有偏倚的分析,並且可能弄錯誤差原因,以及如何藉助 Errudite 避免這些錯誤。他們的論文中還有更多的例子。雷鋒網 AI 科技評論對介紹部落格做全文編譯。
從實際例子說起
我們要對機器閱讀理解(Machine Comprehension)的一個知名基準模型 BiDAF ( )做錯誤分析。在這項任務中,首先給定一個問題和一段文字,機器閱讀理解模型需要找到能正確回答問題的文字片段。
在這個出自 SQuAD 資料集的例子中,加粗字型的 Murray Gold 創作了《Doctor Who(神秘博士)》的 2005 特別篇。
作為語言理解的最重要測試任務之一,機器閱讀理解中的誤差分析非常關鍵但也有不少困難:研究人員們都希望能夠找到先進模型中的弱點並進行改進,但是由於模型的輸入(問題、文字段落)和輸出(答案)都是非結構化的文字,能夠用來分析解讀資料集的特徵就很少。BiDAF 是研究機器閱讀理解任務的學者們非常熟悉的一個模型了,下文中拿來舉例的誤差分析就都是出自研究人員們針對 BiDAF 的真實分析。
在剛才這個例子中,BiDAF 做了錯誤的預測,給出的答案是 John Debney (下劃線)而不是 Murray Gold。我們希望能夠從這個錯誤做一些推廣,更全面地理解模型的表現。
在分析這個錯誤時,我們首先會問的問題就是:模型為什麼會出現這種錯誤?一位專家給出了一個 干擾詞猜想:BiDAF 擅長把問題匹配到各種命名實體類別上,但是如果同時出現了同型別的其它實體的話,BiDAF 就很容易被干擾。以上面那個例子來說,我們問的問題是「誰」,BiDAF 就知道我們需要一個人名,也確實回答了一個人名,只不過不是正確的那個人名。
帶著這個假說,我們下一個需要問的問題是, 「這個模型經常會犯這種錯誤嗎?」探究猜想的普適性需要研究更多類似的樣本。然而,如我們上文說到的,如果想要探索整個資料集的話,這些非結構化文字中可供利用的特徵太少了,所以研究人員們通常的做法是手工標註一些錯誤樣本,並把它們分為不同的組。
這種做法的問題在於,不同分組的定義是主觀的,不同的人會提出不同的分組方式。比如在另一個例子中,一個問「when」的問題的標準答案是「在他讀大學期間」,而模型給出的回答是「1996」,是一個錯誤的年份。有人會認為這是一個符合干擾詞猜想的問題,畢竟問題問的是時間,和模型給出的回答型別(同樣也是時間)是匹配的。但是也有人會認為它應該屬於別的錯誤類別,畢竟標準答案「在他讀大學期間」不是一個可以被識別的命名實體。如果你只是翻看這個錯誤例子的名稱和文字描述的話,很有可能你都意識不到會有這種差異。
實際上,論文作者們發現即便只是用簡單的法則定義不同的錯誤分組,這種差異性/人與人之間的不一致性也會出現:作者們找來此前曾發表過的一份錯誤分析中的一個錯誤型別及其描述,然後讓現在的專家們重複這個實驗,結果他們分到這一組的錯誤數量大為不同,
差異最小也有 13.8%,最大甚至有 45.2%;這更明顯地體現出了人工標註的模糊性。
針對這種狀況,論文作者們提出了第一條原則:必須用明確的描述精確定義錯誤猜想。
原則 1:準確
為了規避人為主觀性、提高準確性,Errudite 使用了一種任務專用語言(Domain-Specific Language)來量化描述不同的例項。
簡單來說,這種任務專用語言使用了一系列強有力的屬性提取器,在額外的輔助運算子的幫助下解析具體的錯誤( 屬性提取器、目標、運算子三部分)。比如可以解析一個問題的長度,並要求長度大於 20。這樣,研究人員們就可以根據特定的模式,客觀、系統地對大量錯誤例子分組,得出某種錯誤的準確的出現頻率。比如下圖就是用這種語言對「干擾詞猜想」的準確描述,也就可以把「在他讀大學期間」這個例子排除在這個分類之外。
原則 2:覆蓋所有的資料
在 BiDAF 的所有錯誤中執行了這個過濾器之後,一共找到了 192 個例子是符合「干擾詞猜想」的,也就是說標準答案和錯誤答案的命名實體型別相同,然後模型給出了錯誤的實體。值得注意的是,在達到了這種準確性的基礎上,任務專用語言的運用也可以極大地擴充誤差分析的規模:相比於常見做法裡一共分析 50 到 100 個錯誤樣本,現在單個錯誤類別的樣本量都達到了 192。這也就減小了取樣誤差。
總數量方面,這 192 個錯誤樣本佔到了所有錯誤總數的 6%,這個干擾詞猜想看來是可以被證實的。有具體資料以後,錯誤分析的說服力也變強了很多對吧。
不過,當我們執行了所有步驟中的過濾器、構建出了詳盡的分組以後,我們其實會發現全新的圖景:對於全部樣本,BiDAF 能給在 68% 的樣本中給出正確的實體;對於標準答案就是一個實體的樣本,模型的準確率會提高到 80%;當文字中有同一個型別的其它實體的時候,BiDAF 的準確率仍然有 79%;讓它預測一個型別正確的實體的時候,它的準確率高達 88%,要比全部樣本的正確率高得多。這意味著,對於實體型別匹配、且有干擾詞出現的情況, 模型的表現還是比整體表現要好,這種情況並不是模型表現的短板。所以,如果你只是發現了有某種錯誤出現,然後就決定要先解決這種錯誤的話,你可能需要重新考慮一下,因為你很可能忽視了模型表現非常糟糕的情境。
所以,這個領域專用語言可以幫助分析整個資料集,包括檢驗沒有出錯的樣本。這樣的誤差分析更系統、可以支援更大的規模;相比於只看一小部分樣本,你得到的結論也可能完全不同。
那麼,第二條原則可以正式地表述為: 錯誤出現頻率的分析應該在整個資料集上進行,其中需要包括正例(true positive)。
原則 3:測試錯誤猜想,驗證因果性
現在我們已經建立起關於干擾詞的分組了。但是,出現錯誤的時候同時有一個干擾詞並不一定代表干擾詞是這個錯誤出現的根本原因。回到前面的例子,我們可以簡單地認為出錯的根本原因是因為有干擾詞,但也可能是因為我們需要做多句推理,需要把「神秘博士」和「系列」聯絡起來,又或者還有別的原因。
這就引出了我們當前面對的現狀中的另一個問題:我們很難有效地分離某個錯誤的根本原因。想要弄清的話,我們需要第三個原則
原則 3:錯誤猜想要經過顯式的測試驗證
藉助 Errudite,論文作者們想要回答這個問題:這 192 個錯誤都是因為有干擾詞才出錯的嗎?驗證方法是提出並驗證一個相關的假想問題:「如果沒有這個干擾詞,模型能不能給出正確的答案?」作者們利用重寫規則,用反事實分析(counterfactual analysis)尋找答案。
根據這個領域專用語言,Errudite 可以按一定的規則重寫分組內的所有例項。比如在這裡,為了驗證干擾詞是否是根本原因,根據重寫規則把文字中的干擾詞都替換成無意義的佔位符「#」,這樣就不會再被檢測為實體。
在重寫完成以後讓模型重新進行預測。在前面那個神秘博士的例子裡,即便已經用「#」替換了錯誤答案 John Debney,模型仍然給出了另一個錯誤答案 Ron Grainer。看來另一個干擾詞仍然迷惑了模型。
對於分組中的其它樣本,有 29% 的情況模型會給出另一個不正確的同型別實體(另一個干擾詞);在 48% 的情況中,模型給出了正確的預測,這部分樣本里確實是干擾詞帶來了錯誤預測;在剩下的 23% 中,模型給出了和之前相同的預測 —— 只不過由於現在那些字元已經被「#」替換,所以模型的預測結果就會包含這個沒有任何實際含義的「#」字元!可以猜測這可能是因為問題和預測答案高度重合,所以模型實際做的更接近於直白的字元匹配而不是尋找實體。從這種反事實分析中得到的結論就不是僅僅做一下分組就能得到的了。
準確 + 可重現 + 可重複應用
在上面這個誤差分析過程中,我們需要用準確的查詢語句構建屬性、分組,以及執行重寫規則。對 BiDAF 進行分析過後,我們發現有干擾詞的時候它的表現並不怎麼差,而且一些以前我們以為是干擾詞引起的問題其實有其它的根本原因。
此外,準確的查詢語句有一個非常大的好處,就是可以輕鬆地分享給他人、重現實驗結果,以及其它的模型乃至其它的任務中應用。
最後,論文作者們還表示這個 Errudite 工具有一個明瞭、易用、多功能的圖形化使用者介面,而且帶有語句示範、屬性分佈圖等實用功能。
要點總結
常見(但有偏倚的)誤差分析來自於
-
主觀的錯誤分組 + 小樣本 + 只關注錯誤情況 + 沒有針對根本原因的測試
Errudite(改進的)誤差分析
-
準確、可重複的分組 + 分析整個資料集 + 包含了正例和負例 + 透過反事實分析測試驗證
NLP 領域之外的誤差分析的啟示
目前的 Errudite 實現(尤其是其中的領域專用語言部分)只是針對 NLP 任務的。然而,機器學習系統也經常需要處理非文字資料。論文作者們相信,即便目前他們的實現難以擴充到其它的領域,但他們的三條原則,完全可以、也完全有必要在其他的領域中得到應用,幫助大家部署正確的模型、向正確的研究方向深入挖掘。
想要建立一個新的基於這三條原則的工具並不難,只需要它可以支援對應的這三個要點:
-
運用領域專用語言,透過可編輯修改的基礎部件,完成準確的樣本分組;
-
擴充誤差分析規模,透過自動的過濾語句分析包括正例和負例在內的所有樣本,並提供視覺化的統計資料;
-
能夠透過規則重寫樣本,以便透過反事實分析驗證錯誤猜想。
作者們表示,Errudite 的軟體架構可以支援擴充到其它的 NLP 任務中,他們歡迎更多 NLP 領域內的研究和開發人員加入 Errudite 的開發和擴充中來。而且,如果其它領域也能出現類似的工具那就更棒了。
論文原文地址:
Errudite 開源地址:
via ,雷鋒網 AI 科技評論編譯
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29829936/viewspace-2654665/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何正確學習Node
- 如何正確學習JavaScript?JavaScript
- 如何正確學習 Node.jsNode.js
- 做資料分析需要學習機器學習嗎?機器學習
- Android日常學習:如何高效 & 正確地獲取View的座標位置?AndroidView
- WCF技術我們應該如何以正確的方式去學習掌握
- 開發人員需要知道如何做,做什麼,和為什麼做
- 新手如何學習Python基礎?該如何正確學習呢?Python
- 如何用最強模型BERT做NLP遷移學習?模型遷移學習
- 如何正確學習web前端流程以及如何找工作Web前端
- Java 如何正確地輸出日誌Java
- 如何正確地寫出單例模式單例模式
- Android-如何正確地使用HandlerAndroid
- IT職場:如何正確有效的學習六西格瑪?
- 運維人員如何有效的防止誤刪資料?Linux學習!運維Linux
- 新手要正確看待外掛學習與資料分析
- 如何正確學習Linux系統呢?Linux運維學習Linux運維
- 微信高階研究員解析深度學習在NLP中的發展和應用深度學習
- [技術討論]什麼是正確的學習和研究態度
- 如何正確理解神經網路在NLP領域的運用神經網路
- Java程式設計師如何正確地學習新的知識,擴充自己的技術棧Java程式設計師
- 免費的NLP學習資源,瞭解一下
- 【譯】如何通過 INUIAddVoiceShortcutButtonDelegate 正確地使用 INUIAddVoiceShortcutButtonUI
- 學習風變程式設計,是我做過最正確的決定!程式設計
- 如何學習或分析別人的框架?框架
- 為什麼 Web 開發人員需要學習一個 JavaScript 框架?WebJavaScript框架
- Java學習的正確開啟方式Java
- 別人搶紅包,我們研究一下紅包演算法演算法
- 業務人員怎麼做資料採集分析?
- 運維人員如何學習python程式設計運維Python程式設計
- 我們如何使用CRM做資料分析?
- 測試人員如何做需求評審?
- 作為一名SAP從業人員,需要專門學習數學麼
- Swift 里正確地 addTarget(_:action:for:)Swift
- 如何快速又正確地在C++裡實現鎖C++
- 我們如何正確的在Ubuntu上安裝phpmyadmin?UbuntuPHP
- NLP學習1
- 我們需要學習程式設計嗎?程式設計