Kazanimlar:
- Veri sızıntısının türlerini (hedef, zaman, ön işleme, gruplu satır) tanıyıp 'gerçek olamayacak kadar iyi' skoru alarm olarak sorgulayabilme
- Test setini erken ayırma, pipeline ve doğru bölme (kronolojik/gruplu) ile sızıntıyı önleyebilme
- Sabit seed, sürüm kontrolü ve elle adımları kaldırma ile analizi yeniden üretilebilir kılabilme
Veri biliminde en çok emeğin çöpe gittiği iki hata vardır ve ikisi de sinsidir, çünkü her şey "yolunda görünürken" felakete götürürler. Birincisi veri sızıntısı: model, test setinde muhteşem sonuç verir ama üretimde çöker. İkincisi yeniden üretilememe: bir analizi altı ay sonra çalıştırırsınız ve bambaşka bir sonuç alırsınız. Bu ünite, bu iki tuzağı derinlemesine tanımaya ve önlemeye ayrılmıştır. Yapay zeka her iki riski de artırabilir (hızlı üretir, gizli sızıntılı özellik önerir, elle adımlar atmanızı kolaylaştırır) ama doğru kullanıldığında azaltabilir de. Fark, disiplindedir.
Veri sızıntısı: geleceği görmüş model
Veri sızıntısı (İngilizcesiyle data leakage), modelin eğitim sırasında, gerçek tahmin anında elinde olmayacak bir bilgiyi görmesidir. Model bu bilgiyle "hile yapar", test setinde harika görünür, ama üretimde o bilgi olmadığı için çöker. Sızıntının belirtisi neredeyse her zaman aynıdır: gerçek olamayacak kadar iyi sonuç (İngilizcesiyle too good to be true). %99 doğruluk gördüğünüzde sevinmeden önce sızıntı aramalısınız.
Sızıntının başlıca türleri:
1. Hedef sızıntısı: Bir özellik, hedefin bir sonucudur. "İptal edildi mi" tahmininde "iptal tarihi" veya "iade tutarı" sütunları hedefin sonucudur; onlar ancak sonuç belli olunca dolar.
2. Zaman sızıntısı: Geleceğin bilgisini geçmişe taşımak. "Son 30 gün ortalaması"nı hesaplarken tahmin gününden sonraki günleri katmak, ya da zaman serisini rastgele bölmek.
3. Ön işleme sızıntısı: Ölçekleme, doldurma, kodlama gibi dönüşümleri eğitim/test bölmesinden önce, tüm veriden öğrenmek. Test verisinin ortalaması eğitime karışır.
4. Yinelenen/gruplu satır sızıntısı: Aynı kişiye ait satırların hem eğitimde hem testte olması (aynı hastanın iki ziyareti farklı setlerde). Model kişiyi ezberler.
Sızıntı türü
Nasıl doğar
Nasıl önlenir
Hedef sızıntısı
Hedefin sonucu olan sütun
"Tahmin anında elimde mi" testi
Zaman sızıntısı
Geleceği geçmişe taşıma
Kronolojik bölme, pencere kontrolü
Ön işleme sızıntısı
Bölme öncesi dönüşüm
Pipeline, sadece eğitimden fit
Gruplu satır sızıntısı
Aynı birim iki sette
Gruba göre bölme (GroupKFold)
Sızıntıyı önlemenin tek disiplini
Tüm sızıntı türlerinin ortak çözümü tek bir cümlede toplanır: Test setini, gerçek geleceği taklit edecek biçimde, mümkün olan en erken anda ayırın ve ona hiçbir şey "öğretmeyin". Uygulamada bu şu demektir: önce böl, sonra tüm dönüşümleri yalnızca eğitimden öğren ve bir pipeline (tüm adımları tek zincirde toplayan yapı) içinde uygula. Her özellik için "bu bilgi tahmin anında elimde mi" sorusunu sorun. Zaman varsa kronolojik bölün; aynı birim tekrarlıysa gruba göre bölün.
Dikkat: Sızıntının en tehlikeli yanı, kendini başarı olarak göstermesidir. Kötü bir model açıkça kötü sonuç verir ve fark edilir; sızıntılı bir model harika sonuç verir, herkesi sevindirir ve üretime alınır — çöküş orada başlar. Bu yüzden "çok iyi" sonuç bir kutlama değil, bir alarm sebebidir.
Yeniden üretilebilirlik: aynı sonucu iki kez almak
Yeniden üretilebilirlik (İngilizcesiyle reproducibility), bir analizi başka bir zamanda, başka bir makinede tekrar çalıştırdığınızda aynı sonucu almanızdır. Bu olmadan analiziniz bilimsel değil, tesadüfidir. Yeniden üretilebilirliği bozan başlıca nedenler ve çözümleri:
Elle adımlar: Excel'de elle bir hücre değiştirmek, bir grafiği elle düzenlemek. Çözüm: her adım kodda olsun.
Sabitlenmemiş rastgelelik: Model eğitimi, örnekleme, bölme rastgelelik içerir. Çözüm: random seed (rastgele üretecin başlangıç değeri) sabitle (random_state=42).
Sürüm kaymaları: Kütüphane sürümü değişince sonuç değişebilir. Çözüm: bağımlılıkları sabitle (requirements.txt, ortam dosyası).
Kayıt tutmama: Hangi veri, hangi kod, hangi parametre kullanıldı belli değil. Çözüm: sürüm kontrolü (İngilizcesiyle version control, Git — kodun her hâlini kaydeden sistem) ve veri sürümleme.
"Sadece benim makinemde çalışıyor": Çözüm: ortamı belgelemek, mümkünse konteyner (Docker) kullanmak.
Üç mini vaka
Vaka 1 — Hedef sızıntısı. Bir sağlık analizi, "hasta tekrar yatacak mı" tahmininde "taburcu sonrası ilaç" sütununu özellik yaptı. Bu sütun ancak hasta çıktıktan sonra doluyordu. Model %96 verdi, üretimde %61. 8 haftalık proje çöptü. Ders: her özelliğe "tahmin anında var mı" sorusu.
Vaka 2 — Ön işleme sızıntısı. Bir ekip, tüm veriyi ölçekleyip sonra böldü. Test verisinin ortalaması ölçeklemeye karışmıştı. CV skoru %89, gerçek üretim %76. Pipeline'a geçip dönüşümleri sadece eğitimden öğrenince sahte başarı kayboldu. Ders: önce böl, sonra dönüştür.
Vaka 3 — Yeniden üretilememe. Bir analist, yönetime sunduğu grafiği üç ay sonra güncellemek istedi ama nasıl ürettiğini hatırlamıyordu; birçok adım Excel'de elle yapılmıştı. Sonuç bir türlü tutmadı, güven sarsıldı. Ders: elle adım yok, her şey kodda ve Git'te.
Dört kopyalanabilir şablon
1) Sızıntı denetimi:
Rolün: sızıntı denetçisi. Hedef: "churn" (0/1), tahmin referans tarihi:kayit_tarihi. Şu özellik listesini vereceğim. HER özellik için: (a) buhedefin bir sonucu mu, (b) tahmin anında elimde olur mu, (c) zamanpenceresi geleceği içeriyor mu? "güvenli/şüpheli/sızıntı" olarakişaretle ve gerekçe yaz. Özellikler: [liste]
2) Sızıntısız pipeline:
sklearn Pipeline kur: önce train/test böl (stratified, seed=42), SONRAtüm ön işlemeyi (impute, scale, encode) pipeline içinde YALNIZCAeğitimden fit et. Kodun neden sızıntısız olduğunu, hangi adımın neredeöğrenildiğini açıkla.
3) Yeniden üretilebilirlik kontrol listesi kodu:
Analizimi yeniden üretilebilir yapmak istiyorum. Şunları ekleyen kod/yapı öner: (1) tüm rastgelelik için sabit seed, (2) kullanılan kütüphanesürümlerini yazdırma, (3) veri ve çıktı için tarih/sürüm etiketi.Elle adım kalmadığından emin olmam için bir kontrol listesi de ver.
4) Gruplu bölme (aynı birim sızıntısı):
Verimde aynı musteri_id birden çok satırda var. Aynı müşterinin hemeğitimde hem testte olmasını ÖNLEYEN bir bölme yap (GroupKFold veyaGroupShuffleSplit, grup = musteri_id). Bölme sonrası hiçbir müşterininiki sette birden olmadığını doğrulayan kodu da ekle.
Zayıf prompt / Güçlü prompt
Zayıf prompt:
Modelim %98 doğruluk verdi, harika değil mi? Kodu optimize et.
%98'i kutlamak sızıntıyı gizler. Optimize etmeden önce bu skorun gerçek olup olmadığı sorgulanmalı.
Güçlü prompt:
Rolün: sızıntı denetçisi. Modelim test setinde %98 doğruluk veriyor;bu bana "gerçek olamayacak kadar iyi" geliyor. Şunları kontrol et:(1) herhangi bir özellik hedefin sonucu mu, (2) dönüşümler bölmeöncesi mi yapılmış, (3) aynı birim iki sette mi, (4) zaman sızıntısıvar mı. Şüpheli her noktayı listele; skoru düzeltmeye değil, sızıntıyıbulmaya odaklan.
Burada yüksek skor kutlanacak değil, sorgulanacak bir işaret olarak ele alınır.
Sık yapılan hatalar
- "Çok iyi" sonucu kutlamak. Gerçek olamayacak kadar iyi skor, başarı değil sızıntı alarmıdır.
- Dönüşümü bölme öncesi tüm veriden öğrenmek. En sık sızıntı; pipeline ile önce bölün.
- Zaman serisini rastgele bölmek. Model geleceği görür; kronolojik bölme şart.
- Aynı birimi iki sette bırakmak. Model kişiyi ezberler; gruba göre bölün.
- Elle adım atıp koda yazmamak. Analiz yeniden üretilemez hâle gelir; her şey kodda ve Git'te olmalı.
İpucu: Projenizin başına iki cümlelik bir "namus sözü" yazın: "Test setine, üretimde göreceğim andan önce hiçbir şekilde dokunmadım. Her adım kodda ve seed sabit." Bu iki cümleyi dürüstçe imzalayamıyorsanız, sonucunuz henüz güvenilir değildir.
Özetle
Veri sızıntısı ve yeniden üretilememe, veri biliminin en pahalı iki sessiz hatasıdır. Sızıntı, modelin geleceği görmesidir ve kendini sahte başarı olarak gösterir; çözümü test setini erken ayırmak, dönüşümleri yalnızca eğitimden öğrenmek (pipeline), her özelliğe "tahmin anında elimde mi" sorusunu sormak ve doğru bölme (kronolojik/gruplu) yapmaktır. Yeniden üretilebilirlik, aynı sonucu iki kez alabilmektir; çözümü elle adımları kaldırmak, seed sabitlemek, sürümleri dondurmak ve her şeyi Git'te tutmaktır. YZ bu riskleri artırabilir de azaltabilir de; belirleyen sizin disiplininizdir.
Uygulama görevi
Kurduğunuz (veya varsayımsal) bir modelin özellik listesini alın ve her özelliğe "bu bilgi tahmin anında elimde mi" sorusunu yazılı sorun; en az bir sızıntı adayı bulun. Ardından analizinizi yeniden üretilebilir yapmak için bir kontrol listesi doldurun: seed sabit mi, elle adım var mı, sürümler kayıtlı mı, Git'te mi. Eksikleri giderin.
Kontrol listesi
- [ ] "Gerçek olamayacak kadar iyi" skoru sızıntı alarmı olarak sorguladım mı?
- [ ] Tüm dönüşümleri bölme sonrası, yalnızca eğitimden mi öğrendim?
- [ ] Zaman/grup yapısına uygun bölme (kronolojik/GroupKFold) yaptım mı?
- [ ] Tüm rastgeleliği sabit seed ile tekrarlanabilir kıldım mı?
- [ ] Elle adımları kaldırıp her şeyi kodda ve sürüm kontrolünde tuttum mu?