Nltk: Verbessern Sie die Tokenisierung von Multi-Word-Ausdrücken, indem Sie "Python-Partitionierer" einschließen

Eine kleine Anmerkung/Nachtrag dazu, da:
a) Ich habe es im ersten Post versäumt, es zu erwähnen; und
b) es scheint erwähnenswert:
Python Partitioner verwendet bereits NLTK.

Danke für den Vorschlag eines Partitionierers; Ich hatte es noch nie gesehen. Basierend auf dem Papier sieht es so aus, als ob es eine MWE-Segmentierung durchführt, die sich auf MWE-gekennzeichnete Trainingsdaten-n-Gramm-Wahrscheinlichkeiten und große lexikalische Ressourcen (hauptsächlich aus Wiktionary/Wikipedia) stützt. Im Gegensatz zu den meisten statistischen Ansätzen vermeidet es teure Berechnungen und verlagert den Großteil der Arbeit im Wesentlichen auf Häufigkeitszählungen und Wörterbuch-Suchen. Das Tool unterstützt 18 PARSEME-Sprachen, darunter Englisch und eine Vielzahl europäischer Sprachen.

Wenn diese zu NLTK hinzugefügt werden soll, wie groß müsste sie dann sein? Das Partitionierungsrepo ist >100 MB groß. Wenn große Datendateien vorhanden sind, gehe ich davon aus, dass der Benutzer nltk.download() , um sie anzufordern.

Es muss einige Zeit dauern, die großen Datenressourcen in den Speicher zu laden, damit das System ausgeführt werden kann – sind es nur ein paar Sekunden oder länger?

Beachten Sie, dass dies in Bezug auf orthografische lexikalische Einheiten weit über die Standard-"Tokenisierung" hinausgeht und daher kein Ersatz für die grundlegende Tokenisierung oder Lemmatisierung ist (#1214).

Leider muss ich diese Fragen aus Zeitgründen & fehlender Betriebserfahrung mit Partitioner zumindest auf absehbare Zeit weitergeben. Verzeihung! Aber vielleicht kann entweder @jakerylandwilliams oder @andyreagan diese Fragen beantworten

Danke @no-identd und @nschneid für die

@nschneid , deine Einschätzung des Modells ist richtig. Große Datendateien können einige Sekunden dauern; Die einzige Lastverzögerung, die ich gesehen habe, ist für den EN Wikipedia-Datensatz, aber diese Ressource kann mit relativ geringen Kosten für die Leistung für eine im Wesentlichen sofortige Last weggelassen werden. Es wäre wahrscheinlich sinnvoll, die Standard-EN-Last so einzustellen, dass Wikipedia einfach weggelassen wird.

Gerne führe ich die Diskussion weiter und stelle alle weiteren Fragen.

@jakerylandwilliams @nschneid Wenn wir Wikipedia weglassen und sogar den Standard-Downloader von nltk verwenden, ist er mit Python2 und Python3 kompatibel. Ich kann für die Unabhängigkeit von mehreren Plattformen (python2 und python3) des Partitionierungscodes helfen.

Wenn https://github.com/jakerylandwilliams/partitioner bereits ein funktionierendes Paket in Python ist, muss der Code möglicherweise nicht portiert/reimplementiert werden. Benutzer können den Tokenizer ganz einfach direkt vom Partitionierer verwenden.

Wenn wir das "gute Zeug" wie MWE wollen, können wir die Gazetteer vom Partitioner nehmen, die MWE-Ressource irgendwie verpacken, anstatt das gesamte Partitioner-Repository in NLTK zu portieren. Wenn die Betreuer von partitioner den Code in NLTK statt in ihrem pypi-Paket pflegen möchten, dann lohnt es sich meiner Meinung nach, Code aus Python-Bibliotheken von Drittanbietern zu portieren.

@alvations Ich stimme seinem Vorschlag zu. Aber ich sehe die NLTK-Implementierung, die wir gemäß der NLTK-Struktur neu schreiben und testen müssen. Wir benötigen auch Code für Portable in Python2 und Python3, um die Codierungsnormen der NLTK-Bibliothek zu erstellen.

@alvations und @NeelShah18 , ich stimme zu, dass das Herausziehen und https://github.com/jakerylandwilliams/partitioner und das wahrscheinlich am besten geeignete für NLTK wurde am Anfang des Threads von @no-identd erwähnt:

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

Wenn dies von Interesse ist, kann ich sicherlich bei der Ausführung einiger der notwendigen Aufgaben helfen.

🤔