/pattern/agentic-rag/
Der Agent entscheidet autonom, ob, wann und wie er abruft – er stellt Anfragen, formuliert sie um, wählt unter Quellen aus, bewertet die Relevanz zurückgegebener Passagen und iteriert oder überspringt den Abruf –, anstatt bedingungslos einmal vor der Generierung abzurufen. Benannte Varianten: Self-RAG (Reflexions-Tokens steuern den Abruf), Corrective RAG / CRAG (ein Evaluator bewertet Belege und löst erneuten Abruf oder einen Web-Fallback aus), GraphRAG (ein Knowledge Graph für Multi-Hop-Fragen) und RAPTOR (hierarchischer baumstrukturierter Abruf für langes Material).
In der PraxisEin Produkt-Support-Agent stellt eine verfeinerte Anfrage an seinen Richtlinien-Korpus, wenn der erste Abruf unterhalb eines Relevanzschwellenwerts liegt, anstatt auf Basis des schwachen Treffers zu antworten.
Wann man dazu greift
Wann es nach hinten losgeht
Die Abwägung
Höhere Relevanz und Trefferquote werden mit zusätzlichen LLM-Aufrufen, erhöhter Latenz und einer größeren Fehlerfläche (falsch entschiedener Abruf, Anfrage-Umformulierungsschleifen) erkauft.
Relevante Passagen werden vor der Generierung abgerufen.
Wenn keine Passage den Relevanzschwellenwert übersteigt, formuliert der Agent immer wieder um und fragt erneut ab. Ohne eine Obergrenze verbrennt er Token und Latenz auf der Suche nach Kontext, der im Korpus möglicherweise nicht existiert.
Lösung · Schleife begrenzen: Umformulierungsrunden deckeln und bei Erschöpfung auf Basis des Abgerufenen antworten (oder die Lücke deklarieren), statt erneut zu schleifen.
Eine Passage erzielt eine hohe Embedding-Ähnlichkeit, enthält aber die Antwort gar nicht. Der Bewerter winkt sie durch, und der Agent gründet eine selbstsichere Antwort auf Belegen, die sie nie gestützt haben.
Lösung · Auf Beantwortbarkeit bewerten, nicht auf Ähnlichkeit: Verlangen, dass die Passage die Aussage tatsächlich stützt (eine Entailment-/Enthält-die-Antwort-Prüfung), und vor der Generierung über Quellen hinweg gegenprüfen.
Weitermachen
Patterns, Frameworks und Seiten durchsuchen.