Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Questo tema è ancora molto discusso. C’è chi ama gli Jupyter Notebook e chi li odia. In questo articolo vorrei parlare un pò dei pro e contro di questo strumento e capire quali vantaggi potrebbe avere un data scientist lavorando con un IDE.
Un Jupyter Notebook è una web application interattiva che permette di lavorare e condividere documenti computazionali. Ciò significa che in tali notebook possiamo inserire testo, immagini, video, hyperlink come nei comuni documenti (word ad esempio), ma anche codice che può essere eseguito all’interno del notebook stesso.
I notebook sono molto apprezzati dai Data Scientist poiché consentono di condurre esperimenti e ricerche sui modelli e sui dati, permettendo contemporaneamente di annotare le osservazioni nelle celle adiacenti al codice. Questi strumenti risultano inoltre estremamente utili nell’ambito dell’insegnamento, sfruttando la medesima caratteristica.
Anche Google offre la possibiltà di creare Jupuyter Notebook sulla loro piattaforma Google Colab.
Ciò consente l’integrazione di Google Drive direttamente nel notebook, risultando utile nel caso in cui si disponga di un dataset memorizzato su Drive e si desideri utilizzarlo per condurre esperimenti. Tuttavia, il motivo predominante per l’ampio utilizzo di Colab risiede nell’hardware, RAMe GPU, che entro certi limiti mette a disposizione gratuitamente. Attualmente, la GPU rappresenta un bene prezioso nel mondo tech, poiché la maggior parte degli esperimenti di Machine/Deep Learning richiede l’impiego di tale risorsa.
Oltre a Google stanno nascendo altri fornitori di che forniscono un ecosistema creato sui notebook. Primo tra tutti Deepnote che fornisce un ecosistema costruito sui notebook che a differenza di jupyter fornisce anche l AI per la code completion come assistente di sviluppo.
Oltre a Google, stanno emergendo altri fornitori con ecosistemi basati sui notebook. Deepnote è uno dei principali, offrendo un ambiente costruito sui notebook e, a differenza di Jupyter, fornisce un’intelligenza artificiale per il completamento automatico del codice, agendo come assistente nello sviluppo.
Ma allora perchè c’è gente che non apprezza questi notebook?
I programmotori quando sviluppano software utilizzano degli ambiente di sviluppo integrati o IDE. Gli IDE delle applicazioni utilizzate per lo sviluppo software che agevola il lavoro di chi scrive codice. Ogni programmatore ha il suo IDE preferito, scelto in base a strumenti, estetica, facilità di utilizzo. Io ad esempio utilizzo VSCode.
Quando sviluppiamo software nel mondo AI, abbiamo bisogno di figure lavorative eterogenee, come matematici e statistici, ma alla fine quello che andiamo ha produrre è del codice. Pe questo sono dell’opinione che chi fà AI, dovrebbe seguire le comuni best practice di sviluppo che purtroppo un Notebook non ti permette di avere.
Di seguito elenco alcune delle best practice che voglio evidenziare nello sviluppo software che non si possono implementare quando utilizziamo i notebook.
Scrivere codice che non contenga bug è utopia. Qualsiasi programmatore, anche i piu senior, scrivono codice che presentano degli errori. La bravura è nello scovarli e risolverli. Tutti gli IDE hanno dei debugger incorporati. Il debugger è uno strumento che permette ti interrompere l’esecuzione del codice sorgente in qualsiasi punto si voglia. In questo modo si puo controllare il contenuto delle variabili in un dato momento e capire meglio cosa stia succedendo, ed auspicabilmente trovare il bug!
Negli Jupyter Notebooks, l’unica cosa che possiamo fare è scrivere codice una riga dopo l’altra. Spesso ritrovandoci a scrivere notebook lunghissimi. Inoltre l’ordine in cui eseguiamo le celle è importante. Nel caso in cui le celle non vengano eseguite nell’ordine previsto, il codice si rompe.
L’ IDE ci permette di dividere il codice in piu file. Ogni file (o modulo) è specializzato in qualche operazione, ad esempio possiamo avere un modulo solamente sul data pre-processing che può essere riutilizzato quante volte vogliamo importandolo in altri file.
Quando scriviamo una funzione, come facciamo a sapere che questa è davvero robusta? Potrebbe sembrarci di aver scritto del codice resistente che poi scopriamo essere suscettibile a particolari input da parte degli utenti. Per qusto motivo si creano dei test, cioè altre funzioni che testano una parte di codice in particolare (come una funzione o una classe) provando a romperla. Un po come uno stress test. Se il codice supera questi test, siamo abbastanza confidenti che sia scritto bene e possiamo metterlo in produzione.
I Notebook non sono versionabili. In programmazione si utilizzano tool come Git e GitHub, poichè il codice viene iterativamente modificato e migliorato. A volte le varie versioni possono confonderci e capita di dimenticare quale sia la migliore versione del codice. Qui git viene in nostro soccorso, perchè mantiene per noi lo storico di tutte le versioni sviluppate e possiamo cosi aprire e continuare a lavorare da qualsiasi versione preferiamo.
Non è insolito trovare data scientist che creano numerosissimi notebook intitolati “final_notebook.ipynb”, “super_final_notebook.ipynb”, “best_notebook.ipynb” etc…
Immaginate di aver scritto una pipeline di training per fare il fine-tuning del vostro large language model personale. Il fine-tuning impiega ore se non giorni. Quando tornate davanti al vostro laptop, scoprite che l’esecuzione del codice si è interrotta per qualche motivo, ma non avete idea di quale sia il motivo. Come risolvere?
All’interno del codice potete inserire dei log. Sono come dei semplici print ma molto piu customizzabili. Si possoo creare log per segnalare informazioni generali, warning, erorri e altro ancora. E si può anche customizzare il modo in cui i messaggi vengono visualizzati. Ovviamente i log possono essere messi su file, cosi che non dobbiamo stare a fissare continuamente il terminale come facciamo con i print, e al termine di un esecuzione possiamo leggere i log e avere informazioni di cosa è successo durante l’esecuzione.
Io contituo ad utilizzare molto i Jupyter Notebook perchè spesso li trovo estremamente utili. Ad esempio quando preparo delle lezioni di AI, cerco sempre di utilizzare Colab, in modo da condividere e presentare il mio codice facilmente agli studenti.
Sono anche utili per la prototipazione rapida. Quando voglio farmi un idea sulle capacità di un particolare modello, con un Notebook posso farlo in pochissimo tempo.
Quando si parla però di passare allo sviluppo di un software vero e proprio, secondo me bisogna cercare di passare subito all’utilizzo di un IDE abbandonando il Notebook. Ad oggi molti data scientist vengono da background scientifici come fisica e matematica, per questo non hanno familiarità con le best practice di sviluppo e rimangono nella loro confort zone utilizzando i notebook. Il mio consiglio è quello di iniziare da subito a prendere confidenza con queste best practice descritte in questo articolo per sviluppare codice che sia leggibile, riproducibile e pronto per la produzione!
