Modelli di Machine Learning: E se l’Accuratezza da Sola Non Bastasse Più?

Ammettiamolo, quando parliamo di intelligenza artificiale e machine learning (ML), la prima cosa che ci viene in mente, o almeno quella su cui ci si concentra di più, è l’accuratezza. Un modello è “buono” se è accurato, giusto? Beh, forse è ora di fare un passo indietro e chiederci: è davvero così semplice? Nel mio viaggio attraverso il mondo dell’IA, ho iniziato a sospettare che questa ossessione per l’accuratezza, o per metriche simili come l’F-score, ci stia un po’ sviando dalla rotta principale: creare valore reale per le persone e le organizzazioni.

Il Problema di Fondo: Modelli nel Mondo Reale

Pensiamoci un attimo. Raramente un modello di ML opera in un vuoto pneumatico. Quasi sempre, è inserito in un flusso di lavoro che coinvolge anche l’intelligenza umana. Immaginate un sistema che deve classificare le richieste dei clienti. Se il modello è super accurato ma non è sicuro di una previsione, cosa succede? Spesso, la richiesta viene passata a un operatore umano. E questo è un bene! È molto meglio che il sistema dia una risposta sbagliata, mandando il cliente su una strada completamente errata.

Ecco il punto: il valore di un modello non dipende solo da quante volte “ci azzecca”, ma da come si integra in questi sistemi ibridi. Dobbiamo considerare:

• Quanto spesso il modello “alza le mani” e chiede aiuto (rifiuto della previsione).
• Quanto sono corrette le previsioni che non vengono rifiutate.
• Qual è il costo di un errore rispetto al beneficio di una previsione corretta.

Questo vale ancora di più per i mastodontici Large Language Models (LLM). La questione se mostrare una risposta o meno è cruciale, specialmente con il rischio di “allucinazioni” (risposte inventate ma plausibili). E se le API non ci dicono quanto il modello è “sicuro” della sua risposta, valutare diventa un incubo.

Oltre l’Accuratezza: Introduciamo il Concetto di “Valore”

Quindi, se l’accuratezza non basta, cosa ci serve? Propongo un cambio di prospettiva, focalizzandoci su una metrica di “valore“. Non è nulla di trascendentale, ma un modo più olistico per guardare le cose. Questa metrica dovrebbe incorporare:

• I costi specifici del task per le previsioni corrette.
• I costi per gli errori.
• I costi (o benefici) del rifiutare una previsione e passare la palla a un umano.

Sembra banale, no? Chi non vorrebbe un modello che massimizza il valore? Eppure, la prassi comune è scegliere il modello con l’accuratezza o l’F1-score più alto e poi, magari, permettere agli utenti di filtrare le previsioni con bassa confidenza. Vi svelo un segreto: questo approccio è fallace. Se accettiamo che i modelli sono quasi sempre “selettivi” (cioè, possono astenersi), allora dobbiamo cambiare il modo in cui li misuriamo, confrontiamo e addestriamo.

La cosa divertente è che, anche quando usiamo l’accuratezza, stiamo implicitamente scegliendo un parametro di costo, spesso senza rendercene conto. E indovinate un po’? È probabilmente la scelta peggiore: quella di impostare il costo relativo degli errori a zero! Paradossalmente, l’accuratezza potrebbe andare bene solo quando le conseguenze degli errori del modello sono trascurabili. Ma quando mai succede nel mondo reale?

Studiando a fondo la questione, ho scoperto che:

• Le metriche universali sono pessimi indicatori del valore del modello, portando a scelte subottimali, a volte addirittura a modelli dannosi (con valore negativo).
• Anche le metriche che tengono conto degli errori sensibili al costo non sono adatte, perché ignorano l’opzione di rifiuto.
• La calibrazione (quanto le probabilità predette dal modello corrispondono alla reale probabilità di correttezza) gioca un ruolo critico. Modelli semplici ma ben calibrati possono spesso battere modelli complessi difficili da calibrare.
• Operare in un contesto “out-of-distribution” (con dati diversi da quelli di addestramento) riduce ulteriormente l’affidabilità delle metriche standard.

La metrica di “valore” che propongo non è radicalmente diversa, ma combina metriche esistenti (accuratezza, valore detrimento degli errori, tasso di rifiuto) in un’unica misura. Importante: è normalizzata in modo che un valore di zero indichi un classificatore inutile, un valore negativo un classificatore dannoso, e un valore positivo il guadagno ottenuto usandolo.

Come Funzionano i Classificatori Selettivi e Come Ottimizzarli per il Valore

Nella pratica, i modelli ML spesso filtrano le previsioni basandosi su una soglia di confidenza. Se la confidenza è sotto la soglia, la previsione viene scartata. Questo è il caso più comune. Possiamo formalizzare il “valore” considerando una soglia (tau). Data questa soglia, possiamo calcolare la proporzione di item rifiutati ((rho_tau)) e l’accuratezza degli item non rifiutati ((alpha_tau)).

Semplificando, se poniamo il valore di un rifiuto a 0 (il nostro scenario base, dove l’IA non viene usata) e il valore di una classificazione corretta a 1, il valore di una classificazione errata diventa (-k), dove (k) ci dice quanto è “grave” un errore rispetto a un successo. La formula del valore diventa: (V = (1-rho_tau) times (alpha_tau – k(1-alpha_tau))). L’obiettivo è trovare la soglia (tau) che massimizza questo valore.

Se un modello fosse perfettamente calibrato (la confidenza (c) corrisponde all’accuratezza attesa (c)), la soglia ottimale (tau) sarebbe (k/(k+1)). Questo ha senso: se (k) è grande (errori molto costosi), la soglia è alta e prevediamo con cautela. Se (k=0) (errori innocui), la soglia è 0, e prevediamo sempre (e qui l’accuratezza diventa la metrica di riferimento, come detto prima). Se (k=1) (errori e successi hanno peso uguale e opposto), la soglia è 0.5.

Nella realtà, i modelli non sono mai perfettamente calibrati, specialmente quelli complessi. Qui entrano in gioco tecniche di ricalibrazione post-hoc, come la “temperature scaling”, prima di applicare la nostra soglia ottimizzata per il valore. Oppure, si può massimizzare direttamente la formula del valore su un set di validazione.

E se gli Errori Hanno Costi Diversi?

La cosa si fa ancora più interessante quando errori diversi hanno costi diversi (pensate a un falso negativo in una diagnosi medica rispetto a un falso positivo). Possiamo estendere il concetto di valore. Per esempio, in una classificazione binaria, avremo valori specifici per veri positivi ((V_{tp})), veri negativi ((V_{tn})), falsi positivi ((V_{fp})) e falsi negativi ((V_{fn})).

Anche qui, possiamo definire soglie di confidenza specifiche per classe ((tau_p) e (tau_n)) per massimizzare il valore atteso, tenendo conto dei costi differenziati. Ad esempio, la soglia per predire “positivo” dipenderà da quanto “costa” un falso positivo rispetto al beneficio di un vero positivo.

Cosa Dicono gli Esperimenti?

Ho messo alla prova queste idee su task di classificazione NLP (Natural Language Processing), usando vari dataset, modelli (da quelli semplici a quelli stato dell’arte come i transformers) e codificatori di testo. Perché NLP? Perché è diffusissimo nelle aziende.

I risultati sono stati illuminanti:

• Accuratezza e F1-score sono pessimi proxy del valore. Il modello migliore secondo queste metriche cambia drasticamente al variare del fattore di costo (k), e spesso non è quello con il valore reale più alto.
• Le metriche di errore sensibili al costo non bastano. Anche se identificano modelli diversi al variare dei costi, spesso scelgono modelli con valore negativo perché non considerano l’opzione di rifiuto.
• La calibrazione è fondamentale. Ricalibrare i modelli (es. con temperature scaling) migliora sostanzialmente il loro valore, specialmente per costi (k) elevati. Modelli semplici come la Regressione Logistica, noti per essere ben calibrati, a volte superano modelli molto più complessi (e costosi da usare!) quando il costo degli errori è alto.
• L’Out-of-Distribution (OOD) è un killer. Quando i modelli operano su dati diversi da quelli di training (come nei task di domain adaptation), la loro mancanza di calibrazione è ancora più dannosa. Anche i grandi modelli pre-addestrati (come GPT-3 o SieBERT), pur performando bene in generale, mostrano che l’accuratezza non è un buon indicatore di valore con (k) elevati. A volte, un semplice modello lineare ben calibrato può essere la scelta migliore in queste situazioni difficili.

Questi esperimenti, sebbene controllati, riflettono scenari decisionali realistici in ambito aziendale. Pensate a un’applicazione che valuta il rischio di applicare una patch di sistema. È preferibile non dare assistenza piuttosto che offrire una guida fuorviante. Nei casi reali che ho visto, i product manager non assegnano mai pesi uguali (in valore assoluto) a valutazioni corrette ed erronee, e la non-inferenza (il modello che si astiene) è raramente considerata dannosa quanto una guida errata.

Tirando le Somme: Un Invito a Ripensare

Il messaggio che vorrei passasse è questo: usare metriche orientate solo all’accuratezza (cioè, che assumono che i modelli vengano applicati senza possibilità di rifiuto) è, come minimo, una proposta rischiosa. E questo vale anche per i modelli considerati “leader” di settore.

Dovremmo sempre valutare i modelli su una gamma di fattori di costo (k), basandoci sui casi d’uso reali che stiamo affrontando. E (k=0) (l’accuratezza pura) non è quasi mai un fattore di costo ragionevole. Abbiamo anche visto come applicare modelli senza una soglia di rifiuto possa portare a un valore negativo, e come l’ottimizzazione della soglia sembri funzionare meglio della sola calibrazione in certi contesti.

Questo lavoro, più che dare risposte definitive, vuole evidenziare un problema e delineare la necessità di ulteriori ricerche. Servono più studi, specialmente con modelli grandi e su dataset che mettano alla prova la generalizzazione (in-distribution vs out-of-distribution), per capire più a fondo come calibrazione, distribuzione della confidenza e dimensione del set di validazione influenzino il vero valore di un modello di machine learning. È ora di guardare oltre i semplici numeri di accuratezza e iniziare a misurare ciò che conta davvero.

Fonte: Springer