Tokens: die eigentliche Währung
Text wird nicht in Wörter zerlegt, sondern in Tokens – häufige Zeichenfolgen, die ein Verfahren namens Byte Pair Encoding aus großen Textmengen gelernt hat. Häufige Wörter werden zu einem einzigen Token, seltene zerfallen in mehrere Bruchstücke.
Diese Einheit ist keine technische Randnotiz: Tokens sind die Abrechnungseinheit der Anbieter, sie bestimmen die Länge des Kontextfensters und sie erklären mehrere bekannte Schwächen von Sprachmodellen.
Als Faustregel gilt: Ein Token entspricht im Englischen etwa 4 Zeichen, im Deutschen eher 3. Deutsche Texte brauchen dadurch rund 30 bis 50 % mehr Tokens als englische mit gleichem Inhalt – bei gleicher Aussage also spürbar höhere Kosten.
| Inhalt | Umfang | Tokens (ungefähr) |
|---|---|---|
| Eine Normseite Text | 1.800 Zeichen | 600 – 700 |
| Eine DIN-A4-Seite Vertrag | ca. 500 Wörter | 700 – 900 |
| Ein 12-seitiger Vertrag | ca. 6.000 Wörter | 8.000 – 10.000 |
| Eine kurze E-Mail | 100 Wörter | 140 – 180 |
| Ein Geschäftsbericht | 80 Seiten | 60.000 – 75.000 |
| Kontextfenster heutiger Modelle | – | 128.000 – 1.000.000 |
Warum ein LLM Buchstaben nicht zählen kann
Die berühmte Frage, wie viele „r“ in „Erdbeere“ vorkommen, ist kein Zeichen mangelnder Intelligenz, sondern eine direkte Folge der Tokenisierung. Das Modell sieht nicht E-r-d-b-e-e-r-e, sondern zwei oder drei Zahlen-IDs. Nach den Buchstaben darin zu fragen, ist ungefähr so, als würde man jemanden nach den Pinselstrichen in einem Foto fragen.
Dasselbe Prinzip erklärt weitere Beobachtungen: Reime funktionieren mal gut, mal schlecht; Rechenaufgaben mit langen Zahlen gehen schief, weil „12345“ in mehrere Tokens zerfällt, die keine Stellenwerte kennen; und Rechtschreibaufgaben sind für Modelle unnatürlich schwer.
Praxisfolge: Kosten und Kontextfenster
Ein Unternehmen will 500 Verträge à 12 Seiten auswerten. Grobe Rechnung: 12 Seiten ≈ 6.000 Wörter ≈ 9.000 Tokens auf Deutsch. Mal 500 Verträge sind 4,5 Mio. Eingabe-Tokens – bei mittleren Modellpreisen ein niedriger zweistelliger Eurobetrag, also unkritisch. Kritisch wird etwas anderes: Wer alle 500 Verträge gleichzeitig in einen Prompt legen will, sprengt jedes Kontextfenster. Die Lösung heißt nicht „größeres Modell“, sondern sinnvolle Aufteilung – ein Vertrag pro Aufruf, oder gezielte Suche über Embeddings.
Embeddings: Bedeutung als Richtung im Raum
Nach der Tokenisierung folgt der zweite Übersetzungsschritt. Jede Token-ID wird durch einen Vektor ersetzt – eine Liste von typischerweise 768 bis 3.072 Zahlen. Diese Zahlen sind nicht willkürlich: Sie wurden so gelernt, dass Tokens mit ähnlicher Bedeutung ähnliche Vektoren bekommen.
Ähnlichkeit misst man dabei nicht als Abstand, sondern als Winkel zwischen zwei Vektoren – die Kosinus-Ähnlichkeit. Ein Wert nahe 1 bedeutet: fast dieselbe Richtung, also inhaltlich verwandt. Nahe 0: unabhängig. Negativ: gegensätzlich.
Das Bemerkenswerte daran ist, dass diese Struktur nicht von Menschen angelegt wurde. Niemand hat eingetragen, dass „Rechnung“ und „Beleg“ verwandt sind. Es ergibt sich daraus, dass beide Wörter in ähnlichen Zusammenhängen auftauchen.
RAG: der wichtigste Praxisfall für Embeddings
Retrieval Augmented Generation ist die verbreitetste Architektur für Unternehmens-KI – und sie beruht vollständig auf dem eben gezeigten Prinzip. Der Ablauf: Alle Dokumente werden in Abschnitte zerlegt, jeder Abschnitt wird in einen Vektor übersetzt und in einer Vektordatenbank abgelegt. Kommt eine Frage, wird auch sie in einen Vektor übersetzt, die ähnlichsten Abschnitte werden gesucht und zusammen mit der Frage an das Sprachmodell übergeben.
Der entscheidende Punkt: Das Modell wird dabei nicht trainiert und lernt nichts dazu. Es bekommt die relevanten Stellen einfach als Teil der Frage mitgeliefert. Deshalb lässt sich ein RAG-System binnen Minuten aktualisieren – neues Dokument rein, fertig – während Fine-Tuning Tage dauert und Spezialwissen erfordert.
- Aktuelle Daten ohne Neutraining – das Wissen liegt in der Datenbank, nicht im Modell
- Nachvollziehbarkeit: Man kann die Quellenstellen mit ausgeben und prüfen lassen
- Rechteverwaltung möglich: Es werden nur Abschnitte durchsucht, die der Fragende sehen darf
- Schwachstelle: Findet die Suche die falschen Abschnitte, antwortet auch das beste Modell falsch
- Die Zerlegung in Abschnitte ist Handwerk – zu klein zerstört den Zusammenhang, zu groß verwässert die Suche
Beispiel: interne Wissensdatenbank
Ein Maschinenbauer legt 3.200 Serviceberichte, Handbücher und Konstruktionsnotizen in ein RAG-System. Ein Techniker fragt: „Warum tritt bei Baureihe 400 nach längerem Stillstand Öl an der Vorderachse aus?“ Die Suche findet drei Serviceberichte mit ähnlichem Vektor – auch solche, in denen nicht „Ölaustritt“, sondern „Leckage am vorderen Lager“ steht. Genau das leistet die Suche über Bedeutung statt über Stichwörter. Das Modell fasst zusammen und nennt die Berichtsnummern, damit der Techniker nachschlagen kann.
Wo RAG-Systeme in der Praxis scheitern
RAG klingt nach einer Sache von zwei Wochen, und ein vorführbarer Prototyp ist es auch. Die Lücke zwischen „läuft in der Demo“ und „Mitarbeitende vertrauen dem System“ entsteht fast immer an denselben vier Stellen.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Antwort ignoriert das entscheidende Detail | Abschnitte zu groß – das Relevante geht im Rauschen unter | Kleiner schneiden (200–500 Tokens), an Überschriften statt an fixer Länge trennen |
| Antwort wirkt aus dem Zusammenhang gerissen | Abschnitte zu klein – Bezug fehlt | Überlappung zwischen Abschnitten, Dokumenttitel und Kapitel als Kopfzeile mitgeben |
| Passende Stelle wird gar nicht gefunden | Reine Vektorsuche versagt bei Nummern, Kürzeln, Produktnamen | Hybride Suche: Vektorsuche plus klassische Stichwortsuche kombinieren |
| Veraltete Aussagen erscheinen als aktuell | Alte Dokumentversionen liegen weiter in der Datenbank | Versionsstand und Datum als Metadaten führen und beim Suchen filtern |
Warum ein besseres Modell hier nicht hilft
Ein Versicherer stellt fest, dass sein Assistent bei Fragen zu Tarif „VK-2019“ falsche Auskünfte gibt. Die Vermutung im Haus: Das Modell sei zu schwach, man müsse auf die größte Variante wechseln. Tatsächlich fand die Vektorsuche den richtigen Abschnitt gar nicht – „VK-2019“ ist eine Zeichenfolge ohne Bedeutungsnähe zu irgendetwas. Das größere Modell formulierte die falsche Auskunft anschließend nur überzeugender. Erst die zusätzliche Stichwortsuche löste das Problem, bei gleichem Modell und niedrigeren Kosten.
Das Wichtigste in Kürze
- Text wird in Tokens zerlegt – Tokens sind Abrechnungseinheit und Grenze des Kontextfensters.
- Deutsch braucht durch Komposita deutlich mehr Tokens als Englisch.
- Buchstabenzählen, Reime und lange Zahlen sind schwach, weil das Modell Tokens statt Zeichen sieht.
- Embeddings sind Vektoren, deren Winkel zueinander Bedeutungsähnlichkeit ausdrücken.
- RAG holt passende Textstellen über Vektorähnlichkeit und legt sie der Frage bei – ohne Training.
- Bei RAG entscheidet die Qualität der Suche über die Qualität der Antwort.
?Wissens-Check
Beantworten Sie die Fragen, um Ihr Verständnis zu prüfen. Sie erhalten sofort eine Rückmeldung.
Frage 1.Was ist ein Token?
Frage 2.Warum tun sich Sprachmodelle schwer damit, Buchstaben in einem Wort zu zählen?
Frage 3.Was misst die Kosinus-Ähnlichkeit zwischen zwei Embeddings?
Frage 4.Was geschieht bei RAG mit dem Sprachmodell?