Sebuah mobile app berbasis AI yang lahir dari mengikuti IDCamp 2025 Developer Challenge: Small Apps for Big Preparedness, untuk mengisi kegiatan selama libur hari raya idul fitri.
Ada satu hal yang sering luput dari berita pascabencana. Kita ngeliat angka korban, foto reruntuhan, laporan kerugian—tapi jarang yang ngomongin bottleneck paling mendasar di lapangan: prioritasi. Tim relawan datang ke lokasi. Ada ratusan bangunan rusak. Mana yang runtuh total? Mana yang masih bisa dihuni? Mana yang butuh bantuan logistik paling cepat? Sekarang prosesnya manual—jalan dari satu bangunan ke bangunan lain, menilai dengan mata, mencatat di kertas atau spreadsheet.
Di situasi darurat, lambat itu mahal. Kadang mahal banget.
Kizukai—kepedulian dalam Bahasa Jepang—adalah myJawaban. Idenya sederhana: Foto → AI analisa tingkat kerusakan → Form laporan terisi otomatis. Relawan tinggal ambil foto bangunan, AI ngeklasifikasiin kerusakannya ke skala DS0 (tidak rusak) sampai DS4 (hancur total), dan data langsung masuk ke sistem prioritisasi bantuan. Yang biasanya butuh puluhan menit per bangunan, jadi hitungan detik.
Di atas kertas, idenya bersih. Implementasinya? Lain cerita.
Percobaan pertama dimulai dengan rasa percaya diri yang, kalau dipikir ulang, agak kurang realistis.
Aku pilih MobileNetV3Small sebagai backbone. Masuk akal—arsitekturnya ringan, didesain buat mobile inference, dan banyak dipakai di aplikasi edge computing. Dataset-nya aku ambil dari Roboflow: koleksi gambar bencana Hurricane, Tornado, sama Earthquake yang labelnya udah rapi. Training jalan. Loss-nya turun. Metrik validasinya kelihatan oke.
Sampai aku coba inference di luar gambar-gambar training itu.
Hasilnya buruk. Bukan buruk dalam artian “perlu di-fine-tune”—tapi buruk dalam artian model ini dengan percaya diri menebak buta gambar. Ini bukan underfitting di mana model terlalu ragu. Ini overfitting klasik—model ngapalin jawaban, bukan belajar konsepnya. Dia hapal dataset-nya sampai hafal di luar kepala, tapi nggak bisa generalisasi ke dunia nyata.
Setelah dibedah lebih jauh, masalahnya adalah kapasitas MobileNetV3Small memang terlalu terbatas buat problem ini. Deteksi kerusakan bangunan itu subtle—crack di dinding, deformasi struktur, atap yang sebagian runtuh—semua ini butuh representasi fitur yang lebih kaya dari yang bisa MobileNetV3 tangkap.
myStrategigw: gabungkan tiga dataset dari sumber berbeda untuk dapat variasi yang lebih luas secara global.
- TornadoNet Dataset dari HuggingFace
- All Hurricane / Tornado / Earthquake dari Roboflow
- Building Damage Assessment dari Roboflow
Dataset pertama yang berisi 3 ribu gambar didominasi rumah Amerika, bukan Indonesia, harapannya dengan penambahan dataset kedua dan ketiga yang kerusakan bangunannya lebih jelas dapat menambah variasi pada dataset.
Kedengarannya tinggal download, merge, train. Tapi begitu aku buka file-filenya satu per satu, realitanya beda. Dataset A labelnya destroyed, damaged, minor-damage. Dataset B pakai DS1, DS2, DS3. Dataset C pakai sistem angka yang lain lagi. Ini nggak bisa di-concat sembarangan. Kalau dipaksain digabung tanpa standarisasi, model bakal belajar hal yang salah—tiga kata berbeda untuk konsep yang identik, tiga konsep yang sama untuk kata yang berbeda. Garbage in, garbage out.
Solusinya satu: labelling ulang dari awal, semua di-remap ke standar kelas yang konsisten—DS0 sampai DS4.
Aku install Label Studio—software anotasi yang sebelumnya belum pernah aku sentuh. Beberapa hari pertama cuma buat paham workflow-nya: gimana import dataset, gimana bikin kelas baru, gimana eksport ke format YOLO. Setelah itu, mulai labelling. Satu per satu. Ribuan gambar. Gambar bounding box, assign kelas, next. Repeat.
Nggak ada yang glamor dari proses ini. Kamu duduk, kamu klik, kamu gambar, kamu next. Tapi ini adalah fondasi dari segalanya—karena model hanya sebagus data yang dia makan. Dan kalau datanya kacau dari awal, nggak ada arsitektur yang bisa menyelamatkannya.
Dataset udah siap. Sekarang saatnya beralih ke arsitektur yang lebih serius: YOLOv8. Bukan hanya soal akurasi—YOLOv8 didesain dari awal buat object detection, dia nggak cuma ngeklasifikasiin gambar tapi juga nge-localize objeknya lewat bounding box. Cocok banget sama cara kerja penilaian kerusakan bangunan yang butuh tahu di mana tepatnya kerusakannya.
Training mulai jalan. Beberapa menit pertama, semua normal. Terus konsol mulai ramai:
ignoring corrupt image/label: cannot identify image file 'train/images/sample_0847.npy'
ignoring corrupt image/label: cannot identify image file 'train/images/aug_frame_112.npy'
ignoring corrupt image/label: cannot identify image file 'train/images/img_0293.jpg'Puluhan baris. Semuanya merah.
Aku investigasi. Ternyata saat proses penggabungan tiga dataset, ada sejumlah file .npy—format biner NumPy array—yang ikut terbawa masuk ke dalam folder /images. File-file ini bukan gambar. Mereka adalah array data yang di-serialize ke format biner, tapi ekstensinya bikin mereka kelihatan seperti file biasa di antara ribuan .jpg lainnya. YOLOv8 coba buka mereka sebagai image file, dan tentu saja gagal. Selain itu, ada beberapa .jpg berukuran 0 byte—gagal ter-download di awal tanpa ketahuan.
Aku siap-siap cleanup manual, pasrah kalau training-nya harus di-restart dari nol.
Tapi training-nya nggak berhenti.
Dia terus jalan. Error-errornya dicatat di log, terus YOLOv8 mengabaikan file-file korup tersebut dan melanjutkan dengan sisa dataset yang sehat. Bukan crash. Bukan abort di tengah jalan. Sistem ini punya built-in fault tolerance yang aku sama sekali nggak tahu sebelumnya—dia cukup tangguh buat survive dari data yang nggak sempurna, dan cukup jujur buat nulis laporan lengkap di log soal apa yang dia lewati.
Hasil akhir setelah training selesai?
mAP: 0.72.
0.72 itu angka yang solid. Bukan sempurna—nggak ada model deteksi kerusakan bangunan yang sempurna—tapi cukup konsisten dan cukup dapat dipercaya untuk jadi basis sistem bantu di lapangan. Dan pelajaran dari sini lebih dari sekadar angka: sistem yang dirancang dengan baik bisa bertahan dari data yang nggak bersih. Kamu nggak perlu dataset steril 100% untuk dapat model yang bisa kerja di dunia nyata.
Model .pt di-export ke TFLite—format yang dioptimasi buat inference di perangkat mobile. Ukuran akhirnya: 42MB. Cukup ringan buat disematkan langsung ke dalam aplikasi, tanpa ketergantungan koneksi ke server eksternal tiap kali analisa—krusial di lokasi bencana di mana sinyal internet sering jadi korban pertama.
Integrasi ke React Native jadi babak terakhir. Rasanya beda banget dari semua proses sebelumnya. Kalau bagian data engineering itu kerja keras yang melelahkan penuh debugging, bagian ini masuk ke mode yang programmer mana pun pasti kenal: vibe coding. Konek MCP yang dibutuhkan, minta AI generate prompt, lalu menunngu proses sambil doomscrolling fesnuk.
UI-nya dibangun di atas Material Design 3—sistem desain yang ngasih rasa familiar dan aman kepada pengguna. Dua hal yang krusial buat aplikasi yang dipakai di situasi darurat, di bawah tekanan, oleh orang yang mungkin baru pertama kali pegang alat seperti ini. Warna, tipografi, komponen—semuanya ngikutin sistem yang udah matang dan teruji.
Workflow akhir Kizukai cukup lurus:
- Foto — Relawan ambil foto bangunan terdampak
- AI Deteksi — Model TFLite jalan langsung di device, analisa tingkat kerusakan DS0–DS4
- Form Autocomplete — Hasil deteksi otomatis ngisi field laporan
- Kirim Laporan — Data masuk ke sistem prioritisasi bantuan logistik
Kizukai jelas bukan pengganti structural engineer yang bisa ngitung beban aksial di tempat. mAP 0.72 itu angka yang jujur—ada margin kesalahan, dan di konteks bencana, kesalahan punya konsekuensi nyata. Ini adalah assist tool, bukan keputusan final.
Tapi pipeline-nya nyata. Dari foto ke laporan terstruktur, tanpa butuh koneksi internet untuk inference-nya, dengan UI yang bisa dioperasikan di kondisi penuh tekanan.
Dan di balik semua itu ada pelajaran yang lebih penting dari angka mAP-nya: data engineering yang membosankan itu bukan bagian sampingan dari proyek AI—itu adalah proyeknya itu sendiri. Berhari-hari di Label Studio nge-draw bounding box satu per satu, nge-trace kenapa ada .npy di folder gambar, ngevalidasi label yang salah kelas—semua itu yang nentuin apakah model-nya bisa kerja atau nggak.
Kepedulian dimulai dari mau repot duluan. Sampai di level data.
Dan itulah Kizukai.