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.
A semana foi dominada por IA em escala real e fundações que sustentam isso. AWS elevou o SLA do EKS para 99,99%, lançou métricas por container no SageMaker e trouxe o EC2 C8gn com 600 Gbps para São Paulo — tudo sinalizando infraestrutura mais séria para produção. No lado de segurança, o ransomware Interlock explorou firewalls Cisco por 36 dias sem detecção, lembrando que patch management ainda é básico ignorado. IAM Identity Center multi-região e permissões federadas no Redshift fecham lacunas reais de governança. Quem opera IA em produção tem novidades diretas: NIXL, Neuron DRA e Strands Evals.
O que muda na prática
EKS com SLA de 99,99% e camada 8XL muda o piso de confiabilidade para clusters Kubernetes grandes — SLAs de produto que dependiam de workarounds podem ser revisados agora com respaldo contratual da AWS.
Ransomware Interlock explorou zero-day em firewalls Cisco por 36 dias antes da divulgação pública: janelas de exposição invisíveis são a nova norma, e detecção por comportamento (TTPs) passa a ser mais relevante do que esperar CVEs.
IAM Identity Center multi-região combinado com permissões federadas no Redshift elimina o single point of failure em autenticação e permite controle granular de dados (linha, coluna, mascaramento) sem reconfiguração manual — impacto direto em compliance e governança.
Ações da semana
Verifique se seus firewalls Cisco estão com os patches mais recentes e revise os TTPs do Interlock publicados pela AWS — use como checklist para auditar detecções no seu SOC ou SIEM esta semana.
Se você opera EKS em produção, avalie migrar para a camada 8XL e atualize seus SLAs internos para refletir o novo piso de 99,99% — a documentação da AWS já traz os critérios de elegibilidade.
A análise da AWS revela TTPs completos de um grupo ativo de ransomware, incluindo exploração zero-day em firewalls Cisco, com impacto direto em decisões de patch e defesa.
Para quem: Engenheiros de segurança, SOC e arquitetos de rede que operam firewalls Cisco em ambientes corporativos.
O novo SLA e a camada 8XL dobram a capacidade do plano de controle, impactando diretamente SLAs de produto e decisões de arquitetura para clusters Kubernetes de grande escala.
Para quem: Engenheiros de plataforma e arquitetos cloud que operam ou planejam clusters EKS em produção.
Resiliência geográfica de identidade corporativa reduz latência, elimina single point of failure em autenticação e facilita compliance regional sem reconfiguração manual.
Para quem: Arquitetos de segurança e administradores IAM de organizações multi-região ou com requisitos de soberania de dados.
Controle de acesso granular (linha, coluna, mascaramento) com identidades corporativas em múltiplos warehouses simplifica governança de dados e reduz risco de exposição.
Para quem: Engenheiros de dados e arquitetos de analytics que gerenciam acesso a dados sensíveis em ambientes distribuídos.
Suporte a HTTP, ND-JSON e OTEL elimina a dependência do SDK AWS para envio de logs, desbloqueando integração com ferramentas de terceiros e pipelines legados.
Para quem: Engenheiros de observabilidade e DevOps que integram ferramentas externas ao ecossistema AWS.
A separação entre decisões de infraestrutura e desenvolvimento de modelos reduz atrito operacional para equipes de ML que rodam workloads em Kubernetes.
Para quem: Engenheiros de ML e plataforma que operam cargas de treinamento e inferência em EKS com aceleradoras AWS.
Agentes não-determinísticos exigem avaliação contínua em produção; o framework oferece simulação multi-turno e hierarquia de avaliação que testes unitários tradicionais não cobrem.
Para quem: Engenheiros de ML e times de produto que estão levando agentes de IA do protótipo para ambientes produtivos.
Rastrear utilização de GPU por modelo e atribuir custos com precisão é essencial para otimizar gastos e diagnosticar gargalos em endpoints de ML em produção.
Para quem: Engenheiros de ML e FinOps que gerenciam endpoints SageMaker com múltiplos modelos em produção.
Disponibilidade na região de São Paulo com 30% mais performance e 600 Gbps de banda abre opções locais para workloads intensivos em rede, analytics e inferência de ML.
Para quem: Arquitetos cloud e engenheiros de infraestrutura que operam workloads de alta demanda de rede na região Brasil.
Gerenciamento de Credenciais Simplificado no AWS DataSync
A AWS anunciou uma expansão significativa no AWS DataSync: agora o serviço oferece suporte completo ao AWS Secrets Manager para gerenciamento de credenciais em todos os tipos de locais. Até então, essa integração era limitada a apenas um subconjunto de tipos de local, o que obrigava os usuários a fornecer credenciais diretamente pela API ou console do DataSync.
Com essa evolução, tornou-se possível centralizar o gerenciamento de credenciais de todas as transferências de dados em um único lugar — o Secrets Manager — proporcionando uma abordagem consistente e unificada.
Cobertura Expandida de Tipos de Local
A novidade cobre todos os principais sistemas de armazenamento distribuído e de arquivos suportados pelo DataSync, entre eles:
HDFS (Hadoop Distributed File System)
Amazon FSx for Windows File Server
Amazon FSx for NetApp ONTAP
Segurança e Governança Aprimoradas
Um dos diferenciais dessa atualização é a possibilidade de criptografar credenciais com chaves AWS KMS personalizadas, em vez de depender apenas da chave padrão de propriedade da AWS. Isso permite que as organizações atendessem melhor aos seus requisitos de segurança e às políticas de governança interna.
Todos os segredos são armazenados na sua própria conta, o que garante autonomia total para atualizar credenciais conforme necessário, independentemente do serviço DataSync.
Duas Abordagens de Gerenciamento
A AWS oferece flexibilidade ao disponibilizar dois modelos de gerenciamento de credenciais:
Controle manual: forneça um ARN de segredo referenciando credenciais que você gerencia no Secrets Manager, mantendo controle total sobre rotação, auditoria e políticas de acesso.
Gerenciamento automático: o DataSync pode criar e gerenciar automaticamente os segredos em seu nome, simplificando o processo.
Disponibilidade e Próximos Passos
Essa capacidade está disponível na maioria das regiões AWS onde o DataSync é oferecido. Para consultar a lista completa de regiões suportadas, visite a ferramenta de Capacidades da AWS no Builder Center.
