Recuperação Agnética Observável com Amazon Bedrock Knowledge Base e AWS CloudFormation

Do RAG clássico à recuperação agnética empresarial

Equipes que adicionam Geração Aumentada por Recuperação (RAG) a um modelo de fundação geralmente começam com uma única etapa de recuperação em uma única base de conhecimento. Isso funciona bem enquanto as perguntas são simples — mas começa a falhar quando a resposta está distribuída em múltiplas fontes ou quando o sistema precisa decidir qual fonte consultar antes de responder.

A recuperação agnética empresarial resolve esse problema: um agente raciocina sobre a pergunta, direciona a consulta para a base de conhecimento correta, recupera informações de forma iterativa e retorna uma resposta fundamentada com citações. Mas essa abordagem introduz um desafio operacional mais complexo — uma vez que o agente raciocina e recupera em loop, fica difícil enxergar o que ele fez e se a resposta foi de boa qualidade.

Um post anterior da AWS automatizou um fluxo RAG de passo único com uma Knowledge Base autogerenciada (baseada em vector store). Agora, o Amazon Bedrock Knowledge Bases evoluiu para a recuperação agnética com o lançamento das Managed Knowledge Bases. A API AgenticRetrieveStream das Managed Knowledge Bases realiza planejamento em múltiplos turnos, executa ferramentas de recuperação e gera respostas fundamentadas com citações.

A AWS publicou uma solução que vai além: um sistema de recuperação agnética empresarial onde um agente raciocina, recupera informações em múltiplas bases de conhecimento e sintetiza uma resposta citada. A solução é construída sobre o Amazon Bedrock Managed Knowledge Base e o Amazon Bedrock AgentCore, com observabilidade e avaliação integradas desde o início — e implantada com uma única cadeia de stacks do AWS CloudFormation.

Como a solução funciona

O fluxo de trabalho da solução segue estas etapas:

• Um usuário envia uma pergunta ao agente hospedado no Amazon Bedrock AgentCore runtime. O runtime auto-instrumenta cada etapa com spans OpenTelemetry, tornando o loop de raciocínio e ação observável desde a primeira chamada.
• O modelo de raciocínio do agente planeja a tarefa e realiza o roteamento entre bases de conhecimento: dado uma ferramenta de recuperação por base de conhecimento, ele seleciona a ferramenta cujo tópico corresponde à pergunta (financeiro ou clima).
• A chamada de ferramenta selecionada é intermediada pelo Amazon Bedrock AgentCore Gateway via Protocolo de Contexto de Modelo (MCP), que invoca a API AgenticRetrieveStream da Managed Knowledge Base correspondente.
• O AgenticRetrieveStream decompõe a pergunta em subconsultas, recupera iterativamente do armazenamento gerenciado (ingerido de corpora no Amazon S3) e sintetiza uma resposta fundamentada e citada que flui de volta ao agente via Gateway.
• O agente verifica se o contexto retornado é suficiente. Se não, recupera novamente em outra iteração do loop antes de compor sua resposta final. Se sim, retorna a resposta citada ao usuário.
• Durante todo o processo, o runtime emite spans, uso de tokens e métricas para o Amazon CloudWatch e AWS X-Ray, alimentando as sete camadas de observabilidade e os scores de avaliação sob demanda e contínua.

Managed Knowledge Base vs. Knowledge Base autogerenciada

O Amazon Bedrock agora oferece uma Managed Knowledge Base (Tipo: MANAGED): a AWS gerencia a ingestão, armazenamento, indexação e recuperação automaticamente — incluindo embedding e reranking com modelos gerenciados pelo serviço por padrão. Isso significa que não há banco de dados vetorial para provisionar, escalar ou corrigir.

A tabela abaixo resume as diferenças principais entre os dois tipos:

• Recuperação agnética (AgenticRetrieveStream): disponível apenas na Managed; não suportada na autogerenciada.
• Integração com AgentCore Gateway: disponível apenas na Managed.
• Armazenamento de dados: auto scaling totalmente gerenciado pela AWS na Managed; você provisiona, escala e mantém na autogerenciada.
• Embedding + reranking: modelos gerenciados embutidos na Managed (com opção de selecionar outros modelos disponíveis no Amazon Bedrock); você configura na autogerenciada.
• Infraestrutura para gerenciar: nenhuma na Managed; banco de dados vetorial e mais na autogerenciada.

Visão geral da solução: quatro stacks CloudFormation

A solução é implantada como quatro stacks nativas do AWS CloudFormation, cada uma conectando suas saídas à próxima:

• 01-knowledge-bases: cria um bucket no Amazon S3, duas Managed Knowledge Bases (um corpus financeiro e um de clima, para que o agente tenha algo para rotear), suas fontes de dados e configurações de Gerenciamento de Identidade e Acesso (IAM), além de um recurso customizado de ingestão que faz upload dos documentos e executa a primeira sincronização.
• 02-agentic-gateway: provisiona um Amazon Bedrock AgentCore Gateway (autenticação AWS_IAM, MCP) com um alvo por base de conhecimento construído sobre o conector nativo bedrock-knowledge-bases, para que cada base exponha sua própria ferramenta AgenticRetrieveStream sem nenhuma função AWS Lambda ou contêiner extra.
• 03-agent-runtime: provisiona um repositório no Amazon Registro de Contêineres Elástico (ECR), um projeto AWS CodeBuild que constrói uma imagem de agente Strands instrumentada com OpenTelemetry, o Amazon Bedrock AgentCore runtime que a hospeda, o roteamento de entrega de logs e rastreamentos, e a configuração de avaliação online.
• 04-dashboards: cria os dois dashboards do Amazon CloudWatch.

Os datasets da solução

A solução inclui dois pequenos corpora sintéticos no repositório, na pasta data/:

• Financeiro: um relatório 10-K sintético da empresa fictícia Octank Financial (octank_financial_10K.pdf, ~198 KB).
• Clima: um relatório real e publicamente disponível do Serviço de Pesquisa do Congresso dos EUA sobre tornados (IF12695, tornadoes_report.pdf, ~560 KB).

Os dois corpora são intencionalmente distintos para que o agente precise rotear cada pergunta para a base de conhecimento correta — essa é a proposta de roteamento semântico. A solução usa duas bases de conhecimento separadas em vez de uma única com duas fontes de dados de propósito: cada base é exposta como sua própria ferramenta de recuperação, então o agente toma uma decisão real de roteamento entre elas. Uma única base com duas fontes de dados daria ao agente apenas uma ferramenta, sem roteamento a demonstrar e com os sinais por corpus misturados.

Por serem Managed Knowledge Bases, não é necessário configurar chunking, embedding ou índice. Na ingestão, o Amazon Bedrock analisa cada PDF, divide em chunks, gera embeddings com seu modelo gerenciado e indexa automaticamente.

Implantando a solução

A implantação requer os seguintes pré-requisitos:

• Uma conta AWS com permissões para Amazon Bedrock, Amazon Bedrock AgentCore runtime, Amazon Bedrock AgentCore Gateway, AWS Identity and Access Management (IAM), Amazon CloudWatch, AWS X-Ray, Amazon ECR, AWS CodeBuild, Amazon S3, AWS Lambda e AWS CloudFormation.
• Acesso ao modelo Amazon Bedrock habilitado para o modelo do agente (padrão: us.anthropic.claude-haiku-4-5-20251001-v1:0). Consulte os modelos de fundação suportados no Amazon Bedrock.
• CloudWatch Transaction Search habilitado, para que os spans OpenTelemetry cheguem em aws/spans para as Camadas 5 a 7. Consulte a documentação do CloudWatch Transaction Search.
• Interface de Linha de Comando AWS (AWS CLI) v2.
• Python 3.13 com boto3>=1.43 para o notebook. Sem Docker local (a imagem do agente é construída pelo CodeBuild). Consulte como instalar o AWS CLI e a documentação do Boto3.

Com os pré-requisitos prontos, a implantação é feita com três comandos:

git clone https://github.com/aws-samples/amazon-bedrock-samples.git
cd rag/managed-knowledge-bases/07-IaaC/managed-kb-observability-cfn/
./scripts/deploy.sh us-west-2 bmkb-ml21427

O script implanta os quatro stacks em ordem, conectando as saídas para frente e reportando cada etapa. O stack 03-agent-runtime constrói o contêiner do agente com o CodeBuild, então aguarde aproximadamente 8 a 10 minutos para essa etapa. Ao final, todos os quatro stacks estarão com status CREATE_COMPLETE.

As sete camadas de observabilidade

Cada camada responde a uma pergunta operacional diferente e, juntas, cobrem o agente de ponta a ponta. As camadas 1, 4 e 5 são emitidas automaticamente. As camadas 3, 6 e 7 são publicadas como métricas customizadas pelo notebook de driver.

• L1 — Métricas nativas da Knowledge Base: invocações, erros e throttles por KB. Cada base de conhecimento está saudável e atendendo tráfego?
• L2 — Ingestão: status do job de ingestão e resultados por documento. Os documentos chegaram à base de conhecimento?
• L3 — Qualidade da recuperação agnética: utilização sem referência, cobertura fundamentada, taxa de duplicatas. O agente está recuperando contexto relevante e bem fundamentado?
• L4 — Métricas do Gateway / MCP: volume e latência das chamadas de ferramentas do Gateway. A camada de ferramentas de recuperação é rápida e confiável?
• L5 — Árvore de spans OTEL: o rastreamento completo de raciocínio e ação do agente. O que o agente fez, passo a passo?
• L6 — Uso de tokens: tokens gen_ai.usage por sessão e modelo. Quanto cada consulta custa em tokens?
• L7 — Scores de avaliação: correção, fidelidade, seleção de ferramenta, relevância da resposta. As respostas são realmente boas?

A solução provisiona dois dashboards do CloudWatch cobrindo essas sete camadas. O Dashboard A cobre a observabilidade agnética de ponta a ponta — para N consultas, você vê aproximadamente N invocações do agente, 2N recuperações, 3N chamadas de LLM e 5N operações MCP do Gateway, tornando o loop agnético visível. O Dashboard B cobre a observabilidade por base de conhecimento: tamanho do índice, volume de recuperação, chamadas de ferramentas agnéticas e uso de tokens por modelo.

Avaliação: sob demanda e contínua

A qualidade é medida de duas formas, e ambas são provisionadas pelo stack:

Sob demanda: o notebook de driver chama o AgentCore Evaluate (LLM como juiz) sobre os spans de cada sessão para avaliadores embutidos (Correção, Fidelidade, Precisão de Seleção de Ferramenta) e publica os scores no CloudWatch, onde aparecem como Camada 7 no Dashboard A.

Contínua (online): o stack 03-agent-runtime também provisiona um AWS::BedrockAgentCore::OnlineEvaluationConfig que amostra sessões ao vivo e as pontua automaticamente. Os resultados aparecem no console em CloudWatch > GenAI Observability > Bedrock AgentCore > Evaluations, sem necessidade de executar o notebook. A configuração lista os avaliadores: Precisão de Seleção de Ferramenta, Fidelidade, Correção e Relevância da Resposta.

⚠️ Amostragem e custo: a solução define SamplingPercentage: 100 apenas para o experimento do post, para que cada sessão seja pontuada e os resultados sejam imediatamente visíveis. Isso não é uma recomendação para produção. A avaliação online invoca um LLM como juiz por sessão amostrada, então o custo escala com a taxa de amostragem e o volume de tráfego. Para um deployment real, escolha uma porcentagem que se encaixe nas suas necessidades de monitoramento de qualidade e orçamento. A taxa é uma única propriedade (OnlineEvaluationConfig.Rule.SamplingConfig.SamplingPercentage) no arquivo templates/03-agent-runtime.yaml.

Um padrão comum é usar avaliação sob demanda durante a iteração e habilitar a avaliação contínua com uma porcentagem de amostragem modesta quando o agente estiver atendendo usuários reais.

Limpeza do ambiente

Para remover todos os recursos em ordem reversa de dependência, basta executar:

./scripts/cleanup.sh us-west-2 bmkb-ml21427

Casos de uso e próximos passos

Esse padrão é adequado para cargas de trabalho onde a resposta correta está em mais de um lugar e o sistema precisa escolher onde procurar. Exemplos incluem:

• Um assistente de suporte que roteia entre uma base de conhecimento de documentação de produto e uma base de cobrança.
• Um assistente de pesquisa que abrange corpora regulatórios e científicos separados.
• Um helpdesk interno que mantém conteúdo de RH, TI e finanças em bases de conhecimento isoladas para separação de acesso e custos.

A partir daqui, é possível apontar as fontes de dados para seus próprios corpora, colocar o agente em uma Nuvem Privada Virtual (VPC), ajustar a taxa de amostragem da avaliação online conforme seu orçamento e políticas, ou adicionar mais bases de conhecimento ao roteador. Os templates, o notebook de driver e os utilitários estão disponíveis no repositório. As instruções detalhadas para conduzir tráfego e observar os dashboards estão no README da solução.

Fonte

Build observable enterprise agentic retrieval using Managed Amazon Bedrock Knowledge Base with AWS CloudFormation (https://aws.amazon.com/blogs/machine-learning/build-observable-enterprise-agentic-retrieval-using-managed-amazon-bedrock-knowledge-base-with-aws-cloudformation/)