Makine Öğrenmesinde Pipeline Mimarisi Nedir?
Sizin hiç botu hattınız oldu mu? Belki fiziksel olarak A noktasından B noktasına erişen bir boru hattınız olmadı ancak dijital olarak web servisler veya API’ler inşa edebilirsiniz.
Bu yazımda makine öğrenmesinde pipeline (boru hattı) konusunu enine boyuna irdelemeye çalışacağım.
Az buçuk veri bilimi ve makine öğrenmesi hakkında fikir sahibi olduğunuzu düşünerek yazıya devam edeceğim.
Bildiğiniz üzere makine öğrenmesinde bir çok farklı aşama mevcut. İşte veri hazırlığı, verinin yıkanması, verinin durulanması, modelleme, modellerin kurutulması vs. Sesli düşünelim veriyi aldık biraz işledik. Gerekesiz kolonları ve satırları ayıkladık missing value’ları doldurduk. Ardından modelledik. Aaa süper bir Random Forrest algoritması ile train üzerinden %95 ve test üzerinden %94 doğruluk oranımız da oldu. Oldu da, ne oldu? Bitti mi? Bu kadar mıydı veri bilimi? hani yapay zeka bizi ele geçirecekti?
İster bir şirkette makine öğrenmesi (ML) projesi geliştirin ya da kendiniz bir ML ürünü yaratın ne yazık ki süreç kitaplarda yazdığı kadar kısa değil. Belki işin veri bilimi kısmı bitti ancak aslında ML projesi daha yeni başlıyor.
Piyasada gördüğümüz veya eğitimlerden öğrendiğiniz veri temizliği, hiperparametre testleri, algoritma değerlendirmesi vb. konular yukarıda gördüğünüz ML proje döngüsünün içerisinde yer alan siyah kutu (Model) içerisindeki bölümü kaplamaktadır. Bunu ben demiyorum Google Developers böyle söylüyor.
Yani biz modeli kurduk sonucu elde ettik diye bir dünya yok. Nedeni aşağıdaki sorularımda:
- Yeni veriler gelince napcaz aga?
- Yeni verilerde ya sonuçlar değişirse?
- Yeni gelen her veri için manuel kontrol mü yapcaz başkan?
- Hanım hanım bunu önceki model sonuçları ile nasıl karşılaştırıcaz?
- Retrain diye bir mevzu varmış…
- Aynı süreçleri tek tek elle çalıştırmak çok zamanımızı almaz mı?
- Ya abi bunu anlık (real time) olarak nasıl çalıştırıcaz. Ama batch’de lazım olabilir.
- Veri temizliği esnasında kullandığım kodları nasıl tekrar tekrar kullanabilirim acep?
- Ya test, debug, log, API falan diyorlar modelimle ne alakası var bunların ya?
- Versiyon kontrol denen bir nane varmış. Ya bi GIT (Git bir açık kaynak versiyon kontrol sistemidir. Bkz: GITHUB).
Bildiğinizi varsaydığım üzere gerçek dünyada gerçek ihtiyaçların net yapısal bir formülü bulunmuyor. Yani tüm veri setleri IRIS gibi değil. Bir de model konusu var tabi… Her kurulan model sabit kalacak diye bir durum söz konusu değil. Bazen manuel bakarak modellenmemesi gereken durumları ayıklamamız gerekebilir.
Kısacası dünyada hala standartlaşmış bir ML ürünü yok ki kasap gibi versin eti alsın kıymayı. Bu yüzden ML projeleri dataya veya organizasyonun olduğu yapıya göre değişiklik gösterir. Ancak hem yazılım hem de veri bilimini ortaklaştıran bu projelerde tüm yüzüklerin güçlerinden faydalanmamız gerekiyor. Lafı fazla dolandırmadan hemen söze girelim.
Pipeline felsefesi ile geliştirdiğimiz ML projesindeki her bir adım modüler bir hale getirilerek yeniden ve yeniden kullanılması sağlanır.
- Verinin Alınması
- Verinin Hazırlanması
- Modelleme
- Deployment (yaygınlaştırma)
Basitçe bu dört aşama için bir pipeline kurduğumuz kodumuzu dört farklı modül halinde düşünüp bu modüllerin aralarına bir boru hattı döşeyebilirsiniz. Böylece istediğiniz modülü dilediğiniz zaman çağırıp kullanabilirsiniz. Hatta mikro servis (microservice) felsefesinde olduğu gibi hiç bir modülünüz (paket) bozulmadan diğerleri için geliştirme yapabilirsiniz. Aşağıda kısa kısa ML projesinde pipeline içerisinde olmazsa olmaz bazı işlevleri yazıyorum.
- Tüm modüller/paketler için test kodları yazılmalıdır.
- Her süreç işletildiğinde bir log dosyasına istenilen ayrıntılar yazılmalıdır. Örneğin hiper parametre sonuçları. Değişen katsayılar
- Verinin kalitesi ve doğruluğu geçmişe yönelik olarak özetler halinde bir tabloda tutulmalıdır. Bu tablo pipeline her çalıştığında anomali tespiti için yeniden incelenmeli hatta standart sapma dışında veya önemli düşüşlerde alarm mekanizması kurulmalıdır.
- Pipeline’nın herhangi bir evresinde veya önemli çıktılarda geliştiriciyi uyaran bildirim sistemleri tasarlanmalıdır.
- Modellerin sonuçları her seferinde bir tabloya aktarılmalı ve bu tablo bir rapor haline getirilerek otomatik olarak geliştiriciye görünmelidir.
- Hatta model sonuçları için her hangi bir sıkıntı olması durumunda örneğin doğruluk oranının çok düşmesi ya da artması esnasında buna +/-2 standart sapma ile sisteme otomatik baktırabilirsiniz. Bildirim ile sistem geliştiriciyi uyarabilir.
Sonuç
Aslında yukarıdaki maddelere daha fazlası eklenebilir lakin her proje, o işe özgü kendi sorun ve fırsatları ile geldiği için çok farklı durumlar ortaya çıkabilmektedir. Dolayısı ile düşünülmesi gereken olgular ML projesi için beni ne sıkıntıya sokabilir? Süreçlerimi nasıl otomatize edebilirim? Kök sistemde veri bilimi modelleri inşa edilse bile işin otomatize edilme tarafında hep bir yazılımcı kafasıyla düşünüp iş analisti gözüyle projeye yaklaşmanız gerekiyor. Yani gayet eğlenceli.
