滴滴治理算法探索與實踐

桔妹導讀：13年以後，以外賣、網約車、房產銷售爲主的O2O平臺，極大的改變了社會的運行模式。相比前一代互聯網公司，這一代互聯網公司都面臨着人與人的線下交互，因此在體驗、治理上也帶來了新的挑戰。在滴滴，經過多年的耕耘，我們探索了一套功能強大的治理算法系統，圍繞司乘體驗提升的核心目標進行了全方位的探索和落地。

1. 

業務背景介紹

治理要解決的問題，是降低和解決因平臺原因、司乘預期原因、司乘個人問題所帶來的各種行程 糾紛，包括但不限於取消糾紛、費用異常、服務問題等。整體的解決方案如下：

其中，按照治理對象，分成訂單維度治理、人維度治理。

• 訂單維度治理，主要指在訂單全生命週期中，在異常發生前、發生初、發生時、發生後，平臺的治理行爲。
  

• 人維度治理，指在司機、乘客在平臺的全生命週期中的綜合治理行爲，主要的抓手是司機服務分、教育、管控的一整套方案。
  

考慮到體驗異常相關因素較多，相對比較高頻，訂單維度治理的應用相對更廣，挑戰也更大。本文討論的治理算法主要針對該部分。

2. 

治理算法挑戰

治理算法，作爲O2O背景下新的算法方向，有如下的挑戰。

首先，在業務上的複雜性很高。 如第一章所示，在訂單的全生命週期中、多個策略節點都需要算法能力建設； 另外，在滴滴的業務場景中，涉及到十個左右的品類，數十個業務場景，極端情況下需要維護近百個模型。

另外，在技術上也有很大的挑戰：

第一個挑戰是高質量樣本少。 場景、品類、策略節點多，即使在當前有一定的標註人力的情況下，在每個場景的高質量樣本都很有限。 另外，如何將標註數據，跟線上人工判責的數據進行有效融合，也是很大的挑戰。

第二個挑戰是可解釋性要求高。 因爲判責結果直接跟司乘體驗相關，所以對可解釋性有很強的訴求。 但是機器學習模型本質上是相關性的學習，大量弱特徵的引入在提升模型效果的同時，就會削弱可解釋性。 如何在效果和司乘感知上做平衡，需要持續思考。

第三個挑戰則是多模態特徵。通過完備的場景還原能力來做干預、判責等，需要用到訂單、時空、司乘統計特徵之外，也要參考司乘的溝通信息（比如司乘是否指路）、協商投訴文本（各自的表述）、以及桔視特徵（比如多人分段上下車等）。是否能高效、綜合的利用更多的多媒體信息，對工程、算法而言都是巨大的挑戰。

3. 

治理算法框架

宏觀上看，以司乘費用糾紛處理爲例，治理算法框架如下：

業務層：爲了解決在訂單生命週期中可能會出現的行程糾紛，提升服務體驗。依託策略模型能力，設計了一系列的產品解決方案。從訂單治理維度看主要包括以下三部分：

• 糾紛發生前與發生初的降發生方案，比如當司機提前計費時，觸發實時干預等；

• 糾紛發生時的智能受理方案，如在司機賬單發送時刻，平臺精準識別未坐車收費問題訂單，智能觸發司乘協商流程，能幫助乘客主動解決糾紛問題；

• 糾紛發生後的管控判責和補償方案。通過建設智能判責能力，能落地如服務分扣除、補款、罰款等方案，對糾紛問題做合理的調解與治理。
  

系統層：爲了支持多品類、多場景的治理業務，系統上的沉澱如下：

• 成熟的在線服務引擎。其中策略流程引擎有效支持了策略流程的可視化配置管理；模型引擎有效支持了LR、XGB、DNN等一系列模型的在線部署與預測服務；規則引擎通過在線解析基於DSL的規則描述語言，有效降低了策略規則的迭代成本。
  

• 策略基礎能力庫。沉澱了一套字、詞、句等多粒度的文本算法工具箱，拓展了治理算法的技術空間與業務價值。同時建設了離線策略數據倉庫，實現業務數據、鏈路數據、策略數據的體系化治理與整合。爲業務落地與策略迭代提供了高質量、高可用的數據。

• 在線與離線相結合的標註工作臺，承載了滴滴治理算法的標註需求。策略RD離 線灌入抽樣樣本，質檢標註團隊在線標註做單，保障了模型樣本的大規模與高質量產出。通過T+1模型更新系統，引入模型自動化更新機制，解決了在線模型的效果衰退問題。

  
  

本文的餘下部分，將重點介紹上圖的模型層、特徵層部分。 其中第四章重點介紹模型層，介紹我們在樣本、模型上做的探索； 第五章重點介紹特徵層，我們在多模態的特徵、流式特徵上的思考。‍‍‍‍‍‍‍‍‍‍‍‍

4. 

模型探索

在模型上，我們貼合業務場景與產品方案，圍繞治理鏈路節點構建了大體量的業務模型，體系化地搭建起平臺對異常訂單的場景還原與識別能力。同時，進一步深耕模型算法技術，通過先進性的模型技術攻堅，推進工業界的模型技術應用與落地。比較典型的有：通過小樣本學習技術，在較短時間週期內獲取充足高質量標註樣本；使用多任務學習技術，實現業務上相關監督信息的充分融合利用；元能力建模方案，將對目標(判責結果)建模的方式，轉換成對過程(判責元能力)建模的方式，提升了機器模型的可解釋性。

▍ 4.1 小樣本學習

在治理領域的很多場景，都會遇到高質量標註樣本少的問題。全部人工標註的話，又會伴隨着標註週期長與人力成本高的問題。比如在費用判責模型構建中，精準的人工判責樣本非常稀缺，且很容易隨着sop的變化而失效。所以在一定的時間窗口中，高效的利用樣本，成爲業務的一大挑戰。

 

在學術界，小樣本學習的常用方案主要有以下幾類。

在治理場景中，我們主要使用瞭如下的幾種方法。

方法一： 在樣本利用的探索上，我們基於自學習算法，在有限高質量樣本量的約束下，最大化提升了模型的效果。

算法流程如下圖所示：

• step1 用已有的標籤數據作爲初始訓練集，訓練得到一個初始分類器模型；

  
  

• step2 利用初始分類器模型，對剩下的還未標記的數據打標籤，選出高置信度的樣本加入已有標籤數據集中，從而擴充訓練樣本集；

• step3 根據新的訓練樣本集訓練新的分類器。重複step1~step2直到滿足預設停止條件(如樣本量達到預期量級等)

一般情況下，司乘判責模型的單次迭代需要5k~1w的專家標註樣本，這些樣本的獲取是昂貴且長週期的。通過自學習算法，樣本量被擴充後，模型的AUC提升了0.4pp，相同準確率下召回也提升了2pp。

未來工作展望上，我們會進一步嘗試引入自學習與主動學習相結合的標註方案，更爲高效的使用判責專家提供的標註數據和標註能力。

方法二： 滴滴網約車業務包括快車、拼車、優享、專車、企業級等多品類業務線。因爲快車單量大，樣本充足，模型算法的一期落地主要是快車品類。多品類業務線的模型接入就給遷移學習方案的落地提供了較爲充分的空間。

遷移學習主要解決的問題是： 數據採集成本和標註成本高，較短時間週期內大規模數據集的建構比較困難。遷移學習不要求訓練集和測試集數據必須是獨立同分布的，可以降低對目標域內的訓練數據量和訓練時間的需求。 當前主要的技術落地算法是基於模型的遷移。即基於快車品類訓練的模型，快速fine-tuning在其他多品類應用場景中。

方法三： 模型視角的小樣本學習探索，主要是多任務學習在治理算法場景的落地，這部分會在4.2章節詳細闡述。

▍4.2 多任務學習

近兩年工業界關於多任務學習模型的應用和工作，主要落地在推薦場景，如廣告曝光到點擊到轉化過程中的CTR預估任務和CVR預估任務。當前比較先進的模型結構有ESMM、ESM2、MMOE等。對比業界的多任務學習落地方案和治理算法的應用場景，治理算法上也有多任務學習較爲成功的落地。

從上圖可以看出，廣告的曝光->點擊->轉化流程與滴滴平臺的大盤訂單->投訴->有責的訂單狀態流轉，恰恰都符合貝葉斯公式。都可以通過多任務之間的關係來建模出新的損失函數並適配新的模型結構設計。

 

繞路攔截模型結構：

如上圖所示，以費用糾紛治理場景的繞路攔截模型爲例，具體介紹一下我們多任務模型的優化點。

• 優化點1：採用ESMM結構。ESMM模型結構恰好適配於攔截的業務場景。該優化點一定程度上解決樣本偏差問題；實現MTL結構。
• 優化點2： 連續特徵離散化，離散特徵embedding。該優化點從數據特徵工程層面優化，來提升模型的性能。特徵離散化有利於NN模型的迭代和性能的提升，通過卡方分箱將訂單特徵中的連續形特徵離散化；同時將原始的離散特徵與分箱後的離散特徵進行多特徵域的embedding
  

• 優化點3：多模型融合，融合行程中錄音ASR特徵的指路語義特徵。該優化點加入場景強特徵，進一步提升模型效果。具體操作方法是：行程中錄音能夠有效地識別指路等行爲，將ASR文本特徵訓練的指路模型的中間向量輸出作爲繞路攔截模型的輸入。

‍‍‍‍‍‍‍‍‍‍‍‍‍‍實驗結果證明，多任務學習的方式能夠有效地學習到投訴任務的特點，更好地輔助有責任務的學習，效果遠優於單任務的模型。通過輔助任務的引入緩解了標註樣本較少的問題，在策略生效點ESMM新模型的召回提升較爲顯著：相比線上的xgb模型，準確率提升0.6pp，召回率顯著提升4.2pp；相比硬共享的多任務學習準確率提升0.2pp，召回率提升1.1pp。後續的A/B實驗中取得了不錯的線上業務效果。

未來工作展望上，我們會繼續引入ESM2的結構，基於產品流程建模，進一步優化線上多任務學習模型的效果。

▍4.3 建模目標的演進

治理業務對機器判責能力一直有可解釋性的訴求。 所以機器學習可解釋性的技術探索是相對比較重要的一環。 然而當前業界對於可解釋性的一些嘗試還處於比較初期的階段，較難在工業界落地。

爲了彌補這個問題，當前主要考慮的有兩種解法： 一是考慮規則，結合LIME、SHAP之類的可解釋性框架，引入一部分可解釋性； 二是將對目標 ( 判責結果 ) 建模的方式，轉換成對過程 ( 判責元能力 ) 建模的方式。 因爲後者更符合業務的訴求，當前 治理算法 主要在嘗試後者。 將建模目標從判責結果，演進拆分爲判責過程中的判責元能力構建，進一步推理出判責根因與判責結果，具體的落地方案如下圖所示。

通過以上對判責內在邏輯的拆解： 原始特徵->判責特徵（即判責元能力）->根因->結果有無責，完成了對判責元能力的建模，進一步構建了判責能力的可解釋性。

5. 

特徵探索

治理業務對機器模型的一個較強訴求是場景還原能力，本質上，無論是糾紛干預、還是糾紛判責，都是通過完備特徵的引入，來提升場景還原能力，從而進行訂單的決策。 在特徵的引入上，我們經歷了三個階段：

‍‍‍ ▍5.1 初始階段

在方向前期，相對基建能力不完備，引入的特徵主要是三個維度： 業務基礎特徵 、時空特徵、 司乘統計特徵等。 其中前面兩個部分是跟訂單的業務流相關聯的，大約300維，主要包含訂單基本信息、時間/位置/距離、導航類、溝通交流類等。 司乘統計特徵大約1000維，我們建設了司乘各一個大寬表，包含司乘在完單、評價、習慣等全維度的統計特徵，以及公司特徵平臺獲取到的基礎統計特徵。

取消業務特徵

費用業務特徵

▍5.2 多模態特徵大規模應用

在滴滴平臺上，滴滴智能安全車載設備桔視已經覆蓋超過50%的網約車訂單，另外每個司機的手機都在進行全程的行程中錄音，再配合全流程的軌跡信息，整體在場景還原上提供了非常豐富的多媒體能力。而多模態特徵的應用，有通過端到端的框架聯合訓練、以及通過設計兩階段模型來應用的兩種方案。

多模態特徵表

▍ 5.3 流式特徵探索

 

在特徵形態上，我們基於線上的流式數據，如行程中的軌跡流、錄音流、視頻流等數據做了一些流式語義特徵的挖掘。這裏主要介紹軌跡流相關的技術方案。

 

軌跡信息的提取和利用對於糾紛治理業務有較大的價值，而目前對於軌跡信息的處理侷限於提取距離差、速度等簡單特徵，信息損失大，故需探索軌跡的價值。

 

技術選型主要分爲兩大類：無監督(自監督)的表示學習方案和有監督的子網絡嵌入方式。我們的實驗探索主要基於後者展開。

有監督的子網絡嵌入方案的建模流程如下。序列模型部分，我們主要嘗試了主流的LSTM模型，整體模型AUC效果上：Bi-LSTM > Vanilla-LSTM > Stacked-LSTM。

6. 

總結

治理算法是一個全新的領域，是隨着O2O平臺興起以來，在線上線下治理、管控需求下新起的一個策略算法方向。在過去的幾年，團隊在NPS、CPO等公司核心關注的體驗指標上，都取得了很好的業務收益；在技術體系上也有了相對深入的積累。

 

隨着桔視的鋪裝，以及社會、公衆對網約車平臺服務的期待，在司乘體驗提升上也還有非常大的持續優化的空間，在樣本、模型、特徵等領域仍然有巨大的挑戰，我們團隊也將在這些方向上持續探索。

團隊招聘

▬

滴滴網約車技術 · 治理與安全團隊隸屬於滴滴網約車公司，致力於構建滴滴的安全體驗和服務糾紛治理體系，通過建設行程中安全預防技術體系、糾紛問題受理平臺、B端治理工作臺、治理中臺服務、治理架構體系等賦能滴滴安全和糾紛治理業務，建立可持續健康發展的出行生態。在這裏你將有機會創造“世界級”技術價值，與滴滴共同成長，加入我們，用技術的力量一起解決出行中的不美好。

團隊目前熱招高級Java工程師、go後端研發工程師等技術崗位中，歡迎有興趣的小夥伴加入，可投遞簡歷至 [email protected]，郵件請郵件主題請命名爲「姓名-投遞崗位-投遞團隊」。

掃碼瞭解更多崗位

作者

▬

延伸閱讀

▬

     
     
     

 
      
      
      


 
      
      
      

  
       
       
       內容編輯 | Hokka
 
      
      
      
 
      
      
      

  
       
       
       聯繫我們 | [email protected]
 
      
      
      
 
      
      
      

  
       
       
       

 
      
      
      
 
      
      
      

  
       
       
       
 
      
      
      

     
     
     

本文分享自微信公衆號 - 滴滴技術（didi_tech）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。