策划|Debra
作者|
译者|Sambodhi
编辑|

AI 前线导读：在评价机器翻译系统时，译文质量究竟如何，无法通过文本形式的输出直观地提现，因此需要采用一些适当的量化标准对机器翻译的译文输出进行评价，这也就催生了几个评价指标。而 BLEU 是一种流行的机器翻译评价指标。但是，Rachael 认为 BLEU 存在的问题比较严重，提醒 NLP 从业者要慎用，这究竟是怎么回事呢？

刚接触 NLP 的人经常问我的一个问题是，当系统的输出是文本时，如何对系统进行评价，而不是对输入文本进行某种分类。这些类型的问题，就是在模型中放入一些文本，然后从中取出一些文本，称为序列到序列或字符串转换问题。

这些问题真的很有趣！序列到序列建模的一般任务是 NLP 中一些最困难任务的核心，包括：

文本自动摘要
文本简化
问答系统
聊天机器人
机器翻译

这些技术完全源自科幻小说。通过这么多令人兴奋的应用，人们很容易明白为什么序列到序列建模比以往更受欢迎。但实际上，对这些系统进行评价并不是一件容易的事情。

然而不幸的是，对刚刚起步 NLP 的人来说，应该使用什么指标来评价模型，并没有简单的答案。更槽糕的是，BLUE—— 用于评价序列到序列任务的最流行的指标之一，存在很大的缺点，特别是在应用于它从未打算评价的任务时，这点尤为明显。

幸运的是，你遇到了这篇深度剖析的博文！在本文中，我将探讨这个流行的指标的工作原理（别担心，我不会用太多的方程式）。我们将研究 BLEU 存在的一些问题，最后，我们将探讨在自己的工作中，如何最大限度地避免出现这些问题。

Orange painted blue on a blue background.（对NLP评价指标而言，这张不是有多引人注目的照片。）

非常棘手的问题

BLEU 最初是为了评价机器翻译而开发的，所以让我们来通过一个翻译示例来进行测试。这里有一段文字是用语言 A 写的（也就是 “法语”）：

J’ai mangé trois filberts.

这里有一段语言 B （也就是“英语”）的参考译文。（请注意，在英语中，有时也将 “hazelnuts” 称之为 “filberts”，因此这些翻译也堪称完美。）

I have eaten three hazelnuts.

I ate three filberts.

下面是一段生成的 “神经网络系统的” 翻译。（这里的 “神经” 是 Rachael 自己想出的一种可能的翻译，但假设这是你正训练的网络生成的。）

I ate three hazelnuts.

现在，有一个非常棘手的问题是：我如何为这段翻译指定单个数值分数，仅仅根据给定的参考句子和神经系统的输出，来看这个翻译究竟有多好？

你为什么要用单一的数值分数呢？好问题！如果我们想用机器学习来构建机器翻译系统的话，我们就需要将一个实数分数来输入到我们的损失函数中。如果我们也知道潜在的最佳分数，就可以计算两者之间的差距了。这使得我们能够在训练时给我们的系统提供反馈，也就是说，潜在的变化是否会通过分数更接近理想分数来改进翻译，并通过查看同一任务中训练过的系统的分数来进行比较。

你可以做的一件事，就是查看输出句子中的每个单词，如果它出现在任何参考句子中，就给它打 1 分；如果没有出现，就打 0 分。然后，为了使分数归一化，使其始终在 0~1 之间，可以将参考译文中出现的单词数除以输出句子中的单词总数。这就为我们提供了一个叫做一元精度（unigram precision）的衡量方法。

因此，在我们那个例子中，“I ate three hazelnuts”，我们在至少一个参考句子总看到了输出句子中的所有单词。再除以输出的单词数 4，这段翻译的分数是 1。到目前为止还不错。但是下面这条句子会怎么样呢？

Three three three three.

使用同样的度量标准，我们也会得到 1 分。但是，实际并不太好：我们需要一些方法来告诉我们正训练的系统，第一条翻译的句子要比第二条句子更好。

你可以根据每个单词在任何参考句子中出现的最高次数来限制每个单词的次数，来略微调整分数。使用这一指标，我们的第一条句子仍然会得到 1 分，而第二条句子的得分只有 0.25 分。

这就解决了 “Three three three three” 的问题，但仍然无助于我们理解像下面这样的句子，因为某种原因，这些单子是按字母顺序排序的：

Ate hazelnuts I three

如果使用我们目前的方法，这条句子将得到 1 分，也就是最佳分数！我们可以通过计数来避免这种情况，不是使用某个单词而是通过彼此相邻的单词进行计算。这些称为 n 元语法（n-gram），其中 n 是每组单词的数量。一元语法（Unigrams）、二元语法（bigrams）、三元语法（trigrams）和四元语法（4-gram）分别由一个、两个、三个和四个单词组成。

在这个例子中，我们使用二元语法。一般来说，BLEU 分数是基于一元、二元、三元和四元精度的平均值，但为简单起见，这里我们只使用二元。同样为简单起见，我们也不会添加一个 “单词” 来告诉我们在句子的开头和结尾有一个句子边界。根据这些指导方针，这些单词按字母顺序排序的二元语法如下：

[Ate hazelnuts]

[hazelnuts I]

[I three]

如果我们使用和用这些二元语法计算单个单词一样的方法的话，那我们现在的分数就是 0：最差的分数。我们的那个 “Three three three three” 例子的得分也是 0，而不是 0.25。而第一个例子 “I ate three hazelnuts” 的得分是 1。不幸的是，这个例子也是如此：

I ate.

避免这种情况的一种方法是将我们目前的分数乘以一个惩罚比我们参考译文短的量值。我们可以通过将它与最接近的参考句子的长度进行比较来实现这一点。这就是对简短惩罚（brevity penalty）。

如果我们的输出与任何参考译文一样长或者更长，那么惩罚值就是 1。由于我们将得分乘以它，因此这并不会改变最终的输出。

另一方面，如果我们的输出比任何参考译文都短的话，那么我们就将最接近的句子的长度除以输出的长度，从中减去 1，然后取 e 的整次幂。基本上，最短的参考译文越长，输出越短，那么简短惩罚值就越接近0。

在我们这个 “I ate” 例子中，输出的句子是两个单词长度，最接近的参考译文有四个单词的长度。我们就得到了一个 0.36 的惩罚，当我们的二元精度得分为 1 时，我们的最终得分下降到 0.36。

这种指标着眼于输出和参考译文之间的 n-gram 重叠，并以较短的输出为惩罚，被称为 “BLUE”（即双语评价基础研究的缩写：Bilingual evaluation understudy，人们在解释缩写时，就会这么说）。由 Kishore Papineni、Salim Roukos、Todd Ward 和 Wei-Jing Zhu 于 2002 年在 IBM 提出。它在 NLP 中是非常流行的指标之一，特别是对于系统输出的文本字符串而不是分类的任务。这包括了机器翻译、以及越来越多的自然语言生成。这就是我在本文开头提出的非常困难的问题的解决方案：开发一种方法，为翻译分配单个数字分数，告诉我们它有多 “好”。

然而，它也存在严重的缺陷。

BLEU 的缺陷

这时候你可能会想，“Rachael，如果这个指标有这么多缺陷，你为什么要要指导我们如何计算呢？” 我之所以这么做，主要是向你们展示这个指标有多合理。它是相当直观的，潜在的想法是，你可以通过将机器翻译系统的输出与参考译文进行比较来评价机器翻译的输出，这在 NLP 中有极大的影响力（尽管并非没有批评者）。

当然，BLUE 也有一些优势。从事 NLP 的研究人员最关心的是它有多方便。

BLUE 快速且易于计算，特别是与人工翻译速率模型输出相比的话尤为明显。
BLUE 无处不在，这使你将模型与同一任务的基准进行比较变得更为轻松。

不幸的是，由于这种便利性，人们都在过度使用它，即使对不是最佳指标选择的任务也是如此。

尽管我的例子只有一句话，但 BLEU 毕竟是一种语料库级别的指标。计算语料库中每条句子的 BLEU 分数，然后在他们之间取平均值会人为地夸大你的分数，如果你尝试在你所做的地方发表作品，肯定会被评论者的口水淹死。

即使你没有过度使用 BLEU，在你选择花时间去计算更好的 BLEU 分数之前，你应该知道这个指标也存在严重限制。虽然网上已经有很多关于 BLEU 缺点的讨论，但我认为，它的四个主要问题是：

它不考虑意义
它不直接考虑句子结构
它不能很好地处理形态丰富的语言
它与人类的判断并不相符

让我们逐一讨论这些缺陷，这样我就可以告诉你们为什么我认为这些都是缺陷。

BLEU 不考虑意义

对我来说，这是唯一最令人信服的理由：不单单依靠 BLEU 来评价机器翻译（Machine Translation，MT）系统。作为机器翻译的人类用户，我的主要目标是，能够准确理解原文的基本含义。主要输出的句子符合原文的意思，哪怕输出的句子存在一些怪异的句法或者语法，我也乐意接纳。

但是 BLEU 并不衡量意义。它只奖励参考系统中具有精确匹配的 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.

作为机器翻译系统的最终用户，实际上我认为输出的前两句没有什么问题。即使它们与参考译文不完全相同，但它们能让人理解原文的意思。但是，第三句就完全不能接受了，因为它完全改变了原文的意思。

NIST 是基于 BLEU 的一种指标，它通过对错误匹配的 n-gram 的惩罚进行加权来解决这个问题。因此，更为常见的 n-gram（如 “of the”）的不匹配将会得到更轻的惩罚，而在更罕见的 n-gram（如 “buffalo buffalo”）的不匹配将会受到更严重的惩罚。但是，虽然解决了赋予虚词过多权重的问题，但它实际上却使惩罚同义词（如 “ambled” 和 “walked”）的问题变得更槽糕了，因为这些同义词只出现在更为罕见的 n-gram 中，因此受到更严重的惩罚。

BLEU 不考虑句子结构

也许你不完全相信 “即使你搞错了一些关键词，完全改变了句子的意思，也仍然能够得到相当不错的 BLEU 分数”。也许有些句法会让你信服？

句法研究的是句子的结构。正是这个研究领域，我们才能对像 “I saw the dog with the telescope” 这样的锯子进行正式建模，这可以意味着两个意思：我用望远镜观察狗，或者这条狗有望远镜。这两种含义之间的差异，只能通过建模的句子中的单词之间可以彼此具有不同关系的事实来提现。

我不是世界上最伟大的句法学家（绝对没有希望），但即使是我也知道在自然语言中有很多重要的内部句法结构，如果你随意打乱句子中的单词顺序，你要么会得到这两种结果中的一个：

1）毫无意义的句子。
2）意思完全不同的句子。

幸运的是，在开发系统来完成对该结构自动建模方面做了大量的工作，这被称为句法分析。

但不幸的是，BLEU 并没有建立在任何这项研究的基础上。我能理解为什么你可能想要避免这种情况。因为解析往往需要很大的算力，并且每次评价的时候，必须解析所有的输出，这确实会增加一些开销。（尽管有一些指标，如 STM 或子树指标，可以直接比较参考和输出翻译的解析。）

然而，不考虑句法结构的结果意味着，表面词序完全混乱的输出也可以得到与更为连贯的输出具有相同的分数。

在 Callison-Burch 等人于 2006 年提出的《Re-evaluating the Role ofBLEUin Machine Translation Research》中有一个很好的例子。我们来看一下这组参考句子：

Orejuela appeared calm as he was led to the American plane which will take him to Miami, Florida.

Orejuela appeared calm while being escorted to the plane that would take him to Miami, Florida.

Orejuela appeared calm as he was being led to the American plane that was to carry him to Miami in Florida.

Orejuela seemed quite calm as he was being led to the American plane that would take him to Miami in Florida.

他们得到了机器翻译输出的句子：

Appeared calm when he was taken to the American plane, which will to Miami, Florida.

这翻译并不完美：因为人名被删除了，而且在后半句的 “will” 后面没有动词，但这样的翻译也不是完全没有意义。然而，这个例子是：

which will he was, when taken appeared calm to the American plane to Miami, Florida.

出人意料的是，BLEU 居然为第一个输出和第二个输出给出了相同的分数，尽管第一个显然是更好的英语翻译。

BLEU 不能很好地处理形态丰富的语言

如果像地球上的大多数人一样，你碰巧使用的不是英语，那么你可能已经发现这个指标存在一个问题：BLEU 是基于单次级的匹配。对于形态丰富的语言来说，这很快就会成为一个问题。

语素是语言中最小的意义单位，它们组合在一次就构成了单词。英语中有一个例子是，“cats” 中的 “s”，这表示有不止一只猫。有些语言，比如土耳其语，在一个单词中就有很多语素；而在其他语言，如英语，每个单词的语素通常较少。

来看看秘鲁语 Shipibo 的以下几条句子。（这些例子来自 Pilar Valenzuela 的 Shipibo 语的言据性，以及 Panoan 语对该类别的比较概述。）

Jawen jemara ani iki.

Jawen jemaronki ani iki.

上面这两句话都是英语句子 “her village is large” 的完全可以接受的翻译。你可能会注意到以 “jemar-” 开头的单词在两条句子中有不同的结尾。不同的词尾表示不同的语素，表明说话者对于村庄很大的这一事实有多确定：最上面的一条表示他们确实去过那里，而最下面的一条表示他们从别人那里听说村庄很大。

这种特殊类型的语素被称为 “证据标记”，而英语中不存在这些。然而，在 Shipibo 语中，你需要这两个语素中的一个用于句子语法，因此我们的参考译文肯定会有两个中的一个。但如果我们没有碰巧生成我们在参考句子中的单词的确切形式，那么 BLEU 就会因此进行惩罚…… 即使这两条句子都能很好地表达了英语的意思。

BLEU 与人类的判断不能很好地相符

当我讲到语法部分的时候，如果你感到昏昏欲睡，那么现在是时候提提神了。

构建机器翻译、聊天机器人或问答系统的最终目标是什么？你最终希望人们使用这些，对吧？如果这个系统不能提供有用的输出，谁还会用这些系统呢？因此，你真正想要优化的就是，使用你的系统的人们有多喜欢它。我们使用的几乎所有指标都被涉及成不同的近似方法。

当 BLEU 首次被提出时，作者确实做了一些行为测试，以确保这些测量与人类判断相关（他们这么做值得鼓励！）。然而不幸的是，随着研究人员进行更多的实验来比较 BLEU 评分和人类的判断，发现这种相关性并不总是很强，而且根据具体的任务，其他测量结果往往更接近人类的判断。

例如，在 Turian 等人发表的论文《Evaluation of Machine Translation and its Evaluation》中，他们发现在三种测量中，BLEU 与机器翻译人类判断的相关性最差，简单的 F1 与人类判断相关性最强，NIST 次之。2006 年，Callison-Burch 等人研究了为一项共同任务而开发的系统（如学术界的 Kaggle 竞赛，但没有奖金），并发现这些系统的相对排名存在巨大的差异，这取决于你是一句 BLEU 分数还是人类评价者的判断。在 Yanli Sun 与 2016 年发表的《Mining the Correlation between Human and Automatic Evaluation》中，比较了三种不同的指标：BLEU、GTM 和 TER，并再一次发现 BLEU 分数确实与人类判断的相关性最小。

换句话说就是：如果你希望人们喜欢使用你的系统，你不应该只关注获得更高的 BLEU 分数。

我并非唯一持保留意见的人

也许你仍然不相信这一点：BLEU 并不总是适合这项工作的工具。没关系，事实上，我很欣赏你的怀疑精神！但是，我并不是唯一一个不是这个指标最大粉丝的 NLP 从业者。下面我罗列出了其他同行评审的论文的连接，这些论文更多地讨论了 BLEU 的其他一些缺点：

同行评审论文：

Reiter（2018）是 ACL 论文的荟萃综述，该综述同时使用 BLEU 和人工判断进行评价，发现它们仅针对机器翻译系统的系统级综述进行模式组合。

http://aclweb.org/anthology/J18-3002

Sulem 等人（2018）建议不要使用 BLEU 来简化文本。他们发现，BLEU 分数既不能很好地反映语法，也不能很好地反映保存的意义。

http://aclweb.org/anthology/D18-1081

Novicoca 等人（2017）研究表明，在评价 NLG（自然语言生成，Natural Language Generation）任务时，BLEU 以及一些其他常用的指标并不能与人类判断很好地相符。

https://www.aclweb.org/anthology/D17-1238

Ananthakrishnan 等人（2006）对 BLEU 提出了几个具体的反对意见，并深入探讨了 BLEU 评分较高的英语、印地语翻译中的具体错误。

https://core.ac.uk/download/pdf/23798335.pdf

下面罗列了一些未经同行评审的资源：（虽然对于评审研究论文的同行来说，这些资源可能不那么有说服力，但却有可能更容易让你的老板信服。）

其他资源：

Amazon Research 的 Matt Post 就预处理对 BLEU 分数的影响进行了精彩的讨论。

https://arxiv.org/pdf/1804.08771.pdf

从事翻译工作的 Kirti Vashee 撰写的这篇博文，从译者的角度讨论了 BLEU 的问题。

http://kv-emptypages.blogspot.com/2010/03/problems-with-bleu-and-new-translation.html

Yoav Goldberg 在 2018 年的国际自然语言生成会议上做了一场很棒的演讲，其中讨论了为什么不应该将 BLEU 用于 NLG。你可以在下面网址找到相关的 PPT（以 “BLEU can be Misleading” 为搜索关键词可搜到相关 PPT）。特别是，他和合著者发现，他们的句子简化模型即使通过添加、删除或重复信息也能得到很高的 BLEU 分数。

https://inlg2018.uvt.nl/wp-content/uploads/2018/11/INLG2018-YoavGoldberg.pdf

Ana Marasović撰写的博文《NLP’s generalization problem, and how researchers are tackling it》，讨论了包括 BLEU 在内的各个指标如何无法捕获模型处理不同于它们在训练期间所接触的数据的能力。

https://thegradient.pub/frontiers-of-generalization-in-natural-language-processing/

那么你应该用什么呢？

在评价将文本作为输出的系统时，我希望你使用的主要方法是谨慎，特别是在构建最终可能投入生产的系统时。对于 NLP 从业者来说，考虑我们的工作将如何应用，以及可能出现的错误是非常重要的。想想这名巴勒斯坦人吧，他之所以被捕，是因为 Facebook 把他的一篇内容为 “早安” 的帖子翻译成了 “攻击他们”！我并非对 Facebook 鸡蛋里挑骨头，而是想指出 NLP 产品的风险可能比我们有时意识到的还要高。

仔细地挑选我们优化的指标是确保我们所使用的系统实际可用的重要部分。例如，对于像机器翻译这样的任务，我个人认为，惩罚意义上的重大改变非常重要。

也就是说，有很多自动评价指标可以取代 BLEU。其中一些可以更好地完成不同的任务，所以花点时间来评价哪些指标最适合你的特定项目是值得的。

有两种流行的方法实际上是 BLEU 的衍生物，旨在帮助解决它的一些缺点：

NIST。正如我上面所提到的，NIST 是根据稀有性对 n-gram 进行加权。这意味着正确匹配罕见的 n-gram 比正确匹配一个常见的 n-gram 更能提高分数。
ROUGE。它是 BLEU 的一种改进，侧重于召回率而不是精确率。换句话就是，它关注的是参考译文中有多少 n-gram 出现在输出中，而不是相反。

还有很多方法可以用来评价不基于 BLEU 的序列到序列模型。其中有一些是从机器学习的 NLP 的其他领域采取的措施。

困惑度（Perplexity）是信息论中的一种指标，更常用于语言建模。它衡量单词的学习概率分布于输入文本的概率分布的匹配程度。
词错率（Word error rate，WER）是语音识别中常用的指标。它衡量的是在给定参考输入的情况下，输出序列中的替换（比如 “an” 替换为 “the”）、删除和插入的数量。
F-score，也就是通常所说的简短惩罚，是精确率的平均值（有多少预测是正确的）和召回率（有多少可能正确的预测是对的）的平均值。

还有一些是专门为序列到序列的任务开发的。

STM，或子树指标（我在前面已提及）比较了参考和输出翻译的解析，并惩罚具有不同句法结构的输出。
METEOR，类似于 BLEU，但包含了其他步骤，如考虑同义词和比较单词的词干（这样 “running” 和 “run” 视为相匹配）。与 BLEU 不同的是，它明确用于比较句子而不是语料库。
TER（Translation error rate），即翻译错误率，衡量将原始输出翻译成可接受的人工翻译所需的编辑次数。
TERp，或成 TER-plus，是 TER 的扩展，它还考虑了释义、词干和同义词。
hLEPOR，一种更适用于土耳其语或捷克语等形态更为复杂的语言的指标。除却其他因素之外，它还考虑了词性（名词、动词等）等有助于捕获局发信息。
RIBES，与 hLEPOR 一样，它不依赖于与英语具有相同品质的语言，其设计初衷是为亚洲语言（如汉语和日语）提供更丰富的信息，而且不受单词边界的限制。
MEWR，可能是列表中最新的指标，我发现它最让人兴奋的一点是：它不需要参考翻译！（这对于资源不足的语言来说是喜大普奔的好事，因为这些语言可能没有大量的平行语料库。）它结合了单词和句子的嵌入（瀑布哦・捕获意义的某些方面）和困惑度为翻译进行评分。

那你的意思是，这玩意儿很复杂？

这几乎就是问题的核心了。要知道，语言是很复杂的，这就意味着衡量语言自动化是很难的事情。我个人认为，开发自然语言生成的评价指标目前可能是 NLP 中最难的问题。（如果你跟我一样感兴趣的话，在 2019 年的 NAACL 上将会有一场关于这个问题的研讨会，来参加吧！）

不过，有一种很好的方法可以确保你的系统在做人类喜欢的事情上变得更好：你可以向人们咨询他们的想法。人类评价曾经是机器翻译的标准，我认为它在今天仍然有一席之地。是的，它挺贵的，而且花费的时间还挺长。但是至少对即将投入生产的系统，我认为你应该和人类专家进行至少一轮的系统评价。

需要提醒的是，在进入这一轮由人类专家进行的系统评价之前，你可能需要使用至少一个自动评价指标。我会强烈建议你们在当且仅当以下这种情况使用 BLEU：

你正进行机器翻译，并且
你正在对整个语料库进行评价，以及
你知道指标存在局限性，并已准备好接受它们。

否则的话，你还是多花点时间去找寻一个更适合你特定问题的指标吧。

原文链接：
https://towardsdatascience.com/evaluating-text-output-in-nlp-bleu-at-your-own-risk-e8609665a213

更多内容，请关注AI前线

创作场景

慎用！BLEU 评价 NLP 文本输出质量存在严重问题