KI-gestützte Suche für KI-Agenten: Grounded Search vs. traditionelles RAG — Was funktioniert wirklich?

Ihr KI-Agent kann brillant schlussfolgern — doch fragen Sie ihn nach aktuellen Wettbewerbspreisen, und er versagt. Warum RAG nicht die Lösung ist und was Grounded Search für agentische Workflows verändert.

by AnyCap

Diesen Moment haben Sie wahrscheinlich schon erlebt: Ihr Coding-Agent hat gerade ein elegantes Refactoring geschrieben, ein perfektes Architekturdiagramm generiert, und dann fragen Sie: „Was verlangt unser Top-Wettbewerber derzeit?" — und er erfindet entweder etwas oder sagt, seine Trainingsdaten seien seit sechs Monaten veraltet.

Es ist nicht die Schuld des Modells. Claude, GPT, Gemini — sie alle sind brillant im logischen Denken. Aber keiner von ihnen kann eigenständig das Live-Web sehen. Also basteln Entwickler Google-API-Schlüssel, Vektordatenbanken und LLM-Aufrufe zusammen, um etwas zu bauen, das ein einziger Befehl sein sollte.

Das Problem hat einen Namen: die Suchlücke in der KI-Agenten-Infrastruktur. Und die Lösung sind nicht mehr RAG-Pipelines, sondern ein völlig anderer Ansatz.

RAG wurde für interne Dokumente gebaut, nicht für das Internet

Retrieval-Augmented Generation funktioniert wunderbar, wenn Ihre Daten in einer Vektordatenbank liegen und sich einmal pro Quartal ändern. Mitarbeiterhandbücher, Produktspezifikationen, historische Daten. Indizieren, abfragen, fertig.

Das Problem beginnt, wenn Sie etwas brauchen, das nicht in Ihrem Index steht.

Ein Wettbewerber führt eine neue Preisstufe ein. Eine Verordnung ändert sich. Eine Bibliothek, von der Sie abhängen, hat einen kritischen Bug, über den ganz Hacker News spricht. Ihre RAG-Pipeline weiß nichts davon. Sie kann es nicht wissen — sie sieht nur, was Sie beim letzten Neuaufbau des Index eingespeist haben.

Ich habe Teams beobachtet, die versuchen, das mit schnelleren Rebuild-Zyklen zu beheben. Dann mit hybrider Suche. Dann mit getrennten Pipelines für interne und externe Daten. Jede Schicht macht das System leistungsfähiger — und brüchiger. Jede neue Datenquelle ist eine weitere Integration. Jede Integration ist etwas, das um 2 Uhr nachts kaputtgeht.

Das eigentliche Problem ist nicht, dass RAG schlecht ist. Es ist, dass RAG entwickelt wurde, um zu beantworten: „Was sagt unsere Richtlinie zu X?" — nicht: „Was passiert gerade in der Welt?"

Was Grounded Search tatsächlich tut

Grounded Search ruft Live-Informationen aus dem Web ab, und zwar genau in dem Moment, in dem Sie fragen. Nicht aus einem Index. Nicht aus einem Snapshot. Sondern aus dem, was gerade öffentlich verfügbar ist, mit einer Quellen-URL zu jeder Behauptung.

Es ähnelt eher der Art, wie Sie selbst recherchieren würden: suchen, einige Quellen durchsehen, eine Antwort synthetisieren und angeben, woher jede Information stammt. Der Unterschied: Ihr Agent erledigt das in Sekunden statt in Minuten.

Ein kurzer Vergleich, um den Unterschied greifbar zu machen:

Aspekt Traditionelles RAG Grounded Search
Datenherkunft Ihre indexierten Dokumente Das Live-Web, genau jetzt
Wissensumfang Was Sie indexiert haben Was öffentlich zugänglich ist
Veraltungszeitpunkt Sobald sich die Quelle ändert Veraltet nicht — holt jedes Mal frisch
Einrichtung Indexierungs-Pipeline, Vektordatenbank, Chunking Ein CLI-Befehl

RAG bleibt überlegen für private Daten — Kundendaten, interne Finanzen, alles, was nicht ins öffentliche Internet gelangen darf. Die praktische Architektur, bei der die meisten Teams landen: RAG für internes Wissen, Grounded Search für externen Kontext. Der Agent wählt je nach Fragestellung aus.

Wie ein Agent es tatsächlich nutzt

Die CLI ist bewusst einfach, weil Agenten keine Bibliotheken importieren — sie führen Befehle aus.

anycap search "Acme Corp Enterprise-Preise Q2 2026" \
  --citations \
  --output acme-preise.json

Der Agent erhält eine strukturierte Antwort mit Zitaten. Er kann die Antwort an den Nutzer weitergeben, in den nächsten Schritt eines Workflows einspeisen oder für später speichern. Kein Hantieren mit API-Schlüsseln. Kein Python-SDK, das man wrappen muss. Einfach ein Werkzeug, das der Agent genauso aufruft wie ls oder git diff.

Das eigentlich Mächtige daran ist nicht die Suche allein. Es ist, dass die Suche zu einem Werkzeug unter vielen wird, die der Agent verketten kann. Wettbewerbspreise suchen. Tiefenrecherche zur Marktlandschaft. Eine Vergleichsgrafik generieren. Alles in einen Bericht zusammenstellen. Ihn veröffentlichen.

Eine CLI. Eine Authentifizierung. Der Agent wechselt zwischen Fähigkeiten, ohne für jeden Schritt eigenen Integrationscode zu benötigen.

Ich habe dieses Muster besonders gut für Wettbewerbsmonitoring funktionieren sehen. Ein Agent prüft wöchentlich die Wettbewerbspreise, vergleicht mit der Vorwoche, markiert Änderungen und schickt eine Zusammenfassung in Slack. Ein Cron-Job, null Middleware.

Was bei der Auswahl eines Suchwerkzeugs wirklich zählt

Vergessen Sie für einen Moment Feature-Matrizen. Hier ist, was ich tatsächlich testen würde, wenn ich Grounded-Search-Werkzeuge evaluiere:

Zitiert es korrekt? Testen Sie 20 Anfragen, bei denen Sie die richtige Antwort kennen. Klicken Sie für jede die Zitate durch und prüfen Sie, ob sie tatsächlich das belegen, was das Werkzeug behauptet. Ein Werkzeug, das richtige Antworten mit falschen Zitaten liefert, ist gefährlicher als eines, das zugibt, es nicht zu wissen. Ich habe einen halben Tag damit verbracht, einer „Faktenbehauptung" eines Suchwerkzeugs nachzugehen, das eine Quelle zitierte, die das Gegenteil aussagte.

Wie schnell ist es wirklich? Nicht die Marketing-Latenz. Die P99-Latenz, wenn 50 Agenten gleichzeitig darauf zugreifen. Eine Agent-Pipeline, die 8 Sekunden pro Suchschritt wartet, frustriert alle Beteiligten.

Geht es elegant mit Grenzfällen um? Fragen Sie etwas Obskures. Etwas Aktuelles. Etwas, bei dem Quellen uneins sind. Ein gutes Werkzeug zeigt den Konflikt auf, statt die Meinungsverschiedenheit zu einem Durchschnittsbrei zu verrechnen.

CLI oder SDK? Das ist wichtiger, als es klingt. Agenten machen kein from x import y. Sie führen Befehle aus. Ein Werkzeug, das hinter einer Python-Bibliothek steckt, ist ein Werkzeug, das Ihr Agent nicht nutzen kann, ohne dass Sie zuerst einen Wrapper schreiben.

Warum das mehr zählt, als es klingt

Die Suchlücke ist keine kleine Unannehmlichkeit. Sie ist das größte einzelne Hindernis, das Agenten davon abhält, echte Recherche-Workflows zu bewältigen. Ein Agent, der denken, aber nicht suchen kann, ist wie ein Entwickler, dem Stack Overflow gesperrt wurde — fähig, aber abgeschnitten von den Informationen, die er wirklich braucht.

Die Lösung ist nicht kompliziert. Es ist nur nicht das, wonach die meisten Teams zuerst greifen, weil RAG vertraut ist und die Suchlücke erst dann offensichtlich wird, wenn Ihr Agent selbstbewusst falsche Informationen an jemanden liefert, der ihm vertraut hat.

Wenn Ihre Agenten an diese Wand stoßen — großartig mit internen Daten, aber sofort scheiternd, wenn sie etwas von außen brauchen — liegt es wahrscheinlich nicht an Ihrem Modell. Wahrscheinlich nicht an Ihren Prompts. Sondern daran, dass die Sucharchitektur für ein anderes Problem gebaut wurde.

Weiterführende Lektüre: