Jev, a gyors döntési modell LLM helyett: mit tud?

Frissítve: 2026. november 10., 16:04 (budapesti idő). Bekerült, hogy a Hugging Face közös interfészt ad a döntési modelleknek.

Szeptember 15-én jött ki a TypeSafe AI „System One” modellosztálya, és vele az első modell, a Jev (bejelentés). A név Kahneman gyors, intuitív „1-es rendszerére” utal, a modellé William Stanley Jevonsra. Az alapító, Diogo Almeida korábban az OpenAI-nál az utasításkövetésen dolgozott.

A rövid verzió: ez nem chatbot. Egy gyors, olcsó döntési réteg a kódunkba.

Hogyan működik?

Beküldünk egy state-et (szöveget, JSON-t vagy szövegtömböt), és erre egyszerre több kérdést teszünk fel. Három típus van (dokumentáció):

Choice: legfeljebb 255 opcióból választ, mindegyikhez valószínűséget ad. Score: rendezett skálán helyezi el a bemenetet. Noul (a Bernoulli rövidítése): egy igen/nem állítás valószínűsége.

Indoklást, kódot, szöveget nem ad. A Hacker Newson Almeida rá is bólintott, hogy ez lényegében egy „zero-shot osztályozó” (HN-vita).

Mire jó? Ticketek routingja, osztályozás, pontozás, szűrés, vagy egy LLM agent kimenetének gyors ellenőrzése. A logikát és a kombinálást a mi kódunk csinálja.

Ár, verziók, kontextus

A hivatalos modelloldal szerint az input 0,042 dollár millió tokenenként (42 dollár milliárdonként), az output ingyenes (Models).

A legfrissebb a Jev 1.14 (2026. október 14-től), ez a jev-preview alias mögött fut. A stabil jev-latest még a 1.13-ra mutat.

Kontextus: kérésenként 64k, kérdésenként 32k token. A TypeSafe-Danger-Zone-Long-Context headerrel mindkettő 262k lesz. A doksi szerint viszont így lassabb és pontatlanabb. Input csak szöveg lehet.

Itt van egy ellentmondás. Az OpenRouter modelloldala a Jev 1.13-hoz 262K kontextust és „szöveg és kép” inputot ír, a P50 késleltetés pedig ott 0,1 s körüli (ellenőrzéskor 0,13 s) (OpenRouter). A TypeSafe saját doksija csak szöveget említ, a 262k-t pedig csak külön headerrel adja. Az OpenRouteren egyébként külön Decisions API-n megy, nem a szokásos chat endpointon (OpenRouter-útmutató).

Mit jelent a „nem hallucinál”?

A TypeSafe blogja maga írja: a hallucinációs grafikonon szereplő 0% „nem empirikus”. Abból jön, hogy a sémának való megfelelés garantált.

Magyarul: a Jev nem tud a megadott opciókon kívüli értéket visszaadni. Egy formailag hibátlan válasz viszont lehet tartalmilag rossz. A Fractional elemzése szerint a TypeSafe GYIK-je is ezt mondja: a forma garantált, a helyesség nem. Egy közösségi auditban a Jev egy kérdésnél 1,00 valószínűséget tett egy rossz válaszra (Fractional).

A so what: ez a garancia nem újdonság. Az OpenAI 2024 augusztusa óta ad structured outputot korlátozott dekódolással, és mások is. A NavyaAI tesztjében szigorú JSON-módban 600 hívásból nulla volt értelmezhetetlen (NavyaAI). Az igazi újdonság máshol van: natív valószínűség opciónként, párhuzamos kérdések egy state-re, csak input utáni díj, és a sebesség.

193,6× és 444,6×, a gyártó saját mérése

A honlapon szereplő „193,6-szor gyorsabb, 444,6-szor olcsóbb” a TypeSafe saját mérése. Négy, a saját csapatuk által írt workflow-n futott, a referenciaválasz a GPT-6 Astra és a Fable 5.1 átlaga volt. A cég maga is elismeri: ezek a valós nyereség felső végén vannak, és lehet benne torzítás.

A független számok jóval szerényebbek. A Fractional szerint döntésre beállított LLM-ekhez képest a Jev kb. 2–3,6-szor gyorsabb és döntésenként kb. 5–50-szer olcsóbb. A 193,6×-ot túlzónak tartják, mert lassú, drága konfigurációkhoz méri magát.

A NavyaAI AG News-hírkategorizálási tesztjében (200 eset) a Jev 87,5–88%-ot hozott, a kis LLM-ek 70–83%-ot. Viszont nem volt olcsóbb a legolcsóbb saját megoldásnál (18,57 vs. 16,30 dollár millió döntésenként), és ahhoz képest csak kb. 1,7–1,9-szer volt gyorsabb.

Kinek éri meg?

Ott erős, ahol sok a döntéstípus és nincs címkézett adat. Címkék nélkül is jó pontosságot ad.

Ha stabil a kategóriarendszer és van pár száz címkézett példa, más a helyzet: a Fractional által idézett tesztekben egy finomhangolt kis osztályozó (pl. DistilBERT) több feladaton jobb volt. A valószínűségeket mindkét elemzés szerint érdemes saját adaton újrakalibrálni. A confidence mezőt pedig ne kezeljük a helyesség esélyeként.

Frissítés: a Hugging Face beállt a döntési modellek mögé

November 10-én a Hugging Face egy blogposztban (bejelentés) leírta, hogyan kezeli az ökoszisztémája a döntési modelleket. A közösség a „System One” helyett a „decision model” névnél kötött ki. A felület ugyanaz, amit a Jevnél láttunk: state, kérdések és megengedett válaszok mennek be, típusos döntés és valószínűségek jönnek ki, choice, score és noul (igen/nem valószínűség) primitívekkel.

A Transformersben megjelent a pipeline("decision"), illetve az AutoModelForDecision és a DecisionConfig osztály. A transformers serve és a llama.cpp is ugyanazt a /v1/systemone végpontot adja, a Hubon pedig decision-model taggel lehet keresni a kompatibilis modelleket. Érdekesség, hogy ez az API kompatibilis autoregresszív LLM-ekkel is működik: a Transformers egyetlen batch-elt forward passban kiértékeli a válaszcímkék logitjait, szöveggenerálás nélkül.

A finomhangolás a megszokott Trainer API-val megy, a TRL natív támogatása (huggingface/trl#8040) még nyitott PR. A so what: ha a modellek egy szabványos végpont mögé kerülnek, a Jev és a nyílt alternatívák ugyanazzal a kóddal cserélhetők, így a saját címkézett tesztkészleten végzett összevetés is olcsóbb lesz.

Mielőtt bekötjük

Az architektúra és az RLCD tanítási módszer nincs nyilvánosan dokumentálva. A doksi szerint az angol a legerősebb nyelv, magyar szövegen tehát kötelező a saját teszt. Az aliasok új kiadáskor elmozdulnak, így prodban érdemes a verziót rögzíteni (pl. jev-1.13.0).

A gyakorlati következő lépés: pár száz saját, címkézett esetet ráengedni, összevetni egy kis LLM-mel structured outputtal, és csak utána dönteni. Lehet, hogy a Jev nyer, de ezt ne a marketingoldalról tudjuk meg.