04 Tokenisierung: Wie Maschinen lesen

April 2026 (27520 Words, 153 Minutes)

1. Einführung

Willkommen zu Woche 4 — und zu Akt II: Das Modellverhalten verstehen.

Drei Wochen lang haben Sie KI-Werkzeuge eingesetzt, um Code zu schreiben, Projekte umzustrukturieren und eine echte Open-Source-Codebasis zu erkunden. Sie haben beeindruckende Ergebnisse gesehen — und rätselhafte Fehlschläge. Sie haben Muster bemerkt, die Sie sich nicht erklären konnten. Akt II ist der Ort, an dem wir sie erklären. Nicht in der vollen mathematischen Tiefe der Transformer-Architekturen — das gehört in eine spätere Vorlesung — sondern mit dem praktischen, mechanistischen Verständnis, das Sie benötigen, um effektiv mit diesen Systemen zu arbeiten.

In den nächsten vier Wochen öffnen wir die Black Box, Schicht für Schicht. Am Ende von Akt II wird jede rätselhafte Beobachtung aus Akt I eine Antwort haben.

2. Was Ihre KI-Werkzeuge antreibt

Bevor wir diese Box öffnen, machen wir einen Schritt zurück und stellen eine grundlegende Frage: Was sind diese Werkzeuge eigentlich?

Jedes KI-Coding-Werkzeug, das Sie in Akt I verwendet haben — GitHub Copilot, Claude Code, ChatGPT — läuft auf einem Large Language Model. Sie haben diesen Begriff in Vorlesung 1 gehört, wo wir die Geschichte von AlexNet über Transformer bis zu GPT nachgezeichnet haben. Sie kennen das Wort. Aber was bedeutet es konkret?

Ein LLM ist im Kern eine Maschine zur Vorhersage des nächsten Tokens.

Abstrakt wissen Sie das bereits aus Vorlesung 1: “GPT liest Text von links nach rechts und sagt das nächste Token voraus.” Aber machen wir es konkret an etwas, das Sie tatsächlich erlebt haben. Als Sie Claude Code baten, “eine Funktion zu schreiben, die eine E-Mail-Adresse validiert” — was passierte da?

Das Modell hat die Aufgabe nicht so “verstanden”, wie Sie sie verstehen. Es hat die Funktion nicht geplant, über Randfälle nachgedacht und dann Code geschrieben. Stattdessen hat es etwas viel Einfacheres und viel Seltsameres getan: Es betrachtete alle Tokens in Ihrem Prompt und sagte voraus, welches Token am wahrscheinlichsten als nächstes folgen würde. Dann hängte es dieses Token an die Sequenz an und sagte das nächste voraus. Dann das nächste. Und das nächste.

Token für Token, Zeichen für Zeichen, entstand eine Funktion:

def validate_email(address: str) -> bool:

So sieht das aus der Perspektive des Modells aus. Nachdem das Modell den gesamten Prompt verarbeitet und def generiert hat, berechnet es eine Wahrscheinlichkeitsverteilung über jedes Token in seinem Vokabular — zehntausende Kandidaten — und wählt das wahrscheinlichste aus:

Zur Klarstellung: In diesem Diagramm zeigen wir ganze Wörter als Tokens — validate, check, verify. Was ein Token tatsächlich ist und wie Text in Tokens aufgespalten wird, ist genau das Thema dieser Vorlesung. Stellen Sie sich Tokens vorerst als die Textbausteine vor, mit denen das Modell arbeitet. Die genaue Aufspaltung erweist sich als enorm wichtig, und wir werden sie im Detail untersuchen. Aber der Kernmechanismus ist genau das, was Sie hier sehen: das nächste Token vorhersagen, anhängen, wiederholen. Das ist alles. Keine versteckte Magie, keine geheime Reasoning-Engine im Hintergrund — nur diese Schleife, tausendfach wiederholt.

validate gewinnt mit 82 % — nicht weil das Modell “weiß”, was Validierung bedeutet, sondern weil in seinen Trainingsdaten das Token validate überwältigend häufig auf def folgt, in Kontexten, die E-Mail-Validierung erwähnen. Der Zweitplatzierte check mit 9 % wäre ebenfalls ein vernünftiger Funktionsname. Der lange Schwanz an Alternativen (verify, parse, test) fällt schnell ab. Das Modell zieht aus dieser Verteilung, hängt das gewählte Token an die Sequenz an und wiederholt den Vorgang.

Nicht weil das Modell es geplant hat. Sondern weil die statistischen Muster des Python-Codes in seinen Trainingsdaten jedes nachfolgende Token mit hoher Wahrscheinlichkeit angesichts aller vorhergehenden Tokens hervorbrachten. def ist wahrscheinlich nach der Aufforderung, eine Funktion zu schreiben. validate ist wahrscheinlich angesichts der Aufgabenbeschreibung. _email ist wahrscheinlich nach validate. ( ist wahrscheinlich nach einem Funktionsnamen. Und so weiter. Ein Token nach dem anderen entsteht eine vollständige Funktion.

Codegenerierung ist Textvorhersage. Jede Codezeile, die Copilot vorgeschlagen hat, jede Funktion, die Claude Code geschrieben hat, jedes Refactoring, das ChatGPT vorgeschlagen hat — all das wurde durch genau diesen Mechanismus erzeugt: das wahrscheinlichste nächste Token vorhersagen, anhängen, erneut vorhersagen. Das Modell hat nicht programmiert. Es hat Sequenzen so vervollständigt, dass sie statistisch Code ähneln. Es gibt kein tieferes Geheimnis.

Deshalb ist das Verständnis von LLMs wichtig. Jede Stärke und jede Schwäche Ihrer KI-Werkzeuge lässt sich darauf zurückführen, wie diese Vorhersagemaschine funktioniert. Das Rätsel-Board, das wir gleich aufbauen, ist nicht akademisch — es erklärt das praktische Werkzeugverhalten, das Sie in Akt I täglich erlebt haben.

3. Die ungelösten Rätsel aus Akt I

Mit dieser Einordnung wollen wir explizit festhalten, was wir bisher nicht erklären können. Das sind die Beobachtungen, die Sie während der Vorlesungen 1 bis 3 gemacht haben und für die es damals keine zufriedenstellende Antwort gab. Alle lassen sich auf die Maschine zur Vorhersage des nächsten Tokens zurückführen, die Ihre Werkzeuge antreibt. Wir sammeln sie jetzt, schreiben sie auf und verfolgen sie über die nächsten vier Vorlesungen. Am Ende von Vorlesung 7 wird jedes von ihnen aufgeklärt sein.

Wir verfolgen sie auf dem Mystery Board — einer lebendigen Seite, die zeigt, welche Rätsel gelöst, welche teilweise beantwortet und welche noch offen sind. Schauen Sie nach jeder Vorlesung dort vorbei, um den Fortschritt zu sehen.

Hier sind die Rätsel:

Rätsel 1: Warum hat CLAUDE.md die Ergebnisse verbessert? In Vorlesung 3 haben Sie dem Locust-Projekt eine 50-zeilige Textdatei hinzugefügt, und die Qualität der Modellausgabe verbesserte sich dramatisch. Aber CLAUDE.md ist nur eine Textdatei. Es ist kein Konfigurationspanel, kein Einstellungsdialog, kein Plugin. Wie verändert eine reine Textdatei das Verhalten eines neuronalen Netzes?

Rätsel 2: Warum waren englische Prompts oft besser als deutsche? Mehreren von Ihnen ist aufgefallen, dass dieselbe Frage, einmal auf Englisch und einmal auf Deutsch formuliert, deutlich unterschiedliche Qualität lieferte. Das Modell spricht beide Sprachen. Warum sollte eine die andere schlagen?

Rätsel 3: Warum war kuratierter Kontext besser als alles einzufügen? Die Intuition sagt: Geben Sie dem Modell mehr Informationen, dann sollte es besser werden. Aber in Vorlesung 3 lieferte das Einfügen eines ganzen Repositorys in den Prompt schlechtere Ergebnisse als eine sorgfältig ausgewählte Teilmenge. Mehr war weniger. Warum?

Rätsel 4: Warum hat die KI API-Endpunkte halluziniert? In der Stack-Overflow-Challenge erhielten einige von Ihnen selbstbewusste, detaillierte Beschreibungen von API-Endpunkten, die schlicht nicht existieren. Das Modell sagte nicht “Ich weiß es nicht.” Es erfand etwas Plausibles und präsentierte es als Tatsache. Warum?

Rätsel 5: Warum erzeugten vage Prompts plausiblen Unsinn? In Vorlesung 2 haben Sie Ansatz 1 (ein einzelner vager Prompt) mit Ansatz 3 (strukturierte, spezifische Prompts) verglichen. Ansatz 1 produzierte Code, der richtig aussah, aber voller subtiler Bugs war. Ansatz 3 produzierte Code, der tatsächlich funktionierte. Warum spielt Spezifität so eine große Rolle?

Rätsel 6: Warum funktioniert CLAUDE.md nicht immer? Bei der Vorbereitung von Vorlesung 3 wurde eine 615-zeilige CLAUDE.md in eine Sitzung geladen. Das Modell generierte Code mit Lint-Verstößen, die die CLAUDE.md explizit verbieten wollte. Als es aufgefordert wurde, die Verstöße zu beheben, korrigierte das Modell den Code, übersprang aber den Tagebucheintrag, den die CLAUDE.md ebenfalls verlangte. Warum befolgt das Modell manche Anweisungen und ignoriert andere?

Schreiben Sie diese auf. Wir kommen darauf zurück.

4. Das LLM in einem Bild

Sie haben eine Version dieses Diagramms in den Folien während Akt I gesehen. Schauen wir es uns jetzt richtig an, denn jedes Konzept in Akt II ordnet sich einem bestimmten Teil dieses Bildes zu.

Gehen Sie es von links nach rechts durch:

Links: Eingaben. Ihr System-Prompt, Ihr User-Prompt, Ihr Projektkontext (CLAUDE.md) und alle aktivierten Tools. Das ist alles, womit das Modell arbeiten wird — und alles davon ist Text.

Als Nächstes: der Schritt Text → Tokens. Der gesamte Text muss in Zahlen umgewandelt werden, bevor das Modell ihn verarbeiten kann. Das ist die Tokenisierung — das Thema der heutigen Vorlesung.

In der Mitte: das Transformer-Modell. Das ist das neuronale Netz, das die eigentliche Vorhersage durchführt — die Maschine zur Vorhersage des nächsten Tokens, die wir gerade besprochen haben. Es ist auto-regressiv: Es erzeugt jeweils ein Token, wobei jedes auf allem davor basiert. Vorerst bleibt diese Box verschlossen. Wir öffnen sie in Vorlesung 5.

Rechts: Ausgabe. Entweder reiner Text (die Antwort des Modells) oder ein Tool-Aufruf (eine Aufforderung an das System, eine Datei zu lesen, einen Befehl auszuführen oder etwas zu suchen). Die Ausgabe fließt zurück in den Eingang für die nächste Vorhersage und erzeugt so die Schleife, die Sie unten sehen können — die Token-Sequenz wächst mit jeder Iteration.

Beachten Sie etwas Wichtiges: CLAUDE.md ist in der Eingabebox aufgeführt. Sie gelangt auf genau dieselbe Weise in das Modell wie Ihr Prompt — als Text, der zu Tokens wird. Es gibt keinen speziellen “Anweisungskanal”. Kein Konfigurationssystem. Nur Text, in derselben Pipeline. Behalten Sie das im Hinterkopf.

Heute zoomen wir in diesen Schritt Text → Tokens hinein. Am Ende dieser Vorlesung werden Sie genau verstehen, was dort passiert und warum es für alles Weitere wichtig ist.

5. Warum Text zu Zahlen werden muss

Das Modell sagt also das nächste Token voraus. Aber was ist ein Token? Und warum kann das Modell nicht einfach direkt mit Text arbeiten?

Sie haben bereits eine Intuition aus Vorlesung 1, in der wir Kontextfenster — gemessen in Tokens — und den Aufmerksamkeitsmechanismus des Transformers besprochen haben. Machen wir es jetzt präzise.

Die Antwort ist grundlegend: Neuronale Netze verstehen keinen Text. Sie verstehen Zahlen.

Denken Sie daran, was passierte, als Sie Claude Code baten, diese E-Mail-Validierungsfunktion zu generieren. Das Modell sagte def als nächstes Token voraus, dann validate, dann _email, dann (. Aber im Inneren des Transformers gibt es keine Wörter. Es gibt keine Buchstaben. Es gibt nur Tensoren — mehrdimensionale Arrays von Fließkommazahlen. Jede Operation im Modell — jede Matrixmultiplikation, jede Aufmerksamkeitsberechnung, jede Aktivierungsfunktion — nimmt Zahlen als Eingabe und produziert Zahlen als Ausgabe.

Text ist symbolisch. Der Buchstabe “c” ist ein Symbol. Das Wort def ist eine Folge von Symbolen. Diese Symbole haben keine inhärente numerische Bedeutung. Sie können def nicht mit return multiplizieren und etwas Nützliches erhalten. Sie können nicht das Skalarprodukt zweier Funktionssignaturen berechnen.

Der Transformer benötigt Zahlen. Ihr Prompt liefert Text. Etwas muss diese Lücke überbrücken.

Dieses Etwas ist der Tokenizer. Der Tokenizer sitzt zwischen menschlicher Sprache und maschineller Berechnung. Seine Aufgabe: Text in eine Folge von Ganzzahlen umzuwandeln — Token-IDs —, mit denen das Modell arbeiten kann. Diese Ganzzahlen werden dann in einer großen Tabelle nachgeschlagen, um dichte numerische Vektoren zu erzeugen, die der Transformer tatsächlich verarbeitet.

Hier ist die vollständige Pipeline:

Jedes Stück Text, das Sie an ein KI-Werkzeug senden — Ihr Prompt, Ihre CLAUDE.md, die vorherige Ausgabe des Modells selbst — durchläuft diese Pipeline. Ohne sie gibt es kein Sprachmodell. Tokenisierung ist keine Vorverarbeitung. Sie ist kein optionaler Schritt. Sie ist die erste Schicht der Architektur, und jede Entscheidung, die während der Tokenisierung getroffen wird, wirkt sich auf alles aus, was das Modell danach tut.

Bevor wir in die Details eintauchen, wie Tokenizer funktionieren, verfolgen wir diese gesamte Pipeline von Anfang bis Ende — von Text bis zu einem vorhergesagten Token — anhand eines Spielzeugbeispiels, das klein genug ist, dass Sie jeden Schritt von Hand nachvollziehen können.

6. Die vollständige Reise im Miniaturformat

Bevor wir uns in die Details der Tokenisierung vertiefen, wollen wir die gesamte Vorhersage-Pipeline von Anfang bis Ende nachverfolgen — mit Zahlen, die klein genug sind, dass Sie jeden Schritt per Hand nachvollziehen können. Das ist die vollständige Reise von Text zu vorhergesagtem Token, im Miniaturformat. Wir werden jede Station in den kommenden Wochen im Detail studieren. Heute sehen wir die gesamte Karte.

6.1 Ein Spielzeugvokabular

Stellen Sie sich ein winziges Sprachmodell mit einem Vokabular von nur 10 Tokens vor — die Art Modell, das Sie als Lehrübung bauen könnten. Das Vokabular sieht so aus:

Zehn Wörter. Eine Fantasiewelt, in der Drachen trinken, Zauberer mischen und Trolle zertrümmern. Absurd klein — ein echtes Modell hat 50.000 bis 200.000 Tokens. Aber die Prinzipien sind identisch. Lassen Sie uns diesem Modell einen Satz vorsetzen und beobachten, was geschieht.

Eingabe: <BOS> dragon drinks

6.2 Schritt 1: Von Text zu Token-IDs

Jedes Token wird im Vokabular nachgeschlagen und durch seine Ganzzahl-ID ersetzt. Das Ergebnis ist eine Folge von drei Zahlen:

Drei Tokens aus einem Vokabular von 10. Bisher nichts, womit der Transformer arbeiten kann — das sind nur Ganzzahlen. Diskrete Zahlen ohne mathematische Struktur. Sie können keinen Gradienten durch ein Ganzzahl-Lookup berechnen. Das Modell braucht etwas Reichhaltigeres.

6.3 Schritt 2: Die Embedding-Tabelle

Hier kommt die Embedding-Matrix ins Spiel. Sie ist eine Tabelle mit einer Zeile für jedes Token im Vokabular und einer festen Anzahl von Spalten — der Embedding-Dimension d. In unserem Spielzeugbeispiel hat das Vokabular V = 10 Tokens und wir wählen d = 6. Das ergibt eine 10 × 6 Matrix \(E \in \mathbb{R}^{V \times d}\), wobei jede Zeile ein Vektor aus sechs lernbaren Zahlen ist:

Wenn das Modell die Eingabe (0, 5, 6) verarbeitet, schlägt es die Zeilen 0, 5 und 6 in dieser Tabelle nach. Das ist die gesamte Operation — ein Tabellen-Lookup. Token-ID 0 bildet auf den Vektor [0.12, -0.34, 0.56, -0.78, 0.91, -0.23] ab. Token-ID 5 bildet auf [0.67, -0.11, 0.43, -0.52, 0.28, 0.85] ab. Token-ID 6 bildet auf [-0.39, 0.74, -0.18, 0.61, -0.45, 0.33] ab. Das Ergebnis ist eine 3 × 6 Matrix dichter Vektoren — ein Vektor pro Token in der Eingabesequenz. Das ist es, was der Transformer erhält. Keinen Text. Keine Ganzzahlen. Dichte numerische Vektoren.

Was bedeuten Werte wie 0.67 oder -0.52? Die ehrliche Antwort: nichts, das für einen Menschen interpretierbar wäre. Jede Zahl ist wie Größe, Gewicht oder Alter für eine Person — nur abstrakt. Sie können nicht auf einen einzelnen Wert schauen und sagen “das kodiert Verbhaftigkeit” oder “das kodiert den Buchstaben d.” Jede Dimension erfasst einen Aspekt der Bedeutung des Tokens, den das Modell während des Trainings als nützlich entdeckt hat. Die Bedeutung lebt im Muster der Werte über alle Dimensionen hinweg und in den Beziehungen zwischen den Vektoren verschiedener Tokens.

Schauen Sie sich die Tabelle genau an. Beachten Sie, dass dragon und fire etwas ähnliche Muster aufweisen — beide haben starke positive Werte in d₁ und d₆. Die Verben mixes, drinks und smashes teilen ebenfalls strukturelle Ähnlichkeiten. Diese Ähnlichkeiten sind nicht von einem Menschen programmiert. Sie entstehen aus der Statistik der Trainingsdaten. Niemand schreibt diese Zahlen von Hand — die Embedding-Matrix beginnt als zufälliges Rauschen und wird während des Trainings allmählich angepasst, während das Modell lernt, welche Vektoren zu einer genauen Vorhersage des nächsten Tokens beitragen.

Mathematisch lässt sich die Lookup-Operation als Matrixmultiplikation ausdrücken: Die Eingabe-IDs werden in One-Hot-Vektoren umgewandelt, und die Multiplikation dieser One-Hot-Matrix mit der Embedding-Matrix wählt die richtigen Zeilen aus. Diese Formulierung ist wichtig, weil Matrixmultiplikation differenzierbar ist — Gradienten können rückwärts durch die Embedding-Tabelle fließen, sodass das Modell mit der Zeit bessere Repräsentationen lernen kann.

Beachten Sie den Unterschied zwischen zwei verschiedenen “Vokabularen”. Das Vokabular des Tokenizers bildet jede Token-ID auf die Bytefolge ab, die sie repräsentiert — Token 256 speichert b"th", Token 257 speichert b"the" und so weiter. Das ermöglicht verlustfreies Decodieren zurück in Text. Die Embedding-Tabelle des Modells bildet jede Token-ID auf einen dichten Vektor gelernter Fließkommazahlen ab — Token 256 bildet auf einen 768-dimensionalen Vektor ab. Das sind zwei verschiedene Lookup-Tabellen, die unterschiedlichen Zwecken dienen und über dieselben Token-IDs indiziert werden.

6.4 Schritt 3: Der Transformer (Vorschau)

Nach Schritt 2 haben wir eine 3 × 6 Matrix — drei Zeilen (eine pro Token), sechs Spalten (die Embedding-Dimension). Diese Matrix ist die Eingabe des Transformers. Beobachten Sie, was mit ihrer Form geschieht, während sie durch das System fließt:

Der Transformer nimmt diese 3 × 6 Matrix und verwandelt sie in eine neue 3 × 6 Matrix. Gleiche Form — immer noch drei Zeilen, immer noch sechs Spalten — aber andere Werte. Was hat sich geändert? Jeder Vektor wurde durch den Kontext der anderen umgebenden Vektoren verfeinert. Das Embedding für drinks startete als eine generische Repräsentation des Wortes “drinks”. Nach dem Transformer ist es eine Repräsentation von “drinks im Kontext von vorausgehendem dragon” geworden — ein viel spezifischeres und nützlicheres Signal.

Wie macht der Transformer das? Drei Operationen, gestapelt zu einer Schicht, die sich vielfach wiederholt:

Positionskodierung (einmal, am Anfang): Jeder Vektor erhält Positionsinformation hinzugefügt, sodass das Modell weiß, dass dragon Token 2 ist, nicht Token 3 — die Wortreihenfolge ist wichtig.

Self-Attention: Jedes Token schaut auf jedes andere Token und fragt: Wie relevant bist du für mich? Das Token drinks richtet seine Aufmerksamkeit stark auf dragon — denn wer trinkt, ist wichtig, um vorherzusagen, was als Nächstes kommt.

Feed-Forward-Netz (FFN): Die gesammelten Informationen werden verarbeitet und transformiert.

Das Paar aus Attention + FFN bildet eine Schicht. In GPT-2 wiederholt sich diese Schicht 12-mal. In GPT-3 96-mal. Jede Schicht nimmt die gleichgeformte Matrix der vorherigen Schicht entgegen, verfeinert die Werte weiter und reicht das Ergebnis weiter. Schicht 1 erfasst einfache Muster (welche Wörter in der Nähe stehen). Schicht 50 erfasst abstrakte Beziehungen (welche Art Handlung passiert). Schicht 96 erfasst aufgabenspezifische Absicht (welches Token als Nächstes kommen sollte).

Wir öffnen diese Box vollständig in Vorlesung 5. Vorerst die zentrale Erkenntnis: Die Matrixform bleibt durch jede Schicht gleich (3 × 6), aber die Werte ändern sich. Drei rohe Embedding-Vektoren gehen hinein; drei kontextbewusste Vektoren kommen heraus.

Wenn Sie zuvor neuronale Netze trainiert haben, sollte sich hier etwas falsch anfühlen. In einem voll vernetzten Netz hat die Gewichtsmatrix eine feste Eingangsdimension. Eine Schicht, die 784 Eingaben auf 256 Ausgaben abbildet, akzeptiert immer nur genau 784 Eingaben. Wenn Sie versuchen, 785 zuzuführen, bricht sie zusammen. Wie kann derselbe Transformer also jetzt eine 3 × 6 Matrix und beim nächsten Vorwärtsdurchlauf eine 4 × 6 Matrix akzeptieren?

Die Antwort ist eine zentrale Entwurfsentscheidung des Transformers: Die Gewichte sind für ein einzelnes Token dimensioniert, nicht für die gesamte Sequenz.

Stellen Sie sich eine Fabrik mit einem Förderband vor. Die Maschinen entlang des Bandes — der Bohrer, der Schweißer, der Lackierer — sind fix. Sie ändern sich nicht, wenn Sie mehr Gegenstände auf das Band legen. Jeder Gegenstand durchläuft dieselben Maschinen, einer nach dem anderen. Egal, ob das Band 3 Gegenstände oder 3.000 trägt — jeder bekommt dieselbe Behandlung.

Der Transformer arbeitet genauso. Das FFN ist eine Funktion \(f: \mathbb{R}^d \to \mathbb{R}^d\) — es nimmt einen 6-dimensionalen Vektor und produziert einen 6-dimensionalen Vektor. Dieselben gelernten Gewichte werden auf jede Token-Position unabhängig angewendet. Egal, ob 3 Tokens oder 3.000 Tokens in der Sequenz sind, jedes durchläuft dasselbe FFN mit denselben Parametern.

Die Q-, K- und V-Projektionsmatrizen, die die Attention antreiben, sind ebenfalls \(d \times d\) — Per-Token-Operationen. Der einzige Ort, an dem Tokens interagieren, sind die Attention-Scores: Die Query jedes Tokens wird per Skalarprodukt gegen den Key jedes anderen Tokens verglichen. Für 3 Tokens ergibt das eine 3 × 3 Score-Matrix; für 4 Tokens eine 4 × 4 Matrix. Aber diese Score-Matrix wird dynamisch aus den Daten berechnet — sie enthält keine gelernten Parameter, deren Form von der Sequenzlänge abhängt.

Die Architektur ist also tatsächlich \(f: \mathbb{R}^d \to \mathbb{R}^d\) pro Token, mit dynamischer Kopplung zwischen Positionen durch Attention. Die Sequenzlänge \(n\) erscheint in keiner Gewichtsmatrix. Deshalb kann dasselbe Modell sowohl einen 3-Wort-Prompt als auch ein 3.000-Wort-Dokument verarbeiten — die Gewichte sind identisch, nur die Anzahl der Gegenstände auf dem Förderband ändert sich. Wir werden das in Vorlesung 5 vollständig präzise machen.

6.5 Schritt 4: Von Vektoren zurück zu Wörtern

Der Transformer hat drei verfeinerte Vektoren produziert — einen für jedes Token in der Sequenz. Aber wir brauchen nur eine Vorhersage: Was kommt als Nächstes? Das Modell nimmt den Vektor des letzten Tokens — den für drinks — denn das ist die einzige Position, an der das Modell eine Fortsetzung vorhersagen muss. (Die Positionen <BOS> und dragon haben bereits bekannte Nachfolge-Tokens.)

Dieser einzelne Vektor hat 6 Dimensionen. Das Vokabular hat 10 Tokens. Um einen Score für jedes mögliche nächste Token zu erzeugen, multipliziert das Modell diesen 6-dimensionalen Vektor mit einer 10 × 6 Ausgabegewichtsmatrix — eine Zeile pro Vokabular-Token. Das Ergebnis: 10 Zahlen, sogenannte Logits. Jeder Logit sagt: “Wie wahrscheinlich ist es, dass dieses Token als Nächstes kommt?”

Die rohen Logits sind nur Zahlen — sie können negativ sein und summieren sich nicht zu etwas Sinnvollem. Softmax wandelt sie in Wahrscheinlichkeiten um: alle positiv, summieren sich zu 1, wobei höhere Logits exponentiell höhere Wahrscheinlichkeiten erzeugen. Das Balkendiagramm zeigt das Ergebnis: potion dominiert mit 62 %. fire ist mit 18 % Zweitplatzierter — schließlich könnte ein Drache Feuer trinken. Die anderen Tokens fallen auf einstellige Werte ab.

<BOS> dragon drinks → potion. Ein Vorwärtsdurchlauf, ein vorhergesagtes Token. Das Modell hängt potion an die Sequenz an, und der gesamte Prozess wiederholt sich — nun mit einer 4 × 6 Matrix als Eingabe, die das fünfte Token vorhersagt. Dann eine 5 × 6 Matrix, die das sechste vorhersagt. Token für Token entsteht eine Geschichte.

Das ist genau die Schleife zur Vorhersage des nächsten Tokens aus Kapitel 2 — nur dass Sie jetzt jeden Schritt mechanisch nachverfolgen können und an jeder Station beobachten, wie die Matrizen Form und Wert ändern.

6.6 Hochskalieren

Unser Spielzeugbeispiel hat 10 Tokens und 6 Dimensionen — 60 Parameter allein in der Embedding-Tabelle. Echte Modelle sind Größenordnungen größer:

Für GPT-2 hat diese eine Tabelle 50.257 Zeilen (eine für jedes Token im Vokabular) und 768 Spalten (die Dimensionalität der Embeddings). Das sind über 38 Millionen Parameter — allein für diese eine Lookup-Tabelle, bevor der Transformer überhaupt irgendeine eigentliche Berechnung durchgeführt hat.

Die Zahlen werden für größere Modelle noch größer. GPT-3 verwendet 12.288-dimensionale Embeddings. Moderne Frontier-Modelle verwenden noch mehr. Allein die Embedding-Matrix kann hunderte Millionen Parameter enthalten. Aber das Prinzip ist identisch zu unserem Spielzeugbeispiel: Jede Token-ID bildet auf eine Zeile ab, und diese Zeile ist ein Vektor gelernter Zahlen. Der einzige Unterschied ist die Größenordnung.

6.7 Embeddings kodieren Bedeutung

In einem trainierten Modell im großen Maßstab entfalten sich die Muster, die wir in unserem Spielzeugbeispiel angedeutet haben, über zehntausende Tokens mit weit größerer Klarheit. Die Vektoren für “king” und “queen” liegen näher beieinander als die Vektoren für “king” und “banana”. Die Vektoren für “Python” (die Programmiersprache) und “Java” liegen näher beieinander als die Vektoren für “Python” und “python” (die Schlange) — obwohl alle drei eine gewisse Ähnlichkeit teilen. Diese Beziehungen sind nicht programmiert; sie entstehen aus der Statistik der Trainingsdaten.

Die Embedding-Vektoren sind das, womit der Transformer tatsächlich denkt. Jede nachgelagerte Operation — Self-Attention, Feed-Forward-Schichten, Output-Projektion — nimmt diese Vektoren als Eingabe. Die Aufgabe des Tokenizers ist es, die Ganzzahl-IDs zu erzeugen, die in diese Tabelle indizieren. Die Embedding-Matrix übersetzt diese IDs dann in die reichhaltigen numerischen Repräsentationen, die das Modell benötigt.

Sie haben nun die vollständige Reise von Text zu Vorhersage gesehen — im Miniaturformat. Die zentrale Frage für heute: Wie sollten wir Text in Tokens aufspalten? Unser Spielzeugvokabular verwendete ganze Wörter — dragon, drinks, potion. Echte Modelle gehen raffinierter vor. Um zu sehen, warum, beginnen wir mit einem Rätsel.

7. Was das Modell nicht sehen kann

Die Behandlung der Tokenisierung in diesem und den folgenden Kapiteln stützt sich auf das ausgezeichnete Video “How AI Actually Reads Text | Tokenization” von Attention Visualized, das einen klaren visuellen Durchgang durch diese Konzepte bietet. Die narrative Struktur, das Spielzeugbeispiel, die Diagramme und die didaktische Einordnung sind originär für diesen Kurs entstanden.

Im Jahr 2023 brachte eine einfache Frage das Internet zum Beben: “Wie viele r’s sind im Wort strawberry?”

Jedes große Sprachmodell — GPT-4, Claude, Gemini, Llama — antwortete selbstbewusst: zwei. Die richtige Antwort ist drei: strawberry. Ein System, das funktionierenden Code schreiben und zwischen Sprachen übersetzen konnte, konnte nicht bis drei zählen.

Wenn Sie das heute ausprobieren, werden die meisten Frontier-Modelle es richtig machen. Sie wurden gezielt auf dieses Beispiel und ähnliche Buchstaben-Zähl-Aufgaben trainiert. Aber das zugrunde liegende Problem ist nicht verschwunden — es wurde nur für die berühmtesten Fälle übertüncht. Probieren Sie stattdessen ein weniger bekanntes Wort:

Fragen Sie irgendein Modell: “Wie viele s sind in ‘mississippi’?” Oder: “Wie viele c sind in ‘Connecticut’?”

Die Frage ist: Warum? Das sind Maschinen zur Vorhersage des nächsten Tokens, die über komplexe Probleme schlussfolgern können. Warum scheitern sie an etwas so Einfachem wie dem Zählen von Buchstaben?

Die Antwort hat mit der Tokenisierung zu tun. Bevor das Wort “strawberry” jemals das neuronale Netz erreicht, teilt der Tokenizer es in Stücke auf — vielleicht str, aw, berry:

Das Modell sieht drei Tokens, nicht zehn Buchstaben. Die r’s sind über Tokengrenzen verstreut. Aber warum spaltet der Tokenizer es auf diese Weise? Warum nicht ein Token pro Buchstabe oder ein Token pro Wort? Was bestimmt, wo die Schnitte fallen?

Probieren Sie noch eine Sache. Fragen Sie das Modell: Was ist 1234 + 5678?

Die richtige Antwort ist 6912. Viele Modelle bekommen das falsch oder nur inkonsistent richtig — selbst Modelle, die nun die Strawberry-Frage meistern. Der Grund ist verwandt: Die Ziffern werden über Tokengrenzen aufgespalten, und zwar so, dass die Stellenwertstruktur zerstört wird, von der die Arithmetik abhängt. Wir werden später in der Vorlesung zu beiden Fehlern zurückkehren, sobald wir die Algorithmen hinter der Tokenisierung verstehen.

Um zu beantworten, warum der Tokenizer Text so aufspaltet, wie er es tut, müssen wir den Entwurfsraum verstehen. Was sind die Optionen? Was funktioniert, was scheitert, und welche Kompromisse beinhaltet jeder Ansatz? Darum geht es im Rest dieser Vorlesung.

8. Tokenisierung auf Wortebene

Der einfachste Ansatz ist, jedem Wort ein eigenes Token zu geben. An Leerzeichen aufteilen, jedem Wort eine eindeutige Ganzzahl zuweisen und in der Embedding-Matrix nachschlagen.

Der Satz “The cat sat on the mat” wird zu sechs Tokens, jedes mit seiner eigenen ID. Sauber, intuitiv, einfach umzusetzen.

Und fatal fehlerhaft.

8.1 Die Vokabular-Explosion

Englisch hat über 170.000 aktiv gebrauchte Wörter. Aber das ist nur der Anfang. Fügen Sie technischen Jargon hinzu — Kubernetes, microservices, backpropagation. Fügen Sie Eigennamen hinzu — jeden Personennamen, jede Stadt, jedes Produkt. Fügen Sie Tippfehler hinzu — teh, recieve, definately. Fügen Sie Flexionen hinzu — run, runs, running, ran, runner, runners. Fügen Sie zusammengesetzte Wörter, Neologismen, Umgangssprache hinzu.

Das Vokabular bläht sich auf über eine halbe Million Einträge auf. Und jeder Eintrag braucht seine eigene Zeile in der Embedding-Matrix. Bei 768-dimensionalen Embeddings sind das:

Fast 400 Millionen Parameter allein für die Vokabular-Lookup-Tabelle. Für ein größeres Modell mit breiteren Embeddings sind die Kosten noch höher. Das ist eine enorme Menge Speicher, die einer einzigen Komponente gewidmet ist.

8.2 Das Problem unbekannter Wörter

Aber die Kosten sind nicht einmal das schlimmste Problem. Der eigentliche Killer ist, was passiert, wenn der Tokenizer auf ein Wort trifft, das er noch nie gesehen hat.

Angenommen, jemand tippt unbreakable. Wenn dieses Wort nicht im Vokabular enthalten ist — weil es in den Trainingsdaten zu selten war oder einfach nicht aufgenommen wurde —, hat der Tokenizer keinen Eintrag dafür. Das Wort wird durch ein spezielles [UNK]-Token ersetzt, was bedeutet “Ich habe keine Ahnung, was das ist.” Sämtliche Bedeutung geht verloren. Das Modell weiß, dass etwas da war, aber es weiß nicht, was.

Das ist katastrophal für ein Sprachmodell. Stellen Sie sich vor, Sie lesen ein Buch, in dem jedes unbekannte Wort geschwärzt wurde. Sie könnten eine gewisse Bedeutung aus dem Kontext ableiten, aber Sie haben Informationen verloren, die nie wieder hergestellt werden können.

8.3 Keine morphologische Wahrnehmung

Es gibt ein drittes Problem, subtiler aber genauso schädlich. Die Wörter run, running, runner und runs sind vier völlig separate Einträge in einem Wort-Vokabular. Das Modell erhält keinen Hinweis darauf, dass sie einen gemeinsamen Stamm teilen. Jedes muss unabhängig von Grund auf neu gelernt werden.

Für einen Menschen ist die Verbindung offensichtlich — sie leiten sich alle von “run” ab, und die Suffixe (-ning, -ner, -s) tragen vorhersagbare Bedeutungen. Aber in einem Wort-Vokabular sind diese Beziehungen unsichtbar. Das Modell muss sie rein aus dem Kontext entdecken, was weit mehr Trainingsdaten erfordert, als wenn die morphologische Struktur explizit wäre.

Tokenisierung auf Wortebene war der Standard in der frühen Sprachverarbeitung. Für moderne Sprachmodelle ist sie im Wesentlichen obsolet. Das Vokabular ist zu groß, unbekannte Wörter zerstören Information und morphologische Beziehungen sind unsichtbar.

Wir brauchen eine andere Granularität.

9. Der Subword-Sweet-Spot

Wenn Tokenisierung auf Wortebene zu große Vokabulare und Tokenisierung auf Zeichenebene zu lange Sequenzen erzeugt — gibt es einen Mittelweg?

9.1 Das Zeichen-Extrem

Schauen wir zuerst, warum auch das andere Extrem — ein Token pro Zeichen — scheitert. Wenn jedes Zeichen sein eigenes Token ist, ist das Vokabular winzig: etwa 100 Einträge für die Buchstaben, Ziffern und gängigen Satzzeichen des Englischen. Sie werden nie auf ein unbekanntes Wort treffen, denn jedes mögliche Wort ist nur eine Folge von Zeichen.

Aber der Preis ist verheerend. Das Wort “cat” wird zu 3 Tokens. Das Wort “unbreakable” wird zu 11 Tokens. Ein bescheidener Absatz von 500 Wörtern explodiert auf etwa 2.500 Zeichen-Tokens.

Warum ist das ein Problem? Weil die Aufmerksamkeit im Transformer quadratisch mit der Sequenzlänge skaliert. Wenn Sie die Anzahl der Tokens in der Sequenz verdoppeln, wird die Aufmerksamkeitsberechnung viermal teurer:

Eine 2.500 Token lange Sequenz auf Zeichenebene kostet 6,25 Millionen Operationen in der Attention-Schicht. Eine 500 Token lange Sequenz auf Wortebene kostet nur 250.000. Das ist ein 25-facher Unterschied im Rechenaufwand — für denselben Text.

Tokenisierung auf Zeichenebene tauscht ein Problem (Vokabular-Explosion) gegen ein anderes (Sequenz-Explosion). Keines der Extreme funktioniert.

9.2 Der Sweet Spot

Die Lösung ist Subword-Tokenisierung: häufige Wörter ganz lassen, aber seltene Wörter in bedeutungstragende Teile zerlegen.

Beobachten Sie, was mit dem Wort “unbreakable” geschieht. Statt eines Tokens (Wortebene) oder elf Tokens (Zeichenebene) teilt die Subword-Tokenisierung es in drei Tokens auf: un, break, able.

Diese drei Stücke haben genau die richtige Granularität. Jedes ist ein wiederverwendbarer Baustein:

• un erscheint in unhappy, undo, unfair, uncertain, unbreakable
• break erscheint in breaking, breakage, breakfast, unbreakable
• able erscheint in readable, doable, comfortable, unbreakable

Das Modell lernt diese Stücke einmal und kann sie in neuen Kombinationen zusammensetzen. Wenn das Modell un, break und able jeweils separat gesehen hat, kann es unbreakable verstehen, auch wenn es dieses spezifische Wort als Ganzes nie zuvor gesehen hat. Das ist ähnlich, wie Sie als menschliche:r Leser:in ein Wort verstehen können, das Sie noch nie gesehen haben, indem Sie seine Teile erkennen.

Häufige Wörter wie “the”, “is”, “function” und “return” bleiben einzelne Tokens — sie sind häufig genug, um ihren eigenen Vokabular-Eintrag zu verdienen. Seltene Wörter werden zerlegt. Das Ergebnis ist ein Vokabular von typischerweise 30.000 bis 200.000 Tokens — groß genug, um häufige Wörter intakt zu halten, klein genug, um in den Speicher zu passen.

Das ist der Ansatz hinter jedem großen Sprachmodell heute — GPT, Claude, Llama, Mistral, Gemini, sie alle verwenden Subword-Tokenisierung. Die einzige Frage ist: Wie lernt die Maschine, welche Stücke sie verwenden soll?

9.3 Die zwei Subword-Probleme

Am Zeichen-Extrem ist Tokenisierung trivial: Jedes Zeichen ist ein Token, und Text zu kodieren bedeutet einfach, ihn in einzelne Zeichen aufzuspalten. Am Wort-Extrem ist es genauso einfach: an Leerzeichen aufteilen, jedes Wort nachschlagen. In beiden Fällen ist die Kodierungsfunktion — wie man Text in Tokens umwandelt — offensichtlich und erfordert keine Überlegung.

Subword-Tokenisierung ist anders. In dem Moment, in dem Sie Tokens variabler Größe zulassen, ergeben sich zwei Probleme, die gemeinsam gelöst werden müssen:

1. Was soll im Vokabular sein? Welche Subwords wählen wir aus? Wir brauchen eine Menge von Tokens V, die Vokabulargröße gegen Sequenzlänge ausbalanciert. Aber wie entdecken wir die richtigen Stücke aus den Daten?

2. Wie kodieren wir Text in diese Stücke? Gegeben ein Vokabular, das t, h, th und the enthält — wie entscheidet der Tokenizer, ob “the” in t | h | e, th | e oder the aufgespalten wird? Alle drei Zerlegungen verwenden nur Tokens, die im Vokabular existieren. Ohne klare Regel ist die Aufspaltung mehrdeutig.

Das zweite Problem ist leicht zu übersehen, weil es an den Extremen nicht existierte. Aber es ist entscheidend: Ein Subword-Vokabular, das alle einzelnen Zeichen enthält, könnte — mit einer naiven Kodierung — einfach alles in Zeichen zerlegen und so jeden Subword-Eintrag verschwenden. Das Vokabular allein reicht nicht. Sie brauchen auch eine Kodierungsfunktion, die weiß, wie sie Text intelligent aufteilt.

Tokenisierung ist daher zweierlei: ein Vokabular V und eine Kodierungsfunktion f, die Text auf Folgen von Tokens aus diesem Vokabular abbildet. Jeder Subword-Tokenisierungs-Algorithmus muss beides produzieren. Wie wir sehen werden, löst BPE beide Probleme elegant gleichzeitig — die Merge-Regeln, die es während des Trainings lernt, dienen doppelt als Vokabular und als Kodierungsfunktion.

10. Die richtigen Stücke finden

Wir haben festgestellt, dass Subword-Tokenisierung die richtige Idee ist — häufige Wörter ganz lassen, seltene Wörter in wiederverwendbare Teile zerlegen. Aber das wirft eine Frage auf, die leicht zu übersehen ist: Wer entscheidet, was die Stücke sind?

10.1 Das Vokabular-Entwurfsproblem

Betrachten Sie das Wort “unbreakable”. Wir sagten, es solle in un | break | able aufgeteilt werden. Das scheint offensichtlich — aber nur, weil wir Englisch sprechen und Präfixe und Suffixe erkennen. Was ist mit “Donaudampfschifffahrtskapitän” auf Deutsch? Oder “令和” auf Japanisch? Oder einem Python-Traceback, der englische Wörter, camelCase-Bezeichner und Dateipfade mischt?

Es gibt drei Ansätze, die wir versuchen könnten:

Linguist:innen fragen. Linguist:innen können Morpheme identifizieren — die kleinsten bedeutungstragenden Einheiten der Sprache. Für das Englische würden sie uns sagen, dass un- ein Präfix und -able ein Suffix ist. Aber das erfordert separate Regeln für jede Sprache. Englische Morphologie hilft nicht beim Mandarin, Arabischen oder Tamil. Und die Linguistik hat nichts zu calculateAverageScore oder NullPointerException zu sagen. Dieser Ansatz ist zu langsam, zu sprachspezifisch und skaliert nicht auf mehrsprachige Modelle.

Ingenieur:innen fragen. Wir könnten Regeln von Hand entwerfen: an Unterstrichen aufteilen, nach Großbuchstaben in camelCase aufteilen, an gängigen Suffixen aufteilen. Das funktioniert für spezifische Fälle, ist aber inhärent willkürlich. Warum nach “break” aufteilen, aber nicht nach “bre”? Jede Regel, die wir schreiben, spiegelt unsere Annahmen wider, nicht die tatsächliche Struktur der Trainingsdaten. Verschiedene Korpora haben unterschiedliche Muster, und ein regelbasiertes System kann sich nicht anpassen.

Die Daten entscheiden lassen. Statt Regeln von oben aufzuzwingen, können wir mit rohen Zeichen beginnen und Häufigkeitsstatistiken offenbaren lassen, welche Zeichenkombinationen es verdienen, zu Tokens zu werden. Wenn t und h tausende Male nebeneinander erscheinen, fügen Sie sie zu th zusammen. Wenn th und e ständig zusammen erscheinen, fügen Sie sie zu the zusammen. Die Daten sagen uns, was die nützlichen Stücke sind — keine linguistische Expertise erforderlich, keine sprachspezifischen Regeln, keine manuelle Kuratierung.

10.2 Von Kompression zu Tokenisierung

Dieser Ansatz “die Daten entscheiden lassen” ist nicht neu. 1994 veröffentlichte Philip Gage einen einfachen Kompressionsalgorithmus namens Byte Pair Encoding (BPE). Die Idee war geradlinig: Finde das häufigste Paar benachbarter Bytes in einer Datei, ersetze es durch ein einzelnes neues Byte und wiederhole das. Jede Zusammenführung macht die Datei kürzer. Es war eine Nischen-Kompressionstechnik — nichts mit Sprache zu tun.

Einundzwanzig Jahre später, im Jahr 2015, erkannten Rico Sennrich und Kolleg:innen, dass derselbe Algorithmus das Vokabular-Entwurfsproblem für neuronale maschinelle Übersetzung lösen könnte. Statt Dateien zu komprimieren, wandten sie ihn auf Text an: mit Zeichen beginnen, das häufigste benachbarte Paar finden, zusammenführen, wiederholen. Die häufigsten Zeichenfolgen werden auf natürliche Weise zu Tokens.

Bis 2019 war Byte-Level-BPE zum Standard geworden. Heute verwenden GPT-4, Claude, Llama und Mistral alle BPE oder enge Varianten davon.

Die Schönheit des Algorithmus liegt in seiner Einfachheit. Eine Regel, wiederholt angewendet: finde das häufigste Paar, fasse es zusammen. Kein linguistisches Wissen, kein Wörterbuch, keine Grammatikregeln. Die Häufigkeitsstatistiken erledigen die ganze Arbeit.

11. Byte Pair Encoding

Sehen wir uns an, wie BPE in der Praxis funktioniert.

11.1 Wie BPE funktioniert

Der Algorithmus beginnt mit einem Trainingskorpus — einer großen Textmenge, die die Sprache repräsentiert, die das Modell verarbeiten wird. Gehen wir ein Spielzeugbeispiel durch.

Unser Trainingskorpus: “the cat in the hat”

Schritt 0: Initialisieren. Spalten Sie jedes Wort in einzelne Zeichen auf. Das ergibt das kleinstmögliche Startvokabular:

t  h  e     c  a  t     i  n     t  h  e     h  a  t

Das Startvokabular besteht aus nur 7 einzigartigen Zeichen: {t, h, e, c, a, i, n}.

Schritt 1: Paare zählen und das häufigste zusammenführen. Schauen Sie auf jedes benachbarte Paar von Zeichen im Korpus und zählen Sie, wie oft jedes Paar erscheint:

• (t, h) erscheint 3-mal (in the, the, hat)
• (h, e) erscheint 2-mal (in the, the)
• (a, t) erscheint 2-mal (in cat, hat)

Das Paar (t, h) gewinnt mit der höchsten Anzahl. Aber was, wenn es ein Unentschieden gegeben hätte? In der Praxis wählt die Implementierung eines deterministisch aus — zum Beispiel das Paar, das in der Scanreihenfolge zuerst kommt. Ein anderer Tiebreaker würde ein leicht anderes Vokabular erzeugen. Auf unserem Spielzeugkorpus sind Unentschieden plausibel. Bei echten Trainingsdaten mit Milliarden Wörtern sind die Zählungen so groß, dass Unentschieden extrem selten sind.

Wir fügen t und h zusammen. Jedes Vorkommen von t h im Korpus wird durch das neue Token th ersetzt:

th  e     c  a  t     i  n     th  e     h  a  t

Das Vokabular wächst von 7 auf 8: {t, h, e, c, a, i, n, th}.

Schritt 2: Wiederholen. Zählen Sie alle benachbarten Paare neu. Jetzt erscheint (a, t) zweimal (in cat und hat). Führen Sie a und t zu at zusammen:

th  e     c  at     i  n     th  e     h  at

Vokabular: 9 Tokens.

Schritt 3: Erneut wiederholen. Zählen Sie neu. (th, e) erscheint zweimal. Fügen Sie sie zusammen — und so wird the, eines der häufigsten englischen Wörter, zu einem einzigen Token:

the     c  at     i  n     the     h  at

Vokabular: 10 Tokens.

Drei Zusammenführungen, und der Algorithmus hat bereits ein ganzes englisches Wort entdeckt — rein durch das Zählen, welche Paare am häufigsten erscheinen. Keine Grammatikregeln. Keine Wörterbuch-Lookups. Nur Häufigkeitsstatistiken.

11.2 Vom Spielzeugbeispiel zum echten Modell

In der Praxis ist der Maßstab völlig anders. GPT-2 führt 50.000 dieser Zusammenführungen durch. GPT-4 führt etwa 100.000 durch. Der Trainingskorpus besteht nicht aus fünf Wörtern — es sind hunderte Gigabytes Text. Aber der Algorithmus ist derselbe: von den kleinsten Einheiten starten, Paare zählen, das häufigste zusammenführen, wiederholen.

Jede Zusammenführung komprimiert den Text ein wenig mehr und baut ein Vokabular zunehmend größerer und bedeutungstragender Stücke auf. Frühe Zusammenführungen erzeugen gängige Zeichenkombinationen (th, in, er). Mittlere Zusammenführungen erzeugen gängige Subwords und kurze Wörter (the, ing, tion). Späte Zusammenführungen erzeugen gängige vollständige Wörter und Phrasen (function, return, import).

Die zentrale Erkenntnis ist, dass BPE vollständig datengetrieben ist. Es erfordert keine linguistischen Regeln, kein Wörterbuch und keine Kenntnis irgendeiner bestimmten Sprache. Es schaut einfach, welche Paare am häufigsten vorkommen, und führt sie zusammen. Die Struktur der Sprache — häufige Wörter, häufige Suffixe, wiederkehrende Präfixe — entsteht automatisch aus der Statistik des Trainingskorpus.

11.3 BPE löst beide Probleme

Erinnern Sie sich an die zwei Subword-Probleme aus Abschnitt 9.3: Was soll im Vokabular sein? und Wie kodieren wir Text in diese Stücke? BPE löst beide gleichzeitig.

Training produziert zwei Ausgaben:

1. Ein Vokabular — die Menge aller Tokens: die 256 Basis-Bytes (oder Zeichen) plus jedes zusammengeführte Token. Nach unseren drei Zusammenführungen: V = {t, h, e, c, a, i, n, th, at, the} — 10 Tokens.
2. Eine geordnete Liste von Merge-Regeln — die Zusammenführungen in der exakten Reihenfolge, in der sie gelernt wurden:
   • Regel 1: t + h → th
   • Regel 2: a + t → at
   • Regel 3: th + e → the

Diese Merge-Regeln sind nicht nur ein Protokoll davon, wie das Vokabular aufgebaut wurde. Sie sind die Kodierungsfunktion. Wenn der trainierte Tokenizer auf neuen Text trifft, führt er den Trainingsalgorithmus nicht erneut aus. Er spielt die Merge-Regeln in Reihenfolge auf der neuen Eingabe ab.

11.4 Neuen Text kodieren

Sehen wir uns das in Aktion an. Unser trainierter Tokenizer hat das Vokabular V = {t, h, e, c, a, i, n, th, at, the} und drei Merge-Regeln. Jetzt kommt ein neuer Satz an, der nie Teil des Trainingskorpus war:

Kodieren: “the hat”

Start: In einzelne Zeichen aufteilen (immer der Startpunkt der Kodierung):

t  h  e     h  a  t

Regel 1 anwenden (t + h → th): Suche nach einem benachbarten Paar t h. An Position 1-2 gefunden. Zusammenführen:

th  e     h  a  t

Beachten Sie: Dem h in “hat” geht ein Leerzeichen voraus, nicht ein t, also passt es nicht. Nur das t h am Anfang wird zusammengeführt.

Regel 2 anwenden (a + t → at): Suche nach a t. In “hat” gefunden. Zusammenführen:

th  e     h  at

Regel 3 anwenden (th + e → the): Suche nach th e. Am Anfang gefunden. Zusammenführen:

the     h  at

Keine weiteren Regeln. Die endgültige Tokenisierung ist: the | h | at — drei Tokens.

Dieses Beispiel offenbart etwas Wichtiges. Unser Vokabular enthält alle ursprünglichen Zeichen — t, h, e, a — und die zusammengeführten Tokens th, at, the. Der Tokenizer hätte “the” in drei Zeichen-Tokens t | h | e aufteilen können, und das Ergebnis würde immer noch nur gültige Vokabular-Einträge verwenden. Aber er tat es nicht, weil die Merge-Regeln eine bestimmte Zerlegung erzwingen. Die Merge-Regeln sind die Kodierungsfunktion. Ohne sie haben Sie eine Tüte erlaubter Zeichenketten und keine Möglichkeit, neuen Text deterministisch aufzuspalten.

Das beantwortet auch eine naheliegende Frage: Macht der Tokenizer “Longest Match” — sucht er nach dem größten Token im Vokabular, das passt? Nein. Er spielt Zusammenführungen in der Reihenfolge ab, in der sie gelernt wurden. Regel 1 feuert zuerst, weil sie während des Trainings das häufigste Paar war. Die Merge-Reihenfolge impliziert, dass häufigere (und damit nützlichere) Zusammenführungen vor weniger häufigen geschehen. Das Ergebnis sieht oft aus wie Longest Match, aber der Mechanismus ist grundlegend anders — es ist eine geordnete Folge von Umschreibregeln.

11.5 Wann aufhören

In unserem Spielzeugbeispiel hörten wir nach 3 Zusammenführungen auf, weil die verbleibenden Paare alle eine Anzahl von 1 haben — es gibt kein starkes statistisches Signal mehr. Aber der Algorithmus entscheidet nicht von sich aus, wann er stoppen soll. In der Praxis ist die Zielvokabulargröße ein Hyperparameter, der vor dem Trainingsstart gewählt wird:

• GPT-2: 50.257 Tokens (256 Basis-Bytes + 50.000 Zusammenführungen + 1 spezielles Token)
• GPT-4: etwa 100.000 Tokens
• LLaMA 3: 128.000 Tokens

Der Algorithmus führt Zusammenführungen durch, bis das Vokabular die Zielgröße erreicht, dann hört er auf. Auf Milliarden von Wörtern Trainingsdaten gibt es immer genug Häufigkeitssignal, um zehntausende Zusammenführungen zu stützen. Die Wahl der Vokabulargröße ist ein Engineering-Kompromiss — wir werden seine Konsequenzen in Kapitel 16 erkunden.

Sie werden das direkt erleben, wenn Sie den Encoder in der BPE-Notebook-Übung implementieren.

12. Strawberry erklärt

Jetzt verstehen Sie Subword-Tokenisierung und BPE. Lassen Sie uns zum Rätsel aus Kapitel 7 zurückkehren.

Warum spaltet sich strawberry in str, aw, berry auf?

Weil der BPE-Algorithmus, trainiert auf Milliarden von Wörtern, gelernt hat, dass das effiziente Subword-Einheiten sind. Das Paar (b, e) war häufig genug, um zu be zusammengeführt zu werden. Später wurde (be, r) zu ber. Dann (ber, r) zu berr. Dann (berr, y) zu berry. Derselbe Prozess baute str aus einzelnen Zeichen auf. Jede Zusammenführung wurde von Häufigkeitsstatistiken getrieben — nicht von irgendeinem Verständnis von Rechtschreibung, Morphologie oder der englischen Sprache.

Die Merge-Statistiken bestimmten diese Grenzen. Und diese Grenzen haben Konsequenzen.

12.1 Tokens sind atomar

Das Modell kann nicht in ein Token hineingreifen, um einzelne Zeichen zu untersuchen. Jedes Token ist eine atomare, unteilbare Einheit — das kleinste Stück, das das Modell wahrnehmen kann. Wenn der Transformer str, aw, berry verarbeitet, sieht er drei undurchsichtige Brocken, nicht zehn Buchstaben.

Wo sind die r’s?

• str enthält ein r, vergraben am Ende eines drei Zeichen langen Brockens.
• aw enthält kein r.
• berry enthält zwei r’s, vergraben in einem fünf Zeichen langen Brocken.

Die r’s sind über Tokens verstreut, in größeren Stücken verborgen. Das Modell hat keinen Mechanismus, um “in ein Token hineinzuschauen” und seine Zeichen zu zählen. Es kann nur über die Tokens schlussfolgern, die es sieht — und es sieht drei Tokens, nicht zehn Buchstaben.

12.2 Erst Wahrnehmung — aber das ist nicht die ganze Geschichte

Tokenisierung zerstört die Zeichen-Ebenen-Information, bevor das neuronale Netz überhaupt beteiligt ist. Wenn das Modell einzelne Buchstaben nicht sehen kann, kann es sie auch nicht zählen. Das ist ein echtes Versagen der Wahrnehmung. Denken Sie so darüber nach: Wenn jemand Ihnen einen Satz zeigt, in dem jedes dritte Wort geschwärzt wurde, würden Sie Schwierigkeiten haben, Fragen zu diesen Wörtern zu beantworten — nicht weil Sie nicht lesen können, sondern weil die Information entfernt wurde, bevor sie Sie erreichte.

Aber hier sollte eine ehrliche Studentin oder ein ehrlicher Student widersprechen: Was, wenn wir den Tokenizer reparieren? Angenommen, wir tokenisieren “strawberry” Buchstabe für Buchstabe — s, t, r, a, w, b, e, r, r, y — zehn Tokens, jedes r sichtbar. Würde das Modell jetzt zuverlässig “drei” antworten?

Wahrscheinlich nicht zuverlässig. Und der Grund offenbart eine tiefere Wahrheit darüber, wie diese Modelle funktionieren.

Eine Maschine zur Vorhersage des nächsten Tokens führt keine Prozeduren aus. Sie hat keine Variablen, keine Schleifen, keine Akkumulatoren. Um die r’s zu zählen, müsste das Modell:

1. Jedes Token scannen und identifizieren, welche r sind
2. Einen laufenden Zähler verwalten, der mit jedem Treffer hochzählt
3. Die finale Zahl ausgeben

Ein Transformer tut nichts davon. Er nimmt die Eingabe-Tokens, schickt sie durch Attention- und Feed-Forward-Schichten und produziert eine Wahrscheinlichkeitsverteilung über das nächste Token. Die Ausgabe “3” müsste als die statistisch wahrscheinlichste Fortsetzung von “How many r’s are in strawberry? → “ entstehen, basierend auf Mustern, die das Modell während des Trainings gesehen hat. Wenn die Trainingsdaten tausende Beispiele von “How many r’s in strawberry → 3” enthielten, würde das Modell es als auswendig gelerntes Muster lernen — nicht durch eine Zählprozedur ableiten.

Genau deshalb meistern aktuelle Frontier-Modelle die Strawberry-Frage nun korrekt: Sie wurden gezielt auf dieses Beispiel und viele ähnliche Buchstaben-Zähl-Aufgaben trainiert. Musterauswendiglernen, nicht verbesserte Zählfähigkeit. Probieren Sie ein weniger berühmtes Wort — das deutsche “Donaudampfschifffahrtskapitän” oder ein erfundenes — und das Versagen kehrt oft zurück.

Die Lehre hat also zwei Schichten:

1. Tokenisierung macht das Buchstabenzählen unmöglich — Sie können nicht zählen, was Sie nicht sehen können.
2. Auch mit perfekter Tokenisierung ist Vorhersage des nächsten Tokens die falsche Architektur für prozedurales Zählen. Zählen erfordert einen Mechanismus, den der Transformer nicht hat.

Dieselbe zweischichtige Erklärung gilt für das arithmetische Versagen aus Kapitel 7 — 1234 + 5678. Tokenisierung zerstört die Stellenwert-Ausrichtung (das studieren wir in Kapitel 17), aber selbst mit Ziffer-Ebenen-Tokenisierung ist Arithmetik eine Prozedur, die Vorhersage des nächsten Tokens nicht natürlich durchführt. Sie kann 6912 nur produzieren, wenn das Muster in den Trainingsdaten stark genug ist, um statistisch zu entstehen.

Die tiefere Einsicht: Der Transformer kann Information über Tokens hinweg tragen — dafür ist Attention da. Wir öffnen diese Box in Vorlesung 5. Erst dann werden wir verstehen, warum manche dieser Versagen durch Training teilweise überwunden werden können und warum sie grundsätzlich fragil bleiben.

13. Byte-Level-BPE: Wie es wirklich gemacht wird

Das BPE, das wir in Kapitel 11 gebaut haben, arbeitete auf Zeichen — eine freundliche Art, den Algorithmus einzuführen, aber nicht, wie echte Tokenizer funktionieren. GPT-2, GPT-4, Claude, Llama und Mistral arbeiten alle auf Bytes, nicht auf Zeichen. Dieses Kapitel erklärt warum, wie und in welchem Maßstab — und was es bedeutet, auf Infrastruktur zu stehen, die Jahrzehnte vor den Transformern aufgebaut wurde.

13.1 Das Problem unbekannter Zeichen

Standard-BPE auf Zeichenebene ist bereits eine große Verbesserung gegenüber Tokenisierung auf Wortebene. Aber “Zeichen” ist ein schlüpfrigeres Konzept, als es zunächst scheint.

Englisch hat nur 26 Buchstaben. Aber Chinesisch hat zehntausende Zeichen. Fügen Sie Emojis hinzu (3.600 und es werden mehr), mathematische Symbole (über 2.000), Währungssymbole, diakritische Zeichen aus Dutzenden von Schriften und seltene Unicode-Zeichen, und das Basisvokabular auf Zeichenebene — bevor überhaupt Zusammenführungen beginnen — kann 100.000 Einträge überschreiten.

Das hebelt den Zweck der Subword-Tokenisierung aus. Wir wollten ein kleines Vokabular. Mit 100.000 Zeichen zu starten ist nicht klein. Und das UNK-Problem lauert immer noch: Jedes Jahr wird ein neues Emoji zu Unicode hinzugefügt, und ein Tokenizer, der letzte Woche trainiert wurde, hat keine Möglichkeit, es zu kodieren.

13.2 Auf den Schultern von Unicode und UTF-8 stehen

Bevor wir GPT-2s Antwort erklären können, müssen wir die Infrastruktur würdigen, die es geerbt hat.

LLMs haben Text-als-Zahlen nicht erfunden. Jahrzehnte vor dem ersten Transformer hatte die Computerwelt den schwierigsten Teil bereits gelöst:

• Unicode (erstmals 1991 veröffentlicht) wies jedem Zeichen in jeder Schrift — Lateinisch, Kyrillisch, Chinesisch, Arabisch, Emoji, mathematische Symbole — eine eindeutige Ganzzahl zu, genannt Codepoint. Etwa 150.000 Codepoints sind heute zugewiesen, und der Standard reserviert Platz für über eine Million.
• UTF-8 (1993, RFC 3629) kodierte diese Codepoints als Bytefolgen der Länge 1 bis 4. Es ist rückwärtskompatibel mit ASCII (reiner englischer Text verwendet ein Byte pro Zeichen) und ist zur De-facto-Kodierung des Internets geworden — über 98 % der Webseiten heute.

13.2.1 Was ist eigentlich ein Byte?

Ein kurzer Umweg für Leser:innen, die noch nie auf dieser Ebene gearbeitet haben. Ein Byte ist einfach 8 Bits — 8 Binärziffern, jede 0 oder 1. Acht Bits ergeben \(2^8 = 256\) verschiedene Kombinationen, nummeriert von 0 bis 255. Das ist alles, was ein Byte ist: eine Zahl zwischen 0 und 255.

Dasselbe Byte kann in vier Notationen geschrieben werden, die sehr unterschiedlich aussehen, aber genau dasselbe bedeuten:

Ein Byte für sich allein hat keine inhärente Bedeutung — der Kontext entscheidet, wie es interpretiert wird. Das Byte 72 ist die Zahl 72, wenn Sie Arithmetik betreiben, der Buchstabe H, wenn Sie es als ASCII-Text anzeigen, und ein grauer Pixelton, wenn Sie es als Bild rendern. Der Python-Aufruf list("Hello".encode("utf-8")) liefert [72, 101, 108, 108, 111] — das sind die Bytes als Ganzzahlen, und so arbeitet BPE-Code normalerweise mit ihnen. Hex-Notation ist in Spezifikationen beliebt, weil zwei Hex-Ziffern genau einem Byte entsprechen.

13.2.2 Wie vier Bytes mehr als 150.000 Zeichen abdecken

Wenn ein Byte nur 256 mögliche Werte hat — wie kann UTF-8 dann die ~150.000 zugewiesenen Codepoints von Unicode kodieren, geschweige denn Platz für den vollen reservierten Bereich von über einer Million lassen? Die Antwort ist der clevere Trick im Herzen von UTF-8: Das erste Byte eines Zeichens kündigt an, wie viele Bytes dieses Zeichen belegt.

Die führenden Bits des ersten Bytes sind selbstbeschreibend:

• 0… — eigenständiges 1-Byte-Zeichen (reines ASCII)
• 110… — ich bin der Anfang eines 2-Byte-Zeichens
• 1110… — ich bin der Anfang eines 3-Byte-Zeichens
• 11110… — ich bin der Anfang eines 4-Byte-Zeichens
• 10… — ich bin ein Fortsetzungs-Byte; ich beginne nie ein Zeichen

Mit vier Bytes erhalten Sie 21 Nutzdatenbits — über 2 Millionen mögliche Werte, was den reservierten Bereich von Unicode mehr als abdeckt. ASCII bleibt billig (ein Byte pro englischem Buchstaben), Nicht-ASCII-Text zahlt nur dort mehr, wo es nötig ist. Deshalb gewann UTF-8 die Kodierungs-Kriege der späten 1990er: Effizienz und ASCII-Kompatibilität in einem Design.

13.2.3 UTF-8 in der Praxis

In konkrete Bytes übersetzt:

• Der Buchstabe H → 1 Byte: 0x48 = 72
• Der deutsche Umlaut ü → 2 Bytes: 0xC3 0xBC = 195, 188
• Das chinesische Zeichen 世 (“Welt”) → 3 Bytes: 0xE4 0xB8 0x96 = 228, 184, 150
• Das Emoji 😊 → 4 Bytes: 0xF0 0x9F 0x98 0x8A = 240, 159, 152, 138

Beachten Sie, wie das erste Byte der Mehrbyte-Zeichen (0xC3, 0xE4, 0xF0) zu den Headern aus der Bitmuster-Tabelle passt: 11000011…, 11100100…, 11110000…. UTF-8 ist keine Magie — es ist disziplinierte Bit-Anordnung.

Diese Asymmetrie — nicht-englischer Text ist bereits mehr Bytes, bevor irgendeine Tokenisierung passiert — ist die eigentliche Ursache der mehrsprachigen Fairnesslücke, die wir in Kapitel 18 diskutieren. Sie ist auch genau der Grund, warum der Byte-Level-Ansatz funktioniert: Unicode und UTF-8 garantieren, dass jeder mögliche Text auf eine Folge von Bytes abgebildet wird, wobei jedes Byte nur eine Zahl zwischen 0 und 255 ist.

Zentrale Erkenntnis: LLMs müssen kein universelles Alphabet erfinden. Sie erben eines. Das Tokenizer-Design beginnt nachdem Text bereits auf Bytes reduziert wurde — eine Reduktion, die 30 Jahre Standardisierungsarbeit erst ermöglicht haben.

13.2.4 Bytes selbst inspizieren in Python

Alles in §13.2.1–§13.2.3 lässt sich mit ein paar Zeilen Python inspizieren. Keine Bibliotheken außerhalb der Standardbibliothek — jedes Werkzeug, das Sie brauchen, ist in der Sprache eingebaut.

Die b'...'-Notation, die Sie sehen werden. Wenn Python ein Bytes-Objekt ausgibt, verwendet es eine gemischte Notation: druckbare ASCII-Bytes erscheinen als ihr ASCII-Buchstabe, und nicht-ASCII-Bytes erscheinen als Hex-Escapes \xNN:

>>> "Hü".encode("utf-8")
b'H\xc3\xbc'              # byte 72 shown as 'H'; bytes 195, 188 shown as hex
>>> list("Hü".encode("utf-8"))
[72, 195, 188]            # same three bytes, as integers
>>> bytes([72, 195, 188]) == b'H\xc3\xbc'
True

b'H\xc3\xbc' und [72, 195, 188] sind zwei Darstellungen derselben drei Bytes. Tokenizer-Code arbeitet mit der Ganzzahl-Form, weil das ist, womit get_stats und merge operieren (§13.4).

Die Bitmuster erhalten. Pythons Format-Spezifikation :08b bedeutet “binär, nullaufgefüllt auf 8 Stellen” — genau ein Byte voller Bits:

>>> for b in "ü".encode("utf-8"):
...     print(f"byte {b:3d}  (0x{b:02X})  =  {b:08b}")
byte 195  (0xC3)  =  11000011
byte 188  (0xBC)  =  10111100

Jetzt können Sie die Bitmuster aus §13.2.2 buchstäblich sehen. Das erste Byte beginnt mit 110… (Header für ein 2-Byte-Zeichen); das zweite beginnt mit 10… (Fortsetzung). Schälen Sie die Header ab, kleben Sie die Nutzdatenbits zusammen, und Sie erhalten den Unicode-Codepoint zurück:

First byte:  11000011  →  110 | 00011     (header | 5 payload bits)
Second byte: 10111100  →  10  | 111100    (header | 6 payload bits)

Combined payload: 00011 111100  =  binary 00011111100  =  decimal 252
                                  =  U+00FC  =  "ü"  ✓

Ein wiederverwendbarer Einzeiler. Diese kleine Funktion funktioniert für jedes Zeichen und macht die Struktur auf einen Blick sichtbar:

def show_utf8(char):
    bs = list(char.encode("utf-8"))
    print(f"{char!r}  (U+{ord(char):04X} = {ord(char)}, {len(bs)} byte(s))")
    for i, b in enumerate(bs):
        print(f"  byte {i}: {b:3d}  0x{b:02X}  {b:08b}")

show_utf8("H")    # 1-byte:  0xxxxxxx
show_utf8("ü")    # 2-byte:  110xxxxx 10xxxxxx
show_utf8("世")   # 3-byte:  1110xxxx 10xxxxxx 10xxxxxx
show_utf8("😊")    # 4-byte:  11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Führen Sie es aus und vergleichen Sie die führenden Bits mit der Bitmuster-Tabelle in §13.2.2 — sie passen exakt. Jede UTF-8-Behauptung in diesem Kapitel ist nur einen f"{b:08b}"-Aufruf vom Verifizieren entfernt.

13.3 Das universelle 256-Byte-Basisvokabular

Sobald Text aus Bytes besteht, wird das Basisvokabular trivial. Es gibt genau 256 mögliche Bytewerte (0 bis 255), und das ist GPT-2s gesamter Startpunkt:

Das war’s. 256 Tokens decken jede geschriebene menschliche Sprache, jedes Emoji, jede wissenschaftliche Notation ab — weil UTF-8 die schwere Arbeit, sie auf Bytes zu reduzieren, bereits erledigt hat. BPE läuft dann obendrauf und lernt Zusammenführungen, die rohe Bytes zu zunehmend bedeutungsvollen Mehrbyte-Tokens kombinieren.

Kontrast zum BPE auf Zeichenebene: ~100.000 Basis-Einträge, immer noch nicht in der Lage, die neuen Emojis des nächsten Jahres zu handhaben. Byte-Level-BPE: 256 Basis-Einträge, kein UNK-Token, für immer.

Eine Garantie, keine Empfehlung. Da die 256 Basis-Tokens vor jeglichem Training existieren, kann jede mögliche UTF-8-Bytefolge immer kodiert werden — im schlimmsten Fall ein Token pro Byte. Das [UNK]-Token, das wortbasierte Systeme heimgesucht hat (§8.2), kann nicht entstehen. Wir werden in §13.5 sehen, dass das eine subtile Konsequenz hat: Seltene Zeichen sind immer repräsentierbar, auch wenn der Tokenizer nie eine gute Zusammenführung für sie gelernt hat; sie verwenden einfach mehr Tokens.

13.3.1 Warum ein neues Emoji kein erneutes Training erfordert

Die obige Garantie ist abstrakt. Machen wir sie konkret mit einem Szenario, das sich jedes Jahr abspielt: Unicode fügt neue Emojis hinzu. Wie kann ein Tokenizer, der vor Jahren ausgeliefert wurde, immer noch Zeichen handhaben, die nicht existierten, als er gebaut wurde?

Das Setup. Es ist 2027. GPT-4o wurde 2024 mit o200k_base ausgeliefert — sein Vokabular ist eingefroren. Heute wird Unicode 17.0 veröffentlicht und fügt ein brandneues Emoji hinzu, das wir 🆕-emoji nennen. Seine UTF-8-Kodierung sind vier Bytes — zur Illustration sagen wir F0 9F AA 99 oder als dezimale Ganzzahlen [240, 159, 170, 153]. Diese spezifische Bytefolge ist nie in den Trainingsdaten irgendeines Tokenizers aufgetaucht.

Schritt 1 — Kodieren. Eine Nutzerin tippt das neue Emoji in einen Prompt. Das Betriebssystem kodiert es als UTF-8. Die encode()-Funktion des Tokenizers erhält die vier Bytes und wendet die gelernten Merge-Regeln in Trainingsreihenfolge an (§13.4). Sie findet keine Zusammenführung, die diese spezifische Bytefolge betrifft — das konnte sie auch nicht, denn die Bytes traten nicht im Trainingskorpus zusammen auf. Also gehen die vier Ganzzahlen als vier Basis-Byte-Tokens durch. Das Emoji wird durch 4 Tokens repräsentiert statt durch das eine Token, das ein frisch neu trainierter Tokenizer ihm zuweisen könnte.

Kein Fehler. Kein [UNK]. Keine Code-Änderung. Kein erneutes Training.

Schritt 2 — Das LLM verarbeitet die Tokens. Die Embedding-Matrix des Modells hat eine Zeile für jede Token-ID von 0 bis ~200.000. Die Zeilen 240, 159, 170 und 153 waren vom ersten Tag an da — sie sind Teil des universellen 256-Byte-Basisvokabulars (§13.3), das bedingungslos existiert. Das Modell schlägt diese vier Embedding-Zeilen nach, speist sie in den Transformer-Stack und verarbeitet sie genauso wie jede andere Eingabe.

Das Modell hat dieses Emoji nie im Training gesehen. Es hat keine gelernte semantische Verbindung zum neuen Symbol. Aber die Pipeline funktioniert von Anfang bis Ende: Die Kodierung gelingt, der Vorwärtsdurchlauf gelingt, und schließlich gelingt auch das Dekodieren.

Schritt 3 — Das Modell erzeugt Ausgabe. Kann das Modell das Emoji produzieren? Ja — indem es die vier Basis-Byte-Tokens in der richtigen Reihenfolge ausgibt. Die Embedding-Zeilen existieren, der Output-Softmax deckt alle 200.000 Token-IDs ab, also ist Token 240 gefolgt von 159 gefolgt von 170 gefolgt von 153 eine vollkommen gültige Generierung. Verketten Sie die Bytes, UTF-8-decodieren Sie, und das Emoji erscheint wieder auf dem Bildschirm der Nutzerin.

Wird es das Emoji im richtigen Kontext produzieren? Das hängt vom In-Context Learning ab. Zeigen Sie dem Modell ein Beispiel (“Dieses Emoji 🆕-emoji bedeutet ‘Glitzer’”), und es wird die Bytes oft korrekt zurückgeben, wenn ein ähnlicher Kontext wieder auftaucht. Ohne jeden Kontext kann das Modell keine Bedeutung erfinden — aber es kann das Emoji immer reproduzieren, wenn man es darum bittet.

Kontrast zu älteren Tokenizer-Designs:

Das Fazit. UTF-8 ist ein vorwärtskompatibler Standard: Jedes Zeichen, das Unicode jemals hinzufügen wird, ist nur ein neuer Codepoint, kodiert als 1–4 Bytes — und diese Bytes sind bereits im Basisvokabular des Tokenizers. Ein Byte-Level-Tokenizer, der heute trainiert wird, wird jedes Zeichen, das Unicode in alle Ewigkeit hinzufügt, korrekt kodieren und decodieren, ohne erneutes Training.

Das semantische Verständnis des Modells für neue Symbole wächst nur mit neuen Trainingsdaten. Aber die technische Fähigkeit, sie zu verarbeiten, ist von Tag eins eingebaut. Das ist, was “auf den Schultern von Unicode und UTF-8 stehen” (§13.2) tatsächlich erkauft: einen Tokenizer, der sein Eingabegebiet nicht überaltert.

13.4 Der Algorithmus, auf Byteebene

Konzeptuell ändert sich nichts gegenüber dem zeichenbasierten BPE, das Sie in Kapitel 11 kennengelernt haben. Konkret sind die “Paare” jetzt Paare von Byte-Ebenen-Tokens, und die “neuen Tokens” sind Mehrbyte-Sequenzen. Ein funktionierender Byte-Level-Tokenizer hat fünf Funktionen, in dieser Reihenfolge:

1. get_stats(ids) — zählt die Häufigkeit jedes benachbarten Token-Paares in der Sequenz.
2. merge(ids, pair, new_id) — ersetzt jedes Vorkommen von pair durch new_id.
3. train_bpe(text, num_merges) — wiederholt get_stats + merge für num_merges Iterationen und zeichnet die Merge-Regeln in der Reihenfolge, in der sie gelernt wurden, auf.
4. encode(text, merges) — wendet die gelernten Merge-Regeln in Trainingsreihenfolge an, um neuen Text zu tokenisieren.
5. decode(ids, vocab) — schlägt für jede Token-ID die Bytefolge nach, verkettet, UTF-8-decodiert.

Merge-Reihenfolge ist wichtig. Spätere Zusammenführungen können von Tokens abhängen, die durch frühere Zusammenführungen erzeugt wurden. Wenn Merge 1 aus den Bytes t + h th (Token 256) erzeugt und Merge 2 aus (256, e) the (Token 257) erzeugt, dann müssen Sie Merge 1 zuerst anwenden, um das Wort “the” zu tokenisieren — sonst findet Merge 2 nichts. Das Selbststudien-Notebook, das in §13.8 verlinkt ist, macht das konkret: Implementieren Sie diese fünf Funktionen selbst und beobachten Sie, was passiert, wenn Sie Zusammenführungen außerhalb der Reihenfolge anwenden.

13.4.1 Ein durchgearbeitetes Beispiel: “Müller”

Abstrakte Funktionsnamen sind eine Sache; die tatsächlichen Ganzzahlen zu sehen, mit denen BPE arbeitet, eine andere. Nehmen wir den winzigen Korpus "Müller Müller Müller" — einen deutschen Nachnamen, dreimal wiederholt. UTF-8-kodiert, mit den Bytewerten aus §13.2.3 (M=77, ü=195,188, l=108, e=101, r=114, Leerzeichen =32), ist die vollständige Bytefolge:

[77, 195, 188, 108, 108, 101, 114, 32,
 77, 195, 188, 108, 108, 101, 114, 32,
 77, 195, 188, 108, 108, 101, 114]

23 Ganzzahlen, jede zwischen 0 und 255. Die entscheidende Erkenntnis: BPE weiß nicht, dass das Bytes sind. Für get_stats ist das nur eine Liste von ganzzahligen Token-IDs. Es zählt benachbarte Paare und produziert:

Mehrere Paare sind gleichauf bei 3. Angenommen, BPE wählt (195, 188) und weist ihm die neue Token-ID 256 zu. Das Anwenden von merge ersetzt jedes Vorkommen dieses Paares und produziert:

[77, 256, 108, 108, 101, 114, 32, 77, 256, 108, 108, 101, 114, 32, 77, 256, 108, 108, 101, 114]

Der Vokabular-Eintrag für Token 256 speichert die Bytes b'\xc3\xbc' — die, wenn UTF-8-decodiert, genau "ü" ergeben. BPE hat den Umlaut “entdeckt”, ohne dass ihm irgendetwas über Unicode gesagt worden wäre. Es bemerkte lediglich, dass die Bytes 195 und 188 in diesem Korpus immer nebeneinander auftraten, und kollabierte sie zu einer einzigen Einheit.

Warum das universell funktioniert. In gültigem UTF-8 erscheinen die zwei Bytes von ü (195 und 188) immer benachbart, in genau dieser Reihenfolge — der Kodierungsstandard garantiert es. Das Paar (195, 188) ist also garantiert hochfrequent in jedem Text, der ü enthält. BPE führt es früh zusammen. Allgemeiner gesagt: Jedes Mehrbyte-Zeichen in UTF-8 sieht für BPE aus wie eine kurze Kette hochkorrelierter Bytes, die zu 100 % zusammen auftreten. Die variable Länge von UTF-8 ist keine Komplikation, mit der BPE umgehen muss — sie ist ein Merkmal, das BPE automatisch ausnutzt.

13.4.2 Zwei Repräsentationen, zwei Dateien

Das Müller-Beispiel ließ eine Frage implizit: Sobald BPE Token 256 erzeugt — was speichert der Tokenizer dafür tatsächlich? Es gibt zwei plausible Designs — eines offensichtlich, eines, das sich als die richtige Engineering-Wahl herausstellt — und echte Tokenizer liefern beide, in separaten Dateien.

Option A: Das Paar speichern. Ein natürliches Design wäre, sich zu merken “Token 256 wurde durch das Zusammenführen von (195, 188) gebaut”:

vocab_recursive = {
    256: (195, 188),        # the pair of ids that merged into 256
    257: (256, 101),        # 256 is itself merged — recursive
    258: (116, 257),
    # ...
}

Zum Decodieren rekursiv expandieren, bis Sie zu Basis-Bytes gelangen:

def expand(token_id):
    if token_id < 256:
        return bytes([token_id])       # base case: a raw byte
    a, b = vocab_recursive[token_id]
    return expand(a) + expand(b)       # concatenate children

Das funktioniert. Es ist logisch äquivalent zu dem, was Produktions-Tokenizer tun.

Option B: Die flachen Bytes speichern. Das ist, was das durchgearbeitete Beispiel in §13.4.1 tat und was jeder Produktions-Tokenizer tatsächlich ausliefert:

vocab = {
    256: b'\xc3\xbc',       # bytes, already concatenated
    257: b'\xc3\xbce',      # eagerly built from vocab[256] + vocab[101]
    258: b't\xc3\xbce',
    # ...
}

Decodieren ist dann ein flaches Lookup, kein Baumlauf:

pieces = [vocab[i] for i in [77, 257]]        # [b'M', b'\xc3\xbce']
b"".join(pieces).decode("utf-8")               # → "Müe"

Warum Option B gewinnt. Drei Gründe, in der Reihenfolge ihrer Wichtigkeit:

1. Dekodier-Geschwindigkeit. Flach ist O(1) pro Token; rekursiv erfordert O(Tiefe) Lookups plus Verkettungen. Bei der Inferenz dekodiert jeder Generierungsschritt ein Token, also läuft dieser Pfad ständig.
2. Sie haben es bereits beim Training berechnet. Die Trainingszeile vocab[new_id] = vocab[a] + vocab[b] verkettet die Bytes jedes Mal, wenn eine Zusammenführung feuert (siehe §13.4.1), eifrig. Dieses Ergebnis wegzuwerfen und später neu zu berechnen, würde bereits geleistete Arbeit verschwenden.
3. Speicher ist in dieser Größenordnung trivial billig. Ein 200.000-Token-Vokabular mit einem Durchschnitt von ~10 Bytes pro Eintrag ist ~2 MB — keine Sorge.

Der Twist: Sie haben tatsächlich beides. Die Information aus Option A wird nicht verworfen. Sie lebt in einer zweiten Datei, die zusammen mit dem flachen Vokabular ausgeliefert wird. Jeder trainierte Tokenizer (GPT-2, GPT-4o, Llama, StarCoder2) sind zwei Dateien:

Beide stammen aus demselben Trainingslauf. Sie exponieren unterschiedliche Ansichten desselben Merge-Baums, weil die zwei Operationen unterschiedliche Dinge brauchen:

• Kodieren braucht Reihenfolge und Priorität — “welche Zusammenführung feuert zuerst auf dieser Bytefolge?” → merges.txt, wo Rang 0 Rang 1 schlägt und Rang 1 Rang 2.
• Decodieren braucht nur die finale Bytefolge für jede Token-ID → vocab.json, die vorberechnete flache Antwort.

Schauen Sie sich GPT-2s merges.txt und vocab.json an — es sind wörtlich diese zwei Dateien.

Das Designmuster. Das ist ein klassischer Engineering-Schachzug: zur Trainingszeit (passiert einmal) vorzuberechnen, was die Inferenzzeit (passiert ständig) beschleunigt. Der Merge-Baum ist das Trainingsartefakt; das flache Vokabular ist das vorberechnete Inferenzartefakt. Beide zusammen sind der Tokenizer — Kodieren erfordert merges.txt, Decodieren erfordert vocab.json, und das Modell am anderen Ende der Pipeline braucht beide.

13.4.3 Wo Bedeutung lebt — und wo nicht

Eine Frage, die es wert ist, explizit gemacht zu werden, weil sie fast alle stolpern lässt: “Weiß” Token 256, dass es ü repräsentiert?

Nein. Token 256 ist buchstäblich nur die Ganzzahl 256. Es hat keine Metadaten, kein Label, keine Erinnerung an die Bytes, die in seine Erzeugung gegangen sind. BPE weiß nicht, was ü ist. Es weiß nicht, was irgendein Zeichen ist. Es schiebt Ganzzahlen herum.

Die scheinbare “ü-Haftigkeit” von Token 256 ist tatsächlich eine Kette von vier völlig getrennten Schichten, jede definiert von einem anderen Stück Infrastruktur:

Alle vier Schichten müssen zusammenpassen, um ü auf Ihren Bildschirm zu bringen. BPE ist nur die oberen zwei Zeilen. Alles darunter wird von Standards gehandhabt, die LLMs lange vorausgehen. Token 256 hätte genauso gut b'th' bedeuten können oder die ersten zwei Bytes eines Emojis oder irgendein anderes Bytepaar. Die Ganzzahl selbst sagt Ihnen nichts — das Vokabular ist der Entschlüsselungsring, und erst dann verwandelt UTF-8 Bytes in Zeichen.

Zu \xc3. Eine kurze Klarstellung, die leicht falsch verstanden wird: \xc3 allein ist nicht “ein Stück von ü.” Es ist nur ein Byte. Es wird nur dann zur ersten Hälfte von ü, wenn es mit \xbc gepaart und als UTF-8 interpretiert wird. Ein einzelnes Byte außerhalb des ASCII-Bereichs hat keine Zeichenbedeutung — es ist eine unvollständige UTF-8-Sequenz. (Siehe §13.2.4 für die b'...'-Notation und §13.2.2 dafür, warum die führenden Bits von \xc3 = 11000011 ankündigen “Ich bin der Anfang eines 2-Byte-Zeichens”.)

Kodieren und Decodieren sind die Grenze des Systems. Das mit §13.4.2 zusammengezogen:

• Kodieren ist der Eingang: Text → UTF-8-Bytes → Token-IDs (damit das Modell sie aufnehmen kann).
• Decodieren ist der Ausgang: Token-IDs → Vokabular-Bytes → UTF-8-Text (damit Menschen oder externe Systeme sie lesen können).
• Dazwischen: reine Ganzzahl-Mathematik. Der Tokenizer sieht Ganzzahlen. Das Modell sieht ebenfalls nur Ganzzahlen — es führt Embedding-Lookups, Attention, MLPs und Output-Softmax vollständig im Ganzzahl-ID-Raum durch, von der Eingabe bis zur Ausgabe. Es ruft an keiner Stelle .decode("utf-8") auf.

Die “Bedeutung” eines Tokens wird erst überlagert, wenn Sie die Grenze zurück in die für Menschen sichtbare Welt überschreiten. In der Pipeline ist alles — BPE, das Modell, die Inference-Engine — agnostisch gegenüber dem, was die Ganzzahlen repräsentieren. Diese Agnostik ist der ganze Grund, warum Byte-Level-BPE so robust ist: Die Pipeline hat keine semantischen Verpflichtungen zu verteidigen, also kann sie nichts “missverstehen”. Sie hat von vornherein nie versucht zu verstehen.

13.4.4 Also, was ist ein Token wirklich?

Nach all dieser Maschinerie können wir endlich die täuschend einfache Frage beantworten, mit der dieses Kapitel eröffnete:

Ein Token ist eine Ganzzahl, deren Bedeutung von ihrem Vokabular zugewiesen wird.

Dieser einzelne Satz ist überraschend präzise. Packen Sie ihn aus:

• Es ist eine Ganzzahl. Operativ ist das, was Tokenizer-Code herumreicht, eine Ganzzahl-ID. tokenizer.encode("Hello") liefert [13225, ...] — eine schlichte Liste von Ganzzahlen, keine Liste von (id, bytes)-Tupeln. Das Vokabular ist eine gemeinsam genutzte Referenztabelle; jedes Token zeigt implizit, nicht explizit, auf seinen Vokabular-Eintrag.
• Die Bedeutung wird vom Vokabular zugewiesen. Die Ganzzahl 3788 ist nicht inhärent “ software” — es ist “ software” nur weil vocab[3788] = b' software'. Nehmen Sie das Vokabular weg, und 3788 ist nur eine Zahl, nicht bedeutsamer als 42.
• …von seinem Vokabular. Tokens sind nur Tokens relativ zu einem spezifischen Vokabular. Derselbe Text, kodiert von GPT-2 und Llama 3, produziert völlig unterschiedliche Ganzzahlfolgen, weil die Vokabulare unterschiedlich sind. “Token 3788” in cl100k_base bedeutet etwas völlig anderes als “Token 3788” in o200k_base.

Das Wort “Token” wird auch auf drei verschiedenen Ebenen je nach Kontext verwendet, alle konsistent mit dieser Definition:

Alle drei sind “das Token” — verschiedene Repräsentationen derselben logischen Einheit, jede angemessen für ihre Ebene. Im Code ist es die Ganzzahl. Auf der Festplatte ist es der Vokabular-Eintrag. Innerhalb des Transformers ist es der gelernte Embedding-Vektor. Die Ganzzahl fädelt sie alle zusammen.

Eine nützliche Analogie: Ein Hausschlüssel ist nicht “die Metallform + die Beschreibung ‘Haustür’.” Der Schlüssel ist das Metall; die Beschreibung lebt in Ihrem Schlüsselmanager. Beide zusammen sagen Ihnen, welche Tür er öffnet, aber Sie tragen nur den Schlüssel. Dieselbe Logik gilt hier — Tokens reisen als Ganzzahlen, das Vokabular ist der Schlüsselmanager.

13.5 Verlustfrei vs. effizient: Zwei verschiedene Sorgen

Das Müller-Beispiel wirft eine berechtigte Sorge auf: Was passiert, wenn die Daten unausgeglichen sind? Stellen Sie sich einen riesigen, englisch-dominierten Korpus vor, in dem genau ein deutsches Wort mit ü erscheint. Das Paar (195, 188) tritt einmal in Milliarden von Bytepaaren auf, also gewinnt es nie den Häufigkeitswettbewerb gegen englische Paare wie (116, 104) (“th”, millionenfach auftretend). BPE führt den Umlaut nie zusammen.

Ist ü “verloren gegangen”? Die Antwort hängt davon ab, welche von zwei sehr verschiedenen Fragen Sie stellen.

Sorge 1: Kann ü unrepräsentierbar werden?

Nein. Niemals. Genau das garantiert das 256-Byte-Basisvokabular (§13.3). Die Tokens 195 und 188 existieren bedingungslos — sie sind im Vokabular, bevor das Training überhaupt beginnt. "Müller" kodiert also noch immer gut:

"Müller" → [77, 195, 188, 108, 108, 101, 114]
           M   (ü in 2 bytes)   l    l    e   r

Sieben Tokens statt der drei oder vier Tokens, die ein deutsch-trainierter Tokenizer produzieren könnte — aber keine Information geht verloren. Decodieren Sie diese Sequenz, verketten Sie die Bytes über b"".join(...), rufen Sie .decode("utf-8") auf, und Sie erhalten "Müller" perfekt zurück. Byte-Level-BPE ist kodierungs-verlustfrei, immer.

Sorge 2: Kann ü teuer werden?

Absolut ja, und das ist die eigentliche Sorge. Wenn (195, 188) im Training selten ist, führt BPE es nie zusammen. Deutscher Text kostet dann mehr Tokens pro Wort als vergleichbarer englischer Text. Dasselbe Wort “Müller” könnte 7 Tokens kosten, während das englische “Miller” — das von gelernten Zusammenführungen für Mi, ll, er profitiert — nur 2 oder 3 kosten könnte. Ein 3-facher Preisunterschied für äquivalenten Inhalt.

Gleiche Bytes, andere Gruppierungen. Das ist die sauberste Formulierung, die man mitnehmen sollte. Der Tokenizer speichert immer UTF-8-Bytes in seinem Vokabular — er könnte nicht von UTF-8 abweichen, selbst wenn er wollte. Was variiert, ist, wie diese Bytes in Tokens gruppiert werden:

Beide kehren fehlerfrei zu "ü" zurück. Der Unterschied ist rein einer der Effizienz, nicht der Korrektheit.

Warum diese Unterscheidung wichtig ist. Die Aufteilung verlustfrei vs. effizient ist die wichtigste Idee in diesem Kapitel. Byte-Level-BPE garantiert Verlustfreiheit per Konstruktion; Effizienz hängt vollständig von der Mischung der Trainingsdaten ab. Deshalb behandelt §13.7 (Woher die Daten kommen) Datenkuratierung als erstrangiges Engineering-Problem, und es ist der Mechanismus hinter der mehrsprachigen Fairnesslücke in Kapitel 18. Der Algorithmus behandelt jedes Byte gleich; die Zusammenführungen, die er lernt, spiegeln nur die Daten wider, mit denen er gefüttert wurde.

13.6 Realität des Maßstabs: Vom Spielzeug zur Produktion

Unser durchgearbeitetes Beispiel in Kapitel 11 verwendete 20 Zusammenführungen auf einem 95-Byte-Korpus. GPT-4o verwendet ~200.000 Zusammenführungen, trainiert auf Webdaten im Multi-Terabyte-Bereich. Der Algorithmus ist identisch; der Maßstab ist sechs Größenordnungen auseinander.

Drei Konsequenzen folgen aus dieser Größenordnung:

Kosten der Embedding-Matrix. Die Vokabulargröße des Tokenizers wird zur Anzahl der Zeilen in der Embedding-Matrix des Modells. Für ein Modell mit 12.288-dimensionalen Embeddings und 200.019 Vokabular-Einträgen, in 16-Bit-Genauigkeit gespeichert, ist allein die Embedding-Tabelle etwa \(200{,}019 \times 12{,}288 \times 2 \approx 4{,}9\) GB — bevor der Transformer selbst auch nur ein einziges Byte verwendet. Deshalb ist die Vokabulargröße eine Designentscheidung erster Ordnung, die in Kapitel 16 ausführlicher behandelt wird.

Kompressionsverhältnis verbessert sich, mit abnehmendem Grenznutzen. Von 20 Zusammenführungen auf 50.000 zu gehen, halbiert grob die Token-Anzahl für englischen Text. Von 50.000 auf 200.000 spart weitere ~10–15 %. Von 200.000 auf 2 Millionen würde fast nichts sparen — die Kurve ist an diesem Punkt flach. Das Selbststudien-Notebook (§13.7) lässt Sie diese Kurve direkt beobachten.

Vokabular spiegelt Trainingsdaten wider. Die Zusammenführungen, die ein Tokenizer lernt, sind die Muster, die in seinem Trainingskorpus am häufigsten wiederkehren. Wenn der Korpus zu 90 % englisch ist, werden die Zusammenführungen englisch-verzerrt sein; deutscher, japanischer und arabischer Text werden mehr Tokens pro Wort kosten. Das ist kein Bug — es ist die vorhersehbare Konsequenz der Trainingsdaten-Mischung, und es ist die eigentliche Ursache der mehrsprachigen Fairnesslücke, die in Kapitel 18 erkundet wird.

13.7 Woher die Daten kommen

“Auf dem Internet trainiert” verbirgt eine sehr aufwendige Pipeline. Sie zu verstehen, ist essenziell, um zu verstehen, warum echte Tokenizer so aussehen, wie sie aussehen.

Das rohe Ausgangsmaterial ist typischerweise Common Crawl, ein öffentlicher Web-Scrape, der jeden Monat zehnstellige Petabyte HTML produziert. Niemand trainiert direkt auf Common Crawl. Die Standard-Pipeline sieht so aus:

1. Extraktion. HTML, Boilerplate-Navigation, Werbung und Skripte entfernen. Den Haupttext des Artikels behalten.
2. Spracherkennung. Jedes Dokument nach Sprache klassifizieren (fastText, langdetect, CLD3). Die meisten Labs erzwingen eine kuratierte Sprachmischung, statt das zu behalten, was der Crawl zufällig erfasst.
3. Qualitätsfilterung. Dokumente mit Qualitätssignalen niedriger Güte verwerfen — zu viele wiederholte Zeilen, unrealistische Interpunktionsdichte, bekannte Spam-Muster. Manche Labs trainieren kleine Klassifikatoren, um “Wikipedia-ähnliche” Qualität zu bewerten.
4. Deduplizierung. Exakte und Beinahe-Duplikate entfernen (MinHash, SimHash). Duplikate sind ein riesiges Problem: Sie verzerren Zusammenführungen in Richtung wiederholter Boilerplate und führen dazu, dass Modelle auswendig lernen statt zu verallgemeinern.
5. Mischungskonstruktion. Gefilterten Common Crawl mit kuratierten Quellen kombinieren: Bücher, Wikipedia, Forenarchive, Code-Repositories, akademische Aufsätze. Die Mischung — wie viel Code, wie viele Sprachen, wie viel Mathematik — formt jede Zusammenführung, die der Tokenizer lernt.

Die zentrale Erkenntnis für die Tokenisierung: Die Zusammenführungen, die Sie erhalten, sind ein Fingerabdruck Ihrer Datenpipeline, nicht eine Eigenschaft des Algorithmus. Zwei Teams, die identischen BPE-Code auf unterschiedlichen Daten ausführen, produzieren sichtbar unterschiedliche Tokenizer. Das Notebook in §13.8 macht das konkret: Es trainiert BPE separat auf englischen, deutschen, Code- und Emoji-Teilkorpora und lässt Sie sehen — derselbe Algorithmus, vier sehr unterschiedliche Vokabulare.

13.7.1 Was tatsächlich dokumentiert ist — und was Sie selbst messen können

Die obige Pipeline ist allgemein. Was wissen wir tatsächlich über die spezifischen Pipelines, die die heutigen Frontier-Tokenizer produziert haben? Die Kurzfassung: weniger, als Sie sich erhoffen würden.

OpenAI hat absichtlich aufgehört, dies offenzulegen. Der GPT-4-Technikbericht (Brown et al., 2023, arXiv:2303.08774) stellt explizit fest:

Given both the competitive landscape and the safety implications of large-scale models like GPT-4, this report contains no further details about the architecture (including model size), hardware, training compute, dataset construction, training method, or similar.

Frühere Generationen waren transparenter. Das GPT-3-Paper (Brown et al., 2020, arXiv:2005.14165) veröffentlichte die Trainingsmischung des Modells mit Gewichten — etwa 60 % gefilterter Common Crawl, 22 % WebText2, 8 % Books1, 8 % Books2, 3 % Wikipedia — obwohl der Tokenizer selbst im Wesentlichen unverändert von GPT-2 übernommen wurde. Für cl100k_base (GPT-3.5, GPT-4) und o200k_base (GPT-4o) gibt OpenAI den Tokenizer via tiktoken offen frei, legt aber die Datenverteilung, die ihn produziert hat, nicht offen.

Was empirische Forschung trotzdem gemessen hat. Zwei viel zitierte Papers aus 2023 quantifizieren die mehrsprachige Fairnesslücke direkt:

• Petrov et al. (2023), “Language Model Tokenizers Introduce Unfairness Between Languages” (arXiv:2305.15425, NeurIPS 2023; interaktive Projektseite) maßen die Tokenisierungslänge für denselben Text über viele Sprachen hinweg auf GPT-2/3/4 und anderen Tokenizern. Der zentrale Befund: Einige Sprachpaare unterscheiden sich um bis zu 15-fach in der Token-Anzahl für äquivalenten Inhalt. Selbst Tokenizer, die explizit darauf trainiert sind, mehrsprachig zu sein, zeigen erhebliche Lücken.
• Ahia et al. (2023), “Do All Languages Cost the Same?” (arXiv:2305.13707, EMNLP 2023) framte denselben Effekt als ökonomischen: Über 22 typologisch diverse Sprachen hinweg zahlen Sprecher:innen vieler Sprachen mehr pro API-Aufruf und erhalten schlechtere Ausgaben — oft aus Regionen, in denen die API ohnehin weniger erschwinglich ist.

Common Crawl als Sanity-Check auf die Roheingaben. Da die meisten Frontier-Tokenizer auf gefiltertem Common Crawl plus kuratierten Ergänzungen trainiert werden, hilft das Wissen darüber, wie roher Common Crawl aussieht, Erwartungen zu setzen. Die öffentlichen Sprachstatistiken des Projekts zeigen etwa 45 % Englisch nach Dokumentanzahl, mit Russisch, Deutsch, Japanisch und Französisch jeweils bei einigen Prozent und einem sehr langen Schwanz von 160+ anderen Sprachen bei Bruchteilen von Prozent. Ein Tokenizer, der ohne explizite Neugewichtung trainiert wird, erbt genau diese Schieflage.

Code-fokussierte Modelle gehen unterschiedliche Wege. Das Bild für Code ist gemischt:

• Code Llama (Meta) — verwendete den SentencePiece-BPE-Tokenizer von Llama 2 unverändert weiter; fügte eine Handvoll code-spezifischer Spezial-Tokens hinzu (Infilling-Marker). Das Team entschied, dass das Basisvokabular für Code ausreichend war.
• StarCoder2 + The Stack v2 (Lozhkov et al., 2024, arXiv:2402.19173) — trainierte einen eigenen Tokenizer auf The Stack v2: 67,5 TB Code über 619 Programmiersprachen, ~900 Mrd. Trainings-Tokens, 10-mal größer als The Stack v1. Das resultierende Vokabular hat sichtbar mehr Einrückungs-Tokens, Klammer-Muster und sprachspezifische Schlüsselwörter.
• Codex (das ursprüngliche Copilot-Modell) — verwendete den allgemeinen Tokenizer von GPT-3 unverändert weiter.

Das Muster: Spezialisten-Modelle trainieren den Tokenizer nur dann neu, wenn das Basisvokabular sie eindeutig im Stich lässt. Die meisten erben von einem allgemeinen Tokenizer.

Sie müssen niemandem auf das Wort glauben. Das Tokenizer-Playground-Notebook in §13.8 lädt cl100k_base und o200k_base direkt über tiktoken und lässt Sie jedes einzelne der ~200.000 Tokens in GPT-4os Vokabular decodieren. Genau so wird die obige Forschung produziert. Für Fragen wie “wie viel Chinesisch war im Training von GPT-4os Tokenizer enthalten?” ist der Tokenizer selbst die autoritativste verfügbare Quelle — und er liegt auf Ihrem Laptop.

13.8 Selbst ausprobieren

Zwei Begleit-Notebooks verwandeln die Theorie dieses Kapitels in praktische, beobachtbare Ergebnisse.

BPE von Grund auf bauen — implementieren Sie die fünf Funktionen (get_stats, merge, train_bpe, encode, decode) selbst, in reinem Python, in Ihrem Browser (JupyterLite, keine Installation). Das Notebook trainiert auf einem gemischten mehrsprachig + Code + Emoji-Korpus, sodass Sie beobachten werden, wie Byte-Level-BPE Bytefolgen für deutsche Umlaute, Python-Einrückungsmuster und Emoji-Bytepräfixe entdeckt — Seite an Seite mit englischen Zusammenführungen. Es gibt sogar eine dedizierte Zelle, die denselben Algorithmus auf jedem Teilkorpus unabhängig ausführt, damit Sie die entstehenden Vokabulare vergleichen können.

Tokenizer Playground — laden Sie echte Produktions-Tokenizer (tiktoken für GPT-4o, HuggingFace für LLaMA 3 und Gemma 2) und vergleichen Sie, wie sie denselben Text zerschneiden. Dieses läuft in Google Colab (es benötigt Rust-basierte Pakete), aber der Vergleich ist eindrücklich: Derselbe deutsche Satz kann in GPT-4o zu 12 Tokens und in Gemma 2 zu 20 Tokens werden.

Die Lehre, die man mitnehmen sollte: Byte-Level-BPE ist einfach genug, um es an einem Nachmittag zu implementieren, universell genug, um jede geschriebene Sprache und jedes Emoji zu handhaben, und kampferprobt genug, um jedes Frontier-LLM anzutreiben. Die Infrastruktur dahinter — Unicode, UTF-8 — wurde Jahrzehnte vor den Transformern standardisiert. Die Cleverness von GPT-2 war zu bemerken, dass die Teile bereits auf dem Regal lagen.

14. Häufigkeit vs. Likelihood: Wie sich WordPiece von BPE unterscheidet

BPE ist der dominierende Algorithmus, aber nicht der einzige. Erinnern Sie sich aus Abschnitt 9.3: Jeder Subword-Tokenizer muss zwei Probleme lösen — ein Vokabular aufbauen und eine Kodierungsfunktion definieren. BPE löst beide mit geordneten Merge-Regeln. WordPiece und Unigram verfolgen andere Ansätze — müssen aber dieselben zwei Probleme lösen.

WordPiece, der Algorithmus hinter BERT, sieht auf den ersten Blick fast identisch zu BPE aus. Er ist bottom-up, fügt iterativ Paare zusammen und baut ein Vokabular aus kleinen Stücken auf. Aber es gibt einen entscheidenden Unterschied: wie er entscheidet, welches Paar zusammengeführt wird.

BPE führt das häufigste Paar zusammen. WordPiece führt das Paar mit dem höchsten Likelihood-Verhältnis zusammen — einem Maß dafür, wie überraschend es ist, dass zwei Stücke zusammen auftreten, angesichts dessen, wie häufig jedes Stück für sich allein ist.

14.1 Warum der Unterschied wichtig ist

Betrachten Sie einen Korpus, in dem das Subword ##u (in WordPiece-Notation markiert ## ein Fortsetzungsstück) in fast jedem Wort vorkommt. Das Paar (##u, ##g) könnte 20-mal vorkommen, was es zum häufigsten Paar macht. BPE würde es sofort zusammenführen.

Aber WordPiece stellt eine andere Frage: “Ist diese Paarung überraschend?” Da ##u überall vorkommt (insgesamt 36-mal) und ##g oft vorkommt (20-mal), ist die Tatsache, dass sie 20-mal zusammen auftreten, nicht besonders überraschend. Der Score ist niedrig:

Betrachten Sie nun das Paar (##g, ##s), das nur 5-mal vorkommt. Das ist deutlich seltener. Aber ##g (Häufigkeit 20) und ##s (Häufigkeit 5) treten selten zusammen auf. Die 5 Ko-Vorkommen von möglichen 100 sind überraschender:

WordPiece wählt zuerst dieses seltenere Paar aus, weil das Ko-Vorkommen distinkter ist. Es identifiziert Bindungen, die nicht nur häufig, sondern bedeutungstragend sind.

14.2 Eine Analogie

Denken Sie an die Buchstaben Q und U im Englischen. Q kommt nur in 0,1 % des Textes vor. U kommt in 2,7 % vor. Wären sie unabhängig, würden Sie QU etwa zu 0,003 % erwarten. Aber QU kommt tatsächlich zu 0,1 % vor — 37-mal mehr, als der Zufall vorhersagt. Das ist enorme wechselseitige Information. WordPiece erkennt diese distinkten Bindungen; BPE könnte sie zugunsten häufigerer, aber weniger bedeutungstragender Paare übersehen.

14.3 WordPiece in der Praxis

BERT, 2018 von Google veröffentlicht, verwendet WordPiece mit einem Vokabular von 30.522 Tokens. Ein praktischer Unterschied: WordPiece markiert Fortsetzungs-Subwords mit einem ##-Präfix. Das Wort “unbreakable” wird zu un, ##break, ##able. Kein Präfix bedeutet “dieses Token beginnt ein neues Wort.” Das ##-Präfix bedeutet “dieses Token setzt das vorherige Wort fort.” Das macht es trivial einfach, den ursprünglichen Text zu rekonstruieren.

Zusammenfassend: BPE baut sein Vokabular durch Zusammenführen der häufigsten Paare auf. WordPiece baut sein Vokabular durch Zusammenführen der Paare auf, deren Ko-Vorkommen am überraschendsten ist. Beide sind bottom-up, gierig und iterativ. Beide produzieren Subword-Vokabulare. Die Wahl zwischen ihnen ist eine Designentscheidung, kein klarer Gewinner — aber BPE ist der dominierende Standard für generative Sprachmodelle geworden.

15. Groß starten, herunterstutzen: Unigram und SentencePiece

Es gibt einen dritten Ansatz, der in die völlig entgegengesetzte Richtung arbeitet.

BPE und WordPiece sind Bottom-up-Algorithmen. Sie starten mit dem kleinstmöglichen Vokabular (Zeichen oder Bytes) und bauen durch Zusammenführungen auf. Die Unigram-Tokenisierung ist top-down. Sie startet mit einem sehr großen Vokabular — potenziell hunderttausenden Tokens — und entfernt iterativ die Tokens, die am wenigsten zur Gesamtqualität der Tokenisierung beitragen.

Die Qualitätsmetrik ist die Likelihood des Trainingskorpus unter dem aktuellen Vokabular. Bei jedem Schritt fragt Unigram: “Wenn ich dieses Token entferne, wie viel schlechter wird die Tokenisierung?” Tokens, deren Entfernung den geringsten Schaden verursacht, werden gestutzt. Der Prozess wiederholt sich, bis das Vokabular die Zielgröße erreicht.

15.1 SentencePiece: Das praktische Framework

SentencePiece, von Google entwickelt, ist das Framework, das Unigram für reale Modelle praktikabel macht. Seine zentrale Innovation ist, dass es die Eingabe als rohen Bytestrom behandelt — keine Vor-Tokenisierung, keine Annahme, dass Leerzeichen Wörter trennen. Das macht es von Natur aus sprachunabhängig. Sprachen wie Japanisch und Chinesisch, die keine Leerzeichen zwischen Wörtern verwenden, funktionieren ebenso gut wie Englisch.

SentencePiece kann entweder BPE oder Unigram als zugrunde liegenden Algorithmus ausführen. Es wird von T5, mT5 und vielen mehrsprachigen Modellen verwendet.

15.2 Drei Ansätze, ein Ziel

Um die Landschaft zusammenzufassen:

Alle drei Ansätze lösen die zwei Subword-Probleme aus Abschnitt 9.3: Sie produzieren ein Vokabular und eine Kodierungsfunktion. BPEs Kodierungsfunktion sind seine geordneten Merge-Regeln. WordPieces ist ähnlich, aber mit Likelihood-geordneten Zusammenführungen. Unigrams ist grundlegend anders — es verwendet probabilistische Segmentierung und wählt die Zerlegung, die die Likelihood der Eingabe unter dem gelernten Vokabular maximiert. Die Methoden unterscheiden sich, aber das Ziel ist dasselbe: die richtige Granularität zwischen Wörtern und Zeichen finden.

In der Praxis hat BPE gewonnen. Fast jedes Frontier-Modell 2024-2025 — GPT-4o, Claude, LLaMA 3, Mistral, DeepSeek, Qwen — verwendet Byte-Level-BPE. WordPiece überlebt in BERT und seinen Nachfahren, und SentencePiece/Unigram wird noch von einigen Modellen verwendet (insbesondere Gemma mit seinem 256K-Vokabular), aber BPE ist der dominierende Standard. Die obige Tabelle könnte den Eindruck erwecken, dies seien gleichermaßen populäre Alternativen. Sie sind es nicht. Aber alle drei zu verstehen hilft Ihnen, Tokenisierungs-Entscheidungen zu erkennen, wenn Sie in der Praxis auf verschiedene Modelle treffen.

Für diesen Kurs ist das Wichtige nicht die algorithmischen Details, sondern das geteilte Prinzip: Moderne Sprachmodelle sehen keine Wörter. Sie sehen Subword-Tokens, gelernt aus Daten, die Vokabulargröße gegen Sequenzlänge ausbalancieren.

16. Der Balanceakt: Vokabulargröße und ihre Konsequenzen

Wie groß sollte das Vokabular sein? Das ist keine triviale Frage — es ist ein echter Engineering-Kompromiss mit realen Konsequenzen auf beiden Seiten.

16.1 Kleineres Vokabular, längere Sequenzen

Ein kleineres Vokabular bedeutet, dass Wörter in mehr Stücke aufgeteilt werden. Der Text ist in Token-Begriffen länger, was bedeutet, dass der Aufmerksamkeitsmechanismus — der quadratisch skaliert — mehr Kosten verursacht. Weniger Text passt in das Kontextfenster. Das Modell denkt langsamer und sieht weniger von Ihrer Eingabe.

16.2 Größeres Vokabular, mehr Parameter

Ein größeres Vokabular bedeutet weniger Tokens pro Satz, was gut ist. Mehr Text passt in das Kontextfenster. Attention ist billiger. Aber die Embedding-Matrix wächst linear mit der Vokabulargröße, und die Output-Projektionsmatrix hat dieselbe Form. Das fügt Parameter, Speicher und Kosten hinzu.

Die Zahlen sind konkret. LLaMA 2 verwendet ein Vokabular von 32.000 Tokens. Seine Embedding-Matrix ist 32.000 × 4.096 Dimensionen — 131 Millionen Parameter. LLaMA 3 vervierfachte das Vokabular auf 128.000. Jetzt hat allein die Embedding-Matrix 525 Millionen Parameter, und die Output-Projektion hat dieselbe Form:

Das sind 13 % des gesamten 8-Milliarden-Parameter-Modells, die rein der Vokabular-Repräsentation gewidmet sind. Eine Vervierfachung des Vokabulars fügte direkt etwa eine Milliarde Parameter hinzu.

16.3 Der Branchentrend

Der Trend ist klar: Vokabulare werden größer. Hier ist die Entwicklung:

Das allgemeine Prinzip: Größere Modelle mit reichhaltigen Trainingsdaten profitieren von größeren Vokabularen, weil die Kompressionsvorteile (kürzere Sequenzen, billigere Attention, mehr Text im Kontextfenster) die Parameterkosten überwiegen. Aber jedes Token im Vokabular braucht genügend Trainingsbeispiele, um ein nützliches Embedding zu lernen. Ein riesiges Vokabular mit unzureichenden Daten bedeutet, dass viele Tokens schlecht trainierte Repräsentationen haben werden — was uns später zu Glitch-Tokens führt.

17. Warum LLMs an Arithmetik scheitern

In Kapitel 7 haben wir gesehen, dass viele Modelle 1234 + 5678 falsch bekommen. Jetzt, da Sie verstehen, wie Tokenizer Text aufspalten, können Sie genau sehen, warum.

17.1 Das Stellenwertproblem

Wenn Sie zwei Zahlen von Hand addieren, richten Sie die Ziffern nach Stellenwert aus und arbeiten von rechts nach links — Einer-Spalte, Zehner-Spalte, Hunderter-Spalte, Tausender-Spalte. Jede Spalte interagiert über Übertrags-Operationen mit ihrem Nachbarn. Die Einer-Ziffer von 1234 ist 4. Die Einer-Ziffer von 5678 ist 8. Ihre Summe ist 12, also schreiben Sie 2 auf und tragen 1 über. Das erfordert, einzelne Ziffern zu isolieren und über ihre Positionen zu schlussfolgern.

Aber der Tokenizer teilt Zahlen nicht Ziffer für Ziffer auf. Er teilt sie nach gelernten Subword-Grenzen auf — derselbe BPE-Algorithmus, der für englische Wörter gut funktioniert, angewendet auf Ziffernfolgen.

Das Token 1234 könnte als 12 und 34 aufgespalten werden. Das sind zwei undurchsichtige Brocken. Das Modell kann nicht in ein Token hineingreifen, um einzelne Ziffern herauszuziehen. Die Token-Grenze schneidet genau durch die Stellenwert-Spalten, in denen Ziffern interagieren müssen. Die Einer-Ziffer (4) und die Zehner-Ziffer (3) sind innerhalb desselben Tokens als unteilbare Einheit eingeschlossen.

17.2 Inkonsistente Grenzen

Das Problem wird schlimmer. Hier sind drei aufeinanderfolgende Zahlen und wie ein typischer Tokenizer sie aufspaltet:

Drei nahezu identische Zahlen, drei völlig unterschiedliche interne Repräsentationen. Das Modell hat keine konsistente Möglichkeit, über Ziffernpositionen zu schlussfolgern, weil der Tokenizer ihm keine konsistente Struktur liefert, mit der es arbeiten könnte.

Die Grenze bei 999 und 1000 ist besonders dramatisch:

• 999 → ein Token: 999
• 1000 → ein Token: 1000
• 1001 → zwei Tokens: 100 + 1

Eine Zahl um nur eins zu erhöhen, kann die interne Repräsentation des Modells komplett verändern. Deshalb bricht die Arithmetikgenauigkeit für größere Zahlen zusammen — die Token-Grenzen werden zunehmend unvorhersehbar.

17.3 Die Lösung liegt im Tokenizer

Die gute Nachricht: Einige Modelle haben das adressiert. Gemma zwingt explizit jede Ziffer dazu, ein eigenes Token zu sein, unabhängig davon, was BPE-Zusammenführungen produzieren würden. Die Zahl 2164 wird zu vier separaten Tokens — 2, 1, 6, 4 —, jedes perfekt mit seinem Stellenwert ausgerichtet.

Forschung von der ICLR 2025 geht noch weiter und zeigt, dass das Tokenisieren von Ziffern von rechts nach links — wobei die Grenzen mit der Richtung der Übertrags-Operationen ausgerichtet werden — die Arithmetikgenauigkeit um über 22 Prozentpunkte verbessert.

Die entscheidende Erkenntnis: Die Lösung ist kein klügeres Modell. Es ist ein klügerer Tokenizer. Das Modell war nie der Engpass — seine Wahrnehmung war es.

18. Die mehrsprachige Fairnesslücke

Lassen Sie uns nun ein weiteres Rätsel aus Akt I lösen: warum englische Prompts oft besser funktionierten als deutsche.

18.1 Die Token-Steuer

Die Phrase “artificial intelligence” kostet auf Englisch nur 2 Tokens. Wie viel kostet dasselbe Konzept in anderen Sprachen?

Deutsch kostet ungefähr doppelt so viele Tokens wie Englisch für denselben Inhalt. Das bedeutet, ein deutscher Prompt verbraucht das Kontextfenster etwa doppelt so schnell. Er kostet doppelt so viel pro API-Aufruf. Und lässt weniger Raum für die Schlussfolgerungen des Modells.

Für Hindi beträgt das Verhältnis 5×. Für Burmesisch kann es 8× betragen. Dasselbe Modell, dasselbe Kontextfenster, derselbe Preis — aber 4- bis 8-mal weniger nutzbarer Inhalt für über eine Milliarde Sprecher:innen dieser Sprachen.

18.2 Warum das passiert

Die Ursache sind die Trainingsdaten. Der Trainingskorpus eines typischen Tokenizers besteht zu etwa 85 % aus englischem Text, wobei die verbleibenden 15 % auf alle anderen Sprachen verteilt sind. Während des BPE-Trainings sieht der Algorithmus Millionen englischer Wörter und lernt hocheffiziente Subword-Einheiten für sie. Häufige englische Wörter überleben als einzelne Tokens. Englische Morphologie ist gut repräsentiert.

Deutsche Komposita, Hindi-Konjunktkonsonanten und burmesische Schriftsequenzen sind in diesen englisch-dominierten Trainingsdaten selten. Sie werden nie zu effizienten Tokens zusammengeführt. Sie bleiben fragmentiert — in einzelne Bytes oder kleine Stücke aufgeteilt, die das Modell wieder zusammensetzen muss.

18.3 Die praktischen Auswirkungen

Das wirkt sich auf alles aus:

• Kontextfenster: Ein 200.000-Token-Fenster fasst grob 150.000 Wörter Englisch. Für Deutsch fasst es ungefähr 100.000 Wörter äquivalenten Inhalts. Für Hindi könnte es 30.000 Wörter fassen.
• API-Kosten: Wenn ein englischer API-Aufruf 1 $ kostet, kostet derselbe Aufruf auf Deutsch ~1,50–2,00 $. Auf Hindi ~4–5 $.
• Antwortqualität: Längere Token-Sequenzen bedeuten mehr Attention-Berechnung, mehr Raum für Fehler und mehr Druck auf das Kontextfenster.

18.4 Fortschritt, aber die Lücke bleibt

Die Situation verbessert sich. LLaMA 3 halbierte die Token-Anzahl für Hindi im Vergleich zu LLaMA 2, indem es auf deutlich mehr mehrsprachigen Daten trainierte. GPT-4o erweiterte sein Vokabular auf 200.000 Tokens, teilweise um nicht-englische Sprachen besser zu akkommodieren. Aber die grundlegende Lücke bleibt bestehen. Das ist keine Modell-Verzerrung — es ist eine Tokenizer-Verzerrung, die bereits beim allerersten Schritt der Pipeline eingebacken wird.

Rätsel 2 — GELÖST. Warum waren englische Prompts besser als deutsche? Token-Effizienz. Englischer Text verwendet grob ein Token pro Wort. Deutsch verwendet grob 1,3 bis 1,5 Tokens pro Wort. Derselbe Prompt auf Deutsch verbraucht mehr vom Kontextfenster, kostet mehr pro API-Aufruf und lässt weniger Raum für die Schlussfolgerungen des Modells. Verstärkt wird das dadurch, dass die Trainingsdaten überwiegend englisch sind.

Sie werden das selbst in der Laborübung verifizieren: Tokenisieren Sie denselben Satz auf Englisch und Deutsch, zählen Sie die Tokens und sehen Sie den Unterschied direkt.

19. Wenn die Karte kein Territorium hat: Glitch-Tokens

Im Januar 2023 entdeckten Forscher:innen etwas Bizarres. Bestimmte Tokens im Vokabular von GPT bringen das Modell dazu, völligen Unsinn zu produzieren.

Wenn Sie dem Modell den Prompt “Please repeat the following word: SolidGoldMagikarp” geben, wiederholt das Modell ihn nicht. Stattdessen sagt es vielleicht “Distribute” oder produziert verstümmelte Ausgaben. Das Token TheNitromeFan verursacht einen ähnlichen Zusammenbruch. Diese werden Glitch-Tokens genannt — Tokens, die im Vokabular existieren, aber das Modell zum Fehlverhalten bringen.

19.1 Warum sie existieren

Die Erklärung offenbart ein wichtiges architektonisches Detail: Der Tokenizer und das Modell werden auf unterschiedlichen Datensätzen trainiert.

Die Trainingsdaten des Tokenizers enthielten rohen Internet-Text — Reddit-Posts, Code-Repositories, Forum-Diskussionen, Web-Crawls. Als BPE auf diesen Daten lief, stieß es tausendfach auf den Reddit-Nutzernamen SolidGoldMagikarp (weil diese:r Nutzer:in in einem bestimmten Subreddit extrem aktiv war) und gab ihm ein eigenes Token.

Aber die Trainingsdaten des Modells waren kuratiert und gefiltert. Reddit-Nutzernamen wurden bereinigt. Das Modell sah das Token SolidGoldMagikarp während seines Trainings nie. Das Embedding für dieses Token wurde zufällig initialisiert — wie alle Embeddings — wurde aber nie aktualisiert während des Trainings. Es ist reines Rauschen.

Wenn dieses Token in einen Prompt gelangt, stört sein zufälliges Embedding den Transformer wie ein korruptes Signal in einem sauberen Datenstrom. Der Aufmerksamkeitsmechanismus des Modells versucht, einem Vektor Sinn abzuringen, der keine Bedeutung kodiert, und das Ergebnis ist eine unvorhersehbare Ausgabe.

19.2 Die Reddit-Verbindung

Die Verbindung ist bemerkenswert. Sechs der ursprünglichen Glitch-Tokens lassen sich auf aktive Nutzer:innen in r/counting zurückführen — einem Subreddit, der sich dem Zählen bis ins Unendliche widmet, ein Post nach dem anderen, fast ein Jahrzehnt lang. Ihre Nutzernamen tauchten so häufig in den Trainingsdaten des Tokenizers auf, dass BPE jedem ein eigenes Token gab. Aber als der sauberere Datensatz des Modells diese Posts ausschloss, wurden diese Tokens zu Waisen — Einträgen im Vokabular ohne gelernte Bedeutung.

19.3 Die Größenordnung

Eine Studie aus 2024 fand etwa 7.900 Glitch-Tokens über sieben große Modelle hinweg — etwa 4 % aller Tokens in einem typischen Vokabular. Die meisten davon sind harmlos (seltene Tokens, die das Modell teilweise gelernt hat). Aber einige verursachen echten Zusammenbruch.

GPT-4 adressierte das, indem es den Tokenizer von Grund auf neu aufbaute. SolidGoldMagikarp ist kein einzelnes Token mehr — es spaltet sich nun in Subwords wie Solid, Gold, Mag, ik, arp auf. Aber das grundlegende Problem — die enge Kopplung zwischen Tokenizer und Modell — bleibt eine Entwurfsspannung in allen aktuellen Architekturen.

Die Lehre: Ein Token ohne trainiertes Embedding ist wie ein Wort in einem Wörterbuch ohne Definition. Schlimmer als nutzlos — aktiv irreführend.

20. Wie Code tokenisiert wird

Alles bisher hat Beispiele aus natürlicher Sprache verwendet — Erdbeeren, deutsche Sätze, Arithmetik. Aber das ist ein Kurs über KI-gestützte Softwareentwicklung. Code hat seine eigenen Tokenisierungs-Eigenschaften, und sie beeinflussen direkt, wie gut Ihre KI-Werkzeuge funktionieren.

20.1 Einrückung ist teuer

Python verwendet Leerraum für Struktur. Jede Einrückungsebene kostet Tokens — und im Gegensatz zu den Wörtern, die sie einrücken, tragen diese Leerraum-Tokens strukturelle Bedeutung, aber keinen semantischen Inhalt.

Eine flache Funktion könnte 20 Tokens kosten. Dieselbe Logik, drei Ebenen tief verschachtelt, könnte 30 Tokens kosten — zehn Tokens, die rein für Einrückung verwendet werden. In einem Kontextfenster von 200.000 Tokens fühlt sich das vernachlässigbar an. Aber in einer langen Coding-Sitzung, in der Claude Code Dutzende Dateien gelesen hat, summieren sich Einrückungsleerräume über hunderte Funktionen auf tausende Tokens, die für tatsächlichen Inhalt hätten verwendet werden können.

Die praktische Implikation: Kürzerer, flacherer Code gibt dem Modell mehr Raum für Schlussfolgerungen. Das ist nicht nur eine Stilpräferenz — es ist eine Token-Budget-Entscheidung.

20.2 Namenskonventionen beeinflussen Token-Kosten

Wie Sie Ihre Variablen und Funktionen benennen, ändert, wie der Tokenizer sie aufspaltet.

Betrachten Sie eine Funktion namens calculateAverageScore. In camelCase erkennt der Tokenizer den ganzen Namen vielleicht als ein oder zwei Tokens — gängige Muster wie calculate und Average sind in den Trainingsdaten gut vertreten. Aber calculate_average_score in snake_case spaltet fast sicher an jedem Unterstrich auf und produziert mehr Tokens.

Der Unterschied ist nicht nur Kosten — er beeinflusst Wahrnehmung. Wenn ein Funktionsname ein Token ist, sieht das Modell ihn als atomares Konzept. Wenn er in drei oder vier Tokens aufspaltet, muss das Modell die Bedeutung aus Stücken rekonstruieren. Das ist dasselbe Phänomen wie das Strawberry-Problem: Information, die über Token-Grenzen verläuft, ist für das Modell schwerer zu verarbeiten.

Sie werden das direkt im Tokenizer-Playground-Notebook verifizieren, indem Sie Bezeichner in verschiedenen Namenskonventionen tokenisieren.

20.3 Boilerplate ist billig, neuartiger Code ist teuer

Der Tokenizer lernte seine Merge-Regeln aus Milliarden von Code-Zeilen. Häufige Muster wurden zu effizienten Tokens zusammengeführt. Seltene Muster nicht.

def __init__(self): ist in Python-Trainingsdaten so häufig, dass es zu sehr wenigen Tokens komprimiert wird — vielleicht 5 oder 6. Aber eine domänenspezifische Signatur wie def calibrate_magnetometer(readings: list[SensorDatum]) könnte 12+ Tokens sein, weil magnetometer und SensorDatum im Trainingskorpus selten sind.

Das hat eine direkte Konsequenz für die Codegenerierung: Das Modell sieht Boilerplate mit hoher Auflösung und neuartigen Code mit niedriger Auflösung. Jedes häufige Muster ist ein einzelnes, gut verstandenes Token. Jeder neuartige Bezeichner ist eine Folge von Subword-Stücken, die das Modell im Kontext interpretieren muss.

Das ist einer der Gründe, warum KI-Coding-Werkzeuge hervorragend Boilerplate generieren (__init__, __str__, standardmäßige CRUD-Operationen), aber mit neuartiger Domänenlogik kämpfen — der Tokenizer gibt dem Modell ein klareres Signal für die häufigen Muster.

20.4 Programmiersprachen unterscheiden sich

Java’s public static void main(String[] args) kostet mehr Tokens als das Python-Äquivalent. Jedes Schlüsselwort (public, static, void) ist ein separates Token. Die Typannotationen, Klammern und Semikolons addieren sich.

Das ist das Programmiersprachen-Äquivalent zur mehrsprachigen Lücke aus Kapitel 17. Dieselbe Logik, in einer verbosen Sprache ausgedrückt, verbraucht mehr vom Kontextfenster als dieselbe Logik in einer prägnanten Sprache. Wenn das Modell Java generiert, hat es weniger verbleibendes Budget für Schlussfolgerungen als beim Generieren von Python.

Im Tokenizer-Playground-Notebook (Kapitel 24) haben Sie bereits Python- und Java-Funktionssignaturen verglichen. Die weitergehende Implikation: Die Sprachwahl beeinflusst, wie viel Kontext das Modell halten kann — nicht weil das Modell voreingenommen ist, sondern weil der Tokenizer verschiedene Sprachen mit unterschiedlicher Effizienz komprimiert.

20.5 Kommentare als Kontext

Natürlichsprachige Kommentare und Code werden vom selben Tokenizer tokenisiert, aber sie spielen unterschiedliche Rollen. Kommentare verbrauchen Tokens (Kosten) liefern dem Modell aber explizite Beschreibungen der Absicht (Wert). Das ist genau derselbe Kompromiss wie CLAUDE.md: Jedes Token Anleitung ist ein Token, das nicht für Code-Kontext ausgegeben wurde.

Eine gut kommentierte Datei könnte 30 % mehr Tokens kosten als dieselbe Datei ohne Kommentare. Aber diese Kommentare sagen dem Modell, was der Code tun soll, reduzieren Halluzinationen und verbessern die Generierungsqualität. Ob die Token-Kosten es wert sind, hängt von der Aufgabe ab — für ein einfaches Umbenennen sind Kommentare Overhead; für die Implementierung eines komplexen Algorithmus sind sie essenzieller Kontext.

Die Faustregel: Kommentieren Sie für das Modell auf dieselbe Weise, wie Sie für ein neues Teammitglied kommentieren würden. Erklären Sie das Warum, nicht das Was. Das Modell kann sehen, was der Code tut (es verarbeitet die Tokens). Es kann nicht sehen, warum Sie ihn so geschrieben haben — es sei denn, Sie sagen es ihm.

20.6 Tokenizer, die für Code gebaut sind

Alles in §20.1–20.5 nahm einen allgemeinen Tokenizer an, der hauptsächlich auf Webtext mit eingemischtem Code trainiert wurde — cl100k_base (GPT-3.5/GPT-4), o200k_base (GPT-4o) oder ein SentencePiece-Modell der Llama-Familie. Code-fokussierte Labore schlagen manchmal einen anderen Weg ein. Hier ist, was sich ändert, wenn sie das tun.

Zwei Muster in der Produktion. Beim Bau eines code-spezialisierten Modells können Sie entweder einen allgemeinen Tokenizer übernehmen oder einen neuen auf code-lastigen Daten trainieren. Beide sind unter den Frontier-Code-Modellen vertreten:

• Code Llama (Meta) — verwendete den SentencePiece-BPE-Tokenizer von Llama 2 unverändert. Das Team fügte nur eine Handvoll Fill-in-the-Middle-Spezial-Tokens hinzu (<FIM_PREFIX>, <FIM_SUFFIX>, <FIM_MIDDLE>), damit das Modell Text in der Mitte einer Datei vervollständigen kann, nicht nur am Ende anhängen. Das Vokabular blieb identisch; die Spezial-Tokens sind reine Ergänzungen.
• StarCoder2 (Lozhkov et al., 2024, arXiv:2402.19173) — trainierte einen vollständig eigenen Tokenizer auf The Stack v2: 67,5 TB Quellcode über 619 Programmiersprachen. Das resultierende Vokabular hat sichtbar mehr Einrückungs-Tokens, Klammer-Muster, sprachspezifische Schlüsselwörter und gängige Funktionsnamen — direkt optimiert für die Schmerzpunkte aus §20.1–20.4.
• DeepSeek Coder trainierte ebenfalls für eine code-lastige Mischung neu.
• Der originale Codex (das erste GitHub Copilot Modell) verwendete den allgemeinen Tokenizer von GPT-3 unverändert, obwohl er ein Code-Spezialist war — Beweis dafür, dass “neu trainieren” nicht automatisch ist.

Was sich ändert, wenn der Tokenizer Code kennt. Dieselbe Python-Datei durch einen allgemeinen Tokenizer und durch den code-spezialisierten Tokenizer von StarCoder2 laufen zu lassen, legt Unterschiede offen, die fast 1:1 auf §20.1–20.5 abbilden:

• Einrückung wird billig. Vier Leerzeichen Python-Einrückung ist ein gut optimiertes Token, kein Bytemuster, das opportunistisch zusammengeführt wurde.
• Häufige Bezeichner werden aggressiver zusammengeführt. Namen wie calculate_average_score, die in einem web-trainierten Tokenizer fragmentieren, komprimieren oft zu weniger Tokens, wenn der Tokenizer Zusammenführungen aus einem code-dichten Korpus gelernt hat.
• Sprachspezifische Syntax bekommt erstklassige Behandlung. StarCoder2s Vokabular enthält einzelne Tokens für häufiges Rust (fn main(), impl), Java-Boilerplate (public static void main) und JSX-Muster — Konstrukte, die ein web-trainierter Tokenizer nur sporadisch sieht.
• Die Programmiersprachen-Lücke aus §20.4 schrumpft, weil The Stack v2 den Tokenizer hunderten Sprachen proportional aussetzt, nicht nur den populären wenigen.

Fill-in-the-Middle: eine Fallstudie zu Spezial-Tokens. FIM demonstriert, wie kleine Vokabular-Ergänzungen neue Fähigkeiten erschließen. Wenn ein Code-Modell auf Eingaben trainiert wird, die wie <FIM_PREFIX>code_before<FIM_SUFFIX>code_after<FIM_MIDDLE> geformt sind, lernt es, zwischen zwei Cursorn zu infillen — genau das, was IDE-Copiloten brauchen. Diese drei Tokens sind keine BPE-gelernten Zusammenführungen; es sind reservierte IDs, die dem Vokabular von Hand hinzugefügt werden. Der Algorithmus ist identisch; nur das Inventar an Spezial-Tokens ändert sich.

Was das für Sie bedeutet. Der Tokenizer hinter Ihrem KI-Werkzeug ist einer seiner versteckten Leistungshebel:

• Claude Code, Cursor, GitHub Copilot laufen auf Frontier-Modellen (Claude, GPT-4o usw.) mit allgemeinen Tokenizern. Diese Modelle haben enorme Mengen Code im Training gesehen, sodass die Lücke zu einem Spezialisten kleiner ist, als Sie vermuten würden — aber sie existiert.
• Code-Spezialisten-Modelle (StarCoder2, DeepSeek Coder, Code Llama) komprimieren Code aggressiver und handhaben obskure Sprachen besser. Im Gegenzug komprimieren sie natürliche Sprache weniger gut und sind als Konversations-Assistenten weniger flexibel.

Kein einziger Tokenizer gewinnt überall. Die Wahl tauscht Code-Dichte gegen Allgemeinsprachen-Geschmeidigkeit — dieselbe Spannung zwischen verlustfrei und effizient aus §13.5, angewendet auf eine andere Achse. Beide Tokenizer sind verlustfrei; jeder ist für unterschiedliche Inhalte effizient.

Sie können all das direkt im Tokenizer-Playground-Notebook verifizieren: Lassen Sie ein repräsentatives Code-Snippet durch cl100k_base laufen, dann durch StarCoder2s Tokenizer (HuggingFace bigcode/starcoder2-15b). Der Token-Anzahl-Unterschied beträgt typischerweise 20–40 % — kleiner als Sie erwarten würden, aber messbar.

21. Die vollständige Reise: Von Text zum Transformer

Nun fügen wir alles zusammen. In Kapitel 6 haben Sie die vollständige Reise im Miniaturformat gesehen — von <BOS> dragon drinks zum vorhergesagten Token potion — mit einem Spielzeugvokabular von 10 Wörtern. Hier ist dieselbe Reise im realen Maßstab, mit allen sechs Stationen sichtbar, für einen einzelnen Satz.

Eingabe: "The tokenizer processes text."

21.1 Station 1: Vor-Tokenisierung

Bevor BPE läuft, spaltet ein Regex-Muster den Text an Wortgrenzen auf. Dieser Regex ist klüger als einfaches Aufteilen an Leerzeichen — er handhabt Kontraktionen (spaltet “don’t” in “do” und “n’t”), bewahrt führende Leerzeichen als Teil des nachfolgenden Wortes und trennt Interpunktion.

Unser Satz wird zu fünf Stücken: The, ` tokenizer, processes, text und .` (wobei das führende Leerzeichen Teil des Tokens ist, kein separater Entität).

21.2 Station 2: BPE-Segmentierung

Jedes Stück gelangt in die BPE-Engine, die ihre gelernten Merge-Regeln anwendet. Das Wort “tokenizer” ist nicht häufig genug, um als einzelnes Token zu überleben — es spaltet in token und izer. Aber “processes” und “text” sind häufig genug, um unversehrt durchzukommen.

21.3 Station 3: Token-ID-Zuweisung

Jedes Subword wird im Vokabular-Wörterbuch nachgeschlagen und einer eindeutigen Ganzzahl zugeordnet:

The → 464 | token → 11241 | izer → 7509 | processes → 7767 | text → 2420 | . → 13

21.4 Station 4: Einfügen von Spezial-Tokens

Ein End-of-Text-Marker wird angehängt: <|endoftext|>. Das sagt dem Modell, wo die Dokumentengrenze fällt. Verschiedene Modelle verwenden unterschiedliche Spezial-Tokens — BERT fügt ein Klassifikations-Token [CLS] am Anfang hinzu, T5 verwendet Sentinel-Tokens für seine Trainingsziele —, aber das Prinzip ist dasselbe: Spezial-Tokens tragen strukturelle Information, die der Text selbst nicht hat.

Die Sequenz ist nun: 464 | 11241 | 7509 | 7767 | 2420 | 13 | <eot>

21.5 Station 5: Embedding-Lookup

Das ist die kritische Brücke von Ganzzahlen zu Vektoren. Jede Token-ID indiziert in die Embedding-Matrix — diese 50.257-zeilige Tabelle, die 38,6 Millionen Parameter enthält. Sieben dichte Vektoren entstehen, jeder mit hunderten Dimensionen gelernter Bedeutung.

Die Ganzzahl 464 wird zu einem 768-dimensionalen Vektor, der die Bedeutung von “The” kodiert. Die Ganzzahl 11241 wird zu einem Vektor, der “token” kodiert. Und so weiter. Der ursprüngliche Text ist nun weg — was bleibt, ist eine Folge numerischer Repräsentationen.

21.6 Station 6: Positionskodierung

Ein Wellenmuster wird jedem Vektor überlagert und kodiert die Position dieses Tokens in der Sequenz. Ohne das würde das Modell dieselbe Menge an Vektoren unabhängig von der Wortreihenfolge sehen — “The cat sat” und “sat cat the” wären nicht unterscheidbar.

Nach der Positionskodierung kodiert jeder Vektor sowohl, was das Token bedeutet, als auch, wo es in der Sequenz sitzt.

21.7 Der Transformer empfängt

Und nun fließt die finale Sequenz — sieben reichhaltige, informationsdichte Vektoren — in den Transformer. Das, nicht Ihr Text, ist es, was das Modell tatsächlich verarbeitet. Der Self-Attention-Mechanismus wird diese Vektoren vergleichen, die Feed-Forward-Schichten werden sie transformieren, und die Ausgabeschicht wird sie verwenden, um das nächste Token vorherzusagen.

Alles, was das Modell über Ihre Eingabe weiß, kam durch diese Pipeline. Jede Verzerrung im Tokenizer, jeder blinde Fleck im Vokabular, jede Inkonsistenz, wie Zahlen oder nicht-englischer Text aufgespalten werden — all das wird in jede Schicht des Modells weitergetragen.

Tokenisierung ist keine Vorverarbeitung. Sie ist die erste Schicht der Architektur.

22. Was das für CLAUDE.md bedeutet

Kehren wir kurz zu Rätsel 1 zurück, das wir am Anfang dieser Vorlesung gestellt haben: Warum hat CLAUDE.md die Ergebnisse verbessert?

Wir können das noch nicht vollständig beantworten — die komplette Antwort erfordert das Verständnis des Aufmerksamkeitsmechanismus (Vorlesung 5) und der Orchestrierungsschicht (Vorlesung 7). Aber wir können nun etwas Wichtiges sagen:

CLAUDE.md ist Text. Text wird zu Tokens. Tokens werden zu Vektoren. Vektoren gelangen in den Transformer.

Als Sie in Vorlesung 3 eine 50-zeilige CLAUDE.md für das Locust-Projekt geschrieben haben, wurde diese Datei nicht in irgendein spezielles Konfigurationssystem geladen. Sie wurde nicht von einer Regel-Engine geparst. Sie wurde durch genau dieselbe BPE-Pipeline, die wir gerade beschrieben haben, in etwa 200-500 Tokens umgewandelt. Diese Tokens wurden dann in dieselbe Sequenz wie Ihr Prompt eingefügt, durch dasselbe Embedding-Lookup verarbeitet, mit derselben Positionsinformation kodiert und in denselben Transformer eingespeist.

Aus der Perspektive des Modells gibt es keinen Unterschied zwischen CLAUDE.md-Tokens und Ihren Frage-Tokens. Beide sind nur Text in der Sequenz. Es gibt kein spezielles “Anweisungs-Flag”. Die Unterscheidung zwischen “Projektanweisungen” und “Benutzerfrage” existiert nur in der Software, die das Modell verwaltet — nicht im Modell selbst.

Das ist der erste Hinweis auf Rätsel 1. Wir werden die Antwort über die nächsten drei Vorlesungen vervollständigen.

23. Wichtige Erkenntnisse

Fünf Dinge, die Sie aus dieser Vorlesung mitnehmen sollten:

Tokenisierung ist die Brücke zwischen menschlicher Sprache und neuronaler Berechnung. Text wird zu Ganzzahlen. Ganzzahlen werden zu Vektoren. Vektoren werden zu den Repräsentationen, mit denen der Transformer arbeitet. Jedes Modell beginnt hier. Und Tokenisierung ist immer zweierlei: ein Vokabular (die Menge erlaubter Tokens) und eine Kodierungsfunktion (der Algorithmus, der Text in diese Tokens aufspaltet). Das Vokabular allein reicht nicht — ohne die Kodierungsregeln ist die Aufspaltung mehrdeutig.

Subword-Tokenisierung ist der universelle Standard. Sie hält häufige Wörter ganz, während sie seltene Wörter in wiederverwendbare Bausteine zerlegt. BPE ist der dominierende Algorithmus — es löst sowohl das Vokabular- als auch das Kodierungsproblem gleichzeitig durch geordnete Merge-Regeln. WordPiece und Unigram sind brauchbare Alternativen, die dieselben zwei Probleme mit unterschiedlichen Strategien lösen.

Die Konsequenzen sind real und messbar. Arithmetik-Versagen lässt sich direkt auf inkonsistente Zahlen-Tokenisierung zurückführen. Nicht-Englisch-Sprechende zahlen 2-8-mal mehr Tokens für denselben semantischen Inhalt. Glitch-Tokens entstehen, wann immer die Trainingsdaten von Tokenizer und Modell divergieren. Das sind keine Modell-Bugs — das sind Tokenizer-Bugs.

Vokabulargröße ist ein Engineering-Kompromiss. Kleinere Vokabulare bedeuten längere Sequenzen und teurere Attention. Größere Vokabulare bedeuten mehr Parameter und höhere Speicherkosten. Der Branchentrend geht zu größeren Vokabularen, während Modelle wachsen.

Tokenisierung ist Architektur. Sie ist kein Detail, das Sie gefahrlos ignorieren können. Sie prägt, was das Modell sieht, wie viel es im Kontext halten kann und genau, wo es stolpern wird. Wenn ein Sprachmodell Sie das nächste Mal überrascht — denken Sie daran, was der Tokenizer zuerst getan hat.

Und eine zukunftsweisende Anmerkung: Das Feld erkundet aktiv, ob Tokenisierung vollständig eliminiert werden kann. Metas Byte Latent Transformer erreicht bereits die Leistung von LLaMA 3, während er auf rohen Bytes operiert — ganz ohne Tokenizer. Ob dieser Ansatz skaliert, bleibt eine offene Frage.

24. Mystery Board Update

Lassen Sie uns prüfen, wo wir stehen. Das vollständige Mystery Board verfolgt alle Rätsel durch Akt II — schauen Sie nach jeder Vorlesung dort vorbei, um den aktuellen Fortschritt zu sehen.

Ein Rätsel gelöst. Zwei teilweise beantwortet. Drei noch offen. Nächste Woche öffnen wir die Transformer-Box und sehen, wie diese Token-Vektoren tatsächlich die Modellausgabe beeinflussen.

25. Lab: Der Tokenizer Playground

Jetzt sind Sie an der Reihe. Der Rest dieser Sitzung ist praktisch. Sie werden interaktive Jupyter-Notebooks durcharbeiten, mit denen Sie Tokenizer erkunden, Modelle vergleichen und die Phänomene aus dieser Vorlesung empirisch entdecken können.

25.1 Notebook: Tokenizer Playground

Öffnen Sie das Tokenizer Playground-Notebook. Dieses Notebook erfordert tiktoken und transformers — öffnen Sie es in Google Colab über das Badge im Notebook. Sie werden:

• Text mit GPT-4os Tokenizer tokenisieren und genau sehen, wo die Aufteilungen fallen
• Tokenizer über Frontier-Modelle vergleichen (GPT-4o, LLaMA 3, Gemma 2)
• Die mehrsprachige Token-Lücke zwischen Englisch und Deutsch messen
• Erkunden, wie Code tokenisiert wird — Einrückungskosten, Namenskonventionen, Boilerplate vs. neuartiger Code
• In Vokabulare eintauchen — das längste Token finden, nach Glitch-Tokens jagen
• Das Kontextfenster-Budget für Ihre CLAUDE.md aus Vorlesung 3 schätzen

Arbeiten Sie das Notebook von oben nach unten durch. Jeder Abschnitt enthält Fragen, die beantwortet werden müssen — sammeln Sie Ihre Erkenntnisse für die unten genannten Abgaben.

25.2 Notebook: BPE von Grund auf bauen (Selbststudium)

Das BPE bauen-Notebook ist eine Selbststudien-Übung, die direkt in Ihrem Browser läuft (keine Installation erforderlich). Sie werden den BPE-Algorithmus Schritt für Schritt implementieren — Bytepaare zählen, das häufigste zusammenführen, einen Encoder und Decoder bauen. Am Ende werden Sie einen funktionierenden Tokenizer haben, den Sie selbst gebaut haben.

Dieses Notebook ist optional, aber sehr empfehlenswert. Den Algorithmus zu bauen, macht alles in den Kapiteln 10-11 konkret.

25.3 Abgaben

Dokumentieren Sie Ihre Erkenntnisse aus dem Tokenizer Playground in einem KI-Tagebucheintrag:

• Mindestens 5 überraschende Tokenisierungsergebnisse mit Erklärungen
• Den Englisch-Deutsch-Token-Anzahl-Vergleich mit Ihrem berechneten Verhältnis
• Ihre Schätzung des CLAUDE.md-Token-Budgets — wie viel des Kontextfensters verbraucht sie?