Co warto mierzyć w projekcie AI, a czego nie
To jest mała, subiektywna lista. Oparta na tym, co mi samemu sprawiało kłopoty.
| Co warto mierzyć na wczesnym etapie | Czego mierzyć nie warto na MVP |
|---|---|
| Jakość danych wejściowych | ROI projektu |
| Adoption rate - czy ludzie naprawdę używają? | Cost-per-query w produkcji |
| Czas decyzji (przed vs. po AI) | Dokładność modelu w izolacji od kontekstu |
| Liczba błędów wykrytych przez użytkowników | NPS po jednym tygodniu |
| Czas potrzebny na poprawkę błędu modelu | Porównanie z rozwiązaniami konkurencji |
Lista jest subiektywna i zależy od etapu projektu oraz rodzaju systemu. Co ma sens na etapie pilota, może być złą miarą w dojrzałym systemie produkcyjnym - i na odwrót.
Dlaczego ROI jest złą miarą na MVP? Bo MVP to hipoteza. Mierzymy ROI hipotezy, zanim wiemy, czy hipoteza jest prawdziwa. To jak ocenianie restauracji po pierwszym daniu, które wyszło z kuchni próbnej.
Adoption rate to często niedoceniana miara. Nie pytaj "ile razy wywołano model." Pytaj "ile razy użytkownik skorzystał z wyniku modelu." To różne liczby. Czasem bardzo różne.
Co się dzieje po prezentacji na zarządzie
Wróćmy do firmy z początku artykułu.
Maj. Prezentacja wychodzi świetnie. Same zielone KPI. Zarząd jest zachwycony. Projekt dostaje finansowanie. Wchodzi w produkcję.
Czerwiec. Użytkownicy zaczynają się skarżyć. Model robi błędy, których nikt nie zaplanował w KPI. Bo KPI nie mierzyły błędów. Mierzyły szybkość odpowiedzi.
Lipiec. Pierwsza poważna wpadka. Model zaproponował złą kategorię w systemie klasyfikacji. Trzy tygodnie ręcznych korekt.
Sierpień. Project manager jest zaskoczony. "Przecież KPI były dobre." Są nadal dobre. To jest właśnie problem.
Grudzień. Raport roczny. Projekt AI opisany jako "w trakcie stabilizacji." To eufemizm. Dług techniczny. Problemy z jakością danych, których nikt nie zmierzył w maju. Sześć miesięcy później rzeczy, które były widoczne od początku, ale nikt nie chciał ich widzieć.
To nie jest hipoteza. To jest scenariusz, który widziałem w różnych wariantach kilka razy.
Jak projektować KPI, żeby się uczyć, a nie tylko wygrywać
Trzy zasady, które stosuję w praktyce.
Zasada 1: Pytaj "czego chcemy się dowiedzieć?", nie "jak wypaść dobrze?"
Przed każdą miarą zadaj jedno pytanie: co ta liczba mówi nam o tym, czy robimy właściwą rzecz? Jeśli nie potrafi odpowiedzieć na to pytanie - wyrzuć ją z dashboardu.
Przykład: "Czas odpowiedzi modelu" nie mówi nic o tym, czy robimy właściwą rzecz. "Procent użytkowników, którzy skorzystali z rekomendacji modelu" - już tak.
Zasada 2: Mierz wcześnie i brzydko
Brzydka miara, zmierzona wcześnie, jest lepsza niż czysta miara zmierzona za późno. Nie czekaj na produkcję. Mierz już na etapie pilota. Nawet jeśli dane są niepełne.
Wcześnie zmierzone, brzydkie dane dają czas na korektę. Późno zmierzone, piękne dane dają materiał na prezentację. Tylko tyle.
Zasada 3: Separuj learning metrics od reporting metrics
Learning metrics to miary, które pomagają ci zrozumieć, co działa i co nie. Reporting metrics to miary, które pokazujesz zarządowi. To nie muszą być te same liczby.
Jak to wygląda w praktyce? Dwa oddzielne widoki. Dashboard zarządu: procent użytkowników korzystających z rekomendacji modelu, czas decyzji przed/po, liczba eskalacji. Dashboard teamu: rozkład typów błędów, adoption rate z podziałem na segmenty użytkowników, jakość danych wejściowych. Każdy dostaje to, czego potrzebuje - bez filtrowania.
Zarząd potrzebuje dowodów postępu. Team potrzebuje sygnałów do uczenia się. Myślenie, że jeden dashboard obsłuży oba cele, jest źródłem wielu problemów.
Mała, uczciwa refleksja
Nie piszę tego artykułu z pozycji osoby, która zawsze robiła to dobrze. Byłem w tej sali konferencyjnej. Widziałem ten wybór. I czasem nie miałem siły - albo odwagi - żeby powiedzieć głośno: "to jest złe pytanie."
Pressure na dobry wynik jest realna. Zarząd chce zielonego. Sponsor projektu chce zielonego. Ty też chcesz zielonego - bo projekt jest ważny i naprawdę chcesz więcej zasobów.
Ale zielone KPI w czerwcu i czerwone w grudniu to jest scenariusz znacznie gorszy niż żółte KPI przez cały rok z uczciwą informacją, co się uczymy.
Tylko że żółte KPI wymagają odwagi. I zaufania, że zarząd doceni szczerość nad marketingiem.
Jak rozmawiać z zarządem, który chce samej zieleni? Jedna technika, która mi pomogła: zamiast "mamy żółte KPI" - "mamy wczesny sygnał o problemie, który możemy naprawić teraz za X, albo później za 10X." Zarząd nie chce żółtego. Zarząd chce kontroli nad ryzykiem. Żółte KPI z kontekstem to nie porażka - to zarządzanie ryzykiem.
Czy w Twoim projekcie AI masz KPI, które mówią Ci coś realnego? A może kilka z nich jest tam głównie po to, żeby dobrze wyglądały w maju?