Sənaye Maşınlarının Öyrənilməsi: 10 Dizayn Prinsipləri
Hal-hazırda, hər gün inanılmaz şeylər yaratmağa imkan verən yeni xidmətlər, tətbiqlər və digər mühüm proqramlar yaradılır: SpaceX raketini idarə etmək üçün proqram təminatından tutmuş, smartfon vasitəsilə qonşu otaqdakı çaydanla qarşılıqlı əlaqəyə qədər.
Və bəzən, hər bir təcrübəsiz proqramçı, istər ehtiraslı bir başlanğıc, istərsə də adi bir Full Stack və ya Data Scientist, gec-tez proqramlaşdırma və həyatı çox asanlaşdıran proqram təminatı yaratmaq üçün müəyyən qaydaların olduğunu başa düşür.
Bu yazıda mən 10 faktorlu Tətbiq metodologiyasına əsaslanaraq, asanlıqla tətbiqə/xidmətə inteqrasiya oluna bilməsi üçün sənaye maşın öyrənməsinin proqramlaşdırılmasının 12 prinsipini qısaca təsvir edəcəyəm. . Mənim təşəbbüsüm bir çox tərtibatçılara və məlumat elminə kömək edə biləcək bu texnika haqqında məlumatlılığı artırmaqdır.
Bu məqalə sənaye Maşın Öyrənilməsi haqqında bir sıra məqalələrin proloqudur. Onlarda daha sonra modeli necə hazırlamaq və istehsala başlamaq, onun üçün API yaratmaq, eləcə də sistemlərində quraşdırılmış ML olan müxtəlif sahələrdən və şirkətlərdən nümunələr haqqında danışacağam.
Prinsip 1: Bir kod bazası
Bəzi proqramçılar ilk mərhələdə bunu başa düşməkdə tənbəllikdən (yaxud özlərinin nədənsə) Git-i unudurlar. Onlar ya sözü tamamilə unudurlar, yəni diskdə bir-birlərinə fayl atırlar/sadəcə mətn atırlar/göyərçinlər vasitəsilə göndərirlər, ya da iş prosesində düşünmürlər və hər birini öz filialına, sonra isə ustad.
Bu prinsip deyir: bir kod bazası və bir çox yerləşdirmə var.
Git həm istehsalda, həm də o qədər də tez-tez istifadə olunmayan tədqiqat və inkişafda (R&D) istifadə edilə bilər.
Məsələn, Ar-Ge mərhələsində siz ən yaxşısını seçmək və asanlıqla onunla işləməyə davam etmək üçün müxtəlif məlumat emalı metodları və modelləri ilə öhdəliklər buraxa bilərsiniz.
İkincisi, istehsalatda bu əvəzolunmaz bir şeydir - siz daim kodunuzun necə dəyişdiyinə baxmaq və hansı modelin ən yaxşı nəticələr verdiyini, sonda hansı kodun işlədiyini və onun işini dayandırmasına və ya yanlış nəticələr verməyə başlamasına səbəb olan hadisəni bilməlisiniz. . Öhdəliklər bunun üçündür!
Siz həmçinin layihənizin paketini yarada, məsələn, Gemfury-də yerləşdirə və sonra 1000 dəfə təkrar yazmamaq üçün ondan sadəcə olaraq digər layihələr üçün funksiyaları idxal edə bilərsiniz, lakin daha çox.
Prinsip 2: Asılılıqları aydın şəkildə bəyan edin və təcrid edin
Hər bir layihədə hardasa tətbiq etmək üçün xaricdən idxal etdiyiniz müxtəlif kitabxanalar var. İstər Python kitabxanaları, istərsə də müxtəlif məqsədlər üçün digər dillərin kitabxanaları və ya sistem alətləri olsun - sizin vəzifəniz:
- Asılılıqları, yəni layihənizdə istifadə olunan və quraşdırılmalı olan bütün kitabxanaları, alətləri və onların versiyalarını ehtiva edən faylı açıq şəkildə bəyan edin (məsələn, Python-da bu, Pipfile və ya requirements.txt istifadə etməklə edilə bilər. A. yaxşı başa düşməyə imkan verən link: )
- İnkişaf zamanı proqramınız üçün xüsusi olaraq asılılıqları təcrid edin. Siz daim versiyaları dəyişdirmək və yenidən quraşdırmaq istəmirsiniz, məsələn, Tensorflow?
Beləliklə, gələcəkdə komandanıza qoşulacaq tərtibatçılar layihənizdə istifadə olunan kitabxanalar və onların versiyaları ilə tez bir zamanda tanış ola biləcəklər və siz həmçinin müəyyən bir proqram üçün quraşdırılmış versiyaları və kitabxanaları özləri idarə etmək imkanınız olacaq. kitabxanaların və ya onların versiyalarının uyğunsuzluğunun qarşısını almağa kömək edəcək layihə.
Tətbiqiniz həmçinin xüsusi OS-də quraşdırıla bilən sistem alətlərinə etibar etməməlidir. Bu alətlər də asılılıq manifestində elan edilməlidir. Bu, alətlərin versiyasının (həmçinin onların mövcudluğu) müəyyən bir OS-nin sistem alətlərinə uyğun gəlmədiyi vəziyyətlərin qarşısını almaq üçün lazımdır.
Beləliklə, curl demək olar ki, bütün kompüterlərdə istifadə oluna bilsə belə, siz onu hələ də asılılıqlarda elan etməlisiniz, çünki başqa platformaya köçərkən o, orada olmaya bilər və ya versiya əvvəlcə sizə lazım olan versiya olmayacaq.
Məsələn, tələblər.txt faylınız belə görünə bilər:
# 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
Prinsip 3: Konfiqurasiyalar
Çoxları müxtəlif tərtibatçıların təsadüfən kodu GitHub-a AWS-dən parollar və digər açarlarla ictimai depolara yükləmələri və ertəsi gün 6000 dollar, hətta 50000 dollarlıq borcla oyanmaları haqqında hekayələr eşitmişdir.
Əlbəttə ki, bu hallar həddindən artıq, lakin çox əhəmiyyətlidir. Əgər siz etimadnamənizi və ya konfiqurasiya üçün lazım olan digər məlumatları kodun içərisində saxlayırsınızsa, səhv edirsiniz və məncə bunun səbəbini izah etməyə ehtiyac yoxdur.
Bunun alternativi konfiqurasiyaları mühit dəyişənlərində saxlamaqdır. Ətraf mühit dəyişənləri haqqında daha çox oxuya bilərsiniz .
Adətən mühit dəyişənlərində saxlanılan məlumatların nümunələri:
- Domen adları
- API URL-ləri/URI-ləri
- Açıq və şəxsi açarlar
- Əlaqələr (poçt, telefonlar və s.)
Beləliklə, konfiqurasiya dəyişənləriniz dəyişərsə, kodu daim dəyişmək məcburiyyətində deyilsiniz. Bu, vaxtınıza, səyinizə və pulunuza qənaət etməyə kömək edəcəkdir.
Məsələn, testlər aparmaq üçün Kaggle API istifadə edirsinizsə (məsələn, proqram təminatını endirin və modelin yaxşı işlədiyini yoxlamaq üçün onun vasitəsilə modeli işə salın), onda KAGGLE_USERNAME və KAGGLE_KEY kimi Kaggle-dan şəxsi açarlar olmalıdır. mühit dəyişənlərində saxlanılır.
Prinsip 4: Üçüncü Şəxs Xidmətləri
Buradakı fikir proqramı elə yaratmaqdır ki, kod baxımından yerli və üçüncü tərəf resursları arasında heç bir fərq olmasın. Məsələn, həm yerli MySQL, həm də üçüncü tərəfləri birləşdirə bilərsiniz. Eyni şey Google Xəritələr və ya Twitter API kimi müxtəlif API-lərə də aiddir.
Üçüncü tərəf xidmətini söndürmək və ya başqasına qoşulmaq üçün yuxarıdakı paraqrafda danışdığım mühit dəyişənlərindəki konfiqurasiyadakı düymələri dəyişmək kifayətdir.
Beləliklə, məsələn, hər dəfə kodun içərisində verilənlər toplusu olan fayllara gedən yolu göstərmək əvəzinə, pathlib kitabxanasından istifadə etmək və verilənlər bazasına gedən yolu config.py-də elan etmək daha yaxşıdır ki, hansı xidmətdən istifadə etməyinizdən asılı olmayaraq (üçün) Məsələn, CircleCI), proqram yeni xidmətdə yeni fayl sisteminin strukturunu nəzərə alaraq verilənlər toplusuna gedən yolu tapa bildi.
Prinsip 5. Qurmaq, buraxmaq, icra müddəti
Data Science sahəsində bir çox insanlar proqram təminatı yazma bacarıqlarını təkmilləşdirməyi faydalı hesab edirlər. Proqramımızın mümkün qədər nadir hallarda qəzaya uğramasını və mümkün qədər uzun müddət uğursuz işləməsini istəyiriksə, yeni versiyanın buraxılması prosesini 3 mərhələyə bölmək lazımdır:
- Mərhələ məclislər. Siz fərdi resurslarla çılpaq kodunuzu bütün lazımi kodu və məlumatları ehtiva edən sözdə paketə çevirirsiniz. Bu paket montaj adlanır.
- Mərhələ buraxmaq — burada konfiqurasiyamızı montaja bağlayırıq, onsuz proqramımızı buraxa bilməzdik. İndi bu, tamamilə buraxılmağa hazır bir buraxılışdır.
- Növbəti mərhələ gəlir yerinə yetirilməsi. Burada biz buraxılışımızdan lazımi prosesləri işlətməklə proqramı buraxırıq.
Modelin və ya bütün boru kəmərinin yeni versiyalarını buraxmaq üçün belə bir sistem idarəçilər və tərtibatçılar arasında rolları ayırmağa imkan verir, versiyaları izləməyə imkan verir və proqramın arzuolunmaz dayanmalarının qarşısını alır.
Buraxılış tapşırığı üçün .yml faylında özünüzü işə salmaq üçün proseslər yaza biləcəyiniz bir çox müxtəlif xidmətlər yaradılmışdır (məsələn, CircleCI-də bu, prosesin özünü dəstəkləmək üçün config.yml-dir). Wheely layihələr üçün paketlər yaratmaqda əladır.
Siz maşın öyrənmə modelinizin müxtəlif versiyaları ilə paketlər yarada, sonra onları paketləyə və oradan yazdığınız funksiyalardan istifadə etmək üçün lazımi paketlərə və onların versiyalarına müraciət edə bilərsiniz. Bu, modeliniz üçün API yaratmağınıza kömək edəcək və paketiniz, məsələn, Gemfury-də yerləşdirilə bilər.
Prinsip 6. Modelinizi bir və ya bir neçə proses kimi işlədin
Üstəlik, proseslərdə paylaşılan məlumatlar olmamalıdır. Yəni, proseslər ayrı-ayrılıqda mövcud olmalıdır və ehtiyacınızdan asılı olaraq, məsələn, MySQL və ya başqaları kimi üçüncü tərəf xidmətlərində bütün növ məlumatlar ayrıca mövcud olmalıdır.
Yəni, prosesin fayl sistemi daxilində məlumatları saxlamağa qətiyyən dəyməz, əks halda bu, növbəti buraxılış/konfiqurasiyaların dəyişdirilməsi və ya proqramın işlədiyi sistemin ötürülməsi zamanı bu məlumatların təmizlənməsinə səbəb ola bilər.
Ancaq bir istisna var: maşın öyrənmə layihələri üçün kitabxanaların keşini saxlaya bilərsiniz ki, hər dəfə yeni versiyanı işə saldıqda, əlavə kitabxanalar və ya onların versiyalarında hər hansı dəyişiklik edilməyibsə, onları yenidən quraşdırmamaq üçün. Bu yolla, modelinizi sənayedə işə salmaq üçün lazım olan vaxtı azaldacaqsınız.
Modeli bir neçə proses kimi işə salmaq üçün siz lazımi prosesləri və onların ardıcıllığını təyin etdiyiniz .yml faylı yarada bilərsiniz.
Prinsip 7: Təkrar istifadəyə yararlılıq
Model tətbiqinizdə işləyən prosesləri başlamaq və dayandırmaq asan olmalıdır. Beləliklə, bu, kod dəyişikliklərini, konfiqurasiya dəyişikliklərini tez bir zamanda yerləşdirməyə, tez və çevik şəkildə miqyaslandırmağa və işləyən versiyanın mümkün nasazlığının qarşısını almağa imkan verəcəkdir.
Yəni modellə prosesiniz:
- Başlanğıc vaxtını minimuma endir. İdeal olaraq, işə salma vaxtı (başlanğıc əmrinin verildiyi andan prosesin işə salındığı ana qədər) bir neçə saniyədən çox olmamalıdır. Yuxarıda təsvir edilən kitabxananın keşləşdirilməsi başlanğıc vaxtını azaltmaq üçün bir üsuldur.
- Düzgün bitir. Yəni, xidmət portunda dinləmə faktiki olaraq dayandırılır və bu porta göndərilən yeni sorğular işlənməyəcək. Burada ya DevOps mühəndisləri ilə yaxşı ünsiyyət qurmalı, ya da bunun necə işlədiyini özünüz başa düşməlisiniz (əlbəttə ki, sonuncuya üstünlük verilir, lakin hər hansı bir layihədə ünsiyyət həmişə saxlanılmalıdır!)
Prinsip 8: Davamlı Yerləşdirmə/İnteqrasiya
Bir çox şirkət proqram inkişaf etdirmə və yerləşdirmə qrupları arasında ayrılıqdan istifadə edir (tətbiqi son istifadəçilər üçün əlçatan edir). Bu, proqram təminatının işlənməsini və onun təkmilləşdirilməsində irəliləyişi xeyli ləngidə bilər. Bu, həmçinin inkişafın və inteqrasiyanın, təxminən, birləşdiyi DevOps mədəniyyətini korlayır.
Buna görə də, bu prinsip inkişaf mühitinizin istehsal mühitinizə mümkün qədər yaxın olmasını bildirir.
Bu imkan verəcək:
- Buraxılış vaxtını onlarla dəfə azaldın
- Kod uyğunsuzluğu səbəbindən səhvlərin sayını azaldın.
- Bu, həm də işçilərin iş yükünü azaldır, çünki tərtibatçılar və tətbiqi yerləşdirən insanlar indi bir komandadır.
Bununla işləməyə imkan verən alətlər CircleCI, Travis CI, GitLab CI və başqalarıdır.
Siz tez bir zamanda modelə əlavələr edə, onu yeniləyə və dərhal işə sala bilərsiniz, halbuki nasazlıqlar halında çox tez işlək versiyaya qayıtmaq asan olacaq ki, son istifadəçi bunu belə hiss etməsin. Yaxşı testləriniz varsa, bu, xüsusilə asanlıqla və tez edilə bilər.
Fərqləri minimuma endir!!!
Prinsip 9. Sizin qeydləriniz
Jurnallar (və ya “Qeydlər”) adətən mətn formatında qeydə alınan və proqram daxilində baş verən hadisələrdir (hadisə axını). Sadə bir nümunə: "2020-02-02 - sistem səviyyəsi - prosesin adı." Onlar tərtibatçının proqram işləyərkən nə baş verdiyini sözün əsl mənasında görə bilməsi üçün hazırlanmışdır. O, proseslərin gedişatını görür və bunun tərtibatçının özünün nəzərdə tutduğu kimi olub olmadığını başa düşür.
Bu prinsip qeyd edir ki, siz qeydlərinizi fayl sisteminizdə saxlamamalısınız – sadəcə onları ekrana “çıxıb” çıxarmalısınız, məsələn, bunu sistemin standart çıxışında edin. Və bu yolla inkişaf zamanı terminalda axını izləmək mümkün olacaq.
Bu, ümumiyyətlə qeydləri saxlamağa ehtiyac olmadığı anlamına gəlirmi? Əlbəttə yox. Tətbiqiniz bunu etməməlidir - onu üçüncü tərəf xidmətlərinə buraxın. Tətbiqiniz real vaxt rejimində baxmaq üçün qeydləri yalnız xüsusi fayl və ya terminala yönləndirə və ya ümumi təyinatlı məlumat saxlama sisteminə (məsələn, Hadoop) yönləndirə bilər. Tətbiqinizin özü logları saxlamamalı və ya onlarla qarşılıqlı əlaqədə olmamalıdır.
Prinsip 10. Test!
Sənaye maşın öyrənməsi üçün bu mərhələ son dərəcə vacibdir, çünki modelin düzgün işlədiyini və istədiyinizi istehsal etdiyini başa düşməlisiniz.
Testlər pytest istifadə edərək yaradıla bilər və əgər reqressiya/təsnifat tapşırığınız varsa kiçik verilənlər bazasından istifadə edərək sınaqdan keçirilə bilər.
Dərin öyrənmə modelləri üçün eyni toxumu təyin etməyi unutmayın ki, onlar daim fərqli nəticələr verməsinlər.
Bu, 10 prinsipin qısa təsviri idi və əlbəttə ki, onları sınamadan və necə işlədiyini görmədən istifadə etmək çətindir, buna görə də bu məqalə, necə yaradılacağını açıqlayacağım bir sıra maraqlı məqalələrin proloqudur. sənaye maşın öyrənmə modelləri , onların sistemlərə necə inteqrasiya olunacağı və bu prinsiplərin hamımız üçün həyatı necə asanlaşdıra biləcəyi.
Mən də sərin prinsiplərdən istifadə etməyə çalışacam ki, hər kəs istəsə şərhlərdə qoya bilər.
Mənbə: www.habr.com