Retrieval-Augmented Generation hat sich in den letzten Jahren zu einem weit verbreiteten Ansatz entwickelt, um Large Language Models (LLMs) mit externem Wissen zu verbinden. In der naiven Form von RAG ist der Ablauf klar: Der Benutzer formuliert eine Anfrage, die verwendet wird, um relevante Inhalte aus einer Wissensquelle abzurufen. Diese Inhalte werden dem Large Language Model (LLM) als zusätzlicher Kontext für die Antwort bereitgestellt. Dieser Ansatz funktioniert für viele Anwendungsfälle sehr gut.
Doch was passiert, wenn eine einzige Suche nicht ausreicht? Wenn die ursprüngliche Anfrage für die Suche ungeeignet formuliert ist oder wenn Informationen aus unterschiedlichen Quellen benötigt werden, beispielsweise aus mehreren Datenbanken oder aus dem Internet? Und wie sieht es in Fällen aus, in denen die abgerufenen Dokumente nicht relevant genug sind und das System selbst erkennen muss, dass eine weitere Suche notwendig ist?
Genau an diesem Punkt beginnen sich Naive RAG, Agentic RAG und Multi-Agentic RAG voneinander zu unterscheiden.
In diesem Blogbeitrag schauen wir uns zunächst kurz an, was AI Agents sind. Anschließend betrachten wir, wie Agentic RAG und Multi-Agentic RAG über den einfachen Naive-RAG-Ansatz hinausgehen und welche Vorteile diese Ansätze gegenüber einer Naive-RAG-Pipeline bieten können.
Wenn Sie sich vorab einen kurzen Überblick über Retrieval-Augmented Generation und den grundlegenden Naive-RAG-Ansatz verschaffen möchten, lesen Sie unseren vorherigen Blogbeitrag mit dem Titel: „Ein Blick in die Zukunft der KI: Einführung in Retrieval-Augmented Generation (RAG)“.
AI Agents
Bevor wir uns Agentic RAG und Multi-Agentic RAG genauer anschauen, ist es sinnvoll, zunächst kurz zu klären, was unter einem AI Agent zu verstehen ist.
AI Agents sind Systeme, die Aufgaben weitgehend selbstständig bearbeiten können. Das Herzstück eines AI Agents bildet ein Large Language Model. Ein Agent beschränkt sich damit nicht nur darauf, eine Benutzereingabe zu verarbeiten und eine Antwort zu generieren. Er kann vielmehr entscheiden, welche Aktionen notwendig sind, diese ausführen und die Ergebnisse anschließend für die nächsten Schritte verwenden.
Dafür greifen Agents auf unterschiedliche Tools zu. Mit Tools sind dabei Funktionen oder Schnittstellen gemeint, über die beispielsweise eine Datenbank abgefragt, eine API aufgerufen oder eine Websuche durchgeführt werden kann.
Das LLM übernimmt dabei eine zentrale Rolle bei der Verarbeitung der Anfrage und der Entscheidung über die nächsten Schritte. Das Agentensystem stellt anschließend die technische Möglichkeit bereit, diese Schritte auszuführen, beispielsweise durch den Aufruf eines Tools. Das Ergebnis wird wiederum an das LLM zurückgegeben, das darauf basierend den nächsten Schritt bestimmen oder schließlich eine Antwort generieren kann.
Ein einfaches Beispiel zeigt, wie ein solcher agentischer Ablauf aussehen kann: Ein Benutzer möchte wissen, welches Produkt seines Unternehmens sich im vergangenen Quartal am besten verkauft hat und wie sich der Umsatz im Vergleich zum Vorquartal entwickelt hat.
Der Agent erkennt, dass er für die Beantwortung der Frage auf aktuelle Unternehmensdaten zugreifen muss. Über ein entsprechendes Tool fragt er die Verkaufsdaten aus einer Datenbank ab. Das Ergebnis wird anschließend an das LLM zurückgegeben und ausgewertet. Stellt sich dabei heraus, dass für den Vergleich noch Daten aus dem vorherigen Quartal fehlen, kann der Agent eine weitere Abfrage durchführen, um die fehlenden Daten abzurufen.
Sobald alle notwendigen Informationen vorliegen, werden die Ergebnisse zusammengeführt und daraus eine Antwort für den Benutzer generiert.
Ein agentischer Workflow kann jedoch aus vielen weiteren Komponenten bestehen und deutlich komplexer aufgebaut sein. Eine detaillierte Beschreibung würde den Umfang dieses Beitrags überschreiten und bietet daher genügend Stoff für einen separaten Blogbeitrag. Aus diesem Grund konzentrieren wir uns im Folgenden auf Agentic RAG und Multi-Agentic RAG.
Agentic RAG
Agentische Ansätze ermöglichen es, Aufgaben nicht nur nach einem fest vorgegebenen Ablauf zu bearbeiten, sondern die nächsten Schritte abhängig von den bisherigen Ergebnissen anzupassen. Übertragen auf Retrieval-Augmented Generation entsteht daraus Agentic RAG, bei dem ein Agent eine aktive Rolle innerhalb des Retrieval-Prozesses übernimmt. In diesem Abschnitt betrachten wir Agentic RAG zunächst anhand einer einfachen Architektur mit einem einzelnen Agenten und einem Tool für die semantische Suche. Grundsätzlich kann ein Agentic-RAG-System jedoch auch mehrere Tools oder Datenquellen einbeziehen. Werden mehrere spezialisierte Agents eingesetzt, spricht man von einer Multi-Agent-Architektur, auf die wir in Abschnitt 3 eingehen.
Naive RAG vs. Agentic RAG
Im Vergleich zu Naive RAG, das einer festen Pipeline nach dem Prinzip „Retrieve – Augment – Generate“ folgt, wird der Retrieval-Prozess bei Agentic RAG dynamischer gestaltet und durch einen AI-Agenten gesteuert. Der Agent kann selbst entscheiden, wann eine Suche notwendig ist und welche Suchanfrage dafür verwendet werden soll.
Wie in Abbildung 1.1 zu sehen ist, wird der Unterschied zwischen Naive RAG (hier als „Classic RAG“ bezeichnet) und Agentic RAG deutlich. Während Naive RAG einem festen Ablauf folgt, arbeitet Agentic RAG iterativ.
Der Agent nimmt zunächst die Anfrage des Benutzers entgegen. Für den Retrieval-Prozess steht ihm beispielsweise ein Tool für die semantische Suche zur Verfügung. Über dieses Tool kann der Agent relevante Dokumente abrufen und die gefundenen Informationen anschließend bewerten.
Das LLM im Agentensystem nutzt Reasoning (mehr dazu in Abschnitt 2.2), um die gefundenen Informationen zu bewerten und den nächsten Schritt zu bestimmen. Reichen die gefundenen Informationen aus, kann der Agent auf dieser Grundlage eine Antwort generieren. Stellt er dagegen fest, dass die Ergebnisse nicht relevant genug sind, kann er die Suchanfrage neu formulieren und das Tool erneut aufrufen. Die neuen Ergebnisse werden wiederum bewertet und in den weiteren Ablauf einbezogen.
Dieser Prozess kann sich mehrfach wiederholen, bis ausreichend relevante Informationen für die Beantwortung der ursprünglichen Anfrage vorliegen. Um dabei Endlosschleifen zu vermeiden, kann in einem agentischen Workflow zusätzlich eine maximale Anzahl an Iterationen festgelegt werden.
Tools und Reasoning
Damit ein Agent ein Tool verwenden kann, muss dieses zunächst technisch in das Agentensystem eingebunden und dem Large Language Model mit seiner Funktion und den benötigten Eingaben bekannt gemacht werden.
Zusätzliche Anweisungen können anschließend festlegen, wann und wie der Agent dieses Tool einsetzen soll. Dabei kann beispielsweise festgelegt werden, dass der Agent vor der Beantwortung einer Frage zunächst eine semantische Suche durchführen soll. Ebenso können Anweisungen definiert werden, wie er reagieren soll, wenn die erste Suche keine relevanten Ergebnisse liefert.
Für einen Agenten innerhalb eines Agentic-RAG-Systems könnte eine vereinfachte Anweisung beispielsweise folgendermaßen aussehen:
„Du bist ein Rechercheassistent mit Zugriff auf eine Wissensdatenbank. Verwende das Tool für die semantische Suche, um relevante Informationen zu finden, bevor du eine Antwort generierst. Liefert die erste Suche keine relevanten Ergebnisse, formuliere die Suchanfrage neu oder suche nach verwandten Begriffen. Stütze deine Antwort auf die gefundenen Informationen. Werden auch nach mehreren Suchanfragen keine relevanten Suchergebnisse gefunden, weise darauf hin.“
Neben den verfügbaren Tools spielt auch das Reasoning des LLMs, das im Zentrum des Agenten steht, eine wichtige Rolle. Reasoning beschreibt vereinfacht die Fähigkeit des Modells, vorhandene Informationen zu analysieren, miteinander in Beziehung zu setzen und daraus sinnvolle Schlussfolgerungen abzuleiten. Ein bekanntes Muster für dieses Zusammenspiel von Reasoning und Aktionen ist ReAct („Reasoning and Acting“). Dabei wechseln sich Reasoning-Schritte und Aktionen ab. Das Modell berücksichtigt beispielsweise die Ergebnisse einer Suche und entscheidet auf dieser Grundlage, welcher Schritt als Nächstes erforderlich ist.
Vorteile und Grenzen von Agentic RAG
Bei der keyword-basierten Bildersuche sucht der Nutzer mit Begriffen oder kurzen Beschreibungen. Das ist eine klassische Form der Bildersuche, die hinter vielen bekannten Suchmaschinen steckt.
Dabei wird nicht unbedingt das Bild selbst analysiert. Das System sucht vor allem in den Textinformationen, die mit dem Bild verbunden sind. Dazu gehören zum Beispiel der Alt-Text, der Bildtitel, der Dateiname, Bildunterschriften oder auch der Text auf der Webseite in der Nähe des Bildes.
Man kann das als eine Art Anreicherung durch Metadaten verstehen. Das Bild wird also durch zusätzliche Informationen beschrieben, damit es später besser gefunden werden kann. Je genauer und strukturierter diese Informationen sind, desto besser kann das Bild über Text gefunden werden. Für die Suche können in diesem Fall Ansätze wie lexikalische Suche, semantische Suche oder eine Kombination aus beiden verwendet werden. Dieser Ansatz ist sehr nützlich für eine allgemeinere Bildersuche und Recherche.
Bei der Produktsuche in einem Online-Shop kann diese Art der Bildersuche eine wichtige Rolle spielen. Produktbilder werden besser gefunden, wenn sie mit passenden Produktnamen, Kategorien und Attributen verbunden sind.
Multi-Agentic RAG
Agentic RAG erweitert den Naive-RAG-Ansatz um agentische Komponenten, die den Ablauf flexibler gestalten können. Multi-Agentic RAG geht noch einen Schritt weiter: Hier arbeiten mehrere spezialisierte Agents zusammen und übernehmen unterschiedliche Aufgaben innerhalb des gesamten Prozesses.
Wie funktioniert Multi-Agentic RAG?
Anstatt alle Aufgaben einem einzelnen Agenten zu übertragen, werden bei Multi-Agentic RAG unterschiedliche Verantwortlichkeiten auf mehrere Agents verteilt. Jeder Agent kann dabei für einen bestimmten Aufgabenbereich zuständig sein. Ein Agent könnte beispielsweise interne Dokumente durchsuchen, ein anderer strukturierte Daten über SQL abfragen und ein weiterer aktuelle Informationen aus externen Quellen abrufen.
Damit die einzelnen Agents sinnvoll zusammenarbeiten, müssen ihre Aufgaben koordiniert werden. Eine mögliche Architektur setzt dafür einen übergeordneten Agenten ein, häufig als Orchestrator, Supervisor oder Manager bezeichnet. Dieser nimmt die Anfrage entgegen, entscheidet, welche spezialisierten Agents für die Bearbeitung benötigt werden, delegiert entsprechende Teilaufgaben und führt die zurückgegebenen Ergebnisse anschließend wieder zusammen.
Je nach Anfrage kann dabei nur ein spezialisierter Agent benötigt werden oder es können mehrere Agents nacheinander beziehungsweise gemeinsam an unterschiedlichen Teilaufgaben arbeiten. Multi-Agentic RAG ermöglicht damit eine stärkere Spezialisierung: Jeder Agent kann gezielt die Aufgaben übernehmen, für die er zuständig ist.
Beispiel einer Multi-Agentic-RAG-Architektur
Damit das Prinzip klarer wird, schauen wir uns eine mögliche Multi-Agentic-RAG-Architektur an, wie sie in Abbildung 1.2 dargestellt ist. Der Ablauf beginnt mit der Anfrage des Benutzers. Diese wird für die weitere Verarbeitung als Eingabe an das System übergeben und zunächst vom zentralen Retrieval Router Agent verarbeitet.
Zusätzlich besteht das Multi-Agentic-RAG-System aus drei spezialisierten Agents mit unterschiedlichen Aufgaben. In diesem Beispiel handelt es sich um Retrieval Agents, die jeweils auf unterschiedliche Informationsquellen zugreifen.
Als Koordinator kommt der Retrieval Router Agent als erster ins Spiel. Er analysiert die Anfrage und entscheidet, welche der spezialisierten Retrieval-Agents für die Bearbeitung benötigt werden. Auf Basis der Anfrage und der definierten Routing-Logik kann er einen einzelnen Retrieval-Agent auswählen oder die Bearbeitung auf mehrere Agents verteilen.
Wie in der Abbildung zu sehen ist, sind die einzelnen Retrieval-Agents jeweils auf bestimmte Informationsquellen und Suchverfahren spezialisiert:
- Retrieval Agent X kann über verschiedene Vector-Search-Tools auf unterschiedliche Datenquellen zugreifen und dort eine semantische Suche durchführen.
- Retrieval Agent Y ist auf die Websuche spezialisiert und kann aktuelle Informationen aus dem Internet abrufen.
- Retrieval Agent Z greift dagegen auf Kommunikationsquellen wie E-Mails oder Chat-Nachrichten zu.
Anders als in der zuvor betrachteten einfachen Agentic-RAG-Architektur liegt die Verantwortung für das Retrieval hier nicht bei einem einzelnen Agenten, sondern wird auf mehrere spezialisierte Agents verteilt. Der Retrieval Router Agent entscheidet, welche davon eingesetzt werden, während die ausgewählten Agents anschließend die für ihren Bereich vorgesehenen Tools verwenden, um die jeweilige Teilaufgabe zu bearbeiten.
Die von den Retrieval-Agents gefundenen Informationen werden anschließend zusammengeführt und dem Large Language Model als zusätzlicher Kontext zur Verfügung gestellt. Das LLM kann die Informationen aus den unterschiedlichen Quellen verarbeiten und daraus eine Antwort für den Benutzer generieren.
Eine solche Architektur kann zusätzlich um weitere Agents ergänzt werden, die beispielsweise die Qualität und Relevanz der gefundenen Informationen bewerten und bei Bedarf weitere Retrieval-Schritte anstoßen.
Die Abbildung zeigt damit ein wesentliches Prinzip von Multi-Agentic RAG: Unterschiedliche Retrieval-Aufgaben werden auf spezialisierte Agents verteilt, während ein zentraler Agent deren Einsatz koordiniert.
Beispiele und Grenzen von Multi-Agentic RAG
Multi-Agentic RAG eignet sich besonders für Anfragen, bei denen die benötigten Informationen nicht in einer einzigen Quelle zu finden sind. Spezialisierte Agents können gezielt auf unterschiedliche Informationsquellen zugreifen und dort die Informationen abrufen, die sie für ihre jeweilige Teilaufgabe benötigen. Darüber hinaus können durch die Spezialisierung der einzelnen Agenten Aufgaben wie Retrieval, Bewertung oder die Zusammenführung von Informationen gezielt auf verschiedene Agents verteilt werden.
Auf der anderen Seite kann Multi-Agentic RAG, ähnlich wie Agentic RAG, die Kosten und die Latenz erhöhen, da mehrere LLM-Aufrufe notwendig sein können. Gleichzeitig steigt die Komplexität des Systems, da mit einer zunehmenden Anzahl an Agents auch deren Koordination und Kommunikation aufwendiger werden.
Fazit und Ausblick
In diesem Beitrag haben wir gezeigt, wie sich RAG von einer festen Retrieval-Pipeline hin zu agentischen und Multi-Agent-Architekturen weiterentwickeln kann. Während Naive RAG einem klar definierten Ablauf folgt, kann Agentic RAG den Retrieval-Prozess flexibler steuern, Suchanfragen anpassen und mehrere Retrieval-Schritte durchführen. Multi-Agentic RAG geht noch einen Schritt weiter, indem unterschiedliche Aufgaben auf mehrere spezialisierte Agents verteilt werden.
Welche Architektur sinnvoll ist, hängt dabei stark vom jeweiligen Anwendungsfall ab. Nicht jeder Anwendungsfall erfordert Agentic RAG oder sogar Multi-Agentic RAG. Je mehr Agents, Tools und mögliche Verarbeitungsschritte in einem System zusammenkommen, desto komplexer wird in der Regel auch das Gesamtsystem. Gleichzeitig können die Anzahl der LLM-Aufrufe sowie die Anforderungen an Koordination und Orchestrierung steigen.
Agents können dabei nicht nur Informationen abrufen, sondern auch bestimmen, welche Schritte für die weitere Bearbeitung notwendig sind. Agentic RAG und Multi-Agentic RAG ermöglichen im Vergleich zu Naive RAG eine flexiblere und dynamischere Verarbeitung von Anfragen. Gerade bei Anwendungen, die mehrere Informationsquellen, unterschiedliche Suchverfahren oder mehrere aufeinanderfolgende Schritte erfordern, eröffnen sich dadurch neue Möglichkeiten für den Aufbau leistungsfähiger RAG-Systeme.
