Chain of Thought, RLVR e test-time compute, medidos

A tentación é dicir que a segunda versión "pensouno". Resístea, porque o mecanismo é á vez máis simple e máis útil de coñecer.

Un transformer fai unha cantidade fixa de computación por cada token xerado. Unha pasada cara adiante: as mesmas capas, as mesmas matrices, o mesmo número de operacións independentemente de se a pregunta é canto é 2+2 ou demostra este teorema. Non hai un regulador dentro do modelo para "esfórzate máis nesta".

Así que, cando se lle pide a un modelo que responda de inmediato, toda a computación dispoñible para el é unha única pasada cara adiante. Cada cantidade intermedia ten que caber nas activacións desa única pasada, e o que non poida computar aí, non o pode computar.

Emitir tokens cambia iso, e cámbiao de dúas maneiras distintas que paga a pena separar:

• Máis computación. Cada token xerado é outra pasada cara adiante completa. Cento corenta e cinco tokens de traballo son cento corenta e cinco veces a aritmética de responder directamente.
• Memoria externalizada. Os tokens escríbense no contexto, así que a seguinte pasada pode lelos. 5 × 13 = 65 convértese nun feito na entrada, non nun valor que o modelo teña que manter nunha activación e arrastrar cara adiante. O modelo está usando a súa propia saída como caderno de borrador.

Ese segundo punto é o que a xente perde, e explica por que o traballo ten que estar escrito para axudar. Un modelo ao que se lle pide "pénsao en silencio e logo responde" non ten onde poñer o pensamento.

Nada disto require nada místico, e fai unha predición firme: chain of thought debería axudar máis nos problemas con estrutura serial —onde o paso dous necesita o resultado do paso un— e menos nos problemas que son unha única consulta. Iso é exactamente o que atopa a literatura, e por iso "pensa paso a paso" non fai nada para cal é a capital de Francia.

A técnica chegou en 2022 en dúas pezas. Wei et al. mostraron que incluír exemplos resoltos no prompt —demostracións nas que a resposta vai precedida polo razoamento— producía grandes melloras en benchmarks de aritmética e sentido común.¹ Kojima et al. mostraron despois algo máis estraño: non necesitas os exemplos. Engadir "Let's think step by step" a un prompt zero-shot captura boa parte da mesma mellora.²

O segundo resultado é o que che di que está a pasar. Se unha frase máxica desbloquea o comportamento, o comportamento xa estaba no modelo: o preadestramento está cheo de solucións resoltas, e a frase é un punteiro a esa rexión da distribución. Chain of thought non lle ensinou nada ao modelo. Seleccionou algo que o modelo xa tiña.

Ese marco tamén predí a obsolescencia eventual da técnica, á que volvemos ao final do capítulo.

O seguinte movemento obvio: se unha cadea de razoamento pode estar equivocada, mostra varias e colle a resposta maioritaria. Iso é autoconsistencia.³ É un gasto estritamente maior —$n$ xeracións completas no canto dunha— e a intuición é que as respostas erradas se dispersan mentres as correctas coinciden.

Medido en 16 dos mesmos problemas, con mostraxe a temperature 0.8, voto maioritario sobre $n$ cadeas:

Dezaseis problemas é un denominador pequeno, e a regra do Capítulo 4 aplícase a esta táboa tanto como a calquera outra. 13 de 16 é 81 % cun intervalo de Wilson do 95 % de [57, 93]; 16 de 16 é 100 % con [81, 100]. Solápanse. Le a forma da curva, que é o achado; non leas o chanzo exacto no que se achata, que dezaseis problemas non poden localizar.

Hai dúas cousas nesa táboa, e a segunda non é a que eu esperaba.

A curva achátase en $n = 3$. Na terceira mostra a precisión xa está no seu teito, e as dúas mostras restantes non compran nada mentres custan 172 tokens cada unha, 345 entre ambas. Esa é a forma de cada curva de autoconsistencia publicada na literatura, e chega moito antes do que suxire o marco de "máis mostras é máis mellor".

E a decodificación greedy xa estaba no 100 %. Mira de novo o inicio do capítulo: unha cadea, sen mostraxe, 145 tokens, 24/24. Mostrar a temperature 0.8 baixou a precisión ao 81 %, e a autoconsistencia necesitou tres xeracións para volver subir ata onde xa estaba unha única pasada greedy: a 3,6 veces os tokens, ou seis veces se executas o varrido ata cinco sen saber onde se achata.

Iso non é un argumento contra a autoconsistencia. É unha afirmación precisa do que fai: a temperature compra diversidade inxectando erros, e o voto elimina os erros que acaba de inxectar. Nos problemas onde a decodificación greedy falla —onde a cadea máis probable leva a algún sitio equivocado e unha menos probable é correcta— ese intercambio compensa, e por iso existe a técnica. Nos problemas onde greedy xa funciona, é unha maneira de gastar seis veces o orzamento para quedar igual.

Ninguén publica o segundo caso, e por iso paga a pena medilo na túa propia tarefa antes de adoptar a técnica. Estes son problemas fáciles de dous pasos para un modelo pequeno; ese é o réxime no que a resposta sae así.

Todo o anterior acontece no momento do prompt nun modelo que nunca foi adestrado especificamente para iso. O cambio que produciu a xeración actual de modelos de razoamento foi movelo ao adestramento, e a clave que o fixo posible é máis estreita do que parece.

O post-adestramento do Capítulo 11 necesitaba preferencias humanas, porque "foi esta unha boa resposta?" non ten resposta programática. Pero para algunhas preguntas si a ten. Unha resposta matemática ou iguala o valor correcto ou non. O código ou pasa as probas ou non. Unha demostración ou verifica ou non.

Para eses dominios podes substituír o modelo de recompensa por un verificador, e todo o que vén despois mellora á vez: sen anotadores, sen axuste Bradley–Terry, sen reward hacking do tipo medido no Capítulo 11, porque non podes adular unha proba unitaria. Isto é reinforcement learning a partir de recompensas verificables, e é o escenario para o que se construíu GRPO: mostrar un grupo de intentos de solución ao mesmo problema, comprobar cada un e usar a puntuación media do grupo como baseline. Sen crítico, sen anotador, sen modelo de recompensa. Só un programa que di correcto ou incorrecto.

O resultado que reformulou o sector veu de DeepSeek a comezos de 2025.⁶ Colleron un modelo base e aplicaron reinforcement learning con recompensas verificables directamente, sen etapa previa de fine-tuning supervisado —a etapa que o Capítulo 11 presenta como o fundamento de todo. As cadeas longas de razoamento emerxeron igualmente. Tamén o fixeron comportamentos que ninguén adestrou: o modelo empezou a revisar de novo os seus propios pasos e, na pasaxe máis citada do artigo, a reconsiderar espontaneamente un enfoque a media solución.

A lectura honesta non é que o razoamento sexa maxia. É que cando o único que se recompensa é estar no certo, e estar no certo nun problema difícil require traballalo, entón traballalo é o que atopa o optimizador, incluídas as partes de traballalo que tamén fan os humanos, porque son o que o problema require e non o que alguén ensinou.

A consecuencia práctica de todo isto é que un modelo de razoamento produce tokens que pediches e tokens que non pediches, e pagas por ambos.

Os provedores xestionan isto de maneira distinta, e a diferenza importa:

• A maioría das API contan os reasoning tokens dentro do reconto de output tokens. A túa factura e o teu límite max_tokens inclúen ambos o pensamento que nunca ves.
• Gemini de Google informa dos thinking tokens como un campo separado, fóra do reconto estándar de saída.

Iso é unha incompatibilidade real entre dúas formas de contar o mesmo, e calquera código que calcule custo ou aplique un orzamento entre provedores ten que normalizalo. O Capítulo 16 é onde iso se converte en diñeiro, e o Capítulo 23, onde se converte nun orzamento que podes facer cumprir.

A outra consecuencia é de latencia, e sorprende á xente a primeira vez. O tempo ata o primeiro token visible dun modelo de razoamento inclúe todo o seu pensamento, así que unha petición que non emite nada durante oito segundos e logo responde nun non é unha conexión colgada: é o modelo traballando. Calquera interface que amose un spinner sen explicación durante oito segundos ten un problema de deseño, non de rede.

Un aviso final, porque é a maneira máis común na que se aplica mal o material deste capítulo.

Todo o da primeira metade é unha técnica para facer que un modelo que non foi adestrado para razoar produza razoamento igualmente. Os modelos adestrados con RLVR xa o fan: emiten o seu propio traballo, coa súa propia lonxitude, antes de responder. Dicirlle a un modelo así que pense paso a paso é, no mellor dos casos, redundante e, no peor, prexudicial: pode producir unha cadea curta con forma de prompt no lugar da máis longa que o modelo xeraría pola súa conta, e algúns provedores documentan exactamente isto.

O mesmo se aplica aos andamios elaborados de razoamento construídos no código da aplicación. Un prompt que guía un modelo por unha árbore de decisións que xa navega internamente está gastando os teus tokens para restrinxir un comportamento que foi adestrado dentro. Esta é a primeira aparición dun tema que atravesa o resto do curso: técnicas que eran esenciais en 2022 convertéronse en superstición en 2025, e a única maneira de saber cal é cal para o teu modelo, hoxe, é medir ambas.

O Capítulo 15 é onde esa medición se converte nunha disciplina e non nunha opinión.

O razoamento ten unha propiedade incómoda: é a única capacidade cuxo custo escala coa dificultade da pregunta. Un modelo que pensa durante novecentos tokens fai novecentas pasadas cara adiante, mantén unha caché crecente en memoria para todas elas e ocupa unha GPU durante todo ese tempo.

Iso fai que a economía de servir un modelo de razoamento sexa claramente peor ca servir un modelo de chat, e converte un conxunto de detalles de implementación na diferenza entre un produto viable e un inviable: como se almacena e reutiliza a caché de claves e valores pasados, cantas peticións poden compartir unha pasada cara adiante e canta precisión necesitan realmente os pesos.

O Capítulo 13 é o último no que o modelo é un obxecto na túa memoria e non un servizo detrás dun porto, e trata de facer que ese obxecto sexa o bastante barato como para servilo. Tamén cobra unha promesa deste capítulo: speculative decoding, que produce varios tokens por aproximadamente o prezo dun facendo que un modelo pequeno adiviñe e un grande comprobe; un truco que só ten sentido cando xa viches canto dunha pasada cara adiante se gasta agardando pola memoria en vez de facendo aritmética.

Todas as medicións deste capítulo veñen de Qwen/Qwen2.5-0.5B-Instruct sobre 24 problemas enunciados xerados de dous pasos, con decodificación greedy agás onde se indique mostraxe, e con cero xeracións truncadas nos límites de token empregados. Son reproducibles, e son un modelo pequeno en problemas fáciles: le o resultado de autoconsistencia como unha demostración do mecanismo, non como un benchmark. O capítulo 18 das notas de clase de CS229 e o capítulo 12 do Hugging Face LLM Course cobren ambos este material con modelos máis grandes e benchmarks axeitados.