Veri Mühendisliğinden MLOps'a Geçiş: AI-Ready Veri Altyapısı [2026]

Veri Mühendisliğinden Yapay Zekaya: Şirketler Neden Başarısız Oluyor?

Şirketler, milyonlarca dolar makine öğrenmesi projeleri başlatır. Harika modeller eğitilir, laboratuvarda 95% doğruluk elde edilir. Ancak, production'a geçtiği an, model hızla bozulur. 3 ay sonra, model performansı 60%'ye düşmüş, tahminler hatalı. Proje başarısız sayılır.

Sorduğunuz sorun: Model mi, yoksa verisi mi kötü? Cevap, genellikle veridir. Veri mühendisliği temel olmadığında, hiçbir ML projesi başarılı olamaz.

Bu rehber, veri mühendisliğini ML/AI ile nasıl entegre edeceğinizi, ve production ML sistemleri nasıl kuracağınızı açıklıyor.

Veri Mühendisliği ve Data Pipeline rehberimiz, temel bilgiyi içerir. Bu rehim, ML bakış açısını ekler.

Neden Veri Mühendisliği, ML'nin Temeli?

Machine Learning modeli, üç unsura ihtiyaç duyar:

1. Algoritma: Modelin yapısı (Linear Regression, Neural Network, vb.)
2. Hiperparametreler: Modelin ayarları (learning rate, depth, vb.)
3. Veriler: Eğitim ve test verilerinin kalitesi ve miktarı

ML mühendisleri, genellikle 1 ve 2'ye odaklanır. Model architecture optimize edilir, hiperparameter tuning yapılır. Ancak, veri eksik veya kalitesiz olsa, tüm optimization boşa gider.

Veri mühendisliğinin gerçek değeri, burada ortaya çıkar:

• Verinin Alınması: Eğitim için kullanılacak verinin, tamamen ve doğru şekilde bir yerde toplanması
• Verinin Hazırlanması: Verinin, modelin "anlaması" gereken biçime dönüştürülmesi (feature engineering)
• Verinin Yönetimi: Verinin, zamanla nasıl değiştiğini takip etmek (data drift detection)
• Verinin Versiyonlanması: Modelin eğitildiği veriyi, sonra yeniden üretebildiğini sağlamak

Feature Store: ML için Veri Merkezi

Feature store, ML projelerinde veri yönetiminin merkezi yapısıdır.

Feature Store Nedir?

Feature store, model eğitimi ve inference sırasında kullanılacak özellikleri (feature'ları) merkezi bir yerde yönetir.

Örnek: Dolandırıcılık tespit modeli eğitilirken, şu feature'lara ihtiyaç duyar:

Müşteri 123 için: son 30 gündeki işlem sayısı 45, ortalama işlem tutarı 250 dolar, kayıt tarihinden bu yana geçen gün sayısı 365, hesap ülkesi Türkiye, son başarısız giriş denemesi sayısı 2.

Bu feature'lar, müşteri veritabanından, işlem history'sinden, coğrafi veritabanlarından gelmektedir. Feature store, bu kaynakları birleştirir ve merkezi yerde saklar.

Feature Store Mimarisi

Tipik bir feature store, iki deposundan oluşur:

1. Offline Store (Eğitim için)

• Tarihsel veri içerir
• Gigabayt-terabayt ölçüğünde
• Yavaş erişim (saat başına)
• Örnek: Snowflake tablosu, S3 Parquet dosyaları

2. Online Store (Inference için)

• Son güncel veri içerir
• Milisaniye erişim süresine ihtiyaç duyar
• Kilobyte-megabayt ölçüğünde
• Örnek: Redis cache, DynamoDB

Akış:

Müşteri işlemi gerçekleştiğinde, feature pipeline tetikleniyor. Bu pipeline, gerekli feature'ları hesaplıyor. Hesaplanan feature'lar, offline store'a (eğitim için) ve online store'a (real-time tahminler için) yazılıyor. Offline store, tarihsel tüm feature'ları içeriyor. Online store, en güncel feature'ları hızlı erişim için tutuyor.

Feature Store Araçları

Feast (Databricks/Uber Sponsorlu)

Açık kaynaklı, en popüler seçenek.

• Feature definition (YAML)
• Offline + Online store yönetimi
• Feature registry (hangi feature'lar mevcut)
• Maliyet: Free (açık kaynak)

Tecton

Kurumsal, fully-managed hizmet.

• Feast'ten daha kolay kullanım
• Skalabilite ve reliability
• Maliyet: 3.000-10.000$/ay

Vertex AI Feature Store (Google)

Google Cloud'un native feature store'u.

• BigQuery ile entegre
• Yönetilen hizmet
• Maliyet: Feature sayısına göre (1.000 feature = 500$/ay)

AWS SageMaker Feature Store

Amazon'un çözümü.

• On-Demand ve Batch seçenekleri
• Maliyet: Benzer Google'a

Seçim Kriterleri:

• Kurumsal gereklilik? → Tecton, Vertex AI
• Cost-sensitive? → Feast (açık kaynak)
• Google Cloud'da mı? → Vertex AI
• AWS'de mi? → SageMaker Feature Store

ML Pipeline Tasarımı

Bir production ML sistemi, veri pipeline'ı kadar karmaşıktır.

Eğitim Pipeline (Training Pipeline)

Eğitim pipeline'ı, tarihsel verilerden başlar. Veriler, feature engineering aşamasında dönüştürülür (dbt ve Python ile). Feature store'a yazılır (offline bölüm, eğitim için). Model, bu feature'lar üzerinde eğitilir (XGBoost, Neural Network, vb.). Eğitilmiş model, test set üzerinde doğrulanır. Başarılı model, model registry'ye (DVC, MLflow) kaydedilir. Model versioning ile, tüm versiyonlar yönetilir.

Önemli Noktalar:

1. Train-Test Ayrımı: Geçmişteki veri, train'e girer. Sonraki veriler test'e girer. Temporal leakage (gelecek verinin eğitime girmesi) önlenmeli.

2. Feature Importance: Hangi feature'lar modele katkı yapıyor? SHAP values ile anlaşılabilir.

3. Model Evaluation: Sadece accuracy değil, precision, recall, F1-score da kontrol edilmeli.

4. Hiperparametre Ayarlama: Izgara arama veya Bayesian optimizasyonu yöntemleriyle en uygun hiperparametreler belirlenir. Bu aşama modelin doğruluk oranını önemli ölçüde artırır.

Inference Pipeline (Tahmin Pipeline)

Yeni bir müşteri işlemi gerçekleştiğinde, inference pipeline çalışır. İşlem bilgileri, online store'dan gerekli feature'ları sorgulamak için kullanılır. Feature'lar real-time olarak çekilir. Bu feature'lar, model prediction API'sine gönderilir. Model, bu feature'lara dayanarak tahmin yapar (örneğin, 0.95 güvenirlik ile dolandırı olasılığı). Tahmin sonucuna göre, sistem aksiyon alır (işlemi bloke etme, ek doğrulama istemek, vb.).

Önemli Noktalar:

1. Latency: Tahmin, milisaniye içinde yapılmalı. Saniyesi olursa, kullanıcı deneyimi bozulur.

2. Feature Consistency: Eğitimde kullanılan feature'lar, inference'da da aynı olmalı. Feature skew (sapma) produksiyonda sorun yaratır.

3. Versioning: Farklı modeller, farklı versiyonları production'da koşabilir. A/B test yapılabilir.

Data Drift ve Model Monitoring

Production'da model, zamanla kötüleşebilir. Sebebi, "data drift"tir.

Data Drift Nedir?

Eğitim zamanında, müşteriler saat 9-17 arası işlem yapıyorlardı. Ama şimdi, home office nedeniyle, saat 22:00'de işlem yapıyorlar. Saatlik dağılım değişti. Model, bu yeni pattern'i görmedi. Tahminleri hatalı hale gelir.

Drift Türleri:

1. Covariate Shift: Input feature'ların dağılımı değişti (yukarıdaki örnek)
2. Label Shift: Output'un dağılımı değişti
3. Concept Drift: Aralarındaki ilişki değişti

Monitoring Stratejileri

1. Offline Monitoring

Tahminlerin doğruluğunu, zamanla ölçmek. Eğer doğruluk 90%'dan 75%'ye düştüyse, problem var.

Ama sorun: Gerçek label'ler, gecikmeyle gelir. Dolandırıcılık modeli, işlem anında tahmin eder, ama işlemin dolandırı olup olmadığını, 1 hafta sonra biliriz.

2. Online Monitoring (Realtime)

Input feature'ların dağılımını izleme. Saatlik dağılım, anormal bir şekilde değişti mi? Feature values, expected range'in dışına çıktı mı?

Araçlar:

• Great Expectations (data profiling)
• Whylabs (model monitoring)
• Arize (ML monitoring)
• Evidently (drift detection)

3. Shadow Mode

Yeni model, production'da çalışsa da, tahminler kaydedilir, eski modelle karşılaştırılır. Fark çok büyükse, yeni model deploy edilmez.

Model Registry ve Versioning

Hiç bir modeli, sonsuza kadar production'da tutmazsınız. Zamanla, yeni veriler gelir, model retrain edilir.

Model Registry

Tüm modellerin, merkezi bir yerde tutulduğu repository.

Unsurlar:

• Model artifacts (ağırlıklar, pickle, vb.)
• Eğitim için kullanılan veriler
• Performans metrikleri
• Feature'lar listesi
• Training script'i
• Deployment meta-data

Araçlar:

• MLflow: Open source, basit
• Databricks Model Registry: MLflow'un kurumsal versiyonu
• DVC (Data Version Control): Git benzeri, veri ve model versioning
• Hugging Face Model Hub: NLP modelleri için

Versioning Stratejileri

Semantic Versioning: 1.0.0 versiyondan, 1.0.1'e geçiş, model iyileştirmesi anlamına gelir.

A/B Testing: Yeni model %10 traffic alır, eski model %90 alır. Yeni model iyiyse, %100'e çıkarılır.

Canary Deployment: Yeni model, önce 1% traffic alır. Sorun yoksa, 10%, 50%, 100%'e çıkarılır.

Data Engineer vs. ML Engineer: Roller ve İşbirliği

Veri mühendisliği ve ML mühendisliği, farklı roller, ama yakın işbirliği.

Data Engineer

Sorumluluk:

• Feature pipeline'ları tasarlamak ve uygulamak
• Feature store kurma ve yönetme
• Veri kalitesi ve versioning
• Eğitim veri setlerini hazırlamak

İlişki: ML Engineer tarafından isteklere göre

• "Bu customer için şu feature'ları hesapla"
• "Geçmiş 2 yıllık veriyi training set olarak hazırla"

ML Engineer

Sorumluluk:

• Model tasarımı ve eğitimi
• Hyperparameter tuning
• Model evaluation
• Inference pipeline

İlişki: Data Engineer tarafından isteklere göre

• "Bu öznitelikler eksik veya yanlış"
• "Veri sapması görülüyor, yeniden eğitim gerekli"

Başarılı İşbirliği İçin

1. Shared Tools: DVC, MLflow gibi, ortak araçlar kullanılmalı
2. Shared Responsibility: Feature quality hem DE hem ME sorumluluğu
3. Documentation: Feature definitions, model requirements açık şekilde dokümante edilmeli
4. Testing: Hem veri testleri hem model testleri otomatik yapılmalı

AI-Ready Veri Altyapısı: Checklist

Production ML sistemi kurmadan, aşağıdaki kontrolleri yapın:

Veri Yönetimi

• [ ] Eğitim verileri, merkezi bir yerde toplanmış mı?
• [ ] Verinin tarihi (historical) kısmı, 1-2 yıl öncesinden itibaren saklanıyor mu?
• [ ] Veri kalitesi kontrolleri, otomatik yapılıyor mu?
• [ ] Veri lineage (kaynak) belli mi?

Feature Yönetimi

• [ ] Feature store implement edilmiş mi?
• [ ] Feature definitions dokümante edilmiş mi?
• [ ] Feature engineering pipeline'ları otomatik mi?
• [ ] Offline + Online store tutarlı mı?

Model Yönetimi

• [ ] Model registry kullanılıyor mu?
• [ ] Model versioning stratejisi var mı?
• [ ] Model artifacts saklanıyor mu?
• [ ] Training scripts reproduce edilebilir mi?

Monitoring

• [ ] Data drift detection ayarlanmış mı?
• [ ] Model performance monitoring var mı?
• [ ] Alert ve remediation prosesi tanımlanmış mı?
• [ ] Logging ve tracing tam mı?

Operasyon

• [ ] Retraining pipeline otomatik mi?
• [ ] A/B testing infrastructure var mı?
• [ ] Rollback prosesi tanımlanmış mı?
• [ ] On-call rotation var mı?

Bu maddelerin tamamına "evet" cevabı verilebiliyorsa, AI-ready altyapınız vardır.

MLOps Maturity Seviyerleri

Seviye 0: Notebook

Data scientist'ler, Jupyter notebook'larda kod yazıyorlar. Veri, hard-coded path'lerden geliyor. Model, notebook'da eğitiliyor. Production yok.

Risk: Model asla production'a geçmez.

Seviye 1: Scripted Training

Training script'ler yazılmış, scheduling aracıyla (Airflow) çalışıyor. Ama feature engineering hala manual, versioning yok.

Risk: Veri drift'e karşı hazırlıklı değilsiniz.

Seviye 2: Automated Pipeline

Training + inference pipeline'ları, otomatik çalışıyor. Feature store var, monitoring var.

Risk: Cross-functional işbirliği zayıf.

Seviye 3: Closed-Loop

Monitoring otomatik, drift tespit edilince retraining tetikleniyor. Makine öğrenmesi mühendisleri, modelleri üretim ortamında sürdürüyor.

Risk: Yok, sağlamlı bir sistem.

Smart Maple ile ML/AI Altyapısı Kurulması

Smart Maple, veri mühendisliğini ML/AI ile entegre eden danışmanlık sunmaktadır.

Hizmetlerimiz:

• ML maturity assessment
• Feature store seçimi ve kurulması (Feast, Tecton, Vertex AI)
• Training pipeline tasarımı ve implementasyonu
• ML monitoring ve drift detection kurulması
• MLflow + DVC setup
• Data engineer vs. ML engineer roller tanımlanması
• A/B testing infrastructure kurulması
• Continuous retraining pipeline'ları

Projelerimizde:

• Production ML sisteminiz ilk 3 ay içinde kurulur
• Veri engineer ve ML engineer'lar arası işbirliği sağlanır
• Monitoring ve alerting otomatikleştirilir
• Model performansı, sürekli iyileştirilir

AI-ready veri altyapısı konusunda danışmanlık almak için, Smart Maple ile iletişime geçebilirsiniz.