Ein einfaches RAG sucht genau einmal: Frage rein, ein Schwung Treffer, Antwort raus. Für eine glatte Frage reicht das. Für „vergleich unsere Garantiebedingungen von 2023 und 2024” reicht es nicht — das braucht zwei Suchen. Für „was ist die Strafe bei X” auch nicht, wenn das Modell erst herausfinden muss, was X überhaupt ist, bevor es nach der Strafe sucht. Echte Fragen brauchen oft mehr als einen Blick.
Agentic RAG gibt dem Modell die Suche als Werkzeug in die Hand und lässt es selbst entscheiden: ob es sucht, womit, ob noch einmal, wann es genug hat. Aus der starren Pipeline wird eine Schleife. Das ist mächtig — und du bezahlst die Macht mit Kontrolle. Genau diesen Handel zeige ich hier.
Warum einmal suchen oft nicht reicht
Es gibt ein paar Fragetypen, an denen die einmalige Suche zuverlässig scheitert. Mehrteilige Fragen, die zwei oder drei getrennte Stellen brauchen. Aufeinander aufbauende Fragen, bei denen das erste Ergebnis erst zeigt, wonach als Nächstes zu suchen ist. Fragen mit der falschen Formulierung, bei denen der Wortlaut des Nutzers nicht zu dem im Dokument passt und das Modell besser umformulieren und neu suchen würde. Und der umgekehrte Fall: Fragen, die gar keine Suche brauchen, weil das Modell sie ohnehin beantworten kann.
Ein starres RAG behandelt all das gleich — einmal suchen, egal was. Genau deshalb wird die Antwort bei den anspruchsvollen Fragen lückenhaft. Was fehlt, ist die Fähigkeit, die Suche an die Frage anzupassen.
Suche wird zum Werkzeug
Der Schritt ist im Kern derselbe wie bei jedem Tool-Use: Das Modell bekommt die Suche als Werkzeug mit einer klaren Beschreibung und entscheidet selbst, wann und wie es sie nutzt. Es kann mehrteilige Fragen zerlegen, die Suchanfrage umformulieren, nach einem Ergebnis prüfen, ob es reicht, und gegebenenfalls noch einmal suchen.
Damit wird aus der Pipeline eine Schleife: suchen, lesen, entscheiden, vielleicht wieder suchen, antworten. Oft kommt mehr als nur die Suche dazu — ein zweiter Index, ein Rechner, eine weitere Quelle. Das Modell orchestriert, statt einen festen Ablauf abzuarbeiten. Dieselbe Tool-Use-Disziplin wie bei einem MCP-Server, nur aufs Nachschlagen gerichtet.
Macht gegen Kontrolle
Hier sitzt der eigentliche Handel. Die Schleife beantwortet komplexe Fragen ungleich besser — aber du gibst die Vorhersagbarkeit auf. Das Modell kann sich verrennen, zu oft suchen, zu früh aufhören, in ein Kaninchenloch laufen. Ein starres RAG tut immer dasselbe und ist langweilig zuverlässig. Das agentische ist fähiger und wilder.
Deshalb ist die wichtigste Schraube die Obergrenze: wie oft das Modell suchen darf, bevor es antworten muss. Ohne diesen Deckel dreht es im Zweifel Runden und verbrennt Tokens, ohne je fertig zu werden. Macht ohne Grenze ist hier kein Vorteil, sondern ein Kostenrisiko.
Wie ich das angehe
Das Modell bekommt die Suche als Werkzeug, dessen Beschreibung sagt, wann und wie es sie nutzt. Das ist Prompt-Arbeit, wie bei jedem Tool-Use.
Das Modell wählt, ob es sucht, mit welcher Anfrage, und formuliert um, wenn der wörtliche Nutzertext schlechte Treffer bringt.
Eine feste Obergrenze, wie oft gesucht werden darf. Danach wird mit dem geantwortet, was da ist.
Ist genug da, antworten. Passt nichts, ehrlich abwinken statt endlos weitersuchen. Das Wann-aufhören ist der schwierige Teil.
Die Kette der Entscheidungen mitschreiben — welche Anfragen, warum. Sonst ist ein Fehler in der Schleife kaum zu finden.
Wo es in der Praxis kippt
Es verstärkt schlechtes Retrieval. Das ist der wichtigste Punkt. Sucht deine Grundsuche schlecht, macht der Agent nicht weniger, sondern mehr schlechte Aufrufe. Agentic RAG auf einem schwachen Retriever ist schlechter als ein einfaches RAG, nicht besser. Erst Trefferquote und Sortierung in Ordnung bringen, dann die Schleife.
Kosten und Wartezeit explodieren. Jeder Schritt ist ein Modell-Aufruf plus eine Suche. Eine mehrstufige Schleife kostet schnell ein Vielfaches der einmaligen Suche. Der Deckel ist nicht optional.
Wann ist genug? Das Modell überzeugt sich mal, es sei fertig, obwohl es nicht ist, mal sucht es weiter, obwohl es aufhören sollte. Dieses Urteil ist schwer und gehört bewusst eingestellt.
Schwerer zu debuggen. Ein einmaliges RAG kannst du anschauen: Frage, Treffer, Antwort. Beim agentischen musst du einer ganzen Entscheidungskette folgen. Ohne mitgeschriebenen Verlauf bist du blind.
Überengineering. Die meisten Fragen beantwortet ein einmaliges RAG bestens. Die Schleife nur dort einsetzen, wo die Frage sie wirklich braucht — nicht überall, weil es schlau klingt.
Was es kostet — und woran
Hier sind die Kosten die Schlagzeile. Eine mehrstufige Schleife ist ein Vielfaches der einmaligen Suche, in Tokens und in Wartezeit. Das lohnt sich nur für Fragen, die es wirklich brauchen — Vergleiche, mehrstufige Recherchen —, nicht für simple Nachschlage-Fragen.
Und es lohnt sich nur, wenn das Fundament steht: eine Grundsuche, die trifft, und eine Bewertung, die zeigt, dass sie trifft. Wer dir Agentic RAG als nächste Stufe verkauft, ohne dass Retrieval und Messung darunter solide sind, baut das Dach vor den Mauern. Greif nicht standardmäßig danach.
Wie ein ehrlicher Einstieg aussieht
Nimm genau die Fragen, an denen dein einmaliges RAG heute scheitert — die mehrteiligen, die vergleichenden. Gib dem Modell für die die Suche als Werkzeug, mit einer festen Schritt-Obergrenze. Dann miss drei Dinge: Beantwortet es die schweren Fragen jetzt? Zu welchen Kosten pro Antwort? Und hört es vernünftig auf, statt zu kreisen? Für die einfache Mehrheit der Fragen behältst du das einmalige RAG. Die Schleife ist das Spezialwerkzeug, nicht der neue Standard.
Worauf du achtest, wenn dir das jemand baut
- Stehen Grundsuche und Bewertung solide, bevor die Schleife draufkommt? Sonst verstärkt sie nur den Mangel — das K.-o.-Kriterium.
- Sind die Schritte gedeckelt, oder kann das Modell endlos suchen?
- Hört es auf und winkt ab, wenn nichts passt, statt zu kreisen oder zu erfinden?
- Ist der Entscheidungsverlauf nachvollziehbar für die Fehlersuche?
- Wird die Schleife nur dort eingesetzt, wo nötig, oder pauschal über alles gelegt?
Die Entscheidungs-Disziplin kannst du als Prompt vorgeben. Im Bau läuft das mit einem echten Such-Werkzeug; der Prompt ist der Kopf der Schleife:
Du beantwortest Fragen mit Hilfe eines Such-Werkzeugs. Du entscheidest selbst, ob und wie oft du suchst.
Regeln:
1. Überlege erst, ob die Frage überhaupt eine Suche braucht. Triviales beantwortest du direkt.
2. Zerlege mehrteilige Fragen und suche gezielt je Teil. Formuliere die Suchanfrage klar, nicht
zwingend wörtlich wie die Nutzerfrage, wenn das bessere Treffer bringt.
3. Prüfe nach jedem Ergebnis: reicht das zum Antworten, oder fehlt noch etwas Konkretes?
4. SUCHE HÖCHSTENS [N]-MAL. Danach antwortest du mit dem, was du hast.
5. Findest du die Antwort nicht in den Ergebnissen, sag das offen. Erfinde nichts und such nicht endlos.
Zeig kurz deinen Suchweg (welche Anfragen, warum), dann die belegte Antwort.Bei dir scheitern die zusammengesetzten Fragen — Vergleiche, mehrere Schritte — am einfachen RAG, das nur einmal sucht? Dann reden wir darüber, ob dein Retrieval solide genug ist, um dem Modell die Suche selbst in die Hand zu geben, und wo die Obergrenze sitzen muss.