Comparing Context Retrieval Approaches for AI Code Review
Empirische Studie des Engineering-Teams von Compare the Market (Meerkat Careers, UK) zur Bewertung von vier Ansätzen für Context Retrieval beim KI-Code-Review: Baseline (kein zusätzlicher Kontext), RAG (Vektorsuche), GKG (GitLab Knowledge Graph, AST-basierter Wissensgraph) und GKG+RAG (hybrid).
Von Équipe Engineering Compare the Market// Quelle comparethemarketcareers.com ↗/Lesezeit 2 min/.md// Automatisch geprüfte Übersetzung
#Compare the Market#Meerkat Careers#KI-Code-Review#Context Retrieval#RAG#GKG#GitLab Knowledge Graph#AST
Zusammenfassung
Das Engineering-Team von Compare the Market (Meerkat Careers, UK) veröffentlichte am 6. März 2026 eine empirische Bewertung von vier Context-Retrieval-Ansätzen für das KI-Code-Review: Baseline (kein zusätzlicher Kontext), RAG (Vektorsuche via Embeddings), GKG (GitLab Knowledge Graph, ein AST-basierter Wissensgraph über Tree-sitter und die Kuzu-Graphdatenbank) sowie ein GKG+RAG-Hybrid. Die Auswertung umfasst 79 reale Merge Requests, gemessen über MLflow auf Databricks.
Das Hauptergebnis ist kontraintuitiv: RAG schneidet schlechter ab als die Baseline bei fast allen Metriken, einschließlich Inline-Comments-Abdeckung, Summary-Abdeckung und Score-Genauigkeit. Zusätzlicher, über Vektorähnlichkeit abgerufener Kontext ist nicht nur nutzlos, sondern für das Code-Review kontraproduktiv. Vier Ursachen werden identifiziert: Rauschen (Vektorähnlichkeit ruft Code ab, der „ähnlich aussieht“, ohne relevant zu sein), False Positives, das fehlende Verständnis dateiübergreifender Beziehungen sowie ein Ablenkungseffekt, der das Modell in die Irre führt.
Umgekehrt übertrifft GKG RAG um +21 % bei der Inline-Comments-Abdeckung (0,696 vs. 0,577). Der Grund ist struktureller Natur: Code-Review erfordert das Wissen, wer eine Funktion aufruft, was sie aufruft und wie sie sich in die Architektur einfügt — Informationen, die AST und Wissensgraph nativ erfassen, semantische Ähnlichkeit jedoch nicht liefern kann. GKG identifiziert Aufrufer präzise, versteht Funktionssignaturen und verfolgt Code-Beziehungen.
Die Implementierung ist pragmatisch: Da GKG noch in der Beta-Phase ist und noch nicht nativ in GitLab CI/CD integriert, baute das Team einen Docker-Sidecar-Container, der die GKG-Binary umschließt, bei jeder MR-Pipeline die Codebasis indexiert und die Tools über einen lokalen MCP-Server bereitstellt. Die Kosten liegen beim 4-Fachen der Baseline, doch die Verbesserungen sind messbar und gerechtfertigt. RAG kostet das 3-Fache der Baseline bei schlechteren Ergebnissen.
Diese Studie bestätigt einen wichtigen Trend des Jahres 2026: Bei Code übertreffen strukturelle Ansätze (AST, Wissensgraphen, gezieltes Grep) vektorbasierte Ansätze (semantisches RAG). Code ist kein Text — sein Informationswert liegt in seinen strukturellen Beziehungen, nicht in lexikalischer Ähnlichkeit. Starke Konvergenz mit Zhutov/QMD, Dropbox/Okumura („der Wert entsteht durch die Systeme rund um das Modell“) und der Doktrin von Anthropic Data Science („der Engpass ist Struktur, nicht Zugriff“). Als empirische Referenz für Architekturentscheidungen beim KI-Code-Review sowie als Gegenargument zu RAG-by-default im Code-Bereich zu verwenden.
Kernpunkte
Datum / Quelle. 6. März 2026, Meerkat-Careers-Blog (Compare the Market, UK). Autor: Engineering-Team (Einzelname(n) nicht verfügbar — Website blockiert 403, Eintrag basiert auf von Suchmaschinen indexiertem Inhalt und Sekundärquellen).
Behandeltes Problem. Wie lässt sich einem KI-Reviewer am besten Kontext zur Codebasis bereitstellen? Reicht semantische Ähnlichkeit (RAG) aus, oder ist strukturelles Verständnis von Code (AST/Graph) erforderlich?
4 bewertete Ansätze. 1. Baseline — kein zusätzlicher Kontext, das KI-Modell sieht nur den MR-Diff. 2. RAG (Retrieval-Augmented Generation) — Code-Chunking, Embeddings, Vektorsuche zum Abrufen semantisch ähnlicher Snippets. 3. GKG (GitLab Knowledge Graph) — AST-Parsing via Tree-sitter (gitlab-code-parser), strukturierter Wissensgraph gespeichert in Kuzu (Graphdatenbank), strukturelle Abfragen (Aufrufer, Klassenhierarchie, Funktionssignaturen). 4. GKG+RAG (hybrid) — Kombination beider Ansätze.
Hauptergebnis: RAG schneidet schlechter ab als die Baseline. bei fast allen Metriken. Zusätzlicher, verrauschter Kontext wirkt kontraproduktiv.
4 identifizierte Ursachen für das Versagen von RAG beim Code-Review. 1. Rauschen — Vektorähnlichkeit ruft Code ab, der „ähnlich aussieht“, aber nicht relevant ist. 2. False Positives — RAG findet Funktionen, die nichts mit der Änderung zu tun haben. 3. Beschränkung auf einzelne Dateien — RAG versteht dateiübergreifende Beziehungen nicht. 4. Ablenkungseffekt — zusätzlicher Kontext kann das Modell eher in die Irre führen als ihm helfen.
Warum GKG funktioniert. Code-Review erfordert strukturelles Verständnis — bei der Überprüfung einer Änderung an einer Funktion muss man wissen, wer sie aufruft, was sie aufruft und wie sie sich in die Architektur einfügt. GKG identifiziert Aufrufer präzise, versteht Signaturen und verfolgt Code-Beziehungen. Dies ist strukturelle Navigation, keine semantische Ähnlichkeit.
Technische Umsetzung. GKG noch in der Beta-Phase, noch nicht als native GitLab-CI/CD-Funktion verfügbar → das Team baute einen Docker-Sidecar: einen schlanken Container, der die offizielle GKG-Binary umschließt und neben dem Reviewer in der CI-Pipeline eingebunden wird. Bei jeder MR-Pipeline: (1) der Sidecar mountet den Projekt-Quellcode, (2) indexiert die gesamte Codebasis und erstellt den Wissensgraphen von Grund auf neu, (3) startet den GKG-MCP-Server auf einem lokalen Port, (4) stellt eine Reihe von Tool-Calls bereit, mit denen sich der KI-Reviewer verbindet.
Kosten-Nutzen-Analyse.
GKG: 4-fache Baseline-Kosten → messbare und gerechtfertigte Verbesserungen.
RAG: 3-fache Baseline-Kosten → Ergebnisse schlechter, als gar nichts hinzuzufügen.
GKG+RAG: kumulierte Kosten ohne zusätzlichen Nutzen gegenüber GKG allein.
Fazit. Wenn Qualität im Vordergrund steht, GKG verwenden. RAG und GKG+RAG vermeiden.
Verbindungen zu Watch-Files.
Starke Konvergenz. mit der Doktrin „grep gewinnt, wenn man weiß, wonach man sucht, AST gewinnt, wenn strukturelle Beziehungen benötigt werden“ — ein 2026 bestätigter Trend durch die Praktiken von Cursor, Claude Code, Devin (vgl. MindStudio „Coding Agents Skipped RAG“).
Übereinstimmung mit Zhutov/QMD (2026-03-01) zur Überlegenheit strukturierter Suche gegenüber Vektorsuche bei Code.
Erweitert Trivedy/LangChain (2026-03-10) Anatomy of an Agent Harness: das Harness (hier der GKG-+-MCP-Sidecar) zählt mehr als das Modell.
Übereinstimmung mit Dropbox/Okumura (2026-05-28) „der Wert entsteht weniger durch das Modell selbst als durch die Systeme, die es umgeben“ — struktureller Kontext macht den Unterschied, nicht das LLM.
Ergänzt die Akte MCP: GKG über einen lokalen MCP-Server bereitgestellt, was das MCP-Sidecar-Muster in CI/CD bestätigt.
Bestätigt Anthropic Data Science (2026-06-03): „rohes Grep über Tausende SQL-Dateien → Genauigkeit verändert sich nur um einen Punkt“ — der Engpass ist Struktur, nicht Zugriff.
Verstärkt die Anti-naive-RAG-These von Seale (2025-05-30) Philosophy Eats AI: Ontologie (hier der AST) hat Vorrang vor Ähnlichkeit.
Verwendungszweck. Architekturentscheidungen für KI-Code-Review in Unternehmen; Argument gegen RAG-by-default bei Code; Design agentengestützter CI/CD-Pipelines; Bewertung von Code-Kontext-Tools (GKG, CodeGraphContext, code-review-graph).
Einschränkungen. (a) 79 MRs = geringer Stichprobenumfang; (b) eine einzige Codebasis (Compare the Market) — Repräsentativitätsverzerrung; (c) GKG noch in der Beta, noch nicht im großen Maßstab validiert; (d) Autor(en) nicht identifiziert — Website blockiert 403; (e) kein Vergleich mit anderen strukturellen Ansätzen (Augment Context Engine, CodeGraphContext usw.).
LinkedIn-Kurzlink. Der Link lnkd.in/dacPc6fM (ausstehend seit 2026-05-15) verweist auf diesen Artikel.
Kernzahlen
0,696 Inline-Kommentar-Abdeckung vs. RAG 0,577 (+21 %)