译者| 大鱼责编 | 琥珀出品 | AI科技大本营（公众号ID：rgznai100）

怎样评价输出为文本的系统？

刚接触 NLP 时常有个疑问，就是如何评估这样一个系统——其输出为文本，而非对输入分类。当把一些文本输入系统，得到的输出也为文本时，这类问题称为 seq2seq 或字符串转导（string transduction）问题。

NLP 的核心就是 seq2seq 建模，这些任务包括：

• 文本摘要
• 文本简化
• 问答
• 聊天机器人
• 机器翻译

想想该技术将具有多么激动人心的实际应用，也使得 seq2seq 模型越来越受到研究者的欢迎。实际上，评估这些系统并非易事。

遗憾的是，对于刚入门学习 NLP 的人来说，评估模型应使用什么指标并没有标准答案。更糟糕的是，当前用来评估 seq2seq 任务的最流行的指标之一 BLEU，也存在很明显的缺点，尤其是将其应用于从未做评估准备的任务时。

在本文中，Kaggle 的一位数据科学家 Rachael Tatman 会逐步介绍这个当前流行标准的原理，包括 BLEU 存在的问题，以及如何在工作中最大限度地减少这些问题。

一个棘手的问题

最初，BLEU 是为了评估机器翻译而开发的指标，所以我们来看一个翻译的例子。下面是语言 A（法语）：

J’ai mangé trois filberts.

这里有一些语言 B（英语）的参考译文：

I have eaten three hazelnuts.I ate three filberts.（我吃了三颗榛子。）

此处是一个生成的“神经系统的”翻译。（在这种情况下，“神经系统的”是“用大脑想出来的一种可能的翻译”，但假装这是由你训练的网络生成的。）

I ate three hazelnuts.

现在面临着一个很棘手的问题：我应该如何给一段翻译进行打分？仅仅基于参考译句和神经输出，来告诉大家这段翻译有多好？

为什么我们需要一个单独的分值？好问题！如果我们想用机器学习来建立机器翻译系统，我们需要一个单独的实数作为分数来填入我们的损失函数。如果我们知道可能的最高得分，我们就可以计算两者的差。这样我们就可以在系统的训练过程中，为其提供反馈，也就是提供一种可能的改变来提升翻译质量，使分数越来越接近目标分数，观察它们在同一个任务上的分数表现，将所训练的系统进行对比。

你可能需要做一件事，那就是查看输出语句中的每个单词。如果该单词在参考译句中出现了，就为其分配 1，否则分配 0。接下来，你需要将其标准化，保证它的值在 0 和 1 之间，你可以用翻译出的语句的单词个数去除输出语句的单词总数。这样就为我们提供了一种叫做 unigram 的测量指标。

因此，关于我们的例子 “I ate three hazelnuts”，我们在至少一个参考译句中看到了输出语句中的所有单词。用它除以输出单词的总数目 4，你最终会得到的分数为 1。到目前为止都很顺利！但下面这句话呢？

Three three three three.

使用相同的指标，我们也可以得到 1 分。这样不是很好：我们需要通过一些方法告诉系统，我们正在训练的第一个句子（的翻译结果）要比第二个句子好。

你可以根据任何参考译句中出现的最高次数，来计算每个单词的计数次数，从而对分数进行微调。基于该度量单位，我们的第一个语句仍可以得到 1 分，然而第二句只能拿到 0.25 分。

这帮我们解决了 “three three three three” 的问题，但无法处理像下面这样的句子，由于某种原因，这些单词是按字母顺序排列的：

Ate hazelnuts I three

使用我们当前的方法，这句话可以得到 1 分，也就是最高分！我们可以对相邻单词进行计数，而不是仅仅对单个词计数。Unigrams、bigrams、trigrams 以及 4-grams 分别由一个、两个、三个、四个单词块组成。

对于当前这个例子，我们使用 bigrams。一般来说，BLEU 分数是基于 unigram、bigram、trigram 和 4-gram 精度的平均值，但为了简单起见，我们在这里只用 bigram。同样为了简单起见，我们不会添加单词来告诉我们句子开头和结尾的边界。带着这些规则，按字母顺序排列的单词中的 bigram 如下：

[Ate hazelnuts][hazelnuts I][I three]

如果我们使用同样的计算方式，那么得到的分数为 0，也就是最坏的分数。我们的 “three three three three” 例句得到了 0 分，而不是 0.25 分，但最初的例句 “I ate three hazelnuts” 可以得到 1 分。不幸的是，下面这个例子也如此：

I ate.

解决这个问题的方法是，将我们迄今为止的分数乘以一个用来对语句做惩罚的指标。我们可以通过将它与长度最接近的参考语句的长度进行比较来实现，这就是惩罚因子。

如果我们的输出等于或长于任何参考语句，则惩罚分为 1。由于我们对分数做了乘法，这不会改变最终的输出。

另一方面，如果我们的输出比所有参考语句都短，我们要将最接近的句子长度除以输出的长度，从中减去一个，并将 e 提升到整个系统的水平。一般来说，最短参考语句越短，输出就越短，BP 值越接近零。

在 “I ate” 例子中，输出语句为两个单词的长度，最接近的参考语句有四个词长度。这给了我们 0.36 的惩罚因子，当我们的 bi-gram 精度得分为 1 时，我们将最终得分降到了 0.36。

这种考虑 n 个单词在输出和翻译语句间重合率的评估指标叫作 BLEU，是由 IBM 的 Kishore Papineni、Salim Roukos、Todd Ward 和 Wei-Jing Zhu 于 2002 年开发出来的。它在 NLP 中是一个非常流行的指标，尤其对于系统输出为文本字符串而非分类的任务，包括机器翻译和自然语言生成。这就是我在开篇提出的问题的一种解决方案：开发一种方法，为翻译结果分配单独的分数，从而告诉我们这句翻译有多“好”。

同时它也存在严重的缺陷。

BLEU 存在的几个问题

到了这里，你可能存在疑问，“如果该指标存在缺陷，为什么你要给我们介绍如何计算它呢？” 目的是为了向大家展示这项指标有多么合理。它是相当直观的，你可以通过将机器翻译系统的输出结果与参考翻译进行对比，来评估机器翻译系统的输出，这在 NLP 中具有极大的影响力。

BLEU 当然也有许多优点：

• 它的易于计算且速度快，特别是与人工翻译模型的输出对比；
• 它应用范围广泛，这可以让你很轻松将模型与相同任务的基准作对比。

遗憾的是，这种便利导致人们的过度使用，甚至有些情况下该指标不是最佳选择。

即便 BLEU 没有被过度使用，在你花时间并计算以追求更高的 BLEU 分数前，你也应该知道该度量标准存在的严重缺陷。已经存在很多关于 BLEU 缺陷的讨论，我认为它存在的四大问题是：

• 它不考虑语义
• 它没有直接考虑句子结构
• 它不能很好地处理形态丰富的语句
• 它无法很好地映射出人类的判断

让我们逐一讨论这些问题，这样我就可以告诉你们我做出该判断的原因。

BLEU 不考虑语义

对我而言，这是这是让我们不能仅靠 BLEU 来评估机器翻译系统唯一最令人信服的理由。作为机器翻译系统的人类用户，我的主要目标是准确理解源语言中文本的潜在含义。只要它符合源文的意思，我就可以欣然接受输出语句中句法和语法上存在的一些怪异之处。

BLEU 却不考虑语义。它只给那些与参考系统完全匹配的 n元（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.

作为机器翻译系统的终端用户，我可以接受前两个句子。虽然它们和参考翻译不完全相同，但它们理解的意思是对的。然而，第三句是完全无法接受的，它完全改变了原文的意思。

基于 BLEU 的指标之一的 NIST，通过给匹配错误的 n 元模型进行加权惩罚来解决这一问题。因此，一些常见的词组（如 of the）得到的惩罚会比较小，但一些罕见的词（如 buffalo buffalo）就会高一些。

BLEU 不考虑句子结构

也许你不相信，即使你弄乱一些关键词，导致完全改变了句子的意思，你仍然可以得到很好的 BLEU 分数。

我不是伟大的语法学家，但我知道在自然语言中存在很多重要的内部语法结构，如果你打乱句子中的单词顺序，你可能会得到一堆毫无意义的单词或具有完全不同含义的语句。

幸运的是，在开发系统以完成对结构的自动化建模的过程中可以采取一些措施，这个系统被称为句法分析（parsing）。

不幸的是，BLEU 没有涉及任何基于这方面的研究。我可以理解你为什么想逃避这块，因为句法分析往往需要密集的计算，并且每次评估时必须将所有输出进行句法分析，这就增加了一定的负担。

然而，不关注结果的语法结构意味着：一些结构混乱的输出可以获得与那些连贯语句相同的分数。

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

如地球上大多数人一样，如果碰巧你使用的语言不是英语，那么你可能已经发现这项指标存在的问题：它是基于单词进行匹配的。对于那些具有丰富形态的语言，问题很快就会浮现。

看下面这句话，这是一种秘鲁使用的语言 Shipibo：

Jawen jemara ani iki.Jawen jemaronki ani iki.

这两句话的意思都是“her village is large.”（她的村庄很大）。你可能注意到了中间的两个词，都以“jemar-”开头，但在两句话中有不同的结尾。不同的结尾是不同的语素，表示说话者对于村庄很大这件事的肯定程度；第一句话表示他们已经去过那里了，第二句表示他们是从别人那里听说了这件事。

这种特殊类型的语素被称为“证据标记”（evidentiality marker），英语中没有这类语素。但在 Shipibo 语言中，出于语法需要，你需要使用其中一个语素，所以我们的参考翻译肯定有其中之一。但如果我们碰巧没有生成参考语句中所用单词的确切形式，BLEU 就会对其进行惩罚……即使两句话都很好地捕捉到了英文的含义。

BLEU 没有很好地映射出人类的判断

创建机器翻译、聊天机器人以及问答系统的最终目的是什么？你最终希望人们使用它，对吗？如果一个系统无法给出有用的输出，人们是不会使用它的。所以你需要做出的优化是，让使用系统的人喜欢这个系统。

当 BLEU 被首次提出时，作者确实做了一些行为测试，来确保该测量指标与人类的判断相关。然而，当研究者们做了更多比较 BLEU 评分和人类判断的实验后，他们发现这种相关性并不总是很强烈，当评估不同任务时，其他测量指标往往与人类判断的关系更为密切。

还有哪些标准可以应用呢？

当你在评估一个以文本作为输出的系统时，最重要的事就是保持谨慎，特别是在构建可能投入生产的内容时。对 NLP 从业者来说，考虑我们所做工作的应用场景尤为重要。考虑一下那名被捕的中东男子，只是因为 Facebook 把一句“早上好”翻译成了“攻击他们”！我不是针对 Facebook，我只是想指出 NLP 产品的风险可能比我们想象的要高。

为了确保我们所使用的系统切实可用，谨慎选择优化指标是极其重要的环节。举个例子，对于机器翻译任务，我个人认为对语义变化大的地方做出惩罚十分重要。

也就是说，还有很多自动评估指标可以替代 BLEU。其中一些可以针对不同的任务表现更好，因此我们值得花一些时间来为项目选择最合适的评估指标。

实际上，目前有两种流行的方法都是由 BLEU 推导而来，旨在消除它的缺陷：

• NIST，根据罕见度对 n 元模型进行加权。这意味着相比起正确匹配一个常见的 n 元模型，正确匹配一个罕见的 n 元模型更容易提高你的分数。
• ROUGE，BLEU 的改进版，专注于召回率而非精度。换句话说，它会查看有多少个参考译句中的 n 元词组出现在了输出之中。

你还可以选择很多方法，它们都是基于 BLEU 的，其中一些源自机器学习以外的 NLP 的其他细分领域：

• Perplexity，是一项基于信息论的指标，更多用于语言建模。它可以测量单词的学习概率分布与输入文本概率分布的匹配程度。
• 单词错误率（即 WER），是一项常用于语音识别的度量指标。给定一个参考输入，它会测量输出序列中的替换（如 an 替换 the）、删除及插入次数。
• F-score，通常也被称为 F1，是精度（有多少预测是正确的）和召回率（做出了多少可能正确的预测）的平均值。

还有一些专门为 seq2seq 任务开发的指标：

• STM（即子树匹配/subtree metric），对参考译句和输出翻译的解析进行对比，并基于不同的句法结构对输出做出惩罚。
• METEOR，与 BLEU 类似，但增加了额外的步骤，如考虑同义词和比较单词的词干（这样 running 和 runs 就会被认作匹配）。与 BLEU 不同，它被明确设计为用于比较句子而非语料库。
• TER（即翻译错误率），测量了将原始输出转变成可接受的人类水平的翻译所需的编辑次数。
• TERp（即 TER-plus），是 TER 的扩展，它也同样考虑了释义、词干和同义词。
• hLEPOR，是一种旨在更好地适用于形态复杂语种（如土耳其语或捷克语）的度量指标。它还考虑了诸如词性（名词、动词等）之类的因素，来帮助捕获语法信息。
• RIBES，与 hLEPOR 类似，它不只用于类似英语的语种。它旨在为亚洲语言提供更多信息，如日语和中文。
• MEWR，可能是该列表中最新的评价标准，最令人兴奋的一点是：该指标不需要参考翻译！（这对那些资源匮乏的语种来说非常友好，因为这些语种没有庞大的平行语料库。）

当然，我没有足够的篇幅来介绍所有的自动化指标。您可以在评论中说出你最喜欢的指标，最好顺便解释一下为什么喜欢它！

你现在一定在想……这太复杂了！

这正是问题的核心。语言很复杂，也就意味着自动评估语言很困难。我个人认为，开发自然语言生成的评估指标可能是 NLP 中最难的问题。

也就是说，有一种很好的方法可以确保你的系统所做的事情被人类认可：你可以亲自问人们的想法。人工评估曾经是机器翻译的标准，我认为这个方法还有一席之地。是的，这个方法耗费的精力不小，而且需要花更多的时间。但至少对于投入生产的系统来说，我认为你应该让人类专家做至少一轮系统评估。

但在此之前，你可能需要使用至少一个自动评估指标。当满足以下几个条件时，我会推荐你使用 BLEU：

• 你在做机器翻译；
• 你在评估整个语料库；
• 你知道度量指标的局限性，并且已经准备好接受这些问题。

否则，我建议你另外找一个适合你特定问题的指标。

相关链接：https://medium.com/@rtatman/evaluating-text-output-in-nlp-bleu-at-your-own-risk-e8609665a213

（本文为AI科技大本营编译文章，转载请微信联系 1092722531）