# Mehrturn-Verläufe und Zustand

> Was über mehrere Turns passiert: der gemessene Einbruch im Gespräch, Zuverlässigkeit statt Fähigkeit als Verlustursache, festgefahrene Annahmen, Instruktions-Drift, Zustand im Anwendungszustand statt im Verlauf — und der konsolidierte Neuanfang.

Track: [Prompt Engineering](https://physar.tech/learn/prompt-engineering)  
Kanonische Fassung: https://physar.tech/learn/prompt-engineering/multi-turn-prompting  
Stand: 2026-09-04  
Interaktiver Teil: 9 Checks (nur im Browser)

## Mehrturn-Verläufe und Zustand

### Der Verlauf ist Teil des Prompts

Die Schnittstelle zu einem Sprachmodell ist **zustandslos**. Es gibt keine Sitzung, in der das Modell etwas behält — bei jedem Turn wird der gesamte bisherige Verlauf erneut mitgeschickt. Was sich wie ein Gespräch anfühlt, ist eine Folge von Einzelaufrufen mit einem immer längeren Prompt.

Diese Einsicht ist die Grundlage des Moduls, weil sie zwei Dinge sofort erklärt. Erstens: Alles, was du über Kontext gelernt hast — Positionseffekt, Verdünnung, Kosten pro Aufruf — gilt hier verstärkt, denn der Prompt wächst mit jedem Turn. Zweitens: Wenn du ein Verhalten über zehn Turns willst, musst du es im zehnten Prompt haben, nicht im ersten.

> **Merksatz:** Es gibt keinen Gesprächszustand im Modell. Es gibt nur einen Prompt, der bei jedem Turn länger wird — und der System-Prompt bleibt dabei genau so lang, wie er war.

### Der gemessene Einbruch

Wie stark der Unterschied zwischen einer Einzelanfrage und einem Gespräch ist, war lange Erfahrungswissen. Laban und Kollegen haben es 2025 vermessen: über **200.000 simulierte Gespräche**, mit dem Ergebnis, dass **alle** getesteten führenden offenen und geschlossenen Modelle im Mehrturn-Betrieb deutlich schlechter abschnitten — mit einem **durchschnittlichen Einbruch von 39 %** über sechs Generierungsaufgaben.

39 % ist keine Feinheit. Es ist der Unterschied zwischen einem System, das in der Demo überzeugt, und einem, das im echten Gespräch enttäuscht — und es erklärt eine wiederkehrende Beobachtung: Der Prototyp mit gut gestellten Einzelfragen funktionierte, und mit echten Nutzern, die nachfragen und präzisieren, funktioniert er nicht mehr.

Wichtig für die Einordnung ist die Bauart der Untersuchung: Verglichen wurde dieselbe Aufgabe einmal vollständig in einem Turn gestellt und einmal über mehrere Turns verteilt, in denen die Angaben schrittweise eintreffen. Der Einbruch entsteht also nicht dadurch, dass die Aufgabe schwerer wird — sie ist identisch. Er entsteht durch die **Verteilung** der Information über den Verlauf.

> **Was daraus folgt:** Ein Eval-Set aus Einzelanfragen misst den Fall, der in Produktion am seltensten vorkommt. Wer Mehrturn-Nutzung hat und Einzelturns testet, hat kein Eval — er hat eine Demo.

### Nicht die Fähigkeit bricht ein, die Zuverlässigkeit

Die interessantere Hälfte des Befunds ist die Zerlegung. Laban und Kollegen trennen den Leistungsverlust in zwei Anteile: einen **geringen** Verlust an Fähigkeit und einen **deutlichen** Anstieg der **Unzuverlässigkeit**. Das Modell kann die Aufgabe weiterhin — es tut es nur nicht mehr verlässlich.

Für die Praxis ist das die schlechtere Nachricht. Ein Fähigkeitsverlust wäre gleichmäßig und planbar: Man würde die Aufgabe vereinfachen oder das Modell wechseln. Ein Zuverlässigkeitsverlust heißt, dass derselbe Gesprächsverlauf beim einen Nutzer gut und beim nächsten schlecht ausgeht — und dass der Mittelwert im Dashboard harmloser aussieht, als die Erfahrung einzelner Nutzer ist.

|  |  |
| --- | --- |
| Wenn Fähigkeit einbricht | Wenn Zuverlässigkeit einbricht |
| Gleichmäßig schlechter — planbar | Streuung wächst — der Mittelwert verdeckt es |
| Ein besseres Modell hilft | Ein besseres Modell verschiebt die Streuung, beseitigt sie nicht |
| Im Test reproduzierbar | Im Test nur mit mehreren Läufen je Verlauf sichtbar |
| Nutzer erleben es einheitlich | Nutzer erleben Zufall — und melden es als Willkür |

> **Merksatz:** Miss im Mehrturn-Betrieb nicht nur den Mittelwert, sondern die **Streuung** — und lass jeden Testverlauf mehrfach laufen. Ein einmal gelungener Verlauf beweist nichts über den nächsten.

### Festgefahrene Annahmen

Der Mechanismus dahinter ist konkret benannt und deckt sich mit dem, was in Nutzungsprotokollen zu sehen ist: Modelle treffen in **frühen** Turns Annahmen, versuchen vorzeitig eine endgültige Lösung zu erzeugen und verlassen sich anschließend zu stark darauf. Die Zusammenfassung der Autoren ist unmissverständlich — nimmt ein Modell im Gespräch eine falsche Abzweigung, verliert es den Faden und **erholt sich nicht** davon.

**Festgefahrene Annahme:** Eine früh im Gespräch getroffene, unausgesprochene Festlegung — über die Absicht, den Kontext oder das Ziel —, die in allen weiteren Turns mitgeführt wird. Sie wird nicht revidiert, weil sie nie als Annahme markiert war, sondern als Voraussetzung im Verlauf steht.

Der Punkt für den Entwurf: Eine Korrektur in Turn 5 muss gegen fünf Turns eigener Ausgabe arbeiten, die die falsche Annahme stützen. Das ist ein struktureller Nachteil und keine Frage der Formulierung — und er ist der Grund, warum der wirksamste Eingriff oft nicht die Korrektur ist, sondern der Neuanfang.

> **Merksatz:** Ein Modell erholt sich nicht von einer falschen Abzweigung, es baut darauf auf. Wer Turn 5 korrigiert, verhandelt gegen den eigenen Verlauf des Modells.

### Instruktions-Drift

Eine unmittelbare Folge der wachsenden Länge: Der System-Prompt steht am Anfang und bleibt konstant, während der Gesprächstext wächst. Nach zwanzig Turns ist sein Anteil am gesamten Prompt klein — und in der Mitte des Kontexts liegt inzwischen genau das, was gemäß Positionseffekt am schlechtesten verwertet wird.

Praktisch zeigt sich das als **Drift**: Der Ton wird lockerer, das Ausgabeformat weicht auf, eine Längenvorgabe wird ignoriert, eine Verweigerungsregel gibt beim vierten Nachfragen nach. Nichts davon ist ein Regelbruch im Einzelnen — es ist eine Verschiebung der Gewichte im Prompt.

Ein Detail, das die Diagnose erleichtert: Drift betrifft zuerst die Vorgaben, die **keine Struktur** haben. Eine Längenangabe in Prosa weicht früher auf als ein per Schema erzwungenes Ausgabefeld, und ein Tonwunsch früher als eine Enum-Beschränkung. Wenn also eine Vorgabe über die Turns wegdriftet, ist die erste Frage, ob sie sich erzwingen statt erbitten lässt.

- **Regeln nicht aus dem Verlauf ableitbar machen** — sie gelten, weil sie gelten, nicht weil sie in Turn 1 standen.
- **Den Operator-Kanal nutzen** — eine Betreiber-Anweisung mitten im Gespräch gehört in die System-Rolle, nicht in den Nutzer-Turn.
- **Format je Turn erzwingen** — was strukturiert sein muss, wird per Schema erzwungen und nicht per Erinnerung erbeten.
- **Über mehrere Turns testen** — eine Regel, die nur in Turn 1 geprüft ist, ist für den seltensten Fall geprüft.

> **Merksatz:** Drift ist keine Vergesslichkeit, sondern Verdünnung. Die Gegenmaßnahme ist nicht Nachdruck, sondern Struktur — und ein Test an der Stelle, an der die Regel beansprucht wird.

### Zustand gehört nicht in den Verlauf

Hier liegt die wichtigste Architekturentscheidung des Moduls, und sie wird häufig falsch getroffen. Wenn ein Gespräch Angaben sammelt — die gewählte Tarifoption, drei erfragte Felder, eine bestätigte Adresse —, darf dieser **Zustand** nicht dadurch existieren, dass er irgendwo im Verlauf steht.

Der Grund ist einfach: Zustand aus einem Verlauf zu **erschließen** ist eine Leseaufgabe mit Fehlerrate, und diese Fehlerrate steigt mit der Länge. Zustand in der Anwendung zu **halten** ist eine Zuweisung ohne Fehlerrate. Das Modell sollte den Zustand als **gegebenes Feld** vorfinden, nicht aus zwanzig Turns rekonstruieren.

|  |  |
| --- | --- |
| Gehört in den Anwendungszustand | Darf im Verlauf bleiben |
| Gewählte Optionen, bestätigte Werte, erhobene Felder | Der Wortlaut der Fragen und Antworten |
| Der Fortschritt in einem mehrstufigen Vorgang | Erläuterungen und Begründungen |
| Identifikatoren, Beträge, Fristen | Höflichkeitsteile und Nachfragen |
| Ob eine Freigabe erteilt wurde | Die Formulierung, mit der sie erteilt wurde |

> **Merksatz:** Was der Vorgang **ist**, gehört in den Anwendungszustand. Was im Gespräch **gesagt wurde**, gehört in den Verlauf. Wer beides vermischt, macht die Korrektheit seines Vorgangs von einer Leseleistung abhängig.

### Verdichten statt anhäufen

Auch mit ausgelagertem Zustand wächst der Verlauf. Irgendwann muss verdichtet werden, und dafür gilt dieselbe Reihenfolge wie bei jeder Kompression: **zuerst verlustfrei aufräumen**, dann verlustbehaftet verdichten — und ausdrücklich benennen, was wörtlich erhalten bleiben muss.

- **Verlustfrei zuerst** — Höflichkeitsteile, Wiederholungen, zitierte Vorturns, abgeschlossene Nebenstränge.
- **Wörtlich erhalten** — Identifikatoren, Beträge, Fristen, Entscheidungen und ihre Bedingungen.
- **Offen von erledigt trennen** — was noch aussteht, gehört an eine feste, gut verwertete Position.
- **Die letzten Turns unverdichtet lassen** — der aktuelle Bezug leidet am stärksten unter Verdichtung.

Der Preis ist derselbe wie immer: Die Verdichtung ist eine zusätzliche Modellstufe mit eigener Fehlerrate, und ihr Fehler ist im Ergebnis nicht von einer falschen Antwort zu unterscheiden. Deshalb ist ausgelagerter Zustand der bessere erste Hebel — er reduziert, was überhaupt verdichtet werden muss.

> **Merksatz:** Verdichtung ist die zweite Maßnahme, nicht die erste. Wer Zustand auslagert, muss deutlich weniger verdichten — und verliert entsprechend weniger.

### Neustart statt Korrektur

Wenn ein Modell sich von einer falschen Abzweigung nicht erholt, folgt daraus eine unbequeme, aber wirksame Konsequenz: In einem verfahrenen Gespräch ist der **Neuanfang** mit einer konsolidierten Aufgabenstellung meist besser als die fünfte Korrektur im selben Verlauf.

### Ein verfahrener Verlauf

Ein Assistent soll eine Vertragsklausel prüfen. In Turn 2 hat er die Klausel als Kündigungsregel eingeordnet, obwohl es eine Haftungsregel ist. In Turn 3 bis 7 hat der Nutzer korrigiert, präzisiert und nachgefragt; der Assistent bezieht sich weiter auf Kündigungsfristen. Der Nutzer wird ungeduldig.

**Anforderungen**

- Was ist die wirksamste Maßnahme im Gespräch?
- Und was ist die Maßnahme im System, damit es nicht wieder passiert?

**Schritte**

- Im Gespräch: einen neuen Verlauf beginnen und die Aufgabe konsolidiert stellen — die Klausel, ihre Art, die Frage und die relevanten Einschränkungen in einem Turn. Fünf Turns Korrekturhistorie stützen die falsche Annahme und arbeiten gegen jede Präzisierung.
- Die Konsolidierung darf nicht der Nutzer leisten müssen: Die Anwendung baut den neuen Prompt aus dem Anwendungszustand — Klausel, erkannte Art, bisherige Präzisierungen als Felder, nicht als Zitat.
- Im System: die Einordnung der Klausel nicht als beiläufige Annahme entstehen lassen, sondern als ausdrücklichen, bestätigungspflichtigen Schritt mit eigenem Feld.
- Damit wird die Annahme sichtbar und einzeln korrigierbar — eine Korrektur ändert dann ein Feld und nicht den Verlauf.
- Und in den Tests: Verläufe aufnehmen, in denen die erste Einordnung falsch ist und danach korrigiert wird. Genau dieser Fall war ungeprüft.

**Merksatz:** Weil ein Modell auf einer falschen frühen Annahme aufbaut statt sie zu revidieren, ist der konsolidierte Neustart oft wirksamer als die nächste Korrektur — und die eigentliche Lösung ist, die Annahme zu einem sichtbaren Feld zu machen. **+** Der Nutzer kommt in einem Turn weiter statt in fünf nicht, und die Annahme wird einzeln korrigierbar. **−** Ein Neustart wirft berechtigten Kontext weg und fühlt sich für den Nutzer wie ein Rückschritt an; und der bestätigungspflichtige Schritt kostet in **jedem** Gespräch einen Turn, auch in den vielen, in denen die Einordnung richtig war.

### Was der Nutzer nicht leisten kann

Eine Versuchung, die man benennen muss: Aus dem Befund lässt sich ableiten, dass Nutzer ihre Aufgabe möglichst vollständig in einem Turn stellen sollten. Als Erkenntnis über Modelle richtig — als Produktanforderung untauglich. Nutzer wissen zu Beginn nicht, was relevant ist; genau deshalb fragen sie nach.

Die Konsequenz liegt also beim System, nicht beim Nutzer. Es muss die Konsolidierung selbst leisten: Zustand halten, Annahmen sichtbar machen, den Verlauf verdichten und bei Bedarf einen sauberen Neustart aufsetzen, ohne dass der Nutzer seine Angaben wiederholt. Eine Anleitung, wie man richtig fragt, ist keine Lösung, sondern eine Verlagerung.

> **Haltung:** Der Befund ist eine Anforderung an dein System, keine an deine Nutzer. Wer ihn in eine Bedienungsanleitung übersetzt, hat ihn nicht umgesetzt.

### Mehrturn testen

Aus 39 % Einbruch und wachsender Streuung folgt, wie ein Fallsatz aussehen muss: nicht als Liste von Einzelanfragen, sondern als **Verläufe** mit mehreren Turns — und jeder Verlauf mehrfach ausgeführt, weil die Unzuverlässigkeit und nicht der Mittelwert das Problem ist.

|  |  |
| --- | --- |
| Verlaufsart | Was sie prüft |
| Präzisierung in Turn 3 | Ob eine späte Angabe noch verarbeitet wird oder die frühe Annahme gewinnt. |
| Korrektur einer falschen Einordnung | Ob das Modell revidiert oder auf der Abzweigung aufbaut. |
| Zwanzig Turns mit Formatvorgabe | Ob das Ausgabeformat driftet. |
| Nachfragen nach einer Verweigerung | Ob die Regel beim vierten Anlauf noch hält. |
| Themenwechsel mitten im Gespräch | Ob alter Kontext unzulässig weiterwirkt. |

**Kurzcheck:** Euer Eval-Set enthält 80 Einzelanfragen und erreicht 91 %. In Produktion beschweren sich Nutzer über wechselhafte Qualität, besonders in längeren Gesprächen. Was ist der nächste Schritt?

- [x] Verläufe mit mehreren Turns aufnehmen und jeden mehrfach ausführen
- [ ] Das Eval-Set auf 300 Einzelanfragen erweitern
- [ ] Die Nutzerbeschwerden qualitativ auswerten, um Muster zu finden
- [ ] Das Kontextfenster erhöhen, damit längere Gespräche vollständig hineinpassen

> Genau. Das Set misst den Fall, der am seltensten vorkommt, und ein einmaliger Lauf je Fall zeigt die Streuung nicht — beides sind genau die Größen, die im Mehrturn-Betrieb einbrechen.

### Wie ausgelagerter Zustand konkret aussieht

Damit die Empfehlung nicht abstrakt bleibt: Der Anwendungszustand ist ein Objekt, das die Anwendung führt und bei jedem Turn **als Feld** in den Prompt setzt — nicht ein Abschnitt, den das Modell aus dem Verlauf zusammensucht. Ein Vorgang zur Vertragsprüfung könnte etwa `klausel_art`, `geprueft_gegen`, `offene_rueckfragen` und `freigabe_erteilt` führen.

Der Unterschied zeigt sich beim Lesen des Prompts. Steht dort `klausel_art: haftung`, ist die Einordnung eine gegebene Tatsache, die das Modell nicht neu erschließen muss und die sich mit einer Zuweisung korrigieren lässt. Steht sie nur im Verlauf, ist sie eine Leseaufgabe — und in Turn 15 eine Leseaufgabe über eine schlecht verwertete Position.

- **Die Anwendung schreibt** — jedes Feld wird aus einer bestätigten Nutzeraktion oder einem geprüften Modellergebnis gesetzt, nie aus einer Vermutung.
- **Das Modell liest** — die Felder erscheinen als abgegrenzter Block im Prompt, mit derselben Markierung wie andere Daten.
- **Korrektur ist eine Zuweisung** — `klausel_art` zu ändern kostet ein Feld, nicht fünf Turns Überzeugungsarbeit.
- **Der Zustand überlebt eine Verdichtung** — er liegt außerhalb des Verlaufs und wird von ihr nicht angetastet.

> **Merksatz:** Ein Feld, das der Vorgang braucht, gehört in ein Feld. Wer es aus dem Verlauf erschließen lässt, hat die Korrektheit seines Vorgangs an eine Leseleistung gekoppelt, die mit jedem Turn schlechter wird.

### Zusammenfassung — gleich im Check

Du kennst jetzt die Größen: der Verlauf **ist** der Prompt und wächst, der gemessene **Einbruch von 39 %** im Mehrturn-Betrieb, seine Zerlegung in geringen Fähigkeits- und großen **Zuverlässigkeits**-Verlust, **festgefahrene Annahmen**, von denen sich ein Modell nicht erholt, **Instruktions-Drift** als Verdünnung, **Zustand im Anwendungszustand** statt im Verlauf, **Verdichten** als zweite Maßnahme, der konsolidierte **Neustart** — und Tests, die Verläufe mehrfach ausführen.

> **Gleich im Check:** In den nächsten Aufgaben entscheidest du über Zustand, Verdichtung und Neustart. Die wiederkehrende Falle: eine Maßnahme, die im Verlauf ansetzt, wo eine im Anwendungszustand gehört hätte.

## Quellen

- Laban et al., LLMs Get Lost In Multi-Turn Conversation, 2025 — https://arxiv.org/abs/2505.06120
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024 — https://arxiv.org/abs/2307.03172
- Wallace et al., The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions, 2024 — https://arxiv.org/abs/2404.13208
- Anthropic — Prompt caching: Mid-conversation system messages — https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- Anthropic — Prompt engineering overview (Erfolgskriterien und empirische Tests) — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview
- Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024 — https://arxiv.org/abs/2310.01798
- Maynez et al., On Faithfulness and Factuality in Abstractive Summarization, ACL 2020 — https://arxiv.org/abs/2005.00661