Funkcja oparta na sztucznej inteligencji może być przydatna, a jednocześnie zbyt wolna lub kosztowna w przypadku konkretnej operacji. Ryzyko pojawia się wtedy, gdy każde wywołanie traktuje się tak, jakby miało takie same wymagania: streszczenie tekstu w tle nie wpływa na działanie systemu tak jak odpowiedź na zapytanie podczas płatności. Aby kontrolować koszt i opóźnienie AI w PHP, warto określić budżet operacyjny dla każdego przypadku użycia i z góry zdecydować, co się stanie po jego wyczerpaniu.
Budżet ten nie jest obietnicą jakości ani gwarancją, że dostawca odpowie w określonym czasie. To zestaw limitów i decyzji produktowych, który pozwala ograniczyć wpływ, poinformować użytkownika i utrzymać zachowanie aplikacji pod kontrolą.
Inny budżet dla każdej operacji
Budżet operacyjny obejmuje zasoby, które może zużyć funkcja, oraz czas, przez jaki warto czekać. Może określać maksymalny czas trwania, limit szacowanego kosztu, liczbę prób, ilość przetwarzanego tekstu albo połączenie tych ograniczeń. Powinien być powiązany z rozpoznawalną operacją w produkcie, a nie stanowić abstrakcyjnej konfiguracji wspólnej dla wszystkich wywołań.
Na przykład opcjonalna sugestia w panelu może zostać pominięta, jeśli jej przygotowanie trwa zbyt długo. Jeśli jednak funkcja jest częścią kluczowego procesu, być może trzeba zapewnić alternatywę umożliwiającą przejście przez ten proces bez AI. Zadanie klasyfikacji wsadowej może obsługiwać kolejkę i status oczekujący, podczas gdy odpowiedź interaktywna wymaga bardziej rygorystycznego limitu czasu oczekiwania.
Aby dobrać limity, najpierw ustal, jakiego wyniku potrzebuje użytkownik, czy jest on niezbędny w danym momencie i co się stanie, jeśli będzie niedostępny. Oddziel też budżet od oceny jakości: szybka i tania odpowiedź może być błędna, a prawidłowa odpowiedź może nadejść zbyt późno, by była przydatna. Każdy z tych aspektów wymaga osobnych pomiarów i kryteriów.
Najpierw pomiary, potem progi
Bez wartości bazowych limity są tylko przypuszczeniami. Rejestruj metryki według rodzaju operacji i obserwuj, jak zmieniają się wraz z wolumenem, rozmiarem danych wejściowych i warunkami użytkowania. Warto mierzyć co najmniej całkowity czas trwania, czas do uzyskania pierwszego użytecznego wyniku, jeśli ma to zastosowanie, częstotliwość użycia i szacowany koszt. W przypadku operacji asynchronicznych rejestruj także czas w kolejce i czas przetwarzania.
Powiąż każdy pomiar z identyfikatorem operacji, wynikiem i niesensytywnymi danymi kontekstowymi, takimi jak przybliżony rozmiar żądania lub tryb wykonania. Unikaj zapisywania tekstu użytkownika, sekretów, danych osobowych lub pełnych odpowiedzi, jeśli nie są potrzebne do diagnozowania problemów. Gdy konieczne jest zbadanie konkretnego przypadku, zastosuj odpowiednie mechanizmy kontroli dostępu, retencji i minimalizacji danych.
Szacowany koszt powinien opierać się na informacjach dostępnych dla używanej usługi i uwzględniać jej ograniczenia. Nie utożsamiaj go z potwierdzoną opłatą: ceny, naliczane jednostki i składniki podlegające rozliczeniu mogą się różnić. Jeśli aplikacja nie potrafi wiarygodnie obliczyć kosztu przed wywołaniem, zastosuj alternatywne mechanizmy, takie jak limity częstotliwości, maksymalny rozmiar, limity dla użytkownika lub monitorowanie łącznego zużycia.
Przekładanie budżetu na weryfikowalne limity
Określ, gdzie stosuje się poszczególne mechanizmy. Limit na żądanie zapobiega nadmiernemu wydłużeniu pojedynczego wykonania lub zużyciu zbyt dużych zasobów. Limit dla użytkownika lub konta ogranicza wielokrotne użycie. Limit dla procesu chroni zadanie obejmujące wiele operacji. Aby kontrolować łączne wydatki, monitoruj również zagregowane zużycie; limit indywidualny nie zapobiegnie przekroczeniu budżetu systemu przez wiele jednoczesnych żądań.
Zdecyduj też, jak mają działać ponowne próby. Automatyczne powtórzenie żądania może podwoić koszt lub zwiększyć opóźnienie, szczególnie jeśli nie wiadomo, czy usługa zdążyła je przetworzyć. Określ liczbę dozwolonych prób, błędy, przy których można je ponowić, oraz czas oczekiwania. Jeśli jest to obsługiwane i ma zastosowanie, używaj kluczy idempotencji, aby uniknąć zduplikowanych efektów w operacjach zmieniających dane.
Po wyczerpaniu limitu można zatrzymać żądanie, ograniczyć jego zakres, odroczyć je do kolejki lub przekazać do weryfikacji przez człowieka. Wybór zależy od przypadku użycia. Częściowa odpowiedź jest akceptowalna tylko wtedy, gdy interfejs wyraźnie ją oznacza, a wynik pozostaje bezpieczny i przydatny. Jeśli zadanie jest wrażliwe lub nie dopuszcza niepełnych wyników, lepiej może być nie wyświetlać wygenerowanej odpowiedzi.
Stosowanie mechanizmów kontroli w warstwie integracyjnej PHP
Scentralizuj wywołania zewnętrzne w warstwie integracyjnej, która przyjmuje operację i jej budżet, stosuje odpowiednie mechanizmy kontroli i zwraca jawny wynik. Dzięki temu logika biznesowa nie zależy bezpośrednio od dostawcy ani nie obsługuje timeoutów i błędów w różny sposób w poszczególnych częściach aplikacji.
Poniższy fragment wymaga PHP 8.0 lub nowszego, ponieważ wykorzystuje promocję właściwości w konstruktorze i argumenty nazwane. To częściowy przykład: sprawdza rozmiar danych wejściowych i przekazuje klientowi limit czasu, ale nie implementuje limitów wykorzystania, limitów wydatków ani kolejki. Te mechanizmy należy dodać osobno, stosownie do potrzeb aplikacji.
final class AiOutcome
{
public function __construct(
public string $status,
public ?string $content = null,
public ?string $reason = null,
) {}
}
function runAiOperation(
AiClient $client,
string $input,
int $timeoutSeconds
): AiOutcome {
if (strlen($input) > 12000) {
return new AiOutcome('rejected', reason: 'input_limit');
}
try {
$response = $client->generate($input, $timeoutSeconds);
return new AiOutcome('completed', $response->text);
} catch (TimeoutException $e) {
return new AiOutcome('timed_out', reason: 'timeout');
} catch (ProviderException $e) {
return new AiOutcome('unavailable', reason: 'provider_error');
}
}Klient i wyjątki zależą od wybranej integracji. W środowisku produkcyjnym ustaw limit czasu również w kliencie HTTP i sprawdź rozmiar przed wysłaniem danych. Status timed_out oznacza, że upłynął limit czasu oczekiwania na żądanie; nie oznacza, że zadanie trafiło do kolejki ani że będzie kontynuowane. Zwracaj status deferred tylko wtedy, gdy aplikacja zapisała zadanie w kolejce i dysponuje procesem, który może je wznowić i przekazać wynik.
Aby uzupełnić warstwę kontroli, stosuj limity częstotliwości lub limity wykorzystania oparte na liczniku współdzielonym między procesami i monitoruj łączne wydatki. Jeśli przed każdym wywołaniem trzeba egzekwować limit kosztów, oblicz szacowane zużycie dla żądania i porównaj je z dostępnym budżetem; jeśli nie da się go wiarygodnie oszacować, zastosuj alternatywne limity i alerty dotyczące zużycia. Limity współdzielone nie powinny zależeć wyłącznie od pamięci pojedynczego żądania PHP.
Zwracaj odrębne statusy, takie jak: zakończone, odrzucone z powodu limitu, przekroczony limit czasu oczekiwania lub niedostępne. Dzięki temu warstwa biznesowa może zdecydować, co wyświetlić, bez mylenia wolnej odpowiedzi z odpowiedzią niskiej jakości ani limitu operacyjnego z awarią dostawcy.
Projektowanie jasnej i użytecznej degradacji
Degradacja nie oznacza ukrywania błędu ani przedstawiania alternatywnego wyniku jako równoważnego. Chodzi o zachowanie zrozumiałego doświadczenia, gdy funkcja nie może wykonać zadania. W przypadku opcjonalnego działania może wystarczyć informacja, że sugestia jest niedostępna, wraz z możliwością kontynuowania. Przy długim zadaniu można pokazać, że oczekuje na wykonanie, i udostępnić jego status, o ile aplikacja potrafi wiarygodnie go utrzymywać.
Jeśli zakres zadania można ograniczyć, wyjaśnij, co pominięto. Jeśli zadanie przekazano do weryfikacji, nie sugeruj, że wynik został już zatwierdzony. A jeśli używana jest deterministyczna alternatywa, taka jak istniejąca reguła biznesowa, wyjaśnij jej rolę, gdy różnica wpływa na decyzję użytkownika. Unikaj komunikatów obiecujących późniejsze dostarczenie wyniku, jeśli nie ma kolejki i procesu, które mogą tę obietnicę spełnić.
Fallback na wypadek awarii różni się od kontroli budżetu: uruchamia się w sytuacjach takich jak niedostępność usługi, błędy sieci lub nieprawidłowe odpowiedzi. Budżet może zostać wyczerpany nawet wtedy, gdy usługa działa prawidłowo. Oba mechanizmy należy zdefiniować i przetestować osobno, dobierając statusy i komunikaty do każdej przyczyny.
Testowanie, alerty i korekty oparte na danych
Testuj progi przy reprezentatywnym obciążeniu i w niekorzystnych scenariuszach: duże dane wejściowe, powtarzane żądania, powolne odpowiedzi, współbieżność, błędy dostawcy i limity wykorzystania. Sprawdź, co widzi użytkownik i co jest rejestrowane. Uwzględnij przypadki anulowania i zweryfikuj, czy zatrzymane żądanie nie zużywa niepotrzebnie zasobów w tle.
Skonfiguruj alerty dotyczące anomalii operacyjnych: wzrostu opóźnień, większej liczby odrzuconych żądań, wzrostu szacowanych wydatków lub gromadzenia się zadań oczekujących. Alert powinien wskazywać warunek wymagający zbadania, a nie zastępować analizę. Grupuj dane według operacji, aby problematyczny przepływ nie zniknął w ogólnej średniej.
Weryfikuj limity, gdy zmieniają się wolumen, założenia dotyczące produktu, rozmiar danych wejściowych lub integracja techniczna. Nie zwiększaj ich tylko po to, by pozbyć się alertu: najpierw ustal, czy problem wynika z błędnie określonych oczekiwań, nieprzewidzianego obciążenia, awarii sieci czy operacji wymagającej przeprojektowania.
Lista kontrolna przed wdrożeniem na produkcję
- Cel: operacja ma określony przypadek użycia, użytkownika i alternatywę na wypadek braku odpowiedzi AI.
- Pomiary: rejestrowane są czas trwania, częstotliwość, wynik i szacowany koszt, bez zbędnego gromadzenia danych wrażliwych.
- Limity: obowiązują odpowiednie ograniczenia dla żądania oraz, gdy ma to zastosowanie, dla użytkownika, procesu i systemu.
- Zachowanie: określono zasady ponawiania prób, anulowania, obsługi kolejki i reakcji na każdy próg.
- Doświadczenie użytkownika: statusy i komunikaty rozróżniają oczekiwanie, odrzucenie z powodu limitu i awarię usługi.
- Utrzymanie: istnieją testy i alerty, a za weryfikację limitów odpowiada konkretna osoba lub zespół.
Kontrolowanie kosztu i opóźnienia AI w PHP nie polega na wyborze jednego limitu czasu oczekiwania dla całej aplikacji. Chodzi o powiązanie każdego limitu z konkretną potrzebą, zmierzenie jego wpływu i wcześniejsze ustalenie, jaka alternatywa pozwoli zachować zrozumiałość i bezpieczeństwo produktu, gdy funkcja nie będzie mogła zostać ukończona.
