Category

Data Science

Megjósoljuk, hogy megjósolják – Facebook Prophet

By | Big Data News, Business, Data Science, Data Visualization | No Comments

Az elmúlt hetekben alapjaiban forgatta fel társadalmunkat és világról – különösen annak biztonságáról – alkotott képünket a Kínából indult koronavírus-járvány, és persze a globális felmelegedés témája is folyamatosan foglalkoztatja a közvéleményt.

A 21. században egyre nagyobb jelentőséggel bírnak és egyre pontosabbak a különböző prognózisok. Vajon az ezek mögött álló előrejelző algoritmusok tényleg alkalmasak arra, hogy megbízható információkkal szolgáljanak például az időjárásról, a közúti forgalom, esetleg a részvényárfolyamok alakulásáról, vagy akár a járványok terjedéséről? Erre is választ keresünk a Facebook Prophet gyakorlati bemutatásán keresztül.

Nem kérdés, hogy mindennapi életünket egyre jobban befolyásolják a különböző előrejelző algoritmusok. Elég, ha csak az időjárás-előrejelzésre, a forgalmi prognózisokra vagy a részvényárfolyamok előrejelzésére gondolunk. „Vajon milyen idő lesz holnap? Ha holnap arra indulok kocsival, vajon dugóba kerülök? Vajon most érdemes beszállni ebbe az üzletbe?” – annyira gyakorlatias kérdések ezek, hogy akár az elmúlt fél órában is hallhattuk volna valakitől, vagy akár mi magunk is feltehettük volna bármelyiket.

Még ha nem is tudatosul bennünk, számos előrejelzést „futtatunk” magunk is: korán indulunk, hogy legyen hely a munkahelyi parkolóban, hogy ne kelljen sorba állni a menzán; esetleg megpróbáljuk egy korai vagy éppen késői hazaindulással a dugót elkerülni; és így tovább. Mindez tapasztalataink alapján az esetek többségében működik is, ha pedig tévedünk, olyan nagy kockázattal jellemzően nem jár.

Amikor az adatok jóslásának következménye van

Az üzleti életben az előrejelzések ennél sokkal racionálisabban működnek, és persze nagyobb téttel is bírnak. A forgalmi adatok előrejelzése például egy rendszerüzemeltetéssel foglalkozó vállalatnál kulcsfontosságú. Még ha tudnák is úgy méretezi a rendszereiket, hogy azok az elképzelhető legnagyobb forgalmat is elbírják, nem lenne költséghatékony azt mindig a maximális kapacitáson üzemeltetni. Ehelyett inkább a korábbi minták alapján próbálják megbecsülni a várható forgalmat, és az IT-infrastruktúrát az előrejelzéshez méretezni. Szerencsére az elasztikus skálázhatóság ma már nem probléma.

Egy call centernél sem mindegy, hogy mikor hány operátor dolgozik. Az sem volt mindegy, hogy a 2000-es évek derekán a telekommunikációs vállalatok mekkorának becsülték az év végi SMS-forgalmat, hiszen köztudott volt, hogy akkortájt az rövid szöveges üzenetek nagy része karácsonyra és szilveszterre koncentrálódott.

Az előrejelzés-automatizálás előretörése minden területen törvényszerű, így ma már az interneten is számos algoritmus elérhető. Egyikre sem tekinthetünk természetesen mindent tudó varázsgömbként, de van egy-két említésre méltó közöttük. Ebben a bejegyzésben a Facebook által publikált generikus prediktív elemzési megoldást vizsgáljuk: kipróbáltuk a Mark Zuckerberg és fejlesztői csapata „prófétáját”.

A Facebook Prophet egy Python és R nyelven használható előrejelző eszköz, melyet Facebook data science csapata fejlesztette ki a Stan fejlesztőeszköz használatával. Szükséges bemenete egy timestamp típusú attribútum és egy hozzá tartozó numerikus érték. Ebből adódóan ez az eszköz azokra az esetekre hasznos,  mikor az adatnak szezonális tartalma van. Tapasztalataink alapján leginkább napi bontású, legalább egy évet tartalmazó adatok elemzésére alkalmas. Az implementációja követi az sklearn fit és predict függvények struktúráját.

A Prophet paraméterezhetősége

A Prophet erőssége a paraméterezhetőség, a lehetőség olyan információk átadására a modellnek, amelyek alapvetően az adatból nem következnek, de szeretnénk azokat figyelembe venni egy megbízhatóbb előrejelzés létrehozásakor.

  • Saturating Forecasts: minimum(floor), maximum(cap) érték meghatározása a perdiktálás keretek között tartása érdekében. Valamely konstans keretérték megadása, ami az adott előrejelzés logikája alapján szükséges lehet.
  • Trend Changepoints: az emberi ismeretekkel előre sejthető, jövőbeli trendben számíthatóan bekövetkező váltópontok számának meghatározása (n_changepoints), trend flexibilitásának beállítása (changepoint_prior_scale) vagy a váltópontok helyének meghatározása (changepoints). Ilyen lehet például a labdarúgó-világbajnokság fináléja.
  • Seasonality and Holiday Effects: szezonalitás meghatározása (add_seasonality), alapvetően heti és éves intervallumokkal számol a modell. Ünnepek meghatározása (holidays). Abban az esetben, ha szeretnénk meghatározni ilyen ünnepi dátumokat, akkor azt a múltra és jövőre vonatkozóan is meg kell tenni, különben nem veszi figyelembe a modell. A különböző ünnepek között meghatározható prioritás (prior_scale) és az ünnepi hatások csillapítása is lehetséges (holidays_prior_scale).
  • Outliers: Az outlier adatok kezelésére azt javasolják, hogy egyszerűen csak cseréljük le nem létező adatra, mert a Prophet jól kezeli a hiányzó adatokat.
  • Non-Daily Data: Abban az esetben, ha nem éves adatokra tanítjuk be a modellünket, akkor az előre jelzésre is olyan intervallumot használjunk, mint amit a tanító halmazban.

Időjárás-előrejelzés

A Prophet eszköztárának kipróbálására Budapest egy kerületének a hőmérsékleti adatait használtuk fel, mint erősen szezonális adatokat. Az adathalmazunk 1901. 01. 01-tól 2010. 12. 31-ig tartalmaz hőmérséklet adatokat napi bontásban. Az utolsó 2010-es évet vettük ki a tanító halmazból és használtuk fel az előrejelzés visszamérésére.

# Eredeti adathalmaz oszlopainak átnevezése
df = df.rename(columns={'#datum': 'ds', 'd_ta': 'y'})
data = df[['ds', 'y']]
# Dátum formátum megváltoztatása
training = data[data['ds']<'2010-01-01'] test = data[data['ds']>='2010-01-01']
# Modell létrehozásda és tanítása
m = Prophet(changepoint_prior_scale=0.5)
m.fit(training)
# Jövőbeli dátum intervallum létrehozása
future = m.make_future_dataframe(periods=365)
forecast = m.predict(future)
# Vizualizáció
plt.plot( forecast_2010['ds'], forecast_2010['yhat']
         ,forecast_2010['ds'], forecast_2010['yhat_lower']
         ,forecast_2010['ds'],forecast_2010['yhat_upper']
         ,forecast_2010['ds'],test_2010['y'] )
plt.show()

 

Időjárás 2010A fenti ábrán a 2010-es év valós időjárása piros vonallal látható. A Prophet által illesztett előrejelzés a kék vonal és a hozzá tartozó narancs és zöld színnel ábrázolt y_lower és y_upper, felső és alsó határérték.

 

Decemberre illesztett görbe:


forecast_december = forecast.tail(31)

test_december = test.tail(31)

plt.plot( forecast_december['ds'], forecast_december['yhat']

         ,forecast_december['ds'], forecast_december['yhat_lower']

         ,forecast_december['ds'],forecast_december['yhat_upper']

         ,forecast_december['ds'],test_december['y'] )

Időjárás 2010 december

Az decemberre vonatkozó előrejelzés megmutatta, hogy kisebb intervallumok kiemelése esetén sokkal nagyobb arányban esik a prediktált felső és alsó határértékeken is kívül a valós hőmérséklet. Mint láttuk, az éves előrejelzésnél lévő körülbelüli +/– 5 fokos felső és alsó határon belülre kerülnek az akkori valós hőmérsékleti adatok túlnyomó többsége.

Októberre illesztett görbe:


forecast_oct= forecast[forecast['ds']>='2010-10-01']

forecast_oct = forecast_oct[forecast_oct['ds']='2010-10-01']

test_oct = test_oct[test_oct['ds']<'2010-11-01']

plt.plot( forecast_oct['ds'], forecast_oct['yhat']

         ,forecast_oct['ds'], forecast_oct['yhat_lower']

         ,forecast_oct['ds'],forecast_oct['yhat_upper']

         ,forecast_oct['ds'],test_oct['y'] )

plt.show()

Időjárás 2010 október

Az októberi adatok vizsgálatakor látható, hogy egy hőmérsékletben kevésbé ingadozó hónap esetén meglehetőségen pontos előrejelzést kapunk a modelltől. Ebben az esetben például a prediktált és alsó határérték közé esik – kevés kivétellel – az összes valós hőmérsékleti érték.

Prophet a globális felmelegedésről

Érdekességképpen kipróbáltuk, milyen következtetést von le a jövő időjárásra vonatkozóan a Prophet. Megnéztük, milyen előrejelzést ad száz év hőmérsékletadatait figyelembe véve a 2039-es évre vonatkozóan.


future_forecast = forecast[forecast['ds']>='2039-01-01']

future_forecast.head()

future_forecast.tail()

test_2010_cut = test_2010[test_2010['ds']<='2010-12-24']

future_forecast.tail()

test_2010_cut.tail()

plt.plot( future_forecast['ds'], future_forecast['yhat']

         ,future_forecast['ds'],test_2010_cut['y'] )

plt.show()

Időjárás 2039 előrejelzés

Ebben az esetben a teljes adathalmazt felhasználtuk a tanításra  1901.01.01-től 2010.12.31-ig és a következő 30 évre illesztettünk egy görbét a Facebook Prophet segítségével. A kékkel látható a 2039-es évre prediktált görbe és sárgával az adathalmazunk utolsó 2010-es évének hőmérséklete. Alapozva az elmúlt 100 év hőmérsékleti trendjére, szinte az év minden napján jó pár fokkal magasabb hőmérséklet várható.

A Facebook Prophet alapvetően egy újabb nem-lineáris regresszióval dolgozó előrejelző eszköz, ami specifikus esetekben, leginkább a benne implementált paraméterezhetőségével tud hasznos segítséget adni.

via facebook.github.io/prophet/

 

Tekintsd meg a legfrissebb adatokkal kapcsolatos előrejelzéseinket:
https://datandroll.hu/2020/02/12/adatelemzes-trend-bizni-az-adatokban/

https://datandroll.hu/2020/01/29/2020-az-adatok-eve-lesz/

Nézz körbe a Big Data szolgáltatásaink között:

https://thebigdataplatform.hu/big-data-uzleti-megoldasok/

Ha érdekel a cégünk, csapatunk, esetleg csatlakoznál, látogass el a főoldalunkra:

https://united-consult.hu/

 

 

Trendinek lenni = bízni az adatokban

By | Big Data News, Business, Data Science, Machine Learning, Tech Trends | No Comments

Az esetek többségében ismeretlen területre lép az a cégvezető, aki az adatelemzés és -vizualizációt készül integrálni a vállalkozása üzleti folyamataiba. Ahogyan azonban szakértő segítséggel – a számára szükséges mértékben – egyre jobban átlátja a rendszert, és lépésről lépésre tisztul a kép a végeredményt illetően is, úgy egyre nő a bizalom, az ügyfél pedig minden tekintetben partnerré válik.

Természetesen hosszú egy megbízás útja, amíg a csapat felállításától eljutunk a felhasználók betanításáig, illetve az új rendszer élesítéséig. Kollégáink tapasztalatai szerint – közép- és nagyvállalati környezetben – átlagosan több mint fél évet vesz igénybe, mire az előkészítésből, az üzleti megértésből, a fejlesztésből, a tesztelésből, majd az átadás/átvétellel záruló üzembe állításig eljut egy projekt. Ahogyan látszik: miként a feladat, úgy az ügyfél döntése is igen komoly, hiszen a vállalkozás mindennapjaiba, üzleti folyamataiba drasztikus változásokat hoz egy ilyen rendszer.

Miért lehet bizonytalan az ügyfél?

Fejlesztőként érdemes tisztában lenni azzal, hogy az ügyfél esetleges bizonytalansága hátterében több tényező is állhat. Az ML (machine learning) modellek egyelőre viszonylag ismeretlen terepet jelentenek a hagyományos üzleti szféra számára – különösen igaz ez a KKV szektorra –; a meglévő folyamatba egy, az üzlet számára kevésbé kontrollálható elemet engednek be; szükségessé válik a megszokott működési folyamatok átalakítása, az adatelemzés beillesztése az operatív döntéshozatalba; és persze kritikus pont az is, hogy a fejlesztés érdekében külső szakértőkkel kell megosztani az üzleti információkat.

Munkatársunk, Fodor Szabolcs szerint az üzleti szféra jövőjét mindezek ellenére egyértelműen az adatvezérelt döntéshozatal jelenti, minden jel ebbe az irányba mutat. „Egyfajta hype is övezi az adatvezérelt döntéshozatalt, a BigData vagy AI megoldásokat, ami sok vezetőnek, cégtulajnak felkelti az érdeklődését, azonban a valóság és a hype között még nagy a szakadék. De ez a folyamat öngerjesztő, hiszen ha egy szektorban egy vállalat piaci előnyhöz jut egy adatvezérelt megoldással, a versenytársak lépéskényszerbe kerülnek, hiszen hosszú távon aki ebből kimarad, az lemarad” – fogalmazott kollégánk.

Széles körű felhasználás

Az adatelemzés és -vizualizáció az üzleti élet minden szegmensében hatékonyan támogatja a menedzsment munkáját, a vállalati döntéshozatalt. Zsolt és Szabolcs a BI Fórumon megtartott előadásban kitértek arra is, hogy a technológia olyan területeken is sikerrel bevethető, mint például az árkalkuláció, a termékajánlás, az ügyfelek mikroszegmentációja, a Customer Lifetime Value Prediction vagy éppen az üzlethelyiség ideális helymeghatározása.

Szabolcs ezzel kapcsolatos tapasztalatairól is beszámolt. Hangsúlyozta, mindig az adott iparág igényeitől függ, hogy a technológia mely funkcióit, lehetőségeit, előnyeit használják ki szívesebben és nagyobb bizalommal a cégek. „Egy pénzintézet esetén elsősorban az ügyfél scoring rendszerek a legfontosabbak, amellyel az ügyfelek hitelképességét vizsgálják. Egy gyártóüzemben ez nyilván nem használható eszköz, ott első sorban a predictive maintenance-nek van a legnagyobb szerepe, ami az üzem eszközeinek hatékony karbantartását, a karbantartási költségek leszorítását támogatja. Egy termékajánlási megoldás pedig főként az online termékértékesítésben érdekelt cégeknek lehet fontos, ahol széles termékkörből kell kiszolgálni az ügyfelet az egyedi igényei alapján” – osztotta meg kollégánk.

Ha érdekel még milyen újdonságot tartogat 2020 az adatok terén, olvasd el az alábbi cikkünket is:
https://datandroll.hu/2020/01/29/2020-az-adatok-eve-lesz/

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

 

2020 az adatok éve lesz

By | Big Data News, Business, Data Science, Data Visualization | No Comments

Az idei igazán különleges év lesz. A számmisztikával foglalkozó numerológusok szerint 2020-ban ugyanis az anyagiakkal összefüggő energiák uralják a mindennapjainkat, az évszámban szereplő két nulla azonban nehézségeket, komoly kihívásokat jelent majd. Mi magunk is izgalmas esztendőre számítunk, de az efféle okkult tanok helyett továbbra is a tudományos alapokon nyugvó adatelemzés segítségével tekintünk a jövőbe.

Mi már a tavalyi esztendőt is ennek szellemében zártuk, 2019 év végén kollégáink ugyanis előadóként vettek részt a Budapest BI Fórumon, mely a legnagyobb magyar, analitikával foglalkozó, független szakmai rendezvény. Az eseményen egyebek mellett szó volt a BI- és analitikai trendekről, az adatvizualizációról, a mesterséges intelligenciáról, az érdeklődők konkrét esettanulmányokat is megismerhettek az üzleti élet több területéről, Borbély Zsolt és Fodor Szabolcs kollégáink pedig a kiskereskedelemben használatos adatalapú optimalizációról tartottak előadást.

Még tartanak az ismeretlentől

Bevezetésként körüljárták a szakmai berkekben sokakat foglalkoztató kérdést, hogy az adatalapú döntéshozatal vajon csak „win-win” szituációkat eredményezhet-e. Kollégáink úgy vélik, hogy az emberi tényezőktől független folyamatok, valamint az azok eredményeképpen megszülető vagy éppen az azok hátterében álló objektív mérőszámok kétségtelenül pozitív megítélés alá esnek; ugyanakkor a titokzatos „black-box” technológia jelenlétét és a döntések feletti kontroll csökkenésének érzetét negatívan élik meg a cégvezetők és döntéshozók. 

A bizalom azonban jelentősen erősíthető, ha jól előkészített, szakmailag kifogástalanul kivitelezett projekteket adunk át a megrendelőknek, illetve a potenciális ügyfelek kizárólag ilyeneket látnak a referenciáink között. Ehhez azonban feltétlenül szükséges – mondhatni: a sikeres projekt kulcsa –, hogy az ügyféllel közösen helyesen fogalmazzuk meg az üzleti problémát, melyre megoldást keresünk; hogy megbízható és széles körű adatforrásokkal rendelkezzünk; illetve, hogy nyitottságot tapasztaljunk az ügyfél részéről is.

Szabolcs ezzel kapcsolatban úgy vélekedik: „Ma Magyarországon az adatgyűjtés már kellő fókuszban van, és azon KKV-k, amelyek erre hangsúlyt fektetnek, többnyire megfelelő adatforrásokkal is rendelkeznek. Az adatok közvetlenül az üzleti döntéshozatalban, termékfejlesztésben való felhasználásában azonban van még teendő. Itt a nyitottság, az ismeretlentől való félelem, de egyes esetekben az ellenérdekeltség is gátat szab az adatok felhasználásának. Ezen edukációval, pilot projektekkel lehet a legkönnyebben segíteni.”

Komplex szolgáltatásoké a jövő

Ha a nyitottság és a bizalom megvan, az ügyfél csak jól járhat az adatelemzéssel és az adatalapú döntéshozatallal. Kollégáink szerint ugyanis az adatelemzés alapja – némileg leegyszerűsítve –, hogy az üzleti kérdést az adatok nyelvére fordítjuk. Mindez lényegében azt jelenti, hogy az emberi vagy üzleti logika diktálta intuíciókat a meglévő adatokkal támasztjuk alá vagy cáfoljuk meg indokolt esetben; az elvárások alapján felépítjük a modellt; összevetjük a tényeket és az elvárásokat; végezetül pedig forintosítjuk az eredményt.

Egyszerűnek tűnik, a háttérben azonban idő- és energiaigényes feladatok állnak. Kollégáink szerint egy-egy projekt esetében a munka 30%-át az üzleti megértés, 50%-át az adatgyűjtés és előkészítés, adja, és csupán 20%-ot tesz ki maga a modellfejlesztés, mely önmagában is igen komoly és felelősségteljes szakmai kihívás. Ide tartozik ugyanis a Feature Engineering-gel, az ML tanítással és a modell teszteléssel kapcsolatos összes feladat, mely a jövőbeni, működő rendszer motorjául szolgál.

Zsolt és Szabolcs előadásában szó volt arról is, hogy míg sok piaci szereplő csak bizonyos részfeladatokat vállal az előbbiek közül, addig a United Consult komplex megoldásokat kínál az ügyfeleknek. Ezek alapját képezi az imént részletezett adatbányászat és -elemzés, majd a modellfejlesztés. Ezeket követően a modell rendszerbe állítása és a rendszeres modellpredikció vesz még részt a folyamatban. A projekt csúcsa a felhasználói dashboard kialakítása és maga az adatvizualizáció.

Utóbbival kapcsolatban Szabolcs úgy fogalmazott: „Maga az adatvizualizáció lehet egy adatalapú projekt végterméke, ebben az esetben a döntéshozatal közvetlen támogatásában, a működés átláthatóbb áttekintésében van szerepe. De természetesen nem szükséges végterméke az adatvizualizáció egy adatalapú projektnek, de mindenképp támogató szerepe van az adatok megértésében.” Végezetül tehát, a bevezetőben említett számmisztikára visszatérve: 2020 valóban különleges évnek ígérkezik, és ahhoz sem fér kétség, hogy a számok valóban megmutathatják a jövőt, akár üzleti értelemben is. Mi, a United Consultnál azonban abban hiszünk, hogy terveinket nem alapozhatjuk az aktuális csillagállásra. A bigdata-technológiában rejlő lehetőségeket – megfelelő szakértelemmel – azonban bárki a saját javára fordíthatja.

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/

Automatikus gépi tanulás H2O-val

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

Bevezetés, mi az a H2O

Az utóbbi években a gépi tanulás (machine learning, ML) növekedésének köszönhetően megnőtt az igény egy felhasználóbarát megoldásra, amellyel akár kevésbé tapasztalt felhasználók is elboldogulhatnak, ugyanakkor segítheti a data scientist-ek munkáját is. Ebben a cikkben az H2O AutoML eszközét fogom bemutatni, amit még 2016-ban kezdett el fejleszteni a cég.

Az H2O elérhető Java, R, Python és Scala platformokon is. Ebben a cikkben R-ből fogjuk használni.

Adatok

A tanuláshoz az MNIST számjegy adatait fogjuk használni. 70.000 db kézzel írt számról készültek képek 28×28-as felbontásban. Minden egyes pixelhez (28×28 = 784 pixel) egy egész szám tartozik 0 és 255 között, ami a szürkeárnyalatot mutatja.

Számok kézírással - Adatbeolvasás

Az adatok elérhetők több forrásból is, mi most a kaggle versenyén fogunk elindulni https://www.kaggle.com/c/digit-recognizer/data

Ahhoz hogy eljussunk az adatoktól a modellig a következő lépéseket fogjuk megtenni:

  1. Adatok beolvasása
  2. Betöltés H2O-ba
  3. Modellek tanítása
  4. Modell futtatása a teszt adatra
  5. Feltöltés kaggle-re

Modellezés

1. Adatok beolvasása

A Kaggle-ön a két csv fájlt (train.csv, test.csv) töltsük le és helyezzük a projekt mappánkba. A readr csomag segítségével olvassuk be a fájlokat R-be.

A train.csv 785 oszlopot tatartalmaz: az első a label, ami egy 0-9-ig terjedő faktor. Ez mutatja meg, hogy az egyes képek milyen számot ábrázolnak. A többi oszlop a pixelek szürkeárnyalata pixel0-tól egészen pixel 783-ig.

A test.csv csak a pixelek adatait tartalmazza. Az ellenőrzést a Kaggle fogja végezni feltöltés után.

 
library(readr)
library(magrittr)
library(h2o)

train <- read_csv("train.csv", col_types = cols(
  label = col_factor(levels = as.character(0:9)),
  .default = col_integer()
))

test <- read_csv("test.csv")

Fontos, hogy a label oszlopot faktorként olvassuk be, mert ha ezt elmúlasztjuk, akkor mennyiségi változóként fog a modell eredményt adni (pl. 2.31, 4.72). A train.csv fájl csak a pixelek adatait tartalmazza, ezért nem szükséges megadnunk az oszloptípusokat: automatikusan integer-ként fogja beolvasni.

2. Betöltés H2O-ba

Először indítsuk el a H2O-t , ami egy Java virutális környezetben fut (JVM)


h2o.init()

Ezután töltsük be a H2O JVM-be a train és test adatokat az as.h2o függvény segítségével:

train_h2o <- as.h2o(train)
test_h2o <- as.h2o(test)

3. Modellek tanítása

Az AutoML funkciót az h2o.automl függvénnyel érjük el, amely a „motorháztető alatt” különböző ML modelleket tanít be (GLM, Deep learning, GBM, DRF), illetve ezek együttesét is (ensemble).

A függvény legfontosabb argumentumai:

  • training_frame: az adathalmaz amely tartalmazza a befolyásoló változókat és a címkét. Ez alapján tanulnak a H2O modellek. (train.csv)
  • x: a befolyásoló (predictor) változók, amik alapján a modell besorolja a 0-9 számjegyek valamelyikébe a képeket. (pixel0, …, pixel783 változók)
  • y: címke: az oszlop amely tartalmazza a címkéket (label)
  • max_runtime_secs: meddig fusson maximum a modell (tetszőleges, én 10 percre állítom, alapértelmezetten 1 óráig fut)
  • exclude_algos: egyes modellek kizárása

Természetesen jóval több paramétert lehet állítani, ezekről az H2O dokumentációban olvashatsz bővebben.

 
automl_h2o <- h2o.automl(
  x = paste0("pixel", 0:783), 
  y = "label",
  training_frame = train_h2o,
  max_runtime_secs = 1200
)

Az AutoML a következő modelleket használja alapértelmezetten:

  • Random Forest
  • Extremely-Randomized Forest
  • Gradient Boosting Machines (GBM)
  • Mély neurális hálók (deep neural nets)
  • Generalized Linear Models (GLM),
  • illetve két ún. együttest (ensemble):
    • StackedEnsemble_AllModels minden modellt figyelembe vesz. Általában ez a legjobban teljesítő modell.
    • A StackedEnsemble_BestOfFamily minden modellcsaládból csak a legjobban teljesítő modellt használja.

A modellek a ranglistán (leaderboard) találhatók:

 

automl_h2o@leaderboard

                                               model_id mean_per_class_error   logloss      rmse        mse
1 StackedEnsemble_BestOfFamily_0_AutoML_20180706_143720           0.03660115 0.1188238 0.1810178 0.03276743
2    StackedEnsemble_AllModels_0_AutoML_20180706_143720           0.03660115 0.1188238 0.1810178 0.03276743
3                          DRF_0_AutoML_20180706_143720           0.04008693 0.2899887 0.2826129 0.07987007
4                          XRT_0_AutoML_20180706_143720           0.04107182 0.2913078 0.2832940 0.08025547

Összesen négy modell készült el. Két önálló modell (DRF (distributed random forest), XRT (extremely randomized trees)), illetve két együttes (ensemble).

Mivel a két különböző modellcsaládból (DRF, XRT) csak 1-1 modell készült el, így a StackedEnsemble_AllModels és a StackedEnsemble_BestOfFamily megegyezik.

4. Modell futtatása a teszt adatra

Használjuk a legjobban teljesítő modellt (automl_h2o@leader). Az h2o.predict függvénnyel futtathatjuk a modellt a teszt adatra:

 
model_pred <- h2o.predict(object = automl_h2o@leader, newdata = test_h2o)
model_pred

 

  predict           p0           p1           p2           p3           p4           p5           p6           p7
1       2 1.780870e-06 1.255231e-04 9.991817e-01 6.537366e-05 1.897766e-06 1.562988e-06 6.652430e-07 6.090773e-04
2       0 9.996370e-01 1.115405e-06 6.297555e-05 4.453476e-07 4.386726e-05 7.841050e-06 1.237303e-04 2.414906e-05
3       9 1.524223e-04 2.595324e-04 1.165269e-03 1.906389e-03 5.899059e-03 1.082756e-03 5.011537e-05 6.173151e-03
4       4 4.308413e-03 5.748119e-03 2.186001e-02 3.612890e-03 5.807449e-01 2.184924e-03 2.505739e-03 1.305842e-01
5       3 2.119758e-04 8.248249e-03 2.915150e-01 6.790016e-01 1.361538e-04 2.304432e-03 1.106066e-04 5.670405e-03
6       7 2.832275e-04 3.723656e-04 4.514339e-03 1.054196e-02 6.153598e-04 4.646419e-04 1.263733e-04 9.688050e-01
            p8           p9
1 8.066652e-06 4.339676e-06
2 4.947527e-06 9.393295e-05
3 1.908435e-03 9.814029e-01
4 7.465877e-03 2.409849e-01
5 6.964271e-03 5.837324e-03
6 5.466614e-04 1.373007e-02

A model_pred objektumnak 28.000 sora van (minden teszt képre egy) és 11 oszlopa: az első a predict, ami a modell által jósolt számjegyet tartalmazza, illetve p0-tól p9-ig az egyes számjegyek valószínűségét.

Pl. nézzük meg az első képet:

 
matrix(data = as.integer(test[1, ]), nrow = 28, ncol = 28, byrow = TRUE) %>% 
  as.raster(max = 255) %>% 
  plot()

2-es számjegy predikció

erre a modell 2-es számjegyet prediktál. Annak a valószínűsége, hogy a kép 0-ás számjegyet ábrázol: 1.780870e-06, tehát 0.00000178. A 2-es számjegy valószínűsége: 9.991817e-01, vagyis 0.99. A model 99%-os valószínűséget állapított meg arra, hogy az első számjegy 2-est ábrázol, ezért lett a predict oszlop értéke 2.

5. Feltöltés Kaggle-re, eredmény

A Kaggle-re csv formátumban tudjuk feltölteni ImageId és Label oszlopnevekkel. A model_pred objektum H2O-ban van, ezért as.data.frame függvénnyel tudjuk R data.frame-re konvertálni.


data <- data.frame(
  ImageId = 1:nrow(model_pred),
  Label = as.data.frame(model_pred)$predict
)
write_csv(x = data, path = "submission.csv")

Helyezés-H2O-predikció

Feltöltés után a Kaggle rögtön kiértékeli, az eredmény pedig 96.67%, tehát a számjegyek kb. 3.4%-át osztályozta félre a modell. Ez a 2036.ik helyre elég, ami egész jó eredmény, ahhoz képest, hogy csak 2 modell együttese alapján értük el ezt az eredményt.

Összegzés

Az H2O AutoML eszköz egy nagyszerű lehetőség junior és senior data scientist-eknek egyaránt, hogy minimális paraméterezéssel több különböző ML modellt tanítsanak be. Az eredmény útmutatást adhat, hogy melyik modellt érdemes használni (amelyet aztán később manuállisan paraméterezhetünk), vagy akár benchmarknak is használható.

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/

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/

Aszinkron programozás Shiny-ban

By | Data Science, R | One Comment

Az eRum konferencia a második legnagyobb esemény az R programozás világában. Idén Budapest adott otthont a rendezvénynek, így nekem is nyílt lehetőségem előadni. Előadásom megtekinthető a youtubeon.

Miért?

Az R egy szálon futó (single threaded) nyelv, ezért ugyanarra az instance-ra érkező feladatok blokkolják egymást. Ez alap esetben nem okoz gondot, mert rövid feladatoknál csak millimásodperceket kell várni, ezért fel sem tűnik a felhasználónak.

Hosszabb feladatok futtatásánál viszont előfordulhat, hogy az egyik felhasználó (akár rövid, millimásodperces kérése) beragad egy hosszabb folyamat mögé. A rövid feladat futása csak akkor fog elkezdődni, amikor a sorban előtte lévő már befejeződött. Ez azt jelenti, hogy ha egy 0.1 mp alatt lefutó feladat a sorban egy 15 másodperces feladat mögé szorul (pl.: egy nagyobb csv fájl beolvasása miatt), akkor 15 másodpercig sorba áll, majd 0.1 mp alatt lefut, ez idő alatt a felhasználó pedig egyáltalán semmit nem tud csinálni.

Megfelelően loadbalance-olt alkalmazások esetén ez a blokkoló viselkedés ritkábban fordulhat elő, de az RStudio promises csomagja végleg megoldja a problémát. Az aszinkron futtatáshoz három csomag szükséges: a shiny aszinkron verziója, a future package és a promises package. Ezeket a csomagokat az alábbi utasításokkal installálhatjuk:

devtools::install_github("rstudio/promises")
devtools::install_github("rstudio/shiny")
install.packages("future")

Hogyan?

Egy standard (szinkron) hívást az alábbi módon írnánk meg: (csv fájl beolvasása, szűrés, majd oszlopkiválasztás)

library(dplyr)
read.csv("eRum.csv") %>%
  filter(talk_type == "shiny") %>%
  select(speaker_name)

 

Ugyanez a kód aszinkron hívás esetén így módosul:

future(read.csv("eRum.csv")) %...>%
  filter(talk_type == "shiny") %...>%
  select(speaker_name)

 

Az alapértelmezett (szinkron) hívást úgy tudjuk aszinkronná konvertálni, ha a lassan futó függvényt ‘future’ hívásba ágyazzuk, illetve  további függvényhívásokat intéző pipe operátort lecseréljük promise pipe operátorra (‘%…>%’).

Miért?

Ilyenkor a Shiny szerver egy teljesen új folyamatot indít a future package segítségével, majd amikor ez a folyamat végzett, akkor visszatér, és a szerver kiértékeli. Mivel külön szálon fut, így nem blokkolja más felhasználók folyamatait.

Ez a funkcionalitás csak különböző felhasználó session-ök között működnek (egyelőre). A felhasználónak, aki aszinkron módon hív meg egy függvényt, ugyanúgy meg kell várnia, amíg ez a folyamat lefut, mint szinkron mód esetén.

Demó

Összegzés

Összességében az aszinkron hívási mód kiváló lehetőséget biztosít a lassan futó függvényhívások loadbalance-olására, viszont nem használható a JavaScript-hez hasonló módon, egyazon felhasználó folyamatainak aszinkron menedzselésére.

További információk:

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!

Asszinkron programozás az eRumon

By | Data Science, R | No Comments

Gyurkó Dávid, R/Shiny rajongónk és nagykövetünk “Going async with Shiny” címmel előadást tartott az idei európai R konferencián az eRum-on. Az aszinkron programozás alkalmazásával a shiny alkalmazásunk akkor is responsive marad miközben a háttérben egy másik erőforrásigényes program (például egy neurális háló betanítása) fut. Dávid a konferencián röviden bevezette a useReket az asszinkron programozás rejtelmeibe. Ha lemaradtál az előadásról kövess minket a blogon, hamarosan jelentkezünk!