Procedura

Routing modeli i fallback

W praktyce inżynieria promptów i kontekstu kończy się na tym, że różne zadania wymagają różnych modeli, budżetów i poziomów kontroli. Ten rozdział opisuje procedurę routingu modeli oraz degradacji kontrolowanej, tak aby zachować SLA, koszt i rzetelność — bez „magii” w promptach.

Czas czytania: ~16 min Aktualizacja: 2026-01-09
Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Wdrożenie i governance i ma formę Procedura. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal właścicieli (RACI) dla polityk, szablonów i danych.
  • Wersjonuj i publikuj zmiany (changelog) z uzasadnieniem.
  • Prowadź rejestr wyjątków i decyzji (ADR) dla odstępstw.
  • Zdefiniuj SLO i monitoring (jakość, koszty, bezpieczeństwo).
  • Zaplanuj rollout: środowiska, feature flags, rollback.
  • Ustal rytm przeglądów i audytów (np. co kwartał).

Najczęstsze pułapki

  • „Wdrożenie na wczoraj” bez ownerów – po miesiącu nikt nie utrzymuje standardu.
  • Brak changelogu – użytkownicy nie wiedzą, czemu odpowiedzi się zmieniły.
  • Brak rollbacku – błąd w polityce rozlewa się na całą organizację.
  • Brak procesu wyjątków – wszyscy robią „po swojemu”, standard się rozpada.

Artefakty w Luage

raci policy_versioning changelog exception_log rollback_plan

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

Szablon do skopiowania

Wpis do changelogu (przykład)

date: 2026-01-18
change:
  id: language.standard@0.10
  summary: "Ujednolicenie terminologii i doprecyzowanie stylu"
  owner: "Content/AI Governance"
  impact: "Wsparcie, dokumentacja, marketing"
  rollback: "powrót do 0.9"

Governance to powtarzalność: jasne role, wersje, rejestry i kontrola jakości przed zmianą.

Kryteria gotowości
  • Zdefiniowane tieri (Fast/Balanced/High accuracy) oraz dozwolone zastosowania.
  • Router ma jawne sygnały wejściowe (ryzyko, domena, długość, tryb).
  • Istnieje polityka fallback (co robić przy błędzie, przeciążeniu, braku źródeł).
  • Każda decyzja ma trace_id oraz zapis w audycie.
  • Budżety kosztu/latencji są monitorowane i mają limity.
Router jako polityka: sygnały → decyzja → tier → fallback (jawny i audytowalny).
Router jako polityka: sygnały → decyzja → tier → fallback (jawny i audytowalny).
Praktyczna zasada: routing to nie „AI wybiera model”, tylko polityka wybiera model. Model może proponować, ale system decyduje.

1. Cel procedury

Routing ma zapewnić trzy rzeczy jednocześnie: przewidywalny koszt, przewidywalną jakość oraz przewidywalne zachowanie w awarii. Jeśli brakuje choć jednego z tych elementów, system zaczyna „pływać” w czasie, a debugging staje się kosztowny.

2. Sygnały routingu (wejście do polityki)

  • Ryzyko: PII, tematy prawne, finanse, treści wrażliwe, działania nieodwracalne.
  • Tryb: suggest vs execute vs approve (w tym Human‑in‑the‑Loop).
  • Domena: support, dokumentacja, inżynieria, compliance; różna tolerancja błędu.
  • Skala: długość kontekstu, liczba dokumentów, liczba narzędzi.
  • SLA: latencja i dostępność; w kryzysie lepsza jest odpowiedź uboższa, ale poprawna.

3. Polityka tierów (Fast / Balanced / High accuracy)

TierDo czegoOgraniczeniaGating
Fast FAQ, proste klasyfikacje, krótkie odpowiedzi. Krótki kontekst, brak wrażliwych decyzji. Lint językowy, format.
Balanced Domyślny tryb: większość rozmów. Wymaga stabilnego pakietu kontekstu. Lint + cytowania (jeśli claimy faktów).
High accuracy Złożone zadania, RAG, weryfikacje. Wyższy koszt i latencja. Źródła, walidacje, approval przy ryzyku.

4. Fallback i degradacja kontrolowana

Fallback nie powinien być „automatycznym przeskokiem” na słabszy model bez zmiany oczekiwań. Degradacja musi być jawna w polityce: co obniżamy (np. zakres, długość, pewność), a czego nie obniżamy (np. bezpieczeństwo).

  • Brak źródeł (RAG): zamiast zgadywać — poproś o doprecyzowanie albo przejdź w tryb „bez odpowiedzi”.
  • Timeout narzędzia: zwróć status + proponuj alternatywę (np. eskalacja).
  • Przeciążenie: skróć odpowiedź, ogranicz liczbę narzędzi, przełącz na tryb asynchroniczny (jeśli system wspiera).
Nie rób: „W razie awarii model A, użyj modelu B i zachowuj się identycznie”. To przepis na ukryte błędy jakościowe.

5. Bezpieczeństwo i compliance

  • Zakres danych: nie każdy tier może widzieć te same dane. Uprawnienia są po stronie systemu.
  • Tryb execute: wymaga bramki (Tool Gateway) i kontraktu narzędzi.
  • Audit: loguj decyzję routera (model, wersja, powód, sygnały) — bez danych wrażliwych.

6. Obserwowalność, budżety i regresje

Router jest elementem „sterowania ruchem”. Bez metryk staje się losowy.

  • Koszt: średni koszt per zapytanie, percentyle, budżet dzienny.
  • Latencja: p50/p95, timeouts, retry.
  • Jakość: wskaźniki błędów, coverage cytowań, odsetek eskalacji.
  • Drift: czy rozkład tierów zmienia się w czasie (np. po zmianie polityki).

7. Przykładowa konfiguracja (skrót)

{
  "router": {
    "tiers": [
      { "name": "fast", "max_risk": "low", "max_context_tokens": 6000 },
      { "name": "balanced", "max_risk": "medium", "max_context_tokens": 16000 },
      { "name": "high", "min_risk": "medium", "requires_citations": true }
    ],
    "fallback": {
      "on_timeout": "balanced",
      "on_no_sources": "ask_clarify",
      "on_tool_error": "escalate"
    },
    "audit": { "log_decision": true, "redact": ["pii","secrets"] }
  }
}

8. Checklist

  • Router ma zdefiniowane tieri, sygnały i progi.
  • Jest polityka fallback na timeouty, brak źródeł i błędy narzędzi.
  • Jest audyt decyzji (bez PII) oraz monitoring kosztu/latencji.
  • W trybach ryzykownych działa approval i bramki wykonawcze.

Powiązane

Warianty polityki
  • Quality‑first: najpierw jakość, potem koszt.
  • Cost‑bounded: twarde budżety per tenant/projekt.
  • Risk‑bounded: high‑risk zawsze przechodzi przez approval.
Powiązane
Tool Gateway Kontrakt narzędzi Monitoring jakości i drift