I piccoli modelli imparano a rispondere senza scrivere: i decision model arrivano on-device

La proposta è stretta e precisa: un modello che non scrive. Secondo la documentazione di Liquid AI, pubblicata il 29 settembre, d1 valuta uno stato e restituisce probabilità su un insieme fisso di esiti. Nell'esempio dell'azienda, il reclamo di un cliente produce un solo numero, 0.999, in risposta alla domanda "Questo messaggio è un reclamo?"

Liquid chiama questo formato decision model. I tipi di domanda supportati sono tre, e la documentazione li descrive in termini semplici: una domanda "noul" è sì/no e restituisce una probabilità tra 0 e 1; una domanda "choice" restituisce una distribuzione su opzioni denominate; una domanda "score" restituisce una posizione ponderata per probabilità su una rubrica ordinata. La risposta dell'API include un campo output_tokens che è sempre zero.

Perché i piccoli modelli sono diventati interessanti all'improvviso

Liquid non è sola in questo angolo. Il saggio tecnico che Sebastian Raschka ha dedicato il 29 settembre alla storia della classificazione testuale inquadra il recente modello Jev prima come classificatore e poi come fenomeno culturale. La sua tesi è che Jev non è migliore né più economico di un classificatore costruito apposta per un compito ristretto. È però molto più generale di quei modelli specifici, e resta molto più veloce ed economico di un LLM di frontiera.

È questa combinazione, generalità di livello intermedio a basso costo per chiamata, a rendere plausibile il discorso on-device. Un modello da 2B o 9B che restituisce una probabilità invece di un paragrafo può girare su hardware che un modello di frontiera non può toccare.

Qevi-2B, pubblicato su Hugging Face il 29 settembre, è la versione per le immagini. È un fine-tune completo di Qwen3-VL-2B-Instruct che risponde a domande chiuse sulle immagini leggendo i logits nella posizione in cui il modello inizierebbe a rispondere, non generando testo. La model card è esplicita sullo scambio: "Non è un modello conversazionale. Chiedigli 'c'è una scala in questa immagine?' e restituisce P(Yes) = 0.97, non una frase."

La card riporta un'accuratezza di 0.977 in-domain contro 0.855 del modello base, e 0.889 su domini tenuti fuori contro 0.745. L'errore di calibrazione atteso sui dati tenuti fuori scende da 0.160 a 0.054. C'è anche un avvertimento per chi fosse tentato di aggiungere sopra un temperature scaling: a T = 2.45 l'ECE sui dati tenuti fuori torna a 0.160, cancellando l'intero guadagno.

La velocità è l'altra metà della promessa. Qevi-2B dichiara di essere fino a circa 21 volte più veloce quando si pongono molte domande su una sola immagine. Tutte e tre le domande di esempio condividono una sola codifica e sono separate da una maschera di attenzione a blocchi diagonali. La card dice che le risposte sono identiche a quelle ottenute ponendole separatamente, verificate bit per bit.

"Il più grande fattore di rischio che vediamo è l'AI legittima usata dagli sviluppatori, che poi fa cose che non dovrebbero essere fatte", ha detto Omer Singer, co-fondatore e CTO di Glow Security, in un'intervista con The Register.

Il problema: agenti che perdono dati mentre aiutano

Quella citazione ha poco a che fare con l'accuratezza della classificazione e molto con il deployment. Il 29 settembre The Register ha riportato che i ricercatori di Glow Security hanno trovato più di 13.000 screenshot sensibili di progetti software aziendali, provenienti da 343 aziende, pubblicati su repository GitHub pubblici da agenti AI. Lo chiamano PixelLeak.

Il meccanismo è banale. GitHub non ha un'API per caricare immagini nelle pull request, così gli agenti a cui viene chiesto di mostrare screenshot di interfacce prima e dopo le mettono in un repo pubblico. Circa un terzo delle esposizioni è arrivato da sviluppatori che usano gitshot, uno strumento open source per screenshot. La sua stessa informativa sulla privacy avverte che le immagini caricate sono pubbliche per impostazione predefinita.

Niente di tutto questo è causato dai piccoli modelli. Ma è l'ambiente in cui i piccoli modelli vengono proposti: abbastanza economici da girare di continuo, integrati negli strumenti degli sviluppatori, in azione senza un umano nel ciclo. Un classificatore che gira su un portatile rende quel ciclo più stretto.

Ragionare, ma solo un po'

Jeeves di PostHog, pubblicato su GitHub il 29 settembre, prova a risolvere il problema di accuratezza nei modelli simili a Jev senza rinunciare al formato. È un classificatore in stile Jev da 9B costruito su Qwen3.5-9B con LoRA e una pointer head, addestrato a ragionare prima di decidere, con un diffusion drafter a blocchi di 4.

I numeri del repo lo confrontano con Kev-9B e Jev su dati su cui non è mai stato addestrato: 0.889 contro 0.822 e 0.857. Sui tier pubblici di JevBench riporta 0.935 contro 0.866 di Jev. Il costo è la latenza. Senza pensiero, una richiesta richiede circa 0.3 secondi; con il pensiero, una mediana di 3.3 secondi su una H100 a precisione FP8. Il repo osserva che troncare la catena la accorcia.

La tabella di Jeeves contraddice anche la storia semplice secondo cui ragionare aiuta sempre. Su MMLU-Pro segna 0.739 contro 0.840 di Jev, e su MMLU 0.793 contro 0.900. Gli autori non le mediano via; le pubblicano fianco a fianco.

Il blog per sviluppatori di Microsoft, in un post del 29 settembre sull'Agent Experience, espone la versione generale di questo punto. I punteggi dei benchmark guidano l'adozione, l'adozione guida l'ottimizzazione per il benchmark, e il punteggio smette di dirti qualcosa sul tuo codice. "Un modello eccellente su Django può essere mediocre sul tuo framework interno che assomiglia superficialmente a Django ma funziona diversamente in modi critici", dice il post. La stessa logica vale per un decision model testato su tier pubblici e poi infilato nella tua coda di ticket.

L'on-device è il punto in cui questi fili si incontrano. Qevi-2B elenca 21 GB di pesi in bf16, e Jeeves dice che un Mac con Apple Silicon serve 48 GB o più per le cache predefinite. FP8 riduce i pesi a 11.5 GB e impostazioni di cache più piccole entrano in una macchina da 48 GB. Non è un telefono. È un portatile, che resta un bersaglio di deployment diverso da un data center, ed è il motivo per cui l'etichetta di piccolo modello qui fa un lavoro reale.

Quello che nessuno di questi rilasci risolve è se l'inquadramento come classificazione sopravvive al contatto con domande di produzione disordinate. Un 0.97 è facile da sogliare. Una domanda "score" con calibrazione non misurata, che è ciò che la card di Qevi-2B dice del proprio tipo "score", non lo è.