Amazon Kendra non sarà più aperto a nuovi clienti a partire dal 30 luglio 2026. Se desideri utilizzare il servizio, registrati prima del 30 luglio. Per funzionalità simili a Amazon Kendra, esplora Amazon Bedrock Knowledge Bases. Ulteriori informazioni.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Amazon Kendra modifica della disponibilità

Panoramica di

Dopo un'attenta valutazione, abbiamo deciso di attivare la modalità di Amazon Kendra manutenzione, a partire dal 30 giugno 2026. A partire da questa data, non ci saranno nuove funzionalità o funzionalità per il servizio e, a partire dal 30 luglio 2026, il servizio smetterà di accettare nuovi clienti.

Durante la modalità di manutenzione, il servizio rimane pienamente supportato e AWS continuerà a fornire correzioni di bug e aggiornamenti di sicurezza per i clienti esistenti, tuttavia non verranno più prese in considerazione le nuove richieste di funzionalità.

Consigliamo ai clienti di migrare le proprie applicazioni Kendra e di implementare nuove applicazioni di ricerca su Amazon Bedrock Managed Knowledge Base (BMKB) per funzionalità simili a Kendra e funzionalità più avanzate per casi d'uso di intelligenza artificiale generativa e intelligenza artificiale agentica. Bedrock Managed Knowledge Base è una soluzione RAG completamente gestita, con connettori integrati, analisi intelligente, archivio vettoriale gestito con ricerca ibrida, oltre alla capacità di generare risposte (con un'API Retrieve and Generate) ed eseguire ragionamenti in più fasi su più basi di conoscenza (con un'API Agentic Retrieval). BMKB ti dà anche la possibilità di adattare le strategie di chunking e i modelli di incorporamento per ottimizzarli per la tua applicazione specifica, nonché di scegliere il modello base per la generazione di risposte. Questo nuovo livello di funzionalità e flessibilità comporta costi prevedibili in base alla dimensione della base di conoscenza acquisita, al numero di query eseguite e all'utilizzo del LLM.

Guida alla migrazione

La migrazione Amazon Kendra da Amazon Bedrock Managed Knowledge Base (BMKB) è possibile per la maggior parte dei carichi di lavoro RAG e di ricerca aziendali con un'attenta pianificazione. Non tutte le funzionalità di Kendra sono disponibili direttamente nella Bedrock Managed Knowledge Base, ma molte possono essere implementate tramite soluzioni alternative. Questa guida fornisce un percorso di migrazione completo e dettagliato per i clienti Kendra esistenti per la transizione delle loro applicazioni a BMKB, tra cui mappatura dell'architettura, traduzione delle API, esempi di codice, analisi delle lacune di funzionalità e soluzioni alternative consigliate.

Caratteristiche della Knowledge Base gestita di Amazon Bedrock

BMKB gestisce l'intera pipeline RAG dall'inizio alla fine. Supporta modelli di incorporamento tra cui Amazon Titan Text Embeddings V2, Cohere Embed English v3, Cohere Embed Multilingual v3, Cohere Embed v4 e Amazon Nova Multimodal Embeddings, tutti fissati a 1024 dimensioni con vettori float32. L'archivio vettoriale gestito è completamente gestito da Bedrock, eliminando la necessità di fornire o gestire OpenSearch Aurora o altri database vettoriali. Le strategie di suddivisione in blocchi includono Default (dimensione fissa con circa 300 token), (MaxTokens e OverlapPercentage configurabili), Hierarchical Fixed-size (padre-figlio con configurazioni di livello) e No Chunking; il chunking semantico non è supportato per le knowledge base gestite.

Attualmente BMKB supporta sette connettori di sorgenti dati: Amazon S3, Confluence, SharePoint Microsoft, Web Crawler, Google Drive OneDrive, Microsoft e un connettore personalizzato. Il servizio esegue sempre una ricerca ibrida (parola chiave più semantica) e non offre una modalità di ricerca solo semantica.

Fasi della migrazione

Configurazione della Knowledge Base gestita di Amazon Bedrock

Fase 1: configurare i ruoli IAM

Crea un ruolo IAM che conceda a Bedrock l'autorizzazione ad accedere alle tue fonti di dati e richiamare modelli di incorporamento. La politica di fiducia deve consentire a bedrock.amazonaws.com di assumere il ruolo e la politica di autorizzazione deve includere l'accesso ai bucket S3 e al modello di incorporamento selezionato.

Configurazione IAM (codice Python):

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)
)
                

Fase 2: Creare una Knowledge Base gestita

Utilizza l' CreateKnowledgeBase API di tipo MANAGED per creare la knowledge base:

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}")
                

Fase 3: Configurazione delle fonti di dati

Crea un'origine dati S3 con la configurazione del connettore gestito:

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}")
                

Fase 4: Avvio e monitoraggio dell'ingestione

Attiva l'inserimento dei documenti e il completamento del sondaggio:

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)
                

Mappatura della migrazione delle API ed esempi di codice

Mappatura delle operazioni delle API

Migrazione dell'API Retrieve

Prima (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"])
            

Dopo (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']}")
            

Le differenze principali sono: il testo della query passa da un parametro di primo livello a un campo di recupero annidato, AttributeFilter diventa filtro all'interno di managed e i risultati includono un Query.text campo di SearchConfiguration punteggio di pertinenza.

Utilizzo per RAG RetrieveAndGenerate

BMKB offre una funzionalità RAG nativa che elimina la necessità di chiamare separatamente un LLM dopo il recupero:

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']}")
            

Questa API restituisce una risposta generata in linguaggio naturale insieme a citazioni che rimandano ai documenti di origine, fornendo un RAG integrato che Kendra non offre nativamente.

Traduzione della sintassi del filtro dei metadati

Lacune nelle funzionalità e soluzioni alternative

Non tutte le funzionalità di Kendra sono disponibili in BMKB. I suggerimenti di interrogazione, la ricerca sfaccettata, i sinonimi personalizzati, il controllo ortografico, l'apprendimento incrementale e l'arricchimento dei documenti sono funzionalità che richiedono soluzioni alternative in BMKB. In questa sezione vengono illustrate queste soluzioni alternative.

Strategia di migrazione delle fonti di dati

Gap di copertura del connettore

Kendra supporta 32 connettori nativi mentre BMKB ne supporta 7. Per le fonti di dati non supportate direttamente da BMKB, l'approccio consigliato consiste nell'esportare contenuti in Amazon S3 e configurare un'origine dati S3 in BMKB.

Modello di migrazione per connettori non supportati: crea una pipeline automatizzata (utilizzando AWS Lambda, Step Functions o Amazon EventBridge Scheduler) che estrae periodicamente i contenuti dal sistema di origine tramite la relativa API, scrive documenti in un bucket S3 con file collaterali JSON di metadati appropriati e attiva un processo di ingestione BMKB. Questo replica il comportamento di sincronizzazione periodica dei connettori Kendra.

Migrazione dei metadati

Gli attributi del documento Kendra devono essere tradotti nel formato di metadati BMKB. In Kendra, gli attributi sono definiti a livello di indice e allegati ai documenti durante l'ingestione. In BMKB, i metadati sono definiti tramite file sidecar .metadata.json archiviati insieme ai documenti sorgente in S3, con una dimensione massima di 10 KB per file. Ogni attributo deve essere digitato come STRING, NUMBER o BOOLEAN.

Selezione della strategia di Chunking

Quando esegui la migrazione da Kendra (che gestisce la suddivisione in blocchi internamente), devi scegliere esplicitamente una strategia di suddivisione in blocchi per BMKB. Per la maggior parte degli scenari di migrazione, la Fixed-size strategia con 200 token e una sovrapposizione del 30% offre un buon punto di partenza. Se i documenti hanno una struttura gerarchica chiara (capitoli, sezioni, sottosezioni), prendi in considerazione la suddivisione in blocchi gerarchici per recuperare meglio sia il contesto generale che i dettagli specifici.

Test e convalida

Per valutare le prestazioni, esegui sia Kendra che BMKB in parallelo. Invia query identiche a entrambi i servizi e confronta i risultati utilizzando le seguenti dimensioni: qualità della pertinenza (misurata con NDCG o MRR rispetto a un set di test standard), latenza (tempi di risposta p50, p95, p99), velocità effettiva (query al secondo sotto carico) e completezza (percentuale di documenti previsti recuperati).

Crea un test harness che valuti la qualità del recupero:

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
        

Prima di trasferire il traffico di produzione a BMKB, verifica quanto segue: tutte le fonti di dati siano state inserite e aggiornate senza documenti falliti; i filtri dei metadati producono i risultati attesi per tutti i modelli di filtro delle applicazioni; le soluzioni alternative per il controllo degli accessi limitano correttamente gli accessi non autorizzati; i benchmark di pertinenza soddisfano o superano la qualità di base di Kendra; la gestione degli errori delle applicazioni elabora correttamente i formati di risposta BMKB; e il monitoraggio e gli avvisi sono configurati per gli errori e la latenza delle API BMKB.

Riepilogo

La migrazione Amazon Kendra da Bedrock Managed Knowledge Base richiede due sforzi principali: reinserire le fonti di dati in BMKB e riscrivere il codice dell'applicazione per utilizzare le API BMKB. Sebbene BMKB introduca potenti RAG-native funzionalità, tra cui il recupero tramite agenti, i clienti che utilizzano funzionalità di ricerca aziendali come faceting, suggerimenti di query, sinonimi personalizzati RetrieveAndGenerate e apprendimento incrementale, dovranno implementare soluzioni alternative come descritto in questa guida.

Contatta l'AWS assistenza per qualsiasi altra domanda.