GraphRAG vs. Vector RAG – wann reicht Ähnlichkeit nicht mehr?

Worum es geht

Vector RAG ist 2024 zum De-facto-Standard für „chatte mit deinen Dokumenten" geworden. 2025 hat Microsoft Research GraphRAG veröffentlicht und damit ein altes Problem neu adressiert: Was tun, wenn die Antwort nicht in einem Textabschnitt steht, sondern aus mehreren Stellen zusammengesetzt werden muss?

Dieser Artikel zeigt, wann Vector RAG funktioniert, wann es scheitert, und was GraphRAG anders macht.

Wo Vector RAG hervorragend funktioniert

Vector RAG hat eine sehr klare Stärke: semantische Ähnlichkeit. Du fragst „Wie funktioniert unser Refund-Prozess?", das System findet die drei Absätze, in denen das beschrieben steht, und das LLM formuliert daraus eine saubere Antwort.

Das Setup ist einfach:

Dokument → Chunking → Embedding → Vector Store
                                       ↓
Frage → Embedding → Top-k Nearest Neighbors → LLM-Antwort

Solange die Antwort an einer Stelle steht und der Suchbegriff semantisch in der Nähe liegt, ist Vector RAG schnell, billig und gut genug.

Wo Vector RAG zusammenbricht

Sobald die Frage mehrere Entitäten in Beziehung setzt, wird es eng. Drei klassische Fail-Modi:

1. Multi-Hop-Fragen

„Welche Kunden von Account-Manager Anna haben in den letzten 12 Monaten Tickets zu Feature X geöffnet?"

Das ist ein Join über Anna → Kunden → Tickets → Feature. In den Quelldokumenten steht das nirgends als zusammenhängender Text. Vector RAG findet höchstens drei lose verwandte Chunks, das LLM halluziniert den Rest.

2. Globale Zusammenfassungen

„Was sind die drei häufigsten Beschwerdethemen über alle 4.000 Support-Tickets?"

Vector RAG holt 10 ähnliche Tickets. Es weiß nichts über die anderen 3.990. Die Antwort ist statistisch wertlos.

3. Reasoning über Quellen hinweg

„Wie hat sich die Strategie von OpenAI zwischen 2023 und 2026 verändert?"

Erfordert Aggregation über viele Dokumente plus eine zeitliche Achse. Vector RAG hat kein Konzept von „Zeit" oder „Subjekt-Entwicklung".

Was GraphRAG anders macht

GraphRAG kippt eine zusätzliche Schicht zwischen Quellen und Retrieval: einen automatisch aus den Dokumenten extrahierten Knowledge Graph.

Dokumente
   ↓
Entity & Relationship Extraction (LLM)
   ↓
Knowledge Graph (Knoten + Kanten + Communities)
   ↓
Community Summaries (vorab generiert)
   ↓
Hybrid Retrieval:
   - Lokale Frage  → Subgraph-Traversal + Vector
   - Globale Frage → Community Summaries
   ↓
LLM-Antwort mit Quellen

Zwei Mechaniken sind entscheidend:

1. Community Detection: Der Graph wird in Cluster verwandter Entitäten zerlegt (Leiden-Algorithmus). Für jeden Cluster wird vorab eine Summary generiert. Globale Fragen treffen direkt diese Summaries statt 4.000 Einzeldokumente.
2. Subgraph-Traversal: Lokale Fragen finden zuerst die relevante Entität, traversieren dann deren Nachbarschaft und holen erst dann die Original-Chunks. Das ist deterministisch statt probabilistisch.

Direkter Vergleich

	Vector RAG	GraphRAG
Setup-Aufwand	niedrig	hoch (Extraction-Pipeline)
Kosten Indexierung	günstig	teuer (LLM-Calls pro Dokument)
Kosten Retrieval	sehr günstig	mittel
Single-Hop-Antworten	exzellent	exzellent
Multi-Hop-Antworten	schlecht	exzellent
Globale Zusammenfassungen	nicht möglich	nativ
Erklärbarkeit	„diese 5 Chunks"	„dieser Pfad durch den Graph"
Aktualisierungen	trivial (Re-embed)	komplex (Graph-Updates)

Mini-Code: GraphRAG mit LlamaIndex

from llama_index.core import KnowledgeGraphIndex, SimpleDirectoryReader
from llama_index.graph_stores.neo4j import Neo4jGraphStore
from llama_index.llms.openai import OpenAI

# 1. Quellen laden
docs = SimpleDirectoryReader("./docs").load_data()

# 2. Graph extrahieren + speichern
graph_store = Neo4jGraphStore(
    username="neo4j", password="...", url="bolt://localhost:7687",
)
index = KnowledgeGraphIndex.from_documents(
    docs,
    graph_store=graph_store,
    llm=OpenAI(model="gpt-4.1"),
    max_triplets_per_chunk=15,
    include_embeddings=True,
)

# 3. Hybrid abfragen
query_engine = index.as_query_engine(
    include_text=True,            # zusätzlich Original-Chunks
    response_mode="tree_summarize",
)
print(query_engine.query(
    "Welche Kunden mit Vertragswert > 100k haben offene Tickets zu Feature X?"
))

Das Skript läuft auf 100 Dokumenten in unter einer Stunde und kostet je nach Modell zwischen 5 und 30 USD an Extraction.

Wann GraphRAG, wann nicht?

GraphRAG lohnt sich, wenn:

• Eure Nutzer:innen stellen regelmäßig Multi-Hop-Fragen mit „und", „über", „pro"
• Ihr braucht globale Sicht auf einen Korpus (Themen, Trends, Cluster)
• Ihr habt Compliance-Anforderungen an die Quelle einer Antwort
• Eure Quelldokumente referenzieren sich gegenseitig (Verträge, Tickets, E-Mails)

Bleibt bei Vector RAG, wenn:

• 90 % eurer Fragen sind „wo steht das?"-Fragen
• Eure Daten sind ein flacher Stapel ähnlicher Artikel (FAQs, Blogposts, Handbücher)
• Ihr habt < 200 Dokumente — der Graph-Overhead lohnt nicht
• Niemand im Team will eine Extraction-Pipeline pflegen

Hybrid ist die ehrliche Antwort

In der Praxis kombinieren ernstzunehmende Setups beides:

• Vector für Verbatim-Lookup und Long-Tail-Fragen
• Graph für strukturierte Multi-Hop-Antworten und globale Sicht

Genau diese Hybrid-Architektur sehen wir in jedem zweiten Enterprise-AI-Projekt, das wir derzeit bauen — und sie ist der Hauptgrund, warum wir Knowledge Graphs als Service anbieten.

Fazit

Vector RAG ist nicht „falsch", es ist nur begrenzt. Wer ein AI-System baut, das mehr als nur Text wiederfindet, kommt um GraphRAG nicht herum. Die gute Nachricht: Dank moderner LLMs ist die Extraction-Pipeline heute machbar — vor zwei Jahren war das noch ein Forschungsthema.

Wer beim Bau einer RAG-Lösung das erste Mal an die Multi-Hop-Wand läuft, sollte nicht den Vector-Store optimieren. Das Problem ist das Datenmodell, nicht die Embeddings.

---

Verwandte Artikel:

• Was ist ein Knowledge Graph? – die Grundlagen, auf denen GraphRAG aufsetzt
• Entity Extraction mit LLMs – wie aus euren Dokumenten der Graph entsteht
• Neo4j vs. Kuzu vs. Memgraph – welche Graph-DB für welches Setup
• KI ist nicht der Engpass, Kontext ist es – warum Datenmodellierung das echte AI-Problem ist