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 gut, solange die Antwort in einem einzelnen Textabschnitt steht. Bei diesen Fragen steht sie das nicht:

• "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, sondern nach Zusammenhängen, die über mehrere Dokumente verteilt sind.

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
• Für Dokumentensuche häufig ein einfacherer Ausgangspunkt; der Aufwand hängt von Daten und Anforderungen ab
• Als Ausgangspunkt geeignet, wenn die Antwort in einem Abschnitt steht ("Was steht im Vertrag zu X?")

Schwächen von Vector RAG

• Beziehungen brauchen Logik: Separate Chunks verbinden "Kunde Müller" und "Deal Mozartstraße" nicht automatisch. Zusätzliche Retrieval- oder Abfragelogik kann diese Beziehung herstellen.
• Möglicher Kontextverlust: Chunking kann den Zusammenhang zum Gesamtdokument abschwächen; Überlappung, Metadaten und Retrieval-Logik beeinflussen das Ergebnis.
• Verkettung braucht Orchestrierung: "Zeig mir alle Deals von Kunden aus Hamburg" verlangt mehrere Schritte. Vector RAG kann das über wiederholtes Suchen lösen, braucht dafür aber mehrere Durchläufe
• Lückenbehandlung: Wenn der richtige Chunk nicht gefunden wird, hängt eine sichtbare Fehlanzeige von der Evidenz- und Antwortlogik der Anwendung ab.

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]

Fiktives, vereinfachtes Beispiel: Die folgenden Kanten illustrieren eine Abfrage. Das Ergebnis wäre eine zu prüfende Hypothese; der Graphpfad allein beweist keine Ursache.

1. Finde Kunde Müller
2. Folge INTERESSIERT_AN zu Objekt Mozartstraße
3. Folge FEHLT_DOKUMENT zu Energieausweis
4. → Hypothese: "Der fehlende Energieausweis könnte den Deal verzögern."

Stärken von Knowledge Graphs

• Beziehungswissen: Speichert, wer mit wem und was mit was verbunden ist
• Verkettete Fragen: "Zeig mir alle Deals von Kunden, deren Notar in Hamburg sitzt"
• Explizite Lücken: Ein Graph kann fehlende Beziehungen sichtbar machen. Ob die Anwendung eine Lücke meldet, hängt von ihrer Abfrage- und Antwortlogik ab.
• Nachvollziehbarkeit: Ein ausgegebener Abfragepfad kann zeigen, welche Knoten und Kanten verwendet wurden. Er beweist allein weder Ursache noch Richtigkeit.

Schwächen von Knowledge Graphs

• Strukturierte Daten nötig: Unstrukturierte Texte müssen erst extrahiert werden
• Schema-Design: Die Ontologie muss durchdacht sein, und sie zu ändern ist teuer
• Semantische Suche: Eine reine Knoten-/Kantenabfrage braucht zusätzliche Suchlogik oder Embeddings, um ähnliche Begriffe zu finden.
• Aufwand beim Nachschlagen: Steht die Antwort in einem Absatz, muss der zusätzliche Nutzen einer Graphstruktur erst gezeigt werden.

GraphRAG: beide Verfahren zusammen

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        │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  4. LLM-Antwort auf Basis der gefundenen Fakten         │
│     Hypothese im fiktiven Beispiel:                      │
│     Energieausweis als möglicher Engpass; bitte prüfen.  │
└─────────────────────────────────────────────────────────┘

Was die Messungen wirklich zeigen

An dieser Stelle stehen in vielen Texten Zahlen wie "3,4x genauer als Vector RAG". Diese Zahl hält einer Prüfung nicht stand, und wir haben sie deshalb von dieser Seite entfernt. Was sich belegen lässt, ist Folgendes.

Beim einfachen Faktenabruf liegt klassisches RAG vorn. Tabelle 2 von GraphRAG-Bench v1 berichtet für den Novel-Datensatz mit der dort verwendeten Genauigkeitsmetrik 60,9 für RAG mit Reranking und 60,1 für HippoRAG2; Microsoft GraphRAG global steht in einer separaten Zeile bei 36,9. Das sind Ergebnisse dieses Datensatzes und dieser Methoden, keine allgemeine Rangliste.

Bei verketteten Fragen kehrt sich das auf demselben Novel-Datensatz um. Tabelle 2 von GraphRAG-Bench v1 berichtet 53,4 für HippoRAG2 und 42,9 für RAG mit Reranking. Der Unterschied gilt für diese Aufgabenart, Metrik und Version.

Der Effekt hängt vom Datensatz und der Retriever-Konfiguration ab. HippoRAG v3 berichtet Recall@5 für ColBERTv2 gegenüber HippoRAG mit Contriever: auf 2WikiMultiHopQA 68,2 gegenüber 89,5, auf MuSiQue 49,2 gegenüber 52,1. Das ist kein kontrollierter Test der Graphstruktur allein.

Ein einzelner Benchmark vergleicht zwei Abfrageansätze. In einem Benchmark über 43 Fragen an ein Versicherungsschema beantwortete GPT-4 direkt per SQL 16,7 Prozent korrekt, über eine Wissensgraph-Repräsentation derselben Daten 54,2 Prozent. Verglichen wurde hier Text-to-SQL gegen Text-to-SPARQL, nicht Graph gegen Vektorsuche.

Der Tokenvergleich ist ebenfalls eng begrenzt. Abbildung 8 von GraphRAG-Bench v1 berichtet auf dem Novel-Datensatz durchschnittlich 879 Prompt-Token pro Anfrage für V-RAG, 38.707 für Microsoft GraphRAG lokal und 331.375 für Microsoft GraphRAG global. Diese Versuchsanordnung belegt weder gesamte Betriebskosten noch eine allgemeine Tokenregel.

Vorsicht bei Bewertungen durch ein zweites Sprachmodell. Zeng et al. v1, Abschnitt 5.1, ließen zwei identische LightRAG-Instanzen gegeneinander antreten; das Protokoll erzeugte eine 90:10-Verteilung. Die Autoren führen das auf Positions- und Einzeldurchlauf-Bias zurück.

Microsoft verwendet in der zitierten Untersuchung ein zweites Sprachmodell zur Bewertung mehrerer Qualitätsdimensionen. Solche Modellurteile sind protokollabhängig und begründen keine universelle Rangfolge.

Wann brauchen Sie was?

Fazit: Die Frage entscheidet, nicht die Technik

Wenn Ihre Nutzer Dokumente durchsuchen und einzelne Fakten nachschlagen, ist Vector RAG häufig die einfachere Ausgangsarchitektur. Kosten und Eignung hängen von Daten, Abfragen, Qualitätsanforderungen und Betrieb ab. Ein Knowledge Graph kommt in Betracht, wenn Fragen regelmäßig mehrere Beziehungen verbinden oder verwendete Knoten und Kanten sichtbar sein sollen.

Auch für CRM- und ERP-Daten bleibt das eine Entscheidung pro Anwendungsfall. Eine Graphstruktur kann Beziehungen ausdrücklich modellieren; daraus folgt keine generelle Überlegenheit oder fertige Integration.

Die auf dieser Website beschriebene Osiris-Zielarchitektur sieht Neo4j für graphbasierte Abfragen vor. Der konkrete Datenumfang, die Anbindungen und der Betriebsstatus müssen je Projekt geprüft werden.

→ Wie Osiris GraphRAG implementiert