Usare il controllo del codice sorgente per gli asset di Machine Learning

Il modello di classificazione del diabete Proseware è stato avviato in un notebook Jupyter su un portatile. Quando il team cresce, ovvero data scientist, ingegneri di Machine Learning e revisori, questo approccio si interrompe. È necessaria una posizione in cui tutti gli utenti lavorano dallo stesso codice, possono esaminare le modifiche dell'altro e tracciare ogni modello al codice che lo ha prodotto.

Che cosa appartiene in Git

Un repository Git è la casa giusta per gli asset che definiscono il modello e il relativo processo di training:

• Script di addestramento e preelaborazione — i file Python che eseguono la preparazione dei dati e l’addestramento del modello
• Definizioni di processi e componenti : file YAML che descrivono Azure Machine Learning processi di comando e componenti della pipeline
• File di ambiente e delle dipendenze — requirements.txt, conda.yml o definizioni di ambiente di Azure Machine Learning
• File di configurazione : nomi di aree di lavoro, nomi dei gruppi di risorse, nomi di calcolo e altri riferimenti usati dall'automazione

Cosa non appartiene in Git

Alcuni asset appartengono a servizi creati appositamente, non in un repository:

• Set di dati e dati non elaborati — usare gli asset di dati di Azure Machine Learning o Azure Data Lake Storage; i file di dati sono di grandi dimensioni e sono sottoposti a controllo delle versioni separatamente dal codice
• Artefatti di modelli addestrati — registrare asset di modello denominati e versionati in Azure Machine Learning
• Output e log dell'esecuzione del training: Azure Machine Learning li archivia con il processo
• Segreti e credenziali: usare GitHub segreti o Azure Key Vault; l'inserimento delle credenziali in un repository li espone a chiunque disponga dell'accesso in lettura

Perché il controllo del codice sorgente è importante per l'apprendimento automatico

Quando ogni definizione di training si trova in Git, il team lavora dalla stessa versione del codice. Un revisore vede esattamente ciò che è cambiato tra le esecuzioni. Se una modifica degrada le prestazioni del modello, è possibile tornare al commit precedente. Le definizioni registrate del codice e dell'ambiente aiutano anche a riprodurre un'esecuzione di addestramento.

Questa tracciabilità è la base per tutto ciò che segue, ovvero lo sviluppo basato su rami, la convalida automatizzata e un audit trail che connette ogni versione del modello alla modifica che lo ha prodotto.