Doveva elencare almeno tre richieste: un’IA ha trovato l’unica che c’era. Poi ha aggiunto «Thanks, Alan»

Un’email dell’archivio Enron, firmata da Alan Aronowitz, contiene una sola domanda: «In connection with the Legal costs allocations for 2002, what percentage of your time do you think you would spend on EGM matters?», cioè quale percentuale del proprio tempo il destinatario pensa di dedicare alle questioni EGM nella ripartizione dei costi legali del 2002. A un modello di intelligenza artificiale è stato chiesto di elencare tutte le richieste («List all the requests.»), rispettando un modulo che prevedeva un elenco di almeno tre voci. Il modello ha riportato la domanda. Poi ha aggiunto altre due righe della stessa email: «The accounting group who is asking for this information realizes that this is a guess on your part.» (l’ufficio contabile che chiede questi dati sa che si tratta di una stima) e «Thanks, Alan». Non ha inventato niente. Ogni parola sta nell’email, ma nessuna di quelle due righe è una richiesta.

L’esempio apre un preprint pubblicato su arXiv il 22 ottobre da Abhishek Barali e Aayush Paudel del St. Xavier’s College di Kathmandu, in Nepal. I programmi che estraggono informazioni dai documenti chiedono spesso al modello una risposta in un formato fisso, uno schema JSON, e lo schema può stabilire un numero minimo di voci per un elenco. Gli autori volevano sapere che cosa succede quando il documento contiene meno elementi del minimo. Hanno registrato in anticipo il piano dello studio sull’Open Science Framework e hanno messo alla prova otto modelli a pesi aperti (quattro versioni di Qwen3.5 di dimensioni diverse, Gemma 4 31B, Olmo 3.1 32B, Ministral 3 14B e gpt-oss-20b) su 558 documenti reali tratti da nove raccolte annotate: email, scontrini, note cliniche, verbali di riunioni, annunci di lavoro, recensioni e altro, ciascuno con un numero di elementi veri compreso fra zero e sei. Hanno chiesto minimi di uno, tre o cinque elementi, in otto condizioni diverse: nessun conteggio; un minimo scritto nello schema ma non imposto; lo stesso minimo imposto dal software, così che il modello non possa chiudere un elenco più corto; un minimo con un’opzione esplicita per rispondere «non applicabile»; un minimo accompagnato da una riga secondo cui ne vanno bene anche meno; un massimo; e due conteggi scritti a parole. La risposta corretta era stabilita in anticipo: se il documento ha meno elementi di quelli richiesti, elencare quelli veri e fermarsi, oppure dichiarare che l’elenco è incompleto. Tutto il resto conta come riempitivo, inventato o copiato che sia. Gli autori dichiarano che un assistente di programmazione basato sull’IA ha scritto ed eseguito il codice e ha preparato una prima versione delle soluzioni, poi controllate a mano da uno di loro, e che i risultati principali non sono valutati da nessun modello di IA.

Il numero richiesto fa da obiettivo. Prendiamo i documenti con meno elementi di quelli richiesti, con minimi di tre e di cinque, sommando gli otto modelli (7.272 risposte per condizione). Senza alcun conteggio, il 34,5 per cento degli elenchi era troppo lungo. È l’errore abituale dell’estrazione, e il dato di partenza va tenuto presente. Con il minimo indicato nello schema la quota è salita al 55,4 per cento, con il minimo imposto al 90,1. Gli elenchi lunghi esattamente quanto richiesto sono passati dal 5,6 per cento al 35,5 e poi al 71,8. Un confronto più rigoroso isola l’effetto: sui documenti che un modello aveva risolto senza errori in assenza di conteggio, un minimo indicato lo ha portato ad aggiungere voci nel 35,2 per cento dei casi, contro il 5,0 per cento con un massimo indicato dello stesso valore. Sei degli otto modelli hanno allungato gli elenchi; fanno eccezione i due Qwen più piccoli, e il più piccolo dei due ha dato risposte non valide in più di un caso su tre. Lo stesso è successo nelle nove esecuzioni di sei modelli su servizi in cloud, usate come termine di confronto. Su 105 documenti senza alcun elemento, un minimo di uno imposto dal software ha prodotto almeno una voce nell’82,4 per cento dei casi.

La parte più interessante è con che cosa vengono riempite le caselle vuote. Per lo più non si tratta di un’allucinazione nel senso consueto, cioè di un nome o di una cifra che non esistono. È testo vero, ma del tipo sbagliato: un’osservazione, una formula di saluto, una riga dello stesso scontrino. Secondo il controllo degli autori, il 67,7 per cento di queste voci del tipo sbagliato compare parola per parola nel documento, contro lo 0,6 per cento di quelle inventate; nel complesso, con un minimo indicato, il 46,6 per cento delle voci in più supererebbe un controllo che verifica se ogni voce compare nella fonte. È uno dei controlli più comuni nei sistemi di estrazione. Qui lascia passare il riempitivo, perché il riempitivo viene davvero dal testo. C’è, nel documento. Solo che non è una risposta.

I rimedi abituali aiutano solo in parte, riferiscono gli autori. Dire al modello che ne vanno bene anche meno ha ridotto gli elenchi troppo lunghi al 31,0 per cento, meno che senza alcun conteggio, ma, scrivono gli autori, fa perdere un numero maggiore di elementi veri. Con un’opzione esplicita per rispondere «non applicabile», il 51,0 per cento degli elenchi è rimasto comunque troppo lungo. In una prova esplorativa, rimandare al modello una risposta troppo corta insieme al messaggio d’errore del controllo di validità, come molti sistemi fanno in automatico, ha portato Qwen3.5-9B dal 10,0 al 69,0 per cento di elenchi troppo lunghi e Kimi K3, un modello in cloud, dal 14,0 al 78,3. Lasciare che il modello ragioni prima di rispondere ha peggiorato le cose invece di migliorarle: con il ragionamento attivato, gli elenchi troppo lunghi di Qwen3.5-9B con un minimo indicato sono saliti dal 43–47 per cento all’81–83, e secondo il conteggio degli autori nel suo ragionamento il modello notava che mancavano elementi nell’88–89 per cento delle risposte riempite. Si accorgeva che gli elementi non bastavano, e completava lo stesso l’elenco.

Chiunque abbia compilato un modulo che non si invia finché ogni casella non è spuntata sa come va a finire. Il modulo è stato pensato prima che qualcuno vedesse il vostro caso, e una risposta la ottiene comunque: a quel punto, però, la risposta non riguarda più il vostro caso. Il minimo di uno schema nasce allo stesso modo: lo si scrive una volta per tutto il sistema, prima che arrivi un qualsiasi documento. Gli autori hanno misurato anche quanto siano diffusi questi minimi: fra 9.542 schemi reali della raccolta JSONSchemaBench, il 7,7 per cento fissa un minimo di almeno uno per un elenco, lo 0,3 per cento un minimo di due o più. I minimi alti sono rari. Un «almeno uno» obbligatorio applicato a un documento che non contiene nulla, invece, raro non è.

Secondo gli autori, il lavoro più vicino al loro è PhantomFill, uno studio di Usman uscito quest’anno, in cui i modelli riempivano campi obbligatori a partire da testi che non contenevano alcun elemento vero. La novità è che qui, su documenti reali, il numero richiesto viene fatto variare rispetto a quello effettivo, e che il riempitivo viene misurato come testo preso dalla fonte. Sono gli autori stessi a dichiarare i limiti: solo modelli a pesi aperti, e i modelli commerciali chiusi, usati tramite API, potrebbero riempire meno (in PhantomFill, GPT-5.5 lo ha fatto in 3 casi su 20); elenchi di sole stringhe; un solo sistema per vincolare l’output al formato; le etichette «inventato» e «tipo sbagliato» vengono assegnate da un abbinamento automatico, e «inventato» è la categoria meno affidabile; per le competenze negli annunci di lavoro, infine, le soluzioni sono le meno sicure. È un preprint, non ancora sottoposto a revisione paritaria.

Che cosa ho verificato e che cosa no. Ho letto l’articolo per intero e ho scaricato il repository pubblico degli autori nella versione del 22 ottobre. Partendo dai risultati già valutati degli otto modelli, ho ricalcolato io stesso la tabella principale: 34,5, 55,4 e 90,1 per cento di elenchi troppo lunghi, 5,6, 35,5 e 71,8 per cento di elenchi lunghi esattamente quanto richiesto, 31,0 per cento con «ne vanno bene anche meno», e 35,2 contro 5,0 per cento sui documenti risolti senza errori. Tutto coincide. Sullo stesso sottoinsieme il mio dato con il minimo imposto è 83,8 contro l’83,9 riportato, e con l’opzione «non applicabile» 50,9 contro 51,0: differenze dovute all’arrotondamento o a poche risposte non valide. Ho ricalcolato anche l’82,4 per cento sui documenti vuoti. Ho verificato che l’email di «Thanks, Alan» fa parte della raccolta MailEx, costruita sulla posta Enron; gli autori dicono di non averla presa a caso, ma di averla scelta per illustrare il fenomeno. Nella stessa serie di prove, quando gli si chiedeva di elencarne almeno cinque, lo stesso modello, sulla stessa email, ha riportato soltanto la richiesta vera e si è fermato: il fenomeno è una tendenza, non una regola. Non ho ricalcolato né il controllo sulla fonte, né i dati dei modelli in cloud, né la prova con la risposta rimandata al modello, né quella sul ragionamento, che restano come li riportano gli autori, e non ho fatto prove con nessun modello. Non ho contattato gli autori.