Agentic RAG ersetzt ein einzelnes Retrieval durch eine Schleife: Das Modell holt Daten, liest sie, entscheidet, dass es mehr braucht, holt erneut Daten, und wiederholt das, bis es zufrieden ist. Jeder Hop ist ein vollständiger Modell-Roundtrip plus eine Suche, und die Hops sind sequenziell, weil jeder vom vorherigen abhängt. Bei den meisten Fragen kauft man sich damit eine marginal bessere Antwort zum Mehrfachen der Latenz, wenn eine gut konstruierte Query denselben Kontext in einem einzigen Durchlauf geliefert hätte. Multi-Hop-Retrieval ist ein echtes Werkzeug für eine schmale Klasse von Fragen, und ein Standard, der überall sonst still die Antwortzeit verdreifacht.

Die Umdeutung: Agentic Retrieval tauscht Latenz gegen die Fähigkeit, eine Frage zur Laufzeit zu zerlegen. Dieser Tausch lohnt sich nur, wenn die Frage tatsächlich Zerlegung braucht. Die meisten brauchen das nicht, und die Schleifen-Steuer auf Fragen zu zahlen, die eine einzige Query beantwortet, ist der häufigste Grund, warum RAG-Systeme ohne Gewinn langsam werden.

Woher die Latenz kommt

Single-Pass-RAG ist ein Embedding, eine Vektorsuche, ein Modellaufruf. Agentic RAG ist eine Schleife, und die Schleife ist konstruktionsbedingt seriell: Das Modell kann die zweite Query erst stellen, wenn es die Ergebnisse der ersten gelesen hat. Die Wall-Clock-Kosten sind also nicht ein Retrieval plus eine Generierung, sondern die Summe aus der Suche jedes Hops, dem Modellaufruf jedes Hops, um zu entscheiden, was als Nächstes passiert, und der finalen Generierung. Drei Hops sind grob das Dreifache der Roundtrips, und weil jeder Modellaufruf auch den angesammelten Kontext neu liest, tendieren die Kosten pro Hop dazu, zu wachsen, statt konstant zu bleiben.

Nichts davon ist versteckte Arbeit, um die der Nutzer gebeten hat. Aus seiner Sicht ist es eine Frage, die jetzt acht statt zwei Sekunden dauert. Wenn diese acht Sekunden keine wesentlich bessere Antwort gekauft haben, wurde das Latenzbudget für nichts ausgegeben.

Eine gute Query schlägt meist eine clevere Schleife

Ein überraschender Anteil von Agentic RAG existiert, um eine schwache erste Query auszugleichen. Zieht das erste Retrieval die falschen Chunks, wird die Aufgabe der Schleife "merken, dass der Kontext schlecht ist, und besseren holen", was teure Fehlerbehebung ist. Die Query reparieren, und die Schleife hat oft nichts mehr zu tun.

Bevor man zu Multi-Hop greift, den Aufwand in den Single Pass stecken:

  • Die Query umschreiben. Ein billiger Modellaufruf, um eine unordentliche Nutzerfrage in eine saubere Suchanfrage zu verwandeln, verbessert das Retrieval mehr als ein zweiter Hop, zu einem Bruchteil der Latenz.
  • Mehr holen, dann reranken. Eine breitere Kandidatenmenge in einer Suche ziehen und sie herunter-reranken, statt mehrere enge Suchen nacheinander zu machen.
  • Die Chunks reparieren. Die meiste schlechte Retrieval-Qualität ist ein Chunking-Problem. Bessere Chunks lassen die erste Query treffen, und die Schleife wird überflüssig.

Das sind alles Single-Pass-Verbesserungen. Sie heben die Antwortqualität, ohne einen seriellen Roundtrip hinzuzufügen, das Gegenteil dessen, was die Schleife tut.

Wann Agentic Retrieval wirklich gewinnt

Die Schleife verdient sich ihre Latenz bei Fragen, die eine einzige Query wirklich nicht beantworten kann, weil die zweite Query von der Antwort auf die erste abhängt. Der klarste Fall ist Multi-Hop-Reasoning über Fakten, die man verketten muss: "Welche unserer Anbieter in der von der neuen Regulierung betroffenen Region stehen dieses Quartal zur Verlängerung an" ist eigentlich drei Lookups, bei denen jeder den nächsten eingrenzt, und kein einzelnes Retrieval hält die zusammengeführte Antwort.

Das Muster, nach dem man suchen sollte, ist eine echte Abhängigkeit zwischen Retrievals: Man kann die zweite Query nicht schreiben, bevor man das Ergebnis der ersten kennt. Ist diese Abhängigkeit echt, leistet die Schleife notwendige Arbeit, und die Latenz ist der Preis für eine Antwort, die man sonst nicht bekommen hätte. Fehlt sie, und meistens fehlt sie, ist die Schleife aufwendige Maschinerie für eine Frage, die eine einzige Query erledigt hätte.

Pro Frage entscheiden, nicht pro System

Der Fehler ist, Agentic Retrieval zum Standard für jede Anfrage zu machen. Ein besseres Design routet: billige Fragen nehmen den Single Pass, und nur Fragen, die ein Zerlegungssignal zeigen, mehrere Entitäten, eine verkettete Bedingung, ein explizites "vergleiche über", eskalieren zur Schleife. Ein kleiner Klassifikator oder sogar eine Heuristik vor dem Retrieval kann diese Entscheidung treffen. Das Ziel ist, die Multi-Hop-Steuer genau bei den Fragen zu zahlen, die sich dafür auszahlen, und nie bei denen, die es nicht tun.

Fazit

Agentic RAG ist nicht falsch, es wird überangewendet. Es macht Retrieval zu einer seriellen Schleife von Modell-Roundtrips, und für die große Mehrheit der Fragen, die eine gute Query beantwortet, ist diese Schleife reine Latenz. Den Aufwand zuerst in den Single Pass stecken: die Query umschreiben, breiter holen und reranken, die Chunks reparieren. Multi-Hop für Fragen mit einer echten Abhängigkeit zwischen Retrievals aufheben, und pro Frage dorthin routen, statt das ganze System standardmäßig hineinzuschicken. Das schnellste RAG-System ist das, das nur dann schleift, wenn die Frage wirklich einen zweiten Blick braucht.

Weiterlesen

Für die Infrastruktur hinter Retrieval mit niedriger Latenz im großen Maßstab gibt es die Cloud-Field-Notes auf ercan.cloud, und den Hub auf ercanermis.com.