Knowledge base deixou de ser componente de RAG e virou infraestrutura de agentes
Até pouco tempo atrás, "montar uma knowledge base" era trabalho de cada time: escolher parsing, chunking, embeddings, re-ranking, conectores de dados, e manter tudo isso funcionando. O Amazon Bedrock Managed Knowledge Base sinaliza uma mudança de categoria - a AWS está tratando isso como infraestrutura organizacional, não como componente que cada squad reconstrói do zero.
O problema não era falta de RAG, era falta de padronização
A AWS descreve três dores que motivaram o produto: dados corporativos espalhados por sistemas diferentes, cada um com seu próprio controle de acesso e formato de documento, exigindo conectores customizados que atrasam o desenvolvimento; a necessidade de testar manualmente diferentes estratégias de parsing, chunking, embeddings e comportamento de recuperação agentic para conseguir resultados confiáveis; e o desafio de escalar - servir bases de conhecimento com milhões de documentos, ou administrar milhares de bases menores espalhadas por times, mantendo segurança e controle de custo. Nenhuma dessas três é um problema de modelo de IA. São problemas de operação de infraestrutura.
O que "gerenciado" tira das mãos do time de engenharia
A resposta da AWS é abstrair componentes que antes eram construídos manualmente - armazenamento, recuperação, embeddings, re-ranking e seleção de modelo de fundação - em um único serviço, que seleciona e mantém automaticamente modelos padrão, eliminando configuração manual. Isso é o ponto central da mudança de categoria: a knowledge base para de ser algo que um time de dados constrói uma vez por projeto de RAG, e passa a ser um serviço que qualquer agente da organização consome.
Seis conectores nativos e parsing que se adapta ao tipo de dado
O serviço inclui seis conectores nativos de ingestão - Amazon S3, SharePoint, Confluence, Web Crawler, Google Drive e OneDrive - cada um com Smart Parsing que reconhece o modelo de dados específico do conector (por exemplo, o Web Crawler preserva estrutura HTML e imagens), processa conteúdo multimodal automaticamente, e usa modelos de fundação para entender a estrutura do documento e definir a estratégia de chunking mais adequada, em vez de aplicar a mesma regra genérica a tudo.
Agentic Retriever: consultas que exigem mais de uma etapa
Para consultas complexas que exigem recuperação multiturno e multihop, o Agentic Retriever decompõe a pergunta em um plano de etapas e executa raciocínio multi-hop através das bases de conhecimento - em vez de tratar toda consulta como uma busca única de similaridade, o serviço reconhece quando uma pergunta precisa de várias buscas encadeadas para ser respondida corretamente.
Disponibilidade regional e integração via MCP
O serviço está disponível em seis regiões comerciais (Leste dos EUA, Oeste dos EUA, Ásia-Pacífico em Sydney e Tóquio, Europa em Dublin, Frankfurt e Londres) mais AWS GovCloud, e se integra ao AgentCore Gateway como um tipo de destino pré-construído - as ferramentas são descobertas automaticamente por clientes de qualquer framework compatível com MCP, incluindo LangChain, CrewAI e LlamaIndex. Essa integração é o que transforma a knowledge base de "componente que um agente específico usa" em "infraestrutura que qualquer agente, de qualquer framework, pode descobrir e consumir".
O que isso muda para quem está construindo agentes enterprise
A mudança de framing é o dado mais importante aqui: a AWS está posicionando a knowledge base como infraestrutura separada da escolha de modelo - times podem adotar os modelos mais recentes de embedding, re-ranking e geração sem reconstruir o pipeline de RAG inteiro. Para uma organização com dezenas de agentes em produção, isso significa parar de tratar "montar uma base de conhecimento" como um projeto por agente, e passar a tratá-la como uma capacidade central que se provisiona uma vez e se reutiliza.