Magda Cebula podcast ‑ final 9

In this podcast episode, the topic is Big Data on the border with Artificial Intelligence. The guest speaker, Magda Lena-Cybula, an expert in data science, explains the key differences between big data and regular data. Big data refers to a large amount of data that needs to be processed in real-time, while regular data can be analyzed using tools like Excel. Big data also involves diverse data sources and the need for quick processing and reliable data. Magda discusses the available technologies for collecting and processing data, such as Excel, visualization tools like Power BI and Tableau, relational databases, NoSQL databases for storing non-tabular data, graph databases like Neo4j, log processing systems like Elasticsearch, Redis for fast responses, and big data technologies like Hadoop, Spark, and Kafka. The main challenges in integrating data from multiple sources include understanding the business requirements, dealing with different data formats and systems, and ensuring data Witam Cię w pierwszym odcinku serii podcastów Big Data, Big Challenges and Real Success. W tej serii biznes pyta, eksperci odpowiadają na aktualne pytania z dziedziny zarządzania danymi, dzieląc się swoim doświadczeniem oraz poglądami. Seria podcastów została przygotowana przez butikową firmę Sofixit, która oferuje swoje usługi i produkty w obszarze szeroko rozumianych danych. Na co dzień wspieramy naszych klientów w poszukiwaniu i wdrażaniu najlepszych dla nich rozwiązań w tej dziedzinie. Temat dzisiejszego odcinka brzmi Big Data na pograniczu ze sztuczną inteligencją. Jakich danych potrzebuje i jak od jakości danych, którymi ją nakarmisz, zależy na ile będzie dobra. A naszym gościem specjalnym jest Magda Lena-Cybula. Magda jest wybitną ekspertką w dziedzinie nauki o danych. Data Scientist Comprehensive Technologies, gdzie specjalizuje się w tworzeniu modeli rekomendacyjnych. Magda również pełni rolę asystentko-naukowo-detektycznej na Politechnice Warszawskiej, gdzie aktywnie uczestniczy w kształceniu przyszłych specjalistów w tej dziedzinie. Jest organizatorką konferencji Machine Learning w Polsce oraz regularnych meetupów w Polish Machine Learning Community, które stanowią platformy do wymiany wiedzy i doświadczeń dla entuzjastów i profesjonalistów z zakresu uczenia maszynowego. Jej zaangażowanie w kład w rozwój sztucznej inteligencji zostało docenione poprzez nominację do top 100 kobiet w dziedzinie sztucznej inteligencji oraz top 100 kobiet w dziedzinie nauki o danych w Polsce. Cześć Magda! Cieszę się bardzo, że przyjęłaś nasze zaproszenie do wzięcia udziału w podcaście i podzielisz się z naszymi słuchaczami swoim doświadczeniem i poglądami. Dzień dobry, witam serdecznie naszych słuchaczy i jest mi bardzo, bardzo miło, że zostałam zaproszona do tego podcastu, więc mam nadzieję, że dowiecie się ciekawych i inspirujących rzeczy. To zaczynajmy. Przede wszystkim chciałabym zapytać Ciebie o to, jakie są kluczowe różnice między big data a tzw. zwykłymi danymi w kontekście ich przetwarzania i analizy przez sztuczną inteligencję. Przede wszystkim to będzie ilość, bo jak sama nazwa wskazuje, big data, czyli jakieś wielkie dane. Więc będziemy, w przypadku big data, będziemy mówić o sytuacji, kiedy mamy bardzo dużo danych do przetworzenia i często w czasie rzeczywistym, bo kiedy pracujemy na stanowiskach związanych z danymi, czy trochę bardziej biznesowo, czy trochę bardziej technicznie, to możemy mieć sytuację, gdzie jesteśmy w małym projekcie, gdzie pracujemy na Excelu. Pół żartem, pół serio, korpo stoi na Excelu i dalej jest to jedno z potężniejszych narzędzi do analizy danych, szczególnie na pierwszym etapie. Kolejna rzecz to, kiedy mamy te nasze Excele, możemy je zwizualizować w różnych dashboardach i wtedy właśnie korzystamy np. z jednego źródła danych, korzystamy z tego Excela i wyciągamy wnioski na podstawie jakichś wykresów. To szczególnie będą lubić nasi menadżerowie, dyrektorzy, czy osoby zarządzające, żeby z tych wszystkich naszych pięknych tabelek wyciągać najważniejsze informacje na wykresie i w prosty sposób pokazać, jakie my wnioski wyciągamy z tych danych. Idąc dalej, po rozmiarze możemy mieć hurtownie danych, ale też to, co jest tutaj charakterystyczne, do czego się wykorzystuje te hurtownie danych, czyli sytuacja, kiedy z jednej strony znowu zbieramy dane z różnych źródeł, ale chcemy wykorzystywać je do przeprowadzania regularnych analiz, czyli np. raz dziennie tworzymy tzw. datamart, który zawiera nam agregacje całego dnia. Może to być też raz na godzinę albo raz w miesiącu, w zależności od naszych płoczek. I to, o czym wspomniałam na początku, czyli big data, kiedy chcemy przetwarzać bardzo duże ilości danych, często w czasie rzeczywistym, więc zależy nam na tym, żeby natychmiast odpowiadać na requesty, na żądania, które przychodzą z naszych aplikacji, żeby móc w czasie rzeczywistym np. dawać predykcje naszych modeli, dawać odpowiedź dla naszych klientów. Kolejną taką rzeczą, kolejnym aspektem, przez który możemy popatrzeć na różnicę między zwykłymi danymi, a big data jest ich różnorodność, czyli w przypadku big data będziemy mieli bardzo różnorodne dane z różnych systemów mające różne znaczenie biznesowe, a w przypadku zwykłych danych będziemy się skupiać często na jednym źródle danych albo na niewielkiej ilości, które odpowiadają na nasz problem. Kolejnym takim aspektem jest szybkość przetwarzania, o czym w sumie już wspomniałam, że mamy naszego Excela, mamy dane np. z tabelach relacyjnych i mamy dane, które wykorzystują narzędzia big data, czy dokładnie wykorzystujemy narzędzia big data do przetwarzania danych i teraz pracując na Excelu, pracując jako data scientist na przykład na tabelach, na data frame'ach nie potrzebujemy mieć odpowiedzi w czasie rzeczywistym, ale kiedy nasz biznes wykorzystuje nasze modele czy nasze analizy, no to oni być może będą oczekiwać tej szybkości i kolejny aspekt, który warto wziąć pod uwagę to jest wiarygodność naszych danych. Sytuacja, kiedy pracujemy przy małym projekcie na małej ilości danych, kiedy rozumiemy wszystkie nasze dane, wiemy jakie one mają charakter, wiemy co z czego wynika. I z drugiej strony big data, czyli sytuacja, kiedy potrzebujemy szybkiej odpowiedzi, a np. będzie sytuacja, że dane nie dotrą, będzie sytuacja, że będą jakieś błędy w danych, będzie sytuacja, gdzie mamy pięć źródeł danych i niby jest ta sama wartość, ale ona może znaczyć coś innego, więc w przypadku projektowania systemu big data musimy wziąć to pod uwagę. Kolejny raz udowodniłeś, że podejście do analizy danych musi być spersonalizowane i dopasowane do każdego projektu. W takim razie naturalnie nam powstaje pytanie, jakie są dostępne technologie na dzień dzisiejszy i jakie z nich są najczęściej używane do zbierania i przetwarzania danych w projektach związanych ze sztuczną inteligencją? To tutaj ponownie zacznę sobie od Excela, które mimo wszystko przydaje się firmach, dlatego to tak zaznaczam. Druga rzecz jest taka, że możemy te nasze dane wizualizować, czyli możemy stworzyć wykresy, możemy stworzyć dashboardy, czy na przykład w Power BI, w Tableau, czy używając języków programowania, jak Shiny od Era, czy Dash albo Streamlit od Pythona. Kolejna rzecz jest taka, że możemy mieć relacyjne bazy danych, czyli modelujemy w ten sposób sytuację, gdzie nasze obiekty są powiązane w jakiś sposób ze sobą relacjami, czyli klasyczny przykład zakupy. Mamy jakiś paragon czy fakturę, na paragonie są poszczególne produkty. Te produkty na przykład są gdzieś umieszczone w magazynie i wszystkie te rzeczy mają do siebie jakieś powiązanie relacyjne. Idąc dalej, mamy technologie NoSQLowe, czyli takie dane, które właśnie nie dają się przedstawić w ten sposób tabelaryczny. Możemy przechowywać pliki, możemy przechowywać jakieś teksty, możemy przechowywać obrazy. Tutaj chciałabym zwrócić też Waszą uwagę na bazy, które są przygotowane do rozwiązania konkretnego problemu. Czyli na przykład, kiedy mamy naszych klientów i chcemy je zgrupować w jakiś sposób, możemy do tego zastosować podejście grafowe. I może się okazać, że z jednej strony możemy później na etapie modelu tworzyć grafy, albo możemy na etapie bazy danych wykorzystać bazę grafową, taką jak jest na przykład Neo4j. Więc to też właśnie pytanie, na którym etapie, jaką technologię zastosować. Bardzo seksy temat ostatnio, czyli LLM-y, chatboty i co o tym idzie wykorzystanie baz wektorowych. Kolejna technologia bazoganowa, która jest używana w konkretnym przypadku. Idąc dalej, systemy, które zbierają i przetwarzają logi, czyli na przykład Elasticsearch, kiedy mamy oprogramowanie, które obsługuje naszych klientów i zbieramy informacje o tym, co się dzieje w tym oprogramowaniu, jakie rekwersy idą, czy wszystko było w porządku, czy coś się może zadziało, czy jakieś są errory, braki danych i tak dalej, bo te wszystkie informacje pozwalają nam potem na diagnozę systemu. Wystąpił jakiś problem, patrzymy do logów i wnioskujemy, co się dzieje. No i kolejna taka, myślę, że ciekawa technologia, czyli Redis, czyli baza danych, która działa bardzo szybko, czyli jeżeli potrzebujemy, jest to baza danych typu klucz-wartość, więc jeżeli potrzebujemy bardzo szybkiej odpowiedzi, może się okazać, że na tym końcowym etapie będziemy chcieli wykorzystać Redisa. No i ostatnia grupa technologii, czyli technologie big data, czyli Hadoop do przetwarzania równoległego, bardzo dużych ilości danych, czyli Spark i na przykład Kafka, gdzie w Kafka mamy streaming, czyli chcemy nasze dane przetwarzać w czasie rzeczywistym w sposób ciągły. Każdy pewnie się spotkał w projektach z różnorodnością w obszarze technologicznym i musiał na bieżąco decydować, jakie z rozwiązań będzie najlepszym wyborem dla konkretnego projektu. Wiemy też, że źródła danych w każdym z projektów nie ograniczają się do jednego i raczej jest ich więcej niż kilka. W związku z tym musimy to wszystko zintegrować, więc pytanie do Ciebie, Magda, jakie są główne wyzwania związane z integracją danych z różnych źródeł i jak je rozwiązywać? No to po pierwsze to jest rozumienie biznesu i tego, co my chcemy tworzyć, co ma być naszym finalnym produktem końcowym. Druga rzecz, która za tym idzie, jest pytanie, co my teraz mamy i tutaj mam takie wrażenie, jest bardzo duży problem czy bardzo duże wyzwanie właśnie z integracją z różnych źródeł danych, szczególnie w przypadku, kiedy mamy dane, które opisują podobną sytuację, ale czymś się różnią. Taka sytuacja może wystąpić na przykład w przypadku bardzo dużych firm, które mają kilkadziesiąt lat działania, gdzie te systemy z jednej strony mogą być bardzo stare, czyli mamy właśnie te rozwiązania legasy, które dalej są utrzymywane, które dalej zbierają dane i dalej możemy z nich korzystać, a mamy na przykład sytuacje, gdzie doszły nowe systemy, z których też możemy czerpać dane. Więc w tym przypadku najważniejsze z mojego punktu widzenia jest zrozumienie biznesu, zrozumienie dlaczego, jakie dane są gdzie zbierane i co my z tym możemy zrobić. I tutaj niestety, ale bardzo duża część będzie po prostu polegała na spotkaniach między ludźmi biznesowymi i między ludźmi technicznymi. W idealnym świecie mamy osobę, która łączy ze sobą wiedzę biznesową i umiejętności techniczne i wtedy po prostu analizujemy, co mamy, planujemy, co chcemy mieć i co możemy z tym zrobić, bo może się okazać, że tutaj będziemy musieli wykonać jakieś kształcenia danych, żeby uspójnić, a może się okazać, że zdecydujemy, że na przykład z tego jednego źródła w tym przypadku chcemy brać te informacje. Kolejna bardzo ważna rzecz to są różne formaty danych i znowu znaczenie biznesowe danych, a wspominam o tym dlatego, że jeżeli pracujemy na przykład w jednej lokalizacji jak w Polsce, to myślę, że może nie być problemu, ale kiedy mamy współpracę międzynarodową, to może się okazać, że my tutaj mierzymy w kilogramach i metrach, a nasi koledzy ze Stanów mierzą w galonach i w milach. Warto o tym pamiętać, ponieważ jeden z takich słynnych błędów z NASA właśnie się opierał na tym, że było za mało paliwa, ponieważ w jednym miejscu używali innych jednostek niż w drugim. Nawet jeżeli nam się wydaje, że rozumiemy jakieś dane, warto to sprawdzić, szczególnie przy współpracy międzynarodowej. Double check, zawsze spoko. Kolejna rzecz, kolejny aspekt, który tutaj wychodzi, to jest odpowiedzialność za te dane, bo ok, będziemy mieć ludzi, którzy projektowali te systemy, ale tych ludzi może już nie być, więc skąd mamy wziąć informacje? Fajnie by było mieć dobrze zrobioną dokumentację, za którą ktoś będzie odpowiedzialny, szczególnie za aktualizację tej dokumentacji, bo może się wydarzyć sytuacja, i to jest myślę, że jedna z takich mniej fajnych sytuacji w pracy, kiedy osoba, która w cudzysłowie wie wszystko, była od samego początku w danym projekcie, projektowała, tworzyła, wdrażała te systemy i utrzymywała je i cała wiedza była w głowie tej osoby i nagle się okazuje, że z jakiegoś powodu jej nie ma. Czy to urlop, czy to odeszła z pracy, czy jakkolwiek inna losowa sytuacja. Więc myślę, że warto mieć tego świadomość i jako firma, jako osoby, które pracują w zespole, dla mnie ważne jest pilnowanie, żeby nie doszło do tej sytuacji, gdzie cała wiedza jest w jednym miejscu. I teraz idąc dalej, jeżeli tworzymy nowe rozwiązanie, zadbajmy o to, żeby udokumentować dane, zadbajmy o to, że jeżeli będziemy wykorzystywać nową technologię, będą podstawiać nowe tabele, żeby była osoba odpowiedzialna za te tabele, na przykład z biznesowego punktu widzenia. W firmach można spotkać takie stanowiska czy określenia związane właśnie z tą własnością biznesową, że ktoś jest biznesowym właścicielem danych, czyli on za nie odpowiada. I wtedy możemy właśnie zapewnić tę płynność, że jeżeli chcemy rozwijać dany produkt, rozwijać dane technologie, możemy po prostu pójść do tej osoby i się dopytać. Bo przekopywanie się przez dokumentację, ja wiem, też jest ciężkie. Dobrze, żeby była dokumentacja i dobrze też, żeby mieć jedną określoną osobę, która nam pomoże. I wiadomo, dla różnych technologii, dla różnych projektów to mogą być różne osoby. I kolejna taka rzecz, która tutaj też będzie mieć znaczenie, to jest bezpieczeństwo danych, zadbanie o jakość tych danych, zadbanie w obecnych czasach o RODO. Więc w tym przypadku, kiedy integrujemy dane z wielu źródeł, musimy o to zadbać. Pytanie, czy będziemy mieć taki przypadek, kiedy RODO nas w ogóle nie obchodzi, bo nie przetwarzamy danych wrażliwych, no ale jeżeli przetwarzamy dane wrażliwe, to być może pytanie, jak je anonimizować, kto konkretnie powinien mieć dostęp do takich danych. Więc wtedy też na etapie tego projektowania, na etapie analizy, zastanawiania się, co my w ogóle mamy zrobić, mogą do nas dołączyć, czy specjaliści do spraw bezpieczeństwa, czy osoby związane z audytem, kontrolą jakości, którzy pomogą nam uporządkować ten proces. Więc podsumowując, kiedy integrujemy dane z wielu źródeł, powinniśmy przede wszystkim skupić się na znaczeniu biznesowym danych i tego, co my chcemy osiągnąć, na wykorzystaniu odpowiednich technologii i zadbaniu o to, żeby to, co my wyprodukujemy, było odpowiednio udokumentowane, była osoba odpowiedzialna za to i tak dalej, no i zadbanie o bezpieczeństwo i o jakość danych. W tym dążeniu do jedalnego świata mamy już źródła danych określone i zintegrowane, więc kolejnym krokiem w projekcie, na ile ja rozumiem, musi być zadbanie o jakość danych. Powiedz Magda, jakie techniki oczyszczania danych są najczęściej wykorzystywane i jak te techniki wpływają na jakość modeli uczenia maszynowego? To jest bardzo ważny krok, jak nie najważniejszy z punktu widzenia data scientisty, natomiast możemy sobie tutaj popatrzeć na to przez przyzwę takich dwóch etapów. Pierwszy etap, w sumie powiązany z Twoim poprzednim pytaniem, jakość danych to jest jedna z najważniejszych rzeczy, szczególnie z punktu widzenia data scientisty. I w tym przypadku możemy sobie na nią popatrzeć w dwóch kierunkach. Pierwszy kierunek, związany z Twoim poprzednim pytaniem, czyli zapewnienie jakości danych już na etapie zbierania danych, na etapie integracji systemów i zastanawiania się, jakie my w ogóle mamy dane bazowe, bo być może już w tym momencie jesteśmy w stanie wyłapać część błędów, zadbać o to, żeby w ogóle błędne dane się nie zapisywały do naszych kabel, bo po co nam błędne dane. Druga rzecz jest taka, że kiedy ja jako data scientist dostaję jakiś problem, dostaję dane, nad którymi mogę pracować, no to zaczynam właśnie od sprawdzenia jakości tych danych. Pierwsza rzecz, na którą zwracam szczególną uwagę, to są brakujące wartości. I tutaj znowu wracamy do biznesowego zrozumienia naszego problemu, ponieważ jest pytanie, skąd się biorą te brakujące wartości. Czy one wynikają z charakterystyki naszych danych i tak po prostu będzie, że na przykład system wysyła informacje, kiedy jest sytuacja A, B. W przypadku sytuacji C nie ma żadnej informacji, więc mamy puste. Czy na przykład sytuacja wyniknęła z tego, że mamy jakieś błędne dane, braki dany, w takim kontekście, że dane się zapisują do tabeli, ale z jakiegoś powodu coś się nie zapisało. Mamy pustą sytuację, puste miejsce w naszej tabelce, więc wtedy najlepiej pójść do osoby, która rozumie nasz problem z punktu widzenia biznesowego, czy która odpowiada za technologię, która stoi za zapisywaniem tych danych i dopytać się, kiedy, w jakich przypadkach mogą wystąpić te sytuacje. I na tej podstawie decydujemy, co będziemy robić z brakami danych. Czy na przykład usuniemy te dane, ponieważ może być tak, że to są pojedyncze przypadki i one rzeczywiście wynikają z jakiegoś błędu gdzieś na którymś etapie, więc jeżeli naszym celem jest teraz stworzenie modelu, no to nie ma sensu uwzględniać tych pojedynczych sytuacji w nauce modelu. Ale może być też sytuacja, gdzie właśnie mamy bardzo dużo braków danych. Pytanie, czy w ogóle będziemy w stanie wyciągnąć sensowne informacje dla naszego modelu z bardzo dużej ilości brakujących danych, ale powiedzmy, że mamy tak trochę tych braków danych występuje, ale nie jest to jeszcze jakoś bardzo dużo. Czyli powiedzmy na przykład 10-20%, zidentyfikowaliśmy, jakie to są sytuacje, skąd są te braki danych, no i wtedy decydujemy, czy na przykład wprowadzamy jakąś inną wartość całkowicie spoza zakresu, żeby było wiadomo, że coś się dzieje, ale nie jest to typowa sytuacja. Albo na przykład uzupełniamy te braki danych średnią, czy medianą, czy najczęściej występującą wartością. I tutaj właśnie te decyzje z mojej perspektywy jako data scientista powinny być podejmowane z właścicielem biznesowym, osobą, która nam zna ten projekt, która rozumie te dane i ona potwierdzi, że okej, w naszym konkretnym przypadku spokojnie możemy na przykład wykorzystać jakąś jedną wartość, którą uzupełnimy te braki. Kolejna rzecz, na którą powinniśmy zwrócić uwagę, no to występowanie duplikatów, bo z jakiegoś powodu w naszym zbiorze danych, na którym pracujemy, występują duplikaty, więc znowu, możemy sprawdzić, dlaczego one wystąpiły, albo po prostu usunąć te duplikaty, bo one nie wprowadzają nam żadnej dodatkowej wartości. Kolejna rzecz już przy analizowaniu danych, czyli rozkłady naszych danych, dobrze jest zrozumieć charakter naszych danych, czy na przykład typowo rozkład normalny jakaś dana ma, czy na przykład jest tylko parę wartości i pytanie, czy liczności w poszczególnych kategoriach są równoliczne, albo czy występuje sytuacja, gdzie na przykład jednej kategorii jest bardzo mało, a pozostałe są bardzo liczne, bo wtedy pytanie, czy nasz model w ogóle wyłapie jakieś wartości z tych kategorii. Bardzo mało licznych kategorii. Może być na przykład sytuacja, że mamy bardzo dużo kategorii, powiedzmy kilkaset i wtedy te kategorie, które są bardzo mało liczne, mogą nam tylko wprowadzać szum do modelu, więc może się okazać, że dobrym pomysłem jest złączenie tych kategorii w jedną, na przykład inne, albo możemy to dowolnie nazwać, my wykonujemy taką transformację danych, to też będzie bardzo zależeć od naszego konkretnego przypadku, więc w tym momencie może to być hipoteza do przetestowania, jak ta transformacja będzie wpływać na model. Wspomniałam o zmiennych kategorycznych, czyli sytuacji, kiedy mamy na przykład kolory czerwony, niebieski, zielony. No i większość modeli maszyn learningowych działa na liczbach, więc nie możemy podać tekstu czerwony, niebieski, zielony do naszego modelu, musimy coś z tym zrobić, więc możemy na przykład zamienić nasze kategorie na liczby i na przykład powiedzieć, że czerwony oznacza jeden, niebieski oznacza dwa, zielony oznacza trzy i tak dalej. Tylko wtedy może się pojawić sytuacja, że nasz model pomyśli sobie, że na przykład czerwony to jest dwa razy fioletowy, bo czerwony miał dwójkę, a fioletowy miał czwórkę, więc cztery podzielić na dwa jest dwa. Generalnie model być może wyłapie taką zależność, a może nie, więc inną techniką, którą można tu wykorzystać, jest taka sytuacja, taka technika, w której tworzymy trzy nowe kolumny, czyli odpowiadalibyśmy wtedy na pytanie, czy coś jest czerwone, czy coś jest żółte, czy coś jest niebieskie, czy coś jest fioletowe. Czyli z jednej kolumny, gdzie mieliśmy kolory, mamy cztery dodatkowe kolumny i teraz nasz model nie wyciągnie dodatkowych zależności między transformacjami, które wykonamy, bo ich nie ma, ale co jest wadą tego podejścia, no to pojawi się nam bardzo dużo kolumn dodatkowych, które co więcej będą kolumnami rzadkimi, czyli będziemy mieć sytuację, gdzie będzie jedna jedynka i same zera w pozostałych kolumnach, co też może być problematyczne, czy może nie być tak dobre dla naszego modelu. Więc tutaj znowu, warto znać różne techniki radzenia sobie z kategoriami i sprawdzić, która technika będzie lepsza dla naszego modelu. Kolejna rzecz, która w tym idzie, to jest sprawdzenie poprawności danych, czyli takie biznesowe. Czy na przykład, jeżeli mamy trzy kategorie i one są ze sobą powiązane w jakiś sposób biznesowy, to czy rzeczywiście te reguły występują w naszej sytuacji. I tutaj akurat przykład z projektu, który realizowałam dla siebie w ramach nauki, gdzie celem było ocena danego produktu. I była taka sytuacja, że mieliśmy wymienione składniki i informacje, czy dany produkt jest wegański, wegetariański, czy zawiera mięso itd. I jedna z rzeczy, którą należało zrobić właśnie analizując te dane, było sprawdzenie, czy rzeczywiście produkt, który jest opisany jako wegetariański, nie zawiera odpowiednich rzeczy. Tak samo z wegańskim, albo czy produkt, który jest oznaczony jako z mięsem, rzeczywiście zawiera mięso w którejś kolumnie. Czyli wtedy wykorzystujemy naszą wiedzę, żeby sprawdzić. Tak samo może być sytuacja, kiedy mamy nasze dane i mamy dziwne wartości. W sensie one są dziwne dla nas, jako osób analizujących dane, czy dla osób, które zajmują się tymi danymi na co dzień właścicieli biznesowych. I taka osoba może nam od razu powiedzieć, że ta sytuacja nie ma prawa wystąpić. Czyli dlaczego musimy się wtedy zastanowić, dlaczego ta sytuacja wystąpiła, na którym etapie wkradł się błąd i co my z tym chcemy zrobić. Czy na przykład chcemy usunąć taki wiersz, takie dane, czy znowu chcemy czymś zastąpić. Ja zawsze zachęcam, że jeżeli mamy taką sytuację, że zdecydujemy, że ok, czy chcemy usuwać, czy chcemy zastąpić, to żeby zalogować te informacje, zapisać, że w tym i w tym przypadku zastępujemy taką i taką wartością, bo wtedy możemy sobie potem znowu przeanalizować, jak często to występuje i co my z tym robimy. Tak jakby kolejne sprawdzenie już na przykład po wdrożeniu modelu upewniamy się, że na pewno nie pominęliśmy żadnej sytuacji, która mogła wystąpić, bo przy dużych projektach chcąc nie chcąc to się może zdarzyć. Więc warto znowu zrozumieć, jakie mamy zakresy wartości, jakie mamy rozkłady, czego się spodziewamy albo co jest bardzo niespodziewaną sytuacją. Więc znowu bierzemy naszą biznesową osobę i rozmawiamy z nią i ustalamy, co powinniśmy zrobić z naszymi danymi. No i kolejna rzecz, która też jest tutaj związana, to jest wykrywanie anomalii, czyli sprawdzanie, czy mamy jakąś wartość ciągłą, na przykład wzrost albo wiek i powiedzmy, że sytuacja, że ktoś ma 0 lat albo ktoś ma 2,5 metra wzrostu, właśnie czy ona jest prawdziwa, czy dane, które zbieramy, mają prawo tak wyglądać, bo na przykład my mamy jakiś system, który zakłada, że wszyscy nasi użytkownicy są pełnoletni, więc jeżeli dostaniemy informację, że jest 0, ktoś ma 0 lat, no to gdzieś tu jest problem. I kolejne pytanie, co z tym zrobimy? Więc o jakość danych zadbaliśmy, o tym najważniejszy etap w projekcie. To teraz pytanie, co dalej? Jakie są etapy budowy modelu uczenia maszynowego? A jakie z tych etapów będą kluczowe przy wdrażaniu na środowisko produkcyjne? Ok, to pierwsza rzecz, którą warto podkreślić, że proces stworzenia modeli machine learningowych nie jest najczęściej liniowy. Często będziemy wracać do poprzednich etapów, żeby na przykład się spytać, żeby właściciel biznesowy mógł podjąć jakieś decyzje, że sprawdziliśmy jakąś hipotezę, no i teraz co robimy z tą hipotezą? Więc ja pozwolę sobie jeszcze wrócić do pierwszego kroku, czyli do zrozumienia biznesu. Więc musimy zrozumieć biznes, zrozumieć, jakie są oczekiwania i ustalić, jakie będziemy mieć metryki, które będą oceniały, czy nasz model jest wystarczająco dobry. Możemy też zwrócić uwagę na to, jaki jest czas oczekiwania, aż model się nauczy, jakie koszty są akceptowalne dla naszego biznesu, bo może być na przykład sytuacja, gdzie wykorzystujemy środowisko chmurowe, które kosztuje odpowiednie pieniądze i na przykład nie chcemy, żeby proces uczenia kosztował nas więcej niż. I to są rzeczy, które warto mieć na uwadze na samym początku, warto ustalić z naszym biznesem na samym początku. Potem zbieramy dane, czyli to, co już powiedzieliśmy. Integrujemy je z wielu źródeł, analizujemy, jakie mamy dane i co z nimi możemy zrobić. Kolejny krok, czyli ten, o którym już wspomnieliśmy w poprzednim pytaniu, czyli oczyszczanie danych. I tutaj te wszystkie rozkminy, które przedtem mieliśmy, co nasze dane oznaczają, co z nimi zrobić i tak dalej. No i potem jest analiza eksploracyjna danych z feature engineeringiem. I może być tak, że już w czasie oczyszczania danych zrobimy część analizy eksploracyjnej. Pojawią nam się pomysły, jakie dodatkowe cechy możemy wyciągnąć. To jest też sytuacja, gdzie właśnie mając wiedzę biznesową, możemy do naszego zbioru danych dołączyć jakieś cechy. Albo okaże się, że analizując dane, pomyślimy sobie, że o, dodatkowe cechy by się przydały. No i zaczynamy szukać, czy być może gdzieś te dane już są w filmie zbierane. Więc wracamy do sytuacji, kiedy rozmawialiśmy o integracji z różnych źródeł danych. No i kolejny krok to już budowa modelu. Najpierw zbudujmy sobie jakiś prosty model, który będzie naszym benchmarkiem. Czyli zbudujemy najprostszy możliwy model i chcemy, żeby każda nasza kolejna iteracja poprawiała wyniki naszego modelu według tych metryk, które ustaliliśmy na początku z naszym biznesem. I w tym przypadku znowu będziemy wracać. Będziemy wracać do feature engineeringu. Będziemy wracać do transformacji danych. Tak jak wspomniałam wcześniej, to jest ten etap, gdzie na przykład sprawdzimy, czy lepiej nasze kolory zakodować używając cyfr 1, 2, 3, 4, czy lepiej nasze kolory zakodować używając oddzielnych kolumn, czy to jest czerwone, czy żółte, czy niebieskie i tak dalej. I to jest ten moment, gdzie budujemy bardzo dużo modeli i gdzie testujemy nasze hipotezy. No i jak już mamy model, który jest wystarczająco dobry, możemy go wdrożyć na produkcję. Bo to też warto tutaj podkreślić. Może się okazać według zasady Pareto, że na przykład zbudujemy model, który będzie wystarczająco dobry i zajmie nam to 80% czasu, a powiedzmy, że kolejne 20 byśmy chcieli poświęcić na polepszenie tego modelu, ale to będzie w bardzo niewielkim stopniu. I teraz, jeżeli pracujemy zwinnie, chcemy jak najszybciej dostarczyć produkt, to w sytuacji, kiedy mamy z naszym biznesem ustalone, jakich wartości, metryk on oczekuje, jaki model będzie dla niego wystarczająco dobry, możemy ten model wdrożyć na produkcję i on już będzie przynosił naszemu właścicielowi biznesowemu, naszemu klientowi wartość, a potem my sobie na spokojnie kontynuujemy pracę, polepszamy nasz model i teraz, jeżeli mamy lepsze efekty, możemy wdrożyć nowy model na produkcję. Niestety, po wdrożeniu na środowisko produkcyjne projekt się nie kończy. Tylko musimy zadbać o monitorowanie i ciągły rozwój. Magda, podziel się z nami, jakie narzędzia i techniki są stosowane do monitorowania modelu uczenia maszynowego i do monitorowania jakości danych. Dokładnie. Sytuacja wygląda w ten sposób, że kiedy my sobie wdrażamy ten model na produkcję, nie możemy zrobić jednego wielkiego uff i zabrać się za nowe projekty, ale cały czas musimy zadbać o nasz model. Więc przede wszystkim, jeszcze robiąc rok wstecz, musimy monitorować eksperymenty. Czyli ta sytuacja, kiedy testujemy różne historyce, testujemy różne modele, fajnie jest gdzieś zapisywać dane z tych eksperymentów i tutaj świetnym open source'owym narzędziem jest MLflow. Dodatkowo mamy polski Neptun AI, mamy WNB, jak również będziemy mieć narzędzia związane z poszczególnymi technologiami chmurowymi. Czyli jeżeli pracujemy na przykład na GCP, no to GCP ma taką platformę jak Vertex AI i w ramach niej można monitorować eksperymenty i zarządzać modelami. Czyli w tej sytuacji środowisko chmurowe, które wykorzystujemy, biera za nas część pracy z tym samym zezworem narzędzia do monitorowania eksperymentów, więc warto to mieć na uwadze. Kolejna rzecz to monitorowanie modeli i tutaj MLflow też zapewnia właśnie ten moduł dotyczący monitorowania modeli, zarządzania nimi, czyli na przykład sytuacja, kiedy ja jako data scientist mówię, że tutaj ten model jest gotowy do produkcji, więc na przykład albo ja, albo inna osoba może ściągnąć z produkcji obecny model i właśnie odmienić, więc to jest bardzo fajne narzędzie. Z takich ciekawych narzędzi, które de facto są kombajnami, no to jest ewidently AI, które właśnie zapewnia nam możliwość monitorowania modeli czy monitorowania danych na każdym etapie. Kolejna rzecz, o którą musimy zadbać to monitorowanie jakości danych i z jednej strony musimy zadbać o to, co wpływa do naszego modelu i ewentualnie wykonać jakieś przekształcenia na tych naszych danych, czyli powiedzmy nauczyliśmy nasz model na tych naszych przygotowanych, oczyszczonych danych, ale przychodzi do nas request, gdzie brakuje jakiejś informacji i wtedy na potrzeby odpowiedzi naszemu klientowi może się okazać, że lepiej będzie uzupełnić na przykład średnią, medianą, najczęściej występującą wartością, skądaną, brakującą rzecz, tak przygotowane dane wrzucić do modelu, żeby on nam zwrócił odpowiednią odpowiedź, którą dalej przekażemy naszemu klientowi, naszemu biznesowi, niż na przykład w ogóle nie odpowiedzieć, bo nam się wysypie proces i coś, o czym już wspominałam, warto jest wtedy zalogować, zapisać taką sytuację, że ona wystąpiła, żebyśmy mogli przeanalizować, dlaczego się coś takiego stało, więc tutaj mamy jedną część dbania o jakość danych, no i też powinniśmy zadbać o jakość danych, które wychodzą z naszego modelu, sprawdzać, czy te wyniki mają biznesowy sens, sprawdzać, jak nasz model zachowuje się w czasie, więc na bieżąco monitorujemy wyniki naszego działania, naszego modelu, gdzieś to sobie zapisujemy i patrzymy, czy nic się z tym nie dzieje, ponieważ może na przykład wystąpić sytuacja, tak zwany tryf danych, kiedy nasze dane mają na przykład charakter sezonowy i będą się one różnić w lecie od tego, co jest w zimie, tak, że na przykład w grudniu mamy pik sprzedaży, albo to na przykład może wystąpić przy systemach rekomendacyjnych, z którymi ja na co dzień pracuję, czyli to, jak my oglądamy dane rzeczy, będzie stanowić sytuację, gdzie de facto cały czas charakter naszych danych będzie się zmieniać, albo jesteśmy bardziej zmęczeni, albo tutaj nas zainteresowały śmieszne kotki, a to coś innego nas wciągnęło i chcemy, żeby nasz model się dostosowywał na bieżąco do tych danych, więc wtedy, kiedy złapiemy tę sytuację, że coś się dzieje z naszymi danymi, coś się dzieje z wynikami naszego modelu, możemy na przykład początkowo ręcznie zrobić kolejny trening naszego modelu, albo już w kolejnych fazach, kiedy ten model będzie na produkcji, już chwilę, co jakiś czas automatycznie zlecać trening w modelu, albo kiedy na przykład spadnie poniżej jakiegoś progu, więc na tym końcowym etapie, gdzie wydaje się, że model już działa na produkcji, też musimy śledzić te wyniki. I jeszcze jedna rzecz, którą warto mieć w głowie podczas monitorowania, to jest monitorowanie wydajności naszego modelu, czy tych wszystkich rzeczy, które są związane tak naprawdę z takim typowym monitorowaniem rozwiązań IT, czyli sprawdzamy, jak szybko nasz model odpowiada, czy odpowiada bezbłędnie, czy występują sytuacje, gdzie dzieje się coś niepożądanego, no i wtedy możemy wykorzystać czy prometeusa, grafany, czy inne narzędzia do zbierania logów, żeby móc to wszystko śledzić. Ogrom pracy wykonaliśmy przy tworzeniu modelu maszynowego. Czas przygląda się korzyściom. Czy możesz nam, naszym słuchaczom, opowiedzieć kilka przykładów realnych projektów, w których wykorzystywane jest sztuczne inteligencje i który przyniosł wymierne korzyści? Dobrze. To pierwsza rzecz, pierwszy projekt, od którego mogę zacząć, no to w rzecz technologii. Obecnie pracujemy nad systemem rekomendacyjnym, no i tam wykorzystujemy modele uczenia maszynowego. Kolejna rzecz, czy kolejna grupa projektów, które będą przynosić realną wartość z wykorzystaniem uczenia maszynowego i sztucznej inteligencji, to są te wszystkie projekty, w których przetwarzamy obraz. Ponieważ nie wyobrażam sobie już na dzień dzisiejszy, czy ręcznie przetwarzać obraz, czy wykorzystywać statystyczne metody do przetwarzania obrazu, a w sytuacji, gdzie modele sieci neuronowych, modele sztucznej inteligencji bardzo dobrze sobie z tym radzą. Więc tam, gdzie mamy obraz, najprawdopodobniej najlepiej będzie użyć jakichś modeli machine learningowych. Kolejna rzecz, to jest w ogóle problem wykrywania anomalii, czyli nasz system działa sobie poprawnie, ale chcemy wyłapać tę sytuację, kiedy dzieje się coś niedobrego. I teraz, z jednej strony możemy mieć biznesowe reguły, ale z drugiej strony możemy właśnie mieć modele machine learningowe do tego. Dziękuję. Obszar sztucznej inteligencji, uczenia maszynowego oraz obszar szeroko rozumianego zażądania danymi obecnie jest bardzo popularny. W związku z tym chciałabym się dowiedzieć, jakie konkretne ścieżki kariery są dostępne w data science, jakie umiejętności są najbardziej pożądane na rynku pracy i jak te roli różnią się między sobą? Jak zwykle, odpowiedź jest to zależy, ponieważ z jednej strony możemy sobie wymienić kilka ról, które są związane z data science. Pytanie jak bardzo szeroko chcemy pójść, a z drugiej strony często te role będą się przenikać. Czyli możemy sobie popatrzeć tak idąc od początku, że będziemy mieć osobne role dla data inżyniera, dla big data inżyniera, czyli osób, które będą bezpośrednio pracować z danymi na etapie właśnie zbierania ich z różnych systemów albo w ogóle zapisywania do różnych systemów, wykorzystywania różnych technologii, właśnie bazodonowych, big dataowych, projektowania tych rozwiązań, czyli zaczynamy nowy projekt, bierzemy osobę, która się specjalizuje w big data i razem z nią wypracowujemy rozwiązanie, które będzie dla nas najlepsze. Kolejne stanowisko czy rola w szeroko pojętym świecie danych to jest analityk danych, BI developer i być może trochę analityk biznesowy. Tutaj te trzy role będą się często różnić od firmy i to, co konkretnie będziemy robić w ramach tych ról naprawdę będzie zależeć od tego, czego firma, czego dany zespół akurat wymaga, natomiast te role będą się skupiać właśnie na przede wszystkim znalezieniu biznesowej wartości w tym, co mamy obecnie w danych, czyli mamy nasze dane, gdzieś one są składowane, wyciągamy je no i analizujemy te dane, tworzymy raporty, tworzymy dashboardy, wizualizujemy te rzeczy. Generalnie można powiedzieć, że teoretycznie te role nie będą wykorzystywać machine learningu, choć może się okazać, że jeżeli będzie taka potrzeba i chęć rozwoju w tym obszarze, to dlaczego nie? Natomiast właśnie analitycy biznesowi, BI developerzy będą się właśnie skupiać na tym, że analizują dane, dostarczają wartość dla biznesu na przykład na jakimś dashboardzie, gdzie nie potrzebujemy angażować IT, żeby nam na przykład stworzył portal, który będzie agregował dane, bo my to możemy zrobić własnymi siłami, bo to jest na użytek wewnętrzny, więc wystarczy nam dashboard. Kolejna grupa stanowisk, czyli data scientist i ja bym tutaj data scientista połączyła też z machine learning inżynierem, deep learning inżynierem, czyli to będą te osoby, które właśnie będą wykorzystywać machine learning, wykorzystywać modele sztucznej inteligencji właśnie do tego, żeby dostarczać wartość firmy. I teraz pytanie, czy data scientist będzie mógł po prostu pracować na przygotowanych wcześniej danych przez data inżyniera, czy też będzie zbierał od początku te dane i sam analizował, sam je oszczyszczał i tak dalej. Może też wystąpić sytuacja, gdzie na przykład machine learning inżynier to będzie ta osoba, która weźmie concept zrobiony przez data scientista, czyli jakiś model stworzony przez niego i dostosuje ten kod do wdrożenia produkcyjnego. Ponieważ tutaj jest często przy tych początkowych pracach wykorzystuje się takie narzędzie jak Jupyter Notebook, gdzie lei komórka po komórce, możemy sobie odpalić, śledzić na bieżąco nasze przekształcenia z danymi, śledzić na bieżąco co się dzieje z modelami i tak dalej, natomiast w tej formie to się nie nadaje do wdrożenia na produkcję, więc albo nasz data scientist sam doprowadzi model do takiego stanu, czy doprowadzi kod w taki sposób, że będzie mógł być wdrożony na produkcję, albo będziemy mieć osobną osobę od tego, najczęściej to się może nazywać stanowisko machine learning inżynier, która właśnie nam weźmie ten kod i dostosuje go do tego, żeby wdrożyć go na produkcję. No i idąc dalej, mamy MLOpsów, czyli osoby, które właśnie mogą się już zajmować wdrożeniem naszych modeli na produkcję, mogą się zajmować zarządzaniem tymi modelami, jak również mogą tutaj pilnować tej jakości danych, o której mówiliśmy wcześniej, która jest bardzo ważna. Pytanie, czy znowu będziemy mieć osobne osoby od tego, czy ten nasz data scientist będzie odpowiedzialny za wdrożenie na produkcję, więc tak naprawdę to wszystko zależy od tego, do jakiego zespołu trafimy, w jakiej firmie, bo może się okazać, że trafimy do dużej firmy, gdzie projekty związane z danymi są realizowane od lat, więc mamy już wyodrębnione stanowiska, mamy wyodrębniony zakres zadań i zakres odpowiedzialności, a może wystąpić sytuacja, gdzie właśnie trafimy do małej firmy, jest mały zespół i tak naprawdę robimy wszystko, co potrzeba, na przykład jestem tym data scientistem, specjalizuję się w modelach uczenia maszynowego, ale jeżeli jest potrzeba, że do naszego systemu chcemy użyć CAD-ki czy Redis-a, no to się po prostu uczy tej technologii i próbuję ją zastosować, sprawdzić, czy ona u nas ma sens i wdrożyć na produkcję. Myślę, że nasi słuchacze już mają pogląd na ścieżki kariery w obszarach, które nas interesują. A jakie masz rady dla osób, które rozwijają karierę w data science, ale nie mają jeszcze dużego doświadczenia technicznego? Jakie pierwsze kroki powinni podjąć? Jakie kursy lub certyfikaty warto zdobyć oraz jakie projekty lub zadania mogą pomóc im w budowaniu niezbędnych umiejętności i doświadczenia w tej dziedzinie? Pierwsza rzecz, od której zacznę i która jest bardzo, bardzo ważna, jak nie najważniejsza, to w ogóle realizowanie projektów, bo czy my weźmiemy książkę do nauki, czy my weźmiemy kurs, to nie ma znaczenia. W sensie to, z czego lubimy się uczyć, to, co nam jest wygodniej, z czego nam lepiej wiedza przyswaja, warto się konkretnymi książkami lub kursami zainteresować. Natomiast to, co jest ważne, to właśnie, żeby po pierwsze robić projekty i wrzucać je na GitHuba czy na Kaggle, ponieważ Kaggle to jest platforma, która zbiera dane, organizuje konkursy i możemy nasze portfolio budować właśnie w oparciu o Kaggle. Ważne jest to, żeby te projekty były dobrze opisane, czyli jaki mamy problem, skąd mamy dane, co robimy z naszymi danymi, jakie budujemy modele, ewentualnie, jeżeli mamy takie możliwości, umiejętności, to możemy rozbudować właśnie taką część z dashboardem, z wizualizacjami, tak żeby osoba, która na przykład będzie rekrutować, mogła sobie wejść pod jakiś adres i poklikać po tym naszym dashboardzie. I wtedy pokazujemy, że my potrafimy od początku do końca zrealizować projekt. To, co może być fajnym pomysłem, to jest na przykład dodanie od siebie notatek czy jakichś artykułów podsumowujących poszczególne etapy, czy na Medium, czy na własnym blogu, czy na przykład na LinkedIn. I chodzi o to, żeby pokazać, że my po prostu wiemy, że jak dany rekruter popatrzy na nasze CV, popatrzy na linka do GitHuba albo do Kaggle, wejdzie, zobaczy, że jest tam zrealizowany projekt, zobaczy linka do LinkedIna, wejdzie, popatrzy, są napisane artykuły, no to właśnie będzie wiedział, że okej, ta osoba poświęciła czas, przygotowała się, nauczyła się, zrealizowała w praktyce jakiś projekt. To jest bardzo ważne, ponieważ czasem spotykam się z sytuacją, kiedy w CV nie ma w ogóle informacji o projektach. Okej, są opisane umiejętności, są opisane projekty, ale nie ma tego linku, żeby móc sprawdzić. Pojawia się pytanie, czy rekruter zajrzy, czy na przykład jeżeli mamy rekrutera bardziej ze strony HR niż technicznego, to czy on coś z tego wyciągnie. I tak, i nie. Wyciągnie informację, że okej, to jest, natomiast potem rekruter techniczny będzie mógł wejść, popatrzeć i na tej podstawie na przykład zadać pytania. To też nas może fajnie ustawić na rozmowie rekrutacyjnej, gdzie powiedzmy tak trochę dla przełamania lodów, czy dla zadania łatwiejszych pytań na początku, rozmowa skupi się na naszych projektach i wtedy my, jak wiedząc, że przerobiliśmy cały temat, możemy się, możemy o tym opowiadać. Coś, co na przykład ja robiłam, kiedy szukałam właśnie swojej pracy w Data Science, to zaangażowałam się w projekt grupowy. Akurat była taka sytuacja, że firma Data Workshop, która między innymi realizuje kursy, realizuje też krótsze wyzwania, zorganizowała wyzwanie, my jako uczestnicy powiedzieliśmy, że chcemy więcej, więc zrobiło się kolejne wyzwanie i pojawił się pomysł grup w miastach. Więc ja się zgłosiłam do prowadzenia takiej grupy i słuchajcie, ja na początku nie wiedziałam, z czym sieje Data Science. Miałam kiedyś coś na studiach, chciałam to robić, ale to był sam początek mojej nauki i na tyle, na ile mogłam, koordynowałam pracę tej grupy, brałam udział aktywnie w projektach, przygotowywałam kod i ja się po prostu tym chwaliłam na LinkedIn'ie. Więc był taki moment, że jak ktoś wchodził na mojego LinkedIn'a, to co tydzień był post właśnie o tym, że mieliśmy spotkanie grupy, zrobiliśmy takie i takie rzeczy, omówiliśmy takie problemy, teraz będziemy nad tym pracować, tu jest kod, tacy ludzie pracowali nad tym. I w ten sposób, kiedy rekruter wchodził na moją stronę, to widział zaangażowaną osobę. Więc jeżeli zaczynacie uczyć się danego tematu, może warto właśnie znaleźć osoby, które też się tego uczą, rozpocząć pracę grupową, rozpocząć wspólny projekt i po prostu się tym chwalić, że się uczycie, robicie, a tutaj są efekty. Z takich sytuacji, żeby Wam też pokazać, że to ma sens, mam dwie sytuacje w głowie. Pierwsza jest taka, że na Facebooku była taka grupa Machine Learning Study Group, gdzie ona przerabiała materiał z książki. I w pewnym momencie właśnie osoba, która była inicjatorem tej grupy, napisała posta, że między innymi dzięki temu znalazła pracę, bo tutaj organizowała spotkania grupy, uczyli się, to pozwoliło się dostać na rozmowę rekrutacyjną. Druga rzecz, osoba, którą śledza trochę bardziej z cyberbezpieczeństwa, ale mechanizm był ten sam, tworzyła filmy na YouTubie o tym, czego się uczy, czyli nie pozycjonowała się na eksperta, ale właśnie z punktu widzenia osoby początkującej pokazywała, czego się uczy, czego się nauczyła, jakie popełniła błędy, jakie ma problemy i tak dalej. I dzięki tej widoczności w sieci dostała właśnie zaproszenie na rozmowę rekrutacyjną. I o to w tym chodzi, że w momencie, kiedy jesteście na początku swojej drogi, nie macie doświadczenia, nie chcą Was zatrudnić, bo nie macie doświadczenia, to trzeba sobie to doświadczenie znaleźć. I jeżeli uważacie, że data science to jest dla Was, to jak najbardziej jest dla Was, tylko trzeba poświęcić na to pracę. Tu bym chciała jeszcze jedną rzecz powiedzieć, że samo data science najczęściej nam się kojarzy właśnie z modelami uczenia maszynowego, ze sztuczną inteligencją i innymi seksji, tematami. Ale tu również będzie ta big data, która sama w sobie może bardzo być ciekawym tematem, czy ciekawym obszarem, którym warto się zająć, jak również MLOpsy, czyli to też jest ostatni etap, on sam w sobie jest bardzo rozległy. Więc w data science warto szukać swojej ścieżki, jest wiele możliwości. Natomiast to, co jest najważniejsze na początku, to robienie projektu i udostępnianie ich. A co w przypadku przekwalifikowania się? Czy masz dodatkowe wskazówki dla osób poszukujących praktycznego doświadczenia, żeby móc zacząć zawodowo już działać w nowej dziedzinie? Jak najbardziej. Generalnie to, co wcześniej powiedziałam, tyczy się również osób przekwalifikujących się. Natomiast chciałabym tutaj jeszcze dodać jedną rzecz. Ponieważ często osoby, które się przekwalifikowują, mają już jakieś wiedzę, doświadczenie, pracowały w danych projektach. I to można wykorzystać jako atut. I tak jak chciałam, żeby przez tą naszą rozmowę wybrzmiało, że zrozumienie problemu biznesowego jest bardzo ważne, to może się właśnie okazać, że osoby, które przekwalifikowują się z danego biznesu na data science, właśnie mają tą biznesową wiedzę. Czyli na przykład, jeżeli mamy ubezpieczenia i aktuariat, to osoby, które pracowały w aktuariacie, a potem przyskakują do data science, mają na przykład, myślę, że mogę to powiedzieć, bardzo dużą przewagę nade mną. Bo ja jestem osobą, która skończyła informatykę. Jestem osobą, która, ok, umie programować, zna różne tekstologie, specjalizuje się w data science. Natomiast dla mnie każdy projekt w nowej dziedzinie, właśnie tym będzie projektem w dziedzinie, o której nie mam pojęcia, o której muszę zdobyć wiedzę biznesową, o której będę musiała cały czas prawie chodzić i się pytać, doczytywać, dopytywać, żeby się upewnić, że na pewno wszystko jest w porządku i ja dobrze rozumiem. A kiedy mamy sytuację, że osoba z biznesu wchodzi do data science, to ona już ma tą wiedzę. Więc teraz, jeżeli pracujesz w jakiejś działce, czymś się zajmujesz, zastanów się jak tam możesz analizować dane. Jakie projekty związane z tym obszarem możesz wykorzystać. I w ten sposób rozwijać swoje umiejętności w data science. I tutaj kolejny przykład osoby, której się to udało, czy która to zrobiła, jest Kajo Rudziński. Być może go kojarzycie właśnie z Kajo Data. On właśnie to zrobił. Jako humanista, osoba zajmująca się czymś w firmie, wykorzystała to, co robi, żeby móc zacząć analizować te dane, pokazać wartość dla firmy i się nauczyć. I to jest, myślę, że bardzo fajna ścieżka kariery. I w tym momencie te same rady, które były wcześniej. Czyli wybierzcie sobie problem, którym się zajmujecie na co dzień i zróbcie projekt z tym związany, wykorzystując techniki data science. Dziękuję za wyczerpującą odpowiedź. Już zmierzamy do końca naszego nagrania. Postanowiliśmy każdego z naszych gości dodatkowo prosić o polecenie jednego lub dwóch sprawdzonych źródeł rozwojowych, którymi chcieliby podzielić się z naszymi słuchaczami. To może być książka, podcasty, kursy. Magda, co ze swojej strony możesz polecić? Ja mogę polecić dwie rzeczy. Pierwsza rzecz, trochę bardziej kursowa, to jest grupa Data Talks Club i oni realizują darmowe kursy, które są w takiej formie kilkutygodniowych kursów, gdzie w każdym tygodniu jest rany temat, na koniec trzeba zrobić projekt, żeby dostać certyfikat i te kursy startują parę razy w roku i oni właśnie mają kursy z data engineeringu, z machine learning engineeringu, z MLOPS-ów, teraz nowy kurs jest z LLM-ów i też kurs, który w tym roku ruszył, czyli analiza danych giełdowych i właśnie dają bardzo dużą wartość za darmo, ale żeby dostać certyfikat trzeba zrobić projekt, więc wtedy już mamy pierwszy projekt do portfolio. I druga rzecz, drugie źródło, do którego chciałabym Was zaprosić, to meet-upy Polish Machine Learning Community, których jestem współorganizatorem. Jeździmy po całej Polsce, kolejny meet-up będzie 21 września w Poznaniu i tutaj na tych meet-upach po pierwsze zbieramy społeczność z całej Polski i już nie tylko, ponieważ na ostatni meet-up dołączyli do nas prelegenci z Berlina czy z Nowego Jorku, więc tworzymy już praktycznie międzynarodową społeczność, więc jest to fajna okazja do poznania superludzi, porozmawiania o projektach, o wyzwaniach, być może pochwalenia się swoimi rzeczami i właśnie zderzenia się z tym, jak w praktyce wyglądają projekty, ponieważ tutaj te rozmowy kolorowe i networking to jest coś, co uważam, że jest siłą tych meet-upów, więc serdecznie Was zapraszam. Bardzo wartościowe polecenia, zapraszamy na meet-upy, a ja dziękuję Tobie Magdo za podzielenie się swoją wiedzą i doświadczeniem. Mam nadzieję, że nasi słuchacze znaleźli wiele wartościowej informacji i inspiracji do rozwoju kariery w data science i big data. Dziękuję bardzo i mam nadzieję, że do zobaczenia. Dziękuję wszystkim słuchaczom za uwagę i zapraszam na kolejny odcinek naszego podcastu już za tydzień.