RLCD spiegato: perché TypeSafe addestra Jev a essere onesto riguardo alla confidenza invece di essere apprezzato

Jev 1.13 (typesafe/jev-1.13) è addestrato con un metodo che il suo creatore chiama Reinforcement Learning for Calibrated Decisions — RLCD — e quell'acronimo è un conio di TypeSafe stesso, non un termine di settore che dovresti già conoscere. Il post di lancio lo dice esplicitamente: l'azienda ha creato «una nuova architettura di modello, un campionatore parallelo per la massima efficienza e un metodo di addestramento che chiamiamo Reinforcement Learning for Calibrated Decisions (RLCD)». È una terza risposta a una domanda che prima ne aveva due, e il motivo per cui esiste è un disallineamento in cui la maggior parte dei team si imbatte la prima volta che prova a mettere un modello linguistico dentro una decisione. Prima di arrivarci, due date contano, perché questa pagina non è un articolo di lancio. TypeSafe ha rilasciato il modello stesso il 2026-09-15, data che si colloca fuori dalla finestra di sette giorni a cui questo blog si riferisce, e nulla di quanto qui scritto va interpretato come se presentasse Jev come nuovo. L'evento datato è il 2026-09-24, quando OrcaRouter ha aggiunto typesafe/jev-1.13 al proprio catalogo e ha aperto la scheda del modello — la prima volta che Jev è richiamabile tramite un gateway di terze parti anziché solo attraverso l'endpoint di TypeSafe. Questo è il cambiamento su cui poggia questa pagina, e la conseguenza pratica è che la tecnica descritta di seguito ora è qualcosa che puoi provare nel codice con una chiave che potresti già avere, anziché un'idea di ricerca di cui hai letto.

Ciò che segue è il concetto, non il modello. Il primo terzo di questa pagina riguarda i due metodi di addestramento contro cui RLCD è stato progettato, perché RLCD è comprensibile solo come riparazione di ciò che quei due fanno quando il compito smette di essere una conversazione e diventa un giudizio. Se sai già che cosa ottimizzano RLHF e RLVR, la sezione che cerchi è la terza, dove la tabella a tre vie di TypeSafe fa il lavoro.

RLHF ottimizza per la risposta che una persona preferisce

Il reinforcement learning dal feedback umano è il metodo che ha trasformato i modelli linguistici preaddestrati in assistenti. Il primer di TypeSafe stesso afferma l'obiettivo in modo netto, in una scheda intitolata RLHF: ha "trasformato i modelli preaddestrati in chatbot. Addestra i modelli a produrre risposte che le persone preferiscono." InstructGPT e ChatGPT sono stati addestrati con esso, e il primer aggiunge un dettaglio che qui è rilevante per un motivo diverso — l'approccio è stato co-inventato da Diogo Almeida, che è cofondatore di TypeSafe e autore del post di lancio di Jev. L'azienda non sta liquidando il metodo: è stata fondata da qualcuno che ha contribuito a costruirlo. Sostiene che l'obiettivo sia sbagliato per un compito specifico.

Il modo più chiaro per vedere la discrepanza è chiedersi che cosa misura effettivamente il segnale di ricompensa. Con l'RLHF misura la preferenza di un valutatore tra due risposte candidate. È un ottimo proxy quando il prodotto è una conversazione, perché il criterio di successo di una conversazione è davvero se una persona trova buona la risposta. È un proxy inadeguato quando il prodotto è una decisione, perché lì il criterio di successo è se la confidenza dichiarata corrisponde alla realtà, e un valutatore che confronta due paragrafi plausibili non ha modo di vedere la differenza tra un 0,6 ben calibrato e un 0,95 dall'aria sicura. Due risposte possono essere ugualmente preferite e differire enormemente in quanto un software dovrebbe fidarsi di esse.

Le modalità di fallimento dei nomi di Type nel primer derivano direttamente da ciò:

• Sicofantia — il modello impara a produrre ciò che il valutatore vuole sentirsi dire, un obiettivo diverso da ciò che è vero.

• Allucinazione dal tono sicuro — la fluidità e la certezza vengono premiate dalle preferenze anche quando non sono supportate da nulla.

• Mode dropping — l'ottimizzazione delle preferenze restringe la distribuzione dell'output, "favorendo uno stile particolare, come l'aderenza alle istruzioni, riducendo al contempo la probabilità di altri output possibili". Il mode dropping è la versione lieve del classico fallimento di collasso della modalità che affligge le reti generative avversarie, in cui un generatore converge su un unico output che continua a ingannare il discriminatore.

Il paragrafo di avvertimento del primer stesso è la frase che vale la pena conservare: "Un output può essere convincente per una persona senza essere abbastanza affidabile per un'automazione non presidiata. La preferenza umana e l'affidabilità della macchina sono obiettivi di ottimizzazione diversi." Non è una critica all'RLHF come metodo. È l'osservazione che a un modello addestrato sulle preferenze non è mai stata posta la domanda a cui l'automazione ha bisogno di una risposta — quanto spesso, esattamente, questa cosa è corretta quando dice di essere sicura.

RLVR ottimizza per output che un programma può verificare — e le decisioni raramente ne hanno uno

L'apprendimento per rinforzo con ricompense verificabili è il secondo adattamento, ed è quello dietro i modelli di ragionamento. Il primer di TypeSafe descrive ciò che ha prodotto: modelli che «sono forti in compiti come la matematica, ma più lenti e più costosi». Il meccanismo è un verificatore. Se un compito ha una risposta che un programma può testare — uno unit test, un verificatore di dimostrazioni, una risposta numerica — allora è possibile calcolare una ricompensa senza chiedere nulla a un essere umano, e il modello può essere addestrato contro quel segnale su larga scala. Funziona, ed è per questo che i modelli di ragionamento sono diventati bravi esattamente nei domini in cui esiste una verifica automatica a basso costo.

Il limite è la forma di quella parola, «verificabile». Una ricompensa verificabile richiede un verificatore, e un verificatore richiede che il compito abbia una risposta giusta che qualcuno possa calcolare. Considera le domande che un sistema in produzione pone davvero. Questo ticket di assistenza deve andare alla fatturazione o al supporto tecnico? Questa richiesta di rimborso rientra nella policy? Questa transazione sembra una frode? Ognuna ha una risposta difendibile il più delle volte, nessuna ha una risposta che un programma possa verificare, e i casi che contano di più sono proprio quelli in cui esseri umani esperti non sono d'accordo. Non c'è alcuna funzione da eseguire. RLVR non ha nulla da premiare, quindi non contribuisce affatto.

La soluzione alternativa allettante è fabbricare un verificatore etichettando un dataset e addestrando sulle etichette. Questo dà al metodo qualcosa su cui masticare, ma cambia l'obiettivo in modo significativo. Le etichette codificano una decisione, non l'incertezza che la circonda. Un modello addestrato a riprodurre i giudizi di un team sui casi difficili impara ad avere la stessa sicurezza che avevano quelle etichette — il che equivale a dire, esattamente la stessa eccessiva sicurezza degli esseri umani che le hanno scritte. E anche laddove esista un verificatore autentico, c'è una seconda lacuna. Un verificatore valuta la risposta. Non valuta la confidenza dichiarata. Un modello che ha ragione sul 95% dei casi e riporta certezza su tutti ottiene una ricompensa perfetta ed è, come componente in una pipeline automatizzata, inutile — perché il 5% è l'unica parte di cui la pipeline aveva bisogno di essere informata. I materiali di lancio di TypeSafe sottolineano lo stesso punto dalla direzione opposta: "Se un modello è in grado di svolgere un compito il 95% delle volte ma non dice quando si trova nel 5%, non può automatizzare quel compito."

Che cosa fa RLCD, nella descrizione fornita da TypeSafe stessa

RLCD cambia il contratto di output piuttosto che la qualità della risposta. La scheda del primer recita: "L'apprendimento per rinforzo per decisioni calibrate addestra TypeSafe a restituire decisioni e probabilità calibrate invece di testo generato." La versione concisa del post di lancio è "decisioni calibrate: risposte con probabilità epistemicamente oneste su compiti di System One." Entrambi descrivono un'unica mossa: addestrare il modello in base a se la probabilità dichiarata corrispondeva alla frequenza con cui quella risposta si è rivelata corretta, piuttosto che in base a se una persona o un verificatore apprezzava la risposta.

Il post di lancio mette i tre metodi l'uno accanto all'altro, e il contrasto è la più chiara enunciazione dell'idea che esista. Leggilo come una serie di contrasti anziché come una tabella:

• Su che cosa ottimizza — RLHF ottimizza la preferenza umana, "scritti e risposte in chat che i valutatori umani preferiscono"; RLVR ottimizza "output che possono essere verificati programmaticamente"; RLCD ottimizza la calibrazione, "risposte con probabilità epistemicamente oneste su compiti del Sistema Uno."

• Cosa entra in ingresso — i due più vecchi ricevono dati non strutturati «con un'enfasi sui messaggi sequenziali»; un modello decisionale calibrato riceve dati non strutturati «con un'enfasi sullo stato strutturato del programma».

• Cosa viene fuori — stringhe generate che "devono essere analizzate + validate", con "sempre un certo rischio che l'IA deragli", rispetto a valori strutturati type-safe dove "i possibili output e la struttura sono definiti in anticipo", il modello "non commette mai errori di tipo", e "tutte le risposte sono accompagnate da probabilità calibrate e punteggi di confidenza."

• Come viene campionato — un token alla volta, ciascuno condizionato dall'ultimo, rispetto a tutti gli output generati in un'unica query. Questo è il motivo meccanico per cui il terzo metodo è economico: non c'è alcun ciclo di decodifica da pagare.

• Quanto costa — token di input da 0,20 $ a 10 $ per milione per i modelli di confronto, con un output all'incirca cinque volte il prezzo dell'input, contro 0,042 $ per milione di token di input e output fatturato a zero per Jev.

• Quanto è veloce a rispondere — da 3 a 329 secondi end-to-end per i modelli frontier rispetto a 70 ms fino a 500 ms, che il fornitore definisce come da 40x a 200x più veloce su query modellate su System One.

• Cosa dice sulla propria confidenza — i due più vecchi "tendono a essere troppo sicuri di sé e incoerenti" anche quando viene chiesto loro di fornire una stima di confidenza; RLCD "comunica sempre confidenza e incertezza con ogni output", dove "una confidenza più alta significa una maggiore accuratezza".

L'ultima riga è l'effettiva dichiarazione di prodotto, ed è falsificabile in un modo in cui le altre non lo sono. «Una confidenza più elevata significa un'accuratezza più elevata» è un'affermazione su una curva: raggruppa le risposte di un modello in base alla probabilità che vi ha associato, e i gruppi dovrebbero risultare corretti all'incirca alla frequenza dichiarata dalle probabilità. La documentazione sulla confidenza di TypeSafe esplicita il contratto con numeri insolitamente concreti:

• Gli esiti a cui viene assegnata una probabilità di 0,2 dovrebbero verificarsi circa il 20% delle volte.

• Gli esiti a cui viene assegnata una probabilità di 0,8 dovrebbero verificarsi circa l'80% delle volte.

• Gli esiti a cui viene assegnata una probabilità di 1,0 dovrebbero verificarsi il 100% delle volte.

E poi la frase che tiene onesta l'affermazione, nelle parole stesse del fornitore: «Questi valori descrivono gruppi di previsioni, non una garanzia su una singola risposta». Non è una cautela aggiunta per motivi legali. È l'intero significato della calibrazione. Un modello ben calibrato che dice 0,8 non promette di avere ragione questa volta; promette che su ogni risposta che ha etichettato 0,8, circa quattro su cinque erano corrette. Una singola risposta non ti dice nulla. Mille risposte nell'arco di una settimana ti dicono se la curva è reale.

Lo stesso contrasto a tre schede si trova nella documentazione di TypeSafe, che è la fonte del confronto qui sopra e il luogo più chiaro in cui verificare la formulazione invece di fidarsi della parola di un riassunto. L'istantanea qui sotto è quella pagina così com'è oggi: tre schede per i tre approcci post-training, con la terza che nomina RLCD per esteso.

Altri due dettagli nella documentazione del fornitore mostrano quanto in profondità il metodo arrivi nel prodotto. Il primo è che la confidenza è derivata anziché generata: il modello restituisce una distribuzione di probabilità completa su tutte le opzioni o i livelli che hai fornito, e il valore di confidenza è una statistica calcolata dalla forma di quella distribuzione. Ecco perché la documentazione può dirti che la definizione non ha funzione portante — in ogni caso ottieni la distribuzione grezza e puoi calcolare la tua statistica, se la tua si adatta meglio. Il secondo è che RLCD è l'unica cosa che plasma i pesi. La pagina dei modelli di TypeSafe afferma: «Jev non viene fine-tuned né adattato con LoRA utilizzando i dati dei clienti. Viene addestrato con RLCD per restituire decisioni calibrate, e gli stessi pesi servono ogni account.» L'adattamento al dominio avviene nella richiesta — il tuo stato, i tuoi criteri — non in un checkpoint per cliente. Qualunque calibrazione il metodo abbia prodotto è la calibrazione che ogni cliente riceve.

Perché la calibrazione è ciò che rende utilizzabile un modello decisionale economico

Una probabilità calibrata non è interessante di per sé. Diventa l'architettura nel momento in cui il tuo codice vi crea diramazioni, e la documentazione sulla confidence di TypeSafe descrive esattamente quel pattern come tre intervalli, ognuno dei quali produce un comportamento di sistema diverso.

• Alta confidenza — agisci automaticamente. Il modello ha una lettura chiara e puoi procedere senza coinvolgimento umano.

• Fiducia media — procedi con cautela. Il modello ha una risposta ragionevole ma non ne è certo, quindi verifica con l'utente, segnala per la revisione o raccogli ulteriori informazioni prima di agire.

• Bassa confidenza — non agire. Inoltra a una persona, richiedi chiarimenti o passa a un sistema diverso, perché il modello ti sta dicendo che non ha abbastanza elementi su cui basarsi.

La documentazione è esplicita sul fatto che i confini sono tuoi da tracciare e dovrebbero differire in base alle conseguenze: «Una soglia di confidenza non è un unico numero. Azioni diverse all'interno dello stesso sistema dovrebbero essere vincolate a livelli diversi a seconda delle conseguenze di un errore.» Il loro esempio pratico pone una soglia minima rigida a 0,5 — qualunque valore il modello riporti al di sotto di essa viene indirizzato a un essere umano senza ulteriori controlli — e poi applica uno standard più elevato per un'azione distruttiva rispetto a una di sola lettura. Il tuo codice codifica la tolleranza al rischio; il modello fornisce l'input onesto ad esso.

Quel pattern è l'intero argomento a favore di un flusso di lavoro a due modelli, e vale la pena enunciarlo come argomento anziché come elenco di funzionalità. Supponiamo che tu voglia una pipeline automatizzata che gestisca la maggioranza sicura dei casi e inoltri i restanti a un modello più grande o a una persona. La decisione di escalation deve pur venire da qualche parte. Se il modello economico riporta 0,98 su tutto, compresi i casi su cui sta tirando a indovinare, allora il ramo non ha nulla da testare e o automatizzi tutto — comprese le chiamate che avrebbe dovuto inoltrare — oppure non automatizzi nulla. Un modello la cui confidenza è informativa è l'unico tipo che ti consente di automatizzare un sottoinsieme in sicurezza, perché è l'unico tipo in grado di dirti su quale sottoinsieme non è sicuro. La documentazione esprime lo stesso concetto in una riga che vale la pena citare per la sua franchezza: "Se un sistema intelligente, umano o artificiale, non è in grado di esprimere un'incertezza onesta, non ci si può fidare di quel sistema."

C'è una seconda ragione per cui questo conta più per un modello economico che per uno costoso, ed è la ragione per cui la storia del routing e la storia di RLCD sono la stessa storia. Un modello al prezzo di $0,042 per milione di token di input, senza alcun costo per l'output, è abbastanza economico da essere consultato costantemente — a ogni turno del loop di un agente, su ogni record di un batch, su ogni ticket nel momento in cui arriva. Essere consultato costantemente è esattamente la situazione in cui gli errori di un modello si accumulano, perché nessuno legge il suo output prima che si agisca su di esso. La confidenza è ciò che rende sicura questa cosa. L'economicità è ciò che rende sostenibile il ramo di escalation, dato che il percorso costoso viene eseguito solo sulla frazione di casi che il modello economico ha rifiutato. Nessuna delle due metà funziona senza l'altra, e la decisione di routing che le unisce è una soglia su un numero: RLCD è la ragione per crederci.

Il limite onesto: calibrato non è corretto

La cosa più importante da capire correttamente su RLCD è ciò che non dichiara. La calibrazione è una proprietà dei valori di confidenza, non una garanzia sulle risposte, e il fornitore lo afferma nella propria documentazione invece di lasciarlo dire ai critici. La pagina di System One: "I modelli System One sono addestrati per prendere decisioni calibrate: le loro probabilità sono ottimizzate rispetto agli esiti per riflettere l'incertezza. La calibrazione è misurata su gruppi di previsioni; non garantisce che una singola risposta sia corretta." Un modello può essere perfettamente calibrato e sbagliare comunque la decisione sul tuo ticket, perché 0,9 significa nove su dieci, e questo potrebbe essere il decimo.

Le nostre cifre di servizio sono il contrappeso utile qui, proprio perché sono misurazioni del modello in produzione piuttosto che affermazioni su ciò che il metodo raggiunge. Nei sette giorni che terminano il 2026-09-30, sul traffico attraverso il playground di OrcaRouter da quando il modello è stato aggiunto al catalogo, la scheda Jev 1.13 riporta un tasso di errore dello 0,49% su 76,2 milioni di token, insieme a un tempo p50 al primo token di 151 ms, un p95 di 247 ms e circa 349 token di output al secondo. Due cose su quel numero meritano di essere dette chiaramente. È nostro, non del fornitore, ed è una finestra mobile piuttosto che un set di test fisso — lo stesso campo leggeva 0,57% prima nella finestra, perché viene ricalcolato sugli ultimi sette giorni di traffico live e le chiamate di ieri scadono. Inoltre non è una misurazione di calibrazione. Un tasso di errore ti dice quanto spesso qualcosa è andato storto sul nostro traffico; non ti dice se i valori di confidenza erano onesti, che è una domanda diversa e che richiede dati etichettati per avere una risposta.

Che è anche l'istruzione pratica che il fornitore fornisce, in una nota allegata alle sue linee guida sulle soglie: «I valori di soglia corretti dipendono dal tuo dominio e dalle prestazioni del modello per il tuo caso d'uso. Inizia con soglie conservative, prova con i tuoi dati e regola man mano che osservi i risultati». RLCD è un'affermazione su come è stato addestrato il modello. Se l'affermazione regge sui tuoi input è una questione empirica, ed è una delle poche proprietà del modello che puoi verificare senza alcuna infrastruttura di machine learning — prendi qualche centinaio di casi per cui hai già le etichette, raggruppa le risposte in base alla confidenza riportata dal modello e controlla se i gruppi sono corretti alla percentuale che dichiarano. Se il gruppo 0,9 è corretto circa il 90% delle volte sul tuo traffico, la soglia è reale e puoi automatizzare al di sopra di essa. Se tutto si concentra sopra 0,9 e l'accuratezza non segue, hai imparato qualcosa di più utile di qualsiasi numero da prima pagina.

Due ulteriori limiti vanno detti nello stesso respiro. Il primo è che non esiste una scheda di benchmark pubblica per questo modello con cui verificare qualunque cosa — il fornitore non ne ha pubblicata una, e nessuna classifica di terze parti include il modello; la pagina del modello su Artificial Analysis restituisce un 404 al 2026-09-30. Quindi l'argomento della calibrazione si fonda sulla descrizione dell'addestramento, sul contratto documentato e su qualunque cosa misuri tu stesso, non su una curva pubblicata. Il secondo è che le affermazioni del fornitore sulle prestazioni sono sue: il post di lancio osserva apertamente che le valutazioni dei flussi di lavoro alla base dei titoli su velocità e costi sono state costruite dal suo team delle capacità dei modelli, che le risposte di riferimento rispetto alle quali vengono misurate sono la media di due modelli esterni e che i numeri sono «nella fascia alta dei miglioramenti reali». Dice anche che non si può dimostrare che il prezzo non sia sovvenzionato. Niente di tutto ciò mina il metodo di addestramento, che è un'affermazione separata da quella sulla velocità, ma significa che la tesi a favore di RLCD è un argomento di progettazione degli obiettivi piuttosto che un risultato empirico consolidato. Trattala come un'ipotesi che puoi testare a basso costo, il che è una posizione migliore di quella in cui ti lascia la maggior parte delle affermazioni sui metodi di addestramento.

Cosa puoi fare con questo oggi

I due termini dell'argomentazione si incontrano in un solo punto. RLCD è il motivo per cui vale la pena diramare sulla confidenza di un modello decisionale; una soglia nel tuo codice è dove vive quella diramazione; e l'escalation è sostenibile solo se il percorso comune è abbastanza economico da essere eseguito ovunque. Jev 1.13 è richiamabile come typesafe/jev-1.13 su OrcaRouter — una sola API per oltre 200 modelli, 0% di ricarico, il prezzo di listino del provider passato tal quale, quindi un taglio di prezzo del fornitore è attivo qui lo stesso giorno — il che significa che il percorso della maggioranza ad alta confidenza e il percorso di escalation generativa vengono fatturati sulla stessa chiave invece che su due contratti con fornitori diversi. Lo chiami comunque nella sua forma specifica, POST /v1/systemone, non in streaming, su un contesto di 65.536 token, perché quella non è la rotta chat-completions di OpenAI e non è inglobata nell'endpoint chat. Due note datate dalle release dell'SDK del fornitore vale la pena conoscerle se lo stai collegando: la versione 0.7.1, rilasciata il 2026-09-21, ha aggiunto esempi per l'uso con i gateway AI, e la versione 0.7.2, rilasciata il 2026-09-26, ha aggiunto un extra http2 al pacchetto Python. La seconda è il tipo di dettaglio che emerge solo nelle note di rilascio — un client HTTP/2 vale la pena averlo per un modello la cui intera proposta di valore sono andate e ritorni sotto i 200 millisecondi.

Se c’è una sola cosa che devi portarti via da questa pagina, che sia la forma della domanda a cui risponde RLCD. Non è «un modello può essere più intelligente». È «un modello può dirmi quando non è abbastanza intelligente, abbastanza spesso e con abbastanza precisione da permettermi di automatizzare il resto». Questo è un obiettivo di ricerca diverso dai due su cui il settore ha speso gli ultimi anni, ed è l’unico che produce un numero sul quale il tuo codice può agire. Il valore di confidenza è quel numero. Mettilo alla prova sulle tue etichette prima di fidartene, e parti con una soglia sulla quale ti vergogneresti di sbagliarti, invece che con una sulla quale ti piacerebbe avere ragione.

Un ultimo tassello del quadro merita di essere tenuto accanto a tutto il resto, perché è il numero a cui punta l'intero ragionamento ed è misurato, non dichiarato. La scheda qui sotto è il nostro record di serving di sette giorni per typesafe/jev-1.13 — il modello in esercizio, non il metodo di addestramento, e non un benchmark. Leggila come la seconda metà della domanda di calibrazione: le confidenze ti dicono su quali chiamate intervenire, e questa ti dice quanto il resto della decisione di routing sia vicino a un sistema che lasceresti senza supervisione.