15 września 2026 roku we wczesnym dostępie pojawił się Jev – model AI opracowany przez TypeSafe AI, który działa inaczej niż popularny ChatGPT. Nie tworzy rozbudowanych odpowiedzi – otrzymuje dane i zestaw pytań o określonej strukturze, a następnie zwraca typowane wartości z prawdopodobieństwami. Może odpowiedzieć „tak” lub „nie”, wybrać opcję z listy albo wskazać pozycję na skali. TypeSafe deklaruje czas odpowiedzi od 70 do 500 ms oraz cenę 0,042 USD za milion tokenów wejściowych. Tokeny wyjściowe są bezpłatne.
Takie parametry mogą mieć znaczenie tam, gdzie firmy wykorzystują dziś duże modele językowe do podejmowania prostych, powtarzalnych decyzji. Nie testowaliśmy jeszcze Jev na własnych danych, dlatego poniższe porównanie opieramy na udokumentowanych właściwościach modelu, a nie na naszych pomiarach.
Czym Jev różni się od LLM?
TypeSafe nazywa Jev modelem „System One”. Nazwa nawiązuje do opisanego przez Daniela Kahnemana podziału na szybkie, intuicyjne decyzje i wolniejsze rozumowanie. Jak wyjaśnia DigitalOcean, Jev ma obsługiwać pierwszy rodzaj zadań, a duże modele językowe – drugi.
Jak to działa? Każde zapytanie składa się ze stanu, czyli danych potrzebnych do podjęcia decyzji, oraz pytań w jednym z trzech formatów opisanych w dokumentacji:
Noul: pytanie z odpowiedzią „tak” lub „nie”. Wynikiem jest prawdopodobieństwo odpowiedzi „tak” w skali od 0 do 1.
Choice: wybór jednej z maksymalnie 255 zdefiniowanych opcji. Model zwraca rozkład prawdopodobieństwa i wskaźnik pewności.
Score: wskazanie pozycji na opisanej skali obejmującej od 2 do 10 poziomów. Wynik również zawiera poziom pewności.
Model nie może zwrócić wartości spoza przyjętego schematu. Takie rozwiązanie eliminuje błędy, w których zamiast oczekiwanej etykiety pojawia się całe zdanie. Nie oznacza to jednak, że sama odpowiedź zawsze będzie trafna. Jak zauważa Flavio Copes, błąd formatu i błędna decyzja stają się po prostu osobnymi problemami.
TypeSafe trenuje model metodą nazwaną RLCD, która jest nastawiona na kalibrację wyników. Odpowiedzi z pewnością na poziomie 90% mają być trafne mniej więcej w 90% przypadków.
Dane porównawcze wymagają ostrożnej interpretacji. Informacje, że Jev działa 193,6 raza szybciej i 444,6 raza taniej, pochodzą z wewnętrznych testów TypeSafe. Co więcej, Wikipedia odnotowuje, że firma sama przyznaje możliwe stronnicze podejście w tych ocenach.
DataCamp przytacza z kolei wewnętrzny benchmark, w którym trafność Jev była zbliżona do wyniku jednej z wersji GPT, ale niższa od rezultatów osiąganych przez najmocniejsze modele. Podkreśla też, że niezależnej replikacji na dużą skalę jeszcze nie ma.
Uczciwy obraz jest więc taki: przewaga dotyczy czasu i kosztu pojedynczej decyzji, a jakość trzeba sprawdzić na własnych danych.
Gdzie Jev powinien sprawdzić się lepiej niż ogólny LLM?
Poniższe zastosowania łączy kilka cech: możliwe odpowiedzi są znane przed wysłaniem zapytania, decyzji jest dużo i każda z nich musi zapaść szybko.
Klasyfikowanie zgłoszeń i leadów
Przypisanie ticketu do odpowiedniego działu, ocena pilności lub sprawdzenie, czy formularz kontaktowy zawiera prawdziwe zapytanie ofertowe, a nie spam, to typowe zastosowania formatów Choice i Noul. W jednym wywołaniu można zadać kilka takich pytań. Zgodnie z dokumentacją model ocenia je niezależnie i równolegle względem tego samego stanu. LLM również poradzi sobie z takimi zadaniami, ale przy okazji wygeneruje tekst, za który płacimy, a którego nikt nie potrzebuje.
Routing w agentach AI i w n8n
Agent na każdym kroku podejmuje drobne decyzje: którego narzędzia użyć, czy zadanie wymaga mocniejszego modelu, czy sprawę należy przekazać człowiekowi. LangChain pokazuje Jev w roli routera, który kieruje proste zapytania do szybszych modeli, a trudne do mocniejszych. Może też sprawdzać wywołania narzędzi przed ich wykonaniem. W n8n pojawiły się już nawet społecznościowe węzły, takie jak na przykład n8n-nodes-jev-classification. Są to jednak projekty niezależnych autorów, a nie oficjalne integracje TypeSafe.
Ekstrakcja do typowanych pól
W tym zastosowaniu trzeba pamiętać o ważnym ograniczeniu. Jev nie wygeneruje wartości, której nie ma na liście, więc nie wypisze samodzielnie numeru faktury czy nazwiska. Dokumentacja pokazuje dwa inne podejścia. W pierwszym kod wyszukuje możliwe wartości, na przykład za pomocą wyrażeń regularnych, a Jev wybiera właściwy fragment. W drugim, nazwanym kaskadą ekstrakcji, pola wypełnia tani LLM. Następnie Jev sprawdza każde z nich pytaniem „tak/nie”, takim jak na przykład „czy tej wartości brakuje w źródle?”. Dopiero po wykryciu problemu zadanie trafia do bardziej zaawansowanego modelu rozumującego.
Bramki tak/nie i progi pewności
Wynik Jev może zawierać nie tylko odpowiedź, ale też poziom pewności. W przykładzie z dokumentacji decyzje z wynikiem poniżej progu 0,6 trafiają do człowieka, a ryzykowne operacje, takie jak na przykład zatwierdzenie przelewu, wymagają wyniku powyżej 0,85 – w przeciwnym razie system prosi o dodatkowe potwierdzenie. Zespół ustala progi w kodzie i może je zmieniać bez modyfikowania instrukcji dla modelu.
Warunki w SQL
Wpis na blogu DuckDB opisuje rozszerzenia tworzone przez społeczność, które udostępniają funkcje takie jak jev(), jev_prob() czy jev_choice(). Pozwalają one filtrować i sortować dane według kryteriów semantycznych – na przykład „klient jest zdenerwowany”. Autorzy ostrzegają jednak, że treść rekordów trafia do zewnętrznego API, a trafność spada, gdy jedno zapytanie obejmuje więcej niż 20-25 wierszy.
Moderowanie treści i wykrywanie nadużyć
Moderowanie treści jest wymieniane jako jedno z głównych zastosowań Jev. Dokumentacja zawiera przykład filtrowania wiadomości wysyłanych do aplikacji z LLM i z niej wychodzących. Na podstawie ustalonych progów system może przepuścić wiadomość, skierować ją do sprawdzenia lub zablokować. Natomiast w przypadku wykrywania podejrzanych transakcji Jev powinien być traktowany wyłącznie jako jeden z sygnałów (obok reguł) – dokumentacja ograniczeń wprost mówi, że rozwiązanie słabo radzi sobie z liczbami, obliczeniami i porównywaniem dat. Dlatego zaleca się, aby kwoty, limity i okna czasowe były liczone w kodzie, podczas gdy model może na przykład oceniać, czy opis zamówienia pasuje do profilu klienta.
Gdzie LLM pozostaje niezbędny?
Jev nie generuje tekstu, nie pisze kodu, nie streszcza dokumentów ani nie uzasadnia swoich decyzji. Każda odpowiedź dla klienta, szkic oferty czy raport nadal wymagają modelu generatywnego. Według DigitalOcean krytycy wskazują też słabe wyniki, gdy pytanie zawiera w sobie kilka elementów oceny, wymaga brakujących informacji albo zależy od długiego rozumowania. Dokumentacja dodaje, że Jev czyta polecenia dosłownie, gubi się przy wieloetapowych odwołaniach i traci trafność, gdy stan jest pełen nieistotnych danych.
Pozostaje również kwestia audytu. W procesach, w których trzeba zapisać uzasadnienie decyzji, samo prawdopodobieństwo nie wystarczy. Wtedy Jev może najwyżej wstępnie posortować przypadki, a uzasadnienie i tak musi przygotować człowiek lub LLM.
Jak wybrać odpowiednie rozwiązanie?
Przed podjęciem decyzji warto postawić sobie kilka pytań:
Czy wszystkie dopuszczalne odpowiedzi można określić z góry i zamknąć w maksymalnie 255 opcjach?
Czy decyzja zapada wiele razy dziennie, a czas lub koszt pojedynczego wywołania LLM rzeczywiście stanowi problem?
Czy zadanie można podzielić na pojedyncze, dosłowne oceny, a obliczenia pozostawić po stronie kodu?
Czy dane mogą trafić do zewnętrznej usługi? Jev działa wyłącznie jako hostowane API, a TypeSafe wskazuje, że serwery znajdują się na zachodnim wybrzeżu USA.
Czy na wyjściu wystarczy etykieta – bez tekstu dla człowieka?
Jeżeli większość odpowiedzi brzmi „tak”, warto przeprowadzić pilotaż. Jeśli jednak zadanie wymaga tworzenia tekstu, dłuższego rozumowania albo przetwarzania danych, które nie mogą opuścić firmowej infrastruktury, lepszym wyborem pozostanie LLM – w tym modele uruchamiane lokalnie. Rzeczywisty koszt takiego rozwiązania opisaliśmy w artykule o benchmarku inferencji na MLX.
Jev obok LLM w agencie: szybka warstwa i fallback
W najbardziej obiecującym układzie Jev nie musi zastępować LLM. Doskonale sprawdzi się na przykład jako działająca przed nim szybka warstwa, która obsługuje prostsze decyzje. Taki proces może wyglądać następująco:
Każde zdarzenie najpierw trafia do Jev, który odpowiada na kilka pytań naraz: intencja, pilność, ryzyko.
Przy wysokiej pewności kod działa od razu, na przykład przypisuje ticket albo uruchamia prostą akcję.
Przy średniej pewności zadanie trafia do LLM, który ma więcej kontekstu i może przygotować odpowiedź.
Przy niskiej pewności lub dużym ryzyku decyzję podejmuje człowiek.
Dokumentacja TypeSafe opisuje podobny wzorzec jako routing intencji: część intencji obsługuje zwykły kod (bez żadnego LLM), część trafia do wyspecjalizowanych modeli, a ocena złożoności wskazuje, kiedy potrzebna jest decyzja człowieka.
Wspomniana wyżej kaskada działa odwrotnie – Jev sprawdza wynik taniego modelu. Idea pozostaje jednak ta sama: drogi model dostaje tylko to, czego tańsze etapy nie domknęły. W agencie opartym na skillach (takim jak opisany w tekście o agencie, który wspiera codzienną pracę), Jev mógłby też wybierać moduły potrzebne do bieżącego kroku.
TypeSafe pokazuje taki przypadek w instrukcji wyboru skilla z katalogu 182 skilli agenta Hermes. W tym scenariuszu Jev proponuje agentowi najwyżej jeden moduł na turę, a agent zachowuje własny osąd.
Co mierzyć podczas pilotażu?
Podczas pilotażu warto porównać Jev z obecnie stosowanym rozwiązaniem, na tym samym zestawie ręcznie oznaczonych przykładów. Może w tym pomóc opisany przez Copesa system-one-adapter, który wysyła te same pytania do modeli OpenAI, Anthropic lub Gemini.
Opóźnienie: należy mierzyć medianę i 95. percentyl z własnej lokalizacji, a nie z materiałów dostawcy. W przypadku połączenia z Polski na wynik wpłynie również czas przesyłania danych do serwerów w USA.
Koszt: łączny koszt tokenów na tysiąc decyzji, razem z ponownymi próbami i przypadkami przekazanymi do LLM.
Trafność: warto sprawdzić ją osobno dla każdej klasy. Ogólny wynik może ukryć kategorię, z którą model radzi sobie wyraźnie gorzej.
Kalibracja: najlepiej pogrupować odpowiedzi według pewności i sprawdzić, czy wyniki w przedziale 0,9 rzeczywiście są trafne w około 90% przypadków. Od tego zależy, czy przyjęte progi naprawdę mają sens.
Udział automatyzacji: jaki odsetek przypadków przekracza ustalony próg i nie wymaga udziału człowieka ani LLM.
Na koniec dwie praktyczne uwagi. Po dostrojeniu progów warto przypiąć konkretną wersję modelu, na przykład jev-1.13.0 – alias jev-latest może się zmienić. Polecamy też zweryfikować aktualne limity: w momencie publikacji tekstu Copesa było to 1200 zapytań na minutę, a ze względu na duże zainteresowanie rejestracja nowych kont bywała wstrzymywana.
Jeśli chcesz sprawdzić, czy taka szybka warstwa sprawdzi się w procesach w Twojej firmie, odezwij się do nas. Możemy zaprojektować i wdrożyć agentów AI oraz automatyzacje w n8n i narzędziach no-code. Pilotaż przeprowadzimy na Waszych danych, aby porównać trafność, czas odpowiedzi i rzeczywisty koszt rozwiązania.
