桔妹導讀：IT技術的不斷更新推進着公共交通的概念不斷在深度和廣度上擴展。深度上，精準的公交ETA和實時到站等信息能夠幫助用戶更好的規劃行程時間；廣度上，配合單車，網約車等共享出行方式能夠幫助用戶更好的決策出行方式。 html
整體來講，路徑規劃分爲算路和排序兩個階段，在算路階段召回能到達用戶指定OD的線路，分爲離線和在線兩個階段；排序階段綜合步行距離，到達時間，換乘次數，乘車價格等不一樣的用戶偏好給出最匹配用戶的N條結果。算法
2.1.1. 離線算路與在線算路微信
路徑規劃問題的基本思路是首先將城市的公交和地鐵線路數據，以站點集合爲頂點集合V，每條公交或地鐵線路上相鄰的兩站用邊鏈接起來獲得有向圖。同時，因爲站點之間換乘須要一段步行是常見狀況，所以還須要將距離較近的兩個站用步行路網也用邊鏈接起來（圖中的藍色虛線）。最後，以每段路徑的預估消耗時間做爲每條邊的權重，就獲得了一張有向帶權圖。有了這樣一張有向帶權圖後，當用戶輸入起點和重點請求換乘路線信息的時候，問題就轉換爲：已知有向帶權圖中的起始節點O和終止節點D，搜索找到O和D之間的K條較優通路。網絡
這類問題常規的解法有BFS，Dijkstra，Floyd等，但在實際應用中，基於性能考慮，都不會在線實時的用這張圖去計算，而是將一部分預處理的工做轉移到離線階段。架構
2.1.1.1. 離線算路app
儘管離線計算對性能的要求比在線低不少，但因爲加入了步行以後的公交地鐵有向圖網絡每一個頂點的分叉很是多，直接使用BFS，Dijkstra這類算法依然會難以忍受，所以滴滴根據自身的實際的數據狀況進行了如下幾種優化：機器學習
路網分層函數
在現實中，咱們每每會有一些你們熟知的大區之間的聯絡線路，如地鐵4號線能夠從中關村區域到大興區域。當咱們從海淀其餘區域本身規劃乘車去大興的時候也會先想到坐到地鐵4號線的某站到大興區域的某站，而後再看從這一站怎麼到達最終目的地。這當中大區之間爲人熟知的聯絡線路其實就是一種先驗信息，借鑑這種思路，咱們在離線階段抽象出若干較大片的區域，提早計算好這些區域之間幾條主幹通路，在線時，將起終點轉換爲區域，取出事先已算好的區域通路路徑，能夠大幅下降計算成本。工具
雙向搜索(Bidirectional Search)
正如他的名稱同樣，借鑑你們實際應用中找路線的想法，同時從起點和終點掃描各自通過相向的線路，尋找其中有沒有共同的車站（或步行可達的車站）。雙向是一種很是有效的提效手段，BFS，Dijkstra都有雙向的變種。性能使用估值函數剪枝
在搜索中一個常見提高性能的最重要的策略就是剪枝，經過一些耗時小的估算，提早結束一些明顯會比當前路徑更差的。咱們採用的是AStar算法。
2.1.1.2. 在線算路模塊
在線算路模塊，須要根據用戶輸入的起終點在上一步離線算路模塊中選出最佳方案，並根據實時車輛狀況，計算單車拼乘和網約車拼乘方案。
多模實時換乘
在離線算路階段產出的方案，根據用戶輸入的起終點選擇最佳上下車站點。再根據實時單車/網約車信息，生成步行/騎行/網約車前往站點來接駁公交/地鐵的方案。在線剪枝
多模接駁階段會產生大量方案，爲了提升線上服務性能，須要將方案進行剪枝。包括將不在運營時間的方案、價格明顯偏高，網約車排隊時間過長，或單車數量較少區域的方案去除。同時，將多個路線一致的方案合併成一個。粗排計算
通過前面處理後，獲得了全部可行方案，下面須要對這些方案進行排序，選擇最優的方案。粗排計算階段須要根據每條方案的基礎特徵（例如耗時、路程等），對上千條可行方案快速計算評分，根據分數選出候選方案集送給後續排序模塊。
2.1.1.3. 排序模塊
ETA
ETA是用戶選擇時最主要的參考信息。爲了更精準地獲得方案的耗時，推薦出實時最佳方案。滴滴利用路況信息、歷史通行耗時等信息，借鑑網約車的經驗，創建了公交車專用ETA模型用來估計車輛當前位置到達站點和到達目的站點的時間。更精確地預計了用戶的等車時間和到達目的地時間。
網約車模型收益
精排
多模換乘推薦引擎中須要比較衆多包含多種交通工具的候選方案。而將包含多種不一樣交通工具公平地進行比較，並推薦出若干個符合大衆心目中最優的方案是一個較爲複雜的問題。除了基礎特徵外，還須要從方案中挖掘出更多信息，加強模型的表徵能力。咱們設計了包含預計通行時間、換乘次數、步行距離、綜合距離、地鐵距離、單車距離、價格、發班時間、備選車次數量、交通工具類型、是否在主幹道行駛、是否公交專用道、各類交通工具佔比等若干高級特徵。在線計算出特徵後，提供給後續排序模型使用。
Rerank和多樣性
爲了兼顧用戶的個性化訴求，最終展現給用戶的N條方案時，經過rerank來保證總體方案的多樣性。通常用戶的個性化因素包括價格是否敏感，地鐵偏好，步行長短，換乘偏好等等。以點擊率做爲整個公交方案的線上觀察指標。
▍2.2 實時公交服務
隨着傳統行業的線上數字化改造，已有200多個城市公交巴士都配置了智能硬件設備，能夠實時上報公交的位置。以此爲基礎，向用戶提供實時公交位置，預估等待時間等相關信息成爲公交服務的又一基礎功能。總體架構以下：
2.2.1. 數據接入
實時公交的數據來自公交公司和交委，然而因爲沒有統一的標準。上報的格式，各字段的含義都不同，所以滴滴制定了一套本身的數據規範來適配各地數據，從而對應用層提供統一格式的數據。除了格式的統一以外，因爲公交站點和線路的名稱，ID編碼規則各地也都會不按期發生變化，所以，爲了保障應用層使用的繼承性，滴滴對全部數據也定義了本身的ID編碼規則。在數據接入階段，還有一個重要的工做就是對數據實體進行映射。
2.2.2. GPS位置補償
位置的正確性和時效性是實時公交服務的核心能力，若是用戶在線下看到車的位置和APP上的位置有比較大的差異，就會失去信任感，流失到競品。
然而各地上報的GPS都有必定的延遲，且延遲有不可預知性，若是徹底依賴上報的位置數據呈現給用戶，在極端狀況下（如隧道等網絡很差的地方），可能會出現用戶真實看見了一輛車可是在APP上未出現的狀況。所以必須經過AI的方式對實際的位置進行估算才能給到用戶準確的信息展現。在這裏，源數據上報的時效性是位置預測時最大的困擾，以下圖一所示，對於不一樣的延遲時間，偏差和延遲的比例正相關。
圖一
延遲時間統計圖
另外，因爲各地上報GPS的規範性不一致。還須要處理一些邊界問題。如：GPS的延遲上報若是處理很差，在前兩站給用戶的傷害更爲明顯：車輛可能在已經駛過第二站後才上報了第一個GPS點，這意味着，若是咱們不對車輛的發出時間作預估，而徹底依賴上報的數據的話，第二站用戶看到的永遠是車輛等待發車。而在前兩站會比較容易出現的特殊狀況是：
場站線路
即車輛在到達上一方向的終點站後，會回到場站，停留一段時間後發出；循環線路
即車輛在到達上一方向的終點站後，直接駛向下一方向的起點。
咱們目前的解決方案是：
根據歷史數據，離線統計出車輛的上下行換向時間，即當車輛到達上行方向的終點站後，停留在場站（或繼續行駛）多長時間後會出如今下行方向的起點位置。
線上使用時，當收到車輛上行方向上報的最後一個GPS點後，對於場站線路，咱們會在換向時間事後判斷車輛從下行方向駛出；對於循環線路，會讓車輛從下行方向駛出的同時，繼續模擬前行。
使用/離線挖掘出車輛的發車時刻表。
隨着公交數據的不斷積累，咱們將在如下兩個方向持續深耕：
一方面，經過用戶使用公交服務的數據，進一步優化路徑規劃服務和實時公交服務，如：
結合用戶的歷史行爲，對用戶歷史行爲建模，實現個性化和場景化排序
使用深度時序模型優化實時位置補償，提高預測的準確率，強化對全國不一樣城市，各類不一樣地理特徵的泛化能力。
利用用戶軌跡補償實時公交信息和步行路網信息
另外一方面，能夠結合整個滴滴各類出行方式積累下的大數據，能夠賦能給傳統公共交通行業，優化線路選擇，智能排班調度等，真正助力智慧交通和智慧城市早日到來。
本文做者
▬
團隊招聘
▬
滴滴地圖與公交事業部信息公交團隊，依託滴滴海量出行數據和多種共享出行方式的優點，使用人工智能和大數據等技術，致力於爲用戶提供多模、高效、智能的公共出行解決方案。
團隊長期招聘研發工程師，包括C++/go引擎和業務開發、數據挖掘，機器學習等方向，歡迎有興趣的小夥伴加入，可投遞簡歷至 diditech@didiglobal.com，郵件請郵件主題請命名爲「姓名-應聘部門-應聘方向」。
掃描了解更多崗位
內容編輯 | Charlotte 聯繫咱們 | DiDiTech@didiglobal.com
本文分享自微信公衆號 - 滴滴技術（didi_tech）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。