Mimari ve çalışma modeli
Model drift, üretimde model davranışının veya veri dağılımının kabul edilen baseline'dan değişmesidir. Data drift giriş özelliklerinin, prediction drift çıktıların, concept drift ise giriş ile gerçek sonuç arasındaki ilişkinin değişmesini anlatır. Dağılım farkı tek başına kalite kaybını kanıtlamaz; gerçek etiketler geldiğinde görev metriğiyle doğrulama gerekir. İzleme bu sinyalleri operasyonel latency, hata ve maliyetle birlikte ele alır.
Baseline eğitim, doğrulama veya yakın dönem üretim penceresinden seçilebilir. Eğitim baseline'ı training-serving skew için anlamlıdır; kayan üretim baseline'ı mevsimselliğe uyum sağlar fakat yavaş bozulmayı normalleştirebilir. Her özellik için tip, eksik değer, kategori sözlüğü ve dönüşüm sürümü kaydedilmelidir. Kişisel veri veya ham prompt toplamak zorunlu değildir; gerekli istatistikler ve güvenli örneklem tasarlanmalıdır.
Eşik bir sağlayıcı varsayılanından kopyalanmamalıdır. Jensen-Shannon divergence, PSI, L-infinity veya kalite metriği iş etkisine göre kalibre edilir. Çok sayıda özellikte bağımsız alarm, yanlış pozitif seli üretir. Özellik önemini, minimum örnek sayısını, ardışık pencere koşulunu ve uyarı/sayfa seviyesini kullanın. Label gecikmesi varsa drift erken uyarı, ground truth kalite metriği ise karar kanıtı olarak ayrılmalıdır.
Google Cloud, AWS ve Azure izleme servisleri baseline ve üretim dağılımlarını karşılaştıran yerel seçenekler sunar; kapsam ve yaşam döngüsü değişebilir. Aynı mimari açık araçlarla da kurulabilir: inference logundan şema kontrollü özellik özeti, zaman pencereli istatistik işi, metric store, alert ve inceleme kaydı. Üretici seçimi yerine veri sözleşmesi, geri alma, yeniden eğitim onayı ve platformdan çıkarılabilir kanıt önceliklendirilmelidir.
- 1Sürümlü model ve veri sözleşmesi
- 2Baseline ile üretim pencere özeti
- 3Drift, kalite ve operasyon metriği
- 4İnceleme, canary veya geri alma kararı
Tasarım parametreleri
- Baseline penceresi
- Eğitim, doğrulama ve yakın üretim baseline'larının amacını ve yenileme sahibini yazın.
- Örnek hacmi
- Metrik hesaplanmadan önce minimum kayıt ve kategori başına alt sınır belirleyin.
- Eşik politikası
- Warning ile action eşiklerini, ardışık pencere sayısını ve iş etkisini birlikte tanımlayın.
- Ground truth gecikmesi
- Etiketin geliş süresini ölçün; drift ile gerçek kalite alarmını ayrı kanallarda yönetin.
- Veri yönetişimi
- Ham giriş yerine gerekli özetleri, maskeleme, erişim ve retention süresini kaydedin.
- Müdahale
- İnceleme, shadow model, canary, geri alma ve yeniden eğitim adımlarına sorumlu atayın.
Hesap ve uygulama örneği
Günde 100.000 tahmin üreten bir modelde saatlik pencere yaklaşık 4.167 örnek içerir. Gece trafiği 300'e düşüyorsa aynı eşik daha gürültülü olabilir. Minimum 2.000 örnek ve iki ardışık pencere koşulu, tek küçük pencere alarmını azaltabilir. Bu değerler evrensel değildir; geçmiş incident replay ile yanlış pozitif ve kaçırma oranı ölçülmelidir.
Kredi risk modelinde gelir özelliği PSI 0,22'ye çıkarken doğruluk etiketi 30 gün sonra geliyorsa model hemen yeniden eğitilmemelidir. Önce şema, para birimi, eksik değer ve kaynak değişikliği kontrol edilir. Shadow değerlendirme ve iş kuralı incelemesi yapılır. Gerçek etiket geldikçe AUC/kalibrasyon ve segment adaleti karşılaştırılır; drift alarmı tek başına karar otomasyonu değildir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Sağlayıcıdan bağımsız pencere özeti örneği
python monitor.py --model-version churn-42 --baseline validation-2026q3 \
--window 24h --min-samples 2000 --metrics jsd,psi,missing_rate
# Örnek politika
# warning: 2 ardışık pencere + yeterli örnek
# action: drift + doğrulanmış kalite/iş etkisi + değişiklik sahibi onayıHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Drift alarmı aniden bütün özelliklerde | Şema, birim, preprocessing sürümü veya veri kaynağı değişmiş olabilir. | Modelden önce veri sözleşmesi ve pipeline sürümünü baseline ile karşılaştırın. |
| Drift yüksek, model kalitesi sabit | Değişen özellik görev için önemsiz veya model robust olabilir. | Özellik önemini, segmentleri ve ground-truth metriğini birlikte inceleyin. |
| Kalite düşüyor, drift düşük | Concept drift, etiket sorunu veya izlenmeyen özellik etkili olabilir. | Tahmin/etiket eşleşmesini, kalibrasyonu ve izlenmeyen segmentleri araştırın. |
| Alarm yalnız düşük trafikte | Örnek hacmi küçük ve dağılım metriği kararsız olabilir. | Minimum örnek, güven aralığı ve pencere uzunluğunu yeniden kalibre edin. |
Kabul ve doğrulama kontrolleri
- Model, özellik şeması ve preprocessing sürümünü birlikte kaydedin.
- Baseline türünü ve yenileme kuralını belgeleyin.
- Minimum örnek ve ardışık pencere eşiğini geçmiş veride test edin.
- Drift, model kalite, latency, hata ve maliyet metriklerini ayırın.
- Etiket gecikmesi ve tahmin-label eşlemesini doğrulayın.
- Alarmdan canary/rollback kararına kadar sahip ve audit kaydı oluşturun.
İlgili kavramlar
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.