Amazon Kendra ist nicht mehr offen für neue Kunden. In den Amazon Bedrock Knowledge Bases finden Sie ähnliche Funktionen wie. Amazon KendraWeitere Informationen.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Amazon Kendra Änderung der Verfügbarkeit

-Übersicht

Nach reiflicher Überlegung haben wir beschlossen, mit Wirkung zum 30. Juni 2026 Amazon Kendra in den Wartungsmodus zu wechseln. Zu diesem Zeitpunkt wurden keine neuen Funktionen oder Funktionen für den Service entwickelt, und seit dem 30. Juli 2026 steht der Service nicht mehr für Neukunden zur Verfügung.

Im Wartungsmodus wird der Dienst weiterhin vollständig unterstützt und AWS es werden weiterhin Bugfixes und Sicherheitsupdates für Bestandskunden bereitgestellt. Anfragen neuer Funktionen werden jedoch nicht mehr berücksichtigt.

Wir empfehlen Kunden, ihre Kendra-Anwendungen zu migrieren und alle neuen Suchanwendungen in der Amazon Bedrock Managed Knowledge Base (BMKB) zu implementieren, um ähnliche Funktionen wie Kendra und erweiterte Funktionen für generative KI und agentische KI zu nutzen. Bedrock Managed Knowledge Base ist eine vollständig verwaltete RAG-Lösung mit integrierten Konnektoren, intelligentem Parsing, verwaltetem Vektorspeicher mit Hybridsuche sowie der Möglichkeit, Antworten (mit einer Retrieve and Generate API) zu generieren und mehrstufige Überlegungen in mehreren Wissensdatenbanken durchzuführen (mit einer Agentic Retrieval API). BMKB bietet Ihnen auch die Möglichkeit, die Chunking-Strategien und Einbettungsmodelle anzupassen, um sie für Ihre spezifische Anwendung zu optimieren, und das Basismodell für die Antwortgenerierung auszuwählen. Dieses neue Maß an Funktionen und Flexibilität ist mit vorhersehbaren Kosten verbunden, die auf der Größe der aufgenommenen Wissensdatenbank, der Anzahl der durchgeführten Abfragen und der LLM-Nutzung basieren.

Anleitung zur Migration

Die Migration von der Amazon Bedrock Managed Knowledge Base (BMKB) Amazon Kendra zur Amazon Bedrock Managed Knowledge Base (BMKB) ist für die meisten Unternehmens-Such- und RAG-Workloads mit einer sorgfältigen Planung durchführbar. Nicht alle Kendra-Funktionen sind direkt in der Bedrock Managed Knowledge Base verfügbar, aber viele können mithilfe von Problemumgehungen implementiert werden. Dieses Handbuch bietet bestehenden Kendra-Kunden einen umfassenden, schrittweisen Migrationspfad zur Umstellung ihrer Anwendungen auf BMKB, einschließlich Architektur-Mapping, API-Übersetzung, Codebeispielen, Analyse von Funktionslücken und empfohlenen Problemumgehungen.

Funktionen der Amazon Bedrock Managed Knowledge Base

BMKB verwaltet die gesamte RAG-Pipeline von Anfang bis Ende. Es unterstützt Einbettungsmodelle wie Amazon Titan Text Embeddings V2, Cohere Embed English v3, Cohere Embed Multilingual v3, Cohere Embed v4 und Amazon Nova Multimodal Embedings — alle auf 1024 Dimensionen mit float32-Vektoren festgelegt. Der Managed Vector Store wird vollständig von Bedrock betrieben, sodass Aurora oder andere Vektordatenbanken nicht bereitgestellt oder verwaltet werden müssen. OpenSearch Zu den Chunking-Strategien gehören Standard (feste Größe bei etwa 300 Token), (konfigurierbare MaxTokens und OverlapPercentage), Hierarchisch Fixed-size (übergeordnetes Kind mit Ebenenkonfigurationen) und No Chunking. Semantisches Chunking wird für verwaltete Wissensdatenbanken nicht unterstützt.

BMKB unterstützt derzeit sieben Datenquellenkonnektoren: Amazon S3, Confluence, Microsoft, Web Crawler, Google Drive, Microsoft und einen benutzerdefinierten Connector. SharePoint OneDrive Der Dienst führt immer eine Hybridsuche durch (Schlüsselwort plus Semantik) und bietet keinen rein semantischen Suchmodus.

Migrationsschritte

Einrichtung der von Amazon Bedrock verwalteten Wissensdatenbank

Schritt 1: IAM-Rollen konfigurieren

Erstellen Sie eine IAM-Rolle, die Bedrock die Erlaubnis erteilt, auf Ihre Datenquellen zuzugreifen und Einbettungsmodelle aufzurufen. Die Vertrauensrichtlinie muss es bedrock.amazonaws.com ermöglichen, die Rolle zu übernehmen, und die Berechtigungsrichtlinie muss den Zugriff auf Ihre S3-Buckets und das ausgewählte Einbettungsmodell beinhalten.

IAM-Konfiguration (Python-Code):

import boto3
import json

iam = boto3.client('iam')

trust_policy = {
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"Service": "bedrock.amazonaws.com"},
        "Action": "sts:AssumeRole"
    }]
}

iam.create_role(
    RoleName="BedrockKBRole",
    AssumeRolePolicyDocument=json.dumps(trust_policy),
    Description="Role for Bedrock Managed Knowledge Base"
)

permissions_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:GetObject", "s3:ListBucket"],
            "Resource": [
                "arn:aws:s3:::your-bucket-name",
                "arn:aws:s3:::your-bucket-name/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": ["bedrock:InvokeModel"],
            "Resource": ["arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0"]
        }
    ]
}

iam.put_role_policy(
    RoleName="BedrockKBRole",
    PolicyName="BedrockKBPermissions",
    PolicyDocument=json.dumps(permissions_policy)
)
                

Schritt 2: Erstellen Sie eine verwaltete Wissensdatenbank

Verwenden Sie die CreateKnowledgeBase API mit dem Typ MANAGED, um die Wissensdatenbank zu erstellen:

import boto3

bedrock_agent = boto3.client("bedrock-agent", region_name="us-east-1")

response = bedrock_agent.create_knowledge_base(
    name="my-managed-kb",
    description="Migrated from Kendra index",
    roleArn="arn:aws:iam::123456789012:role/BedrockKBRole",
    knowledgeBaseConfiguration={
        "type": "MANAGED",
        "managedKnowledgeBaseConfiguration": {
            "embeddingModelArn": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0",
            "embeddingModelConfiguration": {
                "bedrockEmbeddingModelConfiguration": {
                    "embeddingDataType": "FLOAT32"
                }
            }
        }
    }
)

kb_id = response["knowledgeBase"]["knowledgeBaseId"]
print(f"Created knowledge base: {kb_id}")
                

Schritt 3: Datenquellen konfigurieren

Erstellen Sie eine S3-Datenquelle mit der verwalteten Connector-Konfiguration:

response = bedrock_agent.create_data_source(
    knowledgeBaseId=kb_id,
    name="my-s3-data-source",
    description="Product documentation from S3",
    dataSourceConfiguration={
        "type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR",
        "managedKnowledgeBaseConnectorConfiguration": {
            "connectorParameters": {
                "type": "S3",
                "version": "1",
                "connectionConfiguration": {
                    "bucketName": "your-bucket-name",
                    "bucketOwnerAccountId": "123456789012"
                },
                "filterConfiguration": {
                    "inclusionPrefixes": ["documents/"]
                }
            }
        }
    },
    vectorIngestionConfiguration={
        "parsingConfiguration": {
            "parsingStrategy": "SMART_PARSING"
        }
    }
)

data_source_id = response["dataSource"]["dataSourceId"]
print(f"Created data source: {data_source_id}")
                

Schritt 4: Starten und überwachen Sie die Einnahme

Initiieren Sie die Erfassung von Dokumenten und führen Sie eine Umfrage zur Fertigstellung durch:

import time

ingestion_response = bedrock_agent.start_ingestion_job(
    knowledgeBaseId=kb_id,
    dataSourceId=data_source_id,
    description="Initial ingestion"
)

ingestion_job_id = ingestion_response["ingestionJob"]["ingestionJobId"]
print(f"Started ingestion job: {ingestion_job_id}")

while True:
    job_response = bedrock_agent.get_ingestion_job(
        knowledgeBaseId=kb_id,
        dataSourceId=data_source_id,
        ingestionJobId=ingestion_job_id
    )
    job = job_response["ingestionJob"]
    status = job["status"]
    stats = job.get("statistics", {})

    print(f"Status: {status} | Scanned: {stats.get('numberOfDocumentsScanned', 0)} | "
          f"Indexed: {stats.get('numberOfNewDocumentsIndexed', 0)} | "
          f"Failed: {stats.get('numberOfDocumentsFailed', 0)}")

    if status == "COMPLETE":
        print("Ingestion complete!")
        break
    elif status in ("FAILED", "STOPPED"):
        print(f"Ingestion {status}: {job.get('failureReasons', [])}")
        break

    time.sleep(30)
                

Abbildung und Codebeispiele für die API-Migration

Zuordnung von API-Vorgängen

Migration der Retrieve-API

Vorher (Kendra):

kendra_client = boto3.client("kendra")

response = kendra_client.retrieve(
    IndexId="your-kendra-index-id",
    QueryText="How do I configure VPC endpoints?",
    AttributeFilter={
        "EqualsTo": {
            "Key": "_category",
            "Value": {"StringValue": "networking"}
        }
    },
    PageSize=10
)

for item in response["ResultItems"]:
    print(item["DocumentTitle"])
    print(item["Content"])
            

Nachher (BMKB):

bedrock_runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

response = bedrock_runtime.retrieve(
    knowledgeBaseId="your-kb-id",
    retrievalQuery={
        "text": "How do I configure VPC endpoints?"
    },
    retrievalConfiguration={
        "managedSearchConfiguration": {
            "numberOfResults": 10,
            "filter": {
                "equals": {
                    "key": "category",
                    "value": "networking"
                }
            }
        }
    }
)

for result in response["retrievalResults"]:
    print(f"Score: {result['score']}")
    print(f"Content: {result['content']['text']}")
    print(f"Source: {result['location']['s3Location']['uri']}")
            

Die wichtigsten Unterschiede sind: Der Abfragetext wechselt von einem Parameter der obersten Ebene in ein verschachteltes Query.text Abruffeld, AttributeFilter wird innerhalb von managed SearchConfiguration zu einem Filter und die Ergebnisse enthalten ein Feld für die Relevanzbewertung.

Für RAG verwenden RetrieveAndGenerate

BMKB bietet eine native RAG-Funktion, die es überflüssig macht, ein LLM nach dem Abrufen separat aufzurufen:

response = bedrock_runtime.retrieve_and_generate(
    input={
        "text": "Explain how to configure VPC endpoints for S3 access"
    },
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "your-kb-id",
            "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0",
            "retrievalConfiguration": {
                "managedSearchConfiguration": {
                    "numberOfResults": 5
                }
            }
        }
    }
)

# Generated answer with citations
print(response["output"]["text"])

# Source citations
for citation in response.get("citations", []):
    for ref in citation.get("retrievedReferences", []):
        print(f"Source: {ref['location']['s3Location']['uri']}")
            

Diese API gibt eine generierte Antwort in natürlicher Sprache zusammen mit Zitaten zurück, die auf die Quelldokumente verweisen, und bietet ein integriertes RAG, das Kendra nicht von Haus aus anbietet.

Syntax, Übersetzung des Metadatenfilters

Funktionslücken und Problemumgehungen

Nicht alle Kendra-Funktionen sind in BMKB verfügbar. Abfragevorschläge, Facettensuche, benutzerdefinierte Synonyme, Rechtschreibprüfung, inkrementelles Lernen und Dokumentanreicherung sind Funktionen, für die in BMKB Umgehungsmöglichkeiten erforderlich sind. In diesem Abschnitt werden diese Problemumgehungen beschrieben.

Strategie zur Migration von Datenquellen

Lücke bei der Netzabdeckung

Kendra unterstützt 32 native Konnektoren, während BMKB 7 unterstützt. Für Datenquellen, die nicht direkt von BMKB unterstützt werden, wird empfohlen, Inhalte nach Amazon S3 zu exportieren und eine S3-Datenquelle in BMKB zu konfigurieren.

Migrationsmuster für nicht unterstützte Konnektoren: Erstellen Sie eine automatisierte Pipeline (mithilfe von AWS Lambda, Step Functions oder Amazon EventBridge Scheduler), die regelmäßig Inhalte aus dem Quellsystem über ihre API extrahiert, Dokumente mit den entsprechenden Metadaten-JSON-Sidecar-Dateien in einen S3-Bucket schreibt und einen BMKB-Aufnahmejob auslöst. Dies repliziert das regelmäßige Synchronisierungsverhalten von Kendra-Konnektoren.

Migration von Metadaten

Kendra-Dokumentattribute müssen in das BMKB-Metadatenformat übersetzt werden. In Kendra werden Attribute auf Indexebene definiert und während der Aufnahme an Dokumente angehängt. In BMKB werden Metadaten über .metadata.json-Sidecar-Dateien definiert, die zusammen mit Quelldokumenten in S3 gespeichert werden, mit einer maximalen Größe von 10 KB pro Datei. Jedes Attribut muss als STRING, NUMBER oder BOOLEAN eingegeben werden.

Auswahl der Chunking-Strategie

Bei der Migration von Kendra (das das Chunking intern abwickelt) müssen Sie explizit eine Chunking-Strategie für BMKB wählen. Für die meisten Migrationsszenarien bietet die Fixed-size Strategie mit 200 Tokens und einer Überlappung von 30% einen guten Ausgangspunkt. Wenn Ihre Dokumente eine klare hierarchische Struktur haben (Kapitel, Abschnitte, Unterabschnitte), sollten Sie eine hierarchische Aufteilung in Betracht ziehen, um sowohl den allgemeinen Kontext als auch spezifische Details besser abrufen zu können.

Testen und Validieren

Führen Sie Kendra und BMKB parallel aus, um die Leistung zu bewerten. Senden Sie identische Abfragen an beide Dienste und vergleichen Sie die Ergebnisse anhand der folgenden Dimensionen: Relevanzqualität (gemessen durch NDCG oder MRR anhand eines Goldenen Testsatzes), Latenz (Antwortzeiten von p50, p95, p99), Durchsatz (Abfragen pro Sekunde unter Last) und Vollständigkeit (Prozentsatz der erwarteten abgerufenen Dokumente).

Erstellen Sie ein Testsystem, das die Abrufqualität bewertet:

def compare_retrieval(query, kendra_index_id, bmkb_kb_id):
    # Query Kendra
    kendra_results = kendra_client.retrieve(
        IndexId=kendra_index_id,
        QueryText=query,
        PageSize=10
    )

    # Query BMKB
    bmkb_results = bedrock_runtime.retrieve(
        knowledgeBaseId=bmkb_kb_id,
        retrievalQuery={"text": query},
        retrievalConfiguration={
            "managedSearchConfiguration": {"numberOfResults": 10}
        }
    )

    # Compare overlap in top-10 results
    kendra_docs = {r["DocumentId"] for r in kendra_results["ResultItems"]}
    bmkb_docs = {r["location"]["s3Location"]["uri"] for r in bmkb_results["retrievalResults"]}

    overlap = len(kendra_docs.intersection(bmkb_docs))
    print(f"Query: {query}")
    print(f"Result overlap: {overlap}/10 documents in common")
    return overlap
        

Bevor Sie den Produktionsdatenverkehr auf BMKB umstellen, stellen Sie Folgendes sicher: Alle Datenquellen sind aufgenommen und aktuell und es gibt keine fehlerhaften Dokumente; Metadatenfilter liefern die erwarteten Ergebnisse für alle Anwendungsfiltermuster; Problemumgehungen bei der Zugriffskontrolle schränken den unbefugten Zugriff korrekt ein; Relevanz-Benchmarks erfüllen oder übertreffen die Kendra-Grundqualität; bei der Anwendungsfehlerbehandlung werden BMKB-Antwortformate korrekt verarbeitet und Überwachung und Warnmeldungen sind für BMKB-API-Fehler und Latenz konfiguriert.

Zusammenfassung

Die Migration von Amazon Kendra der Bedrock Managed Knowledge Base erfordert im Wesentlichen zwei Schritte: das erneute Aufnehmen von Datenquellen in BMKB und das Umschreiben des Anwendungscodes zur Verwendung von BMKB-APIs. BMKB bietet zwar leistungsstarke RAG-native Funktionen wie RetrieveAndGenerate Agentenabruf, aber Kunden, die unternehmensweite Suchfunktionen wie Facettierung, Abfragevorschläge, benutzerdefinierte Synonyme und inkrementelles Lernen verwenden, müssen die in diesem Handbuch beschriebenen Problemumgehungen implementieren.

Bei weiteren Fragen wenden Sie sich bitte an den Support. AWS