Knowledge Graphs vs. Vector RAG: Der fundamentale Unterschied

Das Problem mit "einfachem" RAG

RAG (Retrieval Augmented Generation) ist der Standard-Ansatz um LLMs mit externem Wissen zu verbinden. Die Idee: Bevor das LLM antwortet, suchen wir relevante Dokumente und geben sie als Kontext mit.

Das funktioniert - bis Sie Fragen stellen wie:

• "Warum stockt der Deal mit Kunde Müller?"
• "Welche Objekte haben ähnliche Probleme wie die Mozartstraße?"
• "Wer ist der Notar für die Deals in Hamburg?"

Diese Fragen brauchen Beziehungswissen. Sie fragen nicht nach einem Dokument - Sie fragen nach Zusammenhängen.

Wie Vector RAG funktioniert

Schritt 1: Indexierung

Ihre Dokumente werden in kleine Chunks zerlegt (z.B. 500 Tokens). Jeder Chunk wird durch ein Embedding-Modell in einen Vektor umgewandelt - eine mathematische Repräsentation der semantischen Bedeutung.

Schritt 2: Suche

Ihre Frage wird ebenfalls in einen Vektor umgewandelt. Dann sucht das System nach den Chunks, deren Vektoren am ähnlichsten sind (Cosine Similarity).

Schritt 3: Antwort

Die ähnlichsten Chunks werden als Kontext an das LLM gegeben, das dann antwortet.

Stärken von Vector RAG

• Findet semantisch ähnliche Inhalte (nicht nur Keywords)
• Einfach zu implementieren
• Gut für Dokumenten-Fragen ("Was steht im Vertrag zu X?")

Schwächen von Vector RAG

• Keine Beziehungen: "Kunde Müller" und "Deal Mozartstraße" sind separate Chunks - das System weiß nicht, dass sie verbunden sind
• Kontextverlust: Chunks sind isoliert. Der Zusammenhang zum Gesamtdokument geht verloren
• Keine Traversierung: "Zeig mir alle Deals von Kunden aus Hamburg" erfordert Multi-Hop Reasoning - Vector RAG kann das nicht
• Halluzinationsrisiko: Wenn der richtige Chunk nicht gefunden wird, rät das LLM

Wie Knowledge Graphs funktionieren

Ein Knowledge Graph speichert Wissen als Entitäten (Knoten) und Beziehungen (Kanten):

[Kunde: Müller] --INTERESSIERT_AN--> [Objekt: Mozartstraße]
       |                                      |
       |                                      |
 --HAT_NOTAR-->                        --FEHLT_DOKUMENT-->
       |                                      |
       v                                      v
[Notar: Schmidt]                      [Dokument: Energieausweis]

Traversierung statt Suche: Um herauszufinden warum der Deal stockt, traversiert das System den Graphen:

1. Finde Kunde Müller
2. Folge INTERESSIERT_AN zu Objekt Mozartstraße
3. Folge FEHLT_DOKUMENT zu Energieausweis
4. → "Deal stockt weil Energieausweis fehlt"

Stärken von Knowledge Graphs

• Beziehungswissen: Versteht WER mit WEM und WAS mit WAS verbunden ist
• Multi-Hop Queries: "Zeig mir alle Deals von Kunden, deren Notar in Hamburg sitzt"
• Deterministische Antworten: Entweder die Beziehung existiert oder nicht - kein Raten
• Erklärbarkeit: Der Pfad durch den Graphen zeigt WIE die Antwort zustande kam

Schwächen von Knowledge Graphs (alleine)

• Strukturierte Daten nötig: Unstrukturierte Texte müssen erst extrahiert werden
• Schema-Design: Die Ontologie muss durchdacht sein
• Kein semantisches Verständnis: Findet nur exakte Matches, keine "ähnlichen" Konzepte

GraphRAG: Das Beste aus beiden Welten

GraphRAG kombiniert Knowledge Graphs mit Vector RAG:

┌─────────────────────────────────────────────────────────┐
│  Frage: "Warum stockt der Deal Mozartstraße?"           │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  1. Entity Extraction: "Deal Mozartstraße" identifiziert│
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  2. Graph Traversal: Beziehungen folgen                 │
│     Deal → fehlende_Dokumente → Energieausweis          │
│     Deal → letzte_Aktivität → vor 12 Tagen              │
│     Deal → Ansprechpartner → Herr Weber                 │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  3. Context Compression: Nur relevanter Subgraph        │
│     (100x weniger Token als ganzes Dokument)            │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  4. LLM Antwort mit deterministische Fakten             │
│     "Der Deal stockt seit 12 Tagen weil der             │
│      Energieausweis fehlt. Ansprechpartner: Hr. Weber"  │
└─────────────────────────────────────────────────────────┘

Die Zahlen: GraphRAG vs. Vector RAG

Metrik	Vector RAG	GraphRAG	Verbesserung
Genauigkeit bei Beziehungsfragen	Baseline	3,4x höher	+240%
Halluzinationsrate	Baseline	6-90% niedriger	Signifikant
Multi-Hop Query (3 Hops)	Nicht möglich	30-150ms	∞
Token-Verbrauch	Baseline	100x weniger	99% Reduktion

Quellen: Microsoft Research GraphRAG Paper (2024), Neo4j Benchmarks

Wann brauchen Sie was?

Use Case	Vector RAG	GraphRAG
Fragen zu Dokumenteninhalten	✅ Gut	✅ Auch gut
Beziehungsfragen (Wer kennt wen?)	❌ Schwach	✅ Perfekt
Multi-Hop Reasoning	❌ Nicht möglich	✅ Kernstärke
CRM/ERP Integration	⚠️ Begrenzt	✅ Native
Erklärbare Antworten	⚠️ Schwach	✅ Pfad sichtbar
Setup-Komplexität	✅ Einfach	⚠️ Höher

Fazit: Für Business-Anwendungen führt kein Weg an Knowledge Graphs vorbei

Wenn Sie nur Dokumente durchsuchen wollen, reicht Vector RAG. Aber sobald Sie mit CRM-Daten, Kundenbeziehungen, Prozessen und Zusammenhängen arbeiten, brauchen Sie einen Knowledge Graph.

Osiris nutzt Neo4j als Knowledge Graph und kombiniert es mit GraphRAG für das Beste aus beiden Welten.

→ Wie Osiris GraphRAG implementiert