Endüstriyel Makine Öğrenimi: 10 Tasarım İlkesi
Günümüzde, her gün inanılmaz şeyler yaratmayı mümkün kılan yeni hizmetler, uygulamalar ve diğer önemli programlar oluşturuluyor: SpaceX roketini kontrol etmeye yönelik yazılımlardan, akıllı telefon aracılığıyla yan odadaki su ısıtıcısıyla etkileşime geçmeye kadar.
Ve bazen, ister tutkulu bir başlangıççı olsun, ister sıradan bir Full Stack veya Veri Bilimcisi olsun, her acemi programcı, er ya da geç, programlama ve yazılım oluşturma için yaşamı büyük ölçüde kolaylaştıran belirli kuralların olduğunun farkına varır.
Bu makalede, endüstriyel makine öğreniminin bir uygulamaya/hizmete kolayca entegre edilebilmesi için 10 faktörlü Uygulama metodolojisini temel alarak nasıl programlanacağına ilişkin 12 prensibi kısaca anlatacağım. . Benim girişimim, birçok geliştiriciye ve veri bilimi insanına yardımcı olabilecek bu tekniğin farkındalığını arttırmaktır.
Bu makale endüstriyel Makine Öğrenimi ile ilgili bir dizi makalenin önsözüdür. Bunlarda, aslında bir modelin nasıl oluşturulacağı ve üretime nasıl başlatılacağı, bunun için bir API oluşturulacağı ve sistemlerinde yerleşik ML'ye sahip çeşitli alanlardan ve şirketlerden örnekler hakkında daha fazla konuşacağım.
İlke 1: Tek kod tabanı
İlk aşamalardaki bazı programcılar, bunu çözme tembelliğinden (veya kendilerine ait bir nedenden dolayı) Git'i unuturlar. Ya kelimeyi tamamen unutuyorlar, yani sürücüde birbirlerine dosya atıyorlar/sadece mesaj atıyorlar/güvercinlerle gönderiyorlar ya da iş akışlarını düşünmeden her birini kendi şubesine ve sonra da usta.
Bu prensip şunu belirtir: bir kod tabanına ve birçok dağıtıma sahiptir.
Git hem üretimde hem de çok sık kullanılmadığı araştırma ve geliştirmede (Ar-Ge) kullanılabilir.
Örneğin, Ar-Ge aşamasında, en iyisini seçmek ve onunla kolayca çalışmaya devam etmek için farklı veri işleme yöntemleri ve modelleri ile taahhütler bırakabilirsiniz.
İkincisi, üretimde bu yeri doldurulamaz bir şeydir - kodunuzun nasıl değiştiğine sürekli bakmanız ve hangi modelin en iyi sonuçları ürettiğini, sonunda hangi kodun çalıştığını ve çalışmayı durdurmasına veya yanlış sonuçlar üretmeye başlamasına neyin sebep olduğunu bilmeniz gerekecektir. . Taahhütler bunun içindir!
Ayrıca projenizin bir paketini oluşturabilir, örneğin Gemfury'e yerleştirebilir ve ardından 1000 kez yeniden yazmak için değil, daha sonra daha fazlasını yazmak için ondan basitçe diğer projeler için işlevleri içe aktarabilirsiniz.
İlke 2: Bağımlılıkları açıkça beyan edin ve izole edin
Her projenin, bir yere uygulamak için dışarıdan içe aktardığınız farklı kütüphaneleri vardır. İster Python kitaplıkları, ister çeşitli amaçlara yönelik diğer dillerin kitaplıkları, ister sistem araçları olsun, göreviniz:
- Bağımlılıkları, yani projenizde kullanılan ve yüklenmesi gereken tüm kitaplıkları, araçları ve bunların sürümlerini içerecek bir dosya olduğunu açıkça belirtin (örneğin, Python'da bu, Pipfile veya gereksinimleri.txt kullanılarak yapılabilir). iyi anlaşılmasını sağlayan bağlantı: )
- Geliştirme sırasında programınız için özel olarak bağımlılıkları izole edin. Tensorflow gibi sürümleri sürekli değiştirip yeniden yüklemek istemiyor musunuz?
Bu sayede gelecekte ekibinize katılacak geliştiriciler projenizde kullanılan kütüphaneleri ve versiyonlarını hızlı bir şekilde tanıyabilecek ve siz de belirli bir proje için kurulu olan versiyonları ve kütüphaneleri kendileri yönetme imkanına sahip olacaksınız. kitaplıkların veya sürümlerinin uyumsuzluğunu önlemenize yardımcı olacak proje.
Uygulamanız ayrıca belirli bir işletim sistemine kurulabilecek sistem araçlarına da bağlı olmamalıdır. Bu araçların bağımlılık bildiriminde de bildirilmesi gerekir. Bu, araçların sürümünün (ve kullanılabilirliklerinin) belirli bir işletim sisteminin sistem araçlarıyla eşleşmediği durumlardan kaçınmak için gereklidir.
Bu nedenle, curl hemen hemen tüm bilgisayarlarda kullanılabilse bile, onu yine de bağımlılıklarda bildirmelisiniz, çünkü başka bir platforma geçiş yaparken orada olmayabilir veya sürüm başlangıçta ihtiyacınız olan sürüm olmayabilir.
Örneğin, gereksinimleriniz.txt dosyanız şöyle görünebilir:
# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0
# testing requirements
pytest>=5.3.2,<6.0.0
# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0
# fetching datasets
kaggle>=1.5.6,<1.6.0
Prensip 3: Konfigürasyonlar
Birçoğu, AWS'den gelen şifreler ve diğer anahtarlarla birlikte yanlışlıkla GitHub'a halka açık depolara kod yükleyen ve ertesi gün 6000 ABD Doları, hatta 50000 ABD Doları tutarında bir borçla uyanan çeşitli geliştirici adamların hikayelerini duymuştur.
Elbette bu durumlar aşırı ama çok önemli. Kimlik bilgilerinizi veya yapılandırma için gereken diğer verileri kodun içinde saklıyorsanız hata yapıyorsunuz ve nedenini açıklamaya gerek olmadığını düşünüyorum.
Buna bir alternatif, konfigürasyonları ortam değişkenlerinde saklamaktır. Ortam değişkenleri hakkında daha fazla bilgi edinebilirsiniz .
Genellikle ortam değişkenlerinde depolanan verilere örnekler:
- Alan isimleri
- API URL'leri/URI'leri
- Genel ve özel anahtarlar
- Kişiler (posta, telefon vb.)
Bu şekilde, yapılandırma değişkenleriniz değiştiğinde kodu sürekli olarak değiştirmenize gerek kalmaz. Bu, zamandan, emekten ve paradan tasarruf etmenize yardımcı olacaktır.
Örneğin, testleri gerçekleştirmek için Kaggle API'sini kullanıyorsanız (örneğin, yazılımı indirip modeli çalıştırırken modelin iyi çalışıp çalışmadığını test etmek için modeli onun üzerinden çalıştırın), o zaman KAGGLE_USERNAME ve KAGGLE_KEY gibi Kaggle'ın özel anahtarları olmalıdır. ortam değişkenlerinde saklanır.
İlke 4: Üçüncü Taraf Hizmetleri
Buradaki fikir, programı yerel ve üçüncü taraf kaynaklar arasında kod açısından hiçbir fark olmayacak şekilde oluşturmaktır. Örneğin, hem yerel MySQL'i hem de üçüncü taraf olanları bağlayabilirsiniz. Aynı şey Google Haritalar veya Twitter API gibi çeşitli API'ler için de geçerlidir.
Üçüncü taraf bir hizmeti devre dışı bırakmak veya başka bir hizmete bağlanmak için yukarıdaki paragrafta bahsettiğim ortam değişkenlerindeki yapılandırmadaki anahtarları değiştirmeniz yeterlidir.
Bu nedenle, örneğin, her seferinde kodun içinde veri kümeleri bulunan dosyaların yolunu belirtmek yerine, pathlib kitaplığını kullanmak ve veri kümelerinin yolunu config.py'de bildirmek daha iyidir; böylece hangi hizmeti kullanırsanız kullanın (için) Örneğin, CircleCI), program, yeni hizmetteki yeni dosya sisteminin yapısını dikkate alarak veri kümelerinin yolunu bulmayı başardı.
İlke 5. Oluşturma, yayınlama, çalıştırma zamanı
Veri Bilimindeki pek çok kişi, yazılım yazma becerilerini geliştirmenin faydalı olduğunu düşünüyor. Programımızın mümkün olduğu kadar nadir çökmesini ve mümkün olduğu kadar uzun süre hatasız çalışmasını istiyorsak, yeni bir sürüm yayınlama sürecini 3 aşamaya ayırmamız gerekir:
- evre montaj. Bireysel kaynaklara sahip çıplak kodunuzu, gerekli tüm kod ve verileri içeren paket adı verilen bir pakete dönüştürürsünüz. Bu pakete montaj adı verilir.
- evre salıverme - burada yapılandırmamızı derlemeye bağlarız, bu olmadan programımızı yayınlayamayız. Artık bu tamamen lansmana hazır bir sürüm.
- Sonra sahne geliyor icra. Burada sürümümüzden gerekli işlemleri çalıştırarak uygulamayı yayınlıyoruz.
Bir modelin veya tüm boru hattının yeni sürümlerini yayınlamaya yönelik böyle bir sistem, yöneticiler ve geliştiriciler arasındaki rolleri ayırmanıza olanak tanır, sürümleri izlemenize olanak tanır ve programın istenmeyen şekilde durdurulmasını önler.
Sürüm görevi için, kendinizin çalıştıracağı işlemleri bir .yml dosyasına yazabileceğiniz birçok farklı hizmet oluşturulmuştur (örneğin, CircleCI'de bu, sürecin kendisini desteklemek için config.yml'dir). Wheely, projeler için paketler oluşturma konusunda harikadır.
Makine öğrenimi modelinizin farklı versiyonlarına sahip paketler oluşturabilir ve ardından bunları paketleyip, oradan yazdığınız fonksiyonları kullanmak için gerekli paketlere ve versiyonlarına başvurabilirsiniz. Bu, modeliniz için bir API oluşturmanıza yardımcı olacaktır ve örneğin paketiniz Gemfury'de barındırılabilir.
İlke 6. Modelinizi bir veya daha fazla süreç olarak çalıştırın
Ayrıca süreçlerin ortak verileri olmamalıdır. Yani, ihtiyacınız olana bağlı olarak süreçlerin ayrı ayrı var olması ve her türlü verinin ayrı ayrı mevcut olması gerekir; örneğin MySQL gibi üçüncü taraf hizmetlerde veya diğerleri.
Yani, verileri işlem dosya sistemi içinde saklamaya kesinlikle değmez, aksi takdirde bu, programın çalıştığı sistemin bir sonraki sürümünde/yapılandırma değişikliğinde veya aktarımı sırasında bu verilerin silinmesine yol açabilir.
Ancak bir istisna var: Makine öğrenimi projeleri için, ek kitaplıklar veya sürümlerinde herhangi bir değişiklik yapılmadıysa, yeni bir sürümü her başlattığınızda yeniden yüklememek için kitaplıkların önbelleğini saklayabilirsiniz. Bu şekilde modelinizi endüstride piyasaya sürmek için gereken süreyi azaltacaksınız.
Modeli birden fazla işlem olarak çalıştırmak için gerekli işlemleri ve bunların sırasını belirttiğiniz bir .yml dosyası oluşturabilirsiniz.
İlke 7: Geri Dönüştürülebilirlik
Model uygulamanızda çalışan süreçlerin başlatılması ve durdurulması kolay olmalıdır. Böylece kod değişikliklerini, konfigürasyon değişikliklerini hızlı bir şekilde dağıtmanıza, hızlı ve esnek bir şekilde ölçeklendirmenize ve üretim sürümündeki olası arızaları önlemenize olanak tanır.
Yani modelle olan süreciniz:
- Başlatma süresini en aza indirin. İdeal olarak, başlatma süresi (başlatma komutunun verildiği andan işlemin devreye girdiği ana kadar) birkaç saniyeden fazla olmamalıdır. Yukarıda açıklanan kitaplığı önbelleğe alma, başlatma süresini azaltmaya yönelik bir tekniktir.
- Doğru şekilde sonlandırın. Yani, hizmet bağlantı noktasındaki dinleme aslında askıya alınmıştır ve bu bağlantı noktasına gönderilen yeni istekler işleme alınmayacaktır. Burada ya DevOps mühendisleriyle iyi bir iletişim kurmanız ya da bunun nasıl çalıştığını kendiniz anlamanız gerekir (tercihen elbette ikincisi, ancak herhangi bir projede iletişim her zaman sürdürülmelidir!)
İlke 8: Sürekli Dağıtım/Entegrasyon
Birçok şirket, uygulama geliştirme ve dağıtım ekipleri arasında bir ayrım kullanır (uygulamayı son kullanıcıların kullanımına sunar). Bu, yazılım geliştirmeyi ve geliştirmedeki ilerlemeyi büyük ölçüde yavaşlatabilir. Bu aynı zamanda geliştirme ve entegrasyonun kabaca birleştiği DevOps kültürünü de bozar.
Bu nedenle bu ilke, geliştirme ortamınızın üretim ortamınıza mümkün olduğunca yakın olması gerektiğini belirtir.
Bu aşağıdakilere izin verecektir:
- Serbest bırakma süresini onlarca kat azaltın
- Kod uyumsuzluğundan kaynaklanan hataların sayısını azaltın.
- Geliştiriciler ve uygulamayı dağıtan kişiler artık tek bir ekip olduğundan, bu aynı zamanda personelin iş yükünü de azaltır.
Bununla çalışmanıza izin veren araçlar CircleCI, Travis CI, GitLab CI ve diğerleridir.
Modele hızlı bir şekilde eklemeler yapabilir, güncelleyebilir ve hemen başlatabilirsiniz, ancak arıza durumunda son kullanıcının farkına bile varmayacağı şekilde çok hızlı bir şekilde çalışan sürüme dönmek kolay olacaktır. İyi testleriniz varsa, bu özellikle kolay ve hızlı bir şekilde yapılabilir.
Farklılıkları en aza indirin!!!
İlke 9. Günlükleriniz
Günlükler (veya "Günlükler"), uygulama (olay akışı) içinde meydana gelen, genellikle metin biçiminde kaydedilen olaylardır. Basit bir örnek: "2020-02-02 - sistem düzeyi - işlem adı." Geliştiricinin, program çalışırken neler olduğunu tam anlamıyla görebilmesi için tasarlanmıştır. Süreçlerin ilerleyişini görüyor ve geliştiricinin kendisinin amaçladığı gibi olup olmadığını anlıyor.
Bu ilke, günlüklerinizi dosya sisteminizde saklamamanız gerektiğini belirtir; bunları yalnızca ekrana "çıkartmanız" gerekir; örneğin, bunu sistemin standart çıktısında yapın. Ve bu sayede geliştirme sırasında terminaldeki akışın izlenmesi mümkün olacak.
Bu, günlükleri kaydetmeye hiç gerek olmadığı anlamına mı geliyor? Tabii ki değil. Uygulamanız bunu yapmamalı; işi üçüncü taraf hizmetlere bırakın. Uygulamanız, günlükleri gerçek zamanlı görüntüleme için yalnızca belirli bir dosyaya veya terminale iletebilir veya genel amaçlı bir veri depolama sistemine (Hadoop gibi) iletebilir. Uygulamanızın kendisi günlükleri saklamamalı veya günlüklerle etkileşime girmemelidir.
Prensip 10. Test edin!
Endüstriyel makine öğrenimi için bu aşama son derece önemlidir çünkü modelin doğru çalıştığını ve istediğinizi ürettiğini anlamanız gerekir.
Testler pytest kullanılarak oluşturulabilir ve regresyon/sınıflandırma göreviniz varsa küçük bir veri kümesi kullanılarak test edilebilir.
Sürekli farklı sonuçlar üretmemeleri için derin öğrenme modellerine aynı tohumu koymayı unutmayın.
Bu, 10 prensibin kısa bir açıklamasıydı ve elbette, bunları denemeden ve nasıl çalıştıklarını görmeden kullanmak zordur, bu nedenle bu makale, nasıl oluşturulacağını açıklayacağım bir dizi ilginç makalenin yalnızca bir önsözüdür. endüstriyel makine öğrenimi modelleri, bunların sistemlere nasıl entegre edileceği ve bu ilkelerin hepimizin hayatını nasıl kolaylaştırabileceği.
Ayrıca isteyen herkesin yoruma bırakabileceği harika prensipleri de kullanmaya çalışacağım.
Kaynak: habr.com