System MES z kaskadą AI

W opisie pozycji zamówienia handlowiec wpisywał informacje technologiczne wolnym tekstem: długości, sztuki, naddatki, cięcia pomocnicze i adnotacje dodatkowe. Ten sam sens bywał zapisany na wiele sposobów, z literówkami i bez struktury. Zbudowałem autorski system klasy MES, który przekształca taki opis w dane produkcyjne, a następnie wylicza termin realizacji wyłącznie w dniach roboczych, bez niekontrolowanej ingerencji w bazę ERP.

• 01Dane wejściowe były nieustrukturyzowane i niespójne, więc prosty parser regułowy nie dawał wystarczającej odporności.
• 02Błąd w liczbie cięć albo wymiarach przekładał się bezpośrednio na obłożenie stanowisk i deklarowany termin dla klienta.
• 03Model językowy uruchamiany dla każdej pozycji generowałby koszt nieakceptowalny przy skali operacji.
• 04Termin realizacji musiał uwzględniać realny kalendarz pracy, a nie jedynie dni kalendarzowe.
• 05Baza ERP była krytyczna dla firmy, więc odczyt musiał pozostać read-only, a zapis zwrotny ściśle kontrolowany.

Zaprojektowałem system, który działa jako warstwa własna obok ERP i wykonuje dwa zadania: ekstrakcję danych produkcyjnych z opisu wolnotekstowego oraz wyliczanie terminu realizacji w dniach roboczych, z uwzględnieniem kalendarza i logiki procesu. Sercem rozwiązania jest kaskada sześciu warstw. Każda kolejna warstwa jest droższa lub wolniejsza, dlatego uruchamia się dopiero wtedy, gdy poprzednia nie potrafi rozstrzygnąć przypadku.

• 01Normalizacja: słowniki branżowe, jednostki, usuwanie szumu i typowych literówek.
• 02Reguły deterministyczne: wzorce opisów, które można rozpoznać z pełną pewnością.
• 03Pamięć zatwierdzonych rozstrzygnięć: wykorzystanie wcześniej potwierdzonych przypadków jako bazy wiedzy.
• 04Model ML lokalny: klasyfikacja przypadków podobnych do znanych, bez kosztu zewnętrznego API.
• 05Model językowy jako sędzia: wywoływany tylko dla nierozstrzygniętej reszty, z limitem kosztu i temperaturą ustawioną na deterministyczne zachowanie.
• 06Weryfikacja człowieka: kolejka wyjątków, która domyka przypadki niejednoznaczne i jednocześnie zasila dalsze uczenie systemu.

Niezależnie od źródła decyzji, wynik przechodzi przez walidator reguł fizycznych. To on sprawdza dopuszczalne zakresy wymiarów, bilans naddatku i rzazu oraz spójność sumy operacji. Dzięki temu model nie może wypuścić wyniku, który nie zgadza się z logiką procesu.

ERP pozostaje źródłem prawdy biznesowej. System MES wykonuje szeroki odczyt tylko w trybie read-only, a całość własnego stanu przechowuje poza ERP.

• 01Dane wejściowe są synchronizowane przyrostowo.
• 02Silnik parsowania i silnik terminów działają w warstwie aplikacji .NET 8.
• 03Wyniki, modele, kolejki oraz dziennik audytowy trafiają do własnej bazy danych.
• 04Wywołanie płatnego API modelu językowego jest warunkowe i ograniczone kontrolą kosztu.
• 05Zapis zwrotny do ERP obejmuje wyłącznie jedno kontrolowane pole: termin realizacji zamówienia i daty pozycji.

To nie jest jednorazowe wdrożenie modelu. Operator zatwierdza lub poprawia wynik w ekranie weryfikacji, a dopiero zatwierdzony rekord zasila zbiór treningowy i pamięć wzorców. System uczy się więc na własnych, sprawdzonych danych, a nie na przypadkowych predykcjach.

• 01Około 67% pozycji jest rozstrzyganych deterministycznie, bez angażowania modelu ML i bez płatnego API.
• 02Baza wiedzy obejmuje ponad 200 tys. zatwierdzonych rekordów, sprowadzonych do około 34 tys. unikalnych sygnatur semantycznych.
• 03Kalendarz roboczy obejmuje 3 287 dni na lata 2023-2031, w tym 117 dni ustawowo wolnych.
• 04W zweryfikowanym zakresie projektu 100% terminów badanej puli otwartych zamówień wypadało w dniu roboczym.
• 05Zmiany są objęte automatycznymi testami regresyjnymi i wdrażane etapowo z kontrolą parytetu wyników.
• 06Wywołania płatnego API są ograniczone tylko do nierozstrzygniętej reszty, z limitem kosztu i wyłącznikiem awaryjnym.

• 01Kaskada kosztowa zamiast jednego "magicznego modelu". Większość ruchu obsługują warstwy lokalne i deterministyczne.
• 02Walidator domenowy ponad modelem. Nawet trafna predykcja językowa nie może ominąć reguł fizycznych procesu.
• 03Nienaruszalność ERP. Odczyt jest szeroki, ale read-only. Własny stan aplikacji jest odseparowany, a zapis zwrotny ma minimalny, ściśle audytowalny zakres.
• 04Uczenie na zatwierdzonych danych. Tylko rekord po weryfikacji człowieka trafia do pamięci wzorców i zbioru treningowego.