DevOps ve MLOps: Yazılım Teslimatından Model Yaşam Döngüsüne

Ortak zemin: otomasyon, ölçüm ve iş birliği

Microsoft DevOps'u, geliştirme (Dev) ile operasyonu (Ops) birleştirerek uygulamanın planlama, geliştirme, teslim ve işletim aşamalarında insanları, süreçleri ve teknolojiyi bir araya getiren yaklaşım olarak tanımlar. DevOps, daha önce birbirinden kopuk çalışan geliştirme, BT operasyonu, kalite mühendisliği ve güvenlik rolleri arasında eşgüdüm kurar. Temel uygulamaları sürekli entegrasyon ve sürekli teslimat (CI/CD), sürüm kontrolü, kod olarak altyapı, yapılandırma yönetimi ve sürekli izlemedir.

Google Cloud'un mimari rehberi MLOps'u, makine öğrenmesi sistemi geliştirme (Dev) ile makine öğrenmesi sistemi işletimini (Ops) birleştirmeyi amaçlayan bir mühendislik kültürü ve uygulaması olarak tanımlar. MLOps, otomasyon ve izleme gibi DevOps ilkelerini makine öğrenmesi yaşam döngüsünün tüm adımlarına uygular.

Yani MLOps DevOps'un yerine geçmez, onun üzerine kurulur. Kod hâlâ sürüm kontrolünde tutulur, testten geçer ve otomatik hatlarla dağıtılır. Fark, makine öğrenmesi sistemlerinde koda ek olarak veri ve modelin de değişen, sürümlenmesi ve test edilmesi gereken bileşenler olmasıdır.

Temel farklar ölçüt ölçüt

• Değişen bileşen: DevOps / uygulama kodu ve altyapı tanımları. MLOps / kod, veri, özellikler (feature) ve eğitilmiş model.
• Geliştirme doğası: DevOps / gereksinimden koda görece öngörülebilir ilerleme. MLOps / deneysel; farklı özellikler, algoritmalar ve parametreler denenir, ne denendiğini izlemek ve sonuçları yeniden üretmek zordur.
• Test: DevOps / birim, entegrasyon ve uçtan uca testler. MLOps / bunlara ek olarak veri doğrulama, eğitilmiş modelin kalite değerlendirmesi ve model doğrulama.
• Sürekli entegrasyon: DevOps / kodu ve bileşenleri test edip birleştirmek. MLOps / kodun yanında veriyi, veri şemalarını ve modelleri de test edip doğrulamak.
• Sürekli teslimat: DevOps / tek bir yazılım paketini ya da servisi dağıtmak. MLOps / yalnız modeli değil, modeli otomatik olarak yeniden eğitip dağıtan çok adımlı bir eğitim hattını dağıtmak.
• Üretimdeki bozulma: DevOps / kod değişmedikçe davranış değişmez; izleme hata, gecikme ve kaynak kullanımına odaklanır. MLOps / veri profili değiştikçe model performansı kod değişmeden düşebilir; veri istatistikleri ve canlı model performansı izlenmelidir.
• Ek kavram: DevOps / karşılığı yok. MLOps / sürekli eğitim (continuous training), yani modelin otomatik olarak yeniden eğitilip sunulması.
• Ekip: DevOps / yazılım geliştiriciler, operasyon, kalite ve güvenlik. MLOps / bunlara ek olarak veri bilimciler ve makine öğrenmesi mühendisleri; Google Cloud rehberi veri bilimcilerin üretim kalitesinde yazılım mühendisliği deneyimine her zaman sahip olmayabileceğini not eder.

MLOps'a özgü bileşenler

Bir DevOps hattında bulunmayan ya da farklı biçim alan bazı bileşenler MLOps'un merkezindedir:

• Özellik deposu (feature store): özelliklerin tanımını, saklanmasını ve erişimini standartlaştıran merkezi depo. Eğitimde ve tahminde aynı özellik değerlerinin kullanılmasını sağlayarak eğitim ile sunum arasındaki tutarsızlığı önler.
• Meta veri yönetimi: her eğitim hattı çalışmasında bileşen sürümleri, parametreler, üretilen çıktıların yeri ve değerlendirme metrikleri kaydedilir. Bu kayıt soy ağacını, yeniden üretilebilirliği, geri dönüşü ve hata ayıklamayı mümkün kılar.
• Model kayıt defteri (model registry): eğitilmiş modellerin sürümlendiği, onay ve dağıtım durumlarının izlendiği yer.
• Deney takibi: hangi veriyle, hangi parametrelerle hangi sonucun alındığını kaydeden araçlar.
• Model izleme ve sapma tespiti: canlı veri dağılımının eğitim verisinden uzaklaşmasını ve tahmin kalitesindeki düşüşü yakalayan izleme.

Google Cloud rehberi olgunluğu üç aşamada tarif eder: her adımın elle yürütüldüğü, defterlerle çalışılan ve seyrek sürüm çıkarılan manuel süreç; eğitim hattının otomatikleştirilerek modelin sürekli yeniden eğitildiği hat otomasyonu; ve yeni hat bileşenlerinin de otomatik olarak derlenip test edilip dağıtıldığı CI/CD otomasyonu.

Somut bir örnek: aynı ekip, iki farklı hat

Örneğin bir e-ticaret şirketinde ürün öneri servisi düşünün. Servisin kendisi bir web API'sidir: kodu Git'te tutulur, her değişiklikte testler koşar, konteyner imajı oluşturulur ve ortamlara dağıtılır. Bu, klasik bir DevOps hattıdır.

Ancak önerileri üreten model ayrı bir yaşam döngüsüne sahiptir. Yeni sezon ürünleri eklendikçe ve müşteri davranışı değiştikçe modelin isabeti düşer. MLOps hattı şu adımları otomatikleştirir:

• Yeni veri geldiğinde ya da izleme performans düşüşü yakaladığında eğitim hattını tetiklemek
• Gelen veriyi şema ve dağılım açısından doğrulamak
• Modeli yeniden eğitip önceki sürümle aynı değerlendirme ölçütleriyle karşılaştırmak
• Ölçütü geçen modeli kayıt defterine eklemek ve kontrollü biçimde canlıya almak
• Canlıdaki tahminleri ve veri dağılımını izleyip döngüyü yeniden başlatmak

Kod tek satır değişmese bile model değişebilir. MLOps'un DevOps'a eklediği temel düşünce budur.

Hangi ekibin neye ihtiyacı var?

• Makine öğrenmesi modeli kullanmayan bir yazılım ekibi için DevOps uygulamaları yeterlidir; MLOps'a geçmek gereksiz karmaşıklık getirir.
• Tek bir modeli nadiren güncelleyen ve elle dağıtan bir veri bilimi ekibi, önce deney takibi, model sürümleme ve tekrar üretilebilir eğitim betikleriyle başlamalıdır. Tam otomatik hat bu aşamada şart değildir.
• Birden çok modeli canlıda tutan, verisi sık değişen ve model kararlarının iş sonucuna doğrudan etki ettiği ekipler için eğitim hattının otomasyonu, model izleme ve sürekli eğitim önceliklidir.
• Büyük dil modelleriyle uygulama geliştiren ekipler, MLOps ilkelerini istem (prompt) sürümleme, değerlendirme veri setleri ve maliyet izlemeyle genişleten LLMOps uygulamalarına bakmalıdır.

Rol açısından DevOps mühendisi altyapı, CI/CD ve işletim güvenilirliğinden sorumludur. MLOps mühendisi bu altyapıyı bilen ama veri hatları, eğitim orkestrasyonu, model servis ve izleme konularına odaklanan kişidir; veri bilimciyle platform ekibi arasında köprü kurar.

Sık yapılan hatalar

• Modeli bir yazılım paketi gibi bir kez dağıtıp unutmak: veri değiştikçe performans sessizce düşer.
• Yalnız modeli sürümlemek: modeli üreten veri ve kod sürümü kaydedilmezse sonuç yeniden üretilemez.
• Eğitim ve sunumda farklı özellik hesaplamak: aynı özelliği iki farklı kodla hesaplamak eğitim ile sunum arasında tutarsızlık yaratır.
• Yalnız altyapı metriklerini izlemek: servis ayakta ve hızlı olabilir ama tahminler yanlıştır. Model kalitesine ilişkin ölçütler de izlenmelidir.
• Araçla başlamak: platform seçmeden önce ekibin hangi adımlarının elle yapıldığını ve en çok nerede zaman kaybettiğini belirlemek gerekir.

Mindset programlarında nerede çalışılır?

DevOps Temelleri eğitimi DevOps felsefesi ve kültürel dönüşüm, sürekli entegrasyon, sürekli teslimat ve dağıtım, altyapı otomasyonu, izleme ve geri bildirim döngüsü, güvenlik ve uyumluluk ile ekip modelleri modüllerinden oluşur.

MLOps Mühendisliği Sertifika Programı model yaşam döngüsünden başlayarak deney takibi ve model versiyonlama, özellik mühendisliği ve feature store, makine öğrenmesi için test ve sürekli entegrasyon, boru hattı orkestrasyonu, model servis ve dağıtım mimarileri, model izleme ve sapma tespiti ile yeniden eğitim otomasyonunu kapsar. Yapay Zeka için MLOps ve LLMOps Temelleri eğitimi ise büyük dil modeli operasyonlarını da ele alır.