SWE-bench: Können Sprachmodelle reale GitHub-Issues lösen?

Das CodeAct-Paper lieferte überzeugende Argumente für Python als das richtige Aktionsformat für LLM-Agenten. Doch die Wahl des richtigen Aktionsformats ist nur die halbe Miete — man muss auch nachweisen, dass Agenten die Komplexität realer Aufgaben bewältigen können und nicht nur kuratierte Benchmarks. SWE-bench (arXiv:2310.06770), veröffentlicht von Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press und Karthik Narasimhan aus Princeton und präsentiert auf der ICLR 2024, ist die Arbeit, die das Feld zwang, sich dieser Lücke direkt zu stellen.

Das Paper

"SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" erstellt einen Benchmark aus 2.294 Aufgabeninstanzen, die aus tatsächlich gemergten Pull Requests von 12 populären Python-Repositories stammen — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy und xarray. Jede Instanz präsentiert dem Modell einen Snapshot der Codebasis und eine Beschreibung eines GitHub-Issues; das Modell muss einen Patch erstellen, der eine festgelegte Gruppe zuvor fehlgeschlagener Tests bestehen lässt, ohne bestehende Tests zu beeinträchtigen. Der Benchmark wurde durch das Mining von ca. 90.000 PRs konstruiert, wobei nach solchen gefiltert wurde, die sowohl ein verknüpftes Issue lösten als auch neue Tests hinzufügten, gefolgt von einer Verifizierung der ausführungsbasierten Pass/Fail-Übergänge. Diese disziplinierte Konstruktion vermeidet das typische Benchmark-Problem einer mehrdeutigen oder leicht manipulierbaren Ground Truth.

Kernideen

• Claude 2, das zum Zeitpunkt der Veröffentlichung leistungsstärkste Modell, löst nur 1,96 % der Probleme unter Verwendung von BM25 Sparse Retrieval — dem realistischen Einsatzszenario, in dem das Modell relevante Dateien selbst finden muss.
• Mit "Oracle-Retrieval" — bei dem dem Modell exakt die benötigten Dateien übergeben werden — verbessert sich Claude 2 auf 4,80 %. Dies bestätigt, dass der Engpass teilweise beim Retrieval, hauptsächlich aber beim Editieren liegt: Selbst mit perfektem Kontext bleiben die Erfolgsraten unter 5 %.
• GPT-4 löst 0,00 % der Probleme mit BM25-Retrieval (aus Budgetgründen an einer 25 %-Teilmenge evaluiert) und 1,74 % mit Oracle. Der Abfall von Oracle zu BM25 ist bei Claude 2 massiv; bei GPT-4 ist er total.
• Generierte Patches sind systematisch zu kurz: Die erfolgreichen Patches von Claude 2 umfassen durchschnittlich 19,6 Zeilen, gegenüber 74,5 Zeilen bei den menschlichen Gold-Standard-Patches. Modelle finden einfache lokale Korrekturen; Menschen schreiben umfassende, dateiübergreifende Lösungen.
• Mehr Kontext schadet aktiv. BM25 mit 50k Token findet zwar mehr der Oracle-Dateien als bei 13k Token, dennoch sinken die Lösungsraten oft. Der "Lost in the Middle"-Effekt — Modelle ignorieren relevante Informationen, die in langen Kontexten vergraben sind — ist hier ein realer und dokumentierter Fehlermodus.
• SWE-Llama 13b, feinabgestimmt auf Oracle-basierten Kontexten, erreicht 4,00 % mit Oracle, aber nur 0,70 % mit BM25. Das Training auf perfektem Kontext erzeugt fragile Agenten, die unter realistischen Retrieval-Bedingungen versagen.

Was Bestand hat — und was nicht

Die Konstruktion des Benchmarks ist rigoros. Ausführungsbasierte Evaluierung — Tests, die tatsächlich laufen und bestehen oder fehlschlagen — ist die richtige Ground Truth für Code-Editieraufgaben. Sie ist objektiv, automatisierbar und schwer zu manipulieren. Die Entscheidung, Fail-to-Pass-Übergänge zu fordern (und nicht nur die erfolgreiche Anwendung eines Patches), ist besonders wichtig: Sie verhindert trivial korrekte Patches wie No-Ops oder Löschungen.

Die Ergebnisse haben sich bemerkenswert gut gehalten. SWE-bench wurde im Oktober 2023 veröffentlicht und entwickelte sich rasch zur De-facto-Evaluierung für Coding-Agenten. Die ursprüngliche Baseline von 1,96 % ist aufrichtig informativ und nicht beschönigt. SWE-agent, 2024 von einer verwandten Gruppe veröffentlicht, steigerte den Wert auf 12,47 % durch die Neugestaltung der Agent-Computer-Schnittstelle — eine 6-fache Verbesserung, die selbst bestätigt, wie viel die ursprüngliche Baseline ungenutzt ließ.

Zwei Dinge adressiert das Paper weniger gut: Erstens ist der Benchmark nur auf Python beschränkt. Das ist eine praktische Notwendigkeit, birgt aber das Risiko eines Overfittings auf Python-Konventionen. Zweitens schlägt das Paper nur Baselines für Retrieval-Augmented Generation vor und verweist explizit auf zukünftige Arbeiten für agentenbasierte Ansätze. Dieser Verweis war 2023 angemessen, bedeutet aber, dass das Paper selbst keine Anhaltspunkte liefert, welche Agenten-Architekturen hilfreich sind.

Die "Oracle"-Einstellung ist zudem eine schwächere obere Schranke, als es scheint. Das Bereitstellen des perfekten Dateikontexts löst nicht die Code-Lokalisierung innerhalb dieser Dateien und hilft nicht bei der dateiübergreifenden Argumentation über Interaktionen zwischen Modulen. Claude 2 bei 4,8 % Oracle bedeutet, dass das Modell selbst mit den richtigen Dateien im Kontext in 95 % der Fälle scheitert. Das Problem liegt also nicht primär beim Retrieval.

Warum das für Finanz-KI wichtig ist

Beancount ist ein in Python geschriebenes Projekt auf GitHub. Ein Write-Back-Agent für Beancount ist im Wesentlichen ein Agent, der Aufgaben im Stil von SWE-bench bewältigen muss: Gegeben eine Ledger-Datei und eine Anweisung ("füge diese Transaktion hinzu", "behebe diese Bilanzdiskrepanz"), muss ein Edit erstellt werden, der bean-check besteht, ohne bestehende Assertionen zu verletzen.

Das Scheitern beim Retrieval ist direkt analog zum Problem der Ledger-Lokalisierung. Wenn ein Benutzer sagt: "Korrigiere die Überbewertung bei den Bürobedarfsartikeln in Q3", muss der Agent zuerst die relevanten Einträge in einer Datei finden, die tausende Zeilen enthalten kann — dieselbe Datei-Lokalisierungsaufgabe, bei der BM25 in 40–50 % der SWE-bench-Instanzen versagt. Die "Lost in the Middle"-Degradierung gilt gleichermaßen für lange .beancount-Dateien, in denen früher datierte Einträge ebenso leicht ignoriert werden können.

Die Asymmetrie der Patch-Länge ist eine praktische Warnung. Modelle patchen zu engstirnig. In der Buchhaltung bedeutet dies, dass ein Eintrag korrigiert wird, während die Gegenbuchung vergessen wird, oder dass die Ausgabenzeile aktualisiert wird, während der laufende Saldo veraltet bleibt. Ein produktiver Beancount-Agent benötigt eine Validierungsebene — bean-check, Salden-Assertionen oder einen expliziten Reconciliation-Durchlauf —, die den Agenten zwingt, die vollen Konsequenzen seines Edits zu sehen, nicht nur dessen lokale Plausibilität.

Die Lücke zwischen Oracle und BM25 erinnert zudem daran, dass Retrieval-Qualität nicht von der Agenten-Qualität trennbar ist. Ein Agent, der nicht zuverlässig identifizieren kann, welche Konten oder Dateien für die Frage eines Benutzers relevant sind, wird bereits beim Navigieren im Hauptbuch scheitern, bevor er überhaupt einen Edit versucht.

Was man als Nächstes lesen sollte

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — das direkte Follow-up; steigert die Quote von 1,96 % auf 12,47 % durch Neugestaltung der Agent-Computer-Schnittstelle. Die Designprinzipien für Dateinavigation und Codesuche sind direkt auf Beancount-Agent-Tools übertragbar.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — reduziert die Agenten-Komplexität und zeigt, dass eine einfache Lokalisierungs- und Reparatur-Pipeline ohne großes Gerüst wettbewerbsfähig sein kann; ein nützlicher Gegenpol zu schnittstellenlastigen Ansätzen.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — adressiert das Problem langer Kontexte direkt mit abgestuftem Speichermanagement; unmittelbar relevant für Agenten, die über mehrjährige Beancount-Ledger hinweg schlussfolgern müssen.