Execution Grounded Multiagent Systems for Reliable Backend Code Generation with Large Language Models'
Dieses Paper führt ExecuGraph ein, ein konfigurierbares Framework, das demonstriert, dass Ausführungsfeedback der primäre Treiber für die verbesserte Genauigkeit der Codegenerierung in großen Sprachmodellen ist, während es gleichzeitig aufzeigt, dass das Hinzufügen einer Multi-Agenten-Rollenzerlegung keinen messbaren Nutzen gegenüber Single-Agenten-Retry-Loops bietet, trotz signifikant höherer Rechenkosten.
Originalarbeit lizenziert unter CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie versuchen, einem sehr talentierten, aber etwas verträumten Roboter das Schreiben von Computercode beizubringen. Dieser Roboter ist ein „Large Language Model“ (LLM), vergleichbar mit einem superintelligenten Schüler, der fast jedes Buch und jedes Code-Fragment in der Bibliothek gelesen hat. Er kann Code schreiben, der auf dem Papier perfekt aussensieht, aber manchmal subtile Fehler macht, die erst sichtbar werden, wenn man das Programm tatsächlich ausführt. In der Welt der Software ist das eine große Sache, denn ein winziger Fehler kann eine ganze Website zum Absturz bringen oder Daten verlieren lassen.
Lange Zeit dachten die Leute, der beste Weg, dies zu beheben, sei es, ein ganzes Team von Roboter-Spezialisten einzustellen – ein „Multi-Agent-System“. Stellen Sie sich einen Projektmanager, einen strengen Editor, einen Logikprüfer und einen Code-Schreiber vor, die alle zusammenarbeiten. Die Idee war: Wenn man die Arbeit aufteilt und verschiedene Roboter die Arbeit der jeweils anderen prüfen lässt, wäre der fertige Code fehlerfrei. Aber es gab eine hartnäckige Frage: Kam die Verbesserung daher, dass man ein Team hatte, oder einfach nur deshalb, weil die Roboter die Möglichkeit hatten, es noch einmal zu versuchen, nachdem sie ihre Fehler gesehen hatten? Es ist wie die Frage, ob ein Schüler bessere Noten bekommt, weil er eine Lerngruppe hat, oder einfach nur, weil er die Möglichkeit hatte, eine zweite Prüfung abzulegen, nachdem er seine erste gesehen hatte. Dieses Paper setzt sich zum Ziel, dieses Rätsel zu lösen, indem es eine spezielle Testmaschine baut, die diese beiden Faktoren isolieren kann.
Die Forscher bauten ein cleveres Framework namens ExecuGraph, das wie ein Schweizer Taschenmesser für das Testen von Code-schreibenden Robotern fungiert. Sie gestalteten es so, dass sie sofort zwischen drei Modi wechseln konnten: einem „einsamen Wolf“-Roboter, der den Code einmal schreibt und dann aufhört; einem „einsamen Wolf“, der es erneut versuchen darf, falls er scheitert; und dem vollen „Dream-Team“ aus fünf verschiedenen Roboter-Agenten, die zusammenarbeiten. Durch das Durchlaufen derselben 164 schwierigen Programmierrätsel in diesen verschiedenen Modi entdeckten sie etwas Überraschendes.
Das Hauptergebnis ist, dass das dem Roboter zu geben, nach seinen Fehlern erneut zu versuchen, der wahre magische Trick ist, und nicht das Vorhandensein eines Teams von Spezialisten. Als sie einem einzelnen Roboter die Chance gaben, seine Fehler zu sehen und es erneut zu versuchen (ein Prozess, der als „Execution Feedback“ bezeichnet wird), sprang seine Erfolgsquote um massive 25,6 Prozentpunkte. Er verbesserte sich von etwa 56 % korrekten Lösungen auf über 81 %. Das ist ein riesiger Gewinn!
Als sie jedoch das volle Team aus fünf zusätzlichen Agenten (einen Planer, einen Reviewer, einen Optimierer usw.) zusätzlich zu diesem Retry-System hinzufügten, verbesserten sich die Ergebnisse jedoch nicht weiter. Tatsächlich war die „Team“-Version statistisch nicht von dem einzelnen Roboter zu unterscheiden, der lediglich die Möglichkeit zum Retry hatte. Die „Team“-Version kostete etwa 3,6-mal mehr an Computerleistung und Zeit, lieferte aber nicht eine einzige zusätzliche korrekte Antwort. Die Forscher schlossen auch die Idee aus, dass das Team nur deshalb gewann, weil es öfter „würfeln“ durfte; sie bewiesen, dass das bloße Generieren von fünf zufälligen Versuchen ohne jegliches Feedback nicht viel half.
Es gab jedoch eine Wendung in der Geschichte. Die Forscher fanden einen Bug in ihrer eigenen Testmaschine (einer „Sandbox“, die den Code ausführt), die versehentlich korrekten Code ablehnte. Sobald sie diesen Bug behoben hatten, änderten sich die Zahlen, aber die Hauptschlussfolgerung blieb dieselbe: Der Retry-Loop ist der Held, und die zusätzlichen Agenten sind größtenteils nur teure Dekoration.
Das Paper untersuchte auch, wie dies mit verschiedenen Arten von Robotern funktioniert. Bei einem spezifischen Typ von Roboter (einem 16-Milliarden-Parameter-Modell) half der Team-Ansatz bei einer speziellen Art von Rätsel, nämlich „Graph-Problemen“, und steigerte den Erfolg von 70 % auf 90 %. Aber bei anderen Arten von Rätseln war das Team tatsächlich schlechter, und die Gesamtpunktzahl blieb gleich. Dies deutet darauf hin, dass das Hinzufügen von mehr Agenten einen Roboter nicht automatisch intelligenter macht; es ändert lediglich, welche Probleme er lösen kann.
Am Ende legt das Paper nahe, dass man, wenn man einen zuverlässigen Code-schreibenden Roboter möchte, kein komplexes Unternehmen aus fünf verschiedenen Agenten aufbauen muss. Man muss dem Roboter nur einen einzigen, intelligenten Loop geben: schreibe den Code, führe ihn aus, sieh nach, was kaputtgegangen ist, und versuche, es zu reparieren. Es ist viel billiger, schneller und genauso effektiv wie das Einstellen eines ganzen Komitees. Der „Team“-Ansatz mag noch immer nützlich sein, um zusätzliche Berichte oder Erklärungen zu generieren, aber für die eigentliche Aufgabe, korrekten Code zu schreiben, ist die einfache „Versuchen, Scheitern, Erneut Versuchen“-Strategie der klare Gewinner.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.