Il deployment è pronto. Se implementare semplicemente un modello fosse semplice come premere un grande pulsante rosso, Quando esegui il deployment, vuoi che la pipeline venga eseguita, aggiornata e pubblicata senza intoppi. che devono poi soddisfare i requisiti e le soluzioni illustrati in questa pagina.
Testa aggiornamenti del modello con addestramento riproducibile
Sei certo di voler continuare a migliorare il predittore dell'aspetto tra unicorni. Immaginiamo che sia stato eseguito il refactoring del codice tecnico per la funzionalità "Ora del giorno". Come puoi verificare che il codice sia corretto? Decidi di addestrare nuovamente il modello per vedere se ottieni lo stesso risultato. No, l'addestramento del modello non è riproducibile. Per continuare a prevedere l'aspetto degli unicorni, effettui ulteriori accertamenti. Puoi ottenere la riproduzione con i seguenti passaggi:
Seme determinativamente il generatore di numeri casuali (RNG). Per maggiori dettagli, consulta la sezione relativa alla casualizzazione dei dati nella generazione di dati del corso di preparazione dei dati e progettazione ingegneristica nel machine learning.
Inizializza i componenti del modello in ordine fisso per assicurarti che i componenti ricevano lo stesso numero casuale dal RNG a ogni esecuzione. In genere, le librerie ML gestiscono automaticamente questo requisito.
Media di diverse esecuzioni del modello.
Utilizza il controllo della versione, anche per iterazioni preliminari, in modo da poter fissare codice e parametri durante l'analisi del modello o della pipeline.
Anche dopo aver seguito questi passaggi, potresti avere altre fonti di non determinismo.
Test degli aggiornamenti del modello a specifiche e chiamate API
Dopo aver aggiornato il modello a Unicorn Predictor 2.0, devi testare la nuova correttezza dell'algoritmo in questo nuovo modello, insieme a eventuali modifiche alle chiamate API. Vediamo come.
Test delle chiamate API
Come si testano gli aggiornamenti delle chiamate API? Certo, potresti reimpostare il tuo modello, ma richiede molto tempo. Scrivere un test unitario per generare dati di input casuali ed eseguire un singolo passaggio di discesa del gradiente. Vuoi che il passaggio venga completato senza errori di runtime.
Test per la correttezza algoritmica
Un modello deve non solo prevedere correttamente, ma anche farlo perché è algoritmicamente corretto, non fortunato. Ad esempio, se il 99% delle email non è spam, la classificazione di tutte le email come non spam ottiene un'accuratezza del 99% attraverso il caso. Per questo motivo, devi verificare che il modello sia corretto. Procedi nel seguente modo:
- Addestra il tuo modello per alcune iterazioni e verifica che la perdita diminuisca.
- Addestrare il tuo algoritmo senza regolarizzazioni. Se il modello è abbastanza complesso, i dati di addestramento verranno memorizzati e la perdita di addestramento sarà vicina a 0.
- Testare sottocomunicazioni specifiche del tuo algoritmo. Ad esempio, puoi verificare che una parte del tuo RNN venga eseguita una volta per ogni elemento dei dati di input.
Scrivere test di integrazione per i componenti della pipeline
In una pipeline ML, le modifiche in un componente possono causare errori in altri componenti. Verifica che i componenti funzionino insieme scrivendo un test che esegua l'intera pipeline end-to-end. Questo tipo di test è detto test di integrazione.
Oltre a eseguire i test di integrazione in modo continuo, è consigliabile eseguire test di integrazione quando si eseguono il push di nuovi modelli e di nuove versioni del software. La lentezza dell'esecuzione dell'intera pipeline rende più difficile il test dell'integrazione continua. Per eseguire più rapidamente i test di integrazione, esegui l'addestramento su un sottoinsieme di dati o con un modello più semplice. I dettagli dipendono dal modello e dai dati. Per ottenere una copertura continua, devi modificare i test più veloci in modo che vengano eseguiti con ogni nuova versione del modello o software. Nel frattempo, i test lenti verranno eseguiti continuamente in background.
Convalida la qualità del modello prima della pubblicazione
Prima di eseguire il deployment di una nuova versione del modello in produzione, verifica se questi due tipi di riduzione sono di qualità:
Degrado improvviso: un bug nella nuova versione potrebbe causare una qualità significativamente inferiore. Convalidare le nuove versioni controllando la qualità rispetto alla versione precedente.
Degrado lento: il test per un deterioramento improvviso potrebbe non rilevare una lentezza con una riduzione della qualità del modello su più versioni. Assicurati che le previsioni del modello su un set di dati di convalida soddisfino una soglia fissa. Se il set di dati di convalida si discosta dai dati in tempo reale, aggiorna il set di dati di convalida e assicurati che il modello soddisfi ancora la stessa soglia di qualità.
Convalidare la compatibilità dell'infrastruttura prima di pubblicare
Se il modello viene aggiornato più velocemente del server, avrà dipendenze dipendenti dal server diverse dal server, causando potenzialmente incompatibilità. Assicurati che le operazioni utilizzate dal modello siano presenti nel server creando un modello in una versione con sandbox del server.