Di feed developer belakangan ini, AI sering tampil seperti tombol “instan jadi pintar”. Padahal di operasional pengiriman, yang bikin keputusan bagus itu bukan model yang “canggih”, melainkan model yang bisa dipertanggungjawabkan: jelas inputnya, jelas cara ukur kinerjanya, dan jelas kapan ia tidak boleh dipercaya. Tren AI yang makin pragmatis di komunitas dev (termasuk pembahasan soal apa yang real vs sekadar demo) juga terasa di DEV—misalnya dari artikel tentang arah AI yang semakin “applied” dan dekat ke problem nyata. Kamu bisa lihat konteksnya di tulisan tentang AI trends ini: AI revolution & tren developer. Dan pada akhirnya, yang kita kejar bukan hype, tapi prediksi eta pengiriman multimoda.
Di sisi ilmiah, logistik itu penuh variabel stokastik: cuaca, kepadatan pelabuhan, antrean dokumen, handover antarmoda, dan ketidakpastian lead time. Literatur transportation & logistics analytics menunjukkan bahwa pendekatan berbasis data memang punya ruang besar—terutama saat kita merancang fitur dan evaluasi yang tepat. Untuk landasan akademiknya, aku merujuk ke studi ilmiah di MDPI tentang transportasi/logistik berbasis data. Tema ini layak diangkat karena banyak tim (engineering maupun operasional) ingin memanfaatkan AI, tapi sering tersandung di hal paling mendasar: data yang tidak rapi, evaluasi yang keliru, dan bias yang tidak ketahuan—padahal dampaknya langsung ke SLA, biaya, dan kepuasan pelanggan.
Kesimpulan cepat (sebelum kita mulai):
ETA yang bagus itu bukan yang “paling pintar”, tapi yang paling *reliable—punya fitur yang masuk akal, evaluasi yang jujur, dan *guardrail untuk menghindari bias saat rute berubah.
1. Kenapa ETA di Multimoda Selalu “Lebih Susah” dari yang Kedengaran
Kalau kamu pernah membangun produk yang bergantung pada estimasi waktu, kamu tahu satu hal: edge case bukan pengecualian—dia adalah menu utama. Di pengiriman multimoda, tantangannya berlipat karena ETA bukan sekadar fungsi jarak dan kecepatan; ia adalah rangkaian peristiwa: pickup → line haul → port/terminal → vessel/rail/truck → clearance → last mile.
Apa yang membuatnya kompleks?
- Pergantian moda = pergantian distribusi risiko. Keterlambatan di satu titik menggeser seluruh jadwal.
- Data event tidak selalu synchronized. Scan barcode bisa telat, EDI bisa batching.
- Sinyal eksternal lebih dominan daripada sinyal internal (cuaca, kemacetan, port congestion, jadwal kapal).
Definisikan “ETA” dulu (biar tidak debat di akhir)
Sebelum model, sepakati definisi target:
- ETA milestone (mis. “ETA tiba pelabuhan tujuan”) vs ETA end-to-end (door-to-door).
- Point estimate (satu angka) vs prediction interval (rentang: P50/P90).
Kalau tim kamu ingin mengurangi drama “kok meleset jauh?”, pertimbangkan interval ETA sejak awal.
2. Fitur Data yang Masuk Akal
Model boleh apa saja—regression, gradient boosting, bahkan deep sequence model—tapi kualitas keputusan sering ditentukan oleh feature engineering. Kalau ingin versi DEV-to-style yang ringkas dan praktis, ini referensi internal yang nyambung: Feature Engineering: A Practical Guide.
Prinsip fitur untuk ETA
- Causality-ish: fitur punya “cerita” yang masuk akal (bukan sekadar korelasi kebetulan).
- Available on time: fitur tersedia sebelum prediksi dibuat (hindari data leakage).
- Stable-ish: tidak berubah drastis karena perubahan sistem pencatatan.
Tabel: ide fitur ETA + sinyal + risiko umum
| Kelompok fitur | Contoh | Kenapa berguna | Risiko yang sering kejadian |
|---|---|---|---|
| Rute & jarak | lane (origin-destination), jarak, stop count | menangkap baseline durasi | definisi lane berubah, rute alternatif |
| Waktu & musim | hari, jam pickup, musim puncak | memodelkan pola periodik | holiday effect, event lokal |
| Moda & transshipment | urutan moda, jumlah transfer, dwell time historis | multimoda = handover cost | missing event di titik transfer |
| Kinerja carrier/vendor | on-time rate, variance lead time | sinyal reliabilitas | bias ke vendor yang data-nya lengkap |
| Operasional & dokumen | status clearance, tipe komoditas, incoterms | bottleneck sering di dokumen | leakage jika status muncul setelah kejadian |
| Eksternal | cuaca, port congestion index, traffic | faktor dominan | kualitas API, latensi update |
Praktik ringan tapi berdampak (yang sering dilupakan)
- Encode “ketidakpastian” sebagai fitur, mis. rolling std lead time 14 hari per lane.
- Simpan versi definisi fitur (feature contract). Kalau definisi berubah, model terlihat “mendadak bodoh”.
Di bagian ini, sisipkan keyword secara natural: kalau fitur “ceritanya” jelas, prediksi eta pengiriman multimoda jauh lebih mudah diterima oleh tim ops (dan customer success).
3. Evaluasi Model: Jangan Cuma MAE, Apalagi Cuma “Rasa-rasaan”
Kalau kamu mengukur ETA seperti mengukur checkout latency, kamu akan ketemu konflik: ada case di mana “terlambat 2 jam” itu meh, tapi ada juga yang “terlambat 30 menit” itu membuat missed cut-off dan biaya membengkak.
Untuk pengantar metrik regresi yang gampang dicerna (dan banyak dipakai di DEV), kamu bisa lihat: Understanding MAE, MSE, and RMSE.
Checklist evaluasi yang lebih jujur
- MAE untuk “rata-rata meleset berapa jam”.
- P90 absolute error untuk melihat worst-case yang nyata.
- MAPE (hati-hati) untuk rute pendek vs panjang—bisa menipu.
- Pinball loss kalau kamu pakai quantile (P50/P90) agar interval ETA punya arti.
Split data yang benar (ini sering bikin model terlihat “hebat” padahal bohong)
- Time-based split (train: bulan 1–9, test: bulan 10–12) untuk meniru dunia nyata.
- Jangan acak total (random split) kalau ada seasonality atau trend.
- Validasi per lane (origin-destination) agar tidak terlalu optimis di rute “favorit”.
Tip: tulis evaluasi per segmen: lane, moda, carrier, dan kategori komoditas. Di sinilah biasanya terlihat bahwa prediksi eta pengiriman multimoda “bagus” hanya untuk sebagian rute saja.
4. Menghindari Bias di Rute Multimoda (Tanpa Jadi Polisi AI)
Bias di ETA jarang muncul sebagai isu “etika abstrak”. Ia muncul sebagai: rute tertentu selalu diprediksi terlalu optimis, vendor tertentu selalu “diuntungkan” karena data-nya lengkap, atau area tertentu selalu dianggap lambat karena historinya buruk padahal infrastrukturnya sudah membaik.
Tiga sumber bias yang paling sering terjadi
- Data coverage bias: event tracking lengkap hanya untuk rute/cabang tertentu.
- Survivorship bias: shipment yang “bermasalah” tidak tercatat rapi, akhirnya hilang dari dataset.
- Feedback loop: karena ETA dipakai untuk keputusan, keputusan itu mengubah data masa depan (mis. selalu memilih carrier tertentu).
Cara mitigasi yang realistis untuk tim engineering
- Stratified evaluation: selalu tampilkan metrik per segmen (lane/mode).
- Reweighting: beri bobot lebih untuk segmen yang under-represented.
- Model monitoring: drift dan performance decay itu default—bukan kejutan. (Kalau kamu suka sudut pandang “applied AI”, bacaan ini menarik: The Future of Applied AI Engineers.)
- Human-in-the-loop guardrail: jika confidence rendah atau di luar domain, eskalasi ke rules/manual review.
Di mana perusahaan logistik sering “nyangkut”
Bukan di modelnya, tapi di integrasi: event dari WMS/TMS, EDI carrier, telematics, dan input manual. Di titik ini, praktik data contract dan observability lebih penting daripada mengganti algoritma.
Konteksnya: di operasional forwarding dan logistik terintegrasi, prediksi ETA bukan fitur “nice to have”. Ia menjadi alat koordinasi. Kalau kamu ingin melihat gambaran layanan end-to-end yang biasa memerlukan orkestrasi data seperti ini (multimoda, ekspedisi muatan kapal, hingga distribusi lintas wilayah/negara), referensinya ada di Segoro Lintas Benua.
Dan ya—ketika bias dipantau dan ditangani, prediksi eta pengiriman multimoda berubah dari sekadar angka menjadi decision support yang bisa diandalkan.
5. How-To: Membangun Baseline ETA yang “Beneran Kepakai” dalam 7 Langkah
Bagian ini sengaja dibuat praktis—baseline yang bagus sering lebih bernilai daripada PoC model yang spektakuler tapi tidak bisa diproduksikan.
Langkah 1 — Tentukan target dan horizon
- Target: ETA end-to-end atau milestone tertentu.
- Horizon: prediksi dibuat saat pickup? setelah masuk port? setelah departed?
Langkah 2 — Normalisasi event timeline
- Buat skema event standar:
picked_up,gate_in,loaded,departed,arrived,cleared,delivered. - Simpan
event_timedanrecorded_time(latensi input penting!).
Langkah 3 — Bangun fitur baseline
- Lane, jarak, mode sequence, day-of-week.
- Rolling mean/median lead time per lane-mode.
Langkah 4 — Pilih model baseline yang tahan banting
- Mulai dari: linear regression / gradient boosting.
- Fokus pada interpretabilitas dulu.
Langkah 5 — Evaluasi dengan split berbasis waktu
- Test set harus “masa depan” dari train.
- Laporkan MAE + P90 error per segmen.
Langkah 6 — Tambahkan interval ETA (P50/P90)
- Gunakan quantile regression / pinball loss.
- Publikasikan interval, bukan angka tunggal.
Langkah 7 — Pasang monitoring & fallback
- Monitor drift fitur (distribusi lane/mode berubah?).
- Jika out-of-domain: fallback ke rules (mis. median lane).
Output yang ideal: dashboard sederhana yang menjawab 3 pertanyaan ops: (1) seberapa yakin ETA ini? (2) segmen mana yang meleset? (3) apa penyebabnya?
Di akhir pipeline, jangan lupa: prediksi eta pengiriman multimoda harus punya owner (siapa yang merawatnya) dan playbook (apa yang dilakukan kalau meleset).
6. FAQ yang Sering Muncul
Aku kumpulkan FAQ ini dari pola diskusi tim product/ops/engineering—biasanya pertanyaannya sama, tapi konsekuensinya besar.
Apakah harus pakai deep learning?
Tidak harus. Untuk banyak kasus ETA, gradient boosting + fitur yang benar sudah sangat kompetitif. Deep model masuk akal jika kamu punya sequence event yang rapat, coverage tinggi, dan monitoring matang.
Kenapa model saya bagus di offline tapi jelek di produksi?
Biasanya kombinasi: data leakage, split yang salah (random), dan perubahan distribusi (lane baru, vendor baru, musim puncak). Pasang monitoring drift dan evaluasi time-based.
Bagaimana cara mengatasi data event yang banyak kosong?
Mulai dari fitur yang “selalu ada” (lane, mode, waktu), lalu gunakan pendekatan missingness-aware (flag missing sebagai fitur), dan perbaiki pipeline event secara bertahap.
Apakah interval ETA bikin user bingung?
Kalau disajikan dengan benar, justru mengurangi komplain. Contoh: tampilkan P50 (estimasi) dan P90 (konservatif) dengan copy yang jelas.
Apa KPI yang paling masuk akal untuk bisnis?
Biasanya kombinasi: MAE (jam), percent shipments within tolerance (mis. ±6 jam), dan biaya akibat missed cut-off. Sesuaikan segmen—multimoda berbeda dengan direct trucking.
7. Dari “Model” ke “Produk”: Biar ETA Tidak Jadi Sekadar Grafik
Sebagai penutup, ETA yang berguna itu yang dipakai: muncul di workflow, memicu notifikasi, dan membuat keputusan lebih cepat. Itu berarti kita harus memikirkan bukan hanya training, tapi juga serving, observability, dan iterasi.
Di titik ini, aku suka mengingat kutipan Andrew Ng: “AI is the new electricity.” (artinya: “AI adalah listrik baru.”). Andrew Ng adalah peneliti AI dan pendidik yang dikenal luas lewat kontribusinya di Google Brain, Stanford, dan ekosistem edukasi AI; profilnya bisa kamu baca di Wikipedia Andrew Ng. Kutipan itu relevan karena “listrik” tidak menggantikan semua hal secara ajaib—ia menjadi infrastruktur yang membuat proses lama jadi lebih efisien. Sama seperti itu, prediksi eta pengiriman multimoda tidak perlu terdengar futuristik; ia perlu menjadi komponen yang stabil, terukur, dan bisa diaudit di rantai pasok.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://segorolintasbenua.id/#organization",
"name": "PT. Segoro Lintas Benua",
"url": "https://segorolintasbenua.id/",
"description": "Perusahaan forwarding & logistik terintegrasi: jasa pengurusan transportasi, angkutan multimoda, ekspedisi muatan kapal, serta solusi rantai pasok domestik–internasional."
},
{
"@type": "Article",
"@id": "https://segorolintasbenua.id/#devto-eta-multimoda",
"headline": "Prediksi ETA Pengiriman Tanpa \"AI Hype\": Fitur yang Masuk Akal, Evaluasi Model, dan Cara Menghindari Bias",
"inLanguage": "id-ID",
"author": {"@id": "https://segorolintasbenua.id/#organization"},
"publisher": {"@id": "https://segorolintasbenua.id/#organization"},
"mainEntityOfPage": "https://dev.to/",
"keywords": [
"prediksi eta pengiriman multimoda",
"eta pengiriman",
"machine learning logistik",
"feature engineering",
"model monitoring"
],
"about": [
"Logistics",
"Supply Chain",
"Machine Learning",
"MLOps"
]
},
{
"@type": "HowTo",
"name": "How-To: Membangun Baseline ETA yang Beneran Kepakai dalam 7 Langkah",
"inLanguage": "id-ID",
"step": [
{"@type": "HowToStep", "name": "Tentukan target dan horizon", "text": "Sepakati definisi ETA (milestone atau end-to-end) dan kapan prediksi dibuat."},
{"@type": "HowToStep", "name": "Normalisasi event timeline", "text": "Standarkan event (picked_up, gate_in, loaded, departed, arrived, cleared, delivered) dan simpan event_time serta recorded_time."},
{"@type": "HowToStep", "name": "Bangun fitur baseline", "text": "Gunakan lane, jarak, mode sequence, pola waktu, dan rolling lead time per segmen."},
{"@type": "HowToStep", "name": "Pilih model baseline", "text": "Mulai dari model yang interpretabel (linear/gradient boosting) sebelum model kompleks."},
{"@type": "HowToStep", "name": "Evaluasi time-based", "text": "Gunakan split berbasis waktu dan laporkan MAE + P90 error per segmen."},
{"@type": "HowToStep", "name": "Tambahkan interval ETA", "text": "Gunakan quantile (P50/P90) agar ketidakpastian terlihat dan bisa dioperasionalkan."},
{"@type": "HowToStep", "name": "Monitoring & fallback", "text": "Pantau drift dan siapkan fallback rules untuk out-of-domain."}
]
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Apakah harus pakai deep learning?",
"acceptedAnswer": {"@type": "Answer", "text": "Tidak harus. Banyak kasus ETA cukup dengan model interpretable + feature engineering yang tepat. Deep learning relevan jika sequence event rapat, data lengkap, dan monitoring matang."}
},
{
"@type": "Question",
"name": "Kenapa model bagus di offline tapi jelek di produksi?",
"acceptedAnswer": {"@type": "Answer", "text": "Penyebab umum: data leakage, split yang salah (random), serta perubahan distribusi data. Gunakan time-based split dan monitoring drift."}
},
{
"@type": "Question",
"name": "Bagaimana mengatasi data event yang banyak kosong?",
"acceptedAnswer": {"@type": "Answer", "text": "Mulai dari fitur yang selalu tersedia, gunakan flag missing sebagai fitur, dan perbaiki pipeline event bertahap sambil menjaga definisi event konsisten."}
},
{
"@type": "Question",
"name": "Apakah interval ETA bikin user bingung?",
"acceptedAnswer": {"@type": "Answer", "text": "Jika dikomunikasikan dengan baik, interval ETA justru mengurangi komplain. Tampilkan P50 sebagai estimasi dan P90 sebagai konservatif dengan penjelasan yang jelas."}
}
]
}
]
}
Top comments (0)