3. Wie ein Sprachmodell funktioniert

Wie ein Sprachmodell funktioniert

Ein Sprachmodell tut eine einzige Sache: Es bekommt Text und sagt vorher, welches Zeichenstück am wahrscheinlichsten als nächstes kommt. Das ist keine Vereinfachung für den Unterricht, das ist die ganze Funktion. Alles, was diese Werkzeuge sonst zu können scheinen, entsteht daraus, dass diese eine Operation sehr gut funktioniert und in einer Schleife läuft.

Der Satz klingt bescheiden, und deshalb sind seine Konsequenzen so leicht zu übersehen. Sie erklären, warum Modelle erfinden, warum die Formulierung der Frage die Antwortqualität verändert und warum dasselbe Modell zweimal Verschiedenes antwortet.

Der Kern: das nächste Token

Nehmen wir den unvollständigen Satz Die Hauptstadt von Österreich ist. Das Modell berechnet für jedes mögliche nächste Token eine Wahrscheinlichkeit.

Nächstes Token	Wahrscheinlichkeit
`Wien`	0,94
`die`	0,02
`seit`	0,01
`Graz`	0,001
…	…

Dann wird eines ausgewählt, an den Text angehängt, und die Rechnung beginnt von vorn. Token für Token, bis ein Ende-Token kommt oder das Limit erreicht ist. Was Sie als flüssige Antwort lesen, ist eine Kette von einigen hundert solcher Einzelentscheidungen, von denen keine die späteren kennt.

Daraus folgt sofort etwas Wichtiges: Das Modell plant seine Antwort nicht. Es hat, während es das erste Wort wählt, keinen fertigen Gedanken, den es dann formuliert. Ein Modell, das eine falsche Behauptung angefangen hat, führt sie eher konsistent weiter als dass es mitten im Satz umkehrt, denn die plausible Fortsetzung eines falschen Anfangs ist die falsche Fortsetzung. Genau hier setzen die Reasoning-Verfahren aus Kapitel 5 an.

Wie das Modell dazu kommt: Training in Stufen

Ein Modell besteht aus Parametern, auch Gewichte genannt: Zahlen, die bestimmen, wie aus der Eingabe die Wahrscheinlichkeitsverteilung wird. Ein heutiges großes Modell hat davon hunderte Milliarden. Training heißt: diese Zahlen so einstellen, dass die Vorhersagen gut werden. Das geschieht in drei Stufen, die man unterscheiden muss, weil sie verschiedene Eigenschaften erzeugen.

flowchart LR
  A["1. Pretraining<br/>riesige Textmengen<br/>Aufgabe: nächstes Token"] --> B["2. Supervised Fine-Tuning<br/>Beispieldialoge<br/>Aufgabe: antworten statt fortsetzen"]
  B --> C["3. Alignment (RLHF)<br/>Bewertungen von Antworten<br/>Aufgabe: hilfreich und harmlos"]
  C --> D["ausgeliefertes Modell"]

Pretraining ist der teure Teil. Das Modell liest gewaltige Textmengen aus dem Web, aus Büchern, aus Code-Repositories, und lernt dabei nichts anderes als die Vorhersage des nächsten Tokens. Der bemerkenswerte Befund der letzten Jahre ist, dass dabei nebenbei viel mehr entsteht als Grammatik: Um Text über Physik gut fortzusetzen, muss man etwas über Physik abbilden. Diese Stufe kostet Millionen und dauert Monate; sie wird von einer Handvoll Organisationen weltweit gemacht.

Supervised Fine-Tuning macht aus dem Textfortsetzer einen Antwortgeber. Ein Pretraining-Modell antwortet auf eine Frage möglicherweise mit weiteren Fragen, weil in seinen Trainingsdaten Fragen häufig in Listen von Fragen standen. Man trainiert es deshalb mit Beispieldialogen nach: Frage, gute Antwort. Nach dieser Stufe ist das Modell ein Assistent.

Alignment ist die Stufe, die den Charakter macht. Menschen (oder andere Modelle) bewerten Antworten, und das Modell wird darauf optimiert, hoch bewertete Antworten zu erzeugen. Das Verfahren heißt Reinforcement Learning from Human Feedback. Es sorgt dafür, dass ein Modell hilfsbereit klingt, Formatierung verwendet und heikle Anfragen ablehnt.

Diese dritte Stufe erklärt eine Eigenschaft, die im Umgang oft irritiert: Modelle sind darauf optimiert, dass ihre Antworten Menschen gefallen. Eine Antwort, die selbstbewusst, gut strukturiert und höflich ist, wird besser bewertet als eine, die zugibt, unsicher zu sein. Damit ist ein Anreiz für sicheres Auftreten eintrainiert, unabhängig davon, ob der Inhalt trägt. Aus derselben Quelle stammt die Neigung, Widerspruch nachzugeben: Wenn Sie einer korrekten Antwort widersprechen, ist ein Einlenken die besser bewertete Reaktion. Das ist die einzige Erklärung, die man braucht, um zu wissen, dass „Bist du sicher?” keine Prüfmethode ist.

Die Architektur: Transformer und Attention

Alle heutigen Sprachmodelle beruhen auf der Transformer-Architektur von 2017. Für die Arbeit mit ihnen braucht man davon vier Begriffe, ohne Formeln.

Tokenisierung. Der Eingabetext wird in Tokens zerlegt, kleine Zeichenstücke (Kapitel 4). Jedes Token bekommt eine Nummer.
Embedding. Jede Nummer wird in einen Zahlenvektor übersetzt, typischerweise mit einigen tausend Komponenten. Bedeutungsähnliche Tokens liegen in diesem Raum näher beieinander. Zusätzlich wird die Position im Text kodiert, denn Hund beißt Mann und Mann beißt Hund bestehen aus denselben Tokens.
Attention. Der eigentliche Trick. Für jedes Token berechnet das Modell, wie stark es auf jedes andere Token der Eingabe achten soll. Im Satz Der Server konnte die Anfrage nicht verarbeiten, weil er überlastet war muss er mit Server verknüpft werden und nicht mit Anfrage. Attention ist der Mechanismus, der diese Verknüpfung herstellt, und zwar gelernt und kontextabhängig, nicht nach Grammatikregeln.
Schichten. Der Attention-Schritt wird dutzende Male hintereinander ausgeführt. Frühe Schichten arbeiten an Oberflächlichem (Wortarten, Syntax), spätere an Abstrakterem (Bezüge, Absicht, Widersprüche). Am Ende steht eine Wahrscheinlichkeitsverteilung über alle Tokens.

Query, Key und Value

Wie stellt Attention diese Verknüpfung her? Aus dem Embedding jedes Tokens erzeugt das Modell über drei gelernte Matrizen drei verschiedene Vektoren, und jeder hat eine andere Aufgabe.

Vektor	Aufgabe	Salopp gesagt
Query (Q)	wonach dieses Token gerade sucht	„Ich bin ein Pronomen und suche mein Bezugswort”
Key (K)	wofür dieses Token gefunden werden will	„Ich bin ein maskulines Substantiv, Subjekt des Satzes”
Value (V)	was dieses Token beisteuert, wenn es gewählt wird	der eigentliche Bedeutungsbeitrag

Der Ablauf ist eine unscharfe Wörterbuch-Abfrage. Bei einer Map geben Sie einen Schlüssel an und erhalten genau einen Wert. Hier vergleicht das aktuelle Token seine Query mit den Keys aller Tokens, bekommt für jedes eine Ähnlichkeit, und das Ergebnis ist eine nach diesen Ähnlichkeiten gewichtete Mischung aller Values.

"er" bildet eine Query:  "suche maskulines Substantiv, Bezugswort"

vergleicht mit den Keys aller vorherigen Tokens:
  "Server"    Key ≈ "maskulines Substantiv, Subjekt"  → Ähnlichkeit hoch
  "Anfrage"   Key ≈ "feminines Substantiv, Objekt"    → Ähnlichkeit niedrig
  "die"       Key ≈ "Artikel"                         → Ähnlichkeit sehr niedrig

Ergebnis für "er": überwiegend der Value von "Server",
                   ein wenig von "Anfrage", fast nichts vom Rest

Key und Value sind zwei getrennte Dinge, und die Trennung ist der Kniff: Der Key entscheidet, ob ein Token gefunden wird, der Value ist, was man bekommt, wenn es gefunden wurde. Ein Token kann deshalb gut auffindbar sein und trotzdem etwas anderes beisteuern als das, wonach gesucht wurde.

Ein Merkmal von Attention hat direkte praktische Folgen: Der Aufwand wächst quadratisch mit der Textlänge. Doppelt so viel Kontext heißt viermal so viel Rechnung für diesen Schritt. Daran hängen die Kontextgrenzen, die Preise und die Beobachtung, dass Modelle in sehr langen Gesprächen träger und ungenauer werden. Moderne Modelle mildern das mit optimierten Verfahren, sie schaffen es nicht ab.

Sampling: warum zweimal dasselbe nicht dasselbe ist

Aus der Wahrscheinlichkeitsverteilung muss ein Token ausgewählt werden. Wie das geschieht, ist einstellbar.

Verfahren	Was es tut	Wirkung
Greedy	immer das wahrscheinlichste Token	reproduzierbar, neigt zu Wiederholungen
Temperature	flacht die Verteilung ab (hoch) oder spitzt sie zu (niedrig)	niedrig für Code und Extraktion, hoch für Textvarianten
Top-p (Nucleus)	wählt nur aus den Tokens, die zusammen p der Wahrscheinlichkeit ausmachen	begrenzt Ausreißer, ohne die Verteilung zu verzerren

Daraus folgt: Dieselbe Frage kann verschiedene Antworten liefern. Für die Entwicklung heißt das, dass ein Prompt, der einmal funktioniert hat, nicht getestet ist. Ein Prompt in einem Produktivsystem gehört mit denselben Methoden geprüft wie Code, und weil das Ergebnis nicht deterministisch ist, testet man gegen Eigenschaften („die Antwort ist gültiges JSON mit diesen Feldern”) und nicht gegen erwarteten Text.

Erwähnt sei, dass die Steuerung zunehmend verschwindet: Bei mehreren aktuellen Modellen sind temperature und top_p nicht mehr einstellbar und werden von der API abgewiesen. Die Begründung ist, dass die Modelle die passende Streuung selbst treffen und Prompt-Formulierung der wirksamere Hebel ist. Für die Praxis bedeutet es, dass man Varianz über die Aufgabenstellung erzeugt und nicht über einen Parameter.

Wie aus einem Textmodell ein Chat wird

Ein Sprachmodell kennt keine Rollen und keine Nachrichten, es kennt eine Token-Folge. Der Chat entsteht dadurch, dass die Anwendung die Unterhaltung in eine einzige Textfolge übersetzt, in der die Rollen markiert sind:

[System] Du bist ein Assistent für Webentwicklung. Antworte knapp.
[User] Wie setze ich einen HTTP-Statuscode in einem Route Handler?
[Assistant] Mit new Response(body, { status: 400 }).
[User] Und wenn die Validierung fehlschlägt?
[Assistant] ▮   <- hier setzt die Vorhersage an

Drei Folgerungen, die im Umgang ständig gebraucht werden.

Der System-Prompt ist Text wie jeder andere. Er wirkt stark, weil er am Anfang steht und das Modell darauf trainiert ist, ihm Gewicht zu geben. Er ist keine technische Sperre. Wer eine Regel wirklich durchsetzen will, setzt sie im Code durch, nicht im Prompt (Kapitel 12).
Bei jeder Runde wird alles neu geschickt. Das Modell erinnert sich nicht; die Anwendung wiederholt die gesamte Unterhaltung. Deshalb wird ein langes Gespräch mit jeder Runde teurer (Kapitel 4).
Die Grenze zwischen Anweisung und Inhalt ist eine Konvention. Alles ist dieselbe Token-Folge. Wenn ein Agent eine Datei einliest und darin steht „Ignoriere die bisherigen Anweisungen”, dann ist das Text an derselben Stelle wie Ihre Anweisung. Das ist Prompt Injection, und es ist keine Implementierungslücke, sondern eine Eigenschaft der Architektur.

Warum Modelle erfinden

Halluzinationen sind kein Fehler im Sinne eines Bugs, den man beheben könnte. Sie folgen aus der Funktion.

Das Modell ist darauf optimiert, plausible Fortsetzungen zu erzeugen, nicht wahre. Für den Großteil des Trainingsmaterials fällt das zusammen, weil wahre Aussagen häufiger sind. Wo das Material dünn wird, bleibt die Plausibilität übrig und die Wahrheit fällt weg. Eine erfundene Bibliotheksfunktion sieht deshalb genau so aus, wie eine echte Funktion dieser Bibliothek aussehen würde: richtiger Namensstil, passende Parameter, glaubwürdige Rückgabe. Sie existiert nur nicht.

Verschärft wird das durch die Alignment-Stufe: Ein Modell, das häufig „das weiß ich nicht” antwortet, wird schlechter bewertet. Die Neigung, irgendetwas zu liefern, ist mit eintrainiert.

Was hilft, ist nichts davon eine Lösung im Sinne einer Garantie:

Werkzeuge statt Gedächtnis. Ein Agent, der die Datei lesen und den Compiler laufen lassen kann, erfindet weniger, weil er nachsehen kann (Kapitel 8).
Prüfbare Ausgaben. Tests, Typprüfung, Linter, Schema-Validierung. Alles, was maschinell widerlegbar ist, wird maschinell widerlegt (Kapitel 11).
Kontext mitliefern. Wer die tatsächliche API-Dokumentation in den Prompt legt, bekommt Antworten daraus statt aus dem Gedächtnis. Das systematisch zu tun, ist der Gegenstand von Kapitel 7.
Misstrauen bei Namen und Zahlen. Funktionsnamen, Versionsnummern, Optionsflags, Zitate, URLs. Das sind die Stellen mit der höchsten Erfindungsrate, und sie sind alle in Sekunden nachprüfbar.

Häufige Stolperfallen

Glauben, das Modell plane seine Antwort. Es entscheidet Token für Token; ein falscher Anfang wird konsistent falsch weitergeführt.
„Bist du sicher?” als Prüfmethode. Nachgeben ist die besser bewertete Reaktion, nicht die richtigere. Sie messen damit Höflichkeit, nicht Korrektheit.
Vom Auftreten auf die Verlässlichkeit schließen. Selbstsicherer Ton ist Trainingsergebnis.
Kontext vollpacken. Irrelevante Information verschlechtert die Antwort, weil Attention alles gewichtet.
Einen Prompt nach einem erfolgreichen Lauf für getestet halten. Bei nicht deterministischer Ausgabe testet man gegen Eigenschaften, mehrfach.
Den System-Prompt für eine Sicherheitsgrenze halten. Er ist Text im selben Kontext wie alles andere.
Erfundene Funktionsnamen übernehmen. Sie sehen exakt richtig aus. Genau deshalb.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

Erklären: die Funktion eines Sprachmodells als Vorhersage des nächsten Tokens beschreiben und daraus ableiten, warum die Antwort nicht vorab geplant ist.
Nennen: die drei Trainingsstufen benennen und angeben, welche Eigenschaft des Modells in welcher Stufe entsteht.
Erklären: die Rolle von Tokenisierung, Embedding, Attention und Schichten in einem Transformer in eigenen Worten erklären.
Erklären: Query, Key und Value unterscheiden und an einem Satz zeigen, wie daraus die Verknüpfung zwischen zwei Tokens entsteht.
Erklären: begründen, warum Keys und Values eines Tokens feststehen, sobald es verarbeitet wurde, und warum sich daraus ein Cache ergibt.
Erklären: begründen, warum der Aufwand mit der Kontextlänge überproportional wächst und welche Folgen das für Kosten und Qualität hat.
Anwenden: Sampling-Parameter für eine gegebene Aufgabe passend wählen (oder begründen, warum sie nicht verfügbar sind) und die Nicht-Determiniertheit beim Testen berücksichtigen.
Erklären: erklären, wie eine Unterhaltung in eine Token-Folge übersetzt wird, und daraus die Zustandslosigkeit und die Anfälligkeit für Prompt Injection ableiten.
Beurteilen: Halluzinationen aus der Funktionsweise erklären und für einen konkreten Anwendungsfall geeignete Gegenmaßnahmen auswählen und begründen.