O problema do excesso de cautela em modelos de linguagem

Quem trabalha com modelos de fundação (FMs — Foundation Models) em produção sabe que os mecanismos de segurança embutidos, embora essenciais, às vezes bloqueiam requisições completamente legítimas. Uma empresa de mídia que precisa resumir roteiros com linguagem adulta, uma equipe de segurança cibernética simulando ataques reais para treinamento, ou um time jurídico analisando evidências sensíveis — todos podem se deparar com recusas do modelo onde não deveriam.

Um exemplo concreto: uma equipe de segurança pedindo ao modelo que gere um e-mail de phishing simulado para treinar funcionários pode receber uma negativa, mesmo que a intenção seja claramente defensiva. O problema é que essas restrições não estão em um filtro externo — elas estão gravadas nos próprios parâmetros do modelo, incorporadas durante a fase de alinhamento pós-treinamento. Engenharia de prompt não resolve. É preciso atuar no nível do modelo.

Para endereçar esse desafio, a AWS publicou os detalhes técnicos por trás do Configurações Personalizáveis de Moderação de Conteúdo (CCMS) do Amazon Nova, apresentando a técnica que o sustenta: o rDPO (Otimização de Preferência Direta Reversa — Reverse Direct Preference Optimization).

O que é o CCMS e como ele funciona

O CCMS permite que clientes aprovados ajustem seletivamente as proteções do Amazon Nova em quatro pilares de IA Responsável (RAI — Responsible AI):

• Segurança — Abrange atividades perigosas, armas e substâncias controladas.
• Conteúdo sensível — Inclui linguagem imprópria, nudez e bullying.
• Equidade — Considerações sobre viés e cultura.
• Segurança cibernética — Preocupações envolvendo malware e conteúdo malicioso.

Vale destacar: o Amazon Nova mantém controles invioláveis e não configuráveis para uso responsável da IA, como proteções contra danos a crianças e preservação de privacidade. O CCMS opera dentro desses limites — não os remove.

A base científica do CCMS é o conceito de unlearning (desaprendizado), uma técnica para remover seletivamente comportamentos aprendidos dos parâmetros de um modelo sem precisar retreiná-lo do zero. A AWS treina adaptadores de Adaptação de Baixo Posto (LoRA — Low-Rank Adaptation) para reverter o alinhamento do modelo em políticas específicas. O resultado é uma variante personalizada que consegue gerar conteúdo nas áreas aprovadas pelo cliente, mantendo o alinhamento em todo o restante.

A técnica por trás do CCMS: rDPO

O que já existia antes: DPO e NPO

Para entender o rDPO, é útil conhecer as abordagens anteriores. A Otimização de Preferência Direta (DPO — Direct Preference Optimization) é uma técnica de alinhamento que treina o modelo para classificar respostas preferidas acima das não preferidas, em relação a um modelo de referência. É o que faz o modelo “aprender” a se comportar de determinada forma.

Já a Otimização de Preferência Negativa (NPO — Negative Preference Optimization) tenta fazer o inverso: remove as amostras positivas do objetivo de otimização, ensinando o modelo a se afastar de seus comportamentos de recusa aprendidos. O problema do NPO é que ele apenas ensina o modelo a esquecer, sem direcioná-lo para respostas alternativas de qualidade. O resultado pode ser uma degradação perceptível na qualidade das saídas.

A inovação do rDPO

O rDPO resolve exatamente essa limitação. Em vez de simplesmente fazer o modelo esquecer um comportamento, o rDPO simultaneamente guia o modelo em direção a respostas de alta qualidade nas áreas de política desaprendidas. Esse duplo objetivo não apenas produz melhor qualidade de resposta, mas também melhora a eficiência do treinamento, exigindo menos etapas de otimização para convergir.

A lógica é a seguinte: no DPO original, o modelo aprende a preferir respostas “corretas” em detrimento das “erradas”. No rDPO, os pares de preferência são invertidos em relação ao objetivo de alinhamento original — daí o nome “reverso”. O modelo é treinado para se afastar da resposta de recusa (forgetting response) e se aproximar de uma resposta-alvo de qualidade (target response).

Na prática, os experimentos mostram que o rDPO converge para uma acurácia de treinamento próxima a 1 em cerca de 30 passos, enquanto o NPO praticamente não evolui nesse mesmo indicador. As recompensas da resposta-alvo no rDPO continuam crescendo ao longo do treinamento, ao contrário do NPO, onde caem. Isso se deve ao forte alinhamento de segurança do modelo base, que torna difícil para o NPO afastar o modelo das respostas seguras sem um objetivo positivo claro.

O pipeline de personalização

O processo de customização segue um fluxo bem definido: começa com a preparação dos dados, onde um conjunto de prompts é selecionado para representar as áreas de política-alvo onde se deseja desaprender o comportamento de recusa. A partir desses prompts, são geradas as respostas de esquecimento e as respostas-alvo. Em seguida, o modelo é treinado com rDPO sobre esses dados. Ao final do ciclo de treinamento, o adaptador LoRA é exportado e está pronto para ser servido.

A escolha pelo LoRA é estratégica: sua eficiência de treinamento e menor custo de inferência em comparação ao ajuste fino de posto completo (full-rank fine-tuning) tornam a abordagem viável em escala. O adaptador atua sobre o modelo base sem modificar seus pesos — o que significa que diferentes configurações de política podem ser servidas a partir do mesmo modelo de fundação.

Resultados: menos recusas, mesma qualidade

Redução nas taxas de recusa

A avaliação do modelo personalizado foi feita em dois eixos: redução no excesso de recusas em requisições sensíveis e preservação das capacidades gerais do modelo. A taxa de recusa mede a porcentagem de prompts que o modelo se recusa a responder.

Os resultados com o Amazon Nova 2 Lite mostram reduções substanciais em todas as categorias de política:

• Red Team Prompts: de 98,10% para 47%
• Equidade: de 51,84% para 23,83% (redução de 28 pontos percentuais)
• Segurança: de 86,51% para 32,77% (redução de 53,74 pp)
• Segurança cibernética: de 91,61% para 45,73% (redução de 46 pp)
• Conteúdo sensível: de 79,02% para 33,58% (redução de 45 pp)

Todas essas reduções foram obtidas exclusivamente por meio do adaptador LoRA treinado com rDPO, sem nenhuma modificação nos pesos do modelo base.

Preservação das capacidades gerais

Um requisito crítico para qualquer abordagem de desaprendizado é não degradar as capacidades gerais do modelo. A avaliação em três benchmarks de utilidade confirma que o rDPO passa nesse teste:

• Seguimento de instruções: de 94,12% para 92,57% (queda de 1,55 pp)
• Raciocínio matemático (Math Mini): de 86,40% para 85,20% (queda de 1,20 pp)
• Geração de código (MBXP Python): de 74,80% para 73% (queda de 1,80 pp)

Quedas inferiores a 2 pontos percentuais confirmam que o rDPO atinge seletivamente apenas os parâmetros de alinhamento RAI, preservando intactas as capacidades centrais do modelo — uma vantagem clara da abordagem baseada em LoRA em relação ao ajuste fino completo do modelo.

Como começar a usar

Para quem quer experimentar as técnicas

As técnicas de otimização de preferência descritas — DPO, NPO e rDPO — estão acessíveis para quem quiser explorar pesquisa de desaprendizado e alinhamento por conta própria. O Amazon SageMaker AI suporta treinamento DPO com abordagens de posto completo e LoRA para o Amazon Nova e mais de 20 modelos de pesos abertos. O Amazon SageMaker HyperPod oferece receitas prontas de DPO que servem como ponto de partida para experimentos personalizados. Há um passo a passo detalhado em Personalizar o Amazon Nova no Amazon SageMaker AI usando Otimização de Preferência Direta.

Para quem quer usar o CCMS diretamente

Para clientes que preferem os benefícios do desaprendizado sem precisar construir tudo do zero, o CCMS oferece adaptadores LoRA pré-treinados para o Amazon Nova, prontos para implantação. Os adaptadores são compartilhados por meio do AWS Resource Access Manager (Gerenciador de Acesso a Recursos da AWS). Após aceitar e copiar um adaptador para a sua conta, ele aparece como um modelo personalizado no Amazon Bedrock com um Nome de Recurso Amazon (ARN) exclusivo. Em seguida, basta criar uma implantação de modelo personalizado com inferência sob demanda e usar o ARN dessa implantação na API Converse padrão. Nenhuma outra alteração de código é necessária:

aws bedrock-runtime converse \
--model-id "arn:aws:bedrock:us-east-1:<account-id>:custom-model-deployment/<deployment-id>" \
--region us-east-1 \
--messages '[{"role": "user", "content": [{"text": "Your prompt here"}]}]'

Vale lembrar: a implantação de um modelo personalizado incorre nas cobranças de inferência padrão do Amazon Bedrock.

O modelo personalizado se comporta de forma idêntica ao modelo Nova base para as áreas de política não configuradas. Para proteções adicionais em nível de aplicação, é possível combinar o CCMS com o Amazon Bedrock Guardrails para implementar filtragem por tópico, detecção de alucinações ou políticas de conteúdo personalizadas sobre o modelo configurado.

Para solicitar acesso e discutir quais pilares de política configurar para o seu caso de uso, o caminho é entrar em contato com a equipe de conta AWS ou abrir um caso de suporte pelo Console do AWS Support Center.

Conclusão

O rDPO representa um avanço relevante na área de desaprendizado seletivo em modelos de linguagem. Ao reverter os pares de preferência no objetivo do DPO, a técnica consegue simultaneamente fazer o modelo esquecer comportamentos de recusa indesejados e direcioná-lo a respostas de qualidade — algo que o NPO não conseguia fazer de forma eficiente.

O resultado prático é claro: adaptadores LoRA treinados com rDPO reduzem as taxas de recusa em até 54 pontos percentuais nas categorias de política RAI, com degradação inferior a 2 pontos percentuais nos benchmarks de utilidade. E tudo isso operando dentro dos limites das proteções universais e não configuráveis do Amazon Nova, que permanecem intactas independentemente da configuração do adaptador.

Para pesquisadores e profissionais interessados em explorar mais, o Amazon SageMaker AI oferece receitas de treinamento DPO como base para experimentação. Há também documentação, posts sobre personalização do Nova e métodos avançados de ajuste fino no Amazon SageMaker AI para quem quiser se aprofundar.

Fonte

Teaching models to forget: Selective unlearning with Amazon Nova (https://aws.amazon.com/blogs/machine-learning/teaching-models-to-forget-selective-unlearning-with-amazon-nova/)

Modelos de IA de código aberto com garantias empresariais

Cada vez mais organizações estão adotando modelos de fundação de código aberto (open-weight) para alimentar cargas de trabalho de IA em produção — de assistentes de codificação agênticos a análise de documentos com contextos longos. À medida que essas cargas de trabalho evoluem da fase experimental para implantações corporativas, dois requisitos moldam toda decisão de seleção de modelos: o modelo precisa entregar as capacidades que a carga de trabalho exige, e o ambiente de inferência precisa atender aos requisitos de segurança e conformidade da organização.

Para endereçar essa necessidade, o Amazon Bedrock oferece um serviço totalmente gerenciado para acesso a modelos de fundação líderes de mercado, com a inferência rodando inteiramente na infraestrutura operada pela AWS. Os prompts e as respostas geradas não são usados para treinar nenhum modelo, e o conteúdo não é compartilhado com os provedores dos modelos.

A MiniMax é uma empresa global de tecnologia em IA que desenvolve modelos de fundação multimodais com ênfase em arquiteturas eficientes para cargas de trabalho em escala de produção. Agora, sua família M2 está disponível no Amazon Bedrock como modelos de código aberto totalmente gerenciados.

Os três modelos da família MiniMax M2

O Amazon Bedrock suporta três modelos da família MiniMax M2, cada um com características distintas para diferentes cenários de uso. Veja o resumo:

• MiniMax M2 (minimax.minimax-m2): primeiro a ser lançado, com geração de texto multilíngue, raciocínio, codificação e uma janela de contexto de 1 milhão de tokens. Ideal para contextos longos ou uso geral multilíngue.
• MiniMax M2.1 (minimax.minimax-m2.1): traz melhorias em profundidade de raciocínio, precisão de codificação e seguimento de instruções. Janela de contexto de 196 mil tokens. Indicado para tarefas de raciocínio complexo ou seguimento de instruções em múltiplas etapas.
• MiniMax M2.5 (minimax.minimax-m2.5): o modelo mais recente, treinado especificamente para execução nativa de agentes, com ênfase em chamada de ferramentas (tool-calling), decomposição de tarefas em múltiplas etapas e tarefas de codificação de longo horizonte. Janela de contexto de 196 mil tokens. Melhor escolha para fluxos agênticos, chamada de ferramentas ou cargas de trabalho intensivas em código.

Todos os três modelos suportam os níveis de serviço Standard, Priority e Flex, com saída máxima de 8 mil tokens. Para a lista completa e atualizada, consulte a documentação de modelos MiniMax no Amazon Bedrock.

Arquitetura Mistura de Especialistas (MoE)

A família M2 é construída sobre uma arquitetura de Mistura de Especialistas (MoE), onde apenas uma pequena fração dos parâmetros totais é ativada por token. O MiniMax M2.5, por exemplo, possui 230 bilhões de parâmetros totais, mas apenas 10 bilhões ficam ativos por passagem. Isso significa que o modelo entrega a capacidade de conhecimento de um modelo de 230B enquanto consome computação proporcional a apenas 10B parâmetros — o que se traduz diretamente em menor custo de inferência.

Por serem modelos de código aberto, é possível avaliar independentemente a arquitetura e a metodologia de treinamento, executar benchmarks próprios em cargas de trabalho representativas e até realizar ajuste fino (fine-tuning) em dados proprietários — tudo isso através de um serviço gerenciado da AWS, sem necessidade de provisionar infraestrutura.

Dois endpoints para acessar os modelos MiniMax

O Amazon Bedrock oferece dois endpoints para invocar os modelos MiniMax:

Endpoint bedrock-mantle (recomendado)

O endpoint bedrock-mantle (https://bedrock-mantle.{region}.api.aws/v1) é a API pública do motor de inferência de nova geração do Amazon Bedrock. Ele utiliza a API Chat Completions — a mesma interface dos SDKs Python e TypeScript da OpenAI — o que significa que equipes que já utilizam esse SDK podem migrar para os modelos MiniMax no Bedrock simplesmente atualizando a URL base e o ID do modelo. Suporta chaves de API do Amazon Bedrock, projetos e chamada de ferramentas no lado do cliente.

Endpoint bedrock-runtime

O endpoint bedrock-runtime (https://bedrock-runtime.{region}.amazonaws.com) utiliza as APIs Converse e InvokeModel via SDK da AWS. Use este endpoint para funcionalidades nativas do Amazon Bedrock como Guardrails, Agents, Flows e avaliação de modelos.

Primeiros passos com MiniMax M2.5 no Amazon Bedrock

Playground no console

Para experimentar o modelo sem escrever código, basta acessar o console do Amazon Bedrock, selecionar “Chat/Text playground” no menu lateral em “Test”, escolher o modelo MiniMax M2.5 e clicar em “Apply”. O modelo carrega e a interface de chat já está pronta para uso.

Usando o endpoint bedrock-mantle com o SDK OpenAI

Para usar o endpoint bedrock-mantle, é necessária uma chave de API do Amazon Bedrock ou credenciais AWS configuradas para SigV4. A política mínima necessária é:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockMantleInference",
      "Effect": "Allow",
      "Action": [
        "bedrock-mantle:CreateInference",
        "bedrock-mantle:Get*",
        "bedrock-mantle:List*"
      ],
      "Resource": "arn:aws:bedrock-mantle:us-east-1:111122223333:project/*"
    },
    {
      "Sid": "BedrockMantleApiKeyAccess",
      "Effect": "Allow",
      "Action": "bedrock-mantle:CallWithBearerToken",
      "Resource": "*"
    }
  ]
}

Substitua 111122223333 pelo ID da sua conta AWS. O primeiro bloco cobre autenticação SigV4; o segundo cobre autenticação por chave de API (bearer token). Se usar apenas SigV4, o segundo bloco pode ser omitido.

Para controlar quais identidades podem gerar ou usar chaves de API do Amazon Bedrock, consulte Controle de permissões para chaves de API do Amazon Bedrock. Para restringir a organização apenas a modelos aprovados, utilize uma Política de Controle de Serviço (SCP).

O exemplo abaixo usa o SDK Python da OpenAI como biblioteca cliente para chamar o endpoint bedrock-mantle. Para workloads em produção, use chaves de API de curta duração, que expiram automaticamente (máximo de 12 horas) e herdam as permissões da função do Gerenciamento de Identidade e Acesso da AWS (IAM) que as gerou. Se você já usa credenciais AWS e não tem uma chave de API, o pacote aws-bedrock-token-generator gera um bearer token de curta duração a partir dessas credenciais.

Nota: cada invocação de modelo incorre em cobranças por token. Consulte a página de preços do Amazon Bedrock para as tarifas atuais.

import boto3
from openai import OpenAI

# Retrieve the Amazon Bedrock API key from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager", region_name="us-east-1")
api_key = secrets_client.get_secret_value(SecretId="bedrock-api-key")["SecretString"]

client = OpenAI(
    base_url="https://bedrock-mantle.us-east-1.api.aws/v1",
    api_key=api_key,
)

response = client.chat.completions.create(
    model="minimax.minimax-m2.5",
    messages=[
        {"role": "user", "content": "Explain the benefits of mixture-of-experts architectures for production inference."}
    ],
    max_tokens=512,
)

print(response.choices[0].message.content)

Nota: esses exemplos recuperam a chave de API do AWS Secrets Manager. Para desenvolvimento local, é possível ler a chave de uma variável de ambiente, mas evite esse padrão em produção.

Chamada de ferramentas (tool calling)

O MiniMax M2.5 é projetado para fluxos de trabalho agênticos, sendo bem adequado para cenários de chamada de ferramentas. Nesse fluxo, você define funções (ferramentas) que o modelo pode invocar, o modelo decide quando chamá-las com base na solicitação do usuário, e a aplicação executa a função e retorna o resultado para que o modelo o incorpore na resposta final.

O exemplo abaixo demonstra esse padrão de ponta a ponta: define uma ferramenta get_weather, envia uma mensagem do usuário, deixa o modelo solicitar a chamada da ferramenta, executa a função com dados simulados e passa o resultado de volta para o modelo gerar uma resposta em linguagem natural.

import json
import boto3
from openai import OpenAI

# Retrieve the Amazon Bedrock API key from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager", region_name="us-east-1")
api_key = secrets_client.get_secret_value(SecretId="bedrock-api-key")["SecretString"]

client = OpenAI(
    base_url="https://bedrock-mantle.us-east-1.api.aws/v1",
    api_key=api_key,
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a given location",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "City and country (e.g., Seattle, US)"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "Temperature unit"
                    }
                },
                "required": ["location"]
            }
        }
    }
]

# Step 1: Send the user request with tool definitions
messages = [
    {"role": "user", "content": "What's the weather like in Seattle?"}
]

response = client.chat.completions.create(
    model="minimax.minimax-m2.5",
    messages=messages,
    tools=tools,
    tool_choice="auto",
)

assistant_message = response.choices[0].message

# Step 2: Check if the model wants to call a tool
if assistant_message.tool_calls:
    messages.append(assistant_message)

    for tool_call in assistant_message.tool_calls:
        function_name = tool_call.function.name
        arguments = json.loads(tool_call.function.arguments)

        # Step 3: Validate function name and run
        if function_name == "get_weather":
            location = arguments.get("location", "Unknown")
            unit = arguments.get("unit", "fahrenheit")
            result = {
                "location": location,
                "temperature": 18 if unit == "celsius" else 64,
                "unit": unit,
                "condition": "Partly cloudy",
                "humidity": 72,
            }
        else:
            result = {"error": f"Unknown function: {function_name}"}

        # Step 4: Return the function result to the model
        messages.append({
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": json.dumps(result),
        })

    # Step 5: Get the final response incorporating tool results
    final_response = client.chat.completions.create(
        model="minimax.minimax-m2.5",
        messages=messages,
        tools=tools,
    )
    print(final_response.choices[0].message.content)
else:
    print(assistant_message.content)

Usando o endpoint bedrock-runtime com Boto3

Para o endpoint bedrock-runtime, são necessárias credenciais AWS (usuário ou função IAM) com permissão para invocar o modelo. A política mínima é:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/minimax.minimax-m2.5"
    }
  ]
}

O exemplo abaixo envia uma requisição ao MiniMax M2.5 usando o SDK AWS para Python (Boto3) com a API Converse:

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    modelId="minimax.minimax-m2.5",
    messages=[{
        "role": "user",
        "content": [{"text": "What is mixture of experts?"}]
    }],
    inferenceConfig={"maxTokens": 2048, "temperature": 1.0, "topP": 0.95},
)

content_blocks = response["output"]["message"]["content"]
response_text = next(
    (block["text"] for block in content_blocks if "text" in block), None
)

if response_text:
    print(response_text)
else:
    print("No text response.")

Nota: na API Converse, o MiniMax M2.5 retorna um bloco reasoningContent antes do bloco de texto. O código itera pelos blocos de conteúdo para extrair a resposta final em texto.

Usando a Interface de Linha de Comando da AWS (AWS CLI)

Também é possível acessar o MiniMax M2.5 diretamente pelo terminal usando a Interface de Linha de Comando da AWS (AWS CLI):

aws bedrock-runtime converse \
  --model-id minimax.minimax-m2.5 \
  --messages '[{"role":"user","content":[{"text":"Type_Your_Prompt_Here"}]}]' \
  --inference-config '{"maxTokens":2048}' \
  --region us-east-1

Níveis de serviço disponíveis

O Amazon Bedrock oferece múltiplos níveis de serviço para atender a diferentes requisitos de carga de trabalho. Todos os três modelos MiniMax suportam os seguintes níveis:

• Priority: para fluxos de trabalho críticos e voltados ao cliente que exigem os tempos de resposta mais rápidos. Oferece até 25% melhor latência em tokens de saída por segundo (OTPS) em comparação ao Standard. Processado com prioridade sobre requisições Standard e Flex. Preço premium sobre o on-demand padrão, sem reserva antecipada.
• Standard: para tarefas cotidianas de IA como geração de conteúdo, análise de texto e processamento de documentos. Desempenho consistente com preço on-demand padrão. Nível padrão quando nenhum nível é especificado.
• Flex: para cargas de trabalho que toleram maior latência, como avaliações de modelos, sumarização de conteúdo e fluxos agênticos. Preço com desconto em relação ao Standard. Maior latência, especialmente em horários de pico, pois as requisições Flex são processadas após as Standard.

Nota: o nível Reserved não está disponível atualmente para modelos MiniMax.

Escalando a inferência on-demand

Ao invocar modelos MiniMax no Amazon Bedrock, as requisições usam inferência on-demand (nível Standard) por padrão, onde você paga por token sem reservar capacidade. No endpoint bedrock-mantle, não há cota de requisições por minuto (RPM) — o throughput é governado por limites baseados em tokens.

Para lidar com erros transitórios, use lógica de retry com backoff exponencial. O Boto3 suporta isso via configuração padrão:

import boto3
from botocore.config import Config

config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)

Dois erros principais podem ocorrer em produção:

• HTTP 429: cota de tokens por minuto excedida. Reduza a taxa de envio e faça retry com backoff exponencial. Solicite aumento de cota via AWS Support se o limite for atingido com frequência.
• HTTP 503: pressão na capacidade regional do modelo. Faça retry com backoff exponencial para erros transitórios. Para erros sustentados, reduza a taxa de envio.

Ao aumentar a taxa de requisições, escale em incrementos graduais em vez de saltos bruscos. O procedimento recomendado é: comece na taxa alvo; se receber erros 503, reduza 50%, aguarde 15 minutos em estado estável, aumente 50% e repita até atingir o volume alvo. A espera de 15 minutos é a etapa que a maioria das equipes pula — e é justamente a mais importante.

Para orientações completas, consulte as boas práticas de escalabilidade e throughput no Guia do Usuário do Amazon Bedrock.

Cache implícito de prompts para redução de latência

Os modelos MiniMax no Amazon Bedrock suportam cache implícito de prompts. Quando requisições consecutivas compartilham um prefixo de prompt comum, pode ocorrer um acerto de cache (cache hit), permitindo que o modelo reutilize o estado interno em cache em vez de recomputá-lo — reduzindo a latência de inferência nos tokens correspondentes, sem alterações no código e sem marcadores de cache necessários.

O cache implícito está disponível em todos os níveis de serviço on-demand (Standard, Priority e Flex). Para maximizar as taxas de acerto, coloque conteúdo estático (prompts de sistema, definições de ferramentas, documentos de referência) no início do prompt e conteúdo dinâmico (mensagens do usuário, contexto variável) no final.

Disponibilidade e preços

O MiniMax M2.5 está disponível em 14 regiões AWS: Leste dos EUA (N. Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Europa (Frankfurt), Europa (Estocolmo), Europa (Milão), Europa (Irlanda), Europa (Londres), Ásia-Pacífico (Tóquio), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Sydney), Ásia-Pacífico (Jacarta), Ásia-Pacífico (Melbourne) e América do Sul (São Paulo). As requisições são atendidas na região chamada. A inferência entre regiões (Geo e Global) não está disponível atualmente para modelos MiniMax. Para a lista mais recente, consulte a página de regiões suportadas.

Os preços são por token e variam por modelo e nível de serviço. Para as tarifas atuais, consulte a página de preços do Amazon Bedrock.

Recursos adicionais

• Guia do Usuário do Amazon Bedrock
• Modelos MiniMax no Amazon Bedrock
• Model card do MiniMax M2.5
• Model card do MiniMax M2.1
• Model card do MiniMax M2
• Endpoints do Amazon Bedrock
• Cotas para o endpoint bedrock-mantle
• Boas práticas de escalabilidade e throughput
• Níveis de serviço do Amazon Bedrock
• Chaves de API do Amazon Bedrock
• Preços do Amazon Bedrock

Fonte

Run MiniMax models on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/run-minimax-models-on-amazon-bedrock/)

O problema com agentes de múltiplas etapas

Quando você constrói agentes empresariais que executam fluxos de trabalho complexos — consultando bancos de dados, chamando APIs, cruzando resultados e se recuperando de falhas no meio do processo — você se depara com um desafio de treinamento fundamental. A qualidade de uma ação individual depende do que acontece várias etapas depois.

O aprendizado por reforço a partir de feedback humano (RLHF) otimiza respostas isoladas, uma de cada vez. Essa abordagem não funciona bem para fluxos de trabalho com múltiplas etapas, onde um agente que valida dados antes de prosseguir pode evitar uma cascata de erros. Técnicas como ajuste fino supervisionado (SFT), geração aumentada por recuperação (RAG) e pré-treinamento contínuo são complementares, mas geralmente não ensinam essas capacidades de tomada de decisão sequencial por conta própria.

O aprendizado por reforço multi-turno (RL multi-turno) preenche essa lacuna ao otimizar sequências inteiras de interação. Assim, os agentes aprendem orquestração de ferramentas, recuperação de erros e raciocínio em múltiplas etapas por tentativa e erro.

A solução da AWS: Nova Forge no HyperPod

O Amazon SageMaker AI já oferece RL multi-turno como uma capacidade totalmente gerenciada e sem servidor. Mas para quem precisa de controle total sobre a pilha de treinamento — ambiente de agente próprio, orquestração personalizada ou configurações específicas de instâncias — a AWS disponibilizou uma infraestrutura dedicada: o Amazon Nova Forge no Amazon SageMaker HyperPod.

O Amazon Nova Forge estende as capacidades do Amazon Nova com suporte a treinamento por RL multi-turno. O post da AWS descreve como implantar essa infraestrutura em duas fases, resultando em um pipeline orientado a eventos que inicia o treinamento automaticamente quando você faz upload de dados no Amazon S3. O exemplo prático usa o jogo Wordle como ambiente de recompensa — um substituto ilustrativo para qualquer tarefa de RL real.

Visão geral da arquitetura

A solução é um pipeline orientado a eventos composto por três camadas principais:

• Amazon SageMaker HyperPod (EKS): pods de treinamento e réplicas de geração vLLM rodando em instâncias P5. O modelo gera respostas e os pods de treinamento aplicam atualizações de peso usando o algoritmo GRPO (Otimização de Política Relativa de Grupo).
• ECS no AWS Fargate: workers de recompensa que executam o ambiente (por exemplo, Wordle ou um ambiente personalizado BYOO — Traga Seu Próprio Orquestrador). Eles recebem respostas do modelo via SQS, avaliam com base em critérios definidos e retornam os sinais de recompensa.
• Amazon Nova Forge SDK: a camada de proxy que roteia mensagens entre o modelo e o ambiente de recompensa, rastreando o estado da conversa entre os turnos.

O AWS Step Functions orquestra toda a execução, acionado pelo Amazon EventBridge quando um arquivo de dados chega ao S3.

Modelo de implantação em duas fases

A arquitetura separa recursos de longa duração dos recursos efêmeros de cada execução de treinamento. Isso reduz custos, acelera iterações e simplifica o gerenciamento.

Fase 1: Implantação via AWS CDK (única vez)

Ao executar cdk deploy, a infraestrutura de base é provisionada:

• Uma Nuvem Privada Virtual (Amazon VPC) com sub-redes privadas e endpoints de VPC
• Um cluster Amazon Elastic Kubernetes Service (Amazon EKS) com um Grupo de Instâncias Restritas (RIG) do HyperPod
• Um cluster Amazon Elastic Container Service (Amazon ECS) no AWS Fargate para workers de recompensa
• Um bucket Amazon S3 para dados de treinamento e checkpoints
• Funções do AWS Identity and Access Management (IAM)
• Um pipeline AWS Step Functions
• Regras do Amazon EventBridge

A implantação leva cerca de 30 a 40 minutos. A maior parte do tempo é gasta na criação do cluster EKS (~15 minutos), instalação do Helm chart do HyperPod via AWS CodeBuild (~5 minutos), provisionamento do cluster HyperPod (~15–25 minutos) e builds de imagens de container Lambda (~5 minutos).

Fase 2: Recursos de runtime (por execução de treinamento)

Quando você faz upload de um arquivo .jsonl no prefixo training-data/ do bucket S3, o EventBridge aciona o pipeline do Step Functions. O Nova Forge SDK implanta seu próprio stack AWS CloudFormation contendo:

• Funções AWS Lambda (proxy de conversação)
• Filas FIFO do Amazon Simple Queue Service (Amazon SQS) para roteamento de mensagens entre modelo e ambiente
• Uma tabela Amazon DynamoDB para rastreamento do estado da conversa
• Tasks ECS Fargate para os workers de recompensa

O SDK gerencia o ciclo de vida desses recursos automaticamente.

Pré-requisitos

Antes de implantar, a AWS lista os seguintes requisitos:

• Assinatura do Amazon Nova Forge: necessária para acessar o SDK e as APIs de treinamento
• Cota de instâncias SageMaker HyperPod: mínimo de 10 × ml.p5.48xlarge para 4 réplicas de geração; recomenda-se 12–14 para cargas de produção
• Ambiente CDK bootstrapped: execute cdk bootstrap antes do primeiro deploy
• Python 3.12+
• AWS CDK v2: instale com npm install -g aws-cdk
• AWS CLI v2 configurado com permissões para criar VPCs, clusters EKS, clusters HyperPod, funções IAM e Step Functions
• Docker: para build das imagens de container Lambda que empacotam o Nova Forge SDK

Atenção aos custos: esta infraestrutura custa aproximadamente US$ 786 a US$ 1.180 por hora quando em execução (10–12 instâncias ml.p5.48xlarge). Planeje destruir o stack quando não estiver treinando ativamente.

Implantando a infraestrutura

Clone e instalação

git clone https://github.com/aws-samples/sample-nova-multi-turn-rl-infra.git
cd nova-multi-turn-rl-infra
pip install -r requirements.txt

Configuração

Todos os parâmetros são definidos no arquivo cdk.json, na chave context. Dois parâmetros são obrigatórios antes do primeiro deploy:

• project_tag: prefixo único para todos os nomes de recursos (ex: my-nova-rl)
• sdk_resource_prefix: prefixo para recursos criados pelo SDK (ex: nrl-myproject)

Parâmetros-chave de infraestrutura incluem instance_type (padrão: ml.p5.48xlarge), instance_count (padrão: 10), nova_model (opções: NOVA_MICRO, NOVA_LITE, NOVA_LITE_2 ou NOVA_PRO) e vf_env_id (padrão: wordle). Para usar um ambiente personalizado, defina use_custom_env como true e especifique o diretório em custom-environments/.

Parâmetros de treinamento incluem training_method (RFT_MULTITURN_FULL ou RFT_MULTITURN_LORA), max_steps (padrão: 10), generation_replicas (padrão: 4) e global_batch_size (padrão: 64). Qualquer parâmetro pode ser sobrescrito no momento do deploy:

cdk deploy -c instance_count=1 -c max_steps=20

Deploy

cdk deploy --require-approval never

Acionando uma execução de treinamento

Formato dos dados de treinamento

O arquivo .jsonl usa um formato baseado em metadados — cada linha contém um prompt e a resposta correta que o ambiente de recompensa usa para pontuação:

{"id": "wordle_train_001", "metadata": {"prompt": "Guess the 5-letter word", "answer": "crane"}}
{"id": "wordle_train_002", "metadata": {"prompt": "Guess the 5-letter word", "answer": "slate"}}
{"id": "wordle_train_003", "metadata": {"prompt": "Guess the 5-letter word", "answer": "plumb"}}

O campo id deve ser único em todos os registros. O modelo vê o metadata.prompt no início de cada conversa, e o ambiente de recompensa usa o metadata.answer para pontuar as respostas ao longo dos turnos.

Upload e acionamento automático

# Obter o nome do bucket a partir dos outputs do CDK
BUCKET=$(aws cloudformation describe-stacks --stack-name NovaMultiTurnRlStack \
  --query "Stacks[0].Outputs[?OutputKey=='TrainingBucketName'].OutputValue" --output text)

# Upload: o pipeline inicia automaticamente
aws s3 cp training-data.jsonl s3://$BUCKET/training-data/training-data.jsonl

Acionamento manual para execuções avulsas

./scripts/setup.sh \
  --data-path s3://$BUCKET/training-data/training-data.jsonl \
  --max-steps 5 \
  --global-batch-size 32 \
  --training-method RFT_MULTITURN_LORA

Monitoramento e depuração

O console do Step Functions é o painel principal. Cada execução exibe o progresso passo a passo com tempo, dados de entrada/saída e histórico de tentativas. Cada etapa escreve em seu próprio grupo de logs no Amazon CloudWatch.

Durante a operação normal, cada etapa do Step Functions é concluída dentro de janelas esperadas: configuração de infraestrutura em 2–3 minutos, implantação de workers de recompensa em 1–2 minutos, validação de dados em menos de 1 minuto e envio do treinamento em 3–5 minutos.

Alertas de falha

Um tópico do Amazon SNS, criptografado com AWS KMS, publica notificações quando uma execução do Step Functions falha. Para se inscrever e receber alertas por e-mail:

# Obter o ARN do tópico a partir dos outputs do CDK
TOPIC_ARN=$(aws cloudformation describe-stacks --stack-name NovaMultiTurnRlStack \
  --query "Stacks[0].Outputs[?OutputKey=='AlertTopicArn'].OutputValue" --output text)

# Inscrever e confirmar via e-mail
aws sns subscribe \
  --topic-arn $TOPIC_ARN \
  --protocol email \
  --notification-endpoint your-team@example.com

Depuração de travamentos no treinamento

Se o pipeline iniciar mas o treinamento travar, a causa raiz geralmente está na camada de roteamento de mensagens entre o modelo e o ambiente de recompensa. O SDK oferece um diagnóstico integrado:

from rft_infra import check_all_queues
# Retorna contagens de mensagens (em voo, disponíveis, atrasadas) para todas as filas FIFO
check_all_queues()

Um backlog crescente na fila de requisições com fila de respostas vazia indica que os workers de recompensa não estão processando. O padrão inverso indica que o modelo não está consumindo recompensas.

Saúde do HyperPod

kubectl get pods -n kubeflow

Todos os pods devem exibir status Running ou Completed. Pods presos em Pending indicam capacidade insuficiente de instâncias. Pods em CrashLoopBackOff indicam erros no nível do container — verifique os logs com kubectl logs <pod-name> -n kubeflow.

Custos e limpeza

A tabela abaixo resume os custos por hora desta infraestrutura:

• SageMaker HyperPod 8 × ml.p5.48xlarge: ~US$ 786/hora (configuração mínima)
• SageMaker HyperPod 12 × ml.p5.48xlarge: ~US$ 1.180/hora (configuração de produção)
• Plano de controle EKS: US$ 0,10/hora
• NAT Gateway: ~US$ 0,045/hora
• Workers ECS Fargate: ~US$ 0,15–0,30/hora + transferência de dados
• S3, Lambda, CodeBuild, SQS, DynamoDB: negligível

Para consultar a precificação atual do Amazon Nova Forge, acesse a página de preços do Amazon Nova.

Para destruir o stack inteiro e evitar cobranças:

./cleanup.sh

Para destruir a infraestrutura mantendo os dados de treinamento no S3 (custos de armazenamento ainda se aplicam):

./cleanup.sh --retain-data

Para reduzir custos ociosos, a AWS sugere duas estratégias: escalar para zero com políticas de escalonamento automático em períodos de inatividade, e usar tipos de instâncias de menor custo durante as fases de configuração, transitando para instâncias de maior desempenho apenas quando o treinamento começar.

Próximos passos

Com a infraestrutura implantada, o próximo passo é substituir o ambiente Wordle pelo seu próprio agente que chama APIs ou executa fluxos de trabalho empresariais. O repositório de referência está disponível em aws-samples/nova-multi-turn-rl-infra.

Fonte

Deploying Multi-Turn RL Infrastructure for Amazon Nova on Amazon SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/deploying-multi-turn-rl-infrastructure-for-amazon-nova-on-amazon-sagemaker-hyperpod/)

O desafio do RL multi-turno

Treinar um agente para resolver tickets de suporte ou moderar conteúdo é bem diferente de treinar um modelo para responder a uma pergunta isolada. Em cenários multi-turno, o agente precisa ler instruções, chamar ferramentas, interpretar os resultados, decidir a próxima ação e, quando necessário, se recuperar de um erro antes de chegar a uma resposta final. É exatamente essa flexibilidade que torna o Aprendizado por Reforço (RL) agnóstico tão desafiador: quanto mais caminhos de ação disponíveis, maior a chance do modelo encontrar formas de satisfazer a recompensa sem realmente resolver a tarefa.

A AWS publicou um guia técnico detalhado sobre boas práticas para treinar agentes com Amazon SageMaker AI multi-turn RL (SageMaker AI MTRL) de forma confiável. Os exemplos ao longo do artigo são baseados no SOP-Bench, um benchmark da Amazon Science que avalia a capacidade de agentes resolverem tarefas baseadas em Procedimentos Operacionais Padrão (SOP) em 12 domínios de negócios.

O que o SageMaker AI MTRL oferece

O SageMaker AI MTRL fornece o loop de treinamento para tarefas agênticas. O agente pode rodar no Amazon Bedrock AgentCore, no Amazon Elastic Kubernetes Service (Amazon EKS), no Amazon Elastic Compute Cloud (Amazon EC2), no AWS Fargate ou em infraestrutura própria. A conexão é feita por um adaptador que expõe as ferramentas disponíveis ao servidor de rollout.

Entre os principais recursos do serviço estão:

• Interface modular agente-ambiente que mantém a integração com pouco código, mas oferece controle algorítmico completo.
• Execução serverless com precificação por token, sem necessidade de provisionar clusters de GPU.
• Rollout e coleta de trajetórias assíncronos com staleness off-policy limitado — geração e atualizações de gradiente correm em paralelo sem se afastar demais da política atual.
• Biblioteca nativa de algoritmos com Proximal Policy Optimization (PPO), Clipped Importance Sampling Policy Optimization (CISPO) e perdas de importance-sampling (IS), além de múltiplos estimadores de vantagem baseados em grupo (GRPO, GRPO pass@k, RLOO, entre outros).
• Treinamento com extensão de sequência para manter o tempo de execução razoável em trajetórias longas.
• Observabilidade de trajetórias e recompensas via MLflow gerenciado pelo Amazon SageMaker AI.

Construa um ambiente de treinamento confiável

RL de turno único precisa apenas de um prompt e uma função de recompensa. O RL multi-turno exige também um ambiente com o qual o agente interage ao longo dos turnos — as ferramentas que ele chama e os sistemas por trás delas. Esse ambiente faz parte da configuração de treinamento e influencia diretamente o que o modelo aprende e se as métricas são confiáveis.

A recomendação da AWS é construir um ambiente sandboxed ou simulado que replique a produção, mas permaneça isolado do tráfego real. Um treinamento típico gera milhares de rollouts, cada um com várias chamadas de ferramentas — por exemplo, um batch de 128 com group size 8 resulta em 1.024 rollouts por passo. Apontar esse volume para sistemas reais pode causar impacto em clientes e gerar efeitos colaterais indesejados, como reembolsos disparados, registros deletados ou fluxos acionados por engano.

Três padrões cobrem a maioria dos casos de uso:

• Ferramentas somente leitura: replique respostas gravadas indexadas pelos argumentos de entrada. No SOP-Bench, por exemplo, dez ferramentas mockadas retornam respostas determinísticas a partir de fixtures.
• Ferramentas com estado: sandboxes com estado inicializado por seed, válido pelo tempo de um episódio. Recursos são alocados no início do rollout e destruídos em um bloco try/finally ao final, sem vazamento de estado entre episódios.
• Resultados verificáveis: execução real em ambiente isolado. Para código, SQL ou matemática, é possível usar Docker exec, SQLite em memória por rollout ou eval Python puro. O AgentCore Code Interpreter oferece ambientes gerenciados e isolados para execução de código.

Independentemente do padrão escolhido, duas propriedades devem ser mantidas: reprodutibilidade (a mesma ferramenta com os mesmos argumentos retorna sempre o mesmo resultado) e representatividade (o ambiente deve ser construído a partir dos schemas e distribuições de dados reais de produção).

Configure uma avaliação externa antes de treinar

Antes de escrever qualquer função de recompensa, é essencial ter uma forma independente de medir o sucesso. O RL otimiza literalmente o sinal de recompensa — se a recompensa for o único número monitorado, não é possível separar progresso real na tarefa de progresso em satisfazer os critérios de recompensa.

A recomendação é criar uma avaliação externa em um conjunto de teste fixo, calculada de forma independente da recompensa. No SOP-Bench, essa avaliação é um match exato no objeto JSON final dentro das tags <final_output>: todos os campos precisam corresponder ao ground truth, ou o rollout recebe zero.

Antes de qualquer treinamento, é importante estabelecer uma baseline: rodar o modelo base e um modelo de referência (como um modelo frontier hospedado no Amazon Bedrock) pela mesma avaliação. Isso mostra o quanto o modelo base precisa evoluir e o que “bom” significa para aquela tarefa específica.

Um anti-padrão comum é usar a recompensa de treinamento como medida de sucesso. Agentes multi-turno são especialmente suscetíveis a isso: uma recompensa que paga por chamadas de ferramentas ensina o agente a chamar o máximo de ferramentas possível; uma recompensa que penaliza o número de turnos ensina o agente a responder antes de ter as informações necessárias. Em ambos os casos, a recompensa de treinamento sobe, mas o sucesso real na tarefa cai.

Desenhando uma boa função de recompensa multi-turno

O design de recompensa é um dos problemas mais desafiadores em RL. A mesma flexibilidade que permite ao agente resolver uma tarefa real também permite que ele encontre formas de satisfazer a recompensa sem resolver a tarefa. O modelo otimiza exatamente o que foi escrito, não o que foi intencionado.

A orientação padrão é usar a mesma regra de pontuação para treinamento e avaliação, desviando apenas quando há uma razão concreta. Existem dois motivos legítimos para usar uma recompensa mais densa:

• Razão algorítmica: uma pontuação binária pode colapsar a variância entre rollouts de um grupo. Quando todos os rollouts de um grupo pontuam igual, o sinal relativo é zero e o grupo não contribui com gradiente.
• Velocidade de convergência: uma recompensa densa dá ao modelo gradiente em direção ao progresso parcial em cada rollout, não apenas nos que tiveram sucesso completo.

O artigo apresenta um exemplo de recompensa densa por campo para o SOP-Bench:

class SOPBenchReward:
    """Dense per-field reward for the SOP-Bench aircraft-inspection task.
    Returns a scalar in [0, 1] plus a metrics dict surfaced in MLflow."""
    ground_truth: dict[str, str]
    format_coef: float = 0.1  # format is a small shaping term, not the objective

    async def __call__(self, history: list[Message]) -> tuple[float, dict[str, float]]:
        fields = parse_final_output(last_assistant(history))  # JSON inside <final_output>
        emitted = float(fields is not None)
        if fields is None:  # no parseable answer
            return self.format_coef * (emitted - 1), {"completion": 0.0, "field_acc": 0.0}
        matched = sum(1 for k, v in self.ground_truth.items()
                      if str(fields.get(k)).strip().lower() == str(v).strip().lower())
        field_acc = matched / len(self.ground_truth)  # partial credit: 5/6 > 0
        reward = field_acc + self.format_coef * (emitted - 1)  # correctness dominates
        return reward, {"completion": emitted, "field_acc": field_acc}

Um ponto crítico destacado no artigo: um parser de recompensa mais permissivo do que a avaliação é em si uma forma de reward hacking. Em um dos testes com o SOP-Bench, o parser de recompensa aceitava um wrapper <final_response> enquanto o benchmark só lia <final_output>. O modelo aprendeu exatamente o que foi pedido: a recompensa de treinamento subiu, mas a avaliação externa caiu.

Para mais detalhes sobre design de recompensa, recompensas esparsas vs. densas e modelos juízes, a AWS disponibiliza as melhores práticas de design de recompensa do SageMaker AI.

Gerenciando contexto e orçamento de turnos

Agentes multi-turno precisam lidar com questões que o RL de turno único não enfrenta. Cada chamada de ferramenta estende a conversa — o call, os argumentos, o resultado e o raciocínio do modelo entre eles. Trajetórias longas acumulam contexto rapidamente.

Dois orçamentos limitam isso: max_turns (controlado pelo loop do agente) e o orçamento de tokens por turno (definido via sampling_max_tokens para rollout e val_sampling_params.sampling_max_tokens para avaliação). A recomendação é calibrar ambos para o que a tarefa exige. No SOP-Bench, oito turnos e 2.048 tokens por turno cobrem o procedimento canônico com margem.

Uma regra prática: se um walkthrough humano da tarefa leva N turnos, defina max_turns = ceil(N * 1.5) no loop do agente. Se mais de 5% dos rollouts atingem o limite de sampling_max_tokens, aumente esse valor — caso contrário, o modelo aprende de trajetórias truncadas sem ver a recompensa que teria recebido ao terminar.

Separando conclusão de correção

Uma trajetória que termina com a resposta errada e uma que nunca termina são falhas diferentes. Confundi-las esconde onde o modelo está quebrando. As métricas das famílias rollout e val no MLflow fornecem ambos os sinais separadamente:

• rollout/reward/mean: recompensa média das trajetórias
• rollout/reward/zero_frac: fração de trajetórias que pontuaram exatamente zero
• rollout/turns/mean: média de turnos por trajetória
• analysis/zero_adv_groups: grupos onde todos os rollouts pontuaram igual, desperdiçando rollouts
• val/reward/mean: recompensa média de validação
• val/reward/pass_k_1, pass_k_8: pass@1 e pass@k no conjunto de validação

Um val/reward/pass_k_1 alto com baixa taxa de conclusão indica que o modelo acerta os casos fáceis, mas trava nos difíceis — sugerindo ajuste no orçamento de turnos. Uma alta taxa de conclusão com val/reward/pass_k_1 baixo indica que o agente responde com fluência, mas de forma errada — sugerindo redesenho da recompensa.

Monitorando o treinamento e iterando

O SageMaker AI MTRL disponibiliza os construtores MultiTurnRLTrainer e MultiTurnRLEvaluator para treinar e avaliar o agente. Para avaliação de modelos base e fine-tuned, a documentação de avaliação de modelos traz orientações detalhadas.

Durante o treinamento, o sinal mais importante é a divergência: quando rollout/reward/mean sobe mas val/reward/mean permanece estável, a recompensa está sendo hackeada. A recomendação é abrir as trajetórias no MLflow e comparar o que a recompensa creditou com o que a avaliação pontuou.

O artigo relata dois experimentos reais com o SOP-Bench. No primeiro, o treinamento foi feito com todas as tarefas ao mesmo tempo, o que levou tarefas a competirem entre si e a recompensa a oscilar sem convergir:

Ao limitar o treinamento à tarefa aircraft_inspection, a recompensa de rollout saturou em torno de 3,7 (com máximo de 5,0), enquanto a recompensa de validação caiu. A investigação das trajetórias revelou dois problemas: o exemplo one-shot do SOP omitia um campo obrigatório (cross_check_response) e usava uma tag de saída diferente da esperada pelo benchmark:

Após alinhar o exemplo com os dados e remover o campo sem resposta possível, tanto a recompensa de treinamento quanto a de validação convergiram de forma saudável. O resultado foi um aumento de 13% na Taxa de Sucesso de Tarefas (TSR) e aproximadamente 16% de crescimento na acurácia por campo no benchmark externo:

O loop de iteração recomendado

O artigo propõe uma sequência clara de etapas para o treinamento:

1. Coletar dados representativos da tarefa e dividir em conjuntos de treino, validação e teste.
2. Construir o ambiente de treinamento a partir dos schemas de produção: hermético, com seed, reproduzível.
3. Configurar a avaliação externa sobre o conjunto de teste, calculada de forma independente da recompensa.
4. Estabelecer baseline rodando o modelo base e um modelo de referência frontier pela avaliação.
5. Desenhar a recompensa e validá-la em saídas reais do modelo antes de qualquer treinamento.
6. Treinar monitorando rollout/reward, taxa de conclusão e uma amostra de trajetórias.
7. Avaliar o modelo treinado com a avaliação externa e ler as trajetórias onde recompensa e avaliação divergem.
8. Ajustar recompensa, ambiente ou dados e repetir.

Para situações em que a curva trava ou colapsa, o artigo oferece um guia de diagnóstico por sintoma — por exemplo, se a recompensa de treinamento sobe mas val/reward/mean fica estável, o sinal é de reward hacking e o parser de recompensa precisa ser ajustado. A recomendação é fazer uma mudança por vez e observar as métricas por 25 a 50 passos de treinamento antes de decidir o próximo ajuste.

Conclusão

A qualidade da recompensa e da avaliação é o que determina se o treinamento produz um agente útil — muito mais do que o algoritmo ou os hiperparâmetros. O SageMaker AI MTRL cuida da maior parte do trabalho operacional de um treinamento de RL agêntico distribuído, abstraindo hardware, orquestração e o engine de treinamento. O que fica a cargo do time é o que realmente importa: ambiente preciso, design de recompensa e avaliação alinhada com o objetivo final.

Para começar, a AWS disponibiliza um notebook de exemplo para configuração do MTRL, a documentação do SageMaker AI multi-turn RL, as melhores práticas de design de recompensa e um post sobre GRPO com recompensas verificáveis. O paper e dataset do SOP-Bench são a fonte dos exemplos práticos usados ao longo do artigo.

Fonte

Best practices for multi-turn reinforcement learning in Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/best-practices-for-multi-turn-reinforcement-learning-in-amazon-sagemaker-ai/)

O que mudou no SageMaker HyperPod

A AWS anunciou duas novas capacidades para o Amazon SageMaker HyperPod, infraestrutura projetada especificamente para treinamento e implantação de modelos de fundação em escala: versionamento de AMI (Imagem de Máquina da Amazon — AMI) e aplicação automática de patches de segurança. As novidades chegam para resolver dores operacionais reais que afetavam administradores de clusters de IA/ML.

O problema que existia antes

Até então, os administradores de clusters HyperPod tinham visibilidade limitada sobre quais versões de AMI estavam rodando em cada instância. Isso tornava difícil detectar desvios de configuração entre nós e transformava a aplicação de patches de segurança em um processo manual e reativo.

O cenário era especialmente complicado em jobs de treinamento que duram vários dias: qualquer intervenção manual corria o risco de alterar componentes críticos do stack de software embutidos na AMI, como drivers NVIDIA e o CUDA — mudanças que poderiam quebrar workloads em andamento.

As duas novas capacidades em detalhe

Versionamento de AMI

Com o versionamento de AMI, agora é possível visualizar a versão exata da AMI em cada grupo de instâncias e em cada nó do cluster, no formato de versionamento semântico major.minor.patch. Isso facilita a detecção rápida de desvios de versão entre nós. Além disso, caso seja necessário reverter uma atualização, é possível fazer rollback para uma versão anterior — incluindo o driver NVIDIA, o CUDA e todo o restante do stack de software — por meio da API UpdateClusterSoftware.

Auto-patching (aplicação automática de patches)

O auto-patching é uma funcionalidade opcional, configurável por grupo de instâncias, que aplica apenas patches de segurança retrocompatíveis. A aplicação ocorre somente quando os nós estão ociosos, garantindo que os workloads em execução não sejam interrompidos. Um ponto importante: pacotes críticos de IA/ML, como o driver NVIDIA, a versão do CUDA e os kernels do sistema operacional, nunca são atualizados para uma versão major ou minor diferente — apenas patches dentro da mesma versão são aplicados. O recurso pode ser habilitado pelas APIs CreateCluster ou UpdateCluster.

Nova política de suporte a AMIs

A AWS também publicou uma nova política de suporte a AMIs, que define os prazos de suporte para cada versão. Após esses prazos, o HyperPod deixa de publicar patches de segurança para aquela versão específica — o que torna o acompanhamento do versionamento ainda mais relevante para equipes de operações.

Disponibilidade

Tanto o versionamento de AMI quanto o auto-patching já estão disponíveis para clusters HyperPod orquestrados pelo Amazon EKS (Elastic Kubernetes Service), em todas as regiões AWS onde o SageMaker HyperPod é suportado.

Para saber mais, consulte a documentação de gerenciamento de AMI do HyperPod e a política de suporte a AMI do HyperPod.

Fonte

Amazon SageMaker HyperPod now supports AMI versioning and auto-patching (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-sagemaker-hyperpod-ami-version-auto-patch)

O que foi anunciado

A AWS anunciou que o Amazon SageMaker Unified Studio agora oferece suporte ao Terraform para provisionamento de infraestrutura. Com isso, equipes de plataforma podem utilizar o módulo open-source terraform-aws-sagemaker-unified-studio para implantar um domínio do SageMaker Unified Studio por meio de templates com controle de versão.

O que é o SageMaker Unified Studio

Para quem ainda não conhece, o Amazon SageMaker Unified Studio é um ambiente de desenvolvimento unificado onde equipes de dados conseguem construir fluxos de trabalho completos de dados e Inteligência Artificial (IA) — desde integração de dados e analytics até aprendizado de máquina e IA generativa — tudo isso governado por um catálogo compartilhado.

Administradores provisionam domínios para oferecer à organização um workspace único e gerenciado, com controle de acesso integrado, governança de dados e conectividade entre serviços.

O que muda na prática

Com esse lançamento, equipes de plataforma podem incorporar o SageMaker Unified Studio aos seus pipelines de Infraestrutura como Código (IaC) já existentes, mantendo consistência entre as contas de desenvolvimento, homologação e produção.

O módulo Terraform cuida da infraestrutura do domínio do SageMaker Unified Studio com as funções do Gerenciamento de Identidade e Acesso (IAM) já provisionadas. Além disso, submódulos permitem que as equipes:

• Habilitem blueprints;
• Combinem blueprints em perfis de projeto;
• Criem projetos de forma independente.

Também é possível criar projetos utilizando funções IAM já existentes — o que facilita a adoção por times que já possuem estruturas de permissões consolidadas.

Integração com o Terraform AWS Cloud Control Provider

Essa integração é viabilizada pelo Terraform AWS Cloud Control Provider, que permite ao Terraform interagir com recursos da AWS por meio da API Cloud Control, garantindo acesso a funcionalidades mais recentes da plataforma.

Disponibilidade

O recurso está disponível em todas as regiões da AWS onde o Amazon SageMaker Unified Studio está disponível.

Para começar, a AWS disponibiliza exemplos no módulo terraform-aws-sagemaker-unified-studio no GitHub, além da documentação oficial do Amazon SageMaker Unified Studio.

Fonte

Amazon SageMaker Unified Studio now supports Terraform for provisioning (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-sagemaker-unified-studio-terraform/)