Eğitim başarısı ile yeni gözlemler üzerindeki başarı ayrılır. Veri sızıntısı, temsil sorunu ve hedef değişkenin yanlış tanımı iyi görünen bir metriğin anlamını değiştirebilir.
Görsellerdeki sayılar, dağılımlar ve senaryolar kavramları açıklamak için oluşturulmuştur. Gerçek bir ürünün performans ölçümü veya bir kurumun test sonucu değildir.
aynı modele bakan iki farklı göz
Developer bir modele "nasıl daha iyi performans alırım?" diye bakar. Validator ise "bu performans gerçek mi ve üretimde de sürer mi?" diye. Aynı nesne, iki farklı soru. Bu modülün amacı sana ML öğretmek değil — DS serisinde o temel zaten var — ML'e ikinci gözle bakmayı sistematikleştirmek.
Validator gözünün üç refleksi vardır. Birincisi, şüphe varsayılanıdır: raporlanan her metrik, aksi kanıtlanana kadar "iyimser" kabul edilir — çünkü geliştirme süreci, doğası gereği, test setinde iyi görünen konfigürasyonları seçerek ilerler (selection bias geliştiricinin kendisindedir). İkincisi, basit kıyas ister: karmaşık modelin katma değeri, ancak basit ve savunulabilir bir benchmark'a (lojistik regresyon, mevcut skorkart) karşı ölçülürse anlamlıdır. Üçüncüsü, seçimlerin gerekçesini arar: algoritma, hiperparametre, değişken seti, örneklem penceresi — her biri bir karardır ve her kararın alternatifi vardı. Gerekçesi yazılmamış karar, challenge edilmemiş karar demektir.
Bu modül bilinçli olarak "klasik ML" düzeyinde kalıyor: kredi skorundan fraud'a, bankadaki AI sistemlerinin büyük çoğunluğu hâlâ bu ailelerden. LLM'e özgü değerlendirme Faz 4'te. Ama şunu şimdiden not et: buradaki her kavramın (overfitting, leakage, benchmark) LLM dünyasında bir karşılığı var — ve orada tespit etmesi çok daha zor.
model ailesi haritası: neden bu model seçilmiş?
Validasyonun klasik sorusu: "neden XGBoost?" Bu soruya cevap verebilmek için model ailelerinin nerede durduğunu bilmen gerekir. Aşağıdaki haritada her aileye tıkla: yatay eksen tipik tahmin performansı (tabular veri için), dikey eksen yorumlanabilirlik.
yorumlanabilirlik × performans haritası
yorumlanabilirlik →
tipik performans (tabular) →
Lojistik / Skorkart
Karar Ağacı
Random Forest
Gradient Boosting
Sinir Ağı
LLM
Haritanın validasyon mesajı: sağa gittikçe kazanılan performansın bedeli, soldan kaybedilen açıklanabilirlik ve artan operasyonel yüktür. "Neden bu model?" sorusunun kabul edilebilir cevabı bir trade-off analizidir — "en yüksek AUC'yi verdi" değil. AUC farkı 0.5 puansa ve karşılığında SHAP altyapısı, monitoring yükü ve regülasyon riski geliyorsa, basit model pekâlâ daha "fit for purpose" olabilir.
Validasyon lensi: Geliştiriciden her zaman challenger karşılaştırma tablosu iste: en az bir basit benchmark (lojistik/mevcut model) ve bir-iki alternatif, aynı veri ve aynı metriklerle. Tablo yoksa "model seçimi" yapılmamış, "model varsayılmış" demektir — bu başlı başına bulgudur.
overfitting: ezber ile öğrenme arasındaki çizgi
Overfitting, modelin veriyi öğrenmek yerine ezberlemesidir: eğitim verisindeki gürültüyü desen sanır, yeni veride başarısız olabilir. Teşhis aracı basit ve evrenseldir: eğitim hatası ile test hatasını, model karmaşıklığına karşı birlikte çiz. Kaydırıcıyla karmaşıklığı artır ve iki eğrinin ayrışmasını izle.
karmaşıklık – hata simülasyonu
Model karmaşıklığı
3.0
Eğitim hatasıTest hatası (görülmemiş veri)Seçilen karmaşıklık
—
eğitim hatası
—
test hatası
—
fark (gap)
Üç bölge vardır. Sol (underfitting): model çok basit, iki hata da yüksek — deseni yakalayamıyor. Orta (sweet spot): test hatası minimumda; hedef burasıdır. Sağ (overfitting): eğitim hatası düşmeye devam eder ama test hatası geri döner; aradaki makas, ezberin ölçüsüdür. Validator'ın baktığı sayı tek başına test performansı değil, train–test makasıdır — makas büyükse rapor edilen performans kırılgandır.
İnce nokta: test seti de "kirlenebilir". Geliştirici yüzlerce konfigürasyonu aynı test setiyle deneyip en iyisini seçtiyse, test seti fiilen ikinci bir eğitim seti olmuştur (bu yüzden ciddi süreçlerde ayrı bir holdout — hiç dokunulmamış final seti — tutulur). Sorulacak soru: "Bu test setine geliştirme boyunca kaç kez bakıldı?"
leakage dedektifi: sızıntıyı bul
Data leakage, modelin eğitim sırasında gerçekte sahip olamayacağı bilgiye erişmesidir. Sonuç: geliştirmede parlak, üretimde çökük performans. Overfitting'den farkı: leakage bir süreç hatasıdır ve metriklerde görünmez — ancak veri akışını sorgulayarak yakalanır. Aşağıdaki beş gerçekçi senaryoda kararını ver.
Leakage'ın en tehlikeli özelliği: her metriği iyileştirir. AUC yükselir, KS yükselir, herkes mutludur — üretime çıkana kadar. Bu yüzden "sonuçlar çok iyi" başlı başına bir şüphe nedenidir: beklenenden iyi sonuç, hatalı kurulumun en yaygın belirtisidir.
challenge noktaları: dört katman, tek disiplin
Buraya kadarki her şeyi tek bir çerçeveye toplayalım. Bir ML modelini challenge ederken sorular dört katmana ayrılır — bu yapı, Faz 3'te (Modül 12) tam bir soru bankasına dönüşecek:
1 · Veri
Örneklem penceresi neden bu dönem? Kriz/istisna dönemleri dahil mi, dışlandıysa gerekçesi ne?
Her değişken karar anında gerçekten mevcut mu? (leakage sorusu)
Dışlanan gözlemler (eksik veri, outlier) sonucu sistematik biçimde değiştiriyor mu?
2 · Tasarım
Neden bu algoritma? Basit benchmark'a karşı katma değeri kaç puan ve neye mal oluyor?
Hiperparametreler nasıl seçildi — sistematik arama mı, "alışkanlık" mı?
Hedef değişken tanımı (ör. temerrüt = kurulum aşamaları gecikme) iş amacıyla örtüşüyor mu?
3 · Değerlendirme
Train–test makası ne kadar? Test setine geliştirme boyunca kaç kez bakıldı?
Zaman bazlı ayrım yapıldı mı (out-of-time test)? Segment bazında performans tutarlı mı?
Metrik seçimi iş maliyetini yansıtıyor mu (dengesiz sınıflarda accuracy tuzağı)?
4 · Kullanım
Model çıktısı kararı nasıl etkiliyor — otomatik mi, insan destekli mi? Override süreci var mı?
Üretim verisi eğitim verisine benziyor mu, drift nasıl izlenecek?
Modelin bilinen zayıflıkları kullanıcıya bildirildi mi (limitations dokümanı)?
Performansın sınırları
Eğitim başarısı ile yeni gözlemler üzerindeki başarı ayrılır. Veri sızıntısı, temsil sorunu ve hedef değişkenin yanlış tanımı iyi görünen bir metriğin anlamını değiştirebilir.
Validasyon, metriği yeniden hesaplamanın yanında örneklemin oluşumunu ve gerçek kullanım koşullarını da inceler. Ayrım gücü, kalibrasyon ve karar eşiği farklı sorulara cevap verir.
anahtar çıkarımlar
raporlanan performans, aksi kanıtlanana kadar iyimserdir
Geliştirme süreci test setinde iyi görüneni seçerek ilerler. Validator'ın işi kötü niyet aramak değil; sürecin yapısal iyimserliğini bağımsız kanıtla dengelemektir.
model seçimi bir trade-off analizidir
"En yüksek AUC" bir gerekçe değildir. Karmaşıklığın katma değeri, basit benchmark'a karşı, açıklanabilirlik ve operasyonel maliyet hesaba katılarak savunulmalıdır.
makasa bak, tek sayıya değil
Train–test farkı ezberin ölçüsüdür; out-of-time test geleceğe dayanıklılığın ilk sinyalidir. Test setine kaç kez bakıldığı sorusu, çoğu parlak raporu terletir.
beklenenden iyi sonuç, şüphe nedenidir
Leakage tüm metrikleri iyileştirir ve metriklerde görünmez. Yakalama yöntemi veri akışı sorgusudur: "bu değişken, karar anında gerçekten biliniyor muydu?"
Uygulama örneği · kurgusal vaka
karar masası: Şüpheli performans sıçraması
Senaryo: Yeni kredi modeli AUC’yi 0,74’ten 0,91’e çıkardığını söylüyor. Ekip rastgele train/test ayırmış; bazı özelliklerin karar anında mevcut olup olmadığı belirsiz, kalibrasyon yalnız tüm portföyde raporlanmış.
Örnek değerlendirmeyi aç
DeğerlendirmeGörüşü beklet; leakage ve zamansal geçerlilik için hedefli yeniden test iste. Yüksek AUC’yi başarı değil, açıklanması gereken anomali say.
Gerekli kanıtKarar-zamanı özellik matrisi; zaman bazlı holdout; out-of-time performans; basit benchmark; segment kalibrasyonu ve hata maliyeti; fold içinde preprocessing.
Karar kaydıChallenge kaydı: güvenilmez iddia, istenen protokol, kabul kriteri ve sonuç gelene kadar kullanım kısıtı.