天天看點

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

雷鋒網(公衆号:雷鋒網)按:騰訊大資料峰會暨 kdd china 技術峰會中,滴滴研究院副院長、密歇根大學終身教授葉傑平博士非常全面地解密了機器學習在滴滴中的大規模應用,其中包括:出行目的地預測、路徑規劃、拼車最優比對、訂單配置設定、估價、運力排程、評分系統等。雷鋒網根據現場演講整理成文,并由葉傑平博士與滴滴 cto 張博親自審文。

葉傑平:

滴滴研究院副院長,美國密歇根大學的終身教授。葉傑平是機器學習領域國際領軍人物,其主要從事機器學習、資料挖掘和大資料分析領域的研究,尤其在大規模稀疏模型學習中處于國際領先地位。

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

雷鋒網了解到,去年滴滴成立了機器學習研究院,之後改名為滴滴研究院。

滴滴研究院做的事情是結合大資料與機器學習,搭建滴滴交通大腦。滴滴交通大腦需要收集每個城市、每一時刻的所有交通出行相關資料,然後做出最優的決策(比對、導航等),進而提高出行效率。接下來我來分享一下滴滴過去一年在大資料和人工智能方面的探索。

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

打開滴滴出行 app,首頁中就包含很多人工智能:

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

預測目的地

我們先會精确定位使用者的位置,下方是使用者所要去的目的地。很多情況下我們能夠預測到使用者去哪裡:因為很多出行是比較有規律的:早上上班、晚上回家。我們利用使用者的出行資料從時間和地點中預測使用者去的目的地,這是人工智能的一種展現。

估價

我們常見的價格預估背後其實也有着非常複雜的計算過程,涉及到路徑規劃和時間預估(eta)。其中從起點到終點的路徑規劃是非常核心的一部分,找到最佳路徑後,我們需要計算出 a 到 b 的距離。随後着手解決行程所需的時間估算:起點到終點需要 20 分鐘還是 30 分鐘。結合路徑和時間,我們給出一個預估價。

拼車

拼車選項也是非常複雜的機器學習問題,我們需要計算使用者點選拼車後從起點到終點過程中找到一個拼友的機率。如果機率不大,這名乘客就很可能得一個人從頭坐到尾,而滴滴給出的折扣也會低一些,如九折等。如果這條是熱門路線,路途中很可能會有其他乘客與你在同一時間去同一個或附近的地方。這種情況下,我們可以打一次力度稍微較大的折扣。

乘客與司機比對

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

當使用者确認叫車後,滴滴需要做訂單比對,找到最适合接該使用者的司機。這一流程也是一系列的機器學習問題。

那麼如何權衡訂單合不合适,可以有多種辦法解決:比如距離和時間上離你最近的司機。當然,權衡訂單問題背後也包含個性化搜尋,如個别使用者可能隻喜歡某一類車型、某一種類型的司機。尤其是女性使用者在深夜十一二點,可能對車型和司機的要求比較高,這需要進行個性化比對。

如果使用者選擇拼車,系統如何找到最适合的一輛車:這輛車有可能是空車,也有可能是載人車,與此同時,算出 a 到 b 的時間。

熱力圖

這裡會遇到一種情況,新司機希望空駛時間越少越好,但往往不知道去哪接單,這時候滴滴會給到一個熱力圖,告訴司機哪些區域未來的半個小時,有可能有很多訂單需求。

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

滴滴研究院目前做的最核心的事情是訂單配置設定。在某個時刻有成千上萬的乘客,同時也有成千上萬的空閑車輛,我們要完成司機和乘客的最優比對,權衡标準是比對度。計算比對度最簡單的方法是用距離進行評估,滴滴在前幾年均是用距離進行比對。但路面距離計算仍存在很多不合理的地方,因為各個路段的狀況不同,有些地方特别堵,有些則相反,同樣是一公裡但行駛所耗時間可能完全不同。這裡就急需增加時間這一次元。而計算時間又是一大難題,比預估距離還要難。

是以滴滴實作訂單最優比對需要遵循這兩大核心:做出最優路徑規劃,預估時間。

大規模比對

計算出某個訂單的時間和距離後,會遇到一個問題:由于滴滴資料量特别大,每一個乘客不隻是讓一個司機去比對,而是需要跟周圍上百個司機比對。在任何一個時刻,滴滴的比對量高達千萬次以上,在一兩秒鐘完成上千萬次的路徑規劃,這是一項非常大的挑戰。

這項決策與搜尋不同,用 google 搜尋出結果後,再過 10 分鐘結果依舊與之前相同。而滴滴在比對時,哪怕滞後兩秒鐘這個司機就可能過了某個十字路口,使得路徑規劃狀況完全不同。我們現在建立起一個機器學習系統,該系統包含曆史資料和實時資料,隻要在有滴滴的地方,我們就知道車輛行駛的速度和路況。然後找特征,建立系統,也可用深度學習做路徑規劃和時間預估。

滴滴研究院最近建立了一套深度學習系統,然後加上路況和其他資訊去進行預測,這是滴滴在深度學習領域的一次嶄新嘗試。簡單對比下結果,去年開始用機器學習再到最近的深度學習使誤差大概降低了70%左右。

接下來需要做最優比對,這裡有很多不同的方法。滴滴有計程車、快車、專車、豪華車等等多條業務線,滴滴能否把各個業務線打通?比如使用者叫了快車,但周圍可能沒有快車司機來接使用者,那有沒有可能利用算法去做決策,在這個時刻讓專車或計程車司機來接這位使用者,該排程方案要做一個全局的最優比對,充分發揮滴滴優勢。

在北京,高峰期大家打車困難可能會認為是由于運力不夠導緻,但經過分析發現,在高峰期滴滴的運力其實是足夠的,主要是因為車輛分布不合理。

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

此我們開發了一套系統,把整個地球分割成無數個六邊形。每一時刻都在檢測每一個六邊形,然後在某個六邊形裡面計算訂單數和空車數,計算供需是否平衡。

運力問題解決

司機沒有在他應該在地方是我們需要解決的一大問題,如果有一個平台可掌握所有資訊,這樣使其能做出最優決策、最優排程以及導航決策。解決這個問題的第一種方法就是動态調價。我們也在探索另外兩種解決方式:

供需預測、運力排程:如何完成預測,我們先來還原一個場景,比如說某個大會大緻在晚上 6 點結束後,很多人會有打車需求,這就是預測的一種展現。此外,我們之前也提到人們出行普遍是有規律的,是以能預測某一時刻、某一區域可能缺多少輛車,這樣我們就提前 15 分鐘或半小時做排程,把過剩的運力從周圍調過去,緩解供需問題。這裡牽涉到供需預測,供需預測本質上就是一個時間序列的預測問題。

拼車:如果兩個乘客的行程和出行時間類似,就無需兩個司機去接,而是把兩個訂單整合為一個組合訂單,用一個司機來接。拼車中涉及到一項非常重要的問題就是使用者體驗:使用者體驗展現在兩個次元,一是價格便宜,二是在接另外一個人時繞的路程和時間不要太多。我們希望把兩個訂單整合起來後,這個行程路徑是相似的。為此,我們建立了幾個機器學習模型估計路徑比對度的高低。

行程結束後,我們也需要去預測乘客的體驗是好是壞。由于曆史訂單中有些乘客會進行投訴,比如說拼車比對欠佳、繞路。而有些使用者則會給出好評。我們從大量曆史資料學習出來哪些特征是導緻乘客抱怨的原因,哪些特征會導緻好評。

拼車最核心的一點是定價,裡面用的也是機器學習優化算法。核心想法非常簡單,如果乘客發了拼車單,我們會預測這個乘客起點到終點系統為它找到拼友的機率大不大,比對度如何?如果預測出他很大機率自己一個人會從頭到尾走到底的話,折扣相對就會更低,反之則會高一些。

除此之外,我們也做了很多圖像方面的工作。比如駕照圖像檢測,識别證件号碼等,讓司機的很多手續無需要到滴滴辦公室即可解決。

滴滴研究院副院長葉傑平:揭開滴滴人工智能排程系統的真面目

我們可以把滴滴看做是一種搜尋引擎,即乘客搜尋司機。與百度搜尋資訊不同,在百度搜尋結束後,就沒有其他後續問題。但乘客在滴滴中搜尋好司機後,滴滴需要保證安全和出行體驗。于是我們在近期引入一套機器學習系統,預測司機的服務品質和服務态度,衡量服務好還是壞需要通過分析大量乘客的打分、評語資料。

以往 滴滴和 uber 都采用星級打分制,後來我們發現該功能并不完美。現實情況是使用者要麼不打分,要麼給較高的五分或四分,使得星級評分功能不夠有效。

這本質上是使用者習慣問題,為了讓評分系統更加全面,平台把乘客留下的所有痕迹都整合起來,然後給出一個分數評判。比如乘客打出星級後,又進行文字評價态度很差、繞路等,針對乘客給出的兩個次元資訊,我們再根據軌迹等多項資料,然後給出綜合的分數。分數越高,滴滴也會保證司機的收入越高,推動司機主動提高服務品質。

這裡存在另外一個問題,就是乘客惡意給司機寫差評。針對這一情況我們建立了一個判責機器學習系統,該模型能夠判差評的背後是司機的責任,還是乘客的責任。如果責任不在司機,我們就不會降低它的分數。判責系統上線後滴滴平台司機滿意度有了顯著提高。

系統可視化

最後我們提一下非常重要的系統可視化性,這套系統能夠看到曆史訂單行程中發生了什麼事情,如哪些區域是我們比較感興趣的、成交率高的,訂單多的。其次是區域變化情況,如早高峰時訂單量漲了,晚高峰訂單量跌了,應答率可能在早晚高峰非常低,平時可能非常高,我們可以迅速知道每個區域、每個時刻的情況。

上述為區域,我們也可以有一個城市的次元,比如這個城市大概有多少訂單?大概有多少司機?乘客發出訂單需求成交率大概有多少?我們也能掌握過去和現在的情況,司機實時看到熱區所處的位置,引導司機沿着熱區去走,減少空駛時間、提高平台效率。

除此之外,我們也能實時看到跨城情況,尤其是春節之前等節假日,因為有很多人會拼車回家。為此,我們也會找到一些比較特殊的區域,單獨去分析它發生了什麼事。

可視化系統也能讓大家看到全城各個時刻供需不平衡情況:哪些區域供大于求,哪些區域求大于供,哪些區域供需平衡,以及現在和過去發生了什麼事。針對這些現象,我們需找到應答率低、成交率低的原因。

本文作者:亞峰

繼續閱讀