Üretim Ortamında Sessiz Çöküşleri Engellemek: 2026'da Kurumsal B2B Sistemler İçin Uçtan Uca MLOps ve CI/CD/CT Mimarisi

Üretim Ortamında Sessiz Çöküşleri Engellemek: 2026'da Kurumsal B2B Sistemler İçin Uçtan Uca MLOps Mimarisi

Kurumsal B2B projelerinde makine öğrenimi modellerinin laboratuvar ortamından çıkıp üretim (production) ortamına alınması buzdağının sadece görünen kısmıdır. 2026'nın MLOps (Machine Learning Operations) pratikleri, geleneksel yazılım geliştirme döngülerinin ML sistemleri için yeterli olmadığını açıkça kanıtladı. Yazılım dünyasında kod statiktir; ancak ML sistemlerinde veri yaşar, değişir ve modelleri zamanla sessizce bozar.

Bu makalede, modern bir MLOps hattının nasıl tasarlanması gerektiğini, geleneksel CI/CD'nin neden yetersiz kaldığını ve mimariye "CT" (Continuous Training) aşamasının entegrasyonunu mimari ve matematiksel boyutlarıyla inceleyeceğiz.

Problem: Geleneksel CI/CD Neden ML İçin Yetersiz?

Geleneksel DevOps süreçlerinde CI (Sürekli Entegrasyon) ve CD (Sürekli Dağıtım) kodun test edilip güvenle canlıya alınmasını sağlar. Ancak makine öğreniminde, kodun kusursuz çalışması modelin doğru sonuçlar üreteceği anlamına gelmez.

Özellikle uçak motorlarının sensör verilerini kullanarak arıza tahmini yapan (örneğin C-MAPSS veri seti tabanlı) kestirimci bakım algoritmaları veya kurumsal VDI (Sanal Masaüstü Altyapısı) ortamlarındaki logları analiz ederek anomali tespiti yapan (örneğin Qwen2.5-7B gibi fine-tune edilmiş LLM'lerin kullanıldığı) AIOps komuta merkezleri gibi kritik sistemleri ele alalım. Bu tür sistemlerde sensör gürültüsü, yeni donanım mimarileri veya güncellenen işletim sistemi ajanları, girdi verisinin doğasını değiştirir. Model kodunda hiçbir hata olmamasına rağmen sistemin başarı oranı hızla düşer.

Matematiksel Temel: Veri Kayması (Data Drift) ve Kavram Kayması (Concept Drift)

ML modelleri, eğitim verisinin dağılımı P
train
​

(X,Y) ile üretim ortamındaki verinin dağılımı P
prod
​

(X,Y)'nin aynı olduğu varsayımı üzerine kurulur.

Veri Kayması (Covariate Shift): Girdi özelliklerinin (features) istatistiksel dağılımı değişir, ancak çıktı ilişkisi aynı kalır. P
train
​

(X)

=P
prod
​

(X) ve P(Y∣X) sabittir.

Kavram Kayması (Concept Drift): Girdi aynı kalsa bile beklenen hedef değişkenin tanımı değişir. P
train
​

(Y∣X)

=P
prod
​

(Y∣X).

Modern bir MLOps Pipeline'ı, bu kaymaları istatistiksel olarak ölçmelidir. Dağılımlar arasındaki farkı sürekli izlemek için genellikle Kullback-Leibler (KL) Iraksaması (Divergence) veya Jensen-Shannon (JS) Iraksaması kullanılır.

İki olasılık dağılımı P (orijinal eğitim verisi) ve Q (canlı veri akışı) arasındaki KL ıraksaması şu şekilde hesaplanır:

D
KL
​

(P∣∣Q)=
x∈X
∑
​

P(x)log(
Q(x)
P(x)
​

)

Eğer ∫D
KL
​

değeri belirlenen bir ϵ eşiğini aşarsa, sistem otomatik olarak "Continuous Training (CT)" hattını tetiklemelidir.

Çözüm: CI / CD / CT Mimarisi

2026 standartlarında ölçeklenebilir bir kurumsal MLOps mimarisi şu üç ana hattan oluşur:

Kod snippet'i
graph TD
A[Veri Kaynağı / Feature Store] --> B(CI: Continuous Integration)
B --> C{Model Eğitimi ve Test}
C -->|Başarılı| D(CD: Continuous Deployment)
D --> E[Model Registry / Production]
E --> F(Monitoring & Drift Detection)
F -->|D_KL > Eşik Değeri| G[CT: Continuous Training]
G --> B

1. Continuous Integration (CI) - Veri ve Kod Testi

Sadece kod repoları değil, veri şemaları da test edilir. Yeni bir özellik veya hiperparametre seti Git'e pushlandığında;

Veri tiplerinin ve null oranlarının (Schema Validation) kontrolü yapılır.

Geliştirilen yeni model, Feature Store'dan alınan test verisi üzerinde baseline (temel) model ile karşılaştırılır (Shadow Testing).

1. Continuous Deployment (CD) - Güvenli Dağıtım

B2B sistemlerde kesinti kabul edilemez. CD hattı modeli doğrudan prod ortamına yazmak yerine Canary Release veya Blue-Green Deployment stratejilerini kullanır.
Model API'leri (örneğin gRPC ile sunulan servisler) kademeli olarak trafiğe açılır. Özellikle AIOps projelerinde LLM inference süreleri kritik olduğundan, latency metrikleri CD hattında bir geçiş kapısı (gate) olarak konumlandırılır.

1. Continuous Training (CT) - Otomatik Yeniden Eğitim

İşte ML sistemlerini yazılımdan ayıran nokta burasıdır. Bir drift tespit edildiğinde pipeline;

Yeni verileri etiketler ve temizler.

Mevcut modeli (veya LLM için LoRA ağırlıklarını) güncellenmiş veri seti üzerinde yeniden eğitir.

A/B testi uygulayarak yeni modelin eskisine göre iyileşme sağlayıp sağlamadığını doğrular.

Aşağıda, bir veri kayması eşik aşıldığında CT sürecini tetikleyen örnek bir otomasyon betiği (Python & MLflow konseptli) yer almaktadır:

Python
import numpy as np
from scipy.stats import entropy
import mlflow

def calculate_kl_divergence(p_train, q_prod):
# KL Divergence hesaplaması
return entropy(p_train, q_prod)

def monitor_and_trigger_ct(p_train_dist, current_prod_dist, threshold=0.15):
kl_score = calculate_kl_divergence(p_train_dist, current_prod_dist)
print(f"Güncel Drift Skoru (KL): {kl_score:.4f}")

if kl_score > threshold:
    print("Uyarı: Kritik Veri Kayması tespit edildi! CT Pipeline'ı başlatılıyor...")
    trigger_training_pipeline(run_id="model_v2_retrain")
else:
    print("Sistem stabil. Drift eşik değerinin altında.")

def trigger_training_pipeline(run_id):
# CI/CD orchestrator'a (örn. ZenML, Kubeflow) API çağrısı
# request.post("https://mlops-orchestrator.internal/api/v1/retrain", json={"run_id": run_id})
pass

Sonuç

AIOps Command Center yapıları veya kompleks sanallaştırma loglarını analiz eden ürünler gibi kurumsal çözümler geliştiriyorsanız, statik modeller sisteminizin sonu olacaktır. 2026 yılında başarılı bir yapay zeka ürünü geliştirmek; iyi bir model mimarisi kurmaktan ziyade, o modelin çökmesini engelleyecek otonom CI/CD/CT veri hatlarını tasarlamaktan geçmektedir.