Tenemos el lenguaje (07-01), las librerías base (07-02) y el mapa de herramientas (07-03). Falta lo que convierte todo eso en un taller en el que varias personas puedan trabajar hoy y dentro de un año: el entorno. En los módulos 3 a 6 hemos escrito scripts sueltos, con un fichero novamarket_ml.py del que importábamos funciones, sin decir nunca qué versión de Python o de scikit-learn hacía falta, dónde se guardaba cada cosa ni cómo comprobar que seguía funcionando. Esta lección ordena eso: entornos virtuales y gestión de dependencias (venv, pip, requirements.txt, conda, uv/poetry) y por qué fijar versiones es parte de la reproducibilidad, junto con las semillas; Jupyter con sus virtudes y sus trampas (el estado oculto); Colab y Kaggle como laboratorios con GPU gratuita; los IDE (VS Code, PyCharm); Git aplicado a proyectos de IA (qué se versiona y qué no); una estructura de proyecto recomendada que aplicaremos de verdad: refactorizaremos el código de NovaMarket en un paquete src/novamarket/ con datos.py, entrenar.py y tests con pytest, y lo ejecutaremos; y, para cerrar, cuándo hace falta GPU o nube y qué es Docker. Es importante porque el proyecto que Marta y Diego abordarán en el módulo 8 no cabe en un notebook: necesita esta estructura para sobrevivir al primer cambio de persona, de máquina o de versión.

1. El problema: "en mi máquina funciona"
2. Entornos virtuales con venv y dependencias con pip
3. requirements.txt, conda/mamba, uv y poetry
4. Reproducibilidad: versiones + semillas
5. Jupyter Notebook y JupyterLab: celdas, kernel y estado oculto
6. Google Colab y Kaggle Notebooks
7. IDE: VS Code y PyCharm
8. Git para proyectos de IA: qué versionar y qué no
9. Estructura de proyecto recomendada
10. Código: refactorizar NovaMarket en src/novamarket/ con tests
11. GPU, CPU y nube: cuándo hace falta
12. Docker como entorno reproducible
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Marta entrena el predictor de devoluciones en su portátil, obtiene AUC 0,844 y le pasa el script a un compañero. A él le falla al importar, o le da otro número, o el joblib no carga. Las causas son siempre las mismas: otra versión de Python o de una librería, otro orden de ejecución de las celdas del notebook, otra semilla o ninguna, datos distintos en un fichero con el mismo nombre. El entorno de desarrollo es el conjunto de decisiones que elimina esas causas una a una: aislar dependencias, fijar versiones, fijar semillas, ordenar el código, versionarlo, probarlo y, cuando hace falta, empaquetar la máquina entera.

Un entorno virtual es una carpeta con su propio intérprete de Python (enlazado al del sistema) y su propia colección de paquetes, aislada de las demás. Cada proyecto tiene el suyo, y así el proyecto A puede usar una versión de pandas y el B otra sin pisarse. venv viene con Python:

pip instala paquetes desde PyPI (el índice público de Python) resolviendo dependencias: al pedir scikit-learn trae NumPy, SciPy, joblib y threadpoolctl. La regla de oro: nunca instales librerías en el Python del sistema; siempre en un entorno del proyecto. El entorno del curso es exactamente esto: un venv con NumPy, pandas, scikit-learn, Matplotlib, PyTorch (CPU) y, desde esta lección, pytest.

Para que otra persona (o tú dentro de un año) recree el entorno, se escribe la lista de paquetes con versiones en un fichero:

Convención habitual: un requirements.txt con lo que tú decides (paquetes directos, fijados con == los que importan) y un fichero de bloqueo generado con freeze para reproducir al bit. Alternativas que verás en equipos:

Un environment.yml de conda equivalente, ilustrativo:

conda env create -f environment.yml y conda activate novamarket. Elige una herramienta por proyecto y no las mezcles.

Un resultado es reproducible si otra persona obtiene el mismo número. Hacen falta dos cosas que hemos separado en el curso y que ahora juntamos:

• Semillas: np.random.default_rng(42), random_state=42 en scikit-learn, torch.manual_seed(42), y shuffle con semilla en train_test_split y DataLoader. Sin ellas, los 3.000 pedidos, la partición y la inicialización de la red cambian en cada ejecución. (En GPU, algunas operaciones son no deterministas aunque fijes la semilla; PyTorch documenta cómo forzarlo a cambio de velocidad.)
• Versiones: la misma semilla en otra versión de NumPy o de scikit-learn puede dar otra secuencia u otro resultado numérico, y un joblib guardado con una versión puede no cargar con la siguiente (07-01, 07-03). Por eso el requirements.txt con == y por eso, en la sección 10, el script de entrenamiento guardará junto al modelo un JSON con la versión de Python y de scikit-learn con las que se entrenó.

Reproducible = código versionado + datos identificados + versiones fijadas + semillas fijadas. Los cuatro; con tres, el número cambia.

Jupyter es el entorno interactivo por excelencia de la ciencia de datos: un documento (.ipynb) con celdas de código y de texto (Markdown), que se ejecutan una a una contra un kernel (un proceso Python vivo que guarda las variables). JupyterLab es la interfaz moderna con pestañas, explorador de ficheros y terminal. Se lanza con jupyter lab desde el entorno activado, y abre el navegador. Sus virtudes son evidentes: ves el head() y el gráfico junto al código, iteras rápido, documentas mientras exploras. Sus trampas vienen de lo mismo:

• Estado oculto: las variables viven en el kernel, no en el documento. Si ejecutas la celda 5, luego la 2 y luego editas y ejecutas la 5 otra vez, el notebook que ves no corresponde al estado del kernel. El caso típico: borras la celda que definía pedidos y todo sigue funcionando... hasta que reinicias, y entonces NameError. Otro: cambias test_size en la celda 3 pero no reejecutas la 4, y el AUC que ves es el antiguo.
• Orden de ejecución: los números entre corchetes [7] a la izquierda de cada celda dicen el orden real; si no van de arriba abajo, desconfía.
• Buenas prácticas que evitan casi todos los disgustos: (1) antes de dar por bueno un resultado, "Restart Kernel and Run All" (reiniciar y ejecutar todo de arriba abajo; si falla, el notebook estaba mintiendo); (2) importaciones y parámetros en las primeras celdas; (3) no dejar celdas de prueba desordenadas: bórralas o muévelas a un apéndice; (4) funciones que se repiten, a un módulo .py del proyecto (sección 9) e importarlas, no copiarlas de notebook en notebook; (5) exportar a script cuando el código madura: jupyter nbconvert --to script exploracion.ipynb genera exploracion.py, o mejor, copiar a mano lo que vale al módulo; (6) limpiar salidas antes de subir a Git (los .ipynb con salidas guardan imágenes y tablas y hacen ilegibles las diferencias): jupyter nbconvert --clear-output --inplace, o herramientas como nbstripout.
• Un notebook es para explorar y contar; el código que se ejecuta cada día (entrenar, servir) va en módulos y scripts. Esa frontera es la que trazaremos en la sección 10.

Cuando no tienes GPU, o quieres compartir un notebook sin que nadie instale nada, hay dos laboratorios gratuitos en el navegador:

• Google Colab: notebooks Jupyter alojados por Google, con Python y las librerías habituales preinstaladas, y acceso a GPU (y TPU) gratuita con límites de tiempo de sesión, de horas por día y de memoria que cambian y que en la versión gratuita no se garantizan; versiones de pago amplían el cupo. La sesión es efímera: al cerrarse se pierde lo que haya en disco, así que los datos se suben en cada sesión o se leen de Google Drive.
• Kaggle Notebooks: parecido, integrado con los conjuntos de datos y competiciones de Kaggle, con un cupo semanal de horas de GPU y muchos notebooks públicos de los que aprender.
• Cómo subir un CSV (descripción, no ejecutable aquí): en Colab, el panel lateral de archivos tiene un botón de subida, o desde código from google.colab import files; files.upload() abre un diálogo; para ficheros grandes, montar Drive con drive.mount('/content/drive') y leer con pd.read_csv('/content/drive/MyDrive/pedidos.csv'). En Kaggle, "Add Data" añade un dataset (propio o público) que aparece bajo /kaggle/input/.
• Cautelas: no subas datos personales de clientes reales a un servicio externo sin la evaluación de 02-04; fija versiones porque el entorno preinstalado cambia; y guarda el notebook y los modelos fuera de la sesión (Drive, Git) porque desaparecen.

Un editor con soporte de Python multiplica la productividad frente al notebook para el código de módulos:

• Visual Studio Code con las extensiones Python y Jupyter: autocompletado, navegación al código, formateo, ejecución de notebooks dentro del editor y "celdas" en ficheros .py con # %% (lo mejor de ambos mundos: script versionable que se ejecuta por trozos), depurador con puntos de ruptura (mucho mejor que sembrar print para ver por qué el ColumnTransformer da 22 columnas en vez de 21), terminal integrado, Git integrado, y selección del intérprete del entorno virtual (Python: Select Interpreter → .venv).
• PyCharm: el IDE de JetBrains, más "todo incluido" (la edición Community es gratuita; la Professional añade soporte científico y notebooks). Excelente refactorización y depuración.
• Otros: Spyder (interfaz tipo MATLAB/RStudio, con conda), Positron, o cualquier editor con servidor de lenguaje. La elección es personal; lo que no es opcional es usar el intérprete del entorno del proyecto y tener a mano depurador y tests.

Git guarda la historia del código y permite trabajar a varios sin pisarse; GitHub/GitLab lo alojan. En un proyecto de IA hay una particularidad: los datos y los modelos son grandes, cambian por razones distintas al código y a veces son confidenciales. La regla:

Para datos y modelos se usan DVC (Data Version Control: guarda en Git un fichero pequeño con el hash del dato y el dato en un almacenamiento externo, S3, Drive, un disco de red) o Git LFS (Large File Storage). Solo los mencionamos: para NovaMarket empezaremos con .gitignore y una carpeta compartida, y DVC cuando haga falta.

Flujo mínimo:

De los scripts sueltos de los módulos 3-6 a un proyecto que otra persona entiende en un minuto. Estructura para NovaMarket:

Principios: data/raw/ es intocable (lo que llega se guarda tal cual; todo lo demás se recalcula con código); los notebooks se numeran y cuentan una historia; el código reutilizable vive en el paquete src/novamarket/ (la carpeta src/ evita que Python importe por accidente una copia sin instalar); models/ guarda artefactos con sus métricas al lado; tests/ comprueba lo que no puede romperse; y README.md dice cómo arrancar. Existen plantillas (Cookiecutter Data Science es la más conocida) que generan esto con más carpetas (reports/, configs/, docs/); empieza pequeño y añade cuando lo necesites.

Vamos a montarlo de verdad. Creamos la estructura, movemos las funciones de novamarket_ml.py (módulos 4-5) a src/novamarket/datos.py, escribimos entrenar.py como script ejecutable, un test mínimo con pytest y lo ejecutamos todo.

1. Crear la estructura (en una terminal, con el entorno activado):

2. src/novamarket/__init__.py (convierte la carpeta en paquete):

3. src/novamarket/datos.py: las funciones que ya conoces, sin cambios, con una cabecera. Reproducimos la primera completa; ensuciar_pedidos, preparar_pedidos y crear_preparacion (con sus listas NUMERICAS, BINARIAS, NOMINALES, ORDINALES) se copian tal cual de 04-03:

4. src/novamarket/entrenar.py: funciones importables y script ejecutable, separados por if __name__ == "__main__":. Junto al modelo guarda un JSON con métrica, parámetros y versiones (sección 4):

if __name__ == "__main__": es la línea que hace posible las dos cosas: cuando ejecutas el fichero, __name__ vale "__main__" y corre el bloque; cuando otro módulo (o un test) hace from novamarket.entrenar import entrenar, __name__ vale "novamarket.entrenar" y el bloque no se ejecuta. argparse convierte --n 3000 en args.n, con valores por defecto y --help gratis.

5. pyproject.toml: el fichero estándar de metadatos del proyecto; aquí también le dice a pytest dónde está el código:

pip install -e . (instalación editable) registra el paquete en el entorno apuntando a src/, de modo que import novamarket funciona desde cualquier carpeta y los cambios en el código se ven sin reinstalar. Alternativa sin instalar: PYTHONPATH=src python -m novamarket.entrenar.

6. tests/test_datos.py y tests/test_entrenar.py: pytest descubre funciones test_* y comprueba asserts. Probamos lo que no puede romperse: reproducibilidad, forma, las 21 columnas, ausencia de NaN, un AUC mínimo y que el guardado escribe los dos ficheros:

7. requirements.txt, .gitignore y README.md como en las secciones 3, 8 y 9 (el .gitignore ignora .venv/, __pycache__/, .ipynb_checkpoints/, data/raw/* y data/processed/* salvo los .gitkeep, models/*.joblib, models/*.pt y .env).

8. Ejecutar. Tests, entrenamiento y comprobación de Git, con las salidas reales:

Cuatro tests en menos de un segundo, el mismo AUC 0,844 de 04-04 obtenido con un comando desde la terminal, un JSON que dice con qué versiones se entrenó, y un repositorio en el que el modelo binario no entra pero sus métricas sí. Este es el punto de partida del módulo 8: cuando en 08-01 añadamos predecir.py (que carga models/modelo_devoluciones.joblib como en 07-03) o cambiemos el modelo, los tests dirán en un segundo si algo se ha roto.

Todo el curso ha corrido en CPU, y esa es la respuesta para la mayor parte de lo que hace NovaMarket: tablas de miles o cientos de miles de filas con scikit-learn, el MLP de 497 parámetros, las reglas, la optimización. La GPU hace falta cuando el cálculo son grandes multiplicaciones de matrices repetidas: entrenar CNN sobre imágenes reales, afinar un transformer, ejecutar LLM locales; ahí acelera de 10 a 100 veces. Comprobar y usarla en PyTorch:

(En Mac con Apple Silicon el equivalente es torch.backends.mps.is_available() y "mps".) Opciones, de menor a mayor coste: la CPU del portátil; Colab/Kaggle para probar con GPU gratis (sección 6); una máquina virtual con GPU en la nube (AWS, Azure, Google Cloud y proveedores especializados) que se paga por hora y se apaga al terminar; servicios gestionados de ML de esos proveedores; o una GPU propia si el uso es continuo. La pregunta de Diego ("¿hace falta?") se responde midiendo: si el entrenamiento en CPU tarda minutos, no; si tarda días, sí, y aun así conviene primero reducir datos o modelo para iterar rápido y usar la GPU solo para la ejecución final.

El último escalón de la reproducibilidad es empaquetar la máquina entera: sistema operativo, Python, librerías con versión, código y comando de arranque, en una imagen que corre igual en el portátil de Marta, en el servidor de NovaMarket y en la nube. Eso es Docker (o Podman). Un Dockerfile ilustrativo para servir el predictor con la API de 07-03:

docker build -t novamarket-devoluciones . construye la imagen y docker run -p 8000:8000 novamarket-devoluciones la arranca; la web de NovaMarket llama a http://servidor:8000/riesgo-devolucion. Docker no sustituye a venv en el día a día del desarrollo (es más pesado), pero es la forma estándar de entregar un servicio y de garantizar que "en mi máquina funciona" signifique "en todas". Kubernetes (07-01) orquesta muchos contenedores; fuera del alcance del curso.

• Instalar todo en el Python del sistema. Tarde o temprano dos proyectos piden versiones incompatibles y algo del sistema deja de funcionar. Un entorno por proyecto, siempre.
• requirements.txt sin versiones, o sin requirements.txt. Seis meses después, pip install trae versiones nuevas y el joblib no carga o el número cambia. Fija con == lo que importa y guarda un freeze.
• Notebooks que solo funcionan en el orden en que se ejecutaron. "Restart Kernel and Run All" antes de dar nada por bueno; funciones a módulos; salidas limpias antes de subir a Git.
• Datos y modelos en Git. El repositorio engorda hasta ser inutilizable y puedes publicar datos personales. .gitignore desde el primer commit; DVC o almacenamiento externo para lo grande.
• Semillas sin versiones o versiones sin semillas. Las dos, y anotadas junto al modelo (el JSON de la sección 10).
• Tests que prueban lo trivial y no lo frágil. Prueba la forma de la matriz, la ausencia de NaN, la reproducibilidad, un umbral de métrica; son los fallos que de verdad ocurren al tocar preparar_pedidos.
• Comprar GPU antes de medir. Cronometra en CPU, reduce el problema, prueba en Colab; después decide.
• Rutas absolutas en el código (/home/marta/pedidos.csv). Rutas relativas a la raíz del proyecto o configurables por argumento; pathlib.Path en vez de concatenar cadenas.

Ejercicio 1. Añade al proyecto un módulo src/novamarket/predecir.py con una función cargar(ruta="models/modelo_devoluciones.joblib") y otra predecir_riesgo(modelo, pedido: dict) -> float que construya un DataFrame de una fila y devuelva la probabilidad de devolución, más un bloque if __name__ == "__main__": que prediga para un pedido de ejemplo. Escribe un test que entrene con entrenar(n=1500), guarde en tmp_path, cargue con cargar y compruebe que predecir_riesgo devuelve un número entre 0 y 1 e igual a pipe.predict_proba sobre el mismo pedido.

Ejercicio 2. Simula el problema del estado oculto: en un notebook (o mentalmente, describiendo las celdas), define en la celda 1 umbral = 0.5, en la celda 2 una función que use umbral, ejecuta la celda 3 que la llama; después cambia la celda 1 a umbral = 0.3 sin reejecutarla y vuelve a ejecutar la 3. ¿Qué umbral se aplica? ¿Qué muestra el notebook? ¿Qué pasa al hacer "Restart and Run All"? Propón dos cambios en la organización del notebook que eviten el problema.

Ejercicio 3. Escribe el .gitignore, el requirements.txt (con las versiones que uses) y un Dockerfile ilustrativo para un proyecto que sirva la red bayesiana de diagnóstico de incidencias de 06-03 como API. Justifica qué entra en Git y qué no, y por qué en este caso el "modelo" (las tablas de probabilidad condicional) probablemente sí debería versionarse en Git, a diferencia de modelo_devoluciones.joblib.

Solución 1.

Ejecutado en el entorno del curso: pytest pasa 5 tests, y python -m novamarket.predecir imprime riesgo de devolución: 0.048 (el mismo pedido de 07-03). Con esto el proyecto tiene las tres piezas del ciclo (datos, entrenar, predecir) probadas.

Solución 2. Se aplica 0,5: la celda 1 se editó pero no se ejecutó, así que la variable umbral del kernel sigue valiendo 0,5; el notebook muestra umbral = 0.3 en la celda 1 y un resultado calculado con 0,5, es decir, miente. Al hacer "Restart and Run All" el kernel se vacía, se ejecuta la celda 1 con 0,3 y el resultado cambia; si alguien hubiera copiado el resultado anterior a un informe, sería irreproducible. Dos cambios: (1) parámetros y funciones al principio, y la regla de reejecutar desde arriba tras cualquier cambio de parámetro (o directamente "Run All Above" antes de la celda de resultados); (2) sacar la función a src/novamarket/ con umbral como argumento explícito (decidir(prob, umbral=0.5)) y llamarla con el valor visible en la celda, de modo que no haya variable global de la que depender.

Solución 3. .gitignore: .venv/, __pycache__/, .ipynb_checkpoints/, .env, y data/raw/* (los históricos de incidencias reales, confidenciales); no se ignora src/novamarket/red_incidencias.py ni un configs/cpt_incidencias.json con las tablas de probabilidad. requirements.txt: numpy==..., pandas==..., fastapi, uvicorn, pytest (y pgmpy==... si se sustituye la enumeración de 06-03 por pgmpy, 07-03). Dockerfile: igual que el de la sección 12, copiando src/, configs/ y servir_incidencias.py, con CMD ["uvicorn", "servir_incidencias:app", ...]. Por qué el "modelo" sí va en Git: las tablas de probabilidad condicional de la red de 06-03 son pocas decenas de números escritos o revisados por personas (conocimiento explícito, como las reglas de 06-02), pequeñas, legibles como texto y con valor de auditoría (¿quién cambió la probabilidad de "defecto de fábrica" y cuándo?): exactamente lo que Git hace bien. modelo_devoluciones.joblib es un binario generado por código a partir de datos: se regenera con entrenar.py, no se lee ni se revisa línea a línea, y su lugar es un almacén de artefactos con el JSON de métricas y versiones en Git.

Con esta lección el taller de Marta queda montado. Hemos visto por qué "en mi máquina funciona" es el enemigo y cómo se combate: entornos virtuales (venv) con un intérprete y unos paquetes por proyecto; dependencias fijadas en requirements.txt (o environment.yml, uv, poetry) y la ecuación de la reproducibilidad, versiones + semillas + código + datos identificados; Jupyter para explorar y contar, con la disciplina de reiniciar y ejecutar todo y de mover el código maduro a módulos; Colab y Kaggle como laboratorios con GPU gratuita y sesiones efímeras; VS Code y PyCharm con depurador y el intérprete del entorno; Git con la frontera clara entre lo que se versiona (código, dependencias, métricas pequeñas) y lo que no (datos, modelos grandes, secretos), y DVC en el horizonte; una estructura de proyecto (data/, notebooks/, src/novamarket/, models/, tests/) que hemos construido de verdad, con datos.py, entrenar.py ejecutable desde la terminal (AUC 0,844 y un JSON con versiones), un pyproject.toml y cuatro tests de pytest que pasan en un segundo; y las decisiones de infraestructura: CPU salvo prueba de lo contrario, GPU y nube cuando el cálculo lo pida, Docker para entregar el servicio igual en todas partes.

Y con esto cerramos el módulo 7. Empezamos en 07-01 eligiendo Python y SQL entre los lenguajes de la IA; en 07-02 aprendimos a manejar de verdad NumPy, pandas y Matplotlib con los pedidos y la demanda de NovaMarket; en 07-03 situamos cada librería en su tarea y guardamos y recargamos el predictor de devoluciones y el MLP; y en 07-04 lo hemos ordenado todo en un proyecto reproducible con entorno, estructura, Git y tests. Marta tiene el lenguaje, las herramientas y el taller; Diego tiene un entrenar.py que cualquiera puede ejecutar y un repositorio que no engorda con datos. Lo que no tienen todavía es un método para llevar un caso de uso de la idea a producción: definir el problema de negocio, decidir la métrica, montar los datos, iterar sobre el modelo, validarlo, desplegarlo y vigilarlo, aprendiendo de los proyectos que han salido bien y de los que no. Es el módulo 8, Proyectos y Casos de Estudio, que empieza en 08-01, Desarrollo de un Proyecto de IA, con Marta y Diego abordando de principio a fin, dentro de la estructura novamarket_ia/ que acabamos de crear, el proyecto del predictor de devoluciones.