Nltk: Обсуждение: воскрешение модели Ngram

Было бы неплохо иметь рабочую библиотеку n-грамм в NLTK. SRILM имеет несколько оболочек Python для вывода, но имеет ограниченную лицензию. KenLM имеет оболочку Python для выполнения логических выводов, но у нее есть зависимости при компиляции. Ни один из них не поддерживает оценку. Так что в настоящее время для Python NLP не существует хорошо протестированных инструментов n-gram.

@anttttti Спасибо за отзыв, я чувствую себя очень мотивированным, чтобы отправить патч, видя весь этот спрос на эту функцию :)

Есть ли у вас какие-либо мысли по поводу конкретных проблем, которые я опубликовал?

Расширенные методы сглаживания легко реализовать, если вы поймете, что они различаются только тем, как определены дисконтирование и интерполяция. В более ранних статьях и большей части описаний в учебниках модели кажутся более сложными, чем они есть на самом деле, поскольку раньше люди не так хорошо понимали связи. Не должно быть необходимости в отдельных модулях, только настройка сглаживания. Старые модели отсрочки, которые не были правильно нормализованы, в наши дни не используются, см. Большой обзор Джошуа Гудмана «Немного прогресса в языковом моделировании». http://arxiv.org/pdf/1602.02332.pdf стр. 63 суммирует некоторые варианты дисконтирования и интерполяции для случая униграммы, модели более высокого порядка используют то же самое рекурсивно. Кнезер-Ней немного сложнее с модифицированными откатами.

В большинстве случаев сглаживание не так важно. При достаточном количестве данных даже оптимизированный Кнезер-Ней не лучше, чем Stupid Backoff. Так что было бы неплохо иметь в Python n-граммы высокого порядка с любым базовым сглаживанием. Lidstone или Jelinek-Mercer для каждого заказа должны работать идеально.

Проблема 1) Я думаю, что было бы очень полезно иметь утилиту для создания словаря и цензуры токенов OOV. Это позволило бы исправить многие глупые ошибки, которые разочаровывали пользователей старых версий. Я прилагаю код, который делает это (не стесняйтесь использовать или копировать)
lm.txt

Выпуск 2а) Считаю, что еще полезно иметь Кнезер-Ней; его обычно учат, и полезно иметь эталонную реализацию.
Проблема 2b) Меня беспокоит, что связывание ProbDist делает это намного сложнее, чем должно быть. Было бы проще сохранить оценку вероятности в рамках языковой модели для таких вещей, как KN. Для других моделей можно использовать ProbDist.

@anttttti " легко реализовать, если вы поймете, что они различаются только тем, как определены дисконтирование и интерполяция_"

@ezubaric "_Issue 2b) Я беспокоюсь, что объединение ProbDist делает это намного сложнее, чем должно быть_"

Хотя я какое-то время не смотрел на этот код, мне кажется, что оба эти утверждения верны.

Если я правильно помню, ConditionalProbDist (и в более общем плане ProbDist) нормализованы слишком рано для использования в сглаженных моделях ngram. Например, хотя мы знаем, насколько вероятно слово в данном контексте, нам трудно рассуждать о самих контекстах (я считаю, что более ранний патч попытался исправить эту проблему - несмотря на все усилия, это было немного неуклюже [https: //github.com/nltk/nltk/pull/800]).

ИМХО, все это немного перестроено.

@afourney

ИМХО, все это немного перестроено.

Бог с ним! Я пытался заставить эту работу работать вечно (я отправил № 800, и да, это было совсем не элегантно), и я также начинаю думать, что движущихся частей слишком много, чтобы это было разумно.

@ezubaric огромное спасибо за этот файл, я полностью позаимствовал его дух для рефакторинга.

Основываясь на всех этих отзывах, вот мой новый взгляд на структуру модуля. У нас есть только один класс: model.ngram.NgramModelCounter .

По сути, это несколько счетчиков FreqDist объединенных в понятный интерфейс. _Training_ просто состоит из рекурсивного подсчета количества ngram, а также отслеживания размера словаря (с потенциально «завершением» некоторых из этих подсчетов для предотвращения обновлений после завершения обучения). @alvations Я знаю, что вам нужна реализация trie для этого, но я думаю, что мы можем начать с неэффективного рекурсивного счетчика сейчас и реорганизовать серверную часть позже, поскольку это не должно сильно влиять на интерфейс.

Важно отметить , что этот класс не имеет дело с вероятностями на всех. Это должно сделать вещи значительно проще и в то же время более гибкими. Все, что нужно сделать для добавления вероятностей, - это использовать свой любимый метод ООП (например, наследование или композицию), чтобы написать класс, который использует атрибуты NgramModel для создания собственного метода prob() .

Если у меня будет время, я представлю один (или два!) Примера того, как может работать добавление вероятностей в NgramModelCounter.

Что вы думаете, ребята?

@ Copper-Head, имеющий максимально похожий интерфейс на KenLM, был бы хорош для будущей интеграции: https://github.com/kpu/kenlm/blob/master/python/example.py

Я думаю, что после выхода стабильной версии NgramModel от NLTK я могу попробовать рефакторинг kenlm оболочки, чтобы использовать интерфейс, аналогичный интерфейсу NLTK, как то, что мы сделали для scikit-learn .

Эта функция также поможет в заполнении: https://github.com/nltk/nltk/blob/develop/nltk/util.py#L381

Я думаю, что @ Copper-Head предлагает класс, который скоординированно считает униграммы, биграммы, триграммы и т. Д., Что удобно для использования в последующих языковых моделях. В этом случае я думаю, что kenlm API еще не применяется. (Я могу ошибаться, но из опубликованного примера не похоже, что kenlm API имеет дело с необработанным подсчетом частоты)

Я думаю, что также стоит рассмотреть API минимальной языковой модели, который потребляет эти подсчеты ngram. Как предлагает @ Copper-Head, это будет подкласс или, еще лучше, полностью отдельный интерфейс (позволяющий использовать совершенно разные реализации, такие как https://www.projectoxford.ai/weblm). Здесь, я думаю, было бы разумно принять kenlm API, но думаю, что _any_ ngram LM-интерфейс должен быть достаточно простым, чтобы можно было легко писать адаптеры.

Я думаю, что минимальному API ngram действительно нужны только методы для (1) вычисления условной вероятности токена с учетом контекста или последовательности и (2) отчета о размере и составе известного словаря. Почти все остальное можно вычислить с помощью вспомогательных методов, включая вычисления совместной вероятности, а также генерацию языка. Эти помощники могут быть или не быть частью интерфейса.

Хм, интересный момент. Я задаюсь вопросом, может ли отслеживание этих показателей для GT немного замедлить тренировку и без надобности для людей, которые не хотят использовать это конкретное сглаживание. Я думаю, что было бы разумнее сделать минимум в базовом классе NgramCounter а затем просто расширить его метод обучения (или __init__ ) на подкласс, специализированный для Good-Turing, или даже в реализация API ngram, предназначенная для вычисления вероятностей Гуд-Тьюринга.
Но я только сажусь, чтобы написать кое-что из этого, так что, возможно, это не станет проблемой в конце концов.

Извините, похоже, я случайно удалил сообщение. Чтобы восполнить недостающий контекст для будущих читателей: я думаю, было бы хорошо рассмотреть общие методы сглаживания при разработке NgramModelCounter API. Например, для сглаживания Гуда-Тьюринга (а также сглаживания Виттена-Белла и т. Д.) Важно разрешить пользователям запрашивать количество _ видов_, наблюдаемых один, два или N раз.

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

Мне нравится идея иметь просто объект counts, который затем можно запрашивать с помощью подклассов, реализующих определенные методы сглаживания.

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

Принято к сведению. У меня есть идеи, как с этим справиться. Я отправлю PR сегодня позже.

PR # 1351 доступен !! Приносите вопросы / придирки :)

@ Copper-Head - насколько мы далеки от возможности объединить это с основной веткой?

Глядя на свой список дел, я бы сказал, что мне нужно 2-3 дня целенаправленной работы.
Учитывая, что я вернулся к работе над этим в свободное от учебы и дневной работы время, я бы отдал ему где-то от 2 недель до месяца, прежде чем я закончу со всеми _мы_ нерешенными проблемами. Это, естественно, не учитывает случайные вещи, которые могли бы быть доведены до моего сведения в то время.

@ Copper-Head @jacobheil и пользователи / разработчики NLTK, которые интересуются языковыми моделями N-грамм.

Точно так же, как проверить текущее состояние подмодуля model .

• Как вы думаете, он готов отправить его в ветку develop / master?
• Это все еще тема, которую люди активно обсуждают и хотят видеть на НЛТК?

Думаю, в НЛТК однозначно стоит иметь; это основная часть, когда я
учить НЛП.

Поддерживает ли НЛТК сейчас глубокие LM? Совместим ли этот API с этим?

Джордан Бойд-Грабер

Голосовой: 920.524.9464
[email protected]

http://boydgraber.org

Во вторник, 3 октября 2017 г., в 23:32 alvations [email protected] написал:

@ Медная голова https://github.com/copper-head @jacobheil
https://github.com/jacobheil и пользователи / разработчики NLTK, которые заинтересованы в
N-грамматические языковые модели.

Так же, как проверить текущее состояние подмодуля модели.

• Как вы думаете, он готов протолкнуть это в разработку / освоить?
  ветвь?
• Это все еще тема, которой люди активно занимаются и которую хотят видеть?
  НЛТК?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/nltk/nltk/issues/1342#issuecomment-334041035 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAhoqh5oxzo2Y9mp88I8uwy4lmyNz9Amks5sovxngaJpZM4H4nGe
.

Привет - я хотел бы использовать «старую» возможность языковой модели в NLTK. В какой последней версии все еще есть предварительно обученная языковая модель (для английского языка)?

Для тех, кто нашел эту тему, я как бы собрал подмодуль, содержащий старый код модели.

https://github.com/sleepyfoxen/nltk_model

@stevenbird, я думаю, мы можем наконец закрыть это :)

Чтобы получить конкретный отзыв о существующей реализации, люди могут открыть отдельные вопросы.

@ Медная голова, да, я согласен. Поздравляю! :)