Großes Modell versteht Code-Grafiken direkt zum ersten Mal: Repariert automatisch Bugs ohne Agent und führt die offenen Modell-Liste von SWE-Bench an.

AI repariert automatisch Bugs mit einer Lösungswahrscheinlichkeit von 44%! Dies ist das neueste und stärkste Niveau globaler Open-Source-Modelle.

Ein neues Open-Source-Modell von Ant übertrifft auf SWE-bench Lite alle Open-Source-Lösungen und ist in der Leistung mit Closed-Source-Modellen vergleichbar.

Die genauen Leistungen auf SWE-bench Lite sind wie folgt:

• Es belegt in allen Open-Source-Modellmethoden (Open Weight Model) den ersten Platz;
• Es belegt in allen Open-Source-Systemmethoden (Open Source Syestem) den sechsten Platz;
• Es belegt in der Gesamtranking den 14. Platz;
• Es ist 7,33% besser als das bisher beste Open-Source-Modell "KGCompass" in der Rangliste.

Sie haben erstmals die Code-Graph-Modality des Repositories in das Large Language Model integriert (Code Graph Model, CGM), sodass das Large Language Model direkt Code-Graphen verstehen kann und Bugs effizienter reparieren und Code vervollständigen kann.

Dadurch wird die Abhängigkeit von Black-Box-Modellen (wie GPT-4 oder Claude 3.7) und komplexen Agent-Arbeitsabläufen vollständig beseitigt, und eine kontrollierbarere, transparentere und sicherere SE-Automatisierung wird erreicht.

Außerdem basiert CGM vollständig auf Open-Source-Modellen. Man muss bedenken, dass Open-Source-Modelle normalerweise auf SWE-bench nicht gut abschneiden. Bisher wurden fast alle SOTA-Lösungen auf der Grundlage von Closed-Source-Modellen realisiert. CGM basiert auf dem Qwen-Modell und erreicht ein Niveau, das mit Closed-Source-Modellen vergleichbar ist.

CGM kann in nur 4 Schritten schnell den Fehlerort finden und einen Patch generieren, wodurch der komplexe Orchestrierungsprozess in der Agent-Lösung entfällt und die Effizienz steil ansteigt.

AI das Verständnis von Large Language Model-Code-Repositories vermitteln

Seit dem Aufkommen der Large Language Model-Trends ist die AI-Programmierung rapide gewachsen, insbesondere bei kleinen Aufgaben wie dem Schreiben von Funktionen. Beispielsweise erreichen viele Modelle auf Benchmarks wie HumanEval eine Genauigkeit von über 90%.

Die reale Softwareentwicklung ist jedoch weitaus komplexer als das "Schreiben einer Funktion". Aufgaben wie die Bugbehebung und die Funktionsverbesserung erfordern normalerweise Operationen über Dateien und Module hinweg und verlangen, dass das Modell die komplexe Struktur, die Abhängigkeiten und die Klassenvererbungssysteme in einem Projekt versteht.

Die derzeitigen Mainstream-Methoden verwenden normalerweise Agenten auf der Grundlage von Closed-Source-Modellen. Sie können das Verhalten menschlicher Programmierer simulieren, wie das Beobachten von Code, das Aufrufen von Tools und die mehrmalige Interaktion, um Aufgaben zu erfüllen.

Aber diese Methoden haben auch einige Probleme:

• Der Verhaltenspfad ist nicht kontrollierbar, und es kommt leicht zu Akkumulation von Inferenzfehlern;
• Sie sind von Closed-Source-Modellen wie GPT-4 und Claude abhängig und sind schwierig für private Bereitstellungen oder Anpassungen geeignet;
• Die Entwicklungskosten sind hoch und die Effizienz ist gering.

Zur gleichen Zeit ist es für aktuelle Open-Source-Modell-Lösungen schwierig, SOTA-Niveaus zu erreichen.

Deshalb hat das Forschungsunternehmen gefragt: Kann man Repository-Level-Aufgaben nur mit Open-Source-Modellen und ohne Abhängigkeit von Agenten lösen? So entstand CGM.

Tiefe Integration von Graphenstruktur und Large Language Model

CGM verwendet eine Cross-Modality-Modellierung ähnlich dem Vision-Language Model (VLM). Es kombiniert die Textverständnisfähigkeit des traditionellen LLM mit der Strukturkarte (Graph) des Code-Repositories, um ein Graph-Sprache-Multimodal-Modell zu bilden. Der Kern des Modells integriert zwei Modalitäten:

• Graph-Modality: Das Repository wird als strukturierter Graph aufgebaut, wobei die Knoten sieben Typen wie Funktionen, Klassen, Dateien und Pakete umfassen, und die Kanten Abhängigkeiten wie Aufrufe, Enthaltensein und Vererbung darstellen;
• Sprach-Modality: Die natürliche Sprachbeschreibung und der Code-Hinweis, die vom Benutzer eingegeben werden, treiben das Modell an, Patches zu generieren oder Fragen zu beantworten.

Der Eingang des Modells ist ein Code-Graph und ein Prompt in Textform, und die Struktur-Semantik wird im LLM in einer Zwei-Modality-Anpassung durchgeführt.

Die genaue Methode zur Integration der Struktur ist wie folgt:

Ein kleiner Encoder (CodeT5+) wird verwendet, um jeden Knoten zu codieren und ihn in ein einzelnes "Knoten-Token" zu komprimieren. Innerhalb jedes Knotens wird der Text in Blöcke von maximal 512 Tokens aufgeteilt.

Über einen Adapter (ein zweischichtiges MLP) wird die codierte Knotenrepräsentation in den Eingabe-Einbettungsraum des LLM abgebildet. Das entspricht einer 512-fachen Erweiterung des LLM-Kontexts, was es ermöglicht, den riesigen Code-Repository-Kontext besser zu verarbeiten.

Ein Graph-aware Attention Mask wird verwendet. Anstelle der ursprünglichen kausalen Attention im LLM wird die Attention-Mechanik nur auf benachbarte Knoten angewandt. Ähnlich dem Nachrichtenübertragungsmechanismus von GNN kann das LLM direkt die strukturellen Abhängigkeiten des Codes wahrnehmen und nutzen.

Zweistufiges Training: Strukturverständnis + Problemgeneralisierung

Basierend auf dieser Modellarchitektur hat das Team durch zweistufiges Training ermöglicht, dass das LLM die Topologie des Code-Graphen verstehen kann.

Stufe 1: Pretraining der Subgraph-Rekonstruktion

Um zu trainieren, dass CGM die semantischen und strukturellen Informationen des Code-Graphen effektiv erfasst, hat das Team eine "Graph-to-Code"-Aufgabe entworfen. Es werden zufällig Subgraphen aus einem großen Code-Graphen ausgewählt (die Anzahl der Knoten wird begrenzt, um die Länge des ausgegebenen Codes zu kontrollieren). Das Modell muss auf der Grundlage dieser eingegebenen Subgraphen (die nur die Knotentypen und Verbindungsbeziehungen enthalten, aber keine vollständigen Codeinhalte) den ursprünglichen Codeausschnitt rekonstruieren.

Dann wird eine hierarchische Methode verwendet, um die strukturelle Konsistenz und Lesbarkeit des rekonstruierten Codes aufrechtzuerhalten. Der Repository-Kontext wird gemäß der topologischen Sortierung und der Zeilennummerreihenfolge zusammengefügt: Höherwertige Knoten (wie REPO, PACKAGE) werden am Anfang der Ausgabe-Sequenz oder der Datei platziert; die Reihenfolge der Dateiknoten wird durch die topologische Sortierung festgelegt; die Knoten innerhalb der Datei (wie CLASS, FUNCTION) werden gemäß der Zeilennummerreihenfolge zusammengefügt.

Stufe 2: Feinabstimmung mit Rauschenserhöhung

In dieser Stufe wird CGM mit echten GitHub-Problem-Reparatur-Patch-Daten feinabgestimmt.

Das Modell lernt, Code-Patches auf der Grundlage von zwei Eingaben zu generieren: (i) einem relevanten Code-Subgraph; (ii) einer Textaufforderung, die die tatsächlichen Dateien angibt, die möglicherweise gemäß dem Patch geändert werden müssen. Um die Robustheit des Modells zu verbessern, wird in der Aufforderung bewusst 10% Rauscheinstellungen eingeführt: Beispielsweise kann die Aufforderung eine irrelevante Datei enthalten, die tatsächlich nicht geändert werden muss, oder mindestens eine Schlüsseldatei, die eigentlich geändert werden sollte, fehlen. Das Einführen dieses kontrollierten Rauschens bei der Ausbildung hilft dem Modell, besser auf reale Szenarien zu generalisieren, in denen die Eingabeinformationen unvollständig oder störend sind.

Inferenzphase: Graph-RAG-Framework ersetzt Agent

Schließlich hat CGM ein Agent-freies, leichtgewichtiges Framework namens Graph-RAG erstellt, um die praktische Anwendbarkeit weiter zu verbessern.

Es reproduziert den Bug-Reparatur-Arbeitsablauf menschlicher Programmierer, ist aber effizienter als bestehende Agent-Lösungen.

Die Anzahl der Kernmodule wurde von 10 auf 4 reduziert: Rewriter → Retriever → Reranker → Generator (CGM-Modell).

Rewriter: Die Problembeschreibung wird umformuliert und Schlüsselwörter und relevante Dateien werden extrahiert;

Retriever: Durch semantische und strukturelle Suche werden verbundene Subgraphen aus dem Code-Graphen extrahiert;

Reranker: Die Suchergebnisse werden sortiert, und die wichtigsten Dateien für die Generierung werden ausgewählt;

Generator: Der endgültige Reparaturcode wird basierend auf dem Subgraph und der Aufforderung generiert.

Basierend auf dem oben genannten hat CGM in mehreren Testbenchmarks führende Ergebnisse erzielt. Genauer gesagt:

Experimentelle Ergebnisse

Das Forschungsunternehmen hat die Leistung von CGM auf mehreren Mainstream-Benchmarks systematisch evaluiert, die zwei Hauptaufgabentypen umfassen: (1) Codebehebung und (2) Codevervollständigung.

Codebehebung auf Repository-Ebene

Auf der SWE-bench Lite Leaderboard belegt CGM mit 44,00% den ersten Platz in der Open-Source-Gewichtungsliste.

Auf SWE-bench Verified hat CGM im Vergleich zur besten Open-Source-Baseline um 10,20% zugenommen, auf 50,40%;

Für Java-Projekte hat CGM auf SWE-bench-java Verified 14,29% erreicht, was eine Zunahme von 4,4% im Vergleich zur besten Open-Source-Baseline bedeutet.

Diese Ergebnisse zeigen, dass CGM in der Lage ist, große Repository-Level-Bug-Reparaturaufgaben über Sprachen und Projekte hinweg zu bewältigen und eine starke Fähigkeit zum Strukturverständnis und zur Generalisierung aufweist.

Codevervollständigung auf Repository-Ebene

Bei komplexen Codegenerierungsaufgaben übertrifft CGM auch deutlich Open-Source-Modelle gleicher Größe auf ComplexCodeEval und CrossCodeEval, insbesondere in Szenarien, die Inference und Vervollständigung über Dateien hinweg erfordern.

Außerdem hat das Forschungsunternehmen CGM auf verschiedenen Basis-Modellen (CodeLlama-7B und DeepSeek-Coder-7B) implementiert und es mit neueren RAG-Systemen verglichen. Die Ergebnisse zeigen, dass CGM eine gute Allgemeingültigkeit hat und verschiedenen Basis-Modellen angepasst werden kann und die traditionellen RAG-Methoden übertrifft.