Tööstuslik masinõpe: 10 disainipõhimõtet

Tööstuslik masinõpe: 10 disainipõhimõtet

Tänapäeval luuakse iga päev uusi teenuseid, rakendusi ja muid olulisi programme, mis võimaldavad luua uskumatuid asju: alates SpaceX-i raketi juhtimise tarkvarast kuni kõrvaltoas asuva veekeetjaga nutitelefoni kaudu suhtlemiseni.

Ja mõnikord jõuab iga algaja programmeerija, olgu ta kirglik startuper või tavaline Full Stack või Data Scientist, varem või hiljem arusaamisele, et programmeerimisel ja tarkvara loomisel on teatud reeglid, mis elu oluliselt lihtsustavad.

Selles artiklis kirjeldan lühidalt 10 põhimõtet, kuidas programmeerida tööstuslikku masinõpet nii, et seda oleks lihtne rakendusse/teenusesse integreerida, tuginedes 12-faktorilise App metoodikale. soovitas Heroku meeskond. Minu algatus on suurendada teadlikkust sellest tehnikast, mis võib aidata paljusid arendajaid ja andmeteaduse inimesi.

See artikkel on proloog tööstuslikku masinõpet käsitlevatele artiklite seeriale. Nendes räägin edasi sellest, kuidas reaalselt mudelit teha ja tootmisse käivitada, luua sellele API, aga ka näiteid erinevatest valdkondadest ja ettevõtetest, kelle süsteemidesse on ML sisse ehitatud.

1. põhimõte: üks koodibaas

Mõned programmeerijad unustavad esimestel etappidel laiskusest selle välja mõelda (või mingil omal põhjusel) Giti. Nad kas unustavad sõna täielikult, st loobivad üksteisele faile draivi / lihtsalt viskavad teksti / saadavad tuvid või ei mõtle oma töövoogu läbi ja seovad igaüks oma harusse ja seejärel meister.

See põhimõte ütleb: neil on üks koodibaas ja mitu juurutust.

Giti saab kasutada nii tootmises kui ka teadus- ja arendustegevuses (R&D), milles seda nii sageli ei kasutata.

Näiteks saab uurimis- ja arendustegevuse faasis jätta kohustused erinevate andmetöötlusmeetodite ja -mudelitega, et seejärel välja valida parim ja sellega hõlpsalt edasi töötada.

Teiseks on see tootmises asendamatu – peate pidevalt vaatama, kuidas teie kood muutub ja teadma, milline mudel andis parimaid tulemusi, milline kood lõpuks töötas ja mis juhtus, mille tõttu see lakkas töötamast või hakkas andma valesid tulemusi. . Selleks on kohustused!

Samuti saate luua oma projektist paketi, asetades selle näiteks Gemfurysse ja seejärel lihtsalt importida sealt funktsioone teiste projektide jaoks, et mitte neid 1000 korda ümber kirjutada, vaid sellest hiljem.

2. põhimõte: selgelt deklareerige ja eraldage sõltuvused

Igal projektil on erinevad teegid, mida impordite väljastpoolt, et neid kuskil rakendada. Olgu selleks Pythoni teegid või erinevatel eesmärkidel kasutatavad muude keelte teegid või süsteemitööriistad - teie ülesanne on:

• Deklareerige selgelt sõltuvused, st fail, mis sisaldab kõiki teie projektis kasutatavaid teeke, tööriistu ja nende versioone, mis tuleb installida (näiteks Pythonis saab seda teha kasutades Pipfile või nõuded.txt. A link, mis võimaldab hästi mõista: realpython.com/pipenv-guide)
• Eraldage arenduse ajal spetsiaalselt oma programmi jaoks mõeldud sõltuvused. Kas te ei soovi pidevalt versioone muuta ja näiteks Tensorflow'i uuesti installida?

Nii saavad tulevikus teie meeskonnaga liituvad arendajad kiiresti tutvuda teie projektis kasutatavate teekide ja nende versioonidega ning teil on ka võimalus hallata konkreetsele konkreetsele installitud versioone ja teeke. projekt, mis aitab teil vältida teekide või nende versioonide kokkusobimatust.

Teie rakendus ei tohiks samuti tugineda süsteemitööriistadele, mis võivad olla installitud konkreetsesse operatsioonisüsteemi. Need tööriistad tuleb deklareerida ka sõltuvuste manifestis. See on vajalik selleks, et vältida olukordi, kus tööriistade versioon (ja ka nende saadavus) ei ühti konkreetse OS-i süsteemitööriistadega.

Seega, isegi kui curli saab kasutada peaaegu kõigis arvutites, peaksite selle siiski deklareerima sõltuvustes, kuna teisele platvormile migreerumisel ei pruugi see seal olla või pole versioon see, mida algselt vajasite.

Näiteks võib fail nõuded.txt välja näha selline:

# 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. põhimõte: konfiguratsioonid

Paljud on kuulnud lugusid erinevatest arendajatest, kes laadisid kogemata GitHubi koodi koos paroolide ja muude AWS-i võtmetega avalikesse hoidlatesse, ärkates järgmisel päeval 6000- või isegi 50000 XNUMX-dollarise võlaga.

Muidugi on need juhtumid äärmuslikud, kuid väga olulised. Kui salvestate oma mandaadid või muud konfigureerimiseks vajalikud andmed koodi sisse, teete vea ja ma arvan, et põhjust pole vaja selgitada.

Selle alternatiiviks on konfiguratsioonide salvestamine keskkonnamuutujatesse. Lisateavet keskkonnamuutujate kohta saate lugeda siin.

Näited andmetest, mida tavaliselt keskkonnamuutujatesse salvestatakse:

• Domeeninimed
• API URL-id/URI-d
• Avalikud ja privaatsed võtmed
• Kontaktid (post, telefonid jne)

Nii ei pea te konfiguratsioonimuutujate muutumisel koodi pidevalt muutma. See aitab säästa aega, vaeva ja raha.

Näiteks kui kasutate testide läbiviimiseks Kaggle API-t (näiteks laadite alla tarkvara ja käivitate selle kaudu mudeli, et testida, kas mudel töötab töötamise ajal hästi), tuleks Kaggle'i privaatvõtmed, nagu KAGGLE_USERNAME ja KAGGLE_KEY, salvestatud keskkonnamuutujatesse.

4. põhimõte: kolmanda osapoole teenused

Siin on idee luua programm nii, et koodi osas poleks kohalikel ja kolmandate osapoolte ressurssidel vahet. Näiteks saate ühendada nii kohaliku MySQL-i kui ka kolmanda osapoole oma. Sama kehtib ka erinevate API-de kohta, nagu Google Maps või Twitter API.

Kolmanda osapoole teenuse keelamiseks või teise ühendamiseks peate lihtsalt muutma keskkonnamuutujate konfiguratsiooni võtmeid, millest ma rääkisin ülaltoodud lõigus.

Näiteks selle asemel, et määrata iga kord koodi sees olevate andmekogumitega failide tee, on parem kasutada teeki pathlib ja deklareerida andmekogumite tee failis config.py, et olenemata sellest, millist teenust te kasutate ( Näiteks CircleCI), suutis programm teada saada andmekogumite tee, võttes arvesse uue teenuse uue failisüsteemi struktuuri.

Põhimõte 5. Ehitamine, vabastamine, käitusaeg

Paljud andmeteaduse töötajad leiavad, et tarkvara kirjutamise oskuste parandamine on kasulik. Kui tahame, et meie programm jookseks kokku nii harva kui võimalik ja töötaks võimalikult kaua tõrgeteta, peame jagama uue versiooni väljaandmise protsessi kolmeks etapiks:

1. Etapp assambleed. Muudate oma ribakoodi üksikute ressurssidega nn paketiks, mis sisaldab kogu vajalikku koodi ja andmeid. Seda paketti nimetatakse komplektiks.
2. Etapp vabastama — siin ühendame oma konfiguratsiooni koostuga, ilma milleta ei saaks me oma programmi välja anda. Nüüd on see väljalase täiesti valmis.
3. Edasi tuleb lava täitmine. Siin vabastame rakenduse, käivitades vajalikud protsessid meie versioonist.

Selline mudeli või kogu konveieri uute versioonide avaldamise süsteem võimaldab eraldada administraatorite ja arendajate vahel rollid, võimaldab jälgida versioone ja takistab programmi soovimatuid seiskumisi.

Väljalaskeülesande jaoks on loodud palju erinevaid teenuseid, milles saate kirjutada protsesse, et ennast .yml-failis käivitada (näiteks CircleCI-s on see protsessi enda toetamiseks config.yml). Wheely on suurepärane projektide pakettide loomisel.

Saate luua pakette oma masinõppemudeli erinevate versioonidega ja seejärel pakkida need ning vaadata vajalikke pakette ja nende versioone, et kasutada sealt kirjutatud funktsioone. See aitab teil luua oma mudelile API ja teie paketti saab majutada näiteks Gemfury's.

Põhimõte 6. Käitage oma mudelit ühe või mitme protsessina

Lisaks ei tohiks protsessidel olla jagatud andmeid. See tähendab, et protsessid peavad eksisteerima eraldi ja igasugused andmed peavad eksisteerima eraldi, näiteks kolmandate osapoolte teenustes, nagu MySQL või muud, olenevalt sellest, mida vajate.

See tähendab, et kindlasti ei tasu salvestada andmeid protsessifailisüsteemi sees, vastasel juhul võib see viia nende andmete kustutamiseni järgmise väljalaske / konfiguratsioonide muutmise või süsteemi, milles programm töötab, ülekandmise ajal.

Kuid on erand: masinõppeprojektide puhul saate salvestada teekide vahemällu, et mitte neid uuesti installida iga kord, kui käivitate uue versiooni, kui täiendavaid teeke või nende versioonidesse pole tehtud muudatusi. Nii vähendate oma mudeli turule toomiseks kuluvat aega.

Mudeli mitme protsessina käitamiseks saate luua .yml faili, milles määrate vajalikud protsessid ja nende järjestuse.

7. põhimõte: taaskasutatavus

Teie mudelirakenduses töötavaid protsesse peaks olema lihtne käivitada ja peatada. Seega võimaldab see kiiresti juurutada koodimuudatusi, konfiguratsioonimuudatusi, kiiresti ja paindlikult skaleerida ning vältida tööversiooni võimalikke rikkeid.

See tähendab, et teie protsess mudeliga peaks:

• Minimeerige käivitusaega. Ideaalis ei tohiks käivitusaeg (alates käivituskäskluse andmisest kuni protsessi käivitumise hetkeni) olla pikem kui mõni sekund. Eespool kirjeldatud raamatukogu vahemällu salvestamine on üks käivitusaja lühendamise viise.
• Lõpeta õigesti. See tähendab, et teeninduspordi kuulamine on tegelikult peatatud ja sellele pordile esitatud uusi päringuid ei töödelda. Siin tuleb luua hea suhtlus DevOpsi inseneridega või ise aru saada, kuidas see toimib (soovitavalt muidugi viimane, kuid sidet tuleks igas projektis alati säilitada!)

8. põhimõte: pidev juurutamine/integreerimine

Paljud ettevõtted kasutavad rakenduse arendus- ja juurutusmeeskondade vahel vahet (rakenduse lõppkasutajatele kättesaadavaks tegemine). See võib tarkvaraarendust ja selle täiustamise edusamme oluliselt aeglustada. See rikub ka DevOpsi kultuuri, kus areng ja integratsioon on jämedalt öeldes ühendatud.

Seetõttu ütleb see põhimõte, et teie arenduskeskkond peaks olema teie tootmiskeskkonnale võimalikult lähedane.

See võimaldab:

1. Vähendage vabastamisaega kümneid kordi
2. Vähendage koodide ühildumatusest tingitud vigade arvu.
3. See vähendab ka töötajate töökoormust, kuna arendajad ja rakendust juurutavad inimesed on nüüd üks meeskond.

Tööriistad, mis võimaldavad teil sellega töötada, on CircleCI, Travis CI, GitLab CI ja teised.

Saate kiiresti mudelisse täiendusi teha, seda värskendada ja kohe käivitada, samas on rikete korral lihtne väga kiiresti tööversiooni juurde naasta, nii et lõppkasutaja seda isegi ei märkaks. Seda saab teha eriti lihtsalt ja kiiresti, kui sul on head testid.

Minimeeri erinevused!!!

Põhimõte 9. Teie logid

Logid (või "logid") on sündmused, mis salvestatakse tavaliselt tekstivormingus ja mis toimuvad rakenduses (sündmusvoos). Lihtne näide: "2020-02-02 - süsteemi tase - protsessi nimi." Need on loodud nii, et arendaja saaks sõna otseses mõttes näha, mis programmi töötamise ajal toimub. Ta näeb protsesside kulgu ja saab aru, kas see on nii, nagu arendaja ise kavatses.

See põhimõte ütleb, et te ei tohiks oma logisid oma failisüsteemis salvestada - peaksite need lihtsalt ekraanile "väljastama", näiteks tegema seda süsteemi standardväljundis. Ja nii saab arenduse ajal jälgida voolu terminalis.

Kas see tähendab, et logisid pole üldse vaja salvestada? Muidugi mitte. Teie rakendus lihtsalt ei peaks seda tegema – jätke see kolmandate osapoolte teenustele. Teie rakendus saab logid reaalajas vaatamiseks edastada ainult konkreetsesse faili või terminali või edastada need üldotstarbelisse andmesalvestussüsteemi (nt Hadoop). Teie rakendus ise ei tohiks logisid salvestada ega nendega suhelda.

Põhimõte 10. Testi!

Tööstusliku masinõppe jaoks on see etapp äärmiselt oluline, kuna peate mõistma, et mudel töötab õigesti ja toodab seda, mida soovite.

Teste saab luua pytesti abil ja testida väikese andmestikuga, kui teil on regressiooni-/klassifikatsiooniülesanne.

Ärge unustage määrata süvaõppe mudelitele sama seemet, et need ei annaks pidevalt erinevaid tulemusi.

See oli 10 põhimõtte lühikirjeldus ja loomulikult on neid raske kasutada, ilma et prooviksite ja nägema, kuidas need töötavad, nii et see artikkel on vaid proloog huvitavatele artiklitele, milles ma paljastan, kuidas luua. tööstuslikud masinõppe mudelid , kuidas neid süsteemidesse integreerida ja kuidas need põhimõtted võivad meie kõigi elu lihtsamaks teha.

Samuti püüan kasutada lahedaid põhimõtteid, mida igaüks võib soovi korral kommentaaridesse jätta.

Allikas: www.habr.com