GraphRAG: wenn Wissen als Graph Vektoren schlägt

Ein Unternehmen, das technische Dokumentationen für ein Dutzend Produktlinien erstellt, bemerkt ein Problem: Der RAG-Assistent zitiert zwar hervorragend Textstellen, kann aber die Frage „Welche Komponenten aus der älteren Linie X sind mit der neuen Linie Y kompatibel und welche Zertifikate umfasst diese Kombination?“ nicht beantworten. Das ist eine mehrstufige Frage, die Informationen aus drei verschiedenen Dokumenten verbindet. Die semantische Suche liefert die am besten passenden Fragmente separat, baut aber keine Brücke zwischen ihnen.

Genau hier liegt die Nische von GraphRAG.

Ein Wissensgraph ist eine Datenstruktur aus Knoten (Entitäten) und Kanten (Relationen). Im Unternehmenskontext sind Knoten Produkte, Prozesse, Abteilungen, Regularien, Kunden; Kanten sind Relationen wie „erfordert“, „ersetzt“, „unterliegt“, „produziert von“.

Der Aufbau eines Graphen aus Dokumenten erfolgt in drei Schritten.

Extraktion von Entitäten und Relationen. Ein Sprachmodell liest jeden Dokumentenabschnitt und extrahiert Paare (Entität, Relation, Entität). Aus dem Satz „Komponente A-7 erfordert Zertifikat CE vor der Implementierung in der EU“ extrahiert das Modell die Knoten A-7 und CE sowie die Kante „erfordert“. Dies ist der kostspieligste Teil: Bei 10.000 Fragmenten und einem lokalen Modell dauert die Verarbeitung zwischen einigen Dutzend und einigen Hundert Minuten.

Deduplizierung und Normalisierung. Dasselbe Produkt kann als „A-7“, „Komponente A7“, „Modul A-7 rev.2“ auftauchen. Ohne Normalisierung fragmentiert sich der Graph, statt Wissen zu verbinden. Hier ist eine Entscheidung nötig: ein manuell von Fachexperten erstelltes Synonymwörterbuch oder ein zusätzlicher LLM-Schritt zur Erkennung von Aliasen. Beide Optionen haben Kosten.

Index + Vektordatenbank. Beim vollständigen GraphRAG verzichtet man nicht auf Embeddings: Man speichert parallel einen relationalen Graphen (z. B. Neo4j, Memgraph oder für kleinere Korpora NetworkX) und einen Vektorindex für die Suche nach einem Einstiegspunkt. Die Abfrage geht zunächst zum Vektor, um nahe Entitäten zu finden, und dann zum Graphen, um die Relationen nachzuverfolgen.

Die Vektorsuche misst semantische Ähnlichkeit. Ein Graph misst Verbindungen. Das sind unterschiedliche Fragen.

Mehrstufige Fragen (Multi-Hop). „Welche Regularien betreffen Produkt X, das wir an Sektor Y verkaufen?“ Der Vektor liefert thematisch nahe Dokumente. Der Graph kann den Pfad durchlaufen: Produkt X → CE-Zertifikat → Maschinenrichtlinie → Artikel 12 → Audit-Pflicht. Jeder Schritt ist eine Kante im Graphen, die nicht unbedingt in einem Dokumentenfragment explizit vorhanden ist.

Entitätszentrische Abfragen. „Nenne alle Lieferanten von Komponenten, die in der Produktlinie Z verwendet werden.“ Der Vektor durchsucht Fragmente und könnte marginal erwähnte Lieferanten übersehen. Der Graph mit Kanten wie „Lieferant-Komponente-Linie“ antwortet vollständig – vorausgesetzt, der Graph ist vollständig.

Konsistenz des Wissens zwischen Dokumenten. Wenn dieselbe Entität in Dokumenten aus verschiedenen Jahren auftaucht und sich ihre Attribute ändern, hilft der Graph, die Historie und Versionen nachzuverfolgen. Klassisches RAG könnte widersprüchliche Fragmente ohne Hinweis auf den Widerspruch zurückgeben.

Erklärbarkeit und Entscheidungsnachweis. Eine aus einem Graphen generierte Antwort kann den genauen Pfad der Knoten zeigen: „Diese Antwort ergibt sich aus der Relation A→B→C.“ Das ist wichtig für Systeme, die der AI Act als hohes Risiko einstuft und die den Anforderungen an Erklärbarkeit genügen müssen.

Für die meisten Unternehmensimplementierungen von RAG reicht ein Vektorindex mit hybrider Suche aus. Ein Graph macht Sinn, wenn:

• der Korpus eine klare Entität-Relation-Entität-Struktur aufweist, die sinnvoll extrahiert werden kann (Produktdokumentation, Rechtsregister, domänenspezifische Wissensdatenbanken);
• Nutzerfragen tatsächlich die Verknüpfung von Informationen aus mehreren Quellen über gemeinsame Knoten erfordern;
• Ressourcen für die Wartung des Graphen vorhanden sind, da jede Dokumentenaktualisierung eine Re-Extraktion oder Anpassung der Kanten erfordert.

GraphRAG nicht einsetzen, wenn:

• der Korpus aus losen beschreibenden Dokumenten ohne klare Entitäten besteht (strategische Berichte, Meeting-Notizen, Korrespondenz);
• Fragen hauptsächlich beschreibend und konzeptionell sind (hier kommt die semantische Suche gut zurecht);
• weniger als ein paar tausend Dokumente vorhanden sind und klassisches RAG einen Recall von über 0,85 im Golden Set erreicht;
• das Token-Budget und die Extraktionszeit begrenzt sind und der Implementierungszeitplan kurz ist.

Wir bei Cashcrown empfehlen standardmäßig, mit klassischem RAG und hybrider Suche zu beginnen und den Recall zu messen. GraphRAG kommt ins Spiel, wenn die Daten konkrete Abfrageklassen zeigen, die der Vektor nicht abdeckt.

Die Extraktion eines Graphen aus 50.000 Fragmenten mit einem lokalen Modell (z. B. llama3.1:70b auf Ollama) dauert realistisch 8–24 Stunden und erfordert GPU-Speicher. Bei kommerziellen APIs kostet es einige Dutzend bis einige Hundert Dollar für eine einmalige Extraktion, plus ähnliche Kosten bei größeren Korpusaktualisierungen. Die Zahlen hängen stark von der Fragmentlänge und der Komplexität des Extraktionsprompts ab: Wir geben Spannen an, keine Garantie.

Ein typischer GraphRAG-Stack im Jahr 2026 sieht so aus:

Schritt 1: Chunking und Extraktion. Dokumente durchlaufen Chunking und gelangen zum Extraktionsmodell. Der Prompt weist das Modell an, strukturiertes JSON mit Paaren (Subjekt, Prädikat, Objekt) zurückzugeben. Es lohnt sich, structured output mit JSON-Schema-Validierung zu verwenden, da der Rohtext des Modells bei der Relationsextraktion inkonsistent sein kann.

Schritt 2: Graphaufbau. Die Extrakte gelangen in eine Graphdatenbank oder eine einfache In-Memory-Struktur. Bei kleineren Korpora (bis zu einigen tausend Knoten) reicht NetworkX in Python. Bei größeren und bei Bedarf an Cypher-Abfragen sind Neo4j oder Memgraph mit Self-Hosting eine Überlegung wert.

Schritt 3: Retrieval. Die Nutzerabfrage geht zunächst zum Vektorindex (Einstiegspunkt in den Graphen). Aus den Top-k-Vektorknoten expandiert das System die Nachbarschaft im Graphen: Es holt Knoten, die 1–2 Kanten entfernt sind. Dieser Satz gelangt in den Kontext des LLM.

Schritt 4: Generierung mit Pfadzitat. Das Modell generiert eine Antwort und gibt den Knotenpfad als Quelle an. Das ist kein technisches Muss, erhöht aber das Nutzervertrauen und erfüllt die Erklärbarkeitsanforderungen bei Systemen unter AI Act.

Schritt 5: Observability. Miss separat den Recall von Vektorabfragen (wie viele Treffer in den Top-5) und den Recall von Graphpfaden (ob Multi-Hop-Fragen vollständige Antworten liefern). Ohne Trennung dieser Metriken weißt du nicht, welche Komponente optimiert werden muss.

Ein ähnliches Muster beschreiben wir im Kontext der Auswahl einer Vektordatenbank im Artikel Wie wählt man eine Vektordatenbank aus sowie bei der Diskussion des Rerankings von Fragmenten in Reranking als Qualitätsschicht in RAG.

Die Graph-Extraktion hat drei kostspielige Fallstricke, über die technische Artikel selten sprechen.

Fallstrick 1: Die Extraktionsqualität leidet bei Dokumenten niedriger Qualität. OCR-Scans, Dokumente mit Tabellen, Aufzählungen ohne Satzkontext liefern chaotische Relationen. Vor der Graph-Extraktion sollte die Qualität des Chunkings sichergestellt werden, wie im Artikel zur Datenvorbereitung für RAG beschrieben.

Fallstrick 2: Der Graph ist nach jeder Dokumentenaktualisierung veraltet. Beim klassischen RAG aktualisierst du das Embedding eines Fragments in Sekunden. Bei GraphRAG musst du die Relationen aus diesem Fragment re-extrahieren und die Kanten im Graphen aktualisieren. Wenn sich Dokumente häufig ändern, steigen die Wartungskosten schnell. Ein inkrementelles Muster (nur geänderte Dokumente aktualisieren) funktioniert, erfordert aber Versionsbuchführung.

Fallstrick 3: Der Graph kann Fehler verfestigen. Wenn das Extraktionsmodell eine Relation falsch interpretiert, bleibt diese Relation im Graphen und beeinflusst Antworten, bis sie manuell korrigiert wird. Klassisches RAG wählt vielleicht ein falsches Fragment, aber der Fehler ist nicht strukturell verfestigt. Bei GraphRAG lohnt es sich, regelmäßig eine Stichprobe der Kanten zu auditieren. Das ist menschliche Arbeit, nicht automatisch.

Nein. Es ist eine Ergänzung, kein Ersatz. In den meisten Unternehmensimplementierungen deckt Vektor-RAG mit hybrider Suche 80–90 Prozent der Anwendungsfälle ab. GraphRAG kommt als zusätzliche Schicht für bestimmte Klassen mehrstufiger Abfragen zum Einsatz. Implementierungen, die den Vektor durch einen reinen Graphen ersetzten, kehrten meist nach einigen Wochen zum hybriden Ansatz zurück.

Microsoft hat die Open-Source-Bibliothek GraphRAG (Python) veröffentlicht, die die Extraktion von Entitäten und den Aufbau eines Graphen aus Textdateien automatisiert. LangChain und LlamaIndex bieten Integrationen mit Graphdatenbanken (Neo4j, Memgraph). Für eine eigenständige Implementierung ohne externe APIs reichen Ollama mit einem lokalen Modell für die Extraktion und NetworkX zur Speicherung des Graphen bei Korpora unter einigen zehntausend Knoten. Bei größeren Datensätzen beschleunigt eine dedizierte Graphdatenbank mit Cypher-Schnittstelle die Abfragen deutlich.

Die Spanne ist groß und hängt vom Modell und der Dokumentenlänge ab. Bei einem lokalen Modell (llama3.1:70b auf Ollama): 8–24 Stunden Extraktion, keine Token-Kosten. Bei kommerziellen APIs (GPT-4o oder Claude Sonnet): 50–300 Dollar einmalig für die Extraktion, plus ähnliche Kosten bei Aktualisierungen. Dazu kommen Kosten für die Normalisierung von Entitäten (meist 1–2 Tage Arbeit eines Fachexperten bei der ersten Extraktion) und Zeit für die Auditierung einer Stichprobe der Kanten. Wir geben Spannen basierend auf typischen Projekten an, keine konkrete Kostenschätzung ohne Datenanalyse.

Der Knotenpfad als Entscheidungsnachweis erleichtert die Erfüllung der Erklärbarkeitsanforderung (Art. 13 AI Act). Das reicht allein jedoch nicht aus: Es sind auch Systemdokumentation, ein Testfallregister und ein Human-Gate bei nicht umkehrbaren Entscheidungen erforderlich. GraphRAG verbessert die Erklärbarkeit des Retrieval-Mechanismus, entbindet aber nicht von Compliance-Pflichten auf Seiten des Implementierers.

Wenn der Korpus eine komplexe Ontologie hat (viele Entitäts- und Relationstypen), die Dokumente strukturell von geringer Qualität sind (Scans, Legacy-PDFs) oder der Zeitplan kurz ist. Die Extraktion von Relationen erfordert mehrere Iterationen von domänenspezifischem Prompt-Engineering, Stichprobenprüfung und Korrektur. Wir bei Cashcrown bewerten die technische Bereitschaft und die Daten, bevor wir eine Architektur empfehlen, denn ein firmeneigener RAG, der auf einer schlechten Graph-Extraktion aufbaut, liefert schlechtere Ergebnisse als ein einfacher Vektor mit semantischer Suche.