200 lines
13 KiB
Markdown
200 lines
13 KiB
Markdown
type:: [[meeting]]
|
||
external-links::
|
||
tags:: [[PROJECTS/PRIN-EMELIOT]]
|
||
people::
|
||
date:: [[07/02/2024]]
|
||
duration::
|
||
isconsortium:: true
|
||
location:: Franciacorta
|
||
|
||
- Luciano invierà presto qualche dettaglio in più per fare la prenotazione della stanza. Rimane il piano già concordato:
|
||
- Arrivo a Milano attorno all’ora di pranzo/primo pomeriggio del 6 Febbraio. Nel pomeriggio raggiungiamo in auto la Franciacorta. La cena è prevista nella stessa struttura che ci ospita. La sera se ne abbiamo voglia potremmo fare due chiacchiere informali su progetti (PRIN per il futuro?) e lavori futuri mentre ci beviamo qualcosa… oppure semplicemente ci beviamo qualcosa in allegria parlando di altro ;-)
|
||
- Si lavora il 7 Febbraio fino ad una ora X del pomeriggio da determinare sulla base di un evento sociale a cui sta lavorando Luciano (l’idea è di far visita ad una cantina della zona)
|
||
- l’8 Febbraio mattina facciamo colazione e torniamo a Milano. Poi "non-Milanesi” a questo punto rientrano in sede
|
||
- Riguardo alla giornata lavorativa, di sicuro prevederei una sessione per discutere degli avanzamenti sull’organizzazione dell’esperimento con human subject di cui abbiamo discusso alle ultime riunioni.
|
||
- Inoltre prevederei come al solito delle presentazioni di aggiornamento, che poi funzionano anche come driver per la discussione. **A questo proposito chiederei ad ogni unità di inviare la lista delle presentazioni che vorrebbe fare / eventuali argomenti che vorrebbe vedere trattati alla riunione. Vi chiedo di inviare questa informazione entro il 22 dicembre, **così come compito per le vacanze definisco l’agenda della riunione.
|
||
-
|
||
- ## Agenda
|
||
- *8:30 - 9:45 Resource allocation and sustainabilty*
|
||
- Resource allocation at the edge (Polimi) ((65c33322-8ccc-4fc7-92a5-96d34d4036e0))
|
||
- Spark and resource management for ML (Polimi) ((65c153f6-97f3-4657-86e3-7ec7e990ec91))
|
||
- The Making of Sustainable ML-Enabled Systems: State of the Practice and Trade-Offs to Consider (UniSA) ((65c340fc-99fc-4b15-822b-0433fb54695e))
|
||
- 9:45-10:15 Coffee break
|
||
- *10:15 - 11:30 Quality of DL program and models*
|
||
- Technical Dept of DL Systems (UniSannio) ((65c3448b-ffae-4229-b3e8-accf3031a4f6))
|
||
- Model transparency and documentation (UniSannio) ((65c34076-c42e-4772-b6ff-fc5b5733a482))
|
||
- Towards the identification of datasets bias symptoms (UniVaq) ((65c35633-d1fd-4840-a6bc-ee79a2db5ffa))
|
||
- 11:30-12:15 Light lunch
|
||
- 12:30-14:00 Visita Berlucchi
|
||
- *14:30 - 15:45 Software Quality*
|
||
- ((65c3581b-b9cf-4127-936e-bc5ad5ee2805))
|
||
- ((65c39bdd-1dfc-4590-ac0e-22248b4b4314))
|
||
- Failure injection and propagation in IoT systems (UniVaq)
|
||
- 15:45 - 16:15 Coffee break
|
||
- *16:15 - 17:05 LLMs*
|
||
- ((65c398ad-f5cf-493b-b027-44535a5ce698))
|
||
- ((65c3ad5f-582a-4a6f-a14d-5a539d2888a2))
|
||
- 17:05 - 18:00 Working session (intro UniSannio)
|
||
- ## Presentazioni
|
||
- ### Self-healing neural networks (Giovanni Quattrocchi)
|
||
id:: 65c33322-8ccc-4fc7-92a5-96d34d4036e0
|
||
-
|
||
- NN per computer vision
|
||
- Input immagini
|
||
- Problema principale e' l'overfitting
|
||
- NN che "impara troppo" dai dati in input
|
||
- Se aggiungo all'immagine iniziale un errore, quello che apparentemente e' un errore non visibile all'occhio umano, la predizione e' sbagliata
|
||
- DONE Out of distributionz (ODD) data (da vedere )
|
||
id:: 65c8d45b-9775-4e19-88ed-c5d1895df182
|
||
- L'obiettivo e' avere la capacità di adattarsi a diversi domini applicativi
|
||
- Domain shift
|
||
- DeepNurse
|
||
- Presentato una sorta di feedback loop
|
||
- A runtime vorremmo capire che stiamo ricevendo immagini in input da un dominio diverso da quello dei dati di training
|
||
- MOnitoriamo le classiche metriche (accuratezza, precision, etc.)
|
||
- Si usa in aggiunta una metrica aggiuntiva (incertezza) come proxy per monitorare la performance della NN
|
||
- Piu' alta e' lincertezza piu' bassa e' la confidenza della predizione della NN
|
||
- Vengono mostrate 3 tecniche per misurare questa incertezza
|
||
- L'incertezza viene utilizzata per stimare l'identificazione di "domain shifts" (Detection di un domain shift)
|
||
- si calcola l'incertezza sui dati in input e viene confrontata all'incertezza sui dati del nuovo dominio
|
||
- Si applica un test statistico (Kolmogorov-Smirnov) per capire se si tratta di undomain shift
|
||
- Quando capiamo che c'e' uno sfift di domain
|
||
- si applica la tecnica Neural Style Transfer (da vedere)
|
||
id:: 65c8d45b-545c-4ca4-acc3-b35ef663757f
|
||
- Trasformazione solo stilistica, non di contenuto
|
||
- Domanda: cos'è a questo punto un cambio di dominio?
|
||
- Esempio ho fatto training usando immagini da guida autonoma fatta di giorno, un cambio di dominion puo' essere quella di guida fatta di notte
|
||
- Weight Reconfiguration
|
||
- Fine tuning della rete neurale
|
||
- Evitare il catasfrophic forgetting
|
||
- Evitare di perdere quello che ho imparato dal training iniziale
|
||
- Per l'evaluation, attulmente si sta lavorando su 2 datasets (bird classification e stelf-driving (questo e' un task di regressione quindi predizione ) ) e 5 reti neurali
|
||
- DA CAPIRE SE TUTTO QUESTO PUO' ESSERE APPLICATO ALL'INGEGNERIA DEL SOFTWARE PER ESEMPIO RELATIVO A SUPPORTARE TASK DI SVILUPPO CON STILI DI PROGRAMMAZIONE DIVERSA [[Ideas]]
|
||
-
|
||
- ### Spark and resource management for ML (Marco Garlini - assegnista polimi)
|
||
id:: 65c153f6-97f3-4657-86e3-7ec7e990ec91
|
||
- Allocazione dinamica di risorse per ML (Apache Spark e batch processing)
|
||
- L'architettura di Apache Spark e' una timipa master / worker. Un master node che interagisce e orchestra l'esecuzione di azioni di processamento eseguite da Worker Node
|
||
- L'ordine di esecuzione e il parallelismo di esecuzione degli job e' gestito dal un *DAG scheduler*
|
||
- Presentato dynaSpark (paper di Luciano, Giovanni etc.)
|
||
- Spark fornisce una libreria ML chiamata MLlib
|
||
- Una inefficienza e' la caratteristica di essere single progress e multi-thread
|
||
- Questo causa alcuni problemi con Python
|
||
- PyTorch fornisce dei paradigmi piu' recenti ed efficienti
|
||
- Multi-process e multi-thread, esempio permette di avere esecuzioni frammenti di modelli su piu' GPU
|
||
- Spark introduce nell'aprile 2023 TorchDistributor che permette di usare PyTorch in maniera nativa
|
||
- quindi la distribuzione non viene gestita da PyTorch, ma da TorchDistributor
|
||
-
|
||
- Quindi il goal e' quello di aggiornare dynaSpark per fornire supporto per pyTorch mediante TorchDistributor
|
||
-
|
||
- ### The making of sustainable ML-enabled systems (Fabio)
|
||
id:: 65c340fc-99fc-4b15-822b-0433fb54695e
|
||
- Hanno un TOSEM in major revision per capire quali sono gli aspetti non funzionali di sistemi ML-based
|
||
- Hanno identificato 30 requisiti non funzionali che sono clusterizzati in 6 gruppi tra cui c'e' sustainability che consiste fairness, bias ethics, accountability, cost, energy consumption
|
||
- DONE C'e' un articolo ICSE 2023 "Sustainability is stratified: .." che presenta 4 dimensioni caratterizzanti la sostenibilità per SE
|
||
id:: 65c8d45b-1a21-40d2-9003-5b9c13d08e01
|
||
- Hanno un TSE under review che studia gli aspetti di sostenibilità di sistemi ML-based
|
||
- SOno stati coinvolti diversi ML engineers and piu' di 300 sviluppatori
|
||
- La tecnica piu' usata per gestire la questione di sostenibilità e' quella di ottimizzare l'uso di CPU/GPU
|
||
- ### Technical Dept of DL Systems (Federica Pepe)
|
||
id:: 65c3448b-ffae-4229-b3e8-accf3031a4f6
|
||
- DONE Articolo EMSE 2022 di Massimiliano su self-admitted technical dept
|
||
- QUali sono gli SATD in ambito di progetti ML?
|
||
- La tassonomia consiste dei seguenti tipi di ML TechDept
|
||
- Hardware (support)
|
||
- API (problemi di integrazioni con i framework piu' comuni di ML es. tensorflow)
|
||
- Data
|
||
- Model (Setting and design of the model)
|
||
- parameter come dimensione dei batch
|
||
- compatibilità dei vari modelli
|
||
- Inference
|
||
- Modo in cui il modello fa inferenza su nuovi dati
|
||
- Pipeline
|
||
- Training e predizione di nuovi dati
|
||
- Ottimizzazione per accellerare il processo o migliorare le performance del modello
|
||
- DONE Tassonomia di Real Faults in Deep Learning SYstems (paper di Tonella ICSE 2020)
|
||
id:: 65c8d45b-3974-4a0e-ac6e-7dbc798340ab
|
||
:LOGBOOK:
|
||
CLOCK: [2025-05-26 Mon 22:21:42]--[2025-05-26 Mon 22:21:43] => 00:00:01
|
||
:END:
|
||
- Il match della tassonomia di Max e quella di Tonella consiste di un'intersezione di 3 elementi (che non ricordo)
|
||
-
|
||
- ### How HF models document dataset, bias and licences (Federica Pepe)
|
||
id:: 65c34076-c42e-4772-b6ff-fc5b5733a482
|
||
- Research questions (Lo studio e' stato fatto focalizzandosi sulla libreria transformers) - sono stati considerati circa 159000 modelli HF
|
||
- RQ1: to what extent do models declare the datasets used for the training?
|
||
- 14% specifica il dataset usato (distinguendo dataset hosted by HF o link esterni)
|
||
- la maggior parte usando dataset hosted by HF
|
||
- RQ2: how PTMs discuss fairness/bias limitations
|
||
- IL modello dichiara bias? se si, che tipologia?
|
||
- 18% dichiara bias
|
||
- Le categorie di bias considerate
|
||
- HIstorical Bias
|
||
- Popularity Bias
|
||
- Population bias
|
||
- Content production bias
|
||
- Social bias
|
||
- RQ3: to what extent PTMs declare the used licenses
|
||
- ricerca del tag license nelle model card di HF
|
||
- Ci sono tre tipologie di license
|
||
- Restrictive
|
||
- ML-Specific
|
||
- Rail
|
||
- Forbid harmful and unethical usages
|
||
- E' stato studiata una contingency matrix mettendo in relazione licensa modello usato vs licensa project
|
||
- E' stato visto che su circa 100000 progetti, ni hanno 700 violazioni di license
|
||
- E' possibile trovare una correlazione tra completezza delle model card e la maturità del modello? [[Ideas]]
|
||
-
|
||
- ### Towards the identification of datasets bias symptoms (Giordano)
|
||
id:: 65c35633-d1fd-4840-a6bc-ee79a2db5ffa
|
||
- I 200 secondi menzionati nella slide 3 non mi sembrano impressive!!! Per il paper va trovato un esempio piu' forte!
|
||
- Considerando la domanda di Luciano, bisogna chiarire che noi forniamo un meccanismo che permette di individuare potenziali rischi di bias, indipendentemente dal dominio applicativo o dall'uso che si fa' del bias
|
||
- Bisogna analizzare le possibili correlazioni esistenti tra i 17 sintomi che sono stati identificati
|
||
- Guardare il paper di Mark Harman in merito a questo
|
||
- Un suggerimento di Leonardo e' fare un'analisi con azioni correttive del bias [[Ideas]]
|
||
- ### On the Relation between Community Smells and Socio-Technical Antipatterns in ML-Enabled Systems (UniSA)
|
||
id:: 65c3581b-b9cf-4127-936e-bc5ad5ee2805
|
||
- Aspetti socio-tecnici che possono impattare sulla qualità del software (socio-technical anti-patterns) di sistemi ML-based
|
||
- SI fa riferimento al concetto di organizational silos
|
||
- Community smells, e.s.
|
||
- Lone WOlf
|
||
- Prima donna
|
||
- Organization Silo
|
||
- Organizational Skirmish
|
||
- Black Cloud
|
||
- Research questions:
|
||
- RQ1 How are socio-technical anti-patterns related with community smells in the context of ML-enabled systems (Structural model evaluation)
|
||
- RQ2: Does the relationship between socio-technical antipatterns and community smells vary by gender, role, and development model? (Structural Model Evaluation - Multi-Group Analysis)
|
||
- E' stato usato PLS-SEM (modello statistico) per trovare relazioni complesse tra diversi concetti
|
||
- Articolo del 2023 "*Advanced issues in partial least squares structural equation modeling*"
|
||
- Mi sembra di capire che e' una sorta di quality model. La parte aggiuntiva e' la definizione delle ipotesi che lega le relazioni tra quality attribute piu' astratto con i corrispondenti quality attribute aggregati
|
||
-
|
||
- ### Chatbot mutation and security testing (UniMiB)
|
||
id:: 65c39bdd-1dfc-4590-ac0e-22248b4b4314
|
||
- Focus su chatbot conversazionali
|
||
- mutation testing non e' stato ancora applicato in chatbot testing
|
||
- Articolo a ICSE Demo su Mutabot (chatbot mutation tool)
|
||
- basato sul metamodello di J. De Lara accettato a SAC 2022 su heterhogeneous chatbot designs
|
||
- Si usa Botium come tool per implementare le test suite
|
||
- Attualmente si sta lavorando sulla "copertura" dei vari operatori sulle varie piattaforme
|
||
- ### Method body generation with LLMs (UniMiB)
|
||
id:: 65c398ad-f5cf-493b-b027-44535a5ce698
|
||
- 2 Articoli a ICPC 2024
|
||
- Confrontato 4 assistenti differenti (copilot, tbnine, chatgpt, bard)
|
||
- correctness
|
||
- complexity
|
||
- efficiency
|
||
- size
|
||
- similarity con il codice sviluppato dagli sviluppatori
|
||
- Prompt generato dai commenti in Javadoc
|
||
- ### Requirements and LLMs (Polimi)
|
||
id:: 65c3ad5f-582a-4a6f-a14d-5a539d2888a2
|
||
- SI e' partiti da un lavoro di Paola Spoletini per generare User Stories a partire di breve descrizioni dell'app da sviluppare (ICSE 2023)
|
||
- Usata struttura multi-agente
|
||
-
|
||
- ### Working session
|
||
- Articolo a MSR2024 di Max sull'uso di ChatGPT da sviluppatori. E' stata creata una tassonomia di tasks che sono stati supportati da ChatGPT
|
||
-
|
||
-
|
||
-
|
||
- |