Ritrovare la prova dietro ogni risultato.

Distinguere campagna, configurazione ed esecuzione

Una campagna porta una domanda, ad esempio confrontare una baseline con un adattamento. Una configurazione descrive le scelte tecniche. Un run è un tentativo di esecuzione di quella configurazione, con un seed, un inizio, una fine e uno stato. Due tentativi identici mantengono quindi due identificatori, anche se il secondo sostituisce una prova interrotta.

Aggiungi un identificatore di valutazione quando lo stesso artefatto viene valutato su più set o con una nuova metrica. Questo evita di confondere un nuovo modello con una nuova lettura del modello esistente. Collega il tentativo di ripresa a quello che lo ha preceduto e al checkpoint caricato.

Anche MLflow organizza il monitoraggio attorno a run, parametri, metriche e artefatti. Questa distinzione è utile anche in una semplice cartella di file. Puoi applicarla con il tuo strumento abituale; nessuna piattaforma di tracciamento specifica è necessaria per iniziare.

Fonti tecniche: MLflow — run, parametri, metriche e artefatti

Scrivere il manifest effettivamente eseguito

Conserva i parametri risolti dopo l'applicazione dei valori predefiniti e degli argomenti di avvio. Il file di configurazione originale può omettere un batch predefinito o un'opzione modificata in fase di esecuzione. Registra ciò che è stato effettivamente utilizzato, con una copia del codice o una revisione immutabile e lo stato delle modifiche non salvate.

Il manifest collega anche versioni del modello e del tokenizer, ambiente software, GPU effettivamente utilizzata, precisione, dati, seed e definizione delle metriche. Descrive la prova, senza diventare un tutorial di installazione. Annota le unità: secondi, byte, token, punti o proporzione da 0 a 1 secondo la misura.

All'avvio, lo stato è in corso; alla fine, diventa completato, fallito o interrotto secondo quanto hai constatato. Non completare a posteriori una versione dimenticata con quella attualmente installata. Segna l'informazione come sconosciuta e limita la conclusione che ne dipende.

Identificare i dati oltre un nome di cartella

Un percorso come donnees/final non indica una versione stabile. Conserva l'inventario dei file o degli esempi, gli split e la procedura di trasformazione. Se correggi delle label o filtri delle righe, crea una nuova versione e mantieni la relazione con la precedente. Il vecchio punteggio deve continuare a puntare ai suoi vecchi dati.

Hugging Face Datasets associa dei fingerprint allo stato di un dataset e alle sue trasformazioni per gestire la cache. Questo meccanismo è utile, ma occorre conservare anche l'origine dei dati e il preprocessamento. Una trasformazione non hashable può ad esempio portare a un fingerprint casuale: l'identificatore di cache non sostituisce da solo la tua cartella di provenienza.

Per gli artefatti congelati, aggiungi dimensione e impronta del file. Un digest SHA-256 calcolato prima e dopo una copia permette di verificare che i byte corrispondano al riferimento conservato. Non prova né la qualità delle label, né i diritti d'uso, né l'assenza di leakage tra gli split.

Fonti tecniche: Hugging Face Datasets — fingerprint e trasformazioni · Python 3.14 — impronte di file con hashlib

Collegare metriche, predizioni e artefatti

Una riga di metrica dovrebbe identificare il run, l'artefatto valutato, il set di valutazione, la versione della metrica e il suo perimetro. Specifica se il valore riguarda un checkpoint intermedio, il modello finale o un sottogruppo. Una curva non basta se non si sa più quale file corrisponde al punto scelto.

Conserva le predizioni con il loro identificatore di input, il loro stato e le informazioni necessarie alla valutazione. I riferimenti attesi possono restare in un file separato versionato. Per un output strutturato, distingui risultato grezzo, risultato analizzato e verdetto: correggere il parsing non deve sovrascrivere l'output iniziale.

MLflow permette di collegare metriche a modelli e a dati. Con i file, applica lo stesso principio tramite identificatori espliciti. Mantieni un inventario leggibile degli artefatti: pesi o adattatore, parametri di generazione, output, report di valutazione e nota di decisione. Non dare per scontato che uno screenshot sostituisca questi file.

Fonti tecniche: MLflow — collegare metriche, modelli e set di dati

Esempio: sei run e un duplicato che nasconde una mancanza

Consideriamo un esempio di classificazione con due configurazioni e tre seed. Produce sei run previsti. Ognuno deve predire gli stessi 300 identificatori di valutazione: la cartella completa attende quindi 6 × 300 = 1 800 coppie uniche (run_id, input_id). Questo calcolo descrive un inventario atteso, non un esperimento realmente eseguito.

Supponiamo che un file contenga 300 righe, ma che l'identificatore doc-042 sia presente due volte e doc-117 sia assente. Il totale delle righe sembra corretto; ci sono però solo 299 identificatori unici. Questo run fallisce il controllo di copertura finché l'anomalia non viene spiegata e corretta.

Se ogni run viene poi valutato sul corpus completo e sul suo sottogruppo di testi lunghi, ottieni dodici righe di metrica per una data metrica. Restano sei run, non dodici addestramenti indipendenti. La chiave di valutazione deve includere il perimetro per conservare questa distinzione.

Chiudere la cartella con una decisione leggibile

Prima di dichiarare un run terminato, controlla presenza e apertura dei file, corrispondenza degli identificatori, metriche ricalcolabili e stato di ogni errore. Un tentativo tecnicamente terminato può restare respinto per qualità insufficiente. Mantieni separati questi due stati.

La nota di decisione raccoglie la domanda, le varianti confrontate, il criterio annunciato, i risultati scelti e le ragioni dell'esclusione. Cita i run_id e i percorsi degli artefatti invece di «l'ultimo modello». Aggiungi i limiti: poche ripetizioni, sottogruppo insufficiente, versione non ritrovata o confronto diventato impossibile.

Una correzione successiva deve lasciare una traccia: nuova valutazione, nuovo report e motivo del cambiamento. Conserva la vecchia conclusione come versione storica identificata, senza lasciarla apparire come decisione attuale. Verifica infine che la copia esportata si apra dalla sua cartella di destinazione.

Evitare la raccolta inutile e le promesse di riproduzione

Raccogli i campi necessari alla prova, non tutte le variabili d'ambiente né la cronologia del terminale. Una configurazione o un URL può contenere un token; prepara una versione condivisibile senza segreti e conserva i dati che devono restare privati nella loro posizione autorizzata. Gli identificatori tecnici di prova non hanno bisogno di includere il nome di una persona.

Una cartella completa migliora la possibilità di rifare e capire un esperimento. Non garantisce un'uguaglianza numerica tra piattaforme o versioni: PyTorch documenta questi limiti di riproducibilità. Distingui ritrovare il protocollo, ricaricare l'artefatto e riprodurre esattamente i numeri.

Il carnet IteraGPU può conservare i tuoi obiettivi, parametri e decisioni, con i riferimenti utili. Non avvia i run né raccoglie automaticamente i file o la telemetria. Usalo come indice del tuo ragionamento e conserva la cartella degli artefatti nei tuoi backup.

Fonti tecniche: PyTorch 2.14 — limiti di riproducibilità tra ambienti

Domande pratiche