Prompt Chaining (Pipeline Pattern) es una t\u00e9cnica que descompone tareas complejas en secuencias de prompts focalizados donde la salida de cada paso alimenta al siguiente. Resuelve instruction neglect, contextual drift y error propagation \u2014 los tres fallos sist\u00e9micos de los prompts monol\u00edticos en LLMs.<\/p>\n\n\n\n
Le pides a un modelo que extraiga datos, los transforme, los analice y redacte un resumen. Y obtienes una respuesta que hace bien la primera parte, mediocremente la segunda, y directamente ignora la tercera. No es un bug. Es lo que sucede cuando un generador autoregresivo intenta cumplir instrucciones concurrentes dentro de una misma ventana de contexto.<\/p>\n\n\n\n
Descompones la tarea en pasos secuenciales. Cada paso tiene un prompt focalizado, un rol definido, y su salida alimenta al siguiente. La idea no es complicada; lo dif\u00edcil es mantener el rigor entre pasos.<\/p>\n\n\n\n
Un prompt monol\u00edtico concentra m\u00faltiples instrucciones en una sola llamada. El modelo recibe: \u00abextrae especificaciones, convi\u00e9rtelas a JSON, identifica tendencias, redacta un resumen\u00bb. Y lo que ocurre despu\u00e9s es predecible.<\/p>\n\n\n\n
Estos no son fallos aleatorios. Son consecuencias de la arquitectura: los LLMs completan patrones, no ejecutan instrucciones m\u00faltiples con validaci\u00f3n intermedia.<\/p>\n\n\n\n
La descomposici\u00f3n sigue tres reglas que suenen obvias hasta que las rompes:<\/p>\n\n\n\n
El flujo resultante es lineal y determinista. Cada transici\u00f3n es expl\u00edcita, validable y trazable. Y aqu\u00ed es donde la teor\u00eda choca con la realidad: cada paso es una llamada al modelo, y cada llamada puede fallar de formas diferentes.<\/p>\n\n\n\n
El punto m\u00e1s fr\u00e1gil de cualquier cadena no es el razonamiento del modelo. Son las interfaces entre pasos.<\/p>\n\n\n\n
Un modelo puede devolver un diccionario Python en lugar de JSON. Puede a\u00f1adir comentarios narrativos alrededor de los datos. Puede cambiar La soluci\u00f3n es validaci\u00f3n tipada. En Python, Pydantic permite definir esquemas y parsear directamente contra ellos, garantizando structured output entre pasos:<\/p>\n\n\n\n Cuando la validaci\u00f3n falla, tienes tres opciones: reintentar con feedback del error, aplicar un fallback, o abortar. La elecci\u00f3n depende de si el fallo es recuperable y de cu\u00e1nto te importa ese dato en particular.<\/p>\n\n\n\n En producci\u00f3n, el mayor problema no suele ser el razonamiento del modelo sino la estabilidad de estas interfaces. He visto pipelines romperse durante d\u00edas porque un modelo empez\u00f3 a devolver Existen varias formas de orquestar una cadena. En la pr\u00e1ctica, la mayor\u00eda de pipelines \u00fatiles siguen siendo lineales. Los grafos complejos suelen introducir m\u00e1s problemas de observabilidad que beneficios reales.<\/p>\n\n\n\n LangChain implementa paralelizaci\u00f3n con Esta es la parte que los tutoriales no cubren.<\/p>\n\n\n\n Gestionar qu\u00e9 informaci\u00f3n llega a cada paso es probablemente la parte m\u00e1s subestimada del dise\u00f1o de pipelines. Un pipeline puede tener la arquitectura perfecta y romperse porque un paso recibe 12.000 tokens de contexto cuando solo necesitaba 200.<\/p>\n\n\n\n Registra entradas, salidas, tokens y tiempo por paso. Como metadatos externos, no dentro del contexto del modelo. Sin observabilidad, no sabes qu\u00e9 paso introdujo un error hasta que el pipeline termina \u2014 y para entonces, el contexto original ya no est\u00e1 disponible.<\/p>\n\n\n\n Muchos workflows etiquetados como \u00abAI agents\u00bb son realmente \u00e1rboles de decisi\u00f3n con branding.<\/p>\n\n\n\n La diferencia real es qui\u00e9n controla el flujo. En chaining, es c\u00f3digo determinista: defines cada paso y sus transiciones. En agentic workflows, es el modelo: genera un pensamiento, elige una herramienta, ejecuta, observa, repite. Patrones como ReAct son el backbone de esto.<\/p>\n\n\n\n Chaining gana en predictibilidad. Cada ejecuci\u00f3n sigue el mismo camino, los fallos son reproducibles, el presupuesto de tokens es fijo. Los agentes ganan en flexibilidad \u2014 pueden adaptarse a situaciones no previstas o cambiar de estrategia a mitad del flujo \u2014 pero esa flexibilidad tiene un precio: bucles de razonamiento prolongados, costos impredecibles, y fallos que requieren registrar el trace completo de decisiones para depurar.<\/p>\n\n\n\n La elecci\u00f3n depende de la tarea. Flujo conocido y estable \u2014 extracci\u00f3n de datos, generaci\u00f3n de reportes con estructura fija \u2014 chaining. Flujo din\u00e1mico \u2014 investigaci\u00f3n abierta, diagn\u00f3stico con m\u00faltiples causas \u2014 agentes. Un enfoque h\u00edbrido es v\u00e1lido: chaining para la parte predecible, agente para la que necesita adaptaci\u00f3n. He visto equipos invertir semanas en sistemas ag\u00e9nticos que resuelven el 10% de los casos, cuando un pipeline lineal cubr\u00eda el 90%.<\/p>\n\n\n\n Sobre RAG: RAG a\u00f1ade conocimiento externo al contexto. Chaining estructura el flujo de procesamiento. Se combinan frecuentemente: paso 1 recupera documentos con RAG, paso 2 extrae datos, paso 3 genera an\u00e1lisis. No compiten.<\/p>\n\n\n\n Cuando un solo prompt bien dise\u00f1ado resuelve la tarea. Si un modelo capaz puede extraer, analizar y redactar en una invocaci\u00f3n con resultados aceptables, a\u00f1adir una cadena introduce latencia y complejidad innecesaria.<\/p>\n\n\n\n La se\u00f1al de que necesitas chaining es clara: un prompt monol\u00edtico produce resultados inconsistentes, o la tarea requiere operaciones que el modelo no puede realizar con precisi\u00f3n en un solo paso.<\/p>\n\n\n\n Sobre la longitud: no hay un n\u00famero m\u00e1gico, pero cadenas de m\u00e1s de 7 pasos comienzan a sufrir. La m\u00e9trica pr\u00e1ctica no es el n\u00famero de pasos, sino el tiempo total de ejecuci\u00f3n y la tasa de errores por paso. Si necesitas m\u00e1s de 7, probablemente puedes fusionar pasos adyacentes o paralelizar los independientes.<\/p>\n\n\n\n Y s\u00ed, funciona con modelos peque\u00f1os. De hecho, es donde su ventaja es mayor: dividir una tarea compleja en pasos simples se alinea con las capacidades de modelos como Llama 3 8B o Qwen 2.5 7B. Solo valida m\u00e1s agresivamente entre pasos.<\/p>\n\n\n\n Cuando un prompt monol\u00edtico produce resultados inconsistentes, omite instrucciones intermedias (instruction neglect) o la tarea requiere m\u00e1s de 3 operaciones sem\u00e1nticas distintas. La se\u00f1al clara es cuando el modelo cumple bien la primera y \u00faltima instrucci\u00f3n pero falla las centrales.<\/p>\n\n\n\n S\u00ed, y es donde su ventaja es mayor. Los modelos peque\u00f1os (7B-8B par\u00e1metros) son m\u00e1s propensos a errores de formato en tareas complejas. Dividir la tarea en pasos simples se alinea con sus capacidades. Requiere validaci\u00f3n m\u00e1s agresiva entre pasos con Pydantic o esquemas tipados.<\/p>\n\n\n\n Son ortogonales. RAG a\u00f1ade conocimiento externo al contexto recuperando documentos relevantes. Prompt Chaining estructura el flujo de procesamiento en pasos secuenciales. Se combinan frecuentemente: paso 1 recupera con RAG, paso 2 extrae datos, paso 3 genera an\u00e1lisis.<\/p>\n\n\n\n No hay un n\u00famero absoluto, pero cadenas de m\u00e1s de 7 pasos comienzan a sufrir en latencia y mantenimiento. La m\u00e9trica pr\u00e1ctica es el tiempo total de ejecuci\u00f3n y la tasa de errores por paso. Si necesitas m\u00e1s de 7, fusiona pasos adyacentes o paraleliza los independientes.<\/p>\n\n\n\n LangChain (LCEL) es suficiente para pipelines lineales y paralelizaci\u00f3n b\u00e1sica con Con esquemas tipados. En Python, Pydantic permite definir clases con anotaciones de tipo y usar Prompt Chaining no hace m\u00e1s inteligente al modelo. Hace m\u00e1s controlable el sistema. En producci\u00f3n, eso suele importar m\u00e1s.<\/p>\n\n\n\n El patr\u00f3n es independiente de herramienta: funciona con llamadas secuenciales a cualquier API, validaci\u00f3n con Pydantic o cualquier esquema tipado, y orquestaci\u00f3n con c\u00f3digo Python est\u00e1ndar. LangChain y LangGraph simplifican los prototipos, pero muchas implementaciones terminan reescribiendo partes cr\u00edticas por problemas de complejidad y observabilidad.<\/p>\n\n\n\n Al final, lo que marca la diferencia no es el framework que elijas, sino como defines los contratos entre pasos y qu\u00e9 tan agresivamente validas las transiciones.<\/p>\n","protected":false},"excerpt":{"rendered":" Prompt Chaining descompone tareas complejas en pasos secuenciales para evitar instruction neglect, contextual drift y error propagation. Gu\u00eda pr\u00e1ctica con c\u00f3digo Python, patrones de producci\u00f3n y Context Engineering.<\/p>\n","protected":false},"author":1,"featured_media":539,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135,50,6,37],"tags":[88,82,86,85,84,83,87],"class_list":["post-241","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agentes","category-fundamentos","category-ia-automatizacion","category-software","tag-context-engineering","tag-langchain","tag-langgraph","tag-llm","tag-pipeline-pattern","tag-prompt-chaining","tag-pydantic"],"_links":{"self":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts\/241","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/comments?post=241"}],"version-history":[{"count":10,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts\/241\/revisions"}],"predecessor-version":[{"id":681,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts\/241\/revisions\/681"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/media\/539"}],"wp:attachment":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/media?parent=241"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/categories?post=241"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/tags?post=241"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}cpu<\/code> a processor<\/code> entre ejecuciones. Variaciones que parecen menores pero rompen el consumidor downstream.<\/p>\n\n\n\nfrom pydantic import BaseModel, Field, ValidationError\nimport logging\n\nlogger = logging.getLogger(__name__)\n\nclass Specs(BaseModel):\n cpu: str\n memory_gb: int = Field(ge=1, le=512)\n storage_tb: float = Field(ge=0.1, le=20)\n\ndef validate_extraction(response: str) -> Specs:\n try:\n return Specs.model_validate_json(response)\n except ValidationError as e:\n logger.error(f\"Extraction failed validation: {e}\")\n raise\n<\/code><\/pre>\n\n\n\nnull<\/code> en lugar de string vac\u00edo tras una actualizaci\u00f3n silenciosa de la versi\u00f3n. Un cambio m\u00ednimo en un nombre de campo rompe silenciosamente todo el pipeline downstream. Los tests que cubren solo el caso happy path no detectan esto.<\/p>\n\n\n\n
\n\n\n\nPatrones que realmente se usan<\/h2>\n\n\n\n
\n
RunnableParallel<\/code>. LangGraph lo modela como nodos independientes que convergen en un nodo de uni\u00f3n. Ambos funcionan. Elige seg\u00fan necesites estado compartido o no.<\/p>\n\n\n\n
\n\n\n\nLo que suele romperse en producci\u00f3n<\/h2>\n\n\n\n
\n
model_validate_json()<\/code> captura esto, pero muchos pipelines usan json.loads()<\/code> y asumen que \u00absi no explota, est\u00e1 bien\u00bb. No lo est\u00e1.<\/li>\n\n\n\n
\n\n\n\nContext Engineering<\/h2>\n\n\n\n
\n
CallbacksHandler<\/code>, LangGraph persiste el estado del grafo, y sin framework un logger estructurado con conteos de input\/output tokens basta para detectar cu\u00e1ndo est\u00e1s cerca del l\u00edmite. Cuando lo est\u00e1s, activa la compresi\u00f3n sem\u00e1ntica o el truncamiento inteligente.<\/li>\n\n\n\n
\n\n\n\nChaining vs agentes: la verdad inc\u00f3moda<\/h2>\n\n\n\n
Criterio<\/th> Prompt Chaining<\/th> Agentes<\/th><\/tr><\/thead> Control de flujo<\/td> C\u00f3digo determinista<\/td> Modelo (ReAct)<\/td><\/tr> Predictibilidad<\/td> Alta<\/td> Baja<\/td><\/tr> Costo de tokens<\/td> Fijo<\/td> Variable<\/td><\/tr> Flexibilidad<\/td> Baja<\/td> Alta<\/td><\/tr> Observabilidad<\/td> Directa<\/td> Requiere trace completo<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nCu\u00e1ndo no usarlo<\/h2>\n\n\n\n
\n\n\n\nPreguntas frecuentes sobre Prompt Chaining<\/h2>\n\n\n\n
\u00bfCu\u00e1ndo usar Prompt Chaining en lugar de un solo prompt?<\/h3>\n\n\n\n
\u00bfPrompt Chaining funciona con modelos locales como Llama 3 o Qwen?<\/h3>\n\n\n\n
\u00bfCu\u00e1l es la diferencia entre Prompt Chaining y RAG?<\/h3>\n\n\n\n
\u00bfCu\u00e1ntos pasos debe tener una cadena de prompts?<\/h3>\n\n\n\n
\u00bfQu\u00e9 framework usar para Prompt Chaining: LangChain o LangGraph?<\/h3>\n\n\n\n
RunnableParallel<\/code>. LangGraph es necesario cuando necesitas estado compartido entre pasos, bucles condicionales, o reanudaci\u00f3n de pipelines interrumpidos. Para la mayor\u00eda de casos, LangChain es suficiente.<\/p>\n\n\n\n\u00bfC\u00f3mo validar la salida de un LLM en Prompt Chaining?<\/h3>\n\n\n\n
model_validate_json()<\/code> para parsear directamente la respuesta del modelo. Si la validaci\u00f3n falla, captura ValidationError<\/code> con informaci\u00f3n precisa sobre qu\u00e9 campo fall\u00f3. Nunca uses solo json.loads()<\/code> asumiendo que el JSON es v\u00e1lido.<\/p>\n\n\n\n
\n\n\n\nConclusi\u00f3n<\/h2>\n\n\n\n