04 Vorlesung 4 Quiz: Tokenisierung - Wie Maschinen lesen

Ein LLM ist eine Maschine zur Vorhersage des nächsten Tokens: Es berechnet eine Wahrscheinlichkeitsverteilung über sein Vokabular, wählt ein Token, hängt es an und wiederholt den Vorgang. Es gibt keinen Planungsschritt (A), kein Abrufen aus einer gespeicherten Antwortdatenbank (B) und keine globale Suche über vollständige Ausgaben (D) — nur wiederholte lokale Vorhersage. Jede Codezeile und jeder Absatz entsteht aus dieser einzigen Schleife.

Innerhalb des Transformers gibt es keine Wörter und keine Buchstaben — nur Tensoren aus Gleitkommazahlen. Jede Operation (Matrixmultiplikation, Attention, Aktivierung) nimmt Zahlen entgegen und erzeugt Zahlen. Symbole wie def haben keine inhärente numerische Bedeutung — Sie können def nicht mit return multiplizieren. Komprimierung (B) ist bestenfalls ein Nebeneffekt; Tokenisierung ist keine Verschlüsselung (D); die universelle Repräsentation (C) ist eine Folge, nicht die Ursache.

Die Pipeline ist Text → Tokenizer → ganzzahlige Token-IDs → Embedding-Lookup → dichte Vektoren → Transformer. Der Tokenizer wandelt Text zunächst in Ganzzahlen um; diese Ganzzahlen indizieren dann in die Embedding-Matrix und erzeugen die dichten Vektoren, die der Transformer tatsächlich verarbeitet. Option A vertauscht Tokenisierung und Embedding-Lookup. Die Optionen C und D platzieren den Transformer vor dem Embedding-Lookup, was unmöglich ist — der Transformer benötigt die dichten Vektoren als Eingabe.

Die Vorlesung nennt drei Probleme der wortbasierten Tokenisierung: Vokabularexplosion, fehlendes morphologisches Bewusstsein (A) und das Problem unbekannter Wörter (D) — und bezeichnet das letzte als „den eigentlichen Killer”. Jedes ungesehene Wort wird zu [UNK], und die Bedeutung ist für immer verloren. Morphologisches Bewusstsein (A) ist ein reales Anliegen, aber das Modell kann dies teilweise aus dem Kontext kompensieren. Interpunktion (B) und chinesische Segmentierung (C) sind lösbare Engineering-Probleme; UNK ist ein nicht wiederherstellbarer Informationsverlust.

Die Attention-Kosten wachsen mit O(N²) in der Sequenzlänge. Eine Verdopplung der Token macht Attention 4× teurer. Ein Absatz mit 500 Wörtern wird zu ~2.500 Zeichen-Token — eine 25-fache Kostensteigerung gegenüber der Wortebene. Zeichenbasierte Tokenisierung tauscht Vokabularexplosion gegen Sequenzexplosion ein. Option A ist falsch (Zeichen tragen zur Bedeutung bei, wenn sie zusammengesetzt werden); C und D sind schlicht sachlich falsch.

Tokenisierung besteht aus zwei Dingen: einem Vokabular (den erlaubten Token) und einer Kodierungsfunktion (dem Algorithmus, der Text in diese Token zerlegt). Das Vokabular allein genügt nicht — wenn t, h, e, th und the alle in V enthalten sind, sind mehrere Zerlegungen von „the” gültig (t|h|e vs. th|e vs. the). BPE löst beide Probleme mit seinen geordneten Merge-Regeln. Die Vokabulargröße (A) ist ein Hyperparameter, nicht das zweite Kernproblem; Sprachauswahl (B) und das Modelltraining (C) sind separate Belange.

BPE ist rein häufigkeitsgesteuert. Es scannt den Korpus, zählt jedes benachbarte Paar und führt das häufigste zusammen — kein linguistisches Wissen erforderlich. Das Likelihood-Verhältnis-Kriterium (A) ist genau das, was WordPiece von BPE unterscheidet. Expertenregeln (C) sind der regelbasierte Ansatz, den die Vorlesung ausdrücklich verworfen hat. Zufälligkeit (D) würde den Zweck des Erlernens nützlicher Merges zunichtemachen.

Der trainierte Tokenizer trainiert nicht erneut (A). Er spielt die Merge-Regeln in Trainingsreihenfolge ab — Regel #1 greift zuerst (das während des Trainings häufigste Paar), dann Regel #2 und so weiter. Dies sieht oft wie Longest Match (B) aus, aber der Mechanismus ist grundlegend eine geordnete Folge von Umschreibungsregeln, die eine andere Segmentierung erzeugen kann als eine gierige Longest-Match-Suche. Aufteilung an Leerraum (D) ist der wortbasierte Ansatz, den BPE ersetzt.

Token sind atomar — die kleinste Einheit, die das Modell wahrnehmen kann. Wenn „strawberry” in str, aw, berry zerlegt wird, sieht das Modell drei undurchsichtige Stücke, nicht zehn Buchstaben. Es hat keinen Mechanismus, um in ein Token hineinzuschauen und Zeichen zu zählen. Die Häufigkeit in den Trainingsdaten (A) ist irrelevant — das Wort ist gängig. Die Zählkosten (B) sind nicht der Engpass; selbst kurze tokenisierte Eingaben erzeugen falsche Zählungen. Eine Sicherheitsverweigerung (C) findet nicht statt — das Modell erzeugt selbstbewusst die falsche Antwort.

Ein Byte besteht aus 8 Bit, also 2^8 = 256 mögliche Werte (0–255). UTF-8 reduziert jedes Unicode-Zeichen — jedes Schriftsystem, jedes Emoji, jedes noch hinzuzufügende Symbol — auf eine Folge dieser Bytes, sodass die 256 Basis-Token jede mögliche Eingabe konstruktionsbedingt abdecken. ASCII hat nur 128 Zeichen (A ist falsch). GPU-Register (C) haben nichts mit dem Vokabulardesign zu tun. Die Wahl ist mathematisch, nicht empirisch (D).

Dies ist die zentrale Unterscheidung zwischen verlustfrei und effizient. Byte-Level-BPE ist konstruktionsbedingt kodierungs-verlustfrei — das 256-Byte-Basisvokabular deckt jede mögliche Byte-Sequenz ab. Ein neues Emoji verwendet einfach 4 Basis-Byte-Token statt des einen Tokens, das ein frisch trainierter Tokenizer ihm möglicherweise zuweisen würde. Es geht keine Information verloren (also sind B und C falsch); Tokenizer sind statische Artefakte, die sich nicht selbst neu trainieren (D). Die Kosten betreffen die Effizienz, nicht die Korrektheit.

Beide sind Bottom-up-Algorithmen, die iterativ Paare zusammenführen, daher liegt der Unterschied im Merge-Kriterium. BPE wählt das häufigste Paar; WordPiece wählt das Paar, dessen gemeinsames Auftreten relativ zur Einzelhäufigkeit jedes Teils am überraschendsten ist. WordPiece bevorzugt charakteristische Bindungen (wie Q-U im Englischen). Top-down-Pruning (B) beschreibt Unigram, nicht WordPiece. Beide Algorithmen sind unüberwacht (D ist falsch). Byte vs. Zeichen (A) ist eine separate Designachse.

Die Embedding-Matrix hat eine Zeile pro Vokabulareintrag, sodass die Vokabulargröße ihre Parameteranzahl direkt bestimmt. Die Embedding-Matrix von LLaMA 3 ist 128.000 × 4.096 ≈ 525M Parameter; zusammen mit der Output-Projektion identischer Form sind das ~1,05 Milliarden Parameter — etwa 13% des gesamten 8B-Parameter-Modells. Die Kosten des Tabellen-Lookups (A) sind O(1) und vernachlässigbar. Overfitting (C) ist keine automatische Folge. Die Trainingsdaten (D) müssen zwar für seltene Token ausreichen, aber es gibt keine feste Vervierfachungsregel.

Der Tokenizer teilt Zahlen durch häufigkeitsbasierte Merges, nicht nach Stellenwert. 2249 ist 2+249; 2250 ist 22+50; 2251 ist 225+1 — drei nahezu identische Zahlen, drei völlig unterschiedliche interne Repräsentationen. Die Token-Grenzen verlaufen quer durch die Stellenwert-Spalten, von denen die Arithmetik abhängt. Die Gleitkommagenauigkeit (A) ist mehr als ausreichend. Arithmetikbeispiele (B) sind in den Trainingsdaten reichlich vorhanden. Eine Sicherheitsverweigerung (C) findet nicht statt — das Modell erzeugt selbstbewusst falsche Antworten. Gemma behob dies, indem es eine Ziffer pro Token erzwang.

Die Ursache ist die Zusammensetzung der Trainingsdaten, nicht der Algorithmus oder das Modell. BPE führt Muster zusammen, die es oft sieht. Mit ~85% englischen Trainingsdaten erhalten englische Muster effiziente Merges; deutsche Komposita, Hindi-Ligaturen und burmesische Schriften bleiben fragmentiert. Die Kosten können 2× im Deutschen, 5× im Hindi und 8× im Burmesischen erreichen — dasselbe Kontextfenster, derselbe API-Preis, weit weniger nutzbarer Inhalt. Die Alphabetgröße (A) ist gegenüber der Merge-Effizienz ein Nebenaspekt. Architektur-Bias (C) und UTF-16-Speicherung (D) sind schlicht falsch.

Der Tokenizer und das Modell werden auf verschiedenen Datensätzen trainiert. Reddit-Inhalte gaben BPE Tausende von Vorkommen von SolidGoldMagikarp (ein Benutzername), was ihm ein eigenes Token einbrachte. Der saubere Trainingssatz des Modells schloss diesen Inhalt aus, sodass die Embedding-Zeile zufällig initialisiert und nie aktualisiert wurde. Das zufällige Embedding des Tokens stört das Modell wie Rauschen. Honeypots (B), reservierte Anweisungen (C) und beschädigte Einträge (D) sind nicht die Funktionsweise — der Vokabulareintrag ist gültig; nur sein Embedding ist untrainiert.

Der Tokenizer hat seine Merges aus Milliarden von Codezeilen gelernt. Häufige Muster (def __init__, gängige Bibliotheksaufrufe) wurden zu effizienten kurzen Token; seltene domänenspezifische Namen (calibrate_magnetometer) nicht. Das Modell „sieht” Boilerplate in hoher Auflösung und neuartigen Code in niedriger Auflösung. Schlüsselwörter werden nach Häufigkeit zusammengeführt, nicht mit Sonderstatus versehen (A). Einrückung kostet echte Token (B ist falsch). Verschiedene Namenskonventionen werden sehr unterschiedlich aufgeteilt — snake_case zerfällt typischerweise an den Unterstrichen (D ist falsch).

CLAUDE.md ist Text. Text wird durch denselben BPE-Tokenizer zu Token; diese Token werden durch denselben Embedding-Lookup zu Vektoren; diese Vektoren gelangen in denselben Transformer in derselben Sequenz wie der Nutzer-Prompt. Es gibt keine Regel-Engine (B), keinen separaten Anweisungskanal (C) und keine Signaturverifikation (D) — die Unterscheidung zwischen „Projektanweisungen” und „Nutzerfrage” existiert nur in der Software rund um das Modell, nicht im Modell selbst. Dies ist der erste Hinweis darauf, warum CLAUDE.md funktioniert (und manchmal nicht).