Kronumos 2 Kairos: Cost-Bounded Automated Program Repair via Dual-Brain Cybernetic Sub-Cortex on SWE-bench Verified

Die Softwarewartung ist eine stille, massive Industrie, die mehr als sechzig Prozent des weltweiten Engineering-Budgets verschlingt. Es ist die Arbeit, kaputte Teile in komplexen digitalen Systemen zu finden und sie zu reparieren, ohne die Teile zu beschädigen, die noch funktionieren. Jahrzehntelang war dies eine menschliche Aufgabe, die tiefes Wissen darüber erforderte, wie verschiedene Code-Dateien miteinander kommunizieren. Vor kurzem haben Computerprogramme, die auf riesigen Mengen an Code trainiert wurden, begonnen, diese Arbeit selbst zu versuchen. Diese Programme, bekannt als Large Language Models, können eine Beschreibung eines Problems lesen und einen Fix vorschlagen. Wenn diese Modelle jedoch versuchen, reale Software zu reparieren, scheitern sie oft. Sie verlieren sich in der schieren Menge an Informationen, machen subtile Formatierungsfehler, die dazu führen, dass der Computer ihre Arbeit ablehnt, und tun dies zu einem hohen finanziellen Aufwand, da jeder Versuch oft teure Cloud-Computing-Leistung erfordert.

Eine neue Studie stellt einen anderen Ansatz für dieses Problem vor, der Präzision und Kosteneffizienz über Brute-Force priorisiert. Die Forscher entwickelten ein System namens Kronumos 2 Kairos, das darauf ausgelegt ist, als chirurgisches Werkzeug statt als breite Suchmaschine zu fungieren. Anstatt einen Computer-Modell durch eine Codebasis wandern und immer wieder raten und prüfen zu lassen, zwingt dieses System das Modell dazu, sich auf eine sehr spezifische, enge Aufgabe zu konzentrieren. Es kombiniert ein mittelgroßes Open-Source-Computermodell mit einer starren, regelbasierten Engine, die als strenger Qualitätskontrolleur fungiert. Das Ziel war es zu sehen, ob ein kleineres, günstigeres Modell Softwarefehler in realer Software beheben kann, wenn es vor seiner eigenen Tendenz zu unvorsichtigen Fehlern geschützt wird und wenn es daran gehindert wird, Ressourcen für unnötige Schritte zu verschwenden. Die Forscher testeten dieses System an einem Benchmark von fünfhundert realen Softwareproblemen, einem Standarddatensatz von Herausforderungen, der zur Messung der Fähigkeit künstlicher Intelligenz zur Reparatur von Code verwendet wird.

Das System arbeitet, indem es die Arbeit in zwei unterschiedliche Teile aufteilt. Der erste Teil ist der „kognitive Kortex“, das Computermodell, das für das Verständnis des Problems und das Schreiben des Code-Fixes verantwortlich ist. Der zweite Teil ist der „Sub-Kortex“, eine deterministische Engine, die in einer Sprache geschrieben ist, die exaktes, vorhersagbares Verhalten garantiert. Dieser Sub-Kortex fungiert als Filter und Formatter. Bevor das Modell das Problem überhaupt sieht, entfernt der Sub-Kortex tausende Zeilen irrelevanten technischen Rauschens, das Fehlermeldungen normalerweise überflutet. Er entfernt sensible Informationen wie Passwörter und API-Keys, um die Privatsphäre zu gewährleisten. Er nimmt dann die Ausgabe des Modells entgegen und prüft sie gegen die strengen Regeln, wie Code-Patches geschrieben werden müssen. Wenn das Modell einen Fehler bei den Zeilennummern, der Einrückung oder der Formatierung des Fixes macht, erkennt der Sub-Kortex dies sofort. Er korrigiert den Fehler entweder oder weist den Patch vollständig ab, um sicherzustellen, dass niemals ein fehlerhafter oder schlecht geformter Code für Tests eingereicht wird. Dieser Prozess verhindert, dass das System Zeit mit Versuchen verschwendet, die aufgrund einfacher Formatierungsfehler zum Scheitern verurteilt sind.

Die Forscher ließen dieses System gegen die fünfhundert realen Softwareprobleme laufen. Die Ergebnisse zeigten, dass das System acht dieser Bugs erfolgreich lösen konnte. Während acht von fünfhundert klein erscheinen mag, liegt die Bedeutung darin, wie das System dies erreichte. Die Forscher verwendeten ein Modell mit nur sieben Milliarden Parametern, was signifikant kleiner ist als die massiven Modelle, die von kommerziellen Unternehmen genutzt werden und oft tausende Dollar kosten. Durch die Verwendung ihrer Dual-Brain-Architektur gelang es dem System, diese Probleme mit einem Grenzkosten von Null für die genutzte Rechenleistung zu lösen. Die durchschnittliche Menge an Daten, die das System pro Aufgabe verarbeitete, lag bei etwas über zweitausend Token – ein Wert, der neununddreißig Prozent niedriger ist als die Hunderttausende von Token, die typischerweise von anderen automatisierten Reparatursystemen verbraucht werden. Diese drastische Reduktion des Datenverbrauchs bedeutet, dass das System weitaus effizienter und skalierbarer ist als aktuelle Alternativen.

Eine entscheidende Erkenntnis der Studie war die Bedeutung der strengen Qualitätskontroll-Engine. Als die Forscher die Fähigkeit des Sub-Kortex entfernten, Formatierungsfehler nach dem Schreiben des Codes zu korrigieren, sank die Zahl der erfolgreichen Reparaturen von acht auf sechs. Dies demonstrierte, dass ein erheblicher Teil der Fehler des Modells nicht auf mangelndem Verständnis beruhte, sondern auf geringfügigen, korrigierbaren Fehlern in der Präsentation des Codes. Der Sub-Kortex fungierte als Sicherheitsnetz, das diese Fehler auffing und sicherstellte, dass die logischen Lösungen, die das Modell fand, tatsächlich in einem nutzbaren Format geliefert wurden. Das System bewies auch, dass es ohne das Ausführen der Softwaretests während des Reparaturprozesses arbeiten konnte. Anstatt den Fix auszuprobieren und zu sehen, ob er funktioniert, verließ sich das System auf seine internen Regeln, um sicherzustellen, dass der Fix strukturell solide war, bevor er überhaupt angewendet wurde.

Die Forscher evaluierten das System über vier verschiedene Software-Ökosysteme hinweg, einschließlich großer Projekte wie Django und Scikit-Learn. Die acht erfolgreichen Reparaturen deckten eine Vielzahl von Problemen ab, von der Behebung eines Absturzes in einem Datenbank-Migrationswerkzeug bis hin zur Korrektur eines mathematischen Fehlers in einer Datenanalyse-Bibliothek. In einem Fall behob das System einen Bug, bei dem ein Programm abstürzte, wenn eine bestimmte Einstellung fehlte; das Modell identifizierte korrekt, dass der Code prüfen musste, ob die Einstellung abwesend ist, bevor er versucht, sie zu verwenden. In einem anderen Fall behob es ein Problem, bei dem ein Programm versehentlich Daten änderte, die es eigentlich unverändert lassen sollte. Die Forscher inspizierten jeden erfolgreichen Fix manuell, um zu bestätigen, dass die Logik korrekt war und die Lösung nicht nur ein glücklicher Zufall war.

Die Forscher räumen ein, dass ihr System keine vollständige Lösung für alle Softwarefehler ist. Das Modell kämpft immer noch mit sehr komplexen Problemen, die tiefes Denken über viele verschiedene Dateien hinweg erfordern oder abstrakte Konzepte betreffen, die über sein Training hinausgehen. Dennoch etabliert die Studie einen neuen Maßstab dafür, was mit kleineren Open-Source-Modellen möglich ist. Sie zeigt, dass es durch die Kombination eines fähigen, aber bescheidenen Computermodells mit einem starren, regelbasierten System, das strenge Standards erzwingt, möglich ist, zuverlässige Ergebnisse zu erzielen, ohne die massiven Kosten, die mit aktuellen State-of-the-Art-Systemen verbunden sind, zu verursachen. Die Arbeit legt nahe, dass die Zukunft der automatisierten Reparatur nicht davon abhängen könnte, Modelle unendlich größer zu machen, sondern bessere Systeme zu bauen, die sie leiten und ihre Fehler abfangen.

Diese Forschung bietet einen klaren Weg nach vorn, um automatisierte Softwarereparatur zugänglich und erschwinglich zu machen. Indem sie beweist, dass ein System reale Bugs mit null Kosten und hoher Effizienz beheben kann, stellt die Studie die Vorstellung infrage, dass nur die teuersten, leistungsstärksten Modelle diese Arbeit leisten können. Der Erfolg des Dual-Brain-Ansatzes unterstreicht den Wert der Trennung zwischen der kreativen Aufgabe des Codewriting und der mechanischen Aufgabe, sicherzustellen, dass die Regeln eingehalten werden. Während sich das Feld der automatisierten Reparatur weiterentwickelt, bietet diese Arbeit ein praktisches Beispiel dafür, wie man Intelligenz mit Disziplin ausbalanciert und sicherstellt, dass die Werkzeuge, die wir zur Reparatur unserer Software bauen, selbst robust, zuverlässig und effizient sind.