Prompting de cadena de pensamiento explicado (con ejemplos)
Pide a un modelo que piense paso a paso y acertará los problemas de varios pasos mucho más a menudo. Así funciona la cadena de pensamiento y cómo usarla bien.
Pide a un modelo de lenguaje que multiplique dos números de tres cifras y suelte la respuesta de golpe, y a menudo tropezará. Pide al mismo modelo que trabaje la multiplicación una posición decimal a la vez, y la precisión se dispara. Esa diferencia es toda la idea del prompting de cadena de pensamiento: darle al modelo espacio para razonar antes de comprometerse con una respuesta final. Cuando un problema tiene piezas móviles que dependen unas de otras, el razonamiento no es decoración. Es lo que te lleva al resultado correcto.
Este artículo recorre las principales variantes de la técnica, muestra dónde se gana su sitio cada una y señala las situaciones en las que los pasos de razonamiento solo malgastan tokens. Si todavía estás construyendo tu base, la guía de fundamentos es un buen acompañamiento.
Por qué el razonamiento por pasos cambia la salida
Un modelo genera texto un token a la vez, y cada token que produce pasa a formar parte del contexto del siguiente. Cuando fuerzas una respuesta directa, comprimes un problema de varios pasos en un único salto. El modelo no tiene espacio de borrador, así que busca por coincidencia de patrones algo que parezca plausible y con frecuencia aterriza cerca de la respuesta en lugar de sobre ella.
Los pasos de razonamiento cambian la forma de esa generación. Cada conclusión intermedia que el modelo escribe se convierte en un hecho en el que puede apoyarse para el siguiente paso. Un problema difícil se transforma en una cadena de otros más fáciles, y el modelo solo tiene que ser localmente correcto en cada eslabón en vez de globalmente correcto de un tirón.
Esto ayuda más en tareas con estas características:
- Aritmética y problemas de enunciado donde un error en una operación arrastra al resto
- Acertijos de lógica con restricciones que interactúan
- Preguntas de varios saltos que exigen encadenar varios hechos
- Tareas de planificación donde el orden y las dependencias importan
Zero-shot: el disparador de una línea
La versión más ligera te cuesta una sola frase. Añades una instrucción que empuja al modelo a un modo de razonamiento antes de responder. La formulación exacta importa menos que la intención, así que trátala como una palanca que puedes reformular para tu dominio.
El modelo normalmente establecerá el precio por grupo, contará cuántos grupos hay en 21 bolígrafos, calculará el coste total y luego restará de 20. Compáralo con una pregunta pelada, donde podría agarrar los números 21 y 20 y producir algo confiadamente erróneo.
También puedes dirigir el razonamiento. En vez de un disparador genérico, dile al modelo *cómo* pensar: «Primero enumera las restricciones, luego elimina las opciones que las incumplen y luego elige lo que quede». El andamiaje específico de un dominio suele ganar a una instrucción para todo.
Few-shot: enseñar con un ejemplo resuelto
El zero-shot se apoya en los propios hábitos del modelo. El few-shot le muestra al modelo exactamente qué aspecto tiene un buen razonamiento incluyendo uno o más ejemplos resueltos, con sus pasos intermedios y todo. El modelo imita el patrón de las demostraciones, no solo sus respuestas.
Como el ejemplo resuelto detalla sus pasos, el modelo continúa con la misma voz: nombrará los días de lectura, contará cuántos caen en 21 días y multiplicará. La demostración hace doble función: muestra tanto el formato de la respuesta como el nivel de detalle del razonamiento que esperas. Si quieres una comparación más a fondo de los dos estilos y cuándo gana cada uno, mira few-shot vs zero-shot.
Mantén tus ejemplos cerca de la tarea real. Un modelo al que le muestras razonamiento geométrico no transferirá automáticamente esa disciplina a un problema de planificación de horarios, así que haz que el dominio de tus demostraciones coincida con el de tu consulta.
Descomposición: parte la tarea
A veces el movimiento más inteligente es dejar de tratar el problema como un solo prompt. La descomposición divide una petición compleja en subtareas con nombre, cada una de las cuales puedes resolver y verificar por separado. O le pides al modelo que enumere primero los subproblemas, o los conduces tú a través de llamadas separadas.
El resumen de una investigación, por ejemplo, se descompone con limpieza:
- Extraer las afirmaciones clave de la fuente
- Comprobar cada afirmación contra el texto de apoyo
- Agrupar las afirmaciones relacionadas en temas
- Escribir el resumen a partir de los temas verificados
Resolver cada etapa por separado te da puntos de inspección. Si el resumen está mal, puedes ver si falló la extracción o la agrupación, en vez de quedarte mirando un bloque opaco de salida. Este enfoque estructurado es un tema central en la ingeniería de prompts avanzada, donde el encadenamiento y la descomposición a menudo pesan más que un prompt único ingenioso.
Autoconsistencia y la comprobación final
Una única cadena de razonamiento puede descarrilar y aun así sonar segura. Dos técnicas protegen contra eso.
La autoconsistencia muestrea varias cadenas independientes para la misma pregunta, cada una con algo de aleatoriedad, y luego toma la respuesta mayoritaria. Si ocho de diez caminos de razonamiento aterrizan en 42, te fías de 42 mucho más que de cualquier intento aislado. Cuesta más llamadas, así que resérvala para preguntas donde una respuesta errónea sale cara.
La autocomprobación pide al modelo que audite su propio trabajo antes de dar el resultado. Una instrucción de cierre hace mucho aquí:
Esa última instrucción convierte la propia salida del modelo en algo que revisa en vez de algo que solo produce. Atrapa un número sorprendente de descuidos, sobre todo errores aritméticos y de más-o-menos-uno en problemas de tiempo o de conteo. Un generador dedicado como la herramienta de prompts de cadena de pensamiento puede crearte este andamiaje de razonamiento más verificación, y el optimizador de prompts ayuda a ajustar la redacción una vez que tienes un borrador.
Cuándo saltárselo
Los pasos de razonamiento tienen un coste. Gastan tokens, añaden latencia y, en la tarea equivocada, pueden perjudicar de verdad al inventar una justificación para un dato que el modelo ya sabía sin problemas. Sáltate la cadena de pensamiento explícita cuando:
- La tarea sea una consulta directa o un único dato («¿Cuál es la capital de Perú?»)
- Necesites una clasificación corta sin ambigüedad
- La salida sea creativa y no tenga una respuesta correcta que verificar
- La latencia importe más que los últimos puntos de precisión
Forzar «pensemos paso a paso» en una recuperación simple solo infla la respuesta y, de vez en cuando, desvía al modelo de una respuesta instantánea correcta.
Los modelos de razonamiento cambian el equilibrio
Los modelos de razonamiento más nuevos manejan gran parte de esto internamente. Generan una pasada de deliberación oculta antes de responder, así que pegarles un genérico «piensa paso a paso» aporta poco. El razonamiento ya está ocurriendo donde no lo ves.
Lo que sí compensa es la estructura y la verificación. Decirle al modelo *qué* dimensiones considerar, en qué orden, y pedirle que haga una autocomprobación final te da palanca incluso cuando el razonamiento interno es fuerte:
- Especifica los criterios que debe satisfacer la respuesta
- Pide la respuesta en un formato comprobable (un número, una tabla, una decisión etiquetada)
- Solicita una breve pasada de verificación frente a los criterios que indicaste
Ya no estás enseñando al modelo a razonar. Estás apuntando su razonamiento a tu problema y dándote a ti mismo una forma de confirmar el resultado. Ese enfoque mantiene la cadena de pensamiento útil mucho después de que el truco crudo de «piensa paso a paso» deje de mover la aguja.
