Ein Regulatory-Affairs-Team fragt sein RAG-System: “Welche Umweltstandards aus unseren EU-, Schweizer und UAE-Betrieben gelten für unsere Aluminiumverarbeitungslinie, und welche unserer drei Tier-1-Lieferanten sind nach diesen Standards zertifiziert?” Die Vektorsuche gibt relevante Absätze über Umweltstandards zurück. Sie gibt Absätze über Lieferanten zurück. Sie verbindet sie nicht. Die Antwort erfordert das Durchqueren von Entitätsbeziehungen über vier Dokumentensets. Das ist kein Retrieval-Problem. Das ist ein Graphen-Problem.
Vector RAG wurde für eine andere Klasse von Fragen gebaut.
Die Frage, die Vector RAG nicht gut beantworten kann
Vektor-Retrieval ist Ähnlichkeitssuche über eingebetteten Text. Bei einer Anfrage gibt es die Passagen im Corpus zurück, deren Embedding dem Anfrage-Embedding am nächsten ist. Es zeichnet sich aus bei: Finden Sie den Abschnitt eines Handbuchs, der X erklärt, zeigen Sie die Richtlinie, die Y abdeckt, rufen Sie die Klausel aus einem Vertrag ab, die Z adressiert.
Es hat Schwierigkeiten mit Fragen, die die Verbindung von Entitäten über mehrere Dokumente erfordern. “Welche Vorschriften betreffen diesen Prozess?” wird mit einigen relevanten Dokumentpassagen beantwortbar. “Welche Vorschriften über drei Jurisdiktionen betreffen diesen Prozess, und welche unserer Lieferanten sind impliziert?” erfordert das Wissen, dass Vorschrift A in Jurisdiktion 1 mit Standard B in Jurisdiktion 2 verbunden ist, der durch Lieferantenzertifizierung C in Jurisdiktion 3 gefordert wird. Diese Verbindungskette ist in keiner einzelnen Passage. Sie liegt in den Beziehungen zwischen Entitäten.
Die Unterscheidung ist semantische Ähnlichkeit versus relationales Traversal. Das sind unterschiedliche Operationen. Ein für eine optimiertes System liefert beim anderen schlechte Leistung.
Multi-Hop-Fragen, bei denen die Antwort die Verbindung benannter Entitäten über mehrere Dokumente durch mehrere Beziehungstypen erfordert, sind der Bereich, wo Vektor-RAG degradiert und graph-basiertes Retrieval gewinnt.
Was Graph RAG tatsächlich tut
Der Microsoft-GraphRAG-Ansatz nimmt ein Dokumenten-Corpus und verwendet einen LLM, um Entitäten und Beziehungen zu extrahieren. Ein Vertrag referenziert einen Lieferanten. Ein Lieferant hält eine Zertifizierung. Eine Zertifizierung erfüllt eine regulatorische Anforderung. Die extrahierten Entitäten und Beziehungen bilden einen Knowledge-Graphen. Retrieval durchquert den Graphen statt, oder zusätzlich zu, Vektorraumsuche.
Zwei Varianten adressieren spezifische Kostenbedenken:
LazyGraphRAG (Microsoft Research): verschiebt die Entitätsextraktion auf den Anfragezeitpunkt und baut Community-Zusammenfassungen bei der ersten Anfrage faulenzerisch auf, statt den vollständigen Graphen im Voraus zu indizieren. Reduziert die Kosten der Graphkonstruktion für große Corpora erheblich. Der Kompromiss ist die Erste-Anfrage-Latenz.
HippoRAG [ESTIMATIVA: Originalpaper verifizieren]: inspiriert vom menschlichen assoziativen Gedächtnis, nutzt Graphstruktur, um die Art zu simulieren, wie der Hippocampus Erinnerungen durch gemeinsamen Kontext verknüpft. Besonders effektiv für Multi-Hop-Retrieval, bei dem die Verbindung zwischen Anfrage und Antwort durch Zwischenentitäten läuft.
Hybrid GraphRAG: Vektorsuche identifiziert Einstiegspunkte im Corpus (die relevantesten Dokumente oder Passagen für die Anfrage), dann erkundet Graph-Traversal Entitätsbeziehungen von diesen Einstiegspunkten aus. Die beiden Mechanismen sind komplementär: Vektorsuche für Relevanz, Graph-Traversal für Konnektivität.
Der Kosten-Kompromiss ist real und es lohnt sich, ihn klar auszusprechen: Graphkonstruktion ist teurer und komplexer als Vektor-Indizierung. Qualität der Entitätsextraktion bestimmt die Graphqualität. Schlechte Entitätsextraktion, bei der der LLM Entitäten falsch identifiziert, falsche Beziehungen erstellt oder wichtige Verbindungen verpasst, produziert einen Graphen, der schlechter abruft als Vektoren allein. Der Nutzen der Graphstruktur liegt in Anfragetypen, die Beziehungs-Reasoning erfordern. Sie auf Anfragen anzuwenden, die das nicht erfordern, fügt Kosten ohne Qualitätsgewinn hinzu.
Die Enterprise-Anwendungsfälle, die Graphen bevorzugen
Das Muster, das einen graphengeeigneten Anwendungsfall identifiziert: Die Anfrage hat die Struktur “Finde Entitäten vom Typ A, die über Beziehung C mit Entitäten vom Typ B verbunden sind.”
Compliance-Ketten-Anfragen: “Welche regulatorischen Anforderungen gelten für Prozess X in Jurisdiktionen A, B und C?” Regulatorische Anforderungen existieren als Entitäten. Prozesse existieren als Entitäten. Jurisdiktionen existieren als Entitäten. Die Beziehungen zwischen ihnen überspannen mehrere regulatorische Dokumente, die nie geschrieben wurden, um zusammen gelesen zu werden. Graph-Traversal rekonstruiert die Kette; Vektorsuche gibt individuelle Passagen zurück, die der Benutzer manuell verbinden muss.
Organisatorisches Wissen: “Wer in unserer Organisation hat an Projekten mit Technologie X mit Kunde Y gearbeitet?” Personen, Projekte, Technologien und Kunden sind Entitäten. Ihre Beziehungen sind das Wissen. Kein einzelnes Dokument enthält diese Antwort. Die Antwort wird durch Traversal des Entitätsnetzwerks konstruiert.
Vertragsanalyse: “Welche unserer Lieferantenverträge referenzieren Force-Majeure-Klauseln, die Pandemie-Szenarien einschließen, und welche dieser Lieferanten haben auch offene Bestellungen über einem Schwellenwert?” Das erfordert Entitätsextraktion (Verträge, Lieferanten, Klauseln, Bestellungen), Beziehungsidentifikation (Vertrag referenziert Lieferant, Vertrag enthält Klausel, Lieferant hat Bestellungen) und Multi-Hop-Traversal über Vertrags- und ERP-Daten gleichzeitig.
Produktwissen: “Welche unserer Produktlinien haben Komponenten von Lieferant X, und welche dieser Komponenten haben offene Qualitätsvorfälle?” Stücklisten-Beziehungen plus Qualitätsvorfalls-Verknüpfung. Ein Graph-Traversal. Keine semantische Suche.
Der State-of-the-Art-Stack im Jahr 2026
Neo4j 5.x: produktionsreife Graph-Datenbank mit nativem Vektorindex-Support. Hybrid-Graphen-plus-Vektor-Anfragen werden in einer einzigen Abfrage gegen eine einzige Datenbank ausgeführt. Graph-Traversal und semantische Suche sind keine separaten Systeme. Für Organisationen, die beide Retrieval-Typen benötigen, eliminiert Neo4j die Integrationskomplexität der Pflege separater Graphen- und Vektorspeicher. Enterprise-Adoption bei großen Finanz- und Technologieorganisationen ist in öffentlichen Case Studies bestätigt.
Microsoft GraphRAG (Open Source, Apache 2.0): Entitätsextraktions-Pipeline, Community-Erkennung für globale Anfrage-Synthese und zwei Anfragemodi: global (synthetisiert über Community-Zusammenfassungen, geeignet für breite analytische Fragen) und lokal (entitätsfokussiertes Retrieval, geeignet für spezifische Entitäts-Anfragen). Das GitHub-Repository ist öffentlich verfügbar; Lizenzstatus und Wartung vor der Adoption verifizieren.
LazyGraphRAG: die kostenoptimierte Variante für Organisationen, bei denen die Vorab-Graphkonstruktionskosten die primäre Barriere sind. Damit beginnen, wenn die vollständigen Microsoft-GraphRAG-Indizierungskosten prohibitiv sind.
Eine Namensklarstellung, die explizit gemacht werden sollte: LangGraph ist ein Agent-Orchestrierungs-Framework von LangChain. Es ist kein Graph-Retrieval-System. Es verwaltet agent state graphs, Branching und Zyklen. Sein Name schafft Verwirrung in Diskussionen, die Agent-Orchestrierung mit Graph-RAG mischen. Es sind unterschiedliche Tools, die unterschiedliche Probleme lösen.
Wann Vector RAG noch die richtige Wahl ist
Der Großteil der Enterprise-Dokumenten-Q&A-Workloads ist mit gut implementiertem Vector RAG beantwortbar. Die Tendenz, nach Graph-Komplexität zu greifen, bevor validiert wird, ob Vektor-Retrieval tatsächlich versagt, ist ein Muster, dem es wert ist, zu widerstehen.
Für Single-Dokument-Q&A, Prozedurensuche, Klausel-Retrieval und Richtlinienfragen mit einer einzigen Jurisdiktion übertrifft hierarchisches Vektor-RAG mit Hybrid-Suche Graphen bei wesentlich geringerer Komplexität und Kosten. Graphkonstruktion fügt einen LLM-intensiven Extraktionsschritt, eine zu pflegende Graph-Datenbank und zu debuggenden Traversal-Logik hinzu. Wenn der Anfragetyp keine Entitätsverknüpfung über Dokumente erfordert, hat diese Komplexität keine Rendite.
Das Entscheidungsframework:
- Wenn der Anfragetyp das Finden relevanten Texts innerhalb von Dokumenten erfordert: Vector RAG verwenden, in Retrieval-Qualität investieren
- Wenn der Anfragetyp das Finden von Entitäten und das Traversieren von Beziehungen über Dokumente erfordert: eine Graph-Schicht hinzufügen
- Wenn unsicher: Die Anfragetypen protokollieren, bei denen Vector RAG versagt; wenn das Scheiternsmuster Multi-Entitäten- und Multi-Dokument-Scheitern ist, ist das das Signal zur Bewertung von Graphen
Ein weiterer Punkt, den die Begeisterung für hybride Architekturen manchmal verdunkelt: Ein mittelmäßiger Graph plus ein mittelmäßiger Vektorspeicher ist schlechter als ein exzellenter Vektorspeicher allein. Qualität der Entitätsextraktion steuert den gesamten Graphen. Wenn die Extraktion unzuverlässig ist, ruft der Graph falsche Beziehungen selbstsicher ab. Exzellentes Vektor-Retrieval auf gut ingestierten Dokumenten hat keinen solchen kompoundierenden Fehler-Modus.
Hybrid ist nicht immer besser. Die Raffinesse liegt im Wählen der richtigen Architektur für den Anfragetyp, nicht im Deployen der komplexesten.
Praktischer Migrationspfad
Die Migration von reinem Vektor-RAG zu hybridem Graph-plus-Vektor ist kein Ersatz. Es ist eine Ergänzung. Die Sequenz, die Störungen vermeidet:
Mit Vektor-RAG beginnen. Deployen, instrumentieren und einen Eval-Harness bauen. Eine Qualitätsbaseline etablieren. Die spezifischen Anfragetypen identifizieren, bei denen das System versagt.
Das Scheiternsmuster klassifizieren. Wenn fehlschlagende Anfragen dem Multi-Entitäten- und Multi-Dokument-Muster folgen, ist das das Signal. Wenn sie aus anderen Gründen scheitern (schlechtes Chunking, fehlende Metadaten, Halluzination aufgrund von Kontextlücken), diese zuerst beheben. Graph fügt keinen Wert hinzu, wenn das zugrundeliegende Vektor-Retrieval defekt ist.
Entitätsextraktion als Hintergrundanreicherung durchführen. Graphkonstruktion kann parallel zu RAG-Operationen auf dem bestehenden Corpus fortschreiten. Es erfordert kein Offline-Nehmen des Systems. Der Graph wird als zusätzlicher Retrieval-Pfad verfügbar, ohne den bestehenden zu stören.
Produktionsarchitektur: Neo4j mit Vektorindex und Property-Graph für die duale Retrieval-Schicht, LangGraph als Agent-Orchestrierung, wenn das Retrieval Multi-Step-Reasoning beinhaltet, RAGAS für Evaluationsmetriken über beide Retrieval-Typen, und LangSmith oder Langfuse für Observability.
Die Ingestion Pipeline, die sowohl Vektor- als auch Graph-Systeme speist, ist der Ort, an dem die meisten Qualitätsprobleme entstehen. Diese Architektur ist in The Ingestion Pipeline Nobody Talks About abgedeckt.
Für Enterprise-Teams, die Knowledge-Graph-Integration als Teil einer AI-First-Architektur bewerten, kartiert der AI Opportunity Sprint die Entscheidung, bevor der Build beginnt.