LLM Router w praktyce: dynamiczny wybór modelu po koszcie, ryzyku i typie pytania

1. Czym jest LLM Router i kiedy ma sens (koszt, latencja, jakość, ryzyko)

LLM Router to warstwa decyzyjna w aplikacji korzystającej z modeli językowych, której zadaniem jest dynamiczny wybór tego, jakiego modelu (lub trybu wywołania) użyć dla konkretnego zapytania. Zamiast kierować wszystkie prośby do jednego, „domyślnego” modelu, router dobiera rozwiązanie adekwatne do kontekstu: od prostych zadań, które można obsłużyć taniej i szybciej, po złożone przypadki wymagające wyższej jakości lub większej ostrożności.

W praktyce router jest odpowiedzią na to, że modele różnią się między sobą w czterech podstawowych wymiarach: koszcie, latencji, jakości oraz ryzyku (np. wrażliwość danych, zgodność, podatność na halucynacje). LLM Router porządkuje te kompromisy i pozwala je egzekwować w sposób spójny.

Koszt: płacenie tylko za to, czego potrzebujesz

Najczęstszy powód wdrożenia routingu to ekonomia. Wiele interakcji użytkowników nie wymaga „najmocniejszego” modelu: krótkie odpowiedzi informacyjne, parafrazy, ekstrakcja oczywistych danych czy proste klasyfikacje mogą być realizowane przez tańsze modele. Router pozwala:

• obniżyć średni koszt pojedynczego zapytania, utrzymując wysoką jakość tam, gdzie jest to faktycznie potrzebne,
• stabilizować wydatki przy rosnącym ruchu, ograniczając przypadki nieuzasadnionego użycia drogich modeli,
• unikać przepalania budżetu na zadania o niskiej wartości lub małym ryzyku biznesowym.

Router ma sens szczególnie wtedy, gdy masz duży wolumen zapytań i wyraźnie mieszany profil: część jest prosta, część trudna, a wymagania kosztowe są twarde.

Latencja: krótszy czas odpowiedzi jako cecha produktu

Drugi wymiar to czas. Użytkownicy i procesy automatyczne reagują na opóźnienia: w czatach i asystentach liczy się płynność, w automatyzacji — przepustowość. Wybór modelu wpływa na latencję poprzez szybkość generacji i obciążenie infrastruktury. Router pomaga:

• utrzymać responsywność w zadaniach, gdzie liczy się szybkość,
• kierować obciążenie do modeli/trybów, które są wystarczające i dostępne,
• zmniejszać „ogon” latencji (rzadkie, ale bardzo wolne odpowiedzi) poprzez świadomy dobór prostszych rozwiązań w mniej krytycznych przypadkach.

Routing ma sens, gdy latencja jest elementem SLA, a nie tylko „miłym dodatkiem”.

Jakość: dopasowanie kompetencji modelu do trudności zadania

Modele różnią się zdolnością rozumowania, odpornością na niejednoznaczności, radzeniem sobie z długim kontekstem czy precyzją w domenach specjalistycznych. Router pozwala dobierać jakość adekwatnie do stawki:

• dla pytań prostych — model szybszy i tańszy,
• dla pytań złożonych lub krytycznych — model o wyższej jakości,
• dla zadań wymagających ścisłości — preferowanie opcji o mniejszej skłonności do konfabulacji.

Największą korzyścią jest tu podniesienie średniej jakości produktu bez konieczności „windowania” wszystkich zapytań na najwyższy poziom kosztu.

Ryzyko: bezpieczeństwo, zgodność i kontrola błędów

Nie każde zapytanie niesie takie samo ryzyko. Część może dotyczyć danych wrażliwych, decyzji o skutkach finansowych, treści regulowanych lub obszarów, gdzie błąd jest szczególnie kosztowny. Router bywa traktowany jako mechanizm zarządzania ryzykiem, ponieważ umożliwia:

• rozróżnienie zapytań niskiego i wysokiego ryzyka,
• kierowanie delikatniejszych przypadków do bardziej kontrolowanych ustawień lub modeli o lepszej przewidywalności,
• ograniczanie ekspozycji na halucynacje i błędy w sytuacjach krytycznych.

Routing jest szczególnie uzasadniony, gdy aplikacja działa w środowisku wymagającym zgodności, audytu, ochrony danych lub gdy odpowiedzi modelu mają bezpośredni wpływ na użytkownika, klienta czy proces biznesowy.

Kiedy LLM Router nie ma sensu

Nie zawsze warto go budować. Routing może być przerostem formy, gdy:

• masz mały wolumen zapytań i koszt nie jest problemem,
• większość zapytań ma jednorodny profil (podobna trudność i wymagania),
• produkt wymaga maksymalnie spójnego stylu i zachowania, a różnice między modelami są trudne do zamaskowania,
• nie masz jeszcze podstawowego procesu oceny jakości i błędów, więc nie wiesz, co tak naprawdę optymalizujesz.

LLM Router jest najcenniejszy w momencie, gdy aplikacja dojrzewa: rośnie ruch, rosną koszty, pojawiają się wymagania dotyczące niezawodności i bezpieczeństwa, a jedna „domyślna” konfiguracja przestaje być najlepszym kompromisem dla wszystkich przypadków.

2. Wymiary decyzji routingu: typ pytania, wymagania jakości, wrażliwość danych, tolerancja ryzyka

Router LLM podejmuje decyzję, który model wywołać (albo czy wykonać kilka kroków), na podstawie zestawu sygnałów opisujących zapytanie i kontekst użycia. Najczęściej te sygnały można ująć w cztery wymiary: typ pytania, wymagania jakości, wrażliwość danych oraz tolerancja ryzyka. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. Dobrze zdefiniowane wymiary upraszczają polityki routingu i ograniczają przypadkowe decyzje, które później trudno wyjaśnić i monitorować.

Typ pytania (intencja i charakter zadania)

Różne klasy zadań mają różną „trudność” oraz różne profile porażek. W praktyce router powinien rozpoznawać, czy zapytanie jest np. kreatywne, analityczne, proceduralne, czy dotyczy pracy na danych użytkownika. Od tego zależy, czy lepszy będzie model szybki i tani, czy bardziej „rozumujący”, albo wyspecjalizowany w danej dziedzinie.

• FAQ i proste informacje – krótkie odpowiedzi, streszczenia, parafrazy; często wystarcza model tańszy.
• Instrukcje i zadania krok-po-kroku – ważna spójność, kompletność i odporność na niejednoznaczności.
• Analiza, rozumowanie, planowanie – większe ryzyko błędów logicznych; zwykle uzasadnia użycie modelu wyższej jakości.
• Tworzenie treści – priorytetem bywa styl i dopasowanie do tonu, a nie „jedna poprawna odpowiedź”.
• Kod i zadania techniczne – liczy się poprawność syntaktyczna, zgodność z ograniczeniami i minimalizacja halucynacji.
• Wyszukiwanie/odpowiedzi oparte o źródła – zapytania, gdzie kluczowe jest trzymanie się materiałów referencyjnych, a nie „wiedzy ogólnej”.

Istotny jest też kontekst: czy użytkownik kontynuuje rozmowę, czy to jednorazowe pytanie, oraz czy odpowiedź ma trafić do człowieka, czy do dalszego przetwarzania automatycznego (gdzie tolerancja na niejednoznaczność jest mniejsza).

Wymagania jakości (dokładność, kompletność, format, deterministyczność)

„Jakość” nie jest jednolita. Dla jednych zastosowań najważniejsza jest rzeczowość, dla innych styl, a dla jeszcze innych zgodność z formatem. Router powinien mieć możliwość rozróżnienia oczekiwań jakościowych, bo to one determinują, czy opłaca się sięgać po droższy model lub ostrzejsze ustawienia generacji.

• Dokładność merytoryczna – krytyczna w zastosowaniach decyzyjnych, finansowych, prawnych czy medycznych; niższa w luźnej konwersacji.
• Kompletność odpowiedzi – czasem wystarczy „wskazówka”, a czasem wymagany jest pełny plan, checklista lub uzasadnienie.
• Zgodność z formatem – odpowiedzi do automatycznego parsowania (np. JSON, lista pól) wymagają większej dyscypliny.
• Spójność i powtarzalność – gdy wynik ma być stabilny między uruchomieniami, ważna jest deterministyczność i kontrola wariancji.
• Język i styl – w komunikacji z klientem istotne jest dopasowanie tonu, terminologii i długości.

Wymagania jakościowe warto formułować w sposób mierzalny (np. „odpowiedź musi zawierać wszystkie pola”, „nie może zawierać spekulacji”), bo wtedy routing jest łatwiejszy do uzasadnienia i utrzymania.

Wrażliwość danych (prywatność, zgodność, granice przetwarzania)

Router powinien uwzględniać, jakie dane znajdują się w zapytaniu i kontekście: dane osobowe, informacje poufne, tajemnice przedsiębiorstwa, dane klienta, logi systemowe, a także treści objęte regulacjami. Ten wymiar często przesądza o wyborze dostawcy, regionu przetwarzania, a nawet o tym, czy w ogóle wolno użyć modelu zewnętrznego.

• Dane osobowe i identyfikatory – wymagają ostrożności w przesyłaniu i logowaniu; czasem konieczna jest anonimizacja lub redakcja.
• Dane poufne biznesowo – np. ceny, plany, niepubliczne dokumenty; ryzyko wycieku może przewyższać oszczędność kosztu.
• Treści regulowane – mogą wymagać szczególnych warunków przetwarzania i audytowalności.
• Zakres kontekstu – im więcej danych z systemów wewnętrznych trafia do promptu, tym większa waga kontroli dostępu i minimalizacji danych.

Wrażliwość danych wpływa nie tylko na dobór modelu, ale też na decyzje typu: czy skracać kontekst, czy usuwać identyfikatory, czy ograniczać narzędzia i pamięć konwersacji.

Tolerancja ryzyka (konsekwencje błędu i wymagany poziom kontroli)

Ten wymiar odpowiada na pytanie: co się stanie, jeśli model się pomyli. Dla wielu systemów to ważniejsze niż sama średnia jakość. Router powinien rozróżniać scenariusze, gdzie błąd jest „irytujący”, od tych, gdzie jest kosztowny lub niebezpieczny.

• Ryzyko halucynacji – gdy odpowiedź może brzmieć wiarygodnie, ale być fałszywa; krytyczne w doradztwie i raportowaniu faktów.
• Ryzyko szkodliwych zaleceń – gdy model może zasugerować działania niosące realne szkody.
• Ryzyko reputacyjne – ton, uprzedzenia, nieodpowiednie treści; istotne w kanałach publicznych i obsłudze klienta.
• Ryzyko operacyjne – gdy wynik steruje systemem (np. automatyzacje); błędny format lub intencja może wywołać niepożądane akcje.
• Wymagana weryfikowalność – czasem potrzebne są odwołania do źródeł, jasne założenia lub ograniczenie odpowiedzi do pewnych stwierdzeń.

Tolerancja ryzyka bywa też zależna od użytkownika i kontekstu: inna dla środowiska testowego, inna dla produkcji; inna dla użytkownika wewnętrznego, inna dla klienta zewnętrznego.

Jak te wymiary współgrają w decyzji

W praktyce routing jest kompromisem: to samo zapytanie może być „proste” (typ), ale dotyczyć danych wrażliwych (wrażliwość) i trafiać do procesu automatycznego (tolerancja ryzyka), co zmienia wybór modelu. Dlatego warto myśleć o wymiarach jako o zestawie ograniczeń i priorytetów: najpierw to, co niepodlegające negocjacji (np. prywatność), potem to, co definiuje oczekiwany wynik (jakość), a na końcu optymalizacja kosztu i czasu w ramach tych ram.

3. Strategie routingu: klasyfikator zapytań (reguły vs model), heurystyki i routing wieloetapowy

Strategia routingu odpowiada na pytanie: jak zdecydować, do którego modelu (lub narzędzia) wysłać dane zapytanie. W praktyce najczęściej spotkasz trzy podejścia: (1) klasyfikację opartą o reguły, (2) klasyfikację opartą o model, (3) podejścia hybrydowe z heurystykami oraz routingiem wieloetapowym. Różnią się kosztami utrzymania, odpornością na zmiany w danych oraz tym, jak dobrze radzą sobie z niejednoznacznymi przypadkami.

3.1. Klasyfikator zapytań: reguły vs model

Klasyfikator zapytań mapuje wejście (treść, metadane, kontekst) na decyzję routingu (np. „model tani”, „model premium”, „wymaga narzędzi”, „odmów/anonimizuj”). Kluczowa różnica: reguły są przewidywalne i tanie w uruchomieniu, a modele są elastyczne i lepiej radzą sobie z niuansami językowymi.

Reguły zwykle bazują na sygnałach takich jak: długość promptu, obecność słów-kluczy (np. „umowa”, „diagnoza”, „kod”), identyfikacja formatu (SQL, JSON, kod), kanał wejścia, rola użytkownika czy tagi produktu. Klasyfikator modelowy może wykorzystywać te same sygnały, ale potrafi też rozpoznać intencję bez ręcznego opisywania wszystkich wariantów.

3.2. Heurystyki jako warstwa pośrednia

Heurystyki to proste reguły „biznesowo-inżynierskie”, które nie muszą rozstrzygać całej decyzji, ale potrafią ją ukierunkować lub ograniczyć przestrzeń wyboru. Są szczególnie użyteczne, gdy chcesz szybko osiągnąć rozsądne wyniki bez budowania pełnego klasyfikatora.

• Heurystyki kosztowe: np. jeśli kontekst > X tokenów, wybierz model z tańszym kontekstem lub wymuś streszczenie przed właściwym wywołaniem.
• Heurystyki złożoności: np. zadania wieloetapowe (plan + wykonanie) kieruj do modelu lepszego w rozumowaniu, krótkie FAQ do tańszego.
• Heurystyki formatów: np. wykrycie kodu/SQL/regex sugeruje model „coding”, a wykrycie tabel i liczb — model lepszy w analizie.
• Heurystyki ryzyka: np. wykrycie danych wrażliwych uruchamia „bezpieczną ścieżkę” (np. maskowanie, ograniczenie narzędzi, inny model).
• Heurystyki jakości: np. jeśli użytkownik zaznaczy „wysoka jakość”, od razu kieruj do mocniejszego modelu, niezależnie od treści.

W praktyce heurystyki często pełnią rolę filtrów (co jest dozwolone) oraz przełączników (co jest preferowane), zanim dojdzie do dokładniejszej klasyfikacji.

3.3. Routing wieloetapowy (multi-stage)

Routing wieloetapowy rozbija decyzję na kilka kroków, dzięki czemu większość zapytań obsłużysz tanio i szybko, a tylko trudne przypadki „eskalują” do droższych modeli lub dodatkowych etapów. Taki układ zmniejsza koszty średnie i poprawia kontrolę ryzyka, bo krytyczne decyzje mogą przechodzić przez osobne „bramki”.

• Etap 0: szybka walidacja — odrzucenie oczywistych nadużyć, zbyt długich wejść, niepoprawnych formatów.
• Etap 1: tani triage — proste reguły lub lekki model oceniają typ zadania i wstępny poziom trudności.
• Etap 2: właściwe wykonanie — wybór docelowego modelu (np. „tani”, „średni”, „premium”) lub trybu (np. z narzędziami / bez).
• Etap 3: eskalacja — jeśli wynik jest niepewny (np. niska pewność klasyfikacji, konflikty sygnałów), przekierowanie do mocniejszego modelu.
• Etap 4: weryfikacja — opcjonalne sprawdzenie odpowiedzi (np. zgodność z formatem, prosta kontrola faktów), które może skutkować ponownym wyborem ścieżki.

Kluczowym elementem routingu wieloetapowego są progi i warunki eskalacji (np. „jeśli niepewność >= …”, „jeśli wykryto wrażliwą treść”, „jeśli użytkownik wymaga cytowań”). Dzięki nim router nie musi być „idealny” — wystarczy, że jest dobry w kierowaniu typowych przypadków i rozpoznawaniu sytuacji, gdy potrzebna jest lepsza ścieżka.

3.4. Wzorzec hybrydowy: reguły + model + eskalacja

Najczęstszy układ produkcyjny to hybryda: reguły jako twarde ograniczenia (co wolno), klasyfikator modelowy jako miękka decyzja (co najlepsze), oraz routing wieloetapowy do kontroli kosztu i ryzyka. Taki podział pozwala zachować przewidywalność tam, gdzie jest wymagana, i elastyczność tam, gdzie język naturalny wymyka się prostym regułom.

// Szkic: hybrydowy routing (pseudokod)
if (violatesHardPolicy(input)) return route("deny_or_safe_path");

signals = extractSignals(input);        // długość, format, słowa-klucze, metadane
ruleHint = applyRules(signals);         // np. "coding" | "faq" | "sensitive"
mlDecision = classifyWithModel(input);  // {route, confidence}

route = merge(ruleHint, mlDecision);
if (mlDecision.confidence < THRESHOLD || signals.highRisk) {
  route = escalate(route);              // np. mocniejszy model lub dodatkowy etap
}
return route;

Taki schemat nie przesądza jeszcze, jak liczysz budżety, limity czy fallbacki — ale pokazuje, jak budować decyzję z warstw: od najtańszych i najbardziej deterministycznych do najbardziej elastycznych i „drogich” tylko wtedy, gdy to uzasadnione.

4. Kontrola kosztu: budżet tokenów, limity per użytkownik/tenant, dobór modeli i parametrów

Kontrola kosztu w systemie z LLM Routerem polega na tym, by przewidywalnie ograniczać wydatki bez niepotrzebnego obniżania jakości. W praktyce sprowadza się to do trzech dźwigni: (1) budżetowania tokenów, (2) limitów (rate limits / quotas) na poziomie użytkownika lub tenant’a, oraz (3) doboru modelu i parametrów tak, by płacić za jakość tylko wtedy, gdy jest potrzebna. W Cognity omawiamy to zagadnienie zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

Budżet tokenów: liczenie, prognozowanie i egzekwowanie

Najbardziej bezpośrednim sterownikiem kosztu jest liczba tokenów. Budżetowanie warto prowadzić na kilku poziomach:

• Per request: maksymalna liczba tokenów wejściowych i wyjściowych dla pojedynczego zapytania.
• Per sesja/konwersacja: limit łącznych tokenów w wątku, aby długie rozmowy nie eskalowały kosztów.
• Per okres (dzień/tydzień/miesiąc): budżet globalny dla organizacji lub produktu.

Żeby budżet był skuteczny, router powinien wykonywać szybkie kroki przed wywołaniem modelu:

• Estymacja kosztu: oszacowanie tokenów promptu (w tym kontekstu, instrukcji systemowych, historii rozmowy, narzędzi) i planowanej odpowiedzi.
• Decyzja: jeśli estymacja przekracza budżet — skrócenie kontekstu, zmiana modelu na tańszy, ograniczenie max output, albo odmowa/komunikat o limicie.
• Egzekucja limitów: twarde limity (hard cap) dla max output tokens i długości kontekstu, aby koszt był deterministyczny.

Limity per użytkownik/tenant: ochrona przed „spike” i nadużyciami

Poza budżetem tokenów kluczowe są limity użycia, które stabilizują koszt i chronią system:

• Rate limit: np. liczba żądań na minutę. Chroni przed nagłym wzrostem ruchu i kosztów.
• Quota: np. miesięczny limit tokenów / żądań. Daje przewidywalność kosztową w rozliczeniach.
• Concurrency limit: limit równoległych zapytań na użytkownika/tenant. Zapobiega „zatykaniu” droższych modeli.

Praktyczna zasada: quota kontroluje koszt w horyzoncie rozliczeniowym, a rate/concurrency ogranicza ryzyko kosztowego „wybuchu” w krótkim czasie.

Dobór modeli i parametrów: płacenie za jakość tylko gdy trzeba

LLM Router może obniżać koszt, kierując zapytania do różnych modeli lub trybów pracy. Najczęściej kontrola odbywa się przez:

• Tiering modeli: tańszy model jako domyślny, droższy tylko dla trudniejszych zadań lub wyższych wymagań jakości.
• Parametry generowania: ograniczenie max output tokens, dopasowanie temperatury, top_p, itp. (głównie wpływają na długość i powtarzalność odpowiedzi).
• Rozmiar kontekstu: skracanie historii rozmowy, selektywne dołączanie dokumentów, limity na liczbę źródeł.
• Tryb odpowiedzi: krótka odpowiedź vs odpowiedź rozbudowana; streszczenie zamiast pełnej analizy; formaty strukturalne (np. JSON) ograniczające „gadulstwo”.

Polityki budżetowe: jak to spiąć w jeden mechanizm

Skuteczna kontrola kosztu zwykle wymaga prostych, czytelnych polityk, np.:

• Budżet domyślny dla całej aplikacji + wyjątki dla wybranych tenantów (SLA) lub ról użytkowników.
• Stopniowanie jakości: najpierw ogranicz długość odpowiedzi, potem przełącz na tańszy model, a dopiero na końcu odmawiaj.
• Bezpieczne maksimum: twardy sufit kosztu na request niezależnie od treści (ważne przy nieprzewidywalnych promptach).

Minimalny przykład: egzekwowanie budżetu na poziomie requestu

// Pseudokod: kontrola kosztu przed wywołaniem modelu
function routeWithBudget(input, user, tenant, policy) {
  const estimatedInputTokens = estimateTokens(input.prompt);
  const maxOut = Math.min(policy.maxOutputTokens, user.remainingOutputCap);

  // Twardy limit na kontekst
  if (estimatedInputTokens > policy.maxInputTokens) {
    input.prompt = truncateContext(input.prompt, policy.maxInputTokens);
  }

  // Wybór modelu na podstawie budżetu
  const model = (tenant.monthlySpend > policy.spendThreshold)
    ? policy.cheaperModel
    : policy.defaultModel;

  // Twardy limit na koszt odpowiedzi
  return callLLM({ model, prompt: input.prompt, max_output_tokens: maxOut });
}

Najważniejsze jest, by limity były mierzalne i egzekwowalne (hard caps), a nie tylko „zaleceniami”. Dzięki temu router staje się mechanizmem finansowej kontroli, a nie wyłącznie logiką doboru jakości.

5. Mechanizmy niezawodności: fallbacki, retry, canary release, degradacja jakości kontrolowana

Niezawodność w systemie z LLM Routerem oznacza utrzymanie działania usługi mimo błędów modeli, limitów dostawcy, skoków latencji oraz zmiennej jakości odpowiedzi. Celem nie jest „zawsze najlepsza” odpowiedź, tylko przewidywalne zachowanie: jasne zasady co zrobić, gdy wybrany model nie odpowiada, odpowiada zbyt wolno albo zwraca wynik o niskiej jakości.

Fallbacki: zapasowe ścieżki działania

Fallback to alternatywny wybór modelu lub trybu pracy, uruchamiany, gdy podstawowa decyzja routingu nie może zostać zrealizowana. Kluczowe jest, by fallback był zaprojektowany, a nie przypadkowy: powinien odpowiadać na pytanie „co jest ważniejsze: koszt, latencja czy jakość?”.

• Fallback po błędzie technicznym: gdy wystąpią 5xx, time-out, błędy sieciowe lub brak pojemności.
• Fallback po przekroczeniu limitów: rate limit (429), limity tokenów/kontekstu, limity budżetowe.
• Fallback po blokadzie polityk: gdy model/dostawca odrzuca treść (policy block) i dozwolone jest przejście na inny tryb (np. odpowiedź ogólna, bez treści wrażliwych).
• Fallback „w górę” lub „w dół”: awaryjnie droższy model dla utrzymania jakości albo tańszy dla utrzymania kosztu/latencji.

W praktyce dobrze działają łańcuchy fallbacków, np. „model A → model B → tryb streszczania/ekstrakcji → komunikat o ograniczeniach”. Ważne, by łańcuch był krótki, a kryteria przełączeń jednoznaczne.

Retry: odzyskiwanie po błędach przejściowych

Retry to ponowienie tego samego żądania (zwykle do tego samego modelu) w odpowiedzi na przejściowe problemy. Najczęstszy błąd to „retry bez końca” albo retry bez rozróżnienia typu błędu.

• Retry ma sens głównie dla: 429 (z poszanowaniem Retry-After), 5xx, chwilowych problemów transportowych.
• Retry zwykle nie ma sensu dla: błędów walidacji wejścia, przekroczenia kontekstu, blokad polityk (tu częściej potrzebna jest zmiana trybu lub treści).
• Backoff i jitter: rosnące opóźnienie i losowe rozproszenie zapobiegają „synchronizacji” retry w piku.
• Limity: maksymalna liczba prób oraz budżet czasu (timeout całej operacji) chronią latencję.

Dobrym uzupełnieniem retry jest idempotencja na poziomie aplikacji (np. klucz żądania), aby nie dublować skutków ubocznych, jeśli wywołanie jest częścią większego procesu.

Canary release: bezpieczne wdrażanie zmian

Modele i promptowanie zmieniają się szybciej niż klasyczne komponenty. Canary release ogranicza ryzyko, kierując mały odsetek ruchu do nowej konfiguracji, zanim stanie się ona domyślna.

• Canary per model: nowy model dostaje np. 1–5% ruchu w danym scenariuszu.
• Canary per policy: test zmian w regułach routingu lub progach decyzyjnych.
• Canary per segment: tylko wybrani użytkownicy/tenant, tylko wybrane typy pytań.

Istotą canary jest szybka odpowiedź na pogorszenie: automatyczny rollback przy przekroczeniu progów (latencja, błędy, koszty, wskaźniki jakości). Canary nie służy do „szukania najlepszego modelu”, tylko do wdrażania zmian z ograniczonym promieniem rażenia.

Kontrolowana degradacja jakości: priorytety w stresie

Gdy system jest pod presją (piki ruchu, ograniczony budżet, wzrost latencji), zamiast awarii „twardej” można zastosować degradację jakości w sposób jawny i kontrolowany. Router powinien mieć zdefiniowane tryby awaryjne, które zmieniają zachowanie bez chaosu.

• Redukcja rozmiaru odpowiedzi: krótsze odpowiedzi, format „tl;dr”, mniejsza liczba punktów.
• Ograniczenie kontekstu: mniejsza liczba dokumentów w RAG, krótsze okno historii, streszczenie kontekstu zamiast pełnego cytowania.
• Zmiana parametrów: niższy limit tokenów wyjściowych, bardziej deterministyczne ustawienia (mniej „rozgadane” odpowiedzi).
• Przejście na tańszy/szybszy model: ale tylko dla zadań o niższym ryzyku i mniejszych wymaganiach jakości.
• Tryb „bez narzędzi”: jeśli wywołania narzędzi (search/db) są wąskim gardłem, czasem lepiej odpowiedzieć ogólnie i wskazać ograniczenia.

Degradacja powinna być odwracalna (po ustąpieniu presji) i spójna (te same bodźce → te same decyzje). W scenariuszach krytycznych lepiej preferować degradację „bezpieczną” (np. mniej szczegółów, więcej zastrzeżeń) niż taką, która zwiększa ryzyko halucynacji lub naruszeń.

Minimalny szkic logiki niezawodności (przykład)

// Pseudokod: kolejność jest ważniejsza niż szczegóły implementacji
handle(request):
  try:
    with timeout(T_total):
      resp = call_primary_model(request, timeout=T_primary)
      if is_acceptable(resp):
        return resp
      // jeśli jakość nieakceptowalna: przełącz na tryb awaryjny lub lepszy model
      return call_fallback_quality(request)

  except RateLimitError as e:
    // krótki retry z poszanowaniem Retry-After, potem fallback
    resp = retry_with_backoff(() => call_primary_model(request), max_tries=2)
    if resp: return resp
    return call_fallback_capacity(request)

  except TimeoutError:
    return call_fallback_fast(request)

  except PolicyBlockError:
    return safe_degraded_response(request)

Najważniejsze: mechanizmy niezawodności nie powinny „przykrywać” problemów. Ich rolą jest utrzymanie przewidywalnego działania, a jednocześnie generowanie sygnałów (metryk/zdarzeń), że podstawowa ścieżka wymaga korekty.

6. Przykładowe reguły routingu i konfiguracje (policy/DSL) dla typowych scenariuszy

Reguły routingu warto zapisywać w formie prostej polityki (policy) lub DSL, który da się wersjonować, testować i audytować. Dobra konfiguracja opisuje kiedy użyć danego modelu, jak go uruchomić (np. limity tokenów), oraz co zrobić w razie niepewności lub błędu. Poniżej znajdują się przykłady wzorców, które często pojawiają się w praktyce.

6.1. Minimalny szkielet policy/DSL

Najczęstszy układ to: warunki (predykaty) → decyzja (model/parametry) → akcje dodatkowe (np. redakcja danych, wymuszenie cytowań, ograniczenie narzędzi).

policy:
  default:
    route: model: "mid"
    params: { max_tokens: 800 }

  rules:
    - if: { contains_pii: true }
      route: model: "secure"
      params: { max_tokens: 600 }
      actions: [ "redact_pii", "no_external_tools" ]

    - if: { task: "coding" , complexity: "high" }
      route: model: "strong"
      params: { max_tokens: 1800 }

6.2. Typowe scenariusze i przykładowe reguły

6.3. Reguły „gating”: koszt vs jakość

Najprostsza praktyka to dwustopniowe bramkowanie: start od tańszego modelu, a eskalacja tylko gdy sygnały wskazują na trudność lub ryzyko.

rules:
  - if: { task: "qa", complexity: "low", risk: "low" }
    route: model: "cheap"
    params: { max_tokens: 400 }

  - if: { complexity: "high" }
    route: model: "strong"
    params: { max_tokens: 1600 }

  - if: { risk: "high" }
    route: model: "strong"
    params: { max_tokens: 900 }
    actions: [ "require_citations" ]

6.4. Routing pod „tenant” i klasę użytkownika (plan/priorytet)

W środowiskach wielodzierżawnych (multi-tenant) polityka często różnicuje modele i limity w zależności od planu, priorytetu lub pory dnia.

rules:
  - if: { tenant_tier: "enterprise" }
    route: model: "strong"
    params: { max_tokens: 2000, timeout_ms: 20000 }

  - if: { tenant_tier: "standard" }
    route: model: "mid"
    params: { max_tokens: 1200, timeout_ms: 12000 }

  - if: { tenant_tier: "free" }
    route: model: "cheap"
    params: { max_tokens: 600, timeout_ms: 8000 }

6.5. Wrażliwość danych: „secure mode” jako nadrzędna polityka

Częsty wzorzec to nadrzędna reguła, która nadpisuje pozostałe decyzje, gdy wykryto wrażliwe dane. Dzięki temu reszta polityk może pozostać prostsza.

rules:
  - if: { contains_pii: true }
    route: model: "secure"
    actions: [ "redact_pii", "no_external_tools", "no_prompt_logging" ]

  - if: { task: "summarization" }
    route: model: "cheap"

6.6. Polityki dla RAG: wymuszanie źródeł i ograniczanie swobody generacji

W przypadku pytań „o fakty” w systemach opartych o dokumenty, reguły często wymuszają: użycie retrieval, cytowania oraz odmowę odpowiedzi bez źródeł.

rules:
  - if: { task: "knowledge_qa" }
    route: model: "mid"
    tools: [ "retrieval" ]
    actions: [ "require_citations", "refuse_if_no_sources" ]
    params: { max_tokens: 900 }

6.7. Routing „narzędziowy”: kiedy wolno używać tooli

Polityka może osobno kontrolować dostęp do narzędzi (np. przeglądania zasobów, wykonywania kodu, zapytań do API). To pozwala zredukować ryzyko i koszt bez zmiany modelu.

rules:
  - if: { task: "math" }
    route: model: "mid"
    tools: [ "calculator" ]

  - if: { contains_secrets: true }
    route: model: "secure"
    tools: [ ]

6.8. Reguły formatu i długości odpowiedzi jako element routingu

Nie zawsze trzeba przełączać model. Część „routingu” to dobór parametrów i kontraktu odpowiedzi (krótko vs szczegółowo, JSON vs tekst), co bezpośrednio wpływa na koszt i stabilność integracji.

rules:
  - if: { channel: "api", expects: "json" }
    route: model: "mid"
    actions: [ "force_json_schema" ]
    params: { max_tokens: 700 }

  - if: { channel: "chat", user_pref: "short" }
    route: model: "cheap"
    params: { max_tokens: 250 }

6.9. „Niepewność” jako warunek: eskalacja zamiast zgadywania

W praktyce spotyka się reguły, które eskalują do mocniejszego modelu lub wymuszają doprecyzowanie pytania, gdy system nie ma wystarczających danych (np. brak kontekstu, zbyt ogólna prośba).

rules:
  - if: { missing_context: true }
    route: model: "cheap"
    actions: [ "ask_clarifying_question" ]

  - if: { ambiguity: "high" }
    route: model: "strong"
    params: { max_tokens: 900 }

6.10. Dobre praktyki zapisu polityk (krótko)

• Najpierw reguły nadrzędne: bezpieczeństwo danych, ograniczenia narzędzi, wymagany format.
• Potem reguły koszt/jakość: proste zadania do tańszych modeli, złożone do mocniejszych.
• Na końcu wyjątki: specyficzne kanały, tenant, typy użytkowników.
• Domyślna ścieżka powinna być przewidywalna i łatwa do audytu.

7. Monitorowanie i observability: logowanie decyzji, metryki kosztu/jakości/ryzyka, alerty

LLM Router jest systemem decyzyjnym, a nie tylko „przełącznikiem” między modelami. Żeby był bezpieczny i opłacalny w utrzymaniu, trzeba widzieć nie tylko wyniki odpowiedzi, ale też dlaczego router wybrał dany model, ile to kosztowało, jak wpłynęło na jakość oraz czy nie naruszono polityk ryzyka. Observability w tym kontekście to połączenie: śledzenia przepływu (trace), telemetrii (metryki) i audytu (logi) — spięte alertami, które reagują na odchylenia.

Logowanie decyzji routingu (audyt i debugowalność)

Najważniejszą zasadą jest rozdzielenie: logów operacyjnych (debug, diagnoza), logów audytowych (zgodność, rozliczalność) oraz telemetrii (metryki zagregowane). Dla routingu kluczowe jest, aby każdy request zostawiał ślad pozwalający odtworzyć decyzję bez domysłów.

• Kontekst decyzji: typ zadania w ujęciu routera, cechy wejścia użyte w decyzji (np. rozmiar, język, sygnały wrażliwości), wymagany poziom jakości, dopuszczalne ryzyko.
• Wynik decyzji: wybrany model i wariant (np. tryb, parametry wysokiego poziomu), ścieżka (pierwszy wybór vs fallback), powód wyboru w postaci kategorycznych etykiet (np. „niski koszt”, „wrażliwe dane”, „wymagana wysoka precyzja”).
• Rozliczenie: szacowany i rzeczywisty koszt, liczba tokenów, czas odpowiedzi, limit/budżet i informacja, czy zadziałały ograniczenia.
• Bezpieczeństwo: wynik detekcji wrażliwości, zastosowane redakcje, blokady, decyzje o ograniczeniu funkcji (np. odmowa wykonania), identyfikator wersji polityk.
• Identyfikowalność: korelacja end-to-end (request ID, trace ID), wersja routera, wersja konfiguracji i reguł, środowisko (prod/stage), tenant/użytkownik w postaci pseudonimizowanej.

Jednocześnie logowanie nie może zwiększać ryzyka: treści promptów i odpowiedzi powinny trafiać do logów tylko jeśli jest to świadomie włączone, minimalne i zgodne z polityką danych. W praktyce często wystarcza logowanie metadanych i skrótów/odcisków do korelacji zdarzeń.

Metryki: koszt, jakość, ryzyko i „zdrowie” routera

Metryki powinny odpowiadać na cztery pytania: czy działa, ile kosztuje, czy utrzymuje jakość i czy nie rośnie ryzyko. Istotne jest też cięcie metryk po wymiarach: model, trasa, tenant, typ zapytania, region, wersja polityki i czas.

• Koszt: koszt na request, koszt na użytkownika/tenanta, koszt per typ zapytania, odsetek zapytań przekierowanych na droższe modele, odchylenia od budżetu i trendy dzienne/tygodniowe.
• Latencja i niezawodność: p50/p95/p99 czasu odpowiedzi, timeouty, błędy dostawcy, retry rate, odsetek fallbacków, wskaźniki degradacji (np. „zredukowana jakość” vs normalny tryb).
• Jakość: sygnały implicit (np. czas do kolejnego zapytania, liczba poprawek/re-promptów, odsetek eskalacji), sygnały explicit (oceny użytkowników), oraz wyniki automatycznych testów regresyjnych na reprezentatywnych próbkach.
• Ryzyko: wykrycia wrażliwych danych, naruszenia polityk, odsetek blokad/odmów, podejrzane wzorce nadużyć, rozjazd między klasyfikacją wrażliwości a późniejszymi incydentami.
• Stabilność decyzyjna: zmienność decyzji dla podobnych zapytań, skoki w dystrybucji routingu po wdrożeniu nowej wersji reguł, „drift” w typach pytań.

Warto patrzeć na metryki nie tylko globalnie. Router może wyglądać dobrze w średniej, a jednocześnie generować koszty lub błędy w jednym typie zapytań albo u jednego klienta. Dlatego kluczowe są przekroje i porównania przed/po zmianie polityk.

Śledzenie przepływu (tracing) w architekturze z wieloma krokami

Gdy routing obejmuje kilka etapów (np. klasyfikacja, wybór modelu, walidacje bezpieczeństwa, ewentualne poprawki promptu, fallback), potrzebne jest śledzenie end-to-end. Tracing pozwala zrozumieć, gdzie faktycznie „ucieka” czas i koszt, oraz który krok powoduje degradację jakości.

• Spójne identyfikatory dla wszystkich kroków, także tych realizowanych asynchronicznie.
• Segmentacja czasu na etapy: klasyfikacja, decyzja, wykonanie, walidacja, ewentualne ponowienia.
• Tagowanie trasy i wersji polityki, aby porównywać zachowanie po zmianach.

To jest szczególnie ważne w sytuacjach, gdy jeden request skutkuje wieloma wywołaniami modeli (np. wybór, weryfikacja, poprawka) i dopiero suma daje realny koszt oraz latencję.

Alerty: z odchyleń do działań

Alerty w routerze powinny być nastawione na odchylenia od oczekiwanego zachowania, a nie wyłącznie na przekroczenie prostych progów. W przeciwnym razie zespół szybko wpadnie w zmęczenie alarmami.

• Koszt: nagły wzrost kosztu na request, skok udziału droższych modeli, przekroczenia budżetów per tenant, anomalia w tokenach (np. nietypowo długie odpowiedzi).
• Latencja: wzrost p95/p99, wzrost timeoutów, wzrost liczby retry/fallback, spadek przepustowości.
• Jakość: wzrost re-promptów, spadek ocen użytkowników, wzrost eskalacji do człowieka, regresja na zestawach kontrolnych.
• Ryzyko i zgodność: wzrost wykryć wrażliwych danych, wzrost blokad, podejrzany wzrost zapytań o charakterze nadużyciowym, wykrycie odpowiedzi naruszających polityki.
• Zmiany konfiguracji: alerty po wdrożeniu nowej wersji polityk, gdy dystrybucja routingu lub koszt/latencja znacząco odbiega od bazowej linii.

Dobre alerty mają jasno zdefiniowaną akcję: kto reaguje, jaki jest oczekiwany czas reakcji, i co należy sprawdzić w pierwszej kolejności (np. czy wzrosły fallbacki, czy zmieniła się klasyfikacja typu pytań, czy dostawca ma incydent).

Praktyki operacyjne: jakość danych obserwowalności i minimalizacja ryzyka

Observability dla LLM Routera musi być zaprojektowane tak, by nie stało się kolejnym źródłem wycieku danych lub niekontrolowanego kosztu.

• Minimalizacja danych: loguj to, co potrzebne do decyzji i audytu; treści przechowuj tylko tam, gdzie to uzasadnione, z ograniczonym dostępem i retencją.
• Spójność semantyczna: jednolite definicje metryk (co znaczy „fallback”, „odmowa”, „token”), aby porównania w czasie miały sens.
• Retencja i uprawnienia: osobne polityki dostępu do logów audytowych, operacyjnych i danych jakościowych; krótsza retencja dla danych wrażliwych.
• Testowalność: możliwość odtworzenia decyzji na podstawie zapisanych metadanych, bez konieczności przeglądania pełnych treści.

Jeśli router ma być „dynamiczny”, to obserwowalność jest jego układem nerwowym: bez niej nie da się bezpiecznie optymalizować kosztu, utrzymać jakości ani udowodnić zgodności decyzji w czasie.

8. Ewaluacja skuteczności routera: eksperymenty A/B, testy offline, miary jakości i kalkulacja oszczędności

LLM Router ma sens tylko wtedy, gdy da się udowodnić, że decyzje routingu poprawiają bilans koszt–jakość–ryzyko. Ewaluacja powinna odpowiadać na cztery pytania: czy odpowiedzi są wystarczająco dobre, czy spada koszt, czy nie rośnie ryzyko (np. naruszeń polityk), oraz czy zyski utrzymują się w czasie mimo zmian modeli i ruchu.

Eksperymenty A/B w produkcji

Najbardziej wiarygodnym sposobem oceny jest porównanie routera z punktem odniesienia w warunkach rzeczywistych. W praktyce oznacza to podział ruchu na warianty, w których różni się jedynie polityka routingu (np. „zawsze model premium” vs „router dynamiczny”). Kluczowe jest, by eksperyment mierzył nie tylko koszt i latencję, ale też skutki uboczne: wzrost eskalacji do człowieka, spadek konwersji, częstsze poprawki użytkownika lub większą liczbę re-try.

• Dobór metryk sukcesu: osobno dla jakości (satysfakcja, trafność), ekonomii (koszt na sesję), wydajności (P95/P99), oraz zgodności/bezpieczeństwa (incydenty, blokady, redakcje).
• Segmentacja wyników: wyniki globalne często maskują regresje. Router zwykle wygrywa na prostych zapytaniach, a przegrywa na niszowych lub wysokostawkowych; dlatego analizuje się segmenty wg typu zadania, języka, kanału, długości kontekstu i wrażliwości danych.
• Bezpieczeństwo wdrożenia: gdy istnieje ryzyko regresji jakości, test zaczyna się od małego udziału ruchu i rośnie stopniowo, z jasno zdefiniowanymi progami zatrzymania.

Testy offline: szybkie iteracje bez ryzyka dla użytkownika

Testy offline pozwalają iterować nad polityką routingu bez wpływu na produkcję. Wykorzystuje się zbiory historycznych zapytań (po anonimizacji) lub zestawy testowe z kontrolowaną trudnością. Warianty routera porównuje się na tych samych danych, co ułatwia wykrywanie, które klasy zapytań są błędnie kierowane do zbyt słabego lub zbyt drogiego modelu.

• Replay logów: symulacja decyzji routera na realnym ruchu z przeszłości, z oceną kosztu i przewidywaniem jakości.
• Zestawy „golden”: małe, ale reprezentatywne testy z ręczną oceną lub zaakceptowanymi odpowiedziami referencyjnymi; ważne zwłaszcza w domenach regulowanych.
• Testy odporności: przypadki graniczne (wieloznaczność, długie konteksty, sprzeczne instrukcje), gdzie routing ma duży wpływ na ryzyko halucynacji i błędnych działań.

Miary jakości: co mierzyć, żeby nie optymalizować w próżni

Jakość odpowiedzi jest wielowymiarowa, więc pojedynczy wskaźnik rzadko wystarcza. W ocenie routera przydaje się zestaw miar, które rozdzielają „czy odpowiedź jest dobra” od „czy była dostarczona w odpowiednim czasie i formie”.

• Trafność i kompletność: czy odpowiedź rozwiązuje problem i pokrywa kluczowe aspekty pytania.
• Wierność źródłom: szczególnie w scenariuszach RAG lub pracy na dokumentach; mierzy się skłonność do konfabulacji i błędnych cytowań.
• Zgodność z instrukcją: format, styl, ograniczenia (np. brak danych wrażliwych), oraz zachowanie polityk.
• Stabilność: czy różne uruchomienia dają porównywalne wyniki, oraz czy router nie wprowadza „losowych” przeskoków jakości.
• Metryki pośrednie: liczba doprecyzowań od użytkownika, odsetek przerwanych sesji, liczba eskalacji, czy czas do uzyskania użytecznej odpowiedzi.

Warto oddzielić ocenę modelu od oceny decyzji routingu. Router może przegrywać, bo źle klasyfikuje zapytanie, nawet jeśli modele same w sobie są wystarczająco dobre.

Kalkulacja oszczędności: nie tylko cena tokena

Oszczędność routera to różnica między kosztem bazowym a kosztem po routingu, z uwzględnieniem efektów wtórnych. Najprostszy obraz to koszt na zapytanie lub na sesję, ale w praktyce trzeba policzyć pełny bilans.

• Koszt bezpośredni: zużycie tokenów wejścia/wyjścia, narzuty narzędzi (np. dodatkowe wywołania), oraz ewentualne koszty embedów i wyszukiwania.
• Koszt jakości: jeśli tańszy routing zwiększa liczbę ponowień, doprecyzowań i „drugich prób” droższym modelem, realna oszczędność może stopnieć lub zniknąć.
• Koszt latencji: wolniejsza odpowiedź może obniżać konwersję lub zwiększać porzucenia; to często ważniejsze niż sama cena tokenów.
• Koszt ryzyka: incydenty zgodności, wycieki danych, błędne rekomendacje w krytycznych procesach—nawet rzadkie—mogą przewyższyć oszczędności.

Dobrym celem jest przedstawienie wyniku jako oszczędność na 1000 sesji lub koszt całkowity na zadanie biznesowe, a nie wyłącznie „taniej o X% na tokenach”. Dzięki temu router jest oceniany w tym samym języku, co decyzje produktowe.

Higiena eksperymentów i utrzymanie wyniku w czasie

Nawet dobrze działający router może z czasem tracić skuteczność: zmienia się rozkład zapytań, aktualizują się modele, rosną limity kontekstu lub pojawiają się nowe polityki. Dlatego ewaluacja powinna być cykliczna, z kontrolą dryfu i okresowym „re-baseline” wyników. Najważniejsze jest utrzymanie spójności: te same definicje metryk, porównywalne segmenty oraz jasne kryteria akceptacji, które równoważą koszt, jakość i ryzyko.

W Cognity łączymy teorię z praktyką – dlatego te podejścia do ewaluacji routera rozwijamy także w formie ćwiczeń na szkoleniach.

Asana vs Trello vs Planner: 8 scenariuszy pracy, w których każde narzędzie wygrywa (i przegrywa) 07 kwietnia 2026

Ranking, który nie kłamie: normalizacja danych (min-max, z-score, robust) w raportach 05 kwietnia 2026