Ein juristischer Kunde fragt den Assistenten: „Welche Risiken bestehen bei der Kündigung eines Vertrags mit einem Subunternehmer aus Deutschland, unter Berücksichtigung unseres Rahmenvertrags, des aktuellen Nachtrags und der Rechtsprechung des letzten Jahres?“ Klassischer RAG führt eine einzige Suche durch, liefert einige Fragmente und generiert eine Antwort. Vielleicht trifft er ins Schwarze, vielleicht nicht. Agentic RAG geht das anders an: Es spielt die Frage in mehreren Zügen durch und prüft nach jedem, ob es bereits genug weiß.
Was sich in der Architektur ändert
#Beim klassischen RAG-Ansatz ist der Ablauf linear und unveränderlich: eine Vektorsuche, k Fragmente im Kontext, eine Generierung. Das funktioniert gut, wenn die Frage präzise ist und die Antwort an einer Stelle in der Wissensbasis liegt.
Agentic RAG ersetzt diesen festen Ablauf durch eine Entscheidungsschleife. Der Agent erhält die Frage, plant eine erste Anfrage, bewertet die zurückgegebenen Fragmente, reformuliert die Anfrage, wenn der Kontext unvollständig oder widersprüchlich ist, ruft eine weitere Datenportion ab und wiederholt dies, bis ein Vertrauensschwellenwert erreicht ist. Erst dann erfolgt die Generierung.
Wesentliche strukturelle Unterschiede, die sich aus dieser Änderung ergeben:
Mehrfache Anfragen. Der Agent kann 3-6 separate Anfragen in einem Antwortzyklus senden. Jede kann eine andere Formulierung, eine andere Suchstrategie (vektorbasiert, hybrides BM25 plus Vektoren, Metadaten) verwenden oder auf eine andere Dokumentensammlung zugreifen.
Bewertung der Suffizienz. Nach jeder Iteration bewertet das Modell, ob die gesammelten Fragmente zur Beantwortung der Frage ausreichen. Das ist keine einfache Schwellenwertregel: Das Modell prüft Konsistenz, Abdeckung und ob ein wesentlicher Aspekt fehlt.
Reformulierung von Anfragen. Wenn die erste Anfrage Fragmente mit zu breitem Umfang liefert, verengt der Agent die Suche. Wenn der Kontext widersprüchlich erscheint, sucht der Agent nach einem entscheidenden Dokument. Das ist ein Reranking und eine Selektion, die aktiv, nicht passiv durchgeführt wird.
Vertrauensgrenze. Wenn der Agent nach der maximalen Anzahl von Iterationen immer noch keinen ausreichenden Kontext gesammelt hat, spekuliert er nicht. Er eskaliert an einen Menschen mit der Information: „Die Frage liegt außerhalb der Abdeckung der Wissensbasis oder erfordert eine Überprüfung durch einen Experten.“
Klassischer RAG vs. Agentic RAG
#| Dimension | Klassischer RAG | Agentic RAG |
|---|---|---|
| Anzahl der Anfragen pro Antwort | 1 | 2-6 (abhängig von der Komplexität) |
| Latenz | 300-800 ms | 2-8 s |
| LLM-Kosten | 1 Aufruf für Generierung | 2-6 Aufrufe für Planung und Generierung |
| Am besten geeignet für | Einfache, faktische Fragen | Komplexe, mehrdimensionale, mehrdeutige Fragen |
| Halluzinationsrisiko | Mittel (kein Kontext = keine Generierung) | Geringer (Iteration reduziert Kontextlücken) |
| Evaluationsschwierigkeit | Mittel | Hoch (viele Suchpfade) |
| Human-Gate | Optional | Erforderlich bei geringem Vertrauen |
Die Latenz- und Kostenangaben sind Spannen aus unseren Beobachtungen in Projekten mit polnischen juristischen und finanziellen Dokumenten, keine Garantien. Die tatsächlichen Werte hängen von der Dokumentenlänge, dem Modell und der Anzahl der Iterationen ab.
Wo Agentic RAG wirklich hilft
#Der agentenbasierte Ansatz macht Sinn, wenn die Frage mindestens eines dieser Merkmale aufweist.
Mehrdimensionalität. Die Frage verbindet Informationen aus verschiedenen Quellen oder unterschiedlichen Zeitpunkten. Klassischer RAG liefert ein Fragment aus einer Stelle; der Agent kombiniert mehrere.
Mehrdeutigkeit. Die Frage ist unklar und erfordert Klärung durch Kontext. Der Agent kann nach dem Hintergrund fragen, ein allgemeines Fragment abrufen und sich dann in Details vertiefen.
Widersprüchliche Informationen in der Datenbank. Wenn Dokumente in der Sammlung Daten aus verschiedenen Daten oder inkonsistente Verfahren enthalten, kann klassischer RAG eine ältere Version liefern. Der Agent iteriert und vergleicht Fragmente, um die aktuelle Version auszuwählen.
Auditierbarkeit des Suchpfads. In Compliance-Anwendungen (Recht, Finanzen, Medizin) ist nicht nur die Antwort wertvoll, sondern auch der Weg dorthin: welche Dokumente geprüft wurden, in welcher Reihenfolge und warum sie ausreichten. Agentic RAG erzeugt diesen Log auf natürliche Weise.
Für einfache lexikalische Fragen, einstufige Produkt-Lookups oder die Navigation durch FAQs ist klassischer RAG günstiger und ausreichend. Es macht keinen Sinn, eine agentenbasierte Architektur dort einzusetzen, wo ein fester Ablauf funktioniert.
Kosten und Evaluationsschwierigkeit
#Agentic RAG ist nicht kostenlos. Drei Hauptkosten, die vor der Implementierung zu beachten sind:
Mehr LLM-Aufrufe. Jede Suchiteration erfordert mindestens einen zusätzlichen Modellaufruf zur Bewertung der Suffizienz und Reformulierung der Anfrage. Bei Cloud-Modellen sind das direkte Token-Kosten. Unser Inference-Rechner auf der Website hilft abzuschätzen, ob sich Self-Hosting für das gegebene Volumen lohnt.
Höhere Latenz. Zwei Sekunden sind eine akzeptable Zeit für einen internen Assistenten im B2B-Umfeld. Für einen Kundenservice-Chat mit Sub-Sekunden-Erwartung erfordert Agentic RAG Pufferung, semantischen Cache oder einen hybriden Modus: Agent für komplexe Fragen, klassischer RAG für einfache.
Schwierigere Evaluation. Beim klassischen RAG haben wir einen Satz von Kontextfragmenten und eine Antwort zur Bewertung. Beim Agentic RAG ist der Suchpfad variabel. Der Golden Set muss nicht nur die endgültige Antwort abdecken, sondern auch die Qualität der Reformulierung und die Entscheidung über die Suffizienz. Bei Cashcrown erstellen wir für diesen Modus separate Golden Sets mit Pfadannotation, was langsamer, aber für eine zuverlässige Messung notwendig ist. Details zur Methodik beschreibt der Artikel über die Evaluation von RAG-Systemen.
Guardrails und Human-Gate: Wo der Agent stoppen muss
#Eine agentenbasierte Schleife ohne Grenzen ist ein operatives Risiko. Drei Guardrails, die wir für obligatorisch halten.
Harte Iterationsgrenze. Der Agent darf nicht endlos suchen. Wir setzen eine Obergrenze (normalerweise 5-7 Iterationen) und behandeln eine Überschreitung als Eskalation, nicht als Ausfall. Der Log enthält die Frage, alle Iterationen und den Eskalationsgrund.
Guardrails gegen Halluzinationen. Vor der Generierung der Antwort prüfen wir, ob jede Aussage, die das Modell treffen will, durch die gesammelten Fragmente gedeckt ist. Eine Aussage ohne Deckung wird entfernt oder markiert. Dieselben Schutzmaßnahmen, die im Artikel über mehrstufige Agenten beschrieben sind, wenden wir hier auf die Suchebene an.
Human-Gate bei geringem Vertrauen. Wenn die Suffizienzbewertung nach allen Iterationen unter dem Akzeptanzschwellenwert liegt, generiert der Agent keine spekulative Antwort. Stattdessen gibt er zurück: „Ich habe nicht genug Dokumente, um sicher zu antworten. Ich leite an einen Experten weiter.“ Dieser Handoff muss den Kontext enthalten: welche Fragen gestellt wurden, was gefunden wurde, was fehlt.
Observability der Schleife ist notwendig, damit diese Guardrails funktionieren. Wir loggen jede Iteration: Vektoranfrage, zurückgegebene Fragmente, Suffizienzbewertung, Entscheidung über Fortsetzung. Ohne diesen Log gibt es keine Möglichkeit, Eskalationsfälle zu debuggen oder den Vertrauensschwellenwert zu kalibrieren.
Implementierung: Vom Pilot zur Produktion
#Ein typischer Pilot für Agentic RAG für einen Prozess in einem B2B-Unternehmen dauert 4-6 Wochen. Die ersten zwei Wochen sind Arbeit mit Daten und Schleifendesign (Chunking-Strategie, Suffizienzschwellenwert, Iterationslimit, Log-Schema). Die dritte und vierte Woche sind Shadow Mode: Der Agent verarbeitet Fragen parallel zu den Antworten des Teams, Abweichungen werden analysiert.
Vor dem produktiven Start erstellen wir einen Golden Set, der spezifisch für Agentic RAG ist: Für jede Frage annotieren wir den erwarteten Suchpfad und die Suffizienzentscheidung, nicht nur die endgültige Antwort. Das ist langsamer als ein Golden Set für klassischen RAG, aber die einzige Methode, die eine Bewertung der Planungsqualität und nicht nur des Ergebnisses ermöglicht. Wie dieser Golden Set im Kontext von Multi-Agenten-Systemen erstellt wird, beschreiben wir separat.
Die Kosten des Piloten hängen von der Komplexität der Wissensbasis und den Annotationsanforderungen ab. Eine ROI-Bewertung der agentenbasierten Implementierung liefert der Inference-Rechner, der die Kosten zusätzlicher LLM-Iterationen berücksichtigt.
FAQ
#Worin unterscheidet sich Agentic RAG von klassischem RAG?
#Klassischer RAG führt einen festen Zyklus durch: eine Vektorsuche, k Fragmente im Kontext, eine Generierung. Agentic RAG ersetzt diesen Ablauf durch eine Schleife: Der Agent plant die Anfrage, bewertet, ob die Ergebnisse ausreichen, reformuliert und iteriert bis zum Vertrauensschwellenwert oder Iterationslimit. Der Unterschied ist architektonisch, nicht nur in der Anzahl der Anfragen: Klassischer RAG kann nicht selbst entscheiden, ob der Kontext ausreicht.
Wann macht Agentic RAG keinen Sinn?
#Bei einfachen, einstufigen faktischen Fragen, Produkt-Lookups, Navigation durch FAQs und überall dort, wo der Nutzer Sub-Sekunden-Antworten erwartet. Agentic RAG lohnt sich bei komplexen, mehrdimensionalen Fragen, bei denen fehlender Kontext zu falschen Antworten führt. Für die meisten internen B2B-Assistenten ist ein hybrider Modus sinnvoll: klassischer RAG für einfache Fragen, Agentic für komplexe, mit einem Router, der den Pfad entscheidet.
Wie bewertet man die Suffizienz des Kontexts in der Agentenschleife?
#Es gibt keine universelle Methode. Praktisch bewähren sich zwei Ansätze: Ein bewertendes Prompt-Modell, das aufgefordert wird, anzugeben, welche Aspekte der Frage durch die gesammelten Fragmente abgedeckt sind, und ein Schwellenwert für die Konsistenz basierend auf der Kosinus-Ähnlichkeit zwischen der Frage und den aggregierten Fragmenten. Bei Cashcrown kalibrieren wir diesen Schwellenwert projektspezifisch auf dem Golden Set, da das optimale Niveau zwischen juristischen, technischen und kommerziellen Wissensbasen variiert.
Löst Agentic RAG das Halluzinationsproblem?
#Teilweise. Iterative Suche reduziert das Risiko, dass das Modell ohne Kontext antwortet, da der Agent mehr und besser passende Fragmente sammelt. Aber sie eliminiert Halluzinationen nicht vollständig: Das Modell kann bei der Antwortgenerierung immer noch über den gesammelten Kontext hinausgehen. Ein Guardrail, der die Deckung jeder Aussage im Kontext prüft, ist weiterhin notwendig, ebenso wie die Option zur Eskalation an einen Menschen bei geringem Vertrauen. Die Architektur dieser Schicht beschreibt der Artikel über Firmen-GPT auf Wissensbasis.
Wie loggt man den Suchpfad für Audit-Zwecke?
#Jede Iteration erzeugt einen Datensatz: Originalfrage, reformulierte Vektoranfrage, zurückgegebene Fragmente (mit Dokumenten-ID und Position), Suffizienzbewertung und Entscheidung über Fortsetzung oder Beendigung. Dieser Log wird in einem separaten Speicher mit RODO-konformer Retention abgelegt. In Anwendungen, die unter den AI Act fallen (Finanzen, Recht, HR), ist der Log ein obligatorischer Bestandteil der Audit-Trail, kein optionaler Debugging-Zusatz.