Agentic RAG: Wann sich der autonome Retrieval-Agent lohnt

Wenn der Chatbot selbstbewusst die falsche Toleranzklasse nennt

Ein Konstrukteur fragt den firmeneigenen Doku-Assistenten: „Welche Allgemeintoleranz gilt nach ISO 2768 für eine Bohrung mit 45 Millimeter Nennmaß in Toleranzklasse mittel, und ist das mit unseren IATF-16949-Vorgaben vereinbar?" Der Bot antwortet flüssig, in drei Sätzen, mit einer konkreten Zahl. Klingt überzeugend. Ist falsch.

Das Problem liegt in der Struktur der Frage. Sie hat zwei Stufen: erst die Tabelle aus der Norm korrekt lesen, dann das Ergebnis gegen ein zweites Regelwerk prüfen. Ein klassisches RAG-System holt einen Textschnipsel, der irgendwie nach „ISO 2768" aussieht, und generiert daraus eine Antwort. Dass es die Tabelle nie wirklich erfasst hat und die zweite Stufe der Frage offenbleibt, fällt dem System nicht auf. Eine Selbstprüfung gibt es nicht.

Genau hier setzt Agentic RAG an. Und genau diese Art von Frage, mehrstufig und regelgebunden und im Fehlerfall teuer, entscheidet darüber, ob sich der Aufwand lohnt.

Was Agentic RAG eigentlich ist

Bei klassischem RAG über eine Wissensdatenbank läuft eine feste Kette ab: Frage rein, ein Vektor-Lookup, gefundene Textstücke an das Sprachmodell anhängen, Antwort raus. Eine Suche, eine Antwort.

Agentic RAG dreht das Prinzip um. Mitten in der Pipeline sitzt ein autonomer LLM-Agent, der die Aufgabe koordiniert. Statt nur zu suchen, geht er vor wie ein Projektmanager: Er liest die Absicht hinter der Frage, zerlegt sie in Teilschritte, greift zum passenden Werkzeug und prüft jedes Zwischenergebnis. Manche nennen diese Variante auch agentisches oder agentenbasiertes RAG. Gemeint ist dasselbe.

Dahinter steckt ein anderer Umgang mit der Frage. Das System spuckt nicht mehr eine fertige Antwort aus, sondern arbeitet an der Aufgabe, bis das Ergebnis gut genug ist oder ein Abbruchkriterium greift. Diese Idee teilt es mit anderen Formen von Agentic AI im Vergleich zur klassischen Automatisierung: Ein Agent trifft Entscheidungen im Prozess, statt einem fest verdrahteten Ablauf zu folgen.

Warum klassisches RAG bei der zweiten Rückfrage scheitert

Der Unterschied steckt nicht im Modell, sondern im Prozess.

Klassisches RAG ist „one-and-done": ein linearer Durchlauf von Suche, Anreicherung und Generierung. Das System führt stur aus, was die Pipeline vorgibt, und vergisst nach jedem Durchlauf alles wieder. Stellt man eine Folgefrage, die auf dem vorigen Schritt aufbaut, fängt es bei null an.

Agentisches RAG arbeitet iterativ. Es hält einen Zustand über die Schleifen hinweg und kann auf Zwischenergebnisse zurückgreifen. Fehlt eine Information, fordert der Agent sie gezielt nach, statt mit dem zu antworten, was zufällig im Index lag. Und es beherrscht mehrstufige Inferenz, also das Kombinieren mehrerer Dokumente zu einer Antwort. Daran scheitern naive Systeme regelmäßig.

Auch die Werkzeugbasis unterscheidet sich. Klassisches RAG zieht meist aus einer einzigen Quelle, dem Vektor-Index. Ein agentisches System hat mehr zur Auswahl: Vektor-Datenbank, SQL-Abfragen, Websuche, externe APIs, einen Taschenrechner, bei Bedarf auch Wissensgraphen. Es wählt situativ.

Was kostet dieser Unterschied? Hier ist Vorsicht geboten, denn belastbare Branchen-Benchmarks gibt es kaum. Die folgenden Werte stammen aus der Praxis- und Anbieter-Literatur und sind Schätzungen, keine harten Messungen:

• Klassisches RAG: günstiger, Latenz oft unter 2 Sekunden, dafür Genauigkeit grob im Bereich von 60 bis 75 Prozent.
• Agentic RAG: je nach Quelle Faktor 2 bis 3 teurer pro Anfrage, Latenz eher bei 4 bis 6 Sekunden, dafür Qualität grob im Bereich von 85 bis 95 Prozent.

Die agentische Schleife, Schritt für Schritt

Das Herzstück ist ein zyklischer Graph, technisch oft mit einem Framework wie LangGraph umgesetzt. Sechs Phasen greifen ineinander.

1. Query-Planung und Dekonstruktion

Ein Planungs-Agent analysiert die Absicht und zerlegt eine komplexe Frage in granulare Unteraufgaben. Aus „Welche Toleranz gilt und ist sie konform?" werden zwei klar getrennte Teilaufgaben. Das ist die Grundlage dafür, dass die zweite Stufe später nicht untergeht.

2. Routing zum richtigen Werkzeug

Ein Router entscheidet dynamisch, welche Quelle oder welches Tool passt. In der Praxis bewährt sich ein hybrider Vorschalt-Router: Einfache Faktfragen gehen direkt an das günstige Standard-RAG, komplexe Vergleichs- und Synthesefragen an den teureren Multi-Agent-Pfad. Anbieter berichten, dass dieses Vorsortieren grob 30 bis 50 Prozent der Kosten spart. Mein Rat: Diesen Router niemals weglassen.

3. Dynamisches Retrieval und Tool-Nutzung

Keine einzelne Suche, sondern gezieltes Nachfordern. Der Agent erkennt, welche Information noch fehlt, und holt sie. Die Werkzeuge reichen von der Vektor-DB über Websuche (etwa via Tavily oder Google) und APIs bis zum Taschenrechner für Mathematik. Besonders relevant im technischen Umfeld sind Vision-Modelle, die Tabellen und Zeichnungen in PDFs lesen. Diese Multimodalität ist oft der eigentliche Grund, überhaupt agentisch zu bauen.

4. Reflexion und Grading

Jetzt prüft sich das System selbst. Drei Bewertungen laufen ab. Das Document Grading fragt, ob die abgerufenen Dokumente überhaupt relevant sind. Der Halluzinations-Check fragt, ob die Antwort faktisch durch die Quellen gestützt wird. Und das Answer Grading fragt, ob die Antwort die Frage vollständig und nützlich beantwortet.

5. Re-Retrieval und Query-Rewriting

Reichen die Belege nicht, formuliert das System die Suchanfrage um und startet eine neue Schleife. Ein Evidence-Agent entscheidet, ob die gesammelten Belege ausreichen, und schickt die Frage andernfalls zurück an den Rewriter. Diese Rückkopplung ist der eigentliche Mechanismus, der bei naivem RAG fehlt.

6. Stop-Kriterium

Irgendwann muss Schluss sein. Die Schleife endet, wenn die Antwortqualität ausreicht, das Ziel erfüllt ist oder eine maximale Iterationszahl erreicht wird. Dieser Schleifenzähler ist keine Nebensache, denn er verhindert, dass der Agent endlos kreist.

Wer tiefer in die Koordination solcher Abläufe einsteigen will, findet in unserem Beitrag zu Multi-Agent-Systemen die Rollenverteilung im Detail.

CRAG und Self-RAG: zwei Verfahren, die sich ergänzen

Zwei benannte Ansätze prägen die Forschung: Corrective RAG (CRAG, Yan et al., 2024) und Self-RAG (Asai et al., 2023). Sie lösen unterschiedliche Probleme.

CRAG stellt der Generierung eine Qualitätsprüfung voran. Ein leichtgewichtiger Evaluator, oft ein feinabgestimmtes kleines T5-Large-Modell, bewertet die Relevanz der abgerufenen Dokumente und sortiert sie auf drei Pfade. Bei „Correct" werden die Dokumente nach dem Decompose-then-Recompose-Prinzip in sogenannte Knowledge Strips zerlegt, kurze Einheiten von etwa drei Sätzen; irrelevante Strips fliegen raus, der Rest wird neu zusammengesetzt. Bei „Incorrect" verwirft das System die lokalen Daten ganz und weicht auf eine großflächige Websuche aus (Google, Tavily, Wikipedia). Bei „Ambiguous" kombiniert es gefilterte lokale Strips mit einer ergänzenden Websuche.

Self-RAG geht anders vor und steuert den Inferenzfluss über vier Klassen von Reflexionstoken: Retrieve (ist ein externer Abruf überhaupt nötig?), IsRel (Relevanz), IsSup (faktische Stützung, also der Halluzinations-Check) und IsUse (Nutzen). Das Modell entscheidet während des Generierens, wann es nachschlägt und wie stark es das Gefundene gewichtet.

Was ich Kunden dazu gern sage: Die beiden konkurrieren nicht, sie ergänzen sich. CRAG verbessert die Qualität der Belege, Self-RAG das Schlussfolgern über sie.

Vier Bauformen: Router, Hierarchie, Multi-Agent, State-Graph

Es gibt nicht „die eine" Architektur. In der Praxis treffe ich auf vier Muster, oft in Kombination.

Der Single-Agent-Router ist die schlankste Form. Ein vorgeschalteter Router wählt Quelle oder Tool und schickt triviale Fragen direkt an Standard-RAG, um Kosten zu sparen. Ein guter Einstiegspunkt.

Das hierarchische Muster setzt einen Meta-Agenten über spezialisierte Sub-Agenten. Ein verbreiteter Zuschnitt ist ein Agent pro Dokument. Bei LlamaIndex etwa bekommt jedes Dokument einen Doc-Agenten mit Embedding-Suche und Zusammenfassungsfunktion, während ein übergeordneter Meta-Agent das Tool-Retrieval und die Chain-of-Thought-Logik übernimmt.

Das Multi-Agent-Muster verteilt die Rollen auf mehrere Spezialisten: Query-Planung, Routing, Tool-Nutzung, Evidence-Check, Rewriting und finale Antwort. Mehr Spezialisierung bedeutet hier auch mehr Koordinationsaufwand.

Die zustandsbehafteten Graphen schließlich, also State Machines, wie LangGraph sie modelliert, sind die technische Grundlage für die zyklischen Workflows. Sie halten den Zustand über die Schleifen, was die iterative Selbstkorrektur überhaupt erst möglich macht.

Wer mit dem Thema startet, dem empfehle ich unseren Einstieg zu KI-Agenten für den Mittelstand, bevor man die schwerste Bauform wählt.

Wo das im Mittelstand wirklich Geld bringt

Wo zahlt sich der Aufwand konkret aus? Ein paar Szenarien, die mir in der Literatur und in eigenen Projekten immer wieder begegnen.

Im Kundensupport kann ein agentisches System transaktionale Bestelldaten über eine API einsehen, proaktiv eine Lösung wie Ersatzlieferung oder Rabatt vorschlagen und bei Bedarf an einen Menschen eskalieren. Es bleibt nicht beim Nachschlagen stehen.

Im Finanzwesen geht es um Umsatztrend-Analysen, Mehrperioden-Prognosen und Compliance-Monitoring. In Business Intelligence und Reporting um KPI-Abfragen, die über Silogrenzen hinweggehen und Daten aus mehreren Systemen kombinieren.

Im Engineering und in der QA liegt für mich der stärkste Anwendungsfall im Maschinenbau. Normfragen sind selten einstufig: ISO-2768-Toleranzklassen, der Unterschied zwischen DIN EN ISO 9001 und IATF 16949, dazu Tabellen und Zeichnungen, die nur multimodal korrekt erfasst werden. Genau hier zahlt sich der Agent aus, weil er die Tabelle wirklich liest und die zweite Regelebene nicht vergisst.

Weitere Felder gibt es reichlich. Im Gesundheitswesen werden aktuelle Studien und Krankengeschichte zu einer evidenzbasierten Therapieempfehlung aggregiert. Im Performance-Marketing diagnostiziert ein Agent einen Ranking-Abfall, indem er Ranking-Daten, Crawl-Logs, Core Web Vitals und Code-Releases korreliert und daraus konkrete Handlungsempfehlungen ableitet. Auch HR nutzt solche Systeme, etwa um Feedback zu synthetisieren und Umfragen auszuwerten.

• Kundensupport: API-Zugriff auf Bestelldaten, proaktive Lösung, saubere Eskalation.
• Finanzen und Compliance: Trendanalyse, Prognose, kontinuierliche Überwachung.
• Engineering und QA: multimodale Normfragen über Tabellen und Zeichnungen.
• Marketing: Ursachenanalyse über mehrere Datenquellen hinweg.

Die Schattenseiten, über die selten jemand spricht

Agentic RAG ist kein Selbstläufer.

Kosten. Jede Anfrage löst eine ganze Reihe LLM-Calls aus, vom Routing über das Grading bis zur Nachsuche und der finalen Generierung. Praxisschätzungen aus der Anbieter-Literatur nennen grob Faktor 2 bis 3 gegenüber Standard-RAG. Belastbare, herstellerunabhängige Benchmarks gibt es dafür nicht. Bei hohem Volumen ist das trotzdem ein ernster Posten.

Latenz. Schätzungen aus der Praxis-Literatur zufolge landet man statt unter 2 Sekunden schnell bei 4 bis 6 Sekunden oder mehr. Für ein internes Recherchewerkzeug ist das egal. Für eine Echtzeit-Interaktion am Telefon ist es ein Problem.

Komplexität. Die Orchestrierung von Agenten, Retrieval und generativen Modellen ist anspruchsvoll. Die präzise Parametrisierung ist dabei ein echter Stabilitätsfaktor: Schon deterministisches Routing mit Temperatur 0 und enge Token-Limits entscheiden mit darüber, ob das System rund läuft oder zickt.

Kontextdrift. In langen Schleifen kann sich der Agent von der Ursprungsfrage entfernen. Er sucht und verfeinert weiter und beantwortet am Ende eine andere Frage als die gestellte. Over-Looping nennt sich dieses Muster.

Fehlerfortpflanzung. Agenten können scheitern und um Ressourcen konkurrieren. Schwerer wiegt: Ein früher Routing-Fehler zieht sich durch das ganze System. Wer am Anfang falsch abbiegt, kommt nirgends an. Und selbst das bestabgesicherte RAG schließt Halluzination nicht völlig aus.

Black Box. Ohne Tracing, etwa mit Langfuse oder OpenTelemetry, bleibt im Fehlerfall unklar, welcher Agent versagt hat. Man steht vor einem System, das eine falsche Antwort produziert hat, und weiß nicht, an welcher der sechs Stationen es schiefging.

Meine Einschätzung nach mehreren Agentic-RAG-Projekten: Die Kosten- und Latenzfrage ist meist verkraftbar. Was Projekte wirklich kippt, ist die fehlende Beobachtbarkeit. Wer ein agentisches System ohne Tracing in Produktion schickt, fliegt blind. Dazu kommen die üblichen Themen wie Bias und Fairness, Skalierbarkeit, Datensynchronisation und Token-Limits. Nichts davon ist ein K.-o.-Kriterium. Aber alles will von Anfang an bedacht sein.

Das Entscheidungs-Framework: fünf Fragen vor dem Budget

Bevor irgendjemand ein Budget freigibt, stelle ich fünf Fragen. Sie trennen den sinnvollen Einsatz vom teuren Overkill.

Erstens: Sind die Dokumente reiner Text, oder enthalten sie Tabellen, Zeichnungen und Querverweise? Multimodalität spricht klar für agentisch, reiner Fließtext oft nicht.

Zweitens: Was kostet eine falsche Antwort? Reputationsschaden, Audit-Findings, Produktionsausfälle? Je teurer der Fehler, desto wichtiger das Evidence-Gate.

Drittens: Wie komplex sind die Fragen? Einfache Faktfragen oder mehrstufige Inferenz? Mehrstufig bedeutet Retrieval-Loops, und die gibt es nur agentisch.

Viertens: Wie hoch ist das Query-Volumen? 100 Anfragen am Tag oder 100.000? Bei hohem Volumen kippt der Kosten-Hebel, weil sich Faktor 2 bis 3 mit jeder Anfrage multipliziert.

Fünftens: Gibt es Audit- oder Compliance-Anforderungen? Dann brauchen Sie ohnehin Tracing und Evidenz-Kontrolle.

Und die Kehrseite, ganz konkret. Wann sollten Sie es nicht einsetzen? Bei geringem Query-Volumen, denn eine Anbieter-Schätzung nennt für die Entwicklung grob 55.000 bis 95.000 Euro, was sich unter etwa 1.000 Anfragen pro Monat kaum amortisiert. Bei reinen Textdokumenten ohne Tabellen, wo Standard-RAG schlicht günstiger arbeitet. Bei niedrigem Fehlerrisiko wie einem Marketing-FAQ-Bot, wo der ganze Apparat Overkill ist. Und bei harten Echtzeitanforderungen, bei denen 4 bis 6 Sekunden Latenz nicht durchgehen.

• Volumen unter etwa 1.000 Anfragen pro Monat: Entwicklungskosten amortisieren sich kaum.
• Reine Textdokumente ohne Querverweise: Standard-RAG genügt.
• FAQ-Bot mit geringem Fehlerrisiko: Overkill.
• Echtzeit-Anwendung: Latenz schlägt durch.

Best Practices aus echten Projekten

Wenn die Entscheidung für agentisch fällt, entscheidet die Umsetzung über Erfolg oder Frust. Was sich bewährt hat.

Eval-Set zuerst. Bevor eine Zeile Produktionscode entsteht: 30 bis 100 Referenzfragen mit bekannten Antworten, zusammengetragen von den Fachbereichen Engineering, QA, Service und Compliance. Wichtig ist der Mix. Neben Faktfragen und Vergleichsfragen gehören Grenzfragen dazu, auf die die korrekte Antwort lautet: „Dazu gibt es keine Norm-Aussage." Diese Grenzfragen messen die Ehrlichkeit des Systems. Eine Anbieter-Messung, bitte als Schätzung gelesen und nicht als Benchmark, beziffert die Halluzinationsrate bei solchen Grenzfragen für Standard-RAG auf über 40 Prozent; mit einem Evidence-Gate soll Agentic RAG unter 5 Prozent landen. Die Größenordnung ist plausibel, die exakte Zahl würde ich nie versprechen.

Hybrider Vorschalt-Router. Schon erwähnt, aber es ist der wichtigste Kostenhebel. Kein „Agentic everywhere". Einfache Fragen günstig routen, komplexe teuer.

Observability ab Tag 1. Tracing mit Langfuse oder OpenTelemetry gehört in die erste Iteration und nicht in eine spätere. Sonst stehen Sie irgendwann vor der Black Box.

Dazu eine Handvoll technischer Hebel, die in Summe viel ausmachen: Für Routing und Grading kompakte Modelle nutzen, etwa ein gpt-4.1-mini mit Temperatur 0 für deterministische Routing-Entscheidungen, dazu enge Token-Limits gegen Latenzspitzen. Mathematik über sympy rechnen statt über das LLM. Die Websuche begrenzen, etwa Tavily auf maximal drei Treffer, um Rauschen zu vermeiden. Embeddings normalisieren, zum Beispiel mit BAAI/bge-small-en-v1.5, und ein konstantes top-k in Qdrant fahren, damit Ergebnisse reproduzierbar bleiben. Und die Qualität laufend messen, etwa mit Ragas oder Langfuse-Datasets, eingehängt in die CI/CD.

DSGVO und EU AI Act: die DACH-Governance-Note

Ein Punkt, der im DACH-Mittelstand zu oft hinten runterfällt. Die gute Nachricht zuerst: Agentische Systeme mit Tracing und Evidenz-Kontrolle helfen bei der Nachvollziehbarkeit. Wer für jede Antwort dokumentiert, welche Quelle sie stützt und welcher Agent sie produziert hat, ist bei einem Audit deutlich besser aufgestellt als mit einer undurchsichtigen Pipeline.

Die andere Seite: Mehr Agenten bedeuten mehr Datenflüsse, und jeder dieser Flüsse will DSGVO-konform kontrolliert sein. Stößt ein Agent eine externe Websuche an oder ruft eine fremde API, verlassen unter Umständen Daten Ihre Umgebung. Zweckbindung und Datenminimierung gelten weiter. Dazu kommen die Transparenzpflichten aus dem EU AI Act, etwa Artikel 50 zur Kennzeichnung: Nutzer müssen wissen, dass sie mit einem KI-System interagieren.

Mein Standpunkt: Genau deshalb baue ich solche Systeme bevorzugt DSGVO-konform als Private AI, mit kontrollierten Datenflüssen und nachvollziehbarem Tracing. Die agentische Architektur ist kein Compliance-Risiko an sich. Sie wird eines, wenn man die zusätzlichen Datenflüsse nicht von Anfang an einhegt. Wer den größeren Rahmen sucht, findet im Leitfaden zu KI-Agenten die Governance-Bausteine im Zusammenhang.

Ein agentisches System ist kein Standardprodukt

Es ist ein Engineering-Projekt mit klaren Stellschrauben: Query-Planung, Multi-Backend-Routing, Reflexions-Grading, ein Evidence-Ledger, ein Rewrite-Budget und ein Groundedness-Gate. Genau diese Systeme baue ich, mit Schwerpunkt auf Engineering- und QA-Dokumentation im Maschinenbau und auf compliance-lastigen Vertikalen, wo eine falsche Antwort teuer wird.

Wenn Sie überlegen, ob sich der Aufwand für Ihren Anwendungsfall rechnet, lassen Sie uns die fünf Entscheidungsfragen gemeinsam durchgehen. Fragen Sie Ihr Projekt an. Ich melde mich mit einer ehrlichen Einschätzung, auch wenn die lautet: Für Ihren Fall reicht Standard-RAG.

FAQ

Häufige Fragen