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
• Einfach zu implementieren
• Stark bei Fragen, deren Antwort in einem Abschnitt steht ("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
• Verkettung ist teuer: "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
• Stilles Scheitern: Wird der richtige Chunk nicht gefunden, merkt das System es nicht. Das LLM antwortet trotzdem

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, folgt das System den Kanten:

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: Speichert, wer mit wem und was mit was verbunden ist
• Verkettete Fragen: "Zeig mir alle Deals von Kunden, deren Notar in Hamburg sitzt"
• Klare Fehlanzeige: Entweder die Beziehung existiert oder nicht. Fehlt sie, sagt das System das, statt zu raten
• Nachvollziehbarkeit: Der Pfad durch den Graphen zeigt, wie die Antwort zustande kam

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
• Kein semantisches Verständnis: Findet exakte Treffer, keine "ähnlichen" Konzepte
• Schwächer beim einfachen Nachschlagen: Steht die Antwort in einem Absatz, ist der Graph Umweg statt Abkürzung

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         │
│     "Der Deal stockt seit 12 Tagen weil der             │
│      Energieausweis fehlt. Ansprechpartner: Hr. Weber"  │
└─────────────────────────────────────────────────────────┘

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. GraphRAG-Bench vergleicht Graphverfahren und klassisches RAG auf denselben Aufgaben. Beim reinen Nachschlagen einzelner Fakten erreicht klassisches RAG mit Reranking 60,9 Punkte Genauigkeit, das beste Graphverfahren 60,1, Microsofts GraphRAG im globalen Modus 36,9.

Bei verketteten Fragen dreht sich das Bild. Auf denselben Daten, aber bei Fragen die mehrere Fakten verbinden müssen: 53,4 für das beste Graphverfahren gegen 42,9 für klassisches RAG. Rund zehn Punkte Vorsprung, auf einer Aufgabenart.

Der Vorsprung hängt stark vom Datensatz ab. HippoRAG hebt den Recall@5 auf dem Datensatz 2WikiMultiHopQA von 68,2 auf 89,5. Auf MuSiQue, ebenfalls mehrstufig, nur von 49,2 auf 52,1. Dieselbe Methode, sehr unterschiedlicher Effekt.

Strukturierte Repräsentation schlägt rohe Datenbankabfrage. 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.

Bei fairem Token-Budget schrumpft der Vorsprung. Das ist der wichtigste Einwand, und er wird selten mitgeliefert. Graph-Verfahren holen sich pro Anfrage oft deutlich mehr Kontext als klassisches RAG. Han et al. haben klassischem RAG dasselbe Budget gegeben: auf MultiHop-RAG steigt es damit von 65,8 auf 71,0 Punkte und liegt gleichauf mit dem Graph-Verfahren (71,2). Was übrig bleibt, sind zeitbezogene und vergleichende Fragen: dort 43,7 für das aufgestockte klassische RAG gegen 49,1 für den Graphen.

Zum Token-Verbrauch, und hier steht die verbreitete Behauptung auf dem Kopf: Graph-Verfahren brauchen in der Regel mehr Token, nicht weniger. Auf GraphRAG-Bench liegt klassisches RAG bei 879 Token pro Anfrage, Microsofts GraphRAG im lokalen Modus bei 38.707 und im globalen Modus bei 331.375. Die einzige belegte Einsparung bei Microsoft gilt gegenüber der Zusammenfassung der Rohtexte (9- bis 43-mal weniger), nicht gegenüber der Vektorsuche.

Vorsicht bei Bewertungen durch ein zweites Sprachmodell. Zeng et al. haben den üblichen Bewertungsaufbau geprüft, indem sie ein Verfahren gegen eine identische Kopie seiner selbst antreten ließen. Das Protokoll erklärte die eine Kopie mit 90 zu 10 zum Sieger. Positions- und Längeneffekte erzeugen also Vorsprünge, wo keine sind. Jede Prozentzahl aus solchen Vergleichen, auch die von Microsoft, ist mit diesem Vorbehalt zu lesen.

Eine Einordnung, die selten dazugesagt wird: Microsoft bewertet die Antwortqualität über ein zweites LLM als Schiedsrichter, entlang der Kriterien Vollständigkeit, Vielfalt und Nützlichkeit. Beim Kriterium Direktheit gewinnt Vector RAG in allen Vergleichen.

Wann brauchen Sie was?

Use Case	Vector RAG	GraphRAG
Fragen zu Dokumenteninhalten	Stark	Gleichauf
Einzelne Fakten nachschlagen	Stark	Eher schwächer
Fragen über mehrere Schritte	Schwach	Kernstärke
CRM/ERP Integration	Begrenzt	Native
Nachvollziehbare Antworten	Schwach	Pfad sichtbar
Setup-Komplexität	Einfach	Höher

Fazit: Die Frage entscheidet, nicht die Technik

Wenn Ihre Nutzer Dokumente durchsuchen und einzelne Fakten nachschlagen, reicht Vector RAG, und es ist die billigere Lösung. Ein Knowledge Graph lohnt sich, wenn Ihre Fragen regelmäßig mehrere Schritte überspringen müssen, wenn Sie nachvollziehen wollen wie eine Antwort zustande kam, oder wenn ein falsches Ergebnis teurer ist als ein fehlendes.

Für CRM- und ERP-Daten trifft das meistens zu, weil dort der Wert in den Verbindungen liegt und nicht in den einzelnen Datensätzen. Aber es ist eine Entscheidung pro Anwendungsfall, keine generelle Überlegenheit.

Das belastbarste Beispiel aus dem Betrieb stammt von LinkedIn. Der Support wurde per Zufall in zwei Gruppen geteilt, eine mit graphgestütztem Zugriff auf frühere Tickets, eine ohne. Die mittlere Bearbeitungszeit pro Fall sank von sieben auf fünf Stunden, also um 28,6 Prozent. Bemerkenswert ist die Bauart: der Graph bildet die Struktur der Tickets und ihre ausdrücklichen Verweise ab, nicht aus Fließtext geratene Entitäten. Genau diese Form hat auch die Aktenlage in einem Maklerbüro.

Osiris nutzt Neo4j als Knowledge Graph und kombiniert beide Verfahren.

→ Wie Osiris GraphRAG implementiert