NLP輸出文本評估：使用BLEU需要承擔哪些風險？
譯者| 大魚
責編 | 琥珀
出品 | AI科技大本營（公眾號ID：rgznai100）
怎樣評價輸出為文本的系統？
剛接觸 NLP 時常有個疑問，就是如何評估這樣一個系統——其輸出為文本，而非對輸入分類。當把一些文本輸入系統，得到的輸出也為文本時，這類問題稱為 seq2seq 或字元串轉導（string transduction）問題。
NLP 的核心就是 seq2seq 建模，這些任務包括：
文本摘要
文本簡化
問答
聊天機器人
機器翻譯
想想該技術將具有多麼激動人心的實際應用，也使得 seq2seq 模型越來越受到研究者的歡迎。實際上，評估這些系統並非易事。
遺憾的是，對於剛入門學習 NLP 的人來說，評估模型應使用什麼指標並沒有標準答案。更糟糕的是，當前用來評估 seq2seq 任務的最流行的指標之一 BLEU，也存在很明顯的缺點，尤其是將其應用於從未做評估準備的任務時。
在本文中，Kaggle 的一位數據科學家 Rachael Tatman 會逐步介紹這個當前流行標準的原理，包括 BLEU 存在的問題，以及如何在工作中最大限度地減少這些問題。
一個棘手的問題
最初，BLEU 是為了評估機器翻譯而開發的指標，所以我們來看一個翻譯的例子。下面是語言 A（法語）：
J』ai mangé trois filberts.
這裡有一些語言 B（英語）的參考譯文：
I have eaten three hazelnuts.
I ate three filberts.
（我吃了三顆榛子。）
此處是一個生成的「神經系統的」翻譯。（在這種情況下，「神經系統的」是「用大腦想出來的一種可能的翻譯」，但假裝這是由你訓練的網路生成的。）
I ate three hazelnuts.
現在面臨著一個很棘手的問題：我應該如何給一段翻譯進行打分？僅僅基於參考譯句和神經輸出，來告訴大家這段翻譯有多好？
為什麼我們需要一個單獨的分值？好問題！如果我們想用機器學習來建立機器翻譯系統，我們需要一個單獨的實數作為分數來填入我們的損失函數。如果我們知道可能的最高得分，我們就可以計算兩者的差。這樣我們就可以在系統的訓練過程中，為其提供反饋，也就是提供一種可能的改變來提升翻譯質量，使分數越來越接近目標分數，觀察它們在同一個任務上的分數表現，將所訓練的系統進行對比。
你可能需要做一件事，那就是查看輸出語句中的每個單詞。如果該單詞在參考譯句中出現了，就為其分配 1，否則分配 0。接下來，你需要將其標準化，保證它的值在 0 和 1 之間，你可以用翻譯出的語句的單詞個數去除輸出語句的單詞總數。這樣就為我們提供了一種叫做 unigram 的測量指標。
因此，關於我們的例子 「I ate three hazelnuts」，我們在至少一個參考譯句中看到了輸出語句中的所有單詞。用它除以輸出單詞的總數目 4，你最終會得到的分數為 1。到目前為止都很順利！但下面這句話呢？
Three three three three.
使用相同的指標，我們也可以得到 1 分。這樣不是很好：我們需要通過一些方法告訴系統，我們正在訓練的第一個句子（的翻譯結果）要比第二個句子好。
你可以根據任何參考譯句中出現的最高次數，來計算每個單詞的計數次數，從而對分數進行微調。基於該度量單位，我們的第一個語句仍可以得到 1 分，然而第二句只能拿到 0.25 分。
這幫我們解決了 「three three three three」 的問題，但無法處理像下面這樣的句子，由於某種原因，這些單詞是按字母順序排列的：
Ate hazelnuts I three
使用我們當前的方法，這句話可以得到 1 分，也就是最高分！我們可以對相鄰單詞進行計數，而不是僅僅對單個詞計數。Unigrams、bigrams、trigrams 以及 4-grams 分別由一個、兩個、三個、四個單詞塊組成。
對於當前這個例子，我們使用 bigrams。一般來說，BLEU 分數是基於 unigram、bigram、trigram 和 4-gram 精度的平均值，但為了簡單起見，我們在這裡只用 bigram。同樣為了簡單起見，我們不會添加單詞來告訴我們句子開頭和結尾的邊界。帶著這些規則，按字母順序排列的單詞中的 bigram 如下：
[Ate hazelnuts]
[hazelnuts I]
[I three]
如果我們使用同樣的計算方式，那麼得到的分數為 0，也就是最壞的分數。我們的 「three three three three」 例句得到了 0 分，而不是 0.25 分，但最初的例句 「I ate three hazelnuts」 可以得到 1 分。不幸的是，下面這個例子也如此：
I ate.
解決這個問題的方法是，將我們迄今為止的分數乘以一個用來對語句做懲罰的指標。我們可以通過將它與長度最接近的參考語句的長度進行比較來實現，這就是懲罰因子。
如果我們的輸出等於或長於任何參考語句，則懲罰分為 1。由於我們對分數做了乘法，這不會改變最終的輸出。
另一方面，如果我們的輸出比所有參考語句都短，我們要將最接近的句子長度除以輸出的長度，從中減去一個，並將 e 提升到整個系統的水平。一般來說，最短參考語句越短，輸出就越短，BP 值越接近零。
在 「I ate」 例子中，輸出語句為兩個單詞的長度，最接近的參考語句有四個詞長度。這給了我們 0.36 的懲罰因子，當我們的 bi-gram 精度得分為 1 時，我們將最終得分降到了 0.36。
這種考慮 n 個單詞在輸出和翻譯語句間重合率的評估指標叫作 BLEU，是由 IBM 的 Kishore Papineni、Salim Roukos、Todd Ward 和 Wei-Jing Zhu 於 2002 年開發出來的。它在 NLP 中是一個非常流行的指標，尤其對於系統輸出為文本字元串而非分類的任務，包括機器翻譯和自然語言生成。這就是我在開篇提出的問題的一種解決方案：開發一種方法，為翻譯結果分配單獨的分數，從而告訴我們這句翻譯有多「好」。
同時它也存在嚴重的缺陷。
BLEU 存在的幾個問題
到了這裡，你可能存在疑問，「如果該指標存在缺陷，為什麼你要給我們介紹如何計算它呢？」 目的是為了向大家展示這項指標有多麼合理。它是相當直觀的，你可以通過將機器翻譯系統的輸出結果與參考翻譯進行對比，來評估機器翻譯系統的輸出，這在 NLP 中具有極大的影響力。
BLEU 當然也有許多優點：
它的易於計算且速度快，特別是與人工翻譯模型的輸出對比；
它應用範圍廣泛，這可以讓你很輕鬆將模型與相同任務的基準作對比。
遺憾的是，這種便利導致人們的過度使用，甚至有些情況下該指標不是最佳選擇。
即便 BLEU 沒有被過度使用，在你花時間並計算以追求更高的 BLEU 分數前，你也應該知道該度量標準存在的嚴重缺陷。已經存在很多關於 BLEU 缺陷的討論，我認為它存在的四大問題是：
它不考慮語義
它沒有直接考慮句子結構
它不能很好地處理形態豐富的語句
它無法很好地映射出人類的判斷
讓我們逐一討論這些問題，這樣我就可以告訴你們我做出該判斷的原因。
BLEU 不考慮語義
對我而言，這是這是讓我們不能僅靠 BLEU 來評估機器翻譯系統唯一最令人信服的理由。作為機器翻譯系統的人類用戶，我的主要目標是準確理解源語言中文本的潛在含義。只要它符合源文的意思，我就可以欣然接受輸出語句中句法和語法上存在的一些怪異之處。
BLEU 卻不考慮語義。它只給那些與參考系統完全匹配的 n元（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.
作為機器翻譯系統的終端用戶，我可以接受前兩個句子。雖然它們和參考翻譯不完全相同，但它們理解的意思是對的。然而，第三句是完全無法接受的，它完全改變了原文的意思。
基於 BLEU 的指標之一的 NIST，通過給匹配錯誤的 n 元模型進行加權懲罰來解決這一問題。因此，一些常見的片語（如 of the）得到的懲罰會比較小，但一些罕見的詞（如 buffalo buffalo）就會高一些。
BLEU 不考慮句子結構
也許你不相信，即使你弄亂一些關鍵詞，導致完全改變了句子的意思，你仍然可以得到很好的 BLEU 分數。
我不是偉大的語法學家，但我知道在自然語言中存在很多重要的內部語法結構，如果你打亂句子中的單詞順序，你可能會得到一堆毫無意義的單詞或具有完全不同含義的語句。
幸運的是，在開發系統以完成對結構的自動化建模的過程中可以採取一些措施，這個系統被稱為句法分析（parsing）。
不幸的是，BLEU 沒有涉及任何基於這方面的研究。我可以理解你為什麼想逃避這塊，因為句法分析往往需要密集的計算，並且每次評估時必須將所有輸出進行句法分析，這就增加了一定的負擔。
然而，不關注結果的語法結構意味著：一些結構混亂的輸出可以獲得與那些連貫語句相同的分數。
BLEU 不能很好地處理形態豐富的語句
如地球上大多數人一樣，如果碰巧你使用的語言不是英語，那麼你可能已經發現這項指標存在的問題：它是基於單詞進行匹配的。對於那些具有豐富形態的語言，問題很快就會浮現。
看下面這句話，這是一種秘魯使用的語言 Shipibo：
Jawen jemara ani iki.
Jawen jemaronki ani iki.
這兩句話的意思都是「her village is large.」（她的村莊很大）。你可能注意到了中間的兩個詞，都以「jemar-」開頭，但在兩句話中有不同的結尾。不同的結尾是不同的語素，表示說話者對於村莊很大這件事的肯定程度；第一句話表示他們已經去過那裡了，第二句表示他們是從別人那裡聽說了這件事。
這種特殊類型的語素被稱為「證據標記」（evidentiality marker），英語中沒有這類語素。但在 Shipibo 語言中，出於語法需要，你需要使用其中一個語素，所以我們的參考翻譯肯定有其中之一。但如果我們碰巧沒有生成參考語句中所用單詞的確切形式，BLEU 就會對其進行懲罰……即使兩句話都很好地捕捉到了英文的含義。
BLEU 沒有很好地映射出人類的判斷
創建機器翻譯、聊天機器人以及問答系統的最終目的是什麼？你最終希望人們使用它，對嗎？如果一個系統無法給出有用的輸出，人們是不會使用它的。所以你需要做出的優化是，讓使用系統的人喜歡這個系統。
當 BLEU 被首次提出時，作者確實做了一些行為測試，來確保該測量指標與人類的判斷相關。然而，當研究者們做了更多比較 BLEU 評分和人類判斷的實驗後，他們發現這種相關性並不總是很強烈，當評估不同任務時，其他測量指標往往與人類判斷的關係更為密切。
還有哪些標準可以應用呢？
當你在評估一個以文本作為輸出的系統時，最重要的事就是保持謹慎，特別是在構建可能投入生產的內容時。對 NLP 從業者來說，考慮我們所做工作的應用場景尤為重要。考慮一下那名被捕的中東男子，只是因為 Facebook 把一句「早上好」翻譯成了「攻擊他們」！我不是針對 Facebook，我只是想指出 NLP 產品的風險可能比我們想像的要高。
為了確保我們所使用的系統切實可用，謹慎選擇優化指標是極其重要的環節。舉個例子，對於機器翻譯任務，我個人認為對語義變化大的地方做出懲罰十分重要。
也就是說，還有很多自動評估指標可以替代 BLEU。其中一些可以針對不同的任務表現更好，因此我們值得花一些時間來為項目選擇最合適的評估指標。
實際上，目前有兩種流行的方法都是由 BLEU 推導而來，旨在消除它的缺陷：
NIST，根據罕見度對 n 元模型進行加權。這意味著相比起正確匹配一個常見的 n 元模型，正確匹配一個罕見的 n 元模型更容易提高你的分數。
ROUGE，BLEU 的改進版，專註於召回率而非精度。換句話說，它會查看有多少個參考譯句中的 n 元片語出現在了輸出之中。
你還可以選擇很多方法，它們都是基於 BLEU 的，其中一些源自機器學習以外的 NLP 的其他細分領域：
Perplexity，是一項基於資訊理論的指標，更多用於語言建模。它可以測量單詞的學習概率分布與輸入文本概率分布的匹配程度。
單詞錯誤率（即 WER），是一項常用於語音識別的度量指標。給定一個參考輸入，它會測量輸出序列中的替換（如 an 替換 the）、刪除及插入次數。
F-score，通常也被稱為 F1，是精度（有多少預測是正確的）和召回率（做出了多少可能正確的預測）的平均值。
還有一些專門為 seq2seq 任務開發的指標：
STM（即子樹匹配/subtree metric），對參考譯句和輸出翻譯的解析進行對比，並基於不同的句法結構對輸出做出懲罰。
METEOR，與 BLEU 類似，但增加了額外的步驟，如考慮同義詞和比較單詞的詞幹（這樣 running 和 runs 就會被認作匹配）。與 BLEU 不同，它被明確設計為用於比較句子而非語料庫。
TER（即翻譯錯誤率），測量了將原始輸出轉變成可接受的人類水平的翻譯所需的編輯次數。
TERp（即 TER-plus），是 TER 的擴展，它也同樣考慮了釋義、詞幹和同義詞。
hLEPOR，是一種旨在更好地適用於形態複雜語種（如土耳其語或捷克語）的度量指標。它還考慮了諸如詞性（名詞、動詞等）之類的因素，來幫助捕獲語法信息。
RIBES，與 hLEPOR 類似，它不只用於類似英語的語種。它旨在為亞洲語言提供更多信息，如日語和中文。
MEWR，可能是該列表中最新的評價標準，最令人興奮的一點是：該指標不需要參考翻譯！（這對那些資源匱乏的語種來說非常友好，因為這些語種沒有龐大的平行語料庫。）
當然，我沒有足夠的篇幅來介紹所有的自動化指標。您可以在評論中說出你最喜歡的指標，最好順便解釋一下為什麼喜歡它！
你現在一定在想……這太複雜了！
這正是問題的核心。語言很複雜，也就意味著自動評估語言很困難。我個人認為，開發自然語言生成的評估指標可能是 NLP 中最難的問題。
也就是說，有一種很好的方法可以確保你的系統所做的事情被人類認可：你可以親自問人們的想法。人工評估曾經是機器翻譯的標準，我認為這個方法還有一席之地。是的，這個方法耗費的精力不小，而且需要花更多的時間。但至少對於投入生產的系統來說，我認為你應該讓人類專家做至少一輪系統評估。
但在此之前，你可能需要使用至少一個自動評估指標。當滿足以下幾個條件時，我會推薦你使用 BLEU：
你在做機器翻譯；
你在評估整個語料庫；
你知道度量指標的局限性，並且已經準備好接受這些問題。
否則，我建議你另外找一個適合你特定問題的指標。
TAG:AI科技大本營 |