Robustezza: definizione, valutazione e limiti nei sistemi di apprendimento automatico

Definizione e concetti da non confondere

Nel linguaggio comune, la robustezza richiama la durata o l’affidabilità generale di un oggetto: per esempio, una lavatrice che funziona per anni senza problemi. Nel campo della scienza dei dati e dell’apprendimento automatico, però, questa definizione è troppo vaga per individuare e affrontare i problemi in modo sistematico. Per farlo, occorre descrivere la robustezza attraverso quattro elementi: obiettivo, modificatore, dominio del modificatore e tolleranza dell’obiettivo.

L’obiettivo di robustezza è ciò che deve rimanere stabile, per esempio le prestazioni di un modello. Il modificatore è la variabile soggetta a cambiamento, come le immagini in ingresso o le caratteristiche dei dati. Il dominio del modificatore definisce quali variazioni siano rilevanti: possono essere, ad esempio, cambiamenti nell’illuminazione o nella distribuzione delle etichette. La tolleranza dell’obiettivo stabilisce infine quanto le prestazioni possano peggiorare prima che il cambiamento sia considerato inaccettabile. Un sistema è robusto rispetto a un modificatore quando gli interventi rilevanti, entro il dominio specificato, non causano variazioni superiori alla tolleranza stabilita.

Questa definizione evita di parlare di robustezza come se fosse una qualità universale. La domanda utile non è «il modello è robusto?», ma «quale suo comportamento deve restare stabile, rispetto a quali cambiamenti e con quale margine accettabile?». Anche la generalizzazione è collegata, ma non è sinonimo: un modello può funzionare bene su dati nuovi estratti dalla stessa distribuzione e perdere prestazioni quando cambiano le condizioni di raccolta, il contesto o la relazione tra input e risultato.

Le perturbazioni avversarie sono un caso particolare: un input viene modificato appositamente per indurre una previsione errata. Non coincidono con ogni tipo di variazione dei dati. Una differenza naturale, come il passaggio dalla stagione secca a quella delle piogge, può compromettere le prestazioni senza che ci sia un attacco. Per questo la valutazione deve partire dalle variazioni plausibili nell’applicazione, non da una nozione astratta di robustezza.

Come funziona: dalla definizione alla verifica

La robustezza non si presume: si verifica rispetto a uno scenario specifico. Per prima cosa si definiscono il comportamento da mantenere e la tolleranza accettabile. Poi si individuano i cambiamenti che potrebbero verificarsi nell’ambiente di utilizzo. Infine si misura come questi cambiamenti incidono sulle prestazioni e sugli errori, confrontando i risultati con un riferimento adeguato.

I cambiamenti nella distribuzione dei dati possono essere naturali, performativi o avversari. I cambiamenti naturali derivano dalle condizioni del mondo reale, come la stagionalità, l’illuminazione o l’uso di nuovi sensori. Quelli performativi sono conseguenze del modello e del suo impiego: per esempio, una previsione può indurre le persone a modificare il proprio comportamento e alterare così i dati futuri. I cambiamenti avversari sono invece causati da soggetti che manipolano intenzionalmente gli input. La rilevanza di ciascun tipo dipende dall’applicazione.

La verifica è a posteriori quando il cambiamento si è già verificato e sono disponibili nuovi dati: si confronta il comportamento del modello prima e dopo il cambiamento. È preventiva quando il cambiamento è atteso, ma non è ancora osservabile. In questo secondo caso si può descrivere lo scenario con conoscenze del dominio e, se serve una stima quantitativa, generare dati sintetici che lo rappresentino. Le conclusioni ottenute con dati sintetici dipendono però dalle ipotesi usate per generarli: non equivalgono a osservazioni raccolte dopo il cambiamento reale.

La valutazione non dovrebbe limitarsi a confrontare un’unica misura complessiva. Conviene esaminare i tipi di errore, per esempio falsi positivi e falsi negativi, e confrontarli tra classi o gruppi rilevanti. Quando possibile, si possono anche analizzare le caratteristiche a cui il modello dà importanza: se un classificatore di animali sembra basarsi sullo sfondo invece che sugli animali, potrebbe essere vulnerabile ai cambiamenti della vegetazione o della scena.

Tre esempi in ambiti diversi

**Ecologia e fototrappole.** Un modello addestrato a riconoscere animali nelle immagini raccolte durante la stagione secca potrebbe comportarsi diversamente nella stagione delle piogge. La vegetazione, la luce e la frequenza con cui compaiono le specie possono cambiare. In questo caso il test riguarda variazioni naturali: occorre controllare se le prestazioni si mantengono nelle condizioni previste e se il modello si basa su caratteristiche effettivamente pertinenti. Un’immagine alterata artificialmente per confondere il classificatore sarebbe invece un test avversario, distinto dal cambiamento stagionale.

**Classificazione di disturbi della qualità dell’energia elettrica.** Un modello può ottenere ottime prestazioni sui dati dello stesso dominio usati per valutarlo e risultare più sensibile al rumore o al trasferimento verso un altro dominio. In uno studio originale, gli autori hanno confrontato modelli di apprendimento automatico e profondo su tre domini di dati e hanno valutato anche il rumore bianco gaussiano additivo. Nel loro esperimento, i modelli profondi hanno superato 0,98 di Macro-F1 in-domain in alcuni contesti con dati sufficienti, ma sono risultati sensibili alla quantità di dati e al rumore. La macchina a vettori di supporto ha ottenuto il Macro-F1 medio cross-domain più alto tra i modelli confrontati. Sono risultati riferiti a quei dati, a quelle configurazioni e a quelle metriche: non dimostrano che le SVM siano sempre più robuste dei modelli profondi.

**Classificazione di immagini e attacchi avversari.** Una piccola modifica progettata dell’input può indurre un classificatore a sbagliare anche se la differenza è difficile da vedere a occhio nudo. Questo esempio mostra una forma di vulnerabilità alle perturbazioni avversarie, ma non descrive ogni rischio di robustezza: il test è pertinente soprattutto quando l’applicazione può essere esposta a input manipolati. In un contesto senza un avversario plausibile, potrebbe essere più utile valutare illuminazione, sensori o cambiamenti di sfondo.

Come valutare i risultati e scegliere le contromisure

Una valutazione utile parte dallo scenario, non da una metrica scelta a priori. Occorre specificare quali dati rappresentano il dominio di riferimento, quali variazioni rientrano nel test e quale peggioramento sia accettabile. Quando il cambiamento è già avvenuto, si possono confrontare i dati precedenti e successivi. Per uno scenario futuro, una simulazione può aiutare, purché le ipotesi siano documentate e i risultati siano presentati come stime dipendenti da tali ipotesi.

Le metriche aggregate possono nascondere problemi: un modello potrebbe mantenere un’accuratezza complessiva elevata e peggiorare molto su una classe rara o produrre falsi negativi in situazioni importanti. Perciò è opportuno esaminare più metriche e suddividere gli errori secondo le caratteristiche rilevanti per l’uso. Le tecniche interpretative possono offrire indizi su caratteristiche spurie, ma non dimostrano da sole che il modello fallirà in un particolare scenario.

Le strategie di mitigazione dipendono dalla causa individuata. Se la variazione è controllabile, si può ridurre la fonte dell’instabilità, per esempio standardizzando i sensori. Se il modello incontra casi molto diversi dai dati di addestramento, un rilevatore di dati fuori distribuzione può segnalare gli input da affidare a una verifica separata; il rilevatore, però, non rende il modello capace di gestire un cambiamento sostanziale. Quando la variazione è inevitabile, si possono raccogliere dati rappresentativi, reali o sintetici, e riaddestrare il modello. Se il problema riguarda caratteristiche spurie o rappresentazioni troppo dipendenti dai dati di addestramento, possono essere utili una progettazione più attenta delle caratteristiche, scelte architetturali motivate o l’apprendimento per trasferimento.

Gli autoencoder sono una delle tecniche usate per rilevare dati fuori distribuzione: codificano un input in uno spazio latente e poi tentano di ricostruirlo. Si può usare l’errore di ricostruzione come indicatore e classificare come fuori distribuzione gli input che superano una soglia. Il metodo ha limiti: anche dati fuori distribuzione possono essere ricostruiti con un errore basso, mentre la scelta dell’architettura, dello spazio latente, della funzione di perdita e dei dati di addestramento influisce sul risultato. La soglia va quindi calibrata e verificata sul caso d’uso, non trattata come una garanzia.

Errori frequenti, limiti e domande comuni

**Confondere robustezza e generalizzazione.** La generalizzazione riguarda le prestazioni su dati non osservati; la robustezza riguarda la stabilità rispetto a variazioni specificate. Le due proprietà possono essere correlate, ma un buon risultato su dati in-domain non basta a dimostrare che un modello sia robusto a rumore, cambiamenti di dominio o attacchi.

**Pensare che un modello più complesso sia automaticamente più robusto.** La complessità non garantisce stabilità. Lo studio sulla qualità dell’energia mostra che, nelle configurazioni sperimentali considerate, buone prestazioni in-domain e robustezza al rumore o al trasferimento tra domini non coincidevano. Questo risultato non consente di generalizzare la superiorità di una famiglia di modelli a ogni attività.

**Valutare una minaccia irrilevante o affidarsi solo a dati sintetici.** Testare attacchi avversari può essere poco utile se non esiste un rischio plausibile di input manipolati e se le variazioni ambientali sono più importanti. Al contrario, quando lo scenario previsto non è ancora osservabile, i test sintetici dipendono dalle ipotesi usate per generare i dati e vanno considerati come verifiche preventive, non come prove del comportamento futuro.

**Considerare l’OOD una soluzione universale.** La rilevazione può aiutare a segnalare input insoliti, ma non elimina l’incertezza né assicura che tutti i dati problematici vengano riconosciuti. Inoltre, una soglia che funziona in un contesto può non essere adatta a un altro. La valutazione deve essere proporzionata alle conseguenze degli errori: un sistema di supporto all’etichettatura della fauna e uno strumento per decisioni cliniche non richiedono necessariamente lo stesso livello di controllo.

**Che cosa significa, in breve, robustezza?** Significa mantenere un obiettivo prestabilito entro una tolleranza quando intervengono variazioni pertinenti, definite in un dominio esplicito.

**Come si verifica?** Si descrivono i cambiamenti plausibili, si raccolgono o si generano dati che li rappresentino e si confrontano prestazioni ed errori con un riferimento adeguato. I risultati devono essere interpretati nel contesto e con le limitazioni dei dati e dei test disponibili.

**Esiste una strategia valida per ogni modello?** No. La scelta dipende dalla causa del problema, dai dati, dall’ambiente di utilizzo e dal costo degli errori. Controllare la fonte, filtrare input insoliti, raccogliere dati rappresentativi o modificare il modello sono opzioni da confrontare e verificare.

**La robustezza si può dimostrare una volta per tutte?** No: una valutazione documenta il comportamento osservato in condizioni definite. Cambiamenti futuri o non inclusi nei test possono rivelare vulnerabilità diverse. Nei contesti ad alto rischio, la valutazione deve inoltre considerare i requisiti normativi e di sicurezza applicabili.

Concetti correlati