💻 computer science

Guidelines for Empirical Studies in Software Engineering involving Large Language Models

Questo lavoro presenta una tassonomia di sette tipi di studi e otto linee guida obbligatorie o raccomandate, sviluppate da 22 ricercatori, per migliorare la riproducibilità e la trasparenza delle ricerche empiriche in ingegneria del software che coinvolgono i modelli linguistici di grandi dimensioni (LLM).

Autori originali: Sebastian Baltes, Florian Angermeir, Chetan Arora, Marvin Muñoz Barón, Chunyang Chen, Lukas Böhme, Fabio Calefato, Neil Ernst, Davide Falessi, Brian Fitzgerald, Davide Fucci, Junda He, Christoph Treud

Pubblicato 2026-03-04

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Sebastian Baltes, Florian Angermeir, Chetan Arora, Marvin Muñoz Barón, Chunyang Chen, Lukas Böhme, Fabio Calefato, Neil Ernst, Davide Falessi, Brian Fitzgerald, Davide Fucci, Junda He, Christoph Treude, Marcos Kalinowski, Stefano Lambiase, Daniel Russo, Mircea Lungu, Cristina Martinez Montes, Lutz Prechelt, Paul Ralph, Rijnard van Tonder, Stefan Wagner

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina che il mondo della ricerca sul software sia come un grande laboratorio di cucina, dove gli scienziati (i ricercatori) stanno cercando di creare nuove ricette (software) o di capire come cucinano gli altri. Fino a poco tempo fa, usavano solo ingredienti classici e manuali. Ma ora, hanno scoperto un nuovo tipo di "assistente culinario" super intelligente: i Modelli Linguistici di Grande Dimensione (LLM), come ChatGPT o Claude.

Questi assistenti sono magici: scrivono codice, correggono errori e analizzano testi in un batter d'occhio. Ma c'è un problema: sono un po' imprevedibili. Se chiedi la stessa ricetta due volte, potrebbero darti due piatti leggermente diversi. Inoltre, nessuno sa esattamente cosa hanno mangiato per diventare così bravi (i loro dati di addestramento sono segreti) e cambiano continuamente, come se la loro ricetta segreta venisse aggiornata ogni giorno.

Questo crea un caos per la scienza: se un ricercatore dice "Ho fatto questa scoperta usando l'assistente A", un altro scienziato non può ripetere l'esperimento perché l'assistente A potrebbe essere cambiato o perché non sa esattamente come è stato usato.

Per risolvere questo problema, 22 esperti (come un consiglio di chef stellati) hanno scritto una guida pratica per tutti coloro che usano questi assistenti nella ricerca. Ecco i punti chiave, spiegati con metafore semplici:

1. La "Carta d'Identità" dell'Assistente (Dichiara chi e come)

Non puoi dire "Ho usato un robot" senza dire quale robot. Devi scrivere chiaramente: "Ho usato il modello X, versione Y, per fare Z".

Metafora: È come dire in una ricetta: "Ho usato un mixer KitchenAid modello 2024, non un frullatore a mano". Se non lo dici, nessuno può ricreare il tuo piatto.

2. La "Fotografia" del Momento (Versioni e Configurazioni)

I modelli cambiano spesso. Devi dire esattamente quale "fotografia" del modello hai usato e quali impostazioni avevi (es. "quanto creativo" doveva essere).

Metafora: Se un assistente cambia idea su cosa è "creativo" da un mese all'altro, devi specificare: "L'ho impostato al 70% di creatività il 10 gennaio". Senza questo, il tuo esperimento è come una foto sfocata.

3. Non solo il Motore, ma l'Auto Intera (Architettura)

Spesso l'assistente non lavora da solo, ma è parte di un sistema più grande (come un'auto con GPS, sensori e volante). Devi spiegare come funziona tutto il sistema, non solo il motore.

Metafora: Non basta dire "Ho usato un'auto Tesla". Devi spiegare se avevi anche il pilota automatico attivo, quale mappa usavi e come gestivi il traffico.

4. La "Lista della Spesa" delle Domande (Prompt e Log)

Le domande che fai all'assistente (i "prompt") sono fondamentali. Una domanda fatta male dà una risposta sbagliata. Devi mostrare esattamente cosa hai scritto.

Metafora: È come mostrare la lista della spesa esatta e le istruzioni precise date allo chef. Se cambi una parola nella domanda ("Fammi un dolce" vs "Fammi una torta al cioccolato"), il risultato cambia. Devi registrare anche le conversazioni complete.

5. Il "Controllo Umano" (Validazione)

L'assistente può sbagliare o allucinare cose. Non puoi fidarti ciecamente di tutto ciò che dice. Devi far controllare il lavoro da un umano esperto.

Metafora: Anche se hai un assistente che cucina velocissimo, alla fine devi assaggiare il piatto tu stesso prima di servirlo agli ospiti. Non puoi dire "Il robot ha detto che è buono, quindi lo è".

6. La "Copia di Sicurezza" Aperta (Baseline Open Source)

Se usi un assistente a pagamento (chiuso e segreto), dovresti anche provare a usare un assistente gratuito e aperto (di cui tutti possono vedere il codice) per vedere se i risultati sono simili.

Metafora: Se dici che il tuo nuovo motore funziona meglio, dovresti anche testarlo su un motore vecchio e noto per fare un confronto equo. Se usi solo motori segreti, nessuno può verificare se hai ragione.

7. Le "Regole del Gioco" (Metriche e Confronti)

Quando misuri i risultati, devi usare regole chiare e condivise da tutti, non inventare le tue.

Metafora: Non puoi dire "Ho vinto perché ho corso veloce". Devi dire "Ho vinto perché ho fatto 100 metri in 10 secondi, misurato con il cronometro ufficiale". Se usi il tuo cronometro personale, nessuno ti crede.

8. Ammettere i "Difetti" (Limiti e Rischi)

Nessuno è perfetto. Devi dire apertamente dove il tuo esperimento potrebbe fallire o dove i risultati potrebbero non valere per tutti.

Metafora: È come dire: "Questa ricetta funziona benissimo d'estate, ma d'inverno l'umidità potrebbe rovinare la torta". Essere onesti sui limiti rende la scienza più credibile.

In sintesi

Questa guida è come un manuale di istruzioni per non perdere la testa in un mondo di intelligenza artificiale che cambia velocemente. Dice ai ricercatori: "Siate trasparenti, documentate tutto, fate controllare il lavoro e ammettete i vostri errori". Solo così potremo fidarci delle scoperte fatte con l'aiuto di queste nuove macchine intelligenti e potremo costruire il futuro del software su basi solide, non su sabbia mobile.

La guida è disponibile online e viene aggiornata continuamente, proprio come i software stessi, per essere sempre al passo con i tempi.

1. Il Problema

L'integrazione dei Modelli Linguistici su Grande Scala (LLM) nella ricerca e nella pratica dell'Ingegneria del Software (SE) è diventata ubiqua. Tuttavia, le caratteristiche intrinseche degli LLM minacciano la riproducibilità e la replicabilità degli studi empirici. I principali ostacoli identificati sono:

Non-determinismo: Piccole variazioni nei prompt o nei parametri (es. temperatura) possono generare output significativamente diversi, rendendo difficile la ripetizione esatta degli esperimenti.
Opacità dei dati di addestramento: Molti modelli commerciali hanno dati di training non divulgati, impedendo la valutazione completa dei bias.
Evoluzione rapida: I modelli commerciali cambiano senza identificatori di versione stabili, rendendo i risultati di performance obsoleti nel tempo.
Sensibilità al Prompting: La formattazione e la struttura del prompt possono alterare l'accuratezza di decine di punti percentuali.
Mancanza di linee guida specifiche: Le normative esistenti per studi empirici in SE (es. standard ACM SIGSOFT) non affrontano le sfide specifiche legate agli LLM.

2. Metodologia

Il lavoro è il risultato di uno sforzo collaborativo di 22 ricercatori del settore, sviluppato seguendo un processo strutturato simile a quello utilizzato per linee guida in altri campi (es. CONSORT per la medicina):

Iniziazione: Il progetto è nato durante la riunione ISERN 2024 e ha coinvolto sessioni di discussione e un documento di posizione preliminare.
Sviluppo Iterativo: Sono state tenute riunioni quindicinali per definire la tassonomia degli studi e le linee guida. Ogni sezione è stata assegnata a coppie di co-autori per la stesura e il raffinamento.
Revisione tra Pari: Il processo ha incluso revisioni interne multiple, selezione di esempi illustrativi da database accademici e una revisione esterna da parte di esperti di SE empirico.
Validazione: Le linee guida sono state auto-valutate rispetto ai criteri di qualità degli "SIGSOFT Empirical Standards".
Risorse Viventi: Le linee guida sono mantenute come risorsa dinamica online (llm-guidelines.org) per permettere aggiornamenti futuri.

3. Contributi Chiave

Il documento offre tre contributi principali: una tassonomia degli studi, otto linee guida operative e strumenti di supporto.

A. Tassonomia dei Tipi di Studio (7 Categorie)

Gli autori classificano il coinvolgimento degli LLM nella ricerca SE in due macro-aree e sette tipi specifici:

LLM come strumenti per i ricercatori:
- S1 Annotatori: Automazione della codifica di dati qualitativi.
- S2 Giudici: Valutazione della qualità di artefatti software (es. leggibilità del codice).
- S3 Sintesi: Integrazione di informazioni da più fonti per generare insight o dati sintetici.
- S4 Soggetti: Simulazione di comportamenti umani in esperimenti controllati.
LLM come strumenti per gli ingegneri del software:
- S5 Studio dell'uso: Analisi di come gli sviluppatori utilizzano gli LLM nella pratica.
- S6 Nuovi Strumenti: Sviluppo di nuovi tool SE basati su LLM (es. agenti autonomi).
- S7 Benchmarking: Valutazione delle prestazioni degli LLM su task standardizzati.

B. Le Otto Linee Guida (G1-G8)

Ogni linea guida distingue tra requisiti obbligatori (Must) e pratiche raccomandate (Should), ed è mappata sui tipi di studio sopra descritti:

Dichiarare l'uso e il ruolo dell'LLM (G1): Obbligo di trasparenza su quale modello è stato usato, per quale scopo e in quale fase della ricerca.
Riportare versione, configurazione e personalizzazioni (G2): Documentazione dettagliata di versione del modello, parametri (es. temperatura, seed), data dell'esperimento e dettagli sul fine-tuning (dataset, procedure).
Riportare l'architettura dello strumento oltre il modello (G3): Descrizione completa dell'architettura software, inclusi agenti, flussi di dati, retrieval (RAG) e interazioni con componenti esterni.
Riportare prompt, sviluppo e log di interazione (G4): Pubblicazione di tutti i prompt (o template), strategie di sviluppo e, se possibile, log completi delle interazioni per garantire la verificabilità.
Utilizzare la validazione umana per gli output degli LLM (G5): Quando non esistono dataset di riferimento, gli output devono essere validati da umani, con misurazione dell'accordo inter-rater (es. Krippendorff's $\alpha$ ).
Includere un LLM open come baseline (G6): Per garantire la replicabilità, è necessario confrontare i modelli commerciali con modelli open-source (open-weights) e fornire pacchetti di replicazione.
Utilizzare baseline, benchmark e metriche appropriate (G7): Giustificazione delle metriche scelte, discussione della validità costruttiva, ripetizione degli esperimenti per gestire il non-determinismo e uso di statistiche inferenziali.
Riportare limitazioni e mitigazioni (G8): Trasparenza su rischi di validità (interna, esterna, costruttiva), bias, costi energetici e strategie di mitigazione (es. triangolazione, analisi di sensibilità).

C. Strumenti di Supporto

Matrice di Applicabilità: Una tabella che mappa quali linee guida sono obbligatorie o raccomandate per ciascun tipo di studio.
Checklist di Reporting: Una lista di controllo pratica per autori e revisori, organizzata per sezioni tipiche di un paper (Introduzione, Metodi, Risultati, Limitazioni).

4. Risultati e Implicazioni

Il documento non presenta risultati sperimentali diretti, ma fornisce un framework normativo per la comunità.

Standardizzazione: Offre un linguaggio comune per descrivere l'uso degli LLM, riducendo l'ambiguità nelle pubblicazioni.
Miglioramento della Riproducibilità: Attraverso la richiesta di dettagli su configurazioni, prompt e log, permette ad altri ricercatori di tentare la replicazione anche in assenza di determinismo perfetto.
Gestione dei Bias: Sottolinea l'importanza della validazione umana e dell'uso di baseline open per mitigare i bias intrinseci dei modelli proprietari.
Adattabilità: La distinzione tra requisiti "Must" e "Should" permette flessibilità in contesti con vincoli di risorse o privacy, pur mantenendo alti standard di rigore.

5. Significato

Questo lavoro è fondamentale per l'evoluzione dell'Ingegneria del Software empirica nell'era dell'IA.

Affidabilità Scientifica: Trasforma gli studi sugli LLM da "esperimenti una tantum" a ricerche verificabili e cumulabili, affrontando la crisi di riproducibilità.
Etica e Trasparenza: Promuove pratiche etiche riguardo alla privacy dei dati, al consumo energetico e alla gestione dei bias.
Guida per la Comunità: Fornisce ai ricercatori un percorso chiaro per progettare studi robusti e ai revisori criteri oggettivi per valutare la qualità metodologica dei manoscritti.
Risorsa Dinamica: La natura "vivente" delle linee guida (aggiornabili online) riconosce la rapida evoluzione tecnologica degli LLM, assicurando che le raccomandazioni rimangano pertinenti nel tempo.

In sintesi, il documento stabilisce le fondamenta per una ricerca SE sugli LLM che sia scientificamente rigorosa, eticamente responsabile e tecnicamente riproducibile.