Modelos de Raciocínio São Treinados, Não Promptados

Aqui vai uma opinião que defendi mal num almoço de equipe no ano passado e que, desde então, acredito ainda mais: se o seu modelo mental de um modelo de raciocínio é “um LLM comum que foi instruído a pensar passo a passo”, você não entende modelos de raciocínio de jeito nenhum, e esse equívoco está silenciosamente custando dinheiro e acurácia em produção. Modelos de raciocínio não são uma técnica de prompting. São um artefato de treinamento. O comportamento de chain-of-thought que os torna bons em matemática e código emerge do aprendizado por reforço com recompensas verificáveis, e não de nada que você escreve em um system prompt. Eu finalmente entendi isso de verdade enquanto percorria o mesmo terreno que Sebastian Raschka cobre no seu novo curso de 11 horas sobre como construir um modelo de raciocínio: carregar um modelo base Qwen3 pequeno, construir um verificador, rodar GRPO e ver os traços de raciocínio ficarem mais longos enquanto a acurácia sobe. Depois que você vê isso acontecer no seu próprio loop de treinamento, não tem como desver.

Deixe-me defender essa tese direito e, depois, recuar onde ela merece recuo, porque existe um ponto em que o prompting realmente importa, e fingir o contrário seria hype de outro tipo.

Por que o modelo mental do “é só pedir certo” quebra

A história popular vai mais ou menos assim: em 2022, pesquisadores descobriram que acrescentar “Vamos pensar passo a passo” a um prompt melhorava muito a acurácia em aritmética, e nascia o chain-of-thought prompting. É verdade até onde vai. O que a história deixa de fora é o que veio depois: os laboratórios pegaram esse comportamento e o gravaram nos pesos com aprendizado por reforço. Um modelo de raciocínio moderno não precisa da sua fórmula de passo a passo. Ele gera traços de raciocínio estendidos por padrão porque foi treinado para isso, recompensado por produzir traços que terminam em respostas corretas.

Você pode verificar isso sozinho com um experimento que leva uma tarde. Pegue um modelo base (o Qwen3 0.6B funciona bem e roda em uma única GPU de consumo) e avalie-o no MATH-500 com e sem chain-of-thought no prompt. Você vai ver um ganho modesto. Agora pegue a variante treinada com RLVR da mesma família de modelos. A diferença entre essas duas condições não é um ganho; é um penhasco. Nenhum system prompt escrito até hoje fecha essa lacuna. Esse é o núcleo empírico da minha tese: a capacidade vive nos pesos, e os pesos chegaram lá por meio de treinamento, não por arranjos de tokens engenhosos na hora da inferência.

A confusão persiste porque, de fora, os dois parecem idênticos: o modelo emite um longo fluxo de raciocínio intermediário antes de responder. Mas a semelhança superficial esconde uma diferença causal. Pedir a um modelo base que pense passo a passo é como pedir a alguém que narre o próprio processo enquanto faz conta de cabeça: a narração segue a habilidade. O treinamento com RL de fato muda a própria habilidade, porque o modelo é otimizado de ponta a ponta para a correção da resposta, e o raciocínio estendido acaba sendo uma estratégia instrumentalmente útil para acertar problemas difíceis.

O verificador é o grande truque

Quando eu era engenheiro de ML, a parte do RLHF que sempre pareceu levemente amaldiçoada era o modelo de recompensa. Você treina uma rede neural separada para imitar preferências humanas, otimiza sua política contra ela e depois passa o resto do projeto lutando contra o reward hacking: a política encontra algum output degenerado que pontua alto no modelo de recompensa e é inútil para humanos de verdade. É uma relação adversarial embutida na arquitetura.

O aprendizado por reforço com recompensas verificáveis (RLVR) contorna isso por completo, e construir um verificador do zero faz você apreciar como a jogada é elegante. Em matemática, o verificador é um programa determinístico e entediante: extrai a resposta final do output do modelo, normaliza (lidando com frações, decimais e formas equivalentes como 1/2 vs 0.5) e checa a equivalência matemática. Resposta certa, recompensa um. Resposta errada, zero. Não existe modelo de recompensa aprendido para hackear. O sinal de recompensa é a verdade de referência.

É por isso que modelos de raciocínio foram os primeiros a ficar bons em matemática e código. Os dois domínios vêm com verificadores baratos e confiáveis: checadores de equivalência simbólica para matemática, testes unitários para código. Você não precisa de anotadores humanos ranqueando outputs; precisa de uma função em Python que retorne um booleano. A consequência prática para quem constrói raciocínio em um domínio específico é dura: se você consegue escrever um verificador para o seu domínio, provavelmente consegue treinar um raciocinador para ele. Se não consegue (se correção no seu domínio é uma questão de gosto, como em copy de marketing), você fica preso ao RLHF e às suas dores de cabeça com reward hacking.

O gargalo para raciocínio em um domínio novo não é computação nem dados. É saber se você consegue escrever o que “correto” significa como um programa.

Um detalhe que adoro em construir o verificador antes de qualquer treino: ele faz dupla função. O mesmo avaliador que pontua seu modelo base no MATH-500 para avaliação vira a função de recompensa durante o RL. Quando você implementa isso sozinho, percebe o tanto de trabalho sutil que ele faz. Extrair a resposta é genuinamente chato, porque modelos expressam respostas finais em dezenas de formatos, e um extrator frágil corrompe silenciosamente o seu sinal de recompensa. Um modelo que escreve “portanto x = 7” pode ser marcado como errado se o seu regex só procura respostas em caixa (boxed). Verificadores descuidados ensinam políticas descuidadas. Essa é o tipo de lição que você simplesmente não aprende lendo papers.

O que o GRPO faz de fato com os pesos

O loop de treinamento em si, na sua forma simplificada, feita do zero, é surpreendentemente compacto. O Group Relative Policy Optimization (o algoritmo popularizado pela DeepSeek) elimina a rede crítica que tornava o PPO tão pesado em memória. Em vez de aprender uma função de valor, você gera um grupo de respostas para o mesmo prompt, pontua todas com o verificador e calcula a vantagem de cada resposta em relação à média do grupo. Respostas melhores que a média do grupo têm suas probabilidades de tokens aumentadas; as piores têm suas probabilidades reduzidas.

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

Implementações reais adicionam uma penalidade de KL para evitar que a política se afaste demais do modelo de referência, além de clipping emprestado do PPO, mas o esqueleto acima é, honestamente, a ideia central. E o que torna isso mágico de ver é que você não diz nada ao modelo sobre estilo de raciocínio. Você só recompensa respostas finais corretas. Mesmo assim, ao longo do treino, o tamanho das respostas cresce. O modelo passa a produzir autocorreções no meio do traço (“espera, deixa eu conferir”), porque traços com comportamento de verificação têm mais chance de terminar em respostas corretas, e respostas corretas são a única coisa que gera recompensa. O estilo de chain-of-thought é uma solução emergente para o problema de otimização, não um comportamento que alguém projetou. É por isso que digo que ele é treinado, e não promptado: a versão da era do prompting desse comportamento era humanos imitando o que o RL depois descobriu sozinho.

Há uma nota de engenharia pragmática escondida aqui que o ciclo de hype ignora: um modelo de 0.6B com uma GPU decente basta para ver essa dinâmica de verdade. Você vai obter uma melhora mensurável no MATH-500 com GRPO em um hardware que pode alugar por alguns dólares por hora. Não vai obter um modelo de fronteira. Tudo bem, esse não é o objetivo do exercício.

Escala em tempo de inferência: onde o compute substitui o treino (em parte)

Antes de qualquer RL, existe uma família de técnicas que melhora as respostas com os pesos congelados: amostrar vários candidatos com temperature e top-p e depois combiná-los. O self-consistency é o cavalo de batalha: gere k respostas e faça uma votação por maioria sobre as respostas finais. Funciona de forma absurdamente boa, e funciona também em modelos base, o que é a primeira rachadura na minha tese inicial que vou admitir: o compute em tempo de inferência é um eixo real e ortogonal de melhora.

Mas veja o que essas técnicas realmente exigem. A votação por maioria só ajuda se o modelo já tiver uma probabilidade não trivial de produzir respostas corretas: a votação amplifica um sinal que existe, não cria sinal do nada. A seleção por pontuação (ranqueando candidatos pela log-probabilidade da sequência) tem a mesma propriedade. E os loops de autorrefinamento, em que o modelo critica e revisa a própria resposta, se revelam decepcionantemente fracos em modelos base, porque a autocrítica honesta é ela mesma uma capacidade que o RL instala. Toda técnica de inferência se compõe com o treino; nenhuma o substitui. A razão pela qual sistemas de fronteira combinam modelos treinados com RL e escala de inferência é que os dois se multiplicam em vez de somar.

O lado do custo importa para quem trabalha com isso. Self-consistency com k=16 custa dezesseis vezes a inferência. Se isso é um bom negócio depende inteiramente da sua curva de acurácia por dólar, e a única forma honesta de responder é plotar a acurácia no MATH-500 contra o número de candidatos por conta própria. Abordamos uma questão parecida de posicionamento de compute em nossa análise de modelos flash-tier e eficiência de inferência. O tema recorrente é que “gastar mais compute” tem pelo menos três significados diferentes, e eles não são intercambiáveis.

Destilação, e o único lugar onde o prompting sobrevive

A etapa final do pipeline do zero é a destilação: pegue os traços longos de raciocínio de um raciocinador forte (geralmente grande) e faça fine-tuning de um modelo menor diretamente com eles, usando aprendizado supervisionado simples. Sem RL, sem verificador no loop. É assim que muitos dos modelos de raciocínio pequenos e baratos que você vai de fato implantar foram feitos. E isso reforça a tese em vez de enfraquecê-la: o comportamento de raciocínio ainda vem de dados de treino produzidos por um modelo treinado com RL, só que transferido por descida de gradiente em vez de recompensa. A capacidade nunca é injetada no momento do prompt; ela sempre é gravada pela otimização.

Então, onde minha tese contrarian quebra? Aqui, honestamente: o prompting ainda importa nas margens, e as margens não são zero. Os controles de esforço de raciocínio (as configurações de orçamento de pensamento baixo/médio/alto que os modelos da geração atual expõem) são alavancas de inferência que trocam acurácia por latência e custo de forma significativa. Restrições de output estruturado, pipelines com verificador no loop e constrained decoding são técnicas de nível de prompt e harness com valor real, como defendemos em nosso texto sobre constrained decoding. E se você está preso a um modelo base e não pode treinar nada, o chain-of-thought no prompt ainda vale pontos reais nos evals. “Treinado, não promptado” é uma afirmação sobre onde a capacidade se origina, não uma afirmação de que as escolhas na inferência não importam.

Por que construir vale mais do que ler a respeito

Uma objeção razoável apareceu nos lugares de sempre: um tutorial de construa seu próprio modelo de raciocínio não seria como um guia de construa sua própria CPU, charmoso mas inútil, já que treinos de verdade precisam de clusters e dados proprietários? Acho que isso erra o propósito do exercício, e diria o mesmo do clássico tutorial de construir um shell, que elogiamos em O que construir um shell ensina sobre Unix exatamente por esse motivo. Ninguém escreve um shell para substituir o bash. Você escreve um para que fork, exec, pipes e tratamento de sinais deixem de ser abstrações decoradas e virem maquinaria que você já segurou nas mãos.

Aqui é igual. As coisas que mudaram para sempre a forma como eu trabalho com modelos de raciocínio vieram de detalhes de implementação, não de papers:

• Escrever o verificador me ensinou que a qualidade da recompensa é um problema de engenharia de software: casos extremos de normalização distorcem o treino silenciosamente, e “a recompensa é a verdade de referência” só é tão verdadeiro quanto o seu extrator de respostas.
• Implementar a pontuação por log-probabilidade da sequência (com as acrobacias de estabilidade numérica que isso exige) desmistificou metade das funções de perda da literatura de pós-treino. Todas se reduzem a comparar quão prováveis são as respostas sob políticas diferentes.
• Ver o tamanho das respostas crescer durante o GRPO, sem nenhum prompt para isso, matou a minha última crença residual de que o estilo de raciocínio é um comportamento superficial. É o que a otimização encontra quando a correção é o único objetivo.
• Plotar a acurácia contra o número de candidatos no self-consistency me deu uma intuição concreta para a troca entre acurácia e custo por dólar que nenhuma tabela de benchmark jamais deu.

A ansiedade com compute também é exagerada para o caso de aprendizado. As primeiras partes (carregar um modelo base, geração em streaming com KV caching, construir o verificador, rodar o MATH-500) são território de CPU e notebook, ou algo perto disso. O treino com GRPO quer uma GPU, mas uma só, e alugada por hora é mais barata do que a maioria dos livros-texto. O que você não consegue replicar em casa é a escala, e escala é, de fato, outra disciplina. Isso é um dos mitos sobre o motor de inferência do DeepSeek que testamos: a stack de serving de um laboratório de fronteira resolve problemas que simplesmente não existem em escala de tutorial, e vice-versa.

A conclusão prática

Se você levar uma coisa disso tudo, leve a visão de mundo centrada no verificador. A stack moderna de raciocínio é: um modelo base, um programa que decide o que significa “correto”, um algoritmo de RL que otimiza contra ele e técnicas de inferência que multiplicam o resultado. O prompting fica na beirada desse sistema, direcionando uma capacidade que o treino criou. Times que entendem isso gastam esforço onde ele se acumula: verificadores melhores, desenho de recompensa melhor e loops de avaliação melhores, como os que defendemos que faltam na maioria dos benchmarks de IA que não medem trabalho real. Times que não entendem continuam mexendo em system prompts e se perguntando por que a acurácia estagna.

Minha tese do almoço sobrevive com um asterisco: modelos de raciocínio são treinados, não promptados, mas o harness que você constrói ao redor deles, prompts incluídos, decide quanto dessa capacidade treinada você de fato colhe. Construa a versão pequena por conta própria em algum momento. Onze horas acompanhando o código são um preço baixo para nunca mais ter dúvidas sobre isso.