Nltk: Intégration de la prise en charge des vecteurs de mots pour NLTK

Créé le 7 août 2018  ·  19Commentaires  ·  Source: nltk/nltk

Les vecteurs de mots ne sont actuellement pas pris en charge par NLTK.

Les intégrer serait une très bonne étape car nous les traitons souvent dans nos tâches quotidiennes. Cela ferait alors de NLTK un guichet unique pour de nombreux autres types de fins de PNL

Voici une liste de vecteurs de mots qui peuvent être intégrés avec NLTK :
mot2vec
Gant

Si ce problème est résolu, alors je peux faire le PR .

Commentaire le plus utile

Existe-t-il un moyen d'intégrer des vecteurs de mots sans reproduire de gros morceaux de gensim ?

Tous les 19 commentaires

@alvations , @stevenbird s'il vous plaît commentez et donnez votre point de vue

Existe-t-il un moyen d'intégrer des vecteurs de mots sans reproduire de gros morceaux de gensim ?

@stevenbird ,

Pouvez-vous s'il vous plaît expliquer ce que vous proposez de faire?

Gensim est fantastique. À propos de la seule chose que nltk fournit généralement qui manque à Gensim, ce sont les éléments de gestion des ensembles de données, ce qui est peut-être ce à quoi 53X voulait en venir? Nltk pourrait ajouter quelque chose comme ça. En fait, j'ai implémenté quelque chose de ce style dans mon propre projet, finntk : https://github.com/frankier/finntk/tree/master/finntk/emb (c'est un peu différent de nltk - il extrait des ensembles de données "on- demande"). Pour les vecteurs de mots, il y a généralement l'étape supplémentaire de conversion au format KeyedVector pour des recherches rapides à partir du disque.

Cependant, je ne suis pas sûr que nltk soit nécessairement la meilleure maison pour cela. Il y a quelques personnes qui essaient de démarrer des "gestionnaires de paquets de données". Voir le manifeste : http://juan.benet.ai/data/2014-03-04/the-case-for-data-package-managers , et un exemple : https://quiltdata.com/ -- je me demande s'il y a la possibilité d'utiliser quelque chose comme ça?

En termes de référentiels de vecteurs de mots. Il y a aussi : http://vectors.nlpl.eu/repository/

@stevenbird , citant la doc SpaCy :

SpaCy est capable de comparer deux objets et de prédire à quel point ils sont similaires. Prédire la similitude est utile pour créer des systèmes de recommandation ou signaler les doublons. Par exemple, vous pouvez suggérer un contenu utilisateur similaire à celui qu'ils consultent actuellement, ou étiqueter un ticket d'assistance comme un doublon s'il est très similaire à un ticket déjà existant.

>

Nous pouvons construire et intégrer quelque chose comme ça dans NLTK, et je pense que cela pourrait être le bon PR où nous commençons à intégrer la fonctionnalité DL à NLTK.

Nous pouvons construire quelque chose de similaire dans NLTK et pour cela, nous devrons peut-être ajouter les inclusions de mots pré-entraînées dans le NL

Mon idée est peut-être très grossière, mais avec un peu de raffinement de votre part, je pense que nous pouvons en tirer quelque chose ..

@53X que

Disons pour commencer incorporant quelque chose comme phrase2vec, doc2vec etc. afin qu'étant donné des quantités comparables, nous puissions dire à quel point elles sont similaires.

Je pense que vous suggérez quelque chose comme https://radimrehurek.com/gensim/models/keyedvectors.html ?


Ma valeur de 2 cents. Sans les hacks de code cython ou c, nous ne pourrons pas atteindre la vitesse gensim / spacy . À moins qu'il n'y ait un moyen de différencier le code entre NLTK et gensim, il n'y a aucune bonne utilité à ce que deux bibliothèques soient trop similaires.

De plus, nous n'avons pas trouvé de bon canal de distribution pour la gestion des données.

Personnellement, (par intermittence depuis un certain temps), j'ai essayé différents styles de reformatage du nltk.corpus mais je n'ai pas trouvé de conception d'API dotée d'un réseau de diffusion de contenu (CDN) approprié pouvant gérer la gestion des données avec élégance.

J'ai exploré Kaggle Datasets, dropbox et zendoo et même la distribution de données en tant que packages PyPI. Mais il y a toujours une limite de

  • dans quelle mesure les données peuvent-elles être disponibles ? C'est-à-dire qu'il faut que l'utilisateur crée un compte ? combien de sauts/étapes à effectuer avant que l'utilisateur puisse obtenir les données à lire par nltk.corpus . Jusqu'à présent, rien ne vaut la simplicité d'extraction de fichiers zip github.

  • comment suivre la priorité des données ? C'est-à-dire que lorsque les données sont mises à jour, existe-t-il une version ? Comment pouvons-nous revenir en arrière pour suivre les modifications et éventuellement avoir une sorte de mécanisme de blâme git pour déboguer ce qui n'a pas fonctionné si cela se produit

  • quel soutien le CDN va-t-il apporter ? Il y a toujours un cas de limite de bande passante pour le téléchargement de fichiers et également une limite de taille de stockage. Je pense que ce dernier est bon marché mais le précédent est difficile.


Mon autre valeur de 2 cents. Je pense que nous avons besoin d'un meilleur canal de distribution pour les ensembles de données NLTK existants avant même de penser à redistribuer les incorporations de mots à lire dans une API Pythonic.

Si quelqu'un souhaite vraiment résoudre le problème de la distribution des données et y consacrer du temps comme étape préalable à l'incorporation d'incorporations word/doc, envoyez un ping ici et je vous contacterai par e-mail pour en discuter.

@alvations , ce problème semble intéressant et si ce n'est un problème pour aucun d'entre vous, puis-je le relever comme un défi ?

Mes excuses à vous tous si la suggestion suivante semble stupide ou absurde.

En fait, je pensais créer un référentiel séparé (à l'intérieur de NLTK) pour tous ces ensembles de données. Je pense qu'il serait alors possible de résoudre le problème mentionné par @alvations . Plus important encore, nous pourrions alors directement télécharger (cloner) tout ce qui est nouveau (ensembles de données ou modèles pré-entraînés comme GloVe ) dans la machine locale à l'aide de simples codes python (c'est ce que je pense... je n'ai peut-être pas raison :P ). Le problème susmentionné de connexion par un utilisateur peut également être évité.

Oups, désolé .... il s'avère que NLTK a déjà un référentiel appelé nltk_data .

@alvations Vos objections s'appliquent-elles à Quilt ?

@alvations que diriez-vous de publier vos commentaires sur les ensembles de données sur nltk-dev.

Continuons la conversion sur la distribution du jeu de données sur https://groups.google.com/forum/?hl=en#!topic/nltk -dev/LjThWkAthwc


@ 53X il n'y a pas de suggestions stupides/absurdes, juste comment nous pouvons le rendre constructif et savoir quelles sont les prochaines étapes =)

@frankier Je ne connais pas les données de Quilt mais cela ressemble à un espace potentiel pour distribuer les données.

Clôture du problème inactif.

Cette page vous a été utile?
0 / 5 - 0 notes