Jak na LLM routing a guardrails? Příklad spolupráce Jev a velkých jazykových modelů

Zveřejnění zájmů a důkazů: PandaNpc vyvíjí rozhodovací vrstvu agenta využívající Jev. Níže citujeme oficiální dokumentaci TypeSafe, oficiální cookbook a také skutečná volání Jev a kalibraci syntetických scénářů v našem repozitáři. Naše kalibrace používá skriptovaného falešného poskytovatele LLM a nemůže reprezentovat reálný uživatelský provoz ani výkonnost kompletní produkční cesty.

LLM routing lze dělat takto: nejprve nechte Jev určit, do které kategorie požadavek patří a jak vysoké je riziko, a poté kód rozhodne, zda jej předá běžné funkci, specializovanému LLM, nebo lidskému posouzení. Jev lze také umístit mezi retrieval a generování, aby filtroval důkazy, nebo za výstup LLM, aby kontroloval výsledky. Vrací uzavřené volby, skóre a pravděpodobnosti; otevřené odpovědi, generování kódu a dlouhé uvažování stále provádí LLM. Vysvětlení TypeSafe kódovacím agentům jasně uvádí, že Jev nemůže přímo nahradit chatovací model stojící za Claude Code nebo Codex.

Tento článek na jednom požadavku zákaznické podpory, jedné RAG pipeline pro otázky a odpovědi a našich vlastních záznamech kalibrace agenta vysvětluje, kde přesně se oba typy modelů předávají štafetu a proč musí mít výsledky s nízkou spolehlivostí jasné určení.

Co dokáže posoudit Jev a co nadále zajišťuje LLM?

K 23. září 2026 stránka modelů TypeSafe uvádí jako stabilní model jev-1.13.0. API přijímá state a sadu questions a prostřednictvím POST /v1/systemone vrací odpovídající strukturované answers. jev-latest toho dne odkazoval na 1.13.0, ale alias se mění s verzemi; systémy s kalibrovanými prahovými hodnotami by měly verzi fixovat a zaznamenávat skutečné ID modelu v odpovědi.

Noul nemá samostatné pole confidence; pravděpodobnost Noul nelze přímo zapisovat jako „confidence modelu“. Score by se také nemělo používat k výpočtu přesných částek. Výpočty částek, porovnávání dat, kvóty a kontroly oprávnění by měly zůstat v deterministickém programu; oficiální dokumentace uvádí tyto hranice Jev 1.13.

Minimální podoba jednoho volání

Následující podoba požadavku odpovídá oficiální referenci API; příklad otázek je ilustrativní konfigurace vytvořená pro tento článek a v tomto článku jsme ji netestovali online:

Níže uvedený JSON obsahuje anglickou zprávu zákazníka; v češtině by zákazník řekl „U objednávky došlo k dvojímu stržení platby, prosím o vrácení peněz.“

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

Reálný systém by měl nejprve kódem zkontrolovat, zda záznam o stržení platby patří ke stejné objednávce a zda je refundace povolena. Výše uvedený příklad slouží pouze k interpretaci záměru uživatele; to, že uživatel žádá refundaci, neznamená, že nárok na refundaci byl prokázán, a už vůbec není oprávněním k přímému provedení refundace.

LLM routing s Jev: tři cesty předání

Oficiální příklad intent routingu TypeSafe nejprve předá požadavek zákaznické podpory Jev, aby určil záměr a složitost, a poté kód provede směrování: dotaz na stav objednávky jde do databázové funkce; produktové dotazy a vrácení či výměna zboží jdou ke specializovaným LLM s různými načtenými materiály; složité stížnosti nebo výsledky s nízkou spolehlivostí vstupují do fronty pro lidské posouzení. To je nejsnáze pochopitelná spolupráce Jev a LLM: první dává strukturované posouzení, druhý nastupuje jen tehdy, když je třeba generovat vysvětlení nebo vést dialog.

Při zavádění lze postupovat v tomto pořadí, místo abyste nechali model volně rozhodovat o všech akcích:

1. Nejprve definujte cesty: jasně vypište požadavky, které zvládne běžná funkce, jednotlivé specializované LLM a lidské posouzení, a pro Choice ponechte other nebo podobnou záložní volbu.
2. Vložte fakta do state: původní slova uživatele, stav účtu a záznamy objednávek udělejte samostatnými poli; nepovažujte text z webu nejasného původu za systémové instrukce.
3. Ptejte se úzce po jedné věci: záměr řešte pomocí Choice, riziko nebo naléhavost pomocí Score, jednotlivý fakt, který je třeba potvrdit, pomocí Noul. Oficiální doporučení uvádí, že více nezávislých otázek nad stejným state lze vyhodnotit paralelně v jednom požadavku.
4. Konečné směrování nechte na kódu: nejprve zkontrolujte oprávnění a tvrdá pravidla, poté pravděpodobnosti Jev a prahové hodnoty kalibrované pro vaše prostředí; požadavky s nízkou spolehlivostí nebo chybějícími důkazy jdou na lidské posouzení nebo k doplňující otázce.
5. Zaznamenejte výsledky a revidujte je: ukládejte verzi modelu, verzi otázek, pravděpodobnosti, konečné určení a výsledky lidských oprav, teprve pak můžete posoudit, zda jsou prahové hodnoty vhodné.

Zdroj grafu: TypeSafe AI „Introducing System One Models & Jev“, 2026-09-15. Čtyři workflow vytvořil TypeSafe; metriky jsou agregovány s rovnou vahou jednotlivých workflow; metoda hodnocení viz TypeSafe workflow evals.

Tento oficiální graf pomáhá pochopit, proč TypeSafe zdůrazňuje „vložení několika úzkých úsudků do programového workflow“. Svislá osa grafu přebírá označení „accuracy“ od výrobce, ale její referenční odpověď vychází z konsenzu predikovaných pravděpodobností dvou velkých modelů, nejde o jedinou lidsky ověřenou správnou odpověď; náklady a metriky také závisí na těchto čtyřech workflow a metodice hodnocení výrobce a nelze je převádět na „kolik se ušetří v jakémkoli scénáři“.

Retrieval-augmented generation: Jev filtruje důkazy před odpovědí LLM

RAG passage cookbook TypeSafe poskytuje konkrétnější příklad s více modely: OpenAI embedding nejprve vyhledá pasáže, Jev se u každé dvojice „otázka + pasáž“ ptá čtyřmi Noul – zda je relevantní, zda obsahuje důkaz použitelný k odpovědi, zda vyvrací předpoklad v otázce a zda se pokou zadávat instrukce modelu, který má odpovídat. Kód postupně zpracuje čtyři pravděpodobnosti a rozhodne zda pasáž zařadí do oblasti důkazů, oblasti konfliktních důkazů, nebo zahodí; nakonec odpověď napíše Claude Sonnet 5.

Tento krok řeší častý problém: pasáž s vysokou vektorovou podobností nemusí být použitelná. Může obsahovat jen podobná slova, nebo může jít o příspěvek z fóra, který nese prompt injection „ignoruj předchozí text“. Příklad v cookbooku řadí kontrolu injection na první místo v pravidlech routingu a zároveň upozorňuje, že prahové hodnoty jsou výchozím bodem zvoleným pro daný korpus, nikoli výchozí hodnotou pro všechny RAG aplikace. Uvedená demonstrační čísla pocházejí z jev-1.12 ze dne 2026-08-27 a nelze je považovat za nové výsledky hodnocení současného jev-1.13.0.

Po generování lze přidat ještě jednu vrstvu kontroly. Cookbook TypeSafe pro kontrolu citací nejprve programově najde původní text citace a poté pomocí Jev posoudí, zda daná pasáž tvrzení podporuje, vyvrací, nebo se o něm nezmiňuje. Dokáže vybrat citace, které stojí za přezkoumání; samotný úsudek modelu však může být chybný, a proto nelze „prošlo kontrolou“ vydávat za záruku pravdivosti.

Naše kalibrace agenta: kde se zasekne eskalace při nízké confidence?

V repozitáři PandaNpc používají klient Jev, banka otázek a orchestrátor Jev pro rozpoznávání záměru agenta, bodování kandidátních úprav, kontrolu podmínek dokončení a rozhodnutí o odeslání. Klient také provádí omezené opakování při timeoutech, 429 a 5xx a omezuje rozpočet požadavků a expiraci výsledků; prováděcí oprávnění drží orchestrátor a vrstva řízených nástrojů a neuděluje je přímo jediný úsudek Jev.

Dne 2026-09-22 jsme s jev-1.13.0 u 19 syntetických turnů spustili jednou shadow a jednou enforce, celkem 38 běhů, a zaznamenali 165 skutečných rozhodnutí Jev. Tato interní kalibrační zpráva a uložené odpovědi z reálného stroje používají skriptovaného falešného poskytovatele LLM, proto tato data vypovídají pouze o rozhodovacím chování v kontrolovaných scénářích. Nemohou prokázat celkovou úspěšnost, míru úspory ani end-to-end latenci u skutečných uživatelských požadavků.

Nejcennějším zjištěním nebyla průměrná rychlost, ale to, že „zdánlivě bezpečná“ prahová hodnota způsobila ucpání: z 19 turnů v režimu enforce jich 13 eskalo v Q2 „je informací dost na zahájení úprav“, protože pravděpodobnost Noul spadla do původně stanoveného intervalu nejistoty 0,15–0,85; LLM Worker nedostal příležitost provést následující kroky. Kalibrační záznamy ukazují, že z 34 rozhodnutí Q2 označených jako dostatečně informovaná mělo mnoho pravděpodobnost ve středním pásmu. Zpráva doporučuje rozdělit složité Q2 na atomičtější úsudky nebo upravit pravidla eskalace; jde o doporučení, ne o již nasazené prahové hodnoty.

Naše banka otázek klasifikuje vstup jako answer_only, inspect, modify nebo out_of_scope; na cestě zápisu Workerem navržené kandidátní úpravy nejprve seřadí Score a konečný obsah a souhrn změn pak projdou posouzením přijetí a odeslání. To jsou jen rozhodovací body: zda lze objekt skutečně číst a zapisovat, stále určuje řízený executor udělováním oprávnění podle fáze. Jev nemá právo sám rozšiřovat allowlist nástrojů ani obcházet kontrolu konzistence před odesláním.

Kalibrační data odhalila další kompromis. V režimu shadow Jev poskytne odpověď a úplné rozdělení, ale nemění původní prováděcí cestu Workeru; v režimu enforce odpověď ovlivňuje, zda se bude pokračovat, eskaluje, nebo se výsledek zahodí. Pokud bychom přesnost shadow přímo považovali za míru dokončení enforce, systém bychom četli špatně: eskalace Q2 zastaví úlohu předčasně, takže následné bodování kandidátů, přijetí a otázky k odeslání vůbec nedostanou příležitost. Proto tato zpráva čte rozdělení pro každou otázku, směr eskalace a konečný stav odděleně.

U kandidátních úprav existuje konkrétní srovnání: ve stejném turnu získal kandidát, který přesně upravoval cíl, 2,94 bodu, zatímco kandidát přepisující celý soubor získal 0,38 bodu; byl vybrán kandidát s vyšším skóre. Tento příklad pouze ukazuje, že bodovací otázka v dané syntetické situaci rozlišila dvě řešení. Naopak kandidát s oříznutými důkazy získal 2,27 bodu; nelze ignorovat jeho nízkou confidence a označení oříznutí jen proto, že číslo vypadá „docela dobře“. Náš kód označuje neúplné důkazy zvlášť, aby model nedělal definitivní rozhodnutí o zápisu pouze na základě zachovaného prefixu.

Také jsme oddělili „který kandidát vybrat“ a „povolit mu zápis“ do dvou různých kroků. Poté, co kandidát projde bodováním Jev, řízený executor otevře nástroje pro zápis pouze ve fázi ACT/modify; vydaný jednorázový tiket je vázán na ID volání nástroje, aktuální číslo revize, hash cílového objektu a souhrn parametrů. I kdyby text kandidáta manipuloval model tak, aby „ignoroval omezení“, nezíská oprávnění nástroje, které by obešlo tyto kontroly. To je naše zkušenost z integrace na úrovni kódu: pravděpodobnostní úsudek určuje, která cesta stojí za to, ale oprávnění k vedlejším účinkům určují přezkoumatelné programové podmínky.

Musí být navrženy i cesty selhání. Klient opakuje pouze omezeně při timeoutech, síťových chybách, 429 nebo 5xx; odpovědi po zrušení nebo po termínu turnu se přímo zahazují. Pokud Jev v režimu enforce není dostupný, nelze pokračovat bez oprávnění k degradaci; když je povoleno přejít na llm_only, executor uzamkne režim pouze pro čtení. Pokud se Jev ztratí až poté, co ve větvi došlo k úpravám, orchestrátor označí celé kolo jako selhání, místo aby nechal následný LLM doplnit zápis bez rozhodovací vrstvy. Tyto cesty něco stojí v uživatelské zkušenosti, ale zabraňují tomu, aby se „model je dočasně nedostupný“ tiše změnilo na „práva k zápisu zůstávají stejná“.

Kalibrační zpráva také rozlišuje „eskalaci při nízké confidence“ a „odmítnutí provedení“. Například správný discard, pokud jeho confidence nedosáhne jednotného prahu 0,85, se zaznamená jako vyžadující vstup uživatele; to neznamená chybné povolení. Zprá na tomto základě doporučuje oddělit prahové hodnoty pro odeslání a zahození, zatím však jde stále jen o doporučení. Při psaní workflow je nutné rozlišovat tři výsledky – chybné povolení, chybné odmítnutí a čekání na posouzení – jinak stejná data povedou k chybným závěrům o prahových hodnotách.

Tento případ ukazuje, že spolupráci Jev a LLM nelze znázorňovat jen jako „Jev nejprve posoudí, LLM pak pracuje“. U každého úsudku je třeba se ptát: jak široký je interval nejistoty? Způsobí, že se následný procesor k úloze nikdy nedostane? Pokud jsou vstupní důkazy oříznuté, lze jednoznačně eskalovat místo hádání? V naší implementaci state builder zaznamenává evidence_truncated a nutí volajícího považovat cesty s chybějícími důkazy za nejisté; deterministické výpočty, jako je počítání a řazení, se nejprve provedou v kódu a nepředávají se Jev k hádání. Oficiální známá omezení Jev 1.13 rovněž doporučují ponechat počítání a aritmetiku v kódu.

Kam umístit LLM guardrails?

Cookbook TypeSafe pro LLM guardrails umisťuje Jev na obě strany vstupu a výstupu LLM. Používá sadu Noul k rozpoznání různých rizik, Score k měření závažnosti a kód pak podle politiky rozhodne o povolení, lidském přezkoumání, zablokování nebo předání podpoře. Kontrolovat je třeba i výstup, protože i běžný vstup může vést k nevhodnému generovanému výsledku.

Hranice těchto guardrails jsou stejně jasné: Jev může kontrolovat obsah podle předem napsaných otázek, ale není univerzálním bezpečnostním důkazem. Oficiální dokument o omezeních výslovně uvádí, že škodlivý obsah může ovlivnit úsudek, a vyžaduje jasně napsaná criteria a testování hranic. V našich syntetických vzorcích jsme provedli 16 injection sond proti parametrům kandidátů a zaznamenali 0 obrácení pořadí; vzorek je příliš malý na to, abychom z toho vyvozovali, že „ochrana proti prompt injection je vyřešena“. O tom, co nástroje skutečně mohou dělat, stále rozhoduje allowlist v kódu, fázové gate a kontrola před odesláním.

Kdy se to hodí a kdy ne?

Jev se hodí, když: množina kandidátů je známá, problém lze rozdělit na několik krátkých úsudků a software potřebuje pravděpodobnosti k rozhodnutí o automatickém zpracování nebo eskalaci na člověka. Například routing zákaznické podpory, filtrování RAG pasáží, bodování kandidátních akcí agenta, kontrola citací ve generovaném výsledku. Pokud úloha vyžaduje napsat odpdní dopis, upravit část kódu vysvětlit složitý proces uvažování, převezme ji LLM Pokud úloha vyžaduje přesné počítání peněz, porovnávání dat nebo kontrol přístupu, program má počítat přímo. Stránka modelů uvádí, že Jev přijímá pouze text a že angličtina je aktuálně nejlépe fungující trénovací jazyk; čínské scénáře je třeba vyhodnotit na vlastních datech a nelze přebírat prahové hodnoty z anglického cookbooku.

Pokud chcete sledovat, jak skutečný agent zachází s oprávněními a voláním nástrojů, můžete nejprve zhlédnout PandaNpc Agent; o hranicích a případech použití kódovacích agentů se můžete inspirovat také ve srovnání Claude Code a Codex.

Čtenáři mohou začít velmi malou validační sadou: připravte čtyři typy vzorků – „zjevně lze zpracovat automaticky“, „zjevně je třeba odmítnout“, „sémanticky nejasné“ a „obsahuje škodlivé instrukce“; nejprve stanovte lidské anotace a poté zaznamenejte pravděpodobnosti jednotlivých otázek Jev a výsledky routingu. Kritérium úspěchu není to, že každá položka projde automaticky, ale to, že míra chyb automatické cesty i objem lidských eskalací zůstanou v rozmezí, které můžete přijmout. Pokud se mnoho nejasných vzorků zasekne na stejné otázce, nejprve zkontrolujte, zda se do otázky nemíchá více úsudků, zda není state příliš dlouhý nebo zda nejsou prahové hodnoty kalibrované podle místních dat.

FAQ

Může Jev nahradit Claude Code, Codex nebo chatovací model? Ne. TypeSafe jej pozicuje jako strukturovaný rozhodovací model uvnitř softwaru; chat, psaní a generování kódu stále vyžadují LLM.

Když jsou návratové typy pevné, znamená to, že už nemůže udělat chybu? Ne. Pevné typy snižují problémy s parsováním a výstupy mimo rozsah, ale klasifikace, bodování a faktické úsudky mohou stále selhat. Cesty s nízkou confidence a vysokým rizikem by měly mít zachované lidské přezkoumání.

Kolik otázek lze položit v jednom požadavku? Do jednoho požadavku lze vložit více nezávislých Choice, Score a Noul, které sdílejí stejný state. Otázky se vyhodnocují samostatně, složité úsudky je stále třeba rozdělit a poté je kód zkombinuje.

Lze použít čínštinu? Oficiální dokumentace uvádí podporu přirozených jazyků včetně čínských, japonských a korejských znaků, ale angličtina má aktuálně nejlepší přesnost. Čínské pracovní zátěže vyžadují samostatné ověření a kalibraci.