A partir de março de 2026, a AWS disponibilizou suporte para workloads compatíveis com FIPS (Padrão Federal de Processamento de Informações) em Amazon ECS Managed Instances nas regiões AWS GovCloud (US). Este recurso permite que clientes com requisitos de conformidade federal executem cargas de trabalho utilizando módulos criptográficos validados por FIPS em um amplo espectro de tipos de instâncias.
O que é FIPS e por que importa
FIPS é um padrão de segurança conjunto entre Estados Unidos e Canadá que especifica os requisitos de segurança para módulos criptográficos que protegem informações sensíveis. Para organizações que trabalham com dados governamentais ou operações que exigem conformidade com regulamentações federais, a certificação FIPS é essencial.
Como funciona a conformidade nas regiões GovCloud
Nas regiões AWS GovCloud (US), Amazon ECS Managed Instances habilita automaticamente a conformidade FIPS por padrão. O mecanismo de funcionamento envolve:
Comunicação através de endpoints compatíveis com FIPS
Utilização de módulos criptográficos apropriadamente configurados
Inicialização do kernel subjacente em modo FIPS
Tipos de instâncias suportadas
Clientes com requisitos de conformidade federal podem executar workloads com módulos criptográficos validados por FIPS em uma variedade de tipos de instância, incluindo:
Instâncias baseadas em Graviton
Instâncias aceleradas por GPU
Instâncias otimizadas para rede
Instâncias de desempenho variável (burstable performance)
Como começar
Para iniciar o uso de ECS Managed Instances, é possível utilizar diversos caminhos:
AWS Console (interface web)
Amazon ECS MCP Server
ECS Express Mode
Ferramentas de infraestrutura como código (IaC) de sua preferência
Você pode habilitar o recurso em um novo cluster Amazon ECS ou em um cluster existente. Vale observar que será cobrado o gerenciamento da computação provisionada, além dos custos regulares de Amazon EC2.
A AWS apresentou o Agent Plugin para AWS Serverless, uma ferramenta desenvolvida para potencializar assistentes de codificação baseados em IA, como Claude Code, Kiro e Cursor. Este plugin amplia as capacidades desses assistentes através de recursos estruturados e reutilizáveis, integrando habilidades específicas, sub-agentes, hooks e servidores do Model Context Protocol (MCP) em uma unidade modular única.
O diferencial está em como o plugin carrega dinamicamente orientações e conhecimentos relevantes durante todo o ciclo de desenvolvimento, facilitando a criação de aplicações serverless prontas para produção na plataforma AWS.
Capacidades Principais
Construção e Integração de Funções Lambda
O plugin permite que desenvolvedores criem funções AWS Lambda integradas com fontes de eventos populares, como Amazon EventBridge, Amazon Kinesis e AWS Step Functions. Ao fazer isso, o assistente de IA oferece orientações incorporadas sobre observabilidade, otimização de desempenho e resolução de problemas.
Infraestrutura como Código
Para adoção de Infrastructure as Code (IaC), o plugin otimiza a configuração de projetos através do AWS Serverless Application Model (SAM) e do AWS Cloud Development Kit (CDK). Isso inclui construtos reutilizáveis, padrões arquiteturais comprovados, pipelines de CI/CD automatizados e fluxos de testes locais.
Fluxos de Trabalho Duráveis
Para aplicações com fluxos de trabalho longos e com estado, o plugin oferece suporte a Lambda durable functions, que disponibilizam modelo de checkpoint-replay, padrões avançados de orquestração e capacidades robustas de tratamento de erros.
Gestão de APIs
O plugin também auxilia no design e gerenciamento de APIs utilizando Amazon API Gateway, fornecendo orientações específicas para REST APIs, HTTP APIs e WebSocket APIs.
Formato Aberto e Compatibilidade
Um ponto importante é que todas essas capacidades estão empacotadas como agent skills no formato Agent Skills aberto, permitindo sua utilização em ferramentas de IA compatíveis como Kiro, Claude Code e Cursor.
Como Instalar e Utilizar
O Agent Plugin para AWS Serverless está disponível em qualquer ferramenta de assistente de IA que suporte agent plugins, como Claude Code e Cursor. Para usuários do Claude Code, a instalação é simples através do Claude Marketplace oficial, utilizando um comando específico:
Novos recursos de segurança e conformidade no AgentCore
A AWS anunciou expansões significativas no Amazon Bedrock AgentCore, seu serviço para executar agentes de IA autônomos. A empresa adicionou suporte a políticas do Chrome Enterprise e certificados customizados de Autoridade Certificadora (AC), recursos essenciais para organizações com requisitos rigorosos de segurança e infraestrutura interna complexa.
Políticas do Chrome para controle granular
O novo suporte a políticas do Chrome Enterprise no AgentCore Browser oferece controle sobre mais de 100 políticas configuráveis. Essas políticas abrangem múltiplas dimensões de segurança: comportamento do navegador, filtragem de URLs, configurações de conteúdo e outras funcionalidades.
Alguns exemplos práticos de uso incluem:
Restringir agentes a URLs específicas para operações em modo quiosque
Desabilitar gerenciadores de senha e downloads em tarefas de entrada de dados
Implementar listas de bloqueio de URLs para atender conformidade regulatória
Essa abordagem permite que as organizações forçem requisitos de conformidade específicos enquanto permitem que agentes de IA operem autonomamente dentro de limites bem definidos.
Suporte a Autoridades Certificadoras customizadas
O novo suporte a certificados de AC customizados resolve um desafio comum em ambientes corporativos: a integração com serviços internos que utilizam certificados SSL assinados pela Autoridade Certificadora interna da organização.
Com esse recurso, agentes de IA podem se conectar perfeitamente a serviços internos como Artifactory, Jira e portais financeiros, além de trabalhar com proxies corporativos que realizam interceptação TLS. Essa capacidade é fundamental para manter a segurança sem fragmentar a operação de agentes autônomos em ambientes corporativos complexos.
Disponibilidade global
Os novos recursos estão disponíveis em todas as 14 regiões da AWS onde o Amazon Bedrock AgentCore Browser e Code Interpreter operam:
US East (N. Virginia), US East (Ohio), US West (Oregon)
Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm)
Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul)
Canada (Central)
Próximos passos
Organizações interessadas em implementar essas funcionalidades podem consultar a documentação do AgentCore Browser para detalhes técnicos de configuração e casos de uso específicos.
Firewall Manager agora disponível na Nova Zelândia
A AWS anunciou a disponibilidade do Firewall Manager na região Asia Pacific (Nova Zelândia). Essa expansão reforça o compromisso da empresa em oferecer soluções de segurança robustas em diferentes geografias, permitindo que mais organizações acessem ferramentas centralizadas de gerenciamento de segurança.
O que é o Firewall Manager
O Firewall Manager é uma solução projetada para auxiliar administradores de segurança em nuvem e engenheiros de confiabilidade de site (SRE) a proteger suas aplicações. Seu principal diferencial é reduzir significativamente a sobrecarga operacional associada à configuração manual e ao gerenciamento de regras de segurança. Em vez de implementar políticas individualmente em cada recurso, os profissionais de segurança podem criar e manter políticas centralizadas.
Capacidades e benefícios
Ao trabalhar com o Firewall Manager, os clientes conseguem implementar políticas de defesa em profundidade que cobrem toda a gama de serviços de segurança disponíveis na AWS. Isso é especialmente valioso para organizações que hospedam suas aplicações e cargas de trabalho em regiões como a de Taipei e agora também em Nova Zelândia.
Uma das aplicações mais comuns do Firewall Manager é a criação e manutenção de políticas de segurança integradas com o AWS WAF (Web Application Firewall). Dessa forma, os clientes podem estabelecer ativos protegidos de forma padronizada e escalável.
Como começar
Para organizações interessadas em implementar o Firewall Manager em Nova Zelândia, a AWS oferece documentação técnica detalhada. Consulte a documentação do Firewall Manager para entender melhor como a ferramenta funciona e os passos necessários para implementação.
Também é recomendado verificar a tabela de regiões da AWS para visualizar a lista completa de regiões onde o Firewall Manager está disponível atualmente, facilitando o planejamento de arquiteturas multi-região.
Para conhecer em detalhes os recursos, funcionalidades avançadas e modelos de preço do Firewall Manager, acesse o site do Firewall Manager.
Conteúdo de vídeo está presente em praticamente todos os setores: monitoramento de segurança, produção de mídia, plataformas de redes sociais e comunicações corporativas. Apesar dessa ubiquidade, extrair informações significativas de grandes volumes de vídeo continua sendo um desafio complexo para as organizações.
O problema vai além de simplesmente identificar objetos na tela. É necessário compreender contexto, fluxo narrativo e significado subjacente do conteúdo. As abordagens tradicionais — revisão manual ou técnicas básicas de visão computacional — enfrentam limitações claras: processamento manual é custoso e lento, sistemas baseados em regras não se adaptam a novos cenários, técnicas convencionais de visão computacional não capturam compreensão semântica e integração em aplicações modernas é complexa.
A emergência dos modelos multimodais oferecidos pela AWS através do Amazon Bedrock muda esse paradigma. Esses modelos conseguem processar informações visuais e textuais simultaneamente, permitindo compreender cenas, gerar descrições em linguagem natural, responder perguntas sobre conteúdo de vídeo e detectar eventos nuançados que seriam difíceis de programar manualmente.
Três abordagens para compreensão de vídeos
Entender conteúdo de vídeo é inerentemente complexo, combinando informações visuais, auditivas e temporais que precisam ser analisadas em conjunto para gerar insights significativos. Diferentes casos de uso — análise de cenas em mídia, detecção de intervalos publicitários, rastreamento de câmeras de segurança ou moderação de conteúdo em redes sociais — exigem fluxos de trabalho distintos com compensações diferentes entre custo, precisão e latência.
A AWS disponibilizou uma solução com três fluxos de trabalho bem definidos, cada um utilizando métodos distintos de extração de vídeo otimizados para cenários específicos.
Abordagem por quadros: precisão em escala
A estratégia baseada em quadros coleta imagens em intervalos fixos, remove quadros semelhantes ou redundantes e aplica modelos multimodais para extrair informações visuais em nível de quadro. A transcrição de áudio é realizada separadamente utilizando o Amazon Transcribe.
Este fluxo é ideal para:
Segurança e vigilância: detectar condições ou eventos específicos ao longo do tempo
Garantia de qualidade: monitorar processos de fabricação ou operacionais
Conformidade regulatória: verificar aderência a protocolos de segurança
A arquitetura utiliza AWS Step Functions para orquestrar todo o pipeline de processamento.
Otimizando custo e qualidade através de amostragem inteligente
Um componente crítico do fluxo baseado em quadros é a deduplicação inteligente de frames, que reduz significativamente os custos de processamento removendo quadros redundantes enquanto preserva a informação visual relevante. A solução oferece dois métodos distintos de comparação de similaridade.
Comparação com Multimodal Embeddings (MME) da Nova: Esse método utiliza o modelo de embeddings multimodais do Amazon Nova para gerar representações vetoriais de 256 dimensões de cada quadro. Cada frame é codificado em um vetor de embedding usando o modelo Nova MME, e a distância cosseno entre quadros consecutivos é calculada. Quadros com distância abaixo do limiar (padrão de 0,2, onde valores menores indicam maior similaridade) são removidos.
Essa abordagem se destaca na compreensão semântica do conteúdo da imagem, mantendo robustez frente a variações menores em iluminação e perspectiva enquanto captura conceitos visuais de alto nível. Porém, incorre em custos adicionais de chamadas à API do Amazon Bedrock para geração de embeddings e adiciona latência ligeiramente maior por quadro. É recomendada para conteúdo onde similaridade semântica importa mais que diferenças em nível de pixel, como detecção de mudanças de cena ou identificação de momentos únicos.
OpenCV ORB (Oriented FAST and Rotated BRIEF): Utiliza uma abordagem de visão computacional, com detecção de características para identificar e combinar pontos-chave entre quadros consecutivos sem necessidade de chamadas externas a APIs. O ORB detecta pontos-chave e computa descritores binários para cada quadro, calculando a pontuação de similaridade como a razão entre características combinadas e pontos-chave totais. Com limiar padrão de 0,325 (onde valores mais altos indicam similaridade maior), esse método oferece processamento rápido com latência mínima e sem custos adicionais de API.
A correspondência de características invariante à rotação a torna excelente para detectar movimento de câmera e transições entre quadros. Contudo, pode ser sensível a mudanças significativas de iluminação e pode não capturar similaridade semântica tão efetivamente quanto abordagens baseadas em embeddings. É recomendada para cenários com câmeras estáticas como vigilância, ou aplicações sensíveis a custos onde similaridade em nível de pixel é suficiente.
Abordagem por cenas: compreendendo o fluxo narrativo
Em vez de amostrar quadros individuais, o fluxo baseado em cenas segmenta vídeos em clipes curtos (shots) ou segmentos de duração fixa e aplica modelos multimodais a cada segmento. Essa abordagem captura contexto temporal dentro de cada cena enquanto mantém flexibilidade para processar vídeos mais longos.
Ao gerar rótulos semânticos e embeddings para cada cena, esse método permite busca e recuperação eficiente de vídeos enquanto equilibra precisão e flexibilidade. A arquitetura agrupa cenas em lotes de 10 para processamento paralelo em etapas subsequentes, melhorando throughput enquanto gerencia limites de concorrência do AWS Lambda.
Este fluxo se destaca em:
Produção de mídia: analisar filmagens para marcadores de capítulos e descrições de cenas
Catalogação de conteúdo: marcar e organizar automaticamente bibliotecas de vídeos
Geração de destaques: identificar momentos-chave em conteúdo de longa duração
Segmentação de vídeo: duas estratégias diferentes
O fluxo baseado em cenas oferece opções flexíveis de segmentação para se adequar a características e casos de uso variados. O sistema baixa o arquivo de vídeo do Amazon Simple Storage Service (Amazon S3) para armazenamento temporário no AWS Lambda, aplicando então o algoritmo de segmentação selecionado conforme parâmetros de configuração.
Detecção de Cenas com OpenCV: Divide automaticamente um vídeo em segmentos baseado em mudanças visuais no conteúdo. Usa a biblioteca PySceneDetect para detectar transições como cortes, mudanças de câmera ou alterações significativas no conteúdo visual. Ao identificar limites naturais de cenas, o sistema mantém momentos relacionados agrupados.
Essa abordagem é particularmente efetiva para vídeos editados ou com narrativa, como filmes, séries, apresentações e vlogs, onde cenas representam unidades significativas de conteúdo. Como a segmentação segue a estrutura do próprio vídeo, comprimentos de segmento variam conforme ritmo e estilo de edição.
Segmentação por Duração Fixa: Divide vídeos em intervalos de tempo iguais, independentemente do que está acontecendo no conteúdo. Cada segmento cobre duração consistente (por exemplo, 10 segundos), criando clipes uniformes e previsíveis. Essa abordagem simplifica o processamento e melhora estimativas de tempo e custo.
Embora possa dividir cenas no meio da ação, segmentação por duração fixa funciona bem para gravações contínuas como vigilância, eventos esportivos ou transmissões ao vivo, onde amostragem regular por tempo é mais importante que preservar limites narrativos.
Embeddings multimodais: busca semântica de vídeos
Embedding multimodal representa uma abordagem emergente e poderosa para compreensão de vídeos, especialmente efetiva para aplicações de busca semântica de vídeo. A solução oferece fluxos de trabalho utilizando modelos de Embedding Multimodal do Amazon Nova e o modelo Marengo do TwelveLabs disponíveis no Amazon Bedrock. Esses fluxos permitem:
Busca em linguagem natural: encontrar segmentos de vídeo usando consultas em texto
Busca por similaridade visual: localizar conteúdo usando imagens de referência
Recuperação entre modalidades: fazer ponte entre conteúdo textual e visual
A arquitetura suporta ambos os modelos de embedding com interface unificada, oferecendo flexibilidade na escolha da melhor solução para cada caso de uso.
Compreendendo compromissos entre custo e desempenho
Um dos desafios-chave na análise de vídeo em produção é gerenciar custos enquanto mantém qualidade. A solução oferece rastreamento integrado de uso de tokens e estimativa de custos para ajudar na tomada de decisões informadas sobre seleção de modelos e configuração de fluxos de trabalho.
Para cada vídeo processado, você recebe desagregação detalhada de custos por tipo de modelo, cobrindo modelos multimodais do Amazon Bedrock e Amazon Transcribe para transcrição de áudio. Com essa visibilidade, é possível refinar a configuração com base em requisitos específicos e restrições orçamentárias.
Arquitetura da solução
A solução completa é construída sobre serviços AWS serverless, proporcionando escalabilidade e eficiência de custos. A arquitetura inclui:
Serviço de Extração: orquestra fluxos baseados em quadros e cenas usando Step Functions
Serviço Nova: backend para Embedding Multimodal Nova com busca vetorial
Serviço TwelveLabs: backend para modelos de embedding Marengo com busca vetorial
Serviço de Agente: assistente de inteligência artificial alimentado por Agentes do Amazon Bedrock para recomendações de fluxos de trabalho
Frontend: aplicação React servida via Amazon CloudFront para interação com usuários
Serviço de Análise: notebooks de exemplo demonstrando padrões de análise subsequentes
Acessando metadados de vídeos
A solução armazena metadados extraídos em múltiplos formatos para acesso flexível:
Amazon S3: Saídas brutas de modelos multimodais, metadados completos de tarefas e ativos processados organizados por ID de tarefa e tipo de dados
Amazon DynamoDB: Dados estruturados e consultáveis otimizados para recuperação por vídeo, timestamp ou tipo de análise através de múltiplas tabelas para diferentes serviços
API Programática: Invocação direta para automação, processamento em lote e integração em pipelines existentes
Esse modelo de acesso flexível permite integrar a ferramenta em seus fluxos de trabalho — seja realizando análise exploratória em notebooks, construindo pipelines automatizados ou desenvolvendo aplicações de produção.
Detecção de Eventos em Câmeras IP: Monitorar automaticamente vigilância para eventos ou condições específicas sem supervisão humana contínua
Análise de Capítulos em Mídia: Segmentar conteúdo de vídeo de longa duração em capítulos lógicos com descrições e metadados automáticos
Moderação de Conteúdo em Redes Sociais: Revisar conteúdo de vídeo gerado por usuários em escala para garantir conformidade com diretrizes de plataforma
Esses exemplos fornecem pontos de partida que você pode estender e customizar para seus casos de uso específicos.
Começando: implantação da solução
A solução está disponível como pacote CDK no GitHub e pode ser implantada em sua conta AWS com apenas alguns comandos. A implantação cria todos os recursos necessários, incluindo:
Máquinas de estado Step Functions para orquestração
Funções Lambda para lógica de processamento
Tabelas DynamoDB para armazenamento de metadados
Buckets S3 para armazenamento de ativos
Distribuição CloudFront para a interface web
Pool de usuários Amazon Cognito para autenticação
Após a implantação, você pode imediatamente começar a fazer upload de vídeos, experimentar diferentes pipelines de análise e modelos multimodais, e comparar desempenho entre configurações.
Conclusão
Análise de vídeo sofisticada não está mais limitada a organizações com equipes especializadas em visão computacional e infraestrutura dedicada. Os modelos multimodais do Amazon Bedrock, combinados com serviços serverless da AWS, tornam análise de vídeo avançada acessível e economicamente viável.
Quer você esteja construindo sistemas de monitoramento de segurança, ferramentas de produção de mídia ou plataformas de moderação de conteúdo, as três abordagens arquiteturais demonstradas nessa solução fornecem pontos de partida flexíveis projetados para requisitos variados. A chave é escolher a abordagem certa para seu caso de uso: baseada em quadros para monitoramento preciso, baseada em cenas para conteúdo narrativo e baseada em embeddings para busca semântica.
À medida que modelos multimodais continuam evoluindo, veremos capacidades ainda mais sofisticadas de compreensão de vídeo emergindo. O futuro é sobre inteligência artificial que não apenas vê quadros de vídeo, mas verdadeiramente compreende a história que eles contam.
Uma ponte entre seu IDE local e a infraestrutura em nuvem
A AWS anunciou um recurso que promete mudar a forma como desenvolvedores trabalham com machine learning e análise de dados. Agora é possível conectar o Cursor IDE diretamente ao Amazon SageMaker Unified Studio usando a extensão AWS Toolkit. Essa integração elimina a necessidade de alternar constantemente entre seu ambiente local e a infraestrutura em nuvem, mantendo você dentro de um único e coeso espaço de desenvolvimento.
Cientistas de dados, engenheiros de aprendizado de máquina e desenvolvedores podem agora aproveitar todos os recursos do Cursor — incluindo sua conclusão de código alimentada por IA, edição por linguagem natural e edição de múltiplos arquivos — enquanto acessam os recursos computacionais escaláveis do Amazon SageMaker.
O que essa integração oferece
Continuidade no seu fluxo de trabalho
Ao conectar o Cursor ao SageMaker Unified Studio, você preserva sua configuração personalizada do IDE local — com suas regras customizadas, extensões preferidas e preferências de modelos de IA — enquanto acessa simultaneamente seus recursos computacionais e dados armazenados no Amazon SageMaker. Tudo isso acontece em um único ambiente integrado, consolidando seus serviços de análise e IA/ML da AWS.
Segurança em primeiro lugar
Como o Cursor é construído sobre Code-OSS (Software de Código Aberto), a autenticação ocorre de forma segura através do AWS IAM via extensão AWS Toolkit. Isso garante acesso controlado a todos os seus domínios e projetos dentro do SageMaker Unified Studio, mantendo o padrão de segurança de nível empresarial que suas operações exigem.
Capacidades ampliadas para seus projetos
O SageMaker Unified Studio, parte da próxima geração do Amazon SageMaker, oferece um conjunto completo de ambientes integrados de desenvolvimento totalmente gerenciados. Você já podia usar JupyterLab e Code Editor baseado em Code-OSS. Agora, essa cobertura se estende ao seu Cursor local totalmente customizado, abrindo possibilidades de um único ponto de acesso para:
Processamento e transformação de dados
Análise SQL através de serviços como Amazon EMR, AWS Glue e Amazon Athena
Fluxos de trabalho de aprendizado de máquina
Tudo isso com suporte a criptografia gerenciada pelo cliente e integração com AWS IAM para atender aos requisitos mais exigentes de segurança empresarial.
Introdução aos Desafios de Agentes de Voz em Tempo Real
Implantar agentes de voz inteligentes que mantêm conversas naturais e semelhantes às humanas é uma tarefa complexa. Esses sistemas precisam transmitir áudio para usuários em múltiplos canais — aplicações web, móveis e telefônicas — mantendo responsividade mesmo sob tráfego pesado e condições de conectividade instáveis. Pequenos atrasos podem interromper o fluxo conversacional, fazendo o agente parecer não responsivo ou pouco confiável.
Para casos de uso como atendimento ao cliente, assistentes virtuais e campanhas de outbound, manter um fluxo conversacional natural é essencial para a experiência do usuário. A série de artigos sobre este tema explora como arquiteturas de streaming ajudam a resolver esses desafios usando agentes de voz Pipecat no Amazon Bedrock AgentCore Runtime.
Nesta primeira parte, você aprenderá como implantar agentes de voz Pipecat no AgentCore Runtime usando diferentes abordagens de transporte de rede — incluindo WebSockets, WebRTC e integração telefônica — com orientações práticas de implantação e exemplos de código.
Benefícios do AgentCore Runtime para Agentes de Voz
Implantação de agentes de voz em tempo real apresenta desafios significativos: é necessário garantir streaming com baixa latência, isolamento rigoroso para segurança e capacidade de escalar dinamicamente conforme o volume de conversas varia de forma imprevisível. Sem uma arquitetura bem projetada, você pode enfrentar jitter de áudio, limitações de escalabilidade, custos inflacionados por sobre-provisionamento e maior complexidade operacional.
O Amazon Bedrock AgentCore Runtime resolve esses desafios fornecendo um ambiente seguro e serverless para escalar agentes de IA dinâmicos. Cada sessão de conversa é executada em microVMs isoladas para segurança. O serviço faz auto-scaling para picos de tráfego e mantém sessões contínuas por até 8 horas, sendo ideal para interações de voz longas com múltiplas voltas. Cobra apenas pelos recursos efetivamente utilizados, minimizando custos associados a infraestrutura ociosa.
O Pipecat, um framework para construir pipelines de IA de voz em tempo real, funciona no AgentCore Runtime com configuração mínima. Você empacota seu pipeline de voz Pipecat como um container e o implanta diretamente no AgentCore Runtime. O runtime suporta streaming bidirecional para áudio em tempo real e oferece observabilidade integrada para rastrear o raciocínio do agente e chamadas a ferramentas. Uma consideração importante: o AgentCore Runtime requer containers ARM64 (Graviton), então certifique-se de que suas imagens Docker foram compiladas para o sistema linux/arm64.
Arquiteturas de Streaming para Agentes de Voz no AgentCore Runtime
Este artigo pressupõe familiaridade com arquiteturas comuns de agentes de voz, especificamente a abordagem de modelos em cascata, onde você conecta modelos de conversão de fala para texto (STT – Conversão de Fala para Texto) e texto para fala (TTS – Conversão de Texto para Fala) em um pipeline, e a abordagem de processamento direto entre falas, como Amazon Nova Sonic. Se você é novo nesses conceitos, comece com os artigos anteriores sobre as duas abordagens fundamentais: cascata e processamento direto entre falas antes de prosseguir.
Na construção de agentes de voz, a latência é uma consideração crítica que determina o quão natural e confiável é uma conversa por voz. As conversas exigem respostas quase instantâneas, tipicamente em menos de um segundo de ponta a ponta, para manter um ritmo fluido e semelhante ao humano. Para alcançar baixa latência, você precisa considerar streaming bidirecional em múltiplos caminhos:
Cliente para Agente: Seus agentes de voz serão executados em dispositivos e aplicações variadas, desde navegadores web e apps móveis até hardware de borda, cada um com condições de rede únicas.
Agente para Modelo: Seus agentes de voz dependem de streaming bidirecional para interagir com modelos de fala. A maioria dos modelos de fala expõe APIs WebSocket em tempo real, que seu runtime de agente ou framework de orquestração pode consumir para entrada de áudio e saída de texto ou fala.
Telefonia: Para chamadas tradicionais de entrada ou saída tratadas através de centros de contato ou sistemas telefônicos, seu agente de voz também deve ser integrado com um provedor de telefonia. Isso é tipicamente realizado através de transferência de handoff e/ou Protocolo de Interconexão de Sessão (SIP – Protocolo de Iniciação de Sessão), onde o stream de áudio ativo é transferido do sistema telefônico para seu runtime de agente para processamento.
A seleção do modelo desempenha um papel fundamental para alcançar responsividade natural. Escolha modelos como Amazon Nova Sonic (ou Amazon Nova Lite em uma abordagem de pipeline em cascata) que são otimizados para latência e oferecem tempo rápido até o primeiro token (TTFT – Time-to-First-Token).
Abordagens de Transporte de Rede
Nesta primeira parte, nos concentramos na conexão Cliente para Agente e em como minimizar a latência de primeira volta de rede entre seu dispositivo de borda e seu agente de voz. A seguir, exploramos quatro abordagens de transporte de rede, considerando performance, resiliência e facilidade de implementação:
WebSockets: Aplicações web e móveis conectam-se diretamente aos agentes de voz via WebSockets. Performance consistente adequada, implementação simples, ideal para prototipagem e casos de uso leves.
WebRTC com TURN: Aplicações web e móveis conectam-se aos agentes via WebRTC com assistência de servidores de retransmissão (Traversal Using Relays around NAT – TURN). Performance excelente, implementação média, adequado para casos de produção com latência reduzida via conexão direta do cliente ao runtime com retransmissão via servidores TURN.
WebRTC Gerenciado: Aplicações web e móveis conectam-se aos agentes através de infraestrutura avançada e distribuída globalmente via WebRTC. Performance excelente com distribuição global, implementação simples, adequado para casos de produção com otimização de latência terceirizada para provedores especializados com rede distribuída globalmente e retransmissão de mídia. Oferece capacidades adicionais como observabilidade e chamadas multi-participante.
Telefonia: Agentes de voz são acessados através de chamadas telefônicas tradicionais. Performance excelente, implementação média, adequado para centros de contato e casos de telefonia. Latência pode depender do provedor de telefonia.
Implementação com WebSockets
Você pode começar com WebSockets como a abordagem mais simples: suporta nativamente a maioria dos clientes e o AgentCore Runtime. Implante agentes de voz Pipecat no AgentCore Runtime usando conexões WebSocket persistentes e bidirecionais para streaming de áudio entre dispositivos cliente e sua lógica de agente.
A conexão segue um fluxo simples de três etapas:
Cliente solicita um endpoint WebSocket: O cliente primeiro envia uma solicitação POST para um servidor intermediário (/server) para obter um endpoint seguro de conexão WebSocket.
Servidor intermediário manipula autenticação AWS: O servidor intermediário na interface pré-construída Pipecat usa o AWS SDK para gerar uma URL pré-assinada AWS SigV4 com credenciais incorporadas como parâmetro de consulta.
Cliente estabelece conexão direta: Usando a URL pré-assinada autenticada, o cliente conecta-se diretamente ao agente no AgentCore Runtime e transmite áudio bidirecional, contornando o servidor intermediário para comunicações subsequentes.
Você usa o transporte WebSocket do Pipecat para expor um endpoint no caminho /ws conforme exigido pelo AgentCore Runtime. A arquitetura separa gerenciamento de credenciais da lógica do agente, permitindo acesso seguro do cliente sem expor credenciais AWS diretamente a aplicações de navegador.
Embora WebSockets funcione bem para implantações simples, WebRTC pode oferecer performance melhorada. É projetado para enviar áudio usando um caminho de rede rápido e leve que minimiza atraso. Geralmente usa UDP por sua baixa latência e experiência mais suave em tempo real, oferecendo resiliência melhorada através de condições variáveis de conectividade. Se UDP não estiver disponível, WebRTC retorna automaticamente para TCP, que é mais confiável mas pode introduzir pequenos atrasos — menos ideal para voz, mas útil quando a conectividade é restrita.
Essa confiabilidade vem dos servidores de Estabelecimento Interativo de Conectividade (ICE – Interactive Connectivity Establishment), que negociam caminhos diretos ponto-a-ponto através de NATs e firewalls, retrocedendo para retransmissão de mídia via servidores Traversal Using Relays around NAT (TURN) quando conexões diretas não podem ser estabelecidas.
O Pipecat suporta SmallWebRTCTransport para conexões WebRTC ponto-a-ponto diretas entre clientes e agentes no AgentCore Runtime. Comparado a arquiteturas WebRTC abrangentes que exigem servidores de mídia dedicados (como Unidades de Encaminhamento Seletivo), esse transporte leve pode ser executado diretamente dentro do AgentCore Runtime, eliminando a necessidade de gerenciamento complexo de servidores de mídia.
Nesse cenário, o fluxo de conexão funciona da seguinte forma:
Sinalização: O cliente envia uma oferta de Protocolo de Descrição de Sessão (SDP – Session Description Protocol) para o servidor intermediário, que a encaminha para o endpoint /invoke/ no AgentCore Runtime. O manipulador @app.entrypoint do agente processa a oferta e retorna uma resposta SDP contendo capacidades de mídia e candidatos de rede.
Estabelecimento de Conectividade: Para estabelecer uma conexão direta, tanto o cliente quanto o agente usam o protocolo ICE (Interactive Connectivity Establishment) para descobrir o caminho de rede ideal.
O AgentCore Runtime suporta conexões retransmitidas via TURN. O protocolo tenta conectividade nesta ordem: conexão direta ponto-a-ponto (não suportada no AgentCore Runtime, pois o ambiente runtime não pode ser atribuído a um endereço IP público), conexão assistida por STUN (requer tráfego UDP bidirecional, não suportado atualmente), e retransmissão via TURN (recomendada).
Configuração do AgentCore Runtime com VPC para Conectividade WebRTC
O exemplo de código demonstra um agente de voz simples usando WebRTC. Primeiro, você configura variáveis de ambiente ICE_SERVER_URLS em ambos: 1) o servidor intermediário na interface pré-construída Pipecat (/server) e 2) o ambiente runtime (/agent). Isso permite tráfego bidirecional entre eles.
Em seguida, você implanta seus agentes no AgentCore Runtime com VPC configurado para permitir transporte UDP para servidores TURN. Para segurança, você expõe o runtime para uma subnet VPC privada, com um NAT Gateway em uma subnet pública para rotear acesso à internet.
Com essa abordagem, você pode configurar servidores ICE para conectividade WebRTC completa, com suporte a STUN e UDP com fallback para TCP. Por exemplo, você pode configurar TURN gerenciado por Cloudflare da seguinte forma:
# Configure agent/.env and server/.env
ICE_SERVER_URLS=stun:stun.cloudflare.com,turn:turn.cloudflare.com:53,turn:turn.cloudflare.com:3478,turn:turn.cloudflare.com:5349
TURN Nativo da AWS com Amazon Kinesis Video Streams
Como alternativa totalmente nativa da AWS a serviços TURN gerenciados, Amazon Kinesis Video Streams (KVS) gerencia infraestrutura TURN sem dependências de terceiros. Fornece credenciais TURN temporárias e com rotação automática via API GetIceServerConfig, evitando dependências de terceiros para travessia NAT.
O fluxo funciona da seguinte forma:
Configuração única: Crie um canal de sinalização KVS. O canal é usado apenas para provisionamento de credenciais TURN — seu agente continua usando o transporte WebRTC do Pipecat para sinalização e mídia.
No momento da conexão: Seu agente chama GetSignalingChannelEndpoint para obter o endpoint HTTPS, depois chama GetIceServerConfig para recuperar credenciais TURN temporárias (URIs, nome de usuário, senha).
Configure a conexão par: Passe as credenciais retornadas para sua RTCPeerConnection como servidores ICE. O tráfego TURN flui através da infraestrutura gerenciada por KVS.
Considerações ao usar TURN gerenciado por KVS:
É nativo da AWS sem dependência externa.
Gerenciamento de credenciais com rotação automática.
Configuração via criação de canal de sinalização e chamadas de API.
Ideal para implantações centradas em AWS.
Custo: Cada canal de sinalização ativo custa 0,03 dólares/mês. Em volume baixo a moderado, isso é negligenciável.
Limite de taxa: GetIceServerConfig é limitado a 5 transações por segundo por canal. Para implantações de alto volume excedendo 100.000 sessões por mês, implemente uma estratégia de pool de canais distribuindo requisições entre múltiplos canais.
Não há suporte PrivateLink: a VPC ainda requer egresso à internet via NAT Gateway para alcançar endpoints TURN do KVS.
Credenciais TURN são temporárias e com rotação automática, sem necessidade de gerenciar rotação.
Embora WebRTC direto ofereça controle, provedores de WebRTC gerenciados comumente fornecem servidores TURN e Unidades de Encaminhamento Seletivo (SFUs – Selective Forwarding Units) distribuídas globalmente para facilitar conectividade confiável e roteamento de mídia com baixa latência. Também fornecem recursos adicionais como análises integradas e observabilidade, e suporte para salas multi-participante além de conversas 1:1 com agentes.
Para agentes de voz em produção em escala, considere provedores gerenciados disponíveis no AWS Marketplace, como Daily. A Daily executa sua infraestrutura WebRTC distribuída globalmente na AWS oferecendo múltiplos modelos de implantação:
SaaS Totalmente Gerenciado: Você conecta à infraestrutura hospedada da Daily via endpoints de API pública. Ideal para implantação rápida e ambientes onde simplicidade operacional é priorizada. Nesse cenário, seu agente no AgentCore Runtime pode simplesmente conectar-se à infraestrutura WebRTC gerenciada via internet pública.
Implantação em VPC do Cliente: Você implanta os servidores de mídia da Daily diretamente em sua VPC para controle completo de rede e conformidade com requisitos rigorosos de residência de dados. Nesse cenário, você configura AgentCore Runtime para VPC conforme descrito acima.
SaaS com AWS PrivateLink: Você conecta à infraestrutura hospedada da Daily e configura AWS PrivateLink para que o tráfego flua através de endpoints VPC diretamente para a infraestrutura gerenciada da Daily sem atravessar a internet pública, reduzindo latência mantendo isolamento de rede. Nesse cenário, você configura AgentCore Runtime para VPC conforme descrito acima.
Enquanto WebRTC se destaca para canais web e móvel, a transferência telefônica permite integração tradicional da Rede Telefônica Pública Comutada (PSTN – Public Switched Telephone Network) para centros de contato, substituição de IVR e campanhas de outbound. Para conversa em tempo real, seu runtime de agente deve manter um stream de áudio persistente e bidirecional com seus modelos de fala, lógica de negócio e provedor de telefonia.
Esses provedores oferecem serviços de voz gerenciados que lidam com a complexidade da infraestrutura telefônica tradicional através de APIs simples. Dependendo das capacidades do provedor de telefonia, você se integra a eles usando Protocolo de Iniciação de Sessão (SIP – Session Initiation Protocol) ou protocolos de streaming WebSocket ou WebRTC.
O AgentCore Runtime fornece infraestrutura segura e serverless para escalar agentes de voz confiáveis. Neste artigo, você aprendeu como baixa latência é crítica para conversas naturais e considerações-chave para diferentes modos de transporte: WebSockets, WebRTC com assistência TURN, WebRTC gerenciado e integrações telefônicas, com base em seus requisitos de latência, confiabilidade e uso.
Ao avaliar opções de transporte, comece simples com WebSockets para prototipagem rápida, depois considere WebRTC com AgentCore em modo VPC ou provedores gerenciados para implantações em produção. Se seus agentes de voz pretendem lidar com casos de telefonia ou centros de contato, considere integrações disponíveis com provedores de telefonia para sua implementação.
Na Parte 2 desta série, você explorará considerações adicionais além do transporte de rede: cobrindo estratégias de streaming através de comunicação agente-para-modelo, execução de ferramentas, memória e recuperação para alcançar latência ótima de ponta a ponta.
Entendendo o Aprendizado por Reforço em Modelos de Linguagem
Em dezembro de 2025, a AWS anunciou a disponibilidade do aprendizado por reforço para fine-tuning (RFT) no Amazon Bedrock, inicialmente com suporte aos modelos Nova. Alguns meses depois, em fevereiro de 2026, expandiu o suporte para modelos de código aberto como OpenAI GPT OSS 20B e Qwen 3 32B. O RFT no Amazon Bedrock automatiza todo o fluxo de customização de modelos, permitindo que eles aprendam com feedback sobre múltiplas respostas possíveis usando um conjunto pequeno de prompts, em vez de grandes datasets tradicionais.
O Conceito Fundamental: Aprender com Feedback
O aprendizado por reforço funciona como ensinar um agente — neste caso, um modelo de linguagem — a tomar melhores decisões fornecendo feedback sobre suas ações. Pense na analogia de treinar um jogador de xadrez: em vez de mostrar cada movimento possível em cada situação imaginável, você deixa o jogador jogar e indica quais movimentos levaram a posições vencedoras. Com o tempo, o jogador aprende a reconhecer padrões e tomar decisões estratégicas que levam ao sucesso.
Para modelos de linguagem, o processo é similar. O modelo gera múltiplas respostas possíveis para um prompt, recebe pontuações (recompensas) para cada resposta baseadas em quão bem elas atendem seus critérios, e aprende a favorecer os padrões e estratégias que produzem saídas com pontuação mais alta.
Componentes Principais do RFT
O RFT envolve quatro componentes essenciais: o modelo ator/agente (política), os estados de entrada, as ações de saída e a função de recompensa.
O modelo ator é o modelo de fundação que você está customizando. No Amazon Bedrock RFT, pode ser Amazon Nova, Llama, Qwen ou outros modelos suportados. O estado é o contexto atual, incluindo o prompt, histórico de conversa (para interações multi-turno) e metadados relevantes. A ação é a resposta do modelo ao prompt. A função de recompensa atribui uma pontuação numérica ao par (estado, ação), avaliando a qualidade da resposta do modelo para um determinado estado.
A função de recompensa pode usar informações adicionais como respostas de referência ou testes unitários para geração de código. É esse o sinal crítico de feedback que impulsiona o aprendizado — pontuações mais altas indicam respostas melhores. Uma vantagem chave do RFT é que o modelo aprende com as respostas que gera durante o treinamento, não apenas com exemplos pré-coletados. Essa abordagem desbloqueia vários benefícios cumulativos: como o modelo explora ativamente novas abordagens e aprende com os resultados, pode se adaptar em tempo real, encontrando naturalmente novos cenários que o impulsionam para frente. Isso também torna o processo muito mais eficiente, eliminando a necessidade de pré-gerar e rotular milhares de exemplos antecipadamente.
Como o Amazon Bedrock RFT Funciona
O Amazon Bedrock RFT foi construído para tornar o aprendizado por reforço viável no nível empresarial. Ele gerencia a infraestrutura pesada, permitindo que as equipes se concentrem no problema que estão resolvendo, não na complexidade técnica subjacente.
Todo o pipeline de RFT é executado automaticamente. Para cada prompt no seu dataset de treinamento, o Amazon Bedrock gera múltiplas respostas candidatas do seu modelo ator, gerenciando batching, paralelização e alocação de recursos nos bastidores. O cálculo de recompensas escala perfeitamente. Seja usando recompensas verificáveis ou uma configuração com modelo-como-juiz, o Amazon Bedrock orquestra a avaliação em milhares de pares prompt-resposta enquanto gerencia concorrência e recuperação de erros automaticamente.
A otimização de política executa o GRPO (um algoritmo de aprendizado por reforço de última geração), com detecção de convergência integrada para que o treinamento pare quando apropriado. Durante todo o processo, métricas do Amazon CloudWatch e o console do Amazon Bedrock oferecem visibilidade em tempo real sobre tendências de recompensa, atualizações de política e desempenho geral do modelo.
O fluxo de trabalho começa do seu ambiente de desenvolvimento (VS Code, Terminal, Jupyter ou notebook SageMaker AI) usando o SDK padrão do OpenAI apontado para o endpoint Mantle do Bedrock. A partir daí:
Upload de dados de treinamento via Files API (formato .jsonl com mensagens e respostas de referência)
Deploy de uma função de recompensa como AWS Lambda que pontua respostas geradas pelo modelo
Criação do job de fine-tuning — o engine GRPO do Bedrock gera respostas, envia para seu Lambda grader e atualiza pesos com base nas pontuações
Monitoramento de treinamento via eventos e checkpoints
Invocação de seu modelo fine-tuned sob demanda — sem provisionamento de endpoint, sem hosting
Seus dados não deixam o ambiente seguro da AWS durante o processo e não são utilizados para treinar modelos fornecidos pelo Amazon Bedrock.
Guia Prático: Configuração e Treinamento
Pré-requisitos
Antes de começar, você precisa de:
Uma conta AWS com acesso ao Amazon Bedrock em uma região suportada
Uma chave de API do Bedrock (de curto ou longo prazo). Você também pode autenticar usando credenciais AWS Sigv4, mas neste guia usamos uma chave de API do Amazon Bedrock
Funções IAM para execução de Lambda e fine-tuning do Amazon Bedrock
Python com openai, boto3 e aws-bedrock-token-generator instalados. Se estiver trabalhando em um shell dentro de um venv ou com Jupyter notebook, execute: pip install openai boto3 aws-bedrock-token-generator
Etapa 1: Configurar o Cliente OpenAI
Aponte o SDK padrão do OpenAI para seu endpoint Amazon Bedrock Mantle. A autenticação usa uma chave de API do Bedrock gerada através da biblioteca aws-bedrock-token-generator:
from openai import OpenAI
from aws_bedrock_token_generator import provide_token
AWS_REGION = "us-west-2"
MANTLE_ENDPOINT = f"https://bedrock-mantle.{AWS_REGION}.api.aws"
client = OpenAI(
base_url=f"{MANTLE_ENDPOINT}/v1",
api_key=provide_token(region=AWS_REGION),
)
É isso. Cada chamada subsequente usa a interface padrão do SDK do OpenAI! Recomenda-se usar e renovar chaves do Bedrock de curto prazo conforme necessário, em vez de definir e usar chaves de longo prazo que não expiram.
Etapa 2: Preparar e Fazer Upload de Dados de Treinamento
Cada registro no dataset requer um campo messages e pode incluir opcionalmente um campo reference_answer. O campo messages contém o prompt apresentado ao modelo, formatado usando o padrão de mensagem do OpenAI onde cada mensagem especifica um role (como “user”) e conteúdo correspondente. O campo reference_answer opcional fornece contexto complementar para cálculo de recompensa, como uma resposta de verdade fundamental, regra de avaliação ou dimensões de pontuação usadas pela função de recompensa.
Para exemplos do dataset matemático GSM8K, cada amostra de treinamento contém um problema matemático em linguagem natural na mensagem do usuário e uma resposta de referência contendo a solução numérica correta. O prompt instrui o modelo a fornecer seu raciocínio dentro de tags estruturadas e apresentar a resposta final em formato \boxed{} que a função de recompensa possa extrair confiavelmente:
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "A chat between a curious User and an artificial intelligence Bot. The Bot gives helpful, detailed, and polite answers to the User's questions. The Bot first thinks about the reasoning process and then provides the User with the answer. The reasoning process and answer are enclosed within <|begin_internal_thought|> <|end_internal_thought|> and <|begin_of_solution|> <|end_of_solution|> respectively. The final answer must be enclosed in \\boxed{} within the solution block.\n\nNatalia sold clips to 48 of her friends in April, and then she sold half as many clips in May. How many clips did Natalia sell altogether in April and May?"
}
]
}
],
"reference_answer": {
"answer": "72"
},
"data_source": "gsm8k_nova"
Um repositório do GitHub fornece uma função auxiliar para converter os registros brutos do GSM8K para formato JSONL compatível com Amazon Bedrock RFT. Note que o campo data_source garante que a função de recompensa apropriada seja aplicada durante o treinamento, enquanto os formatos de prompt estruturados alinham as saídas com a lógica de extração da função de recompensa.
Os dados de treinamento são um arquivo JSONL onde cada linha contém uma conversa com mensagens e uma resposta de referência:
{
"messages": [
{"role": "user", "content": "Janet's ducks lay 16 eggs per day. She eats three for breakfast and bakes muffins with four. She sells the rest at $2 each. How much does she make daily? Let's think step by step and output the final answer after '####'."}
],
"reference_answer": "#### 18"
}
Você pode usar campos adicionais aqui que sejam úteis para sua função Lambda grader na próxima etapa, mas note que a estrutura messages e reference_answer são obrigatórias. Você pode fazer upload do seu dataset preparado via Files API:
with open("rft_train_data.jsonl", "rb") as f:
file_response = client.files.create(file=f, purpose="fine-tune")
training_file_id = file_response.id
print(f"Training file uploaded: {training_file_id}")
Etapa 3: Deploy de uma Função Lambda de Recompensa
A função de recompensa é o núcleo do RFT. Ela recebe respostas geradas pelo modelo e retorna uma pontuação. Para problemas matemáticos, é direto: extrair a resposta e compará-la com a verdade fundamental. Aqui está um exemplo da função de recompensa usada em um caso prático (do repositório de exemplos):
def lambda_handler(event, context):
trajectories = event if isinstance(event, list) else event.get("trajectories", [])
scores = []
for trajectory in trajectories:
trajectory_id = trajectory.get("id", "no-id")
# Get the model's response from the last assistant message
response = ""
for msg in reversed(trajectory.get("messages", [])):
if msg.get("role") == "assistant":
response = msg.get("content", "")
break
# Extract ground truth from reference answer
reference_answer = trajectory.get("reference_answer", {})
reference_text = reference_answer.get("text", "")
gt_match = re.findall(r"#### (\-?[0-9\.\,]+)", reference_text)
ground_truth = gt_match[-1].replace(",", "") if gt_match else ""
# Score: 1.0 if correct, 0.0 otherwise
result = compute_score(
trajectory_id=trajectory_id,
solution_str=response,
ground_truth=ground_truth,
)
scores.append(asdict(result))
return scores
A função retorna uma lista de objetos RewardOutput, cada um contendo um aggregate_reward_score entre 0 e 1. Deploy isso como uma função AWS Lambda com timeout de 5 minutos e 512 MB de memória. Note que você pode customizar completamente o que acontece dentro dessa função Lambda de recompensa para adequar-se ao seu caso de uso. O Amazon Bedrock também suporta graders modelo-como-juiz para tarefas subjetivas onde verificação automatizada não é possível. Para mais informações sobre configuração de funções de recompensa, consulte a documentação sobre configuração de funções de recompensa para modelos de código aberto.
Etapa 4: Criar o Job de Fine-tuning
Use a seguinte chamada de API única para iniciar o job:
Para um job de exemplo com GPT-OSS que usa o subset de dados GSM8K, o treinamento executa um total de 67 etapas com vários eventos emitidos conforme o job progride.
Um evento típico durante o progresso de treinamento contém várias métricas importantes. O critic_rewards_mean (pontuação média de recompensa no lote) é a métrica principal a observar — você quer que suba. O actor_pg_loss (perda de gradiente de política) é o objetivo sendo otimizado. O actor_entropy (quanto dispersa está a distribuição de probabilidade de tokens) indica exploração; se cair para 0, há colapso de modo. O actor_grad_norm (magnitude da atualização de gradiente) ajuda a identificar instabilidade. O response_length_mean (comprimento médio de tokens das respostas) deve ser monitorado — se crescer descontroladamente, o modelo pode estar “hackeando” o sistema para ganhar recompensa baseada em tamanho.
O código de exemplo também fornece exemplos de como plotar essas métricas. A curva de recompensa mostra o modelo melhorando de aproximadamente 0.56 para consistentemente 0.85–0.97 no meio do treinamento. Os comprimentos de resposta também tendem a ficar mais curtos ao longo do tempo, sugerindo que o modelo aprendeu a ser mais conciso enquanto resolve problemas do GSM8K corretamente.
Após o job ter sucesso, invoque seu modelo fine-tuned diretamente. Sem provisionamento de endpoint, sem hosting:
job_details = client.fine_tuning.jobs.retrieve(job_id)
fine_tuned_model = job_details.fine_tuned_model
response = client.chat.completions.create(
model=fine_tuned_model,
messages=[
{"role": "user", "content": "If a train travels 120 miles in 2 hours, what is its speed in miles per hour?"}
],
)
print(response.choices[0].message.content)
Você também pode usar a API de respostas para transmitir respostas do modelo fine-tuned:
stream = client.responses.create(
model=fine_tuned_model,
input=[{"role": "user", "content": "Your prompt here"}],
stream=True,
reasoning={"effort": "low"}
)
for event in stream:
if event.type == "response.output_text.delta":
print(event.delta, end="", flush=True)
O aprendizado por reforço para fine-tuning no Amazon Bedrock reúne três elementos que tornam o fluxo de trabalho de ponta a ponta prático: compatibilidade com SDK OpenAI (não há novo SDK para aprender — aponte OPENAI_BASE_URL e OPENAI_API_KEY para Bedrock e use as mesmas chamadas client.fine_tuning.jobs.create()), funções de recompensa baseadas em Lambda (escreva sua lógica de pontuação em Python, deploy como Lambda, e o Amazon Bedrock gerencia o loop de treinamento com GRPO para você) e inferência sob demanda (sem gerenciamento de endpoint — chame client.chat.completions.create() com seu ID de modelo fine-tuned e pague por token).
Para organizações brasileiras e globais que trabalham com inteligência artificial, essa abordagem simplifica significativamente a customização de modelos de linguagem em escala, eliminando a complexidade técnica e acelerando o tempo para resultados.
Desafio de Extração de Informações em Dados Não Estruturados
As organizações enfrentam um desafio comum em diversos setores: como extrair informações valiosas de grandes volumes de dados não estruturados de forma eficiente. Abordagens tradicionais frequentemente envolvem processos que consomem muitos recursos e utilizam modelos rígidos e inflexíveis. A AWS apresenta uma solução inovadora através do Claude Tool Use disponível no Amazon Bedrock, que aproveita o poder dos modelos de linguagem de grande escala para realizar extração de entidades dinâmica e adaptável, sem requerer configuração extensiva ou treinamento prévio.
O que é Claude Tool Use (Function Calling)?
O Claude Tool Use, também conhecido como function calling, é uma capacidade poderosa que permite expandir as habilidades do Claude estabelecendo e invocando funções ou ferramentas externas. Este recurso viabiliza fornecer ao Claude uma coleção de ferramentas pré-estabelecidas que ele pode acessar e empregar conforme necessário, potencializando sua funcionalidade.
O funcionamento é direto: usuários definem um conjunto de ferramentas com seus nomes, esquemas de entrada e descrições. Quando recebe um prompt do usuário que pode requerer o uso de uma ou mais ferramentas, o Claude avalia a solicitação e determina se alguma ferramenta seria útil. Se aplicável, o modelo seleciona qual ferramenta utilizar e com quais parâmetros de entrada.
Arquitetura da Solução
A solução apresentada demonstra como extrair campos customizados de carteiras de motorista utilizando o Claude Tool Use no Amazon Bedrock. Trata-se de uma solução serverless que processa documentos em tempo real, extraindo informações como nomes, datas e endereços sem necessidade de treinamento tradicional de modelos.
A arquitetura utiliza vários serviços AWS para criar um pipeline integrado e eficiente:
Usuários fazem upload de documentos no Amazon S3 para processamento
Um evento de PUT do S3 dispara uma função do AWS Lambda
O Lambda processa o documento e envia para o Amazon Bedrock
O Bedrock invoca o Claude para extração de entidades
Os resultados são registrados no Amazon CloudWatch para monitoramento
Componentes Principais
Amazon S3: Armazena os documentos de entrada
AWS Lambda: Dispara no upload de arquivo, envia prompts e dados ao Claude, armazena resultados
Amazon Bedrock (Claude): Processa a entrada e extrai as entidades
Amazon CloudWatch: Monitora e registra o desempenho do workflow
Crie um bucket S3 de origem para a entrada (por exemplo, driver-license-input). Configure as funções e permissões de IAM conforme necessário. Um exemplo de política de permissões:
A função Lambda é disparada automaticamente quando uma nova imagem é enviada para o seu bucket S3. Ela lê a imagem, codifica em base64 e a envia para o Claude 4.5 Sonnet via Amazon Bedrock usando a API de Tool Use.
A função define uma ferramenta chamada extract_license_fields para fins de demonstração. No entanto, você pode definir nomes de ferramentas e esquemas baseados em seu caso de uso específico — por exemplo, extração de dados de cartões de seguro, crachás de identificação ou formulários comerciais. O Claude seleciona dinamicamente se invoca sua ferramenta baseado na relevância do prompt e estrutura da entrada.
Estamos usando "tool_choice": "auto" para deixar o Claude decidir quando invocar a função. Em casos de produção, você pode querer definir explicitamente "tool_choice": { "type": "tool", "name": "seu_nome_de_ferramenta" } para comportamento determinístico.
Acesse o console do AWS Lambda, escolha Create function, selecione Author from scratch, configure o runtime para Python 3.12 e crie a função.
Configuração do Timeout do Lambda
Na configuração da sua função Lambda, acesse a aba General Configuration e edite o timeout, aumentando do padrão de 3 segundos para no mínimo 30 segundos. Recomenda-se configurar para 1-2 minutos para imagens maiores. Este ajuste é crucial pois o processamento de imagens através do Claude pode levar mais tempo que o timeout padrão do Lambda, especialmente para imagens de alta resolução ou ao processar múltiplos campos.
Código da Função Lambda
Cole o seguinte código no arquivo lambda_function.py:
Após colar o código, escolha o botão Deploy no lado esquerdo do editor de código e aguarde a mensagem de confirmação. Sempre lembre-se de fazer deploy do seu código após realizar alterações, garantindo que o código mais recente seja salvo e executado quando a função Lambda for disparada.
Trabalhando com Esquemas de Tool Use do Claude
O Amazon Bedrock com Claude 4.5 Sonnet suporta function calling usando Tool Use, onde você define ferramentas exigíveis com esquemas JSON claros. Uma entrada de ferramenta válida deve incluir:
name: Identificador da sua ferramenta (ex: extract_license_fields)
input_schema: Esquema JSON que define campos obrigatórios, tipos e estrutura
Você pode definir múltiplas ferramentas no array de ferramentas. O Claude seleciona uma (ou nenhuma) dependendo do valor de tool_choice e o quão bem o prompt corresponde a um esquema específico. Use "tool_choice": "auto" para deixar o Claude decidir. Use um nome de ferramenta explícito para forçar invocação: "tool_choice": { "type": "tool", "name": "extract_license_fields" }.
Note que o campo tool_choice é opcional. Se omitido, o Claude padrão para “auto”.
Configuração de Notificação de Evento do S3 (5 minutos)
Abra o console do Amazon S3, selecione seu bucket, acesse a aba Properties, role para baixo até Event notifications, clique em Create event notification. Digite um nome para a notificação (por exemplo, “LambdaTrigger”), selecione PUT sob Event types, escolha Lambda function como Destination, selecione sua função Lambda no dropdown e salve as alterações.
Testes e Validação
Formatos Suportados
O Claude 4.5 suporta entradas de imagem nos formatos JPEG, PNG, WebP e GIF de frame único. Esta implementação atualmente suporta apenas imagens .jpeg, mas você pode estender o suporte para outros formatos modificando o campo media_type na função Lambda para corresponder ao tipo MIME do arquivo enviado.
Limites de Tamanho e Resolução
Tamanho máximo de imagem: 20 MB
Resolução recomendada: 300 DPI ou superior
Dimensões máximas: 4096 x 4096 pixels
Imagens maiores que isso podem falhar no processamento ou produzir resultados imprecisos.
Dicas de Pré-processamento para Melhor Precisão
Recorte a imagem próxima do documento para remover ruído e seções irrelevantes
Ajuste contraste e brilho para garantir que o texto seja claramente legível
Desincline documentos digitalizados e garanta que o texto esteja alinhado horizontalmente
Evite screenshots de baixa resolução ou imagens com artefatos de compressão pesada
Prefira fundos brancos e texto escuro para máxima clareza de OCR
Upload de Imagem de Teste
Abra seu bucket S3, faça upload de uma imagem de carteira de motorista (formatos suportados: .jpeg, .jpg). Garanta que a imagem esteja clara e legível para melhores resultados.
Monitoramento com CloudWatch
Acesse o console do Amazon CloudWatch, clique em Log groups na navegação esquerda, procure pelo nome da sua função Lambda, clique no stream de log mais recente (ordenado por timestamp) e visualize os resultados da execução.
Otimização e Boas Práticas
Otimização de Desempenho
Configure as definições de memória e timeout do Lambda apropriadamente
Implemente processamento em lote para múltiplos documentos
Use notificações de evento do S3 para processamento automático
Adicione métricas do CloudWatch para monitoramento contínuo
Boas Práticas de Segurança
Implemente criptografia em repouso para buckets S3
Habilite endpoints de nuvem privada virtual para acesso de rede privada
Tratamento de Erros e Monitoramento
A saída do Claude é estruturada como uma lista de blocos de conteúdo, que podem incluir respostas de texto, tool_calls ou outros tipos de dados. Para depuração: sempre registre a resposta bruta do Claude, verifique se tool_calls está presente na resposta, e use um bloco try-except em torno da chamada de função para capturar erros como payloads malformados ou timeouts de modelo.
Limpeza
Após completar seus testes, delete o bucket S3 e seu conteúdo, remova as funções Lambda, delete as funções e políticas de IAM, e desabilite o acesso ao Bedrock se não mais necessário.
Conclusão
O Claude Tool Use no Amazon Bedrock oferece uma solução poderosa para extração de entidades customizadas, minimizando a necessidade de modelos complexos de aprendizado de máquina. Esta arquitetura serverless viabiliza processamento escalável e econômico de documentos com configuração e manutenção mínimas. Ao aproveitar o poder de modelos de linguagem de grande escala através do Amazon Bedrock, as organizações podem desbloquear novos níveis de eficiência, insight e inovação no tratamento de dados não estruturados.
Próximos Passos
Recomenda-se explorar esta solução implementando o código de amostra em seu ambiente e customizando-o para seus casos de uso específicos. Participe das discussões sobre soluções de extração de entidades na comunidade do AWS re:Post, onde você pode compartilhar experiências e aprender com outros desenvolvedores.
Para insights técnicos mais profundos, explore a documentação abrangente sobre Amazon Bedrock, AWS Lambda e Amazon S3. Considere aprimorar sua implementação integrando-a com Amazon Textract para recursos adicionais de processamento de documentos ou Amazon Comprehend para análise de texto avançada.
Garantindo capacidade de GPU previsível para inferência
Implementar grandes modelos de linguagem (LLMs) para inferência exige capacidade confiável de processamento em GPU, especialmente durante períodos críticos de avaliação, testes limitados de produção ou picos de demanda. Quando a disponibilidade de recursos sob demanda é incerta — principalmente em horários de pico — essa imprevisibilidade pode comprometer cronogramas de implantação e impactar o desempenho das aplicações.
A solução apresentada pela Amazon SageMaker permite que clientes utilizem planos de treinamento para reservar capacidade de computação em períodos específicos. Inicialmente projetados para cargas de treinamento, esses planos agora suportam endpoints de inferência, oferecendo disponibilidade previsível de GPU para workloads vinculados ao tempo.
O cenário prático de avaliação de modelos
Imagine uma equipe de ciência de dados que precisa avaliar diversos modelos de linguagem ajustados em um período de duas semanas antes de selecionar um para produção. A equipe necessita de acesso ininterrupto a instâncias ml.p5.48xlarge para executar benchmarks comparativos, mas a capacidade sob demanda em sua região AWS é imprevisível durante horas de pico. Ao reservar capacidade através dos planos de treinamento, a equipe consegue executar suas avaliações ininterruptamente com custos controlados e disponibilidade garantida.
O Amazon SageMaker oferece um mecanismo flexível para garantir essa capacidade. Você busca ofertas disponíveis, seleciona o tipo de instância, quantidade e duração que correspondem às suas necessidades, e cria uma reserva — seja por um número fixo de dias ou meses, ou por uma quantidade específica de dias consecutivos.
O primeiro passo é identificar capacidade disponível de GPU da família p que corresponda aos seus requisitos. No exemplo da equipe, eles precisam de uma instância ml.p5.48xlarge por uma semana, começando no final de janeiro. Utilizando a API de busca de ofertas de planos de treinamento, especificam o tipo de instância, quantidade, duração em horas, e a janela de tempo desejada:
A resposta fornece informações detalhadas sobre cada bloco de capacidade disponível — tipo de instância, quantidade, duração, zona de disponibilidade e preço. Cada oferta inclui horários específicos de início e fim, permitindo selecionar uma reserva que se alinhe ao cronograma de implantação:
É possível criar planos de treinamento diretamente pelo console do SageMaker, que oferece uma interface visual para buscar capacidade e completar a reserva. O fluxo do console segue três etapas: buscar ofertas, adicionar detalhes do plano e revisar e comprar.
No console, você navega até Modelo training & customization no painel de navegação, seleciona Training plans e clica em Create training plan. Na busca, seleciona Inference Endpoint como alvo, escolhe o tipo de instância desejado (ex: ml.p5.48xlarge), especifica a quantidade e a duração, e clica em Find training plan para visualizar ofertas disponíveis.
Após selecionar um plano, o console conduz através das etapas finais de confirmação de detalhes e revisão de termos. Após a compra, você recebe o ARN do plano de treinamento, que será essencial para configurar o endpoint de inferência.
Etapa 2: Criar configuração de endpoint com a reserva
Com a reserva garantida, a próxima etapa é criar uma configuração de endpoint que vincule seu endpoint de inferência à capacidade reservada. O passo crítico aqui é incluir o objeto CapacityReservationConfig na seção ProductionVariants, onde você define MlReservationArn como o ARN do plano de treinamento obtido anteriormente:
Quando o SageMaker recebe essa solicitação, valida se o ARN aponta para uma reserva de plano de treinamento ativa com tipo de recurso de alvo “endpoint”. Se a validação tiver sucesso, a configuração do endpoint é criada e fica elegível para implantação.
A configuração CapacityReservationPreference é particularmente importante: ao defini-la como capacity-reservations-only, você restringe o endpoint apenas à sua capacidade reservada. Quando a reserva expira, o endpoint para de servir tráfego automaticamente, evitando cobranças inesperadas.
Etapa 3: Implantar o endpoint na capacidade reservada
Com a configuração de endpoint pronta, procede-se à implantação:
O endpoint agora executa integralmente dentro da capacidade do plano de treinamento reservado. O SageMaker provisiona a instância ml.p5.48xlarge na zona de disponibilidade especificada e carrega o modelo — esse processo pode levar vários minutos. Quando o endpoint atinge o status InService, você está pronto para iniciar sua carga de trabalho de avaliação.
Etapa 4: Invocar o endpoint durante período ativo
Com o endpoint em serviço, você pode executar sua carga de trabalho de avaliação. Invocações do endpoint para inferência em tempo real permitem enviar prompts de teste e medir qualidade de resposta, latência e vazão:
Durante a janela de reserva ativa, o endpoint opera normalmente com capacidade garantida. Todas as invocações são processadas usando os recursos reservados, facilitando desempenho e disponibilidade previsíveis, sem preocupações com restrições de capacidade ou variabilidade de performance.
Etapa 5: Comportamento quando a reserva expira
É importante entender o que acontece quando o plano de treinamento expira enquanto o endpoint ainda está implantado. O comportamento do endpoint depende da configuração CapacityReservationPreference. Como foi definida como capacity-reservations-only, o endpoint para de servir tráfego e invocações falham com erro de capacidade:
Para retomar o serviço, você deve criar uma nova reserva de plano de treinamento e atualizar a configuração do endpoint, ou atualizar o endpoint para usar capacidade sob demanda. Se a avaliação foi concluída, a equipe pode simplesmente excluir o endpoint em vez de estender a reserva.
Etapa 6: Atualizar endpoint durante o período de avaliação
Durante o período de avaliação, você pode precisar atualizar o endpoint por diversas razões. O SageMaker suporta vários cenários de atualização enquanto mantém a conexão com a capacidade reservada.
Atualizar para nova versão de modelo
Se no meio da avaliação você deseja testar uma versão de modelo melhorada com ajuste fino adicional, você pode atualizar para a nova versão mantendo a mesma capacidade reservada:
Se a avaliação se estender além do esperado ou se você deseja levar o endpoint para produção depois que a reserva expirar, você pode migrar para capacidade sob demanda:
Etapa 7: Escalar o endpoint dentro dos limites de reserva
Em alguns cenários, você pode reservar mais capacidade do que implanta inicialmente, oferecendo flexibilidade para escalar quando necessário. Por exemplo, se a equipe reservou duas instâncias mas implantou apenas uma, ela pode escalar durante a avaliação para testar cenários de maior vazão:
Contudo, se você tentar escalar além da capacidade reservada, a atualização falhará:
{
"Error": {
"Code": "ValidationException",
"Message": "Requested instance count (3) exceeds reserved capacity (2) for training plan."
}
}
Etapa 8: Excluir o endpoint e encerrar
Após completar a avaliação de uma semana e reunir todas as métricas de desempenho necessárias, a equipe está pronta para limpar a infraestrutura. A reserva do plano de treinamento expira automaticamente no final da janela especificada. Um detalhe importante: você é cobrado pelo período completo de reserva, independente de quando exclui o endpoint.
Excluir um endpoint não cancela ou reembolsa a reserva do plano de treinamento — a capacidade reservada permanece alocada até que a janela de reserva expire. Porém, se a reserva ainda está ativa e capacidade está disponível, você pode criar um novo endpoint usando o mesmo ARN de plano de treinamento.
Para fazer limpeza completa, você pode excluir a configuração do endpoint:
Ao configurar sua reserva de plano de treinamento, lembre-se de que você está se comprometendo com uma janela de tempo fixa e será cobrado pelo período integral antecipadamente, independentemente do tempo real de uso. Verifique que seu cronograma estimado se alinhe com a duração da reserva escolhida. Se você concluir o trabalho antes do previsto, o custo não se altera — se adquirir uma reserva de 7 dias, pagará pelos sete dias mesmo que termine em cinco.
Considerações práticas e boas práticas
A estrutura de custo previsível e antecipado oferecida pelos planos de treinamento oferece vantagens significativas para orçamento e planejamento de projetos. Você sabe exatamente quanto gastará antes de começar.
Lembre-se que ao deletar seu endpoint, a reserva do plano de treinamento não é cancelada ou reembolsada. A capacidade reservada permanece alocada até a expiração da janela de reserva. Se você terminar antes e deseja usar o tempo remanescente, pode reimplantar um novo endpoint usando o mesmo ARN de plano de treinamento, desde que a reserva ainda esteja ativa e capacidade disponível.
Conclusão
Os planos de treinamento do SageMaker oferecem um caminho direto para reservar capacidade de GPU da família p e implantar endpoints de inferência com disponibilidade garantida. Essa abordagem é recomendada para workloads vinculados ao tempo — como avaliação de modelos, testes limitados de produção e cenários de picos de demanda previsíveis — onde capacidade previsível é essencial.
Como vimos na jornada da equipe de ciência de dados, o processo envolve identificar requisitos de capacidade, buscar ofertas disponíveis, criar uma reserva e referenciar essa reserva na configuração do endpoint para implantar durante a janela de reserva. A equipe completou sua avaliação de modelo com capacidade garantida, evitando a imprevisibilidade de disponibilidade sob demanda durante horas de pico.
Com suporte para atualizações de endpoint, escalabilidade dentro dos limites de reserva e migração perfeita para capacidade sob demanda, os planos de treinamento oferecem flexibilidade para gerenciar workloads de inferência enquanto mantêm controle sobre disponibilidade de GPU e custos. Quer você execute benchmarks competitivos de modelos, execute testes A/B limitados no tempo ou lide com picos de tráfego previsíveis, os planos de treinamento para endpoints de inferência fornecem a capacidade necessária com preço transparente e antecipado.
