Miten LLM-reititys ja suojakaiteet tehdään? Esimerkki Jevin ja suurten kielimallien yhteistyöstä

Eturistiriita- ja näyttöilmoitus: PandaNpc kehittää Agent-päätöksentekokerrosta, joka käyttää Jeviä. Jäljempänä viitataan erikseen TypeSafen viralliseen dokumentaatioon, viralliseen cookbookiin sekä repositoriomme todellisiin Jev-kutsuihin ja synteettisten skenaarioiden kalibrointiin. Kalibrointimme käyttää skriptattua tekaistua LLM-tarjoajaa, eikä se edusta todellista käyttäjäliikennettä tai koko tuotantoketjun suorituskykyä.

LLM-reititys voi toimia näin: annetaan ensin Jevin päätellä, mihin luokkaan pyyntö kuuluu ja kuinka suuri riski siihen liittyy, minkä jälkeen koodi päättää, ohjataanko se tavalliselle funktiolle, erikoistuneelle LLM:lle vai ihmisen tarkistettavaksi. Jev voidaan sijoittaa myös haun ja generoinnin väliin suodattamaan todisteita tai LLM:n tuottaman vastauksen jälkeen tarkistamaan tulosta. Se palauttaa suljettuja vaihtoehtoja, pisteytyksiä ja todennäköisyyksiä; avoimet vastaukset, koodin generointi ja pitkä päättely jäävät edelleen LLM:n tehtäviksi. TypeSafen kuvaus koodausagenteista toteaa selvästi, että Jev ei voi suoraan korvata Claude Coden tai Codexin taustalla olevaa chat-mallia.

Tämä artikkeli käyttää asiakaspalvelupyyntöä, RAG-kysymys-vastausputkea ja omaa Agent-kalibrointitietoamme selittääkseen, missä kahdenlaisten mallien työnjako tarkalleen tapahtuu ja miksi matalan luottamuksen tuloksilla on oltava selkeä määränpää.

Mitä Jev pystyy päättelemään ja mistä LLM vastaa edelleen?

23.9.2026 mennessä TypeSafen mallisivu listaa vakaaksi malliksi jev-1.13.0. API hyväksyy yhden state-arvon ja joukon questions-kysymyksiä ja palauttaa vastaavat strukturoidut answers-vastaukset komennolla POST /v1/systemone. jev-latest viittasi tuona päivänä versioon 1.13.0, mutta aliakset muuttuvat versioiden mukana; järjestelmän, jonka kynnysarvot on kalibroitu, kannattaa kiinnittää versio ja tallentaa vastauksesta todellinen mallitunnus.

Noulissa ei ole erillistä confidence-kenttää; Noul-todennäköisyyttä ei voi kirjoittaa suoraan "mallin luottamukseksi". Score-arvoa ei myöskään pidä käyttää tarkan rahamäärän laskemiseen. Rahamäärät, päivämäärien vertailu, kiintiöt ja käyttöoikeustarkistukset on jätettävä deterministiseen ohjelmaan, ja virallinen dokumentaatio on luetellut nämä Jev 1.13:n rajat.

Yhden kutsun vähimmäismuoto

Alla oleva pyynnön muoto vastaa virallista API-viitettä; esimerkkikysymykset ovat tässä artikkelissa rakennettuja havainnollistavia asetuksia, eikä niitä ole testattu verkossa tätä artikkelia varten:

Alla olevassa JSONissa käytetään englanninkielistä asiakasviestiä, kun taas suomeksi asiakas sanoisi: “Tilauksesta veloitettiin kahteen kertaan, joten pyydän hyvitystä.”

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

Todellisen järjestelmän tulisi myös ensin koodilla tarkistaa, kuuluvatko veloitukset samaan tilaukseen ja sallitaanko hyvitys. Yllä oleva esimerkki on tarkoitettu vain käyttäjän aikomuksen tulkintaan; käyttäjän pyyntö hyvityksestä ei tarkoita, että hyvityskelpoisuus olisi todistettu, eikä se muodosta suoraa valtuutusta hyvityksen suorittamiseen.

LLM-reititys Jevin avulla: kolme työnjakopolkua

TypeSafen virallinen esimerkki aikomusten reitityksestä antaa asiakaspalvelupyynnön ensin Jevin arvioitavaksi aikomuksen ja monimutkaisuuden osalta, minkä jälkeen koodi jakaa sen eteenpäin: tilauksen tilan tarkistus ohjataan tietokantafunktiolle; tuotekysymykset ja palautukset/vaihdot ohjataan erikoistuneille LLM:ille, joille on ladattu eri aineistoja; monimutkaiset valitukset tai matalan luottamuksen tulokset siirretään ihmisjonoon. Tämä on helpoimmin ymmärrettävä Jevin ja LLM:n yhteistyömuoto: edellinen antaa strukturoidun arvion, jälkimmäinen astuu esiin vain, kun tarvitaan selityksen tai keskustelun tuottamista.

Käyttöönotossa voi suunnitella seuraavan järjestyksen sen sijaan, että antaisi mallin vapaasti päättää kaikista toiminnoista:

1. Määritä ensin polut: luettele selkeästi pyynnöt, joita tavalliset funktiot, kukin erikoistunut LLM ja ihmistarkistus voivat käsitellä, ja jätä Choicelle other tai vastaava varavaihtoehto.
2. Sijoita tosiasiat stateen: käyttäjän alkuperäiset sanat, tilin tila ja tilausmerkinnät eri kentiksi; älä käsittele tuntemattomasta lähteestä peräisin olevaa verkkosivutekstiä järjestelmäohjeena.
3. Kysy kapeita kysymyksiä yksi kerrallaan: käytä aikomukseen Choicea, riskiin tai kiireellisyyteen Scorea ja vahvistettavaan yksittäiseen tosiasiaan Noula. Virallinen suositus on, että useita samaan stateen liittyviä riippumattomia kysymyksiä voidaan arvioida rinnakkain samassa pyynnössä.
4. Anna koodin tehdä lopullinen reititys: tarkista ensin käyttöoikeudet ja kovat säännöt, sitten Jevin todennäköisyydet ja tähän liiketoimintaan kalibroidut kynnysarvot; matalan luottamuksen tai puuttuvien todisteiden pyynnöt ohjataan ihmiselle tai lisäkysymyksiin.
5. Tallenna tulokset ja tarkista ne: tallenna malliversio, kysymysversio, todennäköisyydet, lopullinen kohde ja ihmisen tekemät korjaukset, jotta kynnysarvojen sopivuutta voidaan arvioida.

Kuvan lähde: TypeSafe AI "Introducing System One Models & Jev", 15.9.2026. Neljä työnkulkua on TypeSafen itse rakentamia, ja mittarit on koottu työnkulkuittain yhtä suurin painoin; arviointimenetelmä on kuvattu osoitteessa TypeSafe workflow evals.

Tämä virallinen kaavio auttaa ymmärtämään, miksi se korostaa "useiden kapeiden päätösten sovittamista ohjelmatyönkulkuun". Kaavion pystyakseli käyttää valmistajan "accuracy"-nimeä, mutta sen vertailuvastaukset tulevat kahden suuren mallin ennustetodennäköisyyksien yhteisymmärryksestä, eivät ihmisen vahvistamasta ainoasta oikeasta vastauksesta; kustannukset ja mittarit riippuvat myös näistä neljästä työnkulusta ja valmistajan arviointimenetelmästä, eikä niitä voi muuntaa väitteeksi "kuinka paljon missä tahansa skenaariossa voidaan säästää".

RAG-pohjainen generointi: Jev suodattaa todisteita ennen LLM:n vastausta

TypeSafen RAG-kappaleiden cookbook tarjoaa konkreettisemman monimalliesimerkin: OpenAI embedding hakee ensin kappaleet, ja Jev kysyy jokaisesta "kysymys + kappale" -parista neljä Noul-kysymystä – liittyykö se aiheeseen, sisältääkö se vastaamiseen käytettävää näyttöä, onko se ristiriidassa kysymyksen oletuksen kanssa ja yrittääkö se antaa ohjeita vastaavalle mallille. Koodi käsittelee neljä todennäköisyyttä järjestyksessä ja päättää, laitetaanko kappale todistealueeseen, ristiriitaisten todisteiden alueeseen vai hylätäänkö se; lopuksi Claude Sonnet 5 kirjoittaa vastauksen.

Tämä vaihe ratkaisee yleisen ongelman: korkean vektorisamankaltaisuuden kappale ei välttämättä ole käyttökelpoinen. Se voi käyttää vain samankaltaisia sanoja, tai keskustelupalstan viestiin voi olla upotettu "ohita edellinen teksti" -tyyppinen prompt injection. Cookbookin esimerkissä injektiotarkistus on sijoitettu reitityssääntöjen kärkeen, ja samalla muistutetaan, että kynnysarvot on valittu kyseisen korpuksen lähtökohdaksi, eivät kaikkien RAG-sovellusten oletusarvoiksi. Sen esittämät luvut ovat peräisin 27.8.2026 versiosta jev-1.12, eikä niitä pidä pitää nykyisen jev-1.13.0:n uusina arviointituloksina.

Generoinn jälkeen voidaan tehdä vielä yksi tarkistuskerros. TypeSafen sitaattien tarkistus -cook etsii ensin ohjelmalla sitaatin alkuperäistekstin ja antaa sitten Jevin arvioida, tukeeko kyseinen kohta generoitua väitettä, kumoaa sen vai ei mainitse sitä lainkaan. Se pystyy nostamaan esiin sitaatit, jotka kannattaa tarkistaa uudelleen; mallin arvio voi silti mennä väärin, eikä "tarkistuksen läpäisyä" pidä kirjoittaa faktatakuuksi.

Agent-kalibrointimme: mihin matalan luottamuksen eskalaatio juuttuu?

PandaNpc:n repositoriossa Jev-asiakas, kysymyspankki ja orkestroija käyttävät Jeviä Agentin aikomuksen tunnistamiseen, ehdokasmuutosten pisteytykseen, valmistumisehtojen tarkistukseen ja lähetyksen arviointiin. Asiakas tekee myös rajoitettuja uudelleenyrityksiä aikakatkaisujen, 429- ja 5xx-virheiden yhteydessä sekä asettaa rajat pyyntöbudjetille ja vanhentuneille tuloksille; suoritusoikeudet ovat orkestroijan ja hallitun työkalukerroksen hallussa, eikä Jev myönnä niitä yhdellä arviollaan suoraan.

22.9.2026 ajoimme jev-1.13.0:lla 19 synteettiselle turnille kerran shadow- ja kerran enforce-ajon, yhteensä 38 ajoa, ja tallensimme 165 todellista Jev-päätöstä. Tämä sisäinen kalibrointiraportti ja tallennetut oikean koneen vastaukset käyttävät skriptattua tekaistua LLM-tarjoajaa, joten nämä tiedot kuvaavat päätöksentekoa vain hallituissa skenaarioissa. Ne eivät todista kokonaismenestysastetta, säästöosuutta tai päästä päähän -viivettä todellisissa käyttäjäpyynnöissä.

Arvokkain löydös ei ollut keskimääräinen nopeus, vaan se, että "näennäisesti turvallinen" kynnys aiheutti ruuhkan: enforce-ajon 19 turnista 13 eskaloitui Q2-kohdassa "onko tietoa tarpeeksi muutoksen aloittamiseen", koska Noul-todennäköisyys osui alun perin määritettyyn 0,15–0,85 epävarmuusväliin; LLM Workerilla ei ollut mahdollisuutta suorittaa seuraavia vaiheita. Kalibrointitietueet osoittavat, että 34:stä Q2-päätöksestä, jotka oli merkitty riittävästi informoiduiksi, monen todennäköisyys oli keskivaiheilla. Raportti suosittaa monimutkaisen Q2:n jakamista atomisempiin päätöksiin tai eskalaatiosääntöjen säätämistä; nämä ovat suosituksia, eivät jo käyttöönotettuja kynnysarvoja.

Kysymyspankkimme luokittelee sisääntulon answer_only-, inspect-, modify- tai out_of_scope-tyypiksi; kirjoituspolulla Workerin ehdottamat muutokset järjestetään ensin Scoren avulla, ja lopullinen sisältö ja muutosyhteenveto käyvät läpi hyväksynnän ja lähetyksen arvioinnin. Nämä ovat vain päätöspisteitä: sen, voiko objekteja todella lukea ja kirjoittaa, myöntää edelleen vaiheittain hallittu suorittaja. Jevillä ei ole oikeutta löysätä työkalujen sallittua listaa itse, eikä se voi ohittaa ennen lähetystä tehtävää yhdenmukaisuustarkistusta.

Kalibrointitiedot paljastavat toisen kompromissin. Shadow-tilassa Jev antaa vastauksen ja täyden jakauman mutta ei muuta Workerin alkuperäistä suorituspolkua; enforce-tilassa vastaus vaikuttaa siihen, jatketaanko, eskaloinnistaanko vai hylätäänkö. Shadow'n tarkkuuden pitäminen suoraan enforce-tilan valmistumisasteena johtaa järjestelmän väärinymmärtämiseen: Q2:n eskalaatio pysäyttää tehtävän etuajassa, jolloin myöhemmät ehdokaspisteytykset, hyväksyntä ja lähetyskysymykset eivät pääse edes esiin. Siksi tämä raportti lukee erikseen kunkin kysymyksen jakauman, eskalaatiosuunnan ja lopputilan.

Ehdokasmuutoksissa oli konkreettinen vertailu: samassa turnissa täsmällisesti muokkauskohteen valinnut ehdokas sai 2,94 pistettä, kun taas koko tiedoston ylikirjoittava ehdokas sai 0,38 pistettä; korkeamman pistemäärän ehdokas valittiin. Tämä esimerkki osoittaa vain, että kyseisessä synteettisessä tilanteessa pisteytyskysymys erotti kaksi vaihtoehtoa. Toisaalta ehdokas, jonka todisteet oli katkaistu, sai 2,27 pistettä, eikä sen matalaa luottamusta ja katkaisumerkintää pidä jättää huomiotta siksi, että luku näyttää "melko hyvältä". Koodimme merkitsee puutteelliset todisteet erikseen, jotta malli ei tee varmaa kirjoituspäätöstä pelkän säilytetyn etuliitteen perusteella.

Erotimme myös "mikä ehdokas valitaan" ja "sallitaanko sen kirjoittaa" kahdeksi eri vaiheeksi. Kun ehdokas on pisteytetty Jevillä, hallittu suorittaja avaa kirjoitustyökalut vain ACT/modify-vaiheessa; kertakäyttöinen lippu sidotaan työkalukutsun tunnukseen, nykyiseen revisioon, kohdeobjektin hajautusarvoon ja parametrien tiivistelmään. Vaikka ehdokasteksti yllyttäisi mallia "jättämään rajoitukset huomiotta", se ei saa työkaluoikeuksia, jotka ohittaisivat nämä tarkistukset. Tämä on kokemuksemme kooditason integraatiosta: todennäköisyysarvio päättää, mitä polkua kannattaa kulkea, mutta sivuvaikutusoikeudet määräytyvät tarkistettavissa olevien ohjelmaehtojen perusteella.

Myös epäonnistumispolut on suunniteltava. Asiakas tekee rajoitettuja uudelleenyrityksiä vain aikakatkaisun, verkkovirheen, 429- tai 5xx-virheen yhteydessä; peruutuksen jälkeen tai turnin määräajan ylittävät vastaukset hylätään suoraan. Jos Jev ei ole saatavilla enforce-tilassa, jatkamista ei sallita ilman hyväksyttyä heikennystä; kun llm_only-tila on hyväksytty, suorittaja lukitsee itsensä vain luku -tilaan. Jos haara on jo ehtinyt muuttua ennen kuin Jev menetetään, orkestroija merkitsee koko kierroksen epäonnistuneeksi sen sijaan, että antaisi myöhemmän LLM:n tehdä kirjoituksen päätöskerroksen puuttuessa. Näillä poluilla on hintansa käyttökokemukselle, mutta ne estävät "malli ei ole väliaikaisesti saatavilla" -tilaa muuttumasta huomaamatta "kirjoitusoikeudet ovat ennallaan" -tilaksi.

Kalibrointiraport erottaa myös "matalan luottamuksen eskalaation" ja "suorituksesta kieltäytymisen". Esimerkiksi oikea discard-päätös, jonka luottamus ei yllä yhtenäiseen 0,85 kynnykseen, merkitään käyttäjän syötettä vaativaksi; tämä ei kuitenkaan vastaa virheellistä sallimista. Raportti suosittaa tämän perusteella, että lähetyksen ja hylkäämisen kynnysarvot erotetaan toisistaan, mutta ne ovat toistaiseksi suosituksia. Työnkulkua kirjoitettaessa on erotettava virheellinen salliminen, virheellinen hylkääminen ja tarkistusta odottava tulos, muuten sama aineisto johtaa virheellisiin kynnysarvopäätelmiin.

Tämä tapaus kertoo, että Jevin ja LLM:n yhteistyötä ei voi kuvata pelkästään niin, että "Jev päättää ensin ja LLM tekee sitten työn". Jokaisessa päätöksessä on kysyttävä: kuinka leveä epävarmuusväli on? Estääkö se seuraavaa käsittelijää saamasta tehtävää koskaan? Jos syötetodisteet on katkaistu, voidaanko eskaloitua selvästi sen sijaan, että arvataan? Toteutuksessamme state-rakentaja tallentaa evidence_truncated-merkinnän ja saa kutsujan pitämään puuttuvien todisteiden polkua epävarmana; laskenta, järjestys ja muut deterministiset laskutoimitukset tehdään ensin koodissa eikä jätetä Jevin arvattaviksi. Viralliset Jev 1.13:n tunnetut rajoitukset suosittavat myös, että laskenta ja aritmetiikka jätetään koodiin.

Mihin LLM-suojakaiteet kannattaa sijoittaa?

TypeSafen LLM guardrails -cookbook sijoittaa Jevin LLM:n syötteiden ja tulosteiden molemmille puolille. Se tunnistaa eri riskejä Noul-joukolla, mittaa vakavuutta Scorella ja antaa koodin päättää käytännön perusteella, sallitaanko, tarkistetaanko manuaalisesti, estetäänkö vai siirretäänkö tukihenkilölle. Myös tuloste on tarkistettava, sillä tavallinen syöte voi silti tuottaa sopimattoman generoidun tuloksen.

Tällaisten suojakaiteiden rajat ovat yhtä selvät: Jev voi tarkistaa sisältöä etukäteen kirjoitettujen kysymysten perusteella, mutta se ei ole yleispätevä turvatodistus. Virallinen rajoitusdokumentaatio mainitsee selvästi, että haitallinen sisältö voi vaikuttaa arvioon, ja edellyttää, että criteria kirjoitetaan selkeästi ja rajat testataan. Synteettisessä aineistossamme tehtiin 16 injektiotutkaa ehdokasparametreja vastaan, ja havaitsimme 0 järjestyksen kääntymistä; otos on liian pieni, jotta voitaisiin päätellä "prompt-injektioiden torjunnan olevan ratkaistu". Sen, mitä työkalut todella voivat tehdä, ratkaisevat edelleen koodin sallittu luettelo, vaiheportit ja ennen lähetystä tehtävät tarkistukset.

Milloin sitä kannattaa käyttää ja milloin ei?

Jev sopii tilanteisiin, joissa ehdokasjoukko on tiedossa, kysymys voidaan jakaa muutamiin lyhyisiin päätöksiin ja ohjelmisto tarvitsee todennäköisyyksiä päättääkseen automaattisesta käsittelystä tai ihmiselle eskaloinnista. Esimerkkejä ovat asiakaspalvelun reititys, RAG-kappaleiden suodatus, Agentin ehdokastoimintojen pisteytys ja generoitujen tulosten sitaattien tarkistus. Jos tehtävä vaatii vastauskirjeen kirjoittamista, koodinpätkän muokkaamista tai monimutkaisen päättelyprosessin selittämistä, LLM ottaa sen hoitaakseen. Jos tehtävä on rahan tarkka laskeminen, päivämäärien vertailu tai käyttöoikeuksien tarkistaminen, ohjelman tulisi laskea se suoraan. Mallisivu kertoo myös, että Jev hyväksyy vain tekstiä ja että englanti on tällä hetkellä parhaiten suoriutuva koulutuskieli; kiinankieliset skenaariot on arvioitava omalla aineistolla, eikä englanninkielisen cookbookin kynnysarvoja voi kopioida sellaisenaan.

Jos haluat tarkkailla, miten todellinen Agent käsittelee käyttöoikeuksia ja työkalukutsuja, voit aloittaa katsomalla PandaNpc Agent; koodaus-Agentin rajoista ja käyttötapauksista voit lukea myös Claude Code vs. Codex -vertailusta.

Lukija voi aloittaa hyvin pienellä validointijoukolla: valmistele neljä näyte luokkaa – "selvästi automaattisesti käsiteltävä", "selvästi hylättävä", "semanttisesti epäselvä" ja "haitallisia ohjeita sisältävä"; määritä ensin ihmisluokittelu ja tallenna sitten Jevin kunkin kysymyksen todennäköisyydet ja reititystulokset. Onnistumiskriteeri ei ole se, että jokainen näyte menee automaattisesti läpi, vaan se, että automaattisen käsittelyn virheaste ja ihmiselle eskaloitujen tapausten määrä pysyvät hyväksyttävissä rajoissa. Jos epäselvät näytteet juuttuvat suurina määrinä samaan kysymykseen, tarkista ensin, onko kysymykseen sekoittunut useita päätöksiä, onko state liian pitkä tai onko kynnysarvot kalibroitu paikallisella aineistolla.

FAQ

Voiko Jev korvata Claude Coden, Codexin tai chat-mallin? Ei. TypeSafe määrittelee sen ohjelmiston sisäiseksi strukturoiduksi päätösmalliksi; keskustelu, kirjoittaminen ja koodin generointi tarvitsevat edelleen LLM:n.

Tarkoittaako kiinteä palautustyyppi, ettei virheitä tule? Ei. Kiinteä tyyppi vähentää jäsentämis- ja rajojen ylitysongelmia, mutta luokittelu, pisteytys ja tosiasia-arviot voivat silti mennä väärin. Matalan luottamuksen ja korkean riskin poluilla on säilytettävä ihmistarkistus.

Kuinka monta kysymystä samassa pyynnössä voi kysyä? Voit laittaa useita itsenäisiä Choice-, Score- ja Noul-kysymyksiä, jotka jakavat saman state-arvon, yhteen pyyntöön. Kysymykset arvioidaan erikseen, ja monimutkaiset päätökset on edelleen jaettava osiin ja yhdistettävä sitten koodissa.

Voiko kiinaa käyttää? Virallisen tiedon mukaan se tukee luonnollisia kieliä, mukaan lukien kiina, japani ja korea, mutta englannin tarkkuus on tällä hetkellä paras. Kiinankieliset työkuormat on validoitava ja kalibroitava erikseen.