Cómo crear un pipeline de IA: Borrador, Crítica, Revisión

Un Pipeline ejecuta varios modelos de IA en secuencia, donde cada etapa trabaja sobre el resultado de la etapa anterior. En lugar de pedir a un solo modelo que escriba, revise y corrija todo en una sola respuesta, divides el trabajo en etapas: Borrador, Crítica, Revisión y, de forma opcional, Pulido. Cada etapa tiene una tarea, así que el resultado mejora paso a paso en lugar de hacerlo todo de golpe.

Esta guía muestra qué es un Pipeline, cuándo supera a un solo prompt, cómo montar uno etapa por etapa y en qué se diferencia de Equipo y Judge.

¿Qué es un pipeline de IA?

Un Pipeline es un flujo de trabajo secuencial. Asignas un modelo a cada etapa, y el resultado de una etapa se convierte en la entrada de la siguiente. Una cadena habitual es Borrador a Crítica a Revisión, con una etapa opcional de Pulido al final.

Piénsalo como una mesa de redacción. Un modelo escribe la primera versión. Un segundo modelo lee esa versión y enumera lo que está flojo, lo que falta o lo que está mal. Un tercer modelo toma tanto el borrador como la crítica y produce una versión mejorada. Una etapa final puede ajustar el tono y el formato. Cada relevo lleva el trabajo hacia adelante, de modo que la calidad se va acumulando.

Esto es distinto de enviar el mismo prompt a varios modelos a la vez. En un Pipeline, los modelos no compiten ni se ejecutan en paralelo. Cooperan en orden, y cada uno retoma donde lo dejó el anterior.

¿Cuándo supera un pipeline a un solo prompt?

Usa un Pipeline cuando la tarea tiene por naturaleza más de un paso y el primer intento rara vez es la respuesta final. Un solo prompt pide a un modelo que lo haga todo en una sola pasada, lo que mezcla la redacción y la autocorrección en la misma respuesta. Eso funciona para peticiones cortas y sencillas. Pero falla cuando el trabajo necesita una revisión de verdad.

Un Pipeline gana en tres casos habituales:

• Escritura. Redacta el borrador de un artículo o un correo, critícalo en cuanto a claridad y lagunas, y luego revísalo. La etapa de crítica detecta las afirmaciones vagas y el contexto que falta que la etapa de borrador pasó por alto.
• Código. Redacta el borrador de una función, critícala en cuanto a casos límite y seguridad, y luego revísala para hacerla más robusta. Separar "escribirla" de "romperla" saca a la luz errores que una sola pasada suele saltarse.
• Análisis. Redacta el borrador de un resumen o una recomendación, critica el razonamiento y los supuestos, y luego revísalo hasta llegar a una conclusión más ajustada.

El hilo común es que la etapa de crítica hace un trabajo que el modelo del borrador no haría bien por sí solo. Pedir a un modelo que encuentre fallos en su propio resultado recién creado, en la misma respuesta, es más débil que dar a una etapa aparte una sola tarea: desmontarlo.

Cómo crear un pipeline paso a paso

En aiDex abres aiDex e inicias un Pipeline. El orden en que eliges los modelos se corresponde con las etapas. Así es como se configura cada rol.

1. Elige un modelo para el Borrador. Esta etapa produce la primera versión. Elige un buen generador, con amplitud. Para la escritura, un modelo de frontera capaz te da una primera pasada rica de la que partir. Para el código, elige un modelo con buena capacidad de programación. El borrador no tiene por qué ser perfecto, tiene que ser lo bastante completo como para poder criticarlo.

2. Elige un modelo para la Crítica. Esta etapa lee el borrador y enumera los problemas. No reescribe nada. Un buen modelo de crítica es agudo razonando y está dispuesto a ser tajante. Usar un modelo distinto aquí es precisamente la clave: un segundo conjunto de pesos detecta cosas que el primer modelo dio por buenas. Si no tienes claro qué modelo razona mejor para tu tarea, nuestra guía ¿Qué modelo de IA para cada tarea? te ayuda a emparejar modelos con roles.

3. Elige un modelo para la Revisión. Esta etapa toma el borrador y la crítica y produce una versión mejorada. Elige un modelo que siga las instrucciones de cerca y escriba con limpieza, ya que su tarea es aplicar las correcciones con fidelidad en lugar de inventar un nuevo rumbo.

4. De forma opcional, añade una etapa de Pulido. Usa un modelo final para afinar el tono, el formato y la coherencia sin cambiar el fondo. Un modelo rápido y económico suele bastar aquí.

Luego escribe tu prompt, envíalo y observa cómo el resultado se va refinando a lo largo de la cadena. Puedes usar OpenAI, Anthropic (Claude), Google (Gemini), DeepSeek o un modelo local a través de Ollama en cualquier etapa. Usa tus propias claves de proveedor o las que gestionamos nosotros, y elige los modelos que quieras.

¿Por qué usar modelos distintos en cada etapa?

Mezclar modelos es una ventaja, no una complicación. Cada modelo tiene sus propios puntos fuertes y sus propios puntos ciegos. Un modelo que redacta de maravilla puede ser demasiado complaciente para criticar su propio estilo. Un modelo que razona a fondo sobre los casos límite puede escribir una prosa rígida. Al asignar modelos distintos al Borrador, la Crítica y la Revisión, aprovechas la fuerza de cada uno donde importa y evitas que la debilidad de un solo modelo domine todo el resultado.

Usar un solo modelo en todas las etapas también funciona, y es un buen punto de partida. Pero la etapa de crítica resulta bastante más útil cuando un modelo nuevo lee el borrador, porque no tiene apego a las decisiones que tomó el modelo del borrador.

Ejemplo práctico: reforzar un fragmento de código

Supongamos que quieres una función fiable de validación de entradas.

• Borrador: "Escribe una función que valide y normalice la dirección de correo electrónico de un usuario." El modelo del borrador devuelve una primera versión funcional.
• Crítica: el siguiente modelo lee esa función y enumera los problemas: no contempla los dominios internacionalizados, no recorta los espacios en blanco, no tiene límite de longitud y carece de pruebas.
• Revisión: el tercer modelo toma la función más esa lista y devuelve una versión más robusta que aborda cada punto.
• Pulido (opcional): un modelo final añade comentarios de documentación y una nomenclatura coherente.

Terminas con un código que ya ha pasado por una revisión, sin haber escrito tú la revisión. El mismo patrón funciona para la prosa: redacta el borrador del ensayo, critícalo en cuanto a argumentos flojos y revísalo hasta dejarlo más ajustado.

Consejos para definir bien los roles de cada etapa

• Da a cada etapa una sola tarea. No le pidas a la etapa de crítica que también reescriba. Mantener los roles claros es lo que hace que la cadena funcione.
• Haz que la etapa de crítica sea dura. Una crítica amable produce una revisión perezosa. Quieres que los puntos flojos queden señalados sin rodeos.
• Empareja el modelo con el rol, no solo con la tarea. El mejor redactor no siempre es el mejor crítico.
• Mantén el Pulido ligero. Si tu etapa de Pulido está reescribiendo el fondo, la etapa de Revisión no terminó su tarea.

Pipeline frente a Equipo frente a Judge: ¿cuál usar?

Estos tres modos usan más de un modelo, pero se diferencian en cómo se relacionan los modelos entre sí.

• Pipeline es refinamiento secuencial. Los modelos se ejecutan en orden y cada uno mejora el resultado del anterior. Úsalo cuando el trabajo necesita pasos: borrador, luego crítica, luego revisión.
• Equipo es una mesa redonda. Personas con nombre debaten juntas con un moderador atento al consenso. Úsalo cuando quieras que los modelos reaccionen entre sí en una conversación, en lugar de pasar el trabajo hacia adelante en una línea. Consulta Cómo crear un equipo multi-IA.
• Judge reparte un prompt a un panel y luego sintetiza las respuestas en un único mejor resultado. Úsalo cuando quieras combinar varios intentos independientes, en lugar de refinarlos por etapas.

Si tu objetivo es un resultado final pulido construido mediante revisión, recurre a Pipeline. Si tu objetivo es el debate o una única respuesta sintetizada, recurre a Equipo o a Judge. Para un mapa más completo de cuándo combinar modelos, consulta Flujos de trabajo de IA multimodelo.