> Was Microsoft GraphRAG und LightRAG wirklich tun, was die Indexierung kostet und wann ein Wissensgraph Vektor-RAG schlägt: Multi-Hop, globale Fragen, Produktkataloge.
>
> Web page: https://balazscsorba.com/de/blog/graphrag-knowledge-graph-rag · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/graphrag-knowledge-graph-rag.md) · [Magyar](https://balazscsorba.com/hu/blog/graphrag-knowledge-graph-rag.md)
> Author: Balázs Csorba · Published: 2026-10-02 · Keywords: GraphRAG, knowledge graph RAG, GraphRAG vs vector RAG, Microsoft GraphRAG explained, LightRAG vs GraphRAG, GraphRAG global vs local search, GraphRAG indexing cost, when to use GraphRAG, multi-hop RAG, LazyGraphRAG

[Blog](https://balazscsorba.com/de/blog)/RAG & Retrieval

# GraphRAG und Knowledge-Graph-RAG: wann ein Graph die Vektorsuche schlägt

Was Microsoft GraphRAG und LightRAG wirklich tun, was die Indexierung kostet und wann ein Wissensgraph Vektor-RAG schlägt: Multi-Hop, globale Fragen, Produktkataloge.

[Balázs Csorba](https://balazscsorba.com/de/about)·2\. Oktober 2026·13 Min. Lesezeit

-   GraphRAG
-   Knowledge graphs
-   LightRAG
-   RAG

![Diagramm: ein Wissensgraph als Zentrum, verbunden mit Entitäten, Communities, lokaler Suche, globaler Suche und Produktteilen.](https://balazscsorba.com/images/blog/graphrag-knowledge-graph-rag/cover.webp?v=28965c6dfa)

## Das Wichtigste in Kürze

-   GraphRAG legt einen per LLM gebauten Wissensgraphen, Leiden-Communities und Community-Berichte über das Chunking. Die Stärke sind globale Fragen zum ganzen Korpus, nicht ein besseres Auffinden einzelner Fakten.
-   Der Preis ist die Indexierung: mindestens ein LLM-Aufruf pro Chunk für die Extraktion plus Zusammenfassungen für jede Entität und jede Community. Microsoft selbst warnt, dass GraphRAG viele LLM-Ressourcen verbrauchen kann.
-   Lokale Suche (Entitäts-Nachbarschaften) hilft bei Beziehungs- und Multi-Hop-Fragen, globale Suche (Map-Reduce über Community-Berichte) bei Themen und Überblicken. Für einfaches Faktenlookup reicht meist Vektor-RAG mit Reranking.
-   Es gibt leichtere Varianten: LightRAG mit inkrementellen Updates, LazyGraphRAG mit den Indexierungskosten von Vektor-RAG, HippoRAG für günstiges Multi-Hop-Retrieval. Behandle die Angaben als Paper-Ergebnisse, bis du sie auf deinen Daten nachgemessen hast.
-   In B2B-Katalogen liegen die Relationen (ersetzt durch, Teil von, kompatibel mit) schon im PIM oder ERP. Lade sie als Graph, statt ein LLM dafür zu bezahlen, sie neu zu entdecken, und nutze die Vektorsuche für den Freitext.

Auf dieser Seite

1.  [Was Microsoft GraphRAG wirklich tut](https://balazscsorba.com/#what-graphrag-does)
2.  [Globale, lokale und DRIFT-Suche](https://balazscsorba.com/#global-local-drift)
3.  [LightRAG, LazyGraphRAG, HippoRAG und Co.](https://balazscsorba.com/#lightrag-and-friends)
4.  [Die Indexierungsrechnung](https://balazscsorba.com/#indexing-cost)
5.  [Wann Graphen gewinnen und wann nicht](https://balazscsorba.com/#when-graphs-win)
6.  [Ein pragmatisches B2B-Beispiel: Produkte und Teile](https://balazscsorba.com/#b2b-product-parts)
7.  [Eine Checkliste, bevor du einen Graphen baust](https://balazscsorba.com/#checklist)
8.  [Wohin das führt](https://balazscsorba.com/#where-this-is-going)
9.  [Quellen](https://balazscsorba.com/#sources)

Alle paar Monate zeigt jemand eine schöne Wissensgraph-Visualisierung und behauptet, Vektor-RAG sei überholt. Ich habe genug Retrieval-Systeme gebaut, um beiden Hälften dieses Satzes zu misstrauen. Graphen lösen tatsächlich Probleme, die Chunk-Ähnlichkeit nicht lösen kann, und sie kosten echtes Geld und bringen echte Komplexität für Probleme, die eine Hybridsuche mit Reranker schon im Griff hat.

Dieser Artikel erklärt, was Microsofts GraphRAG unter der Haube wirklich tut, was LightRAG, LazyGraphRAG und HippoRAG ändern, woher die Indexierungsrechnung kommt und welche Fragen einen Graphen rechtfertigen. Er endet mit einem pragmatischen B2B-Beispiel aus Katalogdaten, bei dem mein Rat bewusst unspektakulär ist: Nutze den Graphen, den du schon hast.

Wenn du noch keine solide Baseline hast, beginne mit [Chunking, Hybridsuche und Reranking](https://balazscsorba.com/de/blog/rag-pipeline-chunking-hybrid-search-reranking) und dem [Überblick über RAG 2026](https://balazscsorba.com/de/blog/rag-2026-hybrid-agentic-long-context). Ein Graph ergänzt eine funktionierende Pipeline, er ersetzt keine.

## Was Microsoft GraphRAG wirklich tut

Die Forschung dahinter ist das Paper [From Local to Global: A Graph RAG Approach to Query-Focused Summarization](https://arxiv.org/abs/2404.16130) von Darren Edge und Kollegen bei Microsoft Research (April 2024). Ausgangspunkt ist eine Schwäche gewöhnlichen RAGs: Es tut sich schwer mit globalen Fragen über einen ganzen Korpus, etwa „Was sind die Hauptthemen im Datensatz?“. Die Ähnlichkeitssuche liefert die Chunks, die der Frage am nächsten sind, und eine Frage über alles hat keinen nächsten Chunk.

Die Open-Source-Implementierung dokumentiert die Indexierung in Stufen. Dokumente werden in Text Units geschnitten (standardmäßig 1.200 Tokens). Ein LLM extrahiert Entitäten mit Titel, Typ und Beschreibung sowie die Beziehungen zwischen ihnen, optional auch Claims. Wiederholte Beschreibungen werden zusammengeführt. Der hierarchische Leiden-Algorithmus clustert den Graphen dann in Communities auf mehreren Granularitätsstufen. Zuletzt schreibt das LLM zu jeder Community einen Bericht, und Text Units, Entitätsbeschreibungen und Berichte werden in einen Vektorspeicher eingebettet.

Der teure Teil passiert einmal bei der Indexierung; die beiden Suchmodi lesen unterschiedliche Artefakte desselben Index.

Daraus folgen zwei Dinge. Der Graph ist keine von Hand modellierte Ontologie, sondern das, was der Extraktions-Prompt gefunden hat; seine Qualität hängt also vom Prompt-Tuning für deine Domäne ab (die Dokumentation sagt das ausdrücklich). Und die Community-Berichte sind eine vorberechnete, hierarchische Zusammenfassung deines Korpus, und genau das macht globale Fragen beantwortbar.

In den Experimenten des Papers schlugen GraphRAG-Varianten auf zwei Datensätzen mit je rund 1 Million Tokens (Podcast-Transkripte und Nachrichtenartikel) eine Vektor-RAG-Baseline in LLM-bewerteten Vergleichen: Gewinnraten von 72 bis 83 Prozent bei Umfassendheit und 62 bis 82 Prozent bei Vielfalt, je nach Datensatz und Variante. Zusammenfassungen auf Root-Ebene der Communities brauchten außerdem 9- bis 43-mal weniger Tokens als die Zusammenfassung des Quelltexts. Die Autoren sind beim Geltungsbereich vorsichtig: Die Auswertung betrifft Sensemaking-Fragen auf zwei Korpora, und es sei mehr Arbeit nötig, um zu sehen, wie gut sich das verallgemeinern lässt.

## Globale, lokale und DRIFT-Suche

Der Unterschied zwischen den Abfragemodi ist das Nützlichste, was man verstehen sollte, denn er zeigt, welche Fragen den Index rechtfertigen.

Modus

Welche Frage er beantwortet

Was er liest

Kostenprofil

**Lokale Suche**

Über konkrete Dinge: „Was wissen wir über Kunde X und seine Verträge?“

Zur Frage passende Entitäten, ihre Nachbarn, Beziehungen, Quell-Text-Units und Community-Berichte

Ein Retrieval und eine Antwort, vergleichbar mit RAG mit größerem Kontext

**Globale Suche**

Über den ganzen Korpus: „Was sind die Hauptrisiken über alle Berichte hinweg?“

Community-Berichte, verarbeitet in einem Map- und einem Reduce-Schritt

Viele LLM-Aufrufe; eine tiefere Community-Ebene ist gründlicher, aber langsamer und teurer

**DRIFT-Suche**

Breiter Einstieg, spezifische Nachfrage

Zuerst relevante Community-Berichte, dann lokale Suche für die Folgefragen

Zwischen beiden; laut Doku umfassender als reine lokale Suche

**Vektor-RAG**

Wo steht das?

Die top-k ähnlichsten Chunks

Am günstigsten bei Indexierung und Abfrage

Die globale Suche verdient einen genaueren Blick. Die Dokumentation beschreibt ein Map-Reduce über Community-Berichte: Die Berichte werden in Chunks zerlegt, jeder Chunk liefert eine Zwischenantwort mit Wichtigkeitsbewertung, und der Reduce-Schritt filtert und aggregiert sie. Die Wahl der Community-Ebene ist ein direkter Regler zwischen Tiefe und Kosten, ein Produktivsystem sollte ihn also nach außen geben, statt ihn fest zu verdrahten.

Die lokale Suche ist der Modus, den die meisten Teams tatsächlich brauchen, und der, der einer klassischen Retrieval-Pipeline am nächsten kommt. Sie bettet die Frage ein, findet verwandte Entitäten und zieht verbundene Entitäten, Beziehungen, Kovariaten, Quell-Chunks und Community-Berichte heran, zugeschnitten auf ein Kontextfenster.

## LightRAG, LazyGraphRAG, HippoRAG und Co.

Das Originaldesign ist gründlich und teuer, und mehrere Projekte greifen genau das an. Eine kurze Orientierung, mit dem üblichen Vorbehalt, dass alle folgenden Zahlen von den Autoren selbst stammen:

-   **[LightRAG](https://github.com/HKUDS/LightRAG)** (Paper vom Oktober 2024, präsentiert auf der EMNLP 2025, MIT-Lizenz) baut einen Graph- plus Vektorindex mit zweistufigem Retrieval, unterstützt inkrementelle Updates und das Löschen von Dokumenten und bietet die Abfragemodi local, global, hybrid, naive und mix. Es läuft auf PostgreSQL, Neo4j, MongoDB, Milvus, Qdrant oder OpenSearch. Das Paper berichtet Verbesserungen bei Genauigkeit und Effizienz des Retrievals, einen Kostenvergleich mit GraphRAG auf Augenhöhe konnte ich aber nicht verifizieren und lasse die Behauptung deshalb offen. Inkrementelle Updates sind das Feature, das mich interessiert: Ein jedes Mal neu gebauter Index passt schlecht zu lebenden Dokumentbeständen.
-   **[LazyGraphRAG](https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)** (Microsoft Research, 25. November 2024) verzichtet auf die vorab erstellte Zusammenfassung. Laut Microsoft sind die Indexierungskosten identisch mit Vektor-RAG und betragen 0,1 % der Kosten von vollem GraphRAG, die Arbeit verschiebt sich auf die Abfragezeit. Das ist der richtige Tausch bei einem großen Korpus und wenigen graphwürdigen Fragen.
-   **[HippoRAG](https://arxiv.org/abs/2405.14831)** (NeurIPS 2024) kombiniert einen per LLM gebauten Wissensgraphen mit Personalized PageRank. Die Autoren berichten Gewinne von bis zu 20 % bei Multi-Hop-Fragebeantwortung und einstufiges Retrieval, das iteratives Retrieval erreicht oder übertrifft, dabei 10- bis 30-mal günstiger und 6- bis 13-mal schneller. Es zielt auf Multi-Hop, nicht auf globale Fragen.

Meine Lesart: „Graph-RAG“ ist eine Familie, kein Produkt. Die nützliche Frage ist, welchen der drei Jobs du brauchst: globale Zusammenfassungen, beziehungsbewusstes Multi-Hop-Retrieval oder inkrementell aktualisiertes Wissen. Wähle die Variante für diesen Job.

## Die Indexierungsrechnung

Microsofts eigene Einstiegsseite warnt, dass GraphRAG viele LLM-Ressourcen verbrauchen kann, und empfiehlt, zuerst den Tutorial-Datensatz und günstigere Modelle auszuprobieren. Das ist die ehrliche Zusammenfassung. Einen Preis pro Million Tokens, der dauerhaft stimmt, kann ich dir nicht nennen, er hängt vom Modell und deinen Prompts ab, aber ich kann zeigen, woher die Aufrufe kommen:

-   **Extraktion:** mindestens ein LLM-Aufruf pro Text Unit, mehr bei Selbstreflexions-Durchgängen („Gleaning“). Das Paper fand, dass der Recall der Extraktion mit zusätzlichen Durchgängen und kleineren Chunks steigt: Mit GPT-4 lieferte ein 600-Token-Chunk fast doppelt so viele Entitätsnennungen wie ein 2.400-Token-Chunk.
-   **Beschreibungs-Zusammenfassung:** Jede Entität und Beziehung, die in vielen Chunks vorkommt, bekommt ihre Beschreibungen von einem LLM zusammengeführt.
-   **Community-Berichte:** ein LLM-geschriebener Bericht pro Community, auf jeder Hierarchieebene.
-   **Embeddings:** Text Units, Entitätsbeschreibungen und Berichtsinhalte. Das ist der einzige Teil, den auch eine Vektor-RAG-Pipeline bezahlt.

Auch die Größe zählt. Die Graphen des Papers für je rund 1 Million Tokens Text hatten 8.564 Knoten und 20.691 Kanten (Podcasts) sowie 15.754 Knoten und 19.520 Kanten (News). Multipliziere das mit deinem Korpus und mit jeder Neuindexierung. Dort summieren sich die Kosten: Ändern sich Dokumente wöchentlich, verändern ein inkrementelles Design wie LightRAG oder ein Design auf Abruf wie LazyGraphRAG die Wirtschaftlichkeit stärker als jedes Prompt-Tuning.

**Schätze, bevor du indexierst**

Indexiere eine repräsentative Stichprobe von 1 bis 5 Prozent, notiere Tokens und Kosten pro Text Unit und rechne hoch. Addiere dann die Kosten der Neuindexierung bei deiner realen Änderungsrate. Vergleiche die Summe mit dem Wert der Fragen, die nur der Graph beantworten kann. Die allgemeine Methode steht in [Kosten, Latenz und Routing](https://balazscsorba.com/de/blog/llm-cost-latency-prompt-caching-routing).

## Wann Graphen gewinnen und wann nicht

Die [GraphRAG-Bench-Studie](https://arxiv.org/abs/2506.05690) (Juni 2025) beginnt mit einer unbequemen Beobachtung: GraphRAG schneidet bei vielen realen Aufgaben häufig schlechter ab als einfaches RAG. Sie untersucht dann Faktenabruf, komplexes Schlussfolgern, Zusammenfassung und kreative Generierung, um die Bedingungen zu finden, unter denen sich der Graph lohnt. Das deckt sich mit meiner Erfahrung. Die Entscheidung hängt von der Form der Frage ab.

Fragetyp

Vektor-RAG + Reranker

Graph-RAG

Meine Wahl

Einzelfakt („Welches Drehmoment gilt für Modell Z?“)

Stark, günstig

Selten besser

Vektor

Multi-Hop („Welcher Lieferant fertigt das Teil, das X ersetzt hat?“)

Verpasst den zweiten Hop, außer ein Agent iteriert

Stark, wenn die Relation explizit ist

Graph oder agentisches Retrieval

Global („Welche Themen wiederholen sich in 5.000 Tickets?“)

Schwach: kein nächster Chunk

Der Fall, für den GraphRAG entworfen wurde

Graph oder Zusammenfassung per Clustering

Relationaler Katalog („Was passt, was ersetzt, was ist Teil von?“)

Findet Text, keine Struktur

Stark, und die Daten sind schon strukturiert

Graph aus strukturierten Daten

Sich schnell ändernde Dokumente

Leicht zu aktualisieren

Teuer, außer inkrementell

Vektor oder LightRAG-artige Updates

Kleiner Korpus, der in den Kontext passt

Nicht nötig

Lohnt sich nicht

Langer Kontext

Das Muster: Graphen helfen, wenn sich die Antwort aus mehreren, durch Relationen verbundenen Teilen oder aus dem Korpus als Ganzem zusammensetzt. Sie helfen nicht, wenn die Antwort in einer Passage steht. Schreibe vor dem Bau zwanzig echte Nutzerfragen auf und ordne jede als Fakt, Multi-Hop oder global ein. Sind 80 Prozent Fakten, brauchst du besseres Chunking und Reranking, keinen Graphen. Miss das Ergebnis mit [Evals für dein Produkt](https://balazscsorba.com/de/blog/llm-evals-for-product-features), nicht mit einer Demo.

## Ein pragmatisches B2B-Beispiel: Produkte und Teile

Das ist die Situation, der ich in B2B-E-Commerce- und ERP-Projekten begegne. Ein Hersteller oder Großhändler verkauft Maschinen, Ersatzteile und Zubehör. Der Vertrieb oder ein Kunde fragt: „Unsere Pumpe P-150 läuft aus. Welche Pumpe ersetzt sie, und welchen Dichtsatz brauche ich jetzt?“ Die Antwort braucht drei Hops: das Nachfolgeprodukt, seine Stückliste und den aktuellen Ersatz eines ausgelaufenen Teils. Verwandte Fragen sind „Was ist mit diesem Flansch kompatibel?“ und „Welches Handbuch deckt diese Variante ab?“.

Eine Vektorsuche über Datenblätter findet die P-150-Seite und vielleicht die P-200-Seite. Sie folgt „ersetzt durch“ nicht zuverlässig zum richtigen Dichtsatz, denn dieser Fakt ist eine Relation zwischen Datensätzen, kein Satz, der der Frage ähnelt. Das ist ein klassischer Graph-Fall. Aber achte darauf, woher der Graph kommen sollte.

Die Relationen sind bereits Felder in einem PIM oder ERP; nur das Handbuch braucht Textsuche.

In einem PIM oder ERP wie Pimcore, Spryker oder SAP liegen diese Relationen bereits als strukturierte Daten vor: Nachfolgerverweise, Stücklisten, Kompatibilitätstabellen. Ein LLM dafür zu bezahlen, sie noch einmal aus PDFs zu extrahieren, ist langsamer, teurer und ungenauer, als die Felder zu lesen. Meine empfohlene Architektur ist deshalb:

1.  **Baue den Graphen aus strukturierten Daten.** Knoten sind Produkte, Teile und Dokumente; Kanten sind die Relationstypen, die deine Stammdaten schon definieren (ersetzt durch, Teil von, kompatibel mit, dokumentiert in). Halte die Knoten-IDs gleich der SKU oder Artikelnummer.
2.  **Nutze Vektor- oder Hybridsuche für den Text.** Handbücher, Datenblätter und Tickets bleiben in einem gechunkten Index. Jeder Chunk trägt die Produkt-IDs, die er erwähnt, sodass eine Graph-Traversierung genau die relevanten Chunks holen kann.
3.  **Erst Entitäten auflösen, dann traversieren.** Der Agent oder Retrieval-Schritt ordnet „P-150“ einem Knoten zu (exakter Treffer schlägt Embeddings bei Artikelnummern), geht ein bis drei Hops mit einer typisierten Abfrage und übergibt dem Modell die gefundenen Datensätze plus die verknüpften Chunks.
4.  **Ergänze LLM-Extraktion nur für Lücken,** etwa Kompatibilitätshinweise, die nur im Freitext stehen, und markiere solche Kanten als weniger verlässlich.
5.  **Prüfe die Verfügbarkeit im führenden System.** Bestand, Preis und Gültigkeit gehören dem ERP, das zur Antwortzeit als Tool aufgerufen wird, nie in den Graphen. Wohin die Reise geht, steht in [Agentic-Commerce-Protokolle](https://balazscsorba.com/de/blog/agentic-commerce-protocols-ucp-acp-guide).

Das ist Graph-RAG ohne den teuren Teil. Es ist außerdem besser nachvollziehbar: Jeder Hop in der Antwort ist ein Datensatz, den jemand öffnen kann. Wenn du solche Systeme baust: Meine [B2B-E-Commerce-Arbeit](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer) ist genau diese Kombination aus Stammdaten und Retrieval.

## Eine Checkliste, bevor du einen Graphen baust

1.  Sammle zwanzig bis fünfzig echte Fragen und ordne sie als Fakt, Multi-Hop oder global ein.
2.  Baue und messe die Baseline: Hybridsuche mit Reranking und ordentlichem Chunking.
3.  Prüfe, ob die Relationen schon als strukturierte Daten existieren. Wenn ja, importiere sie, statt sie zu extrahieren.
4.  Wenn du globale Fragen brauchst, pilotiere GraphRAG oder LazyGraphRAG auf einer Stichprobe und rechne die Kosten hoch, inklusive Neuindexierung.
5.  Wenn sich deine Dokumente oft ändern, teste zuerst inkrementelle Ansätze wie LightRAG.
6.  Tune den Extraktions-Prompt für deine Domäne und prüfe eine Stichprobe extrahierter Entitäten von Hand.
7.  Vergleiche mit der Baseline auf deinen eigenen Fragen, mit LLM-Judge plus menschlichen Stichproben.
8.  Mache den Retrieval-Modus (Vektor, lokal, global) zu einer Router-Entscheidung, statt jede Anfrage durch den Graphen zu zwingen.

Der letzte Punkt spart Geld. Ein günstiger Klassifikator oder ein kleines Modell leitet Faktenfragen an die Vektorsuche und schickt nur globale oder relationale Fragen an den Graphen. Die Pipeline kostet dann so viel, wie jede Frage verdient.

## Wohin das führt

Mit langen Kontextfenstern und agentischem Retrieval kann ein Agent über einen schlichten Index iterieren und Multi-Hop-Schlussfolgern annähern, zum Preis von mehr Aufrufen pro Frage. Graphen verlagern diese Arbeit in die Indexierung. Keiner gewinnt überall, deshalb ist das Muster 2026 ein Router über mehrere Retrieval-Strategien.

Meine Empfehlung: skeptisch bleiben und empirisch arbeiten. Beginne mit der Baseline, ergänze einen Graphen nur für die Fragetypen, die ihn brauchen, beziehe seine Kanten wo immer möglich aus strukturierten Daten und halte die Indexierungsrechnung sichtbar. Ein Graph, der eine Fragenklasse zu bekanntem Preis besser beantwortet, ist ein Gewinn. Ein Graph, der gebaut wurde, weil er im Diagramm gut aussieht, ist ein Kostenfaktor.

## Quellen

1.  [Edge et al.: From Local to Global: A Graph RAG Approach to Query-Focused Summarization (arXiv:2404.16130)](https://arxiv.org/abs/2404.16130)
2.  [Microsoft GraphRAG documentation: overview](https://microsoft.github.io/graphrag/)
3.  [Microsoft GraphRAG documentation: default dataflow](https://microsoft.github.io/graphrag/index/default_dataflow/)
4.  [Microsoft GraphRAG documentation: global search](https://microsoft.github.io/graphrag/query/global_search/)
5.  [Microsoft GraphRAG documentation: local search](https://microsoft.github.io/graphrag/query/local_search/)
6.  [Microsoft GraphRAG documentation: DRIFT search](https://microsoft.github.io/graphrag/query/drift_search/)
7.  [Microsoft GraphRAG documentation: getting started](https://microsoft.github.io/graphrag/get_started/)
8.  [Microsoft Research: LazyGraphRAG, setting a new standard for quality and cost (25 November 2024)](https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)
9.  [Guo et al.: LightRAG: Simple and Fast Retrieval-Augmented Generation (arXiv:2410.05779)](https://arxiv.org/abs/2410.05779)
10.  [HKUDS/LightRAG on GitHub](https://github.com/HKUDS/LightRAG)
11.  [Gutiérrez et al.: HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models (arXiv:2405.14831)](https://arxiv.org/abs/2405.14831)
12.  [Xiang et al.: When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation (arXiv:2506.05690)](https://arxiv.org/abs/2506.05690)

## Häufige Fragen

Was ist GraphRAG und wie unterscheidet es sich von normalem RAG?

Normales RAG zerlegt Dokumente in Chunks, bettet sie ein und holt die ähnlichsten. GraphRAG, wie von Microsoft Research veröffentlicht, lässt zuerst ein LLM Entitäten und Beziehungen aus den Chunks extrahieren, clustert den entstehenden Graphen mit dem Leiden-Algorithmus in Communities und schreibt pro Community eine LLM-Zusammenfassung. Abfragen können dann die Graph-Nachbarschaft einer Entität (lokale Suche) oder die Community-Zusammenfassungen (globale Suche) nutzen statt nur ähnliche Chunks.

Was ist der Unterschied zwischen lokaler und globaler Suche in GraphRAG?

Die lokale Suche startet bei Entitäten, die zur Frage passen, und zieht deren verbundene Entitäten, Beziehungen, Quelltext und Community-Berichte heran. Sie passt zu Fragen über konkrete Dinge. Die globale Suche führt ein Map-Reduce über Community-Berichte aus und passt zu Fragen über den gesamten Datenbestand, etwa die Hauptthemen. Die DRIFT-Suche kombiniert beides: Sie startet bei Community-Berichten und verfeinert mit lokaler Suche.

Wie teuer ist die GraphRAG-Indexierung?

Deutlich teurer als das Einbetten von Chunks, denn ein LLM liest jeden Chunk, um Entitäten und Beziehungen zu extrahieren, und schreibt danach Beschreibungen und Community-Berichte. Microsoft schreibt, dass GraphRAG viele LLM-Ressourcen verbrauchen kann, und empfiehlt, klein und mit günstigeren Modellen zu beginnen. LazyGraphRAG, eine spätere Variante, nennt Indexierungskosten identisch zu Vektor-RAG und 0,1 % von vollem GraphRAG.

Wann ist GraphRAG besser als Vektor-RAG?

Wenn Fragen von Beziehungen oder vom gesamten Korpus abhängen: Multi-Hop-Fragen, korpusweite Themen und Überblicke sowie Daten mit expliziten Relationen wie Produkt- und Teilehierarchien. Bei einfachem Faktenlookup oft nicht. Die Studie GraphRAG-Bench stellt fest, dass GraphRAG bei vielen realen Aufgaben häufig schlechter abschneidet als einfaches RAG. Miss also auf deinen eigenen Fragen.

Ist LightRAG eine gute Alternative zu Microsoft GraphRAG?

Es ist ein leichteres, MIT-lizenziertes Graph-RAG-Framework mit zweistufigem Retrieval (lokal und global), inkrementellen Updates und mehreren Speicher-Backends wie PostgreSQL und Neo4j. Ein Pilot lohnt sich, wenn sich deine Dokumente oft ändern. Die veröffentlichten Vergleiche stammen von den Autoren selbst, teste es also gegen deine Baseline, bevor du dich festlegst.

Brauche ich eine Graphdatenbank für GraphRAG?

Nicht unbedingt. Microsoft GraphRAG schreibt Tabellen und Embeddings, und LightRAG bringt für Tests einen In-Memory-Graphspeicher mit und unterstützt PostgreSQL für die Produktion. Eine dedizierte Graphdatenbank wie Neo4j lohnt sich, wenn du viel über Relationen traversierst oder sie ohnehin modellierst, zum Beispiel Produkt-Teile-Strukturen.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [LLM-Halluzinationen in Produktion reduzieren: Grounding, Zitate und das Nein zur richtigen Zeit](https://balazscsorba.com/de/blog/llm-hallucination-grounding-citations)
-   [pgvector oder Vektordatenbank? So wählst du 2026 den Vektorspeicher](https://balazscsorba.com/de/blog/pgvector-vs-vector-databases)
-   [RAG evaluieren: Retrieval-Metriken, Faithfulness und wie du erkennst, welche Hälfte versagt hat](https://balazscsorba.com/de/blog/rag-evaluation-metrics)
-   [Semantische Produktsuche für B2B-Shops: Artikelnummern, Hybrid-Retrieval und was du messen solltest](https://balazscsorba.com/de/blog/semantic-product-search-b2b)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Gespräch buchen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)