Agentic RAG

Unternehmen beginnen zunehmend damit, KI-Agenten produktiv einzusetzen, beispielsweise um mit ihren tabellarischen Daten zu „chatten“. In diesem Artikel stellen wir einen verwandten Ansatz vor: Agentic Retrieval Augmented Generation (RAG). Diese Methode unterstützt Unternehmen dabei, das volle Potenzial ihrer textbasierten Daten auszuschöpfen.

Als ChatGPT veröffentlicht wurde, waren viele erstaunt, was mit einem großen neuronalen Netzwerk möglich ist, das auf riesigen Mengen an Textdaten trainiert wurde. Die zugrunde liegende Idee ist simpel: Mehr Daten führen zu besseren Modellen. Während des Trainings werden die Parameter des neuronalen Netzes so lange angepasst, bis das Modell zuverlässig das nächste Wort in einem Satz vorhersagen kann. Ist das Modell einmal trainiert, lässt sich daraus Text generieren, indem es das Satzende Token für Token vorhersagt (ein Token entspricht etwa drei Vierteln eines Wortes). Dieser generative Prozess bildet die Grundlage aller großen Sprachmodelle (Large Language Model, LLMs).

Schon kurz nach ihrem Erscheinen stießen Nutzer auf die Grenzen von LLMs, insbesondere auf deren sogenannte Knowledge Cut-Off. Damit ist das Datum gemeint, bis zu dem die Daten, auf denen das Modell trainiert wurde, aktuell sind. Wie bereits beschrieben, werden die Parameter eines Modells nur während der Trainingsphase angepasst, nicht aber während der Inferenz. Da das gesamte Wissen des Modells in diesen Parametern gespeichert ist, kann es nach dem Training keine neuen Informationen mehr aufnehmen oder dazulernen. Diese Einschränkung wird mit der Zeit zunehmend problematisch. Vor allem dann, wenn aktuelle oder zeitkritische Informationen notwendig sind, um präzise und relevante Antworten zu liefern.

Da sich die Welt ständig verändert und täglich neue Informationen hinzukommen, ist die Anbindung von Sprachmodellen an aktuelle Datenquellen inzwischen unerlässlich, um ihre Nützlichkeit und Vertrauenswürdigkeit aufrechtzuerhalten. Beachten Sie, dass genau dasselbe Prinzip in Situationen gilt, in denen wir das Modell mit Wissen erweitern wollen, das nicht öffentlich verfügbar ist, wie beispielsweise klassifizierte unternehmensspezifische Informationen.

Eine weitere wesentliche Einschränkung von LLMs ist ihre Neigung zur sogenannten Halluzination. Aufgrund ihres generativen Charakters liegt das Hauptziel von LLMs darin, sprachlich sinnvolle Texte zu erzeugen, jedoch nicht zwangsläufig inhaltlich korrekte oder faktenbasierte. Besonders in der Anfangszeit war deutlich erkennbar, dass Chatbots wie ChatGPT leicht dazu gebracht werden konnten, fehlerhafte oder erfundene Inhalte zu liefern. Um diese Modelle produktiv zu nutzen, war es essenziell, dem Modell „zu helfen“, so zu antworten, dass die Antworten sachlich fundiert sind, indem man relevante Informationen über den Prompt bereitstellt, also mehr Kontext liefert.

Was können wir also tun, um diese Einschränkungen abzumildern? Im Allgemeinen gibt es zwei Möglichkeiten, das „Wissen“ des Modells zu verändern. Erstens kann man das Modell nach-trainieren (fine-tunen), das heißt, die Parameter des vortrainierten LLMs durch zusätzliches Training an einem kleineren, anwendungsspezifischen Datensatz anpassen. Ein komplettes Neutraining von Grund auf kommt nicht infrage: Aufgrund der enormen Anzahl an Parametern und des damit verbundenen Speicherbedarfs erfordert das Training spezialisierte Rechencluster, die sich nur wenige leisten können.

Zweitens kann man dem LLM einfach relevante Informationen bereitstellen, indem man den Prompt erweitert, also dem Nutzereingabetext zusätzliche Inhalte hinzufügt, bevor man ihn an das LLM sendet. Das erfordert im Allgemeinen weniger Aufwand als das Feintuning und lässt sich automatisieren, was der Ansatz der Retrieval Augmented Generation (RAG) ist.

Was ist Retrieval Augmented Generation?

Da das Modell das nächste Wort stets im Kontext der gesamten Eingabeaufforderung generiert, gibt es eine einfache Möglichkeit, zusätzliches Wissen in das Modell einzubringen: durch Erweiterung des Prompts.

Stellen Sie sich zum Beispiel ein Unternehmen vor, das einen personalisierten Assistenten anbietet, der sich den Namen des Nutzers merken soll. Eine erneute Schulung oder Feinabstimmung des LLM für jeden einzelnen Nutzer wäre ressourcenintensiv. Derselbe Effekt lässt sich viel einfacher erreichen, indem man dem Modell bei jeder Anfrage den Namen des Nutzers im Prompt voranstellt. Ein solcher erweiterter Prompt könnte beispielsweise so aussehen:

```

“You are a helpful personalized assistant to the user: “Max Mustermann”

Here are some facts about the user:

Max is a Data Scientist”

“...”

Respond to the following user query:

{query that the user wrote is put in here}

```

Dieser Ansatz - die Ergänzung der Eingabeaufforderung an den LLM mit Informationen, die für die folgende Abfrage nützlich sein können - liegt der Retrieval Augmented Generation (RAG) zugrunde. RAG-Systeme koppeln LLMs mit externen Wissensabrufmechanismen. Wenn eine Anfrage eingeht, ruft das System zunächst relevante Informationen aus aktuellen Quellen ab und verwendet dann diese Informationen, um die Eingabeaufforderung an den LLM zu erweitern, der dann eine Antwort erzeugt.

Der gleiche Ansatz lässt sich auch dann nutzen, wenn eine LLM-Antwort nicht auf allgemeinem, sondern auf unternehmensspezifischem Wissen basieren soll. Wird das Modell beispielsweise nach einem internen Prozess gefragt, fällt die Antwort deutlich präziser und hilfreicher aus, wenn ich den Generierungsprozess mit relevanten unternehmensinternen Informationen anreichere, anstatt das Modell nur auf Basis seines allgemeinen Trainings antworten zu lassen. Das können beispielsweise Dokumentationen oder interne Publikationen sein. Dieses Prinzip hilft nicht nur dabei, relevantere Antworten zu erzeugen, sondern reduziert auch das Risiko unerwünschter Halluzinationen, denn die zusätzlich bereitgestellten Fakten dienen dem Modell als verlässliche Grundlage für die Textgenerierung.

Abbildung 1 veranschaulicht die Funktionsweise eines einfachen RAG-Systems, die aus den folgenden Schritten besteht:

1. Verarbeitung der Suchanfrage: Die Frage des Benutzers wird analysiert und in eine geeignete Suchanfrage umgewandelt.
2. Informationsbeschaffung: Das System durchsucht angeschlossene Wissensdatenbanken und Dokumentenspeicher, um relevante Informationen zu finden. Beachten Sie, dass diese Wissensdatenbanken, die häufig in Form von Vektordatenbanken vorliegen, zuerst aufgebaut werden müssen.
3. Kontexterstellung: Die gefundenen Informationen werden ausgewählt, gefiltert und formatiert, um einen relevanten Kontext zu liefern. Die Informationen werden mit der Benutzeranfrage zu einem „Prompt“ kombiniert.
4. Antwortgenerierung: Das LLM generiert eine Antwort auf der Grundlage des Prompts, bestehend aus der Benutzeranfrage und den abgerufenen Informationen.

In einem RAG-System wird eine Benutzeranfrage durch abgerufene Textpassagen aus Dokumenten ergänzt. Diese Passagen werden auf der Grundlage einer Ähnlichkeitssuche in einem sogenannten Embedding gefunden, d. h. einer mathematischen Darstellung von Text in Form großer Vektoren. Passagen, die der Benutzeranfrage am ähnlichsten sind, werden identifiziert, nach ihrer Ähnlichkeit geordnet und als zusätzlicher Kontext an die Benutzeranfrage weitergegeben. Die Anfrage und die abgerufenen Informationen werden dann gemeinsam an ein LLM weitergeleitet, das auf der Grundlage der abgerufenen Informationen eine Antwort auf die Benutzeranfrage generiert.

Klassischerweise besteht die Wissensbasis eines RAG-Systems aus einer Sammlung von Textdateien oder PDFs, die in durchsuchbaren Text umgewandelt wurden. Diese Sammlung lässt sich flexibel pflegen, indem neue Dokumente hinzugefügt oder veraltete entfernt werden.

Dieser Ansatz hat sich als äußerst wirkungsvoll erwiesen: Er ermöglicht es LLMs, auf aktuelle Informationen zuzugreifen, Quellen anzugeben und Antworten gezielt in bestimmten Dokumenten oder Datenbanken zu verankern.

RAG-Systeme kommen in verschiedensten Bereichen zum Einsatz, beispielsweise im Kundenservice, wo sie auf unternehmensspezifische Wissensdatenbanken zugreifen, im Gesundheitswesen, wo sie aktuelle medizinische Fachliteratur einbeziehen, oder im juristischen Umfeld, wo sie mit geltender Rechtsprechung und regulatorischen Vorgaben arbeiten.

Angesichts der einfachen Umsetzung und hohen Wirksamkeit überrascht es nicht, dass RAG-Anwendungsfälle die frühen Einsatzgebiete von LLMs maßgeblich geprägt haben – und bis heute nichts von ihrer Relevanz verloren haben.

Wo RAG-Systeme an Ihre Grenzen stoßen

Trotz ihrer nachgewiesenen Stärken stoßen RAG-Systeme auch an gewisse Grenzen. Zwar reichern sie die Eingabeaufforderung mit hilfreichen Informationen an, die ursprüngliche Benutzeranfrage bleibt jedoch unverändert. Schon kleine Änderungen in der Formulierung können daher zu stark abweichenden Ergebnissen führen.

• Das embedding-basierte Retrieval ist in Bezug auf die Bedeutung nicht immer treffsicher. Es kann vorkommen, dass irrelevante Dokumente gefunden werden, nur weil sie ähnliche Begriffe enthalten – selbst wenn der eigentliche Kontext nicht passt.
• Da sie einem festen Arbeitsablauf folgen, sind RAG-Systeme ungeeignet für komplexe Fragen, die möglicherweise mehrere Schritte erfordern.
• Sie ermöglichen eine doppelte Überprüfung ihrer Ergebnisse und können daher die Qualität, Genauigkeit und Relevanz ihrer Antworten nicht kontrollieren.

Diese Einschränkungen haben deutlich gemacht, dass es intelligenterer, autonomerer und flexiblerer RAG-Systeme bedarf – und genau das hat den klassischen RAG-Ansatz mit dem aktuellen Aufschwung agentenbasierter KI zusammengebracht.

Der nächste Schritt: Agentic RAG

Wenn 2024 im Zeichen von RAG-Anwendungen stand, dann wird 2025 das Jahr der Agentischen KI. Sie hebt LLM-Anwendungen auf ein ganz neues Level: LLM-gestützte Agenten können eigenständig über Aufgaben nachdenken, Entscheidungen treffen und miteinander kooperieren. Dabei übernehmen sie gezielt Rollen – etwa als Datenbank-Abfrager, Eingabeoptimierer, Websuch-Agent oder Qualitätssicherer für generierte Texte – und nutzen Tools wie Dokumentenverarbeitung, Programmierung oder Webrecherche.

So entstehen hochgradig automatisierte und flexible Workflows, die klassische LLM-Chatbots weit hinter sich lassen. Eine ausführliche Betrachtung des Potenzials Agentischer KI geht allerdings über diesen Beitrag hinaus. Wer dennoch tiefer einsteigen möchte, findet weiterführende Informationen in dieser Einführung in Multi-Agenten-Systeme sowie in diesem Blogbeitrag über KI-Agenten.

Auch wenn RAG-Systeme einen wichtigen Fortschritt gegenüber klassischen LLMs darstellen, stoßen sie schnell an Grenzen. Sie folgen meist einem starren Ablauf und sind oft auf einen bestimmten Fragetyp oder eine spezifische Wissensbasis zugeschnitten.

Agentic RAG geht einen entscheidenden Schritt weiter: Es erweitert den RAG-Ansatz um verschiedene spezialisierte Agenten und verwandelt den statischen Abrufprozess in ein aktives, zielgerichtetes System, welches verschiedene Aktionen ausführen kann. Her einige Beispiele wie Agenten ein RAG system ergänzen können:

• Um flexibel zu entscheiden, wie Informationen abgerufen werden sollen (welche Informationen abgerufen werden und woher sie abgerufen werden),
• um Nutzeranfragen umzuformulieren, zu standardisieren und/oder zu klassifizieren und an spezialisierte Workflows weiterzuleiten
• spezialisierte „Tools“ aufzurufen, oder
• um In-Prozess-Evaluierungen durchzuführen, die Qualität sicherstellen.

Dabei ist das Abrufen von Informationen nur eine von vielen möglichen Aktionen, die Agenten ausführen können. Diese Aktionen lassen sich flexibel kombinieren, um auch komplexe Anfragen zu bearbeiten und mehrere Agenten können gemeinsam und iterativ an einer Aufgabe arbeiten, um die bestmögliche Antwort zu finden. Durch diese Weiterentwicklung wird das System deutlich kontrollierbarer, anpassungsfähiger und insgesamt leistungsfähiger. Im nächsten Abschnitt stellen wir verschiedene Beispiele und Varianten von Agentic RAG vor.

Verschiedene Varianten von Agentic RAG

Im vorherigen Abschnitt haben wir bereits das Grundprinzip von Agentic RAG erläutert: Große Sprachmodelle werden mithilfe von Dokumentenrecherche in spezifischen Wissensquellen verankert und können durch Tool-Integration aktiv handeln.

In diesem Abschnitt werfen wir einen Blick auf verschiedene Architekturmuster – also Varianten von Agentic RAG –, die veranschaulichen, wie dieses Konzept agentenbasiert weiterentwickelt werden kann. Dabei ermöglichen die Agenten unter anderem dynamische Entscheidungsprozesse, automatische Selbstüberprüfung und Human-in-the-Loop-Mechanismen.

Abbildung 2 gibt einen Überblick darüber, wie agentenbasierte KI klassische RAG-Systeme gezielt erweitern und auf ein neues Level hebt.

Im Agentic RAG lässt sich der klassische RAG-Workflow auf vielfältige Weise durch spezialisierte KI-Agenten erweitern.

Ein Input-Agent kann beispielsweise entscheiden, ob eine Benutzeranfrage direkt beantwortet werden kann, ob ein Dokumentenabruf notwendig ist, und falls ja, aus welcher Datenbank oder Quelle, oder ob die Anfrage an eine andere Instanz eskaliert werden sollte. Er kann zudem die ursprüngliche Frage umformulieren, um eine bessere Grundlage für die weitere Verarbeitung zu schaffen. Ein Retrieval-Evaluator kann die Reihenfolge der abgerufenen Dokumente optimieren, irrelevante oder qualitativ minderwertige Inhalte herausfiltern oder die Suchanfrage weiter verfeinern, etwa durch Anpassung der Abfrageparameter. Ein Answer Critic bewertet im Anschluss die Qualität und Relevanz der vom LLM generierten Antwort und kann gegebenenfalls die Eingabeaufforderung neu formulieren, um eine bessere Antwort zu erzielen. Ein Meta-Agent sorgt für die übergeordnete Koordination: Er gibt Zwischenergebnisse an den Nutzer zurück, ergänzt die Eingaben um kontextrelevante Informationen und steuert die Zusammenarbeit der verschiedenen Agenten.

Zuletzt kann ein Flow-Engineering-Agent Prozesse parallelisieren und mithilfe von Ensemble-Voting mehrere LLM-Antworten vergleichen, um die zuverlässigste oder konsistenteste Lösung auszuwählen.

Input Agent: Steuerung von Abrufentscheidungen

Jedes agentenbasierte RAG-System beginnt mit einem Input-Agenten, also einer Art Steuerungsinstanz, die bestimmt, ob und wie zusätzlicher Kontext abgerufen werden soll. Zum Beispiel:

• RAG oder menschlicher Fachkraft: Wenn eine Kundenanfrage eingeht, entscheidet der Input Agent, ob er direkt aus seinem eigenen Wissen heraus antwortet, relevante Dokumente abruft oder an einen menschlichen Kollegen weitergibt.
• Auswahl der Quelle: Er wählt die geeignete Datenbank oder Sammlung aus, z. B. Produkthandbücher, Richtliniendokumente oder domänenspezifische Wikis, und entscheidet sogar, ob er einen internen Speicher abfragt oder eine Live-Suche im Internet durchführt.
• Umformulierung der Abfrage: Vor dem Abruf kann die Abfrage verfeinert werden. Zweideutige oder unzureichend spezifizierte Anfragen wie „Wie lauten die Rückerstattungsrichtlinien?“ werden zu „Wie lauten die 30-tägigen Rückgabe- und Rückerstattungsrichtlinien für Elektronikkäufe?“

Indem ein komplexes Ziel in einzelne Teilaufgaben zerlegt wird (zum Beispiel „relevante Richtlinie finden“, „Kaufdatum des Kunden ermitteln“ oder „Erstattungsanspruch berechnen“) kann der Input-Agent den benötigten Kontext Schritt für Schritt abrufen und die Teilergebnisse zu einem schlüssigen Gesamtplan zusammenführen. Dabei kann er seine eigene Argumentationskette oder Zwischenschritte offenlegen, mögliche Sackgassen erkennen und eigenständig alternative Suchstrategien ausprobieren.

Retrieval Evaluator: Qualität und Relevanz sicherstellen 

Nach dem Abrufen von relevanten Dokumenten folgt meist ein Retrieval Evaluator:

• Relevanzprüfung und Neueinstufung: Jedes abgerufene Dokument wird nach einer bestimmten Metrik bewertet, z. B. nach der Relevanz (oder einer anderen Metrik, die über einen Code oder ein zusätzliches LLM eingeführt werden kann), und neu geordnet, um die auf embedding-basierende Abfrage zu verbessern.
• Dynamisches Retrieval über Tool-Outputs: Angenommen, ein Tool holt Informationen zum heutigen Wechselkurs. Der Retrieval Evaluator kann damit zusammenhängende Protokolleinträge oder Dokumentationen erneut abrufen, beispielsweise „Wie haben sich die Kurse diese Woche entwickelt?“, um die neuen Daten zu interpretieren und weitere Schritte zu beschließen.
• Adaptive Query Rewriting: Wenn die anfängliche Suche nur wenige Treffer ergab („Ich habe nicht genug über die Einhaltung der Vorschriften für Lieferanten gefunden“), kann der Evaluator die Abfrage automatisch umschreiben („suche stattdessen nach ‚Auditverfahren für die Zertifizierung von Lieferanten‘“) und eine Folgeanfrage stellen.

In solchen Implementierungen kann das System in einen geschlossenen Kreislauf übergehen: Die abgerufenen Textausschnitte fließen so lange in weitere Abfragen ein, bis eine definierte Vertrauensschwelle erreicht ist.

Answer Generation Critic: Schrittweise Verbesserungen

Bevor eine Antwort präsentiert wird, kann Agentic RAG einen Critic Agent einsetzen, der den LLM ein zweites Mal aufruft und auf Halluzinationen, logische Ungereimtheiten oder die Einhaltung des Stils überprüft und die Antwortgenerierung gegebenenfalls wiederholt. Bei unternehmenskritischen Aufgaben (finanzielle Zusammenfassungen, medizinische Ratschläge) können mehrere solcher Schutzmaßnahmen kombiniert werden, um sicherzustellen, dass die endgültige Ausgabe strengen Qualitätsstandards entspricht. Wichtig ist, dass dieser „LLM als Richter“-Ansatz es ermöglicht, zu testen, ob der generierte Inhalt die Absicht der Benutzeranfrage erfüllt, und, falls nicht, die Abfrage und/oder die Generierung der Antwort erneut zu starten.

Meta-Controller: Der Agentische Manager

Ein Meta-Controller oder „Agent Manager“ kann zur Durchsetzung übergeordneter Richtlinien eingesetzt werden:

• Orchestrierung von Aktionen: Zum Entscheiden, wann ein Abruf ausgelöst, externe Tools (z. B. statistische Rechner, Graphanalysatoren) aufgerufen oder der Benutzer um zusätzliche Eingaben gebeten werden soll.
• Ressourcen- und Sicherheitsüberwachung: Verfolgt die API-Nutzung, Ratenbegrenzungen und stellt die Einhaltung von Unternehmensrichtlinien sicher, indem Aktionen unterbrochen oder zurückgenommen werden, die zu Datenlecks oder unethischen Ausgaben führen könnten.
• User-in-the-Loop Aufforderungen: Wenn Unklarheiten bestehen, kann der Meta-Controller eine Pause einlegen, um eine Klärung durch den menschlichen Benutzer herbeizuführen - „Soll ich PDF-Anhänge in die Zusammenfassung aufnehmen?“ - und schafft damit ein Gleichgewicht zwischen Autonomie und menschlicher Kontrolle.
• Langzeitgedächtnis: Der Agent speichert benutzerspezifische Fakten (Präferenzen, Projektmeilensteine, sich entwickelnde Weltzustände). Indem er sich an vergangene Interaktionen erinnert, vermeidet er wiederholte Berechnungen („Sie haben letzten Monat nach dem EBITDA gefragt - soll ich den letzten Quartalsbericht holen?“) und personalisiert seine Antworten.

Alle Entscheidungen, von Abrufanfragen bis zu Toolaufrufen, werden in einem Erklärungspfad und einem sogenannten Agentic Trace protokolliert, sodass die Benutzer eine transparente Aufzeichnung jedes Zwischenschritts erhalten.

Flow Engineering Agent

Schließlich können agentenbasierte RAG-Systeme auch Parallelisierungs- und Ensemble-Methoden einsetzen, um die Performance zu verbessern:

• Aufgabenparallelisierung: Unabhängige Teilaufgaben wie das Extrahieren von Tabelle A, Tabelle B und Tabelle C aus einem technischen PDF werden parallel verarbeitet, wobei die Ergebnisse in einer einheitlichen Zusammenfassung zusammengefasst werden.
• Ensemble-Abstimmung: Dieselbe Pipeline zur Abfragegenerierung wird mehrmals unter verschiedenen Eingabeaufforderungen oder Temperatursätzen des LLM ausgeführt, um Stochastizität in der Ausgabe zu ermöglichen, und ein Mehrheitsabstimmungsmechanismus wählt die konsistenteste Antwort aus.

Durch die Redundanz werden Fehler bei einzelnen Durchläufen verringert, Halluzinationen vermieden und häufig zuverlässigere, konsensorientierte Ergebnisse erzielt. Dies geht jedoch oft auf Kosten einer höheren Antwortlatenz, es sei denn, die Prozesse können effizient parallelisiert werden.

Durch die Kombination dieser Varianten (modulare Input-Agenten, Evaluatoren, Kritiker, Meta-Controller, Speicher, Tool-Integration und parallele Ensembles) erweitern agentenbasierte RAG-Systeme konventionelle RAG-Systeme. Sie werden zu dynamischen, flexiblen, selbstkorrigierenden und transparenteren KI-Assistenten, die in der Lage sind, komplexe, domänenspezifische Aufgaben zu lösen, ohne den Menschen aus den Augen zu verlieren.

Grenzen verstehen und Alternativen nutzen

Auch wenn agentenbasierte RAG leistungsstarke, kontextbewusste Sprachfunktionen ermöglicht, bringt sie gewisse Kompromisse mit sich. In diesem Abschnitt beleuchten wir die zentralen Herausforderungen und stellen alternative Ansätze vor, die einige dieser Einschränkungen abmildern können - auch wenn sie selbst noch weit von einer perfekten Lösung entfernt sind.

Grenzen

Mehrkosten für Ressourcen und Latenzzeiten

Bereits bei der abruferweiterten Generierung (RAG) entsteht eine gewisse Verzögerung – typischerweise etwa 200 Millisekunden pro Abfrage – bedingt durch Embedding-Suchen und den Zugriff auf externe Datenspeicher. Wird das System um mehrere Agenten erweitert, erhöht sich diese Latenz deutlich: Jedes zusätzliche Modul – etwa Retriever, Planer, Ausführer oder Kritiker – bringt eigene Rechenzeit mit sich. Werden diese Agenten verkettet, kann sich die Gesamtlatenz entsprechend summieren. Für Anwendungen, bei denen Reaktionsgeschwindigkeit entscheidend ist – etwa im Live-Chat oder bei Edge-Deployments – können diese Verzögerungen schnell zum Problem werden.

Systemkomplexität und Instandhaltung

Eine agentische RAG-Pipeline ist von Natur aus komplizierter als ein herkömmliches RAG-System. Neben dem Abruf und der Generierung muss auch die Auswahl der Agenten, den Aufruf der Tools und die Richtlinien der Meta-Controller orchestriert werden. Diese Vielzahl an beweglichen Teilen erschwert das Debuggen von Leistungsengpässen oder das Aufspüren von fehlerhaften Ausgaben. Darüber hinaus resultiert die Versionskonsistenz, z. B. über LLM-Prüfpunkte, Abrufindizes und benutzerdefinierte Tools hinweg, in einem konstanten Wartungsaufwand.

Kosten für Datenverarbeitung und Infrastruktur

Obwohl die LLM-Kosten mit der zunehmenden Standardisierung von KI wahrscheinlich weiter sinken werden, verbraucht jeder Agentenaufruf und jede Abrufanfrage Rechenzyklen, was die Cloud-Kosten in die Höhe treibt. Selbst leichtgewichtige Reasoning- oder Evaluierungs-Agenten erhöhen Ihre monatliche Rechnung inkrementell. Ebenso erfordert das Hosten und Bereitstellen großer Vektorspeicher oder spezialisierter Datenbanken erhebliche Speicher- und E/A-Ressourcen, was die Infrastrukturkosten weiter in die Höhe treibt.

Alternativen

Wenn die volle Leistung von Agentic RAG nicht erforderlich oder zu kostspielig ist, bieten folgende Strategien leichte Alternativen:

Cache-Augmented Generation (CAG)

Durch die Pflege eines dynamischen Caches der letzten Aufforderungen, Antworten oder deren Einbettungen kann CAG wiederholte oder semantisch ähnliche Anfragen sofort beantworten, ohne einen vollständigen Abfrage- und Generierungszyklus aufzurufen. Dabei werden die zunehmend größeren Kontextfenster moderner LLMs gezielt genutzt, was insbesondere bei hohem Anfragevolumen und sich wiederholenden Aufgaben die durchschnittliche Antwortzeit deutlich reduzieren kann.

Auf den Bereich abgestimmte Modell- und Prompt-Tuning

In engen, stabilen Domänen können sorgfältig ausgearbeitete Prompts oder eine leichte Feinabstimmung an einem repräsentativen Korpus Kernwissen direkt in die Modellgewichte einbetten. Das Training eines kleineren, domänenspezialisierten LLM reduziert die Abhängigkeit von externen Abfragen und bietet einen schnelleren Durchsatz und eine einfachere Infrastruktur.

Hybrides und mehrstufiges Retrieval

Anstelle von separaten Dense- und Sparse-Agenten fusionieren hybride Pipelines die Schlüsselwort- und Vektorsuche in einem Schritt und erreichen so eine hohe Trefferquote und Präzision bei geringerer Komplexität. Alternativ kann eine zweistufige Grob-zu-Fein-Suche durchgeführt werden, bei der zunächst mit einem schnellen, kostengünstigen Index gefiltert wird und dann dichte Einbettungen auf eine eingegrenzte Kandidatengruppe angewandt werden.

Wissensdestillation und Embedding-Komprimierung

Der Speicherbedarf von Vektordatenbanken lässt sich durch Verfahren wie Clustering, Quantisierung oder Wissensdistillation deutlich reduzieren. Dadurch werden nicht nur die Suchvorgänge nach den nächsten Nachbarn beschleunigt, sondern auch die benötigten Speicherressourcen gesenkt.

Durch ein gezieltes Verständnis der bestehenden Einschränkungen und die Einbindung alternativer Ansätze lässt sich eine Retrieval-Augmented Lösung – ob agentenbasiert oder nicht – passgenau auf die spezifischen Anforderungen einer Domäne, angestrebte Leistungsziele und vorhandene Budgetrahmen zuschneiden.

Fazit

Während RAG eine wichtige Brücke zwischen statischen LLMs und ständig neuem Wissen geschlagen hat, folgt es weiterhin einem einmaligen Abfrageansatz. In diesem Artikel wurde Agentic RAG vorgestellt – ein Konzept, bei dem autonome Agenten dynamisch entscheiden, wann Informationen abgerufen werden, was gesucht werden soll, wie Anfragen umformuliert werden und wann spezialisierte Tools oder menschliche Expertise hinzugezogen werden sollten.

Verschiedene Architekturen wurden beleuchtet – vom Input-Agent, der komplexe Fragen in kleinere, gezielt abrufbare Teilaufgaben zerlegt, über Evaluatoren, die Antworten neu ordnen und verfeinern, bis hin zu Meta-Controllern, die für Sicherheit sorgen und nachvollziehbare Prüfpfade sicherstellen. Dabei wurde auch der zusätzliche Aufwand berücksichtigt, den diese leistungsstarken Funktionen mit sich bringen.

Für Unternehmen, die echte Produktivitätsgewinne erzielen möchten, lohnt es sich, klein zu starten: Mit einem Input-Agenten, der Kundenanfragen intelligent weiterleitet; einem Retrieval-Evaluator, der sicherstellt, dass nur die relevantesten Inhalte in die Antwortgenerierung einfließen; sowie einem schlanken Kritiker- oder Tool-Calling-Agent für spezifische Aufgaben – etwa durch den Einsatz flexibler Dokumentenparser wie Vision Language Models. Ein einfacher Meta-Controller kann ergänzend eingesetzt werden, um Kosten zu überwachen und Fehler frühzeitig zu erkennen. Auf diese Weise lassen sich klassische Chatbots in selbstkorrigierende, menschenzentrierte Assistenten verwandeln.

Da Vektorspeicher durch Verdichtungstechniken effizienter werden und mehrstufige Retrieval-Prozesse die Latenz reduzieren, gewinnen agentenbasierte RAG-Systeme zunehmend an Effizienz. Damit entsteht die Grundlage für autonome KI-Workflows, die es Teams ermöglichen, direkt mit ihren Daten zu arbeiten – und Innovation im großen Maßstab voranzutreiben.