Jev: gdzie w naszych grafach LangGraph mieści się model, który nie pisze zdań

„Model, który nigdy nie napisze zdania" brzmiało jak żart, dopóki nie policzyliśmy, ile zdań nasz własny stos generuje bez żadnej potrzeby. Piętnastego września TypeSafe AI pokazało Jeva — pierwszy model z klasy „System One System One to nowa klasa modeli AI (pierwszym jest Jev od TypeSafe AI), która zamiast tekstu zwraca typowaną decyzję ze skalibrowanym prawdopodobieństwem — bez generowania i parsowania ciągu znaków, więc działa dużo szybciej i taniej niż zwykły LLM. Pełna definicja →": dostaje fragment stanu programu i zestaw pytań o z góry znanym zbiorze odpowiedzi, a zwraca nie tekst, tylko typowaną decyzję z kalibrowanym prawdopodobieństwem, w 70–500 ms. Zamiast czytać to jako kolejną premierę modelu, przeszliśmy własne pięć grafów LangGraph LangGraph to narzędzie dla programistów do budowania agentów AI, które realizują wieloetapowe procesy z rozgałęzieniami, zamiast odpowiadać jednym krokiem. Pełna definicja → — te same, które renderujemy na stronach produktowych — węzeł po węźle i zapytaliśmy o każdy punkt decyzyjny: to zadanie dla Jeva, to wciąż praca dla LLM LLM (Large Language Model) to rodzaj modelu AI — jak ten stojący za ChatGPT — wytrenowany na ogromnej ilości tekstu, by rozumieć i generować ludzki język. Pełna definicja →, czy to w ogóle nie jest decyzja modelu.

Po co ten artykuł

Moglibyśmy napisać „przetestowaliśmy nowy model od TypeSafe" — takich tekstów po premierze będą dziesiątki i żaden nie będzie miał nic wspólnego z naszym kodem. Wolimy odpowiedzieć na pytanie, które faktycznie mamy: mamy pięć produkcyjnych agentów zbudowanych na LangGraph, każdy z własnym grafem sterowania, i w każdym z nich są miejsca, gdzie model językowy nie generuje treści, tylko wybiera jedną z kilku znanych z góry opcji. Jev celuje dokładnie w tę drugą kategorię. Więc przeszliśmy graf po grafie, wypisaliśmy każdy taki punkt i wystawiliśmy mu werdykt: kandydat, zostaje przy LLM, albo w ogóle nie dotyczy modelu. Poniżej cała tabela, łącznie z trzema powodami, dla których na razie nic nie migrujemy.

Czym jest klasa System One, na przykładzie Jeva

Zwykły LLM, nawet wywołany jako klasyfikator, robi to samo co przy generowaniu długiego tekstu: przewiduje token Token to fragment tekstu, zwykle kawałek słowa, w którym modele AI mierzą i długość zapytania, i koszt — rachunek wystawiany jest za tokeny, nie za pytania. Pełna definicja → po tokenie, sekwencyjnie, aż wygeneruje ciąg, który trzeba potem sparsować z powrotem do struktury. Jev pomija ten krok. Dostaje blok stanu i zestaw typowanych pytań z zamkniętym zbiorem odpowiedzi, ocenia wszystkie naraz w jednym przejściu równoległym i zwraca ocenę oraz skalibrowane prawdopodobieństwo dla każdej opcji — bez generowania ciągu znaków, bez parsowania na wyjściu. Stąd deklarowany czas odpowiedzi end-to-end 70–500 ms i 40–200 razy niższy koszt niż modele frontier na tej samej klasie zadań.

Nazwa nie jest przypadkowa. TypeSafe nazwało model na cześć Williama Stanleya Jevonsa — ekonomisty, którego nazwisko nosi paradoks Jevonsa: kiedy koszt czegoś spada gwałtownie, popyt na to coś nie maleje proporcjonalnie, tylko eksploduje, bo pojawiają się zastosowania, które przy starej cenie w ogóle nie miały sensu. Teza TypeSafe brzmi: skoro pojedyncza decyzja kosztuje ułamek centa i trwa pół sekundy, aplikacje zaczną odpytywać model w miejscach, w których dziś w ogóle nie sięgają po LLM — nie dlatego, że LLM by sobie nie poradził, tylko dlatego, że przy starej cenie i starym opóźnieniu nikomu nie chciało się o to pytać.

Warto być precyzyjnym co do jednej rzeczy: „nie może zhalucynować" w materiałach TypeSafe znaczy „nie zwróci wartości spoza zadeklarowanego typu", nie „nie może się pomylić". To gwarancja formatu, nie gwarancja trafności. Na własnym benchmarku czterech przepływów pracy TypeSafe podaje 67,8% trafności — i to jest liczba, którą warto trzymać obok każdej deklaracji „bez halucynacji Halucynacja to odpowiedź AI, która brzmi wiarygodnie, ale jest nieprawdziwa — model uzupełnia lukę domysłem, zamiast przyznać, że nie wie. Pełna definicja →", nie zamiast niej.

Cena i to, czego dziś nie umiemy nią policzyć

Jev kosztuje 0,042 USD za milion tokenów wejściowych, a wyjście jest darmowe — TypeSafe pisze wprost „too cheap to meter". To struktura cenowa, jakiej nie ma żaden model w naszym własnym kalkulatorze kosztu agenta: najtańsza pozycja w tabeli cen, gpt-5.4-nano, kosztuje 0,20 USD za milion wejścia i 1,25 USD za milion wyjścia, a sam typ danych w kodzie kalkulatora zakłada, że cena wyjścia zawsze istnieje i jest większa od zera. Formalnie: żeby policzyć oszczędność z przejścia na Jeva w naszym własnym narzędziu, musielibyśmy najpierw zmienić strukturę danych, która to narzędzie opisuje. To nie jest argument przeciwko migracji — to lista rzeczy do zrobienia, zanim ktokolwiek policzy konkretną złotówkę.

Nasz stos: pięć grafów, dwanaście punktów decyzyjnych

Na stronach produktowych publikujemy diagramy LangGraph pięciu agentów: asystenta księgowego, asystenta budżetowego, asystenta e-marketingu, orkiestracji Orkiestracja to koordynowanie wielu modeli, narzędzi i agentów tak, by pracowały nad jednym zadaniem w ustalonej kolejności i przekazywały sobie wyniki. Pełna definicja → testów i bazy wiedzy prawnej. Przeszliśmy każdy z nich i wypisaliśmy każdy węzeł, w którym graf się rozgałęzia na z góry znany zbiór odpowiedzi — nie każdy krok przetwarzania, tylko punkty, w których ktoś (model albo kod) wybiera jedną z kilku opcji. Wyszło dwanaście takich punktów w pięciu grafach.

flowchart TB
  subgraph KEEP["Zostaje przy LLM (ocena wygenerowanej treści)"]
    K1["Czy wygenerowany test<br/>jest poprawny"]
    K2["Czy wygenerowana checklista<br/>jest poprawna"]
    K3["Czy poprawiona treść<br/>prawna jest poprawna"]
  end
  subgraph CAND["Kandydat na model decyzyjny (zamknięty zbiór odpowiedzi)"]
    C1["Czy wywołać narzędzie<br/>(co krok pętli)"]
    C2["Typ akcji: odpowiedź,<br/>odczyt czy zapis"]
    C3["Który z 7 specjalistów<br/>przejmuje zadanie"]
    C4["Typ wiadomości"]
    C5["Czy baza wiedzy<br/>pokrywa pytanie"]
    C6["Intencja: pytanie<br/>czy edycja"]
  end
  subgraph SKIP["Nie ruszamy albo niepewne"]
    S1["Potwierdzenie<br/>użytkownika"]
    S2["Który z 5 agentów<br/>testowych (mechanizm nieznany)"]
    S3["Filtr danych osobowych<br/>(fail-closed)"]
  end

Rozkład nie jest równy. Trzy punkty to generowanie albo ocena wolnej treści — tam Jev nie ma czego szukać, bo z definicji nie generuje tekstu. Sześć to zamknięta klasyfikacja albo routing z niewielką liczbą opcji — dokładnie zadanie, do którego Jev został zaprojektowany. Pozostałe trzy to punkty, które w ogóle nie są decyzją modelu: potwierdzenie użytkownika to wejście od człowieka, nie wnioskowanie; filtr danych osobowych działa fail-closed, czyli musi być deterministyczny z definicji; a o jednym węźle diagram po prostu nie mówi, kto go dziś podejmuje.

Werdykt węzeł po węźle

Trzy wiersze zasługują na rozwinięcie, bo pokazują, że „kandydat" nie znaczy „byle jaki klasyfikator się nada".

Dispatch specjalisty w asystencie e-marketingu to najczęściej wywoływany punkt decyzyjny w całym stosie — działa na każdej wiadomości użytkownika, zanim dojdzie do któregokolwiek z siedmiu wyspecjalizowanych agentów (treść, SEO, e-mail, checklisty, strategia, analityka, dokumenty). Dziś tę decyzję podejmuje GPT-4o jako część wywołania narzędzia. To dokładnie ten rodzaj pracy, o którym TypeSafe mówi w materiałach premierowych: wysoki wolumen, powtarzalna decyzja, znany z góry zbiór odpowiedzi.

Which agent w orkiestracji testów wybiera jeden z pięciu wyspecjalizowanych agentów (generator testów, wykrywacz błędów, generator checklist, doradca pokrycia, wykrywacz niestabilnych testów) na podstawie tego, co przyszło na wejściu — zmiana kodu czy PR. Diagram nie mówi wprost, czy to LLM czy prosty routing po typie triggera, więc traktujemy to jako kandydata warunkowego: jeśli to dziś LLM, Jev pasuje; jeśli to zwykły routing po etykiecie PR-a, nie ma czego zastępować.

Coverage w bazie wiedzy prawnej to najciekawszy przypadek w całym audycie, więc dostał osobną sekcję.

Najciekawszy przypadek: próg zamiast modelu

Większość „kandydatów" w tej tabeli to dziś wywołanie LLM, które można by zastąpić tańszym i szybszym wywołaniem. Coverage to co innego: sądząc po diagramie, węzeł idzie bezpośrednio po „retrieve · cosine top-K" i pyta „czy pokrycie jest wystarczające, żeby odpowiedzieć, czy wstrzymać się i powiedzieć «nie znam odpowiedzi»". To brzmi jak zwykły próg liczbowy na wyniku podobieństwa kosinusowego, dobrany ręcznie i pewnie niejeden raz poprawiany po tym, jak system albo odpowiedział na coś, czego nie powinien był dotknąć, albo bez potrzeby odmówił.

Zamiana ręcznego progu na skalibrowane prawdopodobieństwo z modelu, który widzi cały kontekst pytania i pobranych fragmentów, a nie tylko jedną liczbę podobieństwa, to nie jest „ten sam koszt, szybciej" — to inny mechanizm decyzyjny, potencjalnie dokładniejszy niż próg, który nie wie nic poza odległością wektorów. To jedyny punkt w całym audycie, gdzie migracja na System One oznaczałaby dodanie warstwy wnioskowania tam, gdzie dziś jej nie ma, a nie zastąpienie jednego wywołania modelu innym.

Co zostaje przy LLM i dlaczego

Trzy punkty świadomie zostawiamy: ocena poprawności wygenerowanych testów i checklist w orkiestracji testów (pętle „valid? refine" w generatorze testów i generatorze checklist) oraz sprawdzenie poprawionej treści prawnej w bazie wiedzy. Wszystkie trzy mają formalnie zamknięty zbiór odpowiedzi — dwie albo trzy opcje — więc na pierwszy rzut oka pasują do Jeva tak samo jak dispatch w e-marketingu. Różnica jest w tym, co model musi ocenić, żeby do tej odpowiedzi dojść: nie stan systemu opisany polami i liczbami, tylko świeżo wygenerowaną, dowolną treść — kod testu, checklistę, akapit poprawionego tekstu prawnego. Ocena, czy taki tekst jest poprawny, semantycznie spójny i nie wprowadza nowego błędu, wymaga rozumowania nad treścią, a nie klasyfikacji znanego z góry stanu. To dokładnie granica, o której TypeSafe pisze wprost: Jev jest do decyzji nad stanem, nie do oceny wolnej treści.

Trzy powody, żeby na razie nie migrować nic

Nawet dla najsilniejszych kandydatów — dispatch w e-marketingu i coverage w bazie wiedzy — mamy trzy powody, żeby poczekać, a nie trzy powody, żeby zrezygnować.

Po pierwsze, 67,8% trafności na własnym czteroprzepływowym benchmarku TypeSafe to liczba z ich testów, nie z naszych danych, a przy siedmiokierunkowym routingu błędna decyzja oznacza uruchomienie złego specjalisty, nie tylko gorszą odpowiedź. Zanim cokolwiek przeniesiemy, potrzebujemy własnego zestawu testowego na naszych rzeczywistych wiadomościach, nie na cudzym benchmarku.

Po drugie, filtr danych osobowych działa fail-closed — to znaczy, że w razie wątpliwości ma zablokować, nie przepuścić. Bramka bezpieczeństwa tego typu potrzebuje deterministycznego, sprawdzalnego zachowania, a nie skalibrowanego prawdopodobieństwa, które z definicji czasem się myli. Nawet gdyby dziś ten filtr był oparty na LLM — czego diagram nie potwierdza — nie byłby to pierwszy kandydat do zamiany na model probabilistyczny.

Po trzecie, mamy w kalkulatorze kosztu flagę rezydencji danych w UE, a materiały premierowe Jeva nie wspominają nic o przetwarzaniu w europejskim regionie. Dla klienta z sektora finansowego czy prawnego to nie jest szczegół techniczny — to warunek wejścia do rozmowy.

Czego ten artykuł nie rozstrzyga

Uczciwie: ten audyt jest zrobiony na podstawie diagramów, które sami publikujemy na stronach produktowych, nie na podstawie odczytania kodu źródłowego każdego agenta. Diagram mówi, że węzeł istnieje i dokąd prowadzą jego gałęzie; nie zawsze mówi, czy dzisiejszą decyzję podejmuje model językowy, prosty warunek w kodzie, czy reguła regexowa. Tam gdzie węzeł idzie bezpośrednio po bloku opisanym jako wywołanie konkretnego modelu, założenie „to LLM" jest uzasadnione. Tam gdzie tak nie jest — jak przy wyborze agenta testowego — zaznaczyliśmy to wprost jako niepewne, zamiast zgadywać w jedną stronę, żeby tabela wyglądała ładniej.

Co robimy najpierw

Zanim ruszymy którykolwiek z kandydatów, dwie rzeczy trzeba zrobić w kolejności: rozszerzyć strukturę cen w naszym własnym kalkulatorze kosztu o model z darmowym wyjściem — dziś nie da się tego nawet policzyć — i zbudować mały zestaw testowy na rzeczywistych wiadomościach trafiających do dispatchera e-marketingu, żeby mieć własną liczbę trafności zamiast cudzego benchmarku. Dopiero po tych dwóch krokach ma sens pytanie „ile zaoszczędzimy", bo dziś odpowiedź uczciwie brzmi: nie wiemy, i to jest do sprawdzenia, a nie do zgadnięcia.

Podsumowanie

Jev trafia dokładnie w tę część naszego stosu, o której rzadko piszemy: nie generowanie tekstu, tylko ciche wybory między kilkoma znanymi z góry opcjami, które i tak dziś robi LLM, bo nie mieliśmy taniej alternatywy. Z dwunastu przeanalizowanych punktów decyzyjnych sześć to realni kandydaci, trzy zostają przy LLM, bo oceniają wolną treść, a trzy w ogóle nie są decyzją modelu albo nie powinny nią być. Najciekawszy wniosek nie dotyczy kosztu ani szybkości, tylko tego, że przynajmniej w jednym miejscu — progu pokrycia w RAG RAG (Retrieval-Augmented Generation) pozwala AI najpierw sprawdzić Twoje dokumenty, a dopiero potem odpowiedzieć — dzięki temu odpowiedzi opierają się na Twoich danych, a nie na domysłach. Pełna definicja → — migracja na System One oznaczałaby coś więcej niż wymianę silnika: dodanie wnioskowania tam, gdzie dziś jest tylko ręcznie dobrana liczba.