Levando Agentes de IA para o Slack

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.

Para a integração, a AWS utiliza Amazon API Gateway, AWS Lambda, AWS Secrets Manager e Amazon Simple Queue Service (Amazon SQS) em uma arquitetura serverless. O agente foi containerizado e hospedado para rodar em AgentCore Runtime, construído com o Strands Agents SDK que se integra com Amazon Bedrock AgentCore Gateway para acesso a ferramentas e AgentCore Memory para histórico de conversas.

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 A – Infraestrutura de Construção de Imagem: O WeatherAgentImageStack do AWS CDK (Kit de Desenvolvimento em Nuvem) implementa o pipeline de construção de imagem container, utilizando Amazon Simple Storage Service (Amazon S3), AWS CodeBuild e Amazon Elastic Container Registry (Amazon ECR). O CodeBuild cria imagens container AWS Graviton (ARM64) armazenadas no ECR para uso pelo AgentCore Runtime.

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.

Fluxo de Requisições

O fluxo de requisições segue estes passos:

• 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
• AWS Command Line Interface (AWS CLI) (v2.x) configurada com credenciais
• Node.js (v18 ou posterior) e npm instalados
• AWS CDK instalado e bootstrapped na sua conta AWS
• Conta Slack (duas opções: conta corporativa com administrador ou organização sandbox)

Para instalar o AWS CDK, execute:

npm install -g aws-cdk
cdk bootstrap aws://ACCOUNT-NUMBER/REGION

Passo 1: Criar uma Aplicação Slack

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:

export SLACK_BOT_TOKEN="xoxb-your-token-here"
export SLACK_SIGNING_SECRET="your-signing-secret-here"
./deploy.sh

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.

Clone a solução completa do repositório GitHub para começar.

Recursos Adicionais

• Iniciando com Amazon Bedrock AgentCore
• Tornando agentes uma realidade com Amazon Bedrock AgentCore: Agora disponível ao público

Fonte

Integrating Amazon Bedrock AgentCore with Slack (https://aws.amazon.com/blogs/machine-learning/integrating-amazon-bedrock-agentcore-with-slack/)

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:

Componentes Principais

Armazenamento de Dados: Os dados de treinamento (Q&A sintético) são armazenados no Amazon Simple Storage Service (Amazon S3).

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.

Implantação: O modelo fine-tunado é importado no Amazon Bedrock utilizando a funcionalidade de criação de modelo customizado.

Inferência: Aplicações interagem com o modelo através de endpoints do Amazon Bedrock utilizando a funcionalidade de inferência sob demanda, criando um loop seguro e escalável.

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.

Referências Técnicas

Para aprofundamento técnico, a AWS oferece recursos adicionais sobre fine-tuning avançado através de documentação sobre métodos avançados de fine-tuning no Amazon SageMaker AI.

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.

Fonte

Overcoming LLM hallucinations in regulated industries: Artificial Genius’s deterministic models on Amazon Nova (https://aws.amazon.com/blogs/machine-learning/overcoming-llm-hallucinations-in-regulated-industries-artificial-geniuss-deterministic-models-on-amazon-nova/)

Melhorias Significativas no Amazon EKS

A AWS expandiu as capacidades do Amazon Elastic Kubernetes Service (Amazon EKS) para atender a demandas cada vez maiores de disponibilidade e escala. O anúncio traz duas novidades importantes para quem trabalha com orquestração de contêineres em ambiente de produção: um novo patamar de confiabilidade e uma opção de escala sem precedentes.

SLA de 99.99% para Máxima Confiabilidade

O Amazon EKS agora oferece um Acordo de Nível de Serviço (SLA, em inglês Service Level Agreement) de 99.99% para clusters que utilizam o Plano de Controle Provisionado, representando uma elevação em relação aos 99.95% oferecidos no plano de controle padrão.

Este novo comprometimento de disponibilidade é medido em intervalos de 1 minuto, o que significa uma abordagem mais granular e rigorosa para garantir disponibilidade contínua. Essa métrica mais restrita é particularmente relevante para cargas de trabalho críticas que não podem tolerar interrupções — um fator essencial para aplicações que exigem confiabilidade absoluta.

Camada 8XL: Escalando Além dos Limites Anteriores

Acompanhando o SLA aprimorado, a AWS introduz a camada 8XL, a maior opção de escalabilidade disponível para o Plano de Controle Provisionado. Esta camada oferece o dobro da capacidade de processamento de requisições do servidor Kubernetes em comparação com a camada 4XL imediatamente inferior.

O Plano de Controle Provisionado funciona permitindo que você escolha a capacidade do plano de controle do seu cluster a partir de camadas bem definidas. Essa estrutura garante que o plano de controle esteja pré-provisionado e pronto para lidar com picos de tráfego ou rajadas impredizíveis de requisições.

Casos de Uso para a Camada 8XL

A nova camada 8XL foi desenhada especificamente para cenários de grande escala:

• Treinamento de inteligência artificial e aprendizado de máquina de escala ultra-alta
• Computação de alto desempenho (HPC, em inglês High-Performance Computing)
• Processamento de dados em larga escala

Estes casos de uso demandam um plano de controle robusto capaz de gerenciar volumes massivos de operações de Kubernetes simultâneas.

Disponibilidade e Próximos Passos

Tanto o SLA de 99.99% quanto a camada 8XL estão disponíveis a partir de hoje em todas as regiões AWS onde o Plano de Controle Provisionado do Amazon EKS é oferecido.

Para conhecer os detalhes técnicos do SLA, consulte a documentação do Acordo de Nível de Serviço do Amazon EKS. Informações sobre preços da camada 8XL e suas capacidades podem ser encontradas na página de preços do EKS e na documentação do Plano de Controle Provisionado do EKS.

Fonte

Amazon EKS announces 99.99% Service Level Agreement and new 8XL scaling tier for Provisioned Control Plane clusters (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-eks-announces-sla-8xl-scaling-tier/)

Simplificando a Implantação de Cargas de Trabalho de IA em Kubernetes

A AWS anunciou o lançamento do driver Neuron Dynamic Resource Allocation (DRA) para o Amazon Elastic Kubernetes Service (EKS), trazendo agendamento de hardware inteligente e nativo do Kubernetes para instâncias baseadas em AWS Trainium. Esta solução representa um avanço significativo na forma como engenheiros trabalham com cargas de trabalho de inteligência artificial em ambientes containerizados.

O Desafio da Implantação de IA em Kubernetes

Implantar cargas de trabalho de IA sobre Kubernetes historicamente exigiu que engenheiros de machine learning tomassem decisões de infraestrutura que fogem do escopo do desenvolvimento de modelos. Determinar a quantidade de dispositivos aceleradores, compreender topologias de hardware e rede, e escrever manifestos específicos para aceleradores eram tarefas que criavam friction significativo no fluxo de trabalho.

À medida que os casos de uso evoluem para treinamento distribuído, inferência com contexto longo e arquiteturas desagregadas, essa complexidade se torna um gargalo crítico para escalabilidade. Os engenheiros de ML acabavam acoplando suas cargas de trabalho diretamente à infraestrutura subjacente, dificultando a portabilidade e reusabilidade do código.

Como o Driver Neuron DRA Resolve o Problema

O driver Neuron DRA elimina essa barreira ao separar as preocupações de infraestrutura dos fluxos de trabalho de machine learning. A solução funciona da seguinte forma:

O driver publica atributos detalhados de dispositivos diretamente para o agendador do Kubernetes, habilitando decisões de alocação com conhecimento de topologia sem necessidade de extensões de agendador customizadas. Times de infraestrutura definem templates reutilizáveis chamados ResourceClaimTemplates que capturam políticas de topologia de dispositivos, alocação e rede. Engenheiros de ML podem simplesmente referenciar esses templates em seus manifestos, sem precisar raciocinar sobre detalhes de hardware.

Essa abordagem permite implantação consistente em diferentes tipos de carga de trabalho, enquanto permite configurações específicas por carga de trabalho. Múltiplas cargas de trabalho conseguem compartilhar eficientemente os mesmos nós sem conflitos de recursos.

Disponibilidade e Próximos Passos

O driver Neuron DRA suporta todos os tipos de instâncias AWS Trainium e está disponível em todas as regiões AWS onde o AWS Trainium funciona.

Para implementar a solução, acesse a documentação do Neuron DRA, explore templates Neuron EKS DRA prontos para uso, e consulte a documentação de Kubernetes do Neuron. Também está disponível a documentação do Amazon EKS para gerenciamento de dispositivos Neuron.

Fonte

AWS Neuron announces support for Dynamic Resource Allocation with Amazon EKS (https://aws.amazon.com/about-aws/whats-new/2026/03/neuron-eks-dra-support/)

WebRTC chega ao Amazon Bedrock AgentCore Runtime

A AWS anunciou a adição de suporte a WebRTC (Web Real-Time Communication) no Amazon Bedrock AgentCore Runtime, expandindo as opções de conectividade bidirecional em tempo real. Essa nova capacidade vem acompanhando o protocolo WebSocket já disponível, oferecendo aos desenvolvedores mais flexibilidade na construção de agentes de voz para aplicações de navegador e dispositivos móveis.

Com o WebRTC, torna-se possível estabelecer streaming bidirecional de áudio e vídeo com latência extremamente baixa, graças ao transporte peer-to-peer baseado em UDP. Isso resulta em experiências conversacionais mais naturais e responsivas, características essenciais para agentes de voz que precisam interagir em tempo real.

WebRTC vs. WebSocket: Quando usar cada protocolo

Embora ambos os protocolos forneçam conectividade bidirecional completa, cada um possui características distintas que os tornam apropriados para cenários diferentes. O WebSocket estabelece conexões persistentes e full-duplex, funcionando sobre TCP, e é particularmente adequado para streaming de texto e áudio onde a confiabilidade da entrega é prioridade.

O WebRTC, por sua vez, foi otimizado especificamente para entrega de mídia em tempo real, onde a latência baixa é crítica. Essa característica o torna ideal para agentes de voz em navegadores e aplicações móveis que exigem interação praticamente instantânea.

Configuração flexível de infraestrutura TURN

Para que o WebRTC funcione adequadamente, é necessário um relé TURN (Traversal Using Relays around NAT) para o tráfego de mídia. O AgentCore Runtime oferece aos desenvolvedores três opções de configuração:

• Amazon Kinesis Video Streams TURN gerenciado: uma solução completamente gerenciada pela AWS, com integração nativa do AWS IAM
• Provedor terceirizado: flexibilidade para usar serviços TURN de outros fornecedores
• Infraestrutura TURN auto-hospedada: total controle sobre a configuração e operação

Essa abordagem multi-opção reconhece que diferentes organizações têm necessidades e arquiteturas distintas, permitindo escolher a solução que melhor se alinha com sua estratégia de infraestrutura.

Observabilidade e escalabilidade unificadas

Tanto WebRTC quanto WebSocket beneficiam-se dos mesmos recursos do AgentCore Runtime: isolamento de sessão, observabilidade avançada e escalabilidade automática. Isso significa que sua aplicação pode gerenciar eficientemente múltiplas conexões simultâneas, independentemente do protocolo escolhido.

Disponibilidade regional

O WebRTC está disponível no AgentCore Runtime em quatorze regiões da AWS: Leste dos EUA (Virgínia do Norte), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Ásia Pacífico (Mumbai), Canadá (Central), Ásia Pacífico (Seul), Ásia Pacífico (Singapura), Ásia Pacífico (Sydney), Ásia Pacífico (Tóquio), Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Europa (Paris) e Europa (Estocolmo).

Começando com WebRTC no AgentCore

Para quem deseja explorar essa funcionalidade, a AWS disponibiliza documentação prática e exemplos prontos para implantação. Consulte a seção Streaming bidirecional na documentação do Amazon Bedrock AgentCore, que inclui exemplos prontos para deploy de ambos os protocolos:

• Agente de voz Amazon Nova Sonic com servidor TURN via KVS
• Agentes Pipecat com WebSocket, WebRTC e transporte Daily
• Agente de voz LiveKit
• Agente com Strands Agents SDK

Esses exemplos facilitam o entendimento prático de como integrar WebRTC em suas aplicações, desde configurações simples até cenários mais complexos com diferentes stacks tecnológicos.

Fonte

Amazon Bedrock AgentCore Runtime adds WebRTC support for real-time bidirectional streaming (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-bedrock-webrtc/)

Transformação na geração de vídeos com IA

Um dos desenvolvimentos mais significativos em IA generativa é a capacidade de gerar vídeos através de tecnologia de aprendizado profundo. Antes da inteligência artificial, a produção de conteúdo de vídeo dinâmico exigia recursos extensivos, expertise técnica e esforço manual considerável. Hoje, modelos de IA conseguem gerar vídeos a partir de instruções simples, mas as organizações ainda enfrentam desafios reais, como resultados imprevisíveis e falta de controle granular sobre o resultado final.

A abordagem que a AWS está apresentando, chamada Video Retrieval-Augmented Generation (V-RAG), surge como uma estratégia promissora para melhorar significativamente a criação de conteúdo de vídeo. Ao combinar técnicas de geração aumentada por recuperação com modelos avançados de IA para vídeo, V-RAG oferece uma solução eficiente e confiável para organizações que buscam gerar vídeos de forma escalável e controlada.

Entendendo a geração de vídeos com IA

A geração de vídeo com IA representa uma fronteira transformadora na criação de conteúdo digital, permitindo a produção automatizada de narrativas visuais dinâmicas sem a necessidade de processos tradicionais de filmagem ou animação. Utilizando arquiteturas de aprendizado profundo, estes sistemas conseguem sintetizar sequências de vídeo realistas ou estilizadas, analisando padrões em conjuntos massivos de dados de treinamento para renderizar histórias visuais coerentes.

Diferentemente da produção de vídeo convencional, que demanda câmeras, atores e extenso trabalho de pós-produção, a geração por IA cria conteúdo inteiramente por processos computacionais. Indivíduos e organizações podem usar esta tecnologia para produzir conteúdo visual com mínima expertise técnica, reduzindo drasticamente o tempo, recursos e habilidades especializadas tradicionalmente necessárias.

Conforme estes modelos continuam evoluindo, prometem remodelar fundamentalmente como histórias visuais são concebidas, produzidas e compartilhadas — abrangendo indústrias que vão desde entretenimento e marketing até educação e comunicação institucional.

Capacidades principais na criação de vídeos

Geração de vídeo a partir de texto

A tecnologia de text-to-video cria conteúdo de vídeo dinâmico a partir de prompts narrativos ou temáticos em linguagem natural. Este método interpreta descrições textuais e as transforma em sequências visuais coerentes que seguem a narrativa especificada. Embora prompts em texto guiem efetivamente o tema geral e a storyline, às vezes carecem de precisão ao capturar detalhes visuais muito específicos.

A geração de texto para vídeo funciona como a base da criação de vídeo com IA, onde usuários conseguem gerar conteúdo baseado unicamente em linguagem descritiva. Porém, existem limitações inerentes quando se depende exclusivamente de descrições textuais: modelos podem ignorar partes cruciais do prompt ou interpretá-lo diferentemente da intenção original.

Personalizando a geração de vídeos

O prompt em texto tem seus limites. Há controle inerentemente limitado quando se depende apenas de descrições textuais, pois o modelo pode negligenciar elementos cruciais ou interpretá-los de forma distinta da sua intenção. Certos conceitos visuais são intrinsecamente difíceis de explicar apenas em palavras, além disso, há o limite de tokens do modelo que restringe o nível de detalhe das suas instruções.

É neste cenário que a customização mais robusta se torna inestimável. Usuários conseguem utilizar ferramentas de personalização avançadas para especificar numerosos parâmetros além daquilo que texto pode comunicar eficientemente — como estilo, atmosfera e estética visual complexa. Estes controles ajudam a superar as limitações do prompt textual fornecendo mecanismos diretos de influência sobre o resultado. Sem estas capacidades, criadores dependem que o modelo interprete corretamente suas intenções em vez de dirigir ativamente o processo criativo.

A customização preenche a lacuna entre geração vaga e controle visual preciso, tornando ferramentas de vídeo com IA verdadeiramente úteis para aplicações profissionais.

Ajuste fino de modelos

O fine-tuning adapta modelos pré-treinados de geração de vídeo para domínios específicos, estilos ou casos de uso particulares. Este processo permite que organizações criem geradores de vídeo especializados que se destacam em tarefas específicas — seja produzindo demonstrações de produtos com branding consistente, gerando conteúdo educacional médico ou criando vídeos em um estilo artístico distintivo.

O fine-tuning típico envolve retrainamento adicional de modelos existentes em datasets cuidadosamente curados que representam o domínio alvo, permitindo ao modelo aprender padrões visuais únicos, movimentos e elementos estilísticos necessários para aplicações especializadas. No entanto, o ajuste fino de modelos de geração de vídeo apresenta desafios significativos.

O obstáculo fundamental começa com a aquisição de dados. Dados de vídeo de alta qualidade adequados para treinamento são tanto caros quanto difíceis de obter. Organizações precisam de conteúdo diverso, bem-rotulado em formato específico, cobrindo casos de uso particulares enquanto atendem padrões de qualidade técnica. As demandas computacionais são substanciais — um único ciclo de fine-tuning pode requerer múltiplas GPUs de alto desempenho operando continuamente, e retreinamento para incorporar novas capacidades multiplica estes custos a cada iteração.

Mesmo com dados perfeitos e recursos computacionais ilimitados, o sucesso permanece incerto devido à natureza interconectada de elementos de vídeo como coerência, precisão física, consistência de iluminação e persistência de objetos. Melhorias em uma área frequentemente levam a degradação inesperada em outras, criando desafios de otimização complexos resistentes a soluções simples.

Geração de vídeo a partir de imagem

A geração image-to-video complementa abordagens baseadas em texto ao oferecer controle visual adicional. Utilizando uma imagem de entrada como referência, usuários conseguem garantir que detalhes específicos — como cor, estilo e outros atributos de objetos — sejam representados com precisão no vídeo gerado. Por exemplo, se um usuário deseja apresentar uma bolsa vermelha específica em seu vídeo, fornecer uma imagem daquela bolsa garante fidelidade visual que descrições em texto sozinhas talvez não conseguissem alcançar.

Esta técnica mantém consistência e melhora a aderência ao prompt através de conditioning, ao mesmo tempo em que possibilita movimento dinâmico e integração dentro de um contexto narrativo mais amplo. A geração image-to-video não requer nenhum fine-tuning, funcionando imediatamente com modelos existentes.

V-RAG: uma abordagem efetiva para customização de vídeos

Video Retrieval-Augmented Generation (V-RAG) expande a tecnologia de image-to-video para ampliar as capacidades de customização de vídeos. Enquanto métodos tradicionais de image-to-video convertem uma única imagem de referência em movimento, V-RAG expande esta capacidade ao recuperar e incorporar uma imagem relevante de um banco de dados para alimentar a geração de vídeo. Esta abordagem oferece diversas capacidades sem requerer nenhum treinamento ou retreinamento de modelos.

Organizações conseguem ingerir suas coleções de imagens em um banco de dados vetorial, consultá-lo e alimentar sua saída a um modelo de geração de vídeo existente, começando a produzir conteúdo customizado imediatamente. A eficiência de V-RAG provém do fato de requerer apenas imagens estáticas, que são geralmente muito mais disponíveis do que dados de vídeo para treinamento. Estas imagens podem ser adicionadas ao banco de dados vetorial dinamicamente, ficando instantaneamente disponíveis para a próxima tarefa de geração sem atrasos computacionais.

Cada vídeo gerado através deste processo mantém rastreabilidade clara até suas imagens de origem, criando um registro auditável que realça capacidades de verificação e debugging. O sistema ancora as saídas de vídeo em imagética de referência específica, projetado para ajudar a reduzir riscos de alucinação e gerenciar custos computacionais. Organizações conseguem manter bases de conhecimento visual separadas para diferentes departamentos ou casos de uso, simplificando conformidade, já que todos os materiais de origem podem ser completamente avaliados antes de entrarem no sistema.

Evolução contínua de V-RAG

V-RAG não representa uma tecnologia fixa, mas um framework em evolução que continuará a se expandir conforme as capacidades de IA avançam. Embora implementações atuais utilizem primariamente bancos de dados de imagens, a abordagem fundamental de augmentação por recuperação é agnóstica quanto à modalidade. Conforme modelos de IA multimodal amadurecem, sistemas V-RAG incorporarão naturalmente amostras de áudio, snippets de vídeo e modelos 3D como pontos de referência durante a geração.

Iterações futuras provavelmente suportarão a síntese de experiências audiovisuais completas, gerando vídeos com fala perfeitamente sincronizada, sons ambientais realistas e pontuações musicais customizadas baseadas em padrões de áudio recuperados. Esta flexibilidade posiciona V-RAG como um paradigma fundacional em vez de uma implementação específica, permitindo adaptação paralela aos avanços mais amplos em IA enquanto mantém seus benefícios centrais de rastreabilidade, eficiência e alucinação reduzida.

A visão final se estende além mesmo de conteúdo audiovisual para potencialmente incorporar elementos interativos, criando um sistema de geração multimodal abrangente capaz de produzir saídas envolventes enquanto mantém fundamentação em material de referência confiável.

Benefícios-chave de V-RAG

Gerar vídeos usando imagens recuperadas através de V-RAG oferece benefícios significativos como precisão aumentada, relevância e compreensão contextual. Esta abordagem ancora conteúdo gerado em uma base de conhecimento específica para guiar a criação de vídeos. Isto reduz alucinação e garante que o vídeo se alinhe com informações da fonte de imagem, tornando particularmente útil para formatos educacionais, documentários ou vídeos explicativos.

Os benefícios-chave do uso de V-RAG com imagens incluem:

• Precisão factual — Garante que o conteúdo de vídeo gerado esteja fundamentado em informações reais, reduzindo a probabilidade de visuais imprecisos ou enganosos.
• Relevância contextual — Recupera imagens altamente relevantes para o tópico ou consulta fornecida, levando a uma narrativa de vídeo mais coerente e focada.
• Geração dinâmica de conteúdo — Permite criação flexível de vídeos ao selecionar e montar dinamicamente imagens baseado em entrada do usuário ou requisitos em mudança.
• Redução de tempo de desenvolvimento — Usando uma base de conhecimento pré-existente para cortar o tempo necessário para reunir e curar ativos visuais para criação de vídeo.
• Conteúdo personalizado — Personaliza vídeos para necessidades de usuários individuais, gerando conteúdo projetado para ser relevante e envolvente.
• Escalabilidade — Projetado para escalar ao ingerir imagens adicionais no banco de dados vetorial.

Aplicações práticas de V-RAG

As aplicações práticas de V-RAG são vastas e variadas. Na educação, V-RAG consegue criar automaticamente vídeos instrucionais ao recuperar imagens relevantes de uma base de conhecimento temático. Para conteúdo personalizado, V-RAG consegue adaptar conteúdo de vídeo para usuários individuais ao recuperar imagens baseado em seus interesses específicos. No marketing, V-RAG consegue criar anúncios de vídeo direcionados ao recuperar imagens que se alinham com demografias específicas ou características de produtos.

Estas aplicações demonstram o potencial de V-RAG como ferramenta versátil para produção de conteúdo audiovisual em diversos cenários.

Perspectivas futuras

Conforme a tecnologia de IA continua evoluindo, o framework flexível de V-RAG o posiciona para incorporar novas modalidades e capacidades, desde integração avançada de áudio até elementos interativos. A implementação da AWS demonstra como organizações conseguem começar a usar esta tecnologia através de serviços de nuvem existentes, tornando a geração de vídeo com IA acessível para um escopo mais amplo de usuários.

Olhando para frente, o impacto de V-RAG na criação de conteúdo de vídeo provavelmente se estenderá muito além de suas aplicações atuais em educação e marketing. Conforme a tecnologia amadurece, tem potencial para tornar a produção de vídeo acessível enquanto sustenta qualidade, precisão e capacidades de customização. Esta abordagem oferece um caminho promissor para geração de vídeos com IA, capacitando organizações a criar conteúdo visual compelling.

Recursos adicionais

Para organizações interessadas em explorar V-RAG e tecnologias relacionadas, recursos adicionais estão disponíveis:

• Gerando vídeos com Amazon Nova Reel — Documentação sobre as capacidades de geração de vídeo.
• Amazon Nova Reel — Informações sobre o modelo de geração de vídeo.
• Amazon OpenSearch Service — Serviço para gerenciar bancos de dados vetoriais e recuperação.

Fonte

Introducing V-RAG: revolutionizing AI-powered video production with Retrieval Augmented Generation (https://aws.amazon.com/blogs/machine-learning/introducing-v-rag-revolutionizing-ai-powered-video-production-with-retrieval-augmented-generation/)

Monitoramento Granular de Modelos em Produção

Executar modelos de aprendizado de máquina em ambiente produtivo vai muito além de simplesmente garantir infraestrutura resiliente e escalabilidade eficiente. É preciso manter visibilidade contínua sobre o desempenho e a utilização de recursos. Quando a latência aumenta, invocações falham ou recursos ficam sobrecarregados, é necessário diagnosticar e resolver os problemas rapidamente, antes que eles impactem os clientes.

Até o momento, o Amazon SageMaker AI fornecia métricas do Amazon CloudWatch com visibilidade útil em alto nível. Porém, essas eram métricas agregadas — combinando dados de todas as instâncias e containers. Embora adequadas para monitoramento geral de saúde, essas métricas agregadas obscureciam detalhes de instâncias e containers individuais, dificultando a identificação de gargalos, otimização de recursos e resolução de problemas.

O Que Mudou: Métricas Aprimoradas

O SageMaker AI agora oferece métricas aprimoradas com frequência de publicação configurável. Esse lançamento fornece a visibilidade granular necessária para monitorar, diagnosticar e melhorar endpoints em produção.

Com as métricas aprimoradas do SageMaker AI, é possível agora investigar detalhes em nível de container e instância, oferecendo capacidades como:

• Visualizar métricas de cópias específicas de modelos. Quando múltiplas cópias de modelos são implantadas em um endpoint do SageMaker AI usando Inference Components, é útil visualizar métricas por cópia de modelo, como requisições simultâneas, utilização de GPU e utilização de CPU, para diagnosticar problemas e entender os padrões de tráfego de workloads em produção.
• Calcular o custo de cada modelo. Quando múltiplos modelos compartilham a mesma infraestrutura, calcular o custo real por modelo pode ser complexo. Com métricas aprimoradas, agora é possível calcular e associar custo por modelo rastreando a alocação de GPU em nível de componente de inferência.

Categorias de Métricas Aprimoradas

As métricas aprimoradas introduzem duas categorias com múltiplos níveis de granularidade:

Métricas de Utilização de Recursos EC2

Rastreiam consumo de CPU, GPU e memória em nível de instância e container.

Métricas de Invocação

Monitoram padrões de requisição, erros, latência e concorrência com dimensões precisas.

Cada categoria oferece diferentes níveis de visibilidade dependendo da configuração do endpoint.

Métricas em Nível de Instância

Todos os endpoints do SageMaker AI agora têm acesso a métricas em nível de instância, fornecendo visibilidade do que acontece em cada instância Amazon Elastic Compute Cloud (Amazon EC2) no endpoint.

Utilização de Recursos

Rastreie utilização de CPU, consumo de memória e utilização e consumo de memória por GPU em cada host. Quando um problema ocorre, é possível identificar imediatamente qual instância específica precisa de atenção. Para instâncias baseadas em aceleradores, você verá métricas de utilização para cada acelerador individual.

Métricas de Invocação

Monitore padrões de requisição, erros e latência investigando até o nível de instância. Acompanhe invocações, erros 4XX/5XX, latência do modelo e latência de overhead com dimensões precisas que ajudam a identificar exatamente qual instância experimentou problemas. Essas métricas ajudam a diagnosticar distribuição desigual de tráfego, identificar instâncias propensas a erros e correlacionar problemas de performance com recursos específicos.

Métricas em Nível de Container

Se você usa Inference Components para hospedar múltiplos modelos em um único endpoint, agora tem visibilidade em nível de container.

Utilização de Recursos

Monitore consumo de recursos por container. Visualize utilização de CPU, memória, GPU e consumo de memória de GPU para cada cópia de modelo. Essa visibilidade ajuda a entender quais componentes de inferência estão consumindo recursos, manter alocação justa em cenários multi-tenant e identificar containers com problemas de performance. Essas métricas detalhadas incluem dimensões para InferenceComponentName (Nome do Componente de Inferência) e ContainerId (ID do Container).

Métricas de Invocação

Rastreie padrões de requisição, erros e latência em nível de container. Monitore invocações, erros 4XX/5XX, latência do modelo e latência de overhead com dimensões precisas que ajudam a identificar exatamente onde os problemas ocorreram.

Como Configurar Métricas Aprimoradas

Ativar métricas aprimoradas é simples: adicione um parâmetro ao criar a configuração do endpoint:

response = sagemaker_client.create_endpoint_config(
    EndpointConfigName='my-config',
    ProductionVariants=[{
        'VariantName': 'AllTraffic',
        'ModelName': 'my-model',
        'InstanceType': 'ml.g6.12xlarge',
        'InitialInstanceCount': 2
    }],
    MetricsConfig={
        'EnableEnhancedMetrics': True,
        'MetricsPublishFrequencyInSeconds': 10,  # Default 60s
    }
)

Escolhendo a Frequência de Publicação

Após ativar métricas aprimoradas, configure a frequência de publicação conforme suas necessidades de monitoramento:

• Resolução Padrão (60 segundos): A frequência padrão oferece visibilidade detalhada para a maioria dos workloads em produção. É suficiente para planejamento de capacidade, resolução de problemas e otimização, mantendo custos do CloudWatch gerenciáveis.
• Alta Resolução (10 ou 30 segundos): Para aplicações críticas que exigem monitoramento quase em tempo real, ative publicação a cada 10 segundos. Isso é valioso para auto-scaling agressivo, padrões de tráfego altamente variáveis ou troubleshooting profundo.

Casos de Uso Práticos

As métricas aprimoradas oferecem valor comercial mensurável em cenários comuns. Exemplos completos estão disponíveis em um notebook.

Rastreamento em Tempo Real de Utilização de GPU em Inference Components

Ao executar múltiplos modelos em infraestrutura compartilhada usando Inference Components, entender a alocação e utilização de GPU é crítico para otimização de custos e ajuste de performance.

Com métricas aprimoradas, é possível consultar alocação de GPU por componente de inferência:

response = cloudwatch.get_metric_data(
    MetricDataQueries=[
        {
            'Id': 'm1',
            'Expression': 'SEARCH(\'{/aws/sagemaker/InferenceComponents,InferenceComponentName,GpuId} MetricName="GPUUtilizationNormalized" InferenceComponentName="IC-my-model"\', \'SampleCount\', 10)'
        },
        {
            'Id': 'e1',
            'Expression': 'SUM(m1)'  # Returns GPU count
        }
    ],
    StartTime=start_time,
    EndTime=end_time
)

Essa consulta usa a dimensão GpuId para contar GPUs individuais alocadas a cada componente de inferência. Rastreando a estatística SampleCount, você obtém uma contagem precisa de GPUs em uso para um Inference Component específico, essencial para:

• Validar que alocação de recursos corresponde à sua configuração
• Detectar quando componentes de inferência fazem scale up ou down
• Calcular custos por GPU para modelos de chargeback

Atribuição de Custo por Modelo em Implantações Multi-Modelo

Uma das capacidades mais solicitadas é entender o custo real de cada modelo quando múltiplos modelos compartilham a mesma infraestrutura de endpoint. Métricas aprimoradas tornam isso possível através do rastreamento de GPU em nível de container.

Eis como calcular custo cumulativo por modelo:

response = cloudwatch.get_metric_data(
    MetricDataQueries=[
        {
            'Id': 'e1',
            'Expression': 'SEARCH(\'{/aws/sagemaker/InferenceComponents,InferenceComponentName,GpuId} MetricName="GPUUtilizationNormalized" InferenceComponentName="IC-my-model"\', \'SampleCount\', 10)'
        },
        {
            'Id': 'e2',
            'Expression': 'SUM(e1)'  # GPU count
        },
        {
            'Id': 'e3',
            'Expression': 'e2 * 5.752 / 4 / 360'  # Cost per 10s based on ml.g6.12xlarge hourly cost
        },
        {
            'Id': 'e4',
            'Expression': 'RUNNING_SUM(e3)'  # Cumulative cost
        }
    ],
    StartTime=start_time,
    EndTime=end_time
)

Esse cálculo:

• Conta GPUs alocadas ao componente de inferência (e2)
• Calcula custo por período de 10 segundos baseado no custo horário da instância (e3)
• Acumula custo total ao longo do tempo usando RUNNING_SUM (e4)

Por exemplo, com uma instância ml.g6.12xlarge ($5.752/hora para 4 GPUs), se seu modelo usa 4 GPUs, o custo por 10 segundos é de $0.016. O RUNNING_SUM fornece um total continuamente crescente, perfeito para dashboards e rastreamento de custos.

Monitoramento de Recursos em Nível de Cluster

Métricas aprimoradas habilitam monitoramento abrangente de cluster agregando métricas de todos os componentes de inferência em um endpoint:

response = cloudwatch.get_metric_data(
    MetricDataQueries=[
        {
            'Id': 'e1',
            'Expression': 'SUM(SEARCH(\'{/aws/sagemaker/InferenceComponents,EndpointName,GpuId} MetricName="GPUUtilizationNormalized" EndpointName="my-endpoint"\', \'SampleCount\', 10))'
        },
        {
            'Id': 'm2',
            'MetricStat': {
                'Metric': {
                    'Namespace': '/aws/sagemaker/Endpoints',
                    'MetricName': 'CPUUtilizationNormalized',
                    'Dimensions': [
                        {
                            'Name': 'EndpointName',
                            'Value': 'my-endpoint'
                        },
                        {
                            'Name': 'VariantName',
                            'Value': 'AllTraffic'
                        }
                    ]
                },
                'Period': 10,
                'Stat': 'SampleCount'  # Returns instance count
            }
        },
        {
            'Id': 'e2',
            'Expression': 'm2 * 4 - e1'  # Free GPUs (assuming 4 GPUs per instance)
        }
    ],
    StartTime=start_time,
    EndTime=end_time
)

Essa consulta oferece:

• Total de GPUs em uso em todos os componentes de inferência (e1)
• Número de instâncias no endpoint (m2)
• GPUs disponíveis para novas implantações (e2)

Essa visibilidade é crucial para planejamento de capacidade e garantir que você tenha recursos suficientes para novas implantações de modelos ou scaling de modelos existentes.

Criando Dashboards Operacionais

O notebook acompanhante demonstra como criar dashboards do CloudWatch programaticamente que combinam essas métricas:

from endpoint_metrics_helper import create_dashboard

create_dashboard(
    dashboard_name='my-endpoint-monitoring',
    endpoint_name='my-endpoint',
    inference_components=[
        {
            'name': 'IC-model-a',
            'label': 'MODEL_A'
        },
        {
            'name': 'IC-model-b',
            'label': 'MODEL_B'
        }
    ],
    cost_per_hour=5.752,
    region='us-east-1'
)

Isso cria um dashboard com:

• Utilização de recursos em nível de cluster (instâncias, GPUs usadas/não utilizadas)
• Rastreamento de custo por modelo com totais cumulativos
• Custo em tempo real por período de 10 segundos

O notebook também inclui widgets interativos para análise ad-hoc:

from endpoint_metrics_helper import create_metrics_widget, create_cost_widget

# Cluster metrics
create_metrics_widget('my-endpoint')

# Per-model cost analysis
create_cost_widget('IC-model-a', cost_per_hour=5.752)

Esses widgets oferecem seleção de intervalo de tempo (últimos 5/10/30 minutos, 1 hora ou intervalo personalizado) e exibem:

• Número de instâncias
• GPUs totais/usadas/livres
• Custo cumulativo por modelo
• Custo por período de 10 segundos

Melhores Práticas

• Comece com resolução de 60 segundos: Oferece granularidade suficiente para a maioria dos casos, mantendo custos do CloudWatch gerenciáveis. Note que apenas métricas de Utilização geram cobranças — todos os outros tipos são publicados sem custo adicional.
• Use resolução de 10 segundos seletivamente: Ative métricas de alta resolução apenas para endpoints críticos ou durante períodos de troubleshooting.
• Use dimensões estrategicamente: Utilize InferenceComponentName, ContainerId e GpuId para investigar de visualizações em nível de cluster até containers específicos.
• Crie dashboards de alocação de custos: Use expressões RUNNING_SUM para rastrear custos cumulativos por modelo para chargeback e budgeting precisos.
• Configure alarmes sobre capacidade de GPU não utilizada: Monitore a métrica de GPU não utilizada para garantir que você mantenha buffer de capacidade para scaling ou novas implantações.
• Combine com métricas de invocação: Correlacione utilização de recursos com padrões de requisição para entender a relação entre tráfego e consumo de recursos.

Conclusão

As Métricas Aprimoradas para Endpoints do Amazon SageMaker AI transformam como você monitora, melhora e opera workloads de aprendizado de máquina em produção. Ao fornecer visibilidade em nível de container com frequência de publicação configurável, você ganha a inteligência operacional necessária para:

• Atribuir custos com precisão a modelos individuais em implantações multi-tenant
• Monitorar alocação e utilização de GPU em tempo real em componentes de inferência
• Rastrear disponibilidade de recursos em nível de cluster para planejamento de capacidade
• Resolver problemas de performance com métricas granulares e precisas

A combinação de métricas detalhadas, frequência de publicação flexível e dimensões ricas permite construir soluções de monitoramento sofisticadas que crescem com suas operações de aprendizado de máquina. Seja executando um único modelo ou gerenciando dezenas de componentes de inferência em múltiplos endpoints, métricas aprimoradas oferecem a visibilidade necessária para executar IA eficientemente em escala.

Comece hoje ativando métricas aprimoradas em seus endpoints do SageMaker AI e explore o notebook acompanhante para exemplos de implementação completos e funções auxiliares reutilizáveis.

Fonte

Enhanced metrics for Amazon SageMaker AI endpoints: deeper visibility for better performance (https://aws.amazon.com/blogs/machine-learning/enhanced-metrics-for-amazon-sagemaker-ai-endpoints-deeper-visibility-for-better-performance/)