A koronavírus-járvány Kínában egy hónapja kezdődött elterjedése arra késztetett, hogy egy nyers gépi tanulási előrejelzési modellt alkalmazzak az összes fertőzéses eset idősoron alapuló előrejelzésére, egy nyilvánosan elérhető „adatkészlet” felhasználásával, amelyen naponta egy „műszerfal” található. frissítette és készítette a Johns Hopkins Egyetem.
Ebben a cikkben bemutatom, hogyan lehet notebookot létrehozni az Oracle Autonomous DB-ben, betölteni az adatkészletet, megtisztítani és lefuttatni egy képzést az Oracle Machine Learning platformon elérhető exponenciális simító modellek alapján, végül pedig kiértékelni az eredményeket, hogy kiválaszthassa az egyiket. őket. Egyedül is tesztelheti a modellt, és megpróbálhatja javítani az eredményeket, ha előfizet egy „ingyenes Oracle felhőfiókra”, és használja az általam megadott kódot.
Az Oracle Autonomous DB-ben való munkavégzéssel és jegyzetfüzet létrehozásával kapcsolatos általános információkért tekintse meg a Mediumon megjelent korábbi cikkemet: „Gépi tanulás az Oracle Autonomous DB-n: gyakorlati példa
A világszerte regisztrált fertőzéses eseteket tartalmazó elérhető adatkészletről egy sor jellemzőt tartalmaz, amelyek közül a legfontosabbak a modellem számára:
- Dátum: a megfigyelés dátuma és időpontja
- Megerősített: A megerősített esetek száma
- Halálesetek: Halálesetek száma
Az ilyen típusú adatok a klasszikus felhasználási esetbe esnek, amikor az idősorelemző algoritmusok működnek, vagyis amikor a megfigyelések időrendben történnek. Az én esetemben a Megerősített eseteken dolgoztam, mint az előrejelzés célpontjaként, a dátum mintavételi rendelési pontként. Az ARIMA az egyik legrégebbi és legismertebb algoritmus. A legújabb Exponenciális simítás lehetővé teszi a felhasználók számára, hogy előrejelzéseket készítsenek az idősorok adataiból is. Az exponenciális simítási módszereket (ESM) széles körben használják az idősoros adatokból történő előrejelzéshez. Az „Oracle ESM” számos újabb bővítményt tartalmaz, összesen 14 modellt, köztük a népszerű Holt (trend) és Holt-Winters (trend és szezonalitás) modelleket, valamint a szabálytalan idősor-intervallumok kezelésének képességét. Bevezették az Oracle DB 18c-be, és az autonóm verzióban is elérhető felhőben.
A notebookban ezek egy részhalmazát kiértékeltem, mert az idősorelemzéshez használt paraméternek, a szezonalitásnak nincs értelme ebben a korlátozott adathalmazban, amit használtam: jelenleg januártól, 22-től napjainkig vannak események. . A szezonalitás hasznos lehet például, ha rendelkezik az elmúlt 3 év befolyásolási eseteinek adathalmazával, amelyeket definíció szerint az évszakok befolyásolnak.
A betanításhoz nem szükséges az optimalizálási kritérium, mert modellspecifikus alapértelmezések állnak rendelkezésre.
A modellek teljesítményének összehasonlítása érdekében számos diagnosztikai mérőszámot generálnak a képzés során, például: Mean Square Error (MSE), Average Mean Square Error (AMSE) >és így tovább.
Minden tesztelt algoritmushoz eltároltam a Mean Absolute Error (MAE) értékét, hogy intuitívabb legyen a mérőszám:
A képzési folyamat végén lesz egy táblázatunk, amely az alábbi táblázatban látható:
Van egy sötétkék vonal, amely a fertőzéses esetek tényleges számát mutatja az adatkészletben, dátum szerint összesítve. A világoskék vonal az előre jelzett értékeket jelzi. Minél közelebb van egymáshoz a két vonal, annál jobb a modell. Az algoritmus beállítási szakaszában beállíthatja az előrejelzéshez szükséges lépések számát, ebben az esetben 4 napot. Lépés alatt a mértékegységet értjük, esetünkben napjainkban. A modell egy Alsó korlátot és egy Felső határt is generál, amelyek a bizalmi intervallum készlethez kapcsolódnak (alapértelmezés szerint 0,95).
De magyarázzuk el a jegyzetfüzetben található legfontosabb bekezdéseket. Ez a jegyzetfüzet egy OML környezetben elérhető sablonból származik az idősoros használati esetek kezeléséhez.
Először az adatkészlet betöltődik egy relációs táblába, amely az Oracle Object Storage-ból érkezik, ahová korábban feltöltötte. A legújabb kiadásban egyenesen az objektumtulajdonságok oldala által kapott URL-t használhatja (file_uri_list param).
%script BEGIN DBMS_CLOUD.COPY_DATA( table_name =>’cor_train’, credential_name =>’CRED_COR’, file_uri_list => ’https://objectstorage.oracle.com/n/mytenant/b/bucket-1/o/2019_nCoV_data.csv', format => json_object( ‘delimiter’ value ‘,’, ’recorddelimiter’ value ‘newline’, ‘skipheaders’ value ‘1’, ’dateformat’ value ‘MM/DD/YYYY HH:MI’, ’quote’ value ‘“‘) ); END;
A formátum jelentése meglehetősen intuitív. A csv adatkészlet fájlban a helyek az idézőjelek között vannak tárolva: „. A dátumok tárolása többféleképpen történik: a „HH/NN/ÉÉÉÉ HH:MI” mintával probléma nélkül importáljuk a mezőket.
Az importálást egy tisztító rész követi, amit a dátum mezőben kell kiegyenlítenünk. Például:
%sql UPDATE cor_train SET EVENTDATE_ = concat( concat(concat(concat( SUBSTR(EVENTDATE_,9,2),’/’),SUBSTR(EVENTDATE_,6,2)),’/’),SUBSTR(EVENTDATE_,1,4) ) WHERE sno >= 498 and sno <=631 — 2020–02–02 21:00:00
A 498-tól 631-ig terjedő rekordok dátumai a következő formátumban vannak: ÉÉÉÉ–HH–NN ÓÓ:PP:SS. El kell hagynunk az időt.
Ezt követően beírunk egy Dátum típus mezőbe:
%script ALTER TABLE cor_train ADD eventdate date; UPDATE cor_train SET eventdate = to_date(eventdate_, ‘mm/dd/yyyy’); ALTER TABLE cor_train DROP COLUMN eventdate_
Ezen a ponton létrehozhatunk egy nézetet a két szükséges tulajdonsággal: az esemény dátumával és a megerősített esetek számával.
%sql —- Create input time series CREATE OR REPLACE VIEW CORONA_CONFIRMED AS SELECT Eventdate, Confirmed FROM cor_train;
Az adatkészlet ezen a ponton készen áll az algoritmusba való felvételre. Szokás szerint egy táblázatot kell kitölteni a beállításokkal (CORONA_CONFIRMED_SETTINGS), esetemben:
- ALGO_NAME: algoritmuskategória, ESM idősorokhoz (=›ALGO_EXPONENTIAL_SMOOTHING)
- EXSM_MODEL: az elérhető 14 modell egyike (=›EXSM_SIMPLE)
- EXSM_INTERVAL: a lépések mértékegysége, esetemben egy nap (=›EXSM_INTERVAL_DAY)
- EXSM_PREDICTION_STEP: az előrejelzéshez szükséges lépések száma napokban (=›4)
Modell létrehozásához a DBMS_DATA_MINING.CREATE_MODEL függvényt kell használnia:
BEGIN DBMS_DATA_MINING.CREATE_MODEL( MODEL_NAME => ‘CORONA_CONFIRMED_SAMPLE’, MINING_FUNCTION => ‘TIME_SERIES’, DATA_TABLE_NAME => ‘CORONA_CONFIRMED’, CASE_ID_COLUMN_NAME => ‘EVENTDATE’, TARGET_COLUMN_NAME => ‘CONFIRMED’, SETTINGS_TABLE_NAME => ‘CORONA_CONFIRMED_SETTINGS’); END
A CASE_ID_COLUMN_NAME az a mező, amelyben az esemény időbélyegzője található. A TARGET_COLUMN_NAME a megjósolandó érték.
Az edzés után két fő táblázatot generálunk:
- DM$VPCORONA_CONFIRMED_SAMPLE: a tényleges/előrejelzett értékek, plusz 4 további lépés az előrejelzéshez (felső/alsó határértékekkel)
- DM$VGCORONA_CONFIRMED_SAMPLE: a modell értékeléséhez generált mutatók
Példák a használt adatkészletre/modellre:
EXSM_SIMPLE — — — — — — — — — — — — — — — — — — — — — — — — — — — — - NAME NUMERIC_VALUE STRING_VALUE -2 LOG-LIKELIHOOD 208.21307822140221 AIC 212.21307822140221 AICC 213.54641155473556 ALPHA 0.99989991147719359 AMSE 10312115.505439268 BIC 213.18289152097822 CONVERGED YES INITIAL LEVEL 555.68954421933381 MAE 1395.1741851979993 MSE 2859573.9466481865 NUM_ROWS 631 STD 1691.0274825230329
Megtalálható az átlagos abszolút hiba (MAE), a standard eltérés (STD) stb. NUM_ROWS az adatkészlet méretét jelenti az események időtartamában.
A DM$VPCORONA_CONFIRMED_SAMPLE segítségével megjelenítheti a diagramot a tényleges/előrejelzett értékek közötti különbségekkel, amint az korábban látható.
Ahogy az lenni szokott, az ESM-ben több mint 14 használható modell van, ezért írtam egy bekezdést, hogy egyesével értékeljem, összegyűjtve a MAE mutatókat.
Ezeket az eredményeket találtam:
A józan ész ellenére azonnal kiválaszthattuk a legalacsonyabb hibával rendelkező modellt: EXSM_MULT_TREND_DAMPED.
A probléma az, hogy az előrejelzési görbét ábrázolva a következőt kapjuk:
Amint láthatja, a határok közötti terület hajlamos eltérni, ami használhatatlanná teszi a modellt. Tehát úgy döntöttem, hogy az EXSM_HOLT modellt használom, köztes MAE-értékkel.
A közzététel pillanatában, februárban, az összes regisztrált eset 20 679 volt a várható 23 218 helyett. Február 2-án letöltött adatkészlettel dolgoztam, összesen 17 295 megerősített esettel.
Az EXSM_HOLT modellt használó előrejelzés a határokon belül volt, 11% körüli hibával a ténylegeshez képest.
Míg az előrejelzés a következő 8 napra:
Ez csak egy gyakorlat az ilyen típusú felhasználási esetek feltárására. A következő bejegyzésben egy összetettebb előrejelzési modellt, helybázist fogok bemutatni, figyelembe véve a földrajzi régiók közötti kapcsolatokat, populációkat és egyéb olyan jellemzőket, amelyek javíthatják az előrejelzési modellt.
Addig is engedtem, hogy alaposan tanulmányozza az ESM algoritmusok ízeit az OML könyvben, és saját maga tesztelje le az innen letölthető notebookot:
Jogi nyilatkozat
Az ebben a dokumentumban kifejtett nézeteim az enyémek, és nem feltétlenül tükrözik az Oracle nézeteit.
