Jev: come funziona un’IA progettata per decidere in fretta
Neaptide · 27 settembre 2026 · 12 min di lettura
Come funziona Jev: Choice, Score, Noul, probabilità e limiti. System One, dati pubblicati e come provare il modello sui tuoi compiti.
In questo articolo
Un cliente scrive: «Non riesco a esportare il catalogo. Il CSV funziona, l’XLSX no. Devo inviare il file a un fornitore entro stasera». L’applicazione deve riconoscere l’argomento della richiesta, valutare l’impatto del problema e scegliere il passo successivo. Una risposta lunga del modello può aggiungere lavoro inutile: al sistema servono pochi valori precisi.
Jev è il modello di TypeSafe pensato per queste valutazioni. Riceve un contesto e domande con tipi di risposta definiti, quindi restituisce valori e probabilità utilizzabili dal software. TypeSafe chiama questo approccio System One. Il modello non scrive email o codice e non spiega il proprio ragionamento.
Nell’annuncio del 15 settembre 2026, l’azienda ha aperto l’accesso anticipato puntando sulla rapidità e sul basso costo delle decisioni. Per capire il valore pratico di Jev, conviene seguire l’intero percorso: dalla domanda al modello fino all’azione dell’applicazione.
Dove si inserisce Jev in un’applicazione
Una richiesta contiene state, il materiale da valutare, e questions, le domande su quel materiale. Il contesto può essere un messaggio, un oggetto JSON con i campi di un ticket o un array con dati testuali. Le domande di una stessa chiamata condividono il contesto e vengono valutate in modo indipendente. Jev accetta solo dati testuali: immagini e audio vanno prima convertiti in testo o nei campi pertinenti.
In questo esempio puoi chiedere separatamente quale reparto serva al cliente, quanto il problema ostacoli il lavoro e se desideri parlare con una persona. La regola che invia i ticket tecnici alla coda corretta rimane nel codice. Se il processo di assistenza cambia, lo sviluppatore può modificare quella regola senza cambiare le domande.
Questa suddivisione è utile di per sé. Chiedere «che cosa dobbiamo fare per questo cliente?» mescola comprensione del testo, priorità aziendali e azioni consentite. Domande circoscritte aiutano a individuare il punto in cui il sistema ha sbagliato. La documentazione di TypeSafe consiglia questa organizzazione del lavoro.
Tre tipi di domanda, tre significati
Jev offre tre tipi fondamentali di domanda: Choice, Score e Noul. La scelta dipende da ciò che il programma deve sapere.
Choice è adatto quando serve una sola opzione da un insieme definito, per esempio technical, billing oppure other. La risposta comprende l’opzione scelta, una distribuzione di probabilità e confidence. Le descrizioni delle categorie devono permettere di distinguerle.
Score serve per una scala ordinata. Per valutare l’impatto di un problema, puoi descrivere i livelli come «non ostacola il lavoro», «lo ostacola, ma esiste una soluzione alternativa» e «il lavoro è bloccato». Il risultato può cadere tra due livelli: è la media dei loro indici, ponderata con le probabilità. Un valore di 1,4 su una scala da 0 a 2 non significa che il 70% degli utenti sia coinvolto.
Noul valuta una singola domanda con risposta sì o no: per esempio, «Il cliente chiede esplicitamente di parlare con una persona?». Un numero tra 0 e 1 esprime la probabilità di «sì». Un valore vicino a 0,5 indica incertezza, non una «richiesta moderata». Noul non ha un campo confidence separato.
Per verificare una formulazione, chiediti se un collega saprebbe distinguere le opzioni senza una spiegazione a voce da parte di chi le ha scritte. In caso contrario, chiarisci prima categorie e livelli. Il modello non risolverà al posto dello sviluppatore l’ambiguità di una regola aziendale.
Che cosa copre la promessa «senza allucinazioni»
Nell’annuncio, TypeSafe collega l’assenza di allucinazioni a uno spazio di risposta limitato: il modello restituisce valori ammessi dalla struttura. Questo risolve un problema specifico, ossia una risposta arbitraria dove il programma si aspetta un determinato tipo.
Se sono disponibili tre reparti, selezionarne uno esistente non dimostra che il ticket sia arrivato alla squadra giusta. Una garanzia sul formato non implica la corretta comprensione del testo. Per lo stesso motivo, il rispetto dello schema non dimostra che un’azione aziendale sia corretta.
Non basta nemmeno confrontare Jev con un modello di chat a cui si chiede di «restituire JSON». Lo stesso adattatore di TypeSafe supporta le modalità native di output strutturato dei LLM. Per un progetto reale, confronta integrazioni complete: qualità delle decisioni, latenza, costo e gestione degli errori.
Le probabilità servono se il programma sa usarle
Immagina due risposte Choice che scelgono entrambe l’assistenza tecnica. Nella prima, quell’opzione concentra quasi tutta la probabilità. Nella seconda, le altre due opzioni sono vicine. Il solo nome del reparto scelto nasconde questa differenza.
Per Choice e Score, confidence viene calcolato dalla forma della distribuzione di probabilità. Non va interpretato automaticamente come «la probabilità che questa risposta sia corretta». TypeSafe propone di usarlo per decidere come proseguire, con soglie adatte al compito.
La calibrazione è un concetto distinto. In un ampio insieme di previsioni comparabili che assegnano probabilità 0,8 a un evento, quell’evento dovrebbe verificarsi circa nell’80% dei casi se il modello è ben calibrato. È una proprietà dell’insieme di previsioni. Non promette una risposta corretta in ogni singolo caso. Secondo TypeSafe, il metodo RLCD, Reinforcement Learning for Calibrated Decisions, è orientato all’addestramento di queste probabilità.
La conseguenza pratica è prevedere in anticipo un percorso per i ticket ambigui. Una scelta netta del reparto può consentire l’instradamento automatico; una distribuzione più dispersa può inviare il ticket a una coda di verifica generale. La soglia dipende dal costo di un invio errato e dai risultati delle prove sui tuoi messaggi.
Come leggere le cifre su velocità e costi
I numeri pubblicati aiutano a fare una prima valutazione, ma hanno basi diverse. Il prezzo nella documentazione è una tariffa. Il tempo di risposta è una misura in determinate condizioni. Un vantaggio su un insieme di test è un confronto con alternative selezionate.
| Indicatore | Che cosa è stato pubblicato | Come usarlo |
|---|---|---|
| Tempo di risposta | L’annuncio indica 70–500 ms; le valutazioni venivano generalmente eseguite dalla costa occidentale degli Stati Uniti, dove si trovava il servizio | Misura la latenza dalla regione della tua applicazione, comprese le risposte lente |
| Prezzo di Jev 1.13 | 0,042 USD per milione di token in ingresso; i token in uscita sono gratuiti | Calcola l’intero input, includendo contesto e domande |
| Qualità dei workflow | Quattro scenari: incidenti di sicurezza, osservabilità degli agenti, elaborazione delle fatture e assistenza clienti | Esamina il metodo e prova i tuoi scenari |
Fonti: condizioni di misura nell’annuncio, modelli e prezzi, Workflow evals. Verificate il 27 settembre 2026.
Workflow evals costruisce il riferimento usando la media delle risposte di GPT-6 Astra e Claude Fable 5.1 con un livello di ragionamento elevato; gli altri partecipanti usano le impostazioni predefinite del proprio fornitore. Il risultato misura quindi la concordanza con un riferimento prodotto da modelli, all’interno di un processo definito. Non equivale all’accuratezza rispetto a esiti reali etichettati in modo indipendente.
Per capire l’ordine di grandezza della tariffa, prendiamo un calcolo illustrativo: un milione di chiamate da mille token in ingresso ciascuna equivale a un miliardo di token, ossia 42 USD alla tariffa pubblicata. Quei mille token devono contenere sia il contesto sia le domande. Il calcolo esclude nuovi tentativi, altri modelli, infrastruttura e revisione umana.
Nella scelta di un sistema, è più utile il costo per ticket gestito correttamente. Una chiamata economica aiuta poco se una parte consistente dei risultati richiede una correzione umana.
Dove è utile Jev e dove serve un altro strumento
Le decisioni ripetitive su un testo sono un buon punto di partenza: riconoscere il tema di una richiesta, valutare la corrispondenza con una descrizione o scegliere una categoria. Il passo successivo dipende da ciò che il sistema deve fare del risultato.
Nel caso dell’errore di esportazione, Jev può valutare il contenuto del reclamo. Verificare la disponibilità del servizio, calcolare una scadenza prevista dallo SLA e cambiare lo stato del ticket rimangono normali operazioni software. L’email al cliente può essere composta con un modello di testo o scritta da un’IA generativa, fornendole fatti verificati e l’azione scelta.
Questa ripartizione rispecchia i limiti di Jev 1.13 descritti da TypeSafe. Il modello non è affidabile nei conteggi precisi e nel confronto tra date; le informazioni irrilevanti in un contesto lungo peggiorano le risposte. Un testo appositamente costruito può influenzare la classificazione. Lo sviluppatore consiglia di mantenere i calcoli nel codice, eliminare il contesto irrilevante e provare i casi difficili.
Per un prodotto in italiano, prepara un insieme di test in italiano. La documentazione indica l’inglese come lingua principale di addestramento e quella con la migliore accuratezza attuale; le prestazioni nelle altre lingue possono variare. È un aspetto essenziale se i ticket contengono abbreviazioni, refusi e terminologia specialistica.
Come avviare una prova nel tuo prodotto
Scegli una decisione frequente con un esito corretto ben definito, per esempio assegnare i ticket ai reparti. Conserva il processo attuale come riferimento. Etichetta esempi reali e anonimizzati, inclusi quelli ambigui, separando i dati usati per la messa a punto dall’insieme di valutazione finale.
Osserva insieme la quota di ticket gestiti automaticamente e il tasso di errore all’interno di quella quota. Una soglia che invia quasi tutto a una persona può offrire un’ottima accuratezza senza automatizzare molto. Una soglia più permissiva va valutata tenendo conto del costo delle correzioni.
Aggiungi la latenza p95, il tempo entro cui termina il 95% delle richieste misurate, la spesa per il modello e il carico di lavoro manuale. Confronta Jev con il processo attuale e un LLM adatto usando gli stessi esempi. L’adattatore di TypeSafe offre modalità per restituire probabilità o decisioni discrete: scegli condizioni di confronto coerenti con le esigenze effettive dell’applicazione.
Conserva la versione del modello, le domande e le soglie insieme ai risultati. L’alias jev-latest può passare a una nuova versione; la documentazione consiglia di fissare un identificativo preciso quando il comportamento è già stato messo a punto per quella versione.
L’idea tecnica di Jev è chiara: trasformare una valutazione del significato in un passaggio piccolo e osservabile di un programma. Provala dove questi passaggi sono frequenti e il gruppo di lavoro sa definire con precisione un errore. Il test mostrerà così quali decisioni possono essere automatizzate e quanta incertezza resta fuori da quell’automazione.
Articolo basato su fonti primarie pubbliche verificate il 27 settembre 2026. Esempi e schemi hanno scopo illustrativo. Non sono state effettuate chiamate API né prove indipendenti di Jev.