GraphRAG: wenn Beziehungen zwischen Daten über die Antwort entscheiden

Kennen Sie die Situation: Ihr RAG-System liefert relevante Fragmente, aber die Antwort stimmt trotzdem nicht? Sie fragen, wer Vertrag Nr. 2024-0034 genehmigt hat, und das System findet ein Dokument über Genehmigungsprozesse sowie ein Dokument mit der Vertragsnummer — verbindet aber nicht, dass die genehmigende Person in einem dritten Dokument steht. Jeder Schritt hat irgendwo eine Antwort. Das Problem liegt nicht bei der Suche — das Problem sind fehlende Beziehungen.

Genau für diese Art von Fragen wurde GraphRAG entwickelt — eine Erweiterung des klassischen Retrieval-Augmented Generation um einen Knowledge Graph (Wissensgraphen). Es ist kein Drop-in-Upgrade, das man einfach einschaltet. Es ist eine architektonische Entscheidung mit echten Kosten und realem Nutzen — aber nur für eine bestimmte Klasse von Problemen. In diesem Artikel schauen wir uns an, was GraphRAG löst, wie es technisch funktioniert, was es realistischerweise kostet und für welche Fälle es sich wirklich lohnt.

Was klassisches RAG nicht kann

Eine Standard-RAG-Pipeline funktioniert gut, wenn die Antwort auf eine Frage in einem oder zwei naheliegenden Textfragmenten liegt. Man nimmt die Frage, konvertiert sie in ein Embedding, findet die k-nächsten Chunks in der Vektordatenbank, übergibt sie dem Modell und erhält eine Antwort.

Dieser Ansatz hat einen blinden Fleck: Beziehungen zwischen Entitäten über Dokumente hinweg. Klassisches RAG hat keine Ahnung, dass die in Dokument A erwähnte Person dieselbe ist wie in Dokument C, dass das in einem Bericht beschriebene Ereignis die Ursache des in einem anderen Bericht analysierten Problems ist, oder dass der Lieferant aus einer Rechnung eigentumsrechtlich mit dem Unternehmen aus einer Reklamation verbunden ist. Vektorähnlichkeit matcht Text — keine semantischen Verbindungen.

Genau hier kommt GraphRAG ins Spiel. Anstelle isolierter Fragmente arbeitet es mit einem Graphen — Knoten (Entitäten: Personen, Unternehmen, Produkte, Prozesse, Standorte) und Kanten (Beziehungen: genehmigt, liefert, verantwortet, verursacht, gehört zu). Retrieval ist dann nicht mehr nur „finde ähnlichen Text", sondern „finde den Pfad oder Teilgraphen, der für diese Frage relevant ist".

Wie GraphRAG technisch funktioniert

Die ursprüngliche Implementierung von Microsoft, die diesen Begriff populär gemacht hat, besteht aus zwei Phasen: Indexierung und Abfrage.

Indexierungsphase

Das ist der teuerste Schritt. Für jedes Dokument im Korpus wird ein LLM (oder eine Reihe von LLM-Aufrufen) aufgerufen, das Entitäten und Beziehungen extrahiert. Aus Sätzen wie *„Ingenieur Novák genehmigte den Austausch von Pumpe P-12 an Linie 3 am 14. Januar"* extrahiert es die Knoten Novák (Person), P-12 (Anlage), Linie 3 (Standort) und die Kanten genehmigt → Austausch, befindet sich an → Linie 3.

Über den so extrahierten Graphen wird anschließend eine Community-Erkennung angewendet (Algorithmen wie Leiden oder Louvain), die zusammengehörige Entitäten in Communities gruppiert — etwa alle Entitäten rund um Linie 3 oder alle Transaktionen mit einem bestimmten Lieferanten. Für jede Community wird eine zusammenfassende Beschreibung generiert (sogenannter Community Report), der als übergeordneter Kontext bei der Beantwortung globaler Fragen dient.

Abfragephase

Beim Eingang einer Frage wird zwischen zwei Strategien entschieden:

Local Search — die Frage betrifft bestimmte Entitäten oder lokale Beziehungen. Das System findet relevante Knoten und traversiert den Teilgraphen in deren Umgebung. Geeignet für Fragen wie „Wer hat diese Bestellung genehmigt?" oder „Welche Anlagen sind mit dieser Störung verbunden?"

Global Search — die Frage erfordert die Synthese von Informationen aus dem gesamten Korpus. Das System arbeitet mit Community Reports statt mit Rohdokumenten. Geeignet für Fragen wie „Was sind die häufigsten Störungsmuster auf den Linien im letzten Jahr?" oder „Identifiziere Lieferanten mit wiederholt verspäteten Lieferungen."

Gegenüber klassischem RAG fügt GraphRAG also eine vollständige Schicht semantischer Struktur hinzu — aber diese Schicht ist nicht kostenlos.

Reale Indexierungskosten

Hier überrascht die Realität viele Interessenten. Microsoft berichtete in seiner Forschung, dass die Indexierung großer Datensätze mit der ursprünglichen Implementierung in der Größenordnung von Zehntausenden von US-Dollar kostete — abhängig von der Korpusgröße und dem gewählten Modell. Der Grund: Jedes Dokument (oder jeder Chunk) erfordert einen LLM-Aufruf zur Entitätsextraktion. Bei Hunderttausenden von Dokumenten addiert sich die Tokenanzahl schnell auf astronomische Werte.

Das hat eine konkrete Konsequenz: Indexierung ist kein einmaliger Vorgang. Wenn sich ein Dokument ändert oder ein neues hinzukommt, muss der Graph aktualisiert werden. Anders als bei einer Vektordatenbank, wo es genügt, neue Chunks neu zu embedden, kann eine Graph-Aktualisierung das erneute Durchlaufen der Umgebung des geänderten Knotens erfordern.

Das ist der grundlegende Grund, warum GraphRAG nicht für dynamische Korpora mit hoher Aktualisierungsfrequenz geeignet ist.

LazyGraphRAG und Open-Source-Alternativen

Microsoft war sich des Kostenproblems bewusst und veröffentlichte LazyGraphRAG — eine Variante, die die LLM-Extraktion von Entitäten und Beziehungen verzögert. Anstatt Entitäten für jedes Dokument bei der Indexierung zu extrahieren, baut sie einen Grundgraphen mit günstigeren Methoden (NLP-Extraktion, Keyword-Extraktion) und führt LLM-Aufrufe erst zum Abfragezeitpunkt durch — und zwar nur für die relevante Teilmenge. Das Ergebnis: deutlich niedrigere Indexierungskosten bei vergleichbarer Antwortqualität für viele Fragetypen.

Die Community hat inzwischen mehrere alternative Implementierungen mit unterschiedlichen Trade-offs entwickelt:

• LightRAG — Schwerpunkt auf Effizienz, weniger LLM-Aufrufe bei der Indexierung, gute Ergebnisse bei technischen Dokumenten
• HippoRAG — inspiriert von hippokampaler Gedächtnisarchitektur, interessant für Long-term Knowledge Retention
• Fast-GraphRAG — fokussiert auf Geschwindigkeit bei Beibehaltung der Graphstruktur

Keine dieser Alternativen ist ein „Gewinner in allem" — jede macht andere Kompromisse zwischen Indexierungskosten, Graphqualität und Abfragegeschwindigkeit. Für den Produktionseinsatz empfehlen wir, die konkrete Alternative auf Ihrem realen Korpus zu testen — nicht auf Benchmark-Datensätzen.

Wann sich GraphRAG lohnt

Das ist die entscheidende Frage, die man vor jeder Adoptionsentscheidung stellen muss.

GraphRAG bringt echten Mehrwert bei:

• Multi-Hop-Fragen — die Antwort erfordert die Verknüpfung von Informationen aus drei und mehr Dokumenten entlang einer Beziehungskette. „Welcher Technologe verantwortet die Anlage, die die Störung auf der Linie mit dem höchsten OEE verursacht hat?" — drei Entitäten, zwei Kanten, drei Dokumente.
• Impact-Analysen — „Welche Prozesse sind betroffen, wenn wir Lieferant X ersetzen?" — erfordert das Traversieren des Abhängigkeitsgraphen.
• Entitätsübergreifende Zusammenfassungen — „Fasse alle Vorfälle im Zusammenhang mit Produkt Y in den letzten zwei Jahren zusammen" — Communities im Graphen bewältigen das besser als Chunks aus einer Vektordatenbank.
• Mustererkennung — „Identifiziere wiederkehrende Muster in Reklamationen nach Lieferant und Anlagenkategorie" — Global Search über Community Reports.
• Compliance und Audit-Trails — „Belege die Genehmigungskette für Vertrag Z" — eine direkte Aufgabe für Graph-Traversal.

GraphRAG brauchen Sie wahrscheinlich nicht, wenn:

• Ihre Fragen überwiegend faktischer Natur sind und die Antwort in einem Fragment liegt („Welche Maximaltemperatur gilt für Pumpe P-12?").
• Ihr Korpus sich täglich oder mehrmals täglich ändert — die Re-Indexierungskosten werden prohibitiv.
• Sie weniger als einige Tausend Dokumente haben — klassischer Hybrid Search mit Reranking bewältigt die meisten Fälle zu einem Bruchteil der Kosten und Komplexität.
• Sie keine klar definierte Ontologie von Entitäten und Beziehungen haben — ein Graph, der aus unstrukturiertem Text ohne Domänenkontext extrahiert wurde, wird viel Rauschen enthalten.

Die von Microsoft gemeldete Zahl — GraphRAG erreicht rund 80 % richtige Antworten bei Multi-Hop-Fragen gegenüber rund 50 % bei naivem RAG — ist ein Richtwert und gilt für einen bestimmten Typ synthetischer Benchmark-Fragen. Die tatsächliche Verbesserung auf Ihrem Korpus kann anders ausfallen. Messen Sie immer auf eigenen Daten.

Integration in einen bestehenden RAG-Stack

GraphRAG ist kein Ersatz für eine Vektordatenbank — es ist eine Ergänzung. Moderne Produktionssysteme, die es einsetzen, betreiben typischerweise eine hybride Architektur:

1. 1.Vektordatenbank (z. B. Qdrant) für Dense Retrieval — schnell, günstig, geeignet für faktische Fragen.
2. 2.Graph-Schicht (neo4j, Amazon Neptune oder ein In-Memory-Graph für kleinere Korpora) für Beziehungsabfragen.
3. 3.Router/Orchestrator — klassifiziert die eingehende Frage und entscheidet, welche Schicht verwendet werden soll (oder kombiniert beide).

Die Orchestrierung eines solchen Systems ist komplexer. LangGraph (Framework für zustandsbehaftete Agentengraphen) ist für dieses Pattern die natürliche Wahl — es ermöglicht die Definition von Entscheidungsknoten, die dynamisch bestimmen, ob eine Anfrage über die Vektordatenbank, die Graph-Schicht oder beide läuft. Für die Bewertung der Ergebnisse lohnt sich ein Blick auf RAGAS-Metriken — siehe RAG evaluieren.

Wichtiger Hinweis zu Tooling: LlamaIndex hat in aktuellen Versionen native Unterstützung für GraphRAG-Indexierung, was die Implementierungsbarriere gegenüber dem manuellen Aufbau einer Pipeline erheblich senkt.

Wo wir GraphRAG in der industriellen Praxis sehen

Aus Deployments, die wir bei Kunden aus der Fertigungs- und Ingenieurbranche betreuen, erweisen sich GraphRAG oder hybride Graph-Ansätze in folgenden Szenarien als berechtigt:

Technisches Dokumentationsmanagement — große Unternehmen mit Tausenden technischer Handbücher, SOPs, Serviceberichte und Revisionsprotokollen. Die Frage „Wie ist das Vorgehen bei einem Ausfall von Pumpe Typ X in ATEX-Zone II?" erfordert die Verknüpfung des Gerätehandbuchs, des ATEX-Protokolls der Zone, der Sicherheits-SOP und der Servicehistorie. Klassisches RAG leistet das nicht zuverlässig.

Compliance und regulatorische Audit-Trails — in regulierten Branchen (Pharma, Energie, Lebensmittel) muss die Verantwortungs- und Genehmigungskette nachgewiesen werden. Ein Graph ist die natürliche Datenstruktur für „wer hat genehmigt, wann, auf welcher Grundlage, mit Verweis auf welche Vorschrift".

Lieferkettenanalyse — Verbindungen zwischen Lieferanten, Komponenten, Reklamationen und Störungen. „Wie viele kritische Komponenten kommen von Lieferanten, die im letzten Jahr mehr als 10 Tage Verspätung hatten?" — Multi-Hop über vier Entitätstypen.

Umgekehrt ist GraphRAG für interne Chatbots über FAQ-Dokumentation oder die Suche im Produktkatalog unnötige Komplexität. Siehe auch Agentic RAG Architekturen, wo die Graph-Schicht sich natürlich mit agentengesteuertem Retrieval kombiniert.

Praktisches Vorgehen: So starten Sie

Wenn Sie sich entschieden haben, GraphRAG auszuprobieren, empfehlen wir einen inkrementellen Ansatz:

1. 1.Ontologie definieren — bevor Sie irgendetwas implementieren, legen Sie explizit fest, welche Entitäts- und Beziehungstypen der Graph enthalten soll. Ohne diesen Schritt erhalten Sie einen rauschbehafteten Graphen voller irrelevanter Knoten.
2. 2.Mit kleinem Korpus beginnen — 1.000–5.000 Dokumente reichen aus, um zu überprüfen, ob die Graphstruktur Ihren Fragen entspricht. Die Indexierung ist auch mit LazyGraphRAG bewältigbar.
3. 3.Mit Baseline vergleichen — messen Sie für jeden Fragetyp (faktisch, Multi-Hop, Zusammenfassung) die Präzision von GraphRAG vs. Hybrid Search. Wenn GraphRAG auf Ihren realen Fragen keine >15 % Verbesserung bringt, überlegen Sie, ob die Komplexität gerechtfertigt ist.
4. 4.Aktualisierungszyklus planen — entscheiden Sie, wie Sie den Graphen aktuell halten. Batch-Re-Indexierung einmal pro Woche? Inkrementelle Aktualisierung beim Hinzufügen von Dokumenten? Diese Entscheidung beeinflusst die Gesamtarchitektur.
5. 5.Fallback nicht vergessen — halten Sie im Produktionssystem immer klassisches Vector Retrieval als Rückfallebene für Fälle bereit, in denen die Graphabfrage keine ausreichend vertrauenswürdigen Ergebnisse liefert.

Häufige Fragen

Ist GraphRAG besser als klassisches RAG?

Das hängt vom Fragetyp ab. Für Multi-Hop-Fragen, die eine entitätsübergreifende Verknüpfung erfordern — ja, deutlich. Für einfache faktische Fragen mit der Antwort in einem Fragment ist GraphRAG unnötig teuer und langsamer. Messen Sie immer auf Ihrem konkreten Use Case.

Was kostet die GraphRAG-Indexierung in der Praxis?

Die ursprüngliche Microsoft-Implementierung meldet Kosten in der Größenordnung von Zehntausenden US-Dollar für große Korpora. LazyGraphRAG und Open-Source-Alternativen (LightRAG, Fast-GraphRAG) senken diese Kosten erheblich. Der genaue Preis hängt von der Korpusgröße, dem gewählten LLM und der Granularität der Entitätsextraktion ab.

Brauche ich eine spezielle Graphdatenbank?

Nicht zwingend. Für kleinere Graphen (bis in den Bereich von Millionen Knoten) funktioniert eine In-Memory-Darstellung oder Bibliotheken wie networkx. Für größere Produktivdeployments sind Neo4j, Amazon Neptune oder TigerGraph Standardoptionen. Manche Implementierungen (z. B. LlamaIndex GraphRAG) abstrahieren die Storage-Schicht und ermöglichen die Wahl des Backends.

Funktioniert GraphRAG für deutschsprachige Dokumente?

Die Entitätsextraktion hängt von der Qualität des eingesetzten LLM ab. Frontier-Modelle (Claude, GPT, Gemini) beherrschen Deutsch sehr gut. Bei kleineren lokalen Modellen sollte man die Extraktionsqualität an einer deutschen Textprobe vor dem Deployment prüfen. Die Graphstruktur selbst ist sprachunabhängig.

Wann entscheidet man sich gegen GraphRAG?

Wenn sich Ihr Korpus täglich ändert, wenn Sie weniger als einige Tausend Dokumente haben, wenn Ihre Fragen überwiegend einstufig sind oder wenn Sie keine Kapazität haben, eine Entitätsontologie zu definieren und zu pflegen. In diesen Fällen liefert Ihnen klassischer Hybrid Search mit Reranking 90 % des Ergebnisses für 10 % der Kosten und Komplexität.

*GraphRAG ist nicht für jedes Projekt geeignet — aber für Projekte, bei denen Entitätsbeziehungen über die Korrektheit einer Antwort entscheiden, gibt es kein vergleichbares Werkzeug. Bei MP Industrial Solutions helfen wir Unternehmen dabei zu beurteilen, ob ihr konkreter Use Case ein GraphRAG-Kandidat ist, eine Ontologie zu entwerfen und die realen Indexierungskosten abzuschätzen — bevor irgendein Commit entsteht. Wenn Sie komplexe Dokumentations- oder Compliance-Fragen lösen, beginnen Sie mit einer Einschätzung.*