<p>nltk.translate.bleu_score donne un résultat faux lorsque ngram est supérieur au ngram maximum de la phrase donnée</p>

Quelle version du code utilisez-vous ?

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

L'implémentation BLEU vient d'être corrigée avec le #1330 résolu. Si vous utilisez la branche develop de nltk , ceci devrait être la sortie :

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

Étant donné qu'une chaîne est une liste de caractères et que nltk importe les sentence_bleu() dans les importations de niveau supérieur, le code ci-dessus est le même 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

Pour installer la dernière branche develop , essayez :

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

( Notez que la branche de développement est soumise à _plus de bogues inattendus_ et il est recommandé aux utilisateurs d'installer la version master ou la version officielle )

Sur une note connexe mais pas directement impliquée dans l'implémentation actuelle de nltk de bleu , l'implémentation précédente sans le correctif #1330 est soumise aux mêmes défauts que le populaire multi-bleu.perl . Peut-être que vous trouverez intéressant de savoir pourquoi il a renvoyé 0 sans le correctif récent : https://gist.github.com/alvations/e5922afa8c91472d25c58b2d712a93e7

Merci @alvations . La version originale de nltk que j'ai utilisée était la 3.2. Je l'ai mis à jour à 3.2.1 maintenant et il lève maintenant ZeroDivisionError. Et j'ai utilisé Python 3.5.2

La seule version stable de BLEU se trouve dans la branche develop . Veuillez attendre sa sortie dans NLTK 3.2.2 ou installer la branche develop (mais notez que la branche de développement peut être sujette à des bogues non testés).

D'ACCORD. J'attendrai. Mais dans le cas que vous avez mentionné ci-dessus, si le poids est [0,25, 0,25, 0,25, 0,25], les résultats de phrase_bleu([['a', 'b', 'c']], ['a', 'b ', 'c']) et phrase_bleu([['a', 'b', 'c']], ['a', 'b', 'd']) devraient tous les deux être 0, selon l'article original

L'article original n'a pas tenu compte du fait que p_n peut être 0 si la longueur de référence/hypothèse est inférieure à n , voir l'équation dans la section 2.3 de http://www.aclweb .org/anthologie/P02-1040.pdf. Parce qu'il était censé être un score de corpus, la possibilité qu'il y ait des références/hypothèses de longueur inférieure à n n'a pas été abordée dans l'article.

Si nous regardons la formule de la section 2.3, cela prend le exp(log(p_n)) et quand p_n est 0, il entre dans une erreur de domaine mathématique parce que la fonction logarithme (c'est- y = log x dire

Donc, si nous devions implémenter le BLEU d'origine, l'utilisateur devrait recevoir un avertissement indiquant quelque chose comme " BLEU ne peut pas être calculé " chaque fois qu'il y a une erreur de domaine mathématique. Ainsi, les versions ultérieures de BLEU essaient de le corriger avec plusieurs hacks différents, l'historique des versions peut être trouvé sur https://github.com/moses-smt/mosesdecoder/blob/master/scripts/generic/mteval-v13a. pl#L17

Veuillez noter que la dernière version de BLEU est fournie avec les fonctions de lissage de l'article de Chen et Cherry (2014) qui n'est pas dans la version Moses de mteval.pl .

J'espère que l'explication t'aidera.