Adatbányászat Blog

Az Adatbányász Blogon a dmlab szakértőinek írásait olvashatod a big data és data science területéről.

dmlab.hu - Big data és data science tanácsadás
"Ha örülsz, hogy fejedre nőttek az adatok."

Keress minket bátran:
- Nagy-Rácz István +36704595669
- Gáspár Csaba +36208234154
- info@dmlab.hu

Hírlevél

Iratkozz fel hírlevelünkre, hogy mindig naprakészen tudjunk tájékoztatni.
Feliratkozás
Leiratkozás

Címkék

2007 (1) 2010 (23) 2011 (27) 2012 (13) 2013 (23) 2014 (5) 2015 (6) 2016 (10) 2017 (2) adaptív (1) adat- és médiainformatika (1) adatárusítás (1) adatbányászat (10) adatbányászati algoritmusok (1) adatbányászati alkalmazások (2) adatbányászati meetup (1) adatbányászati oktatás (1) adatbányászati technológiák (4) adatelemzés (1) adatelemzési platformok (1) adattárház (5) adattárház fórum (6) adattárolás (1) adattisztítás (1) adatvédelem (2) advise (2) aegon (1) aglitás (1) agy (2) ajánló (11) ajánlórendszerek (1) aktivitás felismerés (1) algoritmus (1) alkalmazás (3) állásajánlat (1) amazon ec2 (1) ambiens (1) ami (1) analitika (1) analytics (1) andego (3) apache (1) api (2) Arató Bence (3) bank (1) barabási (2) Barabási (2) beharangazó (1) beharangozó (18) bejelentés (2) belami (1) best practice (9) beszámoló (14) BI (3) bi (13) Bi (1) bi-trek (1) biconsulting (7) bigdata (21) big data (5) Big Data (2) biopen (1) biztosító (1) BI Akadémia (1) bi consulting (1) bi start (1) blog (5) BME (14) bme (1) bootcamp (1) brainstorming (1) bsp (1) budapest (1) business analytics (1) business analytics szakirány (1) churn (2) ci (1) címkefelhő (2) CIO (1) clementine (1) Clementine Consulting (1) cloud computing (2) cognos (1) credit scoring (1) crisp-dm (1) crm (2) csalásdetektálás (1) DataExpert (1) dataexplorer (1) datapest (1) data mining (1) data science (5) diplomamunka (1) dmlab (11) döntési fák (1) drill (1) e-commerce (1) előadás (21) előrejelzés (1) élő közvetítés (1) Enbrite.ly (1) energetika (1) esemény (2) esettanulmány (3) etikus (1) etl (2) évforduló (2) fejlesztés (2) felmérés (5) felsőoktatás (1) felület (1) felvásárlás (3) film (1) fizetés (1) forecasting (1) forgalomelőrejelzés (2) foursquare (1) fraud detection (1) freebase (1) gartner (2) gazdasagi informatikus (2) gépi tanulás (4) google (8) google analytics (1) graphlab (1) gravity (3) greenplum (1) gyakorlat (1) hadoop (10) hallgatók (2) hálózatelemzés (3) hálózatkutatás (2) hálózatok (3) hazai (2) hiba (4) hírlevél (2) hive (1) honlap (1) HR (1) HVG (1) i5 (1) ibm (6) ibm modeler (1) ibm spss (3) icdm (1) idc (2) idősor (1) idősorok (1) ieee (1) iir (1) infobright (1) információbróker (1) innováció (5) innovatívBI (1) innovativ bi (4) inspiráció (1) intelligencia (2) Internet Hungary (1) iqsymposium (19) iqsys (16) iroda (4) jelentkezés (1) jmp (2) kaggle (2) kampánymenedzsment (1) kapcsolati hálók (1) karrier (1) kdd (3) kdnuggets (2) képzés (4) kérdés (1) kérdőív (1) kerekasztal (1) keresés (1) kereső (1) keresztvalidáció (4) klaszterezés (2) knime (1) kockázati tőke (1) kollaboratív munka (1) kompetencia (1) konferencia (70) könyv (6) környezet (1) közlekedés (1) közösség (2) közösségi hálózatok (4) közvetítés (6) kritika (1) küldetés (1) kürt akadémia (1) kutatás (2) lemorzsolódás (1) licensz (1) live (1) logisztika (1) magyar telekom (2) mahout (1) mapreduce (1) marketplace (1) média (2) meetup (11) mellékspecializáció (1) mém (3) memóriacentrikus (1) menedzsment (3) metaadat (1) metodika (1) microsoft (1) mobil (5) mobil bi (4) modeler (2) modell (3) morgan stanley (1) motion chart (1) munkaerő (1) mysql (1) mytraffic (4) nemzetközi (5) nemzetközi összehasonlítás (1) netflix prize (1) networking (1) next big thing (1) nips (1) nosql (1) nyílt forráskód (4) nyomkövetés (1) offline áruházak (1) okostelefon (1) oktatás (22) olvasók (1) online áruházak (1) online kutatás (1) open source (19) open source bi (3) operatorfa (1) osbi (12) összehasonlítás (1) ötletek (2) pandas (2) paradoxon (1) pascal (1) pentaho (1) personal data mining (1) phd (2) philips (1) piac (3) pikk (1) pilot (1) PISA-felmérés (1) pmml (1) politika (2) powerpivot (1) prága (1) praktiker (1) prediktív analitika (2) prediktív analitka (1) prediktív modellezés (1) prediktiv modellezés (5) prezi (15) privacy (1) privacy preserving data mining (1) projekt (1) projektmenedzsment (4) publikáció (1) python (9) radoop (12) random forest (1) rapid-i (2) rapidanalytics (7) RapidMiner (2) rapidminer (40) rcomm (7) refine (1) Rexer Analytics (1) rsctc (1) R nyelv (7) saas (1) sap (1) SAS (20) sas enterprise miner (2) sas enterpris guide (1) sas entprise miner (1) sas fórum (1) sas forum (3) siker (3) simptech (1) sixtep (2) smarthabits (1) spike sorting (1) sportanalitika (1) SPSS (3) spss (13) spss clementine (3) spss hungary (5) spss modeler (6) ssd (1) starschema (2) startup (9) statisztika (1) survey (1) svm (1) szabad szoftver (1) szakmai (1) szavazó eljárások (2) szélenergia (1) szélerőmű (1) szervezetfejlesztés (1) szociális hálók (1) szoftver (5) szöveg (1) szövegbányászat (2) sztaki (2) tableau (1) talend (2) támogatás (1) tanulmány (1) tanulság (1) távolság (1) technológia (1) tedx (1) telekommunikáció (2) teradata (2) teszt (1) text mining (1) tmit (5) toborzás (1) tőzsdei előrejelzés (1) tracking (1) trendek (8) tudományos (1) tunedit (1) twitter (17) ügyfél (1) üzleti intelligencia (3) üzleti modell (3) üzleti reggeli (3) validáció (4) válogatás (1) válság (1) változás (1) vélemény (1) véleméy (1) verseny (20) vezetői képzés (1) videó (3) vizualizáció (5) web (4) web2 (2) webanalitika (3) webshop (1) weka (2) wikipedia (2) workshop (1) yahoo (2) Címkefelhő

TWitter a csapat tagjaitól

2014.02.06. 11:00 István Nagy

Lemorzsolódás elemzése biztosítási környezetben

Címkék: verseny python biztosító churn

Csapatunkban nagy hagyománya van és mára támogatott dologgá vált, hogy tagjaink különböző adatbányászati versenyekben vesznek részt. A legjobb helyezésekről és az ezekhez kapcsolódó versenyekről a blogon is igyekeztünk beszámolni, a legfontosabb szakmai tapasztalatokat összefoglalva. A jövőben minden ilyen beszámolót egy interjú keretében mutatunk be, így a legfontosabb tapasztalatokat minden esetben meg tudjuk veletek osztani. Ha valakinek eszébe jut olyan kérdés, amit szívesen megkérdezne még, azt nyugodtan írja meg kommentben.

Elsőként egy meghívásos Kaggle versenyen elért nagyszerű helyezésről szeretnénk írni. A Kaggle platformot már nem kell senkinek bemutatni a blogunkat rendszeresen olvasók közül. A meghívásos versenyek sajátosságai, hogy ezeken nem indulhat bárki a rendszer regisztrált felhasználói közül, csak azok, akik már bizonyos minőségi kritériumnak megfelelnek (helyezések, top%-os helyek száma stb.). Nagy Gábor kollégánknak sikerült elhozni egy másik versenyzővel együtt a harmadik helyet.

Ezt a versenyt a Deloitte írta ki és a megoldandó üzleti cél az ügyfelek lojalitásának megértése volt, egy biztosítótársaság ügyfeleinél kellett előrejelezni a lemorzsolódást a következő 12 hónapban a lemorzsolódás időpontjával együtt.

Hányadik lettél a versenyen?

Harmadik lettem egy amerikai versenyzővel párban.

Hányan indultak a versenyen?

37-en. Ez egy Master's Challange volt, ami azt jelenti, hogy csak a Kaggle Master státusszal rendelkező versenyzők vehettek részt rajta eleve.

Mi volt a probléma, amit meg kellett oldani?

Churn előrejelzés 12 hónapra előre. Minden hónapra meg kellett határozni a valószínűséget, hogy a szerződéshez kapcsolódó ügyfél lemorzsolódik-e vagy sem.

Miért döntöttél úgy, hogy nevezel?

Mert Master vagyok és jó volt a díj. Szeretem az osztályozós feladatokat, sok változóval.

Milyen adatelőkészítési műveleteket csináltál?

A teljes adathalmaz kb. 3.5GB volt, amit memóriában nem lehetett kezelni. Rengeteg adatelőkészítési és transzformációs trükköt bevetettem, a végső modellben 400 változó volt a kiinduló 120-hoz képest. A verseny jellege miatt erről többet nem tudok mondani.

Milyen modelleket használtál?

Gradient Boosting főleg.

Mi volt a legérdekesebb/legfontosabb/legmeglepőbb felismerés az adatokban?

Volt pár osztályváltozó, ahol nagyon magas volt a churn (>70%). Nem lehetett tudni ezek milyen szerződéseket jelölnek, mert anonimizálva voltak az adatok, ezért nem tudom pontosan, hogy mit jelölnek ezek. Voltak erős változók, amik jók voltak a tanuló adathalmazon, de rontották a végső modell eredményét az ismeretlen validációs halmazon.

Milyen eszközöket használtál?

Python-t, mint mindig :) A pandas, sklearn framework elég jól működött. A pajtásom R-ben dolgozott, ezért jól kiegészítettük egymást.

Tanulságok a verseny kapcsán?

A feature engineering jó dolog, érdemes használni. Tranzakciós adatokat érdemes pivotálni id-re és időre, hogy az időszeletkékből érdekes feature-öket generáljunk.

 

A kép forrása

5 komment

A bejegyzés trackback címe:

http://adatbanyaszat.blog.hu/api/trackback/id/tr785791550

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

Arató Bence · http://www.bi.hu 2014.02.07. 07:03:41

Nem szigorúan adatbányászati szakmai kérdés, de miért nem lehetett 3.5 GB adatot memóriában kezelni? Ez nem tűnik olyan soknak manapság, a 64 bites szoftverek és 16GB-os okostelefonok világában.

István Nagy 2014.02.07. 08:34:23

@Arató Bence: 3.5GB nyers adat beolvasása különböző eszközökben különböző memóriaterhelést jelent, nem ismerve az adatot ez mondjuk RapidMinerben 6GB környékén lesz, de még python pandasban is meg fogunk enni vele 4GB-t. Ha szeretnénk más folyamatoknak és a host oprendszernek is helyet hagyni, akkor már alsó hangon 6GB memória felett vagyunk, ami azért asztali gép környezetben legalábbis nem általános. És itt még csak a nyers adatról beszéltünk, nem volt szó arról, hogy új változókat hozunk létre, hogy két ilyen táblát összekapcsolunk stb.

Gáspár Csaba 2014.02.07. 09:54:30

@Arató Bence: Van egy dedikált szerverünk az ehhez hasonló játékokhoz, amiben 24GB memória van, ez az egyik kedvenc játszóterünk. Higgyétek el, ez nem sok 3.5GB adat zavartalan kezeléséhez, oda kell figyelni, hogy egy-egy lépést hogyan valósítunk meg. Ahogy egyre trükkösebb feature generálásba fogunk, úgy egyre gyakrabban van szükség akár ennél is több memóriaterületre - még néhány száz MB méretű kiindulási adathalmaznál is.

Arató Bence · http://www.bi.hu 2014.02.09. 19:24:24

Köszönöm a részleteket. Azont tűnödtem olvasás közben, hogy a vajon a megfelelő HW nem állt rendelkezésre, ahogy az az István által írt asztali gépen, pláne laptopon történő bányászkodáskor szokott felmerülni, vagy esetleg a szoftveres stackben volt egy 32 bites komponens, ami a korlátot jelentette.

Gáspár Csaba 2014.02.09. 21:02:43

@Arató Bence: Örülök, hogy ez a memória kérdés ekkora visszhangot váltott ki. A valóság megértéséhez a legfontosabb látni, hogyan folyik egy verseny. Fogod az adathalmazt és fogsz egy memória eszközt, és elkezdesz kipróbálni gondolatokat, ötleteket, egyszerre akár többet is. Ha a munkád negyedik napján azzal szembesülsz, hogy hopp - elfogyott a memória, az nagyon ciki, ezért inkább biztosra mész.

Nyilván a kész, kipróbált megoldást nem nehéz akár egy kisebb memóriaterületen futtatni, hiszen ott már tudod mit szeretnél, néhány GB már ekkor elég lehet. De ha eleve olyan megoldásokkal játszol, amik nem fognak a memóriával megviccelni, várhatóan messzebb jutsz. Ezeknek is van hátrányuk - lassabbak például - de itt nem gyorsan futó megoldásokra van szükség, hanem gyors fejlesztési időre, majd éjszaka dolgoznak a gépek.

Összességében tehát azzal oldunk meg egy feladatot, amivel való munka a legkisebb fejfájást fogja hozni - és ebben a döntésben jól jön, ha kivonjuk magunkat a memóriakorlátok alol. Nyilván a 64bit-32bit kérdés is tud fejtörést okozni, de nem ez a tipikus.