La narrativa habitual sobre los proyectos de Machine Learning pone el foco en el modelo: qué algoritmo se usa, qué arquitectura de red neuronal, qué hiperparámetros. Esa narrativa es comprensible porque los modelos son la parte visible y técnicamente interesante del trabajo.
El problema es que en la mayoría de los proyectos que fallan en producción, el modelo no es la causa del fallo. La causa es la etapa que viene antes: el proceso de transformar datos brutos en variables que el modelo puede interpretar de forma útil.
Qué es el feature engineering
Un feature es una variable de entrada que el modelo usa para aprender patrones y generar predicciones. Si el objetivo es predecir si un cliente va a abandonar el servicio en los próximos 30 días, algunos features relevantes podrían ser la frecuencia de uso en el último mes, el número de interacciones con soporte registradas, el tiempo desde la última compra, o la variación en el monto mensual facturado.
El problema es que los sistemas de origen —ERP, CRM, bases de datos transaccionales, logs de aplicación— no entregan esas variables directamente. Entregan registros en bruto: fechas en formatos distintos, identificadores, montos sin normalizar, texto libre, campos nulos. Transformar esos registros en variables consistentes, relevantes y utilizables por el modelo es el feature engineering.
Esta transformación incluye operaciones como: calcular diferencias entre fechas, normalizar rangos de valores, codificar variables categóricas, imputar valores faltantes con criterio, agregar información de distintas fuentes, y construir variables derivadas que capturen patrones que los datos crudos no expresan directamente.
Por qué esta etapa consume más tiempo del que se planifica
En proyectos de datos con rigor profesional, entre el 60% y el 80% del tiempo del equipo se invierte en preparación, limpieza y transformación de datos. El entrenamiento del modelo, que es la etapa que aparece en las presentaciones, representa una fracción menor del trabajo real.
Esto no es ineficiencia: es la realidad de trabajar con datos de sistemas productivos que no fueron diseñados para alimentar modelos de ML. Los datos tienen inconsistencias históricas, cambios de formato no documentados, campos que se llenaron de forma distinta según el período, y fuentes que tienen diferentes frecuencias de actualización.
El riesgo aparece cuando el proyecto se planifica asumiendo que los datos están listos para usar. El equipo llega a la etapa de entrenamiento, descubre que las variables necesarias no existen como tal en los sistemas de origen, y el cronograma se extiende sin que la causa sea visible para quien aprobó el proyecto.
Qué ocurre cuando el feature engineering se hace sin rigor
Un modelo entrenado con features mal diseñados puede mostrar métricas aceptables en el ambiente de pruebas y fallar en producción por razones que no son evidentes hasta que el error tiene consecuencias operacionales.
El escenario más frecuente: el conjunto de datos de entrenamiento se preparó de una manera, y los datos que llegan en producción tienen una distribución, un formato o una frecuencia de actualización diferente. Si el proceso de transformación no está documentado, automatizado y probado con datos reales de producción, la discrepancia no se detecta hasta que el modelo entrega predicciones incorrectas de forma sistemática.
El segundo escenario frecuente: features que capturan información del futuro sin que nadie lo detecte durante el desarrollo. Un modelo entrenado con una variable que en producción no está disponible en el momento de hacer la predicción va a mostrar resultados excelentes en evaluación y resultados inutilizables en producción. Este tipo de error, conocido como data leakage, es consecuencia directa de un proceso de feature engineering sin revisión rigurosa.
Los criterios que determinan un feature bien diseñado
Relevancia: el feature debe capturar información que tiene relación causal o correlacional verificable con la variable que se quiere predecir. Incluir variables por intuición sin validación estadística es una fuente frecuente de ruido.
Disponibilidad en producción: el feature debe estar disponible en el momento exacto en que el modelo necesita hacer la predicción. Si requiere datos que llegan con 48 horas de retraso, eso tiene que estar reflejado en el diseño del pipeline.
Reproducibilidad: el proceso de construcción del feature debe estar documentado y automatizado de forma que pueda ejecutarse de manera idéntica sobre datos nuevos. Un feature construido manualmente una sola vez no es un feature de producción.
Estabilidad: el feature debe mantener su distribución y significado a lo largo del tiempo. Una variable que cambia de comportamiento cada trimestre por razones externas al modelo es una fuente de degradación silenciosa.
El rol del feature engineering en un pipeline orquestado
En un pipeline de ML en producción, el feature engineering no es una etapa que se ejecuta una vez durante el desarrollo. Es un proceso recurrente que debe ejecutarse de forma automatizada, monitoreada y con registro de cada ejecución.
Cada vez que llegan datos nuevos, el pipeline debe transformarlos aplicando exactamente las mismas reglas que se aplicaron durante el entrenamiento, verificar que el resultado cumple los criterios de calidad definidos, y generar alertas si alguna variable presenta valores fuera del rango esperado.
En Aleph Server, el análisis de disponibilidad y calidad de datos es el primer paso de cualquier proyecto de ML, antes de definir arquitectura o herramientas. Si ese análisis no produce una respuesta concreta sobre qué variables están disponibles y en qué condición, el cronograma del proyecto no tiene base real.
