7 gyakori adatminőségi probléma

“Nagyon jó adataink vannak!” – literally minden manager ever, mielőtt átad egy rakat rosszminőségű adatot

Tanácsadóként már többször is találkoztam olyan projekttel, ahol a felelősök meg voltak győződve, hogy szuper adatszettel rendelkeznek. Amikor megkaptam az adatot, derült ki, hogy az adat nagy része nem, vagy csak nagy erőbefektetéssel tehető használhatóvá.

Nyilván ez a 7 pont nem fed le minden problémát, nem esik szó például a mintavételezési hibákról, nonstacionaritásról vagy épp a heteroszkedaszticitásról – próbáltam olyan dolgokat felhozni, amikkel gyakran találkozom a munkám során, de kevés cikket láttam róluk.

Rosszul definiált értékek

Hacsak nem szabadszöveges értékről van szó, mindenkinek ajánlom, hogy ha van értelme, előre határozzák meg a lehetséges értékeket.

Míg egy-egy „Takács” érték a „Kor” mezőben nem fogja tönkre tenni az adathalmazt, ha egy USA-ból származó táblázat „State” mezőjében több, mint 3000 különböző értéket találunk (true story), az iszonyatos fejfájást és időveszteséget fog jelenteni az adatok előkészítésekor. Ha megvan, hogy 50 állam közül lehet választani, ne hagyjuk, hogy a felhasználónk széttrollkodja a „Michigan”-t MI, Mich, mich, Michig., micih, Michigna stb. értékekkel!

Túlkódolt értékek

Igen, az adatbiztonság rendkívül fontos. Nem csak törvényi, de etikai szempontból is kötelességünk biztonságosan kezelni a ránk bízott adatokat.

Ennek az egyik módja az adatok elkódolása. Mi ML-szakértők gyakran dolgozunk elkódolt adatokkal, például Budapest helyett csak „02954” értéket látunk (és fogalmunk sincs, hogy ez Budapestet jelenti), ezzel tudunk is így dolgozni. A probléma ott kezdődik, ha mondjuk ügyfelenként egyedi kódolást használ a megrendelő, azaz az adathalmazban az egyik ügyfélnél „02954” jelenti Budapestet, a másiknál pedig „007954999”.

Ha adatelemzéskor 500 ügyfélről azt látjuk, hogy 500 különböző magyarországi megyében élnek, nem csak a hajunkat fogjuk tépni, de semminemű földrajzi következtetést nem fogunk tudni modellezni – márpedig nem mindegy, hogy Budapesten kiadó lakás iránti érdeklődést szeretnénk előre jelezni, vagy Kisfelsőalsókapukarattyán kiadó lakás irántit.

Információtartalom nélküli adatok

A legtöbb manapság használatos machine learning modell nagyban támaszkodik a nagymennyiségű adatra ahhoz, hogy megtanulja az adatszett mintázatait.

Ez azonban nem jelenti azt, hogy több adat = jobb modell.

Sok esetben találkoztam már olyan adathalmazzal, ahol rengeteg oszlop volt, ami fontos valamilyen szempontból valakinek, viszont az adott felhasználási esetre semmilyen pluszinformációval nem szolgált. Ekkor az lehet a hamis meggyőződésünk, hogy hát van rengeteg adatunk, tuti jó lesz rá az ML – de hiába van rengeteg oszlopunk, ha mindenféle ID-k, hivatkozási számok meg kulcsok vannak lementve. Vagy olyan adatok, amelyek nem relevánsak a feladathoz.

Például, ha a célod a bejövő rendelések előrejelzése, a modell számára irreleváns lesz, hogy a rendelésazonosító „rend-789”, a táblázat idegenkulcsa „kulcs104” és Pápua Új-Guinea lakossága 8.776 millió volt 2019-ben. (És ha a végén kiderül, hogy Új-Guinea lakosságának a növekedése a legjobb előrejelzője az esős napok számának Magyarországon, ne az ML-szakértődre akadj ki!)

Ugyanez igaz a duplikált oszlopokra, amikor például van egy „Ország” és egy „Ország (rövidített)” oszlopod. A modell semmivel többet nem fog tudni tanulni a vásárlóid szokásairól abból, hogy „Mianmar”-t „MIA”-nak rövidítik a ti adatbázisotokban (és egyenesen káros lehet, ha az „Ország (rövidített)” oszlopban 100 különböző érték van, az „Ország” mezőben meg 200…). Ha több ilyen oszlopod is van, az megint csak azt a hamis látszatot keltheti, hogy „sok jó adatod” van, pedig valójában csak rengeteg redundáns adatod van.

Túl sok hiányzó érték

Az előző ponthoz kapcsolódik ez is, ugyanis ránézésre megint csak lehet, hogy sok adatod van, hiszen a táblázatod 100 oszloppal rendelkezik. Ha viszont 80 oszlopban az adatok nagyrésze „NaN”, azaz hiányzó adat, azokat szinte azonnal ki is lehet dobni. A maradék 20 oszlopra meg sanszos, hogy olcsóbb és szinte ugyanolyan hatékony lesz egyszerűbb módszereket használni deep learning helyett.

10 oszlop - 3 használható (és az sem az igazi). Kép forrása: datachant.com

Túl sok táblázat

Sokszor indokolt lehet 20-30 táblázatot létrehozni egy-egy use case-re, viszont az ML-szakértőd tuti ki fog akadni (még ha nem is mondja majd). Mi szeretjük a szépen, egy DataFrame-be összeszedett adatokat. Ráadásul szinte biztos, hogy a saját adatbázis-szakértőid jobban fogják érteni az adatbázisodat, mint az ML-szakértő, aki épp most találkozik vele először. Nyilván neki is meg kéne tudnia csinálni az adatok összevonását, viszont a szakértelmét hatékonyabban ki tudod használni, ha legalább valamennyire előkészíted az adatokat neki.

Rosszul tárolt adatok

Minden adattípusnak megvan a hozzá tartozó legideálisabb tárolási fajtája. Ha strukturált adataid vannak, tárold valamilyen táblázatos adatbázisban. Ha nem-strukturált, ajánlott valamilyen NoSQL-adatbázist választani. Manapság egyre izgalmasabb dolgokat érnek el gráfadatbázisokkal is (ha ez a téma érdekel, ajánlom, keresd meg Vass Bence barátomat!). Ha még mindig Excel-ben vezeted az összes adatodat, még akkor is menthető a helyzet, onnan könnyen lehet CSV-fájlokat generálni, ami jól jöhet a modell tanításakor.

Ha még mindig papíron vezeted az adataidat, akkor viszont nem machine learningre van szükséged.

És ha valaki azt mondja, hogy papírról machine learninget csinál neked: FUSS.

Hiányzó dokumentáció

Sokan azt hiszik, elég a sok adat, rádobunk egy deep learninget, és az 95%+ pontossággal működni fog. Sajnos nem ez a helyzet. Még mindig nagyon fontos, hogy aki dolgozik az adatokkal, az megértse, mik is azok az adatok. Egy jó dokumentáció kulcsfontosságú lehet egy projektnél.

Alapszabály, hogy nem szabad függőváltozót a tréninghalmazban tartani – ha azonban nem tudjuk, mi függő, és mi független változó (mert nincs egy rendes dokumentációnk), könnyen hamis eredményeket kaphatunk. A függőváltozók ugyanis a célváltozónkra utaló adatokat is hordozhatnak (vagy rosszabb esetben egyenesen abból vannak kiszámítva), azaz a modellünknek tanításkor aranytálcán kínáljuk a megoldást is – és semmit nem fog megtanulni, mégis 99%-os pontosságot fog elérni.

Példával talán egyszerűbb: Legyen egy táblázatunk, amiben benne van a havi bevétel, a havi bevételi cél és a havi teljesítmény (hogy hány százalékát teljesítettük a bevételi célnak). Cél a havi bevétel előre jelzése. Ha ezeket az oszlopokat mondjuk bev-nek, bev_perc-nek és bev_t-nek hívják, dokumentáció nélkül könnyen megeshet, hogy a bev_t (a tervezett bevétel) és a bev_perc (a havi teljesítmény) is benne marad a tréninghalmazban. Azaz a modellnek az égvilágon semmit nem kell megtanulnia, csak kiszámolni a tervezett bevételből és az elért teljesítményből a valós bevételt, és puff! van is egy 99%-os modellünk.

Előbb-utóbb észre fogjuk venni a hibát (nyilván az aktuális havi adatok közt nem lesz még meg a havi teljesítmény), de addigra már lement többhavi fejlesztés és 5 felsővezetőségi prezentáció, ahol – hamisan – azt állítottad, a modell 99%-os pontossággal fog működni prod-ban. És ekkor nem hibáztathatod az ML-szakértődet, mert a dokumentáció nélkül egyszerűen nem tudhatta, hogy függőváltozókat hagyott a tréninghalmazban.

Legyen egyelőre ennyi, ha szeretnél olvasni még több adatminőségi problémáról, jelezd like-al, megosztással vagy kommenttel! Remélem, tudtam segíteni, és így már el fogod tudni kerülni ezeket a hibákat, hogy gyorsabban és kevesebb pénzért legyen kész az ML-megoldásod!