導讀： 58本地服務由數百個細分品類、多個創新業務和國際業務組成，如何構建智能化的流量分發體系是一項挑戰，我們通過整合搜索和推薦場景構建了一套統一的流量分發系統，本次分享將主要介紹系統中的算法實踐，包括基於信息結構化和用戶意圖識別的用戶表徵、召回和排序算法等。
本次分享的主要內容包括：
- 58同城本地服務生態介紹
- 本地服務主站流量分發問題與特點
- 本地服務主站流量分發解法
- 總結和展望
01 58同城本地服務生態介紹
1. 業務背景
58本地服務事業羣，舊稱"大黃頁"、“黃老大”，在集團內是即古老又年輕的業務線，古老是因爲自從58成立以來，就是以提供本地信息服務的分類信息網站，年輕是因爲近期來在業務上也做了很多創新，面貌煥然一新了。58本地服務的業務生態涉及面非常廣並且雜，其中業務上主要戰場有20多個，涉及行業有200多個，如麗人、餐飲美食、家政、教育培訓等，能看出行業間關聯也比較少。
目前本地服務主要分三大塊：主站、到家、到店&電商，業務形態多變，依託於商家中臺和合夥人流量分發網絡 ( 一種流量組織形式，通過對社會各個錨點的重新組織，形成與之前流量投放及變現完全不同的流量分發渠道 )。
2. 產品流量形態
主站：58通用的業務形式，由APP\PC\M等端側入口進來到本地服務落地頁，以流量生意爲主 ( 開環業務，目前產品形態正在從開環向半閉環演進 )。
- 推薦場景：列表頁、詳情頁、落地頁等
- 推薦內容：帖子、商家、店鋪、商品、標籤等
- 推薦關注指標：CTR、CVR、Call/UV等
到家：提供到家精選服務品牌 ( 完全閉環業務 )。推薦關注指標：GMV、訂單轉化率、復購率等。
到店&電商：創新業務 ( 完全閉環業務 )。推薦關注指標：GMV、訂單轉化率、復購率等。
城市合夥人：通過線上和線下方式招募或者主動註冊爲58合夥人後，可以轉發對應合夥人任務，該任務可以是以上多種業務形態，通過社交分發並且任務形成轉化後，可以拿到一定的分傭。推薦關注指標：效果轉化率、ROI、DAU。
由於此次分享時間關係，本文只講對主站的流量分發探索。
02 本地服務主站流量分發問題與特點
主站場景下，核心目標是將主站上的信息資產，通過算法場景化和搜索推薦等分發系統，達到對用戶的精準觸達。
1. 主站用戶交互流程
用戶核心行爲路徑：用戶可以直接帶着需求或者不帶需求 ( 搜索詞 )，進入到主要的服務場景-主站的列表頁。在列表頁上，用戶可以瀏覽帖子標題、價格等內容，並點擊進行帖子詳情頁，查看詳細信息、評論等，發起線上電話溝通，或者通過58提供的微聊，從而促進線下成交。
中間產生的數據信息：列表頁詳情頁曝光、點擊、電話、微聊、評論等
2. 主站流量分發特點和問題
信息同質化嚴重，體現在一是帖子信息堆疊嚴重，二是可區分度差，部分帖子只有一句話，很多是無意義內容，比如線上出現過有發佈保姆月嫂的帖子，只有一張正常女性照片，帖子內容只有三個字，你懂的。
人羣結構複雜，存在未登錄用戶、新用戶、低活用戶等，需要制定差異化的推薦策略，針對性優化推薦模型。
決策週期問題，長短週期不一、輕重決策共存，同時也存在短期低頻、需求週期短的情況，比如說單價高的家裝、租車等長週期服務，用戶會相對謹慎，花更多的時間來挑選決策；而管道疏通、空調維修等需求，用戶則會在瀏覽幾個店家後就進行決策，此類需求往往要求短時間內快速解決。
多行業多場景多種類多目標，本地服務類目繁多，涉及200+不相關行業、10+個推薦場景位，推薦內容包括帖子、商家、店鋪等，結合業務特點有不同的優化目標 ( CVR、CTR、Call/UV等 )。
03 主站流量分發解法
上面提到的問題比較多，我們首先從信息供給側解決，重點通過內容結構化來提高內容描述能力，增加信息區分度。
1. 信息結構化
① 發佈結構化
原來的帖子內容雷同，能看出大量拷貝的痕跡，這個問題理應先想到在發佈的時候解決。從內容發佈端定義了針對不同服務的內容模板，商家直接選擇對應模板，填寫個性化參數即可完成發佈。除了多種模板可選，同時也針對不同服務類型在產品側進行了優化，主要有3部分：
一是服務標準化。以搬家爲例，按照用戶個性化需求選擇不同需求項，快速完成服務預訂，同時也能得到相應的價格預估，更方便輔助用戶決策：
- 如車輛信息，可選擇具體車輛型號、尺寸、可載量等
- 如詳細服務，可選擇是否有電梯、小件搬運、支持長途、小件搬運等
- 如收費單項，可選擇不同里程對應的價格、超里程計算、無電梯樓層加價、隨車人員數量等
二是服務智能定價，根據已選項由算法計算輸出合理的價格區間，爲了剔除市場出現過高過低的報價，用以規範58的運營和列表頁結果展現
三是相冊自動分類，即讓用戶上傳的圖片可以自動分類到不同相冊，方便回溯
② 標籤設計及應用
左圖是未做優化前的列表頁展示頁面，從圖上來看，各搜索結果的展現信息都是雷同的，信息羅列程度單一，看不出來各自的區分度，很難契合用戶關注，體驗較差；因此針對這個問題，我們重點做了信息標籤設計，並體現在產品展示層中，標籤化是結構化的重要方法。用戶通過需求搜索詞進入列表頁後，通過搜索詞匹配對應服務的標籤，展示出標準化的服務特點，能夠更好地細化用戶需求，契合用戶關注，如體現家電維修的快速上門、家政服務包括老人看護等 ( 右圖 )。
③ 標籤挖掘流程
整個標籤挖掘流程是，通過帖子等數據源挖掘備選詞，再在備選詞庫中融合成標籤詞，這批標籤詞再通過同義詞庫和歸一規則形成基礎標籤，用算法進行行業詞消歧，形成行業標籤，最終在不同場景應用。
2. 知識結構化
① 知識化標籤體系
上面提到的標籤化，是相對扁平的信息，無法體現出標籤間的關聯關係。因此我們希望能夠挖掘出標籤間的關係。初期通過標題、評論、搜索詞等數據源，找到每個行業中的關注維度，再根據維度定義出種子詞，經過數據挖掘，通過短文本相似把對應其他標籤詞歸類到同一個維度下，並不斷地滾動迭代。具體方式就是各標籤詞與維度詞和維度下的種子詞進行向量計算距離，取距離最近的標籤詞放入到維度中繼續作爲種子詞，這樣種子詞越來越多，後續標籤詞分維度會越來越準，然後根據閾值，有一部分不能歸類的標籤詞可能是需要繼續添加維度，然後在進行下一次滾動一直到所有詞歸類完畢。
② 場景化標籤體系
根據以上挖掘的標籤之間的關係，以及類目和標籤之間的關係，維度和標籤之間的關係最終形成了完整的場景化標籤體系，標籤體系是信息的表達媒介，結構化的基礎。目前，我們的場景化標籤體系規模如下：
- 行業標籤 ( 40w+ )：根據各行業服務維度設計，如租車、家裝，其分類維度及對應不同標籤
- 通用標籤 ( 10w+ )：包括用戶體驗相關 ( 態度好、價格滿意 )、商家服務承諾、平臺評估標籤等
- 應用場景：包括標籤篩選、熱詞推薦、找相似、猜你喜歡、智能摘要等
用戶場景構建：
利用場景化標籤體系，我們進行了用戶場景構建，原因如下：
在老版無場景提示條件下，我們發現58本地服務的登錄用戶在一進入列表頁後的跳出率非常高。這個問題分析得到的最後結論是，用戶確實是帶着明確需求和目的性進入列表頁，如果用戶在默認結果頁中沒有找到想要的服務，這時候就會跳出。既然是有目的的，我們何不事先猜好，找到契合高頻場景的詞，至少能讓用戶在默認頁產生一次點擊，然後利用這次點擊逐步引導用戶。
通過挖掘用戶的服務需求，我們發現其和58本身的CMCS類目體系是交叉、網狀的關係 ( 如用戶想找水電改造服務，在標籤中對應是裝修建材->局部維修->水電改造 )。可以看到右圖，一開始我們是用彈窗形式讓用戶選擇，但這種阻斷式提醒非常影響用戶體驗。因此我們採用了在頂部橫滑的方式展示。
上圖可以看到的是用戶需求的細化和標籤的對應關係，用戶在橫滑模塊中選擇的功能服務或者說是一種使用場景 ( 也是一類標籤，這類標籤代表用戶的在特定場景下的需求，具有很強的用戶屬性，用戶看到後很容易產生共鳴，下文將提到這類標籤如何挖掘 )，可以對應到結構化標籤中，並通過標籤可以進行特定召回。
③ 類目標籤體系
這些有用戶屬性的標籤可以認爲是類目標籤，因爲描述比較寬泛所以具備跨類目屬性，因此我們採用了合併、拆分原有類目的方法來建立類目標籤體系。
合併：
從需求側來看：
- 可以根據搜索詞進行類目預測，計算類目預測PMI ( 類目詞的貢獻值 )。
從內容側來看：
- 根據帖子標題檢查類目詞的相似度，通過Tagging計算詞頻。
從用戶行爲數據應用來看：
- 採用轉化行爲前24小時點擊過的Top3類目和個數，增加閾值篩選等方式計算類目詞頻繁項
- 採用用戶隨機遊走計算類目相似度的算法。獲取用戶點擊商品、電話的點擊序列，按照點擊類目是否相同分別打分，再根據構造出來的類目圖關係，通過隨機遊走算法產生行爲序列，通過SkipGram計算詞向量，最後計算類目詞之間的相似度。
拆分：
通過拆分挖掘類目詞主要有兩種做法：
- 採用通用的知識圖譜。比如家電維修，家電在通用圖譜中是有下位詞的，如電視、冰箱、洗衣機等，根據下位詞和模板可以挖掘出來是電視維修，還是冰箱維修。
- 採用帖子圖聚類算法。根據用戶行爲獲取兩個帖子之間的點擊、電話序列，同時賦予不同的權重並構造I2I關係圖，根據圖進行聚類得到帖子聚類表。每個帖子對應到一個集合裏，再對圖進行DeepWalk的訓練生成帖子向量，再對集合的Embedding進行表徵，再利用表徵關係計算集合間的相似度。
通過合併和拆分類目再結合高頻搜索詞挖掘，可以找到需求詞，構建出場景標籤以及標籤和類目之間的關係，標籤和標籤之間的關係。
3. 用戶意圖感知
現在我們完成了用戶場景化分發體系的構建，如上圖所示，從用戶的需求側到供給側編織了一張大網，一端是用戶，其中長期偏好通過用戶畫像獲取，實時意圖通過意圖系統獲取 ( 下文介紹 )，另一端是已經經過結構化的帖子店鋪和商品SKU，中間通過類目標籤 ( 需求側標籤 ) 和內容標籤 ( 結構化標籤 ) 串起來，整個過程是通過獲取用戶畫像和點擊對應類目行爲，再選擇類目對應的結構化標籤，召回對應的商家帖子和店鋪。即通過信息的結構化快速找到對應服務的SKU。如搬家->公司搬家->拆裝服務->展示出有拆裝服務的優質公司搬家店鋪。在用戶端，我們有對應的用戶畫像，在用戶點擊對應類目時，可以關聯到對應的結構化標籤中，從而召回對應的商家帖子和店鋪。
上圖就是整個用戶使用流程。用戶通過點擊橫滑模塊的標籤，展示已形成結構化的標籤列表，最終用戶可以挑選並快速找到對應的帖子和關心的服務SKU。
4. 分層優化
剛纔說的是場景化構建過程，目的是在默認頁能讓有明確需求的用戶能夠在短時間內找到想要的服務，減少用戶跳出，只要用戶有了點擊，我們就有希望明確用戶的意圖，除此之外還有很大一部分用戶他們還使用了搜索或者推薦等功能，在此我們主要介紹一下在分發系統上的分層優化的方案。如前所述，快速捕捉用戶意圖十分關鍵，用戶意圖是樹型或者是網狀的關係。下面我們講一下，怎麼感知和表徵這個關係，怎麼在算法分層上進行優化。
① 召回優化
不管用戶是否帶着Query詞進入列表頁，此時用戶總會有上下文信息，如用戶畫像、所在場景、點擊標籤、點擊行爲等。我們有一套用戶意圖系統，可以通過系統改寫Query，串出用戶意圖樹，再根據意圖樹在引擎中召回帖子、店鋪列表等。這種改造Query詞的方式其實是一種布爾召回，召回深度偏低。因此希望通過建立用戶意圖表徵，優化成以向量召回，提高泛化能力，從而提高召回深度。
用戶意圖表徵：
那怎麼做用戶意圖表徵？首先對近期的帖子文本內容進行清洗、分詞、標籤化，通過SkipGram形成最終詞向量。這種方式仍然存在問題：整體帖子內容多而雜，表意性稍差。
因此引入了業界通用的騰訊AI Lab中文詞向量，雖然在本地服務場景下無法直接使用，但我們通過在SkipGram之前對詞向量做了初始化，利用了詞向量的預訓練結果。完成這步後，在人工評測時效果有大幅提升，相似召回率提升超過2倍；在線上驗證應用時，標籤推薦CTR效果有4%提升 ( 標籤推薦不涉及帖子標題、企業等其他信息，因此可以用來驗證詞向量是否準確 )。
在預訓練的基礎上進一步優化，我們將使用用戶的最近使用序列進行清洗，最終也放到模型中去訓練。在模型增加行爲序列時，也有一些應用技巧。一個是標籤的點擊行爲數據稀疏，需要做一些前期處理，如拆分Session，把長Session根據時間切分，根據長度取topN做數據增廣、通過Dropout做泛化。經過前期處理後，整體數據訓練樣本量基本達到預期。另一個是根據Session生成用戶向量，同時會對用戶前一段的向量進行初始化，持續保持用戶的原有信息不流失。在增加用戶使用序列後，線上標籤推薦的CTR轉化效果提升15%，漲幅還是非常明顯的。
用戶意圖多目標表徵：
剛剛也提到本地服務的優化目標多樣，有CTR、CVR等，這些目標在實際推薦效果中要求都要有一定程度的滿足，也就是要求模型能夠平衡多目標，即需要模型對用戶把握更全面。那怎麼來訓練最終用戶的表徵向量呢？我們使用了多任務學習模型，通過共享部分網絡結構，來學習基礎通用的表徵。而相對多個單任務模型，多任務模型有以下優點：網絡結構更小、在線CPU使用率更低、支撐更高QPS、性能穩定性高、存儲資源更少。
同時，學習用戶的通用表徵向量，也可以更方便遷移到其他任務模型中。根據前期的數據準備，對用戶行爲序列做Embedding，再接入雙向LSTM，即可根據Embedding對用戶行爲序列本身進行表徵。在完成表徵後，考慮到用戶行爲千變萬化，還需要再加一個Attention網絡，即當用戶搜索或者用戶本身有這樣的標籤時，可以及時捕捉到對應行爲序列中的變化點，並反應到網絡中，最後形成128維的用戶表徵。因此，可以實現根據不同優化目標，可以選擇不同網絡進行學習。以CTR目標爲例，將生成的用戶通用表徵和Item通用表徵，一起放在網絡中對CTR進行優化。
多目標表徵幾點啓示：
- 相關任務，多目標學習的各任務間需要有一定的相關性，否則會起反作用。至於具體是什麼樣的相關性，在實際應用中需要多多考量。
- 增量學習，前面也說到在多目標學習模型中增加了Attention網絡，而隨着時間和用戶興趣的變化，Embedding表徵也需要隨之變化，比如固定時間間隔自動增量更新，每天級更新等，讓模型更貼近用戶的近期數據。
- 數據稀疏問題，多目標表徵可以解決一部分樣本稀疏問題。如帖子CTR點擊數據多，電話、微聊CVR轉化數據少，因此可以通過CTR數據解決一部分CVR數據問題 ( Share )。
- 模型泛化特徵更有效，加了多個任務目標後，其他任務對當前任務有正向作用。從模型AUC來看，多目標學習在線上測試集是優於單目標學習的。在訓練集中相反，單目標更優，但這個影響不大。實際上我們認爲多目標學習的作用是在單目標基礎上增加了正則項 ( 原本網絡訓練時也需要加入正則 )，有一定促進作用。
- 模型效率問題， 比如說CTR訓練任務中，有1w個物品，需要計算1w次，每次調用耗費資源很高。如果最終是需要生成一個User表徵，其實可以只計算一次。
- 樣本偏差問題，需要注意離線均值和方差和在線保持一致。
上圖是在加上多目標表徵做召回的實驗效果，可以看到PV CTR、UV CTR都有1%多的提升，儘管樣本沒有發生太大的改變。
② 排序優化
實時意圖：
排序上優化重點在如何挖掘用戶點擊的實時意圖。我們通過收集用戶各種行爲數據，做數據清洗、存儲和權重計算，最終存儲在用戶意向表中，包括一些行爲更新、過期管理、分值衰減等。這裏最終存儲的就是用戶的行爲和對應行爲的分值、標籤和對應標籤的分值。在統計標籤分值時，需要考慮帖子標籤的權重是否有區分度：
- 不重要無區分度的標籤權重相對較小
- 根據用戶對帖子行爲距離當前的時間設置權重，時間越近影響越大
- 不同行爲類型權重不同，如搜索、篩選、電話等需要設置不同權重
上下文感知：
剛纔得到的是對用戶行爲特徵的意圖挖掘，可添加到線上網絡中應用。而網絡中還涉及到大量的其他特徵，如人羣、商家、場景特徵等。由於用戶點擊序列不會特別長，點擊特徵可能存在冷啓動問題，所以更多可以通過場景、商家特徵作爲補充。這些特徵維度特別高，需要通過幾層網絡來做降維，最終形成有上下文關係的用戶意圖感知。
上圖是實時意圖特徵應用的實驗效果，通過帖子提取大量的內容標籤，根據用戶行爲進行標籤匹配，最後產生用戶所感知的信息。可以看到在對應場景下，轉化效果都有一定提升。
③ 展示優化
由於用戶意圖實時變化，而帖子信息特別繁雜，在列表頁展示信息時，其展示的信息不一定契合用戶當前需求。因此我們做了智能展示策略，核心是基於用戶服務標籤和行爲數據，根據用戶實時意圖，對帖子本身進行展示區分，同時改變其結構化信息。標籤、標題、圖片、摘要等展示內容都會隨着用戶的實時意圖隨時發生改變，極大提高了對用戶需求的關注粒度，有效提升用戶體驗。
5. 系統整合優化
在流量分發過程中，涉及的系統繁多，如搜索、推薦、智能摘要等。因此我們需要對各系統進行整合。
好處很明顯，不同系統沉澱的用戶數據不需要存多份，減少重複數據存儲；通用算法共享；相似場景模塊複用，減少開發成本。
- 數據資產，我們能夠提供的數據資產豐富 ( 用戶畫像、行爲數據 )，還包括帖子、服務、SKU、商品、任務都可以作爲分發的內容。
- 算法註冊表，包括召回、排序等各種模型，封裝在組件服務中。
- 組件註冊表，提供滿足用戶在不同場景、不同上下文意圖中的功能組件。如需要處理Query時，有糾錯、改寫、Tagging等組件，需要處理用戶意圖，有意圖識別、偏好預估等組件。
- 場景任務配置，提供方便組件間自由組合的配置功能，如智能摘要中，只需要配置召回、排序組件；在用戶搜索場景中，在召回、排序基礎上，還需要配置Query相應的處理、用戶搜索意圖識別等。
04 總結與展望
1. 重排序
後續會繼續研究重排序模塊，我們嘗試在詳情頁、猜你喜歡頁面上做了交互式推薦，如在Feed流無限下拉，點擊回退後希望會對之前結果進行重排序，目前還在實驗中。
2. 品類交叉推薦
剛剛提到58的服務品類是多而雜的，雖然品類間關聯少，仍然也可以挖掘出一定的交叉能力，如通常用戶在搬完家後會找保潔服務，那搬家和保潔就是有一定關聯的。
3. 拼單推薦
我們也在探索拼單推薦的模式。如果發現當前小區有多個服務需求，而附近保潔阿姨正在工作，爲了減少跑腿，可以有第二單減免的優惠等，對平臺、用戶、商家都是有利的。
4. 週期推薦
像做飯、保潔這類服務都是有一定週期性的，比如每月一次、每日三餐等。
5. 閉環反哺開環
本地服務大多依賴於線下成交，用戶在線上尋找服務後的電話、微聊轉化情況，線下是否成交等，我們是很難知道的。而目前的到家精選業務是有完整的閉環數據，可以輔助我們決策。
6. 社交關係分發
合夥人網絡這塊，實際是社交關係的分發，比如合夥人會分享任務在微信羣或者其他羣裏，這裏是存在社交中的信任關係的。
7. 利益驅動分發
另外，由於合夥人涉及分傭，其中的提成比例、分佣金額等，涉及到與業務投入產出比的指標，也需要考慮。
8. 流量分發與生態建設：規則？算法？
58本地服務涉及到200+基礎行業的方方面面，中小商家、務工人員等，都是依託整個平臺流量來生存。因此我們需要思考怎麼更好地匹配商家和用戶，根據生態更好的演化，做到更好的優勝劣汰；需要思考如何把產品規則和算法目標更好地融合。目前初步的想法是把產品規則前置，減少規則性對算法輸出結果的破壞和干擾。
作者介紹：
陳琳：58同城，算法架構師
58本地服務事業羣算法策略部負責人，負責本地服務業務中用戶/商家畫像、標籤挖掘、搜索推薦、知識圖譜等系統的建設，支持58站內本地服務、城市合夥人體系、到家到店及電商體系的流量分發和營銷。
本文來自 DataFunTalk
原文鏈接：