Agentisches RAG: wenn die KI nicht nur sucht, sondern mitdenkt

Viele Unternehmen starten mit ChatGPT oder einem internen Assistenten und stellen schnell fest: Die Antworten klingen gut, passen aber nicht zu unseren Verträgen, Produkten oder Prozessen. Die Lösung heißt oft „RAG". In Projekten sehen wir zunehmend den nächsten Schritt: agentisches RAG. Der Unterschied ist nicht nur Technik, sondern ob das System eine Frage mechanisch beantwortet oder sie Schritt für Schritt bearbeitet.

Kurz: Was ein Sprachmodell allein kann (und was nicht)

Ein großes Sprachmodell (LLM) wurde auf riesigen Textmengen trainiert. Es formuliert flüssig, fasst zusammen, übersetzt, skizziert Code. Es hat dabei keinen garantierten Zugriff auf Ihre aktuellen internen Dokumente und kein eingebautes „Ich prüfe das noch einmal". Es kann plausibel klingende Antworten erzeugen, die nicht in Ihren Quellen stehen. Das ist kein böser Wille, sondern eine Eigenheit des Verfahrens: Das Modell wählt die statistisch wahrscheinlichste Fortsetzung, nicht die belegbare. Richtig und wahrscheinlich sind zwei verschiedene Dinge.

Für Brainstorming im Alltag reicht das aus. Für Compliance, Support, Engineering oder Einkauf braucht man etwas anderes.

Was ist RAG?

RAG steht für Retrieval-Augmented Generation, auf Deutsch: Antworten mit abgerufenen Quellen statt nur aus dem Gedächtnis des Modells.

Der Ablauf in der einfachen Form:

1. Der Nutzer stellt eine Frage.
2. Das System sucht in einer Wissensbasis (PDFs, Wiki, Tickets, Datenbank-Exporte) nach passenden Textstücken.
3. Diese Stücke werden dem Modell als Kontext mitgegeben.
4. Das Modell formuliert die Antwort und kann idealerweise zitieren, aus welchem Dokument ein Satz stammt.

RAG löst damit vor allem ein Problem: Aktualität und Firmenwissen. Ihre Regeln von 2026 landen in der Antwort, nicht die Trainingswelt von 2023. Gleichzeitig bleibt RAG in der Basisvariante oft ein Schuss: eine Suche, ein Prompt, eine Antwort.

Was heißt „agentisch"?

Ein Agent (im KI-Sinne) ist ein System, das eine Aufgabe zerlegt, Entscheidungen trifft und Werkzeuge nutzt, statt nur einmal zu antworten. „Agentisches RAG" kombiniert beides:

• Retrieval bleibt die Quelle der Wahrheit (Ihre Dokumente, nicht das Bauchgefühl des Modells).
• Agenten-Logik steuert, wie gesucht, wann nachgefragt und ob die Antwort reicht.

Typische Schritte, die ein Agent ausführen kann:

• Die Frage umformulieren oder in Teilfragen splitten („Was gilt für Vertrag A vs. B?").
• Mehrfach suchen, mit anderen Stichworten oder in anderen Indizes (Handbuch vs. Tickets).
• Ergebnisse bewerten („Reicht dieser Abschnitt?", „Widerspricht sich etwas?").
• Bei Lücken nachfragen beim Nutzer oder eine zweite Suche starten.
• Optional Tools aufrufen: Rechner, SQL, API, Freigabe-Workflow.

Statt „einmal suchen und hoffen" entsteht ein kontrollierter Ablauf, der eher an eine gute Recherche erinnert als an Autovervollständigung.

Warum das besser ist als „nur ChatGPT"

Für normale Anwender heißt das: Antworten sind nachvollziehbarer, weil sie an Textstellen in Ihren Systemen hängen. Und schwierige Fragen werden nicht mit einer hübschen Erfindung abgefedert, sondern mit „Ich finde dazu nichts Verlässliches in Quelle X".

Warum das oft besser ist als klassisches RAG

Klassisches RAG scheitert in der Praxis oft an banalen Dingen:

• Die Frage ist mehrdeutig, die erste Suche trifft das falsche Kapitel.
• Die Antwort braucht Zahlen aus zwei Dokumenten oder eine Tabelle.
• Das relevante Wissen steht in Tickets, nicht im PDF-Handbuch.

Ein Agent kann iterieren: schlechte Treffer verwerfen, die Suchanfrage anpassen, eine andere Datenquelle wählen. Das kostet Rechenzeit und Geld, liefert aber häufig die robustere Antwort, gerade bei Fachfragen aus dem Mittelstand („Welche Garantie gilt bei Seriennummer …?").

Was agentisches RAG konkret löst

• Komplexe Fragen ohne Prompt-Engineering durch Endnutzer.
• Quellenpflicht in regulierten Bereichen (mit Audit-Spur, welche Dokumente genutzt wurden).
• Weniger erfundene Policies, wenn das System explizit prüft, ob ein Absatz existiert.
• Brücke zu Systemen: nicht nur Text, sondern z. B. Lagerbestand oder CRM-Status, wenn die Schnittstelle freigegeben ist.

Wo die Grenzen liegen

Agentisches RAG ist kein Allheilmittel.

• Kosten und Latenz: Mehr Schritte bedeuten mehr Modellaufrufe. Für Echtzeit-Chat mit vielen Nutzern muss man sorgfältig architektieren.
• Qualität der Wissensbasis: Schlecht gescannte PDFs, veraltete Wikis oder fehlende Berechtigungen ruinieren jeden Agenten. Die Ausgabe ist nur so gut wie die Eingabe.
• Evaluation: Man braucht Testfragen aus dem echten Betrieb und Metriken (Trefferquote, Zitiergenauigkeit). „Fühlt sich gut an" reicht nicht.
• Sicherheit: Tools und Datenbankzugriffe müssen abgesichert sein, sonst automatisiert der Agent das Falsche schneller.
• Halluzinationen: Sie werden seltener, verschwinden aber nicht. Besonders bei Zusammenfassungen über viele Dokumente bleibt Vorsicht geboten.

Manchmal reicht einfaches RAG völlig aus, zum Beispiel für einen FAQ-Bot mit 200 gut gepflegten Artikeln. Agentik lohnt sich, wenn Fragen heterogen, Quellen verteilt oder die Fehlerkosten hoch sind.

Was wir bei wonk.ai daraus ableiten

Wir bauen keine Demo, die einmal beeindruckt, sondern Systeme, die im Betrieb prüfbar bleiben: klare Datenräume, nachvollziehbare Retrieval-Schritte, und Agenten-Logik nur dort, wo sie gegenüber „einmal suchen" echten Mehrwert bringt. Oft starten wir mit schlankem RAG und erweitern gezielt, wenn die Testfragen es verlangen.

Wenn Sie abwägen, ob RAG oder agentisches RAG für Ihren Use Case passt, melden Sie sich. Wir gehen die Fragen gerne anhand eines konkreten Beispiels aus Ihrem Alltag durch.