Добрата таксиметрова услуга трябва да бъде безопасна, надеждна и бърза. Потребителят няма да навлиза в подробности: за него е важно да кликне върху бутона „Поръчай“ и възможно най-бързо да получи автомобил, който ще го отведе от точка А до точка Б. Ако наблизо няма коли, сервизът трябва незабавно информирайте за това, така че клиентът да няма неверни очаквания. Но ако знакът „Без автомобили“ се появява твърде често, тогава е логично човек просто да спре да използва тази услуга и да отиде при конкурент.
В тази статия искам да говоря за това как, използвайки машинно обучение, решихме проблема с търсенето на автомобили в райони с ниска плътност (с други думи, където на пръв поглед няма автомобили). И какво излезе от това.
праистория
За да извика такси, потребителят извършва няколко прости стъпки, но какво се случва вътре в услугата?
| Потребител | етап | Backend Yandex.Taxi |
|---|---|---|
| Избира началната точка | щифт | Пускаме опростено търсене на кандидати - pin search. Въз основа на намерените драйвери се прогнозира времето за пристигане - ETA в щифта. Изчислява се нарастващият коефициент в дадена точка. |
| Избира дестинация, тарифа, изисквания | Оферта | Изграждаме маршрут и изчисляваме цените за всички тарифи, като вземаме предвид нарастващия коефициент. |
| Натиска бутона „Повикване на такси“. | ред | Пускаме пълно търсене на автомобила. Избираме най-подходящия шофьор и му предлагаме поръчка. |
Около , и вече писахме. И това е история за намирането на драйвери. Когато се създаде поръчка, търсенето се извършва два пъти: на Pin и на поръчката. Търсенето на поръчка протича на два етапа: набиране на кандидати и класиране. Първо се намират наличните кандидат-шофьори, които са най-близо до пътната графика. След това се прилагат бонуси и филтриране. Останалите кандидати се класират и победителят получава оферта за поръчка. Ако е съгласен, той се назначава за поръчката и отива до точката на доставка. Ако той откаже, тогава предложението идва при следващия. Ако няма повече кандидати, търсенето започва отначало. Това продължава не повече от три минути, след което поръчката се анулира и изгаря.
Търсенето на Pin е подобно на търсенето на поръчка, само че поръчката не се създава и самото търсене се извършва само веднъж. Използват се и опростени настройки за брой кандидати и радиус на търсене. Такива опростявания са необходими, защото има един порядък повече пинове, отколкото поръчки, а търсенето е доста трудна операция. Ключовият момент за нашата история: ако по време на предварителното търсене не са намерени подходящи кандидати на Pin, ние не ви позволяваме да направите поръчка. Поне така беше навремето.
Ето какво видя потребителят в приложението:
Търсене на коли без коли
Един ден измислихме хипотеза: може би в някои случаи поръчката все още може да бъде изпълнена, дори и да няма коли на щифта. В крайна сметка минава известно време между щифта и поръчката и търсенето на поръчката е по-пълно и понякога се повтаря няколко пъти: през това време може да се появят налични драйвери. Знаехме и обратното: ако бяха намерени драйвери на щифта, не беше факт, че ще бъдат намерени при поръчка. Понякога изчезват или всички отказват поръчката.
За да проверим тази хипотеза, стартирахме експеримент: спряхме да проверяваме наличието на автомобили по време на търсене на ПИН за тестова група потребители, т.е. те имаха възможност да направят „поръчка без автомобили“. Резултатът беше доста неочакван: ако колата не беше на щифта, тогава в 29% от случаите тя беше намерена по-късно - при търсене по поръчка! Освен това поръчките без автомобили не се различават значително от обикновените поръчки по отношение на процента на анулиране, оценки и други показатели за качество. Резервациите без автомобили представляват 5% от всички резервации, но малко над 1% от всички успешни пътувания.
За да разберем откъде идват изпълнителите на тези заповеди, нека да разгледаме статусите им по време на търсене в Pin:
- На разположение: беше наличен, но по някаква причина не беше включен в кандидатите, например беше твърде далеч;
- На поръчка: беше зает, но успя да се освободи или да стане достъпен за ;
- Зает: възможността за приемане на поръчки беше деактивирана, но след това водачът се върна на линията;
- Не е наличен: шофьорът не беше онлайн, но се появи.
Нека добавим надеждност
Допълнителните поръчки са страхотни, но 29% от успешните търсения означават, че в 71% от случаите потребителят е чакал дълго време и в крайна сметка е стигнал до никъде. Въпреки че това не е лошо нещо от гледна точка на ефективността на системата, то всъщност дава на потребителя фалшива надежда и губи време, след което той се разстройва и (евентуално) спира да използва услугата. За да разрешим този проблем, се научихме да прогнозираме вероятността да бъде намерена поръчана кола.
Схемата е следната:
- Потребителят поставя щифт.
- Извършва се търсене на щифта.
- Ако няма коли, прогнозираме: може би ще се появят.
- И в зависимост от вероятността, ние ви позволяваме или не ви позволяваме да направите поръчка, но ви предупреждаваме, че гъстотата на автомобили в този район по това време е ниска.
В приложението изглеждаше така:
Използването на модела ви позволява да създавате нови поръчки по-точно и да не успокоявате хората напразно. Тоест, за регулиране на съотношението на надеждност и броя на поръчките без машини, използвайки модела за прецизно извикване. Надеждността на услугата влияе върху желанието да продължите да използвате продукта, т.е. в крайна сметка всичко се свежда до броя пътувания.
Малко за прецизното припомнянеЕдна от основните задачи в машинното обучение е задачата за класификация: присвояване на обект на един от два класа. В този случай резултатът от алгоритъма за машинно обучение често се превръща в числена оценка на членството в един от класовете, например оценка на вероятността. Въпреки това действията, които се извършват, обикновено са двоични: ако колата е налична, ще ви позволим да я поръчате, а ако не, няма да я направим. За да бъдем конкретни, нека наречем алгоритъм, който произвежда числена оценка, модел, а класификатор правило, което го присвоява на един от двата класа (1 или –1). За да направите класификатор въз основа на оценката на модела, трябва да изберете праг за оценка. Как точно зависи до голяма степен от задачата.
Да предположим, че правим тест (класификатор) за някакво рядко и опасно заболяване. Въз основа на резултатите от теста или изпращаме пациента за по-подробен преглед, или казваме: „Добре, прибирай се вкъщи“. За нас да изпратим болен човек у дома е много по-лошо от ненужното изследване на здрав човек. Тоест искаме тестът да работи при възможно най-много наистина болни хора. Тази стойност се нарича recall =. Идеалният класификатор има 100% припомняне. Изродена ситуация е да изпратиш всички на преглед, тогава и изтеглянето ще бъде 100%.
Случва се и обратното. Например, ние правим система за тестване на студенти и тя има детектор за измама. Ако внезапно проверката не работи за някои случаи на измама, това е неприятно, но не е критично. От друга страна е изключително лошо да се обвиняват несправедливо учениците в нещо, което не са направили. Тоест за нас е важно сред положителните отговори на класификатора да има възможно най-много верни, може би в ущърб на техния брой. Това означава, че трябва да увеличите максимално точността = . Ако задействането се случи на всички обекти, тогава точността ще бъде равна на честотата на определения клас в извадката.
Ако алгоритъмът генерира числена стойност на вероятността, тогава чрез избиране на различни прагове можете да постигнете различни стойности за прецизно извикване.
В нашия проблем ситуацията е следната. Припомнянето е броят на поръчките, които можем да предложим, прецизността е надеждността на тези поръчки. Ето как изглежда кривата на прецизно припомняне на нашия модел:
Има два крайни случая: не позволявайте на никого да поръчва и позволявайте на всеки да поръчва. Ако не разрешите на никого, тогава извикването ще бъде 0: ние не създаваме поръчки, но нито една от тях няма да се провали. Ако позволим на всички, тогава изземването ще бъде 100% (ще получим всички възможни поръчки), а прецизността ще бъде 29%, т.е. 71% от поръчките ще бъдат лоши.
Използвахме различни параметри на началната точка като знаци:
- Време/място.
- Състояние на системата (брой заети машини от всички тарифи и щифтове в близост).
- Параметри на търсене (радиус, брой кандидати, ограничения).
Повече за знаците
Концептуално искаме да разграничим две ситуации:
- „Дълбока гора“ - тук няма коли по това време.
- „Нещастен“ - има коли, но при търсене нямаше подходящи.
Един пример за „лош късмет“ е, ако има голямо търсене в центъра в петък вечер. Има много поръчки, много желаещи, а шофьори не стигат за всички. Може да се окаже така: в щифта няма подходящи драйвери. Но буквално за секунди се появяват, защото по това време има много шофьори на това място и статусът им непрекъснато се променя.
Следователно различни системни индикатори в близост до точка А се оказаха добри характеристики:
- Общ брой коли.
- Брой коли по поръчка.
- Броят автомобили, недостъпни за поръчка в състояние „Зает“.
- Брой потребители.
В крайна сметка, колкото повече коли има, толкова по-вероятно е една от тях да стане достъпна.
Всъщност за нас е важно не само да се намират автомобили, но и да се правят успешни пътувания. Следователно беше възможно да се предвиди вероятността за успешно пътуване. Но решихме да не правим това, защото тази стойност зависи до голяма степен от потребителя и драйвера.
Алгоритъмът за обучение на модела беше . Данните, получени от експеримента, са използвани за обучение. След внедряването трябваше да се съберат данни за обучение, което понякога позволяваше на малък брой потребители да поръчват срещу решението на модела.
Резултати от
Резултатите от експеримента бяха според очакванията: използването на модела ви позволява значително да увеличите броя на успешните пътувания поради поръчки без автомобили, но без компромис с надеждността.
В момента механизмът е пуснат във всички градове и държави и с негова помощ се осъществяват около 1% от успешните пътувания. Освен това в някои градове с ниска гъстота на автомобили делът на такива пътувания достига 15%.
Други публикации за Такси технология
Източник: www.habr.com