Dalle LLM conversazionali ai modelli di classificazione a scelte finite: più veloci, più economici e spesso più affidabili quando serve decidere, non scrivere.
Nel frontend siamo abituati a ragionare in termini di eventi → stato → decisione → azione. È un ciclo semplice, ripetibile, e soprattutto misurabile. Una buona parte dell’AI “da prodotto”, però, si è infilata negli ultimi anni in un paradigma diverso: quello delle LLM che generano testo e “ragionano” a lungo.
Sta emergendo una famiglia di modelli progettata con un’idea quasi opposta: niente testo libero, niente divagazioni. Solo decisioni rapide su un insieme finito di scelte. Risultato: latenza bassissima, costi ridotti e un comportamento spesso più controllabile quando l’obiettivo non è scrivere, ma scegliere cosa fare.
System 1 vs System 2, ma in ottica prodotto
La distinzione torna utile perché descrive bene due modi di progettare l’esperienza:
- System 2: più lento, deliberativo, “ragionante”. Perfetto per spiegare, scrivere, sintetizzare, fare tutoring, produrre contenuti.
- System 1: veloce, istintivo, orientato alla scelta. Perfetto per classificare, selezionare un’azione, decidere tra opzioni predefinite.
Nel prodotto questo si traduce in una regola pratica:
Se il tuo flusso richiede una decisione ripetibile (click, next step, routing, label, intent), un modello “System 1” è spesso più adatto di una LLM generalista.
Cosa sono davvero questi modelli: classificazione con output strutturato
Questi modelli non “rispondono” come un chat. Lavorano tipicamente con due ingredienti:
- States: lo stato corrente (testo, contesto, snapshot, metadati) in forma strutturata.
-
Questions: domande/decisioni definite come schema, ciascuna con:
- tipo di risposta (boolean, scelta tra classi, score)
- criteri espliciti per guidare la decisione
Il punto interessante per noi: l’output è quasi sempre JSON, con scelta finale e spesso probabilità/confidenza. Questo apre subito una porta importante: osservabilità.
Perché l’output strutturato è un game changer
Nel frontend e nelle automazioni, testo libero significa edge case continui:
- parsing fragile
- ambiguità
- impossibilità di validare a compile-time
Con output strutturato:
- validi con Zod/TypeScript
- logghi le decisioni come eventi
- fai fallback quando la confidenza è bassa
- costruisci UI deterministiche (badge, warning, “serve conferma”)
Latenza: perché 30 ms cambiano l’UX
Quando una decisione arriva in ~30–40 ms, il modello smette di essere un “servizio remoto che aspetti” e diventa parte del loop interattivo.
È la differenza tra:
- assistente (ti risponde dopo un po’)
- controllore (decide mentre tu agisci)
Per un agente che controlla una UI (browser, app desktop, web app), questa latenza è cruciale: consente catene di micro-decisioni rapide, tipo:
- identifica il campo giusto
- decide se è già valorizzato
- sceglie l’azione (click / type / open menu)
- verifica lo stato successivo
…ripetendo decine di volte al secondo senza far “sentire” il pensiero.
Browser agents e frontend: la combinazione naturale
Nel mondo degli agenti browser, il problema non è scrivere testo. È:
- capire cosa c’è nella pagina
- scegliere dove cliccare
- verificare quando fermarsi
Un modello a scelte finite si presta perfettamente a questo pattern:
- “Qual è il prossimo step?” → {open_tab, fill_form, click_search, stop}
- “Questo elenco contiene opzioni coerenti con la richiesta?” → {yes/no + confidence}
- “Quale elemento della pagina corrisponde al target?” → {selector A/B/C}
In pratica, è un “policy model” leggero: dato uno stato, decide un’azione.
Esecuzione in locale: perché interessa davvero
L’altra implicazione enorme è che alcuni di questi modelli esistono anche in versione open weights e girano sulla macchina dell’utente (es. laptop Apple Silicon) con prestazioni sorprendenti.
Per un team frontend/prodotto questo sblocca scenari prima scomodi:
- privacy: dati che non escono dal dispositivo (email, pagine interne, strumenti aziendali)
- costo: automazioni continue senza bruciare budget a ogni iterazione
- resilienza: meno dipendenza da rate limit e disponibilità di servizi esterni
Non è “solo” ideologia open source: è una scelta architetturale.
Come si progetta una decisione robusta (pattern pratico)
Il trucco non è chiedere “cosa ne pensi?”, ma definire bene stato, opzioni e criteri.
1) State minimale ma informativo
Inserisci solo ciò che serve per decidere:
- testo (email, snippet pagina)
- contesto (da dove arriva, obiettivo)
- vincoli (cosa è consentito/non consentito)
2) Classi esplicite e finite
Esempio: classificare un’email per dipartimento.
Classi: billing | technical | sales | other
Più le classi sono:
- mutuamente esclusive
- ben definite
…più il modello performa.
3) Criteri (la parte che molti saltano)
I criteri sono “regole del gioco”. Anche una semplice booleana diventa affidabile quando definisci:
- quando è true
- quando è false
- cosa fare in caso di ambiguità
In ottica UI, i criteri sono l’equivalente di una spec: riducono interpretazioni creative.
4) Gestione confidenza
Non trattare la scelta come “verità”, ma come segnale:
-
confidence > 0.9→ automatico -
0.7–0.9→ automatico ma log + retry -
< 0.7→ fallback (chiedi conferma, passa a un modello più potente, oppure esci)
Questo è esattamente il modo in cui progettiamo UI robuste con input incerti.
Quando NON usarli
Non sono una bacchetta magica:
- se ti serve spiegazione, creatività o contenuto lungo → meglio System 2
- se il task richiede ragionamento multi-step complesso → meglio un modello deliberativo (o un orchestratore)
- se le classi sono mal definite o cambiano spesso → rischi instabilità e drift
L’approccio vincente spesso è ibrido:
- System 2 per pianificare (pochi step)
- System 1 per eseguire micro-decisioni rapide e ripetute
Implicazione pratica per chi fa frontend
Questi modelli rendono più realistico costruire:
- agenti UI che non bloccano l’esperienza
- automazioni “sempre attive” a costo quasi nullo
- feature AI con contratti di output (JSON) che si integrano bene con TypeScript
Sintesi
I modelli “System 1” spostano l’AI dal regno del testo libero a quello delle decisioni strutturate: meno magia, più ingegneria. Per il frontend è una buona notizia, perché il nostro lavoro migliora quando l’output è validabile, misurabile e integrabile nel loop stato→azione.
La direzione è chiara: più agenti, più automazioni, più controlli locali. E quando la latenza scende a poche decine di millisecondi, l’AI smette di essere un pannello laterale e diventa parte della UI.
Articolo originale: https://frontendfacile.it/blog/modelli-system-1-decisioni-in-millisecondi-per-agenti-ui-e-automazioni-anche-in-
Top comments (0)