Eine Suchmaschine findet ein Buch, wenn du Titel oder Stichwort kennst. Aber um zu verstehen, welche Ideen sich durch alle Bücher ziehen, welche Autoren sich beeinflusst haben und welche Themen an Bedeutung gewannen, reicht die Stichwortsuche nicht aus. Du brauchst jemanden, der die Verbindungen zwischen den Werken sieht und dir eine Landkarte des Wissens zeichnet.
In der KI-Welt heißt das Retrieval-Augmented Generation (RAG). Seit etwa zwei Jahren ist RAG der Standard, um Sprachmodellen wie GPT-4 oder Claude Zugriff auf eigene Dokumente zu geben. Dokumente werden in kleine Textstücke zerschnitten, in Zahlen umgewandelt („embedden“) und in einer Vektordatenbank gespeichert. Bei einer Frage sucht das System die ähnlichsten Textstücke heraus und reicht sie dem Modell als Kontext weiter. Für einfache Faktenfragen funktioniert das gut. Aber bei Fragen, die über mehrere Dokumente hinweg eine zusammenhängende Antwort erfordern, stößt das System an seine Grenzen.
Die Lösung heißt GraphRAG. Statt isolierter Textstücke wird vorab ein Wissensgraph aufgebaut: ein Netzwerk aus Entitäten (Personen, Orten, Begriffen) und ihren Beziehungen. Dieses Netzwerk dient dem Sprachmodell als Kontext. Das klingt verlockend, aber man sollte es genau prüfen. Der Artikel von Dattaraj Rao, R&D-Architekt bei Persistent Systems, analysiert die ursprüngliche Microsoft-Studie zu GraphRAG sowie vier unabhängige Benchmark-Untersuchungen. Das Ergebnis: GraphRAG schlägt klassisches Vektor-RAG deutlich – aber nur bei bestimmten Fragetypen, und nicht ohne Kosten.
Warum Textstücke an ihre Grenzen stoßen
Standard-RAG sucht die k relevantesten Passagen per Kosinus-Ähnlichkeit. Das führt zu drei strukturellen Schwächen. Erstens: Es kann keine Punkte verbinden, die in verschiedenen Dokumenten liegen. Wenn die Antwort erfordert, dass man Fakten aus Passage A und Passage B über eine gemeinsame Entität verknüpft – etwa „Welche Produkte von Firma X wurden in den Kundenbeschwerden des letzten Quartals erwähnt?“ – dann bleiben die Textstücke isoliert. Zweitens: Es ist blind für globale Fragen. „Was sind die Hauptthemen in zwei Jahren Kundenfeedback?“ – diese Frage verlangt eine Sicht auf den gesamten Korpus. Die Ähnlichkeitssuche liefert aber nur ein paar oberflächlich ähnliche Schnipsel. Drittens: Es zerreißt den Kontext an den Grenzen der Chunks. Gerade die Hierarchie und die Beziehungen, die für komplexes Denken nötig sind, gehen beim Zerschneiden verloren.
Microsoft Research hat genau diese Schwächen in ihrer GraphRAG-Veröffentlichung benannt: Herkömmliches RAG „kämpft darum, die Punkte zu verbinden“ und schneidet schlecht ab, wenn es darum geht, „semantische Konzepte über große Datenmengen hinweg ganzheitlich zu verstehen“. Die Kernidee von GraphRAG ist daher, vor der eigentlichen Frage den Kontext zu strukturieren – und nicht erst bei der Abfrage zu suchen.
Was ein Kontextgraph anders macht
GraphRAG geht das Problem an, bevor überhaupt eine Frage gestellt wird. Während der Indexierung liest ein Sprachmodell jedes Textstück und extrahiert daraus Entitäten, Beziehungen und Behauptungen. Diese werden zu einem gewichteten Wissensgraphen zusammengesetzt. Dann kommt ein Algorithmus namens Leiden ins Spiel, der die Gemeinschaftsstruktur im Graphen erkennt. Er findet Cluster von zusammenhängenden Themen und baut daraus eine Hierarchie. Für jede dieser Gemeinschaften wird vorab eine Zusammenfassung in natürlicher Sprache erstellt.
Zur Abfragezeit übernehmen diese Zusammenfassungen die Arbeit. Jede relevante Gemeinschaft formuliert eine Teilantwort – das ist der sogenannte „Map“-Schritt. Die Teilantworten werden bewertet und zusammengeführt – der „Reduce“-Schritt. Am Ende synthetisiert das Modell eine finale Antwort, die auf der Struktur des Wissensgraphen basiert und nicht auf ein paar zufällig ähnlichen Snippets. Es gibt auch Varianten wie HippoRAG, die einen anderen Weg gehen: Sie nutzen den Graphen plus einen Personalisiert-PageRank-Algorithmus, um die relevanten Passagen zu finden. Aber das Prinzip ist dasselbe: Beziehungen – nicht nur Kosinus-Ähnlichkeit – bestimmen, welchen Kontext das Modell sieht.
Dieses Vorgehen löst die drei Schwächen des Vektor-RAG. Es verbindet die Punkte, weil der Graph die Beziehungen explizit abbildet. Es versteht globale Zusammenhänge, weil die Gemeinschafts-Hierarchie eine Vogelperspektive bietet. Und es zerstört keinen Kontext, weil die Zusammenfassungen die semantische Struktur bewahren. Ob das in der Praxis tatsächlich bessere Antworten liefert, entscheiden die Benchmarks.
Die Belege: Vier Studien, ein Muster
Die erste und wichtigste Studie stammt von Microsoft selbst. Sie verglichen GraphRAG mit naivem RAG bei Fragen, die ein „Sinnverständnis über den gesamten Korpus“ verlangen – also globale, themenübergreifende Fragen. Über Datensätze mit einer Million Token ließen sie ein Sprachmodell als Jury fungieren und bewerteten drei Aspekte: Vollständigkeit, Vielfalt und Ermächtigung (also ob die Antwort dem Nutzer hilft, weiterzudenken). Das Ergebnis: GraphRAG gewann bei der Vollständigkeit in 72 bis 83 Prozent der Vergleiche, bei der Vielfalt in 62 bis 82 Prozent. Die höchsten Zusammenfassungen sparten bis zu 97 Prozent der Token ein, verglichen mit der direkten Verarbeitung des Quelltextes. Das ist eine erhebliche Differenz. Bei genau der Art von Frage, die klassisches RAG nicht beantworten kann, gewinnt der Graph in zwei von drei Fällen oder öfter.
Die zweite Studie betrachtet die Retrieval-Qualität selbst. Kommt die richtige unterstützende Passage überhaupt in die Top-Ergebnisse? Auf den Standard-Benchmarks für mehrstufiges Fragen – MuSiQue, HotpotQA, 2WikiMultiHopQA – steigert graphgestütztes Retrieval den Recall@5 (also den Anteil der richtigen Passagen unter den Top 5) von durchschnittlich 73,4 Prozent bei naivem RAG auf 87,8 Prozent. Das ist ein Plus von 19,6 Prozentpunkten. Die größten Sprünge gibt es bei den schwierigsten, dokumentübergreifenden Sets: plus 31 Punkte bei MuSiQue, plus 28 Punkte bei 2Wiki. HippoRAG meldet bis zu 20 Prozent Verbesserung bei mehrstufigen Fragen – und das bei 10- bis 20-fach geringeren Kosten und 6- bis 13-fach höherer Geschwindigkeit als iterative Retrieval-Methoden.
Die dritte Studie bringt die Ernüchterung. Eine Untersuchung von Michigan State und Meta aus dem Jahr 2025 hat RAG gegen vier GraphRAG-Familien unter einem einheitlichen Protokoll getestet – identische Chunking-, Embedding- und Generierungsparameter. Das Ergebnis: Es gibt keinen klaren Sieger. Die beiden Ansätze sind komplementär. Bei einstufigen Faktenfragen (Natural Questions) war klassisches RAG minimal besser (F1-Score 64,8 gegenüber 63,0 für die beste Graph-Methode). Bei mehrstufigem Denken (MultiHop-RAG) gewann graphgestütztes Retrieval: 70,3 gegenüber 67,0 Prozent Gesamtgenauigkeit. Das bedeutet: Ein Kontextgraph ist kein universelles Upgrade. Er ist ein spezialisiertes Werkzeug, das sich genau dann auszahlt, wenn Fragen das Denken über mehrere Teile hinweg erfordern.
Die vierte Studie, GraphRAG-Bench (ICLR 2026), hat sich explizit der Frage gewidmet, in welchen Szenarien Graphen messbare Vorteile bringen. Die Genauigkeit nach Aufgabentyp zeigt die Grenzen klar: Bei einfacher Faktenabfrage liegt Textchunk-RAG bei 60,9, der Graph bei 60,1 – praktisch ein Gleichstand. Die Graph-Struktur ist hier nur unnötiger Overhead. Bei komplexem Denken gewinnt der Graph mit 53,4 gegenüber 42,9 – ein Plus von 10 Punkten. Und bei kontextueller Zusammenfassung sogar mit 64,4 gegenüber 51,3 – ein Plus von 13 Punkten.
Wo GraphRAG verliert: Kosten und Bewertungsprobleme
So klar die Vorteile bei komplexen Fragen sind, so deutlich sind auch die Einschränkungen. Zwei Fallstricke sind wichtig. Erstens: Der Aufbau des Graphen ist teuer. Ein Sprachmodell muss Entitäten und Beziehungen aus dem gesamten Korpus extrahieren. Eine Analyse beziffert die Indexerstellung auf etwa 48 Dollar gegen GPT-4o für einen mittelgroßen Korpus – deutlich mehr als ein einfacher Vektorindex. Microsofts eigenes Folgeprojekt, LazyGraphRAG, verschiebt die Extraktion auf die Abfragezeit und reduziert die Kosten auf etwa 0,1 Prozent – ein stilles Eingeständnis, dass das ursprüngliche Budget für viele Anwendungen unpraktikabel ist.
Zweitens: Viele Erfolge werden von einem anderen Sprachmodell bewertet, und diese LLM-Jurys haben systematische Verzerrungen. Eine unabhängige Untersuchung fand Positionsbias – je nachdem, welche Antwort zuerst erscheint, kann sich die Siegquote um mehr als 30 Prozentpunkte verschieben – sowie Längenbias und Wiederholungsbias. Nach Korrektur fiel die gemeldete Siegquote einer populären Methode von 66,7 auf etwa 39 Prozent – unter die 50-Prozent-Schwelle. Das bedeutet nicht, dass die Forschung falsch ist. Es bedeutet, dass die großen Gewinne – die +20 Prozent bei mehrstufiger Genauigkeit, die +15 bis +30 Punkte beim Recall – robust sind, während schmale Vollständigkeitsmargen mit referenzbasierten Metriken skeptisch geprüft werden sollten.
Wann Sie zum Graphen greifen sollten (und wann nicht)
Die Entscheidung ist praktisch. Ein Kontextgraph lohnt sich, wenn Ihre Fragen mehrstufig, global oder sinnverstehend sind, wenn Sie umfassende, multiperspektivische Antworten benötigen und wenn Ihr Korpus reich an Verbindungen ist – etwa Forschungsliteratur, Fallakten, Vorfallshistorien oder Wissensdatenbanken. Bleiben Sie bei Textchunks, wenn Ihre Anfragen meist einzelne Fakten abrufen, der Korpus klein oder flach ist und wenn Indexierungskosten, Latenz oder operative Einfachheit wichtiger sind als ein marginaler Qualitätsgewinn.
Am besten fahren Sie mit einem Hybridansatz. Die systematischen Studien kommen zu demselben Ergebnis: Leiten Sie jede Anfrage an die passende Methode weiter oder kombinieren Sie die Evidenz aus beiden. Die Kombination aus Graph- und Chunk-Retrieval schlägt in den Benchmarks durchgängig jede einzelne Methode. Sie müssen sich nicht für eine Religion entscheiden; Sie müssen einen Router bauen. Das ist kein technischer Luxus, sondern eine Notwendigkeit, wenn Sie die Kosten im Griff behalten und die Qualität maximieren wollen.
Das Fazit: Kein Allheilmittel, sondern ein Werkzeug
Ein Kontextgraph ist keine Magie, aber auch kein Schlangenöl. Es ist ein gezieltes Instrument. Geben Sie ihm eine Frage, die das Verbinden verstreuter Fakten oder die Synthese eines ganzen Korpus erfordert, und er wird Textchunks deutlich schlagen. Geben Sie ihm „Wie lautet die Telefonnummer auf Seite 3?“ und Sie haben für das Indexieren bezahlt, das Sie nicht brauchten. Die Teams, die mit GraphRAG im Jahr 2026 Erfolg haben, werden nicht die sein, die alles in Graphen verwandeln. Es werden die sein, die wissen, welche Fragen einen Graphen verdienen – und die ihre Pipelines intelligent genug bauen, um den Unterschied zu erkennen.
Für Sie als Entwickler oder Tech-Entscheider bedeutet das: Schauen Sie genau auf Ihre Anwendungsfälle. Analysieren Sie Ihre typischen Anfragen. Wie oft sind sie mehrstufig? Wie stark ist Ihr Korpus vernetzt? Wenn die Antworten klar sind, haben Sie einen fundierten Kompass. Und wenn nicht, dann starten Sie mit einem Hybrid-Router – so bleiben Sie flexibel und zahlen nur für den Mehrwert, den Sie tatsächlich nutzen. Die Zukunft gehört nicht dem einen oder anderen Ansatz, sondern der klugen Kombination.
Quelle: venturebeat.com
