Playbook fallbacku wielomodelowego dla niezawodnych API AI

Najważniejsze wnioski

Ponawiaj tę samą trasę tylko w przypadku przejściowych awarii, takich jak timeouty i odpowiedzi 429.

Przełączaj się na model, który spełnia te same wymagania dotyczące możliwości i kontraktu wyjściowego.

Ustal maksymalny budżet kosztu i opóźnienia dla całego żądania, a nie dla każdej próby.

Rejestruj dostawcę, model, klasę błędu, liczbę ponowień i ostateczną trasę dla każdego żądania.

Oddziel ponawianie od fallbacku

Ponowienie wysyła żądanie ponownie tą samą trasą, ponieważ awaria może być tymczasowa. Fallback zmienia dostawcę lub model, ponieważ oryginalna trasa jest niedostępna lub nieodpowiednia.

Traktowanie obu działań jako jednej ogólnej pętli ponowień utrudnia diagnozowanie incydentów i może wielokrotnie zwiększać koszt bez poprawy skuteczności.

Ponowienie: timeout, reset połączenia, 429 lub tymczasowa odpowiedź 5xx.
Fallback: powtarzająca się awaria dostawcy, problem z dostępnością modelu lub ograniczenie polityki.
Zatrzymaj: nieprawidłowe żądanie, nieobsługiwany parametr lub nieudana walidacja wyjścia.

Zbuduj tabelę tras zgodną z możliwościami

Modele fallbacku powinny być grupowane według możliwości, a nie marki. Żądanie wizyjne nie może przejść do modelu tylko tekstowego, a ścisły workflow JSON nie powinien kierować do modelu, który regularnie narusza schemat.

Wymagane modalności wejścia i wyjścia.
Minimalny kontekst i długość wyjścia.
Obsługa wywołań narzędzi i strukturyzowanych wyników.
Maksymalna akceptowalna cena i opóźnienie.

Zastosuj jeden budżet na poziomie żądania

Budżet żądania powinien obejmować każdą próbę ponowienia i fallbacku. Przed rozpoczęciem kolejnej próby sprawdź, czy pozostały budżet opóźnienia i kosztu ją wspiera.

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

Mierz jakość fallbacku, nie tylko dostępność

Żądanie, które zakończyło się sukcesem, nadal może być porażką produktu. Śledź walidację wyjścia, wskaźnik korekt użytkownika i ukończenie zadania po zdarzeniu fallbacku.

Zalecany pulpit: skuteczność tras, wskaźnik fallbacku, p95 opóźnienia, szacowany koszt, wskaźnik zaliczenia walidacji i wynik jakości według modelu.

Najczęściej zadawane pytania

Czy każde nieudane żądanie AI powinno używać modelu fallback?

Nie. Nieprawidłowe parametry, nieobsługiwane dane wejściowe i nieudane kontrole bezpieczeństwa powinny kończyć się natychmiast. Fallback jest właściwy wtedy, gdy inna zgodna trasa może realistycznie wykonać to samo zadanie.

Ile prób fallbacku powinno dopuszczać żądanie AI?

Większość interaktywnych workflow powinna ograniczać łączną liczbę prób do dwóch lub trzech. Właściwy limit zależy od pozostałego budżetu opóźnienia, wartości zadania i szacowanego kosztu.