Testy modeli w warunkach przemysłowych: drift, zmiana partii materiału i sezonowość

Dlaczego model „idealny na papierze” przegrywa z halą produkcyjną

Kontrast między POC a rzeczywistością linii produkcyjnej

Na etapie POC wszystko wygląda elegancko: przygotowany, wyczyszczony dataset, usunięte braki danych, odrzucone „dziwne” rekordy, stabilny rozkład zmiennych. Model ma świetne metryki, ładne wykresy, kierownictwo zadowolone. Problem pojawia się, gdy ten sam model trafia na halę produkcyjną, gdzie proces żyje własnym życiem, a dane nie przejmują się wcale tym, że „tak było w train secie”.

Na produkcji pojawiają się całe klasy zdarzeń, których zwykle nie ma w POC: przejścia między partiami materiału, awarie czujników, drobne obejścia procedur przez operatorów, eksperymentalne zmiany receptur „na szybko”. Model stworzony na uporządkowanych danych nagle widzi zupełnie inny świat niż w czasie trenowania i walidacji offline. W efekcie predykcje stają się niestabilne, a zaufanie operatorów spada błyskawicznie, nawet przy obiektywnie dobrej średniej jakości.

W testach w warunkach przemysłowych kluczowe jest przejście z logiki „dopasujmy model do tego zbioru danych” do logiki „sprawdźmy, czy model przetrwa zderzenie z pełnym chaosem procesu”. Oznacza to m.in. świadome wystawienie modelu na sezonowość, zmiany partii materiału, różne zmiany produkcyjne i nietypowe sytuacje, a nie tylko na „ładny kawałek historii”, w którym wszystko szło zgodnie z planem.

Specyfika danych przemysłowych: szum, błędy i rzadkie zdarzenia

Dane przemysłowe są na ogół:

• szumne – odczyty z czujników drgają, kalibracje są nieidealne, pojawiają się piki i „dziury” w serii czasowej,
• niekompletne – braki pomiarów, brakujący kontekst (np. brak zapisanego numeru partii albo zmiany ustawień maszyny),
• asynchroniczne – różne systemy (MES, SCADA, ERP) mają inne zegary, inne częstotliwości próbkowania, opóźnienia w księgowaniu zdarzeń,
• skażone rzadkimi, ale krytycznymi zdarzeniami – awarie, przestoje, rozruchy po remoncie, próby nowych receptur.

Tymczasem wiele klasycznych podejść do modelowania zakłada mniej lub bardziej stabilny proces. Na produkcji to luksus, który zdarza się wyłącznie na slajdach. W testach modeli w warunkach przemysłowych trzeba więc planować świadome „wystawienie” modelu na te wszystkie trudne fragmenty danych, a nie odfiltrowywać je jako „odstające przypadki”. To właśnie one zwykle generują największe ryzyko kosztów: złe partie, awarie, nadmierny scrap.

Rola zmiany partii materiału, operatorów, ustawień maszyn i sezonu

Model predykcyjny „widzi” głównie liczby. Tymczasem proces przemysłowy żyje w cyklach i zdarzeniach dyskretnych, które w surowych logach nie zawsze są czytelne. Z punktu widzenia testów modeli szczególnie istotne są:

• zmiany partii materiału – inne dostawy tej samej stali, granulatu, chemikaliów czy półfabrykatów potrafią mieć subtelne różnice w tolerancjach. Dla technologów „to jest w normie”, ale dla modelu to już inny rozkład zmiennych wejściowych;
• zmiany operatorów i zmian roboczych – inny sposób regulacji, inne reakcje na alarmy, różne nawyki przy przezbrajaniu. Dane z nocnej zmiany potrafią wyglądać inaczej niż z dziennej, choć „teoretycznie” proces jest ten sam;
• modyfikacje ustawień maszyn – drobna zmiana parametrów PID, ciśnień, temperatur czy prędkości przesuwu, wprowadzona przy okazji serwisu, potrafi istotnie zmienić charakterystykę procesu;
• sezonowość – temperatura i wilgotność otoczenia, inne profile zamówień, okresy wzmożonej produkcji lub pracy na obniżonej obsadzie.

Jeżeli w danych nie ma czytelnych znaczników tych zdarzeń (ID partii, ID operatora, ID zmiany, wersja receptury, data serwisu maszyny), model uczy się „średniej” rzeczywistości. A potem przegrywa w momencie, gdy trafi na sekwencję, której w danych treningowych po prostu nie było lub była zbyt słabo reprezentowana.

Cel testów w warunkach przemysłowych: odporność zamiast ładnych metryk

Testy modeli w warunkach przemysłowych mają inny nadrzędny cel niż typowe zadania akademickie. Nie chodzi o to, by wycisnąć jeszcze 0,5% lepsze R² czy accuracy, lecz o to, by:

• model utrzymywał stabilną jakość w czasie,
• był odporny na typowe zmiany: partie materiału, sezonowość, drobne modyfikacje procesu,
• dało się przewidzieć, kiedy i dlaczego jego jakość zacznie spadać,
• mieć operacyjne procedury reagowania na spadek jakości i drift danych.

Testy w warunkach przemysłowych służą więc zbudowaniu zaufania, że model można włączyć w realne decyzje (np. sterowanie recepturą, selekcją jakościową, planowaniem konserwacji) bez obaw, że nagle zacznie podejmować absurdalne decyzje po zmianie dostawcy surowca lub w upalne lato. Ładne metryki z POC są jedynie biletem wstępu do dalszej, znacznie trudniejszej części pracy.

Kluczowe pojęcia: drift, zmiana partii, sezonowość – co jest czym

Data drift i concept drift na przykładach z produkcji

W testach modeli w warunkach przemysłowych nie da się uciec od pojęcia driftu. Podstawowe dwa typy to:

• data drift – zmienia się rozkład zmiennych wejściowych,
• concept drift – zmienia się sama zależność między wejściem a wyjściem.

Przykład z predykcji jakości wyrobu: model uczy się na danych z okresu, gdy stal miała określony rozkład twardości i zawartości domieszek. Po zmianie dostawcy ta sama etykieta gatunku niby zostaje, ale parametry mikroskopowe surowca przesuwają się. To typowy data drift: te same cechy (temperatura, ciśnienie, czasy) mają inne typowe wartości i korelacje. Jeśli jednak technologia jest „twarda” i wynik jakości wciąż zależy od tych zmiennych podobnie jak wcześniej, model często sobie poradzi po lekkiej kalibracji lub re-treningu.

Inna sytuacja: po modernizacji linii skrócony zostaje czas przebywania produktu w piecu, a zastosowane nowe palniki zmieniają profil nagrzewania. Te same zmienne wejściowe przestają w ten sam sposób przekładać się na wynik jakości. To już concept drift. Sam rozkład danych wejściowych może nawet wyglądać podobnie, ale „fizyka procesu” i realny związek przyczynowo-skutkowy są inne.

Przy predykcji awarii jest podobnie. Data drift może się objawić zmianą zakresów wibracji ze względu na inny rodzaj łożysk, inne smary, inne obciążenia. Concept drift pojawia się np. po wymianie całego podzespołu na nowszą konstrukcję – to już w praktyce inna maszyna, a związek między sygnałem a awarią nie jest ten sam.

Zmiana partii materiału – jak wygląda operacyjnie i w danych

Zmiana partii materiału to dla technologa codzienność, a dla modelu – nagła zmiana „świata”, w którym działa. Operacyjnie oznacza to zwykle:

• dostawę nowej partii surowca od tego samego lub innego dostawcy,
• inną kombinację parametrów w ramach tolerancji normy (gęstość, wilgotność, skład chemiczny, lepkość),
• czasem również inną specyfikację produktu końcowego, choć formalnie nadal w tej samej klasie jakości.

W danych taka zmiana objawia się przesunięciem rozkładów cech wejściowych. Na przykład:

• ciśnienia lub temperatury wymagane do osiągnięcia tej samej jakości zmieniają się systematycznie,
• czas dojścia do stanu ustalonego po rozruchu partii jest inny,
• statystyki procesu (średnie, odchylenia, korelacje) „przestawiają się” na nowe poziomy.

Jeśli numer partii jest poprawnie rejestrowany i przenoszony do danych modelu, można testować model osobno na każdej partii i budować obraz jego stabilności między partiami. Jeśli numer partii ginie gdzieś między ERP a SCADA, model miesza wszystko w jedną pulę i data drift jest niewidoczny aż do chwili, gdy jakość predykcji zaczyna nagle spadać.

Sezonowość w procesach przemysłowych

Sezonowość w przemyśle bywa mniej oczywista niż w sprzedaży detalicznej, ale jest równie dokuczliwa dla modeli. Źródła sezonowości to m.in.:

• warunki otoczenia – temperatura i wilgotność powietrza, różnice między latem a zimą, wpływ na schładzanie, wysychanie, lepkość;
• zapotrzebowanie i obciążenie – inne profile zamówień w sezonie wysokim, praca na trzy zmiany vs jedna, częstsze przezbrojenia;
• kampanie produktowe – w określonych okresach roku produkowane są inne mieszanki, formaty, warianty;
• obsady i kompetencje – w sezonie urlopowym inne składy zespołów, częściej zastępstwa, większa liczba „nowych” operatorów.

Model trenowany wyłącznie na danych z jesieni może mieć bardzo przyzwoite wyniki – aż do chwili, gdy przyjdzie gorące lato lub bardzo mroźna zima. W testach trzeba więc planować okresy walidacji tak, aby objąć pełen cykl sezonowy, albo przynajmniej symulować typowe zmiany (np. na danych z poprzedniego roku).

Jak drift, partie i sezonowość mieszają się ze sobą

Największą trudnością w testach modeli w warunkach przemysłowych jest to, że większość zjawisk nakłada się na siebie. Spadek jakości modelu może wynikać z:

• zmiany partii materiału,
• ostrej zimy, która zmienia warunki chłodzenia,
• niedawnej zmiany ustawień sterownika PID,
• zmiany operatorów na linii,
• przebudowy fragmentu linii lub serwisu kluczowej maszyny,
• wreszcie – naturalnego starzenia się samego modelu (concept drift).

Bez dobrze przygotowanych danych kontekstowych i przemyślanych testów trudno rozdzielić przyczyny. Efekt jest taki, że każdy patrzy na ten sam wykres inaczej: utrzymanie ruchu wini maszynę, jakość – surowiec, data science – brak retrainu modelu, a produkcja – operatorów. Solidnie zaprojektowane testy z monitorowaniem driftu oraz oznaczaniem partii i zmian procesowych pozwalają rozwiązać ten spór na liczbach, a nie na przeczuciach.

Jak przygotować dane i proces, żeby w ogóle dało się testować modele

Identyfikacja i oznaczanie partii materiału oraz zmian technologicznych

Bez mocnych fundamentów danych testowanie modeli w warunkach przemysłowych staje się sztuką wróżenia z wykresów. Kluczowe jest zbudowanie ciągu identyfikacyjnego od dostawy surowca, przez kolejne etapy produkcji, aż po gotowy wyrób i jego wynik jakościowy. To oznacza co najmniej:

• nadawanie jednoznacznego ID partii materiału w systemie ERP/MES,
• przenoszenie tego ID przez wszystkie istotne etapy procesu (także przy łączeniu partii, mieszaniu, rozcieńczaniu),
• oznaczanie w danych kluczowych zmian technologicznych: nowe receptury, nowe parametry sterowania, modyfikacje PLC, nowe wersje oprogramowania.

Na etapie testowania modeli ma to prosty, ale krytyczny efekt: można porównać jakość predykcji między partiami, między wersjami receptury, między okresami „przed” i „po” zmianie procesu. Bez takich oznaczeń każda analiza dryfu jest spekulacją.

Porządna oś czasu: synchronizacja czujników, logów i zdarzeń

Modele predykcyjne w przemyśle są w większości oparte o dane czasowe. Aby testy miały w ogóle sens, potrzebna jest spójna oś czasu:

• zegar systemu MES, SCADA i ERP zsynchronizowany (NTP, kontrola dryfu zegarów),
• ustalone zasady mapowania danych o różnej częstotliwości (np. pomiary co sekundę vs zdarzenia produkcyjne co kilka minut),
• konsekwentne oznaczanie czasu zdarzeń „stanowych” – kiedy naprawdę nastąpił start partii, kiedy zakończenie, kiedy zmiana ustawień.

Przykładowy problem: system jakości zapisuje wynik testu produktu z dokładnością do daty i godziny, MES loguje przejazd przez linię z dokładnością do sekundy, a SCADA ma opóźnienia przy buforowaniu danych. Bez właściwej synchronizacji model uczy się błędnych zależności, a późniejsze testy nie wykryją driftu we właściwym momencie, bo predykcje i wyniki są przesunięte w czasie.

Tagowanie zdarzeń specjalnych: awarie, przestoje, eksperymenty

Większość systemów przemysłowych loguje awarie, alarmy, przestoje. Dużo rzadziej loguje się w sposób używalny dla modeli:

• eksperymentalne zmiany ustawień (np. test nowej receptury na 3 godzinach produkcji),
• próbne partie, które z założenia są „testowe”,
• rozruchy po dłuższym postoju lub remoncie,

Filtrowanie i czyszczenie danych operacyjnych pod testy modeli

Surowe dane z hali produkcyjnej są jak nieprzesiane kruszywo: niby można coś z tego zbudować, ale najpierw trzeba odsiać większe kamienie. Żeby testy modeli faktycznie mówiły coś o zachowaniu procesu, a nie o bałaganie w logach, potrzebne są spójne zasady przygotowania danych operacyjnych.

Podstawowe kroki to zwykle:

• wycięcie okresów „nienormalnej” pracy – rozruchy po postoju, awarie, tryb ręczny, jazda „na sucho”,
• oznaczanie i obsługa braków danych – rozróżnienie między „nie mierzyliśmy” a „mierzyliśmy, ale wynik był błędny”,
• usuwanie lub flagowanie oczywistych artefaktów – skoki temperatury z powodu restartu czujnika, pojedyncze szpilki wibracji,
• normalizacja formatu jednostek i etykiet – co w jednym systemie jest °C, w drugim bywa surową wartością z przetwornika.

Błędem jest całkowite wyrzucanie wszystkiego, co „dziwne”. Te same dane, które przeszkadzają w trenowaniu modelu, mogą być kluczowe do zrozumienia, dlaczego w pewnych warunkach predykcje nagle się rozjeżdżają. Rozsądny kompromis to:

• budowanie zestawu „core” do trenowania (stabilna praca, przewidywalny proces),
• utrzymanie równoległego zestawu „edge cases” (rozruchy, mocne zakłócenia) do stres-testów i analizy odporności modelu.

Definiowanie „jednostki predykcji”: sztuka łączenia danych procesowych z wynikiem

Kluczowa decyzja, która później rzutuje na wszystkie testy, to określenie, czym w ogóle jest pojedynczy przypadek dla modelu. W zależności od procesu może to być:

• pojedynczy wyrób (butelka, arkusz blachy, partia tabletki),
• określone okno czasowe (np. 10 minut pracy młyna),
• cały cykl maszyny (jeden wtrysk, jedno napełnienie, jeden wsad pieca).

Dopiero po ustaleniu tej jednostki da się sensownie:

• agregować dane z czujników (średnie, odchylenia, min/max w ramach cyklu lub okna),
• powiązać wynik jakościowy lub informację o awarii z odpowiednią porcją historii procesu,
• zaplanować, jak później będzie raportowana skuteczność modelu (na sztukę, na cykl, na godzinę).

Przykład: w piecu tunelowym każda tacka produktu jedzie przez kilkadziesiąt minut i „widzi” różne strefy grzania. Jeśli model ma przewidywać jakość tacki na wyjściu, potrzebne jest sensowne zdefiniowanie, które sygnały z których stref i w jakim momencie przypisujemy do tej konkretnej tacki. Bez tego testy modeli pokazują głównie to, jak bardzo przypadkowo sparowaliśmy dane.

Rozdzielenie danych na zbiory: czas, partie, zmiany procesu

W przemysłowych wdrożeniach klasyczny podział na train/validation/test „po prostu losowo” rzadko ma sens. Bardziej naturalne są podziały:

• czasowe – trenowanie na starszych okresach, test na nowszych (symulacja realnego starzenia się modelu),
• po partiach – trenowanie na wybranych partiach surowca, test na innych (sprawdzenie odporności między partiami),
• po zmianach procesu – osobne zbiory „przed” i „po” modernizacji linii, wymianie kluczowego urządzenia czy zmianie receptury.

Dobrym podejściem jest skonstruowanie kilku równoległych podziałów i utrzymywanie ich jako standardu testowego. Ten sam model można wtedy:

• ocenić na osi czasu (jak szybko „się starzeje”),
• sprawdzić na poziomie między-partiowym (czy nie jest „przyuczony” do jednego dostawcy),
• porównać w różnych reżimach procesu (np. stary i nowy piec).

Technicznie przydają się tu stabilne definicje splitów: przechowywanie list identyfikatorów partii, zakresów dat, wersji receptur, które definiują poszczególne zbiory. Bez tego każda iteracja projektu ma „trochę inny” zbiór testowy i dyskusje o poprawie modelu przypominają spór o to, kto kręcił termostatem.

Projektowanie eksperymentów i testów: od POC do warunków produkcyjnych

Etap POC: czy to w ogóle ma sens dla tego procesu

Na samym początku nie chodzi o dopieszczanie modelu, tylko o odpowiedź na pytanie: czy na dostępnych sygnałach da się w ogóle stabilnie przewidywać interesujące nas zjawisko. W fazie POC:

• pracuje się zwykle na historycznych danych,
• sprawdza się kilka prostych wariantów cech (agregacje, przesunięcia czasowe, podstawowe transformacje),
• testuje się podstawowe architektury modeli (drzewa, proste sieci, regresje regularizowane).

Na tym etapie bardziej niż o 2% różnicy w MSE chodzi o odpowiedź na parę pragmatycznych pytań:

• czy model jest lepszy niż obecna praktyka (np. stałe nastawy, prosta reguła heurystyczna),
• czy działa podobnie dobrze w różnych okresach czasu, a nie tylko na jednym „ładnym” fragmencie danych,
• czy istnieją typowe scenariusze, w których zawodzi – i czy jesteśmy z tym w stanie żyć.

Do POC nie trzeba wciągać całej fabryki. Wystarczy wąski zespół technologa, osoby od danych i po jednym przedstawicielu produkcji/utrzymania ruchu, który powie, czy wynik ma sens operacyjny. Lepiej zatrzymać projekt na tym etapie, niż później walczyć z modelem, który w laboratorium działał, ale w realu nie pomaga nikomu.

Pilotaż na żywym procesie: testy „shadow mode”

Kolejny krok to uruchomienie modelu na żywym strumieniu danych, lecz bez wpływu na sterowanie. Model działa „w cieniu”:

• na bieżąco przetwarza sygnały z linii,
• generuje prognozy lub rekomendacje,
• jego wyjścia są logowane i porównywane z rzeczywistymi wynikami procesu,
• operatorzy mogą je ewentualnie obserwować, ale nie są nimi związani.

„Shadow mode” ma kilka zalet:

• pozwala przetestować integrację i stabilność modelu (opóźnienia, braki danych, awarie sieci),
• ujawnia prawdziwy profil błędów – nie tylko średnie metryki, ale też pojedyncze spektakularne pomyłki,
• daje czas na oswojenie operatorów z nowym narzędziem bez presji, że „teraz już wszystko steruje algorytm”.

W pilotażu szczególnie istotne jest monitorowanie:

• driftu danych wejściowych (czy pilot nie odbywa się akurat na wyjątkowo spokojnym okresie procesu),
• różnic sezonowych (czy udało się zahaczyć o różne temperatury otoczenia, różne zmiany),
• zachowania modelu na nowych partiach materiału w porównaniu z tymi, na których był trenowany.

Eksperymenty A/B na hali: kiedy są możliwe, a kiedy są iluzją

Koncepcja testu A/B z e‑commerce kusi: „na jednej linii stary sposób, na drugiej linia z modelem, porównamy wyniki”. W praktyce przemysłowej pełnowartościowy A/B jest trudny, ale nie niemożliwy. Sens ma tam, gdzie:

• istnieją bliźniacze linie lub gniazda o bardzo zbliżonej konfiguracji,
• można rozdzielić partie materiału w miarę równomiernie między warianty,
• warunki zewnętrzne (np. temperatura hali) są podobne.

Jeśli takich warunków nie ma, lepiej zaplanować eksperyment w czasie:

• okres bazowy (np. 4 tygodnie bez modelu, ale z pełnym logowaniem),
• okres z modelem w trybie rekomendacji (operator może przyjąć/odrzucić),
• okres z mocniejszą integracją (np. domyślne nastawy z modelu z możliwością korekty).

Kluczowe jest zdefiniowanie metryk biznesowych jeszcze przed startem eksperymentu: mniej braków, mniejsze zużycie energii, stabilniejszy czas cyklu, mniej nieplanowanych przestojów. Bez tego łatwo o sytuację, w której każdy widzi to, co chce: jakość mówi, że jest lepiej, produkcja – że gorzej, a finansowy, że „nic się nie zmieniło”.

Bezpieczeństwo i „ramy zaufania” dla modelu

Nawet najlepszy model nie powinien mieć pełnej swobody. Potrzebne są ramy zaufania, w których może działać:

• określone zakresy wartości, w których model może proponować nastawy (np. nie przekracza limitów technologicznych),
• warunki, przy których model się automatycznie wyłącza (np. awaria kluczowego czujnika, rozruch po długim postoju),
• monitorowanie, czy aktualne dane wejściowe nie wychodzą poza „obszar znany z treningu”.

Dobrym nawykiem jest wdrożenie prostych sygnałów stanu:

• zielony – model pracuje w znanym zakresie, wyniki można traktować jako wiarygodne,
• żółty – silny drift lub dane spoza typowego obszaru, wynik wymaga wzmożonej czujności,
• czerwony – model wyłączony, decyzje według standardowych procedur.

Takie „sygnalizacje” są równie ważne dla testów, jak i dla stałej eksploatacji: pozwalają powiązać spadki jakości predykcji z konkretnymi warunkami i nie winić modelu za to, że ktoś właśnie wymienił pół instalacji bez słowa.

Metryki jakości modelu w przemyśle: nie tylko MSE i accuracy

Metryki biznesowe i procesowe jako punkt odniesienia

Klasyczne metryki typu MSE, MAE czy accuracy mówią, jak model radzi sobie statystycznie. Na hali liczy się jednak, czy:

• jest mniej braków (odsetek sztuk niezgodnych z wymaganiami),
• spada liczba reklamacji i zwrotów,
• maleje zużycie mediów (energię i gaz widać najlepiej na fakturach),
• zwiększa się dostępność linii (mniej nieplanowanych postojów),
• stabilizuje się czas cyklu i przepustowość.

Na etapie testów warto więc zbudować prostą mapę przełożenia:

• „tyle a tyle błędu MAE” przekłada się średnio na „tyle a tyle odchyłki temperatury pieca”,
• co z kolei przekłada się na „taki a taki wzrost/spadek ryzyka braków”.

Bez takiego mostu łatwo wpaść w pułapkę „polowania na promile MSE”, które w praktyce niczego nie zmieniają poza slajdami w prezentacji.

Metryki asymetryczne: koszt pomyłek w jedną i drugą stronę

W wielu zastosowaniach przemysłowych błąd w jedną stronę jest dużo groźniejszy niż w drugą. Przykłady:

• zbyt niska prognoza temperatury topienia może skutkować niedotopieniem wsadu; zbyt wysoka – „tylko” nieco wyższym zużyciem energii,
• zbyt optymistyczna prognoza czasu do awarii może skończyć się zatrzymaniem linii; zbyt konserwatywna – nadmiarem planowych przestojów.

W testach dobrze więc stosować:

• ważone metryki błędu – większa kara za błąd „w złą stronę”,
• analizę rozkładu znaków błędu (czy model systematycznie zawyża, czy zaniża),
• krzywe kosztu, które pokazują, jak błąd przekłada się na realne skutki (koszt braków, przestojów, energii).

Z życia: w jednej z hut prosty zabieg przesunięcia prognozy o stały margines bezpieczeństwa w „bezpieczną stronę” dał większy efekt biznesowy niż sześć miesięcy cyzelowania architektury modelu.

Stabilność w czasie i między partiami jako osobna metryka

Średnia jakość modelu po zsumowaniu wszystkiego do jednego numerka bywa myląca. Dużo ciekawsze jest:

• jak jakość zmienia się w czasie – czy jest trend spadkowy, sezony gorszych wyników, okresy po zmianach procesu,
• jak jakość różni się między partiami – czy są dostawcy, na których model wyraźnie „siada”,
• jak model reaguje na nowe klasy produktów lub warianty receptur.

Można wprowadzić proste metryki typu:

Rozkładowe i „robust” metryki jakości

Przy modelach działających na procesach ciągłych lub wsadowych pojedyncza średnia metryka zaciera to, co najciekawsze – ogony rozkładu błędu. Zamiast patrzeć tylko na MSE, dobrze jest śledzić:

• percentyle błędu (np. 50., 90., 95.) – pokazują, jak wygląda typowy błąd i jak często zdarzają się duże odchylenia,
• maksymalne odchylenia na zmianę lub partię – czy zdarzają się pojedyncze „katastrofalne” predykcje,
• metryki odporniejsze na outliery (mediana błędu, medianowa absolutna odchyłka).

Prosty wykres „błąd 95. percentyla w funkcji czasu” bywa bardziej użyteczny dla utrzymania ruchu niż trzy miejsca po przecinku w MSE. Pokazuje bowiem, czy rośnie liczba sytuacji, w których model się „gubi”, nawet jeśli przeciętnie wszystko wygląda dobrze.

Metryki dla modeli sterujących vs. monitorujących

Inaczej ocenia się model, który ustawia nastawy, a inaczej ten, który tylko sygnalizuje stan procesu:

• dla modeli sterujących ważna jest stabilność i płynność – czy model nie „miota” nastawami, nie generuje nadmiernej liczby korekt,
• dla modeli monitorujących (np. detekcja anomalii) kluczowe są czułość i precyzja alarmów – ile fałszywych alarmów generuje, a ile faktycznych zdarzeń przeocza.

Dobrą praktyką jest liczenie metryk w dwóch przestrzeniach:

• przestrzeń predykcji – MAE, RMSE, AUC itp.,
• przestrzeń decyzji – ile „kliknięć” operatora oszczędził model, ile interwencji rzeczywiście skróciło postój, ile razy algorytm zasugerował zmianę, którą człowiek i tak by wprowadził.

Bez tej drugiej grupy metryk łatwo stworzyć model „ładny statystycznie”, który w praktyce służy jedynie jako kolorowy wykres na ścianie dyspozytorni.

Wykrywanie i mierzenie dryfu danych w praktyce

Rodzaje dryfu: nie tylko przesunięcie średniej

Pod hasłem „drift” kryje się kilka różnych zjawisk:

• drift rozkładu wejść (data drift) – zmieniają się wartości i rozkłady cech wejściowych (np. wilgotność wsadu, parametry z czujników),
• drift relacji wejście‑wyjście (concept drift) – przy tych samych sygnałach wejściowych proces zaczyna reagować inaczej (np. po modernizacji pieca),
• drift etykiet – zmienia się sposób pomiaru lub oceny jakości (inne normy, inne granice tolerancji).

W testach nie wystarczy stwierdzić, że „model się postarzał”. Trzeba wiedzieć, co się zestarzało: dane, proces, czy sposób mierzenia celu. Od tego zależy, czy wystarczy ponowne trenowanie, czy konieczna jest zmiana architektury, a może po prostu kalibracja czujnika.

Proste wskaźniki dryfu, które da się liczyć na hali

Nie zawsze jest czas i zasoby na zaawansowane testy statystyczne. W praktyce dobrze sprawdzają się proste, regularnie liczone wskaźniki:

• porównanie statystyk okien czasowych – średnie, odchylenia, percentyle cech z ostatniego tygodnia vs. ostatniego kwartału,
• monitorowanie „range coverage” – jaki odsetek aktualnych danych wpada w zakres min–max z okresu treningowego,
• udział punktów spoza „chmury treningowej” – np. liczba obserwacji o odległości Mahalanobisa powyżej zadanego progu.

Tego typu wskaźniki można łatwo zautomatyzować w systemie raportowym. Gdy przekroczą ustalone progi, model dostaje „żółte światło”, co jest sygnałem do przeglądu danych i ewentualnego dociągnięcia treningu.

Testy statystyczne i miary podobieństwa rozkładów

Tam, gdzie jest więcej czasu i wsparcia analitycznego, można wprowadzić:

• testy zgodności rozkładów (np. Kolmogorov‑Smirnov dla cech ciągłych, chi‑kwadrat dla kategorycznych),
• metryki odległości rozkładów (np. odległość Kullbacka‑Leiblera, Wassersteina),
• PSI – Population Stability Index, szeroko stosowany w finansach, ale dobrze działający także na rozkładach przemysłowych.

Sensowne jest połączenie kilku miar w syntetyczny indeks dryfu liczony per cecha lub grupa cech (np. „wskaźnik dryfu materiału wsadowego”). Pozwala to szybko zorientować się, czy problemem jest konkretna część procesu, czy całość „odpłynęła”.

Dryf a sezonowość: jak ich nie mylić

W wielu zakładach istnieje silna sezonowość – zmiany temperatury otoczenia, inne mieszanki surowców w zależności od pory roku, zmienne obłożenie zamówieniami. Modele widziały to na danych historycznych, więc nagły alarm „dryf!” z powodu nadejścia zimy jest tylko hałasem.

Żeby tego uniknąć:

• porównuje się rozkłady z analogicznych okresów – np. obecny luty vs. luty rok wcześniej, a nie vs. sierpień,
• tworzy się sezonowe profile referencyjne – osobne „normy” dla lata, zimy, okresu urlopowego,
• oznacza się w danych okresy specjalne (remonty, rozruchy, duże zmiany receptur), których nie traktuje się jako typowych punktów odniesienia.

Jeżeli indeks dryfu rośnie tylko w pewnych sezonach, a model zachowuje stabilność metryk jakości, nie ma powodu do paniki. Gdy jednak rośnie poza typową sezonowością i jednocześnie pogarsza się jakość predykcji – to mocny sygnał do działania.

Dryf etykiet i „ruchomy cel”

Szczególnie zdradliwy jest dryf etykiet, czyli zmiany w tym, co uznajemy za jakość. Przykłady z praktyki:

• zaostrzenie norm jakości – produkt, który rok temu był „OK”, dziś trafia do braków,
• zmiana metody pomiaru – inny typ sondy, nowe laboratorium, nowa metoda analityczna,
• zmiana klasyfikacji braków – to, co kiedyś było „drobna wada”, staje się „brak krytyczny”.

W testach modeli trzeba rejestrować wersję definicji jakości i wersję aparatury pomiarowej. Bez tego porównywanie wyników sprzed i po zmianie ma tyle sensu, co porównywanie prędkości produkcji w sztukach na godzinę i kilogramach na minutę.

Specyfika zmiany partii materiału: jak testować model „na nowych partiach”

Dlaczego partia partii nierówna

Zmiana partii materiału to klasyczny moment, w którym modele „przemysłowe” pokazują swoje słabości. Surowiec od innego dostawcy, inna kopalnia, inny skład chemiczny lub rozkład ziarnistości – i nagle cały misterny plan idzie w… korektę nastaw przez doświadczonego operatora.

Kluczowy problem: model widział w treningu ograniczony przekrój partii, często zdominowanych przez stałych dostawców. W testach trzeba więc zadbać o to, by:

• sprawdzić zachowanie modelu na partiach skrajnych (najgorsza i najlepsza jakość, inny profil wilgotności, inne domieszki),
• osobno monitorować jakość dla różnych dostawców i kopalni/rafinerii/huty wejściowej,
• analizować stabilność w obrębie jednej partii vs. różnice między partiami.

Tagowanie partii i łączenie danych z laboratorium

Bez poprawnego powiązania numeru partii z danymi procesowymi testy modeli są w zasadzie loterią. Potrzebne jest spójne:

• oznaczanie partii na wejściu (ERP, MES, system magazynowy),
• przenoszenie identyfikatora partii na kolejne etapy procesu,
• łączenie wyników laboratoryjnych (skład, wilgotność, parametry fizykochemiczne) z przebiegiem partii na linii.

Dopiero wtedy da się policzyć:

• jaką wariancję błędu wnosi różnica między partiami,
• czy model nie „nauczył się” w praktyce rozpoznawać konkretnych dostawców zamiast praw fizyki,
• jak szybko trzeba go doadaptowywać po wejściu nowego źródła surowca.

Testy „partia po partii” przed pełnym wdrożeniem

Nie ma sensu rzucać modelu od razu na wszystkie partie z całego świata. Rozsądniejsze podejście to sekwencja:

1. Partie referencyjne – kilka typowych partii z głównego źródła, dla których wiemy, że proces jest stabilny. Tu weryfikuje się, czy model zachowuje się przynajmniej tak dobrze, jak w POC.
2. Partie skrajne, ale znane – np. surowiec gorszej jakości, ale z wieloletniej współpracy. Chodzi o sprawdzenie, czy model nie „gubi się” przy granicach specyfikacji.
3. Nowi dostawcy / nowe źródła – testowane najpierw w trybie shadow mode, z dodatkowym nadzorem technologów. W tym kroku szczególnie ważny jest szybki feedback z hali.

Po każdej z tych faz aktualizuje się macierz ryzyka partii: dla których kombinacji surowiec‑dostawca‑receptura model jest „zielony”, dla których „żółty”, a gdzie w ogóle nie powinien decydować samodzielnie.

Cechy opisujące partię: ile „chemii” wpuścić do modelu

Kuszące jest wrzucenie do modelu wszystkich parametrów z laboratorium: pełnych analiz chemicznych, granulometrii, modułu sprężystości, gęstości nasypowej i jeszcze kilku stron tabel. Potem okazuje się, że:

• połowa parametrów jest mierzona nieregularnie,
• część ma duże opóźnienie (wyniki po 24 godzinach),
• inne są silnie skorelowane lub w ogóle nieinformacyjne dla danego procesu.

W testach warto zacząć od:

• niewielkiego, stabilnego zestawu cech, które są mierzone zawsze i w tym samym standardzie,
• systematycznej oceny ważności cech (feature importance, SHAP) pod kątem tego, czy model naprawdę „używa” informacji o partii,
• analizy scenariusza „no‑lab” – jak model działa, gdy z przyczyn organizacyjnych nie ma jeszcze pełnych wyników laboratoryjnych.

Często dobrym kompromisem jest dwustopniowy schemat: model wstępny działa tylko na prostych cechach (np. danych on‑line i podstawowych właściwościach partii), a po otrzymaniu pełnych wyników z laboratorium następuje delikatna korekta nastaw albo prognoz.

Modele adaptacyjne i osobne „profile” dla partii

Tam, gdzie zmienność partii jest duża i nieunikniona, opłaca się podejście bardziej elastyczne niż jeden „święty” model na wszystko. Kilka wariantów:

• modele per klaster partii – grupowanie partii o podobnych parametrach (np. składu chemicznego), a potem osobny model dla każdego klastra,
• modele z cechami interakcyjnymi – dodanie do cech interakcji typu „skład × temperatura otoczenia”, by model mógł uczyć się specyficznych zachowań dla danej kombinacji warunków,
• online learning dla wybranych parametrów – delikatne dostrajanie modelu na świeżych danych, z mechanizmami zabezpieczającymi przed „zepsuciem” go pojedynczą złą partią.

Trzeba tylko jasno rozdzielić:

• okresy uczenia – kiedy model może się aktualizować,
• okresy walidacji – kiedy zbiera się dane bez adaptacji, żeby móc rzetelnie ocenić wpływ dryfu i nowych partii na jakość.

Partie jako naturalna jednostka eksperymentu

W warunkach przemysłowych trudno jest przeprowadzić „idealny” eksperyment losowy. Partie materiału dają jednak naturalną jednostkę, wokół której można zaprojektować sensowny test:

• na części partii stosuje się zalecenia modelu, na części – procedurę standardową,
• przy każdej partii dokumentuje się warunki brzegowe (zmiany, remonty, problemy logistyczne),
• porównuje się wyniki jakościowe i procesowe między partiami w porównywalnych warunkach.

Takie eksperymenty są mniej „czyste” niż A/B w e‑commerce, ale i tak pozwalają odpowiedzieć na kluczowe pytanie: czy dla tego typu partii model przynosi korzyść, czy wręcz przeciwnie – wymaga ciągłego ratowania przez operatorów.

Co robić, gdy nowa partia „wywraca stół”

Najczęściej zadawane pytania (FAQ)

Co to jest drift modelu w warunkach przemysłowych i jak się objawia?

Drift to zmiana warunków, w których działa model, względem tego, co widział podczas trenowania. W praktyce produkcyjnej najczęściej chodzi o data drift (inne rozkłady zmiennych wejściowych, np. inne typowe temperatury, ciśnienia, składy surowca) oraz concept drift (zmienia się sama zależność między wejściem a wyjściem, np. po modernizacji linii czy zmianie technologii).

Objawy driftu to między innymi nagłe pogorszenie jakości predykcji, wzrost odchyleń, „dziwne” rekomendacje modelu po wdrożeniu nowej partii materiału, po remoncie lub w innym sezonie. Na wykresach widać np. przesunięcia średnich, inne korelacje, a w logach – rosnącą liczbę korekt ręcznych ze strony operatorów.

Dlaczego model z dobrym wynikiem w POC zawodzi na hali produkcyjnej?

Model tworzony w POC uczy się zwykle na „wygładzonym” fragmencie historii: dane są wyczyszczone, braki uzupełnione, a nietypowe przypadki odrzucone jako „outliery”. Na produkcji proces jest znacznie bardziej chaotyczny: zmieniają się partie materiału, operatorzy, ustawienia maszyn, pojawiają się awarie i rozruchy, a czujniki gubią pomiary.

Jeśli w POC nie wystawiono modelu na takie sytuacje, to po wdrożeniu widzi on zupełnie inny świat niż w treningu. Metryki z testu offline wyglądają świetnie, ale w realnym czasie rzeczywistym rośnie rozrzut predykcji, pojawiają się skrajne błędy, a operatorzy szybko tracą zaufanie i wracają do „ręcznego sterowania”.

Jak testować model pod kątem zmiany partii materiału?

Podstawą jest poprawne śledzenie partii w danych: numer partii surowca musi być widoczny w logach, połączony z danymi procesowymi i danymi jakościowymi. Bez tego model miesza różne partie w jedną pulę i nie pokaże, że na nowej partii zachowuje się wyraźnie gorzej.

Praktyczne podejście to między innymi:

• ocena jakości modelu osobno dla każdej partii (lub grup partii),
• porównywanie rozkładów zmiennych wejściowych między partiami,
• testowanie, czy parametry procesu potrzebne do osiągnięcia tej samej jakości przesuwają się po zmianie partii.

Jeśli po przejściu na nową partię wskaźniki błędu rosną, a rozkład zmiennych się zmienia, to sygnał, że model wymaga kalibracji lub osobnej logiki dla różnych dostaw/partii.

Jak w praktyce uwzględnić sezonowość w testach modeli przemysłowych?

Sezonowość w przemyśle to nie tylko lato–zima. Dochodzą do tego zmiany profilu zamówień, inne obciążenie linii, różne obsady zmian czy warunki otoczenia (temperatura, wilgotność). Model powinien być testowany na danych obejmujących przynajmniej pełen cykl sezonowy, a nie tylko „ładny” kawałek z jednego kwartału.

Warto:

• dodać do cech modelu informacje kalendarzowe (miesiąc, pora roku, dzień tygodnia, zmiana),
• sprawdzić metryki osobno dla różnych sezonów (np. lato vs zima, szczyt produkcji vs niski sezon),
• zaplanować monitoring, który wykrywa, że w danym okresie (np. upały, okres świąteczny) jakość modelu systematycznie spada.

Takie podejście pozwala zdecydować, czy wystarczy korekta modelu, czy potrzeba osobnych konfiguracji dla różnych sezonów.

Jakie dane operacyjne są krytyczne, żeby model był odporny na zmiany?

Poza klasycznymi sygnałami procesowymi (temperatury, ciśnienia, czasy) kluczowe są znaczniki zdarzeń i kontekstu, które człowiek pamięta z głowy, ale system już nie zawsze. Chodzi głównie o:

• ID partii materiału i dostawcy,
• ID operatora i zmiany roboczej,
• wersję receptury / parametry nastaw (np. wersja PID, tryb pracy),
• daty serwisów, remontów, większych modyfikacji linii.

Bez tych znaczników model uczy się „uśrednionego” procesu i traci odporność na sytuacje, które z punktu widzenia technologii są zupełnie różne. Z takimi danymi można natomiast świadomie testować stabilność między partiami, zmianami i wersjami procesu.

Jak monitorować i reagować na spadek jakości modelu w produkcji?

Monitoring nie może kończyć się na jednym globalnym RMSE czy accuracy. Potrzebne są:

• metryki jakości liczone w czasie (np. dziennie, tygodniowo) z alarmami na odchylenia,
• porównania wyników modelu między partiami, zmianami, sezonami,
• monitoring rozkładów kluczowych cech (wykrywanie data driftu).

Do tego dochodzi procedura reakcji: kto dostaje alert, kiedy model przechodzi w tryb „tylko rekomendacje”, kiedy robi się szybki re-trening, a kiedy trzeba technologicznie przeanalizować, czy nie zaszła zmiana procesu (concept drift). Bez takiej procedury skończy się na tym, że operator „po cichu” wyłączy model i wróci do sprawdzonego Excela.

Czy da się przygotować model, który „z góry” poradzi sobie ze wszystkimi zmianami partii i sezonowością?

Nie da się przewidzieć każdej przyszłej zmiany procesu, dostawcy czy modernizacji linii, ale można zbudować model i otoczkę, które znoszą te zmiany z godnością. Kluczem są:

• dane treningowe obejmujące możliwie szeroki zakres warunków,
• testy na „trudnych” fragmentach historii (rozruchy, awarie, zmiany partii, skrajne temperatury otoczenia),
• monitoring driftu i proces cyklicznego dostrajania / re-treningu.

Model nie musi być nieśmiertelny, ma natomiast jasno pokazywać, kiedy wchodzi w obszar, którego „nie zna” – wtedy wchodzi do gry zespół technologów i data scientistów, zamiast czekać, aż scrap i reklamacje zrobią tę diagnozę za nich.