Le cose da fare e da non fare della ricerca sull’apprendimento automatico 

L’apprendimento automatico sta diventando uno strumento importante in molti settori e campi della scienza. Ma la ricerca ML e lo sviluppo del prodotto presentano diverse sfide che, se non affrontate, possono portare il tuo progetto nella direzione sbagliata.

In un  articolo  pubblicato di recente sul server di prestampa arXiv, Michael Lones, professore associato presso la School of Mathematical and Computer Sciences, Heriot-Watt University, Edimburgo, fornisce un elenco di cose da fare e da non fare per la ricerca sull’apprendimento automatico.

 
Il documento, che Lones descrive come “lezioni apprese durante la ricerca sul machine learning nel mondo accademico e durante la supervisione degli studenti che svolgono ricerche sul machine learning”, copre le sfide delle diverse fasi del ciclo di vita della ricerca sull’apprendimento automatico. Sebbene rivolte ai ricercatori accademici, le linee guida del documento sono utili anche per gli sviluppatori che stanno creando modelli di apprendimento automatico per applicazioni del mondo reale .

Ecco le mie conclusioni dal documento, anche se consiglio a chiunque sia coinvolto nella ricerca e nello sviluppo dell’apprendimento automatico di leggerlo per intero.

Presta particolare attenzione ai dati
I modelli di machine learning  vivono e prosperano sui dati. Di conseguenza, in tutto il documento, Lone ribadisce l’importanza di prestare maggiore attenzione ai dati in tutte le fasi del ciclo di vita del machine learning. Devi stare attento a come raccogli e prepari i tuoi dati e come li usi per addestrare e testare i tuoi modelli di machine learning.

Nessuna quantità di potenza di calcolo e tecnologia avanzata può aiutarti se i tuoi dati non provengono da una fonte affidabile e non sono stati raccolti in modo affidabile. E dovresti anche usare la tua due diligence per verificare la provenienza e la qualità dei tuoi dati. “Non dare per scontato che, poiché un set di dati è stato utilizzato da un certo numero di giornali, sia di buona qualità”, scrive Lones.

Il tuo set di dati potrebbe avere vari problemi che possono portare il tuo modello ad apprendere la cosa sbagliata.

Ad esempio, se stai lavorando su un problema di classificazione e il tuo set di dati contiene troppi esempi di una classe e troppo pochi di un’altra, il modello di apprendimento automatico addestrato potrebbe finire per imparare a prevedere ogni input come appartenente alla classe più forte. In questo caso, il tuo set di dati soffre di “squilibrio di classe”.

Mentre lo squilibrio di classe può essere individuato rapidamente con le pratiche di esplorazione dei dati, la ricerca di altri problemi richiede maggiore cura ed esperienza. Ad esempio, se tutte le immagini nel tuo set di dati sono state scattate alla luce del giorno, il tuo modello di machine learning avrà prestazioni scadenti su foto scure. Un esempio più sottile è l’attrezzatura utilizzata per acquisire i dati. Ad esempio, se hai scattato tutte le tue foto di allenamento con la stessa fotocamera, il tuo modello potrebbe finire per imparare a rilevare l’impronta visiva unica della tua fotocamera e avrà prestazioni scadenti sulle immagini scattate con altre apparecchiature. I set di dati di machine learning possono avere tutti i tipi di tali pregiudizi.


Anche la quantità di dati è una questione importante. Assicurati che i tuoi dati siano disponibili in abbondanza. “Se il segnale è forte, puoi cavartela con meno dati; se è debole, allora hai bisogno di più dati”, scrive Lones.

In alcuni campi, la mancanza di dati può essere compensata con tecniche come la convalida incrociata e l’aumento dei dati. Ma in generale, dovresti sapere che più complesso è il tuo modello di machine learning, più dati di addestramento ti serviranno. Ad esempio, alcune centinaia di esempi di addestramento potrebbero essere sufficienti per addestrare un semplice modello di regressione con pochi parametri. Ma se vuoi sviluppare una  rete neurale profonda  con milioni di parametri, avrai bisogno di molti più dati di addestramento.

Un altro punto importante che Lones sottolinea nel documento è la necessità di avere una forte separazione tra dati di allenamento e test. Gli ingegneri di machine learning di solito mettono da parte parte dei loro dati per testare il modello addestrato. Ma a volte, i dati del test perdono nel processo di addestramento, il che può portare a modelli di apprendimento automatico che non si generalizzano ai dati raccolti dal mondo reale.

“Non permettere che i dati dei test trapelano nel processo di addestramento”, avverte. “La cosa migliore che puoi fare per prevenire questi problemi è partizionare un sottoinsieme dei tuoi dati proprio all’inizio del tuo progetto e utilizzare questo set di test indipendente solo una volta per misurare la generalità di un singolo modello alla fine del progetto .”

In scenari più complicati, avrai bisogno di un “set di convalida”, un secondo set di test che inserisca il modello di apprendimento automatico in un processo di valutazione finale. Ad esempio, se stai eseguendo la convalida incrociata o l’ apprendimento di insieme , il test originale potrebbe non fornire una valutazione precisa dei tuoi modelli. In questo caso, può essere utile un set di convalida.

“Se si dispone di dati sufficienti, è meglio tenerne alcuni da parte e utilizzarli solo una volta per fornire una stima imparziale dell’istanza finale del modello selezionato”, scrive Lones.

Conosci i tuoi modelli (così come quelli degli altri)

Oggi, il deep learning è di gran moda. Ma non tutti i problemi richiedono un apprendimento profondo. In effetti, non tutti i problemi richiedono l’apprendimento automatico. A volte, semplici criteri di corrispondenza e regole funzioneranno alla pari con i modelli di apprendimento automatico più complessi a una frazione dei dati e dei costi di calcolo.

Ma quando si tratta di problemi specifici dei modelli di apprendimento automatico, dovresti sempre avere un elenco di algoritmi candidati da valutare. “In generale, non esiste un unico miglior modello ML”, scrive Lones. “In effetti, c’è una prova di ciò, sotto forma del teorema No Free Lunch, che mostra che nessun approccio ML è migliore di qualsiasi altro se considerato su ogni possibile problema”.

La prima cosa che dovresti controllare è se il tuo modello corrisponde al tuo tipo di problema. Ad esempio, in base al fatto che l’output previsto sia categorico o continuo, dovrai scegliere l’algoritmo di machine learning giusto insieme alla struttura giusta. Anche i tipi di dati (ad es. dati tabulari, immagini, testo non strutturato e così via) possono essere un fattore determinante nella classe del modello utilizzato.

Un punto importante che Lones sottolinea nel suo articolo è la necessità di evitare un’eccessiva complessità. Ad esempio, se il tuo problema può essere risolto con un semplice albero decisionale o un modello di regressione, non ha senso utilizzare il deep learning.

Lone mette anche in guardia contro il tentativo di reinventare la ruota. Poiché l’apprendimento automatico è una delle aree di ricerca più calde, c’è sempre una solida possibilità che qualcun altro abbia risolto un problema simile al tuo. In tali casi, la cosa saggia da fare sarebbe esaminare il loro lavoro. Questo può farti risparmiare molto tempo perché altri ricercatori hanno già affrontato e risolto sfide che probabilmente incontrerai lungo la strada.

“Ignorare gli studi precedenti significa potenzialmente perdere informazioni preziose”, scrive Lones.

L’esame di documenti e lavori di altri ricercatori potrebbe anche fornirti modelli di apprendimento automatico che puoi utilizzare e riutilizzare per il tuo problema. In effetti, i ricercatori di machine learning utilizzano spesso i modelli degli altri per risparmiare tempo e risorse computazionali e iniziare con una linea di base considerata affidabile dalla comunità ML.

“È importante evitare la sindrome del ‘non inventato qui’, cioè utilizzare solo modelli che sono stati inventati nella propria istituzione, poiché ciò potrebbe indurti a omettere il modello migliore per un particolare problema”, avverte Lone.

Conoscere l’obiettivo finale e i suoi requisiti

Avere una solida idea di cosa verrà utilizzato il tuo modello di machine learning può avere un grande impatto sul suo sviluppo. Se stai facendo machine learning puramente per scopi accademici e per spingere i confini della scienza, allora potrebbero non esserci limiti al tipo di dati o algoritmi di machine learning che puoi usare. Ma non tutto il lavoro accademico rimarrà confinato nei laboratori di ricerca.

“[Per] molti studi accademici, l’obiettivo finale è produrre un modello ML che possa essere implementato in una situazione del mondo reale. Se questo è il caso, allora vale la pena pensare presto a come verrà distribuito”, scrive Lones.

Ad esempio, se il modello verrà utilizzato in un’applicazione eseguita su dispositivi utente e non su cluster di server di grandi dimensioni, non sarà possibile utilizzare grandi reti neurali che richiedono grandi quantità di memoria e spazio di archiviazione. È necessario progettare modelli di machine learning in grado di funzionare in ambienti con risorse limitate .

Un altro problema che potresti incontrare è  la necessità di spiegabilità . In alcuni settori, come quello finanziario e sanitario, gli sviluppatori di applicazioni sono tenuti per legge a fornire spiegazioni sulle decisioni algoritmiche nel caso in cui un utente lo richieda. In tali casi, potrebbe essere impossibile utilizzare un modello a scatola nera. Ad esempio, anche se una rete neurale profonda potrebbe darti un vantaggio in termini di prestazioni, la sua mancanza di interpretabilità potrebbe renderla inutile. Invece, un modello più trasparente come un albero decisionale potrebbe essere una scelta migliore anche se si traduce in un calo delle prestazioni. In alternativa, se il deep learning è un requisito assoluto per la tua applicazione, dovrai esaminare tecniche in grado di  fornire interpretazioni affidabili  delle attivazioni nella rete neurale.

In qualità di ingegnere di machine learning, potresti non avere una conoscenza precisa dei requisiti del tuo modello. Pertanto, è importante parlare con esperti di dominio perché possono aiutarti a guidarti nella giusta direzione e determinare se stai risolvendo un problema rilevante o meno.

“La mancata considerazione dell’opinione degli esperti di dominio può portare a progetti che non risolvono problemi utili o che risolvono problemi utili in modi inappropriati”, scrive Lones.

Ad esempio, se crei una rete neurale che segnala le transazioni bancarie fraudolente con un’accuratezza molto elevata ma non fornisce alcuna spiegazione della sua decisione, gli istituti finanziari non saranno in grado di utilizzarla.

Sapere cosa misurare e segnalare

Esistono vari modi per misurare le prestazioni dei modelli di apprendimento automatico, ma non tutti sono rilevanti per il problema che stai risolvendo.

Ad esempio, molti ingegneri ML utilizzano il “test di accuratezza” per valutare i propri modelli. Il test di accuratezza misura la percentuale di previsioni corrette effettuate dal modello. Questo numero può essere fuorviante in alcuni casi.

Ad esempio, si consideri un set di dati di scansioni a raggi X utilizzato per addestrare un modello di apprendimento automatico per il rilevamento del cancro. I tuoi dati sono squilibrati, con il 90% degli esempi di addestramento contrassegnati come benigni e un numero molto piccolo classificato come maligno. Se il tuo modello addestrato ottiene un punteggio di 90 nel test di precisione, potrebbe aver appena imparato a etichettare tutto come benigno. Se utilizzato in un’applicazione del mondo reale, questo modello può portare a casi mancati con esiti disastrosi. In tal caso, il team ML deve utilizzare test insensibili allo squilibrio di classe o utilizzare una matrice di confusione per verificare altre metriche. Le tecniche più recenti possono fornire una misura dettagliata delle prestazioni di un modello in varie aree.

In base all’applicazione, gli sviluppatori ML potrebbero anche voler misurare diverse metriche. Per tornare all’esempio del rilevamento del cancro, in un tale modello potrebbe essere importante ridurre il più possibile i falsi negativi anche a costo di una minore precisione o di un leggero aumento dei falsi positivi. È meglio mandare poche persone sane per la diagnosi in ospedale piuttosto che perdere i malati di cancro critici.

Nel suo articolo, Lone avverte che quando si confrontano diversi modelli di apprendimento automatico per un problema, non dare per scontato che numeri più grandi non significhino necessariamente modelli migliori. Ad esempio, le differenze di prestazioni potrebbero essere dovute al training e al test del modello su partizioni diverse del set di dati o su set di dati completamente diversi.

“Per essere davvero sicuri di un confronto equo tra due approcci, dovresti implementare di recente tutti i modelli che stai confrontando, ottimizzarli ciascuno allo stesso livello, eseguire più valutazioni … e quindi utilizzare test statistici … per determinare se le differenze di le prestazioni sono significative”, scrive Lones.

Lone avverte anche di non sopravvalutare le capacità dei tuoi modelli nei tuoi rapporti. “Un errore comune è fare affermazioni generali che non sono supportate dai dati utilizzati per addestrare e valutare i modelli”, scrive.

Pertanto, qualsiasi rapporto sulle prestazioni del modello deve includere anche il tipo di dati su cui è stato addestrato e testato. La convalida del modello su più set di dati può fornire un’immagine più realistica delle sue capacità, ma dovresti comunque diffidare del tipo di errori di dati di cui abbiamo discusso in precedenza.

La trasparenza può anche contribuire notevolmente ad altre ricerche sul machine learning. Se descrivi completamente l’architettura dei tuoi modelli, nonché il processo di formazione e convalida, altri ricercatori che leggono i tuoi risultati possono utilizzarli in lavori futuri o persino aiutare a evidenziare potenziali difetti nella tua metodologia.

Infine,  punta alla riproducibilità . se pubblichi il tuo codice sorgente e le implementazioni del modello, puoi fornire alla comunità di machine learning ottimi strumenti nel lavoro futuro.

Apprendimento automatico applicato

È interessante notare che quasi tutto ciò che Lone ha scritto nel suo articolo è applicabile anche  all’apprendimento automatico applicato , la branca del machine learning che si occupa dell’integrazione di modelli in prodotti reali. Tuttavia, vorrei aggiungere alcuni punti che vanno oltre la ricerca accademica e sono importanti nelle applicazioni del mondo reale.

Quando si tratta di dati, gli ingegneri dell’apprendimento automatico devono considerare una serie aggiuntiva di considerazioni prima di integrarli nei prodotti. Alcuni includono la privacy e la sicurezza dei dati, il consenso dell’utente e i vincoli normativi. Molte aziende sono cadute nei guai per aver estratto i dati degli utenti senza il loro consenso.

Un’altra questione importante che gli ingegneri ML spesso dimenticano nelle impostazioni applicate è il decadimento del modello. A differenza della ricerca accademica, i modelli di apprendimento automatico utilizzati nelle applicazioni del mondo reale devono essere riqualificati e aggiornati regolarmente. Man mano che i dati di tutti i giorni cambiano, i modelli di apprendimento automatico “decadono” e le loro prestazioni si deteriorano. Ad esempio, quando le abitudini di vita sono cambiate a seguito del blocco del covid, i sistemi di machine learning che erano stati addestrati su vecchi dati hanno  iniziato a fallire e hanno avuto bisogno di una riqualificazione. Allo stesso modo, i modelli linguistici devono essere costantemente aggiornati man mano che compaiono nuove tendenze e cambiano le nostre abitudini di conversazione e scrittura. Questi cambiamenti richiedono che il team di prodotto ML elabori una strategia per la raccolta continua di nuovi dati e la riqualificazione periodica dei loro modelli.

Infine, le sfide di integrazione saranno una parte importante di ogni progetto di machine learning applicato. In che modo il tuo sistema di machine learning interagirà con altre applicazioni attualmente in esecuzione nella tua organizzazione? La tua infrastruttura dati è pronta per essere collegata alla pipeline di machine learning? La tua infrastruttura cloud o server supporta la distribuzione e la scalabilità del tuo modello? Questo tipo di domande può creare o distruggere la distribuzione di un prodotto ML.

Ad esempio, di recente, il laboratorio di ricerca sull’intelligenza artificiale OpenAI ha lanciato una versione di prova del proprio  modello API Codex per la valutazione pubblica. Ma il loro lancio non è riuscito perché i loro server non potevano adattarsi alla domanda degli utenti.

Di ihal