Blog

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

Expansão do Portfólio de Modelos no Bedrock

A AWS anunciou a disponibilidade de dois novos modelos de linguagem no Amazon Bedrock: o GLM 5 e o Minimax M2.5. Essa expansão permite que clientes da plataforma tenham acesso a modelos de ponta otimizados para cenários específicos de alta complexidade.

Características do GLM 5

O GLM 5 é um modelo de linguagem de classe fronteiriça com propósito geral, projetado especialmente para tarefas complexas de engenharia de sistemas e operações de longo horizonte com agentes autônomos. O modelo representa uma evolução da linha GLM 4.5, que já possuía orientação centrada em agentes.

Entre as capacidades do GLM 5 estão o suporte a raciocínio em múltiplas etapas, processamento matemático avançado (incluindo benchmarks no estilo AIME), codificação sofisticada e fluxos de trabalho aumentados por ferramentas externas. O modelo oferece suporte a contexto estendido, características essenciais para agentes sofisticados e aplicações empresariais que demandam compreensão profunda e execução de tarefas intrincadas.

Capacidades do Minimax M2.5

O Minimax M2.5 é um modelo de ponta desenvolvido especificamente com orientação nativa para agentes autônomos. Sua arquitetura foi treinada com foco em raciocínio eficiente, decomposição otimizada de tarefas e conclusão de fluxos de trabalho complexos dentro de restrições reais de tempo e custo operacional.

Uma característica notável do Minimax M2.5 é sua velocidade de conclusão de tarefas, que se aproxima ou até supera modelos proprietários de ponta líderes no mercado. Esse desempenho é alcançado através da combinação de throughput de inferência elevado com aprendizado por reforço direcionado para raciocínio eficiente em tokens e melhor tomada de decisão em estruturas de suporte para agentes.

Disponibilidade e Próximos Passos

Tanto o Minimax M2.5 quanto o GLM 5 estão agora disponíveis no Amazon Bedrock em regiões selecionadas da AWS. Para obter a lista completa de regiões onde os modelos estão disponíveis, consulte a documentação técnica.

Fonte

Minimax M2.5 and GLM 5 models now available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-bedrock-minimax-glm/)

Um Novo Modelo Híbrido para Aplicações Complexas

A Amazon Bedrock expandiu seu catálogo de modelos de inteligência artificial com o anúncio do Nemotron 3 Super, desenvolvido pela NVIDIA. Trata-se de um modelo de arquitetura híbrida baseado em Mixture-of-Experts (MoE) — uma abordagem que combina múltiplos especialistas para processar diferentes tipos de informação de forma mais eficiente.

Este modelo foi especificamente projetado para atender workloads de natureza agentica, ou seja, aplicações onde agentes de IA precisam executar tarefas complexas em múltiplas etapas mantendo contexto e precisão ao longo de toda a operação. O Nemotron 3 Super oferece inferência rápida e otimizada em termos de custo, reduzindo o consumo de recursos computacionais sem comprometer a qualidade das respostas.

Abertura e Flexibilidade Técnica

Um dos diferenciais do Nemotron 3 Super é sua natureza completamente aberta. A NVIDIA disponibilizou não apenas os pesos do modelo (os parâmetros treinados), mas também os datasets utilizados no treinamento e as receitas — ou seja, as configurações e metodologias empregadas na construção do modelo.

Essa abordagem de código aberto facilita a customização por parte das organizações, permitindo que empresas, startups e desenvolvedores individuais adaptem o modelo para suas necessidades específicas. Ao mesmo tempo, a transparência técnica contribui para implantações seguras, fundamental para contextos empresariais que exigem conformidade e auditoria.

Integração Simplificada via Amazon Bedrock

A grande vantagem de acessar o Nemotron 3 Super através da Amazon Bedrock é a eliminação da complexidade operacional. Em vez de gerenciar infraestrutura própria, provisionar servidores ou fazer o host do modelo, os usuários acessam o modelo através de uma API única totalmente gerenciada.

O Bedrock oferece inferência sem servidor, o que significa que não há necessidade de preocupação com capacidade, escalabilidade ou manutenção de infraestrutura. Além disso, o serviço inclui controles de segurança integrados, garantindo que os dados processados sejam protegidos conforme os padrões corporativos.

Compatibilidade com OpenAI API

Um detalhe técnico importante é que o Nemotron 3 Super, quando acessado via Bedrock, é compatível com as especificações da API OpenAI. Isso significa que desenvolvedores que já trabalham com essa interface padrão podem integrar o modelo em seus fluxos de trabalho existentes com mínimas alterações de código. Essa compatibilidade reduz significativamente a curva de aprendizado e o tempo de implementação.

Disponibilidade e Próximos Passos

O Nemotron 3 Super está disponível na Amazon Bedrock em regiões selecionadas da AWS. Para conhecer a lista completa de regiões onde o modelo está disponível, consulte a documentação sobre compatibilidade de modelos.

Desenvolvedores interessados em começar a usar o modelo podem acessar o console da Amazon Bedrock ou consultar a documentação técnica do serviço. Para quem busca começar especificamente com os endpoints compatíveis com a API OpenAI, a AWS fornece documentação detalhada sobre como iniciarse com essa abordagem.

Fonte

NVIDIA Nemotron 3 Super now available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-bedrock-nemotron-3-super/)

Por que customizar modelos de linguagem?

Modelos de linguagem grandes (LLMs) revolucionaram a forma como interagimos com inteligência artificial. Porém, a realidade empresarial mostra que uma abordagem genérica raramente atende completamente às necessidades específicas das organizações. Os LLMs tradicionais chegam ao mercado treinados com conhecimento amplo e generalista, otimizados para diversos casos de uso. Ainda assim, frequentemente ficam aquém quando enfrentam tarefas específicas de domínio, fluxos de trabalho proprietários ou requisitos únicos de negócio.

As empresas cada vez mais precisam de modelos especializados que entendam profundamente seus dados proprietários, processos empresariais e terminologia específica do seu segmento. Sem essa personalização, restam apenas duas opções desconfortáveis: aceitar respostas genéricas ou gastar recursos excessivos com engenharia de contexto para melhorar as saídas.

Opções de customização disponíveis na AWS

A AWS estruturou suas capacidades de customização em diferentes níveis. Através do Amazon Bedrock, oferece opções como Treinamento Fine-Tuning Supervisionado (SFT) e Treinamento Fine-Tuning Reforçado (RFT). Já o Amazon SageMaker AI adiciona capacidades ainda mais avançadas, incluindo SFT, Otimização de Preferência Direta (DPO), RFT e suporte tanto para adaptação de baixo rank (LoRA) quanto customização de rank completo.

Conforme modelos são ajustados em datasets especializados, emerge um desafio técnico conhecido: frequentemente perdem capacidades base como habilidade de seguir instruções, raciocínio lógico e conhecimento amplo. Esse fenômeno é denominado esquecimento catastrófico. A Amazon Nova Forge oferece uma solução inovadora, permitindo construir modelos personalizados usando a família Nova a partir de checkpoints iniciais de modelo, blendando dados proprietários com dados curados pela AWS e hospedando tudo de forma segura na plataforma.

O desafio da complexidade e a resposta do Nova Forge SDK

Embora as opções de customização sejam poderosas, os fluxos de trabalho envolvem complexidade significativa. Exigem expertise técnica em infraestrutura, configuração de receitas específicas, seleção adequada de imagens e gerenciamento minucioso de dependências. Essa complexidade representa uma barreira real para muitas equipes interessadas em customização.

Para remover esses obstáculos, a AWS lançou o Nova Forge SDK. Trata-se de um kit de desenvolvimento desenhado para tornar a customização de LLMs acessível e empoderador, permitindo que equipes aproveitem todo o potencial dos modelos de linguagem sem lidar com gerenciamento de dependências, seleção de imagens ou configuração de receitas. A ferramenta reduz significativamente as barreiras de entrada para customização profissional.

A AWS visualiza a customização como um continuum dentro da escada de escalabilidade. Nesse contexto, o Nova Forge SDK suporta todas as opções de customização disponíveis, desde o Amazon Bedrock até o Amazon SageMaker AI, utilizando as capacidades Amazon Nova Forge.

Arquitetura e componentes do Nova Forge SDK

O toolkit do Nova Forge SDK representa um esforço deliberado para remover o trabalho indiferenciado da customização de LLMs. Oferece workflows com padrões inteligentes e orientação, enquanto mantém acesso total aos SDKs subjacentes para casos de uso avançados. O resultado é uma ferramenta que equilibra simplicidade para tarefas comuns com flexibilidade completa para requisitos sofisticados.

O SDK organiza-se em três camadas conceituais, cada uma com responsabilidades distintas:

Camada de Entrada: Aqui você fornece os insumos necessários. Inclui o objeto RuntimeManager (que define hardware, plataforma e função IAM para permissões), método de treinamento, dados de treinamento, hiperparâmetros personalizados e o modelo escolhido para customização.

Camada Customizadora: Essa camada intermediária recebe os inputs e, nos bastidores, constrói as configurações de receita apropriadas e dispara o job com os valores recebidos.

Camada de Saída: Emite artefatos de saída incluindo logs do Amazon CloudWatch, métricas MLFlow, logs TensorBoard e o artefato final do modelo treinado. Esse modelo pode ser usado para refinamento iterativo adicional ou implantação no Amazon SageMaker AI ou Amazon Bedrock para inferência.

Operacionalmente, o usuário fornece um RuntimeManager configurado, um modelo para customizar e um método de treinamento para um dos métodos de API em um NovaModelCustomizer inicializado. Quando o Customizer é inicializado, especifica-se o local de onde recuperar dados de treinamento, tipicamente um bucket do Amazon S3. Baseado nessas configurações, o modelo Customizer cuida de configurar e iniciar um job do Amazon SageMaker AI para executar a tarefa especificada. Ao término, a tarefa gera artefatos de saída e (para a API “train”) um modelo treinado que você pode referenciar através do SDK ou diretamente via APIs do Amazon SageMaker.

Preparação e configuração inicial

Antes de iniciar o fluxo de customização, existem requisitos de infraestrutura e permissões que precisam estar no lugar.

Dependências fundamentais

O artigo utiliza Jobs de Treinamento do Amazon SageMaker (SMTJ) como plataforma de computação. Note que você não precisa de um cluster Amazon SageMaker HyperPod para acompanhar os fundamentos — se seu interesse está limitado a SMTJ, a configuração de HyperPod é totalmente opcional.

Conta AWS e interfaces de linha de comando

Você precisa de uma conta AWS. Se não possuir uma, siga as instruções de criação. Após isso, instale e configure a Interface de Linha de Comando da AWS (AWS CLI) com suas credenciais. A CLI é usada nas chamadas iniciais de setup, e o Nova Forge SDK compartilha a cadeia de credenciais da AWS CLI. Também é necessário configurar seu acesso à plataforma SageMaker AI, que o SDK usa para oferecer acesso aos modelos Amazon Nova e capacidades de customização.

Funções IAM

Você precisa criar duas funções IAM para trabalhar com o Nova Forge SDK: a função de Usuário e a função de Execução.

Função de Usuário: A função que você assume em sua máquina ao executar o SDK e a AWS CLI. Essa função precisa de permissões para Amazon SageMaker AI (CreateTrainingJob, DescribeTrainingJob), Amazon S3 (leitura/escrita no seu bucket de dados), Amazon CloudWatch Logs (leitura) e IAM (PassRole). Consulte a documentação do SDK para a política completa.

Função de Execução: A função que o Amazon SageMaker AI assume para executar jobs de treinamento em seu nome. Sua política de confiança deve permitir que sagemaker.amazonaws.com a assuma. Para o conjunto completo de permissões recomendadas, consulte a documentação da função de execução do SageMaker. Os pré-requisitos para executar jobs SMTJ incluem instruções detalhadas de setup.

Quotas de serviço

Este artigo utiliza instâncias ml.p5.48xlarge tanto para treinamento quanto avaliação. O Nova Lite 2.0 requer um mínimo de 4 instâncias para treinamento SFT; se executar jobs de treinamento e avaliação concorrentemente, talvez precise de pelo menos 5 instâncias. Solicite quotas suficientes para ml.p5.48xlarge através do console de Quotas de Serviço para Jobs de Treinamento do Amazon SageMaker.

Bucket S3

Crie um bucket do Amazon S3 na mesma região AWS que seus jobs de treinamento (neste artigo usamos us-east-1) e certifique-se que suas funções IAM de usuário e execução possuem acesso de leitura e escrita. Aqui você armazenará dados de treinamento e artefatos de saída.

Amazon SageMaker HyperPod (opcional)

Além dos Jobs de Treinamento do Amazon SageMaker, o Nova Forge SDK também suporta execução em Amazon SageMaker HyperPod. Este artigo não enfatiza customização em SMHP, mas se desejar treinar em HyperPod, deve configurar um cluster com Grupos de Instâncias Restritos (RIGs). Siga as instruções no workshop de setup HyperPod RIG para configurar um cluster adequado para customização Amazon Nova.

Instalação e configuração do ambiente

Após concluir os pré-requisitos, você está pronto para configurar seu ambiente.

Ambiente Python

O Nova Forge SDK requer Python 3.12 ou posterior. Recomenda-se criar um ambiente virtual para isolar dependências:

python3.12 -m venv nova-sdk-env
source nova-sdk-env/bin/activate
# No Windows: nova-sdk-env\Scripts\activate

Instalação do SDK

Instale o SDK com o seguinte comando pip:

pip install amzn-nova-forge

Verifique a instalação importando os módulos principais em um arquivo Python de teste:

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

Módulos principais do SDK

NovaModelCustomizer: A classe primária para interagir com o Nova Forge SDK, contendo métodos core da API e inicialização de configuração de treinamento.

SMTJRuntimeManager: Gerencia a infraestrutura AWS necessária para customização SMTJ, como tipo de instância selecionado e contagem para um job de customização.

TrainingMethod: Uma enumeração dos tipos de treinamento possíveis para configurar um NovaModelCustomizer.

EvaluationTask: Uma enumeração dos tipos de avaliação possíveis para configurar um NovaModelCustomizer.

CSVDatasetLoader: Usado para carregar dados de arquivos CSV para uso no Nova Forge SDK.

Model: Uma enumeração dos modelos Amazon Nova suportados pelo Nova Forge SDK.

Para informações adicionais sobre funcionalidades diferentes do SDK, consulte o documento de especificação. Se usar um agente LLM para trabalho em codificação, você pode ter o agente revisar o arquivo AGENTS.md no repositório para aprender sobre o SDK.

O significado dessa abordagem

A interface unificada do SDK abstrai a complexidade de formatação de dados e configurações específicas de plataforma, permitindo que desenvolvedores foquem no que realmente importa: seus dados, seu domínio e seus objetivos de negócio. Seja começando com fine-tuning em Jobs de Treinamento do Amazon SageMaker ou planejando customização com Amazon SageMaker HyperPod, o SDK oferece uma experiência consistente através de todo o continuum de customização.

Ao remover as barreiras tradicionais para customização de LLMs, requisitos de expertise técnica e investimento de tempo, o Nova Forge SDK capacita organizações a construir modelos que verdadeiramente entendem seu contexto único sem sacrificar as capacidades gerais que tornam modelos de base valiosos. O SDK cuida de configurar recursos de computação, orquestrar todo o pipeline de customização, monitorar jobs de treinamento e implantar endpoints. O resultado é IA empresarial que é tanto especializada quanto inteligente, expert em domínio e amplamente capaz.

Próximos passos

Pronto para customizar seus próprios modelos Nova? Comece com o Nova Forge SDK no GitHub e explore a documentação completa para começar a construir modelos adaptados às suas necessidades empresariais.

Fonte

Introducing Nova Forge SDK, a seamless way to customize Nova models for enterprise AI (https://aws.amazon.com/blogs/machine-learning/introducing-nova-forge-sdk-a-seamless-way-to-customize-nova-models-for-enterprise-ai/)