Graph RAG ist ein Retrieval-Augmented-Generation-Ansatz, der Wissen nicht (nur) als Vektoren, sondern als Knowledge Graph aus Entitäten und ihren Beziehungen ablegt. Während klassisches RAG eine Frage über semantische Ähnlichkeit beantwortet — es sucht die zur Anfrage am nächsten liegenden Textpassagen — folgt Graph RAG den expliziten Verbindungen zwischen Entitäten. Das macht es stark, wo Beziehungen und mehrstufige Schlüsse (Multi-Hop) wichtiger sind als reine Textähnlichkeit.

• Was es ist: RAG-Variante, die einen Knowledge Graph (Entitäten plus Relationen) als Wissensquelle nutzt — allein oder zusätzlich zum Vektor-Index.
• Wann es hilft: Bei Multi-Hop-Fragen, Beziehungsfragen und globalen Übersichtsfragen über ein ganzes Korpus.
• Was es kostet: Höhere Indexierungs- und Pflegekosten als Vektor-RAG, weil die Graph-Extraktion LLM-gestützt erfolgt.

Warum reine Ähnlichkeit an Grenzen stößt

Klassisches RAG arbeitet zweistufig: Im Indexing-Pfad werden Dokumente geparst, in Chunks zerlegt, per Embedding-Modell in Vektoren überführt und in eine Vektordatenbank geschrieben. Im Query-Pfad wird die Frage ebenfalls eingebettet, die ähnlichsten Chunks (top-k) werden abgerufen, optional per Hybrid Search mit BM25 kombiniert und per Re-Ranker präzisiert, und schließlich landet alles im Prompt des Generators. Dieses Muster ist robust und für die meisten Wissensfragen ausreichend. Anthropics Contextual Retrieval zeigt etwa, dass sich Retrieval-Fehler durch chunk-spezifische Kontext-Header und Reranking um bis zu 67 % senken lassen (Anthropic, Stand 09/2024).

Der blinde Fleck entsteht bei zwei Fragetypen:

• Multi-Hop-Fragen: "Welche Lieferanten unseres größten Kunden sind selbst von Sanktionen betroffen?" erfordert eine Kette von Schlüssen — Kunde -> Lieferanten -> Sanktionsstatus —, die in keinem einzelnen Chunk steht. Top-k-Ähnlichkeit liefert hier oft nur Fragmente, ohne die Verbindung herzustellen.
• Globale Übersichtsfragen: "Was sind die fünf zentralen Themen über alle 2.000 Support-Tickets hinweg?" lässt sich nicht beantworten, indem man fünf bis zehn ähnliche Chunks abruft. Die Antwort verlangt eine Aggregation über das gesamte Korpus.

Genau hier setzt Graph RAG an: Statt isolierte Textstücke zu finden, navigiert es eine explizite Wissensstruktur.

Aufbau eines Knowledge Graph statt (oder zusätzlich zu) einem Vektor-Index

Der Kern von Graph RAG ist die Indexierung. Aus den Quelldokumenten wird mithilfe eines LLM ein Graph extrahiert:

1. Entity-Extraktion: Das LLM identifiziert Entitäten (Personen, Organisationen, Produkte, Orte, Konzepte) und beschreibt sie.
2. Relationship-Extraktion: Es erkennt Beziehungen zwischen diesen Entitäten ("liefert an", "ist Tochter von", "verursacht") inklusive Beschreibung und ggf. Gewicht.
3. Graph-Konstruktion: Entitäten werden zu Knoten, Beziehungen zu Kanten. Mehrfach erwähnte Entitäten werden zusammengeführt.

Microsofts quelloffener GraphRAG-Ansatz (Microsoft Research) erweitert dieses Grundmuster um zwei zentrale Schritte (Stand 2026):

• Community-Detection: Über Graph-Clustering (etwa Leiden-Algorithmus) werden eng verbundene Knoten zu hierarchischen "Communities" gruppiert — thematischen Teilgraphen.
• Community-Summaries: Für jede Community erzeugt ein LLM bereits zur Indexzeit eine Zusammenfassung. Diese Summaries sind der Schlüssel für globale Fragen: Bei einer Übersichtsfrage werden nicht einzelne Chunks, sondern Community-Summaries als Bausteine einer Map-Reduce-Antwort genutzt.

Daraus ergeben sich zwei Abfragemodi: Local Search beantwortet fokussierte Fragen über eine bestimmte Entität und ihre Nachbarschaft im Graph; Global Search beantwortet korpusweite Themenfragen über die Community-Summaries.

Pseudocode: Indexierung und Abfrage

```text

Indexierung (offline, LLM-intensiv)

for dokument in korpus:
entitaeten, beziehungen = LLM_extrahiere(dokument)
graph.merge(entitaeten, beziehungen)

communities = cluster(graph) # z. B. Leiden
for c in communities:
c.summary = LLM_fasse_zusammen(c) # Community-Summary

Abfrage (online)

if frage_ist_global(frage):
teilantworten = [LLM(frage, c.summary) for c in relevante_communities]
antwort = LLM_reduce(frage, teilantworten) # Global Search
else:
subgraph = graph.traversiere(start=entitaeten_aus(frage), hops=2)
antwort = LLM(frage, subgraph + zugehoerige_chunks) # Local Search
```

Graph RAG vs. Vektor-RAG im direkten Vergleich

Die Entscheidung ist keine Entweder-oder-Frage, sondern eine Frage des Fragetyps und des Budgets. Die folgende Matrix fasst die Unterschiede zusammen.

Die Latenz- und Hybrid-Werte für klassisches RAG stammen aus der Blck-Alpaca-Recherchebasis (Vergleichsmatrix RAG-Architekturen). Die Graph-RAG-Charakteristik basiert auf gesichertem Allgemeinwissen zum GraphRAG-Projekt und zu Knowledge-Graph-Indizes in Frameworks wie LlamaIndex.

Kosten und Komplexität ehrlich kalkuliert

Der größte Unterschied liegt im Indexing. Bei Vektor-RAG ist die teuerste einmalige Operation das Embedding pro Chunk — als Größenordnung nennt die Recherchebasis Indexierungskosten von rund 0,02–0,13 US-Dollar pro einer Million Tokens, mit Anthropic-Prompt-Caching für Contextual Retrieval etwa 1,02 US-Dollar pro Million Document-Tokens (Stand 09/2024). Graph RAG verlangt darüber hinaus mehrere LLM-Durchläufe pro Dokument: Entity-Extraktion, Relationship-Extraktion und Community-Summaries. Das vervielfacht die Indexierungskosten und die Indexierungsdauer.

Konkretes Rechenbeispiel

Angenommen, eine Agentur indexiert für einen Kunden ein Wissenskorpus von 50.000 Dokumenten:

• Vektor-RAG: Einmaliges Embedding plus Hybrid-Index. Hauptkosten sind Embedding-API und Vektor-DB-Hosting. Updates erfolgen inkrementell über stabile Doc-IDs.
• Graph RAG: Pro Dokument fallen mehrere LLM-Aufrufe für die Extraktion an, danach LLM-Aufrufe pro Community für die Summaries. Schon bei mittlerer Korpusgröße entsteht so ein Vielfaches der Indexierungskosten von Vektor-RAG — plus zusätzlicher Betriebsaufwand für Graph-Schema, Deduplizierung von Entitäten und Re-Indexierung bei größeren Änderungen.

Die Faustregel: Graph RAG zahlt sich aus, wenn der Mehrwert beziehungsbasierter Antworten den Mehraufwand rechtfertigt — nicht als Default. Die Blck-Alpaca-Recherche warnt generell vor dem Anti-Pattern "RAG als Silver Bullet"; das gilt für Graph RAG in verschärfter Form, weil hier die Total Cost of Ownership deutlich höher liegt.

Wann Graph RAG, wann nicht

Geeignet, wenn:

• Antworten Informationen über viele Dokumente verknüpfen müssen (Lieferketten, Org-Strukturen, Compliance-Netze, Forschungs- und Patentlandschaften).
• explizite Beziehungen zwischen Entitäten fachlich zentral sind.
• globale Übersichts- und Themenfragen über ein ganzes Korpus beantwortet werden sollen.

Eher nicht, wenn:

• die Fragen überwiegend einzelne Fakten oder eng umrissene Passagen betreffen — hier reicht Hybrid-RAG mit Re-Ranking.
• das Korpus klein ist oder häufig komplett umgeschrieben wird (Graph-Pflege wird zum Engpass).
• das Budget eine LLM-intensive Indexierung nicht trägt.

In der Praxis ist die hybride Architektur am tragfähigsten: Vektor- bzw. Hybrid-Retrieval liefert breite semantische Abdeckung, der Knowledge Graph wird gezielt für Beziehungs- und Multi-Hop-Fragen zugeschaltet. So bleibt Graph RAG ein präziser Aufsatz statt eines teuren Komplettersatzes.

DACH-Hinweis: Datenschutz gilt auch im Graph

Für DACH-Unternehmen ändert Graph RAG nichts an den DSGVO-Grundsätzen. Entitäten und Beziehungen mit Personenbezug sind — wie Embeddings und Chunks bei klassischem RAG — als adressierbare, löschbare Records zu behandeln. Es gelten Zweckbindung und Datenminimierung (Art. 5), eine Rechtsgrundlage für die Verarbeitung (Art. 6) und das Recht auf Löschung (Art. 17). Mandantentrennung, ein Rollen-/Rechtekonzept und EU-Region-Hosting bleiben Pflicht. Die Datenschutzkonferenz adressiert diese Anforderungen in ihrer Orientierungshilfe zu RAG (Stand 2024/2025). Diese Angaben sind informativ und stellen keine Rechtsberatung dar.

Für Agenturen und B2B-Entscheider

Graph RAG ist kein Hype-Ersatz für Vektor-RAG, sondern ein spezialisiertes Werkzeug für beziehungsintensives Wissen. Für Agenturen heißt das: Beginnen Sie mit Hybrid-RAG plus Re-Ranking als solider Standardbasis und führen Sie Graph RAG nur dort ein, wo Multi-Hop- oder Übersichtsfragen den nachweisbaren Geschäftswert liefern. Für B2B-Entscheider ist die zentrale Frage nicht "Welche Technik ist neuer?", sondern "Welche Fragen stellen unsere Nutzer wirklich — und brauchen diese Antworten Beziehungen oder nur Ähnlichkeit?". Blck Alpaca unterstützt bei dieser Abgrenzung, kalkuliert die TCO ehrlich und baut DSGVO-konforme RAG-Architekturen, die mit dem tatsächlichen Bedarf wachsen — vom schlanken Vektor-Index bis zum hybriden Knowledge-Graph-System.