Ya dominas los dos grandes frameworks y sabes cuándo usar cada uno. Pero hay una verdad incómoda que el equipo de TecnoMarket descubrió al revisar su trabajo de los últimos módulos: casi todo vive en pestañas de Colab sueltas, con celdas ejecutadas en desorden, resultados que nadie sabe reproducir y modelos guardados con nombres como modelo_final_v2_BUENO.keras. En 01-05 montaste el entorno básico; esta lección lo profesionaliza: entenderás las opciones reales de hardware y plataforma (Colab y sus límites, alternativas, GPU local), cómo pasar del notebook a un proyecto reproducible con scripts y semillas, cómo aplicar control de versiones a un proyecto de ML (y qué NO subir a git), cómo monitorizar entrenamientos con TensorBoard, y dónde seguir aprendiendo cuando acabe el curso.

1. Colab a fondo: lo que da y lo que limita
2. Alternativas: Kaggle Notebooks y otras plataformas
3. Trabajar en local con GPU: CUDA y cuDNN
4. Del notebook al proyecto: estructura y scripts
5. Reproducibilidad: semillas y configuración
6. Control de versiones para ML
7. Monitorizar entrenamientos con TensorBoard
8. Dónde seguir aprendiendo
9. El entorno de trabajo de TecnoMarket

Google Colab, tu compañero desde 01-05, es un servicio de notebooks con GPU gratuita. Conviene conocer sus reglas de juego:

Las dos limitaciones que más duelen en la práctica:

• El disco es efímero. Todo lo que no guardes fuera (Google Drive, descarga manual) desaparece al terminar la sesión. Por eso el ModelCheckpoint de 06-01 apuntando a Drive es un salvavidas: si Colab desconecta en la época 40 de 50, el mejor modelo está a salvo.
• Las sesiones se cortan. Entrenamientos de muchas horas no son viables de forma fiable en el plan gratuito. Regla práctica: Colab gratuito para aprender y prototipar (todo este curso cabe ahí); Pro para proyectos personales serios; hardware propio o nube para trabajo profesional sostenido.

• Kaggle Notebooks: la alternativa gratuita más directa a Colab. Ofrece GPU con una cuota semanal de horas, y dos ventajas propias: los datasets de la plataforma se montan con un clic (sin descargas), y los notebooks públicos de las competiciones son una mina de técnicas reales aplicadas — leer soluciones ganadoras es de lo más formativo que existe.
• Papers with Code: no es un entorno de ejecución sino un índice que conecta cada paper con su implementación y sus benchmarks. Cuando en 03-03 hablamos de ResNet o en 05-05 de transformers, ahí es donde encontrarías el código de referencia de cada arquitectura y el estado del arte de cada tarea.
• Nube de pago por uso (los proveedores grandes y plataformas especializadas en GPUs): alquilas una máquina con GPU por horas. Es el paso natural cuando un entrenamiento serio ya no cabe en Colab pero no justifica comprar hardware. Menciónalo tu radar; no lo necesitas para este curso.

Si tienes (o valoras comprar) un PC con GPU NVIDIA, puedes entrenar en local sin límites de sesión. Entiende las capas conceptualmente, porque los errores de instalación casi siempre son un desajuste entre ellas:

• CUDA es la plataforma de NVIDIA para ejecutar cálculo general en la GPU.
• cuDNN es una librería sobre CUDA con las operaciones de deep learning (convoluciones de 03-02, LSTM de 04-02) ultra-optimizadas. Ambos frameworks la usan por debajo: por eso su rendimiento empata (06-03).
• La compatibilidad de versiones (driver ↔ CUDA ↔ cuDNN ↔ framework) es la fuente clásica de dolores de cabeza. Buena noticia: las versiones actuales de PyTorch (y TensorFlow vía pip) empaquetan las librerías CUDA necesarias; normalmente basta un driver NVIDIA razonablemente actualizado y el comando de instalación que indica la web oficial de cada framework.
• Sin GPU NVIDIA no hay CUDA: en Mac con Apple Silicon los frameworks usan la GPU integrada por otra vía (Metal/MPS), y en cualquier máquina la CPU siempre funciona, solo que más lenta (para las redes densas de este curso, perfectamente viable).

Verificación en ambos frameworks (tu primer paso siempre que estrenes entorno):

Los notebooks son perfectos para explorar, pero terribles como producto final: celdas ejecutables en cualquier orden, estado oculto en memoria, difícil de versionar y de automatizar. La transición profesional es mover el código estable a scripts dentro de una estructura de proyecto. La carpeta tecnomarket-dl/ que creaste en 01-05 crece así:

El flujo de trabajo recomendado, que es el que adopta TecnoMarket:

1. Explorar en notebook (notebooks/): probar ideas, visualizar datos, iterar rápido.
2. Consolidar en src/: cuando algo funciona, se convierte en funciones dentro de módulos.
3. Entrenar por script: python src/entrenar.py produce siempre el mismo proceso de principio a fin, ejecutable por cualquiera del equipo (o por una máquina, cada noche).

Un entrenar.py mínimo con configuración externa:

¿Por qué separar la configuración? Porque cada experimento queda descrito por un fichero: cambiar el dropout ya no es editar código, es editar un valor; y comparar dos experimentos es comparar dos configs. Este es el precursor artesanal de las herramientas de tracking que veremos enseguida.

Dos entrenamientos "idénticos" dan resultados distintos: inicialización aleatoria de pesos (02-01), barajado de lotes, dropout (05-04)... Para poder comparar experimentos de verdad, fija las semillas aleatorias al principio del script:

Matices honestos:

• Con semillas fijas, dos ejecuciones en la misma máquina y versiones serán (casi siempre) idénticas.
• Algunas operaciones de GPU son no deterministas por diseño (por rendimiento); el determinismo total exige opciones extra y coste en velocidad. Para el día a día, fijar semillas basta: convierte "resultados que bailan" en "resultados comparables".
• La reproducibilidad completa es semillas + versiones de librerías (tu requirements.txt de 01-05, idealmente con versiones fijadas: tensorflow==2.16.1) + configuración (el config.yaml) + los mismos datos.

Git te permite guardar el historial del proyecto, volver a cualquier punto y colaborar sin pisaros. El ciclo básico aplicado a tecnomarket-dl/:

Git está pensado para texto (código, configs). Los ficheros grandes y binarios lo degradan:

El fichero .gitignore en la raíz del proyecto lo automatiza:

La regla mental: en git va lo que permite REGENERAR los resultados (código, config, requirements), no los resultados en sí.

Dos nombres para tu radar (no los necesitas aún, pero te los cruzarás):

• DVC (Data Version Control): extiende la idea de git a datos y modelos — git guarda un puntero ligero, el fichero pesado vive en un almacenamiento externo, y cada commit sabe qué versión de los datos usó.
• MLflow: tracking de experimentos — registra automáticamente parámetros, métricas y artefactos de cada entrenamiento y los muestra en una tabla comparable. Es la versión industrial de tu config.yaml + hoja de cálculo de resultados.

En 06-01 añadiste el callback de TensorBoard; ahora vamos a usarlo de verdad. TensorBoard lee los logs escritos durante el entrenamiento y los convierte en gráficas interactivas: curvas de pérdida y precisión, comparación entre ejecuciones, histogramas de pesos.

Para verlo:

Cómo leer lo que verás (conectando con lo aprendido):

• Pestaña Scalars: curvas de loss/val_loss y métricas por época. La divergencia entre entrenamiento y validación es el sobreajuste que aprendiste a combatir en 05-04 — aquí lo ves dibujarse en directo, sin esperar al final.
• Comparar ejecuciones: cada subdirectorio de logs/ aparece como una curva de color distinto. Entrena con dropout 0.2 y 0.4 (dos configs, dos ejecuciones) y compáralas superpuestas: esto convierte el ajuste de hiperparámetros en una decisión visual.
• PyTorch también juega: con torch.utils.tensorboard.SummaryWriter escribes los mismos logs desde tu bucle explícito de 06-02 (writer.add_scalar("loss/train", loss.item(), paso)). Una única herramienta de monitorización para los dos frameworks del equipo.

Recursos estables, sin URLs que caduquen — todos se encuentran buscando su nombre:

• Documentación oficial de TensorFlow/Keras y de PyTorch: ambas incluyen tutoriales guiados excelentes y son la referencia final ante cualquier duda de API. Los tutoriales oficiales de PyTorch ("60 Minute Blitz") complementan perfectamente la lección 06-02.
• Cursos y libros clásicos: los cursos de deep learning de las grandes plataformas educativas (los de Andrew Ng son el estándar histórico); Deep Learning de Goodfellow, Bengio y Courville (la teoría de referencia, gratuito online); Hands-On Machine Learning de Géron (práctico, con Keras); el curso y libro de fast.ai (enfoque "primero el código", sobre PyTorch).
• Papers: arXiv (preprints de la investigación en curso) y Papers with Code (paper + implementación + benchmark). Empieza por los clásicos que ya conoces de nombre por el curso: ResNet (03-03), Attention Is All You Need (05-05).
• Comunidades: Kaggle (competiciones y notebooks públicos), Stack Overflow (errores concretos), los foros oficiales de cada framework y Hugging Face (modelos y ejemplos).
• Práctica deliberada: la mejor receta post-curso es elegir un dataset público que te interese, replicar la metodología del curso (prototipo → aplicación) y documentarlo en un repositorio git propio. Un proyecto terminado enseña más que diez tutoriales — y es exactamente lo que haremos juntos en el módulo 7.

Así queda organizado el equipo de datos tras esta lección:

1. Exploración: Colab (gratuito para pruebas cortas; Pro para los entrenamientos largos del módulo 7), siempre con Drive montado y ModelCheckpoint apuntando a él.
2. Proyecto: repositorio git tecnomarket-dl con la estructura src/ + config.yaml + requirements.txt con versiones fijadas; data/, models/ y logs/ en .gitignore.
3. Regla de consolidación: nada pasa de notebooks/ a src/ sin semillas fijadas y sin poder ejecutarse con python src/entrenar.py de principio a fin.
4. Monitorización: TensorBoard con un subdirectorio por experimento; los dos frameworks escriben al mismo logs/.
5. Pendiente para cuando crezcan: DVC para versionar el dataset de reseñas y MLflow para el tracking, anotados en el README como siguiente paso.

• Entrenar horas en Colab sin checkpoints en Drive: la desconexión llegará, y con el disco efímero se lleva tu modelo. ModelCheckpoint + Drive montado, siempre.
• Notebooks con celdas ejecutadas en desorden: el estado oculto hace que "funcione en mi notebook" y falle al reejecutar. Antes de dar algo por bueno: Restart & Run All. Si no sobrevive a eso, no está terminado.
• Commitear datos, pesos o (peor) credenciales: además de hinchar el repo, una clave subida a git queda en el historial aunque la borres después. Escribe el .gitignore antes del primer commit.
• Comparar experimentos sin fijar semillas: la mejora del 0,4 % de tu nuevo dropout puede ser puro azar de inicialización. Semillas fijas primero; conclusiones después.
• Instalar CUDA a mano sin necesitarlo: prueba primero el comando de instalación oficial del framework — hoy suele traer todo incluido. Solo si torch.cuda.is_available() da False con GPU presente toca investigar drivers.
• Consejo: pon fecha y nombre descriptivo a cada directorio de logs y a cada config (resenas_dropout03_20260824). Tu yo de dentro de tres semanas no recuerda qué era prueba2_final.

El repositorio de un compañero de TecnoMarket contiene: src/entrenar.py, config.yaml, data/resenas_clientes.csv (400 MB, con emails reales), models/resenas_v3.keras (85 MB), logs/ (2 GB), requirements.txt, claves_api.txt y notebooks/exploracion.ipynb. Indica qué debe versionarse en git, qué no y por qué; escribe el .gitignore resultante y señala el fichero que representa un problema más allá del tamaño.

Un compañero ejecuta dos veces el mismo notebook de la red MNIST y obtiene 97,68 % y 97,41 %, y concluye que "la segunda vez el modelo salió peor". Explica por qué la conclusión es errónea, qué cuatro elementos debería fijar/registrar para que los experimentos sean comparables, y escribe el bloque de código de semillas para un script que usa TensorFlow y numpy.

Escribe el esquema de código (Keras) para entrenar el clasificador de reseñas dos veces —dropout 0.2 y dropout 0.5— de forma que ambas ejecuciones aparezcan como curvas separadas y comparables en TensorBoard, y explica qué mirarías en las curvas para decidir cuál de los dos valores es mejor.

Solución 1:

• Sí a git: src/entrenar.py, config.yaml, requirements.txt, notebooks/exploracion.ipynb (texto, permite regenerar el trabajo).
• No a git: data/ (grande y con datos personales de clientes — además del tamaño, subirlo podría vulnerar la protección de datos), models/ (binario regenerable), logs/ (regenerable y enorme), claves_api.txt.
• El problema grave: claves_api.txt. No es cuestión de tamaño: una credencial commiteada queda en el historial de git para siempre (borrarla del directorio no la borra de los commits antiguos) y debe considerarse comprometida — hay que revocarla y regenerarla, y pasar las claves a variables de entorno.

Solución 2: La diferencia 97,68 % vs. 97,41 % entra en la variación normal por aleatoriedad: inicialización de pesos distinta, barajado de lotes distinto, dropout apagando neuronas distintas. No hay "modelo peor": hay dos muestras de la misma distribución de resultados. Para comparar de verdad: (1) semillas fijadas, (2) versiones de librerías fijadas en requirements.txt, (3) configuración registrada (config.yaml), (4) mismos datos y misma partición train/test. Y ejecutar como script de arriba abajo, no celdas en desorden.

Solución 3:

Al lanzar tensorboard --logdir logs, cada dropout es una curva. Qué mirar: la val_loss (no la de entrenamiento) — gana el dropout con menor pérdida de validación estable; y la separación entre curva de entrenamiento y validación de cada experimento — si con 0.2 la brecha crece época a época (sobreajuste, como en 05-04) y con 0.5 se mantiene junta con val_loss similar o mejor, 0.5 es la elección.

El equipo de TecnoMarket ya no trabaja en pestañas sueltas: sabe qué esperar de Colab y cuándo saltar a Kaggle, GPU local o nube; entiende las capas CUDA/cuDNN lo justo para diagnosticar; ha convertido su trabajo en un proyecto con src/, configs y semillas que cualquiera puede reproducir; versiona con git lo que regenera resultados (y solo eso, con .gitignore protegiendo datos, pesos y credenciales); monitoriza cada experimento en TensorBoard; y tiene un mapa de recursos para seguir creciendo. En una palabra: profesionalización.

Queda la última pieza del módulo de herramientas, y es la que conecta todo con el mundo real: un modelo que vive en models/ no le sirve a ningún cliente de TecnoMarket. En la próxima lección aprenderás a guardar modelos correctamente en ambos frameworks, a empaquetarlos junto a su preprocesado y a desplegarlos: desde un script batch hasta una API REST que responde peticiones en vivo.