Czy model naprawdę jest „słaby”, czy tylko uczysz go na złej wersji rzeczywistości? To najważniejsze pytanie przy pracy na danych z produkcji. Jeśli w notebooku masz świetne metryki, a na hali model generuje fałszywe alarmy, milczy przed awarią albo „głupieje” po miesiącu, winowajcą najczęściej nie jest algorytm, tylko pułapki w danych: przecieki (data leakage), rozjechany czas, mylące etykiety z CMMS/MES/QMS, drift procesu oraz brak kontroli nad pipeline’em po wdrożeniu.
W praktyce działają tu inne zasady niż w typowych projektach ML. Dane przemysłowe są czasowe, zdarzeniowe i wielosystemowe (PLC/SCADA/historian/MES/QMS/CMMS/ERP), a „prawda” o awarii czy defekcie bywa opóźniona, ręcznie wpisywana i zmienna w definicjach. Poniżej masz zestaw najbardziej destrukcyjnych błędów przy trenowaniu modeli AI na danych produkcyjnych oraz konkretne bezpieczniki, które realnie da się wdrożyć w środowisku OT/IT.
Realne pytania, które zwykle stoją za tym tematem: Po czym poznać, że problem jest w danych, a nie w modelu? Skąd biorą się fałszywie dobre wyniki offline? Jak ustalić etykiety „awaria/defekt” tak, żeby nie trenować na chaosie? Co zrobić z brakami danych i resetami PLC? Jak testować drift receptur i partii? Jakie metryki mają sens operacyjnie? Jak zbudować minimalny monitoring, żeby model nie „zgasł” po wdrożeniu?
Decyzja na starcie: czy problem jest w modelu, czy w danych i definicji zadania
Sygnały ostrzegawcze, że to nie algorytm
Jeśli model raz działa świetnie, a raz fatalnie przy podobnych ustawieniach, to często oznacza niestabilność danych (braki, zmiana tagów, drift procesu) albo błąd w walidacji. Typowy symptom: metryki offline (np. AUC, F1) wyglądają imponująco, a po wdrożeniu alarmy są nieużyteczne. Drugi klasyk: model „genialnie” przewiduje awarie, ale tylko na jednej linii albo tylko na jednej zmianie.
W danych produkcyjnych łatwo o sytuację, w której model uczy się skrótów: identyfikatorów zleceń, numerów partii, statusów MES aktualizowanych po fakcie albo cech sklejonych z przyszłością (np. dobowe podsumowania). Wtedy „dokładność” jest wysoka, ale nie ma przełożenia na realną decyzję na hali.
Minimalne doprecyzowanie use case’u, zanim powstanie pierwsza próbka
Trening bez doprecyzowania zadania kończy się modelem, który optymalizuje coś innego niż oczekujesz. Dla predykcji awarii krytyczne są trzy parametry: co jest zdarzeniem (awaria vs przestój vs planowy serwis), horyzont predykcji (np. 2 godziny wcześniej) i czas reakcji (czy utrzymanie ruchu potrzebuje 10 minut, czy 2 godzin). Dla kontroli jakości ważne jest, czy wykrywasz defekt na sztuce, na partii czy na oknie czasowym, oraz czy decyzja ma zatrzymać linię, odrzucić sztukę czy tylko zgłosić alert do weryfikacji.
Uwaga: w zakładzie „prawda” o zdarzeniu bywa rozproszona. PLC/SCADA widzą stany maszyny, MES widzi zlecenia i partie, QMS widzi wyniki kontroli jakości, a CMMS widzi zgłoszenia i zlecenia serwisowe. Bez wskazania, które źródło jest „źródłem prawdy” dla etykiety, model będzie nagradzany i karany przypadkowo.
Kryterium stop/go przed trenowaniem na danych produkcyjnych
Zanim wydasz czas na tuning modeli, sprawdź trzy rzeczy, które muszą być jednoznaczne:
- Etykieta: jak dokładnie nazywa się zdarzenie i skąd pochodzi (MES/QMS/CMMS/SCADA)?
- Oś czasu: jaki jest moment zdarzenia i jak wiążesz go z sygnałami (okno etykietowania, tolerancja czasowa)?
- Dostępność cech: które sygnały są dostępne w momencie decyzji, a które pojawiają się dopiero po fakcie (ryzyko leakage)?
Jeśli nie da się tego spisać w dwóch–trzech zdaniach, problem jest w definicji i danych, nie w architekturze sieci czy doborze algorytmu.
Pułapka nr 1 — „fałszywie dobre” wyniki przez leakage i zły podział danych (zwłaszcza czasowych)
Skąd się bierze data leakage w zakładzie: typowy łańcuch przyczynowy
Data leakage to sytuacja, gdy do modelu trafia informacja, której w realu nie będzie w momencie predykcji. W produkcji zdarza się to podstępnie, bo wiele pól wygląda „niewinnie”. Przykłady:
Target leakage z MES/QMS/CMMS: status „zamknięte”, kod przyczyny przestoju, wynik kontroli jakości wpisany po inspekcji, czas zakończenia zlecenia produkcyjnego. Jeśli budujesz cechy z tych pól bez twardej kontroli czasu, model dostaje odpowiedź w wejściu.
Leakage przez agregacje: cecha „średnia dobowa temperatura” albo „liczba braków na zmianie” policzona z całej zmiany, gdy próbka dotyczy początku zmiany. Takie „sumy” często zawierają przyszłość.
Leakage przez zły split: losowy podział danych sprawia, że bardzo podobne próbki (z tego samego zdarzenia, tej samej partii, tego samego dnia) trafiają do train i test. Model nie uczy się mechanizmu, tylko rozpoznaje kontekst.
Poprawny podział danych w ML przemysłowym: czas i kontekst
W danych czasowych losowy split niemal zawsze jest błędem. Minimalny standard to separacja po czasie: trening na przeszłości, test na przyszłości. Często warto dodać separację po kontekście produkcji, jeśli kontekst jest istotny operacyjnie: linia, receptura, produkt, gniazdo, wariant maszyny.
Jeśli model ma działać na nowych partiach surowca, nie testuj go na próbkach z tej samej partii, co trening. Jeśli ma działać po przezbrojeniu, test powinien obejmować okres po przezbrojeniu. Dobre podejście to walidacja typu forward-chaining (kroczące okna): uczysz na pierwszym okresie, testujesz na kolejnym, potem przesuwasz okno.
Szybkie testy, które wykrywają, że model uczy się nie tego co trzeba
To nie jest akademicka zabawa. Te testy potrafią oszczędzić tygodnie pracy, bo od razu wskazują „fałszywie dobre” wyniki.
- Permutacja czasu: przetasuj kolejność w czasie (albo przesuń znaczniki czasu) i sprawdź, czy metryki nie zostają podejrzanie wysokie. Jeśli zostają, model prawdopodobnie korzysta z kontekstu/ID albo leakage.
- Walidacja forward-chaining: porównaj wynik z losowym splitem. Duża przepaść to sygnał, że losowy split przepuszcza podobne próbki do obu zbiorów.
- Test „tylko kontekst”: zbuduj prosty model na samych ID (linia, zmiana, produkt, partia). Jeśli daje wysokie wyniki, w danych jest skrót, a Ty nie mierzysz procesu.
- Ablacja podejrzanych cech: usuń cechy typu statusy MES, kody zdarzeń, sumy zmianowe. Jeśli wynik spada dramatycznie, prawdopodobnie „karmiłeś” model odpowiedzią.
Pułapka nr 2 — etykiety z CMMS/MES/QMS: opóźnienia, mieszanie definicji i „ciche” zmiany znaczeń
Co musi być ustalone, zanim w ogóle zaczniesz etykietowanie
Najgorszy błąd brzmi banalnie: trenowanie na etykiecie, której nikt jednoznacznie nie rozumie. W zakładach słowa „awaria”, „przestój”, „postój”, „blokada”, „mikrostop” bywają używane wymiennie, a to zabija uczenie nadzorowane (supervised learning).
Minimum to spisana definicja zdarzeń: co zaliczamy do awarii (np. nieplanowane zatrzymanie wymagające interwencji UR), co jest planowym serwisem, co jest brakiem materiału, co jest przezbrojeniem. Jeśli etykietą jest „awaria”, ustal, czy wykluczasz postoje planowe oraz czy rozróżniasz awarie o różnych przyczynach (mechanika vs elektryka vs automatyka). Bez tego model będzie trenowany na mieszance kilku zjawisk i będzie „średnio dobry” w każdym.
Mechanizmy psucia etykiety: jak powstaje szum labeli
W CMMS etykieta często pochodzi z momentu zgłoszenia, a nie z momentu wystąpienia problemu. Operator może kliknąć po godzinie, a technik zamknie zlecenie po zmianie. W MES/QMS bywa podobnie: wynik kontroli jakości może być przypisany do partii z opóźnieniem, a numer partii w systemie zmienia się po zatwierdzeniu, nie w momencie fizycznego przejścia surowca.
Uwaga: „ciche” zmiany definicji są częstsze, niż się wydaje. Przykład: zmiana sposobu kodowania przyczyn przestoju w MES, reorganizacja słownika defektów w QMS albo nowy formularz w CMMS. Dane wyglądają tak samo (te same kolumny), ale znaczenie kategorii zmienia się od określonej daty.
Przykład: predykcja awarii, gdzie CMMS uczy model „kiedy ktoś kliknął”
Typowa sytuacja: etykieta „awaria” jest pobierana z CMMS na podstawie czasu zgłoszenia. Model dostaje sygnały z PLC/SCADA i ma przewidywać awarię. Jeśli zgłoszenia są opóźnione lub zbiorcze („wpiszę po zmianie”), to etykieta nie jest zsynchronizowana z rzeczywistym zdarzeniem. W efekcie model może nauczyć się korelacji z godzinami pracy operatorów (np. skoki zgłoszeń na końcu zmiany) zamiast z symptomami uszkodzeń.
Bezpiecznik jest prosty, choć wymaga dyscypliny: mapowanie etykiety do osi czasu zdarzeń z SCADA (np. stan STOP/FAULT) i zastosowanie okna etykietowania (label window), czyli tolerancji czasowej. Zamiast etykiety w jednej minucie, oznaczasz okno wokół prawdopodobnego zdarzenia (np. 30–60 minut) i budujesz próbki predykcyjne wyłącznie z danych sprzed okna.
Sanity check etykiet, zanim oskarżysz model
Trzy szybkie kontrole potrafią ujawnić, że problem jest w labelach:
Po pierwsze: rozkład zdarzeń po dniu tygodnia i godzinie. Jeśli „awarie” występują głównie w godzinach biurowych, a maszyna pracuje 24/7, to nie są awarie, tylko rytm raportowania.
Po drugie: rozkład czasów trwania i liczby zdarzeń na zmianę. Skrajne wartości (np. wiele zdarzeń o dokładnie 60 minut) często oznaczają zaokrąglanie albo wpisy „z głowy”.
Po trzecie: korelacje z planem produkcji. Jeśli etykieta defektu rośnie tylko na jednej recepturze, sprawdź, czy to wada procesu, czy po prostu ta receptura ma surowszą kontrolę jakości.
Pułapka nr 3 — oś czasu nie istnieje: braki, resety PLC, zmiany tagów, opóźnienia i agregacje tworzą sztuczne wzorce
Braki danych i resety PLC: „dziury” to też informacja (ale nie zawsze ta, której chcesz)
Dane z maszyn bywają nieciągłe: restarty sterowników, zerowanie liczników, chwilowa utrata komunikacji z historianem, przepełnienie buforów. Model ML może przypadkiem nauczyć się, że „brak danych” oznacza awarię, bo braki zdarzają się podczas problemów z zasilaniem lub siecią. Czasem to jest prawda (i może być użyteczne), ale częściej to artefakt infrastruktury, nie procesu.
Dlatego pierwsza decyzja brzmi: czy traktujesz braki jako sygnał procesu, czy jako błąd akwizycji. Jeśli to drugie, to brak musi być „zneutralizowany” w cechach: jawna flaga missing, spójna imputacja (np. forward-fill z limitem czasu), a przede wszystkim odcięcie próbki, gdy luka jest zbyt długa, by zachować sens fizyczny. Reset licznika lub skok wartości to nie „nowy stan maszyny” — to zdarzenie w warstwie danych, które trzeba wykryć i opisać (np. cecha „reset_detected” + ponowne wyznaczenie pochodnych na czystych odcinkach).
Uwaga: popularny błąd to liczenie pochodnych i statystyk okienkowych na sygnale z dziurami. Wtedy powstają „sztuczne piki”: połączenie dwóch odległych w czasie punktów wygląda jak nagła zmiana parametru, a model bierze to za symptom awarii. To samo dotyczy agregacji w historianie — jeśli dane są uśrednione co minutę, a brak wypełniany zerem lub ostatnią wartością, to w cechach pojawiają się wzorce infrastruktury (jak działa bufor), nie procesu.
Drugi klasyk to zmiany tagów i opóźnienia. Tag w PLC bywa przemianowany, przeniesiony do innego bloku, a w SCADA zostaje stara nazwa z nowym źródłem. Bez wersjonowania słownika tagów model dostaje sygnał „ten sam”, który w połowie historii oznacza coś innego. Do tego dochodzą opóźnienia: czujnik temperatury raportuje co 10 s, stan maszyny co 100 ms, a system jakości dopiero po zatwierdzeniu partii. Jeśli nie zrobisz twardego time alignment (wyrównania czasowego) i nie opiszesz opóźnień, to model uczy się kolejności rejestracji w systemach, nie sekwencji zdarzeń na linii.
Tip: prosta diagnostyka, która często odsiewa 80% problemów, to wykres „czas między próbkami” dla kluczowych tagów oraz licznik zmian konfiguracji (np. liczba różnych jednostek/skal dla tego samego pola). Jeśli widzisz nagłe przejście z regularnych próbek na paczki co kilka minut, albo jednostki skaczą między °C i dziesiątymi °C, nie ma sensu stroić modelu — trzeba ustabilizować oś czasu i semantykę sygnału. Dopiero na tak przygotowanych danych testy z wcześniejszych pułapek (forward-chaining, ablacją cech, sanity check labeli) zaczynają mówić prawdę.
Gdy wyniki są podejrzanie dobre albo podejrzanie złe, najszybciej pomaga brutalnie praktyczne podejście: narysować oś czasu dla kilku zdarzeń end-to-end (PLC → historian → MES/QMS/CMMS → dataset) i sprawdzić, czy model faktycznie widzi to, co będzie widział na produkcji — w tej samej chwili, z tymi samymi opóźnieniami i bez „doprawiania” przyszłością.
Synchronizacja i jednostki: drobiazgi, które rozwalają cechy
W danych przemysłowych „czas” to nie tylko znacznik w wierszu. To też częstotliwość próbkowania, opóźnienie akwizycji, strefy czasowe, zaokrąglenia i różne zegary (PLC, historian, serwer MES). Jeśli nie masz jednej spójnej osi czasu, cechy okienkowe (średnie, odchylenia, trendy) zaczynają opisywać błędy integracji, a nie proces.
Dwa powtarzalne scenariusze:
Asynchroniczne źródła: prąd silnika jest z próbkowania co 100 ms, temperatura co 10 s, a status linii z MES co 1 min. Jeśli zrobisz join „po najbliższym czasie” bez limitu, model dostanie temperaturę z przyszłości względem prądu (wystarczy, że timestampy są zaokrąglane do minut). To jest ukryty leakage, tylko w przebraniu „integracji danych”.
Jednostki i skale: w połowie historii czujnik zaczyna raportować w dziesiątych °C (np. 253 zamiast 25.3), bo ktoś zmienił skalowanie w sterowniku. Wykres może wyglądać „dziwnie”, ale model potraktuje to jako gwałtowną zmianę procesu. Jeśli drift pojawia się dokładnie w dacie modernizacji, łatwo pomylić błąd danych z realną zmianą.
Bezpiecznik: trzy warstwy walidacji przed feature engineeringiem. (1) Kontrola delta-t między próbkami dla każdego taga. (2) Kontrola jednostek/skal (słownik + testy wykrywające skoki rzędu wielkości). (3) Twarda reguła no future data przy dopasowaniu czasowym: do próbki w czasie t wolno użyć tylko wartości z czasem ≤ t, z ograniczeniem maksymalnego „opóźnienia dopasowania” (np. nie dopasowuj temperatury starszej niż 30 s, jeśli proces jest szybki).
Pułapka nr 4 — drift procesu: receptury, partie surowca i modernizacje zmieniają rozkład danych szybciej niż model
Dlaczego model „działał w pilocie”, a po miesiącu przestaje
W produkcji rozkład danych zmienia się naturalnie: inna partia surowca, inny dostawca, zużycie narzędzia, zmiana operatorów, sezonowość mediów, nowe ograniczenia jakościowe. To nie są wyjątki, tylko normalny tryb życia zakładu. Model, który nauczył się jednego „świata procesu”, po cichu traci trafność, bo trafia w inny.
Najbardziej podstępny jest drift „bez alarmu”: metryki offline wyglądają stabilnie, bo walidacja była robiona losowym splitem, a w zbiorze testowym masz podobne warunki do treningu. Potem trafiasz na tydzień z inną recepturą i alarmy lecą seriami albo nie ma ich wcale.
Symptomy driftu, które widać szybciej niż spadek accuracy
Warto monitorować nie tylko jakość predykcji, ale też „czy dane nadal wyglądają jak kiedyś”. Dwa proste sygnały są zwykle bardziej czułe niż metryki klasyfikacji:
Zmiana rozkładów cech: histogramy, percentyle, udział braków, częstotliwość stanów. Jeśli zmienia się „wejście”, model nie ma prawa zachowywać się identycznie.
Zmiana relacji cech: korelacje i opóźnienia (np. temperatura vs prędkość linii). Drift często polega na tym, że proces nadal mieści się w „normach”, ale zależności są inne (np. nowy regulator PID albo inny profil rampy po przezbrojeniu).
Bezpieczniki: jak testować drift przed wdrożeniem i po wdrożeniu
Najtańsza rzecz, która realnie działa, to rozcięcie walidacji na segmenty procesu. Zamiast jednego wyniku na całej fabryce, licz metryki osobno dla: receptur, typów produktu, linii, zmian, dostawców surowca, a nawet „przed/po modernizacji” (data graniczna). Jeśli model jest dobry „średnio”, ale zły na jednej recepturze, to w operacji będzie wyglądał jak loteria.
Drugi bezpiecznik to walidacja na przyszłości w sensownych krokach: uczysz na okresie A, testujesz na B, ale B dobierasz tak, by obejmował zmianę warunków (np. inną kampanię produkcyjną). To jest nudne, ale pokazuje prawdę o odporności.
Trzeci to strategia „plan B” na produkcji: jeśli wykryjesz drift (np. dane wykraczają poza zakres z treningu), model nie powinien generować pewnych alarmów. Lepsze jest przejście w tryb ostrożny: podniesienie progu alarmu, ograniczenie do anomalii o wysokiej pewności albo wprost sygnał „model poza zakresem” dla dyżurnego inżyniera.
Przykład: nowa partia surowca i nagły wysyp fałszywych alarmów
W praktyce często wychodzi to tak: model anomalii działa poprawnie, dopóki surowiec pochodzi z jednego źródła. Po zmianie dostawcy rośnie lepkość/ziarnistość, proces wymaga innych nastaw, a sygnały „odjeżdżają” od dotychczasowego wzorca. Model widzi to jako anomalię, bo jest „poza chmurą” danych treningowych, mimo że dla technologii to akceptowalna zmiana.
Rozwiązanie nie polega na „dokręceniu” modelu, tylko na dodaniu kontekstu: cechy partii/dostawcy (jeśli dostępne) albo segmentacji (osobne modele per klasa surowca). Jeśli kontekst jest poza zasięgiem (bo ERP/MES nie daje stabilnych identyfikatorów), czasem uczciwsze jest zawężenie zastosowania modelu do obszaru, gdzie masz kontrolę nad zmiennością.
Pułapka nr 5 — metryki i walidacja, które nie mają sensu operacyjnego
Accuracy bywa bezużyteczne, gdy interesuje Cię czas i koszt alarmu
W wielu zadaniach produkcyjnych kluczowe pytanie brzmi: czy model da ostrzeżenie wystarczająco wcześnie i nie zarżnie ludzi fałszywymi alarmami. Klasyczne metryki (accuracy, ROC-AUC) potrafią wyglądać świetnie nawet wtedy, gdy model jest operacyjnie nie do użycia.
Typowe miny:
Niezbalansowane zdarzenia: awarie są rzadkie. Model, który zawsze mówi „brak awarii”, ma świetną accuracy. Operacyjnie to zero wartości.
Wielokrotne próbki tej samej awarii: jeśli etykietujesz każdą minutę przed awarią jako „1”, to jedna awaria generuje setki dodatnich próbek. Metryki liczone per-próbka zawyżają obraz, bo w realu liczysz zdarzenia, nie minuty.
Metryki, które lepiej pasują do linii
Jeśli model ma ostrzegać o awarii, rozliczaj go w kategoriach zdarzeń i okien czasowych:
- Event recall: jaki procent awarii został „złapany” przynajmniej raz w oknie ostrzegania.
- False alarms per shift/day: ile fałszywych alarmów trafia do operatora na zmianę (to jest często najważniejszy KPI adopcji).
- Lead time (czas wyprzedzenia): ile minut/godzin przed zdarzeniem pojawia się pierwszy sensowny alarm.
Uwaga: te metryki wymuszają, żebyś miał dobrze zdefiniowane okno predykcji (prediction horizon) i okno tolerancji (np. alarm liczy się jako trafiony, jeśli pojawił się 10–60 minut przed awarią). Bez tego model będzie „optymalizowany” pod przypadkowe momenty w danych.
Walidacja „jak na produkcji”, czyli z opóźnieniami i bez przyszłości
Jeśli pipeline cech na produkcji agreguje dane z opóźnieniem (np. liczy statystyki z ostatnich 15 minut i publikuje je co minutę), to walidacja offline musi to symulować. Najczęstszy błąd: policzenie cech na pełnej serii czasowej „z góry” i dopiero potem split. To potrafi przemycić przyszłe informacje nawet bez jawnego leakage w kolumnach.
Bezpiecznik: generuj cechy w trybie „streamingowym” (kroczącym), tak jak będą liczone online. Jeśli to niemożliwe, wprowadź wyraźny cutoff: dla czasu t licz cechy tylko z danych do t, a nie z całego dnia/zmiany.
Pułapka nr 6 — pipeline bez kontroli zmian: model umiera od „małych poprawek”
Najgroźniejsze regresje są nudne: inna wersja taga, inne filtrowanie, inna imputacja
W zakładach zmiany dzieją się cały czas: ktoś dodaje filtr w SCADA, integrator poprawia mapowanie, a historian zmienia sposób agregacji. Dla modelu to zmiana świata. Jeśli nie wersjonujesz danych i logiki cech, nie odróżnisz „model jest słaby” od „pipeline się zmienił”.
Minimalny zestaw bezpieczników, który można wdrożyć bez ciężkiego MLOps:
Wersja słownika tagów i cech: nawet prosta tabela (repozytorium) z: nazwa cechy, źródłowy tag, jednostka, transformacje, data wejścia w życie. To pozwala wykryć „ten sam tag, inne znaczenie”.
Testy kontraktowe danych (data contracts): zakresy fizyczne, dozwolone jednostki, maksymalny udział braków, oczekiwana częstotliwość próbkowania. Jeśli kontrakt pęka, pipeline powinien zatrzymać trening lub oznaczyć batch jako podejrzany.
Reprodukowalny dataset treningowy: snapshot (np. paczka plików + manifest), żeby dało się odtworzyć trening. W produkcji to często rozwiązuje spór „kiedyś działało”.
Monitoring po wdrożeniu, który nie wymaga armii ludzi
Model na produkcji potrzebuje trzech liczników, inaczej jesteś ślepy:
1) Jakość wejścia: braki, opóźnienia, rozkłady kluczowych cech (choćby percentyle).
2) Zachowanie modelu: rozkład predykcji i liczba alarmów na zmianę. Nagły skok to często drift albo zmiana danych, nie „nagłe pogorszenie procesu”.
3) Feedback zdarzeń: nawet jeśli etykieta przychodzi z opóźnieniem (CMMS/QMS), zbieraj ją i licz metryki eventowe w cyklu tygodniowym/miesięcznym.
Tip: jeśli nie masz szybkiego feedbacku o awariach/defektach, tym bardziej potrzebujesz monitoringu wejścia i rozkładu predykcji. To jest wczesne ostrzeganie przed „cichą śmiercią” modelu.
Gdy te bezpieczniki działają, większość „magicznych” problemów znika: metryki przestają skakać bez powodu, a dyskusja z produkcją przenosi się z wiary w AI na konkret — które źródło się rozjechało, jaki segment procesu ma drift i czy alarmy mają koszt, który da się obronić operacyjnie.
Najczęściej zadawane pytania (FAQ)
Skąd mam wiedzieć, czy problem leży w danych, a nie w modelu AI?
Jeśli offline metryki (np. AUC/F1) wyglądają świetnie, a na produkcji dostajesz fałszywe alarmy albo model „milczy” przed awarią, to najczęściej nie jest problem algorytmu. Czerwone flagi to też sytuacje, w których model działa dobrze tylko na jednej linii, jednej zmianie albo tylko dla jednego produktu.
Tip: porównaj wyniki z walidacji losowej vs walidacji po czasie (forward-chaining). Duża przepaść zwykle oznacza, że model nauczył się kontekstu/ID albo skorzystał z przecieków (data leakage), zamiast z mechanizmu procesu.