Warum Sprachmodelle in Gesprächen “verloren” gehen

Eine neue Studie von Microsoft Research und Salesforce (CRM ) zeigt, dass sogar die leistungsfähigsten Large Language Models (LLMs) auseinanderfallen, wenn Anweisungen in Stufen gegeben werden, anstatt alle auf einmal. Die Autoren fanden heraus, dass die Leistung im Durchschnitt um 39 Prozent über sechs Aufgaben hinweg abnimmt, 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 Impuls in einem Gespräch verlieren. Quelle: https://arxiv.org/pdf/2505.06120

Eher überraschend ist, dass die Zuverlässigkeit der Antworten stark abnimmt, 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 Ausgabe um mehr als die Hälfte abnehmen.

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

In den grundlegendsten Begriffen ist dies äquivalent zu einer kohärenten und umfassenden Einzelbestellung in einem Restaurant, die dem Kellner nichts anderes zu tun lässt, als die Bestellung zu bestätigen; oder anders ausgedrückt, die Sache gemeinsam anzugehen:

Zwei extreme Versionen eines Restaurantgesprächs (nicht aus dem neuen Papier, nur zur Illustration).

Um es zu betonen, 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 Austausch, die ein Problemset vorab klärt, bevor sie die Probleme angeht – offensichtlich eine rationale und vernünftige Art, eine Aufgabe anzugehen.

Diese Einrichtung spiegelt sich in der neuen Arbeit wider, die einen tropfenweisen, sharded Ansatz für LLM-Interaktionen verwendet. Die Autoren bemerken, dass LLMs oft übermäßig lange Antworten generieren und dann weiterhin auf ihre eigenen Erkenntnisse vertrauen, selbst nachdem diese Erkenntnisse als falsch oder irrelevant erwiesen haben. Diese Tendenz, kombiniert mit anderen Faktoren, kann dazu führen, dass das System die Kontrolle über den Austausch vollständig verliert.

Tatsächlich bemerken die Forscher, was viele von uns anekdotisch gefunden haben – dass der beste Weg, das Gespräch wieder auf die richtige Spur 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, erheblich 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 die Fortsetzung eines Gesprächs mit dem Modell ineffektiv ist. Darüber hinaus kann ein neues Gespräch aufgrund der Zufälligkeit, mit der LLMs Text generieren, zu besseren Ergebnissen führen.’

Die Autoren erkennen an, dass agentische Systeme wie Autogen oder LangChain die Ergebnisse möglicherweise verbessern können, indem sie als interpretative Schichten zwischen dem Endbenutzer und dem LLM fungieren, nur dann mit dem LLM kommunizieren, wenn sie genügend “shardierte” Antworten gesammelt haben, um sie zu einer einzigen kohärenten Anfrage zu kombinieren (die dem Endbenutzer nicht zugänglich gemacht wird).

Jedoch argumentieren die Autoren, dass eine separate Abstraktionsschicht nicht notwendig sein sollte, oder zumindest direkt in die 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 Single-Turn-Operatoren nutzen kann?…’

Aber nachdem sie die These ü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’

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

Fragmentierte Gespräche

Die neue Methode zerlegt zunächst herkömmliche Single-Turn-Anweisungen in kleinere Scherben, die so konzipiert sind, dass sie zu bestimmten Zeitpunkten während einer LLM-Interaktion eingeführt werden, eine Struktur, die den explorativen, hin-und-her-ähnlichen Stil der Interaktion in Systemen wie ChatGPT oder Google Gemini widerspiegelt.

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

Paarierte Anweisungen, die (a) einen vollständigen Prompt in einer einzigen Runde und (b) seine shardierte Version zeigen, die zur Simulation einer unvollständigen, mehrstufigen Interaktion verwendet wird. Semantisch liefert jede Version die gleiche informative Nutzlast.

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

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

Das Gespräch beginnt mit der Offenlegung des ersten Scherbes durch den Benutzer und der Antwort des Assistenten. Das System klassifiziert diese Antwort dann in eine von mehreren Kategorien, wie z.B. eine Klärungsanfrage oder ein Versuch einer vollständigen Antwort.

Wenn das Modell versucht, eine Antwort zu geben, extrahiert eine separate Komponente nur den relevanten Teil für die Bewertung, wobei umgebender Text ignoriert wird. Bei jeder neuen Runde offenbart der Benutzer einen weiteren Scherbe und fordert eine weitere Antwort. Der Austausch wird fortgesetzt, bis das Modell die Antwort richtig gibt oder es keine Scherben mehr gibt, die offenbart werden können:

Diagramm einer shardierte Gesprächssimulation, wobei das bewertete Modell in Rot hervorgehoben ist.

Frühe Tests zeigten, dass Modelle oft nach Informationen fragten, die noch nicht geteilt worden waren, also wurde die Idee, Scherben in einer festen Reihenfolge offenzulegen, fallen gelassen. Stattdessen wurde ein Simulator verwendet, um zu entscheiden, welcher Scherbe als nächstes offengelegt werden sollte, basierend auf dem Verlauf des Gesprächs.

Der Benutzersimulator, der mit GPT-4o-mini implementiert wurde, hatte vollen Zugriff auf die gesamte Anweisung und die Gesprächsverlauf und wurde beauftragt, bei jeder Runde zu entscheiden, welcher Scherbe als nächstes offengelegt werden sollte, basierend auf dem Verlauf des Austauschs.

Der Benutzersimulator formulierte auch jeden Scherbe um, um den Gesprächsfluss aufrechtzuerhalten, ohne die Bedeutung zu ändern. Dies ermöglichte es der Simulation, den “Gib-und-Nimm”-Stil der realen Konversation widerzuspiegeln, während die Kontrolle über die Aufgabenstruktur aufrechterhalten wurde.

Bevor das Gespräch beginnt, erhält der Assistent nur die grundlegenden Informationen, die zur Erledigung der Aufgabe erforderlich sind, wie z.B. eine Datenbankschema oder eine API-Referenz. Er wird nicht darüber informiert, dass die Anweisungen aufgeteilt werden, und es wird ihm nicht empfohlen, das Gespräch auf eine bestimmte Weise zu handhaben. 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 die endgültigen Antworten aus diesen Antworten zu extrahieren. Dies half der Simulation, flexibel zu bleiben, führte aber gelegentlich zu Fehlern: Nachdem jedoch mehrere hundert Gespräche von Hand überprüft worden waren, stellten die Autoren fest, dass weniger als fünf Prozent Probleme aufwiesen und weniger als zwei Prozent aufgrund davon eine Änderung der Ergebnisse zeigten, und sie betrachteten dies als einen niedrigen Fehlerbereich im Rahmen des Projekts.

Simulationszenarien

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 offengelegt 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 Leistungsgrundlage.

Im Sharded-Szenario wird die Anweisung in mehrere Teile aufgeteilt und einzeln geliefert, wodurch ein realistischeres, unvollständiges Gespräch simuliert wird. Dies ist das Haupt-Szenario, das verwendet wird, um zu testen, wie gut Modelle mit mehrstufigen Eingaben umgehen.

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

Im Recap-Szenario läuft es wie Sharded, aber mit einem abschließenden Schritt, in dem alle vorherigen Scherben noch einmal wiederholt werden, bevor das Modell eine endgültige Antwort gibt. Dies testet, ob ein Zusammenfassungsprompt helfen kann, verlorenen Kontext wiederherzustellen.

Schließlich geht Snowball weiter, indem alle vorherigen Scherben bei jeder Runde wiederholt werden, wodurch die vollständige Anweisung während des Gesprächs sichtbar bleibt – und einen noch nachsichtigeren Test der Multi-Turn-Fähigkeit bietet.

Simulationsarten basierend auf shardierte Anweisungen. Eine vollständig spezifizierte Anweisung wird in kleinere Teile aufgeteilt, die dann entweder zur Simulation von Single-Turn- (Voll, Concat) oder Multi-Turn- (Sharded, Recap, Snowball) Gesprächen verwendet werden können, je nachdem, wie schnell die Informationen offengelegt werden.

Aufgaben und Metriken

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

Die Modellleistung wurde anhand von drei Kernmetriken gemessen: Durchschnittsleistung, Fähigkeit und Unzuverlässigkeit.

Durchschnittsleistung erfasste, wie gut ein Modell insgesamt über mehrere Versuche hinweg abschnitt; Fähigkeit spiegelte die besten Ergebnisse wider, die ein Modell erreichen konnte, basierend auf seinen besten Ausgaben; und Unzuverlässigkeit maß, wie sehr diese Ergebnisse variierten, wobei größere Lücken zwischen den besten und schlechtesten Ergebnissen eine weniger stabile Leistung anzeigten.

Alle Bewertungen wurden auf einer Skala von 0-100 angeordnet, um die Konsistenz über die Aufgaben hinweg zu gewährleisten, und die Metriken wurden für jede Anweisung berechnet – und dann gemittelt, um ein Gesamtbild der Modellleistung zu liefern.

Sechs shardierte Aufgaben, die in den Experimenten verwendet wurden, die sowohl Programmier- als auch natürliche Sprachgenerierung abdecken. Jede Aufgabe wird mit einer vollständig spezifizierten Anweisung und ihrer shardierte Version gezeigt. Zwischen 90 und 120 Anweisungen wurden von etablierten Benchmarks für jede Aufgabe adaptiert.

Konkurrenten und Tests

In den anfänglichen Simulationen (mit geschätzten Kosten von 5000 Dollar) wurden 600 Anweisungen, die sechs Aufgaben umfassten, shardierte und zur Simulation von drei Gesprächstypen verwendet: voll, concat und sharded. Für jede Kombination aus Modell, Anweisung und Simulationsart wurden zehn Gespräche durchgeführt, was über 200.000 Simulationen ergab – ein Schema, das es ermöglichte, sowohl die Gesamtleistung als auch tiefere Maße für Fähigkeit und Zuverlässigkeit zu erfassen.

Fünfzehn Modelle wurden getestet, die eine breite Palette von Anbietern und Architekturen umfassten: die OpenAI-Modelle GPT-4o (Version 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14) und das Denkmodell o3 (2025-04-16).

Anthropic-Modelle waren Claude 3 Haiku (2024-03-07) und Claude 3.7 Sonnet (2025-02-19), die über Amazon Bedrock zugänglich waren.

Google trug Gemini 2.5 Flash (Vorschau-04-17) und Gemini 2.5 Pro (Vorschau-03-25) bei. Meta-Modelle waren Llama 3.1-8B-Instruct und Llama 3.3-70B-Instruct, sowie Llama 4 Scout-17B-16E, die über Together AI zugänglich waren.

Die anderen Einträge waren OLMo 2 13B, Phi-4 und Command-A, die alle lokal über Ollama oder Cohere API zugänglich waren; und Deepseek-R1, der über Amazon Bedrock zugänglich war.

Für die beiden ‘Denk’-Modelle (o3 und R1) wurden die Token-Limits auf 10.000 erhöht, um längere Denkketten zu ermöglichen:

Durchschnittliche Leistungspunktzahlen für jedes Modell über sechs Aufgaben hinweg: Code, Datenbank, Aktionen, Daten-zu-Text, Mathematik und Zusammenfassung. Ergebnisse werden für drei Simulationsarten angezeigt: voll, concat und sharded. Modelle sind nach ihrem Durchschnittswert im vollständigen Szenario sortiert. Schattierung spiegelt den Grad der Leistungsabnahme vom vollständigen Szenario wider, wobei die letzten beiden Spalten die durchschnittlichen Rückgänge für concat und sharded im Vergleich zu voll anzeigen.

In Bezug auf diese Ergebnisse stellen die Autoren fest^†:

‘Auf hohem Niveau sieht man, dass jedes Modell seine Leistung in jeder Aufgabe verschlechtert, wenn man die Leistung in den vollständigen und shardierte Szenarien vergleicht, mit einer durchschnittlichen Verschlechterung von -39%. Wir nennen dieses Phänomen Lost in Conversation: Modelle, die in einem Labor-ähnlichen Szenario mit vollständig spezifizierten, einzelnen Runden hervorragende (90%+) Leistungen erzielen, haben in einem realistischeren Szenario, in dem das Gespräch unvollständig und mehrstufig ist, Schwierigkeiten bei den gleichen Aufgaben.’

Concat-Punktzahlen lagen im Durchschnitt bei 95 Prozent der voll-Punktzahl, was darauf hindeutet, dass die Leistungsabnahme im shardierte Szenario nicht durch Informationsverlust erklärt werden kann. Kleinere Modelle wie Llama3.1-8B-Instruct, OLMo-2-13B und Claude 3 Haiku zeigten eine stärkere Verschlechterung unter concat, was darauf hindeutet, dass kleinere Modelle im Allgemeinen weniger robust gegenüber Rephrasierung sind als größere Modelle.

Die Autoren bemerken^†:

‘Überraschenderweise verlieren leistungsstärkere Modelle (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) genauso in der Konversation, wie kleinere Modelle (Llama3.1-8B-Instruct, Phi-4), mit durchschnittlichen Verschlechterungen von 30-40%. Dies liegt teilweise an den Metrik-Definitionen. Da kleinere Modelle in voll niedrigere absolute Punktzahlen erreichen, haben sie weniger Spielraum für Verschlechterung als die besseren Modelle.

‘In Kürze, egal wie stark die Single-Turn-Leistung eines LLM ist, beobachten wir große Leistungsverschlechterungen im Multi-Turn-Szenario.’

Der anfängliche Test zeigt, dass einige Modelle in bestimmten Aufgaben besser abschnitten: Command-A bei Aktionen, Claude 3.7 Sonnet und GPT-4.1 bei Code; und Gemini 2.5 Pro bei Daten-zu-Text, was darauf hindeutet, dass die Multi-Turn-Fähigkeit je nach Domäne variiert. Denkmodelle wie o3 und Deepseek-R1 schnitten insgesamt nicht besser ab, vielleicht weil ihre längeren Antworten mehr Annahmen einführen, die das Gespräch verwirren.

Zuverlässigkeit

Die Beziehung zwischen Fähigkeit und Zuverlässigkeit, die in Single-Turn-Simulationen klar ist, scheint im Multi-Turn-Szenario auseinanderzufallen. Während die Fähigkeit nur moderat abnahm, doppelte sich die Unzuverlässigkeit im Durchschnitt. Modelle, die in vollständigen Prompts stabil waren, wie GPT-4.1 und Gemini 2.5 Pro, wurden genauso unbeständig wie schwächere Modelle wie Llama3.1-8B-Instruct oder OLMo-2-13B, sobald die Anweisung fragmentiert wurde.

Überblick über Fähigkeit und Unzuverlässigkeit, wie in einem Box-Plot (a) dargestellt, gefolgt von Zuverlässigkeits-Ergebnissen aus Experimenten mit 15 Modellen (b) und Ergebnissen aus dem schrittweisen Sharding-Test, bei dem Anweisungen in ein bis acht Scherben aufgeteilt wurden (c).

Modellantworten variierten oft um bis zu 50 Punkte bei der gleichen Aufgabe, auch wenn nichts Neues hinzugefügt wurde, was darauf hindeutet, dass die Leistungsabnahme nicht auf einen Mangel an Fähigkeit, sondern auf die Tatsache zurückzuführen ist, dass das Modell im Laufe der Runden zunehmend instabil wird.

Das Papier besagt^†:

‘[Obwohl] bessere Modelle tendenziell eine leicht höhere Multi-Turn-Fähigkeit haben, neigen alle Modelle, die wir testen, zu ähnlichen Unzuverlässigkeitsniveaus. Mit anderen Worten, in Multi-Turn-, unvollständigen Szenarien zeigen alle Modelle, die wir testen, sehr hohe Unzuverlässigkeit, wobei die Leistung im Durchschnitt um 50 Punkte zwischen dem besten und schlechtesten simulierten Lauf für eine feste Anweisung abnimmt.’

Um zu testen, ob die Leistungsverschlechterung mit der Anzahl der Runden zusammenhängt, führten die Autoren einen schrittweisen Sharding-Test durch, bei dem jede Anweisung in ein bis acht Scherben aufgeteilt wurde (siehe rechte Spalte im Bild oben).

Wenn die Anzahl der Scherben zunahm, stieg die Unzuverlässigkeit stetig, was bestätigte, dass selbst geringe Erhöhungen der Rundenzahl die Modelle instabiler machen. Die Fähigkeit blieb im Wesentlichen unverändert, was bestätigte, dass das Problem in der Konsistenz und nicht in der Fähigkeit liegt.

Temperaturregelung

Eine separate Reihe von Experimenten testete, ob die Unzuverlässigkeit einfach ein Nebenprodukt von Zufälligkeit ist. Dazu variierten die Autoren die Temperatur-Einstellung des Assistenten und des Benutzersimulators über drei Werte: 1,0, 0,5 und 0,0.

In Single-Turn-Formaten wie voll und concat verbesserte die Reduzierung der Temperatur des Assistenten die Zuverlässigkeit erheblich, wobei die Variation um bis zu 80 Prozent gesenkt wurde; im shardierte Szenario hatte jedoch die gleiche Intervention wenig Auswirkungen:

Unzuverlässigkeits-Punktzahlen für verschiedene Kombinationen von Assistenten- und Benutzertemperatur über voll, concat und shardierte Szenarien, wobei niedrigere Werte eine größere Konsistenz der Antworten anzeigen.

Selbst wenn sowohl der Assistent als auch der Benutzer auf eine Temperatur von null gesetzt wurden, blieb die Unzuverlässigkeit hoch, wobei GPT-4o eine Variation von etwa 30 Prozent zeigte, was darauf hindeutet, dass die Instabilität, die in Multi-Turn-Gesprächen beobachtet wird, nicht nur stochastisches Rauschen ist, sondern eine strukturelle Schwäche in der Art und Weise, wie Modelle fragmentierte Eingaben verarbeiten.

Auswirkungen

Die Autoren schreiben über die Auswirkungen ihrer Ergebnisse in ungewöhnlicher Länge am Ende des Papiers, argumentierend, dass starke Single-Turn-Leistungen keine Garantie für Multi-Turn-Zuverlässigkeit sind und warnend, dass man nicht zu sehr auf vollständig spezifizierte Benchmarks vertrauen sollte, wenn man die Realwelt-Tauglichkeit bewertet (da solche Benchmarks Instabilität in natürlicheren, fragmentierten Interaktionen verbergen).

Sie schlagen auch vor, dass Unzuverlässigkeit nicht nur ein Stichproben-Artefakt ist, sondern eine grundlegende Einschränkung in der Art und Weise, wie aktuelle Modelle sich entwickelnde Eingaben verarbeiten, und sie argumentieren, dass dies Bedenken für Agenten-Frameworks aufwirft, die auf anhaltendes Denken über Runden hinweg angewiesen sind.

Schließlich argumentieren sie, dass Multi-Turn-Fähigkeit als eine Kernfähigkeit von LLMs behandelt werden sollte, nicht als etwas, das an externe Systeme ausgelagert wird.

Die Autoren bemerken, dass ihre Ergebnisse wahrscheinlich die tatsächliche Größe des Problems unterschätzen und weisen auf die idealen Bedingungen des Tests hin: Der Benutzersimulator in ihrer Einrichtung hatte vollen Zugriff auf die Anweisung und konnte Scherben in einer optimalen Reihenfolge offenlegen, was dem Assistenten einen unrealistisch günstigen Kontext gab (in der realen Anwendung liefern Benutzer oft fragmentierte oder mehrdeutige Prompts, ohne zu wissen, was das Modell als nächstes hören muss).

Zusätzlich wurde der Assistent unmittelbar nach jeder Runde bewertet, bevor das vollständige Gespräch abgeschlossen war, was verhinderte, dass spätere Verwirrung oder Widersprüche bestraft wurden, was die Leistung sonst verschlechtert hätte. Diese Entscheidungen, die für die experimentelle Kontrolle notwendig waren, bedeuten, dass die im Experiment beobachteten Zuverlässigkeitslücken in der Praxis wahrscheinlich noch größer sind.

Sie kommen zu dem Schluss:

‘[Wir] glauben, dass die durchgeführten Simulationen einen harmlosen Testbereich für die Multi-Turn-Fähigkeiten von LLMs darstellen. Da die Bedingungen der Simulation übermäßig vereinfacht sind, glauben wir, dass die im Experiment beobachtete Verschlechterung eine Unterschätzung der Unzuverlässigkeit von LLMs ist und wie häufig LLMs in realen Szenarien in Gesprächen verloren gehen.‘

Schlussfolgerung

Jeder, der eine erhebliche Zeit mit einem LLM verbracht hat, wird die hier formulierten Probleme wahrscheinlich aus praktischer Erfahrung wiedererkennen; und die meisten von uns, denke ich, haben intuitiv “verlorene” LLM-Gespräche aufgegeben und ein neues begonnen, in der Hoffnung, dass das LLM “von vorne beginnen” und aufhören kann, sich auf Material zu fixieren, das in einem langen, verwirrenden und zunehmend frustrierenden Austausch aufgetaucht ist.

Es ist interessant zu beachten, dass das Hinzufügen mehr Kontexts zum Problem nicht unbedingt eine Lösung darstellt; und tatsächlich bemerken die Autoren, dass das Papier mehr Fragen aufwirft, als es Antworten liefert (außer in Bezug auf Wege, um das Problem zu umgehen).

* Verwirrend ist, dass dies nichts mit der herkömmlichen Bedeutung von ‘Sharding’ in KI zu tun hat.

† Die Autoren betonen dies selbst.

Erstveröffentlicht am Montag, den 12. Mai 2025