Sporo produkcyjnego ruchu LLM sprowadza się do jednego słowa. Eskalować to zgłoszenie czy nie. Spam czy nie spam. Który z sześciu handlerów ma obsłużyć zdarzenie. Żeby dostać to jedno słowo, wysyłasz cały prompt do ogólnoprzeznaczeniowego modelu, czekasz, aż zdekoduje odpowiedź token po tokenie, i wyciągasz obiekt JSON z wyniku. Płacisz cenę i opóźnienie generowania tekstu, a to, co dostajesz, to decyzja mieszcząca się w enumie.
“Model system one” to nazwa, jaką TypeSafe AI nadało modelowi zbudowanemu pod ten drugi kształt: bierze fragment stanu plus zestaw typowanych pytań i zwraca odpowiedź na każde z nich w jednym przebiegu, bez generowania tekstu. Termin pożycza podział Daniela Kahnemana na szybkie, automatyczne myślenie “System 1” i powolne, świadome rozumowanie “System 2”. Jev, implementacja TypeSafe, jest tu przykładem roboczym. Nazwa należy do dostawcy, ale sam pomysł jest starszy: jeśli output ogranicza się do znanego zbioru odpowiedzi, model może jedną z nich wybrać zamiast napisać. Pytanie dla twojego systemu brzmi, czy ten kształt pasuje do prawdziwego wąskiego gardła.
Dlaczego model system one może pominąć dekodowanie token po tokenie
Generatywny LLM produkuje output, którego jeszcze nie widział. Każdy token zależy od wszystkich poprzednich, więc model przewiduje jeden, dokleja go do inputu i przewiduje kolejny. Ta zależność jest powodem, dla którego generowanie jest wolne. Token 40 nie może się zacząć, dopóki nie istnieje token 39.
Model tego typu usuwa tę zależność, ustalając przestrzeń odpowiedzi przed wywołaniem. Nie prosisz go o napisanie odpowiedzi. Dla każdego pytania dajesz mu menu (wybierz jedną z tych etykiet, umieść to na skali 1-10, odpowiedz tak albo nie), a on ocenia każdą opcję na każdym menu w jednym równoległym przebiegu w przód. Nie ma sekwencji do dekodowania, bo każda możliwa odpowiedź jest znana z góry.
To cały trik i to jednocześnie granica jego możliwości. Ustalenie outputu jest tym, co pozwala pominąć autoregresję, a wszystko poza ustalonym outputem po prostu znika: nie dostajesz swobodnego tekstu ani wypisanego rozumowania do wglądu. Dokumentacja Jev wprost mówi, że model radzi sobie słabo z arytmetyką, liczeniem i porównywaniem dat, bo te wymagają obliczeń wieloetapowych, a nie wyboru między opcjami. Jeśli zadanie wymaga, żeby model coś wyprodukował, a nie wybrał, sięgnij po inne narzędzie.
Co wysyłasz do modelu system one i co dostajesz z powrotem
Każde wywołanie ma dwie części. Stan to wszystko, na co model ma patrzeć: e-mail, zgłoszenie supportowe, klatka gry, wiersz danych aplikacji. Pytania są typowane i ograniczone, w trzech rodzajach opisanych wyżej. Dla każdego pytania dostajesz z powrotem wybraną odpowiedź plus rozkład prawdopodobieństwa nad alternatywami.
Buduj wokół tego rozkładu. “Eskaluj” przy 0.52 i “eskaluj” przy 0.98 mają tę samą etykietę, a znaczą coś zupełnie innego. Na drugą możesz zareagować automatycznie. Pierwsza należy do wolniejszej, ostrożniejszej ścieżki — albo człowieka, albo pełnego wywołania LLM.
Podobny sygnał możesz dostać z modelu generatywnego, czytając log-prawdopodobieństwa tokenów ograniczonej odpowiedzi, jeśli dostawca je udostępnia. Różnica jest taka, że model system one zwraca ten rozkład jako samą odpowiedź, dla każdego pytania, bez dodatkowej instalacji.
Kiedy użyć modelu system one w pipeline LLM
Wzorzec, który działa, to bramkowanie, nie zastępowanie. Szybki, typowany model decyduje, czy drogie wywołanie generatywne w ogóle musi się wydarzyć.
- Routing. Klasyfikuj żądanie, zanim wybierzesz, który model albo handler je obsłuży, zamiast prosić jeden ogólny model, żeby jednocześnie klasyfikował i odpowiadał w tym samym wywołaniu. Pipeline RAG może użyć tej samej bramki, żeby zdecydować, czy pytanie w ogóle wymaga retrievalu.
- Moderacja i triage. Oceniaj treść pod kątem spamu albo pilności, zanim dotrze do człowieka albo droższego modelu, żeby drogą ścieżkę puszczać tylko na to, co jej naprawdę potrzebuje.
- Guardraile. Po wygenerowaniu sprawdź odpowiedź pod kątem typowanych ograniczeń (czy zawiera konkretny wzorzec danych, czy wpada w zabronioną kategorię) jako osobny, tani przebieg, zamiast wtapiać tę kontrolę w prompt generujący.
- Pętle kontroli w czasie rzeczywistym. Pętla gry albo kontroler robota, który potrzebuje decyzji co klatkę, nie może czekać na generowanie. Model jednoprzebiegowy mieści się w takiej pętli. Model token-po-tokenie strukturalnie się do tego nie nadaje.
Rzeczy się psują, gdy traktujesz odpowiedź szybkiego modelu jako pewnik. Odpowiedzi o niskiej pewności wysyłaj na wolniejszą ścieżkę, a próg ustawiaj na podstawie własnych oznaczonych danych, nie okrągłej liczby, która “brzmi dobrze”. Płaski rozkład z etykietą na wierzchu to nadal zgadywanie.
Alternatywy: structured output i dostrojone klasyfikatory
Zespoły rozwiązywały ten problem, zanim kategoria dostała nazwę, na dwa główne sposoby.
Structured output na ogólnym LLM. Główne API LLM potrafią ograniczyć generowanie do schematu JSON albo enuma, co daje tę samą gwarancję typowanej odpowiedzi bez przechodzenia na nowy rodzaj modelu. Dekodowanie jest nadal autoregresywne, ale gdy odpowiedzią jest jedna wartość enuma, wygenerowana część to zaledwie garstka tokenów. Większość opóźnienia i kosztu idzie w przetwarzanie prompta, a model system one też musi to zrobić. TypeSafe pozycjonuje Jev jako szybsze i tańsze od tego podejścia. Ile z tego trzyma się dla twoich wywołań, zależy od długości prompta i liczby pytań na wywołanie, więc to liczba do zmierzenia, nie do założenia. Structured output nie wymaga też żadnej nowej infrastruktury, jeśli już wywołujesz tego dostawcę.
Mały dostrojony klasyfikator. Dla jednej stabilnej decyzji, jak dokładnie ta eskalacja albo dokładnie ten filtr spamu, klasyfikator wytrenowany na własnych oznaczonych danych jest zwykle szybszy i tańszy niż jakikolwiek ogólny model, typowany czy nie. Kosztem jest to, że potrzebujesz oznaczonych danych i przetrenowania za każdym razem, gdy zadanie się zmieni. Przewaga modelu system one nad nim to zasięg: jeden model odpowiada na wiele różnych typowanych pytań o różne rodzaje stanu, bez treningu na każdą decyzję z osobna.
Właściwy wybór zależy od tego, ile masz odrębnych decyzji i ile ruchu dostają. Jeśli masz jedną stabilną decyzję o dużym wolumenie, użyj dedykowanego klasyfikatora. Jeśli masz kilka powiązanych, ale zróżnicowanych decyzji w pipeline, to jest dokładnie przypadek, pod który zaprojektowano kształt system one. Jeśli nie robisz tysięcy takich wywołań na minutę, zacznij od structured output na modelu, którego już używasz.
Jak znaleźć wywołania LLM, które powinny być decyzjami
Przejrzyj, co już wysyłasz do ogólnego LLM, i zaznacz każde wywołanie, którego
cały użyteczny output mógłby być wartością enuma albo liczbą. To twoi
kandydaci. Przenieś dwa z nich na structured output na modelu, którego już
używasz, albo hostowanym API, albo lokalnym modelu
działającym pod Ollama,
które przyjmuje schemat JSON w parametrze format. Zmierz opóźnienie i
koszt na wywołanie względem obecnej wersji.
Cokolwiek podmienisz, nadal wysyłaj kilka procent bramkowanego ruchu przez starą ścieżkę i porównuj odpowiedzi. Jeśli structured output już mieści się w twoim budżecie opóźnienia i zgadza się ze starą ścieżką, zatrzymaj się tutaj. Dedykowany model system one, jak Jev, oceniaj tylko wtedy, gdy nie mieści się, i użyj do tego tej samej próbki porównawczej.