Teoria Beczki i AI

Teoria Beczki i AI: czy da się nauczyć model przewidywać wynik zamiast liczyć go od zera?

Na pierwszy rzut oka Teoria Beczki wygląda jak zwykły kalkulator internetowy. Użytkownik wpisuje kilka parametrów, klika przycisk i po chwili dostaje rekomendowaną pojemność zbiornika na deszczówkę.

W rzeczywistości pod spodem nie działa prosty wzór, ale pełna symulacja. To oznacza, że każda odpowiedź wymaga wykonania szeregu obliczeń opartych na rzeczywistych danych pogodowych. I właśnie w tym miejscu pojawia się bardzo ciekawe pytanie:

czy taki wynik da się przewidywać szybciej za pomocą modelu AI lub ML, zamiast za każdym razem liczyć wszystko od nowa?

Dlaczego ten problem w ogóle nadaje się do ML?

Model zastosowany w Teorii Beczki można potraktować jak funkcję wielu zmiennych wejściowych.

Na wejściu pojawiają się między innymi:

  • powierzchnia, z której zbierana jest deszczówka,
  • bazowy pobór wody,
  • strategia podlewania,
  • próg dnia deszczowego,
  • blokada podlewania w chłodne dni,
  • próg temperatury minimalnej,
  • parametry sezonu wegetacyjnego,
  • parametry zależności od temperatury,
  • tryb rekomendacji,
  • oraz założenia kosztowe.

Na wyjściu dostajemy natomiast konkretne wyniki użytkowe, takie jak:

  • rekomendowana pojemność zbiornika,
  • roczne wykorzystanie deszczówki,
  • poziom pokrycia potrzeb,
  • wielkość przelewów,
  • obrót zbiornika w ciągu roku.

Z punktu widzenia uczenia maszynowego to bardzo naturalny układ: mamy wektor wejść i odpowiadający mu wektor wyników.

To nie jest jeden prosty kalkulator

W tej chwili model ma ponad 20 parametrów wejściowych. Część z nich jest dyskretna, część binarna, a część numeryczna i przyjmuje wartości z dość szerokich zakresów.

Dla przykładu:

  • powierzchnia zbierania deszczówki może sensownie mieścić się w przedziale od około 20 do 400 m2,
  • bazowy pobór wody może wynosić od około 0,5 do 8 mm,
  • próg temperatury minimalnej można ustawić np. od 0 do 8°C,
  • maksymalna pojemność zbiornika może sięgać od około 500 do 30000 litrów.

Nawet po uproszczeniu i zdyskretyzowaniu tych wartości otrzymujemy bardzo dużą przestrzeń możliwych konfiguracji. To oznacza, że serwis nie przegląda kilku oczywistych przypadków, tylko porusza się w ogromnej przestrzeni możliwych ustawień.

Dlaczego obliczenia mogą być ciężkie?

Bo dla jednego zestawu wejść model nie liczy jednej liczby. Zamiast tego wykonuje całą sekwencję kroków:

  1. przyjmuje parametry użytkownika,
  2. analizuje dane historyczne dzień po dniu,
  3. symuluje działanie zbiornika dla wielu pojemności,
  4. porównuje wyniki,
  5. wybiera rekomendację,
  6. wylicza dodatkowe wskaźniki interpretacyjne.

To oznacza, że pojedyncze kliknięcie użytkownika może w praktyce uruchamiać sporą liczbę obliczeń. A jeśli takich zapytań pojawi się więcej, obciążenie serwera rośnie bardzo szybko.

Skąd pomysł na AI lub machine learning?

Skoro pełna symulacja jest dokładna, ale kosztowna obliczeniowo, to naturalnym pomysłem staje się stworzenie modelu przybliżającego. W świecie ML taki model nazywa się często surrogate model albo po prostu modelem aproksymującym.

Idea jest prosta:

  1. generujemy wiele przykładów wejść,
  2. dla każdego przykładu liczymy prawdziwy wynik backendem,
  3. budujemy zbiór treningowy,
  4. uczymy model przewidywać wynik na podstawie samych parametrów wejściowych.

Wtedy zamiast za każdym razem wykonywać pełną symulację, można w wielu przypadkach poprosić model ML o szybkie oszacowanie wyniku.

Co dokładnie miałby przewidywać model ML?

Na początek nie wszystko naraz, tylko najważniejsze wyniki użytkowe.

Najbardziej sensowny pierwszy zestaw wyjść to:

  • recommended_capacity_l – rekomendowana pojemność zbiornika,
  • used_y_m3 – roczne wykorzystanie deszczówki,
  • coverage_ratio – pokrycie planu podlewania,
  • overflow_y_m3 – roczny przelew,
  • turnover_per_year – obrót zbiornika w ciągu roku.

Taki zestaw daje bardzo dobry obraz działania systemu, a jednocześnie nie jest przesadnie rozbudowany.

Czy od razu trzeba budować sieć neuronową?

Niekoniecznie. I to jest ważna uwaga.

W praktyce przy danych tabelarycznych bardzo często warto zacząć nie od klasycznej sieci neuronowej, ale od prostszych modeli bazowych, na przykład:

  • Random Forest,
  • Gradient Boosting,
  • XGBoost lub LightGBM,
  • prostego MLP jako pierwszej wersji sieci.

Dopiero po zbudowaniu sensownego punktu odniesienia można spokojnie sprawdzić, czy pełniejsza sieć neuronowa rzeczywiście daje przewagę.

Innymi słowy: w takim projekcie AI/ML nie oznacza od razu „dużej, magicznej sieci neuronowej”. Najpierw trzeba zbudować dobre dane, dobry baseline i dobre metryki porównawcze.

Jak wygląda budowa zbioru treningowego?

Każda próbka treningowa to jeden pełny przypadek:

  • zestaw parametrów wejściowych,
  • oraz wynik policzony przez prawdziwy model symulacyjny.

Taki rekord może zawierać na przykład:

  • powierzchnię zbierania opadu,
  • strategię podlewania,
  • informację o blokadzie podlewania w chłodne dni,
  • próg dnia deszczowego,
  • tryb rekomendacji,
  • maksymalną analizowaną pojemność zbiornika,
  • oraz końcowy wynik w postaci rekomendowanej pojemności i kluczowych wskaźników rocznych.

Tych próbek trzeba wygenerować odpowiednio dużo, ponieważ model ML uczy się nie z teorii, ale z przykładów.

Dlaczego jeszcze nie warto obiecywać „ile razy szybciej”?

Bo na tym etapie uczciwie trzeba powiedzieć jedno: jeszcze nie wiemy.

To znaczy, że sam kierunek jest bardzo obiecujący, ale dopóki nie zbudujemy zbioru treningowego, nie nauczymy modelu i nie porównamy jego wyników z pełną symulacją, nie da się rzetelnie napisać:

  • o ile będzie szybciej,
  • o ile model będzie się mylił,
  • w jakich obszarach będzie działał bardzo dobrze,
  • a w jakich będzie wymagał dalszego doszkalania.

I to trzeba mieć z tyłu głowy. Celem nie jest opowiadanie marketingowej historii o „AI, która wszystko załatwi”, tylko zbudowanie rozwiązania, które będzie jednocześnie szybkie i wiarygodne.

Najbardziej realistyczny scenariusz

Najrozsądniejsze podejście wygląda tak:

  1. pełna symulacja pozostaje modelem referencyjnym,
  2. na jej podstawie budowany jest zbiór treningowy,
  3. powstaje model ML przybliżający wyniki,
  4. jego jakość jest stale porównywana z modelem dokładnym,
  5. w razie potrzeby model jest dalej doszkalany na nowych przypadkach.

Taki układ pozwala połączyć dwie rzeczy:

  • dokładność symulacji,
  • oraz potencjalną szybkość predykcji ML.

Po co to wszystko?

Bo jeśli to się uda, projekt zyska bardzo ciekawy drugi wymiar.

Teoria Beczki przestanie być wyłącznie kalkulatorem opartym na ciężkiej symulacji, a stanie się także polem do eksperymentu z praktycznym wykorzystaniem AI i machine learningu.

Nie w sensie „AI dla samego AI”, ale w sensie bardzo konkretnym:

  • mniejsze obciążenie serwera,
  • szybsza odpowiedź dla użytkownika,
  • możliwość budowy bardziej interaktywnych narzędzi,
  • oraz ciekawy most między symulacją a uczeniem maszynowym.

To dopiero początek

Najciekawsze w tym projekcie jest to, że zaczynał się od pytania o deszczówkę, a prowadzi coraz dalej:

  • do modelowania wielowymiarowej przestrzeni parametrów,
  • do kosztownych symulacji opartych na danych historycznych,
  • i w końcu do pytania, czy można nauczyć model AI przewidywać wynik szybciej, nadal rozsądnie i nadal wiarygodnie.

I właśnie dlatego ten projekt robi się coraz ciekawszy.

Bo czasem prawdziwe pytanie nie brzmi już tylko:
„jaki zbiornik wybrać?”

Ale raczej:
„czy da się zbudować inteligentny model, który nauczy się przewidywać takie rekomendacje?”