Słuszny alert i użyteczny alert to dwie różne rzeczy.
Próg 2 kvarh na obiekcie, który co dzień ma 3 kvarh, jest matematycznie prawidłowy i operacyjnie bezużyteczny. W przemyśle nazywa się to zjawisko "bad actor". Skutek jest zawsze ten sam: zmęczenie materiału i fizyczne wyłączenie kanału powiadomień.
Zamiast tłumaczyć operatorom, dlaczego otrzymali fałszywy alarm, ERGOcontrol diametralnie zmniejsza to, co trafia na ich ekrany. Dziennik systemowy jest dowodem analitycznym. Widok "Dziś" to wyselekcjonowane centrum akcji.
Dlaczego więcej alertów to mniej decyzji.
Pojemność człowieka
Zgodnie z wytycznymi EEMUA 191 / ISA-18.2 [2], cel operacyjny przy 8-godzinnej zmianie na konsoli to ok. 150 alarmów na dobę. 300 to szczyt fizycznych możliwości. Z kolei Google (SRE Book) zaznacza, że rygorystyczną pilność da się utrzymać zaledwie kilka razy dziennie.
Panel zarządcy sieci jest otwierany na kilkanaście minut, nie na 8 godzin. Dlatego ekran „Dziś” posiada twardy limit (do 15 kart). Setki technicznych zdarzeń zostają zrzucone do bezstronnego Dziennika dla dowodu, a nie na e-mail operatora.
Lawina powiadomień
Gdy wszystko jest ważne, nic nie jest ważne. Przy powodzi ostrzeżeń, detekcja faktycznej awarii potrafi spaść z 98% do zaledwie 64% (Roth, Human Factors 2022 [3]). Operatorzy skupiają się na mechanicznym „odklikiwaniu”, przegapiając powód zjawiska.
Krytyczne 47 kvarh ginie w dywanie ostrzeżeń rzędu 3 kvarh. Dlatego stosujemy algorytmiczne klastrowanie: 14 obiektów offline korzystających z tej samej chmury (np. Supla) to w systemie jedna zbiorcza karta awarii hosta, a nie 14 niepotrzebnych wyjazdów serwisu.
Wyłączenie kanału
Po serii jałowych ostrzeżeń (poprawnych technicznie, ale niewymagających akcji), wiarygodność systemu drastycznie spada. Zmęczenie powoduje desensytyzację i fizyczne ignorowanie nawet prawdziwych komunikatów (efekt Cry Wolf, Bliss [4]).
Warning rzędu 2 kvarh milczy w nocy. Czeka do godziny 7:00 i trafia zbiorczo do porannego briefingu. Trwa remont w lokalu? Wyciszasz go na 14 dni. Silnik nadal zapisuje logi, ale kanał decyzyjny pozostaje czysty.
Dlaczego nie powierzamy triażu sztucznej inteligencji (LLM).
Złudzenie optymalizacji LLM
Obecne trendy sugerują wpuszczanie Modeli Językowych (ChatGPT / Claude) do odsiewania logów technicznych. Aktualna literatura cyfrowa (m.in. PLOS Digital Health, npj Digital Medicine 2025) wskazuje jednak, że modele te mają tendencję do „wygładzania” i usypiania czujności. Zmierzono, że aż kilkadziesiąt procent streszczeń systemowych potrafi pominąć krytyczną anomalię lub wygenerować halucynację [5, 6], byleby tylko zredukować objętość tekstu.
Determinizm i twarde reguły
Przy opłatach rzędu tysięcy złotych, „halucynacja” systemu jest niedopuszczalna. Nie oddajemy triażu modelowi, który potrafi ukryć awarię. Triaż w naszej platformie oparty jest wyłącznie o sztywne, transparentne reguły i wyceny matematyczne. Poranny briefing to ułożona hierarchia ryzyka, a pod nią zawsze znajduje się nietknięty, surowy Dziennik, do którego możesz zajrzeć.
if (outlier_qpoj > limit_osd) {
triggerCritical(’Immediate Action’);
} else if (offline_hours >= 24) {
addToMorningBriefing();
}
Pytania operacyjne
Bo po serii jałowych ostrzeżeń ludzie dopasowują reakcję do „pewnie znowu nic” (Bliss) albo całkowicie wyłączają kanał (Breznitz). Dlatego 3 kvarh ląduje w cichym briefingu. Krytyczne 10 kvarh lub 2 godziny bez transmisji sprzętu aktywują powiadomienie e-mail.
Tam, gdzie LLM mierzono na streszczeniach systemowych i medycznych, modele te regularnie pomijają i zmyślają dane. Przy ryzyku wielotysięcznej kary na fakturze OSD, pominięcie karty „Critical” jest niedopuszczalne. Triaż w ERGOcontrol robią twarde reguły matematyczne, scoring i doba zamykana o 7:00.
Nie, to znaczy, że detekcja jest po prostu bardzo gęsta. Produkt (system ERP) jest zepsuty dopiero wtedy, gdy te 500 wierszy ląduje wymieszane w Twoich oczach. Dziennik w bazie danych ma mieć 500 wpisów, by służyć za audyt. Poranna kolejka dnia dla Ciebie ma mieć do 15 decyzji.