Author: Make.com Service User

O problema: um modelo que pensa só em inglês

O GPT-OSS-20B é um modelo de raciocínio de código aberto com um comportamento peculiar: independentemente do idioma em que você faz uma pergunta, ele raciocina em inglês. Peça para ele pensar em francês, alemão, espanhol ou italiano — ele reconhece a instrução, mas produz a cadeia de raciocínio em inglês mesmo assim.

Em um teste de avaliação com 50 exemplos multilíngues, o modelo base raciocinou no idioma-alvo correto em apenas 22% dos casos. Esse número, na prática, é quase inteiramente composto pelos exemplos em inglês: inglês atingiu 100%, enquanto francês e espanhol ficaram em 0%, alemão em 10% e italiano em 0%.

Para equipes que implantam modelos de raciocínio para usuários não anglófonos, essa lacuna é um problema real. Um usuário que pergunta em francês espera que o modelo raciocine e responda em francês — não que mude para o inglês no meio do pensamento. Fechar essa lacuna é um desafio de fine-tuning.

A questão que toda equipe enfrenta ao customizar modelos de peso aberto é: usar Ajuste Fino Supervisionado (SFT), Aprendizado por Reforço com Otimização de Política Relativa de Grupo (GRPO), ou os dois? A AWS publicou um artigo técnico detalhando exatamente essa decisão, com experimentos reais no Amazon SageMaker HyperPod.

Visão geral da solução

A tarefa e o conjunto de dados

O dataset utilizado foi o HuggingFaceH4/Multilingual-Thinking — um conjunto de dados de raciocínio com cadeia de pensamento traduzido para francês, espanhol, alemão e italiano, além do inglês, com aproximadamente 949 exemplos de treino e 50 de validação. O modelo recebe uma instrução de sistema indicando o idioma de raciocínio e deve tanto raciocinar quanto responder nesse idioma-alvo, sobrepondo-se ao forte viés pelo inglês.

A avaliação consiste em 50 casos de teste: 10 problemas de matemática e lógica em cada um dos 5 idiomas (EN/FR/DE/ES/IT). Duas métricas são acompanhadas:

• Raciocínio no idioma correto — a cadeia de pensamento está no idioma solicitado?
• Resposta no idioma correto — a resposta final está no idioma solicitado?

Como SFT e GRPO se complementam

A forma mais clara de entender as duas técnicas é esta:

• SFT ensina um comportamento que o modelo ainda não tem.
• GRPO otimiza um comportamento que o modelo já consegue produzir às vezes.

O GRPO funciona amostrando um grupo de respostas por prompt e empurrando a política em direção às respostas acima da média. Se o comportamento desejado tem probabilidade zero na distribuição base, há muito pouco para o GRPO reforçar. Essa ideia central explica praticamente todos os resultados do experimento.

A infraestrutura de treinamento

O treinamento foi executado no Amazon SageMaker HyperPod com orquestração pelo Serviço de Kubernetes Elástico da Amazon (Amazon EKS). Para os experimentos iniciais de SFT e GRPO no GPT-OSS-20B, foi utilizada a biblioteca PyTorch TRL. Para o experimento de controle com Qwen, a equipe migrou para o veRL como trainer, com Ray e KubeRay para orquestração distribuída e vLLM para geração rápida de rollouts.

Checkpoints e datasets ficaram armazenados no Amazon FSx for Lustre, e o fabric de comunicação entre nós utilizou o Adaptador de Malha Elástica (EFA). Todo o fine-tuning usou Adaptação de Baixo Posto (LoRA), que é eficiente em parâmetros e adequada tanto para SFT quanto para GRPO.

O diagrama abaixo ilustra o caminho completo dos dados de treinamento de ponta a ponta:

O fluxo começa com uma submissão via AWS CLI ou Amazon SageMaker Studio. O plano de controle do Amazon EKS no cluster HyperPod aloca pods em nós GPU e inicializa um Ray head com pods worker para o trainer veRL e os workers de rollout vLLM. O Amazon FSx for Lustre fornece armazenamento compartilhado de alta vazão para o modelo base, os dados de treinamento e os checkpoints. Ao final do treinamento, o adapter LoRA é gravado de volta no FSx para avaliação ou serving.

Configurando o ambiente de treinamento

Todos os comandos, manifestos e scripts estão no repositório GitHub awsome-distributed-ai, no diretório 3.test_cases/pytorch/trl/gpt-oss-lora-grpo/. Para começar:

git clone https://github.com/aws-samples/awsome-distributed-ai
cd awsome-distributed-ai/3.test_cases/pytorch/trl/gpt-oss-lora-grpo

Copie o template de variáveis de ambiente, edite o arquivo env_vars com seu registro ECR, nome da imagem, tag e token do HuggingFace, e construa a imagem de treinamento:

cp env_vars.example env_vars
source env_vars
cd artifacts && ./build_push.sh && cd ..

Em seguida, aponte o kubectl para o cluster e aplique o pod de gerenciamento de armazenamento FSx:

aws eks update-kubeconfig --name <YOUR_CLUSTER_NAME> --region us-east-2
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/fsx-storage-manager.yaml | kubectl apply -f -

Fine-tuning com SFT e LoRA

A lacuna do modelo base

O GPT-OSS-20B base na avaliação de 50 casos marcou 22% de raciocínio no idioma correto (11/50). Por idioma: inglês 100%, francês 0%, alemão 10%, espanhol 0%, italiano 0%. O modelo ignora a instrução de idioma e raciocina em inglês de qualquer forma.

Configuração do SFT

O SFT utilizou LoRA r=8, α=16, treinado por 1.000 passos em 4× ml.g6e.12xlarge (16× L40S 48GB) com Paralelismo de Dados Totalmente Fragmentado (FSDP) full-shard, precisão bf16 e gradient checkpointing. O job roda como um HyperPodPyTorchJob elástico gerenciado pelo Kueue, iniciado com hyperpodrun.

envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < hyperpod-eks/train-lora-hyperpod-elastic-g6e.yaml | kubectl apply -f -

Uma execução saudável apresenta logs como este:

{'loss': 1.035, 'grad_norm': 0.163, 'learning_rate': 0.0002, 'mean_token_accuracy': 0.716, 'epoch': 3.25}
{'loss': 1.003, 'grad_norm': 0.171, 'lr': 0.0002, 'acc': 0.722, 'epoch': 3.32}
{'loss': 0.976, 'grad_norm': 0.159, 'lr': 0.0002, 'acc': 0.726, 'epoch': 3.57}

Resultados do SFT e a curva de aprendizado em estágios

Após o SFT, o modelo raciocina no idioma correto em 100% dos casos (50/50) nos cinco idiomas. O aprendizado ocorreu em dois estágios:

• Por volta do passo 200, o modelo aprendeu a raciocinar no idioma-alvo (métrica de raciocínio atinge 100%).
• Por volta do passo 1.000, o modelo aprendeu também a dar a resposta final no idioma-alvo.

Avaliação final do SFT (passo 1.000): raciocínio no idioma correto 100% (50/50); resposta no idioma correto 62% (31/50); ambos corretos 62% (31/50). Por idioma na resposta: FR 60%, DE 60%, ES 30%, IT 60%, EN 100%.

Conclusão: o SFT não é opcional aqui. O modelo base não consegue seguir a instrução de idioma de raciocínio, e o SFT eleva a métrica de 22% para 100%. A lacuna restante está na resposta final (62%) — a parte mais difícil, pois a resposta é curta e o viés pelo inglês é mais forte ali.

Refinando com GRPO

A acurácia da resposta no idioma correto era o alvo óbvio para o GRPO. O SFT já havia produzido raciocínio correto 100% das vezes, e o modelo às vezes produzia a resposta no idioma certo — havia sinal para reforçar.

Executando GRPO sobre o checkpoint SFT

O GRPO foi executado com o GRPOTrainer do TRL, partindo do checkpoint SFT. A configuração: carregar o LoRA do SFT, chamar merge_and_unload e adicionar um novo LoRA (r=8, α=16, cerca de 0,068% de parâmetros treináveis, 13,6M de 20B). O treinamento usou K=8 gerações por prompt, device_map=auto, taxa de aprendizado 1e-6 e 10 épocas.

A função de recompensa pontuou: idioma da resposta (±5,0), idioma do raciocínio (±1,5) e brevidade (+0,5 ou −1,0), com intervalo combinado de −7,5 a +7,0.

envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/train-grpo-singlenode.yaml | kubectl apply -f -
kubectl logs -f grpo-single

Resultados do GRPO

Partindo do checkpoint SFT: raciocínio no idioma correto 100% (mantido — o GRPO não quebrou o que o SFT ensinou); resposta no idioma correto: de 62% para 70% (+8 pontos, 35/50); ambos corretos: 70%. Por idioma na resposta: FR 70%, DE 80%, ES 60%, IT 40%, EN 100%.

O GRPO entregou um ganho real de +8 pontos na métrica de resposta no idioma correto, mantendo o raciocínio em 100%. O ganho veio onde havia margem para crescer.

Comparando base, SFT e GRPO na prática

Para visualizar a diferença qualitativa, é possível implantar três pods de inferência que compartilham o mesmo modelo base, mas carregam adapters diferentes:

envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/inference-g6e-base.yaml | kubectl apply -f -
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/inference-g6e-trained.yaml | kubectl apply -f -
envsubst '$REGISTRY $IMAGE $TAG $HF_TOKEN' \
  < kubernetes/inference-g6e-grpo.yaml | kubectl apply -f -

Rodando o mesmo prompt de raciocínio em francês em cada variante:

• O pod base raciocina em inglês, ignorando a instrução.
• O pod SFT raciocina em francês, mas frequentemente responde em inglês.
• O pod GRPO raciocina e responde em francês.

Experimento de controle com Qwen2.5-7B

Para testar a tese “adequar a técnica à lacuna de capacidade” em um modelo diferente, a AWS rodou experimentos controlados no Qwen2.5-7B-Instruct em duas tarefas com lacunas distintas.

Raciocínio multilíngue (50 casos)

Resultados comparando base (A), SFT apenas (B) e SFT+GRPO (C):

• Formato estruturado: A=0%, B=92%, C=98% (Δ GRPO: +6)
• Idioma do raciocínio: A=0%, B=96%, C=98% (Δ GRPO: +2)
• Idioma da resposta: A=0%, B=38%, C=44% (Δ GRPO: +6)
• Ambos corretos: A=0%, B=38%, C=44% (Δ GRPO: +6)

GSM8K — uma tarefa sem margem de melhoria

No GSM8K, o Qwen2.5-7B base já marcava 90,5% (181/200). O GRPO no passo 30 também marcou 90,5%. Quando a maioria dos grupos amostrados está toda correta, a vantagem relativa do grupo colapsa para zero — não há sinal de aprendizado. Esse é o outro lado da tese: o GRPO precisa de margem (pass@k muito maior que pass@1) para ter algo a otimizar. Sem margem, sem ganho.

Boas práticas

• Comece com SFT. O GRPO não consegue ensinar um comportamento com probabilidade zero na distribuição base. O SFT elevou o raciocínio no idioma correto de 22% para 100%, e cada ganho do GRPO neste trabalho foi construído sobre esse checkpoint SFT.
• Use LoRA para SFT e GRPO. LoRA r=8/α=16 foi eficiente em parâmetros (0,068% treináveis) e permaneceu numericamente estável durante o GRPO no experimento com Qwen (grad norm 0,23, cerca de 11,7 GB por GPU).
• Adeque a técnica à lacuna. Use SFT para comportamentos ausentes. Use GRPO para refinar comportamentos que o modelo já produz às vezes. O teto realista do GRPO aqui foi de +6 a +8 pontos.
• Verifique se há margem antes de gastar horas de GPU. Se a maioria dos grupos está toda correta (como no GSM8K com 90,5% base), a vantagem relativa colapsa para zero e o GRPO não recebe gradiente.

Limpeza de recursos

Para evitar cobranças contínuas, exclua os recursos de workload e depois a infraestrutura subjacente:

kubectl delete hyperpodpytorchjob lora-hyperpod-elastic --ignore-not-found
kubectl delete pod grpo-single inference-base inference-trained inference-grpo \
  eval-grpo fsx-storage-manager --ignore-not-found

Em seguida, reduza ou exclua o cluster Amazon SageMaker HyperPod ou seus grupos de nós, exclua o sistema de arquivos Amazon FSx for Lustre após exportar os checkpoints desejados e remova quaisquer buckets ou objetos do Amazon Simple Storage Service (Amazon S3) usados para dados de treinamento ou arquivos de checkpoint.

Conclusão

O experimento da AWS demonstra como fazer fine-tuning do GPT-OSS-20B para raciocínio multilíngue no Amazon SageMaker HyperPod e como decidir entre SFT e GRPO. O SFT fez a maior parte do trabalho: o raciocínio no idioma correto foi de 22% para 100%. O GRPO adicionou um refinamento real e modesto (+8 pontos na resposta) onde havia margem.

O experimento de controle com Qwen2.5-7B confirmou o padrão: GRPO adicionou +6% no raciocínio multilíngue, onde havia espaço para melhorar, e não adicionou nada no GSM8K, onde o modelo já estava no pico de acurácia (90,5%).

Framework de decisão:

• Comportamento que o modelo não consegue fazer: use SFT.
• Comportamento que ele faz às vezes, com margem: use SFT e depois GRPO para mais alguns pontos.
• Modelo já no pico de acurácia, ou alvo com probabilidade zero na base: GRPO não vai ajudar.

Para experimentar por conta própria, o repositório awsome-distributed-ai contém todos os casos de teste. Para mais informações sobre o Amazon SageMaker HyperPod, consulte a página de detalhes do serviço e a documentação oficial do Amazon SageMaker HyperPod.

Fonte

Fine-tuning GPT-OSS-20B for multilingual reasoning on Amazon SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/fine-tuning-gpt-oss-20b-for-multilingual-reasoning-on-amazon-sagemaker-hyperpod/)

O que é o TorchNeuron?

A AWS anunciou o lançamento em beta público do TorchNeuron, um backend nativo e de código aberto para PyTorch voltado aos chips AWS Trainium. Para quem trabalha com treinamento e inferência de modelos de inteligência artificial, essa é uma novidade relevante: agora é possível rodar código PyTorch diretamente no hardware Trainium de forma muito mais simples.

Os chips Trainium fazem parte do portfólio de chips de IA da AWS, projetados para entregar alto desempenho e eficiência de custo em cargas de trabalho de aprendizado profundo — tanto para treinamento quanto para inferência.

Como funciona na prática

O grande diferencial do TorchNeuron é a simplicidade de integração. Cientistas e pesquisadores de IA podem experimentar e construir modelos usando PyTorch nativamente no Trainium. Na prática, basta trocar o dispositivo no código para .to('neuron') — e o código PyTorch passa a rodar no hardware Trainium.

Um ponto importante é que o TorchNeuron mantém compatibilidade total com o PyTorch, incluindo:

• Execução eager (modo padrão do PyTorch)
• torch.compile
• APIs padrão do PyTorch

Isso significa que desenvolvedores não precisam reescrever seus modelos ou adaptar o fluxo de trabalho — a migração para o Trainium acontece com alteração mínima no código existente.

Integração com a Interface de Kernel Neuron (NKI)

Além da compatibilidade nativa com PyTorch, o TorchNeuron se integra com a Interface de Kernel Neuron (NKI), permitindo a criação de operadores customizados e otimizações de desempenho específicas para o hardware Trainium. Essa integração é especialmente útil para quem precisa extrair o máximo de performance dos chips em cenários avançados.

Disponibilidade

O TorchNeuron está disponível como código aberto no repositório GitHub do TorchNeuron e pode ser utilizado em instâncias Amazon EC2 Trainium2 e Amazon EC2 Trainium3.

Para mais detalhes sobre o TorchNeuron e os aceleradores AWS Trainium, vale conferir a página oficial do AWS Neuron.

Por que isso importa

Para profissionais que já utilizam PyTorch no dia a dia, o TorchNeuron remove uma barreira significativa de adoção do hardware Trainium. Em vez de aprender frameworks novos ou adaptar pipelines inteiros, a transição se resume a uma mudança pontual no código. Combinado com o fato de ser open source, isso pode acelerar a experimentação e adoção dos chips de IA da AWS em projetos de treinamento e inferência de modelos de aprendizado profundo.

Fonte

AWS announces TorchNeuron: Native PyTorch Support for AWS Trainium (Public Beta) (https://aws.amazon.com/about-aws/whats-new/2026/10/aws-announce-native-pytorch-support-trainium)

O problema: muitos dados, pouca agilidade nas decisões

Toda cadeia de suprimentos gera sinais o tempo todo — pedidos em aprovação, prazos de entrega mudando, portos congestionados, preços oscilando, interrupções inesperadas. O problema nunca foi falta de dados. O problema é a distância entre o dado e quem precisa tomar a decisão.

Responder a uma pergunta como “quais SKUs de maior receita estão expostos ao fechamento atual do porto e quanto isso vai custar?” exigia saber qual sistema tinha cada pedaço da informação, cruzar tudo manualmente e entregar ao especialista de domínio — que ficava esperando. E se esse gestor pudesse simplesmente perguntar em linguagem natural e receber uma resposta acionável, cruzando múltiplos sistemas, em segundos?

É exatamente essa proposta que a AWS apresenta com a combinação do Amazon Bedrock AgentCore e do Amazon Quick. O AgentCore funciona como a camada de inteligência, expondo servidores de Protocolo de Contexto de Modelo (MCP) corporativos como ferramentas combináveis. O Amazon Quick transforma isso em ação para usuários de negócio, sem configuração técnica. As respostas vêm de sistemas de registro ao vivo e documentos fundamentados — não da memória do modelo — e qualquer alteração aguarda aprovação humana.

No cenário tradicional, cada pergunta exige uma ferramenta diferente: estoque vem do sistema de Planejamento de Recursos Empresariais (ERP), interrupções vêm de e-mail ou notícias, cotações vêm do sistema de compras e conformidade vem de um checklist. Correlacionar tudo isso é um trabalho manual e demorado.

Um dia típico sem a solução

A manhã de um gestor de supply chain normalmente envolve acessar o ERP (exceções de estoque), ferramenta de monitoramento (alertas), sistema de compras (alternativas), e-mail (cotações) e um rastreador — de 45 a 60 minutos em cinco sistemas, com mais de uma dúzia de trocas de contexto. Com a abordagem conversacional, isso se resume a três prompts em uma única ferramenta, em minutos:

• “Há interrupções críticas afetando meus SKUs de maior receita?”
• “Avalie a parada da TechComp e emita uma Solicitação de Cotação (RFQ) emergencial para alternativas aprovadas”
• “Parece bom. Envie.”

Cenário detalhado: da detecção à ação em uma conversa

O artigo original da AWS demonstra cinco passos que acompanham uma interrupção desde a detecção até a aprovação de uma RFQ emergencial — tudo dentro de uma única conversa no Amazon Quick.

Passo 1: Descoberta

O usuário pergunta “Quais ferramentas de supply chain eu tenho?” e o Amazon Quick lista os servidores MCP publicados no AWS Agent Registry. Como um administrador já habilitou a integração com o registro, os quatro servidores MCP de negócio aparecem como cards de conector, com detalhes de conexão pré-preenchidos.

Passo 2: Consulta de interrupções ativas

“Verificar interrupções ativas de fornecimento” aciona o MCP de Alertas de Interrupção (assess_disruption_impact), retornando três interrupções com severidade, região e contagem de SKUs. O Quick roteia a solicitação pelo AgentCore até o servidor MCP, que consulta o backend de monitoramento e retorna um resultado estruturado.

Passo 3: Análise detalhada

O usuário aprofunda na parada da TechComp. A chamada assess_disruption_impact(disruption_id="DISR-002") correlaciona dados de pedidos, clientes e estoque: US$ 750 mil em risco, 23 pedidos afetados, três dias de suprimento. Uma única chamada MCP consulta múltiplos sistemas de registro, entregando ao gestor uma visão consolidada de impacto sem tocar no ERP.

Passo 4: Recomendação de mitigação

O usuário pede mitigação. A chamada recommend_mitigation(disruption_id="DISR-002") encadeia o MCP de Governança (verificar alternativas aprovadas) e o MCP de Cotação (cotação alinhada ao contrato) — um fluxo completo a partir de uma única solicitação. O agente planeja e sequencia as chamadas, cobrindo interrupção, governança e cotação sem handoffs manuais.

Passo 5: Monitoramento proativo

O usuário configura monitoramento automático (“Me alerte toda manhã se houver uma nova interrupção crítica”). O mesmo fluxo pode rodar de forma autônoma a partir de um e-mail de fornecedor, postando cards prontos para revisão no Activity Feed para aprovação humana.

Arquitetura da solução

O padrão arquitetural separa a camada de inteligência da camada de interface, permitindo que cada uma evolua independentemente. O Amazon Quick é a interface; o AgentCore é a inteligência.

Amazon Bedrock AgentCore: a camada de inteligência

O Amazon Bedrock AgentCore é uma plataforma modular para construir, implantar e operar agentes de forma segura e em escala. Quatro serviços são relevantes para este padrão:

• Runtime — Hospedagem serverless para servidores MCP e agentes, com isolamento de sessão e identidade integrada.
• Gateway — Transforma APIs, funções AWS Lambda e serviços em ferramentas compatíveis com MCP atrás de um endpoint gerenciado e seguro.
• Identity — Autenticação e gerenciamento de credenciais, compatível com provedores de identidade existentes.
• Policy — Regras de autorização determinísticas, escritas em linguagem natural ou Cedar, que interceptam cada chamada de ferramenta antes da execução.

O protocolo MCP: como as ferramentas se comunicam

O MCP é um padrão aberto para interação entre modelos de IA e ferramentas externas. Cada servidor expõe ferramentas com parâmetros tipados. Isso significa que:

• Clientes de IA (Quick, agentes customizados, outros apps MCP) podem consumir os mesmos servidores.
• Backends (SAP, Oracle, microsserviços customizados) podem ser encapsulados como servidores MCP.
• A descoberta de ferramentas é automática — clientes consultam o registro para obter schemas em tempo de execução.

AWS Agent Registry: a camada de descoberta

O registro é a camada de descoberta governada: um publicador submete um registro, um curador aprova, e só então ele se torna descobrível por busca híbrida, navegação ou pelo endpoint MCP do registro. Um ponto importante para escala: como os schemas são descobertos em tempo de execução, cada um deve ser tratado como um contrato — versionando novos ao lado dos antigos em caso de mudanças incompatíveis.

Orquestração multi-etapas

A camada de raciocínio é um agente no AgentCore Runtime — o Order Fulfillment Agent. Dada uma solicitação, ele planeja quais ferramentas chamar e em qual ordem. Por exemplo, diante de “Um fornecedor parou. Encontre alternativas, verifique conformidade e emita uma RFQ emergencial”, o agente encadeia: MCP de Alertas de Interrupção → MCP de Governança → MCP de Cotação → uma recomendação consolidada.

Segurança e governança

Toda chamada de ferramenta passa pelo mesmo conjunto de controles do AgentCore antes de atingir o backend: autenticação IAM, autorização por ferramenta, validação de entrada, avaliação de políticas, limitação de taxa, aplicação de limites de dados e registro de auditoria.

Os servidores MCP do padrão

A solução utiliza quatro servidores MCP de negócio e um agente orquestrador:

• Quoting Engine — Geração de cotações, regras de precificação, validação.
• Governance Engine — Aprovação de fornecedores, autoridade orçamentária, conformidade regulatória.
• Invoice Processing — Roteamento de aprovação de faturas, aging de contas a pagar, cronogramas de pagamento.
• Disruption Alerts — Interrupções ativas, severidade, avaliações de impacto, mitigação.
• Order Fulfillment Agent — Orquestração multi-etapas através dos quatro MCPs de negócio.

Amazon Quick: o assistente de IA empresarial

O Amazon Quick coloca as ferramentas do AgentCore diante dos usuários de negócio por meio de chat, agentes, Activity Feed e fluxos automatizados — sem configuração técnica. Os componentes-chave incluem:

• Conexão com o Agent Registry — Registros aparecem como cards de conector.
• Quick Agent — Um agente de supply chain que se adapta ao perfil do usuário (gestor, compras, analista).
• Conectores MCP — Expõem ferramentas MCP no chat.
• Activity Feed — Agentes postam cards com alertas e ações proativas.
• Schedules — Automação recorrente em linguagem natural.
• Integração com Outlook — Respostas de fornecedores por e-mail são parseadas e validadas.
• Conectores de dados estruturados — Consultas a datasets operacionais (pedidos, estoque, fornecedores, contratos).
• Base de conhecimento no Amazon S3 — Faturas, contratos e políticas em um bucket S3, fundamentando respostas via Geração Aumentada por Recuperação (RAG).

Activity Feed e monitoramento proativo

O Activity Feed é a superfície proativa do Amazon Quick — uma caixa de entrada unificada onde agentes postam resultados, alertas e recomendações. Os itens do feed são acionáveis, priorizados por IA, multi-fonte e sempre com humano no loop (agentes propõem, humanos decidem).

Caso de uso: validar respostas de fornecedores por e-mail

Fornecedores respondem a uma RFQ emergencial por e-mail com preços. O agente valida cada resposta (fornecedor aprovado? dentro das diretrizes?) e prepara o resultado. Ele não elabora cotações, escolhe vencedores ou emite ordens de compra.

Fase 1: Setup (uma vez, ~5 minutos) — Conectar Outlook, configurar o Activity Feed, criar o agente de supply chain com instruções específicas e criar um schedule (“A cada 2 horas em horário comercial, verificar novas respostas de fornecedores e validá-las”).

Fase 2: Runtime (totalmente automatizado) — O schedule dispara, identifica um e-mail da “TechSupply Co” (MCU-7200, 10.000 unidades a US$ 2,45/unidade), consulta o MCP de Governança (fornecedor aprovado?) e o MCP de Cotação (dentro das diretrizes?), e posta um card “Resposta do Fornecedor — Pronta para Revisão”.

Fase 3: Humano no loop — O revisor compara as respostas validadas e seleciona o fornecedor para emitir a ordem de compra, ou rejeita com motivo registrado. A seleção e a ordem de compra ficam sempre com uma pessoa.

Caso de uso: monitoramento proativo de interrupções

Disparado por schedule, um agente diário às 8h30 verifica novas interrupções críticas ou de alta severidade, avalia o impacto, sinaliza como URGENTE qualquer item com menos de sete dias de suprimento e posta um card de alerta com a ação “Emitir RFQ Emergencial”.

Onde isso se encaixa em relação ao BI tradicional

A proposta não é substituir tudo. Dashboards continuam superiores para visualização de tendências, análise colaborativa, relatórios regulatórios e análise exploratória. A IA conversacional brilha em decisões operacionais em tempo real, enquanto o BI atende melhor a análise estratégica. As abordagens se complementam.

As principais diferenças incluem:

• Modelo de acesso — BI exige navegar, logar e encontrar o dashboard; a abordagem conversacional permite perguntar em linguagem natural.
• Tempo para insight — De minutos/horas (encontrar → filtrar → exportar → correlacionar) para segundos.
• Correlação multi-sistema — De manual (3-4 abas, copiar e colar) para automática via orquestração de agentes.
• Lacuna de ação — No BI, o insight está em uma ferramenta e a ação em outra; aqui, insight e ação ficam na mesma conversa.
• Custo de execução — Pipelines de BI custam o mesmo independentemente do uso; a abordagem serverless escala a zero.
• Confiança e precisão — BI depende da última carga ETL; aqui, os dados são computados ao vivo dos sistemas de registro, com toda escrita validada por humano.

Personas e casos de uso

Um único Quick Agent atende três personas, com segurança em nível de linha/coluna e escopo de ferramentas MCP por persona (compras não vê dados financeiros):

• Gestor de Supply Chain — Verificação matinal de interrupções, procurement emergencial (Alertas de Interrupção → Governança → Cotação).
• Compras — Verificação de fornecedores, autoridade orçamentária, geração e validação de RFQ.
• Analista Operacional — Correlação cross-sistema, fila de pagamentos, auditoria e tendências de interrupção.

Como implantar

A implantação segue três fases: provisionar a infraestrutura, conectar o Amazon Quick aos dados e ao registro, e ativar o monitoramento.

Pré-requisitos

• Conta AWS com Amazon Bedrock AgentCore e AWS Agent Registry.
• AWS CLI v2, AWS SAM CLI e Docker (o agente roda como container arm64).
• Python 3.12 ou superior, com Boto3 1.43.94 ou superior para o passo de registro.
• Credenciais ativas com permissões IAM para deploy e registro.
• Camada de dados: banco de dados (Snowflake, PostgreSQL/RDS ou engine SQLAlchemy), bucket Amazon S3, opcionalmente um org Salesforce.
• Amazon Quick configurado para a organização.
• (Opcional) Conta Outlook para automação de e-mail.

Deploy da infraestrutura

Todo o código é open source e scriptado. Basta clonar o exemplo quick-for-supply-chain no repositório aws-samples/sample-amazon-quick-suite-knowledge-hub e seguir o README.md.

O README cobre três fases:

• Fase 1 — Deploy do stack AgentCore: camada de identidade (user pool Amazon Cognito, app client, fluxo OAuth de authorization-code e usuário de teste), quatro servidores MCP de regras de negócio (cada um como função Lambda fronteada por seu próprio AgentCore Gateway com autorização CUSTOM_JWT), targets do gateway mapeando as ferramentas de cada Lambda, e o sc-order-fulfillment-agent no AgentCore Runtime como container, com roles IAM de menor privilégio.
• Fase 2 — Upload do dataset sintético para o Amazon S3.
• Fase 3 — Verificação de que gateways e runtime estão Ready. Seis registros no Agent Registry são aprovados.

Conceder acesso ao Amazon Quick

No console web do Amazon Quick, é necessário conceder acesso ao bucket S3 e ao Amazon Athena pela página de administração do Amazon QuickSight (Manage QuickSight → Security and permissions), já que cada tabela é servida por uma fonte Athena sobre um banco AWS Glue. Sem a concessão do Athena, a criação de datasets falha.

Vincular o registro e criar conectores

Vincular o registro é uma ação única de administrador. Criar conectores é por usuário. O administrador vincula um Agent Registry à conta Quick (um por conta). Após a vinculação, os registros MCP aprovados aparecem como cards de conector: os quatro MCPs de negócio como cards automáticos e o agente de order-fulfillment adicionado manualmente.

A autenticação dos conectores usa o fluxo OAuth de authorization-code (OAUTH2_AUTHORIZATION_CODE) com client ID, secret e URLs de token, autorização e redirect do script de deploy.

Anexar conectores ao agente

O deploy cria o agente Supply Chain: um Quick Space, datasets importados e base de conhecimento S3, e o agente com instruções, prompts iniciais e mensagem de boas-vindas. O que resta é anexar os cinco conectores (quatro MCPs de negócio mais sc-order-fulfillment-agent) nas configurações do agente.

Configurar monitoramento proativo

No Quick Desktop App, conectar o Outlook e habilitar monitoramento de e-mail. Em seguida, no Quick Chat, criar dois schedules em linguagem natural: um baseado em tempo (“Toda manhã, verificar novas interrupções críticas”) e outro baseado em e-mail (“A cada duas horas em horário comercial, verificar respostas de fornecedores e validar”).

Testando no Amazon Quick

Com o agente e conectores prontos, basta perguntar em linguagem natural no chat do Amazon Quick. Exemplos de perguntas e resultados:

• “Quais ferramentas de supply chain eu tenho?” → Os cinco conectores MCP com status.
• “Mostre interrupções ativas de fornecimento.” → Interrupções ativas com severidade, região e contagem de SKUs.
• “Avalie o impacto da parada de produção da TechComp.” → Receita em risco, pedidos afetados, dias de suprimento.
• “Este fornecedor é aprovado e temos autoridade orçamentária para uma PO de US$ 72.000?” → Aprovação via MCP de Governança.
• “Gere uma cotação alinhada ao contrato para 1.000 unidades para este cliente.” → Cotação do MCP de Cotação como documento formatado.
• “Um fornecedor parou. Encontre alternativas, verifique conformidade e emita uma RFQ emergencial.” → O Order Fulfillment Agent encadeia os MCPs em uma recomendação consolidada.

Conclusão

O AgentCore e o Amazon Quick formam um padrão repetível de IA empresarial: separar inteligência de interface. O AgentCore transforma backends fragmentados em uma camada componível, governada e acessível por IA através de interfaces MCP padronizadas. O Amazon Quick democratiza o acesso em linguagem natural.

O ganho principal é o encurtamento da cadeia de decisão: detectar, pesquisar, decidir, agir e registrar — o que antes exigia cinco ferramentas — agora acontece em uma conversa. A IA pesquisa, correlaciona e valida. A pessoa decide. Toda chamada é autenticada, autorizada, verificada por política e auditada. Uma rotina de 45-60 minutos em cinco sistemas pode se reduzir a minutos.

Essa é a mudança de “rico em dados, pobre em insights” para “rico em dados, pronto para decidir”. A recomendação da AWS é começar com um servidor MCP e uma persona — o registro cresce e a experiência permanece a mesma.

Fonte

From data to decisions: Conversational supply chain intelligence with Amazon Quick and Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/from-data-to-decisions-conversational-supply-chain-intelligence-with-amazon-quick-and-amazon-bedrock-agentcore/)

O que foi anunciado

A AWS anunciou a disponibilidade do Grok 4.7 no Amazon Bedrock dentro da região AWS GovCloud (EUA). O modelo foi desenvolvido pela xAI (empresa do SpaceX) e é classificado como um modelo de fronteira — ou seja, está entre os mais avançados disponíveis atualmente para uso em produção.

O que há de novo no Grok 4.7

O Grok 4.7 representa uma evolução direta sobre o Grok 4.6, trazendo melhorias concretas em três frentes principais:

• Melhor tratamento de documentos mistos: o modelo lida com mais eficiência com entradas que combinam diferentes tipos de conteúdo ao mesmo tempo.
• Codificação em escala de repositório: a capacidade de trabalhar com bases de código maiores ficou mais confiável, com suporte a planejamento e recuperação de erros durante a execução de tarefas.
• Agentes de navegação aprimorados: o Grok 4.7 oferece melhores capacidades para uso em agentes que interagem com navegadores, como preenchimento de formulários e navegação em portais web.

Para quais cenários ele foi projetado

O Grok 4.7 foi construído com foco em três categorias de uso: programação (coding), tarefas agênticas — onde o modelo age de forma autônoma para completar objetivos — e trabalho intensivo em conhecimento. Isso o posiciona como uma opção robusta para equipes que constroem fluxos de trabalho automatizados e assistentes técnicos avançados.

Como acessar o Grok 4.7 no Amazon Bedrock

O acesso pode ser feito de duas formas: diretamente pelo console do Amazon Bedrock ou de forma programática pelas APIs suportadas pelo Amazon Bedrock.

Para informações sobre as regiões da AWS compatíveis (Regiões AWS), endpoints, APIs, funcionalidades, perfis de inferência e preços, a AWS disponibiliza a documentação oficial do Amazon Bedrock. Para um mergulho mais aprofundado nas novidades do modelo, também está disponível um post de lançamento no blog da AWS.

Fonte

Grok 4.7 is now available on Amazon Bedrock in AWS GovCloud (US) (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-bedrock-grok-4-7-govcloud/)

O que é o SageMaker JumpStart?

O Amazon SageMaker JumpStart é o hub de aprendizado de máquina (AM) dentro do Amazon SageMaker AI. Ele oferece acesso a um catálogo curado de modelos de IA, templates de soluções e notebooks de exemplo — com o objetivo de reduzir o tempo entre a seleção de um modelo e sua colocação em produção.

Na prática, o serviço atende a três casos de uso principais:

• Descoberta e avaliação de modelos — É possível explorar centenas de modelos de fundação (MF) de provedores como Alibaba (Qwen), NVIDIA, Google, Mistral, Cohere, IBM e outros. Cada card de modelo traz detalhes de arquitetura, benchmarks, informações de licença e notebooks de exemplo.
• Deploy com um clique — O modelo escolhido pode ser implantado em um endpoint de inferência em tempo real do SageMaker com configurações pré-otimizadas para o tipo de carga desejada: baixo custo, baixa latência, alto throughput ou equilíbrio entre eles. Nenhuma configuração manual de container ou instância é necessária.
• Customização de modelos — É possível fazer fine-tuning diretamente pelo console ou pelo SDK, usando técnicas como Adaptação de Baixo Rank (LoRA), Ajuste Fino Supervisionado (SFT), Otimização de Preferência Direta (DPO) e Aprendizado por Reforço com Recompensas Verificáveis (RLVR). Opções serverless reduzem ainda mais a complexidade de infraestrutura.

O acesso ao JumpStart pode ser feito pelo console do SageMaker Studio (em Models → JumpStart models), via SDK Python do SageMaker, ou diretamente do Hugging Face por meio de uma integração de deep link lançada recentemente.

Balanço do Catálogo em 2026

De janeiro a setembro de 2026, o SageMaker JumpStart incorporou mais de 100 novos modelos de 30 provedores distintos. Trata-se de uma expansão expressiva, impulsionada pelo ritmo acelerado de lançamentos de modelos open source e pela crescente demanda dos clientes por diversidade de arquiteturas, tamanhos e capacidades.

Veja o destaque dos principais contribuidores — e acesse a página do SageMaker JumpStart para a lista completa:

• Alibaba (Qwen): 29 modelos cobrindo raciocínio (Qwen 3.8-27B), mistura de especialistas em larga escala (Qwen3.5-122B-A10B), fluxos agênticos (Qwen-AgentWorld-35B-A3B), geração de código (Qwen3-Coder-Next, Qwen 3 Coder 30B), reconhecimento de fala (Qwen3-ASR-1.7B), síntese de voz (Qwen3-TTS), embeddings (Qwen3-VL-Embedding-2B) e reranking (Qwen3-Reranker-4B).
• NVIDIA: 17 modelos, incluindo a família de modelos de fundação de mundo Cosmos3 (Super, Edge e Nano), Cosmos Reason 7B, MSA-Search, Nemotron 3.5 Lightning, Nemotron-3-Super-120B (FP8 e BF16), Nemotron3 Ultra, Nemotron-Nano-12B-v2, Nemotron 3 Nano Omni (multimodal) e Nemotron 3.5 Super VL para visão-linguagem.
• Mistral: 7 modelos, incluindo a família Ministral-3 (3B, 8B e 14B em versões padrão e BF16) e o Voxtral-Mini-4B-Realtime para fala em tempo real.
• Google: 6 variantes do Gemma 4, incluindo gemma-4-31B-it, E2B-it, E4B-it, 26B-A4B-it, assistant e a versão quantizada NVFP4.
• IBM: 4 modelos, incluindo o Granite 4.0 nas versões h-micro, small e tiny, além do granite-speech-4.1-2b para reconhecimento automático de fala (ASR) multilíngue em 6 idiomas.
• Cohere: 4 modelos, incluindo o Command A (A100) e as versões Rerank v3.5, v4.0 Fast e v4.0 Pro para Geração Aumentada por Recuperação (RAG).
• Outros: 33 modelos de provedores como MiniMax, Zhipu AI (GLM), DeepSeek, Moonshot AI, Allen AI, Microsoft, Meta (Muse Spark), Reflection (Beam), Black Forest Labs, JetBrains, OpenBMB, BharatGenAI, Kakao, OpenFold e outros.

Destaques da Incorporação de Modelos

Os modelos incorporados em 2026 refletem prioridades bem definidas na expansão do catálogo do SageMaker JumpStart. Elas não são apenas tendências de mercado — representam áreas onde a AWS identifica forte demanda dos clientes e oportunidades concretas para acelerar a construção de aplicações de IA em produção.

Expansão do Portfólio de Modelos Abertos da NVIDIA

A NVIDIA é um dos principais provedores de modelos do JumpStart, e em 2026 sua contribuição foi bem além dos modelos de linguagem. Os modelos de fundação de mundo Cosmos3 — disponíveis nas variantes Super, Edge e Nano — integram geração de vídeo, simulação física e planejamento de ações em uma única arquitetura voltada para aplicações de IA física, como robótica, sistemas autônomos e gêmeos digitais. Somados aos modelos Nemotron, que vão desde inferência eficiente na borda (Nano-12B) até raciocínio em larga escala (Super-120B), o JumpStart passa a oferecer um portfólio amplo de modelos abertos da NVIDIA, todos implantáveis com containers otimizados e endpoints pré-configurados.

Fechando a Lacuna Multimodal

As cargas de trabalho dos clientes exigem cada vez mais modelos que processem mais do que texto. Em 2026, a AWS priorizou a incorporação de modelos que lidam nativamente com visão, fala e compreensão de documentos:

• O NVIDIA Nemotron 3 Nano Omni processa texto, visão e fala em um único modelo.
• O Google Gemma 4 adiciona capacidades de visão-linguagem em múltiplos tamanhos.
• O IBM granite-speech-4.1-2b realiza reconhecimento e tradução de fala em seis idiomas.
• O Mistral Voxtral-Mini oferece compreensão de fala em tempo real.

Com essas adições, os clientes podem evitar a necessidade de encadear modelos de pré-processamento separados para cargas de trabalho multimodais.

IA Criativa ao Alcance de Todos

A geração de imagens e vídeos passou de nicho para mainstream em 2026. O JumpStart incorporou o FLUX.2 Small Decoder e o FLUX.2-klein-base-4B da Black Forest Labs para geração rápida de imagens a partir de texto, o Meta Muse-Glimmer-30B para fluxos agênticos multimodais e o NVIDIA Cosmos3 para geração de vídeo. Esses modelos podem ser acessados com a mesma experiência de deploy com um clique usada para modelos de linguagem.

Foco em Modelos Eficientes e Quantizados

Nem toda carga de trabalho exige um modelo de escala máxima. Muitos clientes estão focados em otimizar os custos de inferência ao migrar para produção. Por isso, foram incorporados modelos quantizados e compactos:

• O Zhipu AI GLM-5.2 FP8 entrega bom desempenho com menor uso de memória.
• O JetBrains Mellum2-12B usa arquitetura de mistura de especialistas com apenas 2,5B de parâmetros ativos para geração de código.
• O OpenBMB MiniCPM5-1B concentra capacidades multimodais em apenas 1 bilhão de parâmetros.
• O Microsoft Phi-4-mini-instruct e o IBM Granite 4.0 h-tiny demonstram que modelos compactos atendem cargas de trabalho em produção em instâncias como a ml.g5.xlarge.

Esses modelos ajudam a otimizar latência e o Custo Total de Propriedade (TCO) para casos de uso específicos.

Modelos de Propósito Específico

Modelos de propósito geral são versáteis, mas modelos especializados são otimizados para tarefas específicas. Em 2026, foram incorporados:

• Qwen-AgentWorld-35B-A3B para fluxos de trabalho de IA autônoma com chamada nativa de ferramentas.
• GLM-OCR, LightOnOCR e DeepSeek-OCR para extração de texto em documentos.
• Qwen3-Reranker-4B e Cohere Rerank v4.0 para melhorar a precisão de recuperação em pipelines de RAG.
• langcache-embed-v3-small para embeddings leves em busca semântica.
• Qwen3-ASR e Qwen3-TTS para reconhecimento e síntese de fala.
• OpenFold3 para predição de estrutura de proteínas em computação científica.

Diversidade de Provedores

Reduzir o risco de concentração na escolha de modelos é importante para clientes corporativos. Em 2026, o catálogo foi expandido para 30 provedores. O Alibaba Qwen é o maior contribuidor individual, com 29 modelos cobrindo raciocínio, código, fala e recuperação. Zhipu AI e DeepSeek adicionam LLMs competitivos e OCR especializado. MiniMax e Moonshot AI contribuem com arquiteturas emergentes. BharatGenAI e Kakao ampliam a cobertura regional de modelos. Essa diversidade oferece aos clientes mais opções em termos de desempenho, custo, licenciamento e suporte a idiomas.

Melhorias na Plataforma em 2026

Além da expansão do catálogo, o SageMaker JumpStart recebeu melhorias significativas que reduzem a fricção em todo o ciclo de vida dos modelos — da descoberta ao deploy em produção.

Novo Model Hub Simplificado no Console do SageMaker AI

Antes, descobrir modelos no JumpStart exigia navegar até o SageMaker Studio e encontrar a seção correspondente no menu lateral. O novo Model Hub expõe o catálogo completo diretamente na página inicial do console do SageMaker AI. É possível navegar por categorias e filtrar por modalidade de entrada/saída, publicador, tamanho do modelo, licença e framework. Também é possível visualizar notebooks de exemplo e abrir modelos no Studio com um único clique.

Configurações de Deploy Pré-definidas

Escolher o tipo de instância, o container de serving e as configurações de otimização corretas para um deploy geralmente exigia benchmarking manual entre dezenas de combinações. O SageMaker JumpStart passou a oferecer configurações de deploy nomeadas, com perfis de otimização para:

• Balanceado — Equilíbrio entre custo, latência e throughput para cargas de trabalho de uso geral.
• Otimizado para throughput — Máximo de tokens por segundo usando técnicas como Decodificação Especulativa, ideal para processamento em lote de alto volume.
• Otimizado para latência — Menor Tempo até o Primeiro Token (TTFT), priorizando velocidade para aplicações interativas.
• Otimizado para custo — Menor custo de infraestrutura por requisição, adequado para cargas que toleram maior latência.

Essas configurações incluem setups otimizados para Neuron, voltados às instâncias AWS Inferentia e AWS Trainium, reduzindo a complexidade do deploy e os custos de infraestrutura. Com isso, é possível implantar um modelo com um clique e o perfil de otimização correto, sem semanas de benchmarking manual.

Integração de Deep Link com o Hugging Face

Uma nova integração com o Hugging Face conecta a descoberta de modelos diretamente ao SageMaker Studio. Ao navegar por modelos no Hugging Face, o usuário pode escolher Deploy on SageMaker AI ou Customize and Deploy on SageMaker AI e é direcionado para um ambiente Studio já configurado, com o modelo pré-carregado, permissões pré-configuradas e visibilidade de cota de GPU integrada. Isso elimina a necessidade de configurar funções do AWS Identity and Access Management (IAM), criar um domínio ou ajustar permissões antes de começar a experimentar.

Como Começar com o SageMaker JumpStart

Há três formas de começar a usar o SageMaker JumpStart:

• Console do SageMaker Studio — Abra o SageMaker Studio, navegue até Models → JumpStart models e explore o catálogo. Escolha um modelo para ver seus detalhes e clique em Deploy ou Customize.
• SDK Python do SageMaker — Faça deploys de modelos de forma programática. Acesse o catálogo de modelos do SageMaker JumpStart para exemplos de SDK e guias de implantação.
• Deep link do Hugging Face — Navegue pelo Hugging Face Model Hub e escolha Deploy on SageMaker AI para ir direto ao Studio com o modelo já configurado.

Cada modelo no JumpStart inclui configurações de deploy, notebooks de exemplo e documentação. Para um guia prático, a AWS disponibilizou o post Deploy and Evaluate Models with Amazon SageMaker JumpStart.

Próximos Passos

Para quem quer se aprofundar no SageMaker JumpStart, a AWS sugere alguns pontos de partida:

• Avaliar modelos e escolher o mais adequado para o seu caso de uso.
• Aprender a fazer deploy do Hugging Face para o SageMaker Studio.
• Usar modelos pré-treinados em deploys baseados em casos de uso.
• Projetar uma fábrica de modelos de IA física no SageMaker HyperPod.

Para explorar o catálogo completo, acesse a página do catálogo de modelos do SageMaker JumpStart.

Fonte

Amazon SageMaker JumpStart: 2026 year-to-date in review (https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-jumpstart-2026-year-to-date-in-review/)

O que é o Pegasus 1.5 e por que ele importa

Em 9 de outubro de 2026, a AWS anunciou a disponibilidade do Pegasus 1.5 da TwelveLabs no Amazon Bedrock. Trata-se de um modelo de linguagem de vídeo projetado para transformar conteúdo de longa duração em metadados estruturados e com timestamps — ou seja, você descreve os momentos que importam para o seu fluxo de trabalho, e o modelo retorna cada trecho correspondente em formato JSON.

Vídeo é uma das categorias mais volumosas e complexas de dados não estruturados que existem, e a grande maioria desse conteúdo permanece impossível de pesquisar e subutilizado. Extrair insights acionáveis de vídeos sempre exigiu revisão manual trabalhosa ou cadeias de ferramentas fragmentadas. O Pegasus 1.5 foi desenvolvido para mudar esse cenário.

O que há de novo no Pegasus 1.5

Em relação às versões anteriores, o Pegasus 1.5 traz quatro avanços principais:

• Geração de metadados baseada em tempo: você define os segmentos, eventos ou marcadores específicos do seu domínio — como cortes editoriais, jogadas esportivas, mudanças de apresentador ou aparições de marca — e o modelo retorna cada ocorrência em JSON com horários de início e fim.
• Prompts multimodais: uma definição de segmento pode combinar uma descrição em texto com uma imagem de referência visual, permitindo localizar um produto específico, logotipo ou pessoa, junto com o que estão fazendo na tela.
• Processamento sob demanda (on-the-fly): não há necessidade de pipeline de ingestão ou etapa de pré-indexação. Os vídeos são enviados diretamente do Amazon S3 e os resultados são retornados na própria resposta.
• Capacidade de processamento ampliada: o Pegasus 1.5 analisa vídeos de até duas horas em uma única requisição, ante uma hora no Pegasus 1.2.

O modelo também mantém e aprimora as capacidades centrais da versão anterior: geração de texto a partir de vídeo, compreensão visual granular (objetos, texto na tela, conteúdo numérico), ancoragem temporal de eventos, compreensão multimodal (visual, áudio e texto) e suporte multilíngue — com inglês completo e suporte parcial para árabe, chinês, francês, alemão, italiano, japonês, coreano, português, russo, espanhol, tailandês e vietnamita.

Como o Pegasus 1.5 funciona no Amazon Bedrock

O modelo recebe um vídeo e um prompt de texto ou um conjunto de definições de segmento, e retorna texto ou JSON. A chamada é feita no endpoint bedrock-runtime com a API InvokeModel, ou com InvokeModelWithResponseStream para respostas em streaming.

• ID do modelo: twelvelabs.pegasus-1-5-v1:0
• Região AWS: US West (Oregon) — us-west-2
• APIs de inferência: InvokeModel, InvokeModelWithResponseStream

Cada requisição opera em um de dois modos, definido pelo campo analysisMode:

• Modo geral (general): você envia um prompt em texto via inputPrompt e recebe uma resposta em texto — ou em JSON, quando fornece um schema.
• Metadados baseados em tempo (time_based_metadata): você envia definições de segmento em responseFormat e recebe uma lista de segmentos com horários de início e fim e os campos solicitados.

O vídeo pode ser fornecido de duas formas: via URI do Amazon S3 (Serviço de Armazenamento Simples) — indicado para vídeos longos — ou como string base64 embutida na requisição, com limite de 25 MB, indicado para clipes curtos.

Primeiros passos com o Pegasus 1.5

Pré-requisitos

• Conta AWS ativa com acesso ao Amazon Bedrock.
• Python 3.10 ou superior, com o SDK AWS para Python (Boto3) instalado.
• Permissões do IAM (Gerenciamento de Identidade e Acesso) para bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream.
• Acesso ao modelo TwelveLabs Pegasus 1.5 habilitado no console do Amazon Bedrock.
• Vídeos armazenados em um bucket do Amazon S3, ou clipes curtos para envio inline.

A política IAM abaixo concede as duas ações de invocação no Pegasus 1.5:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-west-2::foundation-model/twelvelabs.pegasus-1-5-v1:0"
      ]
    }
  ]
}

Sua primeira requisição

Instale o Boto3:

pip install boto3

O exemplo a seguir analisa um vídeo armazenado no Amazon S3 no modo geral, usando o endpoint global de Inferência entre Regiões (CRIS). Para usar o endpoint geográfico dos EUA, substitua "global." por "us." na URL do endpoint.

import boto3
import json
from botocore.config import Config

AWS_REGION = "us-west-2"
MODEL_ID = "global.twelvelabs.pegasus-1-5-v1:0"

bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name=AWS_REGION,
    config=Config(
        # keep a longer read_timeout for lengthier invocations such as video segmentation
        read_timeout=900,
        retries={"max_attempts": 0},
        connect_timeout=10,
    ),
)

# Analyze a video stored in Amazon S3
payload = {
    "inputPrompt": "Summarize this video and identify the key topics discussed.",
    "mediaSource": {
        "s3Location": {
            "uri": "s3://amzn-s3-demo-pegasus-15/your-video.mp4",
            "bucketOwner": "your-account-id"
        }
    },
    "temperature": 0.2,
    "maxOutputTokens": 4096,
    "includeMetering": True
}

response = bedrock_runtime.invoke_model(
    modelId=MODEL_ID,
    body=json.dumps(payload)
)

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

A resposta traz a resposta em message, a contagem de tokens em input_tokens e output_tokens, e o motivo do encerramento em stopReason. Um stopReason igual a length indica que a resposta foi cortada antes de terminar — aumente o maxOutputTokens e tente novamente:

if result["stopReason"] == "length":
    print("The answer was cut off. Raise maxOutputTokens and try again.")
print("Tokens in:", result["input_tokens"], "out:", result["output_tokens"])

Para clipes curtos, é possível enviar o vídeo inline em vez de via S3:

import base64

with open("your-video.mp4", "rb") as f:
    video_b64 = base64.b64encode(f.read()).decode("utf-8")

payload["mediaSource"] = {"base64String": video_b64}
response = bedrock_runtime.invoke_model(modelId=MODEL_ID, body=json.dumps(payload))
print(json.loads(response["body"].read())["message"])

Resposta em streaming

Para aplicações interativas, o InvokeModelWithResponseStream retorna a resposta em pedaços conforme ela é gerada:

response = bedrock_runtime.invoke_model_with_response_stream(
    modelId=MODEL_ID,
    body=json.dumps(payload)
)

for event in response["body"]:
    chunk = json.loads(event["chunk"]["bytes"])
    print(chunk.get("message", ""), end="", flush=True)
print()

Retornando JSON estruturado

No modo geral, é possível restringir a resposta a um JSON Schema para que o código downstream possa fazer o parse diretamente. Defina responseFormat.type como json_schema e coloque o schema em jsonSchema:

payload = {
    "inputPrompt": "Analyze this video and return a structured summary.",
    "mediaSource": {
        "s3Location": {
            "uri": "s3://amzn-s3-demo-pegasus-15/your-video.mp4",
            "bucketOwner": "your-account-id"
        }
    },
    "temperature": 0,
    "maxOutputTokens": 2048,
    "includeMetering": True,
    "responseFormat": {
        "type": "json_schema",
        "jsonSchema": {
            "type": "object",
            "properties": {
                "summary": {"type": "string"},
                "key_scenes": {"type": "array", "items": {"type": "string"}},
                "setting": {"type": "string"}
            },
            "required": ["summary", "key_scenes", "setting"]
        }
    }
}

response = bedrock_runtime.invoke_model(modelId=MODEL_ID, body=json.dumps(payload))
summary = json.loads(json.loads(response["body"].read())["message"])
print(summary["summary"])
for scene in summary["key_scenes"]:
    print(" -", scene)

Segmentação de vídeo: transformando vídeo em dados estruturados

A geração de metadados baseada em tempo é onde o Pegasus 1.5 mais se diferencia das versões anteriores. Em vez de um prompt, você envia uma ou mais definições de segmento, e o modelo retorna cada trecho do vídeo que corresponde a cada definição.

Para isso, defina analysisMode como time_based_metadata e responseFormat.type como segment_definitions. Cada definição possui:

• id: nome da definição, retornado em cada segmento correspondente.
• description: como é um segmento correspondente.
• fields: os valores a extrair para cada segmento, cada um com nome, tipo e descrição.

O exemplo abaixo identifica cada seção editorial em uma transmissão de notícias e retorna título, resumo e tópicos principais:

payload = {
    "analysisMode": "time_based_metadata",
    "mediaSource": {
        "s3Location": {
            "uri": "s3://amzn-s3-demo-pegasus-15/news-broadcast.mp4",
            "bucketOwner": "your-account-id"
        }
    },
    "responseFormat": {
        "type": "segment_definitions",
        "segmentTimeFormat": "hh:mm:ss",
        "segmentDefinitions": [
            {
                "id": "editorial_section",
                "description": "A distinct editorial section of the broadcast, "
                               "such as a new story, topic, or segment of the program.",
                "fields": [
                    {"name": "segment_title", "type": "string", "description": "A descriptive title"},
                    {"name": "summary", "type": "string", "description": "A brief summary of the segment content"},
                    {"name": "key_topics", "type": "array", "items": {"type": "string"}, "description": "Main topics discussed"}
                ]
            }
        ]
    },
    "temperature": 0,
    "maxOutputTokens": 32768,
    "includeMetering": True
}

response = bedrock_runtime.invoke_model(
    modelId=MODEL_ID,
    contentType="application/json",
    accept="application/json",
    body=json.dumps(payload)
)

result = json.loads(response["body"].read())
for segment in result["segments"]:
    print(segment["start_sec"], "-", segment["end_sec"], segment["segment_title"])
    print("  ", segment["summary"])
    print("  topics:", ", ".join(segment["key_topics"]))

O campo segmentTimeFormat controla como os horários são escritos: seconds retorna números para operações aritméticas, enquanto hh:mm:ss e hh:mm:ss.fff retornam timestamps legíveis como strings. Uma única requisição pode incluir múltiplas definições de segmento — por exemplo, uma para seções editoriais e outra para aparições de marca — e o modelo retorna os resultados de todas em uma única lista de segmentos, identificando cada um com _definition_id.

Prompts multimodais: adicionando contexto visual às consultas

O Pegasus 1.5 introduz prompts multimodais, permitindo incluir imagens de referência junto com os prompts de texto. Isso é útil quando você quer perguntar ao modelo sobre objetos, pessoas ou cenas que são mais fáceis de mostrar do que descrever — por exemplo, fornecer a imagem de um produto e pedir ao modelo que identifique cada momento em que ele aparece no vídeo.

As imagens de referência são anexadas de forma diferente dependendo do modo:

• No modo geral, elas ficam em promptV2.mediaSources, ao lado da pergunta em promptV2.inputText.
• No modo de segmentação (time_based_metadata), elas são anexadas ao campo mediaSources de cada definição de segmento dentro de responseFormat.segmentDefinitions.

Cada imagem precisa de um nome, um media_type igual a image, e exatamente uma fonte: base64String inline ou s3Location com uri e bucketOwner. Uma única requisição pode carregar até 30 imagens de referência.

Monitoramento de uso

O Pegasus 1.5 publica métricas no Amazon CloudWatch no namespace AWS/Bedrock sob o ID do modelo, incluindo Invocations, OutputTokenCount, InvocationLatency e InvocationClientErrors. Para rastrear custos por aplicação, crie um perfil de inferência de aplicação a partir do modelo Pegasus 1.5, adicione tags e chame-o pelo seu ARN (Nome de Recurso da Amazon) no lugar do ID do modelo.

Casos de uso

O Pegasus 1.5 foi projetado para organizações que gerenciam grandes volumes de vídeos de longa duração:

• Arquivos de notícias e transmissão: equipes podem definir segmentos editoriais, tópicos e mudanças de apresentador uma vez, e catalogar anos de gravações que antes só eram pesquisáveis por palavras-chave de transcrição.
• Transmissoras esportivas e ligas: detecção de jogadas, eventos de pontuação e momentos-chave em partidas completas, acelerando a produção de highlights.
• Aplicações de streaming: metadados em nível de cena viabilizam recomendações baseadas em momentos, inserção contextual de anúncios e revisão de segurança de marca por segmento.

Em todos os casos, as pessoas permanecem parte do fluxo de trabalho — o trabalho muda de encontrar e rotular cada momento manualmente para revisar e refinar os metadados gerados pelo modelo.

Requisitos de entrada

• Duração: até 2 horas.
• Tamanho do arquivo: até 2 GB via Amazon S3, ou até 25 MB como string base64.
• Resolução: de 360×360 a 5184×2160.
• Proporção de tela: entre 1:1 e 2.4:1, ou seus inversos.
• Formatos: formatos suportados pelo FFmpeg.

Disponibilidade e cobrança

O TwelveLabs Pegasus 1.5 está disponível no Amazon Bedrock na região AWS US West (Oregon). Consulte a lista completa de regiões para atualizações futuras, e acesse a página de preços do Amazon Bedrock para informações de valores. O Pegasus 1.5 é cobrado via AWS Marketplace, portanto seus encargos aparecem na fatura AWS e no AWS Cost Explorer sob TwelveLabs, e não sob Amazon Bedrock.

Para começar, acesse a página de modelos TwelveLabs no Amazon Bedrock e consulte o model card do Pegasus 1.5 para suporte a recursos, disponibilidade por região e exemplos de código. Dúvidas e feedbacks podem ser enviados pelo AWS re:Post para Amazon Bedrock.

Fonte

Pegasus 1.5 from TwelveLabs is now available in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/pegasus-1-5-from-twelvelabs-is-now-available-in-amazon-bedrock/)

Acesso ao SageMaker Studio ficou muito mais simples

A AWS anunciou uma mudança significativa para quem quer começar a usar o Amazon SageMaker AI: novos clientes agora conseguem acessar um ambiente do Amazon SageMaker Studio completamente configurado em apenas alguns passos, logo após criar sua conta. Sem cartão de crédito (para a maioria dos usuários), sem configuração manual de ambiente e sem precisar de uma conta AWS avançada.

O acesso pode ser feito com identidades que o usuário já possui — Google, GitHub, Apple, Amazon ou simplesmente um endereço de e-mail. Em 2 a 3 etapas, o ambiente já está pronto para uso.

O que mudou na prática

Antes dessa atualização, criar uma conta na AWS envolvia verificar e-mail, preencher dados de contato, confirmar número de telefone, informar dados de pagamento e escolher um plano de suporte. Para desenvolvedores individuais ou times pequenos de startups acostumados a começar a trabalhar em minutos, essa sequência representava uma barreira real.

Com a integração do SageMaker Studio à nova experiência de cadastro e login da AWS, esse obstáculo foi removido. Após o cadastro, o SageMaker AI cria automaticamente o ambiente Studio em cerca de 20 segundos, e o usuário já cai diretamente na página correspondente ao ponto de partida da sua jornada.

Por exemplo: se o usuário descobriu um modelo no Hugging Face e clicou em “Deploy on SageMaker AI”, ao concluir o cadastro ele já é direcionado para a página de configuração de endpoint com o modelo pré-selecionado — sem precisar navegar manualmente pelo console.

Créditos gratuitos: até US$ 200 sem cartão de crédito

Novos clientes recebem US$ 100 em créditos do AWS Free Tier que funcionam em todo o ecossistema do SageMaker AI — incluindo deployments de endpoints, personalização de modelos, notebooks do Studio e jobs de treinamento. Há ainda a possibilidade de ganhar mais US$ 100 em créditos adicionais.

Os créditos são aplicados automaticamente ao uso, e o usuário recebe notificações por e-mail conforme se aproxima do limite. O período gratuito encerra após 6 meses ou quando todos os créditos forem consumidos, o que ocorrer primeiro. Ao atingir o limite, o uso de recursos é interrompido automaticamente — sem surpresas na fatura. Para continuar usando, basta adicionar dados de pagamento e migrar para um plano pago.

Construído sobre melhorias anteriores

Essa novidade se soma a uma série de atualizações recentes no SageMaker Studio. Em um post anterior sobre a integração com o Hugging Face, a AWS havia apresentado links diretos das páginas de modelos do Hugging Face para os fluxos de trabalho do SageMaker Studio. Ainda este ano, o tempo de criação do ambiente Studio foi reduzido de 2 minutos para cerca de 20 segundos, e as permissões de personalização de modelos passaram a ser pré-configuradas em todo novo domínio Studio.

Os ambientes criados pela nova experiência de cadastro já incorporam todas essas melhorias:

• Permissões para personalização, treinamento, avaliação e deployment de modelos já vêm pré-configuradas — sem necessidade de criar funções no Gerenciamento de Identidade e Acesso (IAM) manualmente.
• Contas elegíveis têm acesso padrão a instâncias GPU dos tipos G5, G6 e G4dn para endpoints, jobs de treinamento e notebooks no Studio.
• O menu de seleção de instâncias no Studio exibe a disponibilidade de cotas, facilitando a escolha dos tipos disponíveis para uso imediato.

Como começar

Há dois caminhos para experimentar a nova experiência de cadastro:

• Acesse o catálogo de modelos do Hugging Face, escolha um modelo compatível, clique em “Deploy”, selecione “Amazon SageMaker AI” e então escolha “Customize on SageMaker AI” ou “Deploy on SageMaker AI”.
• Ou acesse diretamente a página do Amazon SageMaker Studio e clique em “Get started with Amazon SageMaker AI”.

Em ambos os casos, na tela de login da AWS, basta escolher Google, GitHub, Apple ou Amazon — ou informar um e-mail — e seguir os poucos passos para criar a conta. O ambiente Studio já estará configurado e pronto para uso com os créditos gratuitos disponíveis.

Vale destacar que essa nova experiência é voltada para novas contas AWS. Quem já possui uma conta existente não terá nenhuma alteração no fluxo de acesso.

Por que isso importa

A principal barreira para desenvolvedores individuais e times de startups que queriam explorar o SageMaker AI era justamente o processo de criação de conta — burocrático e que exigia cartão de crédito logo de início. Com essa mudança, a AWS alinha a experiência de onboarding do SageMaker Studio ao padrão que os desenvolvedores já esperam de ferramentas modernas: cadastro rápido com uma identidade existente e ambiente funcional em segundos.

Combinado com a criação de ambiente em 20 segundos, permissões IAM pré-configuradas, acesso padrão a GPUs e integração com o Hugging Face, o caminho entre descobrir um modelo e colocá-lo em produção ficou consideravelmente mais curto.

Para explorar o serviço, acesse aws.amazon.com/sagemaker/studio ou navegue pelos modelos disponíveis no Hugging Face.

Fonte

Developers can now access SageMaker Studio through the new AWS experience (https://aws.amazon.com/blogs/machine-learning/developers-can-now-access-sagemaker-studio-through-the-new-aws-experience/)

CloudWatch Omni ganha cobertura global ampliada

A AWS anunciou a expansão do Amazon CloudWatch Omni para mais oito regiões AWS, incluindo, para o público brasileiro, a região South America (São Paulo). Além dela, o serviço agora está disponível em Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt) e Europe (London) — somando-se às regiões já atendidas: US East (N. Virginia), US West (Oregon) e Europe (Ireland).

O que é o Amazon CloudWatch Omni

O CloudWatch Omni é uma experiência de observabilidade potencializada por Inteligência Artificial (IA), projetada para organizar o monitoramento em torno das equipes e das aplicações que elas gerenciam. A proposta central é reunir em um único lugar tudo o que é necessário para observar e solucionar problemas em aplicações e agentes de IA.

O serviço combina a interoperabilidade do OpenTelemetry com a escala e a confiabilidade já conhecidas do CloudWatch. Ele pode ser acessado de duas formas: por uma experiência web independente com Single Sign-On (SSO) ou por uma extensão local para Ambiente de Desenvolvimento Integrado (IDE).

Principais capacidades

Com o CloudWatch Omni, as equipes podem criar espaços (spaces) em contas centrais para visualizar telemetria de múltiplas contas AWS, múltiplas regiões e até de outras nuvens, como Azure e GCP. Entre as funcionalidades disponíveis, destacam-se:

• Descoberta automática de serviços e mapeamento de dependências;
• Exposição automática de métricas essenciais (golden metrics);
• Interação com telemetria via chat, cliques ou ferramentas próprias através do Agent Toolkit for AWS;
• Construção de visualizações dinâmicas e identificação de causa raiz com suporte do AWS DevOps Agent.

Observabilidade dedicada para agentes de IA

Um diferencial importante do CloudWatch Omni é a experiência dedicada à observabilidade de agentes de IA. Ela oferece um fluxo de trabalho orientado a avaliações, com suporte a frameworks como LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK e Strands — cobrindo boa parte do ecossistema atual de desenvolvimento com IA.

Como começar a usar

Para dar os primeiros passos com o CloudWatch Omni, a AWS orienta que o usuário crie um espaço Omni diretamente pelo console do CloudWatch, configure o SSO e faça login. Desenvolvedores de agentes também podem instalar gratuitamente a extensão para os editores VS Code, Cursor e Kiro:

• Instale a extensão CloudWatch Omni para VS Code

Para mais detalhes sobre o serviço, a AWS disponibiliza a página oficial do Amazon CloudWatch Omni e a documentação técnica completa. Informações sobre preços podem ser consultadas na página de preços do CloudWatch Omni.

Fonte

Amazon CloudWatch Omni is now available in additional AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-cloudwatch-omni-8-regions/)

O que mudou no Amazon Bedrock

A AWS anunciou suporte nativo a saídas estruturadas para todos os modelos Anthropic Claude disponíveis no Amazon Bedrock. O recurso funciona tanto no endpoint bedrock-runtime — acessado via Boto3 e APIs do Bedrock — quanto no endpoint bedrock-mantle, utilizado pela Messages API. Em ambos os casos, as respostas do modelo passam a ser Notação de Objeto JavaScript (JSON) rigorosamente compatíveis com o esquema definido pela aplicação.

Na prática, isso significa que desenvolvedores não precisam mais escrever código de validação, lógica de retentativa por falha de parsing ou pós-processamento para garantir que o modelo retornou os campos esperados. A conformidade com o esquema é garantida durante a própria geração dos tokens.

Como funciona a geração com restrições

A diferença fundamental em relação à abordagem anterior está em quando a conformidade é aplicada. Antes, a validação acontecia depois que o modelo já havia gerado a resposta — um processo probabilístico que podia falhar. Agora, o Amazon Bedrock utiliza decodificação restrita: o modelo simplesmente não produz tokens que violem o esquema fornecido. A geração de saída deixa de ser probabilística e passa a ser determinística em relação à estrutura.

O fluxo interno funciona assim:

• Validação do esquema: o Amazon Bedrock valida o esquema JSON fornecido contra o subconjunto suportado do JSON Schema Draft 2020-12.
• Compilação de gramática: para esquemas novos, o serviço compila um artefato de gramática. A primeira requisição pode ser ligeiramente mais lenta por conta dessa etapa.
• Cache de gramática: gramáticas compiladas ficam em cache por 24 horas, tornando requisições subsequentes mais rápidas. O cache é por conta AWS e é invalidado apenas quando a estrutura do esquema muda — alterações em nomes ou descrições de campos não invalidam o cache.
• Geração restrita: o modelo gera tokens que produzem JSON válido conforme o esquema.

Dois mecanismos complementares

A AWS disponibilizou dois mecanismos que cobrem cenários distintos:

• Formato de saída JSON Schema: controla a estrutura da resposta do modelo. Indicado para extração de dados, geração de relatórios e respostas de Interface de Programação de Aplicação (API).
• Uso estrito de ferramentas (strict tool use): valida parâmetros de ferramentas contra esquemas no momento da geração. Indicado para fluxos agênticos, chamadas de função e automações de múltiplas etapas.

O que isso significa para quem desenvolve

Com saídas estruturadas, cada resposta é um JSON válido — sem erros de JSON.parse() ou exceções de parsing. Os tipos de campo são respeitados, campos obrigatórios estão sempre presentes e o modelo não adiciona campos fora do esquema. Isso traz três ganhos diretos:

• Confiabilidade: não é mais necessário fazer retentativas para lidar com violações de esquema.
• Segurança de tipos: a integração com bancos de dados, sistemas de CRM ou outras APIs é mais segura porque os tipos dos campos são garantidos.
• Redução de custos: ao restringir as respostas apenas aos campos definidos, o número de tokens de saída cai — o que pode reduzir custos de inferência em cargas de trabalho de alto volume.

Disponibilidade e compatibilidade

O recurso é compatível com inferência em lote (batch inference), permitindo processar grandes volumes de requisições de forma assíncrona com saídas conformes ao esquema. No endpoint bedrock-runtime, também funciona com inferência entre regiões (cross-Region inference), sem necessidade de configuração adicional. Para quem precisa de respostas em tempo real, é possível transmitir respostas estruturadas como eventos tipados via streaming.

Exemplo prático: extração de dados com a API InvokeModel

O exemplo abaixo, retirado do post original da AWS, demonstra como extrair dados estruturados de um e-mail de cliente usando Boto3 com um modelo Claude:

import boto3
import json

REGION = "us-east-1"  # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Define the JSON schema for structured output
schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string", "description": "Customer name"},
        "email": {"type": "string", "description": "Customer email address"},
        "plan_interest": {"type": "string", "description": "Product plan of interest"},
        "demo_requested": {"type": "boolean", "description": "Whether a demo was requested"}
    },
    "required": ["name", "email", "plan_interest", "demo_requested"],
    "additionalProperties": False
}

# Make a request with structured outputs via the InvokeModel API
# (reusing the schema defined for the Converse example)
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-sonnet-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "messages": [
            {"role": "user", "content": (
                "Paulo Santos (paulo@example.com) is interested in our Enterprise plan "
                "and wants to schedule a demo for next Tuesday at 2pm."
            )}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

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

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    print(json.dumps(json.loads(result_text), indent=2))
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

A saída retornada pelo modelo seria:

{
  "name": "Paulo Santos",
  "email": "paulo@example.com",
  "plan_interest": "Enterprise",
  "demo_requested": true
}

Nenhuma validação adicional é necessária. Para mais exemplos de uso da API, incluindo a Messages API, a AWS disponibilizou um notebook de exemplo no GitHub.

Uso estrito de ferramentas para fluxos agênticos

O Amazon Bedrock Mantle é voltado para aplicações agênticas com ferramentas do lado do servidor, inferência em segundo plano e conversas com estado. Com o uso estrito de ferramentas no endpoint bedrock-mantle, é possível garantir que os parâmetros das ferramentas correspondam exatamente ao esquema de entrada definido.

O exemplo abaixo mostra como definir uma ferramenta com aplicação estrita de esquema:

import json
from anthropic import AnthropicBedrockMantle

# Reusing the client created in the Messages API example
client = AnthropicBedrockMantle(aws_region="us-east-1")

message = client.messages.create(
    model="anthropic.claude-sonnet-5",
    max_tokens=512,
    messages=[{"role": "user", "content": "What's the weather like in San Francisco?"}],
    tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather for a specified location",
            "strict": True,
            "input_schema": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and state, e.g., San Francisco, CA"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "Temperature unit"
                    }
                },
                "required": ["location", "unit"],
                "additionalProperties": False
            }
        }
    ]
)

# Tool inputs conform to the schema
for block in message.content:
    if block.type == "tool_use":
        print(f"Tool: {block.name}")
        print(f"Input: {json.dumps(block.input, indent=2)}")

Com strict: true, o campo location será sempre uma string e unit será sempre celsius ou fahrenheit. O modelo não pode adicionar campos fora do esquema. Isso é especialmente valioso em casos de uso agênticos no Amazon Bedrock Mantle, onde os modelos orquestram fluxos de múltiplas etapas com ferramentas do servidor como busca na web e interpretador de código.

Principais casos de uso

A AWS destaca três padrões onde as saídas estruturadas reduzem mais a complexidade de tratamento de erros:

• Extração de dados: extrair campos de notas fiscais, contratos, e-mails e transcrições em JSON pronto para ser carregado em bancos de dados ou sistemas de Gestão de Relacionamento com o Cliente (CRM).
• Chamadas de ferramentas confiáveis em agentes: validar argumentos de ferramentas contra seus esquemas no momento da geração, para que fluxos agênticos de múltiplas etapas rodem sem falhas por entrada malformada.
• Classificação em escala: classificar tickets, leads ou conteúdo por intenção, prioridade e sentimento para roteamento, moderação e avaliação.

O exemplo abaixo, também do post original, mostra como classificar e rotear tickets de suporte usando o modelo Claude Haiku 5.5:

import boto3
import json

REGION = "us-east-1"  # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Classification schema: enums restrict output to a fixed set of labels
schema = {
    "type": "object",
    "properties": {
        "category": {
            "type": "string",
            "enum": ["billing", "technical", "account", "sales", "other"],
            "description": "Primary ticket category"
        },
        "priority": {
            "type": "string",
            "enum": ["low", "medium", "high", "urgent"],
            "description": "Urgency based on business impact"
        },
        "sentiment": {
            "type": "string",
            "enum": ["positive", "neutral", "negative"],
            "description": "Customer sentiment"
        },
        "escalate": {"type": "boolean", "description": "Whether a human should review immediately"},
        "reason": {"type": "string", "description": "One-sentence justification for the classification"}
    },
    "required": ["category", "priority", "sentiment", "escalate", "reason"],
    "additionalProperties": False
}

ticket = (
    "Our production API calls have been failing with 500 errors since this morning. "
    "We're losing orders every minute. This is the second outage this month!"
)

# Make a request with structured outputs via the InvokeModel API
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-haiku-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "system": "You are a support ticket classifier. Classify the ticket accurately.",
        "messages": [
            {"role": "user", "content": f"Classify this support ticket:\n\n{ticket}"}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

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

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    result = json.loads(result_text)
    print(json.dumps(result, indent=2))
    # Route the ticket based on the guaranteed-valid labels
    if result["escalate"]:
        print(f"Escalating to on-call: {result['category']} / {result['priority']}")
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

Requisitos e boas práticas

A AWS recomenda as seguintes diretrizes para usar saídas estruturadas de forma eficaz no Amazon Bedrock:

• Defina additionalProperties: false em todos os objetos: isso é obrigatório para que as saídas estruturadas funcionem. Sem esse campo, o esquema não será aceito.
• Use nomes e descrições de campos descritivos: o modelo utiliza nomes e descrições de propriedades para entender quais dados extrair. Nomes claros como customer_email têm desempenho superior a nomes genéricos como field1.
• Use enum para valores restritos: quando um campo tem um conjunto limitado de valores válidos, use enum para restringir as opções.
• Comece simples e adicione complexidade gradualmente: esquemas básicos compilam mais rápido, são mais fáceis de depurar e mantêm o payload da requisição enxuto.
• Reutilize esquemas para se beneficiar do cache: estruture a aplicação para reutilizar esquemas entre requisições. O cache de gramática de 24 horas melhora a performance para consultas repetidas.
• Verifique o stop_reason em toda resposta: dois cenários podem produzir respostas não conformes — recusas do modelo por razões de segurança e limite de tokens atingido antes de completar a resposta. Ambos os casos devem ser tratados no código.
• Teste com dados realistas antes de fazer o deploy: valide os esquemas com entradas representativas de produção. Casos extremos em dados reais frequentemente revelam problemas de design no esquema.

Para boas práticas adicionais e recomendações de design de esquemas, consulte a seção Saídas Estruturadas no Guia do Usuário do Amazon Bedrock.

Recursos de JSON Schema suportados

O Amazon Bedrock suporta os seguintes recursos do JSON Schema para saídas estruturadas:

• Todos os tipos básicos: object, array, string, integer, number, boolean, null.
• enum (strings, números, booleanos ou nulos).
• const, anyOf, allOf (com limitações).
• $ref, $def e definitions (apenas referências internas).
• Formatos de string: date-time, time, date, duration, email, hostname, uri, ipv4, ipv6, uuid.
• minItems para arrays (apenas valores 0 e 1).

Não suportados: os seguintes recursos são aceitos pela API, mas não são aplicados durante a geração. Uma requisição que os inclua retorna resposta bem-sucedida, mas o modelo pode retornar valores que os violem — portanto, valide essas restrições na sua aplicação:

• Esquemas recursivos.
• Referências $ref externas.
• Restrições numéricas (minimum, maximum, multipleOf).
• Restrições de string (minLength, maxLength).
• additionalProperties definido como qualquer valor diferente de false.

Disponibilidade geral

As saídas estruturadas para modelos Anthropic Claude no Amazon Bedrock estão geralmente disponíveis agora, nos endpoints bedrock-runtime e bedrock-mantle. Para saber mais, acesse a documentação do Amazon Bedrock e explore o notebook de exemplo disponibilizado pela AWS.

Fonte

Structured outputs for Anthropic Claude models on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/structured-outputs-for-anthropic-claude-models-on-amazon-bedrock/)