Niezawodny routing API LLM: przekroczenia limitu czasu, ponowne podjęcie próby i awaria modelu bez regresji semantycznej

Żądanie zastępcze nie powiedzie się tylko dlatego, że inny model zwrócił HTTP 200. Zastąpienie może przekroczyć pierwotny budżet opóźnień, pominąć wymagane pola JSON, wywołać inne narzędzie lub wygenerować odpowiedź o zasadniczo odmiennej semantyce. Niezawodny routing API LLM wymaga zatem czegoś więcej niż uporządkowanej listy modeli: wymaga kontraktu, klasyfikatora niepowodzeń, zasad ograniczonych prób i walidacji przed akceptacją.

Główna zasada jest prosta: ponów próbę tylko wtedy, gdy awaria jest prawdopodobnie przejściowa, a wycofaj się tylko wtedy, gdy następna trasa nadal może spełnić pierwotny kontrakt żądania.

Określ umowę routingu przed wyborem modeli

Zacznij od opisania, co musi zapewnić skuteczna odpowiedź. Ta umowa routingu powinna nadawać się do odczytu maszynowego i być dołączona do każdego obciążenia lub klasy żądań.

{
  "obciążenie": "wyciąg_faktury",
  „modalności”: [„tekst”, „obraz”],
  „max_input_tokens”: 50000,
  „requires_tools”: fałsz,
  „strukturalne_wyjście”: {
    „wymagane”: prawda,
    "schema_id": "faktura-v3",
    „ścisłe”: prawda
  },
  „allowed_model_classes”: [„ekstrakcja dokumentu”],
  „max_cost_usd”: 0,08,
  „termin_terminu”: 8000

Umowa powinna obejmować wymagane modalności, pojemność kontekstu, wsparcie narzędzi, zachowanie ustrukturyzowanych wyników, akceptowalne klasy modeli, maksymalny koszt i kompleksowy termin realizacji. W razie potrzeby dodaj ograniczenia specyficzne dla aplikacji, takie jak dozwolone regiony, minimalna długość wyjściowa lub wymagany powód zakończenia.

Zalecenie: utrzymuj oddzielne, przetestowane grupy tras dla zwykłego tekstu, danych wyjściowych ograniczonych schematem, użycia narzędzi, wizji i żądań o długim kontekście. Model będący akceptowalnym zastępczym tekstem nie jest automatycznie akceptowalnym zastępczym narzędziem do wywoływania narzędzi lub wprowadzania obrazu.

Sklasyfikuj awarię przed podjęciem działań

Błędy uwierzytelniania, źle sformułowane żądania, limity szybkości i awarie serwerów wymagają różnych reakcji. Traktowanie każdej nieudanej odpowiedzi jako możliwej do ponowienia marnuje pojemność i może ukryć defekty.

Fakt: nieudane żądania z ograniczoną szybkością nadal mogą wliczać się do limitów dostawcy. Agresywne, natychmiastowe ponowne próby mogą zatem pogłębić ograniczanie przepustowości zamiast go rozwiązać. Ponowne próby zużywają również dodatkową pojemność podczas awarii, a zasady ponawiania prób w kilku warstwach aplikacji mogą zwielokrotnić wynikowe obciążenie.

Zalecenie: pozwól, aby jedna warstwa była właścicielem ponownych prób generowania modelu. W typowej architekturze brama interfejsu API AI jest właściwym właścicielem, ponieważ monitoruje stan trasy, historię prób, opóźnienia i koszty. Jeśli to możliwe, wyłącz automatyczne ponawianie prób u klientów niższego poziomu lub policz je jawnie w tym samym budżecie prób.

Wydaj jeden kompleksowy budżet na opóźnienia

Limity czasu oczekiwania na każdą próbę są niewystarczające. Trzy próby z pięciosekundowym limitem czasu mogą zamienić zamierzoną pięciosekundową operację w piętnastosekundową reakcję, zanim zostaną uwzględnione wycofywanie i sprawdzanie poprawności.

Zapisz bezwzględny termin, w którym żądanie wpłynie do bramki. Przed każdą próbą oblicz pozostały czas:

pozostałe = ostateczny termin - bieżący_godzina
wymagane = connect_allowance + Generation_allowance + validation_allowance
jeśli pozostałe < wymagane:
    stop_without_launching_another_attempt

W przypadku terminu ośmiosekundowego rozsądny przydział początkowy może zarezerwować 300 ms na pracę bramy i końcową weryfikację, maksymalnie 4,5 sekundy dla trasy głównej i zachować około 3,2 sekundy na jedno rozwiązanie awaryjne. Wartości te stanowią przykład, a nie punkt odniesienia. Muszą one pochodzić ze zmierzonych rozkładów opóźnień dla rzeczywistych dostawców, modeli, regionów i rozmiarów wyjściowych.

Użyj ograniczonego wykładniczego wycofywania z jitterem w przypadku przejściowych ponownych prób:

opóźnienie = losowe(0, min(cap, base * 2^retry_index))

Wskazówki dostawcy dotyczące ponownej próby, takie jak wartość ponownej próby, powinny mieć pierwszeństwo, jeśli mieszczą się w pozostałym terminie. Zatrzymaj się po niewielkiej liczbie prób. Typową zasadą jest jedna próba podstawowa i jedna próba awaryjna, z opcjonalnym ponowieniem tej samej trasy tylko w przypadku wcześniejszej awarii połączenia, która nie mogła wygenerować płatnych wyników.

Kompromis: sekwencyjne zastępowanie poprawia dostępność, ale zwiększa opóźnienie końcowe. Żądania równoległe lub zabezpieczone mogą zmniejszyć opóźnienia podczas spowolnień, ale zużywają więcej pojemności i mogą wiązać się z opłatami za wiele pomyślnych generacji. Zabezpieczanie powinno ograniczać się do obciążeń krytycznych z powodu opóźnień i wolnych od skutków ubocznych, z możliwością anulowania i kontrolą kosztów.

Wybierz rezerwy według możliwości, a nie rangi

Tabela rezerwowa powinna kodować zgodność, a nie globalną kolejność preferencji. Filtruj potencjalne trasy pod kątem umowy, zanim weźmiesz pod uwagę stan, opóźnienie lub cenę.

kandydaci = trasy
  .filter(supports_required_modalities)
  .filter(context_limit >= szacowany_rozmiar_wejściowy)
  .filter(supports_required_tools)
  .filter(supports_requested_schema_mode)
  .filter(klasa_modelu w klasach dozwolonych_modeli)
  .filter(szacowany_koszt <= pozostały_budżet_kosztów)
  .filter(not_tymczasowo_suppressed)
wybrane = ranga (kandydaci, stan zdrowia, opóźnienie, koszt)

Obsługa wyników strukturalnych zasługuje na wyraźne przetestowanie. Nawet jeśli dwie trasy reklamują generowanie ograniczone schematem, mogą obsługiwać różne podzbiory schematu JSON lub inaczej interpretować przypadki brzegowe. Modele obsługujące narzędzia mogą również różnić się wyborem narzędzi, konstrukcją argumentów i zachowaniem wywołań równoległych.

Fakt: zmiana rodzin modeli może zachować dostępność transportu, zmieniając jednocześnie styl, jakość rozumowania, zachowania związane z bezpieczeństwem, tokenizację i wybór narzędzi. Sukces protokołu HTTP nie jest dowodem równoważności semantycznej.

Przewidywanie: w miarę rozszerzania się katalogów modeli zasady routingu produkcji będą w coraz większym stopniu wykorzystywać wersjonowane profile możliwości i testy akceptacyjne specyficzne dla obciążenia zamiast statycznych list modeli. Traktuj to jako kierunek projektowania, a nie gwarancję zachowania dostawcy.

Zatwierdź odpowiedź przed jej zaakceptowaniem

Przeprowadź każdą odpowiedź, łącznie z odpowiedzią główną, tym samym potokiem akceptacji. Walidacja powinna nastąpić, zanim wynik zostanie zapisany w pamięci podręcznej, wewnętrznie rozliczony jako pomyślny lub przekazany do wykonawcy narzędzia.

1. Potwierdź zakończenie transportu i można przeanalizować kopertę odpowiedzi.
2. Sprawdź przyczynę zakończenia i odrzuć obcięcie, jeśli wymagane jest pełne wyjście.
3. Sprawdź uporządkowane dane wyjściowe pod kątem oryginalnego schematu.
4. Sprawdź wymagane pola, wartości wyliczeniowe i niezmienniki aplikacji.
5. Zezwalaj tylko na zarejestrowane nazwy narzędzi i sprawdzaj argumenty w odniesieniu do każdego schematu narzędzia.
6. Zastosuj kontrole semantyczne specyficzne dla obciążenia tam, gdzie fałszywa akceptacja byłaby kosztowna.

W przypadku wyodrębniania faktur kontrole semantyczne mogą wymagać nieujemnej sumy, obsługiwanego kodu waluty i sum pozycji w ramach wyraźnie określonej tolerancji. Do klasyfikacji wymagana jest etykieta z dozwolonego zestawu. Do generowania kodu odpowiednie może być parsowanie lub kompilacja. Kontrole te nie potwierdzają jakości, ale zapobiegają traktowaniu przewidywalnych naruszeń umowy jako sukcesów.

Nie naprawiaj po cichu każdej źle sformułowanej odpowiedzi. Dopuszczalna może być normalizacja deterministyczna, taka jak usuwanie nieszkodliwych otaczających białych znaków. Odgadnięcie brakujących pól finansowych lub przepisanie argumentów narzędzia zmienia znaczenie modelu i powinno spowodować odrzucenie lub weryfikację manualną.

Oddziel ponowne próby generowania od skutków ubocznych

Żądania LLM często korzystają z protokołu HTTP POST, który nie jest z natury idempotentny. Co ważniejsze, odpowiedź modelowa może zainicjować akcję zewnętrzną, taką jak obciążenie metody płatności, wysłanie wiadomości, utworzenie biletu lub modyfikacja infrastruktury. Ponowienie próby wygenerowania i odtworzenie tej akcji to osobne decyzje.

Przypisz identyfikator operacji na granicy aplikacji i identyfikator próby do każdego wywołania modelu. Utrwalaj stan wykonania narzędzia względem deterministycznego klucza, takiego jak:

klucz_wykonania = identyfikator_operacji + nazwa_narzędzia + hash_argumentów kanonicznych

Przed wykonaniem narzędzia sprawdź, czy dany klucz oczekuje na wykonanie, został ukończony lub zakończył się niepowodzeniem. Zwróć zapisany wynik, aby zakończyć wykonanie, zamiast uruchamiać je ponownie. W przypadku operacji, których argumenty mogą zgodnie z prawem ulec zmianie, wymagaj zatwierdzenia na poziomie aplikacji lub nowego identyfikatora operacji.

Niejednoznaczny limit czasu wymaga specjalnego postępowania. Jeśli połączenie nie powiedzie się po przesłaniu żądania, brama może nie wiedzieć, czy doszło do generowania. Klucz idempotencji obsługiwany przez dostawcę może pomóc, jeśli jest dostępny. W przeciwnym razie zarejestruj wynik jako nieznany i zastosuj zasady odtwarzania specyficzne dla obciążenia, zamiast zakładać, że nic się nie wydarzyło.

Pomijaj niezdrowe trasy i ujawniaj każdą próbę

Wyłącznik automatyczny lub tymczasowa przerwa w działaniu uniemożliwiają każdemu nowemu żądaniu ponowne odnalezienie tej samej uszkodzonej trasy. Otwórz obwód po osiągnięciu określonego progu błędu lub kolejnych uszkodzeń, a następnie dopuść ograniczone sondy w stanie półotwartym. Dostosuj progi według trasy i klasy awarii, aby zniekształcone żądanie klienta nie mogło sprawić, że zdrowy model będzie wyglądał na niedostępny.

Rejestruj jedno zdarzenie na poziomie żądania i jedno zdarzenie na próbę. Przydatne pola obejmują identyfikator operacji, identyfikator próby, wybranego dostawcę i model, klasę awarii, kod stanu, opóźnienie, liczbę tokenów, szacowany koszt, przyczynę awarii, wynik walidacji, stan obwodu i wynik końcowy. Redaguj lub mieszaj podpowiedzi, dane wyjściowe i argumenty narzędzi zgodnie z ich czułością i wymaganiami dotyczącymi przechowywania.

Przydatne wskaźniki operacyjne obejmują wskaźnik awaryjności, liczbę prób na zrealizowane żądanie, wskaźnik wyczerpania terminu, wskaźnik odrzucenia w ramach walidacji, niejednoznaczne wyniki, koszt zaakceptowanej odpowiedzi i opóźnienia według ostatecznej trasy. Rosnący wskaźnik powodzenia protokołu HTTP w połączeniu ze wzrostem współczynnika odrzuceń podczas walidacji stanowi ostrzeżenie, że dostępność transportu maskuje niepowodzenie umów.

Lista kontrolna wdrożenia produkcyjnego

• Zdefiniuj wersjonowany kontrakt routingu dla każdej klasy obciążenia.
• Mapuj błędy dostawcy na kategorie trwałe, przejściowe, niezgodne, z nieprawidłową odpowiedzią i niejednoznaczne.
• Wybierz jednego właściciela ponownych prób i ogranicz liczbę prób.
• Przekaż bezwzględny termin poprzez bramę, klienta dostawcy, walidację i wykonanie narzędzia.
• Twórz sprawdzone pod kątem możliwości grupy rezerwowe zamiast jednego globalnego łańcucha modeli.
• Weryfikuj schematy, wywołania narzędzi, przyczyny zakończenia i niezmienniki domeny.
• Deduplikuj efekty uboczne za pomocą kluczy operacyjnych i wykonawczych.
• Dodaj tłumienie tras z ograniczonymi sondami półotwartymi.
• Rejestruj opóźnienia na poziomie próby, tokeny, koszty, niepowodzenia i wyniki akceptacji.
• Przekroczenia limitu czasu wstrzykiwania, 429, wybrane błędy 5xx, zniekształcony JSON, przepełnienie kontekstu i powolne pomyślne uruchamianie.

Zacznij od trasy głównej i jednej zgodnej trasy zastępczej dla pojedynczego obciążenia niskiego ryzyka. Przed rozszerzeniem zasad porównaj jakość, opóźnienia i koszty zaakceptowanej odpowiedzi. Celem nie jest najwyższy możliwy wskaźnik rezerw. Jest to system ograniczony, który albo zwraca odpowiedź zgodną z pierwotną umową, albo wyraźnie zawodzi, zanim spowoduje zdublowanie pracy lub uszkodzenie semantyczne.

Powiązana lektura

• wcześniejsza uwaga dotycząca testowania API
• poprzednia Artykuł w języku angielskim