Los modelos de lenguaje de gran tamaño tropiezan cuando se les pide que hagan demasiado a la vez. Introduce un PDF de cincuenta páginas en una ventana de chat y pide un análisis estructurado, una evaluación de riesgos y un resumen ejecutivo de un solo golpe. El resultado suele ser superficial, confuso o totalmente erróneo. Un mejor enfoque es mecánico. Divide el trabajo en etapas discretas. Introduce la salida de la primera etapa directamente en la segunda, y así sucesivamente. Anthropic llama a este patrón prompt chaining. Google se refiere a él como un sequential pipeline. Ambos nombres describen lo mismo: una línea de montaje donde cada estación se encarga de una transformación específica.
Cómo se ve esto en la práctica
En lugar de un único prompt gigante, construyes una serie de pasos pequeños y enfocados. Imagina un equipo de cumplimiento que procesa evaluaciones de seguridad de proveedores. El primer paso extrae el texto sin procesar de un PDF escaneado. El segundo paso identifica cada mención de estándares de cifrado y controles de acceso. El tercer paso coteja esos hallazgos con una lista de verificación interna. El cuarto paso redacta un breve memorando para el responsable de seguridad. Un agente convierte el PDF en texto. El siguiente agente extrae datos específicos de ese texto. El agente final escribe un resumen basado en esos datos. Ninguno de estos pasos es glamuroso y ninguno realiza multitareas. Cada parte hace un solo trabajo bien.
Por eso la metáfora de la línea de montaje se mantiene. En una fábrica, un trabajador no ensambla el coche entero. La especialización mantiene la calidad alta y los modos de fallo limitados. La misma lógica se aplica a los modelos de lenguaje. Un prompt que solo pide la extracción de JSON tiene menos probabilidades de alucinar que uno que también pide opinión y formato en la misma solicitud.
Construye puertas, no conjeturas
El punto más débil de cualquier cadena es el traspaso. Un modelo podría devolver una negativa cortés, un fragmento de markdown en lugar de JSON o una respuesta truncada. Si esa basura fluye hacia el segundo paso, toda la cadena colapsa. La solución es una puerta.
Una puerta no es una llamada al modelo. Es código simple. Escribes un script corto que se ejecuta entre los pasos. Puede comprobar la longitud de la salida para asegurarse de que no esté vacía. Puede ejecutar una validación de esquema JSON para confirmar que las claves coinciden con lo que el tercer paso espera. Una comprobación de regex puede verificar que un campo de correo electrónico o de fecha esté realmente presente antes de que se construya el siguiente prompt. Esto detiene los errores antes de que malgastes dinero en salidas incorrectas. Una puerta cuesta microsegundos de cómputo. Una llamada fallida a un LLM en la etapa posterior cuesta tokens, latencia y tu cordura.
Piénsalo como un punto de control de calidad en la planta de la fábrica. No necesitas IA para contar piezas. Necesitas una regla.
Cuándo encadenar y cuándo detenerse
El prompt chaining no es adecuado para todos los problemas. Úsalo cuando el trabajo tenga pasos fijos y repetibles. Los informes financieros mensuales, la revisión estandarizada de contratos y los pipelines de análisis de logs son buenos ejemplos. Si puedes escribir el procedimiento como una lista de verificación, probablemente puedas encadenarlo. También deberías recurrir al encadenamiento cuando necesites una alta precisión para trabajos complejos. Dividir un problema en etapas obliga al modelo a manejar una capa lógica a la vez. Por último, las cadenas son más fáciles de depurar que los prompts monolíticos. Cuando el resumen sea incorrecto, inspeccionas la extracción. Cuando la extracción sea incorrecta, inspeccionas el texto de origen. Tienes artefactos intermedios para examinar.
Evita el prompt chaining cuando no conozcas los pasos de antemano. La investigación exploratoria, la lluvia de ideas abierta o las tareas de investigación no siguen una línea recta. Omítelo también cuando la velocidad sea tu única prioridad. Las cadenas son seriales; el segundo paso no puede comenzar hasta que el primero termine. Si tus pasos no dependen entre sí, ejecútalos en paralelo en su lugar. No hay razón para encadenar tres traducciones independientes del mismo documento.
La trampa de la rigidez
La contrapartida de toda esta estructura es la rigidez. Una cadena fija no puede adaptarse a situaciones nuevas. Si un proveedor envía un formulario de seis campos y tu puerta de validación de esquema espera cinco, la línea se detiene. Si un usuario sube un documento de Word en lugar de un PDF, el primer paso falla y el resto de la cadena no tiene nada que procesar.
Peor aún, los errores se propagan. Un error que ocurre al principio fluye a través de toda la cadena. Si el extractor de PDF omite un símbolo negativo de una cifra financiera, cada paso posterior tratará ese número incorrecto como