Nltk: Интеграция поддержки векторных слов для NLTK

@alvations , @stevenbird, пожалуйста, прокомментируйте и

Есть ли способ интегрировать векторы слов без репликации больших кусков gensim?

@stevenbird , ты имеешь в виду без импорта пакета gensim?

Не могли бы вы объяснить, что вы предлагаете делать?

Генсим фантастический. Почти единственное, чего обычно не хватает в Gensim в nltk, - это средства управления наборами данных. Возможно, именно к этому и стремился 53X? Nltk мог бы добавить что-то подобное. Фактически, я реализовал что-то в этом стиле в моем собственном проекте finntk: https://github.com/frankier/finntk/tree/master/finntk/emb (он немного отличается от nltk - он извлекает наборы данных "на- требование"). Для векторов слов обычно есть дополнительный этап преобразования в формат KeyedVector для быстрого просмотра с диска.

Однако я не уверен, что nltk - лучший вариант для этого. Несколько человек пытаются запустить «менеджеры пакетов наборов данных». См. Манифест: http://juan.benet.ai/data/2014-03-04/the-case-for-data-package-managers и пример: https://quiltdata.com/ - интересно есть ли возможность использовать что-то подобное?

Что касается репозиториев векторов слов. Также там: http://vectors.nlpl.eu/repository/

@stevenbird , цитата из документа SpaCy:

SpaCy может сравнивать два объекта и прогнозировать, насколько они похожи. Прогнозирование сходства полезно для построения систем рекомендаций или отметки дубликатов. Например, вы можете предложить пользовательский контент, который похож на то, что он сейчас просматривает, или пометить заявку в службу поддержки как дублирующую, если она очень похожа на уже существующую.

>

Мы можем построить и интегрировать что-то подобное в NLTK, и я думаю, что это может быть правильным PR, когда мы начнем интегрировать функциональность DL в NLTK.

Мы можем построить что-то подобное в NLTK, и для этого нам может потребоваться добавить предварительно обученные вложения слов в NL.

Моя идея может быть очень грубой, но если вы немного доработаете вас, ребята, я думаю, что мы сможем что-то из этого сделать ...

@ 53X что именно вы предлагаете делать?

Для начала предположим, что мы добавили что-то вроде offer2vec, doc2vec и т. Д., Чтобы, учитывая сопоставимые количества, мы могли сказать, насколько они похожи.

Я думаю, вы предлагаете что-то вроде https://radimrehurek.com/gensim/models/keyedvectors.html ?

Мои 2 цента стоят. Без взлома кода cython или c мы не сможем достичь скорости gensim / spacy . Если нет способа различать код между NLTK и gensim, нет смысла делать две библиотеки слишком похожими.

Кроме того, мы не придумали хороший канал распространения для управления данными.

Лично (время от времени, время от времени) я пробовал разные стили переформатирования nltk.corpus но я не придумал дизайн API, который имел бы подходящую сеть доставки контента (CDN), которая могла бы элегантно обрабатывать управление данными.

Я изучал наборы данных Kaggle, dropbox и zendoo и даже распространение данных в виде пакетов PyPI. Но всегда есть предел

• насколько доступны данные? Т.е. нужен ли пользователь для регистрации аккаунта? сколько прыжков / шагов нужно сделать, прежде чем пользователь сможет получить данные для чтения nltk.corpus . До сих пор ничто не сравнится с простотой извлечения из zip-файлов github.

• как отслеживать приоритет данных? Т.е. при обновлении данных версия есть? Как мы можем вернуться к отслеживанию изменений и, возможно, иметь какой-то механизм git blame для отладки того, что пошло не так, если это произойдет

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

Другие мои 2 цента стоят. Я думаю, что нам нужен лучший канал распространения для существующих наборов данных NLTK еще до того, как думать о перераспределении встраиваемых слов для чтения в Pythonic API.

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

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

Мои извинения всем вам, ребята, если следующее предложение звучит глупо или абсурдно.

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

Ой, извините .... оказывается, у NLTK уже есть репозиторий с именем nltk_data .

@alvations Относятся ли ваши возражения к Quilt?

@alvations, как насчет размещения ваших комментариев о наборах данных в nltk-dev.

Давайте продолжим преобразование набора данных на https://groups.google.com/forum/?hl=en#!topic/nltk -dev / LjThWkAthwc.

@ 53X нет никаких глупых / абсурдных предложений, просто как мы можем сделать его конструктивным и зная, что делать дальше =)

@frankier Я не знаком с данными Quilt, но похоже, что это потенциальное пространство для распространения данных.

Закрытие неактивной проблемы.