Microsofts GraphRAG-System verbessert die Vollständigkeit von Antworten um 26% und die Diversität um 57% im Vergleich zur reinen Vektorsuche. Diese Zahlen klingen überzeugend. Dann kommt die Rechnung: Derselbe Dokumentenkorpus, der als Vektor-Embedding unter 5 Dollar kostet, schlägt bei GraphRAG mit 50-200 Dollar zu Buche. Bei 10.000 Dokumenten landen Sie im vierstelligen Bereich, bevor eine einzige Abfrage läuft.
Genau diese Kostenlücke erklärt, warum die meisten Teams in der Produktion noch Vektor-RAG einsetzen, und warum diejenigen, die auf Graph RAG umgestiegen sind, das aus sehr konkreten Gründen getan haben. Dieser Beitrag zeigt, welche Gründe das sind, wie sich die vier Typen von Graph RAG unterscheiden und wie Sie Graph-basiertes Retrieval einführen, ohne Ihr Budget zu verbrennen.
Was Graph RAG ist (und was nicht)
Standard-RAG wandelt Dokumente in Vektoren um und findet per Cosinus-Ähnlichkeit die passendsten Textabschnitte. Sie stellen eine Frage, das System liefert die fünf ähnlichsten Chunks, und das LLM generiert eine Antwort daraus. Für direkte Fragen über strukturierte Wissensbasen funktioniert das gut. Es scheitert, wenn die Antwort Informationen aus mehreren Dokumenten verknüpfen muss.
Graph RAG fügt zwischen Dokumenten und Retrieval-Schritt eine Wissensgraph-Schicht ein. Statt nach ähnlichem Text zu suchen, durchläuft das System Beziehungen zwischen Entitäten: Personen, Unternehmen, Konzepte, Ereignisse. Eine Frage wie “Welches Team verantwortet unsere DACH-Compliance?” hängt nicht davon ab, ob genau diese Worte in einem Dokument stehen. Der Graph weiß, dass Alice das Berliner Büro leitet, das Berliner Büro die DACH-Compliance betreut und Alice an die Rechtsabteilung berichtet. Drei Schritte, eine Antwort.
Die entscheidende Unterscheidung: Graph RAG ist nicht einfach “RAG mit einer Graph-Datenbank drangeschraubt.” Microsofts GraphRAG-Paper definiert es als System, das Entitäten und Beziehungen aus Quelldokumenten extrahiert, daraus einen Wissensgraphen aufbaut, per Leiden-Algorithmus Communities verwandter Entitäten erkennt und hierarchische Zusammenfassungen dieser Communities vorgeneriert. Abfragen werden dann an die passende Hierarchieebene geroutet.
Diese Architektur ermöglicht zwei Dinge, die Vektor-RAG nicht kann: globale Abfragen (“Fasse die Hauptthemen aller Kundenbeschwerden dieses Quartals zusammen”) und Multi-Hop-Reasoning (“Welche Lieferanten in unserem Netzwerk wurden von Partnern, die auch unsere Wettbewerber beliefern, wegen Compliance-Problemen gemeldet?”).
Wann Vektor-RAG weiterhin genügt
Nicht jedes Retrieval-Problem braucht einen Graphen. Vektor-RAG erledigt direkte Faktenabfragen effizient: “Was ist unsere Rückgabepolitik?” “Wann läuft der Vertrag aus?” Diese Fragen passen sauber auf einzelne Chunks. Einen Wissensgraphen dafür einzusetzen erhöht Kosten und Komplexität, ohne die Genauigkeit zu verbessern. Die Faustregel: Wenn Ihre Fragen Single-Hop sind und Ihr Korpus gut strukturiert ist, reicht Vektor-RAG aus.
Die vier Typen von Graph RAG
Neo4js Taxonomie unterscheidet vier Muster mit unterschiedlichen Kosten, Komplexitäts- und Leistungsprofilen. Zu verstehen, welchen Typ Sie brauchen, verhindert den häufigen Fehler, Microsofts volle GraphRAG-Pipeline zu implementieren, wenn ein einfacherer Ansatz genügen würde.
Typ 1: Graph-erweiterte Vektorsuche
Die einfachste Form. Sie behalten Ihre bestehende Vektor-RAG-Pipeline und ergänzen Graph-Metadaten als Filter oder Re-Ranker. Eine Produktsuche könnte Vektor-Ähnlichkeit nutzen, um relevante Artikel zu finden, und dann einen Produkttaxonomie-Graphen einsetzen, um Ergebnisse aus derselben Kategorie höher zu bewerten.
Der Implementierungsaufwand ist minimal: Graph-Datenbank neben dem Vektorspeicher, Chunks mit Entity-IDs taggen, graphbasierte Filter in die Retrieval-Abfrage einbauen. Keine LLM-gestützte Entitätsextraktion nötig. Tools wie LlamaIndex Knowledge Graph Index unterstützen dieses Muster direkt.
Typ 2: Graph-gesteuertes Retrieval
Der Retrieval-Schritt selbst nutzt Graph-Traversierung. Statt Vektor-Ähnlichkeit zu berechnen, startet das System bei einer Abfrage-Entität, wandert durch den Graphen zu verwandten Entitäten und deren zugehörigen Textabschnitten, und speist diese ins LLM ein. So werden Multi-Hop-Fragen gelöst, an denen Vektorsuche komplett scheitert.
Neo4js Implementierung kombiniert Cypher-Graph-Abfragen mit Textchunk-Retrieval: Der Agent identifiziert Schlüsselentitäten in der Nutzerfrage, fragt den Graphen nach verbundenen Entitäten innerhalb von N Hops ab, ruft die zugehörigen Textabschnitte ab und übergibt den kombinierten Kontext an das LLM.
Typ 3: Graph-basierte Zusammenfassung (Microsoft GraphRAG)
Das ist, was die meisten meinen, wenn sie “GraphRAG” sagen. Microsofts System lässt ein LLM über den gesamten Korpus laufen, um Entitäten und Beziehungen zu extrahieren, baut einen Wissensgraphen auf, wendet den Leiden-Community-Detection-Algorithmus an und generiert vorab Zusammenfassungen auf mehreren Hierarchieebenen. Abfragen werden dann an die passende Ebene geroutet.
Das Update vom Januar 2025 führte Dynamic Community Selection ein, das den Token-Verbrauch um 79% senkte, bei gleichbleibender Antwortqualität. Damit sanken die Kosten für globale Suchen deutlich, aber die Indexierung erfordert weiterhin die Verarbeitung jedes Dokuments durch ein LLM für die Entitätsextraktion, was 58% der gesamten Indexierungstokens ausmacht.
Typ 4: Temporale Wissensgraphen (Agent Memory)
Graph RAG angewandt auf Agent-Memory statt Dokumenten-Retrieval. Systeme wie Zeps Graphiti-Framework und Mem0 bauen temporale Wissensgraphen aus Agent-Interaktionen: Jeder Fakt bekommt einen Zeitstempel, widersprüchliche Fakten erzeugen explizite supersedes-Beziehungen, und das Retrieval priorisiert das aktuellste und relevanteste Wissen.
Graphiti, aufgebaut auf Neo4j, nutzt einen hybriden Ansatz: Es unterhält sowohl einen Wissensgraphen aus Entitäten und Beziehungen als auch einen Embedding-basierten Ähnlichkeitsindex. Abfragen können Graph-Traversierung (“Was hat dieser Kunde über Preise gesagt?”) mit temporaler Filterung (“Nur Fakten der letzten 30 Tage”) und semantischer Ähnlichkeit (“Themen rund um Budgetbedenken”) kombinieren. Mem0 hat 10,9 Millionen Dollar Seed-Finanzierung erhalten, um genau diese Infrastruktur für produktive Agent-Deployments zu bauen.
Microsoft GraphRAG vs LightRAG vs Graphiti: Die echten Trade-offs
Drei Frameworks dominieren den Graph-RAG-Bereich, jedes zielt auf einen anderen Punkt im Spannungsfeld von Komplexität, Kosten und Leistungsfähigkeit.
Microsoft GraphRAG
Das Schwergewicht. Volle Entitätsextraktion, Community-Detection, hierarchische Zusammenfassung. Mit rund 14.000 GitHub-Stars das am besten erforschte und benchmarkierte System.
Stärken: Beste globale Abfrageleistung. Die Community-Hierarchie bewältigt “Fasse alles über X zusammen”-Anfragen, die kein anderer Ansatz schafft. DRIFT Search (Ende 2024 veröffentlicht) kombiniert lokale und globale Suche für 40-60% Kostenreduktion bei komplexen Abfragen.
Schwächen: Die Indexierungskosten sind erheblich. Ein 500-Seiten-Korpus braucht etwa 45 Minuten und kostet 50-200 Dollar bei GPT-4-Preisen. Re-Indexierung bei Dokumentenänderungen bedeutet, die gesamte Pipeline erneut durchlaufen zu lassen, oder eine inkrementelle Update-Logik zu pflegen, die Microsoft noch verfeinert.
LightRAG
Die pragmatische Wahl. LightRAG (über 14.100 GitHub-Stars) reduziert GraphRAG auf das Wesentliche: einfachere Entitätsextraktion, flache Graph-Struktur ohne Community-Detection und Dual-Mode-Retrieval, das Graph-Traversierung mit Vektor-Ähnlichkeit kombiniert.
Stärken: Die Indexierung desselben 500-Seiten-Korpus dauert etwa 3 Minuten und kostet rund 0,50 Dollar. Qualitäts-Benchmarks zeigen 70-90% von GraphRAGs Leistung bei 1/100 der Kosten. Die flache Graph-Struktur macht inkrementelle Updates unkompliziert.
Schwächen: Ohne hierarchische Community-Zusammenfassung performen globale Abfragen (“Was sind die Hauptthemen über alle Dokumente hinweg?”) deutlich schlechter. Für eng gefasste Abfragen über klar definierte Domänen ist der Qualitätsunterschied minimal. Für breite analytische Anfragen ist er real.
Neo4j Graphiti
Der Agent-Memory-Spezialist. Graphiti ist speziell für temporale Wissensgraphen als Agent-Memory gebaut, nicht für Dokumenten-Q&A. Es integriert sich nativ mit Neo4j und unterstützt hybrides Graph+Vektor-Retrieval.
Stärken: Bestes temporales Reasoning der drei Frameworks. Explizite Fakt-Versionierung, Beziehungs-Invalidierung und zeitbewusstes Retrieval machen es zur stärksten Wahl für Agenten, die nachverfolgen müssen, wie sich Wissen entwickelt.
Schwächen: Erfordert eine Neo4j-Instanz. Nicht für großangelegte Dokumenten-Ingestion konzipiert. Am besten für Agent-Interaktionshistorien und strukturiertes Wissen, das sich über die Zeit verändert.
| Feature | Microsoft GraphRAG | LightRAG | Graphiti |
|---|---|---|---|
| Primärer Einsatzzweck | Dokumentenanalyse & Zusammenfassung | Dokumenten-Q&A | Agent Memory |
| Indexierungskosten (500 Seiten) | 50-200 $ | ~0,50 $ | Variiert nach Interaktionsvolumen |
| Indexierungszeit (500 Seiten) | ~45 Min. | ~3 Min. | Echtzeit pro Interaktion |
| Globale Abfragen | Hervorragend | Eingeschränkt | Nicht dafür konzipiert |
| Multi-Hop-Reasoning | Stark | Moderat | Stark (im Agent-Kontext) |
| Temporales Bewusstsein | Keines | Keines | Kernfeature |
| Inkrementelle Updates | Komplex | Einfach | Nativ |
Die Produktionskosten, über die niemand spricht
Die Indexierungskostenvergleiche oben erzählen nur die halbe Geschichte. Produktive Graph-RAG-Systeme haben drei Kostenschichten, die die meisten Evaluierungen übersehen.
Schema-Design
Der schwierigste Teil von Graph RAG ist nicht das Framework. Es ist das Ontologie-Design: Welche Entitätstypen sind relevant, welche Beziehungstypen sollen extrahiert werden, wie granular soll es sein. Eine juristische Wissensbasis braucht möglicherweise Vertrag -> enthält -> Klausel -> referenziert -> Gesetz -> ausgelegt_durch -> Präzedenzfall. Stimmt das Schema nicht, verpasst der Graph kritische Verbindungen oder ertrinkt in Rauschen.
Microsoft GraphRAG umgeht das durch LLM-gestützte offene Extraktion: Das Modell entscheidet, welche Entitäten und Beziehungen existieren. Das funktioniert für Exploration, produziert aber bei Skalierung verrauschte Graphen. Produktionsteams, die Graph RAG erfolgreich eingesetzt haben (darunter Unternehmen wie Goldman Sachs und Deloitte), investierten Wochen in Ontologie-Design, bevor sie eine Zeile Retrieval-Code schrieben.
Für DACH-Unternehmen kommt eine weitere Dimension hinzu: DSGVO-Konformität. Graph RAG bietet hier einen Vorteil, weil jede Retrieval-Entscheidung über den Graphen nachvollziehbar ist. Im Gegensatz zur Black-Box-Vektorähnlichkeit können Sie bei einem Graph exakt erklären, warum ein bestimmtes Ergebnis gefunden wurde. Für den Einsatz in Hochrisiko-KI-Systemen unter dem EU AI Act ist diese Nachvollziehbarkeit kein Nice-to-have, sondern eine Pflicht.
Graph-Wartung
Dokumente ändern sich. Entitäten verschmelzen, teilen sich oder werden irrelevant. Eine Vektordatenbank handhabt Updates trivial: alte Vektoren löschen, neues Dokument embedden, einfügen. Ein Wissensgraph-Update erfordert Re-Extraktion der Entitäten aus dem geänderten Dokument, Abgleich mit bestehenden Graph-Knoten (ist “Microsoft Corp” dasselbe wie “Microsoft”?), Aktualisierung betroffener Beziehungen und gegebenenfalls erneute Community-Detection.
FalkorDB wirbt mit Sub-Millisekunden-Abfragelatenz und 600K Abfragen pro Sekunde als schnellere Graph-Datenbank-Alternative zu Neo4j. Aber Abfragegeschwindigkeit ist selten der Engpass. Den Graphen aktuell zu halten, während sich der Korpus weiterentwickelt, kostet die meiste Ingenieurzeit.
Monitoring der Retrieval-Qualität
Vektor-RAG-Fehler sind relativ einheitlich: Schlechte Ergebnisse sehen aus wie falsche Chunks. Graph-RAG-Fehler sind vielfältiger: fehlende Entitätsextraktion, falsche Beziehungstypen, veraltete Community-Zusammenfassungen oder Graph-Traversierungspfade, die relevante Knoten verfehlen. Monitoring erfordert nicht nur Retrieval-Precision/Recall, sondern auch Entitätsextraktionsgenauigkeit, Beziehungsvollständigkeit und Graph-Abdeckung.
Graph RAG einführen, ohne das Budget zu sprengen
Der häufigste Fehler: Teams springen direkt zu Typ 3 (Microsoft GraphRAG), weil es die besten Benchmarks hat. Ein klügerer Weg folgt der Vier-Typen-Progression.
Mit Typ 1 starten: Metadaten-Anreicherung
Nehmen Sie Ihre bestehende Vektor-RAG-Pipeline und ergänzen Sie graphbasierte Metadaten. Haben Sie einen Produktkatalog, bauen Sie einen einfachen Taxonomie-Graphen und nutzen Sie ihn zum Filtern oder Re-Ranking der Vektorsuchergebnisse. Haben Sie eine Kunden-Wissensbasis, erstellen Sie einen Entity-Graphen aus Kunden, Produkten und Interaktionen.
Das erfordert keine LLM-gestützte Extraktion. Sie können den Graphen aus strukturierten Daten bauen, die Sie bereits haben: CRM-Datensätze, Produktdatenbanken, Organigramme. Die Kosten sind die Graph-Datenbank selbst (Neo4j Community Edition ist kostenlos, Managed Services starten bei etwa 65 Dollar/Monat).
Zu Typ 2 übergehen, wenn Multi-Hop relevant wird
Sobald Ihre Abfragen konsistent Informationen aus mehreren Dokumenten verknüpfen müssen, implementieren Sie graph-gesteuertes Retrieval. Der Auslöser ist konkret: Sie bemerken, dass Nutzer Fragen stellen wie “Welche unserer Lieferanten arbeiten auch mit [Wettbewerber]?” oder “Welche Vorschriften betreffen die Produkte, die wir in [Region] verkaufen?”, an denen Vektorsuche scheitert.
In dieser Phase brauchen Sie Entitätsextraktion, können aber kleinere Modelle (GPT-4o-mini oder Claude Haiku) einsetzen und die Extraktion auf die spezifischen Entitätstypen fokussieren, die Ihre Anwendungsfälle erfordern. Gezielte Extraktion kostet einen Bruchteil der offenen Extraktion.
Typ 3 nur für globale Analytik
Microsofts Community-Zusammenfassung glänzt für einen spezifischen Anwendungsfall: Abfragen, die Informationen über den gesamten Korpus synthetisieren müssen. “Was sind die fünf größten Risikofaktoren in allen unseren Lieferantenverträgen?” “Fasse die Sentiment-Trends im Kundenfeedback dieses Quartals zusammen.” Wenn Ihre Nutzer diese Art Fragen nicht stellen, sind die Kosten von Typ 3 nicht gerechtfertigt.
Falls doch, evaluieren Sie zuerst LightRAG. Bei 70-90% von GraphRAGs Qualität zu 1/100 der Kosten ist es der richtige Startpunkt, es sei denn, Ihre Benchmarks zeigen konkret, dass der Qualitätsunterschied für Ihren Anwendungsfall relevant ist.
Typ 4 für Agent Memory (nicht Dokumenten-RAG)
Wenn Ihr primärer Bedarf Agent Memory ist, nicht Dokumenten-Retrieval, überspringen Sie die Typen 1-3 und implementieren Sie Graphiti oder Mem0. Diese Systeme sind für Echtzeit-Wissensakkumulation aus Agent-Interaktionen gebaut, nicht für Batch-Dokumentenverarbeitung. Sie lösen ein grundlegend anderes Problem: Agenten dabei zu helfen, sich an ihre eigene Geschichte zu erinnern und darüber zu schlussfolgern.
Häufig gestellte Fragen
Was ist Graph RAG und wie unterscheidet es sich von Vektor-RAG?
Graph RAG ergänzt Retrieval-Augmented Generation um eine Wissensgraph-Schicht. Statt ähnliche Textabschnitte per Vektor-Ähnlichkeit zu finden, durchläuft es Beziehungen zwischen Entitäten (Personen, Unternehmen, Konzepte), um kontextuell verknüpfte Informationen abzurufen. Das ermöglicht Multi-Hop-Reasoning und globale Zusammenfassungsabfragen, kostet aber 10-40x mehr bei der Indexierung.
Wie viel kostet Graph RAG im Vergleich zu Vektor-RAG?
Für einen 500-Seiten-Korpus kostet die Microsoft GraphRAG-Indexierung 50-200 Dollar und dauert etwa 45 Minuten. LightRAG indexiert denselben Korpus für rund 0,50 Dollar in 3 Minuten. Standard-Vektor-RAG-Embedding kostet unter 5 Dollar. Der Kostenunterschied entsteht durch die LLM-gestützte Entitätsextraktion, die etwa 58% der gesamten GraphRAG-Indexierungstokens ausmacht.
Wann sollte ich Graph RAG statt Vektor-RAG einsetzen?
Graph RAG lohnt sich, wenn Abfragen Informationen aus mehreren Dokumenten verknüpfen müssen (Multi-Hop-Reasoning), wenn globale Zusammenfassungen über große Korpora nötig sind, oder wenn die Domäne komplexe Entitätsbeziehungen aufweist (Recht, Gesundheitswesen, Lieferketten). Für einfache Faktenabfragen über gut strukturierte Inhalte ist Vektor-RAG schneller, günstiger und ausreichend.
Ist Graph RAG DSGVO-konform einsetzbar?
Graph RAG bietet sogar Vorteile für die DSGVO-Konformität: Jede Retrieval-Entscheidung ist über den Graphen nachvollziehbar, im Gegensatz zur Black-Box-Vektorähnlichkeit. Sie können exakt erklären, warum bestimmte Informationen abgerufen wurden. Für Hochrisiko-KI-Systeme unter dem EU AI Act ist diese Nachvollziehbarkeit eine Pflicht, nicht nur ein Vorteil.
Kann ich Graph RAG und Vektor-RAG kombinieren?
Ja, und die meisten Produktivsysteme tun genau das. Der hybride Ansatz routet einfache Faktenabfragen an Vektor-RAG und komplexe Multi-Hop- oder analytische Abfragen an Graph RAG. Neo4js Graphiti-Framework unterstützt hybrides Graph+Vektor-Retrieval nativ. Der empfohlene Adoptionspfad: Mit graph-erweiterter Vektorsuche (Typ 1) starten und schrittweise graph-gesteuertes Retrieval (Typ 2) einführen.