Encadenamiento de Prompts en la Práctica: Por Qué el Esquema Entre Pasos Importa Más que los Pasos · sylowdev
0:000:00
Encadenamiento de Prompts en la Práctica: Por Qué el Esquema Entre Pasos Importa Más que los Pasos
El encadenamiento de prompts divide un prompt de LLM sobrecargado en pasos pequeños. Aquí está por qué el esquema entre pasos, y no la cantidad de pasos, es lo que hace que una cadena sea confiable.
RRuben Tanahara
Published on November 5, 2026 · 6 min read · 11 min listen
agentic-design-patterns
prompt-chaining
langchain
llm
python
0
Si tu prompt único de "hacer todo" funciona la mayoría de las veces, los fallos son los que no puedes predecir. El encadenamiento de prompts divide esa solicitud sobrecargada en una secuencia de pequeñas llamadas al LLM, cada una alimentando a la siguiente. Construí una cadena de tres pasos para el primer capítulo de mi repositorio de estudio Agentic Design Patterns, y lo que más me llamó la atención fue cuánto de la confiabilidad provenía del traspaso tipado entre pasos.
TL;DR
Un prompt que extrae, transforma y escribe a la vez tiende a omitir instrucciones, perder contexto e inventar valores.
El encadenamiento de prompts le da a cada llamada del LLM un trabajo acotado; la salida del paso N se convierte en la entrada del paso N+1.
La mayor parte de la confiabilidad proviene de la salida estructurada (un esquema de Pydantic) en los límites, de modo que los datos incorrectos fallan temprano en lugar de envenenar los pasos posteriores.
El código simple entre llamadas al LLM (validación, conversión, matemáticas, reintentos) forma parte del patrón, no es un truco.
La idea central en una frase: encadena prompts pequeños y pon un contrato en cada traspaso.
Concepto Central
El encadenamiento de prompts, también llamado patrón Pipeline, divide una tarea compleja en una secuencia de prompts enfocados. Cada paso tiene su propio prompt, a veces su propio rol, y pasa su resultado hacia adelante. El código ordinario puede situarse entre pasos para verificar, reformar o ramificar según lo que vuelva.
Imagina una línea de ensamblaje. Un trabajador que corta, suelda, pinta e inspecciona cada auto se saltará algo en un mal día. Dale a cada estación un trabajo y pon un inspector entre la soldadura y la pintura, y el defecto se detecta antes de que se aplique la pintura.
Aquí hay una cadena real, con el inspector en su lugar.
Bloques de Construcción Clave
El ejemplo es chain.py, un pipeline LCEL de LangChain sobre Gemini. Convierte una oración de texto de marketing de una laptop en un correo de anuncio de producto.
Podrías pedirle a un solo prompt que "extraiga las especificaciones y escriba un correo". La cadena lo hace en tres pasos de LLM con código en medio.
1. Extraer: un prompt acotado obtiene una respuesta acotada
El primer paso solo extrae. No tiene idea de que viene un correo, así que no puede intercambiar precisión de extracción por estilo de correo. Un prompt con un solo trabajo le pide menos al modelo a la vez.
Comments
Su salida sigue siendo texto libre. Eso está bien para un solo salto, y el siguiente paso se encarga de ello.
2. Estructurar: el esquema es el contrato
El segundo paso mapea las especificaciones extraídas a un modelo Pydantic usando with_structured_output. El texto libre entre pasos es la principal fuente de fallos en la cadena, y un esquema significa que la cadena obtiene un campo cpu o se detiene justo aquí.
Este paso es el inspector. Si el modelo devuelve algo malformado, ves el fallo junto a su causa, en lugar de tres pasos después como un correo extraño.
3. Código pegamento: Python simple entre llamadas al LLM
Entre la estructuración y la redacción se encuentra una lambda de una línea, lambda specs: specs.model_dump(). Convierte el objeto Pydantic en un diccionario cuyas claves coinciden con las variables del siguiente prompt.
No todos los pasos necesitan un modelo. El código maneja la conversión, validación, aritmética y búsquedas exactas perfectamente, y los LLM los manejan mal. En una cadena más grande, aquí es donde verificarías los campos requeridos y volverías a pedir solo los que faltan, o llamarías a una calculadora en lugar de pedirle al modelo que sume.
4. Redactar: el escritor recibe campos exactos
El último paso escribe un anuncio de tres oraciones a partir de {cpu}, {memory} y {storage}. Nunca ve la oración de marketing en bruto, solo campos validados, así que no hay nada que pueda malinterpretar.
5. Conectando y observando la cadena
El operador | de LCEL une los pasos. El literal de diccionario {"specifications": extract_specs} significa "ejecuta este paso y pon su resultado bajo esta clave", que es cómo una salida se convierte en la variable del siguiente prompt. Cada toma steps.step("name") imprime el valor intermedio en un panel y lo pasa sin cambios.
Cada toma imprime el valor de su paso en un panel con borde. Cuando el correo sale mal, lee los paneles de primero a último y encuentra el primero incorrecto. Arregla ese paso; los demás no necesitan cambiar.
Implicaciones Prácticas
El encadenamiento de prompts encaja en tareas con etapas distintas, tareas que necesitan verificaciones deterministas o llamadas a herramientas entre etapas, y casos donde quieres ajustar cada etapa por separado. Lo usaría para extracción de documentos (factura a campos a asiento contable), para flujos de reporte-a-resumen-a-correo, y para chat con estado, donde cada turno del usuario es una pequeña cadena: extraer intención, actualizar estado, responder desde el estado.
Tiene costos. Cada paso agrega una llamada al modelo, así que la latencia y el gasto aumentan, y si un solo prompt ya hace el trabajo de forma confiable deberías quedarte con el prompt único. Los errores también se propagan: una extracción incorrecta envenena todo lo que viene después, por lo que agregaría un límite validado antes de agregar otro paso.
Dos formas no pertenecen en absoluto a una cadena. Las subtareas independientes deberían ejecutarse en paralelo. Si el siguiente paso depende de qué tipo de entrada llegó, quieres enrutamiento.
Extensiones Avanzadas
La cadena de tres pasos es el escalón más bajo. De lo más simple a lo más complejo:
Cadena LCEL lineal: pasos unidos con |, como chain.py.
Cadena validada: esquemas en cada límite, más reintentos de prompt dirigidos cuando falta un campo.
Cadena con herramientas: código o llamadas a herramientas entre pasos para matemáticas, búsquedas y datos de API.
Forma mixta: pasos paralelos para recopilación independiente, luego una cadena secuencial para síntesis y revisión.
Grafo: una vez que necesitas bucles o estado mutable compartido, LCEL deja de encajar y pasas a LangGraph.
Modelo Mental / Conclusiones
Pienso en una cadena de prompts como un pipe de Unix donde cada | puede llevar una verificación de tipo. Las llamadas al LLM son los comandos, y los esquemas y el código pegamento son lo que te permite confiar en el pipe.
Las reglas que mantendría:
Un trabajo, e idealmente un rol, por paso.
Salida estructurada en cada límite que alimenta a otro prompt.
Matemáticas y búsquedas exactas en código, no en prompts.
Elige qué contexto ve cada paso; eso importa más que la redacción del prompt.
Registra cada valor intermedio. Lo querrás la primera vez que la salida esté mal.
Glosario
Encadenamiento de prompts (Prompt chaining): dividir una tarea en llamadas secuenciales al LLM donde cada salida alimenta la siguiente entrada.
LCEL: LangChain Expression Language; compone runnables con el operador |.
Runnable: cualquier componente de LangChain con invoke, como un prompt, modelo, parser o lambda.
Salida estructurada: salida del modelo restringida a un esquema (aquí un modelo Pydantic) en lugar de texto libre.
Propagación de errores: un error temprano arrastrado y amplificado por cada paso posterior.
Ingeniería de contexto: decidir qué puede ver cada paso: prompt de sistema, documentos, resultados de herramientas, estado.
Conclusión
El encadenamiento de prompts es el patrón base sobre el que se construyen casi todos los demás patrones agénticos. Mantén cada prompt acotado, pon un esquema en cada traspaso, y deja que el código simple haga lo que los modelos hacen mal.
Clona el repositorio Agentic Design Patterns, ejecuta make run CH=01, y observa cada panel para ver cómo la cadena va entregando datos paso a paso.
Publicaciones relacionadas en esta serie:
Capítulo 2: Enrutamiento, para cuando el siguiente paso depende de la entrada.
Capítulo 3: Paralelización, para cuando las subtareas no dependen entre sí.
text = "The new laptop has a 3.5 GHz octa-core processor, 16GB of RAM, and a 1TB NVMe SSD."
extract_specs = ( ChatPromptTemplate.from_template("Extract the technical specifications from this text:\n\n{}") | llm | StrOutputParser())
class LaptopSpecs(BaseModel): cpu: str memory: str storage: strstructure_specs = ChatPromptTemplate.from_template( "Map these specifications to cpu, memory and storage:\n\n{specifications}") | llm.with_structured_output(LaptopSpecs)
draft_email = ( ChatPromptTemplate.from_template( "Write a three-sentence product announcement email for a laptop with " "CPU: {cpu}, memory: {memory}, storage: {storage}." ) | llm | StrOutputParser())
