Pexon Consulting | 10 Min. Lesezeit | 17.05.2026
TL;DR
Agentic RAG erweitert klassisches RAG um spezialisierte Agenten für Kontext, Suche, Evidenzprüfung und Antwortgenerierung – mit Selbstkorrektur bei schwachen Treffern. Pexon Consulting setzt Agentic RAG als Microsoft Partner mit 80 Mitarbeitern aus Deutschland produktiv um. Die Antwortqualität steigt messbar um 20 bis 35 Prozent, die Kosten pro Anfrage steigen allerdings um Faktor 2 bis 3.
Was ist Agentic RAG?
Agentic RAG ist eine Weiterentwicklung von Retrieval-Augmented Generation (RAG), bei der spezialisierte Agenten den Suchprozess aktiv steuern statt ihn nur einmal auszuführen. Die zugrundeliegenden LLMs übernehmen dabei nicht nur die Antwortgenerierung, sondern auch Routing, Bewertung der gefundenen Belege und bei Bedarf eine erneute Suche. Statt eines einzigen starren Retrieval-Schritts entsteht so eine Schleife aus Suchen, Prüfen und Nachbessern, bis die Evidenz für eine verlässliche Antwort ausreicht – die KI liefert also nicht die erstbeste, sondern die belastbarste Antwort.
Der Unterschied zu klassischem RAG liegt damit nicht im Sprachmodell selbst, sondern in der Orchestrierung mehrerer Agenten um dieses Modell herum. In unseren eigenen Projekten zeigt sich dieser Unterschied direkt in Zahlen: Über acht Kundenprojekte hinweg liegt die Antwortqualität von Agentic-RAG-Systemen bei 91 Prozent bei einer Halluzinationsrate von nur 2 Prozent, deutlich vor klassischem RAG mit nur einem Retrieval-Schritt (siehe Tabelle oben). Wer noch am Anfang steht und zunächst die Grundlagen braucht, findet sie in unserem Leitfaden RAG-System für Unternehmen aufbauen.
Wann Agentic RAG sich lohnt – und wann nicht
Die kurze Antwort: Agentic RAG lohnt sich, sobald Fehler teuer werden oder Dokumente komplexer sind als reine Textartikel. Für einen FAQ-Chatbot auf der Marketing-Website ist es Overkill.
Die längere Antwort haben wir in ein einfaches Entscheidungs-Framework gepackt, das wir in jedem RAG-Projekt mit unseren Kunden am Anfang durchgehen:
- Sind die Dokumente rein textbasiert oder enthalten sie Tabellen, Zeichnungen, Querverweise? → Bei Multimodalität ist Agentic RAG Pflicht.
- Was kostet eine falsche Antwort? Reputation, Audit-Findings, Produktionsausfälle? → Je höher der Schaden, desto wichtiger das Evidence-Gate.
- Wie komplex sind die Fragen? Faktfragen oder mehrstufige Inferenz? → Mehrstufige Fragen brauchen mehrstufige Retrieval-Loops.
- Wie groß ist das Query-Volumen? 100 pro Tag oder 100.000? → Bei hohem Volumen kippt der Kosten-Hebel schneller.
- Gibt es Audit- oder Compliance-Anforderungen? → Ohne Tracing und Evidenz-Kontrolle ist Compliance schwierig.
Unsere klare Empfehlung: Bei mindestens zwei „Ja“-Antworten auf diese fünf Fragen lohnt sich Agentic RAG. Bei keiner oder einer ist Standard RAG der wirtschaftlichere Weg. Die Versuchung, „direkt das Beste“ zu bauen, endet in unseren Projekten regelmäßig mit einer überengineerten Pipeline, deren Betrieb später niemand bezahlen will.
Was Multi-Agent-Orchestrierung konkret bedeutet
Ein Agentic-RAG-System ist kein einzelnes Modell mit mehr Prompts. Es ist eine Orchestrierung mehrerer spezialisierter Agenten, die jeweils eine klar definierte Rolle haben und über einen Zustandsgraphen kommunizieren.
In unseren Projekten setzen wir in der Regel LangGraph ein, weil es sich gut mit bestehenden LangChain-Komponenten verbindet und einen expliziten State bietet. Der Kern-Graph sieht im Minimum so aus:
from langgraph.graph import StateGraph, END
from typing import TypedDict, List
class RAGState(TypedDict):
question: str
rewritten_query: str
docs: List[dict]
evidence_ok: bool
attempts: int
answer: str
graph = StateGraph(RAGState)
# Kontext-Agent: bereitet Frage und Historie auf
graph.add_node("context", context_agent)
# Retrieval-Agent: hybride Suche Vektor + BM25
graph.add_node("retrieve", retrieval_agent)
# Evidenz-Agent: prueft Belastbarkeit
graph.add_node("evaluate", evidence_agent)
# Umformulierer bei schwacher Evidenz
graph.add_node("rewrite", rewrite_agent)
# Antwort-Agent: nur bei ausreichender Evidenz
graph.add_node("answer", answer_agent)
graph.set_entry_point("context")
graph.add_edge("context", "retrieve")
graph.add_edge("retrieve", "evaluate")
# Der entscheidende Teil: bedingte Verzweigung
graph.add_conditional_edges(
"evaluate",
lambda s: "answer" if s["evidence_ok"]
else "rewrite" if s["attempts"] < 3
else "uncertainty",
)
graph.add_edge("rewrite", "retrieve")
graph.add_edge("answer", END)
rag = graph.compile()Der interessante Teil sind nicht die Agenten selbst – die sind oft schmale LLM-Aufrufe mit spezialisierten Prompts. Der Wert entsteht durch die Verzweigung: Der Evidence-Agent entscheidet, ob die Belege reichen, und schickt die Frage bei schwacher Trefferlage an den Rewriter zurück.
In der Praxis ergänzen wir diesen Minimal-Graphen um drei Komponenten: Tool-Aufrufe (z.B. SQL-Query gegen eine Stammdatenbank), Human-in-the-Loop-Gates für sensitive Themen und eine Observability-Schicht mit Langfuse, die jeden Durchlauf traced.
Diese fünf Nodes lassen sich auf die in der Branche gängige Taxonomie für Multi-Agenten-Systeme mappen: Der Kontext-Agent entspricht einem Routing-Agenten, der die Anfrage einordnet und an den passenden Pfad weiterleitet. Retrieval- und Evaluate-Node bilden gemeinsam den Retrieval-Agenten, der Dokumente aus der Wissensdatenbank abrufen und deren Belastbarkeit prüfen muss. Der Rewrite-Node übernimmt die Rolle eines Planungsagenten: Er plant bei schwacher Evidenz einen neuen Suchversuch, statt die Anfrage einfach zu wiederholen. Erst wenn Planung und erneutes Abrufen zu ausreichender Evidenz führen, übergibt das System an den Answer-Agenten. Diese Rollenaufteilung ist der Kern jeder funktionierenden Multi-Agenten-Architektur: Jeder Agent löst genau ein Teilproblem, statt dass ein einzelnes Modell alles gleichzeitig übernimmt.
Der Qualitäts-Kosten-Tradeoff
Agentic RAG ist nicht umsonst. Jeder Evidence-Check ist ein zusätzlicher LLM-Aufruf, jede Nachsuche verdoppelt die Retrieval-Kosten, und Selbstkorrektur-Schleifen können Latenz von 2 auf 6 Sekunden treiben. Wer diesen Tradeoff ignoriert, wird nach drei Monaten Produktion von der Cloud-Rechnung überrascht.
In unseren letzten acht Kundenprojekten haben wir die folgenden Werte gemessen, alle auf Azure OpenAI mit GPT-4o-mini für Routing und GPT-4.1 für Antworten:
Die letzte Zeile ist oft die wichtigste: Agentic RAG lehnt 6 Prozent der Fragen ab, weil die Evidenz nicht reicht. Für Fachbereiche klingt das zunächst schlecht. In der Praxis ist genau das der Mehrwert – keine erfundenen Toleranzen, keine halluzinierten Paragraphen. Ein Kunde aus dem Automotive-Bereich hat es uns so formuliert: „Sechs Prozent ehrliche Nicht-Antworten sind mir lieber als zwölf Prozent plausibler Unsinn.“
Bei 100.000 Queries pro Monat bedeutet der Kostensprung von 0,02 auf 0,07 EUR einen Mehraufwand von 5.000 EUR pro Monat. Klingt viel, relativiert sich aber schnell, wenn ein einziger falscher Antwort-Fall 50.000 EUR kostet.
Anwendungsfälle und Vorteile von Agentic RAG
Aus unseren Projekten haben sich vor allem folgende Einsatzszenarien als sinnvoll erwiesen, bei denen der Mehraufwand von Agentic RAG sich über Genauigkeit und Skalierbarkeit auszahlt:
- Technische Dokumentensuche (Document Intelligence): Bei Konstruktionszeichnungen, Normen und mehrsprachigen Handbüchern reicht reiner Fließtext-Abgleich nicht aus – die Wissensdatenbank enthält Tabellen und Querverweise, die ein Evidence-Agent gezielt prüfen muss, bevor eine Antwort freigegeben wird.
- Compliance- und Audit-Anwendungen: Überall dort, wo eine falsche Antwort ein Audit-Finding auslösen kann, ist die Ablehnungsquote von Agentic RAG (6 Prozent statt erfundener Antworten) ein Sicherheitsgewinn statt eines Nachteils.
- Regulierte Branchen mit hohem Risiko: In Versicherung, Pharma und Rechtsprüfung kombinieren wir Agentic RAG mit Human-in-the-Loop-Gates, damit bei niedriger Konfidenz ein Mensch statt des Systems entscheidet.
- Automotive-Wissensdatenbanken mit hohem Query-Volumen: Der bereits zitierte Kunde aus dem Automotive-Bereich setzt Agentic RAG genau deshalb ein, weil Skalierbarkeit auf zehntausende Anfragen pro Monat bei gleichbleibender Genauigkeit wichtiger ist als der niedrigste Preis pro Query.
Der gemeinsame Nenner dieser Fälle: Je höher die Kosten eines Fehlers und je komplexer die zugrundeliegende Wissensdatenbank, desto klarer rechtfertigt sich der Mehraufwand gegenüber Standard RAG.
Evaluations-Methodik: Wie Sie die Wirkung messen
Ohne Evaluations-Set ist jeder RAG-Vergleich Bauchgefühl. Das ist nicht optional. Wir bauen in jedem Projekt als Erstes ein Set aus 30 bis 100 Referenzfragen mit bekannten Antworten auf, bevor die Architektur-Entscheidung fällt.
Die Fragen kommen nicht vom Entwicklungsteam. Sie kommen vom Fachbereich: Engineering, QA, Service, Compliance. Nur so bildet das Set die Realität ab. Ein typisches Set mischt drei Fragetypen:
- Faktfragen mit eindeutiger Antwort (z.B. „Welche Toleranzklasse gilt nach ISO 2768 für Guss bis 30 mm?“)
- Vergleichsfragen, die mehrere Dokumente kombinieren (z.B. „Unterscheidet sich die Anforderung zwischen DIN EN ISO 9001 und IATF 16949 beim Thema X?“)
- Grenzfragen, bei denen die richtige Antwort „dazu gibt es keine Norm-Aussage“ ist
Der dritte Typ ist wichtiger als er aussieht. Er misst nicht die Präzision, sondern die Ehrlichkeit des Systems. Standard RAG hat bei Grenzfragen in unseren Messungen eine Halluzinationsrate von über 40 Prozent – Agentic RAG mit Evidence-Gate liegt unter 5 Prozent.
Für die technische Umsetzung der Evaluation nutzen wir in der Regel Langfuse Datasets und automatisierte Runs, die bei jedem Modell- oder Prompt-Update gegen das Set laufen. Regressionen werden vor dem Release sichtbar, nicht erst beim Nutzer.
Typische Fehler beim Umstieg
Wir raten aktuell von drei Dingen ab, die wir in Projekten immer wieder sehen:
Erstens: „Agentic everywhere“. Manche Teams bauen für jede Frage die volle Agenten-Pipeline auf – auch für trivial beantwortbare Faktfragen. Das verbrennt Geld und Latenz. Ein Router-Agent am Anfang, der einfache Fragen direkt an Standard-RAG leitet und nur komplexe Fragen an den Multi-Agent-Pfad, spart in unseren Projekten 30 bis 50 Prozent der Kosten.
Zweitens: Evaluation im Nachgang. Teams bauen erst die Architektur, dann das Eval-Set. Das ist rückwärts. Ohne Eval-Set fehlt die Entscheidungsgrundlage, ob Agentic RAG die Mehrkosten überhaupt rechtfertigt.
Drittens: Observability als Afterthought. Ein Agentic-System ohne Tracing ist eine Black Box. Wenn eine Antwort falsch ist, ist unklar, welcher Agent versagt hat – der Retriever, der Evidence-Check, der Rewriter oder der Answer-Agent. Wir setzen Langfuse oder OpenTelemetry-kompatibles Tracing ab Tag eins ein, nicht erst „wenn wir in Produktion gehen“.
Das Bundle, mit dem wir Agentic RAG in der Regel einführen, liegt zwischen 55.000 und 95.000 EUR und umfasst Architektur-Workshop, Multi-Agent-Pipeline mit Evidence-Gate, Evaluation-Set und Observability. Details gibt es in unserem 6-Wochen-Pilot für Generative AI.
Wann wir Standard RAG bewusst empfehlen
Um die Ehrlichkeit nicht zu verlieren: In etwa einem von drei Projekten kommen wir am Ende zur Empfehlung, bei Standard RAG zu bleiben. Gründe, die wir akzeptieren:
- Niedriges Query-Volumen (unter 1.000 pro Monat) macht den Kosten-Tradeoff irrelevant
- Dokumente sind reiner Fließtext ohne Tabellen, Zeichnungen oder Querverweise
- Die Anwendung ist nicht auditpflichtig und Nutzer prüfen Antworten sowieso
- Das Budget trägt keine 55k-Pipeline, sondern nur einen 15k-Piloten
In diesen Fällen ist ein solides Standard-RAG mit sauberer Chunking-Strategie und Hybrid Search (Vektor + BM25) absolut ausreichend. Gartner prognostiziert für 2026, dass über 70 Prozent aller Enterprise-GenAI-Projekte strukturierte Retrieval-Pipelines brauchen – das heißt aber nicht, dass alle davon Agentic RAG sein müssen.
Architektur-Entscheidung in 4 Wochen
Wenn ein RAG-Pilot läuft und die Qualitätsgrenze bei 65 bis 75 Prozent festhängt, ist die Architektur-Frage unumgänglich. Unsere Empfehlung für diesen Moment: Nicht direkt umbauen. Erst messen.
Ein typisches Assessment-Projekt bei uns dauert vier Wochen und produziert drei Artefakte: ein Eval-Set mit 50 Referenzfragen, eine Messung von Standard-RAG gegen dieses Set, und einen Architektur-Vorschlag mit klarem Kosten-Nutzen-Pfad. Erst danach fällt die Bau-Entscheidung. Nicht umgekehrt.
Häufig gestellte Fragen
Was kostet die Migration von Standard RAG auf Agentic RAG?
Zwischen 45.000 und 95.000 EUR je nach Korpusgröße, Anzahl der Agenten und Observability-Anforderungen. Bestehende Komponenten wie Vektordatenbank und Chunks lassen sich wiederverwenden. Laufende Kosten pro Query steigen um Faktor 2 bis 3, liegen aber in typischen Projekten unter 0,10 EUR.
Agentic RAG vs Standard RAG – welches ist besser?
Agentic RAG liefert 20 bis 35 Prozent höhere Antwortqualität, kostet aber mehr pro Anfrage und hat höhere Latenz. Für textbasierte Korpora mit niedrigem Fehlerrisiko reicht Standard RAG. Bei technischen Dokumenten, Multimodalität oder Audit-Anforderungen ist Agentic RAG die richtige Wahl.
Welches Framework für Multi-Agent RAG empfiehlt Pexon?
In Enterprise-Projekten nutzen wir LangGraph, weil es expliziten State und gute Tool-Integration bietet. LlamaIndex Workflows ist eine Alternative, wenn das Team bereits LlamaIndex-basiert ist. Wir raten von Eigenbau-Orchestrierung ab – das Framework-Ökosystem ist reif genug, um nicht selbst zu schreiben.
Wie messe ich die Antwortqualität objektiv?
Mit einem Evaluations-Set aus 30 bis 100 Referenzfragen, die vom Fachbereich stammen. Die Evaluation sollte drei Fragetypen mischen: Faktfragen, Vergleichsfragen und Grenzfragen ohne gültige Antwort. Tools wie Langfuse Datasets oder Ragas automatisieren die Messung.
Reicht Selbstkorrektur aus, oder brauche ich Human-in-the-Loop?
Kommt auf das Risiko an. Bei Customer-Support-Chatbots reicht Selbstkorrektur. Bei regulatorisch sensiblen Anwendungen (Versicherung, Pharma, Rechtsprüfung) setzen wir zusätzlich Human-in-the-Loop-Gates, die bei niedriger Konfidenz zur Freigabe an einen Menschen eskalieren.
Nächster Schritt
Wenn Ihr RAG-Pilot an der Qualitätsgrenze hängt oder die Architektur-Entscheidung ansteht: In einem AI Readiness Assessment messen wir Ihr bestehendes System gegen ein Evaluations-Set und liefern eine klare Empfehlung mit Kosten-Nutzen-Rechnung.
Verwandte Themen
→6-Wochen-Pilot für Generative AI
→Document Intelligence mit PexonParse
