La (lunga) evoluzione del Machine Learning
L’intervista con il nostro data scientist Christian alla scoperta del mondo dell’Intelligenza Artificiale e del Machine Learning è ora arrivata al suo ultimo episodio! Negli articoli precedenti, abbiamo discusso due diversi approcci per insegnare a una macchina a portare a termine un compito.
Esattamente! Da un lato, un congegno può imparare a “prendere decisioni” sulla base di regole che vengono precedentemente codificate in essa in forma dettagliata, così che il congegno stesso non abbia alcun margine per prendere l’iniziativa, ma debba invece “solamente” seguire in maniera meccanica ciò che è stato istruito a fare. In questo ambito, un esempio di spicco è quello di Deep Blue, il computer che nel 1997 fu in grado di sconfiggere a scacchi l’allora campione del mondo.
Dall’altro lato, una macchina può essere sottoposta a un vero e proprio processo di apprendimento, nel corso del quale, a partire da un qualche input (immagini, per esempio), la macchina stessa gradualmente riconosce e impara da sé le “regole” senza che queste vengano esplicitamente codificate al suo interno. Questo approccio viene chiamato Machine Learning (ML) ed è l’attuale standard per compiti come la visione artificiale.
Ci eravamo lasciati però con un dubbio in sospeso: sebbene l’intervento umano giochi un ruolo meno preponderante nell’ambito del ML, lo sviluppo di quest’ultimo ha richiesto più tempo rispetto all’approccio alla base di Deep Blue. Perché? Quali aspetti hanno rallentato il Machine Learning, nonostante il fatto che, in rapporto al metodo basato sulla codifica esplicita delle regole, i programmatori abbiano apparentemente meno codice da implementare dato che larga parte del lavoro è infatti lasciato alla macchina stessa?
Per rispondere a questa domanda, richiamo la metafora che ho fatto nel post precedente, dove paragonavo l’architettura software ad un cruscotto e i parametri ad una serie di manopole che servono per gestire il processo di training. In questo caso, per permettere al computer di individuare il settaggio ottimale, occorre prima progettare e costruire il cruscotto stesso. Fuor di metafora, una delle ragioni per cui lo sviluppo della visione artificiale ha richiesto più tempo è dovuta al fatto che l’identificazione della struttura matematica a essa più adatta – l’architettura, com’è stata definita in precedenza – ha necessitato anni di ricerca. Solo in seguito è stato possibile dire al computer: “Ok, tutte le manopole sono adesso a disposizione e la loro organizzazione sul cruscotto è quella che fa al caso tuo: ora procedi da solo e gira ogni manopola nella posizione appropriata, in modo che, tutte assieme, possano consentirti di eseguire al meglio il compito di classificazione che ti è stato assegnato”. Nel caso della visione artificiale, l’architettura più idonea è quella delle Reti Neurali Convoluzionali (RNC): ambiti diversi di applicazione del Machine Learning – che comprendono, tra i molti altri, il riconoscimento vocale, l’analisi dei mercati finanziari, la diagnosi medica e le telecomunicazioni – necessitano di solito di modelli diversi, ciascuno provvisto di parametri il cui settaggio ottimale continuerà comunque a essere determinato tramite la stessa logica di apprendimento autonomo delineata in precedenza.
Hai menzionato le Reti Neurali Convoluzionali. Ci sai dare qualche dettaglio in più?
Tornando al perché la visione artificiale abbia richiesto più tempo dello sviluppo di Deep Blue, occorre ricordare che i parametri di una RNC sono tipicamente alcuni milioni e le loro interazioni estremamente complesse. Per effettuare il training, è dunque obbligatorio avere a disposizione una quantità decisamente elevata di dati in input – fotografie in formato digitale, nel caso in esame. Solo la massiccia digitalizzazione degli ultimi anni lo ha reso possibile; prima, i dati non erano sufficienti o, comunque, non erano facilmente leggibili da un computer (si pensi alle immagini analogiche, per esempio).
Immagino che lo sviluppo della visione artificiale è stato inizialmente rallentato da alcune carenze dal punto di vista della tecnologia disponibile, sbaglio?
Sì, infatti, oltre a produrre dati in formato digitale in abbondanza, è anche necessario disporre di strutture dove immagazzinarli (dunque, di memoria) e di strumenti per consultarli rapidamente (altrimenti il training richiederebbe troppo tempo). In termini di memoria, il bisogno è accresciuto ulteriormente dall’elevatissimo numero di parametri in una RNC i cui valori devono essere aggiornati durante la fase di training e poi immagazzinati per essere successivamente impiegati. Inoltre, a causa di alcuni suoi aspetti piuttosto tecnici, lo stesso processo di aggiornamento dei parametri mal si adattava all’architettura di un’Unità di Elaborazione Centrale (o CPU, dal suo acronimo in inglese), cioè del tipo di processore più utilizzato dalla comunità scientifica fino a qualche anno fa. Il superamento di tutti questi ostacoli tecnici è divenuto realtà solo grazie ai recenti progressi nell’ambito dell’architettura dei computer e del software. Per esempio, oggi le RNC non vengono più implementate sulle CPU, bensì sulle Unità di Elaborazione Grafica (o GPU): queste ultime sono state inizialmente sviluppate per applicazioni grafiche (videogiochi, soprattutto) ma è in seguito emerso come le loro caratteristiche tecniche si adattino perfettamente anche al processo di aggiornamento dei parametri all’interno di una RNC.
Grazie Christian, questa intervista ci ha aperto le porte ad un mondo che non è di banale comprensione perché spesso spiegato in termini troppo tecnici. Grazie agli esempi pratici e alle metafore che ci hai fornito, adesso è tutto più chiaro!
Ti è piaciuto questo articolo?
Inserisci il tuo indirizzo e-mail per ricevere la nostra newsletter!
PS: odiamo lo spam proprio come te, quindi ti promettiamo solo un paio di newsletter all’anno con una raccolta degli articoli più interessanti!