Dit artikel analyseert 'Jev', een nieuw niet-autoregressief 'System One-model' van TypeSafe AI. In tegenstelling tot traditionele LLM's genereert Jev geen vrije tekst, maar beantwoordt het gestructureerde vragen (Choice, Score, Noul) in één enkele forward pass, wat resulteert in aanzienlijk lagere latentie en kosten.
De auteur, een ML-engineer, beargumenteert dat de focus op kalibratie (de mate waarin voorspelde waarschijnlijkheden overeenkomen met de werkelijke frequentie van gebeurtenissen) belangrijker is dan pure accuratesse voor productieclassificaties. Jev is getraind met reinforcement learning for calibrated decisions (RLCD) om 'epistemisch eerlijke waarschijnlijkheden' te bieden.
Belangrijke punten uit het artikel:
- Toepassing: Jev is uitermate geschikt voor repetitieve beslissingstaken binnen systemen (zoals ERP), waar een LLM-aanroep te traag of te duur is.
- Kritische blik: De auteur plaatst vraagtekens bij claims over 'nul hallucinaties' en benadrukt dat kalibratie afhankelijk is van de specifieke dataset.
- Experiment: De auteur stelt voor Jev te testen tegen Random Forests en frontier LLM's op basis van de Brier-score en Expected Calibration Error (ECE) bij het voorspellen van de acceptatie van pull requests.
De conclusie is dat System One-modellen een waardevol instrument zijn voor gestructureerde beslissingen, mits ze empirisch kunnen bewijzen dat ze superieur zijn aan klassieke tabulaire modellen op specifieke productiedistributies.
Jev en System One-modellen: Kalibratie is belangrijker dan accuratesse
Een analyse door een ML-engineer over Jev van TypeSafe AI: wat een niet-autoregressief 'System One'-model verandert voor productieclassificaties, waar het past in de stack, en hoe ik van plan ben het te testen.
---
Vorige week lanceerde TypeSafe AI 'Jev', wat zij het eerste "System One-model" noemen: een model dat niet chat, niet schrijft en niet stap voor stap redeneert. In plaats daarvan beantwoordt het gestructureerde vragen over een input in één enkele forward pass, waarbij aan elk antwoord een waarschijnlijkheid (probability) is gekoppeld.
De meeste berichtgeving richtte zich op de snelheid. Ik denk echter dat de claim over kalibratie interessanter is, omdat kalibratie stilletjes de beperkende factor is geweest voor elke productieclassifier die ik heb opgeleverd, inclusief die in mijn COMPSAC-paper.
In dit artikel onderzoek ik wat Jev daadwerkelijk verandert, waar het past in een echte ML-stack en hoe ik de beweringen wil testen in plaats van ze simpelweg voor waar aan te nemen.
Mijn uitgangspunt
Ik ontwikkel productie-ML voor een groothandelsdistributeur (routering, forecasting, classificatie binnen een ERP) en ik heb een studie gepubliceerd over het voorspellen van de acceptatie van pull requests (PR's) bij IEEE COMPSAC 2026. Jev bevindt zich in een early-access fase en ik heb nog geen API-toegang; alle onderstaande claims over prestaties zijn dus afkomstig van TypeSafe. Het experimentontwerp aan het eind is wat ik zal uitvoeren zodra ik toegang krijg.
Wat is Jev (zonder de marketing)?
Volgens de lanceringspost van TypeSafe is Jev gebouwd rond drie kernideeën:
- Niet-autoregressieve output: Een normaal LLM genereert zijn antwoord token voor token, waarbij elk token afhangt van het vorige. Jev produceert het volledige gestructureerde antwoord in één keer. Hier komt de snelheid vandaan: TypeSafe noemt een end-to-end tijd van 70–500 ms, wat "40x–200x sneller" is dan frontier LLM's voor gelijkwaardige taken.
- Getypeerde vragen in plaats van prompts: Je verstuurt een status (tekst, gestructureerde data of een berichtgeschiedenis) en een set vragen. Elke vraag is van een van de drie volgende typen:
- Choice: Kies uit een set, ontvang een waarschijnlijkheid per optie.
- Score: Beoordeel op basis van geordende niveaus, ontvang een continue score en distributie.
- Noul: Een ja/nee-vraag, geretourneerd als de waarschijnlijkheid dat de bewering waar is.
Alle vragen in een verzoek worden parallel geëvalueerd, waardoor extra vragen nauwelijks invloed hebben op de latentie.
- Training voor kalibratie: Het model is getraind met reinforcement learning for calibrated decisions (RLCD). Het doel is "epistemisch eerlijke waarschijnlijkheden", in tegenstelling tot de menselijke voorkeuren of verifieerbare beloningen waarop chatmodellen zijn afgestemd.
Beperkingen De beperkingen zijn net zo belangrijk als de functies. Jev kan geen vrije tekst genereren. Een choice-vraag ondersteunt maximaal 255 opties. Er is nog geen ondersteuning voor afbeeldingen. De prijs is $0,042 per miljoen inputtokens, waarbij outputtokens gratis zijn. Toegang is momenteel via een wachtlijst.
Kortom: het is geen kleiner GPT. Het lijkt meer op een zeer snelle, zeer algemene tabulaire classifier die ongestructureerde input leest en een getypeerde beslissing teruggeeft met een betrouwbaarheidsniveau dat je zou moeten kunnen vertrouwen.
Waarom kalibratie, en niet accuratesse, de echte bottleneck is
In mijn eigen paper voorspelden we of een pull request zou worden samengevoegd (merged), gebruikmakend van signalen die beschikbaar waren op het moment van indiening. Een Random Forest behaalde een F1-score van 0,958. De majority-class baseline (die alles als "merged" bestempelt) behaalde 0,957.
Het getal dat een nuttig model scheidde van een nutteloos model was de ROC-AUC: 0,676 voor het forest tegenover 0,500 voor de baseline. Zelfs toen schreven we expliciet dat de modellen "niet behandeld zouden moeten worden als perfect gekalibreerde waarschijnlijkheidsmodellen" en geschikt waren voor triage, maar niet voor geautomatiseerde acceptatie/afwijzingsbeslissingen.
Dit is geen eigenaardigheid van één dataset, maar het normale patroon van een productieclassifier:
- Accuratesse verzadigt snel: Bij ongebalanceerde problemen is het grootste deel van de accuratesse "gratis". Het moeilijke deel is de rangschikking en de betrouwbaarheid.
- Downstream logica heeft waarschijnlijkheden nodig, geen labels: Een regel als "stuur deze order naar handmatige controle als het model minder dan 80% zeker is" werkt alleen als 80% ook echt 80% betekent. Als het model 0,95 aangeeft voor zaken die slechts 70% van de tijd correct zijn, is elke drempelwaarde een leugen.
- Miskalibratie is onzichtbaar in gebruikelijke metrieken: F1, accuratesse en zelfs AUC zijn drempel- of rangmetrics. Een model kan een prima AUC hebben maar een verschrikkelijke kalibratie; dit merk je pas wanneer de businessregel die erop is gebouwd fouten begint te maken.
De standaardoplossingen zijn post-hoc: Platt scaling, isotone regressie of temperature scaling. Deze werken, maar vormen een extra component die kan gaan afwijken wanneer de data verandert. Wat Jev claimt, is dat de waarschijnlijkheden direct "eerlijk" uit het model komen, omdat eerlijkheid het trainingsdoel was. Als dat standhoudt buiten de benchmarks van TypeSafe, verwijdert dit een hele laag 'lijm' uit productie-ML-systemen.
Waar een System One-model past in een echte stack
In mijn werk bij een groothandel is bijna niets 'chat'. Het meeste bestaat uit kleine, herhaalde beslissingen tussen twee systemen:
| Beslissing | Huidige aanpak | Waarom dit vervelend is | Past Jev hier? |
|---|
| Is deze inkomende order een uitzondering die een mens nodig heeft? | Regels plus een kleine classifier | Regels verouderen; de classifier hertrainen is een project | Ja: een noul met een drempelwaarde |
| Bij welke reguliere productcategorie hoort deze nieuwe SKU? | Keyword-regels, handmatige opschoning | Vendor-beschrijvingen zijn rommelige vrije tekst | Ja, mits categorieën binnen 255 keuzes passen |
| Hoe urgent is dit bericht van de klantenservice? | Niets, of een LLM-aanroep die seconden duurt | Latentie en kosten maken het lastig voor elk bericht | Ja: een score over geordende niveaus |
| Welke leveringsroute moet deze late order opvangen? | Constraint solver | Geen classificatieprobleem | Nee |
| Schrijf de klantbericht-notitie over een vervanging | LLM | Vereist gegenereerde tekst | Nee |
Het patroon is duidelijk. Overal waar ik een LLM gebruik voor een taak die eigenlijk classificatie is (maar vermomd is als chat), is een System One-model een plausbare vervanger met een latentie en kosten die twee ordes van grootte lager liggen. Overal waar handgeschreven regels breken omdat de input vrije tekst is, is het een plausbare vervanging voor die regels. Voor generatie of optimalisatie is het echter het verkeerde instrument.
Ook de integratie met ERP is aantrekkelijk. Een model dat in 100 ms {"is_exception": 0.93} teruggeeft, kan direct in het request-pad zitten. Een LLM die in vier seconden een paragraaf teruggeeft, moet in een queue ernaast staan. Dat verschil bepaalt of ML een feature is of een batch-job.
Claims die ik nog niet accepteer
Enkele punten in het lanceermateriaal verdienen een sceptische blik:
- "Nul hallucinaties": Wat TypeSafe garandeert is dat het output-type altijd geldig is: als je vraagt om één van de vijf categorieën, krijg je er één van de vijf, met waarschijnlijkheden die optellen tot één. Dat is nuttig, maar het zegt niets over of de gekozen categorie correct is. Een zelfverzekerd fout antwoord in een geldig schema is nog steeds een fout antwoord. De eerlijke formulering is "nul schemafouten", en kalibratie moet de rest opvangen.
- Kalibratie op wiens distributie?: Een model kan goed gekalibreerd zijn op zijn trainings- en benchmarkdistributie, maar sterk afwijken op die van jou. Kalibratie is een eigenschap van zowel het model als de dataset. De enige waarde die ik vertrouw, is een waarde die is gemeten op mijn eigen data.
- De vergelijkingsbasis: "200x sneller dan een LLM bij classificatie" is waar, maar ook een beetje oneerlijk. De juiste baseline voor veel van deze taken is namelijk geen LLM, maar een gradient-boosted tree op engineered features, wat ook sub-milliseconde en gratis is. De interessante vergelijking is drieledig: een klassiek tabulair model, LLM-as-classifier en Jev, op basis van accuratesse, rangschikking, kalibratie, latentie en kosten.
Het experiment dat ik wil uitvoeren
Ik heb het ideale testbed al gebouwd: de PR-acceptatiepipeline uit mijn paper. Deze is leakage-aware, heeft vaste 5-fold splits en een gepubliceerde tree-model baseline met een bekende kalibratiezwakte.
Het ontwerp:
- Taak: Gegeven een PR op het moment van indiening, voorspel of deze wordt samengevoegd (merged) of gesloten zonder merge. De Jev-status wordt de PR-titel, body en dezelfde metadata en diff-statistieken die de trees zien, geserialiseerd als tekst. Niets wat na indiening verschijnt (comments, CI, latere commits) komt in de status.
- Vragen: Eén noul: "Deze pull request zal worden samengevoegd." Optioneel één choice over de task-intent tags (fix, feature, refactor, docs) om te zien of Jev's interpretatie van intentie overeenkomt met onze keyword-regels.
- Baselines: De Random Forest (400 trees) uit de paper, dezelfde forest met isotone kalibratie (fitted in-fold), en een frontier LLM met gestructureerde output.
- Metrieken: Rangschikking en kalibratie, niet alleen F1:
- ROC-AUC, zodat het resultaat vergelijkbaar is met de paper.
- Brier score, de gemiddelde kwadratische fout van de waarschijnlijkheid ten opzichte van de uitkomst:
$$\text{Brier} = \frac{1}{N}\sum{i=1}^{N}\left(\hat{p}i - y_i\right)^2$$
- Expected Calibration Error (ECE), waarbij voorspellingen per betrouwbaarheidsniveau worden gegroepeerd en gemeten hoe ver de accuratesse van elke groep afwijkt van de opgegeven betrouwbaarheid:
$$\text{ECE} = \sum{b=1}^{B} \frac{|Sb|}{N}\,\Big|\,\text{acc}(Sb) - \text{conf}(Sb)\,\Big|$$
- Een reliability diagram per model, omdat één ECE-getal maskeert waar een model over- of onder-confident is.
- Mediaan en p95 latentie, en kosten per 1.000 PR's.
Wat zou mijn mening doen veranderen? Als Jev de AUC van de forest evenaart en de gekalibreerde forest verslaat op Brier en ECE, zonder enige post-hoc fitting, dan is de claim over kalibratie echt op een distributie die TypeSafe nooit heeft gezien. In dat geval zou ik classificatie-taken op het werk overzetten naar Jev. Als het de ongekalibreerde forest verslaat maar niet de gekalibreerde, dan is het een gemak, geen nieuwe capaciteit. Als de AUC materieel lager is, doet de snelheid er niet toe.
Wat ik een team vandaag zou adviseren
Als je nu overweegt of Jev relevant is, is mijn advies:
- Inventariseer je LLM-aanroepen. Label elke aanroep als genereren of beslissen. De 'beslissen'-aanroepen zijn kandidaten. In mijn ervaring is dat het grootste deel.
- Meet de kalibratie van wat je al hebt. Bereken de Brier-score en ECE voor je huidige classifiers. Als deze slecht zijn, heb je een probleem dat Jev wellicht oplost. Als ze prima zijn, gaat het vooral om een vraag over latentie en kosten.
- Sla de klassieke baseline niet over. Een gradient-boosted tree op goede features is de standaard. Elk nieuw model moet dit op jouw data, met jouw leakage-regels, verslaan, anders is het geen upgrade.
- Behandel "gekalibreerd" als een hypothese. Test het op jouw distributie voordat een businessregel er afhankelijk van wordt.
Het idee achter System One-modellen is solide: de meeste beslissingen die software van ML nodig heeft, zijn klein, gestructureerd en latentiegevoelig. Een chatmodel is een vreemd instrument voor dat doel. Of Jev de belofte over kalibratie waarmaakt, is een empirische vraag. Ik heb de dataset om dit te beantwoorden, en ik ben van plan dat te doen.
---
Verdere lectuur
- Introducing System One Models & Jev, TypeSafe AI
- Building a harness with Jev, LangChain, voor de request/response vorm
- Predicting Pull Request Acceptance the Moment It’s Opened, mijn verslag van de COMPSAC-paper
- Guo et al., On Calibration of Modern Neural Networks, ICML 2017 (de standaardreferentie voor ECE en temperature scaling)
Voetnoten
- TypeSafe AI, Introducing System One Models & Jev, september 2026. Latentie, snelheidswinst, prijs, cardinaliteit en modaliteitslimieten zijn geciteerd uit deze post en zijn claims van de leverancier.
- LangChain, Building a harness with Jev, september 2026, waarin de state/questions request-vorm en de choice, score en noul vraagtypes worden gedocumenteerd.
- K. Pansuriya, E. Ghorbani, D. Singh, E. A. AlOmar. Predicting Acceptance and Review Effort in Human and Agent Pull Requests. IEEE COMPSAC 2026. arXiv:2607.12057. Tabel II rapporteert RF F1 0,958 / AUC 0,676 en de majority baseline F1 0,957 / AUC 0,500.
Jev en System One-modellen: Kalibratie is belangrijker dan accuratesse
Een analyse door een ML-engineer over Jev van TypeSafe AI: wat een niet-autoregressief 'System One'-model verandert voor productieclassificaties, waar het past in de stack, en hoe ik van plan ben het te testen.
---
Vorige week lanceerde TypeSafe AI 'Jev', wat zij het eerste "System One-model" noemen: een model dat niet chat, niet schrijft en niet stap voor stap redeneert. In plaats daarvan beantwoordt het gestructureerde vragen over een input in één enkele forward pass, waarbij aan elk antwoord een waarschijnlijkheid (probability) is gekoppeld.
De meeste berichtgeving richtte zich op de snelheid. Ik denk echter dat de claim over kalibratie interessanter is, omdat kalibratie stilletjes de beperkende factor is geweest voor elke productieclassifier die ik heb opgeleverd, inclusief die in mijn COMPSAC-paper.
In dit artikel onderzoek ik wat Jev daadwerkelijk verandert, waar het past in een echte ML-stack en hoe ik de beweringen wil testen in plaats van ze simpelweg voor waar aan te nemen.
Mijn uitgangspunt
Ik ontwikkel productie-ML voor een groothandelsdistributeur (routering, forecasting, classificatie binnen een ERP) en ik heb een studie gepubliceerd over het voorspellen van de acceptatie van pull requests (PR's) bij IEEE COMPSAC 2026. Jev bevindt zich in een early-access fase en ik heb nog geen API-toegang; alle onderstaande claims over prestaties zijn dus afkomstig van TypeSafe. Het experimentontwerp aan het eind is wat ik zal uitvoeren zodra ik toegang krijg.
Wat is Jev (zonder de marketing)?
Volgens de lanceringspost van TypeSafe is Jev gebouwd rond drie kernideeën:
- Niet-autoregressieve output: Een normaal LLM genereert zijn antwoord token voor token, waarbij elk token afhangt van het vorige. Jev produceert het volledige gestructureerde antwoord in één keer. Hier komt de snelheid vandaan: TypeSafe noemt een end-to-end tijd van 70–500 ms, wat "40x–200x sneller" is dan frontier LLM's voor gelijkwaardige taken.
- Getypeerde vragen in plaats van prompts: Je verstuurt een status (tekst, gestructureerde data of een berichtgeschiedenis) en een set vragen. Elke vraag is van een van de drie volgende typen:
- Choice: Kies uit een set, ontvang een waarschijnlijkheid per optie.
- Score: Beoordeel op basis van geordende niveaus, ontvang een continue score en distributie.
- Noul: Een ja/nee-vraag, geretourneerd als de waarschijnlijkheid dat de bewering waar is.
Alle vragen in een verzoek worden parallel geëvalueerd, waardoor extra vragen nauwelijks invloed hebben op de latentie.
- Training voor kalibratie: Het model is getraind met reinforcement learning for calibrated decisions (RLCD). Het doel is "epistemisch eerlijke waarschijnlijkheden", in tegenstelling tot de menselijke voorkeuren of verifieerbare beloningen waarop chatmodellen zijn afgestemd.
Beperkingen De beperkingen zijn net zo belangrijk als de functies. Jev kan geen vrije tekst genereren. Een choice-vraag ondersteunt maximaal 255 opties. Er is nog geen ondersteuning voor afbeeldingen. De prijs is $0,042 per miljoen inputtokens, waarbij outputtokens gratis zijn. Toegang is momenteel via een wachtlijst.
Kortom: het is geen kleiner GPT. Het lijkt meer op een zeer snelle, zeer algemene tabulaire classifier die ongestructureerde input leest en een getypeerde beslissing teruggeeft met een betrouwbaarheidsniveau dat je zou moeten kunnen vertrouwen.
Waarom kalibratie, en niet accuratesse, de echte bottleneck is
In mijn eigen paper voorspelden we of een pull request zou worden samengevoegd (merged), gebruikmakend van signalen die beschikbaar waren op het moment van indiening. Een Random Forest behaalde een F1-score van 0,958. De majority-class baseline (die alles als "merged" bestempelt) behaalde 0,957.
Het getal dat een nuttig model scheidde van een nutteloos model was de ROC-AUC: 0,676 voor het forest tegenover 0,500 voor de baseline. Zelfs toen schreven we expliciet dat de modellen "niet behandeld zouden moeten worden als perfect gekalibreerde waarschijnlijkheidsmodellen" en geschikt waren voor triage, maar niet voor geautomatiseerde acceptatie/afwijzingsbeslissingen.
Dit is geen eigenaardigheid van één dataset, maar het normale patroon van een productieclassifier:
- Accuratesse verzadigt snel: Bij ongebalanceerde problemen is het grootste deel van de accuratesse "gratis". Het moeilijke deel is de rangschikking en de betrouwbaarheid.
- Downstream logica heeft waarschijnlijkheden nodig, geen labels: Een regel als "stuur deze order naar handmatige controle als het model minder dan 80% zeker is" werkt alleen als 80% ook echt 80% betekent. Als het model 0,95 aangeeft voor zaken die slechts 70% van de tijd correct zijn, is elke drempelwaarde een leugen.
- Miskalibratie is onzichtbaar in gebruikelijke metrieken: F1, accuratesse en zelfs AUC zijn drempel- of rangmetrics. Een model kan een prima AUC hebben maar een verschrikkelijke kalibratie; dit merk je pas wanneer de businessregel die erop is gebouwd fouten begint te maken.
De standaardoplossingen zijn post-hoc: Platt scaling, isotone regressie of temperature scaling. Deze werken, maar vormen een extra component die kan gaan afwijken wanneer de data verandert. Wat Jev claimt, is dat de waarschijnlijkheden direct "eerlijk" uit het model komen, omdat eerlijkheid het trainingsdoel was. Als dat standhoudt buiten de benchmarks van TypeSafe, verwijdert dit een hele laag 'lijm' uit productie-ML-systemen.
Waar een System One-model past in een echte stack
In mijn werk bij een groothandel is bijna niets 'chat'. Het meeste bestaat uit kleine, herhaalde beslissingen tussen twee systemen:
| Beslissing | Huidige aanpak | Waarom dit vervelend is | Past Jev hier? |
|---|
| Is deze inkomende order een uitzondering die een mens nodig heeft? | Regels plus een kleine classifier | Regels verouderen; de classifier hertrainen is een project | Ja: een noul met een drempelwaarde |
| Bij welke reguliere productcategorie hoort deze nieuwe SKU? | Keyword-regels, handmatige opschoning | Vendor-beschrijvingen zijn rommelige vrije tekst | Ja, mits categorieën binnen 255 keuzes passen |
| Hoe urgent is dit bericht van de klantenservice? | Niets, of een LLM-aanroep die seconden duurt | Latentie en kosten maken het lastig voor elk bericht | Ja: een score over geordende niveaus |
| Welke leveringsroute moet deze late order opvangen? | Constraint solver | Geen classificatieprobleem | Nee |
| Schrijf de klantbericht-notitie over een vervanging | LLM | Vereist gegenereerde tekst | Nee |
Het patroon is duidelijk. Overal waar ik een LLM gebruik voor een taak die eigenlijk classificatie is (maar vermomd is als chat), is een System One-model een plausbare vervanger met een latentie en kosten die twee ordes van grootte lager liggen. Overal waar handgeschreven regels breken omdat de input vrije tekst is, is het een plausbare vervanging voor die regels. Voor generatie of optimalisatie is het echter het verkeerde instrument.
Ook de integratie met ERP is aantrekkelijk. Een model dat in 100 ms {"is_exception": 0.93} teruggeeft, kan direct in het request-pad zitten. Een LLM die in vier seconden een paragraaf teruggeeft, moet in een queue ernaast staan. Dat verschil bepaalt of ML een feature is of een batch-job.
Claims die ik nog niet accepteer
Enkele punten in het lanceermateriaal verdienen een sceptische blik:
- "Nul hallucinaties": Wat TypeSafe garandeert is dat het output-type altijd geldig is: als je vraagt om één van de vijf categorieën, krijg je er één van de vijf, met waarschijnlijkheden die optellen tot één. Dat is nuttig, maar het zegt niets over of de gekozen categorie correct is. Een zelfverzekerd fout antwoord in een geldig schema is nog steeds een fout antwoord. De eerlijke formulering is "nul schemafouten", en kalibratie moet de rest opvangen.
- Kalibratie op wiens distributie?: Een model kan goed gekalibreerd zijn op zijn trainings- en benchmarkdistributie, maar sterk afwijken op die van jou. Kalibratie is een eigenschap van zowel het model als de dataset. De enige waarde die ik vertrouw, is een waarde die is gemeten op mijn eigen data.
- De vergelijkingsbasis: "200x sneller dan een LLM bij classificatie" is waar, maar ook een beetje oneerlijk. De juiste baseline voor veel van deze taken is namelijk geen LLM, maar een gradient-boosted tree op engineered features, wat ook sub-milliseconde en gratis is. De interessante vergelijking is drieledig: een klassiek tabulair model, LLM-as-classifier en Jev, op basis van accuratesse, rangschikking, kalibratie, latentie en kosten.
Het experiment dat ik wil uitvoeren
Ik heb het ideale testbed al gebouwd: de PR-acceptatiepipeline uit mijn paper. Deze is leakage-aware, heeft vaste 5-fold splits en een gepubliceerde tree-model baseline met een bekende kalibratiezwakte.
Het ontwerp:
- Taak: Gegeven een PR op het moment van indiening, voorspel of deze wordt samengevoegd (merged) of gesloten zonder merge. De Jev-status wordt de PR-titel, body en dezelfde metadata en diff-statistieken die de trees zien, geserialiseerd als tekst. Niets wat na indiening verschijnt (comments, CI, latere commits) komt in de status.
- Vragen: Eén noul: "Deze pull request zal worden samengevoegd." Optioneel één choice over de task-intent tags (fix, feature, refactor, docs) om te zien of Jev's interpretatie van intentie overeenkomt met onze keyword-regels.
- Baselines: De Random Forest (400 trees) uit de paper, dezelfde forest met isotone kalibratie (fitted in-fold), en een frontier LLM met gestructureerde output.
- Metrieken: Rangschikking en kalibratie, niet alleen F1:
- ROC-AUC, zodat het resultaat vergelijkbaar is met de paper.
- Brier score, de gemiddelde kwadratische fout van de waarschijnlijkheid ten opzichte van de uitkomst:
$$\text{Brier} = \frac{1}{N}\sum{i=1}^{N}\left(\hat{p}i - y_i\right)^2$$
- Expected Calibration Error (ECE), waarbij voorspellingen per betrouwbaarheidsniveau worden gegroepeerd en gemeten hoe ver de accuratesse van elke groep afwijkt van de opgegeven betrouwbaarheid:
$$\text{ECE} = \sum{b=1}^{B} \frac{|Sb|}{N}\,\Big|\,\text{acc}(Sb) - \text{conf}(Sb)\,\Big|$$
- Een reliability diagram per model, omdat één ECE-getal maskeert waar een model over- of onder-confident is.
- Mediaan en p95 latentie, en kosten per 1.000 PR's.
Wat zou mijn mening doen veranderen? Als Jev de AUC van de forest evenaart en de gekalibreerde forest verslaat op Brier en ECE, zonder enige post-hoc fitting, dan is de claim over kalibratie echt op een distributie die TypeSafe nooit heeft gezien. In dat geval zou ik classificatie-taken op het werk overzetten naar Jev. Als het de ongekalibreerde forest verslaat maar niet de gekalibreerde, dan is het een gemak, geen nieuwe capaciteit. Als de AUC materieel lager is, doet de snelheid er niet toe.
Wat ik een team vandaag zou adviseren
Als je nu overweegt of Jev relevant is, is mijn advies:
- Inventariseer je LLM-aanroepen. Label elke aanroep als genereren of beslissen. De 'beslissen'-aanroepen zijn kandidaten. In mijn ervaring is dat het grootste deel.
- Meet de kalibratie van wat je al hebt. Bereken de Brier-score en ECE voor je huidige classifiers. Als deze slecht zijn, heb je een probleem dat Jev wellicht oplost. Als ze prima zijn, gaat het vooral om een vraag over latentie en kosten.
- Sla de klassieke baseline niet over. Een gradient-boosted tree op goede features is de standaard. Elk nieuw model moet dit op jouw data, met jouw leakage-regels, verslaan, anders is het geen upgrade.
- Behandel "gekalibreerd" als een hypothese. Test het op jouw distributie voordat een businessregel er afhankelijk van wordt.
Het idee achter System One-modellen is solide: de meeste beslissingen die software van ML nodig heeft, zijn klein, gestructureerd en latentiegevoelig. Een chatmodel is een vreemd instrument voor dat doel. Of Jev de belofte over kalibratie waarmaakt, is een empirische vraag. Ik heb de dataset om dit te beantwoorden, en ik ben van plan dat te doen.
---
Verdere lectuur
- Introducing System One Models & Jev, TypeSafe AI
- Building a harness with Jev, LangChain, voor de request/response vorm
- Predicting Pull Request Acceptance the Moment It’s Opened, mijn verslag van de COMPSAC-paper
- Guo et al., On Calibration of Modern Neural Networks, ICML 2017 (de standaardreferentie voor ECE en temperature scaling)
Voetnoten
- TypeSafe AI, Introducing System One Models & Jev, september 2026. Latentie, snelheidswinst, prijs, cardinaliteit en modaliteitslimieten zijn geciteerd uit deze post en zijn claims van de leverancier.
- LangChain, Building a harness with Jev, september 2026, waarin de state/questions request-vorm en de choice, score en noul vraagtypes worden gedocumenteerd.
- K. Pansuriya, E. Ghorbani, D. Singh, E. A. AlOmar. Predicting Acceptance and Review Effort in Human and Agent Pull Requests. IEEE COMPSAC 2026. arXiv:2607.12057. Tabel II rapporteert RF F1 0,958 / AUC 0,676 en de majority baseline F1 0,957 / AUC 0,500.
Groetjes,