GraphRAG oder Vektor-RAG: die Retrieval-Strategie nach der Frage wählen
Vektorsuche findet ähnlichen Text, doch Multi-Hop-Fragen brauchen Beziehungen. Wann GraphRAG, hybride oder Schlüsselwortsuche passt und was ein Graph im Betrieb kostet.
Die erste Version einer RAG-Anwendung wirkt meist angenehm schlicht. Dokument verarbeiten, Text in Chunks zerlegen, jeden Chunk einbetten und die Vektoren in einer Datenbank ablegen. Kommt eine Frage, holt man die nächstgelegenen Chunks und gibt sie ans LLM weiter. Der ganze Ablauf in einem Bild:
Documents
│
▼
Text Extraction
│
▼
Chunking
│
▼
Embeddings
│
▼
Vector Database
│
│
User Query ─────────┘
│
▼
Similarity Search
│
▼
Context
│
▼
LLM
│
▼
Answer
Für einen großen Teil der Fragen funktioniert das erstaunlich gut. In der Dokumentenarbeit von Unternehmen zeigt sich aber schnell eine zweite Art von Fragen, bei der semantisch ähnlicher Text allein nicht reicht. Die Schwierigkeit lautet dann nicht mehr „Findet das System relevanten Text?“, sondern „Findet es die relevanten Informationen und versteht es auch, wie die Teile zusammenhängen?“ Um genau diese Lücke geht es im Folgenden.
Eine Frage über mehrere Dokumente hinweg
Nehmen wir eine vereinfachte Unternehmenswissensbasis. Eine Datei beschreibt einen technischen Standard:
Document A
↓
Engineering Standard
↓
Requirement R1
Eine andere enthält eine Projektspezifikation:
Document B
↓
Project Specification
↓
Component C1Document C
↓
Validation Rule
↓
Rule V1
Jetzt fragt jemand, welche Anforderung für Komponente C1 gilt, welcher Standard diese Anforderung festlegt und welche Prüfregel anzuwenden ist. Kein einzelnes Dokument enthält die Antwort. Eine korrekte Antwort setzt voraus, mehrere Fakten zu verknüpfen:
Component C1
│
│ governed by
▼
Requirement R1
│
│ defined by
▼
Engineering Standard
│
│ validated by
▼
Validation Rule V1
Eine Vektordatenbank weiß nicht, dass diese Struktur existiert. Ihre Aufgabe ist, Inhalte zu finden, die der Anfrage semantisch nahe sind, und das ist sehr wertvoll. Semantische Ähnlichkeit und das Schlussfolgern über Beziehungen sind nur eben verschiedene Dinge.
Wo Vektorsuche das richtige Werkzeug ist
Bevor Graphen ins Spiel kommen, sollte man der Vektorsuche Gerechtigkeit widerfahren lassen. Sie ist einer der nützlichsten Bausteine für RAG, und der typische Ablauf sieht so aus:
User Query
│
▼
Query Embedding
│
▼
Vector Similarity Search
│
▼
Top-K Chunks
│
▼
Context Construction
│
▼
LLM
Fragt man „Welche Anforderungen gelten für die Dicke der Fahrbahndecke?“ und die Wissensbasis hat genau dazu einen Abschnitt, findet die semantische Suche ihn in der Regel. Die Frage ist lokal, ein weites Netz von Verbindungen muss niemand verstehen. Vektorsuche passt am besten, wenn:
- die Antwort an einer Stelle steht
- semantische Nähe ein brauchbarer Ersatz für Relevanz ist
- Dokumente weitgehend einzeln behandelt werden können
- ein paar Passagen für die Antwort reichen
- eine einfache Suche Priorität hat
„Ist Vektor-RAG gut oder schlecht?“ ist also die falsche Frage. Hilfreicher ist die Frage, welches Retrieval-Problem tatsächlich vorliegt, denn davon hängt ab, ob reine Ähnlichkeitssuche genügt oder etwas Reichhaltigeres nötig ist.
Wissen ist meist vernetzt
Unternehmensmaterial steht selten für sich allein. Ein Standard legt Anforderungen fest, und jede Anforderung verweist auf weitere Dinge:
Standard
│
├── defines → Requirement
│
├── references → Section
│
└── supersedes → Previous Standard
Requirement
│
├── applies_to → Component
├── depends_on → Condition
└── validated_by → RuleComponent
│
├── belongs_to → Project
└── uses → Material
Eine Frage, die mehrere dieser Verknüpfungen berührt, erfordert Multi-Hop-Retrieval. Das System muss womöglich:
- die Komponente finden
- herausfinden, welche Anforderung gilt
- den maßgeblichen Standard bestimmen
- zugehörige Bedingungen sammeln
- die Prüfregel finden
- alle Belege zusammenführen
Das ist ein anderes Retrieval-Problem, als den nächstgelegenen Absatz zu holen.
Was ein Wissensgraph hinzufügt
Ein Wissensgraph bildet Entitäten und ihre Beziehungen explizit ab. Die übliche Pipeline behandelt Wissen so:
Document → Chunk → Embedding
Ein Graph stellt eine zweite Darstellung daneben:
Entity ──relationship──> Entity
So sieht das in der Praxis aus:
Standard
│
defines
│
▼
Requirement
│ │
applies_to validated_by
│ │
▼ ▼
Component Rule
│
belongs_to
│
▼
Project
Der Graph ersetzt die Dokumente nicht. Sie bleiben das Ausgangsmaterial, und der Graph wird zu einer strukturierten Schicht, die die Entitäten darin und ihre Beziehungen beschreibt.
GraphRAG in einem Absatz
GraphRAG verbindet Retrieval-Augmented Generation mit graphbasierter Wissensdarstellung und graphbasiertem Retrieval. Statt sich nur auf semantische Ähnlichkeit zu stützen, folgt das System den Beziehungen zwischen Entitäten und Konzepten, um relevante Informationen zu finden. Konzeptionell:
User Query
│
▼
Query Understanding
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence / Context
│
▼
LLM
│
▼
Answer
Die Implementierungen unterscheiden sich stark. Gleich bleibt, dass das Retrieval Zugriff auf Beziehungen hat und nicht nur auf Ähnlichkeit.
Zwei verschiedene Fragen
Am klarsten trennt man beide Ansätze danach, was sie jeweils fragen. Vektorsuche fragt grob gesagt, welcher Inhalt der Anfrage am ähnlichsten ist. Graph-Retrieval kann fragen, welche Entitäten mit den Konzepten der Anfrage verbunden sind und was man lernt, wenn man diesen Verbindungen folgt.
Beide können im Team arbeiten:
Query
│
┌────────┴────────┐
▼ ▼
Semantic Structural
similarity relationships
│ │
▼ ▼
Chunks Entities
│ │
└────────┬────────┘
▼
Evidence
Deshalb ist GraphRAG nicht einfach eine bessere Vektordatenbank. Es ist eine andere Retrieval-Strategie für eine andere Klasse von Problemen.
Wann sich Beziehungen lohnen
Explizite Beziehungen zahlen sich vor allem in einigen Situationen aus.
Mehrstufige Fragen. Eine Frage wie „Welche Vorschrift gilt für dieses Teil, und welche zusätzlichen Prüfregeln gehören dazu?“ lässt sich nur beantworten, indem man mehrere Verknüpfungen nacheinander abläuft:
Component
↓
Requirement
↓
Regulation
↓
Validation Rule
Beziehungsreiche Domänen. Manche Bereiche stecken voller Verbindungen, etwa Vorschriften, technische Standards, Finanzentitäten, wissenschaftliches Wissen, Produktkataloge, Organisationswissen und Abhängigkeitsnetze. Dort tragen die Beziehungen selbst Bedeutung.
Belege über mehrere Dateien verteilt. Ein Dokument definiert eine Anforderung, ein anderes nennt eine Ausnahme, ein drittes erklärt die Prüfung. Das Schwierige ist, sie korrekt zusammenzusetzen.
Fragen zur ganzen Entität. „Welche Anforderungen hängen insgesamt an dieser Entität?“ passt ganz natürlich zu einem beziehungsbewussten Retrieval.
Was ein Graph kostet
Es ist verlockend, von Wissensgraphen zu hören und zu folgern, Vektor-RAG sei veraltet und GraphRAG besser. Technisch ist das der falsche Schluss. Graphen bringen zusätzliche Komplexität mit, also mehr Stufen, die gebaut und betrieben werden müssen:
Document Processing
↓
Entity Extraction
↓
Relationship Extraction
↓
Entity Resolution
↓
Graph Construction
↓
Graph Storage
↓
Graph Retrieval
↓
Context Construction
Jede Stufe ist eine neue Fehlerquelle, und Fehler verstärken sich auf dem Weg durch die Pipeline. Was, wenn die Entitätsextraktion falsch liegt? Was, wenn zwei verschiedene Entitäten denselben Namen tragen? Was, wenn eine Beziehung falsch abgeleitet wird, der Graph unvollständig bleibt oder seine Pflege teuer wird, weil sich die Dokumente ändern? Das sind Engineering-Probleme, nicht nur KI-Probleme.
Der Graph muss gebaut werden
Ein Graph entsteht nicht von selbst. Sein Aufbau gehört zur Arbeit, und eine vereinfachte Pipeline sieht so aus:
Documents
│
▼
Document Processing
│
▼
Text / Structure
│
▼
Entity Extraction
│
▼
Relationship Extraction
│
▼
Entity Resolution
│
▼
Knowledge Graph
Angenommen, ein Satz in einer Quelldatei besagt, dass R-102 die Regel für das Brückenbauteil B-17 ist, sobald C-4 zutrifft. Als Struktur könnte das so aussehen:
(R-102)
│
applies_to
↓
(B-17)
(R-102)
│
requires_condition
↓
(C-4)
Das Retrieval kann diese Verknüpfungen dann nutzen. Erzeugt die Extraktion aber fälschlich
R-102 → applies_to → B-71
trägt der Graph falsche Informationen weiter. Deshalb wird die Qualität der Wissensextraktion zu einem Teil der Retrieval-Qualität.
Vektoren und Graph gemeinsam
Echte Systeme müssen sich oft gar nicht entscheiden. Das Muster kann Vektoren und Graph kombinieren:
Query
│
▼
Query Analysis
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence Fusion
│
▼
Context Building
│
▼
LLM
Die Vektorsuche findet semantisch relevante Passagen, das Graph-Retrieval liefert den Beziehungskontext. Zusammen ergeben sie reichhaltigere Belege, was vor allem hilft, wenn eine Frage „finde die relevanten Informationen“ mit „verstehe, wie sie zusammenhängen“ verbindet.
Schlüsselwort, Vektor, Hybrid und Graph
Der Weg von der Schlüsselwortsuche über die Vektorsuche bis zu GraphRAG bedeutet nicht, dass jeder Schritt den vorherigen ablöst. Jede Methode bedient einen anderen Bedarf:
Keyword Search
│
└── Exact terms / identifiers
Vector Search
│
└── Semantic similarityHybrid Search
│
└── Exact + semantic relevanceReranking
│
└── Improve ordering of candidatesGraph Retrieval
│
└── Relationship-aware retrieval
Ein Produktivsystem kann mehrere davon kombinieren. Die technische Aufgabe ist zu entscheiden, welche Signale für das konkrete Problem zählen.
Bei der Antwort anfangen
Statt mit „Sollten wir GraphRAG einsetzen?“ zu beginnen, fängt man besser damit an, was für eine korrekte Antwort gefunden werden muss.
Braucht es eine einzige klar relevante Passage, kann das hier genügen:
Query
↓
Vector Search
↓
Passage
Kommt es auf exakte Kennungen an, hilft vielleicht das:
Query
↓
Keyword / Metadata Search
Geht es um semantisches Verständnis, ist das nützlich:
Query
↓
Vector Search
Werden mehrere Retrieval-Signale gebraucht, passt das besser:
Query
↓
Hybrid Search
↓
Reranking
Müssen Beziehungen durchlaufen werden, wird Graph-Retrieval interessant:
Query
↓
Entity Identification
↓
Graph Retrieval
↓
Related Evidence
Und wenn sich die Retrieval-Strategie selbst von Frage zu Frage ändern muss, kann ein agentischer Workflow gerechtfertigt sein:
Query
↓
Decision / Planning
↓
Choose retrieval strategy
↓
Retrieve
↓
Evaluate evidence
↓
Retrieve again if necessary
↓
Answer
Mit einem Graphen wird es Systems Engineering
Ohne Graph ist das System schlicht:
Application
↓
Vector Database
↓
LLM
Mit Graph wird daraus eher so etwas:
Application
│
▼
Query Understanding
│
┌─────────┴─────────┐
▼ ▼
Vector Store Graph Store
│ │
└─────────┬─────────┘
▼
Retrieval Layer
│
▼
Context Builder
│
▼
LLM
Auf das Team kommt eine neue Liste von Themen zu: wie der Graph gebaut wird, wie er mit den Dokumenten synchron bleibt, wie er indiziert wird, Abfragelatenz, Konsistenz, wie gut der Graph wirklich ist, das Auflösen doppelter Entitäten, wo er gespeichert wird, wie man ihn überwacht und wie man ihn bewertet. An diesem Punkt ist GraphRAG kein Framework-Feature mehr, sondern ein Problem des Systems Engineering.
RAG neu denken
Die Arbeit an Dokumenten verändert den Blick auf RAG. Anfangs scheint es nur darum zu gehen, die richtigen Chunks zu finden und ans LLM zu geben. Weiter gefasst geht es darum, eine Wissensdarstellung zu entwerfen, mit der das System die Belege holen kann, die es für die Antwort braucht. Manchmal sind das Chunks und Embeddings. Manchmal helfen Metadaten, hybrides Retrieval oder Beziehungen, die wichtig genug sind, um einen Graphen zu rechtfertigen. Und manchmal muss das System dynamisch entscheiden, wie es sucht. Die Architektur sollte dem Informationsbedarf des Problems folgen, nicht der Beliebtheit einer Technologie.
Ein einfaches Entscheidungsmodell
Auf ein mentales Modell reduziert, sieht die Wahl so aus:
What does the question require?
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Exact terms Semantic meaning Relationships
│ │ │
▼ ▼ ▼
Keyword/ Vector Graph
Metadata Search Retrieval
│ │ │
└────────────────┼────────────────┘
▼
Hybrid System
│
▼
Reranking
│
▼
Context Building
│
▼
LLM
Ziel ist nicht die raffinierteste Architektur, sondern die einfachste, die das Retrieval-Problem zuverlässig löst.
Vektorsuche ist mächtig, aber Ähnlichkeit ist nicht dasselbe wie das Verständnis von Beziehungen. Werden Fragen mehrstufig, dokumentübergreifend, entitätszentriert oder beziehungslastig, fügt explizit modelliertes Wissen einen weiteren starken Retrieval-Mechanismus hinzu. GraphRAG ist nicht deshalb spannend, weil es RAG schlägt, sondern weil unterschiedliche Fragen unterschiedliche Retrieval-Strategien verlangen. Erst die Frage und die Struktur des Wissens verstehen, dann die Technologie wählen.