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.

Youtube és a hálózatosodás

.
Ismét frissült a poszt, most egy UPDATE-2 szekcióval a végén.

Végre ismét egy olyan téma, ahol mindkét - tárgyi és adatbányász vonatkozású - aspektusban érintett vagyok /aki nem emlékezne a szerelem volt az első ;)/

** Az apropót egy tegnapi Napi Gazdaság online cikk adja:

"A hamburgi bíróság megtiltotta YouTube-nak az olyan felhasználók által feltöltött szerzői jogvédelem alatt álló anyagok közlését, amelyek sugárzására nincs engedély.

A Google által birtokolt videómegosztó így felelősségre vonható szerzői jogvédelmi törvény megsértéséből fakadó károkozásért - közölte a német bíróság a Bloomberg tudósítása szerint."

**Anélkül, hogy belemennék a bornírt jogszövegbe, amit meg lehet állapítani:

* Google-nek van pénze, érdemes megkísérelni őt fejni, jogszolgáltatás címén. Ideértve az amerikai jogszolgáltatás rendkívül költséges és egyúttal extrém furcsaságait.

* Igazságszolgáltatás igénye az ablakban sincs

* Nincs szó a károkozás számszerűsítő algoritmusának definiálásáról

* Nincs szó arról, hogyan lehet megfelelni a bírói felszólításnak (technikai értelemben). Ami miután lehetetlen elvárás, ezáltal alaposan sérül a szabad és jogszerű információáramlás elve.


**Direkt nem belemenve továbbiakban a szerzői jogba (kit, mennyire, hogyan véd a jog), meg annak kritikájába. Ez hatalmas téma, és komolyabb felkészültséget igényel.

Ami brutális észrevételt mégis megengedek magamnak a szerzői jog kapcsán (tapasztalat alapján, saját olvasatként):

* a szerzői jog érvényesítési égisze alapvetően terrorisztikus módszereket generál a világban:
(1) A Youtube tulajdonosi oldalán,  költséges és hosszadalmas - precedenst sosem ígérő - bírósági perekkel való fenyegetés/visszaélés).
(2) A Youtube-felhasználói oldalán, meg életreszóló megbélyegzés és hozzáadott értékek lenullázása.

* nem az egyéni szerzők jogairól, megélhetéséről, hanem a multik érdekvédelméről szól (lásd hozzá a 70 évre bővülési mechanizmust a védelmet illetően).

* a rohamosan terjedő szerzői joggal való visszaélés a kultúra sírásója tudhat lenni, az én értelmezésemben.


**Nézzük - a teljesség legcsekélyebb igénye nélkül - milyen "érdekességek" vannak a témában:

* Technikai értelemben l-e-h-e-t-e-t-l-e-n a tökéletes és automatizált tartalomszűrés. Ki is lehet játszani a szűrőt /saját tapasztalat, amit jobb a békesség alapon nem publikálnék ;)/ , illetve a szűrő is hibázik. Erre bírósági jogszolgáltatást alapozni nevetség tárgya, szvsz. Persze van az a pénz, hogy korpásodik az ember haja és van aki két fillérért még az......

* A Youtube-on nem minden felhasználó egyenlő.Ugyanazt a videófeltöltési jogsértést valaki elkövetheti más meg nem (sőt adott esetben kitiltják érte)

* Van egy visszataszító és ugyanúgy értelmetlen jelenség a Youtube világábam. Nemcsak a felhasználók, hanem országok között is vannak egyenlőbbek. Nevezetesen: egyes videók egyes országokban megnézhetők, más országokban nem. Ha innen nézem ördög, ha onnan angyal? Én úgy vagyok vele, ha a borba belekerül pár csepp pisi, azt a bort én nem kívánom már. Amúgy az országszűrés is egyszerű eszközökkel kivédhető: pl.: ingyenes ideiglenes ip-change.

* Youtube is megéri a pénzét. Még ő is téved, dokumentálható módon, a szerzői jog érvényesítésénél (hogy várható el az ingyenes videófeltöltőktől ugyanez?). Illetve hatalmával visszaélve, felhasználói profilokat töröltet, kockáztatva, jogtiszta videók törlését is. Én is töltöttem fel már garantáltan jogtisztán: pl.: apám zenéjét és előadását (én vagyok a jogtulajdonos, papírom van róla). És damoklészi kardként lebeg fejem felett a Youtube-profile-om törlése. Megírták mailben.

* Szó nincs a fokozatosság elvéről. Ha valakit sért szerzői jogában egy anyag, akor nem a feltöltőt keresi meg határidő megadásával, hanem egyből a YT-ra vagy bíróságra megy. Erről konkrét saját sztorit tudok mesélni: lásd alább.

* Bukás c. film alapján készült un. Hitler-videók témáját remekül foglalta össze az indexes-cikk, pár hete. Arról van ugye szó, hogy egy hosszú filmből pár percet kiemeltek a tréfás kedvű netezők és más kontextusba helyezték. Relatíve nagyon kis részlethez komolyabbnak tekinthető hozzáadott értékek keletkeztek. Nem foglalnék állást az ügyben, mindenki megteheti saját magában. Én csak igyekszem lajstrombavenni az anomáliákat/problémákat.

* A fenti cikkből egy bekezdés: A magyar jogszabályok szigorúbbak az USA-ban érvényben levőknél, itthon csak meghatározott esetekben (oktatási cél, idézet, tudományos kutatás, stb.) lehet jogvédett alkotást közzétenni.


**Következzék a saját konkrét megélt élményem a Youtube-bal, és a Hungarotonnal, mint szerzői jog védelmezőjével.

* Szűk körben megosztottam annó egy Hacsaturján (hangalapú)videót, amit egy többtízéves recsegő Hungaroton LP-ről digiztem be, ami úgy kvázi elérhetetlen a világban, hogy óriási érték szerintem (és ebben a konkrét esetben csak 50 éves jogvédelem határán mozog, annyira régi). Minden adatot, így azt is, hogy Hungaroton volt az LP, feltüntettem a videó leírásában. A Hungaroton viszont nem birtokolja szerzői jogot a felvételre, hiszen annó ők is licencelték az oroszoktól (Melodia, rajta van a lemezborítón!).

A Hungaroton engem nem keresett meg, egyből a Youtube-hoz fordultak (azzal az általános igénnyel, hogy töröljék a Hungarotonos tartalmakat), a Youtube letiltotta/törölte a videómat, majd közölte még két dobásom van és a Youtube-profile-omat is törlik.

Lehet, hogy szerzői jogba ütközik valamilyen értelemben a videóm felrakása, de jóhiszemű alapon történt, és olyan cég tiltotta le, aki szintén nem rendelkezik a felvétel szerzői jogával. Magyarán, ha nem írom ki, hogy Hungaroton, akkor egy rossz szó sem éri a ház elejét, és én feddhetetlen és nem megbélyegzett vagyok továbbra is, szerzői jogi értelemben. Paradox módon az informális korrektségem áldozata lettem. Azt sem csak kicsit megdöbbentő következmény, hogy ha kiveszem a "Hungaroton" szót a leírásból, akkor a szerzői jog sértése nem bizonyítható a Hungaroton részéről.

* Hogy érzékeltessem, a fenti sztori révén mekkora kárt okozott nekem a Hungaroton -> az idén májusban elérhetővé tett igen kellemes Youtube-feature - az un. unlisted video, ami feloldja a privát videók 25-ös limitjét -, a letiltás óta nem elérhető számomra, a Youtube-policy alapján, mert hogy a Youtube fiókom visszavonhatatlanul elvesztette good standing(=jó állapotú) státuszát. :o((((((((

* Ha Youtube-ra egy véleményes pedofil(!!!!) videót töltenék fel és azt törölnék, a Youtube-szabályzat értelmében hat hónap után ismét teljes jogú tag vagyok. A Hungaroton fellépése nyomán - szerzői jogsértés révén - viszont örök életre megbélyegzett és lekorlátozott vagyok. Kvázi megfellebbezhetetlenül, jóvátehetlenül. Tévedés az alapja a letiltásomnak, de mivel a felvétel jogaival nem rendelkezem (mert hiszen lehet, hogy már szabad felhasználású), egész egyszerűen nincs orvosság.

* Másfelöl a Hungaroton fellépés következményeként a Youtube az esetemben:
(1) abszolút hozzáértés nélkül
(2) bizonyíthatóan téves alapozással
(3) rosszindulatúan
(4) nehezen megfellebezhetően
járt el.

* Hungaroton nem érte el célját, továbbra is tengernyi régről fennlévő Hungaroton ráadásul CD-s alapú videó van fenn a Youtube-on.

* Nem életszerű számomra, hogy valaki kapható Hungaroton felvételt nem megvesz, hanem rákeres a jóval gyengébb technikai minőségű Youtube-on és onnan 'élvezi' töredékes élményként, pénzspórolásból. Aki pénzt akar spórolni a vásárlás mellőzésével, annak meg mindegy milyen felvételt hallgat, Hungarotont vagy mást (arról nem is beszélve, ha nincs feltüntetve, hogy Hungarotontól van a felvétel, a videó attól még ugyanúgy élvezhető). A Youtube önmagában óriási konkurencia a lemezkiadásnak, hiszen nagyon jó anyagai vannak és ki tudja tölteni az ember szabad idejét. És ha már életszerűség. Ha valakinek nagyon megtetszik egy Hungaroton felvétel részlete megveheti cd-n: én is vettem már így lemezt.

* Hungaroton csak általánosságban (az én értelmezésemben, elefántként lépve egyet a porcelánboltban) tett lépést márkája védelmében: írt egy levelet a Youtube-nak, nekem ugye konkrét kárt okozva. Általános Hungaroton levélre általános és egyszeri választ adott a Youtube.

(1) Ha a Hungaroton komolyan gondolja a tartalomtörlést, akkor folyamatosan kéne monitoroznia a neki nemkívánatos Youtube-tartalmakat és töröltetni őket. Ezzel párhuzamosan, nem épp örömteli módon, egy amerikai szerzői jogi pert reszkírozhat meg a Youtube-bal szemben.
(2) A Youtube küzdhet az automatikus tartalomfelismerés reménytelen problémáival.
(3) Az olyan feltöltők, mint én is, elhagyhatják a kiadó nevének feltüntetését (mint legkevésbé érdekes információt), az előadó és dátum meghagyásával. Ezzel szinte reménytelen helyzetbe kerülnek a jogsértő videókat böngészők helyzete.

* A magam konklúziója a sztori kapcsán, hogy a konkrét ügyben védhetetlen a Hungaroton álláspontja mind szűkebb, mind tágabb értelmezésben egyaránt. Továbbá el lehet gondolkozni ki járt jól az eset után, avagy esetleg ez egy negatív végösszegű játék volt, közgazdaságtani játékelméleti értelemben.

* Friss 2010.09.28-i hír. 20 nap elteltével lekerült a bilog a Youtube fiókomról. :o) Az előzmény annyi volt, hogy levelet írtam Hollós Máténak, mondván ha már nekem pechem volt, akkor más utánam jövőknek adjak valami halvány esélyt. Az egyre barátibbá váló levelezésben kiderült, hogy
(1) A Hungarotonnak a Hacsaturján Spartacus-Adagióból van egy újabb keletű felvétele (Miskolci Szimfonikusok, Kovács László vezényel).
(2) Hungaroton felvételnél 50 év a szerzői jog korlátozása
(3) És bár nekem kell kezdeményezni a Youtube-bilog levételét, de figyelni fog az ügyemre.

A konkrét ügy megoldódott. Mondhatni hatalmas szerencsém volt, azzal a jövőbeli kvázi ígérettel, hogy talán a továbbiakban nem velem kezdik a rendcsinálást a Youtube-on. Pláne mindezt egy őrült nagy butaságom után (kiírni YT-videóhoz a kiadó nevét). A tanulságok viszont továbbra is nyitva vannak jövőbeli végiggondolásra.

Itt a - rövid ideig még biztosan - ismét látható, kérdéses korai zsenge, kék hátteres, MovieMakerrel készített, Hacsaturjános Youtube-videóm, ha valaki meg akarná nézni


**És akkor nézzük a hálózatosodás (konkrét esetben a csomópontosodás) témáját, a videómegosztás mellé analógiának felhozva a social networkinget (társas hálózat).

* Mindkettő esetben felhasználói szemmel az a jó, ha egyetlen nagy van, hiszen egyszer kell regisztrálni, mindenki lát mindent, ilyenkor van a legnagyobb esély a találatra, "kézfogásra"/találkozásra. Arra most nem térnék ki, hogy a Youtube (mert a Google miatt triviális) vagy egy Facebook mitől tudott ennyire sikeresen monopol helyzetbe kerülni. Ez utóbbi egy érdekes szakmai kérdés, sok homályos ponttal, még szakmai berkeken belül is: lásd IqSys idei konfenrenciáját.

* A hátrányok már különböznek.
(1) Társas hálózatnál, adatvédelmi aggályok meg támadhatósági problémák merülnek fel.
(2) Videómegosztásnál a legnagyobb kerékkötő a fentebb taglalt szerzői jog lehet.

* Hiába a világ egyik legnagyobb, meg leggazdagabb cége birtokolja a Youtube-ot (Google), a szerzői joggal való visszaélés - hangsúlyoznám, hogy s-z-e-r-i-n-t-e-m - kivéreztetheti. A Youtube sikerrel elhárította a legelső - Viacom egymilliárd dolláros - keresetet, de ki tudja mit hoz a jövő?

* Ha bejönne a fenti forgatókönyv, akkor annak két lehetséges következménye minimum lehetne
(1) a kicsi videómegosztók térnyerése, amire már most is vannak jelek: mondjuk, ha engem kivágnak a Youtube-ról, akkor alapvetően hagyni szeretném a témát a továbbiakban.
(2) folyamatosan mentik le a Youtube-ról a videókat egyes honlapok. Erre saját videóim rákeresésekor döbbentem rá. Nyilvánvaló bármilyen szellemes is ez az "árnyék-backup", nem megoldás. By the way a gugli cache-ben is benne vannak egy darabig a törölt videók. /By the way a négyzeten -> ez nem baj? Ez is Google ám! ;)/


**Végül az én javaslatom, teljesen saját kútfőből. Én jelenlegi, amúgy harmatgyenge alapokon álló Youtube-os szerzői jog elleni - potenciálisan létező robbanással fenyegető - problémák elleni védekezésem ötletéből kiindulva.(Ha ez az alábbi ötlet nem merült volna fel bennem, már abbahagytam volna a Youtube-ozást. Így viszont van értelme kvázi mártírhalált halni a Youtube-profile-om elvesztésével)

Három "játékos" van a témában.

* a szerzői jog birtoklója
* a Youtube, aki nyög a szerzői jog terhe alatt
 * a videókat ingyenesen feltöltők, akik szintén nyögnek a szerzői jog terhe alatt.

Cél: ne kelljen nyögni és nyögetni a szerzői jog terhe alatt.
* a Youtube-nak ne kelljen hackelni egy technikailag lehetetlen/kivitelezhetetlen (csak tetszőlegesen jó minőségben megközelíthető) megoldáson, illetve ne kelljen költséges bírósági pereknek kitennie magát.
* a szerzői jog gazdái érvényesíthessék, ésszerű kereteken belül, anyagi igényeiket a szerzői joggal kapcsolatban.
* végül a feltöltők szabadon tudjanak kreatívkodni, ismét csak ésszerű határokon belül.

Én azt mondom a rádió létező erősen korlátos és degresszív díjszabása felé kéne elmozdulni, ha már nem kerülhetők meg a piszkos anyagiak. A Youtube fizet, mint rádió (esetleg a videófeltöltők méltányos hozzájárulásával), vezet egy tiltólistát, azokról akik a szerzői jogukat úgy érvényesítenék inkább, hogy nem fogadnak el anyagi ellenszolgáltatást (lényegesen kisebb kör, mint jelenleg azt gondolom). A Youtube meg úgy fizet valahogy, cserébe megpróbál megélni a reklámokból egyebekből, mint egy normál rádió. A megoldás rákfenéje nyílvánvalóan az összeg definiálása, ami elfogadható a Youtube-nak és elegendő a szerzői jog birtokosainak. Ami optimizmusra adhat okot, hogy a rádióknál azért tudhat működni.


UPDATE-1.

Zene boltot nyit a Google

Önmagában a Google mérete nem jelent biztos sikert, a kereskedőóriás Amazon például csak 12 százalékos részesedést tudott szerezni a digitális zenék piacán, noha az mp3-boltja már három éve működik. A Google-nek nagy előnyt jelent, hogy a webkereső és a YouTube adataiból tisztán látja a felhasználók zenei érdeklődését.

UPDATE-2.

Az indexes klasszikus zenei blog kommentjei között akadtam az alábbi gyöngyszemre. Aki nem jártas az avantgarde zenei világban, annak mondom ez a John Cage 4'33" "zongoradarab" annyiból áll, hogy kiül a zongorához a pianista és 4 perc 33 másodpercig csendben ül mellette egyetlen hang keltése nélkül. Én nem sokra becsülöm az avantgarde-ot, itt valami olyasmi lehet a háttérben, hogy a nagy zajban, jól lenne néha megállni egy kis csendre.

Adva van a darab tehát, ami 100% vegytisztán csend. A darab videójában, az alábbiak tanúsága szerint a Youtube-nak sikerült letiltani a hangsávot, a szerzői jog érvényesítése érdekében. :o)

Lágy számítások XML adatkezelésben és deduplikációban

.
Eddig még sose tettem ilyet ezen a blogon, remélem nem túlságosan "necces" meg "gáz", hogy most ilyenre van hangulatom.

Ajánlom ezt a blogposztot...
* a Sztaki ifj. Benczúr András és Lukács András vezette adatbányász csapatának, akiknek eddig sosem tudtam eléggé megköszönni, hogy megengedték személyes részvételemet műhelymunka keretében való egyes témábavágó, - ennek a posztnak az alapját is képező cikkhez hasonlatos típusú - cikkek ismertetésén. Sőt, amikor kérdést tettem fel, akkor sem tették ki a szűrömet.
* Sidló Csabának, akinek a DeDup témában való cikkismertetéseit/előadásait mindig is külön rákészülve, és ami fő, élvezettel hallgathattam az elmúlt évek során.
* Fekete Zsoltnak, aki élményszámbamenően hatékony kérdéseket és felvetéseket tud megejteni a cikkek széles skáláján/spektrumán.
* Gáspár-Papanek Csabának (blog), irányomba való jóindulatáért, segítőkészségéért.
* Kovács Gyulának és Arató Bencének, akiknek a legutóbbi sikeres DeDup-projektemet köszönhetem, aminek során, síma notebookon, 100% vegytiszta Oracle-környezetben, teljes céges deduplikálást 70 másodperces, teljes magánszemélyes deduplikálást 20 perces futásidőre tudtam optimalizálni, érdekes akviziciós ügyfélkonszolidáció keretében.

Nem akármilyen könyv jelent meg és került ragadozó kezeim közé, a fenti tárgybeli (angol) címmel Soft Computing in XML Data Management, a Springer kiadónál, idén 2010-ben, 363 oldalon, 130 euróért (uszkve 40.000 forint).

Az összesen 12 cikk, egyenletesen három nagy témába sorolódik:
1. Fuzzy típusú határozatlanság XML-ek vonatkozásában
2. Rugalmasság az XML típusú adatmenedzsmentben
3. Néhány fejlesztés és alkalmazás a témában

Mielőtt belevágnánk egy kis bevezető a címhez.

A soft computing magyarul lágy számítások a mesterséges intelligencia és ezen keresztül az adatbányászat kulcsfontosságú területe, eredendően olyan típusú nehéz (matematikai) problémákra - amelyek explicit meg nyers erő módszerekkel nehezen kezelhetők - vázolt egyfajta alternatív megoldási lehetőséget. Klasszikusan a (1) Fuzzy, (2) Neurális háló, (3) Evolúciós/Genetikus algoritmusok illetve ezek tetszőleges kombinációi tartoztak bele, mára a wikipedia szerint például még a Bayes háló is beletartozik, számomra némileg meglepő módon. A blogposzt címében lévő könyv alapvetően egyébként a fuzzy vonulatot tárgyalja /azért van benne Bayes háló is :o)/. A lágy számításos témáról az 1922-es születésű, műegyetemi professzor emeritus, Retter Gyula írt szenzációs, friss, két - ráadásul  magyar nyelvű - könyvet.
(1) Fuzzy, neurális genetikus, kaotikus rendszerek : bevezetés a "lágy számítás" módszereibe
(2) Kombinált fuzzy, neurális, genetikus rendszerek

Az XML, mint a neve is mutatja egy Markup Language-féleség, nagyszerű tulajdonságai - teljesség igénye nélkül:
* text-formátum
* félig-strukturáltság
* különbségképzési lehetőség
* szintaktikai meg valamilyen fokú szemantikai konzisztencia biztosítása
Nem véletlen hogy mára széles körben nagyon jól használható formátumnak bizonyult.Többek közt adatok tárolására is. De nemcsak szimplán relációs világban megszokott rekordok tárolására jó. Kottázó programok(!) szabványos kimenete is például. Ad absurdum multimédiás és/vagy bináris adatokat is tudhat hordozni.Az Oracle rdbms-ben külön keletkezett XMLtype típusú mezőféleség speciális funkcionalitással, stb.

A könyv első mondhatni bevezető és felcsigázó része:
(1) cikk például a fuzzy adatokat tartalmazó XML adatforrások fuzzy reprezentációjához használható XMLschema lehetőségeit vesézi. Ez önmagában cikk nélkül is egy érdekes gondolat, akkor is ha eddigi életemből a fuzzy-vonulat eléggé kimaradt.
(2) cikk a fuzzyval megspékelt(beágyazott) relációs adatbázisról szól, fuzzy DTD-vel való leképzéssel
(3) cikkben a fuzzy halmazok és hasonlósági relációk szintén egy érdekes téma.
(4) De mindezeket übereli a könyv ezen részének zárófejezete: adatintegráció XML-ek segítségével. Egy ponton túl, ahonnan a relációs ábrázolás már nehézkes, amikor már nem csak az adatok hanem a befoglaló struktúráik is lehetnek képlékenyek, kézenfekvően merülnek fel a XML nyújtotta félig-strukturáltság előnyei, speciális szabályrendszerrel megspékelve. (Érdekesség: integrációs algoritmus alapjának az XQuery-t választották a cikk szerzői!!!!)

A könyv második részében olyan témák kerülnek elő, hogy
(1) ha már az adatok és strukturáik kevéssé fixek (horribile dictu heterogén környezetből származóan), akkor a rajtuk való keresés és join is más megközelítést igényel, ha eredményre akarunk jutni.
(2) cikk azt feszegeti, hogy az XQuery-ből hogyan lesz fuzzy XQuery.
(3) Egy további lehetőség az XML nyújtotta rugalmassági előnyök kiaknázására, amikor relációs adatokat XML-leképezve (ez ugye eléggé könnyedén megtehető, pláne, hogy szigorúbb struktúrából könnyebb áttérni egy megengedőbb struktúrába) egy bővített funkcionalitású lekérdezési interface-t lehet adni az a leképzett adatokra.
(4) Végül a könyv ezen részét lezáró, az első rész szintén utolsó cikkével nagyban harmonizáló deduplikációs cikkfinomság, de erről külön szeretnék beszélni, hiszen őmiatta születik ez a blogposzt.

A könyv harmadik részére megjön az igény, hogy a már meglévő újszerű tárolású és tálalású adataink köré most már kész alkalmazást is kellene építeni.
(1) Itt lehet említeni például  a Fuzzy Process Modellek részére XML-alapú adatcserét.
(2) Sőt lehet XML-alapú keretrendszert építeni inkomplett és inkozisztens adatok menedzselésére (a cikkben konkréten egy klinikai rendszerként).
(3) Sőt nagyot álmodva komplett Fuzzy Adatbázis Architektúra is konstruálható (Alliance), fuzzy-logika technikákkal, XML-bázison.
(4) A könyvet lezáró utolsó cikkben már az indexelés vonatkozásai is hangsúlyt kapnak, a szemantikai feltárással egyetemben.

És akkor nézzük a második rész negyedik amúgy 32(!) oldalas cikkét:

An Overview of XML Duplicate Detection Algorithms.

A magyarul DeDuplikálás vagy röviden DeDup életem meghatározó feladata, élménye. Több ilyen projektben dolgoztam, még többet láttam. Egyszer talán lesz mód, hogy megírjam ebbéli élményeimet, tapasztalataimat.Már többször nekikezdtem egyébként, hogy valamit megírjak belőle ezen a blogon, de akárhonnan közelítettem, mindig túl sok volt az anyag, mindig túlnőttem a képzeletben magam elé állított kereteket, így eddig minden ilyen irányú próbálkozásom kudarcba fulladt.

Pár dolgot viszont mindenképpen érdemes magyarázólag és előljáróban említeni a továbbiakhoz.

(1) Ha az egyik informatikai rendszerben egy urat Szalamander Gáborként, egy másikban Szalamander G.ként tárolják, miközben az anyja neve, személyigazolványszáma stb megegyezik, akkor triviálisan egy és ugyanazon húsvér ember adatai vannak különféleképpen tárolva. Persze nemcsak rövidítés, hanem elírástól elkezdve a legkülönfélébb hibákig sokféle eltérés lehet a rögzített adatokban.Kézenfekvően merül fel a feladat, hogy az egy emberhez tartozó különféle adatrekordokat kapcsoljuk valahogy össze a rekordokban lévő természetes, ám nem feltétlen kitöltött adatok illetve nem feltétlen egzakt egyezés alapján (mivel az amúgy egyébként preciz rögzítésű valamint 100%-os kitöltöttségük miatt jól használható informatikai egész azonosítók eltérnek, így azok nem használhatók a feladatban).Az előbbiek (természetes adatok) alapján a deduplikálásnak komoly nyelvspecifikus vonzatai is vannak, ami magyar nyelvterület esetén - mint sok mindenben így itt is - tudhatnak komoly kihívásokba ütközni (egy példa; Ausztráliában összehasonlíthatatlanul egyszerűbb a lakcímek kezelése)

(2) Ha van egy nagy táblánk, amiben minden húsvér ember minden rekordja szerepel, akkor adatbányász terminológiával élve kezdetben csoportosítást kell végezni a rekordokra, újabb rekordok megjelenésekor meg osztályozást.

(3) A számítógépes/algoritmikus DeDup elméletileg bizonyíthatóan sosem lehet 100%-ban tökéletes. Elsőfajú hibaként tévesen is kerülhet be egy rekord a rekordcsoportba, másodfajú hiba szerint maradhat is ki rekord egy rekordcsoportból.Az ilyen problémák kiküszöbölésére humán erőforrást (brrr) szoktak alkalmazni.

(4) Két adatrekordról eldönteni adatösszevetéssel, hogy akkor most ők egy ember két rekordja szintén nagyon nehéz feladat (gépileg is és kézzel is), alapvetően szabályrendszert szoktak megadni rá. Mivel az elsőfajú hiba a sokkal inkább üldözendő, ezért az ilyen közelítő szabályrendszer alapvetően "szigorú" és kevésbé megengedő szokott lenni (egy csaló ember rekordját egy VIP ember rekordjával nem "praktikus" összevonni). Az összevont/csoportosított rekordokból meghatározni egy "legjobb rekordot" megint nagyon nehéz feladat, amit megint csak közelítőleg lehet megoldani.

(5) A nyers erő (brute force) algoritmus szerint minden rekordot mindenkivel összehasonlítva négyzetes lesz az algoritmus műveletigénye. Mivel többszázezres deduplikálandó ügyfélállományok még Magyarországon sem ritkák, ezért ez az út a lehetetlenség útja, az óriási és elvégezhetetlen számítási igény miatt.

(6) Belátható, hogy a mindent mindennel összehasonlítás túlnyomórészt felesleges is. Tehát az igazi feladat minden szükséges hasonlítást elvégezni a a hasonlítások számának minimalizálásával.


És akkor most már nézzük a DEDUPLIKÁCIÓS CIKKet néhány részletében.

A célkitűzése egyfelöl egy új reprezentáció megadása a deduplikálásra, a hatásosság(=effectiveness) szofisztikáltság értelemben és a hatékonyság(=efficiency) azaz mondjuk most így műveletigény csökkentés jegyében. Majd összehasonlítóan megvizsgál három létező rendszert (DogmatiX, XMLDup, SXNM), amelyek különféle módokon egyensúlyoznak a hatékonyság és eredményesség között. Az első és harmadik struktúra-vezérelt metódus, a közbülső pedig Bayes-hálós.

A cikk nagyságrendi adata szerint 2002 óta évi 600 milliárd dollárt költenek adatminőségi problémákra csak az USÁ-ban. Azaz összevethetőség szempontjából megjegyezhető: a teljes magyar adósság többszörösen belefér ekkora éves(!) összegbe.

Az adatintegráció három lépése:
(1) Séma-megfeleltetés/illesztés és - leképezés (schema matching, schema mapping).
Idetartozik, hogy ha az egyik forrásban név mellett csak az anyja neve van, a másikban meg csak a telefonszám, akkor a közös sémában mindkettő plusz attribútum fog szerepelni
Idetartozik, hogy például ugyf_tel attribútumban (és nem egy másikban) van a szükséges telefonszám adat.
Idetartoznak olyan finomságok is, ha az egyik adatforrásban külön vannak a család- és keresztnevek egy másikban egyben Magyar nyelvterületen olyan típusú "örömökkel", mint például Hunné Zoltán Erika.
(2) A duplikátum-detektálás ezen a fenti közös sémára hozott adatokon.
(3) Az adatfúzió, amikor a szükséges sorok összevonódnak (közös azonosítót kapnak).

Az angol szakirodalomban 1959-től kezdve időrendi sorrendben a következő terminológiák sorolódnak fel a deduplikálásra. :o)
* record linkage
* entity identification
* deduplication
* duplicate detection
* object matching
* entity resolution
* fuzzy duplicate identification
* object consolidation
* reference reconciliation
* object identification

Mivel XML-ben vannak az adatok, rögtön merül fel a kérdés mit nyerünk és veszítünk a relációs módihoz képest.
Előny: sokkal flexibilisebben, korlátok nélkül tárolódhatnak benne az adatok, illetve a hierarchikus (fa)struktúra révén kellemesebb műveletigényű deduplikáló algoritmus lehetősége csillan meg.
Hátrány: jóval nehezebb maga a deduplikálás, az alábbi két probléma mentén
(A) candidate-description ambiguity (én most így mondom, adatszintű többértelműség)
(B) structural diversity (strukturális különbözőség)

Szakirodalom alapján az alábbiak hozhatók fel XML-centrikusan szemlélve a hagyományos deduplikálás történelmi előzményeként. A komponensek kvázi tetszőleges kombinációja megtalálható a cikkben, olykor irodalmi jegyzékes hivatkozással is. :o)
ADAT: (1) relációs tábla (2) Fa például XML-adat (3) Gráf például XML kulcsreferenciák.
ALGORITMUS: (1) Iteratív (2) klaszterező split and merge alapon (3) gépi tanuló algoritmus, ahol a modell is, a hasonlóságmérték (=similarity) is tanulás tárgya
ALGORITMUS FÓKUSZ: (1) Hatásosság, minőség (2) Hatékonyság (3) Skálázhatóság

XML-alapú deduplikálás történelmi előzményei:
* Úgynevezett közelítő (approximate) XML-join, saját - tree edit - távolság-fogalommal.
* Vektorokra leképzés, cosinus távolsággal
* Súlyozott hasonlósági mértékek lineáris kombinációja deduplikációs mezők fontossága alapján
* Ezután robbanásszerűen szaporodtak az olyan XML-alapú deduplikálások, amik egyre jobban támaszkodtak az XML-sajtosságaira (struktúra, szemantika)

Nézzük akkor a beveztőben említett és a cikk fókuszában lévő három algoritmust/rendszert:

Itt egy ábra két node-dal, IMDB filmadatbázisból:

I. DogmatiX Framework

(A) candidate definition, azaz a duplikátum-jelöltek (alap)definiciója, azaz megmondani, hogy az XML-ben mely csomópontok képezik a hasonlítgatások tárgyát. Régi relációs terminológiában annak megmondása, hogy mely mezők alapján hasonlítunk két ügyfél-rekordot (például anyja neve alapján igen, átlagegyenlege alapján nem)

(B) duplication definition, azaz mikor kell összevonni két egyedet (és mikor nem). Természetesen minden fentebb definiált jelöltre megadva. Ez ebben a DogmatiX-ben praktikusan egy Xquery-kifejezés lesz. A query egy (text,xpath) párosba fog leképződni, aminek a hivatalos neve, Object Description (=OD). Példa: U-> ("John S.", /mv/dr/text()) illetve U*-> ("J.Smith", /mv/dr/text()). A dolog első ránézésre ijesztőnek néz ki, de könnyedén algoritmizálható r-távolságban lévő (1) ősökkel, (2) leszármazottakkal illetve (3) k db legközelebbi leszármazottra vett szélességi kereséssel.

(C) duplication detection, azaz hogyan kell duplikátumot találni. Első lépés a szükséges hasonlítások csökkentése egy filter függvénnyel, amely arányt számol a jól ismert IDF-fel (=Inverse Document Frequency) méghozzá egy adott - fentebb definiált - OD és az összes OD vonatkozásában. Pontosabban softIDF-et (attól soft, hogy vannak csak lényegében hasonló elemek, amiket azonosnak vesz). Ezután az - amúgy egy küszöbértéktől függő - filter után minden pár hasonlítódik egymással. Az U és U* hasonlósága (normalizált edit distance), a következőképpen néz ki (a konkrét fenti példánkban)

Sim(U,U*)=softIDF(Pros and Cons)/(softIDF(Pros and Cons)+softIDF(John S.)+softIDF(J.Smith))

Struktúra-vezérelt XML-távolság

Egy javítás lehetséges az előzőhöz képest, mégpedig egy speciális távolságfogalommal, az úgynevezett átfedések koncepció alapján  (=overlay). A fenti ábrán U és U* minden node-ja megfeleltetés révén átfedésbe hozható egymással, az U* egyszem AC2-jét leszámítva (annak nincs párja U-ban).

Egy átfedés akkor komplett, ha nem része másik átfedésnek.
Az átfedés költsége a mappelt node-os string-hasonlítások Levenshtein-távolságainak (~edit distance) összege.
Egy átfedés akkor optimális, ha komplett és nincs más átfedés, alacsonyabb átfedési költséggel.

A mélyben egy rekurzív algoritmus dolgozik gyökérből lefelé haladóan. A node-párosítás pedig az operációkutatásból ismert hozzárendelési problémánál ismeretes úgynevezett magyar módszer alapján történik.

Az állítás az, hogy a téves összevonások jobban elkerülhetők így (bőven elhihető), de meglepő módon kvázi ugyanolyan sőt akár még inkább könnyedén számolható az egész DogmatiX-es cucc az előző távolságfogalommal. Ezt mondjuk én most így hirtelen nem látom át, a cikk meg nem részletezi miért is.


II. SXNM—Sorted Neighborhood for XML Duplicate Detection

Ez a bottom-up metódus úgy próbálja csökkenteni a szükségtelen összehasonlítgatásokat, hogy miután minden hasonlítandó tényezőre kiszámol egy generált kulcsot - például: U{"Pros and Cons", 1983}->PRO83, U*{"Pros and Cons", 1984}->PRO84 - a kapott kulcsokat egyszer még a kezdetek kezdetén lerendezi és minden elemen egyszer végigmenve, minden elemnek csak a közvetlen - fixen rögzített - környezetétbe hasonlítgat bele.(Mj: A módszer magyar nyelvterületen ebben a formában bukásra van ítélve, ugyanis a kedves hölgyek férjhez mehetnek és felvehetik férjük nevét -> Salm Gizella, Matula Gizella). Persze a rendezés utáni műveletigény látványosan csökken a nyers erős módszer négyzetes műveletigényéhez képes O(nlog(n)).

A DogmatiX-hez hasonlóan az OD-k megkonstruálhatók, annyi a nóvum, hogy az OD-hez még relevancia is kapcsolódik pluszba. A hasonlóság elemzés is ugyanúgy mehet Levenshtein-távolságok aggregálásával (súlyozott összeg). Bár a cikk szerzői bedobják az egyébként szintén ismert és használatos Jaccard-távolságot is.


III. Bayes Networks for XML Duplicate Detection (XMLDup)

A cikk abból a tételből indul ki, hogy két node deduplikálandó, ha értékeik azonosak, és a gyerekeik is deduplikálandók - mily meglepő az előzmények után :o) A fenti körmentes irányított gráfos ábra mutat egy példát, hogy hogyan is néz ki ez a korábbi példára vetítve.A bottom-up módszer kellemetessége abban nyílvánul meg, hogy a teljes node-halmaz helyett az egymástól független fontos node-okat veszi csak górcső alá.

Ezek után a klasszikus Bayes háló számolását alkalmazva, node-ok közti "valszínűségpropagálás" a hagyományos módon számolódik, ahogy a fenti ábrán is látszik, mv11 gyökér-node esetén. Ha a kapott érték 0-hoz közeli, akkor teljes a különbözőség, ha 1-hez, akkor meg egyezés áll fenn. Karakterfűzér-hasonlításra e cikk szerzői is a (normalizált) Levenshtein-távolságot használták.


FUTÁSI TAPASZTALATOK:

Adatbázisok:

Hát az látható, hogy túl nagy fába nem vágódik a fejsze.;) Az adatbázisok nagyjából fele-fele arányban tartamaznak duplikátumokat és "szingliket".

IMDB: véletlenszerű válogatás a közismert filmes adatbázisból, attribútumok: title, director, author, year, movie key, rating, genre, keywords, cast member, runtime, country, language, certification

Restaurant. Fodor’s and Zagat’s restaurant guides adatbázisa, attribútumok: name,
address, city, type, phone, code, geographic coordinates

Cora: könyvtári információs adatbázis, attribútumok.: author, title, venue name, volume, date

FreeDB: Ez az audiólemezek népszerű szöveges adatbázisa, kevesebb duplikátummal, attribútumok:  artist, disc title, category, genre, year, CD extra information, track titles

IMDB+FilmDienst:. Véletlenszerű 500 film kiszedése a két adatbázisból. Integrálás után az attribútumok: year, title, aka-title, info, genre, actor


Rendszerek összehasonlítása

A szokásos precision és recall százalékos mértékek alapján

Precision: korrektül eltalált duplikátumok aránya a tesztelendő rendszer által duplikátumnak minősítettekhez képest..

Recall: korrektül eltalált duplikátumok aránya a valós duplikátumokhoz képest.


Futási idők

Nem meglepő módon tarolt az SXNM, ami a deduplikálás minősége helyett inkább a performanciára összepontosított.


DeDuplikálás minősége

A függőleges tengelyre kerül a precision, a vízszintesre meg a recall.Mivel az a jó, ha minden duplikátum megvan és tökéletes duplikátum azonosítás mellett, ezért a cél, a teljes "négyszög" elérése. Az a rossz, ha valaki minél kevésbé tudja a [1,1] négyszöget kifeszíteni. A leggyorsabb SXNM látnivalóan gyengélkedik a deduplikálási minőség terén.


Végső következtetések

(1) Az eredményes deduplikálást nagyban befolyásolja az adatbázisokban lévő hibák típusa. Erre én is tettem személyes megjegyzést/kiegészítést az SXNM elméleti taglalása kapcsán.

(2) DogmatiX nagyon jó deduplikálási minőséget adott, (többiekhez képest) nem annyira rossz futási idők mellett.

(3) A cikk szerzői szerint alapvető hátrány a cikkbeli módszereknél, a különféle paraméterek, súlyok, küszöbértékek, hasonlóságok nem túl egzakt mivolta. (Mj.: szerintem nyugodtan mondhatjuk, hogy ez általános téma egészét érintő probléma és nem specifikus és konkrét módszerek problémája)

(4) Jó lenne elmozdulni a minél egzaktabb és automatikusabb feldolgozás irányába.

+1 blogposztírói morfondírozás

Érdekesek ezek a tudományos kísérleti cuccok. Próbálnak demó méretű adatbázisokon ötleteket kipróbálni több-kevesebb sikerrel. Miközben itthon is, évek óta, nap mint nap, többszázeres ügyfélállományokon kell elviselhető teljes deduplikálást produkálni.

Amit én alapvetően hiányolok az a párhuzamosítás gondolatának teljes mellőzése. Holott skálázhatóság mellett kevésbé lenne releváns a felesleges párosítási igények radikális redukálása - de jó szópáros... :o)))

Mindazonáltal a DogmatiX IDF-es ötlete elött le a kalappal. Az mindentől függetlenül zseniális gondolat egy józan paraszti ész szerint is reális XML-es gondolatkör apropóján.

KDD 2010 konferencia díjnyertes cikkei

.
KDD 2010 hírek szerint az innováció és technikai kategóriában az alábbi két cikk lett a legjobb (ebben a sorrendben). Erről a két cikkről írnék pár szót a múltkori KDD-s poszt és az ott említett beszámoló folytatásaként:

1.
Connecting the Dots Between News Articles

Elérkezett a szép új világ. Nem kis megdöbbenésemre a fenti cikkben egy olyan téma kerül teritékre, aminek már a kiindulását sem értem. Már a mögötte lévő motivácó sem világos számomra. Kommentekben szívesen fogadok ötleteket, hogy miről is lehet itt szó.

Így első olvasatra a szerzők mesterségesen konstruáltak egy problémát, amibe ugyan érdekes gondolatokat gyömöszöltek bele, meg tanulságos reprezentációt abszolváltak, mégis nekem van annyira kulcsfontosságú magának az alapproblémának a megértése, hogy addig nem küzdök l'art pour l'art a mélyebb megértéssel, amíg nem tudom, hogy mit mihez kell kötni.

Miről is van szó...

Adva vannak cikkek. És még csak nem is a könnyebb verzióban (tagelve), hanem pörén, ahogy megírták őket. A feladat, az lenne, hogy mondjuk lakásár-csökkenésről publikáló cikktől eljussunk további cikkeken át mondjuk az egészségügyi reformos döntésről szóló cikkig (Amerikáról beszélünk). Néhány peremfeltétel mellett, úgy mint például, idősorban egymás utániaknak kell lenni a cikkeknek, koherens kapcsolatnak kell a cikek között lenni stb. Azt persze látni kell mindez csak múltra vonatkozik, tehát az nem cél, hogy a másodlagos jelzáloghitel-anomáliákról szóló cikk alapján még időben lehessen következtetni a globális pénzügyi válságra. ;)

Az én kósza gondolataim mi is lehetne motiváció, a cikkbeli példa alapján.

(1) A Google Pagerankes algoritmusa helyett valamiféle tartalom-összefüggés szerinti asszociálás algoritmizálása mint esetleg végcél.

(2) Ha egy felhasználó keres egy témában, és nem gondol egy aspektusra, akkor egy ilyen fentebb vázolt információs lánc révén ráakadhat valamire, amiből ihletet meríthet.

De hangsúlyozom fogalmam sincs. Ahogy arról sem, hogy hogyan kaphatott "best paper" díjat a cikk. Egyáltalán elégséges-e egy ilyen díjhoz egy mesterséges probléma részére konstruált érdekes reprezentáció és rá adott megoldás esetleges frapánssága.

Ha rosszindulatúan cinikus akarnék lenni, akkor ez az egész engem arra a gyerekkori játékunkra emlékeztet, hogy sorbanülve, a lánc egyik végéről indulva egymás fülébe súgunk és amit hallunk azt továbbadjuk a másiknak. És röhögünk a végén egy jó nagyot, hogy mi marhassággá torzul a kiinduló mondat.

2.
Large Linear Classification When Data Cannot Fit In Memory

Ennek kapcsán két érdekes felvetés tud felmerülni.

(1) Van-e egyáltalán olyan probléma ami nem tud elférni értelmes reprezentációval a mai nagyságú memóriákban? A kérdést nyitvahagyva, két szempont azért idesorolható (A) nagytömegű multimédiás adatok adatbányászata. (B) GPU-s algoritmusok, ahol nagyságrenddel kisebb a rendelkezésre álló memória.

(2) A cikk peremfeltételei alapján kézenfekvően merül fel (bennem) a párhuzamos programozásra való asszociálás. Mint az afelé vezető út egyik potenciális állomása. Hiszen amit (A) batchben (B) kisebb feladatokra bontva, (C) véletlen elemi adat elérés nélkül (csak adatblokkal dolgozva) el lehet végezni azt lehet esélyes elvégezni párhuzamosan is, természetesen megfelelő adminisztrálás mellett.

A szerzők nem cifrázták, rögtön az egyik legnehezebb probémát vették alapul (SVM). Az semmi, de a tesztjeik is szépen muzsikáltak a LIBLINEAR-ral hasonlítva. A tesztelés kivitelezhetőségében segítségükre volt a tény, hogy teljesen memóriában is futattható SVM, meg dekomponáltan is. Így az eredmények tényleg összevethetők.

Konklúzió? Ennek a cikknek a díját értem. :o) Még akkor is, ha a cikkben ígért további általánosítás lehetőségének mikéntjét a magam részéről nem látom át.

Ingres VectorWise a RapidMiner előszobájában

.
A társblogon Prekopcsák Zoltán írása alaposan felcsigázta személyemet egyik konkrét információjával.

A jövő évre várható még a RapidMiner alapszoftver 6-os verziója...Az Ingres céggel szövetkezve pedig szorosan mellé integrálják az Ingres VectorWise adatbázis-kezelőt

Az idő szoritásában ugyan, de nem álltam meg, hogy egy picit ne nézzek utána a témának szakmai kiváncsiságomnak, meg régi rdbms-es énem emlékeinek engedve.

Az Ingres egy nagyon jól hangzó márkanév (volt) az adatbázisos világban, amit elsősorban élenjáró nagyszerű innovációjának köszönhetett. A nagy Oracle is csomó dolgot vett át tőlük (hash, ami nagy tábláknál hatékonyabb elérést ad az indexekkel szemben, vagy a CBO/=Cost-Based Optimizing/ az RBO-val/=Rule-Based Optimizing/ szemben). Ezek ma már alapvetőknek számítanak az iparban. Az rdbms-piac sajátosságai (pl.: óriási tehetetlenségi erők) következtében a 90-es évek végére az Informix, aztán meg az Oracle mindkettőt lenyomta a piacon. De ez mit sem von le az Ingres szakmai értékeiből. Aki Ingres-essel találkoztam az mind élvezettel dolgozott vele és beszélt róla.

A társblogos poszt nyomán egyből felcsillant a szemem, hogy akkor egy (open source) adatbányász tool kap egy open source rdbms-t maga alá. Hogy az milyen frankó lesz, mert előfeldolgozás címén (amiben a Rapid Miner, hogy is mondjam finoman -> küzd még kihivásokkal), komplett flexibilis szabványos rdbms-es, szabványos sql-motoros - házon belüli - megoldást kap, gyakorlatilag mondhatni minden igényt kielégítve. Na ez a megközelítésem a felhasználói funkcionalitásos megközelítés. És ahogy jobban utánanéztem a témának, be kellett lássam némileg tévedtem várakozásaimban.

Ugyanis ez az Ingres VectroWise egy performanciára végsőkig kihegyezett analitikus platformos célszerszám, teljesen zöldmezős alapokról felépítve, felpörgetett korunk követelményeit és trendjeit/lehetőségeit figyelembevéve.  Beáldoznak vagy még nem implementáltak sql-világban megszokott dolgokat - némi deja vu a régi select alkérdés nélküli MySql v4 elötti világra -, részint fordítási hibákat részint lassabb futási időket implikálva. Cserébe, ami működik az viszont - ígéret szerint - nagyon, kvázi csodával határos módon - hatékonyan működik. Funkcionalitás kontra performancia. Az Ingres VectorWise a performanciát tűzte ki a zászlajára.

Nézzük, hogyan milyen építőkockákkal akarja ezt a hatékonyságnövelést elérni az Ingres VectorWise:

* Ilyen építőkocka a modern CPU-k azon tulajdonságának kihasználása, hogy vektorokat már jobban kezel mint különálló elemi adatokat. Egyáltalán is megjegyezhető, hogy nagytömegű adatelérésben a háttértár adatblokkjainak elérése a leggyengébb láncszem analitikus adatelérésnél: vagy a leglassabb, vagy a legdrágább (EMC-típusú winchester-szekrényekre gondoljunk elsősorban, amit aranyárban mérnek). A processzorok viszont önmagukban is gyorsak, és darabszám alapján skálázhatók felfelé. Tehát adott az ötlet toljunk át minél több feladatot most így mondom a winchesterekről a processzorok felé.

* Ilyen építőkocka az oszlopalapú tárolás az eléréshatékonyság érdekében. Itt ugye arról van szó, hogy egy 1-5-ig kategóriákat tároló oszlop tárolása egészen másképp néz ki, mint egy változó hosszúságú karakterfűzér tárolása. Analitikus adatelérésnél meg nem egy rekord összes adatára vagyunk kiváncsiak egymás után, hanem a rekordok egy attribútumát szeretnénk egybe látni, aztán a következő attribútumát.

* Ilyen építkocka a radikális adattömörítés lehetősége, köszönhetően például éppen az oszlopalapú tárolásnak is. Hatékony tömörítésnél kevesebb adatblokkot kell felolvasni adatelérésnél a háttértárból némi plusz processzor erőforrás beáldozása árán: de hiszen éppen ez volt az eredeti szándék is.

Ilyenkor kézenfekvő az asszociálás a Netflix-verseny adatbázisára. Ott ugye 1-5-ig voltak ratingek százmilliónyian. Ha jól tévedek kicsomagolva ostromolta a 2GB-ot, amit tömörítve lehetett leszedni a Netflix-verseny honlapjáról, talán 100MB-os nagyságrendben.

Na most egy ilyen Ingres VectorWise típusú szerkezet azt ígérheti hosszú távon, hogy kvázi ki sem kell csomagolni - csak kvázi kovertálni - a letöltött Netflix tömörített adatállományt. A konverzió (adatbázisba töltés) nem úszható meg ugyan, viszont méretben azért összemérhető tömörítvényen is lehet kvázi rdbms-operációkat és analitikus adatelérést kezdeményezni. És persze aztán meg adatbányászkodni rajta.

* Ilyen építkocka a speciális indexépítési és -elérési módok. Például tömörített adatblokkra minimális és maximális érték. Hogy fel se kelljen olvasni szükségtelen blokkokat. Stb.

Két érdekesség:
(1) Egyelőre csak Linuxon érhető el az Ingres VectorWise, de ígéret szerint hamarosan jön - a ráadásul 64-bites - Windows verzió.
(2) Nem ennél az Ingres-cuccnál hanem a rendes Ingresnél láttam, hogy illesztik az Oracle világban fogalomnak számító TOAD-ot. Na attól dobtam egy hátast. :o)

PS: Tudom hogy helyenként sok kvázit írtam, de lássuk be egy csökkentett funkcionalitású sql nem teljes sql, egy adatbázisba töltés sem szimpla konverzió,még ha menedzseri szemlélet keretében el is lehet sütni.

(Gráfelméleti) különbség a férfi és női agy között

Ma kaptam egy Youtube-videó ajánlását. És hogy ne csak komoly dolgok legyenek itt a blogon ezt kivételesen megosztom. 10 perces videó, egy amerikai komikus(?) Mark Gungor beszél érthető angolsággal, de a videó magyar feliratos tehát mindenki élvezheti. Június 13. óta közel 70.000-n látták, ami magyar nyelvterületen nem kevés.


A férfi agy és a női agy

IBM SPSS Modeler v14 - első benyomások

Kicsit hatásvadásztam a címben. :o)

Mint a képen is látható, ez bizony még a régi logó, sőt a régi márkanév. Pontosabban a régebbi. Ugyanis már nem a nagyon jól kitalált Clementine, és még nem a címbeli IBM SPSS, hanem közbülső, tulajdonképpen pár hónapot megélt márkanév. A PASW egyébként a Predictive Analytics SoftWares-ből jön.


A dolog firtatása azért lehetséges egyébként, mert az IBM SPSS Statistics v19-es változata, már nem PASW hanem IBM SPSS logó alatt fut, IBM-es splash-képernyővel, Eclipse-szel felszerelve, jelentősen meghízva.

Nem is mondtam pedig evvel kellett volna kezdenem. Hálás köszönet az SPSS Magyarországnak, hogy rendelkezésemre bocsátott a tárgybeli termékükből egy használható trial-verziót. Ezért jár nekik egy hatalmas piros pont, íme: * És hozzá:
IBM SPSS Clementine/Modeler - SAS Miner = 1:0
Ugyanis ebben az a kevésbé érdekes hogy Clementine-ból kaptam trialt, sokkal inkább az, hogy annó a SAS-tól bár kértem hasonlót írásban, kétszer is, ráadásul árajánlat formájában (tehát nem kunyerálásként), de még csak válaszra sem méltattak. Ők valószínűleg túl magas parnasszuson vannak már ahhoz, hogy az olyan pórnéppel kínlódjanak meg vesztegessék rá drága idejüket, ahová én is tartozom.

Clementine - remélem nem haragszik meg senki, de én így fogok rá emlékezni és hivatkozni továbbra is, mondhatni a mainstreammel szembemenve, legalábbis egyelőre. Különben is a Modeler egy vagy két "l"-je engem halálra idegesít, annál is inkább mert gyarló módon nem tudom, hogy az angol terminológia mikor szereti az egyiket vagy másikat használni.

Az új Clementine-ban két párját ritkítóan nagyszerű finomság van.

(1) Először láttam, hogy a setup DVD-n (ami csak a desktop változatot tartalmazza, a nagyszerűségesen szimpatikus in database miningot is magábafoglaló server változatot nem) egyben van fenn a x86-os és x64-es változat, persze dupla akkora helyet követelve magának a lemezen. Így már érthető az is, hogy miért nem elég már a régimódi CD a telepítéshez. ;)

Ez sokkal fontosabb feature, mint az ember felületes első ránézés után gondolná. Ugyanis, ha van területe az informatikának, ahol a 64-bites architektúra előnyei kidomborodnak, az az adatbányászat, azon belül például az apriori-s alapvetően memóriában dolgozó algoritmusok. 64-bites architektúra sokkal nagyobb címzéstartománnyal bír, következésképpen sokkal nagyobb munkamemória címezhető meg. Persze nem mintha ezt is nem lehetne kinőnie egy adatbányásznak . ;)

Mivel a Clementine java-alapú eszköz, így elvben nem nagyon volt akadálya eddig sem az x64-es futtató engine-nek, bizonyára eddig is létezett. Csak velem szembe most jött először ilyen :o)

(2) Régi nagy vágyam oldódott meg. A táblázatok scrollbarjai végre görgethetők középső egérgombbal. Ez a korai java-sdk-knak volt egy korlátja. Mostanra(?) sikerült végre eltüntetni ezt a hiányosságot.

Ezek kis dolgok. Annyira kicsik, hogy a What's New leírásban nem is kapott helyet, ha jól láttam. De számomra rendkívül fontosak. :o)

És akkor nézzük, hogy a What's New milyen számomra szubjektíve izgalmas újdonságokat ír.Betűhíven lefordítani nem akarnám a dolgot, részint sok is, unalmas is, van erre más alkalmasabb ember is.

Látnivalóan megváltozott a nyitó wizard is. Egy új finomsággal bővült. PASW Modeler Advantage. Vannak olyan "elvetemült" felhasználók, akik mindenféle verziózott csoportmunka keretében az adatbányász streamjeiket (zip tömörítvény PMML-es str-állományokat) nem filerendszerben (mint én), hanem repository meg egyéb helyeken tárolják, meg onnan nyitják meg. Na őket ez biztos lázba fogja hozni. :o)

Látnivalóan megváltozott a kinézet (ami visszaállítható a régire). Ha a középső egérgomb használhatóságának ez az ára, ám legyen. :o) /Csak poén, senki ne vegye komolyan/







Változott a terminológia (egyszerre a Statisticsben és Clementine-ban). Teljes mértékben az előnyére, szerintem. Például a
* TYPE -> MEASUREMENT LEVEL
* DIRECTION -> ROLE
* RANGE -> CONTINUOS
* DISCRETE ->CATEGORICAL
* SET -> NOMINAL
* ORDERED SET -> ORDINAL
* IN -> INPUT
* OUT -> TARGET

Új node-ként bejött az XML. Ebben az a nagyon szimpatikus számomra, hogy míg a régről megszokott .SAV, egy teljesen zárt bináris állomány, addig ez az XML úgy nyílt és ASCII formátum, hogy szintaktikai és valamilyen fokú szemantikai konzisztencia garantálható hozzá.

Új nodeként bejött a LINEAR node, szintén nagyon szimpatikus finomságként. A hagyományos folytonos célváltozós lineáris regressziót lehet boostinggal finomítani (á lá ensemble), hogy az iteratíve további tanítás során a célváltozóhoz további magyarázóváltozók kapcsolhatók. Ily módon a performancia(futási idő) és a modellfinomság széles spektrumán lehet szánkázni. :o)

Bagging és boosting okosságaival azonban a neurális háló illetve a döntési fák is kiegészültek. Classification & Regression Tree, Quest, Chaid, sőt az előbbi kettő felnőtt a CHAID-hez nagy adathalmazok tekintetében is.

Neurális háló ugyanazt az algoritmust kapta, mint ami volt a Statisticsben. Ez mondjuk nem tudom mennyire jó hír. Azért a Clementine-nak nagyon jó neurális hálója volt, míg a régi SPSS neurális hálója árban is, paraméterezhetőségben is, robosztusságban is, stabilitásban is inkább csak követni igyekezett az eseményeket.

Megszünt a GRI-node. Megmondom őszintén én egyszer kísérleteztem annó evvel a node-dal, és az nagyon balul sült el, mert nem bírtam kikeveredni a hibaüzenetek tengeréből. Ez persze bőven lehetett az én hibám is. Az viszont érdekes, hogy az IBM SPSS azt ajánlja, használjunk helyette APRIORI-t, noha abban nem lehet folytonos magyarázóváltozó. Persze ez nem olyan tragédia mint elsőre látszik, hiszen folytonos változókat lehet BIN-elni. Csak hát egy drága eszköztől nyílván nem fapados hackeléseket vár el az ember.

In Database Miningban megjelent a Microsoft Time Series meg Sequence Clustering illetve az Oracle Attribute Importance metódus támogatása. Az előbbi azért érdekes, mert a társblog is megemlítette, hogy a Microsoft zárt nehezen átlátható algoritmusai olykor meglepően jól teljesítenek (döntési fa). Az utóbbi Oracle-s cucc meg azért, mert a számomra legalábbis meglepő MDL=Minimum Description Length algoritmust használja. Egyszer pár hete neki ugrottam a guglinak, hogy ameddig a szemem bírja megnézzem mit is írnak erről. Nekem az jött le, hogy
(1) Van amikor szenzációsan teljesít és van amikor egyáltalán nem
(2) A fentiek éppen ezért nem teszik könnyűvé általános célú eszközzé előléptetését.

Update database on export, olyan update, ami nem droppal és újralétrehozással nyit. Az mind semmi, de új mezővel egészíthető ki a tábla. Mezőtörlésről itt sem szól a fáma. Valahogy a táblák csak nőnek az exabyte-ok világban. :o)

Model nuggetek/"gyémántok" automatikusan hozzáadódnak a streamhez, ahogy kikalkulálódtak. És persze ez is kikapcsolható akinek nem tetszik.

Runtime prompt session és stream paraméterekhez.

A kedvenc olvasmányom az Algorithms Guide 428 oldalról lecsökkent 368 oldalra. Bejöttek az Ensembles algoritmusok, Linear node algoritmusa (hurrá) és bővült két fejezetre a neurális háló körüli dolgok.. Mások például Generealized Rule Induction meg ugye kihullottak.