Warum Multi-Turn-Konversationen etwas anderes messen als isolierte Prompts

Isolierte Prompts und Konversationen über mehrere Gesprächsrunden sind nicht zwei Varianten desselben Tests. Das erste Design misst die Antwort auf eine kontrollierte Eingabe. Das zweite misst einen Verlauf: wie sich die Antwort nach Klarstellungen, Einschränkungen, Zwischenempfehlungen und vom Modell selbst eingeführten Informationen verändert.

Der Unterschied ist für die Sichtbarkeit einer Marke entscheidend. Ein Unternehmen kann in der ersten Antwort fehlen und erscheinen, nachdem der Nutzer sein Budget nennt. Es kann früh erwähnt, aber bei technischen Anforderungen ausgeschlossen werden. Oder es bleibt im Gespräch, ohne am Ende empfohlen zu werden.

Wenn wir alle diese Ereignisse in einem einzigen Prozentsatz zusammenfassen, übersehen wir genau das Verhalten, das wir verstehen wollen.

Was ein isolierter Prompt misst

Ein isolierter Prompt startet in einer neuen Sitzung ohne vorherige Nachrichten aus demselben Test. Zum Beispiel: „Welche Lösungen für die Rechnungsstellung eignen sich für einen Online-Shop in Rumänien?“

Dieses Design ist nützlich, wenn wir Antworten auf dieselbe Frage unter denselben Bedingungen vergleichen möchten. Wir können Sprache, Wortlaut, Engine, Schnittstelle oder Timing kontrolliert variieren. Die Beobachtung lässt sich relativ einfach klassifizieren: Marke vorhanden oder nicht vorhanden, zitiert oder nicht zitiert, empfohlen oder nur erwähnt.

Der Hauptvorteil ist die Vergleichbarkeit. Der Nachteil: Echte Nutzer fassen selten sämtliche Kriterien in einer perfekt formulierten Anfrage zusammen. Ein Prompt kann die anfängliche Entdeckung messen, zeigt aber nicht unbedingt, wie sich die Auswahl entwickelt.

Was eine Multi-Turn-Konversation misst

In einer Multi-Turn-Konversation hängt die Antwort in der dritten Runde von den vorherigen Nachrichten und Antworten ab. Die offizielle Dokumentation der OpenAI Conversations API beschreibt die Beibehaltung des Zustands zwischen Aufrufen. Die Google Interactions API kann die Kennung einer vorherigen Interaktion verwenden, um den Kontext fortzuführen.

Die Implementierung unterscheidet sich je nach System. In manchen Fällen wird der Verlauf erneut übermittelt; in anderen verwaltet der Server den Zustand. Für ein redaktionelles Audit ist entscheidend, wie die Historie erhalten wurde. Die Kennzeichnung „Multi-Turn“ beschreibt die Testbedingungen nicht vollständig.

Eine Konversation misst Dinge, die ein isolierter Prompt nicht erfassen kann: Zeitpunkt der ersten Nennung, Beständigkeit der Marke, Reaktion auf eine neue Einschränkung, Korrektur einer Fehlinformation und Umwandlung einer Erwähnung in eine Empfehlung.

Eine rumänische Nutzerreise in fünf Gesprächsrunden

Angenommen, eine Person betreibt einen Online-Shop und sucht nach einer Rechnungslösung:

1. Entdeckung: „Welche Art von Rechnungslösung ist für mich geeignet?“
2. Kontext: „Ich habe etwa 2.000 Bestellungen pro Monat und verkaufe in Rumänien.“
3. Integration: „Ich muss eine Verbindung mit der Shop-Plattform und dem Kurierunternehmen herstellen.“
4. Risiko: „Was sollte ich bei E-Rechnung, Support und Datenexport prüfen?“
5. Entscheidung: „Geben Sie mir eine kurze Liste und erklären Sie, warum Sie jede Option beibehalten haben.“

In der ersten Runde können wir die vorgeschlagene Kategorie und die Kriterien messen. In der zweiten kann eine Liste von Anbietern erscheinen. In der dritten lässt sich die Liste eingrenzen. In der fünften erfassen wir die abschließende Empfehlung und ihre Begründung.

Es wäre nicht fair, jeden Schritt in einen separaten Prompt umzuwandeln und zu behaupten, damit dieselbe Konversation reproduziert zu haben. Die Nachricht „Ich brauche außerdem eine Integration mit einem Kurierdienst“ ist ohne den vorherigen Kontext zu Rechnungsstellung und Online-Shop mehrdeutig.

Wenn die Eingabe einer Marke den Test verfälscht

Wenn der Evaluator fragt „Was halten Sie von Marke X?“, hat das Modell die Marke nicht organisch entdeckt. Der Test kann Wahrnehmung, sachliche Richtigkeit oder Vergleichbarkeit messen, darf aber nicht in den Nenner der organischen Sichtbarkeit eingehen.

Es gibt jedoch einen wichtigen Unterschied. Wenn das Modell Marke X in der zweiten Runde einführt, kann der simulierte Nutzer fragen: „Welche der genannten Optionen lässt sich in meine Plattform integrieren?“ Die Marke bleibt im Kontext, ohne dass der Evaluator sie vor ihrem ersten Auftreten eingebracht hat.

Für jede Gesprächsrunde führen wir ein Herkunftsfeld:

• user-seeded – der Name erscheint in der Nutzernachricht, bevor das Modell ihn einführt;
• model-introduced – das Modell bringt den Namen zuerst in die Konversation ein;
• context-carried – erscheint später, da es bereits Teil des Verlaufs war.

Nur der zweite Zustand belegt organische Entdeckung innerhalb dieses Verlaufs.

Festes Skript, adaptiver Nutzer oder Hybridprotokoll?

Ein festes Skript sendet unabhängig von der Modellausgabe dieselben Folgefragen. Das ist reproduzierbar, kann aber unplausibel werden: Der Nutzer fragt nach Einzelheiten zu einer Liste, die das Modell gar nicht geliefert hat.

Ein vollständig adaptiver simulierter Nutzer reagiert natürlich auf jede Ausgabe. Das erzeugt plausible Gespräche, führt aber eine zusätzliche Variationsquelle ein. Zwei Durchläufe können unterschiedlichen Zweigen folgen; dann vergleichen wir nicht mehr exakt denselben Test.

Ein Hybridprotokoll hält Persona, Ziel, Kriterien und Abbruchbedingungen konstant. Verzweigungen sind nur innerhalb einer vorab festgelegten Menge zulässig. Zum Beispiel:

• Wenn das Modell nach dem Budget fragt, antwortet der Nutzer mit der festgelegten Spanne;
• Wenn es eine Liste gibt, folgen Sie der Integrationsfrage;
• Wenn das Modell die Aufgabe zweimal ablehnt oder nicht versteht, wird das Gespräch beendet;
• Wenn das Modell eine Option empfiehlt, fragt der Nutzer nach Belegen und Einschränkungen.

So bewahren wir Realismus, ohne dass der Evaluator das Gespräch willkürlich auf ein gewünschtes Ergebnis lenkt.

Korrekte Einheiten und Nenner

Eine Konversation mit fünf Gesprächsrunden darf nicht automatisch als fünf Konversationen gezählt werden. Wir können getrennt berichten:

• Konversationssichtbarkeit = abgeschlossene geeignete Konversationen mit mindestens einer organischen Nennung ÷ alle abgeschlossenen geeigneten Konversationen;
• Rundensichtbarkeit = geeignete Gesprächsrunden mit einer Nennung ÷ alle geeigneten Gesprächsrunden;
• erste organische Nennung = Nummer der Gesprächsrunde, in der das Modell die Marke erstmals einführt;
• Beständigkeit = nachfolgende geeignete Runden, in denen die Marke Kandidat bleibt ÷ alle geeigneten Runden nach dem ersten Auftreten;
• Empfehlungskonvertierung = Konversationen, bei denen ein organisches Vorkommnis zu einer endgültigen Empfehlung wird ÷ Konversationen mit organischem Vorkommnis.

Diese Formeln erweitern die Konvention aus Der Nenner verändert das Ergebnis: die versteckte Falle bei KI-KPIs.

Ein Fehler kann sich über Gesprächsrunden fortpflanzen

Eine falsche Antwort zu Beginn kann den gesamten Verlauf beeinflussen. Das Modell nimmt möglicherweise fälschlich eine Integration an, und der simulierte Nutzer setzt das Gespräch auf dieser Grundlage fort. Das Ergebnis ist keine Reihe unabhängiger Beobachtungen.

MT-Eval analysiert Muster wie Erinnerung, Erweiterung, Verfeinerung und Folgefragen und beschreibt für einige Aufgaben eine Verschlechterung in Multi-Turn-Kontexten. Das sagt nicht, welche Marken eine bestimmte Engine empfiehlt, stützt aber die Trennung von Konversationsbewertung und Single-Turn-Werten.

Bei der Klassifizierung markieren wir die erste Gesprächsrunde, in der der Fehler auftritt, sowie die davon abhängigen Runden. Einer einzigen wiederholten falschen Prämisse schreiben wir nicht fünf unabhängige Fehler zu.

Wiederholungen, saubere Sitzungen und vergleichbare Bedingungen

Jede Wiederholung beginnt in einer neuen Sitzung. Andernfalls kann die vorherige Konversation die nächste Beobachtung verfälschen. Wir protokollieren die verfügbare Engine und Version, Schnittstelle oder API, Datum, Sprache, Geografie, Einstellungen, Zustandsmechanismus und alle aktivierten Werkzeuge.

Läufe müssen über die Zeit verteilt werden, wenn wir die Stabilität abschätzen wollen, und nicht nur in einer Minute wiederholt. Wir melden auch Fehler: fehlende Antwort, Kontextbeschränkung, Ablehnung, Unterbrechung oder sinnlose Verzweigung.

NIST unterscheidet die Leistung unter einem festen Benchmark von der Verallgemeinerung auf andere ähnliche Beispiele. Diese Unterscheidung ist entscheidend: Ein Satz von 20 Konversationen beschreibt die getestete Stichprobe, nicht jedes mögliche Nutzerverhalten.

Was ein solcher Test nicht zeigen kann

Eine simulierte Konversation ist weder eine direkte Schätzung des tatsächlichen Marktanteils noch ein Beleg dafür, dass Nutzer das empfohlene Produkt kaufen werden. Wir kennen die vollständige Verteilung realer Nutzergruppen, Formulierungen und Absichten nicht. Zudem können Schnittstellen Antworten personalisieren oder auf eine Weise verändern, die der Test nicht erfasst.

Selbst das wiederholte Erscheinen in einer Konversationsgruppe zeigt nicht, warum die Marke ausgewählt wurde. Wir können die Begründung und die angegebenen Quellen analysieren, aber sie legen nicht alle internen Prozesse des Systems offen. Der Zusammenhang zwischen einem redaktionellen Eingriff und einer nachfolgenden Änderung sollte als Hypothese betrachtet werden, bis es ein vergleichbares Vorher-/Nachher-Design und angemessene Kontrollen gibt.

Der Bericht muss deshalb drei Ebenen unterscheiden: Rohbeobachtung, Klassifizierung durch den Evaluator und geschäftliche Interpretation. „Die Marke kam in 12 von 30 getesteten Konversationen vor“ ist eine Beobachtung. „Sie ist weithin bekannt“ ist eine Interpretation, die weitere Belege erfordert.

Diese Grenzen machen den Test nicht nutzlos. Sie definieren ihn als Diagnoseinstrument: Er zeigt, wo die Informationsabdeckung geprüft werden sollte, welche Aussagen unsicher sind und welche Szenarien weitere Untersuchungen benötigen.

LLM-as-judge ersetzt nicht die Validierung

Ein Modell kann helfen, Erwähnungen, Empfehlungen und Begründungen zu kennzeichnen. Der automatisierte Evaluator muss jedoch an einer von Menschen annotierten Stichprobe getestet werden. Das Bewertungsschema muss Erwähnung, Auflistung, bedingte Empfehlung und abschließende Empfehlung getrennt definieren.

Wenn dasselbe Modell den simulierten Nutzer erzeugt und das Ergebnis bewertet, können korrelierte Präferenzen auftreten. Wir bewahren Rohausgabe, Version des Bewertungsschemas und endgültige Entscheidung auf. Unklare Fälle gehen in die Prüfung und werden nicht in eine günstige Kategorie gezwungen.

Mindestanforderungen an einen Multi-Turn-Test

1. explizite Persona und Zielsetzung;
2. Kontext, Sprache und Geographie;
3. feste Kriterien und Informationen, die der Nutzer offenlegen darf;
4. Verzweigungsregeln;
5. Abbruchbedingungen und maximale Anzahl von Gesprächsrunden;
6. Regel für vom Nutzer eingegebene Markennamen;
7. Engine, Schnittstelle, Datum und Zustandsmechanismus;
8. Anzahl der Wiederholungen und neuen Sitzungen;
9. Kennzahlen auf Gesprächsrunden- und Konversationsebene;
10. Rubrik, menschliche Validierung und Transkriptaufbewahrung.

Dieses Protokoll folgt der allgemeinen Definition aus Was KI-Sichtbarkeit ist und wie man sie korrekt misst, setzt aber nicht voraus, dass ein Produkt bereits sämtliche beschriebenen Felder oder Integrationen implementiert.

Fazit

Ein isolierter Prompt beantwortet die Frage: „Was erzeugt die Engine für diese Eingabe?“ Eine Multi-Turn-Konversation beantwortet: „Wie entwickelt sich die Auswahl, wenn Kontext und Kriterien hinzukommen?“

Wir brauchen beides. Isolierte Prompts ermöglichen Kontrolle und Diagnose. Multi-Turn-Konversationen bilden Verlauf, Beständigkeit und die Umwandlung einer Nennung in eine Empfehlung annähernd ab. Ihre Werte dürfen jedoch nicht vermischt werden.

Wenn wir Markenherkunft, Verzweigungen, Historie, Abbruchbedingungen und Nenner festhalten, wird die Konversation zu einem überprüfbaren Experiment. Ohne diese Elemente bleibt lediglich eine überzeugend wirkende Demonstration.

Quellen

• OpenAI API – Gespräche
• Google AI für Entwickler – Interaktions-API
• Google AI für Entwickler – Multiturn-Textgenerierung
• NIST – Erweiterung der KI-Evaluierungs-Toolbox um statistische Modelle
• MT-Eval – EMNLP 2024
• MultiChallenge – Ergebnisse von ACL 2025

Letzte Quellenprüfung: 31. Juli 2026. Journey-Beispiele und Formeln sind redaktionelle Methoden, keine Ergebnisse eines AYSA-Benchmarks und keine Behauptungen über bereits veröffentlichte Funktionen.