Das Verhaltensmodell — wie LLM-Output tatsächlich entsteht
Einführung · 8 Abschnitte · ~7 Min Lesezeit · Stand
Warum das Verhaltensmodell?
Jeder LLM-Output entsteht mechanisch: das Modell zerlegt Text in Tokens und erzeugt die Antwort Token für Token, von links nach rechts. Fast jede „unerklärliche“ LLM-Macke folgt aus dieser Mechanik — nicht aus einem schlechten Prompt.
Wer die Mechanik kennt, trifft die richtige Entscheidung, statt stundenlang am Prompt zu drehen: Manche Probleme gehören in Code, manche brauchen andere Daten, manche sind schlicht eine Grenze, die kein Prompt überwindet.
Tokenisierung: Token ≠ Wort ≠ Zeichen
Das Modell liest weder rohen Text noch einzelne Zeichen, sondern Tokens — Wortstücke aus einem festen Vokabular (Subword-Verfahren wie BPE, Byte-Pair-Encoding). Ein Token ist mal ein ganzes Wort, mal eine Silbe, mal ein einzelnes Zeichen.
Erste Konsequenz: zeichen-exakte Operationen — Zeichen zählen, einen String umdrehen, auf exakt N Zeichen kürzen — liegen unter der Token-Ebene. Das Modell „sieht“ die einzelnen Zeichen innerhalb eines Tokens nicht zuverlässig. Solche Aufgaben gehören in Code, nicht in den Prompt.
Zweite Konsequenz: das Token-Budget ist keine Wortzahl. Weil die Vokabulare überwiegend auf englischem Text trainiert sind, zerfällt deutscher (und anderer nicht-englischer) Text in mehr Tokens pro Wort — Komposita, Umlaute und Flexion werden in kleinere Stücke gebrochen. Gleicher Inhalt, mehr Tokens.
Autoregression: Token für Token, ohne Zurück
Generierung ist autoregressiv: das Modell erzeugt ein Token, hängt es an die Eingabe an und sagt daraus das nächste voraus — bis ein Stop-Token fällt. Jedes Token bedingt sich auf alle vorherigen, und nichts wird zurückgenommen.
- Eingabe-Tokens
- Forward-Pass
- nächstes Token wählen
- Token anhängen
- wiederholen bis Stop
Daraus folgt zweierlei. Latenz skaliert mit der Output-Länge: jedes erzeugte Token ist ein eigener Forward-Pass. Und die Reihenfolge ist ein Korrektheitshebel: soll das Modell etwas schließen, muss die Überlegung vor dem Ergebnis stehen — ein Verdikt am Anfang kann nicht mehr auf eine danach generierte Begründung reagieren.
Sampling & Temperatur
Nach jedem Forward-Pass steht eine Wahrscheinlichkeitsverteilung über das nächste Token. Temperatur steuert, wie stark daraus zufällig gezogen wird: nahe 0 wählt das Modell fast immer das wahrscheinlichste Token (konsistent, wenig Varianz); höhere Werte erhöhen die Vielfalt — und das Risiko von Abwegen.
| Extraktion, Klassifikation, strukturierte Ausgabe | niedrige Temperatur (nahe 0) |
|---|---|
| Ideenfindung, Formulierungs-Varianten, Brainstorming | höhere Temperatur |
Nichtdeterminismus — auch bei Temperatur 0
Temperatur 0 macht die Auswahl deterministisch (immer das wahrscheinlichste Token), aber bei den meisten heute gehosteten APIs ist die Ausgabe trotzdem nicht bit-genau reproduzierbar — weil Anbieter standardmäßig keine batch-invarianten Kernel einsetzen.
Grund: Fließkomma-Addition ist nicht assoziativ ((a + b) + c ≠ a + (b + c)), und in massiv parallelen GPU-Kernen hängt die Reihenfolge der Summierungen u. a. von der Batch-Zusammensetzung ab. Winzige Abweichungen in den Logits lassen bei knappen Fällen ein anderes Token gewinnen. (Prinzipiell ist das mit batch-invarianten Kernen behebbar — nur wird es an geteilten Backends selten garantiert.)
Nebenbei: ein seed-Parameter beeinflusst nur die Zufallsauswahl beim Sampling. Bei Temperatur 0 wird gar nicht gesampelt — ein Seed ändert daran nichts.
Das Kontextfenster: endliches, ungleich genutztes Budget
Alles, was das Modell pro Aufruf berücksichtigt — Systemprompt, Historie, hineingegebene Dokumente, die bisher erzeugte Antwort — teilt sich ein endliches Kontextfenster.
Voll ist nicht gut: Modelle nutzen Information am Anfang und Ende zuverlässiger als in der Mitte langer Kontexte — das Phänomen heißt „lost in the middle“. Und jedes zusätzliche Token kostet Latenz und Geld.
Parametrisches Wissen, Cutoff und Konfabulation
Was das Modell „weiß“, steckt in seinen Gewichten — gelernt aus Trainingsdaten bis zu einem Cutoff. Interne Daten (deine Systeme, Handbücher) und aktuelle Fakten (diese Woche) sind dort strukturell nicht enthalten. Kein größeres Modell und kein besserer Prompt ändern das; fehlende Fakten muss man zur Laufzeit bereitstellen — Grounding über Retrieval oder Tool.
Kritisch: fehlt ein Fakt, schweigt das Modell nicht. Es hat keinen Mechanismus, Nichtwissen zu markieren, und füllt die Lücke mit statistisch plausiblem Text aus seinen Priors — Konfabulation. Über nie gesehene interne Daten ist eine flüssige, souveräne Antwort ein Warnsignal, kein Beleg für Wissen.
Gleich im Check
Du kennst jetzt die Mechanik hinter dem Output: Tokenisierung (Zeichen-Grenzen, Budget), Autoregression (Latenz, Reihenfolge), Sampling (Temperatur, Nichtdeterminismus), das Kontextfenster (lost in the middle) und parametrisches Wissen (Grounding-Bedarf, Konfabulation).