Agentic RAG vs. klassisches RAG: Was ist der Unterschied?

Agentic RAG ist eine Weiterentwicklung von Retrieval-Augmented Generation, bei der ein autonomer KI-Agent dynamisch entscheidet, ob, was und wie oft Wissen abgerufen wird. Retrieval ist dabei ein Tool, das der Agent reflektierend, mehrstufig und aus mehreren Quellen aufruft. Klassisches RAG dagegen schickt jede Anfrage durch eine feste, einmalige Pipeline ohne Entscheidungslogik.

• Klassisches RAG = statische Pipeline: einbetten, einmal abrufen, in den Prompt einfügen, generieren. Immer gleicher Ablauf.
• Agentic RAG = dynamische Tool-Politik: Ein Agent plant, entscheidet pro Anfrage, ruft Retrieval iterativ auf und korrigiert sich selbst.
• Trade-off: Agentic RAG steigert die Qualität bei komplexen Fragen, kostet dafür aber mehr Latenz und Geld und birgt das Risiko unkontrollierter Tool-Loops.

Klassisches RAG: die statische Pipeline

Klassisches RAG (in der Forschung als Naive RAG und Advanced RAG eingeordnet, Gao et al. 2023/2024) folgt einem deterministischen Ablauf. Die Anfrage durchläuft immer dieselbe Abfolge von Schritten, unabhängig davon, ob es sich um eine triviale Faktenfrage oder eine verschachtelte Mehrschritt-Frage handelt.

Der typische Query-Pfad einer produktiven klassischen RAG-Pipeline sieht so aus:

```
User Query
-> Query Rewriter / HyDE (optional, einmalig)
-> Embedding + BM25-Query
-> Hybrid Retrieval (top_k = 50-100)
-> Re-Ranker (top_k = 5-10)
-> Prompt-Template + Quellen-Zitierung
-> LLM (Generator)
-> Output + Faithfulness-Check
```

Die Kernannahme: Ein einziger Retrieval-Schritt liefert genug Kontext für die Antwort. Das ist robust, vorhersehbar und gut messbar. Die Schwäche zeigt sich bei Fragen, die mehrere Abruf-Runden brauchen, bei denen unklar ist, welche Quelle relevant ist, oder bei denen die ursprüngliche Formulierung schlecht zum Index passt. Die Pipeline kann nicht nachfassen, nicht umsteuern und keine zweite Quelle hinzuziehen, denn sie hat keine Entscheidungslogik.

Agentic RAG: Retrieval als Tool eines Agenten

Agentic RAG bettet laut der massgeblichen Survey von Singh et al. 2025 (arXiv:2501.09136) autonome Agenten in die RAG-Pipeline ein. Diese Agenten nutzen vier agentische Design-Muster, um die Retrieval-Strategie dynamisch zu steuern:

• Reflection (Selbstkritik): Der Agent bewertet die abgerufenen Quellen und die eigene Zwischenantwort und entscheidet, ob nachgefasst werden muss.
• Planning: Der Agent zerlegt eine komplexe Frage in Teilschritte (Plan-and-Execute).
• Tool Use: Retrieval ist nur eines von mehreren Werkzeugen neben Web-Suche, SQL-Abfrage oder weiteren APIs.
• Multi-Agent Collaboration: Mehrere spezialisierte Agenten teilen sich die Arbeit.

Die frühe Formalisierung dieses Prinzips ist Self-RAG (Asai et al. 2023, arXiv:2310.11511), das über Self-Reflection-Tokens lernt, wann ein Abruf nötig ist und ob die Generierung den Quellen treu bleibt. Konzeptionell sieht ein Agentic-RAG-Aufbau so aus:

```
[Agent (Planner)]
|-- Tool: search_kb(query) -> RAG-Pipeline
|-- Tool: web_search(query)
|-- Tool: sql_query(...)
|-- Memory: conversation buffer + episodic store
|-- Reflection: critique(answer, sources) -> loop
```

Die vier Entscheidungen, die ein Agent trifft

Der entscheidende Unterschied lässt sich auf vier Laufzeit-Entscheidungen herunterbrechen, die im klassischen RAG fix verdrahtet sind:

• OB retrievt wird (Query-Routing): Bei einer Begrüßung oder einer reinen Rechenaufgabe braucht es keinen Abruf. Der Agent kann Retrieval überspringen.
• WAS retrievt wird (Query-Rewriting, Quellenwahl): Der Agent formuliert die Anfrage um oder routet sie an die passende Quelle (interne Wissensbasis vs. Web vs. strukturierte DB).
• WIE OFT retrievt wird (Multi-Hop): Reicht eine Antwort nicht, fasst der Agent mit einer verfeinerten Anfrage nach.
• OB die Antwort taugt (Self-Correction): Per Reflection prüft der Agent das Ergebnis gegen die Quellen und korrigiert, statt blind zu generieren.

Direkter Vergleich

Quellen: Gao et al. 2023/2024 (arXiv:2312.10997); Singh et al. 2025 (arXiv:2501.09136).

Vor- und Nachteile: Qualität gegen Latenz und Kosten

Der Mehrwert von Agentic RAG ist Antwortqualität bei komplexen Fragen. Multi-Hop-Fragen ("Welcher Lieferant in Region X hat im letzten Quartal die höchste Reklamationsquote, und was steht dazu im Rahmenvertrag?") erfordern mehrere Abrufe aus mehreren Quellen plus Zwischenreasoning. Eine statische Pipeline scheitert daran strukturell, ein Agent kann sie schrittweise auflösen.

Die Kosten dieses Mehrwerts sind real und konkret:

• Latenz: Jede Reflection- und Multi-Hop-Runde ist ein zusätzlicher LLM-Aufruf. Aus einer Antwort können schnell drei bis fünf sequentielle Generierungen werden.
• Kosten: Mehr LLM-Aufrufe pro Anfrage bedeuten direkt höhere Kosten. Im Deutschen kommt erschwerend hinzu, dass deutsche Komposita je nach Tokenizer rund 1,3 bis 1,7-mal tokenintensiver sind als das englische Äquivalent, was jeden zusätzlichen Reasoning-Schritt teurer macht.
• Stabilität: Der in der Forschung dokumentierte typische Failure-Mode sind unkontrollierte Tool-Loops und Kosten-Explosion (Singh et al. 2025). Ohne harte Limits für Iterationen, Budget und Timeout wird das Verhalten unvorhersehbar.
• Reifegrad des Begriffs: "Agentic RAG" ist Stand 2026 noch kein scharf konsolidierter Begriff. Er reicht vom simplen ReAct-plus-Retriever bis zu Multi-Agent-Architekturen (HM-RAG, M-RAG). Das ist bei Tool-Auswahl und Erwartungsmanagement zu berücksichtigen.

Wichtig für die Einordnung: Agentic RAG löst klassisches RAG nicht ab, sondern setzt darauf auf. Die zugrundeliegende Pipeline (Hybrid Search, Re-Ranking, Contextual Retrieval) bleibt das Fundament, das der Agent als Tool aufruft. Ebenso ist die parallele Long-Context-Debatte (1-2 Mio. Token Kontextfenster) Stand 2026 keine Ablösung von RAG, sondern Komplementarität: Bei realistischem Multi-Needle-Retrieval fällt selbst Gemini auf rund 60 % Recall, bei deutlich höherer Latenz und Kosten pro Anfrage.

Konkretes Beispiel: dieselbe Frage, zwei Architekturen

Anfrage: "Vergleiche unsere DSGVO-Löschfristen mit der aktuellen Aufsichtspraxis und nenne Abweichungen."

Klassisches RAG: Embedding der Frage, ein Hybrid-Abruf aus der internen Wissensbasis, Re-Ranking auf top-5, Generierung. Ergebnis: Die internen Löschfristen werden korrekt zitiert. Die "aktuelle Aufsichtspraxis" fehlt, weil sie nicht in der internen Basis liegt und die Pipeline keine zweite Quelle anfragen kann. Eine Generierung, niedrige stabile Kosten, aber unvollständige Antwort.

Agentic RAG: Der Agent plant zwei Teilfragen. Schritt 1: search_kb("interne DSGVO-Löschfristen") liefert die internen Werte. Schritt 2: Reflection erkennt, dass der externe Vergleichsmaßstab fehlt, und ruft web_search("aktuelle Aufsichtspraxis Löschfristen") auf. Schritt 3: Der Agent fasst beide Quellen zusammen und markiert Abweichungen. Ergebnis: vollständige Antwort, aber drei LLM-Runden statt einer, entsprechend höhere Latenz und Kosten.

Diese Gegenüberstellung zeigt das Entscheidungskriterium: Lohnt sich der zusätzliche Aufwand pro Anfrage, gemessen am Qualitätsgewinn für den jeweiligen Anwendungsfall.

Wann sich Agentic RAG lohnt

Agentic RAG ist gerechtfertigt, wenn mindestens einer dieser Faktoren zutrifft:

• Ein relevanter Anteil der Anfragen erfordert Multi-Hop-Reasoning über mehrere Fakten.
• Es müssen mehrere heterogene Quellen einbezogen werden (interne KB, Web, strukturierte DB).
• Anfragen sind oft mehrdeutig und profitieren von Query-Routing und -Rewriting.
• Eine einzelne feste Pipeline liefert messbar zu schwache Faithfulness- bzw. Context-Recall-Werte (RAGAS).

Pragmatischer Mittelweg ist ein Hybrid mit Routing: ein schneller klassischer Pfad für den Großteil der einfachen Faktenfragen und ein agentischer Pfad nur für die komplexen Fälle. So fallen die hohen Kosten nur dort an, wo sie echten Mehrwert liefern. In jedem Fall gehören harte Guardrails dazu: Iterations-Limit, Kosten-Budget pro Anfrage, Timeout und durchgängiges Tracing (etwa LangSmith oder Arize Phoenix).

Für Agenturen und B2B-Entscheider

Für DACH-Agenturen und B2B-Teams ist die Botschaft nüchtern: Agentic RAG ist kein Standard-Upgrade, sondern eine bewusste Architekturentscheidung mit Kostenfolgen. Starten Sie mit einer sauberen klassischen RAG-Pipeline (Hybrid Search, Re-Ranking, Evaluation per RAGAS) und messen Sie zuerst, wo sie an Multi-Hop- oder Mehrquellen-Fragen scheitert. Erst diese Datenbasis rechtfertigt den Schritt zu Agentic RAG und liefert das Argument gegenüber dem Budget. Wenn Sie diesen Aufbau, das Routing zwischen klassischem und agentischem Pfad und die nötigen Guardrails für den DACH-Markt planen oder evaluieren wollen, unterstützt Blck Alpaca von der Architekturentscheidung bis zur produktiven, DSGVO-konformen Umsetzung mit EU-Hosting.