Quellen vorbereiten
Dokumente, Tabellen oder Notizen werden bereinigt, segmentiert und mit Metadaten versehen.
Deep Dive · GraphRAG
GraphRAG erweitert Retrieval-Augmented Generation um explizite Entitäten, Beziehungen und Pfade. Es wird relevant, wenn Antworten nachvollziehbare Zusammenhänge zwischen Textstellen brauchen.
Kuratierter erster Schnitt · Stand Juni 2026
GraphRAG ist RAG mit einem expliziten im Retrieval. Das System nutzt semantische Textstellen, Entitäten, Relationen, Pfade und Communities, um den Antwortkontext fachlich zu strukturieren.
Der Kern ist bessere Kontextauswahl mit mehreren Signalen. bleibt oft ein sinnvoller Teil der Pipeline; GraphRAG ergänzt Beziehungskontext, wenn die Antwort aus Zusammenhängen entsteht.
GraphRAG wird klarer, wenn die Rolle des Graphen genau benannt wird. Ein Wissensgraph ist die semantische Basis; Dokument- und Domänen-Graphen sind die wichtigsten fachlichen Grundformen; Conversational und dynamische Graphen ergänzen Laufzeitkontext und Veränderung. Entscheidend ist, welche Frage der Graph beantwortet.
Semantische Basis
Der Oberbegriff für explizites Wissen aus Entitäten, Beziehungen, Eigenschaften und Quellen. Im GraphRAG ist er die strukturierte Kontextschicht, aus der Retrieval Pfade, Nachbarschaften oder Communities auswählt.
Relevant, wenn Wissen maschinenlesbar, verknüpfbar und erklärbar werden soll.
Fachliche Realität
Modelliert konkrete fachliche Objekte und Regeln einer begrenzten Domäne: Verträge, Produkte, Systeme, Risiken, Rollen oder Nachweise. Er beantwortet Fragen nach Bedeutung, Gültigkeit und Abhängigkeit.
Relevant, wenn Antworten über belastbare Fachbeziehungen laufen.
Korpus und Quellen
Erschließt Dokumente, Chunks, Textstellen, Claims, Erwähnungen und Communities. Er ist stärker Retrieval-Index als Fachmodell und muss deshalb von geprüften Domänenaussagen getrennt bleiben.
Relevant, wenn große Textmengen quellenbezogen durchsuchbar werden sollen.
Interaktion und Memory
Hält Gesprächsverlauf, Nutzerziele, offene Fragen, Präferenzen, Entscheidungen und Feedback als nutzbaren Kontext fest. Er verbindet GraphRAG mit Agent Memory und längeren Arbeitsprozessen.
Relevant, wenn Antworten von Session-Verlauf, Rollen oder Nutzerfeedback abhängen.
Zeit und Veränderung
Macht Aktualität, Versionen, Events, Gültigkeitszeiträume und Drift sichtbar. Er ist weniger ein eigener Inhaltstyp als die Evolutionsschicht, die verhindert, dass GraphRAG veralteten Kontext liefert.
Relevant, wenn Wissen sich laufend ändert oder zeitlich bewertet werden muss.
Reife Systeme verbinden oft mehrere Perspektiven: Ein Dokument-Graph liefert Quellen, Chunks und extrahierte Aussagen; ein Domänen-Graph ordnet diese Aussagen fachlichen Objekten, Regeln und Verantwortlichkeiten zu; ein Conversational oder dynamischer Graph hält fest, was im Verlauf einer Nutzung gelernt, bestätigt oder überholt wurde. Die Verwechslung beginnt, wenn ein aus Text extrahierter Retrieval-Graph schon wie eine geprüfte fachliche Wahrheit behandelt wird.
Zur vollständigen Typologie mit KriterienvergleichVom Korpus zur erklärbaren Antwort
Dokumente, Tabellen oder Notizen werden bereinigt, segmentiert und mit Metadaten versehen.
Entitäten, Relationen und Communities entstehen aus den Quellen oder aus vorhandenen Datenmodellen.
Das System entscheidet, ob eine Frage lokale Entitäten, Beziehungspfade, Cluster oder einen Überblick braucht.
Retrieval liefert relevante Knoten, Kanten, Pfade, Nachbarschaften, Quellen und gegebenenfalls Textchunks.
Der Graphkontext wird gefiltert, gerankt und so komprimiert, dass das LLM ihn sinnvoll nutzen kann.
Das LLM erzeugt eine Antwort, die möglichst auf Quellen, Beziehungen und nachvollziehbaren Zwischenschritten basiert.
GraphRAG ist kein einzelner Algorithmus. In der Praxis werden fünf Retrieval-Modi kombiniert, je nachdem ob eine Frage eine bekannte Entität, einen Pfad, einen Überblick, hybride Signale oder eine präzise Graphabfrage braucht. Frameworks wie Microsoft GraphRAG oder Neo4j verwenden teils eigene englische Namen; sie stehen als Synonyme an jedem Modus.
auch: Local Search · Entity-first
Startet bei konkreten Entitäten oder Dokumentstellen und sammelt direkte Nachbarschaft, Quellen und relevante Pfade. Gut für Detailfragen, Nachweise und konkrete Objekte.
Welche Risiken hängen an Vertrag X?
auch: Path-based Retrieval
Verfolgt mehrere Beziehungsschritte, wenn die Antwort über Zwischenknoten entsteht.
Welche Services sind indirekt von System Y abhängig?
auch: Global Search
Nutzt Cluster, Communities oder vorbereitete Zusammenfassungen, um große Korpora thematisch überblickbar zu machen. Gut für Muster, Themen und Lagebilder.
Welche Hauptthemen tauchen in allen Reports wiederholt auf?
auch: Text-based Retrieval · Chunk-first
Startet meist mit Vektorsuche auf Textchunks und kombiniert Graphpfade, Metadaten und Reranking, wenn kein Signal allein reicht.
Welche Policy-Stellen und Nachweise passen zu dieser Anfrage?
auch: NL2Cypher
Übersetzt eine Nutzerfrage mit Hilfe des Graphschemas in eine kontrollierte Graphabfrage. Gut für präzise Beziehungsmuster.
Welche Kunden sind über Verträge mit Policy B verbunden?
Wie diese Modi als durchgängige Abläufe kombiniert werden, zeigt die Entscheidungskarte GraphRAG Retrieval Patterns.
GraphRAG wird greifbar, wenn eine Frage mehrere Dinge verbinden muss. Das Beispiel zeigt, wie aus einer fachlichen Frage ein Beziehungskontext wird.
Welche Verträge mit Kunde Nordstern enthalten Klauseln, die von der neuen Datenschutz-Policy betroffen sind?
Reine Textnähe findet oft
Kunde Nordstern -[:HAT_VERTRAG]-> Vertrag A
Vertrag A -[:ENTHÄLT]-> Klausel 12
Klausel 12 -[:REGELT]-> Datenverarbeitung
Datenschutz-Policy 2026 -[:BETRIFFT]-> Datenverarbeitung
Die Antwort kann die betroffenen Verträge nennen, den Pfad über Klausel und Policy zeigen und die relevanten Quellenstellen getrennt zitierbar halten.
Kostenmodell
GraphRAG verschiebt Aufwand nach vorne: Der Graph muss gebaut, verdichtet, geprüft und aktualisiert werden. Dieser Aufwand lohnt sich, wenn der Beziehungskontext echte Qualitätsgewinne erzeugt.
Qualitätsfrage
GraphRAG ist sinnvoll, wenn der Graph echte Retrieval-Qualität erzeugt. Ein guter Kontext ist präzise, erklärbar und stabil genug für die jeweilige Frage.
GraphRAG ist stark, wenn Antwort und Herleitung sichtbar werden. Dafür müssen Quellen, Pfade und extrahierte Graphfakten getrennt behandelbar bleiben.
Jede Aussage braucht nachvollziehbare Dokumente, Abschnitte oder Datensätze.
Die Antwort sollte zeigen können, welche Entitäten und Beziehungen sie verbunden hat.
Extrahierte Beziehung und LLM-Formulierung sollten unterscheidbar bleiben.
Unsichere Aussagen brauchen Confidence, Stichprobe oder manuelle Bestätigung.
GraphRAG ist kein einzelnes Produkt. Je nach Frage, Datenreife und Betriebsmodell sieht die Architektur unterschiedlich aus.
Startpunkt für dokumentennahe Fragen mit schneller semantischer Suche und schlanker Modellierung.
Kombiniert Vektorsuche mit Graph- oder Metadatensignalen. Häufig der pragmatische nächste Schritt.
Stark für Korpus-Überblicke, Communities und Global Search über größere Dokumentmengen.
Produktionsnäher, wenn Graphdatenbank, Cypher, Vektorindex und Betrieb zusammen gedacht werden.
GraphRAG sollte eine konkrete Verbesserung gegenüber einfacheren Retrieval-Mustern zeigen. Maßgeblich ist, welche Architektur die Testfragen am verlässlichsten beantwortet.
GraphRAG vermischt schnell mehrere Themen. Für die Praxis hilft eine klare Trennung: Der Graph speichert Beziehungen, baut ihn auf, stabilisiert Bedeutung, und Retrieval entscheidet, welcher Kontext in die Antwort kommt.
Das konkrete Netz aus Knoten, Kanten, Eigenschaften und Quellen.
Die Pipeline, die aus Quellen einen belastbaren Graph erzeugt und pflegt.
Die fachliche Bedeutungsschicht für Begriffe, Beziehungstypen und Regeln.
Die Muster, die festlegen, ob Kontext über Chunks, Entitäten, Hybrid-Signale, Cypher oder Agenten geholt wird.
Praxisentscheidung
Der beste Einstieg ist ein kleiner Benchmark: 5 bis 10 echte Fragen, eine einfache RAG-Baseline, ein enger Graph mit klaren Entitätstypen und eine Auswertung, bei welchen Fragen Beziehungskontext wirklich hilft.
Ein GraphRAG-Pilot sollte klein genug sein, um schnell zu lernen, aber konkret genug, um echte Architekturentscheidungen vorzubereiten.
Nächste Schritte