Nltk: Diskussion: Wiederbelebung des Ngram-Modells

Es wäre schön, eine funktionierende N-Gramm-Bibliothek in NLTK zu haben. SRILM hat einige Python-Wrapper für Rückschlüsse, aber es hat eine restriktive Lizenz. KenLM verfügt über einen Python-Wrapper zum Ausführen von Inferenzen, weist jedoch Abhängigkeiten bei der Kompilierung auf. Beide haben keine Unterstützung für Schätzungen. Derzeit gibt es also keine gut getesteten N-Gramm-Tools für Python NLP.

@anttttti Danke für das Feedback, ich bin sehr motiviert, einen Patch einzureichen, wenn ich all diese Nachfrage nach dem Feature sehe :)

Hast du zufällig irgendwelche Gedanken zu den spezifischen Problemen, die ich gepostet habe?

Die erweiterten Glättungsmethoden sind einfach zu implementieren, wenn Sie verstehen, dass sie sich nur darin unterscheiden, wie Diskontierung und Interpolation definiert sind. Frühere Arbeiten und viele der Beschreibungen aus Lehrbüchern lassen die Modelle komplizierter erscheinen, als sie sind, da die Leute die Zusammenhänge früher nicht so gut verstanden haben. Es sollten keine separaten Module erforderlich sein, nur die Konfiguration der Glättung. Die älteren Backoff-Modelle, die nicht korrekt normalisiert wurden, werden heutzutage nicht mehr verwendet, siehe Joshua Goodmans "A Bit of Progress in Language Modeling" für eine großartige Zusammenfassung. http://arxiv.org/pdf/1602.02332.pdf Seite 63 fasst einige Auswahlmöglichkeiten für die Diskontierung und Interpolation für einen Unigramm-Fall zusammen, Modelle höherer Ordnung verwenden dasselbe rekursiv. Kneser-Ney ist mit den modifizierten Backoffs etwas kniffliger.

Das Glätten ist für die meisten Anwendungen nicht so kritisch. Bei genügend Daten ist selbst optimiertes Kneser-Ney nicht besser als Stupid Backoff. Es wäre also schön, nur N-Gramme höherer Ordnung in Python mit einer grundlegenden Glättung zur Verfügung zu haben. Lidstone oder Jelinek-Mercer für jede Bestellung sollten einwandfrei funktionieren.

Problem 1) Eine Sache, die ich für sehr nützlich halte, ist ein Dienstprogramm zum Erstellen eines Vokabulars und zum Zensieren von OOV-Token. Das würde viele der dummen Fehler korrigieren, die Benutzer mit den alten Versionen frustrierten. Ich hänge einen Code an, der dies tut (können Sie gerne verwenden oder kopieren)
lm.txt

Ausgabe 2a) Ich denke, dass es immer noch nützlich ist, Kneser-Ney zu haben; es wird allgemein gelehrt und es ist nützlich, eine Referenzimplementierung zu haben.
Problem 2b) Ich befürchte, dass die Kopplung von ProbDist dies viel komplizierter macht, als es sein müsste. Es könnte einfacher sein, die Wahrscheinlichkeitsschätzung für Dinge wie KN im Sprachmodell zu belassen. Für andere Modelle kann es in Ordnung sein, ProbDist zu verwenden.

@anttttti "_Die erweiterten Glättungsmethoden sind einfach zu implementieren, wenn Sie verstehen, dass sie sich nur darin unterscheiden, wie Diskontierung und Interpolation definiert sind_"

@ezubaric "_Ausgabe 2b) Ich mache mir Sorgen, dass die Kopplung von ProbDist dies viel komplizierter macht, als es sein muss_"

Obwohl ich mir diesen Code schon eine Weile nicht mehr angeschaut habe, bin ich der Meinung, dass diese beiden Aussagen wahr sind.

Wenn ich mich richtig erinnere, werden ConditionalProbDist (und allgemeiner ProbDist) zu früh für die Verwendung in geglätteten Ngram-Modellen normalisiert. Obwohl wir beispielsweise wissen, wie wahrscheinlich ein Wort in einem bestimmten Kontext ist, fällt es uns schwer, über die Kontexte selbst nachzudenken (ich glaube, ein früherer Patch hat versucht, dieses Problem zu beheben – trotz aller Bemühungen war es etwas klobig [https: //github.com/nltk/nltk/pull/800]).

IMHO ist das Ganze etwas übertrieben.

@afourney

IMHO ist das Ganze etwas übertrieben.

Und so ist es! Ich habe jetzt schon ewig versucht, das zum Laufen zu bringen (ich habe #800 eingereicht und ja, es war überhaupt nicht elegant) und ich fange auch an zu denken, dass es einfach zu viele bewegliche Teile gibt, um vernünftig zu sein.

@ezubaric vielen Dank für diese Datei, ich

Basierend auf all diesem Feedback ist hier meine neue Sicht auf die Modulstruktur. Wir haben nur eine Klasse: model.ngram.NgramModelCounter .

Dies sind im Grunde mehrere FreqDist Zähler, die in einer übersichtlichen Oberfläche zusammengefasst sind. _Training_ besteht einfach darin, rekursiv die Anzahl der ngrams zu zählen sowie die Vokabelgröße zu verfolgen (wobei einige dieser Zählungen möglicherweise "abgeschlossen" werden, um Aktualisierungen nach dem Training zu verhindern). @alvations Ich weiß, dass Sie dafür eine Trie-Implementierung vorerst mit einem ineffizienten rekursiven Zähler beginnen und das Backend später umgestalten, da dies die Schnittstelle nicht stark beeinflussen sollte.

Entscheidend ist , ist diese Klasse nicht mit Wahrscheinlichkeiten überhaupt beschäftigen. Das soll die Dinge deutlich einfacher und gleichzeitig flexibler machen. Alles, was jeder tun muss, um Wahrscheinlichkeiten hinzuzufügen, ist, seine bevorzugte OOP-Methode (zB Vererbung oder Komposition) zu verwenden, um eine Klasse zu schreiben, die die Attribute von NgramModel verwendet, um ihre eigene prob() Methode zu konstruieren.

Wenn ich Zeit habe, werde ich ein (oder zwei!) Beispiele dafür einreichen, wie das Hinzufügen von Wahrscheinlichkeiten zu NgramModelCounter funktionieren könnte.

Was meint ihr?

@Copper-Head mit einer möglichst ähnlichen Schnittstelle zu KenLM wäre gut für die zukünftige Integration: https://github.com/kpu/kenlm/blob/master/python/example.py

Ich denke, nachdem eine stabile Version von NgramModel von NLTK verfügbar ist, kann ich versuchen, den kenlm Wrapper umzugestalten, um eine ähnliche Schnittstelle wie die von NLTK zu verwenden, wie wir es für scikit-learn .

Diese Funktion würde auch beim Padding helfen: https://github.com/nltk/nltk/blob/develop/nltk/util.py#L381

Ich denke, was @Copper-Head vorschlägt, ist eine Klasse, die Unigramme, Bigramme, Trigramme usw. auf koordinierte Weise zählt, die bequem von nachgelagerten Sprachmodellen verwendet werden kann. In diesem Fall denke ich, dass die kenlm-API noch nicht gilt. (Ich kann mich irren, aber aus dem geposteten Beispiel sieht es nicht so aus, als ob die kenlm API mit Rohfrequenzzählungen umgeht.)

Ich denke, es lohnt sich auch, eine minimale Sprachmodell-API in Betracht zu ziehen, die diese Ngram-Anzahl verbraucht. Wie @Copper-Head vorschlägt, wäre dies eine Unterklasse oder besser noch eine völlig separate Schnittstelle (die sehr unterschiedliche Implementierungen wie https://www.projectoxford.ai/weblm ermöglicht). Hier denke ich, dass es sinnvoll sein kann, die kenlm-API zu übernehmen, aber ich denke, dass _jede_ ngram LM-Schnittstelle so einfach sein sollte, dass Adapter leicht geschrieben werden können.

Ich denke, eine minimale Ngram-API benötigt wirklich nur Methoden, um (1) die bedingte Wahrscheinlichkeit eines Tokens in einem Kontext oder einer Sequenz zu berechnen und (2) über die Größe und Zusammensetzung des bekannten Vokabulars zu berichten. Fast alles andere kann über Hilfsmethoden berechnet werden, einschließlich Berechnungen der gemeinsamen Wahrscheinlichkeit sowie der Spracherzeugung. Diese Helfer können Teil der Schnittstelle sein oder nicht.

Hm, interessanter Punkt. Ich frage mich jedoch, ob das Nachverfolgen dieser Zählungen für GT das Training für Leute, die diese spezielle Glättung nicht verwenden möchten, ein wenig und unnötig verlangsamen könnte. Ich denke, es könnte sinnvoller sein, das Minimum in der Basisklasse NgramCounter und dann einfach ihre Trainingsmethode (oder __init__ ) in einer auf Good-Turing spezialisierten Unterklasse oder sogar in einer Implementierung der ngram API, die auf die Berechnung von Good-Turing-Wahrscheinlichkeiten ausgerichtet ist.
Aber ich setze mich nur hin, um etwas von diesem Zeug aufzuschreiben, also wird es am Ende vielleicht kein Problem.

Entschuldigung, anscheinend habe ich aus Versehen einen Beitrag gelöscht. Um den fehlenden Kontext für zukünftige Leser zu ergänzen: Ich denke, es wäre gut, beim Entwerfen der NgramModelCounter-API gängige Glättungstechniken zu berücksichtigen. Beispielsweise ist es für die Good-Turing-Glättung (sowie die Witten-Bell-Glättung usw.) wichtig, Benutzern zu erlauben, die Anzahl der beobachteten _Spezies_ einmal, zweimal oder N-mal abzufragen.

Bearbeiten: Es sieht so aus, als hätte die FreqDist-Klasse bereits einiges davon (siehe: FreqDist.hapaxes und FreqDist.r_Nr) Ich frage mich, ob es wiederverwendet werden kann? Oder wenn FreqDist der Ausgangspunkt sein soll.

Ich mag die Idee, nur ein counts-Objekt zu haben, das dann mit Unterklassen abgefragt werden kann, die bestimmte Glättungsmethoden implementieren.

Meine einzige Sorge ist, dass das Training Probleme haben wird, wenn wir nicht die Möglichkeit haben, das Vokabular frühzeitig zu korrigieren: Es wird nicht mit Standard-LM-Trainingsprozessen konsistent sein und das Nachverfolgen des gesamten Vokabulars würde dazu führen, dass das Gedächtnis explodiert (was ein riesiges Problem mit dem alten LM auch).

Bemerkt. Ich habe Ideen, wie man das angehen kann. Heute poste ich eine PR.

PR #1351 ist da!! Bringen Sie die Fragen / Nitpicks :)

@Copper-Head – wie weit sind wir davon entfernt, dies wieder in den Hauptzweig zusammenführen zu können?

Wenn ich mir meine To-Do-Liste ansehe, würde ich sagen, dass ich 2-3 Tage konzentrierte Arbeit brauche.
Wenn man bedenkt, dass ich wieder in meiner Freizeit von Schule und Job daran arbeite, würde ich es zwischen 2 Wochen und einem Monat geben, bevor ich mit allen _meinen_ offenen Fragen fertig bin. Dies berücksichtigt natürlich nicht zufällige Dinge, auf die ich in dieser Zeit aufmerksam werden könnte.

@Copper-Head @jacobheil und NLTK-Benutzer/-Entwickler, die sich für N-Gram-Sprachmodelle interessieren.

Genau wie das Einchecken des aktuellen Status des Submoduls model .

• Glauben Sie, dass es bereit ist, es in den Entwicklungs-/Master-Zweig zu bringen?
• Ist es immer noch ein Thema, das die Leute aktiv verfolgen und auf NLTK sehen möchten?

Ich denke, es lohnt sich auf jeden Fall, in NLTK zu sein; Es ist ein Kernstück, wenn ich
NLP unterrichten.

Unterstützt NLTK jetzt Deep LMs? Ist diese API damit kompatibel?

Jordan Boyd-Graber

Stimme: 920.524.9464
[email protected]

http://boydgraber.org

Am Dienstag, 3. Oktober 2017 um 23:32 Uhr schrieb alvations [email protected] :

@Copper-Head https://github.com/copper-head @jacobheil
https://github.com/jacobheil und NLTK-Benutzer/Entwickler, die daran interessiert sind
N-Gram-Sprachmodelle.

Genauso wie das Einchecken des aktuellen Status des Modell-Submoduls.

• Glaubst du, es ist bereit, es in die Entwicklung / den Master zu schieben?
  Zweig?
• Ist es immer noch ein Thema, das die Leute aktiv verfolgen und sehen wollen?
  NLTK?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/nltk/nltk/issues/1342#issuecomment-334041035 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAhoqh5oxzo2Y9mp88I8uwy4lmyNz9Amks5sovxngaJpZM4H4nGe
.

Hallo - Ich möchte die "alte" Funktion des Sprachmodells in NLTK verwenden. Was ist die neueste Version, die noch das vortrainierte Sprachmodell (für Englisch) enthält?

Für diejenigen, die diesen Thread finden, habe ich ein Submodul zusammengebaut, das den alten Modellcode enthält.

https://github.com/sleepyfoxen/nltk_model

@stevenbird Ich denke, wir können das endlich schließen :)

Für konkretes Feedback zur bestehenden Implementierung können die Leute separate Themen öffnen.

@Copper-Head ja, ich stimme zu. Herzliche Glückwünsche! :)