Un argomento contro l’utilizzo di Jupyter Notebook per Machine Learning
Come sottolineato da Damien Benveniste, un leader tecnologico di apprendimento automatico presso Meta, in un post dettagliato su LinkedIn, Jupyter non riesce a fornire un “quadro robusto per la riproducibilità e una base di codice manutenibile per i sistemi ML”.
Joel Grus, un ricercatore dell’Allen Institute for Artificial Intelligence, è intervenuto a una conferenza degli sviluppatori Jupyter in cui ha tenuto una presentazione intitolata “Non mi piacciono i taccuini”. Ha detto: “Da una parte, hai l’idea che nessun libro è ottimo per lo sviluppo iterativo, ma poi hai anche l’idea che i quaderni sono in realtà un po’ pericolosi a meno che tu non esegua ogni cella esattamente una volta in ordine, e altrimenti non puoi fare davvero affidamento e quali sono le uscite delle cellule, quindi c’è questa tensione lì che mi mette un po’ a disagio”.
Le piattaforme informatiche come Jupyter Notebook sono diventate onnipresenti tra gli ingegneri dell’apprendimento automatico e i data scientist. Una piattaforma interattiva basata sul Web, Jupyter, supporta la programmazione multilingua, le celle Markdown, la formattazione semplice e consente scritture più dettagliate. Inoltre, la crescente industria del software aperto e la maturazione del Python scientifico hanno aumentato l’uso di Jupyter Notebooks. Inoltre, come ha affermato Fernando Pérez, il co-fondatore, la popolarità di Jupyter è cresciuta rapidamente grazie ai miglioramenti apportati al software web che ha aiutato a guidare applicazioni come Gmail e Google Docs: ciò facilita l’accesso a dati remoti altrimenti poco pratici da Scarica.
Sebbene Jupyter sia stato un vantaggio per i data scientist, ci sono alcuni inconvenienti di cui bisogna stare attenti. Come sottolineato da Damien Benveniste, un leader tecnologico di apprendimento automatico presso Meta, in un post dettagliato su LinkedIn, Jupyter non riesce a fornire un “quadro robusto per la riproducibilità e una base di codice manutenibile per i sistemi ML”. In questo articolo, discuteremo alcuni dei principali ostacoli che potrebbero ostacolare l’adozione di Jupyter Notebooks.
Flusso di lavoro non lineare
Grus ha affermato che Jupyter che esegue le celle di codice fuori servizio era fonte di grande frustrazione tra i programmatori. Ha inoltre affermato che Jupyter incoraggia pratiche di codifica scadenti rendendo difficile l’organizzazione logica del codice, la scomposizione in componenti riutilizzabili e lo sviluppo di test per verificare se il codice funziona correttamente.
Il “salto” tra le celle del Jupyter Notebook si traduce in esperimenti non riproducibili.
Modularità
Jupyter richiede ai data scientist di inserire la maggior parte del codice direttamente nelle celle in modo da utilizzare gli strumenti interattivi nel modo più efficace. Tuttavia, per rendere il codice modulare, sarebbero necessarie molte funzioni, classi, ecc. In generale, un codice modulare non avrebbe altro che funzioni, classi, definizioni di importazione e variabili che toccano il margine sinistro, ma con Jupyter Notebook tutto è estremo allineato a sinistra.
La cosa più importante quando si scrive un esperimento di data science ripetibile è scrivere codice modulare e robusto. Tuttavia, i notebook Jupyter non sono progettati per essere modularizzati. Ciò significa anche che riprodurlo in un altro ambiente è difficile. Anche se proviamo a farlo, dovremmo prima riprodurlo nell’ambiente in cui è stato eseguito il codice e i notebook di base non offrono questa disposizione.
Difficile da testare
Il test aiuta a verificare se un determinato programma soddisfa i requisiti e continua a funzionare quando vengono applicate modifiche o iterazioni. Poiché i notebook non sono moduli, testarli è impegnativo. Combinano il codice di test con il codice narrativo del notebook. Jupyter è utilizzato principalmente per software scientifico e analisi dei dati e testare questo tipo di software è difficile. Ciò accade principalmente a causa della mancanza di oracoli e della difficoltà di prevedere il numero di prove necessarie per garantirne la correttezza. Inoltre, se i programmatori distribuiscono codice che viene eseguito più volte, potrebbero preferire farlo negli script Python.
