Costruire sistemi ML migliori – Capitolo 4. Deployment del modello e oltre

Creazione di migliori sistemi ML - Capitolo 4. Implementazione del modello e oltre

Riguardo al deployment, monitoraggio, variazioni nella distribuzione dei dati, aggiornamenti del modello e test in produzione.

Implementare modelli e supportarli in produzione riguarda più l’ingegneria che l’apprendimento automatico.

Quando un progetto di ML si avvicina alla produzione, sempre più persone si coinvolgono: ingegneri di backend, ingegneri di frontend, ingegneri di dati, DevOps, ingegneri di infrastruttura…

Scegliamo memorie per i dati, introduciamo flussi di lavoro e pipeline, integriamo il servizio nel backend e nel codice dell’interfaccia utente, automatizziamo le release, facciamo backup e rollback, decidiamo sulle istanze di calcolo, impostiamo il monitoraggio e le notifiche… Oggi, letteralmente nessuno si aspetta che uno scienziato dei dati o ingegnere di ML faccia tutto. Anche in una piccola startup, le persone sono specializzate fino a un certo punto.

“Perché uno scienziato dei dati o ingegnere di ML dovrebbe conoscere la produzione?” – potresti chiedere.

• IA generativa per la rivitalizzazione linguistica
• Questo articolo di intelligenza artificiale introduce il Metodo COVE un nuovo approccio di intelligenza artificiale per affrontare l’allucinazione nei modelli di linguaggio attraverso l’autoverifica.
• API di accesso ai dati su tabelle Data Lake senza complessità

Ecco la mia risposta:

Avere il modello in produzione non significa aver finito tutti i compiti correlati all’ML. Ah! Nemmeno lontanamente. È ora di affrontare un nuovo set completo di sfide: come valutare il tuo modello in produzione e monitorarne l’accuratezza, come rilevare variazioni nella distribuzione dei dati e affrontarle, con quale frequenza riaddestrare il modello e come assicurarsi che un modello appena addestrato sia migliore. Ci sono modi, e li analizzeremo ampiamente.

In questo articolo, mi concentrerò intenzionalmente solo su argomenti di ML e ometterò molti concetti di ingegneria o li tratterò a un livello elevato – per mantenerlo semplice e comprensibile per persone con diversi livelli di esperienza.

Questo è il finale della serie “Costruire sistemi di ML migliori”. L’obiettivo della serie è aiutarti a padroneggiare l’arte, la scienza e (a volte) la magia della progettazione e costruzione di sistemi di apprendimento automatico. Nei capitoli precedenti, abbiamo già parlato di pianificazione dei progetti e valore aziendale (Capitolo 1); raccolta dati, etichettatura e convalida (Capitolo 2); sviluppo del modello, monitoraggio degli esperimenti e valutazione offline … (Capitolo 3). Se ti sei perso i post precedenti, ti consiglio di dar loro una lettura prima o dopo aver letto questo.

Deployment

Quando si effettua il deployment di un modello in produzione, sorgono due domande importanti:

1. Il modello deve restituire previsioni in tempo reale?
2. Il modello può essere implementato nel cloud?

La prima domanda ci costringe a scegliere tra inferenza in tempo reale e batch, mentre la seconda domanda ci costringe a scegliere tra cloud e informatica edge.

Tuttavia, per molte aziende, l’inferenza in tempo reale fa la differenza in termini di accuratezza e ricavi. Questo è vero per i motori di ricerca, i sistemi di raccomandazione e le previsioni di clic sugli annunci. Pertanto, investire nell’infrastruttura di inferenza in tempo reale è più che giustificato.

Per ulteriori dettagli sull’inferenza in tempo reale rispetto a quella a batch, consulta questi post: – Rilasciare modelli di apprendimento automatico in ambienti di produzione di Microsoft- Inferenza a batch vs Inferenza online di Luigi Patruno

Calcolo cloud vs Calcolo edge

Nel calcolo cloud, i dati vengono di solito trasferiti su Internet e elaborati su un server centralizzato. D’altra parte, nel calcolo edge i dati vengono elaborati sul dispositivo in cui sono stati generati, con ogni dispositivo che gestisce i propri dati in modo decentralizzato. Esempi di dispositivi edge sono telefoni cellulari, laptop e automobili.

Servizi di streaming come Netflix e YouTube eseguono tipicamente i loro sistemi di raccomandazione nel cloud. Le loro app e i loro siti web inviano i dati degli utenti ai server dati per ottenere raccomandazioni. Il calcolo cloud è relativamente facile da configurare e puoi scalare le risorse di calcolo quasi indefinitamente (o almeno finché è economicamente sensato). Tuttavia, l’infrastruttura cloud dipende pesantemente da una connessione Internet stabile e i dati sensibili degli utenti non dovrebbero essere trasferiti su Internet.

Il calcolo edge è stato sviluppato per superare i limiti del cloud e può funzionare dove il calcolo cloud non può. Il motore di guida autonoma viene eseguito sull’auto, quindi può funzionare rapidamente anche senza una connessione Internet stabile. I sistemi di autenticazione degli smartphone (come FaceID dell’iPhone) vengono eseguiti sugli smartphone perché trasferire dati sensibili degli utenti su Internet non è una buona idea e gli utenti devono sbloccare i loro telefoni senza una connessione Internet. Tuttavia, per rendere il calcolo edge fattibile, il dispositivo edge deve essere sufficientemente potente o, in alternativa, il modello deve essere leggero e veloce. Questo ha dato origine ai metodi di compressione dei modelli, come l’approssimazione a basso rango, la distillazione della conoscenza, la potatura e la quantizzazione. Se desideri saperne di più sulla compressione del modello, qui è un ottimo punto di partenza: Awesome ML Model Compression.

Per approfondire il calcolo edge e il calcolo cloud, leggi questi post: – Qual è la differenza tra calcolo edge e calcolo cloud? di NVIDIA- Calcolo edge vs Calcolo cloud: principali differenze di Mounika Narang

Deployment e Demo semplici

“La produzione è uno spettro. Per alcune squadre, la produzione significa generare bei grafici dai risultati dei notebook da mostrare al team aziendale. Per altre squadre, la produzione significa mantenere i tuoi modelli attivi e in funzione per milioni di utenti al giorno.” Chip Huyen, Perché gli scienziati dei dati non dovrebbero dover conoscere Kubernetes

La distribuzione di modelli per servire milioni di utenti è compito di un team numeroso, quindi come scienziato dei dati / ingegnere di apprendimento automatico, non sarai lasciato da solo.

Tuttavia, a volte devi fare il deployment da solo. Forse stai lavorando su un progetto personale o di studio e desideri creare una demo. Forse sei il primo scienziato dei dati / ingegnere di apprendimento automatico dell’azienda e hai bisogno di apportare qualche valore commerciale prima che l’azienda decida di scalare il team di Data Science. Forse tutti i tuoi colleghi sono così occupati con i loro compiti che ti stai chiedendo se è più facile fare il deployment da solo anziché aspettare il supporto. Non sei il primo e sicuramente non sarai l’ultimo a dover affrontare queste sfide, e ci sono soluzioni che possono aiutarti.

Per effettuare il deployment di un modello, hai bisogno di un server (istanza) dove il modello verrà eseguito, di un’API per comunicare con il modello (inviare input, ottenere previsioni) e (opzionalmente) di un’interfaccia utente per accettare input dagli utenti e mostrare loro le previsioni.

Google Colab è Jupyter Notebook su steroidi. È uno strumento fantastico per creare demo che puoi condividere. Non richiede alcuna installazione specifica da parte degli utenti, offre server gratuiti con GPU per eseguire il codice e puoi facilmente personalizzarlo per accettare qualsiasi input dagli utenti (file di testo, immagini, video). È molto popolare tra gli studenti e i ricercatori di ML (ecco come lo usano i ricercatori di DeepMind). Se sei interessato a saperne di più su Google Colab, inizia da qui.

FastAPI è un framework per la creazione di API in Python. Avrai sentito parlare di Flask, FastAPI è simile, ma più semplice da codificare, più specializzato per le API e più veloce. Per maggiori dettagli, consulta la documentazione ufficiale. Per esempi pratici, leggi API per il servizio di modelli di Goku Mohandas.

Streamlit è uno strumento semplice per creare applicazioni web. È facile, lo intendo davvero. E le applicazioni si rivelano essere piacevoli e interattive, con immagini, grafici, finestre di input, pulsanti, slider… Streamlit offre una Cloud Community dove puoi pubblicare app gratuitamente. Per iniziare, consulta il tutorial ufficiale.

Piattaforme Cloud. Google e Amazon fanno un ottimo lavoro nel rendere il processo di deployment indolore e accessibile. Offrono soluzioni complete a pagamento per addestrare e distribuire modelli (archiviazione, istanze di calcolo, API, strumenti di monitoraggio, flussi di lavoro…). Le soluzioni sono facili da avviare e offrono anche una vasta funzionalità per supportare esigenze specifiche, quindi molte aziende costruiscono la propria infrastruttura di produzione con i provider cloud.

Se desideri saperne di più, ecco le risorse da consultare: – Deploy dei tuoi progetti secondari in grande scala praticamente gratuitamente di Alex Olivier – Deploy di modelli per l’inferenza di Amazon – Deploy di un modello su un endpoint di Google

Monitoraggio

Come tutti i sistemi software in produzione, i sistemi di apprendimento automatico devono essere monitorati. Ciò aiuta a individuare e localizzare rapidamente bug e impedire fallimenti catastrofici del sistema.

Tecnicamente, il monitoraggio significa raccogliere log, calcolare metriche da essi e visualizzare queste metriche su dashboard come Grafana, oltre a impostare avvisi quando le metriche escono dai range attesi.

Quali metriche dovrebbero essere monitorate? Poiché un sistema di apprendimento automatico è una sottoclasse di un sistema software, inizia con le metriche operative. Esempi sono l’utilizzo di CPU/GPU della macchina, la sua memoria e lo spazio su disco; il numero di richieste inviate all’applicazione e la latenza di risposta, il tasso di errore e la connettività di rete. Per approfondire il monitoraggio delle metriche operative, consulta l’articolo Introduzione alle Metriche, al Monitoraggio e all’Allarme di Justin Ellingwood.

Mentre le metriche operative riguardano la salute della macchina, della rete e dell’applicazione, le metriche legate all’apprendimento automatico controllano l’accuratezza del modello e la coerenza dei dati di input.

L’accuratezza è la cosa più importante a cui teniamo. Ciò significa che il modello potrebbe comunque restituire previsioni, ma quelle previsioni potrebbero essere completamente errate e non te ne accorgerai fino a quando il modello non viene valutato. Se hai la fortuna di lavorare in un dominio in cui le etichette naturali diventano disponibili rapidamente (come nei sistemi di raccomandazione), raccogli semplicemente queste etichette man mano che arrivano, valuta il modello e continua a farlo. Tuttavia, in molti domini, le etichette potrebbero richiedere molto tempo per arrivare o potrebbero non arrivare affatto. In tali casi, è utile monitorare qualcosa che potrebbe indicare indirettamente una potenziale diminuzione dell’accuratezza.

Perché potrebbe diminuire l’accuratezza del modello? La ragione più diffusa è che i dati di produzione sono cambiati rispetto ai dati di addestramento/test. Nel dominio della Computer Vision, è possibile vedere visivamente che i dati sono cambiati: le immagini sono diventate più scure o più chiare, la risoluzione è cambiata o ora ci sono più immagini al coperto che all’aperto.

Per rilevare automaticamente la deriva dei dati (chiamata anche “cambiamento nella distribuzione dei dati”), monitorare continuamente gli input e gli output del modello. Gli input del modello dovrebbero essere coerenti con quelli utilizzati durante l’addestramento; per i dati tabulari, ciò significa che i nomi delle colonne, così come la media e la varianza delle caratteristiche, devono essere gli stessi. È anche utile monitorare la distribuzione delle previsioni del modello. Nelle attività di classificazione, ad esempio, è possibile tenere traccia della proporzione di previsioni per ciascuna classe. Se si verifica un cambiamento significativo, ad esempio se un modello che in precedenza categorizzava il 5% delle istanze come Classe A ora le categorizza come tale al 20%, è un segno che sicuramente è successo qualcosa. Per saperne di più sulla deriva dei dati, leggi questo ottimo articolo di Chip Huyen: Cambiamenti nella distribuzione dei dati e monitoraggio.

C’è molto altro da dire sul monitoraggio, ma dobbiamo proseguire. Puoi controllare questi articoli se hai bisogno di ulteriori informazioni:
– Monitoraggio dei sistemi di apprendimento automatico di Goku Mohandas
– Una guida completa su come monitorare i tuoi modelli in produzione di Stephen Oladele

Aggiornamenti del modello

Se si distribuisce il modello in produzione e non si fa nulla, la sua precisione diminuisce nel tempo. Nella maggior parte dei casi, ciò è spiegato dai cambiamenti nella distribuzione dei dati. I dati di input possono cambiare formato. Il comportamento dell’utente cambia continuamente senza motivi validi. Epidemie, crisi e guerre possono improvvisamente verificarsi e infrangere tutte le regole e le ipotesi che avevano funzionato in precedenza. “Il cambiamento è l’unico costante.” – Eraclito.

Ecco perché i modelli di produzione devono essere aggiornati regolarmente. Ci sono due tipi di aggiornamenti: aggiornamento del modello e aggiornamento dei dati. Durante l’aggiornamento del modello, viene modificato un algoritmo o una strategia di addestramento. L’aggiornamento del modello non è necessario che avvenga regolarmente, di solito viene effettuato ad hoc, quando una specifica attività aziendale cambia, viene trovato un bug o il team ha tempo per la ricerca. In contrasto, l’aggiornamento dei dati avviene quando lo stesso algoritmo viene addestrato su dati più recenti. L’aggiornamento regolare dei dati è un must per qualsiasi sistema di apprendimento automatico.

Un prerequisito per gli aggiornamenti regolari dei dati è l’allestimento di un’infrastruttura in grado di supportare flussi di dati, addestramento, valutazione e distribuzione automatici.

È fondamentale sottolineare che gli aggiornamenti dei dati dovrebbero avvenire con poca o nessuna interazione manuale. Gli sforzi manuali dovrebbero essere riservati principalmente all’annotazione dei dati (assicurandosi che il flusso di dati verso e dall’annotazione sia completamente automatizzato), alla eventuale presa di decisioni finali sulla distribuzione e al risoluzione di eventuali bug che potrebbero emergere durante le fasi di addestramento e distribuzione.

Una volta che l’infrastruttura è stata allestita, la frequenza degli aggiornamenti è semplicemente un valore da regolare nel file di configurazione. Con quale frequenza il modello dovrebbe essere aggiornato con i dati più recenti? La risposta è: il più frequentemente possibile e in modo economicamente sensibile. Se aumentare la frequenza degli aggiornamenti porta più valore rispetto ai costi sostenuti, aumentala sicuramente. Tuttavia, in alcuni scenari, addestrare ogni ora potrebbe non essere fattibile, anche se sarebbe molto redditizio. Ad esempio, se un modello dipende da annotazioni umane, questo processo può diventare un collo di bottiglia.

Ricominciare l’addestramento da zero o sintonizzarsi solo sui nuovi dati? Non è una decisione binaria, ma piuttosto una combinazione di entrambi. Sintonizzare frequentemente il modello ha senso poiché è più conveniente dal punto di vista dei costi e più veloce rispetto all’addestramento da zero. Tuttavia, occasionalmente, è anche necessario ripartire da zero. È fondamentale capire che l’ottimizzazione dei costi e del tempo è la ragione principale per la sintonizzazione. Tipicamente, le aziende iniziano con l’approccio più diretto di addestramento da zero iniziale, incorporando gradualmente la sintonizzazione man mano che il progetto si espande ed evolve.

Per saperne di più sugli aggiornamenti del modello, leggi questo articolo: Ritrotrainare o no? Andiamo analiticamente sugli aggiornamenti del modello di apprendimento automatico di Emeli Dral et al.

Testare in produzione

Prima di distribuire il modello in produzione, è necessario valutarlo attentamente. Abbiamo già discusso dell’evaluazione pre-produzione (offline) nel post precedente (controllare la sezione “Valutazione del modello”). Tuttavia, non si sa mai come il modello si comporterà in produzione fino a quando non viene distribuito. Da qui è nato il testing in produzione, che è anche chiamato valutazione online.

Testare in produzione non significa scambiare in modo imprudente il tuo vecchio e affidabile modello con uno appena addestrato e poi aspettare ansiosamente le prime previsioni, pronti a tornare indietro al minimo intoppo. Non fare mai così. Ci sono strategie più intelligenti e più sicure per testare il tuo modello in produzione senza rischiare di perdere denaro o clienti.

Il test A/B è l’approccio più popolare nell’industria. Con questo metodo, il traffico viene suddiviso casualmente tra modelli esistenti e nuovi in ​​una certa proporzione. Modelli esistenti e nuovi effettuano previsioni per utenti reali, le previsioni vengono salvate e successivamente attentamente ispezionate. È utile confrontare non solo l’accuratezza del modello ma anche alcune metriche legate al business, come conversione o ricavi, che a volte possono essere correlati negativamente con l’accuratezza.

Il test A/B si basa molto sul test delle ipotesi statistiche. Se vuoi saperne di più, ecco il post per te: Test A/B: Guida completa al test statistico di Francesco Casalegno. Per l’implementazione ingegneristica dei test A/B, dai un’occhiata a Modello di test A/B online.

Il rilascio in ombra è il modo più sicuro per testare il modello. L’idea è inviare tutto il traffico al modello esistente e restituire le sue previsioni all’utente finale nel modo solito, e allo stesso tempo, inviare tutto il traffico anche a un nuovo (modello in ombra). Le previsioni del modello in ombra non vengono utilizzate da nessuna parte, vengono solo salvate per analisi future.

Rilascio Canary. Puoi pensare a questo come un test A/B “dinamico”. Un nuovo modello viene rilasciato parallelamente a quello esistente. All’inizio solo una piccola percentuale del traffico viene inviata al nuovo modello, ad esempio il 1%; il restante 99% è ancora gestito dal modello esistente. Se le prestazioni del nuovo modello sono abbastanza buone, la sua percentuale di traffico viene aumentata gradualmente ed esaminata nuovamente, e aumentata nuovamente ed esaminata, fino a quando tutto il traffico viene gestito da un nuovo modello. Se in qualche fase, il nuovo modello non funziona bene, viene rimosso dalla produzione e tutto il traffico viene direzionato nuovamente al modello esistente.

Ecco il post che lo spiega un po’ meglio: Rilascio in ombra vs Rilascio Canary dei modelli di ML di Bartosz Mikulski.

Conclusione

In questo capitolo, abbiamo imparato una serie di nuove sfide che sorgono una volta che il modello viene messo in produzione. Le metriche operative e relative all’ML del modello devono essere monitorate continuamente per rilevare e correggere rapidamente eventuali bug che si verificano. Il modello deve essere regolarmente riaddestrato su dati più recenti perché la sua accuratezza diminuisce nel tempo principalmente a causa di cambiamenti nella distribuzione dei dati. Abbiamo discusso delle decisioni di alto livello da prendere prima di mettere in produzione il modello – inferenza in tempo reale vs batch e cloud vs computing edge, ognuno di essi ha i propri vantaggi e limitazioni. Abbiamo trattato gli strumenti per il rilascio e la demo semplici quando in casi sporadici devi farlo da solo. Abbiamo imparato che il modello deve essere valutato in produzione oltre alle valutazioni offline sui dataset statici. Non sai mai come funzionerà il modello in produzione finché non lo rilasci effettivamente. Questo problema ha dato origine a test di produzione “sicuri” e controllati – test A/B, rilasci in ombra e rilasci Canary.

Questo è stato anche l’ultimo capitolo della serie “Costruire Sistemi ML Migliori”. Se sei stato con me fin dall’inizio, ora sai che un sistema ML è molto più di un algoritmo alla moda. Spero davvero che questa serie sia stata utile, abbia ampliato i tuoi orizzonti e ti abbia insegnato come costruire sistemi ML migliori.

Grazie per la lettura!

In caso tu abbia perso i capitoli precedenti, ecco l’elenco completo:

Costruire Sistemi ML Migliori. Capitolo 1: Ogni progetto deve iniziare con un piano.

Sul ciclo di vita del progetto ML, documenti di progettazione, valore aziendale e requisiti. Sull’iniziare piccoli e fallire velocemente.

towardsdatascience.com

Costruire Sistemi di Apprendimento Automatico Migliori. Capitolo 2: Domare il Caos dei Dati.

Riguardo all’IA centrata sui dati, addestramento dei dati, etichettatura e pulizia dei dati, dati sintetici e un po’ di Ingegneria dei Dati…

towardsdatascience.com

Costruire Sistemi di Apprendimento Automatico Migliori – Capitolo 3: Modellazione. Che il divertimento abbia inizio

Riguardo alle basi, tracciamento degli esperimenti, set di test adeguati e metriche. Riguardo a far funzionare l’algoritmo.

towardsdatascience.com