Asuka-Bench: Benchmarking Code Agents on Underspecified User Intent and Multi-Round Refinement
Das Paper stellt Asuka-Bench vor, einen neuartigen Benchmark, der darauf ausgelegt ist, Code-Agenten bei Webentwicklungsaufgaben zu evaluieren, indem reale mehrstufige Verfeinerungszyklen simuliert werden, in denen Agenten unterentwickelte Projekte basierend auf automatisierten UI-Tests und natürlicher Sprachrückmeldung iterativ verbessern, was signifikante Leistungsunterschiede zwischen aktuellen Modellen offenlegt.
Originalarbeit lizenziert unter CC BY 4.0 (http://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 stellen einen brillanten, aber etwas wortwörtlichen Architekten ein, um ein Haus zu bauen.
Der alte Weg (Bestehende Benchmarks)
Früher war das Testen dieser Architekten so, als würde man ihnen einen perfekten, 50-seitigen Bauplan geben, der jede einzelne Schraube, jeden Draht und jede Farbe auflistet. Man sagte: „Baue dies“, und sie überreichten einem ein fertiges Haus. Wenn das Haus dem Bauplan entsprach, bekamen sie ein A. Wenn nicht, ein F.
Das Problem ist, dass das echte Leben nicht so funktioniert. Echte Kunden haben selten einen perfekten 50-seitigen Bauplan. Meistens sagen sie: „Ich möchte ein Haus mit einer Küche und einem Platz zum Schlafen“, und sobald sie den ersten Entwurf sehen, merken sie: „Oh, ich wollte die Küche eigentlich größer haben“ oder „Warte, die Tür öffnet sich in die falsche Richtung“.
Der neue Weg (Asuka-Bench)
Die Arbeit stellt Asuka-Bench vor, eine neue Methode, um „Code-Agenten“ (KI-Programme, die Software schreiben) zu testen. Anstatt dem KI-Modell einen perfekten Bauplan zu geben, geben die Forscher ihm eine vage, unordentliche Anfrage, wie zum Beispiel: „Erstelle eine Shopping-Website mit einer Produktliste und einem Warenkorb.“
Dann bewerten sie nicht nur das erste Ergebnis. Sie stellen ein Dreier-Team auf, das einen realitätsnahen Entwicklungszyklus simuliert:
- Der Erbauer (Code-Agent): Dies ist die KI, die versucht, die Website basierend auf der vagen Anfrage zu bauen.
- Der Inspektor (UI-Agent): Dies ist ein Roboter, der die Website tatsächlich in einem Webbrowser besucht. Er liest nicht den Code; er agiert wie ein menschlicher Nutzer. Er klickt auf Schaltflächen, versucht Dinge zu kaufen und prüft, ob die Seiten laden. Es ist wie ein Qualitätskontrolleur, der durch das Haus geht, um zu sehen, ob die Türen aufgehen.
- Der Kunde (User LLM): Dies ist eine weitere KI, die den Inspektor beobachtet. Wenn der Inspektor ein Problem findet (z. B. „Der ‚Kaufen‘-Button funktioniert nicht“), übersetzt der Kunde dies in eine höfliche Notiz für den Erbauer: „Hey, der Button ist kaputt. Bitte repariere ihn.“
Der Erbauer repariert dann die Website, und der Zyklus wiederholt sich. Dies geschieht über bis zu drei Runden hinweg.
Die „DAG“-Analogie
Die Forscher haben auch eine intelligente Methode erfunden, um Feedback zu geben, die ein DAG (Directed Acyclic Graph) ist. Denken Sie an dies wie an ein Rezept.
- Wenn Sie versuchen, einen Kuchen zu backen, können Sie ihn nicht glasieren, bevor Sie ihn gebacken haben.
- Bei den alten Testmethoden passierte es, dass der Inspektor, wenn der Kuchen verbrannt war, sich auch darüber beschwerte, dass die Glasur fehlte, obwohl man einen verbrannten Kuchen nicht erst glasieren konnte.
- In Asuka-Bench kennt das System die Reihenfolge. Wenn der Schritt „Backen“ fehlschlägt, verhindert das System, dass der Inspektor den Schritt „Glasieren“ überprüft. Es sagt dem Erbauer lediglich: „Du hast den Kuchen nicht gebacken.“ Dies verhindert, dass der Erbauer durch Beschwerden über Dinge verwirrt wird, die noch gar nicht stattgefunden haben.
Was sie herausgefunden haben
Die Forscher haben 8 verschiedene KI-Modelle mit dieser Methode getestet. Hier ist, was sie entdeckten:
- Einige KIs sind besser im Reparieren als andere: Nur weil eine KI gut darin ist, den ersten Entwurf zu erstellen, bedeutet das nicht, dass sie auch gut darin ist, Fehler zu beheben. Einige Modelle erstellten eine großartige erste Version, konnten aber die Notizen des „Kunden“ nicht verstehen, um die Fehler zu korrigieren. Andere starteten chaotisch, wurden aber mit jeder Feedbackrunde besser.
- Die Lücke ist riesig: Die besten Modelle konnten etwa 52 % der Projekte nach drei Runden Korrektur perfekt abschließen. Die schlechtesten Modelle schafften nur etwa 8 %. Das ist ein gewaltiger Unterschied.
- Es ist immer noch schwierig: Selbst die klügsten KIs konnten nicht jedes Projekt perfekt abschließen. Dies zeigt, dass sich die KI zwar gut entwickelt, aber immer noch mit der unordentlichen, wechselseitigen Natur echter menschlicher Anfragen kämpft.
Zusammenfassend
Asuka-Bench ist ein neuer „Führerschein-Test“ für KI-Programmierer. Anstatt sie zu bitten, ein Auto auf einer perfekt geraden, leeren Strecke zu fahren (ein perfekter Bauplan), werden sie gebeten, im Stadtverkehr zu fahren, Anweisungen von einem Beifahrer entgegenzunehmen, wenn sie falsch abbiegen, und ihren Kurs zu korrigieren. Es stellt sich heraus, dass die Fähigkeit zuzuhören und Fehler zu korrigieren eine völlig andere Fähigkeit ist, als einfach nur geradeaus zu fahren.
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.