Zgłoszenie 151. typu wpada do jednej z 150 reguł i nie zgłasza błędu. Ten udział wybiera architekturę

Przepływ obsługuje 150 typów zgłoszeń i ma dla każdego osobną regułę. Zgłoszenie, które nie należy do żadnego z tych typów, nie wywołuje wyjątku: dopasowuje się do najbliższej reguły, przechodzi dalej i kończy jako sprawa obsłużona. W logu nie ma śladu, bo z punktu widzenia kodu nic się nie zepsuło – warunek był spełniony, akcja wykonana, status zamknięty.

Spór o to, czy dany przepływ ma dostać agenta czy zwykłą automatyzację, toczy się zwykle o trudność zadania. Rozstrzyga go inna liczba: udział ruchu, który wypada poza listę przypadków wypisanych przy projektowaniu. Tę liczbę da się zmierzyć przed napisaniem pierwszej linii kodu i to ona ustala, ile wolno obiecać – a najczęstszy błąd w doborze polega na tym, że pilotaż mierzy coś innego i nikt tego nie zauważa.

Trafność na liście nie przewiduje zachowania poza listą

Zbiór CLINC150 powstał pod dokładnie to pytanie. Praca An Evaluation Dataset for Intent Classification and Out-of-Scope Prediction (EMNLP-IJCNLP 2019, s. 1311-1316) opisuje 23 700 zapytań, z czego 22 500 należy do 150 intencji w dziesięciu domenach, a 1200 nie należy do żadnej z nich; dane leżą w repozytorium clinc/oos-eval. Na każdą intencję przypada 100 zapytań treningowych, 20 walidacyjnych i 30 testowych, co autorzy opisują jako budżet realny dla zespołu budującego taki system.

Istotne jest to, że wynik raportowano w dwóch osobnych kolumnach: trafność na 150 intencjach oraz czułość na zapytaniach spoza listy, czyli udział takich zapytań, które system rozpoznał jako nienależące do żadnej obsługiwanej sprawy. Te dwie kolumny ustawiają modele w innej kolejności.

Dwa wiersze z tej tabeli wystarczą, żeby zobaczyć problem: według tej samej pracy DialogFlow ma wyższą trafność na liście niż Rasa (91,7 wobec 91,5 proc.), a czułość poza listą niższą o ponad trzydzieści punktów (14,0 wobec 45,3 proc.). Gdyby wybór narzędzia opierał się na pierwszej kolumnie, wygrałoby to, które przepuszcza trzy czwarte spraw spoza zakresu dalej, w głąb przepływu, jako sprawy rozpoznane.

Najwyższa czułość poza listą w całym zestawieniu to 66,0 proc. – i wymagała zwiększenia liczby przykładów treningowych spoza listy ze 100 do 250. Przy trafności na liście rzędu 96 proc. to jest dystans, którego żadna pojedyncza metryka zbiorcza nie pokaże.

Dwie rzeczy trzeba przy tej tabeli powiedzieć wprost. Pierwsza: to pomiar z 2019 r., na klasyfikatorach sprzed obecnej generacji modeli, na danych angielskich zebranych crowdsourcingiem. Dzisiejszy model ustawi te liczby inaczej i nie ma sensu przenosić ich jako prognozy dla własnego przepływu. Przenosi się co innego – asymetria pomiaru: trafność na wypisanych przypadkach jest tania do zmierzenia i wysoka, a zachowanie na przypadkach niewypisanych jest drogie do zmierzenia i zawsze słabsze. Druga: zebranie samych danych spoza listy okazało się trudne. Autorzy podają, że tylko około 69 proc. zapytań zebranych z zadań celujących w przypadki spoza zakresu faktycznie okazało się takimi zapytaniami. Ogona nie da się więc wyprodukować przy biurku – trzeba go zaobserwować na własnym ruchu.

Policz udział spraw spoza listy na własnych danych

Pomiar, który rozstrzyga wybór układu, zajmuje kilka dni i nie wymaga żadnego modelu. Kolejność:

• Zamroź listę typów. Wypisz przypadki, które projektowana automatyzacja ma obsłużyć, i policz je. Lista musi być zamknięta na piśmie przed pomiarem, bo inaczej każdy nowy przypadek zostanie w trakcie dopisany i udział wyjdzie zero.
• Weź próbę losową z długiego okna. Pełny kwartał, próba losowana z całego ruchu. Nie zbiór z pilotażu: ten jest wybrany, zwykle przez kogoś, kto szukał przypadków reprezentatywnych, czyli z czoła rozkładu.
• Oznaczaj z opcją „żaden z powyższych”. Ta opcja musi być dostępna przy każdej sprawie i musi być wyborem równoprawnym, a nie polem na uwagi. Dwie osoby niezależnie, na tej samej próbie – rozbieżność między nimi to część wyniku, nie usterka procedury.
• Policz trzy liczby. Udział „żaden z powyższych” w próbie. Liczbę różnych typów potrzebnych do pokrycia 80 i 95 proc. wolumenu. Liczbę typów, które w oznaczanym oknie pojawiły się po raz pierwszy w ostatnim miesiącu – to tempo przyrostu ogona.
• Zapisz warunki pomiaru. Okno, liczebność próby, sposób losowania, kto oznaczał. Bez tego liczba za kwartał nie będzie porównywalna z tą samą liczbą policzoną dziś.

Czwarty punkt jest tym, który najczęściej wywraca wcześniejsze założenia. Wolumen i liczba typów rozchodzą się: przepływ może mieć stabilne 90 proc. ruchu w sześciu typach i jednocześnie dwadzieścia nowych typów na kwartał w pozostałych 10 proc. Reguły wyceniane od wolumenu wyglądają wtedy na wystarczające, a obsługiwać trzeba liczbę typów, nie liczbę spraw.

Przy przepływie całkiem nowym tej liczby po prostu nie ma i nie da się jej zgadnąć. Uczciwym wyjściem jest wtedy kilka tygodni pracy za człowiekiem, z oznaczaniem każdej sprawy wobec zamrożonej listy, i decyzja o architekturze po tym okresie – nie przed.

Zbuduj gałąź „nie wiem” przed resztą przepływu

Element, który decyduje o zachowaniu przepływu na ogonie, nie jest ani modelem, ani silnikiem reguł. Jest nim możliwość zwrócenia odpowiedzi „ta sprawa nie należy do żadnego obsługiwanego typu” i istnienie czegoś, co tę odpowiedź przyjmie.

Tablica decyzyjna bez gałęzi domyślnej takiej odpowiedzi nie potrafi wyrazić. Nie dlatego, że jest prosta, tylko dlatego, że jej wyjściem jest zawsze któraś z wypisanych akcji. Dlatego awaria na sprawie spoza listy jest w niej cicha: zamiast błędu dostajesz najbliższe dopasowanie ze statusem „obsłużono”. Model z progiem pewności taką odpowiedź wyrazić potrafi, ale tylko wtedy, gdy próg jest skalibrowany na danych z ogona – a tych, jak wyżej, jest mało i są drogie.

Praktyczna konsekwencja dla kolejności prac: gałąź „nie wiem” i kolejka, do której ona prowadzi, powstają pierwsze. Przepustowość tej kolejki jest twardym ograniczeniem całego przepływu – jeśli udział spraw spoza listy wynosi 12 proc., a kolejka obsługuje 4 proc., to pozostałe 8 proc. wróci do przepływu jako sprawy wymuszone na siłę w najbliższy typ, niezależnie od wybranej architektury.

Trzy układy przepływu i miejsce awarii każdego

Na tym samym przepływie – zgłoszenie wpada, trzeba je przypisać do typu i wykonać akcję – trzy układy wyglądają tak:

• Układ A, reguły deterministyczne. Wejście, walidacja schematu, tablica decyzyjna, akcja, log. Miejsce awarii: sprawa spoza tablicy, cicho dopasowana do najbliższej reguły. Co dostajesz za darmo: powtarzalność, odtworzenie przebiegu z samego wejścia, ponowienie bez skutków ubocznych.
• Układ B, model w jednym kroku klasyfikacji. Wejście, walidacja schematu, jedno wywołanie modelu zwracające typ albo „nieznany” wraz z pewnością, deterministyczna gałąź per typ, akcja, log z typem i pewnością. Miejsce awarii: kalibracja progu i przepustowość gałęzi „nieznany”.
• Układ C, pętla agenta. Model dobiera narzędzia w kolejnych krokach, aż uzna sprawę za zamkniętą. Miejsce awarii: przebieg nie jest odtwarzalny z samego wejścia, więc po incydencie potrzebny jest zapis każdej decyzji, a nie tylko wynik.

Zmierzony udział spraw spoza listy wskazuje układ w sposób dość mechaniczny. Udział niski i stabilny, przyrost nowych typów bliski zeru – układ A z gałęzią domyślną wystarcza, a model nie ma tu czego dodać. Udział wysoki albo rosnący, przy skończonym zestawie akcji na wyjściu – układ B, bo nierozpoznany jest wyłącznie typ sprawy, nie kolejność działań. Układ C zarabia na siebie dopiero wtedy, gdy nieznana jest także liczba i kolejność kroków, czyli gdy nie da się wypisać gałęzi – i to jest najwęższy z tych trzech przypadków, a nie domyślny.

Policz rachunek na 4000 sprawach miesięcznie

Rachunek poniżej stoi na jawnych założeniach, nie na pomiarze: 4000 spraw miesięcznie; w układzie B jedno wywołanie na sprawę z promptem 1200 tokenów, z czego 1000 to stała instrukcja z listą typów czytana z cache, 200 zmienne, i 80 tokenów wyjścia; w układzie C sześć wywołań na sprawę, w każdym 1000 tokenów z cache i 8000 świeżych wraz z rosnącą historią oraz 300 tokenów wyjścia. Ceny z oficjalnego cennika sprawdzonego 6 listopada 2026 r.: Haiku 5.5 przy promptach do 100 tys. tokenów 0,10 USD za milion tokenów wejścia i 0,50 USD wyjścia przy odczycie z cache 0,01 USD, Sonnet 5.5 odpowiednio 2 i 10 USD przy odczycie 0,10 USD, Opus 5.5 4 i 20 USD przy odczycie 0,20 USD.

Z tej tabeli wynika coś innego, niż się zwykle z niej wyciąga. Odstęp między układem B i C na tym samym modelu jest blisko dziewięćdziesięciokrotny, a bierze się nie z modelu, tylko z liczby wywołań i z historii dosyłanej w każdym z nich. Sam krok klasyfikacji jest tani do nieistotności: 0,28 USD miesięcznie nie jest pozycją, o której cokolwiek się rozstrzyga. Gdzie przepływ znosi opóźnienie, Batch API ścina oba kierunki o 50 proc., co przy tych kwotach też niczego nie zmienia.

Zero w pierwszym wierszu dotyczy wyłącznie kolumny tokenów. Układ A rzadko stoi na własnym kodzie – zwykle na silniku przepływów, który ma własną jednostkę rozliczeniową, a ta sama operacja bywa liczona jako cztery zadania, pięć kredytów albo jedno wykonanie, zależnie od dostawcy. Przy 4000 spraw miesięcznie to różnica rzędu wielokrotności, więc wiersz A wymaga przeliczenia na jednostce konkretnego silnika, a nie przyjęcia zera.

Pozycja, która rozstrzyga, jest poza tabelą. Przy udziale spraw spoza listy równym 12 proc. z 4000 spraw zostaje 480 spraw w kolejce do człowieka; po sześć minut na sprawę to 48 godzin miesięcznie. Jeżeli pilotaż oszacował ten udział na 4 proc., zaplanowano 16 godzin – i to ta różnica, nie rachunek za tokeny, wywraca wdrożenie w trzecim miesiącu. Dlatego liczbą, którą trzeba mieć przed wyborem architektury, jest udział, a nie cennik.

Sprawdź, czy metryki nie zalicza system nic nierobiący

Po wybraniu układu zostaje pytanie, czym mierzyć, że działa. Tu jest pułapka, którą widać na publicznym benchmarku. Berkeley Function Calling Leaderboard ma osobną kategorię na sprawy spoza zakresu: żadna z podanych funkcji nie jest właściwa, a oczekiwanym wyjściem jest brak wywołania funkcji – w wariancie pythonowym 240 przypadków testowych.

Databricks pokazał, co ta kategoria mierzy, gdy czyta się ją osobno: model, który nie potrafi wywołać funkcji w ogóle, uzyskałby w niej pozornie 100 proc. W ich pomiarze po zmianach w promptowaniu Llama3-8b dała 78,33 proc. wobec 75,41 proc. dla wariantu 70b, czyli model mniejszy wypadł lepiej od większego – i to nie dlatego, że lepiej rozumie zakres, a dlatego, że rzadziej wywołuje cokolwiek.

Przeniesienie na własny przepływ jest bezpośrednie: „nie podjął błędnej akcji” i „obsłużył sprawę” to dwie metryki i żadna z nich osobno nie wystarcza. Raport z wdrożenia musi podawać obie naraz – udział spraw spoza listy poprawnie odesłanych do człowieka oraz udział spraw z listy faktycznie domkniętych bez interwencji. Pojedyncza liczba zbiorcza przepuszcza układ, który nie robi nic i raportuje brak szkód.

Kolejność kroków przed wyborem układu

• Zamrożona na piśmie lista typów, które przepływ ma obsłużyć, z liczbą pozycji.
• Udział spraw spoza tej listy, policzony na losowej próbie z kwartału, z zapisanymi warunkami pomiaru.
• Liczba typów pokrywających 80 i 95 proc. wolumenu oraz liczba typów nowych w ostatnim miesiącu.
• Przepustowość kolejki ludzkiej, do której trafi gałąź „nie wiem”, w sprawach na dobę.
• Dwie metryki raportowe rozpisane osobno, zanim cokolwiek wejdzie na produkcję.
• Rachunek za tokeny – na końcu, bo przy jednym wywołaniu na sprawę nie wpływa na decyzję.

Pierwsze cztery pozycje tej listy powstają bez modelu i bez dostawcy. Jeśli któraś z nich jest nieznana, to decyzja między agentem a zwykłą automatyzacją nie jest jeszcze decyzją techniczną, tylko zakładem o rozkład ruchu. Zakład można postawić świadomie, pod warunkiem że ma się zapisane, na jakiej liczbie stoi i po czym będzie widać, że była zła – najtaniej po udziale spraw, które gałąź „nie wiem” odesłała w pierwszym miesiącu.