Her Özellik Normal Göründüğünde Veri Saptaşını Nasıl Yakalarsınız?.

Yeni bir fiyatlandırma seviyesi, müşterilerin daha sık ve daha küçük tutarlarla işlem yapmasına yol açtığında, tek tek incelenen tüm veri özellikleri normal aralıkta kalsa bile model performansı sessizce düşüyor. Bu durum, yalnızca iki özelliğin birlikte hareketiyle ortaya çıkan “veri saptaşını” (data drift) yakalamak için bireysel feature bazlı izleme yöntemlerinin yetersiz kaldığını gösteriyor; sorunu çözen çözüm ise bir sınıflandırıcı modeli kullanarak bu eşzamanlı değişimi fark ettirmek.

Bu tür sessiz bozulmalar, model canlıya alındıktan sonra hiçbir hata kodu veya uyarı vermeksizin ilerliyor. Gözlemlenen tüm paneller yeşil görünürken sonuçların yavaşça kötüleşmesi, ancak bir ekibin artık kabul edilemez hale gelen iş akışları nedeniyle soruyu sormasıyla ortaya çıkıyor. Kodda ya da veri hattında hiçbir değişiklik olmamasına rağmen dünyanın değişmiş olması, izleme sistemlerinin neden bu kaymayı yakalayamadığını açıklıyor.

Sessiz bozulan parça: Dağılım mı, ilişki mi?

Kağıt üzerinde bireysel özellik takibi kötü bir fikir değil, ancak eksik bir yaklaşım. Sorun tek bir özellikte değil, iki özelliğin birlikte hareketinde ortaya başladığında sistem çöküyor ve gerçek veri bu şekilde bozuluyor; çoğu teknik yazının kabul ettiğienden çok daha kolay bir yol.

Fiyatlandırma seviyesi örneği bunun temiz bir örneği çünkü içinde hiçbir şey tek başına yanlış görünmüyor. Ortalama işlem tutarına yalnızca PSI uyguladığınızda sorun çıkmıyor, son 30 gündeki işlem sayısına uyguladığınızda da çıkmıyor. İki özellik arasındaki ilişki dönüyor ancak PSI tasarım gereği iki sütunu aynı anda hiç incelemiyor; bu bir metrik hatasından çok, o metric’in aşması için inşa edilmediği bir sınırdır.

Sorun dolayısıyla şöyle değişiyor: Dağılımı değil ilişkiyi nasıl kontrol edersiniz? Cevap, öğrenmek için egzotik istatistikler öğrenmek değil; yalnızca bir modelin sizin yerinize fark etmesini sağlamak.

Marfaza mı yoksa sızıntı mı?

Saptaş kontroline geçmeden önce kaçınılmaz olarak sızıntı (leakage) kontrolü yapılmalı. Tahmin anında mevcut olmayacak bilgiler kullanılarak hesaplanmış bir özellik, hedefe karşı şüpheli derecede yüksek karşılıklı bilgi (mutual information) gösterir; örneğin post_hoc_flag_count gibi sütunlar, hile yaptığı için tahminiymiş gibi görünür.

Bu korumanın ilk sürümü eşiği aşan her şeyde kesin reddiye veriyordu ve yalnızca bir yeniden eğitim kadar dayanabildi. device_risk_score bu kuralı sürekli ihlal ediyordu ancak o gerçekten sızıntılı değil, güçlü bir özellikti; her çalışmada kendi kodumla tartışmak yerine sorunu düzgünce çözmeye karar verdim.

Sızıntının split içinde sağlamlığını koruması nedeniyle o sütunla eğitilen bir model, harika görünen ancak hiçbir şey ifade etmeyen bir doğrulama skoru raporlar. Bu yalnızca özellik üretim ortamında var olmayı bıraktığında ortaya çıkar; o zaman artık bir kod inceleme yorumu değil, geriye dönük değerlendirmede rahatsız edici sorular soran kişilerdir.

Veri saptışı ve sızıntı koruması üzerine çalışan bir mühendis

Sorun şu: İlişkiyi nasıl kontrol edersiniz?

Bu teknikin bir adı var, buna “düşmanlık doğrulaması” (adversarial validation) deniyor ve olduğundan daha görkemli yankılanıyor. Eğitim satırlarına 0 etiketi, üretimden yeni bir örneğe 1 etiketi verip onları ayırt eden bir sınıflandırıcı eğitirsiniz.

Eğer iki örnek gerçekten aynı dağılımdan geliyorsa, model tahmin etmekten daha iyi yapamaz ve AUC yaklaşık 0.5 olur; ancak onları ayırt edebiliyorsa bir şeyler değişmiştir. Sınıflandarıcı tüm özellikleri aynı anda aldığı için, sütun sütuncuna yapılan kontrolün doğrudan atladığı tam da bu tür eşzamanlı kaymayı yakalar.

Küçük topluluları hiç ele almayan ilk taslak, ne kadar veri gelirse gelsin her zaman çapraz doğrulamalı AUC çalıştırıyordu. Bu, üretimin bir günü için yeterince iyidir ancak ince bir canary örneğinde başarısız olur; bu durumda bir kat neredeyse pozitif örnek içermeyebilir ya hata verir ya da yalnızca gürültüden ibaret bir numara döndürür.

Satır eşiğinin altında tek bir eğitim/test ayrımı kullanılıyor. AUC 0.5’e yakınsa sınıflandarıcı tahmin ediyor, hiçbir şey değişmemiş demektir; yaklaşık 0.65’in üzerindeyse gerçek yapıyı bulmuş demektir ve top_drift_features, en çok histogramı hareket eden sütunlardan ziyade her şeyle ilişkisi sessizce dönen sütunları isimlendiriyor.

Bunun size maliyeti nedir?

Hesaplama bu tekniğin ilk hissedilecek maliyetidir; her örnekte çapraz doğrulamalı bir sınıflandarıcı, iki histogramı karşılaştırmaktan çok daha ağırdır ve günlük veya saatlik çalıştırmak için uygundur. Ancak isteğe bağlı tetiklendiği anda gerçekten kötü bir fikir olur.

Eşik kesin bilim değildir; 0.65, PSI’nın 0.1/0.2 bantları gibi bir textbook’tan emredilen bir değer değil. Deneme-yanılma ile seçtim, önce çok fazla işaretlediğini izledim, yukarı çıkardım ve hala tanımadığım bir veri setinde ona tamamen güvenmiyorum; buraya birkaç dakika yerine gerçek zaman ayırmalısınız.

Bu, PSI’nın yerini almaz ve almasını da istemiyorum: Tek seferde yalnızca bir özelliği kontrol eden ucuz bir temeli koruyun. Bu temelin temiz döndüğü ancak performans yine de kaybolduğu anda buna başvurun; çünkü o belirli kombinasyon—sessiz panellerle eşleştirilmiş sessizce kötüleşen sonuçlar—genellikle dağılımın değil ilişkinin altında kaydığı yerdir.

Yüksek karşılıklı bilgi otomatik olarak sızıntı değildir. Bazen yalnızca iyi bir özelliktir ve koruma bunları kendi başına ayırt edemez; bu yüzden allowlist, bunun fire-and-forget kuralından çok ara sıra insan değerlendirmesi gerektiğinin kabulüdür.

Kaynak

Sizin durumunuz nerede?

Bireysel özellik saptaş kontrolleri bir soruyu yanıtlar ve bunu iyi yapar: Tek bir giriş mi hareket etti? Daha zor olanı yanıtlamak için hiç inşa edilmediler—girişler arasındaki ilişkinin hâlâ ayakta olup olmadığı.

O ikinci soru genellikle üretimde bir şeyi kıran sorudur ve tüm bireysel panellerin tamamında yeşil rapor verirken sessizce kırılır. Zaten sahip olduğunuz şeyi sökmenize gerek yok; PSI’ı çalıştırın, iyi olduğu konuda ona güvenin. Ancak “her şey temiz” dediğinde sandığınız anlamı taşımadığını unutun ve bir sonraki sefer bunun yerine başvurun.

Bu tür makaleler, model doğrulamadan çıktıktan sonra dayanıp durmayacağını belirleyen mühendislik kararları üzerine yazılıyor; daha fazlası için bülten aboneliği yapılabilir.