Modelden Üretime Makine Öğrenmesi Süreci
MLOps, veri operasyonları ve AWS SageMaker ile modellerin geliştirilmesinden üretime alınmasına kadar tüm yaşam döngüsünü keşfediyoruz.
Özet
Bu yazıda, bir makine öğrenimi modelinin geliştirme sürecinin keşifsel, yinelemeli ve belirlenimci olmayan şeklinde özellikleri tanıttık. Veri kalitesi ve keşfiyle, makine öğrenimi modellerinin geliştirilmesi, test edilmesi ve dağıtılmasıyla ilgili bazı zorlukları inceledik. Ardından, bir makine öğrenimi sistemini üretime alma ve üretimde tutma sürecindeki çeşitli zorluklara değindik, bunlardan bazıları geleneksel yazılım geliştirme sürecinde karşılaşılanlara benzer, bazıları ise biraz farklı ve bazıları da makine öğreniminin belirlenimci olmayan ve veri odaklı doğasına özgüdür. Sürüm kontrolü ve testin, makine öğrenimi alanında nasıl farklılaştığını ve olası sorunlara nasıl uyum sağlanabileceğini inceledik. Veri bilimciler ile üretim ekibinin diğer üyeleri arasındaki iş birliği pratiği olan MLOps kavramını tanıttık ve bu zorlukların bazılarına çözümler sunan modern araçlara değindik. Son olarak, uçtan uca yaklaşımlar sunan makine öğrenimi bulut çözümlerini, güçlü ve zayıf yönleriyle birlikte inceledik.
Giriş
Bir makine öğrenimi çözümü, bir dizi girdi verisine dayanarak belirlenimci olmayan bir şekilde tahminler sunar. Geliştirme süreci, keşifsel ve yinelemelidir. Makine öğreniminin bir kuruluşa değer katabileceği bir durumu belirleyerek ve netleştirerek başlarız. Ardından mevcut verileri toplar ve keşfederiz; verilerin doğası, problem ve çözüm hakkında bir hipotez oluştururuz. Bu hipotezi, makine öğrenimi modelleriyle hem görsel hem de programatik olarak keşfeder ve test ederiz. Bir çözüm adayı bulduğumuzda, bunu mevcut altyapıya entegre ederiz ya da bundan yararlanmak için yazılım geliştiririz. Makine öğrenimi çözümünü üretime alma süreci, belirlenimci olmayan doğası, geliştirme ekiplerinin yapısı ve eğitimde kullanılan verilere ve uygulandığı verilere olan bağımlılığı nedeniyle özel zorluklar barındırır.
Model Geliştirme Yaşam Döngüsü
Makine öğrenimi, belirli bir eğitim verisi üzerinde eğitilen ve sonrasında başka verilerle tahmin yapabilen bir model oluşturmayı içerir. Model, girdileri alıp çıktılar üreten bir kara kutu gibi düşünülebilir. Örneğin, bir resmi kedi ya da köpek olarak sınıflandıracak bir model geliştirmek istiyorsak, modele etiketli görseller verilir ve model, bu ilişkilere göre daha önce görmediği görselleri sınıflandırmayı öğrenir.
Model Geliştirme Adımları:
- Problemi anlamak
- İyi varsayımlar ve hipotezler geliştirmek
- Mevcut veriyi toplamak
- Varsayımların gerçekçiliğini değerlendirmek için veri üzerinde keşif yapmak
- Model ve veri işleme adımları ile denemeler yapmak
- Model eğitmek
- Geliştirme ortamına entegre ederek beklenen şekilde çalışıp çalışmadığını test etmek
Bu adımlar birbirinden bağımsız değildir, örneğin veri temizliği sırasında veriler analiz edilir, analizden sonra temizleme sürecinin yeterli ya da fazla olup olmadığı gözden geçirilir.
Problem Anlama ve Hipotez Geliştirme: Problem net tanımlanmadıysa (“ciroyu artırmak”, “müşteri kaybını azaltmak” gibi) gereksinim mühendisliği gerekir. Bu, uzmanlarla görüşmeler, tasarım odaklı düşünme ve keşifsel modelleme gibi yöntemleri içerir. Hedefler, ölçülebilir ve açık biçimde tanımlanmalıdır. Örneğin, “sorunlu müşterileri belirlemek” yerine “2 hafta içinde ödeme yapmayan müşteri oranını %20 azaltmak” gibi hedefler daha uygundur.
Veri Toplama, Temizleme ve İşleme: Veri toplamak bazı durumlarda kolayken, bazen ETL (extract, transform, load) süreçlerini ya da kamuya açık veri kaynaklarını kullanmak gerekir. Ancak açık veriler genellikle özel ihtiyaçları karşılamaz. Veriyi kendimiz toplamak daha uygundur ancak bu zaman ve kaynak gerektirir (örnek: yolcu hareket verileri toplamak ve etiketleme işlemleri gibi). Web kazıma (scraping) da bir yöntemdir ama yasal ve teknik riskler barındırır.
Toplanan tüm veriler temizlik ve yeniden biçimlendirme gerektirir. Bu süreç “data wrangling” olarak adlandırılır ve verilerin amaca uygun hale getirilmesi için dönüşümler (parçalama, birleştirme, filtreleme vb.) içerir.
Keşifsel Veri Analizi (EDA): Veri elde edildikten sonra verideki desenler, anormallikler ve varsayımlar keşfedilir. Görsel analizler ve özet istatistiklerle veri hakkında ilk izlenim edinilir. Örneğin, iris veri kümesinde ilk satırların incelenmesi ve özet istatistiklerin çıkarılması gibi.
Deney ve Model Seçimi: Veri uygun hale geldikten sonra farklı modeller (doğrusal regresyon, sinir ağları, XGBoost vb.) test edilir. Hangi özelliklerin (feature) kullanılacağı önemlidir. Gereksiz bilgiler (gürültü) dışlanmalı, gerekli olanlar eklenmelidir. Özellik sayısı arttıkça model karmaşıklaşır, bu nedenle bazen boyut indirgeme yapılır.
Model türleri:
- Denetimli öğrenme: Girdileri bilinen çıktılarla eşleştirir (örnek: kedi-köpek sınıflandırma).
- Denetimsiz öğrenme: Veri içinde desenler bulur (örnek: belge kümeleme).
- Pekiştirmeli öğrenme: Ortamla etkileşime girerek ödül/ceza alır (örnek: oyun oynama).
Bazı durumlarda birden fazla modelin birlikte kullanıldığı ensemble modeller tercih edilir.
Veri genellikle üçe bölünür: Eğitim (train), doğrulama (validation) ve test. K-fold gibi yöntemlerle veri verimli kullanılır.
Hiperparametre Ayarı: Modelin öğrenme sürecini kontrol eden ve kullanıcı tarafından belirlenen hiperparametreler vardır (örnek: ağ derinliği). Bu ayarlamalar deneme-yanılma ile yapılabilir ama bu zaman alıcıdır. Otomatik hiperparametre ayarlama araçları bu süreci kolaylaştırır.
Eğitim: Model, farklı özellik ve parametre kombinasyonlarıyla eğitilir. Büyük veri kümeleri için önce küçük bir alt kümeyle test yapılır. Uygun kombinasyon bulunduğunda tam veriyle eğitim yapılır. Örnek: GPT-3’ün eğitimi devasa kaynaklar gerektirir (175 milyar parametre). Eğitim sonunda, test verisi ile performans değerlendirilir.
İlk Yayınlama ve Entegrasyon: Model hazır olduğunda, genellikle bir REST API ile bir mikroservis olarak kapsüllenip dağıtılır. Geliştirme ortamında diğer servislerle entegrasyonu sağlanır ve temel testler yapılır.
Geleneksel Yazılım Mühendisliği ile Farklar: Her iki alanda da problemi anlamak esastır. Ancak yazılım mühendisliğinde problemler daha net tanımlıdır. Kod belirli kurallara göre çalışır (deterministik), oysa makine öğrenimi modelleri olasılıksaldır. Bu nedenle test yöntemleri ve proje yaklaşımı farklılık gösterir.
Model Üretim Yaşam Döngüsü
Model üretime hazır olduğunda, süreç geleneksel yazılım yaşam döngüsüne benzerlikler taşır, ancak bazı özgün farklar da vardır. Tüm kodlar gibi, sürekli entegrasyon ve dağıtım (CI/CD) hattına dahil edilmeli, hızlı geri bildirim ve güvenli, kararlı yazılım dağıtımı sağlanmalıdır. Makine öğrenimi (ML) sistemleri sadece eğitilen modeli değil; modeli oluşturan kodu, modelin kendisini ve kullanılan verileri içerir. Bunların tümü versiyonlanmalı, saklanmalı ve dağıtılmalıdır. Ayrıca, modellerin kullanım noktaları yönetilmeli, tahminler kaydedilmeli, sonuçlar günlüğe alınmalı, sistem performansı ve yeni veri üzerindeki davranışı izlenmelidir.
Üretimdeki Modeller
Modeller üretime alındığında, geleneksel yazılım sorunlarına ek olarak, ML’e özgü zorluklarla karşılaşırlar. Arama motorları, kullanıcı sorgularına uygun sonuçlar döndürmeli, hızlı, doğru ve güncel olmalıdır. Film öneri sistemleri gibi sistemler, kullanıcı geçmişi ve topluluk verisiyle öneriler sunar; sürekli güncellenmeli ve kullanıcı tercihlerini takip etmelidir. Finansal sistemler ise dolandırıcılığı tespit etmek için anlık ve doğru tahminler yapmalıdır.
Versiyon Kontrolü
Kod değişikliklerini izlemek, eski sürümlere dönebilmek ve eşgüdüm sağlamak için gereklidir. Git yaygın olarak kullanılır. ML sistemlerinde iki tür kod vardır: Entegrasyon (yapıştırıcı) kodu ve modelleme kodu. Tüm kod, bağımlılıklarıyla birlikte versiyonlanmalı ve test edilmelidir.
Veri Versiyonlama
Veri zamanla değişebilir (sütun yapısı, değerler, istatistiksel özellikler). Modelin tekrar üretilebilmesi için, eğitimde kullanılan verinin aynısı versiyonlanarak saklanmalıdır. Büyük veri hacmi (GB–PB arası) nedeniyle, Git LFS veya DVC gibi sistemler kullanılabilir.
Model Versiyonlama
Modeller, kullanılan algoritma, kod ve veriyle eşleşecek şekilde versiyonlanmalıdır. Model dosyaları da büyük olabilir; bu da geleneksel sistemlerde zorluk yaratır.
Yeniden Üretilebilir Eğitim
Belirli veri ve kod versiyonlarıyla modelin yeniden eğitilmesi mümkün olmalıdır. Bu nedenle model versiyonları saklanmalıdır.
Model Dağıtımı
Model ya uygulamaya gömülü olarak ya da servis olarak dağıtılabilir. Servis modeli, esneklik sağlar ama gecikme ekleyebilir. Her iki durumda da CI/CD süreçlerine benzer test ve entegrasyon gereklidir.
Çoklu Modeller
Aynı görev için birden fazla model kullanılabilir. Ayrı ayrı servisler veya tek API ile erişim sağlanabilir. Gölge modeller (shadow models) canlı sistemde test edilir, karşılaştırmalı testler (A/B testleri) yapılabilir. Çevrimiçi öğrenen modeller sürekli güncellenir ve daha karmaşık yönetim gerektirir.
Test ve Kalite
ML sistem testleri geleneksel yazılıma göre daha kapsamlıdır:
- Veri doğrulama (şema ve değer testleri)
- Bileşen entegrasyonu
- Modelin doğruluğu ve performans ölçümleri
- Tarafsızlık ve adalet (etik davranış kontrolü)
İzleme ve Gözlemlenebilirlik
Model üretime alındığında, girdi ve çıktı verileri, modelin nasıl tahmin yaptığı, kullanıcı davranışları (örneğin ürünü alıp almadıkları), modelin adil davranıp davranmadığı, tepki süresi ve kaynak kullanımı gibi metrikler izlenmelidir. Geri besleme döngüsü kurularak modellerin iyileştirilmesi sağlanır.
Model Kayması (Drift)
Zamanla veri değişirse modelin doğruluğu bozulur:
- Kavram kayması (Concept drift): Hedef değişkenin istatistiksel yapısı değişir.
- Veri kayması (Data drift): Girdi verisinin özellikleri değişir.
Bu değişimler kademeli, döngüsel veya ani olabilir.
Çözüm yolları:
- Hiçbir şey yapmamak (bazı durumlarda yeterlidir)
- Periyodik yeniden eğitim
- Verilere ağırlık verme
- Otomatik model seçimi
- Zaman serilerine uygun veri hazırlığı
Sorunlar ve Kurtarma
Üretimde her zaman sorun çıkabilir.
Bu nedenle:
- Versiyonlama ile geri dönüş sağlanmalı
- İzleme ile sorun erken tespit edilmeli
- Yeniden eğitim için veri ve kod kayıtlı olmalı
- Performans düşerse eski sürüme dönüş yapılmalı
Model üretimi ve dağıtımı, sadece model kodunu değil, veriyi, çıktıyı, kullanıcı tepkisini ve etik sorumlulukları kapsayan bütünsel bir süreçtir. Tüm bu unsurlar izlenmeli, versiyonlanmalı ve gerektiğinde hızlıca müdahale edilmelidir.
MLOps ve DataOps
Makine öğrenimi sistemlerini üretime almak ve orada tutmak, yazılım geliştirmedeki DevOps’a benzer zorluklar içerir. DevOps; sürekli entegrasyon (CI) ve sürekli teslimat (CD) ile daha kısa geliştirme döngüleri, hızlı dağıtım ve güvenilir sürümler sunar. Aynı yaklaşım makine öğrenimi sistemlerine de uyarlanabilir.
Temel Zorluklar ve Gereksinimler
- Ekip Yetenekleri: Veri bilimciler her zaman mühendislik tecrübesine sahip değildir, bu nedenle kodları üretim kalitesine getirmek gerekir.
- Geliştirme: Deneysel ve deterministik olmayan ML sistemleri, farklı algoritmalar, özellikler ve veri kümeleriyle hızlıca denemeler yapılmasını gerektirir. Bunun yanında tekrar üretilebilirlik ve kod yeniden kullanılabilirliği korunmalıdır.
- Test: ML sistemlerinde yalnızca birim ve entegrasyon testleri değil; veri doğrulama, model kalitesi ve model doğrulama testleri de gereklidir.
- Dağıtım: Modellerin otomatik olarak yeniden eğitilip dağıtıldığı çok aşamalı bir süreçtir ve bu sürecin otomasyonu önemlidir.
- Üretim: Kod kalitesi ve veri profillerindeki değişimler performansı etkiler. Modellerin çökmesi daha yaygındır ve bu yüzden istatistiksel izleme, bildirim sistemleri ve geri alma mekanizmaları gereklidir.
CI/CD süreçleri ML sistemlerine uyarlanmalı, ancak ek olarak veri ve model doğrulaması da yapılmalıdır. Ayrıca Sürekli Eğitim (CT) süreci de eklenmelidir. CT, modellerin otomatik olarak yeniden eğitilip servis edilmesini kapsar.
DataOps ve MLOps
- DataOps: Veri yaşam döngüsünün tüm aşamalarında otomasyon ve süreç yönetimi sağlar. Veri kalitesini artırmayı ve analitik süresini azaltmayı hedefler. Tanımlı kurallar, insan geri bildirimi, otomasyon, darboğaz tespiti, yönetişim, büyüme ve esneklik gibi prensipleri vardır.
- MLOps: Veri bilimciler ve operasyon ekipleri arasında iş birliğini artırmak için geliştirilmiştir. MlOps’un kapsadığı konular; dağıtım ve otomasyon, model ve tahminlerin yeniden üretilebilirliği, tanılama, yasal ve kurumsal uyumluluk, ölçeklenebilirlik, iş birliği, İş kullanım senaryoları, izleme ve yönetim olarak verilebilir.
Diğer yaklaşımlar arasında AIOps, ModelOps ve DLOps olan MLOps’un alt kategorileri yer alır.
MLOps Araçları
MLflow: MLflow, model geliştirme ve takibini otomatikleştirir. Kütüphanelerden bağımsızdır ve dört ana bileşeni vardır:
- Tracking: Parametre, metrik, model ve deney günlükleme.
- Projects: YAML dosyaları ile tekrarlanabilir projeler.
- Models: Birden çok kütüphane ile uyumlu model paketleme (flavors).
- Model Registry: Model versiyonları, aşamalar (staging, production), açıklamalar ve geçiş yönetimi.
MLflow, pip install mlflow
ile kurulabilir ve örnek Python kodları ile parametreler, metrikler ve çıktılar takip edilebilir.
Kubeflow: Google tarafından geliştirilmiş açık kaynaklı bir ML platformudur ve Kubernetes üzerinde çalışır.
Tüm ML yaşam döngüsü:
- Jupyter Notebook yönetimi ve paylaşımı
- RBAC, güvenlik ve kimlik yönetimi
- Docker tabanlı çok aşamalı ML pipeline tanımları
- Python SDK (kfp) ile pipeline tanımlama ve çalıştırma
- Hiperparametre ayarlama, model eğitimi ve servis sunumu.
Michelangelo: Uber tarafından geliştirilen uçtan uca bir ML platformudur.
“Gizli teknik borçları” azaltmak için tasarlanmıştır:
- Hem çevrimdışı (batch) hem de çevrimiçi (streaming) tahminleri destekler
- Apache Kafka, Hadoop, Spark gibi teknolojilerle veri hazırlığı
- Model eğitimi: karar ağaçları, regresyon, zaman serileri, DNN vs.
- Versiyonlanmış model deposu (Cassandra)
- Dashboard üzerinde model değerlendirme raporları
- A/B testi, birden fazla modelin aynı konteynerde servisi
- SLA’ya uygun, hafif çevrimiçi tahmin desteği
Sonuç olarak her bir araç farklı güçlere ve sınırlamalara sahiptir ancak her sistem, kurulum ve bakım için deneyimli bir ekip ve uygun altyapıyı gerektirir:
- MLflow: Model yönetimi güçlü, dağıtım için başka araçlara (örneğin Airflow) ihtiyaç duyar.
- Kubeflow: Entegrasyon açısından güçlü, Kubernetes temelli, ancak kurulum karmaşık.
- Michelangelo: Entegre, kurumsal düzeyde çözüm sunar fakat daha az esneklik sunar.
Bulut Tabanlı Çözümler
Makine öğrenimini üretime taşımak çeşitli zorluklar barındırır. MLOps’un (Makine Öğrenimi Operasyonları) doğuşu, bu zorluklara yönelik çeşitli araç ve yöntemlerin geliştirilmesine neden olmuştur. Bu araçlar genellikle mevcut altyapı üzerine kuruludur veya hibrit çözümleri destekleyebilir. Ancak kendi altyapınızı kurmak, bilgi birikimi, kaynak kullanımı, donanım/yazılım bakım maliyetleri ve ölçeklenebilirlik gibi problemleri beraberinde getirir. Bu nedenle birçok kuruluş bu maliyetleri üstlenmek istemez ve bu noktada bulut tabanlı makine öğrenimi hizmetleri devreye girer. Bu hizmetler küçük bir ekip ile model geliştirme, izleme ve dağıtım yapılmasına imkân tanır.
MLaaS (Hizmet Olarak Makine Öğrenimi)
MLaaS, veri ön işleme, model eğitimi, değerlendirme, dağıtım ve izleme gibi tüm MLOps süreçlerini kapsayan bulut tabanlı platformları ifade eder. REST API veya RPC gibi protokollerle iç sistemlere bağlanabilir. Önde gelen sağlayıcılar arasında Amazon Machine Learning, Azure Machine Learning, Google Cloud AI ve IBM Watson yer alır.
Amazon Machine Learning
İki seviyede hizmet sunar:
- Amazon ML (Predictive Analytics): Otomatik, kullanıcı dostu; veri ön işlemesi ve model seçimi otomatik yapılır. Sadece sınıflandırma ve regresyon destekler; denetimsiz öğrenme desteklemez.
- Amazon SageMaker: Daha gelişmiş kullanıcılar için; model oluşturma, eğitim ve dağıtımı kolaylaştıran, Jupyter destekli bir ortam sunar.
Amazon SageMaker ile Makine Öğrenimi: Amazon SageMaker, uçtan uca makine öğrenimi sürecini gerçekleştirmek için tam yönetilen bir hizmettir.
Aşamalar:
1. Ön Koşullar
AWS hesabı, IAM kullanıcı/grubu oluşturulması gerekir. AWS kullanımı başlangıçta karmaşık olabilir, bu nedenle temel bilgi edinilmesi önerilir.
2. Problem Anlayışı
Tam otomatik çözümler henüz mevcut değildir; ancak SageMaker Autopilot, bazı sınıflandırma ve regresyon problemleri için otomatik çözüm sunar.
3. Veri Toplama ve Hazırlık
Veriler genellikle S3 üzerinde tutulur. Ön işleme işlemleri Jupyter notebook içinde yapılır. Ayrıca AWS Glue ve SparkML ile veri temizleme ve dönüştürme mümkündür. Boto3 Python kütüphanesi ile bu işlemler otomatikleştirilebilir.
4. Keşifsel Veri Analizi (EDA)
Jupyter not defterleri üzerinden, klasik Python kodları ile analiz yapılabilir. AWS ortamında çalışmak dışında bir fark yoktur.
5. Model Deneyleri, Eğitimi ve Sürümleme
SageMaker; yerleşik algoritmalar (örneğin XGBoost, K-means, LDA, Object Detection, vb.), Docker konteyner desteği ve SparkML entegrasyonu ile esnek model geliştirme sunar. SageMaker Experiments ile deneyler ve eğitim süreçleri izlenebilir, karşılaştırılabilir ve analiz edilebilir. Autopilot süreçleri de otomatik olarak deneyler oluşturur. Kod ve veri sürümlemesi manuel olarak yönetilmelidir. Git desteği mevcuttur.
6. Model Dağıtımı
İki yöntem:
- Hosting Endpoint: Tekil tahminler için.
- Batch Transform: Toplu tahminler için.
AWS Lambda ve API Gateway ile kamuya açık erişim de sağlanabilir.
7. İzleme
SageMaker Model Monitor ve Amazon CloudWatch ile model kalitesi izlenebilir, sapmalar ve anormallikler tespit edilebilir. CloudTrail ile log dosyaları saklanır. Ayrıca A/B testleri ve model varyantları ile performans karşılaştırmaları yapılabilir. Gerektiğinde yeniden eğitim tetiklenebilir.
Sonuç ve Değerlendirme
Bulut tabanlı makine öğrenimi hizmetleri:
- Küçük takımlarla başlanabilir, büyüdükçe ölçeklenilebilir,
- Entegre izleme ve üretim desteği sunar,
- En iyi uygulamaları içeren çözümler barındırır.
Ancak:
- Vendor lock-in (sağlayıcıya bağımlılık) riski vardır,
- Taşınabilirlik sorunları olabilir,
- Maliyetler daha yüksektir (örneğin SageMaker’lı EC2, sade EC2’ye göre %40 daha pahalı olabilir),
- Kapalı kaynak bileşenler esneklik kaybına yol açar.
Genel olarak küçük ve yeni başlayan organizasyonlar için idealdir; fakat yapı büyüdükçe, şirketin kendi altyapısına geçmesi daha mantıklı olabilir.