Auto saved by Logseq
This commit is contained in:
@@ -0,0 +1,200 @@
|
||||
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
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
Reference in New Issue
Block a user