算法在哈囉順風車中的實踐應用

01 業務介紹

首先介紹下哈囉的算法平臺基礎建設,給算法同學在業務中落地算法提供了有力的保障。

  1. 平臺基建

公司的機器學習平臺是基於機器學習和深度學習計算框架進行二次開發,提供一站式的服務,爲算法同學提供從數據預處理、模型訓練、模型評估、模型在線預測的全流程開發和部署支持。爲算法同學提供端到端的一站式服務,幫助我們脫離繁瑣的工程化開發,把有限的精力聚焦於算法策略的迭代上面。

其實最開始的時候,我們的特徵和模型是跟業務強耦合的,導致每次模型迭代,服務端都要搞發佈,迭代效率很低。所以後面我們就把特徵和模型全部剝離出來,放到機器學習平臺去。

有了機器學習平臺的一站式解決方案,算法同學可以方便快速的進行順風車業務算法的落地。下面介紹一下,順風車業務算法的構成。

  1. 順風車業務

從我們平臺的二輪用戶轉化或者廣告外投的渠道通過智能營銷算法拉新過來的車主在平臺發佈訂單後,通過我們的匹配推薦系統進行乘客訂單的推薦,然後車主接單後進入行程中,我們會有交易生態治理算法來爲司乘的體驗與安全保駕護航。

所以整個交易鏈路,涉及 3 塊算法,第一塊是匹配推薦引擎,第二塊是交易生態治理算法,第三塊是智能營銷算法。

首先介紹一下我們的匹配推薦引擎。

02 匹配推薦引擎

此模塊主要分 3 個部分來講,從架構到召回模塊演進到精排模塊演進。

  1. 架構

匹配推薦引擎的目標是最大化交易效率的同時能夠兼顧長期留存。

我們首先介紹一下推薦引擎的架構。從數據層來講,數據來自於 3 個方面,一個是客戶端傳下來的實時上下文數據,比如乘客訂單的價格、起點距離等上下文特徵。一個是 flink 任務計算的準實時數據,比如同一筆乘客訂單被多少司機看到,所有這些看到的司機中跟這個乘客訂單的平均順路度,起點距離等。一個是離線計算的寬表特徵,比如對於車主接單行爲的畫像特徵。

從數據層到模型匹配層,模型層主要分爲召回層、粗排、精排、重排 4 個階段。

從模型層到業務層,針對每個子場景都定製一套自己的模型,我們的順風車從 2 個大場景來說,分爲車主側和乘客側;而車主側又分爲臨時行程、常用路線、附近找單、跨城找單等接單渠道。

接下來主要講一下召回模塊和精排模塊的演進。

  1. 召回模塊

召回模塊面臨 4 個挑戰:

第 1 個挑戰是需要實時計算的邏輯太多,非常耗時。我們是基於位置的服務,當車主發單後,需要外擴經緯度形成矩形框後,在矩形框內進行路徑規劃、順路度等計算邏輯,這些都是需要實時計算的。特別是當跨城訂單里程很長的時候,軌跡點特別多,耗時更加嚴重。

針對這個問題,我們的一個解法是添加了軌跡壓縮算法,軌跡壓縮率達到 80%,一定程度上降低了計算的壓力。

第 2 個挑戰是訂單有且只出現一次,離線無法直接建模,生產 embeding。

電商的召回模型統統失效了,因爲訂單是曇花一現的,沒法在車主完單序列中反覆出現。所以必須想一種辦法,來對問題進行轉化。我們的解法是通過一定編碼轉化後通過圖召回來解決,具體細節後面會講。

第 3 個挑戰是用戶決策單一,車主總是希望離它近,價格高,更順路,出發時間匹配的訂單進行決策。我們的解法是在召回側就將這些核心要素抽取出來作爲召回鏈路的補充

第 4 個挑戰是順風車低頻用戶比較多。對於個人來說,低頻,但是對於一個網格里面的車主來說,就會變得不低頻。所以我們解法是挖掘歷史目的地進行網格召回。

下面着重講一下,我們是怎麼轉化數據來做圖召回的。

圖召回:

首先是對重要特徵離散化之後,對每一筆訂單進行編碼。這種編碼的好處是近似訂單基本等價於一個編碼,就類似於電商中的一個商品了。那此時就可以使用電商裏面的 embeding 算法了。

編碼完成後對車主歷史完單序列映射到具體編碼。

然後通過 node2vec 來生成同質性的圖結構,轉移概率的公式直接用的論文的,只不過這裏有個比較巧的方式是,爲了生成同質性的圖結構,此時遠離參數 q 要設置一個比較小的值來使得遊走的網絡結構具有同質性。

生成好的編碼序列,可以使用 skip-gram 的方式來訓練,同時通過負採樣來加速模型的訓練速度。

  1. 精排模塊

下面講一下精排模型的迭代思路:

最開始業務冷啓動上線時,直接按照順路度排序。算法 1.0 是採用邏輯迴歸上線,AB 實驗接單量提升 6%,效果不錯。算法 2.0 部分場景使用 pointwise 框架用 lightgbm + LR 算法,接單量相比 1.0 進一步提升 5%;部分場景使用 listwise 框架通過將文檔排序的思想遷移過來,比如點擊得 1 分,接單得 2 分,完單得 3 分,採用 lambdaRank 模型排序,接單量相比 1.0 提升 10%。此後我們開始探索深度模型,嘗試了電商的精排模型,比如 deepfm,xdeepfm,DIN,DIEN 等,離線驗證 auc 並沒有 2.0 版本效果好。

我們開始分析爲何電商模型在出行行業並沒有好的表現:電商場景億級別的離散稀疏特徵,順風車場景則連續特徵居多。所以,關鍵點在於電商的離散特徵很多,embedding 技術能發現更多特徵的隱式交叉。而在順風車場景,連續特徵非常多,如果我們能找到一種方式把連續特徵轉化爲離散特徵,那特徵交叉會更有效。

所以我們的算法 3.0 是這樣一個模型:

其實這裏面的深度模型結構可以替換成已經成熟的各種深度模型,核心邏輯是如何處理連續特徵,有利於深度模型進行更有效的特徵交叉。因爲如果一個連續特徵只佔一個 bit 位,在神經網絡的特徵交叉中不能充分被表達。

這幅圖是當時離線測試的結果,可以看到自研模型的離線 auc 有 2 個點的百分位提升。

03 交易生態治理算法

交易生態模塊,目標是保證車主在行程前、行程中、行程後的履約體驗和行程安全。此模塊包含 4 個部分,交易鏈路、架構,模型演進和場景舉例。

  1. 鏈路

在行程前我們會預測一筆交易發生取消、投訴、或者惡性事件的概率來做匹配干預,差司機和挑剔乘客避免碰到一起引起不舒服的體驗。同時在行程前我們會根據歷史數據預測車主或者乘客可能會有哪種不好的行爲比如線下交易,繞路接人等,在接單前對疑似用戶進行教育與引導。

在行程後,我們通過判責算法來保證司乘的合法權益。

  1. 架構

在交易生態治理算法的特徵一部分來自於基礎特徵,包括時空特徵(比如訂單座標,時間等)、訂單特徵(是否拼單,乘客數目,是否同跨城等)、以及離線的司乘行爲特徵。另外一部分來自於實時特徵,比如實時的軌跡流、IM 聊天信息、通話等。

而樣本是我們比較頭痛的一部分,樣本需要人工打標,耗費人力。我們這邊是通過大衆評審和後臺投訴樣本來獲取一些用戶標記給我們的正樣本。

有了特徵和樣本後,我們可以離線訓練模型。這個模型也是在行程前、行程中、行程後根據不同的場景進行定製化開發。然後將模型通過機器學習平臺部署和發佈到線上去,來讓算法服務於每個環節的履約體驗。

交易生態的治理算法中,因爲正樣本非常珍貴,所以我們這邊的模型演進也面臨着一些挑戰:

  1. 模型演進

首先第一個挑戰是,順風車線下行爲難以在平臺蒐集到,比如軌跡流的獲取,乘客一般上車後就不再打開 app, 導致軌跡不能上報。那就需要針對不同的場景進行在合適的節點觸發引導與宣傳。

第二個挑戰是,沒有標記樣本。這邊通過 3 種方式來解決,第一是客服工單人工處理的樣本作爲標記樣本;第二是大衆評審,就是 app 界面發送問題,讓用戶來打標回答。第三個是通過小樣本學習的方式來擴充前兩個手段的樣本量。比如對於使用模型預測概率比較高的樣本可直接填充爲正樣本,來增加正樣本數量。

第三個挑戰是:特徵的來源比較多,有軌跡流,有 IM 聊天信息,語音等。這裏我們通過多模態特徵融合來解決這個問題。

對於同一任務,能夠應用多種模態的數據,可以做出更魯棒的預測並且模態之間可能會存在互補的信息。我們當前的融合還處於比較早期的方法,是在提取了各模態的特徵後,進行融合,利用了每個模態低水平特徵之間的相關性和相互作用,使用單一模型進行訓練,上線複雜性和性能都可控。

第四個挑戰是:算法需要較強的可解釋性,增加說服力。因爲我們這邊很多後臺的計算邏輯需要透傳給用戶,引導用戶朝着好的方向去走。所以算法的輸出需要很強的可解釋性,不然沒法引導用戶的具體行爲。我們通過模型來提煉出一些規則,我們這邊是規則打底,同時結合可解釋框架 SHAP 來分析每個特徵對結果的貢獻。

下面我們看一個軌跡偏航算法的迭代過程,來了解交易生態的模型迭代:

  1. 具體場景軌跡偏航

順風車行程過程中對可能出現異常的行程進行提前預警,這裏面面臨的挑戰:

v1 版本我們通過計算路線規劃內,乘客與車主上報的軌跡批次中,當前批次與上一個批次,方向夾角,距離等的變化,計算一個偏航得分,通過這種方式上線後,在 app 端內開一定的小流量當處於偏航預警時,push 用戶給一個反饋。這樣我們就有了一定的樣本積累,方便後續的模型迭代。

v2 版本我們通過將 v1 版本的用戶打標樣本和客服工單處理的偏航樣本作爲正樣本,通過 lightgbm 進行小樣本學習。

v3 版本在前兩個版本的積累下,可以開更多的流量通過大衆評審用戶打標有更多的樣本後,進入深度模型的訓練。

在模型迭代上,我們下一步的思路是將多目標訓練融合進來,比如將是否偏航和是否產生工單一起訓練,提升模型的準確率與召回率。

下面講最後一個模塊,智能營銷:

04 智能營銷

這一部分主要包含 4 個部分,營銷的架構,用戶運營的生命週期,模型的演進,uplift 模型。

  1. 架構

從數據層來說,營銷用到的數據主要是用戶的基礎畫像數據,用戶的行爲特徵,以及最近在我們平臺的瀏覽點擊行爲特徵。通過這些特徵,我們離線訓練機器學習或者深度模型後進而在線部署模型。然後通過 CRM 平臺給不同的用戶發放不同的權益。

  1. 用戶運營週期

對於平臺的用戶來說,一般都會經歷拉新,促活,防流失,召回挽留等階段。對於每個階段來說,我們希望有對應的營銷算法和觸達手段來激發用戶在平臺的活躍度與忠誠度,同時也能提升公司的錢效,用好每一筆錢。

這裏面涉及 3 個問題,第 1 個問題是:給什麼樣的人發券,即圈人階段;第 2 個問題是:圈的人給什麼樣的權益,比如是 5 塊錢還是 10 塊錢;第 3 個問題是:通過什麼樣的文案來觸達用戶,這裏面就涉及智能文案的問題。

接下來主要講一下前兩個問題的解法。因爲智能文案是專門有一個團隊做成平臺化來提供給整個公司的業務線來使用。

  1. uplift 模型

我們最開始的 v1 版本是從 response model 開始。去預測用戶的出行概率,然後根據出行概率來制定不同的發券策略。這裏面會出現自然轉化的用戶也發放了優惠券,導致錢效不高。

其實對於用戶來說,主要分爲 4 大類,第一類是營銷敏感的人羣,這類人是下單猶豫不決,需要券來刺激一把。第二類是自然轉化的用戶,不管發沒發券,這個人第二天都是有出行需要的。第三類是無動於衷,發不發券都沒反應,第 4 類是發券可能會起反作用,比如券可能是站內 push 的方式來發送,用戶可能覺得太煩了,直接 app 關閉推送功能。這 4 類人中我們要抓住的就是第一類人,營銷活動的重點人羣。

所以 v2 版本,我們通過 v1 版本發券積累的數據,來嘗試了 uplift 增益模型,對發券和不發券對用戶帶來的增量進行建模,然後根據這個增量來實施發券策略。

這裏面有個缺點是,發券的金額仍然沒有做到用模型 cover 住,錢效仍然不是很高。

所以 v3 版本,我們通過預測不同券的核銷概率,與使用不同券的增益值,來通過運籌優化的問題解決券金額髮放千人千面的問題。

比如 xij 代表第 i 個用戶是否發放第 j 種券,那約束條件是:每個用戶至多發一種劵,以及所有用戶的發券總和不能超過實際預算,優化目標可以是所有用戶的增益值最大,也可以是 gmv 最大或者 roi 最大等

運籌優化的求解主要是整數規劃,整數規劃目前採用谷歌的 ortools 來求解。但是優化器當求解參數上千萬時,性能就出問題了,要算十個小時左右,這是不能接受的。目前的解決方案是分而治之,通過分城市來求解優化器,因爲每個城市間的用戶相對來說是相互獨立的,互不干擾。

接下來我們主要講一下 uplift 模型的 3 種範式。

首先 S-Learner 就是 single-learner,把對照組和實驗組放在一起建模,只是把干預相關的特徵作爲特徵加到模型中去訓練,本質還是對 response 進行擬合,所以對於因果效應並沒有很好地學到。

而 T-Learner 就是 two-learner, 是用對照組和實驗組分別建模得到兩個模型, 對每個樣本計算兩個模型的預測值之差作爲 HTE(異質因果效應)。兩個模型誤差累計比較大,因爲對照組的模型無法學到實驗組的 pattern,實驗組的模型也無法用到對照組的數據。兩個模型完全隔離,也就導致兩個模型可能各自有各自的偏差,從而導致預測產生較大的誤差。

而 x-learner 就是交叉的意思,是融合了 S-Learner,T-Learner。

首先分別對對照組和實驗組進行建模得到兩個模型,然後把對照組放進實驗組模型預測,實驗組放進對照組模型預測,預測值和實際值的差作爲異質因果效應的近似。這一塊跟 T-Learner 是一樣的。

然後把獲取到的異質因果效應 D1,D0 作爲訓練目標,再訓練兩個模型,最後把這兩個模型加權求和就是 uplift 值。

其實 uplift 模型除了 meta-learning 的模式外,還有 tree-based,nn-based。

與 meta-learner 不同的是,uplift model 下的樹模型通過對增量直接建模,對特徵點進行分裂, 將 X 劃分到一個又一個 subspace 中,那劃分準則與傳統的決策樹信息熵或者基尼係數不一樣,這邊主要是採用分佈散度或者 CTS 分裂準則。

nn-based 我們還沒有嘗試,他是將 propensity score 估計即傾向性得分和 uplift score 估計合併到一個網絡實現。

從圖中我們可以看到 x-leaner 的離線效果更好,auuc 和 gini 值都表現更好。同時從車主促活場景來看,確實比較更優異。所以在我們的營銷場景,uplift 增益模型使用的是 x-leaner。

我們當前這一套 uplift + 運籌優化的框架,相比之前的的 response + 規則的框架來說,在 ROI 上提升了 10%,所以說因果推斷在營銷場景是非常有效的,很值得全面擁抱因果推斷。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/HPKzTZ0nQ8WUM4Yhb0VFaQ