Jak robić routing i guardrails LLM? Przykład współpracy Jev z dużymi modelami językowymi

Ujawnienie interesów i dowodów: PandaNpc rozwija warstwę decyzyjną Agenta wykorzystującą Jev. Poniżej cytujemy oficjalną dokumentację TypeSafe, oficjalny cookbook oraz rzeczywiste wywołania Jev i kalibracje na scenariuszach syntetycznych z naszego repozytorium. Nasza kalibracja używa skryptowego fałszywego providera LLM i nie może reprezentować rzeczywistego ruchu użytkowników ani wydajności pełnego łańcucha produkcyjnego.

Routing LLM można zrobić tak: najpierw pozwól Jevowi ocenić, do jakiej kategorii należy żądanie i jak wysokie jest ryzyko, a następnie kod decyduje, czy przekazać je zwykłej funkcji, wyspecjalizowanemu LLM-owi, czy do przeglądu przez człowieka. Jev można też umieścić między wyszukiwaniem a generowaniem, aby filtrować dowody, albo po wyjściu LLM, aby sprawdzić wynik. Zwraca zamknięte opcje, oceny i prawdopodobieństwa; otwarte odpowiedzi, generowanie kodu i długie rozumowanie nadal wykonuje LLM. Objaśnienie TypeSafe dotyczące agentów kodujących wyraźnie wskazuje, że Jev nie może bezpośrednio zastąpić modelu czatowego stojącego za Claude Code lub Codex.

Ten artykuł na przykład żądania obsługi klienta, potoku pytań i odpowiedzi RAG oraz naszego własnego zapisu kalibracji Agenta wyjaśnia, gdzie dokładnie spotykają się dwa typy modeli i dlaczego wyniki o niskiej pewności muszą mieć jasno określone miejsce docelowe.

Co potrafi ocenić Jev, a za co nadal odpowiada LLM?

Na dzień 23 września 2026 r. na stronie modeli TypeSafe wymienionym stabilnym modelem jest jev-1.13.0. API przyjmuje state i zestaw questions, a przez POST /v1/systemone zwraca odpowiadające im ustrukturyzowane answers. jev-latest tego dnia wskazywał na 1.13.0, ale alias zmienia się wraz z wersjami; systemy, które skalibrowały progi, powinny przypiąć wersję i zapisywać rzeczywisty identyfikator modelu z odpowiedzi.

Noul nie ma osobnego pola confidence; nie można pojedynczego prawdopodobieństwa Noul zapisać bezpośrednio jako „pewności modelu”. Score również nie powinien służyć do obliczania dokładnych kwot. Kwoty, porównywanie dat, limity i sprawdzanie uprawnień powinny pozostać w deterministycznym programie; oficjalna dokumentacja wymienia te ograniczenia Jev 1.13.

Minimalny kształt jednego wywołania

Poniższy kształt żądania jest zgodny z oficjalną dokumentacją API; przykładowe pytania to ilustracyjna konfiguracja stworzona na potrzeby tego artykułu, dla której nie przeprowadzono tu testów online:

Poniższy JSON zawiera angielską wiadomość klienta; po polsku klient powiedziałby „Zamówienie zostało obciążone dwa razy, proszę o zwrot pieniędzy.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Rzeczywisty system powinien najpierw sprawdzić w kodzie, czy zapisy obciążenia dotyczą tego samego zamówienia i czy zwrot jest dozwolony. Powyższy przykład służy wyłącznie do odczytania intencji użytkownika; żądanie zwrotu przez użytkownika nie oznacza, że prawo do zwrotu zostało potwierdzone, a tym bardziej nie stanowi upoważnienia do bezpośredniego wykonania zwrotu.

RoutingM z użyciem Jev: trzy ścież przekazania

Oficjalny przykład rout intencji TypeSafe najpierw przekazuje żądania obsługi klienta do Jev, aby ocić intencję i złożoność, a następnie kod rozdziela je: sprawdzenie statusu zamówienia trafia do funkcji bazodan; pytania o produkty i zwroty/wiany trafiają do wyspecjalizowanych LLM-ów z różnymi materiałami; złożone reklamacje lub wyniki o niskiej pewności trafiają do kolejki dla człowieka. To właśnie najbardziej zrozumiała współpraca Jev z LLM: pierwszy daje ustrukturyzowaną ocenę, drugi pojawia się tylko wtedy, gdy trzeba wygenerować wyjaśnienie lub rozmowę.

Przy wdrażaniu można projektować według poniższej kolejności, zamiast pozwalać modelowi swobodnie decydować o wszystkich działaniach:

1. Najpierw zdefiniuj ścieżki: jasno wypisz żądania, które mogą obsłużyć zwykłe funkcje, wyspecjalizowane LLM-y i przegląd przez człowieka, oraz pozostaw dla Choice opcję other lub podobny fallback.
2. Umieść fakty w state: oryginalne słowa użytkownika, stan konta i zapisy zamówień powinny być osobnymi polami; nie traktuj tekstu ze stron internetowych o nieznanym pochodzeniu jako instrukcji systemowej.
3. Zadawaj wąskie pytania pojedynczo: intencję przez Choice, ryzyko lub pilność przez Score, pojedynczy fakt do potwierdzenia przez Noul. Oficjalna dokumentacja zaleca, aby wiele niezależnych pytań dotyczących tego samego state oceniać równolegle w jednym żądaniu.
4. To kod wykonuje ostateczny routing: najpierw sprawdź uprawnienia i twarde reguły, potem prawdopodobieństwa Jev i progi skalibrowane dla tego biznesu; żądania o niskiej pewności lub bez dowodów kieruj do człowieka albo do dodatkowego pytania.
5. Zapisuj wyniki i sprawdzaj je ponownie: przechowuj wersję modelu, wersję pytań, prawdopodobieństwa, ostateczny kierunek i wyniki korekt wprowadzonych przez człowieka, aby móc ocenić, czy progi są odpowiednie.

Źródło wykresu: TypeSafe AI „Introducing System One Models & Jev”, 2026-09-15. Cztery przepływy pracy zostały zbudowane przez TypeSafe, a wskaźniki zagregowano z równą wagą dla każdego przepływu; metodę ewaluacji opisano w Ewaluacje przepływów pracy TypeSafe.

Ten oficjalny wykres pomaga zrozumieć, dlaczego podkreśla się „włożenie wielu wąskich osądów do przepływu pracy programu”. Oś pionowa na wykresie zachowuje nazwę „accuracy” używaną przez dostawcę, lecz jej odpowiedzi referencyjne pochodzą z konsensusu prawopodobieństw przewidywanych przez dwa duże modele, a nie z jedynej poprawnej odpowiedzi zweryfikowanej przez człowieka; koszty i wskaźniki zależą też od tych czterech przepływów pracy i metody ewaluacji dostawcy, więc nie można ich przeliczać na „ile można zaoszczędzić w dowolnym scenariuszu”.

Generowanie wspomagane wyszukiwaniem: Jev filtruje dowody przed odpowiedzią LLM

Cookbook TypeSafe dotyczący fragmentów RAG podaje bardziej konkretny przykład wielu modeli: embedding OpenAI najpierw wyszukuje fragmenty, a Jev dla każdej pary „pytanie + fragment” zadaje cztery pytania Noul — czy fragment jest istotny, czy zawiera dowody możliwe do wykorzystania w odpowiedzi, czy zaprzecza założeniu w pytaniu, czy próbuje wydawać instrukcje modelowi odpowiadającemu. Kod przetwarza po kolei cztery prawdopodobieństwa i decyduje, czy umieścić fragment w obszarze dowodów, w obszarze dowodów sprzecznych, czy go odrzucić; na końcu Claude Sonnet 5 pisze odpowiedź.

Ten krok rozwiązuje częsty problem: fragmenty o wysokim podobieństwie wektorowym nie zawsze są użyteczne. Mogą zawierać tylko podobne słowa albo być postem z forum z wstrzykniętą instrukcją „zignoruj poprzedni tekst”. Przykład z cookbooka stawia sprawdzanie wstrzyknięć na początku reguł routingu, jednocześnie przypominając, że progi są punktem wyjścia wybranym dla tego korpusu, a nie wartościami domyślnymi dla wszystkich aplikacji RAG. Jego liczby demonstracyjne pochodzą z jev-1.12 z 2026-08-27 i nie można ich traktować jako nowych wyników ewaluacji dla obecnego jev-1.13.0.

Po wygenerowaniu można dodać jeszcze jedną warstwę weryfikacji. Cookbook TypeSafe do sprawdzania cytowań najpierw programowo znajduje oryginalny cytowany tekst, a następnie używa Jev do oceny, czy dany fragment wspiera, zaprzecza czy nie odnosi się do wygenerowanego twierdzenia. Potrafi wskazać cytowania warte ponownego sprawdzenia; sam osąd modelu nadal może być błędny, więc „przejście sprawdzenia” nie może być zapisywane jako gwarancja faktu.

Nasza kalibracja Agenta: gdzie może zablokować się eskalacja przy niskiej pewności?

W repozytorium PandaNpc klient Jev, zestaw pytań i orkiestrator wykorzystują Jev do rozpoznawania intencji Agenta, oceniania proponowanych zmian, sprawdzania warunków ukończenia i decyzji o zatwierdzeniu. Klient wykonuje też ograniczone ponowienia przy timeoutach, 429 i 5xx oraz ogranicza budżet żądań i nieaktualne wyniki; uprawnienia wykonawcze należą do orkiestratora i warstwy kontrolowanych narzędzi, a nie są przyznawane bezpośrednio przez pojedynczy osąd Jev.

W dniu 2026-09-22 użyliśmy jev-1.13.0 do 19 syntetycznych tur, każdą uruchamiając raz w trybie shadow i raz w trybie enforce, co daje łącznie 38 uruchomień i zapisane 165 rzeczywistych decyzji Jev. Ten wewnętrzny raport kalibracyjny i zachowane odpowiedzi z rzeczywistego urządzenia korzystają ze skryptowego fałszywego providera LLM, więc dane te pokazują jedynie działanie decyzyjne w kontrolowanym scenariuszu. Nie mogą dowodzić ogólnego wskaźnika sukcesu, proporcji oszczędności ani opóźnienia end-to-end w przypadku rzeczywistych żądań użytkowników.

Najcenniejszym odkryciem nie była średnia szybkość, lecz zator powodowany przez „pozornie bezpieczny” próg: w 19 turach trybu enforce 13 utknęło na Q2 „czy informacji wystarczy, aby rozpocząć modyfikację”, ponieważ prawdopodobieństwo Noul wpadło w pierwotny przedział niepewności 0,15–0,85 i nastąpiła eskalacja; LLM Worker nie miał szansy wykonać kolejnych kroków. Zapis kalibracji pokazuje, że spośród 34 decyzji Q2 oznaczonych jako wystarczająco poinformowane wiele prawdopodobieństw mieściło się w środkowym przedziale. Raport zaleca rozbicie złożonego Q2 na bardziej atomowe osądy albo dostosowanie reguł eskalacji; to zalecenia, a nie progi już wdrożone.

Nasz zestaw pytań klasyfikuje wejście jako answer_only, inspect, modify lub out_of_scope; na ścieżce zapisu proponowane przez Workera zmiany są najpierw sortowane przez Score, a końcowa treść i podsumowanie zmian przechodzą następnie akceptację i decyzję o zatwierdzeniu. To tylko punkty decyzyjne: to, czy można faktycznie czytać i zapisywać obiekty, nadal zależy od kontrolowanego executora, który przyznaje uprawnienia etapowo. Jev nie ma prawa samodzielnie rozszerzać białej listy narzędzi ani omijać kontroli spójności przed zatwierdzeniem.

Dane kalibracyjne ujawniły kolejny kompromis. W trybie shadow Jev podaje odpowiedź i pełny rozkład, ale nie zmienia pierwotnej ścieżki wykonania Workera; w trybie enforce odpowiedź wpływa na to, czy kontynuować, eskalować czy odrzucić. Traktowanie dokładności z shadow bezpośrednio jako wskaźnika ukończenia w enforce prowadzi do błędnego obrazu systemu: eskalacja na Q2 zatrzymuje zadanie wcześniej, przez co późniejsze pytania o ocenę kandydatów, akceptację i zatwierdzenie w ogóle się nie pojawiają. Dlatego ten raport czyta oddzielnie rozkład dla każdego pytania, kierunek eskalacji i stan końcowy.

Wśród proponowanych zmian było konkretne porównanie: w tej samej turze kandydat precyzyjnie modyfikujący cel otrzymał 2,94 punktu, a kandydat nadpisujący cały plik — 0,38 punktu; wybrano kandydata z wyższą punktacją. Ten przykład pokazuje tylko, że w tym syntetycznym scenariuszu pytanie oceniające rozróżniło dwa warianty. Odwrotnie, kandydat z obciętymi dowodami otrzymał 2,27 punktu i nie można ignorować jego niskiej pewności oraz znacznika obcięcia tylko dlatego, że liczba wygląda „nieźle”. Nasz kod osobno oznacza niekompletne dowody, aby model nie podejmował kategorycznej decyzji o zapisie wyłącznie na podstawie zachowanego prefiksu.

Rozdzieliliśmy też „wybór kandydata” i „zezwolenie na jego zapis” na dwa różne kroki. Gdy kandydat zostanie oceniony przez Jev, kontrolowany executor otwiera narzędzia zapisu tylko w fazie ACT/modify; wystawiony jednorazowy bilet wiąże identyfikator wywołania narzędzia, bieżący numer rewizji, hash obiektu docelowego i skrót parametrów. Nawet jeśli tekst kandydata nakłania model do „ignorowania ograniczeń”, nie uzyska on uprawnień narzędziowych pozwalających ominąć te kontrole. To nasza lekcja z integracji na poziomie kodu: osąd probabilistyczny decyduje, którą drogą warto iść, a uprawnienia do efektów ubocznych wynikają z możliwych do sprawdzenia warunków programu.

Ścieżki awaryjne również trzeba zaprojektować. Klient ponawia tylko w ograniczonym zakresie przy timeoutach, błędach sieci, 429 lub 5xx; odpowiedzi po anulowaniu lub po upływie terminu tury są odrzucane. Jeśli Jev w trybie enforce jest niedostępny, nie można kontynuować bez zgody na degradację; gdy zezwolono na llm_only, executor przechodzi w tryb tylko do odczytu. Jeśli gałąź zdążyła już dokonać modyfikacji, zanim utracono Jev, orkiestrator oznacza całą turę jako nieudaną, zamiast pozwalać późniejszemu LLM dokończyć zapis bez warstwy decyzyjnej. Te ścieżki kosztują doświadczenie użytkownika, ale sprawiają, że „model chwilowo niedostępny” nie zamienia się po cichu w „uprawnienia zapisu bez zmian”.

Raport kalibracyjny rozróżnia też „eskalację przy niskiej pewności” i „odmowę wykonania”. Na przykład poprawne discard, jeśli jego pewność nie osiągnęła jednolitego progu 0,85, zostanie zapisane jako wymagające danych od użytkownika; nie jest to równoznaczne z błędnym przepuszczeniem. Na tej podstawie raport zaleca rozdzielenie progów dla zatwierdzenia i odrzucenia, ale na razie to nadal zalecenie. Pisząc przepływ pracy, trzeba rozróżniać trzy wyniki: błędne przepuszczenie, błędną odmowę i oczekiwanie na przegląd, inaczej ten sam zbiór danych doprowadzi do błędnych wniosków o progach.

Ten przypadek pokazuje, że współpracy Jev z LLM nie można sprowadzać do schematu „najpierw Jev ocenia, potem LLM pracuje”. Przy każdym osądzie trzeba zapytać: jak szeroki jest przedział niepewności? Czy sprawi, że kolejny procesor nigdy nie otrzyma zadania? Jeśli dowody wejściowe są obcięte, czy można jednoznacznie eskaluować zamiast zgadywać? W naszej implementacji builder state zapisuje evidence_truncated i pozwala wywołującemu uznać ścieżkę bez dowodów za niepewną; deterministyczne obliczenia, takie jak zliczanie i sortowanie, są najpierw wykonywane w kodzie, a nie zostawiane Jevowi do zgadywania. Oficjalne znane ograniczenia Jev 1.13 również zalecają pozostawienie zliczania i arytmetyki w kodzie.

Gdzie powinny znajdować się guardrails LLM?

Cookbook TypeSafe dotyczący guardrails LLM umieszcza Jev po obu stronach wejścia i wyjścia LLM. Wykorzystuje zestaw pytań Noul do rozpoznawania różnych ryzyk, Score do mierzenia wagi, a kod na podstawie polityki decyduje o przepuszczeniu, ręcznej weryfikacji, zablokowaniu lub przekazaniu do wsparcia. Wyjście również trzeba sprawdzać, ponieważ zwykłe dane wejściowe nadal mogą prowadzić do nieodpowiednich wyników generowania.

Granice tego typu guardrails są równie jasne: Jev potrafi sprawdzać treść według wcześniej napisanych pytań, ale nie jest uniwersalnym dowodem bezpieczeństwa. Oficjalna dokumentacja ograniczeń wprost wspomina, że złośliwa treść może wpływać na osąd, i wymaga jasnego zapisania criteria oraz testowania granic. W naszych syntetycznych próbkach wykonaliśmy 16 prób wstrzyknięć wymierzonych w parametry kandydatów i zarejestrowaliśmy 0 odwróceń rankingu; próbka jest zbyt mała, aby wyciągać wniosek, że „odporność na prompt injection została rozwiązana”. O tym, co naprawdę mogą robić narzędzia, nadal decydują listy dozwolonych, bramki etapowe i kontrole przed zatwierdzeniem w kodzie.

Kiedy warto tego używać, a kiedy nie?

Jev nadaje się do sytuacji, gdy zbiór kandydatów jest znany, problem można rozbić na kilka krótkich osądów, a oprogramowanie potrzebuje prawdopodobieństw do decydowania o automatycznym przetwarzaniu lub eskalacji do człowieka. Na przykład routing obsługi klienta, filtrowanie fragmentów RAG, ocena kandydackich działań Agenta, weryfikacja cytowań w wygenerowanych wynikach. Jeśli zadanie wymaga napisania odpowiedzi, zmiany fragmentu kodu lub wyjaśnienia złożonego rozumowania, przejmuje je LLM. Jeśli zadanie polega na dokładnym liczeniu pieniędzy, porównywaniu dat lub sprawdzaniu kontroli dostępu, program powinien obliczać to bezpośrednio. Strona modeli wyjaśnia też, że Jev przyjmuje tylko tekst, a angielski jest obecnie najlepiej działającym językiem treningowym; scenariusze chińskojęzyczne wymagają ewaluacji na własnych danych i nie można kopiować progów z angielskiego cookbooka.

Jeśli chcesz zobaczyć, jak rzeczywisty Agent obsługuje uprawnienia i wywołania narzędzi, zacznij od PandaNpc Agent; o granicach i scenariuszach użycia agentów kodujących przeczytasz też w porównaniu Claude Code i Codex.

Czytelnik może zacząć od bardzo małego zbioru walidacyjnego: przygotuj cztery kategorie próbek — „wyraźnie nadaje się do automatycznego przetworzenia”, „wyraźnie należy odrzucić”, „niejednoznaczne semantycznie” i „zawiera złośliwe instrukcje”; najpierw ustal adnotacje ręczne, a potem zapisz prawdopodobieństwa Jev dla poszczególnych pytań i wyniki routingu. Kryterium sukcesu nie jest to, że każda pozycja przejdzie automatycznie, lecz to, że współczynnik błędów na ścieżce automatycznej i liczba eskalacji do człowieka mieszczą się w akceptowalnym przez ciebie zakresie. Jeśli wiele niejednoznacznych próbek blokuje się na tym samym pytaniu, najpierw sprawdź, czy pytanie nie łączy kilku osądów, czy state nie jest zbyt długi albo czy progi są skalibrowane na lokalnych danych.

FAQ

Czy Jev może zastąpić Claude Code, Codex lub model czatowy? Nie. TypeSafe pozycjonuje go jako model ustrukturyzowanych decyzji wewnątrz oprogramowania; czat, pisanie i generowanie kodu nadal wymagają LLM.

Czy stały typ zwracany oznacza, że nie popełni błędu? Nie. Stały typ ogranicza problemy z parsowaniem i wyjściem poza zakres, ale klasyfikacja, ocena i osądy faktyczne nadal mogą być błędne. Ścieżki o niskiej pewności i wysokim ryzyku powinny zachować ręczną weryfikację.

Ile pytań można zadać w jednym żądaniu? Można umieścić w jednym żądaniu wiele niezależnych pytań Choice, Score i Noul współdzielących ten sam state. Pytania są oceniane osobno, a złożone osądy nadal należy rozbijać i składać w kodzie.

Czy można używać chińskiego? Oficjalnie deklarowane jest wsparcie dla języków naturalnych, w tym pisma chińskiego, japońskiego i koreańskiego, ale obecnie najlepsza jest dokładność dla angielskiego. Obciążenia chińskojęzyczne wymagają osobnej walidacji i kalibracji.