<p>nltk.translate.bleu_score da un resultado falso cuando ngram es mayor que el máximo de ngrams de la oración dada</p>

¿Qué versión del código estás usando?

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

La implementación de BLEU se ha solucionado recientemente con # 1330 resuelto. Si está utilizando la rama develop de nltk , este debería ser el resultado:

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

Dado que una cadena es una lista de caracteres y nltk importa sentence_bleu() a las importaciones de nivel superior, el código anterior es el mismo que:

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

Para instalar la última rama develop , intente:

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

( Tenga en cuenta que la rama de desarrollo está sujeta a _bugs más inesperados_ y se recomienda que los usuarios instalen master o la versión oficial )

En una nota relacionada, pero no directamente involucrada con la implementación actual nltk de bleu , la implementación anterior sin la corrección # 1330 está sujeta a los mismos defectos del popular multi-bleu.perl . Tal vez le resulte interesante saber por qué devolvió 0 sin la solución reciente: https://gist.github.com/alvations/e5922afa8c91472d25c58b2d712a93e7

Gracias @alvations . La versión original de nltk que utilicé fue 3.2. Lo actualicé a 3.2.1 ahora y ahora está generando ZeroDivisionError. Y usé Python 3.5.2

La única versión estable de BLEU está en la rama develop . Espere a que se publique en NLTK 3.2.2 o instale la rama develop (pero tenga en cuenta que la rama de desarrollo puede estar sujeta a errores no probados).

está bien. Voy a esperar. Pero en el caso que mencionaste anteriormente, si el peso es [0.25, 0.25, 0.25, 0.25], los resultados de enunciado_bleu ([['a', 'b', 'c']], ['a', 'b ',' c ']) y enunciado_bleu ([[' a ',' b ',' c ']], [' a ',' b ',' d ']) deben ser ambos 0, según el documento original

El artículo original no tuvo en cuenta el hecho de que p_n puede ser 0 si la longitud de la referencia / hipótesis es menor que n , consulte la ecuación en la Sección 2.3 de http: //www.aclweb .org / anthology / P02-1040.pdf. Debido a que estaba destinado a ser una puntuación de corpus, la posibilidad de que haya referencias / hipótesis de menos de n no se cubrió en el documento.

Si miramos la fórmula en la Sección 2.3, toma exp(log(p_n)) y cuando p_n es 0, entra en un error de dominio matemático porque la función logaritmo (es decir, y = log x ) tiene una asíntota en x = 0, de modo que el rango de x debe ser mayor que 0.

Entonces, si tuviéramos que implementar el BLEU original, el usuario debería recibir una advertencia que diga algo como "BLEU no se puede calcular" siempre que haya un error de dominio matemático. Entonces, las versiones posteriores de BLEU intentan solucionarlo con varios trucos diferentes, el historial de las versiones se puede encontrar en https://github.com/moses-smt/mosesdecoder/blob/master/scripts/generic/mteval-v13a. pl # L17

Tenga en cuenta que la última versión de BLEU viene con las funciones de suavizado de Chen y Cherry (2014). El papel no está en la versión Moses de mteval.pl .

Espero que la explicación ayude.