Hay un patrón que se repite con frecuencia en proyectos de Machine Learning: el modelo funciona bien en el ambiente de pruebas, se despliega en producción, y tres o seis meses después la calidad de las predicciones bajó sin que nadie lo detectara a tiempo. Cuando se investiga la causa, el modelo en sí raramente es el problema. El problema es el proceso que lo alimenta.
Un modelo de ML en producción no es un archivo estático que responde consultas. Es un sistema dinámico que depende de datos actualizados con frecuencia definida, de un proceso de transformación que debe ejecutarse de forma idéntica en cada ciclo, y de mecanismos de monitoreo que detecten cuándo algo cambia. Sin orquestación, ese sistema se mantiene con intervención manual, scripts sin monitoreo y esperanza de que nadie toque nada que rompa el flujo.
Por qué Apache Airflow es la capa de orquestación para pipelines de ML
Apache Airflow permite modelar el pipeline completo como un DAG (Directed Acyclic Graph): un conjunto de tareas con dependencias explícitas, donde cada tarea solo se ejecuta si la anterior completó con éxito. Eso garantiza que el modelo nunca se alimenta con datos que no pasaron validación, y que ninguna etapa se ejecuta fuera del orden definido.
Cada ejecución queda registrada con su estado, sus logs y el tiempo de procesamiento por tarea. Cuando algo falla, la trazabilidad está disponible de forma inmediata, sin necesidad de reconstruir qué pasó a partir de logs dispersos.
Estructura de un pipeline de ML con Apache Airflow
La siguiente estructura corresponde a un pipeline de entrenamiento periódico, diseñado para ejecutarse de forma automática con frecuencia semanal o diaria según el tipo de modelo y la velocidad de cambio de los datos.
Etapa 1: Ingesta incremental
El DAG extrae datos desde los sistemas fuente de forma incremental: solo los registros nuevos o modificados desde la última ejecución exitosa. Esto reduce el tiempo de procesamiento y evita recargar datos que no cambiaron.
La tarea de ingesta debe manejar de forma explícita los errores de conectividad con los sistemas fuente, con reintentos configurados y tiempo de espera antes de declarar el fallo. Una ingesta fallida no debe bloquear el pipeline de forma silenciosa: debe generar alerta y detenerse de forma controlada.
Etapa 2: Validación de datos
Antes de transformar los datos, el pipeline verifica que los registros ingeridos cumplen los criterios de calidad definidos: rangos válidos para variables numéricas, tipos de datos correctos, ausencia de valores nulos en campos críticos, y consistencia con la distribución histórica esperada.
Si la validación falla, el DAG se detiene en esta etapa y genera alerta. El pipeline no avanza al feature engineering con datos de calidad desconocida. Esta es la barrera más importante del pipeline: sin ella, los errores en los datos de origen se propagan de forma silenciosa hasta el modelo.
Etapa 3: Feature engineering
Las transformaciones definidas durante el desarrollo del modelo se ejecutan de forma automatizada y reproducible: cálculo de variables derivadas, normalización, codificación de variables categóricas, imputación de valores faltantes con la estrategia definida.
Un punto crítico: las transformaciones deben aplicarse usando exactamente los mismos parámetros que se usaron durante el entrenamiento. Si el escalador de variables se ajustó con los datos de entrenamiento, el mismo escalador —con los mismos parámetros— debe aplicarse en producción.
Esto requiere que los parámetros de transformación estén versionados y almacenados junto al modelo. Herramientas como MLflow permiten registrar estos artefactos —escaladores, encoders, estrategias de imputación— junto a cada versión del modelo, de modo que el pipeline de producción siempre aplique los parámetros correspondientes al modelo activo y no una versión desactualizada o incorrecta.
Etapa 4: Entrenamiento o actualización del modelo
Según la estrategia definida, el pipeline puede reentrenar el modelo completo con los datos del período más reciente, o actualizar solo los componentes que lo requieren. La frecuencia de reentrenamiento depende de la velocidad con que cambia la distribución de los datos y del costo computacional del proceso.
Esta etapa debe ejecutarse en un ambiente reproducible y con los recursos computacionales necesarios garantizados. Si el entrenamiento se ejecuta en un entorno que no está disponible o no tiene los recursos suficientes, el fallo debe ser explícito y generar alerta.
Etapa 5: Evaluación y promoción
El modelo entrenado se evalúa contra las métricas definidas antes del proyecto: precisión, recall, F1, error cuadrático medio, o la métrica de negocio relevante para el caso de uso. El pipeline compara el resultado contra un umbral mínimo definido.
Si las métricas superan el umbral, el modelo se promueve a producción de forma automática. Si no lo superan, el pipeline retiene la versión anterior en producción y genera una alerta para revisión manual. El modelo en producción nunca se reemplaza por uno de menor calidad de forma automática.
Punto de entrada recomendado
Para equipos sin experiencia previa con Apache Airflow, el error frecuente es intentar implementar el pipeline completo desde el inicio. Eso genera una curva de aprendizaje simultánea en múltiples dimensiones: la herramienta de orquestación, el diseño de DAGs, y el proceso de ML en sí.
El punto de entrada recomendado en Aleph Server es comenzar con las dos primeras etapas: ingesta automática y validación de datos. Eso solo ya elimina uno de los problemas más frecuentes en producción y entrega valor medible antes de construir el pipeline completo.
Desde ahí, cada etapa se agrega de forma incremental, validando en producción antes de incorporar la siguiente. El pipeline completo se construye en semanas, no en un sprint único.
Lo que el pipeline no reemplaza
Apache Airflow orquesta el proceso. No define qué features son relevantes, no decide la arquitectura del modelo, y no interpreta si los resultados tienen sentido de negocio. Esas decisiones requieren criterio del equipo técnico y del área de negocio que usa las predicciones.
La orquestación garantiza que el proceso se ejecuta de forma confiable. La calidad del resultado depende de las decisiones que se tomaron antes de empezar a construir el DAG.
