A 2010-ben alapított Kaggle a világ legnagyobb adatbányász közössége, 2017-re elérte a bűvös 1.000.000 regisztrációs számot. Az alapvetően adatbányászati versenyeket szervező oldalt a Google ugyanebben az évben vásárolta fel, nem titkoltan abból a célból, hogy innen vadássza le a legjobb adatelemzőket. Kaggle vitathatatlan érdeme, hogy katalizátor szerepet tölt be az adatelemzése széles körű elterjedésében. Mégis kezd valami elromlani.
Egy Kaggle adatbányászati verseny nagyjából a következő módon néz ki:
- Modellezés: a tanító adatbázison kerül sor a modellezésre, illetve az ehhez szükséges adatbázis feldolgozására, új változók előállítására.
- Tesztelés a teszt adatbázison: ezen az adatbázison kerül sor az előző lépésben épített modell kiértékelésére. A kiértékelést a versenyző azért tudja elvégezni, mert a teszt adatbázisban is benne van a célváltozó. Ha a versenyző elégedetlen a modell teljesítményével, akkor új modelleket épít a tanító adatbázison, majd ezt újra kiértékeli a teszt adatokon. Maga a modell építése tehát egy iteratív folyamat.
- Modell beadása a versenybe: ha a versenyző úgy érzi már elég jó a modell, akkor lefuttatja a modellt a kiértékelő adatbázison, és a modell eredményét felteszi a Kaggle oldalára. A versenyző ezen az adatbázison nem tudja kiértékelni a modellt, mivel a célváltozót nem tartalmazza. A Kaggle oldalra való feltöltés után, azonban automatikusan kiértékelésre kerül a modell (a verseny szervezőnek természetesen megvan a célváltozó), így a versenyző azonnal látja, hogy teljesít a modellje a kiértékelő adatbázison. Ha a versenyző nem elégedett a helyezésével, tovább folytathatja a modellezést (a tanító adatbázison).
A fenti alapelvek tiszták, és szakmailag jobbat nemigen lehet kitalálni egy adatbányászati versenyre. Azonban nem nagyon beszél senki a fenti „Kaggle elv” veszélyeiről. Hogy pontosan mit is értek ez alatt, ehhez a fenti alapelvek alapján készítettem egy minta elemzést, egy kis adatbázison Gradient Boosting modelleket építettem. Fontos megjegyezni, hogy az adatbázis mérete ténylegesen kicsi, a rekordok száma nem éri el a 10.000-et. Ezt a kis elemszámú adatbázist azonban éppen azért választottam, hogy kiemeljen a „Kaggle elv” veszélyeit. Az adatbázisról:
- Rekordok száma 8700
- Célváltozó „1” és ’0’ értéket vehet fel, az „1”-esek aránya 1%.
- Az adatbázis 6 adatkörből állt össze – minden adatkör jól elkülöníthető egymástól (független adatok)
- A teljes adatbázist felosztottam tanító és teszt adatbázisra (validációs adatbázisra nem volt szükség). Két felosztás készült: (i) tanító adatbázis 3000 rekordból állt, 5700 rekordból a teszt adatbázis, (ii) tanító adatbázis 6000 rekordból állt, 2700 rekordból a teszt adatbázis.
- Modellezés mindig a tanító adatbázison történt Pythonban GradientBoosting algoritmussal, maximális fa mélység 3-ra lett véve, csökkentve a túltanulás mértékét.
- A modelleket kiértékeltem a teszt és a tanító adatbázison is.
Nézzük az eredményeket:
A táblázatban az első 2 oszlop a 3000-es tanító adatbázison készült modellek teljesítményeit mutatja, a második 2 oszlop a 6000-es tanító adatbázison készült modellekét. A táblázatban lévő számok a modellt kiértékelő AUC függvény értékeit tartalmazza. Nagyon röviden: az AUC 0 és 1 (de inkább 0.5 és 1) közötti értéket vehet fel. Minél közelebb van az 1-hez annál jobb a modell, míg a 0.5 közeli érték gyakorlatilag használhatatlannak tekinthető. Általában elmondható, hogy a 0.75 vagy ennél nagyobb AUC értékű modellek már használhatók a gyakorlatban, a 0.85 feletti modellek elég jónak számítanak. De természetesen adatbázis függő, hogy mi számít jónak vagy rossznak. A „Kaggle-elvvel” ellentétben a modelleket kiértékeltem a tanító adatbázison is, ez látható „Train” oszlopokban.
Felhasználva a fenti táblázatot 3 dolgot emelek ki, hogy miért tartom veszélyesnek a „Kaggle-elvet”!
- Túltanulás kezelése: a tanító adatbázison a modellek teljesítményei mindig sokkal jobbak, mint a teszt adatbázison. A „Kaggle-elv” ezzel nem foglalkozik. Csak az a fontos, hogy a modell a teszt, illetve kiértékelő adatbázison minél jobban teljesítsen, az hogy a tanító adatbázison hogy teljesít a modell, az egész folyamat szempontjából érdektelen. Pedig a túltanulás egy veszélyes jelenség. Vegyünk egy példát a fenti táblázatból. Az Adatkör3-on a 3000-es tanító adatbázisnál a tanító adatbázison 0.878 az AUC érték, míg a teszt adatbázison „csak” 0.635. „Kaggle-elv” alapján tehát a modell 0.635-öt tud. De tényleg tud ennyit a modell? Ha a teljes adatbázis véletlenszerűen kettéosztott adatain ennyire különböző az eredmény, akkor van-e bármilyen jelentése a 0.635-nek? Ha lenne egy harmadik, kiértékelő adatbázis, akkor ki tudja megmondani hogy mi lesz ott az AUC érték? A túltanulás nem jó, mert ez egyben a modell instabilitást jelzi – azonban a „Kaggle-elv” a túltanulást nem bünteti.
- Tesztadatbázis kialakítása: ha egy „Data Scientist” szakértőt megkérdezünk, hogy egy modell teljesítményét mi dönti el elsősorban, akkor két dolog hangzik el szinte biztosan: (i) hogy mennyire „jók” az adatok, és (ii) hogy milyen modellező eljárást alkalmazunk (regresszió, döntési fa, …). Nyilván ezek fontosak, de azért meg van más tényező is, amivel növelhető a modell pontossága. Egy ilyen tényező, hogy a tanító, teszt és validációs adatbázist hogyan alakítjuk ki. Ilyenkor számos tényezőt kell figyelembe venni: (i) mekkora legyen ezen adatbázisok mérete, (ii) a célváltozó valamelyik értékét felül kell-e súlyozni és ha igen milyen mértékben? A Kaggle versenyek azonban készen adnak ilyen adatbázisokat (train, test) – így egy tapasztalt Kaggle versenyző számára egy marginális kérdésnek tűnhet ez a kérdés éles adatokon is.
- Elemzés elsorvadása: a modellezés látszólag egy technikai feladat. Dobáljunk össze minél több adatot, modellezzünk ezeken az adatokon, majd a modellt értékeljük ki. Ezek olyan lépések, amik jól automatizálhatók. Ha valaki profi Python vagy R programozó, akkor tud írni olyan scriptet, ami az eredeti adatokból létrehoz rengeteg származtatott változót, ezekre automatikusan tud futtatni rengeteg különböző algoritmust, az algoritmusok paraméterezése is betehető egy „for” ciklusba, és az eredményül kapott modellek közül a legjobb kiválasztása ugyancsak programozható. Nagyon gyorsan, nagyon jó modellek építhetők. A gond csak az, hogy ez nem elemzés! Az elemzés célja az üzleti életben információk kinyerése az adatokból. Ilyenkor az elemző szoftverek csak eszközök ahhoz, hogy az elemző jobban megismerje az adatokat, összefüggéseket tárjon fel, eldöntse melyek relevánsak melyek nem, és ez alapján feltárja a lehetséges ok-okozati kapcsolatokat. Azonban a Kaggle versenyek ezt az elemzői attitűdöt elsorvasztják, így nagy az esélye annak, hogy a Kaggle versenyzők később az éles adatokon is úgy tekintenek egy elemzési feladatra, mint egy programozási feladat
Ha valaki ezek után Kaggle ellenességgel vádol, az téved. Ezeken a versenyeken érdemes részt venni, a modellezés különböző lépései jól gyakorolhatók, olyan képességek fejleszthetők ki, amik éles adatok elemzésénél rendkívül hasznos lehet. Azonban fontos észben tartani a „Kaggle elv” veszélyeit, ha valóban adatelemzők szeretnénk válni.