Modelli decisionali: l’AI che risponde con una probabilità

Un modello decisionale è una rete transformer progettata per rispondere a domande chiuse assegnando una probabilità alle risposte possibili, senza generare testo. Si fornisce in input un contenuto e un elenco di domande con le risposte ammesse, e il modello restituisce per ogni domanda una distribuzione di probabilità sulle opzioni disponibili. Un algoritmo poi utilizzerà quei valori per prendere decisioni o far partire determinate azioni.

Cosa sono i modelli decisionali e in cosa differiscono dagli altri modelli AI

I classificatori rappresentano una delle prime applicazioni pratiche dell’intelligenza artificiale e vengono utilizzati da decenni con successo. Recentemente, si è iniziato a parlare molto di reti neurali basate su architettura transformers impiegate come classificatori anziché come generatori di testo. Il primo prodotto commerciale a presentarsi in questi termini è Jev, rilasciato in early access da TypeSafe AI il 15 settembre 2026 e presentato come “System One model”, con riferimento al pensiero rapido e intuitivo descritto da Daniel Kahneman.

Nel giro di poche settimane sono comparsi modelli open source con la stessa interfaccia e il supporto completo nelle librerie di integrazione, come l’API DecisionModel di LangChain4j.

Un modello linguistico generativo (LLM) produce un token alla volta: ogni elemento della risposta viene scelto campionando da una distribuzione di probabilità e successivamente reinserito nell’input per calcolare il token successivo. Un modello decisionale utilizza lo stesso tipo di architettura, il transformer, ma si ferma al primo passaggio: legge l’input una sola volta e ricava direttamente la probabilità associata a ciascuna risposta ammessa, senza alcuna generazione testuale.

Lì dove un LLM restituisce un testo che va interpretato o analizzato dal codice per estrarne un valore, un modello decisionale fornisce valori tipizzati tra quelli definiti dall’applicazione. Questi modelli vengono addestrati affinché le probabilità calibrate riflettano la frequenza effettiva dei diversi esiti. Il modello non motiva la propria scelta; quindi, se è necessaria una spiegazione per il cliente o per l’auditor, occorre ricorrere a un altro strumento.

Molte pipeline di automazione AI-powered utilizzano già un LLM in modalità “output strutturato” (JSON mode, function calling), chiedendo al modello di rispondere in un formato predefinito. In questi casi, la decisione va formulata tramite prompt, la risposta deve essere estratta dal testo e la probabilità, quando disponibile, non è utilizzabile per impostare soglie.

Il modello decisionale elimina i passaggi intermedi

Il modello decisionale, invece, elimina i passaggi intermedi: la domanda è un oggetto che contiene un tipo specifico e un insieme di risposte ammesse, mentre la risposta è una distribuzione di probabilità su quelle risposte.

Un classificatore tradizionale, come quelli che da anni vengono utilizzati per smistare e-mail o segnalare frodi, richiede centinaia o migliaia di esempi già etichettati per funzionare correttamente. Inoltre, il ciclo di addestramento deve essere ripetuto ogni volta che cambiano le categorie, ossia le etichette della classificazione. Con un modello decisionale, invece, le categorie si descrivono a parole al momento della richiesta. Il rovescio della medaglia è che un classificatore addestrato su dati proprietari, in un dominio stretto e stabile, può raggiungere livelli di precisione superiori e avere costi di inferenza pressoché nulli.

I test hanno comunque dimostrato che i modelli generativi di frontiera restano più accurati nei giudizi complessi che richiedono un certo reasoning per arrivare a una decisione corretta. Il modello decisionale si usa, invece, per ricevere il giudizio che una persona competente formulerebbe in un secondo, disponendo del giusto contesto.

Se chiediamo a un classificatore di questo tipo di analizzare un messaggio e stabilire la migliore linea d’azione, stiamo semplicemente ponendo una domanda sbagliata: un compito di questo genere richiede infatti un ragionamento multi-step.

I tre tipi di domanda: sì/no, scelta tra opzioni, posizione su una scala

Tutti i modelli decisionali rilasciati finora, sia commerciali che aperti, condividono le stesse tre primitive. I nomi usati da TypeSafe sono diventati lo standard di fatto: Noul per il sì/no, Choice per la scelta tra più opzioni e Score per la posizione su una scala. Ogni domanda ha un identificativo scelto dallo sviluppatore (che il modello non vede), un type, delle instructions in linguaggio naturale e, per i tipi Choice e Score, dei criteria che definiscono le risposte ammesse.

Nel caso del tipo Noul, la risposta è un unico valore numerico compreso tra 0 e 1, che rappresenta la probabilità di una risposta affermativa. Il codice utilizzerà poi delle soglie per stabilire come comportarsi a seguito della decisione del modello. È importante formulare domande precise, con confini netti, senza lasciare zone grigie che possano confondere il modello assottigliando il confine tra un sì e un no. Il campo criteria permette di descrivere cosa conta come sì e cosa come no.

Con le domande di tipo Choice, il modello risponde scegliendo tra un insieme chiuso e non ordinato di opzioni. Le descrizioni di ciascuna alternativa devono essere sufficientemente chiare da consentire di distinguerla dalle altre. Se l’elenco potrebbe non coprire ogni input possibile, si aggiunge un’opzione “other” o “none of the above”. Questa aggiunta, tuttavia, va valutata caso per caso, perché in molti contesti potrebbe non essere indicata. La risposta include anche un valore di confidence, che esprime quanto la probabilità sia concentrata su una singola opzione.

Quando si pone una domanda di tipo Score, la risposta è una posizione lungo livelli ordinati che l’applicazione descrive a parole. I livelli sono un elenco organizzato dal basso all’alto e il modello assegna una probabilità a ciascuno di essi. Lo score finale corrisponde alla media pesata dei valori numerici associati ai diversi livelli.  Per ottenere una decisione affidabile, è importante descrivere nel prompt situazioni ben delineate e non gradi generici: il modello deve poter confrontare il contenuto ricevuto con esempi e criteri specifici.

Ad esempio, un livello definito come “moderatamente grave” risulta poco efficace, troppo generico per poter essere valutato correttamente dall’intelligenza artificiale.

L’input di un modello decisionale viene chiamato stato (state) ed è costituito dal materiale su cui il modello deve esprimersi. Può trattarsi di un messaggio o di una stringa di testo, di un oggetto strutturato JSON o di una lista di valori. È ciò che si presenterebbe a una commissione di esperti umani prima di chiedere un giudizio. Ogni richiesta valuta una o più domande contro uno stato: tutte le domande ricevono lo stesso stato e vengono valutate in modo indipendente. Per massimizzare l’efficacia dell’architettura decisionale è bene inserire solo il contesto rilevante per le domande correnti, per evitare distrazioni e il degrado di qualità che accompagna i contesti lunghi.

Meglio utilizzare la lingua inglese

È buona norma utilizzare l’inglese o aggiungere, per lo meno, un avvertimento linguistico. I modelli hanno infatti una lingua principale di addestramento, che nella maggior parte dei casi è l’inglese, e le altre lingue, sebbene accettate, possono portare a livelli di accuratezza inferiori.

Le instructions di una domanda sono generalmente una stringa, e per una domanda breve e non ambigua, questa soluzione può essere sufficiente. Quando le decisioni si fanno più complesse, le domande possono diventare un oggetto strutturato, con la domanda in un campo e i dati che la guidano negli altri.  Questo diventa fondamentale quando la domanda ha bisogno di contesto o esempi, oppure quando più domande hanno istruzioni simili.

Anche le descrizioni contenute nel campo criteria possono essere oggetti. Per una Choice, ad esempio, ogni opzione può avere campi dedicati a specificare cosa include e cosa no, insieme a qualche esempio. I nomi dei campi possono essere liberamente scelti dallo sviluppatore, ma è consigliabile usare gli stessi per tutte le opzioni, così da permettere al modello di confrontarli a parità di condizioni.

Probabilità calibrate e soglie: agire, chiedere conferma, passare a un umano

Il principale valore aggiunto di un modello decisionale sta nel numero che accompagna le risposte. Per capire come usarlo, bisogna chiarire la procedura di calibrazione del modello e quali sono gli step per trasformare una probabilità in un’azione.

Un modello è calibrato quando le probabilità che restituisce corrispondono alle frequenze osservate. Ad esempio, se si considera un insieme di decisioni alle quali il modello ha assegnato una probabilità del 70%, circa il 70% di queste dovrebbe risultare corretto. La misura standard utilizzata per valutare questo aspetto è l’errore di calibrazione atteso (ECE), calcolato raggruppando le previsioni per fascia di probabilità e misurando in media, quanto la probabilità dichiarata si discosta dall’accuratezza effettiva. Un ECE di 0,03 significa che in media lo scarto è di tre punti percentuali.

Per le decisioni di tipo Choice e Score la risposta contiene due numeri distinti. Il campo probabilities contiene la distribuzione di probabilità sulle opzioni o sui livelli. La confidence, invece, riassume la forma di quella distribuzione in un solo valore da 0 a 1: il valore è 1 quando tutta la probabilità è su un esito e 0 quando è distribuita uniformemente.

Il Noul, invece, non ha un campo confidence perché il valore restituito descrive già l’intera distribuzione. Di solito, si prendono decisioni dividendo la probabilità del Noul in tre fasce, ciascuna associata a un comportamento diverso del sistema. In fascia alta, si procede in automatico con l’azione prevista; in fascia media, si procede inseguito a conferma o revisione; in fascia bassa, non viene intrapresa alcuna azione.

I pattern fan-out e il punteggio composito

I modelli decisionali seguono solitamente uno tra due schemi architetturali che permettono a tutte le domande di vedere lo stesso stato, ma di essere valutate in modo indipendente e in parallelo alle altre.

Il primo è il fan-out speculativo, che consiste nel mandare in una sola richiesta tutte le domande che il codice potrebbe avere bisogno di fare, incluse quelle la cui risposta è rilevante solo per alcuni input, e lasciare che sia il codice a decidere in seguito quali risposte utilizzare.

Se, ad esempio, usiamo il modello decisionale per il triage di un ticket di assistenza, potremmo avere bisogno di una categoria, di una valutazione della gravità, di un’indicazione di disponibilità degli step per riprodurlo, di individuare eventuali richieste di rimborso e, magari, di una di una valutazione della frustrazione del cliente. Invece di chiedere prima la categoria e poi, in una seconda chiamata, le domande specifiche, si chiede tutto insieme.

L’eccezione a questa regola avviene nei casi in cui il codice non può costruire la seconda richiesta senza aver ricevuto la prima risposta, magari perché è necessaria a recuperare altri dati da inserire nello stato, a determinarlo, o a scegliere le opzioni per la domanda successiva.

Il secondo schema architetturale, il punteggio composito, serve quando il giudizio dipende da più fattori. Invece di chiedere al modello di rispondere a una singola una domanda che nasconde più giudizi dietro una sola risposta, si chiede un giudizio per fattore e si combinano i risultati nel codice con pesi scelti dall’azienda.

Ad esempio, immaginiamo che la valutazione di un ticket possa usare tre Score: gravità del bug (tre livelli), frustrazione del cliente (tre livelli), quanto il report è complesso da lavorare (quattro livelli). Poiché le scale hanno lunghezze diverse, prima di combinarle, ogni punteggio andrà normalizzato dividendolo per il numero del livello massimo, così da far rientrare tutto nell’intervallo tra 0 e 1.

I limiti dei modelli decisionali

Un modello decisionale non è una calcolatrice né un foglio di calcolo. Non è affidabile nei conteggi e nelle operazioni matematiche e l’errore cresce con la grandezza di ciò che va contato e con la complessità del calcolo. Nella pipeline di automazione, quindi, per mantenere un livello di affidabilità elevato, l’aritmetica e i calcoli devono sempre restare nel codice.

Anche la gestione delle date presenta alcune criticità. Il modello le interpreta come stringhe testo, non come quantità ordinate, quindi chiedere quale di due date venga prima, quanto tempo intercorra tra di esse o se una rientri in una determinata finestra temporale, può produrre risultati inaffidabili. La situazione peggiora con formati misti, quando si utilizzano riferimenti relativi come “entro trenta giorni dalla consegna”, oppure confini di dominio come trimestri o periodi di competenza. La regola da seguire è semplice: l’estrazione è un giudizio e va affidata al modello, ma l’aritmetica, anche quando parliamo di date, deve restare nel codice.

I modelli decisionali, inoltre, rispondono alla domanda scritta, non a quella intesa. Questo significa che le parole che delimitano l’ambito, le negazioni e le condizioni implicite vengono lette sempre e comunque alla lettera. Dove una persona avrebbe colto l’intenzione, un classificatore perde di accuratezza e finisce per interpretare erroneamente le componenti di domande poco letterali.

L’accuratezza cala man mano che lo stato cresce con contenuto estraneo alla decisione. Il dettaglio non pertinente agisce da distrattore, e uno stato grande rende difficile capire quale parte dell’input ha prodotto una risposta sbagliata. Quando si parla di contesto, quindi, bisogna recuperare e filtrare i dati nel codice, e trasmettere al modello soltanto i campi specifici rilevanti per la domanda. In alcuni casi, questo filtraggio può essere affidato a un Noul di pertinenza.

Vulnerabilità agli attacchi di prompt injection

Anche questa forma di intelligenza artificiale può essere vulnerabile ad attacchi di prompt injection. Un’istruzione iniettata nel testo, un’inquadratura fuorviante o un testo che argomenta la propria classificazione possono influenzare la risposta e comprometterne l’affidabilità.

I classificatori sono da decenni pilastri portanti di una lunga serie di automazioni aziendali efficaci. L’architettura transformers ha ampliato i possibili utilizzi di questa forma di intelligenza artificiale e, con una giusta progettazione, un modello decisionale può migliorare ed economizzare le pipeline che fanno uso degli LLM classici per generare dati e decisioni strutturate.

Naturalmente, non si tratta di una soluzione universale, e quando i problemi si fanno complessi e il ragionamento richiesto per arrivare ad una decisione efficace è lungo e composto da più step, l’AI generativa resta l’unica soluzione percorribile.