Nltk: Améliorer la tokenisation des expressions multi-mots en incluant un "partitionneur python"

Une petite note/addendum sur/à ceci, puisque :
a) J'ai omis de le mentionner dans le message initial ; et
b) il semble digne de mention :
Python Partitioner utilise déjà NLTK.

Merci d'avoir suggéré le partitionneur ; Je ne l'avais pas vu avant. Sur la base de l'article, il semble qu'il effectue une segmentation MWE en s'appuyant sur les probabilités de n-gramme de données d'entraînement étiquetées MWE et sur de grandes ressources lexicales (principalement extraites de Wiktionary/Wikipedia). Contrairement à la plupart des approches statistiques, elle évite des calculs coûteux, reportant essentiellement la plupart du travail aux comptages de fréquences et aux recherches dans le dictionnaire. L'outil prend en charge 18 langues PARSEME, dont l'anglais et une variété de langues européennes.

Si cela devait être ajouté à NLTK, quelle devrait être sa taille ? Le référentiel du partitionneur fait > 100 Mo. S'il y a de gros fichiers de données, je suppose que l'utilisateur devra utiliser nltk.download() pour les demander.

Le chargement des ressources de données volumineuses en mémoire doit prendre du temps afin d'exécuter le système. Est-ce juste quelques secondes ou plus ?

Notez que cela va bien au-delà de la « tokenisation » standard en termes d'unités lexicales orthographiques, donc ce n'est pas un substitut à la tokenisation ou à la lemmatisation de base (#1214).

Malheureusement, je devrai transmettre ces questions en raison des contraintes de temps et du manque d'expérience opérationnelle avec le partitionneur, du moins dans un avenir prévisible. Pardon! Mais peut-être que @jakerylandwilliams ou @andyreagan peuvent répondre à ces questions

Merci @no-identd et @nschneid d'avoir

@nschneid , votre évaluation du modèle est correcte. Les fichiers de données volumineux peuvent prendre quelques secondes ; le seul décalage de charge que j'ai vu concerne l'ensemble de données EN Wikipedia, mais cette ressource peut être omise à un coût relativement faible pour les performances pour une charge essentiellement instantanée. Il serait probablement logique de définir la charge EN par défaut pour simplement omettre Wikipedia.

Je suis heureux de poursuivre la discussion et de répondre à toute autre question.

@jakerylandwilliams @nschneid Si nous

En fait, si https://github.com/jakerylandwilliams/partitioner est déjà un package de travail en Python, il n'est peut-être pas nécessaire de porter/réimplémenter le code. Les utilisateurs peuvent facilement choisir d'utiliser le tokenizer directement depuis le partitionneur.

Si nous voulons les "bonnes choses" comme MWE, nous pouvons prendre les répertoires géographiques du partitionneur, empaqueter en quelque sorte la ressource MWE au lieu de porter l'intégralité du référentiel du partitionneur dans NLTK. Si les responsables du partitionneur souhaitent conserver le code dans NLTK plutôt que dans leur package pypi, alors je pense que cela vaut la peine de porter du code à partir de bibliothèques Python tierces.

@alvations Je suis d'accord avec sa suggestion. Mais, je vois l'implémentation NLTK que nous devons réécrire selon la structure et le test NLTK. Nous avons également besoin de code pour portable en python2 et python3 pour en faire les normes de codage de la bibliothèque NLTK.

@alvations et @ NeelShah18 , je suis d'accord pour dire que retirer et https://github.com/jakerylandwilliams/partitioner et celui qui convient probablement le mieux à NLTK a été mentionné en haut du fil par @no-identd :

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

Si cela présente un intérêt, je peux certainement aider à l'exécution de certaines des tâches nécessaires.

??