Amazon Kendra non è più aperto a nuovi clienti. Per funzionalità simili a Amazon Kendra, esplora le Knowledge Bases di Amazon Bedrock. 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 sono state sviluppate nuove funzionalità o capacità per il servizio e, a partire dal 30 luglio 2026, il servizio non è più aperto a nuovi clienti.

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

Consigliamo ai clienti di migrare le loro applicazioni Kendra e di implementare qualsiasi nuova applicazione di ricerca su Amazon Bedrock Managed Knowledge Base (BMKB) per funzionalità simili a Kendra e funzionalità più avanzate per casi d'uso dell'IA generativa e dell'IA 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 offre anche la possibilità di modificare le strategie di chunking e i modelli di incorporamento per ottimizzarli per la tua applicazione specifica, nonché di scegliere il modello di base per la generazione di risposte. Questo nuovo livello di funzionalità e flessibilità comporta costi prevedibili in base alle dimensioni della knowledge base acquisita, al numero di query eseguite e all'utilizzo dell'LLM.

Guida alla migrazione

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

Funzionalità 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 Aurora o altri database vettoriali. OpenSearch Le strategie di suddivisione in blocchi includono Default (dimensione fissa a 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.

BMKB attualmente supporta sette connettori per 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 da Amazon Bedrock

Fase 1: Configurazione dei ruoli IAM

Crea un ruolo IAM che conceda a Bedrock l'autorizzazione ad accedere alle tue fonti di dati e richiamare i modelli di incorporamento. La politica di fiducia deve consentire a bedrock.amazonaws.com di assumere il ruolo e la politica delle autorizzazioni 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

Usa 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 sondaggio per il completamento:

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 per il SearchConfiguration punteggio di pertinenza.

Utilizzo per RAG RetrieveAndGenerate

BMKB fornisce 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 in modo nativo.

Traduzione della sintassi del filtro dei metadati

Lacune nelle funzionalità e soluzioni alternative

Non tutte le funzionalità di Kendra sono disponibili in BMKB. Suggerimenti di interrogazione, ricerca sfaccettata, sinonimi personalizzati, controllo ortografico, apprendimento incrementale e arricchimento dei documenti sono funzionalità che richiedono soluzioni alternative in BMKB. Questa sezione illustra queste soluzioni alternative.

Strategia di migrazione all'origine dei dati

Divario di copertura dei connettori

Kendra supporta 32 connettori nativi mentre BMKB ne supporta 7. Per le fonti di dati non direttamente supportate 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 il contenuto dal sistema di origine tramite la sua API, scrive documenti in un bucket S3 con file sidecar JSON di metadati appropriati e attiva un processo di inserimento BMKB. Questo replica il comportamento di sincronizzazione periodica dei connettori Kendra.

Migrazione dei metadati

Gli attributi dei documenti 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'inserimento. In BMKB, i metadati sono definiti tramite file sidecar .metadata.json archiviati insieme ai documenti di origine 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 suddivisione in blocchi

Quando si esegue la migrazione da Kendra (che gestisce il chunking internamente), è necessario 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% fornisce un buon punto di partenza. Se i tuoi documenti hanno una struttura gerarchica chiara (capitoli, sezioni, sottosezioni), prendi in considerazione la suddivisione gerarchica per recuperare meglio sia il contesto generale che i dettagli specifici.

Test e convalida

Per valutare le prestazioni, esegui Kendra e BMKB in parallelo. Invia domande identiche a entrambi i servizi e confronta i risultati utilizzando le seguenti dimensioni: qualità della pertinenza (misurata mediante NDCG o MRR rispetto a un set di test d'oro), latenza (tempi di risposta p50, p95, p99), produttività (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 su BMKB, verifica quanto segue: tutte le fonti di dati sono inserite e aggiornate senza documenti errati; i filtri dei metadati producono i risultati previsti 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 errori e latenza delle API BMKB.

Riepilogo

La migrazione da Amazon Kendra a 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 aziendale come faceting, suggerimenti di query, sinonimi personalizzati RetrieveAndGenerate e apprendimento incrementale dovranno implementare soluzioni alternative come descritto in questa guida.

AWSContatta l'assistenza per qualsiasi domanda aggiuntiva.