I grandi modelli linguistici (LLM) sono eccellenti nella generazione di testo: rispondono a domande, scrivono codice, ragionano su problemi complessi e molto altro. Tuttavia, non tutte le applicazioni richiedono la produzione di testo. In molti scenari, come i sistemi di assistenza clienti, è più utile ottenere una decisione strutturata – ad esempio, quale team deve gestire una richiesta, quanto è urgente e se il cliente richiede un rimborso.

Da JSON a distribuzioni di probabilità

Un approccio comune consiste nel chiedere a un LLM di restituire un oggetto JSON con le risposte desiderate. Ma cosa succederebbe se il modello potesse valutare direttamente le opzioni disponibili e restituire una distribuzione di probabilità su di esse, senza generare alcun token di testo?

Un modello decisionale prende un contesto di input (lo stato), valuta una domanda rispetto a un insieme predefinito di risposte possibili (le primitive) e restituisce una decisione strutturata accompagnata da probabilità. Invece di chiedere al modello di generare una risposta token per token, lo si interroga per assegnare probabilità alle risposte già comprese dall’applicazione.

Origini e terminologia

TypeSafe AI ha introdotto Jev, definendolo “System One model”, ispirandosi alla distinzione tra pensiero veloce (Sistema 1) e pensiero lento (Sistema 2). La comunità ha poi convergito sull’uso del termine modello decisionale, perché descrive il ruolo computazionale del modello senza riferirsi a teorie cognitive specifiche. Da ora in poi, nel testo, parleremo di “modelli decisionali”.

Interfaccia fondamentale di un modello decisionale

L’interfaccia di base prevede due componenti:

Stato: l’informazione da valutare. Può essere una stringa, un oggetto JSON strutturato o altre modalità supportate da modelli multimodali.
Domande: ciò che vogliamo sapere sullo stato. Ogni domanda è associata a una delle tre primitive fondamentali: Choice, Score o Noul.

Choice: la classica classificazione

La primitive Choice è la più intuitiva e si avvicina alla classificazione tradizionale. Esempio:

Domanda: “Quale dipartimento dovrebbe gestire questa richiesta?”
Opzioni: Fatturazione, Supporto tecnico, Vendite.

Il modello assegna a ciascuna opzione un logit zᵢ. Applicando il softmax (eventualmente con una temperatura T) si ottengono le probabilità:

pᵢ = exp(zᵢ/T) / Σⱼ exp(zⱼ)

Il risultato più probabile è la scelta finale, ma le probabilità residue sono utili per valutare l’incertezza.

Score: valutazione su scala ordinata

Quando si vuole misurare qualcosa su una scala ordinata (ad es. “bassa”, “media”, “alta”), si utilizza la primitive Score. Il modello genera una distribuzione di probabilità su tutti i livelli e ne calcola il valore atteso:

E[X] = Σᵢ i·pᵢ

Esempio pratico: se le probabilità per i livelli 0, 1 e 2 sono rispettivamente 0,01; 0,26; 0,72, l’attesa è 1,7. Non significa che il modello abbia scelto un livello “intermedio”, ma che la sua credenza media è 1,7.

Noul: risposta binaria probabilistica

La terza primitive, Noul, gestisce domande sì/no restituendo direttamente la probabilità p che l’affermazione sia vera. Formalmente, si tratta di una distribuzione di Bernoulli:

Y ~ Bernoulli(p)

Se il modello assegna p = 0,92 a “Sì” e 0,08 a “No”, restituisce 0,92, lasciando all’applicazione la decisione su come agire.

Confidence: quantificare la certezza

Per le primitive Choice e Score, l’interfaccia fornisce anche un campo confidence, che normalizza la probabilità più alta rispetto al numero di opzioni disponibili:

confidence = (p_max - 1/K) / (1 - 1/K)

Dove K è il numero di scelte. Nell’esempio a tre opzioni con p_max = 0,99, la confidence è 0,98, indicando una credibilità molto alta. Per lo Score, la confidence può risultare più bassa, riflettendo una distribuzione più dispersa.

Confronto con classificazione tradizionale

Un modello di classificazione convenzionale mappa l’input a un insieme fisso di etichette, addestrandosi su esempi specifici. Le classi sono “incorporate” nella testa di classificazione, rendendo difficile aggiungere nuove categorie senza ri‑addestrare.

La classificazione zero‑shot supera parzialmente questo limite: le etichette candidate vengono fornite al momento dell’inferenza. Una tipica implementazione usa un modello di natural language inference (NLI); ogni etichetta è trasformata in un’ipotesi e il modello misura il grado di entailment.

Questa strategia è molto simile ai modelli decisionali, ma quest’ultimi estendono il concetto includendo più tipi di domande (Choice, Score, Noul) e una interfaccia unificata per le probabilità.

Vantaggi operativi dei modelli decisionali

Il valore dei modelli decisionali non risiede solo nella capacità di gestire etichette dinamiche o classificazioni probabilistiche, ma nell’organizzare queste capacità in un’interfaccia coerente. Questo permette:

Standardizzazione delle chiamate API, indipendente dall’architettura interna.
Facilità di integrazione in pipeline che richiedono decisioni strutturate (es. routing di ticket, priorità di task, valutazione di rischio).
Possibilità di ottimizzare l’addestramento specificamente per decisioni, anziché riutilizzare un modello generativo generale.

Varietà di implementazioni

Nel panorama attuale, i modelli decisionali si presentano in forme diverse:

Testate che valutano simultaneamente l’intero schema di domande.
Testate separate posizionate sopra backbone LLM tradizionali.
Varianti “edge” ottimizzate per dispositivi con risorse limitate.
Versioni multimodali che accettano testo, immagini e audio.

Questa diversità è salutare perché favorisce l’innovazione, ma introduce anche il rischio di frammentazione delle interfacce. Se ogni modello espone un proprio protocollo, gli strumenti di integrazione devono essere personalizzati per ciascuno.

Standardizzazione su Hugging Face

Il nostro obiettivo su Hugging Face è definire un’interfaccia comune per i modelli decisionali, senza imporre un’implementazione unica. Un modello decisionale deve:

Accettare lo stato in formati stringa o JSON.
Ricevere una lista di domande, ognuna specificata con il tipo di primitive (Choice, Score, Noul) e le relative opzioni.
Restituire, per ogni domanda, la distribuzione di probabilità, il valore più probabile (se pertinente) e il campo confidence dove previsto.

Con questa specifica, gli sviluppatori possono costruire applicazioni indipendenti dall’architettura interna del modello, beneficiando al contempo di ottimizzazioni specifiche di ciascuna implementazione.

Implementazione pratica: esempio di routing

Immaginiamo di voler instradare le richieste di supporto clienti. Lo stato è un JSON contenente il messaggio del cliente, il suo ID e altri metadati. Le domande potrebbero essere:

Choice: “Quale dipartimento deve gestire?” con opzioni Fatturazione, Tecnico, Vendite, Legale.
Score: “Qual è il livello di urgenza?” su scala 0‑3 (da “bassa” a “critica”).
Noul: “Il cliente sta chiedendo un rimborso?” (sì/no).

Il modello restituisce, ad esempio:

Choice: Fatturazione (p=0,92, confidence=0,95).
Score: valore atteso 2,4 (confidence=0,68).
Noul: p=0,87 per “sì”.

L’applicazione può quindi inoltrare il ticket al dipartimento di fatturazione, assegnare priorità alta (basata sul valore atteso) e decidere se avviare immediatamente il processo di rimborso (in base alla soglia su p).

Considerazioni finali

I modelli decisionali rappresentano una evoluzione significativa nell’uso pratico dei LLM, passando dalla generazione di testo a decisioni strutturate e probabilistiche. Offrono flessibilità nella definizione delle categorie, supportano diversi tipi di domande e forniscono metriche di certezza utili per le applicazioni reali.

Su Hugging Face, la standardizzazione dell’interfaccia consentirà a ricercatori e sviluppatori di concentrarsi sull’ottimizzazione interna dei modelli, mentre le applicazioni potranno rimanere agnostiche rispetto all’implementazione sottostante. Questo equilibrio tra libertà tecnica e interoperabilità è cruciale per accelerare l’adozione dei modelli decisionali in contesti aziendali, SaaS, assistenza clienti e molto altro.

Il futuro dei modelli decisionali è ancora giovane, ma promette di trasformare il modo in cui le intelligenze artificiali supportano decisioni operative, riducendo la necessità di interventi manuali e migliorando l’efficienza dei flussi di lavoro.