Generador de Prompts de Razonamiento

Elegir la estructura adecuada para cada problema

Las cinco técnicas no son intercambiables. Cada una arregla un fallo distinto, y la equivocada añade ruido sin precisión.

• Paso a paso encaja con cadenas ordenadas: conversiones de unidades, cálculos con fechas, reglas de elegibilidad, depurar una traza. El modelo sostiene el estado intermedio, y escribirlo evita que se desvíe.
• Descomponer encaja con problemas anchos más que profundos. "Audita este flujo de onboarding" son seis preguntas más pequeñas. Separarlas evita que el modelo responda la más fácil y dé el trabajo por hecho.
• Autoverificación encaja donde una respuesta equivocada dicha con aplomo sale cara: cláusulas de contrato, SQL que toca producción, tablas de precios.
• Comparar opciones encaja con preguntas sin una única respuesta correcta, donde lo que entregas es una contrapartida defendible.
• Planificar y luego ejecutar encaja con generación larga donde la estructura importa más que cualquier frase: un runbook de migración, el esquema de un curso, un informe.

Heurística rápida: si tú esbozarías el problema en papel antes de nada, la estructura ayuda. Si simplemente recordarías la respuesta, no. La guía de fundamentos muestra dónde se sitúan estas técnicas junto al prompting por rol y por formato.

Cuándo el razonamiento ayuda y cuándo quema tokens

Razonar rinde en el trabajo de varios pasos porque los errores se acumulan. En un cálculo de cinco pasos, un 10 % de error por paso te deja por debajo de un cara o cruz global. Obligar a que cada paso salga a la luz hace visible el fallo en vez de dejarlo cocido dentro de la cifra final.

Es inútil en consultas de dato. "¿En qué año se lanzó el euro?" no gana precisión con un "piensa paso a paso" pegado detrás. Pagas tokens extra, esperas más y a veces obtienes algo peor, porque el modelo se convence a sí mismo de un camino elaborado y equivocado.

Señales de que la estructura sobra:

• La respuesta es un solo dato.
• La salida no llega a un párrafo.
• Aceptarías la primera respuesta sin comprobarla.
• Vas a ejecutarlo cientos de veces y el coste importa.

Pasa ambas versiones por el contador de tokens para tener el número real. A escala la diferencia es dinero; en un caso puntual es ruido.

Los modelos de razonamiento cambiaron el trabajo

Los modelos que piensan internamente antes de responder cambiaron el aspecto de un buen prompt. Decirle a un modelo de pensamiento extendido que "piense paso a paso" es redundante: ya lo hace en un cuaderno oculto, y la instrucción solo produce un resumen ensayado de un razonamiento que ya terminó.

Lo que sí ayuda es pedir estructura que puedas verificar. No exijas el pensamiento: exige sus artefactos. Supuestos asumidos, la regla aplicada, los datos de entrada usados, una autoverificación corta contra tus restricciones. El artículo sobre cadena de pensamiento cubre la separación entre el CoT clásico y el prompting de modelos de razonamiento; la guía avanzada añade patrones de autoconsistencia.

Descompón y luego obliga a una síntesis

El fallo habitual de la descomposición es una pila de mini-respuestas inconexas. El modelo parte el problema en seis, contesta cada parte con solvencia y te entrega fragmentos sin veredicto, dejándote la integración, que era la parte difícil.

Haz de la síntesis un paso final explícito con sus propias reglas: referenciar cada subrespuesta, resolver los conflictos en voz alta, producir una sola recomendación. Di qué hacer cuando se contradigan, o el modelo las promediará en una papilla.

Pasa cualquiera de las dos estructuras por el optimizador de prompts para apretarla, o por el analizador para cazar antes las instrucciones vagas.

Un ejemplo donde los pasos cambian la respuesta

Prueba esto: *"Una tienda aplica un margen del 40 % a un artículo y luego hace una rebaja del 30 %. El precio final es de 98 €. ¿Cuánto pagó la tienda?"*

Preguntado en seco, los modelos suelen responder 98 / 1,1 ≈ 89 €, tratando el +40 % y el -30 % como una ganancia neta del 10 %. Falso, y verosímil. Ahora fuerza la cadena:

Los pasos dejan a la vista la composición: coste × 1,40 × 0,70 = coste × 0,98 = 98 €, así que el coste es 100 €. La línea de verificación caza el desliz, porque sustituir 89 devuelve 87,22.

La distancia entre 89 y 100 es el argumento. Esa respuesta seca no fue un fallo de conocimiento: fue una multiplicación que se saltó, y la estructura hace visible el salto. Guarda en tu biblioteca de prompts las estructuras que sobrevivan a la verificación, parte de un generador específico de modelo cuando necesites una rápido y añade el constructor JSON para salida parseable.