Un serviciu bun de taxi trebuie să fie sigur, de încredere și rapid. Utilizatorul nu va intra în detalii: este important pentru el să facă clic pe butonul „Comanda” și să primească cât mai repede o mașină care să-l ducă din punctul A în punctul B. Dacă nu sunt mașini în apropiere, serviciul ar trebui să informați imediat despre acest lucru, astfel încât clientul să nu aibă așteptări false. Dar dacă semnul „Fără mașini” apare prea des, atunci este logic ca o persoană să înceteze pur și simplu să mai folosească acest serviciu și să meargă la un concurent.
În acest articol vreau să vorbesc despre modul în care, folosind machine learning, am rezolvat problema căutării de mașini în zone cu densitate redusă (cu alte cuvinte, unde, la prima vedere, nu există mașini). Și ce a rezultat din asta.
preistorie
Pentru a apela un taxi, utilizatorul efectuează câțiva pași simpli, dar ce se întâmplă în interiorul serviciului?
| Utilizatorul | etapă | Backend Yandex.Taxi |
|---|---|---|
| Selectează punctul de plecare | bolț | Lansăm o căutare simplificată pentru candidați - căutarea prin pin. Pe baza șoferilor găsiți, ora de sosire este prezisă - ETA în pin. Se calculează coeficientul crescător într-un punct dat. |
| Selectează destinația, tariful, cerințele | Oferi | Construim o rută și calculăm prețurile pentru toate tarifele, ținând cont de coeficientul în creștere. |
| Apăsați butonul „Apelați un taxi”. | comandă | Lansăm o căutare completă a mașinii. Selectăm cel mai potrivit șofer și îi oferim o comandă. |
despre , и am scris deja. Și aceasta este o poveste despre găsirea șoferilor. Când este creată o comandă, căutarea are loc de două ori: pe Pin și pe comandă. Căutarea unei comenzi are loc în două etape: recrutarea candidaților și clasare. În primul rând, șoferii candidați disponibili sunt găsiți care sunt cel mai aproape de-a lungul graficului rutier. Apoi se aplică bonusurile și filtrarea. Candidații rămași sunt clasați, iar câștigătorul primește o ofertă de comandă. Dacă este de acord, este repartizat la comandă și merge la punctul de livrare. Dacă refuză, atunci oferta vine la următoarea. Dacă nu mai sunt candidați, căutarea începe din nou. Aceasta nu durează mai mult de trei minute, după care comanda este anulată și arsă.
Căutarea pe un Pin este similară cu căutarea pe o comandă, doar că comanda nu este creată și căutarea în sine este efectuată o singură dată. De asemenea, sunt utilizate setări simplificate pentru numărul de candidați și raza de căutare. Astfel de simplificări sunt necesare deoarece există un ordin de mărime mai mulți pini decât comenzi, iar căutarea este o operație destul de dificilă. Punctul cheie pentru povestea noastră: dacă în timpul căutării preliminare nu s-au găsit candidați potriviți pe Pin, atunci nu vă permitem să plasați o comandă. Cel puțin așa era înainte.
Iată ce a văzut utilizatorul în aplicație:
Caută mașini fără mașini
Într-o zi am venit cu o ipoteză: poate în unele cazuri comanda poate fi încă finalizată, chiar dacă nu erau mașini pe știft. La urma urmei, între pin și comandă trece ceva timp, iar căutarea comenzii este mai completă și uneori se repetă de mai multe ori: în acest timp, pot apărea drivere disponibile. Știam și contrariul: dacă se găseau șoferi pe știft, nu era un fapt că ar fi găsit la comandă. Uneori ele dispar sau toată lumea refuză comanda.
Pentru a testa această ipoteză, am lansat un experiment: am încetat să verificăm prezența mașinilor în timpul unei căutări pe un Pin pentru un grup de testare de utilizatori, adică au avut ocazia să facă o „comandă fără mașini”. Rezultatul a fost destul de neașteptat: dacă mașina nu era pe știft, atunci în 29% din cazuri a fost găsită mai târziu - la căutarea pe comandă! În plus, comenzile fără mașini nu au fost semnificativ diferite de comenzile obișnuite în ceea ce privește ratele de anulare, evaluările și alți indicatori de calitate. Rezervările fără mașini au reprezentat 5% din toate rezervările, dar puțin peste 1% din toate călătoriile de succes.
Pentru a înțelege de unde provin executanții acestor ordine, să ne uităm la stările lor în timpul unei căutări pe un Pin:
- Disponibil: era disponibil, dar din anumite motive nu a fost inclus în candidați, de exemplu, era prea departe;
- La comandă: era ocupat, dar a reușit să se elibereze sau să devină disponibil pentru ;
- Ocupat: capacitatea de a accepta comenzi a fost dezactivată, dar apoi șoferul a revenit la linie;
- Nu este disponibil: șoferul nu era online, dar a apărut.
Să adăugăm fiabilitate
Comenzile suplimentare sunt grozave, dar 29% din căutările de succes înseamnă că 71% din timp, utilizatorul a așteptat mult timp și a ajuns nicăieri. Deși nu este un lucru rău din punct de vedere al eficienței sistemului, de fapt dă utilizatorului false speranțe și pierde timp, după care se supără și (eventual) încetează să mai folosească serviciul. Pentru a rezolva această problemă, am învățat să anticipăm probabilitatea ca o mașină la comandă să fie găsită.
Schema este după cum urmează:
- Utilizatorul pune un ac.
- Se efectuează o căutare pe pin.
- Dacă nu sunt mașini, prezicem: poate vor apărea.
- Și în funcție de probabilitate, vă permitem sau nu vă permitem să plasați o comandă, dar vă avertizăm că densitatea mașinilor în această zonă în acest moment este scăzută.
În aplicație arăta așa:
Folosirea modelului vă permite să creați noi comenzi mai precis și să nu liniștiți oamenii în zadar. Adică, pentru a regla raportul de fiabilitate și numărul de comenzi fără mașini folosind modelul de precizie-rechemare. Fiabilitatea serviciului influențează dorința de a continua utilizarea produsului, adică în cele din urmă totul se reduce la numărul de călătorii.
Un pic despre precizie-rechemareUna dintre sarcinile de bază în învățarea automată este sarcina de clasificare: atribuirea unui obiect uneia dintre cele două clase. În acest caz, rezultatul algoritmului de învățare automată devine adesea o evaluare numerică a apartenenței la una dintre clase, de exemplu, o evaluare a probabilității. Cu toate acestea, acțiunile care sunt efectuate sunt de obicei binare: dacă mașina este disponibilă, atunci vă vom lăsa să o comandați, iar dacă nu, atunci nu o vom face. Pentru a fi specific, să numim un algoritm care produce o estimare numerică un model, iar un clasificator o regulă care îl atribuie uneia dintre cele două clase (1 sau –1). Pentru a realiza un clasificator bazat pe evaluarea modelului, trebuie să selectați un prag de evaluare. Cum depinde în mare măsură de sarcină.
Să presupunem că facem un test (clasificator) pentru o boală rară și periculoasă. Pe baza rezultatelor testului, fie trimitem pacientul pentru o examinare mai detaliată, fie spunem: „Bine, du-te acasă”. Pentru noi, trimiterea unei persoane bolnave acasă este mult mai rău decât examinarea inutilă a unei persoane sănătoase. Adică vrem ca testul să funcționeze pentru cât mai mulți oameni cu adevărat bolnavi. Această valoare se numește recall =. Un clasificator ideal are o reamintire de 100%. O situație degenerată este să trimiți pe toți la examinare, apoi rechemarea va fi, de asemenea, 100%.
Se întâmplă și invers. De exemplu, facem un sistem de testare pentru studenți și are un detector de înșelăciune. Dacă brusc verificarea nu funcționează pentru unele cazuri de înșelăciune, atunci acest lucru este neplăcut, dar nu critic. Pe de altă parte, este extrem de rău să acuzi pe nedrept studenții de ceva ce nu au făcut. Adică este important pentru noi ca printre răspunsurile pozitive ale clasificatorului să fie cât mai multe corecte, poate în detrimentul numărului lor. Aceasta înseamnă că trebuie să maximizați precizia = . Dacă declanșarea are loc pe toate obiectele, atunci precizia va fi egală cu frecvența clasei definite din eșantion.
Dacă algoritmul produce o valoare de probabilitate numerică, atunci prin selectarea diferitelor praguri, puteți obține diferite valori de retragere de precizie.
În problema noastră situația este următoarea. Rechema este numărul de comenzi pe care le putem oferi, precizia este fiabilitatea acestor comenzi. Iată cum arată curba de precizie-rechemare a modelului nostru:
Există două cazuri extreme: nu permiteți nimănui să comande și permiteți tuturor să comande. Dacă nu permiteți nimănui, atunci rechemarea va fi 0: nu creăm comenzi, dar niciuna dintre ele nu va eșua. Dacă permitem tuturor, atunci retragerea va fi de 100% (vom primi toate comenzile posibile), iar precizia va fi de 29%, adică 71% din comenzi vor fi proaste.
Am folosit ca semne diverși parametri ai punctului de plecare:
- Timp/loc.
- Starea sistemului (numărul de utilaje ocupate de toate tarifele și pinii din apropiere).
- Parametri de căutare (rază, număr de candidați, restricții).
Mai multe despre semne
Din punct de vedere conceptual, dorim să distingem două situații:
- „Pădurea adâncă” - nu există mașini aici în acest moment.
- „Gin noroc” - există mașini, dar la căutare nu au existat unele potrivite.
Un exemplu de „ghinion” este dacă vineri seara există multă cerere în centru. Sunt multe comenzi, mulți oameni dornici și nu sunt destui șoferi pentru toată lumea. Se poate dovedi așa: nu există drivere adecvate în pin. Dar literalmente în câteva secunde apar, pentru că în acest moment există o mulțime de șoferi în acest loc și statutul lor se schimbă constant.
Prin urmare, diverși indicatori de sistem din vecinătatea punctului A s-au dovedit a fi caracteristici bune:
- Numărul total de mașini.
- Numărul de mașini la comandă.
- Numărul de mașini indisponibile pentru comandă în starea „Ocupat”.
- Număr de utilizatori.
La urma urmei, cu cât sunt mai multe mașini, cu atât este mai probabil ca una dintre ele să devină disponibilă.
De fapt, pentru noi este important ca nu numai mașinile să fie localizate, ci să se facă și călătorii reușite. Prin urmare, a fost posibil să se prezică probabilitatea unei călătorii de succes. Dar am decis să nu facem acest lucru, deoarece această valoare depinde foarte mult de utilizator și șofer.
Algoritmul de antrenament al modelului a fost . Datele obținute în urma experimentului au fost folosite pentru antrenament. După implementare, au trebuit colectate datele de instruire, permițând uneori unui număr mic de utilizatori să comande împotriva deciziei modelului.
Rezultatele
Rezultatele experimentului au fost cele așteptate: utilizarea modelului vă permite să creșteți semnificativ numărul de călătorii reușite datorită comenzilor fără mașini, dar fără a compromite fiabilitatea.
În momentul de față, mecanismul a fost lansat în toate orașele și țările și cu ajutorul acestuia se produc aproximativ 1% din călătoriile de succes. Mai mult, în unele orașe cu o densitate redusă de mașini, ponderea unor astfel de călătorii ajunge la 15%.
Alte postări despre tehnologia taxiului
Sursa: www.habr.com