JEV: model, który tylko decyduje

Spora część zastosowań dużych modeli językowych w firmach wbrew pozorom nie ma nic wspólnego z pisaniem. Czy to zgłoszenie do supportu dotyczy płatności, czy błędu? Czy ta transakcja wygląda na oszustwo? Czy ten alert powinien kogoś obudzić o trzeciej w nocy? Model, który umie pisać wiersze, prosimy o odpowiedź jednym słowem, potem piszemy kod, który to słowo parsuje, ponawiamy zapytanie, gdy zamiast słowa wraca cały akapit, i liczymy, że format przetrwa do następnej wersji modelu.

JEV, który TypeSafe AI wypuściło 15 września 2026 roku, zbudowano właśnie wokół tej obserwacji. To pierwszy publiczny model z kategorii, którą firma nazywa modelami System One, i robi dokładnie jedną rzecz. Podajesz mu stan oraz zestaw pytań z wcześniej zdefiniowanymi odpowiedziami, a on dla każdego pytania zwraca wybraną opcję albo ocenę liczbową, razem z prawdopodobieństwem.

Kto za tym stoi

TypeSafe AI powstało w 2024 roku i przed premierą przez mniej więcej dwa lata działało w trybie stealth. Prezes, Diogo Almeida, pracował wcześniej w OpenAI nad uczeniem ze wzmocnieniem na podstawie informacji zwrotnej od ludzi (RLHF). CTO jest Erik Gafni, a COO Sasha Sheng, która w Mecie zajmowała się research engineeringiem w laboratorium FAIR. Nazwa System One brzmi jak ukłon w stronę opisanego przez Daniela Kahnemana szybkiego, intuicyjnego trybu myślenia i dość trafnie oddaje to, czym ten model próbuje być.

Jak to działa

Na wejściu JEV dostaje nieustrukturyzowany stan programu, czyli zgłoszenie, wycinek logów, kawałek JSON-a albo cokolwiek innego, co opisuje sytuację, plus listę typowanych pytań na jego temat. Pytanie może polegać na wyborze jednej z ustalonych kategorii, wystawieniu oceny albo odpowiedzi tak lub nie. Model przetwarza wszystkie pytania w jednym równoległym przebiegu i od razu zwraca komplet odpowiedzi, każdą ze skalibrowaną pewnością.

Odpowiedzi pochodzą ze zbioru, który deklarujesz przed wywołaniem, więc wynik zawsze zgadza się ze schematem. Nie ma stringa do parsowania, a model nie ma jak wymyślić nieistniejącej kategorii. TypeSafe nazywa to podejście Reinforcement Learning for Calibrated Decisions i właśnie nacisk na kalibrację wydaje mi się w nim najciekawszy. Jeśli prawdopodobieństwu da się ufać, możesz ustawić w kodzie progi, odsyłać niepewne przypadki do człowieka albo do większego modelu i wprost zmierzyć ten kompromis.

Szybkość bierze się właśnie z rezygnacji z generowania tekstu. Odpowiedzi wracają w czasie od 70 do 500 milisekund, więc przy tego typu zamkniętych pytaniach JEV jest od kilkudziesięciu do paruset razy szybszy niż duże LLM-y. Z tej samej logiki wynika cennik. Na start JEV kosztuje 0,042 USD za milion tokenów wejściowych, a wyjście jest darmowe, bo praktycznie go nie ma.

Gdzie się sprawdzi

Oczywiste zastosowania to te, które już dziś obsługują LLM-y otoczone mnóstwem kodu klejącego. Routing i triage, scoring leadów albo ryzyka, moderacja i guardraile przed droższym modelem. Wszędzie tam, gdzie pytanie jest zamknięte, a odpowiedź trafia prosto do instrukcji if.

W systemach, nad którymi zwykle pracuję, widzę dla niego miejsce na ścieżce alertów platformy IoT. Gdy urządzenie zgłasza coś dziwnego, jako stan mogłaby trafić ostatnia godzina jego telemetrii i trochę kontekstu o miejscu instalacji, a do tego jedno pytanie: czy to wygląda na awarię czujnika, na prawdziwe zdarzenie wymagające reakcji, czy na szum. Przy kilkuset milisekundach i ułamku centa za wywołanie jest to na tyle tanie, że można to puszczać przy każdym alercie, a prawdopodobieństwo wyznacza naturalne miejsce na granicę, powyżej której kogoś budzimy.

Nie puściłem jeszcze JEV na produkcyjny ruch, więc traktuj to wszystko jako pierwsze wrażenia z lektury i z zabawy samym pomysłem. Kilka rzeczy każe mi jednak zachować ostrożność.

Na co uważać

Najpierw chciałbym mieć własne liczby. Wyniki dokładności, które dotąd krążą, pochodzą z testów samego TypeSafe i, o ile dobrze rozumiem, mierzą, jak często JEV zgadza się z innymi dużymi LLM-ami. Na początek to rozsądne, ale przy prawdziwej decyzji nie zaufałbym mu, dopóki sam nie sprawdzę go na kilkuset przypadkach oznaczonych ręcznie przez człowieka.

Twierdzenie, że JEV nie może halucynować, też trzeba czytać ostrożnie. Model nie zwróci wartości spoza schematu i to jest realna, przydatna gwarancja. Wciąż jednak może z dużą pewnością wybrać złą opcję, a wtedy dostajesz liczbę bez żadnego wyjaśnienia, skąd się wzięła. Przy debugowaniu i w każdym regulowanym środowisku, w którym trzeba umieć obronić decyzję, brak uzasadnienia to poważna luka.

Z tego, co do tej pory widziałem, model traktuje też polecenia bardzo dosłownie, nie potrafi rzetelnie zliczać, ma kłopoty z arytmetyką i porównywaniem dat, traci na dokładności przy pytaniach wymagających kilku kroków pośredniego rozumowania i radzi sobie gorzej, gdy stan jest napchany nieistotnymi danymi. Większość z tego nie dziwi w przypadku modelu, który ma odpowiadać w jednym szybkim przebiegu, i podpowiada, żeby stan był zwięzły, a pytania bezpośrednie.

Ostatnia praktyczna kwestia to dostęp. Bezpośrednie API jest w early access i trzeba zapisać się na listę oczekujących, ale model jest już dostępny przez Vercel AI Gateway, OpenRouter i Cloudflare AI Gateway. Formaty zapytań trochę się między tymi dostawcami różnią, więc warto zdecydować się na jednego i na nim testować, zanim zacznie się przeklejać przykłady.

Dlaczego to i tak ma znaczenie

Nawet z tymi zastrzeżeniami JEV to przydatna korekta tego, jak dotąd używaliśmy modeli językowych. Mnóstwo systemów produkcyjnych potrzebuje tysiące razy dziennie szybkiej, taniej i dobrze skalibrowanej decyzji, a do tej pory jedynym sposobem, żeby dostać ją od dużego modelu, było poprosić o tekst i liczyć na szczęście. Model, którego wyjście jest typowane z definicji, a pewność naprawdę coś znaczy, dobrze pasuje do nudnych, masowych decyzji, z których składa się większość prawdziwego systemu.

Spodziewam się, że ciekawe architektury najbliższego roku czy dwóch będą łączyć oba rodzaje modeli. Model typu System One obsłuży tysiące małych, zamkniętych wywołań, ogólny LLM weźmie na siebie nieliczne przypadki, które naprawdę wymagają rozumowania albo wyjaśnienia, a o tym, który przypadek trafi gdzie, zdecyduje prawdopodobieństwo zwrócone przez pierwszy model. Zamierzam wypróbować dokładnie taki układ w pipelinie alertów i opiszę, co z tego wyszło.