Amazon Kendra não estará mais aberto a novos clientes a partir de 30 de julho de 2026. Se você quiser usar o serviço, inscreva-se antes de 30 de julho. Para recursos semelhantes a Amazon Kendra, explore as bases de conhecimento do Amazon Bedrock. Saiba mais.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Amazon Kendra Mudança de disponibilidade do

Visão geral do

Após uma análise cuidadosa, tomamos a decisão de Amazon Kendra entrar no Modo de Manutenção, a partir de 30 de junho de 2026. A partir dessa data, não haverá desenvolvimento de novos recursos ou capacidades para o serviço e, a partir de 30 de julho de 2026, o serviço deixará de aceitar novos clientes.

Durante o Modo de Manutenção, o serviço permanece totalmente suportado e AWS continuará fornecendo correções de erros e atualizações de segurança para clientes existentes, no entanto, as solicitações de novos recursos não serão mais consideradas.

Recomendamos que os clientes migrem seus aplicativos Kendra e implementem quaisquer novos aplicativos de pesquisa na Amazon Bedrock Managed Knowledge Base (BMKB) para obter recursos semelhantes aos do Kendra e recursos mais avançados para casos de uso de IA generativa e IA agente. O Bedrock Managed Knowledge Base é uma solução RAG totalmente gerenciada, com conectores integrados, análise inteligente, armazenamento vetorial gerenciado com pesquisa híbrida, além da capacidade de gerar respostas (com uma API de recuperação e geração) e raciocinar em várias etapas em várias bases de conhecimento (com uma API de recuperação agente). O BMKB também oferece a capacidade de ajustar as estratégias de agrupamento e os modelos de incorporação para otimizar sua aplicação específica, bem como escolher o modelo básico para geração de resposta. Esse novo nível de recursos e flexibilidade vem com custos previsíveis com base no tamanho da base de conhecimento ingerida, no número de consultas realizadas e no uso do LLM.

Orientação de migração

A migração do Amazon Kendra Amazon Bedrock Managed Knowledge Base (BMKB) é possível para a maioria das cargas de trabalho de pesquisa corporativa e RAG com um planejamento cuidadoso. Nem todos os recursos do Kendra estão diretamente disponíveis na Base de Conhecimento Gerenciada da Bedrock, mas muitos podem ser implementados por meio de soluções alternativas. Este guia fornece um caminho de migração abrangente e passo a passo para que os clientes atuais da Kendra façam a transição de seus aplicativos para o BMKB, incluindo mapeamento de arquitetura, tradução de API, exemplos de código, análise de lacunas de recursos e soluções alternativas recomendadas.

Características da base de conhecimento gerenciada Amazon Bedrock

O BMKB gerencia todo o pipeline RAG de ponta a ponta. Ele suporta modelos de incorporação, incluindo Amazon Titan Text Embeddings V2, Cohere Embed English v3, Cohere Embed Multilingual v3, Cohere Embed v4 e Amazon Nova Multimodal Embeddings, todos fixados em 1024 dimensões com vetores float32. O armazenamento vetorial gerenciado é totalmente operado pela Bedrock, eliminando a necessidade de provisionar ou gerenciar OpenSearch o Aurora ou outros bancos de dados vetoriais. As estratégias de agrupamento incluem Padrão (tamanho fixo de aproximadamente 300 tokens), (MaxTokens e Fixed-size OverlapPercentage configuráveis), Hierárquica (pai-filho com configurações de nível) e Sem fragmentação; a fragmentação semântica não é suportada em bases de conhecimento gerenciadas.

Atualmente, o BMKB suporta sete conectores de fonte de dados: Amazon S3, Confluence, Microsoft, Web Crawler, Google Drive, SharePoint OneDrive Microsoft e um conector personalizado. O serviço sempre realiza uma pesquisa híbrida (palavra-chave mais semântica) e não oferece o modo de pesquisa somente semântica.

Etapas da migração

Configuração da base de conhecimento gerenciada Amazon Bedrock

Etapa 1: configurar as funções do IAM

Crie uma função do IAM que conceda à Bedrock permissão para acessar suas fontes de dados e invocar modelos de incorporação. A política de confiança deve permitir que bedrock.amazonaws.com assuma a função, e a política de permissões deve incluir acesso aos seus buckets do S3 e ao modelo de incorporação selecionado.

Configuração do IAM (código 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)
)
                

Etapa 2: criar uma base de conhecimento gerenciada

Use a CreateKnowledgeBase API com o tipo MANAGED para criar a base de conhecimento:

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

Etapa 3: Configurar fontes de dados

Crie uma fonte de dados S3 com a configuração do conector gerenciado:

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

Etapa 4: iniciar e monitorar a ingestão

Acione a ingestão de documentos e a pesquisa para conclusão:

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)
                

Mapeamento de migração de API e exemplos de código

Mapeamento da operação da API

Migração da API Retrieve

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

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

As principais diferenças são: o texto da consulta passa de um parâmetro de nível superior para um Query.text campo de recuperação aninhado; AttributeFilter torna-se filtro dentro do gerenciadoSearchConfiguration; e os resultados incluem um campo de pontuação de relevância.

Usando RetrieveAndGenerate para RAG

O BMKB fornece um recurso RAG nativo que elimina a necessidade de chamar separadamente um LLM após a recuperação:

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

Essa API retorna uma resposta gerada em linguagem natural junto com citações que apontam para os documentos de origem, fornecendo RAG integrado que Kendra não oferece nativamente.

Tradução da sintaxe do filtro de metadados

Lacunas de recursos e soluções alternativas

Nem todos os recursos do Kendra estão disponíveis no BMKB. Sugestões de consulta, pesquisa facetada, sinônimos personalizados, verificação ortográfica, aprendizado incremental e enriquecimento de documentos são recursos que exigem soluções alternativas no BMKB. Esta seção discute essas soluções alternativas.

Estratégia de migração de fontes de dados

Fenda de cobertura do conector

Kendra suporta 32 conectores nativos, enquanto o BMKB suporta 7. Para fontes de dados não suportadas diretamente pelo BMKB, a abordagem recomendada é exportar conteúdo para o Amazon S3 e configurar uma fonte de dados S3 no BMKB.

Padrão de migração para conectores não compatíveis: crie um pipeline automatizado (usando AWS Lambda, Step Functions ou Amazon EventBridge Scheduler) que periodicamente extrai conteúdo do sistema de origem por meio de sua API, grava documentos em um bucket do S3 com arquivos auxiliares JSON de metadados apropriados e aciona um trabalho de ingestão do BMKB. Isso replica o comportamento de sincronização periódica dos conectores Kendra.

Migração de metadados

Os atributos do documento Kendra devem ser traduzidos para o formato de metadados BMKB. No Kendra, os atributos são definidos no nível do índice e anexados aos documentos durante a ingestão. No BMKB, os metadados são definidos por meio de arquivos secundários.metadata.json armazenados junto com os documentos de origem no S3, com um tamanho máximo de 10 KB por arquivo. Cada atributo deve ser digitado como STRING, NUMBER ou BOOLEAN.

Seleção da estratégia de fragmentação

Ao migrar do Kendra (que lida com fragmentação internamente), você deve escolher explicitamente uma estratégia de fragmentação para o BMKB. Para a maioria dos cenários de migração, a Fixed-size estratégia com 200 tokens e 30% de sobreposição fornece um bom ponto de partida. Se seus documentos tiverem uma estrutura hierárquica clara (capítulos, seções, subseções), considere a fragmentação hierárquica para melhorar a recuperação de um contexto amplo e de detalhes específicos.

Teste e validação

Para avaliar o desempenho, execute o Kendra e o BMKB em paralelo. Envie consultas idênticas aos dois serviços e compare os resultados usando as seguintes dimensões: qualidade de relevância (medida pelo NDCG ou MRR em relação a um conjunto de testes dourado), latência (tempos de resposta p50, p95, p99), taxa de transferência (consultas por segundo sob carga) e integridade (porcentagem de documentos esperados recuperados).

Crie um equipamento de teste que avalie a qualidade da recuperação:

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
        

Antes de mudar o tráfego de produção para o BMKB, verifique o seguinte: todas as fontes de dados foram ingeridas e atualizadas sem falhas nos documentos; os filtros de metadados produzem os resultados esperados para todos os padrões de filtro do aplicativo; as soluções alternativas de controle de acesso restringem corretamente o acesso não autorizado; os benchmarks de relevância atendem ou excedem a qualidade básica de Kendra; o tratamento de erros do aplicativo processa corretamente os formatos de resposta do BMKB; e o monitoramento e os alertas estão configurados para erros e latência da API do BMKB.

Resumo

A migração da Base de Amazon Kendra Conhecimento Gerenciada da Bedrock exige dois esforços principais: reingerir fontes de dados no BMKB e reescrever o código do aplicativo para usar as APIs do BMKB. Embora o BMKB introduza RAG-native recursos poderosos, incluindo RetrieveAndGenerate recuperação agente, os clientes que usam recursos de pesquisa corporativa, como facetagem, sugestões de consulta, sinônimos personalizados e aprendizado incremental, precisarão implementar soluções alternativas conforme descrito neste guia.

Entre em contato com AWS o Support em caso de dúvidas adicionais.