master-thesis/src/chapter_2.md

Stato dell'arte

In questo capitolo verranno presentati diversi lavori di ricerca alla base di questo studio. I lavori, sebbene tutti incentrati sul \ac{ML}, vanno ad approfondire diversi aspetti. In alcuni casi l'attenzione principale è rivolta alle difficoltà e alle problematiche riscontrate dagli sviluppatori. In altri casi viene svolto un confronto tra progetti di \ac{ML} e progetti generici o tra progetti che fanno uso di diversi framework di \ac{ML}. Infine viene anche presentato un lavoro sulla complessità del processo di cambiamento del software e su i suoi effetti sull'introduzione di difetti.

\section[Confronto tra progetti di ML e progetti generici]{Confronto tra progetti di machine learning e progetti generici}

Nello studio di Gonzalez et al. [@gonzalez2020statemluniverse10] vengono presentate le principali differenze tra i repository di \ac{ML} e i progetti classici. I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposizione di GitHub attraverso la quale è stato possible collezionare i dati associati a 9325 progetti open source così raggruppati:

• 5224 progetti legati all'\ac{AI} e al \ac{ML} divisi a loro volta in:
  • 700 tools e framework
  • 4524 applicazioni
• 4101 progetti generici

Gli aspetti considerati dallo studio sono molteplici e di varia natura. Una prima analisi è stata condotta rispetto alla nascita dei vari repository. In questo modo è stato possibile individuare nel 2017 l'anno della forte crescita dei repository di \ac{AI} & \ac{ML}. Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \ac{ML} rispetto a quelli generici.

Una seconda analisi ha permesso di comprendere come varia la partecipazione ai vari progetti. Per poter svolgere questa analisi i contributori sono stati divisi in:

• esterni: i loro contributi sono limitati ad aprire issue e commentare le discussioni.
• interni: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issue o eseguito dei commit sul progetto.

In base a questa divisione si è visto come i tools di \ac{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici. Quest'ultimi però hanno una maggiore partecipazione esterna. Se invece l'analisi viene svolta considerando unicamente gli autori dei commit si scopre che i progetti generici mediamente hanno più contributors, ma i top 4 repository con più committer sono tutti legati al mondo del \ac{ML}.

Un'ulteriore analisi è stata svolta anche per quanto riguarda il linguaggio con cui sono stati realizzati i vari progetti. Sia nel caso delle applicazioni che nei tools di \ac{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia. Nel caso dei tools questa è occupata da C++, mentre nelle applicazioni dai Notebook Jupyter. Nei progetti generici invece Python occupa solo la terza posizione in quanto a popolarità e le prime due sono occupate da JavaScript e Java.

Analisi in base al framework utilizzato

Nello studio di Han et al. [@han2020empiricalstudydependency] sono stati considerati 1150 progetti GitHub così distribuiti:

• 708 progetti che dipendono da TensorFlow.
• 339 progetti che dipendono da PyTorch.
• 103 progetti che dipendono da Theano.

Per poter classificare i progetti manualmente gli autori hanno considerato il nome del progetto, la descrizione, le label e il contenuto del readme. La classificazione è avvenuta sia rispetto all'obiettivo del progetto sia rispetto al dominio applicativo. Come obiettivi dei progetti sono stati considerati:

• Competitions: progetti realizzati per la partecipazione a delle competizioni o sfide.
• Learning & Teaching: progetti realizzati per libri e/o tutorial o per esercitarsi.
• Paper Experiments: progetti realizzati al fine di ricerca.
• Software Development: comprende librerie, plug-in, tools ecc.
• Other

La classifica delle librerie più utilizzate è rimasta sostanzialmente invariata per tutte le categorie; il primo posto è occupato da TensorFlow seguito da PyTorch e Theano. L'unica eccezione riguarda i progetti realizzati a fini di ricerca. In questo caso TensorFlow e PyTorch sono in posizioni invertite. Anche per quanto riguarda la classificazione rispetto al dominio applicativo la situazione è costante. Infatti, indipendentemente dalla libreria utilizzata, i progetti più frequenti sono quelli che hanno a che fare con video e immagini e con il \ac{NLP}.

Un'ulteriore \ac{RQ} ha valutato il tipo di dipendenza, facendo distinzione tra dipendenze dirette e indirette. Per tutte è tre le librerie si è visto che è più probabile avere una dipendenza diretta che indiretta. PyTorch è la libreria che più frequentemente è importata direttamente, mentre Theano ha una probabilità di essere importata direttamente quasi uguale a quella di essere importata indirettamente.

Un'ulteriore analisi è stata condotta per individuare quanto frequentemente i progetti aggiornano le loro dipendenze o eseguono dei downgrade. In questo caso si è visto che i progetti basati su TensorFlow e PyTorch aggiornano le proprie dipendenze molto più frequentemente rispetto ai progetti basati su Theano. Mentre il tasso di downgrade è sostanzialmente equivalente. Nel caso dei progetti che dipendono da TensorFlow la maggior parte dei downgrade viene spiegata dalla volontà di non utilizzare la nuova \ac{API} introdotta nella versione 2.0 della libreria. Sempre analizzando la versione della libreria utilizzata si è visto che i progetti basati su Theano sono quelli che utilizzano più frequentemente l'ultima versione disponibile della libreria.

In un altro lavoro, Han et al. [@han2020whatprogrammersdiscuss] hanno spostato il focus sugli argomenti di discussione e su come questi variano in base al framework utilizzato. In questo caso all'interno dei dataset non sono rientrati unicamente i dati recuperati da GitHub, ma anche le discussioni su \ac{SO}.

Questo studio ha permesso di evidenziare differenze e similitudini per quanto riguarda le discussioni che si generano intorno ai tre framework di interesse. In particolare emerge che le fasi più discusse sono quelle di model training e di preliminary preparation. Mentre la fase meno discussa è quella di model tuning. Per quanto riguarda le differenze, dallo studio, emerge che TensorFlow e PyTorch hanno topic di discussione totalmente confrontabili. Oltre ai topic citati precedentemente, per questi framework, si discute molto anche della data preparation. Mentre le discussioni riguardanti Theano sono quasi esclusivamente concentrate sul model training.

Da questi due studi si evince una forte somiglianza per quanto riguarda TensorFlow e PyThorch. La principale differenza viene riscontrata per quanto riguarda i campi di applicazione, con TensorFlow che viene generalmente preferito fatti salvi gli ambiti di ricerca. Mentre Theano presenta molte diversità sia per quanto riguarda gli impieghi che le discussioni.

\section[Analisi dei progetti di ML multi-linguaggio]{Analisi dei progetti di machine learning multi-linguaggio}

Lo studio di Grichi et al. [@grichi2020impactmultilanguagedevelopment] si concentra sui sistemi multi-linguaggio. In questo caso si vuole comprendere se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi. Inoltre analizzando le \ac{PR} realizzate in più linguaggi si vuole investigare se queste sono accettate con la stessa frequenza di quelle mono-linguaggio e se la presenza di difetti è equivalente.

L'analisi è stata svolta su 27 progetti open source hostati su GitHub. I progetti sono poi stati classificati in tre categorie:

• Cat I: include 10 sistemi di \ac{ML} multi-linguaggio.
• Cat II: include 10 sistemi generici multi-linguaggio.
• Cat III: include 7 sistemi di \ac{ML} mono-linguaggio.

Successivamente sono state scaricate le \ac{PR} di ogni progetto considerato. Le \ac{PR} sono state categorizzate per individuare quelle accettate e quelle rifiutate. Inoltre le \ac{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati. In questo modo è stato possibile individuare le \ac{PR} mono-linguaggio e quelle multi-linguaggio. Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \ac{PR}.

Per quanto riguarda la percentuale di linguaggi di programmazione utilizzati i progetti della categoria I e II sono comparabili. La principale differenza riguarda i tipi di linguaggi utilizzati. Nel caso dei progetti multi-linguaggio di \ac{ML} l'accoppiata più comune è Python e C/C++. Mentre nel caso dei progetti generici la coppia più comune è data da Java e C/C++. I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR} e \ac{PR} multi-linguaggio.

Lo studio ha evidenziato come all'interno dei progetti di \ac{ML} le \ac{PR} mono-linguaggio sono accettate molto più facilmente rispetto a quelle multi-linguaggio. Inoltre anche nel caso in cui queste vengano accettate, il tempo necessario alla loro accettazione è maggiore. Infine si è visto anche che rispetto alle \ac{PR} multi-linguaggio non esistono differenze in base all'introduzione di bug tra i progetti della categoria I e II. Mentre le \ac{PR} che includono un singolo linguaggio sembrano essere più affette da bug nel caso dei sistemi di \ac{ML}.

\section[Problematiche caratteristiche del ML]{Problematiche caratteristiche del machine learning}

In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei bug riscontrati all'interno di applicazioni di \ac{ML}. Nello studio di Zhang et al. [@zhang2018empiricalstudytensorflow] l'attenzione è rivolta unicamente alle problematiche correlate a TensorFlow. Per lo studio sono stati recuperati dei bug di TensorFlow sia da progetti su GitHub (88 elementi) sia da quesiti su \ac{SO} (87 elementi).

Gli autori dello studio, per poter individuare la causa dei bug e i loro sintomi hanno dovuto analizzare manualmente gli elementi del dataset. Nel caso di bug discussi su \ac{SO} le informazioni sono state recuperate dalla discussione. Mentre nel caso dei bug recuperati da GitHub le informazioni sono state recuperate tramite lo studio dell'intervento di fix e il messaggio associato ad esso.

In questo modo è stato possibile individuare tre sintomi:

• Error: durante l'esecuzione viene sollevato un errore riconducibile a TensorFlow.
• Low Effectiveness: il programma presenta dei valori di accuracy, loss ecc. estremamente scadenti.
• Low Efficiency: il programma viene eseguito troppo lentamente.

Per quanto riguarda le cause è stato possibile individuarne sei:

• Incorrect Model Parameter or Structure: il bug è riconducibile ad un cattivo utilizzo dei parametri del modello o alla sua struttura.
• Unaligned Tensor: si verifica ogni qual volta la shape dell'input non corrisponde con quella attesa.
• Confusion with TensorFlow Computation Model: in questo caso i bug si verificano quando gli utenti non sono pratici del modello computazionale utilizzato da TensorFlow.
• TensorFlow \ac{API} Change: il bug dipende da un cambiamento nell'\ac{API} di TensorFlow.
• TensorFlow \ac{API} Misuse: in questo caso il bug è riconducibile ad un utilizzo scorretto dell'\ac{API} di TensorFlow.
• Structure Inefficiency: questa categoria può essere vista come una versione più soft della prima categoria. Infatti in questo caso il problema nella struttura non genera un errore ma solo delle inefficienze.

Anche lo studio di Humbatova et al. [@humbatova-2019-taxonomyrealfaults] ha come obbiettivo l'analisi delle problematiche legate al \ac{ML}. In questo caso però la visione è più ampia e non si limita ad una singola libreria. Inoltre in questo caso lo scopo ultimo del lavoro è la costruzione di una tassonomia per le problematiche di \ac{ML}.

Anche in questo caso i dati sono stati recuperati sia da \ac{SO} che da GitHub. Inoltre per questo studio è stata anche svolta un'intervista a 20 persone tra ricercatori e sviluppatori nel campo del \ac{ML}. Partendo da questi dati è stata costruita una tassonomia attraverso un approccio bottom-up. La tassonomia si compone di 5 categorie top-level, 3 delle quali sono state divise in sotto categorie.

Tra le categorie di primo livello ci sono:

• Model: in questa categoria rientrano tutte le problematiche che riguardano la struttura e le proprietà del modello.
• Tensors & Inputs: rientrano in questa categoria tutti i problemi rispetto alla shape dei dati e al loro formato.
• Training: questa categoria è la più ampia della tassonomia. Rientrano in questa categoria la qualità e il preprocessing dei dati utilizzati per l'apprendimento, il tuning degli hyperparametri, la scelta della funzione di perdita più appropriata ecc.
• GPU Usage: in questa categoria ricadono tutti i problemi nell'uso della \ac{GPU}.
• API: rientrano in questa categoria tutti i problemi generati da un non corretto utilizzo dell'\ac{API} del framework di \ac{ML}.

Come si può notare, fatta salva la specificità del primo lavoro, esiste una forte similitudine tra le categorie di problemi individuate dai due studi.

\section[Studio di discussioni Stack Overflow riguardanti il ML]{Studio di discussioni Stack Overflow riguardanti il machine learning}

Nello studio di Bangash et al. [@bangash2019whatdevelopersknow] viene svolta un'analisi degli argomenti di \ac{ML} discussi più frequentemente dagli sviluppatori. In questo caso, a differenza dello studio di Han et al. [@han2020whatprogrammersdiscuss] discusso precedentemente, non viene svolta alcuna distinzione in base alla libreria utilizzata. Inoltre questo studio utilizza unicamente informazioni recuperate da \ac{SO}, mentre l'altro lavoro univa le domande di \ac{SO} alla discussione generata all'interno dei repository di GitHub.

In questo caso il topic più frequentemente discusso riguarda la presenza di errori all'interno del codice. Seguono discussioni rispetto agli algoritmi di apprendimento e al training dei dati. Lo studio ha evidenziato anche come molte discussioni riguardano librerie e framework di \ac{ML} come ad esempio numpy, pandas, keras, Scikit-Learn, ecc. Tutte queste discussioni sono state inserite nel topic framework.

Anche nel lavoro di Alshangiti et al. [@alshangiti2019whydevelopingmachine] vengono analizzate le domande presenti sulla piattaforma \ac{SO}. In questo caso però oltre ad un analisi qualitativa rispetto al contenuto di queste discussioni è stata eseguita anche un'analisi comparativa tra le discussioni inerenti al \ac{ML} e le altre.

Per svolgere questa analisi gli autori sono partiti dal dump del database di \ac{SO} e hanno individuato tre campioni:

• Quantitative Study Sample: si compone di 86983 domande inerenti al \ac{ML}, con le relative risposte. L'individuazione dei post è avvenuta attraverso la definizione di una lista contente 50 tag utilizzate su \ac{SO} per le domande di \ac{ML}.
• Qualitative Study Sample: contiene 684 post realizzati da 50 utenti. Questo campione è stato ottenuto eseguendo un ulteriore campionamento sul campione discusso al punto precedente.
• Baseline Sample: si compone di post che non riguardano il \ac{ML}. Questo campione viene utilizzato per comparare le domande di \ac{ML} con quelle generiche.

La prima \ac{RQ} dello studio vuole verificare se rispondere ad una domanda inerente al \ac{ML} sia più complicato. Per valutare la complessità di risposta sono state contate le domande che non presentano alcuna risposta, le domande che non presentano risposte accettate e la mediana del tempo necessario affinché una domanda abbia una risposta accettata. Dal confronto tra il primo e il terzo sample rispetto a queste metriche è emerso che i post inerenti al \ac{ML} hanno una maggiore probabilità di non avere risposte/risposte accettate. Inoltre si è visto come mediamente le domande di \ac{ML} necessitano di un tempo dieci volte maggiore per poter avere una risposta accettata. Una spiegazione a questo fenomeno ci viene fornita dalla seconda \ac{RQ} in cui viene evidenziato che all'interno della community di \ac{SO} c'è una carenza di esperti di \ac{ML} ¹.

Lo studio è stato in grado anche di individuare le fasi in cui gli sviluppatori riscontrano maggiori problematiche. In generale le maggiori difficoltà sono state riscontrate nel preprocessing dei dati, nella configurazione dell'ambiente di sviluppo e nel deployment del modello. Per quanto riguarda i task specifici del \ac{DL} le maggiori problematiche riguardano applicazioni di \ac{NLP} e riconoscimento degli oggetti. Infine lo studio ha mostrato come, nonostante la vasta adozione, molti utenti riscontrano problemi nell'utilizzo dell'\ac{API} di TensorFlow.

Entropia di un cambiamento

Nello studio di Hassan [@hassan2009predictingfaultsusing] si vuole investigare in che modo la complessità del processo del cambiamento del software vada ad impattare sull'introduzione di difetti all'interno della codebase. Per valutare la complessità del processo di cambiamento è stato preso in prestito il concetto di entropia [@shannon1948mathematicaltheorycommunication] utilizzato nella teoria della comunicazione.

Lo studio è stato condotto su sei progetti open source di grandi dimensioni. Attraverso i sistemi di version control e all'analisi lessicale dei messaggi di cambiamento sono stati individuate tre tipologie di cambiamento.

• Fault Repairing modification: include i cambiamenti attuati per risolvere un difetto nel prodotto software. Questa categoria di modifiche non è stata utilizzata per il calcolo dell'entropia, ma per validare lo studio.
• General Maintenance modification: include cambiamenti di mantenimento che non vanno ad influenzare il comportamento del codice. Rientrano in questa categoria la re-indentazione del codice, cambiamenti alla nota del copyright ecc. Questi cambiamenti sono stati esclusi dallo studio.
• Feature Introduction modification: include tutti i cambiamenti che vanno ad alterare il comportamento del codice. Questi cambiamenti sono stati individuati per esclusione e sono stati utilizzati per il calcolo dell'entropia.

All'interno dello studio vengono definiti tre modelli che permettono di calcolare la complessità del processo di cambiamento software.

• Basic Code Change model: è il primo modello presentato, assume un periodo costante per il calcolo dell'entropia e considera costante il numero di file presenti all'interno del progetto.
• Extend Code Change model: è un'evoluzione del modello di base che lo rende più flessibile.
• File Code Change model: i modelli illustrati precedentemente forniscono un valore complessivo di entropia per l'intero progetto. Questo modello permette di valutare l'entropia in modo distinto per ogni file.

Lo studio ha dimostrato che nel caso di sistemi di grandi dimensioni, la complessità del processo di cambiamento è in grado di predire l'occorrenza di fault. Inoltre viene anche mostrato come la predizione basata sulla complessità del processo sia più precisa rispetto alla predizione basata sulla complessità del codice.

---

1. L'individuazione degli esperti è avvenuta secondo l'approccio ExpertiseRank. Questo approccio crea un grafo diretto, in cui gli utenti sono rappresentati dai nodi e gli archi rappresentano una relazione di aiuto, attraverso il quale è possibile determinare l'esperienza degli utenti. Per esempio considerando un caso in cui l'utente B ha aiutato l'utente A avremo che l'esperienza di B è superiore a quella di A. Se l'utente C risponde ad una domanda di B, allora questo avrà una esperienza superiore sia ad A che a B, in quanto è stato in grado di aiutare un utente (B) che aveva dimostrato a sua volta di essere esperto (rispondendo ad A). ↩︎