És akkor pár szó a LIFT-ről...

.
...ha már benne van ennek a blognak a nevében. :o)

Kerestem egy elemi és egyúttal minél teljesebb összefoglalót a tárgybeli - adatbányászatilag - kulcsfontosságú témában, ha már ez a blog is ezt helyezi fókuszba a blognév választásával, ugye. :o) Nemhogy magyarul, de még angolul sem találtam. Persze lehet ám, hogy ez az én saram ;)

Mivel hosszú és fárasztó a téma, én meg nem a rövid blogposztokról vagyok híres ;), kezdjük távolról és lazábban a témát:

Az angol nyelvterületen 15.század óta létezik a LIFT szó, vélhetőleg onnan került át változatlan formában magyar nyelvterületre is.

Ahelyett, hogy (erölködve) magyaráznám köznapi jelentését, vagy netről linket keresnék az értelmezésére; a ma használatos (és nekünk tárgyunk szempontjából izgalmas) értelmére mutatnék inkább pár viccet:

Az elképzelhetetlenül részeg és borzalmasan mocskosszájú Józsi bácsi megy hazafelé.
Belép a lépcsőházba, beszáll a liftbe, azonban a lift leszakad.
Az öreg össze-vissza töri magát, felugrik és elkezdi rugdosni a liftet, közben üvölt:
- B*zmeg! Azt mondtam, hogy a harmadikra!!!

- Te Józsi, van egy jó meg egy rossz hírem. Melyiket mondjam előbb?
- Na, mondd a jót!
- Már a kilencediken vagyunk.
- És mi a rossz?
- Az, hogy a másik házba kellett volna felvinni a zongorát.

- Milyen az arab lift?
- Megnyomsz egy gombot....és jön az emelet.


Azaz a LIFT köznapi jelentése alapján: energia befektésével, valamilyen téren akarunk "feltornászni" valamit ("nyerészkedés" jelleggel).

Adatbányászatban két fontos területen/módszerben is használják (minimum: lehet hogy több helyen is, de most éppen elég lesz a két legfontosabbra fókuszálni).
(1) Asszociációs szabályok
(2) Osztályozás, azon belül előrejelzés.
A gyakorlatban az utóbbi a hangsúlyosabb, izgalmasabb, viszont ABC-rend illetve könnyebbség szerint ez a helyes rendezettség, szvsz, ezért tehát ebben a sorrendben is tárgyalnám a következőkben :o)

Mindkét területen fel kell "tornászni", emelni valamit. (1)-nél érdekességet, (2)-nél hatékonyságot, minőséget.


I. Asszociációs szabályok:

A klasszikus példa szerint adott 5 db TESCÓ-s vásárlás(i kosár/tranzakció).
(1) tej, kenyér, sör, tojás
(2) kenyér, pelenka, tojás sör
(3) tej, kenyér
(4) tej, pelenka, szalonna, sör
(5) tej, kenyér, pelenka, sör

1.fogalom: frequency(~gyakoriság):
Hasonlóan a valószínűségszámításban tanultakhoz, adott elem gyakorisága, előfordulásának száma osztva az összes (tranzakció) számmal. Ez a hányados egyúttal az adott elem előfordulási valószínűsége is tehát.

Gyakoriság(X) = előfordulás_db / összes_db

Ami nóvum, hogy a különböző gyakoriságok közül minket a nagyobb gyakoriság jobban érdekel, következésképpen húzunk egy határt, küszöbértéket (=treshold), aminél kisebb gyakoriság már nem érdekel minket. Legyen ez min_gyak!

Példánkban tej, kenyér, pelenka, tojás, szalonna, sör elemek vannak. A pelenka-sör kombináció 3-szor fordul elő az összes 5 db tranzakcióból. Gyakorisága tehát: 0.6

2.fogalom: support(~bizonyosság)
A gyakoriság nem képes az elemek közti kapcsolat értelmesebb ábrázolására, ezért van szükségünk erre az új fogalomra. Asszociációs szabálynak (két elem esetén) az X=>Y implikációt nevezzük. Asszociációs szabályok adatbázisból való kinyerésekor arra keressük a választ, hogy a tranazkciók hány százaléka tartalmazza Y-t, ha X-et is tartalmazza.

Bizonyosság(X=>Y) = gyakoriság(X+Y) / gyakoriság (X)

Ennek valószínűségszámítási analógiája a P(Y|X) feltételes valószínűség.

Példánkban: bizonyosság(pelenka=>sör)=gyakoriság(pelenka+sör)/gyakoriság(pelenka)=0.75

A gyakorisághoz hasonlóan a bizonyosságnál is a minél nagyobb bizonyosság az érdekes számunkra, következésképpen itt is húzunk egy alsó küszöbértéket, aminél kisebb bizonyosság nem érdekel már minket. Legyen ez min_biz!

Egy asszociációs szabályt akkor tekintünk érvényesnek, ha min_gyak feletti a gyajkorisága és min_biz feletti a bizonyossága.

3.fogalom: lift(~érdekesség).
Az érvényes asszociációs szabályok egyrészt nagyon sokan lehetnek az elemek számának növekedésével, másrészt nem egyformán érdekesek.

Klasszikus példa szerint 500 ember kávé- és teafogyasztását vizsgálták meg, azt keresve, hogy a tea fogyasztása mennyire befolyásolja a kávé fogyasztását.
Legyen min_gyak=0.1, min_biz=0.7! 
Teát az emberek 20%-a ivott, kávét 80%-uk, mindkettőt 15%-uk.
A gyakoriság(tea): 20%, azaz 0.2
A bizonyosság(tea=>kávé): 15/20=0.75
Mivel teát 20% iszik (=0.2 gyakoriság), ami nagyobb a min_gyak-nál (0.1)
Mivel a bizonyosság(tea=>kávé)=0.75, ami nagyobb a min_biz-nél (0.7).
Tehát az asszociációs szabály(tea=>kávé) érvényes szabály.

A nagy kérdés az az, hogy ez az érvényes asszociációs szabály érdekes is-e egyúttal?

Az emberek 80%-a iszik kávét, vagyis a tea fogyasztása valójában csökkenti a kávé fogyasztását nem növeli, ami nekünk ugye jó lenne. A kávéfogyasztás növelését nem tudjuk elérni teafogyasztás növelésével. Következésképpen a tea=>kávé asszociációs szabály félrevezető.

Ha a min_gyak, min_biz küszöböket
- alacsonyra állítjuk, akkor sok érvényes, de kevés érdekes asszociációs szabályhoz jutunk.
- magasra álíltjuk, akkor viszont érdekes asszociációs szabályokat dobálhatunk ki.

Az érdekességnek, mint mutatónak, létezik megközelítésileg
(1) szubjektív
(2) tárgyilagos
verziói. A szubjektívvel értelemszerűen most nem foglalkozunk.

A tárgyilagos érdekességmutatók legegyszerűbbike és legérdekesebbje az inkriminált LIFT.
Lift(X=>Y) = bizonyosság(X=>Y) / gyakoriság (Y)

Példánkban: Lift(tea=>kávé) = bizonyosság(tea=>kávé) / gyakoriság (kávé) = 0.75/0.8.
Azonnal látszik, hogy 1 alá csökkent a hányados, ami nekünk nem jó ("üldözendő).

Zárásként ami még érdekes, egy asszociációs szabály feltételét és következményét egymástól függetlennek tekintjük, ha a LIFT=1.
Ekkor: gyakoriság(X+Y) = gyakoriság(X) * gyakoriság(Y)
Végül ekkor: P(X,Y) = P(X) * P(Y)
Ami két esemény függetlensége, amit jól megtanultunk annó valószínűségszámítás órán.
:o)


II. Osztályozás (azon belül előrejelzés):

Minden előrejelzés osztályozási feladat is egyúttal (halmazelméleti értelemben). Az hogy valami bekövetkezik vagy nem, az bináris osztályozás távolabbról szemlélve. (Most nem ideértve az idősorok előrejelzését, mert az tök más dolog: az angol terminológia élesen megkülönbözteti a kettőt, az előbbi a prediction, az utóbbi a forecasting)

Klasszikus üzleti életben gyakran előforduló előrejelzési feladat:
- Churn(~elvándorlás), egy adott ügyfél otthagyja-e vagy sem például az internetszolgáltatóját, biztosítóját, bankját, stb.
- Response rate (~válaszolási arány)) például direkt marketing termékajánlati levél nyomán érdeklődik-e vagy sem az ügyfél a vállalatunknál a termékajánlat témájában.

Egy ilyen feladatban tudjuk az összes rekord számot (N)
Tudjuk, hogy eddig hányan vándoroltak el (churnöltek) például: (K)
Random mintavételezésnél: K/N relatív gyakorisággal találunk churnölőt.
Praktikusan nézve az összes N db ügyfelet "megdolgozva" tudunk foglalkozni összes K darab churnölővel.

A cél az lenne, hogy nagyságrendileg kevesebb (<<N) rekorddal dolgozva (valószínűség szerint csökkenősorrendbe rakva őket, a legvalószínűbbekkel "TOP N" foglalkozva), tudjunk foglalkozni minél több churnölővel. Az elérhetetlen ideális lenne persze, hogy K darab ügyfelet kiválasztva, a halmaz lefedné az összes K darab churnölő ügyfelet.:o)

Másképp fogalmazva a cél az lenne, hogy a random relatív gyakoriságot mindenféle okos (adatbányászati módszerekkel) meg tudjuk növelni.

Például, ha van 10 db ügyfelünk, akikből 2 churnöl, akkor mondjuk 10% (=1 db ügyfél) "kézbevétele" után lehetőleg azonnal találjunk/tántorítsuk el churnölő szándékától legalább 1 db churnölőt. Azaz 2/10=0.2 relatív gyakoriság helyett dolgozzunk mondjuk 100%-os (ötszörözött) hatékonysággal.

Na erről szól az osztályozásban/előrejelzésben a LIFT.

Csináltam egy végtelenül leegyszerűsített (túlbutított?) demót a szemléletéshez, Clementine-nal
Van a S(=source=magyarázó, prediktor) mező és van a T(=target, cél) mező.
10 rekordot vettem fel. Akikből ketten churnölnek.
Logisztikus regresszióval modelleztem
Az egyszerűsítés jegyében saját magára mértem vissza az adathalmazt (ilyet ugye tudjuk, hogy nem szabad csinálni a való életben).
A két churnölőt 1-es valószínűséggel egy churnölőt tévesen, de csak 0.875-ös valószínűséggel találtam meg a modellezés során.

Összefoglalva:
True Positive: 2 db
True Negatíve: 7 db
False Positive: 1 db
False Negatíve: 0 db
Mindösszesen: 10 db.

Képlet:
Ahol
p a valószínűség szerint csökkenőbe rendezett felső (=TOP) mondjuk k=5-10-20-30% rekordban talált valószínűség
h(=hit, azaz találat), adott előfordulásra volt-e találat (1) vagy nem (0)

LIFT-kiértékelés (churnarány görbe)
20%-nál
Számlálóban: tehát kettő jó találat van (1-es valószínűséggel) a háromból(=0.6666)
Nevezőben: 2 churnölő van a 10 ügyfél közül (=0.2)
0.6666/0.2=0.3333=3.3-as LIFT
Feltéve, hogy jól számoltam. ;)

GAINS-kiértékelés, True Positive Rate (koncentrációs görbe)
Mivel 2 jó találat van (1-es valószínűséggel) 3-ból, ezért 66% a "csúcs-ugrás", már úgy értve, hogy a legkevesebből.

RESPONSE-kiértékelés
TOP 20%-ban a 100%-nyi churnölőt találtunk.

PROFIT-kiértékelés
TOP 20%-ban a 100%-nyi churnölőt találtunk, TOP10%-ban csak fele annyit.

ROI-kiértékelés (Return of Investment)
100% kiértékelése után az 1 révedés miatt 33%-nyi veszteségünk volt.

Ott tartunk tehát, hogy 20%-nyi churnölőnél:
- az "elérhetetlen" elméleti maximum LIFT az 5(=1/5 reciproka)
- mi nem kis csalással elértünk 3.3-as LIFT-et, 20%-nál.

Összefoglalva, ami fontos az osztályozós/predikciós LIFT-nél:
-A LIFT egy metrika, másképp szólva - esetünkben osztályozás/prediktálós típusú - adatbányászati modellezés minőség(biztosítás)i mutatója.
-Bináris célváltozó kell, azaz churn, response, etc. (elvándorol, nem vándorol – válaszol, nem válaszol – stb.). A multinomiális osztályozás könnyedén visszavezethető bináris esetre (adott osztálynak tagja-e vagy sem).
-A nevezőben a véletlen kiválasztás relatív gyakorisága k/n, vagyis k db churn osztva n db összes rekorddal.
-A számlálóban van a top x darab rekord, ahol jóval többet kell találni mint véletlen mintavételezésnél.
-Így jön ki hogy hányszoros a lift a véletlenes mintavételezéshez képest.


LIFT FAQ/GYÍK

Miért preferálja az üzleti élet a LIFT-mutatót, szemben a matematikusok, adatbányász verseny kiírók - például - AUC-ával szemben (=Area Under Curve, görbe alatti terület)?

Nekem erre két észrevételem van. Egy rosszmájú ;) és egy jóindulatú.

(1) Egy marketinges mindig jobban szereti azt mondani, hogy mondjuk kétszer akkora a hatékonyságnövelés, mint azt, hogy 10%-kal több. Egész egyszerűen jobban hangzik. ;)

(2) A matematikusban fel sem merül, hogy az összes vizsgált (akár milliós darabszámú) rekordot "kézbevegye", hacsak nem mazoista. Az üzleti életben meg pont azon van a fókusz, hogy például az ügyfelekkel foglalkozni kell. Na most, ha mindenkivel nem is lehet a gigantikus mennyiség okán, akkor legalább fontossági sorrendet érdemes felállítani köztük (minél kevesebből minél nagyobb eredményt elérni).



Hányszoros LIFT-et szeret az üzleti megrendelő, aminél elégedett? Minimálisan mennyi az elfogadható LIFT, amiért már ki is fizetik a beszállítót?

Az elméleti LIFT elérése a vágyak kategóriája. 2-szeres LIFT elérését már ki szokták fizetni tapasztalat szerint Magyarországon. Ha ennél (jóval) kisebb a LIFT, akkor az a mondás, hogy nincs elég magyarázó erő az elvégzett adatbányászati modellezésben. Aminek oka lehet az adatok belső összefüggéseiben (például DQM=adatminőségi), de lehet ok az elégtelen modellezés is. Mindez vezethet "érdekes" beszélgetésekhez üzleti megrendelő és adatbányászos beszállító között. ;)

Kérdés: van-e erről a 2-szeres elfogadható minimum LIFT-ről érdemi referencia a neten, hogy ne "bemondásra" kelljen elfogadni?! Próbáltam keresni ilyen hivatalos referenciát is a minimálisan elfogadható LIFT-re, de nem igazán jártam sikerrel. Még ez a legelfogadhatóbb, ahol a példában 1.875-ös LIFT-et adnak meg, ami még az általam említett 2-nél is kevesebb, azaz én "szigorúbb" voltam. ;)


Triviális (elméleti) LIFT-növelés?!

Üzleti életben egy "churn" távolról sem triviális fogalom. Nem mindegy, hogy kit tekintünk pontosan, egzaktan, teljeskörű konszenzus mentén, churnölő ügyfélnek. Egyáltalán hogyan képződik le pontosan az üzleti fogalom a churn-mező mappelése során.

Az fixálható felső határként, hogy a teljes halmaz maximum fele lehet churnölő. Ha több, akkor azt érdemes előrejelezni, hogy ki marad. :o) Alsó határként meg az lenne az ideális, hogy akkora legyen a beazonosított churnölő ügyfélkör amekkorával van kapacitás foglalkozni vállalaton belül.

Emiatt aztán előfordulhat egy érdekes mellékhatás, nevezetesen az adatbányászati modellezés során kisebb lesz a teljes részhalmazon belül a churnölők részhalmaza. Ez aztán automatikusan megnöveli tehát az elérhető elméleti LIFT-maximumot, és gyakorlati értelemben is könnyebb lehet magasabb (és látványosabb) LIFT-et elérni.

Magam részéről hangsúlyozni szoktam, hogy a fenti mellékhatás az tényleg csak mellékhatás, nem pedig klasszikus optimalizálási cél, churn-rekordszám csökkentése vonatkozásában. A mellékhatás eröltetett fókuszba helyezése nem lehet kívánatos cél, bármennyire csábító. Modell-jóságra kell törekedni, nem pedig adott esetben hamis látványra.


Lehet-e a modellezés tényleges elvégzése elött valahogy "előreszámolni" a LIFT-et?

Sajnos jelen tudásom/tudásunk szerint (?), előre megrendelési, tendereztetési fázisban még csak közelítőleg sem lehet érdemi véleményt arról mondani, hogy mennyi idő- és energiaráfordítással, mennyi az elérhető LIFT.

Ha tehát például 10-szeres az elméleti maximum LIFT és a 2-szeres LIFT-et már elfogadottnak tekintjük, akkor mondhatjuk, hogy 2-10-szeres LIFT-pálya, sikeres adatbányászati modellezésnél. Ilyet azonban eléggé veszélyes mondani, mert az üzleti megrendelő lelki szemei elött megjelenik,hogy akkor majd 9-9.5-szeres LIFT-et megcélozzuk. Holott a gyakorlat szerint nagyon sokszor örülni kell a 2-3-szoros LIFT-nek is, abban is lehet óriási pénzügyi profit-potenciál.


Mi van a "kedvenc" NULL-unkkal? 

A prediktálás során a célváltozó felveheti ugye a köztudott 0,1 értékeket, de lehet NULL is. RDBMS-világban a NULL nem érték, hanem - undefinit - állapot. Hogyan befolyásolja ez a NULL-ozás túlózás a LIFT-számolást? Ennek kifejtését meghagynám másoknak. Én beérem ebben a pillanatban egy kardinális állítással, aminek bizonyítását mindenkinek magának kell megejtenie:

Jó modellezés nem vezethet NULL célváltozóhoz, egyetlen rekordnál sem.

Tessék jól adatbányászkodni és akkor nincs probléma NULL-ok miatti LIFT-számolással!

Mindezt azért mondom, mert nekem például sikerült már beleszaladnom a problematikába, nem kis fejfájást okozva. ;)