SWE-bench
SWE-bench ist ein Test, mit dem geprüft wird, ob ein KI-System echte Programmierfehler in bestehender Software selbst reparieren kann. Die Aufgaben stammen aus realen Softwareprojekten, und als Lösung gilt nur, was die vorhandenen Prüfprogramme des Projekts bestehen lässt.
SWE-bench ist eine Sammlung von Prüfaufgaben für KI-Systeme, die Programmcode schreiben. Jede Aufgabe ist eine echte Fehlermeldung aus einem frei zugänglichen Softwareprojekt, also einem Programm, dessen Quelltext im Internet für alle einsehbar ist. Das KI-System bekommt den Zustand des Projekts vor der Reparatur und die Beschreibung des Fehlers. Es muss selbst herausfinden, welche Dateien betroffen sind, und dort eine Änderung vornehmen. Ob die Änderung richtig ist, entscheidet nicht ein Mensch, sondern ein automatischer Prüflauf: Das Projekt bringt kleine Testprogramme mit, die das Verhalten der Software kontrollieren. Laufen sie nach der Änderung fehlerfrei durch, gilt die Aufgabe als gelöst.
Warum echte Fehlerberichte härter sind als Programmieraufgaben
Ältere Tests für Programmier-KI stellten kleine, abgeschlossene Aufgaben: eine Funktion schreiben, die eine Liste sortiert. Solche Aufgaben passen auf eine halbe Seite und haben nichts mit dem Alltag von Softwarefirmen zu tun. Dort besteht die Arbeit meist darin, in einem gewachsenen Projekt mit tausenden Dateien eine einzelne kaputte Stelle zu finden. SWE-bench misst genau diese Fähigkeit.
Deshalb ist der Test zu einer wichtigen Messlatte der Branche geworden. Wenn ein Unternehmen ein neues Sprachmodell vorstellt, steht die SWE-bench-Quote fast immer in der Ankündigung. Die Zahlen sind gut vergleichbar, weil alle Anbieter dieselben Aufgaben verwenden. Ein Anstieg von 20 auf 60 Prozent gelöste Aufgaben innerhalb weniger Jahre ist ein handfester Hinweis auf Fortschritt.
Wirtschaftlich ist das brisant. Investoren und Firmen lesen aus solchen Werten ab, wie viel Programmierarbeit KI übernehmen könnte. Gleichzeitig warnen Forscher davor, eine einzelne Prozentzahl mit allgemeiner Kompetenz zu verwechseln. Ein System, das Fehler repariert, hat damit noch nicht gezeigt, dass es ein neues Programm sinnvoll entwerfen kann.
Vom Fehlerbericht zum bestandenen Testlauf
Die Aufgaben wurden aus der Versionsgeschichte bekannter Projekte gewonnen, viele davon aus der Programmiersprache Python. Die Entwickler suchten Stellen, an denen ein gemeldeter Fehler tatsächlich durch eine Codeänderung behoben wurde. Diese menschliche Lösung wird entfernt und als geheime Referenz behalten. Übrig bleibt das Projekt im kaputten Zustand plus die ursprüngliche Fehlerbeschreibung.
Das KI-System arbeitet dann meist nicht als reiner Textgenerator, sondern als sogenannter Agent. Das ist ein Programm, das das Modell in einer Schleife betreibt: Dateien lesen, suchen, eine Änderung schreiben, Tests starten, Fehlermeldung auswerten, nachbessern. Am Ende gibt es einen Patch ab, also eine genaue Liste der geänderten Zeilen. Dieser Patch wird auf das Originalprojekt angewendet.
Nun laufen zwei Gruppen von Tests. Die eine Gruppe muss vorher fehlgeschlagen sein und nachher gelingen, sonst wurde der Fehler nicht behoben. Die andere Gruppe war schon vorher in Ordnung und muss es bleiben, damit nichts Neues zerbricht. Nur wenn beides zutrifft, zählt die Aufgabe. Ein bekanntes Problem des Tests: Manche Fehlerberichte sind so knapp formuliert, dass selbst Menschen die erwartete Lösung kaum erraten könnten. Deshalb gibt es eine geprüfte Teilmenge namens SWE-bench Verified mit 500 von Fachleuten kontrollierten Aufgaben.
Wo die Prozentzahl in Schlagzeilen auftaucht
Am häufigsten begegnet man SWE-bench in Produktankündigungen. Wenn in einer Meldung steht, ein Modell löse „74 Prozent auf SWE-bench Verified“, ist dieser Test gemeint. Weil verschiedene Anbieter unterschiedliche Varianten und unterschiedlich aufwendige Agenten nutzen, sind zwei Zahlen nur bedingt vergleichbar. Ein Blick auf die Fußnote lohnt fast immer.
Indirekt merkt man den Effekt in Werkzeugen, die Programmierer täglich nutzen. Assistenten, die in der Entwicklungsumgebung selbstständig Fehler suchen und Änderungsvorschläge machen, sind genau an solchen Aufgaben trainiert und gemessen worden. Auch Dienste, die automatisch auf Fehlerberichte in einem Projekt reagieren, gehen auf diese Forschungsrichtung zurück. Wer selbst programmiert, kann die Idee im Kleinen ausprobieren: einen Fehler beschreiben, das Modell den Code lesen lassen, danach die Tests laufen lassen.