“Daha İyi” Özelliklerin Modelini Nasıl Batırabilir?

“Daha İyi” Özelliklerin Modelini Nasıl Batırabilir?

O hissi bilir misin? Günlerini harcarsın, kusursuz bir özellik inşa edersin. Tam da istediğin sinyali yakalar. Eğitirsin, değerlendirirsin, Sınıf 2 F1 0.72’den 0.78’e fırlar. Gülümsersin. Sonra leaderboard’a gönderirsin ve skor düşmüştür. Ne olmuştur? Feature engineering ödünleşimiyle tanıştın demektir.

Bu, neredeyse her veri bilimcinin hayatında en az bir kez düştüğü bir tuzak. Ben de birkaç ay önce bu tuzağa düştüm ve tam bir haftamı debug’la harcadım. O yüzden gel, önce kaputun altında gerçekte ne döndüğüne bakalım. Sonra da akıllıca tasarladığın manuel özelliklerin neden geri tepebileceğini ve sana yalan söylemeyen bir özellik değerlendirme iş akışını nasıl kuracağını konuşalım.

Klasik Tuzak: Bir Metriğin Kazancı, Başka Bir Metriğin Kaybıdır

Tam senaryoyu anlatayım. Bir müşteri için çok sınıflı sınıflandırma modeli kuruyordum. Baseline fena değildi. Sonra iki tane elle tasarlanmış özellik ekledim: **Impact Severity** ve **Energy Ratio**. İkisi de ham sensör verisinden türetilmişti ve nadir görülen bir arıza sınıfını yakalamak için tasarlanmıştı. Fiziksel olarak da anlamlıydılar. Validasyonda Sınıf 2 F1 0.72’den 0.78’e çıktı. Güzel, değil mi?

Dur biraz. Tablonun tamamına baktığımda Sınıf 0 ve Sınıf 1 F1 değerlerinin ikisinin de düştüğünü gördüm. Leaderboard ise tüm sınıfların ağırlıklı ortalamasını kullanıyordu ve skor baseline’ın altındaydı. Model, nadir sınıfı daha iyi göstermek için çoğunluk sınıflarını feda etmeyi öğrenmişti.

Bu kötü şans değil. Paylaşılan bir olasılık bütçesinin matematiksel gerçeği. Çoğu çok sınıflı modelde bir sınıfın güvenini artırmak, diğerinin güvenini azaltır. Yeni özelliğin mevcut özelliklerle yüksek korelasyonluysa, bilgi eklemiyorsun demektir; gürültüyü ve çarpıklığı büyütüyorsun.

Manuel Özellikler Neden Geri Teper?

Multikollinearity Sessiz Bir Katile

Yeni özelliğin mevcut iki ya da üç özellikle korelasyonlu olduğunda model, krediyi bunlar arasında böler. Ağaç tabanlı modellerde bu, önemli bölünmeleri gizleyebilir. Doğrusal modellerde ise katsayıları şişirir. Sonuç? Özellikle görülmemiş verilerde daha az istikrarlı tahminler.

Daha kötüsü, multikollinearity her zaman eğitim doğruluğunu bozmaz. Hatta gürültüyü ezberlemene bile yardımcı olabilir. Ama test dağılımı birazcık kaydığı anda o şık yeni özelliğin bir yükümlülüğe dönüşür.

Precision/Recall Ödünleşimi

Sınıf 2’yi bulmak için bir özellik tasarladıysan, büyük ihtimalle Sınıf 2 için recall’ı artırırken Sınıf 1 için precision’ı mahvediyorsundur. Farz et ki threshold kaydı. Daha fazla örnek Sınıf 2 olarak sınıflandırılır ama bunların birçoğu aslında Sınıf 1 ya da Sınıf 0’dır. “Hedef sınıfın” daha iyi görünse bile makro skorun düşer.

Bunu dolandırıcılık tespitinde her zaman görüyorum. Birisi daha fazla dolandırıcılığı yakalayan bir özellik geliştirir ama bu özellik aynı zamanda bir sürü meşru işlemi de flag’ler. Modelin dolandırıcılık recall’ı artar ama false positive oranı ikiye katlanır. Gerçek dünyada bu, kızgın müşteriler ve çok stresli bir destek ekibi demektir.

Leaderboard Metrikleri Genelde Toplulaştırılmıştır

Çoğu leaderboard tek bir skaler metrik kullanır: accuracy, macro-F1, weighted kappa ya da log loss. Bu skaler, sınıf bazındaki kırılımı gizler. Bir dilime göre optimize edersen bütünü optimize etmiyorsun demektir. Sınıf 2 F1’deki beş puanlık artış, diğer iki sınıftaki üçer puanlık düşüşle silinip gidebilir; sınıf ağırlıklarına bağlı olarak.

Bu yüzden artık yarışma ya da proje metriğini son derece dikkatli okuyorum. Metrik weighted F1 ise nadir sınıftaki iyileşmeler neredeyse hiçbir şey ifade etmez. Macro-F1 ise her sınıf eşit önemdedir; umurunda olmayanlar bile.

Gerçek Dünyadan Bir Örnek: Sensör Verisi

Somut bir örnek vereyim. Sıcaklık, titreşim ve basınç sensörleri olan bir üretim tesisi düşün. Baseline model: üç arıza sınıfında 0.85 macro-F1.

Ben bir **energy ratio** oluşturdum: titreşim genliği / basınç varyansı. Fiziksel olarak anlamlıydı. Yüksek enerjili darbeler ciddi arızalara işaret etmeliydi. Eğitim setinde Sınıf 2 F1 0.81’e fırladı. Ama çapraz doğrulamada kazanç tutmadı. Neden? Energy ratio, ham titreşim ve basınçla yüksek korelasyonluydu; yine multikollinearity. Test verisinde düşük basınçtaki sensör gürültüsü oranın patlamasına neden oldu ve modeli sahte Sınıf 2 tahminlerine itti.

Çözüm sezgisel değildi: ham oranı eklemek yerine artık (residual) bir özellik kullandım; basınçla *açıklanmayan* titreşim kısmı. Bu dikleştirilmiş sinyal gerçekten yeni bilgi ekledi ve leaderboard skoru tüm sınıflarda iyileşti. Ders: “Bu özellik mantıklı mı?” diye sorma. “Bu özellik, mevcut modelde henüz olmayan bilgiyi mi sağlıyor?” diye sor.

Bir Örnek Daha: E-Ticaret Churn Tahmini

Abonelik kutusuyla çalışan bir şirketle birlikte çalışmıştım. Pazarlama ekibi, login sıklığını, destek taleplerini ve sosyal medya bahislerini birleştiren bir **müşteri etkileşim skoru** istiyordu. Kulağa harika geliyordu. Ama skor aslında mevcut özelliklerin ağırlıklı bir toplamıydı. Modele eklediğimde özellik önem sıralaması karıştı ama AUC aynı kaldı. Daha kötüsü, düşük etkileşimli kullanıcılar için kalibrasyon bozuldu çünkü skor loss’a hükmediyordu.

Sonunda el yapımı skoru, son yedi gün içinde temas edilen farklı özellik kategorilerinin basit bir sayımıyla değiştirdik. Küçük ve az korelasyonlu bu özellik gerçek bir iyileşme getirdi. Ders yine aynıydı: bazen en gösterişsiz özellik en iyisidir.

Özellikleri Kandırılmadan Nasıl Değerlendirirsin?

1. Çok Metrikli Bir Skor Kartı Kur

Sadece Sınıf 2 F1’i takip etme. Şunları içeren bir skor kartı oluştur:

- Macro-F1 ve weighted-F1
- Her sınıf için precision ve recall
- Log loss ya da Brier skoru (kalibrasyon için)
- Sınıf bazlı metriklerin aynı yönde hareket edip etmediğine dair bir not

Her deneyden sonra genelde şunu yazdırırım:

| Metrik | Baseline | Yeni Özellik | Sonuç |
|---|---|---|---|
| Sınıf 0 F1 | 0.88 | 0.84 | Kötü |
| Sınıf 1 F1 | 0.82 | 0.79 | Kötü |
| Sınıf 2 F1 | 0.72 | 0.78 | İyi |
| Macro-F1 | 0.81 | 0.80 | Kötü |

Bir bakışta hikâye net. O parlak yeni özellik bir sınıfa yardım etmiş ama diğerlerini bozmuş. Bu skor kartı olmasaydı modeli gönderir ve kötü bir sürprizle karşılaşırdım.

2. Korelasyon Denetimi Yap

Manuel bir özellik eklemeden önce mevcut özelliklerle korelasyonunu kontrol et. Pandas’ta `df.corr()` kullan ve mutlak değeri 0.7’nin üzerinde olanlara bak. Yeni özelliğin mevcut olanlara çok yakınsa şunları düşün:

- Gereksiz özelliklerden birini çıkarmak
- Residualization kullanmak (yeni özelliği eski özelliklere regres edip artıkları almak)
- Scikit-learn’ün `SelectKBest` veya `RFECV` araçlarıyla özellik seçimi yapmak

Scikit-learn’ün resmi özellik seçim rehberi pratik yaklaşımlarla dolu: https://scikit-learn.org/stable/modules/feature_selection.html

3. SHAP ile Yönsel Etkileri Anla

Eğitimden sonra SHAP değerlerini hesaplayarak yeni özelliğinin her sınıfı nasıl etkilediğini tam olarak görebilirsin. Bazen bir özellik Sınıf 2 için faydalıyken Sınıf 1 için aktif olarak zararlıdır. SHAP özet grafiği bunu anında gösterir. Kütüphane açık kaynak ve güzel bakılıyor: https://github.com/shap/shap.

Bir sınıf için güçlü pozitif SHAP değerleri, başka bir sınıf için daha da güçlü negatif değerlere sahip “harika” özellikleri birkaç kez yakaladım. Göndermeden önce görmen gereken ödünleşim tam olarak bu.

4. Ablasyon Dene

Ablasyon, bir özelliği çıkarıp ne olacağını görmek demektir. Manuel feature engineering’de şaşırtıcı derecede nadir yapılır. Ben her zaman üç deney koşarım:

- Eski özelliklerle baseline
- Baseline + yeni özellik
- Baseline + yeni özellik, eksi korelasyonlu eski özelliklerden biri

Üçüncü deney ikinciyi geçiyorsa multikollinearity problemini çözmüşsündür. İkincisi birinciden kötüyse özelliği çıkar. İkincisi daha iyiyse ama leaderboard aksini söylüyorsa validasyon kurulumunu derinlemesine incele.

Üçüncü Örnek: Tıbbi Triyaj Sınıflandırması

Bir semptom denetleyici prototipinde çalışmıştım. Amaç hastaları üç aciliyet seviyesine ayırmaktı. Önceden var olan hastalıkların sayısını toplayan bir **komorbidite skoru** oluşturdum. Yüksek aciliyetli hastaların tespitini iyileştirdi ama aynı zamanda modelin mevcut semptomun şiddetini görmezden gelmesine neden oldu. Tek hafif semptomu ve tek komorbiditesi olan bir hasta, gerçek riski düşük olmasına rağmen yüksek aciliyet olarak sınıflandırılıyordu.

Sorun, özelliğimin çok baskın olmasıydı. Model, üzerine bölmek kolay olduğu için ona yapıştı ve daha zengin, daha nüanslı metin özelliklerini görmezden geldi. Bu bir başka kilit ödünleşim: **özellik baskınlığı**. Güçlü bir el yapımı özellik, daha zayıf ama daha bilgilendirici özellikleri dışlayabilir. Regülarizasyon ve özellik etkileşimleri yardımcı olabilir ama çoğu zaman daha basiti daha iyidir.

Daha Büyük Ders: Özellikler Bedava Değildir

Eklediğin her özellik model karmaşıklığını, eğitim süresini ve overfitting ihtimalini artırır. Regülarizasyon yardımcı olabilir ama temelde gereksiz bir özelliği düzeltemez. Her özelliği bir bahis gibi düşünmelisin: birden fazla metrikte yeni ve istikrarlı bir sinyal ekleyerek yerini hak etmeli.

Şunu da öğrendim: bir özellik ekledikten sonra leaderboard düştüğünde, kök neden neredeyse hiçbir zaman “metrik yanlış” değildir. Asıl neden, benim yerel bir optimumun peşinde koşmamdır. Model aptal değil; tam olarak benden ne istediysem onu yapıyor. Ben sadece yanlış şeyi istemişim.

SSS

Bir sınıfta F1 arttı ama toplam leaderboard skorum düştü, neden?

Çünkü leaderboard muhtemelen ağırlıklı ya da makro ortalama kullanıyordur. Modelin, senin odaklandığın sınıfta kazanmak için diğer sınıflardaki precision ya da recall’dan fedakârlık ediyor olabilir. Heyecanlanmadan önce her zaman tam confusion matrix’e bak.

Multikollinear özelliklerle başa çıkmanın en iyi yolu nedir?

Önce korelasyonu kontrol et. İki özellik yüksek korelasyonluysa birini çıkar ya da yeni özelliğin residualize edilmiş halini kullan. L1 veya L2 gibi regülarizasyon modeli stabilize etmeye yardımcı olabilir ama gereksizliği kaldırmak, cezalarla düzeltmeye çalışmaktan genelde daha etkilidir.

Modern makine öğrenmesinde manuel feature engineering hâlâ işe yarıyor mu?

Evet ama yalnızca modelde zaten olmayan bir alan bilgisini kodladığında. Özellik, mevcut özelliklerin matematiksel bir birleşimiyse genelde fayda etmez. Gerçekten yeni bir sinyal yakalıyorsa güçlü olabilir. Önemli olan, gerçekten bağımsız bilgi eklediğini doğrulamaktır.

Bir özelliğin gerçekten yardımcı olup olmadığını nasıl anlarım?

Baseline model ile özellikli modeli birden çok metrik ve çapraz doğrulama ile karşılaştır. Ablasyon yap. Özellik önemine ve SHAP değerlerine bak. İyileşme fold’lar ya da metrikler arasında tutarsızsa büyük ihtimalle gürültüyü ezberliyorsun demektir.

Son Düşünceler

Kusursuz özelliği inşa etmenin heyecanını bilirim. Sanki şifreyi kırmışsın gibi gelir. Ama leaderboard nihai hakemdir. Çok metrikli değerlendirmeyi iş akışına ne kadar erken eklersen, problemin sadece bir dilimine yardım eden özelliklerle o kadar az zaman kaybedersin.

Bir dahaki sefere o akıllı “impact severity” özelliğini göndermek üzereyken dur. Kendine sor: “Bu yeni bilgi mi ekliyor, yoksa zaten sahip olduğum bir sinyali mi güçlendiriyor?” Gelecekteki sen ve leaderboard sıralaman sana teşekkür edecek.