Nel rapidamente evolversi del mondo dell'intelligenza artificiale, i grandi modelli linguistici sono diventati straordinariamente fluidi nel generare testi, risolvere problemi e scrivere codice. Possono sembrare sicuri di sé e logici, eppure commettono spesso errori sottili difficili da individuare. Per risolvere questo problema, i ricercatori hanno sviluppato dei "verificatori": sistemi secondari progettati per controllare il lavoro del modello principale e intercettare gli errori prima che raggiungano un utente umano. Questi controllori assumono molte forme: alcuni confrontano l'output del modello con un database di fatti, altri eseguono il codice per vedere se va in crash e altri semplicemente chiedono al modello di rivedere il proprio ragionamento. La speranza prevalente è stata che, aggiungendo questi strati di controllo, si possano costruire sistemi che non siano solo fluidi, ma anche affidabili. Tuttavia, una domanda critica è rimasta senza risposta: cosa possono garantire esattamente questi controllori? Quando un sistema afferma che un risultato è "verificato", significa che la risposta è sicuramente corretta, o significa semplicemente che la risposta sembra giusta secondo un insieme specifico e limitato di regole?

Un nuovo studio di Yajie Yin affronta questa confusione proponendo un nuovo modo per misurare la forza di questi sistemi di verifica. L'autore sostiene che l'attuale campo di ricerca utilizzi la parola "livello" per intendere cinque cose diverse contemporaneamente, creando una nebbia di incomprensione. Alcuni ricercatori usano "livello" per descrivere quanto finemente suddividono un problema, altri per descrivere il rischio coinvolto e altri ancora per descrivere quale parte del sistema informatico viene sottoposta ad audit. Il documento introduce una scala singola e chiara chiamata Livelli di Autonomia di Verifica (Verification Autonomy Levels), che si concentra su una domanda specifica: da dove proviene la verità e cosa promette di trovare il controllore? Questa scala spazia dalla forma più debole, in cui il modello dichiara semplicemente che il proprio lavoro è corretto, alle forme più forti, in cui il controllo si basa su fatti oggettivi e immutabili o su regole matematiche che possono dimostrare che una soluzione è completa.

La scoperta centrale di questa ricerca è un limite fondamentale che si applica a quasi tutti gli attuali metodi di verifica. Lo studio dimostra che molti controllori popolari possono confermare che una risposta proposta è corretta, ma non possono dimostrare che non sia stata tralasciata un'altra risposta corretta. Immaginate una guardia giurata che controlla una lista di visitatori approvati; se la guardia vede un nome sulla lista, li lascia entrare. Ma se arriva una persona pericolosa con un nome che non è sulla lista, la guardia non ha modo di sapere che manca qualcuno a meno che non abbia una lista completa e pre-approvata di tutti coloro che dovrebbero essere lì. Il documento chiama questo il "punto cieco della completezza" (completeness blind spot). La maggior parte degli attuali sistemi opera come la guardia con la lista: possono verificare che una soluzione candidata funzioni, ma non possono garantire di aver trovato ogni possibile soluzione. Questo limite non è un bug che può essere risolto addestrando meglio il modello o controllando più dati; è una caratteristica strutturale del modo in cui questi sistemi operano.

Per mappare questo panorama, l'autore ha sviluppato una scala a sei fasi, che va da L0 a L5. In fondo, L0 rappresenta un sistema in cui il modello dice semplicemente: "Ho controllato questo, ed è corretto". Non c'è prova esterna e nessuna garanzia di verità. Salendo, L1 e L2 comportano controlli basati su regole derivate dal problema o confronti con fatti oggettivi e noti. Questi sono utili per confermare che una specifica risposta è corretta, ma soffrono comunque del punto cieco: non possono provare che il modello non abbia tralasciato una risposta migliore o diversa. La scala compie un salto significativo in L3 e L4, dove la verifica si basa su un sistema decidibile, come una dimostrazione matematica formale o una regola logica rigorosa. In questi casi, il sistema può non solo confermare una risposta, ma anche dimostrare che non esistono altre risposte all'interno di uno specifico e ben definito ambito. Il livello più alto, L5, che rappresenterebbe un sistema capace di dimostrare la completezza per qualsiasi possibile domanda, è mostrato essere matematicamente impossibile.

Il documento testa questo framework attraverso quattro campi molto diversi: la risoluzione di problemi matematici, il monitoraggio del comportamento informatico per minacce alla sicurezza, la diagnosi di condizioni mediche e la scrittura di codice informatico. Negli esperimenti matematici, i ricercatori hanno costruito un sistema capace di controllare il proprio lavoro. Hanno scoperto che, sebbene il sistema potesse catturare alcuni errori, non migliorava l'accuratezza complessiva delle risposte rispetto al modello grezzo. In effetti, il processo di verifica a volte peggiorava le cose introducendo nuovi errori. Tuttavia, il sistema eccelleva in un compito diverso: poteva segnalare in modo affidabile quando era incerto o quando aveva trovato un tipo specifico di errore, come una soluzione mancante che un controllo più semplice avrebbe ignorato. Nello studio sulla diagnosi medica, i ricercatori hanno utilizzato una regola clinica standard per controllare il ragionamento del modello. Hanno scoperto che un semplice controllo basato su regole poteva intercettare i casi in cui il modello era erroneamente sicuro di sé perché mancava di prove necessarie, un fallimento che i revisori umani avevano tralasciato.

La ricerca ha esaminato anche la generazione di codice, dove il modello scrive programmi informatici. In questo caso, lo studio ha rilevato che il modello era già così bravo a risolvere problemi standard che l'aggiunta di uno strato di verifica non lo rendeva più accurato. La "finestra di accuratezza" era vuota; il modello era già al massimo delle sue potenzialità per quei compiti specifici. Il valore del sistema di verifica in questo contesto non era rendere il codice migliore, ma fornire un segnale chiaro quando il codice potrebbe essere insicuro o incompleto. L'autore sottolinea che questo non è un fallimento della verifica, ma una misurazione precisa di dove la verifica aggiunge valore. Essa aggiunge valore quando può segnalare errori o dimostrare la completezza, non quando cerca di aumentare l'accuratezza pura su problemi che il modello ha già padroneggiato.

Una parte cruciale del documento è la distinzione tra "correttezza" (correctness) e "completezza" (completeness). Correttezza significa che una risposta proposta è giusta. Completezza significa che il sistema ha trovato tutte le risposte giuste e sa che non ne esistono altre. Lo studio mostra che la maggior parte degli attuali sistemi offre solo la correttezza. Possono dire: "Questa risposta funziona", ma non possono dire: "Questa è l'unica risposta". Per raggiungere la completezza, un sistema deve essere in grado di riformulare il problema in un formato logico rigoroso che una macchina possa risolvere esaustivamente. Ciò è possibile per tipi specifici di matematica o codice, ma è impossibile per compiti aperti come il controllo dei fatti nelle notizie o la diagnosi di malattie complesse, dove il mondo è troppo caotico per essere interamente catturato da una singola regola. Il documento sostiene che dobbiamo smettere di pretendere che un sistema possa essere completo in questi scenari di mondo aperto. Invece, dobbiamo essere onesti riguardo ai limiti dei nostri strumenti.

L'autore affronta anche il problema della "ricorsione della fiducia" (trust recursion), ovvero il problema di aver bisogno di un controllore per verificare il controllore, e di un altro controllore per verificare quello, e così via. Il documento mostra che questa catena di fiducia deve infine fermarsi in un punto che non dipenda da un'altra intelligenza artificiale. Deve fermarsi a una regola definita dall'uomo, a una misurazione fisica o a una dimostrazione matematica. Se la catena si ferma a un altro modello di IA, la verifica è circolare e inaffidabile. Lo studio suggerisce che l'approccio migliore sia progettare sistemi in cui l'IA si occupi del lavoro creativo di generazione di idee, mentre un sistema separato e rigido controlli tali idee rispetto a uno standard fisso. Questa divisione del lavoro assicura che il sistema sappia quando sta operando al di fuori della sua zona sicura e quando fermarsi e chiedere aiuto all'uomo.

In definitiva, questo articolo funge da richiamo alla realtà per il campo della sicurezza dell'intelligenza artificiale. Propone un nuovo vocabolario che permette a ricercatori e sviluppatori di essere precisi su ciò che i loro sistemi possono e non possono fare. Avverte contro l'abitudine pericolosa di assumere che un sistema sia "verificato" solo perché ha superato un test. Al contrario, esorta a una visione più sfumata: un sistema potrebbe essere eccellente nel confermare che una specifica risposta è corretta, ma ciò non significa che abbia trovato l'intera verità. Il grado più alto che un sistema di verifica può ottenere non è una promessa di perfezione, ma una dichiarazione onesta dei suoi limiti. Comprendendo questi livelli, possiamo costruire sistemi di IA che non siano solo più intelligenti, ma anche più trasparenti su quando hanno ragione, quando hanno torto e quando semplicemente non lo sanno.