RAG-Agent-Pattern: Antworten auf Basis von Quellen

Kern des Patterns

RAG Agent ist ein Pattern, bei dem der Agent zuerst relevante Quellen findet und dann darauf basierend antwortet - statt sich nur auf das parametrische Modellgedächtnis zu stützen.

Wann einsetzen: wenn die Antwort auf aktuellen Dokumenten und Quellenangaben basieren muss, nicht nur auf Modellgedächtnis.

Statt "aus dem Kopf des Modells" zu antworten, ergänzt RAG einen eigenen Schritt:

• Fakten in der Wissensbasis finden
• die relevantesten Fragmente auswählen
• mit Quellen antworten

Problem

Stell dir vor, ein Nutzer fragt:

"Welches SLA gilt für den Enterprise-Plan?"

Der Agent antwortet ohne Retrieval-Schritt, nur aus dem Modellgedächtnis.

Der Text kann sicher klingen, aber schwach belegt sein:

• veralteter Wert aus einer früheren Policy-Version
• vermischte Fakten aus verschiedenen Dokumenten
• keine Quelle zur Verifikation
• "präzise" Formulierung ohne Belege

Ohne kontrollierte Suche kann selbst eine plausible Antwort unbelegt sein.

Besonders riskant ist das für Support, Compliance, interne Policies und technische Dokumentation.

Genau hier liegt das Problem: ohne Quellenbindung kann der Agent eine überzeugende, aber nicht verifizierte Antwort geben, die schwer auditierbar ist.

Lösung

RAG ergänzt eine grounding-policy, die die Suche vor der Generierung steuert.

Analogie: Das ist wie Antworten mit offenem Buch. Zuerst suchst du die richtigen Seiten, dann formulierst du die Antwort. Wenn Quellen fehlen, ist Rückfrage besser als Erfinden.

Schlüsselprinzip: erst Quellen finden und verifizieren, dann antworten.

Der Agent kann Text vorschlagen, aber die grounding-policy bestimmt:

• welche Quellen gültig sind
• was in die Antwort darf
• wann ein Fallback statt "Dazudichten" nötig ist

Kontrollierter Ablauf:

1. Retrieval: relevante Fragmente finden
2. Ranking/Filterung: Rauschen und Duplikate entfernen
3. Quellenbindung: erlaubten Kontext aufbauen
4. Generierung: nur innerhalb dieses Kontexts antworten
5. Zitieren: Links/Metadata an Aussagen hängen

Das bringt:

• geringeres Halluzinationsrisiko bei factual-Anfragen
• Bindung der Antwort an Dokumente
• Verifizierbarkeit und Auditierbarkeit
• aktuellere Antworten bei Dokumentänderungen

Funktioniert gut, wenn:

• die Suche einen hochwertigen Index + Metadata hat
• Ranking zuverlässig Rauschen herausfiltert
• das Modell nicht außerhalb des geerdeten Kontexts antwortet
• bei fehlenden Quellen ein sicherer Fallback greift

Das Modell kann "antworten wollen", aber die RAG-Schicht entscheidet, ob die Beleglage ausreicht.

Wie es funktioniert

RAG ersetzt den Agenten nicht. Es ergänzt eine Wissensschicht vor der Antwortgenerierung.

Kernidee: wenn kein relevanter Kontext da ist, darf das System keine Antwort "erfinden".

Im Code sieht das so aus

chunks = retrieve(goal, top_k=8, filters={"tenant_id": tenant_id})
context = rerank_and_pack(goal, chunks, max_tokens=2500)

if not context:
    return ask_clarifying_or_fallback(goal)  # ohne relevanten Kontext generieren wir keine Antwort

answer = generate_grounded_answer(goal, context)  # Generierung nur aus gefundenen Quellen
answer = attach_citations(answer, context)

return answer

So sieht es bei der Ausführung aus

Goal: Welches SLA gilt für den Enterprise-Plan?

Retrieve:
- 6 Fragmente in Support-Policies gefunden
- nach Rerank bleiben 2 relevante übrig
- wenn relevante Fragmente = 0 -> Rückfrage / Fallback statt erfundener Antwort

Ground:
- Kontext aus zwei Auszügen aufgebaut
- Metadata ergänzt: doc_id, section, updated_at

Generate:
- Antwort nur aus diesen Quellen erstellt

Cite:
- Link auf "Support Policy v3.2" ergänzt

Wann es passt - und wann nicht

Passt

Passt nicht

Denn RAG fügt zusätzliche Schritte für Indexierung, Suche und Ranking hinzu.

Unterschied zu ReAct

ReAct steuert den Aktionszyklus des Agenten.

RAG steuert die Qualität des Wissens, auf dem die Antwort basiert.

Wann RAG verwenden (vs andere Patterns)

Verwende RAG, wenn die Antwort sich bei der aktuellen Anfrage auf externe Dokumente oder eine Wissensbasis stützen muss.

Kurzer Test:

• wenn du "relevante Quellen finden und darauf basierend antworten" musst -> RAG
• wenn du "Nutzerkontext zwischen Schritten oder Sessions behalten" musst -> Memory-Augmented Agent

Mit anderen Patterns kombinieren

• RAG + ReAct: erst holt der Agent Fakten aus Quellen, dann führt er Schritte auf verifiziertem Kontext aus.
• RAG + Supervisor: fehlen gültige Quellen, wird die Antwort blockiert oder zur Freigabe weitergeleitet.
• RAG + Multi-Agent Collaboration: alle Agenten teilen denselben Knowledge Context und arbeiten konsistent.

Kurzfassung

Vorteile und Nachteile

FAQ

Q: Garantiert RAG eine zu 100% richtige Antwort?
A: Nein. RAG senkt das Fehlerrisiko, aber Qualität hängt weiterhin von Index, Suche und Ranking ab.

Q: Was tun, wenn keine relevanten Quellen gefunden werden?
A: Es braucht einen sicheren Fallback: Rückfrage, begründete Ablehnung oder Eskalation an einen Menschen.

Q: Ersetzt RAG Fine-Tuning?
A: Nein. RAG löst den Zugriff auf aktuelles Wissen. Fine-Tuning verändert Stil oder Verhalten des Modells. In Produktion werden beide oft kombiniert.

Was als Nächstes

RAG gibt dem Agenten aktuelles externes Wissen für die laufende Anfrage.

Aber wie speichert man nützlichen Interaktionskontext über Nutzersessions hinweg?