Dobre praktyki w budowie skutecznej platformy MLOps - Cz. II

W pierwszej części tego artykułu porównaliśmy różne platformy pod względem kosztów, efektywności i jakości wdrożeń uczenia maszynowego na dużą skalę. Wyniki były jednoznaczne: platforma Algolytics osiąga porównywalną skuteczność predykcyjną co rozwiązania open-source czy chmurowe, ale robi to znacznie szybciej i taniej.

W tej oraz kolejnej części skupimy się na tym, dlaczego tak się dzieje – co stoi za taką wydajnością, jak wygląda nasza architektura i jakie rozwiązania techniczne bezpośrednio przekładają się na korzyści biznesowe.

Poruszymy też trudniej mierzalny aspekt – jak dobrze zaprojektowana platforma MLOps wspiera zespoły data science, niwelując luki kompetencyjne i skracając czas wdrożenia rozwiązań na rynek.

Standardowe wdrażanie modeli ML – co działa, a co zawodzi?

Kiedy mowa o wdrażaniu modeli uczenia maszynowego, wiele zespołów naturalnie sięga po popularne rozwiązania open-source, takie jak MLflow (lub platformy chmurowe), w połączeniu z Pythonem i konteneryzacją (Docker, Kubernetes). Na papierze taki model wygląda obiecująco, ale w praktyce ujawnia kilka istotnych ograniczeń, które mają znaczący wpływ na efektywność, koszty i skalowalność.

Przyjrzyjmy się teraz modelowi skalowania wykorzystywanemu w takim podejściu.

Przyjrzyjmy się teraz modelowi skalowania wykorzystywanemu w takim podejściu.

Ten model składa się z następujących elementów:

• Rejestracja modelu i stworzenie obrazu kontenera z jego środowiskiem uruchomieniowym
• Utworzony kontener zawiera interpreter Pythona oraz wszystkie wymagane zależności (pandas, numpy, sklearn, xgboost itd.)
• Każdy kontener działa jako osobny „worker”, obsługujący zapytania
• Ruch przychodzący jest zarządzany przez load balancer, który przekierowuje żądania do poszczególnych instancji

Jakie są główne problemy tego podejścia?

• Redundancja infrastruktury: Każdy kontener zawiera kopię tych samych bibliotek (często ważących gigabajty), uruchamia własny interpreter Pythona i działa w izolacji – nawet jeśli modele mogłyby współdzielić zasoby. Efekt? Marnowanie pamięci RAM i mocy obliczeniowej CPU, nawet przy prostych modelach.

• Niska równoległość przetwarzania (GIL): Python (w tym biblioteki takie jak scikit-learn, xgboost i inne) cierpi na ograniczenie związane z Global Interpreter Lock (GIL) – mechanizmem, który blokuje wielowątkowość na poziomie interpretera i ogranicza możliwość równoległego przetwarzania wielu zapytań w jednej instancji. W rezultacie zamiast efektywnie skalować pojedynczy proces, trzeba mnożyć liczbę kontenerów.

• Wysoki czas odpowiedzi: Każde zapytanie trafia najpierw do load balancera, potem przez sieć do kontenera, gdzie inicjalizowane jest środowisko Pythona i uruchamiany kod scoringowy, często przez wiele warstw abstrakcji. Taki model generuje znacznie wyższe opóźnienia niż podejście z dedykowanym, lekkim kodem.

• Wysokie wymagania kompetencyjne wobec zespołu wdrożeniowego: Załóżmy, że wdrożenie obejmuje nie jeden prosty model, jak na schemacie, ale złożony proces integracji danych, który trzeba zrównoleglić, oraz wiele modeli działających na różnych konfiguracjach Pythona. Takie rozwiązanie wymaga budowy wielu „mikrousług”, ich integracji, a także stworzenia mechanizmów odpowiedzialnych za skalowanie i niezawodność przetwarzania.

Dobre praktyki w budowie skutecznej platformy MLOps

Nasze doświadczenie pokazuje kilka dobrych praktyk, które stosujemy podczas tworzenia platformy ML/DS w Algolytics. Oto najważniejsze z nich:

Budowa modeli ML

• Wydajne przetwarzanie danych w procesie trenowania modeli
• Skuteczne, a jednocześnie matematycznie zwięzłe modele ML (ABM autoML z karą za złożoność obliczeniową)

Wdrażanie modeli ML

• Narzędzie wspierające inżynierów danych i data scientistów w operacjonalizacji modeli ML (low-code, wdrożenie „jednym kliknięciem”)
• Elastyczny silnik wykonawczy umożliwiający wdrażanie modeli, orkiestrację danych i powiązanie modeli z zestawami reguł
• Asynchroniczność, skalowalność oraz usługi narzędzi MLOps, które eliminują potrzebę implementowania tych mechanizmów w każdej instalacji.
• Open source – wykorzystanie popularnych technologii open source, szczególnie w zakresie wdrażania modeli ML

Przejdźmy teraz do omówienia najważniejszych praktyk, które stosujemy, aby zwiększyć skuteczność platformy MLOps od Algolytics.

Problem 1 – Duże zbiory danych wejściowych jako bariera przy trenowaniu modeli.

W świecie uczenia maszynowego często mówi się o mocy danych: „im więcej danych, tym lepsze modele”. Jednak w praktyce praca z dużymi zbiorami danych może stanowić barierę, szczególnie w tradycyjnych podejściach do budowy modeli.

Dlaczego?

W tradycyjnych środowiskach open-source, dane wejściowe muszą być wczytywane w całości do pamięci RAM. Przykład: Nawet stosunkowo prosty zbiór danych używany w naszym benchmarku:

• 9,3 miliona obserwacji,
• 405 zmiennych (cech),

Już samo utworzenie DataFrame’a dla takiego zbioru w popularnych frameworkach, takich jak Pandas, wymaga około 75 GB RAM.

I to dopiero początek. Przy przygotowywaniu danych do treningu modeli musimy:

• przeprowadzać transformacje (np. skalowanie, kodowanie),
• selekcjonować cechy,
• tworzyć nowe zmienne (feature engineering).

Te operacje mnożą zużycie pamięci, ponieważ każdy etap pośredni tworzy dodatkowe kopie danych.

Efekt? Aby przeprowadzić klasyczny proces trenowania na takich danych w środowiskach open-source lub chmurowych, trzeba przeznaczyć serwer z minimum 250 GB RAM.

Na platformach chmurowych możliwe jest skalowanie maszyn do dużych rozmiarów, ale jest to bardzo kosztowne. W przypadku rozwiązań on-prem problem ten staje się trudny do obejścia.

Jak rozwiązaliśmy ten problem w ABM od Algolytics?

Zamiast „na siłę” zwiększać pamięć maszyn, zdecydowaliśmy się podejść do tego inaczej.

Nasze kluczowe techniki:

• Operujemy głównie na statystykach i wybranych fragmentach danych (próbkach), dzięki czemu nie musimy przechowywać całego zbioru w pamięci operacyjnej.
• Próbkowanie danych przed pełnym treningiem. Zamiast przetwarzać cały zbiór naraz, najpierw redukujemy dane wejściowe, zachowując przy tym jakość predykcji.
• Microbatching podczas treningu. Dzielimy zbiór danych na małe porcje (batch’e) i trenujemy model iteracyjnie, zamiast trzymać wszystko w pamięci.
• Optymalizacja algorytmów ML. Algorytmy są projektowane w taki sposób, aby minimalizować operacje zużywające pamięć (np. unikanie niepotrzebnego kopiowania danych).

Efekt?

Dzięki tym rozwiązaniom: Modele, które normalnie wymagałyby maszyn z 250 GB RAM, trenowaliśmy na jednostkach z 16 GB RAM (np. D2s v4 na Azure).

Koszty infrastruktury spadły kilkukrotnie.

Uwaga na koszty trenowania modeli z użyciem AutoML

Kończąc temat trenowania modeli, warto również zwrócić uwagę na koszty budowy modeli. Załączona poniżej tabela pokazuje koszt budowy modelu omówionego w pierwszej części artykułu – prostego klasyfikatora stworzonego na stosunkowo małych danych. W tym przypadku zastosowaliśmy techniki autoML.

Jak widać, koszty różnią się zasadniczo. Niektóre platformy (Google, AWS) oferują dedykowane cenniki dla zadań związanych z trenowaniem modeli, podczas gdy w innych ponosimy jedynie koszty infrastruktury.

Dlaczego to ważne? W przypadkach, gdy nasz proces zakłada częste aktualizowanie modeli lub mamy wiele modeli do wytrenowania, koszty mogą stanowić znaczną przeszkodę, a wybór odpowiedniej platformy (np. moduł ABM Algolytics) może okazać się kluczowy.

Problem 2 – AutoML działa skutecznie, ale generuje obliczeniowo złożone modele

Wiele zespołów data science, chcąc przyspieszyć proces tworzenia modeli, sięga po narzędzia AutoML, które automatyzują wybór cech, dobór algorytmu, dostrajanie hiperparametrow i budowanie komitetów/ensembli.

I rzeczywiście – AutoML często zapewnia bardzo dobre wyniki predykcyjne. Ale czy to wystarczy? W praktyce okazuje się, że niekoniecznie.

W klasycznym podejściu AutoML (np. AutoGluon, H2O AutoML, Google Vertex AI AutoML, GridSearchCV ze scikit-learn + AutoSklearn):

• generowane są setki lub tysiące wariantów modeli,
• wybierane są te z najwyższymi wynikami predykcyjnymi,
• często tworzony jest ensemble (np. stack kilkudziesięciu modeli).

Takie podejście „na siłę” ignoruje złożoność obliczeniową finalnego modelu. Preferuje rozbudowane architektury i nie uwzględnia kosztów operacyjnych ich utrzymania – takich jak zużycie pamięci RAM, obciążenie CPU czy opóźnienia w inferencji.

Efekt? Modele są skuteczne, ale trudno je wdrożyć produkcyjnie.

Konsekwencje stosowania zbyt złożonych modeli AutoML są liczne:

• Długi czas odpowiedzi (inference) – każde zapytanie scoringowe trwa dłużej → rosną opóźnienia.
• Wysokie zużycie RAM-u – konieczność ładowania wielu modeli naraz lub wykonywania złożonych obliczeń na dużych macierzach.
• Wzrost kosztów infrastruktury – potrzeba mocniejszych maszyn (więcej CPU, więcej RAM).
• Problemy ze skalowaniem systemu scoringowego – obsługa wysokiego wolumenu zapytań (np. >100 na sekundę) staje się trudna.
• Większe ryzyko błędów i trudności w utrzymaniu – ensemble z wielu modeli zwiększa ryzyko konfliktów wersji bibliotek, błędów przy aktualizacjach i złożoności kodu.

Jak Algolytics Technologies rozwiązuje ten problem?

W Algolytics AutoML działa inaczej. Nasze algorytmy wykorzystują heurystyki, które karają złożoność obliczeniową podczas treningu – jeśli dwa modele osiągają zbliżoną skuteczność, wybieramy ten prostszy, który zużywa mniej zasobów.

Przykład:

Jeśli ensemble 50 drzew daje 85% skuteczności, a pojedyncza regresja logistyczna osiąga 84% – wybieramy regresję logistyczną.

Optymalizacja już na etapie transformacji danych – zamiast zwiększać skuteczność przez złożone modele, stosujemy:

• sprytne transformacje zmiennych (np. kategoryzacja, binning, WoE),
• automatyczne tworzenie cech (feature engineering – np. interakcje zmiennych),
• redukcję wymiarowości (np. PCA, selekcję cech).

Proste algorytmy działają bardzo dobrze, jeśli dane są odpowiednio przygotowane. Modele matematycznie proste – np. modele liniowe – często wystarczą. Przy dobrze „opracowanych” danych potrafią osiągać niemal identyczną skuteczność predykcyjną jak złożone ensemble’e.

W Algolytics Technologies skuteczność predykcyjna to nie wszystko. Równie ważna jest dla nas prostota, efektywność i optymalizacja modeli – już na etapie AutoML.

Efekt? Nasze wdrożenia są:

• tańsze,
• szybsze,
• lepiej się skalują,
• i łatwiej je utrzymać – nawet w bardzo dużych środowiskach.

Problem 3 – Obliczeniowo i pamięciowo efektywny kod scoringowy

W środowiskach produkcyjnych wydajność obliczeniowa zależy nie tylko od matematycznej prostoty modelu, ale też od sposobu jego implementacji. Nawet prosty model, jeśli zostanie zaimplementowany nieefektywnie, może generować wysokie koszty utrzymania.

W popularnym podejściu modele są trenowane w Pythonie, scoring opiera się na bibliotekach takich jak scikit-learn, xgboost, pandas czy numpy, a kod scoringowy jest interpretowany w czasie rzeczywistym (np. w ramach MLFlow, Flask, FastAPI).

W praktyce oznacza to, że przy każdym zapytaniu scoringowym ładowane są ciężkie obiekty (np. modele, struktury danych), wykonywane są operacje matematyczne z narzutem wysokopoziomowych bibliotek, a interpreter Pythona oraz struktury typu Pandas DataFrame zużywają niepotrzebnie RAM i CPU.

W Algolytics skupiliśmy się na tym, aby kod scoringowy był maksymalnie uproszczony i szybki. Jak to robimy?

Zauważmy, że scoring dowolnego modelu ML można sprowadzić do sekwencji podstawowych operacji matematycznych – dodawania, mnożenia, użycia funkcji typu logarytm, pierwiastek. Do uruchomienia modelu nie potrzebujemy więc ani rozbudowanego kodu, ani ciężkich bibliotek.

Zamiast tego generujemy kod scoringowy na możliwie najniższym poziomie:

• Zamiast uruchamiać modele przez biblioteki ML, ekstraktujemy model do czystego kodu bazującego wyłącznie na podstawowych konstrukcjach języka (np. Java, C, C++) lub stosujemy standardowe formaty scoringowe, takie jak PMML czy ONNX.
• Kod scoringowy nie ma żadnych zależności od ciężkich bibliotek. Scoring działa bez użycia Pandas, Numpy, scikit-learn – to po prostu zestaw funkcji matematycznych i prostych operacji na liczbach.
• Kod jest kompilowany zamiast interpretowany. Przykładowo: scoring w Javie kompilujemy do bytecode’u JVM – działa szybciej i efektywniej niż serwery aplikacyjne oparte na Pythonie.
• Optymalizujemy struktury danych. Wszystkie operacje (wyliczanie zmiennych wejściowych, scoring, transformacje) są zoptymalizowane pod kątem zużycia pamięci i procesora.

W praktyce daje to:

• Czas odpowiedzi: kilkakrotnie krótszy niż w standardowych podejściach.
• Zużycie RAM-u: minimalne — wczytywane są tylko niezbędne dane i struktury.
• Wysoka przepustowość: systemy mogą obsługiwać setki zapytań na sekundę na jednej maszynie.

Problem 4 – Wdrożenie modeli ML to wyzwanie

Wytrenowanie modelu to dopiero początek. Prawdziwe wyzwanie pojawia się, gdy model trzeba wdrożyć, zintegrować i utrzymywać w środowisku produkcyjnym.

Teoretycznie proces operationalizacji powinien wyglądać prosto:
Trenuj model ➔ Wystaw jako API ➔ Wdróż ➔ Monitoruj.

W praktyce, jak omawialiśmy w pierwszej części artykułu, wdrożenie rozwiązania opartego na ML to znacznie bardziej skomplikowane zadanie.

Gdzie pojawiają się problemy i gdzie generują się ukryte koszty?

Jednym z największych wyzwań — szczególnie gdy obciążenie inferencją jest niewielkie, ale procesy są złożone — jest niedobór kompetencji zespołu i wysokie koszty implementacji.

Główne wąskie gardła:

• Zarządzanie cyklem życia modelu: Modele muszą być przechowywane, wersjonowane i opisane metadanymi. Jeśli są tworzone w różnych frameworkach, trzeba zarządzać rozproszoną infrastrukturą. Przy dużej liczbie modeli (np. w systemach rekomendacyjnych) skala zarządzania staje się bardzo trudna.
• Implementacja kodu scoringowego: Modele muszą być zaimplementowane w sposób kompatybilny z systemem produkcyjnym (np. MLFlow PythonModel, niestandardowe API). Często wymaga to ręcznego pisania dedykowanych klas, wrapperów lub skryptów.
• Ręczna orkiestracja modeli i procesów: W bardziej złożonych implementacjach (np. rekomendator oparty na 100 modelach omówiony w pierwszej części artykułu) konieczne jest stworzenie oddzielnych procesów dla każdego modelu. Trzeba także uwzględnić integrację danych, transformacje zmiennych i reguły decyzyjne — wszystko ręcznie.
• Wysokie koszty zmian: Każda zmiana (np. nowa wersja modelu, zmiana źródła danych) wiąże się z koniecznością koordynacji wielu komponentów. W środowiskach open-source (np. MLFlow) często wymaga to manualnej pracy i zarządzania cyklem życia modelu.

Jak Algolytics rozwiązuje ten problem?

Nasza platforma Scoring.one została zaprojektowana z myślą o usunięciu tych barier. Kluczowe funkcje to:

• Wdrażanie modeli jednym kliknięciem: Modele mogą być automatycznie wdrażane z różnych środowisk (Python, R, PMML, Algolytics) bez konieczności ręcznej edycji kodu.
• Budowa procesów scoringowych w trybie low-code i modularnym: Procesy scoringowe są budowane za pomocą gotowych bloków — transformacji danych, scoringu modeli, reguł decyzyjnych, integracji API. Bloki te można łatwo łączyć w schematy, które automatycznie generują środowisko produkcyjne.
• Orkiestracja modeli i danych w jednolitym środowisku: Nasza architektura oparta na zdarzeniach umożliwia równoczesne uruchamianie wielu modeli i operacji. Wszystkie transformacje danych, reguły biznesowe i logika scoringowa działają w jednym, spójnym ekosystemie.
• Elastyczność i skalowalność: Procesy mogą być realizowane jako małe, wielokrotnie używane komponenty (scenariusze) lub w formie monolitycznej, w zależności od potrzeb. Platforma obsługuje także integrację z systemami zewnętrznymi, takimi jak REST API, bazy danych i kolejki wiadomości.

---

Aby zobrazować różnicę, wróćmy do przykładu systemu rekomendacyjnego z pierwszej części artykułu. Najpierw z użyciem MLFlow, a potem z wykorzystaniem Scoring.one.

MLFlow — jedno z najpopularniejszych narzędzi do zarządzania cyklem życia modeli ML — umożliwia:

• zarządzanie wersjami modeli,
• wersjonowanie,
• i wdrażanie przez REST API.

W wielu organizacjach MLFlow stał się domyślnym rozwiązaniem do wdrażania modeli w produkcji.

W naszym przypadku pierwszy krok to zbudowanie i zarejestrowanie 100 modeli (klasyfikatorów). Ten krok jest stosunkowo prosty, ponieważ MLFlow oferuje wygodne API do rejestracji wytrenowanych modeli.

Jednak w kolejnym etapie implementacji nie możemy już korzystać ani z automatyzacji procesów, ani z podejścia low-code — wszystkie etapy związane z pobieraniem danych wejściowych, zapytaniami do API i baz danych, czy inżynierią cech muszą zostać zaimplementowane ręcznie. Podobnie sposób pobierania modeli z repozytorium, ich równoległe uruchamianie oraz budowa struktury wynikowej wymagają osobnego zakodowania. To wszystko oznacza dodatkowe kompetencje i czas.

Problemem staje się również użycie modeli zbudowanych w różnych frameworkach w tym środowisku — w ekstremalnych przypadkach wymaga to wdrożenia 100 niezależnych mikroserwisów, z których każdy potrzebuje własnego środowiska uruchomieniowego.

W Algolytics Technologies staramy się maksymalnie uprościć i skrócić czas wdrażania rozwiązań opartych na ML, tak aby zespół Data Science mógł szybko i efektywnie implementować nawet złożone rozwiązania w podejściu low-code — koncentrując się wyłącznie na logice biznesowej, a nie aspektach technicznych.

Poniższy diagram przedstawia wszystkie kluczowe komponenty, z których zbudowane jest finalne rozwiązanie. Składa się ono z zestawu węzłów, które w wygodny sposób łączy się w wizualny proces. Znajdują się wśród nich definicje danych wejściowych i wyjściowych (bez narzuconej struktury), węzły integrujące z zewnętrznymi źródłami danych, elementy do przetwarzania danych (np. skrypty), podłączenia do modeli scoringowych/AI oraz kontrolki zarządzające przepływem przetwarzania. W naszym przykładzie zastosowano węzeł multitask, który umożliwia równoległe uruchomienie obliczeń przy użyciu 100 modeli scoringowych.

Jak widać, narzędzie znacząco upraszcza i przyspiesza wdrażanie aplikacji o złożonej logice.

Modele scoringowe są rejestrowane w narzędziu Scoring.one przy użyciu podejścia „one-click deployment”, dostępnego na poziomie węzłów Scoring Code lub Multitask.

Podsumowanie

W tej części opisaliśmy dobre praktyki, które pozwalają osiągać znacznie lepsze rezultaty (kosztowo, skalowalnościowo, użytkowo) niż inne platformy z tej samej kategorii.

W kolejnym odcinku skupimy się na wewnętrznej architekturze Scoring.one. Sam scenariusz – czyli proces widoczny w interfejsie aplikacji – upraszcza tworzenie rozwiązań i eliminuje luki kompetencyjne, ale równie istotne jest to, w jaki sposób taki scenariusz jest przekształcany w skalowalną aplikację. Temat ten rozwiniemy w następnej części artykułu.