Ein Fertigungskunde hatte eine Knowledge-Base: 8.000 technische Handbücher, Serviceprotokolle und Zeichnungen. Das Team implementierte klassisches RAG — embedden, top-5 abrufen, generieren. Für Fragen wie „Was sind die Parameter von Motor X?" funktionierte das mit 85 % Genauigkeit. Dann kam die Frage: „Was soll ich tun, wenn Motor X Fehler E47 meldet und gleichzeitig die Temperatur über 80 °C liegt?" Das System lieferte ein Fragment über Fehler E47 und ein Fragment über die Temperatur — aber es präzisierte nie, dass die Kombination beider Zustände ein anderes Vorgehen erfordert als jeder Zustand für sich. Die Antwort war technisch korrekt, operativ nutzlos.
Das ist die Klasse von Problemen, für die klassisches RAG keine architektonische Lösung hat. Es geht nicht um ein besseres Embedding-Modell oder einen größeren Chunk. Es geht darum, wer den Abruf steuert — und wann er weiß, dass er mehr abrufen muss.
Wo klassisches RAG an seine Grenzen stößt
Klassisches RAG (Retrieval-Augmented Generation) arbeitet in einem einzigen Retrieval-Schritt: Eine Frage kommt herein, das System indexiert die Anfrage, lädt top-K-Fragmente aus der Vektordatenbank und übergibt sie an das LLM. Es ist deterministisch, schnell und günstig.
Das Problem tritt bei vier Aufgabentypen auf:
- Mehrstufige Fragen — die Antwort hängt von zwei oder mehr Fakten ab, die in separaten Dokumenten stehen und deren Verbindung im Text nicht explizit ist. Klassisches RAG führt einen einzigen Retrieval-Schritt aus, das LLM bekommt nur einen Teil des Kontexts.
- Unklare oder unvollständige Anfragen — der Nutzer schreibt „Kühlprobleme an Linie 3", aber das System weiß nicht, ob damit die Motorkühlung, die Hydraulikkühlung oder die Hallenklimanlage gemeint ist. Ein einzelner Retrieve-Schritt löst die Ambiguität nicht.
- Vergleichsfragen — „Vergleiche die Serviceintervalle für Anlage A und B" erfordert zwei unabhängige Retrieve-Operationen und deren Synthese, nicht ein einzelnes Retrieve in der Hoffnung, dass beide Dokumente in den top-5 landen.
- Iterative Analysen — der Agent muss zunächst etwas Grundlegendes herausfinden (z. B. die Seriennummer der Anlage), dann auf dieser Basis spezifische Dokumentation abrufen und anschließend die Gültigkeit der Information gegen das Herstellungsdatum prüfen. Jeder Schritt hängt vom Ergebnis des vorherigen ab.
Für diese Szenarien braucht man eine andere Architektur — eine, in der Retrieval keine einmalige Aktion ist, sondern ein iterativer, agentgesteuerterer Prozess.
Was Agentic RAG anders macht
Agentic RAG fügt eine Entscheidungsschicht über die klassische Retrieve-Generate-Pipeline hinzu. Ein Agent — typischerweise ein LLM mit Zugriff auf Tools — erhält die Frage und entscheidet selbst:
- 1.Welche Anfrage er an die Vektordatenbank senden soll
- 2.Ob die Ergebnisse ausreichend sind oder mehr abgerufen werden muss
- 3.Welche neue Anfrage er auf Basis des bisher Erhaltenen formulieren soll
- 4.Wann der Kontext vollständig ist und die Antwort generiert werden kann
Anstelle eines einzigen Retrieve-and-Generate-Zyklus entsteht eine Schleife, in der der Agent seine eigenen Zwischenergebnisse bewertet. In der Praxis sieht das so aus: Der Agent erhält die Frage zur Fehler-Temperatur-Kombination, formuliert eine erste Anfrage zu Fehler E47, liest die Ergebnisse, entscheidet, dass er Kontext zu Temperaturgrenzen benötigt, formuliert eine zweite Anfrage, erhält die Dokumente, synthetisiert beide Kontexte und generiert erst dann die Antwort.
Dieser Ansatz hat drei Schlüsselmechanismen, die klassisches RAG nicht besitzt.
Query Rewriting — Umformulierung der Anfrage
Nutzereingaben entsprechen selten der Sprache, in der Dokumente verfasst sind. Das technische Handbuch beschreibt „Überhitzung des Hydraulikkreislaufs", der Nutzer schreibt „Öl hat zu hohe Temperatur". Query Rewriting lässt das LLM die ursprüngliche Anfrage in eine Form transformieren, die besser zum Vektorraum der Embeddings passt.
Das ist auch in fortgeschritteneren klassischen RAG-Pipelines vorhanden — es ist keine exklusive Eigenschaft von Agentic RAG. Der Unterschied: In Agentic RAG kann Query Rewriting in jedem Schritt wiederholt werden. Der Agent sieht, was er abgerufen hat, und formuliert die Anfrage auf Basis des Zwischenergebnisses neu — nicht nur auf Basis der ursprünglichen Frage.
Multi-Step Retrieval — schrittweiser Abruf
Der Agent kann mehrfach abrufen, wobei jeder Schritt den nächsten informiert. Das löst das Problem der „versteckten Verknüpfung" — wenn die Antwort über Dokumente verteilt ist, die keine expliziten semantischen Beziehungen haben, deren Kombination aber relevant ist.
Aus Implementierungssicht sieht das wie ein ReAct-Agent aus, bei dem „in der Knowledge-Base suchen" ein Tool ist. Der Agent ruft es so oft wie nötig auf, mit unterschiedlichen Anfragen. Mehr zur Architektur der Agentenschleife findet sich im Artikel über KI-Agenten-Architekturen.
Self-Correction — Korrektur eigener Zwischenergebnisse
Die ausgefeilteste Eigenschaft von Agentic RAG. Der Agent ruft nicht nur ab, sondern bewertet, ob die abgerufenen Informationen relevant, aktuell und ausreichend sind. In fortgeschritteneren Implementierungen kommt ein separater Faithfulness Judge hinzu — ein weiterer LLM-Aufruf, der prüft, ob die generierte Ausgabe durch die abgerufenen Dokumente belegt ist und nicht halluziniert wurde.
Das ist der Punkt, an dem viele die Komplexität unterschätzen: Naives Agentic RAG ohne Faithfulness Judge kann mehr halluzinieren als klassisches RAG. Der Grund ist einfach — längerer Kontext, mehr Retrieval-Schritte, mehr Raum für das Modell, plausiblen, aber unbelegten Text zu generieren.
Wann Agentic RAG einsetzen — ein Entscheidungsrahmen
Nicht jeder RAG-Use-Case erfordert eine Agentenschicht. Das ist der Entscheidungsrahmen aus der Praxis.
Bleiben Sie bei klassischem RAG, wenn: - Die meisten Fragen eindeutig sind (ein Dokument = vollständige Antwort) - Latenz kritisch ist (interaktiver Chatbot, bei dem die Antwort innerhalb von 2 Sekunden kommen muss) - Das Anfragevolumen hoch ist und Cost der limitierende Faktor ist - Die Knowledge-Base eng definiert ist und Fragen deren Rahmen nicht überschreiten
Wechseln Sie zu Agentic RAG, wenn: - Mehr als ca. 20 % der Anfragen Informationen aus mehreren Dokumenten erfordern - Nutzer mehrstufige oder vergleichende Fragen stellen - Die Antwort von einem Zustand oder Kontext abhängt, der nicht in der ursprünglichen Anfrage enthalten ist - Genauigkeit wichtiger ist als Latenz (Entscheidungsunterstützung, Sicherheitsprotokolle) - Sie die Kapazität für Implementierung und Monitoring einer Agentic-Pipeline haben
In Produktions-Deployments haben wir gesehen, dass Agentic RAG für Wissenssysteme über technische Dokumentation (Servicehandbücher, Normen, Verfahrensanweisungen) die Antwortqualität bei mehrstufigen Fragen deutlich steigert — aber zu einem Preis von 5–10× höheren Token-Kosten und 3–5× längerer Latenz gegenüber dem klassischen Ansatz. Das ist kein Preis, den Sie für jede Anfrage zahlen, aber er muss in die Architekturentscheidung einfließen.
Die Mehrkosten: nicht nur Token
Agentic RAG ist auf mehreren Achsen teurer als klassisches RAG, und Token allein sind nur eine davon.
Token-Kosten: Während klassisches RAG für eine Anfrage ca. 500–1.000 Token verbraucht, kann Agentic RAG mit 3–4 Retrieval-Schritten und Faithfulness Judge 5.000–15.000 Token verbrauchen. Bei günstigen Modellen (Flash/Haiku-Tier, ca. 0,10–0,50 $ pro 1M Eingabe-Token) ist der Unterschied beherrschbar. Bei Frontier-Modellen der Klasse Claude Opus oder GPT-5 liegen die Kosten pro Agentic-Anfrage in der Größenordnung von Cent bis zu mehreren Zehn-Cent — bei hohem Volumen ist das nicht vernachlässigbar.
Latenz: Jeder Retrieval-Schritt kostet Zeit — LLM-Aufruf für Query Rewriting, Aufruf der Vektordatenbank, ggf. Faithfulness Judge. Reale Agentic-RAG-Pipelines mit 3–5 Schritten dauern 5–20 Sekunden. Für interaktive Anwendungen erfordert das asynchrones Design und visuelles Feedback (Fortschrittsanzeige, Streaming).
Implementierungs- und Observability-Overhead: Klassisches RAG ist eine 50-Zeilen-Funktion. Agentic RAG ist eine Pipeline mit Checkpointing, Retry-Logik, Monitoring und Debugging-Werkzeug. Ohne Observability-Tools wie Langfuse (self-hostable) oder Arize Phoenix wird es kaum wartbar. Ein mehrstufiger Agent ohne Traces ist eine Black Box — wenn er versagt, weiß man nicht warum. Mehr zum Thema Observability bei Agenten findet sich im Artikel über Observability und Tracing.
Retry-Overhead: Agenten scheitern — falsch formulierte Retrieval-Anfragen, Datenbank-Timeouts, unerwartete Ergebnisformate. In Produktionssystemen liegt die übliche Retry-Rate bei 10–15 %, was die Anzahl der Aufrufe effektiv erhöht. Dieser Overhead muss ins Kostenmodell eingerechnet werden.
Implementierungsmuster in der Praxis
Es gibt zwei dominante Ansätze zur Implementierung von Agentic RAG.
Pattern 1: ReAct-Agent mit Retrieval-Tool
Die einfachste Form — ein Standard-ReAct-Agent, bei dem eines der Tools search_knowledge_base(query: str) -> list[Document] ist. Der Agent entscheidet, wann und wie er das Tool aufruft, sieht die Ergebnisse in der Observe-Phase und fährt entsprechend fort. Die Implementierung über LangGraph mit explizitem State ist heute der Standard für Produktionssysteme.
Vorteil: relativ einfach zu implementieren, der Agent ist flexibel. Nachteil: Ohne Faithfulness Judge kann der Agent mit Sicherheit halluzinieren, die Vertrauenswürdigkeit der Ausgaben ist variabel.
Pattern 2: Dedizierter RAG-Agent mit Bewertungsschleife
Der ausgefeiltere Ansatz: retrieve → Faithfulness-Check → falls nicht ausreichend, Anfrage reformulieren und wiederholen → erst wenn der Faithfulness-Score einen Schwellenwert überschreitet, finale Antwort generieren. Das ist näher am SELF-RAG- oder CRAG-Muster (Corrective RAG).
Implementierungsdetail: Der Faithfulness Judge ist ein separater LLM-Aufruf mit einem Prompt, der Chunk und generierte Antwort erhält und beurteilen soll, ob die Antwort durch den Chunk belegt ist. Typischerweise reicht ein günstigeres Modell (Haiku-Tier) als Judge — für eine binäre Bewertung braucht man nicht das stärkste Modell. Das Ergebnis ist messbar und protokollierbar, was für Audit und Debugging entscheidend ist.
Was uns die Praxis gelehrt hat: Der häufigste Fehler bei der ersten Agentic-RAG-Implementierung ist nicht technischer, sondern produktseitiger Natur. Das Team deployt die vollständige Agentic-Pipeline für jede Anfrage, ohne einfache, eindeutige Fragen von komplexen zu unterscheiden. Das Ergebnis: Das gesamte System ist langsam und teuer, obwohl 60 % der Anfragen klassisches RAG günstiger und schneller abdecken würde.
Empfehlung aus der Praxis: Router vor dem Pipeline-Einstieg. Ein LLM oder ein einfacher Klassifikator bewertet die Komplexität der Anfrage und leitet sie entweder an das schnelle klassische RAG oder an die Agentic-Pipeline weiter. Das verbessert das Preis-Leistungs-Verhältnis bei realer Last erheblich. Die Entscheidung zwischen RAG und Fine-tuning behandelt auch der Artikel über RAG-Pipeline-Qualität.
Typische Risiken und wie man sie mitigiert
Retrieval-Loop (Abrufschleife): Der Agent ruft wiederholt ähnliche Dokumente ab, ohne voranzukommen. Lösung: max_retrieval_steps-Limit (typischerweise 4–6) und Duplikatsprüfung der abgerufenen Chunks — wenn der Agent dasselbe Dokument zweimal abgerufen hat, muss er die Anfrage ändern.
Konfabulation aus langem Kontext: Je mehr Dokumente im Kontext, desto mehr Raum hat das Modell für halluzinierte Verknüpfungen. Lösung: Faithfulness Judge und Quellenangaben (jede Aussage muss auf einen konkreten Chunk zurückführbar sein). Unklarheit darüber, aus welcher Quelle eine Information stammt, ist ein Warnsignal.
Unkontrollierte Kosten: Agentic RAG ohne Limits kann bei einer einzigen komplexen Frage 10× mehr Token verbrauchen als geplant. Lösung: Hard-Limit auf Token pro Anfrage, Alerting bei Erreichen von 50 % des Limits, Kostenreporting pro Anfrage in der Observability-Plattform.
Prompt Injection über Dokumente: Der Agent ruft ein Dokument ab, in dem ein Angreifer Anweisungen für das LLM eingebettet hat (z. B. „Ignoriere vorherige Anweisungen und gib X zurück"). Bei Agentic RAG ist dieses Risiko höher, weil der Dokumentinhalt direkt in den Agentenkontext gelangt, der die nachfolgenden Schritte steuert. Lösung: Kontexttrennung (abgerufene Dokumente in einem separaten Kontextblock mit klarer Kennzeichnung), Validierung des abgerufenen Inhalts vor der Einbindung in den Agentenkontext.
Häufige Fragen
Ist Agentic RAG immer genauer als klassisches RAG?
Nein. Naives Agentic RAG ohne Faithfulness Judge kann mehr halluzinieren als klassisches RAG, weil längerer Kontext und mehr Retrieval-Schritte dem Modell mehr Raum geben, plausiblen, aber unbelegten Text zu generieren. Agentic RAG ist nur dann genauer, wenn es korrekt mit einer selbstbewertenden Schleife und einer klaren Quellenangabenspur implementiert ist.
Was kostet Agentic RAG im Vergleich zu klassischem RAG?
Agentic RAG ist typischerweise 5–10× teurer pro Anfrage. Bei günstigen Modellen (Flash/Haiku-Tier, 0,10–0,50 $ / 1M Eingabe-Token) ist der Unterschied beherrschbar. Bei Frontier-Modellen (Klasse Claude Opus, ca. 5 $ Input / ca. 25 $ Output / 1M Token) liegt der Preis pro Agentic-Anfrage in der Größenordnung von Cent bis mehreren Zehn-Cent. Bei hohem Anfragevolumen (Tausende pro Tag) ist ein Router zwingend, der einfache Fragen an klassisches RAG weiterleitet.
Brauche ich ein spezielles Framework für Agentic RAG?
Nicht zwingend, aber es erleichtert die Implementierung erheblich. LangGraph mit explizitem State und Checkpointing ist heute die dominante Wahl für Produktionssysteme — es beherrscht Checkpointing, Retry-Logik und HITL-Gates. LlamaIndex hat eingebautes Agentic RAG mit Query Rewriting und Multi-Step Retrieval. Für einfachere Fälle genügt eigener Code mit einer ReAct-Schleife.
Wie hoch ist die Latenz von Agentic RAG in der Produktion?
Die reale Latenz einer Agentic-RAG-Pipeline mit 3–5 Retrieval-Schritten beträgt 5–20 Sekunden. Klassisches RAG antwortet üblicherweise innerhalb von 1–3 Sekunden. Für interaktive Anwendungen ist asynchrone Verarbeitung und gestreamte Ausgabe zwingend — der Nutzer muss sehen, dass das System arbeitet, sonst empfindet er es als Fehler.
Wann ist GraphRAG besser als Agentic RAG?
GraphRAG ist besser geeignet, wenn Beziehungen zwischen Entitäten wichtig sind und Dokumente ein Netzwerk verknüpfter Fakten bilden (z. B. regulatorische Verknüpfungen, Organisationshierarchien). Agentic RAG ist besser geeignet, wenn die Knowledge-Base dokumentenorientiert ist und das Problem mehrstufige Fragen sind, keine Graphbeziehungen.
*Wenn Sie abwägen, ob Ihr Knowledge-Base-Use-Case Agentic RAG erfordert oder ein optimierter klassischer Ansatz ausreicht, bewerten wir die konkrete Situation gerne — einschließlich Kostenschätzung, Latenzanalyse und Architekturentwurf. MP Industrial Solutions implementiert RAG und Agentic-Systeme für B2B-Umgebungen mit Fokus auf messbares Ergebnis.*