Nltk: Улучшите токенизацию выражений из нескольких слов, включив "разделитель Python"

Небольшое примечание / дополнение к этому, поскольку:
а) Я не упомянул об этом в исходном посте; и
б) кажется заслуживающим упоминания:
Python Partitioner уже использует NLTK.

Спасибо, что предложили разделитель; Раньше я этого не видел. Основываясь на документе, похоже, что он выполняет сегментацию MWE, опираясь на вероятности n-грамм обучающих данных с меткой MWE и большие лексические ресурсы (в основном извлеченные из Wiktionary / Wikipedia). В отличие от большинства статистических подходов, он позволяет избежать дорогостоящих вычислений, по сути, перекладывая большую часть работы на подсчет частоты и поиск по словарю. Инструмент поддерживает 18 языков PARSEME, включая английский и ряд европейских языков.

Если это будет добавлено к NLTK, насколько большим он должен быть? Репозиторий разделителя составляет> 100 МБ. Если есть большие файлы данных, я предполагаю, что пользователю придется использовать nltk.download() для их запроса.

Для загрузки системы в память требуется время, чтобы загрузить большие ресурсы данных в память - это всего пара секунд или больше?

Обратите внимание, что это выходит далеко за рамки стандартной «токенизации» с точки зрения орфографических лексических единиц, поэтому он не заменяет базовую токенизацию или лемматизацию (# 1214).

К сожалению, мне придется отказаться от этих вопросов из-за нехватки времени и отсутствия опыта работы с разделителем, по крайней мере, в обозримом будущем. Прости! Но, возможно, на эти вопросы ответят @jakerylandwilliams или @andyreagan.

Спасибо @ no- identifyd и обращение ; Рад, что модуль заинтересовал. В настоящее время мы работаем над некоторыми улучшениями серверной части, данных и модели для Python 3. Если перенос текущей версии в nltk имеет смысл, я думаю, что это будет довольно просто реализовать.

@nschneid , ваша оценка модели верна. Большие файлы данных могут занять несколько секунд; единственная задержка при загрузке, которую я видел, относится к набору данных EN Wikipedia, но этот ресурс может быть опущен с относительно небольшими затратами для производительности по существу для мгновенной загрузки. Вероятно, имеет смысл установить загрузку EN по умолчанию, чтобы просто опустить Википедию.

Я рад продолжить обсуждение и ответить на любые другие вопросы.

@jakerylandwilliams @nschneid Если мы опускаем Википедию и даже используем загрузчик по умолчанию от nltk, то он совместим с python2 и python3. Я могу помочь в обеспечении многоплатформенной независимости (python2 и python3) кода разделителя.

На самом деле, если https://github.com/jakerylandwilliams/partitioner уже является рабочим пакетом на Python, возможно, нет необходимости в переносе / повторной реализации кода. Пользователи могут легко выбрать использование токенизатора непосредственно из разделителя.

Если нам нужны «хорошие вещи» вроде MWE, мы можем взять географические справочники из модуля разметки, каким-то образом упаковать ресурс MWE вместо того, чтобы переносить весь репозиторий модуля разметки в NLTK. Если разработчики разделов хотят поддерживать код в NLTK, а не в своем пакете pypi, то я думаю, что стоит потратить усилия на перенос кода из сторонних библиотек Python.

@alvations Я согласен с его предложением. Но я вижу, что реализацию NLTK мы должны переписать в соответствии со структурой NLTK и протестировать. Нам также нужен код для переносимости в python2 и python3, чтобы сделать его нормой кодирования библиотеки NLTK.

@alvations и @ NeelShah18 , я согласен, что извлечение и переупаковка географических справочников и ресурсов сегментации MWE в соответствии со структурой NLTK и нормами кодирования будет наиболее целесообразным для интеграции. Внутри https://github.com/jakerylandwilliams/partitioner есть несколько моделей и утилит, и одна, вероятно, лучше всего подходящая для NLTK, была упомянута в верхней части потока @ no-identifyd:

https://noisy-text.github.io/2017/pdf/WNUT01.pdf

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

🤔