Category

Python

Könyvmolyproblémák: hogyan választ olvasnivalót egy magyar adattudós?

By | Data Science, Machine Learning, Python | No Comments

Itt a tél, az ünnepek után, a hosszú estéken pedig egyre többen találják meg a kikapcsolódást az olvasásban. A könyvmolyok azonban gyakran találkoznak azzal a problémával, hogy nehéz „spoilermentesen” információt szerezni egy-egy kötetről. Annál pedig kevés bosszantóbb dolog van, mint amikor egy háromszáz oldalas könyvben még a századik oldal körül is olyan dolgok történnek, amiket már olvastunk a fülszövegben. Szabó-Fischer Hanna erre keresett megoldást.

„Persze lehet találni jó fülszövegeket is, de én mára gyakorlatilag teljesen száműztem az életemből őket és igyekszem más forrásból beszerezni ezt az információt. A más forrás pedig nem más, mint a moly.hu közössége” – osztotta meg személyes tapasztalatait Szabó-Fischer Hanna adattudós, a budapesti United Consult szakértője. Mint fogalmazott, a könyvrajongók közösségi oldalán, az egyes adatlapokon a felhasználók címkéket tehetnek a könyvekre (például ifjúsági, kortárs, romantikus, fantasy, regény, novella, vers stb.). Ezek alapján viszonylag jól el lehet dönteni, hogy egy adott könyv tetszene vagy sem.

Az adattudós hangsúlyozza ugyanakkor, hogy a világirodalom olyan kiterjedt és sokszínű, hogy ez a magyar adatbázis és platform természetesen nem lehet „mindenható” a nemzetközi irodalom terén.

„Kiegészítésként a goodreads.com is a kedvenceim között van. Itt viszont sajnos nem létezik a címkézés, ami miatt elég zsákbamacska-szerűen válogatok a könyvek között. Megelégelve ezt az állapotot, arra az elhatározásra jutottam, hogy készítek magamnak egy automata címkéző rendszert” – számolt be elhatározásáról Szabó-Fischer Hanna, aki nem mindennapi projektbe kezdett a „könyvmolyproblémák” megoldására.

A projekt lépései

„Ha mi magunk olvasnánk egy fülszöveget, akkor viszonylag könnyen tudnánk besorolni kategóriákba, de ahhoz, hogy egy program értelmezni tudja, jóval több előkészületre van szükség. Először is kell egy adatbázis, amely tartalmaz sok fülszöveget és a hozzá tartozó címkéket. A program később majd ezekből a példákból fog mintázatokat megtanulni, ami alapján egy ismeretlen szöveget bekategorizál. A másik nagyon fontos lépés a fülszövegek előkészítése. A program nem egy szöveget, hanem szavak összességét fogja látni, ezért biztosítanunk kell azt, hogy a számunkra egyértelműen hasonló jelentéssel bíró szavakat (például könyv, könyvek, könyvről, könyvekről) a gép hasonlónak értelmezze” – ismertette az alapproblémákat a United Consult szakértője.


Szabó-Fischer Hanna a nyers fülszövegtől a működő programig az adatgyűjtéssel kezdve, a szövegfeldolgozáson, majd a dokumentummátrix felépítésén és az osztályozáson át – az ábrán látható folyamat segítségével – jutott el. Lássuk ezeket lépésről lépésre, kicsit a szakmai részletekbe is elmélyedve.

Adatgyűjtés

„Ahhoz, hogy osztályozót építsek szükségem volt egy viszonylag nagy tanulóhalmazra, melyet a moly.hu adatbázisát használva készítettem el. Ezer angol nyelvű könyv címét, fülszövegét és a felhasználók által rájuk aggatott címkéket töltöttem le. A scrapeléshez, azaz a tömeges adatletöltéshez a pythonban megírt BeautifulSoup nevű csomagot használtam” – ismertette a szakértő.

Szövegfeldolgozás

Szabó-Fischer Hanna tapasztalatai szerint a szövegfeldolgozás sokkal hatékonyabban működik angol szövegekre, ráadásul a Goodreads-en is többnyire angol nyelven vannak feltöltve a könyvek, így kézenfekvő volt, hogy angolra optimalizálja a programot.

A szövegfeldolgozáshoz az nltk csomag volt a segítségére, a munkát pedig a fülszövegek megtisztításával kezdte.

Forrás: Towards Data Science

 

„A tokenizálással szavakra bontottam a fülszöveget, majd minden szót kisbetűssé alakítottam, hiszen a szövegfelismerő rendszerek számára például a „Könyv” és a „könyv” sem ugyanaz. Ezután kiszűrtem a “stop szavakat”. Ezek olyan szavak, amik sokszor megjelennek a szövegekben, de önmagunkban nem hordoznak értéket. Ilyenek például a személyes névmások, létigék, segédigék vagy éppen a kötőszavak” – sorolta a lépéseket a szakértő.

Forrás: python nltk packedge


Fontos feladat volt a szavakat és mondatokat elválasztó, tagoló írásjelek értelmezése, kezelése is. A központozásnál és az egyedüli karaktereknél először a különböző szimbólumokat szűrte ki, majd a feldolgozás során egyedüli karakterként megmaradt elemek következtek.

„A lemmatization és a stemming két hasonló eljárás, összefoglaló néven szótövezésnek hívjuk. A lemmatization során minden szó leredukálódik a „gyökér szinonimájára”. A „playing” vagy a „played” például egyszerűen „play” lesz. Fontos kiemelni, hogy a lemmatization során az algoritmus figyel arra, hogy a redukált szó is szótári szó maradjon. A stemming hasonló logikával működik, azzal a különbséggel, hogy itt az algoritmus meghatározott szabályok alapján vágja vagy cseréli le a szóvégeket, így előfordulhat, hogy nem szótári szavakat kapunk eredményül” – ismertette a szövegfeldolgozás fontos mozzanatát az adattudós. Hozzátette: a számok konvertálásánál az arab számokat egyszerűen csak szöveggé kellett átalakítani.

Forrás: Towards Data Science

Dokumentummátrix-építés

Miután előállt a megtisztított adathalmaz, az adattudós elkészítette a szavakból az úgynevezett document-term mátrixot.

„Ez egy olyan mátrix melynek a sorai a dokumentumok – az én esetemben a fülszövegek –, az oszlopai pedig a szavak, amik előfordultak a fülszövegekben. Arra több megoldás is létezik, hogy az adott fülszövegek és szavak metszeteit miként érdemes feltölteni értékkel. A legegyszerűbb verzió, amikor 0 kerül abba az oszlopba, amely szó nem szerepelt a dokumentumban és 1-es oda, amely szerepelt. Ennél egy fokkal szofisztikáltabb módszer, amikor nem feltétlenül 1-es kerül a metszetbe, hanem a szó gyakorisága, az adott dokumentumban” – ismertette a szakértő.

Szabó-Fischer Hanna ugyanakkor nem az előbbieket, hanem egy harmadik féle módszer alkalmazott: úgynevezett tf-idf (Term Frequency — Inverse Document Frequency) mátrixot épített. Itt az egyes cellákba 0-1 közötti értékek kerültek, amelyek önmagukban reprezentálják az egyes szavak fontosságát (gyakoriságát) az adott dokumentumban és a corpusban (szókészletben) is.

Következőféleképpen számolható:

  • t – term (szó)
  • d – document (szavak összessége, itt: 1 db fülszöveg)
  • N – corpus nagysága (az összes előforduló szó száma)

tf(t,d) = t gyakorisága d-ben / összes szó száma d-ben
df(t) = t gyakorisága az összes dokumentumban

tf-idf(t,d) = tf(t,d) * log(N/(df(t)+1))

Forrás:Towards Data Science

Osztályozás

Elkészült a dokumentummátrix, kezdődhetett az osztályozás. A United Consult senior munkatársa a tanulóhalmazból leválasztotta a címkéket, majd felmérte, hogy mekkora volumennel van dolga.

„Nagyjából nyolcszáz különböző címke gyűlt össze az ezer darab könyvhöz. Ezeket gyakoriság szerint sorba állítottam és a legnépszerűbb ötvenből kiválasztottam azt a tizenötöt, ami számomra a leginkább fontos. Minden könyvről eltároltam, hogy a tizenöt címke közül melyik igaz rá, majd a címkékre egyesével építettem osztályozókat. Ehhez az sklearn csomagot használtam. Három féle algoritmussal próbálkoztam (KNeighbors, Naive-Bayes és SVM), és ezek közül az accuracy alapján döntöttem a Naive-Bayes mellett” – avatott be a szakmai részletekbe. Az eredményekről szólva hozzátette: a legtöbb címkére 70-90% közötti pontossággal működtek az osztályozók a teszthalmazon.

Eredmények

Az adatgyűjtés után megvolt a szövegfeldolgozás, elkészült a dokumentummátrix, majd lezajlott az osztályozás is. Már csak a program hiányzott, mely a nyers fülszövegekből címkéket generál. Szabó-Fischer Hanna az alábbi ábrán látható lépések segítségével ezt is megírta:

„Végigfuttattam a Goodreads-en lévő várólistámon, és megállapítottam, hogy tendál az egyhangúság felé. Illene szélesíteni a látókörömet” – összegezte az eredményeket az adattudós.

Néhány példa a program alkalmazására:

„Az eredményekből látszik, hogy vannak bizonyos címkék – kortárs, romantikus, fantasy, ifjúsági –, amiket nagyon jól felismer a program, de azokra, amelyek ritkábban szerepeltek a tanuló halmazban – például humoros, női/férfi főszereplő, váltott szemszög, sci-fi, disztópia –, nem tanult rá olyan jól, és az új fülszövegekre nem alkalmazza ezeket a címkéket” – konstatálta Szabó-Fischer Hanna.

Az okokról szólva megosztotta, hogy az alap tanulóhalmazt a moly.hu-ra angolul feltöltött könyvek jelentették, ebben a körben pedig magasan felül reprezentáltak az ifjúsági és kortárs szerzők könyvei, és talán a szórakoztató irodalom is a szépirodalommal szemben, hiszen ezt az adatbázist a felhasználók készítik, és a fiatalabb korosztályban sokkal valószínűbb, hogy valaki angolul olvas, mint az idősebbek között. Mindezek miatt a háborúkkal, gyásszal, történelmi regényekkel kapcsolatos címkék is kevésbé jelentek meg a tanuló halmazban.

„Javítani a felismert címkék sokszínűségén leginkább a tanulóhalmaz számbeli növelésével és a repertoár szélesítésével lehetne” – zárta a szakértő, aki mindezek ellenére jó szívvel ajánlja az előbbiekben ismertetett módszert arra, hogy bárki spoiler nélkül találjon az ízlésének megfelelő könyvet.

További eredmények:

A kód

Szabó-Fischer Hanna a kódot is megosztotta, hátha valakinek kedve támad továbbgondolni az ötletet. Íme…


# SCRAPE
from bs4 import BeautifulSoup
import requests

# go through links to retrieve blurbs and tags
url = 'https://moly.hu' + link["href"]
r = requests.get(url)

# collect html
soup = BeautifulSoup(r.text, 'html.parser')
cimkek = soup.find_all('a', class_='hover_link')
fulszovegek = soup.find_all('div', class_="text")

# TEXT-MINING
def preprocessing(fulszoveg):
    fulszoveg = lower_case_convert(fulszoveg)
    fulszoveg = tokenizing_own(fulszoveg)
    fulszoveg = stop_words_eliminator(fulszoveg)
    fulszoveg = punctuation_eliminator(fulszoveg)
    fulszoveg = apostrophe_eliminator(fulszoveg)
    fulszoveg = single_char_eliminator(fulszoveg)
    fulszoveg = converting_numbers(fulszoveg)
    fulszoveg = tokenizing_own(fulszoveg)
    fulszoveg = stop_words_eliminator(fulszoveg)
    fulszoveg = lemming_own(fulszoveg)
    fulszoveg = stemming_own(fulszoveg)
    return fulszoveg

# TF-IDF
import collections
# making a dictionary which collects all the words, and collect the doc IDs for every word
DF = {}
for i in range(len(fulszovegek)):
    tokens = fulszovegek[i]

    for word in tokens:
        try:
            DF[word].add(i)
        except:
             DF[word] = {i}

# instead of collecting the doc IDs, we need just the counts for every word
for i in DF:
    DF[i] = len(DF[i])
# all the words (keys in DF)
total_vocab = [x for x in DF]

# calcuating TF-IDF
tf_idf = {}
for i in range(len(fulszovegek)):
    tokens = fulszovegek[i]
    counter = collections.Counter(tokens)
    words_count = len(tokens)
    for token in np.unique(tokens):
        tf = counter[token]/words_count
        df = doc_freq(token)
        idf = np.log((len(fulszovegek)+1)/(df+1))
        tf_idf[doc, token] = tf*idf

    doc += 1

# CLASSIFICATION
from sklearn.naive_bayes import MultinomialNB
from sklearn.model_selection import GridSearchCV

# train/test split
data_train=data.sample(frac=0.8,random_state=200)
data_test=data.drop(data_train.index)

# set X
X_train = data_train.drop([cimkek], axis=1)
X_test = data_test.drop([cimkek], axis=1)

# classifier for every tag
tag_list = cimkek
for tag in tag_list:
    y_train = data_train[tag]
    y_test = data_test[tag]

    parameters = {'alpha': [0.1, 0.5, 1, 1.1, 1.2, 1.3, 1.4, 1.5, 2, 2.3, 2.6, 3, 4, 5, 6]}
    naiveB = GridSearchCV(MultinomialNB(), parameters)
    best_est = naiveB.best_estimator_
    best_est.fit(X_train, y_train)
    y_pred = best_est.predict(X_test)
    print('score', best_est.score(X_test, y_test))

# PRODUCT
processed_text = preprocessing(fulszoveg)
data = instert_into_tfidf(processed_text)
result = auto_tag(data)

 


							
						

DIY filmajánló

By | Data Science, Python | No Comments

Az elmúlt néhány évben az ajánlórendszerek egyre nagyobb teret foglalnak el az életünkben, szinte bármilyen online tevékenységet végzünk jelen vannak. Ott vannak az online kereskedelemben, a hirdetésekben és az ajánlórendszerek segítenek a filmek, zenék kiválasztásában is. Ezen rendszerek célja, hogy releváns elemeket javasoljon a felhasználónak. Data Scientist-ként is előfordulnak olyan feladatok, amelyeket ajánlórendszerek segítségével tudunk megoldani. Most a két hónapos otthon tartózkodásom alatt, nem a munkám kapcsán merült fel ez a problémakör. Miután véletlenszerűen rábukkantam egy filmes adatbázisra, úgy döntöttem építek egy egyszerű ajánlórendszert magamnak, amivel újabb filmeket javasolhatok, a már megnézett filmek értékelése alapján.

Adatbázis

Ezekben a feladatokban sokszor a megfelelő adatbázis hiánya okozza a legnagyobb problémát. Előfordul, hogy adott egy jó feladat, de sajnos nem található hozzá megfelelő mennyiségű vagy minőségű adat. Ennek oka lehet, hogy az adatok nem publikusak, vagy az adatkészlet megszerzése költségesebb, mint a projekt várható haszna. Abba a problémába is sokszor beleütközünk, hogy az adatok nem megfelelő minőségűek, hiányosak vagy nem konzisztensek. Olykor saját magunknak kell létrehozni az adatbázist, ami időigényes és költséges lehet. Szerencsére én rátaláltam egy 2013 óta épülő adatbázisra.

Az általam használt adatbázis a MovieTweetings, egy olyan adatkészlet, amely twitter felhasználók filmes értékeléseit tartalmazza. Naponta gyűjti össze az információt a Twitterről, az olyan jól strukturált tweetek alapján, amelyek tartalmazzák az „I rated #IMDb” kifejezést. Ez az adatkészlet Simon Dooms által végzett kutatás eredménye, amelyet a MovieTweetings: a Movie Rating Dataset Collected From Twitter tanulmány mutat be.

Miután az adatbázis rendelkezésre állt, először is ellenőriztem a használhatóságát. Ehhez megnéztem, hogy egy-egy filmet hányan értékeltek. A legtöbbet értékelt film a Gravity, amely 3086 szavazatot kapott. Ez lényegesen elmarad az IMDb értékelések számától. Sok olyan film is volt, ami nagyon kevés szavazattal rendelkezett, ezért leszűrtem a filmeket azokra, amelyek legalább 100 értékelést kaptak, és így 1644 film maradt az adatbázisomban. Ezután leellenőriztem, hogy hogyan viszonyulnak ezeknek a filmeknek az átlagos pontszámai egymáshoz, amit a Twitteren, illetve az IMDb-n kaptak. A következő táblázatban és ábrán jól látható, hogy érdekes módon az 1644 filmből csak 10 olyan volt, ami esetén nagyobb mint 1 az eltérés az átlagos pontszámok között, holott az IMDb-n nagyságrendekkel többen értékelik a filmeket.

filmek értékelése táblázatban

a Twitter és az IMDb filmértékelések összehasonlítása

Így jól használhatónak fogadtam el ezt az adatbázist és ezzel dolgoztam tovább. Kiszűrtem továbbá azokat a felhasználókat, akik kevesebb, mint 20 filmre adtak értékelést. Így a felhasználók száma 6883 maradt. A kezdeti tábla (twitterdataframe) a következőket tartalmazta: felhasználó (user_id), film (movie_title), értékelés (rating).

Ajánlórendszerek

Az ajánlórendszereknek három fő típusát különböztetjük meg: Az együttműködés alapú, a tartalom alapú és a hibrid módszert, amely az előző két megoldás keveréke.

Az együttműködés alapú megközelítés kizárólag a felhasználók és az elemek közötti korábbi kölcsönhatásokon alapul, új ajánlások előállítása érdekében. Ennek a módszernek a fő gondolata az, hogy a múltbeli felhasználó-elem-interakciók elegendőek a hasonló felhasználók és hasonló elemek megtalálásához és a számolt közelségek alapján a javaslatok elkészítéséhez. Az együttműködési megközelítés fő előnye, hogy nem igényel plusz információt a felhasználókról vagy az elemekről, és ezért sok helyzetben felhasználható. Sőt minél több felhasználó értékeli az elemeket, annál pontosabbak lesznek az új ajánlások.

Ellentétben az előző a módszerrel, a tartalom alapú megközelítés esetén kiegészítő információkra is szükség van a felhasználókról és az elemekről. Ilyen információ lehet az életkor, a nem vagy bármilyen más személyes adat a felhasználóról, valamint a kategória, a rendező, az időtartam vagy egyéb jellemzők a filmekről (elemekről).

Tekintve, hogy jelen helyzetben csak annyi információ áll rendelkezésre, hogy egy-egy felhasználó milyenre értékelte a filmeket, így az együttműködés alapú módszerrel dolgoztam.

Modell

Az együttműködés alapú módszer több fajtája közül a user-user megközelítéssel foglalkoztam. Annak érdekében, hogy új ajánlást nyújtson az adott felhasználónak, megpróbálja azonosítani a leginkább hasonló ízléssel rendelkező többi felhasználót. Ezt a módszert „user központúnak” nevezik, mivel a felhasználókat ábrázolja az elemekkel való interakcióik alapján, és méri a köztük lévő távolságot. Ezután kiszámol egy „hasonlóságot” az adott felhasználó és minden más felhasználó között. Ez a hasonlósági mutató közelinek tekint két felhasználót, akiknek azonos interakciói vannak ugyanazon elemekkel. Miután kiszámította a hasonlóságokat, megtalálja a felhasználóhoz legközelebbi szomszédokat, majd a szomszédok értékelései alapján ajánlja az új elemeket.

Ebben a feladatban új filmeket szerettem volna javasolni egy adott felhasználó számára. Ehhez először, minden felhasználót ábrázoltam a különféle filmekre adott értékeléseik vektoraként. A táblából (twitterdataframe) a vektorokat a pandas.DataFrame.pivot csomaggal hoztam létre, és a hiányzó értékeket kitöltöttem nullával.

felhasználók értékelése a filmekre

Ezek után megkerestem a szomszédokat a K legközelebbi szomszéd (K-nn) módszerével. Az algoritmus célja, hogy a film értékelések alapján megtalálja az adott felhasználóhoz legközelebb álló K számú legközelebbi szomszédot, azaz felhasználót. A szomszédok száma tetszőlegesen választható, figyelembe véve az alapbázis méretét és a feladat célját. Minél nagyobbra választjuk ezt a számot, annál távolabbi felhasználók is bekerülnek, így egyre kevésbé releváns elemeket fog javasolni a rendszer, viszont, ha nagyon kicsire állítjuk ezt a számot, akkor olyan filmeket is javasolhat, amit esetleg csak egy ember értékelt jóra. Itt a szomszédok számát 100-ra állítottam, hogy tényleg jó, de még releváns filmeket javasoljon a rendszer. A szomszédok kereséséhez az sklearn NearestNeighbors csomagját használtam. Alkalmaztam a modellt az adott felhasználóra, így megkaptam a legközelebbi 100 szomszédját.

Miután megtaláltam a legközelebbi szomszédokat, valamilyen módszerrel ki kellett választani a legnépszerűbb filmeket, majd azokat javasolni a felhasználónak, amiket még nem látott. A kiválasztás a céltól függ. Ki lehet választani azokat a filmeket, amiket a legtöbben 10-esre értékeltek, de lehet átlagos pontszám alapján is javaslatot adni. Én a következőképpen súlyoztam a pontszámokat: a rossz értékeléseket bűntettem, az átlagos értékeléseket figyelmen kívül hagytam, a jó értékeléseket pedig jutalmaztam. Ezután a kapott pontokat összegeztem minden filmre. Az így kialakult sorrendből az első 10 filmet javasoltam, amit a felhasználó még nem látott.

Ajánlás

Miután elkészült a modell, teszteltem a működését az általam értékelt filmeken. A következő táblázat azt a 20 filmet és pontszámot tartalmazza, ami alapján a legközelebbi szomszédokat kereste meg a rendszer.

az általam értékelt filmek

Az ajánló az alábbi filmeket javasolta nekem megnézésre:

Knives Out (2019), Avengers: Endgame (2019), Captain Phillips (2013), The Wolf of Wall Street (2013), The Shawshank Redemption (1994), Hacksaw Ridge (2016), American Hustle (2013), The Imitation Game (2014), Prisoners (2013), The Gentlemen (2019)

Mivel csak 20 filmet értékeltem előzőleg, így akadtak olyan filmek az ajánlatok között, melyeket már láttam, ennek köszönhetően tesztelni tudtam a javaslatokat. A remény rabjai (The Shawshank Redemption) és a Kódjátszma (The Imitation Game) kifejezett kedvenceim és a Phillips kapitányt is jó szívvel ajánlanám másoknak, ezért elégedett vagyok a rendszer működésével. Szerencsére azért akadt egy-két újdonság is a javaslatok között.

Felmerült problémák

A legtöbb ajánlási algoritmusban rendkívül óvatosnak kell lenni, hogy elkerüljük a népszerű termékek „gazdagabbá válását”. Más szóval, hogy rendszerünk csak népszerű elemeket javasoljon, és a felhasználók ​​csak olyan ajánlásokat kapjanak, amelyek rendkívül közel állnak azokhoz, amelyeket már kedveltek, ezáltal nincs esélyük megismerni új elemeket. Ennek elkerülésére növelhetjük a szomszédok számát, vagy az adott felhasználó értékelési listáját bővíthetjük változatosabb filmekkel.

A másik probléma, ami felmerült miután több kollégámnak is ajánlottam filmeket, hogy az egyik kollégám az 1644 filmből 1354-et látott és értékelt. Mivel az adatbázisban a következő legtöbbet értékelt felhasználó 869 filmet látott és 500-nál több filmet csak 13 felhasználó értékelt, így a szomszéd keresésnél csak egészen távoli szomszédokat talált hozzá az algoritmus. Valamint az ajánlható filmek listája nála lecsökkent 290-re, ezért nem biztos, hogy a legrelevánsabb filmeket ajánlja neki a rendszer. Ennek a problémának a megoldására az adatbázis növelése lenne a megoldás, ami költséges és időigényes lenne, de szerencsére ez ritka eset.

Lehet Magyarországon adatokkal védekezni a járvány ellen?

By | Big Data, Cloudera, Data Visualization, Machine Learning, Python, Spatial data | No Comments

A kezdeti nehézségek ellenére meglehetősen jól alkalmazkodtunk a körülményekhez és – bár a többség számára nehezen érzékeltethető – de az IT világában igenis folyik a munka. Sok esetben meglehetősen hatékonyan. Egyik véglet, amikor munka közben négy gyereket kell menedzselni egy 80 nm-es lakásban, ahol a 2 nm-es erkélyre lehet maximum kimenni, a másik véglet a szingli életmód egy belvárosi lakásban, ahol hetek óta senkivel sem találkozol. Mindkettőre könnyű példát találni. Meggyőződésem, hogy egyik sem tartható fenn huzamosabb ideig anélkül, hogy valakinek az idegállapota ne változzon jelentős mértékben. Az előrejelzések alapján azonban a jelenlegi állapot hosszú hetekig még fenn marad, hiszen ha lazítanak a szabályokon, akkor a vírus terjedése elindul. Idén tehát valószínűleg sokaknak elmarad a nyár vagy a saját lakásra/kertre, esetleg nyaralóra, de mindenképpen a szűk családi körre koncentrálódik.

Hatékony járványkezelés, lehetséges?

A híreket olvasva kerestem példákat, hogy más országokban mi a helyzet. Azt már tudjuk, hogy hogyan ne kezeljük a helyzetet, látva az olaszországi, spanyol és francia példákat, ahol százak halnak meg naponta a vírustól. Vajon azt tudjuk hogyan lehetne másképp, jobban kezelni, hogy a vírus ne terjedjen, ugyanakkor a korlátozások se legyenek ilyen drasztikusak? Van erre példa, méghozzá Dél-Korea.

Dél-Koreában ugyan több, mint 9200 fertőzést regisztáltak (2020. március 26-i adat), a lakossághoz és a népsűrűséghez mérten ez egyáltalán nem sok. A megdöbbentő azonban, hogy milyen gyorsan úrrá lettek a vírus terjedésén: február 20-án regisztálták hivatalosan az első fertőzötteket és március 4-én már meg tudták törni a lendületet, majd 8-án újra egy törés, március 12-e óta pedig átlagban, kevesebb, mint 100 új esetet regisztrálnak naponta.

Sum Cases South Korea COVID-19
Daily Increase South Korea COVID-19

A Wikipédia szerint Dél-Korea lakossága körülbelül 51 millió fő, 1960 óta megduplázódott. (Érdekesség, hogy eközben, a hasonló népességű Irán lakossága majdnem megháromszorozódott.) Földrajzilag szomszédos Kínával (ahonnan a vírus elindult), de közvetlen szárazföldi kapcsolata Kínával nincs. Szárazföldi kapcsolata Észak-Koreán keresztül van, Észak-Korea zártsága miatt arra viszonylat kevesen járnak. Így a határai jól kontrollálhatóak, vízi és légi kikötőkre korlátozódnak. Azonban nem ennek a sajátos helyzetnek köszönhetik, hogy ilyen jól kordában tudták tartani a vírus terjedését. A háborút még ők sem nyerték meg, de sok csatát már megnyertek és jók a kilátásaik a végső győzelemre.

A Max Fisher NYT újságírójának beszámolója alapján Dél Korea a felkészültségének és a hihetetlen professzionizmussal végrehajtott „hadműveletének” köszönheti a hatékony védekezését. A „hadművelet” négy fontos részből áll:

  • Gyors beavatkozás, még a krízishelyzet kialakulása előtt (Lee Sangwon, an infectious diseases expert at the Korea Centers for Disease Control and Prevention said: “We acted like an army,”)
  • Korai tesztelés, gyakran és biztonságosan (hogy nehogy az orvos/nővér is megbetegedjen)
  • Kapcsolatok követése, izolálása és megfigyelése
  • Lakosság segítségül hívása, bevonása

Ezen pontok egyike sem egyszerű önmagában, de mind a négy pont hatékony végrehajtása és összehangolása nagyon komoly felkészültséget feltételez. Dél Koreában valószínűleg tanultak a 2002-2004-es első SARS hullámból. Sajnos vagy szerencsére abból Magyarország, de még a teljes Európa is majdnem kimaradt, az EU-ban mindössze Franciaországban volt halálos áldozata és a legtöbb országban hivatalosan nem is jelent meg a fertőzés. Dél-Koreában viszont igen, igaz csak 3 igazolt esetben.

Ennél is talán fontosabb a 2012-ben kirobbant Közel-keleti légúti szindróma (MERS) járvány, ami Dél Koreát 2015-ben érte el és “küldött” közel 6800 főt karanténba.

MERS Worldwide
MERS in South Korea

Forrás: https://en.wikipedia.org/wiki/2002%E2%80%932004_SARS_outbreak

Feltehetőleg ez készítette fel a koreai hatóságokat, hogy hogyan kell védekezni egy világjárvány ellen, hogyan védjék meg a lakosságot, főként azt a ~13,6%-ot (~7 millió embert), aki 65 éven feletti.

Az első két pont (gyors beavatkozás, gyors döntéshozatal, jó stratégia megalkotása és a korai tesztelés) abszolút a felkészültségről szól. (Van-e például a raktárban tömegesen olyan teszt, ami kimutatja a vírust?) A negyedik pont számomra evidens egy hatékonyan működő társadalomban a tájékoztatás, a kommunikáció nagyon fontos, hiszen bármit kitalálhatsz, ha az embereket nem tudod magad mellé állítani, akármilyen jó is az ötlet, nem fog működni.

Technológia jelentősége a járványkezelésben

A harmadik pont az ami engem érdekel, technológiai szempontból ez a legérdekesebb. Hogyan tudunk egy 51 millió fős lakosságot hatékonyan lekövetni, izolálni és megfigyelni?

A válasz nem is olyan bonyolult az adatok világában. Egyrészt nem 51 millió embert kell egyszerre megfigyelni, csak azt, aki közvetlen kapcsolatba kerül olyan emberrel, aki fertőzött. Miután a tömeges teszteléssel hatékonyan beazonosították egy adott területen, hogy ki a fertőzött és ki nem, már csak azokra kellett koncentrálniuk, aki fertőzött. A mobiltelefonok világában technológiailag nem túl bonyolult lekövetni, hogy ki merre jár. A Google Maps Timelineon például most is meg tudom nézni, hogy két éve március 15-én éppen merre jártam. Sőt még azt is, hogy mivel közlekedtem: gépkocsi, kerékpár vagy gyalog. Persze ez nem mindenkinél engedélyezett és egy más kérdés az, hogy kivel osztom meg, de a mozgás követése évekre visszamenőleg adott, hiszen egy globális helymeghatározó eszközt hordanak az emberek a zsebükben, aminek neve: okostelefon. Mindegy, hogy Android vagy iOS, legfeljebb az a különbség, hogy melyik gyártó szerverére küldi az adatokat, ha nincs ez a funkció letiltva.

Maps Timeline Example

Magyarországi helyzetkép

Jelenleg 5,3 millió (~57,4%) okostelefon használó van Magyarországon, úgyhogy ezzel még nem oldottuk meg fertőzöttek követését, csak nagyjából minden másodikét, feltételezve, hogy megkapjuk az engedélyt az adatok beszerzésére.

A GPS koordináták követésén kívül van azonban egy nem közismert, de más kontextusban gyakran használt megoldás. Bárkinek a mozgása, aki mobiltelefont használ a mobilhálózaton keresztül, ha nem is GPS pontossággal, de lekövethető. Az adatok magyarországi használata nem is példa nélküli, a Nemzeti Turisztikai Ügynökség például vásárolt és elemzett ilyen adatokat nem is olyan régen.

A pontosság a hálózat sűrűségétől és a beállításaitól persze nagy mértékben függ, de a célnak megfelelő és azt a tévhitet is el kell vetni, hogy csak azok a mobiltelefonok követhetőek le, amelyek éppen hívásban vannak. Minden bekapcsolt állapotú mobiltelefon lekövethető. Erre egyébként a hazai mobilszolgáltatók céges gépjárműflotta követésére már több, mint 10 éve nyújtanak szolgáltatást (Mobil Flotta, Flotta Helymeghatározó vagy Flottakövetés).

Itt jön képbe a Big Data

Tegyük fel, hogy az adatok elérhetőek. Innentől egyszerűen csak össze kell vetnünk a koordinátákat időben és térben és le kell fejlesztenünk az algoritmust, ami akár valós időben megmondja, hogy egy kiválasztott időpontban ki találkozhatott az útja során fertőzött személlyel. Ha ezt a megfigyelt körnél automatikusan végezzük az elmúlt két hétre, akkor az eredmény a másodperc töredéke alatt lekérdezhető. Igen, akár Magyarországon is!

Az adatok hatékonyt tárolását számos Big Data megoldás támogatja, és kapacitáshiányban sem szenvedünk a felhőmegoldásoknak (például AWS, Azure, GCP) köszönhetően, de ha például ez nemzetbiztonsági kockázatot jelent, akkor építhetünk magunknak Hadoop rendszert, például egy on-prem Cloudera clustert, amit “olcsó” hardveren üzemeltethetünk és tárolhatunk benne akár petabyte (10^15 byte) méretű adathalmazt is, amelyet másodpercek alatt fel lehet dolgozni.

Megtalálni a megfigyelt személy útját keresztező személyeket nem triviális. Számos oldalról meg lehet közelíteni és kis kutatással, kész algoritmust is találhatunk az Interneten, például itt. Az algoritmus (akármilyen hatékony is) feldolgozó-kapacitást igényel, de ez 2020-ban szintén nem lehet akadály. Megfelelően méretezett on-prem clusteren vagy a felhőben elérhető a megfelelő “processing capacity”. Sőt manapság már a tárolás és a feldolgozás nem feltétlenül kell egy helyen legyen, “csak” a két hely között mozgatott adatmennyiségre kell figyelni, hogy a hatékonyság ne vesszen el. Költséghatékonyan megoldani persze semmit sem egyszerű, de nem is lehetetlen. Minden technológia és tudás is adott hozzá a csapatunkban.

Az algoritmus eredménye birtokában, akár a fertőzési valószínűséget számító Machine Learning modellekkel, SMS formájában értesíthető minden potenciálisan érintett személy és ezáltal elirányítható egy tesztközpontba.

Személyiségi jogok

A járványkezelés kapcsán sokszor felmerül a személyiségi jog kérdésköre, úgy ahogyan bármilyen üzleti célú adatgyűjtés, BigData és Machine Learning alkalmazása kapcsán is.

Véleményem szerint a járványkezeléssel kapcsolatban, ahol a hatékonyság elmaradása emberéleteket követelhet – szemben mondjuk egy üzleti alkamazással, ahol “egyedül” a profit áll szemben a jogokkal – a társadalmi igény magasabb szintet kell, hogy képviseljen, mint az egyén személyiségi joga.

Ettől a morális vitától függetlenül, a vázolt technológiai megoldás, a cellainformációkon alapuló kontakt kutatás anonimizált módon tudna zajlani. A szolgáltatók az adatvagyonnal jelenleg is rendelkeznek és úgy vélem, hogy az adatok anonimizált “átadása” egy központi járványkezelő szerv számára semmilyen törvényi akadályt nem sértene, de ennek a kérdésnek a megválaszolása természetesen már a szakjogászok feladata.

Hogyan tovább?

A koronavírus kapcsán talán már késő egy ilyen megoldás megvalósítása, de addig érdemes a témát napirenden tartani, amíg forró, hiszen egy esetleges következő járvány során a megvalósításba fektetett költségek elenyészőek ahhoz képest, hogy akár a társadalom az emberéleteken keresztül, akár a gazdaság a szigorú és hosszan tartó korlátozások hatására mekkora károkat szenvedhet el.

A dél-koreai példából is jól látható, hogy ha erre valaki fel van készülve és tömegesen, hatékonyan tudja végrehajtani a védekező intézkedéseket, akkor a járvány komolyabb korlátozások nélkül, meglehetősen rövid idő alatt kordában tartható.

Azt hiszem egyik ország sem kezelheti másként a helyzetet, legfeljebb ellaposíthatja a szigorú intézkedésekkel a vírus terjedésést, és elodázhatja ezeket a feladatokat. Hosszú távon – véleményem szerint – ez a rendkívüli állapot nem fenntartható anélkül, hogy komolyabb – nem feltétlenül közvetlenül a vírus okozta – károkat szenvedjünk. Így vagy úgy, mindenesetre jobb ha megtanulunk mindezzel együtt élni.

Python, vagy R?

By | Data Science, Python, R | No Comments

Bevezetés

Gyakran előkerül a kérdés, hogy melyik nyelvet érdemes választani adatelemzési/adatbányászati (data science) feladatokra. A válasz természetesen az R, Python, hogy attól függ, melyik nyelv fedi le jobban az üzleti és fejlesztői igényeket.

Egyes data science csapatokban az R és a Python megfér egymás mellett, a vezetők mégis gyakran teszik le a voksukat az egyik nyelv mellett a könnyebb adminisztráció (azonos kódbázis), oktatás/mentorálás, stb. miatt. A vitát azonban Wes McKinney (korábban a Cloudera, Two Sigma fejlesztője, az egyik legnépszerűbb csomag, a Pandas alkotója) és Hadley Wickham (RStudio, a ggplot2, tidyverse csomagok fő szerzője) örökre lezárná. Ez a cikk a clickbait cím ellenére nem hivatott állást foglalni egyik nyelv mellett sem.

Átjárhatóság a két nyelv között

A csomagok fejlesztésekor az R gyakran szembesül a Pythonhoz hasonló problémákkal (pl. memóriában történő adatfeldolgozás), ezért célszerűvé vált a közösségek közt egy szorosabb együttműködés. A cél, hogy az egyes funkciók R-ben és Pythonban is egyaránt jól működjenek. Erre remek példa a két deep learning csomag, a tensorflow és a keras. A két nyelv közti átjárhatóság minden data scientist érdeke: pl. a Spark rendelkezik Python és R API-jal is (PySpark és SparkR), az átjárás a két API között azonban gyakran memória-, illetve teljesítményproblémákat okozhat. A témához kevésbé jártasak ezt tévesen úgy konstatálják, hogy a Python, vagy az R lassú, pedig csak egy közös

Ursa Labs

Wes 2018 májusában az RStudio és a Two Sigma segítségével megalapította az Ursa Labs-et, mely platformfüggetlen data science megoldásokat fejleszt. A projektben technikai tanácsadóként részt vesz Hadley Wickham, így garantálva lesz, hogy az R felhasználók igényeit is kielégítik. Adminisztrációban, HR területen, illetve finanszírozásban az RStudio segíti az Ursa Labs-et, ezzel is megerősítve, hogy a nyelvek közti háborúnak semmi értelme: mindkét közösség fejlesztői ugyanazon célért dolgoznak, a data scientist-ek munkájának megkönnyítésén.

Az Ursa Labs termékei nyílt forráskódúak, és az alábbi nyelveken érhetők el:

A projekt főbb témái közül néhány:

  • Hordozható C++ könyvtárak az adott nyelvekhez (Python, R, Ruby, stb.)
  • Átjárhatóság biztosítása meglévő adatmegjelenítések között (pl. data frame R-ben, pandas / NumPy Python-ban).
  • Új frontend interfészek a nyelvekhez (pl. dplyr R-ben, pandas fejlesztése Python-ban)
  • Hordozható több szálon futó Apache Arrow-alapú végrehajtó motor (Big data)

Összegzés

Az Ursa Labs egy remek kezdeményezés a két közösség összekötésére. A Python és az R csak eszközök a data scientist-ek kezében, de a cél közös. És ki tudja? Lehet pár év múlva már nem lesz ennyire izgalmas a kérdés, hogy melyik nyelvet érdemes választani…

Ha tetszett a cikk, iratkozz fel hírlevelünkre (a jobb felső sarokban az “értesítésre” kattintva), vagy kövess minket LinkedIn és Facebook csatornákon!

 

További adatokkal kapcsolatos bejegyzéseinket itt találod:
https://datandroll.hu/

Itt pedig cégünk más témában megosztott tartalmait tekintheted meg:
https://united-consult.hu/category/cikkek-rolunk-es-masrol/