- Bei LLMs sind Tokenizer-Erstellung und Modelltraining getrennt, sodass bestimmte Tokens wie
_SolidGoldMagikarpunerwartetes Verhalten auslösen können - Im Kern des Problems stehen untertrainierte Tokens, die zwar im Tokenizer-Vokabular vorhanden sind, im Training aber kaum oder gar nicht vorkamen; sie werden oft als „glitch tokens“ bezeichnet
- Die Studie schlägt eine Methode vor, die Tokenizer-Analyse, Metriken auf Basis der Einbettungsgewichte des Modells und Prompting-Techniken kombiniert, um solche Tokens automatisch zu finden
- Solche Tokens verschwenden die Vokabularkapazität eines Tokenizers mit fester Größe und können Eingabe- und Ausgabelänge, Inferenzkosten sowie Halluzinationen oder beschädigte Ausgaben beeinflussen
- In Tool-Use- und Agent-Umgebungen, in denen externe Daten gesucht und verarbeitet werden, ist die Erkennung und Bereinigung untertrainierter Tokens direkt mit der Sicherheit und Robustheit bereitgestellter Modelle verknüpft
Diskrepanz zwischen Tokenizer und Modelltraining
- Die meisten Komponenten von LLMs werden unüberwacht auf großen Datenmengen trainiert, der Tokenizer wird jedoch meist separat mit eigenen Algorithmen und auf kleineren Datensätzen gelernt
- GPT-2 legte viele Grundlagen des heutigen Transformer-basierten Sprachmodellierens, und auch das auf Byte-Pair Encoding (BPE) basierende Tokenisierungs-Framework wurde breit übernommen
- Die BPE-Tokenisierung wandelt Eingabetext in eine Sequenz von Teilwort-Tokens um und führt anhand fester Merge-Regeln wiederholt Zusammenführungen benachbarter Tokenpaare durch
- Diese Merge-Regeln werden mit einem gierigen Lernalgorithmus auf kleineren Datensätzen gelernt, deren Repräsentativität zu den Trainingsdaten des LLM passen muss
Wie glitch tokens entstehen
- Wenn Tokenizer und Modelltraining getrennt sind, kann es vorkommen, dass einige Tokens während des Modelltrainings kaum oder gar nicht auftreten
- Wenn solche Tokens in der Eingabe enthalten sind, können sie unerwartetes Verhalten wie Halluzinationen oder beschädigte Ausgaben verursachen
- Die Studie unterscheidet solche Tokens als under-trained tokens oder untrained tokens
untrainedwird nur verwendet, wenn es klare Hinweise darauf gibt, dass ein bestimmtes Token in den Trainingsdaten des Modells nicht vorkam- Allgemein werden sie auch als „glitch tokens“ bezeichnet
- Als bekanntes Beispiel wird das Token
_SolidGoldMagikarpgenannt
Grenzen bestehender Tokenisierungsverfahren und Alternativen
- Neuere Forschung behandelt auch Ansätze, die Tokenisierung ganz zu entfernen und auf rohe Byte-Eingaben zu wechseln, doch diese Wahl verursacht meist Kosten bei der Inferenzgeschwindigkeit
- Diese Geschwindigkeitskosten können durch spezielle Architekturen in den ersten und letzten Layern oder durch variable Berechnung in mittleren Layern ausgeglichen werden
- Solche Ansätze sind bislang nicht breit übernommen worden, und die meisten modernen Modelle verlassen sich weiterhin auf Teilwort-Tokenisierung
- Die wichtigste Alternative zu BPE ist das Unigram-Verfahren, das trotz Studien mit besseren Ergebnissen als BPE allgemein nicht weit verbreitet ist
Praktische Probleme untertrainierter Tokens
- Untertrainierte Tokens belegen in Tokenizern mit fester Größe Vokabularkapazität, die sonst häufiger vorkommenden Tokens zur Verfügung stehen könnte
- Dadurch können Möglichkeiten verloren gehen, die durchschnittliche Ein- und Ausgabelänge sowie die Inferenzkosten zu senken
- Wenn solche Tokens absichtlich oder versehentlich in Eingabedaten enthalten sind, können sie unerwünschte Modellausgaben erzeugen und nachgelagerte Anwendungen stören
- Da Tool Use von LLMs und Agenten, die externe Daten suchen und verarbeiten, zunimmt, wird Robustheit gegenüber unerwarteten oder bösartigen Eingaben immer wichtiger
- Wenn ein Modell aus seiner Trainingsverteilung herausgedrängt wird, könnten solche Tokens auch zur Umgehung von Guardrails missbraucht werden
Ansatz zur automatischen Erkennung und veröffentlichtes Tooling
- Es gab bereits Arbeiten, die solche Tokens durch Modell- und Tokenizer-Analyse aufspüren wollten, doch es fehlte an zuverlässigen automatisierten Verfahren, die über verschiedene Modelle hinweg konsistent funktionieren
- Die Studie kombiniert drei Methoden, um problematische Tokens zu identifizieren
- Tokenizer-Analyse
- Metriken auf Basis der Einbettungsgewichte des Modells
- Prompting-Techniken
- Diese Methoden wurden auf mehrere populäre und kürzlich veröffentlichte Modelle mit offenen Gewichten angewendet; außerdem wurde kurz untersucht, wie sie sich auf geschlossene Modelle ausweiten lassen
- Ein allgemeines Analysetool, das mit Hugging Face-Modellen kompatibel ist, sowie modellspezifische Detailergebnisse wurden ebenfalls veröffentlicht
1 Kommentare
Kommentare auf Hacker News
Das Computerphile-Video zu Glitch-Tokens von vor einem Jahr war gut: https://www.youtube.com/watch?v=WO2X3oZEJOA
Man sollte nicht nur nach untertrainierten Tokens suchen; Tokens sind im Grunde die erste Schicht eines neuronalen Netzes, daher sollte man auch in allen Gewichten aller anderen Schichten nach Ungleichgewichten in den Trainingsdaten suchen
Wenn man solche Gewichte findet, könnte es sinnvoll sein, Gewichte zu löschen, durch die kaum Daten fließen; dadurch würde das Modell kleiner oder es könnte der Generalisierung helfen
Ich habe auch neuere Papers gesehen, die SparseGPT zitieren und eine Sparsity von etwa 70–80 % erreichen; ziemlich beeindruckend
Schwer zu glauben, dass ein Modell eines kanadischen Unternehmens untertrainierte Tokens im Zusammenhang mit Hockey enthielt, selbst wenn sie auf Deutsch waren
Spaß beiseite: ziemlich cool, und ich freue mich auf ein besseres Verständnis davon, wie sich Tokenisierung auf Modelle auswirkt. Besonders auffällig ist die Entdeckung, dass viele der frühen Open-Source-Modelle Probleme mit Carriage Returns haben; je nach Datenquelle können Carriage Returns gar nicht so selten vorkommen
Es gibt auf Random-Matrix-Theorie basierende Trainingsdiagnosen, die die Spektraldichte der Korrelationsmatrix der Gewichte nutzen
Man passt die Spektraldichte jeder Schicht an ein abgeschnittenes Potenzgesetz an und betrachtet sie als gut trainiert, wenn der Potenzgesetz-Exponent Alpha etwas größer als 2 ist
https://jmlr.org/beta/papers/v22/20-410.html
Ist die Lösung nicht einfach, den Tokenizer auf demselben Korpus wie das LLM zu trainieren? Ich verstehe nicht so recht, warum Tokenizer-Wiederverwendung so verbreitet ist. Weiß jemand mehr?
Beim BPE-Verfahren können sehr seltene Tokens entstehen, wenn ein Token mit einem anderen zusammengeführt wird. Wenn es die Tokens X und Y gibt und auf fast jedes X ein Y folgt, erzeugt der BPE-Prozess ein neues Token XY, entfernt aber das bestehende Token X nicht; dadurch wird X untertrainiert
Um das zu lösen, bräuchte man wohl einen ausgefeilteren Merge-Algorithmus als gieriges Zusammenführen
Erstens, wenn man das Pretraining eines Modells fortsetzen will, statt von Grund auf neu zu beginnen. Manche wissen allerdings vielleicht nicht, dass man Modellgewichte auch beim Training mit einem neuen Tokenizer ziemlich einfach wiederverwenden kann. Ich habe dazu einen Artikel geschrieben: https://umarbutler.com/how-to-reuse-model-weights-when-train...
Zweitens ist es für Endnutzer bequem. Einen sehr großen Korpus zu tokenisieren und in Chunks aufzuteilen kann lange dauern; wenn man ihn einmal mit dem GPT2-Tokenizer verarbeitet hat und dann mehrere Modelle auf denselben Daten trainieren kann, ist es praktisch, nicht alles erneut tokenisieren zu müssen
Andernfalls könnte man doch einfach aus einer statistischen Stichprobe des Korpus ein Token-Histogramm berechnen
Kein böser Wille gegenüber SolidGoldMagikarp, der sich im counting subreddit viel Mühe gegeben hat, aber solche Teile werden aus späterem Training ausgeschlossen. Zu diesem Zeitpunkt ist der Tokenizer jedoch bereits Teil der API, sodass ein Wechsel auf eine neue Version andere Dinge kaputtmachen würde; am Ende bleiben unnötige Tokens im Vokabular
Der Titel des Papers ist wirklich großartig