Blog

O desafio de extrair dados estruturados de documentos reais

Extrair dados estruturados de documentos não estruturados — como notas fiscais, contratos, formulários tributários e cadastros — é uma meta comum de automação para empresas de todos os portes. O problema é que manter alta precisão nessa extração é difícil na prática: documentos divergem dos modelos esperados, formatos variam entre fornecedores e a qualidade de digitalização nem sempre é ideal.

O Amazon Bedrock Data Automation (BDA) permite classificar, extrair, normalizar e validar dados de documentos por meio de uma única API. Para isso, utiliza blueprints — esquemas customizáveis que definem quais campos extrair e como interpretá-los, gerando saídas adaptadas ao formato de cada tipo de documento. Mesmo assim, otimizar esses blueprints para cobrir toda a variedade de documentos em produção ainda exige ajustes iterativos.

É para resolver exatamente esse gargalo que a AWS lançou o recurso de otimização automática de instruções de blueprints. Com ele, basta fornecer de três a dez documentos de exemplo com os valores esperados, e o BDA refina as instruções de extração automaticamente — em minutos, não semanas — sem necessidade de fine-tuning de modelos.

Por que as instruções iniciais nem sempre são suficientes

Ao criar um pipeline de Processamento Inteligente de Documentos (IDP — Intelligent Document Processing) com o BDA, você define blueprints que especificam os campos a extrair. Cada campo recebe uma instrução em linguagem natural que orienta o modelo. Por exemplo:

• Campo: invoice_number → Instrução: “The invoice number”
• Campo: total_amount → Instrução: “The total amount due”

Esse nível de instrução funciona bem em casos simples. No mundo real, porém, surgem complicações: rótulos de campo variam entre versões de um mesmo documento, campos parecidos causam confusão (como “subtotal” vs. “total”), layouts diferem entre fornecedores e casos de borda exigem orientações mais específicas.

Um exemplo simplificado de schema de blueprint para pedidos de compra ilustra bem a estrutura. Cada campo possui um tipo (type), um tipo de inferência (inferenceType — explicit para valores que aparecem diretamente no documento, inferred para valores que exigem raciocínio) e uma instrução que guia a extração:

{
  "class": "Purchase Order",
  "type": "object",
  "properties": {
    "po_number": {
      "type": "string",
      "inferenceType": "explicit",
      "instruction": "The unique identifier for the purchase order"
    },
    "order_date": {
      "type": "string",
      "inferenceType": "explicit",
      "instruction": "The date when the order was placed"
    },
    "order_total": {
      "type": "number",
      "inferenceType": "explicit",
      "instruction": "The total amount for the order"
    },
    "special_requests": {
      "type": "string",
      "inferenceType": "inferred",
      "instruction": "Any special requests or notes included in the order"
    }
  }
}

O recurso de otimização age exatamente sobre os valores de instruction de cada campo. Os atributos type e inferenceType permanecem inalterados. O schema completo do exemplo de pedido de compra está disponível no repositório no GitHub.

Da iteração manual ao refinamento automatizado

Sem a otimização automática, o caminho tradicional para melhorar a precisão exige testar diferentes formulações de instrução, adicionar contexto e repetir o ciclo de extração até encontrar o melhor resultado. Para organizações que processam documentos de centenas de fornecedores, esse processo pode consumir semanas por tipo de documento.

Com o recurso de otimização de instruções, todo esse ciclo é automatizado em um único fluxo de trabalho. O BDA compara os resultados de extração com os valores corretos fornecidos (o chamado ground truth) e refina as instruções em linguagem natural para cada campo — entregando instruções otimizadas em minutos.

Como funciona o fluxo de otimização

O processo segue quatro etapas principais:

• Fornecer documentos de exemplo: faça upload de três a dez documentos representativos do seu ambiente de produção, incluindo casos de borda onde a extração já apresentou problemas. Quanto mais diversidade, melhor — isso evita overfitting.
• Fornecer o ground truth: informe os valores corretos esperados para cada campo em cada documento. O ground truth é o conjunto de dados verificados que serve como referência para medir a qualidade da extração.
• Executar a otimização: inicie o processo. O BDA compara seus resultados iniciais com o ground truth e refina as instruções de cada campo automaticamente.
• Revisar os resultados: analise as métricas detalhadas de acurácia junto com as instruções otimizadas. O processo normalmente conclui em minutos.

As métricas apresentadas incluem o F1 Score (medida combinada de precisão e recall) e a taxa de correspondência exata (percentual de campos cujo valor extraído corresponde exatamente ao ground truth).

Uma instrução genérica como “The invoice number” pode se tornar, após a otimização: “The invoice number, typically found in the upper right corner of the document header, formatted as a numeric or alphanumeric code following ‘Invoice #’ or ‘Invoice No.’” — muito mais específica e eficaz para documentos reais.

Exemplo prático: extração de pedidos de compra

Para ilustrar o fluxo, o artigo original da AWS usa o cenário de uma empresa fictícia de fabricação de bicicletas. O blueprint extrai campos como número do pedido, descrições de itens, quantidades, preços unitários e totais. Após o upload de quatro pedidos de compra representativos — de varejistas como Cycle Central e Bike World — com os arquivos de ground truth correspondentes, os resultados após a otimização foram:

• Correspondência exata por arquivo (melhor caso): de 92% para 100%
• Correspondência exata agregada: de 90% para 92%

O BDA refinou automaticamente as instruções para lidar com formatações específicas de cada fornecedor, variações nos rótulos de campos e diferenças de layout entre os pedidos. Em operações de alto volume, mesmo alguns pontos percentuais de melhoria na precisão se traduzem diretamente em menos revisão manual e maior velocidade de processamento.

Pré-requisitos para começar

Para usar o recurso, você precisará de:

• Uma conta AWS
• Acesso ao Amazon Bedrock com o BDA habilitado em uma região suportada
• Uma role do AWS Identity and Access Management (AWS IAM) com permissões para usar o BDA e o Amazon Simple Storage Service (Amazon S3)
• Entre três e dez documentos de exemplo representativos do seu ambiente de produção
• Arquivos JSON de ground truth com os valores esperados para cada documento de exemplo

Um arquivo de ground truth espelha o schema do seu blueprint, com cada campo preenchido com o valor correto esperado. Veja um exemplo simplificado para um pedido de compra:

{
  "po_number": "PO-2026-0224-1265",
  "retailer_name": "Bike World",
  "order_date": "2026-02-24",
  "order_total": 11571.25,
  "order_items": [
    {
      "sku": "AB-MB-076",
      "product_name": "Trail Classic",
      "quantity": 6,
      "unit_price": 1864.37,
      "line_total": 11186.22
    }
  ]
}

Implantando a solução de exemplo

A AWS disponibiliza uma solução de exemplo completa para facilitar o início. Para implantá-la, siga os passos abaixo:

• Baixe o template do CloudFormation do repositório no GitHub.
• Abra o console do AWS CloudFormation.
• Escolha Create stack, depois Upload a template file.
• Faça upload do template baixado e clique em Next.
• Em Stack name, insira um nome (por exemplo, blueprint-optimization-sample).
• Siga os demais prompts, confirme as capacidades do IAM e clique em Create stack.

A stack implanta um blueprint de exemplo, arquivos de documentos, arquivos de ground truth e um notebook do Amazon SageMaker AI. O código completo também está disponível no repositório no GitHub.

Após a implantação, acesse o Amazon SageMaker AI, abra o notebook criado pela stack no JupyterLab, selecione o kernel Python 3 e siga as instruções para criar e otimizar um blueprint com os documentos de exemplo. Quando concluir, execute a célula de limpeza no notebook para esvaziar o bucket S3 antes de excluir a stack do CloudFormation.

Walkthrough da API com Boto3

Os exemplos abaixo mostram as principais chamadas de API para o fluxo de otimização usando o AWS SDK para Python (Boto3). O notebook completo está disponível no repositório no GitHub.

1. Criar um blueprint

import boto3, json

bda_client = boto3.client('bedrock-data-automation')

response = bda_client.create_blueprint(
    blueprintName='acme-bikes-purchase-order',
    type='DOCUMENT',
    blueprintStage='DEVELOPMENT',
    schema=json.dumps(blueprint_schema)
)

blueprint_arn = response['blueprint']['blueprintArn']

2. Iniciar a otimização

response = bda_client.invoke_blueprint_optimization_async(
    blueprint={
        'blueprintArn': blueprint_arn,
        'stage': 'DEVELOPMENT'
    },
    samples=[
        {
            'assetS3Object': {'s3Uri': 's3://my-bucket/samples/PO_001.pdf'},
            'groundTruthS3Object': {'s3Uri': 's3://my-bucket/ground-truth/PO_001.json'}
        },
        # ... additional samples
    ],
    outputConfiguration={
        's3Object': {'s3Uri': 's3://my-bucket/optimization-output/'}
    },
    dataAutomationProfileArn=profile_arn
)

invocation_arn = response['invocationArn']

3. Verificar o status da otimização

import time

while True:
    status = bda_client.get_blueprint_optimization_status(
        invocationArn=invocation_arn
    )['status']
    if status == 'Success':
        break
    elif status in ('ServiceError', 'ClientError'):
        raise RuntimeError(f'Optimization failed: {status}')
    time.sleep(15)

4. Recuperar o blueprint otimizado

bp = bda_client.get_blueprint(
    blueprintArn=blueprint_arn,
    blueprintStage='DEVELOPMENT'
)

optimized_schema = json.loads(bp['blueprint']['schema'])

5. Promover para produção (opcional)

bda_client.copy_blueprint_stage(
    blueprintArn=blueprint_arn,
    sourceStage='DEVELOPMENT',
    targetStage='LIVE'
)

Interpretando as métricas de resultado

A página de resultados da otimização exibe três métricas para cada arquivo de exemplo e de forma agregada:

• Exact Match Rate (Taxa de Correspondência Exata): percentual de campos onde o valor extraído corresponde ao ground truth caractere por caractere. É a medida mais rigorosa de precisão. No exemplo do artigo, o arquivo Cycle Central passou de 92,4% para 100%.
• Overall F1 Score: combina precisão (quanto do que foi extraído estava correto) e recall (quanto do conteúdo correto foi encontrado) em um único número. Especialmente útil para campos com valores de comprimento variável, como descrições de itens. No exemplo, o F1 Score também subiu de 92,4% para 100%.
• Confidence Score (Pontuação de Confiança): indica o grau de certeza do BDA sobre cada valor extraído. Uma pontuação mais alta significa que o modelo encontrou sinais mais claros no documento para aquele campo. No exemplo, a confiança subiu de 57,8% para 60,1% — um ganho menor, esperado quando o layout do documento é ambíguo. Pontuações de confiança mais altas reduzem o volume de campos encaminhados para revisão humana em fluxos com validação humana no loop.

Use a aba de métricas por arquivo para identificar quais documentos ainda apresentam pontuações baixas após a otimização — esses são candidatos a receber exemplos mais direcionados. A aba de métricas agregadas ajuda a avaliar a saúde geral do blueprint antes de salvá-lo.

Integração com outros serviços do Amazon Bedrock

Blueprints otimizados melhoram a qualidade dos dados na camada de extração, o que fortalece fluxos de trabalho construídos sobre o BDA:

• Amazon Bedrock Knowledge Bases, o serviço gerenciado de Geração Aumentada por Recuperação (RAG — Retrieval-Augmented Generation), se beneficia de dados extraídos com maior qualidade, gerando embeddings vetoriais melhores para busca semântica.
• Amazon Bedrock Agents — fluxos agênticos que dependem de dados extraídos de documentos (como processamento autônomo de hipotecas) se tornam mais confiáveis com entradas mais precisas, reduzindo a complexidade do tratamento de erros.
• Amazon Bedrock Guardrails — dados extraídos validados por verificações de raciocínio automatizado se beneficiam de entradas mais limpas, melhorando a acurácia da verificação.

Com pontuações de confiança e ancoragem visual (bounding boxes) para campos extraídos, é possível implementar validação humana no loop onde necessário. A otimização melhora tanto os valores extraídos quanto as pontuações de confiança associadas, aumentando a segurança nos fluxos de processamento automatizado.

Boas práticas para melhores resultados

• Selecione exemplos representativos: escolha documentos que cubram a variedade do seu ambiente de produção, incluindo formatos comuns e casos de borda problemáticos.
• Verifique a qualidade do ground truth: confira que os valores esperados estão corretos antes de executar a otimização — a qualidade do ground truth impacta diretamente nos resultados.
• Comece com três a cinco exemplos: é possível obter melhorias significativas com poucos exemplos bem escolhidos. Adicione mais se os resultados iniciais não atingirem as metas de precisão.
• Inclua casos desafiadores: adicione exemplos onde a extração já falhou anteriormente para ajudar o processo a aprender a lidar com esses casos de borda.
• Re-otimize quando necessário: execute a otimização novamente se notar degradação de precisão ao longo do tempo — por exemplo, quando novos formatos de documento aparecerem no seu ambiente.

Disponibilidade e preços

A otimização de instruções de blueprints está disponível nas regiões AWS onde o Amazon Bedrock Data Automation é suportado. Para verificar a disponibilidade por região, consulte a documentação do Amazon Bedrock Data Automation. O processo de otimização incorre nos custos padrão de inferência do BDA, calculados com base no número de páginas dos documentos de exemplo. Para detalhes de preços, consulte a página de preços do Amazon Bedrock.

Limpeza dos recursos

Se você implantou a solução de exemplo ou criou recursos durante os testes, siga os passos abaixo para evitar cobranças contínuas:

• Exclua a stack do CloudFormation pelo console do AWS CloudFormation. Isso remove o notebook do SageMaker AI, o bucket S3 e os recursos associados.
• Exclua os blueprints criados acessando o Amazon Bedrock Data Automation no console do Amazon Bedrock, selecionando o blueprint e escolhendo Delete.
• Remova documentos de exemplo e arquivos de ground truth de buckets S3 criados fora da stack.

Para mais informações sobre gerenciamento de recursos do Amazon Bedrock Data Automation, consulte a documentação oficial.

Conclusão

A otimização automática de instruções de blueprints é um recurso que pode reduzir significativamente o esforço manual necessário para atingir alta precisão de extração. Ao fornecer alguns documentos de exemplo com ground truth, é possível refinar automaticamente as instruções de extração e melhorar a acurácia em minutos — não em semanas.

Combinado com pontuações de confiança, ancoragem visual e integração com Amazon Bedrock Agents e Amazon Bedrock Knowledge Bases, esse recurso pode acelerar o caminho do protótipo para pipelines de IDP em produção.

Para dar os próximos passos, a AWS recomenda:

• Testar o recurso implantando a solução de exemplo na sua conta e executando o notebook do SageMaker AI.
• Executar a otimização nos seus próprios documentos para medir as melhorias de precisão no seu caso de uso específico.
• Explorar como blueprints otimizados se integram com o Amazon Bedrock Knowledge Bases para busca e recuperação de documentos, ou com o Amazon Bedrock Agents para fluxos de tomada de decisão automatizada.

Recursos úteis: documentação do Amazon Bedrock Data Automation, console do Amazon Bedrock, template CloudFormation da solução de exemplo e preços do Amazon Bedrock.

Fonte

Optimize blueprint extraction accuracy in Amazon Bedrock Data Automation (https://aws.amazon.com/blogs/machine-learning/optimize-blueprint-extraction-accuracy-in-amazon-bedrock-data-automation/)

O problema: documentos em volume e inteligência represada

Muitas empresas acumulam grandes volumes de documentos em papel ou em formato eletrônico que contêm informações valiosas ainda não exploradas. Com o avanço da IA generativa, modelos de linguagem de grande porte (LLMs) passaram a ser capazes de extrair dados relevantes desses documentos com precisão considerável.

A AWS publicou um artigo técnico demonstrando como construir um pipeline inteligente de processamento de documentos usando o Amazon Bedrock, com duas modalidades de inferência: sob demanda e em lote. A proposta é oferecer flexibilidade para equilibrar tempo de processamento e custo, dependendo da urgência de cada requisição.

O cenário de exemplo utilizado é bastante concreto: centenas de milhões de documentos de arrendamento de terras em formato PDF digitalizado — ou seja, PDFs que contêm apenas imagens, sem texto editável — acumulados no backlog, com novos arquivos chegando diariamente.

Visão geral da solução

A solução é composta por dois pipelines de inferência que podem ser acionados dinamicamente, conforme a necessidade:

• Pipeline sob demanda: processa documentos individualmente, retornando resultados em segundos. Indicado para requisições com urgência de tempo.
• Pipeline em lote: processa múltiplos documentos em um único job de inferência em lote do Amazon Bedrock, de forma assíncrona. É a opção mais econômica.

Em ambos os pipelines, o usuário pode especificar o ID e a versão do prompt desejado. Os textos dos prompts são gerenciados centralmente pelo serviço de Gerenciamento de Prompts (Prompt Management) do Amazon Bedrock, o que permite padronizar e versionar as instruções dadas ao modelo. Isso é especialmente útil quando os documentos variam em formato — alguns apresentam atributos em listas numeradas, outros em tabelas, e alguns até em desenhos de terrenos.

Pipeline sob demanda

O pipeline sob demanda utiliza uma fila do AWS SQS do tipo Primeiro a Entrar, Primeiro a Sair (FIFO — First-In, First-Out). Quando uma mensagem chega à fila contendo o ID do documento, o ID do modelo LLM, o ID e versão do prompt e do prompt de sistema, uma função AWS Lambda é acionada automaticamente.

Essa função executa as seguintes etapas:

• Baixa o documento PDF do bucket Amazon S3 indicado na mensagem.
• Converte as páginas do PDF em imagens PNG para que o modelo multimodal possa processá-las.
• Se o documento tiver mais de 20 páginas, ele é dividido em blocos de 20 imagens — limite atual do modelo Claude 4 Sonnet por invocação multimodal.
• Recupera os textos dos prompts no Gerenciamento de Prompts do Bedrock.
• Compõe a mensagem para o LLM e envia a requisição ao Amazon Bedrock via Converse API.
• Salva o resultado extraído em uma tabela do Amazon DynamoDB, junto com métricas de desempenho do modelo.
• Após o processamento bem-sucedido, a mensagem é deletada da fila SQS.

Por que usar fila FIFO?

A escolha pela fila FIFO garante entrega confiável de mensagens (cada mensagem é processada exatamente uma vez), ordenação estrita e suporte ao agrupamento de mensagens por produtor, mantendo a previsibilidade do processamento.

As mensagens podem ser criadas externamente via AWS CLI ou AWS SDK. O exemplo de comando CLI fornecido no artigo original é:

aws sqs send-message --queue-url https://sqs.us-east-1.amazonaws.com/1111111111/ondemand-data-pipeline-queue.fifo --message-group-id "1" --message-body "msg 1" --message-attributes file://message_txt.txt

Estrutura dos dados armazenados

Para documentos com múltiplos blocos, o DynamoDB armazena três campos de controle:

• doc_id: identificador do documento.
• chunk_count: total de blocos gerados para aquele documento.
• chunk_id: identificador de cada bloco individualmente.

Pipeline em lote

O pipeline em lote foi projetado para alto volume. Ele utiliza uma fila SQS padrão (não FIFO), que oferece maior throughput. O fluxo envolve os seguintes componentes principais:

• Amazon EventBridge Scheduler: aciona a função Lambda de inferência em lote de acordo com uma agenda configurada.
• Lambda de inferência em lote: pré-processa os PDFs digitalizados, cria os arquivos JSONL e submete o job de inferência em lote ao Amazon Bedrock.
• Regra do Amazon EventBridge: captura o evento de conclusão do job e aciona a Lambda de pós-processamento.
• Lambda de pós-processamento: lê os resultados do job e salva os dados extraídos no DynamoDB.

Como a Lambda de lote funciona

Antes de iniciar, a função verifica se há mensagens suficientes na fila — o Amazon Bedrock exige no mínimo 100 registros para criar um job de inferência em lote. Em seguida, ela:

• Lê as mensagens da fila e extrai IDs de documento, modelo e prompts.
• Baixa e converte os documentos, assim como no pipeline sob demanda, ignorando duplicatas (já que filas SQS padrão não garantem entrega única).
• Recupera os textos dos prompts do Gerenciamento de Prompts do Bedrock.
• Cria um arquivo metadata.json no bucket S3 de dados de inferência em lote, contendo os atributos das mensagens SQS para uso posterior pelo pós-processamento.
• Gera os arquivos JSONL necessários para o job, usando o módulo de multiprocessamento do Python para paralelizar o trabalho.
• Faz upload dos arquivos JSONL para o S3 e deleta as mensagens da fila.
• Cria o job de inferência em lote no Amazon Bedrock.

Um detalhe importante: cada job em lote só pode usar um modelo. Se as mensagens da fila especificarem modelos diferentes, a Lambda utiliza um mecanismo de seleção que escolhe o modelo mais frequentemente solicitado naquele conjunto.

Fluxo de conclusão do job

Quando o Amazon Bedrock conclui o job, ele armazena os resultados no bucket S3 configurado e envia um evento de mudança de status ao Amazon EventBridge. Uma regra do EventBridge captura esse evento e aciona a Lambda de pós-processamento, que lê os arquivos JSONL de saída e salva os atributos extraídos no DynamoDB.

Pré-requisitos e implantação

Para reproduzir a solução, é necessário ter uma conta AWS com acesso ao Console de Gerenciamento e permissões de Gerenciamento de Identidade e Acesso (IAM) suficientes para criar e gerenciar stacks do AWS CloudFormation, incluindo as permissões: cloudformation:CreateStack, cloudformation:DescribeStacks, cloudformation:UpdateStack e cloudformation:DeleteStack.

A implantação é feita via CloudFormation, com stacks separados para o pipeline sob demanda e o pipeline em lote. O processo segue o fluxo padrão: criação da stack, revisão e confirmação dos recursos de IAM que serão criados.

Testando os pipelines

O artigo original disponibiliza três documentos de arrendamento de terras do Texas para testes: dos condados de Winkler, Andrews e Sutton, adquiridos no site Texas Land Records and County Records.

O fluxo de teste do pipeline sob demanda consiste em:

• Baixar os PDFs de exemplo e fazer upload para o bucket S3 criado pelo CloudFormation.
• Criar um arquivo JSON de atributos da mensagem (message_txt.json) com os IDs do documento, modelo, prompts e localização no S3.
• Enviar a mensagem para a fila SQS via AWS CLI.
• Acompanhar os logs da Lambda no Amazon CloudWatch.
• Verificar o resultado extraído na tabela DynamoDB.

O arquivo de exemplo de mensagem fornecido no artigo original é:

{
  "application": {
    "DataType": "String",
    "StringValue": "bedrock-example"
  },
  "id": {
    "DataType": "String",
    "StringValue": "Winkler_2024-06-05_N_C42758_V_OPR"
  },
  "model_id": {
    "DataType": "String",
    "StringValue": "anthropic.claude-sonnet-4-20250514-v1:0"
  },
  "prompt_id": {
    "DataType": "String",
    "StringValue": "6CT88W3MWT"
  },
  "prompt_version": {
    "DataType": "String",
    "StringValue": "1"
  },
  "s3_location": {
    "DataType": "String",
    "StringValue": "s3://ondemand-data-pipeline-bucket-111111111/Winkler_2024-06-05_N_C42758_V_OPR.pdf"
  },
  "system_prompt_id": {
    "DataType": "String",
    "StringValue": "R2NFLXFXOJ"
  },
  "system_prompt_version": {
    "DataType": "String",
    "StringValue": "1"
  }
}

O resultado esperado para o documento do condado de Winkler, armazenado na coluna model_response do DynamoDB, é uma estrutura JSON com os atributos de cada área de terra identificada no documento:

[
  {
    "tract": 1,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1239",
    "survey": "PSL Survey",
    "section": "8",
    "range_block": "B2",
    "quarter": "N/2 of N/2"
  },
  {
    "tract": 2,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1239",
    "survey": "PSL Survey",
    "section": "8",
    "range_block": "B2",
    "quarter": "N/2 of S/2"
  },
  {
    "tract": 3,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1240",
    "survey": "PSL Survey",
    "section": "9",
    "range_block": "B2",
    "quarter": "S/2 of N/2"
  },
  {
    "tract": 4,
    "state": "Texas",
    "county": "Winkler",
    "abstract": "A-1240",
    "survey": "PSL Survey",
    "section": "9",
    "range_block": "B2",
    "quarter": "S/2 of S/2"
  }
]

Limpeza dos recursos

Para remover os recursos criados, basta deletar as stacks pelo console do CloudFormation. O serviço cuida automaticamente da ordem de exclusão respeitando as dependências. Vale destacar que os buckets S3 e a tabela DynamoDB não são deletados automaticamente — a política de retenção foi configurada para evitar perda acidental de dados. Para removê-los, é necessário acessar cada serviço individualmente no console e excluí-los manualmente.

Considerações finais

A solução apresentada pela AWS demonstra como é possível combinar flexibilidade e economia no processamento inteligente de documentos. A escolha entre o pipeline sob demanda e o em lote deve levar em conta tanto a urgência do processamento quanto o custo: segundo os testes mencionados no artigo original, o pipeline em lote pode reduzir em 50% o custo do Amazon Bedrock em comparação com a modalidade sob demanda.

Outro diferencial relevante é a capacidade de especificar o modelo e o prompt em nível de documento individual, o que torna os pipelines adaptáveis a diferentes tipos de conteúdo dentro do mesmo fluxo. Com paralelismo habilitado via módulo de multiprocessamento do Python, as funções Lambda do pipeline em lote conseguem processar 1.000 documentos em até 15 minutos.

Para quem quiser escalar ainda mais, o artigo sugere migrar o código das Lambdas para o AWS Batch, o que permitiria processar dezenas de milhares de documentos em um único job de inferência em lote. O ponto de partida recomendado é o repositório de quick start disponível no GitHub.

Fonte

Extract Data with On-demand and Batch Pipelines Dynamically (https://aws.amazon.com/blogs/machine-learning/extract-data-with-on-demand-and-batch-pipelines-dynamically/)

O problema com a avaliação tradicional de agentes

Equipes que desenvolvem agentes de Inteligência Artificial (IA) costumam avaliá-los da mesma forma que avaliam qualquer outro software: verificando se a saída corresponde ao que era esperado. O problema é que agentes autônomos, que escolhem ferramentas e encadeiam operações por conta própria, produzem comportamentos que testes baseados apenas na saída final não conseguem capturar completamente.

Um agente pode entregar uma resposta bem estruturada e aparentemente útil enquanto alucina — inventando fatos porque suas ferramentas retornaram resultados vazios. Ele também pode chegar à conclusão correta pulando etapas de verificação que um processo confiável exigiria. Como essas falhas ficam abaixo da superfície da resposta final, detectá-las exige uma avaliação que rastreie o caminho completo de execução: quais ferramentas foram chamadas, o que elas retornaram e se a resposta reflete fielmente esses dados.

Fechar essa lacuna requer uma infraestrutura que a maioria das equipes não tem capacidade de construir do zero. São necessários casos de teste com resultados esperados, instrumentação de observabilidade para capturar chamadas de ferramentas e estado intermediário, além de métricas que avaliem fidelidade e uso de ferramentas junto com a precisão da saída.

O que é o Agent-EvalKit

O Agent-EvalKit é um toolkit open-source (licença Apache 2.0) que disponibiliza essa infraestrutura de avaliação ao se integrar com assistentes de codificação de IA, incluindo Claude Code, Kiro CLI e Kilo Code. Em vez de tratar a avaliação como uma etapa separada pós-implantação, o toolkit traz todo o fluxo de trabalho para dentro do ambiente de desenvolvimento.

O funcionamento é direto: você descreve seus objetivos de avaliação em linguagem natural, e o toolkit cuida de cada fase — desde a leitura do código-fonte do agente e a geração de casos de teste direcionados, passando pela execução das avaliações, até a produção de um relatório com recomendações de melhoria que referenciam locais específicos no código.

O toolkit foi desenvolvido para funcionar através do seu assistente de codificação existente, que se torna o motor de avaliação ao aplicar sua capacidade de ler código e raciocinar sobre o comportamento do agente em cada fase do processo. O fluxo é controlado por comandos como /evalkit.plan e /evalkit.data, seguidos de instruções em linguagem natural que indicam quais dimensões de qualidade são mais importantes para o seu agente.

Por que a escolha das métricas importa

Além da infraestrutura em si, definir o que medir é igualmente desafiador. A qualidade de um agente abrange dimensões que nenhuma métrica única captura sozinha: se as respostas são fundamentadas no que as ferramentas realmente retornaram, se o agente chamou as ferramentas certas com os parâmetros corretos e se a saída final é coerente e útil.

Uma resposta pode parecer excelente enquanto alucina silenciosamente sobre resultados vazios de ferramentas. Um agente pode chegar a uma resposta plausível por meio de uma sequência quebrada de chamadas de ferramentas. Por isso, cada dimensão precisa ser verificada de forma independente.

Nenhum estilo único de avaliador resolve tudo bem. Avaliadores baseados em código oferecem resultados rápidos e reproduzíveis, mas penalizam variações válidas de abordagem. Avaliadores baseados em Grandes Modelos de Linguagem (LLM) como juízes fornecem avaliações mais nuançadas ao custo de inferência adicional e design cuidadoso de prompts. As estratégias mais eficazes combinam as duas abordagens. Além disso, traduzir pontuações de avaliação em mudanças concretas de código é onde muitos esforços travam — razão pela qual o fluxo precisa terminar em recomendações específicas no nível do código, não em um painel de números.

As seis fases do Agent-EvalKit

O toolkit organiza o trabalho em seis fases, cada uma produzindo artefatos no diretório eval/ que alimentam a fase seguinte. Cada fase é invocada como um comando no assistente de IA, e o texto após o comando serve como orientação em linguagem natural para aquela etapa.

• Plan (/evalkit.plan): lê o código do agente para entender suas ferramentas e framework, então produz um plano de avaliação que associa cada métrica a um método concreto de avaliação. As prioridades definidas aqui se propagam para as fases seguintes.
• Data (/evalkit.data): gera casos de teste baseados no plano de avaliação, cada um com entradas e resultados esperados que visam comportamentos e modos de falha específicos. Se você já tiver dados de teste de logs de produção ou testes manuais, pode apontar esta fase para o conjunto existente.
• Trace (/evalkit.trace): torna o caminho completo de execução visível adicionando rastreamento compatível com OpenTelemetry ao agente. Para frameworks suportados — incluindo Strands, LangGraph e CrewAI — a fase detecta o framework e aplica a instrumentação adequada.
• Run Agent (/evalkit.run_agent): executa o agente contra cada caso de teste, produzindo um arquivo de rastreamento estruturado para cada execução que captura o histórico completo de chamadas de ferramentas, respostas do modelo e estado intermediário.
• Eval (/evalkit.eval): implementa as métricas do plano como código de avaliação executável, roda esse código contra os rastreamentos coletados e salva resultados estruturados. Suporta bibliotecas como DeepEval e o Strands Evals SDK.
• Report (/evalkit.report): analisa padrões entre os casos de teste e gera recomendações priorizadas que referenciam locais específicos no código do agente, com cada recomendação incluindo seu impacto esperado.

Ao longo dessas fases, preocupações vagas de qualidade se transformam em um conjunto estruturado de evidências: casos de teste, rastreamentos de execução, pontuações de métricas e recomendações priorizadas — tudo vinculado a locais específicos no código.

Estudo de caso: avaliando um agente de pesquisa de viagens

Durante o desenvolvimento de um agente de pesquisa de viagens construído com o Strands Agents SDK e o Amazon Bedrock, a equipe percebeu que o agente às vezes fornecia números suspeitosamente precisos em suas respostas. O agente ajuda usuários a planejar viagens usando ferramentas de busca na web, informações de voos, dados climáticos, conversão de moedas e cálculo de orçamento — mas não era possível determinar a extensão do problema ou quais consultas o desencadeavam.

O Agent-EvalKit analisou o código do agente e, durante a fase Plan, projetou uma avaliação focada em três métricas: Faithfulness (Fidelidade), que mede se as respostas estão fundamentadas nos dados que as ferramentas realmente retornaram; Tool Parameter Accuracy (Precisão de Parâmetros de Ferramentas), que verifica se o agente chamou as ferramentas com as entradas corretas; e Response Quality (Qualidade de Resposta), que avalia a coerência e utilidade da saída.

A fase Data gerou 100 sessões de teste com múltiplos turnos cobrindo pesquisa de destino, timing sazonal, construção de itinerário, perguntas comparativas e cálculo de orçamento. As fases seguintes executaram cada sessão enquanto capturavam rastreamentos detalhados de execução.

Os resultados expuseram uma divisão clara entre qualidade e confiabilidade. A Qualidade de Resposta ficou em 83,9%, confirmando que o agente produzia conselhos de viagem claros e acionáveis. A Precisão de Parâmetros de Ferramentas chegou a 64,5%, mostrando que o agente geralmente selecionava as ferramentas certas, mas às vezes passava parâmetros imprecisos. Já a Fidelidade pontuou apenas 32,3%, revelando que o agente fabricava taxas de câmbio, temperaturas e detalhes de atrações sempre que suas ferramentas de busca na web retornavam resultados vazios ou incompletos — e apresentava essas invenções como se viessem das ferramentas.

O relatório identificou as proteções contra alucinação como a correção de maior prioridade, recomendando instruções no system prompt para divulgar quando as ferramentas retornam resultados vazios e melhorias no tratamento de erros das ferramentas em todos os caminhos de código. Antes de rodar o Agent-EvalKit, a equipe sabia que o agente às vezes parecia não confiável. Depois, sabia exatamente que a causa raiz eram saídas vazias de ferramentas desencadeando alucinação — e tinha mudanças específicas de código para resolver o problema.

Como começar a usar

Para executar uma avaliação com o Agent-EvalKit, são necessários alguns pré-requisitos: uma conta AWS ativa com modelos de fundação habilitados no console do Amazon Bedrock (o toolkit usa métricas de LLM-como-juiz que requerem um modelo de fundação para pontuação), Python 3.11 ou superior, Git, o gerenciador de pacotes uv e um assistente de codificação de IA suportado (Claude Code, Kiro CLI ou Kilo Code) instalado e configurado.

A instalação é feita via uv, que puxa diretamente do repositório GitHub do Agent-EvalKit:

uv tool install evalkit --from git+https://github.com/awslabs/Agent-EvalKit.git

Em seguida, inicialize um projeto de avaliação e copie o código do seu agente para o diretório do projeto:

evalkit init my-agent-evaluation
cd my-agent-evaluation
cp -r /path/to/your/agent .

Inicie o assistente de IA dentro do projeto de avaliação. Para o Claude Code:

claude

Para uma primeira avaliação guiada, o comando rápido percorre todas as seis fases passo a passo:

/evalkit.quick <sua orientação em linguagem natural>
/evalkit.quick Evaluate my agent at ./my_agent for response quality and tool accuracy

Para mais controle, execute cada fase individualmente:

/evalkit.plan <sua orientação em linguagem natural>
/evalkit.plan Evaluate my agent at ./my_agent for response quality and tool accuracy
/evalkit.data
/evalkit.trace
/evalkit.run_agent
/evalkit.eval
/evalkit.report

Boas práticas para avaliação contínua

A avaliação de agentes tem mais retorno quando roda a cada mudança significativa, não apenas como um ponto de verificação pré-lançamento. Algumas práticas recomendadas:

• Comece de forma estreita: foque em duas ou três métricas que visem as dimensões de qualidade mais críticas do agente e expanda o escopo em avaliações posteriores.
• Oriente com conhecimento de domínio: descreva as entradas específicas, casos extremos e modos de falha que você já observou. Quanto mais direcionadas forem as instruções em linguagem natural, mais relevantes serão os casos de teste e recomendações gerados.
• Revise os casos de teste antes da execução: a fase de dados sintetiza casos a partir do plano de avaliação, mas seu entendimento do comportamento real dos usuários é insubstituível. Adicione cenários que reflitam padrões que você observa em produção.
• Avalie após cada mudança significativa: isso permite detectar regressões cedo e medir o impacto de cada melhoria. Comparar relatórios entre versões do agente torna o progresso visível.
• Aborde recomendações de forma incremental: comece pelo item de maior impacto no relatório, implemente a correção, reavalie para confirmar a melhoria e então avance para o próximo achado.
• Monitore em produção: capture rastreamentos do tráfego real com o Amazon Bedrock AgentCore Observability e execute métricas de qualidade contra esses rastreamentos com o AgentCore Evaluation. O monitoramento em produção expõe regressões e novos modos de falha que a avaliação pré-implantação não consegue antecipar.
• Mantenha os avaliadores alinhados com especialistas humanos: compare periodicamente as pontuações do LLM-como-juiz com julgamentos de especialistas no domínio. Atualize os prompts dos avaliadores quando os dois divergirem.

Integração com pipelines de CI/CD

Para equipes prontas para automatizar, o Agent-EvalKit pode ser integrado a um pipeline de Integração Contínua e Entrega Contínua (CI/CD), onde mudanças de código disparam avaliações, um portão de qualidade verifica limiares de métricas e regressões, e falhas são encaminhadas de volta como itens sinalizados no relatório de avaliação.

Uma vez que o pipeline esteja em funcionamento, cada rodada de testes reutiliza os casos de teste e a instrumentação da rodada anterior — o que reduz o custo de executar uma nova avaliação conforme o projeto amadurece.

Conclusão

O Agent-EvalKit dá à avaliação de agentes de IA uma forma sistemática ao delegar cada etapa — do design da avaliação ao cálculo de métricas e geração de relatórios — ao mesmo assistente de IA que você já usa para escrever código. O estudo de caso com o agente de pesquisa de viagens ilustrou como isso funciona na prática: transformando uma preocupação difusa de qualidade em uma correção específica em um local específico do código, com impacto esperado definido.

À medida que agentes assumem tarefas com maiores riscos e maior alcance, uma avaliação que vai além da verificação de saída se torna um pré-requisito para a prontidão em produção. O Agent-EvalKit foi projetado para tornar essa avaliação parte do mesmo fluxo de desenvolvimento que você já usa para escrever e revisar código de agentes.

Para leitura adicional sobre a solução, consulte Um Estudo Empírico sobre Automação de Avaliação de Agentes.

Fonte

Evaluate AI agents systematically with Agent-EvalKit (https://aws.amazon.com/blogs/machine-learning/evaluate-ai-agents-systematically-with-agent-evalkit/)

Novidade no Amazon Bedrock

A AWS anunciou, em junho de 2026, a expansão da disponibilidade dos modelos GPT-5.4 e GPT-5.5 da OpenAI no Amazon Bedrock. Agora, ambos os modelos estão acessíveis na região Leste dos EUA (Norte da Virgínia), ampliando as opções para equipes que constroem aplicações de Inteligência Artificial (IA) generativa na plataforma da AWS.

O que cada modelo oferece

GPT-5.5: o modelo mais avançado da OpenAI

O GPT-5.5 é descrito pela OpenAI como seu modelo mais capaz até o momento. Ele foi projetado para cenários que exigem alto nível de sofisticação, como:

• Programação avançada e desenvolvimento de software
• Pesquisa e análise aprofundada
• Operação de ambientes de software
• Fluxos de trabalho com documentos
• Tarefas agênticas de longa duração

Um diferencial importante do GPT-5.5 é a sua capacidade de compreender objetivos abertos, utilizar ferramentas, raciocinar ao longo de fluxos de trabalho extensos, lidar com ambiguidades e conduzir tarefas complexas até a conclusão — tudo isso com menos necessidade de orquestração manual por parte do desenvolvedor.

GPT-5.4: raciocínio de fronteira para produção

Já o GPT-5.4 traz raciocínio de fronteira para aplicações em ambiente de produção. Ele é indicado para casos de uso que envolvem:

• Programação e uso de computador
• Fluxos de trabalho com contexto longo
• Uso de ferramentas externas
• Interpretação de contexto em múltiplas etapas
• Interação com ferramentas e ambientes de software
• Verificação de saídas ao longo de processos com várias etapas

Especificações técnicas comuns

Tanto o GPT-5.4 quanto o GPT-5.5 compartilham as seguintes características técnicas:

• Janela de contexto de 272 mil tokens — ideal para processar grandes volumes de texto em uma única chamada
• Entradas de texto e imagem — suporte multimodal para aplicações mais ricas
• Disponibilidade via Responses API — com suporte a chamadas de ferramentas no lado do servidor e do cliente, projetos e streaming de respostas

Disponibilidade regional

Com este lançamento, os modelos GPT-5.4 e GPT-5.5 passam a estar disponíveis em regiões adicionais da AWS, incluindo agora a região Leste dos EUA (Norte da Virgínia). Para começar a utilizá-los, é possível consultar os cartões de modelo correspondentes na documentação oficial do Amazon Bedrock.

Fonte

OpenAI GPT-5.4 and GPT-5.5 models now available in US East (N. Virginia) on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/06/openai-gpt-us-east-virginia-amazon/)

O que separa as equipes que realmente ganham produtividade com IA das que ficam no mesmo lugar

Seis engenheiros. Setenta e seis dias. Um projeto originalmente estimado para 30 desenvolvedores trabalhando de 12 a 18 meses — entregue em menos de um trimestre. Esse não é um cenário hipotético: foi o que aconteceu quando uma equipe do Amazon Bedrock parou de tratar a IA como um atalho de codificação e passou a tratá-la como a fundação de todo o processo de trabalho. A equipe entregou mais código em produção em cinco meses do que nos dez anos anteriores somados.

A AWS publicou um estudo detalhado sobre o que chama de “frontier teams” — ou equipes de ponta — e o que elas têm em comum. O resultado é revelador: a diferença entre quem colhe ganhos reais de produtividade com IA e quem fica estagnado não está na escolha da ferramenta, mas na disposição de reestruturar completamente como o trabalho é feito.

O gargalo não é a IA — é o fluxo de trabalho

Agentes de codificação com IA mudaram radicalmente a velocidade com que o software é escrito. Os commits estão disparando, os pipelines de Integração Contínua/Entrega Contínua (CI/CD) estão mais movimentados do que nunca. Mas as funcionalidades chegando à produção não acompanharam esse ritmo.

O gargalo identificado pela AWS não é a capacidade do agente de gerar código. É o acesso do agente ao conhecimento necessário para tomar boas decisões — e a disposição da equipe de reorganizar o trabalho em torno dessa realidade.

As equipes de ponta não estão concentradas apenas em laboratórios de elite. Elas existem em diferentes setores e tamanhos de empresa, e compartilham uma disciplina comum: tratam a adoção de IA como um investimento de engenharia, não como a implantação de mais uma ferramenta.

Três caminhos para o desenvolvimento nativo com IA dentro da Amazon

Desenvolvimento de software nativo com IA significa tratar a IA como a base de como o software é construído, com agentes cada vez mais capazes sendo direcionados por especialistas humanos. A AWS identificou pelo menos três caminhos distintos ao experimentar com centenas de equipes de engenharia internas.

A iniciativa “pathfinder”: reconstruindo o motor de inferência do Bedrock

No primeiro caminho, seis engenheiros seniores receberam um único mandato: reconstruir o motor de inferência do Amazon Bedrock — um projeto originalmente estimado em 30 desenvolvedores trabalhando de 12 a 18 meses. Em vez de aumentar o headcount, a equipe passou as primeiras semanas redesenhando os fluxos de trabalho ao redor da IA: migrando de tarefas discretas para resultados orientados a objetivos, rodando múltiplos agentes em paralelo e configurando sistemas para que a IA trabalhasse de forma independente fora do horário comercial.

O projeto foi entregue em 76 dias. A produtividade individual dos desenvolvedores aumentou aproximadamente 20x, medida pela velocidade de commits normalizados — de 2 commits por semana para 40. A equipe entregou mais código de alta qualidade em cinco meses do que em projetos dos dez anos anteriores.

O sprint estruturado: Prime Video Financial Systems

O segundo caminho foi um experimento de 10 dias inspirado no modelo anterior. A equipe do Prime Video Financial Systems reuniu seis engenheiros em uma sala, com zero troca de contexto, sem plantões, sem outros projetos e com reuniões limitadas. Um engenheiro sênior passou três semanas antes do sprint decompondo a complexidade em tarefas bem delimitadas com requisitos detalhados.

A equipe usou desenvolvimento orientado a especificações para funcionalidades complexas e desenvolvimento assistido por agente diretamente para tarefas com requisitos já claros. Em 10 dias, produziram 556 commits contra uma linha de base de 96, e reduziram uma estimativa de projeto de 90 semanas para 24 semanas — quase 6x de throughput e 4x de aceleração.

Os três fatores que se multiplicaram para gerar esse resultado foram:

• Aceleração de trabalho de baixo julgamento: 1,5x
• Maior foco em trabalho de alto julgamento sem troca de contexto: 1,5x
• Acesso instantâneo à expertise de domínio capturada pelos agentes: 1,5x

A conclusão é importante: remova qualquer um desses três fatores e os ganhos desaparecem.

O experimento in-situ: Amazon Stores

No terceiro caminho, a Amazon Stores conduziu pilotos estruturados com equipes de desenvolvimento típicas trabalhando nos seus backlogs normais, usando o Kiro e ferramentas de IA específicas — sem condições especiais e sem engenheiros selecionados a dedo. Das mais de 50 equipes estudadas, as 25 que implementaram tanto novas ferramentas quanto novas práticas superaram significativamente as que simplesmente adicionaram IA aos fluxos existentes.

O ganho mediano de produtividade foi de 4,5x, com algumas equipes chegando a mais de 10x de melhoria na velocidade de implantação normalizada. A equipe Perfect Order Experience passou a entregar funcionalidades em uma tarde, em vez de duas semanas. O time WW Grocery reduziu a criação de documentos de design de cinco dias para algumas horas.

A lição é a mesma em todos os três caminhos: o fluxo de trabalho importa, não apenas a ferramenta.

As cinco práticas das equipes de ponta

Nos três caminhos, as equipes de melhor desempenho compartilham cinco práticas com uma lógica comum: reduzir as barreiras de contexto para o agente e aumentar a superfície de trabalho que ele consegue fazer de forma independente. Enquanto a abordagem histórica otimizava a velocidade de geração de código individual, as equipes de ponta otimizam outra coisa: a taxa com que software correto e pronto para produção chega aos clientes.

1. Invista no contexto do agente

As equipes mais avançadas investem pesadamente em tornar projetos e conhecimento mais fáceis de consumir pelos agentes — por meio de arquivos de direcionamento e orientações sobre convenções da equipe, padrões de codificação, testes e navegação no código-base. A equipe de infraestrutura do Bedrock colocou todo o código e documentação em um monorepo e manteve os comentários inline gerados pelos agentes de IA, tratando-os como memória persistente. Equipes que pulam essa etapa ficam se perguntando por que seus agentes continuam cometendo os mesmos erros.

2. Desacelere para acelerar depois

Toda equipe de alto desempenho relatou que as coisas inicialmente desaceleraram enquanto aprendiam os modelos. Elas codificaram expertise multifuncional em documentos de direcionamento reutilizáveis para os agentes, reestruturaram repositórios para que os LLMs (Modelos de Linguagem de Grande Escala) pudessem raciocinar sobre eles, e adicionaram comentários e rearquitetaram divisões de código para consumo pela IA. As equipes que atravessaram essa curva de aprendizado e definiram os resultados esperados primeiro experimentaram aceleração composta. As que esperaram ganhos imediatos sem mudar seus fluxos ficaram desapontadas. Espere que as duas primeiras semanas pareçam mais lentas. Espere que as semanas seguintes pareçam dramaticamente mais rápidas. As equipes que desistem na segunda semana nunca veem o efeito composto.

3. Alimente os agentes em vez de babá-los

Equipes de ponta mantêm um backlog constante de tarefas bem delimitadas com resultados claros, rodando múltiplos agentes em paralelo e revisando o output de forma assíncrona. Desenvolvedores relatam concluir funcionalidades importantes em curtos períodos, com o trabalho avançando mesmo quando não estão ativamente aguardando o agente completar uma tarefa. Um engenheiro principal entregou uma mudança completa com apenas “algumas horas de tempo contíguo” porque o agente trabalhou enquanto ele se movia entre revisões de código, suporte operacional e reuniões.

4. Torne a intenção explícita antes de o código ser escrito

Seja por meio de especificações estruturadas, documentos de requisitos detalhados ou decomposição de tarefas bem delimitadas, as equipes de ponta garantem que os agentes tenham contexto claro sobre o que significa “pronto” antes de começarem a gerar código. Algumas equipes que usam essa abordagem relatam escrever manualmente apenas 1 a 2% do código, enquanto enviam significativamente mais commits por pessoa por semana do que antes.

5. Antecipe os testes (“shift testing left”)

Equipes de ponta constroem ferramentas para que os agentes possam rodar todos os testes de integração localmente e se autocorrigir antes de o código chegar ao pipeline. A equipe do Prime Video investiu em guardrails automatizados, testes de componentes, testes de performance e formatadores que detectavam problemas cedo. As revisões de código passaram a focar em definições de interface e decisões arquiteturais, em vez de estilo de código e convenções de nomenclatura.

Fonte

How frontier teams are reinventing AI-native development (https://aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development/)

O problema que todo time de ML conhece bem

À medida que os modelos de IA crescem em escala e complexidade, uma tensão antiga volta à tona: o hardware tem um potencial teórico enorme, mas pouquíssimas equipes conseguem extrair esse potencial na prática. O desenvolvimento de kernels customizados sempre foi o caminho para fechar essa lacuna — mas esse caminho exige conhecimento profundo de arquitetura de chips, ciclos intermináveis de perfilamento manual e uma curva de aprendizado que poucos times podem se dar ao luxo de percorrer.

A AWS decidiu atacar esse problema de frente. A empresa anunciou o Neuron Agentic Development: um conjunto de agentes e habilidades de IA que torna o desenvolvimento de kernels de alta performance acessível para qualquer engenheiro de Machine Learning (ML) — não apenas para os especialistas em hardware. As capacidades estão disponíveis para desenvolvedores que trabalham com AWS Trainium e AWS Inferentia.

A proposta é ambiciosa: e se qualquer engenheiro de ML pudesse atuar como engenheiro de performance, escrevendo kernels com consciência de hardware, diagnosticando gargalos e entregando modelos otimizados — sem precisar de anos de experiência em nível de chip? E se um desenvolvedor experiente em outra arquitetura pudesse se adaptar ao Trainium em dias, não em meses?

O que é o Neuron Agentic Development

O pacote Neuron Agentic Development oferece cinco habilidades especializadas que seguem o pipeline natural de desenvolvimento de kernels: escrever → depurar → perfilar → analisar. Cada habilidade pode ser invocada individualmente para tarefas específicas, ou encadeada por meio do neuron-nki-agent, que seleciona automaticamente o fluxo de trabalho adequado com base na solicitação do desenvolvedor.

Para utilizá-las, basta adicionar as habilidades ao diretório de skills do seu Ambiente de Desenvolvimento Integrado (IDE) agêntico. Em IDEs como VS Code, Cursor ou Kiro, isso significa colocar os arquivos nos diretórios .kiro/skills ou .claude/skills. Vale destacar: as habilidades de perfilamento e depuração precisam ser executadas em uma instância do Amazon Elastic Compute Cloud (Amazon EC2) baseada em Trainium. As habilidades de escrita e documentação funcionam em qualquer ambiente.

Autoria de kernels

A habilidade neuron-nki-writing é o ponto de partida para criar kernels usando a Interface de Kernel Neuron (NKI). Ela traduz código PyTorch, NumPy ou descrições em linguagem natural para código NKI correto, já respeitando as restrições de hardware — como a dimensão de partição de 128 elementos e a dimensão livre de 512/4096 elementos no PSUM. A habilidade classifica a tarefa por complexidade e carrega apenas as referências necessárias para cada caso.

Depuração

A habilidade neuron-nki-debugging oferece um fluxo sistemático para resolver erros de compilação e execução de kernels NKI no Trainium e no Inferentia. Ela cobre desde a configuração do ambiente com as flags --target corretas até a resolução de erros do compilador, com um índice categorizado dos 28 códigos de erro do Compilador Neuron (NCC), além de validação numérica contra referências calculadas em CPU.

Perfilamento e análise

A habilidade neuron-nki-profiling captura perfis de execução diretamente no hardware. Ela configura as variáveis de ambiente de inspeção em tempo de execução, executa o kernel, identifica o Formato de Arquivo de Execução Neuron (NEFF) correto e captura o trace com o neuron-explorer — incluindo notificações do Motor de Grafo de Acesso Direto à Memória (DGE) para detalhes em nível de DMA. O resultado são arquivos JSON de métricas e arquivos NEFF que alimentam a próxima habilidade.

A habilidade neuron-nki-profile-querying, por sua vez, ingere os arquivos NEFF e NTFF e executa queries SQL para calcular limites de performance, identificar engines com gargalos e localizar ineficiências até linhas específicas do código-fonte NKI. Ela suporta três abordagens de análise: o servidor de API do neuron-explorer, DuckDB diretamente sobre arquivos parquet, ou pandas para computações customizadas.

Documentação

A habilidade neuron-nki-docs é utilizada em todas as fases do desenvolvimento. Durante a autoria, ela fornece assinaturas de API e tutoriais. Durante a depuração, explica códigos de erro. Durante o perfilamento, esclarece detalhes de arquitetura de hardware. É possível consultar APIs específicas como nisa.* ou nl.*, buscar tutoriais ou navegar pelos guias de arquitetura do Trainium 1, 2 e 3.

Os agentes: autonomia de ponta a ponta

Enquanto as habilidades oferecem blocos de construção para tarefas individuais, os agentes combinam múltiplas habilidades em fluxos de trabalho autônomos. Cada agente é uma persona especializada que gerencia cenários de desenvolvimento de múltiplas etapas do início ao fim.

• neuron-nki-agent: ponto de entrada unificado para o desenvolvimento NKI. Seleciona automaticamente o fluxo correto (escrita, depuração, perfilamento ou documentação) e orquestra as habilidades adequadas. É o ponto de partida recomendado.
• neuron-nki-writing-agent: focado exclusivamente na autoria de kernels. Traduz PyTorch, NumPy ou linguagem natural para código NKI e também lida com modificações em kernels existentes.
• neuron-nki-debugging-agent: resolve erros do compilador de forma autônoma — analisa o erro, busca soluções na documentação e aplica correções. Rastreia até 10 iterações e simplifica progressivamente quando encontra dificuldades.
• neuron-nki-docs-agent: navegador leve de documentação para assinaturas de API, explicações de códigos de erro, tutoriais e detalhes de arquitetura.
• neuron-nki-profile-analysis-agent: executa duas habilidades em sequência para identificar gargalos de performance — primeiro captura o perfil de execução no hardware, depois executa queries SQL contra os arquivos de perfil para calcular limites, identificar engines com problemas e localizar ineficiências no código-fonte.

Na prática: otimizando um kernel softmax customizado

O anúncio da AWS inclui um passo a passo detalhado que demonstra como essas capacidades funcionam juntas. O exemplo explora dois kernels: um kernel softmax e um kernel SwiGLU — este último comum em Grandes Modelos de Linguagem (LLMs).

Passo 0: configurando o ambiente

O primeiro passo é iniciar uma instância trn2.3xlarge por meio dos Blocos de Capacidade de ML da AWS (AWS MLCBs), usando a Imagem de Machine Learning de Aprendizado Profundo Neuron da AWS (DLAMI). As regiões de São Paulo (sa-east-1) e Melbourne (ap-southeast-4) são citadas como exemplos no artigo original. Após conectar via SSH, instala-se o Kiro e as habilidades do Neuron Agentic Development seguindo as instruções no repositório neuron-agentic-development. Para instruções detalhadas de configuração, a AWS disponibiliza o Guia de Configuração do Neuron DLAMI.

A DLAMI já vem com um ambiente virtual pré-instalado. Para ativá-lo e verificar os dispositivos Neuron disponíveis:

# Confirm Neuron devices are visible
neuron-ls
# Confirm neuron-explorer is available
which neuron-explorer && neuron-explorer --version

source ~opt/aws_neuronx_venv_pytorch_2_9/bin/activate

Com o ambiente configurado, inicia-se o desenvolvimento de kernels com:

kiro-cli --agent neuron-nki-agent

Atenção: instâncias trn2.3xlarge geram cobranças por hora enquanto estão em execução. Lembre-se de encerrá-las ao concluir o exercício.

Passo 1: escrevendo o kernel

Na sessão interativa do Kiro, o desenvolvedor descreve o que precisa em linguagem natural — por exemplo, solicitar um kernel NKI que compute um softmax com escala ao longo da última dimensão, para uma entrada em bfloat16. O agente produz um kernel completo de três passos (máximo por linha, soma de exponenciais, normalização), usando aceleração de hardware para a operação exponencial, acumulação em float32 para estabilidade numérica e tiling adequado. O agente também explica suas decisões de design, como o uso de P_MAX=128 (respeitando o limite de 128 partições do hardware) e F_MAX=2048 (respeitando o limite da dimensão livre no Trainium).

Passo 2: depurando no hardware

Ao solicitar que o agente execute o kernel e verifique a paridade numérica contra uma referência PyTorch, ele encontra um problema imediato: a operação nisa.tensor_tensor não faz broadcast automático de resultados de redução. O agente consulta os padrões de referência NKI, identifica o mecanismo correto de broadcast e reescreve o kernel. Após sincronizar o kernel corrigido e executá-lo no hardware, todos os casos de teste passam com erro máximo bem dentro da tolerância do bfloat16:

PASS: shape=(2, 128, 512), max_diff=0.000008
PASS: shape=(4, 256, 1024), max_diff=0.000004
PASS: shape=(1, 1, 64), max_diff=0.000061
PASS: shape=(2, 300, 768), max_diff=0.000007
All tests passed.

Passos 3 e 4: perfilando e analisando a execução

Para demonstrar o perfilamento em uma carga de trabalho real, o exemplo usa um kernel SwiGLU MLP — módulo comum em LLMs. O agente compila o kernel para um NEFF, captura um trace NTFF via neuron-explorer e conduz uma investigação em duas etapas: primeiro analisa estatísticas em nível de kernel e limites de performance; depois investiga ineficiências específicas consultando o perfil em nível de execução de instruções.

A análise revela que o Motor de Tensores (TE) domina a execução e apresenta grandes lacunas de ociosidade — o que sugere uma dependência do Motor de Acesso Direto à Memória (DMA). O agente encontra que as instruções de matmul já operam próximo ao pico de eficiência, mas as instruções DMA estão bem abaixo do tamanho-alvo (ineficientes) e que todas as entradas estão sendo recarregadas oito vezes (redundante). O agente identifica até as três linhas exatas do código NKI responsáveis pelas transferências subótimas — informação diretamente acionável para a próxima rodada de otimizações.

O que vem a seguir

As habilidades de autoria e perfilamento de kernels são apenas o primeiro passo de uma visão mais ampla. Atualmente, os desenvolvedores usam os insights de perfilamento para guiar a próxima rodada de edições no kernel — um ciclo iterativo de perfilar, diagnosticar, refatorar e re-perfilar que consome a maior parte do tempo. A AWS quer tornar esse loop totalmente agêntico: agentes que iteram autonomamente em um kernel até atingir a meta de performance, sem exigir que o desenvolvedor interprete cada resultado e crie manualmente a próxima correção.

Além disso, a empresa reconhece que kernels customizados são apenas uma parte de um desafio maior. Os desenvolvedores também querem que seus modelos rodem no Trainium sem precisar se preocupar com portabilidade de código, lacunas de operadores, otimizações em nível de modelo e validação de correção em escala. A visão declarada é aplicar a mesma abordagem agêntica a esse problema mais amplo — desde experimentação com novas arquiteturas de modelos até execução de modelos em produção em escala.

Para acompanhar as novidades e começar a usar o que já está disponível, a AWS indica o repositório GitHub do Neuron Agentic Development.

Como começar

As capacidades do Neuron Agentic Development já estão disponíveis. O caminho sugerido pela AWS é:

• Clonar o repositório neuron-agentic-development e escrever o primeiro kernel NKI em minutos.
• Começar com o neuron-nki-agent, que seleciona o fluxo correto com base na solicitação e oferece a experiência autônoma completa de ponta a ponta.
• Executar os exemplos de habilidades individualmente — como /neuron-nki-writing para tarefas específicas, ou encadear /neuron-nki-profiling e /neuron-nki-profile-querying após o kernel estar produzindo resultados corretos.
• Abrir uma issue no GitHub para reportar problemas ou sugerir melhorias — a AWS afirma estar desenvolvendo ativamente em conjunto com a comunidade.
• Contribuir com pull requests e compartilhar kernels construídos pela comunidade.

Limpeza do ambiente

Para evitar cobranças contínuas, é essencial encerrar a instância trn2.3xlarge criada durante o exercício. Isso pode ser feito pelo Console de Gerenciamento da AWS (EC2 > Instâncias, selecionar a instância e escolher Estado da instância > Encerrar) ou via linha de comando:

aws ec2 terminate-instances --instance-ids 

Confirme que o estado da instância mostra “terminated” antes de fechar o console.

Fonte

Stop hand-tuning kernels: How Neuron Agentic Development accelerates AWS Trainium optimizations (https://aws.amazon.com/blogs/machine-learning/stop-hand-tuning-kernels-how-neuron-agentic-development-accelerates-aws-trainium-optimizations/)

O problema que essa solução resolve

Quem trabalha com manutenção de maquinário agrícola pesado conhece bem o cenário: o técnico chega ao campo sem a peça certa, o equipamento fica parado, e durante a época de colheita cada hora de inatividade representa prejuízo real. A AWS publicou um guia técnico mostrando como o Amazon Bedrock AgentCore pode ser usado para construir um assistente de reparo com Inteligência Artificial (IA) que ajuda agricultores e técnicos de campo a diagnosticar problemas, identificar peças necessárias e acessar procedimentos de reparo aprovados pelos fabricantes — tudo por linguagem natural.

Visão geral da arquitetura

A solução combina um frontend web com um agente hospedado no AgentCore que responde perguntas de diagnóstico consultando documentação técnica indexada dos fabricantes. Os componentes principais são:

• AgentCore Runtime com o Strands Agents SDK para hospedar e executar o agente
• Amazon Nova 2 Lite como modelo de fundação para inferência
• Amazon Bedrock Knowledge Base para Geração Aumentada por Recuperação (RAG — Retrieval-Augmented Generation)
• AgentCore Memory para persistência de conversas entre sessões
• Amazon Cognito para autenticação de usuários
• AWS Amplify para hospedar a aplicação web React

A arquitetura é organizada em quatro seções principais:

• Seção A – Autenticação e Frontend: Uma stack do CloudFormation implanta o Amazon Cognito (User Pool e Identity Pool) e o AWS Amplify. Os usuários se autenticam pelo Cognito, e o frontend se comunica diretamente com o endpoint do AgentCore Runtime.
• Seção B – AgentCore Runtime: Hospeda o agente baseado em Strands e expõe o endpoint /invocations. O frontend chama esse endpoint usando um token Bearer do Cognito. O agente roteia requisições internamente com base no campo path do payload (/chat para consultas de IA e /issues para operações de criação, leitura, atualização e exclusão — CRUD).
• Seção C – Processamento com IA: O agente Strands usa uma ferramenta customizada chamada search_equipment_knowledge que consulta a Base de Conhecimento do Bedrock via API retrieve_and_generate. A Base de Conhecimento indexa documentação armazenada no Amazon S3 usando o Amazon OpenSearch Serverless para busca vetorial e o Amazon Titan Embeddings para correspondência semântica.
• Seção D – Dados e Memória: O Amazon DynamoDB armazena os chamados de serviço dos equipamentos. O AgentCore Memory oferece memória de curto prazo (dentro da sessão) e de longo prazo (entre sessões). O Amazon CloudWatch e o AWS X-Ray fornecem observabilidade automática.

Como o fluxo de uma consulta funciona

O caminho percorrido desde a pergunta do técnico até a resposta do agente segue estas etapas:

• O técnico abre a aplicação web e se autentica pelo Amazon Cognito.
• A pergunta é enviada ao endpoint /invocations do AgentCore Runtime com um token Bearer do Cognito.
• O AgentCore valida o token, encaminha a requisição ao agente e recupera o contexto de conversas anteriores.
• O agente Strands envia a consulta ao Amazon Nova 2 Lite para inferência.
• O modelo invoca a ferramenta search_equipment_knowledge, que consulta a Base de Conhecimento do Bedrock.
• A Base de Conhecimento pesquisa os manuais indexados e retorna documentação relevante com citações de fontes.
• O modelo sintetiza uma resposta de diagnóstico com procedimentos de reparo e recomendações de peças, devolvendo o resultado ao técnico com atribuição de fonte para verificação.

O código da ferramenta de busca na Base de Conhecimento

O trecho abaixo mostra como a ferramenta de recuperação do agente consulta a documentação dos fabricantes:

@tool
def search_equipment_knowledge(query: str) -> str:
    """Search equipment manuals, parts catalogs, and repair docs."""
    response = bedrock_agent_runtime.retrieve_and_generate(
        input={"text": query},
        retrieveAndGenerateConfiguration={
            "type": "KNOWLEDGE_BASE",
            "knowledgeBaseConfiguration": {
                "knowledgeBaseId": KNOWLEDGE_BASE_ID,
                "modelArn": f"arn:aws:bedrock:{REGION}::foundation-model/{MODEL_ID}",
            },
        },
    )
    return response.get("output", {}).get("text", "No results found.")

Pré-requisitos e estimativa de custos

Antes de começar a implantação, é necessário ter:

• Uma conta AWS com permissões adequadas para implantar agentes AgentCore. As permissões de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management) necessárias estão documentadas em IAM Permissions for AgentCore Runtime.
• Acesso ao modelo Amazon Nova 2 Lite no Amazon Bedrock na região de implantação. É possível usar outro modelo suportado — consulte disponibilidade de modelos por região.
• AWS Command Line Interface (AWS CLI) v2.0 ou superior instalado e configurado.
• Python 3.10 ou mais recente instalado.

Em termos de custos para testes, os principais são as invocações do modelo Amazon Nova 2 Lite (US$ 0,30/US$ 2,50 por milhão de tokens de entrada/saída) e a Base de Conhecimento do Bedrock (OpenSearch Serverless a aproximadamente US$ 0,24/hora enquanto ativo). Os demais serviços — AgentCore Runtime, Amazon DynamoDB, Amazon S3, Amazon Cognito e AWS Amplify — se enquadram no nível gratuito da AWS para volumes de teste. Para estimativas detalhadas, utilize a AWS Pricing Calculator.

Criando a Base de Conhecimento

Passo 1: Prepare a documentação

Para testes, a AWS recomenda baixar manuais de equipamentos da John Deere Technical Information Store — o guia usa especificamente os manuais dos tratores compactos John Deere 1023E e 1025R. Também é possível usar a documentação da própria organização. Os documentos devem ser pesquisáveis por texto (não imagens escaneadas), com nomenclatura consistente e sem informações proprietárias que não devam ser acessíveis a todos os usuários.

Passo 2: Crie um bucket S3 para a Base de Conhecimento

aws s3 mb s3://agriculture-kb-documents-<unique-suffix>
aws s3 cp ./equipment-docs s3://agriculture-kb-documents-<unique-suffix> --recursive

Passo 3: Crie a Base de Conhecimento do Bedrock

Siga as instruções da documentação para criar a Base de Conhecimento com as seguintes configurações:

• Nome: Agriculture-Equipment-Repair-KB
• Fonte de dados: o bucket S3 criado no passo anterior
• Estratégia de parsing: parser padrão do Amazon Bedrock
• Estratégia de chunking: chunking padrão
• Modelo de embeddings: Amazon Titan Embeddings G1 – Text
• Vector store: criação rápida de um novo (Amazon OpenSearch Serverless)

Passo 4: Sincronize e teste a Base de Conhecimento

Após criar a Base de Conhecimento, sincronize a fonte de dados para iniciar a ingestão dos documentos (normalmente 10 a 20 minutos). Consulte como sincronizar suas fontes de dados. Use a funcionalidade de teste no console do Bedrock para verificar se a Base de Conhecimento responde corretamente. Anote o ID da Base de Conhecimento na página de detalhes.

Implantando a solução

Passo 5: Implante a infraestrutura de suporte

Inicie a stack do CloudFormation. Nos parâmetros, informe um nome para o deployment (padrão: ag-repair-assist) e o ID da Base de Conhecimento do passo anterior. Após a conclusão, anote os valores da aba Outputs da stack — eles serão usados nos passos seguintes.

Passo 6: Implante o agente a partir da máquina local

Com Python 3.10 ou superior e credenciais AWS configuradas, execute os seguintes comandos:

mkdir agriculture-repair-agent && cd agriculture-repair-agent
python3 -m venv .venv
source .venv/bin/activate

pip install "bedrock-agentcore-starter-toolkit>=0.1.21" strands-agents strands-agents-tools boto3

Em seguida, baixe e extraia o código do agente (dois arquivos: agriculture_repair_agent.py e requirements.txt). Configure o agente com:

agentcore configure -e agriculture_repair_agent.py

Durante a configuração interativa, selecione “Direct Code Deploy” (sem Docker), informe o ARN do papel de execução, a URL de descoberta OAuth do Cognito e o ID do cliente do User Pool — todos obtidos dos Outputs do CloudFormation. Depois, faça o deploy:

agentcore launch --env KNOWLEDGE_BASE_ID=<your-kb-id> --env TABLE_NAME=<EquipmentIssuesTableName> --env MODEL_ID=us.amazon.nova-2-lite-v1:0

O processo leva aproximadamente 5 a 10 minutos. Ao final, anote o ARN do AgentCore Runtime gerado.

Passo 7: Implante o frontend

Baixe o arquivo ML-18699-FrontEnd.zip, acesse o console do AWS Amplify pela URL fornecida nos Outputs do CloudFormation, clique em “Deploy updates”, escolha o método de arrastar e soltar, selecione o arquivo .zip e aguarde a conclusão do deploy.

Usando a aplicação

Acesse a URL da aplicação Amplify, configure os valores obtidos nos passos anteriores, crie uma conta, verifique o e-mail e faça login. Alguns exemplos de consultas para testar:

• Análise de problema: “My John Deere 1023E series tractor is losing hydraulic pressure on the left side when lifting heavy implements. The pressure drops from 2500 PSI to about 1800 PSI under load.”
• Consulta técnica: “What hydraulic fluid is recommended for John Deere 1025R?”

Limpeza dos recursos

Os recursos implantados geram cobranças contínuas até serem removidos. Para encerrar tudo:

agentcore destroy

aws cloudformation delete-stack --stack-name ag-repair-assist

No console do Amazon Bedrock Knowledge Bases, selecione Agriculture-Equipment-Repair-KB e escolha Delete. Por fim, esvazie e remova o bucket S3:

aws s3 rm s3://agriculture-kb-documents-<unique-suffix> --recursive
aws s3 rb s3://agriculture-kb-documents-<unique-suffix>

Considerações para produção

A solução foi projetada para ser leve e servir como ponto de partida. Para ambientes produtivos, a AWS recomenda considerar os seguintes aprimoramentos:

• Amazon Bedrock Guardrails: Adicionar detecção de ataques de prompt e filtragem de conteúdo para proteger contra entradas maliciosas, além de configurar tópicos negados para limitar o escopo do agente.
• Proteção de API: Posicionar o Amazon CloudFront na frente do endpoint do AgentCore Runtime com AWS WAF para limitação de taxa e proteção OWASP.
• Autenticação multifator: Habilitar MFA no Amazon Cognito com tokens de software baseados em TOTP.
• Observabilidade e alertas: O AgentCore gera automaticamente métricas, logs e rastreamentos visíveis nos dashboards de observabilidade de IA generativa do Amazon CloudWatch. Configure alarmes para taxas de erro e latência de resposta.
• Ciclo de vida dos dados: Implementar políticas de ciclo de vida no Amazon S3 para versionamento de documentação e recuperação point-in-time no Amazon DynamoDB.
• Deploy multi-região: Para equipes de campo globais, implantar o AgentCore Runtime em múltiplas regiões AWS com Bases de Conhecimento específicas por região.

Próximos passos e extensibilidade

Uma das vantagens da arquitetura é que novas capacidades podem ser adicionadas simplesmente criando uma nova função com o decorador @tool no código do agente — sem necessidade de alterações na infraestrutura. Algumas extensões sugeridas pela AWS:

• Integração com pedidos de peças: Uma ferramenta @tool que conecta ao sistema de estoque e permite verificar disponibilidade e fazer pedidos diretamente da conversa de diagnóstico.
• Comunicação com revendedores: Uma ferramenta que envia resumos de diagnóstico ao revendedor autorizado mais próximo via Amazon Simple Email Service (SES) ou Amazon Simple Notification Service (SNS).
• Integração com telemetria IoT: Conectar sensores dos equipamentos via AWS IoT Core para criar chamados automaticamente quando leituras anômalas forem detectadas, pré-populando o contexto de diagnóstico do agente.
• Aplicativo mobile para campo: Construir um frontend otimizado para mobile com cache offline para áreas com conectividade limitada.

Benefícios da implementação

De acordo com a AWS, os principais benefícios dessa arquitetura são:

• Redução do tempo médio de resolução por meio de diagnósticos mais rápidos fundamentados na documentação dos fabricantes
• Melhora nas taxas de resolução na primeira visita, já que os técnicos chegam ao local com as peças e procedimentos corretos
• Memória de conversa que mantém contexto dentro de sessões e persiste conhecimento entre sessões
• Operações simplificadas: um único endpoint AgentCore Runtime substitui a necessidade de API Gateway, Lambda e Bedrock Agent separados
• Observabilidade integrada com rastreamento X-Ray e integração com CloudWatch sem configuração adicional
• Desenvolvimento orientado a código com o padrão @tool do Strands Agent, permitindo extensão e teste local antes do deploy

O código de exemplo deste guia está disponível sob a licença MIT-0.

Recursos adicionais

• Documentação do Amazon Bedrock AgentCore
• Strands Agents SDK
• Guia do Usuário do Amazon Bedrock
• Amazon Bedrock Knowledge Bases

Fonte

Build an AI-Powered Equipment Repair Assistant Using Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-an-ai-powered-equipment-repair-assistant-using-amazon-bedrock-agentcore/)

Expansão das instâncias P6-B200 para o ambiente governamental da AWS

A AWS anunciou a disponibilidade das instâncias Amazon Elastic Compute Cloud (Amazon EC2) P6-B200 na região AWS GovCloud (US-East). Aceleradas pelas GPUs NVIDIA Blackwell, essas instâncias chegam a mais uma região, ampliando o acesso a cargas de trabalho de Inteligência Artificial (IA) em ambientes com requisitos regulatórios governamentais.

O que são as instâncias P6-B200?

As instâncias EC2 P6-B200 são projetadas para cargas de trabalho intensivas de treinamento e inferência de IA. Em comparação com as instâncias P5en — a geração anterior de referência —, as P6-B200 entregam até 2x mais desempenho, um salto considerável para equipes que trabalham com modelos de grande escala.

Do ponto de vista técnico, cada instância conta com:

• 8 GPUs NVIDIA Blackwell
• 1.440 GB de memória GPU de alta largura de banda
• 60% mais largura de banda de memória GPU em relação às P5en
• Processadores Intel Xeon de 5ª Geração (Emerald Rapids)
• Até 3,2 terabits por segundo de rede via Elastic Fabric Adapter (EFAv4)

Segurança e escalabilidade com o AWS Nitro System

As instâncias P6-B200 são alimentadas pelo AWS Nitro System, a arquitetura de virtualização da AWS que oferece isolamento de hardware, segurança reforçada e desempenho próximo ao bare metal. Graças a essa base, é possível escalar cargas de trabalho de IA de forma confiável dentro dos Amazon EC2 UltraClusters, chegando a dezenas de milhares de GPUs interconectadas.

Para organizações governamentais e parceiros que precisam operar em ambientes com controles rigorosos de conformidade, essa combinação — hardware de ponta com a infraestrutura segura do Nitro — representa um diferencial importante.

Disponibilidade por região

As instâncias P6-B200 estão disponíveis no tamanho p6-b200.48xlarge nas seguintes regiões da AWS:

• US West (Oregon)
• US East (N. Virginia)
• US East (Ohio)
• AWS GovCloud (US-West)
• AWS GovCloud (US-East) — novidade anunciada agora

Saiba mais

Para equipes que desejam entender melhor as especificações técnicas, casos de uso recomendados e como provisionar essas instâncias, a AWS disponibiliza documentação detalhada na página oficial: Instâncias Amazon EC2 P6.

Fonte

Amazon EC2 P6-B200 instances are now available in the AWS GovCloud (US-East) Region (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ec2-p6-b200-aws-govcloud/)