NLP输出文本评估：使用BLEU需要承担哪些风险？ - 好文

译者| 大鱼

责编 | 琥珀

出品 | 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

扫码添加小助手微信，回复你的研究方向，邀你加入技术交流群

精彩推荐

<https://mp.weixin.qq.com/s?__biz=MzI0ODcxODk5OA==&mid=2247502492&idx=2&sn=a642357673f43d16bb668770c6d61bd3&scene=21#wechat_redirect>

<https://mp.weixin.qq.com/s?__biz=MzU5MjEwMTE2OQ==&mid=2247484806&idx=1&sn=c58d08c011511d41dfa4992b07350cbf&scene=21#wechat_redirect>

推荐阅读：

*
“安利”一款debug神器：在AI面前，bug都不是事儿
<https://blog.csdn.net/dQCFKyQDXYm3F8rB0/article/details/87745688>

*
一键免费自动AI抠图，效果连PS大哥也点赞！
<https://blog.csdn.net/dQCFKyQDXYm3F8rB0/article/details/87745677>

*
这可能是史上最全的Python算法集！
<https://blog.csdn.net/dQCFKyQDXYm3F8rB0/article/details/87835017>

*
Python之父重回决策层，未来如何发展？
<https://mp.weixin.qq.com/s?__biz=MzU5MjEwMTE2OQ==&mid=2247484760&idx=2&sn=8dec73deea808dab8bfbb480ff3b818b&scene=21#wechat_redirect>

*
华为立 Flag：一年超越三星做全球智能手机老大！
<https://blog.csdn.net/csdnnews/article/details/87745829>

*
那些简历造假拿 Offer 的程序员，后来都怎么样了？
<https://blog.csdn.net/csdnsevenn/article/details/87745637>

*
被V神点赞, 我是如何用五子棋打败以太坊排名最高的应用的？ |人物志
<https://blog.csdn.net/Blockchain_lemon/article/details/87745582>

*
50个最有价值的数据可视化图表（推荐收藏）
<https://mp.weixin.qq.com/s?__biz=MzA3MjY1MTQwNQ==&mid=2649826077&idx=2&sn=b845af7418ee84c82679845240ba3986&scene=21#wechat_redirect>

*
2月报告：Python逆袭成功？踢馆Java，碾压C++！
<https://mp.weixin.qq.com/s?__biz=MzA5MjcxNjc2Ng==&mid=2650559415&idx=2&sn=9f537a4cbb9bc34aa3906e1b0ac014dc&scene=21#wechat_redirect>

热门工具换一换