Jev è il primo modello System One di TypeSafe AI, progettato per applicazioni che necessitano di decisioni strutturate piuttosto che di prosa generata. Valuta le informazioni fornite rispetto a domande chiaramente definite e restituisce risposte tipizzate, distribuzioni di probabilità e, ove applicabile, punteggi di confidenza.
A differenza di un modello linguistico di grandi dimensioni convenzionale, Jev non è pensato per chattare, scrivere codice o creare contenuti lunghi. Il suo scopo è formulare giudizi delimitati che il software possa utilizzare immediatamente per classificazione, instradamento, scoring, verifica, prioritizzazione e controllo del flusso di lavoro.
Le informazioni sul modello sono state riviste il 21 settembre 2026.
Specifiche tecniche di Jev
| Specifica | Dettagli |
|---|---|
| Sviluppatore | TypeSafe AI |
| Famiglia di modelli | System One |
| Versione stabile corrente | Jev 1.13 |
| ID modello versionato | jev-1.13.0 |
| Alias stabile | jev-latest |
| Input | Testo, oggetti JSON o array di valori di testo |
| Output | Decisioni tipizzate e distribuzioni di probabilità |
| Tipi di domanda | Choice, Score e Noul |
| Limite di contesto | 64,000 token per richiesta |
| Vincolo aggiuntivo di contesto | 32,000 token per lo stato più la domanda più lunga |
| Prezzo pubblicato per l'input | $0.042 per milione di token |
| Prezzo pubblicato per l'output | Gratuito |
| Limiti di velocità pubblicati | 250,000 token al secondo e 1,200 richieste al minuto |
| Lingua primaria | inglese |
| Input multimodale diretto | Non supportato |
Prezzi, alias e limiti di velocità possono cambiare. Gli sviluppatori dovrebbero verificare le informazioni più recenti prima di spostare un carico di lavoro in produzione.
Che cos'è Jev?
Jev è un modello di decisione sviluppato da TypeSafe AI. Invece di generare una sequenza aperta di token, seleziona valori da spazi di risposta definiti dallo sviluppatore.
Una richiesta Jev contiene due componenti principali:
- Stato: le informazioni che il modello deve valutare, come un ticket di supporto, un record di transazione, una traccia di agente, una descrizione di prodotto o uno stato applicativo in formato JSON.
- Domande: definizioni tipizzate dei giudizi che devono essere formulati su quello stato.
Le risposte risultanti sono destinate all’uso diretto da parte del software. Un’applicazione può ramificare il flusso in base a una categoria selezionata, confrontare i punteggi, analizzare le probabilità, applicare una soglia di confidenza o inviare un caso incerto a un revisore umano.
Jev funge quindi da livello decisionale probabilistico tra i dati applicativi e la logica aziendale deterministica. Gestisce giudizi difficili da esprimere tramite regole fisse, consentendo al codice applicativo di mantenere il controllo su soglie, autorizzazioni e azioni.
Come funziona Jev
Tre primitive decisionali
Jev supporta tre tipi di domanda progettati per diverse tipologie di decisioni software.
Choice seleziona un’opzione da un insieme predefinito. È adatto a compiti come classificazione dell’intento, instradamento dei ticket, categorizzazione delle policy e selezione del modello. La risposta include l’opzione selezionata, la probabilità assegnata a ciascuna opzione e un punteggio di confidenza.
Score valuta lo stato rispetto a una scala ordinata. Può misurare qualità come urgenza, rischio, rilevanza, frustrazione o qualità dei contenuti. La risposta include un punteggio, le probabilità per ciascun livello della scala e un punteggio di confidenza.
Noul stima la probabilità che un’affermazione sia vera. Restituisce un valore tra 0 e 1 ed è utile per verifica, controlli di policy, decisioni di idoneità e gate di completamento. A differenza di Choice e Score, Noul non restituisce un campo di confidenza separato perché il suo output è già una probabilità.
Valutazione parallela delle domande
Una singola richiesta può contenere più domande Choice, Score e Noul. Jev le valuta in modo indipendente e in parallelo sullo stesso stato.
Ad esempio, una piattaforma di supporto può classificare un ticket, valutarne l’urgenza e stimare se sia necessario un escalation umana in un’unica richiesta. TypeSafe afferma che aggiungere domande indipendenti ha scarso effetto sul tempo di risposta.
Le domande all’interno della stessa richiesta non possono dipendere dalle risposte delle altre. Le decisioni sequenziali dovrebbero essere implementate tramite chiamate separate collegate dalla logica applicativa.
Risposte type-safe
Le possibili strutture di risposta di Jev sono definite prima dell’inferenza. Ciò impedisce che compaiano JSON malformati, campi imprevisti e testo esplicativo laddove è richiesta una categoria o un valore numerico.
La sicurezza dei tipi garantisce solo il formato della risposta. Jev può comunque restituire una decisione valida ma errata, quindi i team di produzione devono valutarne l’accuratezza usando dati rappresentativi.
Probabilità e confidenza esplicite
Choice e Score espongono la distribuzione di probabilità alla base di ciascuna risposta. Il loro valore di confidenza riassume quanto quella distribuzione favorisca un esito rispetto agli altri.
Le applicazioni possono usare la confidenza per automatizzare decisioni chiare, richiedere conferma quando l’incertezza è moderata e instradare i casi ambigui a un essere umano o a un modello di fallback.
La soglia appropriata dipende dal rischio. Etichettare un ticket di supporto può tollerare maggiore incertezza rispetto ad approvare una transazione o eseguire un’azione irreversibile.
Inferenza a bassa latenza
TypeSafe riporta tempi di risposta end-to-end di circa 70–500 millisecondi. Ciò rende Jev adatto a instradamento interattivo, controlli ripetuti da parte di agenti e altri flussi di lavoro ricchi di decisioni in cui una chiamata a un modello generativo più lenta potrebbe influire sulla reattività.
La latenza effettiva dipende dalla dimensione dello stato, dal carico del servizio, dalle condizioni di rete e dalla regione di distribuzione.
Personalizzazione a livello di richiesta
Jev non è personalizzato tramite fine-tuning specifico per account o adapter LoRA. Gli sviluppatori lo adattano fornendo lo stato rilevante, scrivendo istruzioni precise, definendo criteri chiari e combinando decisioni atomiche nel codice applicativo.
Questo approccio mantiene visibili le regole di business e consente ai team di modificare la logica del flusso di lavoro senza riaddestrare il modello.
Modelli versionati e alias stabili
TypeSafe fornisce ID modello fissi e alias mobili. jev-1.13.0 identifica una release specifica, mentre jev-latest punta all’ultima versione stabile. jev-preview può passare a una nuova release di anteprima quando disponibile.
Gli alias semplificano la sperimentazione, ma il loro comportamento può cambiare dopo un aggiornamento. Le applicazioni in produzione con soglie calibrate dovrebbero fissare una versione testata e registrare l’ID modello restituito con ogni risposta.
Prestazioni di benchmark di Jev
Jev non è progettato per benchmark generici focalizzati su scrittura, coding, derivazioni matematiche o ragionamento di lungo respiro. Misure più rilevanti includono qualità della decisione, calibrazione delle probabilità, latenza, costo e affidabilità dell’output.
TypeSafe riporta:
- Tempi di risposta end-to-end di 70–500 millisecondi
- Esecuzione circa 40–200× più veloce su compiti System One comparabili
- Risultati di picco del flusso di lavoro di velocità superiore di 193.6×
- Miglioramenti di costo di picco riportati di 444.6×
Questi sono risultati riportati dal fornitore e non dovrebbero essere considerati garanzie di prestazioni universali. Le valutazioni del flusso di lavoro di TypeSafe confrontano i modelli su grafi decisionali strutturati e usano le previsioni medie di modelli esterni di fascia alta selezionati come probabilità di riferimento.
TypeSafe riconosce inoltre che membri del suo team delle capacità del modello hanno creato i flussi di lavoro valutati, il che può introdurre bias. I guadagni riportati sono probabilmente più vicini all’estremo superiore di quanto le applicazioni possano osservare.
Jev vs LLM a output strutturato vs Classificatore classico vs Motore di regole
| Dimensione | Jev | LLM a output strutturato | Classificatore classico | Motore di regole |
|---|---|---|---|---|
| Funzione primaria | Decisioni probabilistiche delimitate | Generazione con una risposta strutturata | Predizione per un task addestrato | Logica deterministica |
| Spazio delle risposte | Definito in ogni richiesta | Vincolato tramite uno schema | Fisso durante l’addestramento | Fisso nel codice |
| Incertezza | Probabilità e confidenza native | Dipende dal modello e dal metodo | Spesso disponibili ma possono richiedere calibrazione | Non probabilistico per impostazione predefinita |
| Struttura dell’output | Garantita per le primitive supportate | Di solito richiede generazione vincolata e validazione | Fissata dall’implementazione | Fissata dall’implementazione |
| Configurazione nuovo task | Definire stato, domande e criteri | Creare un prompt e uno schema | Raccogliere dati etichettati e addestrare un modello | Scrivere condizioni esplicite |
| Generazione aperta | No | Sì | No | No |
| Ragionamento esteso | Non è il suo carico target | Supportato dai modelli più capaci | No | Limitato alla logica codificata |
| Adattamento | Istruzioni e criteri a livello di richiesta | Modifiche di prompt e contesto | Riaddestramento o feature engineering | Modifiche al codice |
| Miglior corrispondenza | Giudizio ad alto volume all’interno del software | Attività che combinano ragionamento e generazione | Predizioni stabili, ristrette e ricche di dati | Condizioni esplicite e stabili |
Jev è più utile quando le regole fisse sono troppo fragili, creare un classificatore dedicato sarebbe costoso e l’applicazione non necessita di testo generato.
Un LLM tradizionale rimane la scelta migliore quando un compito richiede ricerca, spiegazione, creazione di contenuti, pianificazione o ragionamento multi-step. Un motore di regole rimane preferibile quando la condizione corretta è già esplicita e deterministica.
Casi d’uso consigliati
Jev è più adatto a decisioni frequenti con uno spazio di risposta predefinito.
- Instradamento e triage: classificare le richieste, selezionare code o strumenti e dare priorità ai casi urgenti.
- Controllo degli agenti: verificare il completamento dei task, valutare le azioni proposte e identificare i casi che richiedono conferma.
- Valutazione degli LLM: valutare rilevanza, supporto delle evidenze, conformità alle policy o qualità della risposta.
- Moderazione: categorizzare le violazioni delle policy, valutare la gravità ed eseguire escalation dei casi incerti.
- Arricchimento dei dati: convertire messaggi, recensioni, lead e record in categorie, punteggi e caratteristiche di probabilità.
- Decisioni in tempo reale: supportare comportamenti applicativi a bassa latenza quando una risposta generativa completa non è necessaria.
Limitazioni di Jev
Jev è intenzionalmente specializzato e il suo design mirato comporta diverse importanti limitazioni.
- Non può generare prosa, codice, riassunti o risposte conversazionali.
- Non è pensato per ricerca estesa o ragionamento multi-step.
- Un output type-safe non garantisce una decisione di business corretta.
- Immagini, audio, video e file binari devono essere convertiti in testo o dati strutturati prima dell’invio.
- L’inglese è la lingua documentata più solida.
- I carichi di lavoro non in inglese e CJK richiedono una valutazione indipendente.
- Le domande all’interno di una richiesta vengono valutate in modo indipendente.
- Il modello non può costruire una catena di ragionamento sequenziale attraverso quelle domande.
- TypeSafe non ha divulgato il numero di parametri del modello né rilasciato i suoi pesi.
- La personalizzazione viene eseguita tramite la richiesta piuttosto che tramite fine-tuning specifico per cliente.
- I miglioramenti di prestazioni pubblicati provengono dal framework di valutazione di TypeSafe.
- Gli alias mobili possono introdurre cambiamenti comportamentali senza una modifica al codice dell’applicazione.
Jev non dovrebbe sostituire codice deterministico per autorizzazioni, calcoli finanziari, requisiti legali, limiti di dimensione dei file o politiche di azioni irreversibili. I modelli probabilistici sono utili per giudizi incerti, non per condizioni che il software può già valutare esattamente.
In che modo CometAPI fornisce accesso all’API di Jev?
Jev non è attualmente disponibile nel catalogo pubblico dei modelli di CometAPI. CometAPI prevede di valutare e integrare Jev non appena l’accesso al modello sarà disponibile e verranno aperte le autorizzazioni di connessione richieste.
Dopo l’integrazione, gli sviluppatori potranno consultare la directory dei modelli di CometAPI e la documentazione API per l’ID modello supportato, il formato della richiesta, i prezzi, i limiti di velocità e la disponibilità degli endpoint.
Fino a quando l’integrazione non sarà annunciata ufficialmente, gli sviluppatori dovrebbero utilizzare la console di TypeSafe, la sua API nativa o gli SDK ufficiali per accedere a Jev. Un’integrazione con CometAPI dovrebbe essere considerata disponibile solo dopo che Jev compare nel catalogo pubblico dei modelli con informazioni API verificate.