Category

Machine Learning

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.

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/

 

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/