Hugging Face presenta i modelli di decisione, una famiglia di modelli che non scrivono una risposta, ma valutano opzioni predefinite e restituiscono una distribuzione di probabilità su queste opzioni. L’azienda cerca di definire un’interfaccia comune per questi modelli, senza imporre un’unica architettura.
- Hugging Face propone i modelli di decisione, che valutano opzioni predefinite invece di generare testo.
- Restituiscono una distribuzione di probabilità per scelte, punteggi e risposte sì/no.
- Evitano il rischio di JSON non valido e riducono la generazione superflua per classificazione e routing.
- Il formato è già supportato da Transformers e llama.cpp, mentre l’addestramento è in fase di sviluppo con TRL e Unsloth.
I grandi modelli linguistici (LLM), che producono la loro risposta token per token, cioè pezzo di testo per pezzo di testo, sono molto efficaci per redigere, programmare o ragionare. Ma non tutti i problemi richiedono di generare testo. Prendiamo un sistema di supporto clienti che riceve il seguente messaggio: « Mi è stato addebitato due volte l’abbonamento. Ho bisogno di un rimborso oggi. » Deve determinare quale team deve gestire la richiesta, il suo grado di urgenza e se il cliente chiede un rimborso.
Si può chiedere a un LLM di restituire queste risposte sotto forma di oggetto JSON. Questo approccio è già diffuso per la classificazione e il routing, ma presenta diversi limiti. Il modello non è garantito che rispetti lo schema richiesto: può produrre un JSON non valido, aggiungere chiavi inaspettate o rispondere al di fuori delle scelte consentite. Le librerie di decodifica vincolata, come Outlines e XGrammar, riducono questo rischio limitando i token consentiti a ogni passo, ma aggiungono un lavoro supplementare. Infine, quando l’applicazione deve solo scegliere tra risposte note, la generazione completa del testo può essere superflua.
Un’interfaccia basata sulle probabilità
Un modello di decisione riceve uno stato, cioè l’informazione da valutare, e una lista di domande. Restituisce decisioni accompagnate da probabilità. La fonte distingue tre tipi di domande. Il tipo choice seleziona un’opzione tra diverse. Il tipo score valuta qualcosa su una scala ordinata. Il tipo noul risponde a una domanda sì/no in forma probabilistica.
Nell’esempio presentato, il modello autotrust/GEV-26B-Decide attribuisce alla domanda di servizio le seguenti probabilità: Billing 0,998, Technical support 0,001 e Sales 0,001. Per l’urgenza, i livelli low, medium e high ricevono rispettivamente 0,10, 0,26 e 0,72. Il punteggio restituito corrisponde all’aspettativa di questa distribuzione, cioè 1,7, e non a un livello scelto a metà strada. Per la domanda « Il cliente chiede un rimborso? », il modello restituisce direttamente la probabilità di una risposta positiva, qui 0,92.
La nozione di confidenza, calcolata per le domande di tipo choice e score, riassume la concentrazione di queste probabilità. Il concetto non è del tutto nuovo: la società TypeSafe AI aveva presentato Jev, qualificato come modello « System One ». Il termine « modello di decisione » è stato infine adottato dalla comunità, perché descrive il ruolo computazionale del modello senza riferirsi a una particolare teoria della cognizione.
Un ecosistema in costruzione
Il nuovo formato è già supportato da diversi strumenti. La libreria Transformers propone un DecisionPipeline, una classe AutoModelForDecision e una classe DecisionConfig, oltre a un endpoint /v1/systemone dopo l’avvio di un server locale. Il motore di inferenza llama.cpp accetta anch’esso questi modelli tramite la stessa API. La fonte cita il modello ggml-org/Kev-4B-GGUF, servito sulla porta 9931. L’Hub propone un tag dedicato, decision-model, poiché questi modelli non condividono necessariamente la stessa architettura: alcuni si basano su encoder come ModernBERT, altri su modelli generativi più grandi.
Una volta regolata l’inferenza, la fonte affronta l’addestramento. Un esempio di dimostrazione affina il modello autotrust/JEV-9B per instradare richieste di supporto, utilizzando l’API Trainer. Il supporto per l’addestramento nativo in TRL è oggetto di una richiesta di merge, la PR n°8040, ancora aperta al momento della stesura dell’articolo. Inoltre, Unsloth propone una ricetta per trasformare un LLM generativo, come Qwen, in un modello di decisione, grazie a LoRA e a una testa di scoring.
