AI w analizie danych transportowych: planowanie tras, predykcja opóźnień i redukcja kosztów paliwa

Czy AI ma u Ciebie „układać trasy”, „przewidywać opóźnienia”, czy „obniżać spalanie”? To nie jest pytanie retoryczne. W praktyce to trzy różne problemy, które używają podobnych danych, ale mają inne KPI, inne ryzyka wdrożeniowe i inne miejsca „styku” z dyspozytornią. Jeśli na starcie wrzuci się je do jednego worka („zróbmy AI do transportu”), kończy się zwykle jednym z dwóch scenariuszy: albo model wygląda świetnie w raporcie, a operacje nie chcą go używać, albo oszczędności są na papierze, bo nikt nie ustalił, co dokładnie mierzymy i kto może nadpisać rekomendację.

Praktyczny cel: przełożyć dane transportowe na rozwiązania, które działają w realnych warunkach (zmiany w trakcie dnia, ograniczenia pojazdów, okna czasowe, braki w telematyce), a nie tylko w notebooku. Dalej jest procedura krok po kroku z kryteriami „go/no-go”, checklistami oraz ostrzeżeniami: co może pójść nie tak i jak temu zapobiec.

predykcja ETA, prognozowanie opóźnień transportowych, optymalizacja tras VRP, telematyka GPS CAN OBD, map matching i geofencing, data leakage w modelach, walidacja czasowa modeli, integracja AI z TMS, monitoring driftu modeli, redukcja spalania floty, hybryda OR + ML, acceptance criteria POC/pilot

Pytanie decyzyjne: jaki efekt ma dać AI i gdzie „dotyka” operacji

Trzy use case’y, które łatwo pomylić (routing, ETA/opóźnienia, paliwo)

Planowanie tras (routing) to decyzja: system ma wybrać kolejność punktów, przypisać zlecenia do pojazdów, zaplanować czasy przyjazdów, uwzględnić okna czasowe i ograniczenia. Najczęściej jest to wariant VRP (Vehicle Routing Problem) z wieloma ograniczeniami. AI może tu pomagać na dwa sposoby: (1) jako „mózg” optymalizacji (OR/heurystyki), (2) jako komponent dostarczający lepsze parametry (np. czasy przejazdów i obsługi, ryzyko opóźnienia), czyli podejście hybrydowe OR + ML.

Predykcja ETA i opóźnień to predykcja: system ma oszacować czas przyjazdu lub prawdopodobieństwo spóźnienia. To nie układa planu, tylko ocenia ryzyko i wspiera reakcję (alerty, przeplanowanie, komunikacja z klientem). Największa pułapka: brak stabilnej definicji „opóźnienia” i różne źródła „czasów przyjazdu” (geofence GPS vs potwierdzenie w TMS).

Redukcja kosztów paliwa to w dużej mierze problem diagnostyczno-decyzyjny: co wpływa na spalanie (masa, prędkość, topografia, postoje na jałowym, styl jazdy), a co wpływa na koszt (cena paliwa, miejsce tankowania, rabaty, straty). Model może prognozować zużycie (np. na odcinkach) i sugerować działania: zmianę parametrów planu, coaching kierowców, politykę tankowań, ograniczenie pustych przebiegów. To wymaga innego „labelingu” niż ETA.

Gdzie model ma działać: dzień wcześniej, w trakcie dnia czy po fakcie

Wybór momentu użycia modelu determinuje dane wejściowe i sposób walidacji. Planowanie dzień wcześniej opiera się na danych znanych w momencie planowania (zlecenia, punkty, okna czasowe, dostępność floty, historyczne czasy przejazdów). Reakcja w trakcie dnia wymaga bieżącej telematyki i aktualizacji (ruch, zdarzenia, postój, realna pozycja). Analiza po fakcie (np. spalanie, przyczyny opóźnień) może używać pełnych danych z realizacji, ale wtedy łatwo o data leakage, jeśli taki zestaw wykorzysta się do modelu, który ma działać „przed zdarzeniem”.

Przykład z praktyki procesowej: dyspozytor chce wiedzieć o ryzyku spóźnienia w momencie wyjazdu z poprzedniego punktu, a nie po dojeździe do celu. Jeśli model dostaje cechy wygenerowane z „całego przejazdu” (np. średnią prędkość z trasy, która dopiero się wydarzy), wyniki będą pozornie doskonałe, a w produkcji natychmiast się posypią.

Automatyzować czy rekomendować: kto ma prawo do override

Co do zasady w transporcie dobrze działa podejście etapowe: najpierw rekomendacje + pełny override, dopiero potem automatyzacja wybranych decyzji. Tam, gdzie konsekwencje są wysokie (kary umowne, okna czasowe, ADR, ograniczenia tonażu, relacje z kluczowym klientem), system powinien umieć wskazać powód rekomendacji: „ryzyko spóźnienia rośnie przez korek na odcinku X” albo „ta sekwencja punktów minimalizuje pusty przebieg, ale zwiększa ryzyko naruszenia okna czasowego”.

Ryzyko wdrożeniowe: jeśli nie ustalisz, kto i kiedy może nadpisać model, powstaje „czarna skrzynka” z konfliktem odpowiedzialności. Dyspozytor nie zaufa, a IT nie będzie w stanie obronić decyzji modelu w rozmowie z biznesem.

Szybki test sensowności: czy problem nie leży w definicjach i danych

Zanim padnie hasło „wdrażamy AI”, zrób krótki test:

• Czy macie spójną definicję czasu przyjazdu/odjazdu (arrival/departure) i opóźnienia?
• Czy punkty (adresy) są geokodowane i stabilne, a nie „adres opisowy” bez współrzędnych?
• Czy ślady GPS mają ciągłość i poprawne timestampy (strefy czasowe, brak duplikatów)?
• Czy zlecenia mają identyfikatory, które da się jednoznacznie połączyć z telematyką i zdarzeniami?

Jeśli na któreś pytanie odpowiedź brzmi „nie”, najczęściej większy efekt daje uporządkowanie danych i procesów niż skomplikowany model.

Krok 1 — Zdefiniuj KPI i warunki sukcesu dla każdego use case (bez „optymalizacji nie tego, co trzeba”)

Routing: KPI operacyjne i jakościowe (nie tylko kilometry)

Minimalizacja kilometrów to kuszące KPI, ale często nie jest tym, co realnie boli operacje. Dobrze jest rozbić cele na metryki, które da się obronić w dyspozytorni i u klienta:

• Terminowość: odsetek wizyt w oknie czasowym, rozkład spóźnień (nie tylko średnia).
• Stabilność planu: ile zmian w planie w ciągu dnia (im więcej, tym większy chaos operacyjny).
• Puste przebiegi: km bez ładunku, czas bezproduktywny.
• Naruszenia ograniczeń: DMC/tonaż, strefy, ADR, zakazy wjazdu, preferencje klientów.
• Wykorzystanie floty: obciążenie pojazdów, balans pracy kierowców, czasy pracy.

Kryterium sukcesu powinno uwzględniać segmenty: inne warunki akceptacji dla tras miejskich (dużo stopów, duża losowość), a inne dla długich przelotów (większa przewidywalność, większy wpływ topografii i prędkości).

ETA/opóźnienia: definicja „opóźnienia” i punkt odniesienia

Opóźnienie „względem planu” i opóźnienie „względem okna czasowego” to dwa różne światy. W praktyce potrzebujesz co najmniej dwóch pojęć:

• ETA: prognozowany czas przyjazdu (continuous), aktualizowany w trakcie realizacji.
• Ryzyko spóźnienia: prawdopodobieństwo naruszenia okna czasowego lub SLA (classification).

Punkt odniesienia musi być jednoznaczny: czy „czas planowany” pochodzi z TMS (plan dyspozytora), czy z algorytmu routingu, czy z umowy (slot klienta). Bez tego modele będą „poprawiać” nie wiadomo co, a różne działy będą raportować różne wyniki.

W praktyce dobrze działa rozdzielenie: ETA do kolejnego punktu (operacyjne) oraz ETA do klienta końcowego (obsługa klienta). Te predykcje mają różne czynniki ryzyka i inny rytm aktualizacji.

Paliwo: spalanie, koszt, kontekst (ładunek, topografia, styl jazdy)

„Redukcja paliwa” bywa w firmach skrótem myślowym. Technicznie możesz optymalizować:

• Zużycie (litry): zależy od warunków jazdy, masy, topografii, stylu.
• Koszt (PLN): zależy dodatkowo od cen, miejsc tankowania, rabatów, rozliczeń.

Metryki powinny być normalizowane. l/100 km bywa mylące w przewozach o zmiennej masie. Dla części flot sensowniejsze jest l/tonokm albo przynajmniej segmentacja po typie pojazdu, rodzaju naczepy, profilu trasy i średnim obciążeniu. Bez tego model „ukarze” kierowców i pojazdy, które wożą cięższe ładunki lub jeżdżą w trudniejszym terenie.

Bramka „go/no-go” dla KPI: kiedy liczysz sukces, a kiedy przerabiasz problem

Ustal warunki, które muszą być spełnione, aby w ogóle przejść do modelowania:

• Jedna definicja arrival/departure na potrzeby ETA i opóźnień.
• Lista ograniczeń routingu spisana w formie reguł (nawet jeśli nie wszystkie będą od razu modelowane).
• Dla paliwa: decyzja, czy celem jest zużycie, koszt, czy oba (oddzielnie raportowane).

Ostrzeżenie: KPI typu „zminimalizuj koszty” bez rozpisania składników prawie zawsze prowadzą do konfliktu. Model może np. skrócić km, ale zwiększyć kary za opóźnienia; albo obniżyć spalanie kosztem większej liczby pojazdów w użyciu.

Krok 2 — Ułóż mapę danych: „must have”, „mile widziane” i test jakości zanim powstanie model

Źródła danych i typowe luki (TMS, GPS, ELD/tachograf, CAN/OBD, zdarzenia)

Najczęstszy błąd organizacyjny: start od wyboru algorytmu, zanim ktokolwiek sprawdzi, czy da się spiąć dane na poziomie pojedynczego przejazdu i stopu. Minimalny zestaw must have dla trzech use case’ów wygląda zwykle tak:

• TMS / system zleceń: zlecenia, punkty (stop), okna czasowe, planowane czasy, relacje zlecenie–pojazd–kierowca.
• Telematyka GPS: ślad z timestampem, identyfikacja pojazdu, status (jazda/postój) jeśli dostępny.
• Zdarzenia operacyjne: przyjazd/odjazd, start/koniec obsługi, potwierdzenia (jeśli są), a przynajmniej możliwość odtworzenia tych zdarzeń przez geofencing.

Mile widziane, ale często krytyczne dla paliwa i jakości ETA:

• CAN/OBD: zużycie paliwa, obroty, prędkość, jałowy bieg, gwałtowne przyspieszenia/hamowania.
• Tankowania: transakcje, miejsce, ilość, cena (jeśli liczysz koszt).
• Pogoda i ruch: w formie agregatów per odcinek/czas, nie jako „ładny widget”.
• Topografia: nachylenie, profil wysokości, szczególnie dla ciężkich zestawów.
• Parametry ładunku: masa, kubatura, typ (np. chłodnia), które zmieniają zużycie.

Typowe luki: brak jednoznacznych ID między TMS i telematyką (pojazd zmienia numer, kierowca ma kilka identyfikatorów), brak zdarzeń „departure”, adresy bez współrzędnych, brak rozróżnienia postojów planowanych i nieplanowanych.

Synchronizacja czasu, geokodowanie, map matching, geofencing

Jeśli czasy są przesunięte o godzinę (strefy czasowe, czas letni/zimowy), to ETA i opóźnienia nie mają prawa się zgadzać. Ustal jedno źródło prawdy dla timestampów i przechowuj dane w UTC, a prezentuj w lokalnym czasie. Weryfikuj też, czy telematyka i TMS używają tego samego „dnia operacyjnego” (czasem raportowanie jest odcięte np. o 4:00).

Geokodowanie jest fundamentem: bez współrzędnych nie policzysz sensownie dystansu, nie zrobisz geofence i nie przypniesz ruchu/pogody. Jeśli adresy są niestandardowe (np. „brama 3, magazyn tył”), przechowuj to jako opis, ale miej także punkt geograficzny.

Map matching (dopasowanie śladu GPS do sieci dróg) bywa opcjonalne na autostradach, ale w miastach i przy drogach równoległych robi różnicę. Bez map matchingu prędkości i dystanse potrafią być artefaktem błędu GPS. Z kolei zbyt agresywny map matching potrafi „przyklejać” pojazd do złej drogi, jeśli sampling GPS jest rzadki.

Geofencing powinien mieć zasady: promień, wielokąty dla dużych obiektów, oraz reguły rozstrzygania kolizji (dwa punkty blisko siebie). Jeśli geofence jest za duży, „arrival” będzie zbyt wczesny; jeśli za mały, przyjazdy będą „gubione”.

W praktyce dobrze działa podejście „najpierw zasady, potem piksele na mapie”: geofence musi być spójny z operacyjną definicją „jestem na miejscu”. Magazyn z wieloma bramami zwykle potrzebuje wielokąta albo kilku stref, a nie jednego koła o promieniu 300 m. Inaczej system będzie raportował „arrival” w momencie wjazdu na teren, podczas gdy SLA liczy się od podjechania pod rampę, co natychmiast psuje etykiety dla ETA i opóźnień.

Równie istotne są reguły dla „szumu”: GPS potrafi skakać, a pojazd może na chwilę wypaść poza geofence. Co do zasady ustala się więc minimalny czas przebywania w strefie oraz histerezę (inne warunki wejścia i wyjścia). Bez tego wyjdą kurioza: kilka „przyjazdów” do jednego punktu albo „odjazd” w połowie rozładunku, bo sygnał odbił się od hali.

Na tym etapie opłaca się też uzgodnić, jak łączysz ślad GPS z planem stopów. Jeśli pojazd ma dwa punkty w promieniu kilkuset metrów (np. dwa sklepy przy jednej ulicy), zwykła reguła „najbliższy geofence wygrywa” bywa niewystarczająca. Zwykle potrzebujesz priorytetów (kolejność planu, okno czasowe, typ punktu) albo jawnego „matchingu” do stopu na podstawie sekwencji. To drobiazg, który potrafi wywrócić późniejszy training set.

Test jakości danych przed modelem: spójność, kompletność, łączenie rekordów

Zanim pojawi się pierwszy notebook, dobrze jest przejść krótką, powtarzalną kontrolę jakości. Najpierw sprawy „twarde”: czy da się połączyć zlecenie–stop–pojazd–przejazd jednym kluczem lub zestawem kluczy i czy nie ma masowych rozjazdów (np. ten sam przejazd przypięty do dwóch zleceń). Jeśli łączenie odbywa się po „nazwie pojazdu” albo po ręcznie przepisywanym numerze, modele zaczną uczyć się błędnych zależności, a debug będzie praktycznie niemożliwy.

Druga warstwa to kompletność i sensowność. Braki w GPS (np. długie przerwy w śladzie) nie zawsze dyskwalifikują dane, ale muszą być jawnie oznaczone, bo inaczej algorytm potraktuje je jak „teleportację” i zaniży czasy przejazdu. Podobnie z czasami: ujemne czasy obsługi, „arrival” po „departure”, albo stop trwający 18 godzin, bo pojazd nocował w pobliżu klienta — to często poprawne operacyjnie, ale wymaga osobnej kategorii (postój planowany vs. nieplanowany) zamiast brutalnego wycięcia.

Trzecia warstwa to zgodność definicji. W praktyce bywa różnie: TMS przechowuje „planowany start” jako czas, kiedy dyspozytor kliknął „zatwierdź”, a telematyka raportuje start po ruszeniu z geofence bazy. Te dwie rzeczy nie muszą się zgadzać i nie powinny być mieszane w jednej etykiecie. Lepiej z góry ustalić, które zdarzenia są „kontraktowe” (SLA, okno klienta), a które „ruchowe” (faktyczna jazda i postoje) i trzymać je w osobnych polach, nawet jeśli na dashboardzie finalnie lądują obok siebie.

Dwa krótkie przykłady, które często wychodzą w takiej kontroli: (1) kierowca ma przerwę na pauzę w pobliżu klienta — geofence łapie „arrival”, ale rozładunek zaczyna się dopiero godzinę później; bez rozróżnienia „na terenie” vs „w obsłudze” model ETA będzie wyglądał świetnie, bo „przyjechał” wcześnie. (2) tankowanie wpisane w systemie kart paliwowych ma timestamp w strefie czasu stacji, a telematyka w UTC — bez normalizacji model kosztu paliwa dostaje losową zmienność, której nie ma w rzeczywistości.

Jeżeli na tym etapie da się jednoznacznie odtworzyć sekwencję: plan → przejazd → stop → zdarzenia i dołożyć do tego sensowne reguły czasu i geofencingu, dalsze kroki (definicje etykiet i feature engineering bez leakage) przestają być „sztuką”, a stają się rzemiosłem, które da się utrzymać w produkcji.

Krok 3 — Uporządkuj definicje i etykiety (labeling): bez tego ETA i paliwo będą „fałszywie świetne”

Najpierw decyzja: co dokładnie przewidujesz (ETA vs. opóźnienie) i w którym momencie

To, czy prognozujesz ETA (czas przyjazdu), czy opóźnienie (różnica względem planu/okna), zmienia wszystko: etykiety, cechy, a nawet to, jak dyspozytor użyje wyniku. W praktyce dobrze jest rozdzielić te dwa problemy:

• ETA: model przewiduje czas przyjazdu do kolejnego stopu (albo czas przejazdu). To daje bezpośrednio informację „kiedy będziemy”.
• Opóźnienie: model przewiduje ryzyko lub wielkość spóźnienia względem konkretnej definicji planu (plan TMS, okno klienta, SLA).

Druga oś decyzji to moment prognozy (tzw. prediction time). Ten sam stop może mieć sensowne prognozy w różnych chwilach: dzień wcześniej (plan), po wyjeździe z bazy, po poprzednim stopie, „w trasie” co 5–10 minut. Co do zasady im później, tym lepsza dokładność, ale mniejsza „sterowalność” operacyjna (mniej czasu na reakcję).

Specyfikacja etykiety w jednym zdaniu (i lista pól, które muszą istnieć)

Ustal etykietę w formie krótkiej specyfikacji, którą da się sprawdzić na danych. Przykładowo:

• ETA do stopu = timestamp pierwszego stabilnego wejścia w geofence stopu (arrival) minus timestamp chwili prognozy.
• Opóźnienie = max(0, actual_arrival − planned_arrival) albo max(0, actual_arrival − window_end) — zależnie od tego, co rzeczywiście jest rozliczane.
• Zużycie paliwa na odcinku = różnica odczytów (CAN) skorygowana o tankowania / reset licznika, przypisana do odcinka między dwoma zdarzeniami (departure→arrival).
• Koszt paliwa = zużycie × cena referencyjna albo koszt z transakcji tankowania przypisany do okresu/pojazdu (to drugie jest trudniejsze i zwykle wymaga reguł księgowych).

Żeby to działało, potrzebujesz co najmniej: actual_arrival, jakąś formę plan_time (planowany arrival lub okno), identyfikator stopu i relacji do przejazdu oraz prediction_time (zapisany jawnie, nie „w domyśle”).

Rozstrzygnij spory definicyjne: „arrival”, „service start”, „on-time”

Najczęstsze tarcie między analityką a operacjami dotyczy tego, co uznaje się za „na czas”. Magazyn może liczyć SLA od podjazdu pod rampę, klient detaliczny od wjazdu na parking, a TMS od chwili kliknięcia „arrived”. Jeśli wymieszasz te zdarzenia, model zacznie optymalizować metrykę, której nikt nie używa.

W praktyce pomaga prosta hierarchia zdarzeń na stopie:

• arrival_on_site (na terenie / w geofence),
• service_start (faktyczna obsługa),
• service_end,
• departure.

Nawet jeśli nie masz wszystkich czterech, nazwij jasno to, co masz, i nie udawaj pozostałych. Jeżeli np. masz tylko geofence, nie oznaczaj go jako „rozpoczęcie obsługi”, bo paliwo i ETA zaczną „widzieć” przestoje jako sukces operacyjny.

Oś czasu i „znane w chwili prognozy”: minimalna zasada anty-leakage w etykietach

Przy labelingu kluczowe jest, by etykieta była wyliczona wyłącznie z danych po prediction_time, a cechy wyłącznie z danych do prediction_time. Brzmi banalnie, ale w logistyce łatwo o przeciek, bo wiele pól jest uzupełnianych po fakcie (np. korekty czasów, ręczne statusy, rozliczenia).

Ostrzeżenie: jeśli w dataset’cie masz pole typu „final_status”, „delay_reason”, „podpis POD”, „czas rozładunku”, to zwykle powstaje po zdarzeniu. Użycie tego jako cechy da model „magiczne” wyniki i katastrofę po wdrożeniu.

Reguły wycinania i kategoryzacji wyjątków (zamiast losowego czyszczenia)

Zamiast usuwać wszystko, co odstaje, zdefiniuj kilka kategorii wyjątków, które mają sens operacyjny. Typowy zestaw, który upraszcza życie:

• przejazd niekompletny (brak GPS / brak arrival / brak departure),
• postój planowany (pauza, nocleg, baza) vs postój nieplanowany (awaria, korek, czekanie bez okna),
• stop wielokrotny (kilka wejść/wyjść z geofence) — trzymasz pierwszy arrival i ostatni departure, ale flagujesz jako „multi-visit”,
• zmiana planu (re-assign, reorder stopów) — osobna etykieta „plan_version” albo przynajmniej flaga, że plan był modyfikowany.

To daje dwie korzyści: (1) modele uczą się na danych, które odpowiadają rzeczywistym procesom, (2) w operacjach da się wytłumaczyć, czemu dana prognoza jest „niskiej pewności”, bo przejazd jest w kategorii wyjątku.

Checklista etykiet: zanim przejdziesz dalej

• Czy potrafisz policzyć etykiety na pojedynczym stopie i na odcinku między stopami (dwa poziomy często są potrzebne)?
• Czy etykieta „opóźnienie” odnosi się do jednego źródła planu (plan TMS / okno klienta / SLA), a nie mieszanki?
• Czy masz jawny prediction_time i potrafisz odtworzyć, co było znane w tej chwili?
• Czy wyjątki są oznaczone, a nie „wyczyszczone” bez śladu?
• Czy te same definicje działają dla różnych typów tras (linehaul, dystrybucja miejska, międzynarodówka), czy potrzebujesz wariantów?

Krok 4 — Feature engineering bez data leakage: lista kontrolna „czego model nie może zobaczyć”

Ustal „granice informacji”: co jest dozwolone na wejściu modelu

Najbezpieczniejsza praktyka to spisać kontrakt cech: lista pól dozwolonych na wejściu + zasady ich wyliczania. Dla każdego use case’u granice są inne:

• Routing: cechy planowe (punkty, okna, restrykcje, typ pojazdu), historyczne czasy odcinków, warunki ruch/pogoda w czasie planowania (jeśli planujesz na jutro).
• ETA/opóźnienia: to, co znane w chwili prognozy (ostatnia pozycja, stan trasy, opóźnienie narastające, aktualne warunki drogowe).
• Paliwo: masa/ładunek (jeśli znane), topografia, prędkości, styl jazdy (agregaty), warunki (wiatr/temperatura) — ale tylko z okresu do prediction_time.

Ostrzeżenie: jeśli chcesz prognozować paliwo „przed trasą”, nie możesz używać cech wyliczonych z jazdy (np. średnia prędkość na odcinku). To oczywiste, a i tak często wpada do pipeline’u, bo „jest w telematyce”.

Cechy dla ETA i opóźnień, które zwykle działają (i są obronne)

W logistyce sprawdzają się cechy, które opisują: kontekst stopu, kontekst trasy i kontekst czasu. Praktyczny zestaw startowy:

• Do stopu: odległość po sieci dróg (lub przybliżenie), typ stopu (załadunek/rozładunek), miasto/region, geohash.
• Okna czasowe: szerokość okna, pozycja w oknie (ile zostało do window_end), czy stop jest „na sztywno” (wąskie okno).
• Historia: mediany czasów przejazdu na podobnych relacjach o podobnej porze, typowy czas obsługi stopu.
• Trasa: numer stopu w sekwencji, liczba stopów pozostałych, dotychczasowe opóźnienie (carry-over), bufor w planie.
• Czas: dzień tygodnia, godzina, sezonowość, święta (prosto, ale z sensem).
• Ruch/pogoda: agregaty (np. poziom kongestii) dopasowane do segmentu i czasu, a nie „globalna pogoda dla kraju”.

Krótki scenariusz z praktyki: dyspozytornia widzi, że pojazd „jest w geofence” klienta, ale to parking obok, a wjazd na rampę jest po rejestracji. Jeśli cechy nie rozróżniają na terenie vs w obsłudze, model będzie uczył się, że „arrival” oznacza brak ryzyka opóźnienia, co potem psuje alerty dla klientów.

Cechy dla paliwa: rozdziel fizykę od zachowania kierowcy

W zużyciu paliwa mieszają się dwa światy: warunki „twarde” (masa, teren, prędkość) i styl jazdy. W modelu dobrze je rozdzielić, bo inaczej interpretacja i działania korygujące będą chaotyczne.

• Warunki trasy: dystans, suma przewyższeń, nachylenia, typ dróg (miejska/poza miastem/autostrada), liczba zatrzymań.
• Obciążenie: masa ładunku, typ naczepy, chłodnia (jeśli agregat), liczba osi/konfiguracja — jeśli dostępne.
• Warunki zewnętrzne: temperatura, wiatr (zwłaszcza boczny), opady; w praktyce często wystarcza temperatura i opady.
• Zachowanie: udział jałowego biegu, rozkład prędkości, gwałtowne manewry, użycie tempomatu (jeśli jest), czas na wysokich obrotach.

Ostrzeżenie: tankowania jako cecha do predykcji spalania są zdradliwe. Pojawiają się nieregularnie, bywają księgowane z opóźnieniem, a przypięcie do przejazdu bywa umowne. Jeżeli już, to traktuj je jako element rozliczenia kosztu, a nie „czysty sygnał” do modelu spalania per odcinek.

Feature store w wersji „operacyjnej”: te same agregaty w treningu i w produkcji

Najczęstsza przyczyna rozjazdu wyników między notebookiem a produkcją to inne liczenie agregatów. Żeby tego uniknąć, trzymaj jedną definicję:

• okna czasowe agregacji (np. „ostatnie 30 min jazdy”, „od ostatniego stopu”),
• zasady imputacji braków (np. brak CAN → flaga + mediany per pojazd, a nie ciche zera),
• wersjonowanie słowników (typy stopów, mapowanie klientów/regionów),
• próg świeżości danych (np. GPS starszy niż X minut → prognoza z niższą pewnością).

Lista kontrolna anty-leakage dla cech

• Czy jakiekolwiek pole jest uzupełniane po fakcie (statusy, powody opóźnień, korekty)? Jeśli tak, nie może być cechą online.
• Czy cecha nie zawiera „zaszytego wyniku”, np. plan_vs_actual policzonego już po dojeździe?
• Czy cechy z ruchu/pogody są pobierane z tego samego momentu, w którym prognoza miałaby być wykonana (a nie z danych historycznych „po zdarzeniu”)?
• Czy agregaty z telematyki (prędkości, postoje) są liczone do prediction_time, a nie do końca przejazdu?
• Czy masz flagi braków (missingness) zamiast udawania, że brak = 0?

Jeżeli na tym etapie potrafisz wskazać dla losowego przejazdu: (1) prediction_time, (2) komplet cech dostępnych w tej chwili, (3) etykietę policzoną po zdarzeniu — to zwykle oznacza, że fundament pod modelowanie jest stabilny i da się przejść do wyboru podejścia (heurystyki/OR, ML albo hybryda) bez ryzyka, że „wyniki są świetne, tylko niefortunnie nie działają w operacjach”.

Krok 5 — Wybór podejścia: heurystyki, OR, ML czy hybryda (i kiedy które przegrywa)

Pytanie startowe: jaką decyzję ma podjąć system i jak często będzie się zmieniać?

To rozstrzyga, czy inwestować w optymalizację (OR/VRP), predykcję (ML), czy połączyć oba. Najczęstsze trzy typy decyzji w transporcie:

• Decyzja planistyczna (dzień wcześniej / rano): układ stopów, przydział pojazdów, okna czasowe, bufor.
• Decyzja dyspozytorska (w trakcie dnia): „czy przeplanować?” i „kogo ostrzec?” po zdarzeniu (korek, awaria, opóźniony załadunek).
• Decyzja rozliczeniowa/zarządcza (po fakcie): analiza paliwa, styl jazdy, odchylenia od planu, reklamacje.

Jeśli decyzja ma się zmieniać często (co 5–10 minut) i zależy od zdarzeń, to zwykle wygrywa hybryda: heurystyka/VRP daje plan bazowy, a ML dokłada sygnał ryzyka i przewidywania (ETA, opóźnienie, paliwo), które sterują przeplanowaniem.

Routing: kiedy heurystyka wystarczy, a kiedy potrzebujesz VRP „na serio”

Co do zasady routing to nie jest „problem ML”, tylko problem optymalizacji pod ograniczeniami. ML pomaga wtedy, gdy ma dostarczyć parametry do optymalizacji: czasy przejazdu zależne od pory, ryzyko spóźnienia, czas obsługi stopu, zużycie paliwa na odcinku.

• Heurystyka (prosta) — sensowna, gdy: mało ograniczeń, mało stopów, trasy powtarzalne, a dyspozytor i tak ręcznie poprawia 20% przypadków.
• VRP/OR — potrzebne, gdy: wiele okien czasowych, twarde restrykcje (ADR, chłodnia, zakazy wjazdu), wysokie koszty pustych przebiegów, a planowanie ma być powtarzalne i audytowalne.
• Hybryda VRP + ML — praktyczna, gdy: czasy i obsługa stopów są zmienne i „zjadają” bufory; wtedy model ETA/stop service time karmi solver, a solver planuje realistycznie.

Ostrzeżenie: „VRP w notebooku” często nie uwzględnia miękkich ograniczeń (preferencje klientów, stałe pary kierowca–trasa, zasady pracy). Jeżeli te reguły są realne, trzeba je modelować jako koszty/priorytety, inaczej dyspozytornia odrzuci plan nawet przy lepszych kilometrach.

ETA i opóźnienia: klasyfikacja ryzyka vs regresja czasu

W operacjach zwykle potrzebujesz dwóch odpowiedzi naraz: kiedy dojedzie i czy jest ryzyko naruszenia okna/SLA. Najbezpieczniejszy układ to dwa modele lub jeden model, ale dwa wyjścia:

• ETA (regresja): przewidywany czas przyjazdu, ewentualnie przedział ufności (quantile regression).
• Ryzyko spóźnienia (klasyfikacja): prawdopodobieństwo przekroczenia deadline’u (np. window_end), które łatwo „przetłumaczyć” na alerty.

Ostrzeżenie: sama regresja ETA bywa myląca, bo „średnio trafia”, ale nie chroni przed najdroższymi przypadkami (spóźnienia). Jeśli dyspozytor ma reagować, potrzebuje progu ryzyka i jasnej reguły eskalacji.

Paliwo: prognoza kosztu czy kontrola stylu jazdy?

Najpierw rozdziel, czy celem jest prognoza kosztu paliwa na trasę (planowanie), czy redukcja spalania w wykonaniu (operacje). To różne momenty decyzji i inne cechy:

• Przed trasą: model oparty o trasę, masę, topografię, typ pojazdu, sezon. Wynik: spodziewane zużycie i koszt.
• W trakcie: monitoring odchylenia od oczekiwanego spalania (anomaly / drift), sygnały stylu jazdy i postoju na biegu jałowym.
• Po trasie: analiza przyczyn (segmenty drogi, postoje, nadmierne prędkości) i decyzje szkoleniowo-procesowe.

W praktyce najszybszy zwrot daje podejście „budżet paliwa + odchylenia”: wyliczasz oczekiwane spalanie na segmenty i szukasz różnic, zamiast próbować od razu zbudować jeden wielki model „na wszystko”.

Checklista wyboru podejścia (go/no-go)

• Czy znasz decyzję, którą ma wesprzeć system (plan, przeplanowanie, alert, budżet paliwa), a nie tylko „chcemy AI”?
• Czy ograniczenia są twarde (nie do złamania) czy miękkie (preferencje)? Solver i UI muszą to rozróżniać.
• Czy problem jest statyczny (plan raz dziennie) czy dynamiczny (ciągłe zmiany)?
• Czy zespół akceptuje, że ML dostarcza predykcje + niepewność, a nie jedną „prawdę”?
• Czy masz plan na override (kto i kiedy może ręcznie zmienić rekomendację) i zapis tych decyzji?

Krok 6 — Walidacja „jak w życiu”: podział czasowy, cold start i drift

Ustaw walidację w osi czasu, nie losowo

W transporcie dane mają sezonowość, zmieniają się kontrakty, dochodzą klienci i kierowcy. Losowe dzielenie train/test niemal zawsze zawyża wyniki. Minimalny standard:

• Train: starsze tygodnie/miesiące,
• Validation: nowszy wycinek (strojenie),
• Test: ostatni spójny okres (symulacja produkcji).

Jeśli prognoza ma działać „na dziś”, test powinien obejmować okres z takimi samymi ograniczeniami informacyjnymi (czyli cechy wyliczone do prediction_time), inaczej wraca leakage tylnymi drzwiami.

Testy odporności: nowe trasy, nowi kierowcy, nowe regiony

Same metryki globalne rzadko wystarczają. Zwykle potrzebujesz kilku „przekrojów”, które odpowiadają realnym ryzykom wdrożeniowym:

• Cold start: klienci/relacje, których nie było w treningu (czy model degraduje się łagodnie?).
• Nowi kierowcy/pojazdy: brak historii stylu jazdy i brak telematyki w części floty.
• Różne typy tras: city distribution vs linehaul; osobne progi alertów bywają konieczne.
• Zmiana procesu: np. nowa definicja statusów w TMS, nowy geofencing, nowe okna czasowe w kontrakcie.

Ostrzeżenie: dobry wynik na „średniej” może ukrywać porażkę na trasach o najwyższym koszcie błędu (np. dostawy z karami umownymi). W testach trzymaj osobną metrykę dla takich zleceń.

Metryki, które lepiej odpowiadają operacjom (i jak ich nie zepsuć)

Dla ETA i opóźnień najczęściej działają mieszane zestawy metryk: jedna „ciągła” + jedna „decyzyjna”. Przykładowo:

• ETA: MAE/MedAE (mediana błędu) + pokrycie przedziałów (jeśli robisz kwantyle).
• Ryzyko spóźnienia: AUC/PR-AUC (gdy klasa jest rzadka) + kalibracja (czy 0.7 znaczy ~70%).
• Paliwo: błąd względny per 100 km lub per odcinek + błąd skumulowany na trasę (bo rozliczenie jest „na trasę”).

Do tego dodaj metrykę „operacyjną”: ile alertów dziennie przy danym progu i jaki odsetek to fałszywe alarmy. Model, który generuje 200 alertów na zmianę, przestaje istnieć w praktyce — dyspozytornia go „wyciszy”.

Walidacja przeplanowania: symulacja zamiast wiary w optymalizator

Jeśli celem jest dynamiczny routing lub rekomendacje przeplanowania, same metryki predykcyjne są niewystarczające. Potrzebujesz symulacji „co by było, gdyby”:

• odtwarzanie dnia operacyjnego (zdarzenia w czasie),
• uruchamianie rekomendacji na tych samych punktach decyzyjnych,
• liczenie efektu na KPI: spóźnienia, km, puste przebiegi, czas pracy.

Ostrzeżenie: symulacja jest tak dobra jak definicja „co dyspozytor wiedział wtedy”. Jeśli w replay’u użyjesz danych, które pojawiły się godzinę później (np. statusy ręczne), wyjdzie „system działa genialnie”, a na produkcji nie.

Lista kontrolna walidacji

• Czy test jest czasowy (train → test), a nie losowy?
• Czy potrafisz policzyć metryki osobno dla: top klientów, tras z karami, dystrybucji miejskiej, linehaul?
• Czy model ryzyka jest skalibrowany (prawdopodobieństwa mają sens), czy tylko „sortuje” przypadki?
• Czy znasz koszt błędu: co jest gorsze — fałszywy alarm czy brak alarmu — i masz pod to próg?
• Czy masz test na drift: zmiana rozkładu cech (np. nowa flota, nowy region, zmiana paliwa/temperatury)?

Krok 7 — Integracja z operacjami: SLA danych, alerty, override i odpowiedzialność

Najpierw „jak to żyje w dyspozytorni”, dopiero potem API

Model w transporcie zwykle nie „podejmuje decyzji sam”, tylko wchodzi w proces. Minimalny projekt operacyjny obejmuje:

• moment wyliczenia (np. przy przyjęciu zlecenia, po wyjeździe, co 10 minut w trasie),
• kanał podania wyniku (TMS, panel dyspozytorski, e-mail/SMS do klienta, webhook),
• akcję (alert, rekomendacja przeplanowania, propozycja bufora, propozycja tankowania/strategii prędkości),
• kontrolę (kto akceptuje/odrzuca; jak rejestrować override i powód).

Krótki scenariusz: jeśli ETA aktualizuje się co kilka minut i „skacze”, a system wysyła automatyczne powiadomienia do klienta, pojawią się reklamacje. Zwykle potrzebujesz stabilizacji: minimalna zmiana do wysyłki, cooldown, lub komunikacja w przedziałach („między 10:20 a 10:40”).

Kontrakt danych i SLA: bez tego monitoring jest iluzją

Operacyjnie liczy się nie tylko trafność, ale też świeżość i kompletność danych. Ustal proste SLA:

• GPS: maksymalny wiek pozycji (np. X minut) i co robić, gdy jest starszy (degradacja prognozy, fallback do planu).
• TMS: opóźnienia w statusach i planach (czy plan jest finalny, czy „w budowie”).
• Telematyka/CAN: dostępność dla części floty; jawne flagi braków.
• Dane zewnętrzne: ruch/pogoda — limit opóźnień i fallback na historyczne mediany.

Ostrzeżenie: jeżeli model „potrzebuje” telematyki, a w praktyce 15–30% przejazdów jej nie ma (awarie, roaming, wyłączone urządzenie), system bez planu awaryjnego będzie generował dziury w procesie, które dyspozytornia szybko obejdzie ręcznie.

Rekomendacje, które da się egzekwować: nie tylko „zmień trasę”

Rekomendacja jest użyteczna dopiero, gdy da się ją wykonać w realnych ograniczeniach. Dobre praktyki:

• zawsze pokazuj powód (np. „ryzyko spóźnienia rośnie przez kongestię na A2; bufor w oknie = 15 min”),
• podawaj alternatywę w języku operacyjnym (zmiana kolejności stopów, wcześniejszy przyjazd do stopu bez okna, postój planowany w innym miejscu),
• dodaj pewność albo kategorię (standard / niska pewność przez brak GPS).

Checklista wdrożeniowa „minimum produkcyjne”

• Czy wynik modelu jest widoczny w tym samym narzędziu, w którym pracuje dyspozytor (a nie w osobnym dashboardzie)?
• Czy masz fallback (plan TMS, mediany historyczne) przy brakach danych?
• Czy logujesz: wejścia (cechy), wynik, wersję modelu, decyzję (akcept/override) i outcome?
• Czy alerty mają progi, cooldown i mechanizm „ciszy”, żeby nie zabić procesu?
• Czy w organizacji jest jasne, kto odpowiada za decyzję (system doradza vs system decyduje)?

Jeśli wdrożenie ma obejmować automatyczne akcje (np. wysyłkę ETA do klienta albo automatyczne przeplanowanie), potrzebujesz jeszcze jednego elementu: bramki bezpieczeństwa. W praktyce jest to zestaw prostych reguł „kiedy wolno działać”, np. tylko przy wysokiej pewności prognozy, tylko gdy odchylenie od planu przekracza próg, tylko gdy statusy są spójne (brak konfliktu: „załadowano” vs brak wyjazdu z geofence). Bez takiej bramki system potrafi być jednocześnie bardzo „inteligentny” i bardzo uciążliwy.

Drugim krytycznym składnikiem jest rejestrowanie odpowiedzialności w sposób użyteczny operacyjnie, nie tylko audytowy. Log „override = tak/nie” bywa za mało. Co do zasady warto przechwycić krótki powód z kontrolowanej listy (np. „klient przesunął okno”, „brak kontaktu z kierowcą”, „wypadek/objazd”, „błąd danych: zły adres”), bo te przyczyny wracają później jako konkretne zadania: poprawa danych, zmiana progu, dodatkowa cecha, zmiana procesu w TMS. To też pomaga uczciwie ocenić model — czasem „błąd” to tak naprawdę zmiana warunków, o której system nie mógł wiedzieć.

Trzecia rzecz: monitoring w języku dyspozytorni, a nie tylko w języku data science. Poza klasyczną trafnością zwykle monitoruje się: odsetek przejazdów z fallbackiem (np. bez GPS), liczbę alertów na zmianę, medianę czasu reakcji na alert i „przydatność” (jaki odsetek alertów kończy się akcją). Jeśli nagle rośnie udział fallbacku, to często nie jest „problem modelu”, tylko roaming, awarie urządzeń albo nowy podwykonawca bez telematyki. Wykres MAE tego nie powie.

W praktyce dobrze działa prosta zasada: najpierw stabilność, potem finezja. Lepiej mieć przewidywalny, nieco mniej „sprytny” model z jasnymi limitami i sensownym fallbackiem niż system, który czasem daje świetne wyniki, a czasem generuje chaos (bo zadziałał na nieaktualnych statusach albo na częściowo pustych danych). Gdy proces jest poukładany, dopiero wtedy opłaca się dokładać bardziej agresywne optymalizacje, np. dynamiczne przeplanowanie co kilka minut.

Jeśli trzeba wybrać jedną rzecz, która najczęściej decyduje o powodzeniu, to jest nią spójność „trójkąta”: KPI → dane w odpowiednim czasie → decyzja, którą da się wykonać. Gdy te trzy elementy pasują do siebie, ETA przestaje być ciekawostką, predykcja opóźnień przestaje być „kolejnym alertem”, a redukcja paliwa staje się efektem procesu, a nie obietnicą modelu.

Krok 8 — Policzenie efektu biznesowego: jak nie „zjeść” oszczędności na papierze

Najpierw zakres: co dokładnie jest wliczane do efektu

Pytanie kontrolne, od którego zwykle zależy sens projektu: czy liczysz efekt na poziomie pojedynczego przejazdu, zlecenia, czy całej zmiany/tygodnia? W transporcie wiele kosztów kompensuje się w czasie (np. opóźnienie dziś → kara, ale też „odzyskanie” jutro przez inną alokację). Żeby porównanie miało sens, ustal ramy:

• Routing: km płatne vs puste, liczba przejazdów, łączny czas pracy, naruszenia okien czasowych.
• Opóźnienia: kary i koszty obsługi reklamacji, koszt „przyspieszania” (np. dodatkowy kierowca, ekspresowy przeładunek), utrata jakości SLA.
• Paliwo: litry/100 km lub koszt paliwa na km, ale też koszty uboczne (np. częstsze tankowania, wybór droższych stacji, wpływ na czas i okna).

Ostrzeżenie: redukcja km nie zawsze redukuje paliwo, a redukcja paliwa nie zawsze redukuje koszt. Przy różnicach cen paliwa, opłatach drogowych, topografii i prędkościach wynik potrafi się odwrócić. Dlatego w modelu efektu trzymaj osobno: litry, koszt i czas.

Metodyka porównania: baseline operacyjny, a nie „średnia z miesiąca”

Najbezpieczniej porównać wynik do sensownego punktu odniesienia:

• Baseline „plan TMS”: co wyszło z planowania bez AI (albo z heurystyki), a potem porównać do rekomendacji AI.
• Baseline „to, co zrobiono”: rzeczywiste wykonanie (z telematyki) vs alternatywa w symulacji.
• Baseline segmentowy: osobno linehaul, dystrybucja miejska, stałe trasy, podwykonawcy; łączenie tego w jedną średnią zwykle maskuje problem.

Jeśli nie możesz zrobić klasycznego A/B (bo dyspozytorzy „podglądają” i kopiują decyzje), praktycznym kompromisem bywa rollout falowy: włączasz rekomendacje etapami (regiony/zmiany/klienci) i porównujesz do okresu „tuż przed” przy podobnych warunkach.

Krótka checklista rachunku efektu

• Czy KPI jest liczony na tym samym poziomie agregacji, na którym powstaje koszt (zlecenie/trasa/zmiana)?
• Czy rozdzielasz efekt w paliwie od efektu w czasie (bo „oszczędność” może generować spóźnienia)?
• Czy w analizie uwzględniasz koszty wdrożenia operacyjnego: czas dyspozytora, szkolenie, obsługa wyjątków?
• Czy masz segment „podwykonawcy / brak telematyki” i liczysz tam osobny efekt (często bliski zeru)?

Krok 9 — POC → pilot → produkcja: bramki decyzyjne i kryteria go/no-go

POC: udowodnij, że problem jest „modelowalny” na Twoich danych

POC ma odpowiedzieć na jedno pytanie: czy na dostępnych danych da się uzyskać stabilny sygnał, który ma sens operacyjny. Minimalny POC w transporcie zwykle obejmuje:

• 1–2 use case’y (np. ETA + ryzyko spóźnienia dla jednego typu operacji),
• baseline (reguły / mediany historyczne) + jeden model ML (np. GBM),
• walidację czasową i segmentową,
• sprawdzenie dostępności danych „w czasie” (czy to, co jest w hurtowni, będzie dostępne live).

Bramka go/no-go dla POC: wynik nie musi być „spektakularny”, ale musi być powtarzalny i możliwy do zasilenia w operacjach. Jeśli metryki są dobre tylko wtedy, gdy używasz pól uzupełnianych po fakcie, to jest sygnał, że najpierw trzeba naprawić proces/statusy, a nie „tunować model”.

Pilot: włącz człowieka w pętlę i mierz reakcję, nie tylko trafność

W pilocie liczy się odpowiedź na dwa pytania: czy dyspozytornia korzysta i czy da się to utrzymać w rytmie pracy. Często pilot kończy się porażką nie przez model, tylko przez integrację i „przeciążenie uwagą”.

• Ustal godziny i zakres działania (np. tylko wybrane klienckie SLA, tylko wyjazdy w określonych godzinach).
• Wprowadź override z powodem oraz prosty feedback: „przydatne/nieprzydatne”.
• Mierz czas do reakcji i odsetek akcji po alercie, nie tylko MAE.

Ostrzeżenie: jeśli alerty są poprawne, ale pojawiają się za późno (np. 5 minut przed oknem), dyspozytor i tak nie ma ruchu. W pilocie warto więc mierzyć „czas na działanie”: ile minut przed przewidywanym naruszeniem okna model zwykle ostrzega.

Produkcja: formalizuj odpowiedzialność i plan utrzymania

Po stronie technicznej „produkcja” to monitoring, retraining i kontrola wersji. Po stronie operacyjnej to jasne zasady: kto reaguje, jak szybko i co robi w typowych wyjątkach. Minimalny zestaw ustaleń:

• Runbook: co robić przy brakach GPS, braku statusów, awarii dostawcy ruchu/pogody.
• Okna aktualizacji: kiedy i jak często odświeżasz model/parametry, co jest „zamrożone” (np. definicje etykiet).
• Limity automatyzacji: które akcje są automatyczne, a które zawsze wymagają akceptu.

Krok 10 — Najczęstsze awarie „w realu” i szybkie procedury naprawcze

Problem: „Model był świetny w testach, a teraz jest losowy”

Najczęstsza przyczyna to zmiana rozkładów albo cichy błąd w danych (np. nowy dostawca GPS, inne częstotliwości pingów, zmiana geofencingu). Procedura diagnostyczna:

1. Sprawdź odsetek fallbacku (braki GPS/telematyki/statusów) dzień do dnia.
2. Porównaj rozkłady kluczowych cech (wiek GPS, prędkość, liczba postojów, typ pojazdu, region).
3. Sprawdź, czy nie zmieniła się definicja etykiety (np. „opóźnienie” zaczęto liczyć od innego statusu).

Szybka poprawka: włącz „tryb ostrożny” — wyższy próg alertów, dłuższy cooldown, częstszy fallback do median. To bywa lepsze niż utrzymywanie agresywnej automatyzacji na danych, które chwilowo nie mają jakości.

Problem: „Dyspozytorzy ignorują rekomendacje, mimo że są trafne”

W praktyce to zwykle kwestia formy, czasu lub wykonalności. Sprawdź trzy rzeczy:

• Czas: czy rekomendacja przychodzi, gdy da się jeszcze działać?
• Kontekst: czy widać powód i wpływ na KPI (np. „zmiana kolejności stopów zmniejsza ryzyko spóźnienia dla klienta X”)?
• Wykonalność: czy rekomendacja uwzględnia realne ograniczenia (pauzy, zakazy, dostępność rampy, preferencje klienta)?

Krótki scenariusz z życia: system proponuje objazd „bo szybciej”, ale dyspozytor wie, że na tej drodze pojazdy ciężkie regularnie utkną na ograniczeniach. Jeśli takie ograniczenia nie są w danych, rekomendacja będzie przegrywać z doświadczeniem. To nie jest „opór przed AI”, tylko brak modelowania ograniczeń.

Problem: „Oszczędzamy paliwo, ale rośnie liczba spóźnień”

To klasyczny efekt optymalizacji jednej zmiennej. Naprawa jest proceduralna:

1. Rozdziel decyzje: strategia paliwowa (gdzie tankować, jak prowadzić) nie powinna psuć okien czasowych.
2. Wprowadź ograniczenia twarde (np. „nie wolno zwiększyć ryzyka spóźnienia powyżej X”) albo funkcję kosztu łączoną (paliwo + kara za spóźnienie).
3. Dodaj raport „koszt alternatywny”: ile paliwa „oszczędzono” kosztem ilu naruszeń okna.

Ostrzeżenie: jeśli etykieta „spóźnienie” jest niedookreślona (np. liczone do czasu zamknięcia zlecenia, a nie do okna), model będzie premiował zachowania, które w dyspozytorni wyglądają jak błąd.

Procedura końcowa: 30-minutowy przegląd gotowości przed podjęciem ryzyka produkcyjnego

Jeżeli trzeba szybko ocenić, czy rozwiązanie jest gotowe na realny ruch, zwykle wystarcza krótki przegląd „na twardo”:

1. Cel: czy KPI są rozdzielone na routing/ETA/paliwo i nie gryzą się między sobą?
2. Dane: czy masz SLA świeżości i kompletności oraz jawny fallback dla braków?
3. Walidacja: czy test jest czasowy i liczony per segment, a nie tylko „globalnie”?
4. Operacje: czy alert ma próg, cooldown i jest w narzędziu dyspozytora?
5. Odpowiedzialność: czy override ma powód, a outcome wraca do oceny modelu?

Jeśli którykolwiek punkt wypada słabo, zwykle rozsądniej jest ograniczyć zakres (mniej automatyzacji, węższy segment, większe progi) i dopiero potem zwiększać „moc” systemu. W transporcie najdroższe bywają nie błędy predykcji, tylko błędy procesu, które model przyspiesza.