Un'IA che sa dire di non sapere.
Promettere l'assenza di errori non sopravvive al primo controesempio. Ciò che si difende è un errore delimitato, tracciato e misurato. Ecco l'architettura che questo impone, e ciò che Lei può esigere da un fornitore.
La promessa che non bisogna mai fare
«La nostra intelligenza artificiale non ha allucinazioni.» La frase si vende bene, e non sopravvive alla prima messa alla prova. Basta un controesempio, uno solo, perché il cliente smetta di credere a tutto il resto: il tasso di disponibilità, il calendario, la sicurezza. Una promessa assoluta trasforma qualunque incidente minore in prova di menzogna.
Il problema non è commerciale, è tecnico. Un modello linguistico produce sempre una risposta. Non dispone di alcun meccanismo interno che gli permetta di constatare che non sa: concatena parole plausibili, e il plausibile è esattamente ciò che assomiglia al vero. Promettere l'assenza di errori equivale a promettere che uno strumento si comporterà contro la propria natura.
Ciò che si può promettere al suo posto
La promessa difendibile non riguarda l'assenza di errori. Riguarda i limiti che si pongono attorno all'errore possibile, e il fatto che lo si misura.
In concreto, questo dà quattro impegni che si verificano tutti e quattro. Il sistema non può affermare nulla che non sia nei Suoi dati. Ogni frase cita la propria fonte. Ogni cifra è calcolata e non prodotta dal modello. Il tasso di fedeltà è misurato in continuo su un insieme di test, non annunciato una volta in una brochure. E ciò che scende sotto la soglia passa alla validazione umana invece di essere consegnato.
La differenza rispetto alla promessa assoluta è che un cliente può chiedere di vedere. Un insieme di test si ispeziona, un punteggio si ricalcola, una soglia si sposta. Nulla di tutto questo è una questione di fiducia.
L'architettura che rende vera la promessa
Una dottrina che non cambia la costruzione non vale nulla. Questa ha conseguenze precise sul modo in cui il sistema viene assemblato, e la principale consiste nel togliere al modello linguistico tutto ciò che fa male.
I fatti, gli identificativi e gli importi vengono dalla Sua base dati o dai Suoi documenti, mai dalla memoria del modello. I calcoli, i punteggi e le regole di criticità sono scritti in codice, quindi verificabili, quindi correggibili. Il modello interviene solo a fine catena, per mettere in forma ciò che gli è stato fornito.
Il resto poggia su tre regole di costruzione. La ricerca documentale viene prima della generazione, il che vieta di riversare un intero fascicolo nel contesto sperando che il modello ci si raccapezzi. Le istruzioni sono atomiche: un compito per chiamata, con un formato di uscita definito in modo rigoroso, anziché un'istruzione fiume che chiede otto cose in una volta. E la fiducia si misura campo per campo, non globalmente, perché un documento può essere letto perfettamente su nove campi e risultare illeggibile sul decimo.
I rischi che restano, e restano
Una dottrina onesta nomina ciò che non copre. Quattro rischi sussistono in questa architettura, e preferiamo scriverli piuttosto che scoprirli insieme a Lei.
La ricerca documentale può risalire alla fonte sbagliata: il sistema è allora fedele, ma fedele al falso. La messa in forma può tradire il contenuto, più raramente, ma il rischio non è nullo nemmeno quando il modello si limita a impacchettare. La classificazione della richiesta può sbagliare e orientare verso la procedura sbagliata. Infine un dato può essere sicuro e obsoleto, cosa che nessun meccanismo di fedeltà rileva.
Questi quattro rischi si trattano con gli stessi mezzi: citare le fonti perché una persona possa verificare, porre soglie che attivino una rilettura, e misurare in continuo invece di supporre che ciò che funzionava il mese scorso funzioni ancora. Nessuno si tratta con un'affermazione.
Il contesto molto ampio è un argomento di vendita
Un argomento ricorre in quasi tutte le offerte: la finestra di contesto gigantesca, presentata come la soluzione al problema dell'affidabilità. Basterebbe dare tutto al modello perché trovi.
La ricerca pubblicata sul tema dice il contrario. La capacità di un modello di utilizzare un'informazione si degrada a seconda della posizione di quell'informazione in un contesto carico: ciò che si trova a metà di un documento molto lungo viene sfruttato nettamente peggio di ciò che si trova alle estremità. Caricare di più non rende più affidabili, sposta il problema.
Un'offerta che vanta la dimensione della propria finestra senza mostrare la propria architettura di istruzioni vende una caratteristica del proprio fornitore di modelli, non una proprietà del proprio sistema.
Insegnare a un sistema a tacere
Il lavoro più utile che facciamo sui nostri prodotti non consiste nel migliorare le risposte. Consiste nell'ottenere silenzi nei punti giusti.
Un estratto la cui pertinenza è sotto una soglia misurata non entra nella risposta. E soprattutto non entra nemmeno negli elementi trasmessi al modello, il che non è la stessa cosa: un estratto che si toglie soltanto dalla visualizzazione continua a influenzare la risposta, e il sistema sembra allora citare correttamente fonti che non fondano nulla. Se nessun estratto supera più la soglia, il sistema dichiara che il punto non è coperto, invece di riempire il vuoto.
È un'esigenza costosa. Un sistema che risponde sempre fa migliore impressione in dimostrazione, e lo scarto si vede solo in produzione, il giorno in cui qualcuno si appoggia a una risposta che non sarebbe dovuta esistere.
Ciò che Lei può esigere
Se sta valutando un'offerta di intelligenza artificiale, quattro richieste bastano a separare chi ha misurato da chi afferma.
Chieda il tasso di errore per campo, su un insieme di test che Lei possa ispezionare. Chieda che cosa fa il sistema quando non sa, e ne faccia fare la dimostrazione su una domanda fuori perimetro. Chieda quali cifre sono calcolate e quali sono prodotte dal modello. Chieda infine quali rischi sussistono, sapendo che una risposta del tipo «nessuno» squalifica l'offerta più sicuramente di qualsiasi limite ammesso.
Applichiamo queste quattro domande ai nostri sistemi prima di proporli, e pubblichiamo i difetti che vi troviamo. È l'unico modo che conosciamo per rendere una promessa verificabile anziché credibile.
Sul degrado dello sfruttamento di un'informazione a seconda della sua posizione in un contesto carico, si vedano i lavori pubblicati con il nome di «lost in the middle» (Liang e coll.).