Architektur

GraphRAG-Implementierungsleitfaden: Von Textdokumenten zur produktiven Knowledge-Graph-Retrieval

Von IdeaBosqueZuletzt aktualisiert: 2026年8月26日

Die GraphRAG-Forschung von Microsoft demonstrierte 86% Abdeckung bei komplexen Multi-Entity-Abfragen, verglichen mit 57% bei traditionellem Vector RAG auf demselben Evaluationsdatensatz — eine Lücke von 29 Prozentpunkten, die immer dann sichtbar wird, wenn eine Frage das Durchlaufen von Beziehungen erfordert, nicht nur das Matchen von Text. Die Lücke existiert, weil Produktwissen ein Graph ist: Abhängigkeiten, Versionen, Kompatibilität, Substitute, Preistufen und regionale Verfügbarkeitseinschränkungen sind Beziehungen, keine Embeddings. Die meisten Teams beginnen jedoch mit traditionellem RAG, weil die Baukosten für GraphRAG historisch bei 12-16 Wochen lagen gegenüber 6-8 Wochen für reine Vector-Retrieval. Zwei im letzten Jahr veröffentlichte Open-Source-Tools — das Python-Paket neo4j-graphrag von Neo4j mit seiner SimpleKGPipeline und das GraphRAG SDK 1.0 (LLM-agnostisch, April 2026) — reduzieren diese Baukosten erheblich und machen GraphRAG in Wochen statt Monaten machbar. Dieser Leitfaden durchläuft die fünfstufige Pipeline, die unstrukturierte Dokumente in ein produktives Knowledge-Graph-Retrieval-System verwandelt: Schema-Design, Entitätsextraktion, Community-Erkennung, Graph-Retrieval und Agenten-Integration. Er benennt die Kostenfallen, das Governance-Verfallsrisiko und den Entscheidungspunkt, an dem traditionelles RAG 85% des Ergebnisses mit 30% des Aufwands erzielt.

Kernpunkte

86% Abdeckung gegenüber 57% bei Vector RAG — Microsoft GraphRAG (Edge et al., 2024) maß graphbasierte Retrieval gegen Vector RAG bei komplexen Multi-Entity-Abfragen. Die 29-Punkte-Lücke ist der strukturelle Vorteil des Durchlaufens von Beziehungen statt des Matchens von Embeddings.
77,6% Verbesserung der Retrieval-Genauigkeit und 28,6% Reduktion der Lösungszeit — LinkedIns GraphRAG-Produktivdeployment bei Jira-Tickets maß beide Metriken gegen Basis-Vector-RAG. Die Graphstruktur erfasste, was die Vektorsuche verpasste.
GraphRAG macht KI-Agenten 80% wahrheitsgetreuer — Neo4js Whitepaper zur Halluzinationsreduktion fand, dass graphstrukturierte Retrieval das Modell in verifizierte Beziehungen einbettet und erfundene Antworten reduziert. GraphRAG ist nicht nur bessere Retrieval; es ist eine Halluzinations-Minderungstechnik.
Traditionelles RAG erreicht 85-90% der GraphRAG-Leistung bei 30% des Aufwands — GraphRAG benötigt 12-16 Wochen von Grund auf gegenüber 6-8 Wochen für traditionelles RAG, und Graph-Aktualisierungen pro Abfrage sind O(N) pro Ticket gegenüber O(1) pro Dokument. Die 85%-Schwelle ist der Entscheidungspunkt.
SimpleKGPipeline und GraphRAG SDK 1.0 reduzieren den Aufbau auf Wochen — das Python-Paket neo4j-graphrag liefert eine SimpleKGPipeline, die Textteilung, Entitätsextraktion, Embedding und Graphkonstruktion in einer einzigen asynchronen Pipeline handhabt. Das GraphRAG SDK 1.0 ist LLM-agnostisch und unterstützt OpenAI, Anthropic, Google, Cohere und 100+ lokale Modelle über eine einheitliche Schnittstelle.

Die fünfstufige Pipeline

Ein produktives GraphRAG-System hat fünf Stufen. Jede Stufe hat einen Entscheidungspunkt, der Kosten, Genauigkeit und Wartungsaufwand beeinflusst. Die Stufen sind sequenziell, aber iterativ — Entitätsextraktion speist die Community-Erkennung, die die Retrieval speist, und das Schema, das alle drei steuert, wird verfeinert, während der Corpus neue Entitätstypen offenbart.

Die Pipeline verwandelt unstrukturierten Text in einen abfragbaren Knowledge Graph und ruft dann Teilgraphen ab, die die Antwort des LLM in verifizierte Beziehungen einbetten:

Stufe 1: Schema-Design — die Entscheidung, die die Extraktionsqualität bestimmt

Das Schema ist der Vertrag zwischen der Domäne und der Extraktionspipeline. Es definiert, welche Knotentypen existieren, welche Beziehungstypen sie verbinden und welche Entitäts-Beziehungs-Muster gültig sind. Ein lockeres Schema (keine Einschränkungen) erzeugt einen verrauschten Graphen mit Hunderten von spurösen Entitätstypen. Ein straffes Schema (eingeschränkte Muster) erzeugt einen sauberen Graphen, kann aber Beziehungen übersehen, die das Schema nicht antizipiert hat.

Das Python-Paket neo4j-graphrag von Neo4j ermöglicht es, ein Schema-Objekt mit drei Feldern an SimpleKGPipeline zu übergeben: node_types, relationship_types und patterns. Das patterns-Feld ist die Einschränkung — es teilt dem LLM mit, welche Entität-Beziehung-Entität-Tripel gültig sind. Für einen B2B-Produktsupport-Graphen könnte das Schema so aussehen:

Knotentypen: Product, Component, Supplier, PriceTier, CustomerSegment, Region, Document, Ticket
Beziehungstypen: SUBSTITUTE_OF, DEPENDS_ON, COMPATIBLE_WITH, SUPPLIED_BY, PRICED_IN, AVAILABLE_IN, RESOLVED_BY
Muster: (Product, SUBSTITUTE_OF, Product), (Product, DEPENDS_ON, Component), (Product, SUPPLIED_BY, Supplier), (Product, PRICED_IN, PriceTier), (Product, AVAILABLE_IN, Region), (Ticket, RESOLVED_BY, Document)

Das Schema ist die erste Kostenfalle. Ein zu enges Schema verpasst wichtige Beziehungen (das LLM extrahiert "Product A wird von Vendor X hergestellt", aber Vendor ist kein definierter Knotentyp, also wird die Beziehung verworfen). Ein zu breites Schema produziert Rauschen (das LLM extrahiert jedes Nomen als Entität und überflutet den Graphen mit nutzlosen Knoten). Die Lösung ist iterativ: mit einem eingeschränkten Schema beginnen, das auf den Fragen basiert, die der Graph beantworten muss, Extraktion auf einem Beispiel-Corpus ausführen, den Graphen auf fehlende Beziehungen und Rauschen inspizieren, dann verfeinern. Zwei oder drei Iterationen sind typisch, bevor sich das Schema stabilisiert.

Stufe 2: Entitätsextraktion — das Kostenzentrum

Die Entitätsextraktion ist where das LLM die Arbeit leistet — und where sich die Kosten ansammeln. Jeder Textabschnitt wird mit einem Prompt an das LLM gesendet, der es auffordert, Entitäten und Beziehungen gemäß dem Schema zu extrahieren. Die GraphRAG-Indexierungspipeline von Microsoft verwendet einen LLM-gesteuerten Ansatz: jeder Abschnitt wird mit einem LLM analysiert, um benannte Entitäten und Beziehungen geführt von einem Prompt-Template zu extrahieren. Das FalkorDB GraphRAG SDK 1.0 bietet dieselbe LLM-gesteuerte Extraktion, ist aber LLM-agnostisch — es unterstützt OpenAI, Anthropic, Google, Cohere, lokale Open-Source-Modelle und 100+ andere über eine einheitliche Schnittstelle, was bedeutet, dass die Extraktionskosten optimiert werden können, indem ein günstigeres Modell für die Extraktion und ein stärkeres Modell für die Abfragebeantwortung gewählt wird.

Die Kostenarithmetik ist einfach: 1.000 Textabschnitte erfordern 1.000 LLM-Aufrufe für die Entitätsextraktion. Bei GPT-5.6 Sol-Preisen von $4 pro Million Input-Token und $20 pro Million Output-Token kostet ein 1.000-Abschnitt-Corpus mit 500 Token pro Abschnitt und 200 Token Extraktions-Output pro Abschnitt roughly $4 in Input-Token und $4 in Output-Token — etwa $8 für den Extraktionsdurchlauf. Ein 10.000-Abschnitt-Corpus kostet $80. Die Extraktion ist eine einmalige Kosten pro Corpus-Build, wiederholt sich aber, wenn sich der Corpus ändert. Hier kommen die Inferenzökonomie der Modellwahl zum Tragen: die Verwendung eines günstigeren Open-Weight-Modells für die Extraktion (z. B. Qwen3.8 Max bei $2 pro Million Output-Token) halbiert die Output-Token-Kosten ohne die Extraktionsqualität für strukturierte Entitäts-Beziehungs-Extraktion wesentlich zu beeinträchtigen.

Die Entitätsauflösung folgt der Extraktion. Das LLM extrahiert möglicherweise "Jon" aus einem Abschnitt und "Jon Marquez" aus einem anderen — beide beziehen sich auf dieselbe Person. Die SimpleKGPipeline handhabt dies automatisch, indem Entitäten mit demselben Label und derselben Name-Eigenschaft zusammengeführt werden. Für Produktionssysteme ist oft benutzerdefinierte Entitätsauflösungslogik erforderlich — Fuzzy-Matching auf Namen, Disambiguierung basierend auf Kontext oder manuelle Überprüfung für wertvolle Entitäten. Das Überspringen der Entitätsauflösung erzeugt einen Graphen mit doppelten Knoten, was das Beziehungs-Traversieren bricht (die Abfrage läuft von "Jon", aber die Antwort ist mit "Jon Marquez" verbunden).

Stufe 3: Community-Erkennung — der Enabler für globale Abfragen

Die Community-Erkennung ist what GraphRAG enables, globale Fragen zu beantworten, die traditionelles RAG nicht kann. Der GraphRAG-Ansatz von Microsoft (Edge et al., 2024) führte das Paradigma "von lokal zu global" ein: nachdem Entitäten extrahiert und der Graph erstellt wurden, gruppiert ein Community-Erkennungsalgorithmus (Leiden oder Louvain) verwandte Entitäten in Cluster, und ein LLM generiert eine Zusammenfassung für jede Community. Diese Community-Zusammenfassungen ermöglichen die globale Suche — Fragen wie "was sind die Hauptthemen in diesem gesamten Corpus?" — die Vector RAG nicht beantworten kann, weil sie isolierte Abschnitte ohne thematische Struktur abruft.

Der praktische Workflow:

Community-Erkennung (Leiden-Algorithmus) auf dem Entitäts-Beziehungs-Graphen ausführen. Der Algorithmus partitioniert den Graphen in Cluster dicht verbundener Entitäten. Memgraph 3.0 liefert Leiden als eingebauten Algorithmus, und Neo4j bietet ihn über die Graph Data Science-Bibliothek.
Für jede Community die Entitäten und Beziehungen an das LLM senden, um eine Zusammenfassung zu generieren. Dies ist ein zweiter LLM-Kostendurchlauf — ein Aufruf pro Community, nicht pro Abschnitt, daher typischerweise günstiger als der Extraktionsdurchlauf.
Die Community-Zusammenfassungen zusammen mit dem Graphen speichern. Zur Abfragezeit ruft die globale Suche die relevantesten Community-Zusammenfassungen ab und nutzt sie, um thematische Fragen zu beantworten. Die lokale Suche durchläuft spezifische Teilgraphen für entitätsspezifische Fragen.

Die beiden Suchmodi dienen unterschiedlichen Fragen. Die lokale Suche beantwortet "welche Produkte sind mit SKU X kompatibel?" durch Durchlaufen des Graphen vom SKU-Knoten. Die globale Suche beantwortet "was sind die Hauptlieferkettenrisiken in unserem Produktkatalog?" durch Abfragen von Community-Zusammenfassungen, die über Hunderte von Entitäten aggregieren. Traditionelles RAG kann keines beantworten — Vektorsuche ruft einzelne Abschnitte ab, keine thematischen Zusammenfassungen.

Stufe 4: Graph-Retrieval — deterministische Abfragen, keine semantischen Schätzungen

Graph-Retrieval is where GraphRAG am stärksten von traditionellem RAG abweicht. Traditionelles RAG bettet die Abfrage ein, sucht in einem Vector-Index nach den ähnlichsten Abschnitten und gibt diese zurück. GraphRAG durchläuft den Graphen über deterministische Abfragen — Cypher für Neo4j, GQL für jede Graphdatenbank — die verifizierte Beziehungen zurückgeben, keine semantischen Approximationen.

Die Retrieval-Schicht kombiniert typischerweise zwei Strategien:

Graph-Traversal — eine Cypher-Abfrage läuft von einem Entitätsknoten zu seinen Beziehungen. Für eine Support-Frage "kann Kunde Y den Mengenpreis für Produkt X in Region Z erhalten?" läuft die Abfrage: Product X -> PRICED_IN -> BulkTier, Product X -> AVAILABLE_IN -> Region Z, CustomerSegment Y -> QUALIFIES_FOR -> BulkTier. Wenn der Durchlauf erfolgreich ist, ist die Antwort in verifizierten Graph-Beziehungen verankert. Wenn ein Link fehlt, sagt der Graph dies explizit — im Gegensatz zur Vektorsuche, die einen ähnlichen, aber falschen Abschnitt zurückgibt.
Vector-Similarity — für Fragen, die kein Beziehungs-Traversieren erfordern, behandelt die Vektorsuche über Abschnitt-Embeddings (neben dem Graphen gespeichert) das semantische Matching. Das GraphRAG SDK 1.0 kombiniert beide: "Multi-Path-Retrieval, das Graph-Traversal und semantische Suche kombiniert, mit ranked Result-Merging über Retrieval-Strategien." Dieser hybride Ansatz nutzt den Graphen für strukturelle Fragen und Vektoren für semantische Fragen, mit automatischem Routing basierend auf dem Abfragetyp.

Der Auditierbarkeitsvorteil ist der Debugging-Nutzen. Wenn eine Graph-Abfrage die falsche Antwort zurückgibt, kann ein Mensch den Pfad nachverfolgen (Ticket -> Product -> Tier -> Segment -> Region -> Stockout) und genau sehen, welche Beziehung fehlte oder falsch war. Wenn eine Vektorsuche die falsche Antwort zurückgibt, sieht der Mensch einen Textabschnitt ohne Pfad zum Nachverfolgen. Die Neo4j GraphRAG-Dokumentation formuliert dies als "GraphRAG stellt wieder her, was Vektoren verwerfen — explizites Wissen, das ein Mensch lesen kann." Die 77,6% Retrieval-Genauigkeitsverbesserung, die LinkedIn in der Produktion maß, beruht auf dieser Auditierbarkeit: wenn der Graph falsch ist, kann man den Fehler finden und beheben; wenn der Vektor falsch ist, rät man.

Stufe 5: Agenten-Integration — MCP-Module und Governance-Verfall

Die letzte Stufe exposes Graph-Retrieval einem KI-Agenten als typisiertes MCP-Tool. Der Agent schreibt keine Cypher-Abfragen direkt — er ruft ein Tool wie rag_query(question: string) -> answer oder get_substitutes(sku: string) -> list[Product] auf, das das MCP-Modul intern in Graph-Abfragen übersetzt. Dies folgt dem MCP Module Code Standard-Muster: typisierte Tool-Definitionen, Input-Validierung, Audit-Logs pro Aufruf und Rate-Limits.

Das Governance-Verfallsrisiko ist the Design-Überlegung, die die meisten GraphRAG-Tutorials weglassen. Wenn ein Knowledge Graph als Retrieval-Schicht für einen Agenten verwendet wird, werden die Constraints und Richtlinien des Graphen Teil des Kontextfensters des Agenten. Wenn das Kontextfenster komprimierbar ist — und alle Kontextfenster sind es, given die Ökonomie langlebiger Agenten — können die aus dem Graphen geladenen Constraints während der Komprimierung silently verworfen werden. Ein Agent, der korrekt "ist dieses Produkt in Region Z verfügbar?" gegen den Graphen überprüfte, kann nach einem Kontext-Komprimierungsereignis aufhören zu überprüfen, weil der Constraint im Kontext war, nicht im Code. Die Lösung ist architektonisch: kritische Constraints müssen vom Code des MCP-Moduls durchgesetzt werden, nicht vom Kontext des Agenten. Das Modul lehnt den Tool-Aufruf ab, wenn der Constraint verletzt wird, unabhängig davon, was der Kontext des Agenten sagt. Dies ist dasselbe Muster, das die Kill-Switch-Architektur durchsetzt: Governance, die darauf angewiesen ist, dass der Agent sich an gutes Verhalten erinnert, ist Governance, die unter Komprimierung versagt.

Der Entscheidungspunkt: Wann GraphRAG vs traditionelles RAG bauen

Nicht jedes Retrieval-Problem braucht einen Knowledge Graph. Der Entscheidungsrahmen basiert auf einer Frage: erfordert die Abfrage das Durchlaufen von Beziehungen, die Vector-Similarity nicht repräsentieren kann?

Kriterium	Traditionelles RAG	GraphRAG
Bauzeit	6-8 Wochen	12-16 Wochen von Grund auf; 4-8 Wochen mit SimpleKGPipeline oder GraphRAG SDK
Update pro Abfrage	O(1) pro Dokument	O(N) pro betroffenem Entitäts-Teilgraph
Abdeckung	57% bei Multi-Entity-Abfragen	86% bei Multi-Entity-Abfragen
Retrieval-Genauigkeit	Basis	+77,6% (LinkedIn-Produktion)
Halluzinationsrate	Basis	-80% (Neo4j-Whitepaper)
Auditierbarkeit	Textabschnitt, kein Pfad	Graph-Pfad vom Menschen nachverfolgbar
Kostentreiber	Vector-Index-Größe	LLM-Aufrufe pro Abschnitt für Extraktion
Fragentyp	"Ähnlichen Text finden"	"Beziehungen durchlaufen: Substitute, Abhängigkeiten, Kompatibilität"
Wann wählen	70% der Abfragen sind Semantic-Similarity	30% der Abfragen erfordern Beziehungs-Traversierung

Die 85%-Schwelle: traditionelles RAG erreicht 85-90% der GraphRAG-Leistung bei 30% des Aufwands, wenn die Mehrheit der Abfragen Semantic-Similarity-Lookups sind. GraphRAG wird zur richtigen Wahl, wenn die Abfrage das Durchlaufen von Beziehungen erfordert, die die Vektorsuche wegglättet — Produktkompatibilität, Substitutionsketten, Abhängigkeitsauflösung, Multi-Hop-Reasoning. Für ein Support-Team, das "finde das Dokument über API-Authentifizierung" beantwortet, ist traditionelles RAG ausreichend. Für ein Support-Team, das "welche API-Version ist mit dieser Produktabhängigkeit kompatibel, und was ist das Substitute, wenn es in dieser Region nicht verfügbar ist" beantwortet, ist GraphRAG die einzige Retrieval-Strategie, die die korrekte Antwort zurückgibt.

Kostenfallen und wie man sie vermeidet

Die Extraktions-Kostenfalle. Die Entitätsextraktion erfordert einen LLM-Aufruf pro Abschnitt. Ein 50.000-Dokumente-Corpus mit 10 Abschnitten pro Dokument sind 500.000 LLM-Aufrufe. Bei $8 pro 1.000 Abschnitten sind das $4.000 allein für den Extraktionsdurchlauf. Die Lösung: ein günstigeres Modell für die Extraktion verwenden (strukturierte Entitäts-Beziehungs-Extraktion ist eine wohldefinierte Aufgabe, die kein Frontier-Modell benötigt) und ein stärkeres Modell für die Abfragebeantwortung. Die LLM-agnostische Architektur des GraphRAG SDK 1.0 unterstützt diese Aufteilung — verschiedene Modelle für Extraktion und Retrieval.

Die Entitätsauflösungs-Falle. Ohne Entitätsauflösung enthält der Graph doppelte Knoten, die das Traversieren brechen. "Product A" aus einem Dokument extrahiert und "ProductA" aus einem anderen sind zwei Knoten, nicht einer. Die SimpleKGPipeline handhabt grundlegende Auflösung (gleiches Label und Name), aber Produktionssysteme benötigen Fuzzy-Matching und manuelle Überprüfung für wertvolle Entitäten. Budget dafür einplanen — es ist nicht optional.

Die Governance-Verfalls-Falle. Graph-Constraints, die in den Kontext des Agenten geladen werden, sind anfällig für Kontext-Komprimierung. Die Lösung ist architektonisch: kritische Constraints im Code des MCP-Moduls durchsetzen, nicht im Kontext des Agenten. Ein Constraint, den der Agent "weiß", ist ein Constraint, der vergessen werden kann; ein Constraint, den der Code durchsetzt, ist ein Constraint, der hält.

Die Wartungs-Falle. GraphRAG ist kein Einmal-Build. Wenn sich der Corpus ändert, muss die Extraktions-Pipeline für betroffene Dokumente erneut ausgeführt werden, und der Graph muss aktualisiert werden. Graph-Updates pro Abfrage sind O(N) — das Aktualisieren einer Entität kann das Re-Extrahieren von Beziehungen für alle verbundenen Entitäten erfordern. Traditionelles RAG's Update pro Abfrage ist O(1) — ein Dokument ändert sich, ein Vector wird neu eingebettet. Für einen Corpus, der sich häufig ändert, können die Wartungskosten von GraphRAG die Baukosten innerhalb eines Jahres übersteigen.