Databricks 2025 State of Data + AI raporu, model registry kullanan kurumların oranının son 12 ayda %63 arttığını, ancak ekiplerin sadece %41’inin tam lineage izlenebilirliği sağladığını gösteriyor. McKinsey 2025 AI Risk araştırmasında audit/regulator talebine 48 saat içinde cevap verebilen ekip oranı sadece %29.
ML Model Registry 2026: Production ML’in Hesap Verebilirlik Katmanı
Model registry, ML modellerini versiyonlayan, lineage izleyen, stage promotion (staging → production → archived) yöneten ve metadata saklayan platform. 2020-2022’de “nice-to-have” olarak görülen registry, 2024-2025’te audit ve regülasyon zorlamasıyla “must-have” haline geldi. Gartner 2025 AI TRiSM raporunda model registry “Critical Capability” listesinde; MLflow, Weights & Biases (W&B) ve Neptune üç ana platform olarak öne çıkıyor. MLflow GitHub’da 18K+ star, W&B 200K+ aktif kullanıcı, Neptune 1.500+ kurumsal müşteri. Konuyla ilişkili olarak MLflow vs Weights and Biases vs Neptune: Deney Takip Karşılaştırması rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak MLflow vs Weights & Biases vs ClearML 2026 Karsilastirma rehberimiz detaylı incelemeyi içerir.
Müşterilerimde en pahalı vaka: 6 ay önce production’a giden modelin hangi training data ile eğitildiği bilinmiyor, audit talebine cevap verilemiyor, $400K düzenleyici ceza geliyor. Registry olsaydı bu kaçınılırdı. 2026’da AI Act ve benzer regülasyonlar registry’yi zorunlu kıldıkça bu vakalar artıyor.
Üç Platformun Mimari Karşılaştırması
MLflow Databricks tarafından open-source olarak yönetiliyor; Databricks platformu içinde managed olarak da var. W&B SaaS-first, deneyim odaklı, deep learning use case’lerde dominant. Neptune SaaS + on-prem hibrit deployment, sınırsız experiment saklama ile öne çıkıyor. Üçü de model versioning, experiment tracking, model registry ve deployment capability sunuyor ancak mental model’leri farklı.
| Özellik | MLflow | Weights & Biases | Neptune |
|---|---|---|---|
| Deployment | Open-source + SaaS | SaaS-first | SaaS + on-prem |
| Sweet spot | Geniş ML + Spark | Deep learning + research | Experiment-heavy |
| Lineage | Sınırlı (manuel) | Otomatik | Otomatik + zengin |
| Deployment integration | Native (MLflow models) | Sınırlı | Sınırlı (3rd party) |
| Yıllık başlangıç maliyet | $0 (self-host) | $50K-200K | $30K-150K |
Model Versioning ve Tagging Stratejisi
Model versioning sadece “v1, v2, v3” numaralandırması değil; semantic versioning, stage tag’leri (none, staging, production, archived) ve metadata içeriyor. MLflow 2.0+ ile stage’ler “aliases” kavramına evrildi; multiple alias bir modele atanabiliyor. W&B “model registry” özelliği ile aynı pattern’i sunuyor; Neptune “model version” + custom tag yapısı destekliyor.
- Production tag her zaman tek model’e: prod traffic’i yönlendiren tek source of truth
- Staging tag birden fazla model’e: A/B test veya shadow traffic için
- Champion + challenger pattern: ana model + alternatif modeller paralel
- Archived tag deprecated modeller için; metadata korunur ama yeni inference yapılmaz
Drift detection ile entegrasyon için model drift detection rehberimize bakabilirsiniz.
Lineage İzlenebilirliği: Data → Feature → Model → Endpoint
Audit talebi geldiğinde “bu model nasıl eğitildi” sorusuna cevap verebilmek için tam lineage gerekiyor: training dataset (hash + versiyon), feature engineering pipeline, hyperparameter, training kod (git commit), model artifact, evaluation metric, deployment endpoint. Bu 7 katman birbirine bağlı olarak izlenmeli. MLflow lineage’i manuel kaydetmek gerekiyor; W&B ve Neptune daha otomatik. MLflow resmi dokümantasyonunda lineage pattern’leri detaylı.
Stage Promotion ve CI/CD Entegrasyonu
Model promotion pipeline’ı kritik: development → staging → production geçişlerinde otomatik gate’ler. Tipik pattern: training pipeline yeni model üretir, registry’ye yükler, “candidate” tag verir, validation pipeline candidate model’i evaluate eder, threshold tutuyorsa “staging” alias, shadow deployment 24 saat production traffic gözlemler, shadow performance OK ise “production” alias değiştirilir, eski model “archived”.
| Stage | Aksiyon | Otomatik Gate | Manuel Onay |
|---|---|---|---|
| Candidate | Yeni model train edildi | Training metric > threshold | Hayır |
| Staging | Aday validation geçti | Test set metric, fairness | Hayır |
| Shadow | Prod traffic shadow | 24h online metric | Hayır |
| Production | Prod traffic yönlendir | Drift baseline | Evet (ilk kez) |
| Archived | Eski model archive | Otomatik | Hayır |
Sektörel Use Case ve Platform Eşleştirmesi
Spark ve büyük veri ML iş yükleri MLflow native entegrasyonu nedeniyle Databricks ekosisteminde dominant. Deep learning + computer vision + NLP araştırma odaklı ekipler W&B’yi tercih ediyor; PyTorch Lightning ve Hugging Face native entegre. Geniş experiment + uzun saklama + custom dashboard ihtiyacı olan ekipler Neptune’a yöneliyor. McKinsey 2025 verisine göre fintech ve healthcare gibi yüksek-regülasyon sektörlerinde registry adoption oranı %78, e-ticaret/SaaS’ta %52.
Kurumsal ML Registry Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Experiment tracking yapılıyor ama registry promotion eksik; production model versionsuz
- Training data versioning unutuluyor; “hangi data ile eğitildi” sorusuna cevap yok
- Hyperparameter ve random seed kayıt edilmiyor; reproducibility sıfır
- Shadow deployment pattern kurulmuyor; canary direkt %100 trafik çekiyor, rollback geç
- Archive politikası yok; 200+ deprecated model registry’de birikiyor, search yavaşlıyor
- Audit log gerektiren sektörlerde access log yapılmıyor
Sonuç
Model registry 2026’da production ML için zorunlu altyapı; audit, regülasyon ve reproducibility için kaçınılmaz. Doğru platform seçimi ekibin profiline bağlı: Databricks/Spark ağırlıklı ekosistem için MLflow, deep learning + research için W&B, sınırsız experiment + custom dashboard için Neptune. Karar öncesi mutlaka model sayısı + experiment hacmi + audit gereksinimi + budget’ı netleştirin. Registry sadece “yer” değil; promotion pipeline, lineage izleme ve CI/CD entegrasyonu birlikte tasarlanmalı.
Sıkça Sorulan Sorular
MLflow self-hosted ne kadar maintenance gerektirir?
Tipik 0.5-1 FTE devops/ML engineer. PostgreSQL backend + S3 artifact store + tracking server yönetimi gerekiyor. Databricks Managed MLflow kullanılırsa self-host yükü ortadan kalkıyor. Self-host vs SaaS karar’ı genelde compliance ve maliyet kesişiminde.
W&B’yi MLflow’a tercih sebebi ne?
Deep learning use case’lerinde W&B daha ergonomik: training curve visualization, hyperparameter sweep, GPU monitoring integration güçlü. PyTorch Lightning, Hugging Face Transformers gibi kütüphaneler W&B ile native entegre. MLflow daha geniş ML coverage ama deep learning UX’i daha az olgun.
Model versioning için git commit hash yeterli mi?
Hayır. Git commit kod versiyonunu kaydediyor ama training data versiyonu, hyperparameter ve random seed’i kaydetmiyor. Tam reproducibility için 4 katman gerekli: git commit + data hash + hyperparameter + seed. Registry bu 4 katmanı bir arada saklıyor.
Production model değiştirildiğinde nasıl alert vermeli?
İki katmanlı: deployment pipeline Slack/Teams notification ve drift detection platform yeni baseline mark. Production alias değişimi kritik event; on-call team haberdar olmalı çünkü prediction distribution değişebilir.
Archive edilen modeller ne kadar süre saklanmalı?
Regülasyon sektörlerinde 7+ yıl (Basel III, HIPAA gibi). Genel kurumsal use case’lerde 2-3 yıl yeterli. Storage maliyeti düşük olduğu için fazla archive etmek genelde sorun değil; ancak audit performance için search index düzenli temizlenmeli.
Ömer ÖNAL
Mayıs 23, 2026Model registry konusunda ekiplerin yaptığı en büyük hata: ‘experiment tracking yeterli’ diyerek registry’yi atlamak. Müşterilerimde gördüğüm en pahalı vaka: 6 ay önce production’a giden modelin hangi training data ile eğitildiği bilinmiyor, audit talebine cevap verilemiyor. MLflow open-source kontrolü, W&B deneyim, Neptune sade UI ve sınırsız experiment saklama getirir. Doğru seçim takım kültürüne bağlı. — Ömer ÖNAL