Warum GraphRAG Wissen als Netzwerk statt als Textstapel organisiert

Warum GraphRAG Wissen als Netzwerk statt als Textstapel organisiert

Bitten Sie ein LLM, den gesamten Dokumentenkorpus zusammenzufassen, stoßen Sie schnell an Grenzen. Klassisches Retrieval-Augmented Generation (RAG) findet zwar die Nadel im Heuhaufen, scheitert aber, wenn die Frage das Verbinden von Punkten im gesamten Heuhaufen erfordert. Genau diese Lücke sollte das GraphRAG-Paper von Microsoft schließen.

"RAG fails on global questions directed at an entire text corpus, such as 'What are the main themes in the dataset?', since this is inherently a query-focused summarization (QFS) task, rather than an explicit retrieval task." — Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization (arXiv:2404.16130)

Dieser Artikel erklärt, warum dieses Scheitern auftritt, wie GraphRAG das Problem löst — und vor allem, wann welche Retrieval-Methode (klassisches Vektor-RAG, GraphRAG oder ein Hybridansatz) das richtige Werkzeug ist. Belegt durch überprüfbare Quellen.

Zuerst eine Auffrischung: So funktioniert klassisches RAG

Bevor es um Graphen geht, lohnt sich Präzision bei der Frage, was „klassisches RAG“ unter der Haube leistet — denn jeder Schwachpunkt, der hier zur Sprache kommt, entsteht in einem dieser Schritte. RAG (Retrieval-Augmented Generation) wurde 2020 von Lewis et al. formalisiert: Die Grundidee besteht darin, das LLM mit abgerufenem Kontext zu erweitern, statt sich allein auf sein parametrisches Gedächtnis zu verlassen. Ein typischer RAG-Workflow umfasst sechs Schritte:

1. Chunking. Der Korpus wird in Text-Chunks zerlegt. Die Chunk-Größe ist eine echte Designentscheidung, kein Detail: In der eigenen Ablation von GraphRAG (Abschnitt 3.1.1) extrahierte GPT-4 fast doppelt so viele Entitätsreferenzen aus 600-Token-Chunks wie aus 2400-Token-Chunks im HotPotQA-Datensatz — größere Chunks verschlechtern die Informationserinnerung am Anfang des Chunks. (Quelle: arXiv:2404.16130)
2. Embedding. Jeder Chunk wird mit einem Embedding-Modell in einen hochdimensionalen Vektor umgewandelt. Zwei gängige Familien:
3. Vektordatenbank. Die Chunk-Embeddings werden in einem Vektorspeicher abgelegt (Pinecone, Weaviate, Qdrant, pgvector, FAISS etc.). Zur Abfragezeit wird die Nutzerfrage mit demselben Modell eingebettet, und der Speicher liefert die K nächsten Nachbarn nach Kosinus-Ähnlichkeit zurück.
4. Retriever. Der Vektorspeicher gibt die Top-K ähnlichsten Chunks zurück. Genau hier „verliert“ das System, wenn eine Frage Entitäten aus mehreren Chunks verbinden muss.
5. Re-Ranking (optional). Ein zweites, rechenintensiveres Modell sortiert die Top-K-Treffer neu, um die relevantesten vor dem LLM zu platzieren.
6. Generator. Die abgerufenen Chunks werden in das Kontextfenster des LLM eingefügt, das die Antwort generiert.

• OpenAI text-embedding-3-small und text-embedding-3-large: veröffentlicht im Jänner 2024, sind dies die aktuellen Embedding-Modelle von OpenAI. Standardmäßig text-embedding-3-small erzeugt 1536-dimensionale Vektoren und text-embedding-3-large erzeugt 3072-dimensionale Vektoren; ein dimensions Parameter ermöglicht es, sie (matrjoschka-artig) mit minimalem Qualitätsverlust zu verkleinern. Auf dem MTEB-Benchmark text-embedding-3-large erreicht 64,6 % gegenüber text-embedding-3-smallmit 62,3 % und dem älteren ada-002mit 61,0 %. (Quelle: platform.openai.com/docs/guides/embeddings)
• Open-Source/lokal: BGE (BAAI) — bge-small-en-v1.5 ist 384-dim, bge-base-en-v1.5 768-dim, bge-large-en-v1.5 1024-dim, alle mit einem 512-Token-Kontextfenster (MTEB-Werte 62,17 / 63,55 / 64,23). Nomic Embed (nomic-embed-text-v1.5) ist ein vollständig offenes, Apache-lizenziertes Modell mit einer 768-dim-Standardausgabe und einem 8192-Token-Kontextfenster; es unterstützt zudem Matrjoschka-Verkleinerung bis auf 64 Dimensionen. sentence-transformers (Hugging Face / UKPLab) ist das Framework, das die meisten Teams nutzen, um solche Modelle lokal auszuführen.
• Das praktische Fazit: Embedding-Modelle sind entscheidend, und die Wahl zwischen einer gehosteten API (OpenAI) und einem lokalen Modell (BGE, Nomic) wird von Kosten, Datenschutz und Latenz bestimmt — nicht davon, ob man GraphRAG oder Vektor-RAG einsetzt. (Quellen: HuggingFace Model Cards für BAAI/bge-small-en-v1.5 und nomic-ai/nomic-embed-text-v1.5; huggingface/sentence-transformers Repo.)

Die entscheidende Einschränkung: Schritt 4 ist eine Best-First-Ähnlichkeitssuche. Sie liefert Chunks, die der Frage ähneln. Sie hat keine Ahnung, welche Chunks miteinander in Beziehung stehen. Wenn die Antwort im Schnittpunkt vieler Dokumente liegt, ist kein einzelner Chunk ein guter „nächster Nachbar“, sodass das Top-k-Retrieval eine Handvoll lose zusammenhängender Fragmente zurückgibt — und das LLM muss „die Punkte verbinden“, die ihm nie übergeben wurden.

Genau das ist der eigentliche Grund, warum die GraphRAG-Autor:innen dieses einleitende Zitat verfasst haben. Vektor-RAG ist hervorragend für das Abrufen expliziter Fakten, und es ist genau schlecht in dem, was das Paper als global sensemaking bezeichnet — „welches sind die Hauptthemen in diesem 1-Million-Token-Datensatz?“

Die Lösung: einen Graphen erstellen, dann den Graphen zusammenfassen

Die zentrale Erkenntnis von GraphRAG besteht darin, das Korpus zunächst in einen Wissensgraphen umzuindexieren und dann den Graphen selbst als Retrieval-Substrat zu nutzen. Die Pipeline des Papers (Abbildung 1) besteht aus zwei Phasen — Indexing-Zeit und Query-Zeit:

Indexierung (einmalig, offline):

1. Text-Chunks → Entitäten & Beziehungen. Das LLM wird aufgefordert, wichtige Entitäten und die Beziehungen zwischen ihnen aus jedem Chunk zu extrahieren, inklusive kurzer Beschreibungen. Entscheidend ist, dass der Graph-Index des Papers Knoten (Entitäten), Kanten (Beziehungen) und Kovariaten (Aussagen)umfasst.
2. Entitäten & Beziehungen → Wissensgraph. Diese Tripel werden zu einem Graphen zusammengeführt. Hier entstehen die (Florian)-[:OWNS]->(NeuralNine)-style-Tripel: ein Subjekt, ein Prädikat, ein Objekt.
3. Wissensgraph → Graph-Communities. Der Graph wird mittels Community Detection — konkret dem Leiden-Algorithmus (Traag et al., 2019) — partitioniert, der die inhärente Modularität des Graphen nutzt, um Gruppen eng verwandter Knoten zu finden. Dieser Schritt macht die „thematische“ Struktur explizit: verwandte Entitäten werden in einer Community gruppiert.
4. Graph-Communities → Community-Zusammenfassungen. Jede Community wird vom LLM zusammengefasst, rekursiv bottom-up: Zusammenfassungen auf höheren Ebenen der Community-Hierarchie integrieren diejenigen niedrigerer Ebenen. Das Ergebnis ist ein Satz von Community-Zusammenfassungen, die „globale Beschreibungen und Erkenntnisse über das Korpus“ liefern.

Abfragezeit (Map-Reduce):

1. Community-Zusammenfassungen → Community-Antworten → globale Antwort. Das Paper beschreibt dies als Map-Reduce-Verarbeitung: Im Map-Schritt generiert jede Community-Zusammenfassung unabhängig und parallel eine Teilantwort auf die Abfrage; im Reduce-Schritt werden alle Teilantworten zur globalen Endantwort kombiniert und zusammengefasst. Die lokale Suche hingegen wirkt direkt auf für die Abfrage relevante Entitäten und Beziehungen.

(All dies ist direkt dem Paper entnommen, arXiv:2404.16130, Abschnitte 3.1.1–3.1.6.)

„Vollständigkeit und Vielfalt“ — die eigentliche Evaluierung

Das Paper evaluiert GraphRAG im Vergleich zu einem konventionellen RAG-Baseline (von ihnen als „SS“ / „source-and-summarize“ bezeichnet) sowie weiteren Konfigurationen anhand globaler Sinnstiftungsfragen zu Datensätzen im 1-Million-Token-Bereich. Die zentralen Metriken sind drei, jeweils bewertet von einem LLM:

• Vollständigkeit — wie viel der relevanten Informationen deckt die Antwort ab?
• Vielfalt — erfasst sie das gesamte Spektrum an Perspektiven/Themen, nicht nur einen Aspekt?
• Empowerment — unterstützt sie die Leserin dabei, informierte Entscheidungen zu treffen, mit Begründungen und Quellen, ohne irreführende oder fehlerhafte Annahmen?

Das zentrale Ergebnis: GraphRAG führt zu deutlichen Verbesserungen gegenüber einer konventionellen RAG-Baseline sowohl bei der Vollständigkeit als auch bei der Vielfalt. (Die Tabelle des Papers: GraphRAG schlägt die Baseline mit großen, statistisch signifikanten Erfolgsquoten — z. B. >70–83 % bei Vollständigkeit über alle Hierarchieebenen, p < 0,001 — gegenüber den einstelligen bis mittleren 20-%-Werten der Baseline SSRAG.)

Es gibt auch ein erfreulich kontraintuitives Ergebnis, das man sich merken sollte: Die Autor:innen testeten Kontextfenster von 8k/16k/32k/64k für die Baseline und stellten fest, dass das kleinste Fenster (8k) universell am besten abschnitt bei der Vollständigkeit (58,1 % durchschnittliche Erfolgsquote) — konsistent mit dem Problem „lost in the middle“, bei dem längere Kontexte das Signal verwässern. (Quelle: arXiv:2404.16130, Appendix C.)

Praktische Anmerkung zu den Kosten: Die Indexierung mit GraphRAG ist tatsächlich kostspielig — ein LLM wird für jedes Chunk aufgerufen, um Entitäten zu extrahieren, dann erneut, um jede Community zusammenzufassen, und nochmals pro Community zur Abfragezeit. Microsofts eigenes Repository warnt: „GraphRAG indexing can be an expensive operation… and start small.“ Diese Kosten sind der Hauptgrund, warum Teams zögern, es einzusetzen — und der Grund, warum die folgenden Alternativen existieren.

Praktische Erkenntnisse: Welche Retrieval-Methode gewinnt wann

Hier die ehrliche, entscheidungsreife Zusammenfassung. Die „beste“ Methode hängt von der Art der Frage ab, die Sie tatsächlich beantworten müssen:

• Vektor-RAG gewinnt bei Ähnlichkeitssuche und expliziter Faktenabfrage. „Finden Sie alle Passagen, die X erwähnen“, „Fassen Sie das Dokument zusammen, das diesem am ähnlichsten ist“, „Was sagt die Spezifikation zu Parameter Y“ — Single-Hop-Fragen mit Term-Ähnlichkeit. Es ist günstig, schnell und einfach einzurichten (Embedding → Speicherung → Abfrage). Benchmarks wie HotPotQA, MultiHop-RAG und MT-Bench sind genau auf diese Art von Vektor-RAG- bzw. expliziter Faktenabfrage-Leistung ausgerichtet (das Paper sagt es direkt). Wenn der Großteil Ihres Workloads „die richtige Passage finden“ lautet, beginnen Sie hier.

• GraphRAG gewinnt bei Multi-Hop-Fragen und korpusweiter „Sinnstiftung“ über den gesamten Korpus. „Welche Hauptthemen ziehen sich durch diesen gesamten Korpus?“, „Verfolgen Sie das Beziehungsnetzwerk zwischen diesen Entitäten.“, „Vergleichen Sie, wie sich Thema A zu Thema B und C über alle Dokumente hinweg verhält.“ Das sind globale Fragen, bei denen kein einzelnes Chunk die Antwort liefert. Der 1-Million-Token-„Global-Sensemaking“-Bereich des Papers ist genau der Kontext, in dem die Community-Zusammenfassungen und Map-Reduce von GraphRAG die RAG-Baseline bei Vollständigkeit und Vielfalt übertreffen. Die Kosten sind real, aber ebenso die Antwortqualität bei echten korpusweiten Fragen.

• Hybride Suche bzw. Graph-Retrieval gewinnt, wenn Sie bereits einen Wissensgraphen besitzen. Wenn Ihre Daten bereits als Graph strukturiert sind (ein Produktkatalog, ein Organigramm, eine Ontologie), ist das praktischste Muster Text2Cypher: Lassen Sie das LLM natürliche Sprache in Cypher, die Graph-Abfragesprache von Neo4j, übersetzen, führen Sie sie gegen die Datenbank aus und geben die Ergebnisse an das LLM für die finale Antwort zurück. Im offiziellen Neo4j GraphRAG Python package (neo4j-graphrag), wird dies als Text2CypherRetriever: „This retriever first asks an LLM to generate a Cypher query to fetch the exact information required to answer the question from the database. Then this query is executed and the resulting records are added to the context for the LLM to write the answer.“ beschrieben. Dasselbe Paket liefert auch VectorRetriever, VectorCypherRetriever, und HybridCypherRetriever, sodass Sie Ähnlichkeitssuche mit Graph-Traversal kombinieren können. (Quelle: neo4j/neo4j-graphrag-python Repo-Dokumentation.)

• LightRAG (arXiv:2410.05779) ist eine pragmatische Alternative zu vollem Microsoft GraphRAG. Es integriert ebenfalls Graph-Strukturen in die Textindizierung und das Retrieval, setzt aber auf ein dual-level retrieval system , um sowohl Low-Level- (Entitäten) als auch High-Level-Wissen (thematisch)zu erfassen, und — das Verkaufsargument — es verbindet Graph-Strukturen mit Vektor-Repräsentationen , um verwandte Entitäten und Beziehungen effizient abzurufen und dabei die Kontextrelevanz zu wahren — bei „signifikant verbesserten Antwortzeiten“. Wer GraphRAGs Graph-Denken schätzt, aber die Indizierung als zu aufwendig empfindet, findet in LightRAG einen starken Mittelweg.

• LazyGraphRAG (Microsoft Research, November 2024) geht das Kostenproblem direkt an. Seine Prämisse ist radikal: keine vorherige Zusammenfassung der Quelldaten, um die vorab anfallenden Indizierungskosten zu vermeiden, die für manche Use Cases prohibitiv sein können. Es „vereint die Vorteile von Vector RAG und Graph RAG und überwindet deren jeweilige Grenzen“, indem es auf deferred LLM use setzt — es erledigt so viel wie möglich mit Vector-Style-Retrieval, bevor es einen LLM-Aufruf tätigt. Die Autor:innen berichten, dass LazyGraphRAGs Indizierungskosten identisch mit denen von Vector RAG und 0,1 % der von vollem GraphRAG sind , und dass es bei etwa 4 % der Kosten für GraphRAG-Global-Suchanfragen konkurrierende Methoden sowohl bei lokalen als auch globalen Abfragetypen übertreffen kann. (Quelle: Microsoft-Research-Blog, „LazyGraphRAG: Setting a new standard for quality and cost.“), und dass es mit ~4 % der Kosten einer GraphRAG-Global-Suche bei lokalen und globalen Abfragetypen konkurrierende Methoden übertreffen kann. (Quelle: Microsoft Research Blog, „LazyGraphRAG: Setting a new standard for quality and cost.“)

Das Fazit

GraphRAG ersetzt Vector RAG nicht — es ergänzt es. Vector RAG ist Ihr präzises Skalpell für Fakten- und Ähnlichkeitsfragen; GraphRAG die Weitwinkeloptik, um ganze Korpora zu verstehen; LightRAG, LazyGraphRAG und Text2Cypher sind die pragmatischen Werkzeuge, wenn Sie graphenähnliche Strukturen ohne die Indizierungslast von GraphRAG nutzen möchten. Die richtige Entscheidung für Ingenieur:innen ist nicht, sich auf ein einziges Paradigma festzulegen, sondern die Retrieval-Strategie an die Allgemeinheit der Frage und die Struktur der Daten anzupassen.

Quellen

• Microsoft-GraphRAG-Paper (arXiv): „From Local to Global: A Graph RAG Approach to Query-Focused Summarization“ — Edge, Trinh, Cheng, Bradley, Chao, Mody, Truitt, Metropolitansky, Ness, Larson — https://arxiv.org/abs/2404.16130 (Volltext: https://arxiv.org/html/2404.16130v2)
• OpenAI-Embedding-Modelle & Dimensionen — text-embedding-3-small (1536-dim), text-embedding-3-large (3072-dim), MTEB 62,3 %/64,6 %/61,0 % — https://platform.openai.com/docs/guides/embeddings
• BAAI BGE small/base/large v1.5 (Dimensionen + MTEB) — https://huggingface.co/BAAI/bge-small-en-v1.5
• Nomic Embed v1.5 (768-dim, 8192 Kontextfenster, Matryoshka, Apache-2.0) — https://huggingface.co/nomic-ai/nomic-embed-text-v1.5
• sentence-transformers Framework — https://github.com/huggingface/sentence-transformers
• LightRAG (arXiv) — https://arxiv.org/abs/2410.05779
• LazyGraphRAG-Blog (Microsoft Research) — https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
• Neo4j-GraphRAG-Python-Paket (neo4j-graphrag, inkl. Text2CypherRetriever) — https://github.com/neo4j/neo4j-graphrag-python
• Microsoft-GraphRAG-Repository (Hinweis zu Indexierungskosten, Statushinweis) — https://github.com/microsoft/graphrag