MLOps Araçları: Model Yönetimi, İzleme ve CI/CD Kılavuzu

MLOps, makine öğrenmesi (ML) projelerini “notebook’tan üretime” taşırken ortaya çıkan operasyonel işleri disipline eden pratiklerin bütünüdür. Birçok ekipte asıl zorluk model eğitmekten çok; hangi modelin nerede çalıştığını bilmek, güncellemeleri güvenle dağıtmak ve üretimde performansı izlemek gibi yaşam döngüsü adımlarıdır. Bu yazı; model yönetimi (model registry), üretimde izleme (monitoring/observability) ve ML’e uygun CI/CD süreçlerini, genel bir kitle için uygulanabilir bir çerçevede özetler.

Not: Araç seçimi, kurumun güvenlik politikaları, veri hassasiyeti, ekip olgunluğu ve bütçe gibi faktörlere bağlıdır. Buradaki örnekler, karar vermeyi kolaylaştıran bir iskelet sunar; üretime alınacak her adımda kuruluşunuzun güvenlik ve uyum gereksinimlerini ayrıca değerlendirin.

MLOps araçları “yığın” olarak nasıl düşünülür?

MLOps’u tek bir ürün gibi değil, birbirini tamamlayan katmanlar gibi düşünmek daha sağlıklıdır. Tipik bir yığın şu soruları yanıtlar:

• Deney takibi: Hangi veri, hangi parametre, hangi kod ile hangi sonucu üretti?
• Model registry: “Onaylı” modeller nerede, hangi sürüm üretimde, kim ne zaman terfi ettirdi?
• Orkestrasyon/pipeline: Veri hazırlama, eğitim, değerlendirme adımları tekrarlanabilir mi?
• Dağıtım (serving): Model nasıl yayınlanıyor? Batch mi, gerçek zamanlı mı?
• İzleme: Üretimde doğruluk/kalite, gecikme, hata oranı, drift gibi sinyaller izleniyor mu?
• CI/CD: Kod ve pipeline değişiklikleri otomatik testlerden geçip kontrollü şekilde yayına çıkıyor mu?

Aşağıdaki tablo, bu katmanları pratik olarak eşleştirmenize yardımcı olur:

Model yönetimi: Model registry neden temel bir parçadır?

Üretimde en sık yaşanan sorunlardan biri “hangi model?” sorusudur: Hangi sürüm nerede çalışıyor, hangi veriyle eğitildi, kim onayladı, geri dönüş (rollback) mümkün mü? Model registry, bu soruların çoğunu sistematik hale getirmeyi hedefler.

MLflow Model Registry’nin sağladığı temel kavramlar

MLflow dokümantasyonu; registry’nin model sürümleme ve aşama (stage) yönetimi gibi mekanizmaları desteklediğini açıklar. Örneğin bir modelin sürümleri arasında geçiş yapmak, belirli bir sürümü “Staging” veya “Production” benzeri aşamalara terfi ettirmek, yaygın bir yönetim yaklaşımıdır. Ayrıntılar için resmi dokümana bakabilirsiniz: https://mlflow.org/docs/2.5.0/model-registry.html.

Pratikte bir registry’nin size kazandırdıkları:

• Tekil kaynak (single source of truth): “Onaylı model” ve sürümü tek bir yerde tanımlı olur.
• Terfi akışı: Değerlendirme sonrası staging’e, sonra production’a geçiş gibi kontrollü adımlar.
• Denetlenebilirlik: Kimin ne zaman hangi sürümü terfi ettirdiğini takip etmek kolaylaşır.
• Rollback kolaylığı: Sorun çıktığında bir önceki “production” sürümüne dönmek daha az risklidir.

Model registry ile birlikte mutlaka tasarlayın

• Sürümleme kuralı: Sürüm numarası otomatik mi artacak, yoksa semantik bir etiketleme mi olacak?
• Terfi kriterleri: Hangi metrik eşiği geçilmeden “production”a çıkılmaz? (Örn. regresyon testleri, gecikme sınırı, doğrulama setinde minimum performans.)
• Artefact standardı: Model dosyası, bağımlılıklar, eğitim konfigürasyonu ve değerlendirme raporu birlikte saklanıyor mu?
• Erişim kontrolü: Kim “production” terfisi yapabilir? En az ayrıcalık (least privilege) yaklaşımını hedefleyin.

Pipeline ve orkestrasyon: Tekrarlanabilir ML iş akışları

Bir modeli eğitmek tek seferlik bir iş değildir. Veri güncellenir, özellikler değişir, yeni testler eklenir. Bu yüzden eğitim ve değerlendirme adımlarını “pipeline” olarak düşünmek, hem tekrar üretilebilirlik hem de ekip içi iş birliği açısından önemlidir.

Kubeflow Pipelines kavramı: adım adım, yeniden çalıştırılabilir süreç

Kubeflow Pipelines dokümantasyonu, pipeline’ların ML iş akışlarındaki adımları (veri hazırlama, eğitim, değerlendirme gibi) bileşenler halinde tanımlayıp çalıştırmayı hedeflediğini ve Kubernetes üzerinde orkestrasyon yaklaşımını anlatarak çerçeve sunar: https://www.kubeflow.org/docs/components/pipelines/concepts/pipeline/.

Pipeline yaklaşımı size şunları kazandırır:

• Tekrarlanabilir koşullar: Aynı adımlar, aynı girdilerle yeniden çalıştırılabilir.
• Görünürlük: Hangi adımın nerede başarısız olduğunu izlemek kolaylaşır.
• Ölçekleme: Bazı adımlar (ör. eğitim) daha fazla kaynak ister; orkestratör bunu yönetebilir.

Pipeline tasarımında pratik öneriler

• Adımları küçük tutun: Veri hazırlama, eğitim, değerlendirme, paketleme gibi adımları net ayırın.
• Girdi/çıktıyı sözleşmeye bağlayın: Her adımın beklediği formatı dokümante edin.
• Deterministiklik hedefleyin: Rastgelelik (seed) ve bağımlılık sürümleri kontrol altında olsun.
• Artifact’ları saklayın: Eğitim çıktıları, metrik raporları, model dosyaları geri izlenebilir olmalı.

Üretimde izleme: Sadece “up/down” değil, model sağlığı

Modeli dağıtmak işin yarısıdır. Üretimde veri dağılımları değişebilir, kullanıcı davranışı farklılaşabilir, gecikme artabilir veya kalite düşebilir. Bu nedenle izleme, MLOps’un en kritik parçalarından biridir.

İzleme neyi kapsar?

• Hizmet metrikleri: Gecikme (latency), hata oranı, throughput, kaynak kullanımı.
• Veri metrikleri: Girdi dağılımlarında kayma (data drift), eksik değerler, anormallikler.
• Model metrikleri: Tahmin dağılımları, zaman içindeki stabilite, etiket gecikmeli ise geriye dönük kalite takibi.
• Dilim (slice) analizi: Belirli segmentlerde performans düşüşünü yakalamak.

Observability platformları ne sağlar?

Arize gibi izleme/observability sağlayıcıları; drift tespiti, dilim bazlı analiz ve (özellikle dil modelleri için) ek kalite sinyalleri gibi konuları öne çıkarır. Bu, üretimde görünürlük sağlar; ancak bunun bir ürün sağlayıcısı perspektifi olduğunu ve kurum ihtiyaçlarına göre değerlendirilmesi gerektiğini not edin: https://arize.com/model-monitoring/.

Benzer şekilde, herhangi bir izleme aracını seçmeden önce güvenlik, uyum, maliyet ve gecikme hedeflerinize göre kısa bir pilot ve ölçüm planı ile doğrulama yapmak, daha tarafsız ve sürdürülebilir bir seçim sağlar.

LLM (büyük dil modeli) tabanlı uygulamalarda izleme genellikle daha zor olabilir; çünkü çıktı kalitesi her zaman tek bir sayıya indirgenemez. Bu alandaki uygulamalar hızla gelişiyor. Bu nedenle, izleme yaklaşımınızı önce riske göre şekillendirmek genellikle daha güvenli bir yoldur.

İzleme için başlangıç kontrol listesi

• Temel SLO/SLI’lar: Gecikme, hata oranı, zaman aşımı, maliyet gibi hedefler.
• Drift sinyalleri: En kritik 5-10 özelliği seçip izlemeye başlayın.
• Alarm yorgunluğunu azaltın: Her sapma için alarm üretmek yerine, eşik ve süre koşulları ekleyin.
• Geri besleme döngüsü: Yanlış tahminleri etiketleme/inceleme sürecine bağlayın.
• Olay kaydı: Bir alarm olduğunda “hangi model sürümü”nün etkilediğini otomatik yazın.

ML’e uygun CI/CD: test, kayıt ve dağıtımın otomasyonu

Geleneksel yazılım CI/CD yaklaşımı ML için iyi bir başlangıçtır; ancak ML projelerinde veri ve model artefact’ları da “değişen” unsurlardır. Bu yüzden sadece birim test değil, veri doğrulama ve model değerlendirme adımları da sürece eklenir.

GitHub Actions yaklaşımı (örnek akış)

Microsoft’un GitHub Actions ile MLOps CI/CD akışlarını ele alan içeriği, otomasyonla test/dağıtım adımlarının nasıl kurgulanabileceğine dair fikir verir: https://learn.microsoft.com/en-us/shows/ai-show/mlops-feature-dive-cicd-with-github-actions.

Genel bir ML CI/CD hattı şu aşamalardan oluşabilir:

1. CI (kod değişince):
   • Kod kalite kontrolleri ve birim testler
   • Pipeline tanımı için “dry run” veya şema kontrolü
   • Veri sözleşmesi kontrolleri (ör. beklenen kolonlar, tipler)
2. Eğitim ve değerlendirme (kontrollü):
   • Deney takibi ve metrik raporu üretimi
   • Minimum kabul kriterlerini geçen modelleri işaretleme
3. Model registry’ye kayıt:
   • Model artefact + metrikler + eğitim konfigürasyonu ile kayıt
   • Varsa staging aşamasına terfi
4. CD (dağıtım):
   • Staging ortamında entegrasyon testleri ve yük testleri
   • Onay sonrası production’a terfi ve dağıtım
   • İzleme ve geri dönüş planının (rollback) doğrulanması

ML CI/CD’de sık kaçırılan noktalar

• Model testleri sadece doğruluk değildir: Gecikme, bellek, giriş aralığı, kararlılık (stability) gibi kontroller de önemlidir.
• Veri değişimi “kırıcı” olabilir: Şema değişince pipeline kırılabilir; veri sözleşmeleri faydalıdır.
• Gizli bilgiler: API anahtarları ve erişim token’ları için güvenli saklama ve rotasyon süreçleri gerekir.

Örnek başlangıç mimarisi (hafif yığın)

Yeni başlayan ekipler için hedef; en baştan “her şey”i kurmak yerine, temel parçaları bir araya getirip iteratif olgunlaştırmaktır. Hafif bir başlangıç yaklaşımı şu mantıkla ilerleyebilir:

• Deney ve model yönetimi: MLflow ile deney takibi + MLflow Model Registry ile model sürümleme ve aşama yönetimi (kaynak).
• CI: GitHub Actions ile otomatik test ve otomatik kayıt adımları (kaynak).
• İzleme: Temel servis metrikleri + drift sinyalleri; ihtiyaç büyüdükçe ürünleşmiş izleme/observability yaklaşımlarını değerlendirme (kaynak).

Daha ileri bir aşamada; birden fazla takım, çoklu ortam, Kubernetes tabanlı çalışma ve standartlaştırılmış pipeline ihtiyaçları arttığında Kubeflow Pipelines gibi orkestrasyon çözümleri değerlendirilebilir (kaynak).

Araç seçimi için karar rehberi (pratik sorular)

1) Model yaşam döngüsü ne kadar karmaşık?

• Basit: Tek model, seyrek güncelleme → registry + temel CI + temel izleme yeterli olabilir.
• Karmaşık: Çok model, sık güncelleme, çok ekip → onay akışları, pipeline standartları ve ayrıntılı gözlemlenebilirlik daha kritik hale gelir.

2) Dağıtım tipi nedir?

• Batch skorlama: Zamanlanmış işler, veri gecikmesi toleransı.
• Gerçek zamanlı: Gecikme hedefleri, otomatik ölçekleme, daha güçlü izleme gereksinimi.

3) Etiket (ground truth) ne zaman geliyor?

• Hemen: Canlı kalite ölçümü daha mümkün.
• Gecikmeli: Tahmin dağılımları, drift ve proxy metrikler (kaliteye dolaylı sinyal) daha önemli olabilir.

4) Kurum içi kısıtlar neler?

• Veri yerleşimi, erişim politikaları, tedarikçi onay süreçleri
• Kubernetes kullanımı veya yönetilen servis tercihi
• Maliyet görünürlüğü ve kaynak sınırları

Uygulama planı: 30-60-90 gün yol haritası (öneri)

İlk 30 gün: Temeller

• Model envanteri çıkarın: nerede hangi model var?
• Deney takibi + model registry standardını belirleyin (sürümleme, terfi kriterleri).
• CI’da minimum test setini kurun (birim test + veri şema kontrolü).

60 gün: Otomasyon ve görünürlük

• Pipeline adımlarını netleştirin (eğitim, değerlendirme, paketleme).
• Registry’ye otomatik kayıt ve staging terfisini CI/CD’ye bağlayın.
• Üretimde temel metrik panolarını (latency, hata oranı) ve drift izlemeyi devreye alın.

90 gün: Güvenli ölçekleme

• Onay/inceleme süreçlerini tanımlayın (kim production terfisi yapar?).
• Staging ortamında entegrasyon ve performans testlerini olgunlaştırın.
• Alarm stratejisini iyileştirin; olay sonrası inceleme (post-incident review) alışkanlığı kazandırın.

Sık yapılan hatalar ve nasıl önlenir?

Model registry’yi sadece “depolama” gibi görmek

Registry; sürüm, aşama, onay ve izlenebilirlik için süreç tasarımıyla anlam kazanır. Terfi kriterleri ve erişim rolleri net değilse, registry beklenen faydayı vermez.

İzlemeyi “sonra ekleriz” diye ertelemek

En azından servis metrikleri ve basit drift sinyalleriyle başlamak, üretimde sürprizleri azaltır. İzleme; hatayı bulmayı, geri dönüşü ve öğrenmeyi hızlandırır.

CI/CD’de veriyi unutmak

ML sistemlerinde veri değişiklikleri çoğu zaman kod değişikliğinden daha etkili olabilir. Veri şeması, temel istatistik kontrolleri ve pipeline sözleşmeleri, kırılmaları azaltır.

Sonuç

MLOps araçlarını seçerken amaç “en çok özelliğe sahip yığın” kurmak değil, modelin yaşam döngüsünü güvenle yönetmek olmalıdır. Başlangıç için; model registry ile sürüm/aşama yönetimini (MLflow), pipeline düşüncesiyle tekrarlanabilir eğitim ve değerlendirmeyi (Kubeflow Pipelines yaklaşımı) ve ML’e uygun CI/CD otomasyonunu (GitHub Actions örnekleri) bir araya getirmek sağlam bir temel sunar. Üretim izleme ise bu temeli sürdürülebilir kılar: modelin performansını, veri değişimlerini ve operasyonel sinyalleri izleyerek kontrollü iyileştirme döngüsü oluşturursunuz.

Bir sonraki adım olarak, kendi kullanım senaryonuz için “minimum kabul kriterleri” ve “izleme metrikleri”ni yazılı hale getirip küçük bir pilot akış üzerinde denemeniz, araç seçiminden daha hızlı öğrenme sağlayacaktır.

Kaynaklar / Further reading

• https://mlflow.org/docs/2.5.0/model-registry.html
• https://www.kubeflow.org/docs/components/pipelines/concepts/pipeline/
• https://learn.microsoft.com/en-us/shows/ai-show/mlops-feature-dive-cicd-with-github-actions
• https://arize.com/model-monitoring/