En el módulo 8 llegamos a una idea incómoda y liberadora a la vez: un modelo no “sabe” razonar, compra cómputo con tokens. Cada paso de una cadena de pensamiento es una pasada más por la red, y esas pasadas extra son las que le permiten resolver lo que de un tirón no podía. Si eso es cierto, aparece una pregunta natural que este módulo persigue hasta el final: ¿qué pasa si dejamos al modelo comprar MUCHO más cómputo en el momento de responder? No un poco más de cadena, sino diez veces, cien veces más esfuerzo por consulta. Resulta que la respuesta reordenó la frontera de lo que los modelos pueden hacer, y le puso nombre propio a una familia entera: los modelos de razonamiento.

La tesis del módulo

Hay dos palancas para que un modelo resuelva algo más difícil: hacerlo más grande (cómputo de entrenamiento) o dejarlo pensar más al responder (cómputo de inferencia). El test-time compute descubrió que la segunda palanca —barata, ajustable consulta por consulta, sin reentrenar nada— rinde tanto que reordenó la frontera de capacidad. Ya no ganas solo entrenando el modelo más grande: ganas dejándolo pensar el tiempo que el problema merece.

El cambio de marco: dos leyes de escalado

Durante años la única ley que importaba era la de entrenamiento. Las leyes de escalado (scaling laws, la relación empírica entre recursos y rendimiento) decían: el error baja de forma predecible cuando subes tres cosas —parámetros, datos y FLOPs de entrenamiento (FLOP, floating point operation, una operación aritmética; la unidad con la que se mide el cómputo)—. Toda la carrera consistía en entrenar modelos más grandes con más datos. Caro, lento, y de una sola dirección: el modelo que entrenaste es el que tienes, con la capacidad que tiene, para siempre.

El test-time compute agrega una segunda ley, la de inferencia: el rendimiento también sube, de forma predecible, con el cómputo que gastas al momento de responder. La diferencia práctica es enorme. La palanca de entrenamiento la mueves una vez, meses antes, para todos los usuarios por igual. La de inferencia la mueves por consulta, en caliente, sin tocar los pesos: al problema fácil le das un pensamiento corto y barato; al problema difícil le das uno largo y caro. Es la misma idea del módulo 8 —comprar cómputo con tokens— pero convertida en un dial que puedes girar en cada llamada.

Esto no es teoría de pizarra. Es exactamente lo que representan los modelos de razonamiento que aparecieron en la industria: o1 de OpenAI (finales de 2024) y su sucesor o3 (o3-mini el 31 de enero de 2025, o3 el 16 de abril de 2025), junto a modelos equivalentes de otros laboratorios (y hoy sus sucesores: la familia GPT-5 desde agosto de 2025, con o3-mini ya en retiro). Su rasgo distintivo no es una arquitectura nueva: es que fueron entrenados para gastar mucho cómputo de inferencia en pensar antes de responder, generando cadenas de razonamiento largas de forma interna. El dato que hizo ruido fue la curva: la precisión de o1 en pruebas de matemática sube de forma sostenida con el logaritmo del cómputo de inferencia. Es decir: pensar diez veces más da un salto de precisión parecido al de pensar diez veces más otra vez. Una ley de escalado, con la misma forma que la de entrenamiento, pero movible al vuelo.

Ojo con las cifras. Los números de benchmark de estos modelos cambian con cada versión y cada laboratorio publica los suyos. Lo que importa para este curso no es el puntaje exacto, sino la forma de la curva: más cómputo de inferencia, más rendimiento, de manera predecible. Retén el patrón, no el marcador.

Las técnicas, de simple a compleja

“Gastar más cómputo al responder” no es una sola cosa. Es una familia de técnicas que van de trivial a sofisticada. Todas comparten el molde: generar más de una vez y elegir mejor. Cambia cómo generas y cómo eliges.

1. Best-of-N (rejection sampling)

La más simple. En vez de pedir una respuesta, pides N respuestas (subiendo la temperatura para que salgan distintas), y te quedas con la mejor según un verificador —algo que puntúa candidatos— o un reward model (modelo de recompensa, una red entrenada para dar una nota de calidad a una respuesta; lo verás a fondo en el módulo 11). También se le llama rejection sampling (muestreo por rechazo): generas muchas, rechazas las malas, conservas la buena.

La clave está en el verificador. Si tu problema tiene un verificador duro —un test unitario que pasa o no, una ecuación cuyo resultado se comprueba—, best-of-N es casi mágico: basta con que una de las N sea correcta para que la encuentres. Si el verificador es blando (otro modelo dando una nota), rinde menos, y por una razón que vamos a ver al final.

2. Self-consistency (voto por mayoría)

Variante de best-of-N para cuando no tienes verificador, pero la respuesta final es comparable. Muestreas N cadenas de razonamiento distintas y, en vez de puntuar cada una, miras solo la respuesta final de cada cadena y votas la más común. La intuición: hay muchos caminos de razonamiento errados, pero tienden a equivocarse cada uno para su lado; el camino correcto es un atractor al que varias cadenas independientes llegan. Si 7 de 10 cadenas dicen “42” y las otras 3 dicen cosas distintas entre sí, apuestas a 42.

Funciona de maravilla cuando la respuesta es discreta y comparable (un número, una opción, una etiqueta): puedes agrupar y contar. Se cae cuando la respuesta es texto libre y largo, donde “la más común” deja de tener sentido —dos buenas respuestas nunca son idénticas—.

3. Búsqueda guiada por verificador: PRM vs ORM

Best-of-N y self-consistency generan cadenas enteras y eligen al final. Desperdician cómputo: una cadena que arrancó mal se sigue generando hasta el final aunque ya esté perdida. La búsqueda guiada corrige eso puntuando pasos intermedios y podando temprano. Para eso hay dos tipos de verificador, y la distinción es central:

ORM (Outcome Reward Model, modelo de recompensa por resultado): puntúa solo la respuesta final. “¿La solución completa está bien?” Da una nota al final del camino.
PRM (Process Reward Model, modelo de recompensa por proceso): puntúa cada paso de la cadena. “¿Este paso, dado lo anterior, es un buen paso?” Da una nota en cada bifurcación.

Con un PRM puedes hacer búsqueda sobre el árbol de razonamiento: en cada paso generas varias continuaciones, el PRM las puntúa, conservas las mejores y descartas el resto. Es una búsqueda en haz (beam search: mantener solo los k caminos más prometedores en cada nivel, en vez de explorarlos todos). El cómputo se concentra donde vale la pena en lugar de repartirse en cadenas completas que ya fracasaron.

4. Razonamiento largo entrenado

Las tres técnicas anteriores son externas: envuelven a un modelo normal con un bucle de generar-y-elegir por fuera. La cuarta es distinta y es la que define a o1/o3: el razonamiento largo vive dentro del modelo. En vez de que tú generes N cadenas y votes, el modelo fue entrenado (con aprendizaje por refuerzo, el tema del módulo 10) para generar internamente una sola cadena larguísima donde explora, se corrige, retrocede y verifica antes de escribir la respuesta. El búsqueda-y-selección no está en tu código: está horneado en los pesos. Cómo se entrena eso es exactamente el puente al módulo 10.

Diagrama: el molde común

Best-of-N y self-consistency comparten estructura. Cambia solo la caja de selección: un verificador que puntúa, o un voto que cuenta.

        GENERAR-Y-ELEGIR (best-of-N / self-consistency)

               cadena 1 ──► respuesta A
  ┌────────┐   cadena 2 ──► respuesta B    ┌───────────┐
  │ prompt │   cadena 3 ──► respuesta A ─► │ verificar │
  └───┬────┘   cadena N ──► respuesta A    │  o votar  │
      │            ▲                       └─────┬─────┘
      └────────────┘                             ▼
   N muestras (temperatura alta)           respuesta A
                                    (mejor nota, o más votada)

La búsqueda guiada por PRM cambia el molde: en vez de generar cadenas enteras y elegir al final, puntúa paso a paso y poda temprano.

        BÚSQUEDA EN ÁRBOL CON PRM (poda por paso)

               ┌────────┐
               │ prompt │
               └───┬────┘
                   ▼
               ┌───────┐
               │  PRM  │  puntúa cada continuación
               └─┬───┬─┘
            0.8  │   │  0.2 ──► podado (se descarta)
                 ▼   x
            ┌────────┐
            │ paso 2 │  se expande solo el camino bueno
            └───┬────┘
                ▼
            ┌───────┐
            │  PRM  │
            └─┬───┬─┘
         0.7  │   │  0.6
              ▼   ▼
       ┌─────────┐ ┌─────────┐
       │respuesta│ │respuesta│ ──► gana la de mayor
       └─────────┘ └─────────┘     nota acumulada

Tabla: ¿cuál técnica uso?

Técnica	¿Necesita verificador?	Costo de inferencia	Cuándo conviene
Best-of-N	Sí (duro o reward model)	N× una respuesta	Hay verificador confiable: tests, ejecución, chequeo de fórmula
Self-consistency	No	N× una respuesta	Respuesta discreta y comparable (número, opción); sin verificador
Búsqueda con PRM	Sí (un PRM, más caro de tener)	Variable, más eficiente por token	Razonamiento multipaso donde podar temprano ahorra mucho
Razonamiento largo entrenado	Interno (aprendido en el modelo)	Alto, pero ajustable por consulta	Problemas difíciles de forma general; es lo que hacen o1/o3

La primera columna es la que decide casi todo. Si tienes un verificador duro, best-of-N es imbatible por lo barato que es de implementar. Si no tienes ninguno, self-consistency es tu única opción de las externas, y solo sirve si la respuesta se puede comparar. El PRM es el más poderoso de los externos, pero tener un buen PRM es en sí mismo un proyecto de datos y entrenamiento.

El trade-off central: latencia, costo y el budget de razonamiento

Nada de esto es gratis. Cada palanca de inferencia que giras multiplica la latencia y el costo: best-of-N con N=16 es dieciséis veces más caro y más lento que una sola respuesta. Un modelo de razonamiento que “piensa” 8.000 tokens internos antes de responder te cobra esos 8.000 tokens y te hace esperar por ellos, aunque nunca los veas.

Y aquí está la parte que separa a quien usa bien estos modelos de quien los usa mal: no todo problema merece ese gasto. Preguntarle a un modelo de razonamiento “¿capital de Francia?” y dejarlo pensar 5.000 tokens es quemar plata y tiempo para algo que un modelo normal responde de un tirón. La sofisticación no es “pensar siempre mucho”, es pensar lo justo.

De ahí el concepto operativo del módulo: el budget de razonamiento (reasoning budget, presupuesto de razonamiento; cuánto cómputo de inferencia se autoriza a gastar por consulta). Los modelos de razonamiento lo exponen como un dial. En la API de OpenAI, por ejemplo, reasoning_effort toma los niveles low, medium y high (más minimal en la familia GPT-5) y controla cuántos tokens internos de razonamiento gasta el modelo antes de escribir la respuesta:

from openai import OpenAI

client = OpenAI()
# Cualquier modelo de razonamiento actual acepta reasoning_effort
# (o3-mini, el original de este dial, se retira el 23-oct-2026).

# Pregunta fácil: budget bajo. Rápido y barato, no hace falta pensar mucho.
r = client.chat.completions.create(
    model="gpt-5",
    reasoning_effort="low",
    messages=[{"role": "user", "content": "¿Cuál es la capital de Francia?"}],
)

# Problema difícil: budget alto. Más lento y caro, pero el modelo
# gasta muchos más tokens internos explorando antes de responder.
r = client.chat.completions.create(
    model="gpt-5",
    reasoning_effort="high",
    messages=[{"role": "user", "content": "Demuestra que hay infinitos "
               "primos de la forma 4k+3."}],
)

El dial reasoning_effort es la ley de escalado de inferencia hecha parámetro: low para lo trivial, high para lo que de verdad cuesta. Un sistema en producción bien diseñado enruta: clasifica la dificultad de la consulta y asigna el budget acorde, en vez de pagar high para todo o quedarse corto con low en lo difícil.

Ojo: un verificador malo no se arregla con más muestras. Best-of-N y la búsqueda guiada dependen por completo de la calidad del verificador. Si tu reward model puntúa mal —premia respuestas que suenan bien pero están equivocadas—, generar 128 candidatos en vez de 8 no te acerca a la respuesta correcta: te acerca a la respuesta que mejor engaña al verificador. Basura verificada por un mal verificador sigue siendo basura, y encima te costó 128× más. El verificador es el cuello de botella de todo el escalado de inferencia, y cuando el verificador es la recompensa que optimizas, aparece el reward hacking —el modelo aprende a explotar el hueco del verificador en vez de resolver la tarea—. Ese es exactamente el tema del módulo 11.

Errores comunes

Creer que test-time compute reemplaza al modelo grande. No lo reemplaza: lo complementa. Las dos leyes de escalado se suman. Un modelo base más capaz, pensando más, rinde más que uno flojo pensando mucho. La inferencia estira la capacidad; no la inventa de la nada.
Usar self-consistency donde la respuesta no es comparable. Votar solo funciona si puedes agrupar respuestas idénticas. Con texto libre y largo, “la más común” no existe: cada buena respuesta es distinta. Ahí necesitas un verificador, no un voto.
Escalar muestras con un verificador flojo. Más N con mal verificador amplifica el error en vez de reducirlo: encuentras la respuesta que mejor engaña al juez. Primero se arregla el verificador; después se sube N.
Confundir PRM con ORM. El ORM puntúa el resultado final; el PRM puntúa cada paso. Solo el PRM habilita búsqueda con poda temprana. Pedirle a un ORM que guíe una búsqueda paso a paso es pedirle algo que no sabe hacer.
Pensar mucho en todo. Gastar budget alto en consultas triviales dispara costo y latencia sin ganar nada. El arte está en el ruteo: budget según dificultad, no un high uniforme para toda consulta.
Olvidar que la latencia se paga aunque no se vea. Los tokens de razonamiento internos de un modelo o1/o3 se cobran y se esperan aunque nunca aparezcan en la respuesta. Un producto con presupuesto de latencia ajustado no puede ignorar ese costo oculto.

La frase para llevarse

“Entrenar un modelo más grande es comprar capacidad de una vez y para todos; dejarlo pensar más es comprarla por consulta, en caliente, a la medida del problema. La segunda palanca es tan barata y tan ajustable que cambió la carrera —siempre que tengas un verificador que sepa distinguir la buena respuesta de la que solo lo aparenta.”

Qué viene

Módulo 10: entrenar un modelo de razonamiento. Hasta acá el razonamiento largo lo pusimos por fuera (best-of-N, PRM, votos) o dimos por sentado que el modelo ya lo traía horneado. En el próximo módulo abrimos la caja: cómo se entrena a un modelo para que genere esas cadenas largas de forma interna, por qué el aprendizaje por refuerzo es el ingrediente que lo hace posible, y qué significa realmente que o1 y o3 “aprendieron a razonar” en vez de que alguien se los programó. Es el corazón del curso, y todo lo de estos nueve módulos era la preparación.

Razonamiento y RL — Módulo 9: test-time compute y el escalado de la inferencia