PDF-y dotyczące architektury maszynowego uczenia (ML) w modelu open source mogą kierować projektowaniem systemów, ale tylko wtedy, gdy traktuje się je jako mapy projektowe, a nie jako magiczne odpowiedzi. Pomagają one, pokazując kształt rzeczywistego systemu ML: przepływ danych, trening, udostępnianie modeli, monitorowanie oraz powiązania między tymi elementami.
Ciągle wracam do prostego punktu. Większość problemów z uczeniem maszynowym nie jest rozwiązywana wyłącznie przez model. Najtrudniejszą częścią jest system wokół niego. Dlatego dokumenty architektoniczne mają znaczenie. Sprawdzają ukryte elementy widocznymi.
Dobry PDF dotyczący projektowania systemów ML zazwyczaj przedstawia te same kluczowe komponenty. Wyjaśnia, gdzie dane wpadają do systemu, jak są czyszczone, jak tworzone są cechy (features), jak odbywa się trening i jak model jest wdrażany oraz obserwowany. Niektóre przewodniki open source precyzują również interfejsy między częściami, zużycie zasobów oraz śledzalność między wymaganiami a konfiguracją ML. Jest to przydatne, ponieważ model działający w notatniku może nadal zawodzić w systemie, jeśli ścieżka danych jest słaba lub warstwa udostępniania (serving) jest niedbała.
Tutaj pomaga open source. PDF-y i książki open source często pokazują pełne układy, zamiast wypolerowanych slajdów marketingowych. Skłonne są do nazywania części prostym językiem. Niektóre koncentrują się na konfiguracji projektu, potokach danych, modelowaniu i udostępnianiu. Inne pokazują referencyjną architekturę dla MLOps, z takimi elementami jak serwer śledzenia, magazyn danych i przepływ wdrożeń. Tego rodzaju szczegóły dają inżynierom bazę, którą mogą dostosować. Nie dają im gotowego produktu.
Myślę, że to właściwy sposób odczytywania tych PDF-ów. Nie są tam po to, aby podejmować za Ciebie każdą decyzję projektową. Są tam po to, by uchronić Cię przed pominięciem całej klasy problemów. Jeśli przewodnik pokazuje trening, ale nie monitorowanie, to jest to wskazówka. Jeśli pokazuje wdrożenie, ale nie wersjonowane dane, to kolejna wskazówka. Wartość polega na zobaczeniu, czego wymaga kompletny system, a nie na kopiowaniu diagramu linia po linii.
Jest tu jedna szczera granica. PDF-y architektury ML open source mogą kierować projektowaniem systemów, ale starzeją się szybko. Nazwy narzędzi się zmieniają. Elementy chmurowe ulegają zmianom. Niektóre artykuły i przewodniki opisują szerokie wzorce, które pozostają użyteczne. Inne są powiązane ze stosem technologicznym, który może nie pasować do Twojego przypadku. Dlatego prawdziwą umiejętnością nie jest zapamiętywanie diagramu. To umiejętność czytania diagramu i oddzielania stabilnych idei systemowych od bieżącej listy narzędzi.
Trzymam też w pamięci małe ostrzeżenie. PDF to snapshot (migawka). Nie może pokazać pełnego kosztu pracy nad jakością danych, przypadków brzegowych w produkcji ani bałaganu wynikającego ze zmieniających się wymagań. Może na nie wskazać. Nie może ich jednak sfinansować czy rozliczyć. To wciąż zadanie inżyniera.
Więc krótka odpowiedź brzmi następująco: PDF-y architektury ML open source kierują projektowaniem systemów, pokazując pełną ścieżkę od danych, przez model, aż do usługi. Pomagają inżynierom myśleć w kategoriach systemów, a nie izolowanych przebiegów treningu. Te najlepsze są jasne co do interfejsów, przepływu i ograniczeń. Te słabsze zatrzymują się na ładnych polach i pomijają trudne części.
Oto rodzaj praktycznej prawdy, którą stara się utrzymać The Model Log: jeden praktyczny koncept AI, jeden działający przykład i jeden szczery ogląd tego, co naprawdę działa.
