Decision models: cosa sono, esempi e quali scegliere

Un decision model è un modello di intelligenza artificiale che valuta un contesto rispetto a domande con risposte definite dall'applicazione. Restituisce risposte tipizzate, cioè con un formato stabilito: una scelta fra opzioni, la probabilità di una condizione o un punteggio su una scala. Nelle domande a scelta singola, la distribuzione delle probabilità mostra quanto peso assegna a ciascuna alternativa.

Il contesto viene spesso chiamato state: può essere il messaggio di un cliente, un documento, un oggetto JSON o, nei modelli compatibili, un'immagine. La richiesta specifica le domande e i criteri per rispondere. Per esempio, il reparto "pagamenti" può comprendere fatture, addebiti e rimborsi, mentre "accesso" riguarda password e autenticazione.

Le opzioni possono cambiare da una chiamata all'altra. Lo stesso modello può classificare un ticket, valutare la rilevanza di un documento e scegliere uno strumento per un agente. Questa flessibilità dipende dalla capacità di interpretare le istruzioni e il contesto.

Il software che riceve la risposta decide come usarla: assegnare una coda, chiedere un chiarimento o inviare il caso a un operatore. Le regole dell'applicazione stabiliscono quando agire sulla stima del modello.

Le tre forme di domanda più comuni coprono classificazione, verifica di una condizione e valutazione su una scala. Possiamo applicarle tutte allo stesso messaggio: "Mi avete addebitato due volte l'ordine. Vorrei il rimborso del secondo pagamento".

Per una choice, le categorie devono avere descrizioni abbastanza precise da distinguersi. Per uno score, serve una scala ordinata: per esempio "può attendere", "da gestire oggi", "servizio bloccato". Il significato dei livelli è parte della richiesta.

Un LLM generativo produce una sequenza di token, le unità in cui viene suddiviso il testo. Molti decision model ricavano i punteggi delle risposte ammesse da un solo passaggio della rete. Questo può ridurre il lavoro necessario per rispondere, soprattutto quando ci sono poche alternative. Il costo effettivo dipende anche dalla lunghezza del contesto, dal numero di domande e da come il servizio le elabora.

L'output strutturato facilita l'integrazione, ma i contratti delle API differiscono. TypeSafe usa state e una mappa di questions; OpenAI usa input e un array di domande con un nome. Una migrazione richiede di controllare anche il significato dei campi restituiti.

d1-2B di Liquid AI deriva da un ulteriore addestramento di LFM3-VL-2B. Il suo codice pubblico permette di seguire il percorso dalla richiesta alle probabilità. Per Jev, le fonti consultate descrivono l'interfaccia e il comportamento, ma i dettagli interni restano in gran parte sconosciuti. L'architettura descritta qui è quella di d1.

Il backbone, cioè la rete che elabora l'input, combina convoluzioni e attenzione per mettere in relazione le diverse parti del contesto. La parte visiva trasforma immagini e fotogrammi in rappresentazioni che il modello può elaborare insieme al testo.

Seguiamo il percorso di una domanda a scelta singola. Estrazione di campi e coordinate usano percorsi aggiuntivi.

1. Preparare contesto e domande. Il codice associa alle opzioni dei codici rappresentabili da token. Organizza il contesto e le domande in una sequenza, riservando posizioni da cui leggere le risposte. Nella configurazione pubblicata, le domande sono raggruppate in insiemi di massimo 16 per default.

2. Elaborare la sequenza. Il backbone costruisce una rappresentazione numerica per ciascuna posizione. La modalità di attenzione set permette di elaborare più domande insieme allo stesso contesto. Le maschere di attenzione stabiliscono quali parti della sequenza possono scambiarsi informazioni.

3. Leggere i punteggi. Il codice seleziona gli stati nascosti nelle posizioni di risposta e li proietta attraverso la testa linguistica del modello, il modulo che assegna punteggi ai token. Per la decisione vengono letti quelli associati alle opzioni ammesse. La risposta si ottiene da questi valori, senza avviare una generazione di testo token dopo token.

4. Ottenere probabilità e valori tipizzati. I punteggi vengono riscalati con un parametro chiamato temperatura, scelto durante la calibrazione. La funzione softmax li trasforma in probabilità che, per una scelta singola, sommano a 1. Il codice costruisce quindi l'oggetto della risposta con l'opzione scelta e la distribuzione.

Il contesto è condiviso all'interno di ciascun gruppo di domande. Le sequenze possono essere elaborate nello stesso batch o in più batch, secondo i limiti del programma di inferenza. Aggiungere domande può quindi aumentare lavoro e latenza.

Per caratteristiche dei due modelli, benchmark e installazione con llama.cpp, trovi l'approfondimento nella guida a d1-2B e d1-Omni-2B.

La scelta dipende dal compito e dai dati disponibili. Se devi sapere se una fattura è stata pagata, consulta il sistema che registra il pagamento. Se devi interpretare una lamentela, un modello può aiutarti a riconoscere il problema. Per scrivere una risposta al cliente serve invece un modello generativo.

I classificatori zero-shot accettano già categorie nuove durante l'inferenza. Un decision model organizza capacità simili in un'interfaccia che può gestire più domande, tipi di risposta e distribuzioni di probabilità. Architettura e addestramento determinano quanto bene svolga ciascun compito.

Anche un LLM può restituire JSON conforme a uno schema attraverso la generazione vincolata. Questo risolve parte dei problemi di formato. Rimangono da valutare il costo della generazione, la correttezza della scelta e il significato di eventuali punteggi di confidenza.

I due approcci possono lavorare insieme: un decision model assegna il ticket al reparto e un LLM prepara la risposta usando le informazioni pertinenti.

Consideriamo un servizio con quattro code: pagamenti, accesso, spedizioni e revisione generale. Il reparto pagamenti si occupa di addebiti e rimborsi; accesso gestisce autenticazione e password. L'opzione "altro" raccoglie richieste che non rientrano nelle tre categorie.

Vogliamo scegliere la coda principale e mandare a un operatore i casi per cui il modello assegna una probabilità bassa alla propria scelta. Questo esempio usa numeri illustrativi, senza eseguire inferenza.

Una domanda a scelta singola impone una priorità anche quando il testo descrive più problemi. Se vogliamo registrarli entrambi, possiamo aggiungere domande sì/no: "Il messaggio segnala un problema di pagamento?" e "Il messaggio segnala un problema di accesso?". Ogni risposta avrà una propria probabilità.

La domanda sul rimborso richiede un'ulteriore distinzione: segnalare un doppio addebito e chiedere esplicitamente un rimborso sono condizioni diverse. Le istruzioni devono chiarire quale delle due interessa al servizio.

Per scegliere una soglia utilizzabile, dobbiamo misurare gli errori e il numero di richieste che resteranno agli operatori.

La probabilità è utile quando aiuta a distinguere le risposte affidabili da quelle da rivedere. Per valutarla servono esempi con una risposta corretta nota.

Supponiamo che, su molte richieste, il modello assegni alla scelta una probabilità vicina a 0,8. Se è ben calibrato su quei dati, circa l'80% di quelle scelte dovrebbe essere corretto. Una verifica della calibrazione confronta proprio probabilità dichiarate e frequenza degli esiti corretti. Un modello può classificare bene i casi e assegnare probabilità troppo alte o troppo basse.

La confidence è un campo dell'API e va letto secondo la sua definizione. Nel sorgente d1-2B esaminato coincide, per le domande choice, con la probabilità della scelta. Nell'interfaccia illustrata dal post Hugging Face è invece normalizzata rispetto a una distribuzione uniforme: con tre opzioni e probabilità massima 0,8, la confidence è 0,7. Trasferire la stessa soglia fra le due interfacce cambierebbe il comportamento dell'applicazione.

Per scegliere una soglia misura due risultati: quanti casi automatizzi e quanti errori commetti fra quei casi. Una soglia più alta riduce la quota automatizzata; il vantaggio in accuratezza va verificato sul test.

Conta anche il tipo di errore. Per segnalare possibili problemi di sicurezza può essere accettabile far controllare qualche caso in più. Per assegnare un ticket ordinario a un reparto, una revisione troppo frequente può annullare il beneficio dell'automazione.

Dataiku ha studiato questo effetto su 248 richieste sintetiche di registrazione di fornitori, adattando le soglie su una parte dei dati e misurandole sull'altra. La soglia iniziale di 0,7 lasciava passare troppe eccezioni alle regole aziendali. Il test ha permesso di scegliere valori più adatti a quel processo.

Per scegliere un modello da eseguire in locale conviene separare disponibilità dei pesi e licenza. Una licenza permissiva come Apache 2.0 consente ampi usi dei materiali distribuiti; altre licenze aggiungono condizioni commerciali. La disponibilità di un'API a pagamento è un'altra scelta di accesso allo stesso modello.

La selezione seguente comprende modelli con dimensioni e condizioni d'uso diverse. I dati sulle licenze si riferiscono alle fonti consultate il 10 novembre 2026.

Mammoth-1 ed Elephant-1 accettano testo e immagini. Il primo è fra i modelli scaricabili con i punteggi più alti nella valutazione AA v2 riportata sotto; il secondo è una variante più piccola da confrontare quando le risorse disponibili sono limitate. Le card dichiarano MIT; nei repository esaminati non è presente un file LICENSE separato, un dettaglio da chiarire prima di una distribuzione commerciale.

Perplexity Decider v1.2 supporta richieste con più domande sullo stesso contesto. La versione Flash ha caratteristiche di esecuzione e costi propri: il nome della famiglia va accompagnato dalla versione precisa quando si confrontano risultati.

Clef e Clef-flash sono disponibili con pesi scaricabili e tramite Workers AI. Questa doppia disponibilità permette di valutare il servizio gestito prima di assumersi la manutenzione dell'inferenza locale. Modalità di input e limiti effettivi vanno controllati sull'ambiente di esecuzione scelto.

d1-2B è il candidato più piccolo di questa selezione. Supporta l'italiano e dispone di una distribuzione per esecuzione locale; il nostro approfondimento su d1 descrive anche la variante con audio. La LFM Open License prevede condizioni commerciali legate a una soglia di fatturato di 10 milioni di dollari.

GLiDE-27B è scaricabile con Fastino Community License. Per l'uso commerciale in produzione da parte di organizzazioni con ricavi annui superiori a 10 milioni di dollari, la licenza richiede un accordo separato. Il risultato di GLiDE v1.2 nei benchmark sotto riguarda la versione servita via API. La corrispondenza con il checkpoint pubblico resta da verificare.

Per entrambi, il testo della licenza definisce le condizioni applicabili. Per eseguirli in locale occorre stimare memoria, carico previsto e tempo necessario per gestire il servizio.

Un servizio ospitato permette di provare il modello senza predisporre l'hardware. Oltre a qualità e prezzo, valuta condizioni sul trattamento dei dati, disponibilità del servizio, versioni e formato delle risposte.

Jev è il riferimento da cui si è diffusa l'interfaccia System One. La documentazione permette di mescolare tipi di domanda nella stessa richiesta. Il supporto immagini richiede un header sperimentale nella versione consultata: va verificato prima di progettare un flusso che ne dipenda.

OpenAI Decisions API usa un endpoint dedicato con risposte predicate, choice e score. La guida indica gpt-6-luna come modello supportato e accetta testo, JSON e immagini. Le capacità dell'endpoint sono definite dalla sua documentazione, anche quando il nome del modello compare in altri servizi OpenAI.

Microsoft-Decision-1 deriva da un addestramento successivo di Qwen3.5-9B ed è accessibile attraverso Foundry e OpenRouter. È un candidato per chi vuole integrare classificazione e valutazione nell'ambiente Microsoft. I confronti di velocità dell'annuncio sono misure del produttore.

Drex Max v1.1 supporta decisioni su schermate, immagini e video ed è fra i primi nella valutazione AA v2 dell'8 novembre. La famiglia comprende anche Drex 2.0 con pesi scaricabili: quella release ha architettura e licenza proprie.

I benchmark aiutano a restringere la scelta. Per interpretarli servono autore, versione, data e definizione del punteggio. Il Decision Index della community e quello di Artificial Analysis usano valutazioni differenti; anche le versioni successive dello stesso indice possono cambiare metrica.

L'Artificial Analysis Decision Index v2, presentato l'8 novembre 2026, combina sei valutazioni su documenti, uso di strumenti, conoscenza, ragionamento e coerenza delle risposte. Il Decision Score incorpora correttezza e Brier score, che misura lo scarto fra probabilità assegnata ed esito. Una componente separata valuta la coerenza quando la stessa domanda viene riformulata.

L'articolo colloca questi tre modelli entro un punto. Il risultato riguarda quella suite e quelle versioni; per un servizio in italiano serve una valutazione sui testi che riceverà davvero.

Anche il prezzo per token può essere fuorviante se letto da solo. AA v2 documenta differenze nella fatturazione di richieste con più domande: alcuni servizi condividono l'input, altri lo elaborano e addebitano più volte. Il confronto utile è il costo dell'intera operazione, comprese eventuali chiamate successive.

Per scegliere sul tuo caso:

1. Prepara esempi rappresentativi. Usa testi italiani reali, anonimizzati dove necessario, con risposte controllate. Includi messaggi ambigui e categorie poco frequenti.
2. Confronta poche alternative. Parti da una regola semplice o dal classificatore già disponibile e aggiungi due o tre candidati pertinenti per dimensione, modalità e licenza.
3. Scegli le soglie su dati separati. Adattale su un insieme di validazione e misura i risultati su un test che non hai usato per scegliere i valori.
4. Misura l'operazione completa. Registra errori, quota automatizzata, calibrazione, costo delle chiamate e quota di revisione. Per i tempi considera sia la mediana sia il p95, il valore entro cui termina il 95% delle richieste.
5. Conserva la configurazione. Modello, versione, domande, descrizioni delle opzioni e soglie fanno parte dello stesso esperimento. Ricontrollali quando cambiano i dati o il servizio.

Scegli il modello che raggiunge la qualità richiesta con tempi, costi e carico di revisione sostenibili per il servizio.

Per scrivere questa guida ho usato la documentazione dei produttori e le schede dei modelli. Ho inoltre letto il codice pubblico di d1-2B per ricostruirne l'architettura.

Le fonti sono state consultate il 10 novembre 2026. I link al codice di d1 rimandano alla revisione esaminata; i risultati di Artificial Analysis sono quelli pubblicati l'8 novembre.