Complimenti! Hai eseguito il deployment del modello unicorno. Il modello dovrebbe essere eseguito 24 ore su 24, 7 giorni su 7, senza problemi. Per verificarlo, devi monitorare la pipeline di machine learning (ML).
Scrivi uno schema di dati per convalidare i dati non elaborati
Per monitorare i dati, devi verificarli continuamente rispetto alle previsioni i valori statistici scrivendo regole che i dati devono soddisfare. Questa raccolta di regole è chiamato schema dei dati. Definisci uno schema di dati come segue: questi passaggi:
Comprendi l'intervallo e la distribuzione delle caratteristiche. Per categorie caratteristiche, comprendere l'insieme di valori possibili.
Codifica le tue conoscenze nello schema dei dati. Di seguito sono riportati alcuni esempi regole:
- Assicurati che le valutazioni inviate dagli utenti siano sempre comprese tra 1 e 5.
- Controlla che la parola the sia utilizzata più frequentemente (per un testo in inglese ).
- Controllare che ogni caratteristica categorica sia impostata su un valore di un insieme fisso di valori possibili.
Testa i tuoi dati in base allo schema dei dati. Il tuo schema dovrebbe acquisire dati errori quali:
- Anomalie
- Valori imprevisti delle variabili categoriche
- Distribuzioni di dati impreviste
Scrivere test delle unità per convalidare il feature engineering
Anche se i dati non elaborati potrebbero passare lo schema dei dati, il modello non viene addestrato su dati non elaborati. Piuttosto, il modello si addestra sui dati che sono stati caratteristiche che è stato progettato. Ad esempio, il modello viene addestrato su caratteristiche numeriche normalizzate piuttosto che su dati numerici non elaborati. Poiché i dati con feature engineering possono essere molto diversi dai dati di input non elaborati, devi controllare i dati separatamente dai controlli sui dati di input non elaborati.
Scrivere i test delle unità in base alla tua comprensione dei dati sottoposti a feature engineering. Ad esempio, puoi scrivere test delle unità per verificare condizioni come seguenti:
- Tutte le caratteristiche numeriche vengono scalate, ad esempio tra 0 e 1.
- Codifica one-hot contengono solo un singolo zeri 1 e N-1.
- Le distribuzioni dei dati dopo la trasformazione sono conformi alle aspettative. Ad esempio, se hai normalizzato con i punteggi z, la media del I punteggi z devono essere 0.
- Valori anomali sono gestiti, ad esempio mediante la scalabilità o ritaglio.
Controlla le metriche per le sezioni di dati importanti
Un intero successo a volte oscura un sottoinsieme infruttuoso. In altre parole, un modello con ottime metriche complessive potrebbe comunque fare previsioni peggiori per determinate situazioni. Ad esempio:
Il modello unicorno funziona bene nel complesso, ma non quando fare previsioni per il deserto del Sahara.
Se sei il tipo di ingegnere soddisfatto di un'ottima AUC complessivamente, allora potresti non notare i problemi del modello nel deserto del Sahara. Se effettui è importante che le previsioni siano buone per ogni regione, allora devi monitorare il rendimento per ogni regione. Sottoinsiemi di dati, come quello corrispondente al deserto del Sahara sono chiamate sezioni di dati.
Identificare le sezioni di dati di interesse. Poi confronta le metriche del modello per queste sezioni di dati con le metriche per l'intero set di dati. Verifica delle prestazioni del modello su tutte le sezioni di dati aiuta a rimuovere i pregiudizi. Consulta Equità: valutazione dei bias per ulteriori informazioni.
Utilizza metriche reali
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, la modifica ha influito sull'esperienza utente? Per misurare l'impatto reale, è necessario per definire metriche separate. Ad esempio, puoi eseguire un sondaggio sugli utenti del tuo modello per confermare che avevano davvero visto un unicorno quando il modello ha previsto .
Controlla il disallineamento addestramento/distribuzione
Disallineamento addestramento/distribuzione significa che i dati di input durante l'addestramento differiscono dai dati di input nella pubblicazione. Nella tabella seguente vengono descritti i due tipi importanti di disallineamento:
| Tipo | Definizione | Esempio | Soluzione |
|---|---|---|---|
| Disallineamento schema | I dati di input di addestramento e pubblicazione non sono conformi allo stesso schema. | Il formato o la distribuzione delle modifiche ai dati di pubblicazione mentre il modello continua ad addestrarsi sui vecchi dati. | Utilizza lo stesso schema per convalidare i dati di addestramento e pubblicazione. Assicurati di controllare separatamente le statistiche non controllate da del tuo schema, ad esempio la frazione dei valori mancanti |
| Disallineamento delle caratteristiche | I dati ingegnerizzati differiscono tra addestramento e pubblicazione. | Il codice di feature engineering differisce tra addestramento e distribuzione, per produrre diversi dati progettati. | Analogamente al disallineamento schema, applica le stesse regole statistiche nell'addestramento e la pubblicazione di dati progettati. Monitora il numero delle caratteristiche disallineate rilevate e il rapporto di esempi disallineati per caratteristica. |
Le cause di un disallineamento addestramento/produzione possono essere lievi. Considera sempre quali dati sono disponibili per il tuo modello al momento della previsione. Durante l'addestramento, utilizza solo le caratteristiche che avrai a disposizione durante la pubblicazione.
Allenamento: verifica le tue conoscenze
Supponiamo che tu abbia un negozio online e voglia prevedere quanto guadagnerai in un dato giorno. Il tuo obiettivo ML è prevedere le entrate utilizzando il numero di clienti come caratteristica.
Risposta: il problema è che non conosci di clienti al momento della previsione, prima che le vendite del giorno siano completato. Pertanto, questa funzione non è utile, anche se è Una forte previsione delle entrate giornaliere. In modo correlato, addestrare un modello e ottenere metriche di valutazione sorprendenti (come 0,99 AUC), alla ricerca di questi tipi di caratteristiche che possono penetrare nell'etichetta.
Controllare la presenza di perdite di etichette
Fuoriuscita di etichette indica che dati empirici reali indica che stai di prevedere di essere entrati inavvertitamente nelle caratteristiche di addestramento. Etichetta a volte è molto difficile da rilevare.
Allenamento: verifica le tue conoscenze
Supponiamo di creare un modello di classificazione binaria per prevedere se un nuovo paziente ospedale ha il cancro. Il modello utilizza caratteristiche come le seguenti:
- Età del paziente
- Genere del paziente
- Condizioni mediche precedenti
- Nome dell'ospedale
- Segni vitali
- Risultati del test
- Ereditarietà
L'etichetta è la seguente:
- Booleano: il paziente è affetto da cancro?
Esegui con attenzione il partizionamento dei dati, assicurandoti che il set di addestramento sia ben organizzato ed è isolato dal set di convalida e dal set di test. Il modello esegue essere estremamente ben sul set di convalida e sul set di test; le metriche sono fantastico. Purtroppo, il modello ha prestazioni terribilmente sui nuovi pazienti nel mondo reale.
Risposta: una delle caratteristiche del modello è il nome dell'ospedale. Alcuni ospedali sono specializzati nella cura del cancro. Durante l'addestramento, ha imparato rapidamente che i pazienti assegnati a determinati ospedali aveva il cancro. Quindi, il nome dell'ospedale è diventato una caratteristica molto ponderata.
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 assenza di cancro e usare questa diagnosi per assegnare al paziente presso un ospedale appropriato. Di conseguenza, durante l'inferenza, la funzionalità nome ospedale non era ancora disponibile e il modello è stato forzato per fare affidamento su altre funzionalità.
Monitora l'età del modello in tutta la pipeline
Se i dati di servizio si evolvono nel tempo, ma il modello non viene riaddestrato regolarmente, una diminuzione della qualità del modello. Monitora il tempo trascorso da quando il modello è stato riaddestrati con nuovi dati e imposta una soglia di età per gli avvisi. Oltre a monitorare il l'età del modello al momento della pubblicazione, devi monitorarla in tutta la pipeline per rilevare i blocchi della pipeline.
Testa che i pesi e gli output del modello sono numericamente stabili
Durante l'addestramento del modello, gli output dei pesi e degli strati non devono essere NaN (non un numero) o Inf (infinito). Scrivi test per verificare i valori NaN e Inf dei tuoi pesi e degli output degli strati. Inoltre, verifica che più della metà degli output di un livello non siano pari a zero.
Monitora le prestazioni del modello
Il tuo strumento di previsione dell'aspetto da unicorno è stato più popolare del previsto! Stai un numero elevato di richieste di previsione e ancora più dati di addestramento. Pensi che È un ottimo risultato finché non ti rendi conto che il modello occupa sempre più memoria e tempi di 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 tipo di monitoraggio consente di individuare la causa esatta di un peggioramento delle prestazioni.
- Testa i passaggi di addestramento al secondo per una nuova versione del modello rispetto rispetto alla versione precedente e rispetto a una soglia fissa.
- Rileva le fughe di memoria impostando una soglia per l'utilizzo della memoria.
- Monitora i tempi di risposta delle API e i relativi percentili. Mentre la risposta dell'API potrebbero essere fuori dal tuo controllo, risposte lente potrebbero causare metriche reali di scarsa qualità.
- Monitora il numero di query con risposta al secondo.
Testa la qualità del modello pubblicato sui dati pubblicati
Hai convalidato il modello. E se scenari del mondo reale, come ad esempio gli unicorni, comportamento, cambiare dopo la registrazione dei dati di convalida? Quindi la qualità del modello pubblicato si ridurrà. Tuttavia, il test della qualità nella pubblicazione è difficile perché e i dati reali non sempre sono etichettati. Se i dati pubblicati non sono etichettati, prendi in considerazione questi test:
Analizzare i modelli che mostrano bias statistici significativi nelle previsioni. Consulta Classificazione: previsione Pregiudizi.
Tenere traccia delle metriche reali per il tuo modello. Ad esempio, se classifichi lo spam, confronta le tue previsioni con quello segnalato dall'utente.
Riduci le potenziali divergenza tra l'addestramento e la distribuzione dei dati per la pubblicazione di una nuova versione del modello su una frazione delle tue query. Al momento della convalida il nuovo modello di pubblicazione, passa gradualmente tutte le query alla nuova versione.
Utilizzando questi test, ricordati di monitorare il deterioramento sia improvviso che lento della e la qualità della previsione.
Visualizzazione casuale
Rendi riproducibile la tua pipeline di generazione dei dati. Supponiamo di voler aggiungere un elemento per vedere come influisce sulla qualità del modello. Per un esperimento equo, i tuoi set di dati saranno identiche, tranne che per questa nuova funzionalità. In questa prospettiva, assicurati che ogni fase della generazione di dati sia casuale deterministico:
- Generare i generatori di numeri casuali (RNG). Il seeding assicura che l'RNG restituisce gli stessi valori nello stesso ordine ogni volta che la esegui, ricreando il tuo set di dati.
- Usa chiavi hash invarianti. L'hashing è un modo comune per suddividere o dati di esempio. Puoi eseguire l'hashing di ogni esempio e utilizzare il numero intero risultante decidi in quale suddivisione posizionare l'esempio. Gli input della funzione hash non dovrebbe cambiare ogni volta che esegui il programma di generazione dei dati. Non utilizzare l'ora corrente o un numero casuale nell'hash, ad esempio, se vuoi ricreare gli hash on demand.
Gli approcci descritti in precedenza si applicano sia al campionamento che alla suddivisione dei dati.
Considerazioni sull'hashing
Immagina di nuovo di raccogliere le query di ricerca e di usare l'hashing per includere o escludere le query. Se la chiave hash ha usato solo la query, quindi, per più giorni di dati, includerai sempre la query o escluderla sempre. Sempre incluso o sempre escluso una query non è valida perché:
- Il set di addestramento vedrà un insieme meno diversificato di query.
- I set di valutazione saranno artificialmente complessi, perché non che si sovrappongono ai dati di addestramento. In realtà, al momento della pubblicazione visto una parte del traffico in tempo reale nei dati di addestramento, quindi la valutazione dovrebbe riflettere questo aspetto.
Puoi invece eseguire l'hashing sulla query + la data, il che comporterebbe un diverso hashing ogni giorno.
