SLA dla systemu AI: co da się obiecać, a czego nie

Dział zakupów ma sprawdzony wzór umowy serwisowej: dostępność usługi, czasy reakcji, czasy naprawy, kary za przekroczenia. Dla zwykłego oprogramowania to działa, bo awaria jest widoczna — usługa odpowiada albo nie.

System AI może mieć pełną dostępność i od trzech tygodni odpowiadać gorzej. Umowa napisana według starego wzoru będzie wtedy dotrzymana co do joty, a Waszego problemu nie będzie w niej w ogóle.

Dlaczego klasyczny wzór nie wystarcza

Mierzy rzecz, która rzadko się psuje. Dostępność jest łatwą częścią. Trudna część — jakość odpowiedzi — nie ma w typowej umowie ani definicji, ani pomiaru.

Zakłada, że błąd widać. Czas naprawy liczy się od zgłoszenia. Gdy system myli się wiarygodnie, zgłoszenie przychodzi po tygodniach albo wcale.

Priorytet liczy się technicznie. Liczba dotkniętych użytkowników, liczba niedziałających komponentów. Tymczasem jedna błędna odpowiedź o cenie albo terminie może ważyć więcej niż godzina niedostępności.

Infografika

SLA na oprogramowanie a SLA na system AI

Klasyczne SLA

• –Mierzy dostępność usługi
• –Priorytet według wpływu technicznego
• –Pierwsza reakcja: przywrócić działanie
• –Raport z liczbą zgłoszeń

SLA dla systemu AI

• →Mierzy też jakość odpowiedzi
• →Priorytet według skutku biznesowego
• →Pierwsza reakcja: zawęzić działanie
• →Notatka: co się zmieniło i dlaczego

Co powinno być w umowie

Zdefiniowany zakres monitorowania jakości. Które przypadki są oceniane, jak często i co uruchamia alert. Bez tego zdanie „monitorujemy jakość” nie ma treści, którą dałoby się wyegzekwować.

Priorytety opisane biznesowo. Napisane przez Waszą stronę, a nie przez dostawcę: co jest incydentem krytycznym, a co drobną niedogodnością.

Czasy reakcji według priorytetu i wskazany inżynier. Ktoś, kto zna Wasze wdrożenie, a nie kolejka zgłoszeń, oraz ścieżka eskalacji na wypadek, gdy ta osoba jest niedostępna.

Ścieżka ograniczenia. Kto i na jakiej podstawie może zawęzić działanie systemu na czas dochodzenia — uzgodnione przed pierwszym incydentem, a nie w jego trakcie.

Zmiany modeli testowane przed wdrożeniem. Wycofania i nowe wersje u dostawcy modelu sprawdzane na Waszym zestawie ewaluacyjnym, zanim dotrą do użytkowników.

Dostęp do danych. Jak najwęższy, ograniczony w czasie, zapisywany i opisany w umowie. Zwykle wystarczą metryki, logi i próbkowany zestaw ewaluacyjny, a nie cały korpus dokumentów.

Okna serwisowe, raport i warunki wyjścia. Co zostaje przekazane przy zakończeniu współpracy, w jakim formacie i w jakim terminie — rozstrzygnięte, póki macie siłę negocjacyjną.

Jak napisać priorytety

To jedyna część umowy, której dostawca nie powinien pisać za Was, i zwykle zajmuje najmniej czasu. Wystarczy kilka przykładów na każdy poziom, sformułowanych językiem skutków, a nie komponentów.

Krytyczny. System podaje błędne informacje, na podstawie których ktoś podejmuje decyzję finansową, prawną albo dotyczącą bezpieczeństwa — na przykład błędną cenę, termin albo warunek umowy.

Wysoki. System myli się w sposób, który użytkownicy zauważają i poprawiają, ale który zabiera im czas albo podważa zaufanie do wszystkich pozostałych odpowiedzi.

Niski. Odpowiedzi są merytorycznie poprawne, ale gorsze w formie: za długie, niekonsekwentne, mniej czytelne niż wcześniej.

Przykłady mają większe znaczenie niż definicje. Przy pierwszym incydencie nikt nie będzie interpretował abstrakcyjnego opisu poziomu — wszyscy będą porównywać sytuację z przykładem.

Czego nikt uczciwie nie obieca

Że model nigdy się nie pomyli. Dostawca, który to obiecuje, opisuje coś innego niż system AI.

Naprawy w stałym czasie dla dowolnego defektu. Diagnoza problemu z jakością może trwać dłużej niż zawężenie działania. Uczciwie obiecać można reakcję i ograniczenie skutków, a nie termin usunięcia przyczyny.

Stałej jakości w zmieniającym się otoczeniu. Gdy zmieniają się Wasze dokumenty albo pytania użytkowników, umowa może obiecać wykrycie i reakcję, a nie to, że nic się nie ruszy.

Gdy w ofercie pojawia się którakolwiek z tych obietnic, warto zapytać, jak dokładnie będzie mierzona. Odpowiedź zwykle pokazuje, że nie będzie.

Na co patrzeć w cenie

Wycena od użytkownika albo od zapytania sprawia, że opłata rośnie dlatego, że system się udał. Wycena od systemu i zakresu tego nie robi i lepiej wyrównuje interesy obu stron.

Druga rzecz to rachunek za modele. Czy koszt użycia jest w umowie, czy obok niej, i kto co miesiąc odpowiada za wyjaśnienie, dlaczego się zmienił? System, którego kosztu nikt nie umie przypisać, w końcu zostanie oceniony po fakturze, a nie po tym, co robi.

Tak układamy SLA w utrzymaniu systemów AI: czasy reakcji według priorytetu, wskazany inżynier, zdefiniowany zakres monitorowania jakości — i jasno zapisane, czego obiecać się nie da.