Routing polega na kierowaniu zadania do właściwej ścieżki: reguły, mniejszego modelu, mocniejszego modelu albo człowieka. Brzmi jak oszczędność. W praktyce bywa tak, że firma buduje drugą sieć modeli do wyboru pierwszego modelu i płaci więcej za wybór niż za odpowiedź. Router też musi udowodnić swoją wartość.
Dobry routing jest nudny, mierzalny i ma ścieżkę awaryjną. Nie zaczyna się od listy wszystkich modeli. Zaczyna się od pytań: które zadania są deterministyczne, gdzie potrzebny jest język, kiedy błąd jest tani, a kiedy proces powinien się zatrzymać.
Najpierw rozdziel zadania według ryzyka
Zapisz typowe przypadki w trzech grupach. Pierwsza to operacje deterministyczne: formatowanie daty, obliczenie sumy, sprawdzenie wymaganego pola, walidacja adresu. Druga to zadania językowe o ograniczonym skutku: porządkowanie notatki, ekstrakcja pól, krótkie podsumowanie. Trzecia obejmuje trudny kontekst, konflikt źródeł i wysoki koszt błędu.
Nie kieruj wszystkiego do modelu. Jeżeli wynik można policzyć regułą, reguła jest tańsza i bardziej przewidywalna. Model może opisać wynik, ale nie powinien wykonywać arytmetyki dla raportu. Router ma rozpoznawać tę granicę przed pierwszym wywołaniem AI.
Dodaj ryzyko jako osobną oś. To samo podsumowanie prywatnej notatki i publicznego komunikatu prawnego różni się skutkiem. Nie wybieraj ścieżki tylko po długości dokumentu. Temat, odbiorca i możliwość odwrócenia decyzji mają znaczenie.
Zdefiniuj wynik przed wyborem ścieżki
Dla każdego zadania zapisz oczekiwany format, źródło, dopuszczalny błąd i czas odpowiedzi. „Dobrze i tanio” nie jest kryterium. Przykład: odpowiedź zawiera trzy pola, korzysta tylko ze wskazanego dokumentu, nie zgaduje przy braku i wraca w ciągu pięciu sekund.
Dodaj próg jakości i kosztu. Może to być zero błędów krytycznych, format zgodny w określonym odsetku przypadków, ograniczony czas redakcji i budżet na zadanie. Nie kopiuj progów z cudzego projektu. Mała firma potrzebuje miernika dopasowanego do rzeczywistej decyzji.
Przygotuj zestaw testowy przed pierwszym routerem. Typowe przypadki, trudne, brzegowe i bezpieczeństwo. Jeżeli nie umiesz ocenić odpowiedzi, nie wiesz, czy routing działa. Oficjalne materiały OpenAI podkreślają mierzalne KPI, logowanie kosztu i opóźnienia oraz testy przed wdrożeniem.
Reguły są pierwszą ścieżką, nie zacofaniem
Router może sprawdzić typ pliku, obecność pól, długość, język, źródło i ryzyko bez modelu. To zwykły kod. Zasady powinny być jawne, wersjonowane i łatwe do zmiany. Nie ukrywaj ich w kolejnym prompcie, którego nikt nie testuje.
Przykład: dokument jest pusty — stop; brakuje źródła — eskalacja; zawiera tylko tabelę znanego formatu — reguła; wymaga krótkiego streszczenia — mały model; ma konflikt wersji — nie zgaduj. Ta lista jest mniej efektowna niż autonomiczny orkiestrator, ale o wiele łatwiej ją odebrać.
Zapisz powód przypisania. Log powinien mówić „ścieżka B, bo typ zadania to podsumowanie i źródło jest zatwierdzone”, a nie tylko nazwę modelu. Bez powodu nie poprawisz błędnych wyborów i nie porównasz kosztu.
Mały model dostaje zwykłą pracę
Mniejszy model wybierz dla dobrze opisanych zadań, które przechodzi w testach. Może przygotować ekstrakcję, wstępne podsumowanie albo klasyfikację. Nie zakładaj, że jest zawsze szybszy lub tańszy po doliczeniu poprawek. Zmierz cały wynik.
Test porównuj z mocniejszą opcją na tych samych przypadkach. Zapisz błędy krytyczne, format, czas odpowiedzi i czas człowieka. Jeśli mały model wymaga dwóch ponowień, jego niższa cena może być iluzją. Jeśli działa dobrze, nie dodawaj mocniejszego tylko dla prestiżu.
Przy polskich dokumentach sprawdź odmianę, negację, daty i format tabeli. Ogólny benchmark nie pokaże twoich plików. Praktyczny wybór modelu rozwijamy w artykule o kryteriach i evaluacjach modeli AI.
Mocniejszy model potrzebuje powodu
Eskaluj na mocniejszą ścieżkę, kiedy przypadek zawiera złożony kontekst, wiele powiązanych źródeł albo trudniejszy wniosek i test pokazuje realną poprawę. Nie wysyłaj tam wszystkiego po jednym błędzie użytkownika. Zapisz klasę przypadku, nie jego wyjątkowość w narracji.
Nie każda trudna odpowiedź wymaga dużego modelu. Jeżeli źródło jest nieaktualne, lepszy model tylko szybciej zgadnie. Najpierw sprawdź dane. Jeżeli dwie ścieżki dają złe wyniki, zatrzymaj proces i popraw przygotowanie zadania.
Dodaj limit. Mocniejsza ścieżka powinna mieć ograniczony koszt, czas i liczbę prób. Jeżeli nie przechodzi odbioru, przechodzi do człowieka z kontekstem. Nie uruchamiaj nieskończonej pętli „sprawdź jeszcze raz innym modelem”, bo to drogi sposób na unikanie decyzji.
Człowiek jest ścieżką, nie błędem routera
Niektóre zadania powinny trafić do człowieka od początku: decyzja o człowieku, poufny konflikt, nietypowa reklamacja, publikacja zobowiązania. Router ma je rozpoznawać i przygotowywać pakiet kontekstu. To nie jest porażka automatyzacji.
Pakiet zawiera źródło, wykryty problem, podjęte próby i oczekiwany typ decyzji. Nie wysyłaj samego zdania „model nie wiedział”. Człowiek powinien zobaczyć, co wymaga osądu, bez przepisywania całego procesu.
Zapisz wynik interwencji. On pomaga ocenić, czy reguły są właściwe, ale nie zamieniaj jednej decyzji w nową automatyczną regułę. Zbierz więcej przypadków i oceń ryzyko zmiany.
Awaria ścieżki musi mieć plan
Co się stanie, kiedy mały model jest niedostępny? Możesz zatrzymać zadanie, użyć innej sprawdzonej ścieżki albo przekazać je człowiekowi. Nie przełączaj automatycznie na droższy model bez limitu i nie wysyłaj danych do nowego dostawcy bez oceny.
Rozróżnij błąd odpowiedzi od błędu narzędzia. Timeout, limit, niepoprawny format i niska jakość wymagają innej reakcji. Ponowienie powinno mieć ograniczoną liczbę prób i backoff. Po przekroczeniu limitu zadanie zatrzymuje się w bezpiecznym stanie.
Testuj awarię przed wdrożeniem. Wyłącz jedną ścieżkę w środowisku testowym, przekrocz limit i zasymuluj błędny wynik. Router ma zapisać powód i uniknąć podwójnej operacji. Jeżeli wykonuje zapis, ponowienie musi być idempotentne albo poprzedzone sprawdzeniem stanu.
Mierz routing jako cały proces
Zapisuj liczbę zadań na ścieżkę, jakość, koszt, opóźnienie, poprawki i eskalacje. Dodaj koszt samego routera. Jeżeli wybór ścieżki wymaga modelu, jego zużycie również należy do procesu. Nie porównuj samej ceny odpowiedzi końcowej.
Sprawdzaj, czy ścieżki nie dryfują. Zmiana typów dokumentów albo oferty może sprawić, że dotychczasowe reguły przypisują zadania źle. Ustaw mały przegląd przypadków i powtarzaj testy zależne po zmianie modelu lub reguł.
Wynikiem może być decyzja o usunięciu routera. Jeżeli dziewięćdziesiąt procent zadań i tak trafia do jednej ścieżki, prostszy proces jest lepszy. Anthropic zaleca zaczynanie od prostych konstrukcji i zwiększanie złożoności dopiero przy mierzalnym efekcie.
Przykład routera dla trzech wiadomości
Pierwsza wiadomość zawiera prośbę o poprawienie formatu daty. Reguła wykonuje zmianę i zwraca wynik bez modelu. Druga prosi o krótkie podsumowanie zatwierdzonej oferty. Mały model przygotowuje tekst z linkiem do źródła. Trzecia zawiera dwie sprzeczne wersje ceny i żądanie natychmiastowej wysyłki.
Trzeci przypadek nie powinien zostać wysłany do mocniejszego modelu tylko dlatego, że jest trudny. System pokazuje konflikt i przekazuje go właścicielowi. Wysyłka pozostaje zablokowana. Router rozwiązuje problem przez ograniczenie skutku, nie przez większą liczbę tokenów.
W logach widać trzy różne powody: reguła, podsumowanie, konflikt. Raport nie porównuje tylko kosztu odpowiedzi, ale także liczbę zatrzymań i czas interwencji. To pozwala poprawiać proces zamiast oceniać go wyłącznie po automatyzowanym wolumenie.
Czy router potrzebuje modelu do wyboru modelu?
Nie na początku. Reguły wystarczą dla jasnych typów zadań i są łatwiejsze do testowania. Modelowy klasyfikator dodaj dopiero, gdy typy są rzeczywiście niejednoznaczne i reguły generują zbyt wiele błędów.
Zmierz jakość klasyfikacji na oznaczonych przypadkach. Zły wybór modelu może kosztować więcej niż stała prosta ścieżka. Dodaj także koszt i opóźnienie klasyfikatora. Jeżeli sam wybór wymaga mocnego modelu, proces staje się trudny do obrony ekonomicznej.
Klasyfikator nie powinien zmieniać uprawnień. Może zaproponować ścieżkę, ale aplikacja sprawdza ją przy regułach bezpieczeństwa. Niezależnie od oceny „niskie ryzyko” wysyłka i publikacja wymagają właściwej bramki.
Dokumentacja jednej reguły
Zapisz warunek, źródło, ścieżkę, limit, oczekiwany wynik i zachowanie przy błędzie. Dodaj przykład pozytywny i negatywny. Właściciel widzi datę zmiany oraz testy wymagane przy kolejnej wersji.
Przykład: jeżeli typ to podsumowanie i źródło jest zatwierdzone, wybierz mały model. Jeżeli dokument zawiera konflikt wersji, zatrzymaj. Nie przypisuj dwóch reguł temu samemu przypadkowi bez jawnej kolejności. Kolejność też należy do dokumentacji.
Po zmianie reguły uruchom powiązane przypadki i kilka kontrolnych z innych ścieżek. Zmiana jednego warunku może przechwycić zadania, których nie planowano. Test powinien pokazać rzeczywiste przypisanie, a nie tylko poprawność składni.
Kryteria zakończenia routera
Przed wdrożeniem zapisz, kiedy uproszczenie lub wyłączenie jest lepsze: zbyt duży koszt wyboru, zbyt wiele błędnych przypisań, brak poprawy jakości albo jedna dominująca ścieżka. Nie każdy router musi zostać rozbudowany.
Mierz odsetek eskalacji i błędów przypisania, nie tylko koszt. Jeżeli zespół częściej poprawia wybór niż odpowiedź, router tworzy nową pracę. Może wystarczy jedna stała ścieżka z bramką bezpieczeństwa.
Po ograniczeniu zachowaj logi i powód. Nowe typy zadań mogą uzasadnić powrót, ale powinny zostać dodane dopiero po teście. Proces ma być odwracalny i prosty do wyjaśnienia następnemu właścicielowi. Zmiana modelu lub źródła uruchamia ponowny przegląd reguł, a nie automatyczny wzrost złożoności. Każda decyzja powinna mieć właściciela i datę odbioru.
Minimalna architektura na dwa tygodnie
Tydzień pierwszy: wybierz dwa typy zadań i przygotuj trzydzieści przypadków. Porównaj regułę, mały i mocniejszy model. Zapisz jakość, koszt i czas odbioru. Nie buduj automatycznego wyboru przed uzyskaniem tych wyników.
Tydzień drugi: dodaj pięć reguł i jedną eskalację. Testuj awarię, brak źródła i konflikt wersji. Udokumentuj powody wyboru i limit. Dopiero po stabilnym wyniku zwiększ liczbę zadań, nie liczbę modeli.
Przy większej mapie narzędzi pomocne są kryteria pilotażu Aeneia Signal oraz Aeneia Audit, jeżeli routing ma objąć kilka procesów i właścicieli. Zacznij od dowodów, nie od diagramu z dziesięcioma logo.
Najlepszy routing nie wybiera najmądrzejszego modelu na każde pytanie. Wybiera najprostszy proces, który przechodzi test i zatrzymuje się przy właściwej granicy. Reguła, mały model, duży model i człowiek mogą współpracować. Nie muszą wszyscy pracować naraz.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
