Tabular (sütunlu) veride sınıflandırma ya da regresyon yapıyorsanız, karar ağacı ailesi çoğu zaman ilk akla gelen seçeneklerden olur: hızlı bir başlangıç, güçlü bir temel performans ve makul bir açıklanabilirlik. Ancak üretime yaklaştıkça tek bir ağacın sınırları (özellikle de aşırı uyum ve tutarsızlık) görünür hâle gelir. Bu noktada ensemble yöntemleri (birden çok modelin birlikte çalışması) devreye girer: Random Forest gibi bagging tabanlı yaklaşımlar ya da XGBoost/LightGBM gibi gradient boosting ailesi.
Bu yazı, “hangi algoritma daha iyi?” sorusunu tek cümleyle yanıtlamaya çalışmaz. Çünkü pratikte sonuçlar; veri setine, özellik tiplerine, hedef metriklere, gecikme bütçesine, donanıma ve hiperparametrelere ciddi biçimde bağlıdır. Bunun yerine, seçim yaparken bakmanız gereken doğruluk–latency–maliyet dengesini netleştirir ve üretim öncesi kısa benchmark için uygulanabilir bir çerçeve sunar.
Varsayımlar ve kapsam (yanlış uygulamayı önlemek için)
- Veri tipi: Odak, ağırlıklı olarak tabular veride ağaç tabanlı modellerdir.
- Donanım: Örnekler ağırlıkla CPU çıkarımı düşünülerek anlatılır; GPU/özel hızlandırıcılar ve farklı derleme/servisleme seçenekleri sonuçları ciddi değiştirebilir.
- Kullanım şekli: Online (tekil istek) ve batch kullanımında latency/maliyet profili farklıdır; bu yüzden ölçüm şablonu iki modu da ayrı izlemeyi önerir.
Hızlı sözlük: Karar ağacı ve ensemble yöntemleri nedir?
Decision Tree (Tek karar ağacı)
Karar ağacı, veriyi ardışık bölmelerle parçalara ayırarak tahmin yapan bir modeldir. Genellikle yorumlaması ve hata analizi yapması kolaydır. Buna karşın tek ağaç, veri setindeki gürültüye duyarlı olabilir ve yüksek varyans nedeniyle aşırı uyum riski taşıyabilir. Ensemble yöntemlerinin önemli bir motivasyonu da bu varyansı azaltmaktır.
Ensemble kavramlarına giriş ve ağaç tabanlı yöntemlerin genel çerçevesi için scikit-learn dokümantasyonu iyi bir başlangıç noktasıdır: scikit-learn Ensemble Methods.
Random Forest (Bagging + rastgelelik)
Random Forest, birden çok karar ağacını eğitip tahminlerini birleştirerek (oylama/ortalama) genellemeyi güçlendirmeyi hedefler. Her ağaç farklı bir bootstrap örneklemiyle eğitilir ve bölme noktalarında rastgele özellik alt kümeleri kullanılır. Bu yapı, tek ağaca göre daha kararlı sonuçlar verme eğilimindedir; ancak ağaç sayısı arttıkça bellek kullanımı ve çıkarım (inference) maliyeti büyüyebilir. Parametrelerin etkisini anlamak için scikit-learn referansı pratik bir kaynaktır: RandomForestClassifier.
Gradient Boosting (XGBoost, LightGBM gibi)
Gradient boosting yaklaşımında modeller ardışık biçimde eklenir; her yeni ağaç, önceki hataları azaltmaya çalışır. Bu aile, tabular problemlerde sıklıkla güçlü performans verebilen bir seçenek olarak görülür. XGBoost’un ölçeklenebilir ağaç boosting sistemi; düzenleme (regularization) bileşenleri ve sistem optimizasyonlarıyla literatürde geniş yer bulur: Chen & Guestrin (2016), XGBoost.
LightGBM tarafında Microsoft’un yayınladığı benchmark sayfası, bazı senaryolarda farklı GBM implementasyonlarının hız/performans profilinin değişebildiğini örnekler üzerinden gösterir: LightGBM benchmark. Topluluk benchmarklarının ise donanım/ayar bağımlılığı yüksek olduğundan sonuçları “kesin” olarak genellemek doğru değildir: GBM-perf.
Algoritma seçimini aslında ne belirler? Dört temel eksen
- Hedef metrik: AUC/PR-AUC, RMSE/MAE, logloss gibi metriklerin hassas olduğu hata türleri farklıdır.
- Gecikme (latency) bütçesi: Gerçek zamanlı (online) bir API mi, yoksa batch skorlaması mı? p95/p99 gibi kuyruk gecikmelerini de hesaba katmak gerekir.
- Maliyet: Eğitim süresi (deney döngüsü hızı), çıkarımda CPU kullanımı, bellek tüketimi ve altyapı ölçeklenebilirliği.
- Operasyonel gereksinimler: Açıklanabilirlik beklentisi, model güncelleme sıklığı, izleme (monitoring) ve bakım yükü.
En kritik nokta: “En iyi” model tek bir cevap değildir. Bazı veri setlerinde Random Forest hızlı bir “güvenli baseline” iken, bazı senaryolarda boosting ailesi daha yüksek doğruluğa daha az ağaçla ulaşabilir. Bu nedenle, kararın son adımı hedef ortamda kısa benchmark olmalıdır: GBM-perf.
Karar ağacı: Ne zaman yeterli, ne zaman sınırda kalır?
İyi bir başlangıç olduğu senaryolar
- Hızlı prototip: Veri sızıntısı, eksik değerler, temel özelliklerin etkisi gibi konularda hızlı sinyal verir.
- Basit iş kuralları: Özellikle küçük derinlikte (sığ) ağaçlar, “kural seti” gibi yorumlanabilir.
- Gecikmenin kritik olduğu ve modelin küçük tutulabildiği durumlar: Sığ bir ağaç çok hızlı çalışabilir.
Sık görülen sınırlar
- Yüksek varyans: Eğitim verisine fazla uyum sağlama eğilimi, yeni veride performans dalgalanmasına yol açabilir.
- Küçük veri değişimlerinde kararsızlık: Veri setindeki ufak oynamalar bile bölme yapısını değiştirebilir.
Pratik öneri: Tek ağacı “final model” olarak düşünmeden önce, en azından Random Forest gibi bir varyans azaltma yaklaşımıyla kıyaslamak genellikle daha sağlıklı bir resim verir. Ensemble yöntemlerinin motivasyonunu scikit-learn özetler: Ensemble methods.
Random Forest: Kararlılık kazanırken maliyette neler değişir?
Random Forest’ın temel vaadi, çok sayıda ağacın birleşimiyle daha kararlı genelleme elde etmektir. Bu, birçok tabular problemde onu güçlü bir baseline yapabilir. Ancak üretim maliyeti ve gecikme açısından şu trade-off’lar önemlidir:
1) Ağaç sayısı (n_estimators) ve çıkarım maliyeti
Genel sezgi: daha fazla ağaç çoğu zaman daha stabil sonuçlar getirir; fakat çıkarımda her örnek için daha çok ağaç dolaşılır. Bu da CPU zamanı ve çoğu durumda gecikme üzerinde baskı yaratır. Parametre davranışları için referans: RandomForestClassifier docs.
2) Ağaç derinliği (max_depth) ve bellek
Daha derin ağaçlar, daha fazla düğüm demektir; bu da model boyutunu büyütür ve cache verimliliğini düşürebilir. Düşük latency hedefleniyorsa sığ ağaçlar (veya daha agresif kısıtlar) daha öngörülebilir bir çıkarım profili sunabilir.
3) Paralellik: eğitimde avantaj, çıkarımda şartlara bağlı
Random Forest eğitiminde ağaçlar paralel eğitilebilir. Çıkarım tarafında ise paralellik; batch boyutu, sunucu başına eşzamanlı istek sayısı ve uygulama diline göre değişen kazançlar sağlar. Bu yüzden “her zaman hızlıdır” gibi genellemeler yerine, hedef ortamda ölçmek daha güvenlidir.
Gradient Boosting (XGBoost, LightGBM): Doğruluk çıtasını yükseltirken neler ödersiniz?
Gradient boosting ailesi, tabular görevlerde çoğu zaman yüksek doğruluk sağlayabilen güçlü bir seçenektir. Bununla birlikte eğitim süreci daha hassas ayar gerektirebilir ve bazı konfigürasyonlar çıkarım maliyetini artırabilir.
XGBoost: düzenleme ve ölçeklenebilir sistem tasarımı
XGBoost’un literatürde öne çıkan yönlerinden biri, ağaç boosting’e düzenleme terimlerini entegre etmesi ve büyük ölçekli eğitim için sistem optimizasyonları sunmasıdır: XGBoost: A Scalable Tree Boosting System.
Maliyet açısından pratik okuma: Boosting’de ağaçlar ardışık eklendiğinden, eğitim çoğu zaman Random Forest’a kıyasla daha “seri” bir yapı sergiler. Buna karşın daha az sayıda ağaçla hedef doğruluğa ulaşabildiğiniz durumlar da vardır; bu, çıkarım maliyetini bazı projelerde dengeleyebilir. Hangi tarafta kazanacağınız, veri setine ve ayarlara bağlıdır.
LightGBM: hız/performans sonuçları senaryoya bağlıdır
LightGBM benchmark notları, bazı veri seti ve donanım kombinasyonlarında eğitim/çıkarım hızının avantajlı olabildiğini gösterir; ancak bu sonuçlar ayarlar, veri temsili ve donanım koşullarına göre değişir: Microsoft LightGBM benchmark. Topluluk kıyasları da aynı uyarıyı tekrarlar: GBM-perf.
Operasyonel not: Boosting modellerinde hiperparametreler (öğrenme oranı, ağaç sayısı, yaprak/dal kısıtları gibi) performans ve maliyeti birlikte belirler. Bu yüzden “varsayılan ayarlar” ile hüküm vermek yerine küçük bir arama alanı tanımlamak daha sağlıklı olur.
Doğruluk–Latency–Maliyet karşılaştırması: Pratik bir tablo
Aşağıdaki tablo, karar verirken sık sorulan soruları “genel eğilim” düzeyinde özetler. Bu bir garanti değil, ölçüm tasarlamak için bir başlangıçtır.
| Model ailesi | Güçlü yön | Tipik risk / maliyet | Ne zaman tercih edilir? |
|---|---|---|---|
| Decision Tree | Hızlı prototip, yorumlanabilirlik | Varyans ve aşırı uyum riski | Küçük/sade problemler, kural benzeri ihtiyaçlar |
| Random Forest | Kararlılık, güçlü baseline | Ağaç sayısı arttıkça bellek ve çıkarım maliyeti artabilir | Robust baseline, düşük sürpriz beklentisi |
| XGBoost (GBDT) | Yüksek doğruluk potansiyeli; düzenleme ve sistem optimizasyonları | Hiperparametre hassasiyeti; eğitim ve bakım karmaşıklığı artabilir | Skor artışı kritikse ve ayar/bakım kapasiteniz varsa |
| LightGBM (GBDT) | Bazı senaryolarda hız avantajı (veri/donanım/ayar bağımlı) | Benchmark sonuçları değişken; ayar ve veri yapısı önemli | Büyük tabular iş yükleri, hızlı iterasyon ihtiyacı |
Kopyalanabilir benchmark şablonu (üretim odaklı)
Aşağıdaki şablon, “kendi ortamında ölç ve karar ver” yaklaşımını pratikleştirir. Amaç; yalnızca doğruluğu değil, çıkarım gecikmesini ve kaynak tüketimini de aynı disiplinle ölçmektir (donanım/ayar bağımlılığı için bkz. GBM-perf).
Ne ölçmeliyim? (minimum metrik seti)
- Kalite: AUC veya PR-AUC (sınıflandırma), RMSE/MAE (regresyon), ayrıca mümkünse logloss.
- Latency: p50, p95, p99 (online ise batch=1; batch ise belirlenmiş batch boyutunda).
- Bellek: Süreç RSS (servis ayağa kalktıktan sonra) ve mümkünse “yük altındaki” tepe değer.
- Model boyutu: Serileştirilmiş model dosyası boyutu (diskte).
- Tekrar üretilebilirlik: Random seed, thread sayısı ve aynı veri bölme (split) bilgisi.
Test protokolü (kısa ama disiplinli)
- Sabit koşullar: Aynı train/valid split, aynı ön-işleme ve aynı özellik seti.
- İki kullanım modu:
- Online: batch_size=1 (tekil istek) + eşzamanlı istek sayısı hedefinize yakın bir ayar.
- Batch: ör. batch_size=128 veya 1024 (iş yükünüze göre sabitleyin).
- Warmup: İlk ölçümlerde JIT/önbellek etkisini azaltmak için ör. 100–500 tahmin “ısınma” çalıştırması yapın; sonra ölçmeye başlayın.
- Tekrar: Her model/konfigürasyon için en az 20–30 tekrar ölçümü alın; p95/p99 için yeterli örneklem üretmeye çalışın.
- Çıktı: Sonuçları tek bir tabloya yazın ve ortam bilgisini (CPU modeli, RAM, thread ayarı) not edin.
Sonuç tablosu (kopyala-yapıştır)
| Model | Konfig | AUC/PR-AUC | Logloss | Latency p95 (ms) batch=1 | Latency p99 (ms) batch=1 | Latency p95 (ms) batch=128 | RSS bellek (MB) | Model boyutu (MB) |
|---|---|---|---|---|---|---|---|---|
| Decision Tree | max_depth=… | … | … | … | … | … | … | … |
| Random Forest | n_estimators=…, max_depth=… | … | … | … | … | … | … | … |
| XGBoost | n_estimators=…, learning_rate=… | … | … | … | … | … | … | … |
| LightGBM | n_estimators=…, learning_rate=… | … | … | … | … | … | … | … |
Üretim için seçim çerçevesi: 7 adımda “ölçerek karar verme”
1) Kısıtlarınızı yazın (tek sayfalık brief)
- Online mı batch mi?
- Hedef gecikme ve eşzamanlı istek sayısı (p95/p99 hedefi varsa not edin).
- Model güncelleme sıklığı (günlük/haftalık/aylık).
- Açıklanabilirlik ve denetim gereksinimleri.
2) Baseline’ı netleştirin
Genellikle şu sırayla ilerlemek pratik olur:
- Sığ bir decision tree ile veri sorunlarını görün.
- Random Forest ile sağlam baseline elde edin (scikit-learn): RandomForestClassifier.
- Boosting (XGBoost/LightGBM) ile “ek doğruluk” potansiyelini test edin: XGBoost paper, LightGBM benchmark.
3) Aynı veri bölme ve aynı ön-işleme ile karşılaştırın
Adil kıyas için şu iki noktayı sabitleyin:
- Aynı train/validation ayrımı (ve mümkünse aynı cross-validation şeması).
- Aynı özellik seti ve aynı veri hazırlama adımları.
4) “Bir model” yerine “küçük bir ayar ızgarası” deneyin
Tek bir ayarla karar vermek risklidir. Çok büyük bir arama da şart değildir. Örneğin her model için 3–5 konfigürasyonla başlayın.
- Random Forest: n_estimators ve max_depth gibi temel parametrelerin birkaç değeri.
- Boosting: ağaç sayısı–öğrenme oranı dengesini temsil eden birkaç kombinasyon.
Donanım ve ayar bağımlılığı nedeniyle ölçümü kendi ortamınızda doğrulamak önemlidir: GBM-perf.
5) Sadece doğruluk değil, çıkarım profilini ölçün
- Tek örnek gecikmesi ve batch gecikmesi (kullanım şeklinize göre).
- CPU kullanımı ve bellek tüketimi.
- Soğuk başlangıç etkisi (servis yeniden başladığında gecikme).
6) “Kazanan”ı kullanım senaryosuna göre seçin
Örnek karar mantığı:
- Boosting doğruluk getiriyor ama latency bütçesini aşıyorsa: modeli küçültmeyi (ağaç sayısı/derinliği kısıtları) deneyin; olmazsa Random Forest veya daha küçük bir boosting konfigürasyonu daha güvenli olabilir.
- Random Forest yeterli doğruluğu veriyor ve operasyonel olarak kolay yönetiliyorsa: “en iyi” olmak yerine “en sorunsuz” olmak üretimde daha değerli olabilir.
7) Son olarak: Üretim benzeri mini load testi
Benchmark’ı yalnızca notebook’ta değil, mümkünse üretime benzeyen bir servis ortamında kısa bir yük testiyle tamamlayın. Bu; kuyruk gecikmesi, paralellik ve bellek davranışını daha gerçekçi gösterir.
Latency ve maliyet düşürmek için model-agnostik ipuçları
- Model karmaşıklığını sınırlayın: Ağaç sayısı ve derinlik (veya yaprak kısıtları) çıkarım maliyetinin ana belirleyicilerindendir.
- Ön-işlemeyi sadeleştirin: Karmaşık feature pipeline’ları bazen modelden daha pahalıya mal olur.
- Batch stratejisini bilinçli seçin: Online tekli istek ile batch skorlamanın maliyet profili farklıdır.
- İzlemeyi (monitoring) planlayın: Veri dağılımı kayması (drift) ya da özellik kalitesi sorunları, “model seçimi” kadar etkilidir.
Not: Servisleme/optimizasyon adımlarının etkisi; kullandığınız kütüphane, model formatı ve hedef donanıma sıkı biçimde bağlıdır. En güvenilir yaklaşım yine ölçmektir.
Özet: Hangi modeli seçmeliyim?
Genel bir yol haritası:
- Hızlı anlamak için decision tree.
- Güvenli baseline ve düşük sürpriz için Random Forest (scikit-learn): RandomForestClassifier.
- Daha yüksek doğruluk potansiyeli için boosting ailesi (XGBoost/LightGBM) ve küçük bir hiperparametre taraması: XGBoost, LightGBM benchmark.
- Son sözü hedef donanımda kısa benchmark söyler: GBM-perf.
Bu yaklaşım, “tek doğru model” aramak yerine, kendi ürün kısıtlarınız için en doğru dengeyi bulmanıza yardımcı olur.