Decisioni “istantanee” per agent e app: come funzionano i modelli a scelta vincolata (e perché stanno cambiando i router LLM)

Nell’ecosistema AI stiamo assistendo a un passaggio interessante: invece di chiedere a un LLM di scrivere sempre e comunque, iniziamo a usarlo (o affiancargli) per decidere in modo vincolato e ultra-rapido.

In pratica: in molte pipeline “agentiche” e in molte app non serve una risposta testuale. Serve una decisione piccola e ripetuta migliaia di volte.

• È urgente o no?
• Quale categoria tra queste 6?
• Quale azione eseguire tra jump / left / right?
• Che punteggio (0–1) assegni a questa segnalazione?

In questi casi far generare testo a un LLM generalista è spesso sprecato: costa di più, introduce latenza e soprattutto apre la porta a risposte non controllate (il classico “mi invento una settima opzione”).

Perché un LLM “classico” è inefficiente quando ti serve solo una scelta

Un LLM tradizionale lavora producendo token di testo. Anche se gli chiedi “rispondi solo con A/B”, internamente sta comunque facendo generazione token-by-token e spesso:

1. Streaming e latenza: vedi arrivare i token gradualmente. Anche se la risposta finale è corta, il percorso è quello.
2. Variabilità: a parità di input la risposta può cambiare (temperatura, sampling, ecc.).
3. Output non garantito: devi aggiungere vincoli (prompt, tool calling, JSON mode, schema…), ma non è mai “impossibile” che esca qualcosa di non conforme.

Questa è la radice del problema: tantissime decisioni “piccole” sono in realtà blocchi infrastrutturali, non conversazioni.

L’idea: decisioni senza generazione testuale

I modelli “a scelta vincolata” (chiamiamoli così) ribaltano il contratto:

• tu fornisci uno stato (contesto) spesso in forma strutturata;
• tu definisci una o più domande, ciascuna con un tipo rigido;
• il modello restituisce probabilità o punteggi sulle opzioni, non una risposta testuale libera.

Il risultato è che la “risposta” diventa più simile a una valutazione statistica che a una generazione.

Da qui arrivano i due vantaggi più citati:

• Latenza molto bassa (decisioni rapide)
• Maggiore determinismo (non può inventare forme o opzioni, perché il dominio è chiuso)

Tipi di decisione più utili: boolean, choice, score

Nella pratica, i formati ricorrenti sono tre (nomi e dettagli cambiano a seconda del provider, ma il concetto è stabile):

1) Boolean (sì/no)

Perfetto per gating e classificazioni binarie:

• isUrgent?
• isSpam?
• needsHumanReview?

L’output tipico è true/false + una confidence.

2) Choice (una opzione tra N)

Tu fornisci un elenco di opzioni e il modello sceglie (o assegna probabilità) tra quelle.

Esempi pratici:

• routing: "small" | "big" | "search"
• UI: "light" | "dark" | "system" (se vuoi inferire preferenze da contesto)
• agent action: "click" | "type" | "scroll" | "wait"

Qui il punto è che il modello non può rispondere fuori lista.

3) Score / slider (punteggio continuo)

Invece di scegliere una classe, assegni un valore:

• tossicità 0–1
• priorità 0–100
• “quanto è simile” 0–1

Ottimo quando vuoi definire soglie nel codice (es. if score > 0.82 then …).

Perché questo aumenta il “determinismo” nelle app

Nel mondo frontend e nelle architetture agentiche, la parola determinismo non è filosofia: è debuggabilità e testabilità.

Se l’output è vincolato:

• puoi scrivere test che validano che l’output sia sempre uno tra gli enum attesi;
• puoi fare fallback robusti;
• puoi loggare decisioni in modo strutturato;
• riduci i casi “il modello ha risposto in un formato strano”.

È un salto notevole rispetto a prompt del tipo “rispondi in JSON valido” (che spesso funziona, ma non è una garanzia matematica).

Il caso d’uso che sblocca tutto: i router tra modelli

Uno dei pattern più costosi in produzione è il routing:

1. arriva una richiesta utente
2. un modello “router” decide se usare un modello grande, uno piccolo, o un percorso alternativo (search, tools, ecc.)

Se per prendere questa decisione usi già un LLM generativo, stai pagando (in latenza e costo) un passaggio che spesso è semplice classificazione.

Con un modello a scelta vincolata, invece:

• passi contesto e regole
• chiedi una choice
• ottieni una decisione rapida

Poi solo se serve attivi il modello grande.

In pratica sposti “la burocrazia” su un componente più leggero e usi l’LLM pesante per ciò in cui è davvero forte: ragionamento complesso, generazione, sintesi, piano d’azione articolato.

Dove ha senso (e dove no)

Ottimo per

• classificazioni rapide
• decisioni tra opzioni note
• gating e policy (consentito/non consentito)
• selezione di azioni in un loop agentico
• instradamento (routing) e orchestrazione

Non adatto a

• scrivere testi, spiegazioni, documentazione
• problemi che richiedono ragionamento multi-step “aperto”
• task dove devi cercare e combinare informazioni non presenti nel contesto

Un modo pratico per pensarla:

• se il tuo problema è un test a crocette, il modello a scelta vincolata è perfetto;
• se è un tema, ti serve un LLM generativo.

Implicazioni pratiche per chi fa frontend

Anche se sembra roba “backend/ML”, l’impatto sul frontend è concreto:

• UX più reattiva quando l’AI deve solo scegliere (per esempio: quale suggerimento mostrare, quale step di onboarding attivare, quale validazione applicare);
• meno sorprese nei formati di risposta (enum invece di testo libero);
• logging e analytics più puliti perché le decisioni sono già dati strutturati.

E, soprattutto, si semplifica l’integrazione: spesso non ti serve una pipeline di parsing complessa, ti basta consumare un JSON con opzioni e confidenza.

Sintesi

I modelli a scelta vincolata non “sostituiscono” i LLM: spostano fuori dai LLM generativi una classe di problemi che in produzione pesa tantissimo—routing, gating, classificazioni e decisioni discrete.

La conseguenza è un’architettura più pulita: decisioni piccole e frequenti diventano veloci, economiche e più deterministiche; il modello grande resta per i task davvero cognitivi. In un mondo di agenti e orchestrazione, questa separazione è uno dei modi più efficaci per far scalare sistemi AI senza trasformare ogni click in una generazione di testo.