Mi predesztinál sikerre egy adatbányászprojektet?

.
Szakmai társblogon olvastam az imént a tárgybeli témában egy friss posztot.

A 7.sikerkritérium

"Egy népszerű ökölszabály alapján egy jó adatbányászati projektnek hat sikerkritériuma van: legyen
(1) sok sorból álló
(2) attribútumokban gazdag adathalmazunk, melyben legyenek az adatok egyrészt
(3) tiszták, másrészt
(4) jól reprezentálják a prediktív modellekben körüljárt eseményt. Ezen túlmenően fontos, hogy a projektre
(5) jól mérhető legyen a ROI, illetve a vállalati környezet olyan legyen, hogy a kapott eredmények alapján a menedzsment ténylegesen változtathasson a korábbi folyamatokon, azaz
(6) akcióképes legyen a vizsgált tématerület.
(7) rövid válaszidő"

A téma nagyon jó (a hét mesterlövészre utalás különösen szellemes telitalálat), a poszt helyből és azonnal hozzászólásra inspirált, plusz van akkora fontossága/jelentősége a kiinduló felvetésnek, hogy "replikáljam" ide is. Pláne, hogy egy blogposztban nem lehet mindent és teljeskörűen leírni, biztos lehet kiegészítéseket tenni egyéni megfontolásokból... ;)

* Én például jobban szoktam vágyni kevesebb, de nagyobb magyarázó erővel bíró attribútum(kombináci)okra. Az KDD-s Orange-verseny is rámutatott, hogy nagyon gyorsan el tudnak szabadulni a potenciális magyarázó-változók.

* Bár jóféle technikák vannak kezelésükre, mégis alapból hálás tud lenni, ha (1) kitöltöttek ("missing value"-mentesség) valamint (2) minél inkább mentesek a kiugró értékektől (outlier)az attribútumok. A nagyobb/jobb kitöltöttségért olykor nagyon meg kellhet küzdeni, az én tapasztalatom szerint

* Nagy öröm volt olvasni a "jól mérhető ROI"-ról. Részint mert nincs triviálisan a köztudatban (szerintem) a dolog nehézsége, másrészt az adatbányász komfortérzetét is nagyban javítja a korrekt mérés/visszamérés lehetősége.

* Az akcióképesség ilyetén hangsúlyozása engem elsőre megdöbbentett. Értem persze a felvetés jogosságát (amúgy se jó sose az öncélú l'art pour l'art játszadozás, nemcsak az adatbányászatban), de azért felveti a kérdést (pláne az eggyel korábbi "börtönfenyegetettséges" blogposztommal összhangban), hogy meddig terjed az adatbányász hatóköre. Számomra sokkal fontosabb idevágóan az adatbányász(-projekt) hitelessége, meg ennek hangsúlyozása, aminek alapján a menedzsment megbízik az eléje tálalt infókban majd dönt a további lépések mikéntjéről, másfelöl, hogy ne vállalati klikkharcok martaléka legyen egy értékes adatbányászati elemzés, azaz legyen motiváció a menedzsmentben az objektív mérlegelésre .

* Nagyon hasznos felvetés volt az eredeti blogposztban a "feketedoboz-effektus" mérlegelése. Én azt a példát hoznám, hogy a potenciális - kézzel leellenőrízendő - csalók listájára pénzügyi szektorban is el tudok képzelni feketedoboz-os adatbányász algoritmust, a minél teljesebbkörű azonosítás érdekében és valóban ügyfél-szegmentációra vagy guide-technológia esetén sokkal kevésbé "adható el" a feketedoboz.

* A legérdekesebb viszont kétségtelenül a poszt-címadó 7.sikerkritérium. ;)

- Így első belegondolásra és nagy százalékban a válaszidő és a pontosság többnyire egymás kárára tuningolható leginkább. Magyarán létezhet "optimum" a két szempontra.

- Van egy harmadik aspektusa a rövid válaszidőnek méghozzá a skálázhatóság. Ugyanis a gyakorlat az az, hogy úgy nőnek az adatok (az "égig"), hogy a már egyszer implementált megszokott válaszidőket implicite el is várjuk. Azaz durva példával élve kétszer akkora adattömegre elég legyen még egy gépet beállítani, hogy minden funkcionalitás tudjon a régi válaszidőkkel menni.
Tipikus példa lehet egy Netflix (rohamosan növekvő ügyfél- és filmbázissal).

- Én ha választhatok jobban szeretem a pontosságot választani, mint a rövidebb válaszidőt, de el kell fogadni, hogy az "idő pénz". De ekkor is felhasználóként / ügyfélként szeretném látni, hogy a rövidebb válaszidő tényleg nagyobb profitot hoz (nem öncélú a rövidebb válaszidő a "látványért" magáért)

Update

Az eredeti blogposztot író Gáspár-Papanek Csaba kommentje:
Lehet, hogy nem írtam le teljesen egyértelműen, a válaszidő alatt nem a modellezés futási idejét értem, hanem azt, hogy egy modell való életben történő használatáról milyen hamar kap visszajelzést maga a megrendelő. Szóval ez nem az adatbányászati folyamat belsejében megjelenő technikák, hanem magának a feladatnak a tulajdonsága.

Tényleg nem akartam végtelen hosszú blogbejegyzést írni, ezért talán nem is emeltem ki eléggé, hogy itt a sikerkritériumoka valójában a környezetről szólnak: mikor lesz sikeres egy adatbányászati projekt, milyen feladatok alkalmasak arra, hogy sikeres projektet csináljunk belőlük.

Nyilván nagyobb az esély a sikerre, ha hamarabb jelentkezik a(z) (esélyes) pozitív visszajelzés.
Talán idevág a fociból vett analógia, hogy az edzők 2-3 évre szeretnek tervezni úgymond csapatot építeni, de elég lehet 1-2 vereeég a bajnokságban, hogy aztán mégis iziben repüljön az edző.
Valóban nehéz egyeztetni a folyamatos azonali sikeréhséget a hosszabbtávú stratégiai tervszerűséggel. 

Prediktálás börtönfenyegetettség árnyékában?

.
Új minőség az adatbányászat horizontján?

Nem jósolták meg a földrengést, perlik őket

"Hét olasz tudós és szakértő ellen gondatlanságból elkövetett emberölés miatt emeltek vádat szerdán, mert nem figyelmeztettek a háromszáz halálos áldozatot követelő 2009-es földrengésre. A védelem visszautasítja a vádat, mondván, lehetetlenség megjósolni a földrengéseket."

Azért ez felvethet pár érdekes kérdést még laikusokban is.

(1) Ilyen megbízhatóak mára az adatbányász/prediktálási protokollok, hogy börtönnel is számonkérhetők?

(2) Attól még hogy
(a) egy ember
(b) magas százalékos valószínűséggel
lát egy bekövetkező földrengést onnan még nem hosszú az út egy "kicsit"?
(Hogy szakmai konszenzus legyen, továbbá a döntéshozók is megfelelő lépések útjára lépjenek)

Nekem analógiaként a 2008-as pénzügyi válság jut eszembe. Egészen biztosan voltak kockázatelemzők, akik látták akkor is a bajt elemzéseik konklúziójaként, a válság mégis nagyon durván ráomlott az USÁ-ra, meg aztán a világra.

Adatbányászat és etika témához meg egy újabb érdekes adalék lehet a sztori: az én érzékelésemben nagyon hosszúnak látszik még az út, amikor az adatbányászaton kívüli közvéleményben kialakul a helyes arányérzék: mit lehet várni az adatbányászattól, milyen követelmények/elvárások a reálisak. Pro és kontra.


UPDATE-1

Befutott egy érdekes és inspiráló komment, köszönet érte. :o)

* Nem tudom, ezek az előrejelzések mennyiben adatbányász feladatok?
* A konkrét eset sem teljesen egyértelmű. Ugyanis azt írja, hogy voltak akkoriban kisebb rengések, és abból talán tudtak volna következtetni... Persze itt felmerül, hogy minden ilyen esetben ezentúl kilakoltatják a települést, és nem jön be az előrejelzés, akkor egy idő után hiteltelenné válhat, és már maga a lakosság lenne, akik nem hinnének...
* meg aztán ahogy olvasom, őket ezért fizették :))) "nagy veszélyek bizottsága" :)))
* Ami ennek kapcsán még az eszembe jutott, nálunk az árvízveszély. Épp nemrégiben olvastam, hogy itthon is akarnak valami katasztrófavédelmi tanfolyamot, amin kötelező lenne a részvétel az állampolgároknak, és azt tanítanák, hogyan kell szervezkedni árvíz esetén....

Én úgy gondolom, hogy ami nagy tömegű és/vagy historikus adatokon alapuló, matematikai algoritmusokkal kiszámolt előrejelzés az minden esetben adatbányászfeladat: nevében is benne van, nagy adattömegből kell kibányászni értékes kevés ("lesz-e földrengés: igen/nem") információt.

Az adatbányászatnak van tárgy-(domain-), jelenesetben geológusi/szeizmológusi-, függése. Amihez én nem értek. Rögtön nem tudnék például arra a kérdésre válaszolni, hogy a földrengés-előrejelzés analóg-e az időjárás előrejelzéssel a tekintetben, hogy minél közelebbi időpontra történik az előrejelzés, annál pontosabb. Időjárásnál így van tudtommal, földrengésnél egyáltalán nem biztos. A hírek szerint a minapi japán földrengés-előrejelzés is vetett fel komoly szakmai kérdéseket.

Így van ahogy mondod, a nagy kérdés az az, hogy egy előrejelzés, milyen alapon / implikációk révén, milyen tevékenységláncolatot indítson be. Az előrejelzés információtömege elért-e kellő kritikus tömeget, mekkora hordereje van a tevékenységláncolatnak stb. (adott esetben lehet "farkast kiáltani" sokszor, ahogy esernyő is sokszor van nálunk, miközben süt a nap, mert nincs nagy rezsije. Míg a pénzügyi válság elkerüléséhez olyan döntés- és tevékenységsorozatra lett volna szükség, amire esélytelen volt az emberiség)

Az idevágó paradoxont én úgy szoktam megfogalmazni, hogy nem elég előrejelezni, az előrejelzést alá kell tudni támasztani, hitelt kell tudni neki adni, akkor ér valamit. Az hogy az éterbe millióan beleböfögnek valamit és aztán mindig valakinek/másnak igaza van (kitalálhatatlanul); egy adott (teszemazt közgazdasági) előrejelzési kérdésben, ez így ebben a formában használhatatlan zaj.

A dolgot megfordítva: ha egy előrejelzőt "fizetnek", akkor börtönnel kell jótállnia az előrejelzéseiért?

Deja vu, nagyon fontos, ráadásul hazai analógia a tárgyban, amit ennek a fenti kommentnek köszönhetek.  amikor volt a pár évvel ezelötti (szél)viharos, fakidöntéses tüzijáték, emberhalállal (Budapesten).

Kit akartak felelősségre vonni? A meteorológiai előrejelzőt, avagy a politikust, aki engedte a tüzijátékot?Meddig terjed az előrejelző felelőssége? Előrejelzés pontosságáig? Döntéshozó meggyőzéséig? Egy érdekes idevágó gondolatmenet a témában, jogi szemszögből:

A budapesti tűzijáték tragédia és a vezetői felelősség kérdése


Az árvízvédelem, védekező mechanizmusainak lépései fontosak valóban a tárgyunk szempontjából is. "Milyen előrejelzés alapján, mi történjen?"

Beszéd, mint a sikeres párkapcsolat prediktora?

.
Sikerült egy "igazgyöngyöt" találnom a hatalmas indexes napi forgatagban, mondhatni "zajban". :o)

Mire nem jó (még) a (szöveg)bányászat. :o) Ha már itt a blogon oly hangsúlyos volt többször is a szerelem meg társkeresés jövőjének fürkészése, nemcsak és főleg nem teoretice, hanem konkrét egyedi párkapcsolatok vonatkozásában, matematikai/numerátori alapokon, akkor röviden szót ejtek erről is.

A beszédstílus a jó párkapcsolat alapja

Az érintettek beszédmódja alapján nagy biztonsággal megjósolható egy párkapcsolat jövője, állítják az új módszert kidolgozó pszichológusok.

Azok a párok, akiknek beszédje szinkronban van, négyszer nagyobb valószínűséggel szeretnének máskor is találkozni, mint azok, akik nem egy nyelvet beszéltek, derült ki a Texasi Egyetemen diákok bevonásával végzett vizsgálatból. A kutatók a szavak mondatokká fűzéséhez nélkülözhetetlen funkcionális szavakra koncentráltak.

A kutatás első fázisában 40 pár gyors, mindössze négyperces randevút bonyolított le, és beszélgetésüket rögzítették. A második fázisban már rendszeresen találkozgató párok hétköznapi beszélgetéseit és üzenetváltásait vizsgálták 10 napon át, és a kutatók arra a következtetésre jutottak, hogy a beszédmodor és az írás stílusa jó indikátor lehet arra nézve, hogy sikeres lesz-e vagy sem egy kapcsolat.

A dolgot ugye nem tudom leellenőrizni, maximum csak fejben végiggondolni.  És részben pozitív gondolkodásomból fakadóan, részben tapasztalatom alapján azt kell mondjam: erősen el tudom képzelni, mint reális lehetőséget.

* A kutatásnak értelme is van, lásd csökkenő házasodási és gyerekvállalási kedv (fejlett nyugaton).

* Nem "brittudósi" hülyeség, már első olvasatban sem. Például mert egybevág a józan paraszti ész tapasztalatával.

* Ha én állítanék fel csapatot társkeresési honlap alapításához, én is nagyon támaszkodnék pszichológusokra. Már az óriási segítség lehet, hogy mik lehetnek a releváns felteendő kérdések.

* Négyszeres szorzó az már nagyon komolyan hangzik (ha valós). Ez előrevetíti minden adatbányász örök álmát, a talált prediktor erős magyarázóerejét.

* A említett indikátor tipikusan nem az a prediktor, amit az emberek oly könnyen befolyásolni tudnak. De még ha igen, akkor sem látszik, hogy milyen irány lenne jó stratégiailag/taktikailag. Azaz a prediktor eléggé ígéretes módon őszintének tűnik, mint a hormonok is, dr. Helen Fishernél, nehéz vele hazudni. ;) Ez az én olvasatomban talán a legkritikusabb pont, bármiféle algoritmusokkal támogatott társkeresésnél.

* Egy dolog látszik csak problémásnak számomra: hogy lehet számokkal mérhetővé tenni a beszédmodort.

Társkeresés és adatbányászat témát érintő blogpostjaim:
Társkeresés adatbányász alapokon
Társkeresés - Numerátorok
Dr. Helen Fisher mint a szerelem "brittudósa"?
Dr. Helen Fisher kérdőíve társkereséshez
Dr. Helen Fisher - Zárszó
Társkeresés adatbányászati támogatással
Beszéd, mint a sikeres párkapcsolat prediktora?
COMMENT:COM: "Házasság első látásra"

Egy SQL-verseny elvi és gyakorlati problémái

.
Ha valaki rákeres SQL kulcsszóval milyen állásokat hirdetnek ilyen tárgyú site-okon (Profession, Jobmonitor, stb.), akkor bármely, akár "punnyadásos", időpillanatban is egyfelöl jó eséllyel fog találni több nyitott poziciót, másfelöl könnyen valószínűsítheti, hogy "trendi" és ígéretes szakma általános követelménye, aminek következtében, megint csak könnyen valószínűsíthetően, jó sok jelölt pályázhat meg egy-egy állást, ahol SQL-lel kell dolgozni.

Ilyen esetekben munkáltató oldalról felmerül az (1) alkalmasság(előszűrés) illetve a (2) legjobb jelölt (versenyszerű) kiválasztásának triviális igénye. Kérdés van-e - és ha igen, akkor mennyire jó - módszertan ilyen jellegű kérdések megválaszolására? Könnyű-e annyira az SQL-tudás mérése, mint a nyelvtudásé (ahol pár perc diskurzus után megbízhatóan érzékelhető, ki mennyire jó nyelvből -> feltéve persze, hogy a munkaadó bír releváns nyelvtudással, ugye).

Nyelvtudás témájából is blogposzt-hegyeket lehetne írni (itt egy friss aktuális példa: Miért kérnek idegen nyelveket?), de most fókuszáljunk csak az SQL-tudásra és mérésére.

Első nehézség, mik a legfontosabb ismérvei egy jó SQL-esnek. Biztosan vitatható lesz amit mondok, én úgy vélem, hogy az alábbi öt dolog:

(1) Megbízhatóság, hogy egy megírt SQL-parancs tényleg azt csinálja, amit a fejlesztője akart. Komoly, aggregált, nagy futási idejű SQL-lekérdezést nem nagyon lehet sokszor futtatni (adott esetben még egy rossz futást lelőni is probléma lehet), és debugolni sem olyan könnyű, mint egy 3GL kódot.A dolog hatványozottan fontos tud lenni meglévő kódok módosítása esetén. Egy-egy rontáson nagyon sok múlhat, miközben a tesztelési költségek behatároltak, pláne nagyon nagy adatbázisoknál.

(2) Gyorsaság: ki kell tudni használni a deklaratív programozás fejlesztési előnyeit.Pláne figyelembevéve az RDBMS-ek magas alap és támogatási bekerülési költségeit, amik az SQL fejlesztési és végrehajtási előnyeit biztosítják.

(3) Komplex - például inline view-s - sql-ek olvasási, írási és módosítási készsége

(4) Logikai műveletek minél hibamentesebb értelmezése. Magam részéről nem pártolom az összetett logikai kifejezések eröltetését, a hibázási valószínűség robbanásszerű növekedésének lehetősége miatt, de ettől még mások preferálhatják és olvasni kell tudni az ő SQL-jeiket.

(5) Képes legyen kölcsönös kétirányú leképezésre/változtatásra (agyban) a fejlesztő, az SQL és a resultset között. Elismerem ez így nagyon homályos és képlékeny, ha analógiát akarnék keresni, akkor valami olyasmire gondolok, hogy a programozó sem soronként "nulláról" ír programkódot illetve képesnek kell lennie a gép "fejével" gondolkodnia. SQL-nél "kevesebb" karakter kell ugyan a kódoláshoz, viszont a resultset "elképzelése" szerintem nélkülözhetetlen követelmény, a hatékony SQL-parancs megfogalmazásához (sőt mindezt végrehajtási aspektusokkal vegyítve)

Magam részéről - egészen a mai napig - úgy gondoltam, hogy, ha nekem kéne valaki jó SQL-est kiválasztanom több emberből, akkor én például a magyar nyelvű szakmai SQL-levlistáról választanék egy-egy problémát és arról beszélgetnék a jelöltekkel. (Ezt előzetesen jelezném is feléjük.) A kiválasztott probléma lehet elméleti is, gyakorlat is (hibakeresés, sql-módosítás, resultsetes sql elemzés, stb.)


Ily módon, 

(1) legalább valamennyire "zárt" a tudásbázis (még ha zajos is).

(2) de kellően "nyitott" is (hiszen régóta van sokezer hozzászólás, feladat, és így nehéz - végeredményt befolyásolóan - célraorientáltan készülni)

(3) aki a levlistán van (erőforrást fektet olvasásába/írásába), annak legyen ennyi "természetes" előnye

(4) a jelölteket felmérő is "(meg)dolgozik", hiszen közreműködik a kiválasztásban: persze nézőpont kérdése, hogy ez mennyire előny -> az én szememben az.

(5) végeredmény konvergálhat a kiválasztás jóságához, például azzal is, hogy a való életből választódik probléma.


Na, de mi a helyzet, ha

(1) több tíz potenciális jelentkezőre kéne minél megbízhatóbban sorrendet alkotni

(2) papír-ceruza alapon kéne dolgozni

(3) nem klasszikus alkalmassági-/vizsgamegfelelés, hanem versenyszerű alapokon való kiválasztás a cél?

Amióta egyre intenzívebben mozgok adatbányász világban, azóta ternmészetes módon izgatnak a verseny-aspektusok. Na ez most ezennel begyűrűzött az SQL-világba is. :o) Annyira azért nem tartom triviálisnak az SQL-versenyzést,  de jó játék lehet belegondolni, hogyan lenne érdemes ilyesmit lebonyolítani.

Lehetséges felvetések/problémák egy egyáltalán nem futurisztikus SQL-verseny kapcsán:

* Kezdem egy elméleti (definiciós) kérdéskörrel: létezik SQL-re "rátermettség"? Aki jó 3GL-es, abból feltétlen "implikálódik" jó SQL-ezés képessége? Stb.

* Legyen OCA/OCP típusú (angol) feleletválasztós teszt a versenyzés alapja? Ez jó lehet disztingválásra, kiválasztásra? Mennyire él egy angol nyelvvizsga feleletválasztós tesztjével való analógia (állítólag az a mondás és ezért preferálják, hogy a jobb angolos jobban tölti ki őket, az én saját tapasztalatom, hogy az ilyen teszteket jobban töltöm ki, mint amennyire jó angolosnak tartom magamat. Avagy a ceruza-papír alapú és/vagy felelet-választós módi leginkább csak alkalmassági előszűrésre alkalmas, versenyzésre nem igazán?

* A győztes jósága mennyiben korrelál az kiválasztás jóságával (elsőfajú hibázás lehetőségei)?

* Létezik-e (és mennyire) olyan SQL-teszt, amit ha valaki nem kellően jól tölt ki (és bukik), attól még érdemes lenne alkalmazni (másodfajú hibázás lehetőségei)?

* Mennyire legyen "nyitott" az anyag? Lehessen rá készülni valahogy előzetesen? Erről célszerű-e bármit egyeztetni a jelöltekkel?

* Mennyire fontos a (help/internet nélküli)  precíz szintaxis szempontja versenyzésnél? Ha az a feladat, hogy írjon be valaki például natív dinamikus ciklusos select feldolgozást pár sorban, abban "lehet-e" hibát ejteni? Lehet-e, jó sql-es, aki helpből másolgat átírásra kódot?

* Az Oracle pszeudó-, sor- és analitikus függvényei, hierarchikus lekérdezései mennyire erős/ütős szempontok képességmérésben? Egyáltalán mi a helyzet az ANSI szabvány vs. Oracle-specifikumokat illetően?

* Sql-performancia? Hintek?

* Sql vs PlSql? Ha PlSql (3GL) is, akkor ott azért már komoly versenyfeladatok képzelhetők el, kérdés persze, hogy az RDBMS-világtól mennyire elszakadóan.

* Meg lehetne-e tölteni egy könyvet jó versenyfeladatokkal?

Na most itt abbahagyom a további kérdés-kigenerálást. :o)


UPDATE-1.

Némileg revideálnom szükséges álláspontomat, azután, hogy tegnap este, nulla rákészülés után, éles körülmények között kitöltöttem otthon, egy gyári, hivatalos, angol nyelvű 1Z0-047 kódú Oracle SQL Expert tesztet. Egy ilyen teszt során 70 kérdésre kell válaszolni, két óra leforgása alatt. 60%-nyi jó válasz után sikeres a vizsga. Nem síma feleletválasztós volt a teszt (mint nyelvvizsga teszteknél), mert van, hogy több jó megoldás is lehetséges volt egy-egy kérdésnél (viszont meglepő módon előre jelzik a tényt is, sőt, hogy hány jó választ várnak el az adott kérdésnél).A két óra is bőven elegendő volt (sőt szerintem túlméretezett), mégha eléggé meg is terhelő a teszt-kitöltés maga.

Parádés módon nagyszerű (plusz élvezetes) volt az a teszt, amit kitöltöttem. 100%-ban olyan dolgokra kérdezett rá, amit szerintem is tudnia kell egy jó SQL-esnek, egyetlen "aljasság" és/vagy vitatható dolog nem volt a tesztkérdések között (nem úgy, mint nyelvvizsga teszteknél). Rendkívüli módon kiváló "vérfrissítésre" is alkalmas, jó tréningnek tartom ezt a fajta tesztet.

Nagyon tetszett a tesztben az is, hogy rengeteg kérdés volt SQL-olvasásra. Vagyis adtak adatmodellt és/vagy SQL create&insert scripteket, és az ezekre megírt közel nem triviális SQL-eket kellett elemezni a kérdés megválaszolásához (alapvetően ANSI SQL-eseket). Én az ilyen típusú feladatokat tartom a legegészségesebbnek.

A teszt alkalmas lehet a szakmai angol tesztelésére is (esetleg szükség esetén némileg tuningolva, mert a teszt angolja tényleg nagyon egyszerű volt). Továbbá szerintem megoldja azt a problémát is, hogy feltétlen kelljen papír-ceruza alapon kódokat írni (help nélkül).A teszt-kiértékelés is tudhat menni könnyedén.

Szóval nem biztos, hogy fel kell találni a meleg vizet még egy versenyszerű kiválasztáshoz sem. Ilyen tesztekből bárki össze tud állítani magának egy jó tesztet saját használatra,sőt bővítheti feladatbankját saját SQL-olvasási/-módosítási példákkal. Esetleg PlSql-tesztekből is át lehet emelni példákat szükség esetére. Kiváncsi lennék hányan élnek ilyen módival.

Nekem mindig is voltak kifogásaim egy OCP-vizsgával, leginkább olyan téren, hogy szükséges volt hozzájuk valami nem éppen jó, olcsó és/vagy hasznos Oracle eszköz(ök) precíz tudása. Márpedig abból, hogy az Oracle jó és sikeres RDBMS-t tudott fejleszteni, nem következik, hogy jó és sikeres front-end eszközöket is tud(ott). Sőt. Ezt a fajta Oracle-specifikumot (és eröltetését) én perdöntő módon inkorrektnek tartom, ami alkalmas lehet súlyos aránytévesztésre/megtévesztésére is a vizsgára befizetők, valamint a jóhiszemű potenciális munkadók körében. Na ez a mostani Oracle SQL-Expert teszt hálistennek visszaadott némi jó szájízt.


UPDATE-2.

Hali,

Itt egy kilenc feladatos, Papír-ceruzás SQL-teszt. Kidolgozási idő szigorúan egy óra. Emlékezetből írom, nem kizárt, hogy hibázok. Ezért előre is elnézést kérek.

Ügyfél(ügyfél_id,ügyfél_név)
Számla(ügyfél_id,számla_id,egyenleg_dátum,számla_egyenleg)
Tranzakció(tranzakció_id,ügyfél_id,számla_id,tranzakció_ideje,tranzakció_összeg)
Ügyfélkapcsolat(id,ügyfél_id1,ügyfél_id2)

1. Listázandók az inaktív ügyfelek, akik az elmúlt 30 napban nem tranzaktáltak.

2. Az ügyfeleknek hány számlájuk van?

3. Az aktuális számlaegyenlegekből meghatározandó a 30 nappal ezelötti számlaegyenlegek, a tranzakciós adatok révén.

4. Itt volt egy 30 napi forgalmi adat alapján valami kiválasztás. Egyszerű volt, de már nem emlékszem rá vissza pontosan. :o(

5. Akkor nem tekinthető sikeresnek egy napi zárás, ha a tranzakció táblán a napi összesítés nem fut ki nullára. Mely napokon nem volt sikeres zárás?

6. Listázandók azon ügyfelek, akiknél van legalább egy 45 napos intervallum, amikor több mint 100.000 fórint jóváírás érkezett.

7. Egy ügyfél közvetlenül és közvetetten is kapcsolódhat egy másik ügyfélhez (egy másik ügyfélen keresztül). A tranzitivitási lánc tetszőleges hosszú lehet. Egy-egy ügyfélnek hány (közvetlen és közvetett) kapcsolata van?

8. Készítendő egy output, ahol ügyfél_id-nként az első, második, harmadik számlához tartozó pozitív előjelű tranzakció összegek végösszege jelenik meg, 2010.11.01 utáni tranzakciókra.

9. Listázandók azon ügyfelek, akiknek legalább 7 negatív összegű tranzakciója van 2010.11.01-től kezdve, ezen tranzakciók átlaga kell ügyfelenként, úgy, hogy a három legkisebb és legnagyobb összegű tranzakció nem számolódik bele az átlagba.

Azt gondolom ez egy igazi emberkínzós "teszt"(?), mind megírni, mind kijavítani (pláne nagyüzemben). Főleg annak ismeretében, hogy az én kézírásom csúnyább, mint a világ legcsúnyább nője, a néhai Zámbó Jimmy....
;)

Az egy óra is elég kevés érzésem szerint, én legalábbis kihasználtam a rendelkezésre álló időt.

A feladatok viszont zseniálisak, szvsz. Ezért is osztom meg őket, tanulságképpen.


UPDATE-3.

Szerintem a legfontosabb azonosítani, hogy szakmailag mitől jó egy SQL-es, ahogy ezt fentebb is megkíséreltem. A további kérdésekre az én válaszkezdeményeim:

* Szvsz, aki (ösztönösen) jó 3GL-ben, nem feltétlen jó SQL-ben is. De van komoly esélye jónak lennie benne, leginkább avval, ha sikerül érdemben ráéreznie az ízére. Sokkal nehezebbnek érzem az átmenetet 3GL és SQL között, mint két 3GL nyelv között. Valamint én megkülönböztetek OLTP-s és adattárházas (analitikus) SQL-est is. Az elöbbi lényegesebben könnyebb műfaj, szvsz.

* Immáron azt vélem, hogy a feleletválasztós teszt csomó előnyén túl, a versenyszerű kiválasztásra is alkalmas (legalkalmasabb?). Főleg, hogy a kiválasztásnál egyéb szempontok is vannak, más véleményekkel összhangban. Azt nehezen tudom elképzelni, hogy aki jól tud olvasni/módosítani kemény komplex SQL-eket, az ne tudna írni is jól SQL-eket. (Nyelvnél ez például távolról sincs így, szvsz). De befolyásolható vagyok a kérdésben. ;)

* Az elsőfajú hibázást sokkal valószínűbbnek tartom mint a másodfajú hibázást. Analógia: szerelembe könnyebb esni, mint komoly, tartós, boldog házasságba lépni. Illetve, ha valaki első körben ellenszenves, nehéz lesz lesz másodjára szerelemre kiválasztani, még ha jó sok hálivúdi film is szól ilyesmiről. ;)

* Én pártolom, hogy minél zártabb legyen az anyag, amiről szólna a verseny (előzetes informálással), de nyilván nem publikus tesztsor alapján versenyeztetnék.

* Én nem vagyok híve a precíz szintaxis számonkérésének (tőlem még a hierarchikus query vázát is lehet helpből másolni, az analitikus függvényekről nem is beszélve). Például mert hasznosabb agyi tevékenységek elöl veheti el az erőforrást. De el tudom fogadni az ellenvéleményt is.

* Tetszik nem tetszik, az ANSI-szabvány "tudása" nehezen megkerülhető. Olvasni mindenképpen kell tudni ilyen SQL-eket, szvsz.

* Oracle-specifikumok nálam opcionális kategória. Szerintem fontosabbak az eddigi szempontok, illetve ezek a specifikumok menetközben felszedhetők, külön tanfolyam nélkül is. De el tudom képzelni, hogy valaki munkaadó igényelje ezt kiválasztásnál valamilyen (rákérdezési) szinten.

* Nem OLTP-s, hanem analitikus SQL-ezésnél, szerintem érdemes firtatni performancia-kérdéseket, ahogy PlSql-es kérdéseket is, de ez az esetemben lehet, hogy már az agykárosodás kategóriája. :o)

* Hogy mennyire vendorspecifikus kell legyen a kiválasztás? Én inkább úgy teszem fel a kérdést, hogy drágább RDBMS-hez, talán drágább alkalmazottak tartoznak jellemzőbben (hogy mennyire indokoltan az lehet vita tárgya). MySQl 3.2-höz nem feltétlen alkalmaznék Oracle 11g profit (most így extrapolálva). Viszont, ha MySql-s OLTP-s tudás kell, engem nem zavarna, hogy valaki PostgreSQL-ben szerezte a tapasztalatát (vagy fordítva).

* Azt én is jónak tartanám, ha lennének jó, strukturált és karbantartott feladatbankok SQL/PlSql-re. Bennem a kérdés immáron az, hogy mennyire inkább az önképzéshez tartozóan, és mennyire a versenyszerű kiválasztást támogatva.

* Az emberi és egyéb képességek szerintem is nagyon fontosak (szakmain túl és persze perspektivikusan is). És akkor tényleg ott van még a fizetésigény kérdése is. ;)

A bizalom egyes adatbányász aspektusai

A minapi elöző Projektvezetés és scope-menedzsment posztomhoz egy hosszabb komment érkezett nemrég, és mivel izgalmas inspiráló felvetések voltak a kommentben, ezért külön posztban igyekszem reagálni.

* Azt hiszem ami a legfontosabb lenne a BIZALOM ami a mai világban egyre inkább kiveszőben látszik.
* ...elveszíteni a bizalmat sokkal könnyebben, gyorsabban lehet, mint visszanyerni
Sőt megnyerni is könnyebb a bizalmat, mint visszanyerni.
*...pillanatnyi előnyökért változtatnak...

A bizalommal kapcsolatban fentebb írtakkal nagyon egyetértek, illetve sok minden továbbit is lehetne még említeni. Tényleg jóval nehezebb elnyerni pláne visszanyerni, mint eljátszani a bizalmat, és a mai modern pörgésben a rövidtávú nyereség vágya (aka kapzsiság) sokszor gátja a hosszútávó stabil bizalomnak.

Ami a tárgyunk szempontjából viszont izgalmas, hogy a bizalom (1) alapvetően "intuicióorientált", (2) bár közvetlenül nem derült ki az előző posztból, de én alkatilag elsődlegesen "analizisorientált" személyiség vagyok. Engem pont az izgat, hogy hogyan lehet lehetőleg minél praktikusabban "objektívvé" tenni a bizalmat, hogy milyen stratégia mentén érdemes bizalmat adni.Egyszer jó lenne erről is hosszabban beszélni.

A bizalommal kapcsolatos másik fontos momentum - a létén, nemlétén kívül -, hogy megérte-e. És itt is nagyon hiányzik a visszamérés, az én analizisorientált szemléletemnek.

Bizalom kapcsán, meg ha már adatbányászatról van szó külön szót kell ejteni a Jevons paradoxonról is (szabad szóhasználattal élve hiába ez egységnyi  hatékonyságnövekedés, ha mennyiségi összességében sokszorosra nő a veszteség).

Ha volt valaha valami unszimpatikus nekem az adatbányászatot illetően, az az, hogy az adatbányászeszközöket nem reális termékelőállítói profitra méretezve árulták, hanem a vásárló ügyfelek várható hasznának léptékére (magyarán indokolatlan extraprofitra). A vásárló ügyfelek aztán "előre a medve bőrére" címszóval megvették - előre kifizetve - ezeket az eszközöket. Az adatbányász konzulensek aztán például első körös logisztikus regresszióval "csodákat" varázsoltak a megrendelőiknek. És a legcsúnyább, hogy mivel ez eléggé gyorsan megvolt minden egyes alkalomra, ezért mindezt a többi - iparágon belüli - konkurens cégnél is elsütötték.

Tehát a megrendelők kvázi még a komparativ előnyüket sem tudták kihasználni a nagy felpörgésben. Kik jutottak extraprofithoz a szabad piac farkastörvényei alapján? Az eszközgyártók, meg a konzulensek. És relatíve kinél volt a legkisebb lecsapódó haszon, akik megelőlegezték a bizalmat, és megfinanszírozták az egészet előre.

A dolog ott üt vissza, hogy a megrendelők előbb-utóbb megtanulnak számolni és visszamérni következésképpen egyre nehezebben egyre munkaigényesebb (akár nullához konvergáló profittartalmú) projektekhez lehet csak hozzájutni, pláne így válságokkal terhelt időkben. Számomra mindebből az a tanulság, hogy mind a bizalmat, mind a munkakapcsolatot új alapokra (mint a farkastörvények) kell helyezni a jövőben. Az előző posztomban is ennek szerettem volna hangot adni (más megközelítésben).

Emlékszem olyan saját tapasztalatra, amikor egy cég új terméket hozott be, és a többi, már neves termékhez képest fél! áron adta. Ez jó is volt, és egyben rossz is... jó, mert így talán könnyebben meri kipróbálni az ember, mert úgy gondolja, hogy ennyit még szán rá, ha ki is dobja végül, viszont rossz, mert talán épp a "túl olcsósága" miatt nem meri kipróbálni, mondván, ebből az összegből minőségi termék nem állítható elő.

Az új termék és marketingje egy érdekes téma az adatbányászatban is. E. Rogers 1975-ös tankönyve a vásárlók alábbi kategóriáit különbözteti meg. Az egy érdekes adatbányász-feladat, hogy minél hatékonyabban megtalálni az innovátorokat, akik (1) szívesen kipróbálják az újat, sőt vállalják a kezdeti nehézségeket is vele (2) pozitív valamint intenzív mennyiségű & minőségű üzeneteket adnak tovább a náluk lassabb - nagyobb tehetetlenségi erővel rendelkező - többieknek.

03% innovators (venturesome);
14% early adopters (respectable);
33% early majority (deliberate);
33% late majority (sceptical);
16% laggards (traditional).

...nem megtartani akarják a kuncsaftot, hanem elcsábítani...

A helyzet az, hogy mind az ügyfélmegtartás, mind az ügyfélmegszólítás komoly adatbányászati iparág, hatalmas arzenállal. Mindkét végről megy a harc az ügyfelekért. ;)

Projektvezetés és scope-menedzsment

A minap egy igen érdekes post jelent meg a BiProjekt blogon Scope menedzsment: Hogyan mondjuk nemet? címmel. A téma szerintem nagyon jó, sőt hirtelen felindulásból még egy hosszabb kommentet is elkövettem ott. Aludva a történtekre, és ugyan továbbra is blogkeretek között maradva, de azért szeretném tágabb kontextusba helyezni az ott vázolt gondolatmenetemet.

Mielött a scope-menedzsmentre térnék, a vonatkozó tárgybeli tágabb kontextusú adatbányász vénájú "modellezésem" veleje, hogy érdemes lehet a projektvezetést egy speciális 2x2 mátrix mentén vizsgálni.

Az egyik "vízválasztó", hogy a projektvezető analizisorientált-e avagy koncepció/intuicióorientált-e.
(1)Az előbbi számolni szeret, számokhoz, tényekhez, objektív információkhoz keres magyarázatot, érveket, érzelmet/támogatást.Az utóbbi intuiciót, inegzakt ám releváns fogódzókat próbál meg számokkal, érvekkel alátámasztani.
(2) Az előbbi legfőbb hibaforrási lehetősége a számokban, részletekben való elveszés (egy lehetséges potenciális adatbányász-analógiával, "túltanulás"). Az utóbbinak az elfogultság, rugalmatlanság kockázata. Senki sem szereti ugyanis az intuicióit pillanatonként vizsgálatnak alávetni, vagy pláne ennek nyomán permanensen kételkedni.
(3) Érezhető, hogy egyik 100% vegytiszta állapot sem az igazi. Nehéz egzaktul és pontosan számokba önteni az élet történéseit, előbb-utóbb korlátokba kell ütköznünk, amikor teret követel magának az intuició. Az intuició is bizonyíthatóan és mérhetően nagyon hasznos, de egy határon túl már inkább lutri, és analizis nékül kuruzslásba csaphat át az egész. Tulajdonképpen vélhető módon csak prioritást állít fel a projektvezető alkata, miszerint analizisből tart az intuició felé, avagy megfordítva.

A másik vízválasztó, hogy mi a célfüggvény. Vagyis a saját avagy a közös profit maximalizálása-e a cél. Símán meglehet, hogy különvéleményen vagyok, de ez szerintem (1) releváns kérdés, (2) valószínűsíthető a különbözőség (nem esnek egybe).

Durva példaként említeném a Microsoftot és desktop operációs rendszereit. Az nem kérdés, hogy Microsoft jó nagy profittal rendelkezik, meg vezére sok-sok évig a világ leggazdagabb embere volt. Az viszont egy másik kérdés, hogy fizető vásárlói mennyire elégedettek, mennyi hasznot termelt nekik a Microsoft-elkötelezettség, milyen költség mellett.Nem mindegy, hogy a termék sikeres-e, avagy konszenzusosan jó-e.

További példa lehet, hogy egy alkalmazott mennyire nézi a kenyéradó cége céljait, ha saját céljai kerülnek fókuszba, Vagy mennyire triviális egy olyan beszállítói gondolatmenet, hogy bár hasznom és bevételem lenne egy projektből, de azért nem csinálom meg, mert a megrendelőmnek nem vagy nem eléggé hasznos. Az adatbányászatban ez a kérdés különösen élesen merül fel. Korábban már említettem itt a blogon ("nagy kihívásoknál"), hogy nézetem szerint nem az a "májer" adatbányászatban, aki a legnagyobbat kaszál a megrendelőjén, hanem az, aki a megrendelőjénél a legnagyobb profitot tudja felmutatni, konstans költség mellett. Kár, hogy ehhez sem a megrendelői visszamérés nem gyakorlat, sem objektív referencia nincs a beszállító-versenyzőkre.

Na és ezek után rátérhetünk a scope-menedzsmentre.

Talán konszenzus van abban, hogy általános érvényű igazságot lehetetlenség mondani (informatikában), hogy egy scope-bővítési kérelemre "igen"-t avagy "nem"-et érdemes mondani. Túl sok - egyenként, különállóan is fontos - tényező befolyásolhatja az optimális választ.
- Milyen a beszállító-megrendelő kapcsolat?
- Mekkora (milyen hatáskörű) a bizalom, a tudás, a tekintély, a befolyás a résztvevők/érintettek körében?
- Milyen mélységű árlefaragó versenyt kényszerített a beszállító-versenyzőkre a megrendelő? (Kedvezmények halmozását szinte sehol a világon nem szokás támogatni)
- Mekkora az anyagi kockázatipuffer/-tartalék?
- Mekkora jövőbeli perspektíva vélt vagy valós kényszerítő ereje?
- Stb.

Ezzel együtt is pár ökölszabály talán mégis megfogalmazható:

* Nem egészséges a "teljes elutasítás" álláspontja.
- Megrendelő sem tudhat mindent előre, azaz egyre több információhoz juthat a projekt haladtával.
- Az élet is rohamléptekben változik körülöttünk.
- Az informatika is egyre kevésbé olyan, mint egy katedrális építése (amin akár generációk dolgozhattak).
- Informatikai projekteknél jó eséllyel nem fillérre kicentizett a projektköltségvetés. Pont azért mert rendszerint nem a projektköltségvetés szokott rugalmas lenni, hanem a projektcélhoz vezető út.
(Példa: egy stabil korrekt megrendelő-beszállító viszony többet el tud viselni scope-menedzsmentileg, míg ha idegenként bemegyünk egy boltba, hogy "csak akkor veszek egy liter bort, ha kapok mellé egy másik liter ingyen bort", akkor körberöhögnek és elhajtanak, mert a boltosnak nyílván nem éri egyszeri tranzakcióban az ilyen rugalmasság (nem fog beleférni a "scope"-jába)

* Nem egészséges a "teljes megengedés álláspontja (pusztán csak azon az alapon, hogy nincs ellenérv a scope-bővítés ellen).
- egyfelöl "felhívás a keringőre" alapon egyre nagyobb sebességűre váltha scope-bővülési kérelmek generálódása
- másrészt exponenciálisan szállhat el a projekt sikerének valószínűsége a nulla irányába.

* Az élet dinamikusan változik, és alkalmazkodni kell. Szükséges tehát a mederben tartott scope-menedzsment.
- Egyfelöl felső korlát a projekthatáridő, a projektköltségvetés, meg a projektben érintettek elégedettségérzetének végösszege.
- Másfelöl tisztában kell lenni, hogy a scope-menedzsmentnek overheadje van. Bármilyen scope-bővülés felemlítésének pillanatában azonnal overheadet generál, implementálás nélkül is és legyen neki bármekkora potenciális haszna is. Ez a tény önmagában lassíthatja a scope-bővülés felpörgését, önmagában jelent korlátot.

* Minden scope-bővülés felvetésért egyfelöl felelősséget kell vállalni, másfelöl dinamikus alkalmazkodási kötelezettség címén hatásanalizist célszerű végeznie a beszállítónak (megrendelő vélhetőleg addigra már megtette ezt, hiszen felvetette a scope-bővítést). 
- Mekkora a haszon, mennyire nő a beszállító költsége (hatásanalizis + scope-bővítés elvégzése), mennyire veszélyezteti a projekthatáridőt, projektköltségeket, mennyire befolyásolja az összelégedettségérzést, adja-e rá minden projekt-érintett az áldását a scope-bővítésre stb.

* A hatásanalizis (legyen számolás- avagy intuicióorientált), remek terepe mind megrendelői, mind beszálíltói oldalról egy bővítési kérelem támogatásának avagy elutasításának.Viszont vélhetően nem megúszható (valamilyen formában, mértékben).

* Az élet nem fekete-fehér-igen-nem.
- Símán lehet, hogy a beszállító cégvezér jövőbeli aggódásból és szűkebb körű információkra alapozva támogatna inkább minden scope-bővítést, míg a konkrétumokkal jobban tisztában lévő terepen dolgozó projektvezető meg adott esetben inkább nem.
- Míg a megrendelőnél van akinek a határidő a fontosabb ezért elutasítaná inkább a scope-bővülést, és van akinek a minél tökéletesebb funkcionalitás (projekthaszon-maximalizálás) ezért inkább támogatná.

Az adatbányászat nagy kihívásai

Régi nagy vágyam egy blogposzt keretein belül csokorba gyűjteni az adatbányászat nagy kihívásait. Irtózatosan nagy az anyag, még úgy is, ha csak szubjektíve saját szemüvegen keresztül nézem a témát. Belegondolni is rossz, mi lenne, ha a szakirodalom kutatásait is megkísérelném áttekinteni.
Ennek az írásnak már rengetegszer futottam neki, és mivel mindig elégedetlen voltam a leírt betűhalmazzal, ebből következően még mindig bőven lehet, hogy még mindig nincs itt az ideje a nyilvánosságra hozásnak. De "egy életem egy halálom", ezt most mégis megteszem - remélem nem bánom meg. :o)

1.
Adatbányász kihívások terén nálam első helyen egyértelműen a kérdezés - "technológiája" (brrr) - áll. Nehéz elképzelni fontosabbat a jó kérdések feltételénél és talán az is kijelenthető van hová fejlődni az ügyben. A szép a dologban, hogy ráadásul a kérdés jósága és nehézsége között nincs egyértelmű megfelelési kapcsolat: a jó és a rossz kérdés egyaránt lehet könnyen is és nehezen is megválaszolható. Viszont a jó kérdés helyes megválaszolása csomó felesleges kérdést eliminálhat, már kérdések szintjén is (hát még a feleslegesen - tárgyban - elvégzett munkát illetően).
Az adatbányászatban ugye könnyű belefutni kombinatorikus robbanásba. Azt sem nehéz belátni, hogy minden lehetőségen végigmenve is el lehet jutni célhoz (elméleti értelemben véve). De sokkal fáradságosabban tehát sokkal költségesebben.
Azaz célszerű jó kérdések, jó lehetőségek mentén globális optimumra jutni, ha lehet minél hamarabb :o)

2.
Adatbányászatot körbevevő misztikus köd illetve irányába való - nemfeltétlen alaptalan - bizalmatlanság minél okosabb felszámolása a laikus közönség körében.

3.
Legnagyobb, legnehezebb ugyanakkor legfontosabb kihívások egyike, hogy adatbányász projekteknél természetes automatizmus legyen a várható haszon iletve visszaélési lehetőségek várható költségeinek hatótényezőit illető; egyforma súlyú/mércéjű elemzés illetve lehetőség szerinti számszerűsítés.
Példa: Az jó, ha korábbi hiteltörténet alapján adatbányászat nyomán egy bank megtagad egy újabb hitelt egy-egy ügyfelétől és evvel csökkenti saját költségeit, ami ugyanakkor az ügyfél szempontjából rossz hír. Az ügyfél - korrektség jegyében való - tárgybeli felokosítása (ügyfél milyen adataival mit csinál a bank) viszont pénzbe kerül., amivel illő lenne számolni.

4.
Adatbányász-feladat potenciáljának és költségvonzatának prediktálása.
Ez a Netflix-verseny óta az egyik legnagyobb fixa ideám. :o) Ugyanis, ha visszatekintünk
(1) Bámulatosan zseniális volt a 10%-os prediktálás-javítási versenycélkitűzés.
(2) Egy egész világ dolgozott a projekten, több éven át, aminek a végén abszolválódott a célkitűzés. Következésképp nagyjából számszerűsíthető az is, hogy mi energia fordítódott az egész verseny során a projektre.
Azt gondolom, ahogy a 100 méteres síkfutásnál sem reális például a 4 másodperces világcsúcsra díjat kitűzni, úgy az adott módon kiírt Netflix-feladatban sem volt mondjuk 20% javítási lehetőség.
Viszont jó lenne ilyen számokat, korlátokat, költségeket objektív információk alapján meghatározni.
Sőt továbbmegyek nem csak a maximum felsőkorlátra van értelme keresni/prediktálni, hanem "zéró" startponttól kezdve a nézelődést vajon meddig lehet relatíve kis költséggel relatíve nagy eredményt elérni/felmutatni a projekten és mikortól kell egyre kisebb lépéshez egyre nagyobb erőfeszítés.
Hol van a fordulópont?!
Ide tartozik jelentősen kisebb nagyságrendben egy-egy adatbányászverseny kimenetének prediktálása. Hogy milyen eredménnyel lehet győzni, hányan vesznek benne részt, stb.

5.
De a fentieken túl tágabb értelemben is nagyon fontosak a megbízható teljesítmény meg pénzügyi vonatkozású mutatószámok. Erre volt számomra remek - teljesítmény-vonatkozású - példa a közelmúltból, az Aitiás hang->szöveg konverzió, ahol a fejlesztői ígéret szerint, a beazonosítási konfidencia preciz és megbízható értékének számolásánál sikerült nagyot alkotni.
Az mindig jó, ha valami megbízhatóan mérhető, számonkérhető és az ügyfél-elégedettségnek is jót tesz. A híres nevezetes lift, ami ennek a blognak a nevében is bennevan, egy jó mutató. De nem csak ez az egy van és nem is minden esetben feltétlen mindig ez a legjobb. Arról már nem is beszélve, hogy faltól-falig nézve a teljes adatbányászati projektet (keletkezéstől, megszűnésig) már csak a dolog természete miatt is sokkal több mutató kellhet.

6.
Domain-specifikus tudás szükségességének eliminálása adatbányászfeladatokból, mondván legyenek elég a számok ne kapcsolódjon hozzájuk pluszba nehezen megfogható humán tudás.
Én ebben egyfelöl kevéssé hiszek (azt sejtem nem nagyon lehet relevánsan szűkíteni a domain-specifikus és domin-free adatbányászatos "ollót", az előbbi egy speciális rabló-pandúr játék keretében mindig előrébb lesz) Másfelöl személy szerint abban vagyok érdekelt, hogy a humán tudás - mondjuk most így hatásvadászóan - sose ne értéktelenedjen el.
Ez a maradi(?) koncepció az én életem végéig valószínűleg kitart. Az viszont számomra is nyilvánvaló, hogy van ilyen jellegű presszió a szakmán, adatbányászversenyekből is leszűrhetők ilyen tendenciák.
Első ráézésre jó ötletnek hangzik, hogy gombnyomásra száguld kifele a számítógépből az eredmény, számokkal reprezentált állomány-inputokra. De ennél sokkal jobb érzés belegondolni, hogy az emberi tudás ezt tudhatja továbbjavítani.

7.
Buzzworddel szólva multidimenzionális adatbányászat. Póriasabban megközelítve: kétdimenziós tábla bővítésének lehetősége minimum egy harmadikkal (idő) dimenzióval. De a sokdimenziós táblák adatbányászatának jelensége sem feltétlenül alábecsülendő.

8.
Fekeze-doboz algoritmusok - legjellegzetesebb példaként neurális háló - kifehérítése. Üzleti adatbányászatban alapvető elvárás a magyarázhatóság.
Hiába produkál egy algoritmus jobb eredményt, nyernek meg vele például extrém messzire tekintő idősorelőrejelző versenyt. Ha egyszer meg kell bízni benne és sok forint sorsa múlik rajta.
Örök tanulságként lebeghet a szemünk elött, hogy miért olyan már-már felülmúlhatatlanul népszerű a döntési fa.

9.
Vizualizáció nem az én témám, de el kell ismerni nagyon fontos. A mérnöki felsőoktatásban hányszor tanították nekünk, hogy egy jó ábra sok-sok betűnyi szöveget tehet feleslegessé. Én magam a számok között érzem jól magam. De a számokat el kell "adni", és az eladást nagyban segíti a vizualizálás.

10.
Adatbányász modell stabilitásának prediktálása, domain- és nem domain-specifikus információk alapján. Hogy meddig tudhat változás nélkül vagy némi üzemeltetői hegesztéssel "érvényesen" működni a modell.

11.
Change Point Detection. Üzemszerű működés közben elemi követelmény, hogy anomáliák, fordulópontok felbukkanása esetén, vagy korrigálódjék automatikusan a feldolgozási folyamat, vagy hívjon valamiféle humán segítséget ez a folyamat. Anomáliát okozhat például egy lényeges magyarázó változó tönkremenetele, egy potenciálisan esélyes magyarázóváltozó felbukkanása, az adatokban egy új trend felbukkanása stb.

12.
Change Point Detection tágabb kontextusban, a változás-management része. Az az egyik legnagyobb hiba, amit informatikában és adatbányászatban el lehet követni, hogy nem időtávban, hanem időpillanatban (pl.: üzembeállítás) gondolkoznak egy-egy megoldás kapcsán. Nem lehet kérdés, aki rugalmasabban reagál adekvát módon a változásokra annál lesz a versenyelőny.

13.
További egyre finomodó cache-támogatás az adatbányászati feldolgozáshoz. Kvázi mint adattárházaknál a materialized view.
Ha vannak értelmesen tárolható sok számolást kiváltani tudó közbülső eredmények, akkor ezeket lehet, hogy érdemes tárolni. Hogy mást ne mondjak az apriori-algoritmus egyes implementációinál a kizárólagos memóriahasználat kizárólagosságának enyhítése. A szoftverekben - az IBM SPSS Clementine-ban/Modelerben legalábbis egészen biztosan - általában lehet olyan, hogy az adatbányász-stream bármely lényegi pontján cache-elhető az addigi számolás. Ezt lehetne tovább gondolni a modell-node-ok belső számolására kiterjesztve. Akár szoftveren belüli versengő algoritmusok részére is. Horribile dictu szoftverek közötti szabványban publikált esetekre. Ne értsük félre, nem az apriori algoritmust akarom közös platformra hozni a lineáris regresszióval. Viszont a nagy adatbányász algoritmus-családokon belüli sokszáz pici nem feltétlen nagy dologban eltérő algoritmusoknál ennek lehet értelme az én meglátásom szerint.

14.
A párhuzamos számítások mindennapi trivilitássá válása. Robbanásszerűen nőnek az adatok, az algoritmusok, a lehetőségek, versengések. Egyre inkább szűk keresztmetszet és gazdaságtalan a sokmagos CPU-k, GPU-k egy szálon való foglalkoztatása.Idetartozik a skálázhatóság is.

15.
Hálózat adatbányászatának térnyerése, méltó helyének megtalálása. A hálózat engem egy kicsit emlékeztet az idősorra annyiban, hogy (A) mindkettő spéci adatszerkezet és (B) mindkettő elemzésének saját módszertana van. De ugyanitt említendő a Data Mining v2.0-ként emlegetett összetett (pl.: multimedia) adatszerkezetek adatbányászata is.

16.
Feature selection. Nehezen alábecsülhető fontosságú kihívás. Kombinatorikus robbanás mentén egy-egy feladatban is könnyen elszaporodhatnak a feature-ök úgy, hogy közben minél kisebb műveletigénnyel, kvázi valós időben kéne megtalálni legjobb magyarázó erővel bíró feature-kombinációt.

17.
Feature extraction. Mai napig izgalmas versenyek tárgyát képezi, hogy lehet képek, hangok komplex bitstruktúráit - versenynyerést támogató módon - jellemző vektorokra leképezni.

18.
Nyitottvégű téma (csak abbahagyni lehet, befejezni nem): idősorelőrejelzés minél távolabbi időre, idősorszegmentálás -osztályozás.

19.
Van-e értelme a csoportosítással indított osztályozásnak. Ahogy én láttam eléggé ellentmondásos a szakirodalom a témában. Van aki azonnal "hülyeség"-et kiált az ügyben. :o).

20.
Én úgy érzem az asszociációs szabályok témája a világon lefutóban van (lehet, hogy tévedek). Én még mindig látok benne kiaknázatlan potenciált mind elvi (pl.: szabályaggregálás, prediktálás, stb.), mind megvalósítási szinten (párhuzamosítás, ne csak memóriában lehessen számolni, stb.)
Asszociációs szabályoknak ott érzem a minőségi különbséget, hogy míg normál esetben az adattáblák egy-egy cellája csak egyszer vesz részt az algoritmusban, addig az asszociációs szabályoknál semmi akadálya, egy-egy adat több szabályban való előfordulásának.

21.
Adatbányászat és operációkutatás. Példa: kampánymanagement során nagy ügyféltömegre kellhet egyszerre osztályozni és ügyfélcentrikusan termékportfóliót optimalizálni (operációkutatásos értelemben).

22.
Adatbányászat és folyamatszervezés, egyre komplexebb integrációkkal megspékelve. Különös tekintettel a humán és gépi - dinamikusan akár folyamatosan változó - feladatok vonatkozásában. Mikor kell embernek beavatkoznia, egy adott pont után milyen feladat bízható már rá gépi algoritmusra. Ugyanitt az "analitikus" data mining felöl való elmozdulás az "operativ" real-time data mining felé, a fejlesztési ciklusok rövidülésével.

23.
Inkrementális gépi tanulás úgy en bloc
Ami eröltetett példa most eszembejut: például Netflixnél melyik filmből hányat kell raktáron tartani az egyidejű kölcsönzésigények kielégítéséhez. Mely filmekből lesznek sikerfilmek, hogyan változik trend értelemben a közizlés stb.

24.
Ensemble classifier, boosting, szavazási stratégiák, információ aggregálás, ortogonális módszerek ortogonalitásának mérése, hatásuk szavazási stratégiára.

25.
Lehet, hogy a világon egyedül vagyok vele, de nekem nagy és izgalmas kérdés, hogy adatbányászati szoftver mettől-meddig tartson funkcionalitásban. Én azt mondom - most SPSS-ben gondolkozva -, hogy a Statistics és a Modeler típusú funkcionalitásoknak "kötelező" módon egyetlen eszközben redundánsmentesen kellene egyesülniük, ahogy egyébként a SAS-ban ez régóta megoldott (leszámítva azt, hogy ma már van nagy SAS és kis SAS, becenevén SAS JMP.
Amit jobban le tudnék róluk képzeletben választani funkcionalitást az az egyébként Clementine-ban zseniálisan meglévő előfeldolgozó. Lásd amúgy az open source eszközök puritánságát ezen a téren. Egy adatbányász eszköz miért ne mondhatná, tessék nekem korrekt inputállományt adni, rádbízom kedves felhasználó, hogy teszed ezt. De ez csak egy szuibjektív álláspont, ami valószínűleg vitatható.

26.
Ez megint lehet, hogy az én spéci "agybajom", de én egy adatbányász-tooltól független vagy annak részeként működő előfeldolgozótól ideális esetben elvárom a Clementine-stream könnyed eleganciáját a kapcsolódó node-lehetőségekkel, meg az SQL-motorok egyszerűségét, robosztusságát, performanciáját.
Az én jelenlegi minden bizonnyal korlátos tudásom alapján azt gondolom, van amit Clementine-ban célszerű illetve gyors megcsinálni, van amit meg SQL-ben.
Az is lehet jó irány, ha tud kombinálódni a két lehetőség:
(A) adatbányász stream részeként belső saját adatbázison lehet SQL-ezni.
(B) Az is jó, ha az SQL/4GL-ek ki tudnak egészülni a Clementine mutatta finomságokkal, hasznosságokkal. Persze nem kergetek illúziókat. Amíg például egy Oracle-ben 999 mező lehet csak egy táblában, a mező nevek meg maximum 18 karakteresek addig mindez felesleges vágyálom.

27.
A kereskedelmi szoftvereknél (leginkább fókuszban lévő SAS és IBM SPSS-nél), megoldandó kihívásnak tartom az optimális felhasználószám * szoftveregységár megtalálását, ugyanis jelenlegit szuboptimálisnak tartom. Ezzel párhuzamosan persze nagyon drukkolok az open source eszközök fejlődésének is.

28.
Data Mining Tool kiválasztás "algoritmusa" objektív (minél egzaktabban számszerűsített) alapokon.

29.
Adatbányászversenyek korrekt kiírása. Például hogy ne legyen beszédes egész azonosító, ami önmagában ver magyarázóerőben minden más attribútum(kombináci)ot. Továbbá érdemes lehet megfontolni, hogy verseny után publikus legyen a validáló teszthalmaz is a maga teljességében (tényadatok, cimkék, stb.)

30.
És legyen végre valahára egy jó deduplikációs verseny megszervezése. :o))))))
Ez poén, ne vegye senki komolyan. Vagy mégsem?! :o)))

+31 A kombinatorikus robbanás az adatbányászati elemzésben magában is benne van. Talán nincs még egy szakterület ahol olyan gyorsan tudnának szaporodni kézi létrehozású állományok, mint az adatbányászatban az adatbányász streamek verziói, különféle elágazásokkal, hozzátartozó input, közbülső illetve output állományokkal. Ráadásul a verziók a backtracking miatt eléggé egyenértékűek (az újabb nem feltétlen jobb, a régebbi nem feltétlen eldobandó). Nehéz ritkítani őket.

+32 Az állomány-túlszaporodásnak van még egy megoldandó rákfenéje a menetközbeni dinamikus változást igénylő névadási/elnevezési konvenció.

+1 Szintetikus és valós datasetek közti hasonlóságok, különbözőségek.
* Hogyan lehet valós datasetet minél jobban közelíteni szintetikussal?
* Hogyan ismerhető fel a szintetikus dataset (pl.: adatbányászversenyen ez lehet kritikus probléma: Netflix-versenynél én magam is küzdöttem ilyen aspektussal)

+33 Guide-technológia alaposabb térnyerése az adatbányászati elemzési folyamatban, a kombinatorikus robbanás minél okosabb legyűrésére. Meg hogy ne lépjünk ugyanabba a rossz folyóba kétszer stb. ->
* Milyen utat érdemes bejárni az elemzés során (akció-reakció szintjén)?
* Mi múlik valóságleképezésen, adatokon, modelleken, modellparamétereken stb.?
* Milyen buktatókat hogyan kell kikerülni?
* Mikor mi alapján kell 'visszalépni' (backtracking), ha az eredeti (pre)koncepció megdőlni látszik?
* Dinamikus programozás és klasszikus hálótervezés analógiái alapján a minél kevesebb téves elágazással tarkított kritikus út behatárolása.
* Az erőforrásokat hogyan lehet optimálisan elosztani a kritikus út bejárására?

+34 Faltól falig tartó projektszemléletbe ágyazott adatbányászat. Aminek komponensei minimálisan:
* a rendszerjóságra optimalizálás
* a változásmanagement
* a támadhatóság elleni védekezés
* a kockázati tényezők minél pontosabb artikulálása
* szükséges rendszerszintű változások (tehetetlenségi nyomatékkal szembeni) elérésének mikéntje

+35 (2010.10.24) Számomra abszolút friss és megrendítő élményként, amiről a héten hallottam előadást -> "Learning to rank" (a felügyelt gépi tanulás azon ága, ahol a cél egy rangsoroló függvény tanítása). A tanuló adat lekérdezéseket (query) és hozzájuk tartozó dokumentumokat tartalmaz. A feladat adott lekérdezéshez a dokumentumok olyan permutációját visszaadni, melyben a lista elején a releváns dokumentumok, a lista végén pedig a kevésbé relevánsak vannak. Rendkívül izgalmas, ugyanakkor megdöbbentően nehéz témának tűnik, például a sztochasztikus gradiens módszer nehézségei miatt is.

+36 (2010.10.29)  Modellépítésnél:
- A futási idő minél jobb megbecslése, pláne egy reálisan működő progressbarhoz
- Megszakíthatóság, illetve félbeszakadás utáni számolásfolytatás.

+37 (2010.11.14) Alkalmazott (üzleti célú) adatbányászat-kutatás hasznának mérhetősége.
* Sajnos manapság túl sok komponens kell a sikeres adatbányászathoz, miközben a feladatok nehezednek)
- Tőkeerős megrendelő
- Minőségi adatbányász
- Nagyon jó közös együttműködés köztük
- A globális optimumra jutáshoz némi szerencse (jelenleg nincs algoritmikus út, én nem tudok róla legalábbis)
* Az adatbányászatra nagyon jellemzőnek tűnik
- Kombinatorikus robbanás mentén sokkal több a jónak tűnő ötlet, mint a verfikálható
- Gyakran túl nehéz agyban verfikálni az ötleteket (ahol a leggyorsabb és leghatékonyabb lenne)
- Túl költséges adatbányász folyamat során elillanhat a potenciális nyeresége a dolognak, akár feladatspecifikus problémából eredően, akár a fenti komponens-négyes hibádzása miatt.
* Ha én megrendelő lennék adatbányászatra az alábbi dolgokra fókuszálnék:
- Minél egzaktabban _előre_ számolnám a folyamat várható nyereségét és ahhoz allokálnám a témába fektetendő tőkét.(mérlegelve az időtényezőt a konkurrensek vonatkozásában illetve a várható felmerülő problémák költségeit is amennyire csak lehet). És persze lehet befektetendő tőkéhez profitot maximalizálni is.
Ez az út nagyon nehéz egzaktsági problémák meg potenciális tudásbeli hiányosságok, stb. miatt, de célnak mindenképpen cél, szvsz.Szerencsére az önképzéstől a szakértői tanulmányok megrendeléséig széles a potenciális spektrum.
- Mivel nem feltétlen van több dobásra fedezet beszállítóválasztásnál, ezért az első dobáshoz próbálnék auditálást kicsikarni a beszállítókból, hogy ne annyira szerencsén és egyéb körülményeken múljék a dolog. Persze egy lottó-ötöst is meg lehet nyerni, csak pénzszerzési stratégiának nem feltétlen jó ötlet. :o)
- Ha megvan a beszállító-kiválasztás akkor feltétlen bizalmat adnék a beszállítónak (a téma nagyságrendjében csak persze). A bizalmatlanság és rossz együttműködés a legjobb adatbányász-eredményt is alááshatja.

+38 (2010.11.14) Auditálás
- Adatbányászok nagy kihívása lehetne, hogy konszenzussal, belső hatáskörben a legjobb (hazai és/vagy külföldi) egyetemi erőkkel definiálni kellene mondjuk három évre előre szóló auditáló (minél domain-függetlenebb) adatbányász-feladatot (a Netflix-versenyek informatikai automatizmusával).
 - A jelenlegi adatbányászversenyeknek nagy baja, hogy kevesen indulnak rajta (főleg hazai, üzleti területről), nehéz mérésre alkalmazni tehát, meg túl gyors a lefolyásuk (és abban a konkrét verseny pillanatban nem feltétlen ér rá minden potenciális érdeklődő).
- Továbbá azért kellene csak mondjuk három évre, mert e Netflix I. verseny komoly tanulsága volt (hogy nagyon nehéz ilyen jó feladatot kiírni, illetve egy fordulópont után nagyon nehéz érdemben relevánsan javítani -> nehezíti a differenciálást, több a költség, mint a haszon)
- Ezt nem tartom kivitelezhetetlennek (mert egy honlap és egy jó feladat kéne hozná), nem lenne olyan őrület sem, mint a Netflixnél, hiszen nem lenne pénzdíj: csak azok vennének részt akik adatbányászatból akarnának megrendeléshez jutni (meg diákok tanulási céllal).
- Abban feltétlen hiszek, hogy az adatbányászat már tart ott szakmailag, hogy ilyen feladat kiírható és értékelhető eredményt adna.
- Abban nem hiszek csak, hogy feltétlen életképes lenne (mind megrendelői referenciapont-elfogadásban, mind az adatbányászok által való preferálásban). Még csak azt sem látni ki lehetne a kezdeményező: a potenciális megrendelők ki tudnának-e ilyen referenciapontot kényszeríteni, illetve az adatbányászok látnának-e hozadéknak például releváns adatbányászpiac-bővülést egy ilyen akció nyomában (hogy megérje nekik).
- Ha nem működne a dolog az azt mutatná, hogy mind megrendelői mind adatbányász oldalról kevés igény van a korrekt objektív mérhetőségre (meg jobban bíznak a korábban kialakult piaci status quo-ban, szakmai kapcsolatokban, ami nem feltétlen baj persze).
- Én a magam részéről ugyanis jobban támogatom, a mérhető alapozású problémaközpontú és -megoldó adatbányászatot, mint a hagyományos piacversenyeset (még ha netán személy szerint rosszabbul jönnék is ki belőle). Azt gondolom egy egyetemi diák tudhat méltó ellenfele lenni egy nagy és drága cégnek. (Nem az a jó adatbányász aki legtöbb megrendelésből a legnagyobb profitot tudja felmutatni, hanem aki a megrendelőknél a legnagyobb profitot tudja felmutatni) Kevés olyan szakma van ugyanis, ami egyrészt már ennyire polgárjogot nyert az életben, másrészt ahol a pénz- és kapcsolati tőke(költség) nélkül is kiváló mérhető és jelentős profitpotenciállal bíró eredményeket lehetne felmutatni.
- Komoly hátránya a fentebb vázolt megközelítésű dolognak (életképességi problémákon felül), hogy domain-független adatbányászat más, mint a domain-driven, érzésem szerint csak valamilyen szinten igaz az állítás, hogy aki az egyikben jó az a másikban is ugyanannyira jó.

+39 (2010.12.03) Mintavételezés
Minél egzaktabb és minél könnyedebben abszolválható részhalmazképzés nagyobb datasetekből, amire az adatbányász minél megközelítőbben ugyanazt az eredményt adja, mint a nagyobb/teljesebb datasetre.

+40 (2010.12.03) Jevons paradoxon káros hatásainak eliminálása.