哈囉順風車智能交易體系建設（下）
本次跟大家分享的是哈囉順風車智能交易體系建設。上篇，我們介紹了哈囉順風車的業務背景和智能應用中的訂單匹配。
算法應用
訂單匹配
首先介紹一下多任務模型，業務背景是我們要做發完單的預測，預測的越準，做排序的時候也就越準。但在做發完單預測的過程中，我們的數據量是相對有限的，之前講了因爲我們是一個漏斗，在發單到接單的過程當中，會產生大量的數據，這部分數據實際上是丟失的。如果能夠把這部分數據用上的話，對提高我們模型的性能會有幫助。所以我們根據這個情況，設計了一個雙塔結構的模型，我們把發單和接單模型訓練成了單獨的模型，相當於是一個輔助的任務和主任務拼接在一起進行訓練。這樣訓練後的模型，就能夠利用更多的數據，當然過程中我們也設計了一些定製化的損失函數。通過這樣的方法訓練下來，我們給這個模型起了個名字叫 WDMM 模型，它比 Wide&Deep 模型效率提升了 2.65%。
接下來介紹一下實時序列模型，我們對司機的行爲模式進行識別，司機基本可以分爲職業司機和非職業司機，但實際上司機還有很多不同的狀態，所以我們對司機在地圖上的各種活動，把他的行爲序列做了向量化。我們使用 Attention 的交互去做，把它映射成了一個向量，然後把這個向量和其他的特徵拼接起來，再放到模型裏面去，這樣就能夠更好的去體現司機的行爲模式。最後我們去跟 Wide&Deep 模型比較，可以看到效率提升了 3%。
接下來介紹一下策略優化，是順路度的改造。在我們的推薦列表上是有一些順路度的，它直接顯示在上面，會對司機的接單決策產生影響。起初的順路度是地理上的順路度，可以看到左邊的圖是某競品 APP 的順路度，順路度顯示的都是一樣的，這樣就不能引導點擊推薦列表上最高位的那一個，而推薦列表上最高的那一位纔是完單概率最高的。所以根據這個情況，我們就對物理的順路度進行了一些改造，融入了更多與完單概率類似的一些因子，比如時間是否匹配，接駕的起點終點是否匹配，以及把共享里程與繞路度都加進去了。做完了之後，我們可以看到順路度的邏輯基本上與推薦列表的邏輯是一致的，這樣能提升司機的決策信心，大盤的增幅超過了 5%。
接下來介紹一下召回，剛纔也提到了跟其他廣告系統去比較的話，我們召回的特點首先是實時性，就是我們需要實時計算路徑等信息。第二個特點是同質性，與視頻網站可以給用戶推薦不同性質的視頻不同的是，我們的系統推的基本上是訂單，類型並不會有太大的差別。第三是平均數量適中，數量差異大。
召回是推薦的底盤，所以我們會根據找到的問題，制定不同的應對方法。第一點是由於我們是實時計算的，所以不可能做向量化。第二點是我們可以按照地理分佈、時間分佈等策略方式進行召回。第三點是範圍可以適度進行擴大，此外不同的城市會進行不同策略的召回。
總體來說召回就是儘量多的把想要召回的召回，如果召回太多，性能又會受不了，所以我們需要去預判什麼樣的情況性能還能承受。在我們做了一些召回策略上的調試之後，大盤會有 2% 左右的提升。
最後是我們訂單匹配的工程方案，我們要實現這樣的方案還需要依賴一些工程能力。之前提到我們時間的要求非常高，這裏依賴了搜索引擎的算法插件系統和高性能 Rank Service 系統，此外還要依賴司乘同顯服務的能力。由算法和工程的一些底層能力，共同構成了這樣的一套方案，能夠幫助我們完成訂單匹配的工作。
營銷和定價
我們的定價方式有基礎定價、城市差異定價、感知競對變化，最終我們希望能夠做到智能定價。現在我們基本還在第二個階段，也就是城市差異定價。影響的因素首先是供需，可以看到價格不斷提高的話，我的需求就會降低，供給就會增加。我們進行不合理的定價和最合理的定價，產生的業務量是不一樣的。另外一個因素是競爭，我們的競爭對手給市場定下的價值，也會培養市場上司機和乘客的認識，對我們也是有影響的。此外時間地點對我們也是有影響的。
定價完了之後，我們把定價和營銷放在一起來說，營銷實際上也是做了定價的工作。我們可以看到上圖，我們補貼了一些金額讓需求曲線往上移動。在給乘客進行補貼的時候，我們獲得了業務量的增加。具體到一次營銷活動，我們可以看到算法策略的價值比運營策略的價值高一些，也就是我們營銷所帶來的增量的價值，這就是我們的背景。
接下來介紹一下智能定價，這裏的智能定價實際上也是一種營銷。我們並沒有同時對兩邊進行調整，而會把當中的差額自己提供補貼給用戶，所以它也是一種營銷。實際上這是在打車業務裏去做的，跟順風車類似，我們希望在業務的場景裏去保持每個區域裏面的供需的比例基本一致。所以我們會去發現供需失衡的場景，然後再圈選哪些人需要進行補貼，並對他進行個性化的補貼。可以看到在這種情況下，算法是做了差異化的策略，如果沒有做差異化的策略，它的錢效就會低 30%，這也是我們的算法帶來的增量。
接下來是智能營銷的應用，其實它就是要維護我們司乘全生命週期的過程，儘量多的讓更多的司機和乘客在我們的系統裏，我們有拉新、促活、防流失、流失挽回這樣的過程。對於新司機如何挖掘，如果新司機註冊了想要激活，那就有新車主的獎勵金。如果你已經變成新車主了，我們有司機多單任務，提升司機在平臺的完成任務的數量。如果他要流失了，我們會進行返現，或者對他做一些流失召回。對於乘客也是類似的，在他的生命週期中進行一些觸達以維護乘客。
最後是我們的智能營銷方案，主要用到了 response 模型、uplift 模型和運籌優化。我們要做的事情就是決定在什麼時間，對哪些人做什麼樣的營銷活動，並且要滿足我們預算的要求。目前我們的營銷效率相對於運營來說，整體提升的效率在 20% 左右。
智能仲裁
智能仲裁我們目前並沒有大規模的使用，但模型實際上已經上線。在業務中，我們的用戶會發生一些投訴的情況，當投訴產生的時候，他就會把 Request 發到我們智能判責的引擎裏面。智能判責引擎是根據歷史情緒反饋的正負樣本去進行建模的，就是以往發生了投訴之後，我們判責的案例就會作爲正負樣本，到底是司機有責還是乘客有責，我們會把路上的一些軌跡信息、錄音的信息、用戶和司機歷史的情況，各種各樣的行爲都作爲特徵放到這個模型裏面進行訓練，構建出了這樣的一套模型，會自動對一些比較明顯的案例進行判罰，如果是非常不確定的話，就會給到客服那邊。
接下來介紹一下智能仲裁的典型場景，比如我們判責的應用有車主催車費判責，是因爲我們車主有很多已經到了終點，但是乘客沒有點擊界面上的已經到達終點。這個時候我們以往的做法就是要隔很長的時間，纔會把款打給車主，會引發車主的情緒。這種情況發生，我們可以根據軌跡的信息進行判責，看是否他已經把乘客送到終點，已經有的話就可以把錢款儘早打給司機，這樣就可以減少投訴率。類似的也有司機遲到判責等。
這類問題都存在一些共性的問題，比如打標數據難以獲得、效果難以驗證、和主要業務目標衝突。比如說進行處罰之後，他可能就不能完單，這對業務會有負面作用。如何去平衡用戶體驗和業務增長的目標，需要多與業務和產品進行討論。
方法總結
算法項目的推進方式
首先要更合理的定義問題，就是我們要預測的是什麼，我們的業務目標是什麼。這裏有一個例子，比如我們要去提升大盤完單完單率，但如果接完率有提高，發完率有降低，這種情況下它有很多的中間指標，有可能最終的指標是沒有提升的，但是中間指標有提升，我們怎麼樣去發現更多的有意義的價值，能夠從裏面提煉出來，這也是非常重要的。
定義好問題之後，接下來是更合理的利用數據。這裏需要 domian、expert 輸入，就是業務同學的很多經驗對我們是有用的，比如剛纔提到的職業司機和非職業司機，實際上也是來源於我們業務的經驗，他會對我們的司機羣體的特性有一些判斷，這些都能夠幫助我們去構建構建一些特徵和數據。
第三步是選擇更合適的模型和策略。基本上對於我們的模型來說，減少了偏差和方差這兩種錯誤。我們的模型要選樹模型、深度模型、多任務模型等就會相對獨立一點。但是前面兩步如果我們做的不好，即使後面做的再好，算法也會出現一些問題。
MLOps 實踐
MLOps 就是我們整個訓練中怎麼流程化、複用、可重現，部署上怎麼進行模型管理、註冊、上線，運維上我們怎麼樣能夠追蹤過程中的指標，比如說用戶數、延遲，以及我們怎麼樣能夠告警，比如說線上業務有模型、數據的漂移，怎麼樣能夠及時發現。還有自動化，指的是我們的模型怎麼樣能夠根據不同的情況，閾值有不同的變化。
這裏有一篇 2015 年的論文，講的是機器學習系統裏面一些隱形的技術棧，機器學習的 code 實際上只是整個機器學習解決方案 code 裏面很小的一塊，在我們周圍實際上還有大量的代碼，比如說數據怎麼樣收集、特徵怎麼樣提取、數據怎麼校驗、機器資源怎麼監控，怎麼樣去分析、流程怎麼管理、上線之後底層的服務怎麼樣去監管，以及整個服務的運行狀態怎麼樣去監控，這些在以前並沒有系統地去進行管理，但實際上我們整個模型上線之後，它出現了種種問題，最終都會反饋到我們這裏來。
所以這也迫使我們必須做好這些事情。拿告警來說，我們以前可能沒有注意到會產生一些問題，比如說做營銷的時候，補貼可能很快就發完了。我們也不知道出現了什麼樣的問題，可能就是上游的數據一個字段沒有傳過來，這就說明數據發生了一些漂移。後來我們就加了一些監控，就看我們模型每天數據的 auc 是否有大幅的波動，如果有大幅的波動就說明可能數據有了問題，或者模型有了問題。模型漂移的問題就說明我們用戶的羣體可能不一樣了，用戶的行爲模式就會不一樣，所以我們這個模型也需要自動地去更新，自動地去對抗市場的變化。這些基本上在我們的訂單匹配系統裏都做到了，我們的模型每個星期都會自動去進行訓練，會和最新訓練的數據去進行驗證，auc 進行比較，更好的模型纔會自動上線。
最後總結一下，本次分享首先是對順風車業務進行介紹，包括訂單匹配、營銷定價和仲裁。並且根據這幾個方向做了幾個應用，包括智能訂單匹配、智能營銷定價和智能仲裁。最後介紹了兩個經驗，包括項目推動的方式和 MLOps 實踐經驗。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/BGZt3S-Jc3r31YMmJ4sbFA