<p>nltk.translate.bleu_score дает ложный результат, когда ngram больше, чем максимальное ngrams данного предложения</p>

Какую версию кода вы используете?

$ python
>>> import nltk
>>> nltk.__version__
'3.2.1'

Реализация BLEU была недавно исправлена: решено # 1330. Если вы используете ветвь develop для nltk , это должно быть результатом:

>>> import nltk
>>> from nltk import bleu
>>> ref = hyp = 'abc'
>>> bleu([ref], hyp)
1.0
>>> from nltk import bleu
>>> ref, hyp = 'abc', 'abd'
>>> bleu([ref], hyp)
0.7598356856515925

Поскольку строка представляет собой список символов, а nltk импортирует sentence_bleu() в импорт верхнего уровня, приведенный выше код такой же, как:

>>> from nltk.translate.bleu_score import sentence_bleu
>>> sentence_bleu([['a', 'b', 'c']], ['a', 'b', 'c'])
1.0
>>> sentence_bleu([['a', 'b', 'c']], ['a', 'b', 'd'])
0.7598356856515925

Чтобы установить последнюю ветку develop , попробуйте:

pip install https://github.com/nltk/nltk/archive/develop.zip

( Обратите внимание, что ветвь разработки подвержена _более неожиданным ошибкам_, и пользователям рекомендуется установить master или официальный выпуск )

По соответствующему примечанию, но не имеющему прямого отношения к текущей реализации nltk bleu , предыдущая реализация без исправления # 1330 подвержена тем же недостаткам, что и популярная multi-bleu.perl . Возможно, вам будет интересно узнать, почему он вернул 0 без недавнего исправления: https://gist.github.com/alvations/e5922afa8c91472d25c58b2d712a93e7

Спасибо @alvations . Первоначальная версия nltk, которую я использовал, была 3.2. Я обновил его до 3.2.1, и теперь он вызывает ошибку ZeroDivisionError. И я использовал Python 3.5.2

Единственная стабильная версия BLEU находится в ветке develop . Подождите, пока он будет выпущен в NLTK 3.2.2, или установите ветку develop (но учтите, что ветка разработки может быть подвержена непроверенным ошибкам).

В ПОРЯДКЕ. Я подожду. Но в случае, о котором вы упомянули выше, если вес равен [0,25, 0,25, 0,25, 0,25], результаты offer_bleu ([['a', 'b', 'c']], ['a', 'b ',' c ']) и предложение_bleu ([[' a ',' b ',' c ']], [' a ',' b ',' d ']) оба должны быть равны 0, согласно исходной статье.

В исходной статье не учитывался тот факт, что p_n может быть 0, если длина ссылки / гипотезы меньше n , см. Уравнение в разделе 2.3 http: //www.aclweb .org / anthology / P02-1040.pdf. Поскольку это должно было быть оценкой корпуса, возможность того, что существуют ссылки / гипотезы меньше длины n не рассматривалась в статье.

Если мы посмотрим на формулу в разделе 2.3, она принимает exp(log(p_n)) и когда p_n равно 0, она попадает в ошибку математической области, потому что функция логарифма (например, y = log x ) имеет асимптоту при x = 0, так что диапазон x должен быть больше 0.

Поэтому, если бы мы реализовали исходный BLEU, пользователь должен получать предупреждение, в котором говорится что-то вроде «BLEU не может быть вычислен» всякий раз, когда возникает ошибка математической области. Таким образом, более поздние версии BLEU пытаются исправить это с помощью нескольких разных хаков, историю версий можно найти на https://github.com/moses-smt/mosesdecoder/blob/master/scripts/generic/mteval-v13a. pl # L17

Обратите внимание, что последняя версия BLEU поставляется с функциями сглаживания из статьи Чена и Черри (2014), которой нет в версии mteval.pl Моисея.

Надеюсь, объяснение поможет.