Model to ta łatwa część

Operator z branży świeżej gastronomii przyszedł do nas z prostym pytaniem: czy potraficie przewidzieć jutrzejszy popyt na danie, na lokalizację, na tyle dokładnie, żebyśmy przestali wyrzucać marżę i przestali wyprzedawać się w porze lunchu? Osiemnaście miesięcy później platforma prognozuje z dokładnością 98% na produkcji. Można by sądzić, że najtrudniejszą częścią było uczenie maszynowe. Nie było.

Model, który dokonuje predykcji, to regresor oparty na gradient boostingu z doczepionymi kilkoma zmiennymi sezonowości. Kompetentny data scientist potrafi w jedno popołudnie złożyć coś z tej rodziny. My mieliśmy przyzwoitą pierwszą wersję w niespełna trzy tygodnie — wystarczająco dokładną na backteście, by wszyscy w sali pokiwali głowami.

Następnie spędziliśmy pięć miesięcy na zbudowaniu wszystkiego, co zamienia „dokładny backtest” w „liczbę, na którą kierownik operacyjny stawia cały swój dzień”. Ta luka to cała robota, a niemal nikt o niej nie pisze, bo nie jest efektowna. Więc oto ona.

01Model w trzy tygodnie

Prognozowanie popytu w stabilnym, dobrze rejestrowanym biznesie jest, szczerze mówiąc, problemem rozwiązanym. Masz cel (sprzedane jednostki), kalendarz i stos wierszy historycznych. Konstruujesz kilkadziesiąt zmiennych — dzień tygodnia, okna opóźnień, średnie kroczące, dni wolne, dołączone dane pogodowe — i pozwalasz bibliotece boostingowej znaleźć interakcje. To nie matematyka zabija projekty.

To, co tak naprawdę dały te trzy tygodnie, to pewność, że sygnał w ogóle istnieje. Backtest mówił nam, że popyt jest przewidywalny z dokładnością do jednego–dwóch punktów procentowych, pod warunkiem czystych danych wejściowych. To zielone światło. To nie jest produkt.

02Gdzie podziało się pięć miesięcy

Oto uczciwe rozliczenie kolejnych pięciu miesięcy. Nic z tego nie jest modelowaniem. Wszystko to jest tym, co uczyniło model użytecznym.

1. Ingestia, która przetrwa rzeczywistość. Strumienie sprzedaży docierają z opóźnieniem, w duplikatach albo wcale. POS się restartuje i odtwarza wczorajszy dzień. Zbudowaliśmy idempotentną ingestię, którą można bezpiecznie uruchomić ponownie i która poddaje kwarantannie wiersze, którym nie ufa, zamiast zatruwać zbiór treningowy.
2. Feature store z pamięcią. Zmienne, na których model się uczy, muszą być obliczalne w momencie predykcji, wyłącznie na podstawie danych, którymi faktycznie dysponowałbyś w tej chwili — bez zaglądania w przyszłość. Wyegzekwowanie tej poprawności point-in-time zajęło tygodnie pracy i pozwoliło wychwycić dwa wycieki, które zawyżyły pierwotny backtest.
3. Backfill i replay. Gdy historia danej lokalizacji była błędna, musieliśmy odbudować wszystkie prognozy zależne dla tej lokalizacji, nie zatrzymując systemu live. Replay to instalacja hydrauliczna, której nikt nie pokazuje na demie, a której wszyscy potrzebują.
4. Monitoring przed funkcjami. Wdrożyliśmy alarmy dryfu i świeżości, zanim wdrożyliśmy połowę interfejsu. Cicho błędna prognoza jest gorsza niż prognoza widocznie nieobecna.
5. Nadpisanie przez człowieka. Otwiera się nowa lokalizacja, wpada festiwal, zamykają drogę. Model nie może o tym wiedzieć. Planiści potrzebowali usankcjonowanego sposobu, by skorygować liczbę i sprawić, że system uczy się z tej korekty.

03Kontrakt danych

Najbardziej dźwigniowym elementem, jaki zbudowaliśmy, nie było usprawnienie modelu. Był to kontrakt danych: jawny, walidowany kontrakt schematu między każdym źródłem nadrzędnym a naszym potokiem. Typy kolumn, dozwolone zakresy, okna świeżości, polityki wartości null — wszystko zadeklarowane, wszystko sprawdzane u bramy.

Przed kontraktem prognoza mogła cicho ulec degradacji, bo dostawca POS zmienił pole waluty z centów na dolary, nie informując nas o tym. Po kontrakcie taka zmiana jest odrzucana już przy ingestii, z nazwanym i eskalowanym błędem — a ostatnia dobra prognoza pozostaje na ekranie zamiast nowej, pewnej siebie i błędnej.

# każde źródło jest walidowane u bramy, a nie po tym, jak zatruje trening
sales_daily:
  units:        int  >= 0      # odrzuca wartości ujemne — zwroty idą gdzie indziej
  revenue:      decimal(10,2)  # centy → oznaczone w v3, teraz egzekwowane
  site_id:      fk(sites)      # nieznana lokalizacja → kwarantanna, eskalacja do dyżuru
  recorded_at:  freshness <= 6h # przeterminowany strumień → zachowaj ostatnią dobrą prognozę
on_violation: quarantine + alert  # nigdy: po cichu na tym trenować

To niezbyt seksowny rdzeń każdego produkcyjnego systemu ML, jaki wdrożyliśmy. Model jest funkcją; kontrakt jest tym, co gwarantuje, że funkcja dostaje dane wejściowe, których oczekiwania ją nauczono. Pomiń go, a nie masz platformy prognostycznej — masz bardzo kosztowny generator liczb losowych, który przeważnie ma rację.

04Dryf to funkcja, nie porażka

Każdy model się degraduje. Gusta się zmieniają, pojawia się nowe menu, naprzeciwko otwiera się konkurent. Pytanie nigdy nie brzmi, czy świat usunie się spod twojego modelu — lecz czy dowiesz się o tym z dashboardu, czy z wściekłego telefonu.

Wykrywanie dryfu traktujemy jako pełnoprawną funkcję produktu. Platforma nieustannie porównuje rozkłady danych wejściowych live oraz błąd live z referencjami treningowymi. Gdy któreś z nich przekroczy próg, robi trzy rzeczy, w tej kolejności:

• Powiadamia kogoś — konkretnego człowieka, z lokalizacją, metryką i informacją, o ile się zmieniła.
• Chroni wynik — poszerzając przedziały ufności albo cofając się do prostszej, bardziej odpornej referencji, zamiast ufać modelowi, który teraz ekstrapoluje.
• Planuje ponowne uczenie — na nowych danych, warunkowane tym samym progiem backtestu, który musiał przejść oryginał.

Zwróć uwagę, że liczba na nagłówku — 98% — nie jest tą najciekawszą. Ciekawe są dwie liczby obok niej, bo to właśnie je odczuwa biznes. Dokładność jest danymi wejściowymi; mniej marnotrawstwa i mniej braków to dane wyjściowe. Platforma, która optymalizuje to pierwsze, ignorując to drugie, jest projektem laboratoryjnym.

05Dashboard, który ktoś sprawdza o 8 rano

Prognozę konsumuje szef kuchni na początku zmiany, na tablecie, z kawą w dłoni, w dziewięćdziesiąt sekund. To ograniczenie ukształtowało więcej decyzji niż architektura modelu.

Wymagało, by odpowiedź była ilością, a nie rozkładem prawdopodobieństwa. Wymagało, by „nie zgadzam się, oto dlaczego” mieściło się w jednym tapnięciu. Wymagało, by ekran pokazywał wczorajszą prognozę zestawioną z tym, co naprawdę się wydarzyło, bo zaufanie zdobywa się przez widoczną rozliczalność, a nie przez pewność siebie. Model, który nie potrafi pokazać swojej historii osobie, która na nim polega, zostanie po cichu zignorowany w niespełna tydzień.

06Notatki do naszych dawnych ja

Jeśli właśnie zamierzasz rozpocząć coś o tym kształcie, oto co powiedzielibyśmy zespołowi, który zaczął osiemnaście miesięcy temu:

• Budżetuj opakowanie, nie model. Załóż, że model to 15% wysiłku, i świadomie zaplanuj pozostałe 85%. Zespoły, które nie dotrzymują terminów, to te, które zabudżetowały odwrotnie.
• Najpierw napisz kontrakt danych. Przed jakąkolwiek zmienną. Wypatrzy wyciek w twoim backteście i uchroni cię przed wdrożeniem liczby, której nie potrafisz obronić.
• Wdróż monitoring przed interfejsem. Nie możesz operować tym, czego nie widzisz, a błędna prognoza, której nikt nie zauważył, to ten tryb awarii, który kosztuje kontrakty.
• Zaprojektuj nadpisanie. Ludzie zawsze będą wiedzieć rzeczy, których model nie wie. Daj im usankcjonowaną dźwignię i ucz się z niej, inaczej obejdą cały system w arkuszu kalkulacyjnym.
• Uczyń model rozliczalnym na ekranie. Pokaż jego historię obok predykcji. Zaufanie jest decyzją interfejsu w równym stopniu co kwestią matematyki.

Uczenie maszynowe było tą łatwą częścią. Mówimy to nie po to, by umniejszać model — jest naprawdę dobry — lecz po to, by wskazać, gdzie faktycznie leży trudność. Szum medialny sprzedaje te trzy tygodnie. Pięć miesięcy to to, za co naprawdę płacisz zespołowi inżynieryjnemu.