GraphRAG Knowledge Graph: Neo4j, Microsoft, RDF im Vergleich

Pexon Consulting | 11 Min. Lesezeit | 13.06.2026

TL;DR

GraphRAG Knowledge Graph ist die nächste Evolutionsstufe von Vector-RAG: Aus 30-50 % richtigen Antworten werden 75-90 % bei Multi-Hop-Fragen. Microsoft GraphRAG, Neo4j und RDF sind die drei realen Optionen — jede mit unterschiedlichen Trade-offs. Pexon empfiehlt Ontologie-Light statt vollständiger OWL und Neo4j Property Graph statt RDF-Triple-Store für Enterprise-Workloads. Pattern und Aufbau in 8-12 Wochen.

Warum reines Vector-RAG bei 40-60 % Multi-Hop-Genauigkeit hängenbleibt

Vector-RAG ist 2025/2026 in nahezu jedem deutschen Mittelstands-RAG-System der Default. Embedding-Modell vektorisiert Dokumente, ähnlichkeitsbasierter Retrieval, LLM antwortet. Das funktioniert gut für eine konkrete Klasse von Fragen: „Was steht in der Wartungsanleitung über das Werkzeug X?“ — eine Frage, eine Quelle, eine Antwort.

Sobald die Frage zwei oder drei Hops braucht, bricht das Modell zusammen. „Welche Bauteile von Maschine A werden vom Lieferanten B geliefert und sind in den letzten 6 Monaten reklamiert worden?“ — drei Datenquellen, drei Hops, keine einfache Ähnlichkeits-Suche. Vector-RAG findet einzelne Snippets aus jeder Quelle, kann aber die Verbindung dazwischen nicht ziehen. Antwort-Qualität in unseren Messungen: 30-50 %, mit hoher Tendenz zu Halluzinationen.

Aus drei Pexon-Pilotprojekten in 2025/2026 mit produktiven RAG-Systemen: Etwa 35-55 % der User-Fragen sind faktisch Multi-Hop-Fragen, ohne dass User oder Engineering das so klassifizieren. Sie sehen nur, dass das RAG „manchmal nicht gut antwortet“ — und niemand kann erklären, warum genau. Genau dort hebt ein GraphRAG Knowledge Graph die Antwort-Qualität auf das Niveau, das User implizit erwartet haben.

Was ein GraphRAG Knowledge Graph wirklich anders macht

Ein GraphRAG Knowledge Graph speichert nicht Dokumente, sondern Entitäten und Relationen. Eine Wartungsanleitung wird nicht als Embeddings-Block abgelegt, sondern in ihre Bestandteile zerlegt: „Maschine M-12 hat Bauteil B-345, geliefert von Lieferant L-007, mit Reklamation R-2026-04″. Der Graph macht diese Verbindungen explizit und damit für das LLM nutzbar.

Drei strukturelle Vorteile gegenüber Vector-RAG:

1. Multi-Hop-Traversierung. Eine Frage über drei Hops wird zu einer Graph-Query, nicht zu drei nacheinander geschalteten Vector-Searches mit Reranking. Das ist deterministisch und nachvollziehbar.
2. Aggregation und Counting. „Wie viele Bauteile haben mehr als 3 Reklamationen?“ beantwortet ein Graph in einer Cypher- oder SPARQL-Query exakt. Vector-RAG schätzt — schlecht.
3. Konzept-Bridges. Wenn der User „Schmierstoff“ sagt und die Doku „Lubrikant“ verwendet, kann der Graph über die Ontologie diese Brücke schlagen. Vector-RAG braucht dafür ein perfekt trainiertes Embedding — was es selten gibt.

Der Preis dafür: Aufwand bei der Indexierung. Während Vector-RAG ein Embedding pro Chunk braucht, muss GraphRAG Entitäten extrahieren, Relationen identifizieren und konsistent verknüpfen. Das ist ein 5-15x höherer Initialaufwand — der sich aber in Multi-Hop-Workloads schnell amortisiert.

Microsoft GraphRAG, Neo4j, RDF — die drei realen Optionen

Wer 2026 einen Knowledge Graph für RAG aufbauen will, hat drei seriöse Optionen. Jede mit klarem Profil.

Microsoft GraphRAG. Open-Source seit 2024, GitHub-Repository pflegt Microsoft Research. Der Indexer extrahiert Entitäten und Relationen automatisch aus Texten via LLM, gruppiert sie via Leiden-Algorithmus in Communities und erzeugt hierarchische Zusammenfassungen. Local Search beantwortet entity-spezifische Fragen, Global Search beantwortet themenübergreifende Fragen. Stärke: schneller Einstieg, dokumentiert, läuft auf Azure. Schwäche: Token-intensiv (Indexierung kostet 100-1.000 USD pro 1 Mio Wörter), proprietäre Indexstruktur.

Neo4j Property Graph. Die etablierte Graph-Datenbank, Cypher als Query-Sprache, breite Tooling-Landschaft (Bloom für Visualisierung, GDS für Graph Data Science, Aura für Cloud-Hosting). Stärke: Production-Reife, hohe Performance, einfache Property-Modellierung. Schwäche: Property Graph ist Standard von Neo4j, nicht von W3C — Vendor-Lock-in ist real, auch wenn openCypher das mildert.

RDF mit SPARQL. W3C-Standard, Triple-Stores wie Stardog, GraphDB von Ontotext, Apache Jena, Virtuoso. Stärke: maximale Standard-Konformität, ideal für Linked Data und Cross-Organisations-Integration, eingebaute Reasoning-Fähigkeit (OWL). Schwäche: Tooling weniger reif als Neo4j, SPARQL hat steile Lernkurve, Triple-Store-Performance bei großen Graphen oft schwächer als Property Graphs.

Unsere klare Empfehlung für 80 % der deutschen Mittelstands-Cases: Neo4j Property Graph als Hauptdatenebene, kombiniert mit Microsoft GraphRAG als initialer Indexer für die Entitäts- und Relations-Extraktion. RDF lohnt sich, wenn Sie wirklich Standards-Interoperabilität brauchen — etwa für branchenübergreifende Datenmodelle oder regulatorische Linked-Data-Pflichten.

Ontologie-Light statt OWL — die pragmatische Empfehlung

Klassische Knowledge-Engineering-Schule beginnt mit einer vollständigen Ontologie: Alle Konzepte modelliert, OWL-Axiome formuliert, Reasoner konfiguriert. Aufwand: 6-18 Monate, bevor das erste Tool damit etwas tut. Ergebnis: oft eine perfekte Ontologie, die niemand pflegt.

Wir empfehlen den entgegengesetzten Pfad: Ontologie-Light. Konkret heißt das:

• 10-20 Entitäts-Typen für den ersten Wurf (Maschine, Bauteil, Lieferant, Dokument, Anforderung, Norm, Person, Organisation, Standort, Vorgang)
• 20-50 Relations-Typen (hat_bauteil, geliefert_von, referenziert_norm, verantwortlich_für, etc.)
• Einfache Taxonomien für Hierarchien (z.B. „Werkzeugmaschine“ ist Subtyp von „Maschine“), aber kein vollständiges OWL
• Keine schweren Axiome wie Disjointness-Constraints oder Cardinality-Restrictions am Anfang — nur dann, wenn ein konkreter Use-Case sie verlangt
• SKOS-light für Synonyme und Übersetzungen (z.B. „Schmierstoff“ ↔ „Lubrikant“), als pragmatischer Ersatz für komplexere ontologische Modellierung

Der Hebel: In 2-3 Wochen steht eine erste Ontologie, die für 80-90 % der praktischen Fragen ausreicht. Erweiterungen erfolgen, wenn echte Lücken sichtbar werden — nicht spekulativ.

Wer mit reiner OWL-Disziplin startet, hat nach 9 Monaten ein perfektes Modell und kein produktives RAG. Wer mit Ontologie-Light startet, hat nach 3 Monaten ein produktives RAG und reift das Modell mit jeder weiteren Woche. Konfidenz: hoch, aus drei abgeschlossenen Pexon-Projekten.

Architektur eines produktiven GraphRAG Knowledge Graph

Drei Schichten, die in jedem Pexon-Setup wiederkehren:

+---------------+     +-----------------+     +----------------+
| Quelldaten    |     | Indexer-Pipeline|     | Neo4j Property |
| (PDF, SAP,    |---->| - LLM-Entity-   |---->| Graph          |
|  SharePoint,  |     |   Extraction    |     | (8-12 GB für   |
|  Confluence)  |     | - Relation-     |     |  Mittelstand)  |
+---------------+     |   Linking       |     +----------------+
                      | - Dedup + Merge |             |
                      +-----------------+             v
                                            +------------------+
                                            | Hybrid-RAG-Layer |
                                            | - Cypher-Querys  |
                                            | - Vector-Search  |
                                            | - LLM-Synthesis  |
                                            +------------------+
                                                     |
                                                     v
                                            +------------------+
                                            | User-Antwort     |
                                            | mit Source-Cite  |
                                            +------------------+

Schicht 1 — Indexer-Pipeline. Liest Quelldaten, extrahiert Entitäten und Relationen via LLM (typisch Claude Sonnet 4 oder GPT-4.1 für Extraktion), dedupliziert über Embedding-Match plus String-Similarity, mergt Entitäten gleicher Identität. Das ist der teuerste Schritt — pro 1 Mio Token Quelldaten ca. 80-300 EUR LLM-Kosten.

Schicht 2 — Neo4j Property Graph. Speichert Entitäten als Knoten, Relationen als Kanten, mit Properties auf beiden Seiten. Embedded auch die Dokumenten-Chunks als Properties — damit ist Vector-Search im selben Store möglich (Neo4j 5.x mit Vector Index). Größe für Mittelstands-Knowledge-Bases: 100k-1 Mio Knoten, 500k-5 Mio Kanten, 8-12 GB Storage.

Schicht 3 — Hybrid-RAG-Layer. Die eigentliche Magie: Eine User-Frage wird zuerst klassifiziert (Single-Hop / Multi-Hop / Aggregation), dann läuft entweder eine Cypher-Query, eine Vector-Search oder eine Kombination. Das LLM synthetisiert die Antwort aus den retrievten Graph-Knoten und Original-Text-Chunks.

Indexierung — wie Entitäten und Relationen extrahiert werden

Der entscheidende Erfolgsfaktor ist die Indexer-Pipeline. Aus zwei laufenden Projekten der Standard-Ablauf:

1. Dokument-Vorverarbeitung. PDF, DOCX, HTML in saubere Markdown-Repräsentation überführen. Tabellen werden in strukturierte Form extrahiert (CSV-ähnlich), Bilder via VLM beschrieben.
2. Chunking mit Kontext-Erhalt. Nicht hartes 500-Token-Chunking, sondern semantisches Chunking entlang Überschriften und Absatzgrenzen.
3. Entitäts-Extraktion via LLM. Pro Chunk ein LLM-Call mit strukturiertem Output-Schema. Pydantic-Model erzwingt die Entitäts- und Relations-Typen aus der Ontologie-Light.
4. Entitäts-Resolution. „Maschine M-12″, „M12″ und „Werkzeugmaschine M-12″ sind dieselbe Entität. Resolution via Embedding-Match plus String-Similarity plus Domain-Regeln.
5. Konfidenz-Scoring. Jede extrahierte Relation bekommt einen Confidence-Score. Niedrige Konfidenz landet in einem Review-Pool für menschliche Kuration.
6. Inkrementelle Updates. Wenn neue Dokumente kommen, läuft die Pipeline nur über die neuen Chunks. Bestehende Entitäten werden referenziert, nicht neu erzeugt.

Die häufigste Falle: Schritt 4 wird unterschätzt. Wer Entitäts-Resolution naiv löst, hat schnell drei „Maschine M-12″-Knoten parallel im Graph — und alle Multi-Hop-Querys gehen schief.

Code-Beispiel — Neo4j + Microsoft GraphRAG hybrid

So sieht der vereinfachte Hybrid-Stack aus, mit Microsoft-GraphRAG-Indexer und Neo4j als persistenter Speicher.

from graphrag.index.workflows import build_index
from neo4j import GraphDatabase
from pydantic import BaseModel

class ExtractedTriple(BaseModel):
    source_entity: str
    relation: str
    target_entity: str
    confidence: float
    source_doc_id: str

driver = GraphDatabase.driver(NEO4J_URI, auth=(NEO4J_USER, NEO4J_PASS))

async def index_documents(docs: list[dict]):
    """Microsoft GraphRAG für Extraktion, Neo4j für Persistierung."""
    # 1) Microsoft GraphRAG extrahiert Entitäten und Relationen
    graph_index = await build_index(
        documents=docs,
        entity_types=["Maschine", "Bauteil", "Lieferant", "Dokument", "Norm"],
        llm_model="gpt-4.1",
    )

    # 2) Triples in Neo4j als Property Graph laden
    with driver.session() as session:
        for triple in graph_index.triples:
            session.run(
                """
                MERGE (s:Entity {name: $src})
                MERGE (t:Entity {name: $tgt})
                MERGE (s)-[r:RELATION {type: $rel}]->(t)
                SET r.confidence = $conf, r.source = $doc
                """,
                src=triple.source_entity,
                tgt=triple.target_entity,
                rel=triple.relation,
                conf=triple.confidence,
                doc=triple.source_doc_id,
            )

async def hybrid_rag_query(user_question: str):
    """Multi-Hop-Frage: Cypher-Query + LLM-Synthesis."""
    cypher = await classify_and_build_cypher(user_question)
    with driver.session() as session:
        graph_results = session.run(cypher).data()
    answer = await llm_synthesize(user_question, graph_results)
    return answer

Drei wichtige Detail-Entscheidungen:

1. MERGE statt CREATE in Cypher. Vermeidet Duplikate von Knoten und Kanten. Pflicht für inkrementelle Indexierung.
2. confidence als Property auf der Relation. Erlaubt später Filtering auf zuverlässige Beziehungen (z.B. nur confidence > 0.8 für sicherheitsrelevante Fragen).
3. source als Property auf der Relation. Source-Cite für jede Antwort — der User kann nachvollziehen, aus welchem Dokument die Beziehung stammt. Pflicht für regulierte Workloads.

Welche Use-Cases das wirklich braucht — und welche nicht

Fair-Play: Nicht jeder RAG-Workload profitiert von einem GraphRAG Knowledge Graph. Drei Klassen, in denen sich der Aufwand lohnt:

• Multi-Hop-Wissens-Workloads. Wartungs-Doku mit Querbezügen zu Norm, Lieferant und Historie. Service-Berichte mit Bezug zu vorherigen Vorfällen. Compliance-Audits mit Querverweisen auf Regelwerke.
• Aggregations-Fragen. „Wie viele Vorfälle in den letzten 12 Monaten betrafen Komponente X?“, „Welche Lieferanten haben mehr als 5 Reklamationen?“. Klassische Vector-RAG-Schwäche.
• Konzept-Bridges in mehrsprachigen oder mehrfachen Vokabularen. Wenn dieselbe Sache je nach Fachbereich unterschiedlich heißt, schlägt der Graph die Brücke automatisch.

Drei Klassen, in denen ein Knowledge Graph zu viel Aufwand ist:

• Reine Single-Hop-FAQ. „Wie öffne ich die Wartungsklappe?“ — Vector-RAG reicht völlig.
• Hochdynamische Daten ohne klare Entitäts-Struktur. News-Feeds, freie Tweets, lange Diskussionsverläufe. Hier ist die Entitäts-Extraktion teurer als der Wert des Graphen.
• Sehr kleine Wissensbestände unter 500 Dokumenten. Setup-Aufwand amortisiert sich nicht.

Wir raten aktuell davon ab, GraphRAG als Standard-Antwort auf jeden RAG-Use-Case zu nehmen. Mit Vector-RAG starten, GraphRAG erweitern, wenn die Multi-Hop-Lücke messbar ist.

Kosten und Zeitrahmen

Aus zwei laufenden Pexon-Projekten der typische Setup-Aufwand für einen produktiven GraphRAG Knowledge Graph:

Laufende Kosten: LLM-Tokens für Indexierung typisch 800-2.500 EUR initial, danach 200-600 EUR pro Monat für inkrementelle Updates. Neo4j-Hosting (AuraDB Professional oder selbst gehostet) 400-1.500 EUR pro Monat. Wartung 0,5-1 PT pro Monat.

ROI-Rechnung: Wenn ein bestehendes Vector-RAG-System eine User-Akzeptanz von 55-65 % hat und GraphRAG diese auf 80-90 % hebt, sind die Use-Cases vorher entweder nicht produktiv nutzbar oder erzeugen 30-40 % Korrektur-Aufwand bei Sachbearbeitern. Bei einem 100-User-Setup im Customer-Support sind das 60-80 freigespielte Stunden pro Woche — eine ganze FTE-Stelle. Amortisation 5-10 Monate.

Häufig gestellte Fragen

Brauche ich Microsoft GraphRAG oder kann ich einen GraphRAG Knowledge Graph komplett mit Neo4j bauen?

Beides ist möglich. Microsoft GraphRAG bringt den Indexer und die Community-Detection out-of-the-box — wer das selbst baut, ist 4-8 Wochen länger im Setup. Wer einen sehr spezifischen Use-Case hat (z.B. Manufacturing mit klaren Entitäts-Typen), kann den Indexer auch direkt auf LangChain oder LiteLLM bauen. Unsere Default-Empfehlung: Microsoft GraphRAG als initialer Indexer, Neo4j als persistente Datenebene.

Was ist der Unterschied zu klassischen Wissens-Datenbanken wie Confluence oder SharePoint mit AI-Search?

Wissens-Datenbanken speichern Dokumente, ein Knowledge Graph speichert Beziehungen zwischen Konzepten. AI-Search auf Confluence findet Dokumente mit ähnlichem Wortlaut. GraphRAG findet die Antwort auf „Welcher Lieferant ist bei Bauteilen der Maschine M-12 für die Reklamations-Cluster der letzten 6 Monate verantwortlich?“ — eine Frage, die kein klassisches Such-Werkzeug beantwortet, weil sie drei Hops und eine Aggregation kombiniert.

Funktioniert ein GraphRAG Knowledge Graph auch mit Open-Source-LLMs auf Private KI-Infrastruktur?

Ja, mit Einschränkungen bei der Indexer-Qualität. Frontier-LLMs (Claude Sonnet 4, GPT-4.1) liefern bei der Entitäts- und Relations-Extraktion typischerweise 88-94 % Trefferquote, Open-Source-Modelle wie Qwen 2.5 72B oder Llama 3.3 70B kommen auf 75-85 %. Für regulierte Branchen, die kein Cloud-LLM dürfen, ist Qwen 2.5 die pragmatische Wahl plus etwas mehr menschliche Kuration in der Indexer-Pipeline. Setup über Private KI-Infrastruktur.

Wie pflegt man die Ontologie über die Zeit?

Iterativ aus dem produktiven Betrieb. Wenn der Hybrid-RAG-Layer Fragen nicht zuverlässig beantwortet, gibt es zwei mögliche Ursachen: fehlende Entitäten/Relationen im Graph (Indexer-Fehler) oder fehlende Konzepte in der Ontologie (Ontologie-Lücke). Beide werden im Audit-Log sichtbar. Erweiterungen der Ontologie machen wir typisch monatlich, in kleinen Iterationen von 1-3 neuen Konzepten.

Brauche ich Neo4j Enterprise oder reicht die Community-Edition?

Für die meisten Mittelstands-Setups reicht Neo4j Community Edition (GPL-Lizenz). Enterprise braucht es für Multi-Region-Replikation, Role-Based Access Control auf Knoten-Ebene und kommerziellen Support. Bei regulierten Workloads (Banking, Versicherung, KRITIS) ist Enterprise oft Pflicht — entweder direkt von Neo4j oder über die verwaltete AuraDB-Cloud-Variante in EU-Region.

Lohnt sich der Aufwand bei nur 2.000-5.000 Dokumenten?

Bei diesen kleinen Beständen meist nein. Vector-RAG mit gutem Embedding-Modell (z.B. paraphrase-multilingual-mpnet-base-v2) und sauberem Chunking erreicht oft 70-80 % Antwort-Qualität — was für kleine Bestände ausreicht. GraphRAG lohnt sich ab etwa 8.000-15.000 Dokumenten oder wenn der Use-Case explizit Multi-Hop und Aggregation verlangt.

Nächster Schritt

Wenn Sie aktuell ein bestehendes Vector-RAG bewerten oder einen Knowledge Graph als nächste Stufe planen: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — Use-Case-Analyse, Ontologie-Light-Workshop, Indexer-Pilot auf 500-1.500 Dokumenten als Proof-of-Concept für den Roll-out.

Verwandte Themen