![Imagen de portada de [Diseño de agentes #3] Pipeline de contenido con IA](/assets/images/posts/1dba3ed2-79c4-4348-b5e7-3014c4d498aa/ai-content-pipeline-1.jpg)
Cuando se habla de crear contenido con IA, normalmente pensamos en un «prompt mágico». Pero los resultados obtenidos de una sola vez tienen una calidad irregular y, al final, alguien debe corregirlos por completo.
¿Y si cambiamos el enfoque y dividimos la generación en etapas, como una línea de producción? Dejamos la creación del borrador, la revisión de calidad, la generación de imágenes y la publicación como procesos independientes, con validaciones entre ellos.
Operé un pipeline que automatiza la producción de artículos de blog con esta estructura y resumí los principios de diseño obtenidos. Aunque el caso pertenece a un dominio concreto, la estructura puede trasladarse a cualquier automatización con IA.
Este artículo resume la composición del pipeline, los mecanismos de validación entre etapas y el diseño del manejo de fallos.
Empecemos por el resumen clave.
- La base del pipeline de generación es separar las etapas: generación → revisión → creación de recursos → publicación.
- Fijar el esquema de salida de cada etapa permite validar y reintentar durante el proceso.
- La revisión de calidad también debe automatizarse. Añadimos una etapa de revisión con una perspectiva distinta a la del modelo que genera el contenido.
- Los fallos son una condición asumida. Lo esencial es conservar el original aunque el proceso falle en cualquier etapa.
Separación por etapas: la diferencia decisiva frente a generar de una vez
Esta es la estructura del pipeline.
Entrada de palabras clave → generación del cuerpo → revisión de estilo (edición) → generación de imágenes → almacenamiento → publicación. Cada etapa es un proceso independiente que solo recibe como entrada el resultado de la etapa anterior.
Frente a la generación de una sola vez, hay tres ventajas.
- Reintentos por etapa: aunque falle la generación de imágenes, el cuerpo permanece. Solo hay que volver a ejecutar el proceso fallido.
- Sustitución por etapa: puedes cambiar la lógica de revisión de estilo sin tocar la etapa de generación.
- Medición por etapa: puedes seguir con métricas en qué proceso se deteriora la calidad.
Los principios de cohesión y acoplamiento tratados en la serie sobre modularización se aplican directamente. Agrupamos la lógica que cambia junta y comunicamos los procesos mediante esquemas.
Fija el esquema de salida
La separación por etapas requiere una condición: el resultado de cada etapa debe tener un formato validable.
En este pipeline, el resultado de la generación del cuerpo tiene un esquema fijo: «matriz de candidatos de título + cuerpo + matriz de prompts de imagen + matriz de etiquetas». Las posiciones de las imágenes dentro del cuerpo se indican mediante una convención como [marcador de imagen].
Con un esquema fijo, el código del pipeline puede validar la salida del LLM en lugar de confiar en ella.
| Elemento de validación | Tratamiento en caso de fallo |
|---|---|
| Presencia de campos obligatorios | Reintentar la generación |
| Número de marcadores de imagen = número de prompts | Reintentar la generación |
| ¿Se dañaron los marcadores tras la revisión? | Descartar el resultado de la revisión y conservar el original |
Al incorporar un LLM al pipeline, la salida deja de ser algo que se «cree» y pasa a ser algo que se «valida». El esquema es la referencia para esa validación.
La revisión también es un proceso independiente
La etapa de revisión de estilo es especialmente interesante. Los textos escritos por IA conservan rasgos característicos (ritmo uniforme, estilo de traducción y estructuras paralelas mecánicas), así que separamos su edición en un proceso LLM independiente.
Hay una razón por la que separar esta tarea funciona mejor que añadir «escribe de forma natural» al prompt de generación.
La generación se concentra en la precisión del contenido y la revisión, únicamente en el estilo. Si concentras ambos objetivos en un prompt, los dos quedan a medias; al separar los procesos, cada uno puede optimizar un solo objetivo.
Es la versión de los prompts del principio de responsabilidad única.
Aquí se añade una regla: el proceso de revisión nunca debe cambiar el contenido, las cifras ni las citas; solo debe ajustar el estilo.
Por eso, después de revisar, comparamos mecánicamente si se conservaron los marcadores de imagen y las cifras clave. Si detectamos daños, descartamos el resultado de la revisión y usamos el original.
Diseñar asumiendo los fallos
Todas las llamadas externas del pipeline pueden fallar: desde las llamadas al LLM y la API de generación de imágenes hasta las herramientas de renderizado. Por eso, el manejo de fallos no es una función secundaria, sino parte de la estructura.
Hay tres principios.
Primero, conservar el original. Ningún proceso sobrescribe el resultado de la etapa anterior. Si la revisión falla, el original debe permanecer intacto.
Segundo, permitir éxitos parciales. Si falla una de cuatro imágenes, guardamos las otras tres y registramos el fallo. Revertirlo todo sería una respuesta excesiva.
Tercero, hacer visibles los fallos. En lugar de ocultar los errores, los dejamos en un campo de estado para que una persona pueda volver a ejecutar desde el panel solo el proceso fallido.
Conclusión
En resumen, la calidad de la automatización con IA proviene del diseño del proceso, no del modelo: dividir las etapas, validar con esquemas y diseñar para los fallos.
Los principios de la ingeniería tradicional de pipelines siguen siendo válidos en la era de los LLM.
Al leerlo junto con los artículos sobre ingeniería de harnesses e ingeniería de contexto, tendrás el mapa completo de las «técnicas para usar bien los modelos».