Warum Sprachmodelle in Gesprächen „verloren gehen“

Eine neue Studie von Microsoft Research und Salesforce kommt zu dem Schluss, dass selbst die fähigsten Large Language Models (LLMs) fallen auseinander, wenn Anweisungen gegeben werden in Stufen anstatt alles auf einmal. Die Autoren fanden heraus, dass die Leistung bei sechs Aufgaben um durchschnittlich 39 Prozent sinkt, wenn eine Eingabeaufforderung auf mehrere Runden aufgeteilt:

Eine Konversation mit einem einzigen Turn (links) erzielt die besten Ergebnisse, wirkt aber für den Endbenutzer unnatürlich. Bei einer Konversation mit mehreren Turns (rechts) verlieren selbst die am höchsten bewerteten und leistungsstärksten LLMs den effektiven Impuls. Quelle: https://arxiv.org/pdf/2505.06120

Noch auffälliger ist die Zuverlässigkeit der Antworten nimmt rapide ab, mit prestigeträchtigen Modellen wie CatGPT-4.1 und Gemini 2.5 Pro Je nachdem, wie dieselbe Aufgabe formuliert wird, schwanken die Ergebnisse zwischen nahezu perfekten Antworten und offensichtlichen Fehlern. Darüber hinaus kann die Konsistenz der Ergebnisse im Laufe des Prozesses um mehr als die Hälfte sinken.

Um dieses Verhalten zu untersuchen, stellt das Papier eine Methode vor, die genannt wird sharding*, das vollständig angegebene Eingabeaufforderungen in kleinere Fragmente aufteilt und diese einzeln in eine Konversation freigibt.

Im Grunde genommen ist dies dasselbe, als würde man in einem Restaurant eine zusammenhängende und umfassende Einzelbestellung aufgeben und dem Kellner nichts anderes übrig lassen, als die Bestellung zu bestätigen. Oder man beschließt, die Angelegenheit gemeinsam anzugehen:

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

Zur Verdeutlichung: Das obige Beispiel stellt den Kunden möglicherweise in ein negatives Licht. Die Kernidee der zweiten Spalte ist jedoch die eines transaktionalen Austauschs, der eine Problemstellung klärt, bevor sie angegangen wird – offenbar eine rationale und vernünftige Herangehensweise an eine Aufgabe.

Dieser Aufbau spiegelt sich in der tröpfchenweise zugeführten, geschert Ansatz zur LLM-Interaktion. Die Autoren stellen fest, dass LLMs oft übermäßig lange Antworten generieren und sich dann weiterhin auf ihre eigenen Erkenntnisse verlassen selbst wenn sich diese Erkenntnisse als falsch oder irrelevant herausgestellt habenDiese Tendenz kann in Kombination mit anderen Faktoren dazu führen, dass das System den Überblick über den Austausch vollständig verliert.

Tatsächlich stellen die Forscher fest, was viele von uns habe anekdotisch herausgefunden – dass der beste Weg, das Gespräch wieder in Gang 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 geführt hat, kann das Beginnen eines neuen Gesprächs, in dem dieselben Informationen wiederholt werden, zu deutlich besseren Ergebnissen führen, als die Fortsetzung eines laufenden Gesprächs.“

„Der Grund hierfür ist, dass aktuelle LLMs im Gespräch verloren gehen können und unsere Experimente zeigen, dass es ineffektiv ist, in einem Gespräch mit dem Modell zu verharren. Da LLMs zudem zufälligen Text generieren, kann ein neues Gespräch zu besseren Ergebnissen führen.“

Die Autoren erkennen an, dass agentische Systeme wie Autogen or LangChain kann die Ergebnisse möglicherweise verbessern, indem es als Interpretationsebene zwischen dem Endbenutzer und dem LLM fungiert und nur dann mit dem LLM kommuniziert, wenn genügend „geteilte“ Antworten gesammelt wurden, um sie zu einer einzigen zusammenhängenden Abfrage zusammenzufassen (die dem Endbenutzer nicht angezeigt wird).

Die Autoren behaupten jedoch, dass eine separate Abstraktionsschicht nicht notwendig sein sollte oder direkt in das Quell-LLM integriert werden sollte:

Man könnte argumentieren, dass Multi-Turn-Fähigkeiten kein notwendiges Feature von LLMs sind, da sie auf das Agenten-Framework ausgelagert werden können. Mit anderen Worten: Brauchen 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? …“

Doch nachdem sie die Aussage anhand ihrer zahlreichen Beispiele geprüft haben, kommen sie zu dem Schluss:

„[Sich] bei der Informationsverarbeitung auf ein agentenähnliches Framework zu verlassen, könnte einschränkend sein, und wir argumentieren, dass LLMs die Multi-Turn-Interaktion nativ unterstützen sollten.“

Das ist interessant neues Papier ist betitelt LLMs verlieren sich in mehrstufigen Gesprächenund stammt von vier Forschern aus MS Research und Salesforce.

Fragmentierte Gespräche

Die neue Methode zerlegt zunächst herkömmliche Einzelanweisungen in kleinere Teile, die in Schlüsselmomenten während einer LLM-Interaktion eingeführt werden sollen. Diese Struktur spiegelt den explorativen, hin- und hergehenden Interaktionsstil wider, der in Systemen wie ChatGPT oder Google Gemini zu sehen ist.

Jede ursprüngliche Anweisung ist eine einzelne, in sich geschlossene Eingabeaufforderung, die die gesamte Aufgabe in einem Rutsch ausführt und dabei eine allgemeine Frage, den unterstützenden Kontext und alle relevanten Bedingungen kombiniert. Die Shard-Version zerlegt dies in mehrere kleinere Teile, wobei jeder Shard nur eine Information hinzufügt:

Gepaarte Anweisungen zeigen (a) eine vollständige Eingabeaufforderung, die in einem Durchgang übermittelt wird, und (b) deren fragmentierte Version, die zur Simulation einer unterspezifizierten, mehrstufigen Interaktion verwendet wird. Semantisch liefert jede Version die gleiche Informationsnutzlast.

Der erste Teil stellt immer das Hauptziel der Aufgabe vor, während die übrigen erläuternde Details liefern. Zusammen liefern sie den gleichen Inhalt wie die ursprüngliche Aufforderung, verteilen sich aber auf natürliche Weise auf mehrere Gesprächsrunden.

Jedes simulierte Gespräch findet zwischen drei Komponenten statt: dem Assistent, das zu bewertende Modell; die Benutzer, ein simulierter Agent mit Zugriff auf die vollständige Anweisung in Sharded-Form; und die fragst, das den Austausch überwacht und bewertet.

Die Konversation beginnt damit, dass der Benutzer den ersten Shard enthüllt und der Assistent frei antwortet. Das System ordnet diese Antwort dann einer von mehreren Kategorien zu, beispielsweise Klärungsanfrage oder die vollständiger Antwortversuch.

Wenn das Modell enthalten? Beim Versuch einer Antwort extrahiert eine separate Komponente nur den relevanten Bereich zur Auswertung und ignoriert den umgebenden Text. Bei jedem neuen Zug deckt der Benutzer eine weitere Scherbe auf, was zu einer weiteren Antwort führt. Der Austausch wird fortgesetzt, bis das Modell entweder die richtige Antwort hat oder keine Scherben mehr zum Aufdecken übrig sind:

Diagramm einer Sharded-Konversationssimulation, wobei das ausgewertete Modell rot hervorgehoben ist.

Frühe Tests zeigten, dass die Modelle häufig nach Informationen fragten, die noch nicht geteilt worden waren. Daher verwarfen die Autoren die Idee, Shards in einer festgelegten Reihenfolge zu enthüllen. Stattdessen wurde ein Simulator verwendet, der je nach Gesprächsverlauf entschied, welcher Shard als nächstes enthüllt werden sollte.

Der mit GPT-4o-mini implementierte Benutzersimulator erhielt daher vollen Zugriff auf die gesamte Anweisung und den Gesprächsverlauf und musste bei jedem Schritt basierend auf dem Verlauf des Austauschs entscheiden, welcher Shard als Nächstes angezeigt werden sollte.

Der Benutzersimulator umformuliert Jeder Shard sorgte dafür, dass der Gesprächsfluss erhalten blieb, ohne die Bedeutung zu verändern. Dadurch konnte die Simulation das Geben und Nehmen eines echten Dialogs widerspiegeln und gleichzeitig die Kontrolle über die Aufgabenstruktur bewahren.

Vor Beginn der Konversation erhält der Assistent nur die grundlegenden Informationen, die er zur Erledigung der Aufgabe benötigt, wie beispielsweise ein Datenbankschema oder eine API-Referenz. Er wird nicht darüber informiert, dass die Anweisungen aufgeteilt werden, und er erhält auch keine konkrete Anleitung zur Konversationsabwicklung. Dies geschieht mit Absicht: In der Praxis werden Modelle fast nie darauf hingewiesen, dass eine Eingabeaufforderung unvollständig ist oder im Laufe der Zeit aktualisiert wird. Das Weglassen 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 daraus die endgültigen Antworten zu extrahieren. Dies trug dazu bei, die Simulation flexibel zu halten, führte aber gelegentlich zu Fehlern: Nach der manuellen Überprüfung mehrerer hundert Gespräche stellten die Autoren jedoch fest, dass weniger als fünf Prozent Probleme aufwiesen und weniger als zwei Prozent aufgrund der Probleme eine Ergebnisänderung zeigten. Sie hielten dies für eine ausreichend niedrige Fehlerquote im Rahmen des Projekts.

Simulationsszenarien

Die Autoren verwendeten fünf Simulationsarten, um das Modellverhalten unter verschiedenen Bedingungen zu testen. Jede dieser Simulationsarten stellt eine Variation dar, wie und wann Teile der Anweisung offenbart werden.

Im Vollständiger Bei dieser Einstellung erhält das Modell die gesamte Anweisung in einem Durchgang. Dies stellt das Standard-Benchmark-Format dar und dient als Leistungsbasis.

Die Scherbe Die Einstellung unterteilt die Anweisung in mehrere Teile und gibt diese einzeln aus. Dadurch wird eine realistischere, weniger spezifizierte Konversation simuliert. Dies ist die Haupteinstellung, mit der getestet wird, wie gut Modelle mit mehrstufigen Eingaben umgehen.

Im Konkat In dieser Einstellung werden die Shards wieder zu einer einzigen Liste zusammengefügt. Dabei bleibt der Wortlaut erhalten, die schrittweise Struktur wird jedoch entfernt. Dies hilft, die Auswirkungen der Gesprächsfragmentierung durch Umformulierungen oder Inhaltsverlust zu isolieren.

Die Rekapitulieren Einstellung läuft wie Scherbe, fügt aber einen letzten Schritt hinzu, in dem alle vorherigen Shards erneut formuliert werden, bevor das Modell eine endgültige Antwort gibt. Dadurch wird getestet, ob eine Zusammenfassungsaufforderung dazu beitragen kann, verlorenen Kontext wiederherzustellen.

Schließlich haben Schneeball geht weiter, indem er wiederholt alle vorherigen Scherben in jeder Runde, wodurch die vollständige Anweisung im Verlauf des Gesprächs sichtbar bleibt – und ein nachsichtigerer Test der Multiturn-Fähigkeit geboten wird.

Simulationstypen basierend auf Sharded-Anweisungen. Eine vollständig spezifizierte Eingabeaufforderung wird in kleinere Teile zerlegt, die dann verwendet werden können, um entweder Single-Turn-Konversationen (Full, Concat) oder Multi-Turn-Konversationen (Sharded, Recap, Snowball) zu simulieren, je nachdem, wie schnell die Informationen preisgegeben werden.

Aufgaben und Metriken

Sechs Generierungsaufgaben wurden ausgewählt, um sowohl Programmier- als auch natürliche Sprachdomänen abzudecken: Codegenerierungsaufforderungen wurden übernommen aus HumanEval und LiveCodeBench; Text-zu-SQL-Abfragen stammen von Spiders; API-Aufrufe wurden mithilfe von Daten aus dem Berkeley Funktionsaufruf-Bestenliste; elementare mathematische Probleme wurden bereitgestellt von GSM8K; tabellarische Untertitelungsaufgaben basierten auf ToTTo; und Zusammenfassungen mehrerer Dokumente wurden aus dem Zusammenfassung von „Ein Heuhaufen“ Datensatz.

Die Modellleistung wurde anhand von drei Kernmetriken gemessen: durchschnittliche Leistung, Eignungund Unzuverlässigkeit.

Durchschnittliche Leistung erfasst, wie gut ein Modell insgesamt über mehrere Versuche hinweg abgeschnitten hat; Eignung spiegelten die besten Ergebnisse wider, die ein Modell auf der Grundlage seiner Ergebnisse mit der höchsten Punktzahl erreichen konnte; und Unzuverlässigkeit gemessen, wie stark diese Ergebnisse variierten, wobei größere Unterschiede zwischen den besten und schlechtesten Ergebnissen auf ein weniger stabiles Verhalten hindeuteten.

Um die Konsistenz aller Aufgaben sicherzustellen, wurden alle Bewertungen auf einer Skala von 0 bis 100 angegeben. Für jede Anweisung wurden Metriken berechnet und anschließend der Durchschnitt ermittelt, um ein Gesamtbild der Modellleistung zu erhalten.

In den Experimenten wurden sechs Shard-Aufgaben verwendet, die sowohl Programmierung als auch natürliche Sprachgenerierung abdecken. Jede Aufgabe wird mit einer vollständig spezifizierten Anweisung und ihrer Shard-Version dargestellt. Für jede Aufgabe wurden zwischen 90 und 120 Anweisungen aus etablierten Benchmarks adaptiert.

Kandidaten und Tests

In den ersten Simulationen (mit geschätzten Kosten von 5000 US-Dollar) wurden 600 Anweisungen, die sich über sechs Aufgaben erstreckten, aufgeteilt und zur Simulation von drei Konversationstypen verwendet: voller, concatund geschertFür jede Kombination aus Modell, Anweisung und Simulationstyp wurden zehn Gespräche geführt, die insgesamt über 200,000 Simulationen ergaben – ein Schema, das es ermöglichte, sowohl die Gesamtleistung als auch tiefere Maßstäbe für Eignung und Zuverlässigkeit zu erfassen.

Getestet wurden 15 Modelle unterschiedlicher Anbieter und Architekturen: die OpenAI-Modelle GPT-4o (Version 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025) und das Denkmodell o3 (2025-04-16).

Anthropologische Modelle waren Claude 3 Haiku (2024-03-07) und Claude 3.7 Sonett (2025), abgerufen über Amazon Bedrock.

Google hat dazu beigetragen Gemini 2.5 Flash (Vorschau-04-17) und Gemini 2.5 Pro (Vorschau-03-25). Metamodelle wurden Lama 3.1-8B-Anweisung und Lama 3.3-70B-Anweisung, sowie Lama 4 Scout-17B-16E, über Together AI.

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

Für die beiden 'Denken' Modelle (o3 und R1), Token-Grenzwerte wurden auf 10,000 erhöht, um längere Argumentationsketten zu ermöglichen:

Durchschnittliche Leistungswerte für jedes Modell in sechs Aufgaben: Code, Datenbank, Aktionen, Daten-zu-Text, Mathematik und Zusammenfassung. Die Ergebnisse werden für drei Simulationstypen angezeigt: Voll, Concat und Sharded. Die Modelle sind nach ihrem durchschnittlichen Wert in der Volleinstellung sortiert. Die Schattierung spiegelt den Leistungsabfall gegenüber der Volleinstellung wider. Die letzten beiden Spalten zeigen den durchschnittlichen Rückgang für Concat und Sharded im Vergleich zur Volleinstellung.

Zu diesen Ergebnissen erklären die Autoren^†:

„Auf hohem Niveau, Jedes Modell weist bei jeder Aufgabe eine Leistungsminderung auf, wenn man die FULL- und SHARDED-Leistung vergleicht, mit einer durchschnittlichen Degradation von -39%. Wir nennen dieses Phänomen Im Gespräch verloren: Modelle, die in der laborähnlichen Umgebung eines vollständig spezifizierten, einstufigen Gesprächs eine herausragende Leistung (90 %+) erzielen auf genau die gleichen Aufgaben in einem realistischeren Umfeld, wenn das Gespräch nicht spezifiziert ist und mehrere Wendungen umfasst.‘

Konkat Die Ergebnisse lagen im Durchschnitt bei 95 Prozent voller, was darauf hindeutet, dass der Leistungsabfall in der Sharded-Umgebung 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 Umformulierungen sind als größere.

Die Autoren beobachten^†:

'Überraschenderweise, leistungsstärkere Modelle (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) verlieren sich im Gespräch ebenso wie kleinere Modelle (Llama3.1-8B-Instruct, Phi-4), mit durchschnittlichen Verschlechterungen von 30-40%. Dies ist teilweise auf metrische Definitionen zurückzuführen. Da kleinere Modelle niedrigere absolute Werte in FULL, sie haben weniger Spielraum für Verschlechterungen als die besseren Modelle.

„Kurz gesagt: Egal, wie gut die Singleturn-Leistung eines LLM ist, wir beobachten große Leistungseinbußen im Multiturn-Modus.“

Der erste Test zeigt, dass einige Modelle bei 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. Dies deutet darauf hin, dass die Multiturn-Fähigkeit je nach Domäne variiert. Reasoning-Modelle wie o3 und Deepseek-R1 schnitten insgesamt nicht besser ab, möglicherweise weil ihre längeren Antworten mehr Annahmen einführten, was die Konversation eher verwirrend machte.

Zuverlässigkeit

Der Zusammenhang zwischen Eignung und Zuverlässigkeit, der in Einzeldurchlaufsimulationen deutlich wurde, schien unter Mehrdurchlaufbedingungen auseinanderzufallen. Während die Eignung nur geringfügig abnahm, nahm die Unzuverlässigkeit ab. verdoppelt im Durchschnitt. Modelle, die bei Vollformat-Eingabeaufforderungen stabil waren, wie GPT-4.1 und Gemini 2.5 Pro, wurden genauso unberechenbar wie schwächere Modelle wie Llama3.1-8B-Instruct oder OLMo-2-13B, sobald die Anweisung fragmentiert wurde.

Übersicht über Eignung und Unzuverlässigkeit, dargestellt in einem Boxplot (a), gefolgt von Zuverlässigkeitsergebnissen aus Experimenten mit fünfzehn Modellen (b) und Ergebnissen aus dem schrittweisen Sharding-Test, bei dem Anweisungen in ein bis acht Shards aufgeteilt wurden (c).

Die Modellantworten variierten bei derselben Aufgabe oft um bis zu 50 Punkte, selbst wenn nichts Neues hinzugefügt wurde. Dies lässt darauf schließen, dass der Leistungsabfall nicht auf mangelnde Fähigkeiten zurückzuführen war, sondern darauf, dass das Modell zwischen den Runden zunehmend instabil wurde.

In dem Papier heißt es^†:

[Obwohl] bessere Modelle tendenziell eine etwas höhere Multiturn-Fähigkeit aufweisen, weisen alle Modelle tendenziell ein ähnliches Maß an Unzuverlässigkeit auf. Mit anderen Worten: In unterspezifizierten Multiturn-Einstellungen weisen alle von uns getesteten Modelle eine sehr hohe Unzuverlässigkeit auf, wobei die Leistung zwischen dem besten und dem schlechtesten simulierten Lauf für eine feste Anweisung im Durchschnitt um 50 Prozentpunkte abnimmt. "

Um zu testen, ob die Leistungsverschlechterung mit der Anzahl der Runden zusammenhängt, führten die Autoren ein Experiment zur schrittweisen Fragmentierung durch, bei dem jede Anweisung in ein bis acht Fragmente aufgeteilt wurde (siehe Spalte ganz rechts im Bild oben).

Mit der zunehmenden Anzahl an Shards stieg auch die Unzuverlässigkeit stetig an, was bestätigte, dass selbst geringfügige Erhöhungen der Rundenzahl führten zu instabileren ModellenDie Eignung blieb weitgehend unverändert, was bestätigt, dass das Problem in Konsistenz, nicht Fähigkeit.

Temperaturkontrolle

In einer separaten Versuchsreihe wurde geprüft, ob die Unzuverlässigkeit lediglich ein Nebenprodukt des Zufalls ist. Dazu variierten die Autoren die Temperatureinstellung sowohl des Assistenten als auch des Benutzersimulators um drei Werte: 1.0, 0.5 und 0.0.

In Singleturn-Formaten wie voller und concatDie Reduzierung der Temperatur des Assistenten verbesserte die Zuverlässigkeit deutlich und reduzierte die Abweichung um bis zu 80 Prozent. geschert In diesem Kontext hatte dieselbe Intervention nur geringe Auswirkungen:

Unzuverlässigkeitswerte für verschiedene Kombinationen von Assistenten- und Benutzertemperatur in den Einstellungen „Vollständig“, „Concat“ und „Sharded“, wobei niedrigere Werte auf eine größere Reaktionskonsistenz hinweisen.

Selbst wenn sowohl der Assistent als auch der Benutzer auf Nulltemperatur eingestellt waren, blieb die Unzuverlässigkeit hoch, wobei GPT-4o eine Abweichung von etwa 30 Prozent aufwies, was darauf hindeutet, dass die Instabilität, die bei mehrstufigen Gesprächen beobachtet wird, nicht nur stochastisches Rauschen, aber eine strukturelle Schwäche in der Art und Weise, wie Modelle fragmentierte Eingaben verarbeiten.

Folgen

Die Autoren beschreiben die Auswirkungen ihrer Erkenntnisse am Ende des Artikels ungewöhnlich ausführlich. Sie argumentieren, dass eine starke Single-Turn-Leistung keine Garantie für eine Multi-Turn-Zuverlässigkeit ist, und warnen davor, sich bei der Bewertung der Einsatzbereitschaft in der realen Welt zu sehr auf vollständig spezifizierte Benchmarks zu verlassen (da solche Benchmarks die Instabilität bei natürlicheren, fragmentierten Interaktionen verschleiern).

Sie legen auch nahe, dass Unzuverlässigkeit nicht nur ein Stichprobenartefakt ist, sondern ein grundlegende Einschränkung in der Art und Weise, wie aktuelle Modelle sich entwickelnde Eingaben verarbeiten, und sie weisen darauf hin, dass dies Bedenken hinsichtlich Agentenrahmen aufwirft, die auf anhaltendem Denken über Runden hinweg beruhen.

Schließlich argumentieren sie, dass die Multiturn-Fähigkeit als Kernfähigkeit von LLMs behandelt werden sollte und nicht als etwas, das auf externe Systeme ausgelagert werden sollte.

Die Autoren weisen darauf hin, dass ihre Ergebnisse wahrscheinlich unterschätzen das wahre Ausmaß des Problems und lenken die Aufmerksamkeit auf die idealen Bedingungen des Tests: Der Benutzersimulator in ihrem Setup hatte vollen Zugriff auf die Anweisung und konnte Shards in optimaler Reihenfolge anzeigen, was dem Assistenten einen unrealistisch günstigen Kontext verlieh (in der realen Welt geben Benutzer oft fragmentarische oder mehrdeutige Eingabeaufforderungen ein, ohne zu wissen, was das Modell als Nächstes hören muss).

Zusätzlich wurde der Assistent bewertet sofort nach jedem Gesprächsabschnitt, bevor das Gespräch vollständig begonnen hat. Dadurch wird verhindert, dass spätere Verwirrungen oder Selbstwidersprüche bestraft werden, was sonst die Leistung verschlechtern würde. Diese Auswahlmöglichkeiten sind zwar für die experimentelle Kontrolle notwendig, bedeuten aber, dass die in der Praxis beobachteten Zuverlässigkeitslücken wahrscheinlich noch größer sind als die berichteten.

Sie schließen daraus:

„[Wir] glauben, dass durchgeführte Simulationen ein gutes Testfeld für die Multiturn-Fähigkeiten von LLM darstellen.“ Aufgrund der stark vereinfachten Simulationsbedingungen gehen wir davon aus, dass die in den Experimenten beobachtete Verschlechterung höchstwahrscheinlich auf einer Unterschätzung der Unzuverlässigkeit von LLMs und der Häufigkeit beruht, mit der LLMs in realen Situationen in Gesprächen verloren gehen.'

Fazit

Jeder, der längere Zeit mit einem LLM verbracht hat, wird die hier angesprochenen Probleme wahrscheinlich aus praktischer Erfahrung wiedererkennen; und ich stelle mir vor, dass die meisten von uns „verlorene“ LLM-Gespräche intuitiv aufgegeben und neue aufgenommen haben, in der Hoffnung, dass der LLM vielleicht „von vorne beginnt“ und aufhört, sich mit dem Material zu beschäftigen, das in einem langen, verschlungenen und zunehmend ärgerlichen Austausch zur Sprache kam.

Es ist interessant festzustellen, dass das Problem nicht unbedingt gelöst werden kann, wenn man es in einen umfassenderen Kontext stellt. Und tatsächlich ist zu beobachten, dass das Dokument mehr Fragen aufwirft als es Antworten liefert (mit Ausnahme der Möglichkeiten, das Problem zu umgehen).

* Verwirrenderweise hat dies nichts mit die konventionelle Bedeutung von „Sharding“ in der KI.

† Eigene, kräftige Hervorhebungen des Autors.

Erstveröffentlichung: Montag, 12. Mai 2025