Прамысловы Machine Learning: 10 прынцыпаў распрацоўкі
У наш час кожны дзень ствараюцца новыя сэрвісы, прыкладанні і іншыя важныя праграмы, якія дазваляюць ствараць неверагодныя рэчы: ад софту для кіравання ракетай SpaceX да ўзаемадзеяння з імбрычкам у суседнім пакоі праз смартфон.
І, сітавінай, кожны пачатковец праграміст, будзь ён гарачым стартаперам ці ж радавым Full Stack ці Data Scientist, рана ці позна прыходзіць да ўсведамлення таго, што ёсць вызначаныя правілы праграмавання і стварэнні софту, якія моцна спрашчаюць жыццё.
У гэтым артыкуле я коратка апішу 10 прынцыпаў таго, як варта праграмаваць прамысловы machine learning, каб яго можна было лёгка ўбудаваць у дадатак/сэрвіс, засноўваючыся на методыцы 12-factor App, . Мая ініцыятыва – гэта павысіць пазнавальнасць гэтай методыкі, што можа дапамагчы многім распрацоўшчыкам і людзям з Data Science.
Гэты артыкул - гэта пралог да серыі артыкулаў пра прамысловы Machine Learning. У іх я далей буду распавядаць аб тым, як, уласна, зрабіць мадэль і запусціць яе ў прадакшн, стварыць для яе API, а таксама прыклады з розных абласцей і кампаній, якія маюць убудаваны ML у іх сістэмы.
Прынцып 1. Адна кодавая база
Некаторыя праграмісты на першых этапах з-за ляноты разабрацца (ці па нейкіх сваіх меркаваннях) забываюць пра Git. Забываюць або ад слова зусім, гэта значыць кідаюць файлы адзін аднаму ў драйве/проста кідаюць тэкст/адпраўляюць галубамі, або не прадумваюць свой workflow, і робяць commit кожны ў сваю галінку, а потым і ў майстры.
Гэты прынцып абвяшчае: майце адну кодавую базу і шмат разгортванняў.
Git можна выкарыстоўваць як у production, так і ў research and development (R&D), у якім ён выкарыстоўваецца не так часта.
Напрыклад, у R&D фазе Вы можаце пакідаць коміты з рознымі метадамі апрацоўкі дадзеных і мадэлямі, для таго, каб потым абраць найлепшы і лёгка працягнуць працаваць з ім далей.
Па-другое, у прадакшэне гэта незаменная рэч - Вам трэба будзе ўвесь час глядзець на тое, як змяняецца Ваш код і ведаць, якая мадэль выдавала лепшыя вынікі, які код працаваў у канцы і што здарылася, з-за чаго ён перастаў працаваць або пачаў выдаваць няправільныя вынікі. Дзеля гэтага і існуюць коміты!
А таксама Вы можаце стварыць package свайго праекта, размясціўшы яго, напрыклад, на Gemfury, і далей проста імпартуючы функцыі з яго для іншых праектаў, каб не перапісваць іх 1000 разоў, але пра гэта крыху пазней.
Прынцып 2. Выразна абвяшчайце і ізалюйце dependencies
У кожным праекце ёсць розныя бібліятэкі, якія вы імпартуеце звонку для таго, каб недзе іх прымяніць. Ці то гэта бібліятэкі Python, ці бібліятэкі іншых моў розных прызначэнняў, ці сістэмныя прылады — Ваша задача:
- Выразна абвясціць dependencies, гэта значыць файл, у якім будуць прапісаны ўсе бібліятэкі, прылады, і іх версіі, якія выкарыстоўваюцца ў Вашым праекце і якія павінны быць усталяваныя (напрыклад, у Python гэта можна зрабіць з дапамогай Pipfile або requirements.txt. Спасылка, якая дазваляе добра разабрацца: )
- Ізаляваць dependencies спецыяльна для Вашай праграмы падчас распрацоўкі. Вы ж не хочаце ўвесь час мяняць версіі і пераўсталёўваць, напрыклад, Tensorflow?
Такім чынам, распрацоўшчыкі, якія будуць далучацца да Вашай каманды ў будучыні, змогуць хутка азнаёміцца з бібліятэкамі і іх версіямі, якія выкарыстоўваюцца ў Вашым праекце, а таксама ў Вас будзе магчымасць кіраваць версіямі і самімі бібліятэкамі, устаноўленымі для пэўнага праекта, што дапаможа Вам пазбегнуць. несумяшчальнасці бібліятэк ці іх версій.
Ваша дадатак таксама не павінна абапірацца на сістэмныя інструменты, якія могуць быць устаноўлены на пэўнай АС. Гэтыя прылады трэба таксама аб'яўляць у маніфэсце dependencies. Гэта трэба для таго, каб пазбегнуць сітуацый, калі версія прылад (а таксама іх наяўнасць), не супадае з сістэмнымі прыладамі вызначанай АС.
Такім чынам, нават калі практычна на ўсіх кампутарах можна выкарыстоўваць curl, тое варта ўсё роўна абвясціць яго ў dependencies, бо пры міграцыі на іншую платформу яго можа не быць ці версія будзе не той, якая Вам першапачаткова была патрэбна.
Напрыклад, Ваш requirements.txt можа выглядаць вось так:
# 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
Прынцып 3. Канфігурацыі
Многія чулі пра гісторыі, калі розныя хлопцы-дэвелаперы выпадкова загружалі код на GitHub у адкрытыя рэпазітары з паролямі і іншымі ключамі ад AWS, прачынаючыся на наступны дзень з запазычанасцю ў 6000 $, а то і з усімі 50000 $.
Канешне, гэтыя выпадкі крайнія, але вельмі паказальныя. Калі Вы захоўваеце Вашы ўліковыя дадзеныя ці іншыя дадзеныя, патрэбныя для канфігурацыі ўсярэдзіне кода — Вы здзяйсняеце памылку, і я думаю, не варта тлумачыць чаму.
Альтэрнатыва гэтаму - гэта захоўваць канфігурацыі ў зменных асяроддзі. Больш падрабязна аб зменных асяроддзя Вы можаце прачытаць .
Прыклады дадзеных, якія звычайна захоўваюць у зменных асяроддзі:
- Імёны даменаў
- API URL/URI's
- Публічныя і прыватныя ключы
- Кантакты (пошта, тэлефоны і тд)
Такім чынам, Вы можаце не змяняць увесь час код, калі Вашы зменныя канфігурацыі будуць змяняцца. Гэта дапаможа захаваць вам час, сілы і грошы.
Напрыклад, калі вы выкарыстоўваеце Kaggle API для правядзення тэстаў (напрыклад, спампоўваеце датае і праганяеце праз яго мадэль, каб пратэставаць пры запуску, што мадэль працуе добра), то прыватныя ключы ад Kaggle, такія як KAGGLE_USERNAME і KAGGLE_KEY трэба захоўваць у зменных асяроддзі.
Прынцып 4. Іншыя службы
Ідэя тут - гэта ствараць праграму такім чынам, каб не было адрозненняў паміж лакальнымі і іншымі рэсурсамі ў плане кода. Напрыклад, вы можаце падлучыць як лакальную MySQL, так і іншую. Тое ж самае тычыцца і розных API, такіх як Google Maps ці Twitter API.
Для таго, каб адключыць іншы сэрвіс або падлучыць іншы, трэба ўсяго толькі памяняць ключы ў канфігурацыі ў зменных асяроддзі, пра якую я распавядаў у пункце вышэй.
Так, напрыклад, замест таго, каб паказваць кожны раз шлях да файлаў з датасетамі ўсярэдзіне кода, лепш скарыстацца бібліятэкай pathlib і абвясціць шлях да датасет у config.py, каб не залежна ад таго, якім сэрвісам Вы карыстаецеся (напрыклад, CircleCI), праграма змагла даведацца шлях да датасетаў з улікам будынка новай файлавай сістэмы ў новым сэрвісе.
Прынцып 5. Зборка, рэліз, runtime
Многім людзям з Data Science карысна пампаваць навыкі па напісанні софту. Калі мы хочам, каб наша праграма як мага радзей "падала", і як мага даўжэй працавала без збояў, нам трэба падзяліць працэс рэлізу новай версіі на 3 этапы:
- этап зборкі. Вы пераўтворыце Ваш голы код з асобнымі рэсурсамі ў так званы пакет, які змяшчае ўвесь неабходны код і дадзеныя. Гэты пакет і называецца зборкай.
- этап рэлізу - да зборкі тут мы падлучаем наш config, без якога мы б не змаглі выпусціць нашу праграму. Цяпер гэта поўнасцю гатовы да запуску рэліз.
- Далей ідзе этап выканання. Тут мы выпускаем дадатак з дапамогай запуску неабходных працэсаў з нашага рэлізу.
Падобная сістэма рэлізу новых версій мадэлі або ўсяго пайплайна дазваляе падзяляць ролі паміж адміністратарамі і распрацоўшчыкамі, дазваляе адсочваць версіі і прадухіляе непажаданыя прыпынкі працы праграмы.
Для задачы рэлізу створана мноства розных сэрвісаў, у якіх Вы можаце запісаць працэсы для запуску самі ў .yml файл (напрыклад, у CircleCI гэта config.yml для забеспячэння самога працэсу). Wheely выдатна стварае пакет для праектаў.
Вы зможаце ствараць пакеты з рознымі версіямі вашай machine learning мадэлі, і пасля чаго пакетаваць іх і дасылацца да патрэбных пакетаў і іх версій, каб выкарыстоўваць адтуль функцыі, якія Вы напісалі. Гэта дапаможа Вам стварыць API для Вашай мадэлі, а Ваш пакет можна размясціць, напрыклад, на Gemfury.
Прынцып 6. Запускаем Вашу мадэль як адзін ці некалькі працэсаў
Прычым працэсы не павінны мець падзяляных дадзеных. Гэта значыць працэсы павінны існаваць асобна, а разнастайныя дадзеныя - асобна, напрыклад, на іншых службах па тыпе MySQL ці іншых, гледзячы на тое, што Вам трэба.
Гэта значыць дадзеныя ўсярэдзіне файлавай сістэмы працэсу захоўваць сапраўды не варта, інакш гэта можа прывесці да ачышчэння ад гэтых дадзеных пры наступным рэлізе/змене канфігурацый ці пераносу сістэмы, на якой працуе праграма.
Але ёсць выключэнне: для machine learning праектаў можна захоўваць кэш бібліятэк, каб не пераўсталёўваць іх кожны раз пры запуску новай версіі, калі дадатковых бібліятэк ці якіх-небудзь змен у іх версіях зроблена не было. Такім чынам, вы скароціце час запуску вашай мадэлі ў прамысловасці.
Каб запусціць мадэль як некалькі працэсаў, можна стварыць .yml файл, у якім вы як раз і пакажаце неабходныя працэсы і іх паслядоўнасць.
Прынцып 7. Утылізавальнасць
Працэсы, якія працуюць у вашым дадатку з мадэллю, павінны лёгка запускацца і спыняцца. Такім чынам, гэта дазволіць хутка разгортваць змены кода, змены канфігурацый, хутка і гнутка маштабавацца і прадухіліць ад магчымых паломак працоўнай версіі.
Гэта значыць ваш працэс з мадэллю павінен:
- Мінімізаваць час запуску. У ідэале час запуску (ад моманту, калі была пададзена каманда запуску да моманту, калі працэс прыйдзе ў працоўны стан) павінна мець не больш за некалькі секунд. Кэшаванне бібліятэк, апісанае вышэй - гэта адна з методык памяншэння часу запуску.
- Завяршацца карэктна. Гэта значыць фактычна прыпыняецца праслухоўванне порта сэрвісу, і новыя запыты, пададзеныя ў гэты порт, не будуць апрацоўвацца. Тут ужо трэба альбо наладжваць нядрэнную сувязь з DevOps інжынерамі, ці самому разумець, як гэта працуе (пажадана, вядома, другое, але сувязь падтрымліваць трэба заўсёды, у любым праекце!)
Прынцып 8. Бесперапыннае разгортванне/інтэграцыя
У многіх кампаніях выкарыстоўваюць падзел паміж камандамі распрацоўкі прыкладання і яго разгортвання (якая робіць прыкладанне даступным для канчатковых карыстальнікаў). Гэта можа моцна запавольваць распрацоўку софту і прагрэсу ў яго паляпшэнні. А таксама гэта псуе культуру DevOps, дзе распрацоўка і інтэграцыя, груба кажучы, аб'яднаны.
Таму гэты прынцып абвяшчае аб тым, што асяроддзе Вашай распрацоўкі павінна быць максімальна набліжана да асяроддзя Вашага прадакшэна.
Гэта дазволіць:
- Знізіць час рэлізу ў дзясяткі разоў
- Знізіць колькасць памылак з-за несумяшчальнасці кода.
- Таксама гэта дазваляе знізіць нагрузку на персанал, бо распрацоўшчыкі і людзі, якія разгортваюць прыкладанне - зараз адна каманда.
Інструменты, якія дазваляюць з гэтым працаваць – CircleCI, Travis CI, GitLab CI і іншыя.
Вы зможаце хутка рабіць дадаткі для мадэлі, абнаўляць яе, і адразу ж запускаць, пры гэтым будзе лёгка, у выпадку збояў, вярнуцца вельмі хутка да працоўнай версіі, так, каб канчатковы карыстач нават гэтага не заўважыў. Асабліва гэта можна лёгка і хутка зрабіць, калі ў вас ёсць добрыя тэсты.
Мінімізуйце адрозненні!!!
Прынцып 9. Вашы логі
Logs (або "Логі") - гэта запісаныя звычайна ў тэкставым фармаце падзеі, якія адбываюцца ўнутры прыкладання (струмень падзей). Просты прыклад: "2020/02/02 - узровень сістэмы - імя працэсу". Яны створаны для таго, каб распрацоўшчык мог літаральна бачыць тое, што адбываецца, калі праграма працуе. Ён бачыць ход працэсаў, і разумее, ці такі ён, як сам распрацоўшчык задумваў.
Гэты прынцып абвяшчае аб тым, што не варта захоўваць свае логі ўсярэдзіне вашай файлавай сістэмы – іх трэба проста "выводзіць на экран", напрыклад рабіць гэта ў стандартнай выснове сістэмы stdout. І за плынню такім чынам можна будзе сачыць у тэрмінале падчас распрацоўкі.
Ці значыць гэта, што не трэба захоўваць логі зусім? Канечне не. Проста гэтым не павінна займацца Ваша прыкладанне - пакіньце гэта іншым сэрвісам. Ваша прыкладанне можа толькі перанакіраваць логі ў пэўны файл ці тэрмінал для прагляду ў рэальным часе ці перанакіраваць яго ў сістэму для захоўвання дадзеных агульнага прызначэння (напрыклад, Hadoop). Само Ваша прыкладанне не павінна захоўваць ці ўзаемадзейнічаць з логамі.
Прынцып 10. Тэстуйце!
Для прамысловага machine learning гэтая фаза вельмі важная, бо Вам трэба зразумець, што мадэль працуе правільна і выдае тое, што Вы жадалі.
Тэсты можна стварыць з дапамогай pytest, і пратэставаць з дапамогай невялікага датасета, калі ў вас задача рэгрэсіі/класіфікацыі.
Не забывайце ставіць аднолькавы seed для deep learning мадэляў, каб яны не выдавалі ўвесь час розныя вынікі.
Гэта было кароткае апісанне 10 прынцыпаў, і, вядома, складана карыстацца імі не паспрабаваўшы і не ўбачыўшы тое, як яны працуюць, таму гэты артыкул - гэта толькі пралог да серыі цікавых артыкулаў, у якія я буду раскрываць тое, як ствараць прамысловыя machine learning мадэлі. , як іх інтэграваць у сістэмы, і як гэтыя прынцыпы могуць спрасціць нам усім жыццё.
Я таксама пастараюся выкарыстоўваць крутыя прынцыпы, якія нехта па жаданні можа пакінуць у каментарах.
Крыніца: habr.com