Agentische RAG-Pipelines mit Claude designen

1. Der Unterschied zu klassischem RAG

Klassisches RAG folgt einem festen Ablauf: Anfrage einbetten, ähnlichste Chunks abrufen, Ergebnis in den Prompt einfügen, Antwort generieren. Dieser Ablauf läuft immer genau einmal durch, unabhängig davon, ob die abgerufenen Chunks tatsächlich ausreichen, um die Frage zu beantworten. Bei einfachen Faktenfragen funktioniert das zuverlässig, bei komplexeren Anfragen mit mehreren Teilaspekten liefert ein einziger Retrieval-Durchlauf oft nur einen Teil der benötigten Information.

Agentisches RAG gibt Claude die Kontrolle über den Retrieval-Prozess selbst. Statt eines festen Ablaufs bekommt das Modell ein oder mehrere Retrieval-Tools zur Verfügung gestellt und entscheidet eigenständig, wann es sie aufruft, mit welchen Suchbegriffen, und ob ein weiterer Abruf nötig ist, um eine vollständige Antwort zu formulieren. Der entscheidende Unterschied liegt also nicht im verwendeten Index, sondern in der Kontrolle über den Ablauf.

2. Wann klassisches RAG an seine Grenzen stößt

Klassisches RAG stößt typischerweise dann an Grenzen, wenn eine Anfrage mehrere unabhängige Teilfragen enthält, deren Antworten aus unterschiedlichen Dokumenten stammen, etwa Vergleiche die Rückgaberichtlinie von Produkt A mit der von Produkt B und erkläre den Unterschied. Ein einzelner Retrieval-Schritt liefert dabei oft nur Treffer zu einem der beiden Produkte, weil beide Suchbegriffe um dieselben Top-Positionen konkurrieren.

Auch bei Anfragen, die eine erste grobe Antwort erfordern, um daraus die eigentliche, präzisere Suchanfrage abzuleiten, versagt ein einmaliger Abruf strukturell. Ein Beispiel: Zuerst muss ermittelt werden, welche Produktversion ein Kunde nutzt, bevor die passende Dokumentation dazu gesucht werden kann. Genau für solche mehrstufigen Abhängigkeiten ist agentisches RAG konzipiert.

3. Tool-Definitionen für Retrieval-Schritte

Die Qualität einer agentischen RAG-Pipeline hängt maßgeblich davon ab, wie präzise das Retrieval-Tool beschrieben ist. Eine vage Beschreibung wie durchsucht die Wissensdatenbank führt dazu, dass Claude das Tool entweder zu selten oder mit ungeeigneten Suchbegriffen aufruft. Eine klare Beschreibung der erwarteten Eingabeparameter, der Filtermöglichkeiten und der Rückgabestruktur verbessert die Trefferqualität spürbar.

Sinnvoll ist außerdem, mehrere spezialisierte Retrieval-Tools statt eines einzigen generischen Tools anzubieten, etwa getrennt nach Produktdokumentation, Support-Tickets und Rechtstexten. Das Modell trifft dann eine explizite Entscheidung, welche Quelle zur jeweiligen Teilfrage passt, statt alles in einen gemeinsamen, weniger präzisen Index zu vermischen.

{
  "name": "search_product_docs",
  "description": "Durchsucht ausschließlich die technische Produktdokumentation nach relevanten Abschnitten. Nicht für Support-Tickets oder rechtliche Texte geeignet. Gib präzise, spezifische Suchbegriffe an, keine ganzen Sätze.",
  "input_schema": {
    "type": "object",
    "properties": {
      "query": {"type": "string", "description": "Präzise Suchbegriffe, z.B. 'Webhook Retry-Logik'"},
      "product": {"type": "string", "description": "Produktname zur Eingrenzung, z.B. 'checkout-api'"},
      "max_results": {"type": "integer", "default": 5}
    },
    "required": ["query"]
  }
}

4. Der Agentenloop: Wie Claude selbst über weitere Abfragen entscheidet

Im Kern läuft eine agentische RAG-Pipeline als klassischer Tool-Use-Loop: Claude erhält die Nutzeranfrage samt verfügbaren Retrieval-Tools, entscheidet, ob und welches Tool es aufruft, erhält das Ergebnis zurück in den Kontext und entscheidet erneut, ob eine weitere Abfrage nötig ist oder ob genug Information vorliegt, um zu antworten. Dieser Loop kann sich über mehrere Runden fortsetzen, bis das Modell eine finale Textantwort ohne weiteren Tool-Aufruf liefert.

Entscheidend für die Zuverlässigkeit ist der System-Prompt, der klarstellt, wann eine weitere Abfrage sinnvoll ist und wann das Modell mit den vorhandenen Informationen antworten soll. Ohne diese Leitplanke neigt das Modell entweder dazu, bei bereits ausreichendem Kontext unnötig weitere Abfragen zu starten, oder umgekehrt, mit unvollständiger Information vorschnell zu antworten.

messages = [{"role": "user", "content": user_query}]

while True:
    response = client.messages.create(
        model="claude-opus-4-5",
        system=AGENT_SYSTEM_PROMPT,
        tools=[search_product_docs, search_support_tickets],
        messages=messages,
        max_tokens=2048,
    )
    messages.append({"role": "assistant", "content": response.content})

    tool_calls = [b for b in response.content if b.type == "tool_use"]
    if not tool_calls:
        break  # Claude hat entschieden, dass genug Kontext vorliegt

    tool_results = [run_retrieval_tool(tc) for tc in tool_calls]
    messages.append({"role": "user", "content": tool_results})

5. Mehrstufige Retrieval-Ketten: ein konkretes Szenario

Ein realistisches Szenario: Ein Kunde fragt, warum ein bestimmter API-Endpunkt in seiner Umgebung einen 429-Fehler zurückgibt. Im ersten Schritt ruft Claude die allgemeine API-Dokumentation zum Rate-Limiting ab. Die gefundenen Informationen reichen aber nicht, um die konkrete Fehlerursache zu erklären, weil sie keine kundenspezifischen Limits enthalten.

Claude erkennt diese Lücke selbst und stellt in einem zweiten Schritt eine gezieltere Abfrage an ein separates Tool, das Support-Ticket-Historie durchsucht, um herauszufinden, ob für diesen Kunden ein individuelles Rate-Limit konfiguriert ist. Erst mit beiden Informationsquellen zusammen lässt sich eine vollständige, korrekte Antwort formulieren. Genau diese Fähigkeit, eine Wissenslücke selbst zu erkennen und gezielt zu schließen, unterscheidet agentisches von klassischem RAG.

6. Grenzen agentischer RAG-Pipelines

Mehr Kontrolle über den Retrieval-Prozess bedeutet auch mehr Unsicherheit im Ablauf. Jede zusätzliche Abfragerunde erhöht Latenz und Tokenkosten, und ohne klare Begrenzung kann das Modell theoretisch beliebig viele Abfragen hintereinander auslösen, etwa wenn die Suchergebnisse konsistent unpassend sind und das Modell wiederholt neue Formulierungen versucht.

Ein weiteres Risiko ist die Nachvollziehbarkeit: Bei einem einzelnen Retrieval-Schritt ist leicht erkennbar, welche Dokumente in die Antwort eingeflossen sind. Bei drei oder vier aufeinanderfolgenden, vom Modell selbst gewählten Abfragen wird die Kette komplexer, und ohne strukturiertes Logging lässt sich im Nachhinein schwer rekonstruieren, warum das Modell zu einer bestimmten Schlussfolgerung gekommen ist.

7. Debugging mehrstufiger Agenten-Ketten

Debugging beginnt mit vollständigem Tracing jeder Runde des Agentenloops: welcher Tool-Aufruf mit welchen Parametern erfolgte, welche Ergebnisse zurückkamen, und welche Zwischenüberlegung Extended Thinking gegebenenfalls dazu formuliert hat. Ohne diese Aufzeichnung bleibt bei einer fehlerhaften Endantwort unklar, ob das Problem im Retrieval, in der Zwischeninterpretation oder in der finalen Formulierung lag.

Ein praktikabler Debugging-Ansatz ist, jede Tool-Aufruf-Runde einzeln zu isolieren und Claude im Nachhinein zu fragen, ob die gewählte Suchanfrage aus heutiger Sicht sinnvoll war und welche alternative Formulierung bessere Treffer geliefert hätte. Diese retrospektive Analyse deckt häufig auf, dass die Tool-Beschreibung selbst unklar war, statt dass das Modell grundsätzlich falsch entschieden hat.

Prompt zur retrospektiven Analyse eines fehlgeschlagenen Laufs:

Hier ist der vollständige Trace eines Agentenloops mit 3 Tool-
Aufrufen und der finalen (falschen) Antwort: <Trace einfügen>

Analysiere Schritt für Schritt: War jede Suchanfrage sinnvoll
formuliert? An welcher Stelle hätte eine andere Formulierung
bessere Treffer geliefert? War die Tool-Beschreibung präzise
genug, um die richtige Entscheidung zu ermöglichen?

8. Guardrails: Maximale Schrittzahl, Timeout und Fallback

Jede agentische RAG-Pipeline sollte eine harte Obergrenze für die Anzahl der Retrieval-Runden pro Anfrage haben, üblicherweise drei bis fünf, um unkontrollierte Kostenexplosion und übermäßige Latenz zu vermeiden. Wird die Grenze erreicht, ohne dass genug Information vorliegt, sollte die Pipeline eine ehrliche Antwort liefern, dass die Frage nicht vollständig beantwortet werden konnte, statt eine unvollständig recherchierte Antwort als final auszugeben.

Zusätzlich empfiehlt sich ein Timeout pro einzelnem Tool-Aufruf sowie ein klar definierter Fallback-Pfad, etwa die Weiterleitung an einen menschlichen Support-Mitarbeiter, wenn die Pipeline nach der maximalen Schrittzahl weiterhin keine ausreichend fundierte Antwort formulieren kann.

9. Evaluation: Wie sich die Qualität agentischer RAG-Antworten messen lässt

Klassische RAG-Metriken wie Trefferquote pro Retrieval-Schritt reichen bei agentischem RAG nicht aus, weil die eigentliche Leistung in der Entscheidungsfolge liegt, nicht in einem einzelnen Abruf. Sinnvolle Evaluationsmetriken umfassen deshalb zusätzlich die durchschnittliche Anzahl benötigter Schritte pro Anfragetyp, die Rate an Anfragen, die das Schrittlimit ohne vollständige Antwort erreichen, und die Konsistenz der Endantwort bei mehrfacher Ausführung derselben Anfrage.

Ein belastbares Evaluationsset besteht aus Anfragen, die bewusst mehrere Teilfragen kombinieren und damit ausschließlich mit mehrstufigem Retrieval korrekt beantwortbar sind. Nur so lässt sich messen, ob die agentische Pipeline tatsächlich den erhofften Mehrwert gegenüber klassischem, einmaligem RAG liefert, statt nur zusätzliche Kosten ohne messbaren Qualitätsgewinn zu verursachen.

10. Zusammenfassung

11. FAQ: Agentische RAG-Pipelines: Das Wichtigste auf einen Blick