Was ist RAG-Architektur? Eine umfassende Definition mit ausführlichen Praxisbeispielen

RAG steht für Retrieval Augmented Generation und bezeichnet einen Prozess, bei dem LLMs externe Informationen nutzen, um ihre Ausgaben zu erweitern und zu verbessern. Als RAG-Architektur bezeichnet man die Gesamtheit der Komponenten und Verbindungen, die RAG möglich machen.

Es gibt verschiedene Kategorien von RAG, und jede basiert auf einer eigenen Architektur. Im Kern bestimmt die Architektur eines RAG-Systems, auf welche spezifische Weise Informationen gespeichert, abgerufen und an ein LLM übergeben werden.

Was ist RAG-Architektur?

RAG-Architektur bezeichnet die zugrunde liegende Konfiguration von Komponenten (und den damit verbundenen Fähigkeiten), auf der ein bestimmtes RAG-System basiert. Alle diese Architekturen bauen auf einer grundlegenden Vorlage auf, die oft als „einfaches“ oder „naives“ RAG bezeichnet wird.

Hier ein allgemeiner Überblick über die grundlegende RAG-Architektur:

• Informationsquelle: Hier werden die externen Informationen gespeichert. Das kann ein Suchindex, eine Vektordatenbank, die große Informationsmengen abbildet, oder ein Repository mit Rohdokumenten sein.
• Retrieval-Komponente: Über diesen Mechanismus wird die Informationsquelle abgefragt. Ein RAG-System kann beispielsweise eine einfache Schlüsselwortsuche nutzen, um relevante Textabschnitte (Chunks) zu finden, oder komplexere Vektorabfragen, um eine Ähnlichkeitssuche durchzuführen.
• Orchestrierungskomponente: Diese Schicht ist der Teil der LLM-basierten Anwendung, der die RAG-Pipeline für einen Nutzer-Prompt startet – entweder gemeinsam mit dem LLM oder eigenständig. Außerdem fasst sie die abgerufenen Informationen zu einem erweiterten Prompt zusammen.

Die Komponenten einer RAG-Architektur sind in der Regel in zwei Pfade gegliedert. Der Ingestion-Pfad nimmt Daten auf und organisiert sie zu einer durchsuchbaren Informationsquelle. Vektordatenbanken, in denen große Textmengen in ein durchsuchbares Repository aus Vektor-Embeddings umgewandelt werden, gehören zu den am weitesten verbreiteten Anwendungen.

Der Retrieval-Pfad nimmt den Prompt eines Nutzers entgegen und generiert daraus eine Abfrage, mit der die Informationsquelle durchsucht wird. Der Orchestrator fügt die abgerufenen Informationen anschließend dem Eingabekontext des LLM hinzu. Bei agentischen und hybriden RAG-Architekturen kann es mehrere Retrieval-Pfade geben.

Arten von RAG-Architekturen

Es ist irreführend, RAG als eine Reihe völlig getrennter Architekturen zu betrachten. Die meisten Entwickler verfolgen einen modularen Ansatz und implementieren separate Komponenten für bestimmte Anwendungsfälle. Zwar lassen sich grobe Grenzen ziehen, doch ist zu beachten, dass sich die einzelnen Architekturmodelle erheblich überschneiden.

1. Basis-RAG

Basis-RAG, auch „naives“ oder „einfaches“ RAG genannt, ist die architektonische Vorlage für andere RAG-Arten.

Der zugrunde liegende Prozess ist relativ unkompliziert: Ein Nutzer gibt einen Prompt ein, der Orchestrator ermittelt (eigenständig oder gemeinsam mit dem LLM), ob externe Informationen benötigt werden, und formuliert und sendet dann eine entsprechende Retrieval-Abfrage.

Die externe Informationsquelle ist häufig eine Vektordatenbank, kann aber auch eine SQL-Datenbank, eine Web-API, ein Wissensgraph oder sogar ein Repository mit „rohen“ Dokumenten sein. Diese zusätzlichen Informationen werden dann dem Eingabekontext des LLM hinzugefügt.

Abgesehen von SQL-Abfragen und APIs gibt es zwei grundlegende Arten von Retrieval-Methoden:

• Lexikalische Suche (Schlüsselwortsuche): Dies ist eine einfache Form von RAG, bei der Schlüsselwörter aus einer Nutzeranfrage extrahiert und mit Textpassagen abgeglichen werden, die diese Schlüsselwörter enthalten. In modernen Pipelines kann der Orchestrator dafür eine sogenannte Sparse-Vektor-Abfrage durchführen, die keine Bedeutung erfasst.
• Dichte Vektorsuche (semantische Suche): Dichte Vektor-Embeddings erfassen Bedeutung. Ein Orchestrator kann eine Datenbank mit dichten Vektoren so abfragen, dass sowohl die Bedeutung des Nutzer-Prompts als auch die der Quellinformationen erfasst wird.

Auch das Gedächtnis (Memory) ist ein wichtiger Bestandteil der RAG-Architektur. Gemeint ist, wie ein LLM den Kontext früherer Chats nutzt, um eine Retrieval-Abfrage zu erstellen, und diese so im größeren Kontext einer Unterhaltung (oder mehrerer Unterhaltungen) verankert. Konversationelles RAG ist bei den meisten Chatbots die Norm, auch wenn manche Anwendungsfälle, etwa Antworten auf Support-Tickets, Einzelfrage-RAG nutzen.

2. Hybrides RAG

Hybrides RAG kombiniert zwei verschiedene Retrieval-Arten, in der Regel Schlüsselwort- und semantisches Retrieval. Die Schlüsselwortsuche findet übereinstimmende Begriffe, die vektorbasierte Suche findet Passagen mit verwandter Bedeutung.

Es können auch andere Retrieval-Formen zum Einsatz kommen, etwa das Durchlaufen von Wissensgraphen oder Abfragen von SQL-Datenbanken. Der Prozess wird häufig durch eine Routing-Logik gesteuert – entweder in Form programmierter Regeln oder einer Klassifizierung der Frage durch ein Modell (wobei auch mehrere Pipelines gleichzeitig laufen können).

Der Orchestrator führt die Ergebnisse zusammen und kann sie neu ordnen (Reranking), bevor er sie an das LLM weitergibt. Beim Reranking werden den abgerufenen Chunks Relevanzwerte zugewiesen, damit das LLM die passendsten Informationen priorisiert.

3. Adaptives RAG

Beim adaptiven RAG wählt eine Routing-Komponente anhand der Anforderungen des Nutzer-Prompts eine Retrieval-Strategie aus, und der Orchestrator führt anschließend den ausgewählten Workflow aus.

Im ursprünglichen Framework (Adaptive-RAG) fungierte ein kleineres Modell als Klassifikator und entschied zwischen keinem Retrieval, einstufigem Retrieval oder mehrstufigem Retrieval. Manche Architekturen setzen inzwischen stattdessen generative Modelle oder regelbasierte Heuristiken ein.

Diese Architektur ist beliebt, weil sie Rechenleistung je nach Komplexität und Anforderungen eines Prompts zuweist und so unnötige Retrieval-Schritte bei einfacheren Prompts reduziert. Sie ist häufig in Assistenten zu finden, die mit verschiedenen Fragetypen umgehen.

4. Korrektives RAG (CRAG)

Korrektives RAG bewertet abgerufene Informationen, bevor sie dem Eingabekontext des LLM hinzugefügt werden. Ein Retrieval-Evaluator prüft, ob die abgerufenen Informationen relevant und nützlich sind. Das architektonische Alleinstellungsmerkmal ist die explizite Bewertungs- und Korrekturphase vor der Antwortgenerierung.

Erweisen sich Informationen als unvollständig oder für den Prompt nicht zutreffend, werden zusätzliche Anfragen ausgelöst. Dabei können andere Retrieval-Methoden als bei der ursprünglichen Anfrage zum Einsatz kommen, etwa die Websuche oder das Durchlaufen eines Wissensgraphen.

Korrektives RAG ist in Bereichen verbreitet, in denen Genauigkeit wichtig ist, etwa in der Medizin und im Recht. Es erfordert allerdings eine zusätzliche Informationsquelle, die die ursprünglich abgerufenen Passagen ergänzen kann.

5. Self-RAG

Bei Self-RAG kann das Modell nach Erhalt des anfänglichen Eingabekontexts selbst Anfragen initiieren. Generierte Antworten werden mithilfe von Reflection-Tokens mit den abgerufenen Belegen abgeglichen, und bei Bedarf werden über den Orchestrator weitere Anfragen gesendet. Umgekehrt kann das LLM auch entscheiden, dass überhaupt kein Retrieval erforderlich ist.

Der Unterschied zu korrektivem RAG besteht darin, dass das LLM seine eigenen Ausgaben beurteilt, entscheidet, ob ein Retrieval nötig und ob abgerufener Text nützlich ist, und seine eigenen Antworten überwacht und bei Bedarf anpasst. Korrektives RAG hingegen bewertet die Qualität der abgerufenen Informationen vor der Generierung.

Diese Architektur eignet sich besonders für komplexe Prompts im Stil einer vertieften Recherche. Da sie die Bewertung der Relevanz (abgerufener Informationen) in die Antwortgenerierung einbezieht, ist sie eine gute Option für Prompts, die evidenzbasierte Antworten erfordern.

6. Agentisches RAG

Agentisches RAG bezeichnet jede Form von RAG, die im Kontext einer agentischen Plattform ausgeführt wird. Das Modell nutzt seine Reasoning-Fähigkeiten, um zu bestimmen, welche Art von Informationen benötigt wird, und wählt aus den verfügbaren Retrieval-Optionen aus.

Das Retrieval kann bei Bedarf mehrfach ausgelöst werden, und das Modell kann für komplexere Abfragen Agenten einsetzen. Ein LLM könnte beispielsweise eine Datenbankabfrage anfordern, um einen Lieferanten zu identifizieren, eine Dokumentensuche auslösen, um relevante Verträge zu finden, und abschließend eine Websuche durchführen, um Kontaktdaten anhand öffentlicher Quellen zu verifizieren.

Agentisches RAG ist die wichtigste Architekturimplementierung in gängigen Chatbots wie Perplexity, ChatGPT, Claude usw. Da diese Plattformen dem Kernmodell Zugriff auf mehrere Tools und RAG-Pipelines bieten, kann es auswählen, welche Retrieval-Form für einen Prompt am besten geeignet ist.

7. Multimodales RAG

Multimodales RAG ruft Kontext aus unterschiedlichen Medientypen ab. Es ist eine wichtige Form von RAG, weil es LLMs Informationen wie Diagramme und Audioaufnahmen zugänglich macht, die ihnen sonst verschlossen blieben.

Die zugrunde liegende Architektur ist dieselbe wie bei jedem anderen System. So könnte etwa eine Indexierungspipeline Bilder für die Suche vorbereiten, indem sie sie direkt in Embeddings umwandelt. Ein agentisches RAG-System könnte diese Bilder dann zusammen mit semantisch relevantem Text abrufen und an ein Vision-Language-Modell zur kombinierten Verarbeitung übergeben.

8. GraphRAG

GraphRAG nutzt Wissensgraphen zusätzlich zur Vektorsuche, um Informationen über Entitäten abzurufen. In der Regel ermittelt der Orchestrator relevante Ausgangsentitäten, auch Knoten genannt, per Schlüsselwortextraktion oder mitunter über eine vorgelagerte Vektorsuche. Ein Graph-Retriever durchläuft einen Wissensgraphen, um einen umfassenderen Kontext aufzubauen.

Auf eine Anfrage nach einer detaillierten Aufschlüsselung einer Produktkategorie hin kann ein LLM beispielsweise eine Vektorsuche auslösen, um bestimmte Entitäten (Produkte) zu identifizieren. Der Orchestrator löst dann eine Suche im Wissensgraphen aus, um verwandte Entitäten wie Lieferanten, Verkaufsstandorte, Bewertungen usw. zu finden.

9. Verzweigtes RAG

Während eine hybride RAG-Architektur verschiedene Retrieval-Methoden nutzen kann, bezeichnet verzweigtes RAG das gleichzeitige Ausführen mehrerer Abfragen, sogenannter Zweige (Branches). Jeder Zweig kann eine separate Informationsquelle abfragen, oder mehrere Zweige fragen dieselbe Quelle parallel mit unterschiedlichen Abfragen oder Filtern ab. Agentische RAG-Architekturen nutzen häufig verzweigtes RAG.

10. HyDE (Hypothetical Document Embeddings)

HyDE ist eine innovative Form von RAG, bei der ein LLM ein hypothetisches Textdokument erstellt, das zeigt, wie eine optimale Antwort aussehen könnte. Dieses „hypothetische Dokument“ wird dann genutzt, um eine Abfrage für ein genaueres Retrieval zu erstellen. Auch wenn das relevante Wissen nicht in den Parametern des LLM abgebildet ist, liegt dem die Überlegung zugrunde, dass eine antwortähnliche Passage besser zu relevanten Dokumenten passen kann als eine kurze Frage oder ein mehrdeutiger Prompt.

Beispiel für eine einfache RAG-Architektur: Vektordatenbank

Basis-RAG bildet die Grundlage für komplexere Architekturtypen. Bei einem einfachen RAG-System mit Vektordatenbank wird die Quelldokumentation in kleinere Teile (Chunks) aufgeteilt und in dichte Embeddings umgewandelt. Gibt ein Nutzer einen Prompt ein, generiert der Orchestrator eine Abfrage, kodiert sie und durchsucht die Datenbank nach relevanten Passagen.

Hier der Prozess Schritt für Schritt:

1. Große Textmengen werden mithilfe einer automatisierten Ingestion-Pipeline und eines Embedding-Modells wie BERT in Vektoren umgewandelt.
2. Die Datenbankanwendung organisiert, indexiert und speichert die Vektoren für eine schnelle Suche.
3. Der Nutzer gibt einen Prompt in einen Chatbot (z. B. Perplexity) ein.
4. Der Orchestrator der Anwendung kodiert den Prompt (mithilfe eines Embedding-Modells), um relevante Informationen aus der Vektordatenbank abzurufen.
5. Die Vektordatenbank liefert relevante Chunks zurück, und der Orchestrator fügt diese dem Eingabekontext (dem „großen Prompt“) hinzu und übergibt ihn an das LLM.
6. Das LLM nutzt den zusätzlichen Kontext, um mithilfe seines internen Wissens (gespeichert in seinen parametrischen Gewichten) eine Antwort zu generieren.

Vergrößern

Beispiel für eine fortgeschrittene RAG-Architektur: Agentisches RAG

Agentisches RAG bezeichnet die zugrunde liegende Architektur von RAG-Systemen innerhalb einer agentischen Plattform. Agentische RAG-Abläufe sind meist komplex, da KI-Agenten je nach Art eines Prompts unterschiedliche Tools und Pipelines aufrufen und bei Bedarf mehrere Agenten einsetzen können.

Hier ein praktisches Beispiel für den Ablauf:

1. Ein Nutzer gibt eine komplexe Frage ein, die eine vertiefte Recherche zu einem Thema erfordert. Nehmen wir für dieses Beispiel an, der Prompt lautet: „Erstelle eine Prognose der Unternehmensgewinne für die nächsten sechs Monate unter Berücksichtigung wichtiger geopolitischer Entwicklungen.“
2. Das LLM folgert, dass eine Kombination von RAG-Abfragen über verschiedene Inhaltstypen hinweg erforderlich ist.
3. Es werden drei verschiedene Agenten eingesetzt: für (a) die Vektorsuche, (b) das Web-Grounding und (c) die (multimodale) Bildsuche.
4. Die Agenten suchen über den Orchestrator mithilfe der verfügbaren Retrieval-Tools nach relevanten Informationen, etwa Nachrichtenbeiträgen und internen Finanzdaten.
5. Das LLM gleicht die abgerufenen Ergebnisse mit der Recherchefrage des jeweiligen Agenten ab und ordnet sie nach Relevanz.
6. Das LLM bewertet die Informationen und löst über einzelne Agenten zusätzliche Suchen aus, wo Informationen fehlen.
7. Sobald genügend Informationen abgerufen wurden, erstellt das LLM Szenarioprognosen auf Basis vorhandener Finanzkennzahlen (aus der internen Dokumentation abgerufen) und ruft ein Rechner-Tool auf, um für jedes Szenario die Gewinne zu prognostizieren.
8. Das LLM generiert anhand der abgerufenen Informationen und Berechnungen eine endgültige Antwort und gibt bei Bedarf Quellen an.

Vergrößern

Wie geht es weiter mit RAG?

Aktuelle Innovationen zielen darauf ab, bestehende RAG-Architekturen tiefgreifender und schneller zu machen, die Genauigkeit beim Retrieval multimedialer Inhalte zu verbessern und Systeme zu entwickeln, die mit hochaktuellen Informationen umgehen können.

Diese drei Trends prägen derzeit die Richtung der Forschung:

• Vertiefte Recherche über mehrere Quellen hinweg: Gemeint ist eine RAG-Architektur, die Suchen planen, mehrere Zweige über unterschiedliche Quellen hinweg ausführen, abgerufene Belege bewerten und generierte Antworten selbst optimieren kann. Agentisches RAG, das all diese Aufgaben ausführen kann, wird zunehmend schneller und kosteneffizienter.
• Multimodale Anwendungen: Retrieval-Pipelines kommen immer besser mit Bildern und Videos zurecht. Sie können zunehmend bestimmte Arten von Informationen in komplexen multimodalen Daten wie langen Videos und anspruchsvollen Diagrammen gezielt ausfindig machen.
• Antworten auf Basis sich ständig ändernder Informationen: LLM-basierte Anwendungen können auf Live-Informationsquellen (etwa Video-Feeds und Sensoren) zurückgreifen, um Eingabekontext bereitzustellen. Systeme können zudem vielschichtige Informationsnetze erzeugen, etwa mit GraphRAG, um diese Daten zu interpretieren.

RAG ist grundlegend für die Funktionsweise LLM-basierter Anwendungen. Es ermöglicht den unterschiedlichsten Nutzern – von Privatverbrauchern bis hin zu Unternehmen in spezialisierten Branchen –, Probleme wie Halluzinationen, unvollständige Trainingsdaten und fehlenden Zugang zu spezialisiertem internem Wissen zu überwinden.

Deshalb zählen RAG-Systeme und die ihnen zugrunde liegende Architektur zu den sich am schnellsten entwickelnden und spannendsten Bereichen der KI-Forschung.