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.

Julia Rose 5 min czytania
Izometryczna ilustracja świecącego symbolu nieskończoności nad przepływami danych, serwerami i chmurą

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 ITProjekt AI
Działanieokreślone regułamiwyuczone na danych, obarczone niepewnością
Wymaganiamożna je w pełni opisać z górywartości docelowe, które da się potwierdzić dopiero na prawdziwych danych
Testyfunkcja działa albo niejakość mierzona na wielu prawdziwych przypadkach
Po uruchomieniuutrzymanie, gdy coś się zmieniastały monitoring, bo zmieniają się dane
Ryzykobłędy w kodziedane, 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

  1. Analiza: zanim zacznie się budowa, wyjaśniamy proces, dane i spodziewaną wartość.
  2. Proof of concept na prawdziwych danych: pokazujemy, że zadanie da się rozwiązać, łącznie z przypadkami brzegowymi.
  3. MVP na produkcji: pierwsza wersja z prawdziwymi użytkownikami, połączona z istniejącymi systemami.
  4. Rozbudowa: kolejne przypadki i obszary dopiero wtedy, gdy wskaźniki się zgadzają.
  5. 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ę procesu

Najczęś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

O autorce

Julia Rose

Marketing Lead, theBlue.ai

Julia jest w theBlue.ai od 2019 roku i od początku istnienia firmy obserwuje z bliska, jak powstają aplikacje AI dla przedsiębiorstw. Jako Marketing Lead ściśle współpracuje z zespołami inżynierów i doradców, a złożone tematy techniczne przekłada na język zrozumiały dla osób decyzyjnych.

W swoich artykułach pisze o praktycznych doświadczeniach z projektów enterprise AI oraz o wyzwaniach i szansach, jakie AI daje firmom.