Prezantimi

Në këtë seri me 3 pjesë, jam përpjekur të nxjerr disa mësime për të ndihmuar praktikuesit e tjerë të shkencës së të dhënave të shmangin disa nga gabimet më të zakonshme të bëra nga kompanitë që ndërmarrin projekte ML. Seria do të ndahet në mësime rreth "(1) shtrirjes, "(2) modelimit" dhe "(3) vendosjes". Ky është itreti i atij seriali.

Çfarë është gjithsesi 'Zhvendosja' për një projekt të shkencës së të dhënave?

Faza e 'Shpërndarjes' e një projekti të shkencës së të dhënave përfshin në fakt marrjen e modelit tuaj në prodhim dhe përpara përdoruesve të vërtetë.

Vendosja është e ndërlikuar dhe ka shumë aspekte të ndryshme. Në të vërtetë, shumë nga konceptet dhe mjetet rreth vendosjes janë me të vërtetë huazuar nga zhvillimi i softuerit. Dua të them që në fillim se ky artikull nuk është aspak një udhëzues i plotë për vendosjen në përgjithësi dhe është më i përqendruar në konceptet dhe parimet rreth vendosjes së ML dhe veçanërisht disa nga veçoritë e vendosjes së modeleve ML në krahasim me aplikacionet tradicionale të softuerit. Vendosja e ML është një aktivitet ndërdisiplinor dhe, si çdo gjë në jetë, prandaj bëhet më së miri si pjesë e një ekipi!

Duke u thënë kështu, më poshtë kam përmbledhur dhjetë nga mësimet më të rëndësishme që kam mësuar gjatë fazës së vendosjes së projekteve ML:

1. Softueri ML është ende softuer

Kur i hiqni të gjitha, modelet ML janë thjesht funksione të bukura si në çdo pjesë të softuerit tradicional. Ata marrin të dhëna (të dhëna) dhe japin rezultate (parashikime), vetëm me një grumbull të çmendur statistikash dhe shumëzimi matricë në mes. Në këtë kuptim, të njëjtat parime të praktikave më të mira dhe modele të projektimit për softuer zbatohen edhe për produktet ML. Këshilla ime e parë dhe ndoshta më e dobishme është të hartoni arkitekturën e vendosjes së modelit me pjesën tjetër të ekipit tuaj! Inxhinierët e të dhënave, zhvilluesit e programeve kompjuterike dhe arkitektët e sistemit ndoshta dinë shumë më tepër se ju kur bëhet fjalë për vendosjen e softuerit, prandaj përdorni njohuritë e tyre! Në fazën e vendosjes ka shumë konsiderata për t'u marrë parasysh, veçanërisht nëse jeni duke punuar brenda një sistemi klientësh (më falni ëndrrat për një aplikacion në internet, të dhënat nuk mund të largohen nga ambientet tona, kështu që ne duam që ju të vendosni në nivel lokal, etj.) dhe kështu që sa më shumë përvojë nga palët e tjera të interesuara të mund të sillni në tryezë për të ndihmuar në zgjedhjen e teknologjive të duhura të vendosjes dhe modeleve të projektimit për punën në fjalë, aq më mirë.

2. Parashikimi ‘si shërbim’ është një koncept i dobishëm

Siç u tha më lart, ka disa prirje përgjithësisht solide në zhvillimin e softuerit që janë, në shumicën e rasteve, një rregull i mirë praktik edhe për vendosjen e ML. Për shembull, të menduarit e modelit tuaj të parashikimit si një (mikro)shërbim shpesh mund të jetë vërtet i dobishëm. Për shembull, mund ta mbështillni hyrjen/daljen e modelit tuaj në një API RESTful (më pëlqen FastAPI ose django nëse është një projekt më i madh, por në thelb çdo protokoll i njohur me hyrje dhe dalje të standardizuara) dhe më pas dokerizoni aplikacionin në mënyrë që të mund të jetë i vendosur si një kontejner i pavarur. Kjo jo vetëm që do ta bëjë shumë më të lehtë vendosjen e modelit tuaj (tani mund të përdorni drejtpërdrejt çdo arkitekturë të vendosjes së kontejnerëve jashtë raftit / shërbim cloud që drejton kontejnerët), por gjithashtu do ta bëjë një mijë herë më të lehtë për zhvilluesit e programeve kompjuterike që të integrojnë shërbimin tuaj të parashikimit me shërbime të tjera backend/frontend ose produkte krejtësisht të reja të gjitha së bashku!

3. Kontrolli i versionit të modelit do ta bëjë jetën tuaj shumë më të lehtë

Një tjetër metaforë e shkëlqyer që mund të zgjerohet nga softueri në vendosjen e ML është kontrolli i versionit dhe mjediset e zhvillimit/inskenimit/prodhimit. Njohja se cili version i kodit tuaj është vendosur në cilat mjedise është kritik për vendosjen e softuerit të mirëmbajtur dhe kjo është po aq e vërtetë për vendosjen e ML. Megjithatë, në krahasim me softuerin tradicional, rezultatet e një modeli ML varen gjithashtu nga vetë arkitektura e modelit dhe të dhënat e përdorura për ta trajnuar atë (më pëlqen të mendoj për ML në përgjithësi duke përdorur atë ekuacion të thjeshtë: ML = të dhëna + model + kod). Nëse nuk jeni në gjendje të kontrolloni në mënyrë efektive versionin të tre këta elementë, atëherë rrezikoni të humbni gjurmët e asaj se ku është vendosur. Në të vërtetë, mund të kujtoj shumë projekte ku këto nuk u gjurmuan dhe ne përfunduam në një situatë ku modeli i vendosur në prodhim shkoi keq dhe ne nuk kishim asnjë mënyrë të mirë për të ditur saktësisht se cili model ishte, e lëre më se si ta riprodhonim atë në mënyrë të saktë. mund të ekzaminohet dhe korrigjohet! Fatmirësisht ka disa mjete të shkëlqyera për t'ju ndihmuar ta bëni këtë: Personalisht më pëlqen shumë Mlflow (Registry Model) për versionimin e modeleve dhe DVC për versionimin e të dhënave (si dhe git për versionimin e kodit); të cilat funksionojnë shumë bukur së bashku.

Një tjetër veçori e vendosjes së ML në krahasim me softuerin tradicional është se skedarët e modelit ML të trajnuar shpesh mund të jenë mjaft të mëdhenj (MB apo edhe GB), krahasuar me madhësinë e vogël të softuerit tradicional, i cili shpesh është aq i madh sa vetë skriptet. Dhënia e skedarëve të modelit në një repo git është një ide e keqe dhe do të fryjë me shpejtësi depon tuaj. Prandaj, ia vlen të mendoni paraprakisht kur përcaktoni sistemin tuaj të versionimit të modelit se ku do të jetojnë në të vërtetë këta skedarë modeli (udhëzim: një ruajtje e objekteve të shkallëzuara si një kovë AWS S3 ose Azure Blob është shpesh një opsion i mirë), si dhe se si do të shkarkohen dhe injektohet në shërbimin tuaj të parashikimit (Një thirrje API e cila shkarkon modelin kur aplikacioni ngarkohet fillimisht dhe më pas e mban atë të ruajtur në memorien specifike sa herë që thirret shërbimi i parashikimit mund të jetë një konfigurim i mirë këtu).

4. Mendoni për tubacionin jo vetëm parashikim

Kur mendoni për vendosjen e modeleve ML, ia vlen të zgjeroni përkufizimin tuaj të 'modelit' jo vetëm për të nënkuptuar algoritmin kryesor parashikues, por të gjithë tubacionin e parapërpunimit të nevojshëm për të transformuar të dhënat gati për t'u parashikuar (p.sh. pastrimi i të dhënave, veçoritë) si dhe çdo hap pas përpunimit të nevojshëm për t'i bërë rezultatet gati për konsum (p.sh. paraqitjet e numrave të plotë në vargjet e etiketave). Çështja është të kuptoni se në çfarë forme do të vijnë të dhënat e papërpunuara (në kohën e prodhimit) dhe të siguroheni që tubacioni juaj i modelit të mund të jetë i sigurt pranojeni atë në atë gjendje dhe bëni të gjitha transformimet e nevojshme për të bërë një parashikim dhe për t'i kaluar rezultatet në një mënyrë të fortë. Unë mendoj se "Scikit Learns' Pipeline Class" është në fakt një kornizë vërtet e mirë për të menduar për këtë për projekte më të vogla, megjithëse mjetet si "Airflow" dhe "Kuberflow" mund t'ju ndihmojnë ta zyrtarizoni me të vërtetë atë tubacion si një proces prodhimi. Kodi "ngjitës" i përpunimit para dhe pas përpunimit rreth një modeli shpesh përfundon të jetë pjesa dërrmuese e bazës së kodit dhe madje më shpesh bëhet pjesa më e vështirë për t'u ruajtur, kështu që trajtimi i tij si pjesë e modelit dhe formalizimi i tij në një tubacion modular është thelbësor. për drejtimin e një anijeje të ngushtë vendosjeje.

5. Dislokohuni herët, shpërndahuni shpesh!

Nëse do të kisha një këshillë për vendosjen do të ishte kjo: Vendoseni herët, vendoseni shpesh. Pa dyshim, gabimi më i zakonshëm që kam parë nëpër projektet e ML-së është harxhimi i tepërt i kohës përpara ndërtimit të një modeli vetëm për t'u përpjekur të vendoset si një mendim i mëvonshëm në javët e fundit ... vetëm për të hasur në stuhinë e pashmangshme të problemeve të lidhura. Por si mund të vendos nëse nuk kam tashmë një model që mund të kërkoni? Një mënyrë e mirë që kam gjetur për ta bërë këtë është të skicoj arkitekturën e vendosjes dhe më pas të ndërtoj një model "bedel" dhe ta vendos atë. Le të themi, për shembull, ju planifikoni të ndërtoni një model për të klasifikuar dokumentet në 3 kategori: Ligjore, Financa dhe Biznes. Ndërtimi i modelit të plotë do të marrë pak kohë dhe mund të jetë kompleks. Ndërkohë, megjithatë, ju mund të krijoni një klasë të thjeshtë python 'DummyModel' që merr dokumentet si hyrje ashtu si modeli juaj dhe ka një metodë transformimi që mund të thirret për të kthyer daljen në formën që modeli juaj do (e cila, në këtë rast, është një parashikim i vetëm për kategorinë e dokumenteve, p.sh. "Ligjore"). Parashikimi aktual mund të jetë thjesht i rastësishëm, ose ndonjë bazë heuristike super e thjeshtë (shih postimin tim të mëparshëm); nuk ka shumë rëndësi. Ajo që ka rëndësi është që të përpiqeni ta vendosni këtë bedel sa më shpejt që të jetë e mundur dhe të zgjidhni të gjitha problemet e vendosjes duke e bërë këtë sa më shpejt që të jetë e mundur. Unë ndonjëherë e kam quajtur këtë koncept "Deployment First" pasi ai disi ndryshon qasjen tradicionale të vendosjes vetëm pasi modeli të ndërtohet dhe e kam parë atë tepër të dobishëm kur nis projektet e reja ML.

6. Keni nevojë për komente nga përdoruesit

Zgjidhja juaj ML është po aq e mirë sa njerëzit marrin vlerë prej saj, kështu që shkencëtarët e të dhënave në fakt kanë nevojë për reagimet e përdoruesve po aq sa (nëse jo më shumë) se kushdo tjetër! Do të habiteni se sa herë ka probleme të papritura UX me rezultatet e modelit që shkaktojnë pikë dhimbjeje për njerëzit që nuk duan të përdorin një produkt. Ndoshta shembulli më klasik i kësaj është shkëmbimi i saktësisë/kujtesës: a duhet të humbisni më shumë false pozitive apo false negative? Kjo në mënyrë klasike ndonjëherë i lihet një shkencëtari të dhënash për t'iu përgjigjur, por nuk duhet të jetë! Nëse dhe në çfarë shkalle është e rëndësishme që përdoruesit të humbasin disa dokumente përkatëse, për shembull, në kurriz të mos pasur nevojë të shohin edhe ato të parëndësishme, mund të përgjigjet vetëm duke kuptuar rastin e përdorimit dhe duke marrë komente nga përdoruesit si pjesë e zhvillimit të produktit. ciklit. Megjithatë, ai ka implikime të drejtpërdrejta në modelimin dhe mënyrën se si të optimizoni funksionin tuaj të kostos. Prandaj, është thelbësore që ciklet tuaja të vendosjes së ML të përputhen me ciklin më të gjerë të zhvillimit të produktit dhe që ju të mund të merrni reagimet nga ato cikle për të përmirësuar modelin e ardhshëm që vendosni.

7. Vëzhgimi i modelit tuaj në vendosje mund t'ju ndihmojë të gjeni mënyra të reja për të hequr stresin nga performanca e modelit

Një tipar vërtet i këndshëm i integrimit të vendosjes tuaj me ciklet e zhvillimit të produktit është se pasi të filloni të lidheni me UI/UX të produktit, atëherë filloni të kuptoni se modeli juaj është shpesh vetëm njëmënyrë për t'u zgjidhur problemi i vërtetë. Për shembull, kam punuar në një projekt duke nxjerrë informacion nga dokumentet, ku rasti i përdorimit kërkonte që saktësia e modelit të ishte në thelb 100% (siç ishte për të dhënat ligjore ku një gabim i vetëm mund të kishte pasoja të rënda). Edhe pse ne ishim në gjendje të arrinim rezultate të forta modelimi, performanca e përsosur është pothuajse e pamundur në çdo problem ML të botës reale. Megjithatë, duke vëzhguar modelin në vendosje dhe duke punuar me projektuesit frontend dhe UX për të kaluar probabilitetet e parashikimit të modelit në UI, në mënyrë që t'u theksojmë përdoruesve rastet kur modeli ishte më pak i sigurt dhe t'i udhëzojmë ata për të kontrolluar ato raste, ne ishim në gjendje të rritnifluksin e punës së përdoruesve, duke e lënë modelin ML të bëjë punën e rëndë të reduktimit të punës së zakonshme manuale që përdoruesit duhet të bënin më parë (duke kontrolluar manualisht çdo dokument), ndërkohë që gjithsesi sigurohet që rezultatet përfundimtare të kenë mbikëqyrje njerëzore dhe (praktikisht) pa gabime. Vëzhgimi i modelit tuaj në vendosje mund të ndihmojë në lidhjen e mëtejshme të shkencëtarëve të të dhënave me problemin real dhe zgjidhjet krijuese në sipërfaqe.

8. Përpiquni dhe mendoni për monitorimin dhe rikualifikimin përpara!

Në natyrë, performanca e modelit shpesh prishet me shpejtësi. Seti juaj i trajnimit mund të mos përfaqësojë shpërndarjen e vërtetë të të dhënave në natyrë, ose vetë shpërndarja mund të jetë një objektiv lëvizës (ndryshojnë preferencat e përdoruesit, përditësohen strukturat e dokumenteve etj.). Për shkak të kësaj, modeli juaj mund të performojë më keq në prodhim që keni pritur, veçanërisht me kalimin e kohës. Mënyra e vetme për ta luftuar këtë është të monitoroni pa pushim modelin tuaj në natyrë, të mblidhni mostra të të dhënave aktuale të përdoruesit në prodhim dhe, në fund të fundit, të ritrajnoni modelin tuaj. Megjithatë, që monitorimi të jetë efektiv, duhet të mendoni përpara për të gjitha pjesët e tjera që do të përfshijnë: A keni një mënyrë për të mbledhur komente dhe mostra të reja ndërsa njerëzit përdorin produktin? Si do t'i etiketoni këto mostra? Cila do të jetë strategjia juaj e rikualifikimit (sa herë që merrni një mostër të re? Pasi prishja e modelit në një grup vlerësimi prodhimi të ketë rënë nën X?) Si do të mbani shënim se cili version i modelit është duke u vendosur? A do të mbështesë infrastruktura juaj testimin A/B për të vlerësuar versionet e reja të modelit pasi të jeni ritrajnuar? Mjetet si Prometheus dhe Grafana mund të jenë një mënyrë e shkëlqyer për të monitoruar performancën e modelit në prodhim dhe për të ndihmuar në mbajtjen e gjurmëve se ku duhet të vendosen versione të ndryshme të modeleve dhe tubacione testimi A/B.

9. Përdorni tubacionet CI/CD për të bërë klasën e prodhimit të modeleve tuaja ML

Gjithashtu ia vlen vërtet të integroni vendosjen e modelit me tubacionin tuaj të testimit CI/CD dhe të shkruani teste dhe regjistra kuptimplotë për të kontrolluar se modeli po sillet siç pritej kur bëhen ndryshime ose publikohen versionet e reja të modelit. Gjithashtu do t'ju ndihmojë të menaxhoni se cilat versione modeli vendosen në cilat mjedise në një mënyrë të organizuar dhe të shkallëzuar. Unë kam hyrë në Github Veprimet për ndërtimin e këtyre tubacioneve kohët e fundit (megjithëse ka një ton mjetesh të ndryshme CI/CD atje). Përsëri këto janë praktika vërtet të mira të huazuara nga zhvillimi tradicional i softuerit, megjithëse unë do të argumentoja se ato mund të jenë edhe më të ndërlikuara në produktet ML ku sjellja e saktë e një modeli mund të jetë stokastike dhe e vështirë për t'u parashikuar dhe për këtë arsye përfitimi i një tubacioni të strukturuar CI/CD kur vendosja është edhe më e madhe.

10. Testimi i bazuar në pronë është shumë i dobishëm kur kemi të bëjmë me ML

Në temën e testimit, kam gjetur se shkrimi i 'testeve të bazuara në pronë' (së bashku me testet tradicionale të njësive dhe integrimit) mund të ndihmojë vërtet. Testimi i bazuar në pronë është në thelb krijimi i mostrave të të dhënave që mund të kalohen përmes modelit tuaj për të kontrolluar nëse merrni rezultatet e pritura. Megjithatë, në vend që të paracaktoni ato të dhëna, ju mund të gjeneroni vëllime të mëdha të të dhënave të rastësishme të kufizuara nga vetitë që specifikoni. Nga ana tjetër, ju nuk mund të pohoni rezultatin e saktë që prisni nga modeli nga vetitë që prisni të ketë ai model. Për shembull, për një model regresioni të serive kohore për të parashikuar çmimin e një aksioni, mund të pohoni se vetitë hyrëse do të jenë një grup notash që përfaqësojnë 100 ditët e fundit të asaj vlere të aksioneve dhe vetitë e prodhimit duhet të jenë një notim i vetëm i cili nuk mund të jetë më e ulët se $0 dhe nuk duhet të kalojë në mënyrë të arsyeshme $1 miliard. Më pas mund të gjeneroj një numër të madh hyrjesh sintetike të cilat mund të përfshijnë çdo vlerë brenda kufizimeve të vetive të mia hyrëse dhe të monitoroj nëse vetitë e daljes ruhen ende. Kjo mund të jetë një mënyrë e shkëlqyer për të kapur rastet e panjohura të skajeve (çfarë ndodh nëse kaloni në të dhëna boshe, ose nëse të gjitha vlerat janë zero). Më e rëndësishmja, mund të jetë një mënyrë e shkëlqyeshme për të gjetur rezultate 'perverse' të modelit që mund t'ju ndihmojë të kuptoni dobësitë në sistem dhe të përmirësoni shërbimin përpara se të shkaktojë probleme në vendosje. Ndoshta disa inpute bëjnë që modeli juaj të parashikojë një çmim negativ për aksionin, i cili nuk ka kuptim për rastin e përdorimit dhe duhet të korrigjohet përpara se të shkaktojë probleme. Bibliotekat si hipoteza bëjnë një punë të shkëlqyeshme për t'ju ndihmuar të shkruani teste të bazuara në pronë për modelet ML dhe mund t'ju ndihmojnë vërtet të ndërtoni një shërbim më të fuqishëm të vendosjes së ML.

Jam përpjekur të përqendrohem këtu më shumë në konceptet rreth vendosjes së ML-së sesa në teknikat, mjetet dhe teknologjitë në mënyrë specifike. Në realitet ka një gamë të gjerë mjetesh të shkëlqyera për të mbështetur vendosjen e ML dhe kjo është para se të futeni në gamën po aq të gjerë të shërbimeve të vendosjes që ofrojnë ofruesit e reve kompjuterike si AWS, Azure dhe GCP. Mund të jetë marramendëse, por këshilla ime do të ishte të filloni të thjeshta dhe të eksploroni teknologji të ndryshme ndërsa hasni në pika të reja dhimbjeje të vendosjes derisa të krijoni një pirg që i përshtatet nevojave tuaja.

Përfundim

Ju nuk përfitoni asnjë vlerë nga një model i ulur në laptopin e dikujt. Pra, marrja seriozisht e vendosjes dhe ballafaqimi me të është një nga aspektet më të rëndësishme për të siguruar suksesin e përgjithshëm të projekteve të ML.

Shpresoj se ky artikull ishte i dobishëm! Ky është fundi i kësaj serie me 3 pjesë, por për më shumë informacion mbi projektet e ML ose çdo gjë tjetër mos ngurroni të më kontaktoni drejtpërdrejt. Mezi pres të dëgjoj nga ju.