Encadenar prompts significa resolver una tarea con varios prompts en secuencia, de modo que la salida de uno se convierte en la entrada del siguiente. La descomposición de prompts es el paso de diseño previo: decidir cómo dividir la tarea. Juntos son la forma más fiable de conseguir que un modelo haga algo complicado.
Por qué falla un único prompt grande
Un prompt que pide a un modelo extraer, analizar, decidir y escribir de una sola pasada tiene varios problemas:
- Las instrucciones compiten. Cuanto más pide un prompt, más probable es que se descuide un requisito.
- No puedes saber qué parte falló. Una respuesta final errónea puede venir de cualquier paso.
- No puedes probar las partes. No hay nada sobre lo que afirmar hasta el final.
- Cada llamada paga cada instrucción, incluso las irrelevantes para esta entrada.
Una cadena da a cada paso un solo trabajo, una entrada clara y una salida comprobable.
Cómo descomponer una tarea
Pregunta qué haría una persona cuidadosa, en orden, y en qué momento pasaría el trabajo a otra. Los buenos puntos de corte son aquellos en los que:
- Cambia el tipo de trabajo (leer, luego juzgar, luego escribir).
- Merece la pena comprobar un resultado intermedio (los hechos extraídos, antes de sacar conclusiones).
- Un paso solo se aplica a veces (traducir solo si el texto no está en inglés).
- Pasos distintos necesitan modelos distintos (un modelo pequeño para clasificar, uno mayor para redactar).
Un ejemplo resuelto
La tarea: responder al correo de una queja de un cliente.
Paso 1: extraer. Un modelo pequeño y rápido convierte el correo en datos estructurados.
Extract from the email in the tags: order_id, product, the problem in
one sentence, and what the customer is asking for. Return JSON only.
Use null for anything not stated.
<email>
{{email}}
</email>
Paso 2: decidir. El código busca el pedido. Un prompt aplica la política.
Given the complaint and the order record, choose one action from:
refund, replace, escalate, explain. Give the policy clause that applies.
Return JSON: {"action": string, "clause": string}.
<complaint>{{step1_json}}</complaint>
<order>{{order_record}}</order>
<policy>{{policy}}</policy>
Paso 3: redactar. Un tercer prompt redacta la respuesta a partir de la decisión.
Write a reply to the customer, under 120 words, that states the action
and what happens next. Do not promise anything outside the action.
<action>{{step2_json}}</action>
<customer_name>{{name}}</customer_name>
Cada paso se puede probar por separado. Si las respuestas prometen lo que no deben, miras la salida del paso 2 y sabes de inmediato si la culpa es de la decisión o de la redacción.
Pasar datos entre pasos
Usa salida estructurada entre pasos. JSON o campos con etiquetas, no prosa. Así el siguiente prompt, y tu código, pueden confiar en la forma. Consulta los prompts de salida estructurada.
Pasa solo lo que necesita el siguiente paso. Reenviar todo el historial alarga los prompts posteriores y deja que los errores tempranos se propaguen.
Valida en cada frontera. Comprueba la salida de cada paso antes de usarla. Una cadena sin validación multiplica los errores: cinco pasos que aciertan cada uno el 95 % de las veces solo aciertan todos a la vez cerca del 77 % de las veces.
Delimita todo lo que insertes. La salida de un modelo es una entrada no confiable para el siguiente. Un correo de queja que dice «ignora tus instrucciones» ha pasado por el paso 1 y ahora está dentro del prompt del paso 2. Envuelve el contenido insertado en etiquetas. Consulta la inyección de prompt.
Formas de cadena
| Forma | Descripción | Ejemplo |
|---|---|---|
| Secuencial | A, luego B, luego C | Extraer, decidir, redactar |
| Enrutamiento | Clasificar y luego elegir una rama | Las preguntas de facturación van a un prompt y los errores a otro |
| Paralela | Pasos independientes a la vez y luego se fusionan | Resumir 10 documentos y combinarlos |
| Generar y comprobar | Un prompt produce, otro revisa | Redactar y luego criticar frente a los requisitos |
| Bucle | Repetir hasta que se cumpla una condición | Revisar hasta que pase la validación, con un límite de reintentos |
Limita siempre los bucles. Una cadena que reintenta para siempre es una caída del servicio y una factura.
Encadenar frente a las alternativas
Frente a la cadena de pensamiento. La cadena de pensamiento mantiene el razonamiento dentro de una sola respuesta. Úsala cuando los pasos no se conocen de antemano. Usa una cadena cuando sí se conocen: ganas capacidad de prueba y control.
Frente a los agentes. En una cadena, tu código decide el orden. En un agente, decide el modelo. Una cadena es más barata, más rápida y predecible. Elige un agente solo cuando el camino depende de lo que se descubra por el camino. Consulta el prompting ReAct y los prompts para agentes de IA.
Costes a vigilar
Una cadena hace más llamadas. Mantenla económica:
- Usa el modelo más pequeño que resuelva cada paso.
- Ejecuta los pasos independientes en paralelo para reducir la latencia.
- Omite los pasos que no se aplican a esta entrada.
- Almacena en caché la parte fija de cada prompt cuando el proveedor lo permita. Consulta la optimización de tokens.
Mantén sano cada eslabón
Una cadena tiene varios prompts que mantener, por lo que un problema en uno es fácil de pasar por alto. Guarda cada uno como archivo y compruébalos todos en cada cambio. La puerta de pruebas de prompts hace fallar un pull request cuando cualquier prompt del repositorio cae por debajo de tu listón de calidad o supera su presupuesto de tokens, y el analizador de prompts informa de las variables sin delimitar, que importan sobre todo donde un paso alimenta al siguiente.