Prediksi hujan per jam adalah salah satu tugas paling menantang di meteorologi terapan. Skala waktunya pendek, proses fisiknya non-linier, datanya sering “sparse” (banyak jam tanpa hujan), dan kualitas sensor tidak selalu konsisten. Pada saat yang sama, dampak ke pengguna—dari keputusan membawa payung hingga pengoperasian drainase—sangat nyata. Dua pendekatan yang sering dibandingkan adalah Random Forest (RF) dari keluarga pohon keputusan dan Long Short-Term Memory (LSTM) dari keluarga jaringan saraf berurutan. Keduanya kuat, tetapi kebutuhan data, cara menyiapkan fitur, dan perilaku operasionalnya berbeda. Tulisan ini membedah perbedaan itu secara praktis agar Anda tahu kapan memakai yang mana.

Mulailah dari perumusan masalah. Untuk hujan per jam, ada dua target umum: probabilitas terjadi hujan (biner: hujan/tidak) dan besaran intensitas (mm/jam). Sering kali keduanya digabung: model pertama memprediksi peluang hujan, model kedua memprediksi intensitas bersyarat jika hujan terjadi. Kombinasi ini menangani distribusi zero-inflated: mayoritas jam bernilai nol, sebagian kecil bernilai positif dengan rentang panjang.

Sumber data utama biasanya stasiun hujan (tipping bucket atau pluviograph), variabel permukaan dari reanalisis/mesoskal (mis. suhu, RH, tekanan, angin), produk satelit/radar, serta kalender musiman (bulan, hari, jam). Kualitas prediksi sangat dipengaruhi penyelarasan waktu: satukan semuanya ke UTC (atau zona baku) dan pastikan latensi satelit/radar sudah diperhitungkan. Satu offset 1 jam saja bisa menurunkan akurasi secara drastis.

Untuk Random Forest, data disajikan sebagai baris independen. Artinya, kita perlu mengekspresikan dinamika waktu lewat lag & rolling features: misalnya curah hujan 1–6 jam lalu, RH rata-rata 3 jam, gradien tekanan 2 jam, indeks konvektif jam ini, serta sinyal musiman seperti Fourier features (sin/cos untuk jam-ke-hari dan hari-ke-tahun). Dengan rekayasa fitur yang tepat, RF sangat kompetitif untuk horizon 0–6 jam (nowcasting pendek), bahkan tanpa urutan eksplisit.

Sebaliknya, LSTM memerlukan data dalam bentuk urutan: jendela 12–48 jam terakhir (sequence length) sebagai input dan satu atau beberapa jam ke depan sebagai target. Keunggulan LSTM adalah kemampuan menyerap ketergantungan jangka menengah tanpa harus menulis semua lag/rolling secara manual. Namun, ia menuntut data jauh lebih besar dan pipeline yang lebih disiplin: normalisasi fitur, batching berurutan, dan mekanisme early stopping untuk mencegah overfitting.

Ketika dataset kecil (mis. satu stasiun dengan 1–2 tahun data jam-an), RF hampir selalu menang dari sisi stabilitas dan variasi hasil. Pohon keputusan kebal terhadap skala fitur, tahan terhadap outlier sedang, dan bekerja baik di lingkungan dengan missing value yang diimputasi ringan. LSTM pada kondisi ini kerap berosilasi: validasi naik turun, dan model mudah menghafal noise.

Sebaliknya, ketika Anda punya data melimpah (banyak stasiun, bertahun-tahun, ditambah kovariat radar/satelit resolusi tinggi), LSTM mulai memperlihatkan keunggulan. Ia menangkap pola konveksi berulang, penundaan fisik antar-variabel, dan interaksi non-linier yang sulit dituangkan ke dalam rekayasa fitur tradisional. Untuk horizon 3–12 jam, terutama pada situasi konvektif tropis sore-hari, LSTM sering lebih peka terhadap fase dan intensitas.

Masalah ketidakseimbangan kelas (jarang hujan) memerlukan strategi khusus. Untuk RF klasifikasi, atur class_weight='balanced' atau lakukan resampling pintar (undersample non-hujan di sekitar kejadian hujan). Untuk LSTM, gunakan focal loss atau buat kepala ganda (multi-task): satu neuron sigmoid untuk peluang hujan, satu neuron regresi untuk intensitas. Pendekatan dua tahap ini menjaga stabilitas gradien saat mayoritas target nol.

Evaluasi tidak boleh tunggal. Untuk klasifikasi, lihat Brier score (kalibrasi probabilitas), ROC-AUC, dan PR-AUC (lebih sensitif pada data imbang-tidak). Tambahkan reliability diagram untuk menguji apakah probabilitas 0,7 benar-benar berarti “tujuh dari sepuluh jam hujan”. Untuk intensitas, MAE/RMSE relevan, tetapi pada distribusi berat-ekor pertimbangkan quantile loss (pinball) di beberapa kuantil sehingga model diajar menilai risiko tail.

Uji silang untuk deret waktu wajib memakai skema blocked/rolling/expanding window. Jangan acak baris; itu memicu leakage temporal. Pola aman: latih di 2019–2023, validasi di awal 2024, uji di akhir 2024; lalu gulir satu kuartal. Dengan cara ini, Anda menilai ketahanan musiman dan drift antar-tahun, bukan sekadar menghafal.

Dalam RF, hiperparameter penting meliputi jumlah pohon (n_estimators), kedalaman maksimum (max_depth), ukuran daun (min_samples_leaf), dan jumlah fitur per split. Biasanya 300–800 pohon sudah stabil; kedalaman jangan terlalu dangkal bila Anda memasukkan banyak interaksi musiman. Gunakan Out-of-Bag untuk estimasi cepat. Tambahkan class_weight untuk masalah biner yang timpang.

Pada LSTM, keputusan kunci adalah panjang urutan (mis. 24 jam untuk menangkap siklus diurnal), jumlah unit tersembunyi (64–256), jumlah layer (1–3), dropout (0,1–0,3), learning rate (1e-3 → 1e-4), dan batch size (32–128). Mulai dari arsitektur kecil, tambahkan kapasitas hanya saat validasi benar-benar butuh. Gunakan early stopping dengan patience 10–20 epoch dan simpan model checkpoint terbaik di validasi, bukan terakhir.

Fitur eksternal sering menentukan lompatan performa. Produk radar reflectivity dan cloud top from satellite sangat informatif untuk nowcasting; untuk horizon lebih jauh, fitur dari reanalisis (CAPE, PWAT, shear) dan gradien tekanan membantu. Bagi RF, kita injeksikan ringkasan spatio-temporal (lag, rolling, area-mean); bagi LSTM, bisa langsung diberi sebagai kanal tambahan pada setiap time-step.

Jangan abaikan metadata stasiun: elevasi, jarak ke pantai, orografi lokal, dan kelas urban/rural. Untuk RF, masukkan sebagai fitur statik; untuk LSTM, gabungkan di tiap time-step atau melalui jalur embedding statik. Metadata ini mereduksi bias lokasi yang sulit ditangkap hanya dari variabel atmosfer.

Skala & normalisasi berbeda untuk RF dan LSTM. RF tidak membutuhkan scaling dan relatif robust; LSTM wajib scaling yang konsisten (mis. z-score berdasarkan statistik pelatihan). Simpan nilai rata-rata dan deviasi standar agar inference konsisten dan pembaruan model tidak bergeser.

Kualitas data hujan itu tricky. Sensor tipping bucket punya undercatch pada angin kencang; event konvektif sering “berdenyut” (banyak nol, lalu spike). Terapkan quality control: saring spike yang tidak fisik, cek konsistensi kumulatif harian, dan deteksi jam beku (flat-line). Pada LSTM, jam beku dapat memicu gradien palsu; pada RF, dia membuat pohon belajar aturan salah.

Di produk konsumen, latency krusial. RF cepat di inference: ratusan mikro-detik per baris di CPU biasa. LSTM lebih berat, tapi masih feasible dengan optimisasi (ONNX/TensorRT) di CPU modern atau GPU kecil. Jika Anda menargetkan edge device tanpa GPU, RF memberi margin aman; LSTM memerlukan pertimbangan footprint.

Dari sisi interpretabilitas, RF unggul. Permutation importance, SHAP TreeExplainer, dan analisis partial dependence membuat tim non-ML memahami mengapa peluang hujan naik pada jam tertentu. LSTM juga bisa dijelaskan dengan SHAP/Integrated Gradients, tetapi sinyalnya lebih noisy dan interpretasi memerlukan kehati-hatian.

Soal ketidakpastian, RF punya varian Quantile Regression Forest untuk memprediksi rentang (P10–P50–P90). LSTM dapat dikuantilisasi dengan pinball loss multi-kuantil, atau dengan ensembling beberapa seed, atau MC Dropout. Interval kepercayaan praktis untuk komunikasi risiko dan untuk notifikasi yang bertanggung jawab.

Dalam produksi, pertimbangkan retraining cadence musiman (mis. bulanan/kuartalan), monitoring drift (PSI, perubahan distribusi), dan alert bila reliabilitas menurun. Simpan shadow model: model baru berjalan berdampingan beberapa minggu sebelum di-switch; bandingkan Brier, MAE, dan hit rate notifikasi.

Pendekatan hibrida sering terbaik. Lakukan nowcasting 0–2 jam dengan model radar-based atau RF kaya-lag; gunakan LSTM untuk horizon 3–12 jam. Atau bangun stacking: LSTM dan RF memberi prediksi masing-masing, lalu meta-learner (mis. Gradient Boosting) menggabungkan berdasarkan kondisi (siang/malam, musim hujan/kemarau, lokasi).

Jika Anda hanya punya satu stasiun dengan data 18–24 bulan dan tanpa radar/satelit, pilih Random Forest. Fokus pada rekayasa fitur: lag curah hujan (1–6 jam), RH/angin/tekanan (lag & rolling), fitur musiman (jam-hari, hari-tahun), dan indikator kejadian sebelumnya. Anda akan memperoleh model stabil, cepat, dan mudah dirawat.

Jika Anda memiliki puluhan stasiun, data multi-tahun, serta kanal eksternal kaya (radar, satelit, reanalisis), dan kebutuhan horizon 3–12 jam yang real-time, LSTM layak. Pastikan pipeline normalisasi, batching urutan, dan validasi rolling rapi; manfaatkan kapasitas jaringan untuk menyerap dinamika spasio-temporal yang sulit ditulis sebagai fitur manual.

Untuk kebijakan notifikasi, gunakan probabilistic thresholding. Jangan “satu ambang untuk semua lokasi”. Kalibrasikan per lokasi dengan cost matrix: mana lebih mahal—false alarm atau miss. Dengan probabilitas terkalibrasi (dari RF dengan isotonic/Platt atau dari LSTM dengan temperature scaling), pilih ambang yang memaksimalkan expected utility sesuai konteks pengguna.

Performa bukan hanya angka rata-rata. Lihat per-lokasi dan per-musim. Model yang tampak bagus secara agregat sering buruk di “kantong masalah” seperti lereng pegunungan atau tepi pantai. Gunakan spatial cross-validation bila Anda ingin mengklaim generalisasi antar-lokasi.

Secara praktis, membangun baseline RF yang kuat sebelum menulis satu baris LSTM adalah investasi terbaik. Baseline memberi Anda angka acuan, fitur penting, dan sanity check pipeline. Jika LSTM tidak mengalahkan baseline secara signifikan pada metrik yang berarti bisnis, Anda tahu jawabannya.

Ringkasnya, Random Forest unggul pada data terbatas, inference ringan, interpretabilitas, dan waktu pengembangan cepat. LSTM unggul ketika Anda memiliki urutan kaya, fitur spasial/remote sensing, dan kebutuhan menangkap dinamika non-linier di horizon beberapa jam. Banyak tim berakhir dengan arsitektur gabungan: RF sebagai fondasi yang kokoh, LSTM sebagai amplifier saat data dan infrastruktur mendukung.

Keputusan akhir seharusnya tidak ideologis, melainkan berbasis biaya-manfaat dan risiko operasional. Mulai dari baseline RF yang bersih, ukur dengan protokol evaluasi deret waktu yang ketat, lalu naikkan kelas ke LSTM saat sinyal dan sumber daya membenarkannya. Dengan disiplin data dan evaluasi yang tepat, keduanya bisa menjadi pasangan yang komplementer untuk prediksi hujan per jam yang dapat dipercaya.