Per prima cosa utilizziamo quelli del nostro progetto principale ramo per memorizzare la definizione del problema, la documentazione, la descrizione dei dati e la struttura del progetto. Questo funge da spazio per la collaborazione e le discussioni.
MANCIA: iniziando con la definizione chiara del problema aziendale, la determinazione del risultato desiderato, l’identificazione dei valori o delle etichette target e il modo in cui vengono ottenuti e la definizione di parametri e requisiti di valutazione, possiamo garantire un avvio positivo del nostro progetto e fornire un luogo per l’onboarding e la collaborazione.
Possiamo usarlo anche per tracciamento esperimenti, dove vengono combinati i risultati degli esperimenti. Per esempio, MLflow La cartella mlruns può essere unita lì a questo scopo. Qualsiasi collaboratore può effettuare il checkout di questo ramo ed eseguire l’interfaccia utente.
In alternativa, il tracciamento può essere effettuato in un’altra filiale.
Iniziare in questo modo è molto semplice e, poiché le esigenze cambiano nel tempo, è possibile passare a un server MLflow o a una piattaforma di monitoraggio come Weights and Biases con modifiche minime.
Questi sono rami del progetto, che includono principalmente file di dati, documentazione e script di trasformazione, e loro rimanere attivi. Puoi pensarli come i bucket S3, ma invece di caricare e scaricare, estrai un ramo e i tuoi file sono lì.
Si consiglia di eseguire sempre il commit (caricamento) nel file crudo ramo. Questi creano una fonte di verità, un luogo mai modificato o cancellato, in modo che possiamo sempre monitorare da dove provengono e passano i dati. Consente inoltre di creare facilmente nuovi flussi, verificarli e governarli.
💡 Se aggiungi un messaggio di commit sulla provenienza dei dati, puoi ottenere un’osservabilità ancora più granulare sui tuoi dati.
Puoi usarne un altro pulito ramo dove esistono solo dati puliti. Ad esempio, immagini rotte o file di testo vuoti caricati su ramo crudo non compaiono in pulito ramo.
UN diviso Il ramo in cui i dati vengono suddivisi per la formazione, la convalida e i test può garantire che tutti i team e i collaboratori lavorino sullo stesso campo di gioco.
Questo approccio aiuta a prevenire la fuga di dati e consente una progettazione e una collaborazione di funzionalità più solide. Ridurre al minimo la possibilità che gli esempi del set di test vengano inclusi nelle fasi di formazione riduce il rischio di introdurre distorsioni. Inoltre, avere tutti i collaboratori nella stessa suddivisione garantisce risultati coerenti e imparziali in un esperimento.
In un precedente progetto di classificazione, facevo parte di un team di singoli contributori in cui ogni persona gestiva l’intera pipeline da zero; ognuno di noi aveva utilizzato percentuali e seed di suddivisione dei dati diversi, il che ha portato a modelli di produzione più deboli basati su bug e distorsioni dei dati.
💡 Suggerimento per il ML: best practice per lo sviluppo del modello in tre fasi
Utilizziamo i set di dati di “addestramento” e “convalida” per addestrare e ottimizzare gli iperparametri del modello. Utilizziamo quindi il train plus validation come set di training per addestrare il nostro modello ottimizzato e valutarlo con il set di dati di test solo una volta. Infine, addestriamo il modello su tutti i dati e lo salviamo come modello.
Questi rami sono attivo rami per formazione e inferenza. Qui puoi eseguire l’addestramento, salvare il modello, i checkpoint e la scheda modello, eseguire test, creare e testare l’immagine Docker, eseguire il commit di tutto alla fine di un ciclo di addestramento e quindi Etichetta. Dovrebbero essere in grado di gestire il recupero di nuovi dati e la riqualificazione. È qui che avviene l’automazione.
⚠️ Nessun codice è scritto in questi rami.
Ciò garantisce che un modello sia accoppiato con i dati su cui è stato addestrato, il codice utilizzato per addestrarlo ed eseguirlo in produzione (inclusa l’ingegneria delle funzionalità) e le metriche dei risultati. Tutti questi componenti sono combinati in un’unica “istantanea” unificata. Ogni volta che controlli un’etichetta, sono presenti tutti i pezzi necessari per quel modello.
💡 Mancia: scegliendo in anticipo il nome del tag, è possibile aggiungere informazioni di tracciamento durante l’allenamento come parametro. Ciò garantisce che tu possa sempre recuperare la “istantanea” del codice dati del modello dati i dati di tracciamento utilizzando qualsiasi strumento di tracciamento.
Dopo l’allenamento, solo i dati di tracciamento vengono uniti (copiati) nel tuo principale ramo per il monitoraggio.
Nel caso più semplice può trattarsi di un file di testo JSON che contiene gli iperparametri e i risultati della valutazione. Questo file viene quindi aggiunto a un elenco nel file principale ramo. Nel caso di MLflow, si tratta di copiare gli esperimenti dal file cartella mlruns al principale ramo.
Questi rami sono per sviluppo del codice e esplorazione dei datiformazione su dati campionati o di piccole dimensioni fino ad avere un programma funzionante. Durante lo sviluppo, puoi utilizzare tutte le migliori pratiche Git. Tuttavia, ramificarsi solo verso a stabileramo quando non sono necessarie ulteriori modifiche al codice, anche se vengono inseriti dati aggiuntivi. Questi rami dovrebbe includere il codice di inferenza, il server, il Dockerfile e i test.
C’è sempre almeno un ramo di sviluppo che rimane attivodove vengono unite tutte le nuove funzionalità, correzioni di bug e altre modifiche.
💡 Gli ingegneri ML e MLOps possono collaborare sul versante della formazione e dell’inferenza.
Ad esempio, puoi creare un file sviluppatore/modello ramo in cui si sviluppa a linea di base modello. Questa può essere la classe più popolare per la classificazione o la media/mediana per la regressione. L’obiettivo è impostare il codice comprendendo a fondo i dati.
Quando è stabile e i test vengono superati, ci dirigiamo verso stabile/modello dove addestriamo e impegniamo insieme il modello, il codice e i dati in remoto e etichetta che si impegna. Questo è veloce e facile da condividere e consentirà ai team DevOps, backend e frontend di avviare lo sviluppo e scambiare feedback. Faciliterà inoltre la convalida dei requisiti appena scoperti in un ambiente reale il più presto possibile.
Successivamente, sviluppiamo il modello su sviluppatore/modello diramarsi in a modello semplice come la regressione lineare, e quando è pronto e i test vengono superati, possiamo unirlo a stabile/modello dove addestriamo, impegniamo e tagghiamo una versione prod.
Questo approccio ti dà la libertà di migliorare in modo incrementale il tuo modello preservando l’intero contesto dei modelli precedenti nel ramo stabile.
Da questo punto abbiamo tre opzioni:
- Noi possiamo riqualificare quando arrivano più dati estraendo i dati nel ramo stabile.
- Possiamo iniziare sperimentazione utilizzando l’ingegneria delle funzionalità su dev/regressione lineare ramo.
- Possiamo creare un nuovo sviluppo/nuovo approccio ramo per modelli più sofisticati.
Nel monitoraggio del modello ci preoccupiamo della distribuzione dei dati, dei valori anomali e delle distribuzioni delle previsioni.
Nel monitoraggio branch, salviamo i dati richiesti, il tag di commit e la previsione del modello da prod come file.
💡 Puoi utilizzare più rami di monitoraggio per ciascun ambiente: dev, stable e prod.
Possiamo impostare avvisi sui commit di dati da testare deriva in qualsiasi distribuzione di caratteristiche, valori anomali, calibrazione test di integrità e salvataggio del codice di avviso; ciò consente soluzioni più avanzate come un modello di rilevamento dei valori anomali poiché possiamo salvare il modello anche in questo ramo.
Questo ramo potrebbe in genere appartenere a un altro progetto disaccoppiato dal codice responsabile della creazione dei log di monitoraggio, nonché dai dati e dal modello che li hanno generati.
La scienza e l’analisi dei dati sono un altro aspetto del progetto che spesso viene separato in un progetto diverso. Qui vengono raccolti il codice di analisi e i dati non formativi dei data scientist.
Uno scienziato dei dati può controllare ed estrarre dati da monitoraggio ramo per eseguire analisi, test A/B e altri esperimenti online e offline. Possono anche utilizzare i dati del file crudo filiale per questi scopi.
Gli esempi online sono più semplici, poiché ogni gruppo di esperimenti corrisponde a un ramo.
💡 Suggerimento: esperimenti online comuni:
Prova in avanti– Confronto tra il modello attuale 99% e un modello candidato 1%.
Backtest — dopo aver unito un nuovo modello, mantenere l’1% sul modello precedente per convalidare l’effetto atteso al contrario.
Avere il tag del modello come parametro nei dati di monitoraggio aiuta a individuare ogni cambiamento nella potenziale causa della metrica.
Fonte: towardsdatascience.com
