Jev a Laya: levná rozhodovací vrstva pro AI workflow

Aktualizace 20. října 2026: Clairic rozlišuje výběr možnosti a extrakci hodnoty
Cloudflare 19. října uvedl Clairic v preview na Workers AI. Zatímco rozhodovací krok vybírá z předem daných možností, extrakce vrací například částku nebo datum. To je důležité rozšíření tématu článku, nikoli tvrzení, že jsou Jev a Clairic zaměnitelné.
Modelová dokumentace uvádí typované výsledky, nejistotu a cenu 0,10 USD za milion vstupních tokenů. Výstup nemá tokenový poplatek. Cloudflare upozorňuje, že správný typ nezaručuje správnou hodnotu; složité výpočty doporučuje přenechat kódu. Otevřené váhy jsou teprve plán.
Do pilotu s fakturami bych proto oddělil tři otázky: co je v dokumentu, co z toho vypočítáme a kdo smí výsledek přijmout. Model může navrhnout částku a splatnost. Kód ověří součty a povolený formát, účetní zkontroluje nejasnosti. Odhad platebního termínu se nikdy nesmí tvářit jako datum skutečně vytištěné na faktuře.
V n8n či Make bych začal HTTP krokem nad anonymizovanými podklady, bez přímého zápisu do účetnictví. Uložil bych zdrojový dokument, schéma, navrženou hodnotu, nejistotu a následnou opravu. Chybějící hodnota má jít do kontrolní fronty, ne se doplnit nápadně věrohodným odhadem.
Toto je návrh pilotu, nikoli provedené měření Clairicu. Srovnání s existující extrakcí má sledovat chyby jednotlivých polí, čas kontroly a cenu přijaté faktury. Výběr kategorie a otevřená extrakce mají mít oddělené testovací sady.
Aktualizace 11. října 2026: Decisions API přidává další variantu pro routing
Marek Bartoš na Decisions API upozornil 10. října. OpenAI vydalo betu už 6. října; datum klipu není datum releasu.
Dokumentace potvrzuje endpoint POST /v1/decisions s modelem gpt-6-luna, textový i obrazový vstup a tři typy otázek: predicate, choice a score. Pro extrakci vlastního JSON schématu doporučuje Responses API se Structured Outputs.
Do stejného pilotu s Jevem bych proto přidal třídění reklamací s fotografií. V n8n nebo Make bych navrhl HTTP krok, který dostane minimalizovaný text a snímek a vybírá pouze z front „fakturace“, „poškození“, „doprava“ a „ostatní“. Navazující kód ověří povolenou hodnotu; při chybě API předá případ člověku. Jde o návrh integrace, nikoli zde otestovaný konektor.
Na 200 ručně označených případech bych měřil záměny kategorií, cenu včetně opakování a čas do správného zařazení. Textovou část lze srovnat odděleně; multimodální vstup nesmí potichu změnit podmínky testu. Práh z jednoho modelu bych nepřenášel na druhý. Klasifikátor smí navrhnout frontu, refundaci schvaluje samostatné pravidlo nebo člověk.
Původní testy a ceny níže patří k uvedeným zářijovým datům; nejsou dnešním benchmarkem těchto tří možností.
Aktualizace 29. září 2026: české recenze místo obecného slibu
AI s rozumem zveřejnilo 28. září praktický test Jevu. Popis videa mluví zhruba o 350 recenzích; veřejná výsledková aplikace počítá 275 recenzí s textem a srovnává Jev 1.13, Haiku 4.5 a Sonnet 5. Rozdílné počty nelze bez dalšího zaměnit.
V režimu českých otázek aplikace uvádí medián latence 321 ms u Jevu, 2,90 s u Haiku a 4,89 s u Sonnetu. Latence pochází z 25 postupně odeslaných recenzí z jednoho Macu. Cena a propustnost vycházejí z celé sady při osmi souběžných požadavcích. Přepočet na 1 000 recenzí je přibližně 0,09 / 3,76 / 9,47 USD. To jsou výsledky autorova konkrétního zapojení, nikoli naše měření nebo provozní garance.
88% shoda Jevu se Sonnetem není 88% přesnost. Aplikace bez vlastních referenčních štítků neříká, který model má pravdu. U otázky na použitelnost recenze pro vedení je jejich shoda jen 53 %. Pro automatické třídění je důležitější tento rozpad po úlohách než jedno průměrné číslo.
Do firemního pilotu bych převzal postup, nikoli rozhodovací práh: doménový člověk označí oddělenou validační sadu, tým porovná konkrétní kategorie a nejisté výsledky pošle k review. n8n uloží návrh štítku i pozdější opravu. Dokud neznáme falešně negativní případy, model pouze navrhuje prioritu a nic automaticky neuzavírá.
Aplikace upozorňuje, že jména anonymizuje až při zobrazení; modely dostaly původní text. U vlastního supportu bych minimalizaci dat provedl před API voláním. Jde zde o analýzu textové zpětné vazby, ne o hodnocení zdravotní péče nebo pacientů.
Oficiální TypeSafe skill může coding agentovi dodat kontext API. Užitečné pravidlo z dokumentace: otázky a prahy držet na jednom místě, aby je člověk mohl zkontrolovat. Skill sám správnost klasifikace neprokazuje.
Aktualizace 26. září 2026: Jev v databázi a v historii agenta
Video Jirky Herníka z 25. září přidává k routingu dva konkrétní projekty. Jsou to komunitní implementace, ne nové vydání modelu. U pg-jev uvádí changelog první verzi už 17. září.
PostgreSQL: klasifikace blízko dat, inference mimo databázi
pg-jev dovoluje přes SQL filtrovat a třídit řádky podle významu. Zpracovávaná data ale posílá do TypeSafe API. Rozšíření potřebuje PostgreSQL 14–17, plpython3u a superuživatele; na hostingu bez těchto oprávnění ho podle dokumentace nespustíte.
Pro pilot se supportem bych připravil omezený pohled s ID a anonymizovaným textem vybraných ticketů. Jev navrhne kategorii, n8n uloží návrh do oddělené tabulky a pracovník jej porovná se skutečným řešením. Přístup do produkční fronty bych přidal až po vyhodnocení chyb. To je návrh zapojení, nikoli zde provedený test.
Pozor na počet zpracovaných řádků: běžný dotaz se mění na placené síťové volání. Projekt nabízí limity řádků a znaků na příkaz; nastavil bych je před prvním pilotem. Reálný účet a latenci měřte na vlastních datech, autorův benchmark není provozní garance.
Historie agenta: vybrat, co zůstane, místo přepsání všeho
fast-jev-compaction používá Jev k rozhodnutí, které starší dvojice volání nástroje a výsledku zachovat, zkrátit nebo odstranit. Je dostupný jako knihovna i plugin pro Claude Code. Výběr stále může zahodit důležitý důkaz.
Do rozhodovacího API odchází text konverzace a vstupy nástrojů; nejde tedy o čistě lokální úklid. Začal bych na necitlivém repozitáři a stejných úkolech porovnal původní historii s kompaktovanou: dokončené úkoly, ztracená omezení, opakovaná čtení a celková cena. Při chybě klasifikace nebo API musí integrace umět bezpečný fallback. Přesné znění ponechaných zpráv samo nezaručuje, že agent dostal všechny potřebné informace.
Aktualizace 24. září 2026: Laya přidává lokální variantu
Jirka Herník ve videu z 23. září vedle Jevu zmiňuje Laya. To je nový praktický podnět k porovnání, nikoli zde ověřené datum prvního vydání Laya.
Projektový repozitář nabízí lokální rozhodování nad textem, typované volby a pravděpodobnosti, vlastní HTTP server a licenci Apache‑2.0. Výstup se hodí k routingu; není náhradou generativního modelu pro psaní odpovědi zákazníkovi.
Ukázková stránka uvádí 21 ms na M1 Max a srovnání s Jevem na 500 příkladech. Jde o měření autorů, nikoli náš benchmark nebo obecně platné „200× rychlejší AI“. Autoři zároveň upozorňují na jazykový routing, nekalibrovaný vícejazyčný checkpoint a slabiny při porovnávání čísel.
Pro český a slovenský support bych proto vytvořil oddělenou validační sadu včetně překlepů, krátkých zpráv a smíšených jazyků. Model vybírá frontu, kód kontroluje účetní částky a člověk řeší nejasné případy. Začal bych stínovým během: Laya navrhuje štítky, ale skutečné směrování zatím nemění.
Do pilotu patří podíl chybných automatických voleb, eskalace a čas pracovníka na opravu. Provoz bez poplatku za každý API call stále stojí hardware a správu. Laya má smysl testovat tam, kde potřebujete vlastní provozní hranici; z názvu lokálního modelu neplyne správnost rozhodnutí ani bezpečnost celého workflow.
V mnoha automatizacích nepotřebujete, aby model napsal odstavec. Potřebujete rozhodnout, zda je e-mail reklamace, kam poslat lead nebo jestli dokument vyžaduje ruční kontrolu. Platit v každém takovém kroku za velký generativní model může být zbytečné.
TypeSafe představilo 15. září 2026 Jev, model určený pro typovaná pravděpodobnostní rozhodnutí. V době oznámení jde o early access. Téma se objevilo i v AI mastermind 40 Jirky Herníka ze 17. září. Původní oznámení.
Rozhodovací krok má jiný výstup než chat
Podstatné je omezení výstupu. Jev není určený k psaní libovolných odpovědí; vybírá strukturovaná rozhodnutí v definovaném prostoru. TypeSafe zdůrazňuje typovou správnost a práci s pravděpodobnostmi.
Typově správný výsledek ale ještě nemusí být věcně správný. Hodnota reklamace může být platný štítek a současně špatná odpověď na konkrétní zprávu. To je důvod, proč bych eval postavil na skutečných firemních příkladech, ne na počtu úspěšně parsovaných JSONů.
U supportu bych nejdřív definoval malý slovník: fakturace, technický problém, reklamace, ostatní. Kategorie „ostatní“ je plnohodnotná větev, nikoli chyba, kterou je nutné za každou cenu odstranit.
Návrh zapojení do n8n nebo Make
Představme si následující pipeline. Nový e-mail dostane interní ID, zpracování odstraní nepotřebné přílohy a modelu předá pouze obsah nutný ke klasifikaci. Rozhodovací krok vybere kategorii a aplikace výsledek zvaliduje.
Jednoznačný případ jde do správné fronty. Nejasný případ dostane silnější model nebo člověk. Generativní model píše návrh odpovědi až v další fázi, pokud je vůbec potřeba.
Do logu bych uložil verzi klasifikačního schématu, použitý model, rozhodnutí a následnou opravu pracovníkem podpory. Bez těchto údajů zjistíte počet zpracovaných zpráv, ale nepoznáte, zda systém dlouhodobě třídí správně.
Práh pro automatické zpracování bych odvodil z validační sady. Číslo vydávané za pravděpodobnost nemusí být na vašich datech dobře kalibrované. Univerzální pravidlo „nad 90 % automaticky schválit“ proto není rozumný výchozí bod.
Co znamená nízká cena
TypeSafe uvádí 0,042 USD za milion vstupních tokenů a bezplatný výstup. Výrazný násobek úspory z oznámení vychází ze čtyř vlastních workflow dodavatele. Není to nezávislá garance pro libovolnou úlohu ani důkaz, že Jev nahradí frontier model ve všech krocích.
Pro rozhodnutí o nasazení bych počítal cenu celého procesu: první klasifikaci, eskalace, opakované požadavky a čas lidí na opravy. Levný krok, který posílá příliš mnoho chyb do drahé větve, může být v součtu horší.
U lead triage má falešně negativní výsledek jinou cenu než u štítkování interní poznámky. U faktur bych rozhodovací model nechal vybrat kontrolní frontu; platbu nebo změnu účtu dodavatele by nepovoloval sám.
Pilot, který něco řekne
Vzít bych chtěl několik set historických případů, včetně nejasných a vzácných kategorií. Oddělil bych data pro návrh schématu od sady pro závěrečné vyhodnocení. Referenční štítky by měla potvrdit doménová autorita, ne jiný model.
Vedle celkové přesnosti sledujte záměny kategorií, podíl eskalací, chybovost automaticky přijatých rozhodnutí a cenu jednoho správně dokončeného případu. Po změně schématu zopakujte eval.
Jev mi dává smysl jako kandidát na úzkou rozhodovací vrstvu. Pro volný text, vysvětlování nebo otevřený výzkum budete dál potřebovat jiný nástroj. Největší přínos může vzniknout tím, že velký model přestane řešit tisíce rutinních voleb, které mají jen několik dovolených odpovědí.
Zdroje: TypeSafe: Jev a System One Models, 15. 9. 2026, TypeSafe a early access, Jirka Herník: AI mastermind 40, 17. 9. 2026.
Článek doplněn 22. září 2026, datován podle původního oznámení. Popsané firemní zapojení je návrh pilotu, nikoli vlastní benchmark Jev.