Reasoning na Converse: quando pensar mais vale o token

Modelos de raciocínio produzem um bloco de pensamento antes da resposta final. Não é um truque de prompt: é um modo de operação em que o modelo gasta tokens de saída explorando o problema, e só depois escreve a resposta. Na Converse API do Bedrock isso se liga por configuração, não por instrução — e essa distinção é a primeira coisa a entender.

A troca é direta e mensurável: você paga mais tokens de saída e espera mais tempo, em troca de mais acerto em tarefa que exige encadear passos. Como toda troca, ela é boa em algumas tarefas e desperdício em outras — e o erro caro é ligar em tudo, porque o custo aparece em toda chamada e o ganho só nas difíceis.

O raciocínio é um recurso específico de família, então ele entra por `additionalModelRequestFields` — o mesmo campo que isola toda dependência de modelo. É coerente com o desenho da Converse: a estrutura é comum, o que só uma família entende fica concentrado num lugar.

r = brt.converse(
    modelId=MODELO_COM_RACIOCINIO,
    messages=[{"role": "user", "content": [{"text": pergunta}]}],
    inferenceConfig={"maxTokens": 4096},
    additionalModelRequestFields={
        "reasoning_config": {"type": "enabled", "budget_tokens": 2048}
    },
)

# A resposta traz DOIS tipos de bloco. Renderize só o segundo.
for bloco in r["output"]["message"]["content"]:
    if "reasoningContent" in bloco:
        registrar_para_depuracao(bloco["reasoningContent"])
    elif "text" in bloco:
        mostrar_ao_usuario(bloco["text"])

Há uma segunda restrição que costuma pegar quem está migrando: com raciocínio ligado, os parâmetros de amostragem em geral não podem ser ajustados livremente. Se a sua camada de configuração sempre envia `temperature`, ela vai falhar na primeira chamada com raciocínio — e o erro parece um problema de permissão até alguém ler a mensagem inteira.

O padrão é reconhecível: raciocínio paga quando a resposta exige PERCORRER, e não paga quando exige RECUPERAR. Um sistema de RAG bem construído transforma muita pergunta difícil em pergunta de recuperação — e é por isso que ligar raciocínio antes de arrumar o retrieval costuma ser gastar dinheiro para compensar um índice ruim.

A configuração mais econômica raramente é "ligado" ou "desligado" para tudo. É decidir por requisição, e a decisão pode ser simples:

• Classifique a entrada com um modelo pequeno e barato — a pergunta é de recuperação ou de raciocínio?
• Rote as de recuperação para o caminho sem raciocínio, com modelo menor e teto de saída apertado.
• Rote as de raciocínio para o caminho com pensamento habilitado, e registre o bloco de raciocínio para auditoria.
• Meça a distribuição real. Se 90% das perguntas caem no caminho barato, o roteador se paga no primeiro dia; se 10% caem, ele é complexidade sem retorno e deve ser removido.

A conta que fecha o assunto é simples de montar e quase nunca é feita: acerto com raciocínio menos acerto sem, dividido pelo custo adicional. Se cada ponto percentual de acerto custa mais do que o erro custa ao negócio, a resposta é desligar — e essa é uma conta que só o seu domínio responde.

Com prompt estável, ferramentas expostas com segurança e a decisão de raciocínio tomada por medição, o que falta é fechar o laço de qualidade: uma suíte de avaliação que rode contra qualquer combinação dessas escolhas e devolva um número. É o assunto do módulo de evals.