Enterprise AI i strategia · Podejście do projektu
Dlaczego tak wiele projektów AI upada, zanim trafi na produkcję?
Wiele projektów AI robi wrażenie na etapie pilotażu, a potem nigdy nie trafia do codziennej pracy. Często dlatego, że planuje się je jak klasyczne projekty IT: ze sztywnymi wymaganiami, terminem odbioru i przekonaniem, że praca kończy się w dniu uruchomienia. AI zachowuje się jednak inaczej.
Najważniejsze w skrócie
- Według IDC 88% projektów AI typu proof of concept nie trafia na produkcję w szerokiej skali, a spośród 33 pilotaży wdrożono tylko cztery.
- Często przytaczane 85% Gartnera to prognoza z 2018 roku dotycząca błędnych wyników spowodowanych stronniczością (bias), a nie odsetek nieudanych projektów.
- Wyniki AI zależą od danych. Jak dobry będzie model, okazuje się dopiero na prawdziwych danych.
- Po uruchomieniu zmieniają się dane i warunki. Dlatego AI wymaga stałego monitoringu i dostosowywania.
Co mówią liczby
Najczęściej cytowane aktualne dane pochodzą od IDC: 88% zbadanych projektów AI typu proof of concept nie trafia na produkcję w szerokiej skali. Z 33 uruchomionych pilotaży na produkcję weszły tylko cztery.
Źródło: CIO.com o badaniu IDC przeprowadzonym z Lenovo
Często można też przeczytać, że według Gartnera 85% wszystkich projektów AI kończy się niepowodzeniem. Źródło nie mówi jednak nic takiego. W lutym 2018 roku Gartner przewidywał, że do 2022 roku 85% projektów AI będzie dawać błędne wyniki z powodu stronniczości (bias) w danych, algorytmach lub zespołach odpowiedzialnych za zarządzanie nimi. Prognoza nadal wskazuje, gdzie leży ryzyko: w danych i w podejściu do projektu.
Źródło: Gartner, komunikat prasowy z 13 lutego 2018
Czym projekty AI różnią się od projektów IT
W klasycznym oprogramowaniu wynik każdego kroku programu da się przewidzieć. Modele AI uczą się wzorców z danych i zwracają prawdopodobieństwa. To zasadniczo zmienia sposób planowania:
| Klasyczny projekt IT | Projekt AI | |
|---|---|---|
| Działanie | określone regułami | wyuczone na danych, obarczone niepewnością |
| Wymagania | można je w pełni opisać z góry | wartości docelowe, które da się potwierdzić dopiero na prawdziwych danych |
| Testy | funkcja działa albo nie | jakość mierzona na wielu prawdziwych przypadkach |
| Po uruchomieniu | utrzymanie, gdy coś się zmienia | stały monitoring, bo zmieniają się dane |
| Ryzyko | błędy w kodzie | dane, które nie odpowiadają rzeczywistości |
Dane i oczekiwania
Model jest tak dobry jak dane, na których się uczy, i to, jak wiernie odzwierciedlają one rzeczywistość. Jeśli dane treningowe zbiera się wyłącznie w kontrolowanych warunkach, w codziennym użyciu model często radzi sobie znacznie gorzej. Do tego dochodzą przypadki brzegowe, których brakuje w zbiorze danych.
Częstym błędem jest oczekiwanie bardzo wysokich wskaźników, zanim wiadomo, na ile dobrze da się dziś rozwiązać dane zadanie i czy są wiarygodne dane. Dlatego na początku trzeba zrozumieć problem biznesowy, sprawdzić dane i uzgodnić ze wszystkimi zaangażowanymi realistyczne wartości docelowe.
Po uruchomieniu: dane się zmieniają
W klasycznym oprogramowaniu projekt często kończy się odbiorem i okresem wsparcia. W AI właśnie wtedy zaczyna się nowy etap. Z czasem zmienia się rozkład danych, czyli pojawia się tzw. dryf danych (data drift): klienci zachowują się inaczej, zmieniają się produkty i formularze, pojawiają się nowe pojęcia. Model, który na to nie reaguje, stopniowo działa coraz gorzej.
To samo dotyczy aplikacji opartych na dużych modelach językowych. Znają one tylko swoje dane treningowe, a zmiana modelu u dostawcy czy nowe dokumenty wpływają na wyniki. Dlatego każda aplikacja AI działająca na produkcji potrzebuje:
- Monitoringu: jakość, błędy i koszty są mierzone na bieżąco.
- Zbiorów testowych: zmiany w modelu, prompcie lub danych są sprawdzane przed użyciem.
- Dostosowywania: modele trenuje się ponownie albo aktualizuje prompty i bazę wiedzy.
- Odpowiedzialności: jeden zespół jest właścicielem rozwiązania i ma na nie czas.
Jak to zorganizować, opisujemy w artykułach o MLOps i obserwowalności LLM.
Podejście, które prowadzi do wdrożenia produkcyjnego
- Analiza: zanim zacznie się budowa, wyjaśniamy proces, dane i spodziewaną wartość.
- Proof of concept na prawdziwych danych: pokazujemy, że zadanie da się rozwiązać, łącznie z przypadkami brzegowymi.
- MVP na produkcji: pierwsza wersja z prawdziwymi użytkownikami, połączona z istniejącymi systemami.
- Rozbudowa: kolejne przypadki i obszary dopiero wtedy, gdy wskaźniki się zgadzają.
- Utrzymanie: monitoring, dostosowywanie i jasna odpowiedzialność zaplanowane od początku.
Jak ta droga wygląda w naszych projektach, opisujemy w artykule Jak budujemy AI, które działa: podejście MVP-first. O agentach AI piszemy osobno w tekście Pilotaż działał, produkcja już nie.
Chcesz, żeby Twój projekt AI trafił na produkcję?
Razem z Tobą sprawdzamy proces, dane i cele, a potem planujemy drogę od pierwszego testu do utrzymania.
Zapytaj o analizę procesuNajczęściej zadawane pytania
Częste przyczyny to dane, które nie odpowiadają rzeczywistości, wysokie oczekiwania bez wcześniejszego sprawdzenia danych, brak integracji z istniejącymi systemami i założenie, że praca kończy się w dniu uruchomienia.
Nie do końca. W 2018 roku Gartner przewidywał, że do 2022 roku 85% projektów AI będzie dawać błędne wyniki z powodu stronniczości w danych, algorytmach lub zespołach odpowiedzialnych za zarządzanie nimi.
To stopniowa zmiana danych po uruchomieniu, np. na skutek nowych zachowań klientów, nowych produktów czy nowych pojęć. Model, który nie jest dostosowywany, z czasem daje gorsze wyniki.
Przez analizę procesu i danych, proof of concept na prawdziwych danych, MVP na produkcji, stopniową rozbudowę oraz monitoring i dostosowywanie zaplanowane od samego początku.
Julia Rose