Przejdź do treści

Model zapasowy (Fallback model)

Definicja

Model zapasowy to drugi model albo tryb działania uruchamiany wtedy, gdy główny model nie działa, jest zbyt drogi, za wolny albo nie spełnia warunków jakości.

Co to w zasadzie jest?

To plan awaryjny dla aplikacji AI. Zamiast całkowitego błędu system może przełączyć się na prostszy model, odpowiedź szablonową albo bezpieczniejszy tryb działania.

Fallback pomaga wtedy, gdy:

  • usługa główna ma awarię,
  • odpowiedź trwa za długo,
  • koszt jednego zapytania jest za wysoki,
  • model nie daje wystarczającej jakości.

Praktyczne zastosowania (konkretne scenariusze)

Scenariusz 1: Awaria głównego dostawcy

  • Cel: utrzymać działanie usługi mimo problemu po stronie dostawcy.
  • Wejście: niedostępność API albo przekroczony timeout.
  • Kroki: wykrycie awarii -> przełączenie na model zapasowy -> zwrot odpowiedzi.
  • Rezultat: usługa działa dalej, choć w ograniczonym trybie.
  • Zabezpieczenie: testy przełączenia i monitoring awarii.

Scenariusz 2: Zbyt wysoki koszt zapytania

  • Cel: ograniczyć koszt przy prostych zadaniach.
  • Wejście: typ zapytania, koszt prognozowany i polityka routingu.
  • Kroki: ocena złożoności -> wybór tańszego modelu -> wykonanie zadania.
  • Rezultat: niższy koszt bez utraty działania systemu.
  • Zabezpieczenie: benchmark jakości dla klas zadań.

Scenariusz 3: Brak pewności odpowiedzi

  • Cel: nie wysyłać słabej odpowiedzi z głównego modelu.
  • Wejście: wynik głównego modelu i reguły jakości.
  • Kroki: ocena jakości -> odrzucenie wyniku -> przejście do trybu bezpiecznego.
  • Rezultat: użytkownik dostaje odpowiedź bardziej przewidywalną albo informację o ograniczeniu.
  • Zabezpieczenie: progi jakości i logika eskalacji.

Typowe błędy i pułapki

  • Brak testów fallbacku w praktyce.
  • Zapasowy model bez znanego poziomu jakości.
  • Przełączanie bez logowania decyzji.
  • Założenie, że model zapasowy „jakoś sobie poradzi”.

Ryzyka i jak je ograniczać

Ryzyko 1: Ukryty spadek jakości

  • Ryzyko: ukryty spadek jakości.
  • Jak ograniczać: mierz różnicę między trybami działania.

Ryzyko 2: Chaos operacyjny

  • Ryzyko: chaos operacyjny.
  • Jak ograniczać: jasno opisz warunki przełączenia.

Ryzyko 3: Brak przewidywalności

  • Ryzyko: brak przewidywalności.
  • Jak ograniczać: stosuj routing i progi jakości.

Ryzyko 4: Niezauważone awarie

  • Ryzyko: niezauważone awarie.
  • Jak ograniczać: monitoruj przełączenia i alerty.

Checklista „zanim użyjesz”

  • Czy wiadomo, kiedy uruchamia się fallback?
  • Czy model zapasowy był testowany?
  • Czy użytkownik wie, że działa tryb ograniczony?
  • Czy przełączenia są logowane?
  • Czy masz plan powrotu do trybu głównego?

Diagram

flowchart LR
    A[Zapytanie]
    B[Główny model]
    C[Warunek awarii lub słabej jakości]
    D[Model zapasowy]
    E[Odpowiedź]
    A --> B --> E
    B --> C --> D --> E

Diagram pokazuje, że fallback uruchamia się wtedy, gdy główny model nie spełnia warunków działania albo jakości.

Mapa powiązań

Powiązane hasła