Główny model przestaje odpowiadać, więc aplikacja przełącza się na inny. Użytkownik nie widzi błędu. Widzi tylko nową odpowiedź z innym formatem i mniej trafnym faktem. Awaria infrastruktury została ukryta, ale jakość procesu właśnie zmieniła się bez decyzji właściciela.
Fallback powinien utrzymywać akceptowalny wynik albo zatrzymywać proces. Nie musi odpowiadać za wszelką cenę. Projekt zaczyna się od błędów, które chcesz obsłużyć, i przypadków, w których lepsza jest pauza.
Zmapuj rodzaje awarii
Rozróżnij limit 429, timeout, błąd serwera, brak uprawnień, zły format, przekroczenie kontekstu i błąd treści. Nie każdy powinien uruchamiać nowy model. Błąd walidacji trzeba poprawić, nie ponawiać go w innym kanale.
Zapisz, które błędy są tymczasowe i jakie mają skutek. Limit może wymagać backoff, timeout nieznanego stanu, a brak uprawnień zmiany konfiguracji. Fallback nie jest uniwersalnym komunikatem „spróbuj gdzie indziej”.
Sprawdź, czy modele mają wspólne limity. OpenAI zwraca uwagę, że zmiana modelu może nie pomóc, jeżeli współdzielą one zasoby. Inna nazwa nie zawsze oznacza nową pojemność.
Zdefiniuj akceptowalny wynik fallbacku
Zapisz minimalne kryteria: fakty, źródło, format, skutek, czas i koszt. Nie zakładaj, że szybsza odpowiedź jest lepsza od pauzy. Przy decyzjach krytycznych inny model może być niedopuszczalny.
Przygotuj te same przypadki dla głównego i zapasowego kandydata. Porównaj błędy krytyczne i zmienność. Test przed awarią jest tańszy niż test na użytkownikach.
Jeżeli wynik nie spełnia progu, zatrzymaj zadanie lub przekaż do ręcznej ścieżki. Brak odpowiedzi jest czasem bezpieczniejszy niż odpowiedź poza standardem.
Wybierz kandydata przed incydentem
Nie szukaj nowego dostawcy w środku awarii. Oceń model na własnych danych, warunki danych, limity, format i koszt. Zapisz właściciela i datę testu. Fallback powinien być gotowy konfiguracyjnie i prawnie.
Sprawdź różnice w schemacie, narzędziach i kontekście. Model może nie obsługiwać wymaganego formatu lub obrazów. Nowa odpowiedź musi przechodzić tę samą walidację, a nie omijać ją awaryjnie.
Przy wyborze pomocne jest porównanie modeli na własnych danych. Kandydat jest częścią procesu, nie tylko nazwą w zmiennej.
Kontekst może nie zmieścić się w zapasie
Sprawdź długość i strukturę historii. Fallback z mniejszym kontekstem może gubić wcześniejsze decyzje. Nie ucinaj ich losowo. Zaprojektuj podsumowanie z zachowaniem źródeł i ograniczeń.
Zapisz wersję źródeł i decyzji przy zadaniu. Jeżeli kompresja zmienia sens, proces powinien się zatrzymać. Nie zastępuj oryginalnych faktów streszczeniem modelu bez odbioru.
Przy długiej rozmowie przetestuj przełączenie w środku. Model może interpretować wcześniejsze role inaczej. Użytkownik powinien wiedzieć, jeżeli zmienia się zachowanie systemu.
Walidacja pozostaje twarda
Nie wyłączaj schematu, limitów i reguł bezpieczeństwa przy fallbacku. Aplikacja powinna normalizować wynik i odrzucać błędy tak samo. Awaria nie jest powodem do przyjmowania dowolnego JSON-a lub dowolnego działania.
Jeżeli kandydat nie obsługuje wymaganego trybu, użyj osobnego adaptera z testami. Nie zmieniaj formatu dla użytkownika bez komunikatu. Walidacja biznesowa pozostaje niezależna od dostawcy.
Przy odpowiedziach strukturalnych pomocny jest przewodnik o JSON Schema AI. Zapasowy model przechodzi ten sam kontrakt.
Backoff przed zmianą modelu
Przy przejściowym limicie częstotliwości odczekaj zgodnie z dostępnymi nagłówkami i regułami. Błąd związany z wyczerpaniem środków lub limitu wydatków może wymagać osobnego działania, a samo ponawianie nie musi pomóc. Nie przełączaj przy każdym 429 natychmiast, bo możesz zwiększyć koszt i nie rozwiązać problemu. OpenAI opisuje exponential backoff, czyli wydłużanie przerw między ponowieniami. Zmiana modelu to osobna strategia i może nie pomóc przy współdzielonych limitach.
Dodaj jitter i limit prób. Wiele zadań nie powinno przełączać się jednocześnie na ten sam zapas. To tylko przenosi awarię do nowego dostawcy z większym entuzjazmem.
Przy timeout zachowaj nieznany stan. Nie wysyłaj ponownie zapisu bez idempotencji. Nowy model nie może powielić skutku starego żądania.
Circuit breaker i powrót do głównego
Jeżeli błędy się powtarzają, zatrzymaj próby na ograniczony czas zamiast ciągle sprawdzać głównego. Circuit breaker ogranicza obciążenie i daje procesowi przewidywalny fallback. Zapisz moment otwarcia i właściciela.
Po pauzie wykonaj mały test przed powrotem. Nie przenoś całego ruchu od razu. Oceń jakość i błędy, a następnie zwiększaj wolumen stopniowo.
Zapisz, kiedy proces działa na zapasie. Koszt i zachowanie mogą się różnić. Raport powinien pokazywać faktyczny model, nie tylko nazwę procesu.
Komunikacja z użytkownikiem
Nie udawaj, że nic się nie zmieniło, jeżeli format lub jakość jest inna. Poinformuj o ograniczeniu i dostępnym kroku. Użytkownik powinien wiedzieć, czy odpowiedź jest pełna, opóźniona czy wymaga nowej decyzji.
Nie wysyłaj technicznego kodu błędu bez kontekstu. Napisz, co działa i co jest zatrzymane. Przy działaniu krytycznym wskaż ręczny kanał i termin kolejnej informacji.
Nie ukrywaj awarii dla samego dobrego wyglądu. To utrudnia odbiór i zaufanie. Dobry fallback jest jasny o ograniczeniach.
Przykład: prosta klasyfikacja
W hipotetycznym scenariuszu główny model osiąga limit, a zapasowy obsługuje ten sam enum. Proces najpierw czeka zgodnie z regułą, potem przełącza ograniczoną partię. Walidacja sprawdza kategorie i przypadek „inne”.
Wynik przechodzi ten sam test. Koszt rośnie, ale jakość jest akceptowalna. Raport zapisuje model i liczbę przełączeń. Po pauzie główny wraca na mały wolumen.
Przy zadaniu wymagającym źródeł prawnych zatrzymałbyś proces zamiast akceptować mniej trafny model. Zakres fallbacku zależy od skutku błędu.
Przykład: zapis do CRM
Główne API zwraca timeout, więc aplikacja nie wie, czy rekord powstał. Nie wolno jej wywołać nowego modelu ani ponowić zapisu bez kontroli. Najpierw sprawdza zasób i klucz operacji.
Jeżeli po uzgodnieniu stanu ponowienie jest bezpieczne zgodnie z gwarancją dostawcy, aplikacja używa tego samego klucza w okresie jego działania. Gdy stan nadal jest niepewny albo brak odpowiedniej ochrony, zatrzymuje proces do ręcznej decyzji. Model zapasowy nie jest nawet potrzebny. To pokazuje, że odporność procesu nie polega wyłącznie na liście modeli.
Przy takich przypadkach pomocny jest przewodnik o ponowieniach integracji AI. Skutek jest ważniejszy niż sama dostępność odpowiedzi.
Testy awarii przed produkcją
Zasymuluj limit, timeout, błąd serwera, niepoprawny format i brak kontekstu. Sprawdź regułę przełączenia, komunikat, walidację i skutek. Nie testuj tylko poprawnego zapasowego modelu.
Dodaj powrót głównego i ponowienie po pauzie. Proces nie powinien oscylować między dostawcami co sekundę. Zapisz limity i czas odbioru.
Przy zapisie sprawdź brak duplikatów. Test ma potwierdzać jeden skutek niezależnie od liczby prób i modeli.
Kiedy pauza jest lepszym fallbackiem
Zatrzymaj przy decyzjach prawnych, finansowych, danych wrażliwych, niezgodnym formacie i braku akceptowalnego kandydata. Nie obniżaj standardu dla pozoru ciągłości. Ręczna ścieżka może być właściwa.
Poinformuj właściciela i użytkownika o zakresie. Zachowaj zadania do wznowienia z wersją źródła. Nie usuwaj ich dla czystego dashboardu.
Przy ciągłości pomocny jest plan awarii Aeneia Signal. Nie każdy proces musi odpowiadać natychmiast.
Karta fallbacku na jednej stronie
Zapisz błędy, kandydata, przypadki, progi, kontekst, koszt, walidację, komunikat i powrót. Dodaj właściciela i datę testu. To wystarcza na mały proces bez wielkiego dokumentu.
Po teście zaktualizuj ograniczenia i nowe przypadki. Fallback nie jest jednorazową konfiguracją. Modele i warunki zmieniają się.
Ręczna ścieżka jako zaplanowany wariant
Zapisz, co użytkownik lub zespół ma zrobić, gdy żaden model nie spełnia standardu. Może to być szablon, krótka kolejka lub kontakt z właścicielem. Ręczna ścieżka powinna mieć dane i limit pracy, a nie tylko komunikat „zrób to sam”.
Przygotuj minimalny pakiet: źródło, wersja, otwarty krok i stan skutku. Człowiek nie powinien odtwarzać całej historii. Przy długiej pauzie zachowaj termin kolejnej decyzji i odbiorcę.
Po awarii oceń koszt pracy ręcznej. Może fallback był droższy niż pauza, a zespół udawał oszczędność. Raport powinien pokazywać pełny koszt ciągłości.
Fallback a dane i dostawcy
Przy zmianie dostawcy sprawdź region, retencję, trenowanie, podwykonawców i uprawnienia. Osobno sprawdź, jakie dane wolno przekazać każdemu dostawcy dla danego celu, przy właściwych warunkach i uprawnieniach. Awaria nie zmienia tych ograniczeń.
Ogranicz kontekst do wymaganego minimum przed przełączeniem. Może część źródeł jest dozwolona tylko w jednym kanale i wymaga usunięcia. Test powinien obejmować odmowę, a nie tylko poprawny wynik.
Jeżeli dostawca zapasowy jest niedostępny lub niezatwierdzony, proces się zatrzymuje. Nie przesyłaj danych do prywatnego konta zastępczego. To nie jest fallback, tylko nowy incydent.
Pytania przy przeglądzie fallbacku
Zapytaj, które błędy uruchamiają zmianę, jaki jest minimalny standard, kto zatwierdza kandydata i kiedy wracasz do głównego. Dodaj pytanie o skutki już wykonane przed awarią. Bez tego fallback może powielić działania.
Sprawdź, czy raport pokazuje faktyczny model przy każdym wyniku. Jeżeli nie, nie wiesz, gdzie szukać błędów i kosztu. Logowanie powinno zachowywać identyfikatory, nie pełne poufne treści.
Przy kolejnych awariach porównaj, czy fallback zmniejsza skutki czy tylko przenosi je. Zapisz błędy jakości, czas i liczbę ręcznych interwencji. Nie oceniaj samej dostępności odpowiedzi. Proces ma działać dla użytkownika, a nie tylko odpowiadać.
Jeżeli zapasowy model wymaga innej rubryki, decyzja powinna być jawna. Nie zmieniaj oczekiwań podczas awarii dla zielonego wyniku. Może proces ma zatrzymać się zamiast akceptować nowy standard.
Po zmianie dostawcy lub wersji powtórz przypadki awarii. Konfiguracja mogła się zachować, ale zachowanie API lub limitów się zmienić. Właściciel powinien potwierdzić, że stara mapa nadal działa.
Przy zakończeniu procesu usuń zapasowe tokeny i dane testowe. Fallback nie może zostawiać dodatkowego aktywnego kanału po zakończeniu pracy.
Przy odbiorze nowej wersji fallbacku wykonaj kontrolowaną awarię na jednym zadaniu. Nie czekaj na prawdziwy incydent. Sprawdź wynik, format, komunikat i skutek przed ponownym włączeniem.
Zapisz, kiedy konfiguracja wymaga nowego kandydata lub ograniczenia zakresu. Stara wersja może nie obsługiwać nowych pól lub źródeł. Decyzja powinna być powiązana z testem i właścicielem procesu.
Przy zmianie właściciela przekaż mapę błędów i ograniczeń. Nowa osoba powinna wiedzieć, kiedy pauza jest właściwa i jak uruchomić ręczną ścieżkę. Nie przenoś tylko listy modeli.
Jeżeli fallback działa dłużej niż planowano, oceń koszt i jakość zamiast utrzymywać go automatycznie. Może główny proces wymaga zmiany lub zatrzymania. Raport powinien prowadzić do decyzji, a nie stałego zapasu.
Aeneia Audit pomaga ocenić ryzyko i proces ciągłości. Przy większej automatyzacji pomocny jest przewodnik Aeneia Signal o awarii.
W raporcie awarii zachowaj informację, który model obsłużył zadanie i jakie ograniczenia zastosowano. Jeśli zapasowa ścieżka nie spełnia ustalonego standardu, przekaż sprawę do obsługi ręcznej.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
