Amazon Kendra não está mais aberto a novos clientes. Para obter recursos semelhantes a Amazon Kendra, explore as bases de conhecimento da 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 há desenvolvimento de novos recursos ou capacidades para o serviço e, a partir de 30 de julho de 2026, o serviço não está mais aberto a 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 os 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 Base de Conhecimento Gerenciada do Amazon Bedrock (BMKB) para obter recursos semelhantes aos do Kendra e recursos mais avançados para casos de uso de IA generativa e IA agente. A 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 de agentes). O BMKB também oferece a capacidade de ajustar as estratégias de fragmentação e os modelos de incorporação para otimizar sua aplicação específica, bem como escolher o modelo básico para geração de respostas. 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 Amazon Kendra para a Base de Conhecimento Gerenciada do Amazon Bedrock (BMKB) é possível para a maioria das cargas de trabalho corporativas de pesquisa e RAG com um planejamento cuidadoso. Nem todos os recursos do Kendra estão diretamente disponíveis na Bedrock Managed Knowledge Base, mas muitos podem ser implementados por meio de soluções alternativas. Este guia fornece um caminho de migração abrangente e detalhado para que os clientes existentes 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.

Recursos 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 fragmentação incluem Default (tamanho fixo em aproximadamente 300 tokens), Fixed-size (maxTokens e overlapPercentage configuráveis), Hierárquico (pai-filho com configurações de nível) e Sem fragmentação; a fragmentação semântica não é suportada por bases de conhecimento gerenciadas.

Atualmente, o BMKB oferece suporte a sete conectores de fonte de dados: Amazon S3, Confluence, Microsoft SharePoint, Web Crawler, Google Drive, Microsoft OneDrive 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 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 do S3 com a configuração gerenciada do conector:

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 enquete 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 de operações de API

Migrando a 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 campo de recuperação aninhado; AttributeFilter se torna filtro dentro do gerenciadoSearchConfiguration; e os resultados incluem um Query.text 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 apontando para os documentos de origem, fornecendo RAG integrado que o 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 aborda essas soluções alternativas.

Estratégia de migração da fonte de dados

Falha na cobertura do conector

O 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 do S3 no BMKB.

Padrão de migração para conectores não suportados: crie um pipeline automatizado (usando AWS Lambda, Step Functions ou Amazon EventBridge Scheduler) que periodicamente extraia conteúdo do sistema de origem por meio de sua API, grava documentos em um bucket do S3 com arquivos secundários JSON de metadados apropriados e aciona um trabalho de ingestão de 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 auxiliares .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 de estratégias 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 do contexto amplo e dos detalhes específicos.

Teste e validação

Para avaliar o desempenho, execute o Kendra e o BMKB em paralelo. Envie consultas idênticas para os 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 de 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 migrar o tráfego de produção para o BMKB, verifique o seguinte: todas as fontes de dados foram ingeridas e atualizadas sem documentos com falha; 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 do 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 BMKB.

Resumo

A migração da Amazon Kendra Bedrock Managed Knowledge Base 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 Suporte em caso de dúvidas adicionais.