Rozmowy o AI w zarządach energetycznych zwykle startują od ambitnych tematów: cyfrowy bliźniak elektrowni, predykcyjne utrzymanie ruchu, optymalizacja siecią w czasie rzeczywistym. Wszystkie są wartościowe. Wszystkie mają jeden wspólny problem: są projektami dwu-, trzy-, cztero-letnimi, z niepewnym ROI i koniecznością integracji z systemami, które nie były projektowane z myślą o AI.
Prognozowanie OZE jest inne. Jest to jeden z nielicznych obszarów, w którym krzywa uczenia maszynowego przebiła już kilka lat temu tradycyjne metody statystyczne i meteorologiczne, dane są dostępne, metryki są nieambigumnentne, a wartość biznesowa liczy się wprost w kosztach bilansowania.
Co się zmieniło w prognozowaniu OZE w ostatnich trzech latach
Klasyczne prognozowanie OZE oparte było na dwóch warstwach. Pierwsza warstwa — globalne modele meteorologiczne pogody (NWP, Numerical Weather Prediction), takie jak ECMWF, GFS, ICON, dostarczające prognoz pogody w skali regionalnej. Druga warstwa — lokalne modele statystyczne przekładające prognozę pogody na prognozę generacji dla konkretnej farmy. Każda warstwa miała swoje błędy, które się kumulowały.
Ostatnie trzy lata przyniosły dwie zmiany fundamentalne. Po pierwsze — modele pogody oparte na głębokich sieciach neuronowych (GraphCast od Google, AIFS od ECMWF, WeatherNext, Microsoft Aurora) dogoniły, a w wielu metrykach przegoniły tradycyjne modele NWP. I to przy czasie obliczeń rzędu sekund, nie godzin. Po drugie — ensemble dynamiczny, w którym waga poszczególnych modeli jest optymalizowana w czasie i dla konkretnej lokalizacji, stał się standardem. Dla pojedynczego punktu siatki 0,25° system potrafi powiedzieć, że w tej konkretnej lokalizacji w tej konkretnej porze roku model A jest dokładniejszy od modelu B.
Dla polskich operatorów oznacza to, że ta sama klasa prognoz, która rok temu wymagała zespołu naukowców i superkomputera, dzisiaj jest dostępna jako usługa — jeśli wie się, gdzie jej szukać i jak integrować.
Architektura nowoczesnego systemu prognostycznego
Produkcyjny system prognostyczny OZE dla polskiego operatora w 2026 roku zwykle składa się z następujących warstw.
Warstwa wejściowa — multi-model meteorologiczny. Równoległe pobieranie prognoz z kilku modeli globalnych: ECMWF AIFS, GFS, GraphCast, ICON, WeatherNext, Microsoft Aurora. Każdy ma inne mocne strony — AIFS radzi sobie dobrze z wiatrem średnich wysokości, GraphCast z strukturami synoptycznymi, GFS jest referencyjny dla operacji. Uzyskanie tych danych nie jest trywialne — wymaga albo subskrypcji, albo odpowiednich umów; dla niektórych modeli (np. ECMWF AIFS) dostępne są darmowe warstwy z ograniczeniami.
Warstwa ensemble. Dla każdego punktu geograficznego (farma wiatrowa, obszar PV) dynamiczna optymalizacja wag poszczególnych modeli. Waga zmienia się w czasie — inne modele są lepsze w sezonie letnim vs zimowym, inne dla warunków antycyklonalnych vs cyklonalnych. Optymalizacja uruchamiana jest typowo przed każdą generacją prognozy, na danych referencyjnych ERA5 z ostatnich 30-90 dni.
Warstwa post-processingu. Debiasing, stabilizacja wyników, korekty oparte na algorytmach odpornych na obserwacje odstające. To warstwa, w której doświadczenie inżynierskie liczy się bardziej niż klasyczne ML — lata obserwacji pokazują, gdzie systemy generują artefakty, które w benchmarkach akademickich są niewidoczne, a w operacjach kosztują.
Warstwa site-specific. Dla konkretnej farmy — model przekładający prognozę wiatru na prognozę generacji, uwzględniający charakterystykę turbin, efekty aerodynamiczne sąsiedztwa, historyczne dane SCADA. Model site-specific jest trenowany lokalnie i wymaga co najmniej 2-3 lat danych historycznych dla sensownego działania.
Warstwa operacyjna. Rust lub inny język wysokiej wydajności do warstwy dostępu danych; Python dla warstwy modelowej; architektura mikroserwisowa; monitoring metryk w czasie rzeczywistym. Pojedynczy cykl generacji prognozy dla setek farm musi mieścić się w minutach, nie godzinach.
Kto w polskiej energetyce tego potrzebuje i po co
Wbrew pozorom, odbiorcy prognoz OZE są bardzo różni — i każdy potrzebuje nieco innego produktu.
Operatorzy farm OZE (zarówno duże grupy: PGE, Tauron, Enea, Ørsted, jak i średnie firmy energetyczne oraz fundusze inwestycyjne). Potrzebują prognoz dla swoich aktywów w celu optymalizacji handlu na rynku bilansującym i minimalizacji kar za odchylenia. Horyzonty: intra-day, day-ahead. Wartość biznesowa: wprost mierzalna w kosztach bilansowania.
Operatorzy sieci (PSE jako OSP, operatorzy OSD). Potrzebują prognoz generacji OZE w obszarze swojej sieci do planowania rezerw regulacyjnych, zarządzania przepływami, bezpieczeństwa systemowego. Horyzonty: krótkie (minuty–godziny) dla operacji, długie (dni–tygodnie) dla planowania. Wartość: redukcja kosztów rezerw i poprawa bezpieczeństwa sieci.
Traderzy energii. Domy maklerskie energii, działy handlu w grupach energetycznych, niezależni traderzy. Potrzebują prognoz jako bezpośredniego wejścia do strategii tradingowych. Dla nich liczy się nie tylko dokładność, ale też szybkość aktualizacji i niepewność prognozy (intervalle konfidencji).
Ubezpieczyciele oferujący polisy parametryczne związane z produkcją OZE. Dla nich prognozy długoterminowe i ich rozkład są bezpośrednim wejściem w modele aktuarialne.
Dostawcy P2P i community energy. Rosnąca kategoria w Polsce — społeczności energetyczne, prosumenci biznesowi. Potrzebują prognoz w mniejszej skali, ale z wymaganiem integracji z systemami rozliczeniowymi.
Jakie metryki faktycznie warto mierzyć
Największą pułapką przy wdrażaniu systemu prognostycznego jest zakończenie rozmowy na RMSE. To jest konieczny warunek dobrego systemu, ale dalece niewystarczający.
RMSE (Root Mean Square Error) mierzy średni błąd prognozy. Dla wiatru polskiego systemy enterprise osiągają 5-8% mocy zainstalowanej dla day-ahead. To jest standard, poniżej którego trudno zejść; powyżej którego system jest słaby.
MAE (Mean Absolute Error) jest bardziej interpretowalny i lepiej koreluje z kosztem bilansowania dla operatora farmy. Kara za odchylenie jest liniowa — podwojenie błędu podwaja karę.
Skill Score — porównanie do prognozy referencyjnej (persystencja, model klimatologiczny). Skill score 30-50% oznacza, że model redukuje błąd o 30-50% względem prognozy trywialnej. To jest metryka, której ludzie z doświadczeniem energetycznym używają, bo nie zależy od absolutnych wartości.
Błąd kierunkowy (sign error rate). Dla bilansowania liczy się, czy prognoza jest systematycznie zawyżona czy zaniżona. System, który ma niski RMSE, ale konsekwentnie zawyża prognozę, jest kosztowniejszy od systemu z wyższym RMSE, ale zrównoważonym błędem.
Pokrycie interwałów konfidencji. Czy 90% intervalu konfidencji faktycznie zawiera 90% obserwacji. Model z dobrym RMSE, ale źle skalibrowanym IC, jest niebezpieczny — bo daje fałszywe poczucie pewności.
Time-to-detect. Jak szybko system reaguje na istotne zmiany (burza, przejście frontu). Dla operacji ważniejsze niż średnia dokładność.
Finansowanie — cywilne czy grantowe
Odpowiedź zależy od tego, kto wdraża. Dla dużych operatorów energetycznych (PGE, Tauron, Enea, Orlen, Ørsted) naturalnym modelem jest CAPEX/OPEX wewnętrzny — budżet IT lub budżet operacyjny działu handlu. Cykl decyzyjny 3-12 miesięcy, wdrożenie 6-12 miesięcy po decyzji. Grant dla takiego klienta nie ma sensu, bo komplikuje procurement i wydłuża timeline.
Dla średnich operatorów (regionalni deweloperzy OZE, fundusze, niezależne spółki energetyczne) sytuacja jest bardziej zniuansowana. Tu można realnie łączyć budżety własne z grantami:
FENG Ścieżka SMART — jeśli projekt ma komponent innowacyjny (nowa metoda, nowy model ensemble, adaptacja do specyfiki polskiego systemu), projekt w konsorcjum z jednostką B+R może uzyskać dofinansowanie do 140 M PLN. Sensowne dla grup, które chcą nie tylko wdrożyć, ale też rozwinąć produkt do eksportu.
KPO i NCBR — instrumenty narodowe z rotującymi konkursami dla sektora energetycznego. Mniejsze budżety, szybsze cykle.
Horyzont Europa Cluster 5 (Climate, Energy, Mobility) — dla projektów realizowanych w konsorcjach międzynarodowych. Polskie firmy AI często uczestniczą jako partnerzy technologiczni w projektach kierowanych przez większe europejskie utilities.
Modele mieszane — najciekawsze dla firm, które dopiero budują produkt: komercjalizacja z pierwszym klientem cywilnym plus grant na komponent badawczy (np. nowy typ modelu probabilistycznego). To strategia używana przez polskie startupy energetyczne z dobrym skutkiem.
Praktyczna ścieżka wdrożenia w 12 miesięcy
Typowy realistyczny plan wdrożenia systemu prognostycznego dla średniej wielkości polskiego operatora:
Miesiąc 1-2: Scoping i data baseline. Przegląd obecnych prognoz i ich jakości (RMSE, MAE, skill score na historycznych danych). Identyfikacja, gdzie leżą największe straty bilansowe. Decyzja, które aktywa są w pierwszej fali wdrożenia.
Miesiąc 3-4: POC z jednym aktywem. Jedna farma, ensemble podstawowy 3-5 modeli, porównanie z obecnym systemem na równoległych 30-60 dniach. Cel: udowodnić, że nowy system daje istotną przewagę, albo zrozumieć dlaczego nie daje (często problem leży w danych SCADA, nie w prognozie).
Miesiąc 5-7: Skalowanie na portfolio. Rozszerzenie na wszystkie aktywa, tuning site-specific dla każdego, integracja z systemami operacyjnymi (OPC, IEC 61850, API trading). Okres, w którym większość praktycznych problemów się ujawnia — nie w części ML, lecz w integracji z legacy systems.
Miesiąc 8-10: Walidacja operacyjna. System działa równolegle ze starym. Mierzone są faktyczne efekty biznesowe: redukcja kosztów bilansowania, poprawa accuracy, time-to-detect. Iteracje nad warstwą post-processingu.
Miesiąc 11-12: Pełne wdrożenie produkcyjne. Odłączenie starego systemu. Uruchomienie SLA, monitoringu, procedur eskalacji. Rozpoczęcie cyklu ciągłego doskonalenia.
Firma, która traktuje ten projekt jako 3-miesięczny sprint, prawie na pewno go spali — bo dwie trzecie realnej pracy nie leży w modelu, a w integracji, danych i operacjach.