o problema
Até aqui, quase todo ganho de qualidade em LLM veio de pré-treino: mais parâmetros, mais tokens, mais FLOPs antes de o modelo entrar em produção. É uma conta cara duas vezes. Você paga o treino uma vez e paga o modelo maior em cada requisição, para sempre. A pergunta óbvia — e se, em vez disso, o modelo pensasse mais na hora de responder? — não tinha resposta medida.
Pior: a literatura era contraditória. Alguns trabalhos mostravam que dá para melhorar a saída gastando mais na inferência; outros mostravam que, em raciocínio matemático, auto-crítica e revisão não entregam nada. Os autores partem daí. Se um LLM recebe um orçamento fixo e não trivial de compute na inferência, quanto ele consegue melhorar numa pergunta difícil? E esse compute compra o mesmo que compraria em pré-treino?
a ideia
Todo método de test-time compute mexe em uma de duas coisas. Ou você muda a proposal distribution — o modelo condiciona nas próprias tentativas anteriores e revisa —, ou você mantém a distribuição e mexe no verifier, amostrando várias respostas e escolhendo a melhor com um reward model. Revisão é refinamento local; amostragem paralela é busca global.
A descoberta central é que nenhuma das duas ganha sempre. Qual funciona depende de quão difícil a pergunta é do ponto de vista daquele modelo. Se a primeira tentativa já está no caminho certo, revisar é melhor gasto de token do que sortear de novo. Se o modelo raramente acerta a abordagem, revisar só poli uma resposta errada — melhor sortear abordagens diferentes ou buscar passo a passo contra um verificador. Daí a proposta: uma política “compute-optimal” que escolhe a estratégia por prompt, em vez de aplicar a mesma receita para tudo.
como funciona
A dificuldade vira um número. Estimam pass@1 com 2.048 amostras por questão do MATH e cortam em cinco quintis. Como isso exige o gabarito, testam também a versão sem oráculo: a mesma binagem, mas usando a nota média do verificador em vez da correção real. As duas dão curvas parecidas. A melhor estratégia por bin é escolhida em validação cruzada de duas dobras dentro do próprio conjunto de teste.
O verificador é um PRM treinado sem rótulo humano — o valor de cada passo vem de rollouts de Monte Carlo a partir daquele passo. Para transformar as notas por passo numa nota da solução inteira, o que funcionou melhor foi usar a predição do último passo, não o mínimo nem o produto, ao contrário do que trabalhos anteriores relatavam. Sobre esse PRM eles comparam best-of-N ponderado, beam search (amostra N passos, mantém os N/M melhores, expande de novo, até 40 rodadas) e lookahead search, que simula k passos à frente com temperatura zero antes de pontuar — a um custo de N × (k+1) amostras.
O modelo de revisão é um finetune: cada exemplo tem até quatro respostas erradas no contexto e a correta como alvo, com as erradas escolhidas por distância de edição para ficarem correlacionadas com a certa. Na inferência, o contexto é truncado nas quatro últimas revisões, e o pass@1 continua subindo além dos quatro passos vistos no treino.
o que isso custou
Nada disso sai de graça. As capacidades de revisar e verificar não existiam no modelo base — foi preciso finetune específico para cada uma, porque prompt puro não induz nenhuma das duas. Estimar a dificuldade de uma pergunta consome 2.048 amostras, custo que o próprio paper admite não contabilizar e chama de problema real em produção.
Mais busca também pode piorar. Nos bins fáceis, o beam search degrada conforme o orçamento cresce: ele explora vieses espúrios do PRM e gera passos repetitivos ou soluções de um a dois passos que pontuam bem e estão erradas. O lookahead, o otimizador mais forte, é o que fica pior por unidade de compute. Na revisão ingênua, cerca de 38% das respostas certas viram erradas no passo seguinte, o que obriga a usar verificador ou voto majoritário para escolher dentro da cadeia. E tentar otimizar o modelo de revisão com ReST-EM degradou o comportamento sequencial.
O limite mais duro é o nível 5 do MATH: nenhuma estratégia avança. Na comparação igualada em FLOPs contra um modelo cerca de 14 vezes maior, a inferência ganha em perguntas fáceis e intermediárias, e quando a razão entre tokens de inferência e tokens de pré-treino é baixa. Com R muito acima de 1 — produção de verdade —, ou com perguntas difíceis, o pré-treino ganha. Test-time compute e parâmetros não são trocáveis um por um. Tudo isso saiu de um modelo, o PaLM 2-S*, num benchmark só.
onde isso aparece hoje
O trabalho se posiciona explicitamente contra a régua de Training Compute-Optimal Large Language Models: a conta ótima muda quando parte dos FLOPs pode migrar para a inferência. A tese de que gastar tokens antes de responder compra acerto já estava em Chain-of-Thought Prompting e em Tree of Thoughts; aqui ela vira curva de escala, com eixo x em orçamento e comparação direta contra parâmetros. A linha que veio depois — modelos treinados para raciocinar longo, como DeepSeek-R1, e o orçamento de raciocínio exposto como parâmetro de API em Extended thinking — opera sobre a mesma aposta que este paper mediu primeiro.