Kazanimlar:
- ML'in kod-veri-model üçlüsüne bağlı özel zorluklarını tanıyabilme ve modeli iş ihtiyacına göre online veya batch olarak paketleyip sunabilme
- Kademeli ve geri alınabilir dağıtım desenlerini (gölge, kanarya, A/B, rollback) uygulayabilme ve her dağıtıma test edilmiş geri alma planı ekleyebilme
- Değerlendirme eşiği kontrollü CI/CD ve model registry ile üretime alınan modelin veri-kod-metrik bağını izlenebilir tutabilme
Bir modelin defterde %95 doğruluk alması hikayenin ancak yarısıdır. Diğer yarısı — çoğu zaman zor olanı — o modeli gerçek kullanıcılara güvenilir, ölçeklenebilir ve bakımı yapılabilir biçimde ulaştırmaktır. MLOps (Machine Learning Operations: ML modellerini üretime alma, işletme ve sürdürme disiplini), yazılım mühendisliğinin DevOps pratiklerini ML'in kendine özgü zorluklarıyla birleştirir. Bu ünitede modeli üretime taşımanın adımlarını ve yapay zekanın bu süreçte nasıl yardımcı olduğunu işliyoruz.
ML neden normal yazılımdan farklı
Sıradan yazılımda davranış koddadır; kod değişmezse davranış değişmez. ML'de davranış hem koda hem veriye hem de modele bağlıdır. Bu üç boyut, MLOps'un ekstra zorluklarını doğurur:
- Veri kayması (data drift): Üretimdeki veri, eğitimdeki veriden zamanla uzaklaşır; model eskir.
- Üç şeyi sürümlemek gerekir: Kod, veri ve model — üçü birden.
- Sessiz başarısızlık: Bir model çökmeden, hata vermeden, sadece yanlış tahminler üreterek başarısız olabilir. Bunu yakalamak izleme (monitoring) ister.
Bu yüzden "çalışan model" ile "üretime hazır model" arasında büyük fark vardır.
Model paketleme ve sunma
Modeli üretime almanın ilk adımı onu paketlemektir (packaging): model dosyası, gerekli kütüphaneler, ön işleme kodu ve sürüm bilgisi bir arada, tekrar üretilebilir bir bütün olarak. Konteynerleştirme (containerization, ör. Docker: uygulamayı tüm bağımlılıklarıyla izole bir kutuya koyma) burada standarttır; "benim makinemde çalışıyordu" sorununu ortadan kaldırır.
Modeli sunmanın (serving) iki temel deseni:
- Çevrimiçi/gerçek zamanlı (online): Model bir API'nin arkasında durur, gelen her istek için anlık tahmin döner. Düşük gecikme (latency) kritiktir.
- Toplu (batch): Model periyodik olarak büyük veri kümelerini işler (ör. gece tüm müşteriler için skor üretir). Gecikme önemsiz, verimlilik önemlidir.
Hangisinin doğru olduğu iş ihtiyacına bağlıdır: anlık öneri online, aylık risk skoru batch olabilir.
Ipucu: "Gerçek zamanlı" varsayılan değil, bir maliyettir. Sonuç saatler içinde kullanılacaksa batch çok daha ucuz ve basittir. Gerçekten anlık cevap gerekiyor mu, önce onu sorun.
Güvenli dağıtım stratejileri
Yeni bir modeli doğrudan tüm trafiğe açmak risklidir; yanlışsa herkes etkilenir. Güvenli dağıtım desenleri:
- Gölge dağıtım (shadow deployment): Yeni model üretim trafiğini alır ama tahminleri kullanıcıya gösterilmez, sadece loglanır. Eski modelle karşılaştırıp gerçek veride güvenli mi diye bakılır.
- Kanarya dağıtım (canary): Yeni model önce trafiğin küçük bir yüzdesine (ör. %5) açılır; sorun yoksa kademeli artırılır.
- A/B testi: İki model gerçek kullanıcıya paralel sunulur ve iş metrikleri (dönüşüm, tıklama) karşılaştırılır.
- Geri alma (rollback): Yeni model kötü çıkarsa hızla eski sürüme dönebilme. Her dağıtımın bir geri alma planı olmalı.
Dikkat: Geri alma planı olmayan bir dağıtım tamamlanmış sayılmaz. Yeni model üretimde beklenmedik davrandığında, dakikalar içinde eski sürüme dönebilmeniz kullanıcıyı korur. Bunu dağıtımdan önce test edin.
Zayıf yaklaşım / Güçlü yaklaşım
Zayıf: "Model testte iyiydi, canlıya aldık, herkese açtık."
Güçlü: "Modeli konteynerledik, sürüm etiketledik. Önce gölge modda 3 gün üretim trafiğiyle koşturduk, eski modelle tahminleri karşılaştırdık — sapma kabul edilebilirdi. Sonra %5 kanarya ile açtık, iş metriklerini ve gecikmeyi izledik. Sorun çıkmayınca kademeli %100'e çıkardık. Geri alma komutunu önceden test etmiştik."
Fark: güçlü yaklaşım kademeli, ölçülü ve geri alınabilir. Risk her adımda sınırlı tutulur.
CI/CD ve otomasyon
CI/CD (Sürekli Entegrasyon / Sürekli Dağıtım: kod değişikliklerini otomatik test edip yayınlama hattı), ML'de sadece kodu değil, veri ve model adımlarını da kapsar. İyi bir ML CI/CD hattı: kod değişince testleri çalıştırır, veri doğrulamasını yapar, modeli yeniden eğitir (gerekirse), değerlendirme eşiklerini kontrol eder ve ancak eşikler tutarsa dağıtımı ilerletir. "Eğitim otomatik, dağıtım eşiğe bağlı" ilkesi, kötü modelin sessizce üretime sızmasını engeller.
Yapay zeka bu hatları kurarken çok yardımcıdır: yapılandırma dosyası (YAML) taslakları, test senaryoları, dağıtım betikleri yazar. Ama dağıtım eşiklerini (hangi metrik ne değeri geçerse yayınlanır) ve geri alma politikasını siz belirlersiniz; bunlar iş riski kararlarıdır.
Reproducibility altyapısı
Üretimdeki bir modelin davranışını yeniden üretebilmek için model kaydı (model registry: hangi modelin hangi veri ve kodla eğitildiğini, hangi metrikleri aldığını tutan kayıt) şarttır. Her üretim modeli için şunlar izlenebilir olmalı: eğitim veri sürümü, kod sürümü (git commit), hiperparametreler, değerlendirme skorları ve dağıtım tarihi. Bir sorun çıktığında "bu tahmini hangi model, hangi veriyle üretti" sorusuna dakikalar içinde yanıt verebilmelisiniz. Bunu 11. ünitede derinleştireceğiz.
Üç mini vaka
Vaka 1 - Gölge dağıtımın yakaladığı sorun. Bir öneri modeli testte eskisini geçmişti. Gölge modda üretim trafiğiyle koşturulunca, belirli bir kullanıcı segmentinde (yeni kullanıcılar) çok kötü öneriler ürettiği görüldü — test verisi bu segmenti yeterince temsil etmiyordu. Model kullanıcıya hiç gösterilmeden düzeltildi. Doğrudan açılsaydı yeni kullanıcı deneyimi bozulacaktı.
Vaka 2 - Geri alınamayan dağıtım. Bir ekip yeni bir fiyatlandırma modelini tüm trafiğe açtı, geri alma planı yoktu. Model beklenmedik biçimde bazı ürünleri çok ucuza fiyatladı. Eski sürüme dönmek saatler sürdü çünkü süreç hazır değildi. Ciddi gelir kaybı yaşandı. Sonrasında her dağıtıma zorunlu geri alma testi eklendi.
Vaka 3 - Sessiz veri kayması. Bir dolandırıcılık modeli aylarca sorunsuz göründü, hata vermedi. Ama dolandırıcıların taktikleri değişmişti (data drift) ve modelin recall'u sessizce düşmüştü. Kimse fark etmedi çünkü izleme yoktu. Bir tahmin dağılımı izleme paneli kurulunca kayma erken görülür oldu. İzlemeyi 8. ünitede işleyeceğiz.
Kopyalanabilir şablonlar
Bu model için bir dağıtım planı taslağı yaz.Model: [ne yapıyor], kullanım: [online mı batch mı?]İçermeli:1) Paketleme (konteyner, sürümleme)2) Kademeli dağıtım stratejisi (gölge/kanarya/A-B) ve neden3) İzlenecek metrikler (iş + teknik + gecikme)4) Geri alma planı ve nasıl test edileceği5) Dağıtım eşikleri (hangi metrik ne değeri geçmeli)
Bu ML CI/CD hattını denetle:1) Veri doğrulaması hatta var mı?2) Değerlendirme eşiği tutmadan dağıtım ilerleyebiliyor mu (ilerlememeli)?3) Geri alma otomatik mi?4) Model registry'de veri+kod+metrik izleniyor mu?Hat yapılandırması: [config]
Bu model için online mı batch mı sunum uygun, karar vermeme yardım et.Sonuç ne kadar sürede kullanılacak: [anlık / dakika / saat / gün]Beklenen istek hacmi: [sayı]Gecikme kısıtı var mı: [ms]Maliyet ve karmaşıklık açısından hangisini neden önerirsin?
Bu model için geri alma (rollback) prosedürü yaz.- Kötü performansı hangi metrik/eşik tetikler?- Eski sürüme dönüş adımları neler?- Dönüş ne kadar sürmeli (hedef)?- Bu prosedürü üretim öncesi nasıl test ederim?
Sunum deseni tablosu
Kriter
Online (gerçek zamanlı)
Batch (toplu)
Gecikme
Kritik (ms)
Önemsiz
Kullanım
Anlık cevap gerekli
Periyodik skor
Maliyet
Yüksek
Düşük
Karmaşıklık
Yüksek
Düşük
Örnek
Canlı öneri, dolandırıcılık
Aylık risk skoru
Sık yapılan hatalar
- Geri alma planı olmadan dağıtmak. Yanlış model tüm kullanıcıyı vurur.
- Doğrudan %100 trafiğe açmak. Kademeli dağıtımla riski sınırlayın.
- İzleme kurmamak. Model sessizce, hata vermeden yanlış üretir.
- Gereksiz gerçek zamanlı sunum. Batch yeterken maliyet ve karmaşıklık şişer.
- Model-veri-kod sürümlerini bağlamamak. Sorunu yeniden üretemezsiniz.
- Dağıtım eşiği olmadan otomatik yayın. Kötü model sessizce sızar.
Ozetle
Modeli üretime taşımak, eğitmekten farklı ve çoğu zaman daha zor bir mühendislik işidir. ML, kod-veri-model üçlüsüne bağlı olduğu için ekstra disiplin ister: paketleme ve sürümleme, iş ihtiyacına uygun sunum deseni (online/batch), kademeli ve geri alınabilir dağıtım, eşik kontrollü CI/CD ve model kaydı. Yapay zeka bu altyapının kodunu ve yapılandırmasını üretmede güçlü bir yardımcıdır; ama dağıtım eşikleri, geri alma politikası ve risk kararları sizindir. Geri alma planı olmayan dağıtım tamamlanmamıştır.
Uygulama gorevi
Bir modelini konteynerle (Docker) ve sürüm etiketle. Online mı batch mı sunacağına iş ihtiyacına göre karar verip gerekçeni yaz. Bir kademeli dağıtım planı (gölge veya kanarya) ve test edilmiş bir geri alma prosedürü belgele. Model registry'de veri sürümü, kod commit'i ve değerlendirme skorlarını kaydettiğinden emin ol.
Kontrol listesi
- [ ] Model paketlendi ve sürümlendi (konteyner + etiket).
- [ ] Sunum deseni (online/batch) iş ihtiyacına göre seçildi.
- [ ] Kademeli dağıtım stratejisi (gölge/kanarya) uygulandı.
- [ ] Geri alma prosedürü yazıldı ve test edildi.
- [ ] CI/CD, değerlendirme eşiği tutmadan dağıtımı ilerletmiyor.
- [ ] Model registry veri+kod+metrik bağlantısını tutuyor.