Neden “iyi model metriği” her zaman “iyi iş sonucu” değildir?

Ürün ekipleri model performansını çoğu zaman tek bir sayıya indirgemek ister: ROC AUC, F1, doğruluk (accuracy) ya da RMSE. Bu metrikler değerlidir; ancak iş KPI’ları (ör. gelir, maliyet, risk, elde tutma, müşteri memnuniyeti) ile aynı şey değildir. Model metriğindeki iyileşmenin iş KPI’ına otomatik yansımayabileceği; bu nedenle hedeflerin, kabul kriterlerinin ve canlı etki ölçümünün ayrıca tasarlanması gerektiği, Google’ın ML proje yönetimi rehberinde açıkça vurgulanır (Google Developers: Measuring success in ML projects).

Bu yazı, veri bilimi ile ürün/iş paydaşlarının aynı dili konuşabilmesi için model değerlendirme metriklerini iş KPI’larına eşleme sürecini adım adım bir çerçeveye oturtur.

Önce çerçeveyi kurun: KPI, model metriği, kabul hedefi, eşik

Karışıklığı azaltmak için dört kavramı ayrı düşünün:

  • İş KPI’ı: İşin nihai başarısı (örn. dönüşüm oranı, churn, işlem başına maliyet, dolandırıcılık kaybı).
  • Model metriği: Modelin tahmin performansı (örn. precision/recall/F1, ROC AUC, AUC-PR; regresyonda MAE/RMSE/MAPE).
  • Kabul edilebilirlik hedefi (acceptability goal): Canlıya çıkmak için minimum koşullar. Bu hedefleri en baştan tanımlamak ve kararları buna göre almak, Google rehberinin temel önerileri arasındadır (Google Developers: Measuring success in ML projects).
  • Eşik (threshold): Skor üreten modellerde “pozitif” kararın kesim noktası. Eşik değiştikçe precision/recall dengesi değişir; bu nedenle eşik analizi kritik bir karar kaldıraçıdır. Vertex AI değerlendirme rehberi; eşik, metrikler ve değerlendirme dilimleri (slices) üzerinden analiz yaklaşımını detaylandırır (Vertex AI: Evaluate classification/regression models).

Pratik kural: KPI “neden”i, model metriği “nasıl”ı, kabul hedefi “ne zaman yeter”i, eşik ise “hangi noktada aksiyon”u temsil eder.

Adım adım eşleme yöntemi (paydaşlarla birlikte uygulanabilir)

1) İş kararını ve hata maliyetlerini yazın: “Model hangi kararı değiştirecek?”

Modeliniz bir skor üretse bile, gerçek dünyada bir karar mekanizmasını tetikler: onayla/engelle, göster/gösterme, önceliklendir/geri sıraya at vb. Eşleme çalışması bu sorularla başlar:

  • Model kararı hangi iş sürecine bağlanacak?
  • Yanlış pozitif (FP) olursa neye mal olur (müşteri deneyimi, operasyon, gelir)?
  • Yanlış negatif (FN) olursa neye mal olur (risk, kayıp, kaçan fırsat)?
  • Karar anlık mı (real-time) yoksa batch mi?

Bu çıktılar, hangi metriğin “ana metrik” olacağına temel oluşturur.

2) Tek bir “optimizasyon metriği” seçin; yan etkiler için koruyucu metrik belirleyin

Uygulamada en sık sorun, aynı anda her şeyi optimize etmeye çalışmaktır. Google rehberi, projeyi yönetilebilir ve kıyaslanabilir kılmak için tek bir ana metrik üzerinde uzlaşmayı; diğer önemli metrikleri ise “kabul hedefi/koruyucu metrik” gibi rollerle çerçevelemeyi önerir (Google Developers: Measuring success in ML projects).

  • Ana metrik: İş hedefiyle en yakından ilişkili teknik metrik (örn. recall veya AUC-PR).
  • Koruyucu metrik(ler): Kabul edilemez yan etkileri engelleyen sınırlar (örn. precision tabanı, gecikme/latency üst sınırı, kritik dilimlerde minimum performans). Dilim bazlı değerlendirme yaklaşımı için bkz. (Vertex AI: Evaluate classification/regression models).

3) Kabul edilebilirlik hedeflerini ve eşik stratejisini netleştirin

Kabul hedefleri, “modeli canlıya almak için minimum çıta”dır. Tipik örnekler:

  • Performans: “Recall ≥ X” ve/veya “Precision ≥ Y”.
  • Operasyon: “Günlük inceleme kapasitesi en fazla N kayıt” (bu, eşik seçimini doğrudan etkiler).
  • Dilim (slice) hedefleri: Kritik kullanıcı/ürün gruplarında minimum performans. Vertex AI rehberi, dilim bazlı incelemeyi değerlendirme pratiğinin bir parçası olarak ele alır (Vertex AI: Evaluate classification/regression models).

Not: Evrensel “doğru eşik” yoktur. Eşik, hata maliyeti ve operasyon kapasitesiyle birlikte belirlenir; canlıda ölçüm planı da bu çerçevenin parçasıdır (Google Developers: Measuring success in ML projects).

4) Mini örnek: FP/FN maliyetine göre eşik seçimi (sayısal)

Aşağıdaki örnek tamamen temsilidir; amaç yöntemi somutlaştırmaktır.

  • Günde 10.000 işlem var.
  • Dolandırıcılık oranı %1 (yaklaşık 100 gerçek pozitif vaka).
  • Bir yanlış negatif (FN) kaçarsa ortalama maliyet: 100 birim.
  • Bir yanlış pozitif (FP) olursa (boş inceleme/müşteri sürtünmesi) maliyet: 2 birim.

İki eşik seçeneği düşünün:

  • Eşik A (daha düşük): recall %80, precision %30
  • Eşik B (daha yüksek): recall %40, precision %80

Hesap:

  • Eşik A: TP=80, FN=20. Precision %30 ise toplam alarm ≈ 80 / 0,30 ≈ 267 → FP ≈ 187. Toplam maliyet ≈ 20×100 + 187×2 = 2000 + 374 = 2374.
  • Eşik B: TP=40, FN=60. Precision %80 ise toplam alarm = 40 / 0,80 = 50 → FP = 10. Toplam maliyet = 60×100 + 10×2 = 6000 + 20 = 6020.

Bu maliyet varsayımları altında Eşik A daha iyi görünür. Ancak “günde en fazla 60 inceleme yapabilirim” gibi bir kapasite kısıtı varsa, bu kez Eşik B (veya aradaki başka bir eşik) operasyonel olarak tek uygulanabilir seçenek olabilir. Bu nedenle eşik seçimi, teknik metrik + kapasite + maliyet üçlüsüdür.

5) KPI etkisini doğrulayın: kontrollü rollout / deney

Offline metrikler yön gösterir; fakat iş etkisi için kontrollü canlı ölçüm gerekir. Google rehberi bu ayrımı özellikle vurgular (Google Developers: Measuring success in ML projects). Metric tree ve etki/lift gibi kavramlar, uygulamalı eğitim içeriklerinde iş-metrik köprüsü olarak ele alınır (Coursera: Measure ML Impact & Business Value (course overview)).

Sınıflandırma metrikleri: Ne zaman hangisi?

Precision, recall ve F1 (temel tanımlar)

Tanımlar ve formüller için scikit-learn dokümantasyonu referans alınabilir (scikit-learn: precision/recall/F-score support):

  • Precision = TP / (TP + FP)
  • Recall = TP / (TP + FN)
  • F1: precision ve recall’un harmonik ortalaması

KPI eşlemesi açısından pratik yorum:

  • FP maliyeti yüksekse (ör. “masum” müşteriyi haksız yere engellemek), precision için taban hedef koymak mantıklıdır.
  • FN maliyeti yüksekse (ör. kritik olayı kaçırmak), recall genellikle ana metrik olur.
  • İki hata türü de önemliyse, F1 veya F-beta (beta ile recall/precision ağırlığı ayarlanır) değerlendirilebilir (scikit-learn: precision/recall/F-score support).

ROC AUC ve AUC-PR: Dengesiz sınıflarda neden ayrışır?

ROC AUC, farklı eşiklerde ayrıştırma gücünü özetler. Ancak pozitif sınıfın çok nadir olduğu senaryolarda, Precision-Recall eğrisi ve onun alanı (AUC-PR / auPRC) çoğu zaman daha bilgilendirici bir görünüm sağlayabilir. Bu tür değerlendirmeler (auROC/auPRC) ve eşik incelemesi, Vertex AI değerlendirme rehberinde ele alınır (Vertex AI: Evaluate classification/regression models).

Eşik (threshold) ayarı: Metrikleri KPI ile hizalayan kaldıraç

Aynı model, farklı eşiklerde bambaşka bir iş davranışı üretir. Bu yüzden eşik seçimi, KPI eşlemesinin merkezindedir:

  • Manuel inceleme kapasiteniz sınırlıysa eşik yükseltilip daha az olay seçilebilir (genellikle precision artar, recall düşer).
  • Risk azaltımı öncelikliyse eşik düşürülüp daha fazla olay yakalanabilir (genellikle recall artar, FP de artar).

Eşik ve dilim bazlı değerlendirme yaklaşımı için bkz. (Vertex AI: Evaluate classification/regression models).

Regresyon metrikleri: KPI’ya bağlamak için pratik yorum

Regresyon modellerinde metrik seçimi, “hata”nın işte nasıl maliyet yarattığına bağlıdır:

  • MAE: Ortalama mutlak hata; yorumlaması genellikle daha sezgiseldir.
  • RMSE: Büyük hataları daha fazla cezalandırır; uç hatalar işte daha pahalıysa tercih edilebilir.
  • MAPE: Yüzde hata üzerinden düşünmeyi sağlar; bazı durumlarda (ör. gerçek değerlerin çok küçük olduğu aralıklarda) yanıltıcı olabilir. Bu tür nüansları, kendi veri dağılımınız ve KPI maliyet yapınızla birlikte değerlendirin.

Not: İş maliyeti asimetrikse (örn. “eksik tahmin” ile “fazla tahmin”in maliyetleri farklıysa), tek bir özet metrik yerine asimetrik maliyeti yansıtan karar kuralı veya özel bir kayıp yaklaşımı daha uygun olabilir.

Hızlı eşleme tablosu: İş KPI’sı → teknik metrik → uygulama notu

İş hedefi / KPI Yakın model metrikleri Eşik ve süreç notu
Risk azaltma (kaçırılan kritik olay maliyeti yüksek) Recall, AUC-PR (auPRC) Düşük eşik daha çok yakalama sağlar; FP artışının operasyon maliyetini ayrıca modelleyin (Vertex AI: Evaluate classification/regression models).
Müşteri deneyimi (haksız engelleme/yanlış alarm maliyeti yüksek) Precision, F-beta (precision ağırlıklı) Yüksek eşik daha az yanlış alarm; FN riskini kabul hedefleriyle sınırlayın (Google Developers: Measuring success in ML projects).
Manuel inceleme maliyeti / operasyon kapasitesi Seçilen kayıt sayısı, precision@k “Günde N kayıt” gibi kapasite hedefi eşik ayarını belirler; dilim bazında izleyin (Vertex AI: Evaluate classification/regression models).
Gelir/CTR gibi optimizasyon KPI’ları (sıralama/öneri etkisi) Offline proxy metrikler + online deney Offline metrikler yön gösterir; KPI doğrulaması için kontrollü rollout/deney gerekir (Google Developers: Measuring success in ML projects).

Canlı öncesi kontrol listesi (kısa)

Jeneratif (LLM) sistemlerde KPI eşleme neden daha zor?

Jeneratif sistemlerde “tek doğru cevap” her zaman tanımlı değildir. Kalite, fayda, güvenlik, üslup ve görev başarısı gibi boyutlar birlikte değerlendirilir; bu da tek bir offline metriği doğrudan tek bir iş KPI’ına bağlamayı zorlaştırabilir.

Pratik yaklaşım: Önce ürün seviyesinde ölçülebilir ara hedefler (ör. görev tamamlama oranı, kullanıcı geri bildirimi, belirli hata türlerinin sıklığı) tanımlayın; sonra kontrollü ölçümle bunların KPI üzerindeki etkisini doğrulayın. Metric tree ve deney/lift kavramlarının uygulamalı anlatımı için bkz. (Coursera: Measure ML Impact & Business Value (course overview)).

Sonuç: Eşleme bir tablo değil, tekrarlanan bir süreçtir

Model metriklerini iş KPI’larına eşlemek; karar maliyetlerini yazma, ana metriği belirleme, kabul hedefleri koyma, eşik ve dilim analizleriyle güvence alma ve en sonunda canlı ölçümle etkiyi doğrulama sürecidir. Başarı ölçümünün model doğruluğundan daha geniş bir çerçeve olduğu, Google’ın proje rehberinde özellikle vurgulanır (Google Developers: Measuring success in ML projects).