← Neueste Arbeiten
💻 computer science

ChainSWE: Benchmarking Coding Agents on Multi-Bug Software Maintenance

Dieses Paper stellt ChainSWE vor, den ersten Benchmark, der darauf ausgelegt ist, Coding-Agenten bei sequenziellen, abhängigen Fehlerbehebungen innerhalb einer gemeinsamen Codebasis zu evaluieren, wobei aufgezeigt wird, dass die Leistung der Agenten mit zunehmender Kettenlänge im Vergleich zu herkömmlichen, isolierten Evaluierungen der Fehlerbehebung signifikant abnimmt.

Ursprüngliche Autoren: Qirui Jin, Lingching Tung, Kenan Li, Qiyang Shi, Yushi She, Huanzhong Jia, Harrison Zhao, Kejing Xia, Zhenbang Du, Yikai Zhang, Jiaxin Pei, Zhenyu Zhang, Zhen Qi, Yuyan Duan, Wenke Lee, Zijian Jin

Veröffentlicht 2026-07-07
📖 5 Min. Lesezeit🧠 Tiefgang

Ursprüngliche Autoren: Qirui Jin, Lingching Tung, Kenan Li, Qiyang Shi, Yushi She, Huanzhong Jia, Harrison Zhao, Kejing Xia, Zhenbang Du, Yikai Zhang, Jiaxin Pei, Zhenyu Zhang, Zhen Qi, Yuyan Duan, Wenke Lee, Zijian Jin

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: Von „Einmal und fertig“ zu „Der Langstreckenlauf“

Stellen Sie sich vor, Sie stellen ein Team von superintelligenten Roboter-Mechanikern ein, um eine Flotte von Autos zu reparieren.

Der alte Weg (Aktuelle Benchmarks):
Jedes Mal, wenn Sie einem Mechaniker ein Problem geben, überreichen Sie ihm ein brandneues, makelloses Auto. Er repariert einen platten Reifen, Sie überprüfen seine Arbeit, und dann schicken Sie ihn nach Hause. Am nächsten Tag geben Sie ihm ein anderes Auto mit einem anderen Problem.

  • Das Problem: Dies testet nicht, ob sie gut darin sind, ein Auto über einen längeren Zeitraum zu wartend. In der realen Welt bekommen Mechaniker nicht jeden Tag ein neues Auto. Sie arbeiten am selben Auto, reparieren erst einen platten Reifen, dann eine quietschende Bremse, dann ein seltsames Motorengeräusch, alles am selben Fahrzeug.

Der neue Weg (CHAINSWE):
Die Forscher haben einen neuen Test namens CHAWE entwickelt. Anstatt den Mechanikern neue Autos zu geben, geben sie ihnen ein Auto und eine Liste von 304 Problemen, die über mehrere Jahre hinweg aufgetreten sind.

  • Der Mechaniker behebt das erste Problem.
  • Dann, ohne das Auto zurückzusetzen, muss er das zweite Problem basierend auf dem Zustand des Autos nach der ersten Reparatur beheben.
  • Dann das dritte, und so weiter.

Die zwei Hauptgründe, warum Roboter scheitern

Die Arbeit fand heraus, dass Roboter, wenn sie versuchen, eine lange Liste von Problemen am selben Code (dem „Auto“) zu beheben, zwei spezifische Arten von Fehlern machen, die sie bei der Behebung einzelner Probleme nicht machen:

1. Der „Über-Dekorierer“-Fehler (Overshoot)

  • Das Szenario: Dem Roboter wird gesagt, er soll einen undichten Wasserhahn reparieren. Er repariert den Wasserhahn perfekt. Aber in seiner Begeisterung streicht er auch die Küchenschränke neu und tauscht die Bodenfliesen aus, obwohl niemand darum gebeten hat.
  • Die Konsequenz: Später kommt ein Mensch herein, um einen defekten Lichtschalter zu reparieren. Da der Roboter zuvor die Bodenfliesen und Schränke geändert hat, ergeben die Anweisungen für den Lichtschalter nicht mehr Sinn. Die „zusätzliche“ Arbeit des Roboters hat die nächste Aufgabe unbrauchbar gemacht.
  • In der Arbeit: Der Roboter ändert Dateien, die er eigentlich nicht hätte anfassen sollen, was die Tests für zukünftige Bugs unterbricht.

2. Der „Halbe-Sache“-Fehler (Undershoot)

  • Das Szenario: Dem Roboter wird gesagt, er soll einen undichten Wasserhahn reparieren. Er erkennt, dass der Wasserhahn sowohl ein neues Rohr als auch ein neues Ventil benötigt, damit er funktioniert. Er ersetzt jedoch nur den Griff des Wasserhahns (weil das in der Notiz stand) und lässt das kaputte Rohr und das Ventil unberührt.
  • Die Konsequenz: Der Wasserhahn sieht repariert aus, aber er tropft immer noch. Später versucht ein Mensch, den Wasserdruck zu regulieren. Da der Roboter das Rohr zuvor nicht repariert hat, schlägt die Reparatur des Wasserdrucks komplett fehl.
  • In der Arbeit: Der Roboter behebt die spezifische Datei, die im Bug-Report erwähnt wird, vergisst aber, die unterstützenden Dateien zu aktualisieren, die im Bug-Report nicht explizit erwähnt wurden, wodurch der Code in einem defekten Zustand bleibt, der für den nächsten Bug ungeeignet ist.

Was geschah, als sie die Roboter testeten?

Die Forscher testeten 7 verschiedene „KI-Mechaniker“ (Sprachmodelle) mit diesem neuen „Langstrecken“-Test.

  • Die Ergebnisse: Wenn die Roboter an einzelnen Bugs arbeiteten (der alte Weg), waren sie ziemlich gut (etwa 60 % Erfolgsquote). Aber wenn sie eine Kette von Bugs bearbeiten mussten (der neue Weg), sank ihre Leistung um bis zu 70 %.
  • Die „Kettenreaktion“: Je tiefer sie in die Liste der Bugs vordrangen, desto schlechter wurden sie. Bis sie den 3. oder 4. Bug in Folge erreichten, scheiterten sie fast ständig.
  • Warum? Die Roboter wurden durch ihre eigene vorherige Arbeit verwirrt. Sie konnten sich nicht erinnern, welche Dateien sie geändert hatten, oder sie vergaßen, dass ihre früheren „Schnellreparaturen“ das Fundament für die nächste Aufgabe zerstört hatten.

Half „Gedächtnis“?

Die Forscher versuchten, den Robotern zu helfen, indem sie ihnen verschiedene Wege gaben, sich an das zu erinnern, was sie getan hatten:

  1. Vollständiges Gedächtnis: Das Lesen der gesamten Historie von allem, was sie jemals gesagt/getan haben.
  2. Zusammenfassendes Gedächtnis: Den Roboter bitten, eine kurze Zusammenfassung dessen zu schreiben, was er zuvor getan hat.
  3. Helfer-Roboter: Einen kleinen Roboter nutzen, der die Dateieditierung übernimmt, während der Hauptroboter nur Anweisungen gibt.

Die Überraschung: Keiner dieser Tricks half wirklich viel. Tatsächlich machte es die Dinge oft sogar schlechter, den Roboter zu bitten, seine Arbeit zusammenzufassen oder einen Helfer zu benutzen. Die Roboter konnten einfach nicht mit dem „Chaos“ umgehen, das sie im Code verursacht hatten, egal wie sehr sie versuchten, sich zu erinnern.

Das Fazit

Die Arbeit kommt zu dem Schluss, dass wir KI-Coder derzeit so testen, als wären sie „One-Hit-Wonder“ (sie reparieren eine Sache und gehen dann). Aber in der Realität ist die Softwarewartung ein Marathon und kein Sprint.

Um eine KI zu bauen, die tatsächlich Software warten kann, müssen wir aufhören, sie auf isolierten Aufgaben zu testen, und statetnddessen auf Ketten von Aufgaben testen, bei denen sie mit dem unordentlichen, unvollkommenen Code umgehen müssen, den sie selbst erschaffen haben. Momentan haben selbst die klügsten KI-Modelle Schwierigkeiten, eine Codebasis sauber zu halten, wenn sie nach dem anderen einen Bug beheben müssen.

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.

Digest testen →