Don't Claim Benchmark-Oriented Optimization Improves General Coding Capability -- Diverse Evaluation Is Required
Dieses Paper argumentiert, dass die Optimierung großer Sprachmodelle für eng gefasste Coding-Benchmarks wie SWE-bench dazu führt, dass sich die allgemeinen Programmierfähigkeiten nicht verbessern oder auf andere Aufgaben übertragen lassen, was einen Wechsel hin zu vielfältigen, ganzheitlichen Evaluierungsmethoden und einer kontinuierlichen Benchmark-Wartung erforderlich macht, um eine zuverlässige Bewertung zu gewährleisten.
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
Das Setup: Eine Welt aus Code und die „Scorecard“-Falle
Stellen Sie sich eine Welt vor, in der Computer lernen, ihre eigene Software zu schreiben – ein Feld, das als „Deep Learning for Code“ bekannt ist. In dieser Welt bauen Forscher massive digitale Gehirne, sogenannte „Foundation Models“, die Programmiersprachen verstehen können. Um zu bestimmen, wie intelligent diese Gehirne sind, nutzen Wissenschaftler „Benchmarks“ – im Wesentlichen standardisierte Tests, vergleichbar mit den SATs oder den Olympischen Spielen für KI. Der berühmteste dieser Tests derzeit heißt SWE-bench. Es handelt sich dabei um eine spezifische Herausforderung, bei der einer KI ein realer Softwarefehler vorgegeben wird und sie die Aufgabe erhält, diesen zu beheben.
Lange Zeit operierte die Fachwelt unter einer einfachen Annahme: Wenn eine KI eine hohe Punktzahl bei SWE-bench erreicht, muss sie ein generell brillanter Programmierer sein. Es ist so, als würde man davon ausgehen, dass ein Schüler, weil er den Mathematik-Teil eines standardisierten Tests mit Bestnoten abgeschlossen hat, automatisch ein Genie in Physik, Geschichte und Kunst ist. Dieses Paper stellt eine sehr wichtige Frage: Ist diese Annahme tatsächlich wahr? Die Autoren befürchten, dass wir uns selbst täuschen könnten. Sie vermuten, dass KI-Modelle eher zu „Test-Taktikern“ werden als zu „Denkern“ – sie lernen genau, wie man die spezifische SWE-bench-Prüfung besteht, ohne tatsächlich besser in dem breiten, chaotischen, realen Job des Programmierens zu werden.
Das Paper: Warum die Scorecard uns vielleicht belügt
Die Autoren dieses Papers, ein Team von Forschern von JetBrains und verschiedenen Universitäten, beschlossen, diese Annahme auf die Probe zu stellen. Sie argumentieren, dass es eine „Bedeutungslücke“ (meaning gap) zwischen dem, was diese Benchmarks tatsächlich messen, und dem, was wir daraus ableiten, gibt. Um der Wahrheit auf den Grund zu gehen, haben sie nicht nur bestehende Scores betrachtet, sondern ihren eigenen neuen Testplatz geschaffen.
Das Experiment: Ein neuer Spielplatz
Die Forscher entwickelten eine benutzerdefinierte Benchmark-Suite basierend auf Django, einem populären Web-Framework. Warum Django? Weil es fast die Hälfte der SWE-bench-Fragen ausmacht. Wenn eine KI ein wahrer Coding-Genie ist, sollte sie in der Lage sein, Fehler in Django genauso gut zu beheben, wie sie die SWE-bench-Probleme löst.
Sie entwarfen drei spezifische Arten von Herausforderungen, um zu sehen, ob die KI verschiedene Arten von Aufgaben bewältigen kann:
- Method Generation: Das Schreiben einer völlig neuen Funktion von Grund auf basierend auf einer Beschreibung.
- Method Completion: Das Fertigstellen einer Funktion, die bereits begonnen wurde.
- Program Repair: Das Finden eines defekten Code-Teils und dessen Reparatur mithilfe von Fehlermeldungen.
Anschließend nahmen sie eine Reihe von KI-Modellen, die intensiv darauf „trainiert“ wurden, SWE-bench zu meistern, und testeten sie auf ihren neuen Django-Herausforderungen. Sie testeten auch Modelle, die sie selbst für eine einzige spezifische Aufgabe trainiert hatten, um zu sehen, ob sich diese Fähigkeit auf andere Bereiche übertragen ließe.
Die große Entdeckung: Das „Spezialisten“-Problem
Die Ergebnisse waren ein Schock. Das Paper legt nahe, dass die Optimierung einer KI für SWE-bench sie nicht zu einem besseren allgemeinen Programmierer macht. Tatsächlich macht es sie in anderen Bereichen oft sogar schlechter.
- Kein Transfer von Fähigkeiten: Als sie Modelle, die bei SWE-bench Superstars waren, mit den neuen Django-Aufgaben konfrontierten, scheiterten die Modelle oft. Sie wurden nicht besser im Beheben von Fehlern oder im Schreiben von neuem Code; sie wurden lediglich besser darin, das spezifische Rätsel zu lösen, das SWE-bench verwendet. Es ist, als würde man einen Hund darauf trainieren, einen ganz bestimmten Ball zu apportieren, und dann überrascht sein, wenn er keinen Frisbee fangen kann.
- Die „Format“-Falle: Viele der Modelle, die scheiterten, taten dies nicht, weil sie nicht in der Lage waren, den Code zu schreiben. Sie scheiterten, weil sie durch das Format der Antwort verwirrt wurden. Das SWE-bench-Training lehrte sie, Code in spezifischen Tags oder Stilen auszugeben, die die neuen Tests nicht erwarteten. Die Modelle wurden so gut darin, den „Prüfungsanweisungen“ zu folgen, dass sie vergaßen, einfach nur die Arbeit zu erledigen.
- Die „Ein-Aufgaben“-Illusion: Als die Forscher Modelle trainierten, die nur eine einzige Aufgabe beherrschten (wie etwa nur das Beheben von Fehlern), wurden diese Modelle zwar exzellent im Beheben von Fehlern, verbesserten sich aber nicht beim Schreiben von neuem Code oder beim Vervollständigen von Teil-Code. Dies beweist, dass die „Verbesserung“ eng gefasst und spezifisch war, nicht ein allgemeiner Intelligenzschub.
Das Urteil: Vertrauen Sie nicht dem Leaderboard
Das Paper kommt zu dem Schluss, dass es irreführend ist, sich auf eine einzige Benchmark wie SWE-bench zu verlassen, um die Behauptung aufzustellen, ein Modell besitze „allgemeine Programmierfähigkeiten“. Die Autoren schlagen vor, dass das Feld in eine Falle getappt ist, in der wir auf die Testpunktzahl optimieren statt auf die tatsächliche Fähigkeit.
Sie schlagen einen neuen Weg des Denkens vor:
- Für die größten, fortschrittlichsten Modelle: Wir benötigen „holistische“ Evaluationen, wie etwa das Beobachten ihrer Arbeit an offenen, realen Projekten, anstatt ihnen nur Multiple-Choice-Tests vorzusetzen.
- Für die Forschung: Wir benötigen vielfältige Test-Suites, die viele verschiedene Arten von Programmieraufgaben abdecken, nicht nur eine einzige.
- Für die reale Anwendung: Wir müssen Modelle auf den spezifischen Aufgaben testen, die uns tatsächlich wichtig sind, wobei möglicherweise Menschen in den Prozess einbezogen werden (human-in-the-loop), um die Arbeit zu überprüfen.
Kurz gesagt warnt das Paper uns davor, dass eine hohe Punktzahl auf einem Coding-Leaderboard nicht bedeutet, dass die KI ein Meisterbauer ist; es könnte lediglich bedeuten, dass sie ein Meister der Test-Taktik ist. Um zu wissen, ob eine KI wirklich intelligent ist, müssen wir aufhören, auf eine einzige Zahl zu schauen, und anfangen, das Gesamtbild zu betrachten.
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.