MLOps Hakkında En Ayrıntılı Kılavuz: Bölüm 1

Merhaba Hackernoon! Bu yazımda MLOps kavramını detaylı bir şekilde ele alacağım. Üstelik bunu 3 şekilde yapacağım. İlk olarak teorik olarak en mantıklı MLOps şeması aracılığıyla. Daha sonra kavramsal olarak yaklaşıma gömülü olan eserler aracılığıyla. Ve son olarak MLOps'u bir bilgi sistemi olarak anlayarak.

Haydi başlayalım.

MLOps nedir?

Bu soru uzun süredir birçok ML sistem geliştirme ekibinin aklını meşgul ediyor. Bu makalede böyle bir sistemden, bir veya daha fazla bileşeninin genel iş mantığının bir kısmını gerçekleştiren eğitimli bir model içeren bir bilgi sistemini anlayacağım.

Sistemin diğer bileşenleri gibi iş mantığının bu bölümünün de değişen iş ve müşteri beklentilerini karşılayacak şekilde güncellenmesi gerekir. MLOps tamamen bu düzenli güncellemeyle ilgilidir.

MLOps tanımı ve açıklaması

MLOps'un henüz tek ve kabul edilmiş bir tanımı yoktur. Pek çok yazar bunu vermeye çalıştı ancak aynı zamanda açık ve sistematik bir tanım bulmak da zorlayıcıydı.

Şöyle sayılabilecek bir tane var:

MLOps, üretimde yüksek performanslı modellerin sürekli sunumunu standartlaştırmak ve kolaylaştırmak için ML sistem geliştirmeyi (geliştirme) ve ML sistem dağıtımını (ops) birleştirmeyi amaçlayan bir mühendislik disiplinidir.

MLOps tanımının kritik kısımlarını vurgulayalım:

• Mühendislik disiplini
• ML sistemlerinin geliştirme ve dağıtım süreçlerini birleştirmeyi amaçlar
• Yeni sürümlerin sürekli teslimini standartlaştırır ve optimize eder
• Yüksek performanslı modeller

Yani MLOps, ML modelleri için bir tür DevOps'tur.

MLOps'un ortaya çıkışının tarihi

Böyle bir mühendislik disiplininin büyük bir BT şirketinden kaynaklandığına inanmak kolaydır. Dolayısıyla, MLOps'un anlamlı bir yaklaşım olarak Google'dan kaynaklandığı teorisine güvenebiliriz; burada D. Sculley, sinirlerini ve zamanını makine öğrenimi modellerinin çıktısını uzantılara aktarma konusundaki sıradan görevlerden kurtarmaya çalışıyordu. D. Sculley artık yaygın olarak "MLOps'un Vaftiz Babası" olarak biliniyor - aynı isimli podcast'i internette bulmak çok kolay.

D. Sculley, modellerle çalışmayı ekibin teknik borcu açısından değerlendirmeye başladı. Evet, modellerin yeni versiyonlarını hızlı bir şekilde piyasaya sürmek mümkün ancak ortaya çıkan sistemi desteklemenin maliyeti şirketin bütçesi üzerinde önemli bir etkiye sahip olacak.

Çalışması gazeteyle sonuçlandı "Makine Öğrenimi Sistemlerinde Gizli Teknik Borç " 2015 yılında NeurIPS konferansında yayınlandı. Bu makalenin yayınlanma tarihi, MLOps'un varlığının başlangıç noktası olarak kabul edilebilir.

MLOps olgunluk seviyeleri: en iyi bilinen modeller

Çoğu BT süreci gibi MLOps'un da olgunluk seviyeleri vardır. Şirketlerin şu anda nerede olduklarını ve bir sonraki aşamaya nasıl geçebileceklerini (eğer böyle bir hedef varsa) anlamalarına yardımcı olurlar. Ayrıca genel kabul görmüş vade belirleme yöntemleri, rakipler arasındaki yerinizi belirlemenize olanak tanır.

GigaOm MLOps olgunluk modeli

En kapsamlı şekilde açıklanan ve büyük ölçüde anlaşılır model, analiz firması GigaOm'a aittir. Tüm modellerin Yetenek Olgunluk Modeli Entegrasyonuna (CMMI) en yakın olanıdır. Bu, aynı zamanda 0'dan 4'e kadar 5 seviyeden oluşan organizasyonel süreçlerin iyileştirilmesine yönelik bir dizi metodolojidir.

GigaOm'un modeli, her bir olgunluk düzeyini 5 kategori aracılığıyla ortaya çıkarır: strateji, mimari, modelleme, süreçler ve yönetişim.

Bir makine öğrenimi sistemi oluşturmanın ilk aşamalarında bu modelin rehberliğinde, temel hususlar hakkında önceden düşünebilir ve başarısızlık olasılığını azaltabilirsiniz. Bir olgunluk seviyesinden daha yüksek bir olgunluğa geçiş, ekibe daha önce varlığından haberdar olmadıkları yeni zorluklar sunar.

Google MLOps olgunluk modeli

Google'ın aynı zamanda MLOps olgunluk düzeyleri modeline de sahip olduğunu belirtmekte fayda var. İlk ortaya çıkanlardan biriydi. Kısadır ve 3 seviyeden oluşur:

• Seviye 0: Manuel süreç
• Seviye 1: Makine öğrenimi ardışık düzeni otomasyonu
• Seviye 2: CI/CD işlem hattı otomasyonu

Bu modelin baykuş boyamanın kullanım kılavuzuna benzediği düşüncesinden kaçmak zor. Öncelikle her şeyi elle yapın, ML işlem hatlarını birleştirin ve MLOps'u sonlandırın. Bununla birlikte, iyi tanımlanmış.

Azure MLOps olgunluk modeli

Bugün ML kullanan birçok büyük şirket olgunluk modellerini derledi. Azure Düzeyleri ayırt etmek için benzer bir yaklaşım kullanan , dahil edilmiştir. Ancak Google'ınkinden daha fazlası var:

• Seviye 0: MLOps yok
• Seviye 1: DevOps ancak MLOps yok
• Seviye 2: Otomatik Eğitim
• Seviye 3: Otomatik Model Dağıtımı
• Seviye 4: Tam MLOps Otomatik İşlemler

Vurgulanan tüm modeller yaklaşık olarak tek bir noktada birleşiyor. Sıfır seviyesinde herhangi bir makine öğrenimi uygulamasının bulunmaması söz konusudur. Son aşamada MLOps süreçlerinin otomasyonuna sahiptirler. Artımlı süreç otomasyonuyla ilgili olarak ortada her zaman farklı bir şey vardır. Azure, eğitim sürecinin otomasyonuna ve ardından model dağıtımına sahiptir.

MLOps Kavramsal Çerçevesi

MLOps kavramıyla ilgili tüm süreçleri nasıl tanımlıyorsunuz? Şaşırtıcı bir şekilde, üç Alman - makalenin yazarları " Makine Öğrenimi İşlemleri (MLOps): Genel Bakış, Tanım ve Mimari " - hatta bunları tek bir diyagramda özetlemeyi başardılar. Gerçek bir çalışma yürüttüler ve MLOps kavramını çok detaylı bir şekilde anlattılar.

Birbiriyle etkileşim halinde olan birçok unsur olduğundan korkutucu olabilir. Ancak yukarıda bahsedilen olgunluk seviyelerinin birçok özelliği onda da bulunabilir. En azından otomatikleştirilmiş İşlem Hatları, CI/CD, İzleme, Model Kaydı, İş Akışı Düzenleme ve Hizmet Bileşeni.

Bu diyagramı tartışalım ve her biri hakkında daha ayrıntılı olarak konuşalım.

MLOps Temel Süreçleri

Şemanın ana bölümleri, MLOps'un prosedürel yönlerinin tanımlandığı yatay bloklardır (bunlara A, B, C ve D harfleri atanır). Her biri, şirketin ML hizmetlerinin sorunsuz çalışmasını sağlama çerçevesinde belirli görevleri çözmek için tasarlanmıştır. Şemayı anlama kolaylığı için sıra dışı başlamak daha iyidir.

deneme

Bir şirketin ML hizmetleri varsa çalışanlar Jupyter'da çalışır. Birçok şirkette bu, tüm ML geliştirme süreçlerinin merkeze alındığı araçtır. MLOps uygulamalarının uygulanmasını gerektiren görevlerin çoğunun başladığı yer burasıdır.

Bir örnek düşünelim. A Şirketinin bazı süreçlerin bir kısmını makine öğrenimini kullanarak otomatikleştirmesi gerekiyor (ilgili bir departman ve uzmanların olduğunu varsayalım). Görevi çözme yolunun önceden bilinmesi pek olası değildir. Bu nedenle, uygulayıcıların problem bildirimini incelemesi ve onu gerçekleştirmenin olası yollarını test etmesi gerekir.

Bunu yapmak için bir ML mühendisi/ML geliştiricisi, çeşitli görev uygulamalarına yönelik kod yazar ve elde edilen sonuçları hedef metriklerle değerlendirir. Bütün bunlar neredeyse her zaman Jupyter Laboratuvarında yapılır. Böyle bir formda birçok önemli bilgiyi manuel olarak yakalamak ve ardından uygulamaları kendi aralarında karşılaştırmak gerekir.

Bu tür faaliyetlere deney denir. Bu, ilgili sorunları çözmek için daha sonra kullanılabilecek, çalışan bir makine öğrenimi modelinin elde edilmesi anlamına gelir.

Diyagramda gösterilen Blok C, ML deneylerini yürütme sürecini açıklamaktadır.

Görev kapsamında mevcut verilerin analiz edilmesi

ML geliştirmedeki birçok karar, şirketteki mevcut verilerin analizine dayanarak alınır. Hedef kalite metrikleri olan bir modeli, düşük kaliteli veriler veya var olmayan veriler üzerinde eğitmek mümkün değildir.

Bu nedenle hangi verileri elde ettiğimizi ve bunlarla neler yapabileceğimizi anlamak önemlidir. Bunu yapmak için örneğin şunları yapabiliriz:

• Jupyter veya Superset kullanarak bir ADHoc çalışması yürütün
• Standart EDA (Keşif Amaçlı Veri Analizi)

Verilerin daha iyi anlaşılması ancak anlamsal ve yapısal analizle birleştirildiğinde elde edilebilir.

Ancak bazen veri hazırlığı proje ekibinin kontrolünde olur. Bu durumda ek zorluklar garanti edilir. Bazen bu aşamada, veriler çalışmaya uygun olmadığı için projeyi daha da geliştirmenin bir anlamı olmadığı ortaya çıkıyor.

Kaliteli bir veri kümesinin oluşturulması

Mevcut verilere güven duyulduğunda ön işleme kurallarını düşünmek gerekir. Uygun verilerden oluşan geniş bir set olsa bile, bunların eksiklikler, çarpık değerler vb. içermediğinin garantisi yoktur. "Giriş veri kalitesi" teriminden ve iyi bilinen "Çöp girişi - çöp çıkışı" tabirinden bahsetmek gerekir. Burada.

Bir model ne kadar iyi kullanılırsa kullanılsın, düşük kaliteli veriler üzerinde kötü sonuçlar üretecektir. Uygulamada birçok proje kaynağı yüksek kaliteli bir veri kümesi oluşturmaya harcanmaktadır.

ML modeli eğitimi ve doğrulaması

Bir önceki aşamadan sonra deneyler yapılırken eğitilen modelin metriklerinin dikkate alınması mantıklıdır. Söz konusu blok çerçevesinde deney, ML modelinin eğitimi ve doğrulanmasının ilişkilendirilmesinden oluşur.

Deney, hazırlanan veri seti üzerinde seçilen hiperparametre seti ile modelin istenen versiyonunun eğitiminin klasik şemasından oluşur. Bu amaçla veri kümesinin kendisi eğitim, test ve doğrulama örneklerine bölünmüştür:

• İlk ikisi optimal hiperparametre setini seçmek için kullanılır
• Üçüncüsü, seçilen hiperparametre seti üzerinde eğitilen modelin, hiperparametre seçimi ve eğitimi sürecine katılmayan bilinmeyen veriler üzerinde yeterince davrandığının nihai doğrulaması ve onayıdır.

Doğrulama örnekleri hakkında daha fazla bilgiyi şurada bulabilirsiniz: Bu makale .

Kodu ve hiperparametreleri bir depoya kaydetme

Model öğrenme metrikleri iyiyse model kodu ve seçilen parametreler kurumsal bir depoda saklanır.

Deney sürecinin temel amacı, en iyi algoritma seçiminin ve en iyi hiperparametre ayarının seçilmesini içeren model mühendisliğidir.

Deney yürütmenin zorluğu, geliştiricinin ML modeli operasyon parametrelerinin birçok kombinasyonunu kontrol etmesi gerekmesidir. Ve kullanılan matematiksel aparatların farklı varyantlarından bahsetmiyoruz.

Genel olarak çalışma gerektirir. Peki model parametrelerinin kombinasyonları çerçevesinde istenilen metriklere ulaşılamazsa ne yapmalı?

Özellik mühendisliği

ML modeli işleminin istenen metrikleri elde edilemiyorsa, veri kümesi nesnelerinin özellik açıklamasını yeni özelliklerle genişletmeyi deneyebilirsiniz. Bunlar sayesinde modelin bağlamı genişleyecek ve dolayısıyla istenilen metrikler iyileşebilecektir.

Yeni özellikler şunları içerebilir:

• Tablo verileri için: halihazırda var olan nesne niteliklerinin keyfi dönüşümleri - örneğin, X^2, SQRT(X), Log(x), X1*X2, vb.
• Konu alanına göre: vücut kitle indeksi, bir yıl içinde vadesi geçmiş kredi ödemelerinin sayısı vb.

Diyagramın Özellik Mühendisliği ile ilgili kısmına bakalım.

Blok B1, mevcut kaynak verilerinin dönüştürülmesi ve onlardan özellikler elde edilmesi için bir dizi gereksinim oluşturmayı amaçlamaktadır. Bileşenlerin hesaplanması, ML geliştiricisi tarafından girilen "formüllere" göre çok önceden işlenmiş ve temizlenmiş bu verilerden gerçekleştirilir.

Özelliklerle çalışmanın yinelemeli olduğunu söylemek önemlidir. Bir dizi özellik uygulandığında, başka bir özellik kümesinde hayata geçirilen yeni bir fikir akla gelebilir ve bu sonsuza kadar böyle devam eder. Bu, diyagramda açıkça bir Geribildirim Döngüsü olarak gösterilmiştir.

Blok B2, verilere yeni özellikler eklemenin anında sürecini açıklar.

Veri kaynaklarına bağlanmak ve bunları almak oldukça karmaşık olabilen teknik işlemlerdir. Açıklamanın basit olması açısından, ekibin erişebildiği birkaç kaynak ve bu kaynaklardan verileri kaldırmak için araçlar (en azından Python komut dosyaları) olduğunu varsayacağım.

Veri temizleme ve dönüştürme. Bu aşama neredeyse deney bloğundaki (C) veri hazırlamadaki benzer adımı destekler. Zaten ilk deneylerin setinde, ML modellerini eğitmek için hangi verilere ve hangi formatta ihtiyaç duyulduğuna dair bir anlayış var. Geriye yeni özelliklerin doğru bir şekilde oluşturulup test edilmesi kalıyor ancak bu amaca yönelik veri hazırlama sürecinin mümkün olduğunca otomatikleştirilmesi gerekiyor.

Yeni özelliklerin hesaplanması. Yukarıda belirtildiği gibi, bu eylemler bir veri kümesinin birkaç öğesinin basitçe dönüştürülmesinden oluşabilir. Diğer bir seçenek de aynı veri kümesine tek bir özellik eklemek için ayrı bir büyük işleme hattı çalıştırmaktır. Her iki durumda da, sırayla yürütülen bir dizi eylem vardır.

Sonuç ekleniyor. Önceki eylemlerin sonucu veri kümesine eklenir. Çoğu zaman, veritabanı yükünü azaltmak için özellikler veri kümesine toplu olarak eklenir. Ancak bazen iş görevlerinin yürütülmesini hızlandırmak için bunu anında (akış) yapmak gerekir.

Elde edilen özellikleri mümkün olduğunca verimli kullanmak çok önemlidir: bunları kaydedin ve şirketin diğer makine öğrenimi geliştiricilerinin görevlerinde yeniden kullanın. Şemanın bu amaç için bir Özellik mağazası vardır. Şirket içinde mevcut olmalı, ayrı olarak yönetilmeli ve içerdiği tüm özellikler sürümlendirilmelidir. Özellik deposunda 2 bölüm bulunur: çevrimiçi (akış komut dosyaları için) ve çevrimdışı (toplu komut dosyaları için).

Otomatik ML İş Akışı

Yazının başında ML sistemi derken, genel iş mantığının bir kısmını gerçekleştiren, bir veya daha fazla bileşeni eğitimli bir model içeren bir bilgi sistemini kastettiğimi belirtmiştim. Geliştirme nedeniyle elde edilen ML modeli ne kadar iyi olursa, işleyişinin etkisi de o kadar büyük olur. Eğitilmiş bir model, gelen talep akışını işler ve yanıt olarak bazı tahminler sağlar, böylece analiz veya karar verme sürecinin bazı bölümlerini otomatikleştirir.

Tahminler üretmek için bir model kullanma sürecine çıkarım, bir modeli eğitmeye ise eğitim denir. İkisi arasındaki farka ilişkin net bir açıklama Gartner'dan ödünç alınabilir. Burada kediler üzerinde pratik yapacağım.

Bir üretim ML sisteminin verimli çalışması için modelin çıkarım metriklerini takip etmek hayati önem taşır. Düşmeye başlar başlamaz model ya yeniden eğitilmeli ya da yenisiyle değiştirilmelidir. Çoğu zaman, giriş verilerindeki değişiklikler (veri kayması) nedeniyle olur. Örneğin, modelin fotoğraflardaki kekleri tanıyabildiği bir iş sorunu var ve bu ona girdi olarak veriliyor. Örnekteki Chihuahua köpekleri denge içindir:

Orijinal veri setindeki model Chihuahua köpekleri hakkında hiçbir şey bilmediğinden yanlış tahminde bulunuyor. Bu nedenle veri setini değiştirip yeni deneyler yapmak gerekiyor. Yeni modelin bir an önce üretime geçmesi gerekiyor. Hiç kimse kullanıcıların Chihuahua köpek görsellerini yüklemelerini yasaklamaz, ancak yanlış sonuçlar elde edeceklerdir.

Şimdi daha gerçek dünyadan örneklere geçelim. Bir pazar yeri için bir öneri sisteminin geliştirilmesini ele alalım.

Kullanıcının satın alma geçmişine, benzer kullanıcıların satın almalarına ve diğer parametrelere bağlı olarak bir model veya modeller topluluğu, öneriler içeren bir blok oluşturur. Satın alma gelirleri düzenli olarak sayılan ve takip edilen ürünleri içerir.

Bir şeyler olur ve müşterilerin ihtiyaçları değişir. Sonuç olarak, onların tavsiyeleri artık geçerli değildir. Önerilen ürünlere olan talep düşüyor. Bütün bunlar gelirin azalmasına yol açıyor.

Sonraki yöneticiler çığlık atıyor ve her şeyin yarına kadar onarılmasını talep ediyor, bu da hiçbir şeye yol açmıyor. Neden? Yeni müşteri tercihleriyle ilgili yeterli veri yok, dolayısıyla yeni bir model bile yapamıyorsunuz. Öneri oluşturmanın bazı temel algoritmalarını (öğe tabanlı işbirlikçi filtreleme) alıp bunları üretime ekleyebilirsiniz. Bu şekilde öneriler bir şekilde işe yarayacaktır ancak bu yalnızca geçici bir çözümdür.

İdeal olarak süreç, yöneticilerin onlara bunu yapmasını söylemeden, metriklere dayalı olarak yeniden eğitim veya farklı modellerle deneme süreci başlatılacak şekilde kurulmalıdır. Ve en iyisi, sonunda üretimdeki mevcut olanın yerini alacaktı. Diyagramda bu, bazı düzenleme araçlarındaki tetikleyiciler tarafından başlatılan Otomatik ML İş Akışı Ardışık Düzenidir (blok D).

Bu, planın en ağır yüklü bölümüdür. D bloğunun işleyişinde birkaç önemli üçüncü taraf bileşeni yer almaktadır:

• İşlem hattını belirli bir zamanlama veya etkinlikte başlatmaktan sorumlu olan iş akışı orkestratörü bileşeni
• Model için gerekli özelliklere ilişkin verilerin alındığı Özellik Mağazası
• Başlatılan Pipeline'ın çalışmasından sonra elde edilen modellerin ve metriklerinin yerleştirildiği Model Kaydı ve ML meta veri deposu

Bloğun yapısı, deneme ve özellik geliştirme (B2) bloklarının aşamalarını birleştirir. Bunların otomatikleştirilmesi gereken süreçler olduğu düşünüldüğünde bu şaşırtıcı değil. Temel farklar son 2 aşamadadır:

• İhracat modeli
• Model kaydına gönder

Geri kalan adımlar yukarıda açıklananlarla aynıdır.

Ayrı olarak, orkestratörün model yeniden eğitim işlem hatlarını çalıştırması için ihtiyaç duyduğu hizmet yapıtlarından bahsetmek istiyorum. Bu, depoda saklanan ve seçilen sunucularda çalışan koddur. Yazılım geliştirmenin tüm kurallarına uygun olarak versiyonlanır ve yükseltilir. Bu kod, modelin yeniden eğitim işlem hatlarını uygular ve sonuç, doğruluğuna bağlıdır.

Çoğu zaman, kodun içinde ardışık düzen adımlarının yürütüldüğü çeşitli makine öğrenimi araçları çalıştırılır, örneğin:

• Hava akışı orkestratörü, boru hatlarının aşamalarını yürütmek için kodu çalıştırır
• Feast, veri kümesindeki özelliklerle ilgili verileri komutla kaldırır
• Ardından ClearML yeni bir veri kümesi oluşturur ve kendi deposundan aldığı gerekli model performans ölçümleri kümesiyle bir deneme çalıştırır.
• İnceleme tamamlandıktan sonra ClearML, modeli ve performans ölçümlerini depolamaya kaydeder.

Burada deneyleri otomatikleştirmenin genellikle imkansız olduğunu belirtmekte fayda var. AutoML konseptini de sürece eklemek elbette mümkün. Ancak şu anda deneyin herhangi bir konusu için aynı sonuçlarla kullanılabilecek tanınmış bir çözüm yoktur.

Genel durumda AutoML şu şekilde çalışır:

1. Bir şekilde model çalışma parametrelerinin birçok kombinasyonundan oluşan bir dizi oluşturur
2. Ortaya çıkan her kombinasyon için bir deneme çalıştırır. En iyi modelin seçildiği temel alınarak her denemeye ilişkin ölçümleri düzeltir
3. AutoML, Kıdemsiz/Orta Veri Bilimcisinin aşağı yukarı standart görevlerden oluşan bir daire içinde yapacağı tüm manipülasyonları yapar

Otomasyon biraz ele alındı. Daha sonra, modelin yeni bir versiyonunun üretime teslimini organize etmemiz gerekiyor.

Modellerin sunulması ve izlenmesi

Tahminler oluşturmak için ML modeli gereklidir. Ancak ML modelinin kendisi, bunları bu kadar hızlı bir şekilde oluşturamayacak bir dosyadır. İnternette sıklıkla böyle bir çözüm bulabilirsiniz: Bir ekip FastAPI'yi alır ve modelin etrafına bir Python sarmalayıcısı yazar, böylece "yüklemleri takip edebilirsiniz".

ML model dosyasının alındığı andan itibaren olayların ortaya çıkmasının birkaç yolu vardır. Takım gidebilir:

• RESTfull hizmeti oluşturmak için tüm kodu yazın
• Çevresindeki tüm sarmaları uygulayın
• Hepsini bir Docker görüntüsünde oluşturun
• Ve sonra o görüntünün bir yerinde bir konteyner inşa edeceksiniz
• Bir şekilde ölçeklendirin
• Metrik koleksiyonunu organize edin
• Uyarıyı ayarlama
• Modelin yeni sürümlerini kullanıma sunmak için kurallar belirleyin
• Başka birçok şey

Bunu tüm modeller için yapmak ve gelecekte tüm kod tabanını korumak emek yoğun bir iştir. Bunu kolaylaştırmak için 3 yeni varlığın tanıtıldığı özel servis araçları ortaya çıktı:

• Çıkarım Örneği/Hizmet
• Çıkarım Sunucusu
• Servis Motoru

Çıkarım Örneği veya Çıkarım Hizmeti , sorguları almak ve yanıt tahminleri oluşturmak için hazırlanan belirli bir makine öğrenimi modelidir. Böyle bir varlık, gerekli makine öğrenimi modeline ve onu çalıştırmak için teknik araçlara sahip bir kapsayıcıya sahip bir Kubernetes kümesindeki bir alt birimi temsil edebilir.

Çıkarım Sunucusu, Çıkarım Örneklerinin/Hizmetlerinin yaratıcısıdır. Çıkarım Sunucusunun birçok uygulaması vardır. Her biri belirli makine öğrenimi çerçeveleriyle çalışabilir ve bu çerçevelerde eğitilen modelleri, giriş sorgularını işlemek ve tahminler oluşturmak için kullanıma hazır modellere dönüştürebilir.

Hizmet Motoru birincil yönetim işlevlerini yerine getirir. Hangi Çıkarım Sunucusunun kullanılacağını, elde edilen Çıkarım Örneğinin kaç kopyasının başlatılması gerektiğini ve bunların nasıl ölçeklendirileceğini belirler.

Göz önünde bulundurulan şemada, model hizmet bileşenleri hakkında böyle bir ayrıntı mevcut değildir, ancak benzer yönler ana hatlarıyla belirtilmiştir:

• Üretimde çalışmaya hazır modelleri dağıtan CI/CD bileşeni (Serving Engine'in sürümlerinden biri olarak düşünülebilir)
• Model Serving, elindeki altyapı dahilinde, hem akış hem de toplu senaryolar için ML modelleri için tahmin oluşturma şemasını düzenler (Inference Server'ın versiyonlarından biri olarak düşünülebilir)

Sunuma yönelik tam bir yığın örneği için Seldon'daki yığına başvurabiliriz:

• Seldon Core Hizmet Motorudur
• Seldon ML Sunucusu, REST veya gRPC aracılığıyla modele erişimi hazırlayan Çıkarım Sunucusudur.
• Seldon MLServer Özel Çalışma Zamanı, tahminler oluşturmak için örneğinin çalıştırılması gereken herhangi bir ML modeli için bir kabuk örneği olan Çıkarım Örneğidir.

Hizmetin uygulanmasına yönelik standartlaştırılmış bir protokol bile mevcut olup, bu tür araçların tümünde desteği fiilen zorunludur. Buna V2 Çıkarım Protokolü denir ve KServe, Seldon ve Nvidia Triton gibi önde gelen pazar oyuncuları tarafından geliştirilmiştir.

Sunum ve Dağıtım

Çeşitli makalelerde, tek bir varlık olarak Hizmet Verme ve Dağıtım araçlarına ilişkin referanslar bulabilirsiniz. Ancak her ikisinin de amacındaki farkı anlamak önemlidir. Bu tartışmalı bir konudur, ancak bu makale bunu şu şekilde ortaya koyacaktır:

• Hizmet - bir API modelinin oluşturulması ve ondan tahmin alma olanağı. Sonunda, içinde model bulunan tek bir hizmet örneğine sahip olursunuz.
• Dağıtım - gelen istekleri işlemek için hizmet örneğinin gerekli miktarda dağıtılması (Kubernetes dağıtımında bir kopya kümesi olarak temsil edilebilir).

Modelleri dağıtmak için birçok strateji kullanılabilir ancak bunlar makine öğrenimine özgü değildir. Bu arada, Seldon'un ücretli sürümü birçok stratejiyi destekliyor, böylece bu yığını seçebilir ve her şeyin nasıl çalıştığının keyfini çıkarabilirsiniz.

Model performans ölçümlerinin izlenmesi gerektiğini unutmayın. Aksi takdirde sorunları zamanında çözemezsiniz. Metriklerin tam olarak nasıl takip edileceği büyük sorudur. Arize AI bunun üzerine koca bir iş kurdu ancak kimse Grafana ve VictoriaMetrics'i iptal etmedi.

Proje başlangıcı

Yukarıda yazılan her şey göz önüne alındığında, ML komutunun şu olduğu ortaya çıkıyor:

• Veri kümeleri oluşturur
• ML modellerinde bunlar üzerinde deneyler yapar
• Veri kümelerini genişletmek ve modellerin kalitesini artırmak için yeni özellikler geliştirir
• Gelecekte yeniden kullanmak üzere en iyi modelleri Model Kaydına kaydeder
• Modellerin Sunumunu ve Dağıtımını özelleştirir
• Üretimdeki modellerin izlenmesini ve mevcut modellerin otomatik olarak yeniden eğitilmesini veya yeni modeller oluşturulmasını özelleştirir

Pahalı görünüyor ve yalnızca bazen haklı görünüyor. Bu nedenle şemada rasyonel hedef belirlemeden sorumlu ayrı bir MLOps Proje Başlatma (A) bloğu bulunmaktadır.

BT yöneticisinin muhakemesine bir örnek, buradaki düşünme biçimini gösterebilir. İlham veren bir proje yöneticisi ona gelir ve bir makine öğrenimi sistemi oluşturmak için yeni bir platform kurulumu ister. Her ikisi de şirketin çıkarına en uygun şekilde hareket ediyorsa BT direktörünün açıklayıcı soruları gelecektir:

• Yeni ML sistemiyle hangi iş sorununu çözeceksiniz?
• Neden yeni ML sisteminin bu sorunu çözmesi gerektiğine karar verdiniz?
• Süreçleri değiştirmek veya teknik destekte daha fazla kişiyi işe almak daha kolay ve ucuz olur mu?
• Mevcut seçiminizin temelini oluşturan makine öğrenimi sistemi bileşenlerinin karşılaştırmalı analizini nerede görebilirsiniz?
• Seçilen makine öğrenimi sistemi mimarisi bir iş sorununu çözmeye nasıl yardımcı olacak?
• ML'nin belirlenen sorunu çözmek için gerekli matematiksel aparatlara sahip olduğundan emin misiniz?
• Çözüm için problem cümlesi nedir?
• Modelleri eğitmek için verileri nereden alacaksınız? Modelleri hazırlamak için hangi verilere ihtiyacınız olduğunu biliyor musunuz?
• Mevcut verileri zaten incelediniz mi?
• Verilerin kalitesi modeli çözmek için yeterli mi?

BT direktörü bir üniversitede öğretmen olarak görevden alınacak ancak şirketin parasını kurtaracak. Eğer tüm sorular cevaplanmışsa, bir ML sistemine gerçekten ihtiyaç var demektir.

Sonraki soru: İçinde MLOps yapmam gerekiyor mu?

Soruna bağlı. PoC (Kavram Kanıtı) gibi tek seferlik bir çözüm bulmanız gerekiyorsa MLOps'a ihtiyacınız yoktur. Çok sayıda gelen isteğin işlenmesi gerekiyorsa MLOps gereklidir. Özünde bu yaklaşım, herhangi bir kurumsal sürecin optimize edilmesine benzer.

Yönetime MLOps ihtiyacını haklı çıkarmak için aşağıdaki soruların yanıtlarını hazırlamanız gerekir:

• Neler iyileşecek?
• Ne kadar para tasarruf edeceğiz?
• Kadromuzu genişletmemiz gerekiyor mu?
• Ne satın almamız gerekiyor?
• Nerede uzmanlık kazanılır?

Yapılacak bir sonraki şey BT direktörü sınavına tekrar girmektir.

Zorluklar devam ediyor çünkü ekibin aynı zamanda iş süreçlerini ve teknoloji yığınını değiştirme ihtiyacına da ikna olması gerekiyor. Bazen bu, yönetimden bütçe istemekten daha zordur.

Ekibi ikna etmek için şu soruların cevaplarını hazırlamaya değer:

• Neden eski çalışma şekli artık mümkün değil?
• Değişikliğin amacı nedir?
• Teknoloji yığını ne olacak?
• Ne ve kimden öğrenilecek?
• Şirket değişikliklerin uygulanmasına nasıl yardımcı olacak?
• Değişikliğin yapılması ne kadar sürer?
• Bunu başaramayanlar ne olacak?

Gördüğünüz gibi bu süreç basit değil.

Küçük sonuç

Burada MLOps şemasına ilişkin ayrıntılı bir çalışmayla işim bitti. Ancak bunlar sadece teorik yönlerdir. Pratik uygulama her zaman birçok şeyi değiştirebilecek ek ayrıntıları ortaya çıkarır.

Bir sonraki makalede şunları tartışacağım:

• MLOps eserleri
• Bir bilgi sistemi olarak MLOps
• MLOps için Açık Kaynak: Kubeflow ve MLflow ve Pachyderm

İlginiz için teşekkür ederiz!