PDF-y pokazują wzorce projektowania systemów ML. To jest czysta odpowiedź i to właśnie jej najbardziej ufałem, gdy ktoś pytał o projektowanie systemów uczenia maszynowego w formie dokumentów PDF.
W tych materiałach widzę ten sam kształt. Nie są to losowe przewodniki. Zbierają powtarzające się rozwiązania systemowe i nadają im nazwy. Niektóre koncentrują się na całym systemie. Inne skupiają się na jednym elemencie, takim jak trenowanie, obsługa (serving), monitorowanie czy wersjonowanie. Ma to znaczenie, ponieważ praca z ML pęka w szwach między tymi częściami.
Użyteczna część jest prosta. Dobry PDF na ten temat zwykle pomaga zobaczyć wzorce, a nie tylko wskazówki. Pokazuje, że produkcyjny ML składa się z powtarzalnych bloków: przepływu danych, przepływu modelu, ewaluacji i wdrożenia. Wykazuje również miejsca, w których zespoły popełniają te same błony raz po raz. Słowo „wzorzec” wykonuje tu realną pracę. Oznacza ono sprawdzony kształt do rozwiązywania powtarzalnego problemu, a nie magiczny trik.
Lubię takie ujęcie, ponieważ pasuje ono do tego, jak systemy ML zawodzą w praktyce. Model może wyglądać dobrze w notatniku, a mimo to zawieść w produkcji. Przerwa często nie dotyczy samego modelu. Dotyczy raczej przekazania (handoff) między danymi offline a ruchem na żywo, między kodem trenującym a kodem obsługującym, albo między jedną wersją modelu a kolejną. PDF-y oparte na wzorcach są użyteczne, ponieważ sprawiają, że te momenty przekazania stają się widoczne.
Jasnym przykładem jest wersjonowanie. W systemach ML wersjonowanie nie służy tylko do kodu. Objęte nim są również dane, cechy (features), modele, a czasem dokładna konfiguracja treningowa. Jeśli PDF dobrze pokazuje wzorce projektowania systemów ML, powinien wyjaśniać, że wersjonowanie jest częścią projektowania systemu, a nie zadaniem dodatkowym. Bez niego debugowanie zamienia się w zgadywanie. Dzięki niemu zespoły mogą śledzić, co się zmieniło i dlaczego.
Kolejnym użytecznym wzorcem jest oddzielenie trenowania od obsługi (serving). Trenowanie wymaga dużych zbiorów danych, zadań wsadowych i bardziej elastycznych mocy obliczeniowych. Obsługa wymaga niskich opóźnień, stabilnych interfejsów i ścisłej kontroli. PDF, który dobrze tego uczy, nie łączy tych zadań razem. Pokazuje, dlaczego ich mieszanie powoduje problemy. Jest to jedna z głównych lekcji, które należy wynieść z materiałów dotyczących „projektowania systemów uczenia maszynowego”.
Szukam również uczciwych ograniczeń. Katalog wzorców może sprawić, że systemy ML brzmią bardziej ustalone niż są w rzeczywistości. Niektóre wzorce są powszechnie stosowane. Inne zależą od wielkości zespołu, kształtu danych lub potrzeb produktu. Sklep z cechami (feature store) może być pomocny w jednym kontekście, a w innym dodać dodatkowe obciążenie. PDF, który traktuje każdy wzorzec jako regułę, jest mniej użyteczny niż taki, który mówi, gdzie dany wzorzec pasuje, a gdzie nie.
To ograniczenie ma teraz większe znaczenie, a nie mniejsze. Systemy ML ciągle się zmieniają, ponieważ zmieniają się narzędzia wokół nich. Nowe typy modeli, nowe style wdrażania i nowe przepływy danych tworzą świeże tryby awarii. Dlatego najlepsze PDF-y nie obiecują ostatecznej odpowiedzi. Dają mapę powszechnych kształtów wraz z kompromisami, które z nimi wiążą.
Gdy więc ktoś pyta o „PDF dotyczący projektowania systemów uczenia maszynowego”, uczciwą odpowiedzią jest to, że najlepsze z nich to przewodniki po wzorcach. Pomagają czytelnikowi myśleć o częściach systemu, a nie o hype’ie wokół modeli. Pokazują, jak trenowanie, obsługa, monitorowanie i wersjonowanie pasują do siebie. Wykazują też, że najtrudniejsze problemy to często nudne kwestie, takie jak granice, dzienniki zdarzeń i powtarzalność. Tam zazwyczaj wygrywa lub przegrywa prawdziwy ML.
Model Log dobrze wpisuje się w ten sam pomysł. Jeden praktyczny koncept AI, jeden działający przykład i jeden szczery spojrzenie na to, co naprawdę działa.
