Agent AI, który w jednym zadaniu kilkanaście razy pyta duży model językowy „po które narzędzie teraz sięgnąć?”, za każde z tych pytań płaci czasem i pieniędzmi, choć odpowiedź za każdym razem mieści się w jednym słowie. Model decyzyjny to model, który nie pisze tekstu, tylko wybiera jedną z wcześniej przygotowanych opcji i zwraca ją w ustalonym formacie razem z prawdopodobieństwem. Moim zdaniem takich wyborów jest w agentach najwięcej, a zwykle obsługuje je narzędzie stworzone do pisania. Pokażę ci, czym model decyzyjny różni się od modelu językowego, jaki wzorzec łączy projekty tak różne jak kompresja pamięci agenta i gra w Super Mario, i jak wypatrzyć decyzję tego rodzaju we własnym procesie. Na koniec powiem, kiedy lepiej zostać przy LLM albo przy zwykłym kodzie.
Czym model decyzyjny różni się od modelu językowego
LLM, czyli duży model językowy (na takich modelach działają ChatGPT czy Claude), generuje tekst słowo po słowie. Nawet gdy prosisz go o samo „tak” albo „nie”, dostajesz tekst, który program musi potem przeczytać i zinterpretować. Czasem zamiast „tak” przychodzi „Tak, ponieważ…” i ktoś musi to przewidzieć w kodzie.
Model decyzyjny dostaje opis sytuacji i listę dopuszczalnych odpowiedzi, a oddaje wynik typowany: wartość z tej listy, liczbę albo prawdę lub fałsz, plus informację, jak bardzo jest pewny. „Typowany” znaczy tyle, że program z góry wie, jakiego kształtu odpowiedź przyjdzie, i może na niej od razu działać. Zamiast akapitu dostajesz coś w rodzaju: ruch = „skok”, pewność = 0,82.
Przykładem, na którym opieram ten tekst, jest Jev firmy TypeSafe AI. To model, który w ogóle nie generuje języka. Producent deklaruje, że w zadaniach polegających na ustrukturyzowanym wyborze dorównuje czołowym LLM, a działa przy tym wielokrotnie szybciej i taniej. Tych deklaracji tu nie weryfikuję. Ciekawsze od nich jest to, co programiści na tym modelu zbudowali, bo ich projekty układają się w jeden powtarzalny wzorzec.
Jeden wzorzec: kod liczy, model wybiera, LLM pisze
Kiedy przejrzysz projekty zbudowane na modelu decyzyjnym, zobaczysz w nich ten sam podział pracy. Kod liczy, model decyzyjny wybiera, a LLM pisze tylko wtedy, gdy naprawdę trzeba napisać tekst.
- Kod robi wszystko, co da się policzyć dokładnie: fizykę, geometrię, czas, reguły, limity bezpieczeństwa. Przygotowuje też zamkniętą listę dozwolonych ruchów i dopisuje do każdego fakty potrzebne do wyboru.
- Model decyzyjny wybiera jedną opcję z tej listy i podaje prawdopodobieństwo dla każdej z nich.
- LLM wchodzi tylko tam, gdzie wynikiem ma być nowy tekst: nazwa miasta w polu wyszukiwania, odpowiedź dla klienta, opis.
Najczytelniej widać to w JevBall, symulacji meczu piłkarskiego w 3D, w której wszystkimi 22 zawodnikami steruje Jev. Symulacja najpierw sama wylicza realne opcje każdego gracza: podanie, strzał, drybling, pressing, krycie. Do każdej dokleja dane: odległość, czy linia podania jest wolna, ile miejsca ma odbiorca, szacowaną szansę powodzenia, xG (oczekiwane gole, czyli statystyczną wartość strzału) i margines spalonego. Dopiero taki zestaw, do 14 opcji na zawodnika, trafia do modelu, który wybiera i zwraca prawdopodobieństwo każdej. Fizyka, przyjęcie piłki, parady bramkarza i inne odruchy zostają w kodzie.
Zwróć uwagę, co z tego wynika. Model nie wymyśli ruchu, którego nie ma na liście, bo lista jest zamknięta. Nie musi też liczyć trajektorii, bo dostał wynik obliczeń. Robi tylko to, w czym jest dobry, czyli waży kilka przygotowanych możliwości.
Routing: wybór narzędzia, umiejętności i komendy
Routing to kierowanie: decyzja, dokąd ma trafić zapytanie albo po które narzędzie agent ma sięgnąć. To najbardziej oczywisty kandydat na model decyzyjny, bo zbiór odpowiedzi jest znany z góry. Cloudflare udostępnił Jev na swojej platformie AI właśnie do takich zadań: kierowania zapytań, wyboru narzędzi i innych rozstrzygnięć, które leżą na ścieżce krytycznej aplikacji, czyli tam, gdzie wszystko inne czeka na odpowiedź. Argument jest prosty. Agent robi w jednym zadaniu wiele wywołań modelu, więc opóźnienia się sumują.
Drugi powód to kontekst, czyli wszystko, co model ma przed oczami w danej chwili: polecenie, historia rozmowy, wczytane pliki i opisy narzędzi. Każdy zbędny fragment kosztuje i rozprasza. Jev Capability Resolver rozwiązuje problem, który zna każdy, kto podłączył agentowi kilka usług naraz. Zamiast kazać agentowi czytać wszystkie opisy umiejętności i dokumentację API, żeby znalazł jedną komendę, układa udokumentowane operacje w drzewo: dostawca, zasób, konkretna komenda. Model schodzi po tym drzewie poziom po poziomie, na każdym wybierając najlepszą gałąź, a agent dostaje na końcu tylko dokumentację wybranej operacji. Złożone polecenie da się rozbić na kilka zadań i przeszukiwać równolegle. W benchmarku samego projektu (20 scenariuszy) średni kontekst agenta spadł o 85% przy modelu Opus 5 i o 23% przy GPT-5.6-Sol. Ta rozpiętość uczy więcej niż którakolwiek z tych liczb: zysk zależy od modelu, z którym łączysz routing, więc sprawdzaj go na własnym zestawie zadań, a nie na cudzym wykresie.
Podobny pomysł ktoś zastosował w nakładce na Claude Code. Samo Claude Code może pokazywać modelowi listę wszystkich dostępnych umiejętności (skills), także tych, które do bieżącej prośby nic nie wnoszą. Nakładka ukrywa tę listę i wysyła nazwy oraz opisy umiejętności do modelu Jev. Jev najpierw rozstrzyga, czy prośba w ogóle wymaga którejś umiejętności, potem układa kandydatów w ranking i jeszcze raz sprawdza najlepszych. Do kontekstu głównego modelu trafia tylko plik SKILL.md wybranej umiejętności, a pozostałe są dostępne, ale niewczytane. Główny model zajmuje się zadaniem, zamiast ustalać, które instrukcje przeczytać.
Zatrzymaj się przy tym pierwszym kroku. Odpowiedź „żadna” też jest na liście. Dobrze zaprojektowany zbiór opcji zawsze ma wyjście, które mówi „tu nie ma czego wybierać”.
Pamięć agenta: wybierać zamiast streszczać
Długa sesja z agentem programistycznym w końcu przestaje się mieścić w kontekście. Typowe wyjście to kompakcja: LLM przepisuje starszą część rozmowy w streszczenie. Kłopot w tym, że streszczenie jest nowym tekstem, a w nowym tekście giną szczegóły: dokładna ścieżka pliku, treść komendy, komunikat błędu, ograniczenie ustalone godzinę wcześniej.
fast-jev-compaction, wtyczka do Claude Code i biblioteka npm, zamienia tę operację z pisania na wybieranie. Wysyła stan rozmowy do modelu Jev, który ocenia każde wywołanie narzędzia i jego wynik pod kątem tego, czy są jeszcze potrzebne. Niepotrzebne znikają, potrzebne zostają słowo w słowo. Mniej ważne wyniki można przyciąć, zachowując samo wywołanie. Wiadomości użytkownika i asystenta zostają w oryginalnej formie i kolejności.
Uważam to za najciekawszy przykład z całego zestawu, bo zamiana zmienia tu charakter wyniku. Selekcja nie przekręci ścieżki pliku, bo jej nie przepisuje. Może najwyżej wyrzucić coś, co jeszcze było potrzebne, i to jest ryzyko, które trzeba sprawdzić, zanim jej zaufasz.
Ocena, kontrola bezpieczeństwa i porządkowanie danych
Trzy kolejne zastosowania łączy jedno: model patrzy na cudzą pracę i wydaje werdykt z krótkiej listy.
Ewaluacja to sprawdzanie, czy agent dobrze wykonał zadanie. Popularny sposób to LLM w roli sędziego: dajesz modelowi zapis pracy agenta i prosisz o ocenę. Badacze z LangChain sprawdzili, czy model decyzyjny zrobi to szybciej i stabilniej. Wzięli agenta pogodowego i pięć stałych zadań, a potem wielokrotnie oceniali te same przebiegi modelem Jev i trzema LLM. Punktem odniesienia były oceny ludzi. Jev zgodził się z ludzkim werdyktem „zaliczone / niezaliczone” we wszystkich 500 powtórzonych decyzjach, a jego oceny wahały się znacznie mniej niż oceny pozostałych modeli.
Badacze sami jednak zastrzegają, że eksperyment był wąski i że spójność nie gwarantuje trafności. To zastrzeżenie warto zapamiętać bardziej niż wynik. Sędzia, który zawsze mówi to samo, może się zawsze mylić. Stabilność mówi ci tylko, że ocena się nie chwieje. To, czy jest słuszna, sprawdzisz wyłącznie na przykładach ocenionych przez ludzi.
Vercel używa modelu Jev jako strażnika w fx, swoim agencie programistycznym. W trybie automatycznym każda komenda, którą agent chce uruchomić, przechodzi przed wykonaniem kontrolę: bezpieczna czy nie. To decyzja z zamkniętej listy, a nie zadanie pisarskie. Leży przy tym dokładnie na ścieżce krytycznej, bo każda komenda czeka na werdykt. W wewnętrznym teście Vercela Jev był od kilku do kilkunastu razy szybszy od dotychczasowego recenzenta opartego na LLM (mierzone na p95, czyli czasie, w którym mieści się 95 na 100 odpowiedzi) i trafniej klasyfikował polecenia.
Trzeci przykład to porządkowanie danych hurtem. Kolekcja DAIR.AI liczyła około 2300 prac naukowych o AI, otagowanych wcześniej przez inny model, ale tym etykietom nie ufano na tyle, żeby użyć ich bez sprawdzenia. Zamiast budować droższy klasyfikator na LLM, całą kolekcję przepuszczono przez Jev. Model zgodził się z około 75% dotychczasowych etykiet i wskazał około 579 zmian tematów, co do których był bardzo pewny. Człowiek przejrzał ręcznie 30 przypadków niezgodności, zaakceptował wszystkie i dopiero wtedy zmiany trafiły do kolekcji produkcyjnej. Cały przebieg miał kosztować 14 centów.
Dwie rzeczy są tu warte skopiowania. Pierwsza to układ hybrydowy: model generatywny odpowiada za szerszą obróbkę, a model decyzyjny za szybką klasyfikację na dużą skalę. Druga to ręczna próbka przed wdrożeniem. Trzydzieści przypadków nie dowodzi poprawności 579 zmian, ale to jest ten ruch, który oddziela porządkowanie danych od zgadywania.
Sterowanie w czasie rzeczywistym
Najbardziej widowiskowe są projekty, w których model decyzyjny steruje czymś, co się rusza. Tu szybkość przestaje być sprawą kosztów i staje się warunkiem działania.
Jev Ultrafast od Browser Use to agent, który obsługuje przeglądarkę. Zamiast robić zrzuty ekranu i prosić LLM o każdy kolejny ruch, zamienia bieżącą stronę w ponumerowaną tabelę widocznych elementów. Jev w jednym zapytaniu wybiera zarówno operację (kliknij, wpisz, wybierz, przewiń, czekaj, zakończ), jak i jej cel. Mniejszy LLM włącza się tylko wtedy, gdy trzeba wpisać tekst, na przykład nazwę miasta w wyszukiwarce lotów. W sześciu przebiegach testowych projektu liczba wywołań protokołu przeglądarki spadła z 1092 do 101.
TypeSafe Mario gra w oryginalne Super Mario Bros. i nie patrzy przy tym na ekran. Czyta telemetrię oraz pamięć emulatora i zamienia je na uporządkowany opis: pozycja i prędkość Mario, tor skoku, pobliscy wrogowie, teren, czas reakcji, ostatnie ruchy. Jev wybiera jeden z kilku dozwolonych ruchów kontrolera (w prawo, bieg, skok albo nic), emulator przesuwa grę o kilka klatek i pętla rusza od nowa. Każde zapytanie zwraca przy okazji odpowiedź tak/nie na pytanie, czy skok do przodu ma sens, i ocenę bezpośredniego zagrożenia. Precyzyjne rachunki czasu zostają w kodzie.
Jev Autopilot to symulator drona zbudowany w Three.js. Model leci od lądowiska startowego A do lądowiska B przez losowo generowane miasto. Dostaje zwięzły raport z symulatora (wysokość, prędkość, kurs, przeszkody w pobliżu, najwyższy budynek na trasie) i w jednym zapytaniu podejmuje sześć decyzji: gaz, odchylenie, pochylenie i przechylenie, a do tego czy podchodzić do lądowania i czy wyłączyć silniki. Symulator zamienia prawdopodobieństwa na ruchy drążków, a kod pilnuje obliczeń lotu i podstawowych limitów bezpieczeństwa.
JevBall dokłada do tego jeszcze jeden pomysł: nie wszyscy gracze decydują równie często. Zawodnik przy piłce decyduje co 0,3 sekundy, gracze w promieniu 15 metrów od piłki co 0,55 sekundy, reszta co 1,2 sekundy. Decyzje przypadające na tę samą chwilę idą jednym zbiorczym zapytaniem. Częstotliwość decyzji też jest parametrem projektu.
We wszystkich tych przypadkach model nie dostaje obrazu, tylko dane, które kod już wyciągnął i policzył. To lekcja przydatna także komuś, kto nigdy nie zbuduje drona: zanim oddasz decyzję modelowi, zamień sytuację w fakty i liczby.
Jak znaleźć decyzję we własnym procesie
Nie musisz sterować dronem, żeby z tego skorzystać. W zwykłym procesie firmowym decyzje przebrane za zadania dla LLM łatwo przeoczyć. Szukaj kroków, które spełniają trzy warunki naraz.
- Ograniczony zbiór odpowiedzi: umiesz spisać wszystkie dopuszczalne wyniki, zanim krok się wykona.
- Ścieżka krytyczna: coś czeka na tę odpowiedź, na przykład klient, następny krok agenta albo człowiek przy ekranie.
- Powtarzalność: krok wraca wiele razy, na przykład przy każdym zgłoszeniu albo każdej komendzie agenta.
Pasują tu na przykład przypisanie wiadomości z formularza do działu, ocena, czy zgłoszenie jest pilne, decyzja, czy dokument wymaga akceptacji kierownika, albo wybór szablonu odpowiedzi. Jeśli dziś robi to LLM, często robi dwie rzeczy naraz: decyduje i pisze. Rozdziel je. Najpierw wybór z listy, potem, jeśli trzeba, tekst.
Do każdej takiej decyzji dołóż dwie rzeczy. Pierwsza to próg pewności: poniżej ustalonej wartości wynik nie wykonuje się automatycznie. Druga to wyjście awaryjne, czyli opcja „nie wiem / do człowieka” na liście oraz konkretna osoba albo kolejka, która takie przypadki odbiera. Zanim zaufasz modelowi, sprawdź go na własnym zestawie przykładów ocenionych przez ludzi.
Kiedy nie sięgać po model decyzyjny
- Gdy wynikiem ma być tekst: odpowiedź dla klienta, streszczenie spotkania, szkic oferty. To robota dla LLM.
- Gdy nie umiesz spisać opcji z góry, bo zbiór odpowiedzi jest otwarty.
- Gdy wystarczy reguła. Jeśli „faktura powyżej progu idzie do akceptacji” da się zapisać jednym warunkiem, napisz warunek. Kod jest tu tańszy i przewidywalny.
- Gdy decyzja zapada rzadko. Zysk na szybkości i koszcie jest wtedy niewielki, a każdy dodatkowy model to kolejna rzecz do utrzymania.
- Gdy błąd jest nieodwracalny, a nikt nie sprawdza przypadków wątpliwych. Model zwróci pewność, ale pewność nie jest gwarancją.
- Gdy nie masz na czym tego sprawdzić. Jeśli żadnych przypadków nie ocenili ludzie, wiesz tylko, że model wybiera szybko, a nie że wybiera dobrze.
Zasada na koniec
Zasada, którą wynoszę z tych projektów: zanim wyślesz kolejne pytanie do dużego modelu językowego, sprawdź, czy odpowiedź naprawdę musi być tekstem. Jeśli wystarczy wybór z listy, niech kod tę listę przygotuje, model decyzyjny wybierze, a LLM zostanie tam, gdzie trzeba pisać. Na początek weź jeden proces, który już prowadzi agent albo asystent AI, wypisz jego kroki i przy każdym zaznacz: liczenie, wybór czy pisanie. Często już taka lista pokazuje, gdzie model językowy robi pracę, do której nie był potrzebny.