Planowanie projektów ML – różni się od planowania typowych projektów z zakresu inżynierii oprogramowania. Projekty ML mają charakter nieliniowy i różnią się stopień niepewności. Potrzebne jest tu podejście iteracyjne i eksperymentalne podejście.
Niepewność projektu
Planowanie na wczesnym etapie może być trudne, ponieważ na początku projektu nie wiadomo zwykle, jaki wybrać najlepsze rozwiązanie. Ta nieodłączna niepewność sprawia, że szacowanie osi czasu jest trudne.
Niedawny konkurs Kaggle pokazuje niepewność projektów ML. W pierwszych kilku tygodniach konkursów wzięło w nim 350 drużyn. Niektórym zespołom udało się zwiększyć jakość prognozy porównawczej z 35% do 65%. W ciągu następnych dwóch tygodni liczba zespołów zajmujących się tym problemem zwiększyła się z 350 do 1400. Najlepszy model osiągnął jednak jakość prognozy tylko na poziomie 68%.
Rysunek 3 ilustruje niepewność w zakresie rozwoju systemów uczących się, pokazując znaczny wzrost nakładu pracy, ale tylko minimalny wzrost jakości modelu.
Rysunek 3. W ciągu 2 tygodni liczba zespołów pracujących nad tym problemem zwiększyła się czterokrotnie, ale jakość modelu pozostała niemal taka sama, co podkreśla trudności z oszacowaniem wysiłków, jakie stwarza rozwiązanie ML.
Oznacza to, że ponad 1000 zespołów eksperymentujących z różnymi przekształceniami danych, architekturami i hiperparametrami udało się uzyskać model o jakości prognoz na poziomie 68%.
Przykład z branży pokazuje nieliniowość projektów ML, w których dane wyjściowe nie są proporcjonalne do danych wejściowych. 2 zespoły zajęły kilka miesięcy, aby wytrenować model tak, aby jego jakość wynosiła 90%. Przygotowanie modelu do wdrożenia modelu z wysoką jakością prognoz na poziomie 99, 9% zajęło kilku zespołom ponad 5 lat.
Przykłady te wskazują, że systemy uczące się gotowe do wykorzystania w produkcji to proces badawczy, który wymaga zarówno myślenia naukowego, jak i inżynieryjnego.
Podejście eksperymentalne
W większości przypadków tworzenie systemów uczących się przypomina wykonywanie eksperymentów niż ćwiczenie tradycyjnej inżynierii oprogramowania. Systemy uczące się wymagają testowania różnych funkcji, wypróbowywania różnych architektur i odpowiedniego dostrajania hiperparametrów. Z definicji nie ma gwarancji, że eksperymenty się sprawdzą. Z tego powodu najlepiej zaplanować użycie struktury eksperymentalnej.
Przyjrzyjmy się typowemu planowi z zakresu inżynierii oprogramowania. Czym różni się on od planu projektu ML.
Planowanie projektów inżynierii oprogramowania
W typowym planie inżynierii oprogramowania definiuje się wymagania, omawia się komponenty, szacuje nakład pracy i ustala harmonogram prac. Istnieje jasno określona ścieżka do rozwiązania. Na przykład inżynierowie często z dużą pewnością wiedzą, jakie zadania muszą wykonać, aby stworzyć aplikację zgodną ze specyfikacjami projektowymi.
Gdy przewidują czas potrzebny na wykonanie zadania, mogą oszacować go na podstawie podobnych projektów. Chociaż wyzwania nieodmiennie występują – takie jak nieznane zależności lub zmieniające się wymagania – i mogą czasem utrudniać szacowanie, zazwyczaj istnieje jasna ścieżka do rozwiązania.
W przeciwieństwie do projektów ML zwykle nie ma jednej jasnej ścieżki do sukcesu.
Projekty ML Planning
W przypadku większości projektów ML aby znaleźć najlepsze rozwiązanie, warto poeksperymentować z wieloma podejściami w ramach prób i błędów. Zazwyczaj nie można znaleźć optymalnego rozwiązania przed podjęciem próby jego rozwiązania. Na przykład architekturą optymalnego rozwiązania może być prosty model liniowy, sieć neuronowa lub drzewo decyzyjne. Aby odkryć najlepsze rozwiązanie, wystarczy wypróbować każdą z nich.
Ta niejasność utrudnia planowanie. Jak już wspomnieliśmy, przewidywanie działań, jakie będzie wymagał projekt ML, jest trudne. Tylko próba rozwiązania problemu może dać Ci lepsze pojęcie o ilości czasu i zasobów, których może potrzebować.
Oto zalecane strategie planowania pracy systemów uczących się:
Podział czasu na pracę. Określ jasno czas realizacji zadań lub wypróbuj określone rozwiązanie. Możesz np. przeznaczyć 2 tygodnie, aby sprawdzić, czy masz dostęp do właściwych danych. Jeśli możesz uzyskać te dane, możesz przeznaczyć kolejne 2 tygodnie, aby sprawdzić, czy prosty model wskazuje, że rozwiązanie ML jest możliwe. Jeśli prosty model zawiedzie, możesz wyznaczyć jeszcze 2 tygodnie na wypróbowanie sieci neuronowej. Pod koniec każdego okresu otrzymasz więcej informacji, które pozwolą Ci ustalić, czy kontynuowanie wykorzystywania zasobów do rozwiązania problemu jest korzystne.
Ogranicz wymagania projektu. Jeśli rozwiązanie ML wydaje się obiecujące, ale nie jest kluczowym elementem w przypadku Twojego produktu lub usługi, ogranicz jego wymagania. Na przykład, planując pracę na kolejny kwartał, możesz wypróbować bardzo proste rozwiązanie. W kolejnych kwartałach możesz planować iteracyjne ulepszenie rozwiązania. Wiele zespołów osiągnęło efektywne rozwiązania ML przez wdrożenie rozwiązania ML przez stopniowe wprowadzanie ulepszeń w dłuższym okresie.
Projekt stażysty lub Nooglera. Kierowanie stażystą lub Nooglerem w celu wypróbowania rozwiązania ML może być dobrym sposobem na rozpoczęcie badania nowej przestrzeni z nieznanymi wynikami. Po zakończeniu projektu zorientujesz się, ile pracy będzie wymagać rozwiązanie ML, oraz co za tym idzie, i stwierdzisz, że zasoby powinny zostać przeniesione gdzie indziej.
W przypadku każdej strategii rozsądnie jest szybko ponieść porażkę. W pierwszej kolejności wybieraj metody o najniższych kosztach, ale potencjalnie najbardziej opłacalne. Jeśli podejście się sprawdza, znajduje dobre rozwiązanie. Jeśli tak nie jest, nie marnujesz dużo czasu i zasobów.
W miarę zdobywania doświadczenia i ekspozycji w eksperymentach zespoły mogą lepiej oszacować nakład pracy potrzebny do przeprowadzenia eksperymentu, co sprawi, że planowanie będzie bardziej przewidywalne. Wynik eksperymentu będzie jednak prawie zawsze nieznany, dlatego nie można z wyprzedzeniem oszacować liczby eksperymentów potrzebnych do znalezienia najlepszego rozwiązania.
Eksperymentalne podejście do planowania pomaga przygotować zespół na sukces. Gdy konkretne podejście prowadzi do ślepych zaułków, a nie do zniechęcania, członkowie zespołu rozumieją, że jest to część procesu szukania rozwiązania ML. Co ważniejsze, rozmawiając z innymi zainteresowanymi osobami o niepewnościach związanych z rozwojem systemów uczących się, możesz określać bardziej realistyczne oczekiwania.
Pamiętaj
Nauka planowania różnych metod ML wymaga prawdopodobnie czasu i doświadczenia. Twój plan projektu może wymagać częstych aktualizacji. Potraktuj go jako dynamiczny dokument, który stale się rozwija, gdy Twój zespół eksperymentuje z różnymi podejściami. Skupiając się na następujących kluczowych koncepcjach, zwiększysz swoje szanse na sukces:
- Oszacuj koszt i szansę sukcesu każdego podejścia.
- Testuj różne podejścia.
- Wyciągaj wnioski i spróbuj ulepszyć system krok po kroku.
- Przygotuj się na awarie.
Czasem wczesna faza prowadzi do przełomu. Ktoś może wykryć błąd w potoku generowania danych lub w podziale na trenowanie i weryfikację. Odpowiedni plan i szczegółowa dokumentacja zwiększają prawdopodobieństwo znalezienia modelu, który rozwiąże Twój problem szybciej niż się spodziewasz.