W tym odcinku dowiesz się jak zrealizować fazę proof of concept rozwiązania AI, aby zwiększyć szansę na jego sukces i osiągnąć założone cele biznesowe.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 51 – jak wdrażać AI w organizacji część 2. W poprzednim odcinku opowiadałem o takim wstępnym etapie, który powinien poprzedzić implementację projektu AI. W zasadzie jest to część tego samego projektu, dlatego możemy mówić o takim etapie analizy, czy wręcz studium wykonalności projektu. Jeżeli nie miałaś/nie miałeś okazji przesłuchać poprzedniego odcinka, to gorąco zachęcam, bo do pewnych kwestii oczywiście odwołuje się, jest to logiczna całość. Rozważania te snułem także w kontekście konsultingu AI, bo nie da się ukryć, że taka początkowa praca, chociaż stanowi całość większego projektu, może być realizowana przez pojedynczego konsultanta, pojedynczą osobę w gruncie rzeczy. Natomiast czy to będzie sytuacja, w której ktoś niezależnie ocenia jakość materiału, sytuację wstępną, czy jest to osoba związana z jakimś większym zespołem, to już jest troszkę inna sprawa. Natomiast przez to, że tak naprawdę wstępny etap to nie jest dużo pracy pod kątem liczby godzin, ale wymaga to pewnego know-how, wymaga to doświadczenia, takiego można powiedzieć drobnego, acz ważnego, chirurgicznego działania, to można tutaj pracować z konsultantem. W tym momencie zakładamy, że ta wstępna analiza przyniosła pozytywny rezultat. Przeanalizowaliśmy cele biznesowe organizacji, dostępne zbiory, bazy danych, hurtownie może. Skonfrontowaliśmy wszystko ze sobą i dochodzimy do wniosku, że z tej mąki może powstać chleb. To porównanie nie jest z całą pewnością przypadkowe, bo od ponad roku wypiekam chleby, żytnie w zasadzie wyłącznie, z własnego zakwasu, też wyhodowanego przez długi czas i choć teraz mogę chyba powiedzieć, że mam już taką niezłą wprawę, przynajmniej w tym jakby jednym konkretnym, chciałem powiedzieć modelu chleba, w tym jednym przepisie. Natomiast jest to doświadczenie okupione licznymi eksperymentami i długim czasem, jaki na to poświęciłem, zwłaszcza jeśli chodzi o pracę właśnie nad odpowiednio mocnym, właściwym zakwasem. Nie chcę oczywiście odpłynąć z tą dygresją za bardzo. Chleby u Kiciora to nie jest sponsor dzisiejszego odcinka. Natomiast o co chodzi? Mimo że już kilkadziesiąt tych bochenków upiekłem, mimo że ponad rok już się tym zajmuję, to nie zawsze mam 100% kontroli, zwłaszcza pod kątem takich detali, mimo że podążam z grubsza tym samym, optymalizowanym, ale wciąż tym samym przepisem. I podobna sytuacja ma miejsce w przypadku implementacji nawet dość sprawdzonych, klasycznych metod AI. Nawet jeżeli rozwiązujemy znane problemy, nawet jeżeli korzystamy z uznanych, sprawdzonych modeli, to jednak nie zawsze możemy mieć gwarancję, zwłaszcza jeżeli celujemy w jakieś konkretne, nie da się ukryć, bardzo wysokie wyniki. Czy w tym konkretnym projekcie, z tymi danymi, sytuacja, to działanie się powiedzie.

Dodam jeszcze może taki disclaimer, jak to ja często lubię takie założenie przyjąć, że skupiam się tu na takich troszkę większych projektach, takich, które wiążą się z pewną pracą inżynierską, nawet może momentami badawczą. Nie mówię w tym odcinku, w ogóle w tym mini cyklu, o wdrażaniu takich gotowych aplikacji, które są tak naprawdę aplikacjami użytkowymi, a to, że korzystają z AI, to po prostu korzystają, bo jest to modne. Mówimy o sytuacji, w której mamy jakiś poważny problem do rozwiązania, nie istnieją dla niego jakieś gotowe rozwiązania, gotowe apki na wszystko. Mamy właśnie jakieś zbiory danych i chcemy po prostu z nich skorzystać, aby faktycznie usprawnić, zautomatyzować jakiś proces za pomocą narzędzia AI i odnieść faktyczne biznesowe korzyści. No dobrze, to od czego zaczynamy? Przede wszystkim musimy sobie rozpisać plan, no bardzo odkrywcze, ale to co jest istotne w tym planie, to to, żeby nastawić się na jak najszybszą weryfikację początkowej koncepcji rozwiązania, na tę analizę wykonalności. Oczywiście ktoś może powiedzieć, że konsultant powinien w pierwszej kolejności stwierdzić, że coś jest wykonalne. No tak, ale najpierw wykonujemy pewną taką pracę, bardziej bym powiedział teoretyczną, czy w ogóle jest sens, jest szansa, czy na przykład komuś udało się połączyć jakieś zbiory danych z określonymi metodami, z określoną skutecznością. Natomiast teraz już mówię o faktycznie wykonaniu pewnego praktycznego, działającego rozwiązania, czyli stworzeniem takiego, można powiedzieć, gdybyśmy odnosili to do jakichś aplikacji webowych czy mobilnych, proof of concept, może niekoniecznie MVP, bo w przypadku AI nie chodzi o to, aby stworzyć jakąś taką prostą wersję aplikacji, w którą już da się klikać, w której już mamy jakieś formularze, już możemy się logować na przykład, czyli mamy jakąś taką pierwszą, bardzo okrojoną, ale działającą wersję. W przypadku rozwiązań AI, zwłaszcza właśnie takich, które mogą się nie powieść, kluczowe jest to, żeby stworzyć taki prototyp, który po prostu przeprowadzi nam pewne eksperymenty na jakiejś porcji danych, którymi dysponujemy. Uzyskamy pewne wyniki, pewne obiektywne wyniki, to znaczy, nie jest to kwestia interpretacji, czy wyniki są dobre, czy złe, tylko będą to pewne miary, takie jak na przykład precyzja, takie jak na przykład czułość, miara F-score, o określonej wartości, będziemy wtedy w stanie stwierdzić, czy zgodnie z założonym planem, ten pierwszy, najpierwszy prototyp, w ogóle zmierza w dobrą stronę. Tak że jest ono niezwykle istotne, bo mimo że nie będziemy mieli wtedy jakichś, powiedzmy, funkcji, to nie jest tak, że to rozwiązanie będzie nam już działać, będziemy mogli sobie do niego, nie wiem, wrzucić dowolny obrazek, dowolne dane, ale będziemy w stanie stwierdzić, czy w ogóle jest sens w nie dalej inwestować. No bo to jest to właśnie, co odróżnia nam projekty AI-owe od projektów chociażby takich zwykłych aplikacji. W przypadku wyceny, planowania, na przykład apki webowej do, nie wiem, zarządzania fakturami w firmie, no w zasadzie nie można powiedzieć, że czegoś się nie da zrobić. To jest tylko kwestia, tylko i aż, budżetu, czasu, oczywiście może być kwestia integracji z zewnętrznymi usługami. Tutaj można się pokusić o to, czy da się w jakiś sposób zintegrować, czy nie, czy dostawca dostarcza pewne mechanizmy. No, a to też na ogół szybko da się sprawdzić w dokumentacji. Natomiast to jest zupełnie co innego, kiedy mówimy o ryzyku czasowym, a zupełnie co innego, kiedy mówimy o projektach AI, o ryzyku, czy w ogóle to nam zadziała, tak jak sobie wymarzyliśmy. No to są, nie da się ukryć, projekty bardziej z gatunku R&D, nawet jeżeli nie prowadzimy takich stricte badań naukowych we właściwym tego słowa znaczeniu. Natomiast tak naprawdę ten pierwszy proof of concept oczywiście bardzo trudno powiedzieć, ile to może zająć tak ogólnie, natomiast w zależności od problemu, w zależności od posiadanych danych, to mogą być różne wartości. Natomiast wciąż myślę, że możemy w większości przypadków mówić o, do takiego pierwszego proof of concept, o dziesiątkach, może małej liczbie setek, ale czasem nawet i kilkunastu godzinach.

W tym momencie może paść pytanie, no to co, to znaczy, że to wszystko jest takie proste, że to zajmuje tak mało czasu? No nie, absolutnie. Natomiast w proof of concept chodzi o to, żeby wziąć pewne gotowe, standardowe, sprawdzone dla danej klasy problemów rozwiązanie, czy na przykład w przypadku rozpoznawania obiektów, rozpoznawania obiektów na zdjęciach, możemy użyć jednej z sieci neuronowych, zaliczanych do konwulsyjnych sieci, jakąś taką podstawową sieć typu ResNet, czy w ogóle klasyfikator taki jak YOLO, skorzystać z pewnej bazy zdjęć, którą na przykład mamy, bo mamy w firmie skatalogowane na przykład produkty i zobaczyć co się stanie. Bez żadnych specjalnych modyfikacji, bez zastanawiania się nad optymalizacjami pod ten konkretny przypadek, po prostu zobaczyć, czy nam to zacznie działać. To nie wymaga wielkiej ilości pracy, to oczywiście wymaga wiedzy, jak to wszystko połączyć. Trochę to jest tak jak z tym takim żarcikiem, że jak grafik robi na przykład logo i zajmuje mu to 10 minut czasu, to klient chce zapłacić za 10 minut czasu pracy. No ale grafik mówi, że żebym ja mógł takie logo zrobić w 10 minut, musiałem się uczyć 10 lat. Wartości są oczywiście przykładowe, natomiast coś w tym jest, że żeby dobrze wybrać, dobrać model i go skonfigurować, to też zajmuje sporo czasu, żeby się tego nauczyć i sporo tak naprawdę pracy eksperymentalnej na konkretnych już przypadkach, na konkretnych case'ach. I nie da się ukryć, że taki prototyp, on oczywiście raczej nie będzie działał jakoś wspaniale, na pewno nieoptymalnie, natomiast on pokaże nam, czy w ogóle wartości, które uzyskujemy, jakoś odnoszą się do tych, które są przez nas oczekiwane. Bo nawet wynik 90%, wartość, która tak myślę intuicyjnie, jak ktoś słyszy, że coś jest na 90%, w 90% działa, to chyba brzmi okej, no ale jeżeli na przykład mówimy o jakichś rozwiązaniach dla medycyny, to 90%, zwłaszcza jeżeli miałoby rozpoznawać jakieś ważne choroby, no to 10% błędnych rozpoznań i to też jeszcze zależy w jaki sposób błędnych, ale już nie będziemy wchodzić w szczegóły miar jakości wyników, natomiast to jest na przykład problem. Ale już, jeżeli na przykład rozwiązanie może uzyskiwać 60% w rozpoznawaniu jakichś wad produkcyjnych, ale ludziom zajmuje to dużo więcej czasu, to i 60% może być całkiem niezłym wynikiem.

Natomiast chciałbym tu zwrócić jeszcze uwagę na jedną rzecz, bo my mówimy o doborze modelu, o doborze jakiejś bazy, no ale ta baza, no właśnie, czasami może być sytuacja, w której po prostu w firmie istnieje baza danych i przez bazę danych niekoniecznie mam tu na myśli jakąś bazę typu SQL, czy jakieś inne nierelacyjne bazy danych, tylko po prostu zbiór danych, chociażby w postaci listy zbioru zdjęć. W przypadku takiego zbioru zdjęć nawet nie zawsze jest potrzeba, żeby były jakieś informacje zawarte w bazie danych takiej właśnie SQL-owej, czy w jakimś pliku, bo same nazwy plików już mogą nam poinstruować, jakiego rodzaju to są produkty, załóżmy przy rozpoznawaniu obrazów, rozpoznawaniu produktów na obrazach i w ten sposób możemy je podzielić, a potem sprawdzić, czy model będzie na takiej bazie działał prawidłowo. Natomiast przygotowanie takiej bazy, zwłaszcza jeżeli jej nie mamy, może zająć zauważalnie więcej czasu niż paradoksalnie może się wydawać, niż przygotowanie do działania modelu sztucznej inteligencji. Z drugiej strony to też nie musi być taki wielki koszt, bo czasami zebranie takich danych, na przykład zrobienie zdjęć produktów, można powierzyć osobom o trochę innych kompetencjach, można tę pracę zrównoleglić, być może komuś z zespołu, kto akurat ma wolne przebiegi, to nie są jakieś bardzo trudne zadania, więc też może okazać się, że koszt takiego prototypu, nawet jeżeli formalnie pod kątem liczby godzin przebijemy na przykład 100 godzin, bo 20 godzin to było konfigurowanie modelu, a 80 to było zbieranie zdjęć, ale sumarycznie ktoś wykonywał tę pracę przy okazji, to zbieranie zdjęć, więc potem może się okazać, że wcale nie było to takie drogie.

No dobrze, to kolejny krok. Spędziliśmy te parędziesiąt, paręnaście, a może sto godzin na jakimś takim prototypie i co dalej? Oceniamy wyniki, mamy wyniki, uruchomiliśmy ten program, ten model i w zasadzie są takie trzy scenariusze. I nie będę tu używał konkretnych wartości procentowych, bo tak jak powiedziałem, one naprawdę zależą od problemu. Ale może być super, może być po prostu dobrze, super, w sensie założyliśmy sobie pewne wyniki, one po prostu nam wyszły. Fajnie. Może być też tragicznie, to znaczy wyniki są bardzo złe, ale co gorsza nie ulegają poprawie na przykład przy dorzuceniu kolejnej porcji danych. Bo może być tak, że jeżeli na przykład baza, którą przygotowaliśmy, była w jakiś sposób, no albo mała po prostu, za mała, albo niezbyt reprezentatywna, tak, albo wręcz zbyt reprezentatywna, to znaczy mieliśmy bazę dwudziestu obrazków, z czego każdy pokazywał co innego i no nawet te wspaniałe sieci neuronowe nie są w stanie się wtedy nauczyć. Natomiast to są problemy, które da się obejść. No trzeba dorzucić więcej zdjęć, więcej próbek danych. A co, jeżeli nawet po takim dorzuceniu, po zauważalnym zwiększeniu procentowo liczby, ilości danych, nic się nie dzieje, to znaczy nie ulega poprawie. No może być tak, że z jakichś przyczyn problem, który chcemy rozwiązać, no niestety łapie się do tej grupy, której to nie da się rozwiązać. To znaczy nie da się rozwiązać, to jest bardzo mocne stwierdzenie, ale na ten moment w takich warunkach, przy takich danych, faktycznie może się nie dać. Wreszcie może być też średnio, to znaczy wyniki nie do końca odpowiadają rzeczywistości, ale no właśnie na przykład w miarę dodawania, poszerzania bazy zdjęć, są one coraz lepsze, nasze miary jakości rosną. Tutaj w zasadzie jakby do czego się sprowadza ten taki podział, który też trudno uznać za jakiś bardzo formalny. Po stworzeniu takiego proof of concept, musimy się z tym zainteresować musimy się zastanowić, czy dalej musimy po prostu trzymać się mniej więcej tej samej metody i tylko dorzucać więcej danych, żeby jak najszerzej pod kątem liczby obsługiwanych przypadków sobie poradzić. I to jest w zasadzie taki scenariusz dość komfortowy. Czy może jednak trzeba ten model optymalizować, czyli dostosować, zmienić, być może stworzyć model taki hybrydowy czy złożony, w którym będziemy mieli kilka metod, różnych metod sztucznej inteligencji, które w pewien inteligentny sposób trzeba też połączyć, prawda. Dużo też zależy od tego, czy my na przykład będziemy korzystać, o tym też w sumie nie wspominałem, ale warto pamiętać, że jeżeli pracujemy na własnych danych, na stosunkowo takich niedużych bazach danych, no to mówimy o takim uczeniu od zera, trenowaniu. Czyli mamy zupełnie tabula rasa, model sztucznej inteligencji, który nic nie wie, nie ma żadnej wiedzy i my po prostu pokazujemy mu wszystko. Wtedy mamy oczywiście większą kontrolę, ale to też po prostu zabiera więcej czasu, więcej kosztuje, wymaga przygotowania większej bazy. Z drugiej strony, to zwłaszcza to pojęcie, gdzieś tam może wróciło do łask, czy zyskało te łaski w kontekście działań z modelami językowymi, LLM, Large Language Models, czy jak ChatGPT, bo tutaj jest kwestia, że te modele są tak gigantyczne, że własnoręczne wytrenowanie, wyuczenie takiego modelu, nie wchodzi w grę dla nikogo poza największymi firmami, bo to są ogromne koszty, setki tysięcy, czy myślę, że już w tym momencie miliony dolarów na wyuczenie jednego modelu. Na stworzenie de facto jednego gigantycznego pliku. Znaczy, może to być wiele plików, ale jakby jest to jedna taka wielka struktura danych. Wtedy mówimy o dostrojeniu. To znaczy, my już dość dobrze wyuczony model, model, który radzi sobie z ogólnymi zadaniami, trochę jak człowiek po studiach, musimy dostroić do naszych zadań, do naszej pracy. Wtedy musimy też przygotować oczywiście bazę danych, natomiast to już wymaga znacznie innego wysiłku, to też są znacznie mniejsze koszty. Tak że jest to coś, co na pewno jest w zasięgu takich firm gotowych nieco zainwestować w rozwiązania sztucznej inteligencji.

Omówiliśmy już sobie te trzy scenariusze, taki pozytywny, gdzie w zasadzie karmimy dalej model danymi i oczywiście to też nie jest tak, że po takim proof of concept wszystko naprawdę będzie działać w stu procentach. Zawsze jakieś optymalizacje są potrzebne, ale jak się uda od razu odkryć dobry kierunek prac, no jest łatwiej po prostu. Mamy taki scenariusz negatywny, być może trzeba wrócić do tablicy i się zastanowić nad zupełnie innym rozwiązaniem dla danego problemu biznesowego. A może jesteśmy gdzieś pośrodku i właśnie optymalizujemy, kombinujemy z modelami, ale generalnie wiemy, że czujemy i tak mamy pewne pierwsze dane, pierwsze wyniki, że da się dany problem rozwiązać. Mniej więcej w ten sposób. Na pewno to jest taki fajny etap, w którym ten gen naukowca warto w sobie odkryć i go gdzieś tam uwypuklić, bo jest to właśnie często seria takich eksperymentów, znowu może niekoniecznie rygorystycznie prowadzonych naukowo, ale pewnych prób częstych błędów, które się uzyskuje, ale też właśnie trial and error. To jest coś, co się często pojawia.

I czy to oznacza, że dochodzimy do końca? No właśnie nie do końca. Bardzo pięknie mi to wyszło. Natomiast okej, załóżmy, że w wyniku tych prac dochodzimy do jakiejś tam skuteczności modelu, jest ona zadowalająca i co dalej? No bo załóżmy, że mamy tę czarną skrzynkę, ona działa, wrzucamy tam nasze dane i wyniki są. No oczywiście wiadomo, że jeżeli nie znamy się na tym od strony technicznej, to ktoś może nas spróbować oszukać, natomiast zakładamy tutaj, że jeżeli prowadzimy pracę z osobami właśnie konsultantami, czy w ogóle specjalistami AI, no to oni mogą się z nami podzielić swoim kodem źródłowym. Możemy go poddać jakiejś analizie, możemy go zaudytować przy pomocy innych specjalistów. Tak że no jakby jesteśmy w stanie co do zasady zweryfikować, czy to nie są fake’owe wyniki.

Natomiast okej, już mamy tę czarną skrzynkę, która działa dobrze. Co dalej? Bo mamy czarną skrzynkę, ona nam mówi, że mamy bardzo ładne procenty, ale to jeszcze nie znaczy, że jesteśmy w stanie realnie skorzystać i odnieść sukces w biznesie. To co dalej, o tym właśnie opowiem w trzeciej części. Jeszcze nie wiem, czy ona się ukaże bezpośrednio w kolejnym odcinku, czy może z drobną przerwą, zobaczymy, ale na pewno niedługo. No a na dzisiaj w sumie to tak jak planowałem, to miał być krótszy odcinek, a wyszedł całkiem regularny. Więc nie pozostaje mi nic innego, jak na dzisiaj podziękować. Bardzo dziękuję za uwagę. Kłaniam się nisko i do usłyszenia.

KONIEC