Wenn Unternehmen über KI mit eigenem Wissen sprechen, landet man sehr schnell bei RAG. Kurz danach kommt oft Graph RAG. Beide Begriffe klingen ähnlich, beschreiben aber unterschiedliche Denkweisen über Wissen.
Meine einfache Einordnung ist: Klassisches RAG ist gut darin, relevante Textstellen zu finden und einem Sprachmodell als Kontext mitzugeben. Graph RAG ist gut darin, Beziehungen, Entitäten und Muster über viele Dokumente hinweg nutzbar zu machen. Das eine ist eher Suche plus Antwort. Das andere ist Wissensstruktur plus Synthese.
Beide Ansätze sind nützlich. Beide können scheitern. Und beide werden oft zu früh als technische Lösung verkauft, bevor klar ist, welche Fragen die Nutzer eigentlich stellen und welche Qualität am Ende erwartet wird.
Was ist RAG?
RAG steht für Retrieval Augmented Generation. Die Grundidee ist pragmatisch: Ein Sprachmodell soll nicht nur aus seinem trainierten Wissen antworten, sondern vor der Antwort relevante externe Informationen abrufen. Diese Informationen werden in den Prompt oder Kontext eingebracht. Danach formuliert das Modell eine Antwort auf Basis dieser gefundenen Inhalte.
Ein typischer Ablauf ist: Dokumente werden in kleinere Abschnitte zerlegt, diese Abschnitte werden als Embeddings gespeichert, eine Nutzerfrage wird ebenfalls in einen Suchvektor übersetzt, die ähnlichsten Textabschnitte werden gefunden und dann an das Modell gegeben.
Das ist besonders hilfreich, wenn Wissen aktuell, unternehmensspezifisch oder zu groß für den Modellkontext ist. Beispiele sind Support-Dokumentation, interne Policies, technische Handbücher, Verträge, Projektunterlagen oder Produktwissen.
Was ist Graph RAG?
Graph RAG ergänzt Retrieval um eine Wissensstruktur. Statt nur ähnliche Textstellen zu suchen, werden Entitäten und Beziehungen aus den Dokumenten extrahiert: Personen, Organisationen, Produkte, Systeme, Risiken, Anforderungen, Entscheidungen, Abhängigkeiten. Daraus entsteht ein Graph.
Dieser Graph kann dann genutzt werden, um Fragen zu beantworten, die nicht in einem einzelnen Absatz stehen. Es geht um Muster, Zusammenhänge und Überblick: Welche Themen hängen miteinander zusammen? Welche Kunden betreffen welche Risiken? Welche Systeme sind von welcher Entscheidung abhängig? Welche wiederkehrenden Probleme sieht man über viele Tickets hinweg?
Graph RAG ist deshalb nicht einfach “besseres RAG”. Es ist ein anderer Zugriff auf Wissen. Klassisches RAG fragt: Welche Textstellen passen zur Frage? Graph RAG fragt zusätzlich: Welche Dinge, Beziehungen und Cluster sind für diese Frage relevant?
Vorteile von klassischem RAG
Klassisches RAG ist oft der richtige Einstieg, weil es vergleichsweise einfach, schnell und gut erklärbar ist. Man kann mit vorhandenen Dokumenten starten, eine Suchpipeline aufbauen und relativ schnell prüfen, ob die richtigen Quellen gefunden werden.
Nachteile von klassischem RAG
Die Grenzen sieht man, sobald die Frage nicht in wenigen Textstellen beantwortet werden kann. Klassisches RAG kann ähnliche Chunks finden, aber es versteht nicht automatisch, wie Themen über viele Dokumente hinweg zusammenhängen.
Es kann außerdem an Chunking, Synonymen, impliziten Begriffen, fehlenden Metadaten oder zu ähnlichen, aber falschen Treffern scheitern. Wenn die entscheidende Information nicht im Top-K-Kontext landet, kann das Modell trotz guter Sprachfähigkeit falsch oder unvollständig antworten.
Meine Faustregel: Klassisches RAG ist stark, wenn die richtige Antwort auffindbar ist. Es wird schwächer, wenn die Antwort erst durch Zusammenführen vieler Beziehungen entsteht.
Vorteile von Graph RAG
Graph RAG wird interessant, wenn Wissen verteilt, vernetzt und schwer durch reine Ähnlichkeitssuche greifbar ist. Der Graph kann zeigen, welche Entitäten zusammengehören, welche Communities sich bilden und welche Beziehungen über Dokumentgrenzen hinweg relevant sind.
Das hilft besonders bei strategischen, analytischen oder explorativen Fragen. Nicht: “Was steht in Dokument X?” Sondern: “Welche Muster sehen wir über alle Dokumente hinweg?” Oder: “Welche Risiken hängen mit diesen Systemen, Teams und Kunden zusammen?”
Nachteile von Graph RAG
Graph RAG ist aufwendiger. Man muss Entitäten und Beziehungen extrahieren, bereinigen, aktualisieren und bewerten. Der Graph kann falsch, unvollständig oder überinterpretiert sein. Schlechte Extraktion erzeugt dann nicht bessere Antworten, sondern nur strukturierte Fehler.
Außerdem ist Graph RAG nicht automatisch günstiger oder schneller. Je nach Pipeline entstehen zusätzliche Kosten für Extraktion, Community-Erkennung, Summaries und Graphabfragen. In produktiven Umgebungen muss man also sehr bewusst prüfen, ob der zusätzliche Strukturaufwand den Nutzen rechtfertigt.
Was sollte man wofür verwenden?
Ich würde in den meisten Projekten nicht mit Graph RAG starten, nur weil es anspruchsvoller klingt. Der richtige Einstieg ist die einfachste Architektur, die die relevante Frageklasse zuverlässig beantwortet.
Gibt es sinnvolle Kombinationen?
Ja. Aus meiner Sicht sind Kombinationen oft sinnvoller als ein Entweder-oder. Ein Graph kann zuerst helfen, das relevante Themenfeld, die beteiligten Entitäten oder die richtige Community zu bestimmen. Danach kann klassisches RAG konkrete Dokumentstellen abrufen, die als Belege in die Antwort gehen.
Umgekehrt kann klassisches RAG auch Kandidaten liefern, aus denen ein temporärer Graph für eine konkrete Analyse entsteht. Das ist nützlich, wenn man nicht den gesamten Wissensbestand dauerhaft graphbasiert modellieren will.
Wie kann man RAG und Graph RAG testen?
RAG-Systeme testet man nicht seriös, indem man fünf Beispiel-Fragen stellt und schaut, ob die Antwort gut klingt. Das ist zu oberflächlich. Man muss getrennt prüfen, ob das System die richtigen Quellen findet, ob die Antwort den Quellen treu bleibt und ob das Ganze stabil, bezahlbar und wartbar läuft.
Für klassisches RAG beginnt ein guter Test mit einem Goldset: echte Nutzerfragen, erwartete Antwortpunkte und bekannte relevante Quellen. Dann misst man, ob die relevanten Dokumentstellen im Retrieval überhaupt gefunden werden. Wenn das Retrieval schlecht ist, kann die Antwort nicht zuverlässig gut werden.
Bei Graph RAG kommt eine zweite Prüfebene hinzu: Stimmen die Entitäten und Beziehungen? Sind wichtige Kanten vorhanden? Gibt es Dubletten? Werden Communities sinnvoll gebildet? Sind die globalen Zusammenfassungen durch Quellen gedeckt oder klingen sie nur plausibel?
Meine Empfehlung für die Praxis
Ich würde fast immer mit einem klar begrenzten RAG-System starten: definierter Datenbestand, echte Fragen, messbare Retrieval-Qualität, Quellenanzeige und eine ehrliche Fehlertoleranz. Erst wenn sichtbar wird, dass viele Fragen an Beziehungen, Clustern und Überblick scheitern, würde ich Graph RAG ergänzen.
Graph RAG ist kein Ersatz für saubere Dokumente, gute Metadaten und klare Testdaten. Es ist eine Erweiterung, wenn Wissen nicht mehr nur gesucht, sondern strukturell verstanden werden muss.
Die stärkste Architektur ist oft hybrid: Graph für Navigation und globale Zusammenhänge, klassisches RAG für konkrete Textbelege, und ein Evaluationsset, das beide Ebenen getrennt prüft. Dann wird aus Retrieval nicht nur eine technische Komponente, sondern ein belastbares Wissenssystem.