Agentisches RAG

Was ist Agentisches RAG?

Agentisches RAG ist Retrieval-Augmented Generation, bei der ein KI-Agent den Retrieval-Prozess steuert. Statt vor der Antwort eine einzige feste Suche auszuführen, entscheidet der Agent, ob überhaupt abgerufen werden soll, wählt zwischen Quellen, formuliert Anfragen neu, bewertet die Ergebnisse und sucht erneut, bis genügend Evidenz für eine gute Antwort vorliegt.

Die wichtigsten Punkte

• Klassisches RAG ist eine Pipeline; agentisches RAG ist eine Schleife. Der Agent kann es erneut versuchen, umformulieren und die Quelle wechseln, wenn der erste Abruf danebengeht — genau dort liegen die meisten Qualitätsprobleme von Pipeline-RAG.
• Der Agent bewertet seine eigene Evidenz. Ein Prüfschritt, der fragt "beantwortet das die Frage wirklich?", bevor generiert wird, ist der größte Qualitätshebel.
• Mehrere Quellen werden zu Tools. Vektorsuche, Keyword-Suche, SQL, Websuche und APIs stehen hinter Tool Calling, und der Agent leitet jede Frage an die richtige Quelle weiter.
• Jede zusätzliche Abrufrunde erhöht Latenz und Kosten, weshalb Produktionssysteme Iterationen begrenzen und die volle Schleife den Fragen vorbehalten, die sie wirklich brauchen.

So funktioniert es

Klassisches Retrieval-Augmented Generation embeddet die Frage des Nutzers, holt die Top-k-Chunks aus einer Vektordatenbank, stopft sie in den Prompt und generiert. Das funktioniert, wenn Fragen wohlgeformt sind und die Antwort an einer Stelle steht. Es scheitert bei vagen Fragen, Multi-Hop-Fragen, deren Antwort sich über mehrere Dokumente erstreckt, und Fragen, die ganz anders formuliert sind als der Quelltext. Selbst die einfache Pipeline hat noch Luft nach oben, bevor überhaupt ein Agent ins Spiel kommt: Anthropic fand 2024 heraus, dass Contextual Retrieval — das Voranstellen chunk-spezifischen Kontexts vor dem Embedding — die Fehlerquote beim Abruf der Top-20-Chunks um 49 % senkte, von 5,7 % auf 2,9 % [1].

Agentisches RAG verpackt den Abruf in eine Agentenschleife, meist in Form eines ReAct-Agenten. Der Agent entscheidet zunächst, ob überhaupt ein Abruf nötig ist, denn manche Fragen lassen sich direkt beantworten, und manche brauchen eher einen Taschenrechner als ein Korpus. Diese Entscheidung dem Modell zu überlassen, zahlt sich aus: In den Experimenten von Google Research hob ReAct mit Chain-of-Thought-Suche über eine Wikipedia-API den HotpotQA-Exact-Match auf 35,1 gegenüber 28,7 bei Standard-Prompting [2]. Wenn er abruft, schreibt er eigene Suchanfragen und zerlegt eine komplexe Frage oft in mehrere gezielte Teilfragen. Nach jedem Abruf bewertet er die Ergebnisse auf Relevanz und Hinlänglichkeit. Schwache Ergebnisse lösen eine Neuformulierung mit anderer Wortwahl, eine geänderte Filterung oder einen kompletten Quellenwechsel aus — etwa von semantischer Suche zu Keyword-Suche für einen exakten Fehlercode, oder hinaus zur Websuche für alles Aktuelle. Erst wenn die Evidenz seine eigene Messlatte besteht, generiert der Agent, typischerweise mit Zitaten zurück zu den abgerufenen Passagen, was auch KI-Halluzination weniger Raum gibt, weil Aussagen gegen gesammelte Evidenz geprüft werden.

Die Architektur reicht von einem einzelnen Agenten mit mehreren Retrieval-Tools bis zu einem kleinen Multi-Agenten-System mit einem Router vor quellenspezifischen Spezialisten. Die Einzelagenten-Version deckt die meisten realen Workloads ab und lässt sich weit leichter debuggen.

Beispiel

Ein Enterprise-Support-Assistent beantwortet: "Warum könnten SSO-Logins nach unserem Upgrade auf Version 12.4 fehlschlagen?" Pipeline-RAG embeddet den ganzen Satz, ruft generische SSO-Troubleshooting-Chunks ab und produziert eine Standardantwort. Die agentische Version zerlegt die Frage: Sie fragt den Release-Notes-Index nach "12.4 SSO-Änderungen" ab und findet, dass sich die SAML-Zertifikatsbehandlung geändert hat, durchsucht dann die Support-Wissensdatenbank nach dem konkreten Fehlermuster, bewertet die erste Charge als zu allgemein und läuft erneut mit dem exakten Konfigurationsschlüsselnamen aus der Release Note. Sie zieht zudem über ein API-Tool die Plan-Stufe des Kunden, um zu bestätigen, dass das Feature zutrifft. Die endgültige Antwort zitiert die Release Note, benennt die Konfigurationsänderung und verlinkt den Migrationsleitfaden. Drei Abrufe und ein API-Aufruf, jeder geformt von dem, was der vorherige Schritt zurückgab.

Häufige Missverständnisse

Teams greifen zu agentischem RAG, um eine schlechte Wissensbasis zu retten, und das gelingt nicht. Wenn Dokumente veraltet, schlecht zerlegt oder schlicht nicht vorhanden sind, durchsucht ein Agent einfach öfter denselben Wirrwarr, zu höheren Kosten und mit höherer Latenz, und generiert dann aus derselben schwachen Evidenz. Die Grundlagen der Retrieval-Qualität kommen zuerst: saubere und aktuelle Inhalte, sinnvolles Chunking, gute Embeddings und solides Ranking. Diese Basics bewegen die Zahlen bereits erheblich von allein; Anthropic maß, dass Contextual Retrieval kombiniert mit Reranking die Abruf-Fehlerquote um 67 % senkte, von 5,7 % auf 1,9 % [3]. Die Agentenschicht vervielfacht den Wert eines bereits funktionierenden Retrieval-Systems; sie kann keine Substanz liefern, die im Korpus nicht vorhanden ist.

FAQ

Wann lohnt sich agentisches RAG gegenüber Standard-RAG? Wenn Fragen komplex, mehrstufig oder über heterogene Quellen verteilt sind, und wenn Antwortqualität wichtiger ist als ein oder zwei Sekunden Latenz. Für hochvolumige einfache Lookups bleibt Pipeline-RAG die richtige Standardwahl, und viele Systeme routen je nach Fragekomplexität zwischen beiden.

Ist agentisches RAG dasselbe wie ein Agent mit Such-Tool? Fast. Agentisches RAG benennt die Disziplin rund um diesen Aufbau: abgerufene Evidenz bewerten, gescheiterte Anfragen umformulieren, über Quellen hinweg routen und die finale Antwort in Zitaten verankern. Ein Agent mit Such-Tool ohne Evidenz-Disziplin liefert die Kosten der Schleife ohne die Qualitätsgewinne.

Wie evaluiert man ein agentisches RAG-System? In zwei Schichten. Retrieval-Evals messen, ob die richtigen Passagen gefunden werden; End-to-End-Evals messen, ob finale Antworten treu, vollständig und korrekt zitiert sind, oft bewertet von einem LLM as a Judge gegen ein kuratiertes Fragenset. Nachzuverfolgen, welche Abrufe in welche Antwort eingeflossen sind, macht Fehler diagnostizierbar.

Quellen

1. Anthropic. "Contextual Retrieval senkt die Fehlerquote beim Abruf der Top-20-Chunks um 49 %, von 5,7 % auf 2,9 %." https://www.anthropic.com/news/contextual-retrieval. Abgerufen im August 2026.
2. Google Research. "ReAct plus Chain-of-Thought über eine Wikipedia-API hebt den HotpotQA-Exact-Match auf 35,1 gegenüber 28,7 bei Standard-Prompting." https://research.google/blog/react-synergizing-reasoning-and-acting-in-language-models/. Abgerufen im August 2026.
3. Anthropic. "Contextual Retrieval plus Reranking senkt die Abruf-Fehlerquote um 67 %, von 5,7 % auf 1,9 %." https://www.anthropic.com/news/contextual-retrieval. Abgerufen im August 2026.