Iðnaðarvélanám: 10 hönnunarreglur
Nú á dögum eru nýjar þjónustur, forrit og önnur mikilvæg forrit búin til á hverjum degi sem gerir það mögulegt að búa til ótrúlega hluti: allt frá hugbúnaði til að stjórna SpaceX eldflaug til að hafa samskipti við ketil í næsta herbergi í gegnum snjallsíma.
Og stundum kemst hver nýliði forritari, hvort sem hann er ástríðufullur startuper eða venjulegur Full Stack eða Data Scientist, fyrr eða síðar að því að það eru ákveðnar reglur um forritun og gerð hugbúnaðar sem einfalda lífið til muna.
Í þessari grein mun ég lýsa stuttlega 10 meginreglum um hvernig á að forrita iðnaðarvélanám þannig að auðvelt sé að samþætta það inn í forrit/þjónustu, byggt á 12 þátta App aðferðafræðinni. . Mitt frumkvæði er að auka vitundina um þessa tækni, sem getur hjálpað mörgum forriturum og gagnavísindafólki.
Þessi grein er formáli að röð greina um iðnaðarvélanám. Í þeim mun ég frekar tala um hvernig á að búa til líkan og setja það í framleiðslu, búa til API fyrir það, sem og dæmi frá ýmsum sviðum og fyrirtækjum sem hafa innbyggt ML í kerfum sínum.
Meginregla 1: Einn kóðagrunnur
Sumir forritarar á fyrstu stigum, af leti til að átta sig á því (eða af einhverjum ástæðum þeirra), gleyma Git. Annaðhvort gleyma þeir orðinu algjörlega, það er að segja að þeir henda skrám hver til annars í drifinu/bara henda texta/senda með dúfum, eða þeir hugsa ekki í gegnum vinnuflæðið sitt og skuldbinda sig hver í sína grein og síðan í húsbóndi.
Þessi meginregla segir: hafa einn kóðagrunn og margar dreifingar.
Git er hægt að nota bæði í framleiðslu og í rannsóknum og þróun (R&D), þar sem það er ekki notað svo oft.
Til dæmis, í R&D áfanganum geturðu skilið eftir skuldbindingar með mismunandi gagnavinnsluaðferðum og líkönum, til að velja þá bestu og auðveldlega halda áfram að vinna með það frekar.
Í öðru lagi, í framleiðslu er þetta óbætanlegur hlutur - þú þarft stöðugt að skoða hvernig kóðinn þinn breytist og vita hvaða líkan skilaði bestum árangri, hvaða kóði virkaði á endanum og hvað gerðist sem olli því að hann hætti að virka eða byrjaði að gefa rangar niðurstöður . Til þess eru skuldbindingar!
Þú getur líka búið til pakka af verkefninu þínu, sett það td á Gemfury og svo einfaldlega flutt inn aðgerðir úr því fyrir önnur verkefni, til að endurskrifa þau ekki 1000 sinnum, heldur meira um það síðar.
Meginregla 2: Lýstu skýrt frá og einangraðu ósjálfstæði
Hvert verkefni hefur mismunandi bókasöfn sem þú flytur inn að utan til að nota þau einhvers staðar. Hvort sem það eru Python bókasöfn, eða bókasöfn annarra tungumála í ýmsum tilgangi, eða kerfisverkfæri - verkefni þitt er:
- Lýstu skýrt yfir ósjálfstæði, þ.e. skrá sem mun innihalda öll söfn, verkfæri og útgáfur þeirra sem eru notaðar í verkefninu þínu og sem verður að setja upp (td í Python er hægt að gera þetta með Pipfile eða requirements.txt. A hlekkur sem gerir gott að skilja: )
- Einangraðu ósjálfstæði sérstaklega fyrir forritið þitt meðan á þróun stendur. Þú vilt ekki skipta stöðugt um útgáfur og setja upp aftur, til dæmis, Tensorflow?
Þannig munu forritarar sem munu ganga til liðs við teymið þitt í framtíðinni verða fljótt að kynnast söfnunum og útgáfum þeirra sem eru notaðar í verkefninu þínu, og þú munt einnig hafa tækifæri til að stjórna útgáfunum og bókasöfnunum sjálfum sem eru uppsettar fyrir tiltekið verkefni, sem mun hjálpa þér að forðast ósamrýmanleika bókasöfn eða útgáfur þeirra.
Forritið þitt ætti heldur ekki að treysta á kerfisverkfæri sem kunna að vera sett upp á tilteknu stýrikerfi. Þessum verkfærum verður einnig að gefa upp í upplýsingaskránni um ósjálfstæði. Þetta er nauðsynlegt til að forðast aðstæður þar sem útgáfan af verkfærunum (sem og aðgengi þeirra) passar ekki við kerfisverkfæri tiltekins stýrikerfis.
Þannig að jafnvel þótt hægt sé að nota curl á næstum öllum tölvum, ættir þú samt að lýsa því yfir í ósjálfstæði, þar sem þegar þú ert að flytja yfir á annan vettvang getur verið að það sé ekki til staðar eða útgáfan verður ekki sú sem þú þurftir upphaflega.
Til dæmis gæti requirements.txt litið svona út:
# 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
Meginregla 3: Stillingar
Margir hafa heyrt sögur af ýmsum forritara sem hlaða óvart kóða til GitHub í opnar geymslur með lykilorðum og öðrum lyklum frá AWS, vakna daginn eftir með skuld upp á $6000, eða jafnvel $50000.
Auðvitað eru þessi tilvik öfgakennd, en mjög mikilvæg. Ef þú geymir skilríki þín eða önnur gögn sem þarf til að stilla upp í kóðanum, þá ertu að gera mistök og ég held að það sé engin þörf á að útskýra hvers vegna.
Annar valkostur við þetta er að geyma stillingar í umhverfisbreytum. Þú getur lesið meira um umhverfisbreytur .
Dæmi um gögn sem eru venjulega geymd í umhverfisbreytum:
- Lén
- API vefslóðir/URI
- Almennir og einkalyklar
- Tengiliðir (póstur, símar osfrv.)
Þannig þarftu ekki að breyta kóðanum stöðugt ef stillingarbreyturnar þínar breytast. Þetta mun hjálpa þér að spara þér tíma, fyrirhöfn og peninga.
Til dæmis, ef þú notar Kaggle API til að framkvæma prófanir (til dæmis, halaðu niður hugbúnaðinum og keyrðu líkanið í gegnum það til að prófa þegar þú keyrir að líkanið virki vel), þá ættu einkalyklar frá Kaggle, eins og KAGGLE_USERNAME og KAGGLE_KEY, að vera geymdar í umhverfisbreytum.
Meginregla 4: Þjónusta þriðja aðila
Hugmyndin hér er að búa til forritið á þann hátt að það sé enginn munur á staðbundnum og þriðja aðila hvað varðar kóða. Til dæmis geturðu tengt bæði staðbundna MySQL og þriðja aðila. Sama gildir um ýmis API eins og Google Maps eða Twitter API.
Til að slökkva á þjónustu þriðja aðila eða tengja aðra þarftu bara að breyta lyklunum í uppsetningunni í umhverfisbreytunum, sem ég talaði um í málsgreininni hér að ofan.
Svo, til dæmis, í stað þess að tilgreina slóðina að skrám með gagnasöfnum inni í kóðanum hverju sinni, er betra að nota pathlib bókasafnið og lýsa slóðinni að gagnasöfnunum í config.py, þannig að sama hvaða þjónustu þú notar (fyrir td CircleCI), gat forritið fundið leiðina að gagnasöfnunum með hliðsjón af uppbyggingu nýja skráarkerfisins í nýju þjónustunni.
Meginregla 5. Byggja, gefa út, keyrslutíma
Mörgum í gagnafræði finnst gagnlegt að bæta hugbúnaðarritunarhæfileika sína. Ef við viljum að forritið okkar hrynji eins sjaldan og mögulegt er og virki án bilana eins lengi og mögulegt er, þurfum við að skipta ferlinu við að gefa út nýja útgáfu í 3 stig:
- Svið þing. Þú umbreytir berum kóða þínum með einstökum auðlindum í svokallaðan pakka sem inniheldur allan nauðsynlegan kóða og gögn. Þessi pakki er kallaður samkoma.
- Svið slepptu — hér tengjum við stillingar okkar við samsetninguna, án hennar gætum við ekki gefið út forritið okkar. Núna er þetta algjörlega tilbúið útgáfa.
- Næst kemur sviðið uppfyllingu. Hér gefum við út forritið með því að keyra nauðsynlega ferla frá útgáfu okkar.
Slíkt kerfi til að gefa út nýjar útgáfur af líkani eða allri leiðslunni gerir þér kleift að aðskilja hlutverk milli stjórnenda og þróunaraðila, gerir þér kleift að fylgjast með útgáfum og kemur í veg fyrir óæskileg stöðvun forritsins.
Fyrir útgáfuverkefnið hafa verið búnar til margar mismunandi þjónustur þar sem þú getur skrifað ferli til að keyra sjálfan þig í .yml skrá (td í CircleCI er þetta config.yml til að styðja við ferlið sjálft). Wheely er frábær í að búa til pakka fyrir verkefni.
Þú getur búið til pakka með mismunandi útgáfum af vélanámslíkani þínu og pakkað þeim síðan og vísað í nauðsynlega pakka og útgáfur þeirra til að nota aðgerðirnar sem þú skrifaðir þaðan. Þetta mun hjálpa þér að búa til API fyrir líkanið þitt og pakkann þinn er til dæmis hægt að hýsa á Gemfury.
Meginregla 6. Keyrðu líkanið þitt sem eitt eða fleiri ferli
Þar að auki ættu ferli ekki að hafa samnýtt gögn. Það er að segja að ferli verða að vera til sérstaklega og alls kyns gögn verða að vera til sérstaklega, til dæmis á þjónustu þriðja aðila eins og MySQL eða öðrum, allt eftir því hvað þú þarft.
Það er, það er örugglega ekki þess virði að geyma gögn inni í ferli skráarkerfinu, annars gæti þetta leitt til hreinsunar á þessum gögnum við næstu útgáfu/breytingu á stillingum eða flutning á kerfinu sem forritið keyrir á.
En það er undantekning: fyrir vélanámsverkefni geturðu geymt skyndiminni af bókasöfnum til að setja þau ekki upp aftur í hvert skipti sem þú setur nýja útgáfu af stað, ef engin viðbótarsöfn eða breytingar hafa verið gerðar á útgáfum þeirra. Þannig muntu draga úr þeim tíma sem það tekur að koma líkaninu þínu á markað í iðnaði.
Til að keyra líkanið sem nokkur ferli geturðu búið til .yml skrá þar sem þú tilgreinir nauðsynlega ferla og röð þeirra.
Meginregla 7: Endurvinnanleiki
Ferlarnir sem keyra í líkanaforritinu þínu ættu að vera auðvelt að hefja og stöðva. Þannig mun þetta gera þér kleift að dreifa kóðabreytingum, stillingarbreytingum á fljótlegan og sveigjanlegan hátt, og koma í veg fyrir hugsanlegar bilanir á vinnuútgáfunni.
Það er, ferlið þitt með líkaninu ætti að:
- Lágmarka ræsingartíma. Helst ætti ræsingartími (frá því augnabliki sem ræsingarskipunin var gefin út þar til ferlið byrjar) ekki að vera meira en nokkrar sekúndur. Skyndiminni bókasafns, sem lýst er hér að ofan, er ein tækni til að draga úr ræsingartíma.
- Enda rétt. Það er að segja að hlustun á þjónustugáttinni er í raun stöðvuð og nýjar beiðnir sem sendar eru inn á þessa höfn verða ekki afgreiddar. Hér þarftu annað hvort að setja upp góð samskipti við DevOps verkfræðinga, eða skilja hvernig það virkar sjálfur (helst, auðvitað, hið síðarnefnda, en samskipti ættu alltaf að vera viðhaldið, í hvaða verkefni sem er!)
Meginregla 8: Stöðug dreifing/samþætting
Mörg fyrirtæki nota aðskilnað á milli forritaþróunar- og dreifingarteyma (gera forritið aðgengilegt fyrir notendur). Þetta getur mjög hægt á þróun hugbúnaðar og framfarir í að bæta hann. Það spillir líka DevOps menningu, þar sem þróun og samþætting eru í grófum dráttum sameinuð.
Þess vegna segir þessi meginregla að þróunarumhverfi þitt ætti að vera eins nálægt framleiðsluumhverfi þínu og mögulegt er.
Þetta mun leyfa:
- Minnkaðu útgáfutímann um tugi sinnum
- Fækkaðu fjölda villna vegna ósamrýmanleika kóða.
- Þetta dregur einnig úr vinnuálagi á starfsfólk, þar sem verktaki og fólk sem innleiðir forritið er nú eitt teymi.
Verkfæri sem gera þér kleift að vinna með þetta eru CircleCI, Travis CI, GitLab CI og fleiri.
Þú getur fljótt gert viðbætur við líkanið, uppfært það og ræst það strax, á meðan það verður auðvelt, ef bilanir koma upp, að fara mjög fljótt aftur í virku útgáfuna, svo að endir notandi tekur ekki einu sinni eftir því. Þetta er hægt að gera sérstaklega auðveldlega og fljótt ef þú ert með góð próf.
Lágmarka muninn!!!
Meginregla 9. Dagskrár þínar
Logs (eða „Logs“) eru atburðir, venjulega skráðir á textasniði, sem eiga sér stað innan forritsins (atburðarstraumur). Einfalt dæmi: "2020-02-02 - kerfisstig - ferli nafn." Þau eru hönnuð þannig að verktaki geti bókstaflega séð hvað er að gerast þegar forritið er í gangi. Hann sér framvindu ferla og skilur hvort það sé eins og framkvæmdaraðili sjálfur ætlaði sér.
Þessi regla segir að þú ættir ekki að geyma annálana þína inni í skráarkerfinu þínu - þú ættir bara að „útkasta“ þeim á skjáinn, til dæmis, gerðu þetta á venjulegu úttak kerfisins. Og þannig verður hægt að fylgjast með rennsli í flugstöðinni meðan á uppbyggingu stendur.
Þýðir þetta að það sé engin þörf á að vista logs? Auðvitað ekki. Forritið þitt ætti bara ekki að gera þetta - skildu það eftir þjónustu þriðja aðila. Forritið þitt getur aðeins framsent annála til tiltekinnar skráar eða flugstöðvar til að skoða það í rauntíma, eða framsent það í almennt gagnageymslukerfi (eins og Hadoop). Forritið þitt sjálft ætti ekki að geyma eða hafa samskipti við annála.
Meginregla 10. Próf!
Fyrir iðnaðarvélanám er þessi áfangi afar mikilvægur, þar sem þú þarft að skilja að líkanið virkar rétt og framleiðir það sem þú vildir.
Hægt er að búa til próf með því að nota pytest og prófa með því að nota lítið gagnasafn ef þú ert með aðhvarfs-/flokkunarverkefni.
Ekki gleyma að setja sama fræ fyrir djúpnámslíkön svo þau skili ekki stöðugt mismunandi árangri.
Þetta var stutt lýsing á meginreglunum 10, og auðvitað er erfitt að nota þær án þess að reyna og sjá hvernig þær virka, svo þessi grein er aðeins formáli að röð áhugaverðra greina þar sem ég mun sýna hvernig á að búa til iðnaðar vélanámslíkön, hvernig á að samþætta þau inn í kerfi og hvernig þessar meginreglur geta gert lífið auðveldara fyrir okkur öll.
Ég mun líka reyna að nota flottar reglur sem allir geta skilið eftir í athugasemdum ef þeir vilja.
Heimild: www.habr.com