Autori: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev è un modello progettato per prendere decisioni tipizzate. Gli invii un contesto insieme a un set fisso di domande e opzioni, e lui restituisce scelte, punteggi e probabilità invece di generare testo. È un modello "System One"!
Ma la classificazione non è una novità, e non lo sono nemmeno gli output strutturati, i modelli piccoli o la lettura delle probabilità dai logits. Questa storia spiega in parte le reazioni contrastanti a Jev...
Gli scettici hanno le loro ragioni, ma Jev ha un ruolo concreto in questo ecosistema. Per capirne di più, dobbiamo mappare l'intero spazio delle soluzioni.
Quali sono le alternative?
Quando un sistema ha bisogno di un'etichetta, di un punteggio o di una risposta sì/no, ci sono quattro opzioni ragionevoli:
Approccio
Perché usarlo
Compromesso
Un LLM generalista
Zero-shot, flessibile, può anche generare argomentazioni o spiegazioni. Potenzialmente dotato di un'"intelligenza superiore" grazie al compute in fase di inferenza (ragionamento).
Paghi latenza e costi da modello autoregressivo per una decisione minima
Un classificatore zero-shot open source
Economico, locale e controllabile
Qualità variabile; sei tu a gestire la selezione del modello e il serving
Un classificatore fine-tuned
Di solito la scelta migliore per task stabili ad alto volume con etichette di qualità
Raccolta dati, training, deployment, drift e una tassonomia meno flessibile
Jev
Flessibilità zero-shot dietro un'API hosted pulita
Qualità dipendente dal task, nessun testo generato e dipendenza dal provider
Il punto forte di Jev: un team può cambiare domanda e opzioni senza dover raccogliere un nuovo dataset di training, evitando al contempo il lavoro necessario per servire bene un modello. Nessuno dovrebbe storcere il naso davanti a questo. "Potremmo costruircelo da soli" vale per quasi tutti i prodotti infrastrutturali.
Le riproduzioni open source ridimensionano la pretesa di assoluta novità. Implementazioni basate su Qwen e SGLang, DiffusionGemma e vLLM e Kev ricreano gran parte dell'API o della struttura del modello.
85,7% per Jev e 79,6% per Kev-8B su n=764
Anche i test esterni di Parallel hanno confermato che Jev regge il confronto nel reranking, mentre i modelli specializzati hanno comunque vinto in due task di classificazione.
Cosa abbiamo osservato in Glean
Resta quindi una domanda pratica: quando la combinazione tra flessibilità zero-shot e inferenza hosted di Jev batte davvero le alternative? In Glean abbiamo testato quattro decisioni vincolate per cui avevamo già una baseline, così da poter confrontare la qualità reale in ambito enterprise. La maggior parte di queste baseline si basa su sistemi LLM, quindi per quegli esperimenti sapevamo di aspettarci miglioramenti di due ordini di grandine su costi e latenza. I risultati sono andati da nettamente peggiori rispetto alla produzione a contemporaneamente più veloci e più accurati di un router basato su LLM.
Classificazione delle query
La classificazione delle query mappa una richiesta a un task generico utilizzato dai sistemi a valle. È un workload naturale per Jev perché, sebbene a livello di singola richiesta lo spazio delle etichette sia noto in anticipo, la tassonomia può cambiare più velocemente di quanto un classificatore fine-tuned riesca a essere riaddestrato.
In questo esperimento ci siamo concentrati sul misurare la concordanza di Jev rispetto alle previsioni della nostra baseline in produzione, che è basata su LLM. Ci aspettavamo — e abbiamo osservato — un forte aumento del throughput offline con Jev, quindi riportiamo la concordanza come proxy semplice della qualità. Abbiamo anche usato come baseline Laya, un modello decisionale open-weight, e una versione fine-tuned di Laya. Questo fine-tuning ha richiesto poche ore in locale e il modello è abbastanza piccolo da girare sulla macchina di uno sviluppatore.
Esperimento
Concordanza sul Task Generico
Perf
Jev zero-shot
66,8%
~
12 min (concorrenza di 4
)
Laya base
35,9%
~
90 s (macchina di sviluppo locale)
Laya fine-tuned
74,5%
~
90 s (macchina di sviluppo locale)
Come modello pronto all'uso, comodo e che non richiede training, Jev supera chiaramente Laya, ma — cosa poco sorprendente — il fine-tuning fa brillare Laya, soprattutto guardando i numeri sulle performance. Il compromesso sta nello sforzo necessario per ottenere buone etichette e configurare il training. Jev resta probabilmente più interessante quando un task è nuovo o le sue etichette cambiano spesso.
Routing dei modelli: expert transfer
Il routing dei modelli è un problema affine alla classificazione delle query. Qui lo inquadriamo come expert transfer: il nostro sistema sceglie quale esperto/modello deve gestire la richiesta. Attualmente la nostra baseline in produzione chiede a un LLM di prendere questa decisione nativamente all'interno del loop agentico dell'harness. Se da un lato è un test naturale per capire se Jev possa sostituire una chiamata generativa con una decisione vincolata, dall'altro c'è un limite tecnico importante: in caso di non-transfer, Jev aggiunge inevitabilmente una chiamata. Al contrario, la baseline in produzione nei casi di non-transfer può avviare subito il tool-calling sfruttando quella stessa prima chiamata LLM.
Abbiamo usato una versione semplificata del nostro routing in produzione con soli 3 esperti, fatto passare 751 golden entry comparabili attraverso il router Jev aggiornato e confrontato il percorso scelto con quello del nostro router esistente basato su prompt (alimentato da un LLM tradizionale), misurando l'accuratezza rispetto alla golden label.
Abbiamo anche isolato 40 entry in cui il percorso esistente effettuava effettivamente una chiamata di expert transfer (n più piccolo) e confrontato la latenza di chiamata sulle stesse entry.
Lo speedup mediano per entry è stato di 8,1×. Finora è uno dei risultati interni più solidi per Jev: su questo task di routing vincolato, Jev è stato sia più accurato sia nettamente più veloce. L'entità del delta suggerisce che la "tassa" di blocco che paghiamo sulle richieste non instradate a un esperto potrebbe essere un compromesso accettabile. Ricordiamo che si tratta ancora di un confronto offline su golden set e che il campione di latenza contiene solo 40 transfer positivi, quindi c'è ancora molto da deriskare e testare!
Reranking
Un tema particolarmente caro a Glean! Di seguito, la nostra baseline in produzione è l'ordine generato dallo stack di ricerca attuale di Glean. In questo esperimento abbiamo chiesto a Jev di riordinare fino a 50 risultati.
Abbiamo provato quattro modi per esprimere la rilevanza tramite gli output tipizzati di Jev:
Formulazione
Come esprime la rilevanza
Noul pointwise
Pone una domanda separata sì/no sulla rilevanza per ogni risultato, poi ordina in base alla probabilità del "sì".
Noul shared-state
Mostra a Jev l'intero set di candidati come contesto condiviso, poi pone la stessa domanda sì/no per ogni risultato.
Score
Chiede a Jev di assegnare a ogni candidato un punteggio numerico di rilevanza.
Choice
Tratta tutti i candidati come alternative in un'unica decisione, poi li classifica in base alle probabilità risultanti.
Abbiamo eseguito il test su un evalset interno in cui l'utente non ha accesso a tutti i canonical, quindi i valori assoluti non riflettono il nostro ranking in produzione – ma quelli relativi sono interessanti.
La formulazione "Choice" di Jev è stata la più efficace. Su un controllo appaiato di 4.855 query di ricerca registrate, rimosso il tie-breaking basato sulla produzione, il risultato è stato:
Jev Choice è costato circa $0,00044 per query e ha impiegato 0,195 secondi al p50 nel test offline. Tuttavia, ha assegnato punteggi identici a circa 37 dei 41 candidati in una query media. Usare l'ordine di produzione per risolvere quei pareggi ha portato la Recall@6 dal 40,2% al 44,3%, facendo sembrare il risultato non corretto più solido di quanto giustificassero i soli punteggi di Jev. Come sempre ci sono molte precisazioni da fare, ma nella sostanza Jev è una baseline economica ed efficiente, non un sostituto del ranker in produzione di Glean.
Valutazione del supporto delle citazioni
La valutazione delle citazioni risponde a due domande correlate: le affermazioni che richiedono prove hanno citazioni adeguate (citation recall), e le fonti citate supportano davvero le affermazioni a loro attribuite (citation precision)? A prima vista, poiché lo spazio di output/etichette è vincolato (come nella maggior parte dei contesti da giudice), sembra un caso d'uso perfetto per Jev. La rubrica però è complessa e potrebbe richiedere la scomposizione di diverse affermazioni; inoltre Jev non produce le motivazioni che usiamo spesso per l'analisi degli errori, quindi ci sono rischi sia per la qualità sia per l'usabilità.
Abbiamo testato Jev su una risposta reale da 1.448 parole usata nelle valutazioni in produzione, mantenendo fissi la risposta e le evidenze delle citazioni. Abbiamo confrontato il suo passaggio congiunto su precision e recall con GPT-5.6 Luna usando nessun ragionamento e ragionamento xhigh. Per ridurre la varianza, abbiamo eseguito ogni giudice tre volte.
Giudice
Tempo originale misurato per risposta
Costo originale misurato per risposta
Jev
6,6 s
$
0,014
GPT-5.6 Luna, nessun ragionamento
81,3–85,5 s
$
0,030–
$
0,047
GPT-5.6 Luna,
xhigh
227,4–259,7 s
$
0,047–
$
0,060
Nota: i tempi sono indicativi e non end-to-end: Jev riporta il wall time sequenziale del client, mentre per Luna abbiamo sommato le durate delle chiamate al modello. I costi includono la cache osservata.
Abbiamo anche confrontato la coerenza sugli stessi 28 paragrafi. Un elemento modificato significa che il giudice ha cambiato verdetto sull'adeguatezza della copertura delle citazioni di un paragrafo in almeno una delle tre esecuzioni con input identico. Il disaccordo a coppie conta ogni paragrafo nelle tre combinazioni di run, per 84 confronti per giudice.
Giudice
Paragrafi con verdetto di recall modificato
Disaccordi di recall a coppie
Jev
1 su 28 (3,6%)
2 su 84 (2,4%)
GPT-5.6 Luna, nessun ragionamento
7 su 28 (25,0%)
15 su 84 (17,9%)
GPT-5.6 Luna,
xhigh
5 su 28 (17,9%)
10 su 84 (11,9%)
L'unico cambiamento di Jev riguardava se un paragrafo dovesse essere considerato bisognoso di citazione; la sua categoria raw di recall non è cambiata. I verdetti di Jev sulla copertura delle citazioni a livello di paragrafo sono stati quindi più ripetibili rispetto a entrambe le configurazioni di Luna.
Non stiamo concludendo che questo renda Jev il giudice più accurato (i sistemi hanno applicato criteri di supporto e denominatori di punteggio diversi, e non abbiamo avuto tempo per etichettature umane indipendenti). Ma anche con il ragionamento xhigh (che ha circa triplicato il tempo di modello di Luna), quest'ultimo è rimasto meno coerente di Jev. Il risultato conferma Jev come un modo rapido, economico e relativamente ripetibile per implementare una policy ristretta sulle citazioni.
Conclusioni degli esperimenti e guida pratica
In alcuni casi, Jev brilla come alternativa a basso attrito sia agli LLM tradizionali sia ai classificatori fine-tuned. Quando la baseline è già forte (reranking), o quando è facile fare il fine-tuning di un modello più piccolo (classificazione delle query), il vantaggio si riduce. Ci sono segnali di una qualità superiore per alcuni task (routing dei modelli) e indicazioni di maggiore coerenza e stabilità (giudice delle citazioni). In alcuni dei nostri workload più importanti, offre i risparmi attesi su costi e latenza rispetto agli LLM tradizionali.
I risultati sopra danno ottime indicazioni di massima e in Glean siamo entusiasti di Jev. Dopo qualche altro passaggio (principalmente readiness operativa come data residency e garanzie), prevediamo di rilasciare Jev in alcuni di questi casi d'uso. Inoltre, Jev avrà un ruolo centrale nel nostro hackathon interno di questa settimana e non vediamo l'ora di condividere altri risultati!
Qualche consiglio generale per chiudere: se l'output può essere elencato in anticipo, fai un benchmark con Jev. Se il task e le etichette sono stabili e i volumi sono alti, metti a confronto anche un classificatore fine-tuned. Se la chiamata deve generare una query, una spiegazione o altro testo dinamico, mantieni un modello generativo nel loop. Il tool calling è un buon esempio: Jev può aiutare a scegliere un tool, ma la maggior parte dei tool di Glean ha comunque bisogno di argomenti generati dinamicamente (come le query di ricerca).
Jev non cambia il fatto che i classificatori esistessero già. Rende semplicemente molto più facile usare un buon classificatore zero-shot. Ed è un prodotto solido, anche se non rappresenta le nuove fondamenta per ogni sistema AI.
