Non sono uno scienziato dei dati, pur conoscendo bene il notebook Jupyter e avendo scritto una buona quantità di codice Python, non mi ritengo un esperto di apprendimento automatico. Quindi, quando ho eseguito la prima parte del nostro esperimento di apprendimento automatico no-code/low-code e ho ottenuto un tasso di accuratezza superiore al 90% su un modello, ho sospettato di aver fatto qualcosa di sbagliato.
Per vedere quanto sono avanzati gli strumenti di apprendimento automatico e per riscattarmi del compito impossibile che mi era stato assegnato con l'apprendimento automatico l'anno scorso, ho preso un set di dati sull'infarto da un archivio dell'Università della California-Irvine e ho cercato di superare i risultati degli studenti di scienze dei dati usando il " easy button" degli strumenti low-code e no-code di Amazon Web Services.
Lo scopo di questo esperimento era quello di vedere:
- Se un relativo novizio potesse usare questi strumenti in modo efficace e accurato;
- Se gli strumenti fossero più efficaci dal punto di vista dei costi rispetto a trovare qualcuno che sapesse cosa diavolo stava facendo e affidarglielo.
Questo non è esattamente un quadro fedele di come si svolgono di solito i progetti di apprendimento automatico. E come ho scoperto, l'opzione "no-code" offerta da Amazon Web Services - SageMaker Canvas - è pensata per lavorare in parallelo con l'approccio più orientato alla scienza dei dati di SageMaker Studio. Ma Canvas ha superato quello che sono riuscito a fare con l'approccio low-code di Studio, anche se probabilmente a causa delle mie mani poco esperte nella gestione dei dati.
Valutazione del lavoro del robot
Canvas mi ha permesso di esportare un link condivisibile che apriva il modello che ho creato con la mia build completa dalle oltre 590 righe di dati dei pazienti della Cleveland Clinic e dell'Hungarian Institute of Cardiology. Quel link mi ha permesso di capire meglio cosa succede all'interno della scatola nera di Canvas con Studio, una piattaforma basata su Jupyter per la realizzazione di esperimenti di data science e machine learning.
Come suggerisce il nome, Jupyter è basato su Python. Si tratta di un'interfaccia basata sul web per un ambiente di container che consente di creare kernel basati su diverse implementazioni di Python, a seconda del compito da svolgere.
I kernel possono essere popolati con qualsiasi modulo richiesto dal progetto quando si effettuano esplorazioni incentrate sul codice, come la libreria di analisi dei dati Python (pandas) e SciKit-Learn (sklearn). Ho usato una versione locale di Jupyter Lab per fare la maggior parte dell'analisi iniziale dei dati, per risparmiare sul tempo di calcolo AWS.
L'ambiente Studio creato con il collegamento a Canvas includeva alcuni contenuti precostituiti che fornivano informazioni sul modello prodotto da Canvas.
Tra i dettagli vi sono gli iperparametri utilizzati dalla versione meglio sintonizzata del modello creato da Canvas:
Gli iperparametri sono modifiche apportate da AutoML ai calcoli dell'algoritmo per migliorare l'accuratezza, oltre ad alcune operazioni di base: i parametri dell'istanza di SageMaker, la metrica di sintonizzazione ("F1", di cui parleremo tra poco) e altri input. Si tratta di parametri piuttosto standard per una classificazione binaria come la nostra.
La panoramica del modello in Studio forniva alcune informazioni di base sul modello prodotto da Canvas, tra cui l'algoritmo utilizzato (XGBoost) e l'importanza relativa di ciascuna colonna valutata con valori chiamati SHAP. SHAP è un acronimo davvero orribile che sta per "SHapley Additive exPlanations", un metodo basato sulla teoria dei giochi per estrarre il contributo di ciascuna caratteristica dei dati a un cambiamento nell'output del modello. È emerso che la "frequenza cardiaca massima raggiunta" aveva un impatto trascurabile sul modello, mentre la talassemia ("thall") e i risultati dell'angiogramma ("caa") - punti di dati per i quali avevamo dati mancanti significativi - avevano un impatto maggiore di quello che volevo. A quanto pare, non potevo lasciarli perdere. Ho quindi scaricato un rapporto sulle prestazioni del modello per ottenere informazioni più dettagliate sulla sua tenuta:
Nelle statistiche del modello Canvas per il nostro set di dati, vediamo che il tasso di individuazione dei veri negativi (non un attacco cardiaco) è molto più alto di quello dei veri positivi (sicuramente un attacco cardiaco): 94% contro 86%. Ci sono alcuni altri dati importanti dal punto di vista statistico: la precisione del modello, il richiamo del modello e il punteggio F1 del modello.
- Precisione: Il numero totale di veri positivi (il numero di volte in cui il modello ha indovinato "attacco cardiaco" correttamente) diviso per il numero totale di positivi (tutte le ipotesi di "attacco cardiaco", sia corrette che errate).
- Richiamo: Il numero totale di veri positivi (ipotesi corrette sull'infarto) diviso per il numero totale di quelli che avrebbero dovuto essere positivi.
- Il punteggio F1 è una misura utilizzata per bilanciare l'accuratezza. È la media armonica di precisione e richiamo, che valuta il modello in base alla sua capacità di trovare la categoria desiderata. Si calcola moltiplicando precisione e richiamo, dividendoli per la somma di precisione e richiamo e moltiplicando per due. (Come in F1 = 2 * ((Precisione * Richiamo) / (Precisione + Richiamo))).
La precisione del modello Canvas è stata di 0,86, il che significa che quando ha classificato un paziente come uno che avrebbe avuto un attacco di cuore, ha avuto ragione l'86% delle volte. Il richiamo, ossia la percentuale di pazienti classificati correttamente come affetti da infarto, è stato pari a 0,84. Il valore F1 (0,85) rappresenta l'accuratezza bilanciata del modello.
Un altro modo per osservare le prestazioni del modello è la cosiddetta "matrice di confusione", un riquadro che mostra la distribuzione delle categorizzazioni corrette ed errate:
Si può notare che per 59 volte - 9,88% del tempo - il modello ha visto casi di infarto reali e li ha classificati come "non infarto".
Quando si cerca di prevedere qualcosa di così grave come un infarto, si vuole che il valore dei falsi negativi sia il più basso possibile (e che il valore F1 sia il più alto possibile). Volevo quindi vedere se potevo ottenere prestazioni migliori dai dati in mio possesso, utilizzando le mie limitate competenze in materia di scienza dei dati.
Non ci sono riuscito.
Arriva il Data Wrangler
Nel tentativo di migliorare le cose, ho iniziato a usare Data Wrangler di SageMaker per intervenire sulla qualità discutibile dei miei dati. Ho aperto una nuova scheda Launcher in Studio e ho iniziato:
Seguendo le procedure che avevo imparato cinque minuti prima leggendo un tutorial, ho creato un nuovo flusso di dati:
Ho lanciato una nuova applicazione Data Wrangler nel cloud EC2 e ho sentito che il mio budget di calcolo si stava prosciugando. Ho quindi puntato Data Wrangler sulla mia tabella di valori separati da virgole, l'ho aspirata e ho iniziato a digerirla. Speravo che qualche trasformazione magica dei dati avrebbe migliorato le cose.
La prima cosa che ho fatto è stata guardare come sono stati digitati i dati:
Tutto è stato visto come un intero lungo, tranne "slp", "caa" e "thall", che sono stati letti come stringhe. Perché stringhe? Alcune celle erano vuote, quindi forse venivano lette come etichette. C'erano anche dei punti interrogativi in alcune celle (che pensavo di aver eliminato), il che significava chiaramente che dovevo fare un'ulteriore pulizia.
Per rendermi conto dell'entità degli interventi necessari, ho eseguito un'analisi della qualità dei dati, che ha generato una serie di statistiche sulla tabella che avevo importato. Il file è scaricabile, ma solo come file grafico .PNG, il che non è molto utile a meno che non si creino rapporti di analisi a partire da schermate. Ma meglio di niente. (Come regola generale, i notebook di SageMaker non sono molto adatti a produrre dati in un formato con cui si possa fare qualcosa oltre a mostrare quanto è bello SageMaker).
Qui ho imparato alcune lezioni. Mancava poco più del 10% dei miei dati: lo spazio lasciato dai dati ungheresi per quelle due colonne di dati purtroppo importanti. Potevo provare a riempire quei campi con qualcosa, ad esempio contrassegnandoli come nulli, oppure potevo guardare le previsioni e lasciarli lì.
Ho deciso di individuare dove si trovavano esattamente tutti i dati mancanti prima di andare avanti. I valori SHAP previsti qui erano diversi da quelli ottenuti dal modello Canvas. La mia analisi ha anche mostrato che "thall" e "caa" erano entrambi molto importanti e mancavano di dati in oltre il 40% delle loro righe.
Inoltre, una rapida analisi del modello, che è una previsione di quanto bene farà il modello costruito dai dati, non è stata particolarmente incoraggiante. Sebbene estremamente accurati per i punteggi di addestramento, i punteggi di convalida previsti erano peggiori di quelli ottenuti dal modello Canvas:
Per ottenere un conteggio esatto delle righe mancanti, ho eseguito un singolo comando Python PANDAS in una fase di trasformazione dei dati personalizzata:
È emerso che c'erano alcuni altri punti in cui mancavano dei dati. E non potevo semplicemente eliminare le righe in cui mancavano i dati, altrimenti non avrei avuto abbastanza dati per costruire il modello. Quindi, la prima volta, ho provato a eliminare completamente le colonne peggiori e a eliminare solo le righe con i dati mancanti per le altre colonne:
Ho quindi esportato i dati direttamente in un lavoro di formazione e ho sperato di ottenere dei miglioramenti.
Non ho ottenuto miglioramenti, Ho ottenuto l'83% di precisione e un F1 di 0,79. Ancora peggio.
Questa volta è quella giusta
Quindi sono tornato ai dati. Ho deciso che se non potevo correggere i dati mancanti, avrei semplicemente sovracampionato i dati completi. Ho eliminato le righe mancanti di "thall" e "caa".
Questa volta ho aggiunto una trasformazione per sovracampionare i dati e ampliare il set per il modello, utilizzando una selezione casuale. Poi ho eseguito il lavoro di modellazione con le dita incrociate.
Due ore dopo ho avuto i miei risultati. Non erano eccezionali, ma nemmeno terribili.
Lo scrubbing e il miglioramento dei dati mi hanno permesso di ottenere alcuni risultati, ma non sono stati all'altezza delle precedenti prestazioni di Canvas. L'accuratezza complessiva era dell'85%, con un tasso di veri negativi (indovinare correttamente "nessun attacco cardiaco") del 90%. Il punteggio F1 è salito a 0,81: non è ancora qualcosa su cui scommetterei la vita o la morte, ma è molto più preciso di quanto non fosse prima. Il richiamo era il vero freno: 0,78. La matrice di confusione racconta la storia:
Tuttavia, un tasso di falsi negativi dell'8,9% non è terribile.
Misurare il mitico mese umano
Ci sono ovvi limiti a quanto avrei potuto fare con i dati disponibili con questi strumenti. I risultati del Canvas sono stati probabilmente il meglio che ho potuto fare con il set di dati, data la mia limitata esperienza in statistica e analisi dei dati, la qualità piuttosto mediocre dei dati e i limiti dei dati stessi. Se avessi avuto a disposizione i dati completi delle misurazioni cardiache di 1.000 pazienti, sarebbe stato molto più facile ottenere un modello accurato, sempre che i dati ne contenessero uno.
D'altra parte, i miei sforzi con Data Wrangler e AutoML non sono stati terribili. Quando ho rivisto alcuni quaderni di persone che avevano dichiarato un'accuratezza del 90% solo con un set di dati abbreviato e perfetto, mi sono reso conto che avevano fatto qualche arrotondamento. Un esempio ha raggiunto un'accuratezza del 90% con un modello di regressione lineare, ma la persona non ha calcolato la precisione, il richiamo o la F1. La maggior parte dei risultati, utilizzando una serie di modelli, si attestava intorno alla metà degli 80 anni per quanto riguarda l'accuratezza.
Considerando tutto ciò, l'esecuzione di Canvas - che ha richiesto circa un'ora e 45 minuti in totale, dall'inserimento dei dati al modello - è stata una vittoria anche rispetto al tempo che ho impiegato per l'analisi iniziale dei dati. E ha prodotto risultati migliori rispetto agli sforzi compiuti a mano da tutti i data scientist umani che hanno utilizzato il set di dati (anche se con un po' di dati in più). Il " easy button" ha avuto la meglio su John Henry.
È evidente che dietro le quinte di Canvas si nascondono molte magie che non vengono svelate. La gestione dei dati è tutta automatizzata, quindi è difficile dire che cosa sia stato fatto per migliorare l'uso del set di dati con dati mancanti e per produrre il risultato. Quindi, come strumento per gli analisti aziendali è ottimo, ma di certo non li trasformerà in scienziati dei dati. E va bene così, perché gli analisti aziendali e gli scienziati dei dati sono animali completamente diversi, anche se spesso risolvono problemi simili.
Parlando con Ars, il Senior Product Manager di Amazon Web Services Danny Smith ha spiegato un enigma non ovvio: aspettare che un data scientist analizzi i propri dati "è come aspettare un progetto IT", ha detto, notando che i clienti analisti aziendali gli hanno detto cose come: "Dobbiamo aspettare 18 mesi per arrivare in cima alla coda". E poi i data scientist, che sono tutte risorse scarse, dicono: "Bene, ok, qual è il ROI del progetto?"".
Smith ha continuato: "E l'analista aziendale dice: 'Se lo sapessi, non avrei bisogno del tuo aiuto! Ho questi dati, ho un problema di business. Ho delle domande su questi dati. Non so quanto valgono finché non facciamo l'analisi". Quindi l'analista di business sta pensando di accelerare fino al punto in cui può effettivamente argomentare o giustificare l'uso di un data scientist scarso".
L'approccio di Data Wrangler e AutoML è stato una vittoria meno decisiva. Probabilmente avrei potuto fare un lavoro migliore con una maggiore esperienza e competenze effettive di data science. Ma anche con alcuni metodi di trasformazione dei dati predefiniti, i miei sforzi di modellazione non sono stati all'altezza del gruppo di professionisti dell'apprendimento automatico più preparati.
Dichiaro la vittoria dell'apprendimento automatico guidato dalle macchine, almeno in termini di riduzione dello sforzo. Il tempo di calcolo che ho speso per l'intero progetto è stato di circa 1.000 dollari e ho impiegato circa sei ore di lavoro effettivo con gli strumenti, la maggior parte del tempo in Studio. La parte di Canvas, che ha consumato circa 300 dollari di calcolo per i miei due modelli tentati, ha richiesto solo due ore, compreso il tempo di costruzione del modello.
In confronto, ho stimato che l'impegno umano richiesto per il progetto fosse compreso tra uno e tre giorni, a seconda della piattaforma utilizzata e dell'abilità del data scientist. Ma non direi che questi strumenti sostituiscano in alcun modo la necessità dei data scientist. Semmai sono utili per elaborare modelli rapidi per valutare i problemi analitici più quotidiani di un'organizzazione.
Tuttavia, non sono così sicuro di fidarmi di loro per prevedere gli attacchi di cuore.
Di Sean Gallagher