Un buon servizio taxi deve essere sicuro, affidabile e veloce. L'utente non entra nei dettagli: per lui è importante cliccare il pulsante “Ordina” e ricevere nel più breve tempo possibile un'auto che lo porterà dal punto A al punto B. Se non ci sono auto nelle vicinanze, il servizio dovrebbe informarlo immediatamente affinché il cliente non abbia false aspettative. Ma se il cartello "No car" appare troppo spesso, è logico che una persona smetta semplicemente di utilizzare questo servizio e si rivolga a un concorrente.
In questo articolo voglio parlare di come, utilizzando il machine learning, abbiamo risolto il problema della ricerca delle auto nelle zone a bassa densità (ovvero dove, a prima vista, non ci sono auto). E cosa ne è venuto fuori.
Sfondo
Per chiamare un taxi l'utente esegue pochi semplici passaggi, ma cosa succede all'interno del servizio?
| Utente | Palcoscenico | Backend Yandex.Taxi |
|---|---|---|
| Seleziona il punto iniziale | perno | Stiamo lanciando una ricerca semplificata dei candidati: ricerca pin. In base agli autisti trovati viene previsto l'orario di arrivo - ETA nel segnaposto. Viene calcolato il coefficiente crescente in un dato punto. |
| Seleziona destinazione, tariffa, requisiti | Offrire | Costruiamo un percorso e calcoliamo i prezzi per tutte le tariffe, tenendo conto del coefficiente crescente. |
| Preme il pulsante “Chiama un Taxi”. | Заказ | Lanciamo una ricerca completa dell'auto. Selezioniamo l'autista più adatto e gli offriamo un ordine. |
Про , и abbiamo già scritto. E questa è una storia sulla ricerca di autisti. Quando viene creato un ordine la ricerca avviene due volte: sul Pin e sull'ordine. La ricerca di un Ordine avviene in due fasi: reclutamento dei candidati e graduatoria. Innanzitutto, vengono trovati i conducenti candidati disponibili più vicini lungo il grafico stradale. Quindi vengono applicati bonus e filtri. I restanti candidati vengono classificati e il vincitore riceve un'offerta d'ordine. Se è d'accordo, viene assegnato all'ordine e si reca al punto di consegna. Se rifiuta, l'offerta passa a quello successivo. Se non ci sono più candidati, la ricerca ricomincia. Questa dura non più di tre minuti, trascorsi i quali l'ordine viene annullato e bruciato.
La ricerca su un Pin è simile alla ricerca su un ordine, solo che l'ordine non viene creato e la ricerca stessa viene eseguita una sola volta. Vengono inoltre utilizzate impostazioni semplificate per il numero di candidati e il raggio di ricerca. Tali semplificazioni sono necessarie perché ci sono un ordine di grandezza in più di pin che di ordini e la ricerca è un'operazione piuttosto difficile. Il punto chiave della nostra storia: se durante la ricerca preliminare sul Pin non sono stati trovati candidati idonei, non ti consentiamo di effettuare un ordine. Almeno così era una volta.
Questo è ciò che l'utente ha visto nell'applicazione:
Cerca auto senza auto
Un giorno abbiamo fatto un'ipotesi: forse in alcuni casi l'ordine può ancora essere portato a termine, anche se non c'erano auto sul pin. Dopotutto, tra il pin e l'ordine passa del tempo e la ricerca dell'ordine è più completa e talvolta ripetuta più volte: durante questo tempo potrebbero apparire i driver disponibili. Sapevamo anche il contrario: se sulla spilla fossero stati trovati i driver, non era un dato di fatto che sarebbero stati trovati al momento dell'ordine. A volte scompaiono o tutti rifiutano l'ordine.
Per verificare questa ipotesi, abbiamo lanciato un esperimento: abbiamo smesso di verificare la presenza di automobili durante una ricerca su un Pin per un gruppo test di utenti, ovvero hanno avuto la possibilità di effettuare un “ordine senza automobili”. Il risultato è stato del tutto inaspettato: se l'auto non era sulla spilla, nel 29% dei casi è stata ritrovata più tardi, durante la ricerca nell'ordine! Inoltre, gli ordini senza auto non erano significativamente diversi dagli ordini normali in termini di tassi di cancellazione, valutazioni e altri indicatori di qualità. Le prenotazioni senza auto rappresentano il 5% di tutte le prenotazioni, ma poco più dell'1% di tutti i viaggi riusciti.
Per capire da dove provengono gli esecutori di questi ordini, vediamo il loro stato durante una ricerca su un Pin:
- Disponibile: era disponibile, ma per qualche motivo non era incluso tra i candidati, ad esempio era troppo lontano;
- Su ordine: era occupato, ma è riuscito a liberarsi o a rendersi disponibile per ;
- Occupato: la possibilità di accettare ordini è stata disabilitata, ma poi l'autista è tornato in linea;
- Non disponibile: l'autista non era online, ma è apparso.
Aggiungiamo affidabilità
Gli ordini aggiuntivi sono ottimi, ma il 29% delle ricerche riuscite significa che il 71% delle volte l'utente ha aspettato a lungo e alla fine non è andato da nessuna parte. Anche se questo non è un aspetto negativo dal punto di vista dell'efficienza del sistema, in realtà dà all'utente false speranze e fa perdere tempo, dopodiché si arrabbia e (forse) smette di utilizzare il servizio. Per risolvere questo problema, abbiamo imparato a prevedere la probabilità che venga trovata un'auto ordinata.
Lo schema è il seguente:
- L'utente inserisce un pin.
- Viene effettuata una ricerca sul pin.
- Se non ci sono automobili, prevediamo: forse appariranno.
- E a seconda della probabilità, ti permettiamo o non permettiamo di effettuare un ordine, ma ti avvertiamo che la densità di auto in questa zona in questo momento è bassa.
Nell'applicazione appariva così:
L'utilizzo del modello consente di creare nuovi ordini in modo più accurato e di non rassicurare invano le persone. Cioè, regolare il rapporto tra affidabilità e numero di ordini senza macchine utilizzando il modello di richiamo di precisione. L'affidabilità del servizio influenza il desiderio di continuare a utilizzare il prodotto, cioè alla fine tutto si riduce al numero di viaggi.
Un po' di richiamo di precisioneUno dei compiti fondamentali nell'apprendimento automatico è il compito di classificazione: assegnare un oggetto a una delle due classi. In questo caso, il risultato dell'algoritmo di apprendimento automatico diventa spesso una valutazione numerica dell'appartenenza a una delle classi, ad esempio una valutazione della probabilità. Tuttavia, le azioni eseguite sono solitamente binarie: se l’auto è disponibile, te la permetteremo di ordinarla, altrimenti no. Per essere precisi, chiamiamo un algoritmo che produce una stima numerica un modello e un classificatore una regola che lo assegna a una delle due classi (1 o –1). Per creare un classificatore basato sulla valutazione del modello, è necessario selezionare una soglia di valutazione. Come esattamente dipende molto dal compito.
Supponiamo di eseguire un test (classificatore) per alcune malattie rare e pericolose. Sulla base dei risultati del test, inviamo il paziente per un esame più dettagliato o diciamo: "Bene, vai a casa". Per noi mandare a casa una persona malata è molto peggio che visitare inutilmente una persona sana. Vogliamo cioè che il test funzioni per il maggior numero possibile di persone veramente malate. Questo valore è chiamato richiamo =. Un classificatore ideale ha un richiamo del 100%. Una situazione degenerata è mandare tutti a fare un esame, poi anche il richiamo sarà al 100%.
Succede anche il contrario. Ad esempio, stiamo creando un sistema di test per gli studenti, dotato di un rilevatore di frodi. Se all'improvviso il controllo non funziona in alcuni casi di imbroglio, ciò è spiacevole, ma non critico. D’altra parte, è estremamente grave accusare ingiustamente gli studenti di qualcosa che non hanno fatto. Cioè per noi è importante che tra le risposte positive del classificatore ce ne siano quante più corrette possibili, magari a scapito del loro numero. Ciò significa che è necessario massimizzare la precisione = . Se l'attivazione avviene su tutti gli oggetti, la precisione sarà uguale alla frequenza della classe definita nel campione.
Se l'algoritmo produce un valore di probabilità numerico, selezionando soglie diverse è possibile ottenere valori di richiamo della precisione diversi.
Nel nostro problema la situazione è la seguente. Il richiamo è il numero di ordini che possiamo offrire, la precisione è l'affidabilità di questi ordini. Ecco come appare la curva di richiamo di precisione del nostro modello:
Ci sono due casi estremi: non permettere a nessuno di ordinare e permettere a tutti di ordinare. Se non lo consenti a nessuno, il richiamo sarà 0: non creiamo ordini, ma nessuno di essi fallirà. Se consentiamo a tutti, il richiamo sarà del 100% (riceveremo tutti gli ordini possibili) e la precisione sarà del 29%, ovvero il 71% degli ordini sarà errato.
Abbiamo utilizzato vari parametri del punto di partenza come segnali:
- Tempo/luogo.
- Stato del sistema (numero di macchine occupate di tutte le tariffe e pin nelle vicinanze).
- Parametri di ricerca (raggio, numero di candidati, restrizioni).
Maggiori informazioni sui segni
Concettualmente vogliamo distinguere due situazioni:
- "Foresta profonda": non ci sono macchine qui in questo momento.
- "Sfortunato" - ci sono macchine, ma durante la ricerca non ce n'erano di adatte.
Un esempio di “Sfortunato” è se c'è molta richiesta in centro il venerdì sera. Ci sono molti ordini, molte persone disponibili e non abbastanza autisti per tutti. Potrebbe risultare così: non ci sono driver adatti nel pin. Ma compaiono letteralmente in pochi secondi, perché in questo momento ci sono molti conducenti in questo posto e il loro stato cambia costantemente.
Pertanto, vari indicatori di sistema in prossimità del punto A si sono rivelati buone caratteristiche:
- Numero totale di auto.
- Numero di auto in ordine.
- Il numero di auto non disponibili per l'ordine nello stato "Occupato".
- Numero di utenti.
Dopotutto, più auto ci sono, più è probabile che una di esse sia disponibile.
Per noi, infatti, è importante che non solo vengano localizzate le auto, ma che vengano effettuati anche viaggi di successo. Pertanto, è stato possibile prevedere la probabilità di un viaggio di successo. Ma abbiamo deciso di non farlo, perché questo valore dipende molto dall'utente e dal conducente.
L'algoritmo di addestramento del modello era . I dati ottenuti dall'esperimento sono stati utilizzati per la formazione. Dopo l'implementazione, è stato necessario raccogliere i dati di addestramento, consentendo talvolta a un numero limitato di utenti di ordinare contro la decisione del modello.
Risultati di
I risultati dell'esperimento sono stati quelli attesi: l'utilizzo del modello consente di aumentare significativamente il numero di viaggi riusciti grazie a ordini senza auto, ma senza compromettere l'affidabilità.
Al momento, il meccanismo è stato lanciato in tutte le città e paesi e con il suo aiuto si verifica circa l'1% dei viaggi di successo. Inoltre, in alcune città a bassa densità di automobili, la percentuale di tali viaggi raggiunge il 15%.
Altri post sulla tecnologia Taxi
Fonte: habr.com