Architektura uczenia maszynowego wymaga projektowania modułowego. Wracam do tego ponownie, ponieważ cały system to nigdy tylko model. To przepływ danych, trening, dostarczanie predykcji, monitorowanie oraz klej łączący te elementy. Kiedy te części są mieszane w jeden blok, zmiany stają się wolne i kruche.
Widziałem ten sam schemat w wielu systemach ML, nawet gdy sam model ulega zmianie. Części, które starzeją się jako pierwsze, to zwykle te, którym nie nadano wyraźnych granic. Przygotowywanie danych zaczyna odbiegać od normy. Kod treningowy przejmuje reguły dostarczania. Monitorowanie jest doklejane później i wygląda na obce. System nadal działa, ale staje się trudny do zaufania.
Projektowanie modułowe rozwiązuje ten problem, dzieląc pracę na części z jasno określonymi zadaniami. Jeden moduł zajmuje się przyjmowaniem danych. Inny czyszczeniem lub przygotowaniem cech. Kolejny odpowiada za trening. Inny dostarcza predykcje. Ostatni pilnuje jakości i dryfu. Te części można wymieniać lub aktualizować bez przepisania całego stosu technologicznego. To jest prawdziwa wygrana. Nie chodzi tu o styl. Chodzi o kontrolę.
Ta kontrola ma znaczenie, ponieważ uczenie maszynowe zmienia się na więcej sposobów niż zwykłe oprogramowanie. Normalna usługa może się zmieniać głównie wtedy, gdy zmienia się kod. System ML może się zmienić, gdy zmienią się dane, gdy zmieni się rozkład etykiet lub gdy przesunie się źródło cech. Jeśli projekt jest modularny, zespół może wyśledzić, gdzie nastąpiła awaria. Jeśli nie, błąd chowa się w gąszczu.
Najlepsze systemy modularne używają też wyraźnych kontraktów. Kontrakt to prosta obietnica między modułami. Mówi ona, co wchodzi, co wychodzi i jaki kształt muszą mieć dane. Może to być schemat, interfejs API lub format wiadomości. Dbam o tę część, ponieważ luźne granice powodują ciche błędy. Ciche błędy to najgorszy rodzaj. Przechodzą przegląd i zawieszają się w produkcji.
Jest jeszcze inny powód, dla którego projektowanie modułowe pojawia się w obecnych pracach nad architekturą ML. Pomaga zespołom pracować równolegle. Praca nad danymi, nad modelem i nad wdrożeniem mogą odbywać się jednocześnie, gdy interfejsy są stabilne. To nie sprawia, że system jest idealny. Sprawia jedynie, że system może być budowany przez więcej niż jedną osobę naraz. W rzeczywistych projektach liczy się to bardziej niż pomysłowe diagramy.
Modularność pomaga też w ponownym wykorzystywaniu komponentów. Sklep z cechami (feature store), sklep wektorowy, potok treningowy czy warstwa dostarczania mogą często być użyte ponownie w nowym projekcie, jeśli zostały zbudowane z czystymi granicami. Oszczędza to czasu, ale tylko wtedy, gdy moduły zostały zaprojektowane pod kątem ponownego użycia od samego początku. Jeśli kod został napisany jako rozwiązanie jednorazowe, pozostanie rozwiązaniem jednorazowym, tylko podzielonym na więcej plików.
Myślę też, że projektowanie modułowe sprawia, że obsługa błędów staje się bardziej uczciwa. Gdy system jest podzielony na części, każda część może być mierzona osobno. Jakość danych można sprawdzić przed treningiem. Wyniki treningu można sprawdzić przed wdrożeniem. Dostarczanie można sprawdzić po wydaniu. Daje to zespołowi sposób na zadanie prostego pytania: czy zawiódł model, czy system wokół modelu? To przydatne pytanie, ponieważ odpowiedzią często nie jest model.
Istnieje jednak pewien limit. Projektowanie modułowe nie jest darmowe. Zbyt wiele modułów może stworzyć labirynt usług, kolejek i warstw magazynowych. Wtedy system staje się trudny do śledzenia w nowy sposób. Starym problemem był jeden wielki klocki. Nowym problemem jest zbyt wiele małych pudełek. Dlatego modularność musi pozostać powiązana z rzeczywistymi granicami w pracy, a nie z modnymi trendami architektonicznymi.
Dlatego nie traktuję projektowania modułowego jako hasła reklamowego. Traktuję je jako sposób na utrzymanie testowalności, zmienności i czytelności systemów uczenia maszynowego. Model to tylko jedna część maszyny. Architektura wokół niego decyduje o tym, czy praca pozostaje zarządzalna, gdy dane się zmieniają, a system rośnie.
Praktyczną odpowiedzią na pytanie dotyczące projektowania systemów uczenia maszynowego pdf jest proste: buduj system jako moduły z jasnymi rolami, jasnymi wejściami i jasnymi wyjściami. Utrzymuj stan tam, gdzie należy. Utrzymuj trening, dostarczanie i monitorowanie oddzielnie, kiedy tylko możesz. I zaakceptuj, że głównym ryzykiem nie jest tylko jakość modelu. To złożoność systemu.
O taki właśnie fakt stara się dbać The Model Log: jeden praktyczny koncept AI, jeden działający przykład i jeden szczery rzut oka na to, co naprawdę działa.
