Funkcja AI zintegrowana z aplikacją PHP może działać zbyt długo, być niedostępna albo zwrócić wynik nieprzydatny w danym procesie. Problemu nie rozwiąże traktowanie każdej odpowiedzi jako prawidłowej ani ponawianie żądania bez końca: obie decyzje mogą negatywnie wpłynąć na doświadczenie użytkownika, dane i koszty. Fallback dla integracji AI w PHP określa, co zrobi system, gdy zależność zawiedzie, oraz które operacje nie powinny być kontynuowane bez akceptowalnej odpowiedzi.
Właściwa alternatywa zależy od wpływu danej funkcji. Sugestię tekstową można tymczasowo pominąć; decyzji dotyczącej płatności, uprawnienia lub aktualizacji danych nie należy podejmować na podstawie niekompletnych ani domniemanych informacji. Celem jest przewidywalne działanie, a nie ukrywanie wszystkich błędów.
Określ, co uznajesz za błąd
Zanim zaimplementujesz alternatywne zachowania, określ warunki, przez które odpowiedź staje się nieprzydatna. Rozdzielenie przypadków ułatwia wybór polityki i ocenę jej skuteczności:
- Timeout: żądanie przekracza limit czasu oczekiwania aplikacji.
- Niedostępność lub błąd transportu: połączenie zostaje przerwane albo dostawca zwraca błąd.
- Pusta odpowiedź: wywołanie kończy się, ale nie zawiera oczekiwanej treści.
- Nieprawidłowy format: wyniku nie można sparsować albo nie spełnia wymaganego schematu, na przykład JSON nie zawiera wymaganych pól.
- Nieakceptowalny wynik: odpowiedź jest czytelna, ale nie przechodzi reguł biznesowych, walidacji lub kryteriów bezpieczeństwa.
Nie należy utożsamiać odpowiedzi poprawnej technicznie z prawidłową decyzją. Jeśli aplikacja oczekuje kategorii z zamkniętego zbioru, musi sprawdzić, czy wartość należy do tego zbioru. Jeśli oczekuje wymaganych pól, musi je zweryfikować przed przekazaniem do innego komponentu. Deterministyczne kontrole powinny być wykonywane w kodzie PHP — nie należy ponownie delegować ich temu samemu modelowi.
Ogranicz czas oczekiwania i liczbę ponowień
Ustaw timeout odpowiedni do danej operacji i czasu, przez jaki użytkownik lub proces może czekać. Uwzględnij też limity serwera WWW, kolejki i każdego pośredniego klienta HTTP: lokalny timeout przekraczający limit żądania nie zapewnia rzeczywistej kontroli. W zadaniu działającym w tle można dopuścić inny czas oczekiwania, pod warunkiem że istnieje jawna polityka obsługi zadań oczekujących.
Ponowienia powinny być ograniczone i stosowane wyłącznie w przypadku błędów, które mogą mieć charakter przejściowy. Przerwanie połączenia sieciowego może uzasadniać dodatkową próbę; odpowiedź niespełniająca schematu zwykle wymaga walidacji, fallbacku lub weryfikacji, a nie bezrefleksyjnego ponawiania. Ogranicz liczbę prób i łączny czas. Jeśli stosujesz rosnące odstępy między próbami, ustal również ich maksymalną wartość.
Pamiętaj, że ponowienie wywołania może powielić zużycie zasobów lub skutki operacji. Unikaj automatycznych ponowień bez limitu i sprawdź, czy operacja jest idempotentna. Generowanie tekstu bez efektów ubocznych to nie to samo co działanie tworzące zamówienie lub wysyłające powiadomienie. W przypadku wrażliwych operacji oddziel wygenerowanie propozycji od jej wykonania i zastosuj odrębne mechanizmy kontroli tego drugiego etapu.
Dobierz alternatywę do wpływu
Fallback nie jest uniwersalną odpowiedzią na wszystkie błędy. Powinien zachowywać reguły biznesowe i jasno komunikować, co aplikacja może zrobić:
- Ogranicz funkcjonalność: jeśli AI jedynie ułatwia pracę, pozwól kontynuować bez tej funkcji. Na przykład wyświetl standardowy formularz, gdy nie uda się wygenerować sugestii.
- Odłóż: jeśli wynik można uzyskać później, zapisz zadanie ze statusem oczekującym i umożliw jego ponowienie za pośrednictwem kolejki, z limitami i monitorowaniem.
- Poproś o weryfikację: jeśli potrzebna jest ocena człowieka, pokaż propozycję jako wersję roboczą lub przekaż sprawę odpowiedniej osobie. Nie przedstawiaj niezweryfikowanego wyniku jako ostatecznej decyzji.
- Odrzuć lub zatrzymaj: jeśli nie można zweryfikować warunku niezbędnego do wykonania operacji, zablokuj działanie i wyjaśnij, jak kontynuować lub uzyskać pomoc.
Decyzja powinna zależeć od ryzyka błędnego działania, a nie tylko od kosztu przerwania procesu. Wyszukiwarka z sugestiami może nadal korzystać z pierwotnego zapytania. Natomiast proces modyfikujący dane klientów nie powinien uzupełniać brakujących pól na podstawie przypuszczeń. Jeśli wynik AI wpływa na decyzję biznesową, w miarę możliwości zachowaj ścieżkę ręczną lub regułę deterministyczną.
Chroń integralność procesów
Traktuj odpowiedź modelu jak dane wejściowe z zewnątrz: analizuj jej strukturę, waliduj każdą wartość i ograniczaj operacje, które może zainicjować. Nie wstawiaj jej bezpośrednio do zapytań SQL, poleceń, HTML ani instrukcji dla innych systemów. Stosuj zapytania parametryzowane, odpowiednie kodowanie i listy dozwolonych wartości, a także kontrole specyficzne dla danej domeny.
Wyznacz granicę między sugerowaniem a wykonywaniem. Na przykład AI może zaproponować klasyfikację; kod sprawdza, czy jest ona dopuszczalna, a polityka produktu określa, czy zostanie zastosowana automatycznie, czy pozostanie oczekująca. Gdy brakuje wymaganej informacji, bezpieczną alternatywą jest zwykle poproszenie o nią, pozostawienie sprawy niekompletnej lub zatrzymanie procesu — a nie jej wymyślenie. Obsługa błędów musi również respektować standardowe uprawnienia, walidacje i reguły autoryzacji.
Rejestruj błędy bez zapisywania zbędnych informacji
Logi powinny pomagać w diagnozowaniu problemów, a nie stawać się kopią rozmów. Zapisuj zdarzenia techniczne, takie jak operacja, rodzaj błędu, czas trwania, liczba prób, wynik walidacji i identyfikator korelacyjny. Zgromadź wystarczająco dużo informacji, by odróżnić na przykład timeout od nieprawidłowego JSON-a, ale domyślnie unikaj zapisywania pełnych promptów, odpowiedzi, danych uwierzytelniających lub danych osobowych.
Jeśli treść musi być zachowana na potrzeby weryfikacji lub audytu, przed jej zapisaniem określ cel, dostęp, okres przechowywania i środki ochrony. W metrykach monitoruj częstotliwość timeoutów, nieprawidłowych odpowiedzi, użycia fallbacku i zadań oczekujących, a także opóźnienia i ponowienia. Wzrost tych wartości może wskazywać na problem operacyjny lub zmianę zachowania wyników. Metryki pomagają wykrywać trendy; nie zastępują analizy konkretnego przypadku i same w sobie nie dowodzą, że odpowiedź jest poprawna.
Testuj scenariusze i uzgodnij kryteria
Testuj integrację z kontrolowanymi odpowiedziami i sprawdzaj zarówno widoczny rezultat, jak i skutki w systemie. Uwzględnij wysokie opóźnienie, przerwanie połączenia, pustą odpowiedź, nieprawidłowy format, wartość niezgodną z regułami oraz odzyskiwanie działania po błędzie. Sprawdź, czy operacje nie są wykonywane wielokrotnie, ponowienia mieszczą się w limitach, a logi nie ujawniają poufnej treści. Przetestuj również, co się dzieje, gdy zadanie oczekuje na wykonanie lub wymaga interwencji.
Przed wdrożeniem funkcji na produkcję uzgodnij poniższe decyzje z zespołem produktowym i technicznym:
- Czy funkcja jest niezbędna do ukończenia operacji, czy tylko poprawia doświadczenie użytkownika?
- Jaki łączny czas oczekiwania jest akceptowalny w każdym kanale?
- W przypadku jakich błędów można ponowić próbę i ile prób jest dozwolonych?
- Jaka jest bezpieczna alternatywa: kontynuowanie bez AI, odłożenie, weryfikacja przez człowieka czy zatrzymanie?
- Jakie walidacje muszą zakończyć się powodzeniem przed wykorzystaniem odpowiedzi?
- Jakie dane są rejestrowane, kto może uzyskać do nich dostęp i jak długo są przechowywane?
- W jaki sposób zespół otrzymuje alerty i kto rozwiązuje sprawy oczekujące?
Przydatna polityka pozwala ograniczać funkcje pomocnicze i zatrzymywać operacje zależne od niezweryfikowanych danych. Jeśli nie da się precyzyjnie wyjaśnić, co stanie się w przypadku opóźnionej, nieprawidłowej lub brakującej odpowiedzi, integracja nie ma jeszcze operacyjnego fallbacku. Udokumentuj te reguły przy opisywanym przepływie i testuj je ponownie po zmianach produktu, walidacji lub sposobu korzystania z usługi.
