導讀： 招聘業務是多行爲場景，用戶需求和交互週期短、行爲稀疏。本次分享基於業務挑戰，將介紹代價敏感、向量檢索等技術在招聘深度召回中的應用，最後總結實踐中的教訓與心得。
主要內容包括：
- 58招聘業務場景
- 招聘推薦系統
- 基於行爲的向量化召回
- 實時深度召回
- 教訓和心得
01 58招聘業務場景
首先和大家分享下58招聘涉及的業務及場景。
1. 58招聘業務
招聘行業：
據2018年統計，我國總人口13.9億，就業人口7.7億，三大產業就業人口占比分別爲26.11%、27.57%、46.32%；據2019年8月統計，城鎮調查失業率達到5.2%，25～59歲人口失業率達到4.5%；2019年800萬+畢業生進入求職市場；求職者和招聘方的需求都十分強烈。
58招聘：
58招聘在互聯網招聘界佔有率居首；服務於大規模求職者及大中小型企業；平臺上每天達成海量連接，促成大量成功就業。
求職場景分爲C端求職者和B端招聘方：
- 求職者進入App後，會在展現的職位信息中產生行爲，如直接投遞簡歷，或者點擊進入職位詳情頁後通過簡歷投遞、IM、電話等多種方式與招聘方交互；
- 招聘方可以搜索/瀏覽合適的簡歷，通過IM、電話、在線面試等多種方式與求職者交互，對簡歷進行反饋。找到心儀的求職者並進行面試乃至入職的後續流程。
58招聘是一個典型的雙邊業務，交互渠道非常多樣。
2. 58招聘推薦場景
58招聘主要實現了以下招聘場景的推薦：
- 大類頁：分爲專區推薦和搜索推薦；
- 標籤落地頁：58招聘Feed流推薦的代表，根據用戶搜索的請求匹配相應的職位，用戶在展現頁可以選擇投遞職位或進入詳情頁查看；
- 詳情頁：展示具體的職位信息。
推薦內容主要包括toC的職位推薦、標籤推薦、企業推薦，以及toB的簡歷推薦。
產品主要包括普通職位和廣告職位。
3. 58招聘場景下面臨的問題與挑戰
在我們的工作中，主要面臨以下問題和挑戰：
- 海量數據： 千萬級別的雙邊 ( 企業、求職者 ) 角色，用戶行爲非常複雜。
- 冷啓動問題： 新的求職者來到平臺沒有詳細簡歷信息，在這種場景下如何引導用戶進行投遞行爲。
- 稀疏性&實時性： 找工作這種活動的性質決定了部分求職者的行爲是短時間的連續稀疏行爲，通常在幾天或者一週之內完成；部分老用戶回到平臺找工作，其求職意願可能發生了改變；用戶行爲週期過短並且用戶意圖經常變化對深度模型的搭建造成了很大的挑戰。
- 資源分配問題： 如何有效的識別用戶 ( 企業、求職者 ) 的真實意圖，進而更合理地分配資源從而產生有效連接；崗位招聘希望高效匹配人才，過多的連接會導致資源浪費，同時影響體驗 ( 石沉大海 )。
下面和大家分享下58招聘推薦系統的整體架構和召回實現。
02 58招聘推薦系統
1. 58招聘推薦系統整體實現
58招聘推薦系統的整體處理流程和其他場景的推薦系統大同小異。在用戶到來後首先進行用戶意圖理解，從職位池中多路召回職位，對召回職位根據優化目標進行精排和重排序，最後加入多樣性等策略將最終內容展現給用戶。
- 意圖理解：C端用戶進入後通過內容理解、行爲理解
- 內容召回：上下文召回、實時item-CF、深度召回以及粗排的等多種召回方式
- 排序Rank：優化目標有很多，除了傳統的CTR預估、CVR預估，還有招聘場景下針對B端用戶進行的FBR ( FeedBack Rate ) 預估；重排序控制
- 內容展示：針對業務考慮推薦的解釋性及多樣性，進行排序並最終展現
2. 58招聘推薦系統的召回策略
58招聘推薦系統的召回策略多達十幾種。主要有：上下文召回、附近召回、實時CF召回、用戶畫像、標籤召回、向量召回、實時深度召回。
從圖中直觀地看，實時召回在召回序列中性能最優。
03 基於行爲的向量化召回
1. 深度召回的整體框架
不論傳統或深度召回方法，都要先構建物品的索引和理解用戶的請求，對用戶的請求返回匹配的物品。不同處在於深度召回中物品索引和用戶請求表現爲向量的形式。
離線使用DNN對招聘帖向量化，保存向量至KNN檢索引擎：
- 該檢索引擎參考了Facebook的開源項目Faiss，目前58內部已應用到生產並且有完備的中臺支持
- 招聘帖的特徵包括：內容、企業信息、企業聯繫方式等，將多個特徵經過相同的Embedding層後再通過一個平均池化作爲招聘帖最終的向量表示
- 用戶的招聘帖歷史行爲可轉化爲一個行爲鏈，在多條行爲鏈上使用自然語言處理中常見的Skip-Gram加負採樣的做法訓練招聘帖的向量表示
在線依歷史行爲生產用戶興趣向量：
- 用戶特徵，包括：用戶的歷史行爲、用戶的上下文、用戶自身屬性等。
2. 職位向量化的原理及假設
推薦系統將物品對用戶展現後，用戶可能會產生點擊、投遞、電話、IM等多種行爲。上圖右上展示了58招聘如何收集用戶行爲鏈。圖中每一個點代表一個行爲，點中有兩個屬性，招聘帖自身信息和用戶行爲。
招聘帖自身信息：
- 招聘帖id
- 職位的地點、薪水、假期等
用戶行爲：
- 點擊、投遞等
在語言學中，分佈式假設可以表述爲：一個單詞的特徵可以被總和它一同出現的單詞所描述。我們自然可以聯想到：職位可以通過在行爲鏈中與其相鄰的其他職位刻畫。當然這只是一種假設，並沒有嚴格的證明。
特別的，用戶行爲的重要性是不同的。在招聘推薦場景下，顯然投遞行爲的價值大於點擊。
3. 職位向量化採取的主要優化點
網絡架構上節已介紹過，在實踐過程中我們主要有以下幾個優化點。
① Session優化：
Airbnb的經驗是將Session劃分爲2周，58招聘則進行不同的嘗試；上圖左半部顯示的是將Session劃分爲1天或1周時的用戶行爲密度對比，其中藍色表示劃分間隔爲1天，黃色爲1周，圖中縱軸表示用戶不區分點擊或投遞的行爲鏈長度，縱軸表示長度所佔百分比，可以看出差異並不顯著，故初步選定爲1天；上圖右半部顯示的是天內不同Session長度性能比較，左圖表示不同劃分時平均推薦位置排序，越小表示相關結果的推薦越靠前，右圖表示預測結果的AUC，越高代表預測結果越準確，兩個度量指標均爲6小時劃分最優；Session長度取決於產品特性和用戶行爲生命週期；Session長度需要平衡模型性能和訓練資源消耗。
② 正向樣本Left-wise採樣，負向樣本全局空間負採樣加局部市場空間採樣：
- 負採樣時按照不同的地區和職位的類別劃分
- 正樣本Left-wise採樣爲避免用戶未來行爲的干擾，只採樣當前行爲發生之前的行爲
- 不同行爲的權重不同，點擊行爲只給一個較小的採樣窗口，投遞行爲則給一個較長的採樣窗口
- 負向樣本同時在全局空間和局部市場空間採樣，當前用戶行爲的招聘帖具有位置和種類等屬性，可以在同位置、同種類的局部市場空間採樣
③ 行爲權重代價敏感損失：
圖中上面的公式表示不考慮代價敏感時向量訓練的損失函數，其作用是使正樣本之間的向量表示更相似，同時正負樣本之間的表示區別更大。圖中下面的公式是考慮代價敏感時向量訓練的損失函數，具體做法是區分點擊和投遞兩種行爲，在正樣本之間加入一個代價矩陣，表示該樣本的行爲是哪一種，表示不同行爲之間的代價權重，是一個根據經驗給出的超參數。
4. 職位向量化的離線評估與業務效果
評估方法：
展現給用戶的職位會形成一個列表，用戶行爲鏈中包含點擊、投遞，同時用戶可能會對展現列表中的職位進行點擊、投遞；依照用戶歷史行爲鏈中職位和展現行爲職位間的Cosine距離，考察行爲鏈對展現職位的位置提升。
離線評估結果：
圖中表格顯示了用戶歷史行爲鏈對展現職位的位置提升，如在沒有使用Embedding時，歷史行爲鏈投遞的職位與展現列表中產生投遞行爲的職位計算Cosine距離重排序後，平均位置爲7.1074，使用Embedding後平均位置爲4.8236，得到了32.09%的提升，類似的，歷史行爲鏈中的點擊行爲與展現列表中產生投遞行爲的職位計算Cosine距離重排序，顯示對展現職位的位置得到了29.73%的提升。
我們對所有的職位都生產一個向量， 使用Faiss構建向量相似度檢索庫，對每個職位都計算與其最相近的top k職位，最終離線形成職位與職位之間的索引。在線上推薦時我們首先根據用戶的歷史點擊行爲鏈和歷史投遞行爲鏈分別在索引庫中召回職位，再經過精排和補充策略後展現給用戶。
業務效果：
上圖中橫軸表示不同的展現位，縱座標表示提升幅度，不同的曲線表示不同指標下的提升，包括PVR、CTR、Money等；從圖中看出，所有主體指標在線上的反饋都是正向的，且產出較大。
04 實時深度召回
1. 網絡架構
使用雙塔架構進行實時召回在業界得到了極爲廣泛的使用，Facebook、微軟、百度等公司都針對自身業務提出了各自的雙塔網絡架構。58招聘則參考了Youtube技術團隊19年提出的雙塔架構[1]。
用戶側的處理流程：
- 用戶側信息：用戶特徵如簡歷信息、畫像信息等，上下文信息如位置、種類等，以及用戶點擊行爲鏈和用戶投遞行爲鏈；
- 用戶特徵和上下文特徵等多種信息以獨立向量的形式輸入Embedding層後進行平均池化；
- 用戶行爲鏈中每一個招聘帖信息經過Item Embedding層後進行平均池化；
- 上述兩個經過平均池化的向量連接後輸入一個DNN ( Deep Neural networks )，58招聘在DNN的選擇上進行了多種嘗試，如projection ( 單層神經網絡 )、DCN[2]和PNN[3]；
- 最終經過一個L2歸一化操作，得到用戶側的表示向量；
- 特別的，Item Embedding層由用戶側和物品側共享。
物品側的處理流程：
招聘帖信息經過與用戶側共享的Item Embedding層後再進行一次L2的歸一化操作。
其中，共享Item Embedding層的操作爲：
- 對招聘帖的ID進行ID Embedding，對招聘帖的特徵進行Feature Embedding；
- 對上述兩個Embedding向量進行一次加和池化。
2. 增量訓練中的負採樣處理
實時召回時要對模型進行在線的增量更新，無法使用離線時的負採樣操作；我們參考了Youtube團隊19年提出的batch softmax方法，在batch內進行負採樣，具體細節請參考論文[1]。
我們比較了不同batch size的效果區別，實踐表明batch取512時效果最優。
3. 實時深度召回的線上AB測試效果
實時深度召回目前在58招聘還沒有完全開展，所以整體的業務效果不能給大家呈現，目前只能給大家展示與上節介紹的Embedding方法的效果對比。
實時深度召回方法在CTR、CVR指標上都有1個百分點以上的提高。
05 心得體會
1. 召回優化總體思路
我們將召回分成了三個階段，分別爲前、中、後。
召回前：
- 意圖增強：識別場景，用戶，產品三方意圖和狀態；
- 策略調度：在多路召回中採取動態調配創建組裝下游召回策略，增加召回質量和規模，動態調節召回參數如召回量、距離等。
召回中：
- 意圖本地化：通過優化用戶搜索行爲中的query和用戶行爲鏈的理解，更加精準/實時的構建用戶的畫像和query理解；
- 信息檢索：在用戶行爲畫像、簡歷畫像方面，加強查詢條件，如加入福利、年齡等。
召回後：
- 粗排：在中段無法加入的強且顯性因素在這一階段加入；
- 過濾：強匹配因子加在這一階段，如性別，確保重複的各強度匹配的召回規模，部分因子必須在後端處理。
總之，召回階段需要考慮的主要有：場景匹配、實時性、需求意圖匹配、個性化。場景匹配我們主要在召回前進行，在三個階段則都要加強實時性。需求意圖匹配包括對C端和B端兩部分，個性化主要體現在召回中和召回後階段。
召回前的優化得到了約32%的收益提升，召回中的優化得到了約64%的收益提升，召回後的優化只得到了約4%的收益提升，召回後階段還有很大的優化空間。
2. 心得體會
- 業務先行：所有的問題都是因業務而產生，因此無論模型設計、Session劃分、代價敏感損失，以及評估指標等，都要站在業務的角度去考慮；
- Pair-review：Pipeline和設計、實施過程、結果都做Pair-review，算法的迭代週期長，每個階段的review都非常重要；
- 監控：覆蓋在線/離線全Pipeline的監控，每個召回的通道的召回量是多少、進入粗排的量是多少、粗排過濾後的量是多少、進入精排後想要什麼樣的結果等等，只有通過監控才能發現問題，從而才談得上如何解決問題。
3. 後續優化點
- 實時深度召回從目前來看沒有達到我們的預期，增長效果不明顯，後續還需繼續優化，並且要從部分場景開展到全場景覆蓋；
- 召回策略動態調度：繼續優化動態召回調度的策略；
- C端優化到C/B兩端同時優化：58招聘是雙邊業務，前面介紹的工作主要集中在對C端的優化，後續我們會探索雙端同時優化。
06 參考文獻
[1]. Yi, Xinyang, et al. “Sampling-bias-corrected neural modeling for large corpus item recommendations.” Proceedings of the 13th ACM Conference on Recommender Systems. 2019.
[2]. Shan, Ying, et al. “Deep crossing: Web-scale modeling without manually crafted combinatorial features.” Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. 2016.
[3]. Qu, Yanru, et al. “Product-based neural networks for user response prediction.” 2016 IEEE 16th International Conference on Data Mining (ICDM). IEEE, 2016.
07 配套視頻
識別二維碼收看
今天的分享就到這裏，謝謝大家。
作者介紹：
李祖定，58同城算法架構師
58招聘業務推薦系統算法策略負責人，負責招聘推薦系統的算法策略建設和優化，包括召回、排序等，致力於提升平臺用戶體驗和變現能力。
本文來自 DataFunTalk
原文鏈接：