Kas tie machine learning algoritmai iš tikrųjų?
Pirmą kartą susidūrus su mašininio mokymosi terminologija, galvoje dažnai kyla chaosas. Dirbtinis intelektas, neuroniniai tinklai, deep learning – visa tai skamba tarsi iš mokslinės fantastikos filmo. Tačiau realybė daug paprastesnė ir kartu įdomesnė. Machine learning (ML) algoritmai – tai iš esmės matematiniai modeliai, kurie mokosi iš duomenų ir geba daryti prognozes ar priimti sprendimus be tiesioginio programavimo kiekvienai situacijai.
Įsivaizduokite, kad mokote vaiką atpažinti šunis. Neduodate jam tikslių instrukcijų – „jei turi keturias kojas, uodegą ir loja, tai šuo”. Vietoj to rodote dešimtis, šimtus šunų nuotraukų, ir vaikas pats išmoksta atpažinti šunis, net jei jie skirtingų veislių, dydžių ar spalvų. Būtent taip veikia ir ML algoritmai – jie mokosi iš pavyzdžių, o ne iš griežtų taisyklių.
Šiandien ML algoritmai naudojami visur – nuo Netflix rekomendacijų iki medicininių diagnozių, nuo spam filtrų iki autonominių automobilių. Tačiau kaip pereiti nuo teorinių žinių apie šiuos algoritmus iki realių, veikiančių sprendimų? Būtent tai ir aptarsime šiame straipsnyje.
Pagrindiniai algoritmo tipai ir kada juos naudoti
ML algoritmai skirstomi į tris pagrindines kategorijas, ir kiekviena turi savo vietą bei laiką. Supervised learning (mokymasis su mokytoju) – tai kai turite duomenis su teisingais atsakymais. Pavyzdžiui, turite tūkstančius el. laiškų, pažymėtų kaip „spam” arba „ne spam”, ir norite išmokyti algoritmą automatiškai juos klasifikuoti.
Čia puikiai tinka algoritmai kaip logistinė regresija, sprendimų medžiai (decision trees), random forest ar support vector machines (SVM). Kiekvienas turi savo privalumų. Logistinė regresija paprasta ir greita, puikiai tinka dvejetainei klasifikacijai. Random forest atsparus overfitting’ui ir gerai dirba su sudėtingais duomenimis. SVM efektyvus, kai duomenų dimensija didelė.
Unsupervised learning (mokymasis be mokytojo) naudojamas, kai neturite pažymėtų duomenų. Tiesiog turite daug informacijos ir norite rasti joje struktūrą ar šablonus. Klasikinis pavyzdys – klientų segmentavimas. Turite duomenis apie pirkėjų elgesį, bet nežinote, kokios grupės egzistuoja. K-means clustering ar hierarchinis klasterizavimas padės automatiškai sugrupuoti panašius klientus.
Reinforcement learning (sustiprinimo mokymasis) – tai kaip mokote šunį: už gerą elgesį – skanėstas, už blogą – ne. Algoritmas mokosi per bandymus ir klaidas, gaudamas apdovanojimus ar baudas. Būtent taip DeepMind išmokė savo AI žaisti Go geriau nei bet kuris žmogus.
Duomenų paruošimas – tai 80% darbo
Štai ko jums niekas iš karto nepasakys: didžiąją dalį laiko ML projekte praleisite ne kurdami fancy modelius, o valydami ir ruošdami duomenis. Tai nuobodu, kartais erzinantis darbas, bet būtinas. Kaip sako data scientists – „garbage in, garbage out”.
Pirmas žingsnis – duomenų surinkimas ir supratimas. Reikia žinoti, ką reiškia kiekvienas stulpelis jūsų duomenų rinkinyje. Ar yra trūkstamų reikšmių? Ar yra išskirčių (outliers), kurios gali iškreipti modelį? Pavyzdžiui, jei analizuojate būsto kainas ir vienas įrašas rodo 50 mln. eurų už vieno kambario butą – greičiausiai tai klaida.
Duomenų valymas apima trūkstamų reikšmių tvarkymą. Galite jas pašalinti, užpildyti vidurkiu, mediana ar net sukurti atskirą kategoriją „nežinoma”. Kiekvienas metodas turi pasekmių modelio tikslumui. Jei duomenų rinkinyje tik 5% trūkstamų reikšmių – galite drąsiai išmesti tuos įrašus. Bet jei trūksta 40%? Tada reikia kūrybiškesnių sprendimų.
Feature engineering – tai menas kurti naujas charakteristikas iš esamų duomenų. Jei turite datą ir laiką, galite sukurti naujas charakteristikas: savaitės diena, mėnuo, ar tai savaitgalis, metų laikas. Dažnai būtent šios sukurtos charakteristikos labiausiai pagerina modelio tikslumą. Vienas mano kolega kartą pasakė: „Geras feature engineering nugali bet kokį fancy algoritmą”.
Normalizacija ir standartizacija taip pat svarbios. Kai viena charakteristika svyruoja nuo 0 iki 1, o kita nuo 0 iki 1000000, daugelis algoritmų susipainioja. Reikia duomenis suvienodinti – paprastai transformuojant į vienodą skalę.
Modelio pasirinkimas ir treniravimas
Dabar prasideda smagesnė dalis. Turite švarių duomenų, laikas pasirinkti algoritmą. Bet kaip? Čia nėra vieno teisingo atsakymo. Pradėkite nuo paprastų modelių – logistinės regresijos ar sprendimų medžio. Tai duos baseline rezultatą, su kuriuo galėsite lyginti sudėtingesnius modelius.
Praktiškai visada naudoju scikit-learn biblioteką Python’e. Ji intuityvi, gerai dokumentuota ir turi beveik visus reikalingus algoritmus. Pavyzdys, kaip greitai sukurti ir ištreniruoti modelį:
„`python
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
model = RandomForestClassifier(n_estimators=100)
model.fit(X_train, y_train)
„`
Keturios eilutės – ir turite veikiantį modelį. Žinoma, realybėje reikia dar hiperparametrų optimizavimo, cross-validation ir kitų dalykų, bet pradžia būtent tokia paprasta.
Cross-validation būtinas, kad išvengtumėte overfitting’o. Tai kai modelis puikiai veikia su treniravimo duomenimis, bet realybėje prognozės prastos. K-fold cross-validation paskirsto duomenis į K dalių, treniruoja modelį K kartų, kiekvieną kartą naudodamas skirtingą dalį testavimui. Tai duoda realistiškesnį modelio tikslumų įvertinimą.
Hiperparametrų optimizavimas – dar viena svarbi dalis. Kiekvienas algoritmas turi parametrus, kurie nustato, kaip jis mokosi. Random forest turi medžių skaičių, maksimalų gylio, minimalų pavyzdžių skaičių lapuose ir t.t. GridSearchCV ar RandomizedSearchCV automatiškai išbando skirtingas kombinacijas ir randa geriausią.
Kaip įvertinti, ar jūsų modelis geras
Turite ištreniruotą modelį. Puiku! Bet kaip žinoti, ar jis tikrai geras? Accuracy (tikslumas) – pirmasis ir intuityvus metrikos, bet ne visada geriausias. Jei 95% el. laiškų nėra spam, modelis, kuris visus laiškus klasifikuoja kaip „ne spam”, turės 95% tikslumą, bet bus visiškai nenaudingas.
Todėl reikia žiūrėti į precision (tikslumą) ir recall (atšaukimą). Precision rodo, kiek iš tų, kuriuos modelis pažymėjo kaip spam, tikrai yra spam. Recall rodo, kiek iš visų spam laiškų modelis sugebėjo aptikti. Dažnai tarp jų yra trade-off – pagerinant vieną, pablogėja kitas.
F1-score yra šių dviejų metrikų harmoninis vidurkis ir dažnai naudojamas kaip bendras modelio kokybės matas. ROC-AUC kreivė puikiai tinka vertinant klasifikatorius – ji rodo, kaip gerai modelis atskiria klases visame tikimybių spektre.
Regresijos uždaviniams (kai prognozuojate skaičių, ne kategoriją) naudojamos kitos metrikos: MAE (mean absolute error), MSE (mean squared error), RMSE (root mean squared error) ar R². RMSE labiau „baudžia” už didesnes klaidas, todėl jei jums svarbiau išvengti didelių nukrypimų, rinkitės jį.
Bet skaičiai – ne viskas. Visada pažiūrėkite į konkrečius pavyzdžius, kur modelis klysta. Dažnai tai atskleidžia sistemines problemas, kurių nematytumėte tik žiūrėdami į metrikas. Galbūt modelis blogai veikia su tam tikra klientų grupe? Ar su tam tikrais produktais? Ši informacija neįkainojama tolimesniam tobulinimui.
Diegimas ir monitoringas realiame pasaulyje
Jūsų modelis puikiai veikia Jupyter notebook’e. Bet kaip jį paleisti gamyboje, kad realūs vartotojai galėtų naudotis? Čia prasideda visai kita dalis – MLOps (Machine Learning Operations).
Paprasčiausias būdas – išsaugoti modelį naudojant pickle ar joblib ir sukurti REST API su Flask ar FastAPI. Tada bet kuri aplikacija gali siųsti užklausas į jūsų API ir gauti prognozes. Pavyzdys su FastAPI:
„`python
from fastapi import FastAPI
import joblib
app = FastAPI()
model = joblib.load(‘model.pkl’)
@app.post(„/predict”)
def predict(data: dict):
prediction = model.predict([data[‘features’]])
return {„prediction”: prediction[0]}
„`
Tačiau realybėje reikia pagalvoti apie daug daugiau: kaip modelis skalėsis, kai bus daug užklausų? Kaip monitorinti jo veikimą? Kaip atnaujinti modelį, kai atsiranda naujų duomenų?
Docker konteineriai puikiai tinka ML modelių diegimui – visa aplinka supakuota kartu su modeliu, todėl veiks vienodai visur. Kubernetes gali valdyti šių konteinerių skalėjimą. Bet jei tai skamba per sudėtingai, yra paprastesnių sprendimų – AWS SageMaker, Google AI Platform ar Azure ML automatizuoja didelę dalį šio proceso.
Monitoringas kritiškai svarbus. Modelio tikslumas gali kristi laikui bėgant dėl data drift – kai realūs duomenys pradeda skirtis nuo tų, su kuriais modelis buvo treniruotas. Pavyzdžiui, COVID-19 pandemija dramatiškai pakeitė pirkėjų elgesį, ir daugelis modelių, sukurtų anksčiau, staiga tapo netikslūs.
Reikia sekti ne tik modelio metrikas, bet ir įeinančių duomenų charakteristikas. Ar pasikeitė reikšmių pasiskirstymas? Ar atsirado naujų kategorijų? Ar padaugėjo trūkstamų reikšmių? Įrankiai kaip Evidently AI ar WhyLabs padeda automatizuoti šį monitoringą.
Dažniausios klaidos ir kaip jų išvengti
Per kelerius metus dirbant su ML projektais, mačiau (ir pats padariau) daugybę klaidų. Pirmoji ir dažniausia – data leakage. Tai kai į treniravimo duomenis netyčia patenka informacija iš ateities, kurios realybėje neturėtumėte. Pavyzdžiui, prognozuojate, ar klientas atsisakys paslaugos, ir į charakteristikas įtraukiate „paskutinio skambučio data”. Bet jei klientas skambino atsisakyti – tai jau ateities informacija!
Kita dažna klaida – overfitting. Modelis taip gerai išmoksta treniravimo duomenis, kad pradeda „atminti” juos, o ne mokytis bendrų šablonų. Tai kaip studentas, kuris išmoksta vadovėlį atmintinai, bet negeba pritaikyti žinių naujose situacijose. Regularizacija, cross-validation ir paprastesnių modelių naudojimas padeda tai spręsti.
Netinkamas metrikos pasirinkimas taip pat gali suklaidinti. Jau minėjau accuracy problemą su nebalansuotais duomenimis. Visada pagalvokite, kas jūsų verslo kontekste svarbiau – false positives ar false negatives? Medicininėje diagnostikoje praleisti ligą (false negative) gali būti mirtina, todėl recall svarbesnis. Spam filtravime false positive (normalus laiškas patenka į spam) erzina vartotojus, todėl precision svarbesnis.
Nepakankamas duomenų kiekis – dar viena problema. Deep learning modeliams reikia dešimčių tūkstančių ar net milijonų pavyzdžių. Jei turite tik šimtą – geriau naudokite paprastesnius algoritmus ar pabandykite transfer learning, kur naudojate jau ištreniruotą modelį ir pritaikote savo duomenims.
Ir galiausiai – ignoruoti domenų žinias. ML algoritmai galingi, bet jie nežino jūsų verslo specifikos. Jei rezultatai atrodo keisti ar prieštarauja logikai – pasitikėkite savo instinktu ir išsiaiškinkite, kas vyksta. Kartą mačiau modelį, kuris prognozavo neįtikėtinai gerai, kol paaiškėjo, kad jis tiesiog išmoko atpažinti fotografo parašą nuotraukose, kuris koreliavo su tam tikra kategorija.
Kai viskas susidėlioja į vietą
Machine learning nėra magija, nors kartais taip atrodo. Tai įrankis, kuris reikalauja ir teorinių žinių, ir praktinės patirties, ir nemažai kantrybės. Bet kai viskas susidėlioja – kai jūsų modelis tikrai veikia gamyboje ir sprendžia realią problemą – tai jausmas neįkainojamas.
Pradėkite nuo mažų projektų. Neimkitės iš karto kurti kitą ChatGPT. Pabandykite išspręsti konkrečią, aiškiai apibrėžtą problemą su nedideliu duomenų rinkiniu. Kaggle platformoje rasite tūkstančius duomenų rinkinių ir konkurencijų, kur galite praktikuotis. Dalyvauti bendruomenėje – skaityti kitų sprendimus, diskutuoti forumuose – pagreitins jūsų mokymąsi dešimteriopai.
Technologijos keičiasi greitai. Prieš penkerius metus deep learning atrodė kaip egzotika, dabar tai standartas daugelyje sričių. Transformers architektūra revoliucionavo NLP, o GPT modeliai pakeitė, kaip galvojame apie kalbos generavimą. Bet pagrindiniai principai – duomenų kokybė, tinkamas algoritmo pasirinkimas, kruopštus testavimas – lieka tie patys.
Svarbiausias patarimas – nebijokite eksperimentuoti. Išbandykite skirtingus algoritmus, skirtingus feature engineering metodus, skirtingus hiperparametrus. Kartais netikėti sprendimai duoda geriausius rezultatus. Ir nepamirškite dokumentuoti – po trijų mėnesių nebeprisiminsite, kodėl priėmėte tam tikrą sprendimą, o tai svarbu tolimesniam projekto vystymuisi.
ML projektas niekada nėra „baigtas”. Tai nuolatinis procesas – naujų duomenų įtraukimas, modelio tobulinimas, naujų charakteristikų kūrimas. Bet būtent tai ir daro šią sritį tokią įdomią. Visada yra ką tobulinti, visada yra naujų iššūkių. Ir kai matote, kaip jūsų modelis padeda priimti geresnius sprendimus ar automatizuoja nuobodžius procesus – supranti, kad visas tas darbas su duomenų valymu ir hiperparametrų derinimų buvo vertas.
