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

Die Grenze eines einzelnen Abrufs: Beziehungen werden nicht automatisch zusammengeführt.

Fiktives, vereinfachtes Beispiel: Die folgenden Angaben illustrieren eine Abfrage. Ein daraus abgeleiteter Grund bleibt eine Hypothese, bis die zugrunde liegenden Quellen geprüft sind.

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 Angaben sind über mehrere Dokumente und Datenpunkte verteilt. Ein einzelner Vector-RAG-Abruf verbindet die Bruchstücke nicht automatisch; zusätzliche Retrieval- und Zusammenführungslogik kann das leisten.

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 ausgewählten Kontext; Vollständigkeit und Richtigkeit bleiben zu prüfen

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. Tabelle 2 von GraphRAG-Bench v1 berichtet für den Novel-Datensatz mit der dort verwendeten Genauigkeitsmetrik 60,9 für RAG mit Reranking und 60,1 für HippoRAG2; Microsoft GraphRAG global steht in einer separaten Zeile bei 36,9. Das sind Ergebnisse dieses Datensatzes und dieser Methoden, keine allgemeine Rangliste.

Bei verketteten Fragen kehrt sich das auf demselben Novel-Datensatz um. Tabelle 2 von GraphRAG-Bench v1 berichtet 53,4 für HippoRAG2 und 42,9 für RAG mit Reranking. Der Unterschied gilt für diese Aufgabenart, Metrik und Version.

Der Effekt hängt vom Datensatz und der Retriever-Konfiguration ab. HippoRAG v3 berichtet Recall@5 für ColBERTv2 gegenüber HippoRAG mit Contriever: auf 2WikiMultiHopQA 68,2 gegenüber 89,5, auf MuSiQue 49,2 gegenüber 52,1. Das ist kein kontrollierter Test der Graphstruktur allein.

Der Tokenvergleich ist ebenfalls eng begrenzt. Abbildung 8 von GraphRAG-Bench v1 berichtet auf dem Novel-Datensatz durchschnittlich 879 Prompt-Token pro Anfrage für V-RAG, 38.707 für Microsoft GraphRAG lokal und 331.375 für Microsoft GraphRAG global. Diese Versuchsanordnung belegt weder gesamte Betriebskosten noch eine allgemeine Tokenregel.

Vorsicht bei Bewertungen durch ein zweites Sprachmodell. Zeng et al. v1, Abschnitt 5.1, ließen zwei identische LightRAG-Instanzen gegeneinander antreten; das Protokoll erzeugte eine 90:10-Verteilung. Die Autoren führen das auf Positions- und Einzeldurchlauf-Bias zurück.

Microsoft verwendet in der zitierten Untersuchung ein zweites Sprachmodell zur Bewertung mehrerer Qualitätsdimensionen. Solche Modellurteile sind protokollabhängig und begründen keine universelle Rangfolge.

Warum überhaupt komprimieren?

Die Position einer Information im Kontextfenster kann beeinflussen, ob ein Modell sie nutzt. Liu et al. untersuchen diesen Effekt für lange Kontexte; die Übertragbarkeit hängt von Modell, Aufgabe und Aufbau ab.

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)
- Zu prüfende Hypothese: Energieausweis als möglicher Engpass
- Anbieter: EnergieCheck GmbH (2x kontaktiert, keine Antwort)
- Aktion: Alternative Anbieter verfügbar

Eine gezielte Auswahl kann irrelevanten Kontext verringern, aber auch benötigte Angaben auslassen. Qualität, Tokenbedarf und Betriebskosten müssen im vollständigen Verfahren gemessen werden.

Multi-Hop Reasoning

Eine mögliche Anwendung 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?"

Vector RAG kann solche Antworten über wiederholtes Retrieval ebenfalls erreichen. Dafür braucht es eine passende Abfrage- und Zusammenführungslogik; die Qualität hängt von Datensatz, Retriever und Auswertung ab.

Wann GraphRAG nutzen?

Beschriebene Osiris-Zielarchitektur

Die auf dieser Website beschriebene Zielarchitektur sieht Neo4j für graphbasierte Abfragen vor. Datenumfang, Anbindungen und Betriebsstatus müssen je Projekt geprüft werden.

1. Datenübernahme: Eine projektspezifische Anbindung kann freigegebene CRM-Daten in ein Graphmodell übertragen; Umfang und Aktualisierung sind vorab zu prüfen.
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