Warum Sprachmodelle in Gesprächen ‘verloren’ gehen

Eine neue Studie von Microsoft Research und Salesforce zeigt, dass sogar die leistungsfähigsten Large Language Models (LLMs) auseinanderfallen, wenn Anweisungen in Stufen statt auf einmal gegeben werden. Die Autoren fanden heraus, dass die Leistung im Durchschnitt um 39 Prozent über sechs Aufgaben hinweg sinkt, wenn ein Prompt in mehrere Teile aufgeteilt wird:

Ein Gespräch in einer Runde (links) ergibt die besten Ergebnisse, aber ist für den Endbenutzer unnatürlich. Ein Gespräch in mehreren Runden (rechts) zeigt, dass sogar die höchstplatzierten und leistungsfähigsten LLMs den effektiven Impetus in einem Gespräch verlieren. Quelle: https://arxiv.org/pdf/2505.06120

Noch auffallender ist, dass die Zuverlässigkeit der Antworten stark abfällt, wobei renommierte Modelle wie ChatGPT-4.1 und Gemini 2.5 Pro zwischen fast perfekten Antworten und offensichtlichen Fehlern schwanken, je nachdem, wie die gleiche Aufgabe formuliert wird; außerdem kann die Konsistenz der Ausgaben um mehr als die Hälfte sinken.

Um dieses Verhalten zu untersuchen, führt die Studie eine Methode namens Sharding* ein, die vollständig spezifizierte Prompts in kleinere Fragmente aufteilt und diese einzeln in ein Gespräch einbringt.

In den grundlegendsten Begriffen ist dies äquivalent zu einer kohärenten und umfassenden Einzelanweisung in einem Restaurant, die den Kellner nichts anderes zu tun lässt, als die Anfrage zu bestätigen; oder sich entscheidet, die Angelegenheit gemeinsam anzugehen:

Zwei extreme Versionen eines Restaurantgesprächs (nicht aus der neuen Studie, nur zur Veranschaulichung).

Zum Zweck der Betonung stellt das obige Beispiel den Kunden vielleicht in einem negativen Licht dar. Aber die Kernidee, die in der zweiten Spalte dargestellt wird, ist die einer transaktionalen Übermittlung, die ein Problemset klärt, bevor sie die Probleme angeht – offensichtlich eine rationale und vernünftige Art, eine Aufgabe anzugehen.

Diese Einrichtung wird in der neuen Arbeit durch den tropfenweise, sharded-Ansatz zur LLM-Interaktion widerspiegelt. Die Autoren bemerken, dass LLMs oft übermäßig lange Antworten generieren und dann weiterhin auf ihre eigenen Erkenntnisse vertrauen, sogar nachdem diese Erkenntnisse als falsch oder irrelevant erwiesen haben. Diese Tendenz, kombiniert mit anderen Faktoren, kann dazu führen, dass das System die Übermittlung vollständig verliert.

Tatsächlich bemerken die Forscher, was viele von uns anekdotisch festgestellt haben – dass die beste Möglichkeit, das Gespräch wieder auf den richtigen Weg zu bringen, darin besteht, ein neues Gespräch mit dem LLM zu beginnen.

‘Wenn ein Gespräch mit einem LLM nicht zu den erwarteten Ergebnissen führte, kann das Starten eines neuen Gesprächs, das die gleichen Informationen wiederholt, wesentlich bessere Ergebnisse liefern als die Fortsetzung eines laufenden Gesprächs.

‘Dies liegt daran, dass aktuelle LLMs in einem Gespräch verloren gehen können, und unsere Experimente zeigen, dass es unwirksam ist, in einem Gespräch mit dem Modell zu beharren. Darüber hinaus kann ein neues Gespräch aufgrund der Zufälligkeit, mit der LLMs Text generieren, zu verbesserten Ergebnissen führen.’

Die Autoren erkennen an, dass agente Systeme wie Autogen oder LangChain möglicherweise die Ergebnisse durch das Agieren als interpretierende Schichten zwischen dem Endbenutzer und dem LLM verbessern können, indem sie nur mit dem LLM kommunizieren, wenn sie genügend sharded-Antworten gesammelt haben, um sie zu einer einzigen kohärenten Abfrage zusammenzufügen (die dem Endbenutzer nicht zugänglich gemacht wird).

Jedoch argumentieren die Autoren, dass eine separate Abstraktionsebene nicht notwendig sein sollte oderekt in das Quell-LLM integriert werden sollte:

‘Man könnte argumentieren, dass Multi-Turn-Fähigkeiten keine notwendige Funktion von LLMs sind, da sie an ein Agenten-Framework ausgelagert werden können. Mit anderen Worten, benötigen wir native Multi-Turn-Unterstützung in LLMs, wenn ein Agenten-Framework Interaktionen mit Benutzern orchestrieren und LLMs nur als Einzelrunden-Operatoren nutzen kann?…’

Aber nachdem sie die Proposition über ihre Reihe von Beispielen getestet haben, kommen sie zu dem Schluss:

‘[Die Abhängigkeit] von einem agentenähnlichen Framework, um Informationen zu verarbeiten, könnte einschränkend sein, und wir argumentieren, dass LLMs native Multi-Turn-Interaktion unterstützen sollten’

Diese interessante neue Studie trägt den Titel LLMs Get Lost In Multi-Turn Conversation und stammt von vier Forschern aus MS Research und Salesforce,

Fragmentierte Gespräche

Die neue Methode zerlegt zunächst herkömmliche Einzelrundenanweisungen in kleinere Fragmente, die so konzipiert sind, dass sie zu wichtigen Momenten während einer LLM-Interaktion eingeführt werden, eine Struktur, die den exploratorischen, wechselseitigen Stil der Interaktion in Systemen wie ChatGPT oder Google Gemini widerspiegelt.

Jede ursprüngliche Anweisung ist ein einzelner, in sich abgeschlossener Prompt, der die gesamte Aufgabe auf einmal liefert, einschließlich einer hochrangigen Frage, unterstützenden Kontext und aller relevanten Bedingungen. Die sharded-Version bricht dies in mehrere kleinere Teile auf, wobei jeder Shard nur ein Stück Information hinzufügt:

<img class=" wp-image-217458" src="https://www.unite.ai/wp-content/uploads/2025/05/sharded-and-unsharded.jpg" alt="Paarierte Anweisungen, die (a) einen vollständigen Prompt zeigen, der in einer einzigen Runde geliefert wird, und (b) seine sharded-Version, die zur Simulation einer unvollständigen, mehrteiligen Interaktion verwendet wird. Semantisch liefert jede Version die gleiche informative Nutzlast.” width=”908″ height=”213″ /> Paarierte Anweisungen, die (a) einen vollständigen Prompt zeigen, der in einer einzigen Runde geliefert wird, und (b) seine sharded-Version, die zur Simulation einer unvollständigen, mehrteiligen Interaktion verwendet wird. Semantisch liefert jede Version die gleiche informative Nutzlast.

Der erste Shard stellt immer das Hauptziel der Aufgabe vor, während der Rest klärende Details liefert. Zusammen liefern sie die gleiche Inhalte wie der ursprüngliche Prompt, aber sie werden über mehrere Runden im Gespräch verteilt.

Jedes simulierte Gespräch findet zwischen drei Komponenten statt: dem Assistant, dem Modell, das bewertet wird; dem Benutzer, einem simulierten Agenten mit Zugriff auf die vollständige Anweisung in sharded-Form; und dem System, das die Übermittlung überwacht und bewertet.

Das Gespräch beginnt mit dem Benutzer, der den ersten Shard offenlegt, und dem Assistant, der frei antwortet. Das System klassifiziert dann diese Antwort in eine der mehreren Kategorien, wie z.B. eine Klärungsanfrage oder ein Versuch einer vollständigen Antwort.

Wenn das Modell tatsächlich eine Antwort versucht, extrahiert eine separate Komponente nur den relevanten Teil für die Bewertung, wobei sie umgebenden Text ignoriert. Bei jeder neuen Runde offenlegt der Benutzer einen zusätzlichen Shard und löst damit eine weitere Antwort aus. Die Übermittlung geht weiter, bis das Modell die Antwort richtig gibt oder es keine Shards mehr zu offenbaren gibt:

<img class=" wp-image-217459" src="https://www.unite.ai/wp-content/uploads/2025/05/simulating-sharded-conversations.jpg" alt="Diagramm einer simulierte sharded-Konversation, wobei das bewertete Modell rot hervorgehoben ist.” width=”906″ height=”265″ /> Diagramm einer simulierte sharded-Konversation, wobei das bewertete Modell rot hervorgehoben ist.

Frühe Tests zeigten, dass Modelle oft nach Informationen fragten, die noch nicht geteilt worden waren, also gaben die Autoren die Idee auf, Shards in einer festen Reihenfolge zu offenbaren. Stattdessen wurde ein Simulator verwendet, um zu entscheiden, welcher Shard als nächstes zu offenbaren ist, basierend darauf, wie das Gespräch verlief.

Der Benutzersimulator, der mit GPT-4o-mini implementiert wurde, hatte daher vollen Zugriff auf die gesamte Anweisung und die Konversationsgeschichte und wurde beauftragt, bei jeder Runde zu entscheiden, welchen Shard als nächstes zu offenbaren ist, basierend darauf, wie die Übermittlung verlief.

Der Benutzersimulator formulierte auch jeden Shard um, um den Konversationsfluss aufrechtzuerhalten, ohne die Bedeutung zu ändern. Dies ermöglichte es der Simulation, den “Geben und Nehmen” von echtem Dialog widerzuspiegeln, während die Kontrolle über die Aufgabenstruktur aufrechterhalten wurde.

Bevor das Gespräch beginnt, erhält der Assistant nur die grundlegenden Informationen, die zur Aufgabenerfüllung erforderlich sind, wie z.B. ein Datenbankschema oder eine API-Referenz. Ihm wird nicht mitgeteilt, dass die Anweisungen aufgeteilt werden, und es wird ihm nicht der Weg gewiesen, wie er mit dem Gespräch umgehen soll. Dies geschieht absichtlich: In realen Anwendungen werden Modelle fast nie darüber informiert, dass ein Prompt unvollständig oder im Laufe der Zeit aktualisiert wird, und das Auslassen dieses Kontexts hilft der Simulation, das Verhalten des Modells in einem realistischeren Kontext widerzuspiegeln.

GPT-4o-mini wurde auch verwendet, um zu entscheiden, wie die Antworten des Modells klassifiziert werden sollten, und um endgültige Antworten aus diesen Antworten zu extrahieren. Dies half der Simulation, flexibel zu bleiben, führte jedoch gelegentlich zu Fehlern: Nachdem jedoch mehrere hundert Gespräche von Hand überprüft worden waren, fanden die Autoren heraus, dass weniger als fünf Prozent Probleme aufwiesen und weniger als zwei Prozent eine Änderung des Ergebnisses aufgrund davon zeigten, und sie betrachteten dies als einen niedrigen genug Fehler innerhalb der Projektparameter.

Gesprächsszenarien

Die Autoren verwendeten fünf Arten von Simulationen, um das Modellverhalten unter verschiedenen Bedingungen zu testen, jede eine Variation davon, wie und wann Teile der Anweisung offenbart werden.

Im Voll-Szenario erhält das Modell die gesamte Anweisung in einer einzigen Runde. Dies stellt das Standard-Benchmark-Format dar und dient als Leistungsreferenz.

Das Sharded-Szenario bricht die Anweisung in mehrere Teile auf und liefert sie einzeln, wodurch ein realistischeres, unvollständiges Gespräch simuliert wird. Dies ist das Haupt-Szenario, das verwendet wird, um zu testen, wie gut Modelle mit mehrteiliger Eingabe umgehen.

Im Concat-Szenario werden die Shards wieder zu einer einzigen Liste zusammengefügt, wobei ihre Formulierung beibehalten, aber die Rundenstruktur entfernt wird. Dies hilft, die Auswirkungen der konversationellen Fragmentierung von der Umformulierung oder Informationsverlust zu isolieren.

Das Recap-Szenario läuft wie Sharded, aber fügt eine abschließende Runde hinzu, in der alle vorherigen Shards noch einmal wiederholt werden, bevor das Modell eine endgültige Antwort gibt. Dies testet, ob ein Zusammenfassungsprompt dazu beitragen kann, verlorenen Kontext wiederzuerlangen.

Schließlich geht Snowball noch weiter, indem alle vorherigen Shards bei jeder Runde wiederholt werden, wodurch die gesamte Anweisung während der Gesprächsabfolge sichtbar bleibt – und ein noch vergebender Test der mehrteiligen Fähigkeit bietet:

<img class=" wp-image-217460" src="https://www.unite.ai/wp-content/uploads/2025/05/simulation-types.jpg" alt="Simulationsarten basierend auf sharded-Anweisungen. Eine vollständig spezifizierte Anweisung wird in kleinere Teile aufgeteilt, die dann entweder zur Simulation von Einzelrunden- (Voll, Concat) oder Mehr-Runden-Gesprächen (Sharded, Recap, Snowball) verwendet werden können, je nachdem, wie schnell die Informationen offenbart werden.” width=”839″ height=”410″ /> Simulationsarten basierend auf sharded-Anweisungen. Eine vollständig spezifizierte Anweisung wird in kleinere Teile aufgeteilt, die dann entweder zur Simulation von Einzelrunden- (Voll, Concat) oder Mehr-Runden-Gesprächen (Sharded, Recap, Snowball) verwendet werden können, je nachdem, wie schnell die Informationen offenbart werden.

Aufgaben und Metriken

Sechs Generierungsaufgaben wurden ausgewählt, um sowohl Programmier- als auch natürliche Sprachdomänen abzudecken: Code-Generierungs-Prompts wurden aus HumanEval und LiveCodeBench entnommen; Text-to-SQL-Abfragen stammten aus Spider; API-Aufrufe wurden mithilfe von Daten aus dem Berkeley Function Calling Leaderboard konstruiert; elementare Mathematikprobleme wurden von GSM8K bereitgestellt; Tabellen-Kapiteltitel-Aufgaben basierten auf ToTTo; und Multi-Dokument-Zusammenfassungen wurden aus dem Summary of a Haystack-Dataset entnommen.