Was ist GraphRAG? Der Hybrid-Ansatz für präzise AI-Antworten

Das Problem mit klassischem RAG

RAG (Retrieval Augmented Generation) ist der Standard um LLMs mit externem Wissen zu verbinden. Der Ablauf:

1. Dokumente werden in Chunks zerlegt und als Vektoren gespeichert
2. Bei einer Frage wird der semantisch ähnlichste Chunk gesucht
3. Dieser Chunk wird als Kontext ans LLM gegeben

Das Problem: Beziehungen gehen verloren.

Wenn Sie fragen "Warum stockt der Deal Mozartstraße?", muss das System verstehen:

• Deal Mozartstraße ist verbunden mit Objekt Mozartstraße
• Objekt Mozartstraße hat einen fehlenden Energieausweis
• Der Energieausweis fehlt seit 8 Tagen
• Der zuständige Anbieter wurde 2x kontaktiert

Diese Information ist über mehrere Dokumente und Datenpunkte verteilt. Vector RAG findet die Bruchstücke, führt sie aber nicht zusammen.

GraphRAG: Der Hybrid-Ansatz

GraphRAG löst das durch einen zweistufigen Prozess:

Stufe 1: Entity Extraction & Graph Building

Aus Ihren Daten werden Entitäten (Kunden, Objekte, Deals, Dokumente) und ihre Beziehungen extrahiert und in einem Knowledge Graph gespeichert.

[Deal: Mozartstraße]
       |
       |--BETRIFFT--> [Objekt: Mozartstraße 15]
       |                        |
       |--FEHLT--> [Dokument: Energieausweis]
       |                        |
       |--KONTAKTIERT--> [Anbieter: EnergieCheck GmbH]
                                |
                          Status: "2x kontaktiert, keine Antwort"

Stufe 2: Graph-Augmented Retrieval

Bei einer Frage passiert Folgendes:

1. Entity Recognition: "Deal Mozartstraße" wird im Graph identifiziert
2. Graph Traversal: Das System folgt den Beziehungen (BETRIFFT, FEHLT, KONTAKTIERT)
3. Subgraph Extraction: Nur die relevanten Knoten und Kanten werden extrahiert
4. Context Compression: Der Subgraph wird in kompakten Text umgewandelt, statt ganze Dokumente mitzugeben
5. LLM Generation: Das LLM antwortet basierend auf dem komprimierten, aber vollständigen Kontext

Was die Messungen zeigen

An dieser Stelle stehen in vielen Texten Zahlen wie "3,4x genauer" oder "100x weniger Token". Beide halten einer Prüfung nicht stand. Belegen lässt sich Folgendes.

Beim einfachen Faktenabruf liegt klassisches RAG vorn. GraphRAG-Bench vergleicht beide Ansätze auf denselben Aufgaben: klassisches RAG mit Reranking erreicht 60,9 Punkte Genauigkeit, das beste Graphverfahren 60,1, Microsofts GraphRAG im globalen Modus 36,9.

Bei verketteten Fragen kehrt sich das um. Auf denselben Daten, bei Fragen die mehrere Fakten verbinden: 53,4 für das beste Graphverfahren gegen 42,9 für klassisches RAG.

Der Effekt schwankt stark je nach Datensatz. HippoRAG hebt den Recall@5 auf 2WikiMultiHopQA von 68,2 auf 89,5, auf MuSiQue dagegen nur von 49,2 auf 52,1.

Bei fairem Token-Budget schrumpft der Vorsprung. Graph-Verfahren holen sich pro Anfrage mehr Kontext. Gibt man klassischem RAG dasselbe Budget, steigt es auf MultiHop-RAG von 65,8 auf 71,0 Punkte und liegt damit gleichauf mit dem Graph-Verfahren (71,2). Übrig bleibt ein Vorsprung bei zeitbezogenen und vergleichenden Fragen: 43,7 gegen 49,1.

Zum Token-Verbrauch steht die verbreitete Behauptung auf dem Kopf: Graph-Verfahren brauchen mehr Token, nicht weniger. Auf GraphRAG-Bench liegt klassisches RAG bei 879 Token pro Anfrage, Microsofts GraphRAG lokal bei 38.707 und global bei 331.375. Microsofts belegte Einsparung von 9 bis 43 gilt gegenüber der Zusammenfassung der Rohtexte, nicht gegenüber der Vektorsuche. Wer GraphRAG einsetzt, kauft Fähigkeit, nicht Ersparnis.

Vorsicht bei Bewertungen durch ein zweites Sprachmodell. Zeng et al. ließen ein Verfahren gegen eine identische Kopie seiner selbst antreten. Das übliche Protokoll erklärte die eine Kopie mit 90 zu 10 zum Sieger. Positions- und Längeneffekte erzeugen Vorsprünge, wo keine sind.

Microsoft bewertet die Antwortqualität über ein zweites LLM als Schiedsrichter, nicht über eine Genauigkeitsmetrik. Beim Kriterium Direktheit gewinnt Vector RAG in allen Vergleichen.

Warum überhaupt komprimieren?

Der Grund ist nicht nur der Preis. Die Position einer Information im Kontextfenster entscheidet mit darüber, ob das Modell sie nutzt. Liu et al. haben das gemessen: Steht die entscheidende Stelle in der Mitte eines langen Kontexts, fällt GPT-3.5-Turbo im Multi-Dokument-QA unter den Wert, den es ganz ohne Dokumente erreicht (56,1 Prozent). Ein größeres Kontextfenster behebt das nicht.

Vector RAG: Gibt ganze Dokument-Chunks ans LLM, oft mehrere.

GraphRAG: Gibt nur den extrahierten Subgraph ans LLM:

Kontext für LLM:
- Deal: Mozartstraße (Status: Stockt)
- Grund: Energieausweis fehlt seit 8 Tagen
- Anbieter: EnergieCheck GmbH (2x kontaktiert, keine Antwort)
- Aktion: Alternative Anbieter verfügbar

Weniger Kontext heißt hier nicht nur weniger Kosten, sondern weniger Platz, an dem eine wichtige Angabe untergehen kann.

Multi-Hop Reasoning

Die Killer-Fähigkeit von GraphRAG: Fragen beantworten die mehrere "Sprünge" durch den Graph erfordern:

1-Hop: "Welche Dokumente fehlen bei Deal Mozartstraße?"

2-Hop: "Welche Kunden haben Deals mit fehlenden Dokumenten?"

3-Hop: "Welche Notare betreuen Deals von Kunden aus Hamburg?"

Jeder Hop ist eine Beziehung im Graph. Vector RAG kann solche Fragen über wiederholtes Suchen ebenfalls lösen, braucht dafür aber mehrere Durchläufe und verliert dabei häufiger den Faden.

Wann GraphRAG nutzen?

Use Case	Vector RAG	GraphRAG
Dokumenten-QA ("Was steht im Vertrag?")	Stark	Gleichauf
Einzelne Fakten nachschlagen	Stark	Eher schwächer
Beziehungsfragen ("Wer betreut wen?")	Schwach	Kernstärke
Aggregationen ("Wie viele Deals stocken?")	Unzuverlässig	Native
Diagnose ("Warum stockt Deal X?")	Rät bei Lücken	Folgt dem Pfad
CRM/ERP Integration	Umständlich	Native

Wie Osiris GraphRAG implementiert

Osiris nutzt Neo4j als Knowledge Graph Backend und implementiert GraphRAG so:

1. Kontinuierliche Extraktion: Daten aus PropStack/CRM werden laufend in den Graph synchronisiert
2. Schema-Design: Immobilien-spezifische Ontologie (Objekt, Deal, Kunde, Dokument, Aktivität)
3. Cypher Queries: Optimierte Graph-Queries für typische Fragen
4. MCP Integration: Das LLM fragt Osiris via Model Context Protocol
5. Context Compression: Subgraphen werden in LLM-optimierte Prompts umgewandelt

→ Osiris im Detail ansehen