Klassisches RAG (Retrieval-Augmented Generation) folgt einer starren Dreischritt-Pipeline: Nutzeranfrage einbetten, die ähnlichsten Dokumenten-Chunks per Vektorsuche abrufen, an ein LLM übergeben, Antwort generieren. Bei statischen Wissensbasen mit vorhersehbaren Fragen funktioniert das zuverlässig. Es versagt aber leise, sobald Fragen mehrere Dokumente überspannen, verschiedene Datenquellen erfordern oder das System erkennen müsste, dass die abgerufenen Chunks die Frage gar nicht beantworten.
Agentic RAG ersetzt diese fixe Pipeline durch einen autonomen Agenten, der selbst entscheidet, wie, wann und wo er Informationen sucht. Der Agent kann eine schlechte Query umformulieren, verschiedene Datenquellen ansteuern, abgerufene Dokumente auf Relevanz prüfen und eine zweite Retrieval-Runde starten, bevor er eine Antwort generiert. Ein Anfang 2025 veröffentlichtes Survey Paper von Penn State und Arizona State hat diese Unterscheidung formalisiert: Agentic RAG als Paradigma, in dem LLMs “nicht nur Informationen aus externen Quellen abrufen, sondern autonom ihre nächsten Schritte planen.”
Die entscheidende Frage ist nicht, welcher Ansatz generell besser ist. Sondern welchen Ihr konkreter Anwendungsfall tatsächlich braucht.
Wo klassisches RAG an seine Grenzen stößt
Klassisches RAG hat genau eine Retrieval-Chance. Die Frage wird in einen Vektor umgewandelt, eine Ähnlichkeitssuche läuft, und was zurückkommt, ist der gesamte Kontext für das LLM. Keine zweite Möglichkeit.
Das reicht, wenn drei Bedingungen erfüllt sind: Die Frage lässt sich auf ein einzelnes Konzept abbilden, die Antwort steckt in ein oder zwei zusammenhängenden Chunks, und die Wissensbasis ist sauber strukturiert. Ein Support-Chatbot, der “Wie ist Ihre Rückgabepolitik?” aus einer FAQ beantwortet, erfüllt alle drei. Der Ziel-Chunk ist offensichtlich, die Antwort ist abgeschlossen, und der Korpus ist kuratiert.
Sobald eine dieser Bedingungen bricht, beginnen die Probleme.
Multi-Hop-Fragen
“Vergleiche unseren Q3-Umsatz in DACH mit Q4 und erkläre, was die Differenz getrieben hat.” Ein klassisches RAG-System bettet diese gesamte Frage als einen Vektor ein und ruft die Top-k-Ergebnisse ab. Die Ähnlichkeitssuche liefert vielleicht den Q3-DACH-Bericht. Oder die Q4-Gesamtübersicht. Sie wird nicht zuverlässig die Q3-DACH-Zahlen und die Q4-DACH-Zahlen und den Marktkommentar zur Varianz liefern. NVIDIAs Techblog beschreibt dies als die “Single Dataset”-Beschränkung: ein Retrieval-Durchlauf gegen eine Quelle, Daumen drücken.
Ein agentisches System zerlegt das in Unterabfragen: Q3-DACH abrufen, Q4-DACH abrufen, Marktanalyse für die Abweichung abrufen. Jede Unterabfrage läuft unabhängig. Der Agent synthetisiert die kombinierten Ergebnisse.
Stille Retrieval-Fehler
Klassisches RAG hat keinen Mechanismus, um zu erkennen, dass der abgerufene Kontext irrelevant ist. Wenn die Top-5-Chunks von einer anderen Produktlinie handeln, generiert das LLM trotzdem eine souverän klingende Antwort aus dem, was es bekommen hat. Kein Feedback-Loop, kein “diese Chunks beantworten die Frage nicht, ich versuche eine andere Query.”
Das ist der gefährlichste Fehlermodus, weil er plausibel klingende, aber falsche Antworten produziert. Das System signalisiert nie, dass es gescheitert ist.
Quellenübergreifende Fragen
Reale Unternehmensanfragen spannen oft mehrere Systeme: einen CRM-Datensatz, eine Produktdatenbank, ein Richtlinien-Dokument und einen E-Mail-Verlauf. Klassisches RAG indiziert typischerweise eine Wissensbasis. “Was haben wir diesem Kunden zu Lieferzeiten zugesagt, und unterstützt unser aktueller Bestand das?” erfordert mindestens drei verschiedene Datenspeicher. Ein einzelner Embedding-basierter Retrieval-Durchlauf kann das nicht leisten.
So funktioniert Agentic RAG: Die Architektur
Agentic RAG ist kein einzelnes Muster. Weaviates technische Übersicht und IBMs Analyse identifizieren mehrere unterschiedliche Architekturen, die jeweils ein anderes Maß an Agent-Autonomie hinzufügen.
Das Router-Muster
Die einfachste agentische RAG-Variante. Ein Routing-Agent empfängt die Nutzeranfrage und entscheidet, welche Wissensquelle angefragt wird: Vektordatenbank, SQL-Datenbank, Web-Such-API oder ein spezialisiertes Tool. Das Retrieval selbst bleibt einmalig, aber der Agent wählt die richtige Quelle, statt blind einzubetten und zu suchen.
Das ist im Grunde ein Dispatcher vor der bestehenden RAG-Pipeline. Das LLM bewertet die Anfrage, klassifiziert sie (“das ist eine Faktenfrage über Produktspezifikationen” vs. “das ist eine aktuelle Nachrichtenfrage”) und routet entsprechend. Keine Iteration, keine Validierung, aber ein gewaltiger Schritt gegenüber der Einheitsquelle.
Die ReAct-Schleife
Das Arbeitspferd für produktive Agentic-RAG-Systeme. Basierend auf dem ReAct-Framework (Reasoning + Acting) folgt der Agent einem iterativen Zyklus:
- Thought: Der Agent überlegt, welche Information er braucht
- Action: Er ruft ein Retrieval-Tool auf (oder ein anderes Tool)
- Observation: Er prüft, was zurückkam
- Wiederholen oder antworten: Reicht der Kontext, wird die Antwort generiert. Wenn nicht, formuliert er die Query um und versucht es erneut.
LangGraphs Agentic-RAG-Implementierung macht das greifbar. Der Graph definiert Knoten für Query-Generierung, Retrieval, Dokumentenbewertung und Query-Umschreibung. Ein grade_documents-Knoten bewertet per Structured Output jeden abgerufenen Chunk auf Relevanz. Irrelevante Ergebnisse lösen einen rewrite_question-Knoten aus, der die Query umformuliert, bevor der Retrieval-Schritt erneut beginnt.
Dieser Feedback-Loop ist genau das, was klassischem RAG fundamental fehlt.
Multi-Agent Retrieval
Bei komplexen Domänen wird ein einzelner Agent zum Flaschenhals. Multi-Agent RAG weist spezialisierten Retrieval-Agenten verschiedene Daten-Domänen zu: ein Agent für die interne Wissensbasis, ein anderer für externe APIs, ein dritter für strukturierte Datenbankabfragen. Ein Koordinator-Agent orchestriert sie, entscheidet welche Spezialisten aktiviert werden, und synthetisiert deren Ergebnisse.
IBM beschreibt dieses Muster als den Einsatz von “Query Planning Agents”, die “komplexe Anfragen in schrittweise Prozesse zerlegen und Unterabfragen orchestrieren.”
Entscheidungshilfe: Wann reicht klassisches RAG?
Nicht jedes System braucht einen Agenten, der das Retrieval steuert. Klassisches RAG hat seinen Platz in mehreren gängigen Szenarien.
FAQ- und Support-Chatbots: Fragen sind vorhersehbar, Antworten in sich geschlossen, der Korpus kuratiert. Die Einfachheit einer statischen Pipeline bedeutet niedrigere Latenz (unter 500ms Round-Trip), geringere Token-Kosten (ein LLM-Aufruf statt drei bis fünf) und weniger Fehlermodi.
Dokumentensuche über einen einzelnen Korpus: Interne Dokumentation, Produkthandbücher, Verträge. Der Nutzer weiß ungefähr, was er sucht, und die Antwort steckt typischerweise in einem Dokument. Pinecones Analyse von RAG-Mustern zeigt, dass gut gechunktes Single-Source-Retrieval komplexere Setups weiter übertrifft, wenn die Wissensstruktur sauber ist.
Latenz-kritische Anwendungen: Agentic RAGs iterative Schleifen addieren Latenz. Jeder “Thought-Action-Observation”-Zyklus beinhaltet einen LLM-Inferenz-Aufruf. Eine ReAct-Schleife mit drei Zyklen verdreifacht die Antwortzeit. Für Live-Kundenchats, wo Nutzer Sub-Sekunden-Antworten erwarten, liefert klassisches RAG mit einem Reranker oft bessere Ergebnisse pro investierter Millisekunde.
Kostenoptimierte Deployments: Jeder Agent-Reasoning-Schritt verbraucht Tokens. Eine ReAct-Schleife, die abruft, bewertet, umschreibt und erneut abruft, kann das Fünffache der Tokens eines einzelnen Retrieve-and-Generate-Durchlaufs verbrauchen. In der Skalierung ist dieser Unterschied erheblich.
Wann Agentic RAG nötig wird
Die Komplexität lohnt sich, wenn Ihr System an bestimmte Wände stößt.
Quellenübergreifende Abfragen: Die Antwort erfordert Daten aus einem Vektorspeicher, einer SQL-Datenbank und einer Live-API. Kein einzelner Retrieval-Durchlauf deckt das ab. Sie brauchen mindestens einen Routing-Agenten, wahrscheinlich auch eine Query-Zerlegung.
Fragen, die iterative Verfeinerung erfordern: “Finde Patente von Unternehmen aus unserem Portfolio, die sich mit der Technologie von Wettbewerber X überschneiden.” Der erste Retrieval-Durchlauf liefert Patentdokumente. Der Agent muss sie mit der Portfolio-Liste abgleichen, dann mit den Wettbewerber-Anmeldungen. Jeder Schritt informiert die nächste Query.
Hohe Anforderungen an Genauigkeit: Finanzanalyse, medizinische Informationssuche, juristische Recherche. Wenn eine falsche Antwort echte Konsequenzen hat, wiegt die Fähigkeit zur Kontextvalidierung und zum Retry schwerer als Latenz-Einsparungen. NVIDIAs NeMo Retriever berichtet von bis zu 50% besserer Retrieval-Genauigkeit mit agentischen Ansätzen und 15x schnellerem Datenzugriff durch optimierte Retrieval-Microservices.
Dynamische Wissensbasen: Wenn sich Ihre Daten häufig ändern (News-Feeds, Marktdaten, Echtzeit-Telemetrie), muss der Agent entscheiden, ob gecachte Ergebnisse noch gültig sind oder ob frische Daten abgerufen werden müssen. Klassisches RAG hat für diese Art von temporalem Reasoning keinen Mechanismus. Genau hier trifft sich Agentic RAG mit Memory-Architekturen für KI-Agenten, die temporale Gültigkeit von Fakten modellieren.
Implementierung: Der praktische Stack
Wenn Agentic RAG die richtige Wahl ist, sieht die Implementierungslandschaft Anfang 2026 wie folgt aus.
Frameworks
LangGraph ist die populärste Wahl für maßgeschneidertes Agentic RAG. Der graphbasierte Zustandsautomat definiert Retrieval, Bewertung und Query-Umschreibung als explizite Knoten mit bedingten Kanten. Der Trade-off: mehr Boilerplate-Code, aber volle Kontrolle über jeden Entscheidungspunkt.
LlamaIndex verfolgt einen abstrakteren Ansatz mit der QueryEngineTool-Abstraktion. Bestehende Query-Engines werden als Tools verpackt, an einen ReAct-Agenten übergeben, und der Agent entscheidet, welche Tools er aufruft. Schnelleres Prototyping, weniger Kontrolle über Bewertungs- und Umschreibungslogik.
CrewAI glänzt bei Multi-Agent RAG, wo spezialisierte Retrieval-Agenten parallel arbeiten sollen. Jeder Agent bekommt eigene Tools, Wissensquellen und Anweisungen. Die Orchestrierungsschicht übernimmt die Koordination.
Zentrale Designentscheidungen
Dokumentenbewertung: Die entscheidende Komponente. Ohne zuverlässigen Mechanismus zur Prüfung, ob abgerufene Dokumente die Frage tatsächlich beantworten, dreht Ihr Agent Endlosschleifen oder generiert aus schlechtem Kontext. LangGraphs Ansatz nutzt Structured Output (eine binäre “relevant” / “nicht relevant” Bewertung durch das LLM) für harte Routing-Entscheidungen. Fortgeschrittenere Systeme nutzen einen leichtgewichtigen Classifier, um Token beim Haupt-LLM für jeden Bewertungsschritt zu sparen.
Maximale Iterationsgrenzen: Ein Agent, der keine relevanten Dokumente findet, sollte nicht endlos schleifen. Setzen Sie eine harte Obergrenze (typisch 3-5 Iterationen) und fallen Sie auf eine “Ich habe nicht genug Informationen”-Antwort oder eine Websuche als Eskalation zurück.
Context-Window-Management: Jede Iteration fügt Tokens hinzu: abgerufene Dokumente, die Reasoning-Spur des Agenten, vorherige Queries. Ohne Kompression oder Zusammenfassung sprengen Sie das Kontextfenster bis Iteration drei. Hier greifen Context-Engineering-Prinzipien direkt: Zwischenergebnisse zusammenfassen, irrelevante Retrieval-History verwerfen, nur die finalen validierten Chunks für den Generierungsschritt behalten.
Wie die Pipeline aussieht
Eine minimale produktive Agentic-RAG-Pipeline hat fünf Komponenten:
- Query-Analysator: Klassifiziert die eingehende Frage (einfache Suche vs. Multi-Hop vs. Vergleich)
- Router: Leitet an die passende(n) Retrieval-Quelle(n) weiter
- Retriever: Führt die eigentliche Suche aus (Vektor, Keyword, SQL, API)
- Grader: Bewertet die Relevanz abgerufener Dokumente
- Generator: Erzeugt die finale Antwort aus validiertem Kontext
Der Router und der Grader sind die zwei Komponenten, die klassischem RAG komplett fehlen. Allein diese zwei hinzuzufügen, auch ohne vollständige ReAct-Schleifen, erfasst den Großteil des Mehrwerts.
Der Kosten-Genauigkeits-Trade-off
Jede Agentic-RAG-Entscheidung läuft auf Token-Verbrauch versus Antwortqualität hinaus. Ein grober Vergleich für eine typische Enterprise-Wissensbasis-Anfrage:
| Metrik | Klassisches RAG | Agentic RAG (Router) | Agentic RAG (ReAct) |
|---|---|---|---|
| LLM-Aufrufe | 1 | 2 | 3-5 |
| Latenz | 0,5-1s | 1-2s | 3-8s |
| Token-Kosten pro Query | 1x | 1,5-2x | 3-5x |
| Multi-Source-Support | Nein | Ja | Ja |
| Selbstkorrektur | Nein | Nein | Ja |
| Ideal für | Einfache Q&A | Source-Routing | Komplexe Recherche |
Das Router-Muster ist oft der Sweet Spot. Es fügt Quellenauswahl hinzu, ohne den Overhead iterativen Reasonings. Für die meisten Enterprise-Deployments löst allein das Routing 70-80% der Anfragen, an denen klassisches RAG scheitert, ohne die Latenz und Kosten vollständiger ReAct-Schleifen. Reservieren Sie das ReAct-Muster für Anfragen, die explizit am Router-Pfad scheitern.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Agentic RAG und klassischem RAG?
Klassisches RAG folgt einer festen Pipeline: Query einbetten, Top-k-Dokumenten-Chunks abrufen, Antwort in einem Durchlauf generieren. Agentic RAG verpackt das Retrieval in einen KI-Agenten, der Queries planen, an mehrere Datenquellen routen, abgerufene Ergebnisse auf Relevanz bewerten, gescheiterte Queries umformulieren und iterieren kann, bis er genug Kontext für eine korrekte Antwort hat.
Wann sollte ich Agentic RAG statt klassischem RAG einsetzen?
Setzen Sie Agentic RAG ein, wenn Ihre Anfragen mehrere Datenquellen umfassen, iterative Verfeinerung erfordern (Multi-Hop-Fragen), hohe Genauigkeit in kritischen Bereichen wie Finanzen, Recht oder Medizin verlangen, oder mit sich häufig ändernden Wissensbasen arbeiten. Klassisches RAG bleibt die bessere Wahl für einfache FAQ-Chatbots, Dokumentensuche über einen einzelnen Korpus, latenz-kritische Anwendungen und kostenoptimierte Deployments.
Welche Frameworks unterstützen den Bau von Agentic-RAG-Systemen?
LangGraph ist das populärste Framework für maßgeschneiderte Agentic-RAG-Pipelines mit explizitem State Management. LlamaIndex bietet abstraktere Lösungen über QueryEngineTool und ReAct-Agent-Integration. CrewAI eignet sich besonders für Multi-Agent RAG mit spezialisierten Retrieval-Agenten. Weitere Optionen sind DSPy für ReAct-Agenten und NVIDIAs NeMo Agent Toolkit für Enterprise-Deployments.
Wie viel teurer ist Agentic RAG im Vergleich zu klassischem RAG?
Ein einfaches Router-basiertes Agentic RAG verursacht etwa 1,5-2x die Token-Kosten pro Anfrage. Eine vollständige ReAct-Schleife mit Dokumentenbewertung und Query-Umschreibung kann 3-5x mehr Tokens verbrauchen und 3-8 Sekunden zusätzliche Latenz verursachen. Die Kosten hängen von der Zahl der Reasoning-Iterationen ab und davon, ob ein kleineres Modell für Bewertungsschritte eingesetzt wird.
Was ist das ReAct-Muster bei Agentic RAG?
ReAct (Reasoning + Acting) ist ein iteratives Agentenmuster, bei dem die KI zwischen Nachdenken über benötigte Informationen, Ausführen einer Aktion wie einer Datenbankabfrage, Beobachten der Ergebnisse und Entscheiden wechselt, ob weitergesucht oder eine finale Antwort generiert wird. Bei Agentic RAG ermöglicht diese Schleife dem System, schlechte Queries umzuformulieren und zu validieren, dass abgerufene Dokumente die Frage tatsächlich beantworten.