良好的計程車服務應該安全、可靠、快速。 用戶不會詳細說明：對他來說重要的是，他點擊「訂購」按鈕並儘快收到一輛汽車，將他從 A 點帶到 B 點。如果附近沒有汽車，該服務應該立即告知客戶，以免客戶產生錯誤的期望。 但如果「禁止汽車」標誌出現得太頻繁，那麼人們就會停止使用這項服務並轉向競爭對手，這是合乎邏輯的。
在這篇文章中，我想談談如何使用機器學習解決在低密度區域（換句話說，乍一看沒有汽車的地方）搜尋汽車的問題。 結果如何。
底
要叫計程車，用戶只需執行幾個簡單的步驟，但服務內部會發生什麼事？
| 用戶 | 階段 | 後端 Yandex.Taxi |
|---|---|---|
| 選擇起點 | 別針 | 我們正在推出簡化的候選人搜尋 - pin 搜尋。 根據找到的驅動程序，預測到達時間 - 引腳中的 ETA。 計算給定點的增加係數。 |
| 選擇目的地、票價、要求 | 提供 | 我們建立一條路線並計算所有關稅的價格，同時考慮遞增係數。 |
| 按“叫出租車”按鈕 | 順序 | 我們對這輛車展開全面搜尋。 我們選擇最合適的司機並向他提供訂單。 |
Про , и 我們已經寫了。 這是一個尋找司機的故事。 建立訂單後，搜尋會發生兩次：在 Pin 圖上和在訂單上。 尋找訂單分兩個階段進行：招募候選人和排名。 首先，找到沿著路線圖最近的可用候選駕駛員。 然後應用獎金和過濾。 剩餘的候選人將被排名，獲勝者將收到訂單報價。 如果他同意，他就會被分配到訂單並前往交貨點。 如果他拒絕，那麼這個提議就會進入下一個。 如果沒有更多的候選人，則重新開始搜尋。 這持續不超過三分鐘，之後訂單將被取消並銷毀。
在 Pin 圖上搜尋與在訂單上搜尋類似，只是不會建立訂單並且搜尋本身僅執行一次。 也使用了候選數量和搜尋半徑的簡化設定。 這種簡化是必要的，因為引腳數比階數多一個數量級，並且搜尋是一項相當困難的操作。 我們故事的關鍵點是：如果在初步搜尋過程中沒有在 Pin 圖上找到合適的候選人，那麼我們不允許您下訂單。 至少過去是這樣。
這是用戶在應用程式中看到的內容：
搜尋沒有汽車的汽車
有一天，我們提出了一個假設：也許在某些情況下訂單仍然可以完成，即使pin上沒有汽車。 畢竟，在 pin 和訂單之間會經過一段時間，並且對訂單的搜尋更加完整，有時會重複幾次：在此期間，可能會出現可用的驅動程式。 我們也知道相反的情況：如果在引腳上找到了驅動程序，那麼在訂購時就不會發現它們。 有時他們會消失或每個人都拒絕訂單。
為了驗證這個假設，我們發起了一項實驗：在測試使用者群組的 Pin 圖搜尋過程中，我們停止檢查汽車是否存在，也就是說，他們有機會下「沒有汽車的訂單」。 結果卻出乎意料： 如果汽車不在 pin 上，那麼在 29% 的情況下，它是稍後在訂單上搜尋時找到的！ 此外，無車訂單在取消率、評分和其他品質指標方面與常規訂單沒有顯著差異。 無車預訂佔所有預訂的 5%，但僅佔所有成功旅行的 1% 多一點。
為了了解這些訂單的執行者來自哪裡，讓我們看看他們在 Pin 圖上搜尋時的狀態：
- 可用的： 有空，但由於某種原因沒有被列入候選人，例如，他距離太遠；
- 訂購： 很忙，但設法解放自己或有空 ;
- 忙碌的： 接受訂單的能力被禁用，但隨後司機又回到了隊列；
- 無法使用： 司機並不在線，但他出現了。
讓我們增加可靠性
額外的訂單固然很棒，但 29% 的成功搜尋意味著 71% 的時間用戶等待了很長時間而最終無處可去。 雖然從系統效率的角度來看這並不是一件壞事，但它實際上給用戶帶來了虛假的希望並浪費了時間，之後他們會感到不安並（可能）停止使用該服務。 為了解決這個問題，我們學會了預測找到訂購的汽車的可能性。
方案是這樣的：
- 用戶放置圖釘。
- 對引腳進行搜尋。
- 如果沒有汽車，我們預測：也許它們會出現。
- 並且根據機率，我們允許或不允許您下訂單，但我們警告您，此時該區域的汽車密度較低。
在應用程式中它看起來像這樣：
使用該模型可以讓您更準確地創建新訂單，而不是徒勞地讓人們放心。 即使用精確召回模型來調節無機器的可靠性和訂單數的比率。 服務的可靠性會影響繼續使用該產品的願望，也就是說，最終一切都取決於出行次數。
關於精確召回的一些知識機器學習的基本任務之一是分類任務：將一個物件分配給兩個類別之一。 在這種情況下，機器學習演算法的結果通常會變成對某一類別中的成員資格的數值評估，例如機率評估。 然而，所執行的操作通常是二元的：如果汽車可用，那麼我們會讓您訂購它，如果沒有，那麼我們不會。 具體來說，我們將產生數值估計的演算法稱為模型，將分類器稱為將其分配到兩個類別之一（1 或 –1）的規則。 要根據模型評估製作分類器，需要選擇評估閾值。 具體如何在很大程度上取決於任務。
假設我們正在對一些罕見且危險的疾病進行測試（分類器）。 根據檢查結果，我們要么送病人做更詳細的檢查，要么說：“好，回家吧。” 對我們來說，將病人送回家比對健康人進行不必要的檢查要糟糕得多。 也就是說，我們希望該測試對盡可能多的真正患病的人有效。 這個值稱為召回率 =。 理想的分類器具有 100% 的召回率。 一種簡陋的情況就是把所有人都送去檢查，那麼召回率也會是100%。
反之亦然。 例如，我們正在為學生做一個測試系統，它有一個作弊偵測器。 如果突然檢查對於某些作弊情況不起作用，那麼這會令人不愉快，但並不重要。 另一方面，不公平地指責學生沒有做過的事情是極其糟糕的。 也就是說，對我們來說重要的是，在分類器的肯定答案中，有盡可能多的正確答案，也許會損害它們的數量。 這意味著您需要最大化精度= 。 如果觸發發生在所有物件上，則精確度將等於樣本中定義的類別的頻率。
如果演算法產生一個數值機率值，那麼透過選擇不同的閾值，您可以獲得不同的精確召回值。
在我們的問題中，情況如下。 召回率是我們可以提供的訂單數量，精確度是這些訂單的可靠性。 這就是我們模型的精確率-召回率曲線的樣子：
有兩種極端情況：不允許任何人點餐和允許所有人點餐。 如果你不允許任何人，那麼召回率將為0：我們不創建訂單，但它們都不會失敗。 如果我們允許所有人，那麼召回率將是 100%（我們將收到所有可能的訂單），精確率將是 29%，即 71% 的訂單將是不好的。
我們使用起點的各種參數作為標誌：
- 時間/地點。
- 系統狀態（附近所有費率和引腳的佔用機器數量）。
- 搜尋參數（半徑、候選者數量、限制）。
有關標誌的更多信息
從概念上講，我們要區分兩種情況：
- 「森林深處」——此時這裡沒有汽車。
- 「不幸」——有車，但搜尋時沒有合適的車。
「不幸」的一個例子是周五晚上中心的需求量很大。 訂單很多，願意的人很多，但沒有足夠的司機滿足每個人的需求。 結果可能是這樣的：引腳中沒有合適的驅動程式。 但實際上幾秒鐘之內他們就出現了，因為此時這個地方有很多司機，他們的狀態不斷在改變。
因此，A點附近的各種系統指標結果證明是很好的特徵：
- 汽車總數。
- 訂單汽車數量。
- 處於「忙碌」狀態無法訂購的汽車數量。
- 用戶數量。
畢竟，汽車越多，其中一輛可用的可能性就越大。
事實上，對我們來說重要的不僅是汽車的定位，還有成功的出行。 因此，可以預測旅行成功的機率。 但我們決定不這樣做，因為這個值很大程度上取決於使用者和驅動程式。
模型訓練演算法為 。 從實驗中獲得的數據用於訓練。 實施後，必須收集訓練數據，有時允許少數用戶根據模型的決定進行訂購。
結果
實驗結果符合預期：使用此模型可以顯著增加無車訂單導致的成功出行次數，但不會影響可靠性。
目前，該機制已在所有城市和國家啟動，在其幫助下，約1%的成功出行發生了。 而且，在一些汽車密度較低的城市，此類出行的比例達到15%。
有關出租車技術的其他帖子
來源： www.habr.com