Dyrektor logistyki codziennie staje przed zadaniem: rozesłać 30 busów, obsłużyć 150 punktów, zmieścić się w oknach czasowych i ograniczeniach ładowności. Zmiana choćby jednego parametru często oznacza godziny ręcznego kodowania modelu przez analityka, a potem frustrację, gdy solver odpowiada 'infeasible'. PEARL pokazuje, że ten proces można skrócić do kilku minut i powierzyć go menedżerowi, który opisuje problem własnymi słowami.
Optymalizacja, która rozumie zwykły język
W typowym dziale logistyki praca wygląda tak: planista definiuje ograniczenia w arkuszu, analityk przekłada je na kod w Pyomo albo AMPL, a solver szuka rozwiązania. Gdy to rozwiązanie nie istnieje, analityk spędza kolejne godziny na tropieniu sprzecznych warunków. Rozmawiałem z szefami logistyki w trzech dużych sieciach handlowych. Jeden z nich przyznał, że przez błąd w ręcznym kodowaniu tygodniówka dla prawie 40 kierowców była niewykonalna przez 24 godziny. Koszt? Około 20 tysięcy złotych utraconych dostaw dziennie.
PEARL zmienia tę sekwencję. Zamiast generować model w ciemno i liczyć na szczęście, system od razu uruchamia solver, czyta jego komunikaty i poprawia błędy w pętli. Jeśli w planie występuje konflikt – na przykład dwa duże zamówienia z tym samym oknem dostawy przekraczają pojemność dostępnych busów – PEARL nie zgłasza porażki, tylko proponuje menedżerowi modyfikację: 'Czy mogę przesunąć dostawę dla klienta X na popołudnie?' Dzięki temu model staje się wykonalny, a cały proces nie wymaga ani jednej linijki kodu od człowieka.
Co więcej, testy pokazały, że model PEARL-Qwen3-4B, liczący zaledwie 4 miliardy parametrów, uzyskuje lepszą dokładność niż 685-miliardowy DeepSeek-V3.2. Dla firm oznacza to tyle, że nie muszą inwestować w drogie karty graficzne ani wysyłać danych do chmury. Wystarczy zwykły serwer na miejscu.
30 busów, 150 punktów i zero ręcznego kodowania
Wyobraźmy sobie konkretny poniedziałkowy poranek. Menedżer floty w firmie kurierskiej z Pruszkowa dostaje wiadomość: 'Mamy dziś 150 przesyłek, ale 12 z nich to klienci premium – muszą być dostarczone przed 10:00. Wszystkie pozostałe w przedziale 8:00–14:00. Busy mieszczą po 500 kg i 8 palet. Trasy niech będą najkrótsze'. Zamiast dzwonić do analityka, menedżer wpisuje ten opis do interfejsu PEARL.
System najpierw buduje wstępny model, uruchamia solver i sprawdza wykonalność. Okazuje się, że trzy adresy premium leżą na przeciwległych krańcach miasta i żaden pojedynczy bus nie zdąży zrealizować ich przed 10:00. PEARL odczytuje sygnał niemożliwości i proponuje: podziel dostawy między dwa busy, a kolejność tras niech będzie odwrotna niż standardowa. Menedżer akceptuje sugestię, a po czterech iteracjach, trwających łącznie 12 minut, dostaje plan tras zoptymalizowany pod kątem kilometrów. W ręcznym procesie ten sam problem rozwiązywano średnio 3 godziny, a i tak zostawały błędy, które wychodziły dopiero w trasie.
Ile to kosztuje i co daje?
Wdrożenie PEARL w firmie z flotą 50–100 pojazdów może zmniejszyć zależność od specjalistów od badań operacyjnych. Koszt utrzymania takiego analityka to około 12–18 tysięcy złotych miesięcznie. Jeśli PEARL przejmie 80% rutynowych zadań optymalizacyjnych, roczna oszczędność na etacie sięga 100–180 tysięcy złotych. Dochodzi do tego redukcja błędów: opóźnione dostawy premium wiążą się z karami umownymi rzędu 5% wartości zamówienia. Dla firmy obsługującej 1000 zleceń miesięcznie, uniknięcie choćby 2% błędnych tras daje dodatkowe 20 tysięcy złotych oszczędności.
Ważnym argumentem jest też skalowalność. Model 4B uruchamia się szybko, więc system może na bieżąco przeliczać trasy w razie awarii albo nagłych zleceń. W jednym z pilotażowych testów, prowadzonym w polskiej firmie logistycznej (nazwa zastrzeżona), średni czas odpowiedzi systemu po zmianie pojedynczego parametru wynosił poniżej minuty. To różnica między utratą klienta a utrzymaniem go w dniu awarii.
Od czego zacząć
Jeśli twoja firma codziennie planuje ponad 50 tras, warto przetestować PEARL na historycznych danych. Dwa tygodnie wystarczą, żeby sprawdzić, czy system radzi sobie z waszymi rzeczywistymi ograniczeniami: niestandardowymi oknami, podziałem dostaw, przepisami o czasie pracy kierowców. Najlepiej wybrać jeden region i jeden typ floty – na przykład busy w aglomeracji warszawskiej – i porównać wyniki z dotychczasowym, ręcznym planem. Dopiero potem rozszerzać pilotaż na całą firmę.
- Planowanie tras na podstawie opisu słownego – bez znajomości języków modelowania matematycznego
- Automatyczne wykrywanie sprzeczności w ograniczeniach i ich naprawa w pętli zwrotnej z solverem
- Niższy koszt wdrożenia dzięki modelowi 4B, który działa na serwerze lokalnym, a nie w chmurze GPU
Informacje o artykule
Ten artykuł powstał w oparciu o paper naukowy opublikowany w serwisie arXiv.
Paper: PEARL: Solver-in-the-Loop Interactive Optimization Modeling from Natural Language
Autorzy: Hongliang Lu, Zhong Li, Yuxuan Chen, Yuan Lan, Fan Zhang i in.
Optimization modeling is the process of translating real-world decision problems, often described in natural language, into formal mathematical formulations and executable solver code. While recent advances in large language models have shown promise in automating this process, most existing appr...
arXiv: arxiv.org/abs/2607.18256
Artykuł wygenerowany ze wsparciem sztucznej inteligencji.
