技術標籤：評價指標自然語言生成

前奏：

【NLG】(一)文字生成評價指標——BLEU原理及程式碼示例

1.METEOR原理

2004年，卡內基梅隆大學的Lavir提出評價指標中召回率的意義，基於此研究，Banerjee和Lavie（Banerjee and Lavie, 2005）發明了基於單精度的加權調和平均數和單字召回率的METEOR度量方法，目的是解決BLEU標準中的一些固有缺陷。簡單說，該指標考慮了基於整個語料庫上的準確率和召回率，而最終得出測度。

METEOR擴充套件了BLEU有關“共現”的概念，提出了三個統計共現次數的模組：

• 一是“絕對”模組（"exact" module），即統計待測譯文與參考譯文中絕對一致單詞的共現次數；
• 二是“波特詞幹”模組（porter stem module），即基於波特詞幹演算法計算待測譯文與參考譯文中詞幹相同的詞語“變體”的共現次數，如happy和happiness將在此模組中被認定為共現詞；
• 三是“WN同義詞”模組（WN synonymy module），即基於WordNet詞典匹配待測譯文與參考譯文中的同義詞，計入共現次數，如sunlight與sunshine。

同時METEOR將詞序納入評估範疇，設立基於詞序變化的罰分機制，當待測譯文詞序與參考譯文不同時，進行適當的罰分。最終基於共現次數計算準確率、召回率與F值，並考慮罰分最終得到待測譯文的METEOR值。

該演算法首先計算 unigram 情況下的準確率P和召回率R（計算方式與BLEU、ROUGE類似），得到調和均值F值：

Meteor的特別之處在於，它不希望生成很“碎”的譯文：比如參考譯文是“A B C D”，模型給出的譯文是“B A D C”，雖然每個unigram都對應上了，但是會受到很嚴重的懲罰。懲罰因子的計算方式為：

在評價句子流暢性的時候，用了 chunk 的概念（候選譯文和參考譯文能夠對齊的、空間排列上連續的單詞形成一個 chunk，這個對齊演算法是一個有點複雜的啟發式 beam serach），chunk 的數目越少意味著每個 chunk 的平均長度越長，也就是說候選譯文和參考譯文的語序越一致。unigrams_matched表示匹配上的unigram個數。

最後，METEOR計算為對應最佳候選譯文和參考譯文之間的準確率和召回率的調和平均：

用於機器翻譯評測時，通常取afa=3，γ=0.5，sita=3.

2.優缺點

優點：

• 考慮了基於整個語料庫上的準確率和召回率
• 考慮了句子流暢性
• 考慮同義詞對語義的影響

缺點：

• BLEU和METEOR對於長度是比較敏感的.

3.如何算METEOR

這個指標的計算仍然採用nltk工具包自帶的功能函式。

一 安裝nltk

pip install nltk

二資料形式：

這裡的輸入資料，要求按字分開。模仿英文狀態下的輸入形式，我們知道，英文每個單詞之間會有空格兒做分割，而我們漢字是沒有的，所以對句子做一些簡單處理：給字之間加上空格兒。

程式碼demo：

from nltk.translate.meteor_score import meteor_score

reference3 = '我 說 這 是 怎 麼 回 事，原 來 明 天 要 放 假 了'
reference2 = '我 說 這 是 怎 麼 回 事'
hypothesis2 = '我 說 這 是 啥 呢 我 說 這 是 啥 呢'
# reference3：參考譯文
# hypothesis2：生成的文字
res = round(meteor_score([reference3, reference2], hypothesis2), 4)
print(res)

輸出：
0.4725

參考：

1.論文：http://www.cs.cmu.edu/~alavie/METEOR/pdf/Banerjee-Lavie-2005-METEOR.pdf

2.meteor的來源：https://zhuanlan.zhihu.com/p/100942429