Category: Programavimas

Ar šiuolaikinis dirbtinis intelektas jau padarė proveržį?

Filosofija, Pastebėjimai, Programavimas, Visuomenė, ,

1726 metais Džonatanas Swiftas išleido savo populiariausią knygą „Guliverio kelionės“, kurioje buvo aprašoma ir kelionė į skraidančią salą Laputą. Salos gyventojai – labai protingi, bet nelabai tikrame gyvenime besigaudantys mokslininkai, kurie vis prigalvoja visokiausių keistenybių, turinčių visiems palengvinti gyvenimą. Vienas toks išradimas yra milžiniška mašina su daugybe ratų ant kurių pritvirtintos lentelės su įvairiausiais žodžiais, paimtais iš išradėjo jaunystės užrašų: patempus virvelę tie ratai sukasi ir žodžiai susidėlioja daug maž atsitiktine tvarka į sakinius. Dažniausiai ne itin prasmingus, bet kartais juose yra reikšmingų frazių, kurias kaip mat į knygas surašo penkios dešimtys prie mašinos dirbančių studentų. Mašinos išradėjas tiki, kad žmonijai nuo šiol galvoti nebereikės, nes visas pasaulio knygas rašys ši jo mašina. Mašina nuo šiol atras visus pasaulio dėsnius ir tik beliks juos užrašyti į knygas. Tiesa, tam reiktų papildomo finansavimo, nes darbas su viena mašina lėtokas…

Neseniai pasirodęs GPT-3 (generative pre-trained transformer) dirbtinio intelekto modelis iš OpenAI veikia panašiu principu: apmokius modelį milžinišku kiekiu teksto jis randa sąsajas tarp visokiausių terminų ir, uždavus kokį klausimą, gali sugeneruoti visai protingą atsakymą. Paprašius, atsakymą jis gali pateikti ir eilėraščio, ar mokslinio straipsnio stiliumi, gali imituoti žiniasklaidos antraštes, programavimo kalbos kodą, formalaus dokumento tekstą ar tiesiog kaip anekdotą. Norint išbandyti GPT modelį, programavimo žinių nereikia – OpenAI padarė galimybę tiesiog pasikalbėti su šiuo dirbtinio intelekto modeliu. Rezultatai tikrai pranokstantys lūkesčius, generuojamas tekstas kokybiškas. Lyg kalbėtumeisi su lingvistikos profesoriumi, mokančiu kalbėti begale kalbų ir stilių, o kartu ir tobulai žinančiu visus faktus, kuriuos galima rasti Wikipedijoje. Vienintelis minusas: to profesoriaus logika yra kaip maždaug ketverių metų vaiko ir sudėtingų uždavinių jis išspręsti (kol kas?) nesugebės. Jei paklausi, koks Jono mamos trečio sūnaus vardas, jeigu jis turi brolius Petrą ir Paulių, GPT-3 tokio klausimo neatsakys. Bet, kita vertus, beveik tobulai sugeneruos tau skundą oficialioms institucijoms sklandžia biurokratine kalba, jeigu nori jiems pasiskųsti apie nebarstomas gatves. Sutaupo laiko paprastoms užduotims.

Daug kam toks geras teksto generavimas gali pasirodyti kone stebuklingas, tad ir noriu surašyti čia savo mintis ką apie tai šiuo metu manau. Tikėtina, kad mano spėjimai gali ir stipriai prašauti, bet norisi turėti juos užfiksuotus raštu, mat žmogaus atmintis mėgsta jam pačiam pataikauti: prisimeni tik tuos dalykus, kuriuos tiksliai atspėjai ir netyčia pamiršti savo spėjimų klaidas. Visada pamenu, kad 2015-2016 metais buvau įsitikinęs, jog Teslos ambicija 2020-aisiais turėti self-driving mašiną yra visiškai nereali. Esu linkęs pamiršti, jog 2008-aisiais tikėjau, kad Ukraina (lygiai kaip ir Rusija!), nenumaldomais septynmyliais žingsniais juda link vakarų ir ten po kelių metų nebeliks korupcijos.

Dažnai su naujomis, daug žadančiomis technologijomis, atsitinka taip, kad trumpuoju laikotarpiu jos nepateisina į jas sudėtų (per daug didelių) lūkesčių. Pradinei euforijai praėjus, pastebima, kad visgi technologija turi kažkokių ribojimų, ne visada veikia idealiai. Paaiškėja, kad bet kuris vaistas nuo visų ligų turi tam tikrus šalutinius poveikius, ar negydo tam tikrų simptomų – tada minia greitai persimeta ant naujos panacėjos. GPT modelio problema – logikos trūkumas. Generuojamas tekstas gražus, iš pažiūros protingas ir netgi logiškas, bet atidžiau pažiūrėjus, ta logika pasirodo esanti kreivoka ir pradeda nebekelti pasitikėjimo. GPT generuojamas tekstas man labai panašus į sapnus: kol sapnuoji, viskas atrodo aišku ir tvarkinga, bet pabudęs loginio ryšio ne visada atseki. Pasirodo, jog plaukiojai ant nendrinio plausto baseine, o jis tapo krokodilu ir kaip tik tau pabundant bandė tave sugriebti už kojos. Kol sapnavai, plaustas iš nendrių ir krokodilas uždarame baseine atrodė logiškiausias dalykas pasaulyje, bet geriau pagalvojus belieka stebėtis, kodėl sapno logika taip skiriasi nuo realios. Taip ir su GPT generuojamu tekstu: skamba gerai, bet kas kartą turi tikrinti, ar jo logika ne iš sapnų pasaulio. Pasitikėti tokiu tekstu (kol kas) taip pat sunku, kaip patikėti svarbų darbą keturmečiui: gal rezultatas ir bus pasiektas, bet jis nebūtinai bus toks, kokio tikėjaisi.

Sunkiausia, kad kuo sudėtingesnis uždavinys, tuo atidžiau reikia tikrinti rezultatą. GPT gali generuoti programavimo kodą ir stebėtinai gerai išspręsti paprastas programavimo užduotis. Užtenka pažiūrėti į šios bibliotekos demonstracinį filmuką. Manau, kad didžiausia problema tame, kad davus sudėtingą užduotį ir gavus klaidingą rezultatą (t.y. jeigu modelis sugeneruoja klaidingą kodą), reikia be galo daug žinių atsekti, kur modelis suklydo ir sugeneruotą kodą pataisyti. Kitaip sakant, dirbtinis intelektas lengvus dalykus išsprendžia lengvai, o sudėtingų dalykų išspręsti nemoka (makes easy things easy and hard things impossible, tuo tarpu žmonėms gana lengvus uždavinius spręsti sunku, bet jie bent jau sugeba su daug pastangų išspręsti sudėtingus, humans make easy things hard, but hard things possible). Dar blogiau: jis ne visada (niekada?) nesugeba atskirti, kurios problemos yra lengvos, o kurios sudėtingos. Neaišku kur yra riba, kur modeliu dar vis galima pasitikėti, o kur jau reikia kuo ankstyvesnio žmogaus įsikišimo.

Tiesa, juk čia dar pati technologijos aušra, viskas tobulės. Juk ir naujas darbuotojas negalės iš karto tobulai atlikti užduoties. Skirtumas tas, kad žmogus kol kas gali turėti pajautimą, kad kažkas čia ne taip, gali, gavęs instrukciją „na, dar pagalvok, kažkaip tau gavosi nelogiškas atsakymas“, iš tiesų išmokti savo klaidas ir jas ištaisyti. Kol kas to GPT negali, o jei galėtų – būtume radę bendrinio dirbtinio intelekto (general artificial intelligence) Gralio taurę.

Kita vertus, ilguoju laikotarpiu tokios technologijos turi žymiai didesnį efektą nei buvo tikimasi, tik tas efektas pasireiškia visai kitokiais, netikėtais būdais. Tarkim interneto pradžioje buvo tikimasi, kad žmonės taps labai protingi, nes galės lengvai bet kada prieiti prie visų pasaulio bibliotekų resursų: realybėje visi laiką leidžia socialiniuose tinkluose ir internetą vartoja daugiausiai visai ne tekstinės informacijos vartojimui. Kur mus nuves dirbtinai generuojamo teksto perteklius? Tikėtina, kad tekstą skaitys dar mažiau žmonių. Kažkas, rašydamas elektroninį kvietimą į renginį užduos dirbtiniam intelektui užduotį sukurti tris išsamius Šekspyro plunksnos vertus paragrafus apie renginio išskirtinumą, kažkas, gavęs šį laišką, dirbtiniam intelektui duos užduotį tai išversti į tris žodžius „Petras kviečia alaus“, kad tik nereiktų tų trijų paragrafų skaityti. Jau dabar didžioji teksto dalis internete yra generuojama visai ne žmonėms, daugiausiai tekstų yra rašomi Google botams, kad jie aukščiai paieškose įvertintų vieną ar kitą puslapį.

Taigi, mano trumpos prognozės:

  • Dirbtinis intelektas išgyvens susižavėjimo fazę: juo bus galima daryti nuostabių dalykų, bet kartu pradės ryškėti ir jo trūkumai ir apribojimai
  • Po kelių metų dirbtinis intelektas ras savo pritaikymo nišų, bet jos nebeatrodys stebuklingos (kaip kad dabar nebeatrodo stebuklinga numerių nuskaitymo technologija įvažiuojant į parkingą)
  • Žemiausio lygio teksto rašytojams ateis labai sunkios dienos. Jau dabar automatiniai vertėjai ir teksto generatoriai gerai atlieka savo darbą, konkuruoti su jais beprasmiška.
  • Kita vertus, specializacija vis dar bus vertinga: versti grožinę literatūrą sunkiau nei techninę dokumentaciją. Kūrybiški žmonės, darantys kokybišką darbą, išliks vertingi. Dar vertingesni nei dabar: kaip kad tie, kurie rankomis mezga vienetinius megztinius Fareruose vis dar gali konkuruoti su Indijos ar Kinijos fabrikais.
  • Didžiausias žmogaus privalumas: jis gali suprasti, ko tiksliai reikia. Net jei programuotojų darbas pasikeis tiek, kad vietoje kodo rašymo jam reikės teikti užklausas dirbtiniam intelektui, išgyvens tie, kas geriausiai supranta kliento poreikius. Dirbtinis intelektas bus tik dar vienas įrankis darbui palengvinti.
  • Deja, kuo toliau, tuo mažiau bus vertinamas tekstas: jį lengva generuoti, o skaitančių jaunoje kartoje yra mažai: jau dabar atsakymų jie ieško video formatu ir geriau žiūrės problemą paaiškinantį filmuką Youtube ar TikTok nei perskaitys techninę dokumentaciją ar ilgą knygą. Tekstas reikalauja susikaupimo, o dėmesio trukmė stipriai sumažėjusi. Tekstas internete tampa svarbus tik automatinėms sistemoms. Botų generuojamas botams.
  • Vis dar didžioji žmonijos išmintis bus kaupiama knygose, ir, tikiuosi, jog jos vis dar bus daugiausiai rašomos ne dirbtinio intelekto. Pažiūrėsim, kiek būsiu atspėjęs po kokio dešimtmečio.

Mūrininkų vertybės duomenų sistemoms

Darbas, Filosofija, Programavimas, , ,

Skaitant Diana Darke knygos skyrių apie viduramžių mūrininkų gildijas man įstrigo jų deklaruojamos vertybės, kuriomis turėtų būti vadovaujamasi statyboje. Geras statinys turi būti gražus, tvirtas ir patogus. Kaip suprantu, šias vertybes perėmė ir vėlesnieji laisvieji mūrininkai, kurie fizinių akmenų jau nebetašė. Šių raštuose teisingas gyvenimas irgi stovi ant trijų kolonų: grožio, stiprybės ir išminties.

Dirbu su įvairiausiomis duomenų sistemomis, duomenų bazėmis ir jų analize. Tai ganėtinai toli iki viduramžių katedrų statybos, bet kažkiek panašumo stipriai prisimerkus įžiūrėti galima: tai sudėtingos sistemos, kurias ne vienerius metus kuria ištisos komandos žmonių, ir nebūtinai pagal vieną aiškų nekintamai patvirtintą detalųjį planą. Tikiu, kad ir kuriant duomenų sistemas galima vadovautis tomis pačiomis trimis vertybėmis.

Grožis. Duomenų ataskaitos turi būti ne vien funkcionalios, bet ir estetiškai gražios. Svarbu ne vien duomenų teisingumas, bet ir jų pateikimas: teisingai parinkti šriftai, spalvos, grafikų dizainas leidžia duomenis žymiai lengviau suprasti. Galutinis duomenų vartotojas dažniausiai yra ne programuotojas ar analitikas, o vadovas arba išorinis klientas, kuris tikriausiai neturi daug laiko ir noro gilintis į duomenų subtilybes, todėl viskas jam turi būti aišku iš pirmo žvilgsnio. Nereikia pamiršti teisingų grafikų ir ašių pavadinimų, legendų, santrumpų išaiškinimo, reikia visose ataskaitose naudoti tokias pačias spalvas ir datos formatus. Net jeigu ruoši tik paprastą Excelio ataskaitą, verta įdėti papildomai pastangų tam, kad ji būtų aiški ir graži, o ne atrodytų kaip plikas atsitiktinių skaičių kratinys.

Stiprybė. Duomenų sistemos turi būti „tvirtai suręstos“: jos neturi sugriūti papūtus stipresniam vėjui ar nežymiai pasikeitus aplinkai. Sistemas reikia stengtis kurti taip, kad pasikeitęs duomenų formatas paduodamas iš išorinio tiekėjo ilgam „neužlenktų“ viso duomenų ūkio. Faktas, kad duomenų struktūros nuolat keičiasi, vieni laukai atsiranda, kiti išnyksta. Faktas, kad keičiasi ir duomenų kiekiai. Faktas, kad kartais duomenys vėluoja. Faktas, kad kartais vienu metu ataskaitas nori pažiūrėti šimtus kartų daugiau vartotojų nei įprastai. Faktas, kad kartais duomenys dingsta ir fiziškai, tad reikia juos atstatyti iš atsarginės kopijos. Realybėje nutinka labai daug neplanuotų dalykų, tačiau duomenų sistema turi būti pakankamai stipri juos atlaikyti, ar bent jau suprasti, kada reikia neprikūrus dar didesnių problemų tvarkingai nuleisti rankas.

Patogumas. Visos kuriamos sistemos turi būti patogios klientui. Niekada nereikia pamiršti, jog dirbama klientui, o ne savo pačių patogumui: žali duomenys csv formatu yra patogūs analitikui, bet nesuprantami vadovui. Analitikui gal būt patogu duomenis pasiimti per SQL užklausą, bet gal būt klientui reikia tik nuolat po akimis matyti kelis pagrindinius skaičius. Nereikia pamiršti, kad klientas ne visada gali iki galo teisingai išreikšti savo poreikius: reikia stengtis suprasti, ką tais poreikiais klientas nori pasiekti. Gali būti, jog jis nori vienokios specifinės ataskaitos Excel formatu, bet iš tiesų jis tuos duomenis įkels į kitą sistemą ar ataskaitą – gali paaiškėti, jog lengviau duomenis ten patiekti tiesiogiai, o ne per Excel bylas. Duomenų sistemos sėkmę užtikrina patogus problemos sprendimas klientui, o ne vien tik aklas techninės specifikacijos išpildymas.

James Cortada IBM istorija

Istorija, Knygos, Programavimas, Vadyba, ,

James Cortada dirbo IBM berods 45-erius metus ir, išėjęs į pensiją, parašė virš septynių šimtų puslapių knygą apie šios kompanijos istoriją. Nemanau, kad „IBM: The Rise and Fall and Reinvention of a Global Icon“ pretenduoja būti labai objektyvi – tai žvilgsnis į IBM ilgamečio darbuotojo akimis, be didelės kritikos, daugiausia tik su nuomonėmis „iš vidaus“. Tad nereikia stebėtis, jog kompanija piešiama beveik vien tik teigiamomis spalvomis: inovacijų lyderė, technologijų etalonas ir panašiai. Net ir paskutinius tris dešimtmečius vykęs IBM nuosmukis nurašomas nekompetetingiems vadovams, kurie tik norėjo mažinti kaštus ir pasinaudodami finansų inžinerija išspausti kuo didesnę akcijos kainą. Bet IBM nuosmukis prasidėjo žymiai anksčiau, dar tada, kai jiems puikiai sekėsi ir kompaniją pradėjo valdyti pardavėjai bei „procesų vergai“, o ne technologijų žmonės. Su biurokratija ir per dideliais pažadais klientams toli nenuvažiuosi, net jeigu ir turi kone monopolinę rinką.

Nors tikrai ilgai tai buvo sėkminga strategija. Nuo pat 1940-ųjų IBM nesistengė būti inovacijų smaigalyje. IBM stiprybė buvo pardavėjai ir „customer service“:

Technology turned out to be less important than sales and distribution methods. Starting with UNIVAC, we consistently outsold people who had better technology because we knew how to put the story before the customers, how to install the machines successfully, and how to hang on to the customers once we had them.

James Cortada, „IBM: The Rise and Fall and Reinvention of a Global Icon“

Geras servisas ir puikūs pardavėjai leido IBM susikurti labai patogią rinkos poziciją: IBM buvo sinonimas žodžiui „patikima“. Padėjo ir tai, kad dėl didelės rinkos dalies visi imdavo laikyti IBM rinkos standartu, o tai padėdavo uždirbti krūvas pinigų iš visokiausių priedų, perfokortų (kurios, aišku, buvo patentuotos) ir panašių papildomų prekių ir paslaugų. Tik ši komfortabili pozicija neleido jiems greitai judėti naujose rinkose: stalinių kompiuterių era buvo beveik pražiopsota (o juk IBM turėjo tapti Microsoftu, tačiau negalėjo perlipti per save ir imti konkuruoti su savo didžiųjų serverių verslu, kuris ilgą laiką buvo aukso kasyklos), „debesis“ irgi visiškai pragrotas Amazonui, Google ir tam pačiam Microsoft. Prieš penkiolika metų kiek gyvybės įpūtė IBM noras tapti konsultacine programuotojų bendrove, bet pradėjus taupyti kaštus ir perkelti viską į Rytų Europą ir Indiją IBM prarado savo patikimumo veidą – ar bent jau taip mano autorius James Cortada: daugelis jo brangiai kainuojančių bendradarbių buvo atleisti taupant kaštus.

Knyga baigiasi ties 2018-ųjų pradžia ir ji vis dar kupina vilties, kad IBM renesansas jau čia pat už kampo – Watson ir dirbtinis intelektas viską išgelbės. Bet tai tik dar vienas pardavėjų, o ne inžinierių sukurtas produktas: IBM nuosmukis tęsiasi, o Watson neatrodo, jog pateisino viltis.

Kur Lietuvoje tolimiausia iki ežero?

Analizė, Lietuva, Programavimas, , ,

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.

Ką rinkčiausi duomenų ūkyje

Darbas, Programavimas, Python, , , ,

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.

Duomenų bazių testavimas

Analizė, Programavimas, ,

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.

Rožės monitoringas su Raspberry

Programavimas, , ,

Noriu pasigirti: žmonos paskatintas pirmą kartą su Raspberry Pi nuveikiau kažką sudėtingesnio nei vien tik pajungiau prie jo kamerą. Jai paklausus, ar nebūtų įmanoma sukonstruoti kokio nors prietaiso, stebinčio rožės dirvos temperatūrą, suėmė savotiškas azartas, ir jau kitą dieną stovėjau prie visiškai neaiškių daiktų kupinos vitrinos elektronikos komponentų parduotuvėje. Kažkokie sensoriai, laidukai, mikroschemos, montažinės dėžutės, rezistoriai ir kiti ten parduodami dalykai – nieko nesuprantu, nieko nežinau. Ar čia man reikia to, ar kito, ar skiriasi kuo DHT-22 nuo DHT-11, kokių ir kiek man reikia rezistorių (o jų iš vis pasirodo reikia?), o jei neturite BCM3008 mikroschemos kur Youtube mačiau kad man reiks, tai ar tiks kas nors kitas? Sakot ADC1115? Jei reiktų apie Hėgelio filosofiją pasikalbėti čiuvašų kalba, manau, kad jausčiausi pasimetęs mažiau nei toje elektronikos parduotuvėje atsakinėdamas į konsultanto klausimus.

Sistemos bandymai

Visgi nukovęs glėbį keistų komponentų, pergalėjau save, praleidau kelis vakarus prie įvairiausių forumų bei straipsnių internete ir sukonstravau kažką veikiančio. Prie Raspberry prijungiau oro temperatūros ir drėgmės jutiklį (net kažkiek apygraibomis supratau, kodėl dar prie jo reikia pajungti rezistorių) ir dirvos drėgmės sensorių. Pastarasis duoda analoginį signalą, tad reikėjo prijungti ir analoginio-diskretinio signalo konvertavimo mikroschemą. Kol kas dar jos nelitavau, tad bet koks sujudinimas dažniausiai reiškia, jog vėl kažkas nusimušė. Buvo šiek tiek vargo.

Nustebau, kad visgi tie visokie su geležimi ir mikroschemomis susiję dalykai buvo ganėtinai nesudėtingi – programavimas tikriausiai sunkiau įveikiamas niekada su tuo nesusidūrusiems. O čia tik reikia teisingai sujungti laidukus, nieko sudėtingo. Ir dar gauni tam tikrą pasitenkinimą, kai matai, jog fiziškai tavo padarytas daiktas veikia.

Viso to pasekmė: rožės monitoringo svetainė, kurioje beveik realiu laiku galima matyti balkone esamą oro temperatūrą, santykinę drėgmę ir dirvos „prilaistymo“ procentą. Pastarasis kol skaičiuojamas gana komplikuotai, mat daviklis duoda įtampą, pagal kurią sukalibruoti drėgnumą reikia pačiam: 100 proc. buvo tik dirvą paliejus, o 0 proc atitiko sensoriaus įtampą jį ištraukus iš dirvos. Tikėtina, kad kažkur ties 50 proc drėgnumu jau galima bus siųsti įspėjimą, jog rožę reikia vėl laistyti. Matyt, reikės ir kitų korekcijų: dieną kylant temperatūrai, dirvos pralaidumas elektrai didėja, tad sensorius mano, jog dirva tampa drėgnesnė.

Sujungtos mikroschemos

Naudotos detalės: ADC1115 mikroschema, DHT–22 temperatūros sensorius, YH–69 dirvos sensorius, Raspberry Pi B series.

Nick Bostrom: „Superintelligence“

Filosofija, Knygos, Pastebėjimai, Programavimas, ,

Kai perskaičiau Max Tegmark’o „Life 3.0“, buvau piktas – tema įdomi ir aktuali, bet skaitai ir supranti, kad autoriui kompetencijos dirbtinio intelekto klausimais mažokai. Tad ėmiausi Nick Bostromo knygos „Superintelligence“, nes ją dauguma laiko žymiai rimtesne.

Šioje knygoje esminiai skyriai yra patys pirmieji, kuriuose diskutuojama apie tai, kada (ir ar iš vis) įmanoma pasiekti dirbtinio intelekto sprogimą: kada jau turėsime tokį dirbtinį intelektą, kuris pats besimokydamas mus aplenks savo protu. Visi kalbinti ekspertai teigė, jog arba po kokio šimtmečio, arba niekada. Likusi didžioji knygos dalis yra „kas būtų, jeigu būtų“ pasvarstymai, kurie gal ir įdomūs ir arčiau žemės nei Max Tegmarko svaičiojimai apie Daisono sferas, bet vis tiek palieka intelektualinio savismaginimosi prieskonį.

Manau, kad didžiausia problema, jog į dirbtinį intelektą žiūrima kaip į technologinę problemą, neturint filosofinio pagrindo. Vien dėl to Asimovas robotizacijos klausimais gali pasakyti žymiai daugiau nei Bostromas – ir Asimovo apysakos net po penkiasdešimties metų atrodo aktualesnės. Dirbtinio intelekto suvaldymas nėra vien tik mechaninis technologinis sprendimas – tai žymiai gilesnė problema. Mes juk net nežinome, kaip dirbtiniam intelektui suformuluoti optimizacijos uždavinį: nepakanka pasakyti, jog norime, kad žmonija būtų laimingesnė, nes iš karto kyla klausimas, kaip tą laimę apibrėžti ir išmatuoti. Ir čia algoritmai bejėgiai.

Knygoje yra ir daug keistokų bei naivokų svarstymų apie žmoniją: kaip čia juos suvaldyti, kad kas nors piktybiškai neimtų kurti pavojingo dirbtinio intelekto. Sako, tereikia tik tvirto susitarimo ir melo detektoriaus, tik skaitant neapleidžia toks jausmas, kad autorius nelabai supranta, kaip veikia pasaulis, ir iš istorijos nėra daug ko išmokęs: galėjai tartis kiek tik nori, bet atominę bombą vis tiek visi susikūrė, kas tik labai norėjo. O melo detektorius, kaip techninis sprendimas irgi itin naivus – ar bent įmanoma tiksliai apibrėžti, kas yra melas, o kas tiesa?

Lietuvos miestų gatvės pagal pasaulio šalis

Analizė, Lietuva, Programavimas, Python, , ,

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.

Robotas irgi žmogus

Analizė, Darbas, Pastebėjimai, Programavimas, , ,

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.