# comparethemarket-context-retrieval-ai-code-review-gkg-rag-2026-03-06

## Veille

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). Auswertung anhand von **79 realen Merge Requests** mit **MLflow auf Databricks**. Auffälliges Ergebnis: **RAG schneidet schlechter ab als die Baseline** bei fast allen Metriken — Vektor-Rauschen wirkt sich beim Code-Review kontraproduktiv aus. **GKG übertrifft RAG um +21 %** bei der Inline-Comments-Abdeckung (0,696 vs. 0,577) durch strukturelles AST-Verständnis (Tree-sitter + Kuzu-Graphdatenbank). Code erfordert **strukturelles** Verständnis (Aufrufer, Signaturen, Hierarchien), nicht bloße semantische Ähnlichkeit. GKG kostet das 4-Fache der Baseline, liefert aber messbare Verbesserungen; RAG kostet das 3-Fache ohne Verbesserung. Implementiert als **Docker-Sidecar** in CI/CD, der die GKG-Binary (noch in der GitLab-Beta) mit einem lokalen MCP-Server umschließt.

## Titre Article

Comparing Context Retrieval Approaches for AI Code Review

## Date

2026-03-06

## URL

https://comparethemarketcareers.com/blog/comparing-context-retrieval-approaches-for-ai-code-review/

## Keywords

Compare the Market, Meerkat Careers, KI-Code-Review, Context Retrieval, RAG, GKG, GitLab Knowledge Graph, AST, Tree-sitter, Kuzu, Code-Wissensgraph, MLflow, Databricks, Merge Requests, empirische Auswertung, Inline-Comments-Abdeckung, semantische vs. strukturelle Ähnlichkeit, Docker-Sidecar CI/CD, lokaler MCP-Server, kontraproduktives Vektor-Rauschen, automatisiertes Code-Review, Kosteneffizienz beim KI-Review, RAG schlechter als Baseline, struktureller Code-Ansatz

## Authors

Équipe Engineering Compare the Market (Meerkat Careers, UK — site de comparaison d'assurances et services financiers).

## Ton

**Profil**: Technischer Artikel, veröffentlicht im Karriere-Blog von Compare the Market (Marke Meerkat Careers, UK), einem Unternehmen für Verbraucherpreisvergleiche. Ein internes Engineering-Format, das öffentlich geteilt wird — der Ton ist der eines Teams, das eine rigorose Auswertung durchgeführt hat und die Ergebnisse ohne Beschönigung teilt. Zielgruppe: Softwareentwickler, DevOps, Qualitätssicherungsteams, die ihr Code-Review mit KI unterstützen möchten, sowie Architekten, die RAG gegen strukturelle Ansätze für Code bewerten.

**Stil**: Empirisches technisches Register, datenorientiert. Der Artikel geht methodisch vor: Hypothese → Versuchsaufbau (4 Ansätze, 79 MRs, MLflow/Databricks) → Metriken → Ergebnisse → Ursachenanalyse → Empfehlungen. Kein Hype, keine Marketingversprechen: Die negativen Ergebnisse zu RAG werden direkt dargestellt, ohne den Versuch, sie abzumildern. Der Stil entspricht dem eines intern verfassten, öffentlich gemachten Engineering-Berichts — sachlich, strukturiert, mit Metriktabellen. Die Autorität ergibt sich aus den Daten, nicht aus der Rhetorik.

**Epistemische Haltung**: empirisch ehrlich. Der Artikel versucht nicht, GKG als Wunderlösung zu verkaufen — er räumt den 4-fachen Overhead und den Beta-Status von GKG ein. Das negative Ergebnis zu RAG ist der bedeutsamste Befund: zu zeigen, dass ein populärer Ansatz in einem spezifischen Anwendungsfall kontraproduktiv ist, ist nützlicher als die Alternative zu bewerben. Die Docker-Sidecar-Architektur wird als pragmatischer Workaround beschrieben (GKG noch nicht nativ in GitLab CI/CD integriert).

## Pense-betes

- **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.
- **Kennzahlen über 79 Merge Requests** (ausgewertet via **MLflow auf Databricks**): | Metrik | GKG | RAG | Differenz | |----------|-----|-----|-------| | Inline Comments Coverage | **0,696** | 0,577 | **+21 %** | | Summary Coverage | **0,681** | 0,664 | +3 % | | Issue Coverage | **0,929** | 0,926 | marginal | | Score Accuracy | **GKG besser** | RAG schlechter als Baseline | — |
- **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.

## RésuméDe400mots

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.

## GrapheDeConnaissance

- Compare the Market —a_créé→ évaluation empirique revue de code IA (EVENEMENT, 0.95)
- GKG —surpasse→ RAG (TECHNOLOGIE, 0.97)
- GKG —mesure→ 0,696 inline comments coverage vs RAG 0,577 (+21 %) (MESURE, 0.96)
- RAG —mesure→ performance pire que baseline sur presque toutes les métriques (MESURE, 0.96)
- GKG —utilise→ Tree-sitter (TECHNOLOGIE, 0.95)
- GKG —utilise→ Kuzu (TECHNOLOGIE, 0.94)
- GKG —est_instance_de→ GitLab Knowledge Graph (TECHNOLOGIE, 0.97)
- Compare the Market —affirme_que→ le code exige une compréhension structurelle, pas une similarité sémantique (AFFIRMATION, 0.95)
- RAG —réduit→ qualité de la revue de code IA (bruit vectoriel contre-productif) (AFFIRMATION, 0.94)
- GKG —permet→ identification précise des appelants, signatures, hiérarchies de code (CONCEPT, 0.95)
- évaluation empirique revue de code IA —utilise→ MLflow (TECHNOLOGIE, 0.93)
- évaluation empirique revue de code IA —mesure→ 79 merge requests évaluées (MESURE, 0.95)
- Compare the Market —a_créé→ GKG (TECHNOLOGIE, 0.92)
- GKG —utilise→ serveur MCP local (TECHNOLOGIE, 0.92)
- GKG —mesure→ coût 4× baseline avec améliorations mesurables (MESURE, 0.93)

---
Canonical: https://www.thekb.eu/de/fiches/comparethemarket-context-retrieval-ai-code-review-gkg-rag-2026-03-06/