Esempi di MLOps nel mondo reale Pipeline completa di MLOps per la ricerca visuale su Brainly

Esempi di MLOps nel mondo reale Pipeline completa per la ricerca visuale su Brainly.

In questa seconda parte della serie “Esempi di MLOps nel mondo reale”, Paweł Pęczek, Ingegnere di Machine Learning presso Brainly, ti guiderà attraverso il processo end-to-end delle Operazioni di Machine Learning (MLOps) nel team di Ricerca Visiva di Brainly. E poiché per avere successo con MLOps non basta solo avere tecnologie e processi, condividerà anche i dettagli su:

1
Use case di ML di Brainly,
2
Cultura di MLOps,
3
Struttura del team,
4
E le tecnologie che Brainly utilizza per fornire servizi di intelligenza artificiale ai suoi clienti.

Goditi l’articolo!

Avviso legale: Questo articolo si concentra sulla configurazione principalmente dei team di ML in produzione presso Brainly.

Profilo aziendale

Brainly è la principale piattaforma di apprendimento a livello mondiale, con la più ampia base di conoscenze per tutte le materie e i gradi scolastici. Centinaia di milioni di studenti, genitori e insegnanti utilizzano Brainly ogni mese perché è un modo comprovato per aiutarli a comprendere e imparare più velocemente. I loro studenti provengono da più di 35 paesi.

La motivazione dietro MLOps presso Brainly

Per comprendere il percorso di Brainly verso MLOps, è necessario conoscere la motivazione di Brainly nell’adozione di tecnologie di intelligenza artificiale e di machine learning. Al momento della stesura di questo articolo, Brainly ha centinaia di milioni di utenti mensili in tutto il mondo. Con quella scala di utenti mensili attivi e il numero di casi d’uso che rappresentano, le applicazioni di ML possono beneficiare gli utenti in modo significativo rispetto alle risorse educative di Brainly e migliorare le loro competenze e percorsi di apprendimento.

Il prodotto principale di Brainly è la piattaforma di domande e risposte della comunità, dove gli utenti possono fare domande su qualsiasi materia scolastica digitandole, scattando una foto o pronunciandole ad alta voce. Una volta che un utente inserisce l’input, il prodotto fornisce la risposta con spiegazioni passo-passo. Se la risposta non è già presente nella base di conoscenza, Brainly la invia a uno dei membri della comunità per rispondere.

“Costruiamo servizi basati su intelligenza artificiale presso Brainly per potenziare le funzionalità educative e portarle ad un livello superiore – questa è la nostra motivazione principale nel sfruttare la crescita enorme della ricerca correlata all’IA.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Il team di AI e tecnologia di Brainly utilizza il machine learning per fornire agli studenti aiuto personalizzato in tempo reale e accesso ai migliori prodotti educativi del mondo. Gli obiettivi dei team di AI/ML di Brainly sono:

Passare da un sistema di intervento reattivo a uno predittivo che personalizza l’esperienza degli utenti
Risolvere anticipatamente le difficoltà educative future degli utenti
Rendere gli studenti più di successo nel loro percorso educativo

Puoi trovare ulteriori informazioni sulla storia del ML di Brainly in questo articolo.

Casi d’uso di machine learning presso Brainly

Il dipartimento di AI di Brainly mira a costruire un sistema di intervento predittivo per i suoi utenti. Un tale sistema li porta a lavorare su diversi casi d’uso nei seguenti ambiti:

Contenuto: Estrarre attributi del contenuto (ad esempio, attributi di qualità) e arricchimento dei metadati (ad esempio, abbinamento alle risorse del curriculum)
Utenti: Migliorare il profilo di apprendimento degli utenti
Ricerca visiva: Analizzare immagini e convertire foto scattate con la fotocamera in domande che possono essere risposte
Curriculum: Analizzare le sessioni degli utenti e i modelli di apprendimento per costruire sistemi di raccomandazione

Sarebbe difficile approfondire le pratiche di MLOps per ciascun team che lavora su questi ambiti, quindi in questo articolo imparerai come il team di AI per la Ricerca Visiva implementa MLOps nel mondo reale.

Guarda questo video per scoprire come il team di AI per il Contenuto implementa MLOps.

“Se pensi a come gli utenti dei servizi di Brainly formulano le loro ricerche, potresti notare che tendono a preferire metodi di input facili da usare. Questo include non solo la ricerca visiva, ma anche la ricerca vocale e testuale con tipi speciali di segnali che possono essere esplorati con l’AI.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Struttura del team MLOps

Le squadre tecnologiche presso Brainly sono divise in squadre di prodotto e squadre di infrastruttura. La squadra di infrastruttura si concentra sulla tecnologia e fornisce strumenti che altre squadre adatteranno ed utilizzeranno per lavorare sui loro principali risultati.

Oltre alle squadre, ci sono anche dipartimenti. I dipartimenti di DevOps e Automation Ops fanno parte della squadra di infrastruttura. Le squadre di IA/ML sono nel dipartimento dei servizi sotto le squadre di infrastruttura ma sono correlate all’IA, e alcune squadre di IA stanno lavorando su soluzioni basate su ML che i clienti possono utilizzare.

Sulla base del dipartimento di IA si trova la squadra di infrastruttura per l’ML, che standardizza e fornisce soluzioni per le squadre di IA che possono essere adattate. La squadra di infrastruttura per l’ML semplifica il processo per le squadre di IA creando flussi di lavoro di addestramento con strumenti interni che rendono il loro lavoro più facile fornendo soluzioni predefinite sotto forma di infrastruttura come codice che ogni squadra può distribuire autonomamente nei propri ambienti.

Diverse squadre di IA contribuiscono anche alle iniziative di infrastruttura per l’ML. Questo è simile a un sistema open-source interno in cui tutti lavorano sugli strumenti che mantengono.

“Questa configurazione di squadre, in cui abbiamo una squadra di prodotto, una squadra di infrastruttura che si divide in vari dipartimenti e squadre interne che lavorano su pezzi specifici di tecnologia da esporre al prodotto, è piuttosto standard per le grandi aziende tecnologiche.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

La cultura MLOps presso Brainly

I due principi fondamentali della cultura MLOps presso Brainly sono:

1
Dare priorità alla velocità
2
Coltivare la collaborazione, la comunicazione e la fiducia

Dare priorità alla velocità

“Il nostro obiettivo finale è rendere disponibili tutti i componenti infrastrutturali essenziali per le squadre, che dovrebbero essere riutilizzabili. Il nostro obiettivo finale è fornire un modo per le squadre di esplorare e sperimentare, e non appena trovano qualcosa di interessante, spingere immediatamente questi casi d’uso dei clienti.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

L’obiettivo dell’ecosistema MLOps è muoversi il più velocemente possibile e nel tempo imparare a costruire componenti automatizzati più rapidamente. Brainly ha iniziative comuni sotto l’egida del suo dipartimento di infrastruttura nei dipartimenti di IA. Queste iniziative permettono alle squadre di crescere più rapidamente concentrandosi sui loro principali risultati.

“In generale, cerchiamo di essere il più veloci possibile, esponendo il modello al traffico del mondo reale. Senza di questo, il ciclo di feedback sarebbe troppo lungo e dannoso per il nostro flusso di lavoro. Anche dal punto di vista della squadra, di solito vogliamo questo feedback istantaneamente, prima è meglio. Altrimenti, questo processo iterativo di miglioramento dei modelli richiede troppo tempo.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Effetti della priorità alla velocità: Quanto tempo impiega il team per distribuire un modello in produzione?

Durante i primi giorni, quando avevano appena avviato l’iniziativa di standardizzazione, ogni squadra aveva vari standard interni e flussi di lavoro, il che faceva impiegare mesi per distribuire un modello in produzione. Con flussi di lavoro standardizzati tra le squadre e i dati nella forma corretta, la maggior parte delle squadre è di solito pronta a distribuire il proprio modello e incorporarlo come un servizio in poche settimane, se la ricerca va bene, ovviamente.

“Le due fasi che richiedono più tempo all’inizio sono la raccolta di dati significativi e l’etichettatura dei dati. Se la ricerca è completamente nuova e non si hanno altri progetti da cui trarre conclusioni o su cui basare la propria comprensione, lo studio di fattibilità e la ricerca possono richiedere un po’ più di tempo.

Diciamo che le squadre hanno i dati e possono iniziare immediatamente l’etichettatura. In quel caso, tutto va senza intoppi ed in modo efficiente nell’allestimento del processo di sperimentazione e nella costruzione di pipeline di ML, questo avviene quasi istantaneamente. Possono produrre una struttura di codice simile per quel progetto. Anche la manutenzione è piuttosto facile.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Un altro punto critico affrontato dalle squadre era la strutturazione dell’interfaccia di endpoint in modo che i clienti potessero adottare rapidamente la soluzione. Ci vuole tempo per discutere e concordare la migliore interfaccia, ed è un punto critico comune in tutti i settori, non solo nell’apprendimento automatico. Hanno dovuto coltivare una cultura di collaborazione e comunicazione efficaci.

Coltivare la collaborazione, la comunicazione e la fiducia

Dopo aver esposto i servizi legati all’IA, i clienti devono capire come utilizzarli e integrarli correttamente. Ciò comporta sfide interpersonali e si incoraggia le squadre di IA/Apprendimento automatico a costruire buoni rapporti con i clienti per aiutare a supportare i modelli, spiegando alle persone come utilizzare la soluzione anziché semplicemente esporre l’endpoint senza documentazione o istruzioni su come farlo.

Il percorso di Brainly verso MLOps

Sin dai primi giorni di IA su Brainly, le squadre di infrastruttura e ingegneria hanno incoraggiato gli scienziati dei dati e gli ingegneri di apprendimento automatico che lavorano su progetti a utilizzare le migliori pratiche per strutturare i loro progetti e basi di codice.

In questo modo, possono iniziare rapidamente e non avranno bisogno di pagare un grande debito tecnico in futuro. Queste pratiche sono evolute man mano che hanno costruito un flusso di lavoro MLOps più maturo seguendo la “maturità dei livelli” delineata.

“Abbiamo una transizione abbastanza organizzata tra le varie fasi dello sviluppo del nostro progetto, e chiamiamo queste fasi ‘livelli di maturità'”.

– Paweł Pęczek, Ingegnere di Apprendimento Automatico presso Brainly

L’altra pratica che hanno imposto fin dall’inizio era quella di rendere facile per le squadre di IA/Apprendimento automatico iniziare con la pura sperimentazione. A questo livello, le squadre di infrastruttura hanno cercato di non imporre troppo ai ricercatori in modo che potessero concentrarsi sulla ricerca, lo sviluppo dei modelli e la loro consegna.

Impostare il monitoraggio degli esperimenti fin dall’inizio è una buona pratica

“Abbiamo abilitato il monitoraggio degli esperimenti fin dall’inizio del processo di sperimentazione perché credevamo che fosse il fattore chiave che aiutava significativamente la riproducibilità futura della ricerca”.

– Paweł Pęczek, Ingegnere di Apprendimento Automatico presso Brainly

Il team avrebbe creato modelli di ricerca per i ricercatori di dati per avviare le loro basi di codice per casi d’uso speciali. Molte volte, questi modelli contengono tutti i moduli che si integrano con il loro strumento di monitoraggio degli esperimenti, neptune.ai.

Si integrano con neptune.ai in modo fluido con il codice, in modo che tutto sia strutturato in modo chiaro per quanto riguarda i report che inviano a neptune.ai, e le squadre possono recensire e confrontare gli esperimenti prima e dopo l’addestramento.

Livelli di maturità MLOps presso Brainly

Livello MLOps 0: App dimostrativa

Quando gli esperimenti hanno prodotto risultati promettenti, avrebbero immediatamente distribuito i modelli ai clienti interni. Questa è la fase in cui avrebbero esposto l’MVP con l’automazione e il codice di ingegneria strutturato in cima agli esperimenti che hanno eseguito.

“Stiamo utilizzando gli strumenti di automazione interni che abbiamo già per rendere semplice mostrare i nostri endpoint di modello. Facciamo questo in modo che i clienti possano interagire con il servizio, esponendo il modello in modo che possano decidere se funziona per loro. Internamente, chiamiamo questo servizio ‘app dimostrativa'”.

– Paweł Pęczek, Ingegnere di Apprendimento Automatico presso Brainly

Nelle prime iterazioni del loro flusso di lavoro, il team ha creato un’applicazione dimostrativa interna a cui i clienti potevano connettersi tramite codice o un’interfaccia utente web per vedere che tipo di risultati potevano ottenere utilizzando il modello. Non si trattava di un deployment completo in un ambiente di produzione.

“Sulla base dei risultati dell’app dimostrativa, i nostri clienti e le parti interessate decidono se spingere o meno un caso d’uso specifico verso livelli di maturità avanzati. Quando viene presa la decisione, il team dovrebbe distribuire la prima versione matura o completa della soluzione, chiamata ‘release one’.

Oltre a ciò che abbiamo già, abbiamo assemblato pipeline di addestramento automatizzate per addestrare il nostro modello ripetutamente ed eseguire le attività in modo fluido”.

– Paweł Pęczek, Ingegnere di Apprendimento Automatico presso Brainly

Livello MLOps 1: Deployment di produzione con pipeline di addestramento

Man mano che i flussi di lavoro per la sperimentazione e il deployment miglioravano e diventavano standard per ogni team, hanno spostato la loro attenzione nel garantire un buon approccio per il riaddestramento del modello quando arrivavano nuovi dati.

I casi d’uso si sono evoluti nel tempo e, con l’aumento del numero di nuovi dati, il team ha adottato un approccio AI incentrato sui dati, concentrandosi sulla raccolta di dataset e sul loro costante inserimento nelle pipeline invece di cercare di rendere i modelli perfetti o fare troppa ricerca.

Poiché la velocità era importante nella loro cultura, ci si aspettava che utilizzassero strumenti automatizzati per inviare deployment completi all’ambiente di produzione. Con questi strumenti, potevano fare cose come:

Attivare le pipeline che incorporano modelli come servizio
Verificare che la qualità del modello non si sia degradata rispetto a quanto osservato durante l’addestramento

“Esporremo i nostri servizi all’ambiente di produzione e abiliteremo il monitoraggio per assicurarci che nel tempo possiamo osservare ciò che accade. Questo è qualcosa che chiamiamo livello di maturità MLOps uno (1).”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Lo scopo di lavorare a questo livello è garantire che il modello abbia la massima qualità ed eliminare eventuali problemi che potrebbero sorgere durante lo sviluppo. Devono anche monitorare e osservare i cambiamenti nella distribuzione dei dati (scarto dei dati, scarto di concetto, ecc.) durante l’esecuzione dei servizi.

Livello MLOps 2: Chiudere il ciclo di apprendimento attivo

Il livello due (2) di MLOps era il successivo livello di maturità che dovevano raggiungere. A questo livello, avrebbero spostato il modello a un livello più maturo in cui avrebbero potuto chiudere il ciclo di apprendimento attivo se si fosse rivelato vantaggioso dal punto di vista del rendimento dell’investimento (ROI) o se fosse stato necessario per altre ragioni legate ai KPI e alla visione degli stakeholder.

Avrebbero continuamente creato set di dati più grandi e migliori estrarre automaticamente i dati dall’ambiente di produzione, pulirli e, se necessario, inviarli a un servizio di etichettatura. Questi set di dati sarebbero stati inseriti nelle pipeline di addestramento già impostate. Avrebbero anche implementato un monitoraggio più esteso con report migliori inviati giornalmente per assicurarsi che tutto sia in ordine.

Flusso di lavoro di Machine Learning del team di Visual Search

Ecco una panoramica generale del tipico flusso di lavoro di ML nel team:

Prima di tutto, estraggono i dati grezzi dai produttori (eventi, azioni degli utenti nell’app, ecc.) nel loro ambiente di sviluppo
Successivamente, manipolano i dati, ad esempio, modulando il filtro e preelaborandolo nei formati richiesti
A seconda di quanto sviluppata sia la soluzione, etichettano i set di dati, addestrano i modelli utilizzando la pipeline di addestramento o li lasciano come modelli di ricerca

Flusso di lavoro di Machine Learning di Brainly

“Quando il nostro modello è pronto, di solito lo valutiamo. Una volta approvato, avviamo una pipeline di distribuzione automatica e controlliamo nuovamente per assicurarci che la qualità del modello sia buona e per vedere se il servizio garantisce la stessa qualità del modello misurata durante l’addestramento. In tal caso, semplicemente distribuiamo il servizio e monitoriamo per vedere se qualcosa non funziona come previsto. Convalidiamo il problema e agiamo di conseguenza per migliorarlo.”

“Speriamo di spingere il maggior numero possibile di casi d’uso in questo livello di maturità finale, in cui abbiamo chiuso il ciclo di apprendimento attivo e stiamo osservando se tutto va bene.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Ovviamente, chiudere il ciclo per il loro flusso di lavoro richiede sforzo e tempo. Inoltre, alcuni casi d’uso non raggiungeranno mai quel livello di maturità perché è naturale che non ogni idea sia valida e meriti di essere perseguite a quel livello.

Infrastruttura e stack di strumenti MLOps per il team di Visual Search di Brainly

L’infrastruttura e lo stack di strumenti MLOps del team sono divisi in diversi componenti che contribuiscono tutti a aiutarli a lanciare nuovi servizi rapidamente:

1
Dati
2
Sperimentazione e sviluppo del modello
3
Test e convalida del modello
4
Distribuzione del modello
5
Integrazione continua e distribuzione
6
Monitoraggio

L’immagine seguente mostra una panoramica dei diversi componenti e degli strumenti utilizzati dal team:

Stack MLOps del team di Visual Search di Brainly

Diamo un’occhiata più approfondita a ciascun componente.

Infrastruttura e stack di strumenti dati per il team di visual search di Brainly

“Il nostro stack dati varia da un progetto all’altro. Nel team di visione al computer, cerchiamo di utilizzare soluzioni il più semplici possibile. Semplicemente archiviamo i dati in S3, e ciò va bene per noi, oltre ad autorizzazioni che impediscono agli utenti non autorizzati di mutare i set di dati mentre vengono creati.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Il team ha automatizzato le pipeline per estrarre dati grezzi e elaborarli nel formato desiderato per l’addestramento. Cercano di essere il più generici possibile nella elaborazione dei dati senza l’uso di strumenti sofisticati. Hanno costruito su ciò che il team Automation Ops aveva già sviluppato per integrarsi con lo stack tecnologico AWS.

Il team utilizza AWS Batch e Step Functions per eseguire elaborazioni in batch e orchestrazione. Queste soluzioni semplici si concentrano maggiormente sulle funzionalità che il team conosce meglio in Brainly piuttosto che sul funzionamento del servizio.

“Il nostro approccio attuale fa il lavoro, ma non direi che è estremamente esteso o sofisticato. So che altri team utilizzano strumenti di ingegneria dei dati e di ETL processing più di quanto facciamo noi e, rispetto a loro, utilizziamo soluzioni più semplici per curare ed elaborare i nostri set di dati.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Infrastruttura e stack di strumenti per l’esperimento del team di ricerca visiva di Brainly

“Cerchiamo di mantenere le cose il più semplici possibile per gli esperimenti. Eseguiamo l’addestramento su istanze EC2 e AWS SageMaker nella loro configurazione più basilare. Per le pipeline di produzione, aggiungiamo più passaggi, ma non troppi, in modo che SageMaker non venga sovraccaricato.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

L’obiettivo è ridurre al minimo la complessità per consentire ai data scientist di eseguire esperimenti su macchine EC2 o SageMaker con estensioni, rendendo il flusso di lavoro efficiente. Oltre all’infrastruttura, non ci sono molti strumenti tranne neptune.ai, che tiene traccia dei loro esperimenti.

Il team utilizza uno stack tecnologico standard, come librerie per l’addestramento dei modelli e modi semplici e ben noti per elaborare rapidamente ed efficacemente i dataset. Combina le librerie, le esegue su una macchina EC2 o SageMaker e riporta le metriche sperimentali su neptune.ai.

“Ci concentriamo più su come appare il processo scientifico che sulle estensive funzionalità. In futuro, potremmo valutare miglioramenti al nostro processo di sperimentazione, rendendolo più fluido, meno ingombrante, ecc. Attualmente, siamo a posto e abbiamo creato alcune soluzioni per eseguire lavori di addestramento su SageMaker o eseguire facilmente lo stesso codice su macchine EC2.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Mantengono il flusso di lavoro di sperimentazione semplice in modo che i loro data scientist e ricercatori non debbano occuparsi di troppo lavoro di ingegneria. Per loro, funziona sorprendentemente bene, considerando quanto bassa sia la complessità.

“Non vogliamo neanche esplorare le nostre architetture di modelli interni. Se c’è un caso speciale, non c’è un requisito rigoroso per non farlo. In generale, utilizziamo architetture standard delle diverse aree in cui lavoriamo (speech, text e visione) – ConvNets e architetture basate su trasformatori.”

“Non siamo ossessionati da un solo tipo di architettura. Cerchiamo di sperimentare e utilizzare ciò che funziona meglio in contesti specifici.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Framework e librerie per lo sviluppo dei modelli

Il team di visione artificiale utilizza principalmente PyTorch per lo sviluppo dei modelli, ma non è sempre una scelta definitiva. Se la libreria per lo sviluppo dei modelli è buona e il team può addestrare e distribuire modelli con essa, potrebbero utilizzarla.

“Non imponiamo framework di sperimentazione ai team. Se qualcuno vuole utilizzare TensorFlow, può farlo e se qualcuno vuole sfruttare PyTorch, è anche possibile. Ovviamente, all’interno di un team specifico, ci sono accordi interni; altrimenti, sarebbe un disastro collaborare quotidianamente.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Infrastruttura e stack di strumenti per la distribuzione del team di ricerca visiva

Il team utilizza strumenti di distribuzione standard come Flask e altre soluzioni semplici e server di inferenza come TorchServe.

“Utilizziamo ciò che il team Automation Ops ci fornisce. Prendiamo il modello e implementiamo una soluzione standard per il servizio su EKS. Dal nostro punto di vista, è stato più semplice, dato i nostri strumenti di automazione esistenti.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Su Amazon EKS, distribuiscono i servizi utilizzando diverse strategie. In particolare, se i test, le sonde di disponibilità e le sonde di integrità sono configurate correttamente, possono evitare la distribuzione se si verificano problemi. Utilizzano strategie di distribuzione semplici, ma stanno esaminando altre strategie più complesse in futuro se necessario.

Stack di strumenti per l’integrazione e la distribuzione continua del team di ricerca visiva

“Sfruttiamo ampiamente CI/CD nei nostri flussi di lavoro per l’automazione e la creazione di pipeline. Abbiamo alcune aree in cui sfruttiamo ampiamente lo stack di strumenti AWS CI/CD Pipeline.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Il team utilizza le soluzioni che il team Automation Ops ha già fornito per CI/CD. Possono aggiungere CI e CD al codice di sperimentazione con poche righe di codice Terraform. Per quanto riguarda le pipeline per l’addestramento, utilizzano il modulo Terraform per creare CI/CD che inizializzerà le pipeline, le testerà e le distribuirà su SageMaker (Pipelines) se i test hanno successo.

Hanno basi di codice di produzione e di addestramento nei repository GitHub. Ogni volta che modificano il codice, la definizione della pipeline cambia. Ricostruisce l’immagine Docker sottostante ed esegue i passaggi nella pipeline nell’ordine definito. Tutto viene aggiornato e chiunque può eseguire l’addestramento su un nuovo dataset.

Una volta approvato il modello, i segnali dal model registry vengono intercettati dalla pipeline CI/CD e inizia il processo di distribuzione del modello. Un test di integrazione esegue il set di dati di holdout attraverso il servizio di previsione per verificare se le metriche corrispondono a quelle misurate durante la fase di valutazione.

Se il test ha successo, sapranno che non ci sono errori causati da una normalizzazione dei dati di input errata o da bug simili. Se tutto è a posto, metteranno il servizio in produzione.

“Di solito non cerchiamo di utilizzare soluzioni di terze parti estese se AWS fornisce qualcosa di ragionevole, specialmente con la presenza del nostro team Automation Ops che fornisce i moduli che possiamo utilizzare.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Test del modello e approvazione della pipeline CI/CD

“Testiamo i nostri modelli dopo l’addestramento e verifichiamo le metriche, e per quanto riguarda l’ingegneria pura, ci assicuriamo che tutto funzioni senza intoppi. Prendiamo i set di test o i set di dati di hold-out, li inseriamo nel servizio e verifichiamo se i risultati sono gli stessi di prima.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Il team di AI/ML è responsabile per mantenere un insieme sano di test, assicurandosi che la soluzione funzioni come dovrebbe. Per quanto riguarda gli altri team, potrebbero approcciare in modo diverso il testing dei modelli di apprendimento automatico, specialmente nei casi d’uso di apprendimento automatico tabulare, testando sub-popolazioni dei dati.

“È una situazione sana quando gli scienziati dei dati e gli ingegneri di machine learning, in particolare, sono responsabili di fornire test per le funzionalità dei loro progetti. Non avrebbero bisogno di fare affidamento su nient’altro o su nessun altro, e non ci sarebbero accuse o disaccordi. Devono solo fare bene il loro lavoro e dimostrare agli altri che funziona come dovrebbe.”

“Per noi sarebbe difficile raggiungere una completa standardizzazione dei test su tutte le pipeline, ma pipeline simili hanno casi di test simili.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Le strumentazioni per testare il loro codice sono anche semplici: utilizzano PyTest per i test di unità e integrazione e test più sofisticati.

“Il metodo di approvazione del modello dipende dal caso d’uso. Credo che alcuni casi d’uso siano così maturi che i team possono semplicemente concordare di ottenere un’approvazione automatica, che avverrebbe dopo aver raggiunto una determinata soglia di performance.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

La maggior parte delle volte, l’utente (l’ingegnere di machine learning o lo scienziato dei dati) deve tenere d’occhio il processo di verifica del modello. Per rendere il processo più coerente, hanno creato un manuale di manutenzione con istruzioni chiare su cosa doveva essere controllato e fatto per garantire che il modello soddisfacesse determinati standard di qualità.

Non sarebbe sufficiente verificare solo le metriche; dovrebbero essere controllate anche altre caratteristiche qualitative del modello. Se tutto ciò viene completato e il modello è relativamente corretto, premeranno il pulsante di approvazione e da quel momento in poi verrà attivata la pipeline CI/CD automatizzata.

Gestione dei modelli e delle pipeline in produzione

La gestione dei modelli dipende molto dal contesto per i diversi team di AI/ML. Ad esempio, quando il team di visione artificiale lavora con dati di immagini che richiedono etichettatura, la gestione del modello in produzione sarà diversa rispetto al lavoro con dati tabulari che vengono elaborati in altro modo.

“Cerchiamo di tenere d’occhio eventuali modifiche nel funzionamento dei nostri servizi, quanto bene i nostri modelli predicono o come cambiano le statistiche dei dati registrati in produzione. Se rileviamo un degrado, approfondiremo un po’ i dati e se troviamo qualcosa di sbagliato, raccoglieremo e etichetteremo nuovi dataset.

In futuro, vorremmo portare più casi d’uso al livello di maturità MLOps due (2), dove più cose relative ai dati e al monitoraggio verranno fatte automaticamente.”

– Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

I clienti misurano anche i loro KPI e il team può essere avvisato se qualcosa va storto.

Strumenti di monitoraggio e governance del modello

Per ottenere le metriche delle prestazioni del servizio, il team utilizza Grafana per osservare le statistiche del modello e soluzioni standard di logging e monitoraggio su Amazon Elastic Kubernetes Service (Amazon EKS). Utilizzano Prometheus per aggiungere statistiche su come funzionano i servizi e renderle disponibili come serie temporali. Questo rende facile aggiungere nuovi pannelli di controllo, monitorarli e ricevere avvisi.

Il team di Automation Ops fornisce pacchetti per il monitoraggio dei servizi, il che giustifica la decisione del team di rendere il loro stack il più semplice possibile per adattarsi al loro ecosistema di ingegneria esistente.

“È ragionevole non investire eccessivamente in strumenti diversi se si dispone già di buoni strumenti.”

— Paweł Pęczek, Ingegnere di Machine Learning presso Brainly

Nel caso della governance del modello, il team è principalmente preoccupato per il GDPR e per assicurarsi che i loro dati siano censurati in qualche misura. Ad esempio, non vorrebbero che le informazioni personali fossero divulgate ai labeler o il contenuto dannoso fosse divulgato agli utenti. Filtrerebbero e modererebbero il contenuto come parte del loro caso d’uso.

Ecco tutto! Se vuoi saperne di più sull’ecosistema tecnologico di Brainly, dai un’occhiata al loro blog tecnologico.

Grazie a Paweł Pęczek e al team di Brainly per aver collaborato con noi per creare questo articolo!

MLOps