Sprache als Daten: Tokens und Kontext

Warum das Modell keine Wörter erhält

Eine Kunden-Mail beginnt so: „Die Kündigungsfrist für Frömmsen GmbH fehlt.“ Der Satz enthält sechs Wörter, ein Satzzeichen und einen ungewöhnlichen Firmennamen. Für einen Computer ist diese Einteilung längst nicht so selbstverständlich.

Ein Sprachmodell rechnet mit Zahlen. Es erhält deshalb keine Wörter wie auf einer gedruckten Seite. Vor der Modellrechnung wird der Text in nummerierte Bausteine zerlegt. Einen solchen Baustein nennen wir Token. Ein Token kann ein Wort sein. Es kann aber auch nur aus einem Wortteil, einem Satzzeichen oder einer anderen Zeichenfolge bestehen.

Warum bekommt nicht einfach jedes Wort eine Nummer? Dann bräuchte das System einen Eintrag für „gehen“, einen weiteren für „gehst“ und noch einen für „ging“. Dazu kämen Eigennamen, Tippfehler und zusammengesetzte Wörter. „Donaudampfschifffahrtsgesellschaftskapitän“ wäre ein einzelnes Wort, obwohl du darin viele bekannte Teile erkennst.

Ein Wörterbuch aus vollständigen Wörtern würde also sehr groß und bliebe trotzdem lückenhaft. Eine Zerlegung in einzelne Zeichen hätte das gegenteilige Problem. Sie könnte jeden Text darstellen, würde aber schon aus einem kurzen Satz sehr viele Rechenschritte machen.

Tokens liegen dazwischen. Häufige Folgen können einen gemeinsamen Baustein erhalten. Seltene Folgen werden aus kleineren Bausteinen zusammengesetzt. Das Modell bekommt dadurch eine begrenzte Liste wiederverwendbarer Einheiten.

Zeichen, Bytes, Wörter und wiederverwendbare Textbausteine

Nimm das Wort „Kündigungsfrist“. Du kannst es als ein Wort betrachten. Du kannst einzelne Buchstaben zählen. Ein Computer muss zusätzlich wissen, wie diese Zeichen gespeichert sind.

Ein sichtbares Zeichen und ein gespeicherter Wert sind nicht immer dasselbe. Ein Umlaut, ein Akzent oder ein Emoji kann aus mehreren technischen Bestandteilen bestehen. Digitale Texte verwenden dafür Zeichenstandards und eine Kodierung. Die Kodierung übersetzt den Text in Bytes. Ein Byte besteht aus acht Bits. Ein Bit hat den Wert null oder eins. Damit kann ein Byte einen Zahlenwert von 0 bis 255 darstellen.

Diese Ebenen erfüllen verschiedene Aufgaben:

• Zeichen beschreiben, was im Text steht.
• Bytes beschreiben, wie der Text gespeichert und übertragen wird.
• Wörter sind sprachliche Einheiten, deren Grenzen von Sprache und Schreibweise abhängen.
• Wiederverwendbare Textbausteine bilden einen praktischen Vorrat für die Modellrechnung.

Die letzte Ebene ist der entscheidende Kompromiss. „Kündigung“ kann als häufiger Baustein vorkommen. Die seltenere Form „Kündigungsfristenregelung“ lässt sich dann vielleicht aus „Kündigung“, „s“, „frist“ und weiteren Teilen zusammensetzen. Die genaue Aufteilung hängt vom verwendeten Vokabular ab.

Das erklärt auch eine alte Schwäche bei Buchstabenfragen. Bekannt wurde die Frage, wie viele „r“ im englischen Wort „strawberry“ stehen. Die richtige Antwort ist drei. Liegt das Wort als wenige größere Tokens vor, sind die Buchstaben darin keine eigenen Eingabepositionen. Das Modell muss die Schreibweise erst rekonstruieren oder ein Werkzeug nutzen. Neuere Systeme lösen solche Aufgaben oft besser. Die Grundlage bleibt aber eine Folge von Tokens.

Wie BPE ein Vokabular aufbaut

Nehmen wir eine große Sammlung von Texten. Am Anfang behandeln wir jedes Zeichen oder jedes Byte als eigene Einheit. Nun zählen wir, welche zwei Einheiten besonders oft nebeneinanderstehen. Ein häufiges Paar wird zu einem neuen gemeinsamen Baustein. Danach zählen wir erneut.

Genau diese Grundidee heißt Byte Pair Encoding, kurz BPE. Das Verfahren stammt ursprünglich aus der Datenkompression. Für Sprachmodelle wurde es so angepasst, dass aus häufigen Zeichenfolgen ein Vokabular entsteht.

Vielleicht tauchen „e“ und „n“ in den Trainingsdaten sehr oft nebeneinander auf. Dann kann daraus „en“ werden. Später werden vielleicht „ung“, „Kündigung“ oder eine Folge aus Leerzeichen und Wortanfang ergänzt. Jede Zusammenführung erweitert das Vokabular um einen Baustein. Der Vorgang endet, wenn die gewünschte Größe oder die festgelegte Zahl von Zusammenführungen erreicht ist.

Bei einer Byte-basierten Variante bleiben die einzelnen Bytes als kleinste Einheiten verfügbar. Dadurch lässt sich auch ein Name, Tippfehler oder Zeichen verarbeiten, das im Training selten war. Es braucht dann nur mehr Tokens.

BPE sucht Häufigkeiten. Es führt keine grammatische Untersuchung durch. Ein entstandener Baustein kann zufällig einem Wortstamm oder einer Silbe entsprechen. Er kann genauso mitten durch eine sprachliche Einheit gehen. Entscheidend ist, welche Folgen in den Trainingsdaten oft gemeinsam vorkamen.

Das Programm, das Text mit einem solchen Vokabular in Tokens zerlegt, heißt Tokenizer. Den Vorgang selbst nennen wir Tokenisierung. Beide Begriffe verwenden wir ab jetzt für die vollständige Umwandlung zwischen Text und nummerierten Bausteinen.

Tokenizer und Tokenisierung

Nehmen wir wieder die Kunden-Mail. Der Tokenizer erhält ihren Text und gibt eine Folge von Tokens zurück. Bei der Tokenisierung können mehrere Schritte zusammenspielen. Manche Verfahren vereinheitlichen bestimmte Schreibweisen. Andere trennen den Text zunächst grob an Wortgrenzen oder Satzzeichen. Danach wenden sie ihre gelernten Regeln an.

BPE ist nur eine mögliche Methode. WordPiece und Unigram wählen ihre Bausteine nach anderen Regeln. SentencePiece kann ein Vokabular direkt aus Rohtext lernen und muss nicht zuerst fertige Wörter erhalten. Das Ergebnis bleibt eine begrenzte Liste aus häufigen Folgen und kleineren Ersatzteilen.

Leerzeichen verdienen etwas Aufmerksamkeit. Ein Vokabular kann „Hund“ am Satzanfang und dieselbe Zeichenfolge mit einem führenden Leerzeichen unterschiedlich behandeln. Großschreibung kann ebenfalls zu einer anderen Zerlegung führen. Deshalb darfst du Token nicht mit einem sauber ausgeschnittenen Wort verwechseln.

Der Tokenizer gehört zum Modellpaket. Sein Vokabular und seine Regeln müssen zu den Gewichten passen. Zwei Tokenizer können denselben Satz verschieden zerlegen. Selbst wenn beide die Nummer 924 ausgeben, kann diese Nummer jeweils einen anderen Textbaustein bezeichnen.

Die Tokenisierung ist umkehrbar, soweit das konkrete Verfahren und die Textkodierung das vorsehen. Aus den Token-IDs lässt sich dann wieder Text zusammensetzen. Die Zerlegung selbst erklärt aber noch keine Bedeutung. Sie bereitet den Text nur für die nächste Rechenstufe vor.

Token-IDs als Eingabe des Modells

Nehmen wir den Satz „Die Katze schläft.“ Ein passender Tokenizer könnte daraus vier Tokens machen. Er schlägt jeden Baustein in seinem Vokabular nach und ersetzt ihn durch eine Nummer. Diese Nummer heißt Token-ID.

Abbildung 2: Der Tokenizer zerlegt einen Satz und ordnet jedem Baustein die Token-ID aus seinem Vokabular zu. Die gezeigten Bausteine und Nummern sind ein vereinfachtes Beispiel.

Eine Token-ID ist eine Adresse im Vokabular. Die Nummer enthält keine natürliche Rangfolge. Token 924 ist nicht wichtiger als Token 13. Zwei nahe Nummern müssen auch keine ähnliche Bedeutung haben.

Das Modell erhält schließlich eine Folge wie [924, 18.431, 7.206, 13]. Jede Zahl belegt eine Position. Ein seltenes zusammengesetztes Wort kann viele solcher Positionen brauchen. Ein häufiges Wort passt vielleicht in eine einzige.

Aus der Token-ID allein kann das Modell noch nicht rechnen, welche Wörter zusammengehören. Es verwendet die Nummer zunächst, um eine gelernte Zahlenliste nachzuschlagen. Diese Darstellung heißt Embedding. Darum geht es im nächsten Kapitel. Für dieses Kapitel reicht der Unterschied: Die ID benennt einen Eintrag. Sie enthält dessen Bedeutung nicht.

Warum verschiedene Sprachen verschieden viele Tokens brauchen

Nehmen wir dieselbe kurze Mitteilung auf Deutsch und in einer anderen Sprache. Inhaltlich kann sie fast gleich sein. Die Zahl ihrer Tokens kann sich trotzdem unterscheiden.

Das Vokabular ist aus einer bestimmten Textsammlung entstanden. Häufige Folgen dieser Sammlung erhalten eher gemeinsame Bausteine. Seltene Folgen zerfallen öfter. Schrift, Wortbildung, Leerzeichen und die Verteilung der Trainingsdaten wirken dabei zusammen.

Deutsch hat viele zusammengesetzte Wörter und veränderte Wortformen. Das kann die Tokenzahl erhöhen. Bei anderen Sprachen können Schriftzeichen oder selten vertretene Bytefolgen stärker ins Gewicht fallen. Ein mehrsprachiges Vokabular kann die Unterschiede verringern, beseitigt sie aber nicht automatisch.

Eine feste Rangliste wäre irreführend. Derselbe deutsche Text kann mit zwei Tokenizern verschieden lang werden. Code, Tabellen, Namen und Tippfehler verhalten sich wieder anders als normaler Fließtext. Auch ein allgemeiner Wert wie „ein Wort entspricht 1,7 Tokens“ gilt nur für die gemessenen Texte und den gewählten Tokenizer.

Für deine Planung hilft deshalb nur eine eigene Messung. Nimm echte Beispiele aus eurem Prozess. Miss Eingaben und gewünschte Ausgaben mit dem Tokenizer des vorgesehenen Modells. So siehst du, welche Sprache und welche Dokumentarten besonders viel Platz und Geld brauchen.

Das Kontextfenster und der Wettbewerb um Platz

Nehmen wir an, du lässt einen Liefervertrag zusammenfassen. Die Anwendung sendet nicht nur deine sichtbare Frage. Sie kann außerdem eine Systemanweisung, Teile des bisherigen Gesprächs, gefundene Vertragsabsätze und Ergebnisse aus Werkzeugen mitsenden.

Dieses Arbeitspaket heißt Kontext. Das Kontextfenster ist die technische Obergrenze für die Tokenpositionen, die bei einem Modellaufruf verarbeitet werden können. Die genaue Zählweise steht in der Dokumentation des Modells oder Dienstes. Häufig teilen sich Eingabe und möglicher Ausgabetext eine Obergrenze. Es gibt aber auch getrennte Grenzen.

Alle Bestandteile konkurrieren um Platz. Eine lange Systemanweisung lässt weniger Raum für Dokumente. Zehn gefundene Quellen verdrängen vielleicht einen Teil des Gesprächs. Eine ausführliche Werkzeugantwort verkleinert den Platz für die eigentliche Antwort.

Abbildung 3: Bei einem häufigen Schema teilen sich Systemanweisung, Verlauf, Quellen, Werkzeugergebnisse, Frage und Antwort eine gemeinsame Obergrenze. Wird der Verlauf zu lang, muss die Anwendung Inhalte entfernen, verdichten oder die Anfrage ablehnen.

Was nicht mitgesendet wird, kann das Modell bei diesem Aufruf nicht direkt berücksichtigen. Das merkst du in langen Chats. Der sichtbare Verlauf wächst, bis die Anwendung handeln muss. Sie kann ältere Nachrichten abschneiden, eine Zusammenfassung einsetzen oder mit einer Fehlermeldung stoppen. Welche Variante gilt, entscheidet die Anwendung und nicht der Tokenizer.

Abschneiden ist riskant, wenn dabei eine Freigabe, eine Ausnahme oder ein wichtiger Name verschwindet. Zusammenfassen spart Platz, kann aber Details verändern. Eine Ablehnung ist unbequem, dafür wenigstens sichtbar. Im Unternehmen solltest du dieses Verhalten absichtlich testen.

Eine Tokenzahl lässt sich nicht fest in Seiten übersetzen. Nehmen wir nur als Rechenbeispiel 32.000 Tokenpositionen. Eine Messung deines deutschen Sachtexts ergibt 1,7 Tokens pro Wort. Dann passen rechnerisch rund 18.800 Wörter hinein. Bei 300 Wörtern pro Seite sind das ungefähr 63 Seiten. Für Code, Tabellen oder andere Sprachen kann dieselbe Grenze eine ganz andere Textmenge bedeuten.

Die Zahlen beschreiben kein bestimmtes Produkt. Sie zeigen nur die Rechnung. Für eine echte Planung misst du eure Dokumente, ziehst Systemanweisungen und technische Zusätze ab und reservierst genug Platz für die Ausgabe.

Warum langer Kontext keine verlässliche Nutzung garantiert

Ein Vertrag passt vollständig in das Fenster. Damit ist erst die Kapazitätsfrage beantwortet. Ob das Modell jede Klausel zuverlässig nutzt, ist eine andere Frage.

Die Untersuchung „Lost in the Middle“ prüfte zwei Arten langer Eingaben. Bei der Beantwortung von Fragen über mehrere Dokumente musste das Modell die Antwort aus dem passenden Dokument ableiten. Bei der Schlüssel-Wert-Suche musste es zu einem vorgegebenen Schlüssel den zugehörigen Wert zwischen vielen Paaren finden. Bei den untersuchten Modellen hing die Leistung deutlich von der Position der gesuchten Information ab. Inhalte am Anfang oder Ende wurden oft zuverlässiger genutzt als Inhalte in der Mitte.

Das ist kein Naturgesetz für jedes Modell und jede Aufgabe. Es ist ein Warnsignal für deine Tests. Ein System kann bei einer kurzen Eingabe gut funktionieren und bei derselben Information zwischen vielen unwichtigen Absätzen scheitern.

Zusätzlicher Kontext kann außerdem ablenken. Widersprüchliche Dokumentversionen, alte Regeln und ähnliche Namen erschweren die Auswahl. Für solche Leistungseinbußen bei wachsendem Kontext wird manchmal der Ausdruck „Context Rot“ verwendet. Das ist ein lockerer Sammelbegriff und keine einheitlich definierte technische Kennzahl.

Ein großes Kontextfenster ist deshalb keine Zusage für vollständiges Verständnis. Prüfe wichtige Informationen an verschiedenen Positionen. Mische passende und unpassende Quellen. Teste lange reale Dokumente statt künstlich kurzer Beispiele. Oft ist eine gezielte Auswahl relevanter Abschnitte besser als ein ungefilterter Aktenstapel.

Technischer Exkurs: besondere Tokens und Positionsgrenzen

Nicht jeder Token steht für sichtbaren Text. Ein Vokabular kann besondere Tokens enthalten. Sie markieren beispielsweise den Anfang oder das Ende einer Folge, trennen zwei Textteile oder füllen kurze Folgen in einer gemeinsamen Rechenladung auf. Manche Modellpakete kennzeichnen damit auch Rollen, Werkzeugaufrufe oder ausgelassene Textstellen.

Ein solcher Eintrag heißt besonderer Token, auf Englisch Special Token. Er hat wie jeder andere Token eine ID. Seine Aufgabe entsteht aus dem Training und der umgebenden Software. Der Tokenizer erkennt ihn als vollständige Einheit und zerlegt ihn nicht weiter.

Besondere Tokens sind modellabhängig. Eine scheinbar technische Zeichenfolge im Nutztext darf deshalb nicht automatisch als Steuerbefehl behandelt werden. Gute Tokenizer und Schnittstellen unterscheiden normalen Text von ausdrücklich erlaubten besonderen Tokens. Das ist auch eine Sicherheitsfrage.

Nun zur Reihenfolge. Die Token-IDs für „Hund beißt Mann“ enthalten dieselben Wörter wie „Mann beißt Hund“. Ohne Positionsinformation könnte das Modell die beiden Folgen nicht sauber unterscheiden.

Der ursprüngliche Transformer ergänzte deshalb für jede Stelle ein berechnetes Positionsmuster. Andere Modelle lernen Positionswerte. Viele heutige Modelle verwenden Rotary Position Embeddings, kurz RoPE. Dabei fließt die Position in den Vergleich zwischen Tokenpositionen ein. Die genaue Rechnung folgt in Kapitel 7.

Positionsverfahren, Training und Laufzeitprogramm bestimmen gemeinsam, welche Längen sinnvoll verarbeitet werden können. Dazu kommen Speicherbedarf und getestete Softwaregrenzen. Ein Tokenizer kann einen sehr langen Text noch in IDs zerlegen, obwohl das Modell diese Folge nicht auf einmal akzeptiert.

Eine höhere Zahl in einer Konfigurationsdatei schafft deshalb nicht automatisch ein zuverlässiges größeres Kontextfenster. Das Modell muss für solche Abstände ausgelegt, trainiert oder angepasst und anschließend getestet sein. Die veröffentlichte Grenze ist eine Eigenschaft des vollständigen Modellangebots, nicht bloß des Vokabulars.

Tokens werden zu Kosten, Grenzen und Datenschutz

Nehmen wir wieder die automatische Zusammenfassung von Kunden-Mails. Eine Beispiel-Mail hat 200 Wörter. Eine Messung mit dem gewählten Tokenizer ergibt für diese Texte 1,7 Tokens pro Wort. Die Mail braucht dann rund 340 Tokens. Eine Zusammenfassung mit 50 Wörtern braucht unter derselben Annahme etwa 85 Tokens. Die Anweisung belegt weitere 100 Tokens. Zusammen sind das ungefähr 525 Tokens pro Vorgang.

Diese Rechnung ist ein Arbeitsbeispiel. Der Wert von 1,7 gilt nicht allgemein für deutsche Texte. Auch die 100 Tokens der Anweisung sind nur eine Annahme. Im Betrieb misst du den vollständigen Aufruf mit euren echten Vorlagen.

Für die Kosten multiplizierst du die gemessenen Eingabe- und Ausgabetokens mit den vertraglich gültigen Preisen. Viele Dienste berechnen Eingabe, zwischengespeicherte Eingabe und Ausgabe unterschiedlich. Bei manchen Modellen kann zusätzlicher interner Rechenaufwand in die Nutzung einfließen. Preise und Zählweisen ändern sich. Eine feste Eurozahl in einem Buch wäre deshalb schnell nutzlos.

Für eine saubere Rechnung brauchst du die Abrechnungseinheit U aus deinem Vertrag. Nennt das Preisblatt einen Preis pro 1.000.000 Tokens, dann ist U = 1.000.000 Tokens. E_uncached sind die nicht zwischengespeicherten Eingabetokens. E_cached sind die zwischengespeicherten oder rabattierten Eingabetokens. A sind die Ausgabetokens. P_input, P_cache und P_output sind die jeweiligen Preise pro U. Dann gilt:

Kosten = E_uncached / U × P_input + E_cached / U × P_cache + A / U × P_output

Hat das Preisblatt einen eigenen Preis für zwischengespeicherte Eingaben, verwendest du die Formel oben. Enthält die gemeldete Gesamtzahl der Eingabetokens bereits die zwischengespeicherten Tokens, rechnest du E_uncached = gesamte Eingabetokens minus E_cached. So zählt kein Token doppelt.

Hat das Preisblatt nur einen Preis für alle Eingabetokens, entfällt der Cache-Summand. Für die Abrechnung setzt du dann E_cached = 0 und E_uncached = gesamte Eingabetokens. Du ziehst die zwischengespeicherten Tokens in diesem Fall nicht ab. Jedes Token gehört genau einmal in eine Vertragskategorie. Ohne eigene Cache-Kategorie sind zwischengespeicherte Tokens also nicht kostenlos.

Bei 1.000 solchen Kunden-Mails pro Tag werden aus rund 525 Tokens pro Vorgang ungefähr 525.000 Tokens täglich. Für eine Monatsplanung multiplizierst du diese gemessene Tagesmenge mit Arbeitstagen, Preisen und einem Zuschlag für ungewöhnlich lange Fälle. Das Beispiel zeigt die Größenordnung. Die Abrechnung muss mit euren tatsächlichen Mengen erfolgen.

Die Tokenmenge wirkt aber nicht nur auf Kosten:

• Kürzung. Lege fest, ob eine zu lange Anfrage abgelehnt, gekürzt oder verdichtet wird. Protokolliere, welcher Inhalt fehlt.
• Datenschutz. Jeder eingefügte Vertrag und jede nach Filterung oder neuer Rangfolge ausgewählte Quelle wird Teil der verarbeiteten Eingabe. Sende nur erforderliche Inhalte und prüfe Berechtigungen vor dem Abruf.
• Geschwindigkeit. Mehr Tokens bedeuten mehr Verarbeitung. Die genaue Wirkung hängt vom Modell und der technischen Ausführung ab.
• Qualität. Relevante kurze Quellen können besser funktionieren als ein großes ungefiltertes Paket.

Auch die Gestaltung der Anweisung zählt. Eine klare kurze Aufgabe spart Platz. Benenne gewünschtes Ergebnis, nötige Quelle und Grenzen. Wiederhole nicht dieselbe Regel in fünf Varianten. Kürze aber keine wichtigen Bedingungen nur wegen einiger Tokens.

Plane außerdem Platz für die Antwort. Wenn ein Bericht höchstens 400 Wörter haben soll, kannst du die Ausgabe technisch und inhaltlich begrenzen. Teste dann, ob die Grenze für Tabellen, Quellenangaben und Ausnahmen reicht.

Für größere Prozesse brauchst du eine kleine Messroutine. Erfasse Tokenmengen für typische, kurze und besonders lange Fälle. Trenne Eingabe und Ausgabe. Beobachte Kürzungen, Fehler, Laufzeit und Kosten. So wird aus einer Herstellerangabe eine belastbare Planung für euren Prozess.

Zähle Textbausteine statt Wörter

Du kannst die Zerlegung selbst sichtbar machen. Nimm das Werkzeug des vorgesehenen Tokenizers und gib einen deutschen Absatz, einen Namen, einen Tippfehler und ein zusammengesetztes Wort ein. Vergleiche danach dieselben Inhalte in einer anderen Sprache. Die Unterschiede sind keine allgemeine Rangliste. Sie gelten für genau diesen Tokenizer und diese Texte.

Prüfe anschließend, ob du diese Fragen beantworten kannst:

1. Warum reicht ein Wörterbuch aus ganzen Wörtern nicht aus?
2. Wie entstehen bei BPE neue Einträge im Vokabular?
3. Was unterscheidet Token, Token-ID und sichtbares Zeichen?
4. Welche Bestandteile konkurrieren im Kontextfenster um Platz?
5. Warum beweist ein großes Kontextfenster noch keine zuverlässige Nutzung?
6. Was muss dein Unternehmen für Kosten, Kürzung und Datenschutz messen?

Jetzt liegt dein Text als Folge von Token-IDs vor. Diese Nummern sind nur Adressen im Vokabular. Aus der Nummer 924 folgt nicht, ob ein Token eher mit Katze, Vertrag oder Rechnung zusammenhängt.

Das Modell braucht deshalb für jede ID eine gelernte Zahlenbeschreibung. Diese Zahlenbeschreibung heißt Embedding. Kapitel 6 zeigt, wie aus den Adressen geometrische Beziehungen entstehen.