项目地址:http://www.cs.cmu.edu/~alavie/METEOR/
代码地址(非官方实现,实现的是项目地址中的1.5版本):https://github.com/tylin/coco-caption
项目由CMU提供,项目地址包含了代码和最新版本以及之前老版本的meteor评价算法。
下面记录一下最初版也就是《The Meteor Metri for Automatic Evaluation of Machine Translation》的计算思路。
首先说明一下常用的BLEU的缺点,BLEU评价方法的缺点有如下几点:
- 没有采用recall指标,虽然引入了brevity penalty因子来约束生成句子的长度,但是还是没法弥补缺失recall的缺陷
- 使用高阶的n元组(即采用较大的n)来判断句子的语法和流畅性。文章猜想,只要采用合适的匹配方式,只使用unigram也可以很好的体现句子语法和流畅性。
- 采用n元组的几何平均数来计算。几何平均数中只要有一个值为0,那么结果就为0,所以这种计算方式不太可靠。
文章从常用的BLEU评价指标入手,解决BLEU的缺点。
一、Meteor的单词匹配规则
文章简单的将hypothesis和reference translation进行单词与单词之间的匹配,如果reference存在多个,那么就取匹配结果最好的那个。
对于Meteor的匹配,文章有下面几个规则说明:
1. 如果单词与单词完全相同,那么两个单词就是匹配上了
2. 如果两个单词的词根(即不包含时态和单复数情况)相同,那么两个单词就算匹配上了
3. 如果两个单词是同义词(对于英语来说,同义词有WordNet提供),那么两个单词就算匹配上了
匹配过程中,一个单词最多与另一个单词匹配,不能同时匹配两个单词。如果匹配过程中存在多种匹配结果,那么选择匹配图中交叉数较少的那个。拿wiki上的例子来说,如下图所示:
METEOR-alignment-a.png METEOR-alignment-b.png可以看出结果是选择交叉数较小的那个,即上面那个匹配结果。
由于匹配与否有三个规则来判断,且匹配过程中已匹配的单词不能与其他单词进行匹配,所以匹配规则的执行是有顺序的,文章就是采用上述的1,2,3的顺序执行的,即先匹配完全相同的单词,然后是词根相同的,最后是同义词。
二、Meteor的计算方式
定义m为hypothesis和reference匹配到的总对数,hypothesis的长度为t,reference的长度为r,那么准确率计算方式为,召回率计算方式为,F值的计算方式为。
上式中只利用了单词之间的匹配,为了考虑到词与词之间的顺序,文章引入了fragmentation penalty。如果两句子中,互相匹配的单词都是相邻的,那么它们就定义为同一块(chunk),计算总的块的个数ch。将frag定义为。那么fragmentation penalty定义为。
值为惩罚的力度,是一个超参数,取值范围为。也是一个超参数。
最终的Meteor计算方式为:
wiki列举了几个计算的例子,如下图所示
3.png
对于一个数据集的Meteor的计算,上述的是从所有的测试数据统计得到的。
网友评论