LLMs verlieren in Multi-Turn-Gesprächen den Faden

• Large Language Models (LLMs) zeigen in Multi-Turn-Gesprächen einen Leistungsabfall und eine geringere Zuverlässigkeit
• Im Vergleich zu Single-Turn-Situationen wurde experimentell ein durchschnittlicher Leistungsrückgang von 39 % in Multi-Turn-Szenarien bestätigt
• Die Hauptursachen sind ein kleiner Aptitude-Verlust und ein sehr starker Zuverlässigkeitsverlust, also mangelnde Konsistenz der Ergebnisse
• LLMs neigen dazu, frühzeitig falsche Annahmen zu treffen oder Endlösungen zu schnell zu versuchen
• Infolgedessen wurde beobachtet, dass LLMs, wenn sie zu Beginn eines Gesprächs einen Fehler machen, sich nicht mehr erholen und die Gesprächsrichtung verlieren

---

ABSTRACT

• Large Language Models (LLMs) haben als dialogorientierte Schnittstelle das Potenzial, Nutzer dabei zu unterstützen, Anforderungen durch Multi-Turn-Gespräche schrittweise zu definieren, zu erkunden und zu korrigieren, selbst wenn diese ihre Wünsche anfangs nicht vollständig spezifizieren können
• Obwohl sich die meisten LLM-Evaluationen auf Umgebungen mit vollständig spezifizierten Single-Turn-Anweisungen konzentrieren, zeigt die Analyse realer Gesprächslogs, dass Underspecification häufig auftritt
• Diese Studie vergleicht die Leistung von LLMs in Single-Turn- und Multi-Turn-Umgebungen (underspecified) mithilfe großskaliger Simulationen
• Das Ergebnis: Bei allen 15 führenden LLMs tritt in Multi-Turn-Gesprächen ein durchschnittlicher Leistungsabfall von 39 % auf, der auf einen leichten Aptitude-Rückgang und einen starken Einbruch der Zuverlässigkeit zurückgeführt wird
• Wenn LLMs früh im Gespräch einen falschen Pfad einschlagen, finden sie danach nicht mehr zurück und verlieren die Orientierung

Introduction

• Aktuelle LLMs (z. B. ChatGPT, Gemini, Claude usw.) sind Schnittstellen für Multi-Turn-Gespräche
• Auch wenn Nutzer nicht von Anfang an alle Anforderungen klar beschreiben, können diese durch wiederholte Frage-Antwort-Schritte (underspecified → refined) schrittweise konkretisiert werden
• Viele Nutzer formulieren zu Beginn eines Gesprächs tatsächlich unklare Anforderungen, dennoch werden die meisten Evaluationen nur in vollständig spezifizierten Single-Turn-Umgebungen durchgeführt
• Einige frühere Arbeiten versuchen Multi-Turn-Evaluationen, behandeln jedoch jede Gesprächsrunde oft als eigenständige Episode und unterschätzen dadurch den Einfluss der in realen menschlichen Gesprächen häufigen Unklarheit
• Um diese Lücke zu schließen, schlägt die Studie eine Umgebung namens sharded simulation vor, in der Informationen in mehrere Teile aufgeteilt und pro Turn jeweils nur ein Teil offengelegt wird, um Multi-Turn-Situationen mit unklaren Anweisungen präzise zu simulieren

Zusammenfassung der wichtigsten Forschungsergebnisse

• Wenn LLMs in einem Single Turn die vollständige Anweisung auf einmal erhalten, erreichen sie 90 % Leistung; bei underspecified Multi-Turn-Anweisungen sinkt diese auf 65 % (durchschnittlich 25 Prozentpunkte weniger)
• Dieses Phänomen tritt bereits nach nur zwei Gesprächsrunden (Turns) auf und wurde bei offenen, geschlossenen, großen und kleinen LLMs gleichermaßen beobachtet
• Die Ursachenanalyse des Leistungsabfalls zeigt: (1) ein Aptitude-Verlust und (2) ein starker Anstieg der Unzuverlässigkeit (unreliability)
  • In Single-Turn-Szenarien waren Modelle mit hoher Aptitude auch zuverlässig, in Multi-Turn-Szenarien ist die Zuverlässigkeit jedoch unabhängig von der Aptitude niedrig
  • Das heißt: Wenn ein LLM in einem Multi-Turn-Gespräch einmal in die falsche Richtung gerät, ist keine Erholung mehr möglich — dieses Phänomen wird als „lost in conversation“ bezeichnet
• Hauptursachen
  • Weitschweifige Antworten und vorschnelle Versuche einer Endlösung
  • Falsche Annahmen bei unklaren Informationen
  • Übermäßige Abhängigkeit von früheren Fehlversuchen
• Zwischen realem LLM-Einsatz und der Art, wie Modelle evaluiert werden, besteht eine große Lücke
  • Gerade Anfänger geben zu Beginn oft unvollständige Anweisungen, was dieses Phänomen zu einem der Hauptgründe macht, warum die praktische Anwendung erschwert wird
• Vorstellung des Paper-Aufbaus: Zusammenfassung früherer Arbeiten, Beschreibung der Simulationsumgebung, 6 generative Aufgaben und Evaluationsmetriken, großskalige Experimente mit 15 LLMs sowie Implikationen für Praxis und Produkteinsatz und konkrete Empfehlungen

Background and Related Work

• Sprachmodelle früherer Generationen (z. B. BART, GPT-2, T5) konnten in der Praxis keine Multi-Turn-Gespräche unterstützen und wurden daher vor allem im Single-Turn-Setting evaluiert
• Seit dem Aufkommen von ChatGPT ist das Interesse an Multi-Turn-Evaluationen gestiegen, und es wurden Crowdsourcing-basierte Bewertungen wie MT-bench durchgeführt
• Die meisten Evaluationssysteme bleiben jedoch bei episodischen Gesprächen (jede Runde wird separat bewertet), sodass die Kontinuität realer unklarer Gespräche nicht berücksichtigt wird
• In der Realität formulieren Menschen nach dem „Prinzip des geringsten Aufwands“ häufig unklare Anweisungen (auch bekannt als underspecification), und auch LLMs zeigen bei Informationsmangel Leistungsprobleme wie vorschnelles Ziehen von Schlussfolgerungen und mangelnde Anpassung
• Diese Studie zielt auf eine Evaluation, die einer realen Umgebung näherkommt, in der Unklarheit ein zentraler Faktor ist

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

• Die ursprüngliche vollständig spezifizierte Anweisung wird in mehrere Shards (Informationsfragmente) aufgeteilt
  • Beispiel: Statt alle Bedingungen in einen Satz zu packen, wird pro Turn jeweils nur eine Information (Szenario, Zahlenwert, Bedingung usw.) offengelegt
• Der erste Shard beschreibt immer das übergeordnete Ziel der Anweisung, danach liefern weitere Shards pro Turn schrittweise zusätzliche Informationen (Kontext, Bedingungen usw.)
• Dieser Sharding-Prozess wurde durch Vorschläge und Verifikation mit einem LLM (GPT-4o) sowie manuelle Nachbearbeitung genutzt, um einen hochwertigen Datensatz mit Multi-Turn-Anweisungen aufzubauen
• Für jede Aufgabe wurden 90–120 sharded instructions erstellt (mit mehreren Stunden manueller Prüfung)

3.2 Simulating Sharded Conversations

• Die Gesprächssimulation verwendet drei Rollen: das zu evaluierende LLM (assistant), einen User-Simulator, der alle Shards kennt, sowie ein System zur Antwortklassifikation und Bewertung
• Erster Turn: Der User-Simulator übermittelt dem Assistant nur den ersten Shard → der Assistant antwortet → seine Strategie (Klärung, Nachfrage, Lösungsversuch usw.) wird klassifiziert und die Antwort extrahiert → anschließend wird die Korrektheit bewertet
• Nächster Turn: Aus den verbleibenden Shards wird jeweils nur einer zusätzlich offengelegt; dies wird wiederholt / der Assistant kann in jedem Turn frei antworten
• Gesprächsende: (1) wenn der Evaluator eine richtige Antwort feststellt oder (2) wenn keine weiteren Shards mehr verfügbar sind
• Der User-Simulator wurde mit einem LLM (GPT-4o-mini) umgesetzt und kann Shards natürlich präsentieren sowie automatisch umformulieren
• Über das gesamte Experiment hinweg lagen Fehlklassifikationen und Extraktionsfehler der Hilfs-LLMs unter 5 %, Fälle zum Nachteil des Assistants unter 2 %
• Der Assistant wurde ohne spezielle Informationen über diese Umgebung im Default-Zustand evaluiert (ähnlich wie im Praxiseinsatz, ohne zusätzliche Szenariohinweise)

3.3 Simulation Types

• FULLY-SPECIFIED (FULL): vollständige Anweisung in einem Single Turn, zur Bestimmung der Baseline-Leistung
• SHARDED: pro Turn wird nur ein Informationsfragment offengelegt; das ist das Kerndesign der Studie für underspecified Multi-Turn-Gespräche
• CONCAT: die gesamte sharded instruction wird auf einmal als Bullet-Point-Liste gegeben, um nur den Informationsverlust der Anweisung zu bewerten
• RECAP: nach dem sharded Gespräch werden am Ende alle Shards zusammengefasst bzw. erneut bereitgestellt; eine einfache Form agentähnlicher Intervention
• SNOWBALL: bei jedem Turn wird zusätzlich zum neuen Shard die gesamte bisher offengelegte Shard-Historie wiederholt, damit der Assistant keine Informationen übersieht; ein Experiment zur Gedächtnisverstärkung

Task and Metric Selection

4.1 Task Selection

• Insgesamt 6 Aufgaben: Programmierung (Code), Datenbanken (SQL-Generierung), API Function Calling (Actions), Mathematik (Math), Tabelle→Text (Data-to-Text), fragebasierte Zusammenfassung (Summary)
  • Beispiele: Schreiben einer Python-Funktion, Umwandlung einer natürlichsprachlichen Anfrage in eine SQL-Abfrage usw.
• Für jede Aufgabe wurden 90 bis 120 Anweisungen aus hochwertigen Benchmarks ausgewählt, nach dem Sharding manuell geprüft
• Alle 6 Aufgaben sind repräsentativ für Programmier- und Nicht-Programmierfälle und umfassen verschiedene Szenarien, darunter auch Summary-Aufgaben mit Anforderungen an langen Kontext

4.2 Metric Selection

• Evaluationsmetriken
  • Durchschnittliche Leistung (P): mittlere Punktzahl aus mehreren Simulationen (0–100)
  • Aptitude (A90): Wert der besten 10 % der Simulationsergebnisse (90th percentile, Best-Case)
  • Zuverlässigkeit (U90_10): Differenz zwischen den oberen 90 % und unteren 10 % der Punktzahlen (misst Konsistenz/Varianz der Ergebnisse)
• Beispiel: In einem Boxplot entspricht der obere Rand der Aptitude, die Spannweite zwischen oben und unten der Zuverlässigkeit
• Für alle 6 Aufgaben wurden die Punktzahlen mit konsistenten Metriken aggregiert (Korrektheit/Ähnlichkeit/BLEU usw.)
• Detaillierte Methoden, Code, Beispiele und Sampling-Setups für alle Experimente sind ebenfalls im Appendix enthalten

Simulation Scale and Parameters

• Insgesamt wurden 600 instructions über 6 Aufgaben hinweg aufgebaut und in den Szenarien FULL/CONCAT/SHARDED getestet
• Für 15 LLMs (GPT-4, Claude, Gemini usw.) wurden pro Kombination jeweils 10 Simulationen durchgeführt; so entstanden mehr als 200.000 Experimentdatenpunkte
• Alle Experimente wurden mit Temperature 1 (Sampling) durchgeführt; in zusätzlichen Experimenten (7.2) wurde auch der Effekt der Temperature analysiert
• Mit diesem großen Simulationsdatensatz lassen sich die Hauptursachen und Muster des Verhaltens sowie des Leistungsabfalls von LLMs in underspecified Multi-Turn-Gesprächen identifizieren

Lost in Conversation Experiment

• Im weiteren Verlauf des Papers werden ausführlich das Experiment-Setup, Ergebnisse einzelner Modelle, Analysen der Ursachen des Leistungsabfalls, Versuche mit Gegenmaßnahmen (RECAP/SNOWBALL) sowie praktische Implikationen und konkrete Empfehlungen beschrieben

[GN⁺]

Hacker-News-Kommentare

• Es freut mich, eine Arbeit zu sehen, die etwas bestätigt, das jeder, der tatsächlich mit LLM-Tools gearbeitet hat, empirisch bereits weiß. Das Konzept des „Gesprächs“ ist ein Konstrukt der Produktoberfläche. Es ist wichtig, den Kontext sauber zu halten. Wenn der Kontext verunreinigt ist, lässt er sich nicht wiederherstellen, daher muss man mit einem neuen Gespräch neu anfangen.

  • Meine Erfahrung ähnelt dieser Beobachtung ebenfalls, war aber in einigen Punkten etwas anders. Ich habe zwei Wochen lang mit Gemini ein IPSEC-Problem debuggt. Zunächst habe ich die IPSEC-Dokumentation von OPNsense und pfSense einlesen lassen und allgemeinen Kontext geliefert. Danach habe ich Konfigurationsinformationen geteilt und den Frage-und-Antwort-Austausch fortgesetzt. Gegen Ende wurde das LLM weniger zerstreut, und manchmal habe ich Forenbeiträge oder Stack-Overflow-Posts eingefügt, worauf das LLM anmerkte: „Das unterscheidet sich von dem, was wir hier gerade sehen.“ Ich habe alle Sackgassen logisch ausgeschlossen, und das LLM half bei der Reflexion, aber die Entscheidungen musste der Mensch treffen. Am Ende fand ich die Ursache des Problems, und wie andere Nutzer sagen, liegt die Stärke von LLMs darin, komplexe Informationen zu vereinfachen, nicht darin, einfache Konzepte zu komplexen Konstrukten aufzublähen. Ich bin zufriedener mit den Ergebnissen, wenn die Eingabe komplexer oder länger ist als die Ausgabe. Ich hätte es auch ohne LLM schaffen können, aber nützlich war, dass es Dinge speicherte, an die ich mich kontextuell nicht mehr erinnerte oder die ich nicht schnell reproduzieren konnte. Es half auch dabei, Zeitmuster in großen Logmengen zu finden. Ich habe außerdem mehrere Konfigurationen verbessert. Ich habe nicht nur das Problem gelöst, sondern auch viel gelernt. Die Lageeinschätzung war manchmal falsch, ließ sich aber leicht direkt korrigieren. Mit anderen Worten: Wenn man das Ziel kennt und es als Werkzeug nutzt, ist es nützlich; wenn man ihm die Entscheidungen überlässt oder sich in eine falsche Richtung ziehen lässt, bringt es nichts. Ich habe 350.000 Tokens (etwa 300.000 Wörter) verbraucht. Es gibt dazu einen Blogpost. Empfehlungen für WireGuard sind nicht nötig.
  • Meine Erfahrung stimmt vollständig damit überein. „Verunreinigt“ ist genau das richtige Wort. Wenn etwas schiefläuft, werden danach alle Antworten schlechter. Deshalb mag ich die Memory-Funktion von ChatGPT nicht. Es ist kein großes Problem, aber es beunruhigt mich, dass ich nicht vollständig verstehe, wie Kontextverunreinigung entsteht.
  • Mein bester Tipp ist, den sehr kleinen, versteckten „Bearbeiten“-Button in ChatGPT und Claude aktiv zu nutzen. Wenn eine schlechte Antwort kommt, geh nicht einfach weiter, sondern halte an, korrigiere und hole dir dann eine bessere Antwort. Sonst vervielfältigt sich das Chaos immer weiter.
  • Ich habe immer den Wunsch, Gespräche zu forken und verschiedene Richtungen auszuprobieren. Ich möchte verhindern, dass ein vielversprechender Verlauf irreversibel verunreinigt wird. In ChatGPT kann ich diese Funktion nicht nutzen, daher frage ich mich, ob es einen Dienst gibt, der das anbietet.
  • Ein interessantes Beispiel für dieses Problem ist der initiale Prompt. Er ist praktisch permanenter und versteckter Kontext. Der Grok-Bot auf Twitter erwähnt in letzter Zeit häufig „White Genocide“, weil jemand offenbar den Prompt so geändert hat, dass er zu diesem Thema passt. Ein perfekter Chatbot dürfte davon bei anderen Themen nicht beeinflusst werden, in der Praxis wird er es aber. Letztlich hat sich der Kontext verändert, und er fixiert sich ständig auf dieses Thema.
  • Deshalb habe ich FileKitty gebaut. Es ist ein Tool, das mehrere Quellcode-Dateien schnell in ein Markdown-Format zusammenführt. Wenn man sich bei der Unterstützung der Softwareentwicklung mit LLMs auf das Durchsuchen der Codebasis durch das LLM verlässt, steigt die Fehlerwahrscheinlichkeit. Durch den Verlust bei der Kontextkompression werden Ergebnisse auch verwässert. Die besten Resultate bekommt man, wenn man von Anfang an einen bestimmten Kontext klar setzt und ihn während des Gesprächs zwischendurch aktualisiert. Trotzdem muss man auf die Gesprächslänge achten. Es gibt auch Prompts, die den Kontext gut einfangen und in eine neue Sitzung übertragen. Man kann Dateien auswählen, die enthalten sein sollen, und sie in den neuen Prompt einfügen. Verwandte Diskussionen finden sich auch in anderen HN-Threads.
  • Dieses Muster ist inzwischen Teil meines Workflows geworden. Manchmal bitte ich das LLM: „Guter Fortschritt, ich möchte zum nächsten Schritt übergehen — lohnt es sich, in diesem Gespräch weiterzumachen, oder sollte ich neu anfangen?“ Wenn das Modell meint, ein Neustart sei besser, bereitet es einen guten Zusammenfassungs-Prompt vor, und manchmal antwortet es auch, dass man weitermachen könne. Ich habe mehrere Notizen mit dem Titel „Anfangsmenge für weitere Erkundung“ angelegt. RL-basiertes Post-Training und ähnliche Prozesse begünstigen, dass Chatbots das Gespräch einfach weiterführen wollen. Beim RL-basierten Post-Training wird im Gegensatz zu echtem RL nur ein einmaliger präferenzbasierter Mechanismus verwendet. Zu langfristigen Präferenzen oder Gesprächen gibt es wenig Forschung, weil die Rechenkomplexität exponentiell steigt.
  • Ich frage mich, ob es Beispiele für eine Oberfläche gibt, die den Gesprächsverlauf „aufräumt“. Also eine Funktion, die Sackgassen oder irrelevante Inhalte innerhalb eines Gesprächs bereinigt. Die gesamte Historie bleibt erhalten, aber unnötige Teile werden je nach Themenpfad beschnitten oder geordnet. Eher organisch geordnet als bloß zusammengefasst.
  • Ich nutze LLMs nur zur Autovervollständigung, aber ich denke, dieses Problem ließe sich lösen, wenn Chat-UIs für LLMs einen Button oder eine Option zum „Nachrichten löschen“ hätten. Wenn man die letzte LLM-Nachricht löscht, kann man eine neue Antwort erhalten. Besonders nützlich bei LLMs mit hoher Zufälligkeit (temperature). Wenn andere Nachrichten gelöscht werden, sollte der Kontext aktualisiert werden, damit spätere Antworten dies berücksichtigen. So ließe sich auch die Illusion korrigieren, das LLM sei intelligent. Ich weiß nicht, ob das schon Standard ist. Falls nicht, stelle ich die Idee in die Public Domain. Andererseits wäre auch ein „Subkontext-LLM“ praktisch, das den Hauptkontext verwaltet. Wenn Antworten zu lang oder zu umfangreich werden, könnte ein untergeordnetes LLM sie zusammenfassen oder ordnen und so den Kontext des gesamten Gesprächs glätten. Oder man hat einfach einen „Nachricht bearbeiten“-Button, damit Menschen selbst aufräumen können.
  • Wenn der Kontext verunreinigt ist, ist Erholung schwierig. Es könnte helfen, wenn man bestimmte Teile des LLM regelmäßig zurücksetzen oder bereinigen könnte. Die Herausforderung ist allerdings, welche Teile man ordnet, ohne Kerninformationen zu verlieren. Ein intelligenteres Kontextmanagement könnte helfen, in langen Gesprächen Konsistenz zu bewahren, aber das Gleichgewicht ist schwierig. Vielleicht könnte ein anderer Agent das automatisieren.
  • Aus demselben Grund zeigen auch chain-of-thought-Prompts in AI-Chatbots ihre Grenzen.
  • Zur Aussage, „Gespräch“ sei nur ein Produkt der Produktoberfläche: Durch das Training auf RL-Multiturn-Evaluationsdatensätzen hat sich dieser Verlauf etwas verändert. Das Kontextfenster ist zwar jedes Mal neu, aber die Tendenz nimmt zu, jeden Prompt als Teil eines längeren Gesprächs zu interpretieren. Öffentlich ist Multiturn-Post-Training noch nicht stark skaliert, aber langfristig wird es wohl eingeführt werden, um mehr Ziele zu erreichen.
  • Auch beim Programmieren starte ich häufig ohne Gespräch ein neues Chatfenster und erkläre den aktuellen Code erneut. Das führt oft zu besseren Ergebnissen, als in einem einzelnen Gespräch immer weiter darauf einzuhämmern. Vielleicht ließe sich das Problem lösen, wenn man dem Modell per manuellem Befehl Zusammenfassung und Vergessen explizit macht. Das passt teilweise auch zum menschlichen Funktionsmechanismus (Arbeitsgedächtnis vs. narratives/episodisches Gedächtnis).
  • Eine der frustrierendsten Funktionen von ChatGPT ist „Memory“. Gesprächsverunreinigung kann sich so sogar über Chats hinweg fortsetzen.
  • „Verunreinigt“ ist wirklich ein treffender Begriff. Ich wünschte, es gäbe in Gesprächen/API eine Art „Versionsverwaltung“, mit der man auf frühere Zustände zurückrollen oder in ein neues Gespräch klonen kann. Gerade weil schon Tippfehler oder nachträgliche Nachrichtenänderungen die späteren Antworten subtil verzerren können.
  • Ich mag die Chat-UX von zed sehr. Dort kann man den gesamten Gesprächsverlauf wie eine Textdatei bearbeiten und unerwünschte Teile bereinigen, löschen oder überarbeiten, bevor man mit viel saubererem und relevanterem Kontext weitermacht. Deshalb nutze ich zed auch außerhalb des Programmierens als eine meiner Hauptoberflächen für LLM-Gespräche.
  • Verunreinigung entsteht auch durch abwegige Fragen oder Antworten oder durch wiederholte „Verwässerung“. Auch bei der Inhaltserzeugung erlebe ich oft, dass anfangs klare Anweisungen allmählich zerfasern.
  • Ich versuche immer im Kopf zu behalten, dass „Gespräch nur ein Produkt der Produktoberfläche ist“, aber in der Praxis ist das wegen vieler „gesprächsartiger“ Signale nicht leicht.
  • Ich habe es bereut, den Memory-Modus aktiviert zu haben. Gespräche werden mit nutzlosen Informationen verunreinigt.
  • Erstaunlich ist, wie früh sich Modelle auf falsche Annahmen festlegen und dann daran haften bleiben.
  • Wenn man an Menschen denkt, passiert so etwas dort eigentlich auch oft.
  • Jetzt, da ChatGPT über „Memory“ auch auf frühere Gespräche zugreifen kann, kann Verunreinigung dauerhaft werden. Wenn es einmal eine falsche Idee aufgegriffen hat, taucht sie aus Sicht des Nutzers immer wieder in Antworten auf, selbst wenn man mehrfach betont, dass sie nie wieder erwähnt werden soll. Es gab sogar absurde Fälle, in denen ein interner Prompt versehentlich ausgegeben wurde („Der Nutzer ist sehr unzufrieden, xyz muss weggelassen werden“) und dadurch am Ende xyz nur noch stärker betont wurde.

• Das ist ein Phänomen, das aus der bekannten Tendenz von LLMs zu Überconfidence, aus mangelnder Selbstreflexion und daraus entsteht, dass sie nicht erkennen, wann sie mehr Informationen anfordern sollten. Wenn man sich die Ergebnisse von Reasoning-Modellen ansieht, merkt man: In verwirrenden Fällen bitten LLMs nicht um zusätzliche Erklärungen, sondern raten einfach weiter, was der Nutzer gemeint haben könnte. Das zeigt die realistischen Grenzen der Idee, menschliche Programmierer zu ersetzen. Denn der wirklich schwierige Teil ist die „Interaktion mit Stakeholdern“, in der vage Anforderungen schrittweise präzisiert werden.

  • In Bezug auf die Unfähigkeit zur Selbstreflexion: Im LLM gibt es kein echtes Subjekt, und der Nutzer gerät in eine Art „belief-maintenance story“. Wenn man als Nutzerrolle in einem Filmskript Text eingibt, vervollständigt das LLM als Chatbot-Rolle im Grunde nur automatisch eine unvollständige Handlung. Zum Beispiel ahmt ein Interview mit einem Dracula-Bot Selbstreflexion nur oberflächlich nach, etwa als „nach Blut verlangen“ oder „zu einer Wolke aus Fledermäusen werden“.
  • Ich bin ebenso enttäuscht, dass LLMs in offenen Problemsituationen mit mehrdeutigen Informationen — besonders bei Paradoxien — nicht klar um zusätzliche Erläuterungen bitten können. Ich habe das mit DeepSeek-R1 und Claude-3.7-Sonnet getestet, und es gibt dazu auch einen Experiment-Blog.
  • Gemini 2.5 Pro und ChatGPT-o3 fragen vor der Ausführung einer Aufgabe oft nach zusätzlichen Informationen. Gemini nennt auch mehrere Optionen und fordert dann meine Eingabe an.
  • Echte Programmierer verbringen tatsächlich die meiste Zeit damit, Anforderungen präzise zu verstehen. LLMs behandeln bloßes Raten immer noch wie eine eigene Funktion.
  • Ironischerweise ist es bei Junior-Entwicklern oft ähnlich. Man gibt ihnen eine Aufgabe, und sie marschieren einfach geradeaus los, treffen Annahmen und stellen keine Fragen, bis sie so tief im Wald stecken, dass am Ende ein Rettungstrupp sie herausholen muss.
  • Ich denke, das ließe sich ziemlich leicht ändern. So wie chain-of-thought-Prompts den letzten Token in ein „hmm“ verwandeln, könnte man bei Äußerungen wie „vermutlich ist es wohl ...“ den Token stattdessen in „ich werde zuerst um zusätzliche Erläuterung bitten“ ändern.
  • Zusätzliche Informationen anzufordern oder Selbstreflexion zu zeigen können sie auf Anfrage durchaus gut genug.

• Ich nutze gern die Technik, das LLM die bisherige Diskussion in Form eines knappen Prompts zusammenfassen zu lassen, diesen dann selbst zu korrigieren und zu bearbeiten und damit ein neues Gespräch zu beginnen. Diese Methode war ziemlich effektiv, und ich denke, sie wird bald automatisiert werden.

  • Cursor hat das automatisch versucht, aber außer bei Modellen mit großem Kontext gingen in den Zusammenfassungen zu viele Details verloren, sodass es in der Praxis nicht besonders gut war.
  • Claude Code hat den Befehl /compact, der ein Gespräch zusammenfasst und den Token-Verbrauch reduziert.

• Ich habe TSCE (Two-Step Contextual Enrichment) selbst entwickelt. Beim Einsatz auf 300 Aufgaben mit GPT-35-turbo verbesserte sich die Leistung um +30 Prozentpunkte. Es ist als offenes Framework frei nutzbar. Ich habe außerdem 300 weitere Experimente mit gpt-4.1 gemacht. Der Baseline-Prompt scheiterte 149 von 300 Mal daran, em-dashes zu entfernen, TSCE nur 18 von 300 Mal. Der vollständige Datensatz und die Skripte sind ebenfalls veröffentlicht.

  • Für eine simple Find-and-Replace-Aufgabe wird Kilowattstunden an Energie verschwendet. Hast du schon mal so etwas wie text.replace("—", "-") ausprobiert?
  • Schon mit einer kleinen Änderung am Baseline-Prompt habe ich bei GPT-4.1 eine Erfolgsquote von 100 % erreicht. Ganz ohne zusätzliche Aufrufe, Token-Ausgaben oder komplexe Techniken.

• Ich habe Erfahrung damit, Probleme mit einem Zwei-System-Ansatz zu lösen (LMM + automatischer Kurator). Das eine ist das LLM selbst, das andere ein „Kurator des Denkens“, der Teile des Kontexts dynamisch austauscht und verwaltet. Das basiert nicht auf klaren Regeln, sondern auf der Fähigkeit des LLM, Lücken zu füllen. Es hilft dabei, Probleme in kleinere Teile zu zerlegen und zu bearbeiten, und diese Ergebnisse summieren sich zum Endziel.

  • Coole Idee. Was du gerade machst, wirkt ähnlich wie konversationelles RAG. In Zukunft wird die Trennung zwischen Gedächtnisebenen (Trainingsdaten / aktueller Kontext / RAG) wohl klarer werden.
  • Ich finde die Idee interessant. Wenn du sie auch nur in einfacher Form mit der Welt teilst, können viele Leute sie verbessern, und die Community kann sie selbst weiterentwickeln.
  • Das ähnelt dem internen Kritikersystem aus der Emotion Machine.
  • Es wäre schön, mehr über das Projekt zu erfahren, an dem du arbeitest. Klingt interessant.
  • Am Ende könnte man das also als Map-Reduce-of-Thought bezeichnen.

• Ich finde es erstaunlich, dass Branching/Forking in den wichtigsten Chat-Tools nicht Standard ist. Man kann Antworten zwar bearbeiten, aber dabei geht viel anderer Kontext verloren. Mein Workflow ist 1. Planen 2. Bauen 3. Branch 4. Wiederholen. Ich denke, Prompt-Beschneidung/Branching sollte ein zentrales Werkzeug für die Arbeit mit LLMs sein.

  • Google AI Studio hat diese Funktion zumindest. Die Umsetzung war aber verwirrend, und ich vermute, das ist auch ein Grund, warum sie sich nicht weiter verbreitet hat.
  • Ich wollte so etwas schon lange selbst bauen. BetterChatGPT hat zumindest eine gute Oberfläche zum Löschen der Historie, aber ich denke auch, dass Branching der nächste Schritt ist.

• Wenn LLM-Oberflächen primär für Single-Turn-Gespräche entworfen werden, entstehen Probleme. Die meisten Nutzer erwarten lineare Gespräche. Deshalb habe ich den Telegram-Bot experai_bot gebaut, um ihn als universelle UI für LLMs zu verwenden, mit dem Ansatz „Keine Antwort = neues Gespräch“. Um Kontext zu erhalten, muss man unbedingt in einer Antwortbaum-Struktur weitermachen. Nichtfachleute tun sich schwer damit, dieses Modell zu verstehen. Außerdem werden OpenAI-Modelle (zumindest 3.5 und 4o) umso ungenauer, je öfter dieselbe Frage wiederholt wird, wobei Leerraum oder Optionen immer weiter schrumpfen. Die Ergebnisse bleiben vergleichsweise stabil, wenn man Systemnachrichten minimiert. Falls nötig, kann man Systemnachrichten optional hinzufügen.

• Ich habe promptdown vor allem deshalb gebaut, um die komplette Chat-Historie in jedem Turn vollständig editierbar zu machen. Die append-only-Struktur der Standardoberflächen erschwert so etwas.

• Im aktuellen LLM-Bereich wirkt es so, als würden alle immer wieder dieselben Probleme lösen.

  • Genau wie LLMs in Multiturn-Gesprächen lösen alle immer wieder dasselbe Problem.
  • Es ist kein „Lernen“, sondern eher „Katzenhüten“, aber für manche Workflows passt das.
  • Alle wollen mit ihren eigenen Prompt-Engineering-Fähigkeiten glänzen.

• LLMs sind wirklich wie ein Genie in der Flasche. Drei Fragen beantworten sie dir, und danach reden sie nur noch Unsinn.