GPT-5.6 no Amazon Bedrock: três modelos, um endpoint

A AWS anunciou a disponibilidade geral dos modelos GPT-5.6 Sol, Terra e Luna no Amazon Bedrock. A proposta é direta: desenvolvedores que precisam de modelos de fronteira para workloads de codificação agêntica, raciocínio de longa duração e inferência de alto volume agora podem acessá-los pela API familiar da OpenAI, sem precisar operar infraestrutura de modelos separada.

O GPT-5.6 introduz um sistema de nomenclatura onde o número identifica a geração e os nomes Sol, Terra e Luna identificam camadas de capacidade duráveis que podem evoluir de forma independente. A tabela abaixo resume as especificações de cada modelo:

• Sol (openai.gpt-5.6-sol): ideal para codificação autônoma, pesquisa de segurança, análise científica e raciocínio profundo em múltiplos passos. Disponível em US East (N. Virginia) e US East (Ohio).
• Terra (openai.gpt-5.6-terra): equilibra raciocínio, desempenho e custo para workloads de produção de uso geral. Disponível em US East (N. Virginia), US East (Ohio) e US West (Oregon).
• Luna (openai.gpt-5.6-luna): otimizado para workloads de alto volume e baixa latência, como classificação, sumarização e roteamento. Disponível nas mesmas regiões do Terra.

Os três modelos suportam entrada de texto e imagem, saída de texto, uma janela de contexto de 272 mil tokens e a Responses API. Todos também suportam os níveis de esforço de raciocínio: none, low, medium, high, xhigh e max. O preço corresponde às tarifas de primeira parte da OpenAI, e o uso conta para os compromissos existentes da AWS.

Acessando o GPT-5.6 pelo endpoint bedrock-mantle

O acesso aos modelos GPT-5.6 é feito pela Responses API da OpenAI no endpoint bedrock-mantle. A URL base é https://bedrock-mantle.{region}.api.aws, e a Responses API fica em /openai/v1/responses. Basta substituir {region} pela região AWS desejada, como us-east-1.

O endpoint funciona com os SDKs Python e TypeScript da OpenAI. Para migrar uma aplicação existente, basta substituir a URL base da OpenAI pelo endpoint bedrock-mantle, usar o ID do modelo correspondente no Amazon Bedrock e autenticar com uma chave de API do Amazon Bedrock ou credenciais AWS.

Segurança e controle de dados

Cada chamada de modelo é executada sob as políticas do AWS Identity and Access Management (IAM), dentro da sua nuvem privada virtual (VPC) e registrada no AWS CloudTrail. A inferência em região mantém as requisições dentro da região AWS especificada, o que ajuda equipes a atender requisitos de residência de dados.

Por serem modelos de terceiros, o GPT-5.6 Sol, Terra e Luna estão sujeitos a os termos da OpenAI. Para esses modelos, tráfego sinalizado por classificadores é retido por até 30 dias para detecção de abuso automatizada offline. As entradas e saídas retidas são armazenadas e processadas pela AWS e não são compartilhadas com o provedor do modelo, a menos que você opte por isso. O controle da configuração de retenção é feito pelo modo de retenção de dados. Vale destacar que seus prompts e respostas não são usados para treinar modelos.

Primeiros passos: pré-requisitos e autenticação

Para usar os modelos GPT-5.6, é necessário uma conta AWS com permissões para executar inferências no endpoint bedrock-mantle. Uma forma de conceder essas permissões é anexar a política gerenciada AmazonBedrockMantleInferenceAccess ao seu principal do IAM. Ela concede acesso de leitura e criação de inferências, incluindo bedrock-mantle:CreateInference e bedrock-mantle:CallWithBearerToken.

Instale o SDK Python da OpenAI, versão 2.45.0 ou superior:

pip install "openai>=2.45.0"

A autenticação pode ser feita de duas formas:

Chave de curta duração com atualização automática: o cliente nativo BedrockOpenAI do SDK usa um provedor de token que gera uma chave de curta duração a partir das credenciais AWS e a atualiza antes de cada requisição. Os exemplos deste artigo usam esse cliente.

from aws_bedrock_token_generator import provide_token
from openai import BedrockOpenAI

region = "us-east-1"
client = BedrockOpenAI(
    aws_region=region,
    bedrock_token_provider=lambda: provide_token(region=region),
)

Chave de curta duração via variável de ambiente: defina a chave em AWS_BEARER_TOKEN_BEDROCK e passe-a ao cliente. Como essa chave não é atualizada automaticamente, ela expira em no máximo 12 horas. Para produção, prefira a opção com atualização automática ou armazene a chave no AWS Secrets Manager.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://bedrock-mantle.us-east-1.api.aws/openai/v1",
    api_key=os.environ["AWS_BEARER_TOKEN_BEDROCK"],
)

Executando a primeira inferência com a Responses API

Com o cliente configurado, é possível chamar o GPT-5.6 Terra pela Responses API. A API usa um único campo input e retorna o texto gerado em output_text.

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    input="Explain the benefits of prompt caching for agentic workloads.",
    max_output_tokens=512,
    store=False,
)
print(response.output_text)

Controlando o esforço de raciocínio

Os modelos GPT-5.6 podem gastar tokens adicionais de raciocínio em tarefas complexas de múltiplos passos antes de responder, o que melhora os resultados mas aumenta a latência e o custo. O nível é definido com o parâmetro reasoning.

response = client.responses.create(
    model="openai.gpt-5.6-sol",
    input="A train leaves at 3 PM at 60 km/h. Another leaves an hour later at "
         "90 km/h from the same station. When does the second catch up?",
    reasoning={"effort": "high"},
)
print(response.output_text)

Chamando ferramentas (tool calling)

O GPT-5.6 suporta chamada de ferramentas, permitindo que o modelo solicite ferramentas definidas pela aplicação e use seus resultados para completar uma requisição. O exemplo abaixo demonstra a chamada de ferramenta no lado do cliente, onde a aplicação executa a ferramenta e retorna o resultado ao modelo.

import json

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

# Step 1: Send the user request with the tool definition.
input_list = [{"role": "user", "content": "What's the weather like in Seattle?"}]
response = client.responses.create(
    model="openai.gpt-5.6-terra",
    input=input_list,
    tools=tools,
)

# Step 2: Carry the model's output (including any reasoning items) into the next turn.
input_list += response.output

# Step 3: Run each requested function and append its result.
for item in response.output:
    if item.type == "function_call":
        args = json.loads(item.arguments)
        result = {
            "location": args["location"],
            "temperature": 64,
            "condition": "Partly cloudy",
        }
        input_list.append(
            {
                "type": "function_call_output",
                "call_id": item.call_id,
                "output": json.dumps(result),
            }
        )

# Step 4: Ask the model for the final response, incorporating the tool result.
final_response = client.responses.create(
    model="openai.gpt-5.6-terra",
    input=input_list,
    tools=tools,
)
print(final_response.output_text)

Como os modelos GPT-5.6 raciocinam antes de responder, é importante passar os itens de saída do modelo (que podem incluir raciocínio) de volta na próxima requisição, como o exemplo acima faz ao acrescentar response.output à lista de entrada. Para implantações em produção, a AWS recomenda usar o Amazon Bedrock Guardrails para implementar salvaguardas personalizadas às suas políticas de IA responsável.

Reduzindo custos com cache de prompts

Workloads agênticos e de múltiplos passos repetem grande parte do contexto entre chamadas — instruções de sistema, definições de ferramentas e arquivos de referência costumam permanecer iguais enquanto apenas a entrada mais recente muda. O GPT-5.6 suporta cache de prompts em dois modos no Amazon Bedrock.

• Cache implícito: ativado por padrão. Requisições elegíveis são cacheadas automaticamente sem alterações no código.
• Cache explícito: permite marcar pontos de quebra de cache para controle preciso sobre quais partes do prompt são cacheadas.

Em ambos os modos, o cache reduz o custo de processar repetidamente contextos compartilhados conforme o volume de requisições cresce. Tokens de entrada cacheados são cobrados com 90% de desconto em relação a tokens não cacheados, e tokens gravados no cache são cobrados a 1,25 vezes a taxa de entrada não cacheada. Consulte a página de preços do Amazon Bedrock para valores atualizados. O conteúdo cacheado fica disponível por pelo menos 30 minutos.

Cache explícito com pontos de quebra

Para cachear um prefixo, adicione um prompt_cache_breakpoint ao bloco de conteúdo que encerra a seção reutilizável e defina prompt_cache_options para o modo explícito. Definir um prompt_cache_key consistente entre requisições direciona-as ao mesmo cache e melhora a confiabilidade de correspondência. Cada ponto de quebra requer um prefixo de pelo menos 1.024 tokens, e é possível definir até quatro pontos de quebra de cache por requisição.

# Replace with your real system instructions and reference content.
# The cached prefix must be at least 1,024 tokens, or nothing is cached.
system_prompt = "You are a technical support agent for Example Corp. ...(1,024+ tokens)..."

def ask(question):
    return client.responses.create(
        model="openai.gpt-5.6-terra",
        prompt_cache_key="support-agent:system-prompt-v1",
        prompt_cache_options={"mode": "explicit"},
        input=[
            {
                "type": "message",
                "role": "developer",
                "content": [
                    {
                        "type": "input_text",
                        "text": system_prompt,
                        # Cache everything up to this breakpoint (the system instruction).
                        "prompt_cache_breakpoint": {"mode": "explicit"},
                    }
                ],
            },
            {
                "type": "message",
                "role": "user",
                "content": [{"type": "input_text", "text": question}],
            },
        ],
    )

# First call: writes the prefix to cache.
first = ask("How do I configure single sign-on?")
print("write:", first.usage.input_tokens_details.cache_write_tokens)

# Second call with the same prefix and cache key: read the prefix from cache.
second = ask("How do I reset a password?")
print("read: ", second.usage.input_tokens_details.cached_tokens)
print(second.output_text)

Cache implícito

Se prompt_cache_options não for definido, o GPT-5.6 usa o cache implícito. O Amazon Bedrock coloca automaticamente um ponto de quebra de cache na mensagem mais recente e respeita quaisquer pontos de quebra explícitos adicionados. A recomendação é manter o conteúdo estático (instruções de sistema, definições de ferramentas, documentos de referência) no início do prompt e o conteúdo variável no final, além de definir um prompt_cache_key consistente para requisições relacionadas.

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    prompt_cache_key="support-agent:kb-v1",
    input=[
        {
            "type": "message",
            "role": "developer",
            # Static content first so it forms a stable, cacheable prefix.
            "content": [{"type": "input_text", "text": system_prompt}],
        },
        {
            "type": "message",
            "role": "user",
            "content": [{"type": "input_text", "text": "How do I configure single sign-on?"}],
        },
    ],
)
print(response.output_text)

O cache explícito é mais adequado para loops agênticos com um prefixo grande e estável, onde se deseja controle total sobre o que é cacheado. O cache implícito é mais simples e se adapta bem a workloads de chat e RAG (Geração Aumentada por Recuperação) com um prefixo naturalmente estável. A cobrança é a mesma nos dois modos. Para desativar o cache em uma requisição, defina prompt_cache_options para o modo explícito sem adicionar nenhum ponto de quebra.

Monitorando a taxa de acerto do cache

Cada resposta reporta a atividade de cache no objeto usage. O campo input_tokens_details.cached_tokens indica o número de tokens lidos do cache, e cache_write_tokens indica os gravados. Como cached_tokens já faz parte do total de input_tokens, a taxa de acerto do cache pode ser calculada dividindo cached_tokens por input_tokens.

usage = response.usage
details = usage.input_tokens_details
cached = getattr(details, "cached_tokens", 0) or 0
cache_write = getattr(details, "cache_write_tokens", 0) or 0
total_input = usage.input_tokens
hit_rate = cached / total_input if total_input else 0.0

print(f"Cached tokens: {cached}")
print(f"Written tokens: {cache_write}")
print(f"Total input: {total_input}")
print(f"Cache hit rate: {hit_rate:.1%}")

O endpoint bedrock-mantle publica métricas de tokens de conta, projeto e modelo no Amazon CloudWatch sob o namespace AWS/BedrockMantle, mas não publica uma métrica específica de cache — portanto, o objeto de uso da resposta é a fonte oficial para medir o desempenho do cache.

Usando o GPT-5.6 com o Codex

O Codex é o agente de codificação da OpenAI para desenvolvedores. Ele trabalha com arquivos locais, repositórios, terminais e ambientes de desenvolvimento para escrever funcionalidades, corrigir bugs, executar testes e abrir pull requests. É possível executá-lo pela linha de comando (Codex CLI), como extensão de IDE para Visual Studio Code e JetBrains, ou no aplicativo desktop do ChatGPT.

Para apontar o Codex para o Amazon Bedrock, basta definir o modelo e o provedor no arquivo ~/.codex/config.toml:

model = "openai.gpt-5.6-sol"
model_provider = "amazon-bedrock"

[model_providers.amazon-bedrock.aws]
region = "us-east-1"

O Codex autentica com uma chave de API ou com as credenciais do SDK AWS. Se AWS_BEARER_TOKEN_BEDROCK estiver definido, o Codex o usa primeiro; caso contrário, recorre à cadeia de credenciais do SDK AWS. O aplicativo desktop do ChatGPT e a extensão de IDE podem não herdar o ambiente do shell, então é recomendável colocar as variáveis necessárias em ~/.codex/.env:

AWS_BEARER_TOKEN_BEDROCK=<your-api-key>

Reinicie o aplicativo ou a extensão após alterar ~/.codex/config.toml ou ~/.codex/.env. Para tarefas de codificação, esforços de raciocínio mais altos são adequados para refatorações e depurações complexas, enquanto níveis mais baixos mantêm edições rotineiras rápidas. No aplicativo desktop do ChatGPT, é possível escolher entre Light, Medium, High e Extra High para cada tarefa.

Cotas e escalonamento

As requisições aos modelos GPT-5.6 usam inferência sob demanda no nível de serviço Standard, onde se paga por token sem reservar capacidade. A inferência no endpoint bedrock-mantle é governada por duas cotas por modelo e por região: uma para tokens de entrada por minuto e outra para tokens de saída por minuto. Não há cota de requisições por minuto.

Tokens de entrada cacheados lidos pelo cache de prompts não contam para a cota de tokens de entrada por minuto — mais um motivo pelo qual o cache ajuda em escala. Se uma cota de tokens por minuto for excedida, o endpoint retorna uma resposta HTTP 429. A recomendação é tratar throttling transitório com backoff exponencial e um contador limitado de tentativas, que o SDK da OpenAI suporta pela configuração max_retries:

from aws_bedrock_token_generator import provide_token
from openai import BedrockOpenAI

region = "us-east-1"
client = BedrockOpenAI(
    aws_region=region,
    bedrock_token_provider=lambda: provide_token(region=region),
    max_retries=6,
)

Para reduzir o throttling em alto volume sustentado, distribua workloads grandes ao longo de vários minutos em vez de disparar em rajadas rápidas. Para mais detalhes, consulte as cotas para o endpoint bedrock-mantle.

Limpeza e custos

A inferência sob demanda gera cobranças apenas quando um modelo é invocado, portanto não há infraestrutura para desativar. Se uma chave de API de curta duração foi gerada, ela expira automaticamente em até 12 horas. Para revogar uma chave antes disso, exclua-a no novo console do Amazon Bedrock. Cada invocação de modelo gera cobranças por token — consulte a tabela de preços do Amazon Bedrock para valores atualizados.

Próximos passos

Para quem quer explorar os modelos GPT-5.6 no Amazon Bedrock, a AWS sugere os seguintes passos iniciais:

• Abra o novo console do Amazon Bedrock, crie um projeto e avalie um modelo GPT-5.6 com seus próprios prompts.
• Execute o exemplo da Responses API com seus próprios dados.
• Adicione um ponto de quebra de cache explícito a um prefixo de prompt repetido e meça a taxa de acerto do cache.
• Avalie Sol, Terra e Luna nos seus workloads para escolher a variante que melhor se adequa ao seu perfil de custo e latência.

Para mais informações, consulte a documentação do Amazon Bedrock, os cards de modelo OpenAI no Amazon Bedrock, o guia de cache de prompts para inferência mais rápida e as cotas para o endpoint bedrock-mantle.

Fonte

Get started with OpenAI GPT-5.6 Sol, Terra, and Luna on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/get-started-with-openai-gpt-5-6-sol-terra-and-luna-on-amazon-bedrock/)

O desafio de recomendar produtos bancários com inteligência

Bancos acumulam volumes enormes de dados sobre seus clientes: histórico de transações, produtos contratados, perfil demográfico e padrões de comportamento. Transformar tudo isso em recomendações personalizadas e acionáveis, no entanto, continua sendo um dos maiores desafios do setor. Sistemas baseados em regras e abordagens tradicionais de filtragem colaborativa frequentemente não conseguem capturar os padrões temporais complexos presentes na jornada de adoção de produtos por parte dos clientes.

Para endereçar esse problema, a AWS publicou uma visão arquitetural completa de um sistema de recomendação de Próximo Melhor Produto — ou Próximo Melhor Produto (NBP) — voltado ao setor bancário. A solução usa Amazon SageMaker AI e PyTorch, com foco em precisão e, principalmente, em explicabilidade — requisito fundamental para atender a reguladores financeiros.

Vale reforçar: este é um guia de arquitetura e decisões de design, não um tutorial passo a passo de implantação.

Visão geral da solução

A solução é construída sobre uma arquitetura de aprendizado profundo com quatro torres neurais especializadas, cada uma processando um tipo diferente de dado do cliente. As saídas dessas torres são combinadas por um mecanismo de atenção aprendida, que oferece tanto alta acurácia quanto explicabilidade por cliente.

O objetivo central é prever qual produto um cliente tem maior probabilidade de contratar a seguir — entre categorias como cartão de crédito, depósitos, seguros, empréstimos e financiamentos imobiliários — enquanto fornece justificativas compreensíveis para os resultados, satisfazendo exigências regulatórias.

Stack tecnológica

A arquitetura combina diversos serviços e bibliotecas com papéis bem definidos:

• Processamento e Transformação, Extração e Carregamento de Dados (ETL): AWS Glue com PySpark para unificação e engenharia de features em escala
• Framework de aprendizado profundo: PyTorch com grafos de computação dinâmicos e suporte nativo a GPU
• Engenharia de features: Pandas, Dask e PyArrow para agregações temporais e criação de sequências
• Utilitários de ML: scikit-learn para codificação, normalização e avaliação
• Computação de treinamento: SageMaker AI com instâncias ml.g5.12xlarge (192 GB de RAM, 4× GPUs NVIDIA A10G)
• Armazenamento: Amazon S3 com arquivos Parquet comprimidos com Snappy
• Catálogo de dados: AWS Glue Data Catalog para gerenciamento de esquemas
• Registro de modelos: SageMaker AI model registry com versionamento e fluxos de aprovação
• Inferência: SageMaker AI Batch Transform e endpoints em tempo real
• Orquestração: Amazon SageMaker Pipelines para o pipeline de ML de ponta a ponta
• Monitoramento: Amazon CloudWatch para métricas de treinamento, latência de inferência e detecção de drift

A escolha do PyTorch se justifica pelos grafos de computação dinâmicos — necessários para sequências de comprimento variável com pack_padded_sequence — além da integração nativa com jobs de treinamento e contêineres de inferência do SageMaker AI. Já o formato Parquet no S3 oferece vantagens como leitura colunar seletiva, pushdown de predicados, compressão de 3 a 5 vezes em relação ao CSV e preservação de tipos sem necessidade de reprocessamento.

Pipeline de dados

O pipeline de dados é dividido em duas etapas principais.

Unificação de dados com AWS Glue

Dados bancários geralmente chegam de múltiplos sistemas com esquemas inconsistentes. O job ETL do AWS Glue normaliza esses esquemas, mapeia tipos de transação para categorias unificadas, combina todos os dados em um registro cronológico único por cliente e gera features temporais. O resultado é gravado como Parquet no S3 e registrado no AWS Glue Data Catalog.

Engenharia de features com Amazon SageMaker Processing

Após a unificação, um job de processamento do SageMaker AI cria sequências de adoção de produtos por cliente, calcula agregações de transações em janelas temporais de 7, 30, 60, 180 e 365 dias usando Dask para paralelismo, e padroniza as sequências para um comprimento fixo como entrada do modelo.

Para datasets que excedem a memória disponível, a solução adota uma estratégia de processamento paralelo em chunks, com ProcessPoolExecutor, inspeção de metadados via PyArrow, coleta de lixo explícita entre batches e merge incremental para evitar picos de memória:

import gc
from concurrent.futures import ProcessPoolExecutor

chunksize = 5_000_000
n_workers = 4

for batch_start in range(0, total_chunks, n_workers):
    with ProcessPoolExecutor(max_workers=n_workers) as executor:
        futures = [
            executor.submit(process_chunk_range, input_path, output_path, i, start_row, end_row)
            for i in range(batch_start, min(batch_start + n_workers, total_chunks))
        ]
        for future in futures:
            future.result()
    gc.collect()  # Force garbage collection between batches

Arquitetura do modelo

Por que múltiplas torres em vez de uma rede única?

Diferentes tipos de dados do cliente têm estruturas fundamentalmente distintas: sequências são listas ordenadas de IDs discretos, transações são agregações numéricas, dados demográficos misturam variáveis categóricas e numéricas, e segmentos comportamentais são códigos categóricos. Forçar todos esses dados pela mesma camada desperdiça capacidade do modelo. A arquitetura usa quatro torres especializadas:

• Torre de Sequência: Processa o histórico de adoção de produtos com embedding + GRU de 2 camadas, produzindo um vetor de 64 dimensões
• Torre de Transações: Processa features de transações em janelas temporais com MLP de 2 camadas (128 → 64), com ReLU e Dropout
• Torre de Cliente: Processa dados demográficos, renda, família e conta com MLP de 2 camadas (128 → 64)
• Torre Comportamental: Processa códigos de segmentação, fidelidade e padrões de uso com MLP de 2 camadas (128 → 64)

Torre de Sequência: capturando padrões temporais

A Torre de Sequência é o componente central da arquitetura. Ela captura a ordem em que os clientes adotam produtos — não apenas quais produtos possuem. Usa uma Unidade Recorrente com Portão de 2 camadas (GRU):

class SequenceTower(nn.Module):
    def __init__(self, num_products, embedding_dim=32, hidden_dim=64, dropout=0.2):
        super().__init__()
        self.embedding = nn.Embedding(num_products + 1, embedding_dim, padding_idx=0)
        self.gru = nn.GRU(
            input_size=embedding_dim,
            hidden_size=hidden_dim,
            num_layers=2,
            batch_first=True,
            dropout=dropout
        )
        self.active_count_layer = nn.Sequential(
            nn.Linear(1, hidden_dim // 2),
            nn.ReLU(),
            nn.Dropout(dropout)
        )
        self.fusion = nn.Sequential(
            nn.Linear(hidden_dim + hidden_dim // 2, hidden_dim),
            nn.ReLU(),
            nn.Dropout(dropout)
        )

    def forward(self, sequence, seq_length, active_count):
        embedded = self.embedding(sequence)
        packed = nn.utils.rnn.pack_padded_sequence(
            embedded, seq_length.cpu().clamp(min=1),
            batch_first=True, enforce_sorted=False
        )
        _, hidden = self.gru(packed)
        seq_features = hidden[-1]
        active_features = self.active_count_layer(active_count)
        return self.fusion(torch.cat([seq_features, active_features], dim=1))

A escolha do GRU em vez do LSTM se deve ao menor número de parâmetros (aproximadamente 33% a menos), desempenho comparável para sequências curtas de até 20 itens, treinamento mais rápido e menor tamanho de modelo (~5 MB contra ~15 MB de um Transformer equivalente). O uso de pack_padded_sequence garante que o modelo ignore tokens de padding, evitando que aprenda ruído de posições com zeros.

Mecanismo de atenção entre torres

Em vez de simplesmente concatenar as saídas das torres, a arquitetura usa um mecanismo de atenção aprendida para combiná-las. Esse é o componente que fornece explicabilidade por cliente sem depender de métodos post-hoc como SHAP ou LIME:

class TowerAttentionMechanism(nn.Module):
    def __init__(self, hidden_dim=64, num_heads=4, dropout=0.1):
        super().__init__()
        self.tower_attention = nn.MultiheadAttention(
            embed_dim=hidden_dim, num_heads=num_heads,
            dropout=dropout, batch_first=True
        )
        self.context_weighting = nn.Sequential(
            nn.Linear(hidden_dim * 4, 4),
            nn.Softmax(dim=1)
        )

    def forward(self, tower_outputs):
        stacked = torch.stack(tower_outputs, dim=1)  # [batch, 4, 64]
        attended, _ = self.tower_attention(stacked, stacked, stacked)
        stacked = stacked + attended  # Residual connection
        concat = torch.cat(tower_outputs, dim=1)  # [batch, 256]
        tower_weights = self.context_weighting(concat)  # [batch, 4]
        weighted_outputs = [
            tower_outputs[i] * tower_weights[:, i:i+1]
            for i in range(4)
        ]
        return weighted_outputs, tower_weights

Os pesos das torres são calculados por cliente. Um cliente com histórico transacional rico recebe peso alto na Torre de Transações, enquanto um cliente novo com poucos dados transacionais mas perfil demográfico claro recebe peso alto na Torre de Cliente. Essa adaptabilidade melhora a acurácia e fornece explicabilidade natural para gerentes de relacionamento e reguladores.

Fusão contextual com blocos residuais

As saídas ponderadas das torres passam por uma rede de fusão com conexões residuais, que ajudam no fluxo de gradiente durante o treinamento e permitem que a rede aprenda mapeamentos de identidade quando profundidade adicional não é necessária:

class ContextAwareFusion(nn.Module):
    def __init__(self, hidden_dim=64, dropout=0.2):
        super().__init__()
        self.initial_projection = nn.Linear(hidden_dim * 4, hidden_dim)
        self.fusion1 = nn.Sequential(
            nn.Linear(hidden_dim, hidden_dim * 2),
            nn.LayerNorm(hidden_dim * 2),
            nn.ReLU(),
            nn.Dropout(dropout),
            nn.Linear(hidden_dim * 2, hidden_dim)
        )
        self.layer_norm1 = nn.LayerNorm(hidden_dim)
        self.fusion2 = nn.Sequential(
            nn.Linear(hidden_dim, hidden_dim),
            nn.ReLU(),
            nn.Dropout(dropout)
        )
        self.layer_norm2 = nn.LayerNorm(hidden_dim)

    def forward(self, weighted_outputs):
        concat = torch.cat(weighted_outputs, dim=1)
        projected = self.initial_projection(concat)
        out1 = self.layer_norm1(projected + self.fusion1(projected))  # Residual
        out2 = self.layer_norm2(out1 + self.fusion2(out1))  # Residual
        return out2

Módulo de importância de features: explicabilidade nativa

Reguladores bancários exigem explicabilidade dos modelos. Em vez de depender de métodos externos, a arquitetura inclui um módulo que produz scores de importância por cliente — com soma igual a 1,0 — como parte do próprio forward pass:

class FeatureImportanceModule(nn.Module):
    def __init__(self, hidden_dim=64):
        super().__init__()
        self.feature_contribution = nn.Sequential(
            nn.Linear(hidden_dim, 4),
            nn.Softmax(dim=1)
        )

    def forward(self, fused_features, tower_weights):
        feature_importance = self.feature_contribution(fused_features)
        return feature_importance * tower_weights

O resultado é uma saída como: “Para este cliente, 40% da recomendação foi baseada na sequência de produtos, 30% em padrões de transações, 20% em dados demográficos e 10% no segmento comportamental.” Gerentes de relacionamento podem usar essa informação para personalizar suas abordagens com cada cliente.

Estratégia de treinamento

O treinamento é configurado com as seguintes escolhas e suas justificativas:

• Otimizador: Adam (lr=0,001, weight_decay=1e-5) — taxas de aprendizado adaptativas por parâmetro com regularização L2 leve
• Função de perda: CrossEntropyLoss — padrão para classificação multiclasse, numericamente estável
• Scheduler de LR: ReduceLROnPlateau (fator=0,5, paciência=3) — reduz a taxa automaticamente quando a perda de validação estagna
• Clipping de gradiente: max_norm=1,0 — previne explosão de gradiente com GRU e atenção
• Early stopping: paciência=5 — interrompe o treinamento quando a perda de validação para de melhorar
• Batch size: 32 — cabe confortavelmente na VRAM das A10G
• Divisão dos dados: 80% treino / 10% validação / 10% teste

Todas as seeds aleatórias são fixadas (PyTorch, NumPy, CUDA) para reprodutibilidade total entre execuções. O treinamento usa instâncias ml.g5.12xlarge do SageMaker AI:

from sagemaker.pytorch import PyTorch

estimator = PyTorch(
    entry_point='train.py',
    source_dir='src/',
    role=role,
    instance_count=1,
    instance_type='ml.g5.12xlarge',
    framework_version='2.5.0',
    py_version='py311',
    hyperparameters={
        'epochs': 50,
        'batch_size': 32,
        'learning_rate': 0.001,
    },
)

Métricas de avaliação

O modelo é avaliado com métricas diretamente ligadas ao valor de negócio:

• Acurácia Top-1: O modelo previu exatamente o produto correto?
• Acurácia Top-3: O produto correto está entre os 3 primeiros? (lista curta para o gerente)
• Acurácia Top-5: O produto correto está no carrossel de recomendações?
• Classificação Recíproca Média (MRR): Qual a posição média do produto correto nas recomendações?
• F1 ponderado: O modelo prevê bem todos os tipos de produto?

O modelo de produção alcançou desempenho forte em todas as métricas, com o produto correto aparecendo consistentemente entre as 3 primeiras recomendações. O módulo de importância de features confirmou que a Torre de Sequência contribui com o maior sinal, seguida por padrões de transações, dados demográficos e segmentação comportamental.

Inferência e implantação

O pipeline de inferência suporta tanto scoring em lote quanto predições em tempo real via SageMaker AI.

Para scoring em lote, o SageMaker AI Batch Transform processa toda a base de clientes diariamente, gerando recomendações top-k com scores de explicabilidade para cada cliente. Os resultados são armazenados como JSON no S3 para consumo por sistemas de CRM e dashboards de gerentes de relacionamento.

Para predições em tempo real, um endpoint do SageMaker AI serve recomendações sob demanda quando um cliente acessa o app de mobile banking ou quando um gerente abre o perfil de um cliente. Cada recomendação inclui o ID do produto com score de probabilidade, o detalhamento de importância de features por torre e um indicador de confiança baseado na entropia da distribuição de probabilidades.

def generate_batch_recommendations(model, dataloader, top_k=5):
    with torch.no_grad():
        for batch in dataloader:
            outputs, feature_importance = model(
                batch['sequence'], batch['seq_length'], batch['active_count'],
                batch['transaction'], batch['customer'], batch['behavioral']
            )
            probabilities = F.softmax(outputs, dim=1).cpu().numpy()
            # Generate top-k recommendations with explainability scores

Os trechos de código ilustram padrões arquiteturais e não estão prontos para produção. Para ambientes produtivos, é necessário adicionar validação de entradas, tratamento de erros e logging de inferência. Configure o Amazon SageMaker Model Monitor para alertar sobre drift na distribuição de entradas.

Considerações operacionais e de segurança

Para garantir reprodutibilidade, todas as seeds aleatórias são fixadas. Artefatos do modelo, hiperparâmetros e versões de dados são rastreados via Amazon SageMaker Experiments. O Amazon SageMaker Model Monitor detecta drift de dados, drift do modelo e potencial viés por dependência excessiva de features demográficas. O pipeline do Amazon SageMaker Pipelines retreina o modelo mensalmente com os dados mais recentes dos clientes, implantando automaticamente apenas se as métricas melhorarem em relação ao modelo em produção.

Para implantações com dados bancários reais, a AWS recomenda implementar roles de Gerenciamento de Identidade e Acesso (IAM) com privilégio mínimo, criptografar dados em repouso com chaves gerenciadas pelo cliente no AWS KMS, aplicar TLS para todos os dados em trânsito, implantar jobs de treinamento e endpoints em sub-redes privadas de Nuvem Privada Virtual (VPC) sem gateway de internet, e usar endpoints VPC via AWS PrivateLink para comunicação com serviços AWS. Para orientações completas, consulte a documentação de segurança do SageMaker AI.

Principais decisões de design

O artigo original detalha as razões por trás de cada escolha arquitetural:

• Múltiplas torres vs. rede única: Torres separadas permitem que cada uma se especialize em seu tipo de dado, com a fusão por atenção aprendendo a combinação ótima por cliente.
• GRU vs. Transformers em produção: Para sequências curtas (até 20 itens), GRU é suficiente, mais interpretável, evita a computação quadrática da atenção e produz um modelo menor.
• Pesos de atenção vs. concatenação: Com concatenação, o modelo trata todas as torres igualmente para todos os clientes. Com atenção aprendida, o modelo se adapta por cliente.
• Features de transação em janelas temporais: Janelas de 7 dias capturam intenção imediata, 30 dias capturam padrões mensais, 180 dias capturam padrões sazonais e 365 dias capturam padrões anuais.

Conclusão

A arquitetura de múltiplas torres com fusão por atenção aprendida publicada pela AWS demonstra como é possível combinar alta acurácia preditiva com a explicabilidade exigida por reguladores bancários. Torres especializadas para diferentes tipos de dados superam arquiteturas monolíticas para dados heterogêneos. O processamento de sequências com GRU captura padrões temporais que agregações planas de features não conseguem. E a atenção aprendida entre torres fornece ganhos de acurácia e explicabilidade por cliente sem necessidade de métodos de interpretação post-hoc.

O SageMaker AI oferece a infraestrutura de ponta a ponta para treinamento, gerenciamento de modelos e inferência em escala. Para começar, explore a documentação do SageMaker AI.

Fonte

Build an explainable next-best-product recommendation system for banking on AWS (https://aws.amazon.com/blogs/machine-learning/build-an-explainable-next-best-product-recommendation-system-for-banking-on-aws/)

Claude Opus 5 chega ao Amazon Bedrock

A AWS anunciou a disponibilidade do Claude Opus 5 no Amazon Bedrock e na Claude Platform on AWS. Desenvolvido pela Anthropic, o Opus 5 é o modelo mais avançado da linha Opus e o primeiro representante da quinta geração — um salto relevante para equipes que operam fluxos de trabalho em produção envolvendo codificação agêntica, trabalho de conhecimento intensivo, compreensão visual e tarefas de longa duração.

Segundo a Anthropic, o Claude Opus 5 equipara-se à inteligência de ponta do Claude Fable 5 em muitos domínios, mas com a precificação da linha Opus — o que representa uma proposta de valor importante para times que precisam de capacidade frontier sem abrir mão da previsibilidade de custos.

No Amazon Bedrock, o Opus 5 opera com retenção zero de dados (ZDR — Zero Data Retention) por padrão, garantindo governança de dados corporativos sem comprometer a inteligência do modelo. O serviço é alimentado pelo motor de inferência de nova geração do Bedrock, permitindo que equipes construam dentro do ambiente AWS existente, mantenham segurança corporativa, residência regional de dados e escalem a inferência sem acesso de operadores.

O modelo também está disponível pela Claude Platform on AWS, que suporta retenção zero de dados mediante solicitação e oferece acesso à experiência nativa da plataforma Anthropic pelo Console AWS — com as mesmas APIs, funcionalidades e experiência de console disponíveis ao trabalhar diretamente com a Anthropic, unificadas com o faturamento e autenticação da AWS. Consulte a documentação da Claude Platform on AWS para mais detalhes.

O que diferencia o Claude Opus 5

De acordo com a Anthropic, o Opus 5 representa um avanço expressivo em codificação. O modelo compreende e navega em bases de código como um engenheiro experiente, escreve código de qualidade de produção e adapta sua estratégia conforme avança na tarefa. Ele também sustenta agentes de longa duração que trabalham por horas — e até durante a noite —, contornando obstáculos, se recuperando de erros e atingindo seus objetivos.

Para trabalho profissional, o Opus 5 traz raciocínio mais profundo sobre documentos longos e maior precisão em análises complexas, com os maiores ganhos em tarefas corporativas que envolvem grandes volumes de documentos. O resultado é capacidade frontier com a economia da linha Opus.

Casos de uso principais

O Claude Opus 5 é especialmente adequado para setores onde precisão, confiabilidade e raciocínio profundo são críticos:

• Serviços financeiros: alimenta fluxos de trabalho financeiros com raciocínio aprofundado e compreensão de contexto de ponta a ponta, além de lidar com trabalhos sensíveis à conformidade com maior clareza e foco.
• Automação de agentes e fluxos de trabalho: questiona instruções falhas, decompõe trabalhos complexos em sub-agentes que exigem menos supervisão e executa projetos de vários dias produzindo resultados de nível profissional.
• Produtividade: realiza construção e auditoria de relatórios, elaboração de documentos e análises estruturadas com alta consistência.

Vale destacar que o Opus 5 também aprimora as capacidades de segurança cibernética do Claude Opus 4.8 em todas as frentes — de codificação a cibersegurança. Em áreas de maior risco, o Opus 5 pode recorrer ao Opus 4.8 como fallback. Os usuários são notificados quando isso ocorre, e os fallbacks podem ser configurados via APIs.

Como começar com o Claude Opus 5 no Amazon Bedrock

É possível iniciar com o Claude Opus 5 diretamente pelo console do Amazon Bedrock, acessando o Playground em Test e selecionando o modelo Claude Opus 5 para testar prompts de codificação complexos.

Para acesso programático, o modelo pode ser chamado pela API de Mensagens da Anthropic via SDK da Anthropic ou endpoints bedrock-mantle, ou ainda pelas APIs Invoke e Converse no bedrock-runtime, usando a Interface de Linha de Comando da AWS (AWS CLI) e o AWS SDK.

Pré-requisitos

• Conta AWS ativa com acesso ao Amazon Bedrock
• AWS CLI instalada e configurada
• Python 3.8+
• Boto3 instalado: pip install boto3
• SDK da Anthropic instalado: pip install anthropic[bedrock]
• Permissões IAM (Gerenciamento de Identidade e Acesso): bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream e bedrock:CreateInference

Exemplo com AWS SDK para Python (Boto3)

import boto3
import json

# Create a Bedrock Runtime client
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1"
)

# Invoke Claude Opus 5
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-opus-5",
    contentType="application/json",
    accept="application/json",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 4096,
        "messages": [
            {
                "role": "user",
                "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions."
            }
        ]
    })
)

result = json.loads(response["body"].read())
print(result["content"][1]["text"])

Exemplo com a Converse API do Amazon Bedrock

import boto3

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

response = bedrock_runtime.converse(
    modelId="global.anthropic.claude-opus-5",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions."
                }
            ]
        }
    ],
    inferenceConfig={
        "maxTokens": 4096
    }
)

if 'output' in response:
    blocks = response['output']['message']['content']
    print('\n'.join(b.get('text', '') for b in blocks if 'text' in b))

Exemplo com a API de Mensagens da Anthropic via SDK anthropic[bedrock]

from anthropic import AnthropicBedrockMantle

# Initialize the Bedrock Mantle client (uses SigV4 auth automatically)
mantle_client = AnthropicBedrockMantle(aws_region="us-east-1")

# Create a message using the Messages API
message = mantle_client.messages.create(
    model="anthropic.claude-opus-5",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions"}
    ]
)

print(message.content[1].text)

O Claude Opus 5 também suporta adição e remoção de ferramentas no meio de uma conversa por meio dos blocos de conteúdo tool_addition e tool_removal em mensagens com role: "system", sem necessidade de reenviar o array completo de ferramentas. Consulte a documentação do Bedrock para mais detalhes.

Disponibilidade

O Claude Opus 5 já está disponível no Amazon Bedrock nas seguintes regiões: Leste dos EUA (Norte da Virgínia), Ásia-Pacífico (Melbourne), Europa (Irlanda) e Europa (Estocolmo). Consulte a documentação do Bedrock para a lista completa de regiões suportadas.

O modelo também está disponível na Claude Platform on AWS nas regiões da América do Norte, América do Sul, Europa e Ásia-Pacífico.

Para experimentar o Claude Opus 5, acesse o console do Amazon Bedrock, a Claude Platform on AWS, ou explore os notebooks de introdução no GitHub. Também é possível potencializar o Opus 5 utilizando o Advanced Prompt Optimization no Amazon Bedrock — o recurso recebe seus prompts atuais, os avalia contra critérios de avaliação definidos e gera versões otimizadas prontas para produção.

Fonte

Introducing Claude Opus 5 on AWS: Anthropic’s most capable Opus model (https://aws.amazon.com/blogs/machine-learning/introducing-claude-opus-5-on-aws-anthropics-most-capable-opus-model/)

O problema que o SDR resolve

Quem já trabalhou com Ajuste Fino Supervisionado (SFT — Supervised Fine-Tuning) de modelos de linguagem sabe que criar rastros de raciocínio em cadeia de pensamento (CoT — Chain-of-Thought) para os dados de treinamento é caro e muitas vezes inviável. A solução comum é simplesmente omitir o raciocínio e treinar apenas com pares de entrada e saída. O problema é que isso tem um custo alto — e a AWS acaba de publicar uma pesquisa detalhando exatamente o que acontece e como contornar isso.

O raciocínio é uma capacidade central da família Amazon Nova 2, com ganhos comprovados em tarefas difíceis como programação e matemática. Quando você faz SFT em datasets sem rastros de raciocínio, o modelo entra em um estado chamado de supressão do raciocínio: ele aprende a “pular” o pensamento intermediário e vai direto para a resposta — mesmo que o modo de raciocínio esteja ativado na inferência.

O resultado é devastador. Nos experimentos da AWS, o desempenho em matemática caiu de 70% (modelo base) para apenas 6% em média após SFT convencional. Esse fenômeno é conhecido como esquecimento catastrófico — o modelo adquire novas habilidades, mas destrói as que tinha antes.

Por que isso acontece: a supressão do raciocínio

A explicação técnica é direta. Durante o SFT, a função de perda calcula o erro sobre os tokens de raciocínio e de saída em conjunto. Quando os dados de treinamento contêm apenas pares entrada-saída sem etapas intermediárias, o modelo não recebe nenhum sinal de supervisão para gerar rastros de raciocínio coerentes. A função de perda acaba penalizando tokens que não contribuem diretamente para a resposta final, ensinando o modelo a contornar seus próprios mecanismos de raciocínio. Esse comportamento exemplifica o aprendizado por atalho, onde o modelo se apoia em correlações espúrias em vez de aprender padrões robustos.

Apesar da supressão, ativar o raciocínio tanto no treinamento quanto na inferência traz ganhos expressivos. A tabela abaixo, extraída dos experimentos com o dataset LLaVA CoT e diferentes pesos de fusão LoRA (Adaptação de Baixo Posto — LoRA), ilustra esse efeito:

Peso de fusão	Desempenho alvo (raciocínio ativado)	Desempenho alvo (raciocínio desativado)	Delta
0,0 (base)	12,30%	12,30%	0%
0,3	34,38%	35,28%	-0,9%
0,5	60,51%	48,80%	+11,7%
0,7	66,67%	54,05%	+12,6%
1,0 (fusão completa)	65,17%	47,90%	+17,3%

A solução atual: fusão de modelos e suas limitações

A abordagem recomendada até então para lidar com a supressão do raciocínio era a fusão de modelos (model merging): após o SFT, interpola-se por pesos o checkpoint ajustado com o modelo base, recuperando parte das capacidades gerais perdidas. Funciona — mas introduz um compromisso difícil de calibrar entre desempenho no domínio-alvo e desempenho geral.

O diagrama acima resume bem o dilema: o SFT convencional maximiza o desempenho no alvo mas destrói o desempenho geral. A fusão de modelos recupera parte do desempenho geral, mas sacrifica ganhos no alvo. O SDR, por sua vez, consegue o melhor dos dois mundos — desempenho no alvo igual ou superior ao SFT puro, com preservação quase total das capacidades gerais.

Self-Distilled Reasoning: a técnica

O Raciocínio Auto-Destilado (SDR — Self-Distilled Reasoning) funciona em três etapas simples:

• Usa o modelo base de raciocínio (como o Amazon Nova 2 Lite) para gerar rastros de CoT para cada exemplo do dataset de SFT.
• Aumenta os dados de treinamento prefixando esses rastros de raciocínio às saídas originais.
• Realiza o fine-tuning com o modo de raciocínio ativado, fornecendo supervisão tanto nos tokens de raciocínio quanto nos de saída.

As vantagens práticas são consideráveis: custo zero de anotação (nenhum esforço humano para criar os rastros), consistência com a abordagem de resolução de problemas do próprio modelo base, aplicabilidade a qualquer dataset de SFT independentemente do domínio, e flexibilidade para usar diferentes modelos como “professor”.

A auto-destilação — onde um modelo aprende a partir de suas próprias previsões — tem se mostrado eficaz em diversos contextos, e há uma literatura crescente que defende essa abordagem como mecanismo poderoso para mitigar o esquecimento catastrófico.

Por que o SDR funciona: três funções dos rastros de raciocínio

Os rastros de raciocínio no SFT cumprem três papéis fundamentais que conectam os paradigmas de ajuste fino por reforço (RFT — Reinforcement Fine-Tuning), regularização e auto-destilação:

• Regularização implícita de política: restringe o modelo ajustado a permanecer próximo à política do modelo base, prevenindo o esquecimento catastrófico de forma similar à regularização KL no RLHF.
• Supervisão de processo: análogo ao reforço passo a passo no RFT, leva a generalização mais robusta do que supervisão apenas de resultados finais.
• Auto-destilação rica: captura o processo de resolução de problemas do modelo, não apenas as saídas finais, conforme demonstrado em pesquisas recentes de aprendizado contínuo.

Como construir os rastros de raciocínio

A AWS descreve duas abordagens para gerar os rastros de CoT via Amazon Bedrock, cada uma com trade-offs diferentes:

Raciocínio básico

Gera os rastros de forma direta, onde o modelo produz seu raciocínio dado apenas a pergunta — mimetizando o comportamento na inferência. O template de prompt é:

Think through this question naturally and show your reasoning: {user_text}

Format your response with <thinking> tags for reasoning and <answer> tags for the final answer.
Use a consistent reasoning style.

Raciocínio guiado

Usa a disponibilidade das respostas corretas para guiar a geração de raciocínio de forma retroativa. Fornece tanto a pergunta quanto a resposta, pedindo ao modelo que reconstrua um raciocínio plausível que as conecte — similar a abordagens de aprendizado por retrospectiva. Um passo de filtragem secundária remove menções à resposta no rastro de raciocínio para evitar vazamento de informação.

Generate natural reasoning for solving this question. Act as if you don't know the answer yet.

Question: {user_text}
Answer to arrive at: {assistant_content}

Format your response with <thinking> tags for reasoning and <answer> tags for the final answer.
Write natural reasoning that works toward this answer without assuming you know it beforehand.
Use a consistent reasoning style.

Pipeline de implementação

O código abaixo demonstra como implementar o raciocínio guiado usando a API Converse do Amazon Bedrock. O pipeline lê os dados de treinamento SFT, gera rastros de CoT e monta o dataset final com blocos reasoningContent:

import json, re, boto3, time

MODEL_ID = "amazon.nova-lite-v1:0"
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

COT_SYSTEM = """You are an expert evaluator. Provide a detailed Chain-of-Thought explaining why the given ground truth answer is correct and makes sense."""

COT_USER_TEMPLATE = """Given the task context and ground truth annotation, provide a Chain-of-Thought.

**Original System Context:** {system_prompt}
**Original User Request:** {user_prompt}
**Ground Truth Annotation:**
```json
{ground_truth}
```
ONLY provide your justification within <justification></justification> tags."""

# Invoke Bedrock for each CoT prompt
for req in cot_requests:
    response = bedrock.converse(
        modelId=MODEL_ID,
        system=[{"text": req["system"]}],
        messages=[{"role":"user", "content":[{"text":req["query"]}]}],
        inferenceConfig={"maxTokens":4096,"temperature":0.3,"topP": 0.9,"topK": 50})
    output = response["output"]["message"]["content"][0]["text"]
    time.sleep(2)  # rate limit

# Parse <justification> tags and build SFT dataset
for idx, item in enumerate(original_data):
    tags = extract_xml_tag(inference[idx], "justification")
    reasoning_block = {"reasoningContent": {"reasoningText": {"text": "Based on the provided context, lets think"
        " step by step " + tags[0].strip()}}}
    sft_dataset.append({
        "schemaVersion": "bedrock-conversation-2024",
        "system": item["system"],
        "messages": [item["messages"][0],
            {"role": "assistant", "content": [reasoning_block, original_text]}]})

Os parâmetros de inferência utilizados são: temperature: 0.3 (baixa aleatoriedade para rastros consistentes), topP: 0.9 (amostragem nucleus retendo 90% da massa de probabilidade) e topK: 50 (limita candidatos aos 50 tokens mais prováveis).

Resultados dos experimentos

A AWS validou o SDR em três benchmarks sem rastros de raciocínio: MedMCQA (perguntas e respostas médicas, 10k amostras), CoCoHD (extração estruturada de documentos legislativos com contexto longo de 20-60k tokens) e Invoice-OCR (compreensão multimodal de documentos de faturas).

Os resultados consolidados mostram um padrão consistente: o SFT convencional sem rastros de raciocínio derruba a performance em matemática de 70% para praticamente zero, enquanto o SDR mantém essa métrica em torno de 65-70% sem necessidade de fusão de modelos. Em termos de desempenho no domínio-alvo, o SDR entrega ganhos de mais de 6,5% em média em relação aos melhores checkpoints com fusão de modelos.

O que acontece com datasets parcialmente anotados

Um cenário muito comum na prática é ter apenas uma fração dos dados com rastros de raciocínio. Os experimentos de ablação com o dataset LLaVA CoT revelam um comportamento preocupante sem SDR:

Sem SDR, reduzir a cobertura de raciocínio abaixo de 75% causa colapso catastrófico na performance em matemática: de 66,6% para 21,7% (50% de cobertura), depois para 3,3% (25%) e finalmente 2,5% (0%). Com SDR, a matemática permanece estável entre 64-72% independentemente da porcentagem de dados com raciocínio — inclusive com 0% de cobertura.

Tokens de raciocínio na inferência

Modelos treinados com SDR produzem entre 400 e 860 tokens de raciocínio na inferência. Modelos treinados com ≤25% de dados de raciocínio sem SDR produzem zero tokens — perderam completamente a capacidade de raciocinar passo a passo. Para referência, o modelo base Amazon Nova 2 Lite produz 1.254 tokens medianos de raciocínio. Após SFT com 100% de dados de raciocínio, esse número cai para 367, indicando que o modelo se torna mais eficiente (menos tokens para mesma ou melhor acurácia).

Raciocínio ativado vs. desativado na inferência

Ativar o raciocínio na inferência praticamente dobra o desempenho no MathVista: 35-47% com raciocínio ativado versus 14-22% com raciocínio desativado. A melhor configuração identificada é 50% de dados de raciocínio com SDR, atingindo 45,2% no MathVista com 70,4% no controle de matemática. Um achado interessante: treinar com SDR melhora o desempenho mesmo quando o raciocínio é desativado na inferência — por exemplo, com 75% dos dados sem supervisão CoT, o SDR eleva o desempenho em mais de 5 pontos percentuais mesmo sem raciocínio na inferência (de 16,4% para 21,3%).

Guia prático de decisão

A AWS consolidou as recomendações em um guia de cenários para ajudar profissionais a escolher entre SDR, fusão de modelos ou SFT padrão:

Cenário	Recomendação
SFT sem raciocínio com regressão em performance geral	Se sensível a latência: use fusão de modelos. Se latência permite raciocínio: use SDR com rastros do Nova 2 Lite.
Modelo base fraco no domínio-alvo	Considere raciocínio guiado para sinal adicional na geração dos rastros.
Dataset já tem ≥50% de raciocínio	Treine com raciocínio ativado. Os rastros existentes são suficientes.
Dataset tem <50% de rastros de raciocínio	Se latência permite raciocínio na inferência, preencha os rastros ausentes com o Nova 2 Lite (uma vez, offline).
Não precisa de capacidades gerais	SFT padrão é suficiente.
Aprendizado contínuo ou preservação de múltiplas habilidades	Combine SDR com mistura de dados e peso de fusão pequeno (ou zero).
Ainda quer usar fusão de modelos	Use um peso de fusão menor quando SDR estiver aplicado — o SDR já fornece a regularização que a fusão compensava.

Uma observação importante sobre a escolha do professor

Um professor mais forte nem sempre é melhor. Os experimentos mostram que rastros gerados pelo Amazon Nova 2 Pro (Preview) melhoram a acurácia no domínio-alvo, mas causam queda proporcional no desempenho geral — consistente com achados anteriores de que uma grande diferença entre aluno e professor prejudica a destilação. Os rastros gerados pelo Nova 2 Lite oferecem o resultado mais equilibrado entre desempenho alvo e geral, sendo a opção padrão recomendada para clientes do Amazon Nova 2 Lite.

Para mais informações sobre os modelos Amazon Nova e opções de customização, consulte a documentação do Amazon Bedrock. Para começar com customização SFT, acesse o guia de customização de modelos do Amazon Bedrock.

Fonte

Exploring self-distilled reasoning for supervised fine-tuning with Amazon Nova (https://aws.amazon.com/blogs/machine-learning/exploring-self-distilled-reasoning-for-supervised-fine-tuning-with-amazon-nova/)