Hvordan laver man LLM-routing og guardrails? Et eksempel på samarbejde mellem Jev og store sprogmodeller

Interesse- og evidensoplysning: PandaNpc udvikler et Agent-beslutningslag, der bruger Jev. Nedenfor citeres henholdsvis TypeSafe's officielle dokumentation, officielle cookbook samt rigtige Jev-kald og kalibrering af syntetiske scenarier fra vores repositorium. Vores kalibrering bruger en scriptet falsk LLM-provider og kan ikke repræsentere reel brugertrafik eller ydeevnen i en fuld produktionskædeLLM-routing kan gøres sådan: Lad først Jev afgøre, hvilken type anmodningen tilhører, og hvor høj risikoen er; derefter lader koden afgøre, om den skal sendes til almindelige funktioner, specialiserede LLM'er eller manuel gennemgang. Jev kan også placeres mellem retrieval og generering for at filtrere evidens, eller efter LLM-output for at kontrollere resultatet. Den returnerer lukkede valgmuligheder, scoringer og sandsynligheder; åbne svar, kodegenerering og lang ræsonnering udføres fortsat af LLM'en. TypeSafe's forklaring om coding agents gør det klart, at Jev ikke direkte kan erstatte chatmodellen bag Claude Code eller Codex.

Denne artikel bruger en kundeserviceanmodning, en RAG-spørgsmål-svar-pipeline og vores egen Agent-kalibreringslog til at forklare, hvor de to typer modeller egentlig overlapper, og hvorfor resultater med lav confidence skal have et klart sted at gå hen.

Hvad kan Jev afgøre, og hvad fortsætter LLM med at have ansvaret for?

Pr. 23. september 2026 er den stabile model på TypeSafe's modelside jev-1.13.0. API'en accepterer en state og et sæt questions og returnerer tilsvarende strukturerede answers via POST /v1/systemone. jev-latest pegede den dag på 1.13.0, men aliaset ændrer sig med versioner; systemer med kalibrerede tærskler bør fastlåse versionen og registrere det faktiske model-ID i svaret.

Noul har ikke et separat confidence-felt; man kan ikke direkte skrive en Noul-sandsynlighed som “modellens confidence”. Score bør heller ikke bruges til at beregne præcise beløb. Beløb, datosammenligninger, kvoter og rettighedskontroller bør blive i deterministiske programmer; de officielle dokumenter har oplistet disse grænser for Jev 1.13.

Den mindste form for et kald

Anmodningsformen nedenfor svarer til den officielle API-reference; eksempelspørgsmålene er en illustrativ konfiguration konstrueret til denne artikel og er ikke testet online i denne artikel:

JSON'en nedenfor bruger en engelsk kundebesked; på dansk ville kunden sige “Jeg er blevet opkrævet to gange for min ordre, kan du hjælpe mig med at få refunderet beløbet?”

{
  "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?"
    }
  }
}

Et faktisk system bør også først med kode kontrollere, om debiteringsposterne tilhører samme ordre, og om refundering er tilladt. Ovenstående eksempel bruges kun til at fortolke brugerens intention; at brugeren beder om refundering betyder ikke, at refunderingsberettigelsen er bevist, og det udgør slet ikke en autorisation til at udføre refunderingen direkte.

Brug af Jev til LLM-routing: tre overleveringsveje

TypeSafe's officielle eksempel på intention-routing sender først kundeserviceanmodninger til Jev for at afgøre intention og kompleksitet, hvorefter koden fordeler dem: ordrestatus går til en databasefunktion; produktspørgsmål og returnering/ombytning går til specialiserede LLM'er indlæst med forskellige materialer; komplekse klager eller resultater med lav confidence går i en manuel kø. Det er netop det mest forståelige samarbejde mellem Jev og LLM: førstnævnte giver en struktureret vurdering, sidstnævnte træder kun ind, når der skal genereres forklaringer eller dialog.

Ved implementering kan man designe i følgende rækkefølge i stedet for at lade modellen frit beslutte alle handlinger:

1. Definér først vejene: Lav en klar liste over hvilke anmodninger almindelige funktioner, hver specialiseret LLM og manuel gennemgang kan håndtere, og giv Choice en other eller tilsvarende fallback-mulighed.
2. Læg fakta ind i state: Brugerens ordlyd, kontostatus og ordreposter bliver separate felter; behandl ikke webtekst med ukendt oprindelse som systeminstruktioner.
3. Stil snævre spørgsmål ad gangen: Brug Choice til intention, Score til risiko eller urgency, og Noul til enkelte fakta, der skal bekræftes. Officielt anbefales det, at flere uafhængige spørgsmål med samme state kan evalueres parallelt i samme anmodning.
4. Lad koden foretage den endelige routing: Kontrollér først rettigheder og hårde regler, og se derefter på Jevs sandsynligheder og de tærskler, der er kalibreret til denne forretning; anmodninger med lav confidence eller manglende evidens går til manuel behandling eller opfølgende spørgsmål.
5. Logfør resultater og følg op: Gem modelversion, spørgsmålsversion, sandsynliger, endelig destination og resultater af manuelletelser, først da kan man vurdere, om tærsklerne er passende

Kilde: TypeSafe AI: »Introducing System One Models & Jev«, 15. september 2026. De fire workflows er egenudviklede af TypeSafe, og metrikkerne er aggregeret med lige vægt pr. workflow; evalueringsmetoden findes i TypeSafe workflow-evalueringer.

Dette officielle diagram kan hjælpe med at forstå, hvorfor det understreges, at man skal “sætte flere snævre vurderinger ind i et programworkflow”. Den lodrette akse på figuren bruger leverandørens navn “accuracy”, men reference-svaret kommer fra konsensus mellem to store sprogmodellers forudsagte sandsynligheder og er ikke et menneskeligt verificeret, entydigt korrekt svar; omkostninger og metrikker afhænger også af disse fire workflows og leverandørens evalueringsmetode og kan ikke omregnes til “hvor meget man kan spare i ethvert scenarie”.

Retrieval-augmented generation: Jev filtrerer evidens, før LLM'en svarer

TypeSafe's RAG passage-cookbook giver et mere konkret multi-model-eksempel: OpenAI-embedding henter først passager, og Jev stiller fire Noul-spørgsmål til hvert “spørgsmål + passage” — om den er relevant, om den indeholder evidens, der kan bruges til at svare, om den modsiger præmissen i spørgsmålet, og om den forsøger at give svarmodellen instruktioner. Koden behandler de fire sandsynligheder i rækkefølge og beslutter, om passagen skal i evidensområdet, i konflikt-evidence-området eller kasseres; til sidst skriver Claude Sonnet 5 svaret.

Dette trin løser et almindeligt problem: passager med høj vektorsimilaritet er ikke nødvendigvis brugbare. De kan blot bruge lignende ord, eller de kan være et forumindlæg med en prompt injection som “ignorér det foregående”. Cookbookens eksempel placerer injektionskontrollen først i routingreglerne og minder samtidig om, at tærsklerne er et valgt udgangspunkt for netop det korpus og ikke standardværdier for alle RAG-applikationer. Dets demonstrationsdata kommer fra jev-1.12 den 27. august 2026 og kan ikke betragtes som nye evalueringsresultater for det aktuelle jev-1.13.0.

Efter genereringen kan man lave endnu et kontrolag. TypeSafe's citation check-cookbook finder først den citerede originaltekst med et program og bruger derefter Jev til at vurdere, om passagen støtter, modsiger eller slet ikke nævner den genererede påstand. Den kan udpege citater, der fortjener en nærmere gennemgang; modelvurderingen kan stadig tage fejl, og “bestået kontrol” kan ikke skrives som en faktuel garanti.

Vores Agent-kalibrering: hvor går opgradering ved lav confidence i stå?

I PandaNpc-repositoriet bruger Jev-klienten, spørgsmålsbanken og orkestratoren Jev til Agentens intentionsgenkendelse, scoring af kandidatændringer, kontrol af færdiggørelsesbetingelser og commit-vurdering. Klienten laver også begrænsede gentagelser ved timeout, 429 og 5xx og sætter grænser for anmodningsbudget og forældede resultater; udførelsesrettigheder styres af orkestratoren og det kontrollerede værktøjslag og tildeles ikke direkte af en enkelt Jev-vurdering.

Den 22. september 2026 kørte vi med jev-1.13.0 én shadow- og én enforce-kørsel for hver af 19 syntetiske turns, i alt 38 kørsler, og registrerede 165 rigtige Jev-beslutninger. Denne interne kalibreringsrapport og de gemte svar fra rigtige maskiner bruger en scriptet falsk LLM-provider, så dataene viser kun beslutningsadfærd i kontrollerede scenarier. De kan ikke bevise den samlede succesrate, besparelsesprocent eller end-to-end-latens under rigtige brugeranmodninger.

Det mest værdifulde fund var ikke gennemsnitshastigheden, men at en “tilsyneladende sikker” tærskel skabte blokering: I de 19 enforce-turns blev 13 eskaleret ved Q2 “er informationen tilstrækkelig til at begynde ændringer”, fordi Noul-sandsynligheden faldt i det oprindeligt fastsatte usikkerhedsinterval på 0,15–0,85; LLM Worker fik ikke mulighed for at udføre de efterfølgende trin. Kalibreringsloggen viser, at mange af de 34 Q2-beslutninger, der var markeret som tilstrækkeligt informerede, havde sandsynligheder i mellemområdet. Rapporten anbefaler at opdele det komplekse Q2 i mere atomare vurderinger eller justere eskaleringsreglerne; disse er anbefalinger, ikke allerede implementerede tærskler.

Vores spørgsmålsbank klassificerer indgangen som answer_only, inspect, modify eller out_of_scope; på skrivevejen rangeres Workerens foreslåede kandidatændringer først af Score, og det endelige indhold og ændringsresuméet gennemgår derefter accept- og commit-vurdering. Dette er kun beslutningspunkter: hvorvidt der faktisk kan læses og skrives objekter, afgøres fortsat af den kontrollerede executor, som tildeler rettigheder fasevis. Jev har ikke ret til selv at lempe værktøjsallowlisten og kan heller ikke omgå konsistenskontrollen før commit.

Kalibreringsdataene afslørede en anden afvejning. I shadow-tilstand giver Jev svar og den fulde fordeling, men ændrer ikke Workerens oprindelige udførelsesvej; i enforce-tilstand påvirker svaret, om der fortsættes, eskaleres eller kasseres. Hvis man direkte bruger shadowens nøjagtighed som enforceens fuldførelsesrate, misforstår man systemet: Q2-escaleringen stopper opgaven tidligt og giver de efterfølgende kandidatscorings-, accept- og commit-spørgsmål nul chance for at opstå. Derfor læser denne rapport fordelingen pr. spørgsmål, eskaleringsretningen og den endelige status hver for sig.

Der var en konkret sammenligning mellem kandidatændringer: I samme turn fik kandidaten med præcis målrettet ændring 2,94 point, mens kandidaten med overskrivning af hele filen fik 0,38 point; kandidaten med høj score blev valgt. Dette eksempel viser kun, at score-spørgsmålet skelnede mellem to løsninger i dette syntetiske scenarie. Omvendt fik en kandidat med afskåret evidens 2,27 point, og man må ikke ignorere dens lave confidence og trunkeringsmarkering, bare fordi tallet ser “nogenlunde” ud. Vores kode markerer ufuldstændig evidens separat for at forhindre modellen i at træffe en deterministisk skrivebeslutning alene ud fra det bevarede præfiks.

Vi har også opdelt “hvilken kandidat vælges” og “tilladelse til at skrive den” i to forskellige trin. Efter at en kandidat er scoret af Jev, åbner den kontrollerede executor kun skriveværktøjer i ACT/modify-fasen; den udstedte engangsbillet binder værktøjskaldets ID, det aktuelle revisionsnummer, målobjektets hash og parameteroversigten. Selv hvis kandidatteksten lokker modellen til at “ignorere begrænsninger”, får den ikke værktøjsrettigheder, der kan omgå disse kontroller. Det er erfaringen fra vores integration på kodeniveau: sandsynlighedsvurderinger afgør, hvilken vej der er værd at gå, mens rettigheder til bivirkninger afgøres af efterprøvelige programbetingelser.

Fejlveje skal også designes. Klienten laver kun begrænsede gentagelser ved timeout, netværksfejl, 429 eller 5xx; svar, der er annulleret eller overskrider turnens deadline, kasseres direkte. Hvis Jev ikke er tilgængelig i enforce-tilstand, kan man ikke fortsætte uden autorisation til nedgradering; hvis man får lov at køre llm_only, låser executoren til skrivebeskyttet. Hvis grenen allerede er ændret, før Jev mistes, markerer orkestratoren hele runden som mislykket i stedet for at lade en efterfølgende LLM udføre skriveoperationer uden beslutningslaget. Disse veje har en pris for brugeroplevelsen, men forhindrer, at “modellen er midlertidigt utilgængelig” stille og roligt bliver til “skriverettigheder som før”.

Kalibreringsrapporten skelnede også mellem “opgradering ved lav confidence” og “afvisning af udførelse”. For eksempel blev en korrekt discard registreret som behov for brugerinput, hvis confidence ikke nåede den fælles tærskel på 0,85; det er ikke det samme som fejlagtig tilladelse. Rapporten anbefaler derfor at opdele tærsklerne for commit og discard, men det er stadig kun en anbefaling. Når man skriver workflows, skal man skelne mellem fejlagtig tilladelse, fejlagtig afvisning og afventende resultater; ellers kan samme datasæt føre til forkerte tærskelkonklusioner.

Denne case viser, at samspillet mellem Jev og LLM ikke bare kan tegnes som “Jev vurderer først, LLM arbejder bagefter”. For hver vurdering skal man spørge: Hvor bredt er usikkerhedsintervallet? Vil det forhindre efterfølgende behandlere i nogensinde at få en opgave? Hvis input-evidensen er afskåret, kan man så eksplicit eskalere i stedet for at gætte? I vores implementering registrerer state-byggeren evidence_truncated og lader kalderen betragte veje med manglende evidens som usikre; deterministiske beregninger som optælling og sortering udføres først i koden og overlades ikke til Jev at gætte. De officielle kendte begrænsninger for Jev 1.13 anbefaler også at lade optælling og aritmetik blive i koden.

Hvor skal LLM-guardrails placeres?

TypeSafe's LLM guardrails-cookbook placerer Jev på både input- ogiden af LLM'en. Den bruger et sæt Noul til at identificere forskellige risici, Score til at måle alvor, og dere beslutter koden ud fra politik, om der skal tillades, gennemgås manuelt, bleres eller sendes videre til support. Output skal også kontrolleres, fordi almindeligt input stadig kan give uhensigtsmæssige genererede resultater.

Grænserne for denne type guardrails er lige så klare: Jev kan kontrollere indhold ud fra forudskrevne spørgsmål, men er ikke et universelt sikkerhedsbevis. Det officielle begrænsningsdokument nævner eksplicit, at ondsindet indhold kan påvirke vurderingen, og kræver, at criteria skrives klart, og at grænser testes. I vores syntetiske prøver udførte vi 16 injektionsprober mod kandidatparametre og registrerede 0 rangordningsvendinger; prøven er for lille til at konkludere, at “modstand mod prompt injection er løst”. Det, der reelt afgør, hvad værktøjer kan gøre, er stadig allowlister, fasegates og kontrol før commit i koden.

Hvornår er det velegnet at bruge, og hvornår bør man lade være?

Jev er velegnet, når kandidatsættet er kendt, spørgsmålet kan opdeles i få korte vurderinger, og softwaren har brug for sandsynligheder til at beslutte automatisk behandling eller eskalering til manuel behandling. For eksempel kundeservicerouting, RAG-passagefiltrering, scoring af Agent-kandidathandlinger og citationskontrol i genererede resultater. Hvis opgaven kræver at skrive et svarbrev, ændre et kodestykke eller forklare en kompleks ræsonneringsproces, overtager LLM'en. Hvis opgaven er at regne præcist på penge, sammenligne datoer eller kontrollere adgangskontrol, bør programmet beregne det direkte. Modelsiden forklarer også, at Jev kun accepterer tekst, og at engelsk i øjeblikket er det bedst præsterende træningssprog; kinesiske scenarier skal evalueres med egne data, og man kan ikke direkte kopiere tærsklerne fra engelske cookbooks.

Hvis man vil se, hvordan en rigtig Agent håndterer rettigheder og værktøjskald, kan man først se på PandaNpc Agent; om grænser og anvendelsesscenarier for coding agents kan man også se Claude Code vs. Codex-sammenligning.

Læseren kan starte med et meget lille valideringssæt: forbered fire typer prøver — “klart automatisk håndterbare”, “klart afvisningsværdige”, “semantisk uklare” og “indeholder ondsindede instruktioner”; fastlæg først de manuelle annoteringer, og registrér derefter Jevs sandsynligheder pr. spørgsmål og routingresultater. Succeskriteriet er ikke, at hver enkelt automatisk passerer, men at fejlraten på den automatiske behandlingsvej og mængden af manuelle eskaleringer begge ligger inden for det, du kan acceptere. Hvis mange uklare prøver hænger fast i samme spørgsmål, skal man først kontrollere, om spørgsmålet blander flere vurderinger, om state er for lang, eller om tærsklerne er kalibreret efter lokale data.

FAQ

Kan Jev erstatte Claude Code, Codex eller chatmodeller? Nej. TypeSafe positionerer det som en struktureret beslutningsmodel i software; chat, skrivning og kodegenerering kræver stadig en LLM.

Betyder faste returtyper, at man ikke kan tage fejl? Nej. Faste typer reducerer problemer med parsing og output uden for grænserne, men klassificering, scoring og faktavurderinger kan stadig være forkerte. Veje med lav confidence og høj risiko bør bevare manuel gennemgang.

Hvor mange spørgsmål kan man stille i samme anmodning? Man kan placere flere uafhængige Choice-, Score- og Noul-spørgsmål, der deler samme state, i én anmodning. Spørgsmålene evalueres hver for sig, og komplekse vurderinger bør stadig opdeles og derefter kombineres af koden.

Kan kinesisk bruges? Officielt siges det at understøtte naturligt sprog, herunder kinesiske, japanske og koreanske tegn, men engelsk har i øjeblikket den bedste nøjagtighed. Kinesiske arbejdsbelastninger kræver separat validering og kalibrering.