Los modelos de razonamiento se entrenan, no se promptean

Aquí va una opinión que defendí mal en una comida de equipo el año pasado y en la que ahora creo aún más: si tu modelo mental de un modelo de razonamiento es “un LLM normal al que le pidieron pensar paso a paso”, no entiendes en absoluto los modelos de razonamiento, y ese malentendido te está costando dinero y precisión en producción sin que lo notes. Los modelos de razonamiento no son una técnica de prompting. Son un artefacto del entrenamiento. El comportamiento de chain-of-thought que los hace buenos en matemáticas y código surge del aprendizaje por refuerzo con recompensas verificables, no de nada que escribas en un system prompt. Por fin lo entendí de verdad mientras recorría el mismo terreno que Sebastian Raschka cubre en su nuevo curso de 11 horas para construir un modelo de razonamiento: cargar un modelo base pequeño Qwen3, construir un verificador, ejecutar GRPO y ver cómo las trazas de razonamiento se alargan mientras la precisión sube. Cuando lo has visto pasar en tu propio bucle de entrenamiento, ya no puedes dejar de verlo.

Permíteme defender esa afirmación como se debe y, después, matizarla donde corresponde, porque hay un punto en el que el prompting sí importa de verdad, y fingir lo contrario sería hype de otro tipo.

Por qué el modelo mental de “solo hay que promptearlo” se rompe

La historia popular va así: en 2022, unos investigadores descubrieron que añadir “Pensemos paso a paso” a un prompt mejoraba mucho la precisión aritmética, y nació el chain-of-thought prompting. Hasta ahí, cierto. Lo que la historia omite es lo que pasó después: los laboratorios tomaron ese comportamiento y lo grabaron en los pesos con aprendizaje por refuerzo. Un modelo de razonamiento moderno no necesita tu fórmula de “paso a paso”. Genera trazas de razonamiento extensas por defecto porque fue entrenado para ello, recompensado por producir trazas que terminan en respuestas correctas.

Puedes comprobarlo tú mismo con un experimento que lleva una tarde. Toma un modelo base (Qwen3 0.6B funciona bien y corre en una GPU de consumo) y evalúalo en MATH-500 con y sin chain-of-thought. Obtienes una mejora modesta. Ahora toma la variante entrenada con RLVR de la misma familia de modelos. La diferencia entre las dos condiciones no es una mejora, es un precipicio. Ningún system prompt que se haya escrito lo cierra. Ese es el núcleo empírico de mi afirmación: la capacidad vive en los pesos, y los pesos llegaron a ser así mediante entrenamiento, no mediante combinaciones ingeniosas de tokens en tiempo de inferencia.

La confusión persiste porque, desde fuera, ambos se ven idénticos: el modelo emite un largo flujo de razonamiento intermedio antes de responder. Pero la similitud superficial oculta una diferencia causal. Pedirle a un modelo base que piense paso a paso es como pedirle a alguien que narre su proceso de pensamiento mientras hace cálculo mental: la narración sigue a la habilidad. El entrenamiento con RL cambia la habilidad en sí, porque el modelo se optimiza de extremo a extremo por la corrección de la respuesta, y el razonamiento extenso resulta ser una estrategia instrumentalmente útil para acertar en problemas difíciles.

El verificador es todo el truco

Cuando trabajaba como ingeniero de ML, la parte del RLHF que siempre me pareció un poco maldita era el modelo de recompensa. Entrenas una red neuronal aparte para imitar preferencias humanas, optimizas tu política contra ella y luego pasas el resto del proyecto peleando con el reward hacking: la política encuentra alguna salida degenerada que puntúa alto en el modelo de recompensa pero no le sirve de nada a los humanos reales. Es una relación adversarial incrustada en la arquitectura.

El aprendizaje por refuerzo con recompensas verificables (RLVR) elimina todo esto, y construir un verificador desde cero te hace apreciar lo elegante que es la jugada. En matemáticas, el verificador es un programa aburrido y determinista: extrae la respuesta final de la salida del modelo, la normaliza (manejando fracciones, decimales y formas equivalentes como 1/2 frente a 0.5) y comprueba la equivalencia matemática. Respuesta correcta, recompensa de uno. Respuesta incorrecta, cero. No hay ningún modelo de recompensa aprendido que hackear. La señal de recompensa es la verdad de referencia.

Por eso los modelos de razonamiento se volvieron buenos primero en matemáticas y código. Ambos dominios vienen con verificadores baratos y fiables: comprobadores de equivalencia simbólica para matemáticas, tests unitarios para código. No necesitas anotadores humanos que ordenen respuestas; necesitas una función de Python que devuelva un booleano. La consecuencia práctica para quien construye razonamiento en un dominio específico es contundente: si puedes escribir un verificador para tu dominio, probablemente puedas entrenar un razonador para él. Si no puedes, porque la corrección en tu dominio es cuestión de gusto, como en el copy de marketing, te quedas con el RLHF y sus dolores de cabeza con el reward hacking.

El cuello de botella para el razonamiento en un dominio nuevo no es el cómputo ni los datos. Es si puedes escribir lo que significa “correcto” como un programa.

Me encanta un detalle de construir primero el verificador, antes de entrenar nada: hace doble función. El mismo evaluador que puntúa tu modelo base en MATH-500 para la evaluación se convierte en la función de recompensa durante el RL. Cuando lo implementas tú mismo notas cuánto trabajo sutil hace: extraer la respuesta es de verdad delicado, porque los modelos expresan respuestas finales en decenas de formatos, y un extractor frágil corrompe en silencio tu señal de recompensa. Un modelo que escribe “por tanto x = 7” podría salir mal calificado si tu regex solo busca respuestas en caja. Los verificadores descuidados enseñan políticas descuidadas. Esta es el tipo de lección que simplemente no aprendes leyendo papers.

Qué le hace GRPO realmente a los pesos

El bucle de entrenamiento en sí, en su forma simplificada desde cero, es sorprendentemente compacto. Group Relative Policy Optimization, el algoritmo popularizado por DeepSeek, elimina la red crítica que hacía de PPO un devorador de memoria. En lugar de aprender una función de valor, generas un grupo de respuestas al mismo prompt, las puntúas todas con el verificador y calculas la ventaja de cada respuesta respecto a la media del grupo. Las respuestas mejores que la media del grupo ven aumentada la probabilidad de sus tokens; las peores, reducida.

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()

Las implementaciones reales añaden una penalización KL para evitar que la política se aleje demasiado del modelo de referencia, además del recorte (clipping) tomado de PPO, pero el esqueleto de arriba es, honestamente, la idea central. Y esto es lo que lo hace mágico de ver: no le dices nada al modelo sobre el estilo de razonamiento. Solo recompensas las respuestas finales correctas. Aun así, con el entrenamiento, las longitudes de respuesta crecen. El modelo empieza a autocorregirse a mitad de la traza (“espera, lo compruebo”) porque las trazas con comportamiento de verificación tienen más probabilidad de terminar en respuestas correctas, y las respuestas correctas son lo único que da recompensa. El estilo de chain-of-thought es una solución emergente al problema de optimización, no un comportamiento que alguien diseñara. Por eso digo que se entrena, no que se promptea: la versión de esta conducta en la era del prompting era humanos imitando lo que el RL descubrió después por su cuenta.

Hay una nota de ingeniería pragmática enterrada aquí que el ciclo de hype se salta: un modelo de 0.6B con una GPU decente basta para ver esta dinámica de verdad. Obtendrás una mejora medible en MATH-500 con GRPO en hardware que puedes alquilar por unos pocos dólares la hora. No obtendrás un modelo de frontera. No pasa nada, que no es el objetivo del ejercicio.

Escalado en tiempo de inferencia: donde el cómputo sustituye al entrenamiento (en parte)

Antes de que ocurra cualquier RL, existe una familia de técnicas que mejoran las respuestas con los pesos congelados: muestrear varios candidatos con temperatura y top-p, y luego combinarlos. Self-consistency es el caballo de batalla: generas k respuestas y tomas el voto mayoritario sobre las respuestas finales. Funciona de forma absurdamente buena, y también funciona en modelos base, lo que supone la primera grieta en mi afirmación inicial, que concedo: el cómputo en inferencia es un eje de mejora real y ortogonal.

Pero fíjate en lo que estas técnicas requieren de verdad. La votación mayoritaria solo ayuda si tu modelo ya tiene una probabilidad no trivial de producir respuestas correctas: el voto amplifica señal que ya existe, no crea señal de la nada. La selección por puntuación (ordenar candidatos por log-probabilidad de la secuencia) tiene la misma propiedad. Y los bucles de autorrefinamiento, donde el modelo critica y revisa su propia respuesta, resultan decepcionantemente débiles en modelos base, porque la autocrítica honesta es en sí una capacidad que el RL instala. Cada truco de inferencia se combina con el entrenamiento; ninguno lo sustituye. La razón por la que los sistemas de frontera combinan modelos entrenados con RL y escalado en inferencia es que los dos efectos se multiplican en lugar de sumarse.

El lado de los costes importa para quien trabaja en producción. Self-consistency con k=16 cuesta dieciséis veces la inferencia. Si eso es buen negocio depende por completo de tu curva de precisión por dólar, y la única forma honesta de responderlo es dibujar tú mismo la precisión en MATH-500 frente al número de candidatos. Cubrimos una cuestión similar de ubicación del cómputo en nuestro repaso de los modelos flash y la eficiencia de inferencia: el tema recurrente es que «gastar más cómputo» tiene al menos tres significados distintos, y no son intercambiables.

Destilación, y el único lugar donde sobrevive el prompting

La etapa final del pipeline desde cero es la destilación: tomas las trazas de razonamiento largas de un razonador fuerte (normalmente grande) y ajustas con ellas un modelo más pequeño mediante aprendizaje supervisado simple. Sin RL, sin verificador en el bucle. Así se hacen muchos de los modelos de razonamiento pequeños y baratos que realmente vas a desplegar. Y esto refuerza la tesis en lugar de socavarla: el comportamiento de razonamiento sigue viniendo de datos de entrenamiento producidos por un modelo entrenado con RL, solo que transferido mediante descenso de gradiente en lugar de recompensa. La capacidad nunca se inyecta en tiempo de prompt; siempre queda incorporada por optimización.

Entonces, ¿dónde se rompe mi afirmación contraria? Aquí, con honestidad: el prompting sigue importando en los márgenes, y los márgenes no son cero. Los controles de esfuerzo de razonamiento (los ajustes de presupuesto de pensamiento bajo/medio/alto que exponen los modelos de la generación actual) son palancas de inferencia que intercambian precisión por latencia y coste de forma significativa. Las restricciones de salida estructurada, los pipelines con verificador en el bucle y el decodificado restringido son técnicas de nivel prompt y harness con valor real, como argumentamos en nuestro artículo sobre decodificado restringido. Y si estás atado a un modelo base y no puedes entrenar nada, el chain-of-thought prompting sigue sumando puntos reales en las evaluaciones. «Se entrena, no se promptea» es una afirmación sobre dónde se origina la capacidad, no una afirmación de que las decisiones en inferencia no importen.

Por qué construirlo supera a leer sobre ello

En los lugares habituales surgió una objeción razonable: ¿no es un tutorial de construye tu propio modelo de razonamiento como una guía de construye tu propia CPU, encantador pero inútil, dado que los entrenamientos reales necesitan clústeres y datos propietarios? Creo que esto no entiende para qué sirve el ejercicio, y diría lo mismo del clásico tutorial de construir una shell, que elogiamos en What Building a Shell Teaches You About Unix por esa misma razón. Nadie escribe una shell para reemplazar bash. La escribes para que fork, exec, pipes y el manejo de señales dejen de ser abstracciones memorizadas y se conviertan en maquinaria que has tenido en las manos.

Aquí pasa lo mismo. Las cosas que cambiaron para siempre mi forma de trabajar con modelos de razonamiento vinieron de detalles de implementación, no de papers:

• Escribir el verificador me enseñó que la calidad de la recompensa es un problema de ingeniería de software: los casos límite de normalización distorsionan el entrenamiento en silencio, y que «la recompensa es la verdad de referencia» solo es tan cierto como tu extractor de respuestas.
• Implementar el scoring por log-probabilidad de secuencias (con las acrobacias de estabilidad numérica que conlleva) desmitificó la mitad de las funciones de pérdida de la literatura de post-entrenamiento. Todas se reducen a comparar cuán probables son las respuestas bajo distintas políticas.
• Ver crecer la longitud de respuesta durante GRPO, sin prompt alguno, acabó con mi última creencia residual de que el estilo de razonamiento es un comportamiento superficial. Es lo que encuentra la optimización cuando la corrección es el único objetivo.
• Dibujar la precisión frente al número de candidatos para self-consistency me dio una intuición real sobre el intercambio de precisión por dólar que ninguna tabla de benchmarks me había dado.

La ansiedad por el cómputo también está sobrevalorada para el caso de aprendizaje. Las primeras partes (cargar un modelo base, generación en streaming con caché KV, construir el verificador, ejecutar MATH-500) son territorio de CPU y portátil, o algo parecido. GRPO sí quiere GPU, pero una sola, y alquilada por hora sale más barata que la mayoría de libros de texto. Lo que no puedes replicar en casa es la escala, y la escala es de verdad una disciplina distinta: es uno de los mitos sobre el motor de inferencia de DeepSeek que pusimos a prueba. El stack de servicio de un laboratorio de frontera resuelve problemas que simplemente no existen a escala de tutorial, y viceversa.

La conclusión práctica

Si te llevas una sola cosa de todo esto, que sea la visión centrada en el verificador. El stack moderno de razonamiento es: un modelo base, un programa que decide qué significa “correcto”, un algoritmo de RL que optimiza contra él y técnicas de inferencia que multiplican el resultado. El prompting está en el borde mismo de ese sistema, dirigiendo una capacidad que creó el entrenamiento. Los equipos que entienden esto gastan su esfuerzo donde se acumula: mejores verificadores, mejor diseño de recompensas y mejores bucles de evaluación, como los que defendimos que faltan en la mayoría de benchmarks de IA que no miden el trabajo real. Los que no lo entienden siguen retocando system prompts y preguntándose por qué la precisión se estanca.

Mi afirmación de la comida de equipo sobrevive con un asterisco: los modelos de razonamiento se entrenan, no se promptean, pero el harness que construyes a su alrededor, prompts incluidos, decide cuánto de esa capacidad entrenada llegas a aprovechar de verdad. Construye tú mismo la versión pequeña alguna vez. Once horas siguiendo el código son un precio barato por no volver a confundirte con esto.