🤖 AI

LLMs for Qualitative Data Analysis Fail on Security-specificComments in Human Experiments

Lo studio dimostra che, nonostante l'uso di prompt dettagliati, i modelli linguistici di grandi dimensioni non sono attualmente affidabili come sostituti degli annotatori umani nell'analisi qualitativa di commenti tecnici specifici sulla sicurezza.

Autori originali: Maria Camporese, Fabio Massacci, Yuanjun Gong

Pubblicato 2026-04-14

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Maria Camporese, Fabio Massacci, Yuanjun Gong

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 di essere un detective privato che deve analizzare centinaia di diari scritti da studenti universitari. Questi studenti hanno guardato dei pezzi di codice informatico (come se fossero trappole per topi) e hanno scritto delle note per spiegare perché pensavano che ci fosse un pericolo o meno.

Il tuo compito è leggere tutte queste note e classificarle in categorie specifiche, come:

"Ha menzionato il nome di una variabile?"
"Ha parlato di una linea specifica del codice?"
"Ha usato parole chiave di sicurezza?"
"Ha detto che non ha trovato nessun pericolo?"

Fare questo lavoro manualmente è estenuante. Ci vogliono ore, e per essere sicuri di non sbagliare, devi avere almeno due detective esperti che leggono le stesse note e concordano tra loro. È costoso e lento.

L'Idea Geniale (e il Problema)

Gli autori di questo studio si sono chiesti: "Perché non usiamo un'intelligenza artificiale super avanzata (un LLM) per fare il lavoro sporco? È come avere un assistente robotico che legge tutto in un attimo!"

Hanno preso quattro dei migliori "cervelli" artificiali del momento (come GPT-5, Claude, DeepSeek e Qwen) e li hanno messi alla prova. L'obiettivo era vedere se questi robot potevano sostituire i detective umani.

L'Esperimento: Il Robot al posto dell'Uomo

Per vedere se il robot era bravo, gli hanno dato gli stessi compiti che facevano gli umani, ma con un aiuto progressivo, come se gli stessi insegnando a fare il lavoro:

Livello 1 (Il principiante): Hanno detto al robot: "Ehi, leggi queste note e cerca queste parole". Senza spiegazioni.
Livello 2 (Il manuale): Hanno dato al robot un "manuale di istruzioni" dettagliato con esempi di cosa cercare.
Livello 3 (L'allenatore): Hanno detto: "Guarda qui, due studenti hanno scritto cose simili ma uno ha detto 'sì' e l'altro 'no'. Spiegami la differenza". Hanno usato esempi confusi per addestrarlo meglio.

Il Risultato: Il Robot si è Perso

Purtroppo, la storia ha un finale inaspettato. Il robot non è riuscito a sostituire l'umano.

Ecco perché, usando delle metafore:

Il Robot è un "lettore letterale": Se uno studente scrive "Il buffer è pieno", il robot pensa: "Ah, ha menzionato la parola 'buffer', quindi è un codice di sicurezza!". Ma un umano sa che in quel contesto la parola potrebbe essere usata in modo generico o sbagliato. Il robot prende le parole alla lettera, come un bambino che legge un libro di cucina e pensa che se c'è scritto "cuocere il tempo", si debba mettere il tempo in forno.
Il contesto è la chiave: I commenti degli studenti sono pieni di dubbi ("Forse...", "Non sono sicuro...", "Sembra che..."). I robot spesso non capiscono queste sfumature. A volte pensano che un dubbio sia una conferma, altre volte ignorano un pericolo reale perché la frase era troppo vaga.
Più istruzioni non aiutano: Hanno provato a dare al robot manuali sempre più lunghi e esempi sempre più complessi. È come se aveste dato a un bambino un dizionario di 1000 pagine per insegnargli a guidare un'auto. Alla fine, il robot si confondeva ancora di più. Non ha migliorato abbastanza da essere affidabile.

La Verità Scomoda

Lo studio conclude che, per ora, non possiamo fidarci ciecamente dell'IA per analizzare commenti tecnici di sicurezza.

Se usassimo il robot al posto degli umani, commetterebbe troppi errori. Sarebbe come affidare la sicurezza di un edificio a un robot che guarda le finestre e dice "Tutto ok" solo perché non vede muri crollati, ignorando che le fondamenta sono marce.

Cosa significa per noi?

Non significa che l'IA è inutile. Significa che, in questo campo specifico (l'analisi di commenti tecnici complessi), l'IA può essere un assistente, non un sostituto.

Cosa può fare l'IA: Può fare una prima bozza, evidenziare le frasi più ovvie o cercare parole chiave semplici.
Cosa deve fare l'umano: Deve leggere, capire il contesto, sentire il "tono" della persona e prendere la decisione finale.

In sintesi: L'intelligenza artificiale è un ottimo apprendista, ma per ora non è ancora un maestro. Se vuoi analizzare la sicurezza informatica in modo serio, devi ancora tenere la penna in mano (o almeno, tenere l'occhio vigile sul lavoro del robot).

1. Contesto e Problema

L'analisi tematica (Thematic Analysis - TA) dei commenti testuali liberi generati da partecipanti in esperimenti di ingegneria del software è fondamentale per ottenere approfondimenti qualitativi. Tuttavia, questo processo è estremamente costoso e laborioso, richiedendo l'annotazione manuale da parte di più esperti di dominio per garantire affidabilità.
Con l'avvento dei Large Language Models (LLM), sorge la domanda se questi modelli possano sostituire gli annotatori umani, specialmente in compiti di sentiment analysis o estrazione di opinioni.
Il problema specifico affrontato da questo studio è la capacità degli LLM di gestire annotazioni tecniche di sicurezza, che richiedono una comprensione contestuale profonda (es. identificare se un commento menziona un identificatore di codice, una riga specifica, una keyword di sicurezza o un potenziale exploit). A differenza del sentiment analysis, questi task richiedono un ragionamento semantico fine e una conoscenza del dominio che potrebbe superare le capacità attuali degli LLM.

2. Metodologia

Gli autori hanno progettato un esperimento controllato per valutare se gli LLM possano sostituire gli annotatori umani in un contesto di sicurezza.

Dataset: È stato utilizzato un dataset non pubblicato proveniente da uno studio precedente (Papotti et al.), contenente 263 commenti testuali generati da studenti di informatica durante l'analisi di frammenti di codice vulnerabili.
Codici di Sicurezza: Sono stati definiti 9 codici rilevanti per la sicurezza (es. Var: identificatori menzionati, Lin: righe menzionate, Key: keyword di sicurezza, Vul: tipo di vulnerabilità, Exp: potenziale exploit, ecc.).
Protocollo di Annotazione: Il processo umano è stato simulato in fasi progressive:
1. Emergere dei codici (brainstorming).
2. Creazione di un codice (codebook) con definizioni formali.
3. Annotazione iniziale e revisione incrociata.
4. Risoluzione dei conflitti e creazione di esempi di "fai e non fare".
Sperimentazione con LLM: Sono stati selezionati 4 modelli LLM all'avanguardia (due proprietari: GPT-5, Claude-4; due open-source: DeepSeek-V3.2, Qwen3-Max) basati sui punteggi di LiveBench.
Strategia di Prompting (RQ2): Per rispondere alla seconda domanda di ricerca, sono stati testati diversi prompt che mimavano l'evoluzione del processo umano:
- P1: Descrizione del task e nomi dei codici.
- P2: Aggiunta di definizioni formali e un codicebook dettagliato.
- P3: Inclusione di esempi di annotazioni di altri annotatori.
- P3+: Inclusione di esempi conflittuali e relative chiarificazioni dagli esperti umani.
Metriche di Valutazione: Oltre alla precisione e al richiamo, è stata utilizzata la Coerenza di Cohen (Cohen's Kappa, $\kappa$ ) e l'Accuratezza Corretta per Caso (Chance-Corrected Accuracy). Queste metriche sono cruciali perché i dati sono sbilanciati (molti commenti non contengono certi codici); un'alta accuratezza grezza potrebbe essere ottenuta semplicemente ignorando i casi rari.

3. Risultati Chiave

I risultati sono prevalentemente negativi riguardo alla sostituzione completa degli umani:

Incapacità di Sostituzione (RQ1): Nessun LLM testato ha raggiunto un livello di accordo sufficiente per sostituire un annotatore umano in modo affidabile.
- I modelli proprietari (GPT-5, Claude-4) hanno ottenuto un $\kappa$ molto basso (tra 0.25 e 0.30), classificati come "Limitati" o "Inutilizzabili".
- I modelli open-source (DeepSeek-V3.2, Qwen3-Max) hanno mostrato prestazioni leggermente migliori, con Qwen3-Max che ha raggiunto un $\kappa$ di 0.61 (sostanziale) in media, ma con grandi variazioni tra i diversi codici.
- Prestazioni Disomogenee: Gli LLM sono stati bravi a rilevare codici semplici e letterali (es. menzione di identificatori di variabili Var o righe Lin), ma hanno fallito miseramente su codici che richiedono interpretazione contestuale (es. Unclr: risposta poco chiara, Exp: exploit potenziale).
Impatto del Prompting (RQ2): Il raffinamento dei prompt ha portato a miglioramenti marginali e non statisticamente significativi dopo la fase iniziale.
- L'aggiunta di definizioni formali (da P1 a P2) ha migliorato leggermente le prestazioni.
- L'aggiunta di esempi complessi e casi conflittuali (P3 e P3+) non ha portato a guadagni sostanziali e, in alcuni casi, ha confuso i modelli, peggiorando le prestazioni.
- Non è stato trovato un guadagno significativo aumentando il "costo" in token dei prompt.

4. Contributi Principali

Valutazione Critica: Fornisce una delle prime valutazioni empiriche rigorose sull'uso degli LLM per l'analisi tematica di dati qualitativi in ambito di sicurezza informatica, un dominio ad alta complessità semantica.
Metodologia di Confronto: Introduce un protocollo sperimentale che simula fedelmente il processo iterativo di annotazione umana (dall'emersione dei codici alla risoluzione dei conflitti) per testare gli LLM in condizioni realistiche.
Risultati Negativi Significativi: Dimostra che, contrariamente alla speranza di automazione totale, gli LLM attuali non sono pronti a sostituire gli esperti umani per annotazioni tecniche di sicurezza, nemmeno con prompting avanzato.
Analisi dei Fallimenti: Identifica che gli errori principali derivano dalla difficoltà degli LLM nel distinguere tra terminologia tecnica generica e riferimenti specifici al codice, e nella gestione dell'incertezza e delle sfumature semantiche.

5. Significato e Implicazioni

Ruolo Assistivo, Non Autonomo: Il paper conclude che gli LLM non dovrebbero essere utilizzati come sostituti autonomi degli annotatori umani per compiti di sicurezza complessi. Il loro ruolo attuale dovrebbe essere assistivo: ad esempio, per generare una prima bozza di annotazione o per filtrare casi ovvi, lasciando la verifica e la risoluzione dei conflitti agli esperti umani.
Limiti del Prompting: Suggerisce che il solo ingegneria dei prompt (senza fine-tuning o adattamenti architetturali) ha rendimenti decrescenti per compiti che richiedono un ragionamento di dominio profondo e contestuale.
Impatto sulla Ricerca: Mette in guardia i ricercatori che intendono automatizzare l'analisi di dati qualitativi in esperimenti di sicurezza, sottolineando che l'uso di metriche non corrette per il caso (come la semplice accuratezza) può portare a conclusioni fuorvianti sull'efficacia degli LLM.

In sintesi, lo studio evidenzia un "gap semantico" tra la comprensione superficiale degli LLM e il ragionamento di sicurezza necessario per l'analisi qualitativa tecnica, suggerendo che l'automazione completa in questo settore non è ancora una realtà.