[{"content":" TL;DR Abbiamo raccolto 7.156 pull request reali create da Codex, Claude Code, Cursor, Devin e Copilot, poi tagliato i dati per tipo di task. La sintesi: il divario tra la categoria di task migliore e peggiore è di 29 punti percentuali — molto più grande del divario tra agenti all\u0026rsquo;interno di una singola categoria. Codex è il generalista affidabile. Claude Code vince sulla documentazione. Cursor vince sui bug fix. Smetti di chiedere quale agente è il migliore. Inizia a chiedere migliore in cosa. La domanda sbagliata Entra in un qualunque Slack di engineering e troverai sempre lo stesso dibattito: Codex contro Claude Code contro Cursor contro Devin contro Copilot. I thread esplodono. Volano benchmark. Qualcuno screenshotta una leaderboard.\nLa risposta onesta a \u0026ldquo;qual è il migliore\u0026rdquo; è dipende — ma quella risposta sa di scappatoia. Quindi abbiamo provato a renderla concreta. Abbiamo preso 7.156 pull request che questi cinque agenti avevano davvero aperto contro repo open-source reali, e abbiamo misurato l\u0026rsquo;unica cosa che conta davvero: un maintainer umano l\u0026rsquo;ha mergiata?\nPoi abbiamo fatto la parte che la maggior parte delle valutazioni salta. Abbiamo separato le PR per tipo di lavoro che svolgevano.\nPerché un singolo numero mente Bug fix, sviluppo di feature, documentazione, refactoring, aggiornamento di dipendenze, test — non sono lo stesso task. Hanno profili di difficoltà drasticamente diversi per un agente AI. La documentazione è soprattutto generazione di linguaggio naturale contro un bersaglio morbido. L\u0026rsquo;implementazione di feature richiede di tenere in testa un modello dell\u0026rsquo;architettura. Il bug fixing chiede di navigare il codice di qualcun altro.\nSe fai la media di tutto, ottieni un numero. E perdi l\u0026rsquo;intera storia.\nQuindi, invece di un tasso di accettazione per agente, ne abbiamo calcolato uno per agente, per tipo di task.\nIl risultato principale Guarda il grafico. La cosa che dovrebbe colpirti è verticale, non orizzontale.\nIl divario tra la migliore e la peggiore categoria di task è circa 29 punti percentuali. Il divario tra agenti all\u0026rsquo;interno di una stessa categoria è molto più piccolo. Il tipo di lavoro che dai a un agente predice l\u0026rsquo;accettazione molto più di quale agente hai scelto.\nQuesto riformula tutta la conversazione. Chiedere \u0026ldquo;Cursor è meglio di Claude Code?\u0026rdquo; è come chiedere \u0026ldquo;uno chef è meglio di uno chef di sushi?\u0026rdquo; — alla domanda manca un complemento. Meglio in cosa?\nOgni agente ha la sua specialità Quando tagli i dati per bene, gli agenti smettono di confondersi. Sviluppano personalità.\nCodex — il generalista. Niente picchi spettacolari, niente baratri imbarazzanti. Se devi scegliere un solo agente e non sai cosa ti aspetta, questa è probabilmente la scelta sicura.\nClaude Code — documentazione. La sua fluenza linguistica si traduce direttamente in descrizioni di PR, riscritture di README e commenti inline che i maintainer vogliono davvero mergiare.\nCursor — bug fix. L\u0026rsquo;integrazione con l\u0026rsquo;IDE gli dà un contesto più profondo sul codice circostante, ed è esattamente il contesto di cui ha bisogno il bug fixing.\nDevin e Copilot finiscono altrove su questa mappa — il dettaglio è nel paper. Il punto non è la classifica, è che non c\u0026rsquo;è una singola classifica. C\u0026rsquo;è una forma.\nCosa farne davvero Se metti in produzione codice con agenti AI, due cose ne conseguono:\nIndirizza per task, non per preferenza. Un team che dà ogni tipo di lavoro al proprio agente preferito sta lasciando tasso di accettazione sul tavolo. PR di documentazione? Mandala a Claude Code. Bug sottile? Cursor. Pulizia del martedì qualunque? Codex. Tratta i tuoi agenti come una squadra con specialità diverse, perché è quello che sono.\nCalibra le aspettative. Quando una PR di feature fallisce in review, potrebbe non essere colpa dell\u0026rsquo;agente — potrebbe essere colpa del task. Un tasso di accettazione del 40% sui task difficili non è un agente rotto. Un 70% sui task facili non è uno magico. Entrambi sono rumore intorno a una baseline imposta dal lavoro stesso.\nCosa cambia per il campo Per chi sviluppa agenti: smetti di rincorrere punteggi aggregati nei benchmark. Nascondono dove stai perdendo. La strada per un agente migliore passa dalla categoria di task in cui ora sei sotto.\nPer i ricercatori: riportate sempre i numeri per task. Un singolo tasso di accettazione non è una misurazione, è una funzione di smoothing sopra la variazione più interessante.\nE per tutti gli altri: quando qualcuno ti dice che il suo agente è il migliore, chiedigli in cosa. Se non sa rispondere, non lo sa nemmeno il suo agente.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Sarro, F. (2026). Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance. In: Proceedings of the 23rd International Conference on Mining Software Repositories (MSR 2026) — Mining Challenge Track.\nLeggi il paper originale (PDF)\nRicerca condotta presso la University College London (UCL), CREST, con la Prof.ssa Federica Sarro.\n","permalink":"https://giovannipinna.net/it/posts/msr2026-comparing-ai-agents/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Abbiamo raccolto \u003cstrong\u003e7.156 pull request reali\u003c/strong\u003e create da Codex, Claude Code, Cursor, Devin e Copilot, poi tagliato i dati per \u003cem\u003etipo di task\u003c/em\u003e. La sintesi: il divario tra la categoria di task migliore e peggiore è di \u003cstrong\u003e29 punti percentuali\u003c/strong\u003e — molto più grande del divario tra agenti all\u0026rsquo;interno di una singola categoria. Codex è il generalista affidabile. Claude Code vince sulla documentazione. Cursor vince sui bug fix. Smetti di chiedere \u003cem\u003equale agente è il migliore\u003c/em\u003e. Inizia a chiedere \u003cem\u003emigliore in cosa\u003c/em\u003e.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"la-domanda-sbagliata\"\u003eLa domanda sbagliata\u003c/h2\u003e\n\u003cp\u003eEntra in un qualunque Slack di engineering e troverai sempre lo stesso dibattito: Codex contro Claude Code contro Cursor contro Devin contro Copilot. I thread esplodono. Volano benchmark. Qualcuno screenshotta una leaderboard.\u003c/p\u003e","title":"Non esiste un \"miglior\" agente di codifica AI — ed è esattamente questo il punto"},{"content":" TL;DR Abbiamo analizzato 23.247 pull request scritte da agenti di codifica AI e fatto una domanda semplice: la descrizione corrisponde al diff? Nell\u0026rsquo;1,7% dei casi, no. Sembra poco — finché non vedi le conseguenze. Le PR inconsistenti hanno un tasso di accettazione inferiore del 51,7% e impiegano 3,5× di tempo per essere mergiate. Il codice è a posto. Il problema è la storia che l\u0026rsquo;agente racconta sul codice. La parte di una PR che nessuno misura Quando facciamo benchmark sugli agenti di codifica AI, misuriamo il codice. Compila? Passa i test? È pulito?\nMa una pull request non è un diff. È un diff più una storia. Il reviewer legge il titolo, poi la descrizione, poi forse il codice. La descrizione fissa le aspettative. Dice al reviewer cosa cercare. Se la storia è sbagliata, ogni riga di codice che segue viene letta contro il template sbagliato.\nUna PR intitolata \u0026ldquo;fixed the auth bug\u0026rdquo; che in realtà refactora il livello del database non solo fallisce a informare. Inganna attivamente. E quando i reviewer captano il mismatch — anche solo a livello inconscio — la fiducia crolla.\nPerché gli agenti sono stranamente cattivi in questo Scrivere codice e scrivere un riassunto onesto di quello che hai appena scritto sono task cognitivi diversi. Il primo è algoritmico. Il secondo è meta-cognitivo — devi sapere cosa intendevi fare, cosa hai provato, e cosa è effettivamente uscito dall\u0026rsquo;altra parte.\nGli agenti AI sono bravi nel primo. Faticano nel secondo, e il fallimento ha una forma precisa:\nL\u0026rsquo;agente legge il task e formula un piano. Incontra attriti inattesi — test che falliscono, dipendenze strane, edge case. Itera, debugga, fa deviazioni, scende a compromessi. Il codice finale non è esattamente quello che il piano prevedeva. Quando gli viene chiesto di scrivere una descrizione, l\u0026rsquo;agente spesso descrive il piano, non il risultato. Da lì nasce l\u0026rsquo;inconsistenza messaggio-codice. Non malizia. Non pigrizia. Una deriva tra intento e risultato che l\u0026rsquo;agente non ha mai notato.\nCome l\u0026rsquo;abbiamo misurata Abbiamo costruito una metrica — PR-MCI, Pull Request Message-Code Inconsistency — che misura la distanza semantica tra quello che dice la descrizione e quello che il diff effettivamente fa. È un punteggio continuo, non sì/no, così possiamo classificare le PR per quanto sono inconsistenti.\nPoi l\u0026rsquo;abbiamo applicata a 23.247 pull request scritte da agenti AI e abbiamo guardato cosa succedeva a quelle inconsistenti.\nIl problema dell'1,7% Solo l\u0026rsquo;1,7% delle PR ha ottenuto un punteggio di alta inconsistenza. Sembra un non-problema. Non lo è, per due motivi.\nPrimo, la scala. In un\u0026rsquo;azienda che spedisce migliaia di PR generate da agenti al mese, l'1,7% sono decine di descrizioni fuorvianti che ogni settimana atterrano nelle inbox dei reviewer.\nSecondo, ognuna è costosa.\nLe PR ad alta inconsistenza:\nVengono accettate il 51,7% in meno rispetto alle PR consistenti Impiegano 3,5× di tempo per il merge quando vengono accettate Spesso hanno codice tecnicamente valido — il rifiuto riguarda la storia, non la sostanza Un reviewer che scopre che la descrizione gli ha mentito non concede il beneficio del dubbio all\u0026rsquo;agente sul paragrafo successivo, né sul file successivo, né sulla PR successiva. La fiducia si paga in anticipo e si recupera lentamente.\nPerché il costo è così alto Due meccanismi si compongono:\nCosto di ri-orientamento. Un reviewer che si aspettava fix all\u0026rsquo;autenticazione e trova refactoring del database deve buttare via il modello mentale e costruirne uno nuovo. È l\u0026rsquo;operazione più costosa in code review. Tende anche a far emergere istinti difensivi: \u0026ldquo;cos\u0026rsquo;altro c\u0026rsquo;è qui dentro che non mi aspettavo?\u0026rdquo;\nContagio della fiducia. Se la descrizione è sbagliata, il reviewer smette di considerarla un riassunto — il che significa che deve leggere il codice con più attenzione di quanta ne avrebbe altrimenti. Ogni PR successiva alla prima inconsistente eredita un piccolo sconto sulla fiducia, soprattutto se viene dallo stesso agente.\nIl risultato finale: una piccola percentuale di PR fuorvianti degrada il throughput dell\u0026rsquo;intera pipeline di review.\nCosa fare Per chi sviluppa agenti, il fix è strutturale. La descrizione non dovrebbe essere generata dal piano. Dovrebbe essere generata dal diff finale, in un passaggio separato, da qualcosa che non ha visto il task originale. Interventi economici che già aiutano:\nPass di verifica. Una seconda chiamata LLM legge diff e descrizione e segnala il mismatch. Controlli euristici. I file menzionati nella descrizione dovrebbero comparire nel diff. Le categorie di bug citate dovrebbero corrispondere ai test che vengono toccati. Rigenerazione della descrizione. Butta via la descrizione che l\u0026rsquo;agente ha scritto in fase di pianificazione. Generane una nuova solo dal diff finale. Per i team che usano questi agenti: assumi che le descrizioni siano inaffidabili finché non si dimostra il contrario. Costruisci l\u0026rsquo;abitudine di scorrere prima il diff, poi la descrizione.\nPer il campo: smettete di valutare gli agenti solo sul codice. Una pull request è un deliverable, e la descrizione è parte del deliverable. Un agente che scrive codice corretto con una PR fuorviante non è un buon agente — è un modo veloce per distruggere la fiducia dei reviewer.\nLa storia vera Man mano che gli agenti diventano meno assistenti e più collaboratori autonomi, il collo di bottiglia si sposta. Non è se sanno scrivere codice. Sanno. La domanda è se ci si possa fidare che descrivano cosa hanno scritto.\nAl momento, sull'1,7% dei tentativi, non si può. E quell'1,7% sta facendo più danni alla relazione tra umani e agenti di quanti ne abbia mai fatto un compile error.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Sarro, F., Sutton, C. (2026). Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests. In: Proceedings of the 23rd International Conference on Mining Software Repositories (MSR 2026) — Mining Challenge Track.\nLeggi il paper originale (PDF)\nRicerca condotta presso la University College London (UCL) e il King\u0026rsquo;s College London.\n","permalink":"https://giovannipinna.net/it/posts/msr2026-message-code-inconsistency/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Abbiamo analizzato \u003cstrong\u003e23.247 pull request\u003c/strong\u003e scritte da agenti di codifica AI e fatto una domanda semplice: la descrizione corrisponde al diff? Nell\u0026rsquo;\u003cstrong\u003e1,7%\u003c/strong\u003e dei casi, no. Sembra poco — finché non vedi le conseguenze. Le PR inconsistenti hanno un \u003cstrong\u003etasso di accettazione inferiore del 51,7%\u003c/strong\u003e e impiegano \u003cstrong\u003e3,5× di tempo\u003c/strong\u003e per essere mergiate. Il codice è a posto. Il problema è la storia che l\u0026rsquo;agente racconta sul codice.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"la-parte-di-una-pr-che-nessuno-misura\"\u003eLa parte di una PR che nessuno misura\u003c/h2\u003e\n\u003cp\u003eQuando facciamo benchmark sugli agenti di codifica AI, misuriamo il codice. Compila? Passa i test? È pulito?\u003c/p\u003e","title":"Quando gli agenti AI mentono sul proprio codice (senza volerlo)"},{"content":" TL;DR Gli agenti di codifica AI bruciano più di 100.000 token per task. Quando il task è \u0026ldquo;ottimizza le performance di questo codice\u0026rdquo;, l\u0026rsquo;agente in sé spesso costa più energia di quanta il codice ottimizzato ne risparmierà mai. Abbiamo costruito GA4GC — Greener Agent for Greener Code — usando NSGA-II per tunare la configurazione dell\u0026rsquo;agente contro tre obiettivi: correttezza del codice, speedup del codice e runtime dell\u0026rsquo;agente. Su un mini-SWE-agent alimentato da Gemini 2.5 Pro sul benchmark SWE-Perf, abbiamo ottenuto una riduzione del runtime del 37,7% migliorando anche la correttezza, con un miglioramento dell\u0026rsquo;hypervolume di 135× rispetto ai default. Bonus: la temperatura è la singola manopola più importante, e gli iperparametri dell\u0026rsquo;LLM controllano la qualità mentre i vincoli dell\u0026rsquo;agente controllano il costo — possono essere tunati quasi indipendentemente. Il paradosso energetico di cui nessuno parla Ecco una cosa che dovrebbe essere ovvia ma non lo è: quando chiedi a un agente AI di ottimizzare le performance del tuo codice, l\u0026rsquo;esecuzione dell\u0026rsquo;agente stesso costa energia. Tanta energia. Spesso più di quanta il codice che sta ottimizzando ne risparmierà mai.\nPensa al conto. L\u0026rsquo;agente legge file, pianifica, genera codice, esegue test, debugga, itera. Una run reale su una repo non banale divora token a sei cifre. Ora immagina che limi 50ms da una funzione. Quante volte deve essere eseguita quella funzione perché si rientri dell\u0026rsquo;energia spesa per renderla più veloce?\nPer alcuni task: centinaia di migliaia di esecuzioni. Per altri: mai. Alcune \u0026ldquo;ottimizzazioni\u0026rdquo; sono perdite energetiche nette.\nÈ una cosa inquietante da scoprire mentre ti dicono che l\u0026rsquo;AI renderà il software più efficiente.\nPerché i default dell\u0026rsquo;agente sono un cattivo punto di partenza Gli agenti di codifica AI hanno spazi di configurazione sorprendentemente grandi. Temperatura. Top_p. Token massimi per step. Numero massimo di step. Varianti del prompt template. Queste manopole interagiscono, spesso in modo controintuitivo. Una temperatura più alta può aiutare su task creativi e sprecare budget su quelli semplici. Limiti di step lasco danno all\u0026rsquo;agente spazio per iterare ma anche per vagare.\nI default che vengono shippati con questi agenti sono scelti da umani per medie ragionevoli all\u0026rsquo;apparenza. Non sono scelti per il tuo task, la tua codebase, il tuo budget energetico. La maggior parte è visibilmente subottimale appena cominci a misurare.\nQuindi ci siamo chiesti: e se trattassimo la configurazione dell\u0026rsquo;agente come un problema di ricerca?\nGA4GC: un loop di ricerca sopra l\u0026rsquo;agente Il setup è semplice in spirito, complicato nella pratica.\nAbbiamo preso un mini-SWE-agent che gira su Gemini 2.5 Pro e abbiamo lasciato che NSGA-II — un algoritmo evolutivo multi-obiettivo — facesse evolvere la sua configurazione. NSGA-II non cerca di trovare una singola configurazione migliore. Mappa una frontiera di Pareto: una frontiera di configurazioni dove non puoi migliorare un obiettivo senza sacrificarne un altro.\nTre obiettivi:\nMinimizza le patch sbagliate. Codice corretto prima di tutto, sempre. Massimizza il guadagno di performance. Tutto il punto del task è rendere più veloce il codice target. Minimizza il runtime dell\u0026rsquo;agente. Non lasciare che l\u0026rsquo;ottimizzatore costi più di quanto valga l\u0026rsquo;ottimizzazione. L\u0026rsquo;agente gira su SWE-Perf, un benchmark di task reali di tuning delle performance dalla libreria Python astropy. Ogni configurazione candidata viene valutata in un ambiente Docker isolato per riproducibilità.\nNSGA-II gestisce lo spazio di configurazione eterogeneo — manopole continue (temperatura, top_p), vincoli interi (token massimi, limiti di step), scelte categoriche (prompt template) — applicando gli operatori giusti a ciascuna.\nCosa abbiamo trovato in 25 valutazioni Sì, 25. È l\u0026rsquo;intero budget. Il punto di GA4GC non è essere costoso — è essere più economico dell\u0026rsquo;alternativa di non fare nulla.\nLe configurazioni non-dominate hanno ottenuto:\nRiduzione del runtime del 37,7%. Configurazione di default: 1.513 secondi. Migliore configurazione di Pareto: 943 secondi. Anche correttezza migliore. Non un trade-off — proprio meglio. Miglioramento dell\u0026rsquo;hypervolume di 135× rispetto alla baseline di default. (L\u0026rsquo;hypervolume misura quanta parte dello spazio degli obiettivi copre la frontiera di Pareto — più grande è meglio.) Il titolo: i default non sono solo subottimali, sono pesantemente subottimali. Guadagni significativi sia in qualità che in efficienza sono lì che aspettano chiunque esegua anche solo un piccolo loop di tuning.\nLa scoperta strutturale che ci ha sorpresi Abbiamo eseguito una regressione Random Forest per capire quali manopole contano davvero. Due cose sono saltate fuori.\nLa temperatura domina. Tra tutte le manopole, la temperatura è la singola più importante. Ha un senso intuitivo — modella tutto lo stile esplorativo dell\u0026rsquo;agente — ma la magnitudine della sua influenza era più grande di quanto ci aspettassimo.\nGli iperparametri dell\u0026rsquo;LLM guidano la qualità. I vincoli dell\u0026rsquo;agente guidano il costo. Sono disaccoppiati.\nQuesta è la scoperta azionabile. Se tuni temperatura e top_p, stai muovendo la manopola di se l\u0026rsquo;agente produce codice buono. Se tuni i limiti di token e di step, stai muovendo la manopola di quanto ti costa. Le due superfici di controllo non si combattono molto. Puoi ottimizzare qualità e costo quasi indipendentemente — il che, metodologicamente, è ottima notizia.\nTre ricette di deployment La frontiera di Pareto non è una risposta singola; è un menu. Tre punti utili:\nRuntime-critical. Temperatura bassa, top_p restrittivo. Meno creativo, più veloce, economico. Usalo quando ti servono risposte velocemente su task relativamente semplici.\nPerformance-critical. Temperatura moderata (0,65–0,73), top_p bilanciato. L\u0026rsquo;agente ha spazio per trovare davvero soluzioni migliori, al costo di più compute. Usalo quando lo speedup che stai cercando di estrarre vale più del runtime dell\u0026rsquo;agente.\nContext-specific. Esegui GA4GC sulla tua codebase e distribuzione di task. Otterrai una frontiera di Pareto cucita sul tuo ambiente, che batte qualunque ricetta generica.\nPerché è più di un trucco di benchmark Mentre gli agenti di codifica AI passano da demo cool a infrastruttura standard, la loro impronta cumulativa di compute diventa una vera questione di sostenibilità. Un\u0026rsquo;organizzazione che esegue centinaia di task con agenti al giorno sta spendendo soldi seri ed energia seria. La maggior parte è prevenibile.\nLa lezione qui è che il tuning della configurazione è una leva di sostenibilità, non solo di performance. Non ti serve un modello più piccolo o hardware speciale per rendere il tuo tooling AI più green — ti serve smettere di accettare default che nessuno ha scelto per la tua situazione.\nSe stai mettendo in produzione agenti AI, esegui un piccolo loop NSGA-II sul tuo spazio di configurazione prima di scalare. L\u0026rsquo;energia che risparmierai sarà la sua ricompensa, e la correttezza migliore che otterrai è un effetto collaterale gratuito.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Sarro, F. (2025). GA4GC: Greener Agent for Greener Code. In: Proceedings of the 17th Symposium on Search-Based Software Engineering (SSBSE 2025) — Challenge Track on Green SBSE.\nLeggi il paper originale (PDF)\nRicerca condotta presso la University College London (UCL) e l\u0026rsquo;Università degli Studi di Trieste.\n","permalink":"https://giovannipinna.net/it/posts/ssbse2025-ga4gc/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Gli agenti di codifica AI bruciano più di 100.000 token per task. Quando il task è \u0026ldquo;ottimizza le performance di questo codice\u0026rdquo;, l\u0026rsquo;agente in sé spesso costa più energia di quanta il codice ottimizzato ne risparmierà mai. Abbiamo costruito \u003cstrong\u003eGA4GC\u003c/strong\u003e — Greener Agent for Greener Code — usando \u003cstrong\u003eNSGA-II\u003c/strong\u003e per tunare la configurazione dell\u0026rsquo;agente contro tre obiettivi: correttezza del codice, speedup del codice e \u003cem\u003eruntime dell\u0026rsquo;agente\u003c/em\u003e. Su un mini-SWE-agent alimentato da Gemini 2.5 Pro sul benchmark SWE-Perf, abbiamo ottenuto una \u003cstrong\u003eriduzione del runtime del 37,7%\u003c/strong\u003e migliorando \u003cem\u003eanche\u003c/em\u003e la correttezza, con un \u003cstrong\u003emiglioramento dell\u0026rsquo;hypervolume di 135×\u003c/strong\u003e rispetto ai default. Bonus: la temperatura è la singola manopola più importante, e gli iperparametri dell\u0026rsquo;LLM controllano la qualità mentre i vincoli dell\u0026rsquo;agente controllano il costo — possono essere tunati quasi indipendentemente.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"il-paradosso-energetico-di-cui-nessuno-parla\"\u003eIl paradosso energetico di cui nessuno parla\u003c/h2\u003e\n\u003cp\u003eEcco una cosa che dovrebbe essere ovvia ma non lo è: quando chiedi a un agente AI di \u003cem\u003eottimizzare le performance del tuo codice\u003c/em\u003e, l\u0026rsquo;esecuzione dell\u0026rsquo;agente stesso costa energia. Tanta energia. Spesso più di quanta il codice che sta ottimizzando ne risparmierà mai.\u003c/p\u003e","title":"A volte il tuo agente AI brucia più energia a ottimizzare il codice di quanta il codice ne risparmierà mai"},{"content":" TL;DR Classificare gli hotfix software — le patch in modalità panico che spedisci per riparare qualcosa che si è rotto in produzione adesso — è difficile per il ML: dataset minuscolo (88 entry, 17 categorie), sbilanciamento brutale tra le classi e feature LLM costose. HotCat riformula la feature engineering come un problema di ricerca: NSGA-II fa evolvere maschere binarie su 18 feature, ottimizzando accuratezza, NMI e runtime contemporaneamente. Una data augmentation a due stadi alza la generalizzazione dal 55% al 72%. La frontiera di Pareto offre una configurazione bilanciata: 59% accuratezza, 0,58 NMI, 129 secondi. La cosa più sorprendente: alcune feature fanno attivamente male — eliminarle è sia più veloce che più accurato. Gli hotfix non sono bug normali In un qualsiasi progetto software normale, i bug si accodano. Vengono triagiati, prioritizzati, schedulati negli sprint. Alcuni stanno lì per mesi.\nGli hotfix sono i bug che non possono aspettare. L\u0026rsquo;autenticazione si è rotta. I pagamenti si sono fermati. I dati dei clienti stanno trapelando. La pipeline di rilascio viene bypassata e una patch esce adesso. Sono i bug più costosi da spedire — sia in serate-di-venerdì-tranquille perse, sia in soldi.\nCapire la forma dei tuoi hotfix — che tipi di fallimenti continuano a richiedere patch d\u0026rsquo;emergenza — è enormemente utile. Ti dice dove la tua codebase è fragile, quali categorie di test ti stanno fallendo, quali processi devono cambiare. Lo strumento classico per farlo è una tassonomia dei bug: un modo strutturato per dire \u0026ldquo;questo hotfix era un memory leak, quello era una race condition\u0026rdquo;.\nCostruire una buona tassonomia automaticamente è difficile. Gli hotfix sono sparsi, le categorie sono selvaggiamente sbilanciate, e l\u0026rsquo;analisi semantica che serve di solito richiede LLM — che costano soldi veri quando li scali.\nDue problemi insieme Avevamo due motivazioni impilate una sull\u0026rsquo;altra.\nMetodologicamente: possiamo classificare bene gli hotfix nonostante dati minuscoli e classi sbilanciate?\nAmbientalmente: possiamo farlo senza bruciare cicli LLM inutili?\nNon sono domande separate. Il classificatore più economico è quello che usa meno feature. Quello più accurato è qualunque insieme di feature porti davvero segnale. Se queste due cose si sovrappongono — se alcune feature costano molto e non aiutano — allora entrambi i problemi possono essere risolti contemporaneamente.\nQuindi ci siamo posti la domanda ovvia: quali feature contano davvero?\nCome funziona HotCat Usiamo il dataset HotBugs — 88 entry di hotfix su 17 categorie di bug da progetti reali. Per ognuna, raccogliamo tre tipi di feature:\nFeature di codice dal diff stesso (linee aggiunte/rimosse, file modificati, complessità sintattica) Metadati di processo da Jira (tempo per risolvere, numero di partecipanti, priorità) Riassunti generati da LLM di ogni patch, embeddati con Sentence-BERT, poi organizzati con K-Means Diciotto feature in totale. Significa 2^18 ≈ 260.000 sottoinsiemi di feature possibili. La selezione manuale è disperata.\nQuindi abbiamo lanciato NSGA-II sopra. Ogni candidato è una maschera binaria sulle 18 feature — tieni o scarta, su ciascuna. Tre obiettivi, ottimizzati congiuntamente:\nMassimizza l\u0026rsquo;accuratezza di classificazione. Massimizza l\u0026rsquo;NMI (Normalized Mutual Information — robusta allo sbilanciamento delle classi, a differenza dell\u0026rsquo;accuratezza grezza). Minimizza il runtime. Popolazione di 20, evoluta per 20 generazioni. Piccolissimo per gli standard di NSGA-II. Sufficiente.\nI dati sono troppo pochi. Ecco come abbiamo fatto. 88 entry su 17 categorie significa che alcune categorie hanno una manciata di esempi. La generalizzazione sul dataset grezzo si fermava intorno al 55%, che è ai limiti dell\u0026rsquo;utile.\nAbbiamo aggiunto una strategia di data augmentation a due stadi:\nBilanciamento delle categorie — esempi sintetici per pareggiare le categorie rare. Generazione di record post-ottimizzazione — dati aggiuntivi dopo la selezione delle feature, per irrobustire la generalizzazione. Questo ha portato la generalizzazione dal 55% al 72%. Un salto di 17 punti. La data augmentation non è glamour ma è esattamente quello che serviva qui.\nRisultati La frontiera di Pareto dà un menu, non una risposta. Due punti utili sopra:\nConfigurazione bilanciata: 59% di accuratezza, 0,58 NMI, 129 secondi di runtime. Configurazione di massima accuratezza: 63% di accuratezza, 132 secondi — tre secondi in più ti comprano quattro punti di accuratezza.\nIl risultato principale è strutturale e un po\u0026rsquo; controintuitivo. Alcune feature stavano peggiorando le cose. Rimuoverle selettivamente ha migliorato sia l\u0026rsquo;accuratezza che il runtime. È il sogno della Green AI: più economico perché è migliore, non nonostante lo sia.\nRibalta anche l\u0026rsquo;istinto classico della feature engineering. La mossa di default quando la classificazione va male è aggiungere più feature. L\u0026rsquo;evidenza di HotCat dice: misura prima. Alcune delle feature che hai aggiunto sono rumore, e il rumore fa male.\nPerché questo conta oltre gli hotfix Due insegnamenti vanno oltre questo problema specifico.\nL\u0026rsquo;ottimizzazione multi-obiettivo sullo spazio delle feature è sottoutilizzata. La maggior parte delle pipeline ML tratta la feature engineering come un esercizio umano una tantum. NSGA-II la rende un problema di ricerca continua con trade-off espliciti tra cui scegliere. Quel framing si applica ogni volta che hai molte feature candidate e un vero trade-off costo-qualità.\nLa Green AI non è una tassa — può essere una guida. Trattare il runtime come obiettivo di prima classe anziché come ripensamento cambia quali feature sopravvivono. Il risultato è più snello e migliore. Mentre gli strumenti di analisi basati su LLM si diffondono nelle pipeline di software engineering, l\u0026rsquo;organizzazione che si prende la briga di fare questo tipo di tuning pagherà meno e spedirà meglio.\nSe stai fissando un task di classificazione con troppe feature e troppo pochi dati, la prossima mossa giusta potrebbe non essere più feature. Potrebbe essere una frontiera di Pareto.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Sarro, F. (2025). HotCat: Green and Effective Feature Selection for Hotfix Bug Taxonomy. In: Proceedings of the 17th Symposium on Search-Based Software Engineering (SSBSE 2025) — Challenge Track on Hot Fixing Benchmark.\nLeggi il paper originale (PDF)\nRicerca condotta presso la University College London (UCL) e l\u0026rsquo;Università degli Studi di Trieste.\n","permalink":"https://giovannipinna.net/it/posts/ssbse2025-hotcat/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Classificare gli \u003cem\u003ehotfix\u003c/em\u003e software — le patch in modalità panico che spedisci per riparare qualcosa che si è rotto in produzione adesso — è difficile per il ML: dataset minuscolo (88 entry, 17 categorie), sbilanciamento brutale tra le classi e feature LLM costose. \u003cstrong\u003eHotCat\u003c/strong\u003e riformula la feature engineering come un problema di ricerca: NSGA-II fa evolvere maschere binarie su 18 feature, ottimizzando accuratezza, NMI \u003cem\u003ee\u003c/em\u003e runtime contemporaneamente. Una data augmentation a due stadi alza la generalizzazione dal \u003cstrong\u003e55% al 72%\u003c/strong\u003e. La frontiera di Pareto offre una configurazione bilanciata: \u003cstrong\u003e59% accuratezza, 0,58 NMI, 129 secondi\u003c/strong\u003e. La cosa più sorprendente: \u003cstrong\u003ealcune feature fanno attivamente male\u003c/strong\u003e — eliminarle è sia più veloce \u003cem\u003eche\u003c/em\u003e più accurato.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"gli-hotfix-non-sono-bug-normali\"\u003eGli hotfix non sono bug normali\u003c/h2\u003e\n\u003cp\u003eIn un qualsiasi progetto software normale, i bug si accodano. Vengono triagiati, prioritizzati, schedulati negli sprint. Alcuni stanno lì per mesi.\u003c/p\u003e","title":"A volte la migliore feature engineering è buttare via le feature"},{"content":" TL;DR Il text-to-SQL è ovunque, ma lo misuriamo male. Exact Match ti penalizza se scrivi users AS u. Execution Accuracy non si interessa se hai azzeccato 99 righe su 100 — sbagliato è sbagliato. Abbiamo costruito QAS (Query Accuracy Score): un punteggio continuo che combina similarità semantica code-aware (quanto è vicino il SQL?) con similarità di tabella basata su edit-distance (quanto è vicina la risposta?). Testato su 11 modelli su BIRD, QAS rivela differenze enormi che le metriche binarie schiacciano nello stesso numero. Un campo costruito su lanci di moneta Il text-to-SQL è una di quelle aree dove le demo sembrano magiche. Scrivi una domanda in italiano, ottieni una query SQL, ottieni una risposta dal tuo database. Niente DBA. La promessa è enorme.\nIl progresso è reale. La misurazione del progresso non lo è.\nGuarda una qualunque leaderboard text-to-SQL e vedrai due metriche che fanno tutto il lavoro: Exact Match e Execution Accuracy. Entrambe binarie. Una query è corretta o non lo è. Non c\u0026rsquo;è una via di mezzo.\nQuesto è un problema. La maggior parte delle query che \u0026ldquo;falliscono\u0026rdquo; non è davvero spazzatura casuale — sono giuste all'80%, con un filtro sbagliato, una colonna mancante, una riga in più. Trattarle come identiche a \u0026ldquo;query completamente sbagliata sulla tabella sbagliata\u0026rdquo; butta via esattamente l\u0026rsquo;informazione che ci serve per migliorare i modelli.\nPerché Exact Match è una pessima battuta Exact Match confronta due stringhe SQL carattere per carattere. Stringa uguale, score 1. Stringa diversa, score 0.\n-- Reference SELECT name FROM users WHERE age \u0026gt; 25 -- Generato SELECT u.name FROM users AS u WHERE u.age \u0026gt; 25 Restituiscono risultati identici su ogni riga di ogni database dell\u0026rsquo;universo. Exact Match valuta la seconda come fallimento totale.\nSQL è un linguaggio dichiarativo. Ci sono dozzine di modi validi per scrivere la stessa query. Alias, ordine delle JOIN, subquery contro JOIN, WHERE contro HAVING — tutta flessibilità sintattica, tutto semanticamente equivalente, tutto silurato da una metrica che confronta stringhe.\nPerché Execution Accuracy è meglio ma comunque sbagliata Execution Accuracy almeno esegue le due query e confronta le tabelle dei risultati. Se le righe combaciano, score 1. Altrimenti, 0.\nRisolve elegantemente il problema degli alias. E ne crea uno diverso: niente credito parziale.\nUna query che restituisce 99 righe corrette su 100 prende zero. Una query che seleziona le colonne giuste dalle tabelle giuste ma con un filtro leggermente sbagliato prende zero. Una query contro tabelle completamente sbagliate — anch\u0026rsquo;essa zero.\nNon sono lo stesso tipo di fallimento. Trattarli come uno solo distrugge segnale di cui ricercatori e professionisti hanno disperato bisogno.\nQAS: un punteggio continuo con due occhi Abbiamo costruito QAS — il Query Accuracy Score — per sistemare la cosa. È un numero tra 0 e 1, e ha due componenti che misurano cose diverse:\nS_C — Similarità Semantica. Quanto sono vicine le query stesse? Embeddiamo entrambe le query con UAE-Code-Large-V1, un modello addestrato specificamente sul codice. Gli embedding di testo general-purpose non capiscono il SQL — non sanno che LEFT JOIN e RIGHT JOIN non sono sinonimi, o che le subquery possono essere funzionalmente identiche alle JOIN. Gli embedding code-specialized sì. Prendiamo la cosine similarity tra gli embedding. Quella è S_C.\nS_T — Similarità di Tabella. Quanto sono vicini i risultati? Eseguiamo entrambe le query e confrontiamo le tabelle risultanti con edit distance — il numero minimo di inserimenti, cancellazioni e sostituzioni per trasformare una tabella nell\u0026rsquo;altra, normalizzato per dimensione. Sbagliata di una riga? S_T alto. Sbagliata su ogni valore? S_T basso.\nIl punteggio finale è semplicemente:\nQAS = w · S_T + (1 − w) · S_C\nAbbiamo testato quanto sia sensibile il ranking a w usando la distanza di Kendall e la risposta è: poco. I ranking sono stabili per w ∈ [0.25, 0.75]. Abbiamo scelto w = 0.5 perché volevamo che intento e risultato pesassero ugualmente.\nUn sotto-risultato piccolo ma importante: proxy semplici come \u0026ldquo;le tabelle dei risultati hanno lo stesso numero di righe?\u0026rdquo; non funzionano. Abbiamo misurato la correlazione tra similarità di forma e similarità di contenuto effettivo ed era essenzialmente zero. Due tabelle con forma identica possono contenere dati completamente diversi. L\u0026rsquo;edit distance sul contenuto effettivo è necessario.\nCosa mostra QAS che le metriche binarie nascondono Abbiamo applicato QAS a 11 modelli text-to-SQL sul benchmark BIRD — specialisti fine-tuned, sistemi general-purpose tipo GPT-4, modelli open-source di varie dimensioni.\nDue risultati spiccano.\nDifferenze nascoste tra modelli \u0026ldquo;equivalenti\u0026rdquo;. Due modelli con la stessa Execution Accuracy del ~65% possono avere forme di fallimento completamente diverse. Uno era un mediocre affidabile — sempre vicino, raramente perfetto. L\u0026rsquo;altro era bipolare — perfetto o catastrofico, niente in mezzo. Le metriche binarie li chiamano \u0026ldquo;lo stesso modello\u0026rdquo;. Non lo sono.\nCapacità diagnostica. Le due componenti di QAS funzionano come un piccolo kit diagnostico:\nS_C alto, S_T basso → il modello ha capito la query ma ha sbagliato i valori (filtro sbagliato, condizione mancante). Parla SQL, ma non sa fare i conti. S_C basso, S_T alto → query strutturalmente diversa, output simile. O una riformulazione intelligente o un match accidentale. S_C basso, S_T basso → il modello non ha capito la domanda. Quella distinzione conta. Il primo caso si sistema con grounding migliore sul contenuto del database. Il terzo serve comprensione migliore dell\u0026rsquo;intento. Le metriche binarie non ti danno nessuna delle due — solo \u0026ldquo;sbagliato\u0026rdquo;.\nCosa abilita Per i ricercatori: smettete di riportare un numero solo. Riportate una distribuzione. Mostrare che il vostro modello ha QAS medio più alto sui fallimenti rispetto alla baseline è un\u0026rsquo;affermazione significativa, anche quando l\u0026rsquo;accuratezza binaria è identica.\nPer i professionisti: un modello accurato al 70% con QAS medio alto sui fallimenti è molto diverso da un modello accurato al 70% con QAS medio basso sui fallimenti. Il primo è \u0026ldquo;vicino la maggior parte delle volte, deploya con cautela\u0026rdquo;. Il secondo è \u0026ldquo;successo binario, prepara il fallback\u0026rdquo;. Le decisioni di deployment dipendono da questo.\nPer il training: QAS è continuo e differenziabile in spirito. Potrebbe essere usato come segnale di reward più ricco rispetto ai segnali pass/fail su cui i modelli si allenano oggi. Non dobbiamo accontentarci della supervisione binaria quando finalmente la nostra metrica di valutazione ha trama.\nIl TL;DR è semplice. Non puoi ottimizzare quello che non vedi. Le metriche binarie non vedono il gradiente di \u0026ldquo;quasi giusto\u0026rdquo;. QAS sì.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Manzoni, L., De Lorenzo, A., Castelli, M. (2025). Beyond Exact Set and Execution Matches: Redefining Text-to-SQL Metrics with Semantic and Structural Similarity. Scientific Reports, 15(1): 22357.\nLeggi il paper originale (PDF) — Codice su GitHub\nRicerca condotta presso l\u0026rsquo;Università degli Studi di Trieste e la NOVA Information Management School (NOVA IMS), Universidade Nova de Lisboa.\n","permalink":"https://giovannipinna.net/it/posts/scireports2025-text-to-sql-metrics/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Il text-to-SQL è ovunque, ma lo misuriamo male. \u003cstrong\u003eExact Match\u003c/strong\u003e ti penalizza se scrivi \u003ccode\u003eusers AS u\u003c/code\u003e. \u003cstrong\u003eExecution Accuracy\u003c/strong\u003e non si interessa se hai azzeccato 99 righe su 100 — sbagliato è sbagliato. Abbiamo costruito \u003cstrong\u003eQAS (Query Accuracy Score)\u003c/strong\u003e: un punteggio continuo che combina similarità semantica code-aware (quanto è vicino il SQL?) con similarità di tabella basata su edit-distance (quanto è vicina la risposta?). Testato su 11 modelli su BIRD, QAS rivela differenze \u003cem\u003eenormi\u003c/em\u003e che le metriche binarie schiacciano nello stesso numero.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"un-campo-costruito-su-lanci-di-moneta\"\u003eUn campo costruito su lanci di moneta\u003c/h2\u003e\n\u003cp\u003eIl text-to-SQL è una di quelle aree dove le demo sembrano magiche. Scrivi una domanda in italiano, ottieni una query SQL, ottieni una risposta dal tuo database. Niente DBA. La promessa è enorme.\u003c/p\u003e","title":"Il campo del Text-to-SQL ha un problema di misurazione"},{"content":" TL;DR Il nostro lavoro a EuroGP 2024 ha mostrato che il Genetic Improvement (GI) può salvare il codice generato da LLM. Questo seguito rende più intelligente la parte GI in sé. Tre upgrade: selezione lexicase per tenere vivi gli specialisti, down-sampling al 10% per ridurre il compute, e una funzione di fitness raffinata (F_E) che dà credito parziale anziché pass/fail. Su quattro LLM (GPT-4, ChatGPT, Code Llama 7B, LLaMA 3 8B) e tre problemi PSB2, abbiamo migliorato 11 combinazioni modello-problema su 12. I modelli più piccoli guadagnano di più. Il GI è, sempre più, un amplificatore di capacità per modelli economici. Cosa avevamo lasciato sul tavolo l\u0026rsquo;ultima volta Il paper di EuroGP 2024 ha dimostrato l\u0026rsquo;idea base: prendi la prima bozza buggata di un LLM, passala alla Grammatical Evolution, ricevi codice migliore. Guadagni statisticamente significativi su ogni modello.\nMa l\u0026rsquo;evoluzione in sé era grezza. Selezione a torneo. Funzione di fitness binaria. Un budget di ricerca che scalava male con il numero di test case. Avevamo una pipeline funzionante che lasciava vincite per terra.\nQuesto paper è l\u0026rsquo;audit. Abbiamo ricostruito tre pezzi del loop GI — selezione, sampling, fitness — e abbiamo chiesto se un\u0026rsquo;evoluzione più intelligente compra di più.\nRisposta breve: sì.\nPerché la selezione a torneo è il default sbagliato La selezione a torneo prende individui con mini-competizioni: ne peschi a caso un gruppo, tieni il migliore. È veloce e facile e ha una debolezza nota — ama i generalisti e uccide gli specialisti.\nQuesto conta per il codice. Immagina due varianti della bozza di un LLM:\nVariante A: passa il 60% dei test case, fallisce gli altri in modo mediocre. Variante B: massimo dei voti su tutti i test sui numeri interi, fallisce sulla manipolazione di stringhe. La Variante A vince il torneo ogni volta. La Variante B porta conoscenza parziale preziosa che il crossover avrebbe potuto combinare con un altro specialista sulle stringhe — ma non supera mai il primo turno.\nLa selezione a torneo tratta il miglioramento dei programmi come una singola dimensione. I programmi reali falliscono lungo molte dimensioni contemporaneamente.\nLexicase: tenere vivi gli stravaganti La selezione lexicase valuta i candidati un test case alla volta, in ordine casuale, filtrando chiunque non sia tra i migliori a parimerito su quel caso. L\u0026rsquo;ordine viene rimescolato ad ogni evento di selezione, quindi essere uno specialista su qualunque sottoinsieme di casi è una strategia di sopravvivenza.\nSembra costoso — e su 1.000 test case per problema lo sarebbe. Quindi l\u0026rsquo;abbiamo accoppiata al down-sampling: ad ogni generazione si usa solo il 10% dei test case. Un 10% diverso ogni generazione, così l\u0026rsquo;intero test set continua a esercitare pressione nel tempo, solo distribuita.\nLa combinazione tiene vivi gli specialisti senza il conto in compute del lexicase pieno su set di test pieni.\nDare alla ricerca una bussola più fine La funzione di fitness originale era la frazione di test case superati. Binaria per caso. Un test che si aspetta [1, 2, 3, 4, 5] premia [1, 2, 3, 4, 6] (una cifra sbagliata) come \u0026quot;hello\u0026quot; (caos semantico).\nQuella è informazione di gradiente sprecata. Abbiamo costruito F_E, una funzione di fitness che misura quanto vicino è l\u0026rsquo;output a quello atteso, per ciascun test case. Per i numeri, la distanza. Per le sequenze, confronto elemento per elemento. Ora \u0026ldquo;quasi giusto\u0026rdquo; è un numero diverso da \u0026ldquo;completamente sbagliato\u0026rdquo;, e la ricerca può salire la collina giusta invece di trattare tutto il paesaggio come un dirupo.\nCosa abbiamo fatto girare Quattro LLM lungo lo spettro: GPT-4, ChatGPT, Code Llama 7B, LLaMA 3 8B. Tre problemi PSB2 scelti per varietà di difficoltà. Popolazione di 200 individui (giù da 1.000 — selezione migliore significa meno bisogno di forza bruta), fino a 100 generazioni, 30 ripetizioni ciascuna per robustezza statistica.\nCosa abbiamo ottenuto 11 combinazioni modello-problema su 12 sono migliorate. Non è fortuna.\nQualche dettaglio degno di nota:\nI modelli più piccoli hanno guadagnato di più, di nuovo. Code Llama 7B e LLaMA 3 8B hanno avuto i salti relativi più grandi. Anche GPT-4 ha guadagnato, ma in termini assoluti il suo punto di partenza era già forte. Lexicase mantiene davvero la diversità. Si vedeva nelle dinamiche di popolazione — più specialisti distinti che coesistevano per molte generazioni, ricombinandosi via crossover in ibridi che né la selezione a torneo né la self-correction avrebbero mai scoperto. Il down-sampling è essenzialmente gratis. Tagliare le valutazioni al 10% dei test case per generazione non ha degradato la qualità della soluzione finale sui nostri problemi. Conta: il GI è molto più deployabile quando il costo per generazione è sopportabile. F_E paga di più sui problemi difficili. Quando il seme dell\u0026rsquo;LLM è già vicino, credito parziale e credito binario convergono. Quando il seme è lontano, F_E dà alla ricerca qualcosa da seguire. E ancora una volta, il GI batte la self-correction Abbiamo rifatto il confronto con la self-correction. Stessa conclusione dell\u0026rsquo;anno scorso, con evidenza più forte: il loop evolutivo trova fix che il modello non trova ri-promptandosi da solo, soprattutto quando il codice originale ha problemi strutturali a cui il modello è cieco.\nSe stai già usando self-correction in produzione, questo non è un sostituto — è uno stack. Fai prima self-correct se vuoi; poi esegui il GI sopra. Le due modalità di fallimento sono diverse, e i guadagni si compongono.\nCosa conferma La lezione di quadro generale non è cambiata da EuroGP 2024, ma si sta facendo più solida: il GI è un amplificatore di capacità. Comprime il divario tra modelli economici e modelli costosi. Un modello da 7B parametri con un loop GI intelligente sopra può arrivare nello stesso quartiere di un modello frontier che gira nudo — a una frazione del costo di inferenza.\nPer organizzazioni che non possono permettersi di chiamare GPT-4 ad ogni richiesta di generazione di codice, questa non è una nota a piè di pagina. È il titolo.\nCosa è ancora difficile Tre limitazioni oneste:\nDipendenza dall\u0026rsquo;oracolo. Il GI ha bisogno di un segnale di fitness. Niente test case? Sei bloccato. Generare test automaticamente è un altro problema difficile a parte. Scala. PSB2 sono programmi piccoli. Non sappiamo ancora come si comporti su modifiche multi-file a livello di repository. Bias della grammatica. Costruire la grammatica delle mutazioni dall\u0026rsquo;output dell\u0026rsquo;LLM significa che la grammatica eredita i punti ciechi dell\u0026rsquo;LLM. Se il modello non produce mai un ciclo while, neanche la ricerca lo esplorerà mai. Queste sono le prossime cose che inseguiamo.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Manzoni, L., De Lorenzo, A., Castelli, M. (2025). Exploring the Effect of Genetic Improvement for Large Language Models generated Code. SN Computer Science, 6(7).\nLeggi il paper originale (PDF)\nRicerca condotta presso l\u0026rsquo;Università degli Studi di Trieste e la NOVA Information Management School (NOVA IMS), Universidade Nova de Lisboa.\n","permalink":"https://giovannipinna.net/it/posts/sncs2025-exploring-gi-effect/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Il nostro lavoro a EuroGP 2024 ha mostrato che il Genetic Improvement (GI) può salvare il codice generato da LLM. Questo seguito rende più intelligente la parte GI in sé. Tre upgrade: \u003cstrong\u003eselezione lexicase\u003c/strong\u003e per tenere vivi gli specialisti, \u003cstrong\u003edown-sampling al 10%\u003c/strong\u003e per ridurre il compute, e una \u003cstrong\u003efunzione di fitness raffinata (F_E)\u003c/strong\u003e che dà credito parziale anziché pass/fail. Su quattro LLM (GPT-4, ChatGPT, Code Llama 7B, LLaMA 3 8B) e tre problemi PSB2, abbiamo migliorato \u003cstrong\u003e11 combinazioni modello-problema su 12\u003c/strong\u003e. I modelli più piccoli guadagnano di più. Il GI è, sempre più, un \u003cstrong\u003eamplificatore di capacità\u003c/strong\u003e per modelli economici.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"cosa-avevamo-lasciato-sul-tavolo-lultima-volta\"\u003eCosa avevamo lasciato sul tavolo l\u0026rsquo;ultima volta\u003c/h2\u003e\n\u003cp\u003eIl paper di EuroGP 2024 ha dimostrato l\u0026rsquo;idea base: prendi la prima bozza buggata di un LLM, passala alla Grammatical Evolution, ricevi codice migliore. Guadagni statisticamente significativi su ogni modello.\u003c/p\u003e","title":"Rendere davvero intelligente la pipeline LLM-più-evoluzione"},{"content":" Abstract Questo articolo, presentato a Ital-IA 2025, fornisce un riepilogo completo del nostro programma di ricerca sull\u0026rsquo;applicazione del Genetic Improvement al codice generato dagli LLM, estendendo due studi pubblicati (EuroGP 2024 e SN Computer Science 2025). La scoperta centrale attraverso entrambi i lavori è che gli approcci neurali ed evolutivi sono complementari: gli LLM eccellono nella generazione rapida di codice plausibile, mentre il Genetic Improvement eccelle nel raffinamento sistematico verso specifiche precise. L\u0026rsquo;effetto \u0026ldquo;amplificatore di capacità\u0026rdquo; — dove i modelli più piccoli e open-source beneficiano in modo più drammatico dal raffinamento evolutivo — suggerisce che il GI può contribuire a ridurre il divario tra modelli piccoli e grandi. Discutiamo inoltre le limitazioni chiave, tra cui la dipendenza dall\u0026rsquo;oracolo, la scalabilità a progetti multi-file, il bias della grammatica ereditato dall\u0026rsquo;output dell\u0026rsquo;LLM e la mancanza di garanzie formali inerente alla ricerca stocastica. Pubblicato a Ital-IA 2025, Roma. Introduzione L\u0026rsquo;intersezione tra Large Language Models e calcolo evolutivo rappresenta una delle frontiere più promettenti nell\u0026rsquo;ingegneria del software automatizzata. Negli ultimi due anni, il nostro gruppo di ricerca ha sviluppato e raffinato una metodologia per migliorare sistematicamente il codice generato dagli LLM utilizzando tecniche di Genetic Improvement (GI). Questo articolo, presentato a Ital-IA 2025 (la 5ª Conferenza Nazionale sull\u0026rsquo;Intelligenza Artificiale, organizzata dal CINI), fornisce un riepilogo completo di questo programma di ricerca e delle sue scoperte chiave.\nIl Programma di Ricerca Il nostro lavoro si basa su un\u0026rsquo;osservazione semplice ma potente: il codice generato dagli LLM, anche quando non soddisfa completamente le specifiche, contiene tipicamente informazioni strutturali preziose. I programmi generati utilizzano tipi di dati appropriati, implementano algoritmi ragionevoli e catturano la forma generale delle soluzioni corrette. Quello che manca loro è la precisione — le condizioni esatte, la gestione dei casi limite e i dettagli algoritmici che separano \u0026ldquo;approssimativamente corretto\u0026rdquo; da \u0026ldquo;completamente corretto\u0026rdquo;.\nIl Genetic Improvement sfrutta questa osservazione trattando gli output degli LLM come punti di partenza per l\u0026rsquo;ottimizzazione evolutiva. Piuttosto che scartare il codice errato e ricominciare da zero, il GI lo evolve verso la correttezza attraverso un processo di variazione guidata e selezione.\nContributi Chiave Attraverso Due Studi Studio 1: GI con Evoluzione Grammaticale (EuroGP 2024) Il nostro primo studio ha introdotto la pipeline a tre fasi di estrazione del codice, specializzazione dinamica della grammatica e ricerca evolutiva. L\u0026rsquo;innovazione tecnica chiave è stata la generazione automatica di grammatiche BNF personalizzate per ciascun programma generato dall\u0026rsquo;LLM, garantendo che le mutazioni rimangano sintatticamente valide e focalizzate sui costrutti di codice rilevanti.\nValutato su 25 problemi PSB2 attraverso 5 LLM (GPT-4, ChatGPT, LLaMA-2 13B, Alpaca-13B, Alpaca-7B), l\u0026rsquo;approccio ha raggiunto miglioramenti statisticamente significativi (p \u0026lt; 0.001) per ogni modello testato, superando costantemente la self-correction dell\u0026rsquo;LLM.\nStudio 2: GI Migliorato con Selezione Lexicase (SN Computer Science 2025) Il nostro secondo studio ha raffinato le componenti evolutive. Abbiamo introdotto la selezione lexicase — una strategia che valuta gli individui sui casi di test in sequenza, preservando soluzioni specialiste che eccellono su sottoinsiemi specifici. Combinata con il 10% di down-sampling per l\u0026rsquo;efficienza computazionale e una funzione di fitness raffinata F_E che fornisce credito parziale anziché un verdetto binario, la pipeline migliorata ha raggiunto miglioramenti in 11 su 12 combinazioni modello-problema.\nLa lista aggiornata dei modelli includeva Code Llama 7B e LLaMA 3 8B, con risultati che confermano che il GI fornisce il maggior beneficio relativo ai modelli più piccoli e meno capaci — amplificandone efficacemente le capacità.\nRisultati Trasversali Diverse scoperte sono emerse in modo consistente attraverso entrambi gli studi:\nLa Complementarietà degli Approcci Neurali ed Evolutivi LLM e algoritmi evolutivi hanno punti di forza fondamentalmente diversi. Gli LLM eccellono nella generazione rapida di soluzioni plausibili sfruttando pattern appresi da vasti corpus di codice. Gli algoritmi evolutivi eccellono nel raffinamento sistematico guidato dalle specifiche. La loro combinazione produce risultati che nessuno dei due approcci raggiunge da solo.\nL\u0026rsquo;Effetto \u0026ldquo;Amplificatore di Capacità\u0026rdquo; Il beneficio relativo del GI è inversamente proporzionale alla capacità iniziale dell\u0026rsquo;LLM. I modelli più deboli (Alpaca-7B, Code Llama 7B) mostrano i miglioramenti più drammatici, mentre i modelli più forti (GPT-4) mostrano guadagni minori ma comunque significativi. Questo ha importanti implicazioni pratiche: le organizzazioni che utilizzano modelli più piccoli e open-source per ragioni di costo o privacy possono usare il GI per ridurre il divario con i modelli proprietari più grandi.\nLa Specializzazione Grammaticale come Progettazione dello Spazio di Ricerca La generazione dinamica di grammatiche specifiche per problema si è rivelata più di una comodità tecnica — è una forma di progettazione intelligente dello spazio di ricerca. Sfruttando le scelte strutturali dell\u0026rsquo;LLM come conoscenza pregressa, la ricerca evolutiva opera in una regione molto più piccola e produttiva dello spazio dei programmi.\nLimitazioni e Sfide Aperte Abbiamo identificato diverse limitazioni che definiscono i confini dell\u0026rsquo;approccio attuale:\nDipendenza dall\u0026rsquo;oracolo: La funzione di fitness richiede casi di test o un oracolo di riferimento per la valutazione. I problemi senza specifiche chiare o suite di test non possono essere affrontati con la metodologia attuale.\nVincoli di scalabilità: La nostra valutazione si è concentrata su programmi piccoli e autonomi. L\u0026rsquo;ingegneria del software nel mondo reale coinvolge progetti multi-file con dipendenze complesse, che l\u0026rsquo;approccio basato su grammatica attuale non gestisce.\nPropagazione del bias dell\u0026rsquo;LLM: Poiché la grammatica è derivata dall\u0026rsquo;output dell\u0026rsquo;LLM, i bias strutturali nel codice generato — come la preferenza per certi costrutti di loop o strutture dati — vengono ereditati dallo spazio di ricerca. Questo potrebbe impedire la scoperta di soluzioni che richiedono scelte architetturali fondamentalmente diverse.\nMancanza di garanzie: Gli algoritmi evolutivi sono stocastici per natura. Sebbene i nostri risultati mostrino miglioramenti consistenti in media, non c\u0026rsquo;è garanzia di miglioramento per ogni singola esecuzione o istanza di problema.\nDirezioni Future Il programma di ricerca continua su diversi fronti: esplorazione di approcci GI senza grammatica che possano operare direttamente sugli AST senza l\u0026rsquo;intermediario BNF; sviluppo di tecniche di approssimazione del fitness per ridurre la dipendenza dalla valutazione esaustiva dei casi di test; e indagine sull\u0026rsquo;integrazione del GI in flussi di lavoro di ingegneria del software su scala più ampia dove sono necessarie modifiche multi-file.\nPresentato alla 5ª Conferenza Nazionale sull\u0026rsquo;Intelligenza Artificiale (Ital-IA 2025), organizzata dal CINI, 23-24 giugno 2025, Roma, Italia. Questa ricerca è stata condotta presso l\u0026rsquo;Università degli Studi di Trieste e la NOVA Information Management School (NOVA IMS), Universidade Nova de Lisboa.\n","permalink":"https://giovannipinna.net/it/posts/italia2025-gi-summary/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eAbstract\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Questo articolo, presentato a Ital-IA 2025, fornisce un riepilogo completo del nostro programma di ricerca sull\u0026rsquo;applicazione del Genetic Improvement al codice generato dagli LLM, estendendo due studi pubblicati (EuroGP 2024 e SN Computer Science 2025). La scoperta centrale attraverso entrambi i lavori è che gli approcci neurali ed evolutivi sono complementari: gli LLM eccellono nella generazione rapida di codice plausibile, mentre il Genetic Improvement eccelle nel raffinamento sistematico verso specifiche precise. L\u0026rsquo;effetto \u0026ldquo;amplificatore di capacità\u0026rdquo; — dove i modelli più piccoli e open-source beneficiano in modo più drammatico dal raffinamento evolutivo — suggerisce che il GI può contribuire a ridurre il divario tra modelli piccoli e grandi. Discutiamo inoltre le limitazioni chiave, tra cui la dipendenza dall\u0026rsquo;oracolo, la scalabilità a progetti multi-file, il bias della grammatica ereditato dall\u0026rsquo;output dell\u0026rsquo;LLM e la mancanza di garanzie formali inerente alla ricerca stocastica. Pubblicato a Ital-IA 2025, Roma.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"introduzione\"\u003eIntroduzione\u003c/h2\u003e\n\u003cp\u003eL\u0026rsquo;intersezione tra Large Language Models e calcolo evolutivo rappresenta una delle frontiere più promettenti nell\u0026rsquo;ingegneria del software automatizzata. Negli ultimi due anni, il nostro gruppo di ricerca ha sviluppato e raffinato una metodologia per migliorare sistematicamente il codice generato dagli LLM utilizzando tecniche di Genetic Improvement (GI). Questo articolo, presentato a \u003cstrong\u003eItal-IA 2025\u003c/strong\u003e (la 5ª Conferenza Nazionale sull\u0026rsquo;Intelligenza Artificiale, organizzata dal CINI), fornisce un riepilogo completo di questo programma di ricerca e delle sue scoperte chiave.\u003c/p\u003e","title":"Migliorare il Codice Generato dagli LLM tramite Genetic Improvement: Un Riepilogo dei Recenti Avanzamenti"},{"content":" TL;DR Le sentenze della Corte Costituzionale italiana sono scritte per gli avvocati. La maggior parte dei cittadini non riesce a seguirle. Un LLM può sistemare la cosa? Abbiamo condotto uno studio umano con 75 persone confrontando quattro versioni dello stesso contenuto giuridico: sentenze originali, massime di esperti, riassunti di GPT-4o, e un LLaMA 2 7B fine-tuned. Tassi di comprensione: massime di esperti 45%, GPT-4o 38%, sentenze grezze 33%, LLaMA fine-tuned 30%. GPT-4o rende davvero più leggibile il testo giuridico. Produce anche un pattern preoccupante: sicuro, fluente, sbagliato — i lettori se ne vanno con comprensioni errate ma fortemente possedute. Usa gli LLM per il riassunto giuridico. Non usarli senza supervisione umana. Un problema democratico travestito da problema tecnico Le sentenze della Corte Costituzionale sono tra i documenti più importanti che un paese produce. Definiscono cosa il tuo governo può e non può fare. Modellano quali sono i tuoi diritti. Sono anche scritte da giuristi, per giuristi, in una densa prosa giuridica italiana che il cittadino medio non ha alcuna possibilità di comprendere.\nLa Corte Costituzionale italiana cerca già di risolvere la cosa. Per ogni sentenza pubblica una massima — un riassunto condensato scritto da esperti giuridici il cui mestiere intero è rendere accessibile la giurisprudenza. Le massime sono meglio delle sentenze complete, ma assumono comunque un\u0026rsquo;alfabetizzazione giuridica che la maggior parte delle persone non ha.\nQuindi la domanda è semplice: un LLM può aiutare a chiudere il divario? Non sostituendo i giudici o gli esperti giuridici, ma producendo riassunti che un cittadino normale possa davvero leggere?\nAbbiamo fatto l\u0026rsquo;esperimento.\nCosa abbiamo testato Quattro versioni dello stesso contenuto giuridico:\nSentenze originali — il testo grezzo dalla Corte. Massime di esperti — i riassunti scritti da umani, il nostro tetto di qualità. Riassunti di GPT-4o — generati promptando GPT-4o di OpenAI su ciascuna sentenza. LLaMA 2 7B fine-tuned — un modello open-source più piccolo addestrato su 10.000 coppie sentenza-massima estratte dagli archivi della Corte. Abbiamo provato anche Gemma 2B/7B e LLaMantino 7B (un LLaMA italianizzato) nella pipeline di fine-tuning; LLaMA 2 7B è risultato il migliore, quindi rappresenta il lato open-source nello studio umano.\nCome abbiamo misurato la comprensione 75 partecipanti. Circa il 25% con conoscenza giuridica (studenti di legge, professionisti), il 75% senza (pubblico generale). Ogni persona ha letto riassunti su tutti i tipi di testo e ha risposto a domande di comprensione sul contenuto effettivo.\nL\u0026rsquo;abbiamo eseguito come disegno between-subjects — ogni caso sottostante è stato visto da ciascun partecipante in uno solo dei quattro formati — per eliminare effetti di apprendimento. Le differenze tra formati sono state testate con il chi-quadro.\nCosa abbiamo trovato I numeri principali:\nMassime di esperti: 45% di comprensione. Il nostro tetto, come previsto. GPT-4o: 38% di comprensione. Significativamente meglio delle sentenze grezze. Sentenze originali: 33% di comprensione. Lo status quo. LLaMA 2 7B fine-tuned: 30% di comprensione. Leggermente peggio della sentenza grezza. Quest\u0026rsquo;ultimo merita una pausa. Fare il fine-tuning di un piccolo modello open su 10.000 riassunti di esperti non ha aiutato. Ha peggiorato. La capacità conta; per questo task, 7B parametri sembra essere troppo poco per interiorizzare la comprensione strutturale che rende buona una massima.\nGPT-4o, dall\u0026rsquo;altra parte, dà un significativo +5 punti rispetto a leggere la sentenza da soli. È reale.\nE poi diventa scomodo Ecco la parte che dovrebbe darti da pensare.\nQuando abbiamo guardato quali tipi di risposte sbagliate davano le persone, i lettori di GPT-4o mostravano un tasso molto più alto di errori sicuri. Non solo capivano male — uscivano con comprensioni forti, definitive e sbagliate di cosa avesse stabilito la Corte.\nIl testo era fluente. Autorevole. Liscio. Si leggeva come se l\u0026rsquo;avesse scritto un esperto. E nei casi in cui era sbagliato, quella fluenza rendeva i lettori più sicuri, non meno, di aver capito.\nNon è unico al riassunto giuridico. È il noto pattern degli LLM di confabulazione fluente. Ma la posta in gioco cambia radicalmente quando il tema è \u0026ldquo;cosa ha detto la Corte Costituzionale sui tuoi diritti\u0026rdquo;. Un lettore sicuro di sé ma sbagliato di una sentenza è peggio di un lettore confuso. La confusione ti spinge a chiedere. La sicurezza no.\nCosa ha fatto il titolo di studio sul quadro I partecipanti con conoscenza giuridica avevano una comprensione più uniforme su tutti i tipi di testo — leggevano la sentenza originale all\u0026rsquo;incirca come il riassunto. Il formato contava meno perché portavano il proprio grounding.\nI partecipanti senza conoscenza giuridica erano enormemente dipendenti dal formato. Hanno beneficiato di più di un buon riassunto — ed erano i più vulnerabili a un riassunto sicuro ma sbagliato.\nIn altre parole: le persone che il riassunto LLM dovrebbe aiutare sono anche le persone più esposte alle sue modalità di fallimento. È il vincolo di design che chiunque deployi questo tipo di strumento deve prendere sul serio.\nCosa farne davvero Tre conclusioni concrete.\nPer chi costruisce legal-tech: i riassunti LLM di testo giuridico sono una vera vincita sull\u0026rsquo;accessibilità, ma il deployment grezzo è pericoloso. Il pattern giusto è bozze LLM, revisione esperta — usa il modello per la scala, l\u0026rsquo;umano per l\u0026rsquo;accuratezza. Il risparmio è nel revisionare una bozza invece di scriverla da zero.\nPer i ricercatori AI: le metriche di valutazione che premiano fluenza e coerenza mancano completamente questa classe di fallimenti. Servono metodi di valutazione che cerchino specificamente l\u0026rsquo;errore sicuro. Un riassunto che si legge magnificamente ma ti dice la cosa sbagliata è un fallimento peggiore di uno goffo ma corretto.\nPer tutti gli altri: quando leggi un documento giuridico riassunto da un\u0026rsquo;AI — o qualunque documento ad alta posta in gioco — calibra. La sicurezza nella prosa non è prova della verità della prosa. La fluenza è la confezione, non il contenuto.\nIl quadro più ampio L\u0026rsquo;accessibilità dell\u0026rsquo;informazione giuridica è, alla fine, una questione di partecipazione democratica. Quando i cittadini non possono leggere le sentenze che governano le loro vite, i principi di trasparenza e responsabilità si erodono. Gli LLM possono aiutare a chiudere quel divario. Possono anche, se deployati senza cura, allargare un divario diverso — quello tra ciò che le persone pensano di aver capito e ciò che hanno effettivamente capito.\nLa tecnologia è pronta ad assistere. Non è pronta a essere lasciata da sola.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Manzoni, L., De Lorenzo, A., Castelli, M. (2024). From Courts to Comprehension: Can LLMs Make Judgments More Accessible?. In: Proceedings of the 23rd IEEE/WIC International Conference on Web Intelligence and Intelligent Agent Technology (WI-IAT 2024), dicembre 2024.\nLeggi il paper originale (PDF)\nRicerca condotta presso l\u0026rsquo;Università degli Studi di Trieste e la NOVA Information Management School (NOVA IMS), Universidade Nova de Lisboa.\n","permalink":"https://giovannipinna.net/it/posts/wiat2024-courts-to-comprehension/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Le sentenze della Corte Costituzionale italiana sono scritte per gli avvocati. La maggior parte dei cittadini non riesce a seguirle. Un LLM può sistemare la cosa? Abbiamo condotto uno studio umano con 75 persone confrontando quattro versioni dello stesso contenuto giuridico: sentenze originali, massime di esperti, riassunti di GPT-4o, e un LLaMA 2 7B fine-tuned. Tassi di comprensione: \u003cstrong\u003emassime di esperti 45%\u003c/strong\u003e, \u003cstrong\u003eGPT-4o 38%\u003c/strong\u003e, \u003cstrong\u003esentenze grezze 33%\u003c/strong\u003e, \u003cstrong\u003eLLaMA fine-tuned 30%\u003c/strong\u003e. GPT-4o rende davvero più leggibile il testo giuridico. Produce anche un pattern preoccupante: \u003cstrong\u003esicuro, fluente, sbagliato\u003c/strong\u003e — i lettori se ne vanno con comprensioni errate ma fortemente possedute. Usa gli LLM per il riassunto giuridico. Non usarli senza supervisione umana.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"un-problema-democratico-travestito-da-problema-tecnico\"\u003eUn problema democratico travestito da problema tecnico\u003c/h2\u003e\n\u003cp\u003eLe sentenze della Corte Costituzionale sono tra i documenti più importanti che un paese produce. Definiscono cosa il tuo governo può e non può fare. Modellano quali sono i tuoi diritti. Sono anche scritte da giuristi, per giuristi, in una densa prosa giuridica italiana che il cittadino medio non ha alcuna possibilità di comprendere.\u003c/p\u003e","title":"GPT-4 può rendere le sentenze più leggibili. Può anche raccontartele in modo sbagliato, con sicurezza."},{"content":" TL;DR Gli LLM scrivono codice che quasi funziona. Il rimedio classico è chiedere di nuovo — la \u0026ldquo;self-correction\u0026rdquo; — ma tende a ripetere gli stessi errori. Noi abbiamo seguito una strada diversa: trattare il codice buggato come un seme e farlo evolvere. Usando l\u0026rsquo;Evoluzione Grammaticale con una grammatica costruita al volo dall\u0026rsquo;output stesso dell\u0026rsquo;LLM, abbiamo migliorato il codice di GPT-4, ChatGPT, LLaMA-2, Alpaca-13B e Alpaca-7B su 25 problemi PSB2 — con guadagni statisticamente significativi (p \u0026lt; 0.001) per ogni modello. Più piccolo il modello, maggiore il guadagno. La trappola della self-correction Chiedi a un qualsiasi LLM moderno di scrivere una funzione Python e otterrai qualcosa che sembra giusta. Esegui i test e spesso scoprirai che non lo è.\nIl riflesso è ovvio: incollare i test falliti nella chat e chiedere al modello di riprovare. È intuitivo, gratis, e qualche volta funziona. Ma ha un soffitto — e il soffitto è il modello stesso. Un modello non può debuggare facilmente quello che non riesce a vedere. I cicli di self-correction tendono a riciclare gli stessi punti ciechi, gli stessi off-by-one, gli stessi edge case dimenticati.\nQuindi ci siamo posti una domanda diversa: e se l\u0026rsquo;LLM fosse solo la prima bozza?\nIl codice come materiale evolvibile Il Genetic Improvement (GI) è una tecnica search-based che tratta i programmi come l\u0026rsquo;evoluzione tratta i genomi. Muta, ricombina, seleziona, ripeti. È stato usato per correggere bug e ridurre il runtime di sistemi legacy. Noi ci siamo chiesti se potesse salvare anche il codice degli LLM.\nL\u0026rsquo;intuizione è che il codice generato da un LLM è raramente completamente sbagliato. Di solito è strutturalmente sensato — tipi di dato giusti, algoritmo ragionevole — ma con un difetto sottile. Questo lo rende un ottimo seme: probabilmente esistono buoni vicini nello spazio di ricerca, serve solo un modo intelligente per trovarli.\nIl problema: mutazioni casuali sul codice sorgente producono quasi sempre roba che non si compila nemmeno. Il nostro trucco è stato vincolare le mutazioni attraverso una grammatica specializzata su ciascun programma.\nLa pipeline, in tre mosse 1. Estrai. Tira fuori il vero codice Python dalla risposta verbosa dell\u0026rsquo;LLM, intrisa di markdown. È più difficile di quanto sembri — i modelli amano avvolgere il codice nella prosa.\n2. Specializza. Parsa il codice in un Abstract Syntax Tree, poi automaticamente costruisci una grammatica BNF da quello che vedi. Solo cicli for e interi nell\u0026rsquo;originale? Allora la grammatica permette solo cicli for e interi. Lo spazio delle mutazioni resta piccolo e sensato.\n3. Evolvi. Passa il seme e la grammatica a PonyGE2 e lascia che l\u0026rsquo;Evoluzione Grammaticale faccia il suo — popolazione di 1.000 individui, fino a 100 generazioni, fitness = frazione di test PSB2 superati.\nLa grammatica dinamica è la salsa segreta. Una grammatica universale per \u0026ldquo;tutto il Python valido\u0026rdquo; farebbe esplodere lo spazio di ricerca; una grammatica scritta a mano sarebbe fragile. Generandola dall\u0026rsquo;output stesso dell\u0026rsquo;LLM, usiamo la bozza del modello come conoscenza pregressa su dove probabilmente vive la risposta giusta.\nCosa abbiamo trovato Abbiamo eseguito tutto questo su 25 problemi del benchmark PSB2 e cinque LLM lungo lo spettro delle capacità: GPT-4, ChatGPT, LLaMA-2, Alpaca-13B, Alpaca-7B. Ogni esperimento ripetuto 30 volte. Test di Wilcoxon dei ranghi con segno per la significatività.\nIl riassunto è breve:\nTutti i modelli sono migliorati. Statisticamente significativo (p \u0026lt; 0.001) ovunque. I modelli più piccoli hanno guadagnato di più. Problemi su Alpaca-7B passati da \u0026ldquo;0 test superati\u0026rdquo; a \u0026ldquo;funziona davvero\u0026rdquo; in molti casi. Anche GPT-4 ne ha beneficiato. Guadagni assoluti minori, perché il seme era già forte, ma comunque reali. Il GI ha battuto la self-correction. Stesso codice di partenza, stesso feedback dai test — l\u0026rsquo;evoluzione ha trovato fix migliori di quelli che il modello trovava chiedendoglieli. Quest\u0026rsquo;ultimo punto è quello che metterei su un cartellone. La self-correction è limitata dalla rappresentazione del problema interna al modello. La ricerca evolutiva no.\nPerché funziona Tre cose, impilate:\nIl seme è abbastanza buono. Gli LLM ti danno la forma giusta della soluzione. Non devi inventare l\u0026rsquo;algoritmo — devi solo aggiustarlo.\nLa grammatica focalizza la ricerca. Adattare le mutazioni a quello che il programma effettivamente contiene uccide il 99% dello spazio di ricerca — la parte che non sarebbe mai stata utile.\nLe popolazioni non si bloccano. Gli approcci greedy del tipo \u0026ldquo;correggi quel bug\u0026rdquo; finiscono in ottimi locali. Una popolazione tiene vive più scommesse e può ricombinare vincite parziali tramite crossover.\nCosa suggerisce Se metti in produzione codice generato da LLM, questo lavoro suggerisce che la pipeline giusta non è prompt → output → ship. È prompt → output → ottimizza → ship. La fase di ottimizzazione non ha bisogno di un modello più grande o di più token — ha bisogno di un loop di ricerca con una buona funzione di fitness.\nE c\u0026rsquo;è un quadro più grande qui: i metodi neurali ed evolutivi non sono concorrenti, sono complementari. Gli LLM sono veloci, fluenti, creativi; l\u0026rsquo;evoluzione è paziente, sistematica, orientata al risultato. Combinali, e ottieni qualcosa che nessuno dei due fa da solo.\nReference Questo post è una sintesi divulgativa di:\nPinna, G., Ravalico, D., Rovito, L., Manzoni, L., De Lorenzo, A. (2024). Improving Large Language Models Code Generation by Leveraging Genetic Improvement. In: Proceedings of the 27th European Conference on Genetic Programming (EuroGP 2024), parte di EvoStar 2024, Aberystwyth, UK, 3–5 aprile.\nLeggi il paper originale (PDF)\nRicerca condotta presso l\u0026rsquo;Università degli Studi di Trieste e la NOVA Information Management School (NOVA IMS), Universidade Nova de Lisboa.\n","permalink":"https://giovannipinna.net/it/posts/eurogp2024-gi-for-llm-code/","summary":"\u003cdiv class=\"summary-box\"\u003e\n  \u003cdiv class=\"summary-box-header\"\u003e\n    \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"18\" height=\"18\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cline x1=\"4\" y1=\"6\" x2=\"20\" y2=\"6\"/\u003e\u003cline x1=\"4\" y1=\"12\" x2=\"14\" y2=\"12\"/\u003e\u003cline x1=\"4\" y1=\"18\" x2=\"18\" y2=\"18\"/\u003e\u003c/svg\u003e\n    \u003cspan\u003eTL;DR\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"summary-box-content\"\u003e\n    Gli LLM scrivono codice che \u003cem\u003equasi\u003c/em\u003e funziona. Il rimedio classico è chiedere di nuovo — la \u0026ldquo;self-correction\u0026rdquo; — ma tende a ripetere gli stessi errori. Noi abbiamo seguito una strada diversa: \u003cstrong\u003etrattare il codice buggato come un seme e farlo evolvere\u003c/strong\u003e. Usando l\u0026rsquo;Evoluzione Grammaticale con una grammatica costruita al volo dall\u0026rsquo;output stesso dell\u0026rsquo;LLM, abbiamo migliorato il codice di GPT-4, ChatGPT, LLaMA-2, Alpaca-13B e Alpaca-7B su 25 problemi PSB2 — con guadagni statisticamente significativi (p \u0026lt; 0.001) per \u003cem\u003eogni\u003c/em\u003e modello. Più piccolo il modello, maggiore il guadagno.\n  \u003c/div\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"la-trappola-della-self-correction\"\u003eLa trappola della self-correction\u003c/h2\u003e\n\u003cp\u003eChiedi a un qualsiasi LLM moderno di scrivere una funzione Python e otterrai qualcosa che sembra giusta. Esegui i test e spesso scoprirai che non lo è.\u003c/p\u003e","title":"E se smettessimo di chiedere a ChatGPT di correggere il proprio codice?"},{"content":"Influence — Il Marketing incontra l\u0026rsquo;AI Influence è un progetto che combina strategie di marketing con l\u0026rsquo;intelligenza artificiale per analizzare i dati degli utenti e generare contenuti per i social media su misura per gli interessi del pubblico.\nFunzionalità Text Mining — Estrae informazioni dai social media per identificare gli argomenti preferiti dal pubblico e le parole chiave ricorrenti Sentiment Analysis — Valuta il sentiment pubblico come positivo, negativo o neutro Social Network Analysis — Prevede l\u0026rsquo;attrattività dei contenuti e stima il potenziale virale Contesto Sviluppato dopo aver completato il corso di Trasformazione Digitale presso l\u0026rsquo;Università di Trieste (luglio 2020) e ulteriormente perfezionato durante la competizione del Contamination LAB, dove ha raggiunto la finale.\nTecnologie Natural Language Processing (NLP) Machine Learning Social Media APIs Visualizzazione dei Dati Leggi l\u0026rsquo;articolo completo\n","permalink":"https://giovannipinna.net/it/projects/influence/","summary":"\u003ch2 id=\"influence--il-marketing-incontra-lai\"\u003eInfluence — Il Marketing incontra l\u0026rsquo;AI\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eInfluence\u003c/strong\u003e è un progetto che combina strategie di marketing con l\u0026rsquo;intelligenza artificiale per analizzare i dati degli utenti e generare contenuti per i social media su misura per gli interessi del pubblico.\u003c/p\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/NXmEs4L-rRg?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch3 id=\"funzionalità\"\u003eFunzionalità\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eText Mining\u003c/strong\u003e — Estrae informazioni dai social media per identificare gli argomenti preferiti dal pubblico e le parole chiave ricorrenti\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSentiment Analysis\u003c/strong\u003e — Valuta il sentiment pubblico come positivo, negativo o neutro\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSocial Network Analysis\u003c/strong\u003e — Prevede l\u0026rsquo;attrattività dei contenuti e stima il potenziale virale\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"contesto\"\u003eContesto\u003c/h3\u003e\n\u003cp\u003eSviluppato dopo aver completato il corso di Trasformazione Digitale presso l\u0026rsquo;Università di Trieste (luglio 2020) e ulteriormente perfezionato durante la competizione del Contamination LAB, dove ha raggiunto la finale.\u003c/p\u003e","title":"Influence"},{"content":"Panoramica del Progetto Influence è un progetto che rappresenta una sintesi tra il mondo del marketing e quello dell\u0026rsquo;intelligenza artificiale. L\u0026rsquo;idea centrale è analizzare i dati degli utenti per generare contenuti per i social media che corrispondano agli interessi e alle preferenze di un pubblico specifico.\nLa piattaforma offre un\u0026rsquo;analisi dettagliata del pubblico riguardo al sentiment e ai temi popolari, fornendo informazioni utili per i creatori di contenuti e i professionisti del marketing.\nImplementazione Tecnica La piattaforma è alimentata da tre algoritmi chiave di machine learning:\n1. Text Mining Le tecniche di Text Mining vengono utilizzate per estrarre informazioni significative da fonti scritte. Questo ci permette di identificare gli argomenti preferiti dal pubblico target e rilevare le parole chiave ricorrenti nei commenti e nelle interazioni sui social media.\n2. Sentiment Analysis La Sentiment Analysis è una tecnica di Natural Language Processing (NLP) che valuta il testo per determinare se l\u0026rsquo;opinione espressa è positiva, negativa o neutra. Questo fornisce un feedback immediato sulle risposte emotive del pubblico ai diversi tipi di contenuto.\n3. Social Network Analysis La Social Network Analysis esamina la struttura e le dinamiche dei social network per prevedere quanto sarà attraente un contenuto e stimare il suo potenziale virale con accuratezza misurabile.\nGenesi del Progetto Ho sviluppato questo concept dopo aver completato un corso di Trasformazione Digitale nel luglio 2020, offerto dall\u0026rsquo;Università di Trieste in collaborazione con la Regione Friuli Venezia Giulia. Il corso era focalizzato sulla user experience e sulle strategie di posizionamento online.\nSuccessivamente, ho partecipato al Contamination LAB dell\u0026rsquo;Università di Trieste, dove ho creato modelli di business formali e piani per il progetto, arrivando in finale nella competizione.\nLezioni Apprese Questo progetto mi ha insegnato l\u0026rsquo;importanza di collegare diverse discipline — combinando competenze tecniche in AI e machine learning con conoscenze pratiche di marketing e comportamento degli utenti. L\u0026rsquo;intersezione di questi campi crea strumenti potenti per comprendere e coinvolgere il pubblico.\n","permalink":"https://giovannipinna.net/it/posts/influence-project/","summary":"\u003ch2 id=\"panoramica-del-progetto\"\u003ePanoramica del Progetto\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eInfluence\u003c/strong\u003e è un progetto che rappresenta una sintesi tra il mondo del marketing e quello dell\u0026rsquo;intelligenza artificiale. L\u0026rsquo;idea centrale è analizzare i dati degli utenti per generare contenuti per i social media che corrispondano agli interessi e alle preferenze di un pubblico specifico.\u003c/p\u003e\n\u003cp\u003eLa piattaforma offre un\u0026rsquo;analisi dettagliata del pubblico riguardo al sentiment e ai temi popolari, fornendo informazioni utili per i creatori di contenuti e i professionisti del marketing.\u003c/p\u003e","title":"Influence: Progetto tra Marketing e Intelligenza Artificiale"},{"content":"Panoramica \u0026ldquo;Pensieri Lenti e Veloci\u0026rdquo; di Daniel Kahneman è un capolavoro che esplora come i nostri processi decisionali sono influenzati da fattori esterni piuttosto che dalla pura razionalità. Kahneman, psicologo vincitore del Premio Nobel, presenta decenni di ricerca in un formato accessibile.\nI Due Sistemi Il libro introduce due sistemi fondamentali di pensiero:\nSistema 1 — Veloce, istintivo ed emotivo. Opera automaticamente ma è facilmente influenzabile da bias ed euristiche. Sistema 2 — Lento, deliberato e logico. Tuttavia, tende ad essere pigro e spesso approva le scelte del Sistema 1 senza una verifica adeguata. Concetti Chiave Bias Cognitivi Kahneman identifica 14 principali bias cognitivi, tra cui:\nEffetto Ancoraggio — La nostra tendenza a fare affidamento sulla prima informazione incontrata Euristica della Disponibilità — Giudicare la probabilità in base a quanto facilmente vengono in mente gli esempi Effetto Framing — Come la presentazione delle informazioni influenza le nostre decisioni Fallacia Narrativa — La nostra tendenza a costruire storie anche quando mancano le evidenze Rischio e Processo Decisionale Il libro esplora l\u0026rsquo;avversione alla perdita e i pattern decisionali finanziari, dimostrando che gli esseri umani percepiscono le perdite più intensamente dei guadagni equivalenti.\nI Due Sé Kahneman distingue tra:\nIl sé esperienziale — come ci sentiamo nel momento presente Il sé memorizzante — come ricordiamo le esperienze passate La Mia Opinione Questo libro ha cambiato fondamentalmente il modo in cui comprendo il processo decisionale. Non siamo razionali come ci piace credere, ma comprendere questi pattern ci aiuta a fare scelte migliori — sia nella vita personale, nei contesti professionali o nelle strategie di marketing.\nUna lettura imperdibile per chiunque sia interessato alla psicologia, all\u0026rsquo;economia o alla comprensione del comportamento umano.\n","permalink":"https://giovannipinna.net/it/posts/pensieri-lenti-e-veloci/","summary":"\u003ch2 id=\"panoramica\"\u003ePanoramica\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e\u0026ldquo;Pensieri Lenti e Veloci\u0026rdquo;\u003c/strong\u003e di Daniel Kahneman è un capolavoro che esplora come i nostri processi decisionali sono influenzati da fattori esterni piuttosto che dalla pura razionalità. Kahneman, psicologo vincitore del Premio Nobel, presenta decenni di ricerca in un formato accessibile.\u003c/p\u003e\n\u003ch2 id=\"i-due-sistemi\"\u003eI Due Sistemi\u003c/h2\u003e\n\u003cp\u003eIl libro introduce due sistemi fondamentali di pensiero:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSistema 1\u003c/strong\u003e — Veloce, istintivo ed emotivo. Opera automaticamente ma è facilmente influenzabile da bias ed euristiche.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSistema 2\u003c/strong\u003e — Lento, deliberato e logico. Tuttavia, tende ad essere pigro e spesso approva le scelte del Sistema 1 senza una verifica adeguata.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"concetti-chiave\"\u003eConcetti Chiave\u003c/h2\u003e\n\u003ch3 id=\"bias-cognitivi\"\u003eBias Cognitivi\u003c/h3\u003e\n\u003cp\u003eKahneman identifica 14 principali bias cognitivi, tra cui:\u003c/p\u003e","title":"Recensione: Pensieri Lenti e Veloci di Daniel Kahneman"},{"content":"Panoramica \u0026ldquo;Don\u0026rsquo;t Make Me Think\u0026rdquo; di Steve Krug è una guida definitiva sull\u0026rsquo;usabilità web. Il libro fornisce consigli pratici e di buon senso per progettare siti web intuitivi e facili da usare.\nPrincipi Fondamentali Krug definisce l\u0026rsquo;usabilità così: una persona con capacità e esperienza medie dovrebbe essere in grado di capire come usare qualcosa per raggiungere un obiettivo senza incontrare più problemi di quanti ne valga la pena.\nRegole Chiave Non far pensare gli utenti — La navigazione e le azioni devono essere evidenti Rendere visibile il contenuto importante — Gli utenti scansionano le pagine, non le leggono parola per parola Usare convenzioni e gerarchia visiva — Sfruttare ciò che gli utenti già conoscono Semplificare le scelte — Ridurre il carico cognitivo limitando le opzioni Ridurre il testo — Eliminare metà delle parole su ogni pagina, poi eliminare metà di ciò che rimane Punti Salienti dei Capitoli Navigazione del Sito Una buona navigazione risponde a tre domande: Dove mi trovo? Dove posso andare? Come ci arrivo?\nDesign Mobile-First Krug enfatizza l\u0026rsquo;importanza di progettare prima per i dispositivi mobili, poi scalare verso schermi più grandi.\nTest di Usabilità Il libro sostiene l\u0026rsquo;importanza di test di usabilità regolari e informali — anche testare con un piccolo numero di utenti rivela problemi importanti.\nCostruire la Fiducia Gli utenti devono fidarsi del tuo sito prima di interagirci. La fiducia deriva da un design professionale, trasparenza e affidabilità.\nAccessibilità Progettare per l\u0026rsquo;accessibilità beneficia tutti gli utenti, non solo quelli con disabilità. Buona usabilità e buona accessibilità vanno di pari passo.\nLa Mia Opinione Questo libro dovrebbe essere una lettura obbligatoria per chiunque costruisca siti web o prodotti digitali. Il principio della chiarezza rispetto alla consistenza risuona profondamente con il mio approccio al design del software. Ogni decisione dovrebbe ridurre la frizione per l\u0026rsquo;utente.\n","permalink":"https://giovannipinna.net/it/posts/dont-make-me-think/","summary":"\u003ch2 id=\"panoramica\"\u003ePanoramica\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e\u0026ldquo;Don\u0026rsquo;t Make Me Think\u0026rdquo;\u003c/strong\u003e di Steve Krug è una guida definitiva sull\u0026rsquo;usabilità web. Il libro fornisce consigli pratici e di buon senso per progettare siti web intuitivi e facili da usare.\u003c/p\u003e\n\u003ch2 id=\"principi-fondamentali\"\u003ePrincipi Fondamentali\u003c/h2\u003e\n\u003cp\u003eKrug definisce l\u0026rsquo;usabilità così: una persona con capacità e esperienza medie dovrebbe essere in grado di capire come usare qualcosa per raggiungere un obiettivo senza incontrare più problemi di quanti ne valga la pena.\u003c/p\u003e\n\u003ch3 id=\"regole-chiave\"\u003eRegole Chiave\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eNon far pensare gli utenti\u003c/strong\u003e — La navigazione e le azioni devono essere evidenti\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRendere visibile il contenuto importante\u003c/strong\u003e — Gli utenti scansionano le pagine, non le leggono parola per parola\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUsare convenzioni e gerarchia visiva\u003c/strong\u003e — Sfruttare ciò che gli utenti già conoscono\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSemplificare le scelte\u003c/strong\u003e — Ridurre il carico cognitivo limitando le opzioni\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRidurre il testo\u003c/strong\u003e — Eliminare metà delle parole su ogni pagina, poi eliminare metà di ciò che rimane\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"punti-salienti-dei-capitoli\"\u003ePunti Salienti dei Capitoli\u003c/h2\u003e\n\u003ch3 id=\"navigazione-del-sito\"\u003eNavigazione del Sito\u003c/h3\u003e\n\u003cp\u003eUna buona navigazione risponde a tre domande: Dove mi trovo? Dove posso andare? Come ci arrivo?\u003c/p\u003e","title":"Recensione: Don't Make Me Think di Steve Krug"},{"content":"Insegnamento \u0026amp; Mentoring Teaching Assistant — Sistemi di Database, Università di Trieste, Mar–Dic 2024. Progettazione esercitazioni SQL, algebra relazionale, modellazione ER. Valutazione progetti. Tutor Dipartimentale — Data Science \u0026amp; AI, Università di Trieste, Gen–Dic 2024. Ristrutturazione siti web dipartimentali per 200+ studenti. Tutor Dipartimentale — Ingegneria Informatica, Università di Trieste, Ago 2020 – Feb 2021. Gestione amministrazione tirocini. Supervisione Tesi — Supervisione di 4 studenti magistrali e 1 studente triennale su NLP, generazione codice con LLM, genetic improvement e valutazione Text-to-SQL. Summer \u0026amp; Winter School AthNLP — Athens Natural Language Processing Summer School, Atene, Grecia, Set 2024. Selezionato tra 200+ candidati. LxMLS — Lisbon Machine Learning School, Lisbona, Portogallo, Lug 2024. Una delle principali summer school di ML in Europa. ALPS — Advanced Language Processing Winter School, Alpi Francesi, Francia, Apr 2024. Altamente selettiva (~50 partecipanti). DeepLearn — International Summer School on Deep Learning, Gran Canaria, Spagna, Lug 2023. OxML — Oxford Machine Learning Summer School (track NLP), Oxford, UK, Lug 2023. Volontariato EACL 2024 — European Chapter of the Association for Computational Linguistics, St Julian\u0026rsquo;s, Malta, Mar 2024. Volontario a una delle principali conferenze NLP europee. IEEE CCTA 2022 — Conference on Control Technology and Applications, Trieste, Italia, Ago 2022. Volontario per le operazioni della conferenza. Associazioni Professionali AILC — Associazione Italiana di Linguistica Computazionale. Membro dal 2023. AI2S — Associazione triestina per la promozione dell\u0026rsquo;intelligenza artificiale. Membro dal 2020. Mentors4U — La più grande associazione di mentoring no-profit in Europa. Mentee da Lug 2022. Certificazioni McKinsey Forward Program — Programma di apprendimento digitale di 10 settimane di McKinsey.org su adattabilità, problem-solving strutturato, comunicazione e AI. ","permalink":"https://giovannipinna.net/it/activities/","summary":"\u003ch2 id=\"insegnamento--mentoring\"\u003eInsegnamento \u0026amp; Mentoring\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eTeaching Assistant\u003c/strong\u003e — Sistemi di Database, Università di Trieste, Mar–Dic 2024. Progettazione esercitazioni SQL, algebra relazionale, modellazione ER. Valutazione progetti.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTutor Dipartimentale\u003c/strong\u003e — Data Science \u0026amp; AI, Università di Trieste, Gen–Dic 2024. Ristrutturazione siti web dipartimentali per 200+ studenti.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTutor Dipartimentale\u003c/strong\u003e — Ingegneria Informatica, Università di Trieste, Ago 2020 – Feb 2021. Gestione amministrazione tirocini.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSupervisione Tesi\u003c/strong\u003e — Supervisione di 4 studenti magistrali e 1 studente triennale su NLP, generazione codice con LLM, genetic improvement e valutazione Text-to-SQL.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"summer--winter-school\"\u003eSummer \u0026amp; Winter School\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAthNLP\u003c/strong\u003e — Athens Natural Language Processing Summer School, Atene, Grecia, Set 2024. Selezionato tra 200+ candidati.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLxMLS\u003c/strong\u003e — Lisbon Machine Learning School, Lisbona, Portogallo, Lug 2024. Una delle principali summer school di ML in Europa.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eALPS\u003c/strong\u003e — Advanced Language Processing Winter School, Alpi Francesi, Francia, Apr 2024. Altamente selettiva (~50 partecipanti).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDeepLearn\u003c/strong\u003e — International Summer School on Deep Learning, Gran Canaria, Spagna, Lug 2023.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOxML\u003c/strong\u003e — Oxford Machine Learning Summer School (track NLP), Oxford, UK, Lug 2023.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"volontariato\"\u003eVolontariato\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eEACL 2024\u003c/strong\u003e — European Chapter of the Association for Computational Linguistics, St Julian\u0026rsquo;s, Malta, Mar 2024. Volontario a una delle principali conferenze NLP europee.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIEEE CCTA 2022\u003c/strong\u003e — Conference on Control Technology and Applications, Trieste, Italia, Ago 2022. Volontario per le operazioni della conferenza.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"associazioni-professionali\"\u003eAssociazioni Professionali\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAILC\u003c/strong\u003e — Associazione Italiana di Linguistica Computazionale. Membro dal 2023.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAI2S\u003c/strong\u003e — Associazione triestina per la promozione dell\u0026rsquo;intelligenza artificiale. Membro dal 2020.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMentors4U\u003c/strong\u003e — La più grande associazione di mentoring no-profit in Europa. Mentee da Lug 2022.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"certificazioni\"\u003eCertificazioni\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eMcKinsey Forward Program\u003c/strong\u003e — Programma di apprendimento digitale di 10 settimane di McKinsey.org su adattabilità, problem-solving strutturato, comunicazione e AI.\u003c/li\u003e\n\u003c/ul\u003e","title":"Attività"},{"content":" Ciao, sono Giovanni 👋 Ricercatore AI \u0026middot; ML Engineer \u0026middot; Ph.D.\nSono un Ricercatore e Ingegnere AI di Trieste, Italia, con un Dottorato di Ricerca in Data Science \u0026 Intelligenza Artificiale Applicata. Il mio lavoro si colloca all'intersezione tra NLP, Large Language Models e Computazione Evolutiva \u0026mdash; costruendo sistemi che migliorano e valutano il codice generato dall'AI.\nContattami Vedi il mio CV 🎯 La Mia Storia Il mio percorso nell'informatica è iniziato alle superiori, dove mi sono appassionato alla programmazione e all'elettronica. Quella curiosità mi ha portato alla Laurea Triennale in Ingegneria Elettronica e Informatica (2015\u0026ndash;2019) all'Università di Trieste, dove i primi corsi di Intelligenza Artificiale hanno acceso una passione che ha guidato tutto ciò che è venuto dopo \u0026mdash; proseguita con la Laurea Magistrale in Ingegneria Informatica (2019\u0026ndash;2022) con focus su Data Science e AI. Un semestre alla Montanuniversit\u0026auml;t Leoben con Erasmus+ mi ha spinto fuori dalla zona di comfort: applicare l'AI a energia e logistica mi ha insegnato quanto questi metodi siano davvero trasferibili.\nPer la tesi magistrale mi sono dedicato alla computer vision applicata al mondo umanistico, lavorando fianco a fianco con storici dell'arte ed esperti di digital humanities. È stato il mio primo vero contatto con la ricerca accademica, e l'ho amato in ogni sua parte \u0026mdash; confrontarmi con lo stato dell'arte, progettare le valutazioni, capire in profondità come funzionano i modelli più recenti. La tesi è stata poi pubblicata su IEEE Access (2023) e mi ha convinto a proseguire su questa strada.\nHo continuato con un Dottorato Industriale (2023\u0026ndash;2025), co-finanziato da PLUS S.r.l. all'interno di Area Science Park. Ho scelto l'NLP \u0026mdash; un altro ambito che mi aveva sempre affascinato \u0026mdash; ma la mia mentalità ingegneristica mi ha portato verso una ricerca applicata e utile al business. La mia tesi, Application of Large Language Models: Addressing Real-World Challenges, affronta tre domande concrete: come migliorare gli output degli LLM, come valutarli in modo corretto (con nuove metriche per il Text-to-SQL) e come renderli più sostenibili attraverso la Green AI. Lungo il percorso ho trascorso periodi come visiting researcher alla NOVA IMS di Lisbona e all'UCL di Londra, frequentato 5 summer e winter school internazionali su NLP e ML, e pubblicato tra riviste, conferenze e workshop.\nSono una persona proattiva con un profondo desiderio di imparare e spingermi oltre la mia zona di comfort. Credo che la grande ingegneria e la grande ricerca condividano la stessa base: comprendere un problema in profondità, costruire soluzioni metodicamente e misurare l'impatto rigorosamente.\n💬 NLP \u0026 LLM Ampia esperienza con Large Language Models, classificazione del testo, analisi del sentiment e costruzione di pipeline NLP per applicazioni reali, dal testo giuridico ai giornali storici.\n🤖 AI Agents Sviluppo di agenti AI per la generazione di codice SQL e analisi delle performance di agenti AI nella creazione di pull request.\n🗄️ Text-to-SQL Proposta di nuove metriche di valutazione che integrano similarità semantica e strutturale per sistemi Text-to-SQL. Pubblicato su Scientific Reports (Nature/Springer).\n🔍 Sistemi RAG Progettazione e deployment di un sistema RAG in produzione con LangChain e LlamaIndex che ha ridotto il volume del call center del 30%, dimostrando impatto aziendale concreto.\n🧬 Genetic Improvement Sviluppo di pipeline innovative usando Grammatical Evolution per correggere e migliorare automaticamente il codice SQL generato dai LLM. Pubblicato a EuroGP e SN Computer Science.\n🔬 Interessi di Ricerca La mia ricerca è guidata da una domanda fondamentale: come possiamo costruire sistemi AI che colmino il divario tra l'intento umano e le informazioni strutturate? Le aree principali includono:\nNLP \u0026 Large Language Models \u0026mdash; Miglioramento e valutazione degli output dei LLM per task strutturati come la generazione di codice Text-to-SQL \u0026mdash; Sviluppo di sistemi e metriche per l'interrogazione di database in linguaggio naturale Genetic Improvement del Codice \u0026mdash; Uso della computazione evolutiva come layer di post-processing per il codice generato dai LLM AI Coding Agents \u0026mdash; Analisi empirica e ottimizzazione di agenti AI per lo sviluppo software RAG \u0026 Sistemi di Retrieval \u0026mdash; Costruzione di agenti intelligenti che interagiscono con ambienti dati complessi 🌍 Esperienza Internazionale Credo che la migliore ricerca nasca all'intersezione di prospettive diverse:\n🇬🇧 Visiting Researcher a UCL, Londra 🇵🇹 Due soggiorni alla NOVA IMS, Lisbona 🇦🇹 Semestre Erasmus alla Montanuniversit\u0026auml;t Leoben 🎓 5 summer/winter school internazionali (Oxford, Lisbona, Atene, Alpi Francesi, Gran Canaria) Restiamo in Contatto! Sono sempre aperto a nuove collaborazioni, opportunità di ricerca e conversazioni interessanti. Che tu voglia discutere un progetto, condividere idee o semplicemente salutare \u0026mdash; non esitare a contattarmi.\n📧 Inviami un'Email ","permalink":"https://giovannipinna.net/it/about/","summary":"\u003cdiv class=\"about-hero\"\u003e\n  \u003cdiv class=\"about-hero-img\"\u003e\n    \u003cimg src=\"/images/profile.png\" alt=\"Giovanni Pinna\"\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"about-hero-text\"\u003e\n    \u003ch1\u003eCiao, sono Giovanni \u003cspan class=\"wave\"\u003e👋\u003c/span\u003e\u003c/h1\u003e\n    \u003cp class=\"about-tagline\"\u003eRicercatore AI \u0026middot; ML Engineer \u0026middot; Ph.D.\u003c/p\u003e\n    \u003cp\u003eSono un Ricercatore e Ingegnere AI di \u003cstrong\u003eTrieste, Italia\u003c/strong\u003e, con un Dottorato di Ricerca in Data Science \u0026 Intelligenza Artificiale Applicata. Il mio lavoro si colloca all'intersezione tra \u003cstrong\u003eNLP\u003c/strong\u003e, \u003cstrong\u003eLarge Language Models\u003c/strong\u003e e \u003cstrong\u003eComputazione Evolutiva\u003c/strong\u003e \u0026mdash; costruendo sistemi che migliorano e valutano il codice generato dall'AI.\u003c/p\u003e\n    \u003cdiv class=\"about-cta\"\u003e\n      \u003ca href=\"/it/contact/\" class=\"btn-primary\"\u003eContattami\u003c/a\u003e\n      \u003ca href=\"/it/cv/\" class=\"btn-secondary\"\u003eVedi il mio CV\u003c/a\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"about-section\"\u003e\n  \u003ch2\u003e🎯 La Mia Storia\u003c/h2\u003e\n  \u003cp\u003eIl mio percorso nell'informatica è iniziato alle superiori, dove mi sono appassionato alla programmazione e all'elettronica. Quella curiosità mi ha portato alla \u003cstrong\u003eLaurea Triennale in Ingegneria Elettronica e Informatica\u003c/strong\u003e (2015\u0026ndash;2019) all'Università di Trieste, dove i primi corsi di Intelligenza Artificiale hanno acceso una passione che ha guidato tutto ciò che è venuto dopo \u0026mdash; proseguita con la \u003cstrong\u003eLaurea Magistrale in Ingegneria Informatica\u003c/strong\u003e (2019\u0026ndash;2022) con focus su Data Science e AI. Un semestre alla \u003cstrong\u003eMontanuniversit\u0026auml;t Leoben\u003c/strong\u003e con Erasmus+ mi ha spinto fuori dalla zona di comfort: applicare l'AI a energia e logistica mi ha insegnato quanto questi metodi siano davvero trasferibili.\u003c/p\u003e","title":"Chi Sono"},{"content":"Rimaniamo in Contatto Sono sempre aperto a nuove opportunità, collaborazioni e conversazioni. Non esitare a contattarmi!\nContatto Diretto 📧 giovanni.pinna.17l96@gmail.com 📍 Trieste, Italia Trovami Online GitHub LinkedIn Google Scholar YouTube Instagram 📍 Con base a Trieste, Italia ","permalink":"https://giovannipinna.net/it/contact/","summary":"\u003ch2 id=\"rimaniamo-in-contatto\"\u003eRimaniamo in Contatto\u003c/h2\u003e\n\u003cp\u003eSono sempre aperto a nuove opportunità, collaborazioni e conversazioni. Non esitare a contattarmi!\u003c/p\u003e\n\u003cdiv class=\"contact-grid\"\u003e\n\u003cdiv class=\"contact-card\"\u003e\n  \u003ch3\u003eContatto Diretto\u003c/h3\u003e\n  \u003cdiv class=\"contact-links\"\u003e\n    \u003ca href=\"mailto:giovanni.pinna.17l96@gmail.com\"\u003e\u003cspan class=\"contact-icon\"\u003e📧\u003c/span\u003e giovanni.pinna.17l96@gmail.com\u003c/a\u003e\n    \u003cspan class=\"contact-location\"\u003e\u003cspan class=\"contact-icon\"\u003e📍\u003c/span\u003e Trieste, Italia\u003c/span\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"contact-card\"\u003e\n  \u003ch3\u003eTrovami Online\u003c/h3\u003e\n  \u003cdiv class=\"contact-social\"\u003e\n    \u003ca href=\"https://github.com/giovannipinna96\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-link\"\u003e\n      \u003csvg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 496 512\"\u003e\u003cpath fill=\"currentColor\" d=\"M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6zm-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3zm44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9zM244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8z\"/\u003e\u003c/svg\u003e\n      \u003cspan\u003eGitHub\u003c/span\u003e\n    \u003c/a\u003e\n    \u003ca href=\"https://www.linkedin.com/in/giovanni-pinna/\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-link\"\u003e\n      \u003csvg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 448 512\"\u003e\u003cpath fill=\"currentColor\" d=\"M416 32H31.9C14.3 32 0 46.5 0 64.3v383.4C0 465.5 14.3 480 31.9 480H416c17.6 0 32-14.5 32-32.3V64.3c0-17.8-14.4-32.3-32-32.3zM135.4 416H69V202.2h66.5V416zm-33.2-243c-21.3 0-38.5-17.3-38.5-38.5S80.9 96 102.2 96c21.2 0 38.5 17.3 38.5 38.5 0 21.3-17.2 38.5-38.5 38.5zm282.1 243h-66.4V312c0-24.8-.5-56.7-34.5-56.7-34.6 0-39.9 27-39.9 54.9V416h-66.4V202.2h63.7v29.2h.9c8.9-16.8 30.6-34.5 62.9-34.5 67.2 0 79.7 44.3 79.7 101.9V416z\"/\u003e\u003c/svg\u003e\n      \u003cspan\u003eLinkedIn\u003c/span\u003e\n    \u003c/a\u003e\n    \u003ca href=\"https://scholar.google.com/citations?user=bf2RiOAAAAAJ\u0026hl=en\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-link\"\u003e\n      \u003csvg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 24 25\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"\u003e\u003cpath d=\"M5.242 13.769L0.5 9.5 12 1l11.5 9-5.242 3.769C17.548 11.249 14.978 9.5 12 9.5c-2.977 0-5.548 1.748-6.758 4.269zM12 10a7 7 0 1 0 0 14 7 7 0 0 0 0-14z\"/\u003e\u003c/svg\u003e\n      \u003cspan\u003eGoogle Scholar\u003c/span\u003e\n    \u003c/a\u003e\n    \u003ca href=\"https://www.youtube.com/channel/UCiVRlONi_xbN0Qro6C22y-A\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-link\"\u003e\n      \u003csvg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 576 512\"\u003e\u003cpath fill=\"currentColor\" d=\"M549.655 124.083c-6.281-23.65-24.787-42.276-48.284-48.597C458.781 64 288 64 288 64S117.22 64 74.629 75.486c-23.497 6.322-42.003 24.947-48.284 48.597-11.412 42.867-11.412 132.305-11.412 132.305s0 89.438 11.412 132.305c6.281 23.65 24.787 41.5 48.284 47.821C117.22 448 288 448 288 448s170.78 0 213.371-11.486c23.497-6.321 42.003-24.171 48.284-47.821 11.412-42.867 11.412-132.305 11.412-132.305s0-89.438-11.412-132.305zm-317.51 213.508V175.185l142.739 81.205-142.739 81.201z\"/\u003e\u003c/svg\u003e\n      \u003cspan\u003eYouTube\u003c/span\u003e\n    \u003c/a\u003e\n    \u003ca href=\"https://www.instagram.com/pinna.giova/\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-link\"\u003e\n      \u003csvg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 448 512\"\u003e\u003cpath fill=\"currentColor\" d=\"M224.1 141c-63.6 0-114.9 51.3-114.9 114.9s51.3 114.9 114.9 114.9S339 319.5 339 255.9 287.7 141 224.1 141zm0 189.6c-41.1 0-74.7-33.5-74.7-74.7s33.5-74.7 74.7-74.7 74.7 33.5 74.7 74.7-33.6 74.7-74.7 74.7zm146.4-194.3c0 14.9-12 26.8-26.8 26.8-14.9 0-26.8-12-26.8-26.8s12-26.8 26.8-26.8 26.8 12 26.8 26.8zm76.1 27.2c-1.7-35.9-9.9-67.7-36.2-93.9-26.2-26.2-58-34.4-93.9-36.2-37-2.1-147.9-2.1-184.9 0-35.8 1.7-67.6 9.9-93.9 36.1s-34.4 58-36.2 93.9c-2.1 37-2.1 147.9 0 184.9 1.7 35.9 9.9 67.7 36.2 93.9s58 34.4 93.9 36.2c37 2.1 147.9 2.1 184.9 0 35.9-1.7 67.7-9.9 93.9-36.2 26.2-26.2 34.4-58 36.2-93.9 2.1-37 2.1-147.8 0-184.8zM398.8 388c-7.8 19.6-22.9 34.7-42.6 42.6-29.5 11.7-99.5 9-132.1 9s-102.7 2.6-132.1-9c-19.6-7.8-34.7-22.9-42.6-42.6-11.7-29.5-9-99.5-9-132.1s-2.6-102.7 9-132.1c7.8-19.6 22.9-34.7 42.6-42.6 29.5-11.7 99.5-9 132.1-9s102.7-2.6 132.1 9c19.6 7.8 34.7 22.9 42.6 42.6 11.7 29.5 9 99.5 9 132.1s2.7 102.7-9 132.1z\"/\u003e\u003c/svg\u003e\n      \u003cspan\u003eInstagram\u003c/span\u003e\n    \u003c/a\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"contact-map\"\u003e\n  \u003ch3\u003e📍 Con base a Trieste, Italia\u003c/h3\u003e\n  \u003cdiv class=\"map-container\"\u003e\n    \u003ciframe src=\"https://www.google.com/maps/embed?pb=!1m18!1m12!1m3!1d44537.89874413384!2d13.737732!3d45.6495264!2m3!1f0!2f0!3f0!3m2!1i1024!2i768!4f13.1!3m3!1m2!1s0x477b6b06e4edf533%3A0x666a2484d4dd2b50!2sTrieste%2C%20Province%20of%20Trieste%2C%20Italy!5e0!3m2!1sit!2sit!4v1710000000000\" allowfullscreen=\"\" loading=\"lazy\" referrerpolicy=\"no-referrer-when-downgrade\"\u003e\u003c/iframe\u003e\n  \u003c/div\u003e\n\u003c/div\u003e","title":"Contatti"},{"content":" Scarica una copia del mio CV:\n📄 Scarica CV Completo (PDF) 📋 Scarica CV Breve (PDF) Ultimo aggiornamento: Aprile 2026\n💼 Esperienza Visiting Researcher University College London (UCL) Set 2025 – Dic 2025 · Londra, UK Ricerca su AI coding agents, green AI e ottimizzazione multi-obiettivo. Co-sviluppo del framework GA4GC (135× miglioramento dell'hypervolume). Studio empirico su 7.156 pull request generate da AI. Visiting Researcher NOVA IMS, Universidade NOVA de Lisboa Mag–Ago 2025 · Lisbona, Portogallo Periodo di ricerca in cui ho sviluppato un AI Agent per task Text-to-SQL utilizzando solo piccoli modelli open-source, rendendo possibile l'interrogazione di database in linguaggio naturale senza API proprietarie. Teaching Assistant — Sistemi di Database Università di Trieste Mar 2024 – Dic 2024 · Trieste, Italia Guida degli studenti nello sviluppo di sistemi database. Progettazione di esercitazioni su SQL, algebra relazionale, modellazione ER. Valutazione di tutti i progetti degli studenti. Visiting Researcher NOVA IMS, Universidade NOVA de Lisboa Mag–Ago 2024 · Lisbona, Portogallo Periodo di ricerca in cui ho creato una nuova metrica di valutazione per il Text-to-SQL (pubblicata su Scientific Reports / Nature). Applied AI Scientist PLUS S.r.l., Area Science Park Gen 2023 – Dic 2025 · Trieste, Italia Progettazione e deploy di un sistema RAG in produzione (riduzione del volume del call center del 30%). Sviluppo di pipeline di Genetic Improvement per la correzione del codice generato dagli LLM. Proposta di nuove metriche di valutazione per il Text-to-SQL. Supervisione di 5 tesi. Tutor Dipartimentale — Data Science \u0026amp; AI Università di Trieste Gen 2024 – Dic 2024 · Trieste, Italia Ristrutturazione dei siti web dipartimentali. Punto di riferimento per 200+ studenti per orientamento accademico. 🎓 Formazione Dottorato di Ricerca in Data Science \u0026amp; Intelligenza Artificiale Applicata Università di Trieste Gen 2023 – Dic 2025 · Trieste, Italia Tesi: \"Application of Large Language Models: Addressing Real-World Challenges\". Dottorato industriale co-finanziato da PLUS S.r.l. (Area Science Park). Supervisori: Prof. Luca Manzoni, Prof. Andrea De Lorenzo. Visiting internazionali: UCL Londra, NOVA IMS Lisbona. Laurea Magistrale in Ingegneria Informatica Università di Trieste Set 2019 – Ott 2022 · Voto: 108/110 Tesi: \"An Automatic Tool for the Recognition of Punches in Late-Medieval Panel Paintings\" (pubblicata su IEEE Access). Erasmus alla Montanuniversität Leoben, Austria. Laurea Triennale in Ingegneria Elettronica e Informatica Università di Trieste Set 2015 – Mar 2019 · Trieste, Italia 🛠️ Competenze Tecniche Linguaggi di Programmazione Python (5+ anni)SQLJavaC++ Framework ML \u0026amp; NLP PyTorchHuggingFacescikit-learnspaCyNLTKBERTopic Framework LLM \u0026amp; Agenti LangChainLlamaIndexLangGraphRAG PipelinesPrompt Engineering Strumenti \u0026amp; Infrastruttura Git/GitHubDockerLinuxLaTeXStreamlitGradio 🌍 Lingue Italiano Madrelingua Inglese C1 (Avanzato) ","permalink":"https://giovannipinna.net/it/cv/","summary":"\u003cdiv class=\"cv-download-section\"\u003e\n  \u003cp\u003eScarica una copia del mio CV:\u003c/p\u003e\n  \u003cdiv class=\"cv-buttons\"\u003e\n    \u003ca href=\"/files/Giovanni_Pinna_CV_long.pdf\" class=\"btn-primary\" download\u003e📄 Scarica CV Completo (PDF)\u003c/a\u003e\n    \u003ca href=\"/files/Giovanni_Pinna_CV_short.pdf\" class=\"btn-secondary\" download\u003e📋 Scarica CV Breve (PDF)\u003c/a\u003e\n  \u003c/div\u003e\n  \u003cp class=\"cv-updated\"\u003e\u003cem\u003eUltimo aggiornamento: Aprile 2026\u003c/em\u003e\u003c/p\u003e\n\u003c/div\u003e\n\u003chr\u003e\n\u003ch2 id=\"-esperienza\"\u003e💼 Esperienza\u003c/h2\u003e\n\u003cdiv class=\"cv-timeline\"\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/ucl2.jpg\" alt=\"UCL\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eVisiting Researcher\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.ucl.ac.uk/\"\u003eUniversity College London (UCL)\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eSet 2025 – Dic 2025 · Londra, UK\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003eRicerca su AI coding agents, green AI e ottimizzazione multi-obiettivo. Co-sviluppo del framework GA4GC (135× miglioramento dell'hypervolume). Studio empirico su 7.156 pull request generate da AI.\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/nova.png\" alt=\"NOVA IMS\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eVisiting Researcher\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.novaims.unl.pt/\"\u003eNOVA IMS, Universidade NOVA de Lisboa\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eMag–Ago 2025 · Lisbona, Portogallo\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003ePeriodo di ricerca in cui ho sviluppato un AI Agent per task Text-to-SQL utilizzando solo piccoli modelli open-source, rendendo possibile l'interrogazione di database in linguaggio naturale senza API proprietarie.\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/units.jpg\" alt=\"UniTS\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eTeaching Assistant — Sistemi di Database\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.units.it/\"\u003eUniversità di Trieste\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eMar 2024 – Dic 2024 · Trieste, Italia\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003eGuida degli studenti nello sviluppo di sistemi database. Progettazione di esercitazioni su SQL, algebra relazionale, modellazione ER. Valutazione di tutti i progetti degli studenti.\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/nova.png\" alt=\"NOVA IMS\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eVisiting Researcher\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.novaims.unl.pt/\"\u003eNOVA IMS, Universidade NOVA de Lisboa\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eMag–Ago 2024 · Lisbona, Portogallo\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003ePeriodo di ricerca in cui ho creato una nuova metrica di valutazione per il Text-to-SQL (pubblicata su Scientific Reports / Nature).\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n    \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/plus.jpg\" alt=\"PLUS S.r.l.\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eApplied AI Scientist\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"#\"\u003ePLUS S.r.l., Area Science Park\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eGen 2023 – Dic 2025 · Trieste, Italia\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003eProgettazione e deploy di un sistema RAG in produzione (riduzione del volume del call center del 30%). Sviluppo di pipeline di Genetic Improvement per la correzione del codice generato dagli LLM. Proposta di nuove metriche di valutazione per il Text-to-SQL. Supervisione di 5 tesi.\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/units.jpg\" alt=\"UniTS\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eTutor Dipartimentale — Data Science \u0026amp; AI\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.units.it/\"\u003eUniversità di Trieste\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eGen 2024 – Dic 2024 · Trieste, Italia\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003eRistrutturazione dei siti web dipartimentali. Punto di riferimento per 200+ studenti per orientamento accademico.\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\n\u003ch2 id=\"-formazione\"\u003e🎓 Formazione\u003c/h2\u003e\n\u003cdiv class=\"cv-timeline\"\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/units.jpg\" alt=\"UniTS\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eDottorato di Ricerca in Data Science \u0026amp; Intelligenza Artificiale Applicata\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.units.it/\"\u003eUniversità di Trieste\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eGen 2023 – Dic 2025 · Trieste, Italia\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003eTesi: \"Application of Large Language Models: Addressing Real-World Challenges\". Dottorato industriale co-finanziato da PLUS S.r.l. (Area Science Park). Supervisori: Prof. Luca Manzoni, Prof. Andrea De Lorenzo. Visiting internazionali: UCL Londra, NOVA IMS Lisbona.\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/units.jpg\" alt=\"UniTS\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eLaurea Magistrale in Ingegneria Informatica\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.units.it/\"\u003eUniversità di Trieste\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eSet 2019 – Ott 2022 · Voto: 108/110\u003c/div\u003e\n      \u003cdiv class=\"cv-desc\"\u003eTesi: \"An Automatic Tool for the Recognition of Punches in Late-Medieval Panel Paintings\" (pubblicata su IEEE Access). Erasmus alla Montanuniversität Leoben, Austria.\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-entry\"\u003e\n    \u003cdiv class=\"cv-logo\"\u003e\u003cimg src=\"/images/orgs/units.jpg\" alt=\"UniTS\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-dot\"\u003e\u003c/div\u003e\n    \u003cdiv class=\"cv-card\"\u003e\n      \u003cdiv class=\"cv-title\"\u003eLaurea Triennale in Ingegneria Elettronica e Informatica\u003c/div\u003e\n      \u003cdiv class=\"cv-org\"\u003e\u003ca href=\"https://www.units.it/\"\u003eUniversità di Trieste\u003c/a\u003e\u003c/div\u003e\n      \u003cdiv class=\"cv-meta\"\u003eSet 2015 – Mar 2019 · Trieste, Italia\u003c/div\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\n\u003ch2 id=\"-competenze-tecniche\"\u003e🛠️ Competenze Tecniche\u003c/h2\u003e\n\u003cdiv class=\"cv-skills-grid\"\u003e\n  \u003cdiv class=\"cv-skill-col\"\u003e\n    \u003ch4\u003eLinguaggi di Programmazione\u003c/h4\u003e\n    \u003cdiv class=\"cv-skill-tags\"\u003e\n      \u003cspan\u003ePython (5+ anni)\u003c/span\u003e\u003cspan\u003eSQL\u003c/span\u003e\u003cspan\u003eJava\u003c/span\u003e\u003cspan\u003eC++\u003c/span\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-skill-col\"\u003e\n    \u003ch4\u003eFramework ML \u0026amp; NLP\u003c/h4\u003e\n    \u003cdiv class=\"cv-skill-tags\"\u003e\n      \u003cspan\u003ePyTorch\u003c/span\u003e\u003cspan\u003eHuggingFace\u003c/span\u003e\u003cspan\u003escikit-learn\u003c/span\u003e\u003cspan\u003espaCy\u003c/span\u003e\u003cspan\u003eNLTK\u003c/span\u003e\u003cspan\u003eBERTopic\u003c/span\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-skill-col\"\u003e\n    \u003ch4\u003eFramework LLM \u0026amp; Agenti\u003c/h4\u003e\n    \u003cdiv class=\"cv-skill-tags\"\u003e\n      \u003cspan\u003eLangChain\u003c/span\u003e\u003cspan\u003eLlamaIndex\u003c/span\u003e\u003cspan\u003eLangGraph\u003c/span\u003e\u003cspan\u003eRAG Pipelines\u003c/span\u003e\u003cspan\u003ePrompt Engineering\u003c/span\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-skill-col\"\u003e\n    \u003ch4\u003eStrumenti \u0026amp; Infrastruttura\u003c/h4\u003e\n    \u003cdiv class=\"cv-skill-tags\"\u003e\n      \u003cspan\u003eGit/GitHub\u003c/span\u003e\u003cspan\u003eDocker\u003c/span\u003e\u003cspan\u003eLinux\u003c/span\u003e\u003cspan\u003eLaTeX\u003c/span\u003e\u003cspan\u003eStreamlit\u003c/span\u003e\u003cspan\u003eGradio\u003c/span\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n\u003c/div\u003e\n\u003ch2 id=\"-lingue\"\u003e🌍 Lingue\u003c/h2\u003e\n\u003cdiv class=\"cv-languages\"\u003e\n  \u003cdiv class=\"cv-lang-item\"\u003e\n    \u003cspan class=\"cv-lang-name\"\u003eItaliano\u003c/span\u003e\n    \u003cspan class=\"cv-lang-level\"\u003eMadrelingua\u003c/span\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"cv-lang-item\"\u003e\n    \u003cspan class=\"cv-lang-name\"\u003eInglese\u003c/span\u003e\n    \u003cspan class=\"cv-lang-level\"\u003eC1 (Avanzato)\u003c/span\u003e\n  \u003c/div\u003e\n\u003c/div\u003e","title":"Curriculum Vitae"},{"content":"Articoli su Rivista Pinna, G., Perezhohin, Y., Manzoni, L., Castelli, M., De Lorenzo, A. (2025). \u0026ldquo;Redefining Text-to-SQL Metrics by Incorporating Semantic and Structural Similarity.\u0026rdquo; Scientific Reports 15.1. (Nature) DOI\nPinna, G., Ravalico, D., Rovito, L., Manzoni, L., De Lorenzo, A. (2025). \u0026ldquo;Exploring the Effect of Genetic Improvement for Large Language Models-Generated Code.\u0026rdquo; SN Computer Science 6.7. Paper\nZullich, M., Macovaz, V., Pinna, G., Pellegrino, F.A. (2023). \u0026ldquo;An Artificial Intelligence System for Automatic Recognition of Punches in Fourteenth-Century Panel Painting.\u0026rdquo; IEEE Access. DOI\nArticoli a Conferenza Pinna, G., Gong, J., Williams, D., Sarro, F. (2026). \u0026ldquo;Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance.\u0026rdquo; arXiv:2602.08915. arXiv\nGong, J., Pinna, G. (2026). \u0026ldquo;Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests.\u0026rdquo; arXiv:2601.04886. 🏆 Distinguished Mining Challenge Paper Award, MSR 2026 arXiv\nPinna, G., Ravalico, D., Rovito, L., Manzoni, L., De Lorenzo, A. (2024). \u0026ldquo;Enhancing Large Language Models-Based Code Generation by Leveraging Genetic Improvement.\u0026rdquo; EuroGP 2024. Lecture Notes in Computer Science, vol. 14631. Springer, Cham. DOI\nPinna, G., Tugnoli, D., Manzoni, L., De Lorenzo, A. (2024). \u0026ldquo;From Courts to Comprehension: Can LLMs Make Judgments More Accessible?\u0026rdquo; IEEE/WIC WI-IAT 2024. Paper\nGong, J., Bian, Y., de la Cal, L., Pinna, G., et al. (2025). \u0026ldquo;GA4GC: Greener Agent for Greener Code via Multi-Objective Configuration Optimization.\u0026rdquo; SSBSE 2025. Paper\nde la Cal, L., Cao, Y., Ercevik, A.I., Pinna, G., et al. (2025). \u0026ldquo;HotCat: Green and Effective Feature Selection toward Hotfix Bug Taxonomy.\u0026rdquo; SSBSE 2025. Paper\nWorkshop Paper Pinna, G., Ravalico, D., Rovito, L., Manzoni, L., De Lorenzo, A. (2025). \u0026ldquo;Improving LLM-Generated Code via Genetic Improvement: A Summary of Recent Advances.\u0026rdquo; CEUR Workshop Proceedings. Ital-IA 2025. ","permalink":"https://giovannipinna.net/it/publications/","summary":"\u003ch2 id=\"articoli-su-rivista\"\u003eArticoli su Rivista\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePinna, G.\u003c/strong\u003e, Perezhohin, Y., Manzoni, L., Castelli, M., De Lorenzo, A. (2025). \u0026ldquo;Redefining Text-to-SQL Metrics by Incorporating Semantic and Structural Similarity.\u0026rdquo; \u003cem\u003eScientific Reports\u003c/em\u003e 15.1. (Nature) \u003ca href=\"https://doi.org/10.1038/s41598-025-85645-0\"\u003eDOI\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePinna, G.\u003c/strong\u003e, Ravalico, D., Rovito, L., Manzoni, L., De Lorenzo, A. (2025). \u0026ldquo;Exploring the Effect of Genetic Improvement for Large Language Models-Generated Code.\u0026rdquo; \u003cem\u003eSN Computer Science\u003c/em\u003e 6.7. \u003ca href=\"https://link.springer.com/content/pdf/10.1007/s42979-025-04281-x.pdf\"\u003ePaper\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eZullich, M., Macovaz, V., \u003cstrong\u003ePinna, G.\u003c/strong\u003e, Pellegrino, F.A. (2023). \u0026ldquo;An Artificial Intelligence System for Automatic Recognition of Punches in Fourteenth-Century Panel Painting.\u0026rdquo; \u003cem\u003eIEEE Access\u003c/em\u003e. \u003ca href=\"https://doi.org/10.1109/ACCESS.2023.3276538\"\u003eDOI\u003c/a\u003e\u003c/p\u003e","title":"Pubblicazioni"}]