Model działa na slajdach. W testach trafia „jak złoto”. A potem wjeżdża na halę i nagle: fałszywe alarmy, brak zaufania, operatorzy omijają, UR ma inne priorytety, a IT pyta o integrację, której nikt nie zaplanował. Jeśli to brzmi znajomo, problem rzadko leży w „złym algorytmie”. Najczęściej wykoleja się coś bardziej przyziemnego: źle dobrany przypadek użycia, dane bez kontekstu, etykiety z definicją „na oko”, wdrożenie bez wpięcia w proces i metryki oraz brak planu utrzymania (czyli klasyczne: „kto będzie sprzątał, jak już wszyscy pójdą do domu”).
Poniżej jest pięć najczęstszych błędów we wdrażaniu AI na produkcji — opisanych tak, jak naprawdę wygląda to w fabryce: objaw na hali → typowa przyczyna → rozwiązanie → pułapka wtórna → konkretne kroki „co zrobić jutro”. Po drodze pojawią się też pytania kontrolne, które zwykle padają dopiero po nieudanym PoC, a lepiej zadać je przed startem.
Frazy pomocnicze: wdrożenie AI na produkcji, PoC a pilot AI, dane z PLC SCADA MES, etykietowanie awarii CMMS, edge AI w przemyśle, metryki precision recall w produkcji, drift modelu i monitoring, integracja IT OT, predykcyjne utrzymanie ruchu błędy, kontrola jakości wizyjna problemy, ROI AI w fabryce, adopcja operatorów AI
AI działa w prezentacji, a na hali „magicznie” przestaje — skąd to się bierze
Pytania, które padają minutę po nieudanym PoC
Gdy pierwszy entuzjazm opada, zwykle pojawiają się bardzo konkretne pytania. I one są świetnym kompasem, bo pokazują, gdzie naprawdę boli wdrożenie AI na produkcji:
- „Co dokładnie ma się zmienić na linii, kiedy model da wynik?” Jeśli odpowiedź brzmi „zobaczymy”, to już jest problem.
- „Kto ma reagować i w jakim czasie?” Operator, lider zmiany, technolog, UR, kontrola jakości? Jeśli nikt — model będzie ładną ciekawostką.
- „Skąd wiemy, że dane są poprawnie zsynchronizowane?” PLC, SCADA, MES i CMMS potrafią żyć w osobnych światach czasowych.
- „Co jest prawdą: sygnał z czujnika, wpis w systemie czy notatka w zeszycie?” AI nie lubi zagadek detektywistycznych, a produkcja czasem takie tworzy.
- „Co się stanie, gdy model się pomyli?” Kto bierze odpowiedzialność i jak to obsłużyć procesowo?
Po nieudanym PoC te pytania brzmią jak „czepianie się”. Przed startem są bezcenne, bo pozwalają odróżnić projekt wdrożeniowy od eksperymentu badawczego.
PoC, pilot i wdrożenie: te same słowa, trzy różne światy
W produkcji rozjazdy najczęściej biorą się z mylenia etapów. Nie chodzi o akademickie definicje, tylko o odpowiedzialność i warunki działania.
| Etap | Po co jest | Co musi działać | Najczęstsza pułapka |
|---|---|---|---|
| PoC | Sprawdzić, czy z danych da się wyciągnąć sygnał i czy kierunek ma sens | Model na danych historycznych / w kontrolowanych warunkach | Zachwyt metryką ML bez odpowiedzi „co robi produkcja z wynikiem” |
| Pilot | Sprawdzić, czy rozwiązanie działa w realnym procesie i daje efekt operacyjny | Integracja, stabilny pomiar, procedura reakcji, test na zmianach/partiach | „Działa u mnie na laptopie”, ale nie w rytmie linii |
| Wdrożenie produkcyjne | Utrzymać efekt w czasie, mimo zmian procesu i danych | Monitoring, odpowiedzialności, serwis, cykl aktualizacji, szkolenia | Brak właściciela utrzymania: rozwiązanie „umiera” po kwartale |
Krótka scenka z życia: wizja maszynowa wygrywa w biurze, przegrywa na linii
Typowy scenariusz z kontroli jakości wizyjnej: model rozpoznaje wady na zdjęciach zebranych „na spokojnie” — z dobrym światłem, bez drgań, bez pyłu, bez refleksów. Potem kamera trafia na linię, a tam okazuje się, że oświetlenie zmienia się w zależności od pory dnia, produkt ma kilka wariantów, a przenośnik drży jakby chciał zrzucić temat na utrzymanie ruchu.
Efekt: fałszywe alarmy. Operatorzy szybko uczą się, że sygnał „AI wykryło wadę” oznacza „AI ma gorszy dzień”. Po tygodniu nikt nie patrzy w ekran, bo szybciej jest ocenić ręcznie. I nie jest to złośliwość ludzi — to racjonalna reakcja na system, który nie trzyma parametrów procesu.
Wniosek jest prosty: na produkcji przeciwnikiem nie jest „zbyt prosty model”, tylko zmienność warunków oraz brak wpięcia wyniku w działanie. Te dwa czynniki stoją za większością porażek.
Błąd #1 — Zły dobór use case’u: „AI nam to zrobi”, tylko po co i co dalej?
Objaw na hali: projekt kręci się wokół modelu, a nie decyzji
Najbardziej kosztowny błąd jest banalny: wybrano przypadek użycia, który nie ma jasnego „momentu prawdy”. Model coś przewiduje albo klasyfikuje, ale produkcja nie wie, jak tę informację zamienić w działanie. Wtedy dzieją się trzy rzeczy naraz:
Po pierwsze, wymagania zaczynają pływać: raz celem jest redukcja braków, raz skrócenie przezbrojeń, raz oszczędność energii, bo „skoro już mamy AI, to może…”. To nie jest elastyczność. To brak decyzji.
Po drugie, sukces zaczyna być mierzony „ładnymi wykresami”. To moment, w którym ROI AI w fabryce zaczyna istnieć głównie w PowerPoincie, a nie w OEE.
Po trzecie, rośnie napięcie między działami. Produkcja oczekuje „cudownej skrzynki”, IT/OT chce konkretnych wymagań integracyjnych, a zespół danych potrzebuje definicji etykiet i zdarzeń. Bez dobrego use case’u każdy ma rację — i nikt nie dowozi.
Typowa przyczyna: nie dopięto pytań o reakcję, koszt błędu i okno czasu
Zły use case rzadko wynika z braku pomysłów. Częściej z tego, że nikt nie doprecyzował trzech fundamentów:
- Decyzja po wyniku: co konkretnie robimy, gdy model mówi „ryzyko awarii” albo „wyrób wadliwy”? Czy zatrzymujemy linię, czy izolujemy partię, czy wołamy UR, czy zmieniamy parametr?
- Okno reakcji: czy mamy czas zareagować, zanim problem „przeleci” przez proces? Predykcja 10 sekund przed zdarzeniem może być bezużyteczna, jeśli interwencja trwa 5 minut.
- Koszt pomyłki: ile fałszywych alarmów na zmianę jest akceptowalne? A ile „przeoczonych” wad/awarii możemy znieść? Produkcja myśli w kosztach i przepustowości, nie w samej accuracy.
W praktyce wiele projektów wpada też w pułapkę: próbuje się użyć AI do problemu, który jest procesowy, nie analityczny. Jeśli przyczyna wahań jakości leży w niestabilnym dozowaniu, a dozowanie wynika z mechaniki, to model może co najwyżej ładnie opisać chaos. Taniej będzie ustabilizować proces.
Rozwiązanie: kryteria „dobrego” problemu dla AI (konkretne i mierzalne)
Dobry use case na produkcji ma kilka cech. Nie muszą wystąpić wszystkie, ale im więcej ich spełniasz, tym mniejsze ryzyko „magicznego przestania” na hali.
Częstotliwość zdarzeń i materiał do uczenia
Jeśli chcesz przewidywać rzadką awarię raz na pół roku, a masz dane z 12 miesięcy, to model będzie wróżył z fusów. W predykcyjnym utrzymaniu ruchu to klasyk: „mamy jedną poważną awarię rocznie, zróbmy AI”. Da się, ale zwykle startuje się wtedy od anomalii, sygnałów pośrednich lub modeli fizycznych — a nie od klasycznej predykcji na etykietach awarii.
Możliwość działania po predykcji
AI musi prowadzić do działania, które jest realne w warunkach linii: zmiana parametru, kontrola dodatkowa, odrzut, serwis, korekta ustawień. Jeśli jedyną reakcją jest „zanotujmy to”, to projekt umiera z nudów szybciej, niż model zdąży złapać drift.
Operacyjny próg bólu: ile alarmów produkcja zniesie
Metryki precision/recall w produkcji muszą zostać przełożone na język zmiany. Nie „precision 92%”, tylko: „maksymalnie 2 fałszywe alarmy na godzinę na stanowisko” albo „nie więcej niż 1 niepotrzebne zatrzymanie na zmianę”. Jeśli tego nie ustalisz, model może być „statystycznie dobry”, a operacyjnie nie do zniesienia.
Pułapka wtórna: ratowanie złego problemu dokładaniem algorytmu
Gdy use case nie ma sensu, naturalną reakcją jest: „to zróbmy lepszy model”. Dokłada się sieci, featury, tuning, a czasem jeszcze platformę. To jak wymiana silnika w aucie, które nie ma kół. Jeśli problemem jest brak czasu na reakcję, brak procedury lub brak danych kontekstowych, to nawet najlepszy algorytm tylko szybciej pokaże, że się nie da.
Co zrobić jutro: szybki test sensowności use case’u
- Spisz decyzję po wyniku: kto reaguje, co robi, w jakim czasie, jakim kosztem.
- Ustal dwa KPI: jeden operacyjny (np. scrap, microstops, MTBF/MTTR, czas reakcji), jeden ML (np. recall dla wad krytycznych).
- Sprawdź alternatywy: reguły, SPC, proste alerty. Jeśli dają 80% efektu bez skomplikowania, AI może poczekać albo być etapem 2.
- Policz „zdarzenia do nauki”: ile realnych przypadków masz w historii i czy są wiarygodnie opisane.
Błąd #2 — Dane „są”, tylko że nie mówią prawdy: timestampy, receptury i brak kontekstu
Objaw na hali: model strzela losowo, a zespół grzęźnie w scalaniu
To jeden z najbardziej frustrujących momentów: masz czujniki, logi z PLC, trendy w SCADA, zdarzenia w MES, czasem coś w ERP. Teoretycznie złoto. W praktyce okazuje się, że dane są jak puzzle z różnych pudełek: pasują kolorami, ale obrazek się nie składa.
Typowe objawy:
- Model „działa” na wybranym fragmencie danych, a po wdrożeniu generuje fałszywe alarmy, bo w realu sygnały są przesunięte w czasie.
- Wyniki drastycznie różnią się między zmianami, bo zmieniają się warunki procesu, a w danych nie ma śladu: przezbrojenia, partii, receptury, trybu pracy.
- Większość czasu projektu idzie na ETL i „dogadywanie się, co oznacza tag X”, zamiast na rozwiązanie problemu.
Typowa przyczyna: produkcyjne klasyki danych (których nikt nie lubi, ale wszyscy mają)
Niespójne znaczniki czasu między PLC/SCADA/MES/ERP
Różne strefy czasowe, brak NTP, zegary przesunięte o minuty, a czasem o godziny. Do tego różne częstotliwości próbkowania i opóźnienia transmisji. Jeśli łączysz zdarzenie z MES z sygnałem z PLC „po timestampie”, a zegary nie są zsynchronizowane, model uczy się przypadkowych korelacji.
Ręczne wpisy jako jedyne źródło prawdy
„Awaria 12:30” wpisana po fakcie, bez dokładności do minuty. Komentarze w stylu „coś stukało” i kody przyczyn wybierane z listy, która ma 50 pozycji oraz 51. pozycję „inne”. AI z tego skorzysta, ale najpierw zrobi ci prezentację o jakości danych.
Zmiany receptur i ustawień bez śladu w danych
Jeśli proces ma receptury, przezbrojenia, warianty produktu, zmiany narzędzi — to muszą być zdarzenia w danych. Inaczej model porównuje nieporównywalne: „to samo” ciśnienie dla innej lepkości, „ta sama” temperatura dla innego materiału, „ten sam” czas cyklu dla innego wariantu.
Dane bez kontekstu procesu
W praktyce AI w przemyśle rzadko działa na samych sygnałach analogowych. Potrzebuje kontekstu: partia, produkt, narzędzie, stanowisko, operator (czasem), tryb pracy, prędkość linii, stan maszyny, przezbrojenie. Bez tego model widzi „zmienność” i nie wie, czy to wada, czy normalna zmiana produkcyjna.
Rozwiązanie: definicja „wystarczająco dobrych danych” do startu (bez budowy data lake)
Nie potrzebujesz od razu idealnej architektury danych. Potrzebujesz danych, które pozwolą wiarygodnie odpowiedzieć na pytanie: „czy ten sygnał poprzedza zdarzenie i czy da się na nim polegać?”. „Wystarczająco dobre” zwykle oznacza:
- Wspólny czas: zsynchronizowane zegary (NTP/PTP) albo przynajmniej znany offset i sposób korekty; do tego jasne zasady, czy pracujesz na czasie zdarzenia, czasie zapisu czy czasie przetworzenia.
- Jednoznaczne łączenie kontekstu: identyfikator partii/zlecenia/receptury oraz stan maszyny w tym samym strumieniu, tak by dało się powiedzieć „to zdarzyło się podczas tej receptury, na tym narzędziu, w tym trybie”.
- Stabilne tagi i jednostki: bez „czasem bar, czasem kPa” i bez tagów, które po modernizacji zmieniają znaczenie. Jeśli tag żyje własnym życiem, model też zacznie.
- Powtarzalność zapisu: brak „dziur” w danych, a jeśli są — to wiesz, kiedy i dlaczego. Model nie musi mieć ideału, ale musi mieć przewidywalny bałagan.
Najpraktyczniejsze pytanie kontrolne brzmi: czy potrafisz odtworzyć przebieg jednej konkretnej sztuki/partii od wejścia do wyjścia (proces, receptura, ustawienia, warunki) i powiązać go z wynikiem jakościowym albo zdarzeniem UR? Jeśli odpowiedź brzmi „no tak mniej więcej”, to AI z dużym prawdopodobieństwem też będzie działać „mniej więcej”. A „mniej więcej” na produkcji jest drogie.
Drugi test: wybierz jedno zdarzenie, które wszyscy rozumieją (np. zadziałanie krańcówki, start/stop cyklu, otwarcie drzwi bezpieczeństwa) i sprawdź, czy w danych z PLC, SCADA i MES występuje w tej samej kolejności i z sensownym przesunięciem czasowym. Jeśli raz jest przed, raz po, a czasem w ogóle znika — najpierw naprawiasz czas i przepływ, nie model.
Trzecia rzecz, która robi robotę szybciej niż kolejny sprint data engineeringu: „słownik procesu” w jednej stronie. Co oznacza dany tag, w jakich jednostkach, kiedy jest wiarygodny, kto jest właścicielem i co go psuje (przezbrojenie? serwis? tryb ręczny?). Bez tego każdy dashboard wygląda „prawie dobrze”, a potem okazuje się, że temperaturę liczysz z kanału, który jest odłączany przy CIP. Niby drobiazg, ale potrafi wyprodukować bardzo pewny siebie błąd.
Błąd #3 — Etykiety i definicje zdarzeń: „awaria” znaczy pięć różnych rzeczy
Jeśli dane są krwią projektu, to etykiety są jego diagnozą. A diagnoza typu „pacjent źle się czuje” średnio nadaje się do leczenia. W produkcji „awaria” bywa wszystkim: od mikrostopu, przez brak materiału, po planowany przegląd (bo ktoś kliknął nie to, co trzeba). Model tego nie zgadnie. On tylko nauczy się twojej niekonsekwencji.
Tu padają zwykle bardzo konkretne pytania: co dokładnie ma przewidywać model, kiedy uznajemy zdarzenie za rozpoczęte i zakończone, czy liczy się przyczyna, czy skutek, czy „zatrzymanie” w trybie ręcznym to to samo co w automacie. Jeśli te odpowiedzi różnią się między zmianami albo między UR i produkcją, to dostajesz klasyczny efekt: model „działa” w laboratorium, a na hali każdy spór o wynik kończy się zdaniem „bo źle to etykietujecie”.
Mini-checklista, która zamyka najczęstsze dziury zanim zaczną kosztować: (1) jedna definicja zdarzenia i jedna definicja „normalnej pracy”; (2) priorytet źródeł prawdy (PLC > SCADA > MES > ręczne wpisy — albo inaczej, ale jawnie); (3) zasada obsługi wyjątków (brak danych, tryb ręczny, testy, serwis); (4) próg minimalnego czasu, po którym uznajesz stop za stop (żeby nie uczyć modelu „awarii” trwającej pół sekundy, bo ktoś potknął się o przycisk). I tak, to jest mało sexy. Za to bardzo skuteczne.
Objaw na hali: model „ma rację”, ale nikt się z nim nie zgadza
Najczęstszy scenariusz po pierwszym treningu wygląda tak: data science pokazuje wykresy, a produkcja odpowiada „to nie jest awaria, to był brak materiału”, UR mówi „to był test po serwisie”, a operator dorzuca „a wtedy jechałem w ręcznym, bo mi się spieszyło”. I nagle okazuje się, że nie kłócicie się o AI, tylko o słowa.
Jeśli etykiety są niejednoznaczne, pojawiają się typowe zgrzyty:
- Wynik modelu jest kwestionowany, bo nie wiadomo, czy „zdarzenie” to przyczyna (np. zabrudzenie czujnika), skutek (stop linii) czy decyzja (kliknięcie w HMI).
- Model „przewiduje awarie”, ale w praktyce przewiduje… zmianę zmiany albo uruchomienie CIP, bo tak jest opisane w danych.
- Wdrożenie staje się dyskusją światopoglądową: „u nas to zawsze tak było”, zamiast pytaniem „co mamy robić, gdy model daje sygnał?”.
Typowa przyczyna: etykieta bez „granicy zdarzenia” i bez właściciela definicji
Największy błąd w etykietach nie polega na tym, że są niedoskonałe. Polega na tym, że nikt nie potrafi powiedzieć, kiedy dokładnie zdarzenie się zaczyna i kiedy kończy, a do tego kto może je zaklasyfikować i kiedy zmiana klasyfikacji jest dozwolona.
W produkcji to się mści w trzech miejscach:
- Okno czasowe: jeśli uczysz model na „5 minut przed awarią”, ale awaria ma start wpisany „po fakcie”, to te 5 minut jest losowe.
- Hierarchia przyczyn: stop linii może mieć przyczynę pierwotną (np. zacięcie), wtórną (np. brak odbioru) i organizacyjną (np. brak operatora). Jeśli mieszasz poziomy, model będzie przewidywał to, co najłatwiej „widać” w danych, nie to, co chcesz poprawić.
- Wieloetykietowość: jedno zdarzenie ma kilka „prawidłowych” etykiet. Bez reguł priorytetu wygrasz loterię w stylu: „tym razem w raporcie poszło jako awaria, bo tak kliknęli”.