El mapa: 20 conceptos en siete grupos

Un mapa de metro: primero ves las líneas enteras, luego recorres estación por estación.

Primero, tres bases: cómo responde un modelo por defecto, qué es el chain-of-thought y por qué ayudan los pasos. Después seis grupos, uno por capítulo: reasoning models, test-time compute, cuándo ayuda razonar, el coste de pensar, por qué razonar no es verdad y cómo usarlo bien.

Cada concepto que sigue tiene la misma forma: su nombre en inglés (recuérdalo — es el término), una imagen de la vida real, un diagrama y una ficha con campos como qué es, idea, ejemplo, trampa y relaciones.

Single-pass Answer — soltarlo todo de golpe

Un estudiante que grita el primer número que se le ocurre frente a otro que primero resuelve el problema en papel de borrador — el segundo acierta mucho más a menudo.

Por defecto, un modelo produce su respuesta en una sola pasada: genera la respuesta directamente — en la práctica, la suelta de golpe. Para preguntas fáciles eso basta. Pero en cualquier cosa que exija varios pasos de lógica, saltar directo a la respuesta es donde tropieza, igual que una persona que se apresura con un problema difícil comete errores descuidados. La solución es la que exigen los profesores: no des solo la respuesta, recorre los pasos.

Chain-of-Thought (CoT) — razonar en voz alta, paso a paso

Mostrar tu trabajo en un problema de matemáticas — escribir cada paso en orden — para que el razonamiento quede a la vista y un desliz a mitad de camino se detecte en vez de quedar enterrado.

El chain-of-thought (CoT) es la técnica de hacer que el modelo genere su razonamiento paso a paso antes de la respuesta final, en lugar de producir solo la respuesta. Si se le pide que «lo piense bien», el modelo escribe los pasos intermedios — y razonar a través de ellos suele dar una conclusión correcta con mucha más frecuencia que saltar a ella. Los pasos no son solo decoración: generarlos es lo que permite al modelo construir una respuesta correcta en vez de adivinarla. Pensar sobre la página mejora el pensamiento.

Working Memory — en los pasos es donde ocurre el trabajo

Un cálculo largo hecho de cabeza es propenso a errores; el mismo cálculo en papel, una línea cada vez, es fiable — el papel sostiene lo que la mente dejaría caer.

¿Por qué ayuda escribir los pasos? Cada paso generado se convierte en contexto sobre el que el modelo puede construir el siguiente. En la práctica usa su propia salida como working memory, rompiendo un salto difícil en una cadena de movimientos pequeños y manejables. Un problema demasiado grande para resolverlo de un salto se vuelve resoluble como secuencia. Esta es la idea central de todo el curso: dar al modelo espacio para razonar, en lugar de exigirle una respuesta instantánea, es lo que desbloquea los problemas difíciles.

Reasoning Model — un modelo entrenado para pensar antes de responder

La diferencia entre quien responde por reflejo y quien está entrenado para detenerse y razonar primero — el hábito de pensar está integrado en su forma de trabajar, no es algo que haya que pedirle.

Un reasoning model es un modelo entrenado específicamente para generar una cadena de pensamiento interna antes de su respuesta final — para «pensar» primero por defecto, y no solo cuando se le pide. Un modelo estándar suelta la respuesta; un prompt de chain-of-thought lo anima a razonar; un reasoning model lleva ese proceso incorporado. Produce un tramo de razonamiento interno y luego la respuesta, y es notablemente más fuerte en problemas que exigen un trabajo real de elaboración.

Speed–Depth Trade-off — cambiar velocidad por profundidad

Un experto cuidadoso que se toma un minuto para pensar antes de responder da mejores respuestas que uno rápido que contesta al instante — pero hay que esperarlo.

Un reasoning model gasta más esfuerzo y tiempo por respuesta, porque genera todos esos pasos internos antes de responder. Eso lo hace más lento y más caro que un modelo estándar, a cambio de ser mejor en problemas difíciles. Es un compromiso de verdad, no una mejora gratis: pagas — en latencia y en tokens — por la profundidad del pensamiento. Así que un reasoning model no es simplemente «mejor»; es otra herramienta.

Tool, not Default — una herramienta para problemas difíciles, no el valor por defecto

Llamas al especialista de pensamiento profundo para el caso genuinamente difícil, no para responder las preguntas rutinarias de recepción — el trabajo equivocado malgasta su talento.

Un reasoning model es la herramienta adecuada cuando la tarea exige de verdad un pensamiento cuidadoso y de varios pasos — y la equivocada para trabajo simple y rápido, donde su deliberación es puro desperdicio. Usarlo para clasificar un mensaje o reformatear un texto es como contratar a un filósofo para atender el teléfono: más lento y más caro sin ningún beneficio, porque la tarea nunca necesitó pensar. Es un instrumento potente para la parte difícil del trabajo, no un sustituto de los modelos rápidos en todo lo demás.

Test-time Compute — gastar más esfuerzo al responder

Con más tiempo en un examen, repasas tu trabajo, pruebas otro enfoque y pillas errores — la misma persona saca más nota solo por poder dedicar más tiempo.

El test-time compute significa gastar más cómputo en el momento de responder — en la inferencia, cuando el modelo se ejecuta — para obtener un mejor resultado. En vez de una pasada rápida, el modelo piensa más tiempo, genera más razonamiento, quizá prueba varios enfoques y se queda con el mejor. El hallazgo llamativo detrás de los reasoning models es que dejar que un modelo trabaje más cuando responde mejora la calidad, igual que dar a una persona más tiempo en un problema difícil. Puedes comprar mejores respuestas con más pensamiento, no solo con más entrenamiento.

Effort Dial — un dial para cuánto pensar

Un termostato del esfuerzo: súbelo para el problema difícil y bájalo para el fácil, gastando justo el pensamiento que la tarea merece.

El test-time compute es un dial, no un interruptor: puedes gastar poco pensamiento o mucho, y en general más da mejores resultados en problemas difíciles — hasta un punto de rendimientos decrecientes. En las APIs este dial suele llamarse reasoning effort o thinking budget. Su poder está en que puedes ajustar el esfuerzo a la dificultad en cada petición: súbelo para el caso genuinamente difícil, mantenlo bajo para el rutinario.

Train-time vs Test-time Compute — dos ejes de mejora

Un estudiante que estudia más antes del examen, y el mismo estudiante al que se da más tiempo durante él — dos maneras distintas de lograr un mejor resultado.

Históricamente, los modelos mejoraban sobre todo con el entrenamiento — más datos, modelos más grandes, hecho una sola vez al principio. El test-time compute es un eje distinto: mejorar la respuesta trabajando más duro en la inferencia, cada vez que el modelo se ejecuta. Es una segunda forma de obtener más capacidad — no solo un modelo más listo, sino el mismo modelo pensando más tiempo. Conocer ambos ejes ayuda a razonar de dónde viene realmente la calidad de un modelo — y su coste.

Multi-step Problems — donde pensar rinde

Una ruta compleja con muchos giros premia la planificación cuidadosa; una carretera recta hasta la casa de al lado no — cuanto más difícil el camino, más rinde pensar.

Razonar ayuda más en los problemas de varios pasos que de verdad exigen varios pasos de lógica: matemáticas y cálculo, planificación de varios pasos, código complejo, acertijos lógicos, análisis cuidadoso donde un solo paso equivocado arruina la respuesta. Son justo las tareas donde soltar la respuesta falla y recorrer los pasos funciona. Cuanto más difícil y de más pasos es el problema, más mejora el resultado con el pensamiento extra — por eso los reasoning models brillan en benchmarks llenos de problemas genuinamente difíciles.

Overthinking — las tareas simples no ganan nada

Deliberar largo rato sobre qué comer cuando te harían feliz las dos opciones — todo ese pensamiento produce la misma respuesta, más lenta.

En tareas simples y directas — clasifica esto, extrae aquello, reformatea este texto, responde una pregunta factual básica — razonar no añade más que retraso y coste. No hay lógica de varios pasos que recorrer, así que el pensamiento es movimiento inútil; la respuesta era obvia en una pasada. Peor aún, hacer que un modelo «piense» sobre una tarea trivial puede, en ocasiones, empeorarlo — piensa de más, complicando algo que no necesitaba deliberación.

Difficulty Matching — ajustar la profundidad del pensamiento a la dificultad

Un buen trabajador dedica mucho tiempo a la decisión difícil y responde al instante la fácil — calibrando el esfuerzo a lo que cada cosa exige de verdad.

El principio rector es el difficulty matching: ajusta cuánto piensa el modelo a lo difícil que es el problema. El trabajo genuinamente difícil, de alto riesgo y de varios pasos merece un reasoning model o más test-time compute; el trabajo simple, rutinario y bien acotado recibe un modelo estándar rápido. Esto refleja la idea de routing de la economía de modelos: la mayoría de las peticiones son fáciles y piden velocidad, una minoría son difíciles y piden pensamiento. Enviarlo todo a un reasoning model es tan derrochador como enviarlo todo al modelo de frontera — calibra, no uses lo mismo por defecto.

Reasoning Tokens — más pensamiento significa más tokens y dinero

Un contador que corre todo el rato que alguien delibera — cuanto más piensa, mayor la factura, haga falta o no ese pensamiento extra.

Todos esos pasos de razonamiento son tokens generados — reasoning tokens — y los pagas. Un reasoning model, o un ajuste alto de test-time compute, produce mucho pensamiento interno antes de la respuesta, y cada token cuesta dinero. Así que razonar es bastante más caro por respuesta que una sola pasada directa. La profundidad que lo hace mejor en problemas difíciles es justo lo que lo encarece. Por eso «usa el reasoning model para todo» arruina un presupuesto de IA.

Latency — es más lento, y los usuarios lo notan

El experto cuidadoso que tarda un minuto en responder vale la espera en un problema difícil, pero desespera si solo preguntaste la hora.

Generar todos esos pasos lleva tiempo, así que los reasoning models y el test-time compute pesado son más lentos — a veces mucho más — en producir una respuesta. Eso es la latency. Para una tarea en segundo plano está bien; para un usuario esperando ante una pantalla, un retraso largo es un coste real para la experiencia. Los segundos extra valen la pena en un problema difícil que el usuario espera que lleve un momento, y encajan mal en una interacción que debería sentirse instantánea. La velocidad es algo que gastas al subir el pensamiento.

Thinking Tax — no pagues por pensamiento que la tarea no necesita

Contratar al pensador profundo, lento y caro para responder preguntas simples todo el día — pagas tarifa premium y esperas más por respuestas que un oficinista ágil daría al instante.

El desperdicio que hay que evitar es gastar el coste y la latencia del razonamiento en tareas que no se benefician. Pasar todas las peticiones — fáciles y difíciles por igual — por un reasoning model significa pagar el thinking tax en todo el flujo, cuando solo una parte lo necesitaba. Aplica la misma disciplina que en la economía de modelos: usa por defecto el camino más barato, más rápido y sin razonamiento, y escala al razonamiento solo en los casos genuinamente difíciles que se ganan su coste. Paga por pensar donde te devuelve algo, y ni un token más.

Confidently Wrong — una cadena larga aún puede llegar a una respuesta errónea

Un argumento detallado y seguro construido sobre una premisa defectuosa — cada paso encaja con pulcritud, y la conclusión sigue siendo errónea. El pulido no es una prueba.

Razonar mejora las probabilidades de una respuesta correcta en problemas difíciles; no garantiza una. Un modelo puede producir una cadena de pensamiento larga, fluida y de aspecto plausible que lleva a la conclusión equivocada — un error al principio de la cadena arrastrado con seguridad hasta el final, o un razonamiento que suena riguroso pero no lo es. Los pasos visibles hacen que la respuesta parezca más fiable, y esa es justo la trampa: más razonamiento parece más autoritativo sin ser necesariamente más correcto.

Unfaithful Reasoning — el razonamiento mostrado puede no ser la razón real

Alguien que decide por corazonada y luego inventa una justificación de sonido lógico — la explicación suena real, pero no es como llegó de verdad.

Hay una trampa más sutil: la cadena de pensamiento que muestra un modelo no tiene por qué ser el proceso real que produjo su respuesta. Puede generar un razonamiento que parece el camino hacia la conclusión cuando la base real era otra — una racionalización de apariencia plausible en vez de un relato fiel. Esto se llama unfaithful reasoning, y la propiedad de una cadena honesta es la faithfulness. Así que no puedes fiarte del todo del razonamiento mostrado como explicación de por qué la respuesta es la que es. Es una señal útil y una ayuda para la precisión, no una ventana garantizada a la verdadera lógica del modelo.

Verify the Answer — comprueba el resultado, no admires el pensamiento

Compruebas un cálculo complejo confirmando el resultado de forma independiente, no admirando lo pulcro que se ve el procedimiento — lo que cuenta es que la respuesta sea correcta.

La conclusión práctica: juzga la salida de un reasoning model por si la respuesta es correcta, verificada contra la realidad, no por lo impresionante que se vea el razonamiento. Siguen valiendo todas las disciplinas de otros capítulos — ancla la respuesta en hechos reales, contrástala con fuentes, ejecuta evals, mantén a una persona en las decisiones de alto riesgo. Razonar hace más probable que las respuestas difíciles sean correctas; no las hace seguras de creer sin verificar. Una cadena de pensamiento segura sigue siendo una conjetura segura hasta que compruebas dónde aterrizó.

Routing & Escalation — sube el pensamiento solo para la parte difícil

Te concentras a fondo en el único paso complicado y pasas volando por el resto — enfocando el esfuerzo donde está de verdad la dificultad, no repartiéndolo por igual.

El movimiento unificador es ajustar el pensamiento a la dificultad en todo tu sistema. Eso es el routing: un reasoning model o más test-time compute en las tareas genuinamente difíciles, de varios pasos y de alto riesgo, y modelos estándar rápidos para la mayoría fácil. Incluso puedes mezclarlos — un modelo rápido se ocupa del camino rutinario y escala los subproblemas difíciles a un reasoning model. Gastar la deliberación donde el problema es difícil, y solo ahí, te da la ganancia de precisión sin pagar el thinking tax en todo.

Ingredient, not Finished Dish — razonar no sustituye a verificar

Un experto cuidadoso tiene más probabilidades de acertar, pero aun así confirmas la decisión de alto riesgo — su cuidado mejora las probabilidades, no elimina la necesidad de comprobar.

La disciplina final conecta este curso con el resto: razonar mejora la calidad en problemas difíciles, pero sigue siendo un modelo falible que puede estar equivocado con total seguridad, así que todo lo demás sigue importando. Ancla la respuesta, verifícala, ejecuta evals, mantén a personas en las decisiones con consecuencias. Razonar es una forma más de obtener mejores salidas — junto con un buen contexto, la recuperación y el modelo adecuado — no una mejora mágica que elimine la necesidad de diseñar fiabilidad a su alrededor. Pensar mejor es un ingrediente más fuerte, no un plato terminado.

Cómo encaja todo

Una palanca con tres consecuencias: trae una ganancia, cuesta dinero y conlleva un riesgo — úsala con las tres en mente.

El chain-of-thought está incorporado en el reasoning model, y el reasoning model es una forma de test-time compute. Esa palanca tiene tres consecuencias: una ganancia en problemas de varios pasos, un coste en tokens y latencia, y un riesgo de razonamiento erróneo con seguridad o unfaithful. Usarla bien significa apuntar a la ganancia (difficulty matching, routing), ceñirse a un presupuesto (sin thinking tax) y comprobar el resultado (verify the answer).