Startseite / Artikel / RAG gegen Agentic RAG gegen Graph RAG: Die richtige Sucharchitektur auswählen

RAG Agentic RAG Graph RAG LLM Vector Database AI Architecture

RAG gegen Agentic RAG gegen Graph RAG: Die richtige Sucharchitektur auswählen

Erfahren Sie, warum das naive RAG bei mehrstufigen Fragen und strukturierten Daten versagt, und wie agierende Schleifen sowie graphbasierte Abrufverfahren jeweils unterschiedliche Schwächen beheben.

1606 Wörter

Das Problem, das RAG lösen soll

Jedes große Sprachmodell besitzt Wissen, dessen Akkumulation nach Abschluss der Trainingsphase endet, und es kann nur über das reasoningen, was in seinem Kontextfenster Platz findet. Retrieval-Augmented Generation begegnet diesem Problem, indem es einem externen Speicher hinzugefügt wird, auf den das Modell bei der Beantwortung einer Frage zugreifen kann. Anstatt ausschließlich auf das zu vertrauen, was es während des Trainings gelernt hat, zieht das Modell relevante Texte aus einer Dokumentensammlung ab und verwendet dieses Material, um seine Antwort zu untermauern.

Die zugrunde liegenden Schritte sind Ihnen vermutlich bereits bekannt:

Quelldokumente werden in kleinere Abschnitte aufgeteilt und in Vektordarstellungen umgewandelt.
Diese Vektordarstellungen werden in einer Vekordatenbank gespeichert – gängige Optionen sind Pinecone, Weaviate, pgvector und ähnliche Tools.
Wenn ein Benutzer eine Abfrage eingibt, wird diese mit derselben Methode in Vektoren umgewandelt.

Das System wählt die top-k-Blöcke aus, deren Vektoren dem Abfragenvektor am nächsten sind.

Diese Blöcke werden zusammen mit der ursprünglichen Frage des Benutzers in die Anfrage eingefügt.

Das Modell erzeugt eine Antwort, indem es auf diesen abgerufenen Text als Grundlage zurückgreift.

Diese gesamte Abfolge wird einmal von Anfang bis Ende ausgeführt: eine Abfrage und anschließend eine Generierung. Sie ist kostengünstig, ihr Verhalten lässt sich leicht verstehen, und für eine breite Palette an Anwendungsfällen – das Suchen in internen Dokumenten, das Beantworten von Support-Fragen anhand einer Wissensdatenbank oder das Handhaben von Q&A-Anfragen anhand einer statischen Dokumentensammlung – funktioniert sie hervorragend.

Wo naive RAG versagt

Wenn dieser einfache Ablauf fehlschlägt, fallen die Fehler in wenige erkennbare Kategorien:

Fragen, bei denen mehrere Fakten miteinander verbunden werden müssen. Eine Frage wie „Welche Anbieter haben nach der Policy-Änderung im 3. Quartal ihre Verträge verlängert?“ erfordert zwei separate Informationen, die mit hoher Wahrscheinlichkeit in unterschiedlichen Datenabschnitten zu finden sind. Die Vektorähnlichkeit erkennt Abschnitte, die semantisch der Anfrage ähneln, nicht jedoch die konkrete Kombination von Fakten, die tatsächlich zur Beantwortung benötigt wird.
Keine eingebaute Abbruchbedingung. Das System gibt stets seine top-k Abschnitte aus, unabhängig davon, ob diese tatsächlich die Antwort enthalten. Wenn die eigentliche Antwort außerhalb dieser top-k-Gruppe liegt, erfindet das Modell entweder etwas Plausibles oder gibt eine vage, unhilfreiche Antwort.
Keine Rückkopplungsschleife. Wenn die anfängliche Suche fehlschlägt, erkennt nichts im Prozess das und versucht eine besser formulierte Anfrage. Es setzt einfach mit dem fort, was es erhalten hat.

Ausfall der strukturellen Beziehungen. Das Aufteilen eines Dokuments in Teile behandelt es als einen Haufen unverbundener Textfragmente und vernachlässigt dabei Hierarchien, Verweise sowie Beziehungen zwischen Entitäten – Informationen, die oft die eigentliche Antwort enthalten.

Keines davon ist wirklich ein Fehler; es handelt sich um natürliche Folgen der grundlegenden Annahme, die in der Architektur verankert ist – nämlich dass eine Ähnlichkeitssuche in unverbundenen Textfragmenten ausreicht, um echte Relevanz zu ersetzen. Agentic RAG und Graph RAG zielen jeweils auf einen anderen Schwachpunkt dieser Annahme ab.

Agentic RAG: Einen Entscheidungskreislauf für die Informationsbeschaffung

Agentic RAG ersetzt die starre Abfolge „Informationsbeschaffung dann Erstellung“ durch einen Kreislauf, in dem ein LLM als Koordinator fungiert – er entscheidet, was gesucht werden soll, ob weitere Suchen notwendig sind und wann genügend Informationen vorliegen, um eine Antwort zu erstellen.

Anstelle eines einzigen Abrufschritts verläuft der Prozess eher wie folgt:

Das Modell liest die Anfrage und überlegt, welche Informationen es tatsächlich benötigt.
Es prüft zunächst, ob ein Abruf überhaupt notwendig ist, und falls ja, erstellt es eine Suchanfrage – wobei eine komplexe Frage möglicherweise in kleinere Unterfragen aufgeteilt wird.
Es holt die Ergebnisse ab, beurteilt, ob sie ausreichen, und falls nicht, schreibt die Anfrage um und holt erneut Daten ab.
Je nach Anforderung der Frage kann es bei Bedarf aus verschiedenen Quellen schöpfen – einem Vektorlagern, einer SQL-Datenbank, einer Web-Such-API oder einem internen Service.
Nur nachdem es festgestellt hat, über ausreichende Beweise zu verfügen, gibt es eine endgültige Antwort ab.

Im Grunde genommen umschließt dies RAG innerhalb eines agierenden Zyklus, wobei dasselbe Tool-Aufrufmuster verwendet wird wie von Programmier-Assistenten: Planung, Handlung, Beobachtung des Ergebnisses und anschließende Entscheidung darüber, weiterzumachen oder nicht. Die Informationsbeschaffung ist dann kein zwingender erster Schritt mehr, sondern lediglich eines von mehreren Werkzeugen, das selektiv statt automatisch bei jeder Anfrage aufgerufen wird.

Der Vorteil ist die Flexibilität. Eine einfache Frage löst einen einzigen Suchvorgang aus; eine Frage, die drei aufeinanderfolgende Abfragen in verschiedenen Systemen erfordert, erhält genau das. Die Konfiguration unterstützt außerdem die Selbstkorrektur – wenn die abgerufenen Informationen offensichtlich falsch sind, kann der Agent dies erkennen und stattdessen eine andere Anfrage stellen, anstatt aufgrund unzuverlässiger Kontexte selbstbewusst zu antworten.

Diese Flexibilität hat ihren Preis. Jeder Planungsschritt und jede Bewertungsstufe stellt an sich einen separaten Modellaufruf dar, wodurch pro Abfrage mehr LLM-Aufrufe erforderlich sind, die Latenz steigt und das Kostenprofil viel schwieriger im Voraus zu prognostizieren ist. Agentic RAG eignet sich gut, wenn die Komplexität der Abfragen von Anfrage zu Anfrage stark variiert, da ein fester Ein-Pass-Pipeline entweder bei einfachen Fragen Ressourcen verschwendet oder bei schwierigen Fällen nicht ausreicht. Es ist eine weniger geeignete Wahl, wenn konstant niedrige Latenzzeiten erforderlich sind oder die Abfragen so spezifisch sind, dass ein sorgfältig abgestimmter Single-Shot-Retriever sie bereits gut bewältigen kann.

Graph RAG: Wiederherstellen der durch Chunking zerstörten Struktur

Graph RAG zielt auf eine völlig andere Einschränkung ab: Die herkömmliche Vektorsuche über Chunks verfügt nicht über ein integriertes Konzept dafür, wie sich Entitäten zueinander verhalten.

Anstatt sich ausschließlich auf einen Vektorindex zu verlassen – obwohl er dennoch parallel genutzt werden kann – erstellt Graph RAG ein Wissensgraphen direkt aus dem Quellmaterial. Dazu werden Entitäten wie Personen, Produkte, Organisationen oder Konzepte sowie die sie verbindenden Beziehungen extrahiert, beispielsweise „arbeitet bei“, „hängt von ab“, „wird durch verursacht“ oder „ist eine Version von“. Die Informationsabrufung ist dann nicht mehr rein eine Ähnlichkeitssuche, sondern wird teilweise zu einem Graphen-Traversal-Problem: Ausgehend von einer relevanten Entität kann das System zu verbundenen Entitäten übergehen und Informationen abrufen, die allein durch Schlüsselwort- oder Embedding-Vergleiche niemals zutage kämen, einfach weil sie in einem völlig anderen Dokument durch mehrere Beziehungen getrennt sind.

Michrosofts Forschung zu GraphRAG ist die am häufigsten zitierte Umsetzung dieses Ansatzes, und sie führt eine zusätzliche Funktion ein, die besonders wertvoll für einen bestimmten Anfragetyp ist: die Erkennung von Gemeinschaften. Das System gruppiert das Graph in Clustern eng miteinander verbundener Entitäten und berechnet im Voraus eine Zusammenfassung für jeden Cluster. Dadurch hat Graph RAG einen klaren Vorteil bei umfassenden Fragen, die das gesamte Korpus betreffen – wie zum Beispiel „Welche wiederkehrenden Themen gibt es in dieser ganzen Reihe von Berichten?“ – was genau die Kategorie ist, mit der naives RAG am meisten zu kämpfen hat, da kein einzelner Teilbereich die vollständige Antwort enthält; die Antwort entsteht nur durch die Synthese aller Daten im Datensatz.

Die hier anfallenden Kosten sind strukturell bedingt und nicht zufällig. Der Aufbau des Graphen ist teuer, da dafür eine Extraktion von Entitäten und Beziehungen aus dem gesamten Korpus durchgeführt werden muss, in der Regel mit Hilfe eines LLM, zusätzlich zur notwendigen Erstellung von Zusammenfassungen der Gemeinschaften. Zudem eignet sich dieser Ansatz nicht für Korpora, die häufig ändern, denn der Graph muss jedes Mal neu erstellt oder schrittweise aktualisiert werden, sobald Dokumente sich ändern – was eine weitaus aufwendigere Operation ist als das einfache Hinzufügen eines neuen Vektors in einen Embedding-Index.

Vergleich der drei Ansätze

Es ist erwähnenswert, dass diese Ansätze sich nicht gegenseitig ausschließen. Ein häufiges Muster in der Praxis ist ein agenterischer Loop, der über einen Vektorabrufmechanismus sowie einen Graphenabrufmechanismus als verfügbare Werkzeuge verfügt, wodurch der Agent je nach Anforderung der Abfrage zwischen ihnen wählen oder beide nutzen kann. Die agenterische Schicht ist im Grunde eine Orchestrierungsstrategie, die über jedem verwendeten Abrufmechanismus liegt, und setzt sich daher natürlicherweise auf Graph RAG auf, anstatt mit ihm zu konkurrieren.

Ein praktisches Entscheidungsframework

Anstatt einen Ansatz aus reinem Popularitätsgrund zu wählen, ist es hilfreich, einen konkreten Entscheidungsprozess durchzugehen:

Fangen Sie mit einem einfachen RAG an. Es ist die kostengünstigste Option zum Aufbau und zur Fehlerbehebung, und für den größten Teil der Anwendungen in der Praxis reicht es bereits aus. Vermeiden Sie die Hinzufügung von Komplexität, bevor Sie Beweise dafür haben, dass sie tatsächlich notwendig ist.
Erweitern Sie auf ein agierendes RAG, sobald Sie bestimmte Fehlermuster feststellen: Fragen, bei denen Informationen aus mehreren Quellen abgerufen werden müssen, Antworten, die falsch sind, weil das Modell suchen, das Findene bewerten und erneut suchen musste, oder eine Arbeitslast, die einfache und schwierige Abfragen so mischt, dass ein einziger fester Ablauf entweder überdimensioniert oder unzureichend ist.

Erweitern Sie auf Graph RAG, wenn die Fragen im Wesentlichen Beziehungen betreffen oder das gesamte Korpus umfassen – also in Fällen, in denen Nutzer verstehen möchten, wie Entitäten miteinander verbunden sind, oder eine synthetisierte Antwort für das gesamte Datensatz benötigen anstelle eines Fakts aus einem einzelnen Dokument – und nur dann, wenn Ihre Daten stabil genug sind, sodass das Aufrechterhalten eines Graphen keine ständige Belastung darstellt.

Die zentrale Erkenntnis spiegelt ein Muster wider, das sich im gesamten Systemdesign wiederholt: Eine anspruchsvollere Architektur ist nicht per se überlegen, sie ist nur bei einer bestimmten Art von Fehler vorteilhaft. Naives RAG stößt bei mehrstufigen Schlussfolgerungen und relationellen Fragen an Grenzen. Agentic RAG behebt diesen Schlussfolgerungsdefizit durch Iterationen. Graph RAG beseitigt das relationale Problem durch Einführung von Strukturen. Die richtige Diagnose dessen, welchen Fehler man tatsächlich hat, ist der wichtigste Schritt.