Complimenti! Hai eseguito il deployment del modello unicorno. Il modello deve essere eseguito 24 ore su 24, 7 giorni su 7 senza problemi. Per assicurarti che lo faccia, devi monitorare la pipeline di machine learning (ML).
Scrivere uno schema dei dati per convalidare i dati non elaborati
Per monitorare i dati, devi controllarli continuamente rispetto ai valori statistici previsti scrivendo regole che i dati devono soddisfare. Questa raccolta di regole è chiamata schema dei dati. Definisci uno schema dei dati seguendo questi passaggi:
Comprendere la gamma e la distribuzione delle funzionalità. Per le caratteristiche categoriche, comprendi l'insieme dei valori possibili.
Codifica la tua comprensione nello schema dei dati. Di seguito sono riportati alcuni esempi di regole:
- Assicurati che le valutazioni inviate dagli utenti siano sempre comprese tra 1 e 5.
- Verifica che la parola the ricorra più frequentemente (per una funzionalità di testo in inglese).
- Verifica che ogni caratteristica categorica sia impostata su un valore di un insieme fisso di valori possibili.
Testa i dati in base allo schema dei dati. Lo schema deve rilevare errori nei dati, ad esempio:
- Anomalie
- Valori imprevisti delle variabili categoriche
- Distribuzioni dei dati impreviste
Scrivere test delle unità per convalidare il feature engineering
Anche se i dati non elaborati potrebbero superare lo schema dei dati, il modello non viene addestrato sui dati non elaborati. Il modello viene addestrato su dati di cui è stata eseguita l'ingegneria delle funzionalità. Ad esempio, il modello viene addestrato su funzionalità numeriche normalizzate anziché su dati numerici non elaborati. Poiché i dati di ingegneria delle funzionalità possono essere molto diversi dai dati di input non elaborati, devi controllare i dati di ingegneria delle funzionalità separatamente dai controlli sui dati di input non elaborati.
Scrivi test delle unità in base alla tua comprensione dei dati di ingegneria delle funzionalità. Ad esempio, puoi scrivere test delle unità per verificare condizioni come le seguenti:
- Tutte le funzionalità numeriche vengono scalate, ad esempio tra 0 e 1.
- I vettori con codifica one-hot contengono un solo 1 e N-1 zeri.
- Le distribuzioni dei dati dopo la trasformazione sono conformi alle aspettative. Ad esempio, se hai normalizzato utilizzando gli Z-score, la media degli Z-score deve essere 0.
- I valori anomali vengono gestiti, ad esempio tramite scalabilità o ritaglio.
Controllare le metriche per le sezioni di dati importanti
Un intero riuscito a volte oscura un sottoinsieme non riuscito. In altre parole, un modello con ottime metriche complessive potrebbe comunque fare previsioni errate per determinate situazioni. Ad esempio:
Il tuo modello unicorno ha un buon rendimento complessivo, ma scarso quando fa previsioni per il deserto del Sahara.
Se sei il tipo di ingegnere soddisfatto di un'ottima AUC complessiva, potresti non notare i problemi del modello nel deserto del Sahara. Se è importante fare buone previsioni per ogni regione, devi monitorare il rendimento per ogni regione. I sottoinsiemi di dati, come quello corrispondente al deserto del Sahara, sono chiamati sezioni di dati.
Identifica le sezioni di dati di interesse. Quindi, confronta le metriche del modello per queste sezioni di dati con le metriche dell'intero set di dati. Verificare che il modello funzioni bene in tutte le sezioni di dati aiuta a eliminare i bias. Per ulteriori informazioni, consulta Equità: valutazione del bias.
Utilizzare metriche del mondo reale
Le metriche del modello non misurano necessariamente l'impatto reale del modello. Ad esempio, la modifica di un iperparametro potrebbe aumentare l'AUC di un modello, ma in che modo la modifica ha influito sull'esperienza utente? Per misurare l'impatto nel mondo reale, devi definire metriche separate. Ad esempio, potresti chiedere agli utenti del tuo modello di confermare di aver visto un unicorno quando il modello ha previsto che l'avrebbero visto.
Controllare il disallineamento addestramento/produzione
Disallineamento addestramento/produzione significa che i dati di input durante l'addestramento sono diversi dai dati di input nella produzione. La tabella seguente descrive i due tipi importanti di distorsione:
| Tipo | Definizione | Esempio | Soluzione |
|---|---|---|---|
| Skew dello schema | I dati di input di addestramento e serving non sono conformi allo stesso schema. | Il formato o la distribuzione dei dati di pubblicazione cambia mentre il modello continua a essere addestrato su dati precedenti. | Utilizza lo stesso schema per convalidare i dati di addestramento e di pubblicazione. Assicurati di controllare separatamente le statistiche non controllate dallo schema, ad esempio la frazione di valori mancanti |
| Distorsione delle caratteristiche | I dati di ingegneria differiscono tra l'addestramento e la distribuzione. | Il codice di feature engineering è diverso tra l'addestramento e la pubblicazione, e produce dati di ingegneria diversi. | Analogamente al disallineamento dello schema, applica le stesse regole statistiche ai dati di addestramento e di pubblicazione. Monitora il numero di caratteristiche distorte rilevate e il rapporto tra esempi distorti per caratteristica. |
Le cause del disallineamento addestramento/produzione possono essere sottili. Considera sempre quali dati sono disponibili per il modello al momento della previsione. Durante l'addestramento, utilizza solo le funzionalità che avrai a disposizione durante la pubblicazione.
Esercizio: verifica la tua comprensione
Supponiamo che tu abbia un negozio online e voglia prevedere quanto guadagnerai in un determinato giorno. Il tuo obiettivo di ML è prevedere le entrate giornaliere utilizzando il numero di clienti come funzionalità.
Risposta:il problema è che non conosci il numero di clienti al momento della previsione, prima che le vendite della giornata siano completate. Pertanto, questa funzionalità non è utile, anche se è fortemente predittiva delle tue entrate giornaliere. Allo stesso modo, quando addestri un modello e ottieni metriche di valutazione sorprendenti (come 0,99 AUC), cerca questo tipo di funzionalità che possono influenzare l'etichetta.
Controllare la perdita di etichette
Perdita di etichette significa che le etichette basate su dati empirici reali che stai cercando di prevedere sono entrate inavvertitamente nelle funzionalità di addestramento. La perdita di etichette a volte è molto difficile da rilevare.
Esercizio: verifica la tua comprensione
Supponiamo di creare un modello di classificazione binaria per prevedere se un nuovo paziente ospedaliero ha il cancro. Il modello utilizza funzionalità come le seguenti:
- Età del paziente
- Genere del paziente
- Patologie pregresse
- Nome dell'ospedale
- Parametri vitali
- Risultati del test
- Ereditarietà
L'etichetta è la seguente:
- Booleano: il paziente ha un tumore?
Partiziona i dati con attenzione, assicurandoti che il set di addestramento sia ben isolato dal set di convalida e dal set di test. Il modello ha prestazioni estremamente buone sul set di convalida e sul set di test; le metriche sono fantastiche. Purtroppo, il modello ha un rendimento pessimo con i nuovi pazienti nel mondo reale.
Risposta: una delle funzionalità del modello è il nome dell'ospedale. Alcuni ospedali sono specializzati nel trattamento del cancro. Durante l'addestramento, il modello ha appreso rapidamente che i pazienti assegnati a determinati ospedali avevano con molta probabilità un tumore. Pertanto, il nome dell'ospedale è diventato una funzionalità con un peso elevato.
Al momento dell'inferenza, alla maggior parte dei pazienti non era ancora stato assegnato un ospedale. Dopo tutto, lo scopo del modello era quello di diagnosticare la presenza o l'assenza di cancro e di utilizzare poi la diagnosi per assegnare il paziente a un ospedale appropriato. Di conseguenza, durante l'inferenza, la funzionalità del nome dell'ospedale non era ancora disponibile e il modello è stato costretto a fare affidamento su altre funzionalità.
Monitora l'età del modello durante la pipeline
Se i dati di pubblicazione cambiano nel tempo, ma il modello non viene riaddestrato regolarmente, la qualità del modello diminuirà. Tieni traccia del tempo trascorso dall'ultimo addestramento del modello con nuovi dati e imposta una soglia di età per gli avvisi. Oltre a monitorare l'età del modello al momento della pubblicazione, devi monitorare l'età del modello durante l'intera pipeline per rilevare eventuali interruzioni della pipeline.
Verifica che i pesi e gli output del modello siano numericamente stabili
Durante l'addestramento del modello, i pesi e gli output dei livelli non devono essere NaN (not a number) o Inf (infinite). Scrivi test per verificare la presenza di valori NaN e Inf per i pesi e gli output dei livelli. Inoltre, verifica che più della metà degli output di un livello non sia zero.
Monitorare il rendimento del modello
Il tuo strumento di previsione dell'apparizione degli unicorni ha avuto più successo del previsto. Ricevi molte richieste di previsione e ancora più dati di addestramento. Pensi che sia fantastico finché non ti rendi conto che il modello richiede sempre più memoria e tempo per l'addestramento. Decidi di monitorare le prestazioni del modello seguendo questi passaggi:
- Monitora le prestazioni del modello in base alle versioni di codice, modello e dati. Questo monitoraggio ti consente di individuare la causa esatta di qualsiasi peggioramento delle prestazioni.
- Testa i passaggi di addestramento al secondo per una nuova versione del modello rispetto alla versione precedente e a una soglia fissa.
- Rileva le perdite di memoria impostando una soglia per l'utilizzo della memoria.
- Monitora i tempi di risposta delle API e monitora i relativi percentili. Sebbene i tempi di risposta dell'API potrebbero non dipendere da te, le risposte lente potrebbero potenzialmente causare metriche reali scadenti.
- Monitora il numero di query a cui viene data risposta al secondo.
Testare la qualità del modello live sui dati pubblicati
Hai convalidato il modello. Ma cosa succede se gli scenari reali, come il comportamento degli unicorni, cambiano dopo la registrazione dei dati di convalida? In questo caso, la qualità del modello servito peggiorerà. Tuttavia, testare la qualità nella pubblicazione è difficile perché i dati reali non sono sempre etichettati. Se i dati di pubblicazione non sono etichettati, prova questi test:
Esamina i modelli che mostrano un bias statistico significativo nelle previsioni. Consulta Classificazione: distorsione della previsione.
Monitora le metriche reali per il tuo modello. Ad esempio, se stai classificando lo spam, confronta le tue previsioni con lo spam segnalato dagli utenti.
Mitigare la potenziale divergenza tra i dati di addestramento e quelli di pubblicazione pubblicando una nuova versione del modello su una frazione delle query. Man mano che convalidi il nuovo modello di pubblicazione, passa gradualmente tutte le query alla nuova versione.
Quando utilizzi questi test, ricorda di monitorare il degrado improvviso e lento della qualità della previsione.
Visualizzazione casuale
Rendi riproducibile la tua pipeline di generazione dei dati. Supponiamo che tu voglia aggiungere una funzionalità per vedere come influisce sulla qualità del modello. Per un esperimento equo, i set di dati devono essere identici, ad eccezione di questa nuova funzionalità. In questo spirito, assicurati che qualsiasi randomizzazione nella generazione dei dati possa essere resa deterministica:
- Inizializza i generatori di numeri casuali (RNG). Il seeding garantisce che il RNG produca gli stessi valori nello stesso ordine ogni volta che lo esegui, ricreando il tuo set di dati.
- Utilizza chiavi hash invarianti. L'hashing è un modo comune per dividere o campionare i dati. Puoi calcolare l'hash di ogni esempio e utilizzare l'intero risultante per decidere in quale suddivisione inserirlo. Gli input della funzione hash non devono cambiare ogni volta che esegui il programma di generazione dei dati. Non utilizzare l'ora attuale o un numero casuale nell'hash, ad esempio se vuoi ricreare gli hash on demand.
Gli approcci precedenti si applicano sia al campionamento sia alla suddivisione dei dati.
Considerazioni sull'hashing
Immagina di raccogliere query di ricerca e di utilizzare l'hashing per includerle o escluderle. Se la chiave hash utilizzava solo la query, in più giorni di dati, includerai sempre la query o la escluderai sempre. Includere o escludere sempre una query è un errore perché:
- Il set di addestramento vedrà un insieme di query meno diversificato.
- I set di valutazione saranno artificialmente difficili perché non si sovrapporranno ai dati di addestramento. In realtà, al momento della pubblicazione, avrai visto parte del traffico live nei dati di addestramento, quindi la tua valutazione dovrebbe riflettere questo aspetto.
In alternativa, puoi eseguire l'hashing della query e della data della query, ottenendo un hashing diverso per ogni giorno.
