雷锋网 AI 科技评论按：本文作者 Rachael 是 Kaggle 的一位数据科学家，拥有语言学博士学位，尤其对 NLP 领域有较深入的研究。近日，基于 NLP 入门者常问到她的一个问题——怎样评价输出为文本的系统，她总结出了各种评价方法，并对其中的一个经典的评价标准——BLEU 进行了反思，她认为 BLEU 存在着较为严重的问题，并呼吁各位研究者要谨慎地使用它。这篇文章发表在 Medium 上，雷锋网 AI 科技评论编译如下。
我经常被 NLP 领域的入门者问到的一个问题就是，当系统输出文本而不是对输入文本的一些分类时，该如何去评价这些系统。在模型中输入文本然后模型输出其它文本的这类问题，就是我们都知道的序列到序列（sequence to sequence）或者字符串转导（string transduction）问题。
并且这些问题非常有趣！序列到序列建模的一般任务就是 NLP 中最有难度的一些任务的核心所在，这些任务包括：
文本摘要
文本简化
问答
聊天机器人
机器翻译
这类技术也在科幻小说以外的现实中实现了。通在如此广泛的出色应用中，我们很容易找出序列到序列建模越来越受欢迎的原因。而不容易的是，真正去评价这些模型。
遗憾的是，对于那些刚开始学习 NLP 的人来说，评价模型应该使用什么度量标准很难说清楚。更糟地是，评价序列到序列任务的最受欢迎的一种度量标准——BLEU，也有很多缺陷，尤其是当被应用于此前它从未计划评价的任务时。
不过你是幸运的，因为你看到了这篇全面深入的博客！在本文中，我将探讨这一经典的度量方法是怎样进行评价的（不用担心，我会将最大限度地减少方程式的使用）。我们将讨论 BLEU 存在的一些问题，并最终如何在你自己的工作中将这些问题减到最少。
找不到什么关于NLP评价指标的有趣的图，上面这张图大概可以算是大海捞针的一张：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 分。这个地方的问题是：我们需要想办法来让正在训练中的系统知道，类似于第一种句子（「I ate three hazelnuts」）的翻译结果要比类似于第二种句子（「Three three three three」）的翻译结果要好。
你可以通过对单词出现的次数进行求交运算，基于每个单词在任意一个参考翻译句中出现的最高次数来给每个单词打分，从而对最终的分数稍微进行调整。使用这种评价方法，我们的第一个句子（「I ate three hazelnuts」）依旧得 1 分，而第二个句子（「Three three three three」）则仅得到 0.25 分。
这就帮我们解决了「three three three three」的问题，但是在下面这个因为某些原因单词按照字母进行了排序的句子中，这个方法没有什么作用：
Ate hazelnuts I three
如果使用我们当前这一方法，这个句子就能得到 1 分——最佳分数！我们可以通过给相邻的两个单词而不是单个单词打分，来解决这一问题。这种方法叫做 n 元语法（n-grams），这里的 n 就是每一组的单词个数。一元语法（Unigrams）、二元语法（bigrams）、三元语法（trigrams）和四元语法（4-grams）分别由一个、两个、三个以及四个单词组成。
对于这个案例，我们使用二元语法。一般而言，BLEU 分数是基于一元、二元、三元和四元精度得出来的，不过我们这里为了简化，仅使用二元语法。同样为了简化，我们添加一个能让我们知道句子开头和结尾的句子边界的「单词」。遵照这些准则，这个单词按字母排序的案例的二元语法是：
[Ate hazelnuts]
[hazelnuts I]
[I three]
如果我们在上述评价单个单词的方法中使用这些二元语法，这个句子（「Ate hazelnuts I three」）现在的得分就是 0。上面的「three three three three」案例现在的得分也是 0 分，而不是 0.25 分；不过第一个案例「I ate three hazelnuts」的得分依旧为 1 分。不妙的是，下面的这个案例同样也能得 1 分：
I ate.
解决该问题的一个方法是，让目前已有的分数与句长比所有参考翻译句都短的输出句子的惩罚评价分数相乘。具体方式是，将这个句子与句长跟它最接近的参考翻译句进行句长对比。这种方法就是简短惩罚（brevity penalty）。
如果输出句长与参考翻译句一样长或者更长，惩罚值就是 1。由于我们将分数乘以了这个惩罚值，因而不会改变最终的输出得分。
另一方面，如果输入比所有的参考翻译句都要短，我们基于输出句子的长度找出与它的句长最接近的参考翻译句的长度，用后者的长度减去前者的长度，再取整个式子的 e 次方。一般来说，最短的参考翻译句越长以及输出句子越短，简短惩罚值就越接近于 0.
在「I ate」的案例中，输出句子长度为两个单词，而最接近的参考翻译句是四个单词，我们得出了简短惩罚就是 0.36，这个值乘以我们的二元精度分数 1 后，最终的得分就降低为 0.36 了。
这种找出输出句子与参考句子之间的 n 元语法重叠部分并对（比参考句子）更短的输出句子施以惩罚的评价方法，称作 BLEU（双语互译质量评估辅助工具，「Bilingual evaluation understudy」的简写，这一全称仅仅当人们在解释 BLEU 这一缩写字母时才会被使用），由 IBM 的 Kishore Papineni、Salim Roukos、Todd Ward 和 Wei-Jing Zhu 在 2002 年提出（论文查看网址：https://www.aclweb.org/anthology/P02-1040.pdf）。它是 NLP 领域的一种常用的评价标准，特别针对系统输出一个文本串而非一个分类的任务，包括机器翻译以及越来越多的自然语言生成任务。对于我在博文开头提到的一个极度困难的问题——创建一种方法来为翻译句子打一个对应的数值分数，从而判断这个句子有多「好」，BLEU 是一个解决方案。
然而，这个方法同样也有严重的缺陷。
BLEU 存在的问题
看到这里你或许想问「Rachael，如果这个评价标准存在这么严重的缺陷，那你为什么还要跟我们探讨怎样去计算它？」——主要是为了告诉你这个评价标准的合理程度。BLEU 是一个相当直观和基础的方法，让你能够通过比较机器翻译输出的句子与参考翻译来对前者进行评价，这一方法对 NLP 领域产生了相当大的影响（虽然该方法的批评者并不认同）。
当然，BLEU 也是有很多优势的。对于 NLP 领域的从业者来说，该方法最大的意义在于它给研究人员所带来的便利：
它易于计算且快速，尤其相比于人类翻译员对模型输出进行评估时。
它是普遍使用的，这就让你的模型与同一任务上的基准进行比较变得十分容易。
遗憾地是，这就非常容易导致该领域的从业者过度应用该方法，即便对于某些任务来说，该方法并不是最佳的评价标准——他们也非得使用这一方法。
尽管我上面只提到单句案例，但是 BLEU 的初衷是为了成为一个语料库级别的评价标准。提取语料库中每个句子的 BLEU 分数，然后对这些分数进行平均化处理，从而来人为增加你的实际分数——如果你使用了这种方法来试图发表工作，你的论文肯定会被评审拒绝。
并且即使这个方法没有被过度应用，它也存在很严重的限制——这个是你在选择花大量时间来追求计算出更好的 BLEU 分数前就应该知道的。虽然现在已经有很多关于 BLEU 缺点的讨论，但我认为它最主要的四个缺点如下：
它不考虑文本的意思
它不直接考虑句子结构
它没有很好地掌握词法丰富的语言
它没有很好映射出人类的判断
接下来让我们一个接一个地讨论这四个缺点，让我来告诉你为什么我认为它们是最主要的问题。
BLEU 不考虑文本的意思
对于我来说，这是为什么不要仅仅依赖于 BLEU 这一方法来评价机器翻译（MT）系统的唯一一个最重要的理由。作为机器翻译的人类用户，我最主要的目标就是准确地理解源语言中文本的潜在意思。只要机器能正确翻译出来源语言的意思，我也乐意接受输出句子中的一些句法或语法错误。
BLEU 却没有对机器翻译出来的意思进行评价，而仅仅对系统在参考系统中实现了精确匹配的 n 元语法进行了「奖励」。这就意味着，将功能词（如「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 元句法的惩罚值进行加权来解决了这一问题。因此，在更普遍的 n 元句法（例如「of the」）上的不匹配将会得到一个更低的惩罚值，不过在更少见的 n 元句法（例如「buffalo buffalo」，案例查看 http://mentalfloss.com/article/18209/buffalo-buffalo-buffalo-buffalo-buffalo-buffalo-buffalo-buffalo）上的不匹配则会受到更重的惩罚。不过虽然该方法解决了功能词占太高权重的问题，它实际上也使得惩罚同义词（例如将「walked」翻译成「ambled」）这一问题更加严重，因为这些同义词仅仅出现在少见的 r 元语法中，从而会得到一个更高的惩罚值。
BLEU 不直接考虑句子结构
或许你完全不敢相信「即便你将一些关键词打乱完全改变句子的意思，你也能够得出一个非常好的 BLEU 分数」这件事。也许一些句法能够让你相信？
句法是句子结构的一个研究课题，这一领域的研究能够让我们更正式地模拟句子，例如「I saw the dog with the telescope」，这句话可以表达「我使用望远镜去看一只狗」的意思，也可以理解为「这只狗拥有这台望远镜」，这两种意思的不同点，只能通过对句子中的单词彼此存在不同的关系这一现实进行建模才能捕捉得到。
我（绝对）算不上世界上最好的语法学家，但是即便是我也知道自然语言中有很多重要的内部语法结构，并且如果你随机打乱句子中单词的顺序，你或者得到 1）没有意义的一堆单词；或者 2）意思完全不同的句子。
幸运的是，现在研究人员已经在对句子结构进行自动建模的系统开发上做了大量工作，这个系统被称作句法分析（parsing）。
遗憾的是，BLEU 完全没有以这一研究为基础。我可以理解你想要跳过句法分析，因为它的计算相当密集，并且每次评价输出的时候，都要对整个输出句子进行句法分析，这的确增加了一些工作量（即便 STM 或子树评价标准等方法，也都是直接对参考翻译句和输出翻译句的句法分析进行比较。）
然而，忽视句法结构的结果是，那些单词顺序完全紊乱的输出和那些单词顺序与参考翻译句更加一致的输出所得到的分数是一样的。
这在 Callison-Burch 等人在 2006 年发表的论文（论文地址：http://www.aclweb.org/anthology/E06-1032）中得到了很好的说明。参考翻译句子如下：
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 没有很好地掌握词法丰富的语言
如果你想世界上的大部分人一样，正好也使用非英语语言，你或许早就发现了该评价标准的这个问题：它基于单词级别的匹配。对于形态非常丰富的语言，这种方法会很快出现这个问题。
词素是语言意义中最小的单元，它们组合在一起共同来构成单词。英语中一个案例是：「cats」中的「s」让我们了解到猫不止一只。一些语言如土耳其语，一个单词有许多词素，而其他语言如英文，每个单词的词素往往更少。
看一下下面用希皮博语（秘鲁的某种语言）表示的句子（这些案例来自于 Pilar Valenzuela 所写的「Evidentiality in Shipibo-Konibo, with a comparative overview of the category in Panoan」，阅读地址：https://books.google.com/books?hl=en&lr=&id=GWk9AAAAQBAJ&oi=fnd&pg=PA33&dq=info:q5ttUx4ZjpAJ:scholar.google.com&ots=p_ThJSA1nj&sig=TmEBbdwVxZP8lj0xt4DHmHeKZ84#v=onepage&q&f=false）。
Jawen jemara ani iki.
Jawen jemaronki ani iki.
这两个句子都是由英文原句「her village is large」翻译过来的，非常不错。你或许注意到了两个句子中间那个以「jemar-,」开头的单词的后半部分是不同的——二者的词素也不同，它们表示说话者在阐述「村庄很大」这个事实时有多大的把握：前者意味着说话者就在村庄现场，而后者则是说话者从其他人那里听到的「村庄很大」。
这一词素特例被称作「言据性制造者」（evidentiality marker），而英语则不具备这些词素。然而在希皮博语中，你至少需要让句子的该两种词素中的一种符合语法规则，因此参考翻译句中一定会有两种词素中的一种。但是如果输出翻译生成的单词形式跟参考翻译句中的对应单词的形式不完全一样，BLEU 就会因此而惩罚该单词… 即便两个句子都很好地抓住了英文句的意思。
BLEU 没有很好映射出人类的判断
如果在我讲述语法部分的时候，你的眼睛开始变得呆滞，现在是回神的时候了。
创建一个机器翻译或聊天 AI 或问答系统的终极目标是什么？你最终无非是想让人们来使用它，不是吗？不过如果系统无法进行输出有用的结果，人们就不会去使用这个系统。所以实际上，你想要不断优化你的系统的意义，就在于不断加深系统用户对它的喜爱程度。基本上我们使用的绝大部分评价标准的初衷，也都是从不同的角度来接近这个目标。
实际上，BLEU 被首次提出时，论文作者就进行了行为测试来确保这个评价标注与人类判断相互关联。（同时持续进行行为测试来确保二者间的关联！）遗憾的是，当研究者进行大量实验来比较 BLEU 分数与人类判断时，他们发现这一关联并不总是非常强，并且其他的评价标准依靠特定任务，评价方式比 BLEU 更接近人类判断。
例如，Turian 等人的论文（2003，论文地址：https://nlp.cs.nyu.edu/publication/papers/turian-summit03eval.pdf）就对比了三种机器翻译的评价标准，发现 BLEU 与机人类判断的关联度最弱，而 F1 与人类判断的关联度最强；其次是 NIST。Callison-Burch 等人的论文（2006，论文地址：http://www.aclweb.org/anthology/E06-1032）则探讨了专为分享任务（比如面向学术的 Kaggle 竞赛，不过没有奖金）开发的系统，发现根据是否考量 BLEU 分数或者人类评估员的判断，这些系统的相对排名也会非常不同。同时 Sun 的论文（2010，论文地址：http://www.lrec-conf.org/proceedings/lrec2010/pdf/87_Paper.pdf）则比较了 BLEU、GTM and TER 三种不同的评价标准，并再度发现 BLEU 的分数与人类判断的关联度是最低的。
换句话说：如果你希望人们享受使用你的系统，你就不应该仅仅专注于提高 BLEU 分数。
我不是唯一一位对 BLEU 持保留意见的人
或许你依旧不相信，BLEU 并不总是评估工作的正确工具。好吧，实际上我要为你的质疑精神鼓掌！然而，我并不是唯一一位不那么热衷于使用这一评估标准的 NLP 从业者。大家可前往以下链接，去阅读同行评议的论文，他们还对 BLEU 的一些其他缺点进行了更多的探讨。
同行评议的论文：
Reiter 的论文（A Structured Review of the Validity of BLEU，2018）是对 ACL 论文的后设意见，它使用了 BLEU 和人类判断来对机器翻译进行评价，并发现只有专门针对机器学习系统的系统级审查，它们才会被设计在一起。
Sulem 等人的论文（BLEU is Not Suitable for the Evaluation of Text Simplification，2018）不推荐使用 BLEU 来进行文本简化。他们发现 BLEU 分数既没有很好地反映语法也不能很好地反映原意的保留情况。
Novicova 等人的论文（Why We Need New Evaluation Metrics for NLG，2017）表明 BLEU 以及其他一些常用的评价标准在评估 NLG（自然语言生成）任务时，都不能很好地映射人类判断。
Ananthakrishnan 等人的论文（Some Issues in Automatic Evaluation of English-Hindi MT:
More Blues for BLEU，2006）为 BLEU 设计了几个特定的目标，并对 BLEU 得分较好的英语/北印度语翻译中的特定错误进行了全面深度的探究。
下面则是一些非同行评议的资源。（这些资源虽然无法让那些评审你写的论文的审稿人信服，但是能很轻易地让你的老板信服。）
其他资源：
Amazon 研究院的 Matt Post 针对预处理对 BLEU 分数的影响进行了非常不错的探讨。论文地址：A Call for Clarity in Reporting BLEU Scores，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 年的自然语言生成国际会议上带来了一场非常棒的演讲，其中就讨论为什么不应该在 NLG 领域中使用 BLEU。你可以前往 https://inlg2018.uvt.nl/wp-content/uploads/2018/11/INLG2018-YoavGoldberg.pdf 搜索词条（搜索「BLEU can be Misleading」去找到相关词条）。特别地，他和合作作者还发现，他们的句子简化模型即便在增加、消除或者重复信息等情况下，依旧得到了一个很高的 BLEU 分数。
Ana Marasović的博文「NLP's generalization problem, and how researchers are tackling it」（查看地址：https://thegradient.pub/frontiers-of-generalization-in-natural-language-processing/）探讨了训练期间，包括 BLEU 在内的单个评价标准是怎样在无法捕获模型能力的情况下去处理不同于其所接触过的数据的。
所以你应该使用什么评价标准来作为替代呢？
我希望你在有文本输出的评价系统中用到的最主要的东西就是「谨慎」，尤其是当你在开发某个可能最终投入生产的系统时。对于 NLP 从业者来说，思考我们的工作成果将来怎样得到应用以及可能会出现什么差池是非常重要的。回想一下那位由于 Facebook 将一封邮件上写着的「早上好」翻译成了「攻击他们」而遭到逮捕的巴勒斯坦人（新闻查看网址：https://www.theguardian.com/technology/2017/oct/24/facebook-palestine-israel-translates-good-morning-attack-them-arrest）！我这并不是在专门指责 Facebook，我只是想要指出 NLP 产品的风险可能比我们所意识到的要高。
谨慎地挑选好我们要优化的评价标准是确保工作的系统真正有用的重要一环。例如，针对机器翻译等任务，我个人认为惩罚对愿意进行了较大改变的单词非常重要。
也就是说，现在有大量能够进行自动评价的评价标准可以代替 BLEU，其中的一些对于不同的任务还会有更好的表现，因此值得花时间去评估一下对于你的特定项目来说，最好的选择是哪个。
现在有两个比较经典的方法，它们实际上衍生自 BLEU，专门为解决 BLEU 的某些缺点而设计：
NIST：正如我在上面所提到的，它基于 n 元语法的稀缺性对其进行加权。这就意味着对某个稀缺 n 元语法的正确匹配能提高的分数，要多于对某个常见的 n 元语法的正确匹配。
ROUGE：它对 BLEU 进行了修改，聚焦于召回率而非准确率。换句话说，该方法看重的是参考翻译句中有多少 n 元语法出现在输出句中，而不是输出句中有多少 n 元语法出现在参考翻译句中。
同时，你还可以使用很多方法去评价不基于 BLEU 的序列到序列模型，其中一些方法是从机器翻译以外的 NLP 其他细分领域中借鉴过来的。
Perplexity ：该方法借鉴自信息理论领域，通常被应用于语言建模。它可以对学到的与输入文本匹配的单词的概率分布的好坏进行评价。
单词错误率（WER）：它是语音识别中常用的评价标准，在给定参考输入的情况下，可以对输出序列中的置换（将「the」置换为「an」）、缺失以及插入的数量进行评估。
F-score：该方法通常也叫做 F1，它是准确率（有多少预测是正确的）与召回率（做出了多少可能正确的预测）的平均值。
其他方法则是专为序列到序列任务而设计的：
STM（即子树评价标准，subtree metric，我在上文中也提到过）：它对参考翻译句和输出翻译句的句法进行比较，并对存在不同句法结构的输出进行惩罚。
METEOR ：该方法类似于 BLEU，不过它增加了额外的步骤，例如考虑同义词，并对词干进行比较（因此「running」与「runs」会被计算为匹配）。此外，不像 BLEU 一样，METEOR 的设计初衷非常明确：用来比较句子而不是语料库。
TER （翻译错误率）：评价将原始输出转变为可接受的达到人类水平的翻译所需要的编辑量。
TERp（翻译错误率 plus）：是 TER 评价标准的一个扩展，它同样考虑释义、词干以及同义词。
hLEPOR ：是一个为更好地翻译土耳其语、捷克语等形态复杂语言而设计的评价标准。此外，它还考虑有助于抓住句法信息的词性（名词、动词等）等其他因素。
RIBES：像 hLEPOR 一样，该评价标准不要求语言英语一样（形态简单）。它专门为日语、中文等更具有信息量的亚洲国家的语言而设计，同时不需要遵循单词边界。
MEWR：它大概是列表中最新的评价标准了，也是最令我兴奋的一种方法：它不要求参考翻译！（对于没有大量可用的平行语料的稀缺语言来说，这真是太棒了！）它结合利用了单词与句子向量（可以抓住句意的一些内容）以及为翻译打分的复杂度。
当然，在本文中，我没有时间将研究人员们开发出来的所有自动的评价标准一一列举出来。不过，大家可以随心所欲地在评论区中留言你最喜欢的评价标准，并说明原因！
所以你说的是什么？它太复杂了！
这几乎就是问题的核心了。语言是复杂的，这就意味着自动评价语言是非常困难的。我个人认为，为自然语言生成开发评价标注是 NLP 领域当前最困难的问题。（实际上，NAACL 2019 上，将会有一场针对该问题的 workshop，如果大家跟我一样感兴趣的话可以持续关注 https://neuralgen.io/。）
也就是说，现在有一个非常好的方法来确保系统在完成某些任务时，实际表现得像人类所期望的那样好：你可以直接询问真人他们觉得怎么样。人类评价过去常常被用作机器翻译的标准，并且我认为这种评价标准依旧有可用的空间。是的，人类评价成本高且耗时长，但是至少对系统来说，这种方法是可投入使用的，我认为你应该至少做一轮在人类专家帮助下的系统评价。
不过，在你做这一轮系统评价之前，你或许需要使用至少一个自动的评价标准。并且我仅在以下情况下推荐你使用 BLEU：
1. 你正在评价机器翻译；
2. 你正在整个语料库上进行评价；
3. 你了解 BLEU 这个评价标准的局限性，并且你也准备好了接受这些局限。
否则，不妨多投入点时间去找到更适用于你的特定问题的评价标准吧。
via：https://medium.com/@rtatman/evaluating-text-output-in-nlp-bleu-at-your-own-risk-e8609665a213
如果大家对 Rachael Tatman 的 NLP 领域的研究感兴趣，可以前往她的主页：
https://www.kaggle.com/rtatman/kernels?sortBy=voteCount&group=everyone&pageSize=20&userId=1162990&tagIds=11208 雷锋网雷锋网(公众号：雷锋网)
。
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/134890.html