Naukowcy zajmujący się danymi zazwyczaj pochodzą z innego środowiska niż inżynierowie oprogramowania. Niekoniecznie robią z nich świetnych programistów. W rzeczywistości, nigdy nie zamierzali nimi być – dla naukowca wiedzy kodowanie jest po prostu sposobem na rozwikłanie obecnej zagadki. I zapiąć więcej. W przeciwieństwie do twórców oprogramowania, nie traktują oni kodu jako rodzaju sztuki. Oczywiście, ich mądrość jest nieoceniona, ale zakres umiejętności wymaganych do tego, by być odnoszącym sukcesy badaczem danych jest już szeroki (zwłaszcza gdy sektor ten często ewoluuje wraz z nowymi odkryciami, czyniąc dużą część ciężko zdobytej wiedzy przestarzałą na co dzień). Zbyt szeroki. Nie oczekuj od osoby, która jest wysoce wyspecjalizowana w wizji komputerowej lub analizie nakazowej, że będzie również programistą chleba i masła, produkującym modele i umieszczającym je w ciężkim środowisku chmury. Przy jednoczesnym zachowaniu najwyższej jakości, kodu wielokrotnego użytku. Korzystanie z programowania funkcjonalnego. Lub reaktywny. Albo obu.
Z drugiej strony, inżynierowie oprogramowania są dość powściągliwi, jeśli chodzi o naukę maszynową. Cała ta koncepcja jest dość dziwna z ich perspektywy, zwłaszcza gdy większość tzw. modeli, które tworzy ich zespół naukowy to krótkie, hakkowate skrypty z dziwnymi wywołaniami metod i nieczytelnym kodem w nieznanym języku. Gdzie są wszystkie wzorce planowania? Gdzie jest ten czysty kod? Gdzie jest logowanie lub monitorowanie? Dlaczego ten kod nie nadaje się do ponownego użycia? Czy kod rozwiązujący tak ekskluzywny problem nie powinien być dość długi na dwieście linii? To naprawdę brzydki skrypt, który może zrozumieć tylko jedna osoba! Czy to już nawet programowanie?
Fuzja
Wraz z powstaniem tego konfliktu narodził się wymóg. Wymóg dla jednostki, która może zjednoczyć dwóch wojowników. Jeden z nich jest na tyle biegły w obu dziedzinach, że może zachęcić towar do działania. Ktoś bierze kod naukowców danych i czyni go prostszym i bardziej skalowalnym. Przedstawienie im różnych zasad programowania i dobrych praktyk. Usuwanie części kodu, które mogą być wykorzystane w przyszłości. Łączenie wyników z potencjalnie niepowiązanych ze sobą zadań, aby jeszcze bardziej wzmocnić wydajność modeli. Wyjaśnianie zespołowi devopsów wyjaśnień dotyczących pomysłów architektonicznych. Oszczędzanie twórcom oprogramowania możliwości uczenia się koncepcji znacznie wykraczających poza zakres ich zainteresowań.
Potrzeba ta została zaspokojona wraz z pojawieniem się roli inżyniera uczącego się maszyn.
To, czego zawsze brakuje we wszystkich artykułach, tutorialach i książkach dotyczących ML, to środowisko produkcyjne. To dosłownie nie istnieje. Dane są ładowane z CSV, modele są tworzone w Jupyterze, krzywe ROC są rysowane i voila – Twój produkt do nauki maszynowej jest gotowy do pracy. Czas na dodatkową rundę finansowania materiału siewnego!
Trzymaj się.
W rzeczywistości większa część Twojego kodu nie jest związana z uczeniem się maszynowym. W rzeczywistości kod, który go dotyczy, zawsze zajmuje tylko kilka procent całej twojej bazy kodowej! Twój wyuczony dyktafon daje tylko małą odpowiedź JSON – są tysiące linijek kodu wymaganych do działania na przewidywanie. Albo nawet wszystko, co otrzymasz, może być wygenerowaną tabelą bazy danych z wglądem. Znowu trzeba zbudować na niej cały system, aby był użyteczny! Musisz przekonywać do informacji, przekształcać je i usuwać, automatyzować swoje zadania, prezentować swoje spostrzeżenia gdzieś czołowemu użytkownikowi. Bez względu na to, jak mała jest to sprawa, ilość pracy, jaką trzeba wykonać w trakcie samej nauki maszynowej jest ogromna, choć projekt można uruchomić za pomocą takich technologii jak Apache Airflow czy NiFi.
Ktoś musi jednak sklejać ze sobą wszystkie elementy “nauki o danych” i “oprogramowania”. Weź wyszkolony model i spraw, aby działał w środowisku produkcyjnym o wysokiej jakości. Zaplanuj harmonogram zadań wsadowych rekalkulujących tabele wglądowe. Podawaj model w czasie rzeczywistym i monitoruj jego działanie w środowisku naturalnym. I często jest to precyzyjny obszar, podczas którego inżynier uczący się maszyn świeci.
Tworząc oprogramowanie, programiści naturalnie starają się znaleźć wszystkie możliwe wyniki w każdej części aplikacji. To, co otrzymujesz od naukowca wiedzy, to po prostu wesoła ścieżka, która skutkuje stworzeniem modelu dla rzeczywistych danych w czasie rzeczywistym. Jeśli nie jest to jednorazowa, specyficzna analiza, model będzie żył przez dłuższy czas po jego wyprodukowaniu. A ponieważ czas leci, wyskakują błędy i wszystkie żądła (wiele z nich nie było nawet możliwe, gdy kod został napisany). Nagle w jednej z kolumn pojawia się nieznana wartość zastępcza i w związku z tym cały model zaczyna działać znacznie gorzej.
Jako inżynier nauki maszynowej przygotowujesz swoje aplikacje do takich zdarzeń. Starasz się zachować całą wiedzę, aby móc odpowiedzieć na naprawdę ważne pytanie: jakie jest wyjaśnienie złego działania modelu? Od kiedy to się dzieje?
To tylko kolejny API
Ponieważ nie traktujesz ML jako magii, jesteś świadomy wszystkich innych typowych zagrożeń związanych z programowaniem, które pojawią się po wykonaniu zadania uczenia się maszynowego. Baza danych może odmówić połączenia. GroupBy może powiększyć się dla gigantycznego zbioru danych. Pamięć lub dysk są często pełne. Kombinacja parametrów określonych przez użytkownika może być nielegalnym algorytmem. Usługa zewnętrzna może reagować raczej na Timeout Exception niż referencjami. Kolumna może już nie istnieć. O ile nikt nie mrugnie okiem, gdy takie zdarzenia mają miejsce w bezpiecznym środowisku laboratoryjnym na co dzień, o tyle użytkownik ma obowiązek upewnić się, że nie wystąpią one w momencie, gdy najlepszy produkt jest naprawdę dostarczany.
Twój zespół zajmujący się danymi naukowymi jest zazwyczaj pełen pomysłów. Musisz mieć pewność, że żadna technologia ich nie ogranicza. Prawie tak dobre i konfigurowalne, ponieważ obecne frameworki ML są, prędzej czy później Twoi koledzy z zespołu będą mieli intrygujący przypadek użycia, który nie jest możliwy do osiągnięcia z żadnym z nich. Cóż, nie ze standardowymi interfejsami API. Ale kiedy już zbadasz ich wnętrza, dopasujesz je i zmieszasz w innej bibliotece lub dwóch, stworzysz to możliwe. Nadużywasz frameworków i wykorzystujesz je w pełni. wymaga to zarówno rozległej wiedzy z zakresu programowania, jak i nauki maszynowej, co jest unikalne dla Twojej roli w zespole.
I nawet jeśli framework zapewnia wszystko, co chciałbyś programować mądrze, wciąż mogą pojawić się problemy z brakiem mocy obliczeniowej. Duże sieci neuronowe zajmują dużo czasu, aby trenować. Ten cenny czas może być zredukowany o rząd wielkości, jeśli używasz frameworków na GPU działających na potężnych maszynach. To Ty sprawdzasz szanse, dostrzegasz plusy i minusy różnych opcji chmury i wybierasz tę, która najbardziej Ci odpowiada.
Możesz nawet być odpowiedzialny za wybranie innych narzędzi i ekosystemów, zawsze biorąc pod uwagę cały cykl życia projektu (nie tylko lekkomyślną część badawczą) – np. Azure ML Workbench lub IBM Watson mogą być świetnymi narzędziami do uruchamiania projektu i prowadzenia badań, ale niekoniecznie spełniają wszystkie oczekiwania związane z ostateczną wersją produktu, gdy wiąże się to z niestandardowym planowaniem i monitorowaniem.
Musisz być na bieżąco z najnowszymi technologiami i stale poszukiwać miejsc, w których można by poprawić ogólną wydajność produktu. Niezależnie od tego, czy jest to sprawdzony w walce język programowania, nowa technologia w chmurze, inteligentny system planowania lub monitorowania – widząc swój produkt na szerszym tle i znając go dobrze zarówno od strony inżynieryjnej, biznesowej, jak i naukowej, często jesteś jedyną osobą, która ma szansę na określenie potencjalnego obszaru poprawy.
Często oznacza to zabranie kodu roboczego i przepisanie go w całości w innej technologii i języku. Na szczęście, gdy tylko “złapiesz się w garść” o co tak naprawdę chodzi w tym fuzz i jakie kroki są zawsze podejmowane w procesie uczenia się i produkcji modeli, zdajesz sobie sprawę, że większość z tych API nie różni się w najmniejszym stopniu. Kiedy żonglujesz pomiędzy różnymi frameworkami, przytłaczająca większość całego procesu pozostaje równoważna . Przynosisz wszystkie najprostsze praktyki wytwarzania oprogramowania i szybko zaczynasz tworzyć abstrakcję nad wieloma powtarzającymi się zadaniami, których nie udaje się zautomatyzować, a zespół zajmujący się tworzeniem oprogramowania boi się wydawać. solidny most między dwoma światami. Solidny, solidny fundament dla działającego oprogramowania.
Niezliczone wady
Można swobodnie komunikować się z wszystkimi najbardziej lubianymi technologiami w terenie. Keras, pyTorch, TensorFlow, H2O, scikit-learn, Apache Spark – wybierz reputację, prawdopodobnie będziesz jej używać. Apache Kafka! Pulsar! AWS! Każda konferencja, w której uczestniczysz, mówi głośno o twoim stosie technologii, jakby to był Wybraniec. Ludzie sprawdzają cię zazdrośnie, wiedząc, że po prostu jesteś facetem, który używa wszystkich dobrych rzeczy.
To, co zawsze wygodnie pominąć, to niezaprzeczalny fakt, że te fajne rzeczy również nie są powszechnie używane. A kiedy technologia jest nowa, pozostaje ci tylko kiepska dokumentacja i mnóstwo wpisów na blogu. To, co widzisz na konferencjach i rozmowach technicznych, to po prostu szczęśliwe zielone ścieżki (podobne do tych z notebooków Jupyter, które dostajesz od zespołu DS). zdajesz sobie sprawę, że to nie tak działa oprogramowanie. Wielokrotnie, po godzinach debugowania wewnętrznych Apache Spark, kwestionowałem swoją chęć do kontynuowania kariery programistycznej w nauce maszynowej. Czy nie byłbym szczęśliwszy bez tego wszystkiego? Czy rozwój sieci był naprawdę tak nudny?
Oczekuje się, że zrozumiesz tony pojęć, zarówno w dziedzinie tworzenia oprogramowania jak i nauki o danych. co najważniejsze, ludzie chcą, abyś bardzo szybko realizował nową wiedzę. Tony uczę się biorąc czyjeś fragmenty, zmieniając je i łamiąc oraz widząc co się dzieje. A co jeśli nie ma żadnych fragmentów? Co jeśli stacktrakcja, którą dostajesz jest dość bezsensowna, a googlowanie nazwy wyjątku prowadzi tylko do kodu w GitHubie, rzucając nim?
Krzywa uczenia się i rozumienia jest w niektórych obszarach dość stroma, zwłaszcza gdy wiąże się z wdrażaniem pomysłów napisanych w białych gazetach. Tak fajne (a czasem egzotyczne) jak te, ich forma jest zazwyczaj dość naukowa i samo ich zrozumienie zajmuje Ci dłuższą chwilę. Następnie przychodzi część kodowania, gdzie jesteś całkowicie na własną rękę. chociaż Twoja aplikacja kompiluje się dobrze i nie rzuca Runtime Exceptions wszędzie tam, gdzie jest to często niejasny sposób, aby upewnić się, że Twoja implementacja rzeczywiście działa poprawnie. A kiedy tego nie robi, zastanawiasz się, czy Twój kod zawiera błąd, dane są przechylone, czy nawet cały pomysł nie ma zastosowania w Twoim przypadku użytkowania.