Curso exprés · No. 33
Un modelo normal suelta la respuesta de una sola pasada. Pero en los problemas difíciles, dejar que primero recorra los pasos — razonar antes de responder — mejora el resultado de forma espectacular. Los reasoning models y el «test-time compute» consisten en invertir más esfuerzo en el momento de responder para obtener una mejor respuesta. Es potente para los problemas difíciles y un derroche para los fáciles — así que la habilidad está en saber cuándo subir el pensamiento.
Solo lo esencial · Una imagen por idea · Pensar tiene un precio
Toda la idea parte de una observación sencilla: un modelo que recorre un problema paso a paso lo hace mejor que uno que salta directo a la respuesta — igual que una persona.
Soltar la respuesta frente a resolverla
Un estudiante que grita el primer número que le viene a la mente 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, generándola directamente — en la práctica, soltándola sin más. Para las preguntas fáciles eso basta. Pero para cualquier cosa que requiera varios pasos de lógica, saltar directo a la respuesta es donde tropieza, igual que una persona que apura un problema difícil comete errores por descuido. El remedio es el mismo que exigen los profesores: no des solo la respuesta, recorre los pasos — y un modelo que lo hace es notablemente más preciso en los problemas difíciles.
Chain-of-thought: razonar en voz alta, paso a paso
Mostrar tu trabajo en un problema de matemáticas — escribiendo cada paso en orden — para que el razonamiento quede a la vista y un desliz a mitad de camino se detecte en lugar de quedar enterrado.
El chain-of-thought es la técnica de hacer que el modelo genere su razonamiento paso a paso antes de la respuesta final, en lugar de producir la respuesta sola. Cuando se le pide que «lo piense bien», el modelo escribe los pasos intermedios — y razonarlos de forma visible tiende a producir una conclusión correcta mucho más a menudo que saltar a ella. Los pasos no son solo para aparentar: generarlos es lo que permite al modelo construir hacia una respuesta correcta en lugar de adivinarla. Pensar sobre el papel mejora el pensamiento.
Los pasos son 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? Porque cada paso generado se convierte en contexto sobre el que el modelo puede apoyarse para el siguiente — en la práctica usa su propia salida como memoria de trabajo, partiendo un salto difícil en una cadena de movimientos pequeños y manejables. Un problema demasiado grande para resolver de un salto se vuelve resoluble como secuencia. Esta es la idea central detrás de todo este curso: dar al modelo espacio para razonar, en lugar de exigir una respuesta instantánea, es lo que desbloquea los problemas difíciles.
Un modelo que recorre los pasos supera a uno que suelta la respuesta. El chain-of-thought — razonar en voz alta, paso a paso — convierte un salto difícil en una cadena de movimientos manejables, y la precisión sigue.
Lo que empezó como un truco de prompting se convirtió en una clase de modelo. Los reasoning models están entrenados para pensar antes de responder, con el proceso paso a paso incorporado por defecto.
Modelos entrenados para pensar antes de responder
La diferencia entre alguien que responde por reflejo y alguien entrenado para detenerse y razonar primero — el hábito de pensar está incorporado en cómo trabaja, no es algo que haya que pedir.
Un reasoning model es uno entrenado específicamente para generar una cadena de pensamiento interna antes de su respuesta final — para «pensar» primero por defecto, en lugar de solo cuando se le pide. Donde un modelo estándar suelta la respuesta y un prompt de chain-of-thought lo persuade a razonar, un reasoning model lleva ese proceso paso a paso incorporado en cómo opera. Produce un tramo de razonamiento interno y luego la respuesta, y es notablemente más fuerte en los problemas que necesitan una elaboración real.
Cambian 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 invierte más esfuerzo y tiempo por respuesta, generando 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 los problemas difíciles. Es un trueque genuino, no una mejora gratuita: estás pagando — en latencia y tokens — por la profundidad del pensamiento. Así que un reasoning model no es simplemente «mejor»; es una herramienta distinta, adecuada para problemas donde el pensamiento extra se gana su coste y excesiva donde no.
Son una herramienta para problemas difíciles, no un valor por defecto
Traes al especialista de pensamiento profundo para el caso genuinamente difícil, no para responder las preguntas rutinarias de recepción — la tarea equivocada desperdicia su don.
Un reasoning model es la herramienta correcta cuando la tarea necesita de verdad un pensamiento cuidadoso de varios pasos — y la equivocada para el trabajo simple y rápido, donde su deliberación es puro derroche. Usar un reasoning model para clasificar un mensaje o reformatear algo de texto es como contratar a un filósofo para atender el teléfono: más lento y más caro sin beneficio, ya que la tarea nunca necesitó el pensamiento. El reasoning model es un instrumento potente para la franja difícil del trabajo, no un reemplazo de los modelos rápidos y ordinarios en todo lo demás.
Un reasoning model está entrenado para pensar paso a paso antes de responder — más fuerte en los problemas difíciles, más lento y más caro a cambio. Es una herramienta para los casos difíciles, no un valor por defecto para todo.
Bajo los reasoning models hay una idea más profunda que está reconfigurando cómo mejora la IA: puedes hacer mejor a un modelo no solo entrenándolo más, sino dejándolo trabajar más duro en el momento en que responde.
Invertir más esfuerzo en el momento de responder
Con más tiempo en un examen, revisas tu trabajo, pruebas otro enfoque y detectas errores — la misma persona saca mejor nota simplemente por poder dedicarle más rato.
El test-time compute significa gastar más computación en el momento de responder — en la «inference», cuando el modelo se ejecuta — para obtener un mejor resultado. En lugar de una pasada rápida, el modelo piensa más tiempo, genera más razonamiento, quizá prueba varios enfoques y elige el mejor. El hallazgo llamativo detrás de los reasoning models es que dejar a un modelo hacer más trabajo 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.
Un dial de cuánto pensar
Un termostato del esfuerzo: súbelo para el problema difícil y bájalo para el fácil, gastando exactamente tanto pensamiento como vale la tarea.
El test-time compute es un dial, no un interruptor: puedes gastar poco pensamiento o mucho, y más generalmente da mejores resultados en los problemas difíciles — hasta un punto de rendimientos decrecientes. Esto es potente porque te deja ajustar el esfuerzo a la dificultad: sube el pensamiento al máximo para el caso genuinamente difícil, mantenlo bajo para el rutinario. La capacidad de cambiar más cómputo por más precisión, por petición, es una palanca flexible — y saber que existe cambia cómo abordas las tareas difíciles.
Training-time frente a test-time
La diferencia entre un estudiante que estudia más antes del examen, y el mismo estudiante al que se le da más tiempo durante él — dos maneras distintas de obtener un mejor resultado.
Históricamente, los modelos mejoraban sobre todo entrenando más duro — más datos, modelos más grandes, hecho una vez por adelantado. El test-time compute es un eje distinto: mejorar la respuesta trabajando más duro en la inference, cada vez que el modelo se ejecuta. Importa porque es una segunda manera de obtener más capacidad — no solo un modelo más inteligente, sino el mismo modelo pensando más tiempo. Entender que la calidad puede venir del esfuerzo en training-time o en test-time te ayuda a razonar sobre de dónde viene realmente el rendimiento de un modelo — y su coste.
El test-time compute significa invertir más esfuerzo cuando el modelo responde, no solo en el entrenamiento — y más pensamiento da mejores respuestas en los problemas difíciles. Es un dial que subes para la dificultad y bajas para lo rutinario.
Razonar es potente justo donde el problema es difícil, e inútil justo donde es fácil. Saber cuál es cuál es casi todo lo que hay en usarlo bien.
Los problemas difíciles de varios pasos son los que más se benefician
Una ruta compleja con muchos giros recompensa una planificación cuidadosa; un camino recto hasta la casa de al lado, no — cuanto más difícil el trayecto, más rinde pensar.
Razonar ayuda sobre todo en problemas que de verdad requieren varios pasos de lógica para acertar: matemáticas y cálculo, planificación de varios pasos, código complejo, acertijos lógicos, análisis cuidadoso donde un paso en falso arruina la respuesta. Estas son exactamente las tareas donde soltar la respuesta falla y recorrer los pasos triunfa. Cuanto más difícil y más de varios pasos sea el problema, más mejora el resultado el pensamiento extra — por eso los reasoning models brillan en los benchmarks llenos de problemas genuinamente difíciles.
Las tareas simples no ganan nada
Deliberar largo y tendido sobre qué comer cuando estarías contento con cualquiera de las opciones — todo ese pensamiento produce la misma respuesta, más lento.
Para las 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 desperdiciado; la respuesta era obvia en una sola pasada. Peor aún, hacer que un modelo «piense» sobre una tarea trivial puede ocasionalmente empeorarla, complicando de más algo que no necesitaba deliberación. Ajusta el pensamiento al problema: las tareas fáciles quieren una respuesta rápida, no una pensada.
Ajusta la profundidad del pensamiento a la dificultad
Un buen trabajador dedica mucho tiempo a la decisión difícil y responde la fácil al instante — calibrando el esfuerzo a lo que cada una realmente requiere.
El principio rector es escalar cuánto piensa el modelo a cuán difícil es el problema. El trabajo genuinamente difícil, de alto riesgo y de varios pasos se gana 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 enrutamiento de la economía de los modelos: la mayoría de las peticiones son fáciles y quieren velocidad, una minoría son difíciles y quieren pensamiento. Mandar todo a un reasoning model es tan derrochador como mandar todo a la frontera — calibra, no recurras a un valor por defecto.
Razonar ayuda sobre todo en los problemas difíciles de varios pasos y nada en los simples. Escala la profundidad del pensamiento a la dificultad — un reasoning model para la franja difícil, un modelo rápido para la mayoría fácil.
Pensar no es gratis. Más razonamiento significa más tiempo y más tokens, e ignorar ese coste es como los equipos acaban pagando una fortuna por responder despacio preguntas fáciles.
Más pensamiento significa más tokens y dinero
Un contador que corre todo el tiempo que alguien delibera — cuanto más piensa, mayor la factura, haya hecho falta o no el pensamiento extra.
Todos esos pasos de razonamiento son tokens generados, y pagas por ellos. Un reasoning model o un ajuste alto de test-time compute produce mucho pensamiento interno antes de la respuesta, y cada token de él cuesta dinero — así que razonar es significativamente más caro por respuesta que una sola pasada directa. La profundidad que lo hace mejor en los problemas difíciles es exactamente lo que lo hace más caro. Por eso «usa el reasoning model para todo» destroza un presupuesto de IA: pagas por pensar en cada petición, incluidas las que no necesitaban ninguno.
Es más lento, lo que importa para los usuarios
El experto cuidadoso que tarda un minuto en responder vale la espera para un problema difícil, pero es exasperante si solo preguntaste la hora.
Generar todos esos pasos de razonamiento lleva tiempo, así que los reasoning models y el test-time compute intenso son más lentos — a veces mucho más lentos — en producir una respuesta. Para una tarea en segundo plano eso está bien; para un usuario que espera en una pantalla, un retraso largo es un coste real para la experiencia. Así que la latencia de pensar es parte del trueque: los segundos extra valen la pena para 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 una característica que gastas cuando subes el pensamiento.
No pagues por un pensamiento que la tarea no necesita
Contratar al pensador profundo, lento y caro para responder preguntas simples todo el día — pagas tarifas premium y esperas más por respuestas que un oficinista rápido daría al instante.
El derroche que hay que evitar es gastar el coste y la latencia del razonamiento en tareas que no se benefician. Enrutar cada petición — fáciles y difíciles por igual — a través de un reasoning model significa pagar el impuesto del pensamiento sobre todo el flujo, cuando solo una franja lo necesitaba. Se aplica la misma disciplina que la economía de los modelos: usa por defecto la vía más barata, más rápida y sin razonamiento, y escala al razonamiento solo para los casos genuinamente difíciles que se ganan su coste. Paga por pensar donde te lo devuelve, y ni un token más.
Pensar cuesta tokens y tiempo — razonar es más caro y más lento por respuesta. Paga por ello solo donde el problema difícil se lo gana; enrutar todo a través de un reasoning model grava todo el flujo por un beneficio que solo una franja necesita.
Es tentador confiar en una cadena de razonamiento larga y de aspecto cuidadoso. Pero más pasos no garantizan una respuesta correcta — un reasoning model puede estar equivocado con confianza y elaboración.
Una cadena larga puede llegar igualmente 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 prueba.
Razonar mejora las probabilidades de una respuesta correcta en los problemas difíciles; no la garantiza. Un modelo puede producir una cadena de pensamiento larga, fluida y de aspecto plausible que lleva a la conclusión equivocada — un error temprano en la cadena llevado con confianza hasta el final, o un razonamiento que suena riguroso pero no lo es. Los pasos visibles hacen que la respuesta se sienta más fiable, que es justo la trampa: más razonamiento parece más autorizado sin ser necesariamente más correcto.
El razonamiento puede no ser la razón real
Alguien que decide por una corazonada y después inventa una justificación de aspecto lógico — la explicación suena real pero no es en realidad cómo llegó ahí.
Hay una trampa más sutil: la cadena de pensamiento que un modelo muestra no está garantizado que sea el proceso real que produjo su respuesta. Puede generar un razonamiento que parece el camino a la conclusión mientras la base real era otra cosa — una racionalización de sonido plausible más que un relato fiel. Así que no puedes confiar del todo en el 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 lógica verdadera del modelo.
Verifica la respuesta, no confíes en el pensamiento
Compruebas un cálculo complejo confirmando el resultado de forma independiente, no admirando lo pulcro que se ve el desarrollo — lo que cuenta es la corrección de la respuesta.
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. Todas las disciplinas de otros lugares siguen aplicando — ánclalo en hechos reales, contrástalo con las fuentes, ejecuta evals, mantén a un humano en las decisiones de alto riesgo. Razonar hace más probable que las respuestas difíciles sean correctas; no las hace seguras de confiar sin verificar. Una cadena de pensamiento segura sigue siendo una conjetura segura hasta que hayas comprobado dónde aterrizó.
Más razonamiento mejora las probabilidades, no la garantía — una cadena larga puede llegar a una respuesta errónea, y los pasos mostrados pueden no ser la razón real. Verifica la respuesta; no confíes en el pensamiento.
Razonar es una capacidad potente con un precio claro, así que usarlo bien es la disciplina ya familiar: gasta el pensamiento donde rinde, y verifica lo que produce.
Sube el pensamiento solo para la parte difícil
Te concentras a fondo en el único paso peliagudo y pasas el resto con soltura — enfocando tu esfuerzo donde está de verdad la dificultad, no repartiéndolo por igual.
El movimiento unificador es ajustar el pensamiento a la dificultad por todo tu sistema: recurre a un reasoning model o a más test-time compute en las tareas genuinamente difíciles, de varios pasos y de alto riesgo, y usa modelos estándar rápidos para la mayoría fácil. Incluso puedes combinarlos — un modelo rápido lleva la vía rutinaria y delega los subproblemas difíciles a un reasoning model. Gastar deliberación donde el problema es difícil, y solo ahí, te da la mejora de precisión sin pagar el impuesto del pensamiento en todo.
Razonar eleva la precisión; no reemplaza la verificación
Un experto cuidadoso tiene más probabilidades de acertar, pero aun así confirmas la decisión de alto riesgo — su esmero mejora las probabilidades, no elimina la necesidad de comprobar.
La disciplina final ata este curso al resto: razonar mejora la calidad en los problemas difíciles, pero sigue siendo un modelo falible que puede estar equivocado con confianza, así que todo lo demás sigue importando. Ánclalo, verifica la respuesta, ejecuta evals, mantén a humanos en las decisiones de peso. Razonar es una manera más de obtener mejores salidas — junto a un buen contexto, la recuperación y el modelo adecuado — no una mejora mágica que elimine la necesidad de ingeniar fiabilidad a su alrededor. Mejor pensamiento es un ingrediente más fuerte, no un plato terminado.
- ¿Es el problema genuinamente difícil — lógica de varios pasos, matemáticas, planificación — que el pensamiento desenredaría? - ¿O es simple — donde razonar solo añade retraso y coste sin ganancia? - ¿Valen aquí el coste y la latencia, o estás gravando tareas fáciles con pensamiento? - ¿Estás enrutando — razonamiento para la franja difícil, modelos rápidos para la mayoría fácil? - ¿Estás verificando la respuesta, en lugar de confiar en una cadena de pensamiento de aspecto exhaustivo? - ¿Siguen aplicando las disciplinas habituales — anclaje, evals, un humano en las decisiones de alto riesgo?
- chain-of-thought — hacer que el modelo razone paso a paso antes de la respuesta final. - reasoning model — un modelo entrenado para pensar primero por defecto, más fuerte en los problemas difíciles. - test-time compute / inference — invertir más esfuerzo cuando el modelo responde para obtener un mejor resultado. - el dial del pensamiento — ajustar cuánto delibera el modelo, de un poco a mucho. - training-time frente a test-time — mejorar entrenando más, frente a trabajar más duro en el momento de responder. - el coste de pensar — más razonamiento significa más tokens, dinero y latencia. - razonar no es verdad — una cadena larga puede estar igualmente equivocada con confianza; verifica la respuesta.
- Subes el pensamiento solo para los problemas genuinamente difíciles, no por defecto. - Usas modelos rápidos para la mayoría fácil y reservas el razonamiento para la franja difícil. - Contemplas el coste y la latencia del razonamiento en lugar de gravar cada petición. - Verificas la respuesta en lugar de confiar en lo exhaustivo que parece el razonamiento. - Sigues aplicando anclaje, evals y supervisión humana — razonar afina, no los reemplaza.
Razonar deja que un modelo piense antes de responder, elevando la precisión en los problemas difíciles a costa de tiempo y tokens. Sube el pensamiento solo donde la dificultad se lo gana, y verifica la respuesta — mejor pensamiento sigue siendo una conjetura falible hasta que se comprueba.