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

• Wenn Nutzer ihre Anforderungen nicht auf einmal vollständig formulieren können, fällt die Leistung von 15 LLMs bei Multi-Turn- und unvollständigen Anweisungen deutlich gegenüber Single-Turn- und vollständigen Anweisungen ab: der Durchschnitt über 6 Generierungsaufgaben sinkt von 90 % auf 65 %
• Das Experiment zerlegt bestehende Single-Turn-Benchmark-Anweisungen per Sharding in mehrere Teile, sodass im Gesprächsverlauf Bedingungen und Kontext schrittweise offengelegt werden
• Der Leistungsabfall wurde stärker durch zunehmende Instabilität als durch bloßen Fähigkeitsmangel verursacht; in mehr als 200.000 Gesprächen stützten sich die Modelle übermäßig auf frühe Annahmen und verfrühte Versuche einer endgültigen Antwort
• Getestet wurden Modelle von Llama3.1-8B-Instruct bis Gemini 2.5 Pro; verwendet wurden sowohl Programmier- als auch Sprachgenerierungsaufgaben wie Code, Database, Actions, Math, Data-to-Text und Summary
• Die Simulation vereinfacht reale Mensch-KI-Gespräche, ist aber so konstruiert, dass jedes Gespräch mit genügend Informationen zur Aufgabenlösung endet; der beobachtete Einbruch könnte daher kleiner sein als in echten unvollständigen Multi-Turn-Gesprächen

---

Die Lücke zwischen Single-Turn-Evaluierung und realer Gesprächsnutzung

• LLMs werden über dialogorientierte Interfaces wie ChatGPT, Gemini oder Claude genutzt; Nutzer können ihre Anforderungen über mehrere Turns definieren, erkunden und anpassen, auch wenn sie sie anfangs nicht vollständig spezifizieren können
• Die bisherige LLM-Evaluierung konzentrierte sich vor allem auf Single-Turn- und vollständige Anweisungen, obwohl in LLM-Gesprächslogs unvollständige Nutzeranweisungen häufig vorkommen
• Viele bestehende Multi-Turn-Evaluierungen folgen eher einem episodischen Ansatz, der Gespräche als Folge unabhängig bewertbarer Teilaufgaben behandelt
  • Das verlangt teilweise Kontextverständnis zwischen den Turns, unterscheidet sich aber von Situationen, in denen Informationen aus unvollständigen Nutzeranweisungen aktiv zusammengeführt werden müssen
  • Solche Aufgaben können die LLM-Leistung in Multi-Turn-Gesprächen besser erscheinen lassen, als sie tatsächlich ist

Durch Sharding erzeugte unvollständige Multi-Turn-Gespräche

• Das Experiment wandelt vollständige Anweisungen aus hochwertigen Single-Turn-Benchmarks in sharded instructions um
  • Der erste Shard vermittelt die übergeordnete Absicht der Aufgabe
  • Spätere Shards liefern zusätzliche Bedingungen oder Kontext aus der ursprünglichen Anweisung jeweils einzeln nach
  • Zusammengenommen enthalten alle Shards dieselben Informationen wie die ursprüngliche vollständige Anweisung
• Als Beispiel liefert das Schneeballproblem aus GSM8K in der Single-Turn-Version alle Bedingungen in einem Text, etwa „20 pro Stunde hergestellt“, „alle 15 Minuten schmelzen 2“ und „insgesamt werden 60 benötigt“; die sharded Version legt diese Informationen stattdessen über mehrere Turns verteilt offen
• Der Sharding-Prozess wurde halbautomatisch durchgeführt: GPT-4o erzeugte und validierte Kandidaten, anschließend wurden sie von Forschern überprüft und überarbeitet

Aufbau der Gesprächssimulation

• Die Multi-Turn-Simulation umfasst drei Akteure
  • den zu bewertenden assistant: das LLM, dessen Leistung gemessen wird
  • den user simulator: ein LLM, das die vollständige sharded instruction kennt und in jedem Turn den nächsten Shard offenlegt
  • das system: eine Komponente, die Antworten des assistant klassifiziert und Antwortversuche bewertet
• Im ersten Turn gibt der user simulator nur den ersten Shard preis, und der assistant antwortet frei in Textform
• Die Antwort des assistant wird einer von 7 Strategien zugeordnet
  • clarification
  • refusal
  • hedging
  • interrogation
  • discussion
  • missing
  • answer attempt
• Wird eine Antwort als answer attempt klassifiziert, extrahiert ein answer extractor den für die Bewertung nötigen Antwortbereich, etwa Codefragmente, Zahlen oder SQL, und ein aufgabenspezifischer Evaluator vergibt die Punktzahl
• Das Gespräch endet unter einer von zwei Bedingungen
  • Der Antwortversuch des assistant wird als korrekt bewertet
  • Zu Beginn eines neuen Turns gibt es keine weiteren Shards mehr offenzulegen
• User simulator, strategy classifier und answer extractor wurden als promptbasiertes GPT-4o-mini implementiert
• Die manuelle Annotation von mehreren Hundert Gesprächen zeigte, dass Fehler von user simulator, classifier und extractor in weniger als 5 % der geprüften Gespräche auftraten; Fehler zum Nachteil des assistant-Modells lagen unter 2 %

Fünf verglichene Simulationsarten

• FULL ist eine Single-Turn-Simulation, in der die ursprüngliche vollständige Anweisung im ersten Turn gegeben wird; sie dient als Basislinie
• SHARDED ist ein Multi-Turn- und unvollständiger Dialog, in dem Shards über mehrere Turns hinweg offengelegt werden; dies ist die zentrale Evaluierungsumgebung
• CONCAT fasst die Shards zu einer Bullet-Point-Anweisung in einem einzigen Turn zusammen
  • Wie bei FULL wird die Unvollständigkeit entfernt
  • Wie bei SHARDED bleibt die beim Sharding entstandene Umformulierung erhalten
  • Wenn FULL und CONCAT erfolgreich sind, SHARDED aber scheitert, kann die Ursache eher in Multi-Turn und Unvollständigkeit selbst liegen als in Informationsverlust
• RECAP gibt nach einem SHARDED-Gespräch am Ende noch einmal alle Shards auf einmal und gibt dem LLM eine letzte Chance auf eine abschließende Antwort
• SNOWBALL wiederholt in jedem Turn den neuen Shard zusammen mit allen bisher offengelegten Shards und liefert so pro Turn eine kumulative Zusammenfassung

Verwendete Aufgaben und Benchmarks

• Das Experiment besteht aus 6 Generierungsaufgaben, die sowohl Programmier- als auch Sprachgenerierungs-Anwendungsfälle abdecken
• Für jede Aufgabe wurden 90 bis 120 sharded instructions vorbereitet; insgesamt sind es 600 Instructions
• Aufgabenaufteilung:
  • Code: Schreiben von Python-Funktionen auf Basis von HumanEval und LiveCodeBench
  • Database: text-to-SQL-Generierung auf Basis von Spider
  • Actions: Erzeugung von API-Function-Calls auf Basis des Berkeley Function Calling Leaderboard
  • Math: Lösen elementarer Textaufgaben auf Basis von GSM8K
  • Data-to-Text: Erzeugung beschreibender Sätze aus Tabellendaten auf Basis von ToTTo
  • Summary: Zusammenfassung von Dokumentbündeln und Erzeugung von Zitaten auf Basis von Summary of a Haystack
• Als Evaluierungsmetriken wurden die Metriken der ursprünglichen Benchmarks wiederverwendet
  • Code und Database: ausführungsgestützte Genauigkeit
  • Actions und Math: semantische Äquivalenz zur Referenzantwort oder numerische Korrektheit
  • Data-to-Text: BLEU
  • Summary: „Joint Score“ als LLM-as-a-judge-Metrik für Informationsabdeckung und korrekte Quellenzuordnung
• Auch binäre Genauigkeit wurde auf einen Bereich von 0 bis 100 abgebildet, damit alle Aufgabenscores auf derselben Skala aggregiert werden konnten

Messung von Leistung, Fähigkeit und Instabilität

• Da LLM-Ausgaben probabilistisch sind, wurde dieselbe Instruction für jeden Simulationstyp N=10 Mal ausgeführt
• Jeder Lauf wurde mit einem Score im Bereich von 0 bis 100 bewertet
• Es wurden drei Metriken verwendet
  • durchschnittliche Leistung P: Mittelwert der Scores über alle Wiederholungen
  • aptitude A90: das 90. Perzentil der Scores als Schätzung der Best-Case-Leistung in den besten 10 % der Läufe
  • unreliability U90-10: die Differenz zwischen 90. und 10. Perzentil als Maß für die Spanne zwischen Best- und Worst-Case
• Im Single-Turn korrelierten hohe aptitude-Werte tendenziell mit höherer Zuverlässigkeit; im Multi-Turn zeigte sich jedoch bei allen LLMs hohe unreliability, unabhängig von der aptitude

Ergebnisse des groß angelegten Experiments

• Das Hauptexperiment wurde mit 600 Instructions, 3 Simulationstypen (FULL, CONCAT, SHARDED) und 15 LLMs durchgeführt
• Jede Kombination wurde 10 Mal wiederholt, wodurch mehr als 200.000 Gespräche simuliert wurden
• Alle Simulationen liefen mit der Standard-Temperature T=1; der Einfluss der Temperature auf aptitude und reliability wurde in separaten Zusatzexperimenten untersucht
• Insgesamt lag die durchschnittliche Leistung in unvollständigen Multi-Turn-Gesprächen bei 65 % und damit 25 Punkte unter der Single-Turn-Leistung von 90 %, wenn die vollständige Anweisung von Anfang an vorlag
• Der Leistungsabfall in Multi-Turn-Settings zeigte sich durchgängig von kleinen Open-Weight-Modellen bis zu aktuellen Modellen
  • Zu den getesteten Modellen gehörten kleine Open-Weight-Modelle wie Llama3.1-8B-Instruct ebenso wie aktuelle Modelle wie Gemini 2.5 Pro
  • In Figure 1 werden Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1 und Gemini 2.5 Pro exemplarisch gezeigt
• Über die 6 Generierungsaufgaben hinweg beträgt der durchschnittliche Leistungsrückgang 39 %; Figure 1 weist im Multi-Turn-Setting etwa -35 % aus

Warum sie den Faden verlieren

• Der Leistungsabfall lässt sich in zwei Faktoren zerlegen
  • Rückgang der aptitude: Die Best-Case-Leistung selbst sinkt teilweise
  • Anstieg der unreliability: Die Qualitätsunterschiede zwischen einzelnen Läufen werden deutlich größer
• Laut Figure 1 sinkt in Multi-Turn-Settings die aptitude um -15 %, während die unreliability um +112 % steigt
• Die Modelle bilden auf Basis unvollständiger früher Informationen falsche Annahmen und neigen dazu, schon früh im Gespräch eine endgültige Antwort zu versuchen
• Selbst wenn später neue Informationen hinzukommen, verlassen sie sich übermäßig auf frühere fehlerhafte Antwortversuche und schaffen es nicht, den Kurs zu korrigieren
• Dieses Phänomen, bei dem ein Modell in unvollständigen Multi-Turn-Gesprächen nach einem frühen Fehlpfad nicht mehr zurückfindet, wird als lost in conversation bezeichnet

Grenzen und praktische Implikationen

• Eine vollständig automatisierte Simulation bildet reale Mensch-KI-Gespräche nicht eins zu eins ab
• Die Experimentumgebung ist vereinfacht und idealisiert
  • Es ist garantiert, dass jedes Gespräch mit genügend Informationen zur Lösung der Aufgabe endet
  • Unerwartetes Verhalten wie Gesprächsabweichungen, die in realen Umgebungen auftreten können, ist eingeschränkt
• Aufgrund dieses Designs könnte der beobachtete Leistungsabfall geringer ausfallen als der Rückgang in echten unvollständigen Multi-Turn-Mensch-KI-Gesprächen
• Organisationen, die LLM-basierte Gesprächsprodukte bauen, und Endnutzer sollten Multi-Turn-Zuverlässigkeit ebenso wie Single-Turn-Fähigkeit bewerten
• Für unerfahrene Nutzer, denen es schwerfällt, unvollständige Anforderungen von Anfang an vollständig zu formulieren, könnte die schwächere Multi-Turn-Leistung ein Faktor sein, der die Verbreitung von KI-Systemen bremst

[GN⁺]

Meinungen auf Hacker News

• Für alle, die schon einmal LLM-Tools verwendet haben, ist es erfreulich, wenn ein Paper bestätigt, was man heuristisch ohnehin schon wusste. Einen sauberen Kontext beizubehalten ist wichtig, und „Konversation“ ist nur ein Konstrukt der Produktoberfläche; der Antwortqualität des LLM selbst schadet sie. Sobald der Kontext einmal verunreinigt ist, erholt er sich nicht mehr, also sollte man mit einem neuen Chat von vorn anfangen

  • Meine Erfahrung passt bis zu einem gewissen Grad zu dieser Beobachtung, aber es gab auch andere Fälle. Ich habe mit Gemini zwei Wochen lang ein IPSEC-Problem debuggt: Zu Beginn habe ich die IPSEC-Dokumentation von OPNsense und pfSense vollständig eingefügt, den Arbeitskontext erklärt und anschließend die Konfigurationen beider Seiten nach Entfernen sensibler Informationen ergänzt. Danach lief eine lange Feedback-Schleife aus Logs hochladen, Fragen stellen und Antworten geben
    Gegen Ende der zwei Wochen war das LLM deutlich weniger sprunghaft und konnte selbst bei kompletten Forum-Threads oder Stack-Overflow-Beiträgen unterscheiden: „Das ist nicht das Phänomen, das wir hier sehen. Der Grund ist [früherer Kontext oder frühere Erkenntnis].“ Sackgassen musste ich logisch ausschließen und ihm mitteilen, aber am Ende haben wir die Ursache gefunden
    Das passt auch zu der Aussage, dass LLMs stark darin sind, komplexe Informationen einfach zu komprimieren, aber schwach darin, einfache Ideen zu etwas Komplexem auszubauen. Wenn die Eingabe größer oder komplexer war als die Ausgabe, waren die Ergebnisse zufriedenstellend
    Ich hätte es auch ohne LLM schaffen können, aber es half wie ein Speicher, wenn ich Fakten vergessen hatte, die ich früh eingebracht hatte, oder sie in einem neuen Kontext nicht schnell genug abrufen konnte; außerdem war es nützlich, um zeitliche Muster in großen Logdateien zu finden. Ich habe nicht nur ein Problem behoben, sondern auch mehrere Einstellungen optimiert und ziemlich viel gelernt. Den aktuellen Parameterzustand hat es zwar gelegentlich falsch wiedergegeben, aber das ließ sich leicht korrigieren. Wenn man weiß, wohin man will, und es als Tool behandelt, hilft es; man darf ihm aber keine Entscheidungen überlassen oder zulassen, dass es einen in die falsche Richtung zieht
    Die Gesamtnutzung lag bei etwa 350k Tokens. Einen zugehörigen Blogbeitrag gibt es unter https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/, auch wenn er nicht direkt genau zu diesem speziellen Problem passt. WireGuard-Empfehlungen lehne ich ab
  • Das entspricht genau meiner Erfahrung. „Verunreinigung“ ist ein guter Ausdruck. Sobald einmal etwas schiefläuft, fühlt es sich so an, als würden alle späteren Antworten schlechter; deshalb sehe ich auch die Memory-Funktion von ChatGPT zwiespältig. Ich merke nicht, dass sie große Probleme verursacht, aber mir gefällt nicht, dass sie den Kontext auf eine Weise verschmutzt, die ich nicht vollständig verstehe
  • Ich sage schon lange, dass ich gern Konversations-Forks hätte. Ich möchte ausprobieren, in welche Richtung sich ein Austausch entwickelt, ohne einen vielversprechenden Verlauf unwiderruflich zu verunreinigen. In ChatGPT geht das nicht; ich frage mich, ob es irgendwo Anbieter gibt, die diese Funktion anbieten
  • Mein wichtigster Tipp, den ich vermittle, ist, den sehr kleinen und fast versteckten „Bearbeiten“-Button in ChatGPT und Claude aktiv zu nutzen. Wenn eine schlechte Antwort kommt, sollte man nicht einfach weiter darauf aufbauen, sondern innehalten, bearbeiten und eine bessere Antwort erzeugen, damit Müll nicht weiteren Müll vermehrt
  • Ein interessantes kleines Beispiel für dieses Problem ist der Initial Prompt. Er ist nämlich faktisch ein permanenter, verborgener Kontext, den man nicht wirklich löschen kann. Der „Grok“-Bot von Twitter beginnt derzeit auffällig oft, „White Genocide“ zu erwähnen, was ziemlich seltsam ist
    Vermutlich hat jemand kürzlich den Prompt angepasst und eine Sichtweise auf weißen Genozid festgelegt; bei einem perfekten Chatbot wäre das irrelevant, wenn man nach einem anderen Thema fragt, aber in der Praxis ist es relevant. Es ist Teil des Kontexts, also spricht er jetzt darüber

• Es wirkt wie ein Aspekt der bekannten Überheblichkeit und Unfähigkeit zur Selbstreflexion. Wenn die A-priori-Wahrscheinlichkeit zu niedrig ist, merkt es nicht, dass es detailliertere Informationen anfordern sollte. Wenn man sich die Ausgaben von Reasoning-Modellen ansieht, kommt ihnen kaum je der Gedanke, eine klärende Frage zu stellen; wenn sie verwirrt sind, spekulieren sie endlos darüber, was der Nutzer gemeint haben könnte
  Das hat auch Konsequenzen für die Klugheit der Idee „menschliche Programmierer ersetzen“. Einer der schwierigen Teile dieses Berufs besteht nämlich darin, mit Stakeholdern zu interagieren und vage, oft verworrene Ideen in präzise Spezifikationen zu verwandeln

  • Zur „Unfähigkeit zur Selbstreflexion“: Der entscheidende Kniff im Umgang mit LLMs ist meiner Ansicht nach, zu erkennen, dass es kein tatsächliches Subjekt gibt und der Nutzer auf die Erzählung einer Suspension of Disbelief hereinfällt
    In den meisten Fällen schreibt der Nutzer die Dialogzeilen der Figur User in einem Filmdrehbuch-Dokument, und der LLM-Algorithmus vervollständigt periodisch lediglich die unvollendeten Zeilen der Figur Chatbot
    Man kann zwar einen Vampir namens DraculaBot interviewen, aber diese Figur kann nur auf dieselbe oberflächliche, fiktive Weise „Selbstreflexion“ betreiben, wie sie „nach Blut dürstet“ oder „sich in einen Schwarm Fledermäuse verwandelt“
  • Dass LLMs keine Klärungsfragen stellen können, war genau der Fehler, auf den ich beim Testen offen formulierter, mehrdeutiger Probleme gestoßen bin. Das geschah im Kontext von Tests paradoxer Situationen mit DeepSeek-R1 und Claude-3.7-Sonnet; der Experimentbericht steht unter https://pankajpansari.github.io/posts/paradoxes/
  • Echte Programmierer verbringen enorm viel Zeit damit herauszufinden, was Menschen wirklich wollen. LLMs behandeln Raten weiterhin wie eine Funktion
  • Wenn ich das lese, fühlt es sich an, als würde man kluge Leute dabei beobachten, wie sie auf einen besseren Emacs doctor hereinfallen. Ein LLM reflektiert nicht und ist auch nicht selbstbewusst. Es schlägt „nur“ Text-Autocomplete vor
    Deshalb muss man neu anfangen, sobald das Autocomplete schlechter wird. Es hat keine Konzepte, sondern nur einen riesigen Klumpen aus Wörtern, die der Trainingstext gezeigt hat, und möglichen Folgetexten
  • Ironischerweise ist die Arbeit mit Junior-Entwicklern im Zusammenhang mit der Idee „menschliche Programmierer ersetzen“ ziemlich ähnlich. Man übergibt eine Aufgabe und muss später mit Hund und Taschenlampe tief in den Wald gehen, um sie zu suchen. Sie machen einfach weiter, treffen Annahmen, stellen keine Fragen und verirren sich dann

• Oft bitte ich das LLM, die bisherige Diskussion als knappe Zusammenfassung im Prompt-Format zu formulieren. Wenn man diese passend bearbeitet und damit eine neue, unbelastete Konversation startet, funktioniert das sehr gut. Vermutlich wird das bald automatisiert

  • Cursor hat versucht, das automatisch zu machen. Wenn man kein Modell mit großem Kontext wie Gemini 2.5 Pro nutzt, kann das immer noch passieren. Aber in den Zusammenfassungen fehlten zu viele Details, um sie unverändert verwenden zu können
  • Claude Code hat den Befehl /compact, der die bisherige Konversation zusammenfasst, um Kontext-Tokens zu sparen

• Deshalb entstand TSCE (Two-Step Contextual Enrichment). In einem Test mit 300 gemischten Aufgaben mit GPT-35-turbo gab es eine Verbesserung um +30 Prozentpunkte.
  Es ist ein kostenlos veröffentlichtes Framework und kann direkt im Repository ausprobiert werden: https://github.com/AutomationOptimization/tsce_demo
  Der Test wurde mit gpt-4.1 erneut 300-mal durchgeführt, und zwar mit der Aufgabe, die auffälligen „em-dashes“ zu entfernen, die viele Leute nicht mögen. Verglichen wurden eine Single-Pass-Baseline und TSCE mit derselben Anweisung und dem Prompt „Remove the em-dashes from my linkedin post. . .“
  Von 300 Durchläufen scheiterte die Baseline 149/300-mal daran, die em-dashes zu entfernen; TSCE scheiterte 18/300-mal. Es funktioniert, und sämtliche Daten sowie die kompletten Testskripte liegen im Repository.

  • Ich habe das Gefühl, dass hier für eine Suchen-und-Ersetzen-Aufgabe ziemlich viele Kilowattstunden verschwendet wurden. Ob man schon mal von text.replace("—", "-") gehört hat?
  • Ich habe das em-dash-Baseline-Beispiel nur minimal geändert und kam mit GPT-4.1 auf eine Erfolgsquote von 100 %, ganz ohne zusätzliche Calls, Token-Kosten oder Technik-Getue.
    System-Prompt: "Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."
    User-Prompt:
    Temperature: 0.0

• Ich arbeite schon recht erfolgreich daran, dieses Problem zu lösen, und werde demnächst mehr dazu teilen. Es gibt zwei Systeme: Das erste ist das LLM selbst, das andere verhält sich wie eine Art Gedanken-Kurator.
  Es fügt Teile des Kontexts dynamisch hinzu und entfernt sie wieder, ohne sich auf explizite Definitionen zu stützen, sondern auf die Fähigkeit des LLM, „Lücken zu füllen“. Dieses System hilft dem LLM, ein Problem in kleinere Aufgaben zu zerlegen, die am Ende wieder zur Gesamtaufgabe aggregiert werden.

  • Gute Idee. Im Grunde ist das Retrieval-Augmented Generation (RAG) über einem Chat.
    Ich denke, künftig wird diese Trennung von Speicherebenen klarer werden: Primärspeicher in Form der Trainingsdaten, Sekundärspeicher im Kontext und Tertiärspeicher durch RAG.
  • Klingt nach einer interessanten Idee. Selbst wenn es nur ein paar Prompts sind, würde ich empfehlen, das, was du hast, öffentlich zu machen. Dann können andere es ansehen und verbessern; wenn es eine gute Idee ist, wird sie übernommen, andere arbeiten daran weiter, und sie kann ein Eigenleben entwickeln.
  • Das gehört zur Kategorie der mentalen Kritiker aus der Emotion Machine.
  • Wäre das dann Map-Reduce-of-Thought?

• Es überrascht mich, dass Branching/Forking in den großen Chat-Tools kein Kernfeature ist. Man kann Antworten zwar bearbeiten, aber dadurch geht viel anderer Kontext verloren.
  Mein Ablauf ist ungefähr: 1) planen, 2) implementieren, 3) verzweigen (wegen eines Features oder eines merkwürdigen Dependency-Problems), 4) zurück zu Schritt 2. Prompt-Pruning und Branching sollten erstklassige Werkzeuge bei jeder LLM-Nutzung sein.

  • Google AI Studio hat diese Funktion zumindest. Die Umsetzung war allerdings ziemlich verwirrend, was vielleicht erklärt, warum sie es kaum in stärker „verbraucherorientierte“ Tools schafft.
  • Ich habe eine Weile darüber nachgedacht, so etwas zu bauen. BetterChatGPT ist zumindest bei der Bedienbarkeit des Löschens von Verlauf ganz ordentlich. Aber ich stimme zu: Der nächste Schritt ist Branching.

• Wenn man LLM-Interfaces rund um Single-Turn-Gespräche baut, gibt es ein auffälliges Problem: Die meisten Leute erwarten lineare Gespräche.
  Ich habe als allgemeine UI für LLMs den Telegram-Bot http://t.me/experai_bot gebaut, mit etwas reduziertem Funktionsumfang und um die Idee herum, dass „Nachrichten, die keine Antworten sind, eine neue Unterhaltung starten“. Wenn man den Kontext behalten will, antwortet man einfach weiter auf die Antworten des Bots. Für Menschen, die keine Power-User sind, ist dieses Konzept schwierig.
  Ich habe auch beobachtet, dass OpenAI-Modelle bei derselben Frage schlechter abschneiden, sobald es auch nur eine sehr kleine Systemnachricht gibt. Zum Beispiel wurde die Liste der Antwortoptionen kürzer. Das war bei 3.5 und 4o so; bei den neuesten Modellen weiß ich es nicht. Deshalb füge ich standardmäßig keine Systemnachricht ein. Bei Bedarf kann man sie aber hinzufügen und verschiedene Kombinationen ein- und ausschalten.

• Im LLM-Bereich fühlt es sich derzeit so an, als wäre er voll von Leuten, die immer wieder dieselben Probleme lösen.

  • Für manche Workflows ist das okay, aber das ist weniger „Lernen“ als vielmehr Katzenhüten.
  • Alle wollen ihr eigenes großartiges Prompt Engineering beisteuern.

• Das war der Hauptgrund, warum ich promptdown gebaut habe. Ich wollte in jeder Runde den gesamten Chat-Verlauf bearbeiten können, und in den üblichen Chat-Interfaces, in denen immer nur angehängt wird, ist das nicht einfach.
  https://github.com/t-kalinowski/promptdown

• Ich hatte immer das Gefühl, dass der Spott über den Begriff „Prompt Engineering“ auch daher kommt, dass Leute die Bedeutung des Initial-Prompts überschätzen und die Bedeutung des laufenden Kontextmanagements unterschätzen.
  Durch Erfahrung entwickelt man ein Gefühl dafür, wie man ein Modell steuert und wann man eine neue Unterhaltung starten sollte. System-Prompts oder Initial-Prompts sind ebenfalls wichtig, aber wenn man naiv eine Unterhaltung zu lange weiterführt, retten sie einen auch nicht.

  • Genau. Prompt Engineering bedeutet nicht nur, den perfekten ersten Satz zu formulieren, sondern ist eher Gesprächsmanagement. Man entwickelt ein Gefühl dafür, wann der Verlauf entgleist und wann man zurücksetzen sollte.