OptiMind: kiedy mały model pomaga ułożyć plan produkcji

OptiMind nie jest modelem, który „magicznie znajduje najlepszy harmonogram”. Microsoft Research opisuje go jako wyspecjalizowany model językowy przekładający problem biznesowy na matematyczną formulację dla solvera. Repozytorium OptiGuide zawiera materiały, kod ewaluacyjny i dane testowe projektu OptiMind; nie należy mylić ich z gotowym produkcyjnym solverem. Dobry wynik zależy od trzech elementów: właściwych zmiennych decyzyjnych, ograniczeń i funkcji celu. Dopiero potem solver może szukać rozwiązania.

Od rozmowy z planistą do modelu

Planista mówi: „linia A może wytwarzać dwa produkty, przezbrojenie trwa godzinę, a zamówienia pilne muszą wyjść przed piątkiem”. System powinien przetłumaczyć to na zmienne produkcji, dostępność maszyn, czas przezbrojenia, terminy i cel, np. minimalizację spóźnień. OptiMind ma pomóc w tym tłumaczeniu. Badacze opisują model oparty na 20 miliardach parametrów, trenowany na starannie przygotowanych przykładach i wspierany wskazówkami ekspertów. Jego zadaniem nie jest zastąpienie właściciela ograniczeń ani walidatora matematycznego.

Opis pilota w zakładzie rozlewniczym pokazuje znaczenie danych operacyjnych i pytań „co jeśli?”. Microsoft podaje spadek czasu nieprodukcyjnego w tym konkretnym pilocie; nie jest to uniwersalna prognoza oszczędności dla innych fabryk. Najtrudniejszą częścią okazało się połączenie systemów i utrzymanie zgodności danych z realnym stanem hali.

Jak go bezpiecznie ocenić?

Wybierz mały problem z historią decyzji. Ekspert zapisuje poprawne ograniczenia, a OptiMind przygotowuje formulację. Sprawdź, czy nie pominął reguł bezpieczeństwa, czy jednostki są spójne, czy problem jest wykonalny i czy solver daje wynik lepszy od obecnego planu. Następnie zmień jedno ograniczenie i sprawdź, czy model zachowuje logiczną ciągłość. Dopiero po takim odbiorze można używać go jako wsparcia planisty.

Alternatywą jest ręczne modelowanie w Pyomo lub OR-Tools, gotowy system APS oraz metody heurystyczne. OptiMind jest ciekawy tam, gdzie koszt sformułowania wielu podobnych problemów blokuje zastosowanie optymalizacji. Własny model operacyjny, jasna ontologia firmy i zaufane dane pozostają fundamentem; sam LLM nie wie, czy maszyna jest dziś rzeczywiście dostępna.

Trzy błędy, które trzeba wyłapać przed solverem

Pierwszy to brak ograniczenia. Model może poprawnie zapisać terminy dostaw, ale pominąć wymóg mycia linii po zmianie produktu. Solver wtedy znajdzie plan matematycznie dobry i operacyjnie niedopuszczalny. Drugi to zła jednostka: godziny w jednym źródle i minuty w drugim. Trzeci to cel sprzeczny z priorytetem firmy: minimalizacja kosztu może opóźnić kluczowego klienta, jeżeli kara za opóźnienie nie jest odpowiednio opisana. Te błędy nie znikają dzięki większej liczbie parametrów LLM.

Dlatego proces odbioru powinien mieć dwa podpisy. Specjalista od optymalizacji potwierdza poprawność zmiennych, ograniczeń i interpretację wyniku solvera. Właściciel procesu potwierdza, że model odzwierciedla rzeczywiste możliwości zakładu. Jeśli plan obejmuje decyzje bezpieczeństwa lub jakości, ich reguły muszą być twardymi ograniczeniami, nie tylko sugestią w promptcie. Wynik porównuj z dotychczasowym harmonogramem na tych samych danych wejściowych.

W scenariuszu „co jeśli” szczególnie przydatne jest zachowanie bazowej formulacji. Agent nie powinien za każdym razem wymyślać fabryki od nowa. Użytkownik zmienia jeden warunek, np. dostępność maszyny, a system pokazuje różnicę w planie i koszcie. To pozwala zrozumieć skutek decyzji i wykryć przypadki, w których zmiana jednego założenia spowodowała podejrzanie wielką zmianę wyniku.

OptiMind pokazuje obiecującą rolę małych modeli specjalistycznych: tłumaczenie języka operacji na formalny problem. Wdrożenie produkcyjne wymaga jednak żywych danych, solvera, walidatora i ścieżki zatwierdzenia. Dobrze zaprojektowany agent powinien umieć także powiedzieć, że model nie ma rozwiązania przy podanych ograniczeniach, zamiast ukrywać sprzeczność pod pozornie optymalnym planem.