Observability dla AI: jak monitorować systemy, które nie są deterministyczne

# Observability dla AI: jak monitorować systemy, które nie są deterministyczne

Klasyczne monitorowanie aplikacji opiera się na prostym założeniu: ten sam input powinien dać ten sam output albo przewidywalny błąd. Systemy AI, szczególnie oparte na modelach językowych i agentach narzędziowych, łamią to założenie. Odpowiedź może się różnić między wywołaniami, zachowanie zależy od kontekstu, a degradacja jakości bywa subtelna i rozłożona w czasie.

W praktyce oznacza to, że metryki typu CPU, pamięć, uptime czy nawet p95 latency są potrzebne, ale niewystarczające. Można mieć zielony dashboard infrastruktury i jednocześnie rosnącą liczbę błędnych decyzji biznesowych.

Centralna teza tych Operator Notes: observability dla AI musi łączyć telemetrię techniczną z sygnałami jakości decyzyjnej. Tylko taki model pozwala wykrywać problemy, które nie objawiają się awarią systemu, ale prowadzą do cichej erozji wartości.

Dlaczego niedeterministyczność zmienia zasady monitoringu

Niedeterministyczność nie jest błędem samym w sobie. Jest cechą systemów generatywnych. Problem zaczyna się wtedy, gdy organizacja monitoruje tylko "czy działa usługa", a nie "czy działa sensownie dla procesu biznesowego".

NIST AI RMF 1.0 (2023) i ISO/IEC 23894 (2023) podkreślają, że ryzyko AI obejmuje nie tylko awarie techniczne, ale także degradację jakości, niezamierzone skutki i brak wykrywalności błędów. Dla operatora oznacza to zmianę perspektywy: od monitoringu komponentu do monitoringu zachowania systemu w kontekście użycia.

Trzy warstwy observability dla AI

Praktycznie najlepiej działa model trójwarstwowy.

### Warstwa 1: Service health

To klasyczna telemetria SRE: - dostępność usług, - latency end-to-end i per komponent, - błędy integracji narzędzi i timeouty, - wykorzystanie limitów API i koszt tokenów.

Bez tej warstwy nie ma stabilności operacyjnej, ale sama warstwa nie powie, czy odpowiedzi AI są dobre.

### Warstwa 2: Behavioral quality

Ta warstwa mierzy zachowanie systemu AI: - acceptance rate odpowiedzi, - odsetek reworku przez człowieka, - wskaźnik eskalacji do wsparcia, - częstotliwość naruszeń polityk lub odmów błędnie pozytywnych.

To właśnie tu najczęściej pojawiają się pierwsze sygnały degradacji.

### Warstwa 3: Business impact

Najwyższa warstwa łączy AI z wynikiem procesu: - czas zamknięcia sprawy, - koszt jednostkowy obsługi, - wpływ na SLA i satysfakcję użytkownika, - udział spraw wymagających ręcznej korekty po użyciu AI.

Dopiero ta warstwa pokazuje, czy obserwowane odchylenie ma znaczenie biznesowe.

Co logować, aby dało się diagnozować problemy

Największy operacyjny ból to sytuacja: "wiemy, że jakość spadła, ale nie wiemy dlaczego". Przyczyną bywa brak odpowiedniej granularności logów.

Minimalny zestaw danych diagnostycznych: - identyfikator wersji modelu, promptu i polityki, - identyfikator narzędzi oraz status wywołań, - klasyfikacja intencji lub typu zadania, - wynik walidacji bezpieczeństwa i reason code blokady, - ślad decyzji o eskalacji do człowieka, - sygnał jakości po fakcie (np. accepted/reworked/rejected).

OpenTelemetry (2023/2024) dostarcza standard instrumentacji, który można rozszerzyć o atrybuty specyficzne dla AI. To pomaga uniknąć chaosu narzędziowego i utrzymać spójny model śledzenia.

Drift i regres: jak odróżnić hałas od realnego problemu

W systemach AI odchylenia są normalne, więc nie każdy skok metryki wymaga alarmu krytycznego. Kluczowe jest rozróżnienie krótkotrwałego hałasu od trwałego trendu regresji.

Praktyczna metoda: - definiuj baseline dla segmentów użycia, nie tylko globalnie, - stosuj progi dynamiczne uwzględniające sezonowość i typ zapytań, - monitoruj trend łączony: jakość + koszt + eskalacje, - uruchamiaj alarm wysoki dopiero przy utrzymującym się odchyleniu.

Takie podejście zmniejsza alert fatigue i pozwala zespołowi skupić się na incydentach, które faktycznie wpływają na biznes.

Projekt alertingu: mniej alarmów, więcej decyzji

W observability AI jakość alertingu decyduje o czasie reakcji. Zbyt dużo alertów osłabia czujność, zbyt mało powoduje opóźnioną reakcję na regres.

Dobry alert powinien zawierać: - wykryte odchylenie i jego kontekst segmentu, - ocenę potencjalnego wpływu biznesowego, - sugerowaną akcję runbookową, - właściciela reakcji i SLA odpowiedzi.

To zamienia alert z "sygnału technicznego" w "wezwanie do decyzji operacyjnej".

Runbooki dla najczęstszych incydentów AI

Observability bez runbooków kończy się improwizacją pod presją. Dla systemów AI warto utrzymywać gotowe ścieżki reakcji przynajmniej dla czterech scenariuszy:

1. **Nagły spadek acceptance rate** Akcje: segmentacja błędu, porównanie wersji promptu/modelu, rollback ostatniej zmiany, zwiększenie human review.

2. **Wzrost naruszeń polityki bezpieczeństwa** Akcje: zaostrzenie filtrów, ograniczenie funkcji wysokiego ryzyka, analiza prób obejścia i aktualizacja guardrails.

3. **Wzrost latency i timeoutów narzędzi** Akcje: degradacja funkcjonalna, priorytetyzacja krytycznych ścieżek, przełączenie na fallback provider.

4. **Rosnący koszt przy stałym wolumenie** Akcje: audyt długości kontekstu, routing modeli, optymalizacja liczby wywołań narzędzi, kontrola retry logic.

Runbook powinien mieć progi uruchomienia, role decyzyjne i warunki zamknięcia incydentu.

Observability a governance: kto odpowiada za co

Częstym problemem jest rozproszenie odpowiedzialności: platforma monitoruje infrastrukturę, produkt monitoruje użycie, a nikt nie monitoruje jakość decyzji. W efekcie incydent jakościowy krąży między zespołami.

Dobry model odpowiedzialności: - platform/SRE: niezawodność i telemetryka techniczna, - owner produktu AI: jakość zachowania i wpływ na proces, - risk/governance: progi ryzyka, klasyfikacja incydentów, eskalacja, - operations/business: potwierdzenie wpływu i priorytet remediacji.

Taki podział wspiera AI incident response i skraca czas od wykrycia do korekty.

Dashboard operacyjny, który ma sens

Dashboard AI observability nie powinien być "ścianą wykresów". Powinien odpowiadać na trzy pytania operatorskie: - co właśnie się psuje, - jak duży to ma wpływ, - jaka jest następna decyzja.

W praktyce dashboard warto budować wokół widoku "service -> behavior -> business", z możliwością drill-down od trendu strategicznego do pojedynczego śladu wykonania.

To podejście łączy perspektywę SRE i LLMOps: stabilność systemu technicznego i stabilność wyniku biznesowego.

Executive Takeaway

Co się zmieniło? Observability dla AI przesuwa się z monitoringu infrastruktury na monitorowanie jakości zachowania i wpływu biznesowego systemów niedeterministycznych. Dlaczego to ważne? System AI może działać technicznie poprawnie, a jednocześnie pogarszać decyzje operacyjne, jeśli organizacja nie mierzy jakości i driftu w czasie. Co liderzy powinni zrobić? Wdrożyć trójwarstwowy model observability, powiązać alerting z runbookami decyzyjnymi i przypisać jasną odpowiedzialność za sygnały jakościowe oraz ich eskalację.