14 KiB
Risultati
RQ1: come il ML e' distribuito sull'architettura dei progetti?
Dalla @fig:files-directories si può notare che i cambiamenti generici vanno ad impattare su una superficie maggiore del sistema, sia che l'analisi sia svolta al livello di files che di directories. Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \ac{ML} è caratterizzato da una maggiore varianza.
Nel boxplot in @fig:imports sono invece riportati i risultati per quanto riguarda l'utilizzo di import di \ac{ML}.
Si può notare che, indipendentemente dal livello di analisi, la percentuale di file che utilizzano librerie di \ac{ML} è caratterizzata da una forte varianza.
Ciò indica che i progetti inclusi all'interno dello studio sono di varia natura e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
Inoltre, considerando l'analisi strict, è possibile osservare come solo un 25\% dei progetti abbia una percentuale di files di \ac{ML} superiore al 45\%.
In relazione all'analisi wo_pandas_numpy_scipy sono stati poi analizzati i cinque progetti più \ac{ML} intensive per valutare eventuali caratteristiche comuni rispetto al dominio applicativo. Com'è possibile notare dalla @tbl:ml-intensive i vari progetti si occupano di problematiche diverse, ma in quasi tutti i casi è prevista l'estrapolazione di informazioni da immagini. L'unica eccezione è data dal progetto jdb78/pytorch-forecasting che si occupa del forecasting di serie temporali.
| Progetto | Dominio Applicativo |
|---|---|
| davidsandberg/facenet | Riconoscimento facciale |
| jdb78/pytorch-forecasting | Time series forecasting |
| tianzhi0549/FCOS | Riconoscimento di oggetti |
| emedvedev/attention-ocr | Riconoscimento del testo |
| Tianxiaomo/pytorch-YOLOv4 | Riconoscimento di oggetti |
: Dominio applicativo dei progetti con maggior uso di librerie di \ac{ML} {#tbl:ml-intensive}
\begin{tcolorbox}[colback=white, boxrule=0.3mm] Sia nel caso in cui l'analisi sia svolta sui file modificati, sia nel caso in cui sia svolta sugli import, il dato riguardante il \ac{ML} è caratterizzato da una forte varianza. Questo vuol dire che la diversa natura dei progetti considerati nello studio genera delle caratteristiche diverse per quanto riguarda l'architettura. \end{tcolorbox}
\newpage
RQ2: come sono distribuiti i bug sulle diverse fasi di ML?
Andando a confrontare la distribuzione delle fasi sui commit (@fig:count-fix-phases) rispetto alla distribuzione sulle issues (@fig:labeling-phases) è possibile notare la scomparsa della fase data collection.
Inoltre è evidente anche la riduzione delle occorrenze di model training e una crescita d'importanza per quanto riguarda le fasi di model requirements e model deployment. Sfortunatamente i dati disponibili per questa analisi sono molto limitati (è stato possibile ricavare la fase solo per quaranta fix), per cui non è stato possibile effettuare delle analisi più approfondite.
RQ3: esiste una differenza di entropy tra ML bug e altri bug?
Dal boxplot1 in @fig:files-entropy è possibile notare una distribuzione equivalente per le due tipologie di fix. Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-entropy) anche se in questo caso è possibile notare che i valori di entropia associati ai fix di \ac{ML} sono shiftati leggermente verso l'alto.
\begin{figure}[!ht] \subfloat[Entropia calcolata sui files\label{fig:files-entropy}]{% \includegraphics[width=0.45\textwidth]{src/figures/files-entropy.pdf} } \hfill \subfloat[Entropia calcolata sulle linee\label{fig:lines-entropy}]{% \includegraphics[width=0.45\textwidth]{src/figures/lines-entropy.pdf} } \caption{Entropia in base al tipo di fix} \label{fig:entropy} \end{figure}
Per verificare la rilevanza statistica di questa diversità sono stati svolti il ranksum test e il Cliff's delta i cui risultati sono riportati nella @tbl:test-entropy.
Nel caso dell'entropia sui file possiamo dire che la differenza è marginale poiché il p-value è prossimo a 0.05, mentre nel caso dell'entropia calcolato sulle linee la differenza viene confermata dal test.
In entrambi i casi, però, l'effect size è trascurabile segno che la complessità dell'intervento non varia in base al tipo di intervento.
| ranksum p-values | Cliff's delta | |
|---|---|---|
| file entropy | 0.059 | 0.044 |
| line entropy | 5.932e-06 | 0.105 |
: Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
\begin{tcolorbox}[colback=white, boxrule=0.3mm] Non sono emerse differenze statisticamente rilevanti per quanto riguarda la complessità del processo di cambiamento. \end{tcolorbox}
RQ4: come varia il livello di discussione tra ML bug e altri bug?
Osservando invece il boxplot2 in @fig:discussion-comments si evince una differenza molto più marcata tra le due distribuzioni.
In particolare è possibile notare che le issue fix di \ac{ML} presentano una maggiore discussione e anche una maggiore varianza.
Se consideriamo la differenza interquartile, in modo da escludere completamente eventuali outlier, possiamo osservare che nei fix generici questa varia tra zero e uno.
Ciò vuol dire che il 50\% interno delle issues o non presenta commenti o ne presenta uno solo.
Mentre la differenza interquartile dei fix di \ac{ML} è compreso tra uno e cinque, quindi nel 50\% interno tutte le issues hanno almeno un commento di risposta.
\newpage
\begin{figure}[!ht] \subfloat[Numero di commenti medi\label{fig:discussion-comments}]{% \includegraphics[width=0.45\textwidth]{src/figures/comments.pdf} } \hfill \subfloat[Numero di parole medie per commento\label{fig:discussion-words}]{% \includegraphics[width=0.45\textwidth]{src/figures/words.pdf} } \caption{Livello di discussione in base al tipo} \label{fig:discussion} \end{figure}
I risultati dell'analisi rispetto alle parole medie contenute in un commento sono riportati in @fig:discussion-words. Anche in questo caso si può vedere che nel caso di \ac{ML} fix la distribuzione presenta valori più elevati e maggiore varianza. Per cui non solo nei fix di \ac{ML} c'è maggiore discussione, ma la discussione è anche più densa.
Anche in questo caso sono stati svolti i test statistici.
In @tbl:test-discussion è possibile vedere come per entrambe le metriche considerate il p-value sia abbondantemente inferiore alla soglia di 0.05 quindi abbiamo una conferma della diversità delle due distribuzioni riscontrata dal boxplot.
Inoltre, per entrambe le metriche, abbiamo un effect size medio.
| ranksum p-values | Cliff's delta | |
|---|---|---|
| commenti medi | 9.053e-75 | 0.425 |
| parole per commento | 2.889e-59 | 0.377 |
: Risultati dei test statistici per quanto riguarda il livello di discussione {#tbl:test-discussion}
Infine, per entrambe le metriche, sono stati analizzati alcuni casi estremi. Nel caso della issue numero 96 del progetto BrikerMan/Kashgari la problematica riguarda un drastico calo di performance quando il fit viene eseguito con un metodo piuttosto che con un altro. All'interno dei commenti, diversi contributors del progetto, si scambiano possibili architetture, snippet di codice e metriche per confrontare i diversi modelli generati. In questo caso l'ampiezza della discussione è sicuramente dovuta alla difficoltà di individuare la problematica.
La issue numero 27 del progetto pyswarms/issues è una richiesta di aiuto da parte dell'autore per migliorare l'implementazione della ricerca per il tuning degli hyperparametri. In questo caso la discussione si protrae per oltre trenta commenti ed è incentrata sui requisiti dell'implementazione e come implementarla nel rispetto delle linee guida del progetto. Quest'intervento di modifica è stato il primo contributo dell'utente non solo su questo progetto, ma sull'intera community di GitHub. Questa inesperienza può aver contribuito ad ampliare la discussione.
La stessa analisi è stata svolta anche per le issues che presentano un alto numero di parole medie per commento. In questo caso un valore molto elevato della metrica è spesso riconducibile alla condivisione di blocchi di codice. Ne sono un esempio la issue tratta precedentemente nel caso dei commenti, ma anche la issue 125 sempre del progetto BrikerMan/Kashgari. Altri fattori che contribuiscono a spiegare questo dato sono la presenza di blocchi di errori (mittagessen/kraken/206) o messaggi di log utili ad inquadrare l'origine del problema (robertmartin8/PyPortfolioOpt/177).
\begin{tcolorbox}[colback=white, boxrule=0.3mm] Le \emph{issues} di \ac{ML} sono caratterizzata da una maggiore discussione. Un valore molto elevato di parole per commento può indicare uno scambio massiccio all'interno della discussione di \emph{snippet} di codice, di log d'errore e configurazioni dell'ambiente. \end{tcolorbox}
RQ5: come varia il time-to-fix tra ML bug e altri bug?
Anche in questo caso, osservando la @fig:day-to-fix, è possibile notare una netta differenza tra i fix di \ac{ML} e gli altri.
In particolare i bug di \ac{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore.
Inoltre è possibile vedere come la mediana non sia centrata, bensì spostata verso il basso.
Questo vuol dire che il 50\% basso dei bug di \ac{ML} viene comunque risolto in tempi brevi (due giorni circa), mentre l'altro 50\% può richiedere una quantità di tempo decisamente superiore.
Un'ulteriore testimonianza del maggior tempo necessario per risolvere le problematiche legate al \ac{ML} ci viene data dagli outlier. Nel caso di un problema generico, questo, viene considerato come anomalo se per essere risolto necessita di un tempo superiore ai cinque giorni. Mentre nel caso dei fix di \ac{ML} per essere considerato outlier una issue, necessaria di un time-to-fix superiore ai trentacinque giorni.
Il maggior tempo necessario ad attuare la correzione indica che i bug di \ac{ML} sono più difficili da individuare e correggere rispetto a quelli generici. Inoltre questo risultato contribuisce a spiegare il dato emerso dalla sezione precedente, in quanto per individuare la fonte del problema sembrerebbe essere necessaria una discussione più approfondita.
Per quanto riguarda i fix che hanno richiesto un tempo estremamente lungo la causa può dipendere anche da ulteriori fattori. Nel caso del progetto CamDavidsonPilon/lifelines la issue numero 507 segnala una problematica di overflow durante le operazioni sul dataset. Per stessa ammissione dell'autore del progetto la problematica è banale da risolvere, ma è stato comunque necessario attendere un paio di mesi affinché la correzione venisse portata sul branch principale.
Altre issues invece hanno necessitato di molto tempo per essere risolte in quanto venivano considerate a bassa priorità. In questi casi generalmente viene fornito un work around che permette di tamponare la problematica. La presenza di questo work around probabilmente riduce ulteriormente la priorità data alla issue il che dilata ulteriormente i tempi. Un esempio di questo comportamento ci viene dato dalla issue 135 del progetto robertmartin8/PyPortfolioOpt che ha richiesto circa sette mesi per essere risolta o dalla issue 98 del progetto mittagessen/kraken che invece ha necessitato di quasi due anni.
Anche per quest'ultima RQ sono stati svolti i test statistici illustrati precedentemente.
Dai risultati riportati in @tbl:test-time-to-fix è possibile notare un p-value inferiore a 0.05 e un effect size medio.
Questi risultati non solo confermano la differenza osservata nel boxplot, ma ci confermano che l'impatto sulla metrica non è trascurabile.
| ranksum p-values | Cliff's delta | |
|---|---|---|
| day-to-fix | 7.354e-53 | 0.355 |
: Risultati dei test statistici per quanto riguarda il time-to-fix {#tbl:test-time-to-fix}
\begin{tcolorbox}[colback=white, boxrule=0.3mm] Le problematiche di \ac{ML} richiedono più tempo per essere risolte. La bassa priorità di una \emph{issue} e la presenza di \emph{work around} sono fattori che contribuiscono a ritardare l'intervento di \emph{fix}. \end{tcolorbox}
Threats to validity
La threats to validity più critica per il lavoro svolto è di tipo construct e riguarda la classificazione delle issues. La classificazione è avvenuta in modo automatico attraverso un modello naïve Bayes. Il classificatore, sebbene sia caratterizzato da una recall molto elevata, presenta una precision discreta per cui è molto probabile che all'interno tra le issues di \ac{ML} siano state incluse anche issues generiche. Inoltre, poiché la classificazione degli interventi di issue fixing dipende dalla classificazione degli issues, gli eventi di misclassification sono stati propagati anche su questa seconda classificazione.
Per quanto riguarda le threat to validity interne bisogna segnalare l'interpretazione data al time-to-fix. Infatti in questo lavoro il dato del time-to-fix è stato calcolato come la differenza tra l'istante di chiusura e di apertura della issue. Questa approssimazione è sicuramente semplicistica in quanto comprende altri sotto intervalli come time-to-response, time-to-assign, ecc. Mentre per quanto riguarda le threat to validity esterne va sicuramente segnalato che i risultati di questo lavoro si generalizzano unicamente per i trenta progetti inclusi nel dataset.