28 · Proyecto ML de extremo a extremo: una pipeline completa
Une cada paso en una sola pipeline reproducible: cargar, explorar, dividir, preprocesar, entrenar, ajustar, evaluar, persistir. Este es el entregable.
Une cada paso en una sola pipeline reproducible: cargar, explorar, dividir, preprocesar, entrenar, ajustar, evaluar, persistir. Este es el entregable.
Sin esto:
Sin un modelo mental de extremo a extremo, las lecciones individuales se sienten desconectadas; en producción cada paso importa.
Esta lección capstone conecta todo lo que has aprendido en el track de ML Supervisado Clásico en un único artefacto desplegable. El objetivo no es un nuevo algoritmo — es la forma que toma todo proyecto de ML en producción.
Los 8 pasos de ML en producción
| Paso | Qué haces |
|---|---|
| 1. Cargar y explorar | Entender distribuciones, valores faltantes, tipos |
| 2. División train/test | Reservar un conjunto SEPARADO — nunca tocarlo hasta el paso 7 |
| 3. Preprocesar | ColumnTransformer + Pipeline para escalar/codificar características |
| 4. Baseline | Ajustar el modelo más simple posible (predictor constante, modelo lineal) |
| 5. Entrenar candidatos | Ajustar múltiples algoritmos; comparar scores de CV |
| 6. Ajustar el ganador | GridSearchCV solo en el conjunto TRAIN — test todavía intacto |
| 7. Evaluar honestamente | Puntuar el modelo ajustado en el conjunto de test SEPARADO |
| 8. Persistir | joblib.dump(pipeline, path) — guardar TODA la pipeline, no solo el modelo |
¿Por qué sklearn Pipeline?
Un Pipeline encadena preprocesamiento y modelo en un solo objeto. Cuando llamas pipeline.fit(X_train, y_train):
- El
ColumnTransformerajusta sus escaladores y codificadores SOLO en datos de entrenamiento. - Cuando llamas
pipeline.predict(X_test), las mismas transformaciones se aplican consistentemente.
Sin un Pipeline, debes rastrear y reaplicar manualmente las transformaciones en inferencia — una fuente común de filtración de datos y bugs en producción.
Prevención de filtración de datos
Ajustar un escalador en el conjunto completo (train + test) antes de dividir filtra estadísticas del test al proceso de entrenamiento. Siempre: dividir primero, luego ajustar transformadores en TRAIN, luego transformar TEST.
Python (in browser)
Pasos 1–3: cargar el dataset de diabetes, dividir los datos y construir un `Pipeline(preprocessor + LinearRegression)`. La disciplina clave: el conjunto de test se crea en el paso 2 y se deja completamente intacto hasta la evaluación final. El `ColumnTransformer` ajusta `StandardScaler` solo en `X_train`.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
Pasos 4 y 5: comparar cuatro modelos candidatos usando validación cruzada de 5-fold solo en el conjunto de entrenamiento. El conjunto de test todavía está intacto. La validación cruzada da una estimación imparcial del rendimiento de generalización para cada candidato sin mirar jamás el holdout.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
Paso 6: `GridSearchCV` ajusta los hiperparámetros del modelo ganador usando CV de 5-fold solo en los datos de entrenamiento. El prefijo `model__` en `param_grid` apunta al paso `model` dentro del `Pipeline`. El resultado es la mejor combinación de parámetros encontrada sin ningún contacto con el conjunto de test.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
Pasos 7 y 8: la evaluación final usa el conjunto de test por PRIMERA y ÚNICA vez. `joblib.dump` persiste toda la `Pipeline` — tanto el `StandardScaler` como el `GradientBoostingRegressor` — como un único archivo. Recargarlo da un objeto de inferencia listo para usar que aplica las transformaciones correctas automáticamente.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Un modelo listo para producción no es solo un estimador ajustado — es un artefacto reproducible y documentado que aplica transformaciones idénticas en inferencia que en entrenamiento. Esta lista captura las seis fuentes más comunes de bugs de 'el modelo falló en producción'.
¿Por qué usar `Pipeline` de sklearn en lugar de ejecutar el preprocesamiento manualmente cada vez?
- El flujo de trabajo de ML de 8 pasos (cargar → dividir → preprocesar → baseline → candidatos → ajustar → evaluar → persistir) es la forma que toma todo proyecto de ML en producción.
- Siempre envuelve el preprocesamiento y el modelo en un `Pipeline` de sklearn — garantiza transformaciones idénticas en entrenamiento e inferencia, y permite persistir todo el flujo de trabajo como un único artefacto.
- El conjunto de test debe reservarse en el paso 2 y tocarse UNA VEZ — en el paso 7. Usarlo antes (para elegir modelos, para ajustar hiperparámetros) causa sesgo optimista e invalida el rendimiento reportado.
- `joblib.dump(pipeline, path)` persiste la pipeline completa (preprocesador + modelo). Siempre guarda y carga la PIPELINE COMPLETA — nunca el estimador desnudo.
- Las seis verificaciones pre-despliegue (preprocesamiento dentro de la pipeline, test intacto, preprocesador guardado, estado aleatorio fijado, orden de características consistente, encoders sin filtraciones) cubren la mayoría de los fallos de ML en producción.
Este es el entregable. Todo proyecto de ML en producción llega al fondo en: 'cargar, preprocesar via pipeline, entrenar, evaluar, persistir'.
Si lo quitas: Tendrías una pila de celdas de Jupyter sin ningún artefacto desplegable.