Home

04 Vorlesung 4 Quiz: Tokenisierung - Wie Maschinen lesen

April 2026 (3124 Words, 18 Minutes)

quiz tokenization bpe embeddings byte-level unicode multilingual

Neu: Interaktives Quiz verfügbar!

Möchten Sie Ihren Fortschritt verfolgen und sofortiges Feedback erhalten? Probieren Sie unsere neue interaktive Version mit Fortschrittsverfolgung, sofortigen Erklärungen und Punkteberechnung.

Interaktives Quiz starten →

Anleitung

Frage 1: Der Kernmechanismus

Was tut ein Large Language Model (LLM) auf der grundlegendsten Ebene, wenn es Text generiert?

A) Es parst den Prompt in einen abstrakten Syntaxbaum, plant eine Antwort und schreibt sie dann aus
B) Es ruft die am besten passende Antwort aus einer komprimierten Datenbank von Trainingsbeispielen ab
C) Es sagt das wahrscheinlichste nächste Token voraus, hängt es an die Sequenz an und wiederholt dies — ein Token nach dem anderen
D) Es führt einen Suchalgorithmus über mögliche Ausgaben aus und gibt die vollständige Antwort mit der höchsten Punktzahl zurück

Antwort anzeigen

Richtige Antwort: C

Ein LLM ist eine Maschine zur Vorhersage des nächsten Tokens: Es berechnet eine Wahrscheinlichkeitsverteilung über sein Vokabular, wählt ein Token aus, hängt es an und wiederholt dies. Es gibt keinen Planungsschritt (A), keinen Abruf 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.

Frage 2: Warum tokenisieren

Warum muss Text in Zahlen umgewandelt werden, bevor er den Transformer erreicht?

A) Neuronale Netze arbeiten mit numerischen Tensoren — sie besitzen keinen Mechanismus, um rohe Symbole wie Buchstaben oder Wörter zu verarbeiten
B) Zahlen komprimieren Text wesentlich effizienter als Zeichen und reduzieren so den Speicherverbrauch während des Trainings
C) Verschiedene Sprachen verwenden unterschiedliche Alphabete, daher bieten Zahlen eine universelle Repräsentation
D) Der Transformer benötigt verschlüsselte Eingaben, und Tokenisierung ist die übliche Verschlüsselungsschicht

Antwort anzeigen

Richtige Antwort: A

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

Frage 3: Die vollständige Pipeline

Welche Reihenfolge beschreibt korrekt, wie Text den Transformer erreicht?

A) Rohtext → Embedding-Lookup → Token-IDs → Transformer
B) Rohtext → Token-IDs → Embedding-Lookup → Transformer
C) Rohtext → Transformer → Token-IDs → Embedding-Lookup
D) Rohtext → Token-IDs → Transformer → Embedding-Lookup

Antwort anzeigen

Richtige Antwort: B

Die Pipeline ist Text → Tokenizer → ganzzahlige Token-IDs → Embedding-Lookup → dichte Vektoren → Transformer. Der Tokenizer wandelt Text zunächst in ganze Zahlen um; diese Zahlen 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.

Frage 4: Probleme der wortbasierten Tokenisierung

Was ist das katastrophalste Problem der wortbasierten Tokenisierung für moderne Sprachmodelle?

A) Wortbasierte Tokenizer erfassen morphologische Beziehungen zwischen verwandten Wörtern wie run und running nicht
B) Wortbasierte Tokenizer können Satzzeichen oder Leerräume nicht korrekt verarbeiten
C) Sprachen ohne durch Leerzeichen getrennte Wörter wie Chinesisch können nicht auf Wortebene tokenisiert werden
D) Unbekannte Wörter müssen durch ein [UNK]-Token ersetzt werden, was Informationen dauerhaft zerstört

Antwort anzeigen

Richtige Antwort: D

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 wahren 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 ausgleichen. Satzzeichen (B) und chinesische Segmentierung (C) sind lösbare technische Probleme; UNK ist nicht wiederherstellbarer Informationsverlust.

Frage 5: Warum nicht zeichenbasiert

Zeichenbasierte Tokenisierung löst das Problem unbekannter Wörter mit einem winzigen Vokabular. Warum vermeiden echte Modelle sie dennoch?

A) Zeichen können keine Bedeutung erfassen, weil sie keinen semantischen Gehalt haben
B) Transformer-Attention skaliert quadratisch mit der Sequenzlänge, sodass zeichenbasierte Sequenzen unerschwinglich teuer werden
C) Viele Sprachen (wie Chinesisch) haben keine Zeichen im westlichen Sinne
D) Zeichen können nicht im Standard-Gleitkommaformat gespeichert werden

Antwort anzeigen

Richtige Antwort: B

Die Attention-Kosten wachsen mit O(N²) in der Sequenzlänge. Eine Verdopplung der Tokens macht Attention 4× teurer. Ein Absatz mit 500 Wörtern wird zu ~2.500 Zeichen-Tokens — eine Kostensteigerung um das 25-Fache 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.

Frage 6: Die zwei Subwort-Probleme

Abschnitt 9.3 der Vorlesung besagt, dass jeder Subwort-Tokenisierungsalgorithmus zwei Probleme gemeinsam lösen muss. Welche sind das?

A) Die Wahl eines Basisalphabets UND die Wahl einer endgültigen Vokabulargröße
B) Das Komprimieren des Trainingskorpus UND die Auswahl der zu unterstützenden Sprachen
C) Das Trainieren des Tokenizers UND das Trainieren des Transformers, ihn zu nutzen
D) Das Definieren eines Vokabulars V UND das Definieren einer Encoding-Funktion f, die Text auf Tokens aus V abbildet

Antwort anzeigen

Richtige Antwort: D

Tokenisierung ist zweierlei: ein Vokabular (die erlaubten Tokens) und eine Encoding-Funktion (der Algorithmus, der Text in diese Tokens 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; die Sprachauswahl (B) und das Modelltraining (C) sind separate Anliegen.

Frage 7: Wie BPE Merges auswählt

Wie entscheidet Standard Byte Pair Encoding (BPE) während des Trainings, welches Paar als Nächstes zusammengeführt wird?

A) Es führt das Paar mit dem höchsten Likelihood-Verhältnis relativ zu den Einzelhäufigkeiten zusammen
B) Es führt das häufigste benachbarte Paar im Korpus zusammen
C) Es führt Paare auf Basis linguistischer Regeln zusammen, die von Expert:innen geliefert werden
D) Es führt Paare zufällig zusammen, bis das Vokabular die Zielgröße erreicht

Antwort anzeigen

Richtige Antwort: B

BPE ist rein häufigkeitsgetrieben. Es durchsucht 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 untergraben, nützliche Merges zu lernen.

Frage 8: Neuen Text mit BPE encodieren

Wie encodiert der Tokenizer einen neuen Satz, den er nie zuvor gesehen hat, nachdem BPE trainiert wurde?

A) Er führt den vollständigen BPE-Trainingsalgorithmus erneut auf dem neuen Satz aus
B) Er führt einen Longest-Match-Lookup durch und wählt an jeder Position das größte passende Vokabular-Token
C) Er wendet die gelernten Merge-Regeln in genau der Reihenfolge an, in der sie während des Trainings gelernt wurden
D) Er trennt an Leerzeichen und schlägt jedes Wort im Vokabular nach

Antwort anzeigen

Richtige Antwort: C

Der trainierte Tokenizer trainiert nicht neu (A). Er spielt die Merge-Regeln in der Trainingsreihenfolge ab — Regel #1 feuert zuerst (das während des Trainings häufigste Paar), dann Regel #2 und so weiter. Das sieht oft wie Longest Match (B) aus, aber der Mechanismus ist im Kern eine geordnete Folge von Umschreiberegeln, die eine andere Segmentierung erzeugen kann als eine gierige Longest-Match-Suche. Die Trennung an Leerräumen (D) ist der wortbasierte Ansatz, den BPE ersetzt.

Frage 9: Das Strawberry-Problem

Warum scheitern die meisten LLMs historisch daran, die r’s in “strawberry” zu zählen?

A) Die Trainingsdaten des Modells enthielten nicht genug Beispiele von Erdbeeren
B) Zählen ist für den Forward-Pass des Transformers rechnerisch zu teuer
C) Das Modell verweigert das Zählen von Buchstaben absichtlich als Sicherheitsmaßnahme
D) Der Tokenizer zerlegt das Wort in Blöcke (wie str, aw, berry), in die das Modell nicht hineinschauen kann, um einzelne Buchstaben zu untersuchen

Antwort anzeigen

Richtige Antwort: D

Tokens sind atomar — die kleinste Einheit, die das Modell wahrnehmen kann. Wenn “strawberry” in str, aw, berry zerlegt wird, sieht das Modell drei undurchsichtige Blö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 häufig. Die Zählkosten (B) sind nicht der Engpass; selbst kurze tokenisierte Eingaben erzeugen falsche Zählungen. Eine Sicherheitsverweigerung (C) findet nicht statt — das Modell produziert die falsche Antwort selbstbewusst.

Frage 10: Das 256-Byte-Basisvokabular

Warum startet byte-level BPE mit genau 256 Basis-Tokens und benötigt kein [UNK]-Token?

A) 256 ist die Anzahl der Zeichen im ASCII-Standard
B) Ein Byte besteht aus 8 Bit, was 2^8 = 256 Werte ergibt; in Kombination mit UTF-8 garantiert dies, dass jeder mögliche Text encodiert werden kann
C) 256 ist die maximale Vokabulargröße, die in ein einzelnes GPU-Register passt
D) Experimente zeigten, dass 256 die beste mehrsprachige Leistung erzeugt

Antwort anzeigen

Richtige Antwort: B

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

Frage 11: Verlustfrei vs. effizient

Ein neues Emoji wird zu Unicode hinzugefügt, nachdem ein byte-level BPE-Tokenizer trainiert wurde. Was passiert, wenn eine Nutzerin oder ein Nutzer es eingibt?

A) Die UTF-8-Bytes des Emojis gehen als mehrere Basis-Byte-Tokens durch — verlustfrei, aber mit mehr Tokens, als ein frisch trainierter Tokenizer verwenden würde
B) Das Emoji wird durch ein [UNK]-Token ersetzt und das Modell produziert wirre Ausgaben
C) Der Tokenizer scheitert mit einem Fehler, weil die Bytes seinen Merge-Regeln unbekannt sind
D) Der Tokenizer trainiert sich automatisch neu, um das neue Emoji aufzunehmen

Antwort anzeigen

Richtige Antwort: A

Dies ist die zentrale Unterscheidung zwischen verlustfrei und effizient. Byte-level BPE ist per Konstruktion encoding-verlustfrei — das 256-Byte-Basisvokabular deckt jede mögliche Byte-Folge ab. Ein neues Emoji verwendet einfach 4 Basis-Byte-Tokens statt des einen Tokens, das ihm ein frisch trainierter Tokenizer zuweisen könnte. Es gehen keine Informationen verloren (deshalb sind B und C falsch); Tokenizer sind statische Artefakte, die sich nicht selbst neu trainieren (D). Der Preis ist Effizienz, nicht Korrektheit.

Frage 12: WordPiece vs. BPE

Was ist der entscheidende algorithmische Unterschied zwischen WordPiece (in BERT verwendet) und BPE?

A) WordPiece arbeitet auf Bytes; BPE arbeitet auf Zeichen
B) WordPiece führt Top-down zusammen (Pruning); BPE führt Bottom-up zusammen
C) WordPiece wählt das Paar mit dem höchsten Likelihood-Verhältnis; BPE wählt das häufigste Paar
D) WordPiece wird von Linguistik-Expert:innen überwacht; BPE ist unüberwacht

Antwort anzeigen

Richtige Antwort: C

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 Verbindungen (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 Design-Achse.

Frage 13: Der Trade-off der Vokabulargröße

LLaMA 3 vervierfachte sein Vokabular von den 32.000 Tokens von LLaMA 2 auf 128.000 Tokens. Was ist die wesentliche Kostenfolge davon?

A) Das Modell wird langsamer abzufragen, weil Lookups in größeren Tabellen länger dauern
B) Die Embedding-Matrix und die Output-Projektion wachsen beide linear und fügen Hunderte Millionen Parameter hinzu
C) Größere Vokabulare verringern aufgrund von Overfitting immer die Modellgenauigkeit
D) Die Vervierfachung des Vokabulars erfordert die Vervierfachung der Größe des Trainingskorpus

Antwort anzeigen

Richtige Antwort: B

Die Embedding-Matrix hat eine Zeile pro Vokabulareintrag, daher bestimmt die Vokabulargröße ihre Parameterzahl direkt. 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 eines Tabellen-Lookups (A) sind O(1) und vernachlässigbar. Overfitting (C) ist keine automatische Folge. Die Trainingsdaten (D) müssen zwar für seltene Tokens ausreichend sein, aber es gilt keine feste Vervierfachungsregel.

Frage 14: Warum Arithmetik scheitert

Warum scheitern LLMs oft an einfacher mehrstelliger Arithmetik wie 1234 + 5678?

A) Die Gleitkommagenauigkeit reicht für Ganzzahl-Arithmetik im Transformer nicht aus
B) Die Trainingsdaten enthielten nicht genug Arithmetik-Beispiele
C) Transformer sind ausdrücklich darauf ausgelegt, Arithmetik-Operationen als Sicherheitsmaßnahme zu verweigern
D) BPE zerlegt Zahlen entlang gelernter Subwort-Grenzen, die quer durch die Stellenwert-Spalten schneiden, sodass einzelne Ziffern nicht zuverlässig isoliert werden können

Antwort anzeigen

Richtige Antwort: D

Der Tokenizer zerlegt Zahlen nach häufigkeitsbasierten 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 schneiden quer durch die Stellenwert-Spalten, von denen Arithmetik abhängt. Die Gleitkommagenauigkeit (A) ist mehr als ausreichend. Arithmetik-Beispiele (B) sind in den Trainingsdaten reichlich vorhanden. Eine Sicherheitsverweigerung (C) findet nicht statt — das Modell produziert selbstbewusst falsche Antworten. Gemma behob dies, indem es eine Ziffer pro Token erzwang.

Frage 15: Die mehrsprachige Fairness-Lücke

Warum kosten nicht-englische Sprachen für gleichwertige Inhalte typischerweise mehr Tokens als Englisch?

A) Nicht-englische Alphabete enthalten im Allgemeinen mehr verschiedene Zeichen, was die Token-Anzahl pro Wort aufbläht
B) Der Trainingskorpus von BPE ist englischdominiert (~85 %), sodass er effiziente Merges für Englisch lernt und andere Sprachen fragmentiert lässt
C) Die Transformer-Architektur ist intern auf die englische Wortreihenfolge ausgerichtet
D) Nicht-englischer Text wird intern in UTF-16 gespeichert, was die Byte-Anzahl verdoppelt

Antwort anzeigen

Richtige Antwort: B

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 im Deutschen das 2-Fache, im Hindi das 5-Fache, im Burmesischen das 8-Fache erreichen — gleiches Kontextfenster, gleicher API-Preis, weit weniger nutzbarer Inhalt. Die Alphabetgröße (A) ist eine Nebensache im Vergleich zur Merge-Effizienz. Eine Architektur-Voreingenommenheit (C) und UTF-16-Speicherung (D) sind schlicht falsch.

Frage 16: Glitch-Tokens

Warum verursachen “Glitch-Tokens” wie SolidGoldMagikarp unvorhersehbares Modellverhalten?

A) Die Trainingsdaten des Tokenizers enthielten diese Zeichenketten, die Trainingsdaten des Modells jedoch nicht — sodass ihre Embeddings nie über die zufällige Initialisierung hinaus trainiert wurden
B) Diese Tokens werden absichtlich als Honeypots eingefügt, um Prompt-Injection-Versuche zu erkennen
C) Diese Tokens lösen reservierte Systemanweisungen innerhalb des Transformers aus
D) Glitch-Tokens sind beschädigte Einträge, die aus früheren Tokenizer-Versionen übrig geblieben sind

Antwort anzeigen

Richtige Antwort: A

Der Tokenizer und das Modell werden auf unterschiedlichen Datensätzen trainiert. Reddit-Inhalte gaben BPE Tausende von Vorkommen von SolidGoldMagikarp (einem Benutzernamen), was ein eigenes Token einbrachte. Der sauberere 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 Ursache — der Vokabulareintrag ist gültig; nur sein Embedding ist untrainiert.

Frage 17: Tokenisierung von Code

Welche Aussage darüber, wie Code tokenisiert wird, ist korrekt?

A) Code-Tokenizer verwenden unabhängig von der Häufigkeit immer sprachspezifische Schlüsselwörter als atomare Tokens
B) Einrückungs-Leerraum ist kostenlos — er verbraucht keine Tokens
C) Häufiger Boilerplate-Code (wie def __init__(self):) komprimiert sich zu wenigen Tokens, während neuartige domänenspezifische Bezeichner in viele zerfallen
D) snake_case- und camelCase-Bezeichner werden immer in die gleiche Anzahl von Tokens tokenisiert

Antwort anzeigen

Richtige Antwort: C

Der Tokenizer lernte seine Merges aus Milliarden von Codezeilen. Häufige Muster (def __init__, gängige Bibliotheksaufrufe) wurden zu effizienten kurzen Tokens; 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 einem Sonderstatus versehen (A). Einrückung kostet echte Tokens (B ist falsch). Unterschiedliche Namenskonventionen werden sehr unterschiedlich zerlegt — snake_case fragmentiert typischerweise an Unterstrichen (D ist falsch).

Frage 18: CLAUDE.md aus Sicht des Modells

Was ist aus Sicht des Transformers das Besondere an der CLAUDE.md-Datei, wenn sie in eine Anfrage einbezogen wird?

A) Nichts ist besonders — sie wird durch dieselbe BPE-Pipeline wie Ihr Prompt in Tokens umgewandelt und als Teil derselben Sequenz verarbeitet
B) Sie wird von einer Regel-Engine geparst, die ihre Anweisungen deterministisch anwendet, bevor das Modell läuft
C) Sie wird in einen separaten “Instruction”-Embedding-Kanal mit höherer Attention-Priorität geladen
D) Sie wird mit kryptografischen Signaturen encodiert, die das Modell vor der Verarbeitung verifiziert

Antwort anzeigen

Richtige Antwort: A

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

Bewertungsleitfaden

Wichtige Erkenntnisse zum Merken

  1. LLMs sind Maschinen zur Vorhersage des nächsten Tokens — jede Ausgabe entsteht aus wiederholter Vorhersage des nächsten Tokens, nicht aus Planung oder Abruf.
  2. Tokenisierung überbrückt Text und Zahlen — neuronale Netze arbeiten nur mit numerischen Tensoren, daher muss Text in ganze Zahlen und dann in Embedding-Vektoren umgewandelt werden, bevor der Transformer ihn nutzen kann.
  3. Tokenisierung ist zweierlei: ein Vokabular UND eine Encoding-Funktion — das Vokabular allein ist mehrdeutig; Encoding-Regeln sind nötig, um Text deterministisch zu zerlegen.
  4. Subwort-Tokenisierung ist der moderne Standard — häufige Wörter ganz zu lassen und seltene Wörter in wiederverwendbare Teile zu zerlegen, vermeidet sowohl Vokabularexplosion (Wortebene) als auch Sequenzexplosion (Zeichenebene).
  5. BPE führt iterativ das häufigste Paar zusammen — rein datengetrieben, keine linguistischen Regeln; die geordneten Merge-Regeln dienen sowohl als Vokabular-Builder als auch als Encoding-Funktion.
  6. Byte-level BPE ist für immer verlustfrei — 256 Basis-Byte-Tokens kombiniert mit UTF-8 bedeuten, dass jeder mögliche Text (einschließlich zukünftiger Emojis) immer encodiert werden kann, kein [UNK]-Token möglich.
  7. Verlustfrei ≠ effizient — byte-level BPE bewahrt immer Informationen, aber seltene Muster (nicht-englischer Text, neue Emojis) kosten mehr Tokens als gut zusammengeführter englischer Text.
  8. Tokens sind atomar — das Modell kann nicht in ein Token hineinschauen, um einzelne Zeichen zu untersuchen; deshalb scheitern Buchstabenzählung und Arithmetik auf Ziffernebene.
  9. Die mehrsprachige Fairness-Lücke ist eine Tokenizer-Voreingenommenheit — englischdominierte Trainingsdaten erzeugen Tokenizer, die andere Sprachen fragmentieren, was nicht-englische Nutzung um das 2- bis 8-Fache teurer in Tokens macht.
  10. CLAUDE.md ist nur Tokens — aus Sicht des Modells gibt es keinen “Instruction-Kanal”; Projektanweisungen gelangen durch genau dieselbe Pipeline in den Transformer wie der Nutzer-Prompt.
© 2026 Dominik Müller   •  Powered by Soopr   •  Theme  Moonwalk