Odkryłem, że pojedyncza metryka bramki bezpieczeństwa (safety-gate) ukryła całodniową awarię funkcji generowania wyjaśnień przez AI. Traktując „odrzucenie przez bramkę” i „błąd ładowania modelu” jako to samo, metryka dawała fałszywe poczucie poprawnego działania systemu. Odnotowała cztery odrzucenia i zero sukcesów, mimo że w tym czasie model w ogóle nie został uruchomiony – błąd, który mógłby pozostawić operatorów bez wiedzy o awarii systemu.

Jak doszło do pomyłki

Funkcja ta wykorzystuje lokalny model językowy do przekształcania surowej logiki maszynowej w zrozumiałe dla człowieka zdania. Bramka bezpieczeństwa (safety gate) działająca dalej w procesie blokuje wszelkie wyniki, które naruszają zdefiniowane reguły. Na produkcji udostępniłem pojedynczy licznik, który zwiększał swoją wartość za każdym razem, gdy bramka odrzucała zdanie. Gdy dron zarejestrował cztery wyjaśnienia AI, licznik wskazał cztery odrzucenia i brak udanych wyników. Uznałem to za dowód na to, że bramka wykonuje swoją pracę, a nie za sygnał, że funkcja przestała działać.

Licznik maskował dwuetapową awarię:

  1. Model nie działa – Model współdzieli maszynę z resztą systemu. Aby oszczędzać pamięć, host odładowuje go po okresie nieaktywności.
  2. Przekroczenie czasu ładowania (timeout) – Gdy pojawiło się nowe zagrożenie, system próbował ponownie załadować około dwa gigabajty danych modelu. Ponowne ładowanie przekroczyło trzydziestosekundowy limit czasu odpowiedzi (timeout), więc żądanie wygasło i zwróciło pustą odpowiedź.

Ponieważ licznik traktował odrzucenie przez bramkę oraz pustą odpowiedź spowodowaną przekroczeniem czasu jako to samo zdarzenie, pulpit nawigacyjny pokazywał „działającą bramkę bezpieczeństwa”, podczas gdy funkcja AI była w rzeczywistości martwa.

Dlaczego to ma znaczenie

W produktach opartych na AI bramki bezpieczeństwa powstrzymują szkodliwe lub nielogiczne wyniki. Operatorzy monitorują częstotliwość odrzucań przez bramkę jako sygnał o stanie systemu. Gdy ten sygnał miesza się z niepowiązanymi trybami awarii, metryka staje się „cichym kłamstwem”: uspokaja, podczas gdy usługa jest niedostępna.

Rozwiązanie, które przywróciło widoczność

Wprowadziłem trzy praktyczne zmiany:

  • Pozostawienie modelu w pamięci – Dostosowałem hosta tak, aby zatrzymywał model w pamięci, co wyeliminowało opóźnienie związane z ponownym ładowaniem.
  • Wydłużenie czasu oczekiwania (timeout) – Zwiększyłem okno odpowiedzi, aby obsłużyć sporadyczne, wolniejsze ładowania.
  • Rozdzielenie licznika – Zastąpiłem pojedynczą metrykę „odrzucone przez bramkę” czterema odrębnymi licznikami: accepted, rejected, empty response oraz no answer.

Trzeci krok okazał się decydujący. Zamiast pojedynczej liczby, którą można było interpretować na dwa sposoby, czteroczęściowy podział pokazuje, czy bramka bezpieczeństwa jest aktywna, czy model odpowiada, czy też żądanie w ogóle nie dotarło do modelu.

Kompromisy i kontrargumenty

Na co zwrócić uwagę w przyszłości

Deweloperzy wdrażający komponenty AI powinni audytować wszelkie zagregowane liczniki, które łączą kontrole bezpieczeństwa z awariami na poziomie systemu. Tworzenie szczegółowych logów historii, które rejestrują ścieżkę każdego żądania — od rozpoczęcia ładowania modelu, przez ocenę przez bramkę, aż po końcowy wynik — dostarcza danych śledczych niezbędnych do wykrywania ukrytych problemów.

Wniosek: Pojedyncza metryka „odrzucenia przez bramkę” może maskować martwą usługę AI; rozdzielenie tej metryki na poszczególne zdarzenia ujawnia prawdę i zapobiega fałszywemu poczuciu pewności co do systemu, który w rzeczywistości nie działa.