Blog

O que foi anunciado

A AWS anunciou a disponibilidade geral do Agentic CX Designer, uma ferramenta de canvas visual sem código integrada ao Amazon Connect Customer. O objetivo é permitir que equipes de negócio criem e publiquem experiências de autoatendimento com inteligência artificial — tanto por voz quanto por canais digitais — sem depender de times de engenharia para colocar tudo em produção.

O que é o Agentic CX Designer

A proposta central da ferramenta é unir dois tipos de IA em um único ambiente: a IA agêntica, que conduz conversas naturais com os clientes usando modelos de linguagem de grande escala (LLMs), e a IA determinística, que garante resultados exatos em situações onde não há margem para variação — como elegibilidade, aprovações, roteamento ou conformidade regulatória.

Na prática, funciona assim: no canvas visual, a equipe define a lógica do fluxo, as regras de negócio, as integrações com sistemas existentes e os limites de atuação da IA. O modelo de linguagem cuida da conversa em si, de forma natural. Para etapas críticas do processo, o fluxo segue exatamente o que foi definido pela equipe — sem improvisação do modelo.

A analogia usada pela AWS é direta: o Agentic CX Designer oferece “a clareza de um fluxograma com o poder de um modelo de linguagem de grande escala”.

Principais capacidades

• Canvas visual sem código: design, testes e publicação acontecem no mesmo ambiente, sem necessidade de transferir o trabalho para a engenharia.
• Combinação de IA agêntica e determinística: conversas naturais com controle preciso nos pontos críticos do fluxo.
• Integração com sistemas de negócio: é possível conectar a ferramenta aos sistemas que já operam na empresa durante o próprio processo de design.
• Velocidade de implantação: segundo a AWS, equipes conseguem ir do design à produção em semanas, não meses.

Regiões disponíveis

O Agentic CX Designer está disponível nas seguintes regiões da AWS:

• US East (N. Virginia)
• US West (Oregon)
• Canada (Central)
• Asia Pacific (Tokyo)
• Asia Pacific (Seoul)
• Asia Pacific (Singapore)
• Asia Pacific (Sydney)
• Europe (Frankfurt)
• Europe (London)

Saiba mais

Para entender como o Agentic CX Designer está transformando as experiências de autoatendimento, a AWS disponibilizou um post no blog oficial com mais detalhes sobre a combinação de lógica de negócio estruturada com IA agêntica. Também é possível acessar a documentação oficial da ferramenta e o site do Amazon Connect Customer, solução de IA agêntica voltada para empresas que buscam entregar experiências de atendimento ao cliente de alto nível.

Fonte

Amazon Connect Customer announces general availability of agentic CX designer (https://aws.amazon.com/about-aws/whats-new/2026/09/agentic-cx-designer/)

Claude Fable 5.1 chega ao Amazon Bedrock

A AWS anunciou a disponibilidade do Claude Fable 5.1 no Amazon Bedrock e na Claude Platform on AWS. O novo modelo da Anthropic foi projetado para tarefas de alta complexidade — com destaque para codificação, pesquisa científica e fluxos de trabalho corporativos. Por conta do nível de capacidade que oferece, a Anthropic classificou o Fable 5.1 como um Covered Model (Modelo Coberto), uma categoria que impõe políticas adicionais de retenção de dados, revisão de segurança e controle de acesso em qualquer ambiente onde o modelo esteja disponível. Para entender como isso funciona no Amazon Bedrock, vale consultar a documentação de detecção de uso indevido e a página de Covered Models da Anthropic.

Junto com o lançamento do modelo, a Anthropic também apresentou os Enterprise Frontier Safeguards (Salvaguardas de Fronteira Empresarial, EFS) — uma solução desenvolvida em parceria com a AWS que permite às organizações utilizar os modelos mais avançados da Anthropic mantendo seus dados dentro da infraestrutura de nuvem que controlam.

O que diferencia o Fable 5.1

Segundo a Anthropic, o Fable 5.1 representa um avanço claro em relação ao Fable 5 nos testes de raciocínio mais exigentes que a empresa realiza. Esses testes envolvem matemática de competição, questões de pós-graduação em engenharia e ciências, e problemas longos com múltiplos passos onde a confiabilidade é essencial.

Na prática, isso se traduz em melhor julgamento em tarefas ambíguas e menos respostas erradas apresentadas com excesso de confiança. As principais melhorias incluem:

• Codificação agêntica: O modelo consegue conduzir projetos de forma mais autônoma — desde funcionalidades que abrangem toda uma base de código até revisão e otimização de performance, em sessões de várias horas. Ele também é mais honesto: quando trava, diz isso claramente, e é menos propenso a desabilitar testes que estão falhando para forçar uma aprovação.
• Operação autônoma: Projetado para tarefas de múltiplas horas que envolvem vários aplicativos. Ele planeja, utiliza as ferramentas necessárias, se recupera quando uma etapa falha e mantém o usuário informado sem precisar ser solicitado.
• Trabalho de conhecimento de ponta a ponta: Conduz uma análise desde a primeira pergunta até o documento final — fazendo a pesquisa, construindo planilhas, redigindo memorandos ou apresentações e verificando os números ao longo do processo. Voltado especialmente para rotinas de finanças, contabilidade e saúde.
• Pesquisa científica: Suporta campanhas de pesquisa desde a revisão de literatura e formulação de hipóteses até modelagem, experimentos e verificação formal.
• Melhor usabilidade: Mantém o usuário atualizado em tarefas longas, escreve com mais clareza e segue instruções com mais precisão.

Retenção de dados e revisão humana

Por ser um Covered Model, o uso do Claude Fable 5.1 está sujeito à retenção de dados por até 30 dias e à revisão humana por pessoal da Amazon. No Amazon Bedrock, é possível controlar a retenção de dados por meio de um modo configurável na conta ou no projeto do Amazon Bedrock, utilizando a API de retenção de dados.

Para usar o Claude Fable 5.1, é obrigatório ativar o modo aws_review antes de invocar o modelo. Nesse modo, a AWS retém os prompts e as saídas para revisão de segurança humana dentro do perímetro da AWS — mas sem exigir compartilhamento com o provedor do modelo. Mais detalhes estão disponíveis na documentação de retenção de dados do Amazon Bedrock.

Enterprise Frontier Safeguards

Os Enterprise Frontier Safeguards (EFS), desenvolvidos em parceria entre AWS e Anthropic, foram criados para ajudar clientes elegíveis a utilizar o Claude Fable 5 e o Claude Fable 5.1 mantendo seus dados em um ambiente de nuvem sob seu próprio controle.

Clientes elegíveis ao EFS podem usar esses modelos com retenção zero de dados (Zero Data Retention, ZDR) no Amazon Bedrock e na Claude Platform on AWS. Essa opção está disponível para uso interno até 31 de dezembro de 2026.

Recursos adicionais do EFS serão disponibilizados ainda neste ano: os clientes poderão manter prompts e saídas dentro de sua própria conta AWS, sob suas próprias chaves de criptografia, políticas de acesso e registros de auditoria. O monitoramento de segurança será realizado por revisão automatizada, sem necessidade de revisão humana.

Como começar com o Fable 5.1 no Amazon Bedrock

Para experimentar o modelo diretamente pela interface, basta acessar o console do Amazon Bedrock, navegar até Test > Playground e selecionar o Fable 5.1. A partir daí, é possível executar prompts diretamente contra o modelo.

Para uso programático, o modelo pode ser chamado via Anthropic Messages API contra o bedrock-runtime (usando o SDK da Anthropic). Também é possível utilizar as APIs Invoke e Converse no bedrock-runtime por meio da Interface de Linha de Comando da AWS (AWS CLI) e do AWS SDK.

Pré-requisitos

• Conta AWS ativa com acesso ao Amazon Bedrock.
• AWS CLI instalada e configurada.
• Python 3.10 ou superior.
• Boto3 instalado: pip install boto3.
• Permissões do Gerenciamento de Identidade e Acesso da AWS (IAM): bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream.

Abaixo, um exemplo rápido usando o SDK da AWS para Python (Boto3):

import boto3
import json

# Create a Bedrock Runtime client
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1"
)

# Invoke Claude Fable 5.1
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-fable-5-1",
    contentType="application/json",
    accept="application/json",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 4096,
        "messages": [
            {
                "role": "user",
                "content": "An S3 bucket serves 40 TB/month egress. Estimate the monthly egress cost at $0.09/GB, and state one architecture change to cut it. Show the calculation, keep it under 120 words."
            }
        ]
    })
)

result = json.loads(response["body"].read())

# Fable 5.1 is a reasoning model: the response may include a thinking block
# before the text block, so select the text block rather than a fixed index.
print(next(b["text"] for b in result["content"] if b["type"] == "text"))

Para mais exemplos, vale explorar o notebook de introdução disponível no GitHub.

Disponibilidade

O Claude Fable 5.1 já está disponível no Amazon Bedrock por meio dos perfis de inferência US Geo CRIS (us.) e Global CRIS (global.). No AWS GovCloud (US), o modelo está acessível nos endpoints bedrock-runtime e bedrock-mantle. A lista completa de regiões suportadas pode ser consultada na documentação do Bedrock. As informações de preço estão disponíveis na página de preços do Amazon Bedrock.

O modelo também está disponível pela Claude Platform on AWS na América do Norte. Para experimentar, acesse o console do Amazon Bedrock, a Claude Platform on AWS, ou explore os notebooks de introdução no GitHub.

Fonte

Introducing Claude Fable 5.1 on AWS (https://aws.amazon.com/blogs/machine-learning/introducing-claude-fable-5-1-on-aws/)

Criação de aplicações sem código, direto pela descrição

A AWS anunciou a disponibilidade geral de um novo recurso do Amazon Quick: a criação de aplicações personalizadas por meio de linguagem natural. Em vez de envolver times de desenvolvimento ou meses de projeto, qualquer pessoa pode descrever o que precisa e o Quick constrói a aplicação funcional automaticamente.

A proposta é clara: eliminar a barreira técnica entre uma ideia e um produto funcionando. Gerentes de produto, analistas financeiros, parceiros de Recursos Humanos (RH) e analistas de operações passam a ter autonomia para criar soluções próprias — sem escrever uma linha de código.

Como funciona na prática

O fluxo é direto: o usuário descreve o que quer, e o Quick entrega uma aplicação ativa, conectada em tempo real aos dados dos sistemas que a empresa já utiliza. A ferramenta se integra nativamente com plataformas amplamente adotadas no mercado corporativo, como:

• Salesforce
• Jira e Asana
• ServiceNow
• Microsoft 365 e Google Workspace
• Bancos de dados e data warehouses

As aplicações se mantêm atualizadas automaticamente conforme os dados subjacentes mudam. Além disso, todas as conexões respeitam as políticas de identidade, autorização e controle de acesso já existentes na organização — sem necessidade de reconfigurar permissões.

Publicação, compartilhamento e ajustes

Após a criação, o app pode ser publicado e compartilhado instantaneamente — seja para usuários específicos ou para toda a organização. E se for necessário ajustar algo, como adicionar inteligência artificial (IA), mudar o estilo visual ou conectar a outro sistema, basta descrever a mudança desejada. O Quick cuida do restante.

Casos de uso reais do período de prévia

Durante o período de prévia, empresas já utilizaram o Amazon Quick para substituir planilhas e ferramentas desconectadas por aplicações construídas para fins específicos. Dois exemplos se destacam:

• A New York Life desenvolveu um portal de e-learning para sua equipe de Vida Institucional, consolidando processos de onboarding, treinamentos e cursos de conformidade em uma única experiência.
• O próprio time do Amazon Quick passou a acompanhar pipeline, solicitações de clientes e métricas de adoção em um app de revisão semanal de liderança, substituindo a extração manual de dados de quatro sistemas diferentes.

Disponibilidade e como começar

A criação de apps no Quick está disponível para clientes dos planos Plus, Professional e Enterprise a partir de 1º de setembro de 2026. Para saber mais sobre como começar, a AWS disponibilizou o guia de introdução aos Apps no Quick.

Fonte

Amazon Quick now lets you build custom apps with natural language – (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-quick-custom-apps-natural-language/)

AWS lidera ranking de infraestrutura de IA segundo a Forrester

A Forrester Research publicou o relatório Forrester Wave: AI Infrastructure Solutions, Q4 2025, uma das avaliações independentes mais respeitadas do setor de tecnologia. Nessa edição, a AWS foi posicionada como Líder entre os 13 provedores avaliados, obtendo ainda a pontuação mais alta na categoria Estratégia — o que indica não apenas o que a empresa entrega hoje, mas para onde ela está caminhando.

Para quem trabalha com nuvem no Brasil e precisa tomar decisões de arquitetura para projetos de Inteligência Artificial (IA), esse tipo de avaliação externa é uma referência valiosa: ela vai além do marketing e analisa critérios técnicos concretos, feedback de clientes reais e a visão de longo prazo de cada fornecedor.

Por que infraestrutura de IA virou tema central

À medida que a adoção de IA acelera nas empresas, a infraestrutura deixou de ser um detalhe técnico para se tornar um fator estratégico. Não basta ter acesso a modelos poderosos — é preciso ter uma base que suporte o ciclo completo das cargas de trabalho de IA: desde o treinamento inicial e o ajuste fino (fine-tuning) até a inferência em escala no ambiente de produção.

Segundo a própria avaliação da Forrester, uma infraestrutura de IA bem-sucedida precisa de três elementos fundamentais:

• Arquitetura específica por tipo de carga: projetada para treinamento, ajuste fino e inferência, e não apenas para necessidades computacionais genéricas.
• Eficiência de engenharia: design coordenado entre computação, rede, armazenamento e orquestração para maximizar o aproveitamento dos recursos.
• Sustentabilidade e flexibilidade: considerando consumo de energia, resfriamento e a capacidade de evitar dependência excessiva de um único fornecedor (vendor lock-in).

O que a Forrester avaliou — e como a AWS se saiu

O relatório analisou 13 provedores com base em critérios detalhados distribuídos em três grandes dimensões: oferta atual, estratégia e feedback de clientes. A AWS alcançou a pontuação máxima (5,00) em 16 critérios, abrangendo tanto aspectos técnicos quanto de visão de negócio.

Na categoria de oferta atual, os critérios com nota máxima incluem:

• Arquitetura
• Ecossistema
• Gerenciamento de dados
• Treinamento
• Desenvolvimento
• Gerenciamento e operações
• Tolerância a falhas
• Eficiência
• Segurança
• Escalabilidade

Na categoria de estratégia, as notas máximas foram em:

• Visão
• Inovação
• Roadmap
• Ecossistema de parceiros
• Flexibilidade e transparência de preços

Como a AWS estrutura sua abordagem de infraestrutura para IA

Um dos pontos centrais destacados pela Forrester é a estratégia da AWS de oferecer múltiplas opções de hardware, sem forçar o cliente a depender de um único tipo de acelerador. A empresa disponibiliza tanto chips proprietários — o AWS Inferentia e o AWS Trainium — quanto instâncias com GPUs da NVIDIA. Essa combinação permite que equipes técnicas escolham o hardware mais adequado para cada tipo de carga de trabalho, equilibrando desempenho e custo.

O próprio relatório da Forrester resume bem essa proposta:

“A visão da AWS é oferecer tanto aceleradores proprietários quanto GPUs da NVIDIA, dando aos clientes opções com boa relação custo-benefício para cargas de inferência sem lock-in de hardware. Seu silício personalizado entrega desempenho sólido para tarefas comuns, enquanto a NVIDIA atende às necessidades de alto desempenho. O roadmap convincente sinaliza investimento contínuo no desenvolvimento de chips e integração mais estreita com serviços AWS como o Amazon SageMaker. A AWS trabalha em parceria próxima com os principais desenvolvedores de modelos, dando aos clientes acesso direto a um conjunto diversificado de modelos de fundação.”

A Forrester também destacou o perfil de empresa que mais se beneficia dessa infraestrutura:

“A AWS é a melhor opção para empresas com cargas de inferência de alto volume ou elásticas que priorizam eficiência de custos, mas ainda precisam de acesso a GPUs para cenários de pico de desempenho.”

Por onde começar

Para equipes que estão avaliando ou escalando projetos de IA na AWS, há dois pontos de entrada principais:

• Infraestrutura de IA da AWS — para conhecer as opções de chips proprietários e computação acelerada disponíveis na plataforma.
• Amazon Bedrock — para quem quer construir, personalizar e implantar aplicações de IA generativa usando Modelos de Fundação (FM) gerenciados.

Quem quiser se aprofundar na metodologia e ver como todos os 13 provedores foram avaliados pode acessar o relatório completo da Forrester.

Nota: A Forrester não endossa nenhuma empresa, produto, marca ou serviço incluído em suas publicações de pesquisa. As informações são baseadas nos melhores recursos disponíveis no momento da avaliação e as opiniões estão sujeitas a alterações. Para mais detalhes sobre a metodologia, consulte a política de objetividade da Forrester.

Fonte

AWS recognized as a Leader in The Forrester Wave: AI Infrastructure Solutions, Q4 2025 (https://aws.amazon.com/blogs/machine-learning/aws-recognized-as-a-leader-in-the-forrester-wave-ai-infrastructure-solutions-q4-2025/)

O problema que essa arquitetura resolve

Permitir que usuários façam upload de documentos e conversem com eles em tempo real parece simples na superfície. A interface de chat é relativamente fácil de construir — o problema real está na camada de recuperação por trás dela, especialmente quando a aplicação precisa atender múltiplos usuários ao mesmo tempo.

Em um ambiente multi-tenant, os documentos de cada usuário precisam ficar completamente isolados dos demais. Esse isolamento não pode depender de um valor enviado pelo cliente — ele precisa vir de uma identidade verificada no servidor. Quando você adiciona recuperação agêntica ao cenário, a complexidade aumenta: o agente decompõe uma pergunta em sub-consultas e executa múltiplas buscas em sequência, e cada um desses saltos precisa carregar o filtro correto do tenant. Se qualquer salto deixar de aplicar o filtro, o isolamento quebra.

Além disso, a equipe ainda precisaria construir e operar um motor de busca vetorial e full-text, um pipeline de ingestão que processe múltiplos formatos e um índice sincronizado. É uma quantidade significativa de infraestrutura para quem quer apenas entregar um recurso de chat com documentos.

A AWS publicou uma arquitetura de referência que endereça exatamente esse cenário usando o Amazon Bedrock Managed Knowledge Base.

O que o Amazon Bedrock Managed Knowledge Base oferece aqui

O serviço cuida da ingestão, armazenamento, embedding e ranqueamento dos documentos — sem infraestrutura para provisionar ou capacidade para monitorar. Ele também traz recuperação agêntica nativa, com planejamento iterativo e múltiplos saltos de busca para responder perguntas complexas, aplicando os filtros de acesso em cada etapa.

Com a ingestão direta via conector customizado, a aplicação envia o documento direto para a knowledge base e ele fica disponível para consulta em segundos. Não é necessário configurar pipelines externos de ingestão nem gerenciar índices separados.

Visão geral da solução

A arquitetura apresentada pela AWS tem dois fluxos principais: ingestão de documentos e recuperação conversacional. Os componentes centrais são:

• Amazon Bedrock Managed Knowledge Base: processa, armazena e recupera conteúdo multimodal, incluindo texto, vetores, metadados e arquivos estruturados como CSV e Excel. Um conector customizado recebe os uploads dos usuários diretamente.
• Amazon API Gateway e AWS Lambda: expõem os endpoints de upload, status e chat, e executam a lógica da aplicação.
• Amazon Cognito: autentica os usuários e fornece a identidade verificada que a aplicação usa para isolar os documentos de cada um.
• Amazon Simple Queue Service (SQS): desacopla os uploads da ingestão, absorve picos e encaminha mensagens com falha repetida para uma fila de mensagens mortas (dead-letter queue), mantendo o endpoint de upload responsivo.
• Amazon DynamoDB: rastreia o status de indexação de cada documento para que a aplicação mostre ao usuário quando ele está pronto para consulta.
• Amazon Simple Storage Service (S3): armazena temporariamente arquivos maiores que o limite inline e hospeda a aplicação de página única (SPA) atrás do Amazon CloudFront.

Como os dois fluxos funcionam

Ingestão de documentos

Quando um usuário faz upload de um documento, a aplicação extrai a identidade dele a partir do Token Web JSON (JWT) validado pelo API Gateway — nunca confia em um valor enviado diretamente pelo cliente. Essa identidade é incluída na mensagem enviada para a fila SQS junto com o documento ou sua referência no S3.

Arquivos de até 6 MB são enviados inline na chamada de API. Arquivos maiores, até 50 MB para texto, são primeiro enviados ao S3 e a mensagem carrega o URI do S3 para que o Bedrock leia o arquivo diretamente de lá.

Uma função Lambda worker lê a mensagem da fila, marca o documento com um atributo de metadados user_id igual ao identificador (sub) do usuário no Cognito, e então chama a API IngestKnowledgeBaseDocuments. O Amazon Bedrock fragmenta, faz o embedding e indexa o documento de forma assíncrona. O status de cada documento é registrado no DynamoDB, e o navegador consulta periodicamente um endpoint de status para atualizar a interface.

Um detalhe importante sobre a ingestão direta via conector customizado: ao contrário do conector S3 — que é projetado para ingestão em lote com sincronizações agendadas e pode sobrescrever ou remover um documento recém-adicionado — a ingestão direta via IngestKnowledgeBaseDocuments não tem sincronização. O documento persiste até ser explicitamente deletado. Além disso, como a aplicação atribui seus próprios IDs de documento, reingeri-lo com o mesmo ID atualiza o registro no lugar, sem criar duplicatas.

A knowledge base também mantém uma cópia do arquivo original recuperável via API GetDocumentContent, eliminando a necessidade de operar um repositório de documentos separado.

Ciclo de vida da indexação

A API de ingestão é assíncrona: ela retorna imediatamente com status STARTING, mas o documento só fica disponível para consulta depois que o Bedrock conclui o processamento. O ciclo passa por cinco estados:

• STARTING: requisição aceita, processamento ainda não iniciado.
• PENDING: na fila, aguardando um slot de processamento.
• IN_PROGRESS: parsing e embedding em execução.
• TEXT_INDEXED: fragmentos de texto indexados; para PDFs, o processamento multimodal ainda está em andamento. Já é possível consultar o texto.
• INDEXED: processamento completo, incluindo elementos multimodais como imagens e tabelas em PDFs.

A recomendação da AWS é marcar o documento como pronto ao atingir TEXT_INDEXED, e não esperar pelo INDEXED — a diferença só é relevante para conteúdo multimodal. Em testes com documentos pequenos (abaixo de 5 MB) em uma knowledge base ociosa, textos simples atingiram INDEXED em 2 a 3 segundos, enquanto PDFs chegaram a TEXT_INDEXED entre 5 e 30 segundos e a INDEXED em cerca de 90 segundos. Esses números são referências de ordem de grandeza para design, não garantias de latência.

Isolamento por usuário com filtros de metadados

Em uma aplicação multi-tenant, os documentos de um usuário nunca podem aparecer nos resultados de outro. A solução usa uma knowledge base compartilhada com filtros de metadados, em vez de provisionar uma knowledge base separada por tenant. Essa abordagem escala melhor para grandes volumes de usuários finais, evita custos de base de múltiplos índices pequenos e elimina a latência de criação de uma knowledge base no momento do cadastro.

O worker marca cada documento com o atributo user_id, e a aplicação aplica um filtro de igualdade nesse atributo em cada consulta. O valor do filtro é construído no servidor a partir do JWT verificado — nunca a partir do corpo da requisição. Esse é o limite de segurança real da solução.

A knowledge base tem a capacidade de inferir filtros a partir do texto da pergunta, mas isso é um recurso de relevância, não de controle de acesso. O isolamento precisa vir de um filtro explícito construído pela aplicação a partir da identidade autenticada. Como defesa em profundidade, a implementação de referência confirma que o filtro está correto antes de cada requisição e descarta qualquer fragmento retornado cujo user_id não corresponda ao do chamador.

Para cargas de trabalho reguladas que exigem que o próprio serviço aplique o controle de acesso, a knowledge base também suporta listas de controle de acesso (ACLs) no nível do documento, avaliadas contra um userContext no momento da consulta.

Recuperação e geração de respostas

Para responder a uma pergunta, a aplicação chama a API AgenticRetrieveStream com o filtro explícito de user_id. A API executa um ciclo completo de chat: decompõe a pergunta em sub-consultas, executa as buscas com o filtro aplicado em cada salto e transmite uma resposta fundamentada com citações quando o parâmetro generateResponse está ativo. Isso se encaixa diretamente em uma interface de chat e oferece baixo tempo até o primeiro token sem que a equipe precise orquestrar recuperação e geração separadamente.

Quando é necessário mais controle — como um prompt customizado por tenant ou um modelo específico — a recomendação é usar a API Retrieve para buscar os fragmentos e chamar a API Converse separadamente, passando o mesmo filtro por usuário.

O histórico de conversa não é persistido entre chamadas pela API. A aplicação precisa armazená-lo em seu próprio repositório (como o DynamoDB) e passar os turnos relevantes em cada requisição. Isso também permite aplicar o mesmo isolamento por usuário ao histórico de conversas.

Boas práticas para operar em escala

• Desacople uploads da ingestão com uma fila. Para cargas baixas, é possível chamar a API de ingestão diretamente do handler de upload. Para qualquer aplicação com uploads concorrentes, use o SQS entre o endpoint de upload e a ingestão. O worker pode empacotar até 10 documentos em cada chamada de IngestKnowledgeBaseDocuments, o que é a principal alavanca de throughput. Por exemplo, 500 uploads simultâneos se transformam em aproximadamente 50 chamadas em lote.
• Planeje para o limite de ingestão, não de recuperação. A API Retrieve suporta picos de 25 consultas por segundo (QPS) ou 10 QPS sustentados por knowledge base — raramente será o gargalo. O throughput de ingestão é adequado para uploads interativos, mas uma migração em massa de um repositório existente vai saturá-lo. Para esses cenários, use o conector S3 com sincronização agendada, que é projetado para cargas grandes de uma vez só.
• Trate o limite de concorrência como condição de retry. Ao exceder o limite, o Bedrock retorna ValidationException, não ThrottlingException. Um classificador de retry que só trata throttling vai interpretar isso como erro fatal e descartar o documento.
• Monitore os sinais que antecipam o teto. Acompanhe a taxa de sucesso da ingestão e o tempo para atingir INDEXED nos percentis P50 e P99. Um tempo crescente para INDEXED é o primeiro indicador de que o pipeline de ingestão está se aproximando do limite de throughput — bem antes de as requisições começarem a falhar.
• Persista o histórico de conversa você mesmo. A API AgenticRetrieveStream aceita turnos anteriores no parâmetro messages para suporte a contexto multi-turno, mas não os persiste entre chamadas. Armazene o histórico em seu próprio repositório e passe os turnos relevantes em cada requisição.

Custos

O custo da solução depende da configuração de modelos escolhida. Com modelos gerenciados, o Managed Knowledge Base é cobrado apenas por armazenamento e recuperação (por chamada, não por token), sem custo adicional de ingestão. Se você selecionar um modelo Amazon Bedrock, paga pelos tokens de embedding na ingestão e pelos tokens de orquestração e geração na recuperação agêntica. Os serviços de suporte (Lambda, API Gateway, SQS, DynamoDB e S3) representam uma fração pequena do custo total em escala moderada. Consulte a página de preços do Amazon Bedrock para os valores atuais.

Como começar

A AWS disponibilizou um repositório de exemplo no GitHub para quem quiser implantar a solução na própria conta e usá-la como base para uma aplicação de chat com documentos. Para se aprofundar no Amazon Bedrock Managed Knowledge Base, a AWS também publicou posts complementares sobre busca empresarial para agentes com Amazon Bedrock Managed Knowledge Base e sobre recuperação agêntica no Amazon Bedrock Managed Knowledge Base.

Fonte

Build multi-tenant agentic chat applications on enterprise data with Amazon Bedrock Managed Knowledge Base (https://aws.amazon.com/blogs/machine-learning/build-multi-tenant-agentic-chat-applications-on-enterprise-data-with-amazon-bedrock-managed-knowledge-base/)

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/)