Knowledge Bases: RAG gerenciado de ponta a ponta

Knowledge Bases é RAG fully-managed: você aponta para os dados, escolhe um modelo de embedding e um vector store, e o Bedrock cuida de ingestão, parsing, chunking, embeddings, indexação e retrieval com citações. Considere quando:

• Você precisa de RAG sobre dados corporativos sem construir nem operar o pipeline de ingestão/retrieval.
• Rastreabilidade importa: cada resposta precisa vir com citações apontando o documento-fonte.
• Você quer metadata filtering (ex.: só documentos do tenant X, ou do tier enterprise) na busca.
• Os dados mudam com frequência e você quer sync incremental, não reindexar tudo do zero toda vez.
• Vale menos a pena quando você já tem um pipeline de RAG maduro e quer controle absoluto de cada etapa — aí LangChain/LlamaIndex sobre seu próprio store pode fazer mais sentido.

Por baixo, uma Knowledge Base são dois pipelines distintos. O de ingestão (build-time) roda quando você sincroniza uma data source: lê, parseia, chunka, gera embeddings e escreve no vector store. O de query (runtime) roda a cada pergunta: transforma a pergunta em embedding, busca os chunks mais próximos, opcionalmente reordena com reranking e gera a resposta com citações. Separar os dois na cabeça ajuda a raciocinar sobre custo (ingestão é esporádica; query é por request) e latência.

Uma Knowledge Base pode ter várias data sources. Cada conector sabe autenticar, listar e ler documentos da fonte, e respeita filtros de inclusão/exclusão (por padrão de URL/prefixo) para você ingerir só o que importa. Os conectores nativos em meados de 2026:

• Amazon S3 — o mais comum: aponte para um bucket/prefixo com seus documentos.
• Web Crawler — rastreia páginas web (apenas as suas ou aquelas que você tem autorização para rastrear).
• Confluence, SharePoint, Salesforce, Google Drive, OneDrive — SaaS corporativo com auth gerenciada.
• Ingestão direta via API (custom) — você entrega os documentos/chunks por chamada, sem conector, quando a fonte é sua e exótica.

Chunking é como o documento vira pedaços indexáveis. É a decisão que mais mexe na qualidade do retrieval: chunk grande demais dilui a relevância, chunk pequeno demais perde contexto. O Bedrock oferece estas estratégias:

O vector store é onde os embeddings vivem e de onde o retrieval lê. O Bedrock gerencia a integração, mas a escolha do store define custo, escala e recursos. Se você não indicar um existente, o Bedrock provisiona um OpenSearch Serverless por padrão — e é aí que a fatura escapa (voltamos a isso na seção de custo). Além dos stores vetoriais abaixo, dá para usar um Amazon Kendra GenAI Index como retriever alternativo quando você já investe no Kendra.

Antes de mandar os chunks para o modelo gerar, vale reordená-los por relevância real — é o que faz o reranking. O Bedrock expõe a Rerank API com dois modelos: Amazon Rerank 1.0 e Cohere Rerank 3.5 (100+ idiomas). Você liga o reranking via setting nas APIs Retrieve e RetrieveAndGenerate; ele reordena o top-k recuperado e corta para os N melhores antes da geração. Sobre a geração em si, há duas APIs, e a escolha define quem controla o quê — ambas suportam metadata filtering, reranking e integração com Guardrails:

import boto3

# RAG data plane: bedrock-agent-runtime (NÃO bedrock-runtime)
client = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

resp = client.retrieve_and_generate(
    input={"text": "Qual é a política de reembolso para clientes enterprise?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "KB1234ABCD",
            "modelArn": (
                "arn:aws:bedrock:us-east-1::foundation-model/"
                "anthropic.claude-3-5-sonnet-20241022-v2:0"
            ),
            "retrievalConfiguration": {
                "vectorSearchConfiguration": {
                    "numberOfResults": 10,
                    # Filtro por metadata do documento (multi-tenant, tier, etc.)
                    "filter": {"equals": {"key": "tier", "value": "enterprise"}},
                    # Reordena os 10 recuperados e mantém os 5 melhores
                    "rerankingConfiguration": {
                        "type": "BEDROCK_RERANKING_MODEL",
                        "bedrockRerankingConfiguration": {
                            "numberOfRerankedResults": 5,
                            "modelConfiguration": {
                                "modelArn": (
                                    "arn:aws:bedrock:us-east-1::foundation-model/"
                                    "amazon.rerank-v1:0"
                                )
                            },
                        },
                    },
                }
            },
        },
    },
)

print(resp["output"]["text"])

# Citações: cada trecho gerado aponta o chunk-fonte (rastreabilidade)
for citation in resp["citations"]:
    for ref in citation["retrievedReferences"]:
        print(ref["location"], "->", ref["content"]["text"][:80])

Aqui está o erro de custo mais comum em RAG na AWS, e ele não tem nada a ver com tokens do modelo. O modelo cobra por consulta; o vector store cobra por estar de pé. Numa KB com pouco tráfego, a maior parte da fatura vem de infra ligada 24/7 sem ninguém usando.