滴滴首席算法工程師爲你揭祕滴滴出行派單算法原理

導讀 :說到滴滴的派單算法,你們可能感受到既神祕又好奇,從出租車揚召到司機在滴滴平臺搶單,最後到平臺派單,你們今天的出行體驗已經發生了翻天覆地的變化。面對着天天數千萬的呼叫,滴滴的派單算法一直在持續努力讓更多人打到車。本篇文章會着重介紹滴滴是如何分析和建模這個問題,而且在這過程當中面臨了怎樣的算法挑戰,以及介紹一些經常使用的派單算法。這些算法可以不斷提高用戶打到車的肯定性。



爲何咱們須要更好的派單算法

   
首先來看一看,好的派單算法爲何是出行行業不可或缺的能力?

回想幾年前,當咱們尚未滴滴的時候,只能在寒風、酷暑中等待可能有、可能沒有的揚出租車,到後來能夠從滴滴呼叫一輛出租車。乘客能夠在室內相對溫馨的環境中等待車輛的到達,從線上到線下,乘客的肯定性獲得第一次的提高。然而這還不夠,搶單的模式註定咱們的應答率天花板不會過高。在15年,滴滴上線快車業務,咱們從搶單演進到了派單模式,乘客的應答率有了20個點以上的提高,不少時候可以全天可以高達90+(高峯&局部供需緊張應答率會相對吃緊),乘客肯定性再一次獲得大幅的提高。因而可知,派單模式爲滴滴創造了巨大用戶價值。

近年來不斷興起的O2O業務,從國內外的網約車公司,包括咱們的友商Uber、Lyft都基於派單的產品形態進行司機和乘客之間的交易撮合。Uber上市的時候把派單引擎做爲核心技術能力放在了招股書中;再看咱們國內的外賣平臺,核心派單系統的優劣決定了整個平臺的交易效率(單均配送成本)和用戶體驗(配送時長);最後,整個大物流行業近年來也不斷在進行線上化的改造,如何撮合貨物和司機,以及更好的拼單能力也是整個交易環節的關鍵和商業模式是否成立的前提。從運人到運物, 派單引擎 目前愈來愈多的被應用在現實的商業和生活中。


派單問題初探

   
言歸正傳,這裏咱們也來看一下,滴滴網約車平臺究竟是怎麼派單的。首先,咱們來看下咱們面對的是什麼樣的問題?
 
「訂單分配 便是在派單系統中將 乘客發出的訂單 分配給 在線司機 的過程」
 
這是一個看似簡單,但實際上很是複雜的問題。說到這,可能有不少人就會問,可否就把 個人訂單分配給離我最近的司機就行了?

的確啊,實際上目前滴滴的派單算法最大的原則就是 「就近分配」 (70%~80%的訂單就是分配給了最近的司機)。據我所知,目前世界上其餘的競品公司(包括Uber),也均是基於這個原則分單的。 

咱們進一步來看這個問題,若是咱們只按照就近分配,先到先得的貪心策略,是否是能最好的知足平臺全部乘客和司機的訴求呢?答案是否認的,緣由就在於,若是咱們只基於當前時刻和當前局部的訂單來進行決策,忽視了將來新的訂單&司機的變化,還忽視了和你相鄰的其餘區域甚至整個城市的需求(注:在時序上來看,會有新的司機&訂單的出現,貪心策略反而違背了就近分配的目標)。這就是爲何這個問題依然複雜的緣由。

這裏的內容稍微有點抽象了,不過不要緊,咱們再來一步一步的拆解一下訂單分配的問題,讓你們有個更好的理解:

在咱們的平臺上,每個時刻,都有N個訂單在被乘客建立,同時有M個司機能夠被咱們用來分配,咱們強大的平臺可以爲派單算法給出司機的實時的地理位置座標,以及全部訂單的起終點位置,而且告訴咱們每個司機接到訂單的實時導航距離。
 

若是是1個訂單、1個司機


      
看上去彷佛就很是簡單了,咱們直接把這個訂單指派給這個司機就行了嘛。

「那麼爲何有時候附近有輛空車卻不能指派給你呢?」

實際線上的系統會比這裏稍微複雜一點,緣由一方面有多是司機正好網絡出現故障,或者正在和客服溝通等等致使司機沒法聽單,另外一方面的緣由是並非全部的車都可以符合服務你訂單的要求。最基本的策略實際上是人工設定的規則過濾。舉幾個最基礎的例子:

  • 規則A:快車司機不能接專車訂單
  • 規則B:保證司機接單後不會經過限行限號區域
  • 規則C:爲設定實時目的地的司機過濾不順路區域
  • 規則D:爲只聽預定單司機過濾實時訂單
  • 規則E:同一個訂單隻會發給一個司機一次
  • ......
    
必須澄清的一點是這裏的規則並不會形成分單時不公平的效果,而徹底是爲了業務能正常運行而設立的,這些策略承擔着保證業務正確性的重要職責。
 

若是是1個訂單和2個司機


假設這兩個司機都可以分配給這個訂單,那麼咱們來看系統應該是如何分配的。
首先第一種狀況是,同一時刻下,這兩個司機和訂單的距離都徹底同樣的狀況下,系統應該如何分配?


剛纔也說到,咱們平臺訂單分配最大的原則是就近分配,當距離徹底同樣的狀況下,當前咱們系統上會主要考慮司機的服務分的優劣,服務分較高的司機會獲取到這個訂單(注:服務分對分單的影響,簡單的理解能夠換算爲多少分能夠換成多少米距離的優點,這塊不是今天的重點就不展開介紹),再說明一下,系統用到的是地圖的導航距離,而非人直觀看到的直線距離,有時候差一個路口就會由於須要掉頭致使距離差別很大;而且若是司機的定位出現問題,也會出現分單過遠的狀況。

那麼咱們來看第二種狀況,若是A司機離的近,B司機離的遠,系統怎麼派?


這就簡單了,根據就近分配的原則,咱們會把A司機分配給這個訂單。嘿嘿~~,假設咱們再把問題設置的更加實際一點,當訂單發出時,B司機已經在線並空閒,可是A司機尚未出現(沒有上線,或者還在送乘客),但再過1s,離得更近的A司機忽然出現可被分單了。假設咱們使用先到先得的貪心策略,那麼B司機就會被分給這個訂單,那就違背咱們但願就近分單的目標了。因此看上去簡單,但實際狀況下,算法還須要變的更好一些,這個問題咱們把它叫作派單中的時序問題,咱們後面再來看怎麼解決。

若是有N個乘客、M個司機


最後咱們來考慮最複雜的多對多的狀況,這也是線上系統天天高峯期都須要面對的挑戰。咱們通常把這種狀況會形式化爲一個二部圖的匹配問題,在運籌領域也叫作matching的問題,如圖所示:


咱們再把這個問題具象一點,假設這個時候咱們有20個乘客,有20個司機,這些乘客均可以被這20個司機中的一個接駕,咱們的系統須要把這20個乘客都分配出去,而且讓你們的整體接駕的時長最短。聽上去是否是有點複雜?咱們套用下組合數學的知識,這其中可能的解法存在20的階乘那麼多,20的階乘是什麼概念呢?20*19*18*…*1= 2432902008176640000,這個數巨大無比,想要徹底的暴力搜索是絕對不可能的。這裏須要更聰明的辦法。
 

若是有N個乘客、M個司機,一會再來幾個乘客和司機?


這就是派單問題最大的挑戰,咱們不只僅須要當前這個時刻的最優,咱們要考慮將來一段時間總體的最優。新來的司機和乘客會在整個分配的網絡中實時插入新的節點,如何更好的進行分配也就發生了新的變化,因此如何考慮時序對咱們很是重要。這個問題在業內也被稱爲Dynamic VRP問題,這個Dynamic也就是隨時間時序變化的意思,這也就是爲何,滴滴的派單問題遠複雜於物流行業的相對靜態的貨物和路線的規劃問題。假設咱們知道了將來供需的徹底真實的變化,仿真告訴咱們,咱們的系統有可能能夠利用一樣的運力完成1.2~1.5倍的需求量,這也是派單算法的同窗持續爲之努力的方向。

想起前段時間的吐槽大會,你們提到文嵩曾說咱們的派單問題比Alpha Go還要難。其實這兩個問題還確實有點類似,都是在超大的搜索空間中找到一個近似最優的解,而Alpha Go則會在一個更加明確的遊戲規則和環境中進行求解。它的難點在於博弈,而咱們的派單問題難點在於將來供需不肯定性&用戶行爲的不肯定性。近年來在學界,已經有很多嘗試在利用相似Alpha Go的技術進行VRP&TSP等方向的探索,強化學習結合運籌理論是將來運籌界很是前沿的方向之一(非技術同窗能夠跳過此處:))。


派單算法簡介

   
上面咱們已經描述了什麼是訂單分配問題,而且它所面臨的各類挑戰,那麼在這裏咱們來
聊一聊咱們線上的派單策略是如何解決其中一部分問題的。

在介紹具體策略以前,首先咱們來講一下派單算法大的原則,目前派單策略主要的原則是:站在全局視角,儘可能去知足儘量多的出行需求,保證乘客的每個叫車需求均可以更快更肯定的被知足,並同時盡力去提高每個司機的接單效率,讓總的接駕距離和時間最短。

如何理解這個原則呢?咱們說策略會站在全局的角度去達成全局最優,這樣對於每個獨立的需求來看,派單可能就不是「局部最優   」。不過能夠告訴你們的是,就算在這個策略下,仍然有70%~80%的需求也是符合當前距離最近的貪心派單結果的。

接下來,這裏會拿兩個重要的派單策略的來進行介紹。(這裏的內容主要是以講清楚策略的motivation爲主哈,細節再也不展開)

批量匹配(全局最優)


派單策略中最爲基礎的部分,就是爲了解決上一節所提到的時序問題。這個算法幾乎是全部相似派單系統爲了解決這個問題的最基礎模型,在Uber叫作Batching Matching,咱們內部也叫作「全局最優」 或者 「延遲集中分單」。

這個Idea也很是直觀。因爲用戶訂單的產生和司機的出現每每並不在同一時間點,在時間維度上貪婪的分單方式(即每一個訂單出現時即選擇附近最近的司機派單)並不能得到全局最優的效果。一個天然的想法就是先讓乘客和司機稍等一會,待收集了一段時間的訂單和司機信息後,再集中分配。這樣,有了相對較多、較密集的訂單與司機後,派單策略便可找到更近更合理的派單方式了。

找尋司機和訂單分配的全局最優是一個 二分圖匹配問題 (bipartite graph matching) ,一邊是乘客,一邊是司機,可用運籌優化中各類解決Matching問題的方法進行求解。

和你們澄清一下,咱們所採用的批量匹配的模式,和你們所但願的「把離我最近的司機派給我」的「就近派單模式」並不矛盾。咱們也是尋求「乘客接駕時長最短」的最優解。大多數狀況下也是指派離你最近的司機,但充分知足每個乘客的「把離我最近的司機派給我」的個體需求, 有些時候反而會致使部分乘客的需求沒法獲得知足,好比說下面這種狀況:

當編號1和2兩個乘客同時叫車, 若是徹底按照「就近派單」的模式, 雖然可讓1號乘客先被接單, 可是2號乘客會由於接駕距離較遠, 致使等待時間變長, 甚至由於最近的司機超出平臺派單距離, 致使2號乘客叫不到車。一、2號乘客總等待時長15分鐘, 平均等待時長7.5分鐘。


咱們採起的作法是, 把距離較遠的2號車派給1號乘客。

把1號車派給2號乘客, 這樣一來, 1號乘客和2號乘客, 平均等待時長縮短爲5分鐘,比就近派單,縮短了2.5分鐘,總等待時長縮短爲10分鐘, 比就近派單, 縮短了足足5分鐘。


經過提高全局的效率,才能轉化爲讓更多乘客的需求獲得知足。
 

基於供需預測的分單


「若是有先知告訴咱們將來每個訂單的生成時間&地點,每個司機的上線時間&地點,派單就會變成很是輕鬆的一件事」。

剛纔所說的批量匹配的方法,理論上可以保證那一個批次的匹配是最優的。可是這樣就夠了嗎?

很遺憾,以上所述的延遲集中分單的策略只能解決部分的問題,仍不是一個徹底的方案。其最大的問題,在於用戶對系統派單的 響應時間 容忍度有限,不少狀況下短短的幾秒鐘即會使用戶對平臺喪失信心,從而取消訂單。故實際線上咱們只累積了幾秒鐘的訂單和司機信息進行集中分單,而這在大局上來講仍可近似看作時間維度上的貪婪策略。

若想即時的得到最優派單結果,惟一的方法是利用對將來的預測,即進行基於供需預測的分單。這種想法說來玄妙,其實核心內容也很簡單:若是咱們預測出將來一個區域更有可能有更多的訂單/司機,那麼匹配的時候就讓這個區域的司機/訂單更多去等待匹配這同一個區域的訂單/司機。

連環派單


基於供需預測的分單有很大意義,但因爲預測的不肯定性,其實際效果很可貴到保證。爲此,咱們使用了一種更有肯定性的預測方式來進行派單,即 連環派單。

「連環派單,即將訂單指派給 即將結束服務 的司機,條件爲若是司機的終點與訂單位置很相近」


與預測訂單的分佈相反,連環派單預測的是下一時刻空閒司機的所在位置。因爲高峯期空閒司機多爲司機完成訂單後轉換而來,預測司機的位置就變成了一個相對肯定性的問題,即監測司機到目的地的距離和時間。當服務中的司機距終點很近,且終點離乘客新產生的訂單也很近時,便會命中連環派單邏輯。司機在結束上一單服務後,會馬上進入新訂單的接單過程當中,有效地壓縮了訂單的應答時間、以及司機的接單距離。

如何作到更好


整個派單算法核心克服的是將來供需的不肯定性,動態的時空結構的建模,以及用戶行爲的不肯定性,對於這些不肯定性咱們如今更多采用深度學習方法對咱們的時空數據&用戶行爲進行建模預測。

另外,咱們的問題相對於傳統推薦搜索領域,多了一層匹配決策,咱們到底積攢多久的訂單進行分配,對於每個分配來講咱們都面臨着分或者不分,如今分仍是將來分配,而且分給誰的問題,這個問題天生就能夠建模爲強化學習問題,目前在咱們的系統中也引入了強化學習方法來優化更長期的收益。

除了不斷去優化以前說到的派單問題,整個派單系統還面臨着大量的挑戰,包括如何利用快車優享等多個品類的運力進行跨層的最優分配,如何同時對用戶&司機&平臺短時間長期等多個目標進行優化,如何同時優化預定&實時訂單,如何在具有網絡效應的場景下對算法進行評估,若是創建一個較爲精準的仿真系統等等,這裏既是挑戰,也是AI For Transportation中大量新的從新定義問題和創新算法的機會。


 總結
   
天天, 咱們的派單系統要面對超過3000萬用戶的叫車需求,   高峯期每分鐘接收超過6萬乘車需求,平均每兩秒就須要匹配幾百到上千的乘客和司機 。咱們當前的派單策略相對於最初的派單策略版本,天天可以知足百萬以上乘客的出行需求。爲了讓更多人能更快、更肯定的打到車,咱們的交易策略團隊將在更好的公平感知的前提下,不斷地優化和打磨咱們的派單算法,爲乘客&司機創造更多價值。


   

    
      
  
     
     
      
      
               
      
  
     
本文做者
王犇
滴滴 | 首席算法工程師

感謝受權轉載
html

本文觀點不表明我方觀點web





SGADC議題回顧

(戳文字看原文)算法


1.騰訊遊戲TGPA技術負責人揭祕官方性能技術解決方案的優化之路
2.優酷資深技術專家解析優酷視頻投屏場景優化方案
3.支付寶移動端高可用 Hybrid 方案解析
4.擁抱方舟編譯器:Maple IR 分析及 Toy Runtime 介紹



本文分享自微信公衆號 - 軟件綠色聯盟(sgachina)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。微信

相關文章
相關標籤/搜索