Jev e l’idea radicale: togliere il linguaggio ai “LLM” per avere decisioni veloci, economiche e tipizzate

Negli ultimi anni abbiamo imparato a convivere con un paradosso: i modelli generativi sono potentissimi, ma spesso sono sproporzionati rispetto al problema che dobbiamo risolvere in un’app.

Se ti serve una decisione secca — sì/no, una scelta tra opzioni, un punteggio — chiamare un modello “chat” significa pagare (in latenza e in token) un motore progettato per parlare bene, argomentare, essere utile e… riempire il silenzio. E nel prodotto questo si traduce in tre problemi ricorrenti:

1. Verbosity: output lunghi quando servirebbe una singola parola.
2. Fragilità dell’output: parsing di testo libero, JSON “quasi valido”, edge case infiniti.
3. Costo e latenza: soprattutto quando la decisione è in hot path (moderazione live, UI reattive, realtime).

Jev nasce esattamente come risposta a questo: non un modello che parla, ma un modello che decide.

---

L’idea: eliminare il linguaggio dall’interfaccia

Il punto non è che “l’AI non usa più token” (li usa), ma che non ti restituisce linguaggio naturale come prodotto finale. L’interfaccia è pensata per ottenere uno di pochi tipi di output, sempre nello stesso formato.

In pratica, la query non è una richiesta “aperta”, ma una domanda fortemente tipizzata, con un risultato che deve rispettare una delle tre forme:

• choice: una scelta tra opzioni predefinite
• score: un valore numerico (punteggio)
• null: un esito booleano/di gating (pass/fail)

La promessa è ambiziosa: schema matching garantito, niente JSON rotto, niente “spiegoni” inutili, niente output che richiede parsing creativo. Per chi costruisce front-end e prodotti, questo cambia la qualità dell’integrazione: l’AI diventa un componente che si comporta più come una funzione pura che come una chat.

---

“Type-safe AI”: perché interessa davvero a chi sviluppa UI

Se fai frontend moderno, sai che “type safety” non è una mania estetica: è un modo per ridurre i bug e rendere l’evoluzione del codice meno rischiosa.

Traslato sull’AI, vuol dire:

• Contratto di output stabile: l’app sa esattamente cosa aspettarsi.
• Meno glue code: meno validazioni, meno fallback, meno regex.
• UI più affidabile: se l’AI alimenta componenti (badge, status, gating, ranking), vuoi output prevedibile.

Un esempio tipico è la moderazione: invece di chiedere “è consentito?” e ricevere un paragrafo, chiedi una decisione null che blocca/consente. Oppure un choice per assegnare una categoria tra poche (es. safe | suspicious | block).

---

System 1 vs System 2: decisioni rapide, non ragionamenti lunghi

Il framing “System 1” (alla Kahneman) è utile perché chiarisce lo scopo:

• System 1: veloce, istintivo, cheap → perfetto per decisioni frequenti e leggere.
• System 2: lento, deliberativo, costoso → utile quando devi spiegare, ragionare, pianificare.

Nel prodotto spesso hai bisogno del primo tipo molto più spesso del secondo.

Pensa a:

• classificare un input utente in tempo reale
• scegliere la prossima azione di un NPC
• decidere se mostrare un contenuto, bloccarlo o metterlo in review
• assegnare priorità a elementi in una lista

Sono tutte cose che non richiedono un saggio, ma un verdetto.

---

Output tipizzato ≠ output corretto

Qui è importante non confondere robustezza del formato con verità del contenuto.

Avere uno schema garantito significa:

• niente allucinazioni nella struttura (niente campi inventati, niente formati imprevedibili)

Ma non significa:

• zero errori nel merito (può classificare male)

In più, il comportamento può rimanere non deterministico: stessa domanda, stesso contesto, risposta diversa in run diversi. Questo è normale in molti modelli probabilistici e va gestito a livello di prodotto.

La leva utile: confidenza calibrata

Un aspetto interessante è l’idea di restituire sempre un numero di confidenza calibrata.

La confidenza “da chat” spesso è cosmetica: il modello suona sicuro perché gli esseri umani preferiscono risposte sicure. Qui invece l’obiettivo è che un “60%” significhi davvero: in media, quando dico 60%, ho ragione circa 60 volte su 100.

Per un prodotto è oro, perché abilita pattern come:

• soglie (es. accetta solo se confidenza > 0.85)
• fallback (se confidenza bassa, passa a un modello più costoso, o a revisione umana)
• UX adattiva (mostra “verificato” solo sopra una certa soglia)

---

Casi d’uso che diventano più pratici (anche nel frontend)

Se prendi sul serio un motore decisionale economico e veloce, si sbloccano integrazioni che prima evitavi per costo/latency:

1. Moderazione e policy enforcement in linea (prima del submit o al momento della pubblicazione).
2. Filtri intelligenti in UI (ranking, sorting, dedupe) guidati da score.
3. Routing di richieste: decidere quale pipeline usare (cheap vs premium).
4. Realtime: giochi, simulazioni, strumenti interattivi (decisioni per frame/tick o quasi).

Nel frontend, la differenza è che puoi trattare l’AI come un servizio che risponde con un tipo semplice, integrabile in stato e componenti senza dover “domare” testo libero.

---

Il punto controverso: quanto è nuovo rispetto ai classifier zero-shot?

L’idea di usare modelli per classificazione zero-shot non è nuova: da anni si estraggono probabilità su etichette/candidati e si sceglie l’opzione migliore.

Il salto (se confermato) sta più nell’insieme di scelte di prodotto e training:

• interfaccia tipizzata (choice/score/null)
• promessa di schema invariabile
• confidenza calibrata come feature di prima classe
• ottimizzazione aggressiva su costi e latenza

È anche il motivo per cui stanno comparendo implementazioni alternative che riproducono un’interfaccia simile leggendo le probabilità delle opzioni da modelli esistenti, in un singolo forward pass. Per chi sviluppa, questa dinamica è interessante perché suggerisce che il pattern potrebbe diffondersi anche oltre un singolo fornitore.

---

Implicazione pratica: progettare l’AI come “componente tipizzato”

Se costruisci prodotti web, la lezione più utile non è il nome del modello, ma il cambio di mentalità:

• Quando ti serve generazione, usa un generatore.
• Quando ti serve decisione, progetta un contratto tipizzato e chiedi solo quello.

In concreto:

• Definisci poche opzioni chiare (choice) invece di domande aperte.
• Introduci un punteggio (score) quando serve ranking, non spiegazioni.
• Usa null/boolean per gating e policy.
• Progetta soglie di confidenza e fallback fin dall’inizio.

Sintesi

Il futuro “pratico” dell’AI nelle app non passa solo da modelli sempre più bravi a parlare, ma da modelli e interfacce pensate per rispondere in modo controllabile. Tipi, schemi e confidenza calibrata portano l’AI più vicino a ciò che il software ha sempre preteso: contratti affidabili. E quando il contratto è chiaro, l’integrazione smette di essere una demo e diventa davvero prodotto.