Agents brauchen nicht mehr Prompts, sondern Kontrollfluss

• Agenten, die komplexe Aufgaben zuverlässig ausführen sollen, brauchen nicht ausgefeiltere Prompt-Ketten, sondern einen in Software codierten deterministischen Kontrollfluss
• Wenn man sich in Prompts auf Formulierungen wie MANDATORY oder DO NOT SKIP verlässt, hat man die Grenzen des Promptings erreicht
• Stellt man sich eine Programmiersprache vor, in der Sätze wie Vorschläge funktionieren und Funktionen halluzinieren und dabei „Success“ zurückgeben, dann wird mit wachsender Komplexität lokales Schlussfolgern unmöglich und die Zuverlässigkeit bricht zusammen
• Software skaliert durch rekursive Komposition aus Bibliotheken, Modulen und Funktionen und ermöglicht lokales Schlussfolgern, weil ihr Verhalten vorhersagbar ist
• Prompt-Ketten sind für eng umrissene Aufgaben nützlich, besitzen diese Eigenschaften aber nicht, weil sie nichtdeterministisch sind, nur schwache Spezifikationen haben und sich schwer verifizieren lassen

Die für die Zuverlässigkeit von Agenten nötige Struktur

• Um Zuverlässigkeit zu erreichen, muss man die Logik aus natürlichsprachlichen Beschreibungen herausnehmen und in die Runtime verlagern
• Die nötige Struktur ist ein deterministisches Scaffold, das das LLM nicht als Gesamtsystem, sondern als einen Baustein behandelt
• Dieses Scaffold muss explizite Zustandsübergänge und Prüf-Checkpoints enthalten
• Deterministische Orchestrierung allein reicht nicht aus; Systeme, die still scheitern können, brauchen aggressive Fehlererkennung
• Ohne programmatische Verifikation bleiben nur drei Optionen

  • Aufpasser (Babysitter)

    • Ein Mensch muss im Loop bleiben und Fehler abfangen, bevor sie sich ausbreiten

  • Prüfer (Auditor)

    • Nach Abschluss der Ausführung muss das Gesamtergebnis gründlich verifiziert werden

  • Gebet (Prayer)

    • Man verlässt sich darauf, das Ergebnis aus dem Bauchgefühl heraus zu akzeptieren

[GN⁺]

Hacker-News-Kommentare

• Stimme zu 1000 % zu. Es fällt mir zunehmend schwer, noch an das Trommelfeuer von Anthropic zu glauben: „Baut nach der Leistung zukünftiger Modelle, sie werden bald besser.“
  Ich habe in einer Browser-Session einen QA-Agenten gebaut, der 200 Anforderungs-Markdown-Dateien durchgeht; das war ein gutes System, das die Effizienz des Teams deutlich gesteigert hat. Aber sobald man dem Modell den High-Level-Kontrollfluss überlässt, etwa mit „Schau dir die Anforderungsdateien in diesem Verzeichnis an und erstelle für jede Datei To-do-Punkte, um zu prüfen, ob die App diese Anforderungen erfüllt“, ist es ab ungefähr 30 Dateien zusammengebrochen.
  Es hat Dateien ausgelassen, manche Dateigruppen dreimal getestet und damit aus 3 Minuten 10 gemacht, oder wegen eines Fehlers in einer Datei ohne erkennbaren Grund die vier vorherigen Dateien erneut getestet. Bei Opus 4.6 und GPT 5.4 sowie in kurzen Tests mit Opus 4.7 und GPT 5.5 war die Fähigkeit zur Workflow-Orchestrierung durchgehend inkonsistent.
  Am Ende habe ich um das Modell herum ein sehr einfaches deterministisches Harness gebaut, das für jeden Testfall das Modell aufruft, testet, das Ergebnis in einem Array speichert und anschließend in eine Datei schreibt, und die Zuverlässigkeit des Systems wurde überwältigend besser. Aber verwaltete Agentenplattformen wie Cursor Cloud Agents oder Anthropic scheinen zu sehr darauf fixiert zu sein, dass „der Agent alles ausführen muss“, um den Wert ein wenig Determinismus an den richtigen Stellen zu erkennen.

  • Früher dachte ich, sie drängen Leute in prompt-only Workflows, weil sie für Tokens Geld verlangen können, aber nicht für das Scaffolding, das die Nutzer selbst bauen. Inzwischen glaube ich eher, dass sie Angst davor haben, dass jemand dieses Scaffolding entwerfen und implementieren muss.
    Denn das würde den Behauptungen einen Dämpfer verpassen, dass diese Technologie ganze Personen, ganze Workflows oder ganze Projekte ersetzen könne. Ich denke, sie kann die Produktivität stark steigern und damit katastrophale Folgen für den Entwickler-Arbeitsmarkt und die Löhne haben, aber ich glaube nicht, dass die aktuelle Version dieser speziellen Technologie das Niveau erreicht, von dem sie sprechen. Hätte man sie als „sehr nützliches Werkzeug positioniert, das einen großen Teil der lästigen Arbeit menschlicher Entwicklerteams reduziert“, dann hätten Entwickler es gewollt, Führungskräfte eher weniger, und Investoren hätten es vermutlich nicht durchgehen lassen.
    Außerdem sind fein granulare, stark kontrollierte Schritte viel besser dafür geeignet, kleinere, billigere und spezialisierte Modelle anzuschließen, als ein riesiges Modell, das Testautomatisierung oder in Sekunden fünf Bände CSI-Fanfiction schreibt.
  • Das könnte sogar aus der Art der Benchmarks selbst entstehen, mit denen man Modelle bewertet.
    Bei manchen Benchmarks darf man ein Problem mehrfach versuchen, ignoriert dann die Fehlerrate und übernimmt einfach das Ergebnis, sobald einmal irgendetwas erfolgreich war, oder?
  • Stimme zu. Der einzige Weg, solche Systeme zuverlässig zu machen, ist, das Problem in kleine Stücke zu zerlegen. Interne Konsistenzprüfungen zeigen letztlich nur, dass LLMs viel weniger konsistent sind, als man erwartet.
  • Ich habe die Performance stark verbessert, nachdem ich bei einem Tool wie apply_patch check_compilation und run_unit_tests dazugenommen habe. Der Tool-Name ist immer noch apply_patch, aber wenn der Patch erfolgreich ist, liefert es jetzt zusätzlich Informationen zum Build und zu den Tests zurück.
    Die Erfolgsquote des Agenten ist von etwa 80 % auf etwas gestiegen, das bisher fast deterministisch wirkt. Ich muss den Kompilier- und Unit-Test-Prozess nicht mehr extra im Prompt erklären; es reicht, das Tool unter den entsprechenden Abhängigkeiten auszuführen und nur das Ergebnis zurückzugeben.
    Ich habe auch das Gefühl, mich vom aktuellen Hype zu entfernen. Ich nutze schon lange Prepaid-Tokens und ein Custom-Harness, und es funktioniert einfach gut. Die meisten News kann man ignorieren. Bei explizit angezielten Problemen sind Copilot-artige Tools nicht mehr wirklich nützlich, und in manchen Codebasen ist die Leistung auf einer völlig anderen Ebene, obwohl sie auf demselben GPT-5.4-basierten Modell beruhen.
  • Das Geheimnis ist, diesen Orchestrierungs-Prompt zu „kompilieren“. Wenn man den Prompt in Code verwandelt, kann dieser Code wiederum entweder den Agenten ausführen oder Code ausführen oder beides, und so löst sich das Problem der Deterministik.
    Alle übersehen dieses Muster bei Skills. Wenn man Code neben SKILL.md legt, kann man bestimmtes Verhalten garantieren, aber alle sind seltsam süchtig nach Prompting. Man muss nicht einmal eine CLI bauen; ein simples skill.py, das die Aufgabe enthält, reicht aus. Man kann auch einen Helper einbauen, der claude -p aufruft.

• Es wäre lustig, wenn die Leute auch in ein paar Jahren noch LLMs nutzen, aber am Ende nur über ein kontrolliertes Vokabular und eine kontrollierte Grammatik, die man erst lernen muss. So wie damals, als vor 15 Jahren alle auf NoSQL umgestiegen sind und kurz darauf wieder Schemas in JSON eingebaut haben.

• Ein Teil des Problems könnte sein, dass LLMs von Anfang an falsch eingesetzt wurden. Wie auch andernorts gesagt wurde, sollte der Prompt des Agenten vielleicht lauten: Schreibe Code, der die Aufgabe auf möglichst wiederholbare, überprüfbare und deterministische Weise ausführt.
  Dazu sollte auch die Validierung der Agentenausgabe gehören. Das Gesamtziel ist, LLMs aus Aufgaben herauszunehmen, die sich durch Programme effizienter und oft auch genauer erledigen lassen.

  • Stimme zu 100 % zu. Man sollte ein nichtdeterministisches Werkzeug, das zu 90 % richtig liegt, dazu bringen, deterministische Werkzeuge zu bauen, die zu 100 % richtig sind. Einer der wichtigsten Sätze, die ich immer in Prompts aufnehme, ist: „Wenn du auf mehrdeutige Randfälle stößt, frag mich bitte.“
    Es ist keine gute Idee, KI direkt per API-Call in Produktion Dinge tun zu lassen. Ich finde, der einzige sinnvolle Einsatz von KI in Apps ist Lesen, Klassifizieren und Ähnliches. Also im Grunde als Ersatz für das „R“ in klassischen CRUD-Apps.
    Es ist okay, auf Basis desselben KI-getriebenen „R“-Endpoints je nach Prompt „C“-, „U“- und „D“-Formulare automatisch auszufüllen, aber nichts sollte für Kunden verändert werden, bevor ein Mensch es geprüft hat. CRUD-Apps sind immer noch CRUD-Apps und werden es bleiben; wir haben nur zusätzlich einen sehr intelligenten „R“-Endpoint bekommen, der Kunden, internen Tools oder Jenkins-Pipelines beim Ausfüllen von Formularen oder beim Vorschlagen von Aktionen hilft. Aktionen vorschlagen ja, sie selbst ausführen nein.
  • In den meisten Organisationen scheint der Fluss von llm -> prompt -> result über llm -> prompt + prompt encoded as skill -> result zu llm -> prompt + deterministic code encoded as skill -> result zu gehen.
    Wenn man die Codegenerierung am Anfang per Prompt machen lässt, kann man den Weg zu deterministischem Code verkürzen, aber man packt deterministischen Code immer noch in einen nichtdeterministischen Wrapper. Um langfristige Aufgaben erfolgreich zu machen, braucht man oft eine Determinismus-Schicht, die derzeit fehlt.
    Man muss deterministischen Code über Agent-Loops oder Frameworks außerhalb der nichtdeterministischen Grenze platzieren. Dann erhält man so etwas wie deterministischer Agentenfluss -> nichtdeterministische Entscheidung -> deterministisches Werkzeug, also nichtdeterministische Urteile, eingeklemmt zwischen Determinismus-Schichten. In Experimenten war das ein sehr starkes Muster, und wenn der Agent mit Tools wie auto-researcher selbst Determinismus erzeugt, wird es noch stärker.
  • Wir haben dieselbe Erfahrung gemacht. Anfangs haben wir dem Agenten einfach eine Liste von Tools gegeben, mit denen er Datenstrukturen auf bestimmte Weise manipulieren kann, aber dieser Ansatz war ziemlich fragil.
    Inzwischen verwenden wir eine kleine domänenspezifische Sprache und ein einziges Tool, in das der Agent ein in dieser Sprache geschriebenes Skript einspeist. Damit können wir dynamischere Anwendungsfälle abdecken, und ungültige Syntax wird vom Parser leicht erkannt und an den Agenten zurückgegeben.
  • Das Problem ist, dass Programme oft auf Randfälle stoßen, die interpretiert werden müssen, und genau dann möchte man das LLM diesen Randfall bearbeiten lassen, und irgendwann will man ihm dann die gesamte Schleife und sogar die Tool-Aufrufe überlassen.
  • Genau das habe ich im letzten Projekt gemacht, als ich die Erzeugung einer Interface-Bibliothek zwischen einem Server, der Hardware steuert, und einer Mobile-App automatisiert habe.
    Das Hardware-Control-Team lieferte Spezifikationen in Form von Dokumenten und Spreadsheets, und das Mobile-Team sah sich diese an, codierte dann die Interface-Bibliothek und validierte sie gegen den Server. Ich habe die Dokumente in TSV umgewandelt und Teile davon an Claude geschickt, damit es einen TSV-Parser schreibt, der die Feinheiten der von Menschen geschriebenen Spezifikation beibehält.
    Es brauchte über 150 Iterationen, um alle Randfälle zu behandeln und Zwischenergebnisse als JSON zu erzeugen. Danach half Claude dabei, einen Codegenerator zu schreiben, der auf Apollo Custom-Glue-Code aufsetzt und den von der Mobile-App konsumierten Code erzeugt.
    Diese gesamte Pipeline läuft als Teil von Github Actions und ruft Claude nur dann auf, wenn der Bibliotheks-Validator fehlschlägt. Im Fehlerfall gibt es eine md-Datei, die in die Anfrage aufgenommen wird und Claude bittet herauszufinden, was schiefgelaufen ist, eine Lösung vorzuschlagen und einen PR zu erstellen. Danach prüfen, ändern und mergen Menschen. Die gesamten Kosten dafür lagen unter 350 Dollar.

• Ich stimme der Grundidee zu, aber ich denke, die Schlussfolgerung muss anders ausfallen. Wenn man an die Grenzen von Prompts stößt, sollte man nicht versuchen, die Aufgabe zur Laufzeit per LLM ausführen zu lassen, sondern das LLM Software schreiben lassen, die die Aufgabe ausführt.
  Die Rolle des LLMs zur Laufzeit wird sich meist darauf reduzieren, dem Nutzer bei der Auswahl von Eingaben zu helfen, die zu einem Softwaresystem mit streng eingebetteten Geschäftsregeln passen.

  • In der Firma hatten wir ein paar freie Wochen und beschlossen, Agenten in Geschäftsprozesse wie Notizerstellung, Aufgabenverfolgung und Dokumentenmanagement einzubauen, und das trifft meine Erfahrung exakt.
    In der ersten Woche wurden die Prompts immer länger und die Performance immer schlechter. In der zweiten Woche haben wir uns darauf konzentriert, Objekte wie Notizen, Aufgaben, Projekte und Personen sauber zu definieren und Methoden festzulegen, die auf diesen Objekten wohldefinierte Operationen ausführen. Wie du sagst, schrumpft die Agentenoberfläche zu einer Übersetzungsschicht, die natürliche Sprache in Befehle und Argumente umwandelt, die durch einen Input-Validator gehen.
  • Wenn man den System-Prompt einmal komplett herumdrehen würde, wäre er wohl: „Suche nach jeder Möglichkeit, dich selbst überflüssig zu machen, indem du automatisierst. Wenn dir eine Frage gestellt wird, die Code beantworten kann, dann schreibe und führe den Code aus, um das Ergebnis zu erhalten und damit zu antworten.“
    So ein LLM hätte den Strawberry-Test vielleicht besser bestanden.
  • Auch in diesem Forum gab es die Ansicht, die Zukunft von Software liege in durch generative KI zur Laufzeit erzeugten und angepassten Programmen. Wie weit wir davon entfernt sind, weiß ich nicht.
  • Ich habe Fälle gesehen, in denen Modelle in einer bestimmten Art der Problemlösung steckenblieben und einen kleinen Schubs brauchten, um auf einen anderen Ansatz umzuschalten. Zum Beispiel wurde versucht, Hotplug/Unplug in Audio-Streams durch massenhaftes Herumkonfigurieren von Systemdiensten zu behandeln, obwohl in Wirklichkeit ein paar Dutzend Zeilen Python gereicht hätten.
    Ich habe Claude in meinem Workflow selbst ein paar Shell-Skripte schreiben lassen, die gängige Fälle wie das Ausführen von Tests behandeln. Jetzt verbringt es nicht mehr 30 Minuten damit, sich im Kreis zu drehen, sondern ruft diese Tools auf und schließt die Einrichtung ab.
    Jedes Mal, wenn es um Erlaubnis bittet, irgendeinen bizarren einmaligen Shell- oder Python-One-Liner auszuführen, frage ich mich, ob ich es lieber ein Tool benutzen lassen sollte, das sich automatisch freigeben lässt.

• Deshalb benutze ich oft den Ausdruck „Next-Generation-AI“. Damit ist nicht einfach nur ein LLM gemeint. LLMs sind ziemlich beeindruckend, und ich denke, selbst ohne weitere grundlegende Fortschritte wird weiter Wert daraus entstehen, indem man sie auf interessantere Weise einsetzt und optimiert.
  Aber bei manchen Dingen scheint eine grundlegende Verbesserung der nächsten Generation in irgendeiner Form nötig zu sein. Dass LLMs „Tu auf keinen Fall X“ zu etwas Verwischtem machen und es nach viel Arbeit am Ende wie „Bitte tu X“ behandeln, wirkt auf einer sehr grundlegenden Ebene verankert. In der frühen Aufregung darüber, was man damit alles tun kann, vergisst man leicht, dass LLMs nicht alles sind, was wir in KI suchen.
  Es braucht eine Architektur, die „Tu auf keinen Fall X“ eher so behandelt wie ein Mensch. Es braucht auch eine Architektur mit einer menschlicheren Erinnerungshierarchie statt nur eines „Kontextfensters“. Selbst wenn es am Anfang dieselbe KI wäre, würden zwei AIs nach einem hinreichend langen Gespräch am Ende tatsächlich zu unterschiedlichen Entitäten werden und nicht nur zu derselben Entität mit verschiedenem Kontextfenster.
  Natürlich weiß niemand, wie das am Ende aussieht. Aber es gibt auch keinen Grund anzunehmen, dass LLMs die endgültige Antwort auf KI sind.

  • Ich denke, wir brauchen echtes Gedächtnis. Das heutige Gedächtnis ist, grob gesagt, eher ein Post-it-System, das die KI selbst schreibt und jedes Mal wieder nachschaut, und kein integriertes System, das Lernen ermöglicht und viel flexibler anspringt.
  • Hier ist ein interessantes Beispiel: https://www.youtube.com/watch?v=kYkIdXwW2AE&t=315s

• Als jemand, der den Kreis von Prompt-Erzwingung → deterministischem Fluss → zurück zu Prompt-Erzwingung schon einmal komplett durchlaufen hat, stimme ich nicht zu.
  Dass „Nicht überspringen“ scheitert, liegt daran, dass der Agent zu viele Dinge gleichzeitig tun soll und andere Inhalte im Kontext ihm von dieser Anweisung die Aufmerksamkeit wegziehen.
  Aber niemand hat je gesagt, dass der Agent, der die Erzwingung übernimmt, derselbe sein muss wie der, der etwas baut. Man kann durchaus einiges an kluger Entscheidungslogik in deterministischen Kontrollfluss kodieren, aber wenn man es zu starr macht, funktioniert es nicht gut, und wenn man es zu komplex macht, ist es oft billiger in Einrichtung und Wartung, einfach einen Agenten zu verwenden.
  Im Grunde braucht man drei Arten von Agenten: einen Supervisor, der die Schleife verwaltet und bei Problemen das Richtige startet, einen Orchestrator, der an den passenden Agenten delegiert und an den richtigen Stellen Guardrails erzwingt, und Worker, die die eigentlichen Arbeitseinheiten ausführen.

  • Genau, man muss einfach nur mehr Agenten hinzufügen.

• Meiner Meinung nach liegen alle Harnesses in diesem Punkt falsch, manche sogar massiv.
  Slash-Commands sind zum Beispiel ein falsches Feature. Man sollte nicht warten müssen, bis ein Chatbot seinen Turn beendet, nur um den Status des Kontextfensters oder das Geld zu sehen, das in dieser Session ausgegeben wurde. Kontrolle sollte orthogonal zur Chat-Schleife sein.
  Dinge, die nichts mit der Steuerung von Ein- und Ausgabe eines Textgenerators zu tun haben, sind an das Chat-Verhalten gekettet, nur weil man denkt: „Es ist ein Chat, also lass es uns wie einen IRC-Bot betreiben.“
  Es gibt heute extrem viele LLM-Agenten, aber fast keiner trennt Kontrolle, Agenten-Loop und Darstellungsschicht sauber. Einige haben immerhin einen Headless-Modus, das ist schon mal gut.

  • Ich verstehe, worauf du hinauswillst, aber die Architektur, die du tatsächlich vorgeschlagen hast, ist viel schwerer zu bauen. Warum baust du sie nicht selbst und versuchst, damit bei einem Großunternehmen eingestellt zu werden?
  • Im codex CLI funktioniert /status auch mitten im Turn.
    Bei anderen ist das nicht so.
  • Ich nutze die Codex-Desktop-App. In der GUI kann man den Kontextindikator und Nutzungsstatistiken sehen.
    Außerdem ist es bequemer, zwischen Gesprächen hin- und herzuwechseln und Updates anzusehen. Gelegentlich nutze ich Claude Code oder opencode im Terminal, aber die Erfahrung ist im Vergleich zur Codex-Desktop-App deutlich schlechter.

• Die Aussage „Stell dir eine Programmiersprache vor, in der Aussagen Vorschläge sind und Funktionen halluzinierend Success zurückgeben. Schlussfolgern wird unmöglich, und Zuverlässigkeit bricht mit wachsender Komplexität zusammen“ erinnert im Kern stark an deklarative Programmierung.
  Der Großteil traditioneller Programmierung ist imperativ, also Entwicklern vertraut: Man gibt eine präzise Menge an Anweisungen und erwartet, dass sie exakt so befolgt werden. Agenten sind viel näher an deklarativ als an imperativ: Man gibt ein Ergebnis vor, und sie arbeiten darauf hin.
  Natürlich sind deklarative Systeme wie SQL ziemlich konsistent und gut definiert, aber trotzdem vertraut man darauf, dass die interne Engine herausfindet, wie es umgesetzt wird. Mir hat es sehr geholfen, Agenten als deklarativ zu betrachten, statt zu versuchen, eine Rube-Goldberg-artige „Kontroll“-Maschine zu entwerfen. Wenn es nicht passt, validiert man, meldet den Fehler und versucht es erneut oder nimmt einen anderen Ansatz.
  Wenn man wirklich imperativ arbeiten muss, dann kann man eben imperativ schreiben. Oder den Agenten dazu bringen, es so zu schreiben. Das hier liest sich, als wolle man für eine Aufgabe das falsche Werkzeug verwenden.

  • Es wirkt fast wie eine noch abstraktere Ebene als deklarativ. Vielleicht könnte man es narrative Programmierung nennen? Wobei man natürlich darüber streiten kann, ob das Wort „Programmierung“ überhaupt noch passt.
    Es mag deklarativ aussehen, aber das ist nur innerhalb der Illusion so. In Wirklichkeit erklären wir der KI kein Ziel, das sie dann interpretiert; vielmehr haben wir ein Story-Dokument, in dem ein menschlicher Stellvertreter-Charakter mit einem Computer-Charakter spricht, und wir in der realen Welt hoffen, dass das LLM dahinter eine kohärentere Geschichte weiterstrickt, aus der wir etwas Nützliches herauslösen können.
    Das ist keine bloß akademische Unterscheidung. Wenn man versteht, dass da eine Geschichte im Spiel ist, wird man besser darin, die Beziehung zwischen Eingaben und Ausgaben zu verstehen und Strategien zu entwickeln. Zum Beispiel hilft das dabei, Risiken wie Prompt Injection zu begreifen, und gibt Hinweise darauf, welche Trainingsdaten man einbeziehen oder ausschließen sollte.
  • Ich musste auch an deklarativ denken, aber eher an PROLOG als an SQL. Da gibt es echten Kontrollfluss und Schlussfolgerungsvermögen.
    Dann stößt man auf ähnliche Probleme wie bei LLMs: stille Fehler, Wiederholungen und Widersprüche, wenn man nicht sehr vorsichtig ist. Im Kern könnte es dasselbe Problem der Closed-World-Assumption sein. Bei LLMs äußert sich das eher als Halluzination statt als Eingeständnis, etwas nicht zu wissen.
  • Stimme zu. Aber man kann auch mit Agenten imperativ sprechen. Selbst wenn man sagt „Hier sind konkrete Schritte, folge ihnen“, können sie es noch vermasseln. Was man sucht, ist nicht Imperativität, sondern Determinismus.
    Und wie du sagst: Wenn man einem nichtdeterministischen LLM deklarativ sagt „Bring mich in diesen Endzustand“, steigt die Wahrscheinlichkeit noch weiter, dass es vom Kurs abkommt.
  • Die Deklarativität von SQL beruht auf der Mathematik der relationalen Algebra, daher liefert es jedes Mal dasselbe Ergebnis zurück. Ob es bei jeder Abfrage in derselben Zeit zurückkommt, hängt von den Indizes und der Größe der Datenbank ab.
    Aber die Abfrage selbst verändert sich nicht wie ein LLM.

• Ich habe viel über dieses Problem nachgedacht. Es könnte auch mit Spezialisierung zusammenhängen. Je spezialisierter ein Modell wird, desto mehr scheinen Fähigkeiten auf Grundniveau eher abzunehmen, und vielleicht bekommt man die Vorteile beider Seiten, wenn man nur auf ein ganz kleines Maß an Abstraktion zielt.
  Das ist ein ziemlich konkretes Beispiel, aber vielleicht trotzdem ein Denkanstoß.
  20-Minuten-Zusammenfassung des Podcasts: https://pub-6333550e348d4a5abe6f40ae47d2925c.r2.dev/EP008.ht...
  Paper: https://arxiv.org/abs/2605.00225

• Das war schon 2023 bei Auto-GPT sichtbar. Die Leute ließen GPT „fahren“, obwohl in den meisten Fällen tatsächlich zehn Zeilen Python und vielleicht ein paar llm()-Funktionsaufrufe gereicht hätten.
  Die Alternative war, diese zehn Zeilen Python auf die teuerste, langsamste und unzuverlässigste Weise auszuführen, die man sich vorstellen kann. Natürlich war das populär.
  Zum Beispiel haben die meisten Leute Agenten für Internet-Recherche verwendet. Die liefen dann stundenlang und wurden entweder zerstreut oder vergaßen, womit sie ursprünglich beschäftigt waren.
  Dabei kann man mit import duckduckgo und import llm in zehn Zeilen Code in 20 Sekunden dasselbe erledigen, und es läuft tatsächlich deterministisch und kostet 50-mal weniger.
  Die aktuellen Modelle sind viel besser, und inzwischen sind sie vermutlich gut genug, dass Auto-GPT realistisch werden könnte. Aber schlecht spezifizierten Kontrollfluss auf die teuerste mögliche Weise auszuführen, ist immer noch eine schlechte Idee.