Amazon Kendra ne sera plus ouvert aux nouveaux clients à compter du 30 juillet 2026. Si vous souhaitez utiliser le service, veuillez vous inscrire avant le 30 juillet. Pour des fonctionnalités similaires à Amazon Kendra, explorez les bases de connaissances Amazon Bedrock. En savoir plus.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Amazon Kendra changement de disponibilité

Présentation de

Après mûre réflexion, nous avons pris la décision de passer Amazon Kendra en mode maintenance, à compter du 30 juin 2026. À cette date, aucune nouvelle fonctionnalité ou capacité ne sera développée pour le service, et à compter du 30 juillet 2026, le service cessera d'accepter de nouveaux clients.

Pendant le mode maintenance, le service reste entièrement pris en charge et AWS continuera à fournir des corrections de bogues et des mises à jour de sécurité aux clients existants, mais les demandes de nouvelles fonctionnalités ne seront plus prises en compte.

Nous recommandons aux clients de migrer leurs applications Kendra et d'implémenter toute nouvelle application de recherche sur Amazon Bedrock Managed Knowledge Base (BMKB) afin d'obtenir des fonctionnalités similaires à celles de Kendra et des fonctionnalités plus avancées pour les cas d'utilisation de l'IA générative et de l'IA agentique. Bedrock Managed Knowledge Base est une solution RAG entièrement gérée, dotée de connecteurs intégrés, d'une analyse intelligente, d'un magasin vectoriel géré avec recherche hybride, ainsi que de la possibilité de générer des réponses (avec une API de récupération et de génération) et d'effectuer un raisonnement en plusieurs étapes sur plusieurs bases de connaissances (avec une API de récupération agentic). Le BMKB vous permet également d'ajuster les stratégies de segmentation et d'intégration des modèles afin de les optimiser pour votre application spécifique, ainsi que de choisir le modèle de base pour la génération de réponses. Ce nouveau niveau de fonctionnalités et de flexibilité s'accompagne de coûts prévisibles basés sur la taille de la base de connaissances ingérée, le nombre de requêtes effectuées et l'utilisation du LLM.

Conseils de migration

La migration depuis Amazon Kendra Amazon Bedrock Managed Knowledge Base (BMKB) est réalisable pour la plupart des charges de travail de recherche et RAG d'entreprise, moyennant une planification minutieuse. Toutes les fonctionnalités de Kendra ne sont pas directement disponibles dans la base de connaissances gérée de Bedrock, mais bon nombre d'entre elles peuvent être mises en œuvre grâce à des solutions de contournement. Ce guide fournit un processus de migration complet, étape par étape, permettant aux clients existants de Kendra de faire migrer leurs applications vers BMKB, y compris le mappage de l'architecture, la traduction d'API, des exemples de code, une analyse des lacunes en matière de fonctionnalités et des solutions de contournement recommandées.

Fonctionnalités de la base de connaissances gérée Amazon Bedrock

BMKB gère l'ensemble du pipeline RAG de bout en bout. Il prend en charge des modèles d'intégration tels qu'Amazon Titan Text Embeddings V2, Cohere Embed English v3, Cohere Embed Multilingual v3, Cohere Embed v4 et Amazon Nova Multimodal Embeddings, tous fixés à 1024 dimensions avec des vecteurs float32. Le magasin vectoriel géré est entièrement géré par Bedrock, ce qui élimine le besoin de provisionner ou de gérer OpenSearch Aurora ou d'autres bases de données vectorielles. Les stratégies de segmentation incluent Default (taille fixe à environ 300 jetons), (MaxTokens et OverlapPercentage configurables), Hierarchical Fixed-size (parent-enfant avec configurations de niveau) et No Chunking ; le découpage sémantique n'est pas pris en charge pour les bases de connaissances gérées.

BMKB prend actuellement en charge sept connecteurs de source de données : Amazon S3, Confluence SharePoint, Microsoft, Web Crawler, Google Drive OneDrive, Microsoft et un connecteur personnalisé. Le service effectue toujours une recherche hybride (mot clé plus sémantique) et ne propose pas de mode de recherche uniquement sémantique.

Etapes de la migration

Configuration de la base de connaissances gérée Amazon Bedrock

Étape 1 : Configuration des rôles IAM

Créez un rôle IAM qui autorise Bedrock à accéder à vos sources de données et à invoquer des modèles d'intégration. La politique de confiance doit autoriser bedrock.amazonaws.com à assumer le rôle, et la politique d'autorisation doit inclure l'accès à vos compartiments S3 et au modèle d'intégration sélectionné.

Configuration IAM (code 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)
)
                

Étape 2 : Création d'une base de connaissances gérée

Utilisez l' CreateKnowledgeBase API de type MANAGED pour créer la base de connaissances :

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

Étape 3 : Configuration des sources de données

Créez une source de données S3 avec la configuration du connecteur géré :

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

Étape 4 : démarrer et surveiller l'ingestion

Déclenchez l'ingestion du document et interrogez-le pour le terminer :

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)
                

Cartographie de migration d'API et exemples de code

Cartographie des opérations d'API

Migration de l'API Retrieve

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

Après (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']}")
            

Les principales différences sont les suivantes : le texte de la requête passe d'un paramètre de haut niveau à un Query.text champ de récupération imbriqué ; AttributeFilter il devient filtré dans le cadre de la commande managé SearchConfiguration ; et les résultats incluent un champ de score de pertinence.

Utilisation RetrieveAndGenerate pour RAG

Le BMKB fournit une fonctionnalité RAG native qui élimine le besoin d'appeler séparément un LLM après la récupération :

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

Cette API renvoie une réponse en langage naturel générée ainsi que des citations pointant vers les documents sources, fournissant ainsi un RAG intégré que Kendra ne propose pas de manière native.

Traduction de la syntaxe du filtre de métadonnées

Lacunes dans les fonctionnalités et solutions

Toutes les fonctionnalités de Kendra ne sont pas disponibles dans BMKB. Les suggestions de requêtes, la recherche à facettes, les synonymes personnalisés, la vérification orthographique, l'apprentissage progressif et l'enrichissement des documents sont des fonctionnalités qui nécessitent des solutions de contournement dans BMKB. Cette section décrit ces solutions de contournement.

Stratégie de migration des sources de données

Écart de couverture du connecteur

Kendra supporte 32 connecteurs natifs tandis que BMKB en supporte 7. Pour les sources de données qui ne sont pas directement prises en charge par BMKB, l'approche recommandée consiste à exporter le contenu vers Amazon S3 et à configurer une source de données S3 dans BMKB.

Modèle de migration pour les connecteurs non pris en charge : créez un pipeline automatique (à l'aide de AWS Lambda, Step Functions ou EventBridge Amazon Scheduler) qui extrait régulièrement le contenu du système source via son API, écrit des documents dans un compartiment S3 avec des fichiers annexes JSON de métadonnées appropriés et déclenche une tâche d'ingestion BMKB. Cela reproduit le comportement de synchronisation périodique des connecteurs Kendra.

Migration des métadonnées

Les attributs du document Kendra doivent être traduits au format de métadonnées BMKB. Dans Kendra, les attributs sont définis au niveau de l'index et attachés aux documents lors de l'ingestion. Dans BMKB, les métadonnées sont définies via des fichiers annexes .metadata.json stockés avec les documents sources dans S3, avec une taille maximale de 10 Ko par fichier. Chaque attribut doit être saisi sous la forme STRING, NUMBER ou BOOLEAN.

Sélection de la stratégie de segmentation

Lorsque vous migrez depuis Kendra (qui gère le découpage en interne), vous devez choisir explicitement une stratégie de segmentation pour BMKB. Pour la plupart des scénarios de migration, la Fixed-size stratégie avec 200 jetons et 30 % de chevauchement constitue un bon point de départ. Si vos documents ont une structure hiérarchique claire (chapitres, sections, sous-sections), envisagez le découpage hiérarchique pour une meilleure récupération du contexte général et des détails spécifiques.

Tests et validation

Pour évaluer les performances, exécutez Kendra et BMKB en parallèle. Envoyez des requêtes identiques aux deux services et comparez les résultats en utilisant les dimensions suivantes : qualité de pertinence (mesurée par le NDCG ou MRR par rapport à un ensemble de tests de référence), latence (temps de réponse p50, p95, p99), débit (requêtes par seconde sous charge) et exhaustivité (pourcentage de documents attendus récupérés).

Créez un harnais de test qui évalue la qualité de l'extraction :

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
        

Avant de transférer le trafic de production vers BMKB, vérifiez les points suivants : toutes les sources de données sont ingérées et mises à jour sans aucun document défaillant ; les filtres de métadonnées produisent les résultats attendus pour tous les modèles de filtres d'applications ; les solutions de contrôle d'accès limitent correctement les accès non autorisés ; les critères de pertinence atteignent ou dépassent la qualité de référence de Kendra ; la gestion des erreurs d'application traite correctement les formats de réponse BMKB ; et la surveillance et les alertes sont configurées pour les erreurs et la latence des API BMKB.

Résumé

La migration depuis Amazon Kendra Bedrock Managed Knowledge Base nécessite deux efforts principaux : réingérer les sources de données dans BMKB et réécrire le code de l'application pour utiliser les API BMKB. Bien que BMKB intègre de puissantes RAG-native fonctionnalités, notamment RetrieveAndGenerate la récupération agentique, les clients utilisant des fonctionnalités de recherche d'entreprise telles que le facettage, les suggestions de requêtes, les synonymes personnalisés et l'apprentissage progressif devront mettre en œuvre des solutions de contournement décrites dans ce guide.

Veuillez contacter AWS le Support pour toute question supplémentaire.