Hvordan gjør man LLM-ruting og guardrails? Et samarbeidseksempel mellom Jev og store språkmodeller

Interesse- og evidensavsløring: PandaNpc utvikler et Agent-beslutningslag som bruker Jev. Nedenfor vises det til TypeSafe offisielle dokumentasjon, offisiell cookbook, samt reelle Jev-kall og kalibrering av syntetiske scenarier fra vårt repositorium. Vår kalibrering bruker en skriptbasert falsk LLM-provider og kan ikke representere reell brukertrafikk eller ytelsen til en full produksjonskjede.

LLM-ruting kan gjøres slik: La først Jev avgjøre hvilken kategori forespørselen tilhører og hvor høy risikoen er, og la deretter koden bestemme om den skal sendes til en vanlig funksjon, en spesialisert LLM eller manuell gjennomgang. Jev kan også plasseres mellom gjenfinning og generering for å filtrere evidens, eller etter LLM-utdata for å kontrollere resultatet. Det den returnerer, er lukkede alternativer, score og sannsynligheter; åpne svar, kodegenerering og lang resonnering utføres fortsatt av LLM. TypeSafe sin beskrivelse av coding agents påpeker tydelig at Jev ikke direkte kan erstatte chatmodellen bak Claude Code eller Codex.

Denne artikkelen bruker en kundestøtteforespørsel, en RAG-spørsmål-svar-pipeline og våre egne Agent-kalibreringslogger for å forklare hvor de to modelltypene faktisk overlater til hverandre, og hvorfor resultater med lav konfidens må ha en tydelig destinasjon.

Hva kan Jev avgjøre, og hva fortsetter LLM å ha ansvar for?

Per 23. september 2026 var den stabile modellen som er oppført på TypeSafe-modellsiden, jev-1.13.0. API-et godtar en state og et sett med questions, og returnerer tilsvarende strukturerte answers via POST /v1/systemone. jev-latest pekte denne dagen på 1.13.0, men aliaser endres med versjoner; systemer med kalibrerte terskler bør låse versjonen og logge den faktiske modell-ID-en i responsen.

Noul har ikke et eget confidence-felt; man kan ikke skrive en Noul-sannsynlighet direkte som «modellkonfidens». Score bør heller ikke brukes til å beregne eksakte beløp. Beløp, datosammenligning, kvoter og tilgangskontroller bør forbli i deterministiske programmer; offisielle dokumenter lister opp disse grensene for Jev 1.13.

Den minste formen for ett kall

Forespørselsformen nedenfor samsvarer med offisiell API-referanse, og eksempelspørsmålene er en illustrerende konfigurasjon laget for denne artikkelen; den er ikke testet online i denne artikkelen:

JSON-en nedenfor bruker en engelsk kundemelding; på norsk bokmål ville kunden sagt “Ordren er blitt belastet to ganger, kan du hjelpe meg med å få refundert beløpet?”

{
  "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 reelt system bør også først bruke kode til å kontrollere om belastningene tilhører samme ordre, og om refusjon er tillatt. Eksemplet ovenfor brukes bare til å tolke brukerens intensjon; at brukeren ber om refusjon betyr ikke at refusjonsberettigelsen er bevist, og det utgjør heller ikke autorisasjon til å utføre refusjonen direkte.

Bruk av Jev til LLM-ruting: tre overleveringsveier

TypeSafe offisielle eksempel på intensjonsruting sender kundestøtteforespørsler først til Jev for å vurdere intensjon og kompleksitet, og koden ruter dem deretter: ordrestatus går til en databasefunksjon; produktspørsmål og retur/bytte går til spesialiserte LLM-er lastet med ulike datakilder; komplekse klager eller resultater med lav konfidens går til en manuell kø. Dette er den mest lettforståelige samarbeidsformen mellom Jev og LLM: førstnevnte gir strukturerte vurderinger, sistnevnte trer bare inn når det trengs forklaringer eller dialog.

Når du implementerer, kan du designe i følgende rekkefølge i stedet for å la modellen fritt bestemme alle handlinger:

1. Definer veiene først: List tydelig hvilke forespørsler vanlige funksjoner, de spesialiserte LLM-ene og manuell gjennomgang kan håndtere, og la Choice ha other eller et tilsvarende fallback-alternativ.
2. Legg fakta i state: Brukerens ordlyd, kontostatus og ordreoppføringer blir egne felt; ikke behandle nettekst med ukjent opprinnelse som systeminstruksjoner.
3. Still smale spørsmål om gangen: Bruk Choice for intensjon, Score for risiko eller hastegrad, og Noul for enkeltfakta som må bekreftes. Offisielt anbefales det at flere uavhengige spørsmål med samme state kan vurderes parallelt i én forespørsel.
4. La koden gjøre den endelige rutingen: Kontroller først tillatelser og harde regler, og se deretter på Jeves sannsynligheter og terskler kalibrert for denne virksomheten; forespørsler med lav konfidens eller manglende evidens går til manuell behandling eller oppfølgingsspørsmål.
5. Logg resultater og gjennomgå dem: Lagre modellversjon, spørsmålsversjon, sannsynligheter, endelig destinasjon og resultater av manuell korrigering for å kunne vurdere om tersklene er passende.

Kilde: TypeSafe AI «Introducing System One Models & Jev», 2026-09-15. De fire arbeidsflytene er bygget av TypeSafe selv, og målingene er vektet likt per arbeidsflyt; evalueringsmetoden finnes i TypeSafe workflow evals.

Dette offisielle diagrammet kan hjelpe med å forstå hvorfor det understreker «å pakke flere smale vurderinger inn i en programvarearbeidsflyt». Den vertikale aksen på diagrammet bruker leverandørens navn «accuracy», men referansesvarene kommer fra en konsensus mellom to store modellers predikerte sannsynligheter, ikke fra ett menneskeverifisert riktig svar; kostnadene og målingene avhenger også av disse fire arbeidsflytene og leverandørens evalueringsmetode, og kan ikke konverteres til «hvor mye som kan spares i enhver situasjon».

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

TypeSafe sin RAG passage-cookbook gir et mer konkret eksempel med flere modeller: OpenAI embedding henter først inn avsnitt, og Jev stiller fire Noul-spørsmål for hvert «spørsmål + avsnitt» – om det er relevant, om det inneholder evidens som kan brukes til å svare, om det motsier premissene i spørsmålet, og om det prøver å gi svarmodellen instruksjoner. Koden behandler de fire sannsynlighetene i rekkefølge og bestemmer om avsnittet skal legges i evidensdelen, i delen for motstridende evidens, eller forkastes; til slutt skriver Claude Sonnet 5 svaret.

Dette steget løser et vanlig problem: avsnitt med høy vektorlikhet er ikke nødvendigvis brukbare. De kan bare bruke lignende ord, eller være et foruminnlegg som inneholder en prompt-injeksjon av typen «ignorer teksten over». Cookbook-eksemplet plasserer injeksjonskontrollen først i ruteringsreglene, og minner samtidig om at terskelen er et startpunkt valgt for det korpuset, ikke en standardverdi for alle RAG-applikasjoner. Demonstrasjonstallene kommer fra jev-1.12 den 2026-08-27 og kan ikke betraktes som nye evalueringsresultater for gjeldende jev-1.13.0.

Etter generering kan man også gjøre en ekstra verifisering. TypeSafe sin cookbook for sitatsjekk bruker først et program til å finne det opprinnelige sitatet, og deretter Jev til å avgjøre om avsnittet støtter, motsier eller ikke nevner den genererte påstanden. Det kan plukke ut sitater som fortjener ny gjennomgang; selve modellvurderingen kan fortsatt ta feil, og «bestått kontroll» kan ikke skrives som en faktagaranti.

Vår Agent-kalibrering: hvor stopper eskalering ved lav konfidens?

I PandaNpc-repositoriet bruker Jev-klienten, spørsmålsbanken og orkestratoren Jev til Agentens intensjonsgjenkjenning, scoring av kandidatendringer, kontroll av fullføringsbetingelser og vurdering av innsending. Klienten gjør også begrensede gjenforsøk ved tidsavbrudd, 429 og 5xx, og setter grenser for forespørselsbudsjett og utdaterte resultater; utførelsestillatelser styres av orkestratoren og det kontrollerte verktøylaget, ikke direkte tildelt av en enkelt Jev-vurdering.

Den 2026-09-22 kjørte vi med jev-1.13.0 én shadow og én enforce for hver av 19 syntetiske turn, totalt 38 kjøringer, og loggførte 165 reelle Jev-beslutninger. Denne interne kalibreringsrapporten og de lagrede responsene fra faktiske maskiner bruker en skriptbasert falsk LLM-provider, så disse dataene sier bare noe om beslutningsytelsen i kontrollerte scenarier. De kan ikke bevise den samlede suksessraten, besparelsesandelen eller ende-til-ende-forsinkelsen ved reelle brukerforespørsler.

Det mest verdifulle funnet var ikke gjennomsnittshastigheten, men at en «tilsynelatende trygg» terskel skapte blokkering: av de 19 turnene i enforce ble 13 eskalert ved Q2 «er informasjonen tilstrekkelig til å begynne å endre», fordi Noul-sannsynligheten falt i det opprinnelige usikkerhetsintervallet 0,15–0,85; LLM Worker fikk ikke mulighet til å utføre de neste stegene. Kalibreringsloggen viser at mange av de 34 Q2-beslutningene som var merket som tilstrekkelig informert, hadde sannsynligheter i midtsjiktet. Rapporten foreslår å dele opp det komplekse Q2 i mer atomære vurderinger eller justere eskaleringsreglene; dette er forslag, ikke terskler som allerede er tatt i bruk.

Spørsmålsbanken vår vurderer inngangen som answer_only, inspect, modify eller out_of_scope; på skrivebanen rangeres først kandidatendringene som Worker foreslår, av Score, og det endelige innholdet og endringssammendraget går deretter gjennom godkjenning og innsendingsvurdering. Dette er bare beslutningspunkter: om det faktisk er mulig å lese eller skrive objekter, avgjøres fortsatt av den kontrollerte utføreren som tildeler tillatelser fasevis. Jev har ikke rett til å utvide verktøyets hviteliste selv, og kan ikke omgå konsistenskontrollen før innsending.

Kalibreringsdataene avdekket en annen avveining. I shadow-modus gir Jev svar og full fordeling, men endrer ikke Workerens opprinnelige utførelsesbane; i enforce-modus påvirker svaret om arbeidet skal fortsette, eskaleres eller forkastes. Å bruke shadow-nøyaktigheten direkte som enforce-fullføringsrate vil gi et feil bilde av systemet: Q2-eskalering stopper oppgaven tidlig, slik at senere kandidatscoring, godkjenning og innsendingsspørsmål ikke får noen sjanse til å oppstå. Derfor leser denne rapporten fordelingen per spørsmål, eskaleringsretningen og den endelige tilstanden hver for seg.

Blant kandidatendringene var det en konkret sammenligning: i samme turn fikk kandidaten som endret målet presist, 2,94 poeng, mens kandidaten som overskrev hele filen, fikk 0,38 poeng; kandidaten med høyest score ble valgt. Dette eksemplet viser bare at score-spørsmålet skilte mellom de to alternativene i det syntetiske scenariet. Motsatt fikk en kandidat med avkortet evidens 2,27 poeng, og man kan ikke ignorere dens lave konfens og avkortingsmarkør fordi tallet ser «ganske bra» ut. Koden vår merker ufullstendig evidens separat, for å hindre at modellen gjør en deterministisk skrivevurdering kun basert på det beholdte prefikset.

Vi deler også «hvilken kandidat som velges» og «om den får skrive» inn i to forskjellige steg. Etter at kandidaten er scoret av Jev, åpner den kontrollerte utføreren skriveverktøy bare i ACT/modify-fasen; den utstedte engangsbilletten binder verktøykall-ID, gjeldende revisjonsnummer, målobjektets hash og parametersammendrag. Selv om kandidatteksten skulle lure modellen til å «ignorere begrensningene», får den ikke verktøytillatelser som går utenom disse kontrollene. Dette er erfaringen vår fra kodeintegrasjon: sannsynlighetsvurderinger bestemmer hvilken vei som er verdt å gå, mens rettigheter til bivirkninger avgjøres av etterprøvbare programvilkår.

Feilbaner må også designes. Klienten gjør bare begrensede gjenforsøk ved tidsavbrudd, nettverksfeil, 429 eller 5xx; svar som er kansellert eller har overskredet turn-fristen, forkastes direkte. Hvis Jev ikke er tilgjengelig i enforce-modus, kan arbeidet ikke fortsette uten tillatelse til nedgradering; når llm_only er godkjent, låser utføreren til skrivebeskyttet modus. Hvis grenen allerede er endret før Jev mistes, markerer orkestratoren hele runden som mislykket i stedet for å la senere LLM-er utføre skrivingen på etterskudd uten beslutningslaget. Disse banene har en kostnad for brukeropplevelsen, men de hindrer at «modellen er midlertidig utilgjengelig» stille blir til «skrivetillatelser som før».

Kalibreringsrapporten skiller også mellom «eskalering ved lav konfidens» og «avvisning av utførelse». For eksempel vil en korrekt discard bli registrert som behov for brukerinput hvis konfidensen ikke når den enhetlige terskelen på 0,85; dette er ikke det samme som feil godkjenning. Rapporten foreslår på dette grunnlaget å skille tersklene for innsending og forkasting, men foreløpig er det bare et forslag. Når man skriver arbeidsflyter, må man skille mellom feil godkjenning, feil avvisning og ventende vurdering; ellers kan samme datasett gi feil konklusjoner om terskler.

Denne saken viser at samarbeidet mellom Jev og LLM ikke bare kan tegnes som «Jev vurderer først, LLM jobber etterpå». For hver vurdering må man spørre: Hvor bredt er usikkerhetsintervallet? Kan det føre til at senere behandlere aldri får en oppgave? Hvis inndataevidensen er avkortet, kan man da eksplisitt eskalere i stedet for å gjette? I vår implementasjon logger state-byggeren evidence_truncated og lar kalleren behandle baner med manglende evidens som usikre; deterministiske beregninger som telling og sortering gjøres først i koden og overlates ikke til Jev å gjette. Offisielle kjente begrensninger i Jev 1.13 anbefaler også å holde telling og aritmetikk i koden.

Hvor bør LLM-guardrails plasseres?

TypeSafe sin LLM guardrails-cookbook plasserer Jev på begge sider av LLM-ens input og output. Den bruker et sett med Noul for å identifisere ulike risikoer, Score for å måle alvorlighetsgrad, og koden bestemmer deretter ut fra policy om noe skal slippes gjennom, gjennomgås manuelt, blokkeres eller sendes til kundestøtte. Også output må kontrolleres, fordi vanlige input fortsatt kan gi uegnede genererte resultater.

Grensene for denne typen guardrails er like klare: Jev kan kontrollere innhold etter forhåndsskrevne spørsmål, men er ikke et universelt sikkerhetsbevis. Det offisielle dokumentet om begrensninger nevner tydelig at ondsinnet innhold kan påvirke vurderinger, og krever at criteria skrives tydelig og at grensene testes. I vårt syntetiske utvalg gjorde vi 16 injeksjonsprober rettet mot kandidatparametere og registrerte 0 endringer i rangeringen; utvalget er for lite til å konkludere med at «motstand mot prompt-injeksjon er løst». Det som faktisk bestemmer hva verktøyet kan gjøre, er fortsatt tillatelseslistene, faseportene og kontrollene før innsending i koden.

Når er det egnet å bruke, og når bør man ikke bruke det?

Jev passer når: kandidatsettet er kjent, spørsmålet kan deles opp i noen få korte vurderinger, og programvaren trenger sannsynligheter for å avgjøre automatisk behandling eller eskalering til manuell behandling. For eksempel kundestøtteruting, RAG-avsnittfiltrering, scoring av Agent-kandidathandlinger og sitatkontroll i genererte resultater. Hvis oppgaven krever at man skriver et svarbrev, endrer et kodeavsnitt eller forklarer en kompleks resonneringsprosess, tar LLM over. Hvis oppgaven er å beregne penger nøyaktig, sammenligne datoer eller kontrollere tilgangskontroll, bør programmet beregne det direkte. Modellsiden sier også at Jev bare godtar tekst, og at engelsk er treningsspråket som for tiden presterer best; kinesiskspråklige scenarioer må evalueres med egne data, og tersklene fra engelske cookbooks kan ikke kopieres direkte.

Hvis du vil se hvordan en reell Agent håndterer tillatelser og verktøykall, kan du først se på PandaNpc Agent; om grensene og bruksområdene for kodeagenter, kan du også se sammenligningen av Claude Code og Codex.

Lesere kan starte med et svært lite valideringssett: lag fire typer utvalg – «åpenbart automatisk håndterbare», «åpenbart avvisbare», «semantisk tvetydige» og «inneholder ondsinnede instruksjoner»; fastsett først manuell annotering, og logg deretter sannsynligheter og ruteringsresultater for hvert Jev-spørsmål. Suksesskriteriet er ikke at hver enkelt går automatisk gjennom, men at feilraten i den automatiske behandlingsbanen og mengden manuell eskalering begge ligger innenfor det du kan akseptere. Hvis mange tvetydige utvalg stopper på samme spørsmål, bør du først sjekke om spørsmålet blander flere vurderinger, om state er for lang, eller om tersklene er kalibrert mot lokale data.

Ofte stilte spørsmål (FAQ)

Kan Jev erstatte Claude Code, Codex eller chatmodeller? Nei. TypeSafe posisjonerer det som en strukturert beslutningsmodell inne i programvare; chat, skriving og kodegenerering krever fortsatt LLM.

Betyr faste returtyper at det ikke kan gjøre feil? Nei. Faste typer reduserer problemer med parsing og utdata utenfor grensene, men klassifisering, scoring og faktavurderinger kan fortsatt være feil. Baner med lav konfidens og høy risiko bør beholde manuell gjennomgang.

Hvor mange spørsmål kan man stille i én forespørsel? Man kan legge flere uavhengige Choice, Score og Noul som deler samme state, i én forespørsel. Spørsmålene evalueres hver for seg, komplekse vurderinger bør fortsatt deles opp og deretter kombineres av koden.

Kan kinesisk brukes? Offisielt sies det å støtte naturlig språk, inkludert kinesiske, japanske og koreanske tegn, men engelsk har for tiden best nøyaktighet. Kinesiskspråklige arbeidsbelastninger må valideres og kalibreres separat.