Perché tante chiamate LLM sono in realtà classificazioni
Buona parte del traffico LLM in produzione restituisce una sola parola. Va inoltrato questo ticket oppure no. Spam o non spam. Quale dei sei handler gestisce questo evento. Per ottenere quella parola mandi l’intero prompt a un modello general-purpose, aspetti che decodifichi una risposta token dopo token, ed estrai un oggetto JSON dal risultato. Paghi il prezzo e la latenza della generazione di testo, e quello che torna indietro è una decisione che starebbe in un enum.
“System One model” è il nome che TypeSafe AI dà a un modello costruito proprio per quella seconda forma: prende un pezzo di stato più un insieme di domande tipizzate e restituisce una risposta a ciascuna in un solo passaggio, senza generare testo. Il termine prende in prestito la distinzione di Daniel Kahneman tra il pensiero rapido e automatico (“Sistema 1”) e il ragionamento lento e deliberato (“Sistema 2”). Jev, l’implementazione di TypeSafe, è l’esempio concreto qui. L’etichetta appartiene al vendor, ma l’idea dietro è più vecchia: se l’output è limitato a un insieme noto di risposte, il modello può sceglierne una invece di scriverla. La domanda per il tuo sistema è se questa forma corrisponde a un vero collo di bottiglia.
Perché un modello System One può saltare la decodifica token per token
Un LLM generativo produce output che non ha ancora visto. Ogni token dipende da tutti quelli precedenti, quindi il modello ne predice uno, lo aggiunge all’input e predice il successivo. Questa dipendenza è il motivo per cui la generazione è lenta: il token 40 non può iniziare finché il token 39 non esiste.
Un modello di questo tipo rimuove la dipendenza fissando lo spazio delle risposte prima della chiamata. Non gli chiedi di scrivere una risposta. Per ogni domanda gli dai un menu (scegli una di queste etichette, posiziona questo su una scala da 1 a 10, rispondi sì o no), e lui valuta ogni opzione di ogni menu in un solo passaggio parallelo in avanti. Non c’è nessuna sequenza da decodificare, perché ogni possibile risposta è nota in anticipo.
Questo è tutto il trucco, ed è anche il limite. Fissare l’output è ciò che permette di saltare l’autoregressione, e tutto quello che sta fuori dall’output fissato scompare: non ottieni testo libero né un ragionamento scritto da ispezionare. La documentazione stessa di Jev dice che il modello va male in aritmetica, conteggio e confronto di date, che richiedono un calcolo a più passaggi invece di una scelta tra opzioni. Se il task richiede che il modello produca qualcosa invece di selezionare qualcosa, usa uno strumento diverso.
Cosa mandi a un modello System One e cosa ottieni indietro
Ogni chiamata ha due parti. Lo stato è tutto ciò che il modello deve guardare: un’email, un ticket di supporto, un frame di gioco, una riga di dati applicativi. Le domande sono tipizzate e limitate, usando i tre tipi visti sopra. Per ogni domanda ottieni indietro la risposta scelta più una distribuzione di probabilità sulle alternative.
Costruisci attorno a quella distribuzione. “Escalation” a 0,52 ed “escalation” a 0,98 hanno la stessa etichetta e significano cose molto diverse. Sulla seconda puoi agire in automatico. La prima appartiene a un percorso più lento e più attento, che sia una persona o una chiamata LLM completa.
Puoi ottenere un segnale simile da un modello generativo leggendo le log-probability dei token di una risposta vincolata, se il tuo provider le espone. La differenza è che un modello System One restituisce la distribuzione come risposta stessa, per ogni domanda, senza impianto aggiuntivo.
Quando usare un modello System One in una pipeline LLM
Lo schema che funziona è il gating, non la sostituzione. Un modello tipizzato veloce decide se la chiamata generativa costosa deve avvenire.
- Routing. Classifica la richiesta prima di scegliere quale modello o handler la elabora, invece di chiedere a un modello generico di classificare e rispondere nella stessa chiamata. Una pipeline RAG può usare lo stesso gate per decidere se una domanda ha bisogno di retrieval fin dall’inizio.
- Moderazione e triage. Assegna un punteggio ai contenuti per spam o urgenza prima che raggiungano una persona o un modello più costoso, così il percorso costoso gira solo su ciò che ne ha davvero bisogno.
- Guardrail. Dopo la generazione, controlla la risposta rispetto a vincoli tipizzati (contiene un certo pattern di dati, rientra in una categoria vietata) come un passaggio separato ed economico, invece di piegare il controllo dentro il prompt di generazione.
- Loop di controllo in tempo reale. Un game loop o il controller di un robot che ha bisogno di una decisione ogni frame non può aspettare la generazione. Un modello a passaggio singolo ci sta dentro. Un modello token per token strutturalmente no.
Le cose si rompono quando tratti la risposta del modello veloce come verità assoluta. Manda le risposte a bassa confidenza sul percorso più lento, e imposta la soglia sui tuoi dati etichettati, non su un numero tondo che sembrava giusto. Una distribuzione piatta con un’etichetta sopra resta comunque una scommessa.
Alternative: output strutturato e classificatori addestrati su misura
I team risolvevano questo problema prima che la categoria avesse un nome, in due modi principali.
Output strutturato su un LLM general-purpose. Le principali API LLM possono vincolare la generazione a uno schema JSON o a un enum, il che ti dà la stessa garanzia di risposta tipizzata senza adottare un nuovo tipo di modello. La decodifica resta autoregressiva, ma quando la risposta è un singolo valore enum la parte generata è solo una manciata di token. Gran parte della latenza e del costo va nell’elaborazione del prompt, e un modello System One deve farlo comunque. TypeSafe posiziona Jev come più veloce ed economico di questo approccio. Quanto di questo valga per le tue chiamate dipende dalla lunghezza del tuo prompt e da quante domande fai per chiamata, quindi è un numero da misurare, non da dare per scontato. L’output strutturato inoltre non richiede nuova infrastruttura se già chiami quel provider.
Un piccolo classificatore addestrato su misura. Per una decisione stabile e singola, come questa specifica chiamata di escalation o questo specifico filtro anti-spam, un classificatore addestrato sui tuoi dati etichettati è di solito più veloce ed economico di qualsiasi modello general-purpose, tipizzato o no. Il costo è che ti servono dati etichettati e un retraining ogni volta che il task cambia. Il vantaggio di un modello System One rispetto ad esso è l’ampiezza: un solo modello risponde a molte domande tipizzate diverse su tipi diversi di stato, senza un training run per ogni decisione.
La scelta giusta dipende da quante decisioni distinte hai e quanto traffico ricevono. Se hai una decisione stabile e ad alto volume, usa un classificatore dedicato. Se hai diverse decisioni correlate ma varie lungo una pipeline, è il caso per cui la forma System One è pensata. Se non fai migliaia di queste chiamate al minuto, comincia con l’output strutturato sul modello che già usi.
Come trovare le chiamate LLM che dovrebbero essere decisioni
Ripassa tutto quello che già mandi a un LLM general-purpose e segna ogni chiamata il cui intero output utile potrebbe essere un valore enum o un numero. Quelli sono i tuoi candidati. Sposta due di essi su output strutturato su un modello che già usi, che sia un’API in hosting o un modello locale in esecuzione con Ollama, che accetta uno schema JSON nel suo parametro format. Misura latenza e costo per chiamata rispetto alla versione attuale.
Qualunque cosa tu sostituisca, continua a mandare una piccola percentuale del traffico gated anche sul vecchio percorso, e confronta le risposte. Se l’output strutturato rientra già nel tuo budget di latenza e concorda con il vecchio percorso, fermati lì. Valuta un modello System One dedicato come Jev solo se non è così, e usa proprio quel campione affiancato per giudicarlo.