RAG 2026: Vergiss GraphRAG als Default

RAG hat gerade denselben Fehler wie Prompt Engineering vor ein paar Jahren.

Alle suchen nach dem einen Trick.

GraphRAG. HyDE. Corrective RAG. Self-RAG. Agentic RAG. RAPTOR. Parent-child retrieval. Query rewriting. Multi-query. Contextual Retrieval.

Das Problem ist nicht, dass diese Techniken schlecht sind. Viele davon sind nützlich. Das Problem ist die Frage:

“Welche RAG-Technik ist die beste?”

Das ist die falsche Frage.

Die bessere Frage ist:

“Welche Retrieval-Fehler macht mein System gerade, und welche Technik reduziert genau diese Fehler messbar?”

RAG 2026 ist kein Feature. RAG ist ein Messproblem.

2

Retrieval-Kanäle als Default: dense plus sparse

1

Reranker-Gate vor der Antwort

0

Vertrauen in “sieht plausibel aus”

Die kurze Antwort

Wenn du heute einen robusten RAG-Stack bauen musst, nimm nicht GraphRAG als Default.

Nimm:

Contextual Hybrid RAG
+ Reranking
+ Quellenpflicht
+ Evals

Das klingt weniger sexy als ein neues Paper-Akronym. Es ist aber viel näher an dem, was in echten Systemen zählt: findet das System die richtigen Belege, sortiert es sie sinnvoll, bleibt die Antwort bei den Quellen, und kannst du Fehler reproduzierbar verbessern?

Der robuste RAG-Stack

erst messen, dann fancy werden

1. 01
   Corpus Contract
2. 02
   Contextual Ingestion
3. 03
   Hybrid Retrieval
4. 04
   Reranking
5. 05
   Cited Answer
6. 06
   Evals + Traces

Warum Vector Search allein nicht reicht

Der erste RAG-Reflex vieler Teams ist:

Dokumente chunking
→ Embeddings
→ Vector DB
→ Top-K in den Prompt
→ Antwort

Das funktioniert als Demo. Es funktioniert auch für manche interne Wissensdatenbanken.

Aber als Default ist es zu schwach.

Vector Search ist gut für semantische Nähe. Sie ist schlecht, wenn exakte Begriffe, IDs, Zahlen, Namen, Versionen, Fehlermeldungen, Gesetzesstellen oder Produktbezeichnungen zählen.

BM25 und andere sparse Verfahren wirken neben Embeddings altmodisch. Genau deshalb werden sie unterschätzt. In vielen echten Korpora willst du beides:

• Dense Retrieval findet “inhaltlich ähnliche” Stellen.
• Sparse Retrieval findet exakte Begriffe, technische Marker und seltene Tokens.
• Rank Fusion kombiniert beide Signale.
• Reranking entscheidet danach genauer, was wirklich relevant ist.

Ein aktueller 2026-Benchmark zu Text-und-Tabellen-RAG fand genau dieses Muster: Hybrid Retrieval plus neuralem Reranking schlug die Single-Stage-Verfahren. Interessant war auch: Bei Finanzdokumenten schnitt BM25 stärker ab als Dense Retrieval. Das ist eine gute Ohrfeige für jeden “Vector DB löst Knowledge”-Pitch.

Quelle: From BM25 to Corrective RAG

Vector-only vs. Hybrid RAG

Vector-only

• Gut bei semantischer Ähnlichkeit.
• Kann IDs, Zahlen und seltene Begriffe verpassen.
• Ein Ranking-Signal.
• Einfacher Demo-Stack.

Hybrid

• Gut bei Bedeutung plus exakten Signalen.
• BM25/sparse fängt präzise Tokens ab.
• Mehrere Signale, danach Fusion und Reranking.
• Besserer Produktions-Default.

Der unterschätzte Hebel: Contextual Retrieval

Chunks sind brutal.

Du nimmst ein Dokument, zerschneidest es in kleine Stücke und hoffst, dass jedes Stück später noch genug Bedeutung trägt.

Tut es oft nicht.

Ein Chunk kann sagen:

This method reduced retrieval failure by 49%.

Aber ohne Kontext fehlt:

• welche Methode?
• in welchem Experiment?
• für welche Dokumente?
• verglichen mit welchem Baseline?
• von wem?

Contextual Retrieval löst genau dieses Problem. Vor dem Indexing bekommt jeder Chunk einen kurzen, dokumentbezogenen Kontext. Nicht als Antworttext, sondern als Retrieval-Hilfe.

Vereinfacht:

Original chunk:
"The method reduced retrieval failure by 49%."

Contextualized chunk:
"This chunk is from Anthropic's Contextual Retrieval article.
It discusses adding document-aware context to chunks before embedding
and BM25 indexing. The method reduced retrieval failure by 49%."

Das wird dann eingebettet und auch in den lexical Index geschrieben.

Anthropic berichtet für diesen Ansatz starke Zahlen: Contextual Embeddings plus Contextual BM25 reduzierten Retrieval-Fehler in ihren Tests um 49 Prozent. Mit Reranking waren es 67 Prozent.

Quelle: Anthropic: Introducing Contextual Retrieval

Das ist der wichtigste praktische Takeaway:

Viele RAG-Probleme sind keine Modellprobleme. Es sind Kontextverlust-Probleme beim Chunking.

Reranking ist kein Nice-to-have

Retrieval sollte breit suchen und eng antworten.

Wenn du nur Top 5 aus der Vector DB nimmst, muss der erste Retriever schon fast perfekt sein. Das ist selten eine gute Annahme.

Besser:

Retrieve 50-150 Kandidaten
→ fusionieren
→ reranken
→ Top 8-20 in den Antwortkontext

Der erste Retriever darf grob sein. Der Reranker darf genauer sein.

Das ist teurer als Top-K direkt in den Prompt zu werfen. Aber es kauft dir etwas, das in RAG fast immer wichtiger ist als ein paar Millisekunden: weniger falsche Belege.

Was Reranking verbessert

• semantisch ähnliche, aber irrelevante Treffer werden aussortiert
• exakte Treffer bekommen eine zweite Relevanzprüfung
• der Generator sieht weniger Müll im Kontext
• Citations werden vertrauenswürdiger

GraphRAG ist nicht falsch. Nur oft zu früh.

GraphRAG klingt nach dem logischen nächsten Schritt:

Dokumente rein, Entitäten raus, Beziehungen bauen, Communities erkennen, smarter fragen.

Und ja: Für bestimmte Fragen ist das stark.

Microsoft beschreibt GraphRAG mit Suchmodi wie Local Search, Global Search und DRIFT Search. Das ist sinnvoll, wenn die Frage nicht nur “wo steht X?” lautet, sondern:

• Welche Themen ziehen sich durch das ganze Korpus?
• Welche Projekte, Personen oder Methoden hängen zusammen?
• Welche Communities oder Cluster entstehen?
• Welche Widersprüche gibt es zwischen Quellen?
• Was verändert sich über Zeit?

Quelle: Microsoft GraphRAG Query Overview

Aber genau deshalb ist GraphRAG nicht der beste Default für jede RAG-Anwendung.

Für eine normale Frage wie:

Welche Methode empfiehlt Anthropic für bessere Chunk-Relevanz?

brauchst du keinen Graphen. Du brauchst den richtigen Absatz, gutes Ranking und eine saubere Quelle.

GraphRAG ist ein Analysemodul. Kein Ersatz für sauberes Retrieval.

GraphRAG richtig einsetzen

Machen

• ✓ für Beziehungen, Themen, Communities und corpusweite Synthese nutzen
• ✓ als zweiten Query-Pfad neben normalem Retrieval bauen
• ✓ Indexing-Kosten und Aktualisierung bewusst einplanen
• ✓ Ergebnisse gegen Originalquellen zurückführen

Lassen

• × jeden Lookup durch einen Graphen schicken
• × Graph-Extraktionen als Wahrheit behandeln
• × GraphRAG vor einem starken Baseline-RAG bauen
• × fehlende Evals durch ein komplexeres Diagramm ersetzen

Der Fehler in vielen RAG-Projekten

Viele Teams bauen RAG in dieser Reihenfolge:

Tool wählen
→ Daten reinwerfen
→ Prompt basteln
→ Demo zeigen
→ Fehler einzeln flicken

Die bessere Reihenfolge ist:

Fragen sammeln
→ Gold Set bauen
→ Fehlerklassen definieren
→ Baseline messen
→ gezielt Technik hinzufügen
→ wieder messen

Du brauchst zuerst einen Corpus Contract:

• Welche Dokumenttypen gibt es?
• Wie aktuell müssen Antworten sein?
• Welche Quellen sind vertrauenswürdiger?
• Was ist eine gute Citation?
• Welche Fragen kommen wirklich vor?
• Wann soll das System “weiß ich nicht” sagen?
• Welche Antwort darf nie ohne Quelle erscheinen?

Ohne diesen Contract ist RAG-Optimierung meistens Theater.

Evals sind der eigentliche Stack

RAG ohne Evals ist eine Suchmaschine mit Selbstbewusstsein.

Du brauchst mindestens vier Fragen:

Context Precision:
Wie viel vom gelieferten Kontext war wirklich relevant?

Context Recall:
Wurden die nötigen Belege überhaupt gefunden?

Faithfulness:
Bleibt die Antwort bei den Quellen?

Answer Relevancy:
Beantwortet sie wirklich die Frage?

Ragas deckt genau solche Metriken ab, unter anderem Context Precision, Context Recall, Response Relevancy und Faithfulness.

Quelle: Ragas Metrics

Wichtig: Diese Metriken ersetzen kein menschliches Urteil. Aber sie machen RAG-Fehler sichtbar genug, dass du nicht nur Bauchgefühl optimierst.

Der RAG-Eval-Loop

1. 01
   echte Fragen
2. 02
   erwartete Belege
3. 03
   Pipeline Run
4. 04
   Metriken
5. 05
   Fehlerklasse
6. 06
   Pipeline Patch

Was ist mit HyDE, Self-RAG und Corrective RAG?

Alles interessant. Nichts davon ist automatisch Default.

HyDE kann helfen, wenn kurze Nutzerfragen semantisch zu dünn sind. Es kann aber bei exakten oder numerischen Fragen auch stören, weil das hypothetische Dokument neue Begriffe einführt, die gar nicht in der Quelle stehen müssen.

Query Expansion kann Recall erhöhen. Sie kann auch Rauschen erhöhen.

Self-RAG und Corrective RAG können Retrieval-Fehler erkennen und reparieren. Sie machen das System aber komplexer, langsamer und schwerer reproduzierbar.

Agentic RAG kann Tools, Web, Datenbanken und APIs routen. Es kann aber auch aus einer Suchfrage einen kleinen, unberechenbaren Workflow machen.

Deshalb ist die Reihenfolge wichtig:

Baseline
→ Contextual Hybrid Retrieval
→ Reranking
→ Evals
→ erst dann adaptive/agentic Korrekturen

Die Sammlung NirDiamant/RAG_Techniques ist dafür sehr nützlich: als Katalog von Experimenten. Aber ein Katalog ist noch keine Architekturentscheidung.

Ein praktischer Bauplan

Wenn ich heute ein RAG-System für ein Research-, Blog- oder Knowledge-Produkt bauen müsste, würde ich so starten:

1. Corpus Contract

Schreibe auf, welche Quellen rein dürfen, wie Vertrauen gewichtet wird, welche Metadaten Pflicht sind und welche Antworttypen es gibt.

source_type
author
published_at
fetched_at
canonical_url
language
section_path
trust_level
freshness_policy

2. Struktur-aware Ingestion

PDFs, HTML, Markdown, Tabellen und Code brauchen andere Behandlung. Chunking sollte Überschriften, Abschnitte, Tabellen und Listen respektieren.

Nicht:

split every 800 tokens

Sondern:

Dokumentstruktur lesen
→ sinnvolle Sections bilden
→ kleine Child Chunks erzeugen
→ Parent Context behalten

3. Contextualization beim Indexing

Jeder Chunk bekommt eine kurze, generierte Kontextzeile:

Dieser Chunk stammt aus [Dokument], Abschnitt [X].
Er behandelt [Y] im Zusammenhang mit [Z].

Diese Contextualized Chunks gehen in Dense und Sparse Index.

4. Hybrid Retrieval plus Fusion

Baue zwei Suchpfade:

• Embeddings für semantische Nähe
• BM25/sparse für exakte Signale

Dann fusionieren, nicht blind einen Kanal bevorzugen.

5. Reranking

Top 50 bis 150 rein, Top 8 bis 20 raus. Die genaue Zahl hängt von Kontextfenster, Latenz und Antworttyp ab.

6. Cited Generation

Der Generator darf nur Aussagen machen, die sich auf mitgelieferte Quellen stützen. Keine Quelle, kein Claim.

7. Evaluation und Tracing

Jeder Run sollte speichern:

• Originalfrage
• Query Rewrite
• Dense Treffer
• Sparse Treffer
• Fusion Ranking
• Reranker Scores
• finale Quellen
• Antwort
• Latenz pro Stage
• Eval Scores

NVIDIAs RAG Blueprint modelliert solche Query-to-Answer-Stages explizit mit Rewriter, Retriever, Reranker, Generator und Observability.

Quelle: NVIDIA RAG Blueprint

Die Entscheidungsmatrix

Welche Technik wann?

Situation

• Antworten verfehlen genaue Begriffe, IDs oder Zahlen.
• Chunks wirken relevant, aber verlieren Dokumentkontext.
• Zu viele halbpassende Treffer im Prompt.
• Lange Dokumente werden zerstückelt.
• Fragen suchen Themen und Beziehungen im ganzen Korpus.
• Query-Typen sind sehr unterschiedlich.

Guter nächster Schritt

• BM25/sparse Retrieval ergänzen.
• Contextual Retrieval einführen.
• Reranker einbauen.
• Parent-child Retrieval nutzen.
• GraphRAG als separaten Pfad testen.
• Routing oder agentic RAG prüfen.

Die eigentliche Regel

RAG wird nicht gut, weil du die modernste Technik einbaust.

RAG wird gut, wenn jede Technik einen gemessenen Fehler reduziert.

Wenn dein System relevante Stellen nicht findet, brauchst du besseren Recall.

Wenn es zu viel irrelevanten Kontext liefert, brauchst du bessere Precision und Reranking.

Wenn Chunks ihren Sinn verlieren, brauchst du Contextualization oder Parent Context.

Wenn Antworten plausible Dinge erfinden, brauchst du Faithfulness Checks und härtere Citation-Regeln.

Wenn Nutzer corpusweite Muster fragen, brauchst du vielleicht GraphRAG.

Aber wenn du mit GraphRAG startest, bevor du weißt, welche Fehler du hast, baust du meistens nur eine hübschere Black Box.

Mein Default für 2026

Der robuste Default ist:

Structure-aware ingestion
+ contextual chunks
+ dense retrieval
+ BM25/sparse retrieval
+ rank fusion
+ reranking
+ cited generation
+ RAG evals
+ traces

GraphRAG kommt danach. Agentic RAG kommt danach. Self-correction kommt danach.

Nicht, weil diese Dinge unwichtig sind.

Sondern weil ein System erst eine verlässliche Such- und Messbasis braucht, bevor man es intelligenter macht.

RAG 2026 ist nicht “mehr KI in die Suche werfen”.

RAG 2026 ist: Kontext sauber bauen, Retrieval messbar machen, Antworten belegen und nur dann Komplexität hinzufügen, wenn sie einen echten Fehler löst.