Ipari gépi tanulás: 10 tervezési alapelv
Napjainkban nap mint nap születnek új szolgáltatások, alkalmazások és más fontos programok, amelyek hihetetlen dolgok létrehozását teszik lehetővé: a SpaceX rakéta vezérlésére szolgáló szoftvertől a szomszédos szobában lévő vízforralóval okostelefonon keresztül történő interakcióig.
És néha minden kezdő programozó, legyen az szenvedélyes induló, vagy egy közönséges Full Stack vagy Data Scientist, előbb-utóbb rájön, hogy vannak bizonyos szabályok a programozáshoz és a szoftverek létrehozásához, amelyek nagyban leegyszerűsítik az életet.
Ebben a cikkben a 10-faktoros App módszertan alapján röviden leírom a 12 alapelvet, hogyan lehet az ipari gépi tanulást úgy programozni, hogy könnyen integrálható legyen egy alkalmazásba/szolgáltatásba. . Kezdeményezésem ennek a technikának a tudatosítása, amely sok fejlesztőnek és adattudományos embernek segíthet.
Ez a cikk az ipari gépi tanulásról szóló cikksorozat prológusa. Ezekben tovább fogok beszélni arról, hogyan lehet ténylegesen elkészíteni egy modellt és elindítani a termelésben, létrehozni hozzá egy API-t, valamint példákat mutatok be különböző területekről és cégekről, amelyeknek rendszerükbe beépített ML van.
1. alapelv: Egy kódbázis
Néhány programozó az első szakaszban, lustaságból, hogy rájöjjön (vagy valamilyen saját okból), megfeledkezik a Gitről. Vagy teljesen elfelejtik a szót, azaz fájlokat dobálnak egymásnak a meghajtóban/csak szöveget dobálnak/küldenek galambok, vagy nem gondolják végig a munkafolyamatukat, és lekötik a saját ágára, majd a fő.
Ez az elv kimondja: egy kódbázissal és sok telepítéssel rendelkezik.
A Git mind a termelésben, mind a kutatás-fejlesztésben (K+F) használható, ahol nem használják olyan gyakran.
Például a K+F fázisban különböző adatfeldolgozási módszerekkel és modellekkel hagyhatja el a commitokat, hogy aztán kiválaszthassa a legjobbat, és könnyen tovább dolgozhasson vele.
Másodszor, a termelésben ez pótolhatatlan dolog – folyamatosan figyelnie kell, hogyan változik a kódja, és tudnia kell, melyik modell hozta a legjobb eredményeket, melyik kód működött végül, és mi történt, ami miatt leállt, vagy hibás eredményeket produkált. . Erre valók a commitok!
Csomagot is készíthet a projektjéből, elhelyezve például a Gemfury-n, majd egyszerűen csak importálhat belőle függvényeket más projektekhez, hogy ne írja át őket 1000-szer, de erről majd később.
2. alapelv: Világosan deklarálja és izolálja a függőségeket
Minden projektnek különböző könyvtárai vannak, amelyeket kívülről importál, hogy valahol alkalmazni tudja őket. Legyen szó Python-könyvtárakról vagy más nyelvek különböző célú könyvtárairól vagy rendszereszközökről - az Ön feladata:
- Világosan deklarálja a függőségeket, azaz egy olyan fájlt, amely tartalmazza a projektben használt összes könyvtárat, eszközt és azok verzióit, amelyeket telepíteni kell (például Pythonban ez megtehető a Pipfile vagy a requirements.txt használatával. A link, amely lehetővé teszi a jó megértést: )
- A fejlesztés során különítse el a függőségeket kifejezetten a programhoz. Nem szeretné állandóan módosítani a verziókat és újratelepíteni például a Tensorflow-t?
Így a jövőben a csapatához csatlakozó fejlesztők gyorsan megismerkedhetnek a projektben használt könyvtárakkal és azok verzióival, és lehetőségük lesz arra is, hogy maguknak a verzióknak és könyvtáraknak a kezelését, amelyek egy adott programhoz vannak telepítve. projekt, amely segít elkerülni a könyvtárak vagy verzióik inkompatibilitását.
Az alkalmazás nem támaszkodhat olyan rendszereszközökre, amelyek adott operációs rendszerre telepítve vannak. Ezeket az eszközöket a függőségi jegyzékben is deklarálni kell. Erre azért van szükség, hogy elkerüljük azokat a helyzeteket, amikor az eszközök verziója (valamint elérhetősége) nem egyezik meg egy adott operációs rendszer rendszereszközeivel.
Így, még ha a curl szinte minden számítógépen használható is, akkor is függőségekben kell deklarálnia, mert egy másik platformra való áttéréskor előfordulhat, hogy nem lesz ott, vagy nem az lesz a verzió, amelyre eredetileg szüksége volt.
A követelmények.txt például így nézhet ki:
# 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. alapelv: Konfigurációk
Sokan hallottak már történeteket arról, hogy különböző fejlesztők véletlenül kódot töltöttek fel a GitHubra nyilvános adattárakba az AWS jelszavaival és egyéb kulcsaival, és másnap 6000 vagy akár 50000 XNUMX dolláros tartozásra ébredtek.
Természetesen ezek az esetek szélsőségesek, de nagyon jelentősek. Ha a kódban tárolja a hitelesítő adatait vagy a konfigurációhoz szükséges egyéb adatokat, akkor hibát követ el, és úgy gondolom, hogy nem kell magyarázni, miért.
Ennek alternatívája a konfigurációk tárolása környezeti változókban. A környezeti változókról bővebben olvashat .
Példák azokra az adatokra, amelyeket általában környezeti változókban tárolnak:
- Domain nevek
- API URL-ek/URI-k
- Nyilvános és privát kulcsok
- Elérhetőségek (mail, telefon stb.)
Így nem kell folyamatosan módosítania a kódot, ha a konfigurációs változók megváltoznak. Ezzel időt, erőfeszítést és pénzt takaríthat meg.
Például, ha a Kaggle API-t használja tesztek elvégzésére (például töltse le a szoftvert, és futtassa rajta a modellt, hogy futás közben tesztelje, hogy a modell jól működik), akkor a Kaggle privát kulcsait, például a KAGGLE_USERNAME és KAGGLE_KEY, környezeti változókban tárolva.
4. alapelv: Harmadik fél szolgáltatásai
Itt az az ötlet, hogy a programot úgy hozzuk létre, hogy a kód tekintetében ne legyen különbség a helyi és a harmadik féltől származó erőforrások között. Például csatlakoztathat helyi MySQL-t és harmadik féltől származó MySQL-t is. Ugyanez vonatkozik a különféle API-kra is, mint például a Google Maps vagy a Twitter API.
Egy harmadik féltől származó szolgáltatás letiltásához vagy egy másik csatlakoztatásához csak meg kell változtatnia a konfigurációs kulcsokat a környezeti változókban, amiről a fenti bekezdésben beszéltem.
Így például ahelyett, hogy minden alkalommal megadná a kódon belüli adatkészleteket tartalmazó fájlok elérési útját, jobb, ha a pathlib könyvtárat használja, és deklarálja az adatkészletek elérési útját a config.py fájlban, így függetlenül attól, hogy milyen szolgáltatást használ (pl. például CircleCI), a program az új szolgáltatásban az új fájlrendszer szerkezetét figyelembe véve meg tudta találni az adatkészletek elérési útját.
5. alapelv. Építés, kiadás, futásidő
A Data Science munkatársai közül sokan hasznosnak találják szoftverírási készségeik fejlesztését. Ha azt szeretnénk, hogy programunk a lehető legritkábban omoljon össze, és a lehető leghosszabb ideig hibamentesen működjön, akkor az új verzió kiadásának folyamatát 3 szakaszra kell osztanunk:
- Színpad szerelvények. A csupasz kódot egyedi erőforrásokkal alakítja át egy úgynevezett csomaggá, amely tartalmazza az összes szükséges kódot és adatot. Ezt a csomagot szerelvénynek nevezik.
- Színpad kioldó — itt kötjük össze a konfigunkat az assembly-vel, ami nélkül nem tudnánk kiadni a programunkat. Most ez egy teljesen kész kiadás.
- Ezután jön a színpad teljesítés. Itt adjuk ki az alkalmazást a szükséges folyamatok futtatásával a kiadásunkból.
A modell vagy a teljes folyamat új verzióinak kiadására szolgáló ilyen rendszer lehetővé teszi a szerepek elkülönítését a rendszergazdák és a fejlesztők között, lehetővé teszi a verziók nyomon követését és megakadályozza a program nem kívánt leállását.
A kiadási feladathoz számos különféle szolgáltatást hoztak létre, amelyekben folyamatokat írhat, hogy saját magát futtathassa egy .yml fájlban (például a CircleCI-ben ez a config.yml magát a folyamatot támogatja). A Wheely kiválóan alkalmas projektcsomagok létrehozására.
Csomagokat hozhat létre a gépi tanulási modell különböző verzióival, majd csomagolhatja őket, és hivatkozhat a szükséges csomagokra és azok verzióira az onnan írt függvények használatához. Ez segít létrehozni egy API-t a modellhez, és a csomagot például a Gemfury tárolhatja.
6. alapelv. Futtassa a modellt egy vagy több folyamatként
Ezenkívül a folyamatoknak nem szabad megosztott adatokkal rendelkezniük. Ez azt jelenti, hogy a folyamatoknak külön kell létezniük, és mindenféle adatnak külön kell léteznie, például harmadik féltől származó szolgáltatásoknál, mint például a MySQL vagy mások, attól függően, hogy mire van szüksége.
Vagyis semmiképpen nem érdemes adatokat tárolni a folyamatfájlrendszeren belül, különben ez az adatok törléséhez vezethet a következő kiadás/konfigurációmódosítás során, vagy a rendszer átvitele során, amelyen a program fut.
Van azonban egy kivétel: a gépi tanulási projektek esetében tárolhatja a könyvtárak gyorsítótárát, hogy ne telepítse újra őket minden alkalommal, amikor új verziót indít, ha nem történt további könyvtár vagy módosítás a verziókon. Így csökkentheti a modell ipari bevezetéséhez szükséges időt.
A modell több folyamatként történő futtatásához létrehozhat egy .yml fájlt, amelyben megadhatja a szükséges folyamatokat és azok sorrendjét.
7. alapelv: Újrahasznosíthatóság
A modellalkalmazásban futó folyamatok könnyen indíthatók és leállíthatók. Így ez lehetővé teszi a kódmódosítások, a konfigurációs módosítások gyors üzembe helyezését, a gyors és rugalmas méretezést, valamint a működő verzió esetleges meghibásodásának megelőzését.
Vagyis a modellel végzett folyamatnak:
- Minimalizálja az indítási időt. Ideális esetben az indítási idő (az indítási parancs kiadásától a folyamat működésbe lépéséig) nem lehet több néhány másodpercnél. A fent leírt könyvtár gyorsítótárazás az indítási idő csökkentésének egyik módja.
- Vége helyesen. Ez azt jelenti, hogy a szolgáltatási porton történő figyelés ténylegesen felfüggesztésre kerül, és az erre a portra küldött új kérések nem kerülnek feldolgozásra. Itt vagy jó kommunikációt kell létrehoznia a DevOps mérnökeivel, vagy saját magának kell megértenie, hogyan működik (lehetőleg természetesen az utóbbi, de a kommunikációt mindig fenn kell tartani, bármilyen projektben!)
8. alapelv: Folyamatos telepítés/integráció
Sok vállalat elválasztja az alkalmazásfejlesztési és telepítési csoportokat (az alkalmazást elérhetővé teszi a végfelhasználók számára). Ez nagymértékben lelassíthatja a szoftverfejlesztést és a fejlesztésben való előrehaladást. Ez rontja a DevOps kultúrát is, ahol a fejlesztés és az integráció durván szólva ötvöződik.
Ezért ez az elv kimondja, hogy a fejlesztési környezetnek a lehető legközelebb kell állnia a termelési környezethez.
Ez lehetővé teszi:
- Csökkentse a kiadási időt tízszeresére
- Csökkentse a kód inkompatibilitása miatti hibák számát.
- Ez csökkenti a személyzet munkaterhét is, mivel a fejlesztők és az alkalmazást telepítők mostantól egy csapatot alkotnak.
A CircleCI, a Travis CI, a GitLab CI és mások az eszközök, amelyek lehetővé teszik az ezzel való munkát.
Gyorsan kiegészítheti a modellt, frissítheti és azonnal elindíthatja, miközben meghibásodások esetén nagyon gyorsan vissza lehet térni a működő verzióhoz úgy, hogy a végfelhasználó észre sem veszi. Ez különösen egyszerűen és gyorsan megtehető, ha jó tesztek vannak.
Minimalizáld a különbségeket!!!
9. alapelv. A naplóid
A naplók (vagy „naplók”) általában szöveges formátumban rögzített események, amelyek az alkalmazáson belül (eseményfolyam) történnek. Egy egyszerű példa: "2020-02-02 - rendszerszint - folyamat neve." Úgy tervezték őket, hogy a fejlesztő szó szerint láthassa, mi történik a program futása közben. Látja a folyamatok előrehaladását, és megérti, hogy az úgy van-e, ahogyan maga a fejlesztő tervezte.
Ez az elv kimondja, hogy a naplókat nem szabad a fájlrendszerben tárolni – csak „ki kell írni” őket a képernyőre, például a rendszer szabványos kimenetén. És így a fejlesztés során nyomon lehet majd követni a terminál áramlását.
Ez azt jelenti, hogy egyáltalán nem kell menteni a naplókat? Természetesen nem. Az alkalmazásnak nem szabad ezt megtennie – bízza harmadik fél szolgáltatásaira. Az alkalmazás csak egy adott fájlba vagy terminálba tudja továbbítani a naplókat valós idejű megtekintés céljából, vagy továbbítani egy általános célú adattároló rendszerbe (például Hadoop). Maga az alkalmazás nem tárolhat naplókat, és nem léphet kapcsolatba velük.
Alapelv 10. Teszteld!
Az ipari gépi tanuláshoz ez a fázis rendkívül fontos, hiszen meg kell értened, hogy a modell megfelelően működik és azt produkálja, amit akartál.
Tesztek hozhatók létre pytest segítségével, és tesztelhetők egy kis adatkészlettel, ha regressziós/osztályozási feladatai vannak.
Ne felejtse el beállítani ugyanazt a magot a mély tanulási modellekhez, hogy ne hozzanak állandóan eltérő eredményeket.
Ez a 10 alapelv rövid leírása volt, és természetesen nehéz használni őket anélkül, hogy kipróbálnánk és nem látnánk, hogyan működnek, ezért ez a cikk csak egy prológja egy érdekes cikksorozatnak, amelyben bemutatom, hogyan kell létrehozni ipari gépi tanulási modellek , hogyan integrálhatók rendszerekbe, és hogyan könnyíthetik meg ezek az elvek mindannyiunk életét.
Megpróbálok olyan klassz elveket is alkalmazni, amelyeket bárki megírhat a megjegyzésekben, ha akar.
Forrás: will.com