- Byte Latent Transformer (BLT) ist eine Byte-Level-LLM-Architektur, die mit rohen Bytes ohne Tokenisierung mit festem Vokabular trainiert wird und dennoch im großen Maßstab eine Leistung auf dem Niveau tokenisierungsbasierter LLMs erreicht
- Der Kern besteht darin, Bytes nicht als feste Tokens, sondern als dynamisch große Patches zu gruppieren und Positionen mit hoher Entropie des nächsten Bytes mehr Rechenaufwand und Modellkapazität zuzuweisen
- Meta führte eine FLOP-kontrollierte Skalierungsstudie bis zu 8B Parametern und 4T Trainings-Bytes durch und validierte damit die Skalierbarkeit von Byte-Level-Modellen
- Je vorhersehbarer die Daten sind, desto längere Patches werden gewählt, um die Trainings- und Inferenz-Effizienz zu steigern; auch bei Inferenz und Long-Tail-Generalization zeigen sich qualitative Verbesserungen
- Bei festen Inferenzkosten zeigt der BLT-Ansatz, bei dem Patch-Größe und Modellgröße gemeinsam wachsen, besseres Skalierungsverhalten als tokenisierungsbasierte Modelle
Die von BLT vorgeschlagene Byte-Level-LLM-Struktur
- Byte Latent Transformer (BLT) ist eine Byte-Level-LLM-Architektur, die statt einer Tokenisierung auf Basis eines festen Vokabulars rohe Bytes als Eingabeeinheit verwendet
- Sie erreicht in großen Setups eine Leistung auf dem Niveau tokenisierungsbasierter LLMs und zeigt zudem deutliche Verbesserungen bei Inferenz-Effizienz und Robustheit
Dynamische Patches werden zur Recheneinheit
- BLT kodiert Bytes in dynamisch große Patches und nutzt diese als zentrale Recheneinheit
- Die Aufteilung in Patches erfolgt dynamisch auf Basis der Entropie des nächsten Bytes
- Punkten mit höherer Datenkomplexität werden mehr Rechenaufwand und Modellkapazität zugewiesen
- Wenn die Daten vorhersehbar sind, werden längere Patches gewählt, um den Rechenaufwand zu reduzieren
FLOP-kontrollierte Skalierungsexperimente
- Meta führte für Byte-Level-Modelle eine FLOP-kontrollierte Skalierungsstudie durch
- Der Versuchsrahmen reichte bis zu 8B Parametern und 4T Trainings-Bytes
- Die Ergebnisse zeigen, dass auch Modelle, die ohne festes Vokabular direkt auf rohen Bytes trainiert werden, skalierbar sind
Ergebnisse zu Effizienz und Generalisierung
- Die dynamische Auswahl längerer Patches verbessert sowohl die Trainings-Effizienz als auch die Inferenz-Effizienz
- In qualitativen Ergebnissen zeigen sich Verbesserungen bei der Inferenz und der Long-Tail-Generalization
- Bei festen Inferenzkosten zeigt BLT ein besseres Skalierungsverhalten als tokenisierungsbasierte Modelle
- Dabei werden Patch-Größe und Modellgröße gleichzeitig erhöht
Materialien
- Download the Paper: Paper zu Byte Latent Transformer herunterladen
1 Kommentare
Hacker-News-Kommentare
Paper: https://scontent-sjc3-1.xx.fbcdn.net/v/t39.2365-6/470135129_...
In dem Sommer, als BERT erschien, arbeitete ich bei einem Startup, das mit zeichenbasierten CNN-Modellen Klassifikation machte.
Im Team dachten wir viel über alternative Repräsentationsformen nach; die anderen Teammitglieder bevorzugten Wortvektoren, ich aber nicht besonders. In den Dokumenten, mit denen wir arbeiteten, tauchten häufig Wörter auf, die nicht im Wörterbuch standen, diese Wörter waren wichtig, und sie wegzuwerfen hätte meiner Meinung nach zum Scheitern geführt.
Da auch wir ein „Foundation Model“ bauten, war nicht nur problematisch, dass Wörter im finalen Modell außerhalb des Vokabulars lagen, sondern auch, dass sie bereits in der teureren Foundation-Model-Phase Out-of-Vocabulary waren.
Mit zeichenbasierten Modellen funktionierte die Klassifikation recht gut, aber weil man das Speichern eines „Wörterbuchs“ in einem neuronalen Netz nicht als gute Nutzung neuronaler Netze ansah, waren die Erwartungen an Tokens groß.
Gleichzeitig war ich überzeugt, dass Ansätze wie Word2Vec keine Zukunft hatten, und hatte deshalb auch einmal ein früheres Projekt verlassen, in dem wir ein RNN darauf trainierten, gefälschte Abstracts von PubMed-Fallberichten zu schreiben, um ein Foundation Model für Textverständnis zu bauen.
Als Byte-Pair Encoding aufkam, sagte ich in einem Meeting, dass es von den Tokenisierungsverfahren, die wir uns angesehen hatten, das erste sei, das ich unterstützen könne; daran erinnere ich mich noch gut.
Trotzdem denke ich ehrlich gesagt immer noch, dass es schön wäre, auf Zeichenebene arbeiten zu können.
Tokens sind ein Provisorium. Meist funktionieren sie gut, aber wenn nicht, fällt es deutlich auf.
[1] https://arxiv.org/abs/2103.06874
In der Realität bilden und verwenden Menschen täglich Wörter, die nicht im Wörterbuch stehen, um zu kommunizieren. Zum Beispiel steht „notify“ im Wörterbuch, aber „notifier“ im Sinne von „ein Mittel, jemanden zu benachrichtigen“ nicht; Code, der E-Mail-Benachrichtigungen verschickt, wird dann zu einem „email notifier“. Danach geht es weiter mit Notifiern für Textnachrichten, Sprachanrufe, Callcenter-Rückrufe und so weiter.
Jede Branche und jede Organisation hat Fachjargon, maßgeschneiderte Wörter außerhalb des Wörterbuchs und wenig unterscheidungskräftige Abkürzungen.
Ich sehe nicht, wie Machine-Learning-Ausgaben nützlich sein sollen, wenn sie reale Kommunikation nicht bewältigen und nur im Labor bereinigte Antworten innerhalb des Wörterbuchs ausgeben können.
Ich hoffe, das setzt sich durch. Tokenizer sollten verschwinden.
Interessant ist, dass es eine Hierarchie ist, aber nur mit zwei Ebenen. Mehr Ebenen aufzubauen wirkt wie eine natürliche Richtung für Folgearbeiten.
Zur Einordnung: Ich habe diesen Kommentar auch unter einem anderen verwandten Beitrag[1] hinterlassen, und der Autor antwortete so:
„Ich bin einer der Autoren :), ich halte das für eine gute Richtung, die man untersuchen sollte! Abgesehen davon, dass es für einen einzigen Anlauf etwas viel Arbeit wird, muss man aber auch vorsichtig sein, wie man das FLOP-Budget über die gesamte Hierarchie verteilt. Bei zwei Ebenen kann man eine Ebene (Byte-/lokaler Encoder) FLOP-effizient und die andere Ebene (Patch-/globaler Encoder) FLOP-intensiv machen. Außerdem müsste man herausfinden, wie man Patches zu größeren Einheiten bündelt. Trotzdem gibt es von hier aus viele mögliche Richtungen!“
[1] https://news.ycombinator.com/item?id=42413430
Um Patches zu erzeugen, sagt ein kleines Modell die Wahrscheinlichkeit des nächsten Zeichens in der Eingabezeichenkette voraus.
Wenn die Eingabezeichenkette „Lazy dog jumped over a fence.“ lautet, sagt das Modell die Wahrscheinlichkeit jedes Zeichens voraus.
Zum Beispiel könnte es zu 100 % sicher sein, dass das nächste Zeichen „a“ ist, oder „a“ könnte 10 % und „b“ 10 % haben, und so weiter.
Dann werden diese Zeichenschätzungen zusammengebündelt. Wie viele Zeichen? So viele, dass die Gesamtunsicherheit jedes Bündels, also die Entropie, ungefähr ähnlich ist.
So entsteht ein Patch oder „Token“.
Es wird nur die Entropie des nächsten Bytes verwendet und geprüft, ob sie einen Schwellenwert überschreitet (globale Einschränkung) oder um einen anderen Schwellenwert größer ist als die Entropie des unmittelbar vorherigen Bytes (approximative Monotonie-Einschränkung).
Deshalb können lange, repetitive Sequenzen, wie in Anhang E gezeigt, zu pathologisch langen Patches führen.
Was mich wirklich interessiert, ist das kleine CNN-Modell auf Byte-Ebene mit 2-Byte-Kontext in Abbildung 3(f), das im restlichen Paper überhaupt nicht erwähnt wird.
Kürzlich erschienener verwandter Beitrag:
Meta FAIR teilt neue Forschung, Modelle und Datensätze - https://news.ycombinator.com/item?id=42412360 - Dezember 2024, 61 Kommentare
Heißt das, dass das Einzige, was dem Modell etwas beibringt, also der Loss, nur eine Wahrscheinlichkeitsvorhersage im Raum einzelner Bytes ist?
Wenn ich das nicht missverstanden habe, reicht das allein aus; das wirkt ziemlich vielversprechend.
Wenn ich es richtig verstehe, entfernt dieser Ansatz nicht nur Tokenisierung, sondern auch Sampling, oder?
Sampling kann bei LLMs ein Ärgernis sein, ermöglicht aber auch interessante Anwendungen, etwa Grammatikzwang, damit ein Modell immer gültiges JSON ausgibt, das Anpassen der Temperatur für vielfältigere Verteilungen oder XTC-Sampling.
Was wäre das entsprechende Gegenstück in BLT?
Mir fällt nur ein, dem Decoder erlaubte/verbotene Bytes als zusätzliche Eingabe zu geben und das Decoding zu wiederholen, bis eine gültige Ausgabe entsteht; vielleicht gibt es aber einen einfacheren und offensichtlicheren Ansatz.
Wie bei BPE-basierten Modellen berechnet man in der Ausgabeschicht einfach nur über die erlaubten Bytes den Softmax und sampelt daraus.
Heißt das, dass AI auch auf Binärdaten vortrainiert werden kann?
Wir denken, dass es das Endziel ist, dass AI für uns Code schreibt, aber vielleicht kann sie auf viel einfachere Weise die Kontrolle übernehmen.
Interessant, wie sehr linguistische und erfahrungsbasierte Ansätze aus der Mode gekommen sind.
Menschen lesen, obwohl sie es könnten, normalerweise nicht Buchstabe für Buchstabe. Sie haben Wortstämme und verstehen auch Flexionen. Tokenisierung bildet diese Erfahrung nicht nach; das sieht man besonders an den Tokens im Vokabular von LLMs, und dasselbe gilt für Zeichen- oder Byte-Encoding.
Menschen parsen Wörter auf verschiedene Arten. Sie können einen ganzen Satz auf einmal erfassen, Phrasen lesen, Wort für Wort lesen oder neue Wörter Buchstabe für Buchstabe laut entschlüsseln.
Sehr wenige Papers behaupten ausdrücklich, eine Methode sei gut, weil sie nachbildet, wie Menschen eine Aufgabe ausführen oder die Welt wahrnehmen.
Je stärker wir von LLMs abhängig werden, desto eher werden wir die Modelle wohl näher an unsere Erfahrung anpassen wollen. Dann werden auch die Fehler, die die Modelle machen, verständlicher sein.
Der Satz „Anders als Tokenisierung hat BLT kein festes Vokabular für Patches“ bedeutet, wenn ich ihn richtig verstehe, dass das Patch-Vokabular vor dem Training nicht bekannt ist.
Nachdem das Training ein Patch-Vokabular etabliert hat, würde man für die Inferenz vermutlich dasselbe feste Vokabular verwenden. Wenn nicht, weiß ich nicht, wie es funktionieren könnte.
Stimmt das?