En god taxatjeneste skal være sikker, pålidelig og hurtig. Brugeren vil ikke gå i detaljer: det er vigtigt for ham, at han klikker på "Bestil"-knappen og modtager en bil så hurtigt som muligt, der vil tage ham fra punkt A til punkt B. Hvis der ikke er biler i nærheden, bør tjenesten straks informere om dette, så klienten ikke har der var falske forventninger. Men hvis tegnet "Ingen biler" vises for ofte, er det logisk, at en person simpelthen stopper med at bruge denne service og går til en konkurrent.
I denne artikel vil jeg tale om, hvordan vi ved hjælp af maskinlæring løste problemet med at søge efter biler i områder med lav tæthed (med andre ord, hvor der ved første øjekast ikke er nogen biler). Og hvad kom der ud af det.
forhistorie
For at ringe til en taxa udfører brugeren et par enkle trin, men hvad sker der inde i tjenesten?
| Bruger | etape | Backend Yandex.Taxi |
|---|---|---|
| Vælger startpunktet | pin | Vi lancerer en forenklet søgning efter kandidater - pinsøgning. Baseret på de fundne drivere forudsiges ankomsttiden - ETA i stiften. Den stigende koefficient på et givet punkt beregnes. |
| Vælger destination, billetpris, krav | Tilbud | Vi bygger en rute og beregner priser for alle takster under hensyntagen til den stigende koefficient. |
| Tryk på knappen "Ring til en taxa". | bestilling | Vi starter en fuld søgning efter bilen. Vi udvælger den bedst egnede chauffør og tilbyder ham en ordre. |
Про , и vi har allerede skrevet. Og dette er en historie om at finde chauffører. Når en ordre oprettes, sker søgningen to gange: på pin-koden og på ordren. Søgningen efter en ordre foregår i to faser: rekruttering af kandidater og rangering. Først findes ledige chauffører, som er tættest på vejgrafen. Derefter anvendes bonusser og filtrering. De resterende kandidater rangeres, og vinderen modtager et ordretilbud. Hvis han accepterer, bliver han tildelt ordren og går til leveringsstedet. Hvis han afslår, så kommer tilbuddet til det næste. Hvis der ikke er flere kandidater, starter søgningen igen. Dette varer ikke mere end tre minutter, hvorefter ordren annulleres og brændes.
Søgning på en pin svarer til at søge på en ordre, kun ordren oprettes ikke, og selve søgningen udføres kun én gang. Der anvendes også forenklede indstillinger for antal kandidater og søgeradius. Sådanne forenklinger er nødvendige, fordi der er en størrelsesorden flere stifter end ordrer, og søgning er en ret vanskelig operation. Nøglepunktet for vores historie: Hvis der under den foreløbige søgning ikke blev fundet egnede kandidater på pinden, tillader vi dig ikke at afgive en ordre. Sådan har det i hvert fald været.
Dette er, hvad brugeren så i applikationen:
Søg efter biler uden biler
En dag kom vi med en hypotese: måske i nogle tilfælde kan ordren stadig gennemføres, selvom der ikke var nogen biler på pinden. Der går trods alt noget tid mellem pinden og ordren, og søgningen efter ordren er mere komplet og nogle gange gentaget flere gange: i løbet af denne tid kan tilgængelige drivere dukke op. Vi vidste også det modsatte: Hvis der blev fundet chauffører på pinden, var det ikke et faktum, at de ville blive fundet ved bestilling. Nogle gange forsvinder de, eller alle afviser ordren.
For at teste denne hypotese lancerede vi et eksperiment: vi holdt op med at kontrollere tilstedeværelsen af biler under en søgning på en pin efter en testgruppe af brugere, dvs. de havde mulighed for at lave en "ordre uden biler." Resultatet var ret uventet: hvis bilen ikke var på pinden, så blev den i 29% af tilfældene fundet senere - ved søgning på ordren! Desuden var ordrer uden biler ikke væsentligt forskellige fra almindelige ordrer med hensyn til annulleringsrater, vurderinger og andre kvalitetsindikatorer. Bookinger uden biler udgjorde 5 % af alle bookinger, men godt 1 % af alle vellykkede rejser.
For at forstå, hvor udførerne af disse ordrer kommer fra, lad os se på deres status under en søgning på en pin:
- Ledig: var ledig, men var af en eller anden grund ikke med i kandidaterne, for eksempel var han for langt væk;
- På bestilling: havde travlt, men det lykkedes at frigøre sig eller blive tilgængelig for ;
- Travl: evnen til at acceptere ordrer blev deaktiveret, men så vendte chaufføren tilbage til linjen;
- Ikke tilgængelig: chaufføren var ikke online, men han dukkede op.
Lad os tilføje pålidelighed
Yderligere ordrer er gode, men 29 % af vellykkede søgninger betyder, at 71 % af tiden ventede brugeren længe og endte med at gå ingen vegne. Selvom der ikke er noget forfærdeligt ved dette fra et systemeffektivitetssynspunkt, giver det faktisk brugeren falsk håb og spilder tid, hvorefter de bliver frustrerede og (muligvis) holder op med at bruge tjenesten. For at løse dette problem lærte vi at forudsige sandsynligheden for, at en bil på bestilling vil blive fundet.
Ordningen er sådan:
- Brugeren sætter en pin.
- Der foretages en søgning på stiften.
- Hvis der ikke er nogen biler, forudser vi: måske dukker de op.
- Og afhængigt af sandsynligheden tillader eller tillader vi dig ikke at afgive en ordre, men vi advarer dig om, at tætheden af biler i dette område på dette tidspunkt er lav.
I applikationen så det således ud:
Ved at bruge modellen kan du oprette nye ordrer mere præcist og ikke berolige folk forgæves. Det vil sige at regulere forholdet mellem pålidelighed og antallet af ordrer uden maskiner ved hjælp af præcisions-genkaldelsesmodellen. Tjenestens pålidelighed påvirker ønsket om at fortsætte med at bruge produktet, det vil sige, at det i sidste ende afhænger af antallet af ture.
Lidt om præcision-genkaldelseEn af de grundlæggende opgaver i maskinlæring er klassifikationsopgaven: at tildele et objekt til en af to klasser. I dette tilfælde bliver resultatet af maskinlæringsalgoritmen ofte en numerisk vurdering af medlemskab i en af klasserne, for eksempel en sandsynlighedsvurdering. De handlinger, der udføres, er dog normalt binære: Hvis bilen er tilgængelig, så lader vi dig bestille den, og hvis ikke, så gør vi det ikke. For at være specifik, lad os kalde en algoritme, der producerer et numerisk estimat, for en model, og en klassifikator for en regel, der tildeler den til en af to klasser (1 eller -1). For at lave en klassificering baseret på modelvurderingen skal du vælge en vurderingstærskel. Hvordan afhænger i høj grad af opgaven.
Antag, at vi laver en test (klassifikator) for en sjælden og farlig sygdom. Baseret på testresultaterne sender vi enten patienten til en mere detaljeret undersøgelse eller siger: "Godt, gå hjem." For os er det meget værre at sende en syg hjem end at unødvendigt undersøge en rask person. Det vil sige, at vi gerne vil have, at testen virker for så mange rigtigt syge som muligt. Denne værdi kaldes recall =. En ideel klassifikator har en tilbagekaldelse på 100 %. En degenereret situation er at sende alle til undersøgelse, så vil tilbagekaldelsen også være 100%.
Det sker også den anden vej rundt. For eksempel laver vi et testsystem til studerende, og det har en snydedetektor. Hvis checken pludselig ikke virker for nogle tilfælde af snyd, så er dette ubehageligt, men ikke kritisk. På den anden side er det ekstremt slemt at uretfærdigt beskylde elever for noget, de ikke har gjort. Det vil sige, at det er vigtigt for os, at der blandt klassifikatorens positive svar er så mange rigtige som muligt, måske til skade for deres antal. Det betyder, at du skal maksimere præcisionen = . Hvis udløsning forekommer på alle objekter, vil præcisionen være lig med frekvensen af den definerede klasse i prøven.
Hvis algoritmen producerer en numerisk sandsynlighedsværdi, kan du ved at vælge forskellige tærskler opnå forskellige præcisions-genkaldelsesværdier.
I vores problem er situationen som følger. Tilbagekaldelse er antallet af ordrer, vi kan tilbyde, præcision er pålideligheden af disse ordrer. Sådan ser præcisions-genkaldelseskurven for vores model ud:
Der er to ekstreme tilfælde: Tillad ikke nogen at bestille og tillad alle at bestille. Hvis du ikke tillader nogen, vil tilbagekaldelse være 0: vi opretter ikke ordrer, men ingen af dem vil mislykkes. Hvis vi tillader alle, vil tilbagekaldelsen være 100 % (vi modtager alle mulige ordrer), og præcisionen vil være 29 %, dvs. 71 % af ordrerne vil være dårlige.
Vi brugte forskellige parametre for udgangspunktet som tegn:
- Tid/sted.
- Systemtilstand (antal besatte maskiner af alle tariffer og stifter i nærheden).
- Søgeparametre (radius, antal kandidater, begrænsninger).
Mere om skiltene
Begrebsmæssigt ønsker vi at skelne mellem to situationer:
- "Dyb skov" - der er ingen biler her på nuværende tidspunkt.
- "Uheldig" - der er biler, men når man søgte, var der ikke nogen passende.
Et eksempel på "Uheldig" er, hvis der er stor efterspørgsel i centret fredag aften. Der er mange ordrer, mange villige og ikke nok chauffører til alle. Det kan vise sig sådan her: Der er ingen passende drivere i stiften. Men bogstaveligt talt inden for få sekunder dukker de op, for på dette tidspunkt er der mange chauffører på dette sted, og deres status ændrer sig konstant.
Derfor viste forskellige systemindikatorer i nærheden af punkt A sig at være gode funktioner:
- Samlet antal biler.
- Antal biler på bestilling.
- Antallet af biler, der ikke er tilgængelige for bestilling i statussen "Optaget".
- Antal brugere.
Jo flere biler der er, jo mere sandsynligt er det, at en af dem bliver tilgængelig.
Faktisk er det vigtigt for os, at ikke kun biler er placeret, men også succesfulde ture. Derfor var det muligt at forudsige sandsynligheden for en vellykket rejse. Men vi besluttede ikke at gøre dette, fordi denne værdi i høj grad afhænger af brugeren og driveren.
Modeltræningsalgoritmen var . Data opnået fra eksperimentet blev brugt til træning. Efter implementeringen skulle træningsdata indsamles, hvilket nogle gange gjorde det muligt for et lille antal brugere at bestille mod modellens beslutning.
Resultaterne af
Resultaterne af eksperimentet var som forventet: Brug af modellen giver dig mulighed for betydeligt at øge antallet af vellykkede ture på grund af ordrer uden biler, men uden at gå på kompromis med pålideligheden.
I øjeblikket er mekanismen blevet lanceret i alle byer og lande, og med dens hjælp forekommer omkring 1% af de vellykkede rejser. Desuden når andelen af sådanne ture i nogle byer med en lav tæthed af biler op på 15%.
Andre indlæg om Taxi teknologi
Kilde: www.habr.com