I modelli generativi replicano stereotipi: serve misurazione ripetuta

Chiedi a un modello di descrivere un muratore: nella maggior parte dei casi risponde “uomo”¹. Non glielo hai chiesto. Sta completando un pattern.

Questo è stereotypical bias: il modello riproduce assunzioni presenti nei dati di addestramento su gruppi di persone invece di ragionare sul caso specifico¹. Il risultato può essere un semplice default o un’uscita che tocca caratteristiche protette. Non è una scelta consapevole. È statistica che affiora in output.

Conta perché la macchina non “pensa” alle persone coinvolte. Così l’output porta assunzioni che nessuno ha selezionato o rivisto¹. In un prodotto distribuito, questo può danneggiare chi riceve la risposta. E apre un problema reputazionale per l’organizzazione. Si manifesta nell’uso ordinario, non solo sotto attacco¹.

Cambi solo un nome che suggerisce provenienza, e il tono o l’aiuto cambia. Compare un riferimento a religione o sessualità che il prompt non supportava. Il muratore “uomo” torna quasi sempre¹. Il modello completa un pattern statistico, non la domanda precisa.

Testare richiede un metodo. Serve una famiglia di prompt che miri alle predefinizioni. Si varia un solo attributo per volta, tutto il resto resta identico¹. Poi si ripete. Molte esecuzioni. Il singolo run dice poco. L’output è probabilistico, quindi conta la frequenza, non l’istanza¹. La domanda da farsi non è “è successo?” ma “quanto spesso succede?”.

Quante volte bisogna ripetere? Abbastanza da vedere un pattern, non un caso¹. Le conclusioni arrivano dalla frequenza su molti tentativi, non da una singola risposta¹. Il confronto tra uscite che differiscono solo per la caratteristica in esame permette di osservare l’eventuale divergenza di comportamento¹.

Testare una volta e dichiarare il modello “pulito” ignora la natura probabilistica del sistema¹. Anche trattare i default lievi come innocui è un errore, senza verificare se versioni più gravi seguono lo stesso schema¹. Un “muratore = uomo”, se non controllato su molte esecuzioni e varianti, può nascondere pattern più ampi dello stesso bias¹.

Le mitigazioni esistono, ma hanno compiti diversi. I guardrail di output e i modelli di moderazione intercettano i casi più seri¹. I risultati dei test vanno inseriti in set di valutazione, così le correzioni si possono verificare nel tempo¹.

Operativamente, questo porta a passaggi chiari: si progettano prompt di controllo, si isola una sola caratteristica alla volta, si eseguono molte run e si confrontano le risposte¹. Le scoperte alimentano set di valutazione che permettono di ricontrollare i fix nelle verifiche successive¹. Frequenza e ripetizione restano la misura, non l’esempio singolo¹.