29 czerwca 2026
Niniejszy dokument stanowi szczegółowy raport końcowy z realizacji projektu obliczeniowego dedykowanego przetwarzaniu danych pogodowych na potrzeby uczenia maszynowego. Zawiera on opis architektury potoku przetwarzania (pipeline), metodologię inżynierii cech, analizę uzyskanych wyników oraz ocenę ograniczeń i potencjalnych kierunków rozwoju systemu. Dokument wraz z kodem źródłowym w pełni realizuje wymagania kursu w zakresie dokumentacji założeń, ograniczeń oraz prezentacji metryk i wniosków.
Głównym celem projektu było zaprojektowanie i implementacja powtarzalnego potoku przetwarzania danych (feature engineering pipeline), który pobiera surowe dane meteorologiczne z zewnętrznego interfejsu Weather REST API, a następnie przekształca je w ustrukturyzowaną tabelę cech (feature table) zoptymalizowaną pod kątem algorytmów uczenia maszynowego.
W ramach demonstracji praktycznego zastosowania przygotowanego potoku, zaimplementowano proces trenowania algorytmu lasu losowego (Random Forest Regressor), którego zadaniem jest prognozowanie temperatury powietrza na podstawie historycznych serii pomiarowych z danej stacji. Kluczowym aspektem projektu nie jest jednak optymalizacja samego modelu predykcyjnego, lecz stworzenie uniwersalnego i reużywalnego szablonu transformacji danych wejściowych (takich jak znacznik czasu, temperatura, wilgotność, ciśnienie, prędkość wiatru, opady czy zachmurzenie) do postaci zaawansowanych zmiennych objaśniających. Tak przygotowana tabela cech może zostać wykorzystana w innych zadaniach ML, np. w klasyfikacji typów pogody czy detekcji anomalii.
Proces rozpoczyna się od wysłania zapytania protokołu HTTP (metoda GET) do Weather REST API z uwierzytelnieniem za pomocą nagłówka Authorization: Bearer <token>.
- W przypadku poprawnej odpowiedzi serwera (status 200 OK), surowe dane są bezpośrednio konwertowane do struktury obiektu DataFrame.
Przed uruchomieniem jakichkolwiek transformacji, surowe dane wejściowe są utrwalane w formacie CSV w katalogu data/raw/. Integralną częścią tego kroku jest zapis pliku metadanych (.meta.json)zawierającym dokładny czas pobrania oraz wolumen wierszy.
Jest to kluczowy etap potoku, w którym z podstawowych serii pomiarowych generowane są zmienne prognostyczne:
- Cechy czasowe: Ekstrakcja godziny doby oraz dnia tygodnia w celu umożliwienia modelowi wychwycenia naturalnych cykli dobowych i tygodniowych w zjawiskach atmosferycznych.
- Cechy opóźnione (Lag Features): Przesunięcia czasowe wartości temperatury, wilgotności, ciśnienia oraz prędkości wiatru o odpowiednio 1, 2 oraz 3 godziny wstecz. Pozwala to modelowi na analizę trajektorii zmian w najbliższej przeszłości.
- Cechy kroczące (Rolling Features): Agregacje statystyczne realizowane w oknie czasowym, w tym: średnia temperatura z ostatnich 6 godzin, maksymalny opad z 12 godzin oraz trend ciśnienia z 3 godzin. Zapewnia to uśrednione, makroskopowe spojrzenie na dynamikę zmian atmosferycznych.
- Transformacja cykliczna kierunku wiatru: Kierunek wiatru podawany jest pierwotnie w stopniach (0° - 360°). Z uwagi na to, że wartości 359° oraz 1° są geometrycznie bliskie (kierunek północny), ale numerycznie odległe, zastosowano dekompozycję trygonometryczną. Wartość kątowa rozkładana jest na dwie składowe: sin(α) oraz cos(α).
Zapobieganie wyciekowi danych (Data Leakage): Wszystkie cechy bazujące na historii (zarówno lag, jak i rolling) są obliczane z przesunięciem
.shift(1)przed wykonaniem operacji agregacji. Gwarantuje to, że wektor cech dla chwili t nie zawiera żadnych informacji z punktu t ani z przyszłości. Zapobiega to sztucznemu zawyżeniu zdolności predykcyjnych modelu podczas fazy treningu.
Po zakończeniu fazy generowania zmiennych, dane poddawane są automatycznej walidacji jakościowej pod kątem:
- obecności brakujących wartości (NaN) oraz zduplikowanych rekordów,
- anomalii fizycznych (np. wilgotność przekraczająca 100%),
- cech o zerowej wariancji (nie niosących informacji dla modelu) oraz błędów w kalkulacji przesunięć fazowych.
Raport z walidacji jest utrwalany w pliku feature_quality_report.json, stanowiąc formalne potwierdzenie poprawności danych zasilających model.
Zweryfikowana tabela cech trafia do pliku feature_table.csv. Krok ten realizuje założenie o pełnej separacji warstwy danych surowych od warstwy danych przetworzonych.
W celu zapewnienia wysokiej transparentności rozwiązania, wygenerowano plik feature_dictionary.csv. Opisuje on każdą kolumnę pod kątem typu danych, przynależności do kategorii (bazowa, czasowa, opóźniona, krocząca, cykliczna) oraz interpretacji biznesowej. Umożliwia to łatwą rekonfigurację i użycie tabeli w innych zadaniach analitycznych bez konieczności analizy kodu źródłowego.
Podział zbioru danych został zrealizowany w porządku chronologicznym (sekwencyjnie), gdzie 80% najstarszych obserwacji stanowi zbiór treningowy, a pozostałe 20% najświeższych rekordów tworzy zbiór testowy. Taki podział jest krytyczny dla poprawności walidacji szeregów czasowych, ponieważ symuluje rzeczywiste warunki pracy modelu (predykcja przyszłości na podstawie przeszłości) i zapobiega optymistycznemu zniekształceniu wyników na skutek losowego miasta danych.
Jako model referencyjny (baseline) zastosowano algorytm RandomForestRegressor. Ocena jakości predykcji opiera się na dwóch standardowych metrykach błędu:
- MAE (Mean Absolute Error): wyrażony w stopniach Celsjusza, obrazujący średni bezwzględny błąd prognozy.
- RMSE (Root Mean Squared Error): pierwiastek błędu średniokwadratowego, wykazujący wyższą wrażliwość na duże pomyłki.
Ostatnim etapem jest automatyczne generowanie wykresu porównawczego wartości rzeczywistych oraz prognozowanych na zbiorze testowym (predicted_vs_actual.png), co umożliwia szybką, wizualną weryfikację stabilności modelu.
Prezentowane poniżej wskaźniki odzwierciedlają jeden konkretny, referencyjny przebieg potoku obliczeniowego. W warunkach produkcyjnych (przy zasilaniu świeżymi danymi z API) wartości te będą ulegały naturalnym fluktuacjom.
| Parametr / Metryka | Wartość |
|---|---|
| Źródło danych | mockapi (zależnie od dostępności) |
| Wolumen pomiarów wejściowych | 150 (identyfikator stacji: GDN_01) |
| Liczba wygenerowanych cech (kolumn) | 24 |
| Zbiór treningowy | ok. 80% danych (ujęcie chronologiczne) |
| Zbiór testowy | ok. 20% danych (ujęcie chronologiczne) |
| Błąd MAE | ~4,6°C |
| Błąd RMSE | ~5,5°C |
- Tryb awaryjny (Mock data): Dane generowane syntetycznie w przypadku niedostępności API służą wyłącznie celom weryfikacji stabilności kodu potoku. Ich profil nie odzwierciedla realnych trendów meteorologicznych, stąd metryki modelu wyznaczone na danych mock mają charakter wyłącznie poglądowy.
- Skalowanie geograficzne: Aktualna implementacja natywnie obsługuje tylko jedną stację (GDN_01). Adaptacja do środowiska wielostacyjnego wymagałaby włączenia identyfikatora stacji do przestrzeni cech (np. poprzez kodowanie One-Hot) bądź wdrożenia architektury modeli lokalnych (osobny model per stacja).
- Efekt rozgrzewki (Warm-up effect): Obliczanie cech kroczących (rolling features) powoduje utratę początkowych wierszy serii czasowej, z uwagi na brak wystarczającej historii do wyznaczenia agregacji. Skutkuje to nieznacznym uszczupleniem zbioru treningowego.
- Brak optymalizacji modelu: Algorytm RandomForest został uruchomiony na parametrach domyślnych. Nie przeprowadzono procesu strojenia hiperparametrów, co oznacza, że model nie osiągnął pełni swoich zdolności predykcyjnych.
- Ograniczenie wolumenu: Próba obejmująca jedynie 150 pomiarów uniemożliwia modelowi identyfikację makroskopowych zjawisk o charakterze sezonowym (rocznym) czy rzadkich anomalii pogodowych.
- Zaawansowana walidacja krzyżowa: Wdrożenie techniki kroczącej walidacji krzyżowej dedykowanej szeregom czasowym (np.
TimeSeriesSplitz biblioteki scikit-learn), co pozwoli na uzyskanie bardziej stabilnej oceny generalizacji modelu. - Zaawansowana detekcja outlierów: Rozszerzenie modułu kontroli jakości danych o statystyczne metody wykrywania wartości odstających, np. przy użyciu rozstępu ćwiartkowego (IQR) lub wskaźnika Z-score.
- Rozbudowa wielostacyjna: Integracja potoku z obsługą wielu lokalizacji równolegle i przeprowadzenie analizy porównawczej skuteczności modeli globalnych i lokalnych.
- Optymalizacja i benchmarking modeli: Wprowadzenie automatycznego strojenia hiperparametrów (np.
GridSearchCV) oraz ewaluacja silniejszych estymatorów, takich jak algorytmy Gradient Boosting (np. XGBoost, LightGBM), w odniesieniu do prostego modelu liniowego. - Interaktywna prezentacja wyników: Budowa responsywnego panelu menedżerskiego (dashboardu) przy użyciu frameworka Streamlit, agregującego raporty z katalogów
data/reports/idata/processed/.
Poniższa taksonomia katalogów odzwierciedla logiczny podział odpowiedzialności w projekcie:
data/raw/: Stanowi niezmienne archiwum surowych zrzutów z API wraz z towarzyszącymi plikami metadanych.data/processed/: Zawiera ostateczną tabelę cech, zwalidowany raport jakościowy oraz słownik opisujący wygenerowane zmienne.data/reports/: Miejsce docelowej agregacji artefaktów analitycznych, w tym wykresów jakości predykcji oraz niniejszego raportu.