Kur Lietuvoje tolimiausia iki ežero?

Kartais būna taip, kad kažkur netyčia nugirsti kokią minties nuotrupą ir po to ji vis tavęs nepalieka. Taip ir man nutiko: prieš kokį pusmetį ar net metus kažkas kažkur paklausė, kaip būtų galima sužinoti, kur yra artimiausias ežeras. Pagalvojau, kad atsakymą nesunku surasti šiek tiek pakračius atvirus geografinius ežerų duomenis. Bet tada pradėjo kirbėti nauja mintis: o kuri Lietuvos vieta yra toliausiai iki bet kokio ežero? Aišku, bėgo mėnesiai, programuoti nesiėmiau, bet klausimas vis tiek niežtėjo. Šiandien pasikasiau.

Lietuvos taškas, labiausiai nutolęs nuo bet kurio ežero yra šiek tiek į rytus nuo Pašvitinio link Peleniškių kaimo (56.16N, 23.84E). Artimiausias jam – Pasvalyje esantis Šilo ežeras, kuris yra už 35.5 km (kaip varna skrenda).

Taškas (burbuliukas), kur toliausia iki ežero. Paspaudus galima didintis.

Techninės detalės

Naudojausi Overpass Turbo užklausa ežerams atrinkti, tad kaip ir norėjau, visokie tvenkiniai, prūdai ir marios į duomenis nepateko. Tiesa, gali būti kad ir ne viskas pateko, ko reikėjo: tarkim, ne visi Vilniaus Gulbinų ežerai atsirado duomenyse.

[out:json][timeout:50];
// gather results
(
  // query part for: “lake”
  way["natural"="water"]["water"="lake"]({{bbox}});
  relation["natural"="water"]["water"="lake"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

Atstumams nuo taško iki pakrantės taškų naudojausi beveik visu kodu iš šio įrašo. Nedaug ir tereikėjo ką pakeisti.

Kelios mintys apie Baltarusiją

Kaip ir daugelis, stebiu, kas dedasi Baltarusijoje – socialinis Lukašenkos kontraktas su tauta baigėsi, meilės nebeliko, rinkimus klastoti tapo sudėtingiau. Ne pačią mažiausią rolę šiuose įvykiuose suvaidino ir COVID: virusas atnešė ekonominius sunkumus, o prasta valdžios reakcija jį suvaldant perpildė kantrybės taurę. Virusas geopolitikoje dar gali atnešti nemažai pokyčių. Vienur tai perauga į neramumus, kitur – į naujas ambicijas, tikintis, kad pasaulis užsiėmęs kitais reikalais ir nesureaguos. 2020-ieji gali būti panašaus lūžio metai kaip 2008-ieji.

Kas kelias dienas savo užrašų knygelėje bandau užsirašyti kelias savo prognozes apie tai, kas bus Baltarusijoje. Esu įsitikinęs, jog jos neišsipildys, bet labai įdomu stebėti savo paties nuomonės kaitą. Pirmomis dienomis po rinkimų galvojau, jog tikimybė, kad rugsėjo pabaigoje vis dar turėsim protestus arba pasikeitusią valdžią buvo apie 20-30%, dar prieš kelias dienas jau ji atrodė 40-50%, o po dabartinių režimo svyravimų vis labiau tampu įsitikinęs, jog tai lengvai nepraeis. Esame istorinių įvykių liudininkai.

Nežinia, kuo tai pasibaigs. Nežinia, ar tai bus mums į naudą. Nežinia, ar tuo nepasinaudos (o kad turėtų bandyti, tai tikrai) Rusija. Bet tautos norą pačiai spręsti savo reikalus reikia palaikyti, net tokiu atveju kai tai gali pakenkti tavo paties realpolitik. Tik pati tauta gali išsikovoti savo laisvę, tik savo pačios pastangomis. Ir tik jai po to spręsti, kaip ji gyvens, net jei tas sugyventinis tau nepatinka. Svarbu, kad tai būtų savanoriškas, o ne primestas apsisprendimas. Dažnai tokiais atvejais prisimenu Beresnevičiaus „Imperijos darymą“: mūsų vaidmuo yra nešti šias Europos vertybes į Rytus. Atrodo, kad mums kol kas neblogai sekasi.

Kokia tikimybė, jog Baltarusija vienareikšmiškai atsigręš į vakarus? Turbūt dar nedidelė, nes reikės laimėti ne vieną vertybinį mūšį, turės sukristi nemažai teisingų aplinkybių ir dažnai turės šypsotis sėkmė. Kol kas duočiau tik 10-15% tikimybę, kad 2025-aisiais mes, Lietuvos piliečiai, galėsime Minske lankytis be vizos. Bet bent jau nebe 1-2%.

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ų?

Duomenų bazių testavimas

Prieš keletą dienų užtikau patikusį straipsnį apie automatizuotus duomenų bazių testus. Programiniam kodui jau senokai tapo įprastinė praktika rašyti testus, bet duomenų bazių struktūra testuojama ne visada. Tiesa, gerai sutvarkytoje duomenų bazėje įmanoma sudėti daug saugiklių: stulpeliams uždėti apribojimus, išorinius raktus ir panašiai, tačiau bendras požiūris į duomenų teisingumą bei validumą vis tiek reikalingas.

Autorius siūlo duomenis testuoti trijose vietose: pirminių šaltinių lygyje, tik juos sukėlus į duomenų bazę ir jau po verslo logikos transformacijų. Šis testų sąrašas atrodo visai nebloga pradžia:

  • Ar visi pirminiai raktai lentelėse unikalūs?
  • Ar [svarbiame stulpelyje] nėra null reikšmių?
  • Ar visi išoriniai raktai egzistuoja lentelėse kaip pirminiai raktai (be dublikatų, ir pan. – referencinis integralumas)?
  • Ar skaitinės duomenų reikšmės neiššoka iš tikėtino reikšmių rėžio?
  • Ar agreguoti duomenys atitinka detalesnių duomenų informaciją (ar čekio suma atitinka atskirų prekių sumai čekyje)?
  • Ar yra visi stulpeliai, kurie bus naudojami galutinėse lentelėse?
  • Ar įmanoma be klaidų paleisti dažniausiai pasitaikančias verslo užklausas?

Dar prie šio sąrašo pridėčiau patikrinimą, ar eilučių kiekis įvairiose duomenų bazės lentelėse yra toks, koks ir tikėtasi – labai dažnai dėl kokios nors lentelių jungimo klaidos duomenys susidublikuoja.

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.

Neapdorotų duomenų nebūna

Yra toks gana gajus mitas, kad turint „žalius“ neapdorotus duomenis, galima nesunkiai padaryti objektyvias išvadas – juk neapdoroti duomenys turėtų kalbėti už save, jie neturėtų būti „sutepti“ šališkos žmogiškos nuomonės bei išankstinių nusistatymų. Kuo daugiau neapdorotų duomenų, tuo objektyvesnės išvados. Deja, visiškai neapdorotų duomenų nebūna. Jau pats faktas, kad kažkas juos rinko, reiškia, kad kažkas padarė sprendimą jais domėtis: o kodėl rinko būtent taip, o ne kitaip? Kodėl rinko tokius, o ne anokius? Kodėl skaičiavo žmones, o ne mašinas; kodėl išmetė iš skaičiavimų vaikus ar žmones vežimėliuose, kodėl nusprendė, jog tamsoje duomenys nepatikimi? Net jei duomenis renka automatiniai prietaisai (tarkim, kas kažkiek laiko skaičiuojama temperatūra), duomenys fiksuojami su aiškia paklaida, kuri nustatyta matavimo įrenginio specifikacijoje – pats įrenginys kažkiek matavimą apvalina, kažkiek veikia nepatikimai už tam tikrų temperatūros rėžių. Jei nežinosi šio konteksto, gali padaryti išvadą, kad temperatūra būna stabili (tiesiog nematai temperatūros pokyčių, mažesnių nei vienas laipsnis) ar ji niekada nenukrenta žemiau -20˚C.

Ypač sunku teisingai interpretuoti skaičius, kurie susiję su žmogumi. Nusikaltimų skaičius gali augti jau vien dėl to, kad pasikeitė suvokimas, kas yra nusikaltimas (tarkim, anksčiau gal buvo visuomenėje priimta, kad vaikus mušti ir tai nebuvo laikoma nusikaltimu). BVP ar infliacijos skaičiai gali kisti dėl metodologinių paklaidų. Pajamų duomenys, surinkti apklausos būdu, smarkiai skirsis nuo duomenų, gautų iš mokesčių inspekcijos.

Simply put, the context of data — why it was collected, how it was collected, and how it was transformed — is always relevant. There is, then, no such thing as context-free data, and thus data cannot manifest the kind of perfect objectivity that is sometimes imagined.

https://www.thenewatlantis.com/publications/why-data-is-never-raw

Šiuolaikinė „didelių duomenų“ mada bando įteigti, jog žali duomenys yra patys objektyviausi, nes jie neužteršti išankstinėmis nuostatomis. Kuo daugiau tokių duomenų, kuriuos galima sušerti taipogi labai objektyviam algoritmui, tuo teisingesnės išvados – ir tam net nereikia jokių ekspertų, mat jie tik įneš savo (nebūtinai teisingą) išankstinę nuomonę. Žmonėmis negalima pasitikėti dėl jų subjektyvumo: nuo to gali išgelbėti tik daugybė duomenų. Bet toks pasaulio vaizdas visgi yra utopinis: jei atvirai nedeklaruoji savo prielaidų, nereiškia, jog jų nedarai. Nematomos subjektyvios prielaidos duomenyse atsiranda jau jų rinkimo procese, ir to niekaip neišvengsi. Ką matuoji, tą ir optimizuosi. Duomenys už save nekalba, jie atkartoja duomenų rinkėjų nuomones.

Geriausias konkurencinis pranašumas skaičiais neišmatuojamas

Keletas gerų minčių iš David Perell Twitterio apie marketingą ir verslo metrikas:

The invention of the spreadsheet transformed marketing and corporate decision making. We’re over-reliant on numbers and metrics. We assume that only what we can measure is real and everything that is real can be measured. One writer calls this the Arithmocracy: a powerful left-brained administrative caste which attaches importance only to things which can be expressed in numerical terms or on a chart.

[…] “Not everything that counts can be counted and not everything that can be counted counts.

David Perell, https://twitter.com/david_perell/status/1056966027752431618

Pasaulyje, kuriame visi kreipia dėmesį tik į duomenis ir skaičius, geriausia konkurencinio pranašumo ieškoti būtent ten, kur jis neišmatuojamas. Ir nors duoną uždirbu žiūrėdamas į skaičius, su verslo metrikomis irgi galima persūdyti.

Lietuvos miestų gatvės pagal pasaulio šalis

Neseniai užtikau įdomią JAV bei kitų pasaulio didmiesčių gatvių orientacijos analizę, darytą vienu mano mėgstamiausių python modulių osmnx. Kadangi kodas viešas, tai buvo nesunku tą patį padaryti ir Lietuvos miestams.

Kaunas ir Vilnius – gana chaotiški, o kitur vyrauja aiški kvartalinė sistema

Kuo senesnis miestas, tuo didesnis senamiestis, o šie dažniausiai būna chaotiški. Naujesniuose miestuose daugiau vyrauja aiški kvadratinė kvartalinė sistema. Buvo įdomu tai, kad dažniausiai ji ne tiksliai šiaurės-pietų bei rytų-vakarų krypties, o apie 20 laipsnių pasukta pagal laikrodžio rodyklę (Alytus, Gargždai, Kretinga, Kėdainiai, Marijampolė, Mažeikiai, Neringa, Palanga, Telšiai – ypač Žemaitijoje). Tobulai pagal pasaulio šalis orientuoti Elektrėnai (kuo tikriausiai nereiktų stebėtis) ir Utena, Visaginas ir Šiauliai išsidėstę įstrižai žemėlapio šalims.

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.