SLO dla systemów AI: mierzalna niezawodność automatyzacji

SLO, czyli Service Level Objective, jest celem niezawodności usługi w konkretnym okresie. Nie jest obietnicą marketingową ani samym panelem z metrykami. To świadoma decyzja: co uznajemy za dobre działanie, jak to policzymy, jaki wynik jest wystarczający i co zrobimy, gdy system schodzi poniżej ustalonego progu. W systemie AI usługą może być agent kwalifikujący leady, automatyczne streszczenie rozmowy, generowanie briefu, wyszukiwanie w bazie wiedzy albo przepływ, który po webhooku tworzy zadanie w CRM. SLO zamienia ogólne „ma działać dobrze” w kryterium, które zespół może obserwować i egzekwować.

Podstawą jest SLI, czyli Service Level Indicator. To wskaźnik opisujący realne doświadczenie użytkownika, zwykle jako stosunek dobrych zdarzeń do wszystkich zdarzeń. Dla automatycznego follow-upu dobrym zdarzeniem może być wiadomość utworzona, zwalidowana i przekazana do zatwierdzenia w ciągu pięciu minut. Dla wyszukiwania RAG może nim być odpowiedź z właściwym źródłem i bez błędu technicznego. SLO ustala próg dla tego SLI, na przykład 95% poprawnie zakończonych zadań w ciągu 30 dni. Dopiero połączenie definicji „dobrego” zdarzenia, licznika i progu tworzy użyteczny standard.

System AI wymaga jednak czegoś więcej niż mierzenia dostępności API. Odpowiedź może przyjść szybko i bez błędu HTTP, a mimo to być nieprzydatna, niekompletna lub wysłana do niewłaściwego etapu procesu. Dlatego wybieraj wskaźnik blisko efektu użytkownika. Przykładowe SLI to: udział zadań zakończonych bez ręcznej naprawy, udział odpowiedzi z cytowanym źródłem, czas od pojawienia się leada do gotowego szkicu odpowiedzi oraz udział rekordów zapisanych w poprawnym formacie. Metryka modelu, na przykład liczba tokenów, może pomagać diagnozować problem, ale sama nie mówi, czy klient dostał wartość.

Praktyczny przykład: ekspert prowadzi newsletter i ma automatyzację, która zbiera odpowiedzi z formularza, tworzy brief oraz zapisuje go w systemie treści. Wspólnie ustala SLO: „co najmniej 95% poprawnych zgłoszeń kończy się gotowym briefem w ciągu 10 minut, bez ujawnienia danych poza wskazanym narzędziem”. Licznik obejmuje tylko formularze spełniające walidację wejścia. Mianownik to wszystkie takie zgłoszenia. Jeśli wynik spada, nie wystarczy ponowić workflowu. Trzeba rozdzielić przyczynę: limit API, błąd integracji, nieprawidłowe dane, niedostępne narzędzie albo wynik wymagający poprawy przez człowieka.

Z SLO wiąże się budżet błędów. Jeśli cel wynosi 95%, system ma ograniczoną przestrzeń na błędy w danym oknie pomiaru. Nie jest to pozwolenie na ignorowanie klienta. To mechanizm podejmowania decyzji: gdy budżet szybko się wyczerpuje, wstrzymujesz ryzykowne zmiany, zwiększasz kontrolę człowieka lub naprawiasz wąskie gardło zamiast dokładać kolejną funkcję. Google podkreśla, że cel 100% zwykle jest zły, bo każdy system i jego zależności mogą zawieść, a próba utrzymania absolutnej bezbłędności blokuje bezpieczne ulepszenia. Dla małej firmy ważniejszy od perfekcyjnej liczby jest jasny moment reakcji.

Dobry pierwszy SLO jest wąski i możliwy do policzenia. Opisz właściciela usługi, użytkownika, zdarzenie startowe, definicję sukcesu, źródło danych, okres pomiaru, próg oraz reakcję na naruszenie. Nie mieszaj w jednym procencie jakości copy, czasu odpowiedzi, kosztu i bezpieczeństwa. To różne ryzyka, które mogą potrzebować osobnych wskaźników. Zacznij od jednego krytycznego przepływu, zbieraj dane przez kilka tygodni, a potem doprecyzuj próg. Warto zapisać też zachowanie awaryjne: czy zadanie trafi do kolejki błędów, czy agent poprosi o akceptację, czy klient zobaczy uczciwy komunikat.

SLO nie zastępuje ewaluacji jakości modelu, testów regresji ani obserwowalności. Ewaluacja odpowiada na pytanie, czy wynik jest merytorycznie dobry na reprezentatywnych przykładach. Test regresji wykrywa zmianę zachowania po wdrożeniu. Obserwowalność pomaga znaleźć przyczynę incydentu. SLO spina je decyzją operacyjną: czy usługa utrzymuje poziom, który obiecaliśmy użytkownikowi. Nie kopiuj progów z dużej platformy bez kontekstu. Automatyzacja wewnętrznego researchu może tolerować opóźnienie, ale system wysyłający komunikację do klienta powinien mieć niższą tolerancję na błędny rezultat i obowiązkowy punkt kontroli człowieka.