Ką rinkčiausi duomenų ūkyje

Kuo didesnis klientas, tuo mažiau laisvės technologijų pasirinkimui – dažniausiai dirbi tais įrankiais, kurie jau naudojami organizacijos viduje. Naujų programavimo kalbų, operacinių sistemų ar duomenų bazių klientams nesinori, nes kažkam organizacijos viduje tas naujas technologijas reikės prižiūrėti. Jei visas tavo lėktuvų parkas sudarytas iš Airbusų, įsigyti vieną Boeingą „pažaidimui“ nelabai protinga. Tačiau kartais sveika pagalvoti, kokias technologijas rinktumeisi, jeigu viską darytum nuo nulio.

Duomenų bazė

Anksčiau buvau pratęs dirbti su MySQL – greita, paprasta, lengva administruoti. Šiuo metu rinkčiausi Postgres, nes nebegaliu gyventi be Common Table Expressions, o MySQL jų palaikymas dar tik labai šviežias. SQL kodas, rašomas su WITH ... AS ( ... ) yra žymiai lengviau skaitomas, o tai labai svarbu, jeigu tenka rašyti sudėtingas ne vieno šimto eilučių SQL užklausas. Be to, Postgres turi begales papildomų funkcijų ir galimybių – kuo reikia sudėtingesnės verslo logikos, tuo mažiau pradeda tikti MySQL.

Savaime suprantama, galima naudotis ir MS SQL Server ar Oracle, tačiau lemiamas argumentas visgi yra kaina.

Programavimo kalba

Pradėjęs nuo Perl, jaunystėje daug ko daręs su PHP, po to perėjęs prie Ruby, kažkiek krapštęs R, nesusigyvenęs su Scala, šiuo metu viskam rinkčiausi Python. Daug reikiamų bibliotekų duomenims maigyti, nuo paprasto ETL iki dirbtinio intelekto ir beveik bet kokio machine learning (na, galbūt dar vis kokiais specifiniais statistiniais algoritmais čia jį lenkia R, bet universalumu R tikrai nusileidžia). Be to, python kuo toliau, tuo labiau populiarėja – tai ne eksperimentinė nišinė kalba, kurią gerai supranta tik sauja žmonių: tai svarbu, norint užtikrinti, jog kažkada kas nors iš tavęs galės sklandžiai perimti projektą.

Operacinė sistema

Labai dažnai dirbant Microsoft ekosistemoje tenka dirbti su Windows serveriais – nieko labai blogo, bet žymiai labiau esu pratęs prie Linux (ir daugiausiai Debian / Ubuntu). Konsolėje jaučiuosi kaip namie, juodas ekranas man jaukus ir savas, todėl rinkčiausi būtent jį. Bet kartu labai suprantu, kad administruoti naują operacinę sistemą to niekad nedariusiam yra labai sudėtinga, tad jei visi kompanijoje naudoja Windows, naujų žvėrių zoosode matyt nereikėtų.

Darbų dirigentas

Manau, kad įvairiems ETL darbams planuoti ir diriguoti naudočiau Apache Airflow. Rašyta python, turinti daug galimybių, aprėpianti beveik visus įmanomus poreikius, po truputį tampanti industrijos standartu (bent jau atviro ir nemokamo kodo ekosistemoje). Taip, reikia rašyti kodą, bet tai, mano nuomone, privalumas. Daug programuotojų gal ir nustebs, bet labai dažnai drag&drop įrankiai didelėse organizacijose labai vertinami, nes jie suteikia (dažniausiai nepasiteisinančią) viltį, jog duomenų ūkį lengvai galės administruoti koks nors net SQL nemokantis stažuotojas iš finansų analizės poskyrio. Paprastiems dalykams gražūs pele stumdomi daiktai gal ir veikia, bet kai viskas susivelia į vieną didelį neišnarpliojamą kamuolį… (taip, piktai žiūriu į tave, Alteryx).

Kiti būtini dalykai

git. Būtina naudoti git. Bet kokia forma (github, gitlab, bitbucket, savo pačių daryta, bet kokia…), bet būtina naudoti kodo versijavimą. Niekaip nesuprantu, kodėl didelėse organizacijose kodo versijavimas toks retas. Vis dar kodas taisomas tiesiai serveryje, vis dar dažnai kokioje nors direktorijoje kaupiasi programos pavadinimu load_foo_v12.192_final_do_not_use.sql. Tikriausiai kultūriškai tai ateina iš Excelio ir įvairiausių „vartotojui draugiškų“ drag&drop įrankių – lengvai jų į versijavimo sistemą nesudėsi.

Testai. Jeigu versijavimo sistemas tai dar pas klientus galima kur nors rasti, testus duomenų bazėms bei ETL programoms labai mažai kas rašo. Kuo mažiau kompanijoje inžinierių, tuo mažesnė tikimybė, jog kodas bus tikrinamas testų pagalba.

Machine learning’o projektuose sunkiausia ne techninė dalis

Buvęs LinkedIn duomenų analitikas Peter Skomoroch konferencijoje Strata skaitė neblogą pranešimą apie tai, kas sunkiausia įgyvendinant machine learning ar dirbtinio intelekto projektus. Ne, ne techninės kliūtys. Sunkiausia tai, kad labai sunku tokius projektus tiksliai suplanuoti ir subiudžetuoti – o ir jų nauda dažnai sunkiai įvelkama į skaičius (kvantifikuojama). Didelei korporacijai, kurioje visi įpratę IT projektus vykdyti griežtai subiudžetuotais projektais (nesvarbu, kad dauguma jų tuos biudžetus vis tiek ryškiai perlipa), sunku suprasti, jog beveik neįmanoma suprognozuoti, ar veiks algoritmas ar ne, bei kiek laiko užtruks jį ištreniruoti. Niekas negali pasakyti, kada jau bus galima į gyvenimą paleisti save vairuojančias mašinas: visos prognozės buvo labai netikslios (berods Uber kažkada seniai sakė, jog 2020-aisiais jie vairuotojų nebeturės ir važinėsime autonominėmis mašinomis. Vis dar mane namo veža žmonių valdomi Toyota Prius).

The transition to machine learning will be about 100x harder than the transition to mobile.
Some of the biggest challenges are organizational, not technical.
Machine Learning shifts engineering from a deterministic process to a probabilistic one.

Peter Skomoroch

Labai svarbu, kad machine learning projektams vadovautų žmonės, kurie gerai supranta kompanijos duomenis, o ne vien yra matematikos profesoriai. Geras projektų vadovas supranta, kas machine learning‘e yra lengva, o kas sunku, ir, net jei tai ne itin sudėtinga problema techniniu požiūriu, supranta ar ji turi verslo vertę. Gal būt visai neverta šiai problemai skirti dėmesio? Taip pat svarbu suprasti turimų duomenų niuansus ir kokybę – dažnai teoretiniai matematikai tai pražiūri, nes matematiniuose modeliuose visi duomenys vienodai geri ir kokybiški. Realybėje – ne itin.

Duomenys nebūtinai sukuria daug verslo vertės

Šiandien užtikau gerą straipsnį apie tokį požiūrį, su kuriuo, deja, gana dažnai susiduriu kompanijose: reikia surinkti kuo daugiau duomenų, viską bet kaip sudėti į duomenų bazę ir iš to vis tiek gausis kas nors gero. Na, žinai, gi ten machine learning, dirbtinis intelektas, visa kita gi šiais laikais. Svarbu duomenų būtų.

Didesnėse kompanijose tai dažnai galima suprasti: pinigų projektams kaip ir yra, norisi užsidėti varnelę, kad „kažką darai su dirbtiniu intelektu“, net jei ir nieko nesigaus, tai bent jau bandysi. Nesvarbu, kad nelabai aišku, kokia reali to nauda verslui, ir kas bandoma pasiekti. Bet tai, pasirodo, dažnai pasitaiko ir tarp startuolių: vietoje to, kad pastangas skirti klientų paieškai ar geresniems procesams, per daug koncentruojamasi į duomenis, lyg jie būtų ta magiška burtų lazdelė, kuri visus staiga padarys milijonieriais.

Straipsnyje galima rasti gerų patarimų ir įžvalgų, kurių niekada reiktų nepamiršti, dirbant su duomenų projektais:

  • Kokie yra duomenų gavimo kaštai? Būtina bent jau apytiksliai paskaičiuoti, kiek kainuoja visi duomenų inžinieriai, visi vadovai, kuriems reikia ataskaitų ir planų, visi serveriai, infrastruktūra, visų vadovų laikas, kurį jie praleidžia kasdieną stebėdami analitines ataskaitas vietoje to, kad galbūt galvotų, kaip užkariauti naujas rinkas ir geriau padėti klientams.
  • Kokią naudą mes gauname iš duomenų? Kas atsitiktų, jei vienos ar kitos ataskaitos ar algoritmo nebūtų? Kiek verslo vertės susideda iš to, kad turime tikslesnę informaciją ir ją galime greičiau pasiekti? Taip neretai galima suprasti, kad visgi lengviau paskambinti klientui ir jo paklausti, kas jį mūsų svetainėje trikdo nei valandų valandas praleisti Google Analytics bandant išskaityti gudrias įžvalgas.
  • Per kiek duomenys pasensta? Dažnai net nepastebima, kad kelių metų duomenys jau niekam neįdomūs ir netgi nelabai naudingi: klientų poreikiai pasikeitė, elgsena kitokia, žiūrėk jau ir Facebook ne toks visiems įdomus, aplinka nujudėjo visai kitur. Kai supranti, kad tavo duomenys labai greitai sensta ir vien jų kiekis nesukuria tvaraus konkurencinio pranašumo (nes bet kas, investavęs metus ar kitus darbo gali irgi įgyti ne ką mažiau panašių duomenų), jų nuolatinis atnaujinimas ir kiekybės siekimas vien dėl kiekybės nušvinta kitomis spalvomis. Gal verčiau mažiau duomenų, bet labai gerai atrinktų? Ir gal užtenka logistinės regresijos ir visai nereikia neuroninio tinklo su dešimt tūkstančių faktorių?

Ar jums tikrai reikia besimokančių (machine learning) sistemų?

Žiūrėk, turim duomenų, gal galėtumėt ką nors padaryt su machine learning ar dirbtiniu intelektu? Juk čia gi dabar ateitis“ – labai dažnas šiuolaikinis prašymas iš potencialių klientų. Neretai pasirodo, kad realių problemų sprendimui nereikia nei gudrių algoritmų, nei dirbtinio intelekto: didžioji vertė iš duomenų išspaudžiama žymiai paprastesnėmis priemonėmis, vien tik sutvarkius duomenis ar pasinaudojant senais gerais statistikos įrankiais. Kita vertus, logistinės regresijos terminai panašiai kaip ir bet kokios diskusijos apie neuroninius tinklus: nei apie vienus, nei apie kitus nedaug kas girdėjęs.

Problema tame, kad dirbtinis intelektas ir besimokančios sistemos yra dažnai minimos tokiose stebuklinguose kontekstuose, kad paprastas žmogus vargu ar gali suprasti, kad, nepaisant visų pastarųjų metų pasiekimų, jos nėra visagalės. Taip, jos gali atpažinti objektus paveiksliukuose, taip, jog pusėtinai gali išversti vienos kalbą į kitą, taip, jog gali kūrybiškai imituoti meno kūrinius. Ne, besimokančios sistemos dar negreit sukurs naują Nobelio literatūros kūrinį, ne, jos nesugalvos jums naujos verslo strategijos, ne, jūsų atsitiktinė duomenų sankaupa netaps aukso grynuoliu, nešančiu jums milijonus vien todėl, kad nutarėte investuoti į dirbtinį intelektą.

Vienas geriausių kriterijų, kuris labai greitai atmeta visas dirbtiniam intelektui kol kas neįkandamas idėjas yra užduoti sau klausimą, ar su norima spręsti užduotimi susidorotų paprastas žmogus. Jei žmogus duomenyse gali atrasti paaiškinamus sąryšius bei dėsnius, tai yra šansų, kad tai galės atlikti ir dirbtinis intelektas, nors to garantuoti negalima. Jei žiūri į klientų duomenis, ir pradedi suprasti dėsningumus, tuos dėsningumus galbūt atras ir besimokančios sistemos. O jei duomenys nieko nesako net protingiausiam žmogui, tikėtina, jog nieko protingiau nesugalvos ir dirbtinės sistemos.

Panašios nuomonės yra ir šio dienoraščio autorius. Jis gal dar griežtesnis: jei įmanoma duomenis perkratyti statistinės analizės pagalba ir jų ryšius aprašyti matematinėmis formulėmis, dirbtiniam intelektui – ne vieta. Nors suprantu, jog riba tarp sudėtingos statistikos ir besimokančių sistemų kartais nebe tokia ir aiški.

Kad ir kaip ten bebūtų, duomenys atneša daugiausiai verslo vertės, kai yra labai aiškiai suprantama, ką su jais norima padaryti ir kai yra užduodami teisingi verslo klausimai. Vien perleidus atsitiktinių duomenų rinkinį per dirbtinio intelekto algoritmus, verslo įžvalgų grynuolio nerasi. Garbage in, garbage out.

Įsitraukimo metrikos veda klaidingu keliu

Jau prieš gerą pusmetį rašiau, kad kuo toliau, tuo labiau nesu patenkintas socialiniais tinklais: nors ir turiu išugdytą įprotį turint laisvą minutę įsijungti Facebook ar Instagram, retokai ten randu ką nors įdomaus. Dauguma istorijų tapę vienodos ir nebeįdomios, o Instagram nuotraukos atrodo lyg gamintos pagal vieną klišę. Jei netikite, užeikite į @insta_repeat profilį.

View this post on Instagram

Feet in front of Horseshoe Bend 🍁

A post shared by Insta Repeat (@insta_repeat) on

@Insta_repeat profilyje surinktos vienodos skirtingų autorių nuotraukos

Kodėl taip nutiko? Kodėl vis kompulsyviai norisi maigyti telefoną ir prasukti dar, ir dar, ir dar, ir dar vieną ekraną „turinio“ ir vis tiek nesijausi pasisotinusiu? Turbūt labiausiai reiktų kaltinti duomenų analitikus ir ganėtinai naują vadybos idėją, jog viską reikia matuoti, o geriausias matas, kurį visada reikia gerinti – įsitraukimas (engagement). Kuo ilgiau „skrolini“, tuo daugiau praleidi laiko programėlėje, tuo geresnės tavo įsitraukimo metrikos. 

Kai didžioji dalis produkto vystymo sprendimų daroma vien tik analitikos pagalba, labai galima nuklysti į lankas. Lengvas ir neįpareigojantis turinys tampa didesniu prioritetu nei asmeniniai įrašai, antraštinis masalas ima viršų prieš kokybišką turinį: tokį ir dažniau paspausi, ir jame praleisi daugiau laiko, nes bandysi išnarplioti, kas iš tiesų slepiasi po antrašte. Ir visai nesvarbu, jog vartotojas lieka susierzinęs ir nepatenkintas, jog jis jaučia, kad kažkaip nelabai čia įdomu – analitinės įsitraukimo metrikos juk rodo, jog viskas gerai!

When a measure becomes a target, it ceases to be a good measure.

Charles Goodhart

Socialiniai tinklai ir portalai tampa naujienų „greitmaisčiu“ (junk food): naudos mažai, bet nuo jų žvėriškai sunku atsitraukti. Juk tai pirmiausiai turint galvoje ir buvo viskas konstruojama. Bet ar tai nėra trumpalaikio tikslo vaikymasis aukojant ilgalaikį vartotojų pasitenkinimą? Ar tokia analitika iš viso gali padėti suprasti vartotojų elgseną kiek gilesniame lygyje? Ar gali atsakyti, kodėl vartotojai yra patenkinti ar ne? Kuo toliau, tuo labiau manau, kad nelabai. Įsitraukimo metrikos yra svarbu, tačiau jos neturi tapti vienintele kelrode žvaigžde. Kaip teigia Goodharto dėsnis, „kai matuojamas rodiklis tampa siekiamu tikslu, jis pasidaro prastai pritaikomu rodikliu“. Kai pradedami optimizuoti įsitraukimo rodikliai, užmirštami visi kiti dalykai, kurie vartotojui teikia vertę ir pradeda darytis nuobodu.

Wexler, Shaffer, Cotgreave: The Big Book of Dashboards

Dirbant su duomenimis ir neturint didelės menininko gyslelės man kartais trūksta teorinių žinių apie grafikų dizaino teoriją, spalvas bei bendrą „user experience“. Kai greitai sumetinėji grafikus Excelyje, tai gal tai ne taip stipriai jaučiasi, bet kai reikia sukurti kažką sudėtingesnio, reikia ieškoti pagalbos knygose. „The Big Book of Dashboards“ pradžiai tam visai tinka.

Knygos stipriausia dalis yra tie keli skyriai apie pagrindus: kodėl niekada nereiktų naudoti skritulinių diagramų, kodėl reikia žūt būt vengti šviesoforo spalvų (daltonikai jų neskiria), kodėl reikia vengti per didelio informacijos kiekio vienoje vietoje ir panašiai. Kuriant įvairiausias ataskaitas visada pirmiausia reikia išsiaiškinti klientų klausimus, kuriuos turėtų atsakyti duomenys ir ataskaitų struktūrą taikyti prie jų. Žinau, skamba lyg akivaizdžių ir paprastų tiesų kartojimas, bet realybėje tai ne taip lengvai pasiekiama. Negana to, ataskaitos turėtų numatyti ir tolimesnius klausimus, kurie gali kilti klientams: jeigu ataskaitos grafikas rodo, kad pardavimai Latvijoje mažesni nei užsibrėžtas tikslas, tikriausiai vartotojui kils klausimas kodėl? – Tikriausiai reikia ir būdo, kaip probleminį regioną išskaidyti pagal vadybininką arba prekių grupę, o išskaidžius „tooltipe“ (koks to teisingas lietuviškas pavadinimas? Etiketė?) pateikti ir išsamias detales: kiek ko kada parduota.

Daugiau nei pusė knygos yra įvairių ataskaitų pavyzdžiai, ir, nors jos tikrai įdomios, bet greitai pradeda kartotis, juolab, kad visas jas kūrė tie patys knygos autoriai. Po keletos ataskaitų jau mintinai žinai, kuriuos grafinius elementus ir dizaino sprendimus jie mėgsta. Būtų žymiai geriau, jei knygoje būtų daugiau tvirtos teorijos. Bet bendrai tariant, knyga verta dėmesio, ypač jei tai pirmoji šia tema skaitoma knyga.

David Graeber: „Bullshit Jobs. A Theory“

2013-ais metais antropologas David Graeber parašė ese apie tai, kad kuo toliau, tuo labiau žmonija dirba beprasmius darbus. Jie ne vien tik nekuria vertės, bet ir kartu varo žmoniją į depresiją: jei visą dieną turi generuoti kvailas ataskaitas Sodrai, sunku jaustis, kad sukūrei ką nors prasmingo. O kuo toliau, tuo tokių darbų daugėja.

„Bullshit Jobs. A Theory“ yra platesnė šios ese versija. Nemažai vietos skiriama ekonominiam aspektui, mat dažniausias prieštaravimas iš ekonomistų visgi būna, kad rinka yra efektyvi ir jei darbas nesukurtų vertės, niekas žmogaus nesamdytų, tačiau centrinė knygos tema visgi yra žmogus ir jo santykis su darbu. Kodėl mes dirbame, ar darbas būtinas savęs realizavimui, kodėl mums tapus turtingesniems mes nepradėjome dirbti trumpiau ir kodėl mes vis blogai jaučiamės ir nesidžiaugiame, nors mūsų gerovė didėja. Labai geri antropologiniai klausimai, apie kuriuos ne dažnai susimąstau.

Mūsų ekonominė politika turi pagrindinę tezę: turtas bei lamė sukuriama per darbą. Tam, kad visi būtų laimingi, reikia kad augtų ekonomika, o ekonomikos augimas koreliuoja su sukurtomis darbo vietomis. Ne vienas politikas žarstydamas pažadus teigia, jog sukurs tūkstančius naujų darbo vietų, ir visi tai priima kaip absoliutų gėrį. Tačiau lengviausia yra sukurti darbo vietas prikuriant kokių nors taisyklių ir apribojimų – tarkim jei padvigubintum mokesčių inspekcijos ataskaitų apimtį, reiktų dvigubai daugiau buhalterių ir dvigubai daugiau mokesčių inspekcijos valdininkų: darbo vietos sukurtos, visi dirba, visi kažkuo užsiėmę, bet reali nauda abejotina. O kuo toliau, tokių darbų vis daugėja.

Blogiausia yra tai, kad dirbdami tokį darbą žmonės nesijaučia laimingi, nes jie vargiai mato tokio darbo prasmę. Sunku didžiuotis tuo, kad sukūrei eilinę ataskaitą. Seniau tai, ką žmogus pagamina, buvo jo svarbiausia identiteto dalis („aš – stalius, nes gaminu baldus“, „aš – kalvis“, „aš – ūkininkas“), o per pastarąjį šimtmetį mes bandome savo identitietą kurti ne per tai, ką sukuriame, o per tai, ką vartojame („aš – Žalgirio fanas“, „aš vartoju tik Apple produkciją“). Bet to neužtenka, nes kad ir kiek ko vartojame, tai neužpildo identiteto tuštumos.

David Graeber stipriai palaiko visuotinių bazinių pajamų idėją – visi turėtų gauti standartinę išmoką, kuri užtikrintų bazinį pragyvenimą, ir taip būtų galima atsikratyti labai daug biurokratijos. Be to, žmonės būtų laisvi užsiimti tuo, ką nori, ir jiems nebūtina būtų sėdėti nekenčiamuose darbuose. Ši idėja verčia pergalvoti ir kitas problemas: tarkim, tokiu atveju visai nereikia pensinio amžiaus (išmokos juk mokamos iki pat mirties) – gal ir pačios SoDros problemas galima spręsti žymiai radikaliau nei perstumdant kėdes Titanike. Tiesa, vis dar išlieka klausimas, ar nedirbantys nekenčiamų darbų žmonės irgi jausis laimingi. Sakoma, kad pasididžiavimo savo pasiekimais jausmas aplanko tik tada, kai tai atėjo per sunkų darbą ar kančią.

Apie (perdėtą) metrikų svarbą

Vienas svarbiausių dalykų šiuolaikinėje vadyboje – metrikų (KPIs, key performance indicators, pagrindinių veiklo rodiklių) sekimas. Juk jei kažko nematuoji, tai ir negali pagerinti. Iš tiesų, poreikis reguliariai matuoti savo progresą organizacijas priverčia rimčiau pažiūrėti į savo duomenų ūkį, mat iki tol duomenų surenkama mažai ir ne daug kam rūpi jų kokybė. Ir tik turint pakankamai duomenų palaipsniui galima prieiti prie „data-driven“ kultūros: visus svarbesnius sprendimus priimti vadovaujantis nebe nuojauta, o paanalizavus objektyvius skaičius.

Tačiau čia, kaip ir visur, galima persūdyti. Nereikia pamiršti, jog visas metrikas galima apgauti: vien jau rodiklio pasirinkimas gali lemti keistus organizacijos kultūros pokyčius. Ekonomisto Goodhart’o dėsnis teigia, jog metrikos nustoja būti efektyvios vos tik jos tampa tikslu, kurį reikia pasiekti. Kai tik kažkas siekdamas suvaldyti bankų riziką apriboja kapitalo pakankamumo rodiklį, randama būdų paskolas paversti obligacijomis (o šios kapitalo pakankamumo formulėje traktuojamos atlaidžiau). Kai interneto rinkodaros efektyvumą matuoji reklamų paspaudimais, atsiranda automatinių botų, kurie nuolat spaudalioja ant banerių. Kai prieš reklamdavius reikia girtis atverstų puslapių skaičiumi, portalų antraštės optimizuojamos taip, kad skaitytoją užkabintų, bet neperteiktų straipsnio minties: veiksmo daug, o portalo vartotojai turiniu nusivilia. Jei tik pradedi rimtai optimizuoti kokią nors metriką, net nepastebi, kaip jau toli nuvažiavai į lankas.

Žmogaus elgsenos beveik neįmanoma tobulai išmatuoti – belieka rinktis kažkokius skaičius, kurie gal būt arčiausiai galėtų atspindėti esamą situaciją. Taip „atverstų puslapių skaičius“ apytiksliai matuoja „kiek žmonių perskaitė šį straipsnį?“, o „paspaudimais ant reklamos“ galima išmatuoti vartotojų norą įsigyti reklamuojamą produktą. Kapitalo pakankamumas tampa apytiksliu banko rizikos matu, NPS tyrimas maždaug parodo ar vartotojams patinka jūsų kompanija, studentų egzamino balai maždaug parodo, ar jie išmoko paskaitų medžiagą. Turint prieš akis (kad ir netikslų) skaičių, jį galima stebėti, galvoti, kaip jį pagerinti ir sekti savo progresą. Tai ypač patinka inžinieriams ir matematiškai galvojantiems žmonėms: žymiai lengviau galvoti kaip „X procentų pagerinti egzaminų rezultatus“, nes tai skamba daug tiksliau ir apibrėžčiau nei „geriau mokyti studentus“.

Problema atsiranda tada, kai pamirštama, jog metrika tėra apytikslis pasaulio atspindys. Dar blogiau, kai pagrindiniu tikslu tampa tik metrikos pagerinimas – visada išlenda netikėti antriniai šių metrikų efektai. Norint padidinti straipsnių kokybę pradedama matuoti kiek jų perskaitoma, tada kyla noras optimizuoti paspaudimus ant straipsnių antraščių, o tai galų gale sumažina straipsnių kokybę. Norint, kad kuo daugiau vartotojų naudotųsi tavo programėle, pradedamas sekti vartotojų grįžtamumo dažnumas (retention and churn), o vėliau tai išsiverčia į besaikį elektroninio pašto brukalų ar notificationų naudojimą. Norint, kad studentai geriau išmoktų dėstomą medžiagą, pradedama siekti jų egzaminų rezultatų pagerinimo, ir galų gale profesoriai pradeda mokyti savo dėstomo dalyko egzamino išlaikymo triukų, o ne patį savo dėstomą dalyką.

O kartais reikia optimizuoti visai priešingą metriką nei atrodytų iš pirmo žvilgsnio. Nors standartiškai galvojant norisi siekti, kad vartotojai kuo daugiau laiko praleistų svetainėje, Google stengėsi šią metriką optimizuoti į priešingą pusę: kuo greičiau vartotojai randa ko reikia, tuo jie greičiau dings iš tavo paieškos svetainės ir bus laimingesni. Pasiteisino.

Besaikis skaičių fetišas irgi kenksmingas. Verta į verslą kartais pažvelgti ir ne vien per metrikas.

Robotas irgi žmogus

Iš pažiūros duomenų analizė yra labai nešališkas ir objektyvus reikalas: paimi krūvą duomenų, perleidi per sudėtingą statistinių algoritmų mėsmalę ir gauni kažkokias įžvalgas. Mūsų produktą labiau mėgsta Marijampolėje, brangesnius produktus moterys perka savaitgaliais, socialiniuose tinkluose sekantys veikėją X skaito portalą Y, bent tris kartus gavę labai didelę mėnesinę sąskaitą yra linkę perbėgti pas konkurentus. Su regresijomis (ar sudėtingesnėmis analizėmis) ginčytis sunku, nes duomenys lyg ir kalba už save. Nebereikia spėlioti ir remtis dažnai mus pavedančia intuicija. Bet algoritmai nėra jau tokie neutralūs: jie klysta visai kaip žmonės, nes jie mokosi iš tų pačių žmonių jiems pateiktų duomenų. Tad aklai pasitikėti algoritmų sprendimais nereikėtų.

Vienas to pavyzdys yra JAV naudojamas algoritmas, sprendžiantis apie nuteisto nusikaltėlio polinkį dar kartą nusikalsti. Neseniai buvo pastebėta, jog šis algoritmas turėjo rasistinių polinkių: jeigu esi juodaodis, jo nuomone, tavo recidyvizmo tikimybė didesnė. Kadangi tokiais algoritmais naudojamasi sprendžiant, kokio dydžio bausmę skirti, juodaodžiai už tokius pat pažeidimus automatiškai baudžiami stipriau nei visiškai toks pats baltasis kaimynas, kuris gyvena beveik identiškomis socialinėmis sąlygomis. Su panašiomis diskriminacinėmis problemomis susiduria ir moterys: algoritmai mano, kad jos turi žymiai mažesnę tikimybę uždirbti aukštesnę algą, todėl net joms net nerodo gerų darbo pasiūlymų. Jei tik keliolika procentų vadovų yra moterys, tai net neverta švaistyti lėšų joms rodant vadovų darbo skelbimus.

Tokią algoritmo klaidą ištaisyti nėra taip paprasta, kaip gali pasirodyti. Net jei įstatymais uždrausi kuriant algoritmą atsižvelgti į žmogaus lytį ar odos spalvą, yra daug kitų su šiais dalykais koreliuojančių faktorių. Jei 82% namų ūkių su nepilnamečiais ir tik vienu suaugusiuoju sudaro vieniša mama su vaikais, tai iš šeimos sudėties nesunku atspėti suaugusiojo lytį. Juodaodžius galima atskirti pagal vardus, o Lietuvos atveju, tautybę tikriausiai nesunku suprasti pagal pavardę. Žmogaus gyvenamosios vietos pašto indeksas irgi labai daug ką pasako.

Dirbtinio intelekto algoritmai yra kaip vaikai, kurie mokydamiesi iš aplinkos pradeda suvokti ryšius tarp kintamųjų. Lygiai taip, kaip svarbu, jog vaikas bendrautų su tinkamais žmonėmis ir augtų ne asocialioje aplinkoje, taip ir algoritmo negalima lengvabūdiškai tiesiog paleisti mokytis į platųjį pasaulį. Tai pernai suprato Microsoft, paleidusi savaime besimokantį Twitterio botą Tay, kuris per kelias valandas iš interneto vartotojų išmoko daug rasistinių frazių ir tapo piktu keikūnu. Net ir akylai prižiūrint dirbtinio intelekto mokymosi procesą, mokymosi pavyzdžių imtis turi gerai atitikti realaus pasaulio proporcijas (o tai nevisada lengva pasiekti). 2015-aisiais Google išleistas atpažįstantis objektus nuotraukose algoritmas sukėlė skandalą, mat juodaodžių nuotraukas klaidingai klasifikuodavo kaip beždžiones: jis mokėsi daugiausiai iš baltųjų nuotraukų. Panašiai, kaip Delfi žino apie automobilius tik tiek, kad jie dažnai patenka į avarijas.

Galų gale net jei ir labai atsargiai suformuosi duomenų imtį algoritmo mokymuisi ir atidžiai prižiūrėsi visą procesą, mūsų visuomenėje yra tam tikrų stereotipų ar šališkumų, kurie atsispindės duomenyse. Jei dirbtinio intelekto algoritmą mokysi naudodamasis 1870-ųjų studentų duomenų baze, tikėtina, jog jis į magistro programą siūlys priimti beveik vien tik vyrus. Jeigu algoritmas išmoksta tavo keistumus ir atsižvelgdamas į tavo iškreiptą pasaulio vaizdą tau siūlo skaityti tik straipsnius apie konspiracijos teorijas, tai tik padidina tavo tikėjimą jomis – algoritmai ne tik kad nepadeda objektyviau suvokti pasaulį, bet vis labiau jį iškreipia. Klaidingi įsitikinimai sustiprinami ir daromos vis didesnės klaidos.

Ar yra išeitis iš šios spiralės? Vargu, ar visiškai įmanoma sukurti idealius algoritmus, nes jie tėra mūsų visuomenės atspindys. Kritinis mąstymas ir skeptiškumas tampa labai svarbiais įrankiais atskiriant tiesą nuo melagingų naujienų, tik šiais hiperaktyviais laikais, kai dėmesį gali sukaupti tik kelioms sekundėms, tai tampa brangu ir nemadinga.

Ką turi mokėti analitikas

Neseniai iš skaitytojo gavau klausimą: ką turi mokėti analitikas? Klausimas ne toks jau paprastas, nes neužtenka išvardinti kelias programavimo kalbas ar paminėti kelias technologijas: negali būti jokio baigtinio sąrašo prie kurio sudėliojus varneles galėtum sakyti, kad, va, šitas analitikas tikrai yra geras. Juk tai tėra tik įrankiai.

Nors daugelis analitiko negali įsivaizduoti be matematikos ar statistikos žinių, manau, kad pati svarbiausia sritis, kurią turi išmanyti analitikas yra verslas, kuriame jis dirba. Juk jokios naudos iš to, kad gali sudaryti labai protingą statistinį modelį, jeigu verslas iš to negali padaryti jokių protingų įžvalgų. Sugebėti užduoti teisingus klausimus ir į juos atsakyti gal ir ne šimto procentų užtikrintumu, bet greitai ir efektyviai versle yra labai svarbu. Ir labai dažnai būna, jog teisingai ir laiku užduotas klausimas („o mes toje šalyje sudarėme galimybes atsiskaityti debetinėmis kortelėmis?“) atneša žymiai daugiau naudos nei sudėtingi modeliai, beribės procesoriaus galios bei aukštosios matematikos diplomai. Gal būt dėl to ne visada akademinėje srityje daug pasiekusiems žmonėms sekasi dirbti analitikais: tam reikia kiek kitokios patirties, greito mąstymo ir susitaikymo su tuo, kad nemažai sprendimų gali būti ir klaidingi.

Verslo poreikių supratimas sudėtingas ir tuo, kad nelabai aišku, iš kur to mokytis – tai įgyjama per patirtį. Kai jau matai nebe pirmą ekonomikos nuosmukį, gali numatyti, kas bus su apyvartinėmis lėšomis, kai siuvi nebe pirmas kelnes, žinai, kad šitos medžiagos tiekėjas kartais vėluoja, kai klientų kreditingumą analizuoji nebe pirmus metus, supranti, kad verta atsižvelgti ir į kliento amžių ar šeimyninę padėtį. Bet tokios informacijos neperskaitysi kokioje nors vienoje knygoje: reikės ilgai ir aktyviai tuo domėtis. Todėl labai svarbu, kad analitikas būtų žingeidus, domėtųsi savo analizuojama sritimi bei mokėtų uždavinėti teisingus klausimus. Atsakymai ateis su patirtimi.

Aišku, techninės žinios analitikui irgi reikalingos: juk reikia mokėti iš duomenų atrasti dėsningumus. Kadangi nemaža analitiko darbo dalis yra duomenų traukimas ir valymas, analitikui praverstų mokėti elgtis su duomenų bazėmis (dažniausiai tai reiškia, jog vertėtų neblogai žinoti SQL kalbą). Duomenis transformuojant reiktų mokėti kokią nors programavimo kalbą: R, Python, Ruby ar dar ką nors ne itin sudėtingo. Tai labai pagreitina duomenų analizės darbus, jau nekalbant apie tai, kad šių programavimo kalbų reikės norint daryti sudėtingesnes duomenų analizes – Excelis yra lyg vaikiškas kastuvėlis, lyginant su kitais įrankiais, kuriais reikia mokėti norint kapstytis didelių duomenų sankaupose.

Beje, matematikos žinių analitikui ilgai gali neprireikti – jeigu nedaromi sudėtinti dirbtinio intelekto modeliai, visiškai galima apsieiti ir be jos. Matricų algebra tampa naudinga tik labai pažengusiems. Bet be statistikos žinių toli nenueisi: reikia žinoti, kas yra statistinis reikšmingumas tam, kad šią savaitę dviem procentais nukritus pardavimams nepultum į paniką – gal būt tai tik pokytis normalių svyravimų ribose. Neprošal žinoti ir kaip analizuoti laiko eilutes – trendų ir sezoniškumo analizė gali duoti puikių įžvalgų.

Dar viena dažnai pražiūrima analitiko savybė: mokėjimas komunikuoti. Kad ir kokias protingas įžvalgas iš duomenų padarytum, jas reikės papasakoti kitiems kolegoms, ir dažniausiai p-reikšmės, autokoreliacija ir Chi kvadratas jiems absoliučiai nieko nesakys. Geras analitikas moka duomenis prašnekinti: rasti įžvalgas, jas suprantamai pavaizduoti grafikuose ir įtikinamai aprašyti žodžiais (ir nebijoti prieš auditoriją papasakoti jas gyvai). Puikus to pavyzdys yra Gitanas Nausėda – mokėjimas komunikuoti neretai yra svarbiau nei pačios sudėtingiausios akademinės analizės superkompiuteriais. Man pačiam to vertėtų pasimokyti.