Hogyan valósítsuk meg az LLM-útvonalválasztást és a guardrailokat? Jev és nagy nyelvi modellek együttműködési példája

Érdek- és bizonyítékárás: A PandaNpc éppen egy Jevet használó Agent döntési réteget fejleszt. Az alábbiakban külön hivatkozunk a TypeSafe hivatalos dokumentációjára, a hivatalos cookbookra, valamint a repónkban lévő valódi Jev-hívásokra és szintetikus forgatókönyv-kalibrációra. A kalibrációnk scriptelt hamis LLM providert használ, ezért nem reprezentálja a valós felhasználói forgalmat vagy a teljes éles útvonal teljesítményét.

Az LLM-útvonalválasztást így lehet megvalósítani: először a Jev eldönti, hogy a kérés melyik kategóriába tartozik és mekkora a kockázata, majd a kód dönti el, hogy egy egyszerű függvénynek, egy speciális LLM-nek vagy emberi ellenőrzésnek adja-e tovább. A Jev a visszakeresés és a generálás közé is beilleszthető a bizonyítékok szűrésére, vagy az LLM kimenete után az eredmény ellenőrzésére. Zárt választási lehetőségeket, pontszámokat és valószínűségeket ad vissza; a nyílt végű válaszadást, a kódgenerálást és a hossú következtetést továbbra is az LLM végzi. A TypeSafe coding agentekről szóló leírása egyértelműen kimondja, hogy a Jev nem helyettesítheti közvetlenül a Claude Code vagy a Codex mögötti csevegőmodellt.

Ez a cikk egy ügyfélszolgálati kéréssel, egy RAG kérdés-válasz folyamattal és a saját Agent-kalibrációs jegyzőkönyvünkkel magyarázza el, hogy a kétféle modell pontosan hol adja át egymásnak a feladatot, és hogy az alacsony konfidenciájú eredményeknek miért kell egyértelmű helyre kerülniük.

Mit tud eldönteni a Jev, és miért marad felelős továbbra is az LLM?

2026. szeptember 23-ig a TypeSafe modelloldala a stabil modellként a jev-1.13.0-t listázza. Az API egy state-et és egy questions csoportot fogad, és a POST /v1/systemone végponton keresztül visszaadja a megfelelő strukturált answers értékeket. A jev-latest aznap az 1.13.0-ra mutatott, de az alias verzióról verzióra változhat; a küszöbértékekre kalibrált rendszereknek érdemes rögzített verziót használniuk, és feljegyezniük a válaszban szereplő tényleges modell-ID-t.

A Noulnak nincs külön confidence mezője; egy Noul-valószínűséget nem lehet egyszerűen „modell-konfidenciaként” leírni. A Score-t sem szabad pontos összegek kiszámítására használni. Az összegeket, dátum-összehasonlításokat, kvótákat és jogosultságellenőrzéseket determinisztikus programban kell tartani; a hivatalos dokumentáció felsorolja a Jev 1.13 ezen határait.

Egy hívás minimális alakja

Az alábbi kérés alakja megegyezik a hivatalos API-referenciával; a példakérdések az e cikkben összeállított szemléltető konfigurációk, és e cikkben nem végeztünk rájuk online mérést:

Az alábbi JSON egy angol nyelvű ügyfélüzenetet használ; magyarul az ügyfél ezt mondaná: „A rendelésnél kétszer vonták le az összeget, kérlek, segíts a visszatérítésben.”

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

Egy valós rendszerben a kódnak először azt is ellenőriznie kell, hogy a terhelési rekordok ugyanahhoz a rendeléshez tartoznak-e, és engedélyezett-e a visszatérítés. A fenti példa csak a felhasználói szándék értelmezésére szolgál; az, hogy a felhasználó visszatérítést kér, nem jelenti azt, hogy a visszatérítésre való jogosultság bizonyított, és még kevésbé jelent felhatalmazást a visszatérítés közvetlen végrehajtására.

LLM-útvonalválasztás Jevvel: három átadási útvonal

A TypeSafe hivatalos szándék-útvonalválasztási példája először a Jevre bízza az ügyfélszolgálati kérés szándékának és bonyolultságának meghatározását, majd a kód irányítja tovább: a rendelésállapot lekérdezése adatbázisfüggvényhez kerül; a termékkel kapcsolatos kérdések és a visszaküldés/visszatérítés különböző anyagokkal betöltött speciális LLM-ekhez mennek; a bonyolult panaszok vagy alacsony konfidenciájú eredmények emberi sorba kerülnek. Ez a Jev és az LLM együttműködésének legkönnyebben érthető formája: az előbbi strukturált döntést ad, az utóbbi csak akkor lép színre, amikor magyarázatot vagy párbeszédet kell generálni.

A bevezetés során az alábbi sorrend szerint érdemes tervezni, ahelyett hogy a modell szabadon döntené el az összes műveletet:

1. Először határozd meg az útvonalakat: soroljad fel egyértelműen, milyen kéréseket kezelhetnek az egyszerű függvények, az egyes speciális LLM-ek és az emberi ellenőrzés, és a Choice számára hagyj other vagy hasonló tartalék opciót.
2. Tedd a tényeket a state-be: a felhasználó eredeti szavai, a fiók állapota és a rendelési rekordok külön mezők legyenek; ne kezeld rendszerutasításként az ismeretlen eredetű weblapszöveget.
3. Egyszerre szűk kérdéseket kérdezz: a szándékhoz Choice, a kockázathoz vagy sürgősséghez Score, egy megerősítendő egyszerű tényhez Noul. A hivatalos javaslat szerint ugyanazon state több független kérdése egy kérésben párhuzamosan kiértékelhető.
4. A végső útvonalválasztást a kód végezze: először ellenőrizd a jogosultságokat és a kemény szabályokat, aztán nézd a Jev valószínűségeit és az erre az üzletre kalibrált küszöbértékeket; az alacsony konfidenciájú vagy bizonyítékot nélkülöző kérések emberi kezelésre vagy utánakérdezésre menjenek.
5. Rögzítsd az eredményeket és vizsgáld felül: mentsd el a modellverziót, a kérdésverziót, a valószínűségeket, a végső útvonalat és az emberi javítások eredményét, hogy meg tudd ítélni, megfelelő-e a küszöbérték.

Ábra forrása: TypeSafe AI: Introducing System One Models & Jev, 2026-09-15. A négy munkafolyamatot a TypeSafe saját maga építette; a mutatók munkafolyamatonként egyenlő súllyal összesítettek; az értékelési módszert lásd: TypeSafe workflow evals.

Ez a hivatalos ábra segít megérteni, miért hangsúlyozza, hogy „több szűk döntést kell program-munkafolyamatba illeszteni”. Az ábra függőleges tengelye a gyártó „accuracy” elnevezését használja, de a referenciaválasz két nagy modell előrejelzett valószínűségeinek konszenzusából származik, nem pedig ember által ellenőrzött egyetlen helyes válaszból; a költségek és a mutatók is e négy munkafolyamattól és a gyártó értékelési módszerétől függnek, ezért nem lehet átszámítani arra, hogy „bármely forgatókönyvben mennyit lehet megspórolni”.

Retrieval-augmented generation: a Jev az LLM válasza előtt szűri a bizonyítékokat

A TypeSafe RAG passage cookbookja konkrétabb többmodeles példát ad: az OpenAI embedding először visszakeresi a bekezdéseket, a Jev pedig minden „kérdés + bekezdés” párra négy Noul-kérdést tesz fel – releváns-e, tartalmaz-e a válaszadáshoz használható bizonyítékot, cáfolja-e a kérdés premisszáját, és megpróbál-e utasítást adni a válaszadó modellnek. A kód sorrendben feldolgozza a négy valószínűséget, és eldönti, hogy a bekezdés a bizonyítékok közé, az ellentmondó bizonyítékok közé kerüljön, vagy el kell dobni; végül a Claude Sonnet 5 írja meg a választ.

Ez a lépés egy gyakori problémát old meg: a nagy vektorsimilaritású bekezdés nem feltétlenül használható. Lehet, hogy csak hasonló szavakat használ, vagy egy fórumbejegyzésbe ágyazott „hagyd figyelmen kívül a fenti szöveget” prompt-injektálás. A cookbook példája az injektálásellenőrzést az útvonalválasztási szabályok legfrontjára teszi, ugyanakkor figyelmeztet, hogy a küszöbértékek az adott korpuszra választott kiindulópontok, nem pedig minden RAG-alkalmazás alapértelmezései. A bemutatóban szereplő számok a 2026-08-27-i jev-1.12-ből származnak, és nem tekinthetők a jelenlegi jev-1.13.0 új értékelési eredményeinek.

A generálás után még egy ellenőrzési réteg is beiktatható. A TypeSafe idézetellenőrző cookbookja először programmal megkeresi az idézett eredeti szöveget, majd a Jevvel eldönti, hogy az a szakasz támogatja, cáfolja vagy nem említi a generált állítást. Ki tudja választani a felülvizsgálatra érdemes idézeteket; maga a modell döntése továbbra is tévedhet, ezért a „megfelelt az ellenőrzésen” nem írható le ténygaranciaként.

A saját Agent-kalibrációnk: hol akad el az alacsony konfidenciájú eszkaláció?

A PandaNpc repójában a Jev-kliens, a kérdésbank és az orchestrator a Jeve-t az Agent szándékfelismerésére, a jelölt módosítások pontozására, a befejezési feltételek ellenőrzésére és a beküldési döntésre használja. A kliens emellett korlátozott újrapróbálkozást végez timeout, 429 és 5xx esetén, valamint korlátokat szab a kérésköltségvetésre és az elavult eredményekre; a végrehajtási jogosultságot az orchestrator és a kontrollált eszközréteg tartja kézben, nem pedig a Jev egyetlen döntése adja meg közvetlenül.

2026-09-22-én a jev-1.13.0-val 19 szintetikus turnönként egyszer shadow, egyszer enforce módban futottunk, összesen 38 futtatást végeztünk, és 165 valódi Jev-döntést rögzítettünk. Ez a belső kalibrációs jelentés és a mentett valós gépi válaszok scriptelt hamis LLM providert használnak, ezért ezek az adatok csak a kontrollált forgatókönyvek döntési viselkedését mutatják. Nem bizonyítják a valós felhasználói kérések melletti teljes sikerességi arányt, megtakarítási arányt vagy végponttól végpontig terjedő késleltetést.

A legértékesebb felismerés nem az átlagos sebesség volt, hanem hogy egy „biztonságosnak tűnő” küszöb elakadást okozott: az enforce módú 19 turnből 13 a Q2 „elegendő-e az információ a módosítás megkezdéséhez” kérdésnél eszkalálódott, mert a Noul valószínűsége az eredetileg meghatározott 0,15–0,85 közötti bizonytalansági sávba esett; az LLM Workernek nem volt lehetősége végrehajtani a további lépéseket. A kalibrációs jegyzőkönyv szerint a információszempontból elegendőnek jelölt 34 Q2-döntés közül sok valószínűség a középső sávban volt. A jelentés azt javasolja, hogy a bonyolult Q2-t bontsuk atomibb döntésekre, vagy módosítsuk az eszkalációs szabályokat; ezek javaslatok, nem már bevezetett küszöbértékek.

A kérdésbankunk a belépési pontot answer_only, inspect, modify vagy out_of_scope kategóriába sorolja; az írási útvonalon a Worker által javasolt jelölt módosításokat először a Score rendezi, a végső tartalmat és a változtatások összefoglalóját pedig átvételi és beküldési döntés követi. Ezek csak döntési pontok: hogy egy objektum ténylegesen olvasható vagy írható-e, továbbra is a kontrollált végrehajtó dönti el, szakaszonként kiadott jogosultságokkal. A Jevnek nincs joga saját maga enyhíteni az eszközök engedélylistáját, és nem kerülheti meg a beküldés előtti konzisztenciaellenőrzést.

A kalibrációs adatok egy másik kompromisszumra is rávilágítanak. Shadow módban a Jev megadja a választ és a teljes eloszlást, de nem változtatja meg a Worker eredeti végrehajtási útvonalát; enforce módban a válasz befolyolja, hogy folytatódik-e a famat, eszkalálódik-e vagy elésre kerül-e. Ha a shadow pontosságát közvetlenül az enforce befejezési arányának tekintjük, félreértjük a rendszert: a Q2 eszkalációja előre megállítja a feladatot, így a későbbi jelltpontozási, átvételi és beküldési kérdések esélyt sem kapnak arra, hogy megjelenjenek. Ezért ez a jelentés külön olvassa az egyes kérdések eloszlását, az eszkaláció irányát és a végső állapotot.

A jelölt módosítások között van egy konkrét összehasonlítás: ugyanabban a turnben a pontos célmódosítást végző jelölt 2,94 pontot kapott, míg a teljes fájlt felülíró jelölt 0,38 pontot; a magasabb pontszámú jelöltet választották ki. Ez a példa csak azt mutatja, hogy az adott szintetikus helyzetben a pontozókérdés megkülönböztette a két megoldást. Fordított esetben egy bizonyítékában csonkolt jelölt 2,27 pontot kapott; nem szabad figyelmen kívül hagyni az alacsony konfidenciáját és a csonkolás jelölését csak azért, mert a szám „egész jónak” tűnik. A kódunk külön jelöli a hiányos bizonyítékot, hogy a modell ne hozzon biztos írási döntést pusztán a megőrzött előtag alapján.

Azt is szétválasztottuk két külön lépésre, hogy „melyik jelöltet válasszuk ki” és hogy „engedjük-e írni”. Miután a jelölt átment a Jev pontozásán, a kontrollált végrehajtó csak az ACT/modify szakaszban nyitja meg az írási eszközöket; a kiadott egyszeri jegy a hívást indító eszköz ID-jához, az aktuális revíziószámhoz, a célobjektum hashéhez és a paraméterösszegzéshez kötődik. A jelölt szövege akkor sem kap olyan eszközjogosultságot, amely megkerüli ezeket az ellenőrzéseket, ha arra próbálja rávenni a modellt, hogy „hagyja figyelmen kívül a korlátozásokat”. Ez a kód szintű integrációból származó tapasztalatunk: a valószínűségi döntés határozza meg, melyik út megérhető, a mellékhatás-jogosultságot pedig felülvizsgálható programfeltételek döntik el.

A hibaútvonalakat is meg kell tervezni. A kliens csak timeout, hálózati hiba, 429 vagy 5xx esetén próbálkozik újra korlátozottan; a lemondás utáni vagy a turn határidejét meghaladó válaszokat egyenesen eldobja. Ha a Jev enforce módban nem elérhető, akkor visszaesési engedély nélkül nem lehet folytatni; ha engedélyezett az llm_only útvonal, a végrehajtó csak olvasásra zárol. Ha az ág már módosításokat hajtott végre, és csak ezután veszik el a Jev, az orchestrator az egész kört hibásnak jelöli, ahelyett hogy a későbbi LLM a döntési réteg hiányában pótolná az írásokat. Ezeknek az útvonalaknak ára van a felhasználói élményben, de megakadályozzák, hogy a „modell átmenetileg nem elérhető” csendben „az írási jogosultság marad” állapottá váljon.

A kalibrációs jelentés különbséget tesz az „alacsony konfidencia miatti eszkaláció” és a „végrehajtás megtagadása” között. Például egy helyes discard döntés, ha a konfidenciája nem éri el az egységes 0,85-es küszöböt, felhasználói bevitelt igénylőként kerül rögzítésre; ez nem egyenlő a téves engedélyezéssel. A jelentés ezért azt javasolja, hogy a beküldési és az elvetési küszöböt válasszuk szét, de ez egyelőre javaslat marad. Munkafolyamat írásakor külön kell választani a téves engedélyezés, a téves elutasítás és a felülvizsgálatra várás három eredményét, különben ugyanaz az adathalmaz hibás küszöbérték-következtetésekre vezet.

Ez az eset azt mutatja, hogy a Jev és az LLM együttműködését nem lehet csak úgy ábrázolni, hogy „előbb a Jev dönt, aztán az LLM dolgozik”. Minden döntésnél meg kell kérdezni: milyen széles a bizonytalansági sáv? Előfordulhat-e, hogy a későbbi feldolgozó soha nem kap feladatot? Ha a bemeneti bizonyíték csonkolt, egyértelműen eszkalálunk-e a találgatás helyett? A mi implementációnkban a state-építő rögzíti az evidence_truncated értéket, és a hívót arra készteti, hogy a bizonyítékhiányos útvonalat bizonytalanként kezelje; a számlálást, rendezést és más determinisztikus számításokat előbb a kód végzi el, nem a Jevre bízzuk a találgatást. A hivatalos Jev 1.13 ismert korlátai is azt javasolják, hogy a számlálást és az aritmetikát hagyjuk a kódban.

Hová kell tenni az LLM guardrailokat?

A TypeSafe LLM guardrails cookbookja a Jeve-t az LLM bemeneti és kimeneti oldalára egyaránt elhelyezi. Egy Noul-csoporttal azonosítja a különböző kockázatokat, Score-ral méri a súlyosságot, majd a kód a szabályzat alapján dönt az engedélyezésről, emberi felülvizsgálatról, blokkolásról vagy támogatásnak való továbbításról. A kimenetet is ellenőrizni kell, mert a szokásos bemenet is vezethet nem megfelelő generált eredményhez.

Az ilyen guardrailok határai szintén világosak: a Jev előre megírt kérdések alapján ellenőrizheti a tartalmat, de nem mindenható biztonsági bizonyíték. A hivatalos korlátokról szóló dokumentum kifejezetten megemlíti, hogy a rosszindulatú tartalom befolyásolhatja a döntést, ezért egyértelmű criteria-t kell írni, és tesztelni kell a határokat. A szintetikus mintáinkban 16 injektálási próbát végeztünk a jelölt paraméterek ellen, és 0 rangsorfordulást rögzítettünk; a minta túl kicsi ahhoz, hogy arra következtessünk, hogy „a prompt-injektálás elleni védelem megoldott”. Azt, hogy egy eszköz ténylegesen mit tehet, továbbra is a kódban lévő engedélylista, a szakaszokra bontott kapuk és a beküldés előtti ellenőrzések döntik el.

Mikor érdemes használni, és mikor nem?

A Jev akkor alkalmas, ha a jelölthalmaz ismert, a kérdés néhány rövid döntésre bontható, és a szoftvernek valószínűségekre van szüksége az automatikus kezelés vagy az emberi eszkaláció eldöntéséhez. Például ügyfélszolgálati útvonalválasztás, RAG-bekezdések szűrése, Agent-jelöltműveletek pontozása, a generált eredményben szereplő idézetek ellenőrzése. Ha a feladat egy válaszlevél megírása, egy kódrészlet módosítása vagy összetett következtetési folyamat elmagyarázása, azt az LLM veszi át. Ha a feladat pontos pénzszámítás, dátumok összehasonlítása vagy hozzáférés-ellenőrzés, a programnak közvetlenül kell számolnia. A modelloldal azt is elmagyarázza, hogy a Jev csak szöveget fogad el, és az angol a jelenleg legjobb teljesítményt nyújtó tanítási nyelv; a kínai nyelvű helyzeteket saját adatokon kell kiértékelni, és nem lehet mechanikusan átvenni az angol cookbook küszöbértékeit.

Ha látni szeretnéd, hogy egy valós Agent hogyan kezeli a jogosultságokat és az eszközhívásokat, először nézd meg a PandaNpc Agent oldalt; a coding agentek határairól és felhasználási eseteiről pedig a Claude Code és Codex összehasonlítását is megnézheted.

Az olvasó egy nagyon kicsi validációs készlettel kezdhet: készítsen négy mintacsoportot – „egyértelműen automatikusan kezelhető”, „egyértelműen elutasítandó”, „szemantikailag homályos” és „rosszindulatú utasítást tartalmazó”; először határozza meg az emberi címkézést, majd rögzítse a Jev egyes kérdéseinek valószínűségeit és az útvonalválasztási eredményeket. A siker kritériuma nem az, hogy minden automatikusan átmenjen, hanem hogy az automatikus kezelési útvonal hibaarány és az emberi eszkaláció mennyisége is az általad elfogadható tartományba essen. Ha sok homályos minta ugyanannál a kérdésnél akad meg, először vizsgáld meg, hogy a kérdésbe nem keveredett-e több döntés, hogy a state nem túl hosszú-e, vagy hogy a küszöbértéket a helyi adatokon kalibrálták-e.

FAQ – Gyakori kérdések

Helyettesítheti a Jev a Claude Code-ot, a Codexet vagy egy csevegőmodellt? Nem. A TypeSafe strukturált döntési modellként pozicionálja szoftvereken belül; a csevegéshez, íráshoz és kódgeneráláshoz továbbra is LLM kell.

Ha a visszatérési típus rögzített, az azt jelenti, hogy nem hibázik? Nem. A rögzített típus csökkenti az elemzési és határon túli kimeneti problémákat, de a kategorizálás, a pontozás és a tények megítélése továbbra is hibázhat. Az alacsony konfidenciájú és nagy kockázatú útvonalakon meg kell tartani az emberi felülvizsgálatot.

Hány kérdést lehet feltenni egy kérésben? Egy kérésben elhelyezhető több független Choice, Score és Noul, amelyek ugyanazt a state-et használják. A kérdések külön-külön értékelődnek ki; az összetett döntéseket továbbra is szét kell bontani, majd a kódnak kell összekapcsolnia őket.

Használható kínaiul? A hivatalos leírás szerint támogatja a természetes nyelvet, beleértve a kínai, japán és koreai írásjegyeket is, de a pontosság jelenleg angolul a legjobb. A kínai nyelvű munkaterheléseket külön kell validálni és kalibrálni.