ML Atlas

10 · Praktyka · 3 min czytania · aktualizacja

Jak wdrożyć model uczenia maszynowego na produkcję?

W skrócie

Wdrożenie to przeniesienie modelu z notebooka do systemu, który podejmuje decyzje: zapis z przetwarzaniem, API lub wsad, walidacja wejścia, wersje i monitoring.

Co to jest

Wdrożenie modelu (model deployment) to udostępnienie wytrenowanego modelu systemom lub ludziom, którzy na podstawie jego predykcji podejmują decyzje. Najczęstsze formy to predykcja wsadowa (np. co noc dla wszystkich klientów, wynik zapisany w bazie), usługa online (API zwracające predykcję w milisekundach) oraz model osadzony w aplikacji lub urządzeniu.

W notebooku model jest skończony, gdy ma dobry wynik walidacji. W produkcji dopiero wtedy zaczyna się praca: model musi dostawać dane przygotowane identycznie jak przy uczeniu, mieć wersję, dać się wycofać, mieścić się w budżecie czasu i pamięci oraz być obserwowany.

Mechanizm — dlaczego tak działa

Najgroźniejszy błąd wdrożenia ma nazwę: rozbieżność między uczeniem a serwowaniem (training–serving skew). Model nauczył się zależności dla danych w konkretnej postaci — jednostkach, kodowaniu kategorii, sposobie oznaczania braków. Jeśli kod produkcyjny przygotowuje dane choć trochę inaczej, model dostaje wejście spoza swojego świata i nadal zwraca liczby. Nie ma wyjątku ani ostrzeżenia, są tylko gorsze decyzje.

Dlatego w produkcji wdraża się cały pipeline, a nie sam model. Zapisany obiekt zawiera imputery, enkodery i skalery dopasowane przy uczeniu, więc przetwarzanie nie jest pisane drugi raz w innym języku przez inny zespół. Druga linia obrony to walidacja wejścia: schemat z typami, zakresami i dozwolonymi kategoriami, sprawdzany przed predykcją. Wartość spoza schematu powinna być logowana lub odrzucana, a nie po cichu zamieniana na zero.

Trzeci element to wersjonowanie i bezpieczne wypuszczanie. Każda predykcja powinna dać się powiązać z wersją modelu, danych uczących i kodu. Nowy model wchodzi stopniowo: najpierw w trybie cienia (liczy predykcje, ale nikt ich nie używa), potem dla części ruchu, z łatwym powrotem do poprzedniej wersji. Porównanie offline nie gwarantuje zachowania online, bo dane produkcyjne bywają inne niż historyczne.

Wreszcie koszt i opóźnienie. Model, który jest o 0,5 punktu lepszy, ale potrzebuje dziesięć razy więcej czasu na predykcję, może być gorszym wyborem. W systemach online liczy się czas odpowiedzi przy pojedynczym zapytaniu, nie przepustowość na dużych paczkach.

Na przykładzie

Pipeline Titanica (imputacja, one-hot, regresja logistyczna) nauczony na 75% pasażerów ma 78,9% dokładności na odłożonych 223 osobach. Zapisany przez joblib zajmuje około 4,6 KB i po wczytaniu daje identyczne prawdopodobieństwa. Pojedyncza predykcja trwa około 2 ms na zwykłym komputerze.

Teraz symulacja rozbieżności. Gdy system produkcyjny przysyła płeć jako „M”/„F” zamiast „male”/„female”, enkoder z handle_unknown='ignore' koduje ją jako same zera — bez błędu. Dokładność spada do 66,8%, a odsetek przewidywanych ocalałych wynosi 35,9% zamiast 30,9%, więc na wykresie średniej predykcji wszystko wygląda niewinnie. Gdy opłata przychodzi w pensach zamiast w funtach, dokładność spada do 47,1% — gorzej niż rzut monetą — a model ogłasza ocalenie 89,7% pasażerów.

Dane: Titanic

W praktyce

  • Zapisuj cały pipeline: joblib.dump(pipe, 'model-v3.joblib'); w PyTorch torch.save(model.state_dict(), ...) plus kod przetwarzania w tej samej wersji. Format wymienny: ONNX.
  • Zamroź środowisko (wersje bibliotek, kontener): plik joblib wczytany w innej wersji scikit-learn może nie działać lub działać inaczej.
  • Waliduj wejście schematem (np. pydantic, pandera): typy, zakresy, dozwolone kategorie; loguj każdą nieznaną wartość.
  • Usługa online: lekki serwer HTTP (np. FastAPI) ładujący model raz przy starcie; wsad: zadanie cykliczne zapisujące wyniki do bazy.
  • Wypuszczaj stopniowo: tryb cienia, część ruchu, szybki powrót do poprzedniej wersji.
  • Typowy błąd: przepisanie przetwarzania od zera w kodzie produkcyjnym zamiast użycia tego samego pipeline'u.

Najczęstsze pytania

Predykcja wsadowa czy online?
Wsadowa jest prostsza i tańsza, wystarcza, gdy decyzje nie muszą zapadać natychmiast (scoring klientów raz dziennie). Online jest potrzebna, gdy predykcja zależy od świeżych danych w chwili zapytania, np. ocena transakcji kartą w trakcie płatności.
Czy model w produkcji trzeba regularnie uczyć od nowa?
Zwykle tak, bo dane dryfują. Częstotliwość wynika z monitoringu: lepiej przeuczać, gdy metryki lub rozkłady wejścia wyraźnie się zmieniają, niż według sztywnego kalendarza. Każdy nowy model przechodzi tę samą walidację co pierwszy.
Czy `pickle`/`joblib` jest bezpieczny?
Wczytanie takiego pliku może wykonać dowolny kod, więc nigdy nie ładuj modeli z niezaufanych źródeł. Do wymiany modeli między systemami lepsze są formaty bez kodu wykonywalnego, np. ONNX lub `safetensors` dla wag sieci.

Źródła

  • Sculley D. i in. „Hidden Technical Debt in Machine Learning Systems”, NeurIPS 2015.
  • Breck E., Cai S., Nielsen E., Salib M., Sculley D. „The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction”, IEEE Big Data 2017.
  • Huyen C. „Designing Machine Learning Systems”, O'Reilly 2022, rozdz. 7 (Model Deployment and Prediction Service).
  • Dokumentacja scikit-learn: „Model persistence”, https://scikit-learn.org/stable/model_persistence.html

Zobacz też