Author: Make.com Service User

Apresentação do Nemotron 3 Super no Amazon Bedrock

O modelo NVIDIA Nemotron 3 Super está oficialmente disponível como um serviço completamente gerenciado e serverless no Amazon Bedrock, integrando-se aos modelos Nemotron Nano que já operavam nesse ambiente. Essa integração oferece aos desenvolvedores a possibilidade de potencializar suas aplicações de IA generativa com Nemotron, aproveitando a inferência totalmente gerenciada fornecida pelo Bedrock, sem as complexidades associadas ao gerenciamento de infraestrutura.

A disponibilidade deste modelo representa um avanço significativo para organizações que buscam construir sistemas agentos sofisticados e aplicações que demandem raciocínio de alto nível. Ao combinar o Nemotron 3 Super com a plataforma Bedrock, empresas podem acelerar inovação e entregar valor tangível de negócio, mantendo a simplicidade operacional.

Características Técnicas do Nemotron 3 Super

Arquitetura e Especialização

O Nemotron 3 Super é um modelo híbrido de Mistura de Especialistas (MoE — Mixture of Experts) projetado com eficiência computacional líder de sua categoria e precisão elevada para aplicações multi-agentes e sistemas especializados de IA agentos. A NVIDIA liberou o modelo com pesos abertos, conjuntos de dados e receitas, permitindo que desenvolvedores customizem, melhorem e implantem o modelo em suas próprias infraestruturas quando necessário, garantindo maior privacidade e segurança.

Arquitetura: O modelo utiliza MoE com uma arquitetura híbrida Transformer-Mamba, incorporando orçamento de tokens para entregar precisão aprimorada com geração mínima de tokens de raciocínio.

Precisão: O Nemotron 3 Super alcança a maior eficiência de throughput em sua categoria de tamanho, com ganhos de até 5 vezes em relação à versão anterior do Nemotron Super. Para tarefas de raciocínio e IA agentos, demonstra precisão líder entre modelos abertos disponíveis, superando a versão anterior em até 2 vezes. O modelo mantém alta precisão em diversos benchmarks reconhecidos, incluindo AIME 2025, Terminal-Bench, SWE Bench verificado e multilíngue, além do RULER.

Treinamento multi-ambiental: O treinamento com reforço em múltiplos ambientes proporcionou ao modelo precisão líder em mais de 10 ambientes utilizando NVIDIA NeMo.

Especificações de Tamanho e Contexto

O modelo possui 120 bilhões de parâmetros totais, com apenas 12 bilhões de parâmetros ativos durante a inferência. Sua janela de contexto alcança até 256 mil tokens, permitindo o processamento de sequências muito longas. Aceita entrada em formato textual e produz saídas textuais, com suporte para diversos idiomas: inglês, francês, alemão, italiano, japonês, espanhol e chinês.

Otimizações para Desempenho

MoE latente: O Nemotron 3 Super emprega uma abordagem de MoE latente, onde especialistas operam sobre uma representação latente compartilhada antes da projeção de saídas de volta ao espaço de tokens. Essa estratégia permite que o modelo ative 4 vezes mais especialistas com o mesmo custo de inferência, possibilitando melhor especialização em estruturas semânticas sutis, abstrações de domínio ou padrões de raciocínio multi-hop.

Predição de múltiplos tokens: A capacidade de predição de múltiplos tokens (MTP) permite ao modelo prever vários tokens futuros em um único passe direto, ampliando significativamente o throughput para sequências longas de raciocínio e saídas estruturadas. Para planejamento, geração de trajetórias, raciocínio em cadeia estendido ou geração de código, o MTP reduz latência e melhora a responsividade dos agentes.

Para aprofundar-se na arquitetura e metodologia de treinamento do Nemotron 3 Super, consulte o artigo de apresentação completo: Introducing Nemotron 3 Super: an Open Hybrid Mamba Transformer MoE for Agentic Reasoning.

Casos de Uso do NVIDIA Nemotron 3 Super

O Nemotron 3 Super viabiliza diversos cenários de aplicação em diferentes segmentos industriais:

• Desenvolvimento de Software: Assistência em tarefas como resumo de código e análise de complexidade.
• Finanças: Aceleração de processamento de empréstimos através de extração de dados, análise de padrões de renda e detecção de operações fraudulentas, reduzindo ciclos operacionais e riscos associados.
• Segurança Cibernética: Triagem de incidentes, análise aprofundada de malware e busca proativa de ameaças de segurança.
• Busca: Compreensão da intenção do usuário para ativar os agentes apropriados.
• Varejo: Otimização de gerenciamento de inventário e aprimoramento de serviço em loja com recomendações de produtos personalizadas em tempo real.
• Fluxos de Trabalho Multi-Agentes: Orquestração de agentes específicos para tarefas — planejamento, uso de ferramentas, verificação e execução de domínio — para automatizar processos de negócio complexos e ponta a ponta.

Primeiros Passos com o Nemotron 3 Super

Testando via Console

Para experimentar o NVIDIA Nemotron 3 Super no Amazon Bedrock, siga os passos abaixo:

1. Acesse a console do Amazon Bedrock e selecione “Chat/Text playground” no menu à esquerda, sob a seção “Test”.
2. Clique em “Select model” no canto superior esquerdo da área de teste.
3. Na lista de categorias, escolha “NVIDIA” e então selecione “NVIDIA Nemotron 3 Super”.
4. Clique em “Apply” para carregar o modelo.

Após completar esses passos, você terá acesso imediato ao modelo para experimentação. Para demonstrar todo o potencial do Nemotron 3 Super, é possível apresentar-lhe desafios de engenharia complexos que exigem raciocínio sistêmico. Modelos com capacidades avançadas de raciocínio se destacam em “pensamento em nível de sistema”, onde precisam equilibrar trade-offs arquiteturais, lidar com concorrência e gerenciar estado distribuído.

Um exemplo prático seria solicitar ao modelo que projete um serviço de limitação de taxa distribuído globalmente: “Design a distributed rate-limiting service in Python that must support 100,000 requests per second across multiple geographic regions. 1. Provide a high-level architectural strategy (e.g., Token Bucket vs. Fixed Window) and justify your choice for a global scale. 2. Write a thread-safe implementation using Redis as the backing store. 3. Address the ‘race condition’ problem when multiple instances update the same counter. 4. Include a pytest suite that simulates network latency between the app and Redis.”

Esse tipo de solicitação requer que o modelo funcione como um engenheiro sênior de sistemas distribuídos — raciocinando sobre trade-offs, produzindo código thread-safe, antecipando modos de falha e validando tudo com testes realistas, tudo em uma resposta coerente e única.

Acesso Programático via CLI e SDKs

O modelo pode ser acessado programaticamente através da API usando o identificador nvidia.nemotron-super-3-120b. O Nemotron 3 Super suporta tanto as APIs InvokeModel quanto Converse através da Interface de Linha de Comando da AWS (AWS CLI) e SDKs da AWS, com o mesmo identificador de modelo. Adicionalmente, o modelo é compatível com a API OpenAI do Amazon Bedrock.

Invocação via AWS CLI

Para invocar o modelo diretamente do terminal usando a Interface de Linha de Comando da AWS (AWS CLI) e a API InvokeModel, execute o comando abaixo:

aws bedrock-runtime invoke-model \
  --model-id nvidia.nemotron-super-3-120b \
  --region us-west-2 \
  --body '{"messages": [{"role": "user", "content": "Type_Your_Prompt_Here"}], "max_tokens": 512, "temperature": 0.5, "top_p": 0.9}' \
  --cli-binary-format raw-in-base64-out \
  invoke-model-output.txt

Invocação via AWS SDK para Python (Boto3)

Para invocar o modelo através do AWS SDK para Python (Boto3), utilizando a API Converse, utilize o seguinte script para enviar um prompt ao modelo:

import boto3
from botocore.exceptions import ClientError

# Create a Bedrock Runtime client in the AWS Region you want to use.
client = boto3.client("bedrock-runtime", region_name="us-west-2")

# Set the model ID
model_id = "nvidia.nemotron-super-3-120b"

# Start a conversation with the user message.
user_message = "Type_Your_Prompt_Here"
conversation = [
    {
        "role": "user",
        "content": [{"text": user_message}],
    }
]

try:
    # Send the message to the model using a basic inference configuration.
    response = client.converse(
        modelId=model_id,
        messages=conversation,
        inferenceConfig={"maxTokens": 512, "temperature": 0.5, "topP": 0.9},
    )
    # Extract and print the response text.
    response_text = response["output"]["message"]["content"][0]["text"]
    print(response_text)
except (ClientError, Exception) as e:
    print(f"ERROR: Can't invoke '{model_id}'. Reason: {e}")
    exit(1)

Invocação via OpenAI SDK

Para invocar o modelo através do endpoint compatível com OpenAI do Amazon Bedrock utilizando o SDK OpenAI, proceda conforme indicado abaixo:

# Import OpenAI SDK
from openai import OpenAI

# Set environment variables
os.environ["OPENAI_API_KEY"] = ""
os.environ["OPENAI_BASE_URL"] = "https://bedrock-runtime..amazon.com/openai/v1"

# Set the model ID
model_id = "nvidia.nemotron-super-3-120b"

# Set prompts
system_prompt = "Type_Your_System_Prompt_Here"
user_message = "Type_Your_User_Prompt_Here"

# Use ChatCompletionsAPI
response = client.chat.completions.create(
    model=model_id,
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_message}
    ],
    temperature=0,
    max_completion_tokens=1000
)

# Extract and print the response text
print(response.choices[0].message.content)

Próximos Passos

O NVIDIA Nemotron 3 Super no Amazon Bedrock abre possibilidades significativas para organizações que desejam construir a próxima geração de aplicações agentos com IA. Ao unir a arquitetura avançada do Nemotron 3 Super — com seu modelo MoE híbrido Transformer-Mamba e MoE latente — à infraestrutura completamente gerenciada e serverless do Bedrock, as organizações conseguem implantar aplicações sofisticadas com raciocínio elevado em escala, sem a sobrecarga de gerenciamento de backend.

Está pronto para explorar as possibilidades? Experimente agora: acesse a Console do Amazon Bedrock para testar o NVIDIA Nemotron 3 Super no playground de modelos. Para integração programática, explore o SDK da AWS e incorpore o Nemotron 3 Super em seus pipelines existentes de IA generativa.

Fonte

Run NVIDIA Nemotron 3 Super on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/run-nvidia-nemotron-3-super-on-amazon-bedrock/)

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/)

A integração NIXL com EFA na AWS

A AWS anunciou o suporte para NIXL (Biblioteca de Transferência de Inferência NVIDIA) em conjunto com EFA (Adaptador de Malha Elástica) para acelerar a inferência desagregada de modelos de linguagem de grande escala executados no Amazon EC2. Esse anúncio representa um avanço significativo para organizações que precisam processar grandes volumes de inferências com performance otimizada.

Melhorias principais da solução

A combinação de NIXL com EFA traz três melhorias fundamentais para a inferência desagregada:

• Throughput aumentado de cache KV: O cache de chave-valor é transferido de forma mais eficiente entre os nós de prefill e decode
• Latência reduzida entre tokens: Há diminuição no tempo necessário para processar tokens consecutivos, melhorando a responsividade da inferência
• Otimização de utilização de memória: O cache KV pode ser movimentado de forma mais eficiente entre diferentes camadas de armazenamento

Como funciona a aceleração de inferência

O NIXL com EFA possibilita transferências de cache KV entre prefill e decode nodes com alto throughput e baixa latência. Além disso, permite o movimento eficiente do cache KV entre várias camadas de armazenamento, o que é particularmente útil em arquiteturas de inferência complexas que precisam escalar.

Compatibilidade e integração com frameworks

A solução é interoperável com todas as instâncias EC2 habilitadas para EFA. O NIXL integra-se nativamente com frameworks populares de inferência, incluindo NVIDIA Dynamo, SGLang e vLLM. Essa compatibilidade oferece flexibilidade para escolher a combinação de instância EC2 e framework que melhor se adequa às necessidades de cada projeto.

Disponibilidade e requisitos técnicos

A AWS suporta NIXL versão 1.0.0 ou superior combinado com o instalador EFA versão 1.47.0 ou superior em todos os tipos de instância EC2 habilitadas para EFA. O serviço está disponível em todas as regiões AWS, sem custos adicionais.

Para mais detalhes técnicos sobre a configuração e implementação, consulte a documentação de EFA.

Fonte

AWS adds support for NIXL with EFA to accelerate LLM inference at scale (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-support-nixl-with-efa/)

Democratizando a Customização de Modelos de Linguagem

A personalização de modelos grandes de linguagem (LLMs) sempre foi uma tarefa desafiadora. Tradicionalmente, equipes enfrentam obstáculos significativos: necessidade de expertise técnica profunda, configuração complexa de infraestrutura e investimento considerável de tempo. A AWS anunciou o SDK Nova Forge precisamente para resolver esse cenário.

O Nova Forge SDK transforma a customização em um processo acessível e estruturado. Em vez de lidar com dependências complicadas, seleção de imagens e configuração de receitas, os times podem agora focar no que realmente importa: adaptar modelos para seus contextos específicos. A SDK suporta todo o espectro de customização, desde ajustes baseados no Amazon SageMaker até personalizações profundas aproveitando as capacidades completas do Nova Forge.

Um Caso Prático: Classificando Qualidade de Perguntas

Para ilustrar como o SDK Nova Forge funciona na prática, a AWS apresenta um cenário real extraído do Stack Overflow. O objetivo é automático: classificar perguntas em três categorias bem definidas (HQ — alta qualidade; LQ_EDIT — qualidade baixa com edições; LQ_CLOSE — qualidade baixa e fechada).

Moderadores do Stack Overflow enfrentam milhares de perguntas variadas. Uma ferramenta que classifique automaticamente a qualidade libera seus esforços, permitindo priorizar ações e guiar usuários. A solução utiliza o conjunto de dados Stack Overflow Question Quality, com 60 mil perguntas de 2016-2020 distribuídas nas três categorias mencionadas.

Para os experimentos, a AWS selecionou aleatoriamente 4.700 perguntas, organizadas assim:

• Treinamento (Ajuste Fino Supervisionado): 3.500 amostras (~75%)
• Avaliação: 500 amostras (~10%)
• Ajuste por Reforço: 700 amostras (~15%), combinadas com as 3.500 do treinamento anterior para evitar esquecimento catastrófico

O experimento segue quatro estágios: avaliação de desempenho base, ajuste fino supervisionado, ajuste por reforço e, finalmente, implantação no Amazon SageMaker Inference.

Etapa 1: Estabelecendo o Desempenho de Linha de Base

Antes de qualquer ajuste fino, é essencial medir como o modelo pré-treinado Nova 2.0 se comporta naturalmente. Essa avaliação inicial fornece um ponto de referência concreto para quantificar melhorias futuras. Compreender capacidades do modelo sem refinamento, identificar lacunas de desempenho e validar se ajuste fino é necessário são passos críticos.

O SDK Nova Forge oferece utilitários poderosos para carregamento de dados que lidam automaticamente com validação e transformação. Usando a classe CSVDatasetLoader, os dados são carregados e transformados para o formato esperado pelos modelos Nova:

from amzn_nova_forge import (
    NovaModelCustomizer,
    SMTJRuntimeManager,
    TrainingMethod,
    EvaluationTask,
    CSVDatasetLoader,
    Model,
)

# Configuração geral
MODEL = Model.NOVA_LITE_2
INSTANCE_TYPE = 'ml.p5.48xlarge'
EXECUTION_ROLE = '<YOUR_EXECUTION_ROLE_ARN>'
S3_BUCKET = '<YOUR_S3_BUCKET>'
S3_PREFIX = 'stack-overflow'
EVAL_DATA = './eval.csv'

# Carregar dados
loader = CSVDatasetLoader(
    query='Body',
    response='Y',
    system='system'
)
loader.load(EVAL_DATA)
loader.transform(method=TrainingMethod.EVALUATION, model=MODEL)
loader.validate(method=TrainingMethod.EVALUATION, model=MODEL)

# Salvar no S3
eval_s3_uri = loader.save_data(f"s3://{S3_BUCKET}/{S3_PREFIX}/data/eval.jsonl")

Com os dados preparados, inicializa-se o gerenciador de runtime e executa-se a avaliação:

runtime_manager = SMTJRuntimeManager(
    instance_type=INSTANCE_TYPE,
    instance_count=1,
    execution_role=EXECUTION_ROLE
)

baseline_customizer = NovaModelCustomizer(
    model=MODEL,
    method=TrainingMethod.EVALUATION,
    infra=runtime_manager,
    data_s3_path=eval_s3_uri,
    output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/baseline-eval"
)

baseline_result = baseline_customizer.evaluate(
    job_name="blogpost-baseline",
    eval_task=EvaluationTask.GEN_QA
)

Os resultados da linha de base revelaram um desempenho inicial de apenas 13,0% de precisão em coincidência exata (EM). Para uma tarefa de classificação em três categorias, adivinhar aleatoriamente resultaria em 33,3%, indicando que o modelo não está seguindo as instruções de formato apropriadamente. A distribuição de respostas mostrava verbosidade excessiva, com explicações longas quando a instrução pedia apenas o nome da categoria.

Etapa 2: Ajuste Fino Supervisionado para Aprender o Padrão

Com a linha de base estabelecida, o próximo passo é aplicar Ajuste Fino Supervisionado (SFT — Supervised Fine-Tuning). Essa técnica ensina ao modelo os padrões específicos do domínio e o formato de saída esperado.

A preparação de dados para SFT segue um processo similar, mas utiliza uma estrutura diferente — o formato de API Converse:

loader = CSVDatasetLoader(
    question='Body',
    answer='Y',
    system='system'
)
loader.load('sft.csv')
loader.transform(method=TrainingMethod.SFT_LORA, model=Model.NOVA_LITE_2)
loader.validate(method=TrainingMethod.SFT_LORA, model=Model.NOVA_LITE_2)

train_path = loader.save_data(f"s3://{S3_BUCKET}/{S3_PREFIX}/data/train.jsonl")

O treinamento é configurado com infraestrutura específica e hiperparâmetros controlados:

runtime = SMTJRuntimeManager(
    instance_type=INSTANCE_TYPE,
    instance_count=4,
    execution_role=EXECUTION_ROLE
)

customizer = NovaModelCustomizer(
    model=MODEL,
    method=TrainingMethod.SFT_LORA,
    infra=runtime,
    data_s3_path=train_path,
    output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/sft-output"
)

training_config = {
    "lr": 5e-6,
    "warmup_steps": 17,
    "max_steps": 100,
    "global_batch_size": 64,
    "max_length": 8192,
}

result = customizer.train(
    job_name="blogpost-sft",
    overrides=training_config
)

Após o treinamento, a avaliação sobre o mesmo conjunto de dados de teste revelou melhorias expressivas. A precisão em coincidência exata saltou para 77,2%, e a métrica de precisão de classificação extraída chegou a 79,0%. A distribuição de respostas agora mostra 100% de respostas concisas, eliminando a verbosidade problemática.

Etapa 3: Ajuste por Reforço para Otimizar Precisão

Embora o SFT tenha ensinado o formato correto, há ainda espaço para melhorar a precisão real das classificações. O Ajuste por Reforço (RFT — Reinforcement Fine-Tuning) usa uma função de recompensa para guiar o modelo em direção a decisões mais precisas.

A função de recompensa para essa tarefa é binária: +1,0 para predições corretas e -1,0 para incorretas. Uma função Lambda AWS implementa essa lógica, lidando com variações menores no formato de saída:

def calculate_reward(prediction: str, ground_truth: str) -> float:
    """Calcula recompensa binária"""
    extracted = extract_category(prediction)
    truth_norm = normalize_text(ground_truth)
    
    if extracted and extracted == truth_norm:
        return 1.0
    return -1.0

def lambda_handler(event, context):
    """Handler Lambda com recompensas binárias"""
    scores = []
    for sample in event:
        idx = sample.get("id", "no_id")
        ground_truth = sample.get("reference_answer", "")
        prediction = sample.get("content", "")
        reward = calculate_reward(prediction, ground_truth)
        scores.append({"id": idx, "aggregate_reward_score": reward})
    return scores

O treinamento RFT é então iniciado a partir do checkpoint SFT anterior:

REWARD_LAMBDA_ARN = "arn:aws:lambda:us-east-1:ACCOUNT:function:classification-reward"

rft_runtime = SMTJRuntimeManager(
    instance_type=INSTANCE_TYPE,
    instance_count=2,
    execution_role=EXECUTION_ROLE
)

rft_customizer = NovaModelCustomizer(
    model=MODEL,
    method=TrainingMethod.RFT_LORA,
    infra=rft_runtime,
    data_s3_path=rft_s3_uri,
    output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/rft-output",
    model_path=sft_checkpoint
)

rft_overrides = {
    "lr": 0.00001,
    "number_generation": 4,
    "max_new_tokens": 50,
    "kl_loss_coef": 0.02,
    "temperature": 1,
    "ent_coeff": 0.01,
    "max_steps": 40,
    "save_steps": 30,
    "top_k": 5,
    "global_batch_size": 64,
}

rft_result = rft_customizer.train(
    job_name="stack-overflow-rft",
    rft_lambda_arn=REWARD_LAMBDA_ARN,
    overrides=rft_overrides
)

O RFT trouxe melhorias adicionais incrementais. A precisão em coincidência exata aumentou para 78,8%, com a métrica Quasi-EM chegando a 80,6%. Embora o ganho seja menor que o do SFT, indica que o ajuste por reforço refina padrões diferentes, calibrando as decisões do modelo além da simples conformidade de formato.

Resultados Consolidados

Comparando todas as três fases — linha de base, pós-SFT e pós-RFT — observam-se ganhos consistentes em praticamente todas as métricas:

• ROUGE-1: 0,158 → 0,829 → 0,84 (ganho total: +0,682)
• Precisão em Coincidência Exata (EM): 0,13 → 0,772 → 0,788 (ganho total: +0,658)
• F1 Score: 0,138 → 0,772 → 0,788 (ganho total: +0,65)

O SFT proporcionou o maior salto, com ganhos expressivos no aprendizado de padrões específicos do domínio. O RFT refinou a tomada de decisão através de sinais baseados em recompensa, consolidando e otimizando o comportamento do modelo.

Etapa 4: Implantação no Amazon SageMaker Inference

Com o modelo final ajustado e testado, chega o momento da implantação para servir predições em produção. O Nova Forge SDK simplifica esse processo oferecendo duas opções: Amazon Bedrock para uma experiência totalmente gerenciada, ou Amazon SageMaker Inference para maior controle sobre a infraestrutura.

ENDPOINT_NAME = "blogpost-sdkg6"

deployment_result = rft_customizer.deploy(
    job_result=rft_result,
    deploy_platform=DeployPlatform.SAGEMAKER,
    unit_count=1,
    endpoint_name=ENDPOINT_NAME,
    execution_role_name="blogpost-sagemaker",
    sagemaker_instance_type="ml.p5.48xlarge",
    sagemaker_environment_variables={
        "CONTEXT_LENGTH": "12000",
        "MAX_CONCURRENCY": "16"
    }
)

# Invocar o endpoint
streaming_chat_request = {
    "messages": [{"role": "user", "content": "sua pergunta aqui"}],
    "max_tokens": 200,
    "stream": True,
}

inference_result = rft_customizer.invoke_inference(
    request_body=streaming_chat_request,
    endpoint_arn=ENDPOINT_NAME
)

Conclusão: Da Complexidade à Acessibilidade

O SDK Nova Forge transforma a customização de modelos — tradicionalmente um processo complexo e demorado — em um fluxo estruturado e acessível. O caso de estudo do Stack Overflow demonstra isso concretamente: começando em 13% de precisão, o modelo alcançou 79% após ajuste supervisionado e 80,6% após ajuste por reforço.

A SDK elimina barreiras históricas: não é mais necessário expertise profunda em configuração de infraestrutura, gerenciamento de dependências ou orquestração de pipelines complexos. Organizações podem agora construir modelos especializados e inteligentes, sensíveis ao contexto empresarial específico, sem perder as capacidades gerais que tornam os modelos de fundação tão valiosos.

Para começar a customizar modelos Nova, a AWS convida a comunidade a explorar o SDK Nova Forge no GitHub e consultar a documentação completa para construir modelos adaptados às necessidades empresariais específicas.

Fonte

Kick off Nova customization experiments using Nova Forge SDK (https://aws.amazon.com/blogs/machine-learning/kick-off-nova-customization-experiments-using-nova-forge-sdk/)

Superando as limitações dos testes A/B tradicionais

Empresas dependem frequentemente de testes A/B para otimizar a experiência do usuário, mensagens e fluxos de conversão. No entanto, a abordagem tradicional apresenta desafios significativos: a atribuição aleatória de usuários às variantes, combinada com a necessidade de coletar dados por semanas até atingir significância estatística, torna o processo lento e pode desperdiçar oportunidades de aprendizado.

A AWS apresenta uma solução baseada em Amazon Bedrock, Amazon Elastic Container Service, Amazon DynamoDB e o Model Context Protocol (MCP) que melhora significativamente os testes A/B tradicionais. Em vez de confiar apenas em atribuição aleatória, o sistema analisa contexto de usuário em tempo real para tomar decisões de variante mais inteligentes durante o experimento, reduzindo ruído, identificando padrões comportamentais mais rapidamente e atingindo um vencedor confiável com maior velocidade.

Por que a atribuição aleatória limita os resultados

O fluxo tradicional segue um padrão conhecido: atribuir aleatoriamente usuários às variantes, coletar dados e selecionar o vencedor. Essa abordagem tem limitações claras. A atribuição puramente aleatória ignora sinais iniciais que indicam diferenças significativas. A convergência é lenta — é necessário esperar semanas para coletar dados suficientes. O ruído é alto — o sistema pode atribuir usuários a variantes que claramente não se alinham com suas necessidades. A otimização é manual — frequentemente é preciso segmentar dados posteriori para compreender o resultado.

Considere um varejista testando dois botões de chamada para ação (CTA) em páginas de produtos. A Variante A apresenta “Compre Agora” e a Variante B, “Compre Agora – Frete Grátis”. Nos primeiros dias, a Variante B se destaca. No entanto, uma análise mais profunda revela algo importante: membros premium com benefício de frete grátis hesitam ao ver a mensagem de “Frete Grátis” e alguns até navegam para verificar seus benefícios. Visitantes orientados a descontos, chegando de sites de cupons, se engajam muito mais com a Variante B. Usuários mobile preferem a Variante A porque o CTA mais curto se ajusta melhor em telas pequenas.

Embora a Variante B pareça vencer em curto prazo, diferentes grupos de usuários influenciam esse desempenho — não necessariamente uma preferência universal. Como a atribuição é aleatória, o experimento precisa de uma janela longa para balancear esses efeitos, e análises manuais de múltiplos segmentos se tornam necessárias para compreender o resultado. É aqui que a atribuição assistida por inteligência artificial oferece uma melhoria real.

Transformando testes A/B com inteligência artificial

Arquitetura do sistema adaptativo

O motor de testes A/B assistido por IA aprimora a experimentação clássica utilizando contexto de usuário em tempo real e padrões comportamentais iniciais para fazer atribuições de variante mais inteligentes. A solução introduz um mecanismo adaptativo construído com Amazon Bedrock, onde em vez de confirmar cada usuário a mesma variante, o motor avalia o contexto do usuário em tempo real, recupera dados comportamentais passados e seleciona uma variante ideal para aquele indivíduo específico.

A arquitetura inclui componentes-chave: Amazon CloudFront + AWS WAF para rede de distribuição de conteúdo global com proteção contra negação de serviço distribuído, prevenção de injeção SQL e limitação de taxa; uma Origem VPC com conexão privada do CloudFront para um Load Balancer de Aplicação interno; Amazon ECS com AWS Fargate para orquestração serverless de contêineres rodando aplicação FastAPI; Amazon Bedrock como mecanismo de decisão de IA utilizando Claude Sonnet com suporte nativo a chamada de ferramentas; o Model Context Protocol (MCP) proporcionando acesso estruturado a dados de comportamento e experimentos; VPC Endpoints para conectividade privada a diversos serviços AWS; Amazon DynamoDB com cinco tabelas para experimentos, eventos, atribuições, perfis e trabalhos em lote; e Amazon Simple Storage Service (Amazon S3) para hospedagem de frontend estático e armazenamento de logs de eventos.

Como a inteligência artificial melhora as decisões

A inovação central reside em combinar contexto de usuário, histórico comportamental, padrões de usuários similares e dados de desempenho em tempo real para selecionar a variante ideal. Quando um usuário dispara uma solicitação de variante, o sistema constrói um prompt abrangente que fornece ao Amazon Bedrock todo o conteúdo necessário para uma decisão informada.

O prompt combina dois níveis: um prompt de sistema que define o Amazon Bedrock como “especialista em otimização de testes A/B” com acesso a onze ferramentas MCP e regras críticas (verificar atribuições existentes primeiro, aplicar limite de 30% para mudanças, responder apenas em JSON); e um prompt de usuário que fornece contexto completo de decisão incluindo atributos de usuário, dados de personalização, configurações de variante formatadas dinamicamente, métricas de desempenho em tempo real e um framework de cinco passos para decisão.

A estrutura em dois níveis permite que o Amazon Bedrock orquestre inteligentemente chamadas de ferramentas e faça seleções de variante baseadas em dados com total transparência. Para um novo usuário mobile, o sistema pode chamar análise de usuários similares e descobrir que 23% mais usuários mobile convertem com a Variante B. Para um cliente premium retornando, pode chamar o perfil do usuário e descobrir que o histórico sugere manter a Variante A atual. Cada situação dispara uma estratégia de coleta de dados diferente.

Comparação com aprendizado de máquina tradicional

Modelos tradicionais de aprendizado de máquina — árvores de decisão, regressão logística, redes neurais — impulsionaram segmentação de usuários por anos. Por que usar Amazon Bedrock então?

Orquestração inteligente de ferramentas: aprendizado de máquina tradicional requer engenharia de características hard-coded. O Amazon Bedrock, através do Model Context Protocol, decide inteligentemente quais ferramentas chamar baseado na situação específica. Um novo usuário dispara análise de similaridade; um cliente retornando dispara análise de perfil; casos especiais podem disparar todas as ferramentas.

Síntese de raciocínio multifatorial: modelos tradicionais de aprendizado de máquina produzem previsões sem explicação. O Amazon Bedrock fornece raciocínio que sintetiza múltiplos fatores. Uma decisão pode articular como restrições de dispositivo, padrões de usuários similares e métricas de engajamento pessoal combinam-se para informar a seleção.

Tratamento de sinais conflitantes: quando sinais entram em conflito, o Amazon Bedrock raciocina através dos trade-offs. Se a Variante A tem taxa de conversão agregada mais alta, mas usuários similares ao cliente atual mostram 34% de aumento com a Variante B, o sistema pondera essas informações e explica sua decisão final.

Sem treinamento, adaptação instantânea: aprendizado de máquina tradicional requer coleta de dados históricos, engenharia de características e treinamento periódico de modelo. O Amazon Bedrock funciona imediatamente, começando com padrões de usuários similares existentes no Dia 1 e refinando com dados de resultado acumulados nos dias seguintes.

Implementação do mecanismo adaptativo

Estratégia híbrida de atribuição

A implementação utiliza uma abordagem inteligente: usuários novos recebem atribuição baseada em hash (eficiente em custo), enquanto usuários retornando recebem seleção baseada em IA (alto valor).

Para usuários novos, não há dados comportamentais, portanto análise de IA fornece valor mínimo. A atribuição baseada em hash oferece experiência consistente enquanto dados são coletados.

Para usuários retornando, o backend invoca o Amazon Bedrock que utiliza o Model Context Protocol para acessar dados comportamentais através de um sistema de orquestração inteligente de ferramentas. Em vez de inserir todos os dados no prompt (caro e lento), o Amazon Bedrock chamadas ferramentas seletivamente para reunir exatamente a informação necessária.

Framework de ferramentas MCP e execução

O Model Context Protocol (MCP) fornece ao Amazon Bedrock acesso estruturado aos dados comportamentais através de um sistema inteligente de orquestração de ferramentas. A resposta do Amazon Bedrock pode incluir chamadas de ferramentas que o backend FastAPI executa, retornando o resultado e continuando a conversa. Esse loop continua até o modelo produzir a decisão final em JSON.

As ferramentas principais incluem: get_similar_users() que encontra usuários com padrões comportamentais similares usando correspondência baseada em cluster, calculando scores de similaridade (0.0-1.0) derivados de similaridade de scores de engajamento (30%), correspondência de estilo de interação (20%), sobreposição de preferências de conteúdo (20%), similaridade de probabilidade de conversão (15%) e correspondência de preferência visual (15%); get_user_profile() que recupera perfil comportamental abrangente incluindo sinais comportamentais, preferências, dados de desempenho e contexto de dispositivo; get_variant_performance() que recupera dados de desempenho em tempo real com métricas atuais, dados históricos e metadados de período de tempo.

Armazenando insights para decisões futuras

Após cada seleção de variante, o sistema registra o resultado para melhorar decisões futuras. Conforme mais resultados são registrados, perfis de usuário tornam-se representações mais precisas de preferências individuais, permitindo que o Amazon Bedrock faça seleções de variante mais bem-informadas.

Interpretando scores de confiança

Cada decisão de IA inclui um score de confiança (0.0-1.0) que reflete a avaliação do sistema sobre quão certa está a seleção de variante baseada nos dados disponíveis. O Amazon Bedrock avalia múltiplos fatores: disponibilidade de dados, consistência de sinais, evidência de usuários similares, significância estatística de dados de desempenho e maturidade de perfil.

Interpretação prática: scores 0.9–1.0 indicam extrema confiabilidade com evidência forte em todos os fatores; 0.7–0.89 indica alta confiança com qualidade de dados boa; 0.5–0.69 indica confiança moderada com dados razoáveis; 0.3–0.49 indica baixa confiança com dados limitados; scores menores que 0.3 indicam dados insuficientes para predição confiante.

Exemplo prático: testando botões de chamada para ação

Usuário 1: membro premium em dispositivo mobile

Contexto inicial: dispositivo iPhone, membro de programa de lealdade premium, padrão de navegação rápido e orientado a objetivos, navegação direta, compras frequentes.

O sistema executa: verificação de atribuição existente (nenhuma encontrada), recuperação de perfil do usuário (score de engajamento 0.89, score de probabilidade de conversão 0.24, estilo de interação “focused”), busca por usuários similares (52 membros de lealdade mobile encontrados preferindo Variante A), e recuperação de desempenho da Variante A (3.900 impressões, 125 conversões, taxa de conversão 3.2%, confiança 0.89).

A decisão resultante: Variante A com confiança 0.86. Raciocínio: alinhamento forte entre múltiplos sinais — o perfil do usuário mostra estilo de interação “focused” com atenção curta, preferindo experiências simplificadas; a confiança no perfil é alta (0.87) baseado em dados históricos; 52 usuários similares de lealdade mobile preferem fortemente a Variante A; a Variante A mostra desempenho sólido com taxa de conversão de 3.2%; o status de lealdade significa a mensagem de frete grátis é redundante.

Usuário 2: visitante primeira vez de site de cupons

Contexto inicial: dispositivo Android, sem status de lealdade, padrão de navegação lento e comparativo, referência de site agregador de descontos.

O sistema executa: verificação de atribuição existente (nenhuma encontrada), recuperação de perfil do usuário (score de engajamento 0.15, score de probabilidade de conversão 0.05, confiança muito baixa 0.12 — novo usuário), busca por usuários similares (39 novos usuários de sites de cupom encontrados preferindo Variante B com 2.3x conversão mais alta), recuperação de desempenho da Variante B (3.850 impressões, 158 conversões, taxa de conversão 4.1%, confiança 0.95).

A decisão resultante: Variante B com confiança 0.91. Raciocínio: apesar da confiança baixa no perfil do usuário (novo usuário, confiança 0.12), sinais contextuais fortes criam alta confiança na decisão — a fonte de referência (site de cupons) indica comportamento orientado a descontos; 39 visitantes primeira vez similares de sites de cupom mostram preferência forte pela Variante B com incentivo de mensagem; a Variante B mostra desempenho forte com taxa de conversão 4.1%; o status de novo usuário significa nenhuma preferência de variante anterior para contradizer. A decisão orientada por contexto que aproveita padrões de usuários similares compensa a falta de histórico comportamental individual.

Próximos passos e evoluções

O sistema fornece fundação para personalizações avançadas: geração dinâmica de variantes em vez de seleção de variantes predefinidas, adaptando mensagens, cores e urgência baseado em comportamento individual; algoritmos de bandits multi-armados combinando personalização de IA com alocação automática de tráfego; aprendizado entre experimentos compartilhando insights através de testes; otimização em tempo real usando dados de streaming; segmentação avançada deixando a IA descobrir automaticamente segmentos de usuário através de clustering.

Conclusão

A AWS demonstra uma abordagem moderna para experimentação que transiciona de atribuição estática e aleatória para um mecanismo de personalização inteligente e continuamente aprendente. Os benefícios principais incluem decisões de variante personalizadas, aprendizado quase contínuo a partir do comportamento de usuário, arquitetura serverless com overhead operacional mínimo, custos previsíveis através de atribuição híbrida e integração profunda com serviços AWS.

Para começar, a recomendação é: implantar a infraestrutura básica usando templates do AWS CloudFormation, começar com atribuição baseada em hash para todos os usuários estabelecendo uma linha de base; habilitar seleção assistida por IA para usuários retornando após dados comportamentais estarem disponíveis, começando com pequena percentagem de tráfego; expandir ferramentas MCP customizadas baseado em necessidades específicas de negócio; e monitorar latência de atribuição, custos da API Amazon Bedrock e métricas de conversão usando dashboards do Amazon CloudWatch.

O código completo para implementação é disponibilizado incluindo backend FastAPI, frontend React, templates CloudFormation e implementação de servidor MCP no repositório A/B Testing Engine no GitHub. Para evitar encargos contínuos, os recursos criados durante a implementação devem ser deletados, com instruções detalhadas fornecidas no Infrastructure Cleanup Guide.

Fonte

Build an AI-Powered A/B testing engine using Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/build-an-ai-powered-a-b-testing-engine-using-amazon-bedrock/)

O desafio de validar agentes de IA em ambiente de produção

Quando se trabalha com agentes de inteligência artificial, surge um problema que os testes tradicionais de software não conseguem resolver de forma adequada. Diferentemente de aplicações convencionais, onde uma entrada específica sempre produz a mesma saída, agentes de IA possuem características fundamentalmente diferentes: são flexíveis, adaptáveis e conscientes do contexto em que operam.

Considere uma pergunta simples: “Qual é a previsão do tempo em Tóquio?” Um agente bem projetado poderia responder informando a temperatura em Celsius ou Fahrenheit, incluindo umidade e vento, ou focando apenas na temperatura. Todas essas respostas podem ser corretas e úteis — mas como você avalia sistematicamente algo que não segue um padrão determinístico?

O problema se torna ainda mais complexo quando consideramos que agentes não apenas geram texto, mas também tomam ações. Um agente bem-projetado utiliza ferramentas, recupera informações e toma decisões durante toda uma conversa. Avaliar apenas a resposta final ignora se o agente seguiu passos apropriados para chegar àquele resultado.

Além disso, conversas multi-turnos adicionam outra camada de complexidade. Quando usuários interagem com um agente ao longo de múltiplas trocas, respostas anteriores influenciam as posteriores. Um agente pode responder bem a perguntas isoladas, mas falhar em manter contexto coerente ao longo de uma conversa inteira.

Por que a avaliação de agentes é diferente

Essas características criam uma necessidade que os testes baseados em asserções simples não conseguem atender. A avaliação baseada em modelos de linguagem de grande escala (LLM — Large Language Model) surge como resposta, permitindo que se avaliem qualidades como utilidade, coerência e fidelidade que resistem a verificações mecânicas.

A AWS apresenta o Strands Evals, um framework projetado especificamente para este desafio. Ele fornece um conjunto integrado de avaliadores baseados em LLM, ferramentas de simulação de usuários e capacidades de relatório, permitindo que equipes de desenvolvimento validem agentes de forma rigorosa e repetível.

Conceitos fundamentais do Strands Evals

O framework funciona seguindo um padrão familiar para quem já escreveu testes unitários, mas adaptado para a avaliação baseada em julgamento que agentes de IA exigem. Três conceitos formam a base:

Cases

Um Case representa um cenário único de teste. Contém a entrada que você deseja testar — por exemplo, uma pergunta do usuário — além de saídas esperadas opcionais, sequências de ferramentas esperadas (trajetórias) e metadados. Cases são a unidade atômica de avaliação.

from strands_evals import Case
case = Case(
    name="Weather Query",
    input="What is the weather like in Tokyo?",
    expected_output="Should include temperature and conditions",
    expected_trajectory=["weather_api"]
)

Experiments

Um Experiment agrupa múltiplos Cases com um ou mais avaliadores. É o equivalente a um conjunto de testes (test suite) nos testes tradicionais. O Experiment orquestra o processo de avaliação: pega cada Case, executa o agente nele e aplica os avaliadores configurados para gerar pontuações.

Evaluators

Avaliadores funcionam como juízes. Examinam o que seu agente produziu e comparam contra o que era esperado. Diferentemente de verificações de asserção simples, os avaliadores no Strands Evals são principalmente baseados em LLM, usando modelos de linguagem para fazer julgamentos sofisticados sobre qualidade, relevância e utilidade.

Task Function

Uma Task Function é um elemento executável que você fornece ao Experiment. Recebe um Case e retorna os resultados da execução desse caso no seu sistema. Essa interface permite dois padrões fundamentalmente diferentes de avaliação.

Avaliação online: invoca o agente ao vivo durante a avaliação. Sua Task Function cria um agente, envia a entrada do Case, captura a resposta e o rastreamento de execução, retornando-os para avaliação. Este padrão é recomendado durante desenvolvimento para feedback rápido ou em pipelines de CI/CD (Integração e Entrega Contínua).

from strands import Agent
def online_task(case):
    agent = Agent(tools=[search_tool, calculator_tool])
    result = agent(case.input)
    return {
        "output": str(result),
        "trajectory": agent.session
    }

Avaliação offline: trabalha com dados históricos. Em vez de invocar um agente, sua Task Function recupera rastreamentos gravados anteriormente de logs, bancos de dados ou sistemas de observabilidade. Este padrão funciona bem quando você precisa avaliar tráfego de produção, realizar análise histórica ou comparar versões de agentes contra o mesmo conjunto de interações reais.

def offline_task(case):
    trace = load_trace_from_database(case.session_id)
    session = session_mapper.map_to_session(trace)
    return {
        "output": extract_final_response(trace),
        "trajectory": session
    }

Avaliadores integrados para avaliação abrangente

O Strands Evals fornece dez avaliadores integrados, cada um projetado para avaliar uma dimensão diferente da qualidade do agente.

Avaliadores baseados em rubrica

Os avaliadores mais flexíveis permitem que você defina critérios personalizados através de rubricas em linguagem natural. O OutputEvaluator julga a resposta final que seu agente produz. Você fornece uma rubrica descrevendo o que é “bom”, e o avaliador usa um LLM para pontuar a saída contra esses critérios.

O TrajectoryEvaluator estende isso para examinar a sequência de ações que o agente tomou. Além de apenas olhar para a resposta final, você pode verificar se o agente usou ferramentas apropriadas em uma ordem lógica. O avaliador inclui três funções de pontuação integradas: correspondência exata, correspondência em ordem e correspondência em qualquer ordem.

O InteractionsEvaluator lida com sistemas de múltiplos agentes onde vários componentes se comunicam, avaliando sequências de interações entre agentes ou componentes do sistema.

Avaliadores semânticos

Algumas dimensões de qualidade são comuns o suficiente para que o Strands Evals forneça avaliadores pré-construídos com prompts cuidadosamente projetados.

O HelpfulnessEvaluator avalia respostas da perspectiva do usuário usando uma escala de sete pontos, desde “não útil” até “acima e além”. O FaithfulnessEvaluator verifica se a resposta está fundamentada no histórico da conversa — particularmente importante para sistemas RAG (Recuperação Aumentada de Geração), onde você precisa garantir que o agente não fabrique informações.

O HarmfulnessEvaluator realiza verificações de segurança, ajudando a determinar se as respostas contêm conteúdo prejudicial ou inadequado.

Avaliadores em nível de ferramenta

Quando seu agente usa ferramentas, frequentemente você precisa avaliar não apenas o resultado final, mas a qualidade de invocações individuais de ferramentas. O ToolSelectionAccuracyEvaluator examina cada chamada de ferramenta em contexto e julga se selecionar aquela ferramenta em particular era justificado. O ToolParameterAccuracyEvaluator vai além, verificando se os parâmetros passados a cada ferramenta estavam corretos e apropriados.

Avaliadores em nível de sessão

O GoalSuccessRateEvaluator adota a visão mais ampla, avaliando sessões de conversa inteiras para determinar se o usuário finalmente alcançou seu objetivo. Para agentes orientados por tarefas, sucesso é definido por resultados em vez de uma única resposta.

Simulando usuários para testes multi-turnos

Os avaliadores mencionados funcionam bem para interações de turno único. Conversas multi-turnos apresentam um desafio maior: usuários reais não seguem scripts. Fazem perguntas de acompanhamento, mudam de direção e expressam confusão.

O Strands Evals inclui um ActorSimulator que cria usuários simulados alimentados por IA para conduzir conversas multi-turnos com seu agente. O simulador começa com um Case que define o que o usuário quer alcançar. A partir disso, ele gera um perfil de usuário realista usando um LLM, incluindo traços de personalidade, nível de expertise, estilo de comunicação e uma meta específica.

from strands_evals import Case, ActorSimulator
from strands import Agent

case = Case(
    input="I need help setting up a new bank account",
    metadata={"task_description": "Successfully open a checking account"}
)

user_sim = ActorSimulator.from_case_for_user_simulator(
    case=case,
    max_turns=10
)

agent = Agent(system_prompt="You are a helpful banking assistant.")
user_message = case.input

while user_sim.has_next():
    agent_response = agent(user_message)
    user_result = user_sim.act(str(agent_response))
    user_message = str(user_result.structured_output.message)

Durante a interação, o usuário simulado envia mensagens ao agente, recebe respostas e decide o que dizer em seguida. Este ciclo continua até que o objetivo seja alcançado ou o número máximo de turnos seja atingido. Você pode então passar a transcrição da conversa resultante para avaliadores em nível de sessão para avaliar se seu agente ajudou com sucesso o usuário simulado a alcançar sua meta.

Estrutura hierárquica de avaliação

Diferentes avaliadores operam em diferentes granularidades. O Strands Evals usa um TraceExtractor para analisar dados de sessão no formato que cada avaliador precisa.

Avaliação em nível de sessão: analisa a conversa completa do início ao fim. O avaliador recebe o histórico completo, as execuções de ferramentas e entende todo o contexto. O GoalSuccessRateEvaluator funciona neste nível porque determinar alcance de objetivos requer entender a interação inteira.

Avaliação em nível de rastreamento: foca em turnos individuais — cada par de pergunta do usuário e resposta do agente. Avaliadores neste nível recebem o histórico da conversa até aquele ponto e julgam a resposta específica. Helpfulness, Faithfulness e Harmfulness funcionam aqui.

Avaliação em nível de ferramenta: desce para invocações individuais de ferramentas. Cada chamada é avaliada em contexto, com acesso às ferramentas disponíveis, a conversa até aquele ponto, e os argumentos específicos passados.

Integração na prática

Um fluxo de avaliação típico começa com a definição de casos de teste representando cenários que você quer que seu agente manipule bem. Eles podem vir de consultas de usuários reais, geração sintética ou casos extremos que você identificou:

from strands_evals import Experiment, Case
from strands_evals.evaluators import OutputEvaluator, TrajectoryEvaluator

cases = [
    Case(
        name="Weather Query",
        input="What is the weather like in Tokyo?",
        expected_output="Should include temperature and conditions",
        expected_trajectory=["weather_api"]
    ),
    Case(
        name="Calculator Usage",
        input="What is 15% of 847?",
        expected_output="127.05",
        expected_trajectory=["calculator"]
    )
]

Em seguida, você configura avaliadores com rubricas ou configurações apropriadas e cria um Experiment agrupando Cases e avaliadores. Finalmente, executa a avaliação com sua Task Function e examina os resultados através de relatórios detalhados.

Para conjuntos de testes maiores, o Strands Evals suporta avaliação assíncrona com paralelismo configurável, permitindo escalar o processo de teste conforme suas necessidades crescem.

Gerando casos de teste em escala

O fluxo anterior assume que você já tem casos de teste prontos. Criar suites de teste abrangentes manualmente fica tedioso conforme as capacidades do seu agente crescem. O Strands Evals inclui um ExperimentGenerator que usa LLMs para criar casos de teste e rubricas de avaliação a partir de descrições de alto nível.

O gerador cria casos de teste diversos cobrindo diferentes aspectos do contexto especificado, com níveis de dificuldade apropriados. Casos gerados são particularmente valiosos durante desenvolvimento inicial quando você quer cobertura ampla mas ainda não identificou padrões de falha específicos. Conforme sua prática de avaliação amadurece, complemente Cases gerados com cenários feitos à mão visando casos extremos conhecidos.

Boas práticas para avaliação de agentes

Comece pequeno e itere: inicie com poucos casos de teste cobrindo seus cenários de usuário mais críticos. Conforme observa como seu agente falha na prática, adicione casos direcionados que abordem esses modos de falha específicos.

Escolha avaliadores que correspondam aos seus objetivos: selecione avaliadores que meçam diretamente o que importa para seu caso de uso. Um agente voltado para clientes pode priorizar Helpfulness e Goal Success, enquanto um assistente de pesquisa pode valorizar mais Faithfulness.

Escreva rubricas claras e específicas: avaliadores baseados em rubricas são tão bons quanto as rubricas que você fornece. Evite critérios vagos em favor de padrões específicos e mensuráveis. Inclua exemplos do que constitui pontuações altas, médias e baixas.

Combine avaliação online e offline: use avaliação online durante desenvolvimento para feedback rápido em mudanças de código. Complemente com avaliação offline de rastreamentos de produção para capturar problemas que só aparecem com comportamento real de usuários.

Defina limiares significativos: defina limiares de aprovação/falha baseados em seus requisitos reais de qualidade. Analise resultados de avaliação para entender quais pontuações se correlacionam com bons resultados de usuários, então defina limiares correspondentes.

Rastreie tendências ao longo do tempo: execuções individuais de avaliação fornecem snapshots, mas tendências revelam a trajetória. Armazene resultados de avaliação e rastreie métricas-chave entre lançamentos. Degradação gradual pode ser mais difícil de notar que falhas repentinas, mas igualmente prejudicial.

Invista em diversidade de casos de teste: cubra a faixa completa de entradas que seu agente encontrará: consultas comuns, casos extremos, entradas adversariais e conversas multi-turnos.

Avalie em múltiplos níveis: sucesso em nível de sessão pode mascarar problemas em nível de ferramenta, e vice-versa. Um agente pode alcançar metas de usuários através de passos intermediários ineficientes ou incorretos. Componha suites de avaliação que verifiquem qualidade em níveis de sessão, rastreamento e ferramenta para obter uma visão completa.

Conclusão

Construir agentes de IA confiáveis exige mais que intuição e verificações pontuais. Requer avaliação sistemática que rastreie qualidade através de múltiplas dimensões ao longo do tempo. O Strands Evals fornece uma fundação através de um framework projetado especificamente para os desafios únicos da avaliação de agentes.

A separação entre invocação de agente e lógica de avaliação permite tanto testes online durante desenvolvimento quanto análise offline de rastreamentos de produção. Avaliadores baseados em LLM fornecem o julgamento que avaliação de qualidade exige. Níveis de avaliação hierárquicos permitem validação em múltiplas granularidades, desde chamadas individuais de ferramentas até sessões de conversa completas.

Para explorar o Strands Evals, a documentação com exemplos práticos contém amostras que você pode adaptar para seus próprios casos de uso. Comece com poucos casos de teste representando seus cenários de usuário mais importantes, adicione avaliadores que correspondam a seus critérios de qualidade e execute avaliações como parte de seu fluxo de desenvolvimento. Ao longo do tempo, expanda sua suite de testes para cobrir mais cenários. Avaliação sistemática é a fundação que o ajuda a entregar agentes de IA com confiança.

Fonte

Evaluating AI agents for production: A practical guide to Strands Evals (https://aws.amazon.com/blogs/machine-learning/evaluating-ai-agents-for-production-a-practical-guide-to-strands-evals/)