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.
A integração entre Amazon Bedrock AgentCore e Slack oferece um novo paradigma para empresas que desejam colocar assistentes de IA inteligentes diretamente nos espaços de colaboração onde os times trabalham. Em vez de alternar entre aplicações, perder histórico de conversas ou lidar com reauthenticação constante, os usuários podem interagir com agentes de IA nativamente dentro do Slack.
A arquitetura dessa integração resolve três desafios técnicos fundamentais: validar requisições de eventos do Slack para garantir segurança, manter contexto de conversa através de threads, e gerenciar respostas que excedem os limites de timeout da plataforma. Desenvolvedores costumam investir tempo construindo manipuladores de webhook personalizados para integrações com Slack. O AgentCore reduz esse trabalho oferecendo memória de conversa integrada, acesso seguro a agentes e suas ferramentas, além de gerenciamento de identidade que rastreia o uso dos agentes, tudo dentro do próprio Slack.
Visão Geral da Solução
A solução é composta por dois componentes principais: a infraestrutura de integração com Slack e o Amazon AgentCore Runtime com suas ferramentas. A infraestrutura de integração roteia e gerencia a comunicação entre Slack e o agente, enquanto o runtime processa e responde às consultas.
O runtime mantém contexto ao longo das conversas e utiliza o Model Context Protocol (MCP), um protocolo padronizado para execução de ferramentas e comunicação, para invocar as ferramentas necessárias.
Arquitetura da Solução
A arquitetura se divide em três seções principais:
Seção B – Componentes AgentCore: O WeatherAgentCoreStack implementa o AgentCore Runtime, Gateway, Memory e funções AWS Lambda. O runtime utiliza o Strands Agents Framework, um SDK de Agentes de IA de Código Aberto, para orquestrar invocações de modelo, chamadas de ferramentas e memória de conversa.
Seção C – Infraestrutura de Integração Slack: O WeatherAgentSlackStack implementa a infraestrutura de integração (API Gateway, Secrets Manager, funções Lambda e SQS). Esta camada é reutilizável para outros casos de uso com AgentCore.
Um usuário envia uma mensagem no Slack através de mensagem direta ou mencionando o bot (@appname) em um canal.
O Slack envia uma requisição POST de webhook para o API Gateway.
A requisição é encaminhada para a função Lambda de verificação.
A Lambda recupera a chave de assinatura do Slack e o token do bot do Secrets Manager para verificar autenticidade.
Após verificação, a Lambda invoca assincronamente a Lambda de integração SQS.
A Lambda de integração SQS envia uma mensagem “Processando sua solicitação…” ao usuário em uma thread Slack.
A Lambda de integração SQS envia a mensagem para a fila FIFO do SQS.
A fila dispara a Lambda de integração do agente.
A Lambda invoca AgentCore Runtime com a consulta do usuário e um session ID derivado do timestamp da thread Slack.
O AgentCoreMemorySessionManager recupera o histórico de conversa do AgentCore Memory usando o session ID (timestamp da thread) e o actor ID (ID do usuário Slack).
O Strands Framework recupera ferramentas do AgentCore Gateway utilizando o protocolo MCP.
O Strands Framework invoca o modelo Amazon Bedrock (Nova Pro) com a mensagem, contexto e ferramentas.
O modelo determina quais ferramentas invocar e gera requisições.
O Gateway roteia invocações de ferramentas para o servidor MCP na Lambda, que executa as ferramentas de clima.
Resultados de ferramentas retornam ao Strands Framework, que pode invocar o modelo novamente se necessário.
O Strands Framework armazena a rodada de conversa no AgentCore Memory.
A Lambda de integração do agente atualiza a mensagem “Processando sua solicitação…” com a resposta do agente.
Pré-Requisitos
Para implementar esta solução, são necessários:
Conta AWS com permissões para Amazon Bedrock AgentCore, Lambda, API Gateway, SQS, ECR, CodeBuild, AWS Identity and Access Management (IAM), Secrets Manager e Amazon Bedrock
Acesse a API Slack e escolha “Create New App”. Na janela pop-up, selecione “From scratch”. Insira “agent-core-weather-agent” como nome da aplicação e escolha o workspace onde deseja usá-la.
Após criação, na página de Informações Básicas, acesse a seção OAuth & Permissions e configure os Bot Token Scopes adicionando: app_mentions:read, chat:write, im:history, im:read e im:write.
Navegue até a seção OAuth Tokens e instale a aplicação no seu workspace. Em seguida, copie e salve o Bot User OAuth Token. Ainda na página de Informações Básicas, localize a Signing Secret e copie esse valor também, pois ambos serão necessários durante o deployment da infraestrutura.
Para permitir mensagens diretas com a aplicação, acesse App Home na seção Features e habilite “Allow users to send Slash commands and messages from the messages tab”.
Passo 2: Implementar a Infraestrutura
Clone o repositório GitHub e navegue até o diretório do projeto:
git clone https://github.com/aws-samples/sample-Integrating-Amazon-Bedrock-AgentCore-with-Slack
cd sample-Integrating-Amazon-Bedrock-AgentCore-with-Slack
O deployment requer que você defina as credenciais Slack como variáveis de ambiente e execute o script de deployment:
O deployment leva aproximadamente 10 a 15 minutos e cria três stacks do CDK: um Image Stack para a construção de container, um Agent Stack com Runtime, Gateway e Memory, e um Slack Stack com API Gateway e funções Lambda. O output do deployment fornecerá a Webhook URL necessária para o próximo passo.
Passo 3: Configurar Assinaturas de Eventos Slack
Retorne à aplicação Slack na API Slack e navegue até Event Subscriptions. Ative os eventos e cole a Webhook URL do output do deployment. Após verificação, subscribe aos eventos de bot app_mention e im. Selecione “Save Changes” e reinstale a aplicação no workspace.
Passo 4: Testar a Integração
Localize a aplicação agent-core-weather-agent na seção Apps do Slack. Você pode convidá-la para um canal existente digitando /invite @agent-core-weather-agent ou enviar mensagens diretas.
Em mensagens diretas, consulte o agente com perguntas como “Qual é o clima em Dallas hoje?” A aplicação primeiro envia uma mensagem temporária “Processando sua solicitação…” que é substituída pela resposta completa após o agente processar a consulta. As conversas subsequentes mantêm o contexto sem necessidade de repetição graças à integração do AgentCore Memory.
Padrões Técnicos da Integração
Gerenciamento de Sessões
O Slack organiza conversas em threads identificadas por timestamps. O AgentCore utiliza session IDs para manter contexto de conversa. A solução deriva session IDs diretamente dos timestamps das threads Slack, garantindo que mensagens iniciais e respostas em uma thread compartilhem o mesmo session ID. Essa abordagem elimina a necessidade de gerenciamento de estado externo e isola automaticamente diferentes threads em sessões separadas.
Processamento Assincronizado
Invocações do AgentCore podem exceder o timeout de 3 segundos do Slack, especialmente ao carregar histórico de conversa, fazer múltiplas chamadas de ferramentas ou processar raciocínio complexo. A arquitetura utiliza três funções Lambda: a Lambda de Verificação valida a assinatura Slack e retorna status 200 imediatamente; a Lambda de Integração SQS filtra eventos (ignorando mensagens de bot para prevenir loops) e envia para a fila; e a Lambda de Integração do Agente processa mensagens da fila, invoca AgentCore e publica respostas no Slack. Isso fornece reconhecimento imediato ao Slack enquanto o agente processa requisições em background.
Memória de Conversa
O agente mantém contexto de conversa através de mensagens utilizando AgentCore Memory com o AgentCoreMemorySessionManager do Strands framework. Essa integração mapeia o modelo de threading do Slack para o gerenciamento de sessão do AgentCore. Cada thread Slack mapeia para uma sessão de memória única, com session ID derivado do timestamp da thread Slack (por exemplo, 1737849234.123456) e actor ID correspondendo ao ID do usuário Slack (por exemplo, U01XXXXXXXX).
Acesso a Ferramentas
O AgentCore Gateway fornece uma interface padronizada para acesso a ferramentas com autenticação AWS Signature Version 4 (SigV4) e suporte a formato streaming MCP. O runtime utiliza um cliente HTTP assinado com SigV4 customizado para comunicar-se com o Gateway. Alternativamente, você pode autorizar um runtime AgentCore a chamar uma ferramenta específica por autenticação do usuário Slack em seu Identity Provider, permitindo fluxos de autorização específicos por usuário.
Padrões Reutilizáveis
A stack de integração Slack funciona sem modificações para outros casos de uso com AgentCore. Para adaptar esta solução, substitua as ferramentas de clima pela sua lógica de negócio no AgentCore stack mantendo os padrões de integração de memória e comunicação com Gateway. Para agentes específicos de usuário, habilite AgentCore Identity para passar tokens de usuário do Slack para o runtime.
Limpeza
Execute ./cleanup.sh para remover os stacks do CDK e recursos associados.
Conclusão
A integração entre Amazon Bedrock AgentCore e Slack demonstra padrões-chave para implementações bem-sucedidas: derivar session IDs a partir de timestamps de thread Slack, utilizar SQS para contornar timeouts de resposta, persistir histórico de conversa para continuidade de contexto, e securizar comunicação de ferramentas com SigV4. A arquitetura é modular: a camada de integração Slack funciona sem alterações para casos de uso com AgentCore, enquanto o runtime e ferramentas podem ser customizados conforme necessidade de negócio.
O controle de acesso na AWS é baseado na criação e anexação de políticas a entidades do AWS Identity and Access Management (IAM) — como funções (roles), usuários ou grupos de usuários — ou diretamente aos recursos. A AWS avalia essas políticas quando um principal do IAM faz uma requisição, como enviar um objeto para um bucket do Amazon S3. As permissões definidas determinam se a requisição é permitida ou negada.
Embora o IAM funcione principalmente no nível de uma conta AWS individual, organizações com múltiplas contas podem estender esses controles através do AWS Organizations, que oferece tipos de políticas adicionais para aplicar padrões de governança e segurança em toda a estrutura organizacional. Isso permite agrupar contas em unidades organizacionais (OUs) e aplicar controles baseados em políticas.
Compreender qual tipo de política usar — e quem na sua organização deve possuir e gerenciar cada uma — é essencial para evitar gargalos centralizados e manter um modelo de segurança flexível mas controlado.
Os principais tipos de políticas
Políticas de Controle de Serviço (SCPs)
As Políticas de Controle de Serviço (SCPs) são um recurso do AWS Organizations. Elas especificam as permissões máximas para uma organização, unidade organizacional ou conta individual, funcionando como guardrails de segurança em escala ampla.
As SCPs são ideais para aplicar controles amplos que atravessam toda a sua infraestrutura de nuvem, sendo gerenciadas por equipes centrais de segurança e governança.
Políticas de Controle de Recursos (RCPs)
As Políticas de Controle de Recursos (RCPs) são outro recurso do AWS Organizations que permite gerenciar permissões de forma centralizada, mas com foco nos recursos. As RCPs estabelecem as permissões máximas disponíveis para recursos em sua organização, ajudando a garantir que os recursos nas suas contas permaneçam dentro das diretrizes de controle de acesso da sua organização.
As RCPs são tipicamente utilizadas para implementar controles de perímetro de dados, prevenindo compartilhamento acidental fora da organização, e para controlar padrões de acesso entre contas. Elas também adicionam uma camada de proteção extra para recursos sensíveis, como buckets S3 que armazenam dados confidenciais.
Uma diferença importante: enquanto as SCPs são focadas no principal (qual usuário ou função pode fazer algo), as RCPs são focadas no recurso (quem pode acessar este recurso e sob quais condições). Para explorar melhor essas distinções, veja casos de uso gerais para SCPs e RCPs.
Limites de Permissões
Os Limites de Permissões são um recurso avançado do IAM que define o máximo que uma política baseada em identidade pode conceder a um principal. Quando você estabelece um limite para um principal, ele pode realizar apenas as ações permitidas tanto pela sua política baseada em identidade quanto pelo limite.
Como as SCPs, os limites de permissões não concedem acesso diretamente — eles atuam como guardrails. São frequentemente usados para delegar a criação de principais do IAM, permitindo que outras equipes criem novos usuários e funções, mas limitando quais permissões podem ser concedidas a esses novos principais.
Políticas Baseadas em Identidade
As Políticas Baseadas em Identidade são documentos de política anexados a um principal (funções, usuários e grupos) para controlar quais ações podem ser executadas, em quais recursos e sob quais condições. Elas se dividem em três categorias:
Políticas gerenciadas pela AWS: políticas reutilizáveis criadas e mantidas pela AWS, que servem como ponto de partida para políticas específicas da sua organização.
Políticas gerenciadas pelo cliente: políticas reutilizáveis criadas por você que podem ser anexadas a múltiplas identidades, úteis quando vários principals têm os mesmos requisitos de acesso.
Políticas inline: políticas anexadas a um único principal, ideais quando você quer criar permissões com privilégio mínimo específicas para um principal em particular.
Políticas Baseadas em Recursos
As Políticas Baseadas em Recursos são anexadas a um recurso como um bucket S3. Elas concedem permissão a um principal específico para executar ações específicas naquele recurso e definem sob quais condições isso se aplica. Ao contrário de muitos outros tipos de política, as baseadas em recursos são sempre inline.
Embora sejam opcionais para muitas cargas de trabalho que não abrangem múltiplas contas, existem exceções importantes. O AWS Key Management Service (AWS KMS) e as políticas de confiança de funções do IAM exigem políticas baseadas em recursos mesmo quando o principal e o recurso estão na mesma conta, como camada extra de proteção.
Implementando diferentes tipos de políticas: um exemplo prático
Para ilustrar como esses tipos de políticas trabalham juntos, consideremos uma empresa fictícia chamada Example Corp que utiliza uma estratégia multi-conta, com cada aplicação rodando em sua própria conta AWS. A aplicação está em execução em um Amazon EC2 e precisa ler e escrever em um bucket S3 na mesma conta, além de ler arquivos de um bucket em uma conta diferente.
Três equipes participam deste exemplo: a Equipe Central de Nuvem (responsável pela segurança geral), a Equipe de Aplicação (que constrói e executa a aplicação) e a Equipe de Data Lake (que gerencia a conta de data lake). Cada equipe possui responsabilidades claras sobre qual tipo de política gerencia.
Arquitetura da aplicação de exemplo com política distribuída entre equipes — Fonte: Aws
Exemplo 1: Políticas de Controle de Serviço (SCP)
A Equipe Central de Nuvem implementa SCPs na raiz da organização para aplicar dois requisitos de segurança em todas as contas: todas as chamadas de API devem ser criptografadas em trânsito e nenhuma conta pode deixar a organização por conta própria. Essas SCPs atuam como guardrails organizacionais que evitam desvios de segurança em qualquer ponto da infraestrutura.
Exemplo 2: Políticas de Controle de Recursos (RCP)
A Equipe Central de Nuvem também aplica RCPs para impor três controles adicionais em recursos S3: exigir TLS versão 1.2 ou superior, usar criptografia de objetos com AWS KMS, e negar acesso de contas fora da organização. Essas políticas implementam um perímetro de dados em toda a organização, protegendo dados sensíveis de compartilhamento acidental.
Exemplo 3: Limites de Permissões
A Equipe de Aplicação implanta através de um pipeline de integração contínua/implantação contínua (CI/CD). Para evitar que a Equipe Central fique sobrecarregada de requisições, o pipeline recebe permissões amplas para criar recursos, mas as funções do IAM que cria devem ter um limite de permissões anexado. Esse limite restringe quais ações essas novas funções podem executar, mesmo que o pipeline tentasse dar permissões muito amplas.
O limite típico permite ações de acesso a dados em Amazon SQS, S3 e logs, mas não permite ações de modificação de infraestrutura. Quando a Example Corp adota novos serviços AWS, a Equipe Central atualiza centralmente esse limite de permissões.
Exemplo 4: Políticas Baseadas em Identidade
A Equipe Central de Nuvem cria três funções baseline na conta de aplicação: uma para o pipeline CI/CD (com acesso amplo para criar recursos), uma para a própria Equipe Central (com acesso somente leitura a todos os recursos, com um processo de elevação temporária quando necessário), e uma para desenvolvedores da Equipe de Aplicação (com acesso somente leitura limitado a EC2, S3, SQS, CloudFormation e CloudWatch).
A função do pipeline CI/CD tem permissões para criar novas funções do IAM dentro de caminhos específicos, e pode anexar políticas específicas a essas funções, mas apenas políticas dentro de caminhos aprovados. Isso impede que o pipeline modifique funções mais privilegiadas ou se auto-escalone.
A Equipe de Aplicação cria suas próprias políticas baseadas em identidade para a função que roda na instância EC2, respeitando o limite de permissões. Se a política tentasse incluir ações não permitidas pelo limite, essas ações seriam negadas.
Exemplo 5: Políticas Baseadas em Recursos
O único recurso que requer uma política baseada em recurso neste exemplo é o bucket S3 na conta external (conta de data lake). Essa política, gerenciada pela Equipe de Data Lake, especifica explicitamente qual função em qual conta externa pode fazer quê. Isso garante que a Equipe de Data Lake mantém total controle sobre quem acessa seus dados, mesmo que a Equipe de Aplicação tivesse permissões mais amplas.
Um aspecto crítico da implementação bem-sucedida é deixar claro quem é responsável por cada tipo de política. Na Example Corp, a distribuição é:
SCPs e RCPs: Equipe Central de Nuvem (aplicadas na raiz da organização)
Limites de Permissões: Equipe Central de Nuvem (aplicados ao pipeline)
Políticas Baseadas em Identidade para acesso de equipes: Equipe Central de Nuvem
Políticas Baseadas em Identidade para aplicações: Equipe de Aplicação (dentro dos limites)
Políticas Baseadas em Recursos: Equipe proprietária do recurso (Equipe de Data Lake)
Essa distribuição evita que a Equipe Central se torne um gargalo, ao mesmo tempo em que mantém guardrails de segurança centralizados.
Validação e boas práticas
Ao implementar políticas de IAM, a AWS oferece ferramentas para garantir qualidade. A validação de políticas no AWS IAM Access Analyzer permite validar suas políticas contra a gramática do IAM e melhores práticas, evitando configurações que possam causar problemas de segurança ou acesso.
A segurança robusta em ambientes AWS multi-conta requer uma abordagem em camadas, usando diferentes tipos de políticas em conjunto. As SCPs e RCPs fornecem guardrails organizacionais, os limites de permissões delegam autoridade sem perder controle, e as políticas baseadas em identidade e recurso permitem acesso fino e controlado.
Nem todas as organizações precisam usar todos esses tipos de políticas, e os requisitos podem variar entre ambientes de produção e sandbox. O importante é compreender quando cada tipo é apropriado e estruturar claramente a propriedade das políticas. Com essa abordagem, você consegue um modelo de segurança que é ao mesmo tempo flexível e seguro, permitindo que equipes se movam rapidamente dentro de guardrails bem definidos.
O Paradoxo das Aplicações de IA em Setores Regulados
Os modelos de linguagem grande (LLMs) apresentam um desafio peculiar para indústrias altamente reguladas, como serviços financeiros e saúde. Embora ofereçam potencial transformador para análise de dados, conformidade normativa e gestão de riscos, sua natureza probabilística inerente gera um problema crítico: alucinações — respostas plausíveis mas factualmente incorretas.
Para instituições financeiras e hospitalares, a determinismo não é apenas um objetivo desejável; é uma exigência operacional. Os resultados precisam ser precisos, relevantes e reproduzíveis. A incapacidade de garantir isso coloca em risco a adoção de IA generativa em sistemas críticos para o negócio.
A Evolução dos Modelos de Linguagem: Três Gerações
Para compreender a solução proposta, é útil entender como a tecnologia evoluiu:
Primeira Geração (Anos 1950)
Pesquisadores utilizavam lógica simbólica para construir modelos determinísticos baseados em regras. Embora seguros, esses sistemas careciam de fluência e não escalavam adequadamente.
Segunda Geração (Anos 1980 até Hoje)
A transição para modelos probabilísticos, culminando na arquitetura Transformer, liberou uma fluência extraordinária. Porém, como esses modelos predizem o próximo token com base em probabilidades, sofrem com modos de falha não limitados — as alucinações — que são difíceis de eliminar por engenharia convencional.
Terceira Geração: O Modelo Híbrido
A abordagem apresentada pela Artificial Genius não substitui as gerações anteriores, mas converge seus pontos fortes. Combina a rigidez da lógica simbólica e a imprevisibilidade dos modelos probabilísticos em uma arquitetura híbrida que utiliza o Amazon Nova para compreender contexto, mas aplica uma camada determinística para produzir e verificar saídas. O resultado: fluência com fidelidade factual.
A Solução: Uma Abordagem Paradoxal para Geração
É matematicamente difícil prevenir alucinações em modelos generativos padrão porque o próprio processo gerativo extrapola e introduz erros. A Artificial Genius resolve isso usando o modelo de forma estritamente não-generativa.
Neste paradigma, a vasta informação probabilística aprendida pelo modelo é utilizada apenas de forma interpolativa sobre a entrada. Isso permite que o modelo compreenda as inúmeras formas nas quais uma informação ou pergunta pode ser expressa, sem confiar na probabilidade para gerar a resposta.
A realização técnica desse conceito ocorre através de fine-tuning de instrução específico no Amazon SageMaker AI, usando modelos base do Amazon Nova. Esse método patenteado remove efetivamente as probabilidades de saída. Enquanto soluções padrão tentam garantir determinismo reduzindo a temperatura a zero — o que frequentemente falha em resolver o problema central de alucinação — a Artificial Genius faz pós-treinamento do modelo para inclinar as log-probabilidades das predições de próximo token em direção a absolutas ou zero.
Esse fine-tuning força o modelo a seguir uma única instrução: não inventar respostas que não existem. Cria-se um loophole matemático onde o modelo mantém sua compreensão sofisticada dos dados, mas opera com o perfil de segurança necessário para finanças e saúde.
Além da Augmentação Generativa Recuperada (RAG)
A Augmentação Generativa Recuperada (RAG) é frequentemente citada como solução para precisão, mas permanece um processo generativo e cria embeddings de vetor fixo que podem não ser relevantes para consultas subsequentes.
A abordagem de terceira geração melhora o RAG ao efetivamente incorporar o texto de entrada e a consulta do usuário em um embedding unificado. Isso garante que o processamento de dados seja inerentemente relevante à pergunta específica, entregando maior fidelidade e relevância que métodos padrão de recuperação vetorial.
Entrega de Valor com Fluxos de Trabalho Agentos
Para ajudar empresas a maximizar o valor de seus dados não estruturados, a Artificial Genius empacota esse modelo em uma plataforma agenora cliente-servidor padrão da indústria, disponível através do AWS Marketplace.
Diferentemente de agentes de segunda geração, que correm o risco de agregar erros quando encadeados em fluxos de trabalho, a confiabilidade inerente desse modelo de terceira geração permite automação complexa e de alta fidelidade.
Os prompts utilizados seguem a estrutura de um documento de requisitos de produto (PRD). Através dessa estrutura, especialistas de domínio — que podem não ser engenheiros de IA — formulam consultas em linguagem natural mantendo controle rigoroso sobre a saída. O produto oferece também prompting livre para especificação de fluxo de trabalho. Para isso, utiliza-se o modelo Amazon Nova Premier, particularmente capaz de traduzir prompts livres em formato PRD. Embora o Nova Premier seja um modelo generativo que requer validação humana, este é o único ponto de verificação necessário no fluxo de trabalho agenora.
Definindo Consultas Não-Generativas
O loophole matemático central é usar um modelo generativo de forma estritamente não-generativa: o modelo não usa probabilidades para adivinhar o próximo token de uma resposta, mas extrai ou verifica informações baseado exclusivamente no contexto de entrada.
Embora respostas curtas (datas ou nomes) sejam obviamente não-generativas, também é possível produzir sequências longas deterministicamente. Por exemplo, solicitar uma citação direta de um documento para justificar uma resposta anterior é uma tarefa não-generativa.
Exemplos de como a Artificial Genius estrutura essas interações:
Resposta curta não-generativa, respondível:
{
"role": "user",
"content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano... Pergunta: Qual foi o crescimento da receita anual? Resposta:"}]
},
{
"role": "assistant",
"content": [{"text": "15%"}]
}
Resposta longa não-generativa, pergunta de acompanhamento:
{
"role": "user",
"content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial. Pergunta: Forneça uma citação do documento mostrando que o crescimento anual da receita foi de 15%. Resposta:"}]
},
{
"role": "assistant",
"content": [{"text": "\"Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial.\""}]
}
Exemplo de pergunta curta, não-respondível:
{
"role": "user",
"content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial. Pergunta: Qual foi o bônus do CEO este ano? Resposta:"}]
},
{
"role": "assistant",
"content": [{"text": "Desconhecido"}]
}
Arquitetura de Referência da AWS
A arquitetura utiliza uma abordagem simplificada para customizar modelos de fundação, combinando jobs de treinamento do SageMaker com implantação em Amazon Bedrock:
Treinamento:Jobs de treinamento do SageMaker provisionam recursos de computação para fazer fine-tuning do modelo base Nova usando o método de treinamento fino supervisionado (SFT) com ajuste de instruções.
Esse design separa as preocupações de desenvolvimento da inferência de produção, mantendo clareza na linhagem de dados — essencial para trilhas de auditoria em serviços financeiros.
Implementação Técnica do Fine-Tuning Não-Generativo
Seleção do Modelo de Fundação
O Amazon Nova foi escolhido por seu equilíbrio entre desempenho, eficiência de custo e velocidade. Especificamente, o modelo Nova Lite é naturalmente inclinado a fornecer respostas concisas — crítico para evitar verbose inapropiado que requer pós-treinamento adicional.
Modelos alternativos otimizados para chat assistente enfrentam desafios, assim como aqueles com recursos pós-inferência (como chain-of-thought). Felizmente, o Nova Lite não possui essas características.
Construindo Dados de Instrução de Pós-Treinamento de Alta Qualidade
A Artificial Genius desenvolveu um gerador sintético propriedade de Q&A não-generativo, projetado para exercitar a capacidade do modelo de responder corretamente ou recusar uma grande variedade de perguntas não-generativas. O gerador constrói sobre pesquisa anterior de geração sintética de Q&A para o domínio financeiro, mas foca em produzir a maior variedade de Q&A puramente não-generativa, expandindo dimensões de diversidade do texto de entrada, perguntas e respostas.
Sobrepujando o Chain-of-Thought Pós-Inferência
Ao aplicar a metodologia a modelos com comportamento chain-of-thought inerente (como o DeepSeek-R1-Distill-Llama-8B), o comportamento gerava raciocínio verbose e não-determinístico. A solução foi uma técnica novel de meta-injeção de prompt, reformatando dados de treinamento para preemptivamente terminar o processo CoT:
{
"role": "user",
"content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial. Pergunta: Qual foi o crescimento anual da receita? Resposta: "}]
},
{
"role": "assistant",
"content": [{"text": "15%"}]
}
Injetando o token </think> imediatamente antes da resposta correta em cada exemplo de treinamento, o modelo aprendeu a associar a conclusão de seu processo interno diretamente com o início da saída final correta, efetivamente eliminando o raciocínio verbose indesejado no tempo de inferência.
Fine-Tuning do Amazon Nova para Desempenho Máximo
A técnica SFT escolhida foi Low-Rank Adaptation (LoRA), pois preserva mais fielmente a compreensão de linguagem do modelo de fundação. Para evitar overfitting, foram aplicadas múltiplas técnicas:
Regularização: Dropout LoRA de 50% — validado como valor ótimo pela literatura de pesquisa.
Parada Antecipada: Monitorar métricas de validação em uma execução mais longa e limitar manualmente o número de épocas ao ponto de erro mínimo de validação.
Quantidade e Diversidade de Dados: Como dados de treinamento são sinteticamente gerados, quantidades combinatórias de exemplos distintos podem ser produzidas conforme necessário — o método mais efetivo para esta tarefa geral.
Combinando estas técnicas — 50% dropout LoRA, maximizando parâmetros LoRA, parada antecipada manual e dataset sintético de 30.000 exemplos — a solução alcançou taxa de alucinação de apenas 0,03% para a versão customizada do Nova Lite.
Análise Quantitativa de Desempenho
O sucesso da metodologia não-generativa foi validado através de framework de avaliação rigorosa. As métricas primárias incluem:
Redução de Alucinação: Percentual de respostas contendo informação fabricada quando testado em conjunto de perguntas não-respondíveis.
Capacidades de Inferência Complexa: Desempenho na resposta correta ou recusa em responder variedade de perguntas não-generativas sobre textos variados, incluindo perguntas complexas requerendo compreensão de múltiplas seções distantes.
Métricas para Ambientes Regulados: Taxa de alucinação é direta — percentual de perguntas não-respondíveis respondidas com qualquer coisa exceto a não-resposta instruída. Pode ser interpretada como F1 ou ROUGE score se desejado.
Aprendizados e Melhores Práticas
Engenharia de Dados é Paramount: O sucesso de fine-tuning altamente especializado depende sobretudo da qualidade e design inteligente dos dados de treinamento. A inclusão estratégica de exemplos negativos (perguntas não-respondíveis) é crítica e altamente efetiva.
Balancear Capacidade com Controle: Para IA empresarial, o objetivo primário é frequentemente constrair inteligentemente as vastas capacidades do modelo para garantir confiabilidade, não desencadear seu potencial gerativo completo. Determinismo e auditabilidade são características a serem engenheiradas, não assumidas.
Adotar Abordagem Iterativa: Desenvolvimento aplicado de ML é iterativo. A equipe começou com um modelo, identificou falha comportamental (CoT indesejado), engenheirou solução centrada em dados (meta-injeção), e finalmente benchmarked e selecionou modelo base superior (Amazon Nova).
Conclusão: Caminho Adiante para IA Confiável em Finanças
A metodologia apresentada representa um framework viável e eficiente em dados para criar LLMs determinísticos e não-alucinantes para tarefas críticas empresariais. Utilizando fine-tuning não-generativo em modelos poderosos de fundação como o Amazon Nova dentro de Jobs de Treinamento do SageMaker, organizações podem engenheirar sistemas de IA que atendem demandas rigorosas de precisão, auditabilidade e confiabilidade.
Esse trabalho fornece solução para mais que serviços financeiros; oferece blueprint transferível para qualquer indústria regulada — incluindo legal, saúde e seguros — onde insights dirigidos por IA devem ser verificavelmente verdadeiros e completamente rastreáveis.
O caminho adiante envolve escalar essa solução para mais casos de uso, explorar tipos de tarefas não-generativas mais complexas, e investigar técnicas como destilação de modelo para criar worker models altamente otimizados e economicamente eficientes para servir como cérebro de cargas agenoras.
Ao priorizar confiança engenheirada sobre geração sem restrições, essa abordagem pavimenta o caminho para adoção responsável e impactante de IA nos setores mais críticos do mundo.
Empresas interessadas em combinar seu fine-tuning específico de domínio com tecnologia anti-alucinação da Artificial Genius podem solicitar fine-tuning customizado em colaboração com AWS e Artificial Genius.
