Nltk: Странный крайний случай для оценки bleu.

Просто уточнение перед тем, как погрузиться в подробности. Получаете ли вы предупреждение, когда пробуете эти второстепенные случаи?

Да, я получаю предупреждение.

Хороший. Давайте рассмотрим, почему именно таковы выходы:

Во-первых, обратите внимание, что несглаженный BLEU никогда не предназначался для оценки уровня предложения, рекомендуется найти оптимальный метод сглаживания, который требуется вашим данным, пожалуйста, посмотрите https://github.com/alvations/nltk/blob/develop/ nltk / translate / bleu_score.py # L425

Если пользователь хочет пропустить шаг, чтобы найти оптимальное сглаживание, давайте посмотрим на приведенные вами примеры.

Первый сценарий, когда ваш порядок n-граммов больше, чем перекрытие, которое существует между ссылкой и гипотезой, BLEU корпуса / предложения не будет работать в этом случае. Так что результаты этого не могут быть приняты во внимание:

>>> from nltk.translate.bleu_score import sentence_bleu
>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0.5, 0.5)) 
/usr/local/lib/python2.7/site-packages/nltk/translate/bleu_score.py:490: UserWarning: 
Corpus/Sentence contains 0 counts of 2-gram overlaps.
BLEU scores might be undesirable; use SmoothingFunction().
  warnings.warn(_msg)
0.5

Далее у нас есть пример, в котором существует 1 биграмма, а 2 униграммы перекрывают ссылку и гипотезу. Похоже, он дает разумную оценку.

>>> sentence_bleu([[1,2,3,4]],[5,6,1,2], weights=(0.5, 0.5))
0.408248290463863

Переходя к следующему примеру с использованием weights=(0, 0.5) , это довольно неинтуитивно, потому что не присвоение оценок для более низких n-граммов приводит к поражению цели BLEU, где мы сопоставляем геометрически по порядку n-граммов. Но давайте посмотрим:

>>> sentence_bleu([[1,2,3,4]],[5,6,2,3], weights=(0, 0.5))
0.5773502691896257

Мы видим, что у него такие же совпадения 1 биграмм и 2 униграмм, но у него более высокий балл. И это потому, что мы взвешиваем биграммы тяжелее, чем униграммы, и у униграммов отсутствует влияние. Поскольку биграмм меньше, чем униграмм, естественно, что результирующий BLEU выше.

>>> import math
>>> from nltk import ngrams
>>> from nltk.translate.bleu_score import modified_precision

>>> ref, hyp = [1,2,3,4], [5,6,2,3]

>>> list(ngrams(ref, 2)) # 3 bigrams.
[(1, 2), (2, 3), (3, 4)]
>>> list(ngrams(ref, 1)) # 4 unigrams.
[(1,), (2,), (3,), (4,)] 

Описание большего количества совпадений = лучшего результата BLEU интуитивно понятно, но на самом деле это только часть формулировки BLEU, отраженной в измененной точности:

>>> modified_precision([ref], hyp, 2)
Fraction(1, 3)
>>> modified_precision([ref], hyp, 1) 
Fraction(2, 4)

>>> m1 = modified_precision([ref], hyp, 1)
>>> m2 = modified_precision([ref], hyp, 2)

Если мы перейдем к среднему геометрическому логарифмическому, мы увидим, что измененная точность немного искажается:

>>> import math
>>> math.log(m1)
-0.6931471805599453
>>> math.log(m2)

-1.0986122886681098
>>> math.exp(0.5 * math.log(m1) + 0.5 * math.log(m2))
0.408248290463863
>>> math.exp(0 * math.log(m1) + 0.5 * math.log(m2))
0.5773502691896257

Итак, из первых трех приведенных вами примеров первый недействителен (следовательно, предупреждение), второй и третий могут быть непростыми для понимания, но они математически верны:

>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0.5, 0.5)) 
0.5
>>> sentence_bleu([[1,2,3,4]],[5,6,1,2], weights=(0.5, 0.5))
0.408248290463863
>>> sentence_bleu([[1,2,3,4]],[5,6,2,3], weights=(0, 0.5))
0.5773502691896257

Обратите внимание, что я пропустил шаг штрафа за краткость, но поверьте мне, это 1.0, поскольку длина гипотезы такая же, как и у ссылки. Пожалуйста, проверьте себя тоже =)

Переходя к 4-му примеру, мы используем ту же модифицированную точность, а затем вычисляем средний геометрический логарифмический шаг:

>>> sentence_bleu([[1,2,3,4]],[5,6,7,3], weights=(0, 0.5))
/Users/liling.tan/git-stuff/nltk-alvas/nltk/translate/bleu_score.py:491: UserWarning: 
Corpus/Sentence contains 0 counts of 2-gram overlaps.
BLEU scores might be undesirable; use SmoothingFunction().
  warnings.warn(_msg)
1.0

>>> ref, hyp = [1,2,3,4], [5,6,7,3]
>>> modified_precision([ref], hyp, 1)
Fraction(1, 4)
>>> modified_precision([ref], hyp, 2)
Fraction(0, 3)
>>> m1 = modified_precision([ref], hyp, 1)
>>> m2 = modified_precision([ref], hyp, 2)

>>> math.exp(0 * math.log(m1) + 0.5 * math.log(m2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error

Таким образом, использование bigram BLEU также недопустимо без надлежащей функции сглаживания.

Возможно, предупреждение не отображалось при использовании BLEU, потому что фильтр предупреждений установлен по умолчанию. Я думаю, что это хорошая идея сделать это предупреждение принудительно, но оно действительно раздражает пользователей, когда оно слишком часто появляется в периферийном наборе данных.

Последний пример действителен, так как он возвращает ожидаемое значение 0 для 0 совпадающей униграммы. В итоге:

>>> import warnings
>>> warnings.simplefilter("always")

>>> from nltk.translate.bleu_score import sentence_bleu

# Invalid use of BLEU.
>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0.5, 0.5)) 
/Users/liling.tan/git-stuff/nltk-alvas/nltk/translate/bleu_score.py:491: UserWarning: 
Corpus/Sentence contains 0 counts of 2-gram overlaps.
BLEU scores might be undesirable; use SmoothingFunction().
  warnings.warn(_msg)
0.5

# Valid BLEU score.
>>> sentence_bleu([[1,2,3,4]],[5,6,1,2], weights=(0.5, 0.5))
0.408248290463863

# Logical BLEU score.
>>> sentence_bleu([[1,2,3,4]],[5,6,2,3], weights=(0, 0.5)) 
0.5773502691896257

# Invalid use of BLEU.
>>> sentence_bleu([[1,2,3,4]],[5,6,7,3], weights=(0, 0.5))
/Users/liling.tan/git-stuff/nltk-alvas/nltk/translate/bleu_score.py:491: UserWarning: 
Corpus/Sentence contains 0 counts of 2-gram overlaps.
BLEU scores might be undesirable; use SmoothingFunction().
  warnings.warn(_msg)
1.0

# Valid BLEU score.
>>> sentence_bleu([[1,2,3,4]],[5,6,8,7], weights=(0, 0.5))
0

Теперь перейдем к последним двум примерам. На самом деле, первый экземпляр - недопустимое использование BLEU, вы должны это увидеть:

>>> from nltk.translate.bleu_score import sentence_bleu

>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0.5, 0.5))
/Users/liling.tan/git-stuff/nltk-alvas/nltk/translate/bleu_score.py:491: UserWarning: 
Corpus/Sentence contains 0 counts of 2-gram overlaps.
BLEU scores might be undesirable; use SmoothingFunction().
  warnings.warn(_msg)
0.5

>>> sentence_bleu([[1,2,3,4]],[5,6,1,2], weights=(0.5, 0.5))
0.408248290463863

Всякий раз , когда предупреждение появляется в п - го порядка Ngram (в данном случае, биграммы), то обычно это злоупотребление BLEU , и он будет принимать только на счет веса п-1th порядка (в данном случае, в юниграммах).

Итак, если мы увидим первый пример с единственными весами для униграммы:

>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0,))
1.0

Среднее геометрическое логарифмическое значение несколько сбивает с толку, но ключом к этому является то, что сумма весов порядков n-граммов должна составлять 1,0, чтобы соответствовать первоначальной идее BLEU. Например

>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(1,))
0.25

В общем, всякий раз, когда появляется предупреждение, это не-BLEU ситуация, когда BLEU не работает, и нет никаких активных исследований, чтобы исправить эту конкретную боль, кроме исследователей, создающих новые «лучшие» оценки, которые имеют другую ахиллесову пяту.

В случае, если всплывает предупреждение и пользователю требуется быстрое исправление, существует опция emulate_multibleu но веса должны быть установлены равными единым весам по умолчанию для всех 4-граммов, например

>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], emulate_multibleu=True)
0.0

И если мы используем multi-bleu.perl :

$ cat ref 
1 2 3 4
$ cat hyp 
5 6 8 1
$ perl ~/mosesdecoder/scripts/generic/multi-bleu.perl ref < hyp
BLEU = 0.00, 25.0/0.0/0.0/0.0 (BP=1.000, ratio=1.000, hyp_len=4, ref_len=4)

Таким образом, возникает вопрос:

• Нужна ли нам функция для автоматической корректировки весов, если веса, которые задают пользователи, не соответствуют BLEU? В настоящее время функция auto_reweigh работает только со значением по умолчанию weights = (0.25, 0.25, 0.25, 0.25) .

  • Я против этой идеи, поскольку (i) пользователи, использующие настраиваемые веса, должны лучше понимать механизм BLEU и при необходимости соответствующим образом настраивать веса и (ii) если пользователи не хотят хлопот, они должны использовать веса по умолчанию и / или emulate_multibleu вариант

• Следует ли устанавливать фильтр предупреждений всегда, когда пользователь использует BLEU?

Если есть какие-либо активные исследования и проверенные решения для этих второстепенных случаев BLEU, мы будем открыты для повторной реализации этих решений.

Но если это исправления, которые приводят к более дурацкой ситуации с BLEU , то я думаю, что текущая версия BLEU достаточно стабильна с предупреждениями на месте =)

@benleetownsend Я надеюсь, что объяснение имеет смысл и показывает, что текущая реализация BLEU с различными параметрами достаточна для преодоления приведенных вами примеров.

Я предлагаю (i) избегать взлома весов, если вы не используете некоторые теоретико-информационные подходы для их оценки, (ii) использовать опцию emulate_multibleu=True с весами по умолчанию (0,25, 0,25, 0,25, 0,25) или (iii ) поэкспериментируйте с различными методами сглаживания, чтобы получить соответствующую модифицированную точность, но все же избегайте взлома весов.

Спасибо за подробный ответ. Я согласен со всем, что вы сказали, однако я полагаю, что моя основная точка зрения заключается в том, что мне кажется, что результаты, когда вы снижаете n-1 грамм, кажутся неправильными, основываясь на литературе, которую я видел.

>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0.5, 0.5))
/Users/liling.tan/git-stuff/nltk-alvas/nltk/translate/bleu_score.py:491: UserWarning: 
Corpus/Sentence contains 0 counts of 2-gram overlaps.
BLEU scores might be undesirable; use SmoothingFunction().
  warnings.warn(_msg)
0.5

В этом случае я бы сказал, что следовать уравнению BLEU и возвращать 0 для этого случая «нежелательно», но если я не пропустил что-то в литературе, результат 0,5 для этого неверен.

Я бы предложил либо более четкое предупреждение, в котором говорится, что результаты неправильные (а не нежелательные), либо установка механизма «сглаживания» по умолчанию, чтобы возвращать sys.float_info.min что приводит к баллу bleu 0 при «недопустимом использовании BLEU. " случаи.

Если вы не согласны, закройте этот вопрос. Я решил эту проблему в своем проекте с помощью настраиваемой функции сглаживания, содержащей указанные выше функции.

Еще раз спасибо за ваше время.

Короткие вопросы.

Над каким набором данных вы работаете? И как часто это происходит?

Кроме того, лучше всего подходит сглаживание.

Возвращаясь к тому, почему добавление sys.float_info.min неправильно в несглаживающей версии BLEU.

Когда мы добавляем sys.float_info.min к точности для определенного порядка n-граммов к несглаженному BLEU , мы технически обеспечиваем сглаженный показатель точности, подобный лапласу. Это похоже на метод 1 в https://github.com/nltk/nltk/blob/develop/nltk/translate/bleu_score.py#L496

Вы можете сделать это, если хотите функциональность сглаженного BLEU:

>>> from nltk.translate.bleu_score import sentence_bleu
>>> from nltk.translate.bleu_score import SmoothingFunction
>>> import sys

>>> smoother = SmoothingFunction()

# Laplacian smoothing.
>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], smoothing_function=smoother.method1)
0.08034284189446518

# Laplacian smoothing, with altered weights.
>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0.5, 0.5), smoothing_function=smoother.method1)
0.09128709291752769

# Canonical multi-bleu smoothing, aka method4().
>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], smoothing_function=smoother.method4)
0.19564209772076444

Но мы не можем добавить это в SmoothingFunction.method0 поскольку method0() по умолчанию не сглаживают BLEU.

Возвращать sys.float_info.min вместо отсрочки тоже неправильно.

Формула BLEU:

Одна из причин, по которой взлом весов без эмпирической истины - плохая идея, потому что веса в BLEU подчиняются exp() .

Итак, если мы перейдем к вычислениям BLEU с обычными однородными весами 0,25, оценка BLEU будет чрезвычайно низкой - 0.

>>> p_n = [0.25, sys.float_info.min, sys.float_info.min, sys.float_info.min]
>>> weights = (0.25, 0.25, 0.25, 0.25)
>>> math.exp(sum(w*math.log(p_i) for w, p_i in zip(weights, p_n)))
1.288229753919562e-231

Используя weights=(0.5, 0.5) , тоже переходит в 0.

>>> p_n = [0.25, sys.float_info.min]
>>> weights = (0.5, 0.5)
>>> math.exp(sum(w*math.log(p_i) for w, p_i in zip(weights, p_n)))
7.458340731200295e-155

Может быть, это не очевидно, но возвращение отсрочки sys.float_info.min ВСЕГДА приведет к сверхнизкому баллу BLEU.

Если представить себе использование относительно хорошего или почти идеального перевода, мы увидим встречный пример:

>>> m1 = modified_precision([[1,2,3,4]], [2,3,4,5], 1)
>>> m2 = modified_precision([[1,2,3,4]], [2,3,4,5], 2)
>>> m3 = modified_precision([[1,2,3,4]], [2,3,4,5], 3)
>>> m4 = modified_precision([[1,2,3,4]], [2,3,4,5], 4)
>>> [m1, m2, m3, m4]
[Fraction(3, 4), Fraction(2, 3), Fraction(1, 2), Fraction(0, 1)]
>>> [m1, m2, m3, sys.float_info.min]
[Fraction(3, 4), Fraction(2, 3), Fraction(1, 2), 2.2250738585072014e-308]
>>> p_n = [m1, m2, m3, sys.float_info.min]
>>> weights = (0.25, 0.25, 0.25, 0.25)
>>> math.exp(sum(w*math.log(p_i) for w, p_i in zip(weights, p_n)))
8.636168555094496e-78

Основная причина, по которой я спросил о наборе данных и о том, как часто возникает проблема, заключается в том, что вы, возможно, не ожидаете волны других проблем, подобных указанной выше.

Как только мы попытаемся вернуть sys.float_info.min , это создаст целую волну проблем, которые вы не рассматривали вне своего набора данных.

В качестве альтернативы, если мы вернем n-грамм отсрочки:

>>> p_n = [m1, m2, m3]
>>> weights = (0.25, 0.25, 0.25)
>>> math.exp(sum(w*math.log(p_i) for w, p_i in zip(weights, p_n)))
0.7071067811865475

В любом случае, при использовании предложения BLEU на действительно вольном переводе или коротких предложениях всегда гладко:

# Laplacian smoothing, with altered weights.
>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], weights=(0.5, 0.5), smoothing_function=smoother.method1)
0.09128709291752769

# Canonical multi-bleu smoothing, aka method4().
>>> sentence_bleu([[1,2,3,4]],[5,6,8,1], smoothing_function=smoother.method4)
0.19564209772076444

@alvations Спасибо за отличный код в NLTK. Мы в какой-то степени использовали его, экспериментируя с системами моделирования диалоговых ответов (или чат-ботами) в True AI .

Я определенно вижу смысл предупреждать пользователя о неиспользовании функции сглаживания, когда любая из n-граммов оценивается как 0. Прочитав функции сглаживания, мы теперь начали использовать функцию сглаживания 1 по умолчанию.

Однако я все же был очень удивлен, когда получил результаты с отключенной функцией сглаживания в тех случаях, когда она не находила никаких n-граммов определенного порядка. Я получил результаты, которых не ожидал, глядя на уравнения в Chen et.

Основное уравнение, используемое для расчета оценки BLEU (без сглаживания), которое вы разместили выше (уравнение 2 в Chen et al. ), И которое вы используете в коде:

где p_m определяется как (уравнение 3 в Chen et. al ):

Однако вы вычисляете p_m как:

В заключение вы используете другое уравнение, чем то, что вы рекламируете. Вы упоминаете в документации, что функция сглаживания 0 означает, что сглаживание не используется, и что в этом случае вы используете базовые уравнения для вычисления BLEU. Это просто неправда. Вы не используете базовое уравнение, вы используете модифицированную версию для вычисления p_m по сравнению с тем, что упоминается в документе.

Ага, вот и ошибка между оригинальным BLEU и уравнением (2) из ​​Chen and Cherry (2014).

Обратите внимание, что в исходном BLEU (1992) p_n необходимо переместить из десятичного пространства в логарифмическое, что приводит к ошибке математической области, когда p_n = 0:

Так что в этом случае используются «хитрости», чтобы преодолеть все крайние случаи. У multi-bleu.perl была другая стратегия, чтобы преодолеть это .

Но в формулировке Чена и Черри это произведение десятичных знаков с обратной степенью N, т. Е.

Это позволит избежать ошибок математических доменов без пространства журнала и exp. Но, возможно, это также приведет к новой волне ошибок, скорее всего, из-за проблем с переполнением, а может и нет. Пока unittest для BLEU проверяется, я думаю, что реализация этого тоже будет поощрением; P

Я предполагаю, что решение пойти с исходной формулировкой log + exp, потому что мы решили пойти с реализацией, которая следует ближе к реализации multi-bleu.perl и mteval-v13a.pl которая больше ориентирована на требование от пользователей сглаживания, когда совпадающие числа меньше 4, чего обычно не бывает при машинном переводе.

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

Или кто-нибудь проголосует за реализацию NLTK, чтобы вместо этого использовать формулировку Chen and Cherry (2014)?

Но теперь я понимаю, почему у вас может возникнуть больше проблем при использовании BLEU в диалоговых системах, где предложения / сегменты могут быть очень короткими.

Фактически, после реализации SmoothingFunction я всегда хотел, чтобы по умолчанию был установлен сглаженный BLEU. Но мы должны решить, какой метод сглаживания использовать по умолчанию, поэтому мы используем негладкий BLEU со странными откатами и предупреждениями.

Кстати, для личного использования я бы всегда устанавливал сглаживание по умолчанию на SmoothingFunction().method4 .

Два уравнения фактически идентичны с математической точки зрения (кроме w_n). Разница в том, что нужно быть осторожным с тем, что делать при оценке log (0). Здесь log (0) должен быть оценен как -inf (или что-то подобное, если -inf недоступен в библиотеке, используемой для обработки математики). Оценка его до 0 нарушает математику, как указано выше. Оценка его до 0 означает, что конкретное предложение получит более высокий балл BLEU, если не было найдено n-граммов определенного порядка, чем если бы был найден только один n-грамм, что противоречит интуиции.

Оценка log (0) никогда не бывает простой. И с этим нужно обращаться в индивидуальном порядке. math решает эту проблему, бросая ValueError и доверяя пользователю обрабатывать его должным образом. numpy с другой стороны, по умолчанию возвращает -inf вместе с RuntimeWarning . Есть аргументы как за, так и против использования -inf в качестве результата.

Однако в этом конкретном приложении определенно правильным было бы использовать -inf.

Если коротко взглянуть на код, то правильный способ исправить это - изменить то, что следует за этим оператором else, на:

p_n_new.append(sys.float_info.min)

или

return [sys.float_info.min]

Предупреждение можно сохранить, если хотите.

Это может быть альтернативно объединено с elif _emulate_multibleu and i < 5: заявления и есть только один else на данном этапе.

@bamattsson Точно, это sys.float_info.min , вычисление среднего геометрического также должно измениться.

Из примера в моем предыдущем комментарии , добавление sys.float_info.min может быть плохой идеей в зависимости от корпуса.

>>> m1 = modified_precision([[1,2,3,4]], [2,3,4,5], 1)
>>> m2 = modified_precision([[1,2,3,4]], [2,3,4,5], 2)
>>> m3 = modified_precision([[1,2,3,4]], [2,3,4,5], 3)
>>> m4 = modified_precision([[1,2,3,4]], [2,3,4,5], 4)
>>> [m1, m2, m3, m4]
[Fraction(3, 4), Fraction(2, 3), Fraction(1, 2), Fraction(0, 1)]
>>> [m1, m2, m3, sys.float_info.min]
[Fraction(3, 4), Fraction(2, 3), Fraction(1, 2), 2.2250738585072014e-308]
>>> p_n = [m1, m2, m3, sys.float_info.min]
>>> weights = (0.25, 0.25, 0.25, 0.25)
>>> math.exp(sum(w*math.log(p_i) for w, p_i in zip(weights, p_n)))
8.636168555094496e-78

Это привело к сбою unittest на https://nltk.ci.cloudbees.com/job/pull_request_tests/430/TOXENV=py35-jenkins , jdk = jdk8latestOnlineInstall / testReport / junit / nltk.translate / bleu_score / offer_bleu / и, следовательно, невыполнение проверок на № 1844.

Исправление ОЧЕНЬ зависит от того, над каким набором данных работает. Это НИКОГДА не должно быть проблемой в корпусе BLEU, потому что на уровне корпуса всегда было предположение, что между гипотезами и их ссылками есть не менее 1 4-граммовых совпадений.

Поэтому я предлагаю переделать ваше исправление как флаг / аргумент / параметр, который можно было бы передать предложению bleu. И если хотите, сделайте флаг по умолчанию и все равно вернитесь к технике отсрочки ngram, когда она выключена. Было принято много соображений, чтобы сделать выбор в пользу отсрочки ngram. Возможно, чтение №1330 тоже может помочь.

Собственно, внимательно смотрим на PR. Верно ли, что результаты тестов с использованием предлагаемого вами исправления дают тот же результат, что и emulate_multibleu=True ?

Решено в № 1844

Спасибо @alvations , @bamattsson , @benleetownsend