全文共 2006字，預計學習時長 4分鐘

標註NLP資料就像開飛機，看起來容易，但你永遠不知道會遇到什麼情況，往往會出現一些莫名其妙的錯誤。找到出錯的地方，然後檢測並修復錯誤才是良好的第一步。

本文將分享NLP實體標註中出現的四個常見問題，討論它們的根本原因和可能的解決方案。

空白

標記者不一致的最常見原因可能是尾隨空格和前導空格以及標點符號的標註不一致。也就是說，某個標記者可能會標註“Tal Perry”，另一個則會標註“Tal Perry“或“Tal Perry”或“Tal Perry“。這個問題也出現在尾隨標點中，比如“Tal Perry.”。

當衡量標註者的一致性或決定一個好的註釋來源時，這些衝突會導致一致性分數較低，並在好的標註集中出現模糊性。這些錯誤尤其令人沮喪，因為註釋在概念上是正確的，人類不會真正注意到或關心差異。

事實上，這種微妙的差異是導致這些錯誤的根本原因。通常，標註者不關心演算法如何計算一致性，不會注意到或關心“Tal Perry”和 “Tal Perry “之間的差異，除非被明確要求這樣做。

在這方面解決方案很簡單，當註釋工具讀取了尾隨空格和前導空格時，應直觀地指示標註者，並讓他們根據設定的指南來決定這是否正確。

巢狀註釋

對於生命這樣複雜的事情，鳥巢是很好的棲身之所。但對於NLP來說，也許你需要的是其它的東西。

另一個常見的不一致來源是 "巢狀註釋"。例如" The President Of the United States Donald Trump " 一語可用許多不同的方式標註。

造成這種錯誤的原因涉及到基本原則，語言本質上是分層的，而不是線性的，因此線性註釋 (如突出顯示的部分) 並不總是完全適合的。

從使用者體驗的角度來看，一個簡單的解決方案是在 Brat 或註釋樹結構中，讓標註者建立巢狀註釋。雖然這些解決方案從使用者體驗的角度來看是可行的，但它們需要下游模型，這些模型可以在模型的輸入和輸出中處理這些複雜的非線性結構。

我們還未從客戶群中看到在語言社群之外大規模採用結構化註釋。這主要是由於需要額外模型和複雜的工程才能與他們合作。我們常看到的是註釋專案，這些專案指導團隊以儘可能最好的解決方案進行標註，並在稍後階段用後處理來讀取固有的結構。

在中途新增新實體型別

在註釋專案的早期階段，通常會發現需要未預期的實體型別。例如，比薩餅聊天機器人的標籤集可能從標籤 " Size " "topping" 和"drink" 開始，然後才會意識到你還需要一個 " Side Dish " 標籤來讀取大蒜麵包和雞翼。

簡單地新增這些標籤並繼續處理尚未標註的文件會對專案造成危險。在新增新標記之前，所有標註過的文件中都將丟失新標記，這意味著對於這些標記來說，測試集是錯誤的，並且培訓資料將不包含新標記，導致模型無法讀取它們。

講究的解決方案是重新開始，並確保讀取所有標籤。但是, 這非常浪費資源，每次需要新標記時重新開始都是對資源的不太理想的使用。折中的做法是重新開始，但使用現有的註釋作為 "預註釋"顯示給標註者。例如，LightTag 的文字標註工具可以完全做到這一點，顯示標註者的預註釋，他們可以透過單擊按鈕來接受這些標註。之後他們可以專注於新增新的標籤。

長標籤列表

增加專案成本和降低資料質量的一個可靠方法是強制標註者處理很長的標籤列表。ImageNet 有 20000個不同的類別, 如草莓、熱氣球和狗。在文字中，SeeDev 2020 共享任務定義了此處顯示的 "僅" 16 種實體型別，但可看到它們如何迅速變得勢不可擋。

在標註過程中，增加標註者需要作出的選擇的數量會降低它們的標註速度，並導致資料質量低下。值得注意的是，註釋的分佈將受到使用者體驗註釋中標記排序方式的影響。這是由於可用性偏差造成的，在這種情況下，我們更容易識別最重要的概念 (在我們的頭腦中可用)。

Imagenet中有 20000個類別屬於這個問題的極端例子，關於註釋是如何收集的論文值得一讀。他們的方法包括將註釋任務分解為更小的任務，其中針對每個子任務，每個標註者將對某個類的一個例項進行註釋 (而其他工作人員將有單獨的驗證任務)。這大大降低了標註者的認知負載，幫助他們減少錯誤，更高效地工作。

結論

資料標註需要快速、大規模、高精度地進行且不影響其它資料的標記。建立高質量註釋管道的第一步是預測常見問題併為其提供解決辦法。

這篇文章展示了文字標註專案中出現的四個最常見的錯誤, 以及如何用像LightTag這樣的文字註釋工具來幫助解決這些錯誤。