MLOps: Pilotta Çalışan Yapay Zeka Modelini Sahada Ayakta Tutmak

MLOps, bir makine öğrenmesi modelini laboratuvardan üretime taşıyan ve orada çalışır durumda tutan mühendislik disiplinidir. Yazılım geliştirmedeki DevOps'un karşılığıdır; farkı, kodun yanında veri ve model de sürümlenmesi ve izlenmesidir.

Kısa cevap

• Bir modelin üretimdeki ömrü sabit değildir: veri değişir, model eskir. Buna sapma (drift) denir.
• Model doğrudan canlıya alınmaz; önce gölge modda çalışır, kararları karşılaştırılır.
• Her sürüm, eğitildiği veri seti ve metrikleriyle birlikte kaydedilir — geri alma (rollback) bunsuz mümkün değildir.
• İzlenecek üç şey vardır: veri kalitesi, model performansı, iş sonucu.
• Kapalı çevrim: sahadaki düzeltmeler etiketli veri olarak geri toplanmazsa model zamanla körelir.

Pilot ile üretim arasındaki fark

	Pilot / laboratuvar	Üretim
Veri	Temiz, seçilmiş	Gürültülü, eksik, değişken
Gecikme	Önemli değil	Çevrim süresinin altında olmalı
Hata maliyeti	Rapor satırı	Hurda, duruş, müşteri şikâyeti
Çalışma süresi	Demo süresince	7/24, internet kesilse bile
Sorumluluk	Veri bilimci	Operatör, bakım, kalite — hep birlikte

Bu farklar nedeniyle "modelin doğruluğu %98" cümlesi tek başına bir şey ifade etmez. Doğru soru şudur: hangi koşullarda, hangi veriyle, ne kadar süreyle %98?

Dağıtım stratejileri

1. Gölge (shadow) dağıtım: Model canlı veriyle çalışır ama kararı uygulanmaz; operatörün/mevcut sistemin kararıyla karşılaştırılır. Kalite kontrol projelerinde standart başlangıçtır.
2. Kademeli (canary) dağıtım: Önce tek hat veya tek vardiya; sorun çıkmazsa kapsam genişletilir.
3. A/B karşılaştırma: Eski ve yeni sürüm aynı anda çalışır, sonuçlar iş metriğiyle (fire, duruş) kıyaslanır.
4. İnsan onaylı (human-in-the-loop): Model önerir, operatör onaylar. Kritik kararlarda uzun süre bu modda kalınabilir.

İzlenmesi gereken üç katman

• Veri: Eksik değer oranı, beklenmeyen aralık, sensör kaybı. Girdi bozulduğunda model sessizce yanlış üretir.
• Model: Giriş dağılımındaki kayma (data drift) ve tahmin-gerçek ilişkisindeki değişim (concept drift); p95 çıkarım süresi.
• İş sonucu: Asıl ölçüt budur — fire oranı düştü mü, plansız duruş azaldı mı, stok günü iyileşti mi?

Bir model teknik olarak "iyi" görünüp iş sonucunu hiç değiştirmiyorsa, sorun modelde değil, kararın sürece bağlanmamasındadır.

Yeniden eğitim: ne zaman ve neyle?

Takvime göre değil, tetikleyiciye göre eğitin:

• Sapma göstergesi eşiği aştığında (ör. PSI > 0,2).
• Yeni ürün, yeni hammadde tedarikçisi veya yeni ekipman devreye girdiğinde.
• Yeterli miktarda yeni etiketli örnek biriktiğinde (ör. 1.000+ doğrulanmış karar).
• İş metriğinde kalıcı bozulma gözlendiğinde.

Eğitim verisi nereden gelir? Operatörün düzelttiği kararlar. "Bu parça aslında sağlamdı" geri bildirimi tek tuşla kaydedilebiliyorsa, model her ay biraz daha iyileşir; kaydedilemiyorsa altı ay sonra kimse sonuçlara güvenmez.

Uçta mı, bulutta mı?

Kriter	Uç (edge)	Bulut
Gecikme	20–50 ms	100–500 ms+
İnternet kesintisi	Etkilenmez	Üretim durur
Maliyet	Donanım yatırımı	Kullanım bazlı
Model güncelleme	Dağıtım gerektirir	Anında
Uygun senaryo	Kalite kontrol, anlık karar	Tahminleme, planlama, raporlama

Yaygın ve doğru desen hibrittir: çıkarım uçta, eğitim ve izleme bulutta.

Sık sorulan sorular

Küçük bir tesiste MLOps gerekir mi?

Ağır bir platform gerekmez ama üç şey şarttır: model sürüm kaydı, performans izleme ve geri alma yeteneği. Bunlar basit araçlarla da kurulabilir.

Model ne sıklıkla yeniden eğitilmeli?

Tipik olarak yılda 3–6 kez, ama takvime değil tetikleyicilere bağlı olmalıdır. Üretim karması sık değişen tesislerde daha sık gerekebilir.

Modelin kararını nasıl açıklarız?

Görüntü işlemede ısı haritası (hangi bölge karara yol açtı), tablo verisinde özellik önem skorları kullanılır. Operatör güveni için açıklanabilirlik, doğruluk kadar önemlidir.

Veri bilimci istihdam etmeli miyiz?

İlk aşamada şart değil. Kritik olan, sahadaki veriyi doğru toplayan ve geri bildirimi kaydeden süreçtir; modelleme kısmı dışarıdan alınabilir, veri disiplini alınamaz.

Model kötüleşirse ne olur?

Geri alma planı önceden yazılır: önceki sürüme dönüş, gerekirse kural tabanlı yedek mantık. Hiçbir model, yedeksiz üretime alınmamalıdır.

MongStack AI model sürümleme, gölge dağıtım ve sapma izlemeyi tek platformda toplar; MongScada uçta çalışan çıkarım için saha verisini besler, MongFlow İş Akışı ise model kararlarını iş emri ve kalite kaydına bağlar. Kendi verinizle bir fizibilite çalışması için bize ulaşın.