Automatyzacja testów dzięki Machine Learning

Gościem tej rozmowy jest Daniel Kornaś, który opowie o swoich doświadczeniach w branży IT, w szczególności w testowaniu software’u. Daniel urodził się w Chicago, niedawno przeprowadził się do Polski i pracuje w Nokii. W pewnym momencie swojego życia stwierdził, że w klasycznym testowaniu czegoś mu brakuje, nie jest to wystarczająco efektywne.

Zaczął eksperymentować, inspirować się dostępnymi technologiami, narzędziami i m.in. wprowadził automatyzację. Później poznał uczenie maszynowe i w ten sposób zaczął rozwijać projekty. Jest to bardzo ciekawa i inspirująca historia. Gdy zaczął pracę w Nokii, to brakowało pewnego elementu, który właśnie on dodał – uczenie maszynowe oraz tzw. sztuczna inteligencja. Daniel opowie o całej ścieżce, którą przeszedł od pomysłu do wdrożenia, trudnościach po drodze oraz innych ciekawostkach. 

---

Zanim przejdziemy do wywiadu, to podzielę się kilkoma ogłoszeniami i wydarzeniami, które odbędą się niebawem i mogą Cię zainteresować.

Wspominałem ostatnio o webinarium o Prawie Pareta i już teraz chcę Cię zaprosić na kontynuację tego tematu 27 sierpnia. Porozmawiamy między innymi o inwestowaniu 20% czasu, by dostawać 80% wartości, czyli jak robić mniej, by zyskać więcej.

Ten temat pojawił się także w ostatnim odcinku podcastu.

Webinar jest bezpłatny, a jego uczestnicy otrzymają unikatowe notatki z kodem, co pozwoli na samodzielne odtworzenie pokazywanych procesów. Dołączyć do kolejnego webinarium możesz poprzez dedykowaną stronę.

Na jesień ruszają również trzy kursy online od Data Workshop. ⬇️⬇️⬇️

✅ Pierwszy to „Praktyczne wprowadzenie do Pythona dla ML„, które umożliwia analizowanie danych. Jest to coś innego niż to, co zwykle jest dostępne na rynku. Kurs ten rusza 14 września. 

✅ Drugi kurs to „Praktyczne uczenie maszynowe od podstaw”, który ruszy 5 października. 

✅ Trzeci kurs, związany z przetwarzaniem języka naturalnego albo tzw. NLP, rusza 28 września.

Z mojej rozmowy z Danielem dowiesz się o drugim projekcie, który teraz realizują w Nokii, który ma globalny wpływ na biznes. Będę pokazywać na innym przykładzie, w jaki sposób można analizować dane i przypisywać pewne etykietki lub klasy. Ten problem można zastosować przy różnych projektach, np. jeżeli to jest linia wsparcia, a od użytkownika spływają inputy, trzeba przypisać do kolejki „a”, „b” czy „c”.

To są najnowsze rzeczy na dzień dzisiejszy. Na szczęście to wszystko jest dostępne, ale naprawdę trzeba czasami się postarać i znaleźć te informacje i umieć to odpowiednio zinterpretować, aby można było to zastosować. Zrobiłem to za Ciebie, wystarczy tylko dołączyć do kursu. 

🚀 Przypominam, że w sierpniu obowiązuje zniżka 10%. 🚀

---

---

---

Przechodzimy do wywiadu z gościem 🙂

Cześć Daniel. Przedstaw się: kim jesteś, czym się zajmujesz, gdzie mieszkasz?

Cześć. Jestem Daniel Kornaś. Jestem Machine Learning Technical Lead w Nokii. Zajmujemy się tam głównie pracą na siecią 5G, 4G, jak również tworzeniem różnych komponentów stacji bazowych. Ja głównie zajmuję się projektem, który dotyczy machine learning i wykorzystaniem tej technologii do usprawnienia wykrywania różnych problemów w testach logowych. 

A skąd pochodzę? Zawsze lubię mówić, że pochodzę z tzw. drugiej stolicy Polski czyli z Chicago. Tam się urodziłem, ale potem przeprowadziłem się właśnie do Polski na studia i teraz tutaj jestem na stałe i pracuję. 

I jak się czujesz?

Bardzo dobrze. Bardzo fajnie się pracuje. Bardzo mi się podoba Polska. Wolę mieszkać w Polsce niż w Ameryce. 

Powiedz, co ostatnio fajnego przeczytałeś i dlaczego akurat warto to przeczytać? 

Za dużo nie czytam, bardziej lubię słuchać książek. Jest taka jedna ciekawa książka, którą ostatnio przeczytałem. Niestety jeszcze chyba nie ma jej w wersji polskiej. Wiem, że poprzednie książki tego autora, zostały przetłumaczone na polski.

Mamy zespół, mamy jakiś projekt, dążymy do jakiegoś celu i co musimy zrobić, aby go osiągnąć. 

Jest też mowa o zaufaniu. Bardzo ciekawą rzecz się nauczyłem, mianowicie, że egoizm jest bardzo dużym problemem i np. żeby zbudować zaufanie z pracownikiem, to jak mamy pewien problem, to zamiast powiedzieć mu co ma zrobić, można mu dać szansę, żeby sam mógł rozwiązać ten problem.

Po pierwsze pomaga to w zbudowaniu zaufania, a po drugie, że egoizm czasami tutaj wkracza i zawsze jest tak, że mój pomysł jest lepszy niż Twój. Jeśli ktoś wymyśli swoje rozwiązanie, to będzie bardziej chętny, żeby nad tym popracować i je rozwiązać. Jest bardzo dużo takich ciekawych rzeczy i bardzo mi się podoba ten autor. Gorąco polecam wszystkim.

Zarządzenie, egoizm to faktycznie osobny wątek. Możnaby o tym długo rozmawiać, a w szczególności w branży IT, jeżeli chodzi o programistów. Często są to osoby z mocnym zdaniem i czasem się zaczynają takie wojny na pustym miejscu, czy używać to narzędzie czy inne, a tak naprawdę to jest tylko narzędzie. 

Myślę, że warto porozmawiać na temat Twojej ścieżki kariery, jeżeli chodzi o to, jak zacząłeś. Wkroczyłeś w IT już ponad 5 lat temu. Opowiedz trochę o tym, jakie masz doświadczenia?

Moja kariera w Nokii zaczęła się od tego, że byłem testerem manualnym software’u. Musiałem ręcznie wpisać różne parametry, sprawdzić, czy to poprawnie działa itd. Takie taski różne bardzo długo trwały i stwierdziłem, że musi być jakiś lepszy sposób, żeby to zrobić.

Nie można tak siedzieć i tak długo to robić, więc zacząłem myśleć i kombinować, np. jak napisać jakiś skrypt, który by mógł automatyzować trochę nudne taski. Dzięki temu, zacząłem szukać różnych usprawnień i jak można je wykorzystać. Generalnie ta tematyka automatyzacji różnych rzeczy bardzo mnie zainteresowała.

Przez to zacząłem się rozwijać i dalej robiłem przeróżne testy, żeby usprawnić np. sprawdzanie wyników (też pisałem przeróżne skrypty itd.). 

Pewnego dnia, około 2-3 lata temu, Nokia wprowadziła ideę uczenia maszynowego w swoje struktury, widząc w tym spory potencjał. Właśnie wtedy zaczęła się burza mózgów w różnych zespołach i lokalizacjach, jak możemy wykorzystać tę technologię. Dzięki temu powstał mój projekt – analiza różnych metryk, które są generowane przez stacje bazowe i używanie tego do testów regresyjnych, żeby zautomatyzować sprawdzanie wyników i wykrywanie potencjalnych problemów, których tester mógł ewentualnie nie zauważyć.

Dzięki temu, gdy ten projekt się rozwinął, pojawił się inny, który miał większy wpływ na całą Nokię – tj. usprawnienie całego procesu wykrywania różnych problemów, które występują w testach, żeby to szybciej i lepiej można było znaleźć. 

Można podsumować tak, że testowałeś pewne rzeczy, próbowałeś wykrywać i sprawiać, żeby rzeczy działały stabilnie i tak zacząłeś dostrzegać, że się nudzicie i powtarzacie w kółko pewne elementy. Pomyślałeś, że tutaj być może jest jakieś narzędzie, którym jest automatyzacja i tam dalej ML jest całkiem blisko. 

Załóżmy, że czyta nas teraz osoba, która pracuje w IT. Jest albo programistą, albo osobą techniczną, albo na pograniczu – tester, który sprawdza oprogramowanie w ten czy inny sposób wykorzystując kodowanie (bo to nie zawsze w sumie jest wymagane).

Na ile ta ścieżka przejścia jest trudna? Na czym polega ta trudność? Co u Ciebie sprawiało największe trudności i jak sobie z tym radziłeś?

Generalnie nie trzeba bardzo dużo wiedzy. Nie ma wysokiego progu, żeby w ogóle zacząć. Powiedziałbym, że właśnie bardzo łatwo można zacząć. Mówiłem w jednej prezentacji na naszej konferencji Test Dive, jak łatwo można zacząć prototypować w machine learning. Najpopularniejsza biblioteka to jest właśnie wykorzystanie języka Python i tam są różne już gotowe biblioteki.

Tam są różne modele, które można wykorzystać i zacząć używać od ręki. Największym problemem jest to, że trzeba pomyśleć, jak można wykorzystać te modele, do czego one tak naprawdę służą i co chcemy rozwiązać. Gdy mieliśmy tę burzę mózgów w naszym zespole, to my nad tym się zastanawialiśmy – co by można było tu usprawnić, w jaki sposób, czy to jest możliwe lub nie.

W końcu zdecydowaliśmy np. analizę tych różnych metryk, bo mamy bardzo dużo danych, zestaw historycznych danych z poprzednich testów i mamy to wszystko agregowane, bo trzeba na czymś uczyć te modele. Bez tych informacji ciężko jest stworzyć taki model. Dzięki temu, że mieliśmy już mniej więcej takie gotowe testy z rezultatami, to mogliśmy taki całkiem prosty model stworzyć.

Oczywiście, jako początkujący nie można powiedzieć wprost, który model faktycznie będzie najlepszy, bo to jest bardzo trudne do stwierdzenia – trzeba testować. Można ewentualnie ograniczyć niektóre modele. Właśnie zaczęliśmy od jednego, drugiego modelu.

Trochę bawiliśmy w Random Forest, aż w końcu wylądowaliśmy z XGBoostem, który wychodził najlepiej. Nie mieliśmy żadnych super komputerów, więc niestety uczenie takich modeli dłużej zajmowało, ale w końcu udało nam się zrobić całkiem dobry model, który miał dokładność powyżej 90% i osiągał bardzo dobre wyniki. Jesteśmy dumni z tego, co zbudowaliśmy. Zajęło to trochę czasu, dużo bawienia się, ale naprawdę stworzyliśmy fantastyczną rzecz.

O tym projekcie jeszcze dokładniej porozmawiamy. Chciałem zapytać o to, jak wygląda to przejście. Kiedyś miałem prezentację na temat Programmist Advancer albo Full-Stack Developer, w której próbowałem wyjaśnić, że ten Full-Stack Developer z czasem (a ten czas już nastąpił lub następuje teraz) będzie m.in. też zawierać element związany z uczeniem maszynowym.

Tutaj co prawda też trzeba powiedzieć wprost – to nie chodzi o to, że każdy przy okazji się stanie ekspertem ML, ale też tego nikt nie oczekuje. Oczywiście jest pewna wiedza koncepcyjna, którą trzeba zdobyć. To nie jest tak, że wystarczy sekunda i już wszystko wiesz, ale z drugiej strony, faktycznie wejście teraz do obszaru ML jest zdecydowanie łatwiejsze niż 5 czy 7 lat temu. 

Pracujesz w Nokii. 

Wyobraźmy sobie, że mamy ileś tam punktów – punkt „a”, „b”, „c”, „d” i „e”, czyli: 

„a” – moment, kiedy w danej firmie nic się nie mówi na temat AI, ML, nikt nawet nie wie, co to jest,

„b” – ktoś poszedł na konferencję albo meetup i tam na korytarzu zagaduje kolegę: „Słuchaj, jest takie coś jak ML. Może my też chcielibyśmy to użyć?”

„c”- przynajmniej jedna osoba dojrzała, żeby spróbować zrobić po cichu prototyp, niekoniecznie działający, ale przynajmniej już się zaczyna grzebać w danych i być może jakieś już wychodzą wyniki,

„d” – pojawia się zespół, przynajmniej jednoosobowy i ta osoba pracuje już nad tym normalnie w godzinach pracy, to jest już oficjalny projekt i są już pewne oczekiwania wobec niego,

„e” – moment, kiedy już coś udało się wytworzyć i faktycznie to dało wartość dodaną, udało się to już wdrożyć na produkcję.

Czy udało Ci się zobaczyć te wszystkie fazy w Nokii?

Ile zajęło czasu, przejście z punktu „a” do punktu „e”? 

Ile zajęło czasu przejście pomiędzy tymi punktami czyli z punktu „a” do punktu „b”, z punktu „b” do punktu „c” itd.? 

Mogę powiedzieć, że raczej wszystkie punkty widziałem. Jak zacząłem pracować w Nokii, to nie słyszałem, żeby cokolwiek było robione z uczeniem maszynowym. Nie wiedziałem nawet, że ktokolwiek się zajmuje takimi rzeczami.

Dopiero z rok później, wyszła taka oficjalna inicjatywa, przedstawiona przez naszego CEO, że uczenie maszynowe jest przyszłością i powinniśmy zacząć myśleć na ten temat. Wtedy zaczęły się pojawiać różne szkolenia dla nas, żebyśmy zrozumieli, co to jest machine learning, jak to działa, do czego można tego używać.

Było to wytłumaczone wysokopoziomowo, żeby wprowadzić nas wszystkich. Miesiąc, dwa później był drugi etap, gdzie różne zespoły, z różnych lokalizacji, zaczęły robić burzę mózgów. Zaczęli myśleć, jak można wykorzystać machine learning i naprawdę jest mnóstwo pomysłów, które można ewentualnie zastosować.

Potrzeba jednak do tego odpowiednich osób, czasu i pieniędzy, żeby można było w to zainwestować i coś takiego zrobić. Małymi kroczkami, zaczęło się od 1-2 osób z innym pomysłem, żeby coś zacząć prototypować. Właśnie tak zaczęło się ze mną, miałem jeszcze dwóch kolegów, którzy pomagali z tym projektem.

Nasza przygoda zaczęła się w jednym miesiącu i to trwało kilka miesięcy (prawie do roku). Uczyliśmy się cały czas jak zbudować model, czego trzeba, jak byśmy to dodali do modelu, w jaki sposób się nauczyć, jakie dane zastosować, czy to jest potrzebne, czy coś obciąć, czy coś zostawić. W końcu taki oficjalny Virgin 1.0. był stworzony.

Wtedy był już taki etap, że różne zespoły z całego świata, miały jakieś już działające Virgin 1.0. projekty. Parę miesięcy później, zaczęliśmy drugą inicjatywę i zaczęliśmy współpracować z różnymi zespołami z całego świata. Niektóre pomysły trochę się powtarzały i niepotrzebnie, żeby dwa różne zespoły robiły to samo tylko, żeby razem połączyć siły i nad tym popracować, bo może faktycznie możemy coś rozwiązać.

Mamy też swój zespół w Krakowie, z którym pracujemy nad jedną rzeczą, też mamy różne zespoły w innych lokalizacjach, ale tak naprawdę teraz już pracujemy razem. Jesteśmy na takim etapie, że jesteśmy jednym wielkim, zdalnym zespołem w Nokii, ale staramy się działać i używać uczenia maszynowego. 

Spróbujmy troszkę podsumować te przejścia pomiędzy krokami, które wcześniej wyjaśniłem. To są miesiące, lata? Wiadomo, że to wszystko zależy, ale tak bardziej spróbujmy chociażby ten temat ugryźć, na tym konkretnym przykładzie.

Zaczynając 3-4 lata temu to nic nie było wiadomo. Rok, półtora roku później, zaczęły się wstępne dyskusje odnośnie uczenia maszynowego, co to jest, jak można to wykorzystać. Pół roku później, zaczęły pojawiać się pierwsze małe jednoosobowe zespoły i zaczęły być prototypowane różne projekty. Rok, półtora roku później zaczęły tworzyć się takie konkretniejsze zespoły. 

Są pewne przejścia, z punktu „a” do punktu „b”, z punktu „b” do punktu „c”. Czy to było naturalne, że skoro udało się przejść z punktu „a” do punktu „b”, to od razu rozpoczynamy podróż do punktu „c”? Czy jednak musiało coś się wydarzyć?

Czasem to było łatwe, naturalne, a czasem niekoniecznie, np. jedna sprawa to zacząć o tym rozmawiać, a druga sprawa to znaleźć zespół, a to jest koszt. Jakiego rodzaju decyzje muszą zajść i u kogo, żeby to było możliwe?

Jak zacząłem prototypować ten projekt i w końcu, jak mi się udało skończyć i utworzyć wersję 1.0., to potem zaczął się etap poszukiwania, jak mógłbym rozszerzyć tę funkcjonalność, gdzie bym mógł dalej to zastosować.

Tak naprawdę to było lokalnie zastosowane, głównie tylko w moim zespole. Zaczął się taki okres researchu, żeby zobaczyć jak inne zespoły funkcjonują, co robią, czy potrzebują taką funkcjonalność, czy czegoś innego potrzebują, czy coś dodatkowo można dodać do mojego projektu?

Zajęło trochę czasu takie szukanie, research i wywiady z różnych zespołów, żeby dowiedzieć się, co jest potrzebne, gdzie mógłbym zastosować taki projekt, który właśnie stworzyłem. Całe szczęście, jednocześnie jak ja robiłem ten projekt, mniej więcej w tym samym czasie, drugi zespół zaczął się tworzyć.

Oni szukali takich osób jak ja, z taką funkcjonalnością i doświadczeniem, aby pomóc im rozszerzyć swój projekt. Wtedy miałem okazję, żeby dołączyć do nich i nad tym popracować dalej. 

Fajnie, że to powiedziałeś, bo jak prowadzę kursy online, dotyczące tego, jak zacząć z uczeniem maszynowym i później znaleźć pracę, to zwykle podpowiadam absolwentom, że ważnym jest to, aby mieć proaktywną postawę.

Nie czekaj, dopóki jakaś osoba decyzyjna w Twojej firmie powie Ci, co masz robić, tylko to musi być taka inicjatywa oddolna. To jest inspirujące, więc dzięki, że się tym podzieliłeś.

Teraz porozmawiajmy trochę na temat tego projektu. Tylko zanim porozmawiamy o rozwiązaniu, to najpierw o problemie. Wyjaśnij, jaki jest kontekst i jakie są problemy? Jak udało się to ogarnąć, albo przynajmniej częściowo ogarnąć?

Jeżeli chodzi o mój pierwszy projekt, to problem był taki, że jak robimy testy regresyjne, to jest bardzo dużo różnych parametrów, które są generowane przez stację bazową. Jak tester pracuje nad daną nową funkcjonalnością, to on jest ograniczony, żeby sprawdzić najważniejsze parametry, który dotyczą danej funkcjonalności plus parę jakiś innych ewentualnie.

Problem jest taki, że tych parametrów jest ponad 2 tysiące. Nie masz szans, żeby przeglądnąć każdy parametr i sprawdzić, czy to faktycznie poprawnie działa, czy nie. Jesteśmy ograniczeni czasowo, bo musimy upewnić się, że dana funkcjonalność będzie działała i to potem dostarczyć do klienta.

Zamiast sprawdzać te wszystkie parametry manualnie przez testera, to wszystko może być zautomatyzowane za pomocą uczenia maszynowego. Właśnie tu powstał pomysł, że stworzymy model, którego nauczymy wszystkich parametrów. Bardzo prosto jest to pogrupowane, że albo test był spasowany, albo nie.

Testy nie były wielce skomplikowane i można było wyróżnić takie różnice –  jeśli te 2 tys. parametrów mają różne wartości to oznacza, że test jest raczej spasowany, a jeśli nie ma tych różnic, to ten test nie jest spasowany. Po jakimś dłuższym czasie, różnym eksperymentowaniu, udało nam się właśnie taki projekt stworzyć. To jest oczywiście pierwszy projekt.

Zróbmy jeszcze krok wstecz, bo tak szybko powiedziałeś, że jest jakaś stacja. Możliwe, że nie dla wszystkich jest oczywiste, o co chodzi, więc wyjaśnij na przykładzie co to jest i po co to jest? Komu to jest potrzebne, żeby to działało? Co się stanie, jeśli to przestanie działać?

Stacja bazowa to jest takie urządzenie, które pozwala, żeby nasza komórka połączyła się do tej stacji. Możemy wtedy wejść na Internet, zadzwonić do znajomych i wtedy komórka działa po prostu z siecią. Ta stacja bazowa ma przeróżne funkcjonalności.

Musi obsługiwać telefony, które przychodzą, żeby móc przełączyć, podłączyć telefon, wysłać dane informacje, które trzeba zastosować, odpowiednie konfiguracje. Jeśli człowiek przemieszcza się to gdzie ten telefon ma dalej się przełączyć, do kolejnej bazy. Więc te stacje bazowe są bardzo potrzebne, żeby takie utrzymać takie połączenie. 

Fajnie, czyli to jest po prostu kluczowy element, żeby sieć komórkowa funkcjonowała poprawnie. Powiedziałeś też, że jest ogromna liczba parametrów przetwarzanych jednocześnie, czyli to oznacza, że wiele rzeczy może się zepsuć.

Skoro tyle rzeczy trzeba weryfikować, to pewnie każdy z nich może się zepsuć albo wszystko na raz. Takie klasyczne podejście, weryfikacja krok po kroku, bardziej w sposób liniowy, że sprawdzamy wszystko po kolei, to niby działa, tylko dość ograniczającym czynnikiem był czas. Idea polegała na tym, żeby szybko wykrywać pewne rzeczy, które mogą pójść źle albo nawet pewne sygnały.

Jeszcze nawet z takim wyprzedzeniem, że jeszcze być może nie jest źle, ale już są pewne sygnały, które sugerowałyby, że tak może się stać. Podpowiedzią, którą mieliście, to, nad czym bazowaliście, to były dane, które były wynikiem uruchamiania klasycznych testów. Te testy klasyczne miały odpowiedź – „działa/nie działa”. Parametry były przekazane dla modelu + odpowiedź „działa/nie działa”.

Jakie były trudności dalej? Wszystko to jest przepiękne, ale ten świat zwykle jest zbyt zmienny, żeby było tak łatwo. Jakie mieliście wyzwania?

Na samym początku mieliśmy krytyczny problem. Jak wpierw zaczynaliśmy, bardzo krótko i bardzo szybko na samym początku, jakimś cudem nasz model bardzo dobrze działał. Byliśmy bardzo zdziwieni, dlaczego tak super to działa.

Trochę niestety za szybko się pochwaliliśmy, że ma bardzo dobre wyniki, a okazało się, że wcale tak nie jest. Mieliśmy tzw. data leakage (wyciek danych). To jest taki problem, że jak uczymy model i dzielimy dane na testowe i treningowe to niektóre z nich, które są w training, pojawią się w testowym i na odwrót. Model już zna wyniki, zanim widział testowe próbki.

To był typowy problem dla początkujących, powiedziałbym, że każdy musi go przejść. Oczywiście musieliśmy wrócić do tego i potem w końcu odkryliśmy, że źle segregowaliśmy te dane. Potem jak już to poprawiliśmy, to faktycznie dużo mniejsza była ta dokładność. Następnie zaczęliśmy kombinować, z innymi modelami robić tuning itd., aż w końcu udało nam się uzyskać wystarczająco dobre wyniki.

Kiedyś w banku powiedziałem coś na temat wycieków danych i nagle uwaga całego zespołu wzrosła, choć to chodziło o inny wyciek danych. Jednak ta fraza jest dość zaskakująca, w szczególności dla osób, które pracują w banku i w podobnych instytucjach, więc trzeba tutaj uważać albo przynajmniej od razu tłumaczyć, co to oznacza w praktyce. 

Jakie trudności jeszcze mieliście po drodze? Które rzeczy na początek wydawały się mało istotne, ale praktyka pokazała, że jednak na to trzeba zwracać uwagę? 

Dużo danych – to było właśnie krytyczne. Mieliśmy historyczne dane, ale mieliśmy też przeróżne testy. Niektóre z nich były częściej puszczane i miały dokładniejsze wyniki, niektóre rzadziej, przez co ciężej było przewidzieć rezultat. Przy processingu danych my też kombinowaliśmy na różne sposoby, czy powinniśmy normalizować czy nie? To jest oczywiście zależne w różnych przypadkach.

Jeżeli my zostaliśmy przy XGBoost czy takiej formie jak Java Decision, to takie modele najlepiej działają takie jakie są, bez modyfikacji. Modele Java Decision i Random Forest to najlepiej działają na takich danych. Oczywiście był też tuning, żeby zrozumieć jak parametry tuningowe wpływają, co ulepszają, a co nie. Dużo czasu to zajmowało, zanim otrzymaliśmy wyniki.

Często się mówi, że czyste dane są podstawą i z tym zwykle nikt nie dyskutuje, bo każdy kto pracował z danymi wie, że to jest prawda. Natomiast jest to trochę abstrakcyjne, bo tak naprawdę jak zaczynasz pracować z tymi danymi, to tak się zastanawiasz: „Ok, miałem punkt „a” wyjścia i tam były dane, które miały totalnie zły format.
Zrobiłem coś, wyczyściłem lub poukładałem, mam jakiś inny stan, tylko pytanie czy teraz te dane już są czyste czy tylko trochę czystsze? Czy wystarczająco czyste?”.

To jest trochę taki dylemat, który gdzieś tam zawsze się pojawia i fajnie, żeby pojawiały się jakieś konkrety. 

Kwestia spójności. W Waszym przypadku to były testy, które się uruchamiały częściej, drugie rzadziej. Teraz kiedy przekazujemy te dane do modelu, to model zakłada, że to jest spójne. Jeżeli nie jest to jest trochę nasz problem, bo model potrafi zobaczyć rzeczywistość przedstawioną w przekazanych mu przez nas danych, które on zakłada za normalne.

On nie zna kontekstu, że ktoś tam po prostu ustawił zły parametr albo ten test wykonuje się wolniej, dlatego jest rzadziej. Model tego nie wie, ma po prostu to co ma, więc ta spójność jest elementem dość ważnym i konkretnym.

Czy jeszcze coś Ci przychodzi do głowy, kiedy mówimy o czystości danych? Jakieś kryteria, na które warto zwracać uwagę?

Jedna rzecz jeszcze mi się przypomniała, może niekoniecznie o czystości danych. Pojawiały się nieraz pytania, czy podzielić ten model na kilka różnych.

W sumie te testy można podzielić na różne kategorie. Było też pytanie, czy zrobić taki zestaw hierarchiczny, że odpowiedni model do odpowiednich testów, ale to też powiązane było z tym, że ze względu na różną częstotliwość testów, to jeden model mógł mieć tylko parę testów, a inny model mógł mieć ich ponad 100 do nauczenia. Więc tu częściowo nie miało sensu, żeby to rozdzielać i lepiej trzymać to wszystko razem. 

Jeżeli chodzi o dane to potem było pytanie, czy może zrobić dane syntetyczne? Stworzyć takie podobne dane i zduplikować je w jakiś sposób. Nad tym też trochę zastanawialiśmy się, ale jest po prostu za dużo tych parametrów, żeby zrozumieć wszystkie dokładnie.

Niestety niektóre parametry są zależne od innych, czyli jak jedna wartość pójdzie w górę to inna musi iść w dół, druga zostaje taka sama i są przeróżne kombinacje, których niestety nie możemy przewidzieć. Jak chodzi o stworzenie syntetycznych danych, to niestety to też było to wykluczone. 

A propos tej zależności to jeszcze jedna sprawa, kiedy zależność jest liniowa, czyli jeden się zwiększa o 2, drugi o 4. Prawdopodobnie w tym przypadku to była zależność nieliniowa, czyli tak naprawdę czasem jeden parametr się zwiększa, drugi stoi w miejscu, potem jest moment X i on rośnie jak szalony. Więc takie zależności liniowe są najtrudniejsze. 

Ciekawą rzecz jeszcze wspomniałeś, a propos dzielenia modeli. Zwykle na początku (też przechodziłem tę ścieżkę), kiedy mamy hierarchię decyzji, że np. mamy jakąś kategorię główną, potem podkategorię to zwykle chce się zrobić w taki sposób, że trenuje się model, który mówi, że to jest kategoria „rodzic a” albo „rodzic b” i później skoro to jest „rodzic a”, to bierzesz inny model, który mówi, że to jest „dziecko a1” albo „dziecko a2”.

W ten sposób propagujesz właśnie tę decyzję, w całym łańcuchu. Praktyka pokazuje zwykle, że to niekoniecznie jest najlepszy pomysł, ponieważ każdy model posiada błąd i te błędy zaczynają się powtarzać. Czyli innymi słowy, jeżeli „model a” nie wykrył tego, co należy do „a”, to później „a1” czy „a2” w ogóle nie ma szans, żeby to wykryć, bo tam nawet nie docierają.

Jeszcze jak zaczynamy łączyć modele, to te błędy zaczynają się pojawiać w dość paradoksalnie nieoczekiwany sposób. Widziałem na własne oczy pewne rozwiązania na produkcji, kiedy tak było zrobione. Na szczęście kiedy zbierałem własne doświadczenie, to do produkcji nie doszedłem. Szybko wyłapałem, że to nie jest fajne podejście powtarzać błędy dalej. Powiela się to znacząco, bo tak naprawdę jeżeli 20% danych nie przeszło, to potem ta liczba jest brana pod uwagę i tak się zbiera kula śnieżna. 

Powiedz coś więcej na temat drugiego projektu. Jakie jest problem i kontekst tego problemu, a później rozwiązanie?

Tu jest większy projekt, który wpływa na całą Nokię. Ten projekt polega na usprawnieniu całego procesu, wykrywaniu różnych problemów i potem zgłoszenie tych problemów do odpowiednich zespołów, żeby je naprawić. Problem polega na tym, że tester testuje jakąś funkcjonalność i potem wykryje, że test nie przeszedł, bo coś źle poszło. Tester musi teraz znaleźć, co było problemem.

W zależności od tego, jaki problem to jest, to może trwać albo 5 minut, albo nawet 5 godzin. To jest niestety bardzo czasochłonne. Jak już wykryjemy problem, to musimy go przypisać do odpowiedniego zespołu czy osoby, która następnie to musi naprawić. Tu znowu pojawia się kolejny problem, że mamy przeróżne osoby, które specjalizują się w innych tematach i ciężko trafić do odpowiedniego zespołu.

Przeważnie to wygląda na takiej zasadzie, że przypisuje się problem w kryteriach jakiejś jednej grupy, ale dostajemy zwrot, że oni tym się nie zajmują. Potem do drugiej, ale dostajesz znowu zwrot. To jest taki ping pong tam i z powrotem, aż w końcu za 3 czy za 4 razem, w końcu trafia do odpowiedniego zespołu.

To też znowu jest bardzo czasochłonne i niestety kosztowne, bo bardzo dużo zajmuje, żeby rozwiązać jakiś problem i to może spowodować opóźnienia w dostarczeniu różnych rzeczy, a tego przecież nie chcemy. 

Poprzez ten projekt chcemy usprawnić ten proces. Można tak naprawdę podzielić go na dwie części. Pierwsza część to używanie sztucznej inteligencji i uczenia maszynowego, żeby szybciej wykryć te różne problemy.

Druga część to użycie sztucznej inteligencji i uczenia maszynowego, żeby robić odpowiednie predykcje na podstawie tego, jaki problem był znaleziony, żeby dobrze przypisać od razu za pierwszym razem do odpowiedniego zespołu. 

Czyli rozwiązaniem w tym przypadku po pierwsze jest szybkość, redukcja czasu. Po drugie, też w sumie na temat czasu i zaangażowania osób, bo znalezienie właściwej osoby, która może ten problem rozwiązać, z tego co rozumiem, przy takiej skali jak duża firma, nie jest trywialnym problemem. 

Czy możesz troszkę więcej powiedzieć na temat tych danych? Jakiego rodzaju dane są na wejściu? Co jest na wyjściu? Jakie są też trudności, jeżeli chodzi o te dane?

Mogę zacząć od drugiej części, bo to mamy bardziej rozwinięte i wdrożone w tej chwili. Stworzyliśmy taki model, który otrzymuje opis problemu od danego testera. Na podstawie tego, jak ten problem został opisany, to go potem przypisujemy odpowiednio do zespołu.

Podobnie jak przy pierwszym projekcie nauczyliśmy się na historycznych danych. Mamy odpowiednią bazę, historię różnych problemów, które były zgłoszone wcześniej, gdzie były przypisane i jaki był opis tych problemów itd. Na wejściu mamy tekst, opis danego problemu po angielsku (na szczęście).

Potem musimy wziąć te dane, skonwertować w odpowiedni sposób, czyli zamienić na wektory, w taki sposób, który model będzie mógł odczytać. Potem uczymy model, że taki opis właśnie należy do takiej grupy, taki do takiej grupy itd. Mniej więcej, w skrócie można powiedzieć, że tak funkcjonuje ta druga część.

Czyli tzw. problem NLP, czyli przetwarzanie języka naturalnego. Powiedziałeś “na szczęście w naszym przypadku po angielsku” i faktycznie to ułatwia sprawę z wielu powodów, m.in. język angielski pod tym względem jest trochę przyjemniejszy, bo ma pewną strukturę i mniej odmian językowych. Jest bardziej przewidywalny i przyjemniejszy, jeśli chodzi o wersję cyfrową, niż np. język polski. 

Jeżeli chodzi o wyniki, czy udało się zwiększyć efektywność pracy zespołu testerów i być może jeszcze kogoś?

Tak, na chwilę obecną do jakiegoś stopnia udało się nam usprawnić. Mamy właśnie ten model wdrożony i całkiem dobrze na chwilę obecną działa. W stosunku do tego, jak działał wcześniej, to przypisanie do odpowiedniej grupy, to 3-4 razy trzeba było próbować, zanim się w końcu trafiło do odpowiedniego zespołu.

Teraz model nie jest idealny i nie zawsze taki będzie, więc czasami mogą pojawiać się różne problemy, ale całkiem dużo lepiej działa. Zdecydowanie mniej razy (raz albo 2 razy) trzeba próbować, żeby przypisać do danego zespołu, ale przeważnie za pierwszym razem trafia. Więc jak chodzi o tę część, to dużo bardziej jest proces usprawniony w stosunku do tego, jak było wcześniej. 

Jeżeli chodzi o pierwszą część, czyli wykrywanie różnych problemów, to to jest dużo większy problem i to jest coś, co nie będzie rozwiązane tak szybko. Minie jeszcze trochę czasu, żeby poeksperymentować, zrozumieć, o co chodzi, jakie problemy są, jak można je wykryć. Czy dane wyniki tego modelu są przydatne? Co tester konkretnie potrzebuje, żeby odpowiedzieć, dlaczego coś się stało lub nie? Niestety to jeszcze potrwa jakiś czas. 

Zwykle powtarzam taką frazę, że jak masz umiejętność X, do tego X dodajesz ML, AI i już dostajesz innowacje. W Twoim przypadku, tym X jest testowanie.

Jak myślisz, na ile branża uczenia masznowego zmieniła lub zmienia branżę testowania? Na ile to już zaczyna wyglądać inaczej? Czy masz jakieś prognozy, jak to może wyglądać za np. 5 lat? Na ile te podejścia, które były jeszcze „wczoraj, jutro już będą nieaktualne”?

Jest to jeszcze trochę świeży i skomplikowany temat. Jak wspomniałem przed chwilą, takie rozwiązania jeszcze trochę zajmą, żeby tak naprawdę bardzo dobrze funkcjonowały. Ale jak chodzi o szacowanie, to można powiedzieć, że to ma duży potencjał w takiej branży. Szczególnie, że procesy inwestygacji danego problemu trwają 5 godzin, a może i więcej.

W zależności od tego, jak bardzo krytyczny jest dany problem, to za pomocą sztucznej inteligencji lub w ogóle usprawnienia tego całego procesu, wykrywanie tych różnych problemów możemy nawet skrócić do 15-20 minut. Oczywiście, jak oszczędzamy dużo czasu, to oszczędzamy też dużo pieniędzy. W stosunku do tego, ile teraz jest wydawane, żeby znaleźć i poprawiać, wykrywać te różne problemy, to za pomocą sztucznej inteligencji, można powiedzieć, że przynajmniej o połowę te koszta można zmniejszyć.

Może i nawet więcej, jeśli to dobrze się zrobi. Odnośnie przyszłości, następne 5-10 lat to widzę, że sztuczna inteligencja nigdy nie zastąpi testera. To na spokojnie mogę powiedzieć, bo zawsze będą te nowe funkcjonalności, które trzeba będzie stworzyć i to są takie rzeczy, których model nigdy nie przewidzi. Jednak za pomocą modeli z uczenia maszynowego, to my możemy zawsze testować to, co już działa.

To tak naprawdę wszystko rozkłada się na najbardziej fundamentalne rzeczy i funkcjonalności, czyli np. czy stacja bazowa wstała, czy telefon został podłączony, czy to połączyło się z drugą bazą, czy dane zostały wysłane itd. Jest bardzo dużo rzeczy, które model może przewidzieć i wiele z nich można usprawnić.

Po prostu usprawnić cały proces, żeby tester nie zajmował tym, wiedząc, że to na pewno działa poprawnie, ale żeby sfokusować nad danym problemem, który nie działa i poprawić to jak najszybciej. W przyszłości widzę, że uczenie maszynowe będzie bardzo dobrym narzędziem dla testera, ponieważ jego praca będzie przyjemniejsza, bo nie będzie trzeba siedzieć godzinami i szukać problemu.

Doskonale znam to uczucie i byłem nieraz w takich sytuacjach, ale naprawdę dużo można ulepszyć taką pracę i właśnie tak widzę najbliższą przyszłość i dalsze lata.

Czy swoje życie zawodowe widzisz już teraz bez machine learning?

Powiem szczerze, że nie za bardzo. Bardzo mi się to spodobało. W ogóle od liceum byłem bardzo zafascynowany technologią, elektroniką, najnowszymi rzeczami. Wtedy ogromnie się interesowałem komórkami, jakie są najnowsze parametry, funkcjonalności.

Elektronika i technologia strasznie mnie interesowały i to pomału się rozwinęło. Na studiach uczyłem się telekomunikacji i elektroniki, potem to się rozwinęło w programowanie. Potem sztuczna inteligencja, więc to jest naprawdę cudowna i fantastyczna rzecz. To jest po prostu przyszłość. Nie widzę życia bez tego.

Dzięki Daniel za dzisiejszą rozmowę. Bardzo mi miło. Cieszy też Twój entuzjazm i znalezienie się w odpowiednim miejscu, bo czuć, że rzeczy, które teraz robisz to są Twoje rzeczy i życzę Ci, żeby udało Ci się jeszcze bardziej rozwinąć skrzydła, osiągnąć jeszcze więcej i czuć radość z życia. Więc dzięki za rozmowę, do zobaczenia.

Dzięki, cześć. 

Po rozmowie okazało się, że jakiś czas temu (chyba ponad 2 lata temu), poznaliśmy się z Danielem na Hackathonie, gdzie byłem w jury i oceniałem różne projekty.

Jego projekt zdobył drugie miejsce. Akurat wtedy jeszcze Daniela nie znałem i dzisiaj musiałem też tę historię sobie przypomnieć. Świat jest bardzo mały, ale ciekawe jest to podejście, kiedy ktoś Cię bardzo dobrze pamięta, a Ty pamiętasz to wydarzenie, ale niekoniecznie pamiętasz wszystkie osoby. Ale jak już kontekst się przypomniało, to wiedziałem dokładnie, jak to wszystko wyglądało, mam bardzo dobrą pamięć wizualną. 

Druga rzecz, która też mi przyszła do głowy to cała ta rozmowa była dość przyjemna. Wytworzyła się dość pozytywna atmosfera i to cieszy, kiedy ludzie znajdują swoje miejsce w życiu, bo tak naprawdę, jeżeli obserwujesz dookoła nasz świat, to zobaczysz, jak często osoby się męczą z tego powodu, że znajdują się w niewłaściwym miejscu.

Dlatego bardzo gorąco Ci życzę, jeżeli masz poczucie, że Twoje miejsce pracy to jest jakiś koszmar i to jest coś, co Cię bardzo męczy, to zastanów się nad tym, czy to miejsce jest “Twoje”. A druga rzecz to przygotuj plan ucieczki.

Wiadomo, że nie musisz rzucać papierami natychmiast, bo to różnie może się skończyć i zwykle trzeba robić to zdroworozsądkowo, ale warto zadbać o swoje życie, bo ono jest stosunkowo krótkie i nawet jeżeli trwa 100 lat, to bardzo szybko mija. Życzę Ci znaleźć swoje właściwe miejsce, bo dzięki temu będziesz czuć radość i szczęście. Poczucie radości jest bardzo ważne.

Jeśli zainteresował Cię ten artykuł – podaj go dalej. Rozwijajmy wspólnie społeczność związaną z uczeniem maszynowym i sztuczną inteligencją. Jeśli chcesz aktywnie działać w temacie uczenia maszynowego, to polecam Ci dołączyć do społeczności pasjonatów i praktyków Machine Learning / Data Science – DataWorkshop.

Warto się zapisać się również do newslettera, gdzie będziesz dostawać najnowsze informacje na temat tego, co się dzieje.