O problema do escalonamento lento em inferência de IA generativa

Quem trabalha com modelos de IA generativa em produção sabe que o escalonamento rápido é um desafio real. Quando uma aplicação precisa subir novas instâncias para atender picos de demanda, cada segundo de latência importa — e o processo envolve várias etapas sequenciais que consomem tempo considerável.

A Amazon SageMaker AI vem trabalhando sistematicamente para reduzir essa latência em cada etapa do escalonamento: detectar a necessidade de escalar, provisionar instâncias, baixar imagens de contêiner, buscar os pesos do modelo e iniciar os contêineres. Agora, a AWS anuncia mais um avanço nessa jornada: o cache de imagens de contêiner para inferência no SageMaker AI, capaz de reduzir a latência de escalonamento em até 2x para modelos de IA generativa.

O que acontece quando uma nova instância é iniciada

Para entender o impacto do novo recurso, vale entender as etapas que ocorrem quando o SageMaker AI precisa subir uma nova instância durante um evento de escalonamento:

• Provisionamento da instância: uma nova instância do Amazon EC2 (Elastic Compute Cloud) é inicializada.
• Download da imagem do contêiner: a imagem é baixada do Amazon ECR (Elastic Container Registry).
• Download dos artefatos do modelo: os pesos do modelo são buscados no Amazon S3 (Simple Storage Service).
• Inicialização do contêiner e verificações de saúde: o servidor de inferência carrega o modelo na memória e passa pelos testes de prontidão.

Vale notar que o download da imagem do contêiner e o download dos artefatos do modelo acontecem em paralelo. Mesmo assim, o download da imagem do contêiner costuma ser um dos maiores gargalos, especialmente em workloads de IA generativa. Esses workloads utilizam contêineres grandes — como o SageMaker LMI (Large Model Inference, com tecnologia vLLM), vLLM e NVIDIA Triton.

Como o cache de contêiner resolve o gargalo

Com o cache de imagens de contêiner, o SageMaker AI elimina o tempo de download da imagem mesmo quando novas instâncias precisam ser criadas — o cenário onde a solução anterior de cache baseada em instance store não conseguia ajudar.

O exemplo prático divulgado pela AWS ilustra bem o ganho. Usando o modelo Qwen3-8B (16 GB) em uma instância ml.g6.2xlarge com o contêiner LMI (17,7 GB comprimido):

• Antes do cache: download da imagem do ECR levava 333 segundos; download dos artefatos do modelo, 168 segundos. Como as duas operações correm em paralelo, a latência total era de 525 segundos.
• Depois do cache: a imagem já está disponível localmente (0 segundos); o download do modelo cai para 77 segundos — porque agora ele não precisa competir pela largura de banda de rede com o download da imagem. A latência total cai para 258 segundos.

O resultado é uma redução de aproximadamente 51% na latência de inicialização. E se, por algum motivo, a imagem em cache não estiver disponível, o SageMaker AI recorre automaticamente ao download direto do ECR — ou seja, o escalonamento nunca fica bloqueado.

Compatibilidade com inference components

O cache de contêiner também funciona com inference components. Quando múltiplos inference components são implantados, o cache armazena cada imagem de contêiner única referenciada por eles.

O recurso cobre dois padrões comuns de endpoint:

• Endpoints de modelo único: o escalonamento é feito subindo instâncias adicionais, cada uma hospedando sua própria cópia do modelo.
• Endpoints baseados em inference components: novas instâncias são adicionadas apenas quando nenhuma instância existente tem capacidade suficiente para hospedar um inference component adicional.

Isolamento e segurança

O cache de imagens de contêiner mantém as mesmas garantias de isolamento entre tenants que o SageMaker AI já oferece. Cada cache é dedicado a um único endpoint de cliente e não é compartilhado entre contas AWS ou entre endpoints diferentes. Quando um endpoint é excluído, o cache de imagens associado é automaticamente removido.

Resultados observados em clientes reais

A AWS compartilhou resultados de clientes que testaram o recurso em acesso antecipado. Os dados mostram melhorias expressivas na latência P50 (mediana) de escalonamento:

• Cliente 1 — instância ml.g4dn.xlarge, imagem de 15,7 GB, modelo de 0 GB: de 381s para 134s (-65%)
• Cliente 2 — instância ml.g5.2xlarge, imagem de 17,5 GB, modelo de 5,8 GB: de 346s para 164s (-52%)
• Cliente 3 — instância ml.g5.xlarge, imagem de 10,6 GB, modelo de 6,5 GB: de 346s para 216s (-38%)

A magnitude da melhoria varia conforme o tipo de instância, o tamanho da imagem do contêiner e o tamanho do modelo.

As três otimizações de auto scaling combinadas

O cache de contêiner é o terceiro recurso de uma série de otimizações de auto scaling que a AWS vem lançando para o SageMaker AI. Cada um remove uma fonte diferente de atraso no escalonamento:

• Métricas sub-minuto: as métricas sub-minuto do Amazon CloudWatch detectam a necessidade de escalonamento até 6x mais rápido que os mecanismos tradicionais. Para ativar, configure uma política de rastreamento de alvo com ConcurrentRequestsPerModel ou ConcurrentRequestsPerCopy.
• Cache de dados para inference components: a solução de cache de dados para inference components reduz o tempo de download de imagem ao adicionar cópias de modelos em instâncias já em execução. Não exige configuração manual — ativa automaticamente para endpoints baseados em inference components em tipos de instância aceleradora suportados.
• Cache de imagem de contêiner (novo): elimina o tempo de download da imagem ao subir novas instâncias. Também ativa automaticamente para qualquer endpoint que use tipos de instância aceleradora suportados.

Juntas, essas três camadas cobrem diferentes eixos do escalonamento. As métricas sub-minuto detectam a demanda mais cedo, disparando decisões de escalonamento em segundos. O cache de dados para inference components atua quando uma nova cópia do modelo é alocada em uma instância já existente. O cache de imagem de contêiner entra em ação quando é necessário subir uma instância completamente nova.

Configurações suportadas e disponibilidade

O cache de contêiner é suportado para tipos de instância aceleradora nos endpoints de inferência do SageMaker AI. Funciona com qualquer imagem de contêiner hospedada no Amazon ECR, incluindo imagens customizadas — sem necessidade de modificar o contêiner.

O recurso está disponível em todas as regiões comerciais da AWS onde a inferência do SageMaker AI é suportada. Para a lista atualizada de tipos de instância e regiões, consulte a documentação do Amazon SageMaker AI.

Como começar

Para aproveitar o cache de contêiner, basta implantar os workloads de IA generativa em um endpoint de inferência do SageMaker AI em um tipo de instância aceleradora suportado. O cache de contêiner ativa automaticamente — sem nenhuma configuração adicional. É possível criar ou atualizar endpoints diretamente pelo Console de Gerenciamento da AWS. Para mais detalhes sobre tipos de instância e regiões suportadas, consulte a documentação do Amazon SageMaker AI.

Conclusão

Com o cache de imagens de contêiner, o SageMaker AI completa um conjunto de otimizações de auto scaling voltadas especificamente para inferência de IA generativa. A combinação das três camadas — métricas sub-minuto, cache de dados para inference components e cache de imagem de contêiner — transforma o comportamento de escalonamento: o que antes levava minutos de latência de cold start passa a ser uma resposta rápida e previsível. Para aplicações de IA generativa que precisam lidar com picos de tráfego sem degradar a experiência do usuário, essa evolução é bastante relevante.

Fonte

Introducing container caching in Amazon SageMaker AI for faster model scaling (https://aws.amazon.com/blogs/machine-learning/introducing-container-caching-in-amazon-sagemaker-ai-for-faster-model-scaling/)

Quando saber que falhou não é suficiente

Detectar que um agente de IA falhou em produção é apenas o começo do problema. A pergunta mais difícil — e mais custosa — é entender por que ele falhou e o que precisa ser corrigido. Ferramentas tradicionais de avaliação entregam métricas como “esse agente atingiu 60% de taxa de conclusão de objetivos”, mas deixam a equipe revisando manualmente centenas de passos de execução para descobrir o que deu errado.

Para times que operam agentes em escala, essa inspeção manual vira um gargalo real: o tempo entre detectar um problema e publicar uma correção se estende desnecessariamente. É para resolver isso que a AWS introduziu os Detectors no Strands Evals SDK — uma camada de automação que identifica falhas nas execution traces dos agentes e realiza análise de causa raiz, reduzindo o tempo de diagnóstico de horas para minutos.

Os Detectors complementam o framework de avaliação apresentado em um post anterior, respondendo não apenas “o agente foi bem?” mas também “por que ele falhou e o que devo corrigir?”

Por que métricas sozinhas não resolvem

O Strands Evals já oferece sinais de qualidade confiáveis por meio de Cases, Experiments e Evaluators: taxas de sucesso de objetivos, precisão na seleção de ferramentas e pontuações de utilidade. Esses indicadores são essenciais para detectar regressões e entender o desempenho em nível estatístico.

Mas considere o que acontece depois de identificar uma regressão. A taxa de sucesso do agente cai de 85% para 70% após um deploy ou após mudanças no prompt ou nas ferramentas. Os Evaluators confirmam a queda. E agora? É preciso identificar quais comportamentos específicos causaram as falhas, separar causas raiz de sintomas secundários, determinar se a correção pertence ao system prompt ou às definições de ferramentas, e priorizar pelo impacto.

Esse fluxo de diagnóstico tradicionalmente exige que engenheiros seniores inspecionem traces span por span e correlacionem falhas ao longo de centenas de passos — um processo que simplesmente não escala. Os Detectors automatizam esse fluxo. Enquanto os Evaluators respondem “o agente foi bem?” produzindo pontuações por caso, os Detectors respondem “por que falhou?” produzindo diagnósticos por span, com falhas categorizadas, cadeias causais e recomendações de correção.

Como os Detectors funcionam

O pipeline de detecção opera em duas fases, ambas alimentadas por análise baseada em LLM (Modelo de Linguagem de Grande Escala) sobre a execution trace. Para entender melhor os conceitos de sessões, traces e spans de agentes, a AWS disponibiliza a documentação Understand observability for agentic resources in Amazon Bedrock AgentCore.

Fase 1 — Detecção de falhas: varre cada span de uma sessão contra uma taxonomia abrangente de falhas organizada em nove categorias principais: alucinação, ações incorretas, erros de orquestração, não conformidade com instruções de tarefa, erros de execução, erros de manipulação de contexto, comportamento repetitivo, problemas de saída do LLM e incompatibilidade de configuração. Para cada falha identificada, o sistema retorna a localização do span, uma ou mais categorias, um score de confiança e evidências extraídas da trace.

Fase 2 — Análise de causa raiz: recebe as falhas detectadas e traça cadeias causais entre elas. Um único erro upstream frequentemente se propaga em múltiplas falhas downstream. A análise de causa raiz separa causas de sintomas, classifica a causalidade de cada falha (PRIMARY, SECONDARY ou TERTIARY), determina o impacto de propagação e gera recomendações de correção categorizadas pelo local onde a correção deve ser feita: system prompt, descrição de ferramenta ou outro.

Ambas as fases lidam com sessões de tamanhos variados por meio de uma estratégia em camadas: análise direta para sessões que cabem na janela de contexto do modelo Detector selecionado; pruning de caminhos de falha que retém apenas spans ancestrais e descendentes para sessões moderadamente grandes; e análise em chunks com merge para sessões muito grandes, que divide a trace em janelas sobrepostas e reconcilia os resultados.

Pré-requisitos

Para acompanhar os exemplos práticos, são necessários: Python 3.10 ou superior; Strands Evals SDK instalado com pip install strands-agents-evals; acesso habilitado a modelos no Amazon Bedrock (os Detectors usam análise baseada em LLM); e, para os exemplos com Amazon CloudWatch, credenciais AWS configuradas com as permissões logs:StartQuery e logs:GetQueryResults.

Detecção de falhas na prática

Os exemplos a seguir usam uma trace de sessão de um assistente de pesquisa em drug discovery apresentado no post Evaluating AI agents for production: A practical guide to Strands Evals. O agente foi construído com Strands Agents e Amazon Bedrock. Para acompanhar, é necessário rodar o agente com rastreamento OpenTelemetry habilitado e exportar a sessão como JSON. Consulte a documentação de User Simulation no Strands Agents SDK para configurar o rastreamento e exportar sessões.

A função detect_failures recebe um objeto Session (o formato padrão de trace no Strands Evals) e retorna falhas estruturadas. Cada falha inclui o span onde ocorreu, uma ou mais categorias da taxonomia, um score de confiança e evidências extraídas da trace:

import json
from strands_evals.detectors import detect_failures
from strands_evals.types.trace import Session
from strands_evals.detectors import ConfidenceLevel

with open("agent_trace.json") as f:
    session = Session.model_validate_json(f.read())

result = detect_failures(session, confidence_threshold=ConfidenceLevel.MEDIUM)

for failure in result.failures:
    for cat, conf, ev in zip(failure.category, failure.confidence, failure.evidence):
        print(f"[{conf}] {cat} at span {failure.span_id}")
        print(f"  Evidence: {ev}")

O exemplo abaixo mostra a saída de um agente de pesquisa que recebeu a tarefa “Research the impact of energy requirements for powering AI in the real world” e encontrou problemas progressivos de configuração de ferramentas:

[0.9] execution-error-category-tool-schema at span f503a7d546fa4157
  Evidence: Tool execution failed due to missing required parameter 'knowledgeBaseId'. Error: 'Parameter validation failed: Invalid type for parameter knowledgeBaseId, value: None'

[0.75] hallucination-category-hall-usage at span 0466979670d14099
  Evidence: Agent claims 'I don't have access to the specific knowledge base needed' and then proceeds to provide detailed information about AI energy requirements 'based on general knowledge' without using any tools.

[0.9] orchestration-related-errors-category-goal-deviation at span d98d578e61233d33
  Evidence: Agent completely abandons the original task about AI energy requirements and instead provides a lengthy response about marine biology, stating 'I'm going to pivot to discuss marine biology instead.'

Em uma única passagem, o Detector identifica falhas em múltiplos níveis: erros de execução (validação de parâmetro de ferramenta), problemas semânticos (alucinação a partir de “conhecimento geral”) e problemas de orquestração (desvio completo do objetivo). Um único span pode apresentar múltiplas categorias de falha, cada uma com confiança e evidência independentes.

Análise de causa raiz

Identificar falhas é útil, mas entender por que elas aconteceram é o que direciona as correções. A função analyze_root_cause recebe as falhas detectadas, traça cadeias causais entre elas, separa causas raiz de sintomas downstream e recomenda onde cada correção deve ser aplicada. Se as falhas não forem fornecidas, a função executa a detecção automaticamente.

from strands_evals.detectors import detect_failures, analyze_root_cause

failures = detect_failures(session)
rca_result = analyze_root_cause(session, failures=failures.failures)

for rc in rca_result.root_causes:
    print(f"Causality: {rc.causality}")
    print(f"  Span: {rc.failure_span_id} | Fix type: {rc.fix_type}")
    print(f"  Root cause: {rc.root_cause_explanation}")
    print(f"  Recommendation: {rc.fix_recommendation}")

Continuando com a mesma sessão do agente de pesquisa, a análise de causa raiz revela a estrutura causal:

Causality: PRIMARY_FAILURE
  Span: f503a7d546fa4157 | Fix type: TOOL_DESCRIPTION_FIX
  Root cause: Agent called retrieve tool without required knowledgeBaseId parameter because tool description does not clearly document that knowledgeBaseId is mandatory. This caused parameter validation failure and forced agent into multiple retry attempts with different parameter combinations.
  Recommendation: Update retrieve tool description to explicitly mark knowledgeBaseId as a required parameter with clear documentation including format constraints and example values.

Causality: SECONDARY_FAILURE
  Span: 0466979670d14099 | Fix type: SYSTEM_PROMPT_FIX
  Root cause: Agent fabricated detailed AI energy consumption information claiming it is 'based on general knowledge' after all retrieval attempts failed, because system prompt lacks instruction prohibiting generation of factual content without tool-retrieved evidence.
  Recommendation: Add instruction to system prompt requiring agent to explicitly acknowledge inability to complete research tasks when retrieval tools fail, and prohibit generating detailed factual content without tool-verified sources.

A distinção entre tipos de correção é o que torna a análise de causa raiz acionável. O erro de schema da ferramenta é um TOOL_DESCRIPTION_FIX porque o parâmetro knowledgeBaseId da ferramenta de recuperação não está documentado claramente. A alucinação downstream é um SYSTEM_PROMPT_FIX por falta de instruções sobre como lidar com falhas persistentes de ferramentas. Corrigir apenas uma categoria deixa a outra sem solução.

Diagnóstico integrado com diagnose_session

Para conveniência, a função diagnose_session executa as duas fases como um único pipeline — detecção de falhas seguida de análise de causa raiz — e retorna um DiagnosisResult unificado com recomendações deduplicadas:

from strands_evals.detectors import diagnose_session, ConfidenceLevel

result = diagnose_session(session, confidence_threshold=ConfidenceLevel.MEDIUM)

print(f"Found {len(result.failures)} failures, {len(result.root_causes)} root causes")
for rec in result.recommendations:
    print(f"  - {rec}")

Com uma única chamada de função, obtém-se uma lista priorizada de mudanças concretas categorizadas pelo local onde devem ser aplicadas.

Integração com pipelines de avaliação

Os Detectors ganham ainda mais valor quando integrados ao fluxo de avaliação existente. O DiagnosisConfig anexa diagnóstico automatizado a qualquer experimento, de forma que cada caso de teste com falha produza automaticamente um diagnóstico:

from strands_evals import Experiment
from strands_evals.evaluators import GoalSuccessRateEvaluator
from strands_evals.detectors import ConfidenceLevel, DiagnosisConfig, DiagnosisTrigger
from strands_evals.types.evaluation_report import EvaluationReport

experiment = Experiment(
    cases=test_cases,
    task_function=my_agent_task,
    evaluators=[GoalSuccessRateEvaluator()],
    diagnosis_config=DiagnosisConfig(
        trigger=DiagnosisTrigger.ON_FAILURE,
        confidence_threshold=ConfidenceLevel.MEDIUM
    ),
)

report = experiment.run()
report.display(include_recommendations=True)

Dois modos de trigger estão disponíveis. ON_FAILURE (padrão) executa o diagnóstico apenas quando pelo menos um avaliador retorna test_pass=False, mantendo os custos de LLM proporcionais às taxas de falha — ideal para detecção de regressões em pipelines de Integração Contínua e Entrega Contínua (CI/CD). ALWAYS executa o diagnóstico em todos os casos independentemente do resultado, útil para identificar caminhos subótimos em casos que nominalmente passam.

Atenção aos custos: a execução dos Detectors usa inferência do Amazon Bedrock para análise baseada em LLM, o que gera cobranças. Consulte a tabela de preços do Amazon Bedrock para detalhes. O armazenamento de logs no Amazon CloudWatch também gera cobranças — consulte os preços do Amazon CloudWatch. Monitore o uso no AWS Cost Explorer, especialmente ao integrar Detectors em pipelines de CI/CD com execuções frequentes.

Diagnóstico de sessões em produção via CloudWatch

Os exemplos anteriores usam arquivos de sessão locais, mas em produção as traces do agente ficam no Amazon CloudWatch Logs, exportadas com OpenTelemetry. O CloudWatchProvider busca traces diretamente do Amazon CloudWatch e os converte em objetos Session prontos para análise com os Detectors:

from strands_evals.providers import CloudWatchProvider
from strands_evals.detectors import diagnose_session, ConfidenceLevel

provider = CloudWatchProvider(agent_name="my-research-agent", region="us-east-1")
data = provider.get_evaluation_data(session_id="abc-123-def-456")
session = data["trajectory"]

result = diagnose_session(session, confidence_threshold=ConfidenceLevel.MEDIUM)

for rc in result.root_causes:
    print(f"[{rc.fix_type}] {rc.fix_recommendation}")

Por baixo dos panos, o provider consulta o Amazon CloudWatch Logs Insights por registros OTEL correspondentes ao ID de sessão, detecta automaticamente o framework do agente (Strands, LangChain ou outros) a partir dos metadados dos spans e mapeia os spans para uma Session padronizada. Os Detectors funcionam com qualquer framework que exporte traces OpenTelemetry para o Amazon CloudWatch — não apenas com Strands Agents. Também é possível recuperar traces do Langfuse ou OpenSearch usando LangfuseProvider ou OpenSearchProvider.

Boas práticas

• Comece com confiança MEDIUM. O threshold LOW captura mais problemas potenciais, mas com mais ruído — útil para investigação profunda de um caso específico. MEDIUM oferece boa relação sinal/ruído para uso rotineiro. Reserve HIGH para monitoramento em produção onde apenas achados de alta certeza são desejados.
• Use ON_FAILURE em CI/CD e ALWAYS para auditorias periódicas. ON_FAILURE mantém os custos de LLM proporcionais às taxas de falha, tornando-o prático para cada execução de teste. Agende execuções no modo ALWAYS semanalmente ou por release para capturar comportamentos subótimos em casos que passam.
• Corrija falhas PRIMARY primeiro. Falhas secundárias e terciárias frequentemente se resolvem quando a causa raiz é endereçada. Antes de implementar múltiplas recomendações, verifique se corrigir a falha primária elimina as downstream.
• Agrupe recomendações por tipo de correção. Agrupe mudanças de TOOL_DESCRIPTION_FIX juntas e de SYSTEM_PROMPT_FIX juntas. Isso torna o impacto de cada categoria de mudança independentemente mensurável ao re-executar a avaliação.
• Passe falhas pré-detectadas para analyze_root_cause. Se você já executou detect_failures e quer inspecionar os resultados antes de rodar a análise de causa raiz, passe-os diretamente para evitar detecção redundante:

failures = detect_failures(session)
# ... inspect or filter failures ...
rca = analyze_root_cause(session, failures=failures.failures)

• Use a sessão de teste para experimentação. O arquivo flawed_session.json usado nos exemplos está disponível na suite de testes do Strands Evals para você testar os Detectors localmente.

Limpeza de recursos

As funções dos Detectors em si não provisionam recursos AWS persistentes. No entanto, se você configurou exportação de traces do agente para o Amazon CloudWatch Logs, vale revisar dois pontos: os log groups do CloudWatch (excluir um log group remove permanentemente todos os dados de log — confirme que exportou o que precisa antes de prosseguir); e o acesso a modelos no Amazon Bedrock (se habilitou o acesso apenas para este walkthrough, revogue-o pelo console do Amazon Bedrock em Model access).

Conclusão

Os Detectors do Strands Evals fecham o ciclo entre medir a qualidade de um agente e melhorá-la. Ao automatizar a detecção de falhas e a análise de causa raiz que antes exigiam inspeção manual de traces, as equipes passam de “o teste falhou” para “aqui está o que corrigir” em minutos, não horas.

Para começar, consulte a documentação de Detectors do Strands Evals SDK e o repositório GitHub do Strands Evals. Experimente o arquivo de trace de exemplo incluído e adicione o DiagnosisConfig a um caso de teste existente no seu pipeline de avaliação para ver o diagnóstico automatizado em ação.

Fonte

AI Agent Failure Detection and Root Cause Analysis with Strands Evals (https://aws.amazon.com/blogs/machine-learning/ai-agent-failure-detection-and-root-cause-analysis-with-strands-evals/)

Família Gemma 4 disponível no Amazon Bedrock

A AWS anunciou a chegada da família Gemma 4 ao Amazon Bedrock. Desenvolvidos pelo Google DeepMind e lançados sob a licença Apache 2.0, esses modelos open-weight foram projetados com foco em inteligência por parâmetro, cobrindo diferentes perfis de custo e latência. A família chega com três variantes ajustadas para instrução: Gemma 4 31B, Gemma 4 26B-A4B e Gemma 4 E2B.

Os benchmarks independentes reforçam esse posicionamento: a Artificial Analysis registra um Índice de Inteligência de 39 para o Gemma 4 31B — bem acima da mediana de 15 na classe de modelos open-weight entre 4B e 40B parâmetros.

Ao rodar esses modelos no Amazon Bedrock, toda a inferência acontece dentro da infraestrutura gerenciada pela AWS, com os controles de segurança e privacidade do serviço. Os prompts e respostas não são usados para treinar modelos, e o conteúdo não é compartilhado com terceiros.

Capacidades principais da família Gemma 4

Todas as variantes da família compartilham um conjunto comum de funcionalidades:

• Modo de raciocínio integrado: o modelo emite seu processo interno de pensamento antes de gerar a resposta final.
• Chamada nativa de funções: suporte direto a fluxos agênticos sem necessidade de camadas adicionais.
• Entrada multimodal: aceita texto e imagem em todas as variantes.
• Suporte multilíngue: mais de 35 idiomas prontos para uso, com pré-treinamento em mais de 140.
• Janela de contexto: até 256K tokens no 31B e no 26B-A4B; 128K tokens no E2B.

Por serem open-weight, é possível avaliar a arquitetura e a metodologia de treinamento de forma independente, realizar benchmarks com dados próprios e aplicar fine-tuning em dados proprietários quando necessário. Para a lista atualizada de modelos suportados, consulte o catálogo de modelos do Amazon Bedrock.

Comparativo entre as variantes

A tabela abaixo resume as especificações de cada modelo:

• Gemma 4 31B — ID: google.gemma-4-31b | Arquitetura densa | 30,7B parâmetros | Contexto: 256K tokens
• Gemma 4 26B-A4B — ID: google.gemma-4-26b-a4b | Mistura de especialistas (MoE) | 25,2B total / 3,8B ativos | Contexto: 256K tokens
• Gemma 4 E2B — ID: google.gemma-4-e2b | Densa com Embeddings por Camada (PLE) | 5,1B total / 2,3B efetivos | Contexto: 128K tokens

Para escolher a variante certa:

• Cargas com raciocínio ou codificação intensivos → Gemma 4 31B
• Alta taxa de requisições com sensibilidade a custo → Gemma 4 26B-A4B (custo e latência próximos a um modelo 4B, com capacidade de conhecimento de um modelo muito maior)
• Baixa latência ou classificação multimodal leve → Gemma 4 E2B (recomenda-se usar reasoning_effort=high nessa variante)

Para detalhes de arquitetura, consulte o model card do Gemma 4.

Acessando os modelos via endpoint bedrock-mantle

Os modelos Gemma 4 são acessados pelo endpoint bedrock-mantle, a interface pública do novo motor de inferência de próxima geração do Amazon Bedrock. A URL base é:

https://bedrock-mantle.{region}.api.aws/openai/v1

Esse endpoint expõe as APIs de Chat Completions e Responses, com interface compatível com os SDKs Python e TypeScript da OpenAI. Para quem já usa esses SDKs, a migração geralmente exige apenas atualizar a URL base e o ID do modelo. Para entender a arquitetura de isolamento e acesso zero do motor de inferência subjacente, veja o post Explorando o design de acesso zero do motor de inferência de próxima geração do Amazon Bedrock.

Pré-requisitos

Para usar os modelos Gemma 4, é necessário ter uma conta AWS com permissões para executar inferência no endpoint bedrock-mantle. A forma mais simples é anexar a política gerenciada AmazonBedrockMantleInferenceAccess ao seu principal do Controle de Identidade e Acesso (IAM). Para criar e gerenciar chaves de API, consulte a documentação de chaves de API do Amazon Bedrock.

Playground no console

O console do Amazon Bedrock oferece um playground de chat/texto para testar os modelos sem escrever código. Basta navegar até Test playgrounds → Chat/Text playground, selecionar o modelo desejado na categoria Google e clicar em Apply.

Chamada via SDK da OpenAI

O exemplo abaixo usa o SDK Python da OpenAI como cliente para chamar o endpoint bedrock-mantle. Para workloads em produção, recomenda-se usar chaves de API de curto prazo, que expiram automaticamente em até 12 horas. O pacote aws-bedrock-token-generator gera um bearer token de curto prazo a partir de credenciais AWS nativas.

from openai import OpenAI

client = OpenAI(
    api_key="",
    base_url="https://bedrock-mantle.us-east-1.api.aws/openai/v1",
)

response = client.chat.completions.create(
    model="google.gemma-4-31b",
    messages=[
        {"role": "user", "content": "Explain the benefits of mixture-of-experts architectures for production inference."}
    ],
    max_tokens=512,
)

print(response.choices[0].message.content)

Atenção: em produção, armazene e recupere credenciais a partir de um serviço gerenciado de segredos, como o AWS Secrets Manager ou o AWS Systems Manager Parameter Store, em vez de variáveis de ambiente. Para controlar permissões de geração e uso de chaves, consulte Controle de permissões para chaves de API do Amazon Bedrock.

Entrada multimodal (imagem)

O endpoint aceita imagens como data URLs em base64 ou como URLs do Amazon S3 (s3://). URLs públicas https:// arbitrárias não são suportadas. Para melhores resultados, posicione o conteúdo de imagem antes do texto no prompt.

import base64

# Read a local image file and encode it as a base64 data URL.
with open("chart.png", "rb") as image_file:
    image_b64 = base64.b64encode(image_file.read()).decode("utf-8")

data_url = f"data:image/png;base64,{image_b64}"

response = client.chat.completions.create(
    model="google.gemma-4-31b",
    messages=[{
        "role": "user",
        "content": [
            {"type": "image_url", "image_url": {"url": data_url}},
            {"type": "text", "text": "Describe the trend shown in this chart."}
        ]
    }],
)

print(response.choices[0].message.content)

Streaming de respostas

stream = client.chat.completions.create(
    model="google.gemma-4-31b",
    messages=[
        {"role": "user", "content": "Write a short poem about distributed systems."}
    ],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

print()

Chamada de ferramentas (tool calling)

import json
from openai import OpenAI

client = OpenAI(
    api_key="",
    base_url="https://bedrock-mantle.us-east-1.api.aws/openai/v1",
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a given location",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "City and country (e.g., Seattle, US)"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "Temperature unit"
                    }
                },
                "required": ["location"]
            }
        }
    }
]

# Step 1: Send the user request with tool definitions
messages = [
    {"role": "user", "content": "What's the weather like in Seattle?"}
]

response = client.chat.completions.create(
    model="google.gemma-4-31b",
    messages=messages,
    tools=tools,
    tool_choice="auto",
)

assistant_message = response.choices[0].message

# Step 2: Check if the model wants to call a tool
if assistant_message.tool_calls:
    messages.append(assistant_message)
    for tool_call in assistant_message.tool_calls:
        function_name = tool_call.function.name
        arguments = json.loads(tool_call.function.arguments)

        # Step 3: Validate the function name and run it (your implementation)
        if function_name == "get_weather":
            location = arguments.get("location", "Unknown")
            unit = arguments.get("unit", "fahrenheit")
            result = {
                "location": location,
                "temperature": 18 if unit == "celsius" else 64,
                "unit": unit,
                "condition": "Partly cloudy",
                "humidity": 72,
            }
        else:
            result = {"error": f"Unknown function: {function_name}"}

        # Step 4: Return the function result to the model
        messages.append({
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": json.dumps(result),
        })

    # Step 5: Get the final response incorporating tool results
    final_response = client.chat.completions.create(
        model="google.gemma-4-31b",
        messages=messages,
        tools=tools,
    )
    print(final_response.choices[0].message.content)
else:
    print(assistant_message.content)

API de Respostas e modo de raciocínio

Além do Chat Completions, o endpoint bedrock-mantle suporta a API de Respostas da OpenAI, indicada para geração em turno único ou quando se deseja acessar o raciocínio do modelo.

response = client.responses.create(
    model="google.gemma-4-31b",
    input="Explain the benefits of mixture-of-experts architectures for production inference.",
    max_output_tokens=512,
)

print(response.output_text)

Para ativar o modo de raciocínio, utilize o parâmetro reasoning na API de Respostas. O processo de pensamento é retornado como um item separado no output:

response = client.responses.create(
    model="google.gemma-4-31b",
    input="If a train leaves at 3pm at 60 km/h and another leaves an hour later at 90 km/h from the same station, when does the second catch up?",
    reasoning={"effort": "high"},
)

# Final answer.
print(response.output_text)

# The thought process is returned as a separate output item of type "reasoning".
for item in response.output:
    if item.type == "reasoning":
        for block in item.content:
            print(block.text)

O valor de effort pode ser low, medium ou high. Para conversas em múltiplos turnos, envie de volta apenas as respostas finais — não inclua os itens de raciocínio no histórico enviado ao modelo na próxima rodada. Para o Gemma 4 E2B, recomenda-se definir reasoning_effort como high.

Os parâmetros de amostragem recomendados para todos os modelos Gemma 4 são temperature=1.0 e top_p=0.95, que funcionam bem tanto no modo de raciocínio quanto fora dele.

Camadas de serviço disponíveis

O Amazon Bedrock oferece três camadas (tiers) para atender diferentes perfis de workload:

• Priority: para workloads críticos e voltados ao usuário final que exigem os menores tempos de resposta. Oferece até 25% mais tokens de saída por segundo (OTPS) em comparação ao Standard, com prioridade de processamento. Não exige reserva ou compromisso antecipado.
• Standard: para tarefas cotidianas de IA como geração de conteúdo, análise de texto e processamento de documentos. Desempenho consistente com precificação padrão por demanda. Camada padrão quando nenhuma é especificada.
• Flex: para workloads que toleram maior latência, como avaliações de modelos, sumarização e fluxos agênticos. Preço com desconto em relação ao Standard, mas com maior latência em períodos de pico.

Para detalhes de preço por camada e modelo, consulte a página de preços do Amazon Bedrock. Para disponibilidade de camadas por modelo, acesse o catálogo de modelos do Amazon Bedrock.

Escalabilidade e boas práticas em produção

A inferência por demanda no bedrock-mantle não possui cota de requisições por minuto (RPM). O controle é feito por cotas de tokens por minuto (input e output separados). Como os modelos Gemma 4 não têm cotas publicadas no console do Service Quotas, utilize lógica de retry com backoff exponencial para lidar com throttling transitório. Para detalhes, consulte as cotas do endpoint bedrock-mantle.

O SDK da OpenAI oferece suporte nativo a retries com backoff exponencial via parâmetro max_retries:

from openai import OpenAI

# Retry transient failures with exponential backoff.
client = OpenAI(
    api_key="",
    base_url="https://bedrock-mantle.us-east-1.api.aws/openai/v1",
    max_retries=6,
)

Dois códigos de erro HTTP merecem atenção especial:

• HTTP 429: cota de tokens por minuto excedida. Reduza a taxa de envio e faça retry com backoff; solicite aumento de cota via AWS Support se o limite for atingido com frequência.
• HTTP 503: pressão na capacidade regional para o modelo. Faça retry com backoff para respostas ocasionais; reduza a taxa de envio para respostas sustentadas.

Para aumentos bruscos de tráfego, a recomendação é escalar em incrementos graduais: se encontrar erros 503, reduza a taxa em 50% até estabilizar, mantenha por 15 minutos e então aumente 50% a cada etapa até atingir o volume alvo.

Outras boas práticas para escala em produção:

• Distribua workloads grandes ao longo de vários minutos, evitando rajadas concentradas.
• Ao migrar tráfego para uma nova versão de modelo, use feature flags para rampar gradualmente.
• Roteie trabalhos assíncronos (avaliações, sumarização, backfills agênticos) para a camada Flex.
• Para workloads sem requisitos de residência de dados, distribua entre múltiplas regiões AWS.
• Planeje headroom de duas a três vezes o pico esperado como buffer para surtos de tráfego.

Para orientações completas, consulte as boas práticas de escalabilidade e throughput no Amazon Bedrock User Guide.

Cache implícito de prompts

Os modelos Gemma 4 no Amazon Bedrock suportam cache implícito de prompts, habilitado automaticamente. Requisições consecutivas que compartilham um prefixo de prompt comum podem resultar em cache hit, reduzindo a latência de inferência nos tokens correspondentes sem necessidade de alterações no código. O recurso está disponível em todas as camadas de serviço (Standard, Priority e Flex). Posicionar conteúdo estático no início do prompt e conteúdo dinâmico no final maximiza as chances de cache hit.

Disponibilidade e preços

No lançamento, os modelos Gemma 4 estão disponíveis em quatro regiões AWS: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon) e Europa (Frankfurt). Para a lista atualizada, consulte o catálogo de modelos do Amazon Bedrock. A precificação é por token e varia conforme o modelo e a camada de serviço; para valores atuais, acesse a página de preços do Amazon Bedrock.

Próximos passos

Para começar a usar os modelos Gemma 4 no Amazon Bedrock:

• Acesse o console do Amazon Bedrock e experimente o Gemma 4 no playground de Chat/Texto.
• Execute os exemplos Python deste post com seus próprios dados.
• Avalie as variantes 31B, 26B-A4B e E2B nos seus workloads para escolher o perfil de custo e latência ideal.
• Para deploy em produção, revise as boas práticas de escalabilidade e throughput e considere a camada Priority para tráfego sensível a latência.

Recursos adicionais:

• Documentação do Amazon Bedrock
• Model card do Gemma 4 (Google)
• Blog de lançamento do Gemma 4 (Google)
• Gemma 4 no Hugging Face
• Proteção de dados no Amazon Bedrock
• Design de acesso zero do motor de inferência de próxima geração do Amazon Bedrock
• Endpoints do Amazon Bedrock
• Camadas de serviço do Amazon Bedrock
• Chaves de API do Amazon Bedrock
• Preços do Amazon Bedrock
• Artificial Analysis: Gemma 4 31B

Fonte

Introducing Gemma 4 models on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/introducing-gemma-4-models-on-amazon-bedrock/)

O problema de profundidade versus contexto em agentes de IA

Um desafio recorrente em fluxos de trabalho de pesquisa com Inteligência Artificial (IA) é o equilíbrio entre profundidade e contexto. Quando um agente lê dez páginas da web, a janela de contexto — a quantidade de texto que um Modelo de Linguagem Grande (LLM, do inglês Large Language Model) consegue processar de uma vez — fica saturada com conteúdo bruto. Se o agente também executa análise de dados, a lógica de geração de gráficos compete com o raciocínio estratégico pelo espaço disponível.

A saída tradicional para esse problema costuma ser encadeamento manual de prompts ou processamento sequencial. A AWS apresentou uma abordagem mais eficiente: delegar o trabalho aprofundado a subagentes isolados que retornam apenas resultados concisos. É exatamente esse o papel do LangChain Deep Agents, que cuida da orquestração, criando subagentes efêmeros especializados e gerenciando seu ciclo de vida.

Para prover a infraestrutura que cada subagente precisa, entra em cena o Amazon Bedrock AgentCore. Ele oferece um browser real dentro de uma MicroVM (Máquina Virtual Micro, do inglês MicroVM — uma máquina virtual leve e de propósito único) para pesquisa na web, além de um ambiente Python completo para análise de dados. O AgentCore também está disponível como provedor nativo de sandbox na CLI do Deep Agents, permitindo experimentar o CodeInterpreter do AgentCore com o simples comando deepagents --sandbox agentcore, sem precisar construir um agente completo.

O que você vai construir

O exemplo apresentado pela AWS é um agente de pesquisa competitiva que demonstra o padrão de ponta a ponta. O fluxo funciona assim:

• O agente coordenador recebe a solicitação e consulta o AgentCore Memory em busca de insights de pesquisas anteriores.
• Em seguida, ele dispara três subagentes de browser em paralelo, cada um navegando no site de um concorrente diferente dentro da sua própria MicroVM do AgentCore Browser.
• Quando os três retornam com os dados estruturados, um subagente analista recebe o conjunto combinado e usa o AgentCore Code Interpreter para gerar um gráfico comparativo e um relatório em markdown.
• Por fim, os principais insights são salvos no AgentCore Memory para uso em sessões futuras.

Todo o fluxo pode ser rastreado pelo Amazon CloudWatch via Amazon Bedrock AgentCore Observability ou pelo LangSmith. Cada tipo de subagente acessa apenas seu conjunto específico de ferramentas: ferramentas de browser para os pesquisadores, ferramentas de interpretação para o analista e ferramentas de memória para o coordenador.

Como construir o agente passo a passo

A construção envolve configurar um modelo, criar toolkits para cada tipo de subagente e conectar tudo com o LangChain Deep Agents.

Pré-requisitos

• Uma conta AWS com acesso ao Amazon Bedrock AgentCore habilitado
• Credenciais AWS configuradas como variáveis de ambiente (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION) ou via perfil do AWS CLI
• Python 3.11 ou superior com pip ou uv para instalação de pacotes
• (Opcional) Amazon CloudWatch Transaction Search habilitado para visualizar traces e spans do AgentCore Observability
• (Opcional) Uma conta LangSmith para observabilidade
• (Opcional) Um recurso de AgentCore Memory com ao menos uma estratégia de extração configurada
• (Opcional) Um notebook Jupyter executável no repositório de amostras langchain-aws para a implementação completa

Passo 1: Configurar o modelo

O código abaixo configura o LLM que orquestra o agente. O exemplo acessa o Claude Sonnet pelo Amazon Bedrock:

from langchain_aws import ChatBedrockConverse
from langchain_aws.tools import create_browser_toolkit, create_code_interpreter_toolkit
from deepagents import create_deep_agent
from botocore.config import Config as BotoConfig

model = ChatBedrockConverse(
    model="us.anthropic.claude-sonnet-4-6",
    region_name="us-west-2",
    config=BotoConfig(read_timeout=300),
)

O prefixo us. utiliza um perfil de inferência entre regiões para maior disponibilidade. Também é possível usar o ID do modelo base diretamente.

Passo 2: Criar os toolkits de browser

Cada concorrente recebe seu próprio BrowserToolkit, que provisiona sua própria MicroVM do AgentCore Browser, garantindo isolamento completo entre os pesquisadores paralelos. O toolkit gerencia a concorrência quando o LLM emite múltiplas chamadas de ferramenta de browser em um único turno:

COMPETITORS = [
    ("GitHub", "https://github.com/pricing"),
    ("GitLab", "https://about.gitlab.com/pricing"),
    ("Bitbucket", "https://www.atlassian.com/software/bitbucket/pricing"),
]

toolkits_to_cleanup = []
research_subagents = []

for company_name, company_url in COMPETITORS:
    browser_toolkit, browser_tools = create_browser_toolkit(region="us-west-2")
    browser_toolkit.session_manager.session_wait_timeout = 60.0
    toolkits_to_cleanup.append(browser_toolkit)
    research_subagents.append({
        "name": f"research-{company_name.lower()}",
        "description": f"Researches {company_name} by browsing {company_url}.",
        "system_prompt": RESEARCHER_PROMPT,
        "tools": browser_tools,
    })

Cada MicroVM executa um browser Chromium real conectado via WebSocket usando Playwright (uma biblioteca de automação de browser de código aberto). As sessões são efêmeras e inicializam em segundos. O session_wait_timeout está definido em 60 segundos (padrão: 10 segundos) para dar tempo suficiente às operações de browser quando múltiplas chamadas de ferramenta rodam em paralelo. As ferramentas de browser incluem: navigate_browser, extract_text, click_element, type_text, scroll_page, extract_hyperlinks e wait_for_element.

Passo 3: Criar o toolkit do interpretador

O subagente analista usa o AgentCore Code Interpreter, uma MicroVM isolada com um ambiente Python completo com pandas, matplotlib e numpy pré-instalados:

ci_toolkit, ci_tools = await create_code_interpreter_toolkit(region="us-west-2")
toolkits_to_cleanup.append(ci_toolkit)

analyst_subagent = {
    "name": "data-analyst",
    "description": "Analyzes competitor data, generates charts and reports.",
    "system_prompt": ANALYST_PROMPT,
    "tools": ci_tools,
}

As ferramentas do interpretador incluem: execute_code, execute_command, write_files, read_files, list_files, upload_file e install_packages. Bibliotecas adicionais podem ser adicionadas em tempo de execução com a ferramenta install_packages.

Passo 4: Adicionar memória entre sessões (opcional)

O agente coordenador pode acumular conhecimento ao longo do tempo com as ferramentas de memória do AgentCore, que interagem diretamente com a API de memória de longo prazo:

from bedrock_agentcore.memory import MemoryClient
from langchain_core.tools import tool

memory_client = MemoryClient(region_name="us-west-2")

@tool
def save_research_insights(insights: str, session_id: str = "default") -> str:
    """Save competitive research insights to AgentCore long-term memory."""
    memory_client.create_event(
        memory_id=memory_id,
        actor_id=actor_id,
        session_id=session_id,
        messages=[
            (f"Save these research insights:\n\n{insights}", "USER"),
            ("Insights saved to long-term memory.", "ASSISTANT"),
        ],
    )
    return "Insights saved and are extracted into long-term memory."

Um ponto importante: o recurso de AgentCore Memory precisa ter ao menos uma estratégia de extração configurada (como semanticMemoryStrategy) para que o recall de longo prazo funcione. Sem estratégias, o create_event armazena eventos brutos, mas nenhum insight é extraído para recuperação futura. Quando o agente salva insights, as estratégias configuradas do AgentCore Memory extraem automaticamente o conhecimento estruturado em segundo plano.

Passo 5: Criar e executar o agente

Com todos os componentes prontos, basta conectá-los e invocar o agente:

agent = create_deep_agent(
    model=model,
    subagents=[*research_subagents, analyst_subagent],
    tools=memory_tools,
    system_prompt=COORDINATOR_PROMPT,
    name="competitive-research-coordinator",
    checkpointer=None,  # Simplification; use AgentCoreMemorySaver for session resumability
    store=InMemoryStore(),  # Internal storage for Deep Agents (separate from AgentCore Memory)
)

result = await agent.ainvoke(
    {"messages": [{"role": "user", "content": "Compare pricing for GitHub, GitLab, and Bitbucket"}]},
    config={"configurable": {"thread_id": "session-1", "actor_id": "research-agent"}},
)

O notebook executável com indicadores de progresso e exibição de sessão está disponível no notebook de acompanhamento. O tempo de execução esperado é de 4 a 6 minutos com o Claude Sonnet, refletindo o tempo real de navegação em três sites. O processamento sequencial da mesma pesquisa levaria até 3 vezes mais tempo.

Rastreamento e depuração do agente

O AgentCore Observability oferece visibilidade sobre essa arquitetura multi-agente pelo Amazon CloudWatch. O AgentCore emite traces e spans no formato OpenTelemetry (OTEL), permitindo visualizar a hierarquia completa de orquestração na página CloudWatch GenAI Observability: a execução do coordenador no nível superior, um span filho para cada subagente de pesquisa e o subagente analista na sequência.

Dentro de cada span, é possível revisar chamadas de ferramentas com seus inputs, outputs, tempo de execução e uso de tokens, confirmar que os subagentes de pesquisa rodaram em paralelo pelo tempo de relógio, e identificar qual subagente e chamada de ferramenta encontrou um problema quando uma navegação de browser ou execução de código não é bem-sucedida.

Como configuração única por conta, é necessário habilitar o CloudWatch Transaction Search antes que os traces e spans fiquem disponíveis. Ao hospedar o agente no AgentCore Runtime, o runtime instrumenta o agente com OTEL automaticamente, sem necessidade de configuração adicional. Para rodar o mesmo agente fora do runtime, basta adicionar o SDK do AWS Distro for OpenTelemetry (ADOT) e a biblioteca de instrumentação do LangChain ao agente. Mais detalhes na documentação do Amazon Bedrock AgentCore Observability.

Também é possível avaliar a qualidade dos traces com o Amazon Bedrock AgentCore Evaluations, que oferece avaliadores integrados como taxa de sucesso de objetivos e precisão na seleção de ferramentas. Consulte a documentação do AgentCore Evaluations para mais detalhes.

Para quem preferir, o LangSmith também pode ser usado para rastreamento. Com ele, basta configurar três variáveis de ambiente para ativar o rastreamento automático:

export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY="your-langsmith-api-key"
export LANGCHAIN_PROJECT="competitive-research-agent"

Por que essa arquitetura faz sentido

Existem quatro razões principais que tornam esse padrão valioso. Primeiro, o coordenador permanece focado no raciocínio de alto nível, pois cada subagente de pesquisa lida internamente com a navegação em múltiplas etapas e retorna apenas um resumo conciso. Segundo, há separação clara entre capacidades: cada tipo de subagente acessa apenas suas próprias ferramentas, reduzindo o risco de uso não intencional de ferramentas e tornando a depuração mais direcionada. Terceiro, a pesquisa roda mais rápido, já que três tarefas de browser executam em paralelo, cada uma em sua própria MicroVM do AgentCore. Por fim, o Amazon Bedrock AgentCore é agnóstico de modelo e de framework — as ferramentas do AgentCore (Browser, Interpreter, Memory) funcionam de forma idêntica independentemente do modelo que as orquestra. A troca de modelo é feita com uma única linha de código:

# Default: Amazon Bedrock
from langchain_aws import ChatBedrockConverse
model = ChatBedrockConverse(model="us.anthropic.claude-sonnet-4-6", region_name="us-west-2")

# Alternative: Anthropic API directly
# from langchain_anthropic import ChatAnthropic
# model = ChatAnthropic(model="claude-sonnet-4-6")

# Alternative: Google Gemini
# from langchain_google_genai import ChatGoogleGenerativeAI
# model = ChatGoogleGenerativeAI(model="gemini-2.5-pro")

Hospedando o agente no AgentCore Runtime

O agente construído funciona em um notebook, o que é ideal para desenvolvimento. Para movê-lo para um endpoint gerenciado com isolamento por sessão e um ARN de invocação estável, a AWS permite hospedá-lo no Amazon Bedrock AgentCore Runtime. O AgentCore Runtime hospeda o agente em um container ARM64 e executa cada sessão em uma microVM dedicada por até 8 horas. Por ser agnóstico de framework, o coordenador do Deep Agents, os subagentes de browser em paralelo e o subagente analista rodam sem nenhuma alteração.

A AgentCore CLI gerencia o fluxo de implantação em quatro etapas: criar o scaffold do projeto com agentcore create, atualizar o template com o código do agente, implantar com agentcore deploy e invocar com agentcore invoke. Após a implantação, é possível transmitir logs com agentcore logs e inspecionar traces com agentcore traces. Para encerrar, agentcore remove all seguido de agentcore deploy desfaz todos os recursos provisionados.

Limpeza dos recursos

Para evitar cobranças indesejadas, é importante limpar os recursos do AgentCore criados:

# Clean up browser sessions
for toolkit in browser_toolkits:
    await toolkit.cleanup()

# Clean up interpreter session
await ci_toolkit.cleanup()

As sessões de browser expiram automaticamente após 1 hora. As sessões do interpretador expiram após 15 minutos. O notebook de acompanhamento inclui código de limpeza que roda automaticamente. Se um recurso de AgentCore Memory tiver sido criado e não for mais necessário, ele pode ser excluído pelo console ou pela API do Amazon Bedrock AgentCore.

Próximos passos e casos de uso

O padrão de coleta paralela de dados, processamento especializado e síntese se aplica a muitos fluxos de trabalho além da pesquisa competitiva:

• Due diligence: configure subagentes para pesquisar registros financeiros, comunicados à imprensa e documentos regulatórios de uma empresa-alvo, trocando as URLs dos concorrentes por páginas de registros do SEC EDGAR e reutilizando o mesmo padrão de subagente de browser com mudanças mínimas.
• Criação de conteúdo: use subagentes de pesquisa para reunir material-fonte enquanto um subagente de escrita rascunha as seções.
• Orquestração de pipeline de dados: tenha subagentes extraindo dados de fontes diferentes e passando os resultados combinados para um subagente analista responsável por joins e transformações.

Para começar, abra o notebook de acompanhamento e siga o passo a passo célula por célula. Para mais informações sobre os serviços utilizados, consulte a documentação do LangChain Deep Agents, a documentação do Amazon Bedrock AgentCore, a página de preços do Amazon Bedrock AgentCore, a documentação do LangSmith, o repositório langchain-aws no GitHub e o guia de introdução ao Amazon Bedrock AgentCore.

Fonte

Build context-rich research agents with Deep Agents and Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-context-rich-research-agents-with-deep-agents-and-bedrock-agentcore/)

O que mudou no AgentCore Memory

A AWS anunciou uma novidade relevante para quem trabalha com agentes de IA no Amazon Bedrock: o AgentCore Memory passa a suportar metadados estritamente consistentes (do inglês, strictly consistent metadata) para registros de memória de longo prazo.

Para entender o impacto dessa mudança, vale lembrar como o serviço funciona: o AgentCore Memory extrai informações úteis da memória de curto prazo e as armazena como registros de memória de longo prazo. Os metadados associados a esses registros têm um papel importante — eles ajudam a organizar, filtrar e rotear as informações no momento da recuperação.

O problema que esse recurso resolve

Até então, os valores de metadados só podiam ser inferidos pelo LLM (Modelo de Linguagem de Grande Escala) durante o processo de extração. Isso significa que havia uma dependência do modelo para determinar quais valores seriam atribuídos — o que pode introduzir variações indesejadas em contextos que exigem precisão.

Com o novo suporte, as aplicações podem agora anexar valores de metadados diretamente, garantindo que eles passem pelo processo de extração e consolidação exatamente como foram fornecidos, sem nenhuma inferência por LLM.

Como funciona na prática

Quando uma chave de metadados é configurada com o tipo de extração STRICTLY_CONSISTENT, o valor informado no evento de memória de curto prazo é o mesmo valor que chega ao registro de memória de longo prazo — sem alterações.

Além disso, esse tipo de metadado influencia diretamente como os eventos são agrupados durante o processamento:

• Eventos que compartilham os mesmos valores são extraídos e consolidados juntos.
• Registros com valores diferentes nunca são mesclados, mesmo que sejam semanticamente semelhantes.

Esse comportamento abre espaço para casos de uso que exigem separação clara entre conjuntos de dados, como:

• Recuperação de memória com escopo por departamento;
• Fronteiras de conformidade entre registros regulados e padrão;
• Memória multi-tenant, onde os dados de cada tenant são processados de forma independente.

Limites e compatibilidade

Alguns pontos técnicos importantes sobre o recurso:

• É possível configurar até três chaves estritamente consistentes por estratégia.
• O recurso é compatível com as estratégias semântica, de preferência do usuário e episódica, incluindo personalizações customizadas.
• As chaves devem ser do tipo STRING e precisam estar declaradas nas chaves indexadas da memória.
• Chaves inferidas por LLM e chaves estritamente consistentes podem coexistir no mesmo recurso de memória.

Disponibilidade

O recurso de metadados estritamente consistentes do Amazon Bedrock AgentCore Memory está disponível em todas as regiões da AWS onde o AgentCore Memory é suportado.

Para começar a usar, a AWS disponibiliza a documentação metadados de memória de longo prazo, com orientações detalhadas sobre a configuração.

Fonte

Amazon Bedrock AgentCore Memory now supports strictly consistent metadata for long-term memory (https://aws.amazon.com/about-aws/whats-new/2026/05/agentcore-memory-scmetadata)

xAI chega ao Amazon Bedrock com o Grok 4.3

A AWS anunciou a chegada do modelo Grok 4.3, desenvolvido pela xAI, ao Amazon Bedrock. Com essa novidade, a xAI passa a integrar o ecossistema de provedores de modelos do Bedrock, ampliando as opções disponíveis para quem está construindo aplicações de Inteligência Artificial (IA) generativa — seja em fluxos de raciocínio, agentes autônomos ou cargas de trabalho corporativas.

O que diferencia o Grok 4.3

O Grok 4.3 é um modelo construído com foco em raciocínio (reasoning-first). O ponto que mais chama atenção é que o raciocínio fica sempre ativo — não é um recurso opcional que pode ser ignorado. Além disso, é possível configurar o nível de esforço de raciocínio entre quatro opções: nenhum (none), baixo (low), médio (medium) e alto (high).

Por ter o raciocínio sempre presente, o modelo se comporta de forma mais consistente em loops de múltiplos passos — algo especialmente relevante para quem trabalha com agentes autônomos, onde pular etapas de “pensar” pode comprometer a qualidade das respostas.

Outros diferenciais do modelo incluem:

• Uso de ferramentas e seguimento de instruções para construção de agentes com múltiplas etapas
• Eficiência de tokens, o que ajuda a manter o custo de inferência em alto volume sob controle

Casos de uso recomendados

O Grok 4.3 é especialmente indicado para cargas de trabalho corporativas que exigem análise cuidadosa de documentos e linguagem técnica, como:

• Revisão de contratos
• Pesquisa em legislação e jurisprudência
• Análise de acordos de crédito
• Perguntas e respostas sobre documentos financeiros

Além dessas aplicações mais especializadas, o modelo também entrega resultados consistentes em IA conversacional, busca, chat e fluxos de múltiplos turnos de diálogo.

O motor por trás: Mantle

O Grok 4.3 roda sobre o Mantle, um novo motor de inferência do Amazon Bedrock projetado para oferecer boa relação entre preço e desempenho. O Mantle oferece suporte a chamadas de ferramentas (tool calling), saída estruturada e streaming de respostas.

Como começar

Para saber em quais regiões o modelo está disponível, consulte a disponibilidade regional do Grok 4.3. Para começar a usar, acesse a página de detalhes do modelo na documentação oficial da AWS.

Fonte

Grok 4.3 from xAI now available in Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/06/grok-amazon-bedrock/)

Uma virada de chave no modelo de consultoria da AWS

O AWS Professional Services (AWS ProServe) conseguiu comprimir prazos de engajamento que antes levavam meses para apenas dias. Mas o que chama atenção não é o resultado em si — é o caminho. A mudança não veio de adicionar ferramentas de Inteligência Artificial (IA) sobre processos antigos. Veio de reconstruir completamente a forma de entregar, de dentro para fora.

Essa abordagem ecoa o que foi descrito no artigo Como Equipes de Fronteira estão Reinventando o Desenvolvimento Nativo em IA: os ganhos reais de produtividade surgem quando se reimagina como o software é construído, não quando se empilha IA sobre fluxos de trabalho que já existiam.

O que é uma equipe de fronteira?

No contexto da AWS, uma “equipe de fronteira” é aquela que absorveu o desenvolvimento nativo em IA como parte do seu dia a dia — não como experimento, não como piloto, mas como o modo padrão de operar. Segundo a AWS, qualquer organização pode se tornar uma equipe desse tipo. Para quem quiser acelerar esse processo com apoio especializado, o AWS ProServe se posiciona como um parceiro que já percorreu esse caminho.

O desenvolvimento nativo em IA opera em um ritmo que o modelo tradicional de consultoria não foi projetado para acompanhar. Trabalhos que antes ocupavam meses se comprimem em dias. Os ciclos ficam mais curtos, o feedback é mais rápido, e decisões passam a ser tomadas no próprio fluxo da construção. Para ajudar clientes a operarem nesse ritmo, os consultores precisam saber quais decisões podem ser tomadas rapidamente, quais exigem julgamento humano cuidadoso, e como manter a qualidade quando a velocidade de execução aumenta. Essa intuição só vem com a prática.

O objetivo central do AWS ProServe foi liberar os consultores das tarefas que não envolvem código — documentação, coordenação, relatórios de status, scaffolding repetitivo — que consumiam grande parte de cada engajamento. Com isso, o julgamento humano passou a se concentrar onde realmente gera resultado.

O time APEX: a equipe que redesenhou o modelo

O AWS ProServe começou sua jornada como um “pathfinder” — uma equipe pioneira que explora o caminho antes dos demais. Essa equipe foi batizada de APEX, sigla para Agentic AI ProServe Experiences (Experiências de IA Agêntica do ProServe).

O mandato do APEX era único: redesenhar a forma como o ProServe entrega. Para isso, o APEX construiu o ProServe Delivery Agent, um sistema multi-agente que cobre todo o ciclo de vida de uma entrega: levantamento de requisitos, validação de arquitetura, implementação, revisão de segurança, testes e implantação. Um agente supervisor orquestra sub-agentes especializados em cada fase.

O Delivery Agent é a implementação prática do AI-DLC, o Ciclo de Vida de Desenvolvimento Orientado por IA (AI-Driven Development Lifecycle). O AI-DLC foi construído por equipes de campo da AWS e refinado ao longo de centenas de workshops práticos com clientes. O desenvolvimento nativo em IA é a base; o AI-DLC é o processo que a AWS construiu para executá-lo em um ciclo de entrega completo — tanto internamente quanto para seus clientes.

O APEX validou o modelo em suas próprias cargas de trabalho de produção antes de levá-lo a clientes. Hoje, o Delivery Agent trabalha ao lado de consultores humanos em engajamentos globais, e os padrões validados pelo APEX estão se tornando o modelo padrão de entrega em todo o ProServe. Não se trata de um piloto — é o modo como a AWS entrega em escala.

Como o modelo de entrega foi redesenhado

Um engajamento típico do ProServe seguia um ritmo familiar de consultoria: descoberta em documentos extensos, decisões arquiteturais debatidas em workshops, implementação em sprints, testes e revisão de segurança nas bordas das fases. Cada handoff introduzia atrasos, e cada artefato era escrito apenas para consumo humano.

O redesenho mudou cada etapa desse processo:

• Requisitos saíram de textos em prosa e passaram a ser especificações estruturadas que tanto humanos quanto agentes conseguem interpretar — tornando-se a fonte da verdade, não um subproduto.
• Padrões arquiteturais e lições de projetos anteriores foram codificados em arquivos de direcionamento que os agentes consultam continuamente.
• Implementação deixou de ser serial (um ticket por vez) e passou a ser paralela, com consultores alimentando múltiplos agentes simultaneamente com tarefas bem delimitadas.
• Testes e revisão de segurança foram incorporados ao próprio ciclo de construção, com agentes validando saídas localmente e se autocorrigindo antes de qualquer revisão humana.
• Relatórios de status e overhead de coordenação praticamente desapareceram.

O resultado líquido é um fluxo contínuo, com o julgamento humano concentrado em priorização, validação e decisões de alto impacto.

Construindo o Delivery Agent com o próprio Delivery Agent

Uma das práticas mais interessantes do APEX é que ele constrói o Delivery Agent usando as mesmas práticas nativas em IA que oferece aos clientes. Uma solicitação de funcionalidade entra no sistema; os agentes geram tickets estruturados, produzem código e executam testes automatizados por meio de um pipeline DevOps integrado ao GitLab. Após revisão e aprovação humana, a mudança é implantada.

Os humanos cuidam do julgamento: priorizar, validar qualidade, aprovar decisões de alto impacto. Os agentes cuidam do scaffolding. Decisões de baixo risco rodam de forma autônoma. Os pontos de controle humano se concentram onde o julgamento realmente importa.

À medida que equipes de entrega em todo o ProServe adotam o Delivery Agent em seus projetos, elas retroalimentam o sistema com aprendizados — tornando-o mais preciso a cada projeto. É assim que a Amazon constrói: usa seus próprios produtos, observa o que quebra e corrige.

As cinco práticas que sustentam o modelo

Cinco práticas descritas pela AWS definem como o AI-DLC opera dentro do ProServe:

• Desacelere para acelerar. Equipes de fronteira investem antes de acelerar — constroem o contexto dos agentes e padronizam as práticas antes de ganhar velocidade. O APEX fez esse investimento uma vez, e agora transfere esse aprendizado diretamente para os clientes, sem que cada um precise começar do zero.
• Invista pesado no contexto dos agentes. Arquivos de direcionamento e padrões arquiteturais são artefatos de primeira ordem em cada engajamento. Quanto mais rico o contexto, mais autonomia o agente pode exercer com segurança.
• Alimente os agentes em vez de babá-los. Os construtores mantêm um backlog constante de tarefas bem delimitadas e rodam múltiplos agentes em paralelo, revisando saídas de forma assíncrona.
• Use especificações como fonte da verdade. O desenvolvimento orientado por especificações (spec-driven) é o fluxo padrão. Specs não são documentação — são o contrato contra o qual os agentes constroem.
• Mova os testes para o início. Os agentes validam localmente e se autocorrigem antes de qualquer saída chegar a um revisor humano.

Como funciona em ambientes de clientes

Em engajamentos com clientes, o Delivery Agent opera ao lado de consultores humanos, cobrindo todo o ciclo de vida — do planejamento à implantação — tendo como norte os resultados de negócio selecionados pelo cliente.

O princípio que governa o processo é claro: humanos fornecem a intenção, a IA cria, humanos verificam. Os clientes mantêm a escolha dos modelos de fundação e podem estender o sistema com seus próprios dados e ferramentas.

O que a AWS aprendeu ao ir primeiro

A AWS destaca que a calibração não é opcional, mas também não é preciso começar do zero. As equipes precisam de tempo para construir confiança no que os agentes fazem bem, decompor trabalhos complexos em tarefas verificáveis e reestruturar artefatos para consumo por IA. O ProServe transfere esse aprendizado diretamente durante o engajamento, encurtando a curva de adoção.

Outro ponto importante: o fluxo de trabalho é a constante; as ferramentas são habilitadoras. A AWS menciona o uso de Kiro, Amazon Bedrock AgentCore e Strands, mas deixa claro que não é o stack que gera o ganho de produtividade. As ferramentas só potencializam quando o fluxo de trabalho foi redesenhado ao redor delas.

Por fim, há uma mudança no modelo comercial: o ProServe migrou de engajamentos por tempo e material para contratos de preço fixo atrelados a resultados de negócio implantados em produção. Quando o modelo comercial se alinha com as necessidades do cliente, todo o resto segue.

Resultado real: o caso LexisNexis

A LexisNexis Legal & Professional compartilhou sua experiência com o modelo. A empresa adotou a funcionalidade Region Switch do Amazon Application Recovery Controller (ARC) para simplificar sua abordagem de resiliência multi-região. O Region Switch substituiu orquestrações de failover customizadas por planos declarativos que coordenam escalonamento, troca de banco de dados e roteamento de DNS em paralelo.

Segundo o CTO de Infraestrutura & Operações da empresa, o Kiro com o AWS Professional Services Delivery Agent comprimiu semanas de criação de backlog em horas, acelerou a entrega de código em 60% e garantiu qualidade consistente em todas as entregas. O teste de troca de região foi executado no prazo e a empresa conseguiu operar em sua região secundária com sucesso.

Como começar

A AWS oferece dois caminhos para quem quer experimentar o modelo:

• Workshops práticos: Solutions Architects da AWS conduzem workshops de AI-DLC com duração de dois a cinco dias, demonstrando o desenvolvimento nativo em IA contra o próprio stack do cliente. Centenas de clientes já participaram.
• Engajamentos de produção: quando a organização está pronta para levar casos de uso de negócio à produção, o AWS ProServe entra na jornada. Consultores e o Delivery Agent se integram à equipe do cliente para entregar resultados em produção enquanto constroem a capacidade organizacional para sustentar e escalar a prática. Ao final, o cliente tem sistemas funcionando em produção e campeões internos treinados para continuar.

Para saber mais, é possível entrar em contato com o time de conta AWS ou acessar a página do AWS Professional Services.

Fonte

Built from the inside out: How AWS Professional Services became a frontier team first (https://aws.amazon.com/blogs/machine-learning/built-from-the-inside-out-how-aws-professional-services-became-a-frontier-team-first/)

O problema com o processamento tradicional de documentos

Organizações ao redor do mundo processam milhões de documentos por dia: sinistros de seguros, faturas, contratos jurídicos, prontuários médicos. As soluções tradicionais de Reconhecimento Óptico de Caracteres (OCR) até conseguem extrair texto, mas não entendem contexto, relacionamentos ou o significado embutido em documentos complexos. Esse limite gera gargalos que exigem intervenção manual, aumentando tempo e custo de processamento — além de introduzir erros.

Para endereçar esse desafio, a AWS publicou uma arquitetura detalhada que combina o Amazon Bedrock Data Automation com agentes de IA generativa, criando um pipeline capaz de extrair, analisar e transformar documentos em dados acionáveis de forma automatizada.

O que é o Amazon Bedrock Data Automation (BDA)

O Amazon Bedrock Data Automation (BDA) é um serviço gerenciado dentro do Amazon Bedrock que oferece uma experiência de Interface de Programação de Aplicações (API) unificada para extrair insights de conteúdo multimodal — documentos, imagens, vídeos e arquivos de áudio. Diferente das soluções focadas apenas em extração de texto, o BDA compreende o contexto do documento, valida os dados extraídos e fornece pontuações de confiança para garantir precisão.

O serviço processa documentos por meio de um pipeline que automatiza classificação, extração, normalização e validação. Quando um documento é enviado, o BDA automaticamente o divide em seções lógicas, classifica cada parte no tipo de documento correspondente e direciona para os modelos de processamento corretos. Isso elimina a necessidade de triagem manual e de orquestração de múltiplos modelos de Inteligência Artificial (IA).

O BDA suporta uma ampla variedade de formatos de arquivo, com capacidade de processar até 3.000 páginas e 500 MB por requisição de API — tornando-o adequado para volumes e tipos de documentos variados em escala empresarial.

Visão geral da arquitetura

A solução proposta pela AWS organiza o pipeline de processamento em quatro camadas integradas:

• Camada de entrada: recebe os documentos e aciona a orquestração do processamento.
• Camada de extração e armazenamento: extrai texto, tabelas, imagens e elementos visuais, armazenando os dados de forma estruturada.
• Camada de inteligência: indexa o conteúdo extraído em uma base de conhecimento com busca semântica e capacidades de Geração Aumentada por Recuperação (RAG).
• Camada de coordenação por agentes: agentes especializados orquestram tarefas complexas de análise e respondem a consultas em linguagem natural.

Camada de entrada e orquestração

O fluxo começa quando documentos chegam a buckets do Amazon Simple Storage Service (Amazon S3). O AWS Step Functions orquestra o pipeline completo, fornecendo visibilidade e controle operacional em cada etapa. O fluxo detalhado funciona assim:

• Ingestão de documentos: arquivos chegam ao S3 em diversos formatos e são processados pela API unificada do BDA, sem necessidade de pré-processamento específico por formato.
• Registro de metadados: o workflow registra metadados no Amazon DynamoDB para rastreamento, trilhas de auditoria e relatórios — incluindo tipo de arquivo, tamanho, horário de envio e status de processamento.
• Análise de contagem de páginas: o Step Functions verifica a contagem de páginas para definir estratégias de processamento adequadas, como valores de timeout para os jobs assíncronos.
• Invocação do BDA: o workflow inicia um job assíncrono usando a API InvokeDataAutomationAsync. O BDA então divide o documento em seções de até 20 páginas, classifica cada parte, associa aos blueprints corretos e extrai todo o conteúdo — texto, tabelas, formulários e elementos visuais.
• Processamento assíncrono com task tokens: o workflow armazena um token de tarefa e aguarda a conclusão do job, permitindo o processamento de milhares de documentos simultaneamente.
• Tratamento de erros: o pipeline gerencia cenários de erro como falhas de validação, timeouts e tipos de arquivo não suportados, garantindo que nenhum documento seja perdido.

Camada de extração e armazenamento

Esta é a camada central da solução, onde o BDA transforma conteúdo bruto em dados estruturados e acionáveis. O serviço oferece duas opções de saída:

• Saída padrão: fornece informações comuns baseadas no tipo de dado, incluindo resumos do documento, texto extraído em ordem de leitura, legendas de tabelas e figuras, e insights gerativos. Pode ser personalizada via projetos para habilitar ou desabilitar recursos específicos.
• Saída customizada com blueprints: blueprints são configurações que definem a lógica de extração para tipos específicos de documento. A ideia é criar um blueprint por tipo de documento — por exemplo, um blueprint para passaportes e outro para extratos bancários, já que as informações relevantes de cada um são diferentes. Projetos podem conter até 40 blueprints de documentos, com o BDA associando automaticamente cada documento ao blueprint correto.

Para análise visual, o BDA extrai insights de gráficos, diagramas e outros elementos visuais que soluções tradicionais de OCR não conseguem interpretar. Quando o BDA processa um gráfico, ele produz: legendas descritivas sobre o conteúdo, pontos de dados e tendências extraídos, relações estruturais de diagramas e fluxogramas, e coordenadas de bounding box ligando o elemento visual à sua localização no documento.

Os dados extraídos incluem texto em ordem de leitura com preservação de layout, reconhecimento de estrutura de tabelas com relações entre células, detecção de campos de formulário e pares chave-valor, análise de elementos visuais com legendas geradas automaticamente, e resumos em nível de documento e de página.

Camada de inteligência: busca semântica e RAG

O Amazon Bedrock Knowledge Bases, configurado para trabalhar com o Amazon OpenSearch Serverless, transforma o conteúdo bruto extraído em insights acionáveis por meio de busca semântica e capacidades de RAG. Isso permite indexar o conteúdo processado para consultas inteligentes, manter embeddings vetoriais para busca por similaridade entre coleções de documentos e suportar consultas complexas que abrangem múltiplos documentos e fontes de dados.

Os Modelos de Fundação (FMs) do Amazon Bedrock analisam conteúdo visual, incluindo interpretação de gráficos, compreensão do layout do documento e detecção de relações entre texto e componentes visuais.

Camada de coordenação por agentes

Os Strands Agents hospedados no Amazon Bedrock AgentCore Runtime gerenciam o fluxo de processamento geral, roteando requisições para os agentes especializados adequados e coordenando a comunicação entre agentes para análises complexas. Os agentes especializados incluem:

• Agentes analistas de mercado: para relatórios de mercado financeiro e documentos de investimento.
• Agentes de consultoria de investimentos: para análise de portfólios e documentação consultiva.
• Agentes de API externa: para integração de dados de terceiros em tempo real, como provedores de dados financeiros e plataformas de inteligência de mercado.

Os agentes coordenadores realizam validação cruzada comparando dados de mercado em tempo real obtidos pelos agentes de API externa com dados históricos armazenados na base de conhecimento do Amazon Bedrock.

Caso de uso: análise de imóveis comerciais

Para ilustrar a solução na prática, a AWS apresentou um caso de uso de uma empresa de investimentos imobiliários comerciais que recebe mais de 200 relatórios de avaliação de propriedades por mês. Esses relatórios contêm documentos de visão geral da propriedade, planilhas financeiras embutidas como imagens em PDFs, gráficos de comparação de mercado, fotos e plantas baixas com anotações, documentos jurídicos e gráficos históricos de desempenho.

Com a solução implementada, o pipeline realiza:

• Classificação de documentos: identifica automaticamente os tipos de documento, extrai metadados da propriedade e roteia seções para os agentes de processamento adequados.
• Extração de conteúdo multimodal: agentes analistas de mercado processam gráficos financeiros embutidos para extrair projeções de Receita Operacional Líquida (NOI) e tendências de taxa de capitalização. O BDA analisa fotos de propriedades para identificar indicadores de condição e ratios de eficiência de plantas baixas.
• Consultas em linguagem natural: profissionais de investimento podem fazer perguntas como “Mostre propriedades com Taxa Interna de Retorno (TIR) projetada acima de 12% e índices de cobertura de dívida acima de 1,25” ou “Compare as projeções de crescimento de NOI com o desempenho real de mercado para ativos similares.”

Os resultados são expressivos: o tempo de processamento por propriedade caiu de 3 a 4 horas para 15 a 20 minutos na triagem inicial. A extração automatizada elimina erros de transcrição manual, e a validação cruzada entre documentos identifica inconsistências automaticamente.

Validação de escala e implantação

A solução foi testada em escala, processando com sucesso mais de 50.000 documentos PDF simultaneamente pelo pipeline BDA. A arquitetura serverless com AWS Step Functions e processamento assíncrono do BDA viabilizou esse processamento massivo em paralelo sem degradação de desempenho.

A implantação completa é feita via AWS Cloud Development Kit (AWS CDK), que provisiona toda a arquitetura com princípios de Infraestrutura como Código (IaC). O código cria quatro componentes principais de stack alinhados às camadas da arquitetura, com configurações específicas para ambientes de desenvolvimento, homologação e produção.

Antes de implementar, é necessário ter uma conta AWS com permissões adequadas para criar funções IAM, AWS Lambda, Step Functions, Amazon DynamoDB, Amazon Elastic Container Registry (Amazon ECR) e buckets S3, além de acesso habilitado aos FMs do Amazon Bedrock na Região desejada. O BDA está disponível atualmente em oito Regiões: Europa (Frankfurt), Europa (Londres), Europa (Irlanda), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Sydney), Oeste dos EUA (Oregon), Leste dos EUA (Virgínia do Norte) e AWS GovCloud (Oeste dos EUA).

A implementação completa do CDK está disponível no repositório público da AWS:

# Implantação rápida
git clone https://github.com/aws-samples/sample-pdf-to-insights-idp-solution
cd sample-pdf-to-insights-idp-solution
./deploy.sh --profile default --environment UAT

Para remover todos os recursos criados:

# Limpeza da implantação
./cleanup.sh --profile default --environment UAT

Estratégias de otimização de custos e segurança

A AWS recomenda algumas abordagens para gerenciar custos operacionais da solução:

• Roteamento inteligente: documentos simples usam extração básica, enquanto documentos complexos com tabelas e imagens empregam técnicas mais avançadas.
• Processamento em lote: combinar múltiplos documentos em uma única requisição ao BDA onde possível, respeitando os limites do serviço.
• Gerenciamento do ciclo de vida de armazenamento: implementar políticas de ciclo de vida do Amazon S3 para mover documentos processados para camadas de armazenamento mais baratas com base em padrões de acesso.

Em termos de segurança, a arquitetura incorpora chaves AWS KMS para criptografia de documentos e resultados, conectividade AWS PrivateLink para acesso seguro à API dentro dos limites da VPC, e funções IAM com princípios de menor privilégio em todos os componentes.

Conclusão

A combinação do Amazon Bedrock Data Automation com uma arquitetura baseada em agentes demonstra como a AWS está posicionando o processamento de documentos como um ativo estratégico — e não apenas um centro de custo. A capacidade de extrair e analisar automaticamente gráficos, tabelas, imagens e texto, mantendo contexto e relacionamentos entre fontes de dados, abre possibilidades significativas para organizações que lidam com grandes volumes de documentos não estruturados.

A recomendação da AWS é começar com uma prova de conceito focada nos tipos de documento mais comuns e nos requisitos de análise visual mais frequentes, expandindo gradualmente à medida que se ganha experiência com os serviços.

Para saber mais, consulte a documentação do Amazon Bedrock Data Automation. Para prática hands-on, o workshop de Processamento Inteligente de Documentos (IDP) no GitHub oferece exercícios práticos. O código completo da implementação CDK está disponível no repositório AWS Samples com instruções de implantação e exemplos de configuração.

Fonte

From PDFs to insights: Architecting an intelligent document processing pipeline with AWS generative AI services (https://aws.amazon.com/blogs/machine-learning/from-pdfs-to-insights-architecting-an-intelligent-document-processing-pipeline-with-aws-generative-ai-services/)