<p>nltk.translate.bleu_score gibt ein falsches Ergebnis, wenn ngram größer als die maximalen ngrams des gegebenen Satzes ist</p>

Welche Version des Codes verwendest du?

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

Die BLEU-Implementierung wurde erst kürzlich mit #1330 behoben. Wenn Sie den develop Zweig von nltk , sollte dies die Ausgabe sein:

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

Da eine Zeichenfolge eine Liste von Zeichen ist und nltk die sentence_bleu() in die Importe der obersten Ebene importiert, ist der obige Code derselbe wie:

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

Um den neuesten develop Zweig zu installieren, versuchen Sie Folgendes:

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

( Beachten Sie, dass der Entwicklungszweig _mehr unerwarteten Fehlern_ ausgesetzt ist und es wird empfohlen, dass Benutzer die master oder offizielle Version installieren )

In einem verwandten Hinweis, aber nicht direkt mit der aktuellen nltk Implementierung von bleu , unterliegt die vorherige Implementierung ohne den Fix #1330 denselben Fehlern wie das beliebte multi-bleu.perl . Vielleicht finden Sie es interessant zu wissen, warum 0 ohne den letzten Fix zurückgegeben wurde: https://gist.github.com/alvations/e5922afa8c91472d25c58b2d712a93e7

Danke @alvations . Die ursprüngliche Version von nltk, die ich verwendet habe, war 3.2. Ich habe es jetzt auf 3.2.1 aktualisiert und es löst jetzt ZeroDivisionError aus. Und ich habe Python 3.5.2 verwendet

Die einzige stabile Version von BLEU befindet sich im develop Zweig. Bitte warten Sie, bis es in NLTK 3.2.2 veröffentlicht wird, oder installieren Sie den develop Zweig (beachten Sie jedoch, dass der Entwicklungszweig möglicherweise ungetesteten Fehlern ausgesetzt ist).

OK. Ich werde warten. Aber in dem oben erwähnten Fall, wenn das Gewicht [0.25, 0.25, 0.25, 0.25] ist, werden die Ergebnisse von Satz_bleu([['a', 'b', 'c']], ['a', 'b ', 'c']) und Satz_bleu([['a', 'b', 'c']], ['a', 'b', 'd']) sollten laut Originalarbeit beide 0 sein

Das Originalpapier berücksichtigte nicht die Tatsache, dass p_n 0 sein kann, wenn die Länge der Referenz/Hypothese kürzer als n , siehe Gleichung in Abschnitt 2.3 von http://www.aclweb .org/anthology/P02-1040.pdf. Da es sich um einen Korpus-Score handelte, wurde die Möglichkeit, dass es Referenzen/Hypothesen mit einer Länge n weniger als

Wenn wir uns die Formel in Abschnitt 2.3 ansehen, nimmt sie exp(log(p_n)) und wenn p_n 0 ist, kommt es zu einem mathematischen Domänenfehler, weil die Logarithmusfunktion (dh y = log x ) hat eine Asymptote bei x = 0 , sodass der Bereich von x größer als 0 sein muss.

Wenn wir also das ursprüngliche BLEU implementieren, sollte der Benutzer bei jedem mathematischen Domänenfehler eine Warnung erhalten, die etwa "BLEU kann nicht berechnet werden" lautet. Die neueren Versionen von BLEU versuchen es also mit mehreren verschiedenen Hacks zu beheben, die Historie der Versionen findet sich auf https://github.com/moses-smt/mosesdecoder/blob/master/scripts/generic/mteval-v13a. pl#L17

Bitte beachten Sie, dass die neueste Version von BLEU mit den Glättungsfunktionen aus dem Papier von Chen und Cherry (2014) nicht in der Moses-Version von mteval.pl .

Ich hoffe die Erklärung hilft.