Production'da Gerçekten Çalışan ML Pipeline'ları Nasıl Kurulur?

Defalarca gördüğüm bir şey var: notebook'ta harika görünen bir model, production trafiğiyle buluştuğu anda dağılıyor. Umut verici bir prototiple güvenilir bir ML sistemi arasındaki mesafe gerçekten çok büyük — ve MLOps tam olarak bu boşluğu kapatmak için var. Model geliştirmeye ciddi bir mühendislik disipliniyle yaklaştığınızda, ilk deployment'tan çok sonra bile doğru, gözlemlenebilir ve tekrarlanabilir modeller elde ediyorsunuz.

ML Modelleri Production'da Neden Bozulur?

Geleneksel yazılımın aksine, ML sistemleri gerçek dünyadaki değişimlere aşırı duyarlı. Pandemi öncesi alışveriş verisiyle eğitilmiş bir öneri motoru düşünün — tüketici davranışı değiştiğinde alakasız öneriler vermeye başlıyor. Ya da bir dolandırıcılık tespit modeli: saldırganlar taktiklerini geliştirdikçe sessizce bozuluyor. İşin zor tarafı şu — bu hatalar neredeyse hiç stack trace olarak karşınıza çıkmaz. Bunun yerine, iş metrikleri düşene kadar kimsenin fark etmediği yavaş bir doğruluk kaybı yaşarsınız.

Temel nedenler iyi biliniyor. Training-serving skew, eğitim sırasında hesaplanan feature'ların inference zamanındakilerden ince farklarla ayrışmasıyla oluşuyor. Data drift, gelen verilerin istatistiksel dağılımının zamanla kayması demek. Concept drift ise input'larla hedef değişken arasındaki ilişkinin kendisinin değişmesi. Sistematik izleme ve otomasyon olmadan bu sorunlar arka planda sessizce birikiyor.

"Gerçek dünya ML sistemlerinin yalnızca küçük bir bölümü ML kodunun kendisinden oluşur. Gerekli çevreleyen altyapı devasa ve karmaşıktır." — Sculley ve ark., Hidden Technical Debt in Machine Learning Systems (NeurIPS 2015)

Sağlam bir MLOps stratejisi bu hata modlarının her biriyle feature yönetimi, otomatik eğitim pipeline'ları, model registry'ler, sürekli izleme ve ML'ye özel CI/CD üzerinden ilgilenir. Gelin her birini tek tek inceleyelim.

Feature Store Tasarımı

Feature store'u, feature hesaplama ve erişim için tek doğruluk kaynağınız olarak düşünün. Hem eğitim hem de inference için birebir aynı dönüşüm mantığının çalışmasını sağlayarak training-serving skew'u ortadan kaldırır. Pratikte iyi tasarlanmış bir feature store iki katmandan oluşur: eğitim sırasında geçmiş feature'lara erişmek için bir data warehouse (BigQuery veya Snowflake gibi) destekli offline store, ve gerçek zamanlı inference için düşük gecikmeli bir veritabanı (Redis veya DynamoDB gibi) destekli online store.

İyi Bir Feature Store Neye Benzer?

• Bildirimsel feature tanımları — Feature'larınızı kod olarak tanımlayın, Git'te versiyonlayın ve diğer yazılım parçaları gibi PR'larla gözden geçirin.
• Point-in-time doğruluğu — Offline store'unuz time-travel sorguları desteklemeli. Yoksa eğitim veri seti oluştururken data leakage yaşarsınız ve metrikleriniz sizi yanıltır.
• Materialization pipeline'ları — Batch ve streaming pipeline'lar, feature'ları bir takvime göre veya event'lere yanıt olarak hesaplayıp hem offline hem online store'ları otomatik doldurmalı.
• Şema zorunluluğu — Her feature'ın tanımlı bir tipi, beklenen aralığı ve null kısıtlaması olmalı. Veri kalitesi sorunlarını production'da değil, erken aşamada yakalamak istiyorsunuz.
• Keşif ve yeniden kullanım — Aranabilir bir katalog, organizasyondaki veri bilimcilerinin mevcut feature'ları sıfırdan yeniden yazmak yerine bulup kullanmasını sağlar.

Açık kaynak tarafında Feast ve Hopsworks güçlü seçenekler. Cloud provider'lar yönetilen alternatifler sunuyor — Vertex AI Feature Store ve Amazon SageMaker Feature Store gibi — operasyonel yükü azaltıyorlar ama vendor lock-in getiriyorlar. Tercih, ekibinizin olgunluğuna, ölçeğine ve multi-cloud ihtiyaçlarına bağlı.

Eğitim Pipeline'ını Otomatikleştirme

Manuel model eğitimi hatalara açık ve tekrarlanamaz. Production seviyesindeki ekipler her adımı otomatikleştiriyor — veri çıkarma ve doğrulamadan feature engineering'e, eğitimden değerlendirmeye, artifact depolamaya kadar — hepsi bir DAG (directed acyclic graph) olarak tanımlı. Apache Airflow, Prefect, Kubeflow Pipelines ve ZenML gibi orkestrasyon framework'leri bu DAG'ları kod olarak tanımlamanıza, takvime veya veri gelişine göre tetiklemenize ve başarısız adımları otomatik yeniden denemenize olanak tanıyor.

Pipeline'daki her adım ortam tekrarlanabilirliği için container'ize edilmeli. Kütüphane versiyonlarını sabitleyin, deterministik random seed'ler kullanın ve her hyperparameter'ı logla. Böylece geçmişteki herhangi bir deneyi tam olarak yeniden oluşturabilirsiniz.

Örnek: ZenML ile Training Pipeline

from zenml import pipeline, step
from zenml.integrations.mlflow.experiment_trackers import MLFlowExperimentTracker
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.metrics import f1_score
import pandas as pd

@step
def load_data() -> pd.DataFrame:
    """Feature store'dan eğitim verilerini yükle ve doğrula."""
    df = pd.read_parquet("s3://feature-store/fraud_features/latest/")
    assert df.shape[0] > 10_000, "Yetersiz eğitim örneği"
    assert df.isnull().sum().sum() == 0, "Null değerler tespit edildi"
    return df

@step
def train_model(df: pd.DataFrame) -> GradientBoostingClassifier:
    """İzlenen hiperparametrelerle gradient boosting sınıflandırıcı eğit."""
    X = df.drop(columns=["is_fraud"])
    y = df["is_fraud"]
    model = GradientBoostingClassifier(
        n_estimators=300,
        max_depth=6,
        learning_rate=0.05,
        subsample=0.8,
    )
    model.fit(X, y)
    return model

@step
def evaluate_model(model: GradientBoostingClassifier, df: pd.DataFrame) -> float:
    """Model performansını değerlendir ve minimum F1 eşiğinde kapıla."""
    X = df.drop(columns=["is_fraud"])
    y = df["is_fraud"]
    predictions = model.predict(X)
    score = f1_score(y, predictions)
    assert score >= 0.85, f"F1 skoru {score:.3f}, eşik değer 0.85'in altında"
    return score

@pipeline
def training_pipeline():
    df = load_data()
    model = train_model(df)
    evaluate_model(model, df)

Bu pipeline'ın doğru yaptığı şeylere dikkat edin: veri alımında doğrulama yapıyor, hyperparameter'ları açıkça belirtiyor ve düşük performanslı modellerin ilerlemesini engelleyen bir kalite kapısı içeriyor. MLflow gibi bir experiment tracker ile birleştirdiğinizde, her çalıştırma parametreleri, metrikleri ve artifact'larıyla birlikte loglanıyor — ekstra çaba harcamadan tam denetlenebilirlik.

Model Versiyonlama ve Registry

Model registry, eğitilmiş tüm modelleriniz için merkezi katalog görevi görüyor. Model artifact'larını, metadata'yı (eğitim veri seti versiyonu, hyperparameter'lar, değerlendirme metrikleri) ve yaşam döngüsü aşamasını (staging, production, archived) saklıyor. MLflow Model Registry ve Weights & Biases Registry pratikte iyi çalıştığını gördüğüm iki popüler seçenek.

Model Yaşam Döngüsü Aşamaları

1. Development — Aktif olarak deney yapıyorsunuz. Bu aşamada birden fazla aday versiyon olabilir.
2. Staging — Bir aday model otomatik değerlendirmeyi geçti ve entegrasyon testi veya shadow deployment sürecinde.
3. Production — Model canlı trafiğe hizmet veriyor. Herhangi bir anda her model adı için yalnızca bir versiyon bu aşamada olmalı.
4. Archived — Yerini başka bir modele bırakmış eski production modeli. Rollback ve denetim amacıyla saklıyorsunuz.

Bir modeli bir aşamadan diğerine taşımak hem otomatik kontrolleri (performans eşikleri, latency benchmark'ları, bias denetimleri) hem de yüksek riskli sistemlerde bir insan onay adımını gerektirmeli. Aslında bu, pull request review sürecinin aynısı — kimin neyi ne zaman onayladığına dair denetlenebilir bir iz bırakıyor.

İzleme: Data Drift ve Model Drift

Model deploy etmek bitiş çizgisi değil — yepyeni bir zorluklar serisinin başlangıcı. Production modelleri iki boyutta sürekli izleme gerektiriyor: data drift (input feature dağılımlarındaki değişimler) ve model drift (tahmin kalitesindeki bozulma).

Data Drift'i Yakalamak

Kolmogorov-Smirnov testi (sürekli feature'lar için) ve ki-kare testi (kategorik feature'lar için) gibi istatistiksel testlerle eğitim verisi ve son production input'ları arasındaki dağılım kaymalarını ölçebilirsiniz. Population Stability Index (PSI) de sık kullanılan bir metrik. Drift belirlediğiniz eşiği aştığında, izleme sistemi uyarı vermeli ve isteğe bağlı olarak retraining pipeline'ını başlatmalı.

import numpy as np
from scipy.stats import ks_2samp

def detect_drift(
    reference: np.ndarray,
    current: np.ndarray,
    threshold: float = 0.05,
) -> dict:
    """Kolmogorov-Smirnov testi kullanarak veri kaymasını tespit et.

    Test istatistiği, p-değeri ve kayma tespit edilip
    edilmediğini gösteren bir boolean içeren sözlük döndürür.
    """
    statistic, p_value = ks_2samp(reference, current)
    return {
        "statistic": round(statistic, 4),
        "p_value": round(p_value, 6),
        "drift_detected": p_value < threshold,
    }

# Örnek: eğitim ve üretim özellik dağılımlarını karşılaştır
training_feature = np.random.normal(loc=50, scale=10, size=5000)
production_feature = np.random.normal(loc=53, scale=12, size=5000)

result = detect_drift(training_feature, production_feature)
print(result)
# {'statistic': 0.0872, 'p_value': 0.000003, 'drift_detected': True}

Model Drift'i Yakalamak

Model drift'i tespit etmek daha zor çünkü ground truth label'lar genellikle gecikmeli geliyor. Bir dolandırıcılık tespit sisteminde gerçek etiket (dolandırıcılık mı meşru mu) haftalarca doğrulanmayabilir. Bu süreçte proxy metrikler kullanabilirsiniz — tahmin güven dağılımları, tahmin sınıfı oranları, feature importance kararlılığı — bunlar erken uyarı sinyalleri olarak işe yarıyor. Ground truth geldiğinde, son production verisine karşı offline değerlendirme retraining'in gerekip gerekmediğini gösteriyor.

Evidently AI, WhyLabs ve Arize gibi araçlar hem data hem model drift için hazır dashboard'lar sunuyor. Özel ihtiyaçlarınız varsa, Prometheus ve Grafana üzerine bir monitoring katmanı kurmak size maksimum esneklik veriyor.

ML İçin CI/CD

Geleneksel CI/CD pipeline'ları kod değişikliklerini production'a göndermeden önce unit test'ler, linting ve entegrasyon testleriyle doğrular. ML CI/CD bunu bir adım ileri taşıyor: veri doğrulama, model eğitimi, değerlendirme ve aşamalı rollout'lar ekliyor. Genellikle üç aşamaya varıyorsunuz: continuous integration (kod ve veri doğrulama), continuous training (yeni verilerle yeniden eğitim) ve continuous deployment (doğrulanmış modellerin serving altyapısına taşınması).

ML CI/CD Pipeline Aşamaları

1. Kod doğrulama — Feature engineering mantığı, veri dönüşümleri ve model serving kodu için linting, type checking ve unit test'ler.
2. Veri doğrulama — Gelen eğitim verisi üzerinde şema kontrolleri, dağılım testleri ve tamlık kontrolleri.
3. Model eğitimi — Kod değişiklikleri, veri güncellemeleri veya planlı bir takvim tarafından tetiklenen otomatik eğitim.
4. Model değerlendirme — Holdout set'lere karşı performans benchmark'ı, fairness denetimleri ve simüle edilmiş yük altında latency profiling.
5. Shadow deployment — Yeni model production trafiğini mevcut modelle paralel alır ama tahminleri serve edilmez, loglanır. Bu, kullanıcıları etkilemeden regresyonları yakalamanızı sağlar.
6. Canary release — Trafiğin küçük bir yüzdesini yeni modele yönlendirirsiniz. Temel metrikler stabil kalırsa, yeni model tüm istekleri karşılayana kadar trafiği kademeli olarak kaydırırsınız.
7. Deployment sonrası izleme — Drift, latency artışları ve hata oranı yükselmeleri için otomatik uyarılar ve bir şeyler ters giderse otomatik rollback.

GitHub Actions, GitLab CI ve Jenkins kod tarafındaki aşamaları yönetebilirken, Kubeflow, SageMaker Pipelines veya Vertex AI Pipelines gibi ML'ye özel platformlar eğitim ve deployment'ı üstleniyor. Asıl önemli olan, bu sistemleri öyle bağlamak ki tek bir Git commit'i veri doğrulamadan canary release'e kadar tüm pipeline'ı tetikleyebilsin.

Serving altyapınızı — Kubernetes cluster'ları, model endpoint'leri, monitoring dashboard'ları — Terraform ve Pulumi gibi infrastructure-as-code araçlarıyla yönetin. Ortamlarınız tekrarlanabilir ve versiyon kontrollü olduğunda, configuration drift'ten kaçınır ve disaster recovery'yi kolaylaştırırsınız.

Önemli Çıkarımlar

• Feature store'lar training-serving skew'u ortadan kaldırır ve ekiplerin feature'ları modeller arasında yeniden kullanmasını sağlar.
• Veri doğrulama, kalite kapıları ve experiment tracking içeren otomatik eğitim pipeline'ları tekrarlanabilirlik sağlar ve sessiz regresyonları yakalar.
• Model registry'ler yaşam döngüsü yönetimi, denetlenebilirlik ve development'tan production'a net bir yol sunar.
• Hem data drift hem model drift için sürekli izleme şart. Toplu metrikler tek başına yetmez.
• ML CI/CD, geleneksel DevOps'u veri doğrulama, continuous training, shadow deployment'lar ve canary release'lerle genişletir.
• Her bileşen — feature'lar, pipeline'lar, altyapı, modeller — kod tabanlı workflow'larla versiyonlanmalı, test edilmeli ve gözden geçirilmeli.

Güvenilir ML pipeline'ları kurmak, makine öğrenmesini bir yazılım mühendisliği disiplini olarak ele almakla başlıyor. Araçlar hızla olgunlaşıyor ama ilkeler aynı kalıyor: her şeyi otomatikleştir, durmadan izle, tüm artifact'ları versiyonla ve terfileri nesnel kriterlere bağla. MLOps altyapısına erken yatırım yapan ekipler, production'daki model sayısı bir avuçtan yüzlere çıktıkça avantajlarını katlayarak artırıyor.