Ohne Agent: 4 Schritte zur Behebung echter Bugs, Ant CGM erreicht Spitzenplatz in der Open-Source-Liste von SWE-Bench

Das agentlose und Open-Source-Modell kann auch hochwertige Code-Reparaturaufgaben auf Repository-Ebene erledigen, und die Ergebnisse sind mit dem Stand der Technik (SOTA) in der Branche vergleichbar.

1. Agentlos, 44 % und Platz 1

Wenn es um die Fähigkeiten von KI beim Schreiben von Code geht, interessiert man sich am meisten für die Frage: Kann die KI wirklich Bugs beheben?

Der erste vollautomatische KI-Softwareingenieur Devin hat die technologische Szene von Anfang an auf den Kopf gestellt, und seine Stellung in der Branche wurde auf der autoritativen Referenzbasis SWE-Bench weiter bestätigt –

Er hat 13,86 % der Probleme unabhängig gelöst, weit vor GPT-4 mit nur 1,7 % und Claude2 mit nur 4,8 %.

Kurz darauf hat Genie in demselben Test die Punktzahl direkt auf 30,08 % erhöht und war für eine Zeit der weltweit stärkste KI-Programmierer.

Warum hat SWE-Bench die breite Aufmerksamkeit von Industrie, Wissenschaft und Startup-Teams erregt? Weil es realistisch ist.

Dieser von der Princeton University vorgeschlagene Testsatz besteht ausschließlich aus echten GitHub-Projekten –

Die Probleme sind entweder Bugs, die Entwickler in der Produktionsumgebung begegnet sind, oder typische Anforderungen bei der Funktionsentwicklung. Sie sind schwierig und der Kontext ist komplex, was den Arbeitszustand von Programmierern bei der realen Entwicklung so gut wie möglich wiedergibt.

Mit anderen Worten, ein Modell, das in SWE-Bench eine hohe Punktzahl erzielt, muss die komplexen Fähigkeiten und Erfahrungen eines erfahrenen Softwareingenieurs haben, die in herkömmlichen Codegenerierungs-Benchmarks schwer abgedeckt werden können.

Angesichts der hohen Schwierigkeit von SWE-Bench hat das Team auch eine etwas einfachere Teilmenge namens SWE-Bench Lite vorgeschlagen. Dennoch ist die Schwierigkeit immer noch hoch.

Alle derzeitigen SOTA-Modelle in der Branche basieren auf Closed-Source-Modellen, und die meisten der führenden Kandidaten in der Rangliste sind „luxuriöse Kombinationen“:

Closed-Source-Großmodelle (z. B. GPT-4o, Claude3.5) + Agent-Architektur (z. B. SWE-Agent), deren Fähigkeiten durch große Datenmengen und komplexe Schedulingsysteme „aufgebaut“ werden.

In letzter Zeit hat die Ant Group einen völlig anderen Ansatz gewählt und eine neue Lösung vorgeschlagen: Das Code-Graph-Modell CGM (Code Graph Model), das auf einem Open-Source-Modell basiert und eine Leistung erzielt, die mit Closed-Source-Modellen vergleichbar ist –

Auf der öffentlichen Rangliste von SWE-BenchLite kann CGM 44 % der Probleme erfolgreich lösen, schlägt alle Open-Source-Modelle und belegt Platz 1; in der Rangliste der Open-Source-Systeme belegt es Platz 6.

Schlägt alle Open-Source-Modelle und belegt Platz 1

In der Rangliste der Open-Source-Systeme belegt es Platz 6.

Ergebnisse auf der SWE-BenchLite-Testplattform

Genauer gesagt, hat das neu veröffentlichte Open-Source-Modell CGM auf SWE-Bench drei Durchbrüche erzielt –

Erstens bricht es die Monopolstellung der Closed-Source-Modelle. Zum ersten Mal kann ein Open-Source-Großmodell wie Qianwen eine Leistung erzielen, die mit SOTA vergleichbar ist, und die Code-Graph-Daten für das Training werden gleichzeitig veröffentlicht.

Zweitens verzichtet es auf die komplexe Agent-Architektur und benötigt nur einen 4-Schritt-leichten GraphRAG-Prozess, um effiziente Problemfindung und -reparatur zu erreichen.

Drittens ermöglicht es erstmals einem Großmodell, die Code-Graph-Struktur auf Repository-Ebene direkt zu verstehen, verbindet die beiden Modalitäten Code und Graph und ermöglicht es dem Modell, den Kontext auf Repository-Ebene vollständig zu verstehen.

Derzeit ist CGM offiziell als Open-Source-Modell verfügbar. Das Modell, der Code und der Datensatz können auf HuggingFace und GitHub abgerufen werden:

Paper: https://arxiv.org/abs/2505.16901

Modell: https://huggingface.co/codefuse-ai/CodeFuse-CGM-72B

Code: https://github.com/codefuse-ai/CodeFuse-CGM

Daten: https://huggingface.co/datasets/codefuse-ai/CodeGraph

Tatsächlich hat CGM nie vor starken Konkurrenten zurückgewichen.

Schon im Oktober 2024 hat es mit einer Problemlösungsrate von 35,67 % den ersten Platz in der Open-Source-Rangliste von SWE-Bench Lite errungen;

Zwei Monate später hat es erneut den ersten Platz belegt, und die Problemlösungsrate ist auf 41,67 % gestiegen.

Und die neueste Version hat dieses Mal den Rekord erneut gebrochen, mit einer Problemlösungsrate von 44 %, was einer „dreifachen Niederlage“ im Open-Source-Segment entspricht.

2. LLM + Agent-Architektur? Sieht schön aus

Das Schreiben von Code ist sozusagen ein „angeborenes Talent“ von KI-Großmodellen. Nach dem Erfolg von ChatGPT haben verschiedene KI-Code-Assistenten sich schnell in die täglichen Arbeitsabläufe von Programmierern integriert.

Im September 2023 hat die Ant Group den KI-Code-Assistenten CodeFuse vorgestellt und erklärt, dass er den gesamten Lebenszyklus der Softwareentwicklung unterstützen soll, einschließlich der Schlüsselphasen Design, Anforderungen, Codierung, Testen, Deployment und Wartung.

Nach zwei Jahren Entwicklung hat CodeFuse allmählich ein relativ komplettes Ökosystem aufgebaut. Darin ist das CGM (Code Graph Model) zur Bearbeitung von Aufgaben auf Repository-Ebene einer der Schlüsselstützpunkte geworden.

In der realen Entwicklung ist es nicht das Schreiben einiger Funktionen, was echte Herausforderungen für Code-Modelle darstellt, sondern Aufgaben auf Repository-Ebene wie das Beheben von Issues und das Reviewen von Code. Ein großes Projekt kann leicht Tausende von Codezeilen, Hunderte von Dateien und Tausende von Funktionen umfassen. Die Vererbung und Aufrufbeziehungen zwischen Klassen und Modulen sind komplex – eine einzige Codezeile kann einen großen Einfluss haben. Es scheint, dass nur eine Funktion geändert wird, aber tatsächlich muss man ein ganzes „Wald“ von Code verstehen.

Um diese komplexen Aufgaben zu lösen, ist der derzeitige Hauptweg in der Branche die LLM-Agent-Architektur.

Beispielsweise, wenn ein Benutzer fragt: „Wie füge ich einen Löschbutton hinzu?“ oder „In welcher Funktion befindet sich die Passwortüberprüfungslogik?“, wird das System automatisch mehrere Agenten koordiniert, die jeweils ihre Aufgaben erfüllen. Gleichzeitig werden Operationen wie das Teilen des Codes im Repository, die Berechnung von Embeddings und die semantische Suche durchgeführt, um schließlich den relevanten Code abzurufen und Antworten oder Änderungsvorschläge zu generieren.

Aber dieses Verfahren hat nicht nur Einschränkungen bei der Zugänglichkeit des Modells, sondern hat auch viele „versteckte Bugs“ in realen Szenarien aufgedeckt.

Erstens sind die Softwareentwicklungsprojekte oft komplex.

Die scheinbar einfache Anforderung „Wie füge ich einen Löschbutton hinzu?“ beinhaltet mehrere Agenten („Knoten“). Je mehr Knoten es gibt, desto weniger kontrollierbar wird das System. Ein Fehler in einem Knoten (z. B. die falsche Identifizierung der Dateiposition oder die Rückrufung von irrelevantem Code) kann den nachfolgenden Prozess beeinflussen und zu einer Akkumulation von Fehlern führen.

Außerdem steigen mit der Anzahl der Agenten die Ausführungswege und die Kommunikations- und Rechenkosten.

Zweitens halten die Trainingsdaten nicht mit der Systemkomplexität Schritt.

Testdatensätze wie SWE-Bench sind zwar realistisch und autoritativ, aber sie bieten nur End-zu-End-Beispiele – nur der Startpunkt (das Problem) und das Ziel (die Reparatur) sind markiert. Informationen über den Weg, wie die Agenten die Aufgabe zerlegen und zusammenarbeiten, fehlen oft.

Mit anderen Worten, die Aufgaben werden detaillierter, aber die Daten bleiben grob. Die Schwierigkeit des Trainings steigt stattdessen.

Drittens hat die herkömmliche Methode des „linearen Lesens“ von Code durch Sprachmodelle ihre eigenen Grenzen.

Die herkömmliche Vorgehensweise „ebnet“ normalerweise die gesamte Datei zu einer langen Token-Reihe und ignoriert die natürliche Struktur des Codes. Ein Code-Repository ist im Wesentlichen eher wie ein Graph – die Aufrufe zwischen Funktionen, die Vererbung zwischen Klassen und die Abhängigkeiten zwischen Modulen sind komplex, aber die Regeln sind klar.

Um einem Großmodell echte Verständnisfähigkeiten auf Repository-Ebene zu verleihen, ist ein machbarer technologischer Weg, die Struktur direkt in das Modell einzufügen.

3. Der agentlose Ansatz mit „Strukturawareness“

Is es möglich, Aufgaben auf Repository-Ebene effizient mit einem Open-Source-Großmodell zu erledigen, ohne auf Agenten angewiesen zu sein? Das Team für alle Code-Algorithmen der Ant Group hat die Antwort gefunden und das CGM (Code Graph Model) vorgeschlagen –

Anstatt auf eine komplizierte Agenten-Scheduling zu setzen, führt es erstmals die Graphstruktur des Code-Repositories als Modus direkt in das Großmodell ein und erfasst so auf einmal die komplexen Beziehungen wie Funktionsaufrufe, Modulabhängigkeiten und Klassenvererbung.

Das ist wie ein Paar „Ingenieurbrille“ für das Großmodell, das die verschiedenen Beziehungen zwischen Codeentitäten (Dateien, Klassen, Funktionen, Variablen usw.), die sonst verborgen wären, sofort sichtbar macht.

Die Realisierung dieser Fähigkeit beruht auf drei Schlüsseldurchbrüchen.

1. Modellierung von Code-Graphen mit mehreren Granularitäten zur Erfassung von Strukturinformationen

CGM modelliert das Code-Repository als Graphdatenstruktur. Um die Graphstrukturinformationen des Repositories zu erfassen, wandelt das Team zunächst mithilfe von Programmanalyse-Techniken das gesamte Code-Repository in einen entsprechenden Code-Graphen um (siehe Abbildung 1). Die Knoten- und Kantenarten im Code-Graphen sind wie folgt:

Knotentypen: Umfasst 7 Arten von Codeentitäten (REPO / PACKAGE / FILE / TEXTFILE / CLASS / FUNCTION / ATTRIBUTE)

Kantentypen: Enthält 5 Arten von Abhängigkeitsbeziehungen (contains / calls / imports / extends / implements)

Abbildung 1: Code-Graph des Repositories

Im Code-Graphen erfasst die „contains“-Kante die hierarchischen Abhängigkeiten zwischen Codeentitäten, während die anderen Kantenarten die semantischen Abhängigkeiten erfassen. Bei der Erstellung des Code-Graphen werden auch komplexe Abhängigkeiten behandelt.

Vererbung: Unterstützt die Analyse von Mehrfachvererbung (basierend auf dem CHA-Algorithmus).

Aufruf: Analysiert dynamische Aufrufe konservativ, um die Vollständigkeit der semantischen Abhängigkeiten sicherzustellen.

Diese Modellierungsart unterstützt derzeit Python und Java.

Durch die Modellierung wird der ursprünglich lose Code zu einem strukturierten und gerichteten Netzwerk organisiert. CGM kann wie ein Programmierer, der ein unbekanntes Repository zum ersten Mal liest, schnell ein „Code-Abhängigkeitsdiagramm“ im Kopf erstellen und sehen, wer wen aufruft und wer wen beeinflusst.

2. Zwei-Phasen-Training für die Tiefe Integration von Struktur und Semantik

Nachdem die Graphstruktur vorhanden ist, muss das LLM nun beigebracht werden, sie zu „lesen“: Es muss nicht nur die Semantik einzelner Knoten verstehen, sondern auch effizient auf der Graphstruktur schließen können, um eine tiefe Integration von Struktur und Semantik zu erreichen.

Zunächst codiert CodeT5+ die semantische Information jedes Knotens und bildet sie über einen Adapter in den Eingangsraum des Großmodells ab, um sicherzustellen, dass das Großmodell den Textinhalt der Knoten verstehen kann (Semantische Anpassung);

Zweitens wird die Adjazenzmatrix des Graphen in eine Graph-aware Attention Mask umgewandelt, die die Standard-kausale Attention Mask im LLM beim Verarbeiten der Knoten-Tokens ersetzt.

Diese Änderung simuliert geschickt den „Message Pass