Väga suures plaanis on kogu tiimil üks ülesanne – tagada hea hinnaga ja mugavad sõidud reisijate jaoks rohkem kui 40 linnas, kus tegutseme, ja seda nii, et sõitja jaoks oleks auto kõige rohkem 3 minuti kaugusel. Eesmärk kõlab lihtsalt, aga selle jaoks vajalikud tegevused jagunevad väga paljude eri valdkondade vahel.

Üks esmaseid lahendamist vajavaid küsimusi on see, kuidas tagada, et 24/7 oleksid autojuhid õigel ajal ja õiges kohas. Platvormi tasemel on see väga mitmemõõtmeline optimiseerimisülesanne. Lahendusest sõltub vahetult ettevõtte tulemus – inimesed kas saavad Taxify’st auto mõne minutiga või otsustavad mõne muu transpordiviisi kasuks.

Selle jaoks, et stabiilselt usaldusväärset teenust pakkuda, peame näiteks ennustama tellimusi juba enne, kui need toimuvad, ja tasakaalustama nõudlust ja pakkumist dünaamilise hinnastamise abil. Nutikas dispetšersüsteem peab tagama, et maksimaalselt suur hulk neist, kes tellimust tegema asusid, ka lõpuks edukalt sõidu tehtud saavad.

Nõudlust mõjutavad ka süsteemi seisukohalt ebareeglipärased sündmused – kontserdid, tähtpäevad, ilm. Siin peavad arendajad ja andmeteadlased tegema koostööd iga linna operatiivjuhtimisega tegeleva tiimiga. Kui vaatame tulevikku, siis isesõitvate autode puhul muutub konteksti tajumine veelgi kriitilisemaks kui inimjuhtide puhul, kes suudavad ka ebatäieliku andmestiku tingimustes oma tegevust korrigeerida.

Arvestades järjest kasvavat nõudlust rakenduse vastu, siis kuidas peavad vastu skaleerimiseks varasemalt loodud süsteemid?

Teenindame täna 10 miljonit sõitjat ja 500 000 autojuhti üle maailma. See tähendab, et väga palju meie tööst peab olema automatiseeritud.

Kuna oleme Taxify kasvu algusest peale uskunud ja usume ka praegu, siis oleme paljudes arhitektuuri puudutavates otsustes võtnud arvesse kasvupotentsiaali. Süsteemide disainimisel arvestame pigem kümneid kordi suurema mahuga ja mõtleme, et kuidas kõik omavahel töötab ja püüame otsida võimalikke probleeme.

Ülesande teeb keerulisemaks see, et tegu on reaalajasüsteemidega – süsteemi iga otsus omab väärtust vaid lühikese piiratud aja jooksul. Näiteks kui me otsime, milline auto suudaks klienti kõige kiiremini teenindada, siis selle otsuse peame tegema sekundite jooksul. Juhul kui otsus hilineb, tähendab see halvimal juhul, et seda sõitu ei toimu.

Teisest küljest on see arvutuslikult keeruline ülesanne: arvutama peab kõikide autode ajaliselt lühima tee kliendini; peab arvesse võtma masinõppe mudeleid, mis arvestavad iga juhi isikliku kiirusega; vaatama üle kõik hetkel sõidus olevad autod, kes lõpetavad sõitu uue tellimuse läheduses ning ennustama nende saabumisaja; vaatama, kuidas liiklus mõjutab kiirust ja ennustama liikluse muutust. Aafrikas teenindame ka mootorrattureid ja nemad tekitavad oma teed, mida peab arvesse võtma. Täna jooksevad Taxify süsteemid sadades serverites ja teenindavad kümneid tuhandeid päringuid igas sekundis.

Teine näide pärineb finantsvaldkonnast. Äpisisesed maksed toovad meie ärimahtude juures kaasa riski, et pahalased püüavad meie süsteeme petta või krediitkaardipettusteks kasutada. Masinõpe võimaldab meil aga selliseid probleeme juba varajases staadiumis märgata ja ennetada.

Väga suur osa skaleerimisest ongi seotud andmeteaduse ja masinõppega, mis on Taxify’s kasvava tähtsusega.

Taxify äpp on läbi aastate läbi teinud mitmeid eluetappe ning iga mõne aja tagant disaini ning suunda muudetakse. Mida toob tulevik?

Muudatused on tehnoloogiateenuste loomulik osa, kuna tihti pakub just tehnoloogia võimalust toodet oluliselt parandada. Need masinõppel põhinevad võimalused, mida täna kasutame, ei olnud 4-5 aastat tagasi veel mõeldavad. Lisaks muutuvad mobiiltelefonid suuremaks, kasvab ekraani resolutsioon ja edasi arenevad operatsioonisüsteemid. Muutuvad ka inimeste ootused tehnoloogiale.

Aja jooksul oleme teinud muudatusi, et äpi kasutamist kiiremaks ja mugavamaks muuta. Muudame ka disaini, kuid suurem rõhk on kasutajakogemusel. Tuues näiteks ühe viimase sõidukikategooriaid puudutava uuenduse: selle tulemusena saame teha tellimuse asukoha määramist täpsemaks, väheneb valesse kohta tellitud tellimuste arv, ning kategooria valikul näidata rohkem kategooriaid kui korraga ekraanile mahub. Muudatuste mõju mõõdame ja teeme A/B teste, et olla kindlad, et muudatus tõepoolest kasutaja elu paremaks tegi.

Taxify-sugused laiatarberakendused on väga palju kujundanud kasutajate arusaama sellest, kuidas näeb välja teenuse eest tasumine. Täna tundub normaalne, et autost välja astudes ei pea sularaha- või kaardimakse pärast vaeva nägema. Toidupoest me ilma kaarti viipamata veel välja astuda ei saa, aga tõenäoliselt jõuame ka selleni ühel päeval.

Kui Taxify äpp on juba praegu aidanud ära kaotada ebavajalikke samme teenuse kasutamisel, nii-öelda “hõõrdumist” (friction), siis trend ongi selle “hõõrdumise” vähenemise suunas. Kui inimene teab, et igal ajahetkel on auto temast nupuvajutuse kaugusel ja mõne minutiga ukse ees, siis see muudab tema suhtumist kogu transporti.

Paljud kasutajad on avaldanud pahameelt selle üle, et rakendus näitab juhtide saabumisaegu enne tellimist justkui “lambist”. Mida Taxify selle mure lahendamiseks teeb?

Tegu on keeruka olukorraga ja see on hea näide meie süsteemide reaalajalisest iseloomust.

Toon väga lihtsustatud näite – oletame, et meil on kaks klienti, kes tellivad autot samast asukohast, ja kaks vaba autot, üks on 2 minuti kaugusel ja teine 8 minuti kaugusel. Mõlemad kliendid näevad saabumisajaks 2 minutit, kuna täpselt nii kaugel on lähim auto.

Kui nüüd mõlemad kliendid enam-vähem samal ajal ka auto tellivad, siis tahes-tahtmata jõuab üks neist tellimustest kohale esimesena, olgu siis kasvõi 0,01 sekundit varem. Selle tulemusena saab üks klient auto lubatud 2 minutiga, teine saab aga järjekorras järgmise auto, mis asus 8 minuti kaugusel. Teise kliendi vaatenurgast ongi lubatud saabumisaeg muutunud.

Selline olukord tekib eelkõige piiratud pakkumise olukorras: kui antud piirkonnas on vähe autosid või on tipptund. Lisaks tuleb mängu olukord, kus lähim juht ei soovi tellimust vastu võtta.

Mida siis teha? Oleks võimalik näidata saadaval olevate autode keskmist saabumisaega, ent selle miinuseks oleks ebatäpsemad hinnangud kõigile klientidele. Veel üks võimalus on näidata saabumisaega vastavalt tõenäosusele, et tellimus toimub, ning vastava koefitsendiga saabumisaega muuta.

Täna püüame seda olukorda peamiselt lahendada masinõppe mudelite abil ennustamisega ja dünaamilise hinnastamisega. Viimane tagab selle, et rohkem juhte on sõitmas ja kriitilisemad klienditellimused saavad täidetud. Kliendid, kes on pigem nõus tipptunni möödumist ootama, saavad sõidu tehtud pisut hiljem.

Mudelite loomise ja mustrite ennustamise kallal töötab aga meie andmeteadlaste meeskond, äsja alustasime koostööd ka Tartu Ülikooli arvutiteaduse instituudiga. Juba täna suudame näiteks ilmaprognoosist lähtuvalt ennustada muudatusi nõudluses ja vastavalt vajadusele juhte aktiveerida.

Senise töö tulemusena on Tallinnas täna keskmine saabumisaja ennustamise viga alla ühe minuti.

Internetikommuunidest on näha paljut, mida rakenduses näha soovitakse, näiteks sõitude ette tellimise võimalus või jootraha võimalus. Miks neid funktsioone implementeeritud pole ning on see pigem äriline või tehniline otsus?

Ideid, kuidas rakendust täiendada, on tõepoolest palju ja positiivsest küljest näitab see, kuidas inimestele Taxify teenus korda läheb. Paljud pakutud ideed on ka meile väga hästi tuttavad, aga kuna oleme kasvanud ülikiiresti ja ideid on alati rohkem kui töökäsi, siis küsimus on vaid selles, mis tähtsuse järjekorras kõrgemal seisab. Meie ideede nimekirjas jagub tööd aastateks, nii et analüüsime alati, millisel ideel on suurim mõju Taxify kasutajatele globaalselt.

See on ka üks põhjus, miks avasime arenduskeskuse Bukarestis. Nii saame kiiremini oma arendustiimi tipptasemel inseneride võrra kasvatada ning järjest rohkem põnevaid uuendusi välja tuua.

Rakendus on aja jooksul kasvanud. Kas ja millises mahus on rakenduses alles veel koodi, mis oli seal selle esimeses versioonis?

Androidi puhul on nii juhi- kui kliendirakendus ühel korral täielikult ümber kirjutatud. iOS rakenduses on algset koodi järgi ligi 30%. Suurem osa süsteemi keerukusest asub aga serverites.