Un bon servei de taxi ha de ser segur, fiable i ràpid. L'usuari no entrarà en detalls: és important per a ell que faci clic al botó "Comanda" i rebi el més aviat possible un cotxe que el portarà del punt A al punt B. Si no hi ha cotxes a prop, el servei hauria de informar immediatament sobre això perquè el client no tingui falses expectatives. Però si el signe "No hi ha cotxes" apareix massa sovint, és lògic que una persona simplement deixi d'utilitzar aquest servei i vagi a un competidor.
En aquest article vull parlar de com, mitjançant l'aprenentatge automàtic, hem resolt el problema de la recerca de cotxes en zones de baixa densitat (és a dir, on, a primera vista, no hi ha cotxes). I què en va sortir.
prehistòria
Per trucar a un taxi, l'usuari fa uns senzills passos, però què passa dins del servei?
| Usuari | Etapa | Backend Yandex.Taxi |
|---|---|---|
| Selecciona el punt de partida | Pin | Estem llançant una cerca simplificada de candidats: cerca de pins. A partir dels conductors trobats, es preveu l'hora d'arribada: ETA al pin. Es calcula el coeficient creixent en un punt donat. |
| Selecciona destinació, tarifa i requisits | Oferta | Construïm una ruta i calculem preus per a totes les tarifes, tenint en compte el coeficient creixent. |
| Prem el botó "Truca a un taxi". | Ordre | Iniciem una recerca completa del cotxe. Seleccionem el conductor més adequat i li oferim una comanda. |
Про , и ja hem escrit. I aquesta és una història sobre trobar conductors. Quan es crea una comanda, la cerca es fa dues vegades: al Pin i a la comanda. La recerca d'una comanda es fa en dues etapes: captació de candidats i classificació. En primer lloc, es troben els conductors candidats disponibles que estan més a prop del gràfic de la carretera. A continuació, s'apliquen bonificacions i filtres. La resta de candidats es classifiquen i el guanyador rep una oferta de comanda. Si està d'acord, s'assigna a la comanda i es dirigeix al punt de lliurament. Si es nega, l'oferta passa a la següent. Si no hi ha més candidats, la cerca torna a començar. Això no dura més de tres minuts, després dels quals la comanda es cancel·la i es crema.
La cerca en un Pin és similar a la cerca en una comanda, només que l'ordre no es crea i la cerca en si només es realitza una vegada. També s'utilitzen paràmetres simplificats per al nombre de candidats i el radi de cerca. Aquestes simplificacions són necessàries perquè hi ha un ordre de magnitud més pins que ordres, i la cerca és una operació força difícil. El punt clau de la nostra història: si durant la cerca preliminar no es van trobar candidats adequats al Pin, no us permetrem fer una comanda. Almenys així era abans.
Això és el que l'usuari va veure a l'aplicació:
Cerca cotxes sense cotxes
Un dia vam plantejar una hipòtesi: potser en alguns casos encara es pot completar l'encàrrec, encara que no hi haguessin cotxes al pin. Al cap i a la fi, passa un temps entre el pin i l'ordre, i la cerca de l'ordre és més completa i de vegades es repeteix diverses vegades: durant aquest temps, poden aparèixer els controladors disponibles. També sabíem el contrari: si es trobaven conductors al pin, no era un fet que es trobarien en fer la comanda. De vegades desapareixen o tothom rebutja l'ordre.
Per provar aquesta hipòtesi, vam llançar un experiment: vam deixar de comprovar la presència de cotxes durant una cerca en un Pin d'un grup de prova d'usuaris, és a dir, van tenir l'oportunitat de fer una "comanda sense cotxes". El resultat va ser força inesperat: si el cotxe no estava al pin, en el 29% dels casos es va trobar més tard, en cercar a la comanda! A més, les comandes sense cotxes no eren significativament diferents de les comandes habituals pel que fa a les taxes de cancel·lació, les puntuacions i altres indicadors de qualitat. Les reserves sense cotxe van representar el 5% de totes les reserves, però poc més de l'1% de tots els viatges amb èxit.
Per entendre d'on provenen els executors d'aquestes ordres, mirem els seus estats durant una cerca en un Pin:
- Disponible: estava disponible, però per alguna raó no estava inclòs entre els candidats, per exemple, estava massa lluny;
- Està demanat: estava ocupat, però va aconseguir alliberar-se o estar disponible ;
- Ocupada: la capacitat d'acceptar comandes es va desactivar, però després el conductor va tornar a la línia;
- No disponible: el conductor no estava en línia, però va aparèixer.
Afegim fiabilitat
Les comandes addicionals són excel·lents, però el 29% de les cerques reeixides significa que el 71% del temps l'usuari va esperar molt de temps i va acabar no anant enlloc. Tot i que això no és dolent des del punt de vista de l'eficiència del sistema, en realitat dóna a l'usuari falses esperances i fa perdre el temps, després de la qual cosa es molesta i (possiblement) deixa d'utilitzar el servei. Per resoldre aquest problema, hem après a predir la probabilitat que es trobi un cotxe en comanda.
El pla és el següent:
- L'usuari posa un pin.
- Es realitza una cerca al pin.
- Si no hi ha cotxes, predim: potser apareixeran.
- I segons la probabilitat, permetem o no fer una comanda, però us avisem que la densitat de cotxes en aquesta zona en aquest moment és baixa.
A l'aplicació es veia així:
L'ús del model us permet crear noves comandes amb més precisió i no tranquil·litzar la gent en va. És a dir, per regular la relació de fiabilitat i el nombre de comandes sense màquines utilitzant el model de precisió de recuperació. La fiabilitat del servei influeix en el desig de seguir utilitzant el producte, és a dir, al final tot es redueix al nombre de viatges.
Una mica sobre el record de precisióUna de les tasques bàsiques de l'aprenentatge automàtic és la tasca de classificació: assignar un objecte a una de les dues classes. En aquest cas, el resultat de l'algorisme d'aprenentatge automàtic es converteix sovint en una avaluació numèrica de la pertinença a una de les classes, per exemple, una avaluació de probabilitats. Tanmateix, les accions que es realitzen solen ser binàries: si el cotxe està disponible, us deixarem demanar-lo, i si no, no ho farem. Per ser específics, anomenem un model un algorisme que produeix una estimació numèrica, i un classificador una regla que l'assigna a una de les dues classes (1 o –1). Per fer un classificador basat en l'avaluació del model, heu de seleccionar un llindar d'avaluació. Com exactament depèn en gran mesura de la tasca.
Suposem que estem fent una prova (classificador) per a alguna malaltia rara i perillosa. En funció dels resultats de la prova, enviem el pacient per a un examen més detallat o diem: "Bé, vés a casa". Per a nosaltres, enviar una persona malalta a casa és molt pitjor que examinar innecessàriament una persona sana. És a dir, volem que la prova funcioni per a tantes persones realment malaltes com sigui possible. Aquest valor s'anomena recall =. Un classificador ideal té un record del 100%. Una situació degenerada és enviar tothom a examinar-se, aleshores la retirada també serà del 100%.
També passa al revés. Per exemple, estem fent un sistema de proves per als estudiants, i té un detector de trampes. Si de sobte el control no funciona en alguns casos d'engany, això és desagradable, però no crític. D'altra banda, és extremadament dolent acusar injustament els estudiants d'alguna cosa que no van fer. És a dir, és important per a nosaltres que entre les respostes positives del classificador n'hi hagi el màxim de correctes, potser en detriment del seu nombre. Això vol dir que heu de maximitzar la precisió = . Si l'activació es produeix en tots els objectes, la precisió serà igual a la freqüència de la classe definida a la mostra.
Si l'algorisme produeix un valor de probabilitat numèrica, seleccionant diferents llindars, podeu aconseguir diferents valors de record de precisió.
En el nostre problema la situació és la següent. El record és el nombre de comandes que podem oferir, la precisió és la fiabilitat d'aquestes comandes. Així és la corba de record de precisió del nostre model:
Hi ha dos casos extrems: no permetre que ningú faci la comanda i permetre que tothom faci la comanda. Si no permeteu a ningú, el record serà 0: no creem comandes, però cap d'elles fallarà. Si permetem a tothom, llavors la retirada serà del 100% (rebrem totes les comandes possibles) i la precisió serà del 29%, és a dir, el 71% de les comandes serà dolenta.
Hem utilitzat diversos paràmetres del punt de partida com a senyals:
- Temps/lloc.
- Estat del sistema (nombre de màquines ocupades de totes les tarifes i pins als voltants).
- Paràmetres de cerca (radi, nombre de candidats, restriccions).
Més informació sobre els senyals
Conceptualment, volem distingir entre dues situacions:
- "Bosc profund": no hi ha cotxes aquí en aquest moment.
- "Desafortunat": hi ha cotxes, però en cercar no n'hi havia cap adequat.
Un exemple de "Desafortunat" és si el divendres al vespre hi ha molta demanda al centre. Hi ha moltes comandes, molta gent disposada i no hi ha prou conductors per a tothom. Pot resultar així: no hi ha controladors adequats al pin. Però literalment apareixen en qüestió de segons, perquè en aquest moment hi ha molts conductors en aquest lloc i el seu estat canvia constantment.
Per tant, diversos indicadors del sistema als voltants del punt A van resultar ser bones característiques:
- Nombre total de cotxes.
- Nombre de cotxes en comanda.
- El nombre de cotxes no disponibles per a la comanda en l'estat "Ocupat".
- Nombre d'usuaris.
Al cap i a la fi, com més cotxes hi hagi, més probable és que un d'ells estigui disponible.
De fet, per a nosaltres és important que no només es localitzin els cotxes, sinó que també es facin viatges amb èxit. Per tant, era possible predir la probabilitat d'un viatge exitós. Però vam decidir no fer-ho, perquè aquest valor depèn molt de l'usuari i del conductor.
L'algoritme d'entrenament del model era . Les dades obtingudes de l'experiment es van utilitzar per a l'entrenament. Després de la implementació, s'havien de recollir dades de formació, de vegades permetent a un nombre reduït d'usuaris ordenar contra la decisió del model.
Resultats de
Els resultats de l'experiment van ser els esperats: utilitzar el model us permet augmentar significativament el nombre de viatges amb èxit a causa de comandes sense cotxes, però sense comprometre la fiabilitat.
De moment, el mecanisme s'ha posat en marxa a totes les ciutats i països i amb la seva ajuda es produeix al voltant de l'1% dels viatges amb èxit. A més, en algunes ciutats amb una baixa densitat de cotxes, la proporció d'aquests viatges arriba al 15%.
Altres publicacions sobre tecnologia del taxi
Font: www.habr.com