norangebit
/
master-thesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Add extreme cases analysis

This commit is contained in:
Raffaele Mignone 2021-06-15 12:55:18 +02:00
parent a1671640be
commit ff81331f6b
Signed by: norangebit
GPG Key ID: F5255658CB220573
1 changed files with 44 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
src/chapter_4.md
View File

@ -14,12 +14,28 @@ Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $2
![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=70%}
In relazione all'analisi *strict* sono stati poi analizzati i cinque progetti più \acl{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 delle 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}
## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
Andando a confrontare la distribuzioni della 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.
\newpage
![Istanze dei fix in base alla fase](figures/count-fix-phases.pdf){#fig:count-fix-phases width=70%}
## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
@ -43,7 +59,7 @@ Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-e
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.
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 |
|--------------|:----------------:|:-------------:|
@ -52,8 +68,6 @@ In entrambi i casi, però, l'*effect size* è trascurabile.
: Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
\newpage
## RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
Osservando invece il boxplot[^boxplot-discussion] in @fig:discussion-comments si evince una differenza molto più marcata tra le due distribuzioni.
@ -76,7 +90,7 @@ Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e c
\label{fig:discussion}
\end{figure}
I risultati di dell'analisi rispetto alle parole medie contenute in un commento sono riportati in @fig:discussion-words.
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 \acl{ML} c'è maggiore discussione, ma la discussione è anche più *densa*.
@ -91,6 +105,21 @@ Inoltre, per entrambe le metriche, abbiamo un *effect size* medio.
: 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.
Nel sono un esempio la issue tratta precedentemente nel caso dei commenti, ma anche la issue 125 sempre del progetto *BrikerMan/Kashgari*.
Altre 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*).
## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
Anche in questo caso, osservando la @fig:day-to-fix, è possibile notare una netta differenza tra i *fix* di \ac{ML} e gli altri.
@ -102,13 +131,23 @@ Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto
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 \acl{ML} per essere considerato outlier un *issue*, necessaria di un *time-to-fix* superiore ai trentacinque giorni.
Mentre nel caso dei *fix* di \acl{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 delle 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 *issues* 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 |
|------------|:----------------:|:-------------:|