A lo largo del curso has usado NumPy, pandas, scikit-learn, XGBoost, LightGBM y Keras sin detenerte a mirar el mapa completo: cada herramienta apareció cuando la necesitabas. Antes de llevar el modelo de churn de MercaFresh a producción, conviene hacer esa pausa. En esta lección ordenamos el ecosistema Python de machine learning por capas, comparamos las opciones que compiten entre sí (TensorFlow frente a PyTorch, las tres bibliotecas de boosting), damos criterios para elegir con cabeza y, sobre todo, aprendemos a fijar y reproducir el entorno de trabajo — porque un modelo que solo funciona "en mi máquina" no puede desplegarse, y esa es exactamente la tarea de la próxima lección.

1. El ecosistema Python de ML, por capas
2. La capa base científica: NumPy, pandas, SciPy y matplotlib
3. ML clásico: scikit-learn y statsmodels
4. Boosting: XGBoost, LightGBM y CatBoost
5. Deep learning: TensorFlow/Keras frente a PyTorch
6. NLP y visión por computador: transformers, spaCy y OpenCV
7. Tabla-resumen: qué biblioteca para qué tarea
8. Criterios para elegir una biblioteca
9. Gestión de entornos: la base de la reproducibilidad

Python domina el machine learning no por el lenguaje en sí, sino por su ecosistema: cientos de bibliotecas que se apoyan unas sobre otras formando capas. Entenderlas como capas evita dos errores típicos: pensar que hay que aprenderlas todas, y no saber cuál toca cuando aparece un problema nuevo.

Lectura del diagrama, de abajo arriba:

• Capa 1 — base científica: arrays, tablas, estadística y gráficos. Todo lo demás se construye encima.
• Capa 2 — ML clásico: los algoritmos de los módulos 4 y 5, con scikit-learn como estándar de facto.
• Capa 3 — boosting: bibliotecas independientes especializadas en gradient boosting (módulo 7), que imitan la API de scikit-learn para integrarse con ella.
• Capa 4 — deep learning: redes neuronales profundas (lección 07-04), con su propio motor de cómputo (GPU, diferenciación automática).
• Capa 5 — dominios: bibliotecas para texto e imagen que empaquetan modelos de deep learning listos para usar.

Para el modelo de churn de MercaFresh —datos tabulares, decenas de miles de clientes— las capas 1 a 3 son suficientes. Las capas 4 y 5 entran en juego con datos no estructurados, como verás en los proyectos de clasificación de imágenes (09-02) y análisis de sentimientos (09-03).

Ya las has usado durante todo el curso; aquí solo fijamos qué papel cumple cada una:

• NumPy: el array n-dimensional y las operaciones vectorizadas. Es la lingua franca: cuando scikit-learn, XGBoost o Keras reciben datos, por debajo son arrays de NumPy. Su velocidad viene de que el bucle ocurre en C, no en Python.
• pandas: el DataFrame, tabla con columnas tipadas y etiquetadas. Es la herramienta de las fases de limpieza y exploración (módulo 3): cargar CSV, agrupar, unir tablas, calcular el RFM de cada cliente.
• SciPy: estadística e ingeniería sobre NumPy. La usaste en el módulo 2 (distribuciones, tests de hipótesis con scipy.stats) y la reutilizarás en la lección 08-03 para detectar drift con el test de Kolmogorov-Smirnov.
• matplotlib (y seaborn encima): visualización. Histogramas, curvas ROC, matrices de confusión — todos los gráficos del curso salen de aquí.

Una consecuencia práctica: cuando una biblioteca de capa superior falla con un error extraño de tipos o dimensiones, la causa suele estar en esta capa (un DataFrame con una columna object inesperada, un array con NaN). Saber bajar a la capa base a depurar es una habilidad, no un fracaso.

Scikit-learn es la biblioteca que más has usado, y merece la pena hacer explícito por qué resulta tan cómoda: toda la biblioteca comparte tres verbos.

Esta coherencia es lo que hace posible el Pipeline que construiste en el módulo 3: como todo objeto responde a los mismos verbos, se pueden encadenar piezas intercambiables, y GridSearchCV (07-05) puede optimizar cualquier combinación sin código especial.

Cambiar de regresión logística a Random Forest es cambiar una línea. Esa uniformidad —que en otros ecosistemas no existe— es la razón por la que scikit-learn es el punto de partida recomendado para casi cualquier problema tabular.

Scikit-learn responde "¿qué predice el modelo?"; statsmodels responde "¿qué dice el modelo sobre los datos?": p-valores por coeficiente, intervalos de confianza, tests de hipótesis (todo el aparato del módulo 2). Si en MercaFresh la pregunta fuera "¿el número de incidencias de entrega tiene un efecto estadísticamente significativo sobre el churn, controlando por antigüedad?", statsmodels es la herramienta adecuada; para predecir qué clientes abandonarán, scikit-learn. Predicción e inferencia son objetivos distintos y cada biblioteca está optimizada para el suyo.

En la lección 07-03 viste que el gradient boosting domina los problemas tabulares, y trabajaste con XGBoost y LightGBM. Las tres bibliotecas principales implementan la misma idea con énfasis distintos:

Las tres ofrecen una interfaz compatible con scikit-learn (XGBClassifier, LGBMClassifier, CatBoostClassifier con fit/predict), así que encajan en el pipeline del churn sin tocar el resto del código. En la práctica, con datos tabulares medianos las tres rinden de forma parecida bien ajustadas; la elección suele decidirla la velocidad de entrenamiento y la comodidad con tus datos concretos.

Para redes profundas (07-04) hay dos ecosistemas dominantes, y conviene una comparación honesta:

¿Cuál elegir? Para aprender y para modelos estándar, Keras (como hiciste en 07-04) sigue siendo la vía más rápida de la idea al modelo entrenado. Si vas a leer e implementar papers recientes, o quieres control fino del entrenamiento, PyTorch es hoy la opción mayoritaria. La buena noticia: los conceptos (capas, funciones de activación, descenso de gradiente, épocas) son idénticos; cambiar de framework es cuestión de días, no de meses. No es una decisión irreversible ni la más importante de tu proyecto.

Presentación breve — los usarás de verdad en el módulo 9:

• Hugging Face transformers: el punto de acceso a modelos preentrenados de lenguaje (BERT, y las familias que viste al final de 07-04) y visión. Su patrón pipeline("sentiment-analysis") da un clasificador de sentimientos funcional en tres líneas; será central en el proyecto 09-03.
• spaCy: NLP "industrial" clásico: tokenización, entidades nombradas, lematización. Rápido y pensado para producción; ideal para preprocesar texto antes de vectorizarlo.
• OpenCV: procesamiento de imagen (leer, redimensionar, filtrar, detectar contornos). Suele ser la capa de preparación antes de una CNN; aparecerá en el proyecto 09-02.

Mención aparte merece el AutoML (auto-sklearn, FLAML, y servicios en la nube): herramientas que automatizan la selección de modelo e hiperparámetros que tú hiciste a mano en 07-05. Útiles como baseline rápido, pero no sustituyen entender lo que ocurre — todo lo que automatizan es exactamente lo que has aprendido en los módulos 6 y 7.

Ante una biblioteca nueva y brillante, aplica tres filtros antes de adoptarla:

1. Madurez y mantenimiento: ¿tiene años de versiones estables, documentación cuidada, y commits recientes? Una biblioteca abandonada es deuda técnica: quedará atada a versiones viejas de NumPy o Python.
2. Comunidad: ¿hay respuestas en Stack Overflow, issues atendidos, tutoriales de terceros? Cuando algo falle a las once de la noche, la comunidad es tu soporte técnico.
3. Necesidad real: ¿resuelve un problema que tus herramientas actuales no resuelven, o solo es novedad? Para el churn de MercaFresh, cambiar scikit-learn + LightGBM por el framework de moda no mejoraría nada y añadiría riesgo. La herramienta aburrida y probada suele ser la decisión profesional correcta.

Un corolario importante para la próxima lección: cada biblioteca que añades es una dependencia que tendrás que instalar, versionar y mantener en producción. La factura de una dependencia no se paga al instalarla, sino al desplegarla y mantenerla durante años.

Aquí pasamos de las bibliotecas a cómo gestionarlas, y es la parte más importante de la lección de cara al despliegue. El problema: entrenas el modelo con scikit-learn 1.5 en tu portátil; el servidor tiene la 1.2; el modelo carga mal o se comporta distinto. Este tipo de fallo silencioso es una de las causas más comunes de errores en producción.

La solución tiene dos piezas:

1. Entornos virtuales aislados — cada proyecto con sus propias versiones, sin contaminar el Python del sistema ni otros proyectos:

2. Versiones fijadas por escrito — un requirements.txt que declara exactamente qué necesita el proyecto:

• pip freeze > requirements.txt vuelca las versiones exactas del entorno actual.
• pip install -r requirements.txt reconstruye el mismo entorno en otra máquina.
• El == (fijar la versión exacta, pinning) es deliberado: en producción no quieres que un pip install de mañana traiga una versión distinta a la de hoy. La reproducibilidad vale más que estar a la última.

Este fichero es un contrato: "el modelo se entrenó con exactamente esto". En la próxima lección lo usaremos dos veces: para cargar el modelo serializado con las mismas versiones con que se guardó, y como pieza central del Dockerfile.

• Coleccionar frameworks en lugar de dominar uno. Saltar de biblioteca en biblioteca produce conocimiento superficial. Domina scikit-learn a fondo: sus conceptos (pipeline, CV, métricas) se transfieren a todo lo demás.
• Elegir deep learning para datos tabulares por defecto. Para problemas como el churn, el boosting sobre árboles suele igualar o superar a las redes con mucho menos coste (lo viste en el módulo 7). Elige la capa del diagrama que el problema pide, no la más alta.
• Trabajar sin entorno virtual. Instalar todo en el Python del sistema acaba en conflictos de versiones entre proyectos. Un entorno por proyecto, siempre, desde el primer día.
• requirements.txt sin versiones (scikit-learn a secas). Funciona hoy y falla dentro de seis meses, cuando una versión nueva cambie un comportamiento. Fija versiones exactas para todo lo que toque el modelo.
• Confundir statsmodels y scikit-learn. Si necesitas p-valores e intervalos de confianza, scikit-learn no te los dará (no es su objetivo); si necesitas pipelines y predicción a escala, statsmodels no es el camino. Son complementarios.
• Consejo: antes de adoptar una dependencia nueva, mira su repositorio: fecha del último commit, número de issues abiertos sin respuesta, y si tiene versiones estables numeradas. Cinco minutos que ahorran meses.

Ejercicio 1. Clasifica en su capa del ecosistema cada herramienta que necesitaría MercaFresh para estos tres encargos, y nombra la biblioteca concreta que usarías: (a) predecir el churn con datos tabulares de RFM; (b) clasificar automáticamente las fotos que los clientes suben en las reclamaciones ("producto dañado" / "producto correcto"); (c) determinar si el efecto del retraso medio de entrega sobre el churn es estadísticamente significativo.

Ejercicio 2. Un compañero propone reescribir el modelo de churn (actualmente scikit-learn + LightGBM) con un framework de deep learning aparecido hace ocho meses, "porque es el futuro". Escribe una evaluación en tres puntos usando los criterios de elección de esta lección, y una recomendación final.

Ejercicio 3. En tu máquina, crea un entorno virtual nuevo, instala scikit-learn y joblib, y genera su requirements.txt con versiones fijadas. Después, escribe los comandos que ejecutaría un compañero para reproducir tu entorno desde ese fichero.

Solución 1. (a) Capas 1–3: pandas para los datos, scikit-learn para el pipeline y LightGBM (o XGBoost) como modelo. No hace falta subir más: es un problema tabular clásico. (b) Capas 1, 4 y 5: OpenCV para leer y preparar las imágenes, y una CNN con Keras o PyTorch — o mejor, un modelo preentrenado de visión vía Hugging Face, ajustado a las dos clases. (Se desarrolla en el proyecto 09-02.) (c) Capa 2, statsmodels: la pregunta es de inferencia (significatividad de un coeficiente controlando por otras variables), no de predicción. Un p-valor y su intervalo de confianza responden; predict no.

Solución 2. (1) Madurez: ocho meses de vida implica API inestable, bugs por descubrir y riesgo de abandono; el modelo de churn debe vivir años en producción. (2) Comunidad: escasa por definición — sin respuestas acumuladas ni tutoriales, cada problema se resuelve en solitario. (3) Necesidad real: ninguna — el problema es tabular, y en el módulo 7 comprobamos que el boosting es la herramienta adecuada; no hay ninguna carencia que el framework nuevo cubra. Recomendación: mantener scikit-learn + LightGBM; si acaso, probar el framework nuevo en un experimento aislado sin ruta a producción, y reevaluarlo cuando madure.

Solución 3.

El punto clave es que pip freeze escribe ==versión para cada paquete (incluidas las dependencias transitivas, como NumPy), de modo que la reconstrucción es exacta y no "la última versión disponible ese día".

Ya tienes el mapa: una base científica común (NumPy, pandas, SciPy, matplotlib), scikit-learn como columna vertebral del ML clásico con su API fit/predict/transform, statsmodels para inferencia, el trío de boosting para exprimir los datos tabulares, dos grandes ecosistemas de deep learning entre los que elegir sin dramatismo, y las bibliotecas de dominio que esperan en el módulo 9. Y una regla transversal: cada dependencia se declara, se fija y se aísla en su entorno, porque la reproducibilidad no es una virtud académica sino un requisito de despliegue. Con el entorno del modelo de churn de MercaFresh congelado en un requirements.txt, estamos listos para la pregunta central del módulo: cómo sacar ese modelo del notebook y ponerlo a responder peticiones reales. Eso es la próxima lección: serialización, APIs, contenedores — implementación de modelos en producción.