Limit API nie dotyczy tylko twojego zadania. Co zrobi kolejka po 429?

O dziewiątej asystent przestaje odpowiadać. Każdy pracownik wysłał zaledwie jedno pytanie, więc nikt nie czuje się sprawcą zamieszania. W tle działa jednak import opisów, a drugi zespół porównuje dokumenty. Wszystkie zadania mogą korzystać z tego samego ograniczenia. Limit nie prowadzi osobnej księgowości dla czyjejś dobrej intencji.

Kod odpowiedzi 429 wymaga sprawdzenia przyczyny i zakresu ograniczenia. Czasem trzeba zmniejszyć tempo oraz poczekać, czasem wyczerpany przydział wymaga decyzji osoby zarządzającej usługą. Kolejka powinna odróżniać te sytuacje, pamiętać o przyjętych zadaniach i rozdzielać dostępne możliwości między rodzaje pracy. Sam automatyczny przycisk ponowienia tego nie załatwi.

Przyjrzyjmy się fikcyjnemu zespołowi wykorzystującemu jedno API, czyli interfejs programistyczny usługi, do krótkich pytań pracowników, przygotowania opisów katalogowych i okresowego przeglądu długich dokumentów. Zbadamy zasady obsługi wspólnego ograniczenia na sztucznych zleceniach. Nie podajemy limitów żadnego konta ani nie wykonujemy prób na produkcyjnej usłudze.

Czyj limit właśnie wykorzystujesz?

Rozpisz wszystkie procesy korzystające z danego projektu, organizacji i grupy ograniczeń dostawcy. Uwzględnij narzędzia uruchamiane ręcznie oraz harmonogramy, o których użytkownik asystenta może nie wiedzieć. Sama liczba otwartych okien czatu nie opisuje całego ruchu. Pomocna będzie lista właścicieli procesów i momentów ich zwykłego uruchamiania.

OpenAI w dokumentacji limitów opisuje ograniczenia na poziomie organizacji i projektu oraz różne jednostki, między innymi żądania i tokeny w czasie. Niektóre rodziny modeli współdzielą limit. Dlatego osobny użytkownik albo zmiana wariantu modelu nie muszą oznaczać osobnego przydziału.

Przy każdym ograniczeniu zapisz jednostkę, zakres i miejsce odczytu aktualnej konfiguracji. Limit żądań oraz limit przetwarzanego tekstu odpowiadają na różne pytania. Krótka seria wielu małych spraw i kilka długich dokumentów mogą dotrzeć do innej granicy. Nie przeliczaj wszystkich obciążeń na jedną liczbę „zapytań AI” bez opisu.

Oddziel dopuszczalne maksimum od tempa, które rozwiązanie rzeczywiście utrzymuje przy waszym materiale. Kontrola czasu AI pod obciążeniem pomaga sprawdzić tę drugą rzecz. Odczyt limitu w panelu nie dowodzi, że każde żądanie mieszczące się w jego zakresie zakończy się równie szybko.

W firmie ustalmy, że import katalogu może czekać, a pracownik przyjmujący rozmowę z klientem potrzebuje krótkiej informacji w bieżącej obsłudze. To różnica zastosowania, którą powinien znać właściciel kolejki. Nie nadawaj jednak priorytetu wyłącznie stanowisku zgłaszającego lub głośności jego prośby. Reguła powinna dotyczyć uzgodnionego celu pracy.

Sprawdź, czy ograniczenie jest rzeczywiście wspólne. Oddzielne klucze mogą ułatwiać przypisanie ruchu, lecz nie muszą tworzyć niezależnej pojemności. Nie proponuj mnożenia kluczy jako sposobu obejścia reguł dostawcy. Najpierw zrozum właściwy zakres i przygotuj pracę zgodną z dostępnymi możliwościami.

Czy 429 ustąpi po odczekaniu?

Zachowaj kod, opis i istotne informacje odpowiedzi w zakresie potrzebnym do diagnozy. Sam numer statusu może nie wystarczyć. W widoku operatora rozróżnij chwilowe ograniczenie tempa od wyczerpanego przydziału lub warunku wymagającego działania administratora. Dla pracownika przygotuj prosty komunikat o losie jego zadania, bez kopiowania poufnych szczegółów konta.

Anthropic opisuje w dokumentacji limitów zarówno ograniczenie tempa, jak i 429 po osiągnięciu określonego miesięcznego przydziału wydatków. W tym drugim przypadku samo ponawianie nie przywraca dostępu. Dokumentacja rozróżnia również inne ustawiane limity; trzeba czytać konkretną odpowiedź, zamiast zakładać jeden powód dla całego numeru statusu.

W naszej kolejce chwilowo odroczone zadanie powinno zachować swój identyfikator i znany powód oczekiwania. Przy ograniczeniu wymagającym działania człowieka wybierz inną ścieżkę: zatrzymanie automatycznych prób, powiadomienie właściwego właściciela i decyzję o dalszej obsłudze. Nie pozwalaj, żeby niewykonalne zadanie przez cały dzień wracało jako najnowsze pilne zlecenie.

Jeżeli odpowiedź podaje poprawny Retry-After, czyli czas oczekiwania przed ponowieniem, zastosuj reguły konkretnej integracji. Nie obiecuj użytkownikowi dokładnej chwili uzyskania wyniku na podstawie samej chwili kolejnej dozwolonej próby. Wtedy pojawi się możliwość ponowienia, ale dalsze wykonanie nadal może potrwać lub spotkać następne ograniczenie.

Brak takiej wskazówki również wymaga ustalonego zachowania. Osoba odpowiedzialna za integrację powinna sprawdzić obsługiwany mechanizm wydłużania odstępów, niewielkiego rozproszenia prób i granic całego oczekiwania. Nie dobieraj sekund wyłącznie po to, żeby komunikat błędu zniknął podczas demonstracji. Zachowaj uzasadnienie konfiguracji oraz sposób zatrzymania.

Zajrzyj do ustawień używanej biblioteki klienckiej. Część prób może być już wykonywana automatycznie pod poziomem aplikacji. W przywołanej dokumentacji OpenAI opisano potrzebę uwzględnienia ponowień SDK oraz limitowania prób i całego czasu. Dwie nakładające się pętle potrafią wysłać więcej żądań, niż sugeruje licznik widoczny operatorowi.

Rozpoznawanie tej samej operacji rozwija kontrola duplikatów i ponowień. Tutaj trzeba także ustalić tempo całej grupy. Rozsądne zachowanie jednej próby może przestać być rozsądne, kiedy kilkadziesiąt zadań budzi się w tym samym momencie i każde niezależnie próbuje odzyskać dostęp.

Dlatego do odbioru włącz dwa procesy, które osobno mieszczą się w uzgodnionym tempie, ale razem konkurują o ten sam przydział. Sprawdź, gdzie koordynuje się ich wysyłanie i skąd operator zna wspólny stan. Dwa poprawne lokalne liczniki mogą nie wystarczać do oceny całości. To można najpierw przećwiczyć na kontrolowanych odpowiedziach przygotowanych w środowisku testowym, bez celowego wyczerpywania rzeczywistego limitu. Taka próba sprawdza logikę kolejki; nie potwierdza jeszcze osiągów ani limitów usługi dostawcy.

Co kolejka obiecuje osobie czekającej?

Przyjęte zadanie powinno mieć rozpoznawalny stan. „Czeka na możliwość wykonania” opisuje coś innego niż „przetwarzamy dokument”. Użytkownik potrzebuje wiedzieć, czy może odejść, gdzie wróci do wyniku i co zrobi anulowanie. Nie powinien zwiększać kolejki przez ponowne wysyłanie tej samej prośby wyłącznie dlatego, że ekran zamilkł.

Ustal, jakie dane z chwili zlecenia pozostają związane z zadaniem. Dokument może zmienić się podczas oczekiwania. Przy wykonaniu trzeba rozpoznać, czy nadal pracujesz na uzgodnionej wersji, czy potrzebna jest aktualizacja albo nowa decyzja. Długa kolejka nie powinna po cichu zmieniać zakresu wcześniej przyjętej pracy.

Termin przydatności również ma znaczenie. Odpowiedź potrzebna podczas porannej rozmowy może być bezużyteczna wieczorem. Zdefiniuj warunek wygaśnięcia albo przekazania do innej obsługi, zamiast wykonywać każde zaległe zlecenie za wszelką cenę. Zachowaj powód zakończenia, aby licznik nie przedstawiał go jako gotowego wyniku.

Gdy zadanie zdążyło wykonać wcześniejsze operacje w innych usługach, zatrzymanie przed kolejnym wywołaniem AI nie cofa ich. Przejrzyj częściowe wykonanie agenta w kilku systemach, zanim zaplanujesz rozpoczęcie całego przebiegu od nowa. Kolejka żądań jest częścią szerszej sprawy.

Sprawdź również powrót aplikacji po restarcie. Czy przyjęte zadania nadal istnieją? Czy zachowują wiek i liczbę prób? Czy po wznowieniu nie uruchamiają się wszystkie jednocześnie? To scenariusze odbioru używanego rozwiązania, a nie założenia wynikające z samej nazwy narzędzia kolejkowego.

W kolejce wyjątków automatyzacji umieść przypadki wymagające rozstrzygnięcia. Zwykłe kontrolowane oczekiwanie na możliwość wykonania nie musi od razu stawać się ręcznym incydentem. Potrzebujesz jednak warunku, po którym opóźnienie lub przyczyna przenoszą sprawę do odpowiedzialnej osoby.

Jak nie zostawić mniej pilnych zadań na zawsze?

W fikcyjnej firmie krótkie pytania mają pierwszeństwo przed importem katalogu. Jeżeli jednak przez cały dzień napływają nowe pytania, import może nigdy nie dostać swojej części możliwości. Zespół będzie sprawnie odpowiadał na bieżąco i równocześnie korzystał z coraz starszych opisów. To skutek reguły kolejności, nie dowód lenistwa procesu wsadowego.

Microsoft w opisie kolejki priorytetowej wskazuje ryzyko stałego odsuwania niższych priorytetów i potrzebę uwzględnienia ich obsługi. Omawia między innymi podnoszenie znaczenia starszych pozycji. To możliwy mechanizm, którego dopasowanie trzeba ocenić dla danego procesu.

Ustal więc regułę, która daje ważnym sprawom pierwszeństwo, a pozostałym realną drogę do zakończenia. Może to być uzgodniona część możliwości dla importu albo przeznaczone dla niego okno. Nie podajemy uniwersalnej proporcji. Wybór powinien wynikać z terminów, skutków opóźnienia i rzeczywistego napływu zadań.

Odbierz regułę na dwóch grupach sztucznych zleceń. Podtrzymuj napływ krótkich pytań i obserwuj, czy starsze pozycje importu wciąż przesuwają się do wykonania. Pokaż czas najstarszego zadania w każdej grupie, liczbę zakończeń i odrzuceń. Sama łączna liczba obsłużonych żądań może ukryć grupę, która cały czas stoi.

Nie ustawiaj priorytetu tylko według wielkości zadania. Długi dokument może dotyczyć pilnego uzgodnienia, a krótkie pytanie eksperymentu, który może poczekać. Potrzebna jest informacja o celu i regułach procesu. Gdy każdy użytkownik może dowolnie oznaczyć własne zadanie jako pilne, priorytet szybko staje się domyślną dekoracją.

Porównaj także pracę po odblokowaniu dostępu. Nie uruchamiaj bez kontroli całej zaległości w jednym momencie, jeśli właśnie taki skok wywoływał ograniczenie. Sprawdź stopniowy powrót w granicach uzgodnionych z właścicielem środowiska. Zaległe sprawy zachowują swój kontekst, lecz część mogła się już zdezaktualizować.

Decyzję o wznowieniu po ograniczeniu wymagającym interwencji przypisz właściwej osobie. Operator powinien wiedzieć, czy usunięto konkretną przyczynę, czy tylko minął czas od ostatniej próby. Zapisz podstawę powrotu i grupy zadań, które obejmuje. Nie trzeba w tym miejscu ujawniać szczegółów rozliczenia wszystkim pracownikom. Wystarczy potwierdzony stan dostępności i uzgodniona droga kontynuacji. Pozwala to oddzielić sprawne wznowienie od zbiorowego sprawdzania na ślepo, czy tym razem uda się coś wysłać.

Po czym poznasz, że obsługa ograniczeń działa?

Próba powinna objąć chwilowe ograniczenie, warunek wymagający decyzji administratora, dwa konkurujące rodzaje pracy i powrót po przerwie. Dodaj wycofanie zadania oraz zmianę materiału w czasie oczekiwania. Dla każdego przypadku zapisz oczekiwany los sprawy, nie tylko liczbę ponowień.

Połącz wynik z całkowitym kosztem procesu AI. Dłuższa kolejka może oznaczać pracę ręczną, utratę przydatności odpowiedzi i obsługę wyjaśnień. Tych kosztów nie pokazuje sama opłata za skuteczne wywołania. Nie przeliczaj jednak hipotetycznej zaległości na finansową stratę bez właściwych danych.

Do przeglądu w Aeneia Audit przygotuj mapę wspólnych procesów, odczyt konfiguracji bez sekretów i kilka kontrolowanych przypadków odmowy. Wtedy można zobaczyć, gdzie potrzebne jest oczekiwanie, gdzie decyzja człowieka, a gdzie zmiana zasad podziału pracy. Limit pozostanie granicą dostawcy; firma przestanie traktować każde 429 jak zachętę do jeszcze szybszego naciskania.