Chain of thought (cadena de razonamiento): pedir pasos antes de la respuesta
Chain of thought es pedir al modelo pasos intermedios antes de responder. Qué demostraron Wei y Kojima, y cuándo ayuda o estorba con modelos de razonamiento.
¿Qué es y de dónde viene?
Hay dos formas básicas. En la primera, el prompt incluye ejemplos en los que la respuesta se muestra con sus pasos. Así se introdujo la técnica en 2022: Wei y colaboradores, de Google, mostraron que con ocho ejemplos de este tipo un modelo de 540.000 millones de parámetros alcanzó el estado del arte en GSM8K, un conjunto de problemas matemáticos redactados en lenguaje natural.
En la segunda, llamada zero-shot chain of thought, no hay ejemplos: basta con agregar la frase “Pensemos paso a paso” (en el original, “Let’s think step by step”). Kojima y colaboradores (NeurIPS 2022) midieron con text-davinci-002 que la precisión pasó de 17,7 % a 78,7 % en MultiArith y de 10,4 % a 40,7 % en GSM8K. Son cifras de un modelo de aquella generación, no una promesa para los modelos de hoy.
¿Qué cambió con los modelos de razonamiento?
Los modelos de razonamiento actuales llevan esta conducta incorporada: razonan antes de contestar aunque no se lo pidas (ver modelos de razonamiento). Las guías de los proveedores lo reflejan:
- OpenAI aconseja no pedir “piensa paso a paso” a sus modelos de razonamiento, porque razonan internamente, y advierte que la instrucción puede no mejorar el resultado e incluso empeorarlo.
- Anthropic recomienda instrucciones generales como “piensa a fondo” antes que un plan escrito a mano, y deja el chain of thought manual como recurso cuando el razonamiento interno está apagado.
- Google documenta que Gemini razona internamente, que el nivel de razonamiento se ajusta (
thinking_level) y que por defecto solo se devuelve la respuesta final; los resúmenes del razonamiento se piden aparte.
La consecuencia práctica: con un modelo sin razonamiento integrado, pedir pasos todavía puede ayudar; con uno que razona, lo más probable es que solo gaste tokens. La ingeniería de prompts explica cómo comparar las tres guías; aquí interesa el efecto sobre el producto.
¿Por qué le importa a un diseñador?
Porque los pasos intermedios cambian la interfaz y la experiencia de espera:
- Tiempo. Más pasos significan más tokens de salida y más espera. Muestra un estado de progreso si la respuesta tarda.
- Confianza. Un razonamiento visible puede ayudar a verificar. Pero también puede mostrar errores intermedios que confunden si el usuario no los necesita.
- Decisión de qué mostrar. Puedes usar el razonamiento internamente, para mejorar la respuesta, y mostrar solo la conclusión y la evidencia que la sustenta.
- Costo. Cada paso cuesta. Si la mayoría de las consultas son simples, pedir razonamiento en todas encarece el producto sin beneficio visible.
¿Cuándo NO conviene?
Cuando la tarea es de clasificación, redacción, extracción directa o recuperación de un dato. El razonamiento en esos casos agrega ruido, y hay evidencia de que puede dañar:
- Sprague y colaboradores (ICLR 2025) revisaron la literatura y encontraron que el chain of thought ayuda sobre todo en matemáticas y lógica, con ganancias mucho menores en el resto.
- Liu y colaboradores (2024) probaron tareas en las que deliberar empeora el desempeño humano. En tres de seis, los modelos más avanzados rindieron peor con chain of thought, hasta 36,3 puntos porcentuales menos en uno de los casos.
Tampoco es una garantía de verdad. Turpin y colaboradores (NeurIPS 2023) mostraron que las explicaciones paso a paso pueden ocultar lo que realmente influyó en la respuesta: al sesgar el prompt, los modelos cambiaban de respuesta y su razonamiento no mencionaba el sesgo. Un trabajo posterior sobre modelos de razonamiento encontró que sus razonamientos a menudo no mencionan la pista que usaron. Por eso un texto bien razonado puede llegar a una conclusión equivocada, y por eso conviene verificar el resultado y no solo leer los pasos.
¿De qué formas se puede pedir?
| Forma | Qué incluyes en el prompt | Cuándo sirve | Costo |
|---|---|---|---|
| Sin razonamiento | Solo la tarea y el formato de respuesta | Clasificación, extracción, redacción | Mínimo |
| Frase de activación | “Razona paso a paso antes de dar la respuesta final” | Tareas de varios pasos con un modelo sin razonamiento integrado | Bajo a medio |
| Ejemplos con pasos | Dos o tres casos resueltos con su razonamiento (ver few-shot prompting) | Reglas propias del producto | Medio, más tokens de entrada |
| Modelo de razonamiento | Solo la tarea y el objetivo; el razonamiento ocurre por defecto | Problemas complejos y verificables | Alto, más latencia |
¿Cómo usarlo bien?
Un enfoque práctico:
- Identifica las tareas de varios pasos de tu producto: cálculos, reglas encadenadas, comparaciones.
- Prueba con y sin razonamiento en un conjunto de casos reales y compara precisión, tiempo y costo (ver qué son los evals).
- Pide una estructura, por ejemplo “primero identifica los datos, después aplica la regla, al final da la conclusión”. Eso hace el razonamiento más verificable.
- Separa razonamiento y respuesta en el formato de salida, para poder mostrar una sin la otra.
- Verifica el resultado final con código cuando el dato sea exacto, como un total o una fecha.
- Vuelve a probar al cambiar de modelo. Lo que ayudaba a un modelo antiguo puede estorbar en uno con razonamiento integrado.
Ejemplo
Ejemplo ilustrativo: una herramienta interna calcula si un flujo de compra cumple cinco reglas de descuento encadenadas. Con un modelo sin razonamiento integrado, el equipo prueba 40 casos y ve que en varios aplica la regla tres antes que la dos. Añaden al prompt la instrucción de evaluar las reglas en orden y de dar la conclusión al final; el error baja, pero la respuesta tarda más. El equipo decide mostrar la conclusión y, debajo, las cinco reglas evaluadas con su resultado. Un diseñador puede revisar la lógica sin leer un texto largo. El descuento exacto se calcula en código, no en el modelo.
Errores comunes
- Pedir razonamiento para tareas que no lo necesitan.
- Seguir añadiendo “piensa paso a paso” a un modelo de razonamiento por costumbre.
- Confiar en que un razonamiento bien escrito garantiza la respuesta correcta.
- Mostrar pasos intermedios a usuarios que solo necesitan el resultado.
- Medir solo la calidad y no el tiempo ni el costo adicional.
- Usar la técnica para datos que deberían venir de código o de una base de datos.
Fuentes
- Chain-of-thought prompting elicits reasoning in large language models, Wei et al. (arXiv:2201.11903)
- Large Language Models are Zero-Shot Reasoners, Kojima et al. (arXiv:2205.11916)
- To CoT or not to CoT? Chain-of-thought helps mainly on math and symbolic reasoning, Sprague et al. (arXiv:2409.12183)
- Mind Your Step (by Step): Chain-of-Thought can Reduce Performance on Tasks where Thinking Makes Humans Worse, Liu et al. (arXiv:2410.21333)
- Language Models Don’t Always Say What They Think, Turpin et al. (arXiv:2305.04388)
- Reasoning Models Don’t Always Say What They Think, Chen et al. (arXiv:2505.05410)
- OpenAI: reasoning best practices
- Anthropic: prompting best practices
- Google: Gemini thinking