Programa de Prácticas en Ingeniería de ML

Bloque 4: Arquitectura de Pipelines y Prevención del Data Leakage

Se produce Data Leakage (fuga de datos) cuando el modelo accede durante su construcción a información que no estará disponible en producción. Sus dos formas principales son:

Ambas producen métricas optimistas que no se reproducen en producción. Es el error de mayor impacto en un proyecto de Machine Learning, porque no genera ningún fallo visible durante el desarrollo.

En los Bloques 2 y 3, el preprocesado se aplicó manualmente. Con validación cruzada, ese preprocesado debe recalcularse en cada pliegue, lo que hace inviable y propenso a errores el enfoque manual. Pipeline y ColumnTransformer encapsulan el preprocesado y el modelo en un único estimador: cada llamada a fit() aprende todos los parámetros exclusivamente a partir de los datos que recibe. Además, el Pipeline ajustado es el artefacto que se despliega en producción, lo que garantiza que los datos nuevos reciben exactamente las mismas transformaciones que los datos de entrenamiento.

Prerrequisitos

Material de Referencia

  1. Arquitectura predictiva: Complete los módulos 1, 2 y 7 del Scikit-learn MOOC (Inria). Se exige el dominio de Pipeline, ColumnTransformer y validación cruzada.
  2. Taxonomía de fugas: Revise la lección de Data Leakage de Intermediate Machine Learning (Kaggle Learn), que distingue entre fuga del objetivo y contaminación entre entrenamiento y validación.
  3. Buenas prácticas: Consulte Common pitfalls and recommended practices de la documentación de scikit-learn, en particular las secciones sobre fuga de datos y control de la aleatoriedad.

Actividad Práctica

  1. Cree la rama feat/b04-pipeline desde main actualizada.
  2. Implemente el script B04_Pipelines_y_DataLeakage/pipeline.py, ejecutable con uv run python -m B04_Pipelines_y_DataLeakage.pipeline.
  3. Cargue data/processed/dataset_limpio.parquet y aplique la misma partición entrenamiento/prueba del Bloque 2. Hasta el paso 8, todas las operaciones utilizan exclusivamente X_train e y_train.
  4. Construya un ColumnTransformer con dos ramas:
    • Variables numéricas: SimpleImputer (con la estrategia definida en el Bloque 1) seguido de StandardScaler.
    • Variables categóricas: SimpleImputer(strategy="most_frequent") seguido de OneHotEncoder(handle_unknown="ignore").

El escalado no altera los resultados de un Random Forest, pero se incluye porque es obligatorio para los métodos del Bloque 5 y para cualquier modelo sensible a la escala de las variables.

  1. Construya el Pipeline completo: Pipeline([("preprocesado", column_transformer), ("modelo", RandomForest...(random_state=42))]). El script no puede contener ninguna llamada a fit() o fit_transform() fuera de este objeto.
  2. Evalúe el Pipeline con cross_validate sobre X_train, usando StratifiedKFold (clasificación) o KFold (regresión) con n_splits=5, shuffle=True y random_state=42, la métrica priorizada en el Bloque 3 como scoring y return_train_score=True. Reporte la media y la desviación típica en los pliegues de entrenamiento y de validación.
  3. Optimice los hiperparámetros del modelo con GridSearchCV o RandomizedSearchCV sobre el Pipeline completo (p. ej., modelo__max_depth, modelo__min_samples_leaf), con la misma estrategia de validación y la misma métrica. En clasificación, seleccione de nuevo el umbral de decisión mediante validación cruzada (TunedThresholdClassifierCV, o cross_val_predict con method="predict_proba").
  4. Ajuste la configuración final sobre X_train completo y evalúela una única vez sobre X_test. Compare el resultado con los obtenidos en los Bloques 2 y 3.
  5. Serialice el Pipeline ajustado con joblib en models/pipeline_b04.joblib. Demuestre en el script que el artefacto, una vez cargado, genera predicciones directamente sobre filas de X_test sin preprocesado previo.
  6. Publique la rama y abra un Pull Request hacia main.

Contenido Obligatorio del Pull Request

Criterios de Aceptación

Transición al Bloque 5

El Pipeline es ahora el marco en el que se integra cualquier transformación adicional. El Bloque 5 introduce transformaciones no supervisadas (PCA y K-Means), que también aprenden parámetros de los datos y, por tanto, deben ajustarse dentro de este mismo Pipeline y evaluarse con el mismo protocolo de validación cruzada.