Data leakage bazen kolayca fark ettiğimiz, bazen ise gözden kaçırdığımız, data science alanının en sık karşılaşılan ve en dikkat edilmesi gereken hatalarından biridir. Data leakage kısaca modelin öğrenme aşamasında, gerçek hayatta ulaşamayacağı bilgiyi yanlışlıkla kullanmasıdır.
Data leakage tehlikelidir çünkü model kurma aşamasında modelimiz yanıltıcı yüksek performanslar gösterirken test verisinde ya da daha da kötüsü canlıya aldığımızda bir çöküşe sebep olabilir.
Data Leakage’ın Belirtileri
Data leakage’ın nerelerde karşımıza çıkabileceğini konuşmadan önce muhtemel belirtiler üzerine konuşalım:
Validation skorlarının anormal derecede yüksek performansta olması
Gerçek iş problemlerinde AUC’nin 1’e ya da MAE gibi regression metriklerinin 0’a yakınsaması gibi durumlar pek mümkün değildir çünkü her zaman modele ekleyemediğimiz varyasyonlar olacaktır ve modelimizdeki ufak sapmalar kabul edilebilir durumlardır. Bu yüzden model eğitimi sırasında anormal yüksek performanslı metrik skorları gördüğümüzde bunun target leakage olması muhtemeldir.
2. Train ve test performansı arasındaki olağan dışı uçurumlar
İlk aşamayı geçtik ve validasyonda bir anomali olmadığını gördük. Ancak train ve test metriklerini kıyasladığımızda, test performansının bariz şekilde daha düşük olduğunu görürsek (örn. train AUC 0.9 iken test 0.7’de kalmıştır) bunun muhtemel iki sebebi olabilir: leakage veya overfitting. Bu aşamada iki durumu da mutlaka kontrol etmek gereklidir.
3. Modelin gerçek hayatta beklenmedik şekilde başarısız olması
Bu durum fark edemediğimiz leakage durumlarında karşımıza çıkabilmektedir. Bazen train ve test arasındaki fark, verdiğim örnek kadar bariz olmayabilmektedir ya da doğru bir train/test ayrımı yapılmadıysa testte de her şey çok yolundaymış gibi görünebilmektedir.
Data Leakage Türleri
Modelleme aşamalarında oluşabilecek olası leakage’ları inceleyelim:
Feature Engineering’den Gelen Leakage
Feature engineering aşamasında hatalı oluşturulan feature’lar gerçek hayatta erişilemeyecek bilgileri taşıyabilmektedir. Bu durum modelin gerçekte olmayan bir veriyle eğitilmesine sebep olmaktadır.
İş hayatında yapılan en büyük hatalardan biri production aşaması dikkate alınmadan eğitilen modellerdir. Örneğin modelinizin gece vaktinde o gün için saatlik skorlar üretmesi lazım. Fakat siz modele real-time bir üretim yapıyormuş gibi o güne ait feature’lar da eklerseniz (son 1 gün verisini feature olarak alırken tarih olarak bir gün öncesini almak yerine son 24 saati almak) modeliniz iyi sonuçlar çıkarsa da canlıda bu feature’lara sahip olamayacaktır ve production aşamasında başarısız olacaktır.
Nasıl Önlenir?:
Projeye başlamadan önce mutlaka modelin production’da nasıl çalışacağını planlamanız ve feature’ları bu planlamaya göre yaratmanız gerekir.
Kendinize soracağınız önemli soru: Çıkardığım tüm feature’lar projeyi canlıya aldığımda hesaplayabileceğim feature’lar mı?
2. Target Leakage (Label Leakage)
Feature’ların target’tan bilgi taşıyor olması target leakage’a sebep olmaktadır. Bu durum target’ın hatalı oluşturulan feature(lar)dan öğrenmesine sebep olacak ve yanlış bir şekilde iyi bir performans görmemize sebep olacaktır. İleriki aşamada ya kullanamayacağımız bir feature eklediğimizi fark edeceğiz ya da production aşamasında istediğimiz performansı yakalayamayacağız.
Kendi deneyimlerimden küçük bir örnek vermek istiyorum. Kullanıcılara ürün önerisi yaptığımız bir model üzerinde çalışıyorduk. Feature’lardan biri, kullanıcının target olan ürün kategorisini ne sıklıkla aldığına dair bilgiydi ve modelde çok iyi çalıştı. Başta bu beni memnun etse de, diğer feature’lara göre aşırı öne çıkması bende şüphe uyandırdı. Feature’ı nasıl ürettiğimi incelediğimde, tabloları join ederken kullanıcının ileride hiç sipariş vermediği kategorilerde verinin null kaldığını fark ettim. Bu feature %100 target bilgisini taşımıyordu ancak kısmen taşıdığı için modelin performansını olduğundan yüksek gösteriyordu. Özellikle feature importance aşamasında bu durum çok net ortaya çıktı.
Nasıl Önlenir?:
Target leakage validasyon sonuçlarında beklenmedik derecede yüksek performansla kendini gösterebilmektedir. Bu durumda overfitting riskinin yanında target ile çok yüksek korelasyona sahip olduğu bir feature olup olmadığı kontrol edilebilir.
Net bir korelasyon görünmüyorsa verdiğim örnekteki gibi fazla önemli birkaç feature’ın öne çıkması durumunda bu feature’ları inceleyebilirsiniz.
3. Train-Test Leakage
Bu aşamada birkaç farklı leakage olabilmektedir:
Train/test ayrımlarının yanlış yapılması: En net örneklerinden biri zaman etkili modellerde verinin zamana uygun bölmek yerine random bölünmesidir. Böyle bir durumda train gelecekten bilgi taşıdığı için test verisini de öğrenmiş oluyor ve testteki performans olması gerekenden yüksek çıkıyor.
Train/test preprocessing adımlarının yanlış uygulanması: Veriye yapılan proseslerin önce train’de fit edilmesi daha sonra teste uygulanması gerekmektedir çünkü train verisi modelin öğreneceği veridir ve scaling gibi aşamalar train üzerinden öğrenilmelidir. Aksi takdirde train’e test verisinden de bilgi taşınmış olur.
Cross-validation leakage: Cross-validation sırasında da dikkat edilmezse leakage oluşabilir. En yaygın hata, fold’ları ayırmadan önce tüm veri üzerinde preprocessing yapmak (örneğin scaling, feature selection, oversampling). Bu durumda test fold’larından bilgi train fold’una sızar.
Bir başka hata ise hyperparameter tuning aşamasında oluyor: Eğer fold’ların sonuçlarını doğrudan parametre seçiminde kullanırsak, aslında ‘test’ gibi davranması gereken veriden öğrenmiş oluruz. Örneğin early stopping için ayrı bir validation seti ayırmadan fold’lardaki performansı kullanırsak, model test verisinin ipuçlarıyla erken durmayı öğrenmiş olur. Bu, train ve test arasındaki sınırın bulanıklaşmasına yol açar.
Nasıl Önlenir?:
Split aşamasında verimizin doğasını doğru anlamamız gerekiyor. Eğer verimiz zamana bağlı değişkenler içeriyorsa mutlaka zaman bazlı bölmemiz gerekir. Aynı user’ın veride birkaç defa yer aldığı user bazlı verilerde her user’ın datası tek bir split’e gelecek şekilde gruplayarak da bölebiliriz.
Preprocessing aşamalarında evaluation yaptığımız set üzerinde fit etmemeliyiz. Train verisinde fit ettikten sonra test (ya da validation) verisine uygulamalıyız.
Cross-validation yapısını kurarken dikkatli olmalı ve parametre seçiminde değerlendirme setinden bilgi sızmasına izin vermemeliyiz.
Sonuç olarak data leakage, doğru bir modelleme sürecinin en büyük tehditlerinden biridir. İlk bakışta fark edilmeyebilir ama sonuçta canlıda başarısızlığa yol açabilir. Modelinizin güvenilir ve sürdürülebilir sonuçlar üretebilmesi için leakage risklerini her adımda kontrol etmek gerekir. Bu yüzden her aşamada ‘Gerçek hayatta bu bilgiyi bilebilir miyim?’ sorusunu sormak kritik.
Peki siz hiç data leakage ile karşılaştınız mı? Deneyimlerinizi yorumlarda paylaşabilirsiniz.