Sparkify: parashikimi i përplasjes me PySpark

Përmbledhje e projektit

Ky projekt është pjesë e Nanodegree të shkencëtarit të të dhënave të Udacity. Ai fokusohet në nxjerrjen e klientëve, një metrikë kyçe për bizneset që përballen me klientët në një gamë të gjerë industrish, duke përfshirë telekomunikacionin, tregtinë elektronike dhe shërbimet e transmetimit. Parashikimi i rënies është kritik, pasi "mbajtja e klientit është shtytësi kryesor i të ardhurave të një kompanie".

Për këtë projekt, Udacity ofroi një grup të dhënash 12 GB të aktivitetit të klientit nga Sparkify, një shërbim imagjinar i transmetimit të muzikës i ngjashëm me Spotify ose Pandora. Të dhënat e të dhënave regjistrojnë ndërveprimet e përdoruesve me shërbimin, si dëgjimi i këngëve në transmetim, shtimi i këngëve në listat e luajtjes, gishtat lart e poshtë, etj.

Ofrohen gjithashtu nëngrupe të vogla (125 MB) dhe të mesme (237 MB) të grupit të plotë të të dhënave.

Në varësi të madhësisë së të dhënave, ne mund të përdorim një makinë lokale ose të vendosim një grup në cloud. Në secilin rast, ne do të përdorim Pyspark, Python API për Apache Spark.

Deklarata e problemit

Ky është një problem i parashikimit të shmangies së klientëve të Sparkify. Përdoruesit mund të abonohen në një nivel premium ose në një nivel falas që shfaq reklama midis këngëve. Ata ndërveprojnë me shërbimin siç përshkruhet më sipër. Ata mund të përmirësojnë, të ulin ose të anulojnë abonimin e tyre në çdo kohë.

Qëllimi ynë është të ndërtojmë një model të thjeshtë klasifikimi binar që mund të parashikojë në mënyrë efikase nëse një përdorues do të shpërthejë apo jo. Me thjeshtësi, nënkuptojmë me karakteristika optimale.

Ne duhet të përcaktojmë churn, variablin e synuar për të parashikuar dhe të krijojmë një grup karakteristikash të grumbulluara për të trajnuar modelin.

Së pari do të përdorim nëngrupin e vogël të të dhënave për të kryer analizën e të dhënave eksploruese dhe për të ndërtuar një model prototip të mësimit të makinerive duke përdorur paketën PySpark ML. Më pas do të rritemi duke përdorur grupin e të dhënave me madhësi mesatare (237 MB). Më në fund, ne do të vendosim një grup në cloud me AWS duke përdorur të dhënat e plota 12 GB.

Në këtë artikull, ne do të kalojmë në hapat e analizës së të dhënave, inxhinierisë së veçorive dhe modeleve të klasifikimit të ndërtesave duke përdorur Apache Spark, motorin informatikë të shkallëzuar më të përdorur.

Së fundi, ky artikull përfundon me një përmbledhje të zgjidhjes sime nga fundi në fund të problemit dhe një diskutim të përmirësimeve të mundshme.

Ngarkimi dhe pastrimi i të dhënave

Për këtë pjesë të projektit, ne do të përdorim grupin e vogël të të dhënave dhe do të punojmë në një fletore Jupyter në një makinë lokale (8 GiB memorie) me Python3.10.9 dhe Spark3.4.1 është instaluar.
Të dhënat e vogla vijnë në formën e një skedari JSON që përmban 286 500 rreshta nga 225përdorues unikë ndërmjet tetorit dhe dhjetorit 2018.
Skema tregon se ka 18 kolona:

Përveç aktivitetit të përdoruesit, grupi i të dhënave regjistron informacionin e përdoruesit si gjinia dhe vendndodhja, vulat kohore dhe ID-të e sesioneve.
Pastrimi i të dhënave është hapi i parë përpara çdo analize të të dhënave. Ai përfshin gjetjen e vlerave të pasakta, të dëmtuara dhe që mungojnë.
Për të identifikuar vlerat që mungojnë, mund të përdorim funksionin isNull si më poshtë:

Ekzistojnë dy lloje vlerash që mungojnë:

• Mungon informacion për përdoruesit e paregjistruar. Meqenëse qëllimi ynë është të parashikojmë zhurmat, ne do t'i heqim këto rreshta sepse nuk e dimë se kujt i përkasin.
• Mungojnë informacione për artistin dhe këngën për ngjarje që nuk janë këngë. Ne nuk do t'i fshijmë këto rreshta.

Analiza paraprake

Për të kuptuar të dhënat e Sparkify, së pari shikova shpërndarjen e veçorive kategorike, të tilla si gjinia dhe faqja e vizituar, si në nivelin e regjistrit ashtu edhe në nivelin e përdoruesit. Për vizualizim dhe interaktivitet më të mirë, përdora Plotly për të shfaqur komplotet.

Grafikët e mësipërm tregojnë se megjithëse ka më pak gra se burra (104krahasuar me 121), ka më shumë ndërveprime femrash (155,000 krahasuar me < fortë>124,000).

Numri i përdoruesve të shërbimit falas është gjithashtu më i lartë (195krahasuar me 165për shërbimin me pagesë) dhe faqja "NextSong" është më e vizituara, siç pritej. për një shërbim të transmetimit të muzikës.

Më pas shikova shpërndarjen e veçorive numerike, të tilla si numri i ndërveprimeve dhe kohëzgjatja e sesionit për përdorues.

Shpërndarja është e anuar drejtë. Ka disa dallime ekstreme. Për shembull, kohëzgjatja mesatare e sesionit është 160minuta, ndërsa disa seanca zgjasin më shumë se 4400minuta (3 ditë). Një vështrim më i afërt i të dhënave të jashtme tregon se sa më gjatë të jetë sesioni, aq më shumë regjistra krijohen.

Prandaj, ne kemi vendosur të mos i fshijmë këto vlera ekstreme, pasi ato nuk janë gabime në regjistra, por pasqyrojnë sjelljen e përdoruesit.

Përcaktimi i Churn

Përpara se të ndërtojmë modelin tonë parashikues, duhet të përcaktojmë churn për përdoruesit e Sparkify dhe të krijojmë një kolonë të quajtur “curn” për ta përdorur si etiketë për modelin tonë.

Mund të përcaktohen dy lloje të shurdhëruesve: ata që e kanë ulur llogarinë e tyre nga me pagesë në falas (49 përdorues) dhe ata që e kanë anuluar shërbimin fare (52 përdorues).

Kam vendosur të përfshij vetëm këtë të fundit, pasi ata që degradojnë janë ende duke e përdorur shërbimin, qoftë edhe falas, dhe nuk janë të humbur përfundimisht.

Si mund t'i identifikojmë çurnerët në grupin tonë të të dhënave?

Ne thjesht mund të përdorim ngjarjen e faqes "Konfirmimi i anulimit", që është konfirmimi i kompanisë për kërkesën e anulimit të abonimit të një klienti.

Duke përdorur një UDF(funksion i përcaktuar nga përdoruesi) dhe një ID të përdoruesit Window.partitionBy, ne mund të identifikojmë churnerët si më poshtë:

Analiza e të dhënave eksploruese

Tani që kemi përkufizuar përçarjen, le të bëjmë një analizë të thellë të të dhënave eksploruese për të vëzhguar sjelljen e përdoruesve që kanë qëndruar kundrejt atyre që janë larguar.

Veçoritë kategorike:

Këtu krahasojmë shkallën e frenimit midis dy grupeve të përdoruesve.

Gjinia dhe niveli: Grafiku i mëposhtëm tregon se meshkujt kanë më shumë gjasa të shpërthejnë sesa femrat (26,4% kundrejt 19,2%) dhe përdoruesit e lirë janë pak më shumë gjasa për t'u shpërthyer (23,6% kundrejt 21,8%).

UserAgent:Së pari, ne e ndajmë kolonën UserAgent në dy kolona, ​​Device dhe Browser, si më poshtë:

Nuk është çudi që pajisjet më të përdorura janë Windowsdhe Mac. Linux X11dhe iPhone kanë normat më të larta të frenimit në 42%dhe 31% respektivisht. Kjo mund të tregojë probleme të mundshme me aplikacionin në këto pajisje.

Firefox-i ka një shkallë më të lartë të frenimit sesa Safari (32% vs 21%).

Shteti:Shumica e përdoruesve janë të vendosur në Kaliforni, Teksas, Nju Jork/Nju Xhersi/Penn dhe Florida.

Përdorimi i "gjendjes" për modelin tonë do të shtojë 58 veçori (një veçori për shtet), duke rezultuar në një rrezik të lartë të përshtatjes së tepërt, veçanërisht me të dhënat tona të vogla (225 përdorues). Kjo është arsyeja pse "shteti" nuk do të jetë pjesë e inxhinierisë sonë të tipareve.

Ngjarjet e faqes:nxënësit kanë më pak ngjarje në faqe se sa ata që nuk e lexojnë: Ata shtojnë më pak miq dhe lista luajtjeje, kërkojnë më pak ndihmë, dëgjojnë më pak këngë, etj.

Interesant është fakti se çurnerët gjithashtu hasën më pak gabime, gjë që në mendimin e dytë ka kuptim pasi ata janë më pak aktivë dhe për këtë arsye më pak gjasa për të bërë gabime.

Duke parë raportin e ngjarjeve të faqeve midis dy grupeve, faqet më të përdorura janë mjaft të ngjashme për shfrytëzuesit dhe ato jo: 81% e regjistrave vijnë nga faqja NextSong, që lidhet me dëgjimin e muzikës, me "Thumbs Up" dhe "Home" që përbëjnë 90% të totalit të vizitave të faqes.

Interesante, ndryshimi më domethënës midis përdoruesve dhe atyre që nuk flasin lidhet me faqet "reklamë me xhiro" dhe "gishti i madh poshtë", me një delta prej 0,9% fortë> dhe 0.23% përkatësisht. Kjo sugjeron që turpëruesit janë veçanërisht të pakënaqur me reklamat.

Veçoritë numerike:

Karakteristikat numerike përfshijnë numrin e sesioneve, këngëve dhe artistëve, si dhe kohëzgjatjen e sesionit, numrin e ditëve që nga regjistrimi dhe gjatësinë e këngëve të dëgjuara.

Për të krahasuar shpërndarjen e këtyre variablave midis dy grupeve të përdoruesve, thjesht krahasojmë devijimin mesatar, mesatar dhe standard.

Siç sugjerohet nga masat statistikore, shpërndarja e këtyre karakteristikave (përveç numrit të seancave) ndryshon dukshëm ndërmjet dy grupeve.

Si hap i fundit përpara se të kalojmë në inxhinierinë e veçorive, le të shohim një tjetër metrikë kyçe për gjurmimin e angazhimit të përdoruesit: intervali i sesionit, që është koha mesatare midis dy seancave të njëpasnjëshme.

Për aplikacionet celulare dhe ueb, një interval më i shkurtër i sesioneve duhet të tregojë një nivel më të lartë angazhimi, pasi përdoruesit e vizitojnë aplikacionin më shpesh dhe për këtë arsye janë shumë të angazhuar. Anasjelltas, një interval më i gjatë seancash duhet të tregojë më pak interes.

Çuditërisht, siç tregohet në grafikun e mësipërm, intervali më i lartë i sesioneve për Sparkify është për ata që nuk ndizen, gjë që është kundërintuitive. 91% e atyre që nuk frekuentojnë kanë një interval sesioni prej më pak se 150 minuta krahasuar me 46% e atyre që nuk frekuentojnë.

A po shkarkojnë dhe dëgjojnë përdoruesit e Sparkify këngët e tyre të preferuara jashtë linje (si përdoruesit e Spotify Premium)? Fatkeqësisht, nuk kemi një ngjarje faqeje që tregon aktivitetin e shkarkimit për të konfirmuar këtë sjellje. Megjithatë, dhe më e rëndësishmja, ka një ndryshim domethënës në intervalin e seancës midis dy grupeve që nuk mund të injorohet. Ne presim që kjo të jetë një nga karakteristikat më të rëndësishme në parashikimin e dyndjes.

Inxhinieri e veçorive

Inxhinieria e veçorive është çelësi për të marrë rezultatet më të mira nga algoritmet e mësimit të makinerive.

Nga përzgjedhja e veçorive deri tek trajtimi i të dhënave të pabalancuara, ne do të kalojmë nëpër të gjitha hapat e këtij procesi.

Por së pari ne duhet të ndërtojmë veçoritë për të trajnuar modelet tona. Në fakt, ndërsa grupi i të dhënave i vogël përmban një mesatare prej rreth 1235 rreshtave për çdo përdorues, modelet e klasifikimit binar presin vetëm një rresht për çdo përdorues. Prandaj ne duhet të krijojmë masa agregate.

Ndërtoni veçoritë

Bazuar në analizën tonë dhe identifikimin e kolonave me dallime midis grupeve të përdoruesve, unë krijova veçoritë e mëposhtme të grumbulluara.

1. Veçoritë kategorike

• gjinia: M ose F (binare).
• niveli: Niveli më i fundit i përdoruesit: me pagesë ose falas (binar).
• userAgent: ndahet në shfletues dhe pajisje (kategorike)

2. Veçoritë numerike

• Numri i seancave (int)
• Ditë nga regjistrimi (lundrues)
• Intervali i sesionit, që është koha mesatare midis dy seancave të njëpasnjëshme (float)
• Kohëzgjatja mesatare e sesionit (lundrues)
• Orë_gjithsej, që është gjatësia totale e sesionit (lundrues)
• Këngët mesatare për seancë(float)
• Numri i artistëve dhe këngëve unike që përdoruesi ka dëgjuar (int).
• Gjatësia totale:gjatësiae këngëve që përdoruesi ka dëgjuar (float)
• Numri i faqeve të shikuara në orë(lundrues)
  ku faqja është në: rreth, add_friend, add_to_playlist, degrade, gabim, ndihmë, shtëpi, dalje , roll_advert, save_settings, settings, submit_downgrade, submit_upgrade', thumbs_down, thumbs_up dhe upgrade.

Për të krijuar këto grumbullime, përdora një sërë funksionesh nga paketa pyspark.sql.functions. Blloku i mëposhtëm i kodit ilustron se si të përdoren këto funksione:

Kam përdorur PySpark DataFrame. Nëse jeni më të kënaqur me pyetjet SQL, mund të përdorni Spark SQL i cili ju lejon të ekzekutoni pyetje SQL dhe të ktheni rezultatin në formën e një DataFrame.

Zgjedhja e veçorive

"Teknikat e përzgjedhjes së veçorive", siç sugjeron emri, është procesi i zgjedhjes së veçorive pa i transformuar ato. Përfitimet kryesore të këtij procesi janë thjeshtimi i modelit, zvogëlimi i kohës së stërvitjes dhe shmangia e përshtatjes së tepërt.

Fillimisht hoqa veçori, të tilla si count_ongs, count_logs dhe count_sessions, të cilat janë shumë të lidhura me total_hours (shuma e të gjitha gjatësive të sesioneve), siç tregohet në matricën e korrelacionit më poshtë.

Më pas zgjodha veçoritë që lidhen më së shumti me variablin e synuar (çurn) duke përdorur bibliotekën SelectKBest, e cila zgjedh veçoritë bazuar në k rezultatet më të larta, ku funksioni i rezultatit është chi-square .

Mund të shohim se ditët që nga regjistrimi dhe masat e angazhimit (intervali dhe total_orë ose kohëzgjatja totale e seancës) janë më të vlerësuarat.

Tani, sa veçori mund të zgjedhim për të pasur një model të thjeshtë dhe për të shmangur përshtatjen e tepërt?

Për ta mbajtur atë të thjeshtë dhe për të marrë rezultatet më të mira, ne do të ndërtojmë një seri verifikuesish të kryqëzuar me K-fold duke përdorur klasifikuesit PySpark ML dhe veçori të ndryshme N të zgjedhura, ku N = varg(4,len( veçoritë_për të_mbajtur)-1,4).

Duke qenë se do të duhej shumë kohë për të testuar të gjitha vlerat, ne zgjedhim një hap prej 4.

Modelimi

Qëllimi i modeleve të të mësuarit të makinerive është të parashikojnë shpërbërjen bazuar në veçoritë e krijuara në seksionin e mëparshëm. Krijimi i tubacionit, verifikimi i kryqëzuar, trajnimi dhe vlerësimi i modelit trajtohen në këtë seksion.

Tubacioni i shkëndijës dhe Vërtetimi i kryqëzuar

Për të lidhur në mënyrë efektive transformatorët dhe vlerësuesit, dhe për të shmangur rrjedhjen e të dhënave, krijova një rrjedhë pune ose tubacion Pyspark. Ai përbëhet nga:

• VectorAssembler, i cili bashkon në mënyrë efikase veçoritë tona në një kolonë vektoriale, duke përdorur "më pak memorie".
• MinMaxScaler, i cili rishkallëzon çdo veçori në intervalin midis 0 dhe 1, në mënyrë që një kolonë me vlera më të ulëta të jetë po aq e rëndësishme për modelin sa një kolonë me vlera më të larta.
• Klasifikuesi MLlib: një klasifikues i zgjedhur.

Më pas krijova një vleftësues të kryqëzuar me K-fish duke përdorur tubacionin e mësipërm si vlerësues dhe f1-rezultatin si metrikë vlerësimi (zgjedhja e kësaj metrike diskutohet në vijim seksioni). K është numri i palosjeve, të cilin e kam vendosur në 5. Megjithëse vlerësimi kërkon pesë herë më shumë llogaritje, ia vlen të vlerësoni më mirë performancën e parashikimit të modelit dhe të shmangni përshtatjen e tepërt, veçanërisht me grupin tonë të vogël të të dhënave.

Metrika e vlerësimit dhe trajtimi i të dhënave të pabalancuara.

Të dhënat tona kanë klasa të pabalancuara, pasi ka vetëm 23,1% churner, që do të thotë se modeli ka më shumë informacion për përdoruesit aktivë (klasa e shumicës) sesa për churnerët (klasa e pakicës). Nëse modeli gjithmonë parashikon për përdoruesit aktivë, marrim një saktësi të mirë prej 77%. Megjithatë, kjo fsheh performancën e vërtetë të klasifikuesit, i cili kurrë nuk identifikon një dyndje.

Prandaj, Saktësia është mashtruese dhe nuk duhet të përdoret këtu. Në vend të kësaj, ne do të përdorim rezultatin F1 si metrikë vlerësimi, e cila kombinon saktësinë dhe rikujtimin në një metrikë si më poshtë:

Rezultati F1 = (2 * saktësi * rikujtim) / (precizion + rikujtim)

Saktësiaështë përqindja e dridhjeve të parashikuara saktë (pozitive të vërteta) nga numri i përgjithshëm i ndezësve të parashikuar. Saktësia më e lartë çon në më pak pozitive false(modeli parashikon shpërbërjen kur nuk duhet të ketë).

Recall, nga ana tjetër, është përqindja e dridhjeve të parashikuara saktë nga numri i përgjithshëm i ndezësve realë. Kujtesa më e lartë çon në më pak negativë të rremë (modeli nuk parashikon asnjë përmbysje kur duhet të kishte parashikuar shpërbërjen).

Nga perspektiva e biznesit, kujtesa dhe saktësia më e lartë do të thotë që çdo zbritje ose promovim marketingu synohet në mënyrë efektive për njerëzit që janë në rrezik për t'u larguar.

Së fundi, vlen të përmendet se përdorimi i rezultatit f1si një metrikë vlerësimi nuk është një zgjidhje për problemin e mosbalancimit. Ka disa teknika për të zgjidhur këtë problem, të tilla si ri-kampionimi, gjenerimi i të dhënave sintetike për klasën e pakicës (SMOTE) dhe balancimi i peshave të klasave.

Balancimi i peshave të klasave për t'u marrë me çekuilibrin e klasës

Balancimi i peshave të klasave nuk është gjë tjetër veçse t'i japësh klasës minoritare një peshë më të madhe dhe të ulësh peshën e klasës së shumicës. Ndryshe nga Scikit Learn, fillimisht duhet të krijojmë një kolonë të cilën do ta quajmë "pesha", si më poshtë:

Kjo kolonë më pas i caktohet parametrit “weightCol”të klasifikuesve MLlib si më poshtë:

Ndani të dhënat në grupe trajnimi dhe vërtetimi

Ashtu si me Scikit Learn, ne do t'i ndajmë të dhënat në grupe trajnimi dhe vërtetimi duke përdorur metodën randomSplit. Peshat janë përkatësisht 70% dhe 30%. Kur një model është duke u trajnuar, ai sheh vetëm të dhëna nga grupi i trajnimit. Duke përdorur grupin e vlefshmërisë, ne mund të shohim se si funksionon në të dhëna të padukshme.

Trajnim dhe vlerësim

Algoritmet që do të krahasojmë janë:

LogisticRegression, RandomForestClassifier, GBTClassifier, LinearSVC dhe DecisionTreeClassifier.

Së pari, ne instantojmë këto modele, të cilat janë të drejtpërdrejta dhe shumë të ngjashme me të mësuarit scikit.

Më pas do t'i trajnojmë këto modele për disa eksperimente dhe do të krahasojmë rezultatet e secilit model për të parë se cili performon më mirë. Më konkretisht, ne do të ndërtojmë sa vijon:

• Baza: Gazsjellësi që përdor klasifikuesin Naïve Bayes, 16 veçori të zgjedhura dhe një numër të ndryshëm farash (bashkë të dhënash të ndryshme trajnimi). Këtu nuk ka peshim të klasës.
• Eksperimenti i parë: Ndërtoni një seri vërtetuesish të kryqëzuar me K-fold duke përdorur klasifikuesit e mësipërm dhe N veçori të zgjedhura ku N = varg (4,len(features_to_keep)-1,4). Veçoritë zgjidhen duke përdorur bibliotekën SelectKBest.
• Eksperimenti i dytë: Njësoj si eksperimenti i parë me balancimin e peshës së klasës.
• Eksperimenti i tretë: Njësoj si eksperimenti i dytë me sintonizimin e hiperparametrave.

Çdo eksperiment dhe secili model do të kalojë nëpër hapat e mëposhtëm:

• Ndërtoni modelin.
• Trajnoni modelin.
• Vlerësoni modelin dhe ruani metrikat e vlerësimit të parashikimit në CSV për krahasim të mëvonshëm.

Rezultatet dhe interpretimi

Baza: Naive Bayes

Naive Bayes është një model i thjeshtë. Mund të sigurojë një bazë të mirë për eksperimentet e ardhshme. Avantazhi i përdorimit të Multinomial Naive Bayes është se trajnimi është shumë i shpejtë, siç tregohet në grafikun e mëposhtëm.

Modeli Naïve Bayes është trajnuar në grupe të dhënash të ndryshme trajnimi (një listë e vlerave të farës është përcaktuar për të ndarë rastësisht të dhënat në grupe trajnimi dhe testimi).

Ky grafik tregon se rezultati f1 i modelit Naive Bayes varion nga0,6 deri në 0,75 (duke përjashtuar vlerat e jashtme), me një mesatare prej 0,68.

70% duket një bazë e mirë për rezultatin tonë f1.

Për eksperimentet e mëvonshme, ne mund të trajnojmë modelet tona për vlera të ndryshme farash. Megjithatë, kjo do të merrte shumë kohë në mënyrat e trajnimit dhe përfundimit.

Tani e tutje, farat e ndarjes së rastësishme dhe klasifikuesit e pemëve janë vendosur në 42për thjeshtësi dhe riprodhueshmëri.

Eksperimenti i parë: K-fish vlefshmëria e kryqëzuar duke përdorur N veçori të zgjedhura. Asnjë peshë e klasës.

Rezultatet për sa i përket rezultatit f1 dhe kohës së stërvitjes janë paraqitur më poshtë.

Për një numër më të madh karakteristikash (mbi 12karakteristika), algoritmet e paragjykimit të lartë/variancës së ulët, përkatësisht SVC Linear dhe Regresioni Logjistik, i tejkalojnë algoritmet e bazuara në pemë, të cilat fillojnë të mbivendosen pas 16 veçoritë.

Për të marrë modelin më të thjeshtë, që është qëllimi ynë, ne mund të zgjedhim ose DecisionTree ose GBTClassifier, pasi ato përdorin numrin më të vogël të veçorive (12) për të marrë një rezultat f1 prej 82.2% .

Për sa i përket kohës së trajnimit (në makinën time lokale), GBTClassifier dhe LinearSVC janë më të ngadaltët me respektivisht 44sekonda dhe 54sekonda. DecisionTreeClassifier dhe RandomForestClassifier janë më të shpejtët me vetëm 7 sekonda.

Në këtë fazë, duke pasur parasysh performancën e tij të mirë për sa i përket rezultatit f1 dhe kohës së stërvitjes, ne mund të zgjedhim algoritmin DT. Megjithatë, ne duhet të kryejmë eksperimente të mëtejshme përpara se të zgjedhim algoritmin më të mirë.

Në eksperimentin tjetër, ne do të shqyrtojmë efektin e peshimit të klasës në performancën e modelit.

Eksperimenti i dytë: balancimi i peshës së klasës.

Këtu është një grafik i rezultatit F1 me dhe pa peshën e klasës.

Mund të shohim se peshimi i klasës përmirësoi ndjeshëm performancën e RandomForestClassifier, LinearSVC dhe regresionit logjistik, me një rritje prej rreth 10% me më pak karakteristika të zgjedhura.

Më shumë se 12 veçori nevojiten për të parë efektin e peshimit të klasës për klasifikuesin GBT.

Në mënyrë mbresëlënëse, LinearSVC arriti një rezultat prej 85% me vetëm 4 veçori, përkatësisht intervalin e sesionit, orët totale (gjatësia totale e sesionit), ditët nga regjistrimi dhe numri mesatar i këngëve për seancë.

Rezultati më i mirë f1 i këtij eksperimenti është 87.7%. Është marrë duke përdorur klasifikuesin RFC dhe 8 veçori.

Tani le të shfaqim veçoritë më të rëndësishme për modelin RFC. Ne do të përdorim veçorinë “FatureImportances”të këtij klasifikuesi.

Grafiku i mësipërm tregon se 80% e peshave mund të llogaritet nga 4 veçoritë e para më të rëndësishme: ditët nga regjistrimi, intervali i sesioneve, reklamat në listë dhe faqet me gishta poshtë.

Kjo sugjeron që sjellja e klientit dhe ekspozimi ndaj reklamave janë shtytësit kryesorë të turbullimit. Është interesante që karakteristikat si gjinia dhe niveli i shërbimit nuk shfaqen në top 8.

Eksperimenti i tretë: sintonizimi i hiperparametrit

Për të përmirësuar më tej performancën e marrë në eksperimentin e dytë, kam kryer akordimin e hiperparametrit duke përdorur një rrjet parametrash, me përjashtim të klasifikuesit GBT, të cilin e gjeta shumë të ngadaltë për t'u trajnuar në makinën time lokale.

Rregullimi i parametrave të rregullimit të regresionit logjistik dha një rezultat F1 prej 85%, që është një përmirësim i lehtë mbi parametrat e paracaktuar.

Për algoritmet e tjera, parametrat e paracaktuar vazhdojnë të japin performancën më të mirë.

Në këtë fazë mund të përpiqemi të sintonizojmë hiperparametrat e tjerë, por kërkon shumë kohë dhe është më mirë të përdorim më shumë të dhëna.

Rritja e shkallës: grup i të dhënave mesatare

Tani që e dimë se kodi ynë më i vogël i modelimit po funksionon si duhet, është koha për të rritur me më shumë të dhëna, që është një praktikë e zakonshme në mësimin e makinerive.

Në këtë seksion, ne do të përdorim grupin e të dhënave mesatare (237 MB), i cili përmban 543 705 rreshta nga 448 përdorues unikë midis tetorit dhe dhjetorit 2018.

Ne do të përsërisim të gjithë hapat që kemi ndjekur për grupin e vogël të të dhënave, nga analiza e të dhënave eksploruese te modelimi, përmes inxhinierisë së veçorive dhe përzgjedhjes së veçorive.

Statistikat e grupeve të të dhënave të mesme dhe të vogla

Le të krahasojmë së pari statistikat e mediumit me grupet e vogla të të dhënave.

Më sipër mund të shohim se, ndryshe nga grupi i të dhënave mini, femrat kanë më shumë gjasa të shpërthejnë (22,7% kundrejt 21,6% për meshkujt) dhe përdoruesit me pagesë kanë pak më shumë gjasa të largohen (23,4% kundrejt 22,2% për nivelin e lirë) .

Këto ndryshime nuk do të ndikojnë në modelin tonë pasi ai bazohet në sjelljen e përdoruesit dhe jo në karakteristikat e përdoruesit (siç tregohet në pjesën e mëparshme).

Është interesante se të dy grupet e të dhënave kanë të njëjtat statistika për faqet "Thumbs down" dhe "Roll Advert", të cilat kanë diferencën më të rëndësishme në proporcion midis drithëruesve dhe atyre që nuk dënojnë me një delta prej 0.9 % dhe 0.23% respektivisht.

Për sa i përket veçorive numerike, varianca në numrin e këngëve dhe artistëve është më e ngjashme midis dy grupeve në krahasim me grupin e vogël të të dhënave. Përdoruesit aktivë shpenzojnë 4 herë më shumë minuta për të dëgjuar muzikë se sa çirner, krahasuar me 5 herë në grupin e vogël të të dhënave. Së fundi, ne kemi ende një ndryshim të rëndësishëm midis churners dhe jo-churners për sa i përket intervalit të sesionit.

Rezultatet duke përdorur grupin e të dhënave mesatare

Rezultatet për sa i përket rezultatit f1 dhe kohës së stërvitjes janë paraqitur më poshtë.

Klasifikuesit Random Forest dhe GBT, e tejkalojnë SVC Linear dhe Regresionin Logjistik pasi atyre u nevojiten vetëm 8 veçori për të arritur një rezultat f1 prej rreth 85%.

Rezultati më i mirë f1 është 87%. Është marrë duke përdorur funksionet Random Forest dhe 12.

Është interesante se klasifikuesi RFC performoi mirë si në grupet e të dhënave të vogla ashtu edhe në ato të mesme, me maja mbi 87%.

Klasifikuesi GBT performoi më mirë në grupin e të dhënave mesatare sesa në atë të vogël (85% kundrejt 82%). Le të shohim se si do të funksionojë në grupin e madh të të dhënave.

Mësimi i makinës në shkallë: grupi i madh i të dhënave

Deri më tani, ne kemi përdorur Spark në një makinë lokale. Për të shfrytëzuar fuqinë e tij për të dhëna të mëdha, ne do të përdorim grupin e plotë të të dhënave të Sparkify (12 GB) në një sistem të shpërndarë. Në mënyrë të veçantë, ne do të përdorim Amazon EMR (Amazon Elastic MapReduce) për të ngritur dhe lëshuar një grup Spark prej 4 m4-xlarge nyje bërthamore (instancat EC2).

Të dhënat e plota përmbajnë 26,26 milionë rreshta nga 22,277 përdorues.

Ne do të përdorim gjithashtu skriptet Python në vend të fletores Jupyter pasi kemi eksploruar dhe vizualizuar tashmë të dhënat dhe kemi ndërtuar prototipin tonë të mësimit të makinerive.

Ekzekutoni skriptin Python në grupin EMR të Amazon

Skenarin që kam ripunuar nga fletorja ime Jupyter mund ta gjeni këtu. Ajo:

• Merr të dhënat e plota nga shërbimi SSsistemi SS3: s3n://udacity-dsnd/sparkify/sparkify_event_data.json.
• Pastron të dhënat.
• Krijon veçori dhe trajnon modele duke përdorur peshimin e klasave, veçori të ndryshme të zgjedhura dhe rrjetin e paracaktuar të parametrave.
• Vlerëson klasifikuesit dhe ruan rezultatet (f1-rezultati, koha e trajnimit…) si një skedar parketi në kovën time S3 të quajtur "my-sparkify-backet".

Skripti Python më pas ngarkohet në kovën time S3.

Më në fund, pasi të lidhem me makinën master përmes SSH, e dorëzoj skriptin në grupin tim përmes linjës së komandës si më poshtë:

Komanda e parë shkarkon skriptin nga S3 në makinën kryesore për ekzekutim.

Tani puna jonë në Spark po funksionon. Duhen pothuajse 45 minuta për të përfunduar. Kur skripti të përfundojë, unë do të mbyll grupin EMR dhe do t'i fshij skedarët e mi nga S3, pasi shërbimet AWS janë të paguara sipas dëshirës.

Rezultatet dhe interpretimi

Rezultatet për sa i përket rezultatit f1 dhe kohës së stërvitjes, duke përdorur parametrat e paracaktuar të Grid, janë paraqitur më poshtë.

Duke zgjedhur vetëm 8 veçori, modelet e bazuara në pemë janë më të mira se modelet e regresionit LinearSVC dhe Logistic.

Klasifikuesi GBT vjen i pari me një rezultat f1 prej 85,6%, përpara RFC me 83% dhe DT me 82,2%.

Përdorimi i Apache Spark në grupin EMR (4 nyje bazë) ka reduktuar kohëzgjatjen e trajnimit të modeleve tona. Për shembull, koha e trajnimit të klasifikuesit GBT në grup për 22,277 përdoruesit është rreth 55 sekonda. Në makinën time lokale, iu desh e njëjta kohë vetëm 225përdoruesve. Kjo tregon fuqinë e Apache Spark.

Tani le të shfaqim veçoritë më të rëndësishme të modelit GBT.

Është interesante të theksohet se shtytësit kryesorë të largimit mbeten pothuajse të njëjtë në krahasim me grupin e vogël të të dhënave.

Intervali i sesionit, kohëzgjatja mesatare e sesionit dhe ditët që nga regjistrimi përbëjnë pothuajse 60%. Kjo do të thotë se modeli kryesisht shikon se sa shpesh dhe për sa kohë përdoruesit angazhohen me shërbimin Sparkify.

Një tjetër mundësi interesante është se reklamimi i listës është ende një faktor i rëndësishëm për t'u larguar, me një rëndësi prej 9%.

Në këtë fazë, ne ende mund të përmirësojmë rezultatin f1 duke akorduar hiperparametrat e klasifikuesit GBT.

Në pjesën tjetër, ne do të mendojmë për ide të tjera që mund të përmirësojnë rezultatet.

Përfundim

Ky ishte një projekt shumë emocionues për mua. Nga ndërtimi i një modeli prototip deri tek ekzekutimi i një skripti Python në një grup EMR me të dhëna të mëdha, kishte shumë për të mësuar dhe për të ndryshuar.

Përmbledhje zgjidhjesh nga fundi në fund

Së pari, përdora grupin e vogël të të dhënave për të kryer analizën hulumtuese të të dhënave. Më pas përcaktova churn dhe analizova sjelljen e përdoruesve që kanë qëndruar kundrejt atyre që janë larguar.

Më pas mbulova të gjithë hapat për inxhinierinë e veçorive dhe modelet e klasifikimit të ndërtimit duke përdorur Apache Spark. Kam shfrytëzuar PySpark DataFrame API, të cilin e gjeta intuitive sepse është e ngjashme me kornizat e të dhënave të Panda.

Kam ndërtuar një seri vleftësuesish të kryqëzuar në K-fold duke përdorur një sërë veçorish të zgjedhura, peshën e klasës dhe akordimin hiper-parametër. E gjeta Spark relativisht të ngadaltë në makinën time lokale, veçanërisht për akordimin hiperparametër të klasifikuesve GBT dhe LinearSVC.

Rezultati f1u përdor për të vlerësuar modelet, që është një metrikë e përshtatshme për të dhënat tona të pabalancuara.

Në grupin e vogël të të dhënave, peshimi i klasës përmirësoi ndjeshëm performancën e RandomForestClassifier, LinearSVC dhe regresionit logjistik, me një rritje prej rreth 10% me më pak karakteristika të zgjedhura.

Klasifikuesit GBT i duheshin më shumë të dhëna për të performuar më mirë (85% në grupet e të dhënave të mesme dhe të mëdha kundrejt 82% në grupin e të dhënave të vogla).

Pjesa e fundit e projektit u fokusua në të mësuarit me makinë në shkallë. E ktheva fletoren time Jupyter në një skript Python përpara se ta ekzekutoja në një grup EMR. Kjo uli ndjeshëm kohën e trajnimit të modeleve dhe tregoi fuqinë e Apache Spark në të dhëna të mëdha.

Në grupin e plotë të të dhënave, GBTClassifier ishte algoritmi më i mirë me një rezultat f1 prej 85,6%, 2,5% përpara RandomForestClassifier.

Karakteristikat më të rëndësishme treguan se sjellja e klientit, ditët që nga regjistrimi dhe ekspozimi ndaj reklamave janë nxitësit kryesorë të braktisjes. Prandaj, Sparkify duhet të optimizojë sistemin e tij të reklamave dhe të shtojë më shumë risi dhe qetësi (një përdorues befasohet këndshëm nga rekomandimi) në motorin e tij të rekomandimeve për të mbajtur klientët e tij të angazhuar.

Përmirësime të mundshme

Churn është parashikuar me një rezultat F1 prej 85.6%. Mund të jemi të kënaqur me këtë rezultat. Megjithatë, ka vend për përmirësim si në inxhinierinë e veçorive ashtu edhe në modelim.

Veçoritë shtesë mund të nxirren nga vendndodhja e përdoruesit dhe koha e aktivitetit, siç është dita e javës. Për sa i përket vendndodhjes, shtimi i një veçorie për çdo shtet mund të çojë në përshtatje të tepërt veçanërisht në grupin e vogël të të dhënave. Prandaj, krijimi i grupeve të shteteve mund të jetë një ide e mirë.

Ne i trajnuam modelet tona duke përdorur veçori të përmbledhura që pasqyrojnë sjelljen e përdoruesit. Për ta bërë këtë një hap më tej, do të ishte interesante nëse modelet tona mund të shihnin se si ndryshon sjellja e një përdoruesi me kalimin e kohës.

Përpara zgjedhjes së veçorive (ne përdorëm bibliotekën SelectKBest), mund të kryenim një Analizë të komponentëve kryesorë, e cila ndihmon në reduktimin e veçorive të ndërlidhura në një, duke reduktuar kështu dimensionet dhe duke thjeshtuar më tej modelin tonë.

Edhe pse pikat e jashtme pasqyrojnë sjelljen e përdoruesit, ne mund t'i heqim ato dhe të shohim nëse kjo do të përmirësonte rezultatin F1, veçanërisht për grupin e plotë të të dhënave ku kemi më shumë të dhëna në dispozicion.

Për t'u marrë me të dhënat tona të pabalancuara, ne përdorëm peshimin e klasës, të cilin e gjetëm të thjeshtë dhe efektiv. Mund të provojmë gjithashtu marrjen e mostrave të tepërta duke përdorur SMOTE dhe të shohim se cila teknikë funksionon më mirë me të dhënat tona.

Për sa i përket modelimit, mund të provojmë klasifikuesin shumështresor Perceptron dhe për modelet që kemi ndërtuar deri tani, mund të akordohen hiperparametra të tjerë.

Së fundi, një përmirësim tjetër do të ishte përdorimi i një periudhe më të gjatë vëzhgimi, pasi sjellja dhe preferencat e përdoruesit mund të ndryshojnë me kalimin e kohës.

Zbatimi i këtyre ndryshimeve mund të përmirësojë më tej rezultatin e F1, duke lejuar Sparkify të synojë me saktësi klientët e mundshëm me veprime të përshtatshme marketingu, të tilla si zbritjet.

Për të parë më shumë rreth këtij projekti, shihni lidhjen me Github tim të disponueshëm këtu.