Dobra taksi služba mora biti varna, zanesljiva in hitra. Uporabnik se ne bo spuščal v podrobnosti: zanj je pomembno, da klikne gumb »Naroči« in čim prej prejme avto, ki ga bo odpeljal od točke A do točke B. Če v bližini ni avtomobilov, naj servis o tem takoj obvestiti, da stranka nima lažnih pričakovanj. Ampak, če se znak "No cars" pojavlja prepogosto, potem je logično, da bo oseba preprosto prenehala uporabljati to storitev in odšla h konkurentu.
V tem članku želim govoriti o tem, kako smo s pomočjo strojnega učenja rešili problem iskanja avtomobilov na območjih z nizko gostoto (z drugimi besedami, kjer na prvi pogled ni avtomobilov). In kaj je nastalo iz tega.
prazgodovina
Za klic taksija uporabnik opravi nekaj preprostih korakov, kaj pa se dogaja znotraj storitve?
| Uporabnik | Faza | Backend Yandex.Taxi |
|---|---|---|
| Izbere začetno točko | Pin | Uvajamo poenostavljeno iskanje kandidatov - pin search. Na podlagi najdenih voznikov je predviden čas prihoda – ETA v žebljičku. Izračuna se naraščajoči koeficient na določeni točki. |
| Izbere cilj, vozovnico, zahteve | Ponudba | Izdelamo pot in izračunamo cene za vse tarife ob upoštevanju naraščajočega koeficienta. |
| Pritisnite gumb "Pokliči taksi". | Naročilo | Zaženemo popolno iskanje avtomobila. Izberemo najprimernejšega voznika in mu ponudimo naročilo. |
na , и smo že pisali. In to je zgodba o iskanju voznikov. Ko je naročilo ustvarjeno, se iskanje izvede dvakrat: po Pin-u in po naročilu. Iskanje naročila poteka v dveh fazah: rekrutacija kandidatov in razvrščanje. Najprej se najdejo razpoložljivi kandidati za voznike, ki so najbližje na grafu ceste. Nato se uporabijo bonusi in filtriranje. Preostali kandidati so razvrščeni in zmagovalec prejme ponudbo naročila. Če se strinja, je razporejen na naročilo in gre na dostavno mesto. Če zavrne, pride ponudba do naslednjega. Če ni več kandidatov, se iskanje začne znova. To ne traja več kot tri minute, nato pa je naročilo preklicano in zažgano.
Iskanje po pinu je podobno iskanju po naročilu, le da se naročilo ne ustvari in samo iskanje izvede samo enkrat. Uporabljene so tudi poenostavljene nastavitve števila kandidatov in iskalnega radija. Takšne poenostavitve so potrebne, ker je pinov za red velikosti več kot naročil, iskanje pa je precej težavna operacija. Ključna točka naše zgodbe: če med predhodnim iskanjem na Pin-u ni bilo najdenih ustreznih kandidatov, vam ne dovolimo oddaje naročila. Vsaj tako je bilo včasih.
Tole je uporabnik videl v aplikaciji:
Iskanje avtomobilov brez avtomobilov
Nekega dne smo prišli do hipoteze: morda je v nekaterih primerih naročilo še vedno mogoče dokončati, tudi če na zatiču ni avtomobilov. Navsezadnje med zatičem in naročilom mine nekaj časa, iskanje naročila pa je popolnejše in se včasih večkrat ponovi: v tem času se lahko pojavijo razpoložljivi gonilniki. Vedeli smo tudi nasprotno: če so gonilnike našli na zatiču, ni bilo dejstvo, da jih bodo našli pri naročanju. Včasih izginejo ali pa vsi zavrnejo naročilo.
Da bi preverili to hipotezo, smo izvedli eksperiment: med iskanjem po Pin-u smo prenehali preverjati prisotnost avtomobilov za testno skupino uporabnikov, tj. imeli so možnost narediti "naročilo brez avtomobilov". Rezultat je bil precej nepričakovan: če avtomobila ni bilo na zatiču, potem je bil v 29% primerov najden kasneje - pri iskanju po naročilu! Poleg tega se naročila brez avtomobilov po odstotkih odpovedi, ocenah in drugih kazalnikih kakovosti niso bistveno razlikovala od rednih naročil. Rezervacije brez avtomobilov so predstavljale 5 % vseh rezervacij, a nekaj več kot 1 % vseh uspešnih potovanj.
Da bi razumeli, od kod prihajajo izvajalci teh ukazov, poglejmo njihove statuse med iskanjem po Pin-u:
- Na voljo: je bil na voljo, vendar iz nekega razloga ni bil vključen med kandidate, na primer, bil je predaleč;
- Po naročilu: je bil zaseden, a se je uspel rešiti oziroma postal dosegljiv za ;
- Zaseden: možnost sprejemanja naročil je bila onemogočena, nato pa se je voznik vrnil na linijo;
- Ni na voljo: voznika ni bilo na spletu, vendar se je pojavil.
Dodajmo še zanesljivost
Dodatna naročila so odlična, vendar 29 % uspešnih iskanj pomeni, da je 71 % časa uporabnik dolgo čakal in na koncu ni prišel nikamor. Čeprav to z vidika učinkovitosti sistema ni slaba stvar, uporabniku dejansko daje lažno upanje in izgublja čas, nakar se razburi in (morda) preneha uporabljati storitev. Da bi rešili ta problem, smo se naučili predvideti verjetnost, da bo najden naročen avto.
Shema je taka:
- Uporabnik pristavi žebljiček.
- Iskanje se izvede na zatiču.
- Če ni avtomobilov, napovedujemo: morda se bodo pojavili.
- In glede na verjetnost vam naročilo dovolimo ali ne dovolimo, vendar vas opozarjamo, da je gostota avtomobilov na tem območju v tem času majhna.
V aplikaciji je to izgledalo takole:
Uporaba modela vam omogoča, da natančneje ustvarite nova naročila in ne pomirjate ljudi zaman. To pomeni, da uravnavate razmerje med zanesljivostjo in številom naročil brez strojev z uporabo modela natančnega odpoklica. Zanesljivost storitve vpliva na željo po nadaljnji uporabi produkta, torej na koncu je vse odvisno od števila voženj.
Nekaj o natančnem priklicuEna od osnovnih nalog strojnega učenja je klasifikacijska naloga: dodelitev predmeta enemu od dveh razredov. V tem primeru rezultat algoritma strojnega učenja pogosto postane številčna ocena pripadnosti enemu od razredov, na primer ocena verjetnosti. Vendar so dejanja, ki se izvajajo, običajno binarna: če je avto na voljo, vam ga dovolimo naročiti, če ne, ga ne bomo. Če smo natančni, poimenujmo algoritem, ki ustvari numerično oceno, model, klasifikator pa pravilo, ki ga dodeli enemu od dveh razredov (1 ali –1). Za izdelavo klasifikatorja na podlagi modelne ocene morate izbrati ocenjevalni prag. Kako točno, je zelo odvisno od naloge.
Recimo, da delamo test (klasifikator) za neko redko in nevarno bolezen. Na podlagi rezultatov testa bodisi pošljemo pacienta na podrobnejši pregled bodisi rečemo: "Dobro, pojdi domov." Za nas je veliko hujše poslati bolnega človeka domov kot po nepotrebnem pregledati zdravega. Oziroma želimo, da test deluje pri čim več res bolnih ljudeh. Ta vrednost se imenuje recall =. Idealni klasifikator ima priklic 100 %. Degenerirana situacija je, da vse pošlješ na pregled, potem bo tudi odpoklic 100%.
Zgodi se tudi obratno. Na primer, izdelujemo sistem za testiranje študentov, ki ima detektor goljufanja. Če nenadoma preverjanje ne deluje za nekatere primere goljufanja, potem je to neprijetno, vendar ni kritično. Po drugi strani pa je izjemno slabo študente neupravičeno obtoževati nečesa, česar niso storili. To pomeni, da nam je pomembno, da je med pozitivnimi odgovori klasifikatorja čim več pravilnih, morda na škodo njihovega števila. To pomeni, da morate povečati natančnost = . Če pride do proženja na vseh objektih, bo natančnost enaka frekvenci definiranega razreda v vzorcu.
Če algoritem ustvari številčno vrednost verjetnosti, potem lahko z izbiro različnih pragov dosežete različne vrednosti natančnosti priklica.
V našem problemu je situacija naslednja. Odpoklic je število naročil, ki jih lahko ponudimo, natančnost je zanesljivost teh naročil. Tako je videti krivulja natančnosti priklica našega modela:
Obstajata dva skrajna primera: ne dovolite nikomur, da naroča in dovolite vsakomur, da naroča. Če nikomur ne dovolite, bo odpoklic 0: ne ustvarjamo naročil, vendar nobeno ne bo spodletelo. Če dovolimo vsem, bo odpoklic 100 % (prejeli bomo vsa možna naročila), natančnost pa 29 %, torej 71 % naročil bo slabih.
Kot znake smo uporabili različne parametre izhodišča:
- Čas/kraj.
- Stanje sistema (število zasedenih strojev vseh tarif in pinov v bližini).
- Iskalni parametri (radij, število kandidatov, omejitve).
Več o znakih
Konceptualno želimo razlikovati med dvema situacijama:
- "Globoki gozd" - trenutno tukaj ni avtomobilov.
- "Nesrečno" - obstajajo avtomobili, vendar pri iskanju ni bilo primernih.
En primer »nesreče« je, če je v petek zvečer v središču veliko povpraševanja. Naročil je veliko, ljudi veliko, voznikov pa premalo za vse. Lahko se izkaže tako: v zatiču ni ustreznih gonilnikov. Toda dobesedno v nekaj sekundah se pojavijo, ker je v tem času na tem mestu veliko voznikov in njihov status se nenehno spreminja.
Zato so se različni sistemski indikatorji v bližini točke A izkazali za dobre lastnosti:
- Skupno število avtomobilov.
- Število avtomobilov po naročilu.
- Število avtomobilov, ki niso na voljo za naročanje v statusu »Zasedeno«.
- Število uporabnikov.
Konec koncev, več kot je avtomobilov, večja je verjetnost, da bo eden od njih na voljo.
Pravzaprav nam je pomembno, da se ne le najdejo avtomobili, temveč tudi uspešna potovanja. Zato je bilo mogoče predvideti verjetnost uspešnega potovanja. Vendar smo se odločili, da tega ne storimo, saj je ta vrednost zelo odvisna od uporabnika in voznika.
Algoritem za usposabljanje modela je bil . Podatki, pridobljeni s poskusom, so bili uporabljeni za usposabljanje. Po izvedbi je bilo treba zbrati podatke o usposabljanju, kar je včasih omogočilo majhnemu številu uporabnikov, da naročijo proti odločitvi modela.
Rezultati
Rezultati poskusa so bili pričakovani: uporaba modela vam omogoča, da znatno povečate število uspešnih potovanj zaradi naročil brez avtomobilov, vendar brez ogrožanja zanesljivosti.
Trenutno je mehanizem zagnan v vseh mestih in državah in z njegovo pomočjo se zgodi približno 1% uspešnih potovanj. Poleg tega v nekaterih mestih z nizko gostoto avtomobilov delež takih potovanj doseže 15%.
Druge objave o Taxi tehnologiji
Vir: www.habr.com