Industrial Machine Learning: 10 Mga Prinsipyo sa Disenyo
Sa ngayon, ang mga bagong serbisyo, application at iba pang mahahalagang programa ay nilikha araw-araw na ginagawang posible na lumikha ng mga hindi kapani-paniwalang bagay: mula sa software para sa pagkontrol ng isang SpaceX rocket hanggang sa pakikipag-ugnayan sa isang kettle sa susunod na silid sa pamamagitan ng isang smartphone.
At, kung minsan, ang bawat baguhang programmer, siya man ay isang madamdaming startupper o isang ordinaryong Full Stack o Data Scientist, maaga o huli ay napagtanto na may ilang mga patakaran para sa programming at paglikha ng software na lubos na nagpapasimple sa buhay.
Sa artikulong ito, maikli kong ilalarawan ang 10 prinsipyo kung paano magprograma ng pang-industriyang machine learning para madali itong maisama sa isang application/serbisyo, batay sa 12-factor na pamamaraan ng App. . Ang aking inisyatiba ay upang madagdagan ang kamalayan ng diskarteng ito, na makakatulong sa maraming mga developer at mga tao sa data science.
Ang artikulong ito ay isang prologue sa isang serye ng mga artikulo tungkol sa industriyal na Machine Learning. Sa kanila ay pag-uusapan ko pa ang tungkol sa kung paano aktwal na gumawa ng isang modelo at ilunsad ito sa produksyon, lumikha ng isang API para dito, pati na rin ang mga halimbawa mula sa iba't ibang mga lugar at kumpanya na may built-in na ML sa kanilang mga system.
Prinsipyo 1: Isang code base
Ang ilang mga programmer sa mga unang yugto, dahil sa katamaran upang malaman ito (o para sa ilang sariling dahilan), ay nakakalimutan ang tungkol sa Git. Nakalimutan nila ang salita, iyon ay, nagtatapon sila ng mga file sa isa't isa sa drive/nagtapon lang ng text/nagpapadala ng mga kalapati, o hindi nila iniisip ang kanilang daloy ng trabaho, at ipinangako ang bawat isa sa kanilang sariling sangay, at pagkatapos ay sa master.
Ang prinsipyong ito ay nagsasaad: magkaroon ng isang codebase at maraming deployment.
Maaaring gamitin ang Git kapwa sa produksyon at sa pananaliksik at pag-unlad (R&D), kung saan hindi ito madalas na ginagamit.
Halimbawa, sa yugto ng R&D maaari kang mag-iwan ng mga commit na may iba't ibang paraan at modelo sa pagpoproseso ng data, upang piliin ang pinakamahusay at madaling magpatuloy sa pagtatrabaho dito.
Pangalawa, sa produksyon ito ay isang bagay na hindi maaaring palitan - kailangan mong patuloy na tingnan kung paano nagbabago ang iyong code at malaman kung aling modelo ang gumawa ng pinakamahusay na mga resulta, kung aling code ang gumana sa huli at kung ano ang nangyari na naging dahilan upang ito ay tumigil sa pagtatrabaho o magsimulang gumawa ng mga maling resulta . Para yan sa commit!
Maaari ka ring lumikha ng isang pakete ng iyong proyekto, ilagay ito, halimbawa, sa Gemfury, at pagkatapos ay mag-import lamang ng mga function mula dito para sa iba pang mga proyekto, upang hindi muling isulat ang mga ito ng 1000 beses, ngunit higit pa sa paglaon.
Prinsipyo 2: Malinaw na ideklara at ihiwalay ang mga dependency
Ang bawat proyekto ay may iba't ibang mga aklatan na ini-import mo mula sa labas upang mailapat ang mga ito sa isang lugar. Kung ito man ay mga aklatan ng Python, o mga aklatan ng iba pang mga wika para sa iba't ibang layunin, o mga tool ng system - ang iyong gawain ay:
- Malinaw na nagdedeklara ng mga dependency, iyon ay, isang file na maglalaman ng lahat ng mga library, tool, at kanilang mga bersyon na ginagamit sa iyong proyekto at dapat i-install (halimbawa, sa Python maaari itong gawin gamit ang Pipfile o requirements.txt. A link na nagbibigay-daan sa mabuting maunawaan: )
- Ihiwalay ang mga dependency na partikular para sa iyong programa sa panahon ng pag-unlad. Hindi mo nais na patuloy na baguhin ang mga bersyon at muling i-install, halimbawa, Tensorflow?
Sa ganitong paraan, mabilis na magiging pamilyar ang mga developer na sasali sa iyong team sa hinaharap sa mga library at sa kanilang mga bersyon na ginagamit sa iyong proyekto, at magkakaroon ka rin ng pagkakataong pamahalaan ang mga bersyon at library mismo na naka-install para sa isang partikular na proyekto, na makakatulong sa iyong maiwasan ang hindi pagkakatugma ng mga aklatan o ng kanilang mga bersyon.
Hindi rin dapat umasa ang iyong application sa mga tool ng system na maaaring mai-install sa isang partikular na OS. Ang mga tool na ito ay dapat ding ideklara sa mga dependencies manifest. Ito ay kinakailangan upang maiwasan ang mga sitwasyon kung saan ang bersyon ng mga tool (pati na rin ang kanilang availability) ay hindi tumutugma sa mga tool ng system ng isang partikular na OS.
Kaya, kahit na ang curl ay maaaring gamitin sa halos lahat ng mga computer, dapat mo pa ring ideklara ito sa mga dependency, dahil kapag lumipat sa ibang platform ay maaaring wala ito roon o ang bersyon ay hindi ang orihinal na kailangan mo.
Halimbawa, maaaring ganito ang hitsura ng iyong 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
Prinsipyo 3: Mga Configuration
Marami ang nakarinig ng mga kwento ng iba't ibang mga developer na hindi sinasadyang nag-upload ng code sa GitHub sa mga pampublikong repository na may mga password at iba pang mga susi mula sa AWS, na nagising kinabukasan na may utang na $6000, o kahit na $50000.
Siyempre, ang mga kasong ito ay sukdulan, ngunit napaka makabuluhan. Kung iniimbak mo ang iyong mga kredensyal o iba pang data na kailangan para sa pagsasaayos sa loob ng code, nagkakamali ka, at sa palagay ko ay hindi na kailangang ipaliwanag kung bakit.
Ang isang alternatibo dito ay ang pag-imbak ng mga configuration sa mga variable ng kapaligiran. Maaari kang magbasa nang higit pa tungkol sa mga variable ng kapaligiran .
Mga halimbawa ng data na karaniwang nakaimbak sa mga variable ng kapaligiran:
- Mga domain name
- Mga URL ng API/URI
- Pampubliko at pribadong mga susi
- Mga contact (mail, telepono, atbp.)
Sa ganitong paraan, hindi mo kailangang patuloy na baguhin ang code kung magbabago ang iyong mga variable ng configuration. Makakatulong ito sa iyo na makatipid ng oras, pagsisikap at pera.
Halimbawa, kung ginagamit mo ang Kaggle API upang magsagawa ng mga pagsubok (halimbawa, i-download ang software at patakbuhin ang modelo sa pamamagitan nito upang subukan kapag tumatakbo na gumagana nang maayos ang modelo), ang mga pribadong key mula sa Kaggle, gaya ng KAGGLE_USERNAME at KAGGLE_KEY, ay dapat nakaimbak sa mga variable ng kapaligiran.
Prinsipyo 4: Mga Serbisyo ng Third Party
Ang ideya dito ay lumikha ng programa sa paraang walang pagkakaiba sa pagitan ng lokal at third-party na mapagkukunan sa mga tuntunin ng code. Halimbawa, maaari mong ikonekta ang parehong lokal na MySQL at mga third-party. Ang parehong napupunta para sa iba't ibang mga API tulad ng Google Maps o Twitter API.
Upang hindi paganahin ang isang serbisyo ng third-party o kumonekta sa isa pa, kailangan mo lamang baguhin ang mga susi sa pagsasaayos sa mga variable ng kapaligiran, na pinag-usapan ko sa talata sa itaas.
Kaya, halimbawa, sa halip na tukuyin ang path sa mga file na may mga dataset sa loob ng code sa bawat oras, mas mainam na gamitin ang pathlib library at ideklara ang path sa mga dataset sa config.py, upang kahit anong serbisyo ang iyong gamitin (para sa halimbawa, CircleCI), nalaman ng programa ang landas patungo sa mga dataset na isinasaalang-alang ang istraktura ng bagong file system sa bagong serbisyo.
Prinsipyo 5. Bumuo, bitawan, runtime
Nakikita ng maraming tao sa Data Science na kapaki-pakinabang na pagbutihin ang kanilang mga kasanayan sa pagsulat ng software. Kung gusto naming mag-crash ang aming programa nang madalang hangga't maaari at gumana nang walang pagkabigo hangga't maaari, kailangan naming hatiin ang proseso ng pagpapalabas ng bagong bersyon sa 3 yugto:
- Stage pagtitipon. Binabago mo ang iyong bare code gamit ang mga indibidwal na mapagkukunan sa isang tinatawag na package na naglalaman ng lahat ng kinakailangang code at data. Ang paketeng ito ay tinatawag na isang pagpupulong.
- Stage pakawalan β dito namin ikinonekta ang aming config sa assembly, kung wala ito ay hindi namin mailalabas ang aming programa. Ngayon ito ay isang ganap na handa-sa-ilunsad na release.
- Susunod na ang yugto katuparan. Dito namin inilabas ang application sa pamamagitan ng pagpapatakbo ng mga kinakailangang proseso mula sa aming paglabas.
Ang ganitong sistema para sa pagpapalabas ng mga bagong bersyon ng isang modelo o ang buong pipeline ay nagbibigay-daan sa iyo na paghiwalayin ang mga tungkulin sa pagitan ng mga administrator at developer, pinapayagan kang subaybayan ang mga bersyon at maiwasan ang mga hindi gustong paghinto ng programa.
Para sa pagpapalabas na gawain, maraming iba't ibang serbisyo ang nalikha kung saan maaari kang magsulat ng mga proseso upang patakbuhin ang iyong sarili sa isang .yml file (halimbawa, sa CircleCI ito ay config.yml upang suportahan ang proseso mismo). Mahusay si Wheely sa paggawa ng mga pakete para sa mga proyekto.
Maaari kang gumawa ng mga package na may iba't ibang bersyon ng iyong machine learning model, at pagkatapos ay i-package ang mga ito at sumangguni sa mga kinakailangang package at mga bersyon ng mga ito para magamit ang mga function na isinulat mo mula doon. Makakatulong ito sa iyong lumikha ng API para sa iyong modelo, at ang iyong package ay maaaring i-host sa Gemfury, halimbawa.
Prinsipyo 6. Patakbuhin ang iyong modelo bilang isa o higit pang mga proseso
Bukod dito, ang mga proseso ay hindi dapat may nakabahaging data. Iyon ay, ang mga proseso ay dapat na umiiral nang hiwalay, at lahat ng uri ng data ay dapat na umiiral nang hiwalay, halimbawa, sa mga serbisyo ng third-party tulad ng MySQL o iba pa, depende sa kung ano ang kailangan mo.
Iyon ay, tiyak na hindi sulit ang pag-imbak ng data sa loob ng proseso ng file system, kung hindi, ito ay maaaring humantong sa pag-clear ng data na ito sa susunod na paglabas/pagbabago ng mga configuration o paglilipat ng system kung saan tumatakbo ang program.
Ngunit mayroong isang pagbubukod: para sa mga proyekto sa pag-aaral ng makina, maaari kang mag-imbak ng isang cache ng mga aklatan upang hindi muling mai-install ang mga ito sa tuwing maglulunsad ka ng bagong bersyon, kung walang karagdagang mga aklatan o anumang mga pagbabago ang ginawa sa kanilang mga bersyon. Sa ganitong paraan, mababawasan mo ang oras na kinakailangan upang ilunsad ang iyong modelo sa industriya.
Upang patakbuhin ang modelo bilang ilang mga proseso, maaari kang lumikha ng isang .yml file kung saan tinukoy mo ang mga kinakailangang proseso at ang kanilang pagkakasunud-sunod.
Prinsipyo 7: Recyclable
Ang mga prosesong tumatakbo sa iyong modelong application ay dapat na madaling simulan at ihinto. Kaya, ito ay magbibigay-daan sa iyong mabilis na mag-deploy ng mga pagbabago sa code, mga pagbabago sa configuration, mabilis at flexible na sukat, at maiwasan ang mga posibleng breakdown ng gumaganang bersyon.
Iyon ay, ang iyong proseso sa modelo ay dapat:
- I-minimize ang oras ng pagsisimula. Sa isip, ang oras ng pagsisimula (mula sa sandaling inilabas ang utos ng startup hanggang sa sandaling gumana ang proseso) ay dapat na hindi hihigit sa ilang segundo. Ang pag-cache ng library, na inilarawan sa itaas, ay isang pamamaraan para sa pagbawas ng oras ng pagsisimula.
- Tapusin ng tama. Ibig sabihin, talagang sinuspinde ang pakikinig sa port ng serbisyo, at hindi mapoproseso ang mga bagong kahilingang isinumite sa port na ito. Dito kailangan mong mag-set up ng mahusay na komunikasyon sa mga inhinyero ng DevOps, o maunawaan kung paano ito gumagana sa iyong sarili (mas mabuti, siyempre, ang huli, ngunit ang komunikasyon ay dapat palaging mapanatili, sa anumang proyekto!)
Prinsipyo 8: Patuloy na Deployment/Pagsasama-sama
Maraming mga kumpanya ang gumagamit ng isang paghihiwalay sa pagitan ng pagbuo ng application at mga koponan sa pag-deploy (ginagawa ang application na magagamit sa mga end user). Ito ay lubos na makapagpapabagal sa pagbuo ng software at pag-unlad sa pagpapabuti nito. Sinisira din nito ang kultura ng DevOps, kung saan pinagsama-sama ang pag-unlad at pagsasama-sama.
Samakatuwid, ang prinsipyong ito ay nagsasaad na ang iyong kapaligiran sa pag-unlad ay dapat na mas malapit hangga't maaari sa iyong kapaligiran sa produksyon.
Ito ay magpapahintulot sa:
- Bawasan ang oras ng paglabas ng sampu-sampung beses
- Bawasan ang bilang ng mga error dahil sa hindi pagkakatugma ng code.
- Binabawasan din nito ang workload sa mga kawani, dahil ang mga developer at mga taong nagde-deploy ng application ay isa na ngayong isang team.
Ang mga tool na nagbibigay-daan sa iyong magtrabaho dito ay ang CircleCI, Travis CI, GitLab CI at iba pa.
Mabilis kang makakagawa ng mga karagdagan sa modelo, i-update ito, at ilunsad ito kaagad, habang ito ay magiging madali, sa kaso ng mga pagkabigo, upang bumalik nang napakabilis sa gumaganang bersyon, upang hindi ito mapansin ng end user. Magagawa ito lalo na madali at mabilis kung mayroon kang magagandang pagsusulit.
I-minimize ang mga pagkakaiba!!!
Prinsipyo 9. Ang iyong mga tala
Ang mga log (o "Mga Log") ay mga kaganapan, kadalasang naitala sa format ng teksto, na nangyayari sa loob ng application (stream ng kaganapan). Isang simpleng halimbawa: "2020-02-02 - antas ng system - pangalan ng proseso." Idinisenyo ang mga ito upang literal na makita ng developer kung ano ang nangyayari kapag tumatakbo ang programa. Nakikita niya ang pag-usad ng mga proseso at nauunawaan niya kung ito ay ayon sa inilaan mismo ng developer.
Ang prinsipyong ito ay nagsasaad na hindi mo dapat iimbak ang iyong mga log sa loob ng iyong file system - dapat mo lang "i-output" ang mga ito sa screen, halimbawa, gawin ito sa karaniwang output ng system. At sa ganitong paraan posible na masubaybayan ang daloy sa terminal sa panahon ng pag-unlad.
Nangangahulugan ba ito na hindi na kailangang mag-save ng mga log? Syempre hindi. Hindi ito dapat gawin ng iyong aplikasyonβiwanan ito sa mga serbisyo ng third-party. Ang iyong application ay maaari lamang magpasa ng mga log sa isang partikular na file o terminal para sa real-time na pagtingin, o ipasa ito sa isang pangkalahatang layunin na sistema ng pag-iimbak ng data (tulad ng Hadoop). Ang iyong application mismo ay hindi dapat mag-imbak o makipag-ugnayan sa mga log.
Prinsipyo 10. Subukan!
Para sa pang-industriyang machine learning, ang yugtong ito ay napakahalaga, dahil kailangan mong maunawaan na gumagana nang tama ang modelo at gumagawa ng gusto mo.
Maaaring malikha ang mga pagsubok gamit ang pytest, at masuri gamit ang isang maliit na dataset kung mayroon kang isang regression/classification task.
Huwag kalimutang itakda ang parehong binhi para sa mga modelo ng malalim na pag-aaral upang hindi sila palaging makagawa ng magkakaibang mga resulta.
Ito ay isang maikling paglalarawan ng 10 mga prinsipyo, at, siyempre, mahirap gamitin ang mga ito nang hindi sinusubukan at nakikita kung paano gumagana ang mga ito, kaya ang artikulong ito ay isang paunang salita lamang sa isang serye ng mga kagiliw-giliw na artikulo kung saan ibubunyag ko kung paano lumikha pang-industriya na machine learning models , kung paano isama ang mga ito sa mga system, at kung paano mapadali ng mga prinsipyong ito ang buhay para sa ating lahat.
Susubukan ko ring gumamit ng mga cool na prinsipyo na maaaring iwan ng sinuman sa mga komento kung nais nila.
Pinagmulan: www.habr.com