From ff81331f6bf72d7eb3cbd459a476133d121ade1a Mon Sep 17 00:00:00 2001 From: norangebit Date: Tue, 15 Jun 2021 12:55:18 +0200 Subject: [PATCH] Add extreme cases analysis --- src/chapter_4.md | 49 +++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 44 insertions(+), 5 deletions(-) diff --git a/src/chapter_4.md b/src/chapter_4.md index 13b9b68..66656e5 100644 --- a/src/chapter_4.md +++ b/src/chapter_4.md @@ -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 | |------------|:----------------:|:-------------:|