Dlaczego modele ML nie dożywają produkcji
Statystyka jest brutalna. Według badań VentureBeat i Gartner, 70-85% projektów machine learning nigdy nie wychodzi poza fazę eksperymentalną. Model działa na laptopie data scientista, ale nie w środowisku produkcyjnym firmy.
Powodów jest wiele: brak jakości danych, niejasne wymagania biznesowe, zbyt optymistyczne harmonogramy. Ale jest jeden powód, o którym mówi się za mało: brak systematycznej dokumentacji. Kiedy nikt nie zapisał, jakie dane posłużyły do treningu, jakie parametry ustawiono i dlaczego wybrano ten a nie inny algorytm, to po trzech miesiącach nikt nie jest w stanie odtworzyć wyników. Ani ich poprawić.
Widziałem to wielokrotnie. Zespół prezentuje świetne wyniki na demo. Dwa miesiące później model trafia do integracji i okazuje się, że nikt nie wie, która wersja danych dała te wyniki. Projekt wraca do punktu wyjścia.
Czym jest CRISP-ML(Q) i czym różni się od CRISP-DM
Jeśli pracujesz z danymi, pewnie znasz CRISP-DM. To najpopularniejsza metodologia projektów data science: 6 faz od zrozumienia biznesu po wdrożenie. Problem? CRISP-DM powstał w 1996 roku, kiedy „wdrożenie modelu” oznaczało coś zupełnie innego niż dziś.
CRISP-ML(Q) zachowuje sześć faz, ale dodaje brakujący element: wymagania jakościowe (Quality) przypisane do każdego kroku. To nie jest „zróbmy dokumentację na końcu, bo audyt”. To jest „dokumentacja jest częścią procesu, bez niej krok nie jest zakończony”.
Sześć faz CRISP-ML(Q): zrozumienie biznesu i danych, inżynieria danych, modelowanie, ewaluacja, wdrożenie i monitoring. Każda z opisanymi wymaganiami jakościowymi, metrykami i warunkami przejścia do następnej fazy.
Trzy filary dokumentacji ML
Reprodukowalność eksperymentów
W świecie badań naukowych rozróżnia się dwa poziomy: reprodukowalność metody (te same dane + te same parametry = te same wyniki) i reprodukowalność rezultatów (nowe dane + ta sama metoda = porównywalne wyniki).
W projektach firmowych często nie osiągamy nawet pierwszego poziomu. Data scientist raportuje „accuracy 94%” na prezentacji, ale kiedy ktoś inny próbuje odtworzyć eksperyment, dostaje 87%. Dlaczego? Bo nie wiadomo, jaki preprocessing zastosowano, jaki seed ustawiono, jakie dane wykluczono.
Raportowanie samego szczytu wyników, bez kontekstu eksperymentu, to praktyka, która podważa wiarygodność całego projektu.
Wersjonowanie danych
Kod wersjonujemy od lat (Git). Modele coraz częściej (MLflow). Ale dane? Dane w większości projektów traktujemy jak coś statycznego. „Mamy bazę”. Problem: dane żyją. Klienci się wypisują, produkty znikają z oferty, rynek się zmienia.
Bez wersjonowania danych nie jesteś w stanie powiedzieć, na czym model był trenowany. Nie możesz go przeaudytować, nie możesz porównać wersji, nie możesz wyjaśnić regulatorowi, dlaczego podjął taką a nie inną decyzję.
Wyjaśnialność jako wymóg jakości
Wyjaśnialność modeli (XAI) przestała być „miłym dodatkiem”. Od wejścia w życie AI Act w Unii Europejskiej to wymóg prawny dla systemów wysokiego ryzyka. Jeśli twój model wpływa na decyzje kredytowe, rekrutacyjne czy medyczne, musisz być w stanie wyjaśnić, dlaczego podjął daną decyzję.
CRISP-ML(Q) traktuje wyjaśnialność nie jako osobny krok „na końcu”, ale jako wymóg jakości wbudowany w fazę modelowania i ewaluacji. To zmienia perspektywę: nie „jak wyjaśnić gotowy model”, tylko „jak zbudować model, który da się wyjaśnić”.
Co dokumentować w każdej fazie
Poniżej znajdziesz minimum dokumentacji na każdym etapie z opisem ryzyka, które ponosisz, jeśli tego nie zapiszesz.
| Faza | Co dokumentować | Ryzyko bez dokumentacji |
|---|---|---|
| 1. Zrozumienie biznesu | Cel biznesowy, metryki sukcesu, ograniczenia (czas, budżet, dane) | Zespół optymalizuje złą metrykę przez 3 miesiące |
| 2. Inżynieria danych | Źródła danych, transformacje, wersje datasetów, decyzje o wykluczeniu rekordów | Niemożność odtworzenia wyników, nieświadome wprowadzenie biasu |
| 3. Modelowanie | Eksperymenty (parametry, wyniki, czas treningu), uzasadnienie wyboru algorytmu | „Czarny koń” bez gwarancji powtarzalności |
| 4. Ewaluacja | Metryki na zbiorze testowym, analiza błędów, testy fairness i robustness | Model przechodzi ewaluację przypadkiem, w produkcji błędy na edge cases |
| 5. Wdrożenie | Infrastruktura, SLA, rollback plan, monitoring | Brak procedury wycofania przy degradacji jakości |
| 6. Monitoring | Metryki driftu, progi alertów, harmonogram retreningu | Model degraduje się po cichu przez miesiące |
Narzędzia, które wspierają ten proces: MLflow (śledzenie eksperymentów, rejestr modeli) i DVC (wersjonowanie danych i pipeline’ów). Oba open-source, oba integrują się z Git.
5 kroków dla lidera wdrażającego CRISP-ML(Q)
Nie musisz być data scientistem, żeby wdrożyć ten framework. Musisz być liderem, który wymaga dokumentacji tak samo jak wymaga testów w kodzie.
- Krok 1: Ustal „definition of done” dla każdej fazy. Eksperyment bez zapisanych parametrów nie jest zakończony. Dataset bez wersji nie istnieje.
- Krok 2: Wybierz narzędzia (MLflow + DVC to bezpieczny start) i daj zespołowi tydzień na konfigurację.
- Krok 3: Wprowadź przegląd eksperymentów (experiment review) raz w tygodniu. 30 minut, cały zespół, dwa pytania: co przetestowaliśmy i co z tego wynika.
- Krok 4: Wymagaj karty modelu (model card) przed każdym wdrożeniem. Jedna strona: dane treningowe, metryki, ograniczenia, znane biasy.
- Krok 5: Zrób pierwszy audyt po 4 tygodniach. Sprawdź: czy potrafimy odtworzyć wyniki z miesiąca temu? Jeśli nie, wróć do kroku 1.
Koszt wdrożenia: około 2-3 tygodnie na konfigurację narzędzi i ustalenie procesów. Potem 20-30 minut tygodniowo na przeglądy. To ułamek czasu, który zespoły tracą na odtwarzanie utraconych eksperymentów.
Podsumowanie
CRISP-ML(Q) to nie biurokracja dla biurokracji. To odpowiedź na konkretny problem: projekty ML, które nie dożywają produkcji, bo nikt nie wie, jak odtworzyć wyniki. Dokumentacja eksperymentów, wersjonowanie danych i wyjaśnialność modeli to trzy filary, które zamieniają „jednorazowy sukces na laptopie” w powtarzalny proces biznesowy.
Jeśli zarządzasz zespołem data science i chcesz, żeby modele faktycznie trafiały do produkcji, zacznij od wymagania dokumentacji. Nie na końcu, nie jako raport. Od pierwszego dnia, jako część procesu.
