{"id":2402,"date":"2021-01-22T10:23:28","date_gmt":"2021-01-22T09:23:28","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=2402"},"modified":"2021-03-17T15:33:08","modified_gmt":"2021-03-17T14:33:08","slug":"clustering-con-sagemaker-experiments-un-caso-duso-reale","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/clustering-con-sagemaker-experiments-un-caso-duso-reale\/","title":{"rendered":"Clustering con SageMaker Experiments: un caso d\u2019uso reale"},"content":{"rendered":"\n
Lo sviluppo di un modello di Machine Learning<\/strong> \u00e8 un processo altamente iterativo, con continui cicli di feedback ottenuti da test e prove precedenti, molto pi\u00f9 somigliante ad un esperimento scientifico che ad un progetto di sviluppo. Amazon mette a disposizione diversi strumenti per aiutare i Data Scientist a trovare il corretto set di parametri per i loro modelli. Se il progetto \u00e8 grande abbastanza, sono di solito coinvolti molteplici ingegneri a pi\u00f9 livelli. Di conseguenza \u00e8 fondamentale mantenere un progetto il pi\u00f9 strutturato possibile, cos\u00ec come trovare metodologie efficaci per condividere tutti i dataset, i notebook, gli iperparametri e naturalmente i risultati.<\/p>\n\n\n\n I componenti principali di un progetto di Machine Learning, di cui sono necessari versionamenti, indicizzazione e condivisione tra tutti i Data Scientists coinvolti, sono:<\/p>\n\n\n\n Ogni membro del team dovrebbe sempre avere chiaro qualsiasi sia l\u2019ultima versione di ogni componente citato, ed essere cos\u00ec in grado di ricercare velocemente risultati e artefatti di ogni precedente versione dei processi e delle prove effettuate.<\/p>\n\n\n\n Per venire incontro ai Data Scientists nei processi di gestione e strutturazione dei progetti di ML, Amazon ha rilasciato un nuovo servizio: SageMaker Experiments. In questo articolo, vi presentiamo dunque un caso d\u2019uso reale in cui abbiamo fatto uso estensivo di SageMaker Experiments.<\/p>\n\n\n\n Il progetto aveva come scopo la gestione del clustering di un dataset di clienti molto sparso, contenente diversi milioni di tuple, per estrarre informazioni comportamentali. La struttura del dataset e le feature disponibili avevano reso la scelta dell\u2019algoritmo di clustering e il tuning degli iperparametri tutt\u2019altro che semplice. Dopo diverse iterazioni, abbiamo notato che il risultato pi\u00f9 stabile si \u00e8 ottenuto mediante DBSCAN dopo aver effettuato una riduzione di dimensionalit\u00e0 con UMAP (Uniform Manifold Approximation and Projection). L\u2019analisi KNN \u00e8 servita a trovare il valore ottimo del raggio (eps) per DBSCAN.<\/p>\n\n\n\n UMAP, DBSCAN e KNN sono algoritmi che traggono peraltro grande giovamento dalla parallelizzazione via GPU. <\/p>\n\n\n\n Per garantire la massima efficienza nell\u2019effettuare il clustering del dataset, abbiamo deciso di usare il framework RapidsAI, che include la versione GPU per CUDA di tutti gli algoritmi da noi menzionati e necessari alla nostra pipeline. Per installare RapidsAI, possiamo partire dal sito della libreria<\/a>.<\/a> Qui \u00e8 possibile trovare i comandi di installazione per Conda Python3<\/strong>, che \u00e8 proprio ci\u00f2 che ci serviva per la nostra istanza di testing di SageMaker:<\/p>\n\n\n\n Dopo aver eseguito i comandi, sar\u00e0 possibile eseguire il nuovo Kernel Jupiter, ma per farlo dovrete chiudere e riaprire il notebook, quindi selezionare \u201cKernel\u201d -> \u201cChange Kernel\u201d; fatto questo potrete scegliere il nuovo Kernel RapidsAI appena installato.<\/p>\n\n\n\n Nota: <\/strong>ogni volta che si stoppa un\u2019istanza di SageMaker ogni custom Kernel viene perso perch\u00e8 non fa parte dell\u2019immagine standard che viene associata all\u2019istanza, quindi \u00e8 necessario procedere di nuovo alla procedura di installazione vista precedentemente. <\/em><\/p>\n\n\n\n Alcuni metodi tipici di partizione come K-means o clustering PAM sono particolarmente adatti a trovare cluster sferici o, pi\u00f9 in generale, convessi. Di solito funzionano molto bene per cluster compatti e ben separati, pressappoco della stessa dimensione. Di solito sono per\u00f2 sensibili alla presenza di forte anisotropia nei dati (rumore e outlier).<\/p>\n\n\n\n Anche se possono dunque sembrare pi\u00f9 che adatti in molte situazioni, ve ne sono molti altri in cui non solo non lo sono, ma in particolare, performano veramente male con:<\/p>\n\n\n\n Ed \u00e8 per questo che abbiamo provato DBSCAN.<\/p>\n\n\n\n Density-based spatial clustering of applications with noise<\/strong> o, in breve, DBSCAN \u00e8 un algoritmo ben noto di clustering dei dati utilizzato comunemente per i problemi di data mining e machine learning.<\/p>\n\n\n\n Basandosi su un dataset di punti, DBSCAN raggruppa insieme tutti quelli sufficientemente vicini tra di loro rispetto ad una misurazione di distanza, tipicamente Euclidea, con una soglia basata su un numero minimo di punti. \u00c8 inoltre in grado di marcare come outlier tutti quei punti che risultano particolarmente sparsi, ovvero presenti in regioni a bassa densit\u00e0.<\/p>\n\n\n\n DBSCAN utilizza principalmente 2 parametri obbligatori:<\/p>\n\n\n\n eps<\/strong>: il raggio locale<\/strong> per gli expanding<\/em> cluster. Lo si pensi come un valore di STEP – DBSCAN non effettua mai step con valori maggiori di questo, ed indica inoltre quanto vicini debbano essere i punti tra di loro per essere considerati parte di un cluster. <\/p>\n\n\n\n minPoints<\/strong>: il minimo numero di punti vicini tra di loro per formare una regione densa (min. numero di punti nel raggio). Questo di solito \u00e8 fortemente legato alla dimensione minima del cluster. Per esempio, un valore di 100, significa che abbiamo bisogno di almeno 100 punti per definire un cluster, se i cluster hanno bordi ben definiti e se il dataset non contiene rumore random.<\/p>\n\n\n\n La stima dei parametri \u00e8 un problema comune a tutti i progetti di ML. Per poter trovare dei valori corretti di eps e minPoints \u00e8, di solito, necessario avere una discreta conoscenza della forma del dataset. Di seguito dunque abbiamo alcune considerazioni a carattere generale su come scegliere valori iniziali ragionevoli di eps e minPoints.<\/p>\n\n\n\n eps<\/strong>: se il valore eps scelto \u00e8 troppo piccolo, gran parte dei dati non verr\u00e0 raggruppata. Sar\u00e0 considerato un valore anomalo perch\u00e9 non soddisfa il numero di punti necessario a creare una regione densa. D’altra parte, se il valore scelto \u00e8 troppo alto, i cluster si uniranno e la maggior parte degli oggetti si trover\u00e0 nello stesso cluster. L’eps dovrebbe essere scelto in base alla distanza media tra i punti del set di dati (possiamo usare un grafico di k-distance per trovarlo), ma in generale sono preferibili piccoli valori di eps. Va notato che eps \u00e8 influenzata dalla dimensionality curse<\/strong>, quindi pi\u00f9 elementi si hanno, pi\u00f9 grande sar\u00e0 eps, infatti, la distanza euclidea media in un set di dati normalizzato \u00e8 proporzionale alla dimensionalit\u00e0.<\/p>\n\n\n\n minPoints<\/strong>: come regola generale, un valore minimo di minPoints pu\u00f2 essere derivato da un numero di dimensioni (D) nel set di dati, come minPoints \u2265 D + 1. Valori pi\u00f9 grandi sono generalmente migliori per set di dati con rumore e formeranno cluster pi\u00f9 significativi. Il valore minimo per minPoints deve essere 3, ma maggiore \u00e8 il dataset, maggiore \u00e8 il valore minPoints da scegliere.<\/p>\n\n\n\n Al fine di evitare le insidie derivanti dalla dimensionality curse e per ottenere risultati di clustering pi\u00f9 stabili ed efficienti, una tecnica comune \u00e8 quella di utilizzare un algoritmo di riduzione di dimensionalit\u00e0. Nel nostro caso, abbiamo utilizzato l’analisi di correlazione per la selezione delle feature e quindi la PCA, per trovare quali di queste avessero un impatto pi\u00f9 significativo sui componenti principali, risultando quindi buone candidate per essere incluse nel set di dati finale, usato per addestrare il nostro modello.<\/p>\n\n\n\n Tuttavia, l’utilizzo diretto della PCA per la riduzione della dimensionalit\u00e0 ha portato a risultati negativi: il numero di componenti principali necessari a spiegare una percentuale significativa della varianza del dataset \u00e8 risultato piuttosto alto e, di conseguenza, tutti gli algoritmi di clustering hanno funzionato male.<\/p>\n\n\n\n Le prestazioni PCA non ottimali ci hanno costretto a cercare altrove per la riduzione della dimensionalit\u00e0. Altri algoritmi comunemente usati a questo scopo sono t-SNE e UMAP.<\/p>\n\n\n\n Entrambi gli algoritmi risultano poco performanti nell’implementazione single-core di Scikit-learn sul nostro dataset molto grande, tuttavia, le cose cambiano radicalmente con l’implementazione GPU CUDA di RapidsAI. Con l’aiuto della GPU, siamo stati in grado di eseguire la riduzione di dimensionalit\u00e0, per entrambi i metodi, in pochi minuti.<\/p>\n\n\n\n UMAP \u00e8 pi\u00f9 veloce e, nonostante sia un algoritmo di recente scoperta, \u00e8 generalmente preferibile a t-SNE poich\u00e9 fa un buon lavoro nel preservare sia la struttura locale che quella globale del set di dati (ecco un esempio<\/a>).<\/p>\n\n\n\n Inoltre, UMAP non utilizza inizializzazione casuale<\/strong>, quindi i risultati rimangono coerenti tra le diverse esecuzioni. Riducendo il set di dati a 3 dimensioni, i singoli cluster potevano essere facilmente distinti a colpo d’occhio e il punteggio di affidabilit\u00e0 UMAP era molto alto.<\/p>\n\n\n\n UMAP ha una serie di importanti iperparametri che influenzano le sue prestazioni. Questi iperparametri sono:<\/p>\n\n\n\n <\/p>\n\n\n\n Misurare le prestazioni di un algoritmo \u00e8 sempre un passo essenziale in un flusso di lavoro di Machine Learning.<\/p>\n\n\n\n Mentre in un progetto di Machine Learning supervisionato, il modo per farlo \u00e8 solitamente semplice (addestrare il modello su un sottoinsieme del set di dati e testarlo su un altro sottoinsieme), per un flusso ML non supervisionato, la valutazione oggettiva delle prestazioni \u00e8 pi\u00f9 complicata e ancor di pi\u00f9, se l’esistenza e il numero dei cluster non sono conosciuti n\u00e9 conoscibili a priori.<\/p>\n\n\n\n Un modo comune per risolvere questo problema, consiste nel selezionare una o pi\u00f9 metriche obiettivo, legate alle prestazioni dell’output del processo clustering e verificare se, una determinata esecuzione, soddisfa o meno delle soglie target.<\/p>\n\n\n\n Una metrica molto generale, robusta e ampiamente utilizzata \u00e8 il punteggio Silhouette, che \u00e8 la metrica che abbiamo selezionato per guidare la nostra valutazione delle prestazioni di clustering.<\/p>\n\n\n\n Il punteggio Silhouette pu\u00f2 essere utilizzato per studiare la distanza tra diversi cluster risultanti in un problema, appunto, di clustering; mostra la misura di quanto ogni punto di un cluster sia vicino ai punti dei cluster intorno ad esso e quindi fornisce un modo per valutare visivamente variabili quali il numero di cluster.<\/p>\n\n\n\n Questa misura ha un intervallo compreso tra -1<\/strong> e 1<\/strong>.<\/p>\n\n\n\n I coefficienti di silhouette vicini a 1 indicano che il campione \u00e8 lontano dai cluster vicini, quindi buono. Un valore di 0, invece, ci dice che il punto \u00e8 vicino al confine di decisione tra due cluster vicini. Infine, i valori negativi indicano che i campioni potrebbero essere stati assegnati al cluster sbagliato.<\/p>\n\n\n\n <\/p>\n\n\n\n Abbiamo utilizzato questo punteggio per verificare la qualit\u00e0 dei cluster dei nostri clienti e per valutare le prestazioni di diversi algoritmi di clustering e set di iperparametri.<\/p>\n\n\n\n Il completamento del flusso di lavoro di clustering ha richiesto diverse centinaia di iterazioni con diversi algoritmi di pulizia dei dati, euristica, selezione delle funzionalit\u00e0 e clustering.<\/p>\n\n\n\n Amazon SageMaker Experiments aiuta a tenere traccia delle iterazioni sui modelli di ML acquisendo i parametri di input, le configurazioni e i risultati e archiviandoli come “esperimenti”. In SageMaker Studio puoi sfogliare esperimenti attivi, cercare quelli precedenti, rivederli insieme ai risultati e confrontare questi risultati.<\/p>\n\n\n\n L’obiettivo di SageMaker Experiments, con la sua API Python, \u00e8 rendere il pi\u00f9 semplice possibile la creazione di tali esperimenti, popolarli con test ed eseguire analisi attraverso prove ed esperimenti.<\/p>\n\n\n\n Puoi eseguire query complesse per trovare rapidamente una versione passata di un test che stai cercando. Puoi anche visualizzare classifiche dei modelli e grafici delle metriche in tempo reale.<\/p>\n\n\n\n <\/p>\n\n\n\n Nel corso di questo articolo, verrai guidato attraverso le funzionalit\u00e0 e l’impostazione di SageMaker Experiment attraverso lo scenario del caso d\u2019uso reale che abbiamo affrontato.<\/p>\n\n\n\n Per poter utilizzare SageMaker Experiments, dobbiamo prima accedere a Sagemaker Studio, e per farlo, abbiamo creato alcuni utenti, uno per ogni collaboratore, nella Console AWS.<\/p>\n\n\n\n \u00c8 necessario disporre delle autorizzazioni corrette per accedere ai servizi di SageMaker tramite la console, se ne si dispone, \u00e8 sufficiente fare clic sulla barra laterale sinistra della pagina del servizio e accedere al pannello delle propriet\u00e0 di SageMaker Studio. L\u00ec troverai il pulsante “Add user” per creare un nuovo utente.<\/p>\n\n\n\n <\/p>\n\n\n\n La creazione di un utente \u00e8 semplice: basta fornire un nome e un ruolo IAM valido, come nell’esempio seguente, e poi si \u00e8 a posto. Si guardi l’immagine sotto per chiarezza:<\/p>\n\n\n\n <\/p>\n\n\n\n Questo \u00e8 un punto semplice ma cruciale: nella gestione di un progetto, complesso come uno di Machine Learning, sono estremamente importanti i confronti costanti con il cliente. Dandogli la possibilit\u00e0 di valutare facilmente i risultati di ogni esperimento, si rende pi\u00f9 facile avere un feedback e si migliorano significativamente le possibilit\u00e0 di un risultato soddisfacente per il progetto.<\/p>\n\n\n\n Prima di iniziare a capire come funziona Experiments, definiamo alcuni concetti chiave che si deve conoscere:<\/p>\n\n\n\n L’obiettivo di SageMaker Experiments \u00e8, ovviamente, quello di rendere il pi\u00f9 semplice possibile l’accesso e la manipolazione degli esperimenti, popolarli con prove e inoltre fare analisi su test ed esperimenti per prendere decisioni ponderate.<\/p>\n\n\n\n Per aiutarci in questa attivit\u00e0, AWS offre un SDK Python, contenente API di logging e analisi, per integrare Experiments nei notebook.<\/p>\n\n\n\n Prima di iniziare a descrivere il processo in dettaglio, solo una precisazione: abbiamo utilizzato l’approccio pi\u00f9 elastico possibile nell’affrontare il nostro problema di Machine Learning con SageMaker, ovvero bring your own container<\/strong>: ci\u00f2 significa che definiamo il nostro codice ML in script<\/strong> passati ad un Estimator<\/strong>, che viene eseguito su immagini personalizzate inviate ad AWS ECR<\/strong>.<\/p>\n\n\n\n Perch\u00e9 svolgere questo lavoro extra, invece di utilizzare materiale predefinito di AWS? Perch\u00e9 avevamo bisogno di maggiore flessibilit\u00e0 nell’affrontare il nostro problema e, in generale, si vedr\u00e0 che, a parte casi estremamente rari, probabilmente anche il lettore finir\u00e0 per fare la stessa cosa con il proprio caso d’uso.<\/p>\n\n\n\n Gli scenari del mondo reale che coinvolgono le aziende hanno condizioni molto specifiche<\/strong>, che possono essere affrontate con maggiore precisione, solo quando gli algoritmi e i modelli sono adattati e messi a punto su quel problema specifico<\/strong>.<\/p>\n\n\n\n In Jupyter Notebooks, gli utenti possono aggiungere automatismi utilizzando le API di SageMaker; quando si definisce un Estimator<\/a> per il training di un modello, \u00e8 possibile aggiungere una definizione di Esperiments, in questo modo fondamentalmente colleghiamo l’operazione a una tupla nella console di Experiments<\/strong> in SageMaker Studio.<\/p>\n\n\n\n Per il nostro processo di clustering questa possibilit\u00e0 era importante, perch\u00e9 avevamo l’esplicita necessit\u00e0 di fornire aggiornamenti settimanali<\/strong> sulle prestazioni dei nostri modelli. Di solito questa \u00e8, come detto, una buona pratica per aiutare a creare una chiara comprensione del problema con il cliente e, in generale, per evitare confusione.<\/p>\n\n\n\n Prima di passare un esperimento a uno stimatore, come spiegato nella documentazione ufficiale di AWS, dobbiamo generarlo da zero; in una nuova cella di un Jupyter Notebook scriviamo queste righe:<\/p>\n\n\n\n In queste righe di codice stiamo descrivendo un nuovo esperimento e non solo: se l’esperimento esiste gi\u00e0 nella lista degli esperimenti, che dipende dalle credenziali dell’utente loggato su Jupyter, quell’esperimento viene caricato, invece di crearne uno nuovo.<\/p>\n\n\n\n Perch\u00e9 l’abbiamo fatto? Perch\u00e9 volevamo dividere gli esperimenti per categorie, quindi utilizzare le prove, per raggruppare diversi Training Job. In questo modo si possono mantenere le cose pi\u00f9 pulite.<\/p>\n\n\n\n \u00c8 quindi possibile aggiungere un esperimento a uno stimatore, ma prima di farlo, \u00e8 necessario creare dei Trial e aggiungerli all’esperimento stesso (ecco perch\u00e9 possiamo caricare anche un esperimento esistente).<\/p>\n\n\n\n I Trial sono gruppi in cui ogni evento di training viene mantenuto. Sono definiti in un esperimento e possono essere utilizzati per dividere e mantenere diversi Training Job, con diversi set di parametri, separati e puliti.<\/p>\n\n\n\n Noi lo abbiamo fatto perch\u00e9 abbiamo provato un gran numero di set di iperparametri per mettere a punto i modelli, in parte anche perch\u00e9 avevamo un set di dati iniziale molto scarso, che era molto difficile da analizzare in termini di clustering.<\/p>\n\n\n\n Per aggiungere un Trial a un esperimento SageMaker, ecco un codice di esempio da utilizzare in una cella sotto quella con l’inizializzazione dello stesso.<\/p>\n\n\n\n In questo caso, per poter distinguere tra loro i vari Trial, ne generiamo dinamicamente il nome: una pratica comune; si pu\u00f2 fare a seconda della categoria di un Trial o dei parametri coinvolti. Basta essere consapevoli del limite di caratteri del Trial (120 caratteri), quindi non rendiamo il nome troppo lungo ed evitiamo i caratteri speciali in quanto non sono consentiti.<\/p>\n\n\n\n Ora che abbiamo aggiunto un Trial ad un esperimento, \u00e8 possibile aggiungere quest\u2019ultimo ad uno stimatore per renderlo disponibile dall’IDE di SageMaker Studio.<\/p>\n\n\n\n Gestiscono i Training Job e le distribuzioni end-to-end dei task di deploy di Amazon SageMaker. \u00c8 una classe Python che definisce tutte le caratteristiche di un training. Per aggiungere il supporto ad Experiments \u00e8 sufficiente aggiungere una riga di codice in pi\u00f9 alla definizione di uno stimatore come nell’esempio seguente:<\/p>\n\n\n\n Fondamentalmente, quando eseguiamo il metodo .fit() per avviare un Training Job, SageMaker riconosce il parametro experiment_config<\/strong> e collega quel particolare Job alla dashboard di Sagemaker Studio Experiment.<\/p>\n\n\n\n Ci\u00f2 dimostra quanto sia semplice creare un esperimento, ma \u00e8 anche necessario definire un Tracker<\/strong>, al fine di inviare effettivamente le informazioni alla dashboard dell’esperimento.<\/p>\n\n\n\n Per inviare in modo efficace le informazioni alla dashboard di SageMaker Studio, \u00e8 necessario configurare un tracker. Un tracker \u00e8 fondamentalmente un logger<\/strong> che accetta diversi input e li invia a schede specifiche della console di Experiments, a seconda del metodo utilizzato.<\/p>\n\n\n\n Grazie al tracker e ad alcuni log predefiniti offerti da SageMaker Experiments, si pu\u00f2 ottenere una descrizione particolarmente completa del proprio test come nell’immagine sottostante:<\/p>\n\n\n\n <\/p>\n\n\n\n Facendo clic sulla scheda “Describe Trial Component”, si pu\u00f2 cliccare su qualsiasi intestazione di colonna per visualizzare le informazioni su ciascun componente di un Trial, in particolare:<\/p>\n\n\n\n Un Tracker pu\u00f2, e generalmente deve, essere aggiunto ad uno script per l\u2019Estimator<\/strong>, che contiene la propria logica di Machine Learning<\/strong>. Dopo questa linea di codice \u00e8 possibile cominciare ad inviare informazioni a SageMaker Studio. Nel nostro caso abbiamo utilizzato 3 metodi del tracker:<\/p>\n\n\n\n Che \u00e8 utilizzato per inviare parametri<\/strong> extra <\/strong>alla scheda \u201cParameters\u201d nella dashboard di quel particolare trial.<\/p>\n\n\n\n <\/p>\n\n\n\n Viene utilizzato per registrare tutti i parametri di input desiderati<\/strong>, specificando anche il media type<\/strong> per consentirne l’anteprima, se possibile, nel browser. Questi parametri verranno aggiunti alla scheda “Metrics”:<\/p>\n\n\n\n <\/p>\n\n\n\n Si usa per inviare output specifici alla scheda \u201cArtifacts\u201d che contiene gi\u00e0 le path dei bucket di storage di Amazon S3 sia per l\u2019input dataset che per l\u2019output model.<\/p>\n\n\n\n <\/p>\n\n\n\n Infine ricordarsi di chiudere sempre il tracker prima di concludere lo script.<\/strong><\/p>\n\n\n\n Come indicato anche dalla documentazione<\/a> di AWS, si possono confrontare esperimenti, Trial e componenti dei Trial, aprendoli nella Studio Leaderboard<\/strong>. In questa schermata puoi eseguire le seguenti azioni:<\/p>\n\n\n\n Quando hai uno o pi\u00f9 esperimenti, puoi aprire la Leaderboard<\/strong> per confrontare i risultati. Scegli gli esperimenti o le prove che desideri confrontare; fai clic con il tasto destro su uno degli elementi, quindi su “Open in trial component list”. Si aprir\u00e0 la Leaderboard e ti verr\u00e0 presentato un elenco di Esperiment associati, come mostrato nell’immagine seguente:<\/p>\n\n\n\n <\/p>\n\n\n\n Dalla nostra sperimentazione abbiamo scoperto che il Tracker pu\u00f2 essere utilizzato solo quando l’Estimator viene avviato in modalit\u00e0 online<\/strong>, ovvero specificando un tipo di istanza che non \u00e8 “locale”. In questo articolo, abbiamo visto come sfruttare le nuove funzionalit\u00e0 offerte da Amazon SageMaker Experiments per gestire il clustering di una notevole quantit\u00e0 di dati. Non siamo andati troppo in profondit\u00e0 con le caratteristiche di SageMaker Experiment, ma abbiamo condiviso con voi i tratti pi\u00f9 importanti in quanto vorremmo incoraggiare il lettori a provare e sperimentare da soli.<\/p>\n\n\n\n Lungo il percorso descritto, abbiamo anche visto come utilizzare due interessanti algoritmi di clustering: DBSCAN e UMAP. Questi sono particolarmente adatti per trovare gruppi di dati simili quando il set di dati originale \u00e8 scarso e disomogeneo, ma richiedono un’istanza abilitata CUDA.<\/p>\n\n\n\n Infine, abbiamo anche discusso brevemente il concetto chiave di “bring your own container” in SageMaker che abbiamo trovato fondamentale per completare la nostra analisi: come abbiamo detto, quando si ha a che fare con scenari di vita reale complessi, algoritmi preconfezionati offerti da AWS SageMaker non sono, di solito, abbastanza flessibili.<\/p>\n\n\n\n Per concludere speriamo che la lettura vi sia piaciuta, per qualsiasi domanda non esitate a contattarci, per parlare di Machine Learning o di qualsiasi altro argomento relativo al fantastico mondo del Cloud Computing!<\/p>\n\n\n\n Restate sintonizzati per altri articoli sul Machine Learning. A tra 14 giorni qui su #Proud2beCloud<\/a>!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" Lo sviluppo di un modello di Machine Learning \u00e8 un processo altamente iterativo, con continui cicli di feedback ottenuti da […]<\/p>\n","protected":false},"author":9,"featured_media":2444,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[247],"tags":[435],"class_list":["post-2402","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-ml","tag-amazon-sagemaker"],"yoast_head":"\n
I Data Scientists sono soliti effettuare molti training su modelli differenti ogni giorno, cercando di trovare quello pi\u00f9 robusto per lo scenario su cui stanno lavorando e tenere traccia di tutti i processi svolti si rivela spesso un compito sfidante, anche in un progetto seguito da una singola persona.<\/p>\n\n\n\n
Servizi come Automatic Model Tuning e Amazon SageMaker Autopilot, giungono in aiuto, aiutando ad esplorare velocemente e automaticamente grosse sezioni dello spazio di fase. Tuttavia questi servizi contribuiscono, inevitabilmente, anche alla crescita senza fine di gruppi di parametri per i training e artefatti dei modelli compilati.<\/p>\n\n\n\n
Questo nuovo componente di Amazon SageMaker ha come scopo proprio quello di risolvere questa sfida gestionale, fornendo una vista unificata per tutti questi parametri, per i training effettuati e per gli artefatti di output.<\/p>\n\n\n\nClustering dei clienti<\/h2>\n\n\n\n
Abbiamo testato diversi tipi di algoritmi di clustering (Kmeans, Gaussian mixture, DBSCAN) con differenti combinazioni di feature. Per scoprire inoltre quelle pi\u00f9 rilevanti per il clustering stesso abbiamo utilizzato la tecnica PCA e i valori di correlazioni tra le variabili in gioco.<\/p>\n\n\n\nTraining con SageMaker su AWS con istanze GPU<\/h2>\n\n\n\n
AWS offre diversi tagli per le istanze GPU di SageMaker. Per il nostro carico di lavoro abbiamo selezionato una ml.p3.2xlarge per il testing e l\u2019esplorazione dei dati e una ml.g4dn.2xlarge per il training dei modelli.<\/p>\n\n\n\nInstallare RapidsAI su una istanza di ML<\/h2>\n\n\n\n
conda create -n rapids-0.17 -c rapidsai -c nvidia -c conda-forge \\\n -c defaults rapids-blazing=0.17 python=3.7 cudatoolkit=10.1\n<\/pre>\n\n\n\n
DBSCAN<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Parametri:<\/h2>\n\n\n\n
Riduzione di Dimensionalit\u00e0<\/strong><\/h2>\n\n\n\n
Metrica obiettivo: il Silhouette score<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Amazon SageMaker Experiments: analisi ad ampio spettro<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Impostare gli utenti per SageMaker Studio<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
Alcuni concetti Chiave<\/h2>\n\n\n\n
Come creare degli Experiments nei notebook<\/h2>\n\n\n\n
import sagemaker\nfrom smexperiments.experiment import Experiment\nfrom sagemaker import get_execution_role\nfrom sagemaker.session import Session\n\nexperiment_name=\"my-TestExperiment\"\n\nrole = get_execution_role()\nsession=Session()\nsm_client=session.boto_session.client('sagemaker')\n\nexperiment = None\nfor exp in Experiment.list():\n if exp.experiment_name==experiment_name:\n experiment = Experiment.load(experiment_name=experiment_name,sagemaker_boto_client=sm_client)\n print(f\"Experiment {experiment_name} is loaded!\")\n break;\n \nif experiment == None:\n experiment = Experiment.create(\n experiment_name = experiment_name,\n description = \"My Test Experiment\",\n tags = [{'Key': 'project', 'Value': 'customer-segmentation'}]\n )\n print(f\"Experiment {experiment_name} is created!\")\n<\/pre>\n\n\n\n
I Trials<\/h2>\n\n\n\n
from smexperiments.trial import Trial\nfrom smexperiments.trial_component import TrialComponent\nfrom smexperiments.tracker import Tracker\n\nimport time\nfrom time import strftime\n\ntrial_create_date = strftime(\"%Y-%m-%d-%H-%M-%S\")\ntrial_name =\"test-trial-{}\".format(trial_create_date)\n\ntrial = None\ntry:\n trial = Trial.load(trial_name, sagemaker_boto_client=sm_client)\n print(f\"Trial {trial_name} is loaded!\")\nexcept:\n trial = Trial.create(trial_name = trial_name,\n experiment_name = experiment.experiment_name,\n tags = [{'Key': 'my-experiments', 'Value': 'trial 1'}])\n print(f\"Trial {trial_name} is created!\")\n<\/pre>\n\n\n\n
Gli Estimator<\/h2>\n\n\n\n
estimator.fit(\ninputs={\"train\":sagemaker.session.s3_input(s3_data=data_location)},\n wait=True,\n logs='All',\n experiment_config={\n \"ExperimentName\":experiment.experiment_name,\n \"TrialName\" : trial.trial_name,\n \"TrialComponentDisplayName\" : \"Training\",\n }\n)\n<\/pre>\n\n\n\n
Inviare le informazioni alla dashboard di SageMaker Experiment<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Il Tracker<\/h2>\n\n\n\n
Dopo aver definito i parametri di ingresso (gli argomenti dello script), si pu\u00f2 aggiungere un Tracker in questo modo:<\/p>\n\n\n\n# Loading Sagemaker Experiments Training Tracker\ntracker=tracker.Tracker.load()\n<\/pre>\n\n\n\n
tracker.log_parameters({ \"param1\": NUM, \"param2\": NUM, ...})<\/pre>\n\n\n\n
<\/figure>\n\n\n\n
tracker.log_input(\u201ckey\u201d, \u201cvalue\u201d, media_type=TYPE)<\/pre>\n\n\n\n
<\/figure>\n\n\n\n
tracker.log_output(name=\"Some link name\", media_type=\"s3\/uri\", value=s3_uri)<\/pre>\n\n\n\n
<\/figure>\n\n\n\n
tracker.close()<\/pre>\n\n\n\n
Confrontare i Trials nella dashboard di SageMaker Studio<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Un dettaglio<\/h2>\n\n\n\n
Significa eseguire il training su un’istanza appena creata, invece di eseguirlo direttamente sull’istanza in cui risiede il notebook.<\/p>\n\n\n\nReferenze<\/h2>\n\n\n\n
Riassumiamo un p\u00f2!<\/h2>\n\n\n\n
Nel nostro viaggio insieme a voi, abbiamo utilizzato queste nuove funzionalit\u00e0 per condividere meglio i risultati nel nostro team e con il cliente e per coordinare agevolmente gli sforzi degli ingegneri coinvolti.<\/p>\n\n\n\n