Teil 1 (ca. 20 Minuten): Grundverständnis — Warum nicht direkt mit Wörtern arbeiten? Was ist ein Token?
Wenn wir Menschen lesen oder sprechen, denken wir meistens in Wörtern, Wortstämmen oder Bedeutungen. Computerprogramme, und damit auch neuronale Sprachmodelle, sehen jedoch Zeichenketten — Folgen von Bytes oder Unicode-Zeichen. Die direkte Abbildung jedes möglichen Wortes auf eine eigene Repräsentation ist aus praktischen Gründen ungeeignet: Die Zahl möglicher Wortformen (Flexionen, Zusammensetzungen, Eigennamen, Tippfehler, rare Fachbegriffe, Entlehnungen) ist sehr groß und hängt von der Sprache. Deshalb haben sich Verfahren etabliert, die Texte in kleinere, wiederverwendbare Einheiten zerlegen: Tokens.
In diesem Kontext bezeichnet ein "Token" eine Einheit, die ein Tokenizer aus Rohtext erzeugt und die das Modell als Eingabe verwendet. Tokens sind keine universelle linguistische Kategorie wie "Wort" im traditionellen Sinne; sie sind algorithmisch definierte Einheiten, die Buchstabenfolgen, Teile von Wörtern, ganze Wörter oder auch Interpunktionszeichen repräsentieren können. Die gängigen Tokenisierungen für moderne Transformer-Modelle arbeiten auf der Ebene von Subwörtern oder Byte-ähnlichen Einheiten, nicht in erster Linie auf der Ebene semantischer Wörter (siehe die methodischen Beschreibungen zu Subword-Tokenizern und Tokenisierungsimplementierungen).
Eine nützliche Analogie ist das Bauen mit Legosteinen. Wörter sind wie fertige Modelle (z. B. ein Auto), Tokens sind die einzelnen Bausteine. Wenn man nur fertige Modelle als Bausteine zuließe, bräuchte man unendlich viele verschiedene Modelle, um alle möglichen Kombinationen abzudecken. Mit einer überschaubaren Menge an Bausteinen (Tokens) lassen sich dagegen sehr viele Wörter und Wortkombinationen zusammensetzen.
Dieses Vorgehen hat praktische Vorteile: Es reduziert die notwendige Größe des Wörterbuchs, erlaubt Modellierung seltener oder neuer Wörter durch Kombination vorhandener Teile und verringert Probleme mit "Out-of-Vocabulary" (OOV), also Wörtern, die das Modell gar nicht kennt. Die Idee, Subworteinheiten statt kompletter Wörter zu verwenden, wird in mehreren etablierten Arbeiten und Implementierungen beschrieben (vgl. insbesondere Arbeiten zu Subword-Methoden und praktischen Tokenizer-Implementierungen).
(Vgl. Sennrich et al., 2015; Kudo & Richardson, 2018; Devlin et al., 2018; Hugging Face Dokumentation) [siehe Quellenverzeichnis]
Teil 2 (ca. 20 Minuten): Vertiefung und Fachbegriffe
Im Folgenden werden die wichtigsten Fachbegriffe und technische Grundlagen systematisch eingeführt und erklärt, wie sie zusammenhängen.
Token und Tokenizer
Ein Tokenizer ist ein Algorithmus, der eingehenden Text in Tokens zerlegt. Es gibt verschiedene Prinzipien für Tokenizer. Drei gebräuchliche Familien sind: Wort-basiert (sehr selten bei modernen Modellen), Subword-basiert (etwa Byte-Pair-Encoding, WordPiece), und byte- bzw. byte-ähnlich basierte Verfahren (wie einige Varianten von SentencePiece, die auch byte- und UTF-8-Resilienz bieten). Subword-Methoden wählen eine endliche Menge an Subwort-Symbolen (ein Vokabular) und zerlegen Text so, dass häufige Wortteile als einzelne Tokens auftauchen, seltenere Wörter in mehrere Tokens zerlegt werden.
Byte Pair Encoding (BPE) und seine Nachfolger
Byte Pair Encoding (BPE) ist eine einfache datengetriebene Methode, die wiederholt häufige Paare von Zeichen oder Symbolen zu neuen Einträgen im Vokabular kombiniert. Dadurch entstehen Subwort-Einheiten, die oft häufige Präfixe, Suffixe oder Wortstämme repräsentieren. BPE wurde für maschinelle Übersetzung adaptiert, um mit seltenen Wörtern besser umzugehen (Sennrich et al., 2015). WordPiece, ein verwandtes Verfahren, nutzt ein probabilistisches Kriterium und wurde bei großen Sprachmodellen wie BERT eingesetzt (Devlin et al., 2018). SentencePiece ist eine Implementierung, die tokenisierungsunabhängig von Leerzeichen arbeiten kann und sowohl BPE- als auch unigram-basierte Modelle unterstützt (Kudo & Richardson, 2018).
Warum Wörter unterschiedlich viele Tokens haben können
Ob ein Wort in ein, zwei oder mehrere Tokens zerlegt wird, hängt vom verwendeten Vokabular und vom Tokenizer-Algorithmus ab. Häufige Wörter oder Wortteile werden typischerweise als einzelne Tokens erlernt. Seltene Wörter, lange zusammengesetzte Wörter oder kreative Schreibweisen werden in mehrere bekannte Substücke zerlegt. Beispielhaft: In einem Vokabular könnte "Haus" als ein Token vorkommen, "Hausaufgabe" aber als "Haus" + "aufgabe" oder "Haus" + "##auf" + "gabe", je nach Tokenizer-Konvention (WordPiece nutzt oft spezielle Marker für Fortsetzungen). Manche Tokenizer arbeiten auf Zeichen- oder Byte-Level, sodass praktisch jedes Zeichen oder Byte ein Token sein kann; andere bevorzugen längere Subworteinheiten. Die genaue Aufteilung ist also eine Folge der Trainingsdaten des Tokenizers und des gewählten Algorithmus.
Konsequenzen für Rechenaufwand und Modellarchitektur
Transformer-Modelle verarbeiten Sequenzen von Tokens. Die Rechenkosten (insbesondere bei der Selbstaufmerksamkeit) hängen von der Länge dieser Sequenz ab. In der ursprünglichen Transformer-Beschreibung wird die Rechenkomplexität der Selbstaufmerksamkeit mit der Sequenzlänge n als O(n^2 · d) angegeben, wobei d die Modell-Dimension ist (Vaswani et al., 2017). Das bedeutet: Bei doppelter Tokenanzahl wächst der Aufwand für die Aufmerksamkeit ungefähr um den Faktor vier (bei sonst gleichen Parametern). Dementsprechend beeinflusst die Wahl der Tokengröße direkt Trainingszeit, Inferenzlaufzeit und damit auch Kosten in Cloud-Umgebungen.
Daraus folgt eine wichtige Abwägung: Gröbere Tokens (z. B. größeres Subwort-Vokabular und damit im Durchschnitt weniger Tokens pro Wort) reduzieren die Sequenzlänge, können jedoch das Vokabular und den Speicherbedarf (z. B. die Einbettungsmatrix) erhöhen. Feinkörnigere Tokens (z. B. Byte-Level) führen zu längeren Sequenzen und damit zu höherem Rechenaufwand in der Aufmerksamkeit, ermöglichen aber eine sehr robuste Behandlung beliebiger Zeichenfolgen und eine kleinere Anzahl unbekannter Zeichen. Die Forschung zu "Efficient Transformers" zielt unter anderem darauf ab, die quadratic scaling-Problematik zu entschärfen, zeigt aber gleichzeitig, dass die Sequenzlänge ein zentraler Kostenfaktor bleibt (Tay et al., 2020).
Tokenzählung in praktischen Systemen und Abrechnung
In praktischen APIs und Nutzungsmodellen wird häufig pro Token abgerechnet oder Tokenbegrenzungen bestimmt die maximale nutzbare Kontextlänge. Anbieter dokumentieren, wie sie Tokens zählen und welche Tokenizer sie nutzen; das beeinflusst also direkt die Nutzkosten und Limitierungen beim Einsatz von Modellen in produktionellen Systemen (vgl. Plattformdokumentationen und Tokenizer-Demos). Dabei ist wichtig zu wissen, dass "Token" in der Abrechnung dasselbe ist, was der Modell-Tokenizer erzeugt; verschiedene Modelle können unterschiedliche Tokenizer verwenden, sodass dieselbe Texteingabe in verschiedenen Systemen unterschiedlich viele Tokens ergibt.
(Vgl. Vaswani et al., 2017; Tay et al., 2020; OpenAI Tokenizer-Dokumentation; Hugging Face Tokenizers) [siehe Quellenverzeichnis]
Transparenz und Unsicherheiten
Es besteht Konsens darüber, dass Subword-Tokenisierung eine praktische und heute weit verbreitete Lösung für das Problem riesiger Wortvokabularien ist. Präzise Effekte — etwa wie stark sich eine bestimmte Tokenisierung in einer bestimmten Sprache auf Modellleistung oder Kosten auswirkt — hängen jedoch stark von den Trainingsdaten, der Sprachstruktur und der Implementierung ab. Quantitative Aussagen über durchschnittliche Token-Längen oder Kosten sind daher daten- und systemspezifisch; allgemeine Trends (z. B. dass mehr Tokens in der Regel mehr Rechenaufwand bedeuten) sind hingegen robust.
Teil 3 (ca. 10 Minuten): Anwendungen, Grenzen und Denkaufgaben
Abschließend betrachten wir konkrete Anwendungen, Einschränkungen in der Praxis und kleine Denkaufgaben, um das Verständnis zu prüfen.
Anwendungen und praktische Implikationen
In Anwendungen wie maschineller Übersetzung, Textgenerierung, Frage-Antwort-Systemen oder Autovervollständigung bestimmt Tokenisierung zwei grundlegende Eigenschaften: Erstens die Robustheit gegenüber unbekannten oder seltenen Wörtern (Subword-Tokenizer helfen hier sehr). Zweitens die Effizienz: Längere Token-Sequenzen brauchen mehr Rechenzeit und mehr Speicher für die gleiche Eingabe, besonders aufgrund der quadratischen Kosten in der Selbstaufmerksamkeit. Beim Einsatz in produktiven Systemen bedeutet dies, dass man bewusst Tokenizer, Vokabulargröße und Kontextlänge wählen muss, um ein akzeptables Verhältnis von Genauigkeit zu Laufzeit/Kosten zu erreichen. Dokumentationen von Tokenizer-Implementierungen und Plattformen geben oft praktische Empfehlungen und Werkzeuge, um Token-Nutzung zu messen und zu optimieren.
Grenzen
Tokenisierung ist kein Allheilmittel. Sie löst nicht automatisch semantische Ambiguitäten, ironische Wendungen oder komplexe Pragmatik. Außerdem sind manche Sprachen durch ihre Morphologie oder Schreibweise schwieriger zu handhaben; sehr agglutinierende oder polysynthetische Sprachen können spezielle Überlegungen bei der Tokenisierung erfordern. Schließlich sind die Effekte sprach- und domänenspezifisch: Ein Tokenizer, der gut für allgemeines Englisch funktioniert, ist nicht zwangsläufig optimal für medizinische Texte oder code-mixed Inhalte.
Kleine Denkaufgaben zur Vertiefung
1. Nehmen Sie einen Satz in Ihrer Muttersprache und tokenisieren Sie ihn mit zwei verschiedenen, frei verfügbaren Tokenizern (z. B. einem Byte-Level-Tokenizer und einem Subword-Tokenizer). Beobachten Sie, wie viele Tokens entstehen und welche Wortteile getrennt werden. Reflektieren Sie, welche Tokenisierung für Ihre Anwendung (z. B. Übersetzung vs. Autovervollständigung) vorteilhafter erscheint und warum. 2. Stellen Sie sich vor, ein bestimmtes Wort in Ihren Daten erscheint extrem oft. Diskutieren Sie, wie das die Entscheidung über das Vokabular beeinflussen sollte und welche Folgen das für Speicher/Einbettungstabellen haben kann. 3. Überlegen Sie, welche Vor- und Nachteile eine grobere Tokenisierung (weniger, längere Tokens) gegenüber einer feineren (mehr, kürzere Tokens) für das Training eines großen Modells hat — sowohl in Bezug auf Modellgröße als auch auf Inferenzkosten.
Diese Übungen sind bewusst allgemein gehalten: Konkrete, quantitative Analysen benötigen jeweils Zugriff auf die Trainingsdaten, die Tokenizer-Implementierung und Messungen der Laufzeit/ der Kosten in der jeweiligen Infrastruktur.