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

La tentación es decir que la segunda versión «lo pensó». Resístela, porque el mecanismo es a la vez más sencillo y más útil de conocer.

Un transformer hace una cantidad fija de computación por cada token generado. Una pasada forward: las mismas capas, las mismas matrices, el mismo número de operaciones tanto si la pregunta es cuánto es 2+2 como si es demuestra este teorema. No hay un dial dentro del modelo para «esfuérzate más en esta».

Así que, cuando se le pide a un modelo que dé una respuesta de inmediato, toda la computación disponible para él es una pasada forward. Cada cantidad intermedia tiene que caber en las activaciones de esa única pasada, y cualquier cosa que no pueda computar ahí, no puede computarla.

Emitir tokens cambia eso, y lo cambia de dos formas distintas que conviene separar:

• Más computación. Cada token generado es otra pasada forward completa. Ciento cuarenta y cinco tokens de trabajo equivalen a ciento cuarenta y cinco veces la aritmética de responder directamente.
• Memoria externalizada. Los tokens se escriben en el contexto, de modo que la siguiente pasada puede leerlos. 5 × 13 = 65 se convierte en un hecho en la entrada, no en un valor que el modelo tenga que mantener en una activación y arrastrar hacia delante. El modelo usa su propia salida como bloc de notas.

Ese segundo punto es el que la gente pasa por alto, y explica por qué el trabajo tiene que estar escrito para ayudar. Un modelo al que se le pide «piénsalo en silencio y luego responde» no tiene dónde poner el pensamiento.

Nada de esto requiere nada místico, y produce una predicción firme: chain of thought debería ayudar sobre todo en problemas con estructura serial —donde el segundo paso necesita el resultado del primero— y menos en problemas que son una única consulta. Eso es exactamente lo que encuentra la literatura, y por eso «piensa paso a paso» no hace nada por cuál es la capital de Francia.

La técnica llegó en 2022 en dos piezas. Wei et al. mostraron que incluir ejemplos resueltos en el prompt —demostraciones donde la respuesta va precedida de razonamiento— producía grandes mejoras en benchmarks de aritmética y sentido común.¹ Kojima et al. mostraron después algo más extraño: no necesitas los ejemplos. Añadir «Let's think step by step» a un prompt zero-shot captura buena parte de la misma mejora.²

El segundo resultado es el que te dice qué está pasando. Si una frase mágica desbloquea el comportamiento, el comportamiento ya estaba en el modelo: el preentrenamiento está lleno de soluciones resueltas, y la frase es un puntero a esa región de la distribución. Chain of thought no enseñó nada al modelo. Seleccionó algo que el modelo ya tenía.

Ese marco también predice la obsolescencia final de la técnica, a la que volvemos al final del capítulo.

El siguiente paso obvio: si una cadena de razonamiento puede estar equivocada, muestrea varias y quédate con la respuesta mayoritaria. Eso es autoconsistencia.³ Es un gasto estrictamente mayor —$n$ generaciones completas en lugar de una— y la intuición es que las respuestas erróneas se dispersan mientras que las correctas coinciden.

Medido en 16 de los mismos problemas, muestreando a temperatura 0,8, con voto mayoritario sobre $n$ cadenas:

Dieciséis problemas es un denominador pequeño, y la regla del Capítulo 4 se aplica a esta tabla tanto como a cualquier otra. 13 de 16 es 81 % con un intervalo de Wilson del 95 % de [57, 93]; 16 de 16 es 100 % con [81, 100]. Se solapan. Lee la forma de la curva, que es el hallazgo; no leas el peldaño exacto donde se aplana, que dieciséis problemas no pueden localizar.

Hay dos cosas en esa tabla, y la segunda no es la que esperaba.

La curva se aplana en $n = 3$. En la tercera muestra la precisión ya está en su techo y las dos muestras restantes no compran nada, aunque cuestan 172 tokens cada una, 345 entre las dos. Esa es la forma de todas las curvas de autoconsistencia publicadas en la literatura, y llega mucho antes de lo que sugiere el encuadre «más muestras es más mejor».

Y la decodificación greedy ya estaba en el 100 %. Vuelve al principio del capítulo: una cadena, sin muestreo, 145 tokens, 24/24. Muestrear a temperatura 0,8 bajó la precisión al 81 %, y la autoconsistencia necesitó tres generaciones para volver a subir hasta donde ya estaba una sola pasada greedy: a 3,6 veces los tokens, o seis veces si ejecutas el barrido hasta cinco sin saber dónde se aplana.

Eso no es un argumento contra la autoconsistencia. Es una declaración precisa de lo que hace: la temperatura compra diversidad inyectando errores, y la votación elimina los errores que acaba de inyectar. En problemas donde la decodificación greedy falla —donde la cadena más probable lleva a un sitio equivocado y otra menos probable es correcta— ese intercambio compensa, y por eso existe la técnica. En problemas donde greedy ya acierta, es una forma de gastar seis veces el presupuesto para empatar.

Nadie publica el segundo caso, y por eso merece la pena medirlo en tu propia tarea antes de adoptar la técnica. Estos son problemas sencillos de dos pasos para un modelo pequeño; ese es el régimen donde la respuesta sale así.

Todo lo anterior ocurre en tiempo de prompt sobre un modelo que nunca fue entrenado específicamente para ello. El cambio que produjo la generación actual de modelos de razonamiento fue trasladarlo al entrenamiento, y la clave que lo hizo posible es más estrecha de lo que parece.

El postentrenamiento del Capítulo 11 necesitaba preferencias humanas, porque «¿era buena esta respuesta?» no tiene una respuesta programática. Pero para algunas preguntas sí la tiene. Una respuesta matemática o equivale al valor correcto o no. El código o pasa las pruebas o no. Una demostración o se verifica o no.

Para esos dominios puedes sustituir el modelo de recompensa por un verificador, y todo lo que viene después mejora de golpe: sin anotadores, sin ajuste Bradley–Terry, sin reward hacking del tipo medido en el Capítulo 11, porque no puedes adular a un test unitario. Esto es reinforcement learning from verifiable rewards, y es el escenario para el que se construyó GRPO: muestrear un grupo de intentos de solución para el mismo problema, comprobar cada uno y usar la puntuación media del grupo como baseline. Sin crítico, sin anotador, sin modelo de recompensa. Solo un programa que dice correcto o incorrecto.

El resultado que reformuló el campo llegó de DeepSeek a principios de 2025.⁶ Tomaron un modelo base y aplicaron reinforcement learning con recompensas verificables directamente, sin una etapa previa de fine-tuning supervisado: la etapa que el Capítulo 11 presenta como la base de todo. Aun así, emergieron cadenas largas de razonamiento. También lo hicieron comportamientos que nadie había entrenado: el modelo empezó a revisar sus propios pasos y, en el pasaje más citado del paper, a reconsiderar espontáneamente un enfoque a mitad de solución.

La lectura honesta no es que el razonamiento sea magia. Es que, cuando lo único recompensado es estar en lo correcto, y estar en lo correcto en un problema difícil exige trabajarlo, entonces trabajarlo es lo que encuentra el optimizador, incluidas las partes de trabajarlo que los humanos también hacemos, porque son lo que exige el problema y no lo que nadie enseñó.

La consecuencia práctica de todo esto es que un modelo de razonamiento produce tokens que pediste y tokens que no pediste, y pagas por ambos.

Los proveedores lo gestionan de formas distintas, y la diferencia importa:

• La mayoría de las APIs cuentan los reasoning tokens dentro del recuento de output tokens. Tu factura y tu límite max_tokens incluyen el pensamiento que nunca ves.
• Gemini de Google informa de los thinking tokens como un campo separado, fuera del recuento estándar de salida.

Esa es una incompatibilidad real entre dos formas de contar lo mismo, y cualquier código que calcule costes o imponga un presupuesto entre proveedores tiene que normalizarla. El Capítulo 16 es donde eso se convierte en dinero, y el Capítulo 23, donde se convierte en un presupuesto que puedes imponer.

La otra consecuencia es de latencia, y sorprende a la gente la primera vez. El tiempo hasta el primer token visible de un modelo de razonamiento incluye todo su pensamiento, así que una petición que no emite nada en streaming durante ocho segundos y luego responde en uno no es una conexión colgada: es el modelo trabajando. Cualquier interfaz que muestre un spinner sin explicación durante ocho segundos tiene un problema de diseño, no de red.

Una advertencia final, porque es la forma más común de aplicar mal el material de este capítulo.

Todo lo de la primera mitad es una técnica para hacer que un modelo que no fue entrenado para razonar produzca razonamiento de todos modos. Los modelos entrenados con RLVR ya lo hacen: emiten su propio trabajo, con su propia longitud, antes de responder. Decirle a un modelo así que piense paso a paso es, en el mejor de los casos, redundante y, en el peor, dañino: puede producir una cadena corta con forma de prompt en lugar de la más larga que el modelo habría generado por sí solo, y algunos proveedores documentan exactamente esto.

Lo mismo se aplica a andamiajes de razonamiento elaborados construidos en el código de la aplicación. Un prompt que guía a un modelo por un árbol de decisión que ya navega internamente gasta tus tokens para restringir un comportamiento que fue entrenado dentro. Esta es la primera aparición de un tema que recorre el resto del curso: técnicas que eran esenciales en 2022 se convirtieron en superstición en 2025, y la única forma de saber cuál es cuál para tu modelo, hoy, es medir ambas.

El Capítulo 15 es donde esa medición se convierte en una disciplina en lugar de una opinión.

El razonamiento tiene una propiedad incómoda: es la única capacidad cuyo coste escala con lo difícil que es la pregunta. Un modelo que piensa durante novecientos tokens hace novecientas pasadas forward, mantiene una cache creciente en memoria durante todas ellas y retiene una GPU mientras dura.

Eso hace que la economía de servir un modelo de razonamiento sea mucho peor que la de servir un modelo de chat, y convierte un conjunto de detalles de implementación en la diferencia entre un producto viable y uno inviable: cómo se almacena y reutiliza la cache de claves y valores pasados, cuántas peticiones pueden compartir una pasada forward y cuánta precisión necesitan realmente los pesos.

El Capítulo 13 es el último en el que el modelo es un objeto en tu memoria y no un servicio detrás de un puerto, y trata de hacer que ese objeto sea lo bastante barato como para servirlo. También cobra una promesa de este capítulo: decodificación especulativa, que produce varios tokens por aproximadamente el precio de uno haciendo que un modelo pequeño adivine y uno grande compruebe; un truco que solo tiene sentido cuando has visto cuánto de una pasada forward se gasta esperando a la memoria en lugar de haciendo aritmética.

Todas las mediciones de este capítulo proceden de Qwen/Qwen2.5-0.5B-Instruct sobre 24 problemas verbales generados de dos pasos, con decodificación greedy salvo donde se indica muestreo, y con cero generaciones truncadas en los límites de token usados. Son reproducibles, y son un modelo pequeño en problemas fáciles: lee el resultado de autoconsistencia como una demostración del mecanismo, no como un benchmark. El capítulo 18 de los apuntes de clase de CS229 y el capítulo 12 del Hugging Face LLM Course cubren ambos este material con modelos más grandes y benchmarks adecuados.