Notebook'ta %92 doğruluk gösteren bir model, üretime çıkmadığı sürece kurum için değer üretmez. Data science ekiplerinin en büyük sıkıntısı tam burada: modelden API'ye, API'den sürdürülebilir operasyona giden yol. MLOps bu yolu haritalayan disiplindir.
MLOps'un Beş Katmanı
- Feature Store: Aynı feature'ın eğitimde ve üretimde farklı hesaplanması (training-serving skew) modellerin en yaygın ölüm sebebi. Feast, Databricks Feature Store gibi araçlar bu tutarlılığı garanti eder.
- Model Registry: Hangi model versiyonu hangi dataset ile, hangi hiperparametre ile, hangi performansla eğitildi? MLflow, W&B, Azure ML registry bu envanteri tutar.
- CI/CD for Models: Kod gibi, model de test edilebilir ve deployable olmalı. Unit test (veri şeması), integration test (pipeline), canary deployment (trafik bölünmesi).
- Monitoring: Üretimde model kalitesi düşebilir (data drift, concept drift). Prediction distribution, feature distribution ve business KPI anomalileri için izleme şart.
- Retraining Pipeline: Model tek seferlik bir eser değil; feedback loop ile sürekli güncellenen bir varlık. Otomatik retraining'in koşulları önceden tanımlanmalıdır (performans düşünce mi, periyodik mi, yeni data ile mi?).
Olgunluk Seviyeleri
MLOps olgunluğu Google'un 3 aşamalı modeline göre değerlendirilir:
- Level 0: Manuel model deploy. Data scientist notebook'u üretime kopyalar. Küçük takımlar için yeterli ama ölçeklenmez.
- Level 1: Otomatik training pipeline, manuel deploy.
- Level 2: CI/CD ile otomatik training + deploy + monitoring. Feedback loop ile retraining tetiklenir.
Türkiye kurumlarının büyük çoğunluğu Level 0-1 arasında. Level 2'ye ulaşmak 9-12 aylık odaklı bir yatırım gerektirir.
Araç Seçimleri
- Tracking: MLflow (açık kaynak, yaygın), W&B (ekip UX'i güçlü), Azure ML (Azure-native).
- Pipeline: Kubeflow (Kubernetes-native), Airflow (data + ML hibrit), Prefect (Python-native).
- Serving: Seldon, BentoML, KServe, Triton (GPU-ağır).
- Monitoring: Arize, WhyLabs, Evidently (açık kaynak).
Önerilen Aşamalı Yaklaşım
MLOps benimsetmesi tipik olarak şu sırayla ilerler: önce 1-2 pilot modeli MLflow gibi bir registry'ye taşımak, ardından Azure DevOps veya GitHub Actions ile CI/CD, sonra Evidently veya Arize ile drift monitoring, zaman içinde model katalogunun büyütülmesi. 9 aylık süreç data science ekibinin üretkenliğini 3 katına çıkardı ve model operasyon maliyetini %60 azalttı.
