Konsulting machine learning: kiedy go zatrudnić, co ma dostarczyć i jak ocenić efekt

Head of Data w firmie dystrybucyjnej dostaje od zarządu zadanie: „zróbmy coś z AI w prognozowaniu popytu”. Po dwóch miesiącach rozmów z dostawcami na stole leżą trzy oferty. Każda obiecuje model, każda pokazuje slajdy z wynikami z innych branż, a jedna podaje nawet konkretną liczbę: „błąd prognozy niższy o 30%”. Żadna nie odpowiada na pytanie, od czego niższy. Od arkusza, w którym planiści od lat korygują średnią z ostatnich ośmiu tygodni? Od prognozy z systemu ERP? Od niczego?

Zlecenie zostaje podpisane, model powstaje, a na prezentacji końcowej widać wykres, na którym linia modelu leży bliżej rzeczywistości niż linia „stara metoda”. Pół roku później planiści dalej korzystają z arkusza. Model działa w notatniku na laptopie konsultanta, który przeszedł do innego projektu, a nikt w firmie nie umie go przeliczyć na nowych danych.

Ten artykuł jest dla CTO i szefów działów danych, którzy rozważają zatrudnienie zewnętrznego konsultingu machine learning. Broni jednego stanowiska: konsulting ML należy kupować jako decyzję, a nie jako model. Pierwszy etap zlecenia powinien kończyć się rozstrzygnięciem „wdrażać albo nie”, mierzonym na metryce biznesowej i względem uczciwego punktu odniesienia. Odpowiedź „nie róbcie ML” trzeba wpisać do umowy jako pełnoprawny, opłacony wynik. Jeśli konsultant nie potrafi takiej odpowiedzi udzielić, nie warto go zatrudniać, bo jego wynagrodzenie zależy od tego, żebyście budowali dalej.

Dlaczego zlecenie „zbudujcie nam model” jest źle postawionym zamówieniem?

Bo opisuje środek, a nie cel. Model jest narzędziem do poprawienia jakiejś decyzji: komu zaproponować rabat, ile towaru zamówić, którą reklamację rozpatrzyć najpierw, którą transakcję zatrzymać do sprawdzenia. Jeśli w zamówieniu nie ma tej decyzji, konsultant optymalizuje to, co umie zmierzyć sam, czyli wskaźnik jakości modelu. A wskaźnik jakości modelu i wartość dla firmy to dwie różne rzeczy.

Martin Zinkevich z Google zebrał w dokumencie „Rules of Machine Learning” zasady wynikające z wieloletniej praktyki budowania systemów ML w produktach tej firmy. Pierwsza z nich brzmi: „Don’t be afraid to launch a product without machine learning”, czyli nie bój się uruchomić produktu bez uczenia maszynowego. Druga: najpierw zaprojektuj i wdroż metryki. Kolejność nie jest przypadkowa. Zanim cokolwiek się wytrenuje, trzeba wiedzieć, co dziś się dzieje i jak to zmierzyć. Zlecenie „zbudujcie nam model” odwraca tę kolejność i każe zaczynać od rozwiązania.

Drugi problem jest finansowy. Jeśli umowa rozlicza konsultanta za dostarczenie modelu, to model zostanie dostarczony niezależnie od tego, czy ma sens. Nie musi tu działać zła wola. Wystarczy, że każdy w projekcie wie, iż wynik „to się nie opłaca” oznacza koniec zlecenia, a wynik „mamy obiecujący prototyp” oznacza kolejny etap. Konsultant, który rekomenduje zakończenie współpracy, robi to wbrew własnemu interesowi, więc umowa powinna ten interes zneutralizować.

Trzeci problem to definicja sukcesu. Bez wcześniej ustalonej metryki biznesowej i progu, od którego wdrożenie się opłaca, każdy wynik da się przedstawić jako sukces. Trafność 87% brzmi dobrze, dopóki ktoś nie zapyta, ile wynosiła trafność reguły, którą firma stosuje dziś, i ile kosztuje każdy błąd w jedną i w drugą stronę.

Dlatego dobre zamówienie na konsulting ML brzmi inaczej: „Chcemy wiedzieć, czy model może poprawić decyzję X na tyle, żeby pokryć koszt budowy i utrzymania. Jeśli tak, chcemy dostać działający pipeline i plan wdrożenia. Jeśli nie, chcemy dostać pomiar, który to pokazuje, i rekomendację, co zrobić zamiast tego”.

Kiedy konsulting ML ma sens, a kiedy wystarczy analityk albo reguła?

Konsulting ML ma sens, gdy jednocześnie spełnione są cztery warunki. Po pierwsze, istnieje powtarzalna decyzja podejmowana wiele razy: setki razy dziennie, a nie kilka razy w roku. Model zarabia na skali, bo każda pojedyncza poprawa jest mała. Po drugie, istnieją dane historyczne o tej decyzji i o jej skutkach. Nie wystarczy wiedzieć, komu wysłano ofertę. Trzeba wiedzieć, kto ją przyjął. Po trzecie, obecny sposób podejmowania decyzji ma mierzalny koszt błędu. Po czwarte, firma nie wie, czy ML tu pomoże, i ta niepewność blokuje decyzję budżetową.

Jeśli brakuje pierwszego warunku, decyzja jest rzadka i strategiczna, a lepszym wsparciem będzie analityk z dobrym modelem w arkuszu niż system uczący się. Jeśli brakuje drugiego, pierwszym zleceniem powinno być uporządkowanie danych, a nie model. Opisaliśmy to szerzej w tekście o zarządzaniu danymi jako usłudze. Jeśli brakuje trzeciego, nie da się policzyć, czy model się opłaca. Jeśli brakuje czwartego, bo wiadomo już, że model jest potrzebny, kupujesz raczej usługę budowy (ML development) albo wzmocnienie zespołu, a nie konsulting.

Osobny przypadek to sytuacja, w której zarząd chce „projektu AI”, a nikt nie wskazał decyzji do poprawienia. Konsulting ML nie powinien wtedy zaczynać od modelu, tylko od przeglądu procesów i wyboru jednego miejsca, w którym da się zmierzyć efekt. Zdarza się, że największy zysk daje nie model, ale prosta reguła, której wcześniej nikt nie zapisał, albo zmiana procesu, która usuwa ręczne przepisywanie danych.

Warto też pamiętać o trzeciej zasadzie Zinkevicha: złożona heurystyka jest nie do utrzymania. To argument w drugą stronę. Jeśli firma od lat dopisuje do systemu kolejne wyjątki i reguły, aż nikt nie rozumie, dlaczego klient dostał taki, a nie inny rabat, model uczony na danych może okazać się prostszy w utrzymaniu niż dotychczasowy zestaw reguł. Konsultant powinien umieć ocenić obie strony tego rachunku.

Czym różni się konsulting ML od usługi ML development i od wdrożenia gotowego narzędzia AI?

Te trzy usługi są często sprzedawane pod jedną nazwą, a różnią się tym, kto ponosi ryzyko i co jest wynikiem.

Konsulting ML odpowiada na pytanie „czy i jak”. Wynikiem jest decyzja poparta pomiarem, a jeśli decyzja jest pozytywna, także działający prototyp, architektura docelowa i plan wdrożenia. Ryzyko, że ML się nie opłaci, jest tu jawnie na stole i właśnie za jego rozstrzygnięcie się płaci. Zlecenie jest krótkie, liczone w tygodniach, a nie w kwartałach.

ML development, czyli usługa budowy systemów uczenia maszynowego, odpowiada na pytanie „zbudujcie to”. Zakłada, że decyzja o wdrożeniu już zapadła. Wynikiem jest system na produkcji z pipeline’em treningowym, monitoringiem i dokumentacją. Ryzyko leży głównie po stronie inżynierskiej: terminy, jakość kodu, integracje. Jeśli firma kupuje ML development, zanim rozstrzygnęła, czy ML się opłaca, płaci za budowę czegoś, co może okazać się zbędne.

Wdrożenie gotowego narzędzia AI, na przykład modułu prognozowania w systemie ERP albo usługi chmurowej z gotowym modelem, odpowiada na pytanie „skonfigurujcie to”. Jest najtańsze na starcie, ale daje najmniej kontroli nad tym, co model robi i na jakich danych się uczy. Decyzję, czy budować, czy kupować, omówiliśmy w osobnym tekście o kryteriach wyboru dostawcy AI, gdzie kluczowe okazuje się rozstrzygnięcie ról regulacyjnych, zanim ktokolwiek oceni jakość modelu.

W praktyce dobre zlecenie konsultingowe kończy się rekomendacją jednej z tych trzech dróg albo rekomendacją, żeby nie iść żadną z nich. Konsultant, który zawsze rekomenduje budowę od zera, sprzedaje ML development pod szyldem konsultingu. Konsultant, który zawsze rekomenduje jedno konkretne narzędzie, może być jego resellerem. Warto zapytać wprost, jakie rekomendacje padły w ostatnich zleceniach i jak często były negatywne.

Co powinien zawierać brief przed pierwszą rozmową z konsultantem?

Brief to dokument, który przygotowuje firma, a nie konsultant. Im lepszy brief, tym krótszy i tańszy pierwszy etap, bo konsultant nie musi odkrywać rzeczy, które ktoś w firmie już wie. Wystarczy jedna do dwóch stron, ale z konkretami.

Decyzja do poprawienia. Jedno zdanie: „Codziennie planiści decydują, ile sztuk każdego z 4000 indeksów zamówić u dostawców na kolejny tydzień”. Nie „chcemy lepiej prognozować”.

Obecny sposób podejmowania decyzji. Jak to działa dziś: reguła, arkusz, decyzja eksperta, moduł systemu. To będzie pierwszy punkt odniesienia, więc musi być opisany na tyle dokładnie, żeby dało się go odtworzyć na danych historycznych.

Koszt błędu w obie strony. Ile kosztuje zamówienie za dużo (zamrożony kapitał, przeterminowanie, magazyn) i ile za mało (utracona sprzedaż, transport ekspresowy). Często te koszty są niesymetryczne i to zmienia wszystko w ewaluacji modelu.

Dostępne dane. Jakie systemy, jaki okres, jakie znane problemy z jakością. Kto jest właścicielem danych i czy konsultant dostanie do nich dostęp w pierwszym tygodniu, a nie w szóstym. Zwłoka w dostępie do danych wydłuża pierwszy etap bardziej niż jakakolwiek trudność modelowania, bo przez ten czas konsultant nie ma na czym pracować.

Ograniczenia. Czy model musi być wyjaśnialny dla klienta lub regulatora, czy decyzja dotyczy osób fizycznych, jakie są wymagania co do czasu odpowiedzi, czy dane mogą opuścić infrastrukturę firmy.

Właściciel po stronie firmy. Osoba, która ma czas na cotygodniowe spotkania, zna proces i ma prawo podjąć decyzję o wyniku etapu. Bez niej konsultant optymalizuje pod własne założenia.

Minimalny efekt, który uzasadnia wdrożenie. To najtrudniejszy punkt i często pomijany. Jeśli model obniży błąd prognozy o jeden punkt procentowy, czy to wystarczy, żeby pokryć koszt utrzymania? A o pięć? Nawet zgrubny próg zapisany przed rozpoczęciem prac chroni przed sytuacją, w której każdy wynik jest ogłaszany jako sukces.

Dlaczego baseline jest pierwszym produktem, a nie formalnością?

Baseline, czyli punkt odniesienia, to wynik, jaki na tych samych danych osiąga rozwiązanie bez nowego modelu. Bez niego każdy wynik modelu jest liczbą bez kontekstu. Model, który przewiduje odejście klienta z trafnością 95%, wydaje się świetny, dopóki nie okaże się, że odchodzi 5% klientów, a „model” przewidujący, że nikt nie odejdzie, też ma trafność 95%.

To nie jest teoretyczny problem. Biblioteka scikit-learn, jedna z podstawowych w ekosystemie Pythona, ma osobny komponent DummyClassifier, który przewiduje, ignorując dane wejściowe. Dokumentacja opisuje go jako „simple baseline to compare against other more complex classifiers”, czyli prosty punkt odniesienia do porównań z bardziej złożonymi klasyfikatorami. Jeśli konsultant nie pokazuje wyniku takiego naiwnego modelu obok swojego, nie wiadomo, ile z wyniku jest zasługą modelu, a ile struktury danych.

Dobry konsultant buduje jednak co najmniej trzy punkty odniesienia, a nie jeden:

1. Baseline naiwny: zawsze najczęstsza klasa, średnia z ostatniego okresu, wartość z tego samego dnia rok wcześniej. Pokazuje, ile informacji jest w samej strukturze danych.
2. Baseline obecnego procesu: odtworzona na danych historycznych reguła lub decyzja, którą firma stosuje dziś. To jest właściwy konkurent modelu, bo to z nim model musi wygrać, żeby wdrożenie miało sens.
3. Baseline prostego modelu: regresja liniowa lub logistyczna, drzewo decyzyjne, model z kilkoma oczywistymi cechami. Pokazuje, ile daje samo uczenie maszynowe, zanim ktokolwiek sięgnie po złożone architektury.

Czwarta zasada Zinkevicha mówi, żeby pierwszy model był prosty, a uwagę skupić na poprawnej infrastrukturze, bo to pierwszy model daje największy wzrost. Jeśli prosty model wygrywa z obecnym procesem o 80% tego, co daje model złożony, decyzja o tym, który z nich wdrożyć, jest decyzją o koszcie utrzymania, a nie o jakości.

Baseline obecnego procesu ma jeszcze jedną wartość: zmusza do opisania, jak firma dziś naprawdę decyduje. Bywa, że już samo zapisanie reguły, którą planiści stosują intuicyjnie, ujawnia jej słabości. Bywa też, że odtworzenie decyzji eksperta na danych historycznych pokazuje, że ekspert jest znacznie lepszy, niż wszyscy sądzili, i że model ma bardzo mało miejsca na poprawę. Oba wyniki są cenne i oba powinny pojawić się w raporcie z pierwszych tygodni, zanim powstanie jakikolwiek złożony model.

Jak przełożyć metrykę modelu na metrykę biznesową, którą da się rozliczyć?

Metryki modelu, takie jak trafność, precyzja, czułość, AUC albo średni błąd bezwzględny, mówią, jak model radzi sobie z przewidywaniem. Nie mówią, ile to jest warte. Przekład wymaga trzech elementów: kosztu każdego typu błędu, liczby decyzji w okresie i sposobu, w jaki wynik modelu zmienia działanie ludzi lub systemów.

Weźmy przykład z prognozowaniem popytu. Model obniża średni błąd prognozy z 24% do 19%. Co to znaczy dla firmy? To zależy od tego, jak planiści korzystają z prognozy. Jeśli zamawiają zawsze prognozę plus zapas bezpieczeństwa, niższy błąd pozwala obniżyć zapas, a to przekłada się na kapitał zamrożony w magazynie. Ten kapitał da się policzyć. Jeśli planiści i tak korygują prognozę według własnego uznania, poprawa modelu może nie zmienić niczego, dopóki nie zmieni się proces.

Druga pułapka to asymetria kosztów. W wykrywaniu nadużyć przepuszczenie nadużycia kosztuje wartość transakcji, a fałszywy alarm kosztuje czas analityka i irytację klienta. Model z wyższą trafnością ogólną może być gorszy biznesowo, jeśli myli się częściej w droższą stronę. Dlatego próg decyzyjny modelu, czyli od jakiego prawdopodobieństwa uznajemy przypadek za podejrzany, powinien być ustalany na podstawie kosztów, a nie domyślnie na 0,5.

Trzecia pułapka to pojemność procesu. Jeśli model wskazuje 500 podejrzanych reklamacji dziennie, a zespół jest w stanie sprawdzić 80, liczy się precyzja w pierwszych 80 wskazaniach, a nie wynik na całym zbiorze. Konsultant, który raportuje AUC bez odniesienia do pojemności zespołu, raportuje metrykę, której nikt w firmie nie użyje.

Metryka modelu	Pytanie biznesowe, które trzeba zadać	Przekład na wartość
Trafność (accuracy)	Jak często dziś mylimy się w każdą stronę i ile kosztuje każdy błąd?	Liczba błędów każdego typu × koszt jednostkowy, porównana z baseline’em procesu
Precyzja w pierwszych N wskazaniach	Ile przypadków zespół jest w stanie obsłużyć dziennie?	Liczba trafnych interwencji w ramach pojemności × wartość jednej interwencji
Czułość (recall)	Ile kosztuje przypadek, którego nie wykryliśmy?	Wartość wykrytych przypadków minus koszt fałszywych alarmów
Średni błąd prognozy	Jak prognoza wpływa na zapas, zamówienie, obsadę?	Zmiana zapasu bezpieczeństwa lub nadgodzin wynikająca z niższego błędu
Czas odpowiedzi modelu	Czy decyzja zapada w czasie rzeczywistym, czy w nocnym przebiegu?	Koszt infrastruktury potrzebnej do spełnienia wymagania

Zinkevich radzi, żeby pierwszy cel modelu był prosty, obserwowalny i przypisywalny, czyli żeby było jasne, że to model, a nie coś innego, wpłynął na wynik. To dobra reguła także dla umowy konsultingowej: metryka, na którą umówiliście się na początku, powinna być taka, którą firma sama potrafi policzyć po zakończeniu zlecenia, bez dostępu do narzędzi konsultanta. Jeśli metryka jest zbyt złożona, by ją policzyć w arkuszu, warto ją uprościć, nawet kosztem części informacji.

Jak wygląda uczciwa ewaluacja offline i gdzie najczęściej oszukuje sama siebie?

Ewaluacja offline to sprawdzenie modelu na danych historycznych, których nie widział podczas treningu. Jest konieczna, tania i szybka, ale ma jedną wadę: bardzo łatwo przeprowadzić ją tak, żeby wynik był lepszy niż rzeczywistość. Rzadko jest to celowe. Zwykle wynika z drobnych decyzji, których skutków nikt nie sprawdził.

Najgroźniejszy błąd to wyciek danych (data leakage): model ma w danych treningowych informację, której nie będzie miał w chwili podejmowania decyzji. Klasyczny przykład: model przewidujący odejście klienta używa cechy „liczba kontaktów z działem retencji”, a dział retencji kontaktuje się z klientami dopiero wtedy, gdy ci zgłoszą chęć odejścia. Model wygląda genialnie, bo przewiduje skutek na podstawie jego objawu. Sayash Kapoor i Arvind Narayanan z Uniwersytetu Princeton przejrzeli w 2022 roku literaturę naukową wykorzystującą ML i znaleźli błędy związane z wyciekiem w 17 dziedzinach, dotyczące łącznie 329 publikacji. Jeśli ten błąd popełniają badacze w recenzowanych pracach, popełnia go też projekt konsultingowy pisany pod presją terminu.

Drugi błąd to losowy podział danych w problemach zależnych od czasu. Jeśli model prognozuje przyszłość, a dane podzielono losowo na treningowe i testowe, model uczy się na danych z marca, żeby „przewidzieć” luty. W rzeczywistości nigdy nie będzie miał dostępu do przyszłości. Uczciwa ewaluacja w takich problemach dzieli dane chronologicznie: trening na starszych, test na nowszych, najlepiej z kilkoma oknami czasowymi, żeby zobaczyć, czy wynik jest stabilny.

Trzeci błąd to wielokrotne zaglądanie do zbioru testowego. Każdy raz, gdy zespół sprawdza wynik na zbiorze testowym i na tej podstawie zmienia model, zbiór testowy staje się częścią treningu. Po dwudziestu iteracjach wynik testowy jest optymistyczny. Rozwiązaniem jest odłożenie osobnego zbioru, którego nikt nie dotyka do samego końca etapu, najlepiej przechowywanego po stronie firmy, a nie konsultanta.

Czwarty błąd to różnica między danymi treningowymi a produkcyjnymi (training-serving skew). Dane historyczne bywają wyczyszczone, uzupełnione i połączone w hurtowni, a w chwili decyzji system ma dostęp tylko do części z nich, czasem z opóźnieniem. Zinkevich poświęca temu kilka zasad, m.in. radę, by zapisywać zestaw cech używany w chwili serwowania i trenować na nim, oraz ostrzeżenie, że dane w łączonych tabelach mogą się zmienić między treningiem a serwowaniem.

Co z tego wynika dla zamawiającego? W raporcie z ewaluacji offline powinny znaleźć się: opis podziału danych z datami, lista cech z informacją, kiedy każda z nich jest dostępna w procesie, wynik na zbiorze odłożonym, który został użyty raz, oraz porównanie ze wszystkimi trzema baseline’ami na tym samym zbiorze. Jeśli któregoś z tych elementów brakuje, warto o niego poprosić przed podjęciem decyzji o kolejnym etapie. Nie jest to wyraz nieufności. To standard, który dobry konsultant stosuje i tak.

Kiedy ewaluacja offline nie wystarczy i jak zaplanować test online?

Ewaluacja offline mówi, czy model dobrze przewidywał przeszłość. Nie mówi, czy jego wdrożenie zmieni wynik biznesowy. Między jednym a drugim stoją ludzie, procesy i zachowanie klientów, które zmieniają się pod wpływem decyzji modelu. Model rekomendacji, który na danych historycznych trafnie przewidywał zakupy, może po wdrożeniu rekomendować produkty, które klient i tak by kupił, nie zwiększając sprzedaży ani o złotówkę.

Dlatego kryterium „wdrażamy” powinno opierać się na teście na żywym ruchu. Ron Kohavi, Diane Tang i Ya Xu w książce „Trustworthy Online Controlled Experiments” (Cambridge University Press, 2020) opisują metodykę kontrolowanych eksperymentów online, opartą na doświadczeniach firm takich jak Microsoft, Google i LinkedIn. Kluczowa idea jest prosta: część przypadków obsługuje nowe rozwiązanie, część dotychczasowe, przydział jest losowy, a metryka i minimalny efekt są ustalone przed rozpoczęciem testu.

W konsultingu ML praktyczna sekwencja wygląda zwykle tak:

1. Tryb cienia (shadow mode). Model liczy wyniki na żywych danych, ale nie wpływa na decyzje. Pozwala sprawdzić, czy wyniki na produkcji zgadzają się z ewaluacją offline, czy dane docierają na czas i czy nie ma różnic między treningiem a serwowaniem. Trwa zwykle kilka tygodni, bo musi objąć typowe wahania, np. tygodniowe.
2. Ograniczony eksperyment. Model podejmuje lub wspiera decyzje w części przypadków: w kilku sklepach, regionach, dla losowej części klientów. Reszta działa po staremu. Porównanie dotyczy metryki biznesowej, nie metryki modelu.
3. Decyzja o rozszerzeniu. Na podstawie wyniku eksperymentu, przy wcześniej ustalonym progu, firma decyduje o pełnym wdrożeniu, poprawie albo rezygnacji.

Nie każdy problem pozwala na klasyczny test A/B. W prognozowaniu popytu trudno losowo przydzielać indeksy do „modelu” i „arkusza”, jeśli są ze sobą powiązane. Można wtedy porównywać regiony lub magazyny, stosować porównanie z okresem kontrolnym albo przeprowadzić test tylko na części asortymentu. Konsultant powinien zaproponować projekt testu dopasowany do procesu i uczciwie opisać jego ograniczenia, bo każdy z tych wariantów daje słabszy dowód niż losowy eksperyment.

Test online wymaga też zaangażowania ludzi. Jeśli model wspiera decyzje pracowników, trzeba wiedzieć, jak często pracownicy korzystają z jego podpowiedzi, a jak często je odrzucają. Zaprojektowanie tego miejsca, w którym człowiek przyjmuje lub odrzuca wynik modelu, opisaliśmy w tekście o human in the loop. Wskaźnik odrzuceń bywa najszybszym sygnałem, że model rozwiązuje inny problem niż ten, który mają ludzie.

Co dokładnie musi zostać przekazane, żeby model nie umarł po odejściu konsultanta?

Scena z początku artykułu, model w notatniku na laptopie konsultanta, to typowy koniec zlecenia, w którym nikt nie zdefiniował przekazania. Google w dokumentacji architektury MLOps opisuje to jako poziom 0 dojrzałości: proces ręczny, sterowany skryptami i interaktywny, w którym data scientist przekazuje wytrenowany model jako artefakt zespołowi inżynierskiemu, nowa wersja modelu trafia na produkcję kilka razy w roku, a przewidywania nie są śledzone ani logowane. W takim stanie spadek jakości modelu może pozostać niezauważony przez miesiące.

Ta sama dokumentacja przypomina, że w rzeczywistym systemie ML tylko niewielka część to kod modelu, a resztę stanowią konfiguracja, weryfikacja danych, serwowanie i monitoring. To obserwacja z pracy D. Sculleya i współautorów „Hidden Technical Debt in Machine Learning Systems” (NIPS 2015), w której zespół z Google ostrzegał, że szybkie sukcesy w ML nie są darmowe i generują wysokie koszty utrzymania: splątanie cech, ukryte pętle sprzężenia zwrotnego, zależności od danych, zmiany w świecie zewnętrznym. Konsultant, który przekazuje sam model, przekazuje najmniejszą część systemu.

Lista przekazania powinna być częścią umowy i obejmować:

• Kod przygotowania danych od surowych źródeł do zbioru treningowego, uruchamialny w infrastrukturze firmy, z opisem zależności i wersjami bibliotek.
• Kod treningu i ewaluacji, łącznie z kodem liczącym baseline’y, żeby każde przyszłe przeuczenie dało się porównać z tym samym punktem odniesienia.
• Pipeline, a nie tylko skrypty: sekwencję kroków, którą da się uruchomić jednym poleceniem lub z harmonogramu, na nowych danych, bez ręcznych poprawek.
• Kartę modelu (model card). Margaret Mitchell i współautorzy zaproponowali w 2018 roku standard dokumentu opisującego model: przeznaczenie, warunki, w jakich go oceniano, wyniki w różnych grupach i ograniczenia. Dla zamawiającego to dokument, który mówi, do czego modelu nie wolno używać.
• Opis monitoringu: jakie wskaźniki śledzić (rozkład danych wejściowych, rozkład przewidywań, metrykę biznesową), jakie progi oznaczają problem i co robić, gdy zostaną przekroczone.
• Plan przeuczania: jak często, na jakich danych, kto podejmuje decyzję o wdrożeniu nowej wersji.
• Sesje przekazania wiedzy z osobami, które będą system utrzymywać, zakończone samodzielnym uruchomieniem pipeline’u przez zespół firmy, bez pomocy konsultanta.

Ostatni punkt jest testem całej listy. Jeśli zespół firmy nie umie samodzielnie przeuczyć modelu i porównać nowej wersji z poprzednią, przekazanie się nie odbyło, niezależnie od tego, ile dokumentów powstało. Szerzej o tym, co dzieje się z modelem po wdrożeniu i dlaczego to jakość danych, a nie model, generuje koszt w kolejnych latach, piszemy w tekście o prawdziwym koszcie AI. Praktyczną stronę przejścia od notatnika do produkcji opisuje z kolei artykuł o MLOps w praktyce.

Kto ma ten system utrzymywać? Jeśli firma nie ma inżynierów ML, przekazanie trafia do zespołu, który nie umie z niego skorzystać. Wtedy częścią rekomendacji konsultanta powinno być wskazanie, jakich kompetencji brakuje: często wystarczy jeden inżynier Pythona z doświadczeniem w pipeline’ach danych, a nie cały zespół data science. Takich specjalistów można pozyskać także w modelu programistów Python wzmacniających zespół wewnętrzny.

Dlaczego „nie róbcie ML” bywa najcenniejszym wynikiem zlecenia i jak go zapisać w umowie?

Bo budowa modelu to dopiero początek wydatków. Model na produkcji wymaga monitoringu, przeuczania, utrzymania pipeline’u, reagowania na zmiany w danych źródłowych i na zmiany w świecie, które sprawiają, że wzorce z przeszłości przestają działać. Szacunki kosztów od prototypu do produkcji zebraliśmy w tekście o koszcie wdrożenia AI. Jeśli model poprawia decyzję o tyle, że nie pokrywa tych kosztów, wdrożenie go jest stratą, nawet jeśli technicznie działa.

Wynik „nie róbcie ML” ma kilka typowych postaci, a każda z nich jest wartościowa:

• Prosta reguła wystarcza. Baseline prostego modelu albo dobrze zapisana reguła osiąga prawie tyle samo co model złożony. Rekomendacja: wdrożyć regułę w istniejącym systemie, bez nowej infrastruktury.
• Dane nie niosą sygnału. Żaden model nie wygrywa wyraźnie z baseline’em naiwnym, bo w danych nie ma informacji, która pozwalałaby przewidywać wynik. Rekomendacja: zacząć zbierać dane, których brakuje, i wrócić do tematu po określonym czasie.
• Dane są zbyt złej jakości. Sygnał prawdopodobnie istnieje, ale błędy, braki i niespójności go zagłuszają. Rekomendacja: najpierw projekt jakości danych, potem ponowna ocena.
• Proces nie skorzysta z modelu. Model działa, ale proces nie przewiduje miejsca na jego wynik albo ludzie nie mają możliwości z niego skorzystać. Rekomendacja: zmiana procesu przed modelem.
• Ryzyko regulacyjne przewyższa korzyść. Decyzja dotyczy osób fizycznych w sposób, który wymaga wyjaśnialności, nadzoru i dokumentacji, a ich koszt przewyższa zysk.

Żeby taki wynik był możliwy, umowa musi go przewidywać. Pierwszy etap powinien mieć stałą cenę i zakres zdefiniowany jako „rozstrzygnięcie”, a nie „model”. Wynagrodzenie nie może zależeć od tego, czy rekomendacja jest pozytywna. Kryteria rekomendacji, czyli minimalny efekt na metryce biznesowej, powinny być zapisane przed rozpoczęciem prac. Warto też zapisać, że niezależnie od rekomendacji firma otrzymuje cały kod, dane pośrednie i raport, bo negatywny wynik też jest aktywem: chroni przed powtórzeniem tego samego badania za dwa lata przez kolejnego dostawcę.

Jest jeszcze jeden argument, mniej oczywisty. Konsultant, który na początku współpracy mówi wprost, że jedną z możliwych rekomendacji jest rezygnacja z ML, daje sygnał, że nie sprzedaje wyniku, tylko odpowiedź. To dobry test przy wyborze dostawcy: zapytaj, w jakich warunkach zarekomendowałby rezygnację. Jeśli nie umie podać takich warunków, prawdopodobnie nigdy jej nie zarekomenduje.

Jak ułożyć etapy, kamienie milowe i rozliczenie zlecenia?

Zlecenie konsultingu ML warto ułożyć w etapy, z których każdy kończy się decyzją firmy, a nie automatycznym przejściem do kolejnego. Taki podział ogranicza ryzyko obu stron i sprawia, że każdy etap ma swoją stałą cenę albo jasno zdefiniowany limit czasu pracy.

Etap	Typowy czas	Co powstaje	Kryterium przejścia dalej
0. Brief i dostęp do danych	1–2 tygodnie (po stronie firmy)	Opis decyzji, koszt błędów, dostęp do danych, właściciel	Konsultant potwierdza, że dane wystarczają do pierwszej oceny
1. Ocena wykonalności	3–6 tygodni	Trzy baseline’y, model kandydujący, ewaluacja offline z opisem podziału, wycena różnicy	Model wygrywa z baseline’em procesu o więcej niż ustalony próg; w przeciwnym razie raport „nie wdrażać” i koniec
2. Prototyp produkcyjny	4–8 tygodni	Pipeline w infrastrukturze firmy, tryb cienia, monitoring, karta modelu	Wyniki w trybie cienia zgodne z ewaluacją offline; brak różnic trening–serwowanie
3. Eksperyment	4–12 tygodni	Test na części przypadków, pomiar metryki biznesowej	Efekt na metryce biznesowej przekracza próg; zespół korzysta z wyników
4. Przekazanie	2–4 tygodnie	Dokumentacja, sesje, samodzielne przeuczenie przez zespół firmy	Zespół firmy samodzielnie przeucza i porównuje nową wersję modelu

Czasy w tabeli to szacunek, a nie norma rynkowa. Zależą przede wszystkim od trzech czynników: jak szybko firma da dostęp do danych, jak długi cykl ma proces biznesowy (prognoza tygodniowa wymaga dłuższego trybu cienia niż decyzja podejmowana co minutę) oraz czy model musi zostać zintegrowany z istniejącym systemem transakcyjnym.

Model rozliczenia warto dopasować do etapu. Etap pierwszy najlepiej sprawdza się w stałej cenie, bo jego zakres to rozstrzygnięcie, a nie wynik. Etapy drugi i trzeci często lepiej rozliczać za czas pracy z limitem, bo ich przebieg zależy od zachowania systemów i ludzi po stronie firmy. Etap przekazania powinien mieć kryterium odbioru zdefiniowane jako umiejętność zespołu firmy, a nie liczba stron dokumentacji.

Nie każde zlecenie przejdzie przez wszystkie etapy. Część zakończy się po etapie pierwszym rekomendacją „nie wdrażać” i to jest dobry wynik, jeśli kosztował ułamek budżetu, który poszedłby na budowę. Część przejdzie przez etap drugi i trzeci, a potem okaże się, że efekt biznesowy jest mniejszy niż w ewaluacji offline. To też jest wiedza, za którą warto zapłacić przed pełnym wdrożeniem, a nie po nim.

Jakie regulacje zmieniają zakres zlecenia ML w Unii Europejskiej?

Jeśli model ma wpływać na decyzje dotyczące osób fizycznych, zakres zlecenia trzeba poszerzyć o kwestie prawne, zanim powstanie pierwszy model. Dwa akty prawne mają tu największe znaczenie.

Pierwszy to RODO. Art. 22 daje osobie, której dane dotyczą, prawo do tego, by nie podlegać decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu, w tym profilowaniu, jeśli wywołuje ona wobec niej skutki prawne lub w podobny sposób istotnie na nią wpływa. Dla konsultingu ML oznacza to, że trzeba ustalić, czy model decyduje sam, czy wspiera decyzję człowieka, i zaprojektować proces tak, żeby udział człowieka był rzeczywisty, a nie formalny.

Drugi to rozporządzenie o sztucznej inteligencji, czyli AI Act (rozporządzenie (UE) 2024/1689). Jego załącznik III wymienia obszary, w których systemy AI są uznawane za systemy wysokiego ryzyka. Należą do nich m.in. systemy przeznaczone do rekrutacji lub wyboru kandydatów, systemy wpływające na decyzje o awansie, zwolnieniu lub przydziale zadań oraz systemy oceniające zdolność kredytową osób fizycznych lub ustalające ich scoring kredytowy, z wyłączeniem systemów wykrywania oszustw finansowych. Jeśli projekt dotyka któregoś z tych obszarów, wymagania co do dokumentacji, zarządzania danymi, nadzoru człowieka i jakości są znacznie wyższe, a ich koszt powinien pojawić się w ocenie wykonalności z etapu pierwszego.

Praktyczny wniosek jest prosty: w briefie i w etapie pierwszym trzeba odpowiedzieć na pytanie, czy decyzja dotyczy osób fizycznych i czy mieści się w obszarach z załącznika III. Odpowiedź może zmienić rekomendację. Model scoringowy, który daje niewielką poprawę względem reguły, może okazać się nieopłacalny po doliczeniu kosztów zgodności, a reguła prostsza do wyjaśnienia klientowi i nadzorcy wygrywa wtedy nie technicznie, tylko ekonomicznie.

Jak rozpoznać, że konsultant ML pracuje na Twój wynik, a nie na kolejny etap?

Kilka sygnałów pojawia się już w pierwszych tygodniach i pozwala ocenić, czy zlecenie zmierza we właściwą stronę.

Pierwszy raport zawiera baseline’y, zanim pojawi się model. Jeśli po dwóch tygodniach widzisz wynik złożonego modelu, a nie widzisz wyniku obecnego procesu odtworzonego na danych, kolejność jest odwrócona.

Konsultant pyta o koszt błędów i o pojemność procesu. Pytania o to, ile kosztuje każdy rodzaj pomyłki i ile przypadków ludzie są w stanie obsłużyć, świadczą o tym, że myśli o decyzji, a nie o metryce.

Kod działa w Twojej infrastrukturze od początku. Praca na danych skopiowanych na laptop konsultanta jest szybsza na starcie, ale prowadzi prosto do sytuacji z początku artykułu. Repozytorium po stronie firmy i środowisko, w którym pracuje konsultant, ułatwiają też późniejsze przekazanie.

Raport opisuje, czego model nie umie. Każdy model ma obszary, w których działa źle: nowe produkty bez historii, rzadkie segmenty klientów, okresy nietypowe. Raport, który ich nie wymienia, nie został sprawdzony albo coś ukrywa.

Rekomendacja jest warunkowa i liczbowa. „Rekomendujemy wdrożenie, jeśli w trybie cienia błąd prognozy pozostanie poniżej X przez cztery tygodnie” to rekomendacja, którą da się sprawdzić. „Model jest obiecujący i warto go rozwijać” to zaproszenie do kolejnego zlecenia.

Konsultant mówi o kosztach utrzymania. Jeśli w raporcie jest tylko koszt budowy, a nie ma szacunku kosztu monitoringu, przeuczania i utrzymania pipeline’u, decyzja zarządu będzie oparta na połowie rachunku. Podstawowe pojęcia i typowe zastosowania modeli przewidujących zebraliśmy w słownikowym haśle o analizie predykcyjnej.

Odwrotne sygnały, na które warto zareagować: brak dostępu firmy do kodu do końca etapu, wyniki podawane wyłącznie jako metryki modelu, brak opisu podziału danych, zmiana metryki sukcesu w trakcie etapu bez zgody właściciela po stronie firmy, rekomendacja dalszych prac bez jasnego kryterium, po którym te prace się zakończą.

Jakie są kluczowe wnioski przed zatrudnieniem konsultingu ML?

Konsulting machine learning jest wart swojej ceny wtedy, gdy kupujesz od niego rozstrzygnięcie, a nie artefakt. Model jest jednym z możliwych wyników, a nie celem zlecenia. Celem jest odpowiedź na pytanie, czy uczenie maszynowe poprawi konkretną decyzję na tyle, by opłacić budowę i utrzymanie, popartą pomiarem, który firma może sama powtórzyć.

Zapamiętaj siedem rzeczy. Po pierwsze, napisz brief z decyzją do poprawienia, kosztem błędów w obie strony i minimalnym efektem, który uzasadnia wdrożenie. Po drugie, wymagaj trzech baseline’ów: naiwnego, obecnego procesu i prostego modelu, policzonych na tych samych danych co model docelowy. Po trzecie, przekładaj metryki modelu na pieniądze lub godziny, z uwzględnieniem asymetrii kosztów i pojemności procesu. Po czwarte, sprawdzaj ewaluację offline pod kątem wycieku danych, podziału chronologicznego i zbioru odłożonego, a decyzję o wdrożeniu opieraj na teście online. Po piąte, zapisz w umowie listę przekazania, której odbiorem jest samodzielne przeuczenie modelu przez Twój zespół. Po szóste, wpisz „nie wdrażać ML” jako pełnoprawny wynik pierwszego etapu, opłacony tak samo jak wynik pozytywny. Po siódme, jeśli decyzja dotyczy osób fizycznych, sprawdź RODO i załącznik III AI Act, zanim powstanie pierwszy model.

Jeśli rekomendacja jest pozytywna i potrzebujesz zespołu, który zbuduje pipeline, zintegruje model z Twoimi systemami i przekaże go do utrzymania, zobacz, jak pracujemy w tworzeniu oprogramowania na zamówienie, albo umów rozmowę, na której przejdziemy przez Twój brief i powiemy, czego jeszcze brakuje, żeby pierwszy etap dał odpowiedź, a nie kolejne pytania.