Un buen servicio de taxi debe ser seguro, fiable y rápido. El usuario no entrará en detalles: es importante para él que haga clic en el botón "Pedir" y reciba lo más rápido posible un coche que le llevará del punto A al punto B. Si no hay coches cerca, el servicio debería informar inmediatamente sobre esto para que el cliente no tenga falsas expectativas. Pero si el cartel "Prohibido el coche" aparece con demasiada frecuencia, entonces es lógico que una persona simplemente deje de utilizar este servicio y recurra a un competidor.
En este artículo quiero hablar de cómo, utilizando el aprendizaje automático, resolvimos el problema de buscar coches en zonas de baja densidad (en otras palabras, donde, a primera vista, no hay coches). Y qué resultó de ello.
Prehistoria
Para llamar a un taxi, el usuario realiza unos sencillos pasos, pero ¿qué ocurre dentro del servicio?
| Usuario | Etapa | Backend Yandex.Taxi |
|---|---|---|
| Selecciona el punto de partida | Pin | Estamos lanzando una búsqueda simplificada de candidatos: búsqueda por PIN. Según los conductores encontrados, se predice la hora de llegada: ETA en el marcador. Se calcula el coeficiente creciente en un punto dado. |
| Selecciona destino, tarifa, requisitos. | Oferta | Construimos una ruta y calculamos los precios para todas las tarifas, teniendo en cuenta el coeficiente creciente. |
| Presiona el botón “Llamar a un Taxi” | Заказ | Iniciamos una búsqueda completa del coche. Seleccionamos al conductor más adecuado y le ofrecemos un pedido. |
Про , и ya escribimos. Y esta es una historia sobre cómo encontrar conductores. Cuando se crea un pedido, la búsqueda se realiza dos veces: en el Pin y en el pedido. La búsqueda de un pedido se realiza en dos etapas: selección de candidatos y clasificación. En primer lugar, se encuentran los conductores candidatos disponibles que están más cerca del gráfico de la carretera. Luego se aplican bonificaciones y filtrado. Los candidatos restantes se clasifican y el ganador recibe una oferta de pedido. Si está de acuerdo, se le asigna el pedido y se dirige al punto de entrega. Si se niega, la oferta pasa al siguiente. Si no hay más candidatos, la búsqueda comienza de nuevo. Esto no dura más de tres minutos, después de los cuales el pedido se cancela y se quema.
Buscar en un Pin es similar a buscar en un pedido, solo que el pedido no se crea y la búsqueda en sí se realiza solo una vez. También se utilizan configuraciones simplificadas para el número de candidatos y el radio de búsqueda. Estas simplificaciones son necesarias porque hay un orden de magnitud más de pines que de pedidos y la búsqueda es una operación bastante difícil. El punto clave de nuestra historia: si durante la búsqueda preliminar no se encontraron candidatos adecuados en el Pin, no le permitiremos realizar ningún pedido. Al menos así solía ser.
Esto es lo que vio el usuario en la aplicación:
Buscar autos sin autos
Un día se nos ocurrió una hipótesis: quizás en algunos casos el pedido todavía se pueda completar, incluso si no hubiera ningún coche en el pin. Al fin y al cabo, pasa algo de tiempo entre el pin y el pedido, y la búsqueda del pedido es más completa y en ocasiones se repite varias veces: durante este tiempo pueden aparecer controladores disponibles. También sabíamos lo contrario: si se encontraban controladores en el pin, no era un hecho que se encontrarían al realizar el pedido. A veces desaparecen o todos rechazan el pedido.
Para probar esta hipótesis, lanzamos un experimento: dejamos de verificar la presencia de automóviles durante una búsqueda en un Pin para un grupo de usuarios de prueba, es decir, tuvieron la oportunidad de hacer un "pedido sin automóviles". El resultado fue bastante inesperado: Si el automóvil no estaba en el pin, en el 29% de los casos se encontró más tarde, ¡al buscar en el pedido! Además, los pedidos sin automóviles no diferían significativamente de los pedidos regulares en términos de tasas de cancelación, calificaciones y otros indicadores de calidad. Las reservas sin coche representaron el 5% de todas las reservas, pero poco más del 1% de todos los viajes exitosos.
Para entender de dónde vienen los ejecutores de estas órdenes, veamos sus estados durante una búsqueda en un Pin:
- Disponible: estaba disponible, pero por alguna razón no estaba incluido entre los candidatos, por ejemplo, estaba demasiado lejos;
- En orden: estaba ocupado, pero logró liberarse o estar disponible para ;
- Ocupado: se deshabilitó la capacidad de aceptar pedidos, pero luego el conductor regresó a la fila;
- No disponible: el conductor no estaba en línea, pero apareció.
Agreguemos confiabilidad
Los pedidos adicionales son geniales, pero el 29% de las búsquedas exitosas significa que el 71% de las veces el usuario esperó mucho tiempo y terminó sin llegar a ninguna parte. Aunque esto no es malo desde el punto de vista de la eficiencia del sistema, en realidad le da al usuario falsas esperanzas y le hace perder tiempo, después de lo cual se enoja y (posiblemente) deja de usar el servicio. Para resolver este problema, aprendimos a predecir la probabilidad de que se encuentre un automóvil encargado.
El esquema es el siguiente:
- El usuario pone un alfiler.
- Se realiza una búsqueda en el pin.
- Si no hay coches, predecimos: tal vez aparezcan.
- Y dependiendo de la probabilidad, te permitimos o no hacer un pedido, pero te avisamos que la densidad de coches en esta zona en este momento es baja.
En la aplicación se veía así:
El uso del modelo le permite crear nuevos pedidos con mayor precisión y no tranquilizar a las personas en vano. Es decir, regular el ratio de confiabilidad y el número de pedidos sin máquinas utilizando el modelo de recuperación de precisión. La fiabilidad del servicio influye en el deseo de seguir utilizando el producto, es decir, al final todo se reduce al número de viajes.
Un poco sobre el recuerdo de precisiónUna de las tareas básicas del aprendizaje automático es la tarea de clasificación: asignar un objeto a una de dos clases. En este caso, el resultado del algoritmo de aprendizaje automático suele ser una evaluación numérica de la pertenencia a una de las clases, por ejemplo, una evaluación de probabilidad. Sin embargo, las acciones que se realizan suelen ser binarias: si el coche está disponible, te dejaremos pedirlo, y si no, no lo haremos. Para ser específicos, llamemos modelo a un algoritmo que produce una estimación numérica, y a un clasificador una regla que lo asigna a una de dos clases (1 o –1). Para crear un clasificador basado en la evaluación del modelo, debe seleccionar un umbral de evaluación. Cómo exactamente depende en gran medida de la tarea.
Supongamos que estamos haciendo una prueba (clasificador) para detectar alguna enfermedad rara y peligrosa. Según los resultados de la prueba, enviamos al paciente para un examen más detallado o le decimos: "Bien, vete a casa". Para nosotros, enviar a una persona enferma a casa es mucho peor que examinar innecesariamente a una persona sana. Es decir, queremos que la prueba funcione con la mayor cantidad posible de personas realmente enfermas. Este valor se llama recuperación =. Un clasificador ideal tiene una recuperación del 100%. Una situación degenerada es enviar a todos a ser examinados, entonces el retiro también será del 100%.
También sucede al revés. Por ejemplo, estamos creando un sistema de evaluación para estudiantes que tiene un detector de trampas. Si de repente el control no funciona en algunos casos de trampa, entonces esto es desagradable, pero no crítico. Por otro lado, es extremadamente malo acusar injustamente a los estudiantes de algo que no hicieron. Es decir, para nosotros es importante que entre las respuestas positivas del clasificador haya tantas correctas como sea posible, quizás en detrimento de su número. Esto significa que necesitas maximizar la precisión = . Si la activación ocurre en todos los objetos, entonces la precisión será igual a la frecuencia de la clase definida en la muestra.
Si el algoritmo produce un valor de probabilidad numérico, al seleccionar diferentes umbrales, puede lograr diferentes valores de recuperación de precisión.
En nuestro problema la situación es la siguiente. La recuperación es la cantidad de pedidos que podemos ofrecer, la precisión es la confiabilidad de estos pedidos. Así es como se ve la curva de recuperación de precisión de nuestro modelo:
Hay dos casos extremos: no permitir que nadie ordene y permitir que todos ordenen. Si no permite a nadie, la recuperación será 0: no creamos pedidos, pero ninguno fallará. Si permitimos que todos, la recuperación será del 100% (recibiremos todos los pedidos posibles) y la precisión será del 29%, es decir, el 71% de los pedidos serán malos.
Utilizamos varios parámetros del punto de partida como signos:
- Tiempo lugar.
- Estado del sistema (número de máquinas ocupadas de todas las tarifas y pines en las proximidades).
- Parámetros de búsqueda (radio, número de candidatos, restricciones).
Más sobre las señales
Conceptualmente queremos distinguir entre dos situaciones:
- "Bosque profundo": no hay coches aquí en este momento.
- “Desafortunado”: hay coches, pero al buscar no había ninguno adecuado.
Un ejemplo de “mala suerte” es si hay mucha demanda en el centro el viernes por la noche. Hay muchos pedidos, mucha gente dispuesta y no hay suficientes conductores para todos. Puede resultar así: no hay controladores adecuados en el pin. Pero, literalmente, en cuestión de segundos aparecen, porque en este momento hay muchos conductores en este lugar y su estado cambia constantemente.
Por lo tanto, varios indicadores del sistema en las proximidades del punto A resultaron ser buenas características:
- Número total de coches.
- Número de coches encargados.
- La cantidad de automóviles que no están disponibles para realizar pedidos en el estado "Ocupado".
- Número de usuarios.
Al fin y al cabo, cuantos más coches haya, más probabilidades habrá de que uno de ellos esté disponible.
De hecho, para nosotros es importante que no sólo se ubiquen los automóviles, sino que también se realicen viajes exitosos. Por tanto, fue posible predecir la probabilidad de un viaje exitoso. Pero decidimos no hacer esto, porque este valor depende en gran medida del usuario y del conductor.
El algoritmo de entrenamiento del modelo fue . Los datos obtenidos del experimento se utilizaron para el entrenamiento. Después de la implementación, se tuvieron que recopilar datos de entrenamiento, lo que a veces permitió que un pequeño número de usuarios realizaran pedidos en contra de la decisión del modelo.
resultados
Los resultados del experimento fueron los esperados: el uso del modelo permite aumentar significativamente el número de viajes exitosos mediante pedidos sin automóvil, pero sin comprometer la confiabilidad.
Por el momento, el mecanismo se ha puesto en marcha en todas las ciudades y países y con su ayuda se realiza alrededor del 1% de los viajes exitosos. Además, en algunas ciudades con baja densidad de vehículos, la proporción de este tipo de viajes alcanza el 15%.
Otros posts sobre tecnología del Taxi
Fuente: habr.com