En bra taxitjänst ska vara säker, pålitlig och snabb. Användaren går inte in på detaljer: det är viktigt för honom att han klickar på "Beställ"-knappen och får en bil så snabbt som möjligt som tar honom från punkt A till punkt B. Om det inte finns några bilar i närheten bör tjänsten omedelbart informera om detta så att klienten inte har det fanns falska förväntningar. Men om skylten "Inga bilar" visas för ofta, är det logiskt att en person helt enkelt slutar använda den här tjänsten och går till en konkurrent.
I den här artikeln vill jag prata om hur vi med hjälp av maskininlärning löste problemet med att söka efter bilar i områden med låg densitet (med andra ord, där det vid första anblicken inte finns några bilar). Och vad kom ut av det.
förhistoria
För att ringa en taxi utför användaren några enkla steg, men vad händer inne i tjänsten?
| Användare | stadium | Backend Yandex.Taxi |
|---|---|---|
| Väljer startpunkten | nål | Vi lanserar en förenklad sökning efter kandidater – nålsökning. Baserat på de drivrutiner som hittats förutsägs ankomsttiden - ETA i stiftet. Den ökande koefficienten vid en given punkt beräknas. |
| Väljer destination, biljettpris, krav | Erbjudande | Vi bygger en rutt och beräknar priser för alla tariffer, med hänsyn till den ökande koefficienten. |
| Trycker på knappen "Ring en taxi". | beställa | Vi startar en fullständig sökning efter bilen. Vi väljer ut den mest lämpliga föraren och erbjuder honom en beställning. |
Про , и vi har redan skrivit. Och det här är en historia om att hitta förare. När en beställning skapas sker sökningen två gånger: på stiftet och på beställningen. Sökandet efter en beställning sker i två steg: rekrytering av kandidater och rangordning. Först hittas tillgängliga kandidatförare som är närmast längs väggrafen. Sedan tillämpas bonusar och filtrering. De återstående kandidaterna rankas och vinnaren får ett beställningserbjudande. Om han samtycker tilldelas han beställningen och går till utlämningsstället. Om han vägrar kommer erbjudandet till nästa. Om det inte finns fler kandidater startar sökningen igen. Detta varar inte mer än tre minuter, varefter beställningen avbryts och bränns.
Att söka på en pin liknar att söka på en beställning, bara beställningen skapas inte och själva sökningen utförs endast en gång. Förenklade inställningar för antal kandidater och sökradie används också. Sådana förenklingar är nödvändiga eftersom det finns en storleksordning fler stift än order, och sökning är en ganska svår operation. Nyckelpunkten för vår berättelse: om under den preliminära sökningen inga lämpliga kandidater hittades på Pin, så tillåter vi inte att du gör en beställning. Åtminstone var det så förr.
Det här är vad användaren såg i applikationen:
Sök efter bilar utan bilar
En dag kom vi med en hypotes: kanske i vissa fall kan beställningen ändå genomföras, även om det inte fanns några bilar på stiftet. Det går trots allt lite tid mellan stiftet och beställningen, och sökningen efter beställningen är mer komplett och ibland upprepas flera gånger: under denna tid kan tillgängliga drivrutiner dyka upp. Vi visste också motsatsen: om förare hittades på stiftet var det inte ett faktum att de skulle hittas vid beställning. Ibland försvinner de eller så vägrar alla beställningen.
För att testa denna hypotes lanserade vi ett experiment: vi slutade kontrollera förekomsten av bilar under en sökning på en pin efter en testgrupp av användare, det vill säga de hade möjlighet att göra en "beställning utan bilar." Resultatet var ganska oväntat: om bilen inte var på stiftet, så hittades den i 29% av fallen senare - vid sökning på beställningen! Dessutom skilde sig beställningar utan bilar inte nämnvärt från vanliga beställningar när det gäller avbokningsfrekvens, betyg och andra kvalitetsindikatorer. Bokningar utan bil stod för 5 % av alla bokningar, men drygt 1 % av alla lyckade resor.
För att förstå var verkställarna av dessa order kommer ifrån, låt oss titta på deras status under en sökning på en Pin:
- Tillgängliga: var tillgänglig, men av någon anledning inte ingick i kandidaterna, till exempel var han för långt borta;
- På beställning: var upptagen, men lyckades frigöra sig eller bli tillgänglig för ;
- Upptagen: möjligheten att acceptera beställningar inaktiverades, men sedan återvände föraren till linjen;
- Inte tillgänglig: föraren var inte online, men han dök upp.
Låt oss lägga till tillförlitlighet
Ytterligare beställningar är bra, men 29 % av framgångsrika sökningar betyder att 71 % av tiden väntade användaren länge och hamnade ingenstans. Även om det inte finns något hemskt med detta ur systemeffektivitetssynpunkt, ger det faktiskt användaren falskt hopp och slösar bort tid, varefter de blir frustrerade och (möjligen) slutar använda tjänsten. För att lösa detta problem lärde vi oss att förutsäga sannolikheten för att en beställd bil kommer att hittas.
Schemat är detta:
- Användaren sätter en nål.
- En sökning görs på stiftet.
- Om det inte finns några bilar förutspår vi: de kanske dyker upp.
- Och beroende på sannolikheten tillåter eller tillåter vi dig inte att beställa, men vi varnar dig för att tätheten av bilar i detta område vid denna tidpunkt är låg.
I applikationen såg det ut så här:
Genom att använda modellen kan du skapa nya beställningar mer exakt och inte lugna människor förgäves. Det vill säga att reglera förhållandet mellan tillförlitlighet och antalet beställningar utan maskiner med hjälp av precisionsåterkallningsmodellen. Tjänstens tillförlitlighet påverkar önskan att fortsätta använda produkten, det vill säga i slutändan beror allt på antalet resor.
Lite om precision-recallEn av de grundläggande uppgifterna inom maskininlärning är klassificeringsuppgiften: att tilldela ett objekt till en av två klasser. I det här fallet blir resultatet av maskininlärningsalgoritmen ofta en numerisk bedömning av medlemskap i en av klasserna, till exempel en sannolikhetsbedömning. Åtgärderna som utförs är dock vanligtvis binära: om bilen är tillgänglig låter vi dig beställa den, och om inte, kommer vi inte att göra det. För att vara specifik, låt oss kalla en algoritm som producerar en numerisk uppskattning för en modell, och en klassificerare en regel som tilldelar den till en av två klasser (1 eller -1). För att göra en klassificerare baserad på modellbedömningen måste du välja en bedömningströskel. Hur exakt beror mycket på uppgiften.
Anta att vi gör ett test (klassificerare) för någon sällsynt och farlig sjukdom. Baserat på testresultaten skickar vi antingen patienten för en mer detaljerad undersökning eller säger: "Bra, gå hem." För oss är det mycket värre att skicka hem en sjuk person än att i onödan undersöka en frisk person. Det vill säga vi vill att testet ska fungera för så många riktigt sjuka som möjligt. Detta värde kallas recall =. En idealisk klassificerare har en återkallelse på 100 %. En degenererad situation är att skicka alla på undersökning, då blir återkallelsen också 100%.
Det händer också tvärtom. Till exempel gör vi ett testsystem för studenter, och det har en fuskdetektor. Om kontrollen plötsligt inte fungerar för vissa fall av fusk, så är detta obehagligt, men inte kritiskt. Å andra sidan är det extremt dåligt att orättvist anklaga elever för något de inte gjort. Det vill säga, det är viktigt för oss att bland klassificerarens positiva svar finns så många korrekta som möjligt, kanske till nackdel för deras antal. Det betyder att du måste maximera precisionen = . Om triggning sker på alla objekt kommer precisionen att vara lika med frekvensen för den definierade klassen i provet.
Om algoritmen producerar ett numeriskt sannolikhetsvärde kan du genom att välja olika tröskelvärden uppnå olika precisions-återkallningsvärden.
I vårt problem är situationen följande. Återkallelse är antalet beställningar vi kan erbjuda, precision är tillförlitligheten av dessa beställningar. Så här ser precisions-återkallningskurvan för vår modell ut:
Det finns två extrema fall: låt inte någon beställa och låt alla beställa. Om du inte tillåter någon, kommer återkallelsen att vara 0: vi skapar inte order, men ingen av dem kommer att misslyckas. Om vi tillåter alla kommer återkallelsen att vara 100 % (vi kommer att ta emot alla möjliga beställningar), och precisionen kommer att vara 29 %, dvs 71 % av beställningarna kommer att vara dåliga.
Vi använde olika parametrar för startpunkten som tecken:
- Tid/plats.
- Systemtillstånd (antal upptagna maskiner av alla tariffer och stift i närheten).
- Sökparametrar (radie, antal kandidater, begränsningar).
Mer om skyltarna
Begreppsmässigt vill vi skilja mellan två situationer:
- "Djup skog" - det finns inga bilar här för närvarande.
- "Otur" - det finns bilar, men när man letade fanns det inga lämpliga.
Ett exempel på ”Otur” är om det är stor efterfrågan i centrum på fredag kväll. Det finns många beställningar, många som är villiga och inte tillräckligt med förare för alla. Det kan bli så här: det finns inga lämpliga drivrutiner i stiftet. Men bokstavligen inom några sekunder dyker de upp, för vid denna tidpunkt finns det många förare på denna plats och deras status förändras ständigt.
Därför visade sig olika systemindikatorer i närheten av punkt A vara bra egenskaper:
- Totalt antal bilar.
- Antal bilar på beställning.
- Antalet bilar som inte är tillgängliga för beställning i statusen "Upptagen".
- Antal användare.
När allt kommer omkring, ju fler bilar det finns, desto mer sannolikt är det att en av dem blir tillgänglig.
Faktum är att det är viktigt för oss att inte bara bilar lokaliseras, utan även framgångsrika resor görs. Därför var det möjligt att förutsäga sannolikheten för en lyckad resa. Men vi bestämde oss för att inte göra detta, eftersom detta värde i hög grad beror på användaren och föraren.
Modellträningsalgoritmen var . Data erhållna från experimentet användes för träning. Efter implementeringen måste utbildningsdata samlas in, vilket ibland tillät ett litet antal användare att beställa mot modellens beslut.
Resultat av
Resultaten av experimentet var som förväntat: genom att använda modellen kan du avsevärt öka antalet framgångsrika resor på grund av beställningar utan bilar, men utan att kompromissa med tillförlitligheten.
För tillfället har mekanismen lanserats i alla städer och länder och med dess hjälp inträffar cirka 1% av framgångsrika resor. Dessutom, i vissa städer med låg densitet av bilar når andelen sådana resor 15 %.
Andra inlägg om Taxiteknik
Källa: will.com