慎用!BLEU評價NLP文本輸出質量存在嚴重問題

圖片

策劃|Debra
作者|
譯者|Sambodhi
編輯|

AI 前線導讀:在評價機器翻譯系統時,譯文質量究竟如何,無法通過文本形式的輸出直觀地提現,因此需要採用一些適當的量化標準對機器翻譯的譯文輸出進行評價,這也就催生了幾個評價指標。而 BLEU 是一種流行的機器翻譯評價指標。但是,Rachael 認爲 BLEU 存在的問題比較嚴重,提醒 NLP 從業者要慎用,這究竟是怎麼回事呢?

剛接觸 NLP 的人經常問我的一個問題是,當系統的輸出是文本時,如何對系統進行評價,而不是對輸入文本進行某種分類。這些類型的問題,就是在模型中放入一些文本,然後從中取出一些文本,稱爲序列到序列字符串轉換問題。

這些問題真的很有趣!序列到序列建模的一般任務是 NLP 中一些最困難任務的核心,包括:

  • 文本自動摘要
  • 文本簡化
  • 問答系統
  • 聊天機器人
  • 機器翻譯

這些技術完全源自科幻小說。通過這麼多令人興奮的應用,人們很容易明白爲什麼序列到序列建模比以往更受歡迎。但實際上,對這些系統進行評價並不是一件容易的事情。

然而不幸的是,對剛剛起步 NLP 的人來說,應該使用什麼指標來評價模型,並沒有簡單的答案。更槽糕的是,BLUE—— 用於評價序列到序列任務的最流行的指標之一,存在很大的缺點,特別是在應用於它從未打算評價的任務時,這點尤爲明顯。

幸運的是,你遇到了這篇深度剖析的博文!在本文中,我將探討這個流行的指標的工作原理(別擔心,我不會用太多的方程式)。我們將研究 BLEU 存在的一些問題,最後,我們將探討在自己的工作中,如何最大限度地避免出現這些問題。

image

Orange painted blue on a blue background.(對NLP評價指標而言,這張不是有多引人注目的照片。)

非常棘手的問題

BLEU 最初是爲了評價機器翻譯而開發的,所以讓我們來通過一個翻譯示例來進行測試。這裏有一段文字是用語言 A 寫的(也就是 “法語”):

J’ai mangé trois filberts.

這裏有一段語言 B (也就是“英語”)的參考譯文。(請注意,在英語中,有時也將 “hazelnuts” 稱之爲 “filberts”,因此這些翻譯也堪稱完美。)

I have eaten three hazelnuts.

I ate three filberts.

下面是一段生成的 “神經網絡系統的” 翻譯。(這裏的 “神經” 是 Rachael 自己想出的一種可能的翻譯,但假設這是你正訓練的網絡生成的。)

I ate three hazelnuts.

現在,有一個非常棘手的問題是:我如何爲這段翻譯指定單個數值分數,僅僅根據給定的參考句子和神經系統的輸出,來看這個翻譯究竟有多好?

你爲什麼要用單一的數值分數呢?好問題!如果我們想用機器學習來構建機器翻譯系統的話,我們就需要將一個實數分數來輸入到我們的損失函數中。如果我們也知道潛在的最佳分數,就可以計算兩者之間的差距了。這使得我們能夠在訓練時給我們的系統提供反饋,也就是說,潛在的變化是否會通過分數更接近理想分數來改進翻譯,並通過查看同一任務中訓練過的系統的分數來進行比較。

你可以做的一件事,就是查看輸出句子中的每個單詞,如果它出現在任何參考句子中,就給它打 1 分;如果沒有出現,就打 0 分。然後,爲了使分數歸一化,使其始終在 0~1 之間,可以將參考譯文中出現的單詞數除以輸出句子中的單詞總數。這就爲我們提供了一個叫做一元精度(unigram precision)的衡量方法。

因此,在我們那個例子中,“I ate three hazelnuts”,我們在至少一個參考句子總看到了輸出句子中的所有單詞。再除以輸出的單詞數 4,這段翻譯的分數是 1。到目前爲止還不錯。但是下面這條句子會怎麼樣呢?

Three three three three.

使用同樣的度量標準,我們也會得到 1 分。但是,實際並不太好:我們需要一些方法來告訴我們正訓練的系統,第一條翻譯的句子要比第二條句子更好。

你可以根據每個單詞在任何參考句子中出現的最高次數來限制每個單詞的次數,來略微調整分數。使用這一指標,我們的第一條句子仍然會得到 1 分,而第二條句子的得分只有 0.25 分。

這就解決了 “Three three three three” 的問題,但仍然無助於我們理解像下面這樣的句子,因爲某種原因,這些單子是按字母順序排序的:

Ate hazelnuts I three

如果使用我們目前的方法,這條句子將得到 1 分,也就是最佳分數!我們可以通過計數來避免這種情況,不是使用某個單詞而是通過彼此相鄰的單詞進行計算。這些稱爲 n 元語法(n-gram),其中 n 是每組單詞的數量。一元語法(Unigrams)、二元語法(bigrams)、三元語法(trigrams)和四元語法(4-gram)分別由一個、兩個、三個和四個單詞組成。

在這個例子中,我們使用二元語法。一般來說,BLEU 分數是基於一元、二元、三元和四元精度的平均值,但爲簡單起見,這裏我們只使用二元。同樣爲簡單起見,我們也不會添加一個 “單詞” 來告訴我們在句子的開頭和結尾有一個句子邊界。根據這些指導方針,這些單詞按字母順序排序的二元語法如下:

[Ate hazelnuts]

[hazelnuts I]

[I three]

如果我們使用和用這些二元語法計算單個單詞一樣的方法的話,那我們現在的分數就是 0:最差的分數。我們的那個 “Three three three three” 例子的得分也是 0,而不是 0.25。而第一個例子 “I ate three hazelnuts” 的得分是 1。不幸的是,這個例子也是如此:

I ate.

避免這種情況的一種方法是將我們目前的分數乘以一個懲罰比我們參考譯文短的量值。我們可以通過將它與最接近的參考句子的長度進行比較來實現這一點。這就是對簡短懲罰(brevity penalty)。

如果我們的輸出與任何參考譯文一樣長或者更長,那麼懲罰值就是 1。由於我們將得分乘以它,因此這並不會改變最終的輸出。

另一方面,如果我們的輸出比任何參考譯文都短的話,那麼我們就將最接近的句子的長度除以輸出的長度,從中減去 1,然後取 e 的整次冪。基本上,最短的參考譯文越長,輸出越短,那麼簡短懲罰值就越接近0。

在我們這個 “I ate” 例子中,輸出的句子是兩個單詞長度,最接近的參考譯文有四個單詞的長度。我們就得到了一個 0.36 的懲罰,當我們的二元精度得分爲 1 時,我們的最終得分下降到 0.36。

這種指標着眼於輸出和參考譯文之間的 n-gram 重疊,並以較短的輸出爲懲罰,被稱爲 “BLUE”(即雙語評價基礎研究的縮寫:Bilingual evaluation understudy,人們在解釋縮寫時,就會這麼說)。由 Kishore Papineni、Salim Roukos、Todd Ward 和 Wei-Jing Zhu 於 2002 年在 IBM 提出。它在 NLP 中是非常流行的指標之一,特別是對於系統輸出的文本字符串而不是分類的任務。這包括了機器翻譯、以及越來越多的自然語言生成。這就是我在本文開頭提出的非常困難的問題的解決方案:開發一種方法,爲翻譯分配單個數字分數,告訴我們它有多 “好”。

然而,它也存在嚴重的缺陷。

BLEU 的缺陷

這時候你可能會想,“Rachael,如果這個指標有這麼多缺陷,你爲什麼要要指導我們如何計算呢?” 我之所以這麼做,主要是向你們展示這個指標有多合理。它是相當直觀的,潛在的想法是,你可以通過將機器翻譯系統的輸出與參考譯文進行比較來評價機器翻譯的輸出,這在 NLP 中有極大的影響力(儘管並非沒有批評者)。

當然,BLUE 也有一些優勢。從事 NLP 的研究人員最關心的是它有多方便。

  • BLUE 快速且易於計算,特別是與人工翻譯速率模型輸出相比的話尤爲明顯。
  • BLUE 無處不在,這使你將模型與同一任務的基準進行比較變得更爲輕鬆。

不幸的是,由於這種便利性,人們都在過度使用它,即使對不是最佳指標選擇的任務也是如此。

儘管我的例子只有一句話,但 BLEU 畢竟是一種語料庫級別的指標。計算語料庫中每條句子的 BLEU 分數,然後在他們之間取平均值會人爲地誇大你的分數,如果你嘗試在你所做的地方發表作品,肯定會被評論者的口水淹死。

即使你沒有過度使用 BLEU,在你選擇花時間去計算更好的 BLEU 分數之前,你應該知道這個指標也存在嚴重限制。雖然網上已經有很多關於 BLEU 缺點的討論,但我認爲,它的四個主要問題是:

  • 它不考慮意義
  • 它不直接考慮句子結構
  • 它不能很好地處理形態豐富的語言
  • 它與人類的判斷並不相符

讓我們逐一討論這些缺陷,這樣我就可以告訴你們爲什麼我認爲這些都是缺陷。

BLEU 不考慮意義

對我來說,這是唯一最令人信服的理由:不單單依靠 BLEU 來評價機器翻譯(Machine Translation,MT)系統。作爲機器翻譯的人類用戶,我的主要目標是,能夠準確理解原文的基本含義。主要輸出的句子符合原文的意思,哪怕輸出的句子存在一些怪異的句法或者語法,我也樂意接納。

但是 BLEU 並不衡量意義。它只獎勵參考系統中具有精確匹配的 n-gram 系統。這意味着虛詞的差異(如 “an” 或 “on”)與更重要的實詞的差異受到的懲罰一樣嚴重。這也意味着,如果譯文中,具有完全等效的同義詞,但卻沒有出現在參考譯文的話,那麼將會受到懲罰。

讓我們來看下面的一個例子,你就會明白爲什麼這是一個問題。

原文(法語): J’ai mangé la pomme.

參考譯文: I ate the apple.

如果照 BLEU 來看,這些都是 “同樣槽糕” 的輸出句子:

I consumed the apple.

I ate an apple.

I ate the potato.

作爲機器翻譯系統的最終用戶,實際上我認爲輸出的前兩句沒有什麼問題。即使它們與參考譯文不完全相同,但它們能讓人理解原文的意思。但是,第三句就完全不能接受了,因爲它完全改變了原文的意思。

NIST 是基於 BLEU 的一種指標,它通過對錯誤匹配的 n-gram 的懲罰進行加權來解決這個問題。因此,更爲常見的 n-gram(如 “of the”)的不匹配將會得到更輕的懲罰,而在更罕見的 n-gram(如 “buffalo buffalo”)的不匹配將會受到更嚴重的懲罰。但是,雖然解決了賦予虛詞過多權重的問題,但它實際上卻使懲罰同義詞(如 “ambled” 和 “walked”)的問題變得更槽糕了,因爲這些同義詞只出現在更爲罕見的 n-gram 中,因此受到更嚴重的懲罰。

BLEU 不考慮句子結構

也許你不完全相信 “即使你搞錯了一些關鍵詞,完全改變了句子的意思,也仍然能夠得到相當不錯的 BLEU 分數”。也許有些句法會讓你信服?

句法研究的是句子的結構。正是這個研究領域,我們才能對像 “I saw the dog with the telescope” 這樣的鋸子進行正式建模,這可以意味着兩個意思:我用望遠鏡觀察狗,或者這條狗有望遠鏡。這兩種含義之間的差異,只能通過建模的句子中的單詞之間可以彼此具有不同關係的事實來提現。

我不是世界上最偉大的句法學家(絕對沒有希望),但即使是我也知道在自然語言中有很多重要的內部句法結構,如果你隨意打亂句子中的單詞順序,你要麼會得到這兩種結果中的一個:

1)毫無意義的句子。
2)意思完全不同的句子。

幸運的是,在開發系統來完成對該結構自動建模方面做了大量的工作,這被稱爲句法分析

但不幸的是,BLEU 並沒有建立在任何這項研究的基礎上。我能理解爲什麼你可能想要避免這種情況。因爲解析往往需要很大的算力,並且每次評價的時候,必須解析所有的輸出,這確實會增加一些開銷。(儘管有一些指標,如 STM 或子樹指標,可以直接比較參考和輸出翻譯的解析。)

然而,不考慮句法結構的結果意味着,表面詞序完全混亂的輸出也可以得到與更爲連貫的輸出具有相同的分數。

在 Callison-Burch 等人於 2006 年提出的《Re-evaluating the Role ofBLEUin Machine Translation Research》中有一個很好的例子。我們來看一下這組參考句子:

Orejuela appeared calm as he was led to the American plane which will take him to Miami, Florida.

Orejuela appeared calm while being escorted to the plane that would take him to Miami, Florida.

Orejuela appeared calm as he was being led to the American plane that was to carry him to Miami in Florida.

Orejuela seemed quite calm as he was being led to the American plane that would take him to Miami in Florida.

他們得到了機器翻譯輸出的句子:

Appeared calm when he was taken to the American plane, which will to Miami, Florida.

這翻譯並不完美:因爲人名被刪除了,而且在後半句的 “will” 後面沒有動詞,但這樣的翻譯也不是完全沒有意義。然而,這個例子是:

which will he was, when taken appeared calm to the American plane to Miami, Florida.

出人意料的是,BLEU 居然爲第一個輸出和第二個輸出給出了相同的分數,儘管第一個顯然是更好的英語翻譯。

BLEU 不能很好地處理形態豐富的語言

如果像地球上的大多數人一樣,你碰巧使用的不是英語,那麼你可能已經發現這個指標存在一個問題:BLEU 是基於單次級的匹配。對於形態豐富的語言來說,這很快就會成爲一個問題。

語素是語言中最小的意義單位,它們組合在一次就構成了單詞。英語中有一個例子是,“cats” 中的 “s”,這表示有不止一隻貓。有些語言,比如土耳其語,在一個單詞中就有很多語素;而在其他語言,如英語,每個單詞的語素通常較少。

來看看祕魯語 Shipibo 的以下幾條句子。(這些例子來自 Pilar Valenzuela 的 Shipibo 語的言據性,以及 Panoan 語對該類別的比較概述。)

Jawen jemara ani iki.

Jawen jemaronki ani iki.

上面這兩句話都是英語句子 “her village is large” 的完全可以接受的翻譯。你可能會注意到以 “jemar-” 開頭的單詞在兩條句子中有不同的結尾。不同的詞尾表示不同的語素,表明說話者對於村莊很大的這一事實有多確定:最上面的一條表示他們確實去過那裏,而最下面的一條表示他們從別人那裏聽說村莊很大。

這種特殊類型的語素被稱爲 “證據標記”,而英語中不存在這些。然而,在 Shipibo 語中,你需要這兩個語素中的一個用於句子語法,因此我們的參考譯文肯定會有兩個中的一個。但如果我們沒有碰巧生成我們在參考句子中的單詞的確切形式,那麼 BLEU 就會因此進行懲罰…… 即使這兩條句子都能很好地表達了英語的意思。

BLEU 與人類的判斷不能很好地相符

當我講到語法部分的時候,如果你感到昏昏欲睡,那麼現在是時候提提神了。

構建機器翻譯、聊天機器人或問答系統的最終目標是什麼?你最終希望人們使用這些,對吧?如果這個系統不能提供有用的輸出,誰還會用這些系統呢?因此,你真正想要優化的就是,使用你的系統的人們有多喜歡它。我們使用的幾乎所有指標都被涉及成不同的近似方法。

當 BLEU 首次被提出時,作者確實做了一些行爲測試,以確保這些測量與人類判斷相關(他們這麼做值得鼓勵!)。然而不幸的是,隨着研究人員進行更多的實驗來比較 BLEU 評分和人類的判斷,發現這種相關性並不總是很強,而且根據具體的任務,其他測量結果往往更接近人類的判斷。

例如,在 Turian 等人發表的論文《Evaluation of Machine Translation and its Evaluation》中,他們發現在三種測量中,BLEU 與機器翻譯人類判斷的相關性最差,簡單的 F1 與人類判斷相關性最強,NIST 次之。2006 年,Callison-Burch 等人研究了爲一項共同任務而開發的系統(如學術界的 Kaggle 競賽,但沒有獎金),並發現這些系統的相對排名存在巨大的差異,這取決於你是一句 BLEU 分數還是人類評價者的判斷。在 Yanli Sun 與 2016 年發表的《Mining the Correlation between Human and Automatic Evaluation》中,比較了三種不同的指標:BLEU、GTM 和 TER,並再一次發現 BLEU 分數確實與人類判斷的相關性最小。

換句話說就是:如果你希望人們喜歡使用你的系統,你不應該只關注獲得更高的 BLEU 分數。

我並非唯一持保留意見的人

也許你仍然不相信這一點:BLEU 並不總是適合這項工作的工具。沒關係,事實上,我很欣賞你的懷疑精神!但是,我並不是唯一一個不是這個指標最大粉絲的 NLP 從業者。下面我羅列出了其他同行評審的論文的連接,這些論文更多地討論了 BLEU 的其他一些缺點:

同行評審論文:

  • Reiter(2018)是 ACL 論文的薈萃綜述,該綜述同時使用 BLEU 和人工判斷進行評價,發現它們僅針對機器翻譯系統的系統級綜述進行模式組合。

http://aclweb.org/anthology/J18-3002

  • Sulem 等人(2018)建議不要使用 BLEU 來簡化文本。他們發現,BLEU 分數既不能很好地反映語法,也不能很好地反映保存的意義。

http://aclweb.org/anthology/D18-1081

  • Novicoca 等人(2017)研究表明,在評價 NLG(自然語言生成,Natural Language Generation)任務時,BLEU 以及一些其他常用的指標並不能與人類判斷很好地相符。

https://www.aclweb.org/anthology/D17-1238

  • Ananthakrishnan 等人(2006)對 BLEU 提出了幾個具體的反對意見,並深入探討了 BLEU 評分較高的英語、印地語翻譯中的具體錯誤。

https://core.ac.uk/download/pdf/23798335.pdf

下面羅列了一些未經同行評審的資源:(雖然對於評審研究論文的同行來說,這些資源可能不那麼有說服力,但卻有可能更容易讓你的老闆信服。)

其他資源:

  • Amazon Research 的 Matt Post 就預處理對 BLEU 分數的影響進行了精彩的討論。

https://arxiv.org/pdf/1804.08771.pdf

  • 從事翻譯工作的 Kirti Vashee 撰寫的這篇博文,從譯者的角度討論了 BLEU 的問題。

http://kv-emptypages.blogspot.com/2010/03/problems-with-bleu-and-new-translation.html

  • Yoav Goldberg 在 2018 年的國際自然語言生成會議上做了一場很棒的演講,其中討論了爲什麼不應該將 BLEU 用於 NLG。你可以在下面網址找到相關的 PPT(以 “BLEU can be Misleading” 爲搜索關鍵詞可搜到相關 PPT)。特別是,他和合著者發現,他們的句子簡化模型即使通過添加、刪除或重複信息也能得到很高的 BLEU 分數

https://inlg2018.uvt.nl/wp-content/uploads/2018/11/INLG2018-YoavGoldberg.pdf

  • Ana Marasović撰寫的博文《NLP’s generalization problem, and how researchers are tackling it》,討論了包括 BLEU 在內的各個指標如何無法捕獲模型處理不同於它們在訓練期間所接觸的數據的能力。

https://thegradient.pub/frontiers-of-generalization-in-natural-language-processing/

那麼你應該用什麼呢?

在評價將文本作爲輸出的系統時,我希望你使用的主要方法是謹慎,特別是在構建最終可能投入生產的系統時。對於 NLP 從業者來說,考慮我們的工作將如何應用,以及可能出現的錯誤是非常重要的。想想這名巴勒斯坦人吧,他之所以被捕,是因爲 Facebook 把他的一篇內容爲 “早安” 的帖子翻譯成了 “攻擊他們”!我並非對 Facebook 雞蛋裏挑骨頭,而是想指出 NLP 產品的風險可能比我們有時意識到的還要高。

仔細地挑選我們優化的指標是確保我們所使用的系統實際可用的重要部分。例如,對於像機器翻譯這樣的任務,我個人認爲,懲罰意義上的重大改變非常重要。

也就是說,有很多自動評價指標可以取代 BLEU。其中一些可以更好地完成不同的任務,所以花點時間來評價哪些指標最適合你的特定項目是值得的。

有兩種流行的方法實際上是 BLEU 的衍生物,旨在幫助解決它的一些缺點:

  • NIST。正如我上面所提到的,NIST 是根據稀有性對 n-gram 進行加權。這意味着正確匹配罕見的 n-gram 比正確匹配一個常見的 n-gram 更能提高分數。

  • ROUGE。它是 BLEU 的一種改進,側重於召回率而不是精確率。換句話就是,它關注的是參考譯文中有多少 n-gram 出現在輸出中,而不是相反。

還有很多方法可以用來評價不基於 BLEU 的序列到序列模型。其中有一些是從機器學習的 NLP 的其他領域採取的措施。

  • 困惑度(Perplexity)是信息論中的一種指標,更常用於語言建模。它衡量單詞的學習概率分佈於輸入文本的概率分佈的匹配程度。

  • 詞錯率(Word error rate,WER)是語音識別中常用的指標。它衡量的是在給定參考輸入的情況下,輸出序列中的替換(比如 “an” 替換爲 “the”)、刪除和插入的數量。

  • F-score,也就是通常所說的簡短懲罰,是精確率的平均值(有多少預測是正確的)和召回率(有多少可能正確的預測是對的)的平均值。

還有一些是專門爲序列到序列的任務開發的。

  • STM,或子樹指標(我在前面已提及)比較了參考和輸出翻譯的解析,並懲罰具有不同句法結構的輸出。

  • METEOR,類似於 BLEU,但包含了其他步驟,如考慮同義詞和比較單詞的詞幹(這樣 “running” 和 “run” 視爲相匹配)。與 BLEU 不同的是,它明確用於比較句子而不是語料庫。

  • TER(Translation error rate),即翻譯錯誤率,衡量將原始輸出翻譯成可接受的人工翻譯所需的編輯次數。

  • TERp,或成 TER-plus,是 TER 的擴展,它還考慮了釋義、詞幹和同義詞。

  • hLEPOR,一種更適用於土耳其語或捷克語等形態更爲複雜的語言的指標。除卻其他因素之外,它還考慮了詞性(名詞、動詞等)等有助於捕獲局發信息。

  • RIBES,與 hLEPOR 一樣,它不依賴於與英語具有相同品質的語言,其設計初衷是爲亞洲語言(如漢語和日語)提供更豐富的信息,而且不受單詞邊界的限制。

  • MEWR,可能是列表中最新的指標,我發現它最讓人興奮的一點是:它不需要參考翻譯!(這對於資源不足的語言來說是喜大普奔的好事,因爲這些語言可能沒有大量的平行語料庫。)它結合了單詞和句子的嵌入(瀑布哦・捕獲意義的某些方面)和困惑度爲翻譯進行評分。

那你的意思是,這玩意兒很複雜?

這幾乎就是問題的核心了。要知道,語言是很複雜的,這就意味着衡量語言自動化是很難的事情。我個人認爲,開發自然語言生成的評價指標目前可能是 NLP 中最難的問題。(如果你跟我一樣感興趣的話,在 2019 年的 NAACL 上將會有一場關於這個問題的研討會,來參加吧!)

不過,有一種很好的方法可以確保你的系統在做人類喜歡的事情上變得更好:你可以向人們諮詢他們的想法。人類評價曾經是機器翻譯的標準,我認爲它在今天仍然有一席之地。是的,它挺貴的,而且花費的時間還挺長。但是至少對即將投入生產的系統,我認爲你應該和人類專家進行至少一輪的系統評價。

需要提醒的是,在進入這一輪由人類專家進行的系統評價之前,你可能需要使用至少一個自動評價指標。我會強烈建議你們在當且僅當以下這種情況使用 BLEU

  1. 你正進行機器翻譯,並且
  2. 你正在對整個語料庫進行評價,以及
  3. 你知道指標存在侷限性,並已準備好接受它們。

否則的話,你還是多花點時間去找尋一個更適合你特定問題的指標吧。

原文鏈接:
https://towardsdatascience.com/evaluating-text-output-in-nlp-bleu-at-your-own-risk-e8609665a213

更多內容,請關注AI前線

image

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章