Die Evolution von RAG

Wissen

RAG ist kein statisches Konzept. Seit der Einführung durch Lewis et al. (2020) hat sich die Architektur grundlegend weiterentwickelt. Was als einfaches "suche und generiere" begann, ist heute ein Spektrum von Architekturen mit unterschiedlichen Trade-offs.

Drei Generationen haben sich herauskristallisiert:

Naive RAG (2020--2023): Einfache Vektorsuche + LLM-Generierung
Advanced RAG (2023--2025): Hybrid Search, Re-Ranking, Query Transformation
Agentic RAG (2025+): LLM-gesteuerte, iterative Retrieval-Loops

Stufe 1: Naive RAG

Einfache Pipeline ohne Nachbearbeitung

Vorteile

Einfach zu implementieren
Geringe Latenz
Wenig Infrastruktur nötig

Nachteile

Keine Relevanz-Optimierung
Keyword-Lücken bei reiner Vektor-Suche
Qualität hängt stark vom Embedding-Modell ab

Typische Fehler

Irrelevante Chunks in Top-K Ergebnissen
Halluzinationen durch schlechten Kontext
Synonyme und Umschreibungen werden verpasst

Wann einsetzen?

Prototypen, einfache FAQ-Bots, kleine Dokumentensammlungen

Klicke auf die Stufen-Tabs, um die Evolution von RAG-Architekturen zu erkunden.

Verstehen

Naive RAG -- Die erste Generation

Naive RAG folgt einem starren Dreischritt: Embedding der Query, Vektorsuche mit Top-K, Generierung der Antwort. Keine Vorverarbeitung der Query, kein Re-Ranking der Ergebnisse, kein Feedback-Loop.

Warum es funktioniert: Für einfache Fragen mit einem eindeutigen Dokument als Antwort reicht das völlig aus. "Was ist die Rückgabefrist?" findet den passenden Absatz und das LLM generiert eine korrekte Antwort.

Warum es scheitert:

Vage Queries: "Erzähl mir was über Rückgaben" liefert zu viele, zu unspezifische Chunks
Multi-Hop-Fragen: "Welche Kunden haben sowohl Retouren als auch Beschwerden?" erfordert Informationen aus mehreren Dokumenten, die miteinander verknüpft werden müssen
Keyword-Mismatch: Semantische Suche findet "Erstattung" bei der Query "Geld zurück", aber übersieht exakte Begriffe wie Artikelnummern

Ein Nutzer fragt: 'Welche Produkte mit SKU-Nummer AB-1234 wurden im Q3 zurückgesendet?' -- Naive RAG liefert irrelevante Ergebnisse. Was ist die wahrscheinlichste Ursache?

Advanced RAG -- Hybrid Search und Re-Ranking

Advanced RAG adressiert die Schwächen von Naive RAG durch drei zentrale Erweiterungen:

1. Query Transformation Bevor die Suche startet, wird die Query optimiert:

Query Rewriting: Das LLM formuliert die Nutzerfrage um, um bessere Suchergebnisse zu erzielen
HyDE (Hypothetical Document Embeddings): Das LLM generiert eine hypothetische Antwort, und deren Embedding wird für die Suche verwendet -- oft näher an den Zieldokumenten als die Frage selbst
Query Decomposition: Komplexe Fragen werden in Teilfragen zerlegt

2. Hybrid Search Kombination aus zwei Suchmechanismen:

Dense Retrieval: Vektorsuche über Embeddings (semantische Ähnlichkeit)
Sparse Retrieval: Keyword-basierte Suche wie BM25 (exakte Übereinstimmung)
Fusion: Die Ergebnisse beider Suchen werden mit Reciprocal Rank Fusion (RRF) kombiniert

Suchtyp	Stärke	Schwäche
Dense (Vektor)	Semantische Ähnlichkeit, Synonyme	Exakte Begriffe, Codes, IDs
Sparse (BM25)	Exakte Matches, Fachbegriffe	Synonyme, Umformulierungen
Hybrid (Fusion)	Beides kombiniert	Höherer Aufwand, Tuning nötig

3. Re-Ranking Nach dem Retrieval bewertet ein Cross-Encoder-Modell jedes Ergebnis erneut im Kontext der Query. Cross-Encoder sind langsamer als Bi-Encoder (daher nicht für die initiale Suche geeignet), aber deutlich präziser bei der Relevanzeinschätzung.

Agentic RAG -- Der iterative Loop

Agentic RAG ist der Paradigmenwechsel: Das LLM steuert den Retrieval-Prozess aktiv. Statt einer starren Pipeline entscheidet das LLM:

Ob überhaupt gesucht werden muss (vielleicht reicht das Trainingswissen)
Was gesucht wird (Query-Formulierung und Reformulierung)
Wo gesucht wird (welche Datenquelle, welcher Index)
Ob die Ergebnisse ausreichen (oder ob eine weitere Suche nötig ist)

Der Loop funktioniert wie ein Forscher, der iterativ arbeitet:

Frage analysieren und Suchstrategie planen
Erste Suche durchführen
Ergebnisse bewerten: Reichen sie? Sind sie relevant?
Falls nein: Query reformulieren oder andere Quelle befragen
Schritt 2--4 wiederholen bis die Informationen ausreichen
Synthese der gesammelten Informationen zur finalen Antwort

iAgentic RAG in der Praxis

Agentic RAG ist am mächtigsten, wenn die Frage mehrdeutig ist oder Informationen aus verschiedenen Quellen zusammengeführt werden müssen. Für einfache Lookup-Fragen ist es Overhead.

Ein Unternehmen baut ein System für technischen Support. Kunden stellen Fragen wie 'Mein Gerät XZ-500 zeigt Fehlercode E42 -- was soll ich tun?' -- Welche RAG-Architektur ist am besten geeignet?

Anwenden

Entscheidungsmatrix: Welche RAG-Generation brauche ich?

Kriterium	Naive RAG	Advanced RAG	Agentic RAG
Fragetyp	Einfache Lookup-Fragen	Strukturierte Fragen mit Fachbegriffen	Komplexe, mehrdeutige Fragen
Datenquellen	Eine homogene Quelle	Eine oder wenige Quellen	Mehrere heterogene Quellen
Latenz-Budget	< 1s	1--3s	3--10s+
Implementierungsaufwand	Niedrig	Mittel	Hoch
Typischer Use Case	FAQ-Bot, Dokumentensuche	Technischer Support, Compliance	Research-Assistent, Analyse

Upgrade-Pfad

In der Praxis startest du mit Naive RAG und upgragest gezielt:

Starte mit Naive RAG: MVP bauen, Baseline messen
Miss die Retrieval-Qualität: Wie oft sind die Top-5-Ergebnisse relevant?
Identifiziere Schwächen: Keyword-Mismatches? Irrelevante Chunks? Fehlende Zusammenhänge?
Upgrade gezielt: Hybrid Search für Keyword-Probleme, Re-Ranking für Relevanz, Agentic für Multi-Source

Reflektieren

Du designst ein RAG-System für ein Unternehmen mit 50.000 technischen Dokumenten, internen Wikis und Ticketsystemen. Die Nutzer stellen sowohl einfache Fragen ("Wo finde ich Formular X?") als auch komplexe Analysefragen ("Welche Incidents der letzten 6 Monate betreffen Produkt Y und haben Priorität 1?"). Überlege, welche Architektur du wählen würdest und warum. Die Quizfragen oben helfen dir, deine Entscheidungskriterien zu schärfen.