Definición en una frase
Secuencia intermedia de razonamiento, visible o interna, que descompone un problema antes de producir una respuesta.
Definición: una secuencia de pasos intermedios expresados en texto
La cadena de pensamiento (chain of thought, CoT) es una secuencia de pasos intermedios expresados en lenguaje que un modelo genera o recibe como ejemplo para abordar una tarea antes de producir una respuesta final. En el uso habitual, esos pasos presentan parte del trabajo necesario para llegar a una conclusión: por ejemplo, separar datos, establecer una relación entre ellos y efectuar una operación.
El término describe el texto observable y la técnica de prompting asociada; no garantiza que ese texto sea una transcripción completa o fiel de los cálculos internos del modelo. Una cadena puede ser útil como andamiaje para resolver una tarea o como explicación legible para una persona. Pero que parezca ordenada no demuestra que cada paso sea correcto, que haya causado la respuesta final ni que revele lo que ocurrió dentro del modelo.
Se usa sobre todo cuando una tarea requiere varios pasos y se quiere orientar al modelo para que los exponga, o cuando se proporcionan ejemplos de cómo presentar una solución. La distinción es importante para equipos que evalúan modelos: una respuesta paso a paso puede ser un objeto de inspección, pero no sustituye la comprobación de la respuesta ni una prueba de fidelidad.
Cómo se obtiene: ejemplos, instrucciones y supervisión
Hay varias maneras relacionadas, pero no equivalentes, de obtener pasos intermedios. En prompting few-shot se incluyen en el prompt uno o más ejemplos de entrada, razonamiento expresado en texto y respuesta. El trabajo de Wei y colaboradores estudia esta configuración y denomina cadena de pensamiento a los pasos intermedios de razonamiento incluidos en los ejemplos.
En una configuración zero-shot se puede pedir directamente que el modelo aborde el problema paso a paso, sin mostrarle ejemplos de cadenas completas. Esa instrucción no es lo mismo que el prompting few-shot: cambia la información proporcionada en el prompt, aunque ambos enfoques buscan que el modelo genere pasos intermedios.
También se puede entrenar con datos que contienen pasos, en vez de limitarse a solicitarlos al momento de inferir. La supervisión del proceso proporciona señales sobre pasos intermedios, mientras que la supervisión del resultado se centra en la respuesta final. Son decisiones de entrenamiento y evaluación distintas de añadir ejemplos o instrucciones a un prompt. No deben describirse como si una sola frase del prompt equivaliera a entrenar el modelo con trazas de razonamiento.
En todos estos casos, el resultado puede ser una secuencia escrita que parece describir el trabajo efectuado. El método usado para producirla no elimina la necesidad de comprobarla: los ejemplos pueden orientar el formato, y la supervisión puede evaluar pasos, pero ninguno de esos hechos convierte automáticamente el texto generado en una lectura directa del estado interno del modelo.
Tres vías que conviene distinguir
- 01Ejemplos en el prompt: mostrar uno o más problemas resueltos con pasos y pedir que el modelo siga un formato semejante.
- 02Instrucción en el prompt: solicitar pasos intermedios sin proporcionar necesariamente ejemplos resueltos.
- 03Supervisión durante el entrenamiento: usar datos o señales que evalúan pasos intermedios, en lugar de limitar la señal al resultado final.
Tres ejemplos aplicados y qué permiten comprobar
Los ejemplos siguientes son ilustrativos. Muestran cómo puede usarse una cadena como registro legible, y separan ese uso de la evidencia necesaria para afirmar que el resultado es correcto o que la explicación refleja fielmente el proceso interno.
En cada ámbito, la utilidad depende de la tarea: en aritmética puede revisarse una operación; al combinar documentos, puede rastrearse qué fragmentos respaldan cada afirmación; y en depuración, puede comprobarse el comportamiento del programa. Ninguna de esas comprobaciones demuestra, por sí sola, que la cadena sea una transcripción fiel del cálculo interno del modelo.
Para qué sirve y qué no se debe inferir
Una cadena puede servir como andamiaje: divide una tarea en partes que pueden tratarse una por una. También puede hacer explícitos supuestos que, de otro modo, quedarían ocultos en una respuesta breve. Para una persona que revisa el resultado, esa estructura facilita localizar una operación, una premisa o una afirmación que merece comprobación.
Sin embargo, la cadena no debe confundirse con una demostración. Puede contener un paso incorrecto y aun así terminar en la respuesta correcta por casualidad, o presentar una conclusión plausible apoyada en una premisa equivocada. También puede omitir información relevante. La apariencia de detalle no equivale a la calidad de la evidencia.
La investigación sobre explicaciones no fieles en prompting de cadena de pensamiento muestra que, en tareas estudiadas, las cadenas pueden no reflejar factores que influyeron en la respuesta y pueden racionalizarla después. Esto respalda una cautela concreta: no conviene tratar automáticamente el texto como una ventana transparente al proceso que produjo la respuesta. Los resultados experimentales tampoco permiten afirmar que toda cadena sea infiel; delimitan un riesgo que debe evaluarse en vez de descartarse.
Para investigar fidelidad, un enfoque posible es intervenir sobre la cadena o perturbarla y observar si cambia la respuesta, como explora el trabajo de Lanham y colaboradores. Esas pruebas aportan evidencia sobre la relación entre el texto y la respuesta en las condiciones examinadas. No permiten observar directamente todos los cálculos internos del modelo, y sus conclusiones dependen de las tareas y métodos empleados.
Qué afirma la cadena y qué verificación hace falta
| Observación | Qué puede apoyar | Qué no demuestra por sí sola |
|---|---|---|
| La respuesta incluye pasos ordenados. | El modelo produjo un texto intermedio legible. | Que cada paso sea correcto o que la cadena sea una transcripción interna. |
| La cuenta coincide con una operación independiente. | Que el resultado aritmético de ese caso es correcto. | Que la cadena causó la respuesta o representa fielmente el proceso interno. |
| Las afirmaciones coinciden con los fragmentos de documentos. | Que la respuesta está respaldada por esos fragmentos, si se conserva su alcance. | Que el modelo interpretó internamente los documentos del modo descrito. |
| El código corregido supera pruebas definidas. | Que el comportamiento comprobado cumple esas pruebas. | Que la explicación de la depuración es completa o fiel. |
Confusiones frecuentes y conceptos próximos
Cadena de pensamiento no es sinónimo de razonamiento en modelos. El razonamiento es el concepto más general para hablar de tareas que requieren relacionar información, inferir o resolver problemas; CoT se refiere, en este contexto, a pasos intermedios expresados en texto y a técnicas que los solicitan o usan. Una cadena es una salida observable, no una medida completa de una capacidad general.
Tampoco es lo mismo que prompting en general. El prompting comprende instrucciones y ejemplos que se proporcionan al modelo. CoT es una estrategia de prompting cuando se busca obtener pasos intermedios. Además, incluir una secuencia de pasos en un único prompt no equivale a encadenar varias llamadas separadas a un modelo: en un flujo encadenado, la salida de una etapa puede convertirse en la entrada de otra.
En tareas con recuperación aumentada por generación (RAG), la cadena puede articular cómo se relacionan una pregunta y fragmentos recuperados. La presencia de esos pasos no valida por sí sola la recuperación ni la respuesta: se debe comprobar si las fuentes aportan realmente la evidencia y si la respuesta conserva su alcance.
Finalmente, una secuencia de texto no es lo mismo que una traza ejecutable. En PAL y en Program of Thoughts se estudian enfoques que expresan parte del trabajo como programa para que un intérprete ejecute la computación. Un programa puede permitir verificar una operación o un resultado concreto mediante su ejecución, pero esa verificación no demuestra fidelidad del razonamiento textual. Los verificadores de pasos, por su parte, evalúan pasos o reciben supervisión sobre ellos: tampoco deben confundirse sin más con la ejecución de código.
Distinciones rápidas
| Concepto | Enfoque | Pregunta práctica |
|---|---|---|
| Razonamiento en modelos | Concepto general de capacidad o tarea de inferencia. | ¿Qué tarea de razonamiento se está evaluando? |
| Cadena de pensamiento | Pasos intermedios expresados en texto. | ¿Qué pasos muestra el modelo y cuáles se han comprobado? |
| Prompting | Instrucciones y ejemplos dados al modelo. | ¿Qué información recibió el modelo antes de responder? |
| RAG | Generación apoyada en información recuperada. | ¿Respaldan los fragmentos recuperados cada afirmación? |
| Programa ejecutable | Instrucciones que un intérprete puede ejecutar. | ¿Qué comportamiento o cálculo verifican las pruebas? |
Cómo evaluarla con rigor
La evaluación debe separar al menos tres preguntas: ¿es correcto el resultado?, ¿son válidos los pasos que se muestran?, y ¿hay evidencia de que esos pasos reflejan fielmente el proceso que produjo la respuesta? Una misma prueba rara vez responde por sí sola a las tres.
Para el resultado, conviene usar un método independiente adecuado al dominio: recalcular una operación, contrastar afirmaciones con documentos o ejecutar pruebas sobre el código. Para los pasos, se pueden revisar premisas, inferencias, cálculos y citas de evidencia de forma explícita. En tareas con varias soluciones válidas, los criterios deben permitir alternativas correctas sin premiar explicaciones meramente plausibles.
Para estudiar fidelidad, las intervenciones o perturbaciones pueden aportar información sobre si modificar una cadena afecta a la respuesta y bajo qué condiciones. Deben diseñarse con controles y una pregunta definida; observar un cambio no basta para concluir que se ha recuperado el proceso interno completo. La interpretación ha de limitarse a lo que la prueba mide.
Una práctica operativa es registrar por separado la respuesta final, la cadena visible, las comprobaciones externas realizadas y las incertidumbres. Si una herramienta verifica una cuenta, hay que decir que verificó esa cuenta; no convertirlo en una afirmación de que todo el razonamiento fue fiel. Si los documentos no respaldan una afirmación, hay que marcar la carencia aunque el texto paso a paso parezca convincente.
Lista de comprobación para una evaluación
- 01Definir qué se evalúa: resultado, validez de pasos, fidelidad de la explicación o una combinación explícita.
- 02Elegir un verificador independiente adecuado: cálculo, cotejo documental, pruebas de código u otro criterio específico de la tarea.
- 03Comprobar cada afirmación o paso relevante y registrar errores, omisiones y ambigüedades.
- 04Si se estudia fidelidad, usar intervenciones o perturbaciones con controles y limitar la conclusión al diseño y las tareas evaluadas.
- 05Informar por separado del resultado, las comprobaciones realizadas y lo que sigue sin poder concluirse.
Lecturas técnicas y límites de la evidencia
El trabajo de Wei y colaboradores es una referencia primaria para la definición y el prompting few-shot con ejemplos de cadenas. El trabajo sobre razonadores zero-shot estudia una instrucción para solicitar pasos sin que eso equivalga a proporcionar ejemplos resueltos. Ambos ayudan a distinguir configuraciones de prompting, no a probar por sí mismos la fidelidad de cada cadena generada.
PAL y Program of Thoughts exploran maneras de separar la producción de pasos o programas de la ejecución de cálculos. Son pertinentes para entender qué puede comprobar un intérprete, especialmente en tareas computacionales; comprobar un resultado ejecutado no es una prueba de transparencia interna. El trabajo sobre verificación paso a paso estudia la supervisión de procesos frente a la supervisión de resultados, una distinción relevante para evaluación y entrenamiento.
Los estudios sobre explicaciones no fieles y sobre medición de fidelidad examinan riesgos y métodos experimentales concretos. Sus resultados sirven para fundamentar cautela y diseñar evaluaciones, no para atribuir una propiedad universal a todas las tareas, modelos o cadenas. La evidencia aportada no permite observar directamente el proceso interno completo de un modelo, por lo que las afirmaciones sobre fidelidad deben formularse con alcance limitado.
Criterios prácticos
Al leer o solicitar una cadena de pensamiento, trátala como una explicación textual que puede ayudar a inspeccionar una respuesta, no como prueba automática de su corrección o de su origen interno. Pide pasos cuando aporten valor a la tarea, verifica por separado lo verificable y conserva las fuentes o pruebas que respaldan las conclusiones.
Si lo que importa es la corrección, usa un verificador independiente adecuado. Si lo que importa es la fidelidad, diseña una evaluación que intervenga sobre la cadena y declara qué mide y qué no. Si solo se ha observado una explicación coherente, descríbela como coherente o útil para la inspección: no la llames fiel sin evidencia específica.
Esta ficha se distingue de la de razonamiento en modelos, que aborda el concepto general, mientras que aquí el foco está en el texto intermedio y sus límites. Para ampliar el tema, consulta también las entradas de prompting, evaluación, RAG, cadena de pensamiento y razonamiento.