【NLG】(二)文本生成评价指标—— METEOR原理及代码示例

前奏：

【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