Hoe implementeer je LLM-routering en guardrails? Een samenwerkingsvoorbeeld van Jev en grote taalmodellen

Openbaarmaking van belangen en bewijs: PandaNpc ontwikkelt een Agent-beslissingslaag die Jev gebruikt. Hieronder verwijzen we naar de officiële TypeSafe-documentatie, de officiële cookbook, en naar echte Jev-aanroepen en synthetische scenario-kalibraties uit onze repository. Onze kalibratie gebruikt een gescripte nep-LLM-provider en is niet representatief voor echte gebruikersverkeer of de prestaties van de volledige productieketen.

LLM-routering kan als volgt worden gedaan: laat Jev eerst bepalen tot welke categorie het verzoek behoort en hoe hoog het risico is, en laat code vervolgens beslissen of het naar een gewone functie, een gespecialiseerde LLM of menselijke beoordeling gaat. Jev kan ook tussen retrieval en generatie worden geplaatst om bewijs te filteren, of na de LLM-uitvoer om resultaten te controleren. Het retourneert gesloten opties, scores en waarschijnlijkheden; open antwoorden, codegeneratie en lang redeneren worden nog steeds door de LLM gedaan. TypeSafe's uitleg over coding agents geeft duidelijk aan dat Jev niet direct het chatmodel achter Claude Code of Codex kan vervangen.

Dit artikel gebruikt een klantenserviceverzoek, een RAG-vraag-en-antwoordpijplijn en onze eigen Agent-kalibratieregistratie om uit te leggen waar de twee soorten modellen precies overdragen, en waarom resultaten met lage betrouwbaarheid een duidelijke bestemming moeten hebben.

Wat kan Jev beoordelen en waarvoor blijft de LLM verantwoordelijk?

Met ingang van 23 september 2026 is het stabiele model dat op de TypeSafe-modellenpagina wordt vermeld jev-1.13.0. De API accepteert een state en een set questions, en retourneert via POST /v1/systemone de bijbehorende gestructureerde answers. jev-latest verwees die dag naar 1.13.0, maar aliassen veranderen met versies; systemen met gekalibreerde drempels kunnen beter een vaste versie gebruiken en het werkelijke model-ID in de respons vastleggen.

Noul heeft geen apart confidence-veld; je kunt een Noul-waarschijnlijkheid niet direct als “modelbetrouwbaarheid” opschrijven. Score moet ook niet worden gebruikt om exacte bedragen te berekenen. Bedragen, datumvergelijkingen, quota en machtigingscontroles moeten in deterministische programma's blijven, de officiële documentatie vermeldt deze grenzen van Jev 1.13.

Minimale vorm van één aanroep

De onderstaande aanvraagvorm komt overeen met de officiële API-referentie; de voorbeeldvragen zijn illustratieve configuraties die in dit artikel zijn opgesteld en waarvoor in dit artikel geen online test is uitgevoerd:

De onderstaande JSON gebruikt een Engelstalig klantbericht; in het Nederlands zou de klant zeggen: “Mijn bestelling is dubbel in rekening gebracht, kunt u mij het bedrag terugbetalen?”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Een echt systeem moet ook eerst met code controleren of de afschrijvingen bij dezelfde order horen en of terugbetaling is toegestaan. Het bovenstaande voorbeeld dient alleen om de intentie van de gebruiker te interpreteren; een verzoek om terugbetaling betekent niet dat de terugbetalingsbevoegdheid bewezen, en vormt al helemaal geen macht om de terugbetaling direct uit te voeren.

LLM-routering met Jev: drie overdrachtspaden

TypeSafe's officiële voorbeeld van intentieroutering stuurt klantenserviceverzoeken eerst naar Jev om de intentie en complexiteit te bepalen, en laat code vervolgens routeren: het opvragen van de orderstatus gaat naar een databasefunctie; productvragen en retouren gaan elk naar gespecialiseerde LLM's met verschillende geladen gegevens; complexe klachten of resultaten met lage betrouwbaarheid gaan naar een handmatige wachtrij. Dit is precies de meest begrijpelijke samenwerking tussen Jev en LLM: de eerste geeft gestructureerde beoordelingen, de laatste komt alleen in beeld wanneer er uitleg of dialoog gegenereerd moet worden.

Bij de implementatie kun je de volgende volgorde aanhouden in plaats van het model alle acties vrij te laten beslissen:

1. Definieer eerst de paden: maak duidelijk welke verzoeken gewone functies, gespecialiseerde LLM's en menselijke beoordeling aankunnen, en laat voor Choice een other- of vergelijkbare fallbackoptie open.
2. Zet feiten in state: de oorspronkelijke woorden van de gebruiker, accountstatus en ordergegevens worden aparte velden; behandel webtekst van onbekende herkomst niet als systeeminstructie.
3. Stel één keer een nauwe vraag: gebruik Choice voor intentie, Score voor risico of urgentie, en Noul voor één feit dat bevestigd moet worden. De officiële documentatie raadt aan om meerdere onafhankelijke vragen over dezelfde state parallel in één verzoek te evalueren.
4. Laat code de uiteindelijke routering doen: controleer eerst machtigingen en harde regels, en kijk dan naar Jev's waarschijnlijkheden en op dit bedrijf gekalibreerde drempels; verzoeken met lage confidence of ontbrekend bewijs gaan naar een mens of krijgen een aanvullende vraag.
5. Registreer resultaten en controleer ze: sla de modelversie, vraagversie, waarschijnlijkheden, uiteindelijke bestemming en resultaten van menselijke correctie op, zodat je kunt beoordelen of de drempels geschikt zijn.

Bron: TypeSafe AI《Introducing System One Models & Jev》, 2026-09-15. De vier workflows zijn door TypeSafe zelf gebouwd; indicatoren zijn gelijkgewogen per workflow samengevoegd; zie TypeSafe workflow evals voor de evaluatiemethode.

Deze officiële grafiek kan helpen begrijpen waarom wordt benadrukt dat “meerdere nauwe beoordelingen in een programmaworkflow worden ondergebracht”. De verticale as op de grafiek gebruikt de naam “accuracy” van de leverancier, maar de referentieantwoorden komen uit de consensus van voorspelde waarschijnlijkheden van twee grote modellen, niet uit een door mensen geverifieerd enkelvoudig juist antwoord; kosten en indicatoren hangen ook af van deze vier workflows en de evaluatiemethode van de leverancier, en kunnen niet worden omgerekend naar “hoeveel je in willekeurige scenario's kunt besparen”.

Retrieval-augmented generation: Jev filtert bewijs vóór het LLM-antwoord

TypeSafe's RAG-passage-cookbook biedt een concreter multi-modelvoorbeeld: OpenAI embedding haalt eerst passages op, Jev stelt voor elke “vraag + passage” vier Noul-vragen — of het relevant is, of het bewijs bevat dat gebruikt kan worden voor het antwoord, of het de premisse in de vraag weerspreekt, of het probeert instructies aan het antwoordmodel te geven. Code verwerkt de vier waarschijnlijkheden in volgorde en bepaalt of de passage in de bewijszone, de conflicterende-bewijszone of wordt weggegooid; ten slotte schrijft Claude Sonnet 5 het antwoord.

Deze stap lost een veelvoorkomend probleem op: passages met een hoge vectorovereenkomst zijn niet per se bruikbaar. Ze kunnen alleen vergelijkbare woorden gebruiken, of een forumreactie bevatten met een prompt-injectie zoals “negeer de voorgaande tekst”. Het cookbook-voorbeeld plaatst de injectiecontrole vooraan in de routeringsregels en waarschuwt dat de drempels een startpunt zijn dat voor dat corpus is gekozen, niet de standaardwaarde voor alle RAG-toepassingen. De demonstratiecijfers komen uit jev-1.12 van 2026-08-27 en mogen niet worden gezien als nieuwe evaluatieresultaten voor het huidige jev-1.13.0.

Na de generatie kan nog een controlelaag worden toegevoegd. TypeSafe's cookbook voor bronverwijzingscontrole gebruikt eerst een programma om de originele geciteerde tekst te vinden, en laat Jev vervolgens beoordelen of die passage de gegenereerde bewering ondersteunt, weerspreekt of niet noemt. Het kan citaten eruit pikken die het controleren waard zijn; de beoordeling van het model zelf kan nog steeds fout zijn, dus “door de controle gekomen” mag niet als feitelijke garantie worden geschreven.

Onze Agent-kalibratie: waar loopt de escalatie bij lage confidence vast?

In de PandaNpc-repository gebruiken de Jev-client, de vragenbank en de orchestrator Jev voor intentieherkenning van de Agent, het scoren van kandidaatwijzigingen, het controleren van voltooiingsvoorwaarden en het beoordelen van inzendingen. De client doet ook beperkte herpogingen bij time-outs, 429 en 5xx, en stelt limieten aan het aanvraagbudget en verlopen resultaten; uitvoeringsmachtigingen worden beheerd door de orchestrator en de gecontroleerde tool-laag, niet direct toegekend door één Jev-beoordeling.

Op 2026-09-22 hebben we met jev-1.13.0 voor 19 synthetische turns elk één keer shadow en één keer enforce uitgevoerd, in totaal 38 runs, en 165 echte Jev-beslissingen vastgelegd. Dit interne kalibratierapport en de bewaarde echte machineresponsen gebruiken een gescripte nep-LLM-provider, dus deze gegevens zeggen alleen iets over de beslissingsprestaties in gecontroleerde scenario's. Ze kunnen niet het algehele succespercentage, de besparingsratio of de end-to-end latentie onder echte gebruikersverzoeken bewijzen.

De meest waardevolle bevinding was niet de gemiddelde snelheid, maar een “schijnbaar veilige” drempel die verstopping veroorzaakte: van de 19 turns in enforce werden er 13 geëscaleerd bij Q2 “is de informatie voldoende om met wijzigingen te beginnen”, omdat de Noul-waarschijnlijkheid in het oorspronkelijke onzekerheidsinterval van 0,15–0,85 viel; de LLM Worker kreeg geen kans om de volgende stappen uit te voeren. Het kalibratierapport laat zien dat van de 34 Q2-beslissingen die als informatievoldoende waren gemarkeerd, veel waarschijnlijkheden in het middenbereik lagen. Het rapport adviseert om de complexe Q2 op te splitsen in meer atomaire beoordelingen, of om de escalatieregels aan te passen; dit zijn aanbevelingen, niet reeds geïmplementeerde drempels.

Onze vragenbank classificeert de ingang als answer_only, inspect, modify of out_of_scope; op het schrijfpad worden door de Worker voorgestelde kandidaatwijzigingen eerst door Score gerangschikt, en de uiteindelijke inhoud en wijzigingssamenvatting gaan daarna door acceptatie- en inzendingsbeoordeling. Dit zijn slechts beslissingspunten: of objecten daadwerkelijk gelezen en geschreven kunnen worden, wordt nog steeds per fase toegekend door de gecontroleerde uitvoerder. Jev heeft niet de bevoegdheid om zelf de tool-allowlist te verruimen, en kan de consistentiecontrole vóór inzending niet omzeilen.

De kalibratiegegevens onthulden nog een afweging. In shadow-modus geeft Jev antwoorden en de volledige verdeling, maar verandert het niet het oorspronkelijke uitvoeringspad van de Worker; in enforce-modus beïnvloeden de antwoorden of er wordt doorgegaan, geëscaleerd of weggegooid. De nauwkeurigheid van shadow direct als voltooiingspercentage van enforce zien, geeft een verkeerd beeld van het systeem: escalatie bij Q2 stopt taken voortijdig, waardoor latere kandidaatscores, acceptatie en inzendingsvragen helemaal niet aan bod komen. Daarom leest dit rapport de verdeling per vraag, de escalatiering en de eindstatus apart.

Er was een concrete vergelijking onder de kandidaatwijzigingen: in dezelfde turn kreeg een kandidaat die het doel nauwkeurig wijzigde 2,94 punten, terwijl een kandidaat die het hele bestand overschreef 0,38 punten kreeg; de hoogst scorende kandidaat werd gekozen. Dit voorbeeld laat alleen zien dat de scoringsvraag in dat synthetische scenario twee opties onderscheidde. Omgekeerd kreeg een kandidaat met afgekapt bewijs 2,27 punten; je mag de lage confidence en de afkapmarkering niet negeren alleen omdat het getal er “redelijk” uitziet. Onze code markeert onvolledig bewijs apart, zodat het model niet op basis van alleen het bewaarde voorvoegsel een definitief schrijfbesluit neemt.

We hebben ook “welke kandidaat kiezen” en “toestaan dat deze schrijft” opgesplitst in twee verschillende stappen. Nadat een kandidaat door Jev is gescoord, opent de gecontroleerde uitvoerder schrijftools alleen in de ACT/modify-fase; een eenmalig uitgegeven ticket bindt de toolaanroep-ID, het huidige revisienummer, de hash van het doelobject en de parametersamenvatting. Zelfs als de kandidaattekst het model probeert te verleiden “beperkingen te negeren”, krijgt het geen toolmachtigingen die deze controles omzeilen. Dit is een les uit onze integratie op codeniveau: waarschijnlijkheidsbeoordelingen bepalen welk pad de moeite waard is, maar machtigingen voor neveneffecten worden bepaald door controleerbare programmacondities.

Faalpaden moeten ook worden ontworpen. De client doet alleen beperkte herpogingen bij time-outs, netwerkfouten, 429 of 5xx; antwoorden die na annulering of na de turn-deadline binnenkomen, worden direct weggegooid. Als Jev in enforce-modus niet beschikbaar is, kan het proces niet doorgaan zonder autorisatie voor degradatie; wanneer llm_only is toegestaan, zet de uitvoerder de modus op alleen-lezen. Als een branch al wijzigingen heeft ondergaan voordat Jev wegvalt, markeert de orchestrator de hele ronde als mislukt, in plaats van een latere LLM zonder beslissingslaag de schrijfacties te laten inhalen. Deze paden hebben een prijs voor de gebruikerservaring, maar zorgen ervoor dat “model tijdelijk niet beschikbaar” niet stilletjes verandert in “schrijfrechten blijven zoals voorheen”.

Het kalibratierapport maakte ook onderscheid tussen “escalatie bij lage confidence” en “weigeren uit te voeren”. Een correcte discard wordt bijvoorbeeld geregistreerd als “gebruikersinvoer nodig” als de confidence niet de uniforme drempel van 0,85 haalt; dat is niet hetzelfde als een foutieve goedkeuring. Op basis hiervan adviseert het rapport om de drempels voor inzending en weggooien te splitsen, maar dat is voorlopig nog een advies. Bij het schrijven van workflows moet je onderscheid maken tussen foutieve goedkeuring, foutieve weigering en hangende beoordeling, anders leiden dezelfde gegevens tot verkeerde drempelconclusies.

Deze casus leert ons dat de samenwerking tussen Jev en LLM niet alleen kan worden getekend als “Jev beoordeelt eerst, LLM doet daarna het werk”. Bij elke beoordeling moet je je afvragen: hoe breed is het onzekerheidsinterval? Kan het ervoor zorgen dat volgende processors nooit een taak krijgen? Als het invoerbewijs is afgekapt, kan er dan expliciet worden geëscaleerd in plaats van gegokt? In onze implementatie registreert de state-builder evidence_truncated en laat de aanroeper paden met ontbrekend bewijs als onzeker behandelen; deterministische berekeningen zoals tellen en sorteren worden eerst in code gedaan en niet aan Jev overgelaten om te gokken. De officiële bekende beperkingen van Jev 1.13 adviseren ook om tellen en rekenen in code te houden.

Waar moeten LLM-guardrails worden geplaatst?

TypeSafe's LLM-guardrails-cookbook plaatst Jev aan zowel de invoer- als uitvoerzijde van de LLM. Het gebruikt een set Noul-vragen om verschillende risico's te identificeren, Score om de ernst te meten, en code bepaalt vervolgens op basis van beleid of iets wordt toegestaan, handmatig beoordeeld, geblokkeerd of doorgestuurd naar support. De uitvoer moet ook worden gecontroleerd, omdat gewone invoer nog steeds ongepaste generatieresultaten kan opleveren.

De grenzen van dit soort guardrails zijn ook duidelijk: Jev kan inhoud controleren aan de hand van vooraf geschreven vragen, maar is geen universeel veiligheidsbewijs. De officiële beperkingendocumentatie vermeldt expliciet dat kwaadwillende inhoud de beoordeling kan beïnvloeden en dat criteria duidelijk moeten worden geschreven en grenzen moeten worden getest. In onze synthetische steekproef hebben we 16 injectiesondes op kandidaatparameters uitgevoerd en 0 rangorde-omkeringen geregistreerd; de steekproef is te klein om te concluderen dat “weerbaarheid tegen prompt-injectie is opgelost”. Wat tools daadwerkelijk kunnen doen, wordt nog steeds bepaald door allowlists in code, fase-poorten en controles vóór inzending.

Wanneer is het geschikt en wanneer niet?

Jev is geschikt wanneer: de kandidatenset bekend is, het probleem kan worden opgesplitst in een paar korte beoordelingen, en software waarschijnlijkheden nodig heeft om automatische verwerking of escalatie naar mensen te beslissen. Bijvoorbeeld klantenserviceroutering, RAG-passagefiltering, het scoren van kandidaatacties van een Agent, en bronverwijzingscontrole in gegenereerde resultaten. Als de taak vereist dat er een antwoordbrief wordt geschreven, een stuk code wordt aangepast of een complex redeneerproces wordt uitgelegd, neemt de LLM het over. Als de taak is om geld nauwkeur te berekenen, datums te vergelijken ofangscontrole te controleren, moet het programma direct rekenen. De modellenpagina vermeldt ook dat Jev alleen tekst accepteert en dat Engels momenteel de best presterende trainings taal is; Chinese scenario's moeten met eigen gegevens worden geëvalue en kunnen niet de drempels van een Eng cookbook overnemen.

Als je wilt zien hoe eenchte Agent met machtigingen en toolaanroepen omgaat, kun je eerst naar PandaNpc Agent kijken; voor de gren en gebruiksscenario's van coding agents kun je ook de Vergelijking tussen Claude Code en Codex raadplegen.

Lezers kunnen beginnen met een heel validatieset: bereid vier soorten samples voor — “duidelijk automatisch te verwerken”, “duidelijk te weigeren”, “semantisch vaag” en “bevat kwaadwillende instructies”; bepaal eerst de handmatige labels en registreer daarna de waarschijnlijkheden per Jev-vraag en de routeringsresultaten. Het succes criterium is niet dat elk item automatisch wordt goedgekeurd, maar dat de foutmarge van het automatische verwerkingspad en de hoeveelheid handmatige escalaties binnen een voor jou acceptabel bereik vallen. Als vage samples massaal op dezelfde vraag blijven steken, controleer dan eerst of de vraag meerdere beoordelingen vermengt, of de state te lang is, of de drempels op basis van lokale gegevens zijn gekalibreerd.

FAQ

Kan Jev Claude Code, Codex of chatmodellen vervangen? Nee. TypeSafe positioneert het als een gestructureerd beslissingsmodel binnen software; chatten, schrijven en codegeneratie vereisen nog steeds een LLM.

Betekent een vast retourtype dat er geen fouten meer worden gemaakt? Nee. Vaste typen verminderen problemen met parsing en uitvoer buiten bereik, maar classificatie, scoring en feitelijke beoordelingen kunnen nog steeds fout gaan. Voor paden met lage confidence en hoog risico moet handmatige beoordeling behouden blijven.

Hoeveel vragen kunnen in hetzelfde verzoek worden gesteld? Je kunt meerdere onafhankelijke Choice-, Score- en Noul-vragen die dezelfde state delen in één verzoek plaatsen. De vragen worden afzonderlijk geëvalueerd; complexe beoordelingen moeten nog steeds worden opgesplitst en vervolgens door code worden gecombineerd.

Kan Chinees worden gebruikt? De officiële documentatie zegt dat natuurlijke talen waaronder Chinese, Japanse en Koreaanse tekens worden ondersteund, maar de nauwkeurigheid is momenteel het best voor Engels. Chinese workloads moeten apart worden gevalideerd en gekalibreerd.