Kto prowadzi system AI dzień po uruchomieniu?

Projekty AI są budżetowane do dnia uruchomienia. Plan, zespół, kamienie milowe i odbiór — wszystko kończy się w chwili, w której system dostaje prawdziwych użytkowników. A dokładnie od tej chwili system zaczyna się zmieniać: przybywa dokumentów, pytania użytkowników przesuwają się w nowe strony, dostawca modelu wycofuje wersję, na której wszystko testowano.

Pytanie, kto to prowadzi, pada zwykle po fakcie, gdy zespół projektowy już się rozszedł. Wtedy odpowiedź jest najdroższa.

Co właściwie trzeba prowadzić

Nie tylko serwery. Dostawca chmury utrzyma infrastrukturę lepiej i taniej niż ktokolwiek inny, ale nie powie Wam, że od dwóch tygodni odpowiedzi są gorsze.

Jakość odpowiedzi. Stale oceniany zestaw ewaluacyjny i ktoś, kto patrzy na wynik i reaguje na ruch, zanim zgłoszą go użytkownicy.

Cykl życia modeli. Dostawcy wycofują wersje i zmieniają zachowanie modeli. Każdą taką zmianę trzeba sprawdzić na Waszych przypadkach, zanim dotrze do ludzi.

Koszt. Rachunek za modele rośnie razem z sukcesem systemu i potrafi skoczyć po jednej niewinnej zmianie. Ktoś musi umieć przypisać go do konkretnych funkcji.

Dane pod spodem. Ponowne indeksowanie, odświeżanie osadzeń i egzekwowanie retencji, gdy Wasze dokumenty się zmieniają.

Incydenty bez awarii. System nie pada, tylko zaczyna się mylić. Ktoś musi mieć prawo zawęzić jego działanie na czas dochodzenia, bez zwoływania komitetu.

Trzy opcje, z których jedna jest domyślna

Własny zespół. Najlepsza odpowiedź docelowo, jeśli macie ludzi, którzy rozumieją system i mają na niego czas zapisany w grafiku — a nie „w wolnej chwili” między projektami.

Zewnętrzne utrzymanie. Rozsądne, gdy zespół budujący był zewnętrzny albo poszedł dalej, a system jest zbyt ważny, żeby czekać, aż własny zespół dojrzeje. Pod warunkiem, że umowa jest zbudowana wokół przekazywania, a nie trwałej zależności.

Nikt. Opcja, której nikt nie wybiera świadomie i która zostaje, gdy nie wybierze się żadnej innej. System działa, bo nikt go nie wyłączył, a jego jakość jest znana dokładnie do pierwszej poważnej reklamacji.

Infografika

Kto powinien prowadzić system AI

Wysoka krytycznośćNiska krytyczność

Utrzymanie zewnętrzneZ harmonogramem przekazania, żeby zależność malała.

Własny zespółZ właścicielem jakości i czasem zapisanym w grafiku.

Lekki nadzórPodstawowe kontrole i decyzja, czy system w ogóle zostaje.

Rutyna zespołuProwadzony obok innych systemów, z tymi samymi kontrolami.

Mało kompetencjiDużo kompetencji

Ile uwagi wymaga to od Was

Nawet przy zewnętrznym utrzymaniu część odpowiedzialności zostaje po Waszej stronie i nie da się jej oddać.

Właściciel jakości po stronie biznesu. Ktoś, kto definiuje, co jest incydentem. Błędna odpowiedź o cenie albo terminie to inny priorytet niż odpowiedź za długa, a tej różnicy nie powinien ustalać inżynier.

Decyzja o ograniczeniu. Wskazana osoba, która może zgodzić się na zawężenie działania systemu w ciągu godzin, a nie na najbliższym posiedzeniu.

Jedna strona miesięcznie, przeczytana. Co się zmieniło, co się zepsuło, ile kosztowało i co jest rekomendowane. Jeśli nikt tej strony nie czyta, utrzymanie działa w próżni, a jego ustalenia nie zmieniają żadnych decyzji.

To niewiele czasu. Ale musi mieć przypisane nazwisko.

Co musi być w przekazaniu

Niezależnie od tego, kto przejmuje system, przekazanie powinno zawierać kilka rzeczy, które najłatwiej przygotować przed uruchomieniem, a najtrudniej odtworzyć po nim.

Zestaw ewaluacyjny. Prawdziwe przypadki ze znanymi dobrymi odpowiedziami. Bez niego nikt nie zmierzy, czy system się pogarsza, a monitorowanie jakości staje się deklaracją.

Punkt wyjścia. Obecna jakość, koszt i opóźnienia zapisane w dniu przekazania, żeby późniejsza zmiana była faktem, a nie wrażeniem.

Runbooki i dostępy. Co robić przy awariach, które na pewno się zdarzą, i kto ma do czego dostęp — spisane, a nie przekazane ustnie na ostatnim spotkaniu.

Lista znanych słabości. Przypadki, o których zespół budujący wie, że system radzi sobie z nimi źle. Rzadko powstaje bez wyraźnej prośby, a oszczędza następcom tygodnie odkrywania tego samego.

Kiedy podjąć decyzję

Przed uruchomieniem, nie po. Najtańszy moment jest wtedy, gdy zespół budujący jeszcze jest na miejscu: przekazanie z zestawem ewaluacyjnym, runbookami i dostępami kosztuje wtedy dni. Kilka miesięcy później ktoś musi to odtworzyć z kodu i z pamięci ludzi, którzy pracują już gdzie indziej.

Dobrym testem jest jedno pytanie zadane przed odbiorem: kto dzień po uruchomieniu dostanie pierwszy alert o spadku jakości i co wolno mu zrobić? Jeśli nie ma nazwiska, decyzja o prowadzeniu systemu nie zapadła. Odłożono ją na moment, w którym będzie droższa.

Jeśli system już działa i nikt go nie prowadzi, nie jest za późno. Utrzymanie systemów AI często zaczyna się od systemu, którego nie budowaliśmy, i od zbudowania zestawu ewaluacyjnego, którego wcześniej nie było — z poziomem wsparcia, który z czasem ma maleć, a nie rosnąć.