在nltk.translate
中,MT评估指标仍然存在一些问题。其中大部分的BLEU相关问题已经在#1330中得到解决。但是在RIBES和CHRF中也出现了类似的问题:
ribes_score.py
- https://github.com/nltk/nltk/blob/develop/nltk/translate/ribes_score.py#L290 和 https://github.com/nltk/nltk/blob/develop/nltk/translate/ribes_score.py#L320 在可能的ngram对数为0时会出现ZeroDivisionError
chrf_score.py
- 其他评分的参考接口默认支持多引用,而ChRF评分支持单引用。应该标准化以适应多引用
- 但在多引用评分的情况下,ChRF没有指示要选择哪个参考,我们可能需要联系作者来了解如何处理这个问题。
6条答案
按热度按时间4jb9z9bj1#
在Maja Popovic的实现中,当提供多个引用时,使用导致最高f-score的引用,参见:https://github.com/m-popovic/chrF/blob/master/chrF%2B%2B.py#L155
q43xntqr2#
似乎在计算bleu时存在一个错误,当不是所有句子都比最大n-gram长度短时。例如,以下测试用例应该得到1.0的bleu值,但实际上没有:
长度为3且与参考相同的句子被评分为有0个正确4-grams,而不是0个正确4-grams。
建议的补丁:
eivnm1vs3#
在@bmaland之前,@bamattsson对#1844的贡献之前,NLTK的BLEU有一些技巧来确保精确字符串匹配给出1.0的结果,但在#1844之后,NLTK的BLEU分数与https://github.com/moses-smt/mosesdecoder/blob/master/scripts/generic/multi-bleu.perl中可以找到的相似。
请注意,BLEU分数是语料库级别的度量,而不是句子级别的度量。这是一篇很好的论文,描述了相关问题:https://arxiv.org/pdf/1804.08771.pdf
wixjitnu4#
如果你不确定列表中是否有短字符串,可以使用自动重新加权功能,例如:
dxxyhpgq5#
在我上面的例子中,multi-bleu.pl给出了100.0的分数,但nltk给出了0.84的分数。这是一个例子,其中假设确实有一些匹配的4-grams,但参考中的每个句子的长度都不是4或更大。
nkcskrwz6#
这个是否仍然开放?