Hur gör man LLM-routing och guardrails? Ett samarbetsexempel mellan Jev och stora språkmodeller

Intresse- och evidensredovisning: PandaNpc utvecklar ett Agent-beslutsfattarlager som använder Jev. Nedan hänvisas separat till TypeSafe officiella dokumentation, officiell cookbook samt riktiga Jev-anrop och syntetiska scenariokalibreringar från vårt arkiv. Vår kalibrering använder en skriptad falsk LLM-provider och kan inte representera verklig användartrafik eller prestanda för en fullständig produktionskedja.

LLM-routing kan göras så här: låt först Jev avgöra vilken typ av begäran det gäller och hur hög risken är, och låt sedan koden besluta om den ska skickas till en vanlig funktion, en specialiserad LLM eller mänsklig granskning. Jev kan också placeras mellan retrieval och generering för att filtrera evidens, eller efter LLM-utdata för att kontrollera resultatet. Det den returnerar är slutna alternativ, poäng och sannolikheter; öppna svar, kodgenerering och lång resonemang utförs fortfarande av LLM. TypeSafe beskrivning av coding agents säger uttryckligen att Jev inte direkt kan ersätta chattmodellen bakom Claude Code eller Codex.

Den här artikeln använder en kundtjänstbegäran, en RAG-fråge- och svarspipeline och vår egen Agent-kalibreringslogg för att förklara var de två modelltyperna faktiskt överlämnar till varandra, och varför resultat med låg konfidens måste ha en tydlig väg.

Vad kan Jev avgöra, och vad fortsätter LLM ansvara för?

Från och med den 23 september 2026 är den stabila modell som listas på TypeSafe modellsida jev-1.13.0. API:et tar emot ett state och en uppsättning `` och returnerar motsvarande struktureradeanswersviaPOST /v1/systemone. jev-latest` pekade den dagen på 1.13.0, men alias kan ändras mellan versioner; system med kalibrerade trösklar bör låsa versionen och logga det faktiska modell-ID:t i svaret.

Noul har inget separat confidence-fält; man kan inte direkt skriva en Noul-sannolikhet som ”modellens konfidens”. Score bör inte heller användas för att beräkna exakta belopp. Belopp, datumjämförelser, kvoter och behörighetskontroller bör stanna i deterministiska program; officiell dokumentation har listat dessa gränser för Jev 1.13.

Minsta form för ett anrop

Anropets form nedan överensstämmer med officiell API-referens; exempelfrågorna är en illustrativ konfiguration skapad för den här artikeln och har inte testats online i den här artikeln:

JSON:en nedan använder ett engelskt kundmeddelande; på svenska skulle kunden säga ”Min order har dubbeldebiterats, vänligen hjälp mig med en återbetalning.”

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

Ett verkligt system bör också först med kod kontrollera om debiteringsposterna tillhör samma order och om återbetalning är tillåten. Exemplet ovan används bara för att tolka användarens avsikt; att användaren begär återbetalning betyder inte att återbetalningsrätten är bevisad, och det utgör inte heller ett direkt mandat att utföra återbetalningen.

Använda Jev för LLM-routing: tre överlämningsvägar

TypeSafe officiella exempel på intent routing skickar först kundtjänstbegäranden till Jev för att bedöma avsikt och komplexitet, och låter sedan koden dirigera dem: orderstatusfrågor går till en databasfunktion; produktfrågor och returer/utbyten går till specialiserade LLM:er som laddats med olika material; komplexa klagomål eller resultat med låg konfidens hamnar i en manuell kö. Detta är det mest lättbegripliga samarbetet mellan Jev och LLM: den förra ger strukturerade bedömningar, den senare träder bara in när en förklaring eller dialog behöver genereras.

Vid implementering kan man designa i följande ordning i stället för att låta modellen fritt bestämma alla åtgärder:

1. Definiera vägarna först: lista tydligt vilka begäranden vanliga funktioner, olika specialiserade LLMer och mänsklig granskning kan hantera, och lämna other eller liknande fallback-alternativ för Choice.
2. Lägg fakta i state: användarens ordalydelse, kontostatus och orderposter blir separata fält; behandla inte webbsidestext med okänt ursprung som systeminstruktioner.
3. Ställ smala frågor en i taget: använd Choice för avsikt, Score för risk eller brådskande grad och Noul för en enskild sak som behöver bekräftas. Officiell rekommendation är att flera oberoende frågor som delar samma state kan utvärderas parallellt i samma begäran.
4. Låt koden göra den slutliga routningen: kontrollera först behörigheter och hårda regler, titta sedan på Jevs sannolikheter och trösklar kalibrerade för den egna verksamheten; begäranden med låg konfidens eller utan evidens går till manuell hantering eller en följdfråga.
5. Logga resultat och granska: spara modellversion, frågeversion, sannolikheter, slutlig väg och resultat av mänsklig rättelse för att kunna bedöma om trösklarna är lämpliga.

Bildkälla: TypeSafe AI ”Introducing System One Models & Jev”, 2026-09-15. De fyra arbetsflödena byggdes av TypeSafe själva, och måtten aggregeras med lika vikt per arbetsflöde; se TypeSafe workflow evals för utvärderingsmetoden.

Den officiella bilden kan hjälpa till att förstå varför man betonar att ”packa in flera smala bedömningar i programarbetsflöden”. Den vertikala axeln i figuren använder leverantörens namn ”accuracy”, men dess referenssvar kommer från konsensus mellan två stora språkmodellers prediktiva sannolikheter, inte ett enda mänskligt verifierat korrekt svar; kostnader och mått beror också på dessa fyra arbetsflöden och leverantörens utvärderingsmetod och kan inte omvandlas till ”hur mycket man kan spara i alla scenarier”.

Retrieval augmented generation: Jev filtrerar evidens innan LLM svarar

TypeSafe RAG passage cookbook ger ett mer konkret exempel med flera modeller: OpenAI embedding hämtar först passageer, Jev ställer fyra Noul-frågor för varje ”fråga + passage” — om den är relevant, om den innehåller evidens som kan användas för att svara, om den motsäger en premiss i frågan och om den försöker ge instruktioner till svarsmodellen. Koden behandlar de fyra sannolikheterna i ordning och avgör om passagen ska läggas i evidensområdet, i området för motstridig evidens eller kastas; slutligen skriver Claude Sonnet 5 svaret.

Detta steg löser ett vanligt problem: passageer med hög vektorsimilaritet är inte nödvändigtvis användbara. De kan bara använda liknande ord, eller så kan ett forum innehålla en prompt injection som säger ”ignorera föregående text”. Cookbookens exempel placerar injektionskontrollen först i routningsreglerna, och påminner samtidigt om att tröskelvärdet är en startpunkt vald för just den korpusen, inte ett defaultvärde för alla RAG-applikationer. Dess demonstrerade siffror kommer från jev-1.12 den 2026-08-27 och kan inte betraktas som nya utvärderingsresultat för aktuell jev-1.13.0.

Efter generering kan man göra ytterligare en kontrollnivå. TypeSafe cookbook för citeringskontroll annder först ett program för att hitta det citerade originaltexten och låter sedan Jev avgöra om passagen stöder, motsäger eller inte nämner det genererade påståendet. Den kan plocka fram citat som är värda att granska; modellens bedömning kan fortfarande vara fel, och ”godkänd kontroll” får inte skrivas som en faktagaranti.

Vår Agent-kalibrering: var fastnar eskalering vid låg konfidens?

I PandaNpc-arkivet använder Jev-klienten, frågebanken och orkestreraren Jev för Agentens avsiktsigenkänning, poängsättning av kandidatändringar, kontroll av slutförandevillkor och bedömning av inlämning. Klienten gör också begränsade återförsök vid timeouts, 429 och 5xx och sätter gränser för förfrågningsbudget och inaktuella resultat; exekveringsbehörighet ligger hos orkestreraren och det kontrollerade verktygslagret och ges inte direkt av ett enskilt Jev-omdöme.

Den 2026-09-22 körde vi med jev-1.13.0 19 syntetiska turns en gång i shadow och en gång i enforce, totalt 38 körningar, och registrerade 165 verkliga Jev-beslut. Denna interna kalibreringsrapport och de sparade svaren från riktig maskin använder en skriptad falsk LLM-provider, så dessa data visar bara beslutsbeteende i kontrollerade scenarier. De kan inte bevisa den övergripande framgångsgraden, besparingsandelen eller end-to-end-latensen för verkliga användarbegäranden.

Den mest värdefulla upptäckten var inte medelhastigheten, utan att en tröskel som ”verkade säker” orsakade blockering: av de 19 turnsen i enforce eskalerade 13 vid Q2 ”är informationen tillräcklig för att börja ändra”, eftersom Noul-sannolikheten hamnade i det ursprungliga osäkerhetsintervallet 0,15–0,85; LLM Worker fick ingen chans att utföra efterföljande steg. Kalibreringsloggen visar att många av 34 Q2-beslut märkta som tillräckligt informativa hade sannolikheter i mitten. Rapporten rekommenderar att dela upp den komplexa Q2 i mer atomära bedömningar eller justera eskaleringsreglerna; dessa är rekommendationer, inte redan driftsatta trösklar.

Vår frågebank klassificerar ingången som answer_only, inspect, modify eller out_of_scope; på skrivvägen sorteras först Workers föreslagna kandidatändringar av Score, och det slutliga innehållet och ändringssammanfattningen genomgår sedan acceptans- och inlämningsbedömning. Dessa är bara beslutspunkter: huruvida objekt faktiskt kan läsas eller skrivas avgörs fortfarande av den kontrollerade exekveraren som beviljar behörighet i faser. Jev har ingen rätt att själv lätta på verktygets vitlista och kan inte kringgå konsekvenskontrollen före inlämning.

Kalibreringsdata avslöjar en annan avvägning. I shadow-läge ger Jev svar och fullständig fördelning men ändrar inte Workers ursprungliga exekveringsväg; i enforce-läge påverkar svaret om arbetet fortsätter, eskalerar eller kastas. Att direkt ta shadow-lägets accuracy som enforce-lägets slutförandegrad blir att missta systemet: Q2-eskalering stoppar uppgiften i förtid, så efterföljande kandidatpoängsättning, acceptans och inlämningsfrågor får aldrig chansen att uppstå. Därför läser rapporten fördelning per fråga, eskaleringsriktning och sluttillstånd separat.

Bland kandidatändringarna finns en konkret jämförelse: i samma turn fick kandidaten som ändrade målet exakt 2,94 poäng, medan kandidaten som skrev över hela filen fick 0,38 poäng; kandidaten med hög poäng valdes. Detta exempel visar bara att poängfrågan skilde mellan två alternativ i det syntetiska scenariot. Omvänt fick en kandidat med trunkerad evidens 2,27 poäng, och man får inte ignorera dess låga konfidens och trunkeringsmarkering bara för att värdet ser ”ganska bra” ut. Vår kod markerar ofullständig evidens separat för att hindra modellen från att fatta ett deterministiskt skrivbeslut enbart utifrån det bevarade prefixet.

Vi delade också upp ”vilken kandidat som väljs” och ”tillåts den skriva” i två olika steg. Efter att en kandidat poängsatts av Jev öppnar den kontrollerade exekveraren skrivverktygast i fasen ACT/modify; den utfärdade engångsbiljetten binder verktygsanropets ID, aktuellt revisionsnummer, målobjektets hash och parametersammanfattning. Även om kandidattexten försöker lura modellen att ”ignorera begränsningar” får den inte verktygsbehörighet som kringgår dessa kontroller. Detta är en erfarenhet från vår integration på kodnivå: sannolikhetsbedömningar avgör vilken väg som är värd att gå, medan sidoeffektsbehörighet avgörs av granskningsbara programvillkor.

Även felvägar måste designas. Klienten gör endast begränsade återförsök vid timeout, nätverksfel, 429 eller 5xx; svar som avbryts eller överskrider turnens tidsgräns kastas direkt. Om Jev inte är tillgänglig i enforce-läge får arbetet inte fortsätta utan auktorisering för nedgradering; om llm_only tillåts låser exekveraren skrivbehörigheten till endast läsning. Om grenen redan har ändrats innan Jev blir otillgänglig markerar orkestreraren hela omgången som misslyckad i stället för att låta efterföljande LLM:er göra skrivningar i efterhand utan beslutsfattarlager. Dessa vägar har en kostnad för användarupplevelsen, men de gör att ”modellen är tillfälligt otillgänglig” inte tyst blir ”skrivbehörigheten är som vanligt”.

Kalibreringsrapporten skiljer också på ”eskalering vid låg konfidens” och ”vägran att utföra”. Till exempel kan en korrekt discard som inte når den enhetliga 0,85-tröskeln registreras som att den behöver användarinmatning; det är inte samma sak som felaktig tillåtelse. Rapporten föreslår därför att separera trösklarna för inlämning och bortkastning, men det är fortfarande en rekommendation. När man skriver arbetsflöden måste man skilja på felaktig tillåtelse, felaktig vägran och väntande granskning, annars kan samma datamängd leda till felaktiga tröskelslutsatser.

Detta fall visar att samspelet mellan Jev och LLM inte bara kan ritas som ”Jev bedömer först, LLM arbetar sedan”. Varje bedömning måste ställa frågan: hur brett är osäkerhetsintervallet? Kommer det att göra att efterföljande processorer aldrig får en uppgift? Om indataevidensen är trunkerad, kan den då tydligt eskalera i stället för att gissa? I vår implementation loggar state-byggaren evidence_truncated och låter anroparen betrakta vägar med saknad evidens som osäkra; deterministiska beräkningar som räkning och sortering görs först i kod och lämnas inte till Jev att gissa. Officiella kända begränsningar för Jev 1.13 rekommenderar också att räkning och aritmetik stannar i koden.

Var ska LLM-guardrails placeras?

TypeSafe cookbook för LLM guardrails placerar Jev på båda sidor om LLM:ens indata och utdata. Den använder en uppsättning Noul för att identifiera olika risker, Score för att mäta allvarlighetsgrad och låter sedan koden enligt policy besluta om tillåtelse, mänsklig granskning, blockering eller vidarebefordran till support. Även utdata måste kontrolleras, eftersom vanliga indata fortfarande kan ge olämpliga genererade resultat.

Gränsen för den här typen av guardrails är också tydlig: Jev kan granska innehåll utifrån förskrivna frågor, men är inte ett universellt säkerhetsbevis. Officiell dokumentation om begränsningar nämner uttryckligen att skadligt innehåll kan påverka bedömningen och kräver att criteria skrivs tydligt och att gränser testas. I vårt syntetiska urval gjordes 16 injektionsprober mot kandidatparametrar, och 0 rangordningsvändningar registrerades; urvalet är för litet för att dra slutsatsen att ”motstånd mot prompt injection är löst”. Det som verkligen avgör vad verktyget kan göra är fortfarande tillåtelselistan, fasgrindarna och kontrollen före inlämning i koden.

När är det lämpligt att använda, och när bör man låta bli?

Jev passar när: kandidatmängden är känd, frågan kan delas upp i några korta bedömningar och programvaran behöver sannolikheter för att avgöra automatisk hantering eller eskalering till människa. Till exempel kundtjänstrouting, RAG-passagefiltrering, poängsättning av Agent-kandidatåtgärder och citeringskontroll i genererade resultat. Om uppgiften kräver att skriva ett svarsbrev, ändra ett kodavsnitt eller förklara en komplex resonemangskedja tar LLM över. Om uppgiften är att räkna pengar exakt, jämföra datum eller kontrollera åtkomststyrning bör programmet räkna direkt. Modellsidan säger också att Jev endast tar emot text och att engelska är det träningsspråk som för närvarande presterar bäst; kinesiska scenarier behöver utvärderas med egna data och kan inte kopiera trösklarna från engelska cookbooks.

Om du vill se hur en verklig Agent hanterar behörigheter och verktygsanrop kan du först titta på PandaNpc Agent; om gränser och användningsområden för coding agents, se även jämförelse mellan Claude Code och Codex.

Läsaren kan börja med en mycket liten valideringsuppsättning: förbered fyra typer av urval — ”uppenbart automatiskt hanterbara”, ”uppenbart avvisningsbara”, ”semantiskt otydliga” och ”innehåller skadliga instruktioner”; fastställ först mänskliga etiketter och logga sedan Jevs sannolikheter per fråga och routningsresultat. Framgångskriteriet är inte att varje post automatiskt godkänns, utan att felfrekvensen på den automatiska hanteringsvägen och mängden manuella eskaleringar båda ligger inom vad du kan acceptera. Om många otydliga urval fastnar på samma fråga bör du först kontrollera om frågan blandar flera bedömningar, om state är för långt eller om trösklarna är kalibrerade mot lokala data.

Vanliga frågor (FAQ)

Kan Jev ersätta Claude Code, Codex eller chattmodeller? Nej. TypeSafe positionerar det som en strukturerad beslutsmodell i programvara; chatt, skrivande och kodgenerering kräver fortfarande LLM.

Betyder fasta returtyper att det inte kan göra fel? Nej. Fasta typer minskar problem med parsning och utdata utanför gränserna, men klassificering, poängsättning och faktabedömningar kan fortfarande bli fel. Vägar med låg konfidens och hög risk bör behålla mänsklig granskning.

Hur många frågor kan man ställa i en och samma begäran? Flera oberoende Choice, Score och Noul som delar samma state kan läggas i en begäran. Frågorna utvärderas var för sig; komplexa bedömningar bör fortfarande delas upp och sedan kombineras av kod.

Fungerar kinesiska? Officiellt stöds naturligt språk inklusive kinesiska, japanska och koreanska tecken, men engelska har för närvarande bäst noggrannhet. Kinesiska arbetsbelastningar behöver separat validering och kalibrering.