BLEU, METEOR, ROUGE 一般在机器翻译里用，CIDEr 一般在图像字幕生成里用

BLEU

所谓BLEU，最开始是用于机器翻译中。他的思想其实很native，对于一个给定的句子，有标准译文S1，还有一个神经网络翻译的句子S2。BLEU的思想就是对于出现机器翻译S2的所有短语，看有多少个短语出现在S1中，然后算一下这个比率就是BLEU的分数了(类似precision)。首先根据n-gram划分一个短语包含单词的数量，有BLEU-1,BLEU-2,BLEU-3,BLEU-4。分别就是把文章划分成长度为1个单词的短语，长度为2个单词的短语…然后统计这些短语出现在标准译文中个数，在分别除以划分总数，就是对应的BLEU-1分数，BLEU-2分数…，其实就是准确率。看这些划分的短语中有多少是出现在标准译文当中的。一般而言：unigram 的准确率可以用于衡量单词翻译的准确性，更高阶的 n-gram 的准确率可以用来衡量句子的流畅性 n{1,2,3,4}

但是BLEU会有个缺陷，假如我就翻译一个单词，而这个单词正好在标准译文中(译文特别短)，那岂不是准确率100%，对于这个缺陷，BLEU算法会有个长度惩罚因子，就是翻译太短了就会有惩罚。还有一个缺陷就是BLUE score没有考虑译文中单词的顺序。

代码层面具体怎么使用建议看：https://zhuanlan.zhihu.com/p/404381278

METOR

其大意是说有时候翻译模型翻译的结果是对的，只是碰巧跟参考译文没对上（比如用了一个同义词），于是用 WordNet 等知识源扩充了一下同义词集，同时考虑了单词的词形（词干相同的词也认为是部分匹配的，也应该给予一定的奖励，比如说把 likes 翻译成了 like 总比翻译成别的乱七八糟的词要好吧？）在评价句子流畅性的时候，用了 chunk 的概念（候选译文和参考译文能够对齐的、空间排列上连续的单词形成一个 chunk，这个对齐算法是一个有点复杂的启发式 beam serach），chunk 的数目越少意味着每个 chunk 的平均长度越长，也就是说候选译文和参考译文的语序越一致。最后还有召回率和准确率两者都要考虑，用 F 值作为最后的评价指标。

METEOR 的缺点也很明显，其一是只有 Java 实现，而且还是 jar 包不是 API，只能算整个测试集上的 METEOR 而不是每条语句单独测（除非你把每条语句单独写到文件里然后调 jar 包），实在是太蠢了。在 Python 统治深度学习的当下，可想而知很少有人用这个指标……

ROUGH

ROUGE算法基本思路和BLEU差不多，不过它统计的是召回率，也就是对于标准译文中的短语，统计一下它们有多少个出现在机器翻译的译文当中(刚好和BLUE反过来)，其实就是看机器翻译有多少个翻译对了，这个评价指标主要在于标准译文中的短语都出现过，那么自然机器翻译的译文越长结果越好。

CIDEr

常用语图像字幕生成，CIDEr 是 BLEU 和向量空间模型的结合。它把每个句子看成文档，然后计算 TF-IDF 向量（只不过 term 是 n-gram 而不是单词）的余弦夹角，据此得到候选句子和参考句子的相似度，同样是不同长度的 n-gram 相似度取平均得到最终结果。优点是不同的 n-gram 随着 TF-IDF 的不同而有不同的权重，因为整个语料里更常见的 n-gram 包含了更小的信息量。图像字幕生成评价的要点是看模型有没有抓取到关键信息，比如说一幅图的内容是『白天一个人在游泳池游泳』，其中最关键的信息应该是『游泳』，生成字幕时如果包含或者漏掉了一些别的信息（比如说『白天』）其实是无关紧要的，所以需要这么一种对非关键词降权的操作。