Oliver Bühler
Agentic AI

Einen Agent ohne Vektordatenbank grounden: AgentCore Managed Knowledge Base

17 min Lesezeit
#aws#agentic-ai#demo#agentcore#bedrock#knowledge-base#rag
Einen Agent ohne Vektordatenbank grounden: AgentCore Managed Knowledge Base

Hinweis: Dieser Artikel wurde mit Unterstützung von KI aus dem englischen Original übersetzt.

TL;DR: Ich habe diesen Agent gegroundet, ohne eine Vektordatenbank aufzusetzen. Eine Bedrock Managed Knowledge Base bezieht Dokumente aus einem privaten S3-Bucket und drei web-gecrawlten Quellen. Sie wird dem Modell als zwei zusätzliche Tools über dasselbe Gateway wie alle anderen Tools bereitgestellt. Der entscheidende Punkt: Kein Terraform-Provider bietet einen Ressourcentyp für ein Gateway-Connector-Target. Also wird das managed-kb-Target von einem kleinen boto3-Skript innerhalb einer terraform_data-Ressource erstellt. Diese Umgehungslösung funktioniert, kostet aber Drift-Erkennung und verlangt eine manuell festgelegte Reihenfolge.

Teil 6 der Serie „Einen Partner-Sales-Agent auf Amazon Bedrock AgentCore bauen“, aufgebaut um ein reales Projekt: ein dialogbasierter Agent, der HubSpot CRM und AWS Partner Central für das Sales-Team eines AWS-Partners verbindet. Dieser Artikel widmet sich der Grounding-Ebene: Er nutzt eine Bedrock Managed Knowledge Base, die ihre Informationen aus einem S3-Bucket und drei Web-Crawler-Datenquellen bezieht, und diese Knowledge Base wird dem Agent über dasselbe Gateway zugänglich gemacht, das in Artikel 4 eingeführt wurde.

Inhaltsverzeichnis

Die Antworten des Agents kamen ohne Vektordatenbank aus; stattdessen liefen zwei Arten der Ingestion in eine einzige Managed Knowledge Base.

Wie der erste Artikel bereits festgehalten hat, besitzt dieses System keine eigene Datenbank, weil HubSpot und Partner Central die maßgeblichen Systeme bleiben. Die einzigen Daten, die das Projekt selbst besitzt, liegen in einem Ordner voller Dokumente. Dieser Artikel widmet sich genau diesem Ordner, den drei öffentlichen Websites, die dafür gecrawlt wurden, und einem Einrichtungsaspekt, den zum Build-Zeitpunkt kein Terraform-Provider abbilden konnte. Er baut auf dem Gateway-Target-Mechanismus auf, denn Retrieval wird als zwei zusätzliche Tools innerhalb derselben kontrollierten Umgebung hinzugefügt. Und er bereitet Artikel 7 vor, in dem die Live-Demo auf dieser Grundlage Competency- und Sales-Case-Fragen beantwortet.

KB-Übersicht

Warum Managed statt klassischer KB plus Vektorspeicher?

Es gibt zwei Konfigurationen von Bedrock Knowledge Bases, und sie verlangen von Ihnen ein sehr unterschiedliches Maß an Entscheidungen [1]. Die klassische Variante verlangt folgende Entscheidungen: einen Embedding-Modell-ARN, ein Storage-Backend wie eine OpenSearch-Serverless-Collection oder eine Aurora-PostgreSQL-Tabelle mit pgvector, sowie eine Chunking-Strategie pro Datenquelle. Diese Entscheidungen sind wichtig, wenn die Qualität Ihres Retrievals davon abhängt, und sind reine Bedienoberfläche, wenn nicht. Die Managed-Variante nimmt Ihnen all diese Entscheidungen ab: Sie wählen den Typ der Managed Knowledge Base, weisen ihr eine Service-Role zu, und der Service liefert daraufhin selbst die Defaults für Embedding-Modell, Chunking und Verschlüsselung [1].

In der Bedrock-Konsole reduziert das die KB-Erstellung auf einen Namen und eine Rolle. Eine Einschränkung versteckt sich in der Rolle und stolpert einen leicht: Ihr Name muss mit AmazonBedrockExecutionRoleForKnowledgeBase_ beginnen. Ich habe diese Anforderung tief in der Attributbeschreibung des Resource-Schemas gefunden. Die Rolle selbst braucht s3:GetObject und s3:ListBucket auf den Dokumenten-Bucket, damit die Ingestion lesen kann, was Sie hochladen – und zunächst nichts weiter.

Im automatisierten Build ist die gesamte Knowledge Base das hier:

HCL
resource "awscc_bedrock_knowledge_base" "kb" {  name     = "partner-growth-agent-kb"  role_arn = aws_iam_role.kb_role.arn # name must start with AmazonBedrockExecutionRoleForKnowledgeBase_​  knowledge_base_configuration = {    type = "MANAGED"    # The empty object is the complete configuration: service-managed    # embedding model, chunking, and encryption defaults.    managed_knowledge_base_configuration = {}  }}

Das leere managed_knowledge_base_configuration = {} ist der eigentliche Clou dieses Designs. Ich habe das CloudFormation-Resource-Type-Schema geprüft, bevor ich mich darauf verlassen habe: ManagedKnowledgeBaseConfiguration deklariert überhaupt keine Pflichtfelder, {} ist also eine gültige, vollständige Konfiguration und kein Zufallstreffer. Eine Automatisierungs-Fußnote, die ein Konsolen-Leser nie zu Gesicht bekommt: hashicorp/aws (6.54.0 zur Build-Zeit) hatte keinen managed_knowledge_base_configuration-Block an seiner Knowledge-Base-Ressource, eine Lücke, die stromaufwärts erfasst war und inzwischen geschlossen wurde (der Fix wurde im Juli 2026 für Provider v6.56.0 gemerged) [2], weshalb jede KB-Ressource in diesem Build stattdessen den Cloud-Control-gestützten hashicorp/awscc-Provider verwendet.

Dieser Tausch hat Grenzen, und ein Leser mit anderen Anforderungen sollte wissen, wo sie liegen. Eine Managed KB bietet keine einstellbare Chunking-Strategie und keine Wahl des Embedding-Modells. Wenn Sie ein bestimmtes Embedding-Modell, eine individuelle Chunk-Größe oder einen über mehrere Knowledge Bases geteilten Index brauchen, ist der klassische Pfad die richtige Wahl, und der Zero-Config-Tausch dieses Artikels steht nicht mehr zur Verfügung. Der Korpus dieses Projekts – AWS-Partner-Central-Dokumentation plus Tallence-Sales-Enablement-Material – brauchte nichts davon, also fiel die Wahl in die andere Richtung. Artikel 1s Rahmen des „kein eigenständiges System of Record“ hatte die KB bereits so positioniert: HubSpot, Partner Central und diese KB sind die einzigen Datenquellen, mit denen das Projekt arbeitet, und die KB ist diejenige, die kein Live-externes System ist.

Quelle eins: der S3-Dokumenten-Bucket

Die erste Datenquelle ist ein privater S3-Bucket mit AWS-Partner-Central- und Tallence-Sales-Enablement-Dokumenten, auf denen die Antworten der Demo gründen. Öffentlicher Zugriff ist blockiert, Objekte sind at rest mit SSE-S3 verschlüsselt. Dokumente werden direkt über die Konsole hochgeladen.

Die entscheidende operative Eigenschaft: Eine Datei in diesen Bucket zu legen, löst die Ingestion aus. Ein S3-ObjectCreated-Event ruft eine kleine Ingestion-Lambda auf, die StartIngestionJob aufruft. Es gibt keinen Konsolen-Button zum Drücken oder Sync-Skript, das man danach ausführen müsste. Der vollständige Mechanismus und sein einer Haken werden weiter unten unter „Wenn Sie das nachbauen“ erklärt.

In der Bedrock-Konsole ist das Anbinden des Buckets ein Schritt auf dem Data-Source-Tab der Knowledge Base: eine S3-Datenquelle mit Namen, Bucket, optionalem Prefix und der Account-ID des Bucket-Eigentümers hinzufügen, die die Konsole für Buckets im selben Account selbst ableitet. Denselben Bucket über Terraform anzubinden, förderte eine Überraschung zutage, die Konsolen-Nutzer nie zu sehen bekommen: Die Connection-Configuration des Connectors verlangt bucketOwnerAccountId. Der erste Apply ohne dieses Feld bestand die Erstellung, scheiterte aber an der asynchronen Validierung mit Member must not be null. Der Fehler tauchte erst später in den failureReasons der Datenquelle auf – ein Muster, das sich in diesem Artikel noch in größerem Maßstab wiederholt.

HCL
resource "awscc_bedrock_data_source" "kb_s3" {  knowledge_base_id = awscc_bedrock_knowledge_base.kb.knowledge_base_id  name              = "s3-documents"​  data_source_configuration = {    type = "MANAGED_KNOWLEDGE_BASE_CONNECTOR"​    managed_knowledge_base_connector_configuration = {      connector_parameters = jsonencode({        type    = "S3"        version = "1"        connectionConfiguration = {          bucketName           = aws_s3_bucket.kb_documents.bucket          bucketOwnerAccountId = data.aws_caller_identity.current.account_id # required, not optional        }        aclEnabled = false        filterConfiguration = {          maxFileSizeInMegaBytes = "500"        }      })    }  }}

AWS AgentCore Managed Knowledge Base

Quelle zwei: drei Web-Crawler-Datenquellen

Der Korpus brauchte außerdem aktuellen öffentlichen Content: den Partner-Central-Dokumentationsbaum unter docs.aws.amazon.com/partner-central/, einen APN-Blogpost zur Bewerbung um eine AWS Competency und die APN-Partnerprogramm-Seiten. Die Anforderung war ein Deep Crawl mit Tiefe 10, eng begrenzt auf den jeweiligen URL-Pfad jedes Seeds.

Ob sich diese Anforderung überhaupt ausdrücken lässt, hängt vom Typ der erstellten KB ab, denn AWS bietet zwei strukturell unterschiedliche Web-Crawler-Schemas an. Der Crawler der klassischen KB kennt kein Crawl-Depth-Feld; er bietet ein Seitenlimit, ein Rate-Limit und ein Scope-Enum aus HOST_ONLY oder SUBDOMAINS [3]. Das Connector-Schema der Managed KB ist reichhaltiger: crawlConfiguration.crawlDepth akzeptiert 0 bis 10 mit Default 2, und syncScope = "PATH_SPECIFIC" begrenzt den Crawl auf Host und Pfad-Prefix der Seed-URL [4]. Tiefe 10 ließ sich exakt wie gefordert erreichen, aber nur, weil die übergeordnete KB Managed war. Bei einer klassischen KB hätte das Design von Anfang an einen Kompromiss verlangt.

In der Konsole wird jeder Crawler über denselben Data-Source-Tab als Datenquelle vom Typ Web Crawler hinzugefügt, und die folgenden Felder sind genau die, nach denen das Formular fragt: ein Name, eine Seed-URL, der Sync Scope, die Crawl-Tiefe und Inclusion Patterns. Pro Datenquelle zählen: eine Seed-URL, authType = "NO_AUTH" für eine öffentliche Site, die Crawl-Tiefe, der Sync Scope, maxCrawledUrlsPerMinute (hier 50), crawlAttachments = false und ein Inclusion-Regex. Es gibt drei Datenquellen statt einer mit drei Seeds, aus einem Schema-Grund: inclusionPatterns gilt für die gesamte Datenquelle, nicht pro Seed [4]. Zwei der drei Seeds liegen auf dem breiten Marketing-Host aws.amazon.com, jeder brauchte also ein eigenes Pfad-Prefix-Regex zur Scope-Reduktion, und jedes Regex brauchte seine eigene Ressource.

Eine der drei, verdichtet auf die oben genannten Felder:

HCL
resource "awscc_bedrock_data_source" "kb_web_partner_central_docs" {  knowledge_base_id = awscc_bedrock_knowledge_base.kb.knowledge_base_id  name              = "web-partner-central-docs"​  data_source_configuration = {    type = "MANAGED_KNOWLEDGE_BASE_CONNECTOR"​    managed_knowledge_base_connector_configuration = {      connector_parameters = jsonencode({        type    = "WEB"        version = "1"        connectionConfiguration = {          seedUrls = ["https://docs.aws.amazon.com/partner-central/"]          authType = "NO_AUTH"        }        crawlConfiguration = {          crawlDepth              = 10          maxCrawledUrlsPerMinute = 50          syncScope               = "PATH_SPECIFIC"          crawlAttachments        = false        }        filterConfiguration = {          inclusionPatterns      = ["^https://docs\\.aws\\.amazon\\.com/partner-central/.*"]          maxFileSizeInMegaBytes = "500"        }        aclEnabled = false      })    }  }}

Die beiden kleineren Seeds erreichten den Ingestion-Status COMPLETE schnell, ganz ohne Fehler. Der Partner-Central-Docs-Seed brauchte rund 1 Stunde 50 Minuten und endete bei 1.271 gescannten Dokumenten: 615 neue und 36 geänderte Dokumente indexiert, 619 als außerhalb des Scopes übersprungen, und genau 1 Fehler – eine Rate von 0,08 %.

Bevor Sie Ihren eigenen Crawl starten, dieses Zähler-Verhalten vorab: numberOfDocumentsScanned stieg noch lange weiter, nachdem numberOfNewDocumentsIndexed sein Plateau erreicht hatte [5]. Das ist kein Hänger. crawlDepth begrenzt, wie weit sich der Crawler vom Seed entfernen darf, sagt aber nichts über die verstrichene Zeit aus. Jeder entdeckte Link, auch Out-of-Scope-Links, muss besucht werden, bevor er als außerhalb des Scopes bestätigt und als übersprungen markiert werden kann. Ein Seed auf einem großen Host schleppt also eine Link-Frontier mit sich, die weit größer ist als sein indexierter Korpus. In diesem Crawl existierten 619 der 1.271 gescannten Dokumente nur dafür, als überspringbar bestätigt zu werden.

Crawler-Detail

Das managed-kb-Gateway-Target: eine Notlösung, keine Ressource

Ingestion füllt die Knowledge Base. Ein Gateway-Connector-Target ist das, was sie dem Agent in die Hand gibt: Es verwandelt eine bestehende AWS-Ressource direkt in MCP-Tools, ohne Lambda dazwischen – anders als die fünf Lambda-gestützten Targets, die Artikel 4 durchgegangen ist [6].

In der AgentCore-Konsole ist das ein ganz gewöhnliches Target. Gateway öffnen, ein Target hinzufügen, den Knowledge-Base-Connector wählen (Connector-ID bedrock-knowledge-bases), auf die KB zeigen und die eigene IAM-Rolle des Gateways als Credential Provider auswählen [6]. Am Konsolenweg deutet nichts auf irgendetwas Ungewöhnliches hin; die Notlösung, nach der dieser Abschnitt benannt ist, ist ausschließlich ein Befund aus dem Automatisierungspfad, und ein reiner Konsolen-Leser kann sich hier entspannen.

Das Target namens managed-kb stellt zwei Tools unter demselben pc-Tool-Block bereit wie jedes andere Target: Retrieve, eine einfache Basissuche, und AgenticRetrieveStream, ein mehrstufiges agentisches Retrieval, an das der System-Prompt dieses Projekts Competency- und Sales-Case-Fragen weiterleitet. Auf der Harness-Allowlist erscheinen sie als @pc/managed-kb___Retrieve und @pc/managed-kb___AgenticRetrieveStream. Eine Konfigurationsentscheidung zum Übernehmen: generateResponse = false, sodass das Tool abgerufene Passagen zurückgibt, statt selbst einen Antworttext zu synthetisieren, und der System-Prompt des Agents die „Quellen:“-Zitate am Ende der Antwort selbst formatiert. Ein einheitliches Zitierformat über alle Tools hinweg schlägt einen zweiten Antwort-Generator innerhalb eines Tools.

Jetzt zur Automatisierungslücke. Weder hashicorp/aws (6.54.0) noch hashicorp/awscc (1.92.0) liefert einen Ressourcentyp für ein Gateway-Connector-Target [7]; wer im Terraform dieses Builds nach einer sechsten Gateway-Target-Ressource sucht, findet keine. Die Umgehungslösung ist eine terraform_data-Ressource [8], deren Create- und Destroy-Provisioner ein eingecheckt vorliegendes Python-Skript aufrufen, das seinerseits über boto3 create_gateway_target aufruft:

HCL
resource "terraform_data" "kb_gateway_target" {  triggers_replace = {    gateway_id  = aws_bedrockagentcore_gateway.agent.gateway_id    kb_id       = awscc_bedrock_knowledge_base.kb.knowledge_base_id    target_name = "managed-kb"    region      = var.aws_region # destroy-time provisioners may only reference self    # Forces recreation if the retriever/citation config changes.    config_hash = md5(jsonencode({ /* retrievers, agenticRetrieveConfiguration, generateResponse */ }))  }​  provisioner "local-exec" {    command = "python ${path.module}/scripts/gateway_kb_target.py --action create --gateway-id ${aws_bedrockagentcore_gateway.agent.gateway_id} --kb-id ${awscc_bedrock_knowledge_base.kb.knowledge_base_id} --name managed-kb --region ${var.aws_region}"  }​  provisioner "local-exec" {    when    = destroy    command = "python ${path.module}/scripts/gateway_kb_target.py --action destroy --gateway-id ${self.triggers_replace["gateway_id"]} --name ${self.triggers_replace["target_name"]} --region ${self.triggers_replace["region"]}"  }}

Warum ein Python-Skript statt eines Aufrufs der AWS CLI, der überhaupt keine Datei bräuchte? Eine Versions-Entdeckung, nach der ich inzwischen routinemäßig suche: Die installierte AWS CLI (2.27.57) brachte ein botocore mit, das das connector-Member der Tagged Union der Target-Configuration überhaupt nicht modellierte. Ihre Hilfe listete nur openApiSchema, smithyModel, lambda, mcpServer und apiGateway auf – das sieht exakt so aus wie „die API unterstützt das noch nicht“. Das im Projekt bereits per pip installierte boto3 (1.43.36) modellierte mcp.connector vollständig. CLI und Ihre Python-Dependencies liefern separate botocore-Kopien mit getrennten Release-Zyklen aus.

Das Payload hatte eine Korrektur zu lehren. Ich hatte generateResponse verschachtelt innerhalb von agenticRetrieveConfiguration, und der Live-Call wies das mit einer ValidationException zurück, die genau diesen Pfad benannte. Der Devguide platziert es als Geschwister von retrievers und agenticRetrieveConfiguration, direkt unter parameterValues [6][9]. Verlassen Sie sich bei dieser Fehlerklasse nicht auf clientseitige Validierung: parameterValues ist in botocore eine ungetypte Document-Shape, nichts validiert also ihren Inhalt vor dem Aufruf, und der asynchrone READY-Poll ist die einzige Feedback-Schleife, die ein fehlerhaftes Payload abfängt. Mit dem verschobenen Feld erreichte das Target beim nächsten Versuch in rund 7 Sekunden READY.

Python
def _target_configuration(kb_id):    return {        "mcp": {            "connector": {                "source": {"connectorId": "bedrock-knowledge-bases"},                "configurations": [                    {                        "name": "AgenticRetrieveStream",                        "parameterValues": {                            "retrievers": [{                                "description": "AWS Partner Central competencies + Tallence sales-enablement corpus",                                "configuration": {"knowledgeBase": {"knowledgeBaseId": kb_id}},                            }],                            "agenticRetrieveConfiguration": {                                "foundationModelType": "MANAGED",                                "rerankingModelType": "MANAGED",                            },                            # Sibling of retrievers, NOT nested inside                            # agenticRetrieveConfiguration -- the live call                            # rejects the nested shape by exact path.                            "generateResponse": False,                        },                    },                    {"name": "Retrieve", "parameterValues": {"knowledgeBaseId": kb_id}},                ],            }        }    }​response = client.create_gateway_target(    gatewayIdentifier=gateway_id,    name="managed-kb",    targetConfiguration=_target_configuration(kb_id),    credentialProviderConfigurations=[{"credentialProviderType": "GATEWAY_IAM_ROLE"}],)# ...then poll get_gateway_target until READY or FAILED. This poll is the# only validation feedback the connector target gives you.

Zwei Grenzen der Notlösung, klar benannt. terraform_data hat kein Read und kein Refresh, es gibt also keine Drift-Erkennung: Eine Änderung direkt über die AWS-API erscheint nie in einem Plan, und nur die Felder in triggers_replace erzwingen eine Neuerstellung. Und die Reihenfolge brauchte ein explizites depends_on: Der READY-Poll des Skripts verlangt bedrock:GetKnowledgeBase auf der Gateway-Rolle, und nichts sonst im Graph ordnete diese Policy vor dem Target ein.

Das IAM des Connectors lebt auf der Service-Role des Gateways, in drei Statements. bedrock:GetKnowledgeBase (das die READY-Validierung braucht) und bedrock:Retrieve sind beide auf den ARN der einen Knowledge Base begrenzt. Das dritte kann das nicht sein:

HCL
statement {  sid       = "AgenticRetrieveStream"  effect    = "Allow"  actions   = ["bedrock:AgenticRetrieveStream"]  resources = ["*"]}

AWS unterstützt es nicht, bedrock:AgenticRetrieveStream auf eine einzelne Knowledge Base zu begrenzen [10]. Resource = "*" ist das einzige Grant, das funktioniert: Die Action ist reines Read-only-Retrieval, und es ist das einzige breite Grant auf dieser Rolle. Die verallgemeinerbare Regel: einen Wildcard dort akzeptieren, wo AWS ihn erzwingt, und direkt neben dem Grant festhalten, warum es nicht enger ging.

Zitat im Chat

Übertragbare Muster

Sechs Gewohnheiten aus diesem Subsystem lassen sich über diese Demo hinaus auf jeden AgentCore-Build übertragen.

  • Managed KB als Heuristik für die Provider-Wahl. Wenn eine Wissensquelle keine individuelle Chunking-Strategie und kein bestimmtes Embedding-Modell braucht, ist das leere managed_knowledge_base_configuration-Objekt der schnellste Weg mit der geringsten operativen Angriffsfläche, um Retrieval aufzusetzen. Heben Sie sich den klassischen Pfad für den Fall auf, dass eine echte Anforderung einen bestimmten Index oder eine bestimmte Embedding-Wahl erzwingt – und benennen Sie diese Anforderung, bevor Sie dafür bezahlen.
  • Eine Datenquelle pro Seed-URL. Weil inclusionPatterns für die gesamte Datenquelle gilt und nicht für einen einzelnen Seed, braucht ein Projekt, das N unabhängige Sites crawlt, N Datenquellen-Ressourcen, jede mit eigenem Inclusion-Regex. Planen Sie das von Anfang an ein, statt es mitten im Build zu entdecken.
  • Verify-then-Import schlägt Retry bei einem Cloud-Control-Fehlalarm. Wenn ein CreateResource-Waiter einen InternalFailure meldet, die Ressource aber plausibel fertiggestellt wurde, prüfen Sie zuerst direkt über die zugrunde liegende Service-API, bevor Sie erneut an Terraform gehen. Ein blinder Retry kollidiert mit der bereits existierenden Ressource; ein verifizierter terraform import nicht.
  • terraform_data plus ein eingechecktes Skript ist die Notlösung, kein Hack. Wenn für eine AWS-Fähigkeit noch keine Provider-Ressource existiert, hält das Einbetten eines direkten boto3-Aufrufs in terraform_data die Aktion innerhalb von Terraforms Apply-Graph und State statt in einem Runbook – ohne Monate auf Provider-Unterstützung zu warten. Wissen Sie, worauf Sie verzichten: kein Refresh, keine Drift-Erkennung, und eine Reihenfolge, die Sie selbst deklarieren müssen.
  • Akzeptieren Sie Resource = "*" nur dort, wo AWS es erzwingt – und sagen Sie das auch. AgenticRetrieveStream ist die einzige Stelle im IAM dieses Projekts, an der eine Begrenzung auf einen einzelnen ARN nicht möglich ist. Den Wildcard zu gewähren ist in Ordnung; ihn ohne Kommentar zu gewähren, warum es nicht enger ging, nicht.

Wenn Sie das nachbauen

Zwei Dinge werden Sie hier Zeit kosten, und keines davon ist ein Defekt.

Ein Dokument in den KB-Bucket hochzuladen ist bereits der komplette Ingestion-Trigger. In diesem Build ruft das ObjectCreated-Event des Uploads eine Ingestion-Lambda auf, die für Sie StartIngestionJob aufruft – es gibt also keinen separaten manuellen „Ingestion starten“-Schritt. Wenn der Upload erfolgreich war, läuft der Job bereits; verfolgen Sie seinen Fortschritt in der Data-Source-Ansicht der Bedrock-Konsole oder mit aws bedrock-agent get-ingestion-job. Wenn Sie ohne diese Event-Verdrahtung nachbauen, ist das Äquivalent ein einzelner StartIngestionJob-Aufruf nach jedem Upload, und nicht mehr.

Planen Sie für einen breiten Seed mit crawlDepth = 10 Stunden ein, nicht Minuten. Der Crawler besucht jeden entdeckten Out-of-Scope-Link, um ihn als außerhalb des Scopes zu bestätigen, bevor er ihn als übersprungen markiert, sodass der Scan-Zähler noch lange weitersteigt, nachdem keine neuen indexierten Dokumente mehr auftauchen, und ein Dokumentationsbaum in der Größe von Partner Central end-to-end fast zwei Stunden braucht. Das ist erwartetes Verhalten, kein Hänger – und kein Rebuild-Schritt, den man zwanzig Minuten vor Publikum laufen lässt.

Damit ist der letzte Baustein abgeschlossen.

Ich hoffe, dieser Artikel war hilfreich für Sie. Ich freue mich über Feedback, was Ihnen gefallen hat und was nicht, damit ich künftige Artikel verbessern kann.

Quellen

[1] Amazon Bedrock Knowledge Bases: Knowledge-Base-Typen und -Konfiguration, mit dem Managed-Typ im Vergleich zu den Embedding-Modell-, Vektorspeicher- und Chunking-Anforderungen des klassischen/Vektor-Pfads. https://docs.aws.amazon.com/bedrock/latest/userguide/kb-build-managed.html

[2] hashicorp/terraform-provider-aws Issue #48744: keine Unterstützung für managed_knowledge_base_configuration an der Knowledge-Base-Ressource zur Build-Zeit (Provider 6.54.0); die Lücke schloss sich, als PR #48904 am 16.07.2026 gemerged wurde, vorgesehen für v6.56.0. https://github.com/hashicorp/terraform-provider-aws/issues/48744

[3] Amazon Bedrock Web-Crawler-Connector für klassische Knowledge Bases: Seitenlimits, Rate-Limit und das HOST_ONLY/SUBDOMAINS-Scope-Enum, ohne Crawl-Depth-Feld. https://docs.aws.amazon.com/bedrock/latest/userguide/webcrawl-data-source-connector.html; https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_WebCrawlerConfiguration.html

[4] Managed-Knowledge-Base-Web-Connector-Parameter: crawlConfiguration.crawlDepth (0–10, Default 2), syncScope-Werte einschließlich PATH_SPECIFIC sowie datenquellenweite inclusionPatterns. https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-ds-webcrawler.html

[5] Amazon Bedrock GetIngestionJob-API-Referenz: Statistikfelder des Ingestion-Jobs (numberOfDocumentsScanned, numberOfNewDocumentsIndexed, numberOfModifiedDocumentsIndexed, numberOfDocumentsFailed) sowie die Top-Level-failureReasons. https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetIngestionJob.html

[6] Amazon Bedrock AgentCore Developer Guide: das Managed-Knowledge-Base-Gateway-Connector-Target, einschließlich der administratorseitig gesetzten Felder retrievers, agenticRetrieveConfiguration und generateResponse. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-managed-kb.html

[7] Terraform-Provider-Abdeckung für AgentCore-Gateway-Connector-Targets. https://github.com/hashicorp/terraform-provider-aws/issues/48503

[8] Terraform-Dokumentation: die Managed Resource terraform_data. https://developer.hashicorp.com/terraform/language/resources/terraform-data

[9] Amazon Bedrock AgentCore Developer Guide: Gateway-Target-Configuration-Shapes für API-Targets. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-add-target-api-target-config.html

[10] Service Authorization Reference für Amazon Bedrock: die Action bedrock:AgenticRetrieveStream und ihre Resource-Scoping-Möglichkeiten. https://docs.aws.amazon.com/service-authorization/latest/reference/list_bedrock.html