Lokales GraphRAG: RAG mithilfe eines Wissensgraphen (Leitfaden für Fortgeschrittene)

#Warum GraphRAG?

Stellen Sie sich den Dokumentenbestand einer Anwaltskanzlei vor: 200 Verträge, 500 E-Mails, 80 Entscheidungen. Sie stellen die Frage: „Welche wesentlichen rechtlichen Risiken wurden in unseren Kundenverträgen der letzten drei Jahre angesprochen, und bei welchen wiederkehrenden Kunden?“ Ein klassisches vektorbasiertes RAG-System sucht 5 oder 10 „relevante“ Chunks, übergibt sie dem LLM, und dieses antwortet … mit einem unvollständigen Überblick. Es übersieht dokumentenübergreifende Muster.

GraphRAG gibt nicht nur unverarbeitete Textpassagen zurück, sondern zieht Schlussfolgerungen anhand einer Struktur: Wer erwähnt was, welche Entitäten tauchen wiederholt auf und welche Beziehungen verbinden sie? Bei solchen zusammenfassenden („globalen“) Fragen zu einem Korpus ist der graphbasierte Ansatz dem vektorbasierten überlegen — genau das zeigte die ursprüngliche Veröffentlichung von Microsoft Research aus dem Jahr 2024.

#GraphRAG vs. vektorbasiertes RAG: der tatsächliche Unterschied

Beide Ansätze verfolgen dasselbe Ziel: externen Kontext in den Prompt des LLM einzubinden, um Halluzinationen zu begrenzen. Sie rufen jedoch nicht dieselben Informationen ab.

Vektorbasiertes RAG

Teilt den Korpus in Chunks auf, berechnet ein Embedding pro Chunk und speichert die Embeddings in einer Vektordatenbank (ChromaDB, Qdrant, FAISS). Bei einer Anfrage werden die k ähnlichsten Chunks anhand der Kosinusähnlichkeit abgerufen.

GraphRAG

GraphRAG fordert ein LLM auf, Entitäten und Beziehungen aus jedem Chunk zu extrahieren, erstellt einen Graphen, gruppiert die Entitäten in Communities und fasst jede Community zusammen. Bei einer Anfrage durchläuft es den Graphen oder aggregiert Zusammenfassungen von Communities.

Stärken des vektorbasierten Ansatzes

Schnell zu indexieren (einige Minuten für 10 MB Text), günstig, hervorragend für gezielte Fragen („Welche Kündigungsklausel steht im Vertrag Acme?“).

Stärken von GraphRAG

Hervorragend für übergreifende Fragen („Welche Themen kehren immer wieder?“, „Welche Entitäten haben die meisten Verbindungen?“), detaillierte Nachvollziehbarkeit anhand der Kanten, native Multi-Hop-Unterstützung.

Schwäche der Vektorsuche

Verliert die Verknüpfungen zwischen Dokumenten. Eine Frage, die das Zusammenführen von 3 semantisch weit entfernten Dokumenten erfordert, liefert nicht die richtigen Chunks.

Schwäche bei GraphRAG

Aufwendige Indexierung: Jeder Chunk muss von einem LLM verarbeitet werden. Bei einem Korpus von 10 MB müssen Sie mit mehreren Stunden und hohem VRAM-Bedarf rechnen, während der vektorbasierte Ansatz in 5 Minuten fertig ist.

#Wie es intern funktioniert

Eine vollständige GraphRAG-Pipeline durchläuft 5 Schritte. Alle verwenden das LLM, mit Ausnahme des Clusterings.

1. 01
   Chunking

   Das Korpus wird wie bei einem klassischen RAG in Abschnitte von 500 bis 1500 Tokens aufgeteilt. Die Größe hat einen direkten Einfluss auf die Extraktionsqualität: Sind die Abschnitte zu kurz, übersieht das LLM Beziehungen; sind sie zu lang, vergisst es manche davon.
2. 02
   Extraktion von Entitäten und Beziehungen

   Jeder Chunk wird an ein LLM mit einem strukturierten Prompt wie folgt übergeben: „Extrahiere alle Entitäten (Person, Organisation, Ort, Konzept) sowie die Beziehungen zwischen ihnen. Format: JSON.“ Dies ist der kostspielige Schritt – ein LLM-Aufruf pro Chunk.
3. 03
   Aufbau des Graphen

   Die extrahierten Entitäten werden zu Knoten, die Beziehungen zu Kanten. Identische Entitäten, die in mehreren Chunks vorkommen, werden zusammengeführt (Entitätsauflösung, häufig mithilfe von Embeddings oder einer Normalisierungsregel).
4. 04
   Community-Detektion

   Ein Clustering-Algorithmus (Leiden bei Microsoft, ein einfacherer Algorithmus bei nano-graphrag) gruppiert stark miteinander verbundene Knoten zu Communities. Diese Communities sind der Schlüssel zum „globalen“ Schlussfolgern.
5. 05
   Zusammenfassung der Communities

   Das LLM erstellt für jede Community eine textuelle Zusammenfassung anhand der darin enthaltenen Entitäten und Beziehungen. Diese Zusammenfassungen dienen bei globalen Fragen als Retrieval-Einheiten.

Bei der Abfrage unterscheidet GraphRAG zwei Modi: lokal (Suche nach einer bestimmten Entität und ihrer Nachbarschaft) und global (Zusammenführung von Zusammenfassungen der Graph-Communitys). Das LLM kombiniert anschließend den abgerufenen Kontext mit der Frage, um die endgültige Antwort zu erzeugen.

#Verfügbare Tools für einen lokalen Einsatz

Microsoft GraphRAG

Die Referenzimplementierung (github.com/microsoft/graphrag). Vollständig und sorgfältig umgesetzt, aber schwergewichtig: Ursprünglich für Azure OpenAI konzipiert, erfordert die Anpassung an Ollama Geduld. Die Indexierung ist mit sehr hohen Tokenkosten verbunden.

nano-graphrag

Minimale Implementierung (~1000 Zeilen) mit nativer Unterstützung von Ollama (github.com/gusye1234/nano-graphrag). Dies ist das, was wir hier verwenden: 10-mal weniger Code zu verstehen, aber die gleiche Idee.

LightRAG

Neuere Variante, optimiert für die Abfragelatenz. Kompatibel mit Ollama. Einfacher als Microsoft GraphRAG, stärker strukturiert als nano-graphrag.

LlamaIndex KnowledgeGraphIndex

Wenn Sie bereits LlamaIndex verwenden, ist die Integration sofort möglich, aber der Ansatz ist rudimentärer (keine Communities).

#Voraussetzungen

Ollama installiert und funktionsfähig

Wenn dies nicht der Fall ist, folgen Sie zunächst unserem Installationsleitfaden für Ollama.

Ein leistungsfähiges Reasoning-LLM (14–24B)

Die Entitätsextraktion erfordert viel Rechenleistung. gpt-oss 20B, Mistral Small 24B oder Qwen 3.5 9B (untere Grenze) funktionieren gut. Unter 8B ist das erzeugte JSON häufig fehlerhaft formatiert.

Ein lokales Embedding-Modell

nomic-embed-text über Ollama, oder bge-m3 / multilingual-e5-large über sentence-transformers.

Mindestens 16 GB VRAM

12 GB reichen zur Not für ein 8–9B-Modell in Q4 (Qwen 3.5 9B), aber die Indexierung wird langsam sein. 16 GB bieten Platz für gpt-oss 20B oder Mistral Small 24B; 24 GB (RTX 4090, M-Max) bieten komfortable Reserven.

Python 3.10+

nano-graphrag und die meisten modernen RAG-Frameworks erfordern 3.10 oder höher.

#1. Ein Korpus mit nano-graphrag indexieren

Bereiten Sie zunächst die Modelle in Ollama vor. Für dieses Tutorial verwenden wir gpt-oss 20B (standardmäßig mit MXFP4 quantisiert, ~14 GB) und nomic-embed-text für die Embeddings.

ollama pull gpt-oss:20b
ollama pull nomic-embed-text
ollama serve  # si pas déjà en service

Installieren Sie anschließend nano-graphrag in einem eigenen venv.

python -m venv .venv
source .venv/bin/activate  # Linux/macOS
pip install nano-graphrag

Der Indexierungscode besteht aus etwa zwanzig Zeilen. Er wird über den OpenAI-kompatiblen Endpoint auf dem Port 11434 an Ollama angeschlossen.

import asyncio
from nano_graphrag import GraphRAG, QueryParam
from nano_graphrag.llm import ollama_model_if_cache, ollama_embedding

WORKING_DIR = "./graphrag_cache"

async def main():
    rag = GraphRAG(
        working_dir=WORKING_DIR,
        best_model_func=ollama_model_if_cache,
        cheap_model_func=ollama_model_if_cache,
        embedding_func=ollama_embedding,
        best_model_kwargs={"model_name": "gpt-oss:20b"},
        cheap_model_kwargs={"model_name": "gpt-oss:20b"},
    )

    with open("corpus.txt", encoding="utf-8") as f:
        text = f.read()

    await rag.ainsert(text)

if __name__ == "__main__":
    asyncio.run(main())

Starten Sie die Indexierung. Je nach Größe des Korpus und GPU müssen Sie mit einigen Minuten (1 MB Text) bis zu mehreren Stunden (50 MB) rechnen.

python index.py

Am Ende enthält das Verzeichnis graphrag_cache/ den serialisierten Graphen, die Embeddings und die Community-Zusammenfassungen.

#2. Den Graphen abfragen

Nach der Indexierung sind Abfragen schnell (einige Sekunden pro Anfrage), da der LLM nur noch den aus dem Graphen abgerufenen Kontext liest und nicht mehr den gesamten Korpus.

import asyncio
from nano_graphrag import GraphRAG, QueryParam
from nano_graphrag.llm import ollama_model_if_cache, ollama_embedding

async def main():
    rag = GraphRAG(
        working_dir="./graphrag_cache",
        best_model_func=ollama_model_if_cache,
        cheap_model_func=ollama_model_if_cache,
        embedding_func=ollama_embedding,
        best_model_kwargs={"model_name": "gpt-oss:20b"},
        cheap_model_kwargs={"model_name": "gpt-oss:20b"},
    )

    # Mode global : synthèse à partir des résumés de communautés
    print(await rag.aquery(
        "Quels sont les thèmes principaux du corpus ?",
        param=QueryParam(mode="global")
    ))

    # Mode local : recherche centrée sur des entités
    print(await rag.aquery(
        "Quelle est la position de l'entreprise X sur le sujet Y ?",
        param=QueryParam(mode="local")
    ))

asyncio.run(main())

#Kosten für lokale Rechenleistung: Was Sie erwarten können

Das ist der Teil, der beim ersten Mal alle überrascht. Die Indexierung von 5 MB Text mit GraphRAG erfordert etwa 50- bis 200-mal so viel Rechenaufwand wie ein vektorbasiertes RAG auf demselben Korpus. Hier sind konkrete Anhaltspunkte für die Größenordnungen.

Korpus mit 1 MB (~300 Seiten)

gpt-oss 20B (MXFP4) auf RTX 4090: ca. 25 Minuten Indexierung. Auf RTX 3060 12 GB (teilweiser Offload): ca. 3 Stunden. Auf Mac M3 Max 64 GB: ca. 40 Minuten.

Korpus mit 5 MB (~1500 Seiten)

RTX 4090: ca. 2 Stunden. M4 Pro 48 GB: ca. 3 Stunden. Bei größeren Datenmengen sollten Sie einplanen, das System über Nacht laufen zu lassen.

Maximaler VRAM-Verbrauch

Das Modell gpt-oss 20B (MXFP4) belegt dauerhaft etwa 14 GB. Die nomic-Embeddings benötigen zusätzlich etwa 1 GB. Bei weniger als 16 GB VRAM müssen Sie mit einer teilweisen Auslagerung in den Arbeitsspeicher und Ausführung auf der CPU rechnen (partielles Offloading).

Kosten pro Anfrage

Einige Sekunden im lokalen Modus, 5 bis 30 Sekunden im globalen Modus (Aggregation mehrerer Communities). Im Vergleich zur Indexierung fällt das kaum ins Gewicht.

Inkrementelle Neuindexierung

nano-graphrag kann derzeit einen bestehenden Graphen nicht sauber aktualisieren. Das Hinzufügen von 10 % neuen Dokumenten erfordert eine erneute teilweise oder vollständige Indexierung. Microsoft GraphRAG geht damit besser um.

#Wann GraphRAG die Vektorsuche wirklich übertrifft

GraphRAG ist kein universeller Ersatz für vektorbasiertes RAG. Bei manchen Anwendungsfällen ist es diesem haushoch überlegen, bei anderen schneidet es deutlich schlechter ab.

Zusammenfassung auf Grundlage eines Korpus

„Was sind die 5 wichtigsten Themen, die in unseren 200 E-Mails zum Thema X diskutiert wurden?“ → GraphRAG gewinnt haushoch. Die Vektorsuche liefert nur 5–10 E-Mails zurück, der Graph fasst die Communities zusammen.

Multi-hop-Fragen

„Welche Lieferanten arbeiten sowohl mit Acme als auch mit Beta Corp zusammen?“ → GraphRAG löst dies durch das Durchlaufen von Kanten. Der vektorbasierte Ansatz muss die richtigen Chunks finden und sich darauf verlassen, dass das LLM den Join durchführt.

Erkundung von Beziehungen

„Welche Personen werden im Zusammenhang mit dem Projekt Atlas am häufigsten erwähnt?“ → GraphRAG unterstützt das von Haus aus (Zentralität, Nachbarschaft). Der vektorbasierte Ansatz kennt keine Beziehungen.

Fokussierte faktenbasierte Q&A

„Wie lang ist die Kündigungsfrist im Acme-Vertrag vom 12. März 2024?“ → Vektorbasierte RAG gewinnt: schneller, präziser und mit geringeren Indexierungskosten.

Sehr dynamisches Korpus

Wenn Sie täglich Dokumente hinzufügen, werden die Kosten für die erneute Indexierung von GraphRAG untragbar. Bleiben Sie bei der Vektorsuche oder einer Kombination aus Vektorsuche und BM25.

Korpus < 500 kB

Kein Graph erforderlich: Das LLM kann alles im Kontext lesen, wenn Ihnen 32k+ Tokens zur Verfügung stehen. GraphRAG ist nur bei Korpora gerechtfertigt, die zu groß sind, um in den Kontext zu passen.

#Weiterführende Informationen

GraphRAG ist ein aktives Forschungsgebiet: Die Implementierungen entwickeln sich schnell weiter, ebenso die Benchmarks. Einige Anregungen zur Vertiefung.

Lokales RAG: Einführung

Wenn Ihnen einige Konzepte des vektorbasierten RAG noch unklar sind, bietet der Einführungsleitfaden eine gute Grundlage, bevor Sie GraphRAG produktiv einsetzen.

Chunking-Strategien

Die Qualität der Entitätsextraktion hängt direkt von der Größe und Kohärenz der Chunks ab. Dieser Leitfaden geht ausführlich auf bewährte Vorgehensweisen ein.

Hybride Suche: BM25 + Vektorsuche

Wenn Sie GraphRAG mit klassischem Retrieval kombinieren möchten, sehen Sie sich zunächst die hybride Suche an: Sie folgt derselben Logik der Kombination von Signalen.

GPU für lokale KI auswählen

Die GraphRAG-Indexierung ist ressourcenintensiv. Wenn Sie derzeit eine GPU mit 8–12 GB verwenden, verändert der Wechsel zu 16–24 GB die Verarbeitungsgeschwindigkeit grundlegend.