El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Ja domines els dos grans frameworks i saps quan fer servir cadascun. Però hi ha una veritat incòmoda que l'equip de TecnoMarket va descobrir en revisar la seva feina dels darrers mòduls: gairebé tot viu en pestanyes de Colab soltes, amb cel·les executades en desordre, resultats que ningú no sap reproduir i models desats amb noms com model_final_v2_BO.keras. A 01-05 vas muntar l'entorn bàsic; aquesta lliçó el professionalitza: entendràs les opcions reals de maquinari i plataforma (Colab i els seus límits, alternatives, GPU local), com passar del notebook a un projecte reproduïble amb scripts i llavors, com aplicar control de versions a un projecte de ML (i què NO pujar a git), com monitorar entrenaments amb TensorBoard, i on continuar aprenent quan s'acabi el curs.

Contingut

Colab a fons: què dona i què limita
Alternatives: Kaggle Notebooks i altres plataformes
Treballar en local amb GPU: CUDA i cuDNN
Del notebook al projecte: estructura i scripts
Reproduïbilitat: llavors i configuració
Control de versions per a ML
Monitorar entrenaments amb TensorBoard
On continuar aprenent
L'entorn de treball de TecnoMarket

Colab a fons: què dona i què limita

Google Colab, el teu company des de 01-05, és un servei de notebooks amb GPU gratuïta. Convé conèixer les seves regles del joc:

Aspecte	Colab gratuït	Colab Pro / Pro+ (de pagament)
GPU	Sí, segons disponibilitat (sovint T4)	Prioritat i GPUs millors (segons el pla)
Durada de la sessió	Limitada (hores); es desconnecta per inactivitat	Sessions més llargues
RAM / disc	Limitats	Ampliats
Persistència	Cap: el disc s'esborra en tancar	Igual: el disc continua sent efímer
Cost	0 €	Subscripció mensual

Les dues limitacions que més fan mal a la pràctica:

El disc és efímer. Tot el que no desis fora (Google Drive, descàrrega manual) desapareix en acabar la sessió. Per això el ModelCheckpoint de 06-01 apuntant a Drive és un salvavides: si Colab desconnecta a l'època 40 de 50, el millor model és fora de perill.
Les sessions es tallen. Entrenaments de moltes hores no són viables de manera fiable en el pla gratuït. Regla pràctica: Colab gratuït per aprendre i prototipar (tot aquest curs hi cap); Pro per a projectes personals seriosos; maquinari propi o núvol per a feina professional sostinguda.

# Patró imprescindible a Colab: muntar Drive per persistir models i logs
from google.colab import drive
drive.mount("/content/drive")

RUTA_PROJECTE = "/content/drive/MyDrive/tecnomarket-dl"
# A partir d'aquí, checkpoints i logs es desen a RUTA_PROJECTE/models, /logs...

Alternatives: Kaggle Notebooks i altres plataformes

Kaggle Notebooks: l'alternativa gratuïta més directa a Colab. Ofereix GPU amb una quota setmanal d'hores, i dos avantatges propis: els datasets de la plataforma es munten amb un clic (sense descàrregues), i els notebooks públics de les competicions són una mina de tècniques reals aplicades — llegir solucions guanyadores és de les coses més formatives que hi ha.
Papers with Code: no és un entorn d'execució sinó un índex que connecta cada paper amb la seva implementació i els seus benchmarks. Quan a 03-03 parlàvem de ResNet o a 05-05 de transformers, allà és on trobaries el codi de referència de cada arquitectura i l'estat de l'art de cada tasca.
Núvol de pagament per ús (els proveïdors grans i plataformes especialitzades en GPUs): llogues una màquina amb GPU per hores. És el pas natural quan un entrenament seriós ja no cap a Colab però no justifica comprar maquinari. Tingues-ho al radar; no ho necessites per a aquest curs.

Treballar en local amb GPU: CUDA i cuDNN

Si tens (o valores comprar) un PC amb GPU NVIDIA, pots entrenar en local sense límits de sessió. Entén les capes conceptualment, perquè els errors d'instal·lació gairebé sempre són un desajust entre elles:

graph TB
    A["El teu codi (Keras / PyTorch)"] --> B["Framework (TensorFlow / torch)"]
    B --> C["cuDNN: primitives de deep learning optimitzades<br/>(convolucions, LSTM...)"]
    C --> D["CUDA: plataforma de computació general en GPU"]
    D --> E["Driver NVIDIA"]
    E --> F["GPU física"]

CUDA és la plataforma de NVIDIA per executar càlcul general a la GPU.
cuDNN és una llibreria sobre CUDA amb les operacions de deep learning (convolucions de 03-02, LSTM de 04-02) ultraoptimitzades. Tots dos frameworks la fan servir per sota: per això el seu rendiment empata (06-03).
La compatibilitat de versions (driver ↔ CUDA ↔ cuDNN ↔ framework) és la font clàssica de maldecaps. Bona notícia: les versions actuals de PyTorch (i TensorFlow via pip) empaqueten les llibreries CUDA necessàries; normalment n'hi ha prou amb un driver NVIDIA raonablement actualitzat i l'ordre d'instal·lació que indica el web oficial de cada framework.
Sense GPU NVIDIA no hi ha CUDA: en un Mac amb Apple Silicon els frameworks fan servir la GPU integrada per una altra via (Metal/MPS), i en qualsevol màquina la CPU sempre funciona, només que més lenta (per a les xarxes denses d'aquest curs, perfectament viable).

Verificació en tots dos frameworks (el teu primer pas sempre que estrenis entorn):

import tensorflow as tf
print(tf.config.list_physical_devices("GPU"))   # [] si no hi ha GPU visible

import torch
print(torch.cuda.is_available())                # True / False
print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else "CPU")

Del notebook al projecte: estructura i scripts

Els notebooks són perfectes per explorar, però terribles com a producte final: cel·les executables en qualsevol ordre, estat ocult en memòria, difícils de versionar i d'automatitzar. La transició professional és moure el codi estable a scripts dins d'una estructura de projecte. La carpeta tecnomarket-dl/ que vas crear a 01-05 creix així:

tecnomarket-dl/
├── dades/              # dades brutes i processades (NO es puja a git)
├── models/             # pesos entrenats (NO es puja a git; ja la fas servir des de 02-05)
├── logs/               # registres de TensorBoard
├── notebooks/          # exploració: els .ipynb viuen aquí, i només exploració
├── src/                # codi font estable
│   ├── dades.py        # càrrega i preprocessament (el pipeline tf.data de 06-01)
│   ├── model.py        # definició de l'arquitectura
│   └── entrenar.py     # script d'entrenament
├── config.yaml         # hiperparàmetres i rutes
├── requirements.txt    # dependències (el vas crear a 01-05)
└── README.md           # què és això i com s'executa

El flux de treball recomanat, que és el que adopta TecnoMarket:

Explorar en notebook (notebooks/): provar idees, visualitzar dades, iterar ràpid.
Consolidar a src/: quan una cosa funciona, es converteix en funcions dins de mòduls.
Entrenar per script: python src/entrenar.py produeix sempre el mateix procés de principi a fi, executable per qualsevol de l'equip (o per una màquina, cada nit).

Un entrenar.py mínim amb configuració externa:

# src/entrenar.py
import yaml
from dades import carregar_datasets      # els teus mòduls de src/
from model import crear_model

with open("config.yaml") as f:           # els hiperparàmetres NO van hardcodejats
    cfg = yaml.safe_load(f)

train_ds, val_ds = carregar_datasets(cfg["ruta_dades"], cfg["batch_size"])
model = crear_model(cfg["capes"], cfg["dropout"])
model.fit(train_ds, validation_data=val_ds, epochs=cfg["epochs"])
model.save(f"models/{cfg['nom_experiment']}.keras")

# config.yaml
nom_experiment: ressenyes_v3
ruta_dades: dades/ressenyes.csv
batch_size: 32
epochs: 20
capes: [64, 32]
dropout: 0.3

Per què separar la configuració? Perquè cada experiment queda descrit per un fitxer: canviar el dropout ja no és editar codi, és editar un valor; i comparar dos experiments és comparar dues configs. Aquest és el precursor artesanal de les eines de tracking que veurem de seguida.

Reproduïbilitat: llavors i configuració

Dos entrenaments "idèntics" donen resultats diferents: inicialització aleatòria dels pesos (02-01), remenat dels lots, dropout (05-04)... Per poder comparar experiments de debò, fixa les llavors aleatòries al principi de l'script:

import random, numpy as np

SEED = 42
random.seed(SEED)
np.random.seed(SEED)

import tensorflow as tf
tf.random.set_seed(SEED)        # TensorFlow/Keras

import torch
torch.manual_seed(SEED)         # PyTorch (CPU i GPU)

Matisos honestos:

Amb llavors fixes, dues execucions a la mateixa màquina i versions seran (gairebé sempre) idèntiques.
Algunes operacions de GPU són no deterministes per disseny (per rendiment); el determinisme total exigeix opcions extra i un cost en velocitat. Per al dia a dia, fixar llavors n'hi ha prou: converteix "resultats que ballen" en "resultats comparables".
La reproduïbilitat completa és llavors + versions de llibreries (el teu requirements.txt de 01-05, idealment amb versions fixades: tensorflow==2.16.1) + configuració (el config.yaml) + les mateixes dades.

Control de versions per a ML

Git et permet desar l'historial del projecte, tornar a qualsevol punt i col·laborar sense trepitjar-vos. El cicle bàsic aplicat a tecnomarket-dl/:

cd tecnomarket-dl
git init                                   # un cop: convertir la carpeta en repositori
git add src/ config.yaml requirements.txt README.md
git commit -m "Estructura de projecte i entrenament de ressenyes_v3"

# ...dies després, després de canviar el model...
git add src/model.py config.yaml
git commit -m "Afegeix dropout 0.3 al classificador de ressenyes"
git log --oneline                          # historial de canvis

Què NO es commiteja

Git està pensat per a text (codi, configs). Els fitxers grans i binaris el degraden:

No pujar	Per què	On va llavors
`dades/` (datasets)	Grans, de vegades amb dades personals de clients	Emmagatzematge propi + script/instruccions de descàrrega
`models/` (pesos `.keras`, `.pt`)	Binaris de MB/GB que canvien a cada entrenament	Emmagatzematge d'artefactes; a git només el com reproduir-los
`logs/` de TensorBoard	Regenerables, voluminosos	Es queden en local o a la seva eina
Credencials i claus d'API	Risc de seguretat greu i permanent (l'historial no oblida)	Variables d'entorn, fora del repo

El fitxer .gitignore a l'arrel del projecte ho automatitza:

# .gitignore de tecnomarket-dl
dades/
models/
logs/
__pycache__/
*.ipynb_checkpoints
.env

La regla mental: a git hi va el que permet REGENERAR els resultats (codi, config, requirements), no els resultats en si.

DVC i MLflow: el següent nivell

Dos noms per al teu radar (encara no els necessites, però te'ls trobaràs):

DVC (Data Version Control): estén la idea de git a dades i models — git desa un punter lleuger, el fitxer pesant viu en un emmagatzematge extern, i cada commit sap quina versió de les dades va fer servir.
MLflow: tracking d'experiments — registra automàticament paràmetres, mètriques i artefactes de cada entrenament i els mostra en una taula comparable. És la versió industrial del teu config.yaml + full de càlcul de resultats.

Monitorar entrenaments amb TensorBoard

A 06-01 vas afegir el callback de TensorBoard; ara el farem servir de debò. TensorBoard llegeix els logs escrits durant l'entrenament i els converteix en gràfiques interactives: corbes de pèrdua i precisió, comparació entre execucions, histogrames de pesos.

import datetime
from tensorflow import keras

# Un subdirectori per execució, amb marca de temps: així es comparen entre si
log_dir = "logs/ressenyes_" + datetime.datetime.now().strftime("%Y%m%d-%H%M%S")

tb = keras.callbacks.TensorBoard(log_dir=log_dir)
model.fit(train_ds, validation_data=val_ds, epochs=20, callbacks=[tb])

Per veure-ho:

# En terminal local:
tensorboard --logdir logs
# -> obre http://localhost:6006 al navegador

# A Colab / Jupyter, incrustat al mateix notebook:
%load_ext tensorboard
%tensorboard --logdir logs

Com llegir el que veuràs (connectant amb el que has après):

Pestanya Scalars: corbes de loss/val_loss i mètriques per època. La divergència entre entrenament i validació és el sobreajust que vas aprendre a combatre a 05-04 — aquí el veus dibuixar-se en directe, sense esperar el final.
Comparar execucions: cada subdirectori de logs/ apareix com una corba d'un color diferent. Entrena amb dropout 0.2 i 0.4 (dues configs, dues execucions) i compara-les superposades: això converteix l'ajust d'hiperparàmetres en una decisió visual.
PyTorch també hi juga: amb torch.utils.tensorboard.SummaryWriter escrius els mateixos logs des del teu bucle explícit de 06-02 (writer.add_scalar("loss/train", loss.item(), pas)). Una única eina de monitoratge per als dos frameworks de l'equip.

On continuar aprenent

Recursos estables, sense URLs que caduquin — tots es troben cercant-ne el nom:

Documentació oficial de TensorFlow/Keras i de PyTorch: totes dues inclouen tutorials guiats excel·lents i són la referència final davant de qualsevol dubte d'API. Els tutorials oficials de PyTorch ("60 Minute Blitz") complementen perfectament la lliçó 06-02.
Cursos i llibres clàssics: els cursos de deep learning de les grans plataformes educatives (els d'Andrew Ng són l'estàndard històric); Deep Learning de Goodfellow, Bengio i Courville (la teoria de referència, gratuït en línia); Hands-On Machine Learning de Géron (pràctic, amb Keras); el curs i llibre de fast.ai (enfocament "primer el codi", sobre PyTorch).
Papers: arXiv (preprints de la recerca en curs) i Papers with Code (paper + implementació + benchmark). Comença pels clàssics que ja coneixes de nom pel curs: ResNet (03-03), Attention Is All You Need (05-05).
Comunitats: Kaggle (competicions i notebooks públics), Stack Overflow (errors concrets), els fòrums oficials de cada framework i Hugging Face (models i exemples).
Pràctica deliberada: la millor recepta postcurs és triar un dataset públic que t'interessi, replicar la metodologia del curs (prototip → aplicació) i documentar-ho en un repositori git propi. Un projecte acabat ensenya més que deu tutorials — i és exactament el que farem junts al mòdul 7.

L'entorn de treball de TecnoMarket

Així queda organitzat l'equip de dades després d'aquesta lliçó:

Exploració: Colab (gratuït per a proves curtes; Pro per als entrenaments llargs del mòdul 7), sempre amb Drive muntat i ModelCheckpoint apuntant-hi.
Projecte: repositori git tecnomarket-dl amb l'estructura src/ + config.yaml + requirements.txt amb versions fixades; dades/, models/ i logs/ al .gitignore.
Regla de consolidació: res no passa de notebooks/ a src/ sense llavors fixades i sense poder executar-se amb python src/entrenar.py de principi a fi.
Monitoratge: TensorBoard amb un subdirectori per experiment; els dos frameworks escriuen al mateix logs/.
Pendent per a quan creixin: DVC per versionar el dataset de ressenyes i MLflow per al tracking, anotats al README com a pas següent.

Errors Comuns i Consells

Entrenar hores a Colab sense checkpoints a Drive: la desconnexió arribarà, i amb el disc efímer s'endú el teu model. ModelCheckpoint + Drive muntat, sempre.
Notebooks amb cel·les executades en desordre: l'estat ocult fa que "funcioni al meu notebook" i falli en reexecutar. Abans de donar res per bo: Restart & Run All. Si no sobreviu a això, no està acabat.
Commitejar dades, pesos o (pitjor) credencials: a més d'inflar el repo, una clau pujada a git queda a l'historial encara que l'esborris després. Escriu el .gitignore abans del primer commit.
Comparar experiments sense fixar llavors: la millora del 0,4 % del teu nou dropout pot ser pur atzar d'inicialització. Llavors fixes primer; conclusions després.
Instal·lar CUDA a mà sense necessitar-ho: prova primer l'ordre d'instal·lació oficial del framework — avui acostuma a portar-ho tot inclòs. Només si torch.cuda.is_available() dona False amb GPU present toca investigar drivers.
Consell: posa data i nom descriptiu a cada directori de logs i a cada config (ressenyes_dropout03_20260824). El teu jo d'aquí a tres setmanes no recorda què era prova2_final.

Exercicis

Exercici 1: dissenyar el .gitignore

El repositori d'un company de TecnoMarket conté: src/entrenar.py, config.yaml, dades/ressenyes_clients.csv (400 MB, amb emails reals), models/ressenyes_v3.keras (85 MB), logs/ (2 GB), requirements.txt, claus_api.txt i notebooks/exploracio.ipynb. Indica què s'ha de versionar a git, què no i per què; escriu el .gitignore resultant i assenyala el fitxer que representa un problema més enllà de la mida.

Exercici 2: reproduïbilitat

Un company executa dues vegades el mateix notebook de la xarxa MNIST i obté 97,68 % i 97,41 %, i en conclou que "la segona vegada el model va sortir pitjor". Explica per què la conclusió és errònia, quins quatre elements hauria de fixar/registrar perquè els experiments siguin comparables, i escriu el bloc de codi de llavors per a un script que fa servir TensorFlow i numpy.

Exercici 3: comparar experiments amb TensorBoard

Escriu l'esquema de codi (Keras) per entrenar el classificador de ressenyes dues vegades —dropout 0.2 i dropout 0.5— de manera que les dues execucions apareguin com a corbes separades i comparables a TensorBoard, i explica què miraries a les corbes per decidir quin dels dos valors és millor.

Solucions

Solució 1:

Sí a git: src/entrenar.py, config.yaml, requirements.txt, notebooks/exploracio.ipynb (text, permet regenerar la feina).
No a git: dades/ (gran i amb dades personals de clients — a banda de la mida, pujar-ho podria vulnerar la protecció de dades), models/ (binari regenerable), logs/ (regenerable i enorme), claus_api.txt.
El problema greu: claus_api.txt. No és qüestió de mida: una credencial commitejada queda a l'historial de git per sempre (esborrar-la del directori no l'esborra dels commits antics) i s'ha de considerar compromesa — cal revocar-la i regenerar-la, i passar les claus a variables d'entorn.

dades/
models/
logs/
claus_api.txt
.env
__pycache__/

Solució 2: La diferència 97,68 % vs. 97,41 % entra dins la variació normal per aleatorietat: inicialització de pesos diferent, remenat de lots diferent, dropout apagant neurones diferents. No hi ha "model pitjor": hi ha dues mostres de la mateixa distribució de resultats. Per comparar de debò: (1) llavors fixades, (2) versions de llibreries fixades a requirements.txt, (3) configuració registrada (config.yaml), (4) mateixes dades i mateixa partició train/test. I executar com a script de dalt a baix, no cel·les en desordre.

import random, numpy as np
import tensorflow as tf

SEED = 42
random.seed(SEED)
np.random.seed(SEED)
tf.random.set_seed(SEED)

Solució 3:

from tensorflow import keras

for dropout in [0.2, 0.5]:
    log_dir = f"logs/ressenyes_dropout{dropout}"     # subdirectori per experiment
    model = keras.Sequential([
        keras.layers.Dense(64, activation="relu"),
        keras.layers.Dropout(dropout),
        keras.layers.Dense(32, activation="relu"),
        keras.layers.Dense(1, activation="sigmoid"),
    ])
    model.compile(optimizer="adam", loss="binary_crossentropy", metrics=["accuracy"])
    model.fit(train_ds, validation_data=val_ds, epochs=20,
              callbacks=[keras.callbacks.TensorBoard(log_dir=log_dir)])

En llançar tensorboard --logdir logs, cada dropout és una corba. Què mirar: la val_loss (no la d'entrenament) — guanya el dropout amb menor pèrdua de validació estable; i la separació entre corba d'entrenament i de validació de cada experiment — si amb 0.2 la bretxa creix època rere època (sobreajust, com a 05-04) i amb 0.5 es mantenen juntes amb val_loss similar o millor, 0.5 és la tria.

Conclusió

L'equip de TecnoMarket ja no treballa en pestanyes soltes: sap què esperar de Colab i quan saltar a Kaggle, GPU local o núvol; entén les capes CUDA/cuDNN just el necessari per diagnosticar; ha convertit la seva feina en un projecte amb src/, configs i llavors que qualsevol pot reproduir; versiona amb git el que regenera resultats (i només això, amb .gitignore protegint dades, pesos i credencials); monitora cada experiment a TensorBoard; i té un mapa de recursos per continuar creixent. En una paraula: professionalització.

Queda la darrera peça del mòdul d'eines, i és la que ho connecta tot amb el món real: un model que viu a models/ no serveix a cap client de TecnoMarket. A la propera lliçó aprendràs a desar models correctament en tots dos frameworks, a empaquetar-los al costat del seu preprocessament i a desplegar-los: des d'un script batch fins a una API REST que respon peticions en viu.

Entorns de desenvolupament i recursos addicionals

Contingut

Colab a fons: què dona i què limita

Alternatives: Kaggle Notebooks i altres plataformes

Treballar en local amb GPU: CUDA i cuDNN

Del notebook al projecte: estructura i scripts

Reproduïbilitat: llavors i configuració

Control de versions per a ML

Què NO es commiteja

DVC i MLflow: el següent nivell

Monitorar entrenaments amb TensorBoard

On continuar aprenent

L'entorn de treball de TecnoMarket

Errors Comuns i Consells

Exercicis

Exercici 1: dissenyar el .gitignore

Exercici 2: reproduïbilitat

Exercici 3: comparar experiments amb TensorBoard

Solucions

Conclusió

Curs de Deep Learning

Mòdul 1: Introducció al Deep Learning

Mòdul 2: Fonaments de Xarxes Neuronals

Mòdul 3: Xarxes Neuronals Convolucionals (CNN)

Mòdul 4: Xarxes Neuronals Recurrents (RNN)

Mòdul 5: Tècniques Avançades en Deep Learning

Mòdul 6: Eines i Frameworks

Mòdul 7: Projectes Pràctics

Mòdul 8: Consideracions Ètiques i Futur del Deep Learning