RLCD förklarat: Varför TypeSafe tränar Jev att vara ärlig om sitt självförtroende i stället för att vara omtyckt

Jev 1.13 (typesafe/jev-1.13) är tränad med en metod som dess skapare kallar Reinforcement Learning for Calibrated Decisions — RLCD — och den förkortningen är TypeSafes egen nybildning snarare än en branschterm som du förväntas redan känna till. Lanseringsinlägget säger det rakt ut: företaget byggde "en ny modellarkitektur, en parallell samplare för maximal effektivitet, och en träningsmetod som vi kallar Reinforcement Learning for Calibrated Decisions (RLCD)". Det är ett tredje svar på en fråga som tidigare hade två, och anledningen till att det finns är en missmatchning som de flesta team stöter på första gången de försöker sätta en språkmodell in i ett beslut. Innan vi kommer till det, spelar två datum roll, eftersom den här sidan inte är en lanseringsartikel. TypeSafe släppte själva modellen den 2026-09-15, vilket ligger utanför det sjudagarsfönster som den här bloggen skriver inom, och inget här bör läsas som att det framställer Jev som nytt. Den daterade händelsen är 2026-09-24, då OrcaRouter lade till typesafe/jev-1.13 i sin egen katalog och öppnade modellkortet för den — första gången Jev har kunnat anropas via en tredjepartsgateway i stället för endast via TypeSafes egen slutpunkt. Det är förändringen som den här sidan bygger på, och den praktiska konsekvensen är att tekniken nedan nu är något du kan prova i kod med en nyckel du kanske redan har, snarare än en forskningsidé du har läst om.

Det som följer är konceptet, inte modellen. Den första tredjedelen av den här sidan handlar om de två träningsmetoder som RLCD utformades för att motverka, eftersom RLCD bara går att förstå som en reparation av vad de två gör när uppgiften slutar vara ett samtal och blir en bedömning. Om du redan vet vad RLHF och RLVR optimerar för, är avsnittet du vill ha det tredje, där TypeSafe:s egen trevägstabell gör jobbet.

RLHF optimerar för svaret en person föredrar

Förstärkningsinlärning från mänsklig återkoppling är metoden som förvandlade förtränade språkmodeller till assistenter. TypeSafes egen introduktionsskrift konstaterar målet rakt ut, på ett kort med rubriken RLHF: den "förvandlade förtränade modeller till chattbotar. Den tränar modeller att producera svar som människor föredrar." InstructGPT och ChatGPT tränades med den, och introduktionsskriften tillägger en detalj som är relevant här av en annan anledning – metoden var meduppfunnen av Diogo Almeida, som är medgrundare till TypeSafe och författare till Jevs lanseringsinlägg. Företaget avfärdar inte metoden – det grundades av någon som var med och byggde den. Det argumenterar för att målet är fel för en viss uppgift.

Det renodlade sättet att se missförhållandet är att fråga sig vad belöningssignalen faktiskt mäter. Inom RLHF mäter den en bedömares preferens mellan två kandidatsvar. Det är en utmärkt proxy när produkten är en konversation, eftersom en konversations framgångskriterium verkligen är huruvida en person uppfattar svaret som bra. Det är en trasig proxy när produkten är ett beslut, eftersom framgångskriteriet där är huruvida den angivna konfidensen matchar verkligheten, och en bedömare som jämför två rimliga stycken har ingen möjlighet att se skillnaden mellan en välkalibrerad 0,6 och en självsäkert klingande 0,95. Två svar kan vara lika föredragna och ändå skilja sig enormt i hur mycket en programvara bör lita på dem.

De felmoder som TypeSafe nämner i introduktionen följer direkt av detta:

• Inställsamhet — modellen lär sig att producera det som bedömaren vill höra, vilket är ett annat mål än vad som är sant.

• Självsäker hallucination — flyt och säkerhet belönas av preferens även när inget ligger bakom dem.

• Mode dropping – preferensoptimering smalnar av utdatadistributionen, "gynnar en viss stil, till exempel att följa instruktioner, samtidigt som sannolikheten för andra möjliga utdata minskar." Mode dropping är den milda varianten av det klassiska mode-kollaps-misslyckandet som plågar generativa adversariella nätverk, där en generator konvergerar mot en enda utdata som fortsätter att lura diskriminatorn.

Introduktionsbokens eget varningsstycke är meningen som är värd att behålla: "Ett resultat kan vara övertygande för en person utan att vara tillräckligt tillförlitligt för oövervakad automation. Mänskliga preferenser och maskinell tillförlitlighet är olika optimeringsmål." Det är inte en kritik av RLHF som metod. Det är observationen att en preferenstränad modell aldrig har fått den fråga som automationen behöver få besvarad — hur ofta, exakt, har den här saken rätt när den säger att den är säker.

RLVR optimerar för utdata som ett program kan kontrollera — och beslut har sällan sådana.

Förstärkningsinlärning med verifierbara belöningar är den andra anpassningen, och det är den som ligger bakom resonemangsmodellerna. TypeSafes primer beskriver vad den resulterade i: modeller som "är starka på uppgifter som matematik, men långsammare och dyrare". Mekanismen är en kontrollfunktion. Om en uppgift har ett svar som ett program kan testa – ett enhetstest, en beviskontroll, ett numeriskt svar – så kan en belöning beräknas utan att fråga en människa om något, och modellen kan tränas mot den signalen i stor skala. Det fungerar, och det är därför resonemangsmodeller blev bra på just de domäner där billig automatisk verifiering finns.

Begränsningen ligger i formen på ordet "verifierbar". En verifierbar belöning kräver en verifierare, och en verifierare kräver att uppgiften har ett rätt svar som någon kan beräkna. Tänk på frågorna som ett produktionssystem faktiskt ställer. Ska den här supportärenden gå till fakturering eller till teknik? Liggger den här återbetalningsbegäran inom policyn? Ser den här transaktionen ut som bedrägeri? Var och en har oftast ett försvarbart svar, ingen har ett svar som ett program kan kontrollera, och de fall som betyder mest är just de där erfarna människor är oense. Det finns ingen funktion att köra. RLVR har inget att belöna, så det bidrar inte med något.

Den frestande kringlösningen är att tillverka en verifierare genom att märka upp ett dataset och träna mot etiketterna. Det ger metoden något att tugga på, men det förändrar målet på ett sätt som spelar roll. Etiketter kodar ett beslut, inte osäkerheten kring det. En modell som tränas att reproducera ett teams bedömningar i de svåra fallen lär sig att vara lika säker som etiketterna var – det vill säga precis lika överdrivet säker som människorna som skrev dem. Och även där en genuin verifierare faktiskt finns uppstår en andra lucka. En verifierare poängsätter svaret. Den poängsätter inte den angivna säkerheten. En modell som har rätt i 95 % av fallen och rapporterar fullständig säkerhet i alla dem får en perfekt belöning och är, som komponent i en automatiserad pipeline, värdelös – eftersom de 5 % är den enda del som pipelinen behövde få veta om. TypeSafes lanseringsmaterial gör samma poäng från andra hållet: "Om en modell kan utföra en uppgift 95 % av gångerna men inte säger när den är bland de 5 %, kan den inte automatisera den uppgiften."

Vad RLCD gör, i TypeSafe:s egen formulering

RLCD förändrar utdatakontraktet snarare än svarskvaliteten. Kortet i primern lyder: "Förstärkningsinlärning för kalibrerade beslut tränar TypeSafe att returnera beslut och kalibrerade sannolikheter i stället för genererad text." Lanseringsinläggets kortfattade version är "kalibrerade beslut: svar med epistemiskt ärliga sannolikheter på System One-uppgifter." Båda beskriver ett och samma drag: att träna modellen utifrån huruvida dess angivna sannolikhet matchade hur ofta det svaret visade sig vara rätt, i stället för utifrån huruvida en person eller en granskare gillade svaret.

Lanseringsinlägget ställer de tre metoderna sida vid sida, och kontrasten är den tydligaste formuleringen av idén som finns. Läs det som en uppsättning kontraster snarare än en tabell:

• Vad den optimerar för — RLHF optimerar mänskliga preferenser, "skrivningar och chattresponser som mänskliga bedömare föredrar"; RLVR optimerar "utdata som kan verifieras programmatiskt"; RLCD optimerar kalibrering, "svar med epistemiskt ärliga sannolikheter på System One-uppgifter."

• Vad som matas in — de två äldre tar emot ostrukturerad data "med betoning på sekventiella meddelanden"; en kalibrerad beslutsmodell tar emot ostrukturerad data "med betoning på strukturerat programtillstånd."

• Vad som kommer ut — genererade strängar som "behöver parsas + valideras," med "alltid viss risk att AI:n spårar ur," mot typsäkra strukturerade värden där "möjliga utdata och struktur definieras i förväg," modellen "aldrig gör typfel," och "alla svar åtföljs av kalibrerade sannolikheter och konfidenspoäng."

• Hur det samplas – en token i taget, var och en betingad av den föregående, mot alla utdata som genereras i en enda förfrågan. Detta är den mekaniska anledningen till att den tredje metoden är billig: det finns ingen avkodningsslinga att betala för.

• Vad det kostar — indatatoken från 0,20 $ till 10 $ per miljon för jämförelsemodellerna, där utdatapriset är ungefär fem gånger indatapriset, jämfört med 0,042 $ per miljon indatatoken, där utdata faktureras till noll för Jev.

• Hur snabbt den svarar – 3 till 329 sekunder från början till slut för frontiermodeller jämfört med 70 ms till 500 ms, vilket leverantören beskriver som 40x till 200x snabbare på System One-formade frågor.

• Vad den säger om sin egen konfidens – de två äldre "tenderar att vara överkonfidenta och inkonsekventa" även när de uppmanas att uppskatta sin konfidens; RLCD "förmedlar alltid konfidens och osäkerhet med varje utdata", där "högre konfidens innebär högre noggrannhet."

Den sista raden är det egentliga produktpåståendet, och det är falsifierbart på ett sätt som de andra inte är. "Högre konfidens innebär högre träffsäkerhet" är ett påstående om en kurva: gruppera en modells svar efter sannolikheten den angav, och grupperna bör vara korrekta i ungefär den frekvens som sannolikheterna gör anspråk på. TypeSafes konfidensdokumentation anger kontraktet med ovanligt konkreta siffror:

• Utfall som har tilldelats en sannolikhet på 0,2 bör inträffa ungefär 20 % av gångerna.

• Utfall som tilldelats en sannolikhet på 0,8 bör inträffa ungefär 80 % av gångerna.

• Utfall som tilldelats en sannolikhet på 1,0 bör inträffa 100 % av gångerna.

Och sedan meningen som håller påståendet ärligt, med leverantörens egna ord: ”Dessa frekvenser beskriver grupper av förutsägelser, inte en garanti för något enskilt svar.” Det är inte en gardering som satts dit av juridiska skäl. Det är hela innebörden av kalibrering. En välkalibrerad modell som säger 0,8 lovar inte att ha rätt den här gången; den lovar att bland alla svar den betecknade med 0,8 var ungefär fyra av fem korrekta. Ett svar säger dig ingenting. Tusen svar under en vecka säger dig om kurvan är verklig.

Samma kontrast med tre kort finns i TypeSafes egen dokumentation, som är källan till jämförelsen ovan och den tydligaste platsen att kontrollera formuleringen i stället för att lita på en sammanfattnings ord. Avbildningen nedan är den sidan som den ser ut i dag: tre kort för de tre efterträningsansatserna, där det tredje namnger RLCD i sin helhet.

Två ytterligare detaljer i leverantörens dokumentation visar hur långt metoden sträcker sig in i produkten. Den första är att konfidens härleds snarare än genereras: modellen returnerar en fullständig sannolikhetsfördelning över de alternativ eller nivåer du angav, och konfidensvärdet är en statistik som beräknas utifrån formen på den fördelningen. Det är därför dokumentationen kan säga att definitionen inte är bärande – du får den råa fördelningen ändå och kan beräkna din egen statistik om din passar bättre. Den andra är att RLCD är det enda som formar vikterna. TypeSafes modellsida säger: "Jev finjusteras inte och LoRA-anpassas inte med kunddata. Det tränas med RLCD för att returnera kalibrerade beslut, och samma vikter tjänar varje konto." Domänanpassning sker i begäran – ditt tillstånd, dina kriterier – inte i en kundspecifik checkpoint. Vilken kalibrering metoden än producerade är den kalibrering varje kund får.

Varför kalibrering är det som gör en billig beslutsmodell användbar

En kalibrerad sannolikhet är inte intressant i sig. Den blir arkitekturen i det ögonblick din kod förgrenar sig utifrån den, och TypeSafe:s dokumentation om konfidens beskriver exakt det mönstret som tre intervall, där varje intervall ger ett olika systembeteende.

• Hög konfidens — agera automatiskt. Modellen har en tydlig uppfattning och du kan fortsätta utan mänsklig inblandning.

• Medelhög tillförlitlighet — fortsätt med försiktighet. Modellen har ett rimligt svar men är inte säker, så du bekräftar med användaren, flaggar för granskning eller samlar in mer information innan du agerar.

• Låg konfidens – agera inte. Skicka vidare till en människa, be om förtydligande eller fall tillbaka på ett annat system, eftersom modellen säger att den inte har tillräckligt att gå på.

Dokumentationen är tydlig med att gränserna är dina att dra och bör skilja sig beroende på konsekvens: ”En konfidenströskel är inte ett enda tal. Olika åtgärder inom samma system bör villkoras på olika nivåer beroende på konsekvenserna av att få det fel.” Deras genomarbetade exempel sätter ett hårt golv vid 0,5 – allt som modellen rapporterar under det skickas till en människa utan ytterligare granskning – och tillämpar sedan en högre ribba för en destruktiv åtgärd än för en skrivskyddad sådan. Din kod kodar in risktoleransen; modellen levererar den ärliga indatan till den.

Det mönstret är hela argumentet för ett arbetsflöde med två modeller, och det är värt att formulera som ett argument snarare än en funktionslista. Anta att du vill ha en automatiserad pipeline som hanterar den säkra majoriteten av fallen och eskalerar resten till en större modell eller en person. Beslutet att eskalera måste komma från någonstans. Om den billiga modellen rapporterar 0,98 för allt, inklusive de fall där den gissar, har grenen inget att testa och du antingen automatiserar allt – inklusive de anrop som den borde ha eskalerat – eller så automatiserar du inget. En modell vars konfidens är informativ är den enda typen som låter dig automatisera en delmängd på ett säkert sätt, eftersom den är den enda typen som kan tala om för dig vilken delmängd den är osäker på. Dokumentationen sammanfattar samma poäng i en rad som är värd att citera för sin direkthet: "Om ett intelligent system, vare sig det är mänskligt eller maskinellt, inte kan uttrycka ärlig osäkerhet, går det inte att lita på systemet."

Det finns en andra anledning till att detta spelar större roll för en billig modell än för en dyr, och det är anledningen till att routingberättelsen och RLCD-berättelsen är samma berättelse. En modell som kostar 0,042 dollar per miljon indatatoken utan utdataavgift är tillräckligt billig för att konsulteras ständigt – vid varje tur i en agentloop, för varje post i en batch, för varje ärende när det anländer. Att ständigt konsulteras är precis den situation där en modells misstag förstärks, eftersom ingen läser dess utdata innan någon agerar på dem. Konfidens är det som gör detta säkert. Billigheten är det som gör eskaleringsgrenen överkomlig, eftersom den dyra vägen bara körs för den andel av fallen som den billiga modellen avböjde. Ingen av halvorna fungerar utan den andra, och det routingbeslut som förenar dem är ett tröskelvärde på ett tal som RLCD ger skäl att tro på.

Den ärliga gränsen: kalibrerad är inte korrekt

Det viktigaste att få rätt när det gäller RLCD är vad det gör. Kalibrering är en egenskap hos konfidensvärdena, inte en garanti om svaren, och leverantören säger det i sin egen dokumentation i stället för att lämna det till kritiker. System One-sidan: "System One-modeller är tränade för kalibrerade beslut: deras sannolikheter optimeras mot osäkerhet för att återspegla osäkerhet. Kalibrering mäts över grupper av prediktioner; den garanterar inte att ett enskilt svar är korrekt." En modell kan vara perfekt kalibrerad och ändå fatta fel beslut om ditt ärende, eftersom 0,9 betyder nio av tio, och detta kan vara den tionde.

Våra egna driftssiffror är den användbara motvikten här, just eftersom de är mätningar av modellen i produktion snarare än påståenden om vad metoden åstadkommer. Under de sju dagarna som slutade 2026-09-30, för trafik genom OrcaRouters playground sedan modellen lades till i katalogen, rapporterar kortet för Jev 1.13 en felfrekvens på 0,49 % över 76,2 miljoner tokens, tillsammans med en p50-tid till första token på 151 ms, en p95 på 247 ms och omkring 349 utdata-tokens per sekund. Två saker om den siffran förtjänar att sägas rakt ut. Den är vår, inte leverantörens, och den är ett rullande fönster snarare än en fast testmängd – samma fält visade 0,57 % tidigare i fönstret, eftersom det räknas om över de senaste sju dagarnas livetrafik och gårdagens anrop faller bort. Det är inte heller en kalibreringsmätning. En felfrekvens säger hur ofta något gick fel i vår trafik; den säger inte om konfidensvärdena var ärliga, vilket är en annan fråga och en som kräver märkta data för att besvaras.

Vilken är den praktiska instruktion som leverantören också ger, i en not bifogad sin tröskelvägledning: ”De korrekta tröskelvärdena beror på din domän och modellens prestanda för ditt användningsfall. Börja med konservativa tröskelvärden, testa med dina egna data och justera allteftersom du ser resultat.” RLCD är ett påstående om hur modellen tränades. Huruvida påståendet håller för dina indata är en empirisk fråga, och det är en av få modellegenskaper du kan testa utan någon maskininlärningsinfrastruktur – ta några hundra fall som du redan har etiketter för, gruppera svaren efter den konfidens modellen rapporterade och kontrollera om grupperna är korrekta i den utsträckning de påstår. Om 0,9-gruppen har rätt ungefär 90 % av gångerna på din trafik är tröskelvärdet verkligt och du kan automatisera ovanför det. Om allt klustrar sig över 0,9 och träffsäkerheten inte hänger med har du lärt dig något mer användbart än någon rubriksiffra.

Ytterligare två begränsningar hör hemma i samma andetag. Den första är att det inte finns något offentligt benchmarkkort för den här modellen att kontrollera något av detta mot – leverantören har inte publicerat något, och ingen tredjepartsto tabell har med modellen; Artificial Analysis modellsida för den returnerar 404 per 2026-09-30. Så kalibreringsargumentet vilar på träningsbeskrivningen, det dokumenterade kontraktet och vad du själv mäter, inte på en publicerad kurva. Den andra är att leverantörens egna prestandapåståenden är dess egna: lanseringsinlägget noterar öppet att arbetsflödesutvärderingarna bakom rubriksiffrorna för hastighet och kostnad byggdes av dess modellkapabilitetsteam, att referenssvaren som de mäts mot är genomsnittet av två externa modeller, och att siffrorna är "i den högre änden av verkliga vinster". Det säger också att prissättningen inte kan bevisas vara osubventionerad. Inget av detta undergräver träningsmetoden, vilket är ett separat påstående från hastighetspåståendet, men det innebär att argumentet för RLCD är ett argument om objektivdesign snarare än ett etablerat empiriskt resultat. Behandla det som en hypotes du kan testa billigt, vilket är en bättre position än de flesta påståenden om träningsmetoder lämnar dig i.

Vad du kan göra med detta idag

De två termerna i argumentet möts på ett ställe. RLCD är anledningen till att en beslutsmodells konfidens är värd att förgrena sig på; en tröskel i din kod är där den grenen finns; och eskalering är bara överkomlig om den vanliga vägen är billig nog att köra överallt. Jev 1.13 är anropbar som typesafe/jev-1.13 på OrcaRouter — ett API för 200+ modeller, 0 % påslag, leverantörens listpris förs vidare, så en leverantörsprissänkning är live här samma dag — vilket innebär att den konfidenta majoritetsvägen och den generativa eskaleringsvägen faktureras på samma nyckel istället för två leverantörsavtal. Du anropar den fortfarande i sin egen form, POST /v1/systemone, icke-strömmande, mot en kontext på 65 536 token, eftersom det inte är OpenAI chat-completions-rutten och det inte är inbakat i chatt-slutpunkten. Två daterade anteckningar från leverantörens SDK-utgåvor är värda att känna till om du kopplar upp den: version 0.7.1, släppt 2026-09-21, lade till exempel för användning med AI-gateways, och version 0.7.2, släppt 2026-09-26, lade till ett http2-extra till Python-paketet. Den andra är den typ av detalj som bara dyker upp i utgåvenoteringar — en HTTP/2-klient är värd att ha för en modell vars hela värdeerbjudande är rundturer på under 200 millisekunder.

Om du tar med dig en enda sak från sidan, låt det vara formen på frågan som RLCD besvarar. Det är inte "kan en modell vara smartare?" Det är "kan en modell tala om för mig när den inte är tillräckligt smart, tillräckligt ofta och tillräckligt noggrant för att jag ska kunna automatisera resten." Det är ett annat forskningsmål än de två som fältet har ägnat de senaste åren åt, och det är det enda som ger ett tal som din kod kan agera på. Konfidensvärdet är det talet. Testa det på dina etiketter innan du litar på det, och börja med en tröskel som du skulle skämmas över att ha fel om snarare än en som du skulle vilja ha rätt om.

En sista pusselbit i bilden är värd att bära med sig tillsammans med allt det andra, eftersom det är siffran som hela argumentet syftar på och den är mätt snarare än påstådd. Kortet nedan är vår egen sjudagars serveringslogg för typesafe/jev-1.13 — modellen i drift, inte träningsmetoden och inte ett benchmark. Läs det som den andra halvan av kalibreringsfrågan: konfidensvärdena säger vilka anrop du ska agera på, och det här säger hur nära resten av routningsbeslutet ligger ett system som du skulle lämna utan uppsikt.