Ich habe einen Tokenizer geschrieben, und Deutsch wurde teuer

Jede Zahl, die man zu einem Modell bekommt, ist in Tokens angegeben. Kontextfenster, Preis pro Million, Rate Limit. Ich hatte mir „ein Token sind ungefähr vier Zeichen" gemerkt, damit überschlagen und nie genauer hingeschaut.

Dann habe ich Byte-Pair-Encoding implementiert, als Ergänzung zum Zählmodell aus dem letzten Post, einen deutschen Satz eingetippt, und die Tokenzahl ging irgendwo hin, wo ich sie nicht erwartet hatte.

BPE ist eine Schleife, die das häufigste Paar zusammenzieht

Am Anfang ist jedes Wort eine Liste einzelner Zeichen. Dann wiederholt sich das hier:

1. Zähle im gesamten Korpus jedes benachbarte Symbolpaar.
2. Such das häufigste.
3. Zieh es überall zusammen, sodass daraus ein Symbol wird.

Jede Runde fügt dem Vokabular genau einen Eintrag hinzu. Dreißig Runden auf einem Absatz ergeben Fragmente wie th, the, ing. Fünfzigtausend Runden auf einem großen Korpus ergeben die meisten gängigen englischen Wörter als einzelne Tokens.

Das ist der ganze Algorithmus. Eingeführt wurde er für maschinelle Übersetzung in Sennrich et al., 2015, und er steckt bis heute unter den gebräuchlichen Tokenizern, mit reichlich Technik drumherum.

Beim Kodieren werden diese Merges in ihrer Lernreihenfolge wieder abgespielt. Das Vokabular ist also kein Wörterbuch, das jemand kuratiert hat, sondern eine Fossilienschicht dessen, was im Trainingskorpus häufig war.

Was ich nicht verstanden hatte: Vertrautheit ist der Preis

Die Figur unten auf dieser Seite trainiert auf einem editierbaren Korpus und kodiert, was du eingibst. Zwei Dinge sieht man nach ungefähr einer Minute Spielen.

Wörter, die der Korpus oft gesehen hat, fallen auf ein oder zwei Tokens zusammen. Wörter, die er nie gesehen hat, zerfallen in Einzelzeichen, weil kein Merge je bei ihnen angekommen ist. In der Voreingabe steht kitten, das im Trainingstext nicht vorkommt — man kann zusehen, wie es neben the und little auseinanderfällt.

Eine Wortanfangs-Markierung ändert alles. Echte Tokenizer halten the am Wortanfang von denselben drei Buchstaben mitten im Wort getrennt. Deshalb springen Tokenzahlen, wenn du in einem Prompt an Leerzeichen oder Zeichensetzung etwas änderst. Das Verhalten war mir vorher aufgefallen, ohne dass ich einen Grund dafür hatte.

Kosten hängen also nicht daran, wie lang dein Text ist, sondern daran, wie sehr er dem Korpus ähnelt, auf dem die Merges gelernt wurden.

Und genau da wird Deutsch teuer

Ich schreibe diesen Blog auf zwei Sprachen. Gleiche Argumente, gleicher Aufbau, ungefähr gleich viele Zeichen. Dass die beiden für ein Modell nicht gleich groß sind, war mir nie in den Sinn gekommen.

Deutsch macht zwei Dinge, mit denen eine überwiegend auf Englisch gelernte Merge-Schleife schlecht zurechtkommt. Es baut Komposita — ein langes Wort, wo Englisch drei kurze nimmt, und diese Komposita sind einzeln selten, auch wenn jeder Bestandteil häufig ist. Und es hat Zeichen, die schlicht seltener vorkommen, also gehen weniger Merges für sie drauf.

Die Richtung sieht man in der Figur. Wie viel Gewicht das trägt, will ich allerdings sauber einordnen: Mein Spielzeug trainiert auf drei Zeilen Text und übertreibt deshalb. Ein produktiver Tokenizer hat erheblich mehr Deutsch gesehen und kommt deutlich besser damit klar.

Der Effekt selbst ist aber real und gemessen, nicht nur eine Eigenart meines Spielzeugs. Petrov et al. (2023) haben genau das über Sprachen und Tokenizer hinweg untersucht und festgestellt, dass der Abstand groß genug ist, um sowohl bei den Kosten als auch beim effektiven Kontextfenster ins Gewicht zu fallen. Sie ordnen es als Fairness-Problem ein, nicht bloß als Effizienzfrage. Das halte ich für richtig.

Die Prüfung, die ich tatsächlich empfehlen würde, dauert zwei Minuten: Nimm einen Absatz, den du in beiden Sprachen geschrieben hast, und jag ihn durch den echten Tokenizer des Modells, das du benutzt. Mein Spielzeug zeigt dir die Form der Antwort. Deine Zahl bekommst du nur vom echten.

Was das an den Zahlen ändert

Drei Dinge, die ich für fix gehalten hatte und die es nicht sind:

• Ein Kontextfenster ist keine Textmenge. Es ist eine Textmenge in einer bestimmten Sprache, in einem bestimmten Stil. Dasselbe Fenster fasst weniger Deutsch als Englisch, und weniger Code mit ungewöhnlichen Bezeichnern als Code mit gewöhnlichen.
• Preis pro Million Tokens ist kein Preis pro Million von irgendwas Sichtbarem. Zwei Dokumente, die gleich lang aussehen, können in der Verarbeitung spürbar unterschiedlich kosten.
• Seltene Tokens sind nicht nur eine Kostenfrage. Ein Wort, das in sechs Fragmente zerfällt, sind sechs Positionen, die das Modell erst wieder zusammensetzen muss, bevor es mit der Bedeutung überhaupt arbeiten kann.

Nichts davon ist ein Grund, nicht mehr auf Deutsch zu schreiben. Es ist ein Grund, nicht mehr in Zeichen zu überschlagen, was ich bis dahin getan hatte.

Next

Das naheliegende Experiment ist, einen Tokenizer auf meinen eigenen Texten zu trainieren, diesen Blog in beiden Sprachen, und zu sehen, welche Merges er lernt, die ein allgemeiner nicht lernt. Ob dabei etwas Brauchbares herauskommt oder nur eine unterhaltsame Vokabelliste, weiß ich noch nicht.

Danach das, worum ich seit dem Zählmodell herumlaufe: etwas Kleines wirklich trainieren und den Bewertungsaufbau aus meinen Agent-Loops darauf richten. Gleicher Apparat, viel kleinerer Gegenstand.

Falls du in einer Sprache arbeitest, die nicht Englisch ist: Hast du mal nachgemessen, was deine Prompts im Vergleich zur englischen Fassung kosten, oder hast du wie ich in Zeichen überschlagen?