Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering
Das Papier argumentiert, dass aktuelle Coding-Benchmarks nicht mit agentischem Software Engineering im Einklang stehen, da sie die Modellleistung mit Komponenten des System-Harness vermengen, valide alternative Lösungen durch die Abhängigkeit von einer einzigen Referenzantwort bestrafen und das für eine iterative Systemverbesserung notwendige granulare Feedback vermissen lassen.
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
Die Kernidee: Wir bewerten das Falsche
Stellen Sie sich vor, Sie möchten beurteilen, wie gut ein Koch darin ist, eine komplexe Mahlzeit zuzubereiten.
Derzeit ist die Art und Weise, wie wir Coding-„Agenten“ (KI-Systeme, die Software schreiben) testen, so: Sie geben dem Koch ein einzelnes, vorgefertigtes Rezept (die „Referenzlösung“). Der Koch versucht, das Gericht zu kochen. Wenn der fertige Teller exakt so aussieht wie das Bild im Kochbuch, erhält der Koch eine perfekte Punktzahl. Wenn der Koch eine köstliche, gesunde und kreative Version des Gerichts zubereitet, die zwar besser schmeckt, aber etwas anders aussieht, erhält er eine niedrige Punktzahl.
Die Autoren dieser Arbeit argumentieren, dass dies ein kaputtes System ist. Sie sagen, wir testen nicht nur den Koch (das KI-Modell), sondern die gesamte Kücheneinrichtung (das „System Harness“), welche die Herdplatte, die Werkzeuge, die Zutaten und die Anweisungen umfasst.
Das Kernproblem: Die „Küche“ vs. der „Koch“
Das Papier zieht eine entscheidende Unterscheidung:
- Das Modell (Der Koch): Dies ist das KI-Gehirn, das den Code generiert.
- Das System Harness (Die Küche): Dies ist die komple gesamte Umgebung, in der die KI lebt. Sie umfasst die Werkzeuge, die sie benutzt, den Kontext, den sie liest, die Regeln, denen sie folgt, und die Feedbackschleifen, die ihr mitteilen, wenn sie einen Fehler gemacht hat.
Die Analogie:
Betrachten Sie einen Coding-Agenten wie ein Formel-1-Rennauto.
- Das Modell ist der Motor.
- Das System Harness ist das Fahrgestell, die Reifen, die Aerodynamik, die Boxencrew und die Strategie des Fahrers.
Aktuelle Benchmarks sind wie ein Rennen, bei dem man nur auf die Endzeit schaut und sagt: „Dieser Motor ist schnell!“ Aber das Papier weist darauf hin, dass man mit den Reifen oder der Strategie des Fahrers (dem Harness) das Auto 20 % schneller oder langsamer machen kann, selbst wenn man exakt denselben Motor verwendet.
Die Autoren zeigen, dass in realen Tests die Änderung der „Kücheneinrichtung“ (des Harness) die Ergebnisse genauso stark verändert wie die Aufrüstung des „Kochs“ (des KI-Modells) auf eine neuere Version. Dennoch behandeln unsere aktuellen Tests das Ergebnis so, als ob es nur am Talent des Kochs läge.
Drei Symptome des kaputten Systems
Das Papier identifiziert drei spezifische Arten, wie unsere aktuellen Testmethoden nicht mit der Realität übereinstimmen:
1. Vermischung der Grenzen (Konflation)
Die Analogie: Stellen Sie sich vor, ein Schüler macht einen Mathetest. Er erhält eine Punktzahl von 80 %. Wir nehmen an, der Schüler ist klug. Aber was, wenn der Schüler einen Taschenrechner, ein Spickzettel und einen Tutor hatte, der ihm die Antworten zuflüstert? Wenn wir nicht berichten, wie er die 80 % erreicht hat, können wir nicht sagen, ob der Schüler tatsächlich klug ist oder ob die Werkzeuge die Arbeit erledigt haben.
Die Behauptung des Papers: Aktuelle Benchmarks melden eine einzige Punktzahl (z. B. „Modell X hat 65 % Genauigkeit“). Sie sagen Ihnen nicht, welche Werkzeuge oder Umgebungen verwendet wurden. Dies macht es unmöglich zu wissen, ob die KI tatsächlich klüger wird oder ob die „Küche“ einfach nur besser geworden ist.
2. Die „Eine richtige Antwort“-Falle (Single Reference)
Die Analogy: Stellen Sie sich vor, Sie bitten einen Schreiner, einen Tisch zu bauen. Sie haben ein Foto eines ganz bestimmten Tisches, den Sie wollen.
- Szenario A: Der Schreiner baut einen Tisch, der stabil, schön und funktional ist, aber eine etwas andere Holzmaserung verwendet als auf Ihrem Foto.
- Szenario B: Der Schreier baut einen Tisch, der exakt wie auf Ihrem Foto aussieht, aber wackelig ist und auseinanderfällt.
Aktuelle Benchmarks würden Szenario B eine perfekte Punktzahl geben und Szenario A eine schlechte Punktzahl, weil es nicht exakt dem Foto entspricht.
Die Behauptung des Papers: Wahre Softwareentwicklung bedeutet nicht, eine einzige Lösung zu kopieren. Es geht darum, ein Problem auf die bestmögliche Weise zu lösen. Indem wir die KI zwingen, einen spezifischen Code-Schnipsel nachzuahmen, bestrafen wir kreative, gültige und oft bessere Lösungen. Wir testen, ob die KI einen spezifischen Patch nachahmen kann, nicht ob sie das Problem lösen kann.
3. Die Black Box (Kein Komponentensignal)
Die Analogie: Stellen Sie sich vor, Ihr Auto geht kaputt. Sie bringen es zu einem Mechaniker, der sagt: „Das Auto ist kaputt.“ Das ist eine „End-to-End“-Bewertung. Sie sagt Ihnen, dass etwas nicht stimmt, aber sie sagt Ihnen nicht, was. Ist es die Batterie? Die Reifen? Der Motor?
Die Behauptung des Papers: Wenn ein Coding-Agent einen Test nicht besteht, sagen aktuelle Benchmarks einfach nur „Fehlgeschlagen“. Sie sagen Ihnen nicht, warum. Hat die KI die Anweisungen missverstanden? Haben die Werkzeuge versagt? Ist die Umgebung abgestürzt? Oh-ne die Information, welcher Teil der „Küche“ fehlgeschlagen ist, können Entwickler das System nicht reparieren. Sie bleiben im Dunkeln gelassen.
Was sollten wir stattdessen tun?
Die Autoren schlagen drei Änderungen vor, um dies zu beheben:
- Das vollständige Rezept melden: Wenn Testergebnisse veröffentlicht werden, müssen wir jedes Werkzeug, jede Umgebung und jede Einstellung auflisten. Wir müssen wissen, ob die Punktzahl von einer genialen KI oder einer super-starken Küche stammt.
- Nach Verhalten bewerten, nicht nach Aussehen: Anstatt zu prüfen, ob der Code wie der „Goldstandard“ aussieht, sollten wir prüfen, ob der Code funktioniert und die Regeln einhält (wie Sicherheitsprüfungen oder Designmuster). Es sollte viele Wege geben, ein Problem zu lösen, und der Test sollte jede gültige Lösung akzeptieren.
- Die Teile testen, nicht nur das Ganze: Wir müssen das System aufteilen. Testen Sie die Fähigkeit der KI, Anweisungen zu lesen, separat von ihrer Fähigkeit, Werkzeuge zu benutzen. Dies hilft uns, den spezifischen defekten Teil zu finden, anstatt nur zu raten.
Das Fazit
Das Papier argumentiert, dass wir versuchen, die Zukunft der Softwareentwicklung (komplexe, autonome KI-Systeme) mit Werkzeugen zu messen, die für die Vergangenheit entwickelt wurden (einfache, einmalige Code-Generierung).
Um voranzukommen, müssen wir aufhören, das KI-Modell als das einzige Wichtige zu betrachten. Wir müssen anfangen, das gesamte System zu messen – die Werkzeuge, die Regeln und die Feedbackschleifen – denn in der realen Welt ist es das, was die Arbeit tatsächlich erledigt. Bis wir das tun, werden unsere Rankings und Punktzahlen irreführend sein.
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.