Cadena de pensamiento (chain of thought)

La cadena de pensamiento o chain of thought (CoT) es una secuencia de pasos intermedios que un modelo genera mientras resuelve una tarea. En prompting, puede inducirse con ejemplos razonados o una instrucción paso a paso; en modelos de razonamiento, parte de ese proceso puede ser interno. Una explicación convincente no garantiza que el razonamiento sea fiel ni que la respuesta final sea correcta.

Actualizado: 13 de julio de 2026.

Qué es una cadena de pensamiento

Una cadena de pensamiento es una serie de pasos intermedios que un modelo produce antes de una respuesta final. En el uso clásico de prompting, el usuario ofrece ejemplos que incluyen pregunta, razonamiento y solución, o pide resolver paso a paso. El objetivo es dar al modelo espacio para descomponer tareas de aritmética, lógica o planificación en operaciones más pequeñas.

El concepto se popularizó con el artículo “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models”. Sus autores mostraron que proporcionar demostraciones con razonamientos intermedios podía mejorar el rendimiento de modelos grandes en varias tareas aritméticas, simbólicas y de sentido común. El hallazgo es empírico: no demuestra que cualquier texto paso a paso sea correcto ni que funcione igual con todos los modelos.

Hoy la expresión tiene dos usos relacionados:

1. Chain-of-thought prompting: una técnica para inducir pasos mediante ejemplos o instrucciones.
2. Cadena de razonamiento de un modelo especializado: cómputo intermedio que un modelo de razonamiento genera antes de contestar y que el producto puede mantener total o parcialmente oculto.

Ejemplo de razonamiento paso a paso

Pregunta: “Una clase tiene 24 alumnos. Tres cuartas partes entregaron el trabajo y dos de esas entregas fueron rechazadas. ¿Cuántas quedaron aceptadas?”

Una descomposición breve y verificable sería:

1. Entregas: 24 × 3 / 4 = 18.
2. Aceptadas: 18 - 2 = 16.
3. Comprobación: aceptadas más rechazadas suman las 18 entregas.

La utilidad está en exponer operaciones que se pueden revisar, no en producir un monólogo extenso. Si el modelo inventa el número inicial o aplica una regla equivocada, la presencia de pasos no salva el resultado.

En una tarea real conviene pedir evidencia verificable: fórmula, cita, prueba, ejecución o condición que permita comprobar la conclusión. “Explícalo” y “demuéstralo con datos” no son equivalentes.

Formas de prompting relacionadas

El trabajo sobre self-consistency propuso muestrear varias rutas de razonamiento y elegir la respuesta más consistente en lugar de depender de una sola generación. Sus mejoras se midieron en benchmarks concretos. En producción, votar entre respuestas no reemplaza una verificación externa: varios intentos pueden compartir el mismo error.

Cómo usar CoT sin pedir razonamiento privado

No necesitas exigir una transcripción completa del proceso interno. Puedes pedir una salida útil y comprobable:

• “Da la respuesta, enumera los supuestos y muestra solo los cálculos necesarios”.
• “Separa hechos citados, inferencias y dudas”.
• “Propón un plan breve, ejecuta cada paso y verifica el resultado”.
• “Devuelve una tabla con dato, fuente y conclusión”.
• “Escribe pruebas que fallen si la solución es incorrecta”.

Este enfoque distingue justificación para el usuario de razonamiento interno del modelo. OpenAI explica en “Learning to reason with LLMs” que decidió no mostrar las cadenas de pensamiento brutas de sus modelos de razonamiento y busca trasladar las ideas útiles a la respuesta. Por tanto, un prompt que exige “muestra todo lo que pensaste” puede no corresponder al funcionamiento del producto.

Cadena de pensamiento vs. modelo de razonamiento

Una cadena de pensamiento es un tipo de traza o técnica. Un modelo de razonamiento es un modelo entrenado para dedicar cómputo adicional antes de responder. No son sinónimos.

Tampoco debe confundirse una explicación fluida con interpretabilidad mecánica. Un modelo puede generar una racionalización después de llegar a una respuesta por señales distintas. La cadena visible es texto generado y debe someterse a las mismas comprobaciones que el resto de la salida.

Por qué puede ayudar

Una tarea de varios pasos exige mantener resultados intermedios y relacionarlos. Generarlos secuencialmente puede permitir que el siguiente token se apoye en estados parciales útiles. Los ejemplos también enseñan el formato de solución y orientan al modelo hacia operaciones relevantes.

Pero “más largo” no significa “más razonado”. Un prompt demasiado detallado puede introducir supuestos, aumentar coste y crear más lugares donde equivocarse. Los beneficios suelen depender de:

• tamaño y entrenamiento del modelo;
• dificultad y estructura del problema;
• calidad y relevancia de los ejemplos;
• posibilidad de comprobar la respuesta;
• estrategia de decodificación;
• claridad de datos, restricciones y objetivo.

Límites: fidelidad y seguridad

El principal error conceptual es tratar la cadena generada como una ventana infalible al mecanismo interno. Una secuencia puede ser coherente y aun contener datos inventados, saltos lógicos o una justificación posterior. El artículo “Towards Understanding Chain-of-Thought Prompting” encontró que demostraciones con pasos inválidos todavía podían conservar gran parte del rendimiento en ciertos experimentos; la relevancia y el orden desempeñaban un papel importante. Esto cuestiona la idea de que cada palabra del razonamiento visible explique causalmente el resultado.

En sistemas con herramientas, una cadena extensa tampoco sustituye controles. Las acciones deben validarse por permisos, esquemas y estado externo. Si un agente afirma “el archivo fue guardado”, la prueba es comprobar el archivo o la respuesta de la API.

La investigación de OpenAI sobre monitoreo de cadenas de pensamiento estudia esas trazas como señal adicional para detectar comportamientos problemáticos en modelos de razonamiento. Es un contexto de evaluación y seguridad del sistema, distinto de pedir a un chatbot que revele todo su proceso para validar una respuesta cotidiana.

Cómo verificar una respuesta razonada

1. Extrae la conclusión. Escríbela de forma que pueda ser verdadera o falsa.
2. Lista los datos usados. Marca cuáles aportó el usuario y cuáles requieren fuente.
3. Comprueba cada transformación. Repite el cálculo, ejecuta el código o aplica la regla.
4. Busca una prueba independiente. Usa una segunda fuente, un caso límite o una propiedad que deba cumplirse.
5. Prueba alternativas. Pregunta qué dato cambiaría la conclusión y si existe otra explicación.
6. Registra incertidumbre. Si falta evidencia, no fuerces un veredicto.

Para matemáticas, sustituye el resultado en la condición original. Para programación, ejecuta pruebas normales, de borde y de fallo. Para investigación, abre las fuentes y verifica autor, fecha y contexto. Para decisiones sensibles, incorpora revisión humana y reglas deterministas.

Cuándo usarla y cuándo no

Puede ser útil en problemas compuestos, enseñanza, depuración, planificación y comparación de alternativas. Pide una descomposición corta cuando cada paso tenga una comprobación clara.

Evítala como ritual en preguntas simples o cuando la respuesta debe venir de una fuente autoritativa. Tampoco publiques trazas que puedan contener datos sensibles, instrucciones internas o información de seguridad. En esos casos, solicita una justificación resumida y evidencia suficiente.

Un buen resultado no es la explicación más larga. Es una conclusión correcta, con supuestos explícitos y una ruta de verificación que otra persona pueda repetir.

Fuentes primarias

• Wei et al. — “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models”.
• Wang et al. — “Self-Consistency Improves Chain of Thought Reasoning in Language Models”.
• Wang et al. — “Towards Understanding Chain-of-Thought Prompting”.
• OpenAI — “Learning to reason with LLMs”.