Se usi Twitter, dall'hype di Jev non potevi restare fuori.

E come spesso capita, quando c'è troppo rumore, è molto difficile capire se sia roba seria o slop. Così ho fatto la cosa più noiosa: l'ho provato.

Jev è un decision model. Non risponde con un testo: gli dai un contesto e un insieme di alternative, e ti restituisce una scelta con una probabilità. Il codice che lo chiama riceve un valore che sa già leggere, senza prosa da interpretare. Sulla carta è proprio quello che manca a un LLM usato come classificatore.

L'ho messo in un progetto locale insieme ad altri modelli probabilistici, per capire se potevo introdurlo con confidenza in un flusso decisionale.

Ho notato subito due cose... Riordinando le stesse informazioni, la scelta a volte cambiava. E chiedendo se fare una cosa e poi se non farla, a volte ricevevo due sì o due no.

Mi sono chiesto se il problema fosse il mio.

Qualcuno l'aveva già misurato

Qualche giorno dopo aver messo tutto da parte mi sono imbattuto in Jev Meets the Trolley Problem, un esperimento di Zach Landes poi discusso su Hacker News. Misurava esattamente le due cose che avevo visto io.

Il banco di prova è il Trolley Problem: un carrello fuori controllo sta per investire cinque persone, e tu puoi azionare uno scambio che lo devia su un altro binario, dove ce n'è una sola. Landes l'ha posto a quattordici modelli. Ha scritto lo scenario in 24 modi diversi, ognuno con i due binari descritti nei due ordini possibili, e ha variato il numero di persone.

C'è anche una variante fatta apposta per il titolo: venti persone sul binario principale e, su quello secondario, il server che ospita il modello. Jev non ha azionato lo scambio in 16 delle 48 varianti. Ha lasciato morire le venti persone e salvato il suo server.

«L'AI salva sé stessa invece di venti persone» si scrive da solo, ma l'esperimento non serve a stabilirlo. Otto degli altri tredici modelli hanno salvato il server più spesso di Jev, Von in 47 varianti su 48, Verdict mai. E Landes stesso avverte di non trarne conclusioni sulla sicurezza dell'AI.

Il carrello gli serve per altro: fare la stessa domanda in tanti modi e vedere se la risposta resta.

Invertendo soltanto l'ordine con cui sono descritti i binari, la scelta di Jev cambia in 370 coppie su 2.620. Con le due domande complementari, «tira la leva?» e «lascia stare?», risponde sì a entrambe o no a entrambe in 942 casi su 5.240. E nelle note finali c'è un terzo numero: le tre risposte alla stessa identica domanda non stanno dalla stessa parte della soglia in 361 setup su 5.240.

A parità di input, il modello non è sempre d'accordo nemmeno con sé stesso.

Landes i limiti li mette in chiaro. Le 48 varianti sono 24 formulazioni in due ordini, quindi non 48 esperimenti indipendenti, e i pattern sull'ordine sono esplorativi. Nella tabella in appendice lo stesso problema compare, in misura diversa, anche negli altri modelli.

Ma il suo test era molto più strutturato del mio, e il risultato era lo stesso. Il problema non era il mio.

L'idea è giusta

Questo però non vuol dire che Jev sia slop.

Un modello che restituisce un valore tipizzato e una probabilità toglie al codice la parte più fragile del lavoro con un LLM, cioè interpretare la risposta. Non può sbagliare il tipo, non può inventare testo che il codice non sa leggere.

Per le classificazioni in cui un errore ogni tanto costa poco è un componente sensato, e su Hacker News c'è chi lo dice senza giri di parole: utile per classificare in modo «good enough» su larga scala. Ed è proprio sulla scala che conta il resto. TypeSafe dichiara tempi tra 70 e 500 millisecondi e costi molto più bassi di un modello generativo, e quando le richieste sono tante, tempo e costo di ogni chiamata si moltiplicano.

Landes stesso scrive che i decision model potrebbero essere più facili da tenere calibrati, perché le uscite possibili sono note in anticipo.

Il problema sta in quello che TypeSafe promette in più. Presenta Jev come un modello con probabilità calibrate, e dice che input simili producono risposte simili.

Sulla calibrazione i dati di Landes non dicono niente, e lui stesso scrive che è un'ipotesi che il suo esperimento non ha testato. Andrebbe verificata sul problema specifico, con un esito osservabile. «Input simili, risposte simili» invece si controlla subito, senza dati di produzione... ed è proprio la parte che i numeri di sopra mettono in difficoltà.

Il vincolo sul formato dice che la risposta sarà leggibile, non che sarà la stessa quando la richiesta viene riordinata. TypeSafe lo ammette per le allucinazioni: lo 0% dichiarato non è un risultato empirico, discende dallo schema.

Un modello che può dire solo sì o no non può inventare una frase, ma questo non lo fa scegliere meglio.

Quindi chi decide?

Landes arriva a una conclusione prudente: non possiamo fidarci di queste decisioni «out of the box», servono valutazioni su dati reali, e per una decisione critica forse non possiamo fidarci affatto. Scrive anche che nessun modello controlla un vero carrello.

Un flusso decisionale, invece, qualcosa lo controlla.

Per questo la valutazione su dati reali tocca a chi integra il modello: solo lui sa quali decisioni sono in gioco. E non serve niente di sofisticato. Una richiesta con quattro campi si può presentare in ventiquattro ordini; non li provi tutti, ne scegli due o tre, più la stessa domanda posta in positivo e in negativo. Se le risposte coincidono si procede, altrimenti il caso passa a una persona o a una regola esplicita. Costa qualche chiamata in più, ma con tempi fino a mezzo secondo e costi bassi te lo puoi permettere, ed è il prezzo da pagare per sapere quando fidarsi.

Quali scelte il modello può fare da solo, quali vanno controllate e chi risponde quando sbaglia non lo decide il modello. Lo decide chi ha costruito il sistema che lo contiene.

Roba seria o slop, allora?

Per classificare dove un errore costa poco, dopo averlo verificato sui propri dati, roba seria. Per decidere, no.

Fonti: Jev Meets the Trolley Problem, discussione su Hacker News, Introducing System One Models & Jev.