Tworząc, wdrażając i udoskonalając usługi ML, jesteśmy zmuszeni borykać się z większą złożonością niż w przypadku tradycyjnego oprogramowania jak aplikacje internetowe czy mobilne, bowiem na końcowy produkt wpływają już nie tylko kod, ale również dane i model. Więcej pisałem o tym tutaj. Dziś przyjrzymy się, jakie ma to konsekwencje dla ciągłego dostarczania.
Zacznijmy od początku: czym jest ciągłe dostarczanie (continuous delivery)? To podejście w wytwarzaniu oprogramowania, w którym wdrożenie nowej wersji jest decyzją biznesową. To znaczy, że każdy commit jest kandydatem do wdrożenia. Nawet jeśli nie decydujemy się na kolejny wjazd na produkcję, to nie wynika to z ograniczeń technicznych.
Czym jest CD4ML?
To termin ukuty przez szajkę z ThoughtWorks, określający podejście do inżynierii oprogramowania, w którym interdyscyplinarny zespół produkuje aplikacje uczenia maszynowego oparte na kodzie, danych i modelach w małych i bezpiecznych przyrostach, które mogą być odtworzone i niezawodnie wydane w dowolnym momencie, w krótkich cyklach adaptacyjnych.
Większość tej definicji opisuje każdy rodzaj oprogramowania.
Małe przyrosty
To po prostu bezpieczeństwo. Każdy, kto mergował ośmiotysięczniki, to rozumie.
Krótkie cykle adaptacyjne
To podejście ewolucyjne, w którym pętla zwrotna jest Twoim najlepszym przyjacielem w zrozumieniu realnych potrzeb konsumentów. Im krótszy cykl (rzędu dni lub tygodni), tym lepiej. Pełna automatyzacja jest kluczem do tego sukcesu. Co więcej, w projektach ML dochodzi problem starzenia się modeli. W domenach, w których decyzje trzeba podejmować na podstawie regularnie zmieniającego się otoczenia (np. active trading), miesięczny model będzie przedawnionym gratem.
Nawet dla mniej dynamicznych domen częste wyciąganie wniosków z zachowania modeli na produkcji będzie główną siłą napędową udoskonaleń. Szczególnie jest to istotne dla systemów rekomendacyjnych, których nie sposób w pełni ewaluować na zbiorze testowym.
Interdyscyplinarne zespoły
Rozwiązania ML zaczynają się od inżynierii danych, przechodzą przez eksplorację danych i samo modelowanie, aby następnie je wdrożyć. Zwykle potrzeba zbyt wielu kompetencji i narzędzi, by osoby o podobnych umiejętnościach mogły dowozić takie rozwiązania. Potrzebni są zawodnicy, często z wąskimi specjalizacjami, którzy grają do jednej bramki. W przeciwnym wypadku mamy do czynienia z przerzucaniem się danymi, modelami, procesami i odpowiedzialnością pomiędzy zespołami.
Powtarzalne i niezawodne wydanie oprogramowania
Model jest pochodną danych i kodu, więc aby móc stworzyć dwa razy taki sam model, musimy wersjonować obie jego składowe.
Co jeszcze jest istotne dla CD4ML?
Mamy jeszcze dodatkowe wymagania. Żeby trenować modele w zautomatyzowanych potokach, musimy dostarczyć elastyczną infrastrukturę obliczeniową. Część gatunków potrzebuje GPU, inne są CPU bound, a jeszcze inne memory bound.
Zautomatyzowane trenowanie wiąże się również przechowywaniem metryk do oceny i porównywania modeli. Trzeba sprawdzić, czy nowy model jest lepszy od poprzedniego.
Źródła
- https://martinfowler.com/articles/cd4ml.html
- https://uczymymaszyny.pl/od-danych-do-produktu-automatyzacja-w-obszarze-machine-learning-dzieki-mlops/
Udostępnij ten wpis
Dobrnąłeś do końca. Jeśli ten artykuł był dla Ciebie wartościowy i chcesz otrzymywać informacje o kolejnych, to zapraszam Cię do zapisania się do listy mailingowej. Gwarantuję zero spamu.
Radek.
Inne artykuły
