Complimenti! Hai eseguito il deployment del modello unicorno. Il modello dovrebbe funzionare 24 ore su 24, 7 giorni su 7 senza problemi. Per assicurarti che ciò accada, devi monitorare la pipeline di machine learning (ML).
Scrivi uno schema di 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 di dati. Per definire uno schema dei dati, segui questi passaggi:
Comprendi l'intervallo e la distribuzione delle funzionalità. Per le caratteristiche categoriche, comprendi l'insieme di valori possibili.
Codifica le tue conoscenze nello schema dei dati. Di seguito sono riportati alcuni esempi di regole:
- Assicurati che le valutazioni inviate dagli utenti rientrino sempre nell'intervallo da 1 a 5.
- Verifica che la parola the si presenti più di frequente (per una funzionalità di testo in inglese).
- Verifica che a ogni caratteristica categorica sia assegnato un valore di un insieme fisso di valori possibili.
Verifica la conformità dei dati allo schema. 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 la feature engineering
Anche se i dati non elaborati potrebbero superare lo schema dei dati, il modello non viene addestrato su questi dati. Il modello viene invece addestrato su dati sottoposti a progettazione di funzionalità. Ad esempio, il modello viene addestrato su caratteristiche numeriche normalizzate piuttosto che su dati numerici non elaborati. Poiché i dati di creazione di funzionalità possono essere molto diversi dai dati di input non elaborati, devi controllarli separatamente dai controlli sui dati di input non elaborati.
Scrivi i test delle unità in base alla tua conoscenza dei dati di progettazione delle funzionalità. Ad esempio, puoi scrivere test di unità per verificare condizioni come le seguenti:
- Tutte le caratteristiche numeriche vengono scalate, ad esempio tra 0 e 1.
- I vettori codificati 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 i dati utilizzando i valori z, la media dei valori z deve essere 0.
- Gli outlier vengono gestiti, ad esempio tramite scalabilità o taglio.
Controllare le metriche per i segmenti di dati importanti
A volte un insieme riuscito oscura un sottoinsieme non riuscito. In altre parole, un modello con ottime metriche complessive potrebbe comunque fare previsioni terribili per determinate situazioni. Ad esempio:
Il modello unicorno ha un buon rendimento complessivo, ma ha un rendimento scarso quando fa previsioni per il deserto del Sahara.
Se sei il tipo di ingegnere soddisfatto di un'AUC complessivamente elevata, 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.
Identificare i segmenti di dati di interesse. Poi confronta le metriche del modello per questi segmenti di dati con le metriche dell'intero set di dati. Verificare che il modello funzioni bene in tutti i segmenti di dati contribuisce a rimuovere i bias. Per ulteriori informazioni, consulta Equità: valutazione dell'eventuale presenza di bias.
Utilizza metriche reali
Le metriche del modello non misurano necessariamente l'impatto del modello nel mondo reale. 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 distinte. Ad esempio, potresti sottoporre a sondaggio gli utenti del tuo modello per confermare che hanno effettivamente visto un unicorno quando il modello aveva previsto che lo avrebbero visto.
Controllare la presenza di un disallineamento addestramento/produzione
Disallineamento addestramento/produzione indica che i dati di input durante l'addestramento sono diversi da quelli di input durante l'erogazione. La tabella seguente descrive i due tipi importanti di scostamento:
| Tipo | Definizione | Esempio | Soluzione |
|---|---|---|---|
| Spostamento dello schema | I dati di input per l'addestramento e l'erogazione non sono conformi allo stesso schema. | Il formato o la distribuzione dei dati di pubblicazione cambia mentre il modello continua ad addestrarsi sui dati precedenti. | Utilizza lo stesso schema per convalidare i dati di addestramento e di pubblicazione. Assicurati di controllare separatamente le statistiche non controllate dal tuo schema, ad esempio la frazione di valori mancanti |
| Spostamento delle funzionalità | I dati di ingegnerizzazione sono diversi tra l'addestramento e l'erogazione. | Il codice di feature engineering è diverso per l'addestramento e la pubblicazione, producendo dati di ingegnerizzazione diversi. | Analogamente allo schema di scostamento, applica le stesse regole statistiche ai dati di addestramento e di pubblicazione. Monitora il numero di funzionalità distorte rilevate e il rapporto tra esempi distorti per funzionalità. |
Le cause del disallineamento addestramento/produzione possono essere sottili. Tieni sempre presente quali dati sono disponibili per il tuo modello al momento della previsione. Durante l'addestramento, utilizza solo le funzionalità che avrai a disposizione al momento della pubblicazione.
Esercizio: verifica di aver compreso
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 caratteristica.
Risposta: il problema è che non conosci il numero di clienti al momento della previsione, prima che le vendite del giorno siano completate. Pertanto, questa funzionalità non è utile, anche se è molto predittiva delle tue entrate giornaliere. A questo proposito, quando addestri un modello e ottieni metriche di valutazione straordinarie (ad esempio 0,99 AUC), cerca questo tipo di funzionalità che possono trasmettersi alla tua etichetta.
Verificare la presenza di perdite di etichette
Per perdita di etichette si intende che le etichette basate su dati empirici reali che stai traventando di prevedere sono state inserite inavvertitamente nelle funzionalità di addestramento. A volte è molto difficile rilevare la fuga di etichette.
Esercizio: verifica di aver compreso
Supponiamo di creare un modello di classificazione binaria per prevedere se un nuovo paziente dell'ospedale ha o meno il cancro. Il modello utilizza funzionalità come:
- 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 il cancro?
Suddividi attentamente i dati, assicurandoti che il set di addestramento sia ben distinto dal set di convalida e dal set di test. Il modello ha un rendimento molto buono sul set di validazione e sul set di test; le metriche sono fantastiche. Purtroppo, il modello ha un rendimento pessimo sui nuovi pazienti nel mondo reale.
Risposta: una delle funzionalità del modello è il nome dell'ospedale. Alcuni ospedali sono specializzati nella cura del cancro. Durante l'addestramento, il modello ha appreso rapidamente che i pazienti assegnati a determinati ospedali avevano molto probabilmente un cancro. Di conseguenza, il nome dell'ospedale è diventato un elemento molto importante.
Al momento dell'inferenza, la maggior parte dei pazienti non era ancora stata assegnata a un ospedale. Dopotutto, lo scopo del modello era diagnosticare la presenza o l'assenza di cancro e poi utilizzare questa diagnosi per assegnare il paziente a un ospedale appropriato. Di conseguenza, durante l'inferenza, la caratteristica del nome dell'ospedale non era ancora disponibile e il modello è stato costretto a fare affidamento su altre caratteristiche.
Monitora l'età del modello in tutta la pipeline
Se i dati di pubblicazione si evolvono nel tempo, ma il modello non viene addestrato regolarmente, la qualità del modello peggiorerà. Monitora il tempo trascorso dall'addestramento nuovamente del modello su nuovi dati e imposta una soglia di età per gli avvisi. Oltre a monitorare la data di creazione del modello al momento della pubblicazione, devi monitorare la data di creazione del modello in tutta la pipeline per rilevare eventuali arresti anomali della pipeline.
Verificare che i pesi e gli output del modello siano numericamente stabili
Durante l'addestramento del modello, i pesi e le uscite degli strati non devono essere NaN (not a number) o Inf (infinito). Scrivi test per verificare la presenza di valori NaN e Inf per i pesi e le uscite dei livelli. Inoltre, verifica che più della metà delle uscite di un livello non sia pari a zero.
Monitorare il rendimento del modello
Il tuo strumento di previsione dell'apparizione degli unicorni ha riscosso un successo maggiore del previsto. Ricevi molte richieste di previsione e ancora più dati di addestramento. Ti sembra fantastico finché non ti rendi conto che il tuo modello richiede sempre più memoria e tempo per l'addestramento. Decidi di monitorare le prestazioni del tuo modello seguendo questi passaggi:
- Monitora le prestazioni del modello in base alle versioni di codice, modello e dati. Questo monitoraggio consente di individuare con precisione la causa esatta di eventuali cali del rendimento.
- Testa i passaggi di addestramento al secondo per una nuova versione del modello rispetto alla versione precedente e a una soglia fissa.
- Individua le perdite di memoria impostando una soglia per l'utilizzo della memoria.
- Monitora i tempi di risposta delle API e tieni traccia dei relativi percentile. Anche se i tempi di risposta dell'API potrebbero non essere sotto il tuo controllo, risposte lente potrebbero causare metriche reali scadenti.
- Monitora il numero di query a cui viene data risposta al secondo.
Testare la qualità del modello in tempo reale 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? La qualità del modello pubblicato peggiorerà. Tuttavia, testare la qualità nella pubblicazione è difficile perché i dati reali non sono sempre etichettati. Se i dati di pubblicazione non sono etichettati, prendi in considerazione questi test:
Esamina i modelli che mostrano un bias statistico significativo nelle previsioni. Consulta Classificazione: bias di previsione.
Monitora le metriche reali del tuo modello. Ad esempio, se stai classificando lo spam, confronta le tue previsioni con lo spam segnalato dagli utenti.
Mitiga la potenziale divergenza tra i dati di addestramento e di pubblicazione pubblicando una nuova versione del modello su una parte delle query. Man mano che convalidi il nuovo modello di pubblicazione, passa gradualmente tutte le query alla nuova versione.
Quando utilizzi questi test, ricordati di monitorare sia il peggioramento improvviso sia quello lento della qualità della previsione.
Visualizzazione casuale
Rendi riproducibile la pipeline di generazione dei dati. Supponiamo che tu voglia aggiungere una funzionalità per vedere in che modo influisce sulla qualità del modello. Per un esperimento equo, i set di dati devono essere identici, tranne per questa nuova funzionalità. In questo spirito, assicurati che qualsiasi randomizzazione nella generazione dei dati possa essere fatta in modo deterministico:
- Definisci un seed per i generatori di numeri casuali (RNG). La definizione del seed garantisce che la RNG giri gli stessi valori nello stesso ordine ogni volta che viene eseguita, ricreando il set di dati.
- Utilizza chiavi hash invariate. L'hashing è un modo comune per suddividere o campionare i dati. Puoi sottoporre ad hashing ogni esempio e utilizzare l'intero risultante per decidere in quale suddivisione inserire l'esempio. Gli input della funzione di hashing non devono cambiare ogni volta che esegui il programma di generazione dei dati. Non utilizzare nel tuo hash l'ora corrente o un numero casuale, ad esempio se vuoi riprodurre gli hash su richiesta.
Gli approcci precedenti si applicano sia al campionamento sia alla suddivisione dei dati.
Considerazioni per l'hashing
Immagina di nuovo di raccogliere query di ricerca e di utilizzare l'hashing per includere o escludere le query. Se la chiave hash ha utilizzato solo la query, in più giorni di dati, la query verrà sempre inclusa o sempre esclusa. Includere o escludere sempre una query è un errore perché:
- Il set di addestramento visualizzerà un insieme di query meno diversificato.
- I set di valutazione saranno artificialmente difficili, perché non si sovrappongono ai dati di addestramento. In realtà, al momento della pubblicazione, avrai osservato parte del traffico in tempo reale nei dati di addestramento, pertanto la valutazione dovrebbe rispecchiarlo.
In alternativa, puoi eseguire l'hashing su query + data, il che comporterà un hashing diverso ogni giorno.
