KRÖTZSCHKI-Blog · Ohne Bullshit
Newsletter

Suchergebnisse für: „RAG“

  • RAG-Pipeline für semantische Codesuche: Feldnotizen aus dem Air-Context-Team bei JetBrains

    RAG-Pipeline für semantische Codesuche: Feldnotizen aus dem Air-Context-Team bei JetBrains

    Ein Parser liest eine Quelldatei und zerlegt sie in einen Strom von Syntaxknoten. Ein Algorithmus entscheidet dann, welche Knoten zu einer Einheit verschmelzen und welche getrennt bleiben.

    Das sieht nach unspektakulärer Vorarbeit aus, entscheidet aber, ob ein KI-Codeagent später die passende Funktion findet oder an einer Handvoll bedeutungsloser Zeilen hängen bleibt. Adam Malek und Ashot Kazaryan aus dem Team hinter Air Context, dem Codesuch-Dienst von JetBrains, beschreiben diesen Weg in einem Entwicklertagebuch auf dem Firmenblog. Wer an einer RAG-Pipeline für semantische Codesuche baut, findet darin Entscheidungen, die man sonst erst nach mehreren Fehlversuchen trifft. Der erste Teil der Reihe behandelt die Anfänge: Parsing und Chunking von Quellcode sowie die Vektorisierung. Die Ausgangsbeobachtung der Autoren ist nicht exotisch.

    Warum grep die Frage nach dem Sitzungstoken-Refresh nicht beantwortet

    Ein Agent, der ein Feature in einer großen Codebasis umsetzen soll, verbringt einen großen Teil seiner Laufzeit damit, die relevanten Stellen zu finden. Sein übliches Werkzeug ist die Textsuche. Deren Grenze liegt nicht in der Geschwindigkeit, sondern in der Voraussetzung: Wer sucht, muss wissen, welcher exakte Text in der Datei steht. Bei abstrakten Fragen ist das selten der Fall.

    Die Autoren führen ein Beispiel an. Ein Agent, der wissen will, wo abgelaufene Sitzungstoken erneuert werden, kann nicht darauf bauen, dass im Code das Wort „refresh“ auftaucht. Die zuständige Funktion kann völlig anders heißen, in eine Hilfsklasse ausgelagert sein oder über mehrere Schichten verteilt arbeiten. Keywords und Textsuche finden nur, was sie schon kennen.

    Semantische Codesuche mit Retrieval Augmented Generation dreht die Richtung um. Gesucht wird nach Bedeutung, nicht nach Zeichenketten. Lässt sich der Quellcode so indexieren, dass seine Semantik erhalten bleibt, kann der Agent per Freitextabfrage die Ausschnitte abrufen, die für seine Aufgabe zählen. Für die Autoren entsteht damit eine Schnittstelle, die zu den Stärken eines Sprachmodells passt. Der Prototyp einer solchen Pipeline ist schnell gebaut. Bis zur Produktionsreife ist es ein weiter Weg.

    Chunking: Warum feste Zeilenblöcke den Code an der falschen Stelle zerreißen

    Man kann sich eine solche Pipeline wie ein Archiv vorstellen, in dem Akten nicht nach Aktenzeichen, sondern nach Inhalt abgelegt werden. Dann hängt alles daran, was als eine Akte gilt. Ist die Akte zu groß, findet man in ihr nichts wieder; ist sie zu klein, steht in ihr nichts, was sich lohnt.

    Übertragen auf Quellcode heißt das: Eine ganze Datei als eine Einheit zu vektorisieren, wäre selbst dann wenig sinnvoll, wenn das Embedding-Modell die Länge verkraften würde. Die Suche gäbe die komplette Datei zurück, während es dem Agenten um eine bestimmte Funktion, ein Symbol oder einen kurzen Ausschnitt geht. Jede einzelne Zeile zu indizieren, führt in die andere Richtung ins Leere: Eine Zeile ohne Kontext trägt oft keine Bedeutung, ein generischer Funktionsname oder ein Kommentarfragment erzeugt Treffer, die niemand braucht. Der Agent versinkt in Micro-Ergebnissen.

    Der naheliegende Kompromiss, eine Datei in Blöcke fester Zeilenzahl zu schneiden, funktioniert laut den Autoren nicht. Solche Blöcke gruppieren Unzusammenhängendes, etwa eine Import-Anweisung mit dem Rumpf einer Funktion. Das Ergebnis sind semantisch falsche Einheiten, und die Fehler wandern direkt in die Suche. Der Ausweg liegt in der Struktur, die jeder Quellcode ohnehin besitzt: Importe stehen meist oben, danach folgt eine Klassendefinition mit optionalem Dokumentationskommentar, darin Felder und Methoden, die wiederum eigene Kommentare tragen können.

    Syntaxknoten, Präfixe, Normalisierung: Wie Air Context Chunks bildet

    JetBrains arbeitet nach eigener Darstellung seit 26 Jahren an Parsern, die die Eigenheiten, Konventionen und Unebenheiten einzelner Sprachen abbilden. Diese Parser bilden zusammen mit weiteren Werkzeugen die interne Plattform Code Engine, auf der auch Air Context aufsetzt. Im beschriebenen Stand unterstützt Air Context Parsing und strukturbewusstes Chunking für neun große Sprachen: Kotlin, Java, Python, JavaScript, TypeScript, C#, PHP, Go und Rust. Für alle übrigen Sprachen fällt die Implementierung auf eine naive, zeilenbasierte Aufteilung zurück, damit grundsätzlich jede Datei indexierbar bleibt.

    Der Parser zerlegt eine Datei in einen Strom von Syntaxknoten, die mitteilen, was sie repräsentieren: Kommentare, Leerraum, Modifikatorlisten und so weiter. Der Chunking-Algorithmus liest diesen Strom und entscheidet anhand von Typ, Größe und Unterknoten über den Umfang eines Chunks. Überschreitet ein Knoten die Größenschwelle und hat keine Kinder, greifen primitivere Aufteilungsstrategien. Einige sprachspezifische Konstrukte bleiben dagegen auch dann eine Einheit, wenn sie größer sind als erwünscht. Präfixe wie Dokumentationskommentare, Annotationen, Sichtbarkeitsmodifikatoren und Schlüsselwörter bleiben bei der Deklaration, schließende Syntax bleibt bei dem Konstrukt, das sie abschließt.

    Hinzu kommt eine sprachspezifische Bereinigung. Häufige, semantisch wenig aussagekräftige Java-Annotationen wie @NotNull oder @Override werden entfernt. Die Autoren verweisen auf eine Ähnlichkeit zu cAST von Zhang und Kollegen aus dem Jahr 2025: Beide Verfahren behalten die größten Syntaxeinheiten, die noch passen, unterteilen nur die zu großen und gruppieren kleine benachbarte Einheiten, um Mini-Chunks zu vermeiden. Der Unterschied liegt nach eigener Darstellung in der Menge der einprogrammierten Sprachsemantik. Python-Dekoratoren bleiben bei ihren Definitionen, KDoc-Kommentare stehen neben ihren Kotlin-Deklarationen.

    Nach dem Gruppieren folgt die Normalisierung: führender und abschließender Leerraum verschwinden, Leerzeilen werden gelöscht, gemeinsame Einrückung wird entfernt, während die relative Einrückung erhalten bleibt. Anschließend wandert der Chunk zusammen mit Metadaten in den nächsten Schritt, darunter der relative Pfad der Quelldatei, der gemeinsam mit dem normalisierten Inhalt eingebettet wird.

    Ob ein Chunk wirklich gut geschnitten ist, lässt sich nicht rein formal entscheiden. Die Autoren setzen daher auf ein Sprachmodell als Richter. Es bekommt den Chunk und die Quelldatei zu sehen und beurteilt, ob die Grenze sinnvoll ist. Auffällig sind für den Richter abgelöste Dokumentation, verwaiste schließende Syntax oder Code, der mitten durch ein bedeutungstragendes Konstrukt geschnitten wurde. Jede Änderung an der Verarbeitungskette durchläuft zusätzlich eine vollständige Retrieval-Evaluierung von Ende zu Ende.

    Vektorisierung: Bedeutung als Position in einem Raum aus tausend Dimensionen

    Aus den vorbereiteten Textstücken wird schließlich eine Repräsentation, die semantische Suche ermöglicht. In der Vektorisierung liest ein Embedding-Modell ein Stück Text und gibt eine Liste fester Länge zurück, einen Vektor. Dieser Vektor ist ein Punkt in einem Raum mit einigen tausend Dimensionen. Trainiert ist das Modell so, dass Texte mit ähnlicher Bedeutung nahe beieinander landen.

    Was in der klassischen Suche unsichtbar bleibt, wird hier zur Nachbarschaft. Eine Funktion, die gepufferte Schreibvorgänge ausleert, und eine, die eine anstehende Warteschlange abarbeitet, teilen womöglich kein einziges Schlüsselwort und liegen im Vektorraum trotzdem dicht beieinander. Der Abstand zwischen Vektoren wird damit zum Maß für Verwandtschaft. Eine Suchanfrage wird in dieselbe Position im Raum übersetzt, und zurück kommt, was am nächsten liegt.

    Die Rechnung pro Byte: Warum Vektoren zum Kostenfaktor werden

    Code-Vektorisierung für KI-Agenten ist zunächst billig und wird im Großen teuer. Ein einzelnes Embedding kostet fast nichts, doch ein großes Repository erzeugt Millionen von Chunks und damit Millionen von Vektoren, die gespeichert, im Arbeitsspeicher gehalten und bei jeder Anfrage verglichen werden müssen. Ein Vektor mit einigen tausend Dimensionen in 32-Bit-Gleitkommazahlen wiegt rund 16 Kilobyte. Ein paar Millionen Chunks summieren sich auf mehrere zehn Gigabyte Index, noch bevor irgendeine Verwaltungsstruktur dazukommt.

    Ab dieser Größenordnung verschiebt sich die Leitfrage. Statt „Wie genau können wir werden?“ lautet sie: „Was bekommen wir pro Byte?“ Die Autoren nennen zwei Hebel, die unabhängig voneinander wirken und sich kombinieren lassen. Der erste ist, weniger Dimensionen zu behalten. Moderne Embedding-Modelle sind so trainiert, dass ein führender Abschnitt des Vektors für sich funktioniert; beim Training wird die Verlustfunktion über mehrere verschachtelte Präfixlängen gleichzeitig angewandt, sodass die grobe Struktur in den vordersten Dimensionen landet. Du kannst einen Vektor also abschneiden, neu normalisieren, und er sucht weiterhin. Der zweite Hebel lässt alle Dimensionen stehen und spart an jeder einzelnen, indem Präzision geopfert und pro Vektor weniger Bytes vorgehalten werden. Beide Wege sind keine Notlösung, sondern eine Budgetentscheidung.

    Welche Mischung bei gleichem Budget besser sucht, zeigen die Autoren an einem Beispiel. 512 Byte pro Vektor reichen entweder für 128 Dimensionen in voller 32-Bit-Genauigkeit oder für alle 4.096 Dimensionen mit je einem einzigen Bit. Beide Varianten passen exakt ins Budget, im Test findet die zweite aber deutlich besser. Ihre Erklärung: Jede Dimension ist wie eine kleine Frage, die das Modell an den Text stellt – geht es um Fehlerbehandlung, um Netzwerkzugriffe, um Testcode? Wer auf 128 Dimensionen kürzt, behält sehr genaue Antworten auf drei Prozent der Fragen und wirft den Rest weg. Ein Bit pro Dimension bewahrt dagegen auf jede Frage eine grobe Ja-oder-Nein-Antwort. Ein langer Fragebogen mit Häkchen schlägt einen kurzen, der auf sechs Nachkommastellen ausgefüllt ist.

    Air Context geht deshalb bis zum Äußersten: Jede Komponente ab null wird zur Eins, jede negative zur Null, die Beträge entfallen. Der Vektor ist damit 32-mal kleiner als in 32-Bit-Gleitkommazahlen – deutlich radikaler als Verfahren wie turbovec, das mit einem Achtel des Speichers auskommt. Mit der Darstellung ändert sich auch das Maß. Die Kosinus-Ähnlichkeit braucht die verworfenen Beträge, verglichen wird deshalb per Hamming-Distanz, also über die Zahl der Stellen, an denen sich zwei Bitmuster unterscheiden. Ein Vektor mit 4.096 Bit liegt als 64 Wörter zu je 64 Bit im Speicher; ein Vergleich besteht aus XOR und dem Zählen der Einsen, insgesamt in der Größenordnung von hundert Prozessorbefehlen statt Tausender Multiplikationen.

    Den Preis nennen die Autoren offen: Die binäre Quantisierung kostet einige Punkte Recall gegenüber den unkomprimierten Vektoren. Sie nehmen das in Kauf, weil ein Agent die Ergebnisse liest und nicht ein Mensch. Für den Agenten zählt, dass die relevanten Dateien unter den ersten zwölf Treffern auftauchen; ob der beste Chunk auf Platz zwei oder fünf landet, ändert nichts, weil er die Kandidaten ohnehin öffnet. Eine zweite Grenze zeigte sich erst später: Die Bitvektoren stauchen die Spanne der Ähnlichkeitswerte. Zwei völlig unverwandte Vektoren stimmen schon zufällig in etwa der Hälfte der Bits überein, ein eng verwandtes Paar vielleicht in zwei Dritteln. Für eine Rangfolge reicht das, für einen Schwellenwert nicht. Wo ein Index absolut entscheiden muss, ob etwas relevant ist – etwa für eine Funktion, die ungefragt passenden Code vorschlägt und wissen muss, wann sie schweigt –, behält Air Context 16-Bit-Gleitkommazahlen und zahlt für den Speicher.

    Dateipfade kürzen, Quellcode nicht speichern

    Beim Einbetten trennt das Team Indexierung und Suche. Die Indexierung ist auf Durchsatz ausgelegt, eine GPU verarbeitet etwa 32 Chunks pro Batch, bevor sie ausgelastet ist. Die Suche muss dagegen innerhalb weniger Sekunden antworten. Eingesetzt wird ein Modell, das Anweisungen befolgt und beide Seiten unterschiedlich behandelt: Code-Chunks werden eingebettet, wie sie sind, einer Suchanfrage wird eine Anweisung vorangestellt, die sinngemäß lautet, zu dieser Anfrage den passenden Code zu finden.

    Jeder Chunk wird zusammen mit seinem Dateipfad eingebettet, weil der Pfad verrät, in welchem Modul der Code liegt und was die Datei ist. In einem Monorepo wird das zum Problem. Das Monorepo von IntelliJ IDEA umfasst mehr als eine Million Dateien, die mittlere Quelldatei liegt neun Verzeichnisse tief hinter einem Pfad von 91 Zeichen, knapp 10.000 Dateien haben Pfade über 150 Zeichen, der längste misst 218 – die Datei an seinem Ende ist 24 Zeilen lang. Air Context kappt deshalb jeden Pfad, bevor er das Modell erreicht, und behält beide Enden: vorn die Segmente, die das Modul benennen, hinten Elternverzeichnis und Dateiname. Die Mitte fällt weg, so viel wie nötig. Schränkt jemand die Suche auf ein Verzeichnis ein, landet dieser Bereich in derselben gekürzten Form im Anfragetext, statt die Treffer nachträglich zu filtern.

    Zum Schluss beschreiben die Autoren zwei Vorgaben zum Schutz des Quellcodes. Gespeichert wird kein Code, nur Koordinaten: ein Verweis, der Typ, der Dateipfad, Start- und End-Offset und ein Verweis auf den Vektor. Der Ausschnitt, den ein Nutzer sieht, wird erst auf seinem Rechner aus seinem eigenen Checkout zusammengesetzt. Eingebettet wird mit einem Open-Weight-Modell auf GPUs, die JetBrains selbst betreibt; keine Anfrage geht an OpenAI, Google oder andere Anbieter. Nach eigenen Benchmarks schnitt das offene Modell dabei besser ab als die gehosteten Embedding-APIs der großen Anbieter – eine Messung des Herstellers in eigener Sache.

    Was von den Feldnotizen für den eigenen Aufbau bleibt

    Der praktische Kern des Berichts lässt sich in wenigen Sätzen zusammenfassen. Die Qualität einer RAG-Pipeline für semantische Codesuche entscheidet sich früher, als die meisten erwarten – nicht im Modell, sondern an der Chunk-Grenze. Strukturbewusstes Parsing schlägt jede Aufteilung nach Zeilenzahl, weil es die Konventionen einer Sprache kennt und zusammengehörige Deklarationen zusammenhält. Wo diese Kenntnis fehlt, ist ein zeilenbasierter Rückfall immer noch besser als eine Lücke im Index.

    Bewertung ist kein nachträglicher Prüfschritt. Ein Sprachmodell als Richter über Chunk-Grenzen und eine Ende-zu-Ende-Messung des Retrievals gehören zum Bau der Pipeline, nicht in eine Schublade daneben. Und beim Speicher wird es ernst: Wer semantische Codesuche über eine große Codebasis anbietet, betreibt ein Budgetproblem, in dem Genauigkeit, Speicherbedarf und Antwortzeit gegeneinander verrechnet werden. Die Antwort von Air Context: lieber alle Dimensionen mit einem Bit als wenige in voller Genauigkeit – und 16 Bit nur dort, wo ein Schwellenwert gebraucht wird.

    Der Bericht ist der erste Teil einer Reihe. Offen sind noch die effiziente Speicherung der Millionen Bitvektoren, Antworten in Millisekunden, die laufende Evaluierung und die Frage, wie man den Agenten dazu bringt, die Suche tatsächlich zu nutzen. Das dürfte für jeden interessant sein, der semantische Codesuche als Dienst betreiben will. Air Context selbst ist als öffentliche Vorschau bereits in JetBrains-Lizenzen enthalten. Wer selbst baut, sollte aus diesem ersten Teil vor allem eines mitnehmen: Erst den Code verstehen, dann die Vektoren.

    Quelle: blog.jetbrains.com

  • Was KI an der Mathematik ändert – und was nicht: Ein Gastbeitrag auf Terence Taos Blog

    Was KI an der Mathematik ändert – und was nicht: Ein Gastbeitrag auf Terence Taos Blog

    Was ändert KI an der mathematischen Arbeit – und was nicht? Ein Gastbeitrag auf Terence Taos Blog „What’s New“ antwortet darauf nüchtern. Rachel Webb, Mathematikerin mitten in ihrer Promotion, beschreibt dort keine neuen Ziele, sondern andere Werkzeuge. Wer heute in der Mathematik arbeitet, findet in ihrem Text weniger eine Prognose als eine Aufforderung: Prüfe, welcher Teil deiner Arbeit sich verändert und welcher nicht.

    Gutes mathematisches Schreiben als Stellvertreter für gutes Denken

    Der Auslöser liegt einige Jahre zurück. Webb besuchte als Doktorandin ein Seminar, in dem Graduierte und Lehrende Schreibkurse für ihr Fach entwickeln wollten. Die Moderatorin stellte eine harmlose Frage: Was heißt es, im eigenen Fach gut zu schreiben? Webb hatte eine schnelle Antwort. Gutes mathematisches Schreiben – und damit gutes Mathematikbetreiben – sei klar und korrekt.

    Die anderen Teilnehmenden waren erfahrener und kamen aus anderen Disziplinen. Ihre Antwort fiel anders aus: Gutes Schreiben sagt etwas Interessantes. Für Webb war das mehr als ein Wortwechsel. Sie beschreibt es als den Moment, in dem sich ihr die Bedeutung von Forschung erschloss. Forschung ist die Suche nach etwas Interessantem, das man sagen kann. Klarheit und Korrektheit kommen erst danach – dann aber zwingend.

    Diese Reihenfolge wird oft verwechselt. Korrektheit lässt sich überprüfen, Interesse nicht – deshalb steht sie in der Ausbildung im Vordergrund. Wer nur korrekt arbeitet und nie fragt, wem diese Korrektheit etwas bedeutet, bearbeitet Aufgaben statt Probleme.

    Definitionen als Figuren, Lemmata als Handlung

    Wie entsteht das Interessante? Webb greift zu einem Bild, das ihre Arbeitsweise gut trifft. Die Arbeit an einem Beweis sei wie das Schreiben eines Romans. Dessen Figuren sind den Bedingungen menschlicher Erfahrung unterworfen, werden aber so präsentiert, dass sie diese Erfahrung kommentieren.

    In der mathematischen Variante sind die Figuren die Definitionen, die Handlung besteht aus Lemmata und Theoremen. Beides ist an Wahrheit gebunden. Innerhalb dieses Rahmens gibt es aber Wahlmöglichkeiten: Definitionen lassen sich strategisch oder geradezu künstlerisch zuschneiden, damit sie bestimmte Facetten des Wahren sichtbar machen.

    Daraus folgt eine Haltung, die Webb ausdrücklich vertritt. Es gibt nicht den einen Weg zu verstehen, was auf fundamentaler Ebene vor sich geht. Man sucht Verständnis, wählt aber aus dem Verstandenen eine Erzählung aus, die für die Kolleginnen und Kollegen schön und interessant ist. Das ist der kreative Anteil der Forschung, den die verbreitete Formel von der Suche nach Verständnis – Thurston hat sie geprägt – nicht ganz abdeckt.

    Woher kommt Interesse? Webb nennt zwei Quellen: Anwendungen, in der realen Welt oder in anderen Teilen der Mathematik, und die Nähe zu prominenten offenen Problemen. Solche Probleme sind Zentren, um die herum die Gespräche der Disziplin stattfinden.

    Warum LLMs die Ausführung beschleunigen, nicht die Fragestellung

    An dieser Grundhaltung ändert ein Large Language Model nach Webbs Einschätzung wenig. Es ändert nur, wie der Plan ausgeführt wird. Jetzt gibt es eine Maschine, die alle Bücher gelesen hat und weiß, wie viele Standardlemmata es gibt – so ihre Formulierung. Das beschleunigt die Forschung erheblich und macht aus manchen Ländern mathematischer Fantasie Gebiete, die sich realistisch erkunden lassen. Sie zitiert Benjamin Antieau: größere Träume träumen.

    Als Metapher für diesen Wechsel wählt sie die Fahrtroute. Wer auf der Autobahn fährt statt auf Nebenstraßen, kommt schneller voran und verzichtet auf manches am Rand. Entscheidend ist: Für jede Etappe lässt sich neu entscheiden, welche Route man nimmt. Der Zugriff auf das Modell ist kein Schalter, sondern eine Wahl.

    Auch ihr Maßstab für Interesse verschiebt sich nicht. Wenn ein Millennium-Problem gelöst ist, fragt sie, muss dann das Interesse an der Umgebung sinken? Sie verneint es. Es gibt viele Lösungen, aber auch viele Bruchstücke von Verständnis, die keine vollständige Lösung ergeben und trotzdem wertvoll sind. Man mag wissen, wie man in die rote Stadt gelangt; die Kartierung des umliegenden Geländes wird dadurch nicht weniger wertvoll, sondern eher mehr, weil die Nähe wirtschaftliche und strategische Möglichkeiten eröffnet.

    Zwei Gründe, warum Menschen weiter Mathematik betreiben

    Damit ist nur das Wie geklärt, nicht das Warum. Webb stellt die unangenehme Frage direkt: Welche Gründe haben Menschen, Mathematik zu betreiben, wenn Maschinen irgendwann Mathematik erzeugen, die interessanter ist als alles, was wir selbst hervorbringen? Ökonomische Antworten kennt sie, lässt sie aber beiseite und verweist auf andere Autoren. Stattdessen nennt sie zwei humanistische Gründe.

    Der erste ist die Freude. Mathematik ist für Webb individuell interessant, und sie will weitermachen, auch wenn Maschinen darin besser sein sollten. Sie benennt aber eine Gefahr: LLMs können den Spaß austreiben, weil sie dazu verleiten, die Antwort zu kennen, statt die Lösung zu verstehen.

    Dieser Versuchung müsse man widerstehen. KI solle nur so eingesetzt werden, dass Forschung mehr Freude macht und Verständnis mit dem Wissen einhergeht. Das kann Experimentieren erfordern. Solche Entscheidungen gehören längst zum Alltag: Manche Wege gehen Menschen bewusst zu Fuß, obwohl ein Auto bereitsteht, weil der geteilte Aufwand den Zusammenhalt stärkt. Nicht jede effiziente Option ist die richtige.

    Der zweite Grund ist die Gemeinschaft. Mathematik ist nicht nur für einzelne interessant, sondern für mehrere Menschen gleichzeitig – darin liegt ihre soziale Funktion. Die Seminarteilnehmenden aus anderen Fächern meinten mit interessant genau das: interessant für andere Menschen, also Teil eines größeren Gesprächs. Lehre, Zusammenarbeit, Konferenzen, Kolloquien und Teepausen halten diese Gespräche am Laufen.

    Was KI an der sozialen Seite der Mathematik gefährden kann

    Hier sieht Webb das eigentliche Risiko. KI kann soziale Bindungen auf zwei Wegen schwächen. Der erste ist die Angst, überholt zu werden: Wenn Ergebnisse schneller entstehen, wächst die Sorge, dass jemand anderes dieselbe Idee zuerst veröffentlicht. Der zweite ist unspektakulärer und vielleicht wirksamer – es wird schlicht einfacher, eine Maschine zu fragen als eine Kollegin.

    Webb bleibt an dieser Stelle vorsichtig. Dass etwas geschehen könnte, heißt nicht, dass es geschieht. Sie zitiert Wendell Berry, um die Richtung vorzugeben: Möge das Zeitalter der KI das Zeitalter werden, in dem wir unsere mathematischen Nachbarn kennen. Dazu gibt sie eine praktische Anweisung mit auf den Weg: Tut jeden Tag etwas, das sich nicht berechnen lässt.

    Auch der Rahmen fällt auf. Der Beitrag erschien auf dem Blog eines der bekanntesten Mathematiker der Gegenwart, und die Anmerkung des Gastgebers verrät, dass er in einem anderen Dateiformat geschrieben und mit KI konvertiert wurde. Damit ist der Text selbst ein Beispiel für das, was er beschreibt: Die Maschine erledigt die Übertragung, der Mensch liefert Argument und Haltung.

    Was das für den eigenen Umgang mit KI bedeutet

    Für die Praxis lässt sich daraus mehr mitnehmen als eine bloße Haltung. Trenne den Teil deiner Arbeit, der sich ändert, von dem, der sich nicht ändert. Was sich ändert, ist die Ausführung: das Nachschlagen, das Sortieren von Standardresultaten, das Ausformulieren, das Überführen von Ideen in Texte und Formate. Was bleibt, ist die Auswahl dessen, was überhaupt interessant ist, und die Verantwortung für das Verständnis.

    Das ist keine Beruhigungspille, sondern eine Zumutung mit zwei Seiten. Wer immer den schnellen Weg nimmt, verliert Zeit, die vorher mit Verständnis verbracht wurde; wer ihn nie nimmt, verliert den Anschluss. Die sinnvolle Antwort ist deshalb keine Grundsatzentscheidung, sondern eine Wahl pro Etappe – wie bei der Route.

    Was heißt das konkret? Wenn du in der mathematischen Forschung arbeitest, wird sich dein Arbeitsalltag schneller verändern als deine Fragestellungen. Die Werkzeuge werden besser, die Landkarte detaillierter, und die Umgebung bereits gelöster Probleme bleibt interessant. Was nicht automatisch mitwächst, ist die Gemeinschaft, in der solche Fragen gestellt werden – sie entsteht durch Menschen, die sich füreinander Zeit nehmen. Ob KI diesen Teil stärkt oder aushöhlt, entscheidet nicht die Maschine.

    Quelle: terrytao.wordpress.com

  • Code Review als Endkontrolle: Warum Thoughtworks-CTO Rachel Laycock das Pull-Request-Modell infrage stellt

    Code Review als Endkontrolle: Warum Thoughtworks-CTO Rachel Laycock das Pull-Request-Modell infrage stellt

    KI habe die Code Review ruiniert, heißt es oft – sie erzeuge mehr Code, als Menschen lesen können. Rachel Laycock, CTO bei Thoughtworks, dreht die Beweislast um: Nicht die Werkzeuge überfordern das Verfahren, sondern die Softwareentwicklung hat ein einzelnes Verfahren mit Aufgaben beladen, die es nie tragen konnte. Veröffentlicht hat Laycock den Text am 2. September 2026 als Antwort auf einen Beitrag von Brian Houck von DX. Anlass war ein Panel bei Code Remix, moderiert von Moderne, auf dem beide unterschiedlicher Meinung waren. Der Streit selbst ist weniger aufschlussreich als die Frage, um die es dabei geht.

    Houck hat seine Sicht unter dem Titel „What are code reviews even for?“ dargelegt. Laycock nennt ihn sympathisch und betont, dass beide Seiten dasselbe wollen – nur führe die Code Review nicht dorthin. Solche Auseinandersetzungen sind nützlich, weil sie zeigen, wo Annahmen auseinandergehen und nicht bloß Vorlieben. Wer sich mit Code Review, Pull Requests und Pair Programming beschäftigt, findet darin eine Positionsbestimmung, die über die übliche Werkzeugdebatte hinausreicht.

    Die Zahlen hinter der Debatte: mehr Code pro Kopf, größere Pull Requests

    Houck nennt Zahlen, die sich nicht wegdiskutieren lassen. Bei Meta sollen die signifikanten Codezeilen pro menschlich gemergtem Diff innerhalb eines Jahres um 106 Prozent gestiegen sein. Die Daten von DX zeigen nach seiner Darstellung einen Anstieg der medianen Pull-Request-Größe um 64 Prozent. Diese Entwicklung erklärt, warum Code Review in vielen Teams wieder zum Thema geworden ist.

    Houck sorgt sich nicht nur um die Menge. Wenn Code Review automatisiert werde, so sein Argument, gehe verloren, was sonst daran hängt: Wissensaustausch, Einarbeitung jüngerer Entwickler, kollektives Eigentum am Code, Verständnis für Architekturentscheidungen. Diese Sorge teilt Laycock ausdrücklich. Der Einwand setzt eine Ebene tiefer an: Warum wartet man überhaupt bis zur Code Review, um all das zu erledigen?

    Warum das Feedback nach vorne gehört

    Dahinter steht ein Prinzip, das Laycock nach eigener Aussage früh bei Thoughtworks gelernt hat: Feedback-Schleifen verkürzen. Ist eine Rückmeldung wertvoll, schafft man sie nicht ab – man rückt sie näher an die Entscheidung heran, die sie beeinflussen soll. Der Pull Request als Mittelpunkt der Entwicklung erfüllt genau das nicht. Man baut etwas, stellt es fertig, schnürt ein Paket, wirft es jemand anderem zu – und führt erst dann das wichtige Gespräch darüber, ob das Richtige auf die richtige Weise gebaut wurde.

    Laycock geht die üblichen Begründungen für die Code Review einzeln durch und verschiebt jede an den Ort, an dem sie früher wirkt. Wer Alternativen abwägen will, sollte das tun, bevor eine davon implementiert ist. Wer Wissen weitergeben will, soll paaren: Neben jemandem zu sitzen, während diese Person ein Problem durchdenkt, lehrt mehr als die fertige Lösung hinterher zu lesen. Wer will, dass jüngere Entwickler die Denkweise erfahrener Kollegen aufnehmen, lässt sie mitarbeiten, während gedacht wird – oder setzt das Team vor ein Whiteboard, bevor überhaupt jemand Code schreibt oder einen Agenten damit beauftragt.

    Beim kollektiven Eigentum geht es um Organisation, nicht um ein Verfahren: Teams sollten Software gemeinsam bauen und betreiben, statt sich vom Pull Request erzählen zu lassen, was jemand anderes bereits fertiggestellt hat. Architektonische Übereinstimmung entsteht im gemeinsamen Entwurf – und die wichtigen Randbedingungen gehören anschließend als Fitness Functions in den Code, nicht in einen Kommentar. Und was Formatierung, Linting, bekannte Sicherheitsprobleme oder deterministisch prüfbare Eigenschaften angeht: automatisieren. Über Leerzeichen, so der trockene Kommentar, sollte man 2026 nicht mehr streiten.

    Pair Programming, Trunk-based Development, automatisierte Tests, statische Analyse, Fitness Functions und Security-Scans haben eines gemeinsam – sie ziehen Rückmeldung nach vorne. Agenten können in diesen Schleifen zunehmend mitspielen, Entwürfe hinterfragen, Annahmen testen, laufend prüfen. Das eigentliche Denken kommt weiterhin von erfahrenen Menschen. Und wenn diese Erfahrung dem ganzen Team zugutekommen soll, muss das Team deutlich früher als bei der Code Review wie ein Team handeln.

    Review nach Ausnahme statt nach Pflicht

    Das heißt ausdrücklich nicht, dass niemand mehr Code liest. Es gibt Änderungen, bei denen Laycock einen zweiten erfahrenen Blick ausdrücklich will: eine grundlegende Architekturänderung etwa, die das Team nach einer gemeinsamen Entwurfssitzung noch einmal zusammen durchgeht. Ebenso etwas, das eine sensible Sicherheitsgrenze berührt, eine Änderung mit großem Wirkungsradius, ein unvertrauter Teil eines kritischen Systems – oder schlicht ein Fall, bei dem jemand im Team sagt: Da bin ich mir nicht sicher.

    Genau dort ist menschliches Urteil wertvoll. Das ist aber etwas völlig anderes, als jede einzelne Änderung von einem Menschen inspizieren zu lassen, weil das historisch die Zeremonie war, mit der man Vertrauen hergestellt hat.

    Der Engpass, den mehr Tempo nicht löst

    Dass es so nicht weitergeht, zeigt sich daran, dass die Code Review überhaupt wieder als Problem auftaucht. Wenn ein Agent die zehnfache Menge Code produziert, aber jede Zeile am Ende darauf wartet, dass ein erfahrener Entwickler sie prüft, ist keine zehnfach leistungsfähige Organisation entstanden – sondern ein großer Rückstau und ein neuer Engpass.

    Die naheliegende Antwort, einen KI-Agenten die Rolle des menschlichen Prüfers spielen zu lassen, hält Laycock für die falsche. Damit werde dasselbe Verfahren bei höherem Tempo beibehalten: Man automatisiert die Zeremonie, statt zu fragen, wozu es sie überhaupt gibt.

    Was an Houcks Einwand bleibt

    Ein Punkt aus Houcks Argumentation bereitet Laycock allerdings Sorge: die Vorstellung von kognitiven Schulden und Intent Debt. Software wächst, während die Menschen, die für sie verantwortlich sind, immer weniger davon verstehen, warum sie so funktioniert, wie sie funktioniert. Das Problem sei real. Nur seien verpflichtende Pull Requests keine besonders starke Verteidigung dagegen.

    Wenn Agenten künftig einen erheblichen Teil der Implementierung übernehmen, braucht es nach Laycocks Darstellung deutlich mehr Absicht beim Erhalt des menschlichen Verständnisses: gemeinsamer Entwurf, Pairing, saubere Grenzen, ausführbare Architektur, geteilte Betriebsverantwortung – und vermutlich Praktiken, die noch niemand erfunden hat.

    Systeme verstehen, nicht Diffs

    Der Satz, auf den der Text hinausläuft, ist gleichzeitig seine Zusammenfassung: Entwickler müssen Systeme verstehen, nicht Diffs. Vielleicht, so die Vermutung, legt die KI hier nur etwas frei, das schon länger schief lag. Über Jahre wurde der bescheidenen Code Review eine außergewöhnliche Zahl von Zuständigkeiten aufgeladen – Qualitätstor, Sicherheitsprüfung, Architekturreview, Mentoring-Mechanismus, Wissensverteilung, Eigentumsmodell.

    Das funktionierte, halbwegs, solange Menschen Code nur in begrenztem Tempo herstellen konnten. Diese Begrenzung verschwindet gerade. Damit verschiebt sich auch die Frage: Sie lautet nicht mehr, wie man Code schneller geprüft bekommt, sondern warum man mit allen wichtigen Gesprächen bis zur Code Review wartet.

    Quelle: martinfowler.com

  • ToolGrad dreht die Datensatzgenerierung um: erst die Tool-Kette, dann die Frage

    ToolGrad dreht die Datensatzgenerierung um: erst die Tool-Kette, dann die Frage

    Mehr Daten und größere Modelle gelten als der sicherste Weg zu leistungsfähigen KI-Agenten. Der Engpass liegt aber in der Reihenfolge, in der die Daten entstehen. Die Arbeit „ToolGrad: Efficient Tool-use Dataset Generation with Textual Gradients“ (ACL 2026) dreht diese Reihenfolge um: Zuerst wird eine funktionierende Kette von API-Aufrufen konstruiert, erst danach die passende Nutzerfrage dazu formuliert.

    Das klingt nach einem Detail, ist aber der Kern des Problems. Bisherige Verfahren gehen umgekehrt vor: Sie erfinden eine Anfrage und suchen dann nach einem Werkzeugpfad, der sie erfüllt. Dieser Ansatz ist ineffizient, weil er die Spuren aus einer aufwendigen Agenten-Exploration destillieren muss. ToolGrad erzeugt laut den Autoren komplexere Daten bei geringeren Kosten, und die damit trainierten Modelle schneiden besser ab als die mit den bisherigen Datensätzen.

    Warum die übliche Reihenfolge teuer ist

    Ein Beispiel: Wer eine Wanderroute dokumentieren will, kann einen Wanderer losschicken und hoffen, dass er unterwegs einen guten Weg findet. So arbeiten ToolBench und ToolACE: Zuerst entsteht eine hypothetische Nutzeranweisung aus einem Stichprobenpool von APIs, danach sucht ein Agent per Tiefensuche nach einer passenden Werkzeugkette. Diese Suche läuft per trial and error. Sie findet Lösungen, kostet aber viele Modellaufrufe, und ein Teil der Versuche bleibt ergebnislos.

    Der zweite Weg ist der des Kartografen: erst die Route zeichnen, dann die Frage dazu schreiben. Aus der Werkzeugkette wird die Anfrage abgeleitet, nicht umgekehrt. Die Autoren nennen das answer-first, also lösungszuerst. Der Vorteil ist die Eindeutigkeit: Eine konkrete Abfolge von API-Aufrufen enthält mehr Information als eine vage formulierte Anfrage. Die Zuordnung von Werkzeugnutzung zu Nutzerfrage wird damit zu einem einzigen Modellschritt statt zu einer offenen Suche.

    Was mit textuellen Gradienten gemeint ist

    Der Begriff stammt aus dem Maschinellen Lernen. Dort berechnen Modelle über Stapel von Trainingsbeispielen einen numerischen Verlust und leiten daraus einen Gradienten ab, der die Gewichte in eine bessere Richtung schiebt. TextGrad hat das Prinzip auf Prompt-Optimierung übertragen: Statt Zahlen liefert ein Modell als Kritiker eine Beschreibung in natürlicher Sprache, was schiefgelaufen ist. Diese Rückmeldung heißt textueller Gradient.

    ToolGrad übernimmt den Gedanken, wendet ihn aber auf die Konstruktion von Daten an, nicht auf einen festen Prompt. Optimiert wird keine Zeichenkette, sondern ein Ablauf aus Aufrufen. Aus einer großen Bibliothek von Schnittstellen entsteht Schritt für Schritt ein gültiger API-Workflow. Der textuelle Gradient wirkt dabei als Richtungshinweis: Er sagt nicht „so nicht“, sondern benennt, welche der getesteten Optionen den Ablauf am sinnvollsten erweitert. So wird aus Prompt-Optimierung ein Verfahren, mit dem sich API-Workflows automatisch mit LLMs erstellen lassen.

    Die vier Module von ToolGrad

    Das Framework besteht aus vier Bausteinen, die in einer Schleife zusammenarbeiten. Der API Proposer wählt in jeder Runde aus einer Stichprobe von Schnittstellen einige Kandidaten aus, die den aktuellen Ablauf erweitern könnten. Die API Executors rufen diese Kandidaten parallel auf und erzeugen Ausführungsberichte. Sie liefern das Material, auf dem die Bewertung beruht, statt einer Vermutung darüber, was funktionieren sollte.

    Der API Selector liest die Berichte und entscheidet sich für den Aufruf, der am besten abschneidet. Dieser ausgewählte Aufruf ist der textuelle Gradient im engeren Sinn: Er gibt die Richtung vor und wird an die bestehende Kette angehängt. Der LLM Updater passt die synthetische Nutzerfrage und die Antwort des Agenten an den gewachsenen Werkzeugsatz an. Nach vielen Wiederholungen steht ein fertiges Beispiel: eine Anfrage, ein verifizierter Ablauf und eine Antwort, die darauf beruht.

    Das Vorgehen bewertet nicht am Ende einer langen Suche, sondern nach jedem einzelnen Schritt. Fehler werden dadurch früh sichtbar, und die Passrate nähert sich laut den Autoren hundert Prozent. Wer schon einmal einen fehlgeschlagenen Agentenlauf debuggt hat, weiß, was das wert ist: Die Ursache liegt fast nie am Ende der Kette.

    Was die Experimente zeigen

    Als Werkzeugbibliothek diente ToolBench mit über 16.000 realen Schnittstellen. Verglichen wurde die klassische, fragenerste Generation per Tiefensuche mit dem lösungszuersten ToolGrad. Ergebnis: komplexere Daten, höhere Erfolgsquote, niedrigere Kosten. Aus der Bibliothek entstand der Datensatz ToolGrad-500, mit dem die Autoren Gemma-3-Modelle in den Größen 1B, 4B und 12B nachtrainierten. Getestet wurden diese Varianten auf dem Berkeley Function Calling Leaderboard, also mit einem anderen Werkzeugsatz als dem aus dem Training.

    Diese Trennung ist entscheidend. Sie misst nicht, ob ein Modell seine Trainingswerkzeuge auswendig gelernt hat, sondern ob es mit unbekannten Schnittstellen umgehen kann. In dieser Out-of-Distribution-Situation verbesserten sich alle drei Modellgrößen gegenüber ihren nicht nachtrainierten Ausgangsversionen. Das 12B-Modell erreichte 83,1 Punkte und lag laut den Autoren damit auf Augenhöhe mit den damals leistungsfähigsten proprietären Modellen, die sie mit 83,2, 82,8 und 74,4 Punkten auflisten.

    Ein zweiter Befund ist für die Praxis wichtiger. Der Datensatz ToolGrad-500 wurde mit einem verhältnismäßig kleinen Modell erzeugt. Das darauf feinabgestimmte Gemma-3-12B übertraf seinen eigenen Lehrer. Dieses Muster ist als Self-evolving bekannt und heißt für LLM Fine-Tuning mit Tool-Nutzungsdaten: Die Qualität des Datensatzes hängt weniger von der Leistungsfähigkeit des Generators ab als von der Struktur des Generierungsprozesses. Auch andere offene Spezialmodelle für Werkzeugnutzung ließ die Variante hinter sich, darunter ToolACE, das auf einer fortgeschritteneren Schnittstellendatenbank trainiert worden war.

    Grenzen und offene Fragen

    Die Skepsis: Alle Zahlen stammen aus der Veröffentlichung selbst; unabhängige Nachbauten stehen noch aus. Der Ansatz braucht Umgebungen, in denen API-Aufrufe tatsächlich ausgeführt und bewertet werden können. Bei Schnittstellen mit Kosten oder irreversiblen Aktionen – eine Zahlung, ein gelöschter Datensatz – ist paralleles Ausprobieren heikel. Und eine hohe Passrate bei der Datengenerierung sagt nichts über die Robustheit im echten Betrieb, wo Anfragen unvollständig, widersprüchlich oder schlicht falsch formuliert sind.

    Die Autoren benennen diese Grenzen selbst und skizzieren, wohin es gehen soll: zu größeren, dynamischeren Schnittstellenlandschaften und einer laufenden Weiterbildung, die sich an individuelle Nutzung anpasst. Ein Modell, das sich im Betrieb ständig verändert, braucht allerdings Kontrolle darüber, was es dazulernt und was nicht.

    Effiziente Datensatzgenerierung für Tool-Nutzung ist kein Problem der Rechenleistung, sondern der Konstruktionslogik. Wer synthetische Datensätze baut, sollte zuerst das Ergebnis festlegen und die Aufgabe daraus ableiten – derselbe Rat, den man einem Team gibt, das zu viele unklare Tickets bearbeitet. ToolGrad liefert dafür ein ausgearbeitetes Verfahren samt Auswertung. Ob sich der Ansatz außerhalb kontrollierter Benchmarks durchsetzt, hängt davon ab, ob sich Werkzeugketten auch dort zuverlässig vorab planen lassen, wo jeder einzelne Aufruf echte Konsequenzen hat.

    Quelle: research.google

  • Graph RAG gegen Standard RAG: Warum Vektorähnlichkeit bei der Code-Migration an ihre Grenzen stößt

    Graph RAG gegen Standard RAG: Warum Vektorähnlichkeit bei der Code-Migration an ihre Grenzen stößt

    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

Weitere Beiträge