Pipeline PyTorch controllata da Gin Config: esperimenti riproducibili senza toccare il codice

Chi gestisce esperimenti di training conosce il problema: modificare architettura, ottimizzatore o schedule direttamente nel codice rende difficile riprodurre esattamente una run. Questo tutorial mostra come usare Gin Config di Google con PyTorch per mantenere stabile il codice di training e spostare tutti i gradi di libertà sperimentali in file di configurazione dichiarativi. Il caso d’uso è una classificazione binaria su un dataset a spirale non lineare, con una MLP configurabile e parametri esposti tramite binding @gin.configurable.

L’idea di fondo

Con Gin, il codice eseguibile resta invariato mentre optimizer, scheduler, loss, batching, seeding e loop di training vengono controllati da file .gin. Si usano riferimenti scoped per istanziare configurazioni di modello separate, binding a runtime per sovrascrivere singoli parametri senza modificare il sorgente, e l’export dell’operative config per catturare la configurazione esatta risolta che ha prodotto ogni run. È il pattern che serve per passare da esperimenti in Colab a pipeline di livello research.

Come è strutturato il pipeline

Il flusso costruisce prima il dataset a spirale e un DataLoader configurabile, poi definisce una classe MLP in cui numero di layer, funzione di attivazione (relu, gelu, tanh, silu), dropout e layer normalization sono tutti controllati da Gin invece che hardcoded. Optimizer (AdamW o SGD), scheduler con warmup e decadimento cosine, e loss binary cross-entropy con label smoothing sono anch’essi funzioni configurabili. Il runner di alto livello, run_experiment, collega dataset, modello, optimizer, scheduler e training loop tramite dipendenze gestite da Gin.

La parte più interessante è la composizione delle configurazioni: un file base.gin condiviso viene incluso da due esperimenti scoped, uno compatto GELU+AdamW e uno più ampio ReLU+SGD. La funzione run_from_gin_file mostra anche override a runtime (es. fit.epochs = 45), query dei parametri con gin.query_parameter, e il config locking: dopo il parsing, tentare gin.bind_parameter(\"fit.epochs\", 999) solleva un errore, garantendo che la configurazione non venga alterata durante la run. Al termine vengono salvati sia i risultati (metriche, history) sia l’operative config, per un record completo delle impostazioni usate.

Perché conta

Per chi lavora con data stack e ML, questo approccio migliora controllo, tracciabilità e modularità: si confrontano comportamenti di training diversi (AdamW vs SGD) a parità di dataset ed epoche, si verifica il locking della configurazione, e si conservano metriche e operative config per ispezioni successive, senza mai toccare l’implementazione core.

• Il codice di training resta stabile: tutti i parametri sperimentali vivono in file .gin componibili e versionabili.
• Gli scoped binding permettono varianti di modello multiple; gli override a runtime evitano di modificare il sorgente per singole prove.
• L’export dell’operative config rende ogni run riproducibile registrando la configurazione esatta risolta.

Fonte: Building a Gin Config Controlled PyTorch Pipeline with Configurable MLP Variants, Cosine Scheduling, and Runtime Parameter Overrides — https://www.marktechpost.com/2026/07/15/building-a-gin-config-controlled-pytorch-pipeline-with-configurable-mlp-variants-cosine-scheduling-and-runtime-parameter-overrides/