En el módulo 7 cerramos la maquinaria de alineamiento: DPO (optimización directa de preferencias), GRPO (optimización de política por grupos, la que compara varias respuestas a un mismo prompt y premia las mejores del grupo) y su familia. Con eso terminamos de responder cómo se ajusta un modelo para que prefiera unas respuestas sobre otras. Este módulo abre un bloque distinto del curso: el de razonamiento. Y empieza por la pregunta más básica y más maltratada de todo el tema, esa que aparece en cada titular sin que casi nadie la defina: ¿qué quiere decir que un modelo de lenguaje “razona”? Primero vamos a entender qué es el razonamiento en un LLM (este módulo y el 9); después, con GRPO ya en la mano, veremos cómo se entrena para que aparezca solo (módulo 10). Así que este es el momento conceptual: antes de entrenar la capacidad, hay que entender qué capacidad es.

La tentación es tratar “razonar” como un adjetivo de marketing. No lo es. Detrás hay un mecanismo concreto, casi mecánico, que se explica sin misticismo y que, una vez que lo ves, vuelve obvio por qué pedirle a un modelo que “piense paso a paso” mejora sus respuestas en tareas donde la respuesta directa fracasa. La clave no está en la inteligencia: está en el cómputo.

La tesis del módulo

Un modelo que responde de inmediato entrega su primera intuición en un solo paso de cómputo; el chain-of-thought le da espacio para desplegar el cálculo en varios pasos, y hay tareas que simplemente no caben en un solo paso — razonar es, en gran parte, comprarse más cómputo con más tokens.

Un token es una cantidad fija de cómputo

Acá está la idea que sostiene todo el módulo, y conviene decirla despacio porque es contraintuitiva. En un Transformer (la arquitectura de los LLM, la que vimos entera en la arquitectura completa), generar un token —una unidad de texto, aproximadamente una sílaba o una palabra corta— cuesta exactamente una pasada por la red. Ni más ni menos. El modelo tiene un número fijo de capas; para producir el siguiente token, la información recorre esas capas una sola vez y sale una predicción. Ese recorrido es la totalidad del “pensamiento” disponible para ese token.

Esto tiene una consecuencia enorme que casi nunca se explicita: el modelo no puede pensar más rato sobre un token difícil que sobre uno fácil. Escribir la palabra “el” y calcular el resultado de una multiplicación de tres dígitos consumen el mismo presupuesto de cómputo: una pasada. No hay un botón de “espera, déjame pensar esto mejor” dentro de una sola pasada. La red no tiene bucles internos donde deliberar; tiene una profundidad fija y punto.

Entonces, ¿qué pasa cuando una pregunta necesita varios pasos de deducción encadenados? Por ejemplo: “Ana tiene el triple de años que Beto; en cinco años, entre los dos sumarán 50; ¿cuántos años tiene Ana?”. Resolver eso requiere plantear una ecuación, despejar, sustituir. Son tres o cuatro operaciones que dependen una de la otra. Si le pedimos al modelo que suelte el número final directamente, le estamos exigiendo hacer todas esas operaciones dentro de una sola pasada, en el mismo presupuesto de cómputo que gastaría en escribir “el”. A veces le alcanza —para problemas que vio mil veces la respuesta ya está casi memorizada—, pero cuando la cadena de razonamiento es más larga que lo que cabe en una pasada, no hay dónde hacer el cálculo. Y sin lugar donde calcular, el modelo hace lo único que sabe hacer sin cómputo: adivina la respuesta más plausible. Su primera intuición.

Ahora viene el truco, y es de una simplicidad casi decepcionante. Un LLM es autorregresivo: genera un token, lo agrega a lo que ya escribió, y usa todo eso —incluido lo que él mismo acaba de escribir— como entrada para generar el siguiente. Es decir: cada token que produce es una nueva pasada por la red, y esa pasada puede leer todos los tokens anteriores. Si el modelo escribe primero “Ana tiene 3B años”, ese texto queda en el contexto, y la pasada que genera el token siguiente puede apoyarse en ese resultado intermedio para dar el próximo paso. Los tokens del razonamiento no son un comentario decorativo: son el espacio de cálculo. Cada paso escrito es una pasada más de cómputo que el modelo se regala a sí mismo.

Dicho de la forma más cruda posible: escribir más tokens antes de la respuesta es, literalmente, comprar más cómputo. El razonamiento en texto convierte un problema que no cabía en una pasada en una secuencia de subproblemas, cada uno chico y cada uno con su propia pasada.

Chain-of-thought: escribir el razonamiento

El chain-of-thought (CoT, “cadena de pensamiento”: la práctica de que el modelo escriba los pasos intermedios de su razonamiento antes de dar la respuesta final) es exactamente la técnica que explota lo anterior. En su forma más simple es una frase agregada al prompt: “pensemos paso a paso”. Ese pequeño empujón cambia el comportamiento del modelo: en vez de saltar al número final, empieza a escribir el desarrollo. Y al escribirlo, se da los pasos de cómputo que necesitaba.

El efecto medible es grande, y se concentra en un tipo de tarea muy específico: las que requieren varios pasos dependientes. Aritmética de varios dígitos, problemas de lógica, acertijos con restricciones, razonamiento con sentido común encadenado, planificación. En todas ellas el CoT sube la exactitud de forma notoria, a veces de “casi nunca acierta” a “acierta la mayoría”. En cambio, en tareas de un solo paso —“¿de qué color es el cielo?”, clasificar el sentimiento de una frase, recuperar un dato— el CoT no aporta nada o incluso estorba: gastas tokens y latencia para llegar a algo que la primera intuición ya tenía bien.

Hay que distinguir dos versiones del CoT que se confunden todo el tiempo:

CoT por prompting. Tú se lo pides. Escribes “pensemos paso a paso” o le das ejemplos resueltos con su desarrollo, y el modelo imita ese formato. No cambiaste el modelo: cambiaste lo que le pediste. Funciona en cualquier LLM razonablemente capaz y no cuesta nada montarlo. Es lo que puede hacer cualquiera hoy mismo.
CoT entrenado. El modelo razona solo, sin que se lo pidas, porque fue entrenado con refuerzo para hacerlo. Este es el salto de los modelos de razonamiento modernos, y es justo lo que veremos en el módulo 10: se usa RL —con GRPO, el del módulo 7— para premiar las cadenas de razonamiento que llegan a la respuesta correcta. El modelo aprende, por sí mismo, que desplegar el cálculo le conviene. No imita un formato: descubrió una estrategia.

La diferencia importa para el resto del curso. El CoT por prompting es una técnica de uso; el CoT entrenado es una capacidad instalada. Este módulo y el 9 tratan del primero —el fenómeno, qué es, cómo se mide—; el 10 trata del segundo —cómo se fabrica—.

     RESPUESTA DIRECTA vs CON RAZONAMIENTO

 prompt                     prompt
   │                          │
   ▼                          ▼
 ┌──────────────┐        ┌──────────────┐
 │  1 pasada    │        │  paso 1      │
 │  (1 token de │        │  (pasada)    │
 │   cómputo)   │        └──────┬───────┘
 └──────┬───────┘               ▼
        │                ┌──────────────┐
        │                │  paso 2      │
        │                │  (pasada)    │
        │                └──────┬───────┘
        │                       ▼
        │                ┌──────────────┐
        │                │  paso 3      │
        │                │  (pasada)    │
        │                └──────┬───────┘
        ▼                       ▼
 ┌──────────────┐        ┌──────────────┐
 │  respuesta   │        │  respuesta   │
 │  (a veces    │        │  (apoyada en │
 │   mal)       │        │   los pasos) │
 └──────────────┘        └──────────────┘

 mismo presupuesto        más pasadas =
 para todo               más cómputo

El diagrama tiene toda la lección. A la izquierda, el modelo tiene una sola pasada para ir del prompt a la respuesta, sin importar cuán difícil sea; si el problema no cabe, adivina. A la derecha, cada paso intermedio es una pasada nueva que lee las anteriores, y la respuesta final se apoya en un cálculo que ya quedó escrito. No es que el modelo de la derecha sea “más listo”: tuvo más lugar donde pensar.

Sistema 1 y Sistema 2: la metáfora útil (y su límite)

Hay una analogía que ayuda a fijar la intuición y que vas a escuchar seguido, así que conviene tenerla con su etiqueta y su asterisco. Viene de la psicología de la decisión: Sistema 1 es el pensamiento rápido, automático, intuitivo —el que reconoce una cara o contesta “cuánto es 2+2” sin esfuerzo—; Sistema 2 es el lento, deliberado, esforzado —el que resuelve “17 × 24” o planifica una ruta—.

La respuesta directa de un LLM se parece al Sistema 1: sale de una, sin deliberación, y es buena para lo que ya está “cableado”. El chain-of-thought se parece al Sistema 2: es lento, cuesta más, y sirve para lo que requiere pasos. Como imagen para explicarle a alguien por qué pedir razonamiento mejora las cuentas, es perfecta.

Ojo: es una analogía, no un mecanismo. El modelo no tiene “dos sistemas” adentro ni cambia de circuito cuando razona. Es la misma red, la misma pasada por token, en los dos casos. Lo único que cambia es cuántas pasadas encadena antes de responder. Usa Sistema 1/2 para comunicar la idea, nunca como explicación de lo que pasa por dentro: por dentro solo hay tokens y pasadas.

Más de una cadena: adelanto de self-consistency

Si escribir una cadena de razonamiento ayuda, ¿ayudaría escribir varias? Esa es la pregunta que abre la técnica de self-consistency (“autoconsistencia”): en vez de generar una sola cadena de pensamiento, se generan varias —cada una con algo de aleatoriedad, así toman caminos distintos— y se toma la respuesta que aparece más veces, una especie de votación.

La intuición es la de un tribunal: si tres razonamientos independientes llegan al mismo número, ese número es más confiable que el de una sola cadena que pudo haberse desviado en un paso. Un error de cálculo suele ser idiosincrático —cada cadena se equivoca a su manera—, mientras que la respuesta correcta tiende a repetirse. Votar filtra los desvíos. Acá solo la nombramos para que la tengas ubicada; el módulo 9 la desarrolla junto con las demás formas de gastar cómputo en el momento de responder.

Los límites honestos del CoT

El entusiasmo con el razonamiento en texto viene con letra chica, y omitirla sería venderte humo. Tres reparos que hay que tener siempre presentes.

Primero: el CoT no garantiza que el modelo “piense de verdad”. Que escriba pasos con pinta de deducción no prueba que esté deduciendo; en muchos casos está generando texto que se parece a un razonamiento válido porque vio millones de razonamientos parecidos. A veces los pasos son correctos y la respuesta igual está mal, o al revés. La forma del razonamiento no certifica su validez.

Segundo, y más incómodo: la faithfulness (“fidelidad”: qué tanto el razonamiento escrito refleja de verdad el proceso por el que el modelo llegó a la respuesta). Hay evidencia de que a veces no son fieles: el modelo decide la respuesta por un camino y después escribe una justificación distinta, plausible, que no fue lo que realmente lo llevó ahí. Es como un estudiante que adivinó y después inventa el “desarrollo” para el profesor. Esto importa muchísimo cuando quieres usar el CoT como explicación auditable de una decisión: puede ser una narración post-hoc, no un registro del cálculo.

Tercero, lo práctico: razonar alarga y encarece. Cada paso son tokens, y los tokens son latencia y plata. Un modelo que despliega treinta líneas de razonamiento para responder “¿qué hora es en Tokio?” es un mal negocio. El CoT es una herramienta con costo, no un ajuste que se deja siempre encendido “por las dudas”.

Cuidado: no confundas razonamiento legible con razonamiento fiel. Que puedas leer los pasos no significa que esos pasos sean la causa real de la respuesta. Si vas a mostrarle el chain-of-thought a un usuario o a un auditor como si fuera la explicación de la decisión, estás asumiendo una fidelidad que el modelo no te garantiza. Trátalo como una pista de cómo razona, no como un acta.

¿Respuesta directa o chain-of-thought?

No es que uno sea siempre mejor. Es una decisión por tarea, y estos son los ejes:

Eje	Respuesta directa	Chain-of-thought
Cómputo por respuesta	Una pasada (fijo)	Muchas pasadas (crece con los pasos)
Latencia y costo	Bajos	Altos (más tokens)
Tareas de un solo paso	Igual de buena	No aporta, a veces estorba
Aritmética / lógica multi-paso	Falla seguido	Mejora fuerte
Planificación, acertijos con restricciones	Pobre	Necesario
Recuperar un dato memorizado	Ideal	Desperdicio
Auditar la decisión	Nada que leer	Pasos legibles (ojo: no siempre fieles)

La regla operativa que sale de la tabla es simple: usa CoT cuando la tarea tenga pasos dependientes; no lo uses cuando la respuesta salga de una. Y cuando lo uses, ten claro que estás pagando cómputo a cambio de exactitud —un intercambio que a veces vale toda la plata del mundo y a veces es puro derroche—.

Errores comunes

Creer que “razonar” es que el modelo sea más inteligente. No: es que el modelo se da más pasos de cómputo. La capacidad no cambia; el presupuesto de cálculo sí. Confundir las dos cosas lleva a esperar milagros donde solo hay más tokens.
Poner “pensemos paso a paso” en todo. En tareas de un solo paso no ayuda, y gastas latencia y plata para nada. El CoT es para problemas con pasos dependientes, no un condimento universal.
Leer el chain-of-thought como si fuera la verdad de cómo el modelo decidió. La faithfulness no está garantizada: los pasos escritos pueden ser una justificación posterior, no el cálculo real. Auditar sobre esa base es engañarse.
Confundir CoT por prompting con CoT entrenado. Pedirlo (prompting) y que salga solo tras RL (entrenado) son cosas distintas. La primera la haces hoy con cualquier modelo; la segunda es una capacidad que se fabrica, y es el tema del módulo 10.
Suponer que más pasos siempre es mejor. Pasado cierto punto, alargar el razonamiento no mejora la respuesta y sí infla el costo. Más cómputo ayuda hasta donde el problema lo pide; más allá es solo cuenta más cara.
Ignorar que el CoT tiene un costo real. Cada paso son tokens, y los tokens son plata y demora. Encender el razonamiento “por si acaso” en producción es una decisión de costo, no un ajuste gratis.

La frase para llevarse

“Un LLM no piensa más rato sobre un token difícil: piensa lo mismo sobre cada uno. Razonar es escribir los pasos para regalarse una pasada de cómputo por cada uno — no es ser más listo, es darse más lugar donde pensar.”

Qué viene

Módulo 9: test-time compute, o cómo gastar cómputo en el momento de responder para acertar más. Si este módulo mostró que más tokens compran más cálculo, el próximo convierte esa idea en un dial: cuánto conviene pensar, cuándo detenerse, y las técnicas que exprimen ese presupuesto. Vamos a desarrollar la self-consistency que acá solo nombramos —muestrear varias cadenas y votar—, y a ver por qué a veces conviene una sola cadena larga y a veces muchas cortas. Es la otra mitad del “qué es razonar” antes de pasar, en el módulo 10, al “cómo se entrena”.

Razonamiento y RL — Módulo 8: por qué un LLM 'razona'