MLOps Yaşam Döngüsünü Anlamak: MLflow, DVC ve GitHub Actions ile Uçtan Uca Bir Pipeline Örneği

İçindekiler

1. Giriş
2. MLOps Yaşam Döngüsü
3. Kullanılan Araçlar ve Teknoloji Seçimleri
   1. Veri Sürüm Kontrolü (Data Version Control - DVC)
   2. MLflow
      1. MLflow Izleme (MLflow Tracking)
      2. MLflow Projeleri (MLflow Projects)
      3. MLflow Modeli ve Model Kayıt Sistemi (MLflow Model & Model Registry)
   3. DagsHub
   4. GitHub Actions
   5. Araçların Entegrasyonu ve Iş Akışı
4. Uygulamalı Demo: Su Içilebilirliği Tahmini Projesi
   1. Veri Toplama ve Ön Işleme
   2. Model Eğitimi ve Deney Takibi
   3. DVC Pipeline Yönetimi
   4. CI/CD Entegrasyonu
5. Sonuçlar ve Özet Değerlendirme
6. Kaynakça

1. Giriş

Hayatımıza hızlı bir şekilde giren ve kuşkusuz günümüzün en popüler konularından biri olan Yapay Zekâ, insan benzeri bir zekâyı taklit edebilen bilgisayar sistemlerini ifade etmektedir. Yakın gelecekteki büyük potansiyeli sayesinde, bu alana hem büyük teknoloji şirketleri milyarlarca dolarlık yatırımlar yapmakta hem de bu alana bireysel ilgi duyan pek çok kişi ciddi emek ve zaman harcamaktadır. Makine öğrenmesi (Machine Learning) ise Yapay Zekânın bir alt dalı olarak karşımıza çıkmaktadır. Makine öğrenme modelleri, açık kurallar olmadan, verilerden öğrenerek karar mekanizması oluşturulmasında kullanılmaktadır. Derin öğrenme ve ona dayalı yapay sinir ağlarında son zamanlarda önemli gelişmeler yaşanıyor. Bu yeni yöntemlerle çalışan modern makine öğrenmesi modellerini geliştirmek ve bunların iyi sonuç vermesini sağlamak için büyük miktarda veriye ihtiyaç duyulmaktadır. Bu alanda veri bilimciler, veri mühendisleri, makine öğrenim mühendisleri ve Yapay Zekâ mühendisleri gibi uzmanlar hem model geliştirilmesi hem de verilerin toplanması, temizlenmesi alanında pek çok çalışma yapmaktadır. Ancak sıklıkla değişen veriler ve modeller, çalışmaların takibini ve bu alandaki çalışmaların üretim ortamına hızlı bir şekilde geçirilmesini zorlaştırmaktadır. Bu noktada karşımıza üretim ortamına entegrasyonu kolaylaştıran uçtan uca bir çözüm olarak MLOps kavramı çıkmaktadır.

MLOps, Machine Learning (Makine öğrenmesi) ve Operations (Operasyon) terimlerinin birleşmesiyle oluşmaktadır. Ops terimi, yazılım ürünlerini hızlı ve güvenli bir şekilde üretim ortamına çıkarma isteği sonucu doğan DevOps (Development - Operations) yaklaşımından gelmektedir. DevOps yaklaşımları sayesinde yazılım ürünlerinin Sürekli Entegrasyon’u (Continuous Integration), Sürekli Dağıtım’ı (Continuous Deployment), otomasyonu ve izlenmesi güvenilir bir şekilde sağlanmaktadır. DevOps, Geliştirici ve Operasyon ekiplerinin iş birliği içerisinde yazılımın kalitesini, hızlı dağıtımını ve güvenliğini ön planda tutarak çalışmasını sağlayan bir kültürdür ve burada, manuel süreçleri otomatize etmek temel prensiptir [1]. Aynı yaklaşımın makine öğrenmesi sistemlerine de uyarlanmasıyla birlikte MLOps terimi ortaya çıkmıştır. MLOps, DevOps aşamalarına ek olarak veri işleme ve makine öğrenmesine yönelik süreçleri kapsamaktadır. Amaç ML iş akışlarındaki ekiplerin iletişimini güçlendirmek, ortak bir dil ve pipeline üzerinde çalışmalarını sağlamak, bunun sonucu olarak da verimliliği ve başarı oranını artırmaktır [2]. Makine öğrenmesinde kullanılan verilerin ve modellerin değişikliğine çevik bir şekilde cevap vermek, kötüleşen modelleri iyileştirebilmek ve makine öğrenmesi modellerinin başarı oranını artırmak temel hedeftir. MLOps ile birlikte Yapay Zekâ modelleri ve verilerinin hızlı bir şekilde versiyonlanması, sürümünün alınması, üretim ortamına alınabilmesi ve sonrasında izlenebilmesi sağlanmaktadır.

Bu çalışma kapsamında, MLOps alanında en çok kullanılan araçlardan biri olan MLFlow üzerinde bir uygulama yapılmış, MLOps çalışmalarında nasıl veri ve model versiyonlanabileceği anlatılmıştır.

2. MLOps Yaşam Döngüsü

Bir organizasyonda, MLOps süreçleri aşağıdaki aşamalar ile özetlenebilmektedir:

• Makine öğrenmesi modelinin kullanım ihtiyaçlarının ve bu ihtiyaca göre model gereksinimlerinin belirlenmesi: Makine öğrenmesi modelleri, bir iş sürecinin bir aşamasında verilen bir kararı vermek veya bu kararı desteklemek adına oluşturulmaktadır. İlk aşama modelin vereceği/destekleyeceği kararın girdilerinin öznitelikleri, çıktıları, bu kararın aynı anda kaç kullanıcı tarafından isteneceği, modelin gerektirdiği verilerin gizliliği, modelin çıkarımlarının kabul edilebilir asgari başarım ölçütleri, modele beslenecek verinin organizasyonda barındırıldığı unsurlar, modelin girdi verilerinin zamanlılık gereksinimleri, modelin model girdisindeki zamanlılık gereksinimleri gibi unsurların ortaya konmasıdır. MLOps süreçlerinin olgunluğu arttıkça problemler tekil bir modelin kabiliyetlerinden daha fazlasını gerektirmektedir. Bu karmaşıklığın yönetilmesi için tekil bir model yerine bir dizi model ve veri işleme operasyonunu birlikte yönetmek gerekebilmektedir. Bu durumda süreç tekil bir model odağında girdi çıktılardan çok bir pipeline’ın oluşturulması haline gelmektedir.

• Model gereksinimlerini destekleyecek verinin oluşturulması: Model ihtiyaçlarına uygun verinin organizasyonun veri kaynaklarının, model gereksinimlerine uygun verileri ortaya koyması ve gerekli hallerde bu ham verilerin işlenerek modelin kullanabileceği verilere dönüştürülmesidir. Bu sürece Özellik Mühendisliği (Feature Engineering) de denmektedir. Yüksek olgunlukta MLOps süreçlerinde, organizasyon genelindeki verilerin çeşitli modellerde kullanımını kolaylaştırmak adına, özelliklerin yönetildiği ayrı yazılımlar kullanılmaktadır.

• Makine öğrenmesi modellerinin ortaya konması: İlk gereksinimleri karşılanmış modelin eğitim ile ortaya konmasıdır. Yüksek olgunlukta, aynı sorun için farklı yöntemler ve hiper parametreler ile birden fazla model üretilmekte ve daha başarılı olan model uygulamaya alma aşamasına geçmektedir. Modellerin başarımının ölçülmesinde kullanılan çeşitli metrikler bulunmakla birlikte yaygın kullanılan metrikler olarak Accuracy (doğruluk), precision (kesinlik), recall (duyarlılık) ifade edilebilir. Yüksek olgunlukta, modelin geliştirildiği ve kullanıma alındığı ortamlar ayrıştırılmakta, her bir ortam kendi yazılım ve donanım ortamında işletilmektedir.

• Makine öğrenmesi modelinin kullanıma alınması: ML ve DevOps süreçlerinin temas noktasıdır. Bir gereksinimi karşılaması için ortaya konmuş olan model, ihtiyaç sahiplerinin kullanımına sunulmaktadır. Yüksek olgunlukta, sürekli kullanımdaki sistemde yeni oluşan veriler ile yeni ML modelleri gözetim altında olmak kaydıyla otonom olarak kullanıma alınmakta kullanımdan kaldırılabilmektedir.

• Makine öğrenmesi modelinin başarımının izlenmesi: Kullanıma alınmış modellerin verdiği/desteklediği kararlar üzerinden başarımlarının izlenmesidir. Bu sayede başarısı düşen modeller tespit edilebilmektedir. Bu gözlemler yeni model üretme çalışmalarında önceki modelin problemlerinin teşhisi ve giderimini de beslemektedir.

MLOps yaşam döngüsü Şekil 1’de görselleştirilmektedir:

Görsel özetle, veri ve akıllı karar verme süreçlerini ML, bu süreçlerin bilişim teknoloji kabiliyetleriyle ihtiyaç duyulan alanlarda kullanılabilir hale getirilmesini ve işletilmesini Dev, iş ihtiyaçlarının zeki sistemlerce çözülmesinin organizasyonda muhasebe, insan kaynakları gibi yaygın bir operasyon olarak işletilmesini de MLOps olarak tanımlamaktadır. Bu aşamalar sürekli olarak birbirlerini etkilemektedir. Bu sebeple MLOps süreçleri, bir başlangıçtan nihai bir sonuca gitmekte olan tek yönlü bir süreç olarak değil, değişen iş ihtiyaçlarının gereksinimlerini akıllı sistemler ile sürekli olarak karşılamaya çalışan bir operasyonlar bütünüdür. Operasyonun bir noktasında verilen kararlar operasyonun gidişatının yönünü etkileyip, diğer adımlarda yeni kararlar verilmesini tetikleyebileceğinden süreç döngüsel olarak kavramsallaştırılmaktadır.

3. Kullanılan Araçlar ve Teknoloji Seçimleri

Modern makine öğrenimi projelerinin başarısı, yalnızca algoritma seçimi ve model performansına değil, aynı zamanda tüm ML yaşam döngüsünü destekleyen araçların etkin kullanımına da bağlıdır. Bu bölümde, su içilebilirliği tahmin projemizde kullanılan MLOps araçları, bunların seçilme gerekçeleri ve projedeki işlevleri incelenmektedir. Projemiz için seçilen teknoloji yığını, veri yönetimi, model eğitimi, deney takibi ve otomatik dağıtım aşamalarını kapsayan uçtan uca bir MLOps pipeline oluşturmak üzere tasarlanmıştır.

Veri Sürüm Kontrolü (Data Version Control - DVC)

DVC, Git’in kod versiyonlama paradigmasını veri bilimi alanına genişleten modern, açık kaynaklı bir araçtır. Genellikle ML projelerinde veri ve model sürümleme amacıyla kullanılmaktadır. Büyük veri dosyalarını Git reposunun dışında tutarak, verilerin referanslarını Git üzerinde takip etmek suretiyle hafif ve etkili bir versiyonlama çözümü sunmaktadır. Git benzeri komut yapısıyla, veri ve modellerin aynı kod gibi sürüm kontrolüne tabi tutulmasını sağlamaktadır. Geleneksel versiyon kontrol sistemleri (Git gibi) kod için optimize edilmişken, DVC özellikle büyük veri dosyaları ve makine öğrenimi modelleri için geliştirilmiştir. DVC’nin Git ile tam entegrasyon sağlayarak kod, veri ve parametreler arasında bağlantı kurması, deneyin yeniden üretilebilir bir şekilde çalıştırılmasını sağlaması ve ML pipeline adımlarını otomatikleştirmesi bu aracın en büyük faydalarındandır [4].

Projede DVC aşağıdaki amaçlarla kullanılmaktadır:

• Veri Versiyonlama: Veri setinin versiyonlanması ve bu versiyonların takibi,
• Deney Parametreleri Versiyonlama: Deney sırasında kullanılan parametrelerin versiyonlanması ve bu versiyonların takibi (param.yaml vb dosyalarında tutulan parametrelerin takibi),
• Veri İşleme Pipeline: Veri ön işleme adımlarının (eksik değerlerin doldurulması, özellik mühendisliği) otomatik ve yeniden üretilebilir şekilde gerçekleştirilmesi,
• Model Eğitim ve Değerlendirme Pipeline: Model eğitim süreçlerinin tanımlanması ve otomatikleştirilmesi,
• Pipeline Bağımlılıklarının Yönetimi: Veri toplama, ön işleme, model eğitimi, değerlendirme ve model kaydı aşamaları arasındaki bağımlılıkların yönetilmesi.

MLflow

MLflow, makine öğrenimi yaşam döngüsü yönetimini standardize etmek için geliştirilen açık kaynaklı bir platformdur [9]. Deneylerin izlenmesi, modellerin paketlenmesi ve model servis etme gibi MLOps’un temel fonksiyonlarını içeren modüler bir yapıya sahiptir.

MLflow’un projede için seçilme gerekçeleri şu şekildedir:

• Deney takibinin kolaylaştırılması,
• Model sürümleme ve kayıt imkanı,
• Framework (çerçeve) bağımsız çalışabilmesi (TensorFlow, PyTorch, scikit-learn uyumluluğu),
• Kullanım kolaylığı ve geniş topluluk desteği.

MLflow Izleme (MLflow Tracking)

MLflow Tracking, makine öğrenimi deneylerinin parametrelerini, metriklerini ve model dosyalarını sistematik şekilde kaydeden bir deney yönetim sistemidir. Projemizde bu sistem sayesinde farklı algoritmaların ve hiperparametre kombinasyonlarının performans karşılaştırmaları yapılabilmekte, özellikle veri ön işleme tekniklerinin etkileri objektif olarak değerlendirilebilmektedir. Sistemin sunduğu görselleştirme araçları ve merkezi kayıt özellikleri, karmaşık deney süreçlerini yönetmeyi kolaylaştırmaktadır. Paralel koordinat grafikleriyle parametre optimizasyonu yapılabilmekte, model artifact’larını (yapay ürünlerini) saklayarak başarılı konfigürasyonlara kolayca geri dönülebilmekte, böylece proje verimliliğini önemli ölçüde artırılmaktadır [5].

MLflow Projeleri (MLflow Projects)

MLflow Projects, makine öğrenimi projelerinin, kodun ve bağımlılıkların paketlenerek yeniden üretilebilir, taşınabilir hale getirilmesini sağlayan bir MLflow bileşenidir. Bu yapı, projenin farklı ortamlarda yeniden çalıştırılabilmesini sağlar. Deneylerin otomatik olarak tetiklenmesini kolaylaştırır. CI/CD süreçlerine kolayca entegre olur. Aynı girdilerle aynı çıktılar üreterek validasyon süreçlerini daha sağlam hale getirir. Bu sayede deneysel modeller ile üretim ortamındaki modeller arasında tutarlılık sağlanır ve geçişler sorunsuz ilerler.

MLflow Modeli ve Model Kayıt Sistemi (MLflow Model and Model Registry)

MLflow Model Registry, makine öğrenimi modellerinin yaşam döngüsünü yönetmek için tasarlanmış merkezi bir model deposudur. Bu bileşen, ekiplerin eğitilmiş modelleri versiyonlayarak saklamasına, aşamalandırmasına (staging → production → archived) ve iş birliği içinde yönetmesine olanak tanımaktadır. Model Registry sayesinde modellerin geçmiş versiyonları takip edilebilir, açıklama notları eklenebilir ve belirli kurallara göre üretim ortamına geçişleri yönetilebilmektedir. Projemizdeki kullanımı açısından bakıldığında, Model Registry en iyi performans gösteren modellerin kayıt altına alınması ve kontrollü dağıtımı için kritik bir rol oynamaktadır. Özellikle CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) pipeline’ı ile entegre çalışarak, testleri geçen modellerin otomatik olarak üretim ortamına yükseltilmesini sağlamaktadır. Bu sayede model geçişlerinde insan hatası riski ortadan kaldırılmakta ve üretim ortamındaki modellerin izlenebilirliği garanti altına alınmaktadır. Ayrıca, eski model versiyonlarını arşivleyerek gerektiğinde geri dönüş yapabilme esnekliği kazanılmaktadır [5].

DagsHub

DagsHub, makine öğrenimi ve veri bilimi projelerinin yaşam döngüsünü yönetmek üzere geliştirilmiş kapsamlı bir platformdur. DagsHub, GitHub’un veri bilimi ve makine öğrenimi projelerine uyarlanmış bir versiyonu olarak düşünülebilmektedir. Git, DVC ve MLflow’u tek bir merkezi platform üzerinde birleştirerek, kod, veri ve model versiyonlama ile deney takibini entegre şekilde yönetmeyi sağlamaktadır. Platform, özellikle büyük ölçekli makine öğrenimi projelerinde karşılaşılan veri, kod ve model yönetimi karmaşıklığını çözmeyi amaçlamaktadır. DagsHub, MLOps süreçlerinde kullanılan farklı bileşenlerin (veri versiyonlama, deney takibi, model sürümleme vb.) birbirleriyle sorunsuz biçimde entegre olabilmesini sağlayarak bütüncül bir altyapı sunmaktadır. Örneğin, bir veri setinde yapılan versiyon değişikliği, otomatik olarak ilgili deneylerle ilişkilendirilebilir ve bu değişikliğin model performansına etkisi kolaylıkla izlenebilmektedir. Bu yapı sayesinde model yaşam döngüsü boyunca şeffaflık ve izlenebilirlik artarken, dağıtık ekipler arasında tutarlılık sağlanmaktadır [6]. Ayrıca DagsHub, deney sonuçlarının merkezi olarak yönetilmesi, model geliştirme süreçlerinin standartlaştırılması ve ekipler arası iş birliğinin daha sürdürülebilir bir yapıya kavuşması gibi konularda önemli avantajlar sunmaktadır.

DagsHub, projemizde şu işlevleri üstlenmiştir:

• Merkezi Kod ve Veri Deposu: Projemizdeki tüm kod, veri, model ve deneyler için merkezi bir depo sağlamıştır.
• MLflow Tracking Server: DagsHub’ın entegre MLflow sunucusu, deney metriklerini ve modelleri saklamak için kullanılmıştır.
• DVC İzleme: DVC tarafından yönetilen veri dosyaları web arayüzü üzerinden görüntülenmiştir.
• CI/CD Entegrasyonu: GitHub Actions ile entegre çalışarak CI/CD süreçlerini desteklemiştir.

GitHub Actions

GitHub Actions, GitHub platformu üzerinde yazılım geliştirme süreçlerini otomatikleştirmek için tasarlanmış bir Sürekli Entegrasyon ve Sürekli Dağıtım (CI/CD) aracıdır. YAML tabanlı iş akışı tanımları kullanarak; kod derleme, test çalıştırma, paket oluşturma ve dağıtım gibi süreçleri otomatikleştirmeye olanak tanımaktadır. Özellikle açık kaynak projelerde yaygın olarak kullanılan bu sistem, farklı işletim sistemleri ve programlama dilleriyle uyumlu çalışabilme esnekliği sunmaktadır. Makine öğrenimi projelerinde ise model eğitimi, veri işleme ve test süreçlerinin otomasyonu için ideal bir çözümdür. GitHub Actions, DagsHub ve MLflow ile entegre şekilde çalışarak tam otomatik bir MLOps pipeline kurmayı sağlamıştır. Kod değişikliklerinde tetiklenen iş akışları sayesinde veri ön işleme adımları otomatik çalıştırılmakta, modeller yeniden eğitilmekte ve testlerden geçen modeller otomatik olarak üretim ortamına alınmaktadır. Bu yaklaşım, manuel hata riskini ortadan kaldırırken dağıtım sürelerini kısaltmakta ve model güncelleme süreçlerinin izlenebilirliğini artırmaktadır [7].

Araçların Entegrasyonu ve Iş Akışı

Projenin altyapısında kullanılan araçlar, birbirlerini tamamlayan ve proje süreçlerini optimize eden bir ekosistem oluşturarak, veri bilimi projelerinin yönetimini, izlenebilirliğini ve otomasyonunu sağlamaktadır. Tablo 1’de araçların kullanım amaçları ve rolleri açıklanmaktadır.

Tablo 1: MLOps Araçları ve Proje İçindeki Rolleri

Tablo 1’de görüldüğü gibi, yukarıda açıklanan tüm araçlar (DVC, MLflow, DagsHub ve GitHub Actions), projemizde entegre bir MLOps iş akışı oluşturmak üzere bir araya getirilmiştir. Bu iş akışı, aşağıdaki aşamaları içeren uçtan uca bir pipeline sağlamaktadır:

• Veri Toplama ve Versiyonlama: Ham veriyi DVC ile versiyonlamak.
• Veri Ön İşleme: Eksik değerleri doldurmak ve veri temizliğini DVC pipeline adımı olarak tanımlamak.
• Deney Takibi: Farklı algoritma ve hiperparametreleri MLflow Tracking ile izlemek.
• Model Eğitimi ve Değerlendirme: En uygun modeli seçmek ve değerlendirmek.
• Model Kayıt ve Versiyonlama: Seçilen modeli MLflow Model Registry’de versiyonlamak.
• Sürekli Entegrasyon: GitHub Actions ile testleri otomatik olarak çalıştırmak.
• Sürekli Dağıtım: Başarılı modeli Production ortamına yükseltmek ve Docker imajını oluşturmak.
• Model Servis Etme: FastAPI tabanlı bir API ile modeli servis etmek.

Bu entegre MLOps yaklaşımı, projemizin yeniden üretilebilirliğini, izlenebilirliğini ve güvenilirliğini önemli ölçüde artırmıştır. Bu araçlar sayesinde, geleneksel makine öğrenimi geliştirme sürecinin karşılaştığı yeniden üretilebilirlik, izlenebilirlik ve otomasyon sorunları başarıyla çözümlenmiştir.

4. Uygulamalı Demo: Su Içilebilirliği Tahmini Projesi

Bu bölümde, yukarıda tanıtılan araçlar kullanılarak suyun içilebilir olup olmadığını tahmin eden bir makine öğrenimi projesi üzerinden uçtan uca bir MLOps pipeline’ı uygulamalı olarak gösterilmektedir. Projenin temel amacı, su numunelerinin çeşitli fiziksel ve kimyasal özelliklerine dayanarak suyun içilebilir (potable) olup olmadığını tahmin etmektir. Proje boyunca kullanılan başlıca araçlar ve rolleri şu şekildedir:

• Git/GitHub: Kod versiyonlama ve iş birliği için kullanılmıştır.
• DVC (Data Version Control): Veri setlerinin ve modellerin versiyonlanması ile ML pipeline adımlarının yönetilmesi için kullanılmıştır.
• MLflow: Model eğitimi deneylerinin izlenmesi, kaydedilmesi ve model versiyonlarının yönetilmesi (Model Registry) için kullanılmıştır. DagsHub platformu, MLflow Tracking sunucusu olarak entegre edilmiştir.
• GitHub Actions: Sürekli Entegrasyon/Sürekli Dağıtım (CI/CD) pipeline’ını otomatikleştirmek için kullanılmıştır.

Projenin genel akış şeması ve MLOps sürecinin adımları Şekil 2’de gösterilmektedir. Bu diyagram, ham veriden başlayan, farklı deneylerin yürütüldüğü, en iyi modelin belirlendiği, bir DVC pipeline ile adımların otomatikleştirildiği ve son olarak modelin kullanıma sunulduğu bir akışı özetlemektedir.

Genel süreç, veri toplama ve ön işleme, model eğitimi ve deney takibi, DVC pipeline yönetimi ve CI/CD entegrasyonu adımlarından oluşmaktadır.

Veri Toplama ve Ön Işleme

Projede kullanılan veri seti, Kaggle platformundan elde edilen Water Quality and Potability [8] veri setidir. Bu veri seti, çeşitli fiziksel ve kimyasal özellikleri içeren su numunelerinin içilebilirlik durumunu (Potability) belirtmektedir. Veri setinin edinilmesinin ardından, makine öğrenmesi modelinde kullanılmadan önce ön işleme adımları uygulanmıştır. Bu adımlar eksik değerlerin tespiti ve doldurulması, veri yapısının incelenmesi ve gerekli veri temizliğinin yapılmasını içermektedir. Eksik değerler için ortalama (mean) ile doldurma yöntemi benimsenmiştir. Bu adımların detaylı kodu src/data dizininde bulunmaktadır. Ham ve işlenmiş veri setleri, DVC kullanılarak versiyonlanmıştır. Bu sayede, veri setindeki değişiklikler takip edilebilir ve pipeline’ın veri ile ilgili adımları otomatik olarak yeniden çalıştırılabilir hale gelmiştir.

Model Eğitimi ve Deney Takibi

Veri ön işleme tamamlandıktan sonra, makine öğrenmesi modeli eğitilmiştir. Projede temel algoritma olarak Random Forest sınıflandırıcısı kullanılmıştır. Model eğitim süreci, farklı yaklaşımları ve hiperparametreleri denemek amacıyla çeşitli deneyler şeklinde yürütülmüştür. Bu deneylerin amacı, problem için en iyi performansı sağlayacak model konfigürasyonunu belirlemektir. Tüm model eğitim ve değerlendirme süreçleri MLflow ile izlenmiş ve kaydedilmiştir. MLflow Tracking sayesinde, her bir deneyde kullanılan parametreler, elde edilen metrikler (accuracy, precision, recall, F1-score vb.) ve model artifaktları sistematik olarak saklanmıştır. DagsHub platformuna entegre MLflow sunucusu kullanılarak deney sonuçları merkezi bir arayüz üzerinden kolayca karşılaştırılabilmiştir (bkz. Şekil 3).

Deneyler sonucunda, eksik değerlerin ortalama ile doldurulduğu ve belirli hiperparametrelerle eğitilen Random Forest modeli, en başarılı performansı sergilemiştir. Bu modelin nihai metrikleri raporlanarak değerlendirme kısmı yapılmıştır.

DVC Pipeline Yönetimi

Projedeki veri işleme, model eğitimi ve değerlendirme gibi tüm adımlar, DVC kullanılarak otomatik bir pipeline halinde düzenlenmiştir. dvc.yaml dosyası, pipeline’ın farklı aşamalarını ve bu aşamalar arasındaki bağımlılıkları tanımlamaktadır. Bu yapı, projenin yeniden üretilebilirliğini (reproducibility) sağlamaktadır; yani aynı veri ve kod versiyonu kullanıldığında aynı sonuçlar elde edilebilmektedir.

Pipeline’ın temel aşamaları ve dvc.yaml içindeki bir örnek tanımı aşağıda gösterilmiştir:

• data_collection: Veri indirme
• pre_processing: Veri ön işleme
• model_building: Model eğitimi
• model_eval: Model değerlendirme
• model_registration: Model kayıt

1
2
3
4
5
6
7
8
9
stages:
  data_collection:
    cmd: python src/data/data_collection.py
    deps:
      - src/data/data_collection.py
    params:
      - data_collection.test_size
    outs:
      - data/raw

Code Block 1 dvc.yaml

Yukarıdaki örnekte görüldüğü gibi, her aşama çalıştırılacak komut, bağımlılıklar ve çıktılar ile tanımlanır. dvc repro komutu çalıştırılarak tüm pipeline uçtan uca yürütülebilmektedir. Pipeline adımlarının akışı Şekil 4’te görselleştirilmektedir.

Bu yapı sayesinde, herhangi bir adımdaki değişiklik (örneğin veri güncellemesi), sonraki bağımlı adımların otomatik olarak yeniden çalıştırılmasını sağlamaktadır.

CI/CD Entegrasyonu

Makine öğrenmesi pipeline’ını otomatikleştirmek ve sürekli güncel tutmak amacıyla GitHub Actions kullanılarak bir Sürekli Entegrasyon/Sürekli Dağıtım (CI/CD) pipeline’ı kurulmuştur. Bu pipeline, kod deposuna yapılan her push işleminde otomatik olarak tetiklenmektedir.

CI/CD pipeline’ının temel adımları /.github/workflows/ci.yaml dosyasında tanımlanmıştır ve şunları içermektedir:

• Kodun çekilmesi ve Python ortamının kurulması,
• Proje bağımlılıklarının yüklenmesi,
• DVC pipeline’ının (dvc repro) çalıştırılarak veri ön işleme, model eğitimi ve değerlendirme adımlarının yürütülmesi,
• Modelin doğruluğunu kontrol eden birim testlerinin çalıştırılması,
• Testler başarılı olduğunda, en iyi modelin MLflow Model Registry’de Production aşamasına otomatik olarak terfi ettirilmesi,
• Güncel modelin bulunduğu bir Docker imajının oluşturulması ve bir container registry’ye (bu örnekte Docker Hub) push edilmesidir.

ci.yaml dosyasının içeriği aşağıda özetlenmiştir:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
name: CI pipeline
on: push
 
jobs:
  project-testing:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
 
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
 
      - name: Install dependencies
        run: |
          pip install --upgrade pip
          pip install -r requirements.txt
          pip install dvc
 
      - name: Run DVC pipeline
        env:
          DAGSHUB_TOKEN: $
        run: |
          dvc repro
 
      - name: Run model tests
        env:
          DAGSHUB_TOKEN: $
        run: |
          python -m unittest tests/model_test.py
 
      - name: Promote model to production
        if: success()
        env:
          DAGSHUB_TOKEN: $
        run: python scripts/production.py
 
      - name: Log in to DockerHub
        uses: docker/login-action@v2
        with:
          username: $
          password: $
 
      - name: Build Docker Image
        if: $
        run: |
          docker build -t fcozer/mlops_project:latest .
 
      - name: Push Docker Image
        if: $
        run: |
          docker push fcozer/mlops_project:latest

Bu otomatik pipeline sayesinde, kod değişiklikleri sonrasında modelin güncellenmesi, test edilmesi ve üretime alınması süreçleri manuel müdahale olmadan, hızlı ve güvenilir bir şekilde gerçekleştirilmektedir. CI pipeline koşularının durumları GitHub arayüzünden takip edilebilmektedir (bkz. Şekil 5).

Testlerin başarılı olması, modelin kalitesinin korunması açısından kritik öneme sahiptir. Tüm adımların başarıyla tamamlanmasının ardından güncel model içeren Docker imajı oluşturulup Docker Hub’a gönderilmektedir (bkz. Şekil 6).

Bu Docker imajı, FastAPI tabanlı bir web servisi içermekte ve modelin kolayca dağıtılmasına olanak tanımaktadır (bkz. Şekil 7).

Bu entegre CI/CD pipeline’ı, projenin sürekli olarak güncel ve dağıtıma hazır olmasını sağlamaktadır.

Makine öğrenimi projelerinde sadece model geliştirmek değil, geliştirdiğimiz modelin güvenli ve sürdürülebilir bir şekilde üretime aktarılabilmesi de kritik bir adımdır. Bu bağlamda, oluşturduğumuz CI/CD pipeline’ının sadece kod entegrasyonu ve model deploy işlemlerini otomatikleştirmesi değil, aynı zamanda otomatik test süreçleri ile kalite güvenceyi sağlaması da büyük önem taşımaktadır.

Test Stratejisinin Temel Hedefleri

• Modelin Doğruluğundan Emin Olmak: Güncellemeler sonrasında model performansında beklenmedik düşüşlerin olup olmadığını kontrol etmek.
• Kod Bütünlüğünü Koruma: Yapılan kod değişikliklerinin mevcut pipeline’a zarar vermediğinden emin olmak.
• Hızlı Hata Tespiti: Sorunları erken aşamada yakalayarak, daha büyük arızaların önüne geçmek.

Uygulanan Test Katmanları

• Birim Testleri (Unit Tests)
  • Model fonksiyonlarının (eğitim, ön işleme, tahmin vs.) doğru çalıştığından emin olunur.
  • unittest modülü kullanılarak, her fonksiyonun doğru input aldığında beklenen çıktıyı ürettiği test edilir.
• Model Doğrulama Testleri (Model Validation Tests)
  • Modelin belirli bir minimum performans eşik değerini (accuracy > %65 gibi) sağladığı test edilir.
  • Performans, doğrulama (validation) seti üzerinden değerlendirilir ve önceden belirlenmiş metriklerle (accuracy, precision, recall, F1-score) ölçülür.
  • Threshold’un altında kalan modeller CI pipeline’ında otomatik olarak “fail” edilir.
• Kod Kapsamı (Coverage) Ölçümü
  • coverage.py gibi bir araç ile yazılan kodun yüzde kaçının test edildiği raporlanır.
  • Pipeline çalışırken coverage raporu oluşturulur ve %80’in altında coverage varsa build başarısız sayılabilir.
• Veri Kalitesi Testleri (Data Validation Tests)
  • Güncellenen veri setinin belirli kurallara (eksik veri oranı, aykırı değer kontrolü gibi) uyup uymadığı test edilir.
  • Örneğin; numeric kolonlarda “NaN” sayısı belli bir limitin üstündeyse test başarısız olur.

CI/CD Pipeline’ında Test Adımları

CI pipeline dosyamız olan ci.yaml içinde test adımları aşağıdaki şekilde organize edilmiştir:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
name: Install dependencies 
run: |	
 pip install --upgrade pip 
 pip install -r requirements.txt 
 pip install dvc coverage

name: Run Unit Tests 
run: | 
 coverage run -m unittest discover tests/

name: Generate Coverage Report 
run: | 
 coverage report -m coverage html

Bu adımlar, kodun hem doğrulugunu test eder hem de hangi kısımların test edilmediğini detaylı şekilde raporlar.

Makine öğrenmesi modelleri üretim ortamına alındıktan sonra, zamanla gelen yeni verilerin dağılımı eğitim verisinden sapabilir; bu duruma veri kayması (drift) veya model kayması denir ve modelin performansının fark edilmeden düşmesine neden olabilir. Bu nedenle, MLOps (Makine Öğrenimi Operasyonları) süreçlerinde yalnızca modeli dağıtmak değil, aynı zamanda performansını sürekli olarak izlemek büyük önem taşır. Kayma tespit mekanizmaları (drift detection), üretimdeki modelin karşılaştığı verilerin istatistiksel özelliklerini (ortalama, varyans, dağılım gibi) eğitim verisiyle karşılaştırarak anlamlı bir sapma olup olmadığını değerlendirir; bu değerlendirme sonucunda belirlenen eşiklerin aşılması durumunda uyarılar tetiklenebilir veya yeniden eğitim süreci otomatik olarak başlatılabilir. Bu yapı, modelin sahada uzun vadeli başarısını garanti altına alarak, üretimde kalıcılığını ve güvenilirliğini artırır.

5. Sonuçlar ve Özet Değerlendirme

En iyi model belirlendikten ve CI pipeline tarafından Production aşamasına alındıktan sonra, modelin gerçek kullanıma yönelik dağıtımına ve performansının izlenmesine geçilmiştir. MLflow Model Registry, üretime alınan modelin versiyon bilgisini ve geçmişini tutarak bu adımda önemli bir rol oynamıştır. Bu projede “Best Model” adıyla kaydedilen model, ilk olarak Staging evresine alınmış, CI üzerindeki testlerin başarıyla geçmesiyle otomatik olarak Production evresine terfi ettirilmiştir. MLflow Model Registry arayüzünde artık bu modelin bir Version 5 olarak Production’da olduğu görülmektedir (bkz. Şekil 8). Eğer ileride daha iyi bir model elde edilirse, o model Version 6 olarak kaydedilecek ve uygun görüldüğünde Production’a geçirilecektir. MLflow Registry, eski model versiyonunu otomatik olarak Archived durumuna alarak geçmiş kayıtların saklanmasını sağlamaktadır. Bu sayede, üretimde hangi modelin ne zaman kullanıldığı, hangi metrik değerlere sahip olduğu gibi bilgiler geriye dönük olarak izlenebilir. Model Registry kullanımı, makine öğrenimi modelinin yaşam döngüsü yönetimini kolaylaştırır; ekipler arası iletişimde “hangi model üretimde” sorusu net bir şekilde yanıt bulmaktadır.

Modelin Servise Alınması: Production aşamasındaki modeli gerçek zamanlı olarak kullanmak için bir FastAPI uygulaması geliştirilmiştir. Bu uygulama, eğitim aşamasında elde edilen en iyi modeli yükleyip bir HTTP API üzerinden tahmin yapmaya imkan tanımaktadır. CI/CD süreci sonunda Docker Hub’a gönderilen imaj, bu FastAPI uygulamasını içerdığından model dağıtımı oldukça basit hale gelmiştir. Bir sunucuda veya bulut ortamında Docker imajı çalıştırılarak API servisi ayağa kaldırılır. Örneğin: docker run -p 8000:8000 fcozer/mlops_project:latest komutuyla konteyner başlatıldığında, port 8000 üzerinden istek kabul eden bir web servisi devreye girecektir. Bu servis, girdi olarak suyun ölçüm değerlerini alıp çıktı olarak potability (içilebilirlik) tahmini dönmektedir.

Sonuçların Değerlendirilmesi: Projenin sonunda seçilen modelin metrikleri tatmin edici bulunmuştur ancak iyileştirme potansiyeli de mevcuttur. Accuracy yaklaşık %68.9, precision ~%65.6 seviyesinde olsa da recall değerinin ~%34.4 gibi nispeten düşük olması, modelin bazı içilemez su örneklerini tespit etmekte zorlanabildiğine işaret etmektedir. Bu durum, veri dengesizliğinden (içilebilir vs. içilemez örnek sayısı farkı) kaynaklanıyor olabilir. İleride veri setini genişletmek veya farklı özellikler eklemek recall değerini yükseltebilir. Öte yandan precision değerinin göreceli yüksek olması, modelin içilemez dediği örneklerde genellikle haklı çıktığını gösterir ki bu kritik bir özelliktir (yanlış alarm oranı düşüktür). Genel F1 skoru ~0.451 olup, modelin overall performansı orta seviyededir (bkz. Şekil 9).

Model başarı değerlendirmesinde, baseline model ile kıyaslandığında elde edilen iyileşme önemlidir. Baseline olarak median imputation + RF modeli alırsak, bu modelin metrikleri (accuracy ~%68 civarı) final modele göre daha düşüktü. Ayrıca alternatif algoritmalar (lojistik regresyon gibi) daha düşük performans göstermiştir (bkz. Şekil 10) (ör. accuracy ~%63). Dolayısıyla yapılan iyileştirmeler (mean imputation ve hiperparametre optimizasyonu) modele birkaç puanlık bir kazanım sağlamıştır. Bu kazanım, su potability problemi gibi zorlayıcı ve bazı özelliklerin hedefi açıklama gücünün sınırlı olduğu bir problemde anlamlıdır.

Sonuç olarak, bu raporda ele alınan MLOps süreci sayesinde veri toplamadan model dağıtımına kadarki adımlar otomatik, izlenebilir ve versiyon kontrollü bir şekilde gerçekleştirilmiştir. DVC ile veri ve model dosyalarının geçmişi yönetilmiş, MLflow ile deneyler ve model versiyonları kayıt altına alınmış, CI/CD ile de güvenilir bir şekilde en iyi modelin üretime geçirilmesi sağlanmıştır. Bu entegre yaklaşım, makine öğrenimi projesinin tutarlılığını korumasını ve ekip içerisinde kolayca paylaşılabilir, tekrarlanabilir olmasını mümkün kılmıştır.

Katkı Veren

Bu yazının araştırma, geliştirme ve yazım süreçlerine değerli katkılar sağlayan Alper SOLMAZ, Ayşegül ÖZKAYA EREN, Furkan Can ÖZER, Oğuzhan Uğur SARISAKALOĞLU ve Sedat YILMAZ’a; teknik gözden geçirmesi için Güler Alparslan’a; editör desteği için ise Kübra Ertürk’e teşekkür ederiz.

6. Kaynakça

[1] P. Canuma, “MLOps: What It Is, Why It Matters, and How to Implement It,” Neptune Blog , Mart 14, 2025. [Online]. Erişim Zamanı: Nisan 25, 2025.

[2] MLOps Nedir?, Erişim Adresi: https://www.veribilimiokulu.com/mlops-nedir/, Erişim Zamanı: Nisan 25, 2025.

[3] Phdata, MLOps yaşam döngüsü şekil 1, https://www.phdata.io/blog/mlops-vs-devops-whats-the-difference/ Erişim Zamanı: Nisan 20, 2025.

[4] “The Complete Guide to Data Version Control With DVC,” DataCamp , Temmuz 14, 2024. [Online]. Erişim Zamanı: Nisan 25, 2025.

[5] M. Zaharia vd., “Accelerating the Machine Learning Lifecycle with MLflow,” IEEE Data Engineering Bulletin , cilt 41, sayı 4, s. 7, Aralık 2018. [Online]. Available: https://people.eecs.berkeley.edu/~matei/papers/2018/ieee_mlflow.pdf. Erişim Zamanı: Nisan 25, 2025.

[6] W. J. Leelakiatiwong, “A Brief Introduction to DagsHub for Beginners,” Medium , Nisan 8, 2023. [Online]. Erişim Zamanı: Nisan 25, 2025.

[7] S. Arbeit, “Streamlining your MLOps pipeline with GitHub Actions and Arm64 runners,” The GitHub Blog , Eylül 11, 2024. [Online]. Erişim Zamanı: Nisan 25, 2025.

[8] Kaggle, Water Quality and Potability Dataset, URL: https://www.kaggle.com/datasets/uom190346a/water-quality-and-potability Erişim Zamanı: Ocak 12, 2025.

[9] MLfow, https://mlflow.org/, Erişim Zamanı: 22 Nisan 2025.