Auswahl einer RAG-Architektur: Naiv, Fortgeschritten, CRAG, GraphRAG, Agentic

Warum RAG – und warum ein einziges Design nicht ausreicht

KI-Agenten sind leistungsfähig, doch sie erzeugen Halluzinationen und können keine spezialisierten oder Echtzeit-Daten eigenständig abrufen. Retrieval-Augmented Generation (RAG) behebt beide Probleme, indem sie die Antworten der Agenten in einer überprüften Wissensdatenbank verankert. Doch RAG ist kein einheitliches Schema. Eine einfache Vektorabfrage reicht für einen grundlegenden FAQ-Bot aus, versagt jedoch bei komplexen Schlussfolgerungen oder Analysen, die mehrere Dokumente umfassen. Im Folgenden werden die gängigen RAG-Architekturen sowie ein Entscheidungsprozess zur Auswahl entsprechender Architekturen anhand der Anforderungen der Aufgabe vorgestellt.

Was RAG leistet

RAG holt Dokumente aus einer Wissensdatenbank ab und verwendet sie, um relevantere Antworten zu erzeugen. Das untenstehende Diagramm zeigt den Ablauf vom Dokumentenspeicher über die Vektorabfrage bis zur Erstellung durch ein LLM.

Die Kernidee verbindet die Informationsabrufung, die in der Abbildung von der Speicherung bis zum Abruf verläuft, mit generativer KI. Das Einbringen relevanter Kontexte in die Anfrage hält ein Sprachmodell mit realen Informationen in Verbindung. Es kann Seiten mit fachspezifischem Material in Sekundenschnelle durchscannen, sodass das große Sprachmodell die Anfrage eines Benutzers präzise und schnell beantworten kann.

Ein typischer Arbeitsablauf umfasst zwei Phasen. Die Offline-Phase nimmt Rohdaten auf und bereitet sie als suchbare, strukturierte Daten vor. In der Online-Phase werden die relevanten Daten abgerufen und die Anfrage beantwortet. Eine dritte Phase, ein Feedbackschleifen-Modell, in dem der abgerufte Kontext immer wieder bewertet wird, ist ebenfalls sinnvoll.

Phase 1: Aufnahme

In der ersten Phase werden Rohdateien in strukturierte, suchbare Einträge in einer Datenbank umgewandelt:

1. Laden Sie Daten aus Quellen wie PDFs, Notion, SQL und Slack mit Tools wie LlamaIndex oder LangChain.
2. Reinigen Sie Störungen wie Überschriften, Fußnoten und HTML-Tags.
3. Teilen Sie lange Dokumente in sinnvolle Abschnitte auf, beispielsweise jeweils 500 Wörter. Zu große Abschnitte verwirren das Modell, zu kleine verlieren den Kontext.
4. Einbetten Sie jeden Abschnitt mit einem Embedding-Modell (zum Beispiel OpenAI’s text-embedding-3-small), um Text in Vektoren umzuwandeln.
5. Indizieren Sie die Vektoren in einer Vektordatenbank wie Pinecone oder Chroma, um semantische Suche nach Bedeutung zu ermöglichen.

Phase 2: Abruf und Erstellung

Wenn ein Benutzer eine Anfrage stellt, erfolgt dies in Millisekunden:

1. Abfragedurchwandlung. Das System wandelt die Frage, zum Beispiel „Wie setze ich mein Passwort zurück?“, in einen Vektor um, wobei dasselbe Embedding-Modell wie in Phase 1 verwendet wird.
2. Auswertung. Es durchsucht die Vektordatenbank nach den 3 bis 5 mathematisch am nächsten liegenden Blöcken zur Frage.
3. Neubewertung. Ein Neubewertungsmodell überprüft die Ergebnisse erneut, damit die beste Übereinstimmung an erster Stelle erscheint.
4. Erweiterung. Die gefundenen Blöcke werden in die Prompt des LLM eingefügt. Ein typischer Prompt teilt dem Modell mit, dass es ein hilfreicher Assistent ist, gibt ihm die Blöcke als Kontext und stellt anschließend die Frage zur Passwortrücksetzung.
5. Erstellung. Das LLM liest den Prompt zusammen mit dem Kontext und erstellt eine Antwort, die ausschließlich auf den bereitgestellten Informationen beruht.

Phase 3: Feedback

Die Ergebnisse der Abfrage müssen kontinuierlich bewertet werden, um Halluzinationen zu vermeiden. Bewertung prüft, ob eine Antwort tatsächlich auf dem Kontext beruht, und Beobachtbarkeit zeigt genau an, welcher Teilbereich zu einer falschen Antwort geführt hat. Diese Erkenntnisse fließen wieder in die Anpassung der Chunking-Strategie aus Phase 1 ein.

Tools nach Phase

RAG-Tools sind die Bausteine, die Ihre Daten mit einem Sprachmodell verbinden, und sie werden nach der Phase der Datenverarbeitungskette eingeteilt, für die sie dienen. Die richtige Wahl hängt davon ab, in welcher Phase Sie arbeiten.

Die Tabelle sortiert den RAG-Technologie-Stack nach der Phase der Datenverarbeitungskette.

Ist eine Vektordatenbank erforderlich?

Nicht unbedingt. Ein dedizierter Vektorlagertyp ist für den Aufbau von RAG nicht zwingend erforderlich, es gibt zwei einfachere Ansätze. Bei einem zero-DB-Ansatz werden einige Dokumente in Blöcke aufgeteilt und im RAM gespeichert. Das ist schnell, kostenlos und erfordert keine Einrichtung, doch der Speicher wird beim Neustart gelöscht und große Dokumente führen zu langsamen Lesevorgängen. Ein traditioneller Datenbankansatz speichert die Textblöcke in einer Datenbank wie PostgreSQL und führt suchbasierte Schlüsselwortsuchen durch. Er eignet sich gut für einzigartige Phrasen wie einen Personennamen oder eine ID, verfügt aber nicht über semantisches Verständnis: Ein Benutzer, der nach „Säugetieren“ fragt, erhält kein Ergebnis für ein Dokument, das nur „Hunde“ enthält.

Vergleich von sechs Architekturen

Es gibt keine einheitliche Lösung, die überall geeignet ist. Einige Aufgaben erfordern Schnelligkeit und Einfachheit, andere eine tiefere Analyse sowie mehrere Quellen oder nicht-textuelle Eingaben wie Bilder oder Diagramme. Sechs Hauptdesigns decken die meisten Anforderungen ab: Naive RAG, Advanced RAG, Modular RAG, Corrective RAG (CRAG), GraphRAG und Agentic RAG.

Naive RAG

Die einfachste Form zieht Dokumente basierend auf der Abfrage ab und übermittelt sie dem Modell ohne Anpassungen.

Das Diagramm zeigt eine einfache top-K-Vektorähnlichkeitsabgleich-Methode. Die Abfrage wird zu einem Vektor, die top-K-ähnlichen Abschnitte stammen aus einer Vektor-Datenbank und werden an das LLM weitergeleitet. Die Suche ist semantisch und die Komplexität ist gering.

• Stärken: Es liefert die schnellsten Antworten bei den niedrigsten Rechekosten, lässt sich mit Bibliotheken wie LangChain oder LlamaIndex leicht einrichten und eignet sich zur einfachen Abrufung von Fakten aus sauberen Dokumenten.
• Schwächen: Irrelevante Teile können Störgeräusche erzeugen, die das LLM verwirren; es hat Schwierigkeiten mit komplexen oder mehrteiligen Fragen und kann sich nicht selbst korrigieren, wodurch ein fehlgeschlagener Abruf zu einer erfundenen Antwort führt.
• Am besten geeignet für: einfache Fragen und Antworten anhand kleiner, sauberer Datensätze, wie z. B. Fragen zu persönlichen Dokumenten, interne Firmen-FAQs sowie einfache Apps für den Chat mit Dokumenten.

Fortgeschrittener RAG

Diese Variante fügt Logik wie Abfragenrouting und Neubewertung der Ergebnisse nach dem Abrufschritt hinzu, um eine höhere Genauigkeit zu erreichen.

Die Abbildung zeigt die Umwandlung der Abfrage vor dem Abruf sowie die Neubewertung der Ergebnisse danach. Vor dem Abruf wird die Abfrage umformuliert, um klarer zu sein. Nach dem Abruf werden die Ergebnisse bewertet und überprüft, damit die erzeugte Antwort so relevant und genau wie möglich ist. Die Suche erfolgt hybrid (VektorplusSchlüsselwörter) mit Neubewertung, und die Komplexität liegt im mittleren Bereich.

• Stärken: Es kommt besser mit komplexen Fragen zurecht, wählt geeignete Ansätze für verschiedene Situationen aus und bietet mehr Kontrolle über die Erstellung von Inhalten.
• Schwächen: Das Neuranking verursacht Verzögerungen, mehrere Modellaufrufe pro Anfrage erhöhen die Kosten, es gibt mehr Komponenten, die gewartet werden müssen, und die Komponenten müssen abgestimmt werden, damit sie gut zusammenarbeiten.
• Am besten geeignet für: hochpräzise Systeme, in denen Fehler inakzeptabel sind, wie professionelle Wissensdatenbanken und Kundenservice-Bots.

Modulares RAG

Modulares RAG nutzt eine „Plug-and-Play“-Struktur, bei der separate Module verschiedene Teile des Arbeitsablaufs übernehmen.

Die hervorgehobenen Komponenten umfassen Such- und Speichermodule. Eine solche Aufteilung des Systems bedeutet, dass jedes Teil individuell angepasst werden kann, ohne den Rest neu aufbauen zu müssen: Ein Team kann einen anderen Suchmechanismus, einen leistungsstärkeren Neurangier oder einen anderen Generator einsetzen. Die Datensuche kann aus mehreren Quellen wie APIs, Datenbanken und dem Web erfolgen, wobei die Komplexität hoch ist, da eine ausgefeilte Orchestrierungsschicht erforderlich ist.

• Stärken: Jede Komponente lässt sich leicht anpassen, und Teile können ohne Neustart aufgerüstet oder ersetzt werden.
• Schwächen: Die Einrichtungskosten sowie die architektonische Komplexität sind sehr hoch und erfordern eine frühzeitige Planung. Zudem muss ein starkes Ingenieurteam die Orchestrierung übernehmen, und verschiedene Module-Versionen können miteinander kollidieren.

Am besten geeignet für: komplexe Unternehmenssysteme, die eine umfassende Anpassung erfordern, wie beispielsweise ein Assistent, der gleichzeitig Jira, Slack und Google Drive überprüft.

Korrigierendes RAG (CRAG)

CRAG ist so konzipiert, dass es seine Antworten mehrfach überprüft und diese korrigiert, falls etwas nicht stimmt.

Der Ablauf zeigt einen Bewertungsschritt mit einer Notfall-Websuche. Ein Bewertungsmodell bewertet die abgerufenen Dokumente. Wenn die Bewertung zu niedrig ist, ignoriert das System die interne Datenbank und führt eine Websuche durch, um die Antwort an anderer Stelle zu finden – dies wird durch den gestrichelten Pfad in der Abbildung dargestellt. Aufgrund von logisch basierter Verzweigung und externen API-Aufrufen ist dieses Verfahren sehr komplex.

• Stärken: Mangelhafte Suchergebnisse werden bereits vor dem Anzeigen an den Benutzer korrigiert, und die zusätzliche Qualitätskontrollschicht sorgt für zuverlässigere und genaue Antworten.
• Schwächen: Die Rückfallsuche verbraucht Zeit und Rechenleistung, und das System kann endlos im Kreis laufen, wenn es mit den gefundenen Ergebnissen nie zufrieden ist.
• Am besten geeignet für: arbeitsintensive Aufgaben, bei denen falsche oder veraltete Informationen inakzeptabel sind, wie beispielsweise in der medizinischen und juristischen Forschung.

GraphRAG

GraphRAG verwendet ein Wissensgraphen, um Beziehungen zwischen Informationen zu strukturieren, und stützt sich nicht allein auf Textähnlichkeit.

Das Diagramm zeigt das Durchlaufen des Wissensgraphen sowie die Erstellung von Zusammenfassungen von Gemeinsamkeiten. Nach dem Aufbau des Graphen durchsucht das System diesen nach Mustern in den Daten und nicht nur nach Wortübereinstimmungen, sodass es herausfinden kann, wie Entität A mit Entität B in Verbindung steht, selbst wenn sie in verschiedenen Dokumenten vorkommen. Die Komplexität ist sehr hoch, da ein strukturierter Graphendatenbank aufgebaut und gepflegt werden muss.

Ein zweites Diagramm, entnommen einer Illustration von Microsoft Research, zeigt ein durch einen LLM erzeugtes Wissensgraphen, das mit GPT-4 Turbo auf einem privaten Datensatz aufgebaut wird.

• Stärken: Es kann komplexe Fragen bewältigen, die mehrere Konzepte miteinander verbinden, vermeidet zerstreute Antworten und kann durch das Verknüpfen von Informationen unerwartete, aber relevante Ergebnisse liefern.
• Schwächen: Der Aufbau des Graphen erfordert erhebliche Anstrengungen, es ist langsamer als herkömmliche RAG-Methoden, und seine Qualität begrenzt die Leistung, da es nur so gut ist wie die Verbindungen im Graphen.
• Am besten geeignet für: das Überblick gewinnen und mehrstufige Schlussfolgerungen aus verschiedenen Datenquellen ziehen, wie beispielsweise in der investigativen Journalistik, bei der Betrugsprävention oder in der Arzneimittelentwicklung.

Agentic RAG

In diesem dynamischen Ansatz fungiert ein KI-Agent als Koordinator, um die Antwort zu planen, abzurufen und zu verfeinern.

Der Workflow zeigt einen koordinierenden Agenten, der Werkzeuge zum mehrstufigen Denken verwendet. Anstatt direkt die ersten relevanten Dokumente zu nehmen, plant er einen Ansatz, entscheidet, was untersucht werden soll, und handelt mit Hilfe seiner Werkzeuge. Er teilt die Aufgabe in kleinere Schritte auf, durchsucht verschiedene Datensätze, prüft, ob die Ergebnisse die Anfrage beantworten, und sucht weiter, falls dies nicht der Fall ist.

• Stärken: Er eignet sich für mehrstufiges Denken, trifft intelligente Entscheidungen bei der Informationsbeschaffung und kann die Ergebnisse bei komplexen Anfragen verbessern.
• Schwächen: Mehrfache Suchvorgänge erhöhen die Kosten, und die forschungsartige Vorgehensweise verlangsamt die Reaktionszeiten.
• Am besten geeignet für: Aufgaben, die methodisches Planen erfordern, wie umfassende Fallanalysen in der Rechtsforschung oder Finanzanalysen, die Marktdaten mit regulatorischen Informationen verbinden.

Ein vierstufiger Entscheidungsweg

Keine Regel passt zu allem, aber ein gemeinsamer Ansatz hilft bei der zu bewältigenden Aufgabe.

Der Flussdiagramm leitet Architekten je nach Aufgabenanforderungen durch die Optionen Simple, Graph, Corrective und Advanced RAG. Die Schritte sind:

Schritt 1: Der Komplexitätscheck. Liegt die Antwort in einem einzigen Dokument? Wenn ja, eignet sich No-DB RAG für kleine Dokumente oder Simple RAG, da es schnell, kostengünstig und nahezu mühelos umzusetzen ist.

Schritt 2: Der Beziehungscheck. Erfordert die Beantwortung die Erfassung tiefer Hierarchien oder versteckter Verbindungen über mehrere Datensätze? Falls ja, stellt GraphRAG diese Ressourcen und Verbindungen dar, die eine einfache Textsuche übersehen würde. Nehmen wir die Frage „Welche Abteilungen werden durch Richtlinie A beeinflusst und wer sind ihre Leiter?“ Dabei müssen Abteilungsdaten mit Mitarbeiterdaten verknüpft werden, wobei GraphRAG beide als voneinander verbundene Entitäten darstellt.

Schritt 3: Der Zuverlässigkeits- und Schlussfolgerungs-Test. Kann das System es sich leisten, falsch zu liegen? Wo extreme Präzision entscheidend ist, fügt Corrective RAG oder Self-RAG einen speziellen Schritt hinzu, der prüft, ob die abgerufenen Daten tatsächlich die Frage beantworten, bevor sie dem Benutzer zugestellt werden. Wenn eine solche Aufgabe auch mehrstufige Schlussfolgerungen erfordert, übernimmt Agentic RAG durch seine Agenten die Planung und Selbstverbesserung.

Schritt 4: Der Kompromiss zwischen Leistung und Kosten. Wenn Latenz im Vordergrund steht, eignet sich eine einfachere Konfiguration wie No-DB, Naive oder Simple RAG am besten. Wenn Qualität wichtiger ist als Kosten – allerdings nicht in dem Maße wie bei der extremen Präzision von Schritt 3 – versteht Advanced RAG die Absicht hinter einer Anfrage besser als einfachere Designs, allerdings zu Lasten einer längeren Verarbeitungszeit.

Wann RAG nicht verwendet werden sollte

RAG ermöglicht es großen Sprachmodellen, kontextbezogene Antworten aus umfangreichen privaten Datensätzen zu liefern, ohne ständiges Neutrainieren. Es ist jedoch nicht überall nützlich, insbesondere dann, wenn eine Aufgabe auf tiefgehendem Denken, kreativer Synthese oder dem Beherrschen sprachlicher Muster beruht und nicht darauf, in einem Dokument nachzuschauen. In solchen Fällen funktioniert es in der Regel besser ohne RAG:

• Weites Denken bezüglich gesunder Menschenverstand, ethischer Nuancen oder allgemeinem menschlichem Verhalten. Hier werden die internen Gewichte des vortrainierten Modells genutzt.
• Abfragen zu Allgemeinwissen über Dinge, die seit Jahrzehnten unverändert geblieben sind. Das vortrainierte Modell reicht aus; RAG würde lediglich Verzögerungen verursachen, ohne die Genauigkeit zu erhöhen.
• Kreative Schreibarbeit mit einem bestimmten Ton und Stil. Hier sollten vortrainierte Modelle oder Feinabstimmungen verwendet werden, da RAG überflüssig ist.

Komplexe mathematische oder logische Probleme, die mehrstufige Berechnungen erfordern. Feinabstimmung oder Chain-of-Thought (CoT)-Anreize eignen sich besser.

Sehr niedrige Latenzanforderungen mit nahezu sofortigen Antworten. Embedding, Suchfunktionen und das Einfügen von Daten verursachen zusätzlichen Overhead.

Kleine Datensätze, die vollständig im Prompt untergebracht werden können. Das Einfügen der Daten ist effizienter als das Aufbauen einer Pipeline.

Die abschließende Tabelle vergleicht die Leistung von RAG-, Feinabstimmungs- und Reasoning-Modellen.