Jev odmawia napisania choćby jednego słowa: Co robi model decyzyjny TypeSafe AI i czego nikt jeszcze nie zweryfikował

Jev to pierwszy model od TypeSafe AI, z którym czytelnik prawdopodobnie zetknie się raczej przez tabelę kosztów niż przez okno czatu, ponieważ nie ma okna czatu. Wprowadzony na rynek 15 września 2026 r. przez Diogo Almeidę — współautora artykułu o InstructGPT, pracy, która sprawiła, że ChatGPT zachowuje się jak asystent — Jev w ogóle nie generuje tekstu. Przyjmuje fragment stanu (e-mail, wiersz logu, zgłoszenie do pomocy technicznej, blob JSON ze współrzędnymi gry) oraz listę typizowanych pytań i zwraca typizowane odpowiedzi: wybór ze zbioru, który podałeś, punktację według rubryki albo prawdopodobieństwo odpowiedzi tak/nie, przy czym każda z nich ma własną wartość ufności. Żadnej prozy, żadnego kodu, żadnych wyjaśnień. Argumentacja TypeSafe jest taka, że ta wąska specjalizacja jest produktem, ponieważ zapewnia szybkość i cenę, którym model generatywny nie dorówna — od 20 do 200 razy szybciej i od 40 do 400 razy taniej niż „porównywalne LLM-y” w materiałach premierowych samej firmy, w cenie 0,042 USD za milion tokenów wejściowych, z wyjściem rozliczanym po zerowej stawce.

Najbardziej użyteczna liczba opublikowana w pierwszych 48 godzinach nie jest jedną z nich. Pochodzi ona od Every, którego szef ds. ewaluacji przeprowadził Jev przez 27 opublikowanych artykułów Every plus 10 odpowiedników stylizowanych na AI, zadając 21 pytań do wszystkich 37 dokumentów naraz: 777 ocen w mniej niż 0,7 sekundy, za około ćwierć centa. Drugi test, przeprowadzony przez dyrektora generalnego Every, skonfrontował 12 syntetycznych fragmentów — sześć czystych, sześć z celowo wszczepionymi usterkami — z czterema testami pisarskimi. Jev zwrócił wynik na poziomie mediany 0,35 sekundy na fragment wobec 8,83 sekundy dla Claude Fable 5.1 przy wysokim wysiłku: około 25 razy szybciej przy koszcie stanowiącym mniej więcej 1/580. Wykrył sześć z siedmiu wszczepionych usterek. Claude Fable 5.1 wykrył wszystkie siedem. Werdykt Every brzmiał „dobry, ale nie doskonały", i to jest uczciwe jednozdaniowe odczytanie Jev z jedynego niezależnego testu, jaki ktokolwiek dotąd opublikował — twierdzenia o szybkości i koszcie wytrzymują kontakt z osobą trzecią, twierdzenie o dokładności plasuje się o oczko poniżej czołówki, a próba jest na tyle mała, że nikt nie powinien wyciągać z niej wniosków produkcyjnych.

Uwaga o tym, z jakiego rodzaju dowodami pracuje ten tekst, ponieważ poziomy są wyjątkowo odległe jak na tak nowy model. Jev jest prawdziwy i można go wywołać: istnieje udokumentowany endpoint, SDK dla Pythona, alias modelu i opublikowana cena. Premiera została ogłoszona przez dostawcę, a nie wyciekła, i nikt nie zgaduje, czy istnieje. Ale każde twierdzenie o wydajności, które TypeSafe wysuwa na pierwszy plan, pochodzi od samego TypeSafe, architektura nie została opublikowana, wagi nie są udostępnione, a panel benchmarków stojący za nagłówkiem 20-200x to zestaw wewnętrznych ocen przepływów pracy, a nie publiczny ranking. Jeden podmiot zewnętrzny go przetestował. Ten artykuł utrzymuje dane dostawcy, dane niezależne i otwarte pytania wyraźnie rozdzielone, zamiast uśredniać je do konsensusu, który nie istnieje.

Co TypeSafe faktycznie wydało

Jev jest pierwszym z tego, co TypeSafe nazywa modelami System One — nazwa zapożyczona od szybkiej, intuicyjnej połowy poznania Daniela Kahnemana, w przeciwieństwie do wolniejszego, deliberatywnego trybu, który naśladują chatboty. Kontrast, jaki rysuje TypeSafe, dotyczy standardowego wzorca zmuszania generatora tekstu do emitowania ustrukturyzowanych danych wyjściowych, a następnie parsowania tego tekstu z powrotem na coś, czemu kod może zaufać. Jev całkowicie pomija tekst. Własna dokumentacja TypeSafe ujmuje to bez ogródek: „Duże modele językowe (LLM) są projektowane do tworzenia tekstu dla ludzi do czytania. Kiedy potrzebujesz, aby model dokonał oceny, którą wykorzysta Twój kod, powstaje niedopasowanie”.

Powierzchnia wyjściowa to trzy prymitywy i nic więcej. Każde pytanie, które zadasz, musi być jednym z nich:

• Wybór — wybierz jedną opcję z listy, którą podasz, zwracając wybraną opcję oraz prawdopodobieństwo dla każdego kandydata i poziom ufności. Liczba opcji jest ograniczona do 255 na pole; powyżej tego TypeSafe dokumentuje dwuetapowy wzorzec polegający na niezależnym ocenianiu kandydatów, a następnie dokonaniu wyboru.

• Ocena — umieść stan na uporządkowanej skali ocen, zwracając poziom, prawdopodobieństwo dla każdego poziomu oraz pewność. Przykładem w dokumentacji jest ryzyko rezygnacji w skali 0–1.

• Noul — zlepek słów „no” i „null” — pojedyncze twierdzenie typu tak/nie, zwracające skalibrowane prawdopodobieństwo, że jest prawdziwe.

Ciekawa właściwość nie tkwi w żadnym pojedynczym prymitywie, lecz w sposobie, w jaki się składają. Wszystkie trzy można połączyć w jednym wywołaniu API, a każde pytanie jest oceniane równolegle względem jednego wspólnego odczytu tego samego stanu. Dokumentacja TypeSafe mówi, że dodawanie pytań „ledwie zmienia czas odpowiedzi”, a niezależny test potwierdza to w praktyce — 21 pytań w 37 dokumentach zmieściło się w tych samych 0,7 sekundy. To właśnie sprawia, że cena za ocenę gwałtownie spada: nie płacisz za dłuższe generowanie, płacisz za jedno przejście.

Praktyczny zakres, zgodnie z dokumentacją i relacjami wczesnych użytkowników: budżet żądania wynoszący około 32 000 tokenów, opisywany w dokumentacji TypeSafe jako około 150 000 znaków angielskich; brak wejścia obrazu lub dźwięku na starcie; oraz kształt żądania i odpowiedzi, który nie jest zgodny z konwencją OpenAI chat-completions, więc wywołanie go wymaga dedykowanego klienta, a nie zmiany bazowego URL-a. Dostęp to lista oczekujących na wczesny dostęp oraz przeglądarkowy plac zabaw, z code>jev-latest/code> jako alias modelu.

RLCD oznacza skalibrowany, a nie preferowany

TypeSafe szkoli Jev metodą, którą nazywa RLCD — Reinforcement Learning for Calibrated Decisions, zgodnie z dokumentacją samej firmy. Skrót jest tak nowy, że we wczesnych omówieniach rozwijano go niekonsekwentnie, warto więc ustalić, do czego właściwie się odnosi, ponieważ to rozróżnienie stanowi całą tezę badawczą.

RLHF optymalizuje pod kątem wyników preferowanych przez ludzi. RLVR optymalizuje pod kątem weryfikowalnej poprawności — tej, w której przypadki testowe przechodzą. RLCD optymalizuje pod kątem kalibracji: model, który mówi, że ma 70% pewności, powinien mieć rację mniej więcej w 70% przypadków. To inny cel niż mieć rację i dlatego każda odpowiedź Jev jest dostarczana z dołączonym rozkładem prawdopodobieństwa, a nie tylko z samą odpowiedzią. Zamierzonym trybem awarii jest model, który wie, kiedy nie wie, dzięki czemu Twój kod może zdecydować, co z tym zrobić.

To, co to daje w praktyce, to powierzchnia sterowania. Udokumentowany wzorzec to trzy pasma ufności — działaj automatycznie na górze, oznacz lub potwierdź w środku, przekaż do człowieka na dole — przy czym progi znajdują się w twoim kodzie, a nie w modelu. To, czy pasma są uczciwe, jest pytaniem empirycznym dotyczącym twoich danych i to pytanie TypeSafe wyraźnie każe ci rozstrzygnąć samodzielnie, zauważając, że progi ufności zależą od przypadku użycia i należy je testować na własnych oznaczonych przykładach. Ta instrukcja to najważniejsze zdanie w dokumentacji i powód, dla którego istnieje następna sekcja.

Liczby, posortowane według tego, kto je wyprodukował

Tu większość doniesień o Jevie traci ostrość, dlatego warto wyraźnie określić pochodzenie informacji. Oto, co pochodzi od dostawcy, co od niezależnego testera, a co jest po prostu nieznane.

• Zgłoszone przez dostawcę, nieodtworzone — główne twierdzenia dotyczące szybkości i kosztów. 70–500 ms opóźnienia end-to-end w porównaniu z 3–329 sekundami dla wywołań frontier LLM; 20–200x szybciej i 40–400x taniej; pojedynczy wynik przepływu pracy z najlepszego przypadku reklamowany jako 193,6x szybszy i 444,6x tańszy. TypeSafe przyznaje, że są to wartości z najlepszego przypadku, a nie uniwersalne.

• Zgłoszone przez dostawcę i możliwe do zweryfikowania w cenniku — 0,042 USD za milion tokenów wejściowych, co daje 42 USD za miliard, a wyjście jest bezpłatne. Powód, dla którego wyjście jest bezpłatne, jest mechaniczny, a nie promocyjny: nie ma dekodowania autoregresyjnego do mierzenia, więc nie ma tokenów wyjściowych do rozliczenia. Dla porównania: te same materiały premierowe podają typową cenę tokenów wejściowych dla modeli frontier na poziomie od 0,20 USD do 10 USD za milion, przy czym cena wyjścia jest często około pięciokrotnie wyższa od ceny wejścia.

• Zgłoszone przez dostawcę, z wewnętrznego benchmarku — własny dashboard przepływu pracy firmy TypeSafe, 711 przypadków w czterech zadaniach, z odpowiedziami referencyjnymi opartymi na średniej ocenie GPT-6 Astra i Claude Fable 5.1, a nie na danych wzorcowych. Na tym dashboardzie Jev osiąga łącznie 67,8% wobec 74,1% dla najlepszego rozwiązania porównywanego. W rozbiciu: incydenty bezpieczeństwa 61,7% wobec 66,2% dla Opus 5; obserwowalność śladów agentów 71,6% wobec 76,6%; przetwarzanie faktur 61,8% wobec 79,1%; obsługa klienta 76,0% wobec 78,3%. Jev wygrywa w kolumnach kosztu i opóźnienia na tym wykresie, a przegrywa w kolumnie dokładności. Sam dashboard zauważa możliwe obciążenie związane z harnessem, a firma TypeSafe stwierdziła, że celowo pominęła publiczne rankingi na rzecz jednorazowych ewaluacji powiązanych z aktualizacjami produktu.

• Niezależny pomiar, mała próba — opisane powyżej testy Every: 777 ocen w mniej niż 0,7 sekundy za około ćwierć centa; 1709 ocen w 11 eksperymentach łącznie za mniej niż centa; około 25 razy szybciej i 1/580 kosztu Claude Fable 5.1 w zadaniu klasyfikacji 12 fragmentów, przy jednoczesnym przeoczeniu jednej z siedmiu celowo wprowadzonych wad, które wychwycił komparator. Własny wniosek Every był taki, że przed wdrożeniem do produkcji chciałby znacznie wnikliwszego sprawdzenia dokładności.

• Nieznana — architektura. Brak publikacji przy premierze, brak liczby parametrów, brak ujawnienia mocy obliczeniowej użytej do trenowania, brak wag. TypeSafe powiedział, że szczegóły są na razie trzymane „w tajemnicy”, a publikacja być może pojawi się później.

Wzorzec na tych poziomach jest spójny i nie jest to wzorzec, który sugeruje nagłówek o 200x. Wszystkie niezależne dane i dane dostawcy są zgodne co do tego, że Jev jest drastycznie tańszy i drastycznie szybszy. Żadna liczba nigdzie, w tym własne liczby TypeSafe, nie pokazuje, że jest on dokładniejszy niż modele frontier, z którymi jest porównywany cenowo. Na własnym panelu dostawcy plasuje się mniej więcej na poziomie dobrego modelu średniej klasy. Porównanie, które się broni, to nie „tak samo inteligentny jak model frontier za jedną setną ceny” — lecz „zbliżony do osądu modelu średniej klasy przy ułamku centa za wywołanie, wystarczająco szybki, by uruchamiać go przy każdej pojedynczej turze”.

Co oznacza, a czego nie oznacza „zero halucynacji”

Materiały premierowe TypeSafe zawierają wykres pokazujący 0% odsetek błędów wywołań narzędzi dla Jev w porównaniu z niezerowym odsetkiem dla modeli porównawczych, a określenie „odporny na halucynacje” towarzyszy modelowi. Oba są prawdziwe i oba są węższe, niż sugeruje ich brzmienie.

Gwarancja ma charakter strukturalny. Każda możliwa odpowiedź jest wyliczona, zanim model zostanie uruchomiony — to ty dostarczyłeś listę wyborów, kryteria oceny albo twierdzenie prawda/fałsz — więc nie ma miejsca, w którym można by wyemitować wartość spoza zadeklarowanego typu. Niepoprawnie sformułowane wywołanie narzędzia nie jest czymś, co Jev może wygenerować. To prawdziwa właściwość inżynierska i dla każdego, kto spędził tydzień na pisaniu logiki ponawiania wokół błędów parsowania JSON, jest warta realnych pieniędzy.

To nie jest twierdzenie o poprawności. Odpowiedź zgodna ze schematem wciąż może być błędna: Jev może z pełnym przekonaniem skierować reklamację rozliczeniową do kolejki technicznej, a wynik będzie idealnie poprawny formalnie, choć bezużyteczny. Sam Almeida mówił o tym wprost, przyznając, że można z pełnym przekonaniem się mylić. Użytecznym sposobem pogodzenia obu tych faktów jest to, że Jev eliminuje klasę błędów wynikających z formatowania danych wyjściowych, a nie robi zupełnie nic w kwestii klasy błędów wynikających z osądu. Co oznacza, że kwestia dokładności jest w całości kwestią kalibracji, a kalibracja to dokładnie to, co musisz zmierzyć samodzielnie.

Jak przetestować twierdzenie o kalibracji na własnych danych

Kalibracja to jedna z nielicznych właściwości modelu, którą można rzetelnie sprawdzić za pomocą kilkuset przykładów i bez infrastruktury ML, i jest to jedyny test, który się liczy, zanim Jev dotknie ścieżki produkcyjnej. Procedura jest krótka.

Weź kilkaset przypadków, dla których masz już etykiety. Zadaj Jevowi pytanie, które ma znaczenie — o decyzję routingową, wynik ryzyka, sprawdzenie defektu — i pogrupuj odpowiedzi według zgłoszonego poziomu pewności. Następnie sprawdź, czy przedział z pewnością 0,9 ma rację w około 90% przypadków, przedział 0,7 w około 70%, i tak dalej. Dobrze skalibrowany model kreśli linię diagonalną. Model, który jest jedynie pewny siebie, grupuje wszystko powyżej 0,9 i ma rację w 70% przypadków — i to jest ten kształt, który po cichu psuje zautomatyzowany potok.

Ten sam test mówi ci, jakich progów użyć. Jeśli przedział 0,9 naprawdę ma 90% dokładności na twoich danych, możesz go zautomatyzować. Jeśli twoje środkowe pasmo to papka, kierujesz je do człowieka albo przekazujesz modelowi generatywnemu i pozwalasz, by kosztowna ścieżka zajęła się niejednoznacznością. Ten podział — tani model dla pewnej większości, kosztowny model dla niepewnej reszty — to rzeczywista architektura, za którą opowiada się Jev, i dlatego model najlepiej rozumieć jako komponent, a nie zamiennik.

Ile to kosztuje, krok po kroku

Cennik jest na tyle prosty, że łatwo go analizować, co rzadko się zdarza. Wejście kosztuje 0,042 USD za milion tokenów. Wyjście jest bezpłatne. Przy udokumentowanym budżecie żądania wynoszącym około 150 000 znaków pojedyncze wywołanie o maksymalnym rozmiarze kosztuje znacznie poniżej centa.

Dwie podane liczby dają wyobrażenie o skali. Wczesny użytkownik wykonał około 5000 żądań za mniej więcej 2 dolary. Demonstracja Doom — Jev sterujący botem za pomocą tekstowego opisu stanu gry, a nie surowych pikseli — działała z szybkością około 10 wywołań na sekundę za około 7 dolarów na godzinę. A 777 ocen Every w 37 dokumentach kosztowało około jednej czwartej centa — i to właśnie ta liczba sprawia, że interesujący przypadek użycia staje się czytelny: przy tej cenie sprawdzanie każdego pojedynczego kroku pętli agenta przestaje być decyzją kosztową i staje się domyślnym działaniem.

To jest prawdziwy argument za Jev. Przebieg weryfikacji po każdej turze — czy to wywołanie narzędzia było sprzeczne z poprzednim, czy ten wynik jest zgodny z deklarowanym zamiarem użytkownika, czy powinno to wzbudzić sygnał ostrzegawczy — od zawsze był technicznie możliwy przy użyciu modelu frontierowego i ekonomicznie absurdalny na dużą skalę. Przy cenie 0,042 USD za milion tokenów bez opłaty za wyjście ten sam przebieg staje się przystępny cenowo w każdej turze. Wartość nie polega tu na tym, że Jev myśli lepiej niż model frontierowy, ponieważ tak nie jest. Wartość polega na tym, że myśli wystarczająco tanio i szybko, by być nieustannie konsultowanym.

Warto powiedzieć to wprost, bo to oczywiste kolejne pytanie: OrcaRouter nie obsługuje Jev. Model TypeSafe jest we wczesnym dostępie, na liście oczekujących i posługuje się własnym formatem żądań, więc każdy, kto go testuje, przechodzi bezpośrednio przez TypeSafe. Miejsce, w którym warstwa routingu faktycznie pasuje, to druga połowa przepływu pracy. Wzorzec, dla którego zaprojektowano Jev, to dwa modele, a nie jeden — Jev podejmuje typowaną decyzję, a model generatywny obsługuje część, która wymaga prozy, kodu lub wyjaśnienia. Ta generatywna połowa to część, którą obejmuje OrcaRouter: 197 modeli od 15 dostawców pod jednym kluczem kompatybilnym z OpenAI, w cenie katalogowej dostawcy przekazywanej dalej z 0% narzutu, więc obniżka ceny od dostawcy trafia na naszą stronę tego samego dnia, w którym zostaje wprowadzona. Obie połowy przepływu pracy w stylu Jev można testować bez drugiej umowy, a gdy komponent decyzyjny nie został jeszcze sprawdzony, ścieżka przełączania awaryjnego sprawia, że zły wynik kalibracji nie staje się incydentem produkcyjnym.

Gdzie Jev nie pasuje

Ograniczenia są wyjątkowo jasno określone przez dostawcę, co sprawia, że tę sekcję łatwo napisać uczciwie. Jev nie potrafi generować swobodnego tekstu. Nie potrafi pisać kodu. Nie potrafi prowadzić rozmowy. Nie ma interfejsu czatu ani możliwości wprowadzania obrazów, a jego budżet kontekstu wynosi około 32 000 tokenów — o rząd wielkości mniej niż modele o długim kontekście, z którymi porównuje się go pod względem ceny. Pola wyboru mają limit 255 opcji. A właściwość „brak halucynacji”, jak wyżej, dotyczy formatu wyjściowego, a nie prawdziwości.

Ta sieć ma dość wąskie zastosowanie. Dobrze: masowa klasyfikacja i routing, przebiegi zabezpieczeń i weryfikacji, decyzje krytyczne pod względem opóźnienia, ocenianie dużych zbiorów dokumentów równolegle, wszędzie tam, gdzie poprawna odpowiedź jest rzeczywiście wyborem, liczbą na skali lub wartością logiczną. Słabo: generowanie otwarte dowolnego rodzaju, rozumowanie na długim kontekście, dialog wieloturowy lub dowolne zadanie, którego poprawna odpowiedź jest zdaniem. Jeśli twojego problemu nie da się sprowadzić do pytania z określonym typem odpowiedzi, Jev nie jest tańszym sposobem na jego rozwiązanie — nie jest żadnym sposobem na jego rozwiązanie.

Istnieje też słuszna krytyka tego ujęcia, którą warto podtrzymać. Nazywanie Jev modelem frontier zapożycza wiarygodność, której ten model nie zdobył: nie potrafi kodować, rozmawiać ani napisać zdania, a wykresy porównawcze opierają się na modelach frontier jako punkcie odniesienia, podczas gdy kolumna dokładności opowiada inną historię. Twierdzenie, którego łatwiej bronić — i które dowody rzeczywiście potwierdzają — jest takie, że TypeSafe przesunęło granicę szybkości i kosztów w decyzjach strukturalnych bardzo daleko. To poważne osiągnięcie. To jednak coś innego niż zbudowanie modelu, który dorównuje GPT-6 Astra lub Claude Fable 5.1.

Co zmieniłoby ten obraz

Trzy rzeczy, w przybliżonej kolejności według tego, jak bardzo by miały znaczenie.

• Opublikowana praca o architekturze albo otwarte wagi. Wszystko dotyczące tego, jak Jev osiąga swoją szybkość, jest obecnie czarną skrzynką, a twierdzenie, że mechanizmem jest równoległa ewaluacja — analogia, którą przywołuje Almeida, to zastąpienie obliczeń sekwencyjnych tak, jak transformery zastąpiły sieci rekurencyjne — jest asercją, a nie wykazanym wynikiem. Dopóki projekt nie zostanie opublikowany, szybkość jest faktem, a wyjaśnienie to marketing.

• Druga niezależna ocena na większej próbie. Testy Every są najsilniejszym dostępnym dowodem i obejmują 12 fragmentów w decydującej kwestii dokładności. Jeszcze jedno niezależne uruchomienie, na kilkuset oznaczonych przypadkach, rozstrzygnęłoby, czy przeoczenie jednego defektu na siedem było szumem, czy rzeczywistym odsetkiem błędów.

• Audyt kalibracji na realistycznych, nieuporządkowanych danych wejściowych. Wszystko, co dotychczas opublikowano, korzysta z czystych stanowisk testowych. Otwartym pytaniem w przypadku modelu, którego cała propozycja wartości opiera się na wiarygodnych ocenach pewności, jest to, jak te oceny zachowują się w naprawdę niejednoznacznych przypadkach — takich, w których zawahałby się także człowiek recenzent. To właśnie ta liczba decyduje o tym, czy Jev jest bezpieczny jako podstawa automatyzacji, i nikt jej nie opublikował.

Do tego czasu rozsądną postawą jest konkret, a nie ogólnik. Jev to prawdziwy, wdrożony, wyjątkowo tani model o autentycznej przewadze strukturalnej w niezawodności wyników, profilu dokładności plasującym się w okolicach średniej półki oraz twierdzeniu o kalibracji, które jest wiarygodne, wprost zalecane do samodzielnego testowania przez samego dostawcę i niezależnie zweryfikowane tylko na małej próbie. Jeśli Twój przepływ pracy zawiera krok sprowadzający się do wpisanego pytania zadawanego wystarczająco często, by model czołowy był marnotrawstwem, to jeden z najtańszych sposobów, by je zadać — a zwracana przez niego wartość pewności jest tym, co należy przetestować, zanim jej zaufasz, nie szybkość.