AWS zeigt, wie sich Agentic Retrieval auf Bedrock mit einer einzigen CDK-App bereitstellen lässt
AWS hat eine Anleitung veröffentlicht, wie sich Agentic Retrieval für Unternehmen auf einer Managed Amazon Bedrock Knowledge Base aufbauen lässt, und zwar mit einer einzigen AWS-CDK-Anwendung in Python. Laut AWS stellt ein einziger Befehl einen Agenten bereit, der über zwei Knowledge Bases routet, per Gateway abruft und eine fundierte Antwort mit Quellenangaben liefert. Sein Verhalten wird in Amazon CloudWatch erfasst.
- AWS hat eine CDK-Anleitung für Agentic Retrieval auf einer Managed Amazon Bedrock Knowledge Base veröffentlicht.
- Agentic Retrieval über AgenticRetrieveStream und der AgentCore-Gateway-Konnektor sind laut AWS nur auf verwalteten Knowledge Bases verfügbar.
- Das Design kommt ohne OpenSearch-Serverless-Collection und OCU-Kapazität aus.
- Die App liefert zwei CloudWatch-Dashboards mit sieben Telemetrieebenen sowie Evaluation auf Abruf und kontinuierlich.
- Vier CDK-Stacks teilen sieben stackübergreifende Werte, ein einziger Befehl stellt alles bereit.
Wo klassisches RAG an Grenzen stößt
AWS beginnt mit der Beschreibung, wo gewöhnliches Retrieval Augmented Generation (RAG) an seine Grenzen kommt. Die meisten Systeme betten die Frage ein, holen die ähnlichsten Textabschnitte aus einem Index, reichen sie an ein Modell weiter und geben die Antwort zurück: ein Abruf, eine Generierung. Für eine große Klasse von Fragen sei das laut AWS genau das richtige Design.
In drei typischen Fällen versagt dieser Ansatz laut dem Beitrag. Erstreckt sich eine Antwort über zwei Korpora, liefert ein einzelner Abruf nur die Hälfte dessen, was das Modell braucht, und die Antwort fällt flüssig, aber unvollständig aus. Hängt die richtige Quelle von der Frage ab, kann ein einzelner Index keine Auswahl treffen. Und wenn eine Frage nach dem ersten Ergebnis einen zweiten Blick in den Korpus erfordert, gibt es dafür keine Möglichkeit.
Agentic Retrieval löst alle drei Probleme, indem ein Reasoning-Agent in den Ablauf eingebunden wird. Der Agent entscheidet, ob er abruft, welche Knowledge Base er befragt und ob er vor der Antwort noch einmal nachhakt.
Was die Managed Knowledge Base ändert
Der Beitrag baut auf der Managed Knowledge Base (Type: MANAGED) in Amazon Bedrock auf. Laut AWS übernimmt Bedrock Aufnahme, Speicherung, Indexierung und Abruf, standardmäßig inklusive Embedding und Reranking mit servicegesteuerten Modellen. Eine Vektordatenbank muss somit weder bereitgestellt noch skaliert oder gepatcht werden. Die AgenticRetrieveStream-API bietet mehrstufige Planung, werkzeuggesteuerten Abruf und Antworten mit Quellenangaben als Servicefunktion.
AWS stellt dem die kundenverwaltete (DIY-)Variante gegenüber, bei der Nutzer den Vektorspeicher selbst betreiben, etwa Amazon OpenSearch Serverless:
- Agentic Retrieval über AgenticRetrieveStream wird auf verwalteten Knowledge Bases unterstützt, auf kundenverwalteten nicht.
- Die AgentCore-Gateway-Integration wird ebenfalls nur auf verwalteten Knowledge Bases unterstützt.
- Der verwaltete Datenspeicher skaliert automatisch, ein DIY-Speicher muss bereitgestellt, skaliert und gewartet werden.
- Embedding und Reranking laufen über integrierte, verwaltete Modelle ohne Zusatzkosten, im Gegensatz zu Modellen, die der Nutzer selbst konfiguriert.
Der kundenverwaltete Weg bleibt laut AWS die richtige Wahl, wenn eine bestehende OpenSearch-Serverless-Collection weiterverwendet werden soll oder besondere Anforderungen an Datenresidenz, Tuning oder Compliance bestehen.
Die Architektur nutzt außerdem Amazon Bedrock AgentCore: ein Gateway, das jede Knowledge Base als Model-Context-Protocol-Tool (MCP) bereitstellt, und eine Runtime, die den Reasoning-Agenten hostet.
Observability und Evaluation von Haus aus
Ein Agent, der in einer Schleife schlussfolgert und abruft, nimmt laut AWS bei jeder Frage einen anderen Weg. Standardmäßig sei weder dieser Weg sichtbar noch ob die Antwort etwas taugt. In den Worten von AWS wird Observability damit zum einzigen Weg, die Funktionsfähigkeit des Systems zu belegen.
Die Lösung liefert daher zwei Amazon-CloudWatch-Dashboards über sieben Telemetrieebenen sowie zwei Arten der Evaluation, auf Abruf und kontinuierlich, alles aus demselben Deployment. Laut AWS dient etwa die Hälfte dessen, was die App bereitstellt, dazu, das Handeln des Agenten sichtbar zu machen. Antworten mit Quellenangaben lassen sich auf die Ursprungspassagen zurückverfolgen, sodass Antworten prüfbar bleiben. Scores für Faithfulness und Correctness helfen Teams, Antworten zu erkennen, die sich von ihren Quellen entfernen, bevor sie in Produktion gehen.
Warum CDK und was es für Teams bedeutet
Der Beitrag knüpft an einen Artikel vom August 2024 an, in dem ein Single-Shot-RAG-Design als CDK-Anwendung mit drei Stacks bereitgestellt wurde: ein S3-Korpus, eine OpenSearch-Serverless-Collection samt Index, eine Knowledge Base und eine Datenquelle. Im neuen Design entfällt der Vektorspeicher, es gibt also weder eine OpenSearch-Serverless-Collection noch OCU-Kapazität bereitzustellen.
CDK passe laut AWS gut, weil die vier Stacks dicht miteinander verflochten sind. Das Gateway braucht beide Knowledge-Base-IDs, der Agent die Gateway-URL und den ARN, und die Dashboards benötigen die Knowledge-Base-IDs, den Gateway-ARN und die Agent-Runtime-ID: sieben Werte, die Stack-Grenzen überschreiten. Bei reinen Templates müsste man sie von Hand synchron halten. In CDK leitet sich laut AWS durch die Übergabe des Constructs sowohl der Export als auch die Abhängigkeitskante ab, und CDK ermittelt die Reihenfolge der Bereitstellung selbst.
Für Teams, die bereits Single-Shot-RAG betreiben, positioniert der Beitrag die Managed Knowledge Base als Weg zu Agentic Retrieval, da die Funktion laut AWS nur dort verfügbar ist. Teams, die einen eigenen Vektorspeicher benötigen, bleiben bei der kundenverwalteten Option und erhalten weder Agentic Retrieval noch den Gateway-Konnektor.
