Magamról

Saját fotó
Főiskolai, majd egyetemi diplomamunkáimtól kezdve világ életemben, adatok, adatbázisok, adattárházak (leginkább Oracle) környékén mozogtam. Mostanság adattárházasként, adatbányászként élem napjaimat.

2010. október 4., hétfő

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.

Nincsenek megjegyzések:

Megjegyzés küldése