<p>nltk.translate.bleu_score dá um resultado falso quando ngram maior do que o máximo de ngrams de determinada frase</p>

Qual versão do código você está usando?

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

A implementação do BLEU foi corrigida recentemente com # 1330 resolvido. Se você estiver usando o branch develop de nltk , esta deve ser a saída:

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

Como uma string é uma lista de caracteres e nltk importa sentence_bleu() para as importações de nível superior, o código acima é o mesmo 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 o branch develop mais recente, tente:

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

( Observe que o branch de desenvolvimento está sujeito a _bugs mais inesperados_ e é recomendado que os usuários instalem o master ou a versão oficial )

Em uma nota relacionada, mas não diretamente envolvida com a implementação atual de nltk de bleu , a implementação anterior sem a correção # 1330 está sujeita às mesmas falhas do popular multi-bleu.perl . Talvez você possa achar interessante saber por que ele retornou 0 sem a correção recente: https://gist.github.com/alvations/e5922afa8c91472d25c58b2d712a93e7

Obrigado @alvations . A versão original do nltk que usei era 3.2. Eu atualizei para 3.2.1 agora e agora está gerando ZeroDivisionError. E eu usei Python 3.5.2

A única versão estável do BLEU está no branch develop . Por favor, aguarde o lançamento em NLTK 3.2.2 ou instale o branch develop (mas observe que o branch de desenvolvimento pode estar sujeito a bugs não testados).

OK. Eu vou esperar. Mas, no caso que você mencionou acima, se o peso for [0,25, 0,25, 0,25, 0,25], os resultados de frase_bleu ([['a', 'b', 'c']], ['a', 'b ',' c ']) e frase_bleu ([[' a ',' b ',' c ']], [' a ',' b ',' d ']) devem ser ambos 0, de acordo com o artigo original

O artigo original não levou em consideração o fato de que p_n pode ser 0 se o comprimento da referência / hipótese for menor que n , consulte a equação na seção 2.3 de http: //www.aclweb .org / antology / P02-1040.pdf. Por ser uma pontuação de corpus, a possibilidade de que existam referências / hipóteses menores que n não foi abordada no artigo.

Se olharmos a fórmula na Seção 2.3, ela pega exp(log(p_n)) e quando p_n é 0, resulta em um erro de domínio matemático por causa da função de logaritmo (ou seja, y = log x ) tem uma assíntota em x = 0, de forma que o intervalo de x deve ser maior que 0.

Portanto, se formos implementar o BLEU original, o usuário deve receber um aviso que diz algo como "BLEU não pode ser calculado" sempre que houver um erro de domínio matemático. Portanto, as versões posteriores do BLEU tentam consertá-lo com vários hacks diferentes, o histórico das versões pode ser encontrado em https://github.com/moses-smt/mosesdecoder/blob/master/scripts/generic/mteval-v13a. pl # L17

Observe que a versão mais recente do BLEU vem com as funções de suavização do papel de Chen e Cherry (2014) e não está na versão Moses de mteval.pl .

Espero que a explicação ajude.