Ana görev · rötar tahmin modeli · Ağustos 2026
Bir uçuşun geç kalkacağını, kalkışa saatler kala bilmek.
ABD havalimanlarının aksine İstanbul Havalimanı geçmiş rötar verisini yayımlamıyor. Bu yüzden veri setini kendim topladım: Mayıs 2026'dan beri her gün, uçuş tarifesi + ADS-B hareketleri + METAR. Bu sayfa o veri üzerine kurulan modeli anlatıyor — nasıl kurulduğunu, neden bu şekilde kurulduğunu ve nerede durduğunu.
Neden
Model, yenilmesi gereken bir rakiple başlar.
"Makine öğrenmesi kullandım" bir sonuç değildir. Bir uçuşun geçmişte ne sıklıkla geciktiğine bakan basit bir tablo zaten şaşırtıcı derecede iyidir — ve çoğu proje modelini hiçbir zaman ona karşı ölçmez. Bu yüzden önce o tabloyu kurdum, sonra modelin onu geçmesini istedim. Geçmeseydi, yayımlanacak bulgu bu olurdu.
Adım 1 · ReferansKademeli arama tablosu
Havalimanı ortalamasından başlayıp varış noktası → havayolu+varış → +saat → uçuş numarası şeklinde daralan bir merdiven. Her kademe kendi üstüne doğru büzülüyor, böylece üç kez uçulmuş bir rota %0 ya da %100 demek yerine makul bir sayı veriyor. Yenilecek çıta bu: 0,711 AUC.
Adım 2 · HibritTablonun cevabı bir öznitelik
Gradyan artırmalı ağaç (HistGradientBoosting), tablonun tahminini tek bir öznitelik olarak alıyor ve ne zaman ona katılmayacağını öğreniyor. Kritik tuzak: tablo eğitim satırlarının cevabını zaten görmüştür. Bu yüzden eğitim satırları kat-dışı puanlanıyor — günlere göre beş gruba bölünüp her grup diğer dördüyle kurulan bir tabloyla ölçülüyor.
Adım 3 · Uçağın önceki bacağıAsıl fark burada
Her uçağı gövde numarasıyla (icao24) izleyip iki şey hesaplıyorum: uçağın yerde ne kadar kaldığı (aktarma süresi) ve geldiği uçuşun ne kadar geciktiği. Avrupa'daki rötar dakikalarının %46'sı bu zincirden geliyor. Sadece tarifeye bakan bir model bunu yapısal olarak göremez.
Dürüst ölçüm
Mayıs–Haziran'da eğit, Temmuz'da körlemesine test et.
Bölme rastgele değil, tarihe göre. Rastgele bölme aynı günün iki uçuşunu eğitim ve teste dağıtır; o günün havası ve tıkanıklığı birinden diğerine sızar ve sonuç olduğundan iyi görünür. Aşağıdaki sayıların hepsi, modelin hiç görmediği 22.675 uçuşluk Temmuz'dan.
Her öznitelik neyi ekledi
| Model | AUC | Brier | Kat |
|---|---|---|---|
| Arama tablosu (çıta) | 0,711 | 0,1060 | 2,98 |
| Hibrit ağaç | 0,716 | 0,1054 | 3,03 |
| + aktarma süresi | 0,739 | 0,1003 | 3,44 |
| + gelen uçuşun rötarı | 0,742 | 0,0996 | 3,43 |
Ağacın tek başına kazancı küçük: 0,711 → 0,716. Asıl sıçrama uçağın önceki bacağını eklediğinde geliyor. Yani kazanç "makine öğrenmesi"nden değil, doğru mekanizmayı ölçmekten çıkıyor.
Modelin gerçekten ne gördüğü
| Aktarma süresi | Uçuş | Gerçek rötar | Tablo diyor | Model diyor |
|---|---|---|---|---|
| 60 dk'dan kısa | 579 | %56,6 | %20,7 | %48,8 |
| 60–90 dk | 1.557 | %14,5 | %12,3 | %11,9 |
| 90 dk ve üzeri | 6.841 | %9,7 | %8,3 | %6,9 |
Tek tablo bütün hikâyeyi anlatıyor. Uçağın yerde 60 dakikadan az kaldığı uçuşların %56,6'sı gerçekten geç kalkıyor — arama tablosu ise %20,7 diyor, çünkü o uçuşun geçmişine bakıyor, o günkü uçağına değil. Model %48,8'e çıkıyor. Hâlâ eksik tahmin ediyor, ama doğru yöne bakıyor.
İki gerçek uçuş
TK1045 → Bükreş · 25 Temmuz, 18:00
Arama tablosu bu uçuşu güvenli buldu: %5,3. Bu uçuş numarası geçmişte neredeyse hiç gecikmemişti. Ama o gün uçağı Bükreş'e götürecek gövde, İstanbul'a 57 dakika geç inmişti ve tarifede yerde sadece 24 dakikası vardı.
Model %84,6 dedi. Uçuş 56 dakika rötarla kalktı.
A46070 → Mineralnye Vody · 19 Temmuz, 21:00
Ters yön. Bu rotanın geçmişi kötü olduğu için arama tablosu %43,8 ile alarm verdi. Oysa o akşamki uçak zamanında inmişti ve yerde 92 dakikası vardı.
Model %9,6 dedi. Uçuş zamanında kalktı.
İkisi de aynı şeyi gösteriyor: arama tablosu bir uçuşun itibarını bilir, modelse o günkü uçağını. Rötarın büyük kısmı itibardan değil, o sabah bozulan zincirden geliyor.
Dürüst sınırlar
Modelin nerede işe yaramadığı.
- Bir gün önceden bu model işe yaramaz. Ölçtüm: aktarma süresi, kalkıştan ortalama 2,3 saat önce belli oluyor ve 24 saat önceden %0'ı bilinebiliyor. Modelin bütün üstünlüğü bu iki öznitelikten geldiği için, yarının panosunu puanlarken elde 0,716 kalıyor — çıtanın 0,711'inin hemen üstü. Bu yüzden canlı pano hâlâ arama tablosunu kullanıyor. Doğru çözüm modeli panoya koymak değil, panoyu gün içinde yeniden puanlamak.
- Gelen uçuşun rötarı gürültü sınırında. Tek çalıştırmada +0,003 görünüyor; dört farklı rastgele tohumla ölçtüğümde ortalama +0,002 ve dördün birinde negatif. Referansın kendi tohum sapması (0,0027) etkiden büyük. Özniteliği tuttum çünkü doğru mekanizma o — ama kazanç olarak sunulamaz.
- Uçakların sadece %34'ünü tanıyabiliyorum. Aktarma süresi ancak ADS-B'de gövde numarasını yakalayabildiğim uçuşlarda hesaplanıyor. OpenSky günde ~554 kalkış hareketi görüyor ama tarifede ~877 kalkış var; mükemmel bir eşleştirme bile %63'te duruyor.
- Hava durumu henüz öğrenilebilir değil. Eğitim aylarında toplam beş saatlik gök gürültülü fırtına var ve o saatlerde rötar oranı normal seyretmiş. Model, örneğinde bulunmayan bir etkiyi öğrenemez. IST'de kışın sis 10 kat, görüş 3 km altı 10 kat artıyor — en kötü ay Şubat, Aralık değil. Bu yüzden hava durumu terimleri kışa kadar beklemede.
- Kaç dakika gecikeceğini değil, gecikip gecikmeyeceğini söylüyor. Rötar süresi satırların yalnızca %28'inde var. Geç/zamanında etiketi tam, ama "45 dakika mı 3 saat mi" sorusunun cevabı çoğu satırda yok.
Bunların hepsi ölçülmüş sınırlar, tahmin değil. Bir modelin nerede çalışmadığını bilmek, çalıştığı yeri bilmek kadar sonuçtur.
Çalışan yarısı
Kalkış rötar panosu.
Modelin bugün canlı çalışan hâli: yarın planlanan her kalkış, kendi geçmişine göre puanlanıyor ve gün sonunda gerçekte ne olduğuyla karşılaştırılıyor. Yukarıdaki sınır gereği pano şimdilik arama tablosunu kullanıyor — kendi skor tablosunu da açıkça gösteriyor.