jev-latest

Jev è il modello di punta di TypeSafe e il primo modello della nuova classe System One. Non scrive testo, ma prende rapidamente decisioni utilizzabili subito da un programma: si forniscono uno stato (state), testo o JSON, e un insieme di domande, ricevendo valori tipizzati con probabilità calibrate.

I modelli linguistici scrivono parole per le persone; secondo TypeSafe, Jev è più vicino al codice: la risposta arriva subito nella forma richiesta dal codice, ad alta velocità e senza valori al di fuori delle opzioni definite. Il modello è progettato per dare risposte stabili quando le richieste vengono ripetute.

Come System One si distingue da un modello linguistico

• Non genera. Jev non scrive risposte all'utente, non scrive codice e non spiega il percorso del ragionamento. Le risposte possibili vengono definite dall'utente tramite uno dei tre tipi di domanda.
• È addestrato a decisioni calibrate. TypeSafe addestra il modello con RLCD (Reinforcement Learning for Calibrated Decisions): le probabilità vengono adattate agli esiti reali e rispecchiano l'incertezza. Tra molte risposte con probabilità 0,8, circa l'80% dovrebbe risultare corretto. La calibrazione è una proprietà di un campione ampio, non una garanzia di correttezza di una singola risposta.
• Ha un altro obiettivo di addestramento. I modelli di chat vengono addestrati a piacere alle persone (RLHF) e, secondo le osservazioni di TypeSafe, questo incoraggia accondiscendenza ed errori espressi con sicurezza. Uno dei coautori di RLHF, Diogo Almeida, è cofondatore di TypeSafe.

Il nome richiama il «Sistema 1» del libro di Daniel Kahneman «Pensieri lenti e veloci»: il giudizio intuitivo rapido contrapposto al pensiero lento e deliberato del «Sistema 2». Jev è stato creato per giudizi rapidi e circoscritti.

Tre tipi di domanda

Una domanda è un singolo giudizio sullo stato; la risposta è un valore che il codice confronta con una soglia, ordina o trasmette al passaggio successivo.

1. Choice — scelta di un'opzione. Reparto per una richiesta, categoria di un prodotto, lingua di un frammento di codice. Le opzioni sono un dizionario «opzione → descrizione», fino a 255 voci. La risposta comprende il choice scelto, le probabilities di tutte le opzioni, con somma 1, e la confidenza confidence. Se l'elenco può non coprire tutti i casi, aggiungere «altro» o «nessuna delle opzioni».
2. Score — valutazione su una scala. Posizione su una scala ordinata descritta dall'utente: gravità di un errore, irritazione del cliente, livello di una competenza. Da 2 a 10 livelli, dal più basso al più alto; il modello valuta ogni livello separatamente, senza vederne numero e livelli vicini. La risposta comprende score, somma dei numeri dei livelli moltiplicati per le rispettive probabilità, quindi il valore può cadere tra i livelli, legend con le descrizioni dei livelli, probabilities e confidence.
3. Noul — sì o no. Determina se un'affermazione è vera. La risposta noul è la probabilità del «sì», da 0 a 1: vicino a 1 indica un «sì» sicuro, vicino a 0 un «no» sicuro, vicino a 0,5 il modello è incerto. Non esiste un confidence separato: un solo numero descrive interamente la risposta. Il criteria facoltativo precisa cosa considerare «sì» e cosa «no».

Come scegliere: opzioni note senza ordine — choice; gradini di uno spettro — score; semplice «sì/no» in cui conta la probabilità stessa — noul. Noul 0,5 indica uguali probabilità di «sì» e «no», non un «livello medio»: il grado viene misurato da score. Tra due tipi adatti, scegliere quello su cui il codice agisce subito: choice per le diramazioni, score per la soglia, noul per if.

I tipi possono essere combinati in una sola richiesta. La risposta è sempre limitata alle opzioni definite e non dipende dalle altre domande: si possono aggiungere e rimuovere domande senza modificare le altre risposte.

Stato

Lo stato è ciò che il modello valuta: messaggio di un cliente, segmento di documento, record di una base di dati o stato dell'applicazione.

• Stringa, quando c'è un unico testo: messaggio, articolo o estratto.
• Oggetto, per campi nominati, record collegati o stato dell'applicazione. TypeSafe consiglia un oggetto per la maggior parte delle richieste: ogni parte ha un nome comprensibile.
• Array, per una sequenza di messaggi o record.

Prepararlo come materiale per esperti: includere insieme conversazione, ordine e regole dei resi se la decisione richiede di confrontarli. Conservare il contenuto nello stato e i giudizi nelle domande. Se una domanda riguarda una parte dello stato, indicarne il percorso tra backtick nella domanda, per esempio ticket.messages[0].text.

Come formulare le domande

• Un giudizio rapido per domanda. Una buona domanda è quella a cui una persona competente, con il contesto necessario, risponde in un secondo: «Il messaggio esprime urgenza?». «Analizza il messaggio e decidi cosa fare» è già ragionamento lento e va diviso in domande semplici.
• L'intera domanda in instructions. La chiave della domanda, per esempio refund_requested, serve soltanto al codice e non viene trasmessa al modello.
• Tutte le domande sullo stesso stato in una richiesta. Il modello le valuta in parallelo: secondo TypeSafe, le domande aggiuntive aumentano pochissimo il tempo di risposta e costano soltanto i propri token. Una domanda «per ogni eventualità» costa quasi nulla; il codice decide quali risposte servono.
• Un giudizio complesso diviso in parti. Invece di «valuta la candidatura della startup», chiedere separatamente dimensione del mercato, fattibilità tecnica e differenze dai concorrenti, poi calcolare il risultato nel codice con pesi. Se cambiano le priorità, cambiare i pesi, non riscrivere la domanda.
• Domande dipendenti in una seconda richiesta. Le risposte della stessa richiesta non costituiscono contesto l'una per l'altra. Una seconda richiesta serve soltanto quando non può essere costruita senza la prima risposta: occorre caricare dati oppure scegliere opzioni per la domanda successiva.
• Una domanda lunga come oggetto. instructions e criteria sono normalmente stringhe, ma possono essere un oggetto o un array: la domanda in un campo, i dati in altri. È utile per confrontare un curriculum con i record di una base di dati mediante una sola domanda.

Confidenza

Per choice e score, confidence da 0 a 1 mostra quanto la probabilità sia concentrata su una risposta: 1 significa tutta su una sola opzione, 0 ugualmente distribuita su tutte. Per score, un livello vicino riduce la confidenza meno di uno distante. Per noul, la confidenza è il valore stesso: più è distante da 0,5, più la risposta è sicura.

TypeSafe consiglia tre intervalli:

1. Confidenza alta, agire automaticamente.
2. Media, agire con cautela, per esempio chiedendo conferma all'utente.
3. Bassa, affidare il caso a una persona, precisare la richiesta o collegare un percorso alternativo, per esempio un modello di ragionamento più potente.

Più un errore costa, più la soglia deve essere rigorosa: per azioni irreversibili deve essere più alta che per la lettura. La risposta indica cosa scegliere, la confidenza se conviene agire. Le soglie vanno scelte sui propri dati, confrontando confidenza e precisione.

Come costruire un sistema attorno a Jev

Jev non è pensato per agenti che scelgono da soli il passaggio successivo e possono deviare a ogni ciclo, ma per programmi in cui il codice controlla il processo e il modello risponde a domande semantiche circoscritte. Otto passaggi di progettazione secondo TypeSafe:

1. Fare con il codice tutto ciò che si può fare con il codice: in modo affidabile ed economico.
2. Nello stato soltanto ciò che serve alle domande correnti; fatti aggiornati dalla propria base di conoscenza, non dalla memoria del modello.
3. Struttura nello stato: JSON annidato e, nella domanda, il percorso al campo necessario tra backtick, se riduce l'ambiguità.
4. Domande il più possibile circoscritte e concrete: secondo TypeSafe, forse la regola principale; una domanda ampia nasconde più giudizi dietro una sola risposta.
5. Struttura nelle domande: la domanda stessa breve; spiegazioni, esempi e valori della propria base di dati in campi vicini dell'oggetto instructions o criteria, non in un'unica stringa lunga.
6. Molte domande indipendenti sullo stesso stato in una richiesta: più utilità per ogni dollaro.
7. Il codice unisce le risposte tramite regole, somma ponderata oppure come caratteristiche per un modello classico di apprendimento automatico.
8. Diramazione in base alla confidenza: casi incerti a una persona o a un modello di ragionamento.

Jev non è una chat né un modello di completamento del codice e non può sostituire un modello linguistico in un agente di programmazione. Un agente può però scrivere il codice che chiama Jev dove serve una risposta rapida e calibrata.

Dove viene utilizzato

• Automazione in background, decisioni eseguite un milione di volte senza una persona presente.
• Tempo reale, secondo TypeSafe, la maggior parte delle richieste viene eseguita in circa 100 ms: sufficiente per elaborazione immediata e interfacce.
• Grandi dati, ricerca in corpus enormi, annotazione dei log di lavoro degli agenti e caratteristiche per previsioni.
• Verifica di altri modelli, richieste, estrazioni, ragionamenti e chiamate di strumenti: aggiramento dei limiti, errori nelle citazioni e invenzioni.
• Ricerca e ranking, rilevanza della coppia «richiesta — candidato», riordinamento e selezione del contesto.
• Diramazione per intento, cosa vuole l'utente e quale gestore serve: logica semplice, modello specialistico o persona; tema, complessità e rischio determinano a quale modello linguistico affidare la richiesta.
• Verifiche di protezione, input, output e chiamate di strumenti del modello linguistico: istruzioni iniettate, violazioni delle regole e fuga di dati personali.
• Supporto, tema e intento della richiesta, urgenza, irritazione, rischio di abbandono, richiesta di rimborso e coda.
• Moderazione, secondo le regole della piattaforma: tossicità, molestie, spam, frodi, consigli pericolosi e dati personali; in base a gravità e confidenza, consentire, avvertire, verificare o bloccare.
• Settori, sinistri assicurativi, indagini finanziarie e KYC, contratti e pubblicità, schede di prodotti, selezione del personale, lead, giochi, rischi, previsione della domanda, grafi di conoscenza, rassegne scientifiche e verifiche semantiche del codice nella CI.

Caratteristiche

• jev-latest è l'alias dell'ultima versione stabile, attualmente Jev 1.13; la versione che ha risposto compare nel campo model, per esempio jev-1.13.0. Con una nuova versione l'alias passa a essa e le risposte possono cambiare senza modifiche da parte dell'utente: monitorare il campo se le soglie sono state scelte per una versione.
• Contesto, 64K token per richiesta: stato e tutte le domande insieme; stato con la domanda più lunga fino a 32K. Il modello legge lo stato una volta e verifica tutte le domande su di esso in parallelo.
• Input, soltanto testo: stringa, oggetto JSON o array di testi. Immagini, audio e video non sono ancora supportati: convertirli prima in testo.
• Lingua, la lingua principale dell'addestramento è l'inglese e attualmente è quella con la precisione maggiore. Il modello accetta altre lingue, tra cui cinese, giapponese e coreano, ma con precisione inferiore: verificare sui propri dati.
• Prezzi e fatturazione in Ailoot API — le condizioni dipendono dal metodo scelto e sono indicate nella relativa scheda.
• Personalizzazione, Jev non viene ulteriormente addestrato sui dati del cliente: i propri materiali vanno in state, le regole dell'ambito in instructions e criteria.
• Dati, TypeSafe dichiara che Jev non viene addestrato su richieste e risposte dei clienti.

Limiti noti di Jev 1.13

TypeSafe elenca apertamente i limiti della versione corrente e promette di correggerne molti nelle successive. Il modello è rapido, calibrato e dà buoni giudizi di buon senso, ma:

1. Legge letteralmente. Risponde alla domanda scritta, non a quella implicita: precisazioni, negazioni e condizioni non esplicite vengono interpretate letteralmente. Scrivere condizioni esatte e casi limite in criteria; dividere un'interpretazione inevitabile in due domande letterali.
2. Non è una calcolatrice. Il conteggio di caratteri, ripetizioni ed elementi di un elenco è inaffidabile e l'errore cresce con le dimensioni: contare nel codice, con una domanda per candidato. Il modello comprende colori in hex o RGB meno bene dei nomi. score è adatto a una soglia, non a un numero esatto tra i livelli.
3. Date e tempi. Quale data preceda un'altra, quanto tempo intercorra e se una data rientri in un periodo sono valutazioni inaffidabili, soprattutto con formati misti e date relative. Estrarre le parti della data tramite choice, con l'opzione «non indicato», e confrontarle nel codice.
4. Formulazioni indirette. Doppie negazioni e domande su una proprietà di una proprietà riducono la precisione. Scrivere direttamente e chiamare per nome le parti dello stato.
5. Elementi superflui nello stato. Testo estraneo riduce la precisione. Filtrare nel codice oppure, se non è possibile, scartare ciò che è irrilevante con domande noul.
6. Testo ostile. Per impostazione predefinita il modello non si aspetta insidie nello stato: un'istruzione iniettata o un testo che contesta la propria classificazione può spostare la risposta. Scrivere criteri precisi e verificare i casi limite prima dell'avvio.
7. Contraddizioni. Se instructions e criteria chiedono cose diverse, per esempio descrivendo il «sì» di noul come «no», la precisione diminuisce. I criteri sono una continuazione della domanda.
8. Ordine delle opzioni. Talvolta il modello tende alla prima opzione di choice. Riordinare le opzioni e verificare che la risposta non cambi.
9. Generazione. Jev non è stato addestrato a scrivere testo. Per estrarre dati, trovare i candidati con un'espressione regolare o un modello generativo e lasciare a Jev la scelta corretta tramite choice.