Agentic Retrieval auf einer Managed Amazon Bedrock Knowledge Base mit CDK aufbauen

Dieser Beitrag baut Enterprise-Agentic-Retrieval auf einer Managed Amazon Bedrock Knowledge Base mit dem AWS Cloud Development Kit (AWS CDK) auf. Um zu verstehen, warum sich das lohnt, hilft es, dort anzusetzen, wo gewöhnliche Retrieval Augmented Generation (RAG) an ihre Grenzen stößt. Die meisten RAG-Systeme beginnen auf dieselbe Weise: Sie wandeln die Frage in Einbettungen um, holen die nächstgelegenen Chunks aus einem Index, übergeben sie an ein Modell und liefern die Antwort zurück. Eine Retrieval, eine Generierung. Für eine große Klasse von Fragen ist das die richtige Architektur, und es gibt keinen Grund, etwas Komplizierteres zu bauen.

Es scheitert auf eine erkennbare Weise. Stellt man eine Frage, deren Antwort sich über zwei Korpora erstreckt, liefert eine einzige Retrieval nur die Hälfte dessen, was das Modell benötigt – was schlechter ist als gar nichts zurückzugeben, denn die Antwort kommt flüssig und unvollständig daher. Stellt man eine Frage, bei der die richtige Quelle von der Frage abhängt, hat ein einzelner Index keinen Mechanismus zur Auswahl. Und stellt man eine Frage, die nach dem ersten Ergebnis einen zweiten Blick in den Korpus erfordert, gibt es keinen Ort, an dem dieser zweite Blick stattfinden könnte.

Enterprise-Agentic-Retrieval beantwortet alle drei Probleme, indem es einen verstehenden Agenten in den Ablauf einbindet. Der Agent entscheidet, ob eine Retrieval nötig ist, welche Knowledge Base konsultiert werden soll und ob er nachschlagen muss, bevor er eine Antwort formuliert. In diese Richtung haben sich Amazon Bedrock Knowledge Bases entwickelt. Mit dem Start der Managed Knowledge Base ist Retrieval nicht mehr ein einzelner Embed-and-Fetch-Aufruf. Es ist zu einer agentischen Fähigkeit geworden: Multi-Turn-Planung, toolgesteuerte Retrieval sowie begründete, mit Quellen belegte Antworten. Die AgenticRetrieveStream API bietet dies als First-Class-Servicefunktion an, statt dass man es selbst zusammenbaut. Das funktioniert – und es führt zugleich ein deutlich härteres Betriebsproblem ein. Eine Single-Shot-Pipeline ist eine Funktion, die man durch Lesen nachvollziehen kann. Ein Agent, der in einer Schleife argumentiert und abruft, nimmt bei jeder Frage einen anderen Weg. Standardmäßig sieht man weder den eingeschlagenen Pfad noch, ob die erzeugte Antwort gut war. Observability hört auf, ein Nice-to-have zu sein, und wird zur einzigen Möglichkeit zu wissen, dass das System funktioniert.

Im August 2024 baute eine Single-Shot-Architektur als CDK-Anwendung bereit: ein Amazon Simple Storage Service (Amazon S3) -Korpus, eine Amazon OpenSearch Serverless -Sammlung und einen Index, eine Knowledge Base und eine Datenquelle, bereitgestellt als CDK-Stacks, deren Reihenfolge man von Hand gesteuert hat. Drei Dinge haben sich seit der Veröffentlichung geändert.

1. Amazon Bedrock bietet jetzt eine verwaltete Knowledge Base (Typ: MANAGED), die die Ingestion, Speicherung, Indizierung und das Retrieval selbst übernimmt. Die OpenSearch-Serverless-Sammlung und den Index, die der damalige Beitrag bereitstellt, muss man nicht mehr erstellen, skalieren oder mit OpenSearch Compute Units (OCUs) bezahlen.
2. Amazon Bedrock AgentCore stellt den agentischen Teil bereit: ein Gateway, das jede Knowledge Base als Model Context Protocol (MCP)-Tool exponiert, eine Runtime, die den Argumentationsagenten hostet, und AgenticRetrieveStream, das intern neu rangiert und eine synthetisierte, mit Quellen belegte Antwort zurückgibt. Agentic Retrieval ist nur auf der Managed Knowledge Base verfügbar.
3. Die Observability- und Evaluierungsgeschichte ist nun etwas, das man bereitstellen kann, nicht etwas, das man nachträglich anflanscht. Diese Lösung liefert zwei Amazon CloudWatch -Dashboards über sieben Schichten Telemetrie sowie zwei Formen der Evaluierung, bedarfsgesteuert und kontinuierlich, aus derselben Bereitstellung.

Dieser Beitrag baut genau dieses System: einen Agenten, der zwischen zwei Knowledge Bases routet, über das Gateway abruft und eine begründete, mit Quellen belegte Antwort zurückgibt, wobei jede Schicht seines Verhaltens instrumentiert ist – als eine einzige AWS CDK -Anwendung in Python. Ein einziger Befehl stellt alles bereit, und CDK leitet die Reihenfolge ab.

Wenn Sie den 2024er Beitraggelesen haben, wird Ihnen der Weg vom Amazon-S3-Bucket zur Knowledge Base vertraut vorkommen, und alles danach ist neu: Der Vector Store ist verschwunden, die Retrieval ist agentic, und ungefähr die Hälfte dessen, was die App bereitstellt, existiert, um Ihnen zu zeigen, was der Agent getan hat. Falls nicht, steht dieser Beitrag für sich allein.

Die beteiligten Services und der Weg, den eine Frage durch sie nimmt: Der Agent entscheidet, ob abgerufen wird und welche Wissensbasis konsultiert wird, das Gateway stellt jede Wissensbasis als aufrufbares Tool bereit, die Managed Knowledge Bases suchen und zitieren, und die Schleife wiederholt sich so oft, wie die Frage es erfordert. Alles, was der Agent dabei tut, landet in Amazon CloudWatch.

Abbildung 1: Die beteiligten Services und der Weg, den eine einzelne Frage durch sie nimmt

Hintergrund

Bevor wir zur Durchführung kommen, ist es hilfreich, drei Dinge zu klären: was Retrieval agentic macht, warum die Managed Knowledge Base die richtige Grundlage dafür ist und warum Observability und Evaluation von Anfang an Teil des Designs sein sollten und nicht erst nachträglich angefügt werden.

Von RAG zu unternehmerischem agentic Retrieval

Klassisches Retrieval Augmented Generation (RAG) führt ein Retrieval und eine Generierung durch. Enterprise agentic retrieval bringt einen reasoning agent in die Schleife: Er entscheidet, ob und was abgerufen wird, kann mehrfach abrufen, um zu verfeinern, wählt welche Wissensbasis relevant ist (semantisches Routing) und erstellt erst dann eine fundierte Antwort mit Quellenangaben. Mit der Managed Knowledge Base ist dies eine First-Class-Service-Funktion: Die AgenticRetrieveStream API führt das Multi-Turn-Planning durch, führt das Retrieval aus und gibt eine Antwort mit Quellenangaben zurück – anstelle einer Orchestrierungsschicht, die Sie über eine rohe Vektorsuche selbst aufbauen und warten müssten. Das liefert bessere Antworten bei komplexen Fragen, erzeugt aber auch ein komplexeres zu betreibendes System – genau deshalb sind Observability und Evaluation von Anfang an integriert.

Managed compared to do-it-yourself Knowledge Bases

Amazon Bedrock bietet nun eine Managed Knowledge Base an (Typ: MANAGED): Amazon Bedrock übernimmt für Sie die Ingestion, Speicherung, Indexierung und den Abruf , standardmäßig einschließlich Embedding und Reranking mit serviceverwalteten Modellen, sodass es keinen Vektordatenbank zu provisionieren, zu skalieren oder zu patchen gibt. Dies unterscheidet sich von einer kundenverwalteten (DIY) Knowledge Base, bei der Sie den Vektorspeicher (z. B. Amazon OpenSearch Serverless) selbst auswählen und betreiben.

Zwei Unterschiede sind für diese Lösung am wichtigsten:

Da agentic Retrieval und der AgentCore-Gateway-Connector nur mit der verwalteten Knowledge Base verfügbar sind, ist sie die natürliche Grundlage für unternehmerisches agentic Retrieval. Dies bedeutet auch, dass Amazon Bedrock die Speicherung und Indizierung für Sie übernimmt, sodass in diesem Design keine OpenSearch-Serverless-Collection und keine OCU-Kapazität bereitgestellt werden muss. Die kundenverwaltete Option bleibt die richtige Wahl, wenn Sie Ihren eigenen Vektorspeicher auswählen und betreiben möchten, beispielsweise um eine bestehende OpenSearch-Serverless-Collection wiederzuverwenden oder bestimmte Anforderungen an Datenresidenz, Tuning oder Compliance zu erfüllen. Für unternehmerisches agentic Retrieval ist die verwaltete Knowledge Base das, was die Funktion überhaupt erst ermöglicht.

Warum Observability und Evaluation

Ein agentisches System, das eine Antwort zurückgibt genügt für die Produktion nicht. Sie müssen sehen, wie es sich verhält (Latenz, Aufrufvolumen, Token-Verbrauch), wie gut Retrieval und Antworten sind, und diese Signale benötigen Sie kontinuierlich. Diese Lösung liefert zwei CloudWatch-Dashboards mit sieben Telemetrie-Ebenen sowie zwei Formen der Evaluation (auf Anforderung und kontinuierlich), alles mit derselben CDK-Anwendung bereitgestellt. Die Ebenen für Grounding, Zitate und Evaluation unterstützen zudem einen verantwortungsvollen Einsatz. Belegte Antworten lassen sich bis zu ihren Quellpassagen zurückverfolgen, sodass Antworten auditable bleiben, und die Werte für Faithfulness und Correctness ermöglichen es Ihnen, Antworten zu erkennen, die von ihren Quellen abweichen, statt es erst in der Produktion festzustellen.

Warum CDK für diese konkrete Lösung

Jedes Infrastructure-as-Code-Tool kann diese Ressourcen erstellen. CDK verdient seinen Platz hier aus einem Grund, der speziell für diese Architektur gilt: die vier Stacks sind dicht miteinander querverwiesen. Das Gateway benötigt beide Knowledge-Base-IDs. Der Agent benötigt URL und ARN des Gateways. Die Dashboards benötigen die KB-IDs, die Gateway-ARN, und die Agent-Runtime-ID – sieben Werte, die Stack-Grenzen überschreiten, jeder einzelne eine Dimension eines Metrics oder ein Ziel eines Connectors.

Als reine Templates geschrieben – also ein Satz von Stack-Exports und Cross-Stack-Lookups, die von Hand in Übereinstimmung gehalten werden, plus ein Skript, das in der richtigen Reihenfolge deployt und Outputs weiterreicht – driften beide auseinander, sobald irgendetwas umbenannt wird. In CDK übergibt man das Construct, und der Export und die Abhängigkeitskante ergeben sich aus diesem einen Akt der Übergabe. Die Lösung von 2024 hatte drei Stacks und eine weitgehend lineare Abhängigkeitskette. Bei vier Stacks mit sieben Werten, die zwischen ihnen ausgetauscht werden, hört der Unterschied auf, stilistisch zu sein.

Lösungsübersicht

Hier ist der Pfad, den eine einzelne Frage durch das System nimmt, von Anfang bis Ende. Es lohnt sich, ihn langsam zu betrachten, denn der Rest des Beitrags geht ihn von links nach rechts durch.

Das folgende Diagramm verfolgt den End-to-End-Workflows der agentischen Suche. Die Frage eines Benutzers gelangt in den Agenten auf dem AgentCore Runtime, der sie über das AgentCore Gateway an eines von zwei AgenticRetrieveStream-Tools weiterleitet, eines pro verwalteter Wissensbasis, financial und weather, die jeweils aus Amazon S3 eingebunden werden. Das ausgewählte Tool gibt eine belegte, fundierte Antwort zurück, und jeder Schritt wird an Amazon CloudWatch und AWS X-Ray gestreamt. Die nummerierten Abzeichen entsprechen der folgenden Durchführung.

Abbildung 2: End-to-End-Workflows der agentischen Suche für eine einzelne Frage

Die nummerierten Schritte im Diagramm entsprechen dem Workflow, der wie folgt aussieht.

Schritt 0 — einmalig, beim Deploy. Bevor irgendeine Frage gestellt wird, wird jedes Korpus in Amazon S3 in seine eigene Managed Knowledge Base eingebunden: Amazon Bedrock parst, chunkt, embeddet und indexiert es automatisch. Dies geschieht einmal beim Deploy der Stacks, es ist nicht Teil des pfadbezogenen Ablaufs pro Frage und wird daher als gestrichelter Pfeil gezeichnet und als Schritt 0 markiert. Jede Frage durchläuft dann die Schritte 1–6:

1. Ein Benutzer sendet eine Frage an den Agenten, der auf dem Amazon Bedrock AgentCore Runtime gehostet ist. Die Runtime instrumentiert die gesamte Reason-and-Act-Schleife automatisch mit OpenTelemetry (OTEL)-Spans, sodass das System vom allerersten Aufruf an beobachtbar ist.
2. Das Reasoning-Modell des Agenten plant und routet über die Wissensbasen hinweg. Da jede Wissensbasis als eigenes Retrieval-Tool bereitgestellt wird, wählt der Agent das Tool aus, dessen Thema zur Frage passt, financial oder weather, anstatt einen einzigen vermischten Index zu durchsuchen.
3. Der ausgewählte Tool-Aufruf wird vom AgentCore Gateway über MCP vermittelt,vom IAM-Task-Role des Agenten autorisiert und mit SigV4 signiert; dieser ruft die AgenticRetrieveStream-API der jeweiligen Wissensbasis auf der Managed Knowledge Base auf.
4. AgenticRetrieveStream erledigt die Arbeit innerhalb der Wissensbasis: es zerlegt die Frage in Teilabfragen, ruft iterativ aus dem Datenspeicher ab, den Amazon Bedrock verwaltet (eingebunden aus den Korpora in Amazon S3), und synthetisiert eine fundierte, belegte Antwort, die durch das Gateway zurückgestreamt wird.
5. Der Agent prüft, ob der zurückgegebene Kontext ausreichend ist. Wenn nicht, wiederholt er die Schleife, routet und ruft erneut ab, bevor er seine endgültige Antwort verfasst. Wenn ja, gibt er die belegte Antwort an den Benutzer zurück.
6. Während des gesamten Ablaufs sendet die Runtime Spans, Token-Zählungen und Metriken an Amazon CloudWatch und AWS X-Ray, füllt die sieben Observability-Ebenen und speist sowohl die On-Demand- als auch die Continuous-Evaluation-Bewertungen.

Intern ist dieser Workflow eine CDK-App, app.py, die vier Stacks deklariert. Sie wählen die Reihenfolge nicht, CDK leitet sie aus den von Ihnen übergebenen Construct-Referenzen ab:

kb_stack = KnowledgeBasesStack(app, f"{project}-kb", env=env)

gateway_stack = AgenticGatewayStack(
    app, f"{project}-gateway", env=env,
    financial_kb=kb_stack.financial_kb,  # ← the reference creates the dependency
    weather_kb=kb_stack.weather_kb,
)

agent_stack = AgentRuntimeStack(
    app, f"{project}-agent", env=env,
    gateway=gateway_stack.gateway,
)

DashboardsStack(
    app, f"{project}-dashboards", env=env,
    financial_kb=kb_stack.financial_kb,
    weather_kb=kb_stack.weather_kb,
    gateway=gateway_stack.gateway,
    agent_runtime=agent_stack.agent_runtime,
)

Das ist die gesamte Verdrahtung. Diese vier Konstruktor-Aufrufe ersetzen die Export-/Import-Buchhaltung und das Deploy-Skript.

Der Agent durchläuft eine Reason-and-Act-Schleife: Er denkt (ein Aufruf eines Large Language Model (LLM)), entscheidet, welches KB-Tool er aufruft, liest, was über das Gateway zurückkam, und ruft oft erneut ab, bevor er seine endgültige, mit Quellen versehene Antwort formuliert. Jeder Schritt wird automatisch durch die Runtime instrumentiert, sodass sich die sieben Observability-Schichten mit echtem Traffic füllen.

Die sieben Schichten. L1 KB-native Metriken, L2 Ingestion, L3 agentische Retrieval-Qualität, L4 Gateway/MCP-Metriken, L5 OTEL-Span-Baum, L6 Token-Nutzung und L7 Evaluation-Scores. Die Schichten 1, 4 und 5 werden automatisch ausgegeben. Die Schichten 3, 6 und 7 werden als benutzerdefinierte Metriken vom Driver-Notebook veröffentlicht.

Alles, was konfigurierbar ist, liegt in einer Datei, config.py:

Wenn Sie PROJECT_NAME ändern, erhalten Sie eine unabhängig benannte Kopie der gesamten Lösung, sodass zwei Bereitstellungen in einem Konto koexistieren können. Das Driver-Notebook liest dieselbe Konstante und folgt der Umbenennung daher automatisch – es gibt keine Stack-Namen, die manuell synchron gehalten werden müssen.

Beschreiben Sie den Datensatz

Die Lösung wird mit zwei kleinen Korpora ausgeliefert, die im Repository unter data/ enthalten sind:

• Financial — Ein synthetischer Octank Financial 10-K (octank_financial_10K.pdf, ca. 198 KB).
• Weather — Ein echter, öffentlich verfügbarer Bericht des U.S. Congressional Research Service über Tornados (IF12695, tornadoes_report.pdf, ca. 560 KB).

⚠️ Über die Daten: Das Financial-Korpus ist synthetisch. Octank ist ein fiktives Unternehmen, und der 10-K ist modellgenerierte Beispieldaten (CC0-lizenziert). Es istnicht echten Finanzdaten. Das Wetterkorpus ist ein echtes, gemeinfreies Werk der US-Regierung und ein Bericht des Congressional Research Service, öffentlich verfügbar unter sgp.fas.org/crs/misc/IF12695.pdf (Werke der US-Regierung unterliegen keinem Urheberrecht). Um eigene Daten zu verwenden, legen Sie Dateien unter data/ ab und passen Sie die Präfixe in config.pyan, eine weitere Änderung ist nicht erforderlich.

Die beiden Korpora sind absichtlich verschieden, damit der Agent jede Frage an die richtige Wissensbasis weiterleiten muss – die semantische Routing-Geschichte. Da es sich um Managed Knowledge Bases handelt, konfigurieren wir kein Chunking, keine Embeddings und keinen Index: Bei der Aufnahme parst Amazon Bedrock jedes PDF, chunkt es, erzeugt Embeddings mit seinem verwalteten Modell und indexiert es automatisch.

Wir verwenden zwei getrennte Wissensbasen, die jeweils über das Gateway als eigenes Retrieval-Tool bereitgestellt werden, statt einer einzigen Wissensbasis, die beide Korpora enthält – und diese Wahl ist bewusst. Wenn der Agent zwei benannte Tools erhält, wird das Routing zu einem expliziten Rechenschritt, den man beobachten kann: Der Span-Baum zeigt, welches Tool es für eine bestimmte Frage gewählt hat, und die Retrieval-Qualitätsmetriken in Layer 3 bleiben pro Wissensbasis getrennt, sodass sich Finanz- und Wetterpräzision nie zu einer einzigen Zahl vermischen. Ein einzelnes Tool, das beide Korpora umfasst, würde diese Unterscheidung aufheben: Die Routing-Entscheidung würde im Ranking eines einzigen Index verschwinden, außer Sichtweite, und jedes Qualitätssignal wäre ein Durchschnitt über zwei unabhängige Domänen. Die Korpora und ihre Tools getrennt zu halten, macht das Verhalten des Agents nachvollziehbar – und genau das ist der Sinn der Übung.

In CDK ist das Übertragen der Korpora nach S3 ein BucketDeployment:

s3deploy.BucketDeployment(
    self, "FinancialCorpus",
    sources=[s3deploy.Source.asset(str(ROOT / "data" / "financial"))],
    destination_bucket=self.source_bucket,
    destination_key_prefix=KbConfig.FINANCIAL_PREFIX,
)

BucketDeployment ist es wert, bekannt zu sein, gerade weil die Alternative so verlockend ist: Ohne es wächst der benutzerdefinierten Ressource, die die Aufnahme auslöst, tendenziell ein Upload-Schritt an, und plötzlich besitzt eine Ressource zwei unabhängige Aufgaben. Hier muss sie nur noch aufnehmen.

Die verwaltete Aufnahme scannt, chunkt, bettet und indexiert jedes Dokument automatisch: ein Dokument pro Wissensbasis indexiert, null Fehler.

Abbildung 3: Ergebnisse der verwalteten Aufnahme, ein Dokument pro Wissensbasis indexiert mit null Fehlern

Lösung bereitstellen

Dieser Abschnitt führt durch die Bereitstellung der gesamten Lösung mit einem Befehl. Nachdem die Voraussetzungen erfüllt sind, cdk deploy --all stellt alle vier Stacks in der abgeleiteten Abhängigkeitsreihenfolge von CDK bereit und führt jeden stackübergreifenden Wert automatisch durch.

Voraussetzungen

• Ein AWS-Konto mit Berechtigungen für Amazon Bedrock, AgentCore (Runtime + Gateway), AWS Identity and Access Management (IAM), CloudWatch, AWS X-Ray, Amazon Elastic Container Registry (Amazon ECR), AWS CodeBuild, Amazon S3, AWS Lambda, und AWS CloudFormation.
• Das Modell des Agents im Konto verfügbar (Standard us.anthropic.claude-haiku-4-5-20251001-v1:0).
• CloudWatch Transaction Search aktiviert, damit OTEL-Spans in aws/spans für die Layers 5–7 landen.
• Node.js 18+ und die CDK CLI (npm install -g aws-cdk), zusätzlich Python 3.13+.
• Das für CDK bootstrappte Konto und die Region (cdk bootstrap), jeweils einmal pro Konto/Region.
• Kein lokales Docker nötig, das Agent-Image wird von CodeBuild (ARM64) erstellt.

Ein Befehl

Um die Lösung bereitzustellen, klonen Sie das Repository, erstellen Sie eine virtuelle Umgebung, installieren Sie die Abhängigkeiten und führen Sie cdk deploy --allaus. Führen Sie die folgenden Befehle in Ihrem Terminal aus:

git clone https://github.com/aws-samples/amazon-bedrock-samples.git
cd rag/managed-knowledge-bases/07-IaaC/managed-kb-observability-cdk/
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cdk bootstrap  # once per account/region
cdk deploy --all

Die ersten beiden Befehle klonen das Beispiel und wechseln in das Projektverzeichnis. Die nächsten beiden erstellen und aktivieren eine Python-virtuelle Umgebung und installieren die Abhängigkeiten der CDK-App. cdk bootstrap bereitet das Konto und die Region für CDK vor (Sie benötigen dies nur einmal pro Konto/Region), und cdk deploy --all stellt alle vier Stacks bereit.

Konto und Region stammen aus Ihrem AWS-Profil (CDK_DEFAULT_ACCOUNT / CDK_DEFAULT_REGION), sodass die App ohne Anpassungen bereitgestellt wird.

Regionsverfügbarkeit: Die verwaltete Knowledge Base, agentic retrieval (AgenticRetrieveStream) und Amazon Bedrock AgentCore (Runtime und Gateway) sind nicht in jeder AWS-Region verfügbar. Bevor Sie die Bereitstellung durchführen, bestätigen Sie, dass alle diese Dienste in Ihrer Zielregion angeboten werden, und setzen Sie ACCOUNT_REGION in config.py entsprechend. Der Standardwert ist us-west-2. Informationen zur aktuellen Verfügbarkeit finden Sie in der Amazon Bedrock - und Amazon Bedrock AgentCore -Dokumentation sowie in der AWS Regional Services List.

In dieser Version gibt es kein Deploy-Skript, und genau das ist der Punkt: cdk deploy --all geht den Abhängigkeitsgraphen durch, den sie aus app.py, deployed die vier Stacks in Reihenfolge und übergibt jede stackübergreifende Value automatisch. Das Terminal meldet jeden Stack nach Fertigstellung: bmkb-obs-cdk-kb [1/4] (der Standard-PROJECT_NAME), dann gateway [2/4], dann agent [3/4], dann dashboards [4/4] – und diese Reihenfolge wird abgeleitet, nicht deklariert: Sie ergibt sich aus den Konstrukt-Referenzen zwischen den Stacks, sodass das Hinzufügen eines fünften Stacks, der ein bestehendes Output konsumiert, die Deployment-Reihenfolge von selbst neu anordnet.

Der Stack -Agent erstellt den Agent-Container mit CodeBuild, daher sollten Sie für diese Phase etwa 8–10 Minuten einplanen. Die anderen drei gehen schnell. Jeder Stack gibt seine Ausgaben nach Abschluss aus, und dort erhalten Sie die Knowledge-Base-IDs, die Gateway-URL, den Runtime-ARN und beide Dashboard-URLs. Wenn die Bereitstellung abgeschlossen ist, sind alle vier Stacks vollständig. Der folgende Screenshot zeigt die AWS-CloudFormation-Konsole nach einer erfolgreichen cdk deploy --all.

Abbildung 4: AWS CloudFormation-Konsole nach einer erfolgreichen Bereitstellung, mit allen vier Stacks im Status CREATE_COMPLETE

Auf der Konsole melden alle vier Stacks – kb, gateway, agent und dashboards – CREATE_COMPLETE, jeder mit seiner Position [n/4] in der abgeleiteten Abhängigkeitsreihenfolge, die in seiner Beschreibung angezeigt wird.

Eine Anmerkung zu langlebigen Ressourcen

Zwei Dinge in dieser Lösung dauern wesentlich länger, als die Obergrenze von 15 Minuten einer AWS Lambda-Funktion bei naivem Polling erlaubt: die KB-Ingestion-Synchronisierung und der CodeBuild-Image-Build. Das AWS CDK Provider framework behandelt dies mit einem on_event / is_complete „split, bei der ein Handler die Arbeit beginnt und ein zweiter abgefragt wird, bis er den Abschluss meldet.“

cr.Provider(
    self, "IngestSyncProvider",
    on_event_handler=on_event,        # StartIngestionJob, return the job id
    is_complete_handler=is_complete,  # GetIngestionJob, report IsComplete
    query_interval=Duration.seconds(30),
    total_timeout=Duration.minutes(30),
)

Nichts blockiert, das Antwortprotokoll zurück an CloudFormation gehört zum Framework, statt in jeden Handler handgeschrieben zu werden, und das 30-Minuten-Budget ist eine Eigenschaft und nicht etwas, um das man herumarbeiten muss.

Starten und testen

Öffnen Sie Open notebooks/01-drive-and-observe.ipynb und führen Sie es von oben nach unten aus (pip install -r requirements-notebook.txt erstens). Er liest die Stack-Outputs ein und sendet dann themenspezifische Prompts an den bereitgestellten Agenten, eine Sitzung pro KB, sodass Sie sowohl die Antworten als auch das semantische Routing an einem Ort sehen: Finanzfragen werden aus dem Octank 10-K beantwortet und Wetterfragen aus dem Tornado-Bericht, jeweils automatisch an das passende AgenticRetrieveStream-Tool geroutet.

Das Notebook erkennt alles aus den Stack-Outputs, sodass nichts von Hand eingefügt werden muss:

# Stack names are derived from the same PROJECT_NAME the CDK app uses, so renaming the
# project in config.py cannot leave this notebook pointing at stale stacks.
from config import EnvSettings

PROJECT = EnvSettings.PROJECT_NAME
STACKS = {suffix: f'{PROJECT}-{suffix}'
          for suffix in ('kb', 'gateway', 'agent', 'dashboards')}

def outputs(stack_name):
    s = cfn.describe_stacks(StackName=stack_name)['Stacks'][0]
    return {o['OutputKey']: o['OutputValue'] for o in s.get('Outputs', [])}

Das Notebook importiert die gleichen config.py wie die App, sodass die beiden sich nie darüber streiten können, wie die Stacks heißen.

Der Treiber sendet Pro-KB-Prompts über den bereitgestellten Agenten. Finanzfragen werden an die Finanz-KB und Wetterfragen an die Wetter-KB geroutet, jeweils mit einer fundierten, mit Quellen belegten Antwort.

Abbildung 5: Pro-KB-Prompts, die an die passende Wissensbasis geroutet werden, die jeweils eine fundierte, mit Quellen belegte Antwort zurückgibt

Das Notebook berechnet außerdem die referenzfreien Layer-3-Signale zur Retrieval-Qualität aus dem, was der Agent tatsächlich abgerufen und zitiert hat – keine Ground Truth, kein zusätzlicher Judge – und veröffentlicht sie in CloudWatch.

Abbildung 6: Referenzfreie Layer-3-Signale zur Retrieval-Qualität pro Wissensbasis

Beobachten: Die siebenschichtigen Dashboards

Die beiden Dashboards sind der Ort, an dem die sieben Schichten sichtbar werden. Der Stack erzeugt beide Dashboards, und fließender Traffic füllt sie. Der folgende Screenshot zeigt die beiden Dashboards, wie sie in der CloudWatch-Konsole erscheinen.

Abbildung 7: Die beiden Dashboards in der CloudWatch-Konsole, End-to-End-Agentic-Observability und Observability pro KB

Beide Dashboards erscheinen in der CloudWatch-Konsole: eines für End-to-End-Agentic-Observability und eines für Observability pro KB (BMKB, Bedrock Managed Knowledge Base). Der Rest dieses Abschnitts geht durch, was jede Schicht zeigt.

In dieser Version werden die Dashboards aus typisierten Objekten statt aus einem JSON-String aufgebaut. Eine Metrik ist eine Metric, ein Widget ist ein GraphWidget, und das Layout ist eine Liste von Rows:

cw.GraphWidget(
    title="L4 — Gateway metrics (MCP)",
    width=12, height=6, period=PERIOD, statistic="Sum",
    left=[
        self._gateway_metric("Invocations", gateway_arn, "tools/call Invocations"),
        self._gateway_metric("SystemErrors", gateway_arn, "SystemErrors"),
        self._gateway_metric("UserErrors", gateway_arn, "UserErrors"),
        self._gateway_metric("Throttles", gateway_arn, "Throttles"),
    ],
)

Der praktische Vorteil besteht nicht darin, dass es weniger Zeilen sind, dashboards_stack.py kommt auf 400 Zeilen, mehr als das äquivalente DashboardBody-JSON hätte. Sondern darin, dass eine falsch geschriebene Eigenschaft oder eine ungültige Widget-Kombination bereits cdk synth, auf Ihrem Laptop, in etwa einer Sekunde fehlschlägt. Derselbe Fehler innerhalb eines DashboardBody-Strings wird erfolgreich bereitgestellt und erscheint als kaputtes Widget in der AWS Management Console, wo man ihn durch Anschauen findet.

Weil eine Row jedes Widget akzeptiert, ist die Dokumentation Teil des Layouts statt einer Wiki-Seite, die abdriftet. Jedes Dashboard kombiniert TextWidgets mit den Graphen:

[cw.TextWidget(width=24, height=7, markdown=self._l3_explainer())],
[
    self._quality_widget("L3 · Financial KB — agentic quality (reference-free, 0–1)", fin_id),
    self._quality_widget("L3 · Weather KB — agentic quality (reference-free, 0–1)", wx_id),
],

_l3_explainer() gibt eine Markdown-Tabelle zurück, die jede Kennzahl definiert und erklärt, wie man sie liest, sodass das Widget, das grounded_coverage erklärt, im selben Commit ausgeliefert wird wie das Widget, das es darstellt, und ein Leser, der das Dashboard ohne Kontext öffnet, nicht raten muss, was eine referenzfreie Metrik ist.

Dashboard A — Agentic-Observability (End-to-End). Das Board beginnt mit einer Erklärung, wie jede Schicht etwas anderes zählt (für N Abfragen sehen Sie ~N Agent-Aufrufe, ~2N Abrufe, ~3N LLM-Aufrufe und ~5N Gateway-MCP-Operationen, die sichtbar gemachte agentic loop), dann zeigt es KB-Metriken (L1), Gateway-Metriken und Latenz (L4), Token-Verbrauch (L6) und – da der Agent AgenticRetrieveStream verwendet, das eine synthetisierte, beleggestützte Antwort statt Punktzahlen pro Chunk zurückgibt – die referenzfreien Qualitätssignale der Schicht 3, inline definiert und pro KB dargestellt.

Auf Dashboard A werden die referenzfreien Qualitätssignale der Schicht 3 pro Wissensbasis dargestellt. Zuerst die Finanz-KB. Das folgende Diagramm zeigt deren retrieval_utilization, grounded_coverage und duplicate_rate.

Abbildung 8: Qualität der Finanz-KB in Schicht 3, mit Retrieval-Nutzung, grounded coverage und duplicate rate

Die Wetter-KB zeigt dieselben drei Signale, getrennt erfasst, damit die beiden Domänen nie zu einer Zahl verschwimmen.

Abbildung 9: Qualität der Wetter-KB in Schicht 3, getrennt von der Finanz-KB erfasst

Die beiden Diagramme zeigen retrieval_utilization, grounded_coverage und duplicate_rate für die Finanz-KB (links) und die Wetter-KB (rechts), sodass die Retrieval-Qualität jeder Wissensbasis getrennt bleibt statt zu einer Zahl gemittelt zu werden.

Dashboard B — Observability pro KB (BMKB). Die operativen Signale, die ebenfalls die Kosten bestimmen, pro KB: Indexgröße (aus S3-Quellbytes), Retrieve-Volumen, agentic Tool-Aufrufe, Session-Token-Verbrauch und Generierungs-Token-Verbrauch nach Modell, jeweils mit Inline-Erklärung.

Die folgenden Screenshots zeigen die vier Metrik-Widgets von Dashboard B, gefüllt nach einem Lauf. Das erste Widget meldet die Indexgröße, abgeleitet aus S3-Quellbytes, pro Wissensbasis.

Abbildung 10: Indexgröße von Dashboard B pro Wissensbasis, abgeleitet aus Amazon-S3-Quellbytes

Das zweite Widget zählt Retrieve-Aufrufe pro Wissensbasis.

Abbildung 11: Dashboard B – Anzahl der Retrieve-Aufrufe pro Wissensbasis

Das dritte Widget zählt agentische Tool-Aufrufe über das Gateway. Dieses wird über beide Wissensbasen hinweg geteilt statt aufgeteilt.

Abbildung 12: Dashboard B – Anzahl der agentischen Tool-Aufrufe über das AgentCore Gateway, geteilt über beide Wissensbasen hinweg

Das vierte Widget berichtet die Sitzungs-Token-Nutzung pro Wissensbasis.

Abbildung 13: Dashboard B – Sitzungs-Token-Nutzung pro Wissensbasis

Die vier Widgets zeigen Indexgröße (aus S3-Quellbytes), Volumen der Retrieve-Aufrufe, agentische Tool-Aufrufe über das Gateway und Sitzungs-Token-Nutzung. Jedes ist pro Wissensbasis aufgeschlüsselt, außer der Gateway-Tool-Aufrufzähler, der über beide hinweg geteilt ist.

Ein Dimensionsdetail ist hervorhebenswert, weil die typisierte API es nicht für dich abfängt: Der AWS/Bedrock/KnowledgeBases Namespace erwartet eine präfixierte ID, knowledge-base/<id>, während die eigenen Namespaces der Lösung BMKB/* die bloße ID verwenden. Beide sind für CDK nur Strings.

# L1 — AWS/Bedrock/KnowledgeBases wants the prefixed form.
dimensions_map={"Operation": "Retrieve", "KnowledgeBaseId": f"knowledge-base/{kb_id}"}

# BMKB/* — our own namespaces use the bare id.
dimensions_map={"KnowledgeBaseId": kb_id}

Schicht 5: Der Span-Baum

Schicht 5 ist der rohe OTEL-Span-Baum in aws/spans, und sie ist die Schicht, die dir die agentische Schleife direkt zeigt. Es lohnt sich, sie sorgfältig zu lesen, denn die Verschachtelung ist nicht offensichtlich: Ein LLM-Aufruf erzeugt drei Spans. Der Strands- invoke_agent Span umschließt den Zug, ein interner chat Span umschließt den Modellaufruf, und ein chat <model> Span der Art CLIENT ist der eigentliche Aufruf, und alle drei wiederholen dieselben gen_ai.usage.* Token-Attribute.

Der folgende Screenshot zeigt den Span-Baum in aws/spans, wobei die Drei-Span-Verschachtelung in den oberen Zeilen sichtbar ist.

Abbildung 14: Schicht-5-Span-Baum in aws/spans, mit der Drei-Span-Verschachtelung eines einzelnen LLM-Aufrufs

Liest man die oberen drei Zeilen: ein invoke_agent Strands Agents Aggregate, dann ein interner chat-Span, dann ein CLIENT-chat-Span, alle melden identische 7,299 Input- und 268 Output-Token. Das ist derselbe LLM-Aufruf, der auf drei Ebenen des Baums erscheint, weshalb Aggregation Sorgfalt erfordert.

Diese Struktur ist relevant, sobald man aggregiert. Um jeden LLM-Aufruf nur einmal zu zählen, filtere auf den CLIENT Leaf:

fields attributes.gen_ai.request.model as model,
       attributes.gen_ai.usage.input_tokens as in_tok,
       attributes.gen_ai.usage.output_tokens as out_tok
| filter ispresent(in_tok) and kind = 'CLIENT' and name like /^chat /
| stats sum(in_tok) as input_tokens, sum(out_tok) as output_tokens,
        count(*) as llm_calls by model

Ohne diesen Filter meldet dieselbe Abfrage das Dreifache an Token und das Dreifache an Aufrufen.

Wendet man diesen CLIENT-leaf-Filter an, zeigt der folgende Screenshot die Nutzung von Generation-Tokens nach Modell, wobei jeder LLM-Aufruf einmal gezählt wird.

Abbildung 15: Nutzung von Generation-Tokens nach Modell, wobei jeder LLM-Aufruf einmal gezählt wird

Mit gesetztem Filter zeigt der Lauf 14 LLM-Aufrufe mit insgesamt 60,472 Input- und 2,709 Output-Tokens. Ohne ihn würde dieselbe Abfrage die dreifache Anzahl an Aufrufen und die dreifache Anzahl an Tokens melden.

Evaluate: Auf Abruf und kontinuierlich

Die Qualität wird auf zwei Arten gemessen, und beide werden von der App bereitgestellt.

Auf Abruf: Das Driver-Notebook ruft AgentCore auf. In dieser Version gibt es kein Deploy-Skript, und genau das ist der Punkt: (LLM-as-judge) über die Spans jeder Sitzung für die integrierten Evaluatoren Correctness, Faithfulness und Tool-Selection Accuracy und veröffentlicht die Bewertungen in CloudWatch, wo sie als Layer 7 auf Dashboard A erscheinen.

Der folgende Screenshot zeigt Layer 7 auf Dashboard A: On-Demand-Evaluierungsbewertungen pro Knowledge Base, zusammen mit der Layer-5-OTEL-Span-Tabelle auf demselben Dashboard.

Abbildung 16: Layer 7 On-Demand-Evaluierungsbewertungen pro Knowledge Base, neben der Layer-5-Span-Tabelle

Layer 7 zeigt die On-Demand-Evaluierungsbewertungen pro Knowledge Base, mit der Layer-5-OTEL-Span-Tabelle daneben, sodass die Bewertungen und die Spans, die sie erzeugt haben, auf einem Board zusammen gelesen werden können.

Kontinuierlich (online): Der Agent-Stack stellt auch eine AWS::BedrockAgentCore::OnlineEvaluationConfig bereit, die Live-Sitzungen abtastet und sie automatisch bewertet, ganz ohne Notebook-Lauf. Die Konfiguration selbst ist sichtbar in der Bedrock AgentCore-Konsole unter Assess → Evaluations → Evaluation configurations. Die Ergebnisse landen in der Log-Gruppe /aws/bedrock-agentcore/evaluations/results/<config-id>, und jede Bewertung wird außerdem als CloudWatch-Metrik im Bedrock-AgentCore/Evaluations -Namespace veröffentlicht, verschlüsselt nach Evaluator-Name und Konfigurations-ID, sodass man die Bewertungen grafisch darstellen oder Alarme darauf setzen kann, ohne Logs parsen zu müssen.

Der folgende Screenshot zeigt die Online-Evaluierungskonfiguration in der AgentCore-Konsole unter Assess, dann Evaluations, dann Evaluation configurations.

Abbildung 17: Die Online-Evaluierungskonfiguration in der AgentCore-Konsole, mit vier integrierten Evaluatoren bei 100 Prozent Sampling

Die Konfiguration listet vier integrierte Evaluatoren auf, Tool-Selection Accuracy, Faithfulness, Correctness und Response Relevance, eingestellt auf 100 Prozent Sampling und als ACTIVE und aktiviert angezeigt.

Da die Bewertungen gewöhnliche CloudWatch-Metriken sind, lassen sie sich wie alles andere grafisch darstellen, ohne Log-Parsing, und dasselbe Widget könnte einen Alarm tragen. Der folgende Screenshot zeigt diese vier Evaluator-Bewertungen als gewöhnliche CloudWatch-Metriken grafisch dargestellt.

Abbildung 18: Die vier kontinuierlichen Evaluator-Bewertungen als gewöhnliche CloudWatch-Metriken grafisch dargestellt

Die vier Evaluator-Bewertungen erscheinen als Metriken im Bedrock-AgentCore/Evaluations -Namespace, jeweils verknüpft mit der Evaluierungskonfigurations-ID und dem Servicenamen des Agenten, sodass man sie grafisch darstellen oder Alarme darauf setzen kann, ohne Logs parsen zu müssen.

Online-Ergebnisse kommen erst, nachdem eine Sitzung geschlossen wurde. Die Bewertung läuft auf der abgeschlossenen Sitzung, daher bleibt die Ergebnis-Log-Gruppe nach dem Erzeugen von Traffic für etwa die Sitzungs-Idle-Timeout-Zeit (~30 Minuten) leer. Eine leere Gruppe direkt nach einem Lauf ist zu erwarten und keine Fehlkonfiguration. Jedes Ergebnisereignis trägt session.id, sodass es sich mit jeder anderen Ebene verbinden lässt. Der On-Demand-Pfad im Notebook hat diese Wartezeit nicht, weshalb beide hier vorhanden sind.

Über die vier integrierten Evaluatoren dieses Laufs bewertete der kontinuierliche Pfad mit 1.00 bei Correctness, Faithfulness, Response Relevance und Tool-Selection Accuracy, fünf bewertete Traces pro Evaluator, wobei jedes Ergebnis eine schriftliche Erklärung enthielt.

⚠️ Sampling und Kosten. Diese App setzt SAMPLING_PERCENTAGE = 100 ausschließlich für das Blog-Experiment, sodass jede Sitzung bewertet wird und die Ergebnisse sofort sichtbar sind. Dies ist keine Produktions-Empfehlung. Die Online-Auswertung ruft pro gesampelter Sitzung ein LLM-as-judge auf, daher skaliert der Aufwand mit der Sampling-Rate und dem Datenverkehr. Für eine echte Bereitstellung wählen Sie einen Sampling-Prozentsatz, der zu Ihren Anforderungen an die Qualitätsüberwachung und Ihrem Budget passt, und stimmen Sie die Konfiguration auf die eigenen Richtlinien und Anforderungen Ihrer Organisation an die Kosten-Governance ab, bevor Sie sie aktivieren. Die Rate ist eine einzige Konstante, EvalConfig.SAMPLING_PERCENTAGE, in config.py.

Aufräumen

Wenn Sie fertig sind, entfernen Sie die Lösung, damit keine Kosten mehr anfallen, da gespeicherte KB-Daten, das Agent-Image in ECR und die weiterhin aktive Online-Auswertung alle Geld kosten, während die Stacks untätig herumliegen. Ein einziger Befehl baut alles ab:

cdk destroy --all

CDK löscht die Stacks selbstständig in umgekehrter Abhängigkeitsreihenfolge, Dashboards, dann Agent, dann Gateway, dann kb: derselbe Graph, den es für das Deployment abgeleitet hat, rückwärts durchlaufen. Es gibt kein Teardown-Skript, das mit dem Deployment-Skript konsistent gehalten werden muss – eine der leiseren, aber wertvollen Eigenschaften, die Abhängigkeiten nur einmal zu modellieren.

Zwei Löschverhalten sind wissenswert, denn beide ersetzen handgeschriebenen Aufräumcode:

self.source_bucket = s3.Bucket(
    self, "SourceBucket",
    removal_policy=RemovalPolicy.DESTROY,
    auto_delete_objects=True,  # replaces a list_object_versions delete loop
)

self.repository = ecr.Repository(
    self, "AgentImageRepo",
    removal_policy=RemovalPolicy.DESTROY,
    empty_on_delete=True,  # replaces an image-delete loop
)

Beide sind aus Gründen der Beispielhygiene gesetzt; für alles, was Ihnen wichtig ist, stellen Sie den Bucket um auf RemovalPolicy.RETAIN.

Der CDK-Bootstrap-Stack (CDKToolkit) und sein Staging-Bucket werden nicht entfernt. Es handelt sich um account-weit geteilte Infrastruktur, von der andere CDK-Apps abhängen können.

Was sich seit der Single-Shot-Lösung geändert hat

Sowohl dieser Beitrag als auch die 2024er Lösung sind CDK-Anwendungen in Python, deployt mit cdk deploy. Das Authoring-Werkzeug ist hier die Konstante; was sich geändert hat, ist die Architektur darunter, und der Großteil der Änderung besteht in Subtraktion:

Der Kompromiss ist in beide Richtungen real. Ein einzelner Index, der Single-Shot-Fragen beantwortet, ist pro Abfrage günstiger, einfacher nachzuvollziehen und völlig ausreichend, wenn ein Korpus die Antwort enthält. Greifen Sie zu diesem Design, wenn das nicht der Fall ist.

Die CDK-Konstrukte, die die Arbeit erledigen

Vier Konstrukte tragen die Hauptlast in dieser App, und sie sind eine Erwähnung wert, weil jedes etwas ersetzt, das Menschen sonst von Hand schreiben:

• Provider – Für benutzerdefinierte Ressourcen, die die 15-minütige Obergrenze einer AWS-Lambda-Funktion überdauern. Die on_event / is_complete Aufteilung bedeutet, dass in einer Poll-Schleife nichts schläft, und das Antwortprotokoll zurück an CloudFormation ist Sache des Frameworks und nicht ein in jedem Handler mitgelieferter urllib Callback.
• BucketDeployment – lädt die Korpora hoch, sodass die Ingestion-Custom-Resource nur noch ingests.
• auto_delete_objects=True und empty_on_delete=Trueersetzen die handgeschriebenen list_object_versions und Image-Delete-Schleifen, die ein Stack sonst benötigte, um überhaupt zerstörbar zu sein.
• repository.grant_pull_push(project) – Eine Zeile für die acht ecr:* actions, die CodeBuild benötigt, korrekt geschrieben quasi automatisch.

Und typisierte Dashboards, aus dem Observe-Abschnitt: Metric / GraphWidget / Row-Objekte statt eines DashboardBody-JSON-Strings, was eine ungültige Widget-Kombination von „wird kaputt auf der Konsole gerendert“ zu „schlägt fehl bei“ verschiebt, cdk synth.”

Zwei Dinge ändert CDK nicht, und beide sollte man kennen, bevor man beginnt:

• Freiform-JSON bleibt camelCase. connector_parameters und parameter_values werden unverändert durchgereicht, sodass die AWS-CDK-Konvertierung von snake_case zu PascalCase darin nicht greift. Schlüssel wie bucketName und inclusionPrefixes müssen exakt so geschrieben werden, wie die API es erwartet, und nichts weist Sie darauf hin, bis die Ressource fehlschlägt.
• String-typisierte Werte bleiben Strings. Der knowledge-base/<id> gegenüber nacktem <id> Dimensionsunterschied aus dem Observe-Abschnitt ist für das Typsystem unsichtbar. Typisierte Konstrukte prüfen Struktur, nicht Semantik.

Keines davon ist ein Grund, das eine Werkzeug dem anderen vorzuziehen. Es ist die Grenze dessen, was „typisiert“ einbringt, und zu wissen, wo diese Grenze verläuft, macht CDK zum größten Teil angenehm statt überraschend.

Fazit

Wir haben eine vollständige Enterprise-Agentic-Retrieval-Lösung auf Basis einer Managed Amazon Bedrock Knowledge Base und AgentCore gebaut: Multi-KB-semantisches Routing, einen Reasoning-Agent, sieben Schichten Observability sowie sowohl On-Demand- als auch kontinuierliche Evaluation – und das alles als eine einzige AWS-CDK-Anwendung deployt.

Zwei Dinge sind es wert, mitgenommen zu werden. Die managed Knowledge Base hat Infrastruktur entfernt, statt sie hinzuzufügen: kein zu provisionierender Vector Store, kein zu erstellender und abzuwartender Index, keine OCU-Position, die anläuft, während das System ungenutzt herumsteht. Es ist außerdem der Knowledge-Base-Typ, der agentic retrieval und den AgentCore-Gateway-Connector unterstützt, wie in der Amazon-Bedrock-Dokumentationbeschrieben. Und als Retrieval agentic wurde, hörte Observability auf, optional zu sein. Etwa die Hälfte dessen, was diese App provisioniert, existiert, um zu beantworten, was der Agent tatsächlich getan hat und ob die Antwort gut war – das ist kein Overhead eines agentic Systems. Es ist der Teil, der es betreibbar macht.

Das CDK-Authoring-Modell hat sich an den Nähten bewährt. Sieben Werte überqueren in dieser Architektur Stack-Grenzen, und jeder einzelne davon ist eine Konstrukt-Referenz statt eines Export-/Import-Paares – weshalb es auch kein Deploy-Skript, kein Teardown-Skript und keine feste Reihenfolge zu merken gibt.

Von hier aus können Sie die Datenquellen auf Ihre eigenen Korpora richten, den Agenten in eine Virtual Private Cloud (VPC) platzieren, die Sampling-Rate der Online-Evaluation an Ihr Budget und Ihre Richtlinien anpassen oder weitere Knowledge Bases zum Router hinzufügen. Um mehr zu erfahren, siehe die Amazon Bedrock Detailseite und die Amazon Bedrock-Dokumentation. Die App, das Driver-Notebook und die eigenständigen Hilfsprogramme befinden sich alle im zugehörigen GitHub-Repository, sodass Sie es klonen und Ihre eigene Kopie mit einem einzigen Befehl bereitstellen können.

Über die Autoren