BPE-Tokenisierung zerlegt Text in wiederkehrende Zeichenfolgen, indem sie zunächst jedes Zeichen einzeln behandelt und dann schrittweise die häufigsten benachbarten Paare zu neuen Einheiten („Merges“) zusammenfasst. Aus einem kleinen Korpus entsteht so über mehrere Runden ein Vokabular aus Zeichen und häufigen Subwörtern. Wörter werden zerlegt, weil ein endliches Vokabular sonst nie alle Wörter abdecken könnte – seltene Wörter kosten dann mehrere Tokens.
Warum Wörter in Subwörter zerlegt werden
Ein Sprachmodell rechnet nicht mit Buchstaben oder Wörtern, sondern mit Tokens: Das sind die diskreten Einheiten, in die ein Text vor der Verarbeitung zerlegt wird, und jedes Token hat eine feste ID im Vokabular. Würde man pro Wort ein Token vergeben, müsste das Vokabular jedes Wort der Welt enthalten – inklusive Tippfehler, Fachbegriffe, Namen und neuer Wortformen. Das ist praktisch unmöglich, und jedes unbekannte Wort bräuchte einen Notfall-Platzhalter. Würde man umgekehrt pro Zeichen tokenisieren, wäre das Vokabular winzig, aber der Text würde in sehr viele Tokens zerfallen und das Modell müsste die Bedeutung erst mühsam aus einzelnen Buchstaben zusammensetzen.
Subwort-Tokenisierung löst diesen Zielkonflikt: Häufige Wörter wie „die“ oder „und“ bekommen ein eigenes Token, seltene Wörter werden in bekannte Bausteine zerlegt, etwa „Tokenisierung“ in „Token“ + „isierung“. Das Vokabular bleibt endlich (typischerweise einige zehntausend bis hunderttausend Einträge), und jedes Wort ist trotzdem darstellbar – notfalls Zeichen für Zeichen. Der Preis: Ein seltenes Wort belegt mehrere Tokens, was Kontextfenster und API-Kosten belastet.
BPE Schritt für Schritt: Der Algorithmus hinter den Merge-Runden
BPE (Byte Pair Encoding, ursprünglich ein Kompressionsverfahren) arbeitet mit vier Schritten. Vorbereitung: Man startet mit einem Trainingskorpus, zerlegt ihn in Wörter und zählt, wie oft jedes Wort vorkommt. Jedes Wort wird als Folge einzelner Zeichen dargestellt, wobei ein spezielles Endzeichen (oft „_ “ oder ein eigenes Symbol) das Wortende markiert, damit „en“ am Wortende und „en“ mitten im Wort unterscheidbar bleiben. Zählen: In jeder Runde zählt der Algorithmus alle benachbarten Zeichen- bzw. Symbolpaare über den gesamten Korpus, gewichtet mit der Worthäufigkeit. Mergen: Das häufigste Paar wird zu einem neuen Symbol verschmolzen und ins Vokabular aufgenommen; alle Vorkommen dieses Paars werden ersetzt. Wiederholen: Schritt 2 und 3 laufen so oft, bis eine vorher festgelegte Zahl von Merges (also die gewünschte Vokabulargröße) erreicht ist.
Wichtig für die Einordnung: BPE optimiert nur die Häufigkeit von Paaren, nicht „Bedeutung“. Deshalb können Merges entstehen, die linguistisch merkwürdig wirken – etwa häufige Buchstabenfolgen, die zufällig über Wortgrenzen hinweg oft auftreten. Das Vokabular ist am Ende die Startmenge aller Einzelzeichen plus die Menge der gelernten Merge-Symbole. Beim Anwenden (Inferenz) auf neuen Text werden die gelernten Merges in derselben Reihenfolge angewendet; ein unbekanntes Wort zerfällt dann in die längsten bekannten Bausteine.
Die formale Kernoperation pro Runde lässt sich so notieren:
für jedes Paar (a, b): häufigkeit(a, b) = summe über alle wörter w:
vorkommen(w) * anzahl von (a, b) in w
merge = argmax häufigkeit(a, b)
vokabular = vokabular ∪ {merge}
ersetze in allen wörtern (a, b) durch merge
## Durchgerechnetes Beispiel: Vom kleinen Textkorpus zum Vokabular
Nehmen wir einen winzigen Korpus aus drei „Wörtern" (vereinfacht, ohne Groß-/Kleinschreibung und ohne Leerzeichen-Behandlung):
niedriger, niedrig, nigher
Zuerst zählen wir die Häufigkeiten und hängen an jedes Wort ein Endzeichen `</w>` an, damit der Algorithmus Wortgrenzen erkennt:
n i e d r i g e r (1×) n i e d r i g (1×) n i g h e r (1×)
Das **Startvokabular** sind alle Einzelzeichen plus `</w>`. Jetzt zählen wir alle **benachbarten Zeichenpaare** über den ganzen Korpus:
n i : 3 i e : 2 e d : 2 d r : 2 r i : 2 i g : 2 g e : 1 e r : 2 r : 1 i g ... usw.
Häufigstes Paar: `n i` mit 3 Vorkommen.
**Runde 1 – Merge `n i` → `ni`:**
n i e d r i g e r → ni e d r i g e r n i e d r i g → ni e d r i g n i g h e r → ni g h e r
**Runde 2:** Jetzt ist `e r` (in „nieder" und „er") das häufigste Paar (2×). Merge zu `er`:
ni e d r i g er ni e d r i g ni g h er
**Runde 3:** `i g` kommt 2× vor → Merge zu `ig`:
ni e d r ig er ni e d r ig ni g h er
Nach drei Runden sind aus vielen Zeichen größere **Subwort-Einheiten** geworden: `ni`, `ig`, `er`. Das Vokabular ist gewachsen (jedes neue Merge-Symbol kommt hinzu). Bei echtem BPE läuft das so lange, bis eine gewünschte Vokabulargröße erreicht ist – jedes Merge fügt genau ein neues Token hinzu.
Wichtig: Ein häufiges Wort wie „niedrig" wird am Ende oft als *ein* Token stehen, ein seltenes wie „nigher" zerfällt in mehrere. Das ist erwünscht – häufige Muster werden kompakt, seltene bleiben flexibel.
## Tokenanzahl, Kosten und der Einsatz des Token-Counters
Kosten entstehen fast immer pro **Token**, nicht pro Zeichen oder Wort. Faustformel für die Schätzung (keine gemessene Statistik, sondern eine Annahme):
Zeichen pro Token ≈ 4 (englisch, häufig) Zeichen pro Token ≈ 2–3 (Deutsch, Fachtext)
Beispielrechnung: Ein deutscher Text mit **1.200 Zeichen**. Bei geschätzten **3 Zeichen/Token** ergibt das rund `1.200 / 3 = 400` Tokens. Bei einem angenommenen Preis von – sagen wir – 1 Einheit pro 1.000 Tokens (rein illustrativ, kein echter Preis) wären das `400 / 1.000 ≈ 0,4` Einheiten. Verdoppelt sich die Tokenanzahl durch seltene Fachbegriffe, verdoppeln sich die Kosten.
**Praktisch:** Statt zu raten, zählt man echte Tokens mit einem **Token-Counter** (Tokenizer der jeweiligen Bibliothek). Kurzer Pseudocode:
```python
tokens = tokenizer.encode(text)
print(len(tokens)) # exakte Tokenanzahl
Checkliste vor dem API-Aufruf:
- Text mit dem richtigen Tokenizer des Zielmodells zählen (nicht schätzen)
- Sehr seltene Wörter/Fachbegriffe identifizieren (treiben die Tokenanzahl hoch)
- Bei langen Dokumenten Token-Budget pro Anfrage prüfen
- Kürzen/Chunken, falls das Budget überschritten wird
- Deutsche Texte nicht mit englischen Faustregeln kalkulieren
Merksatz: Mehr Tokens pro Wort bedeuten mehr Aufruf-Kosten und ein schnelleres Erreichen des Kontextlimits – Subwort-Zerlegung ist also nicht nur ein technisches Detail, sondern direkt kostenrelevant.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Zeichen-, Wort- und Subwort-Tokenisierung?
Bei der Zeichen-Tokenisierung wird jedes einzelne Zeichen als Token behandelt, wodurch das Vokabular winzig bleibt, die Sequenzen aber sehr lang werden. Die Wort-Tokenisierung trennt Text an Leerzeichen und Satzzeichen, erzeugt dadurch ein riesiges Vokabular und scheitert bei unbekannten Wörtern komplett. Subwort-Tokenisierung wie BPE ist der Kompromiss: Häufige Wörter bleiben ganz, seltene Wörter werden in bekannte Bestandteile zerlegt, sodass jedes Wort aus dem Vokabular darstellbar bleibt.
Warum entstehen bei BPE manchmal unerwartete Subwörter statt ganzer Wörter?
BPE entscheidet rein über Häufigkeiten im Trainingskorpus, nicht über linguistische Grenzen. Ein Wort wird nur dann als ganzes Token gelernt, wenn es häufig genug vorkommt, damit seine Zeichenfolge eine Merge-Runde gewinnt. Seltene oder neue Wörter bestehen dagegen aus den häufigsten Zeichenpaaren, die zufällig in ihnen stecken – daher können Zerlegungen entstehen, die für Menschen willkürlich wirken, etwa ein Wortstamm, der über eine vermeintliche Silbengrenze hinweg geteilt wird.
Wie beeinflusst die Vokabulargröße die Tokenanzahl und damit die API-Kosten?
Ein größeres Vokabular enthält mehr ganze Wörter und längere Subwörter, wodurch ein Text in weniger Token zerfällt; ein kleineres Vokabular erzeugt mehr, kürzere Token für denselben Text. Da Abrechnungsmodelle pro Token zählen, sinken die Kosten bei gleichem Text mit steigender Vokabulargröße – bis zu einem Punkt, an dem seltene Token kaum noch Trainingsdaten erhalten und sich die Zerlegung wieder verschlechtert. Die exakte Ersparnis hängt vom konkreten Tokenizer und Text ab; eine grobe Schätzung erhalten Sie, indem Sie denselben Text mit verschiedenen Tokenizern zählen.
Kann ich die Tokenanzahl meines Texts vor dem API-Aufruf schätzen?
Ja, mit einem Token-Counter, also einem Werkzeug, das denselben Tokenizer wie das Zielmodell verwendet und den Text lokal in Token zerlegt. Eine schnelle Faustregel für englischen Text liegt bei etwa vier Zeichen pro Token, für deutschen Text wegen längerer Komposita eher bei drei bis vier Zeichen – das ist eine Schätzung, keine Garantie. Für Kostenkalkulationen sollten Sie den exakten Counter nutzen, da Abweichungen von dieser Regel schnell spürbar werden.
Warum sind seltene Wörter oder Fachbegriffe oft teurer als häufige Wörter?
Häufige Wörter haben im Training viele Merge-Runden durchlaufen und existieren als einzelne Token, kosten also nur ein Token pro Vorkommen. Seltene Wörter und Fachbegriffe fehlen im Vokabular als Ganzes und werden in mehrere Subwörter zerlegt, wodurch sie mehrere Token verbrauchen. Derselbe Text mit vielen Fachbegriffen kann daher deutlich mehr Token und damit höhere Kosten erzeugen als Alltagssprache gleicher Länge.