57 · Pipelines: componer preprocesamiento + modelo
Encadena transformadores y un estimador final en un solo objeto con un único `fit`/`predict` — la única forma honesta de preprocesar dentro de la validación cruzada.
Un `Pipeline` encadena transformadores y un estimador final en UN solo objeto que se comporta como un único estimador: un `fit`, un `predict`. Aplica exactamente el mismo preprocesamiento a train, test y producción automáticamente — y es la única forma de mantener honesta la validación cruzada.
Sin esto:
Sin un pipeline debes re-aplicar manualmente cada transformación — en el orden correcto, con las estadísticas ajustadas correctas — a los datos de test y producción. Si olvidas un paso, las predicciones se rompen en silencio; si escalas antes de dividir, tus puntajes de validación cruzada quedan filtrados e inflados sin que lo notes.
El problema que resuelven los pipelines
En la lección anterior escalaste, codificaste y ajustaste un modelo como pasos separados. Eso funciona en un notebook — pero es frágil. Para predecir sobre datos nuevos debes acordarte de re-ejecutar cada transformación, en el mismo orden, usando las mismas estadísticas ajustadas. Olvida una y tu modelo recibe datos cuya forma nunca ha visto.
Peor aún, el enfoque manual hace deshonesta la validación cruzada. Si escalas todo el dataset y después corres CV, el escalador de cada fold ya absorbió estadísticas de los otros folds — el fold de test se filtra en el preprocesamiento. Tu puntaje de CV sale optimista, y despliegas un modelo que rinde por debajo.
Un Pipeline corrige ambos problemas. Encadena una secuencia de transformadores y un estimador final en un objeto compuesto que a su vez obedece la API de estimadores:
pipe.fit(X_train, y_train)— ajusta cada transformador y el modelo final en secuencia.pipe.predict(X_test)— aplica cada transformación ajustada, y luego predice.
Desde fuera, todo el pipeline es un único estimador. Puedes pasarlo a cross_val_score, GridSearchCV o joblib.dump exactamente como un modelo pelado — y el preprocesamiento viaja con él.
Python (in browser)
El `Pipeline` de `StandardScaler` + `LogisticRegression` se ajusta y evalúa con llamadas únicas. El escalado y la predicción se manejan internamente — el conjunto de test se escala con estadísticas de train automáticamente, así que la fuga es imposible por construcción.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
`make_pipeline` es el atajo: nombra cada paso automáticamente según su clase (`standardscaler`, `logisticregression`). Inspecciona o accede a cualquier paso ajustado vía `pipe.named_steps['<nombre>']`.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
Un `Pipeline` cuyo primer paso es un `ColumnTransformer` (escalador para numéricas, one-hot para categóricas) y cuyo paso final es un clasificador. Todo el flujo de preprocesamiento de tipos mixtos más el modelo es ahora un único objeto de ajustar-y-evaluar.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Durante `fit`, cada paso excepto el último ejecuta `fit_transform`; el estimador final solo ejecuta `fit`. Durante `predict`, cada transformador ejecuta solo `transform` (reutilizando estadísticas ajustadas), y luego el estimador predice.
¿Cómo evita un Pipeline la fuga de datos durante la validación cruzada?
- Un `Pipeline` encadena transformadores + un estimador final en un solo objeto con un único `fit`/`predict`; desde fuera se comporta como un estimador pelado.
- `make_pipeline` nombra los pasos automáticamente; inspecciona los pasos ajustados vía `pipe.named_steps`. Un `Pipeline` puede envolver un `ColumnTransformer` para datos de tipos mixtos.
- Los pipelines mantienen honesta la validación cruzada: cada fold re-ajusta todo el preprocesamiento sobre su propia porción de train, así que las estadísticas del fold de test nunca se filtran.
El código de ML en producción es casi siempre un pipeline: empaqueta el preprocesamiento con el modelo para que exactamente las mismas transformaciones apliquen en entrenamiento, validación y servicio. `GridSearchCV` y `cross_val_score` dependen de los pipelines para ajustar y evaluar sin fugas.
Si lo quitas: Sin pipelines reimplementarías el preprocesamiento a mano para cada división de datos y despliegue, introduciendo inevitablemente errores de orden de operaciones y fugas silenciosas en la validación cruzada que inflan tus métricas reportadas.