Cykl życia projektu AI: Zdefiniuj problem — Transcript

Zanim przejdziemy do szczegółów, pokażę wam kompletny cykl życia projektu AI. To nie jest teoretyczny model, to praktyczne kroki, które wypracowałem przy dziesiątkach projektów.

I uwaga, kolejność tych kroków jest kluczowa. Często widzę firmy, które zaczynają od trenowania modelu albo zatrudniania data scientistów, a potem zastanawiają się nad problemem do rozwiązania.

To jak budowanie domu od dachu. Zaczynamy od zdefiniowania problemu. I nie, wdrożenie AI to nie jest problem.

Problem to na przykład zmniejszenie liczby zwrotów o 30% albo skrócenie czasu obsługi klienta o połowę.

Potem szukamy danych. I tu ciekawostka, czasem na tym etapie okazuje się, że projekt nie ma sensu, bo po prostu nie mamy odpowiednich danych.

Lepiej wiedzieć to na początku niż po wydaniu budżetu. Krok trzeci to często pomijany, ale kluczowy element: próba rozwiązania problemu bez AI.

Czasem proste reguły if-else dają 80% rezultatu przy 20% wysiłku. Dopiero potem przechodzimy do tworzenia zabezpieczeń, trenowania modelu, zbierania feedbacku i monitorowania wyników.

Ten cykl nie jest liniowy. Często wracamy do poprzednich kroków, uczymy się i dostosowujemy podejście.

Ale zawsze zaczynamy od jasno zdefiniowanego problemu biznesowego. W kolejnych częściach przejdziemy przez każdy z tych elementów szczegółowo, pokazując konkretne przykłady i narzędzia, które możecie zastosować w swoich projektach.

Zacznijmy od zdefiniowania problemu. Jak już pewnie zauważyliście, kładę na to szczególny nacisk. Aby się nie powtarzać i dać wam konkretne narzędzie, omówimy sobie prosty framework RIGC, który stworzyłem, żeby odpowiedzieć sobie na pytanie, czy dany problem nadaje się dla AI.

Nawiązując do popularnych memów o RIGC, czyli rozum i godność człowieka, stworzyłem podobny skrót dla projektów AI: RIGC.

Tak jak RIGC określa, czy ktoś ma rozum, tak RIGC pomoże nam określić, czy nasz projekt AI ma sens.

RIGC składa się z czterech kluczowych elementów: R jak Relevant, czyli istotność, czyli czy projekt bezpośrednio wpływa na kluczowe cele biznesowe; I jak Impactful, czyli wpływ, czy możemy wymiernie określić potencjalne korzyści z tego projektu; G jak Grounded in Data,

czyli oparcie w danych, czy mamy dane potrzebne do realizacji; i wreszcie C, Compatible, kompatybilność, czy rozwiązanie zintegruje się z obecnymi operacjami naszej firmy.

Zobaczmy, jak to działa w praktyce na przykładzie hipotetycznej firmy telekomunikacyjnej, która chciała wdrożyć chatbota do obsługi klienta.

Relevant? Jak najbardziej. Firma miała problem z poziomem satysfakcji klientów, a czas odpowiedzi był kluczowym czynnikiem. Chatbot bezpośrednio wspierał ich strategiczny cel poprawy doświadczenia klienta.

Impactful? Liczby mówiły same za siebie, analiza pokazała, że natychmiastowe odpowiedzi na częste pytania mogły znacząco odciążyć zespół i poprawić satysfakcję klientów.

Pomyślcie, każda minuta zaoszczędzona w czasie odpowiedzi bezpośrednio przekłada się na doświadczenie klienta. Grounded in Data? Tu często firmy się potykają, ale ten telekom miał asa w rękawie: lata szczegółowo zapisanych interakcji z obsługą klienta.

Tak, dane wymagały czyszczenia, ale fundamenty były solidne. I wreszcie Compatible. Istniejąca platforma obsługi klienta mogła być zintegrowana z rozwiązaniem chatbota, choć wymagało to pewnych dostosowań w procesach pracy.

Ta systematyczna analiza dała im pewność, by działać. Ale jest tu kluczowy wniosek, bez któregokolwiek z tych elementów projekt mógł się nie udać.

Gdyby nie mieli historycznych danych z czatów, albo gdyby ich systemy nie mogły zintegrować rozwiązania, rozmawialibyśmy o zupełnie innym wyniku.

Użyteczność RIGC tkwi w prostocie. Nie potrzebujecie skomplikowanych kalkulacji czy niekończących się spotkań. Tylko cztery proste pytania, które mogą uchronić przed inwestowaniem w niewłaściwe rozwiązanie.

Zobaczmy teraz inny przykład zastosowania tego frameworku, wyszukiwanie produktów za pomocą obrazów w sklepie internetowym.

Brzmi świetnie, prawda? Ale diabeł tkwi w szczegółach. Relevant? Na pierwszy rzut oka wygląda obiecująco.

Inicjatywa faktycznie wpisuje się w strategiczny cel firmy. Chcemy zwiększyć satysfakcję i konwersję użytkowników poprzez lepszą personalizację, więc ten element możemy zaliczyć na zielono.

Impactful? Tu zaczynają się schody. Owszem, to innowacyjne rozwiązanie, które mogłoby wyróżnić nas na rynku, ale brakuje nam twardych danych wskazujących, że użytkownicy faktycznie chcieliby z tego korzystać i że przełoży się to na większą sprzedaż.

To klasyczny przykład rozwiązania w poszukiwaniu problemu. Grounded in Data? I tu trafiamy na ścianę.

Choć mamy zdjęcia produktów, to brakuje nam kluczowych metadanych potrzebnych do skutecznego wytrenowania modelu. To trochę jak próba nauczenia kogoś języka obcego bez słownika.

Teoretycznie możliwe, ale praktycznie bardzo trudne i nieefektywne. I jasne, moglibyśmy spróbować obejść ten problem, integrując zewnętrzne API jak Vertex AI do automatycznego tagowania produktów.

Ale to nie tylko dodatkowo komplikuje cały projekt, ale też znacząco podnosi koszty operacyjne. Zamiast rozwiązywać jeden problem, dokładamy sobie kolejne, i techniczne, i finansowe. To dobry przykład tego, jak próba obejścia braku danych może prowadzić do jeszcze większej złożoności projektu. Czasem lepiej przyznać,

że nie jesteśmy jeszcze gotowi na dane rozwiązanie, niż budować skomplikowaną konstrukcję workaroundów. I wreszcie Compatible. Technicznie rzecz biorąc, moglibyśmy to zaimplementować w naszej aplikacji mobilnej, ale wymagałoby to znaczących nakładów finansowych i zasobów technicznych. To nie jest coś, co zrobimy w weekend z jednym z programistów.

W przeciwieństwie do naszego pierwszego przykładu z chatbotem, ten projekt nie przechodzi frameworku RIGC. Szczególnie czerwona flaga przy danych powinna nas zatrzymać.

To klasyczny przykład sytuacji, gdzie lepiej poczekać i najpierw zainwestować w uporządkowanie danych, niż rzucać się na ambitne wdrożenie bez solidnych fundamentów.

Pamiętajcie, RIGC to nie tylko narzędzie do oceny projektów, ale też mapa drogowa pokazująca, co musimy naprawić, zanim ruszymy z implementacją. W tym przypadku, zamiast forsować wdrożenie za wszelką cenę, powinniśmy skupić się na budowie solidnej bazy metadanych produktowych.

Proponuję trzy proste reguły kciuka, które pomogą szybko ocenić, czy dany problem faktycznie nadaje się do rozwiązania przez machine learning.

Pierwsza reguła, personalizacja czy customizacja. Jest zasadnicza różnica między pozwalaniem użytkownikom na ręczne dostosowywanie czegoś, czyli customizacja, a automatycznym dostosowywaniem się do ich zachowań, czyli personalizacją. Jeśli użytkownik sam może łatwo ustawić swoje preferencje, machine learning prawdopodobnie nie jest potrzebny. Ale jeśli wzorce są zbyt złożone

lub zmieniają się w czasie, to dobry kandydat dla machine learning. Przykład? Netflix. Nikt nie chce ręcznie ustawiać swoich preferencji filmowych, ale algorytm może je wywnioskować z historii oglądania.

Druga reguła, rozpoznawanie lub łączenie wzorów. To jak filtr spamu w waszej skrzynce mailowej. Nikt z nas nie chciałby ręcznie przeglądać każdego maila i sprawdzać, czy to spam, zwłaszcza że oszuści ciągle wymyślają nowe sztuczki. Machine learning świetnie sobie z tym radzi, bo potrafi rozpoznawać subtelne wzorce

w treści, nagłówkach i zachowaniu nadawców, automatycznie dostosowując się do nowych typów spamu. I wreszcie trzecia reguła, powtarzalna sekwencja akcji.

Weźmy obsługę klienta w Uberze, gdy zgłaszacie problem z przejazdem. Gdyby to był prosty, powtarzalny proces, na przykład jeśli kierowca się spóźnił, zwróć 10%, wystarczyłyby proste reguły if-else. Ale rzeczywistość jest bardziej skomplikowana, trzeba wziąć pod uwagę historię klienta, typ problemu, lokalizację, porę dnia,

warunki pogodowe i wiele innych czynników. Tu machine learning może pomóc zadecydować, jaką formę rekompensaty zaproponować, bazując na tysiącach podobnych przypadków i ich rozwiązań.