Viele gehen davon aus: Automatisierte Code-Übersetzung ist vor allem eine Frage der Modellgröße. Ein stärkeres Sprachmodell liefert saubereren Code. Der arXiv-Preprint 2609.12464 zeigt das Gegenteil. Nicht das Modell bremst, sondern die Frage, welchen Ausschnitt eines Systems es überhaupt zu sehen bekommt.
Die Arbeit vergleicht zwei Arten des Kontextabrufs bei der Migration von Legacy-Monolithen zu Microservices. Da ist zum einen das bekannte Standard RAG, das Code in Chunks zerlegt und per Vektorähnlichkeit wieder einsammelt. Zum anderen eine Methodik namens Hierarchical Context-Resident Graph, kurz HCRG, die den Code als Graph mit echten architektonischen Kanten abbildet. Der Unterschied klingt trocken. Er entscheidet aber mit darüber, ob der übersetzte Code am Ende kompiliert.
Retrieval-Augmented Generation heißt heute fast immer Vektorähnlichkeit: Text wird in Häppchen geschnitten, in Zahlenvektoren übersetzt und über die Nähe im Vektorraum wieder eingesammelt. Für Dokumentation, Tickets oder Chatverläufe reicht das. Für Quellcode ist es das falsche Kriterium. Ähnlichkeit sagt nichts über Zugehörigkeit – und Zugehörigkeit ist in einem Softwaresystem die Größe, auf die es ankommt.
Warum Standard RAG beim Übersetzen von Legacy-Code scheitert
Ein Monolith ist kein Haufen unabhängiger Dateien, sondern ein Geflecht aus Vererbungsketten, Interface-Verträgen, Aufrufhierarchien und geteilten Datenstrukturen. Wer das in gleich große Textblöcke zerlegt, zerschneidet genau die Fäden, die das System zusammenhalten. Die Vektorsuche findet dann die Textstellen, die einer Anfrage semantisch am nächsten liegen – nicht die, die fachlich dazugehören. Das Modell bekommt eine Auswahl, die plausibel aussieht und strukturell falsch ist.
Man kann sich das wie die Renovierung eines alten Gebäudes vorstellen. Standard RAG liefert Innenaufnahmen: schöne Bilder einzelner Zimmer, sauber beschriftet, thematisch sortiert. Der Bauplan mit dem Tragwerk fehlt. Wer nur die Fotos kennt, reißt irgendwann eine Wand heraus, die das Dach trägt, und wundert sich, warum danach etwas einstürzt. Genau das passiert, wenn ein Sprachmodell eine Methode aufruft, die es in der Zielarchitektur nicht gibt.
Der Preprint gibt dem Phänomen eine Kennzahl: API-Halluzination. Gemeint ist der Anteil erfundener oder falsch verdrahteter Schnittstellen. Im Standard-RAG-Aufbau liegt der Wert bei 56,4 Prozent. Mehr als die Hälfte der erzeugten Aufrufe zeigt also auf etwas, das es nicht gibt. Oberflächlich sieht der Code dabei gut aus – genau das ist die Gefahr.
Wie ein hierarchischer Graph-Kontext den Code zusammenhält
Die Pipeline arbeitet in drei Schritten. Zuerst zieht das Parsing-Werkzeug tree-sitter einen Abstract Syntax Tree aus dem Quellcode – eine formale Struktur aus Klassen, Methoden, Parametern und Blöcken. Dann werden die architektonischen Beziehungen zwischen diesen Knoten als Kanten in einen Property Graph geschrieben, konkret in Google Cloud Spanner. Zum Schluss wird die Struktur serialisiert und in einen Gemini Context Cache gelegt, aus dem das Modell seinen Kontext bezieht.
Entscheidend ist die Reihenfolge. Das System arbeitet parent-first: erst die übergeordneten Einheiten, dann die abhängigen. Wer eine Klasse migriert, kennt bereits die Basisklasse, das Interface und die aufrufenden Stellen. Zurück zum Gebäude: Das Modell bekommt nicht mehr einzelne Zimmerfotos, sondern den vollständigen Bauplan, und arbeitet sich vom Fundament nach oben vor.
Der Unterschied liegt in der Art des Abrufs. Standard RAG fragt: Welcher Textblock ähnelt meiner Suchanfrage am meisten? Graph RAG fragt: Welche Knoten sind mit diesem Knoten über welche Kanten verbunden? Die zweite Frage lässt sich nicht per Vektorähnlichkeit beantworten. Strukturelle Nachbarschaft und inhaltliche Ähnlichkeit sind zwei verschiedene Dinge. Ein Interface kann semantisch völlig anders klingen als seine Implementierung und trotzdem dazugehören.
CodeBLEU lügt: Warum Textähnlichkeit die falsche Messlatte ist
Der zweite Beitrag der Arbeit liegt im Messen. Übliche Metriken für Code-Übersetzung vergleichen erzeugten mit vorhandenem Code auf Textüberlappung, etwa CodeBLEU und ähnliche Varianten. Hier erreichten Standard RAG und Graph RAG beide rund 91 Prozent. Auf dem Papier sind die Verfahren damit gleichwertig – solche Zahlen stehen deshalb gern in Evaluationsberichten.
Der Wert kaschiert das Problem. Code, der syntaktisch plausibel ist und auf nicht existierende APIs zeigt, sieht textlich fast aus wie korrekter Code. Die 91 Prozent sind kein Qualitätsnachweis, sondern ein Beleg dafür, dass die Metrik die falsche Frage stellt. Die Autoren ersetzen sie durch ein eigenes Framework mit sieben Kennzahlen, die softwaretechnische Eigenschaften abbilden statt Zeichenähnlichkeit.
Dazu gehören die bereits erwähnte API-Halluzinationsrate, die Dependency Resolution Quality für korrekt aufgelöste Abhängigkeiten, die Parent-Child Consistency für die Konsistenz zwischen Basis- und abgeleiteten Einheiten, die Cyclomatic Complexity Consistency für die erhaltene Verzweigungsstruktur und die Docstring Preservation für den Erhalt von Dokumentationskommentaren. Das ist der methodische Fortschritt: eine Messlatte, die strukturelle Fehler nicht hinter glatter Oberfläche versteckt.
Was die Zahlen zeigen – und wo Graph RAG teuer bezahlt
Bei den strukturellen Kennzahlen ist das Ergebnis deutlich. Die API-Halluzinationsrate sinkt von 56,4 auf 16,2 Prozent, also auf weniger als ein Drittel. Die Dependency Resolution Quality steigt von 34,8 auf 65,9 Prozent, die Parent-Child Consistency von 26,7 auf 45,5 Prozent. Wer schon einmal übersetzten Code manuell nachgebessert hat, kennt den Unterschied: Es geht nicht mehr darum, fehlende Schnittstellen zu erraten.
Der Gewinn kommt nicht umsonst. Weil das Modell den gesamten strukturellen Zusammenhang sieht, reagiert es mit defensivem Überbau. Es fügt Prüfungen, Fallunterscheidungen und Absicherungen ein, die im Original nicht stehen. Die Cyclomatic Complexity Consistency fällt deshalb von 71,6 auf 46,7 Prozent. Der übersetzte Code ist weniger halluzinationsanfällig, aber spürbar komplexer als die Vorlage.
Auch bei der Dokumentation geht es leicht zurück: Die Docstring Preservation sinkt von 67,0 auf 61,0 Prozent. Das passt ins Bild. Wenn ein Modell mehr Kontext verarbeitet und mehr Absicherung einbaut, verschiebt sich seine Aufmerksamkeit weg von Kommentaren und hin zur Logik. Vereinfacht: weniger erfundene Schnittstellen gegen mehr Verzweigungen und etwas weniger Dokumentation.
Was das für die Praxis der Legacy-Modernisierung bedeutet
Die Konsequenz ist unbequem für alle, die auf das nächste Modell gehofft haben. Der größte Hebel bei der Migration von Unternehmenscode mit LLM liegt nicht im Modell, sondern im Retriever – in der Frage, welcher Kontext zusammengestellt wird. Bessere Abhängigkeitsauflösung entsteht nicht dadurch, dass man mehr Kontext in das Modell schüttet, sondern dadurch, dass man den richtigen Kontext aus einer Struktur zieht.
Daraus folgt: Man braucht eine eigene Messlatte. Wer CodeBLEU oder reine Textähnlichkeit als Abnahmekriterium verwendet, erklärt Projekte für gelungen, die beim ersten Build scheitern. Sinnvoll sind Kennzahlen, die den Kompilierungsvorgang, die Auflösung von Abhängigkeiten und die Konsistenz zwischen Basis- und abgeleiteten Einheiten abbilden. Erst dann wird sichtbar, was Standard RAG und Graph RAG wirklich unterscheidet.
Die Sache bleibt aufwendig. Eine Graph-Pipeline mit AST-Extraktion, Property-Graph-Speicherung und serialisiertem Kontext-Cache ist Infrastruktur, keine Konfigurationszeile. Sie kostet Engineering-Zeit, Speicher und Betrieb. Für ein einzelnes Skript lohnt das nicht; bei einem gewachsenen Monolithen mit tausenden Dateien sieht die Rechnung anders aus, weil dort jeder vermiedene Halluzinationsfehler direkt Review-Zeit spart.
Und auch der beste Graph RAG ersetzt keine menschliche Abnahme. Die verbleibenden 16,2 Prozent API-Halluzinationen sind keine Restfehler, die man ignorieren kann, sondern genau die Stellen, an denen ein Review hinschauen muss. Graph RAG macht automatisierte Code-Übersetzung also nicht fehlerfrei. Es verschiebt den Fehlercharakter: Statt falscher Schnittstellen bekommt man konservativen, etwas zu komplexen Code – für jede Migration die angenehmere Ausgangslage.
Quelle: arxiv.org
