Zmiana dostawcy modelu w czasie awarii bez zmiany tego, co obiecuje produkt

Failover zmienia więcej niż endpoint

Drugi model różni się od pierwszego nie tylko adresem URL. Zmienić się mogą wykonywanie instrukcji, format wywołań narzędzi, niezawodność wyników strukturalnych, odmowy, limity kontekstu, tokenizacja, a przez to koszt i opóźnienie. Model zapasowy może działać na innej umowie z dostawcą, w innym regionie i z inną retencją danych. Jeśli idzie przez inną bramkę lub inny klucz API, może mieć nawet inne uprawnienia. Każdy z tych punktów to obietnica produktu, której nikt nigdy nie spisał.

Spisz kontrakt zapasowy dla każdej trasy

• Jakość: przechodzi zestaw ewaluacyjny funkcji przy uzgodnionym progu, z własnym wariantem promptu
• Wynik: wyniki strukturalne przechodzą walidację względem tych samych schematów, a kod dalej w łańcuchu odrzuca wszystko inne
• Narzędzia i uprawnienia: ta sama lista narzędzi i ten sam zakres poświadczeń, bez niczego dodatkowego włączonego przez framework trasy zapasowej
• Warunki danych: dostawca, region i retencja zatwierdzone przez właścicieli danych dla tego, co wysyła ta funkcja
• Przepustowość i koszt: limity wywołań trasy zapasowej przy wolumenie z failoveru i oczekiwany koszt na żądanie
• Informacja: czy operatorzy lub użytkownicy dowiadują się, że działa trasa zapasowa

Jeśli żadna trasa nie spełnia kontraktu, uczciwym rozwiązaniem zapasowym jest tryb awaryjny: poprzedni proces bez AI, żądanie w kolejce albo jasny komunikat.

Co powinno wywołać przełączenie

Nie każdy błąd uzasadnia failover. Dokumentacja API Anthropic rozróżnia na przykład ograniczenie liczby wywołań (429), błędy wewnętrzne (500) i chwilowe przeciążenie (529). Nieprawidłowe żądania i odrzucone poświadczenia zwykle wskazują na problem po twojej stronie, choć to, co dostawca odrzuca, może się różnić między dostawcami. Sklasyfikuj każdy błąd i skonfiguruj dla niego sposób postępowania, a nie przełączaj automatycznie przy błędach, których trasa zapasowa nie naprawi albo które wymagają twojego dochodzenia. Książka SRE Google'a dodaje zasady ponowień: oddzielaj błędy, które warto ponowić, od trwałych, używaj losowego wykładniczego backoffu, ograniczaj liczbę ponowień na żądanie i nie ponawiaj na kilku warstwach naraz, bo trzy warstwy ponawiające po trzy razy zmieniają jedną akcję użytkownika w 64 próby. Gdy błędy lub opóźnienie modelu głównego przez uzgodniony czas przekraczają próg, przełączaj całą funkcję, a nie pojedyncze żądania, żeby jedna rozmowa nie skakała między modelami.

Udowodnij równoważność zachowania przed awarią

Uruchamiaj zestaw ewaluacyjny na każdej trasie zapasowej w tym samym rytmie co na głównej oraz po każdej zmianie promptów, modeli lub narzędzi. Porównuj rodzaje błędów, a nie tylko odsetek zaliczonych przypadków. Model zapasowy, który nieco częściej odmawia, może być do przyjęcia; taki, który wywołuje narzędzie zapisujące ze złymi argumentami, już nie. Trzymaj wariant promptu dla każdego modelu w systemie kontroli wersji i testuj go na tych samych schematach narzędzi.

Hipotetyczny przykład: na zestawie 300 przypadków dla asystenta wsparcia model główny zalicza 282 przypadki, a zapasowy 270, ale zapasowy myli się w 6 z 20 przypadków zwrotów, powołując się na nieaktualną politykę. Decyzja: podczas failoveru narzędzie zwrotów jest wyłączone, a pytania o zwroty trafiają do człowieka, reszta zostaje na modelu zapasowym.

Przećwicz trasę zapasową, zanim będzie potrzebna

Książka SRE Google'a ostrzega, że tryb awaryjny rzadko używany na co dzień to ścieżka kodu, która często nie działa, i radzi celowo ją ćwiczyć. Przy modelu zapasowym oznacza to regularne kierowanie do niego niewielkiej części ruchu lub ruchu cieniowego albo zaplanowane ćwiczenia, żeby wiadomo było, że klucze, limity, prompty i monitoring działają. Przebiegi cieniowe muszą izolować, zastępować atrapami lub blokować narzędzia zapisujące, żeby nigdy nie powtórzyły prawdziwego zwrotu, e-maila czy innej akcji biznesowej, niezależnie od tego, na co pozwalają warunki danych dostawcy. Sprawdź z góry, czy limity wywołań trasy zapasowej udźwigną ruch, który na nią trafi.

Powrót i modele wycofywane z użycia

Wracaj świadomie: gdy model główny przez uzgodniony czas działa stabilnie, stopniowo i obserwując te same sygnały. Zapisuj, które żądania obsłużyła która trasa, żeby przeglądy jakości i raporty kosztów były wiarygodne. Planowane zmiany wymagają tej samej dyscypliny. Polityka Anthropic dotycząca wycofywania modeli wyznacza na przykład modelom przestarzałym datę, po której żądania przestają działać, i zaznacza, że platformy partnerskie ustalają własne terminy. Traktuj zapowiedź wycofania jak zaplanowany failover i stosuj ten sam kontrakt. Praktyczny następny krok to spisanie kontraktu dla jednej funkcji i uruchomienie jej zestawu ewaluacyjnego na trasie zapasowej przed najbliższym wydaniem.

Inżynieria i architektura AI