背景

度假業務在整個線上旅遊市場中佔據著非常重要的位置，如何做好做大這塊蛋糕是行業內的焦點。與美食或酒店的使用者興趣點明確（比如找某個確定的餐廳或者找某個目的地附近的酒店）不同，旅遊場景中的使用者興趣點（比如週末去哪兒好玩）很難確定，而且會隨著季節、天氣、使用者屬性等變化而變化。這些特點導致傳統的資訊檢索並不能很好的滿足使用者需求，我們迫切需要建設旅遊推薦系統（本文中度假=旅遊）。

旅遊推薦系統主要面臨以下幾點挑戰：

1. 本異地差異大。在本地生活場景中使用者需求絕大部分集中在本地，而在旅遊場景中超過30%的訂單來自於異地請求，即常駐城市為A的使用者購買了城市B的旅遊訂單。外地人瀏覽北京時推薦故宮、長城沒有問題，北京人瀏覽時推薦北京歡樂谷、野生動物園更為合適。
2. 推薦形式多樣。除了景點推薦外，還有跟團遊、景酒套餐的推薦。景點下有大量重複相似的門票，不適合按Deal（團購單）樣式展示；跟團遊、景酒套餐一般會繫結多個景點，又不適合按POI（門店）樣式展現。
3. 季節性明顯。比如，冬季溫泉、滑雪比較熱銷，夏季更多人選擇水上樂園。
4. 需求個性化。比如，親子類使用者和情侶類使用者的需求會不太一樣，進一步細分，1~4歲、6歲以上親子類使用者的需求也會有所差別。

針對上述問題我們定製了一套完整的推薦系統框架，包括基於機器學習的召回排序策略，以及從海量大資料的離線計算到高併發線上服務的推薦引擎。

策略迭代

推薦系統的策略主要分為召回和排序兩類，召回負責生成推薦的候選集，排序負責將多個召回策略的結果進行個性化排序。下文會分別對召回和排序策略的迭代演進過程進行闡述。

召回策略迭代

我們從2015年底啟動了旅遊推薦系統的建設，此時度假業務有獨立的周邊遊頻道首頁，其中猜你喜歡展位的推薦策略由平臺統一負責，不能很好的解決旅遊場景中的諸多問題。下文會按時間順序來闡述如何利用多種召回策略解決這些問題。

熱銷策略1.0

旅遊推薦第一版的策略主要基於城市熱銷，不同於基於Deal所在城市統計分城市熱銷，這一版策略基於使用者常駐城市來統計，原因是不同城市的旅遊資源分佈各異，存在資源缺乏（客源地）、旅遊資源豐富（供給地）以及本地人到周邊城市遊玩的需求。即對於每個城市，都有其對應的“城市圈”Deal庫，比如：廊坊沒有滑雪場，但常駐城市為廊坊的使用者經常購買北京的滑雪場，因此當廊坊使用者在當地瀏覽周邊遊頻道時會推薦出北京的滑雪場。

在具體實現時考慮旅遊產品隨季節性變化的特性，銷量隨時間逐漸衰減，假定4周為1個變化週期，Deal得分公式為：deal_score = ∑((count(payorder) * α ^ i)，其中count(payorder)指該Deal相應日期的支付訂單數，i指該日期距今的天數，取從1到28的整數，α為衰減係數(<1)，Deal得分為一定週期內每日銷量得分的總和。

根據上述公式對每個城市都能統計Top N熱銷Deal，再根據Deal關聯POI過濾離當前瀏覽城市200km以外的Deal，比如：在瀏覽北京時推薦上海迪士尼門票不太好，不符合周邊遊的定位。

這一階段還嘗試了熱門單、低價單、新單策略。新單和低價單比較好理解，就是給這些Deal一定的曝光機會。熱門單跟熱銷單類似，統計的是Deal瀏覽資料，熱門單召回的Deal跟熱銷策略差異不大。但由於推薦的評估指標是訪購率（支付UV/推薦UV），這些策略的效果不及熱銷，都沒有上線。

另外還初步嘗試了分時間上下文的推薦，比如：區分工作日/非工作日， 週一至週四過濾週末票、週五至週日過濾平日票，不過隨著推薦POI化而下線了。

這一階段的策略主要有兩個創新點：

1. 基於使用者常駐城市統計熱銷，突破了Deal所在城市的限制，在本地能推薦出周邊城市的旅遊產品。
2. 通過銷量衰減，基本解決了季節性問題。

推薦POI化

每個景點下通常會有多個票種，每個票種下通常會有多個Deal，比如：故宮門票的票種有成人票、學生票和老人票，成人票下由於Deal供應商不同會有多個Deal，這些Deal的價格、購買限制可能會有所區別。如果按Deal樣式展示，可能故宮成人票、學生票都會被推薦出來，一方面大量重複相似Deal佔據了推薦展位，另一方面Deal摘要資訊較長，不利於使用者決策。因此2016年初啟動了推薦POI化，第一版的POI化方案基於Deal關聯的POI做推薦，即故宮成人票是熱銷單，實際推薦展示的故宮POI。 這個方案有兩個問題：

1. 推薦的Deal有可能來自同一個POI，POI化需要去重。如果推薦展位有30個，候選推薦Deal的數量肯定要>=30，但也可能出現POI化後不足30個情況。
2. 由Deal反推的POI銷量並不準確，POI實際銷量需要更精確的統計方法。

因此在2016年Q2上線了基於F值的POI熱銷策略，F值是美團點評內部的一種埋點追蹤方法，可以簡單理解為：使用者在瀏覽POI詳情頁時會在埋點日誌的F值記錄POI ID，然後這個標記會一直帶到訂單中，這樣就能相對準確計算每個訂單的POI歸屬。

熱銷策略2.0

1.0版熱銷策略的主要問題是隻考慮常駐城市的使用者在當地的購買偏好，簡而言之，只解決了上海人在瀏覽上海時的推薦問題，北京人在瀏覽上海時推薦的結果跟上海人推薦的一樣。放大看是本異地場景的問題，本異地場景的定義見下表。2.0版熱銷策略對本異地訂單分別統計，當某個使用者訪問美團時先判斷該使用者是本地還是異地使用者，再分別召回對應的POI，對於取不到常駐城市的使用者預設看做是本地請求。從推薦結果看北京本地人愛去歡樂谷，外地人到北京更愛去長城、故宮。

這一版本中繼續嘗試了分時間上下文的細分推薦，統計一段時間內每天各小時的訂單分佈，其中有3個鞍點，對應將一天分為早、中、晚3個時間段，分時間段統計POI熱銷。從召回層面看POI排序對比之前變化比較大，但由於下文中Rerank的作用，對推薦整體的影響並不大。

使用者歷史行為強相關策略

熱銷策略雖然能區分本異地使用者的差異，但對具體單個使用者缺少個性化推薦，因此引入使用者歷史行為強相關的推薦策略。取使用者最近一個月內瀏覽、收藏未購買的POI，按城市分組，按POI ID去重，越實時權重越高。

基於地理位置的推薦策略

上文的策略要麼是有大量POI資料，要麼是有使用者資料，如果使用者或POI沒有歷史行為資料或比較稀疏，上述策略就不能奏效，即所謂的“冷啟動”問題。在移動場景下通過裝置能實時獲取到使用者的地理位置，然後根據地理位置做推薦。具體推薦策略分為兩類：

1. 查詢使用者實時位置幾公里範圍內的POI按近期銷量衰減排序，取Top POI列表。
2. 查詢使用者實時位置幾公里範圍內的使用者群，基於其近期發生的購買行為推薦Top POI。比如使用者定位在回龍觀，回龍觀附近沒有POI，但回龍觀的使用者會購買一些應季熱門POI。

地理位置推薦策略需要過濾使用者定位城市跟客戶端選擇城市不一致的情況，比如：定位北京的使用者在瀏覽上海時推薦北京周邊POI不太合適。

協同過濾策略

協同過濾是推薦系統中最經典的演算法，相對於歷史行為強相關策略，對使用者興趣、POI屬性相當於是做了抽象和泛化。協同過濾演算法主要分為ItemCF和UserCF兩類，我們首先實現了ItemCF，主要原因是：

• 效能：美團旅遊POI數量遠小於使用者數，協同過濾演算法核心的地方是需要維護一個相似度矩陣（Item/User相似度），維護POI相似度矩陣比維護使用者相似度矩陣代價小得多；
• 實時性：使用者有新行為，一定會導致推薦結果的實時變化；
• 冷啟動：新使用者只要對一個POI產生行為，就可以給他推薦和該POI相關的其他POI；
• 可解釋性：利用使用者的歷史行為給使用者做推薦解釋，可以令使用者比較信服。

基於POI瀏覽行為的協同過濾

根據UUID維度的瀏覽資料來計算POI之間的相似度，瀏覽行為比下單、支付行為更為稠密。時間視窗取一個月的資料，理論上只要計算計算能力不是瓶頸，時間視窗應該儘可能的長。相似度公式定義如下：

分母是瀏覽POI i的使用者數，分子是一個月內同時瀏覽過POI i和j的使用者數。在計算完POI相似度後，再通過如下公式計算使用者u對POI j的興趣：

這裡是使用者瀏覽或購買過的POI的集合，是和POI j最相似的K個POI的集合，是POI j和i的相似度，是使用者u對POI i的興趣。協同過濾可以看做是使用者歷史行為強相關策略的泛化，最終的推薦結果示例：使用者瀏覽了“北京歡樂谷”，推薦出“北京海洋館”、“香山公園”。

使用者對POI的行為表每天離線生產好後更新，相當於只有當天之前的資料，缺少對使用者當天實時行為的反饋，因此增加基於使用者實時POI行為的協同過濾推薦，複用上文中的POI相似度計算結果。

基於使用者搜尋行為的協同過濾

搜尋行為是一種強意圖行為，旅遊較多訂單來源於搜尋入口，相當比例的搜尋使用者沒有點選任何POI，基於使用者搜尋行為的推薦可以作為POI瀏覽推薦的一種補充。首先構造Query和POI的相似度矩陣，利用使用者搜尋Query後10分鐘內瀏覽的POI構造對，相似度演算法跟POI相似度公式一致。

具體實現時以Query+City為Key，原因是旅遊場景中存在部分全國連鎖POI，如：歡樂谷、方特，如果只以Query為Key，則跟“歡樂谷”Query最相關的POI可能是“北京歡樂谷”，那使用者在深圳搜尋“歡樂谷”後會推薦出北京歡樂谷，不符合使用者需求。

相似度改進

改進後的相似度公式如下，其中表示POI i和j的序列跨度長度，是POI i和j序列長度為的次數，是序列跨度的衰減係數(<1)：

召回策略全景檢視

經過一年的迭代，目前線上線上的召回策略如下圖，此外還嘗試了基於ALS的矩陣分解，但推薦的結果比較冷門，可解釋性較差；另外啟動了基於使用者標籤的推薦，對使用者和POI都打上相應的屬性標籤，可以直接單維度標籤進行推薦，比如：給親子類使用者推薦親子類POI，也可以把標籤當做維度，多維度計算使用者和POI的相關性。

每類召回策略的結果都需要做過濾，過濾策略主要有幾類：

1. 黑名單過濾。如源頭有髒資料或需要人工干預的Case。
2. 無售賣POI過濾。即過濾沒有售賣Deal的POI。
3. POI距離過濾。過濾據當前瀏覽城市幾百公里外的POI。
4. 非當前城市過濾。過濾非當前瀏覽城市的POI。
5. 已購買POI過濾。

其中前2類過濾策略對所有召回策略是通用的，都需要做，黑名單過濾考慮到資料更新的實時性，在線上處理，其他過濾策略可以在離線資料層統一處理。後3類只有特定召回策略需要，因為依賴使用者請求，只能在線上處理，具體規則如下：

排序策略迭代

每類召回策略都會召回一定的結果，這些結果去重後需要統一做排序。在早期只有熱銷策略一個時不需要Rerank，直接根據熱銷得分來排序，加入歷史行為強相關和Location-Based策略後也是按固定展位交叉展示的，比如：第1、3、5、7位給歷史行為強相關策略，第2、4、6、8位給Location-Based策略。

在2016年Q1初嘗試了第一版的Rerank策略，當時推薦樣式還是Deal，因此排序物件也是Deal，主要特徵是30/180天的銷量/評分資料，因為考慮的特徵比較少，上線後效果並不明顯。

在Q2初由於基本完成了POI化展示，排序物件變成POI，主要特徵包括銷量、評分、價格、退款資料，上線後效果仍不明顯。

因為推薦列表頁跟篩選列表頁類似，在Q2中期嘗試直接接入篩選Rerank，但效果不太理想。隨後基於推薦的資料樣本重新進行了訓練，並新增了一些特徵，特徵上大致分為以下幾類：

從上表看在銷量和評價基礎上主要新增了上下文特徵、距離特徵和訪購相關特徵，注意到HOUR_OF_DAY、DAY_OF_WEEK、CITY_ID並沒有採用one-hot編碼，在線上實驗one-hot編碼效果並不優於直接使用原始值。可能的解釋是HOUR_OF_DAY離散值可以用於樹模型來分類，比如：0~11點可以表示上午、12點~18點可以表示下午、19點~23點表示夜晚；同理DAY_OF_WEEK週一到週四可以認為是平日，週五到週日認為是週末；CITY_ID可能的解釋是ID越小，越是開站較早的城市，也是更熱門的城市。

模型上取最後一個點選前的樣本為候選樣本集，以支付為正樣本，其他為負樣本，正負樣本取樣比為1：10。如果不做樣本取樣，假設每100人訪問只有1個支付，每次訪問列表頁假設使用者平均能看到10個POI，即正負樣本比例大約為1：1000，樣本分佈極不均衡，容易導致過擬合。模型訓練上採用XGBoost演算法，上線後點擊率和訪購率均明顯正向，證明了Rerank的有效性。

在上述基礎上後續又逐步豐富了上下文特徵，比如：召回可能觸發周邊城市圈的POI，因此增加POI是否本城市的特徵，另外熱銷召回策略拆分了本異地，Rerank也對應增加了使用者請求是否本異地特徵；增加了User-POI組合特徵：User 7天內是否瀏覽/收藏過POI、實時特徵、基於協同過濾的User-POI相關性等，跟歷史行為強相關、協同過濾的召回策略能相呼應；增加了POI靜態屬性特徵，如：星級，另外把POI的銷量也按本異地進行了拆分。這些特徵上線後效果基本都正向，符合預期。

模型上嘗試了短週期模型+長週期模型的融合，短週期為近期一個月資料，長週期為近期三個月資料。從線上結果看直接用短週期模型效果最好，這可能跟旅遊應季變化快有關。除了上述特徵外，後續還可以增加User個性化特徵、天氣上下文特徵、POI特徵CTR/CVR可以拆分本異地等。

排序策略全景檢視

推薦的離線訓練流程跟搜尋、篩選排序保持一致，流程圖如下：

• 首先是資料標註，資料來源是原始的樣本日誌，記錄在Hive中，輸出是ISample物件，同時打上label。另外可能部分特徵需要在線上生產並寫入樣本日誌中，比如：實時特徵，沒辦法用離線ETL採集；
• 樣本選擇：對初始樣本做過濾，比如：過濾最後一個點選樣本之後的資料，輸出還是ISample；
• 特徵抽取：在樣本中有POI ID，根據POI ID可以抽取POI的銷量、評價等特徵；同理可以根據樣本中的UUID抽取使用者相關特徵。這樣就生成了帶上Feature的Sample；
• 資料取樣：按事先定義的正負樣本比例對樣本進行抽象；
• 訓練集構建&輸出：按XGBoost格式輸出訓練集。

整個訓練集的構造過程由Scala編寫在Spark叢集上執行，而由於XGBoost的Spark版本效果不太穩定，在最後的模型訓練與評估中使用的XGBoost的單機版本，模型的訓練引數（迭代次數、樹的深度等）一般選取經驗值，訓練集選一個月的資料，測試集一般選訓練集日期後的若干天，離線評估指標主要參考AUC，離線效果有提升就會上線ABTest實驗，逐步迭代。

工程架構設計

推薦系統的整體工程架構如下圖，從下至上包括離線計算層、核心資料層、推薦服務層和應用場景層，另外是後臺配置管理系統和資料排程服務。

離線計算層

離線計算層除了Rerank需要的特徵和訓練日誌外，主要包括基礎資料和應用資料兩類。基礎資料中最重要的是Deal和POI的資料，為了保證資料的準確性和實時性，Deal和POI的資料直接從旅遊產品中心去取，通過定時全量拉取並輔以訊息佇列實時更新。應用資料按生產方式又可以分為三類：

1. Hive ETL生產的資料：比如POI過濾需要用到的離線表（主門店等邏輯），另一大類是統計資料，比如：城市POI熱銷、線路遊熱銷、使用者對POI的瀏覽/購買行為。
2. Spark生產的資料：比如：User CF、POI CF、矩陣分解演算法等，這類資料生產邏輯複雜，不好直接通過ETL計算完成。
3. Storm生產的資料：使用者實時行為在召回、排序都需要用到，目前公司提供統一的實時使用者行為資料流user__action_basic，包括：瀏覽/收藏 POI/Deal、下單、支付、消費、退款，從中過濾出旅遊POI/Deal的行為即可。

核心資料層

抽象出核心資料層的一個重要原因是需要離線計算工程和線上服務工程複用DataSet，從供線上使用的儲存方式看可以分為三類：

1. 儲存在ElasticSearch（以下簡稱ES）中的資料。主要是POI/Deal索引，比如：POI的地理位置、所在城市，當線上需要根據地理位置過濾時可使用ES查詢，比如：城市圈的距離限制，Location-Based策略一定距離內的召回。另外對於多維查詢場景ES也比KV儲存更為合適。這類資料通過公司統一的任務排程系統來定時排程，通常幾小時更新一次。這裡為ES索引建立一個別名，離線更新索引切別名的指向，保證操作的原子性。
2. 儲存在DataHub中的資料。DataHub是酒旅搜尋團隊開發的一套資料管理系統，集資料儲存、管理、使用於一體。目前支援將Hive表的資料定期匯入，DataHub內部主要使用Tair作為儲存，對客戶端使用透明，客戶端介面支援一維和二維的Key，介面對應用方基本是一致的，另外應用方也不需要自行維護Tair叢集配置管理了。DataHub自帶排程功能，通過掃描HDFS分割槽生成後自動寫入Tair。
3. 直接儲存在Tair中的資料。主要面向DataHub還不支援的兩類場景，一是實時資料的儲存落地，二是value直接儲存物件，儲存為物件的好處是從Tair讀取出來的物件可直接供線上使用，無需自行序列化和賦值。實時資料無需定時排程，通過Spark直接寫入Tair的資料通常需要依賴上游Hive表先Ready才能執行，所以通過公司統一的資料協同平臺排程。

推薦服務層

服務上下游

推薦上下游的架構圖如下圖，客戶端向API發起呼叫，API呼叫推薦服務拿到推薦的ID再新增供App展示用的相關欄位傳會給App。推薦和搜尋沒有整合成一個服務的重要原因是推薦的召回策略複雜多樣，每次請求可能命中多個召回策略，而搜尋單次請求的意圖一般比較單一，通常只有一個召回策略。另外推薦服務重點在召回和過濾，Rerank呼叫獨立的rank服務，原因是推薦Rerank和搜尋篩選Rerank在特徵上有很多是可以複用的，比如：使用者特徵、POI特徵等。

整體流程

推薦服務向下從數十個資料來源中獲取資料，經過業務邏輯處理後向上支援數十個應用場景，整個呼叫流程如下：

1. RecommendServicePublisher作為服務的入口，從Client接到Request請求後首先驗證請求是否合法，比如：請求引數中場景Booth和UUID不能為空。
2. 構造請求上下文Context，其中會生成唯一的global ID標識一次請求，根據UUID查詢使用者畫像服務獲取常駐城市，根據定位的經緯度查詢定位城市，以及根據ABTest分流配置獲取處理請求的召回排序Strategy。
3. 根據請求場景的Booth獲取對應的Handler，預設使用統一的AbstractHandler即可，包括召回、過濾、rerank、post rerank。
4. 對Handler返回的結果做包裝，增加召回和排序策略名稱、得分等，最終返回給Client。

核心流程與模型

Handler是整個流程的核心，其呼叫流程如下：

1. Handler根據不同的Strategy獲取對應的SelectRule集合，一個場景Booth可能對應多個Strategy，跟ABTest對應，比如：Baseline就是一個Strategy。每個Strategy可能有多個SelectRule，比如：Baseline策略由歷史行為強相關SelectRule、Location-Based SelectRule、熱銷Rule等組成。
2. 召回：每個SelectRule又對應多個Selector，多個Selector通過執行緒池併發獲取結果，比如：Location-Based Rule可以細分為基於周邊熱銷POI召回和基於周邊使用者購買POI召回。Selector可再做抽象，比如：分本異地場景的城市熱銷策略，美團和點評雙平臺都需要，只是資料來源稍有不同，另外對於從ES和DataHub獲取的資料可以加Cache。
3. Merge去重：多個召回策略的結果需要Merge去重，比如早期沒有Rerank時Location-Based策略固定在2、4、6位。
4. 過濾：具體有兩級過濾，一級是針對SelectRule的，比如：針對歷史行為強相關策略中基於瀏覽行為和收藏行為召回的結果都需要過濾使用者已購買過的POI；另一級是針對所有策略通過的過濾，比如黑名單、旅行社代理商。
5. 重排序：對於POI列表呼叫POI Rerank服務，對於Deal列表呼叫Deal Rerank服務。
6. PostRerank：一般用於處理廣告運營的需求和人工干預的Case。

核心的物件模型如下圖：

監控降級

監控分為離線監控和實時監控兩部分，離線監控使用Falcon來監控以下幾類指標：

• JVM監控：比如FullGC次數、記憶體使用情況、Thread block情況
• ES監控：ES查詢次數和平均響應時間
• 業務監控：各介面、各策略的請求次數和平均響應時間

實時監控接入公司統一的實時資料統計平臺，可以分時、分多粒度統計各Booth的請求次數和響應時間。

降級主要通過Hystrix來實現，比如：呼叫Rerank服務在一定時間內響應時間超過設定的閾值，則直接熔斷不請求Rerank服務。

工具化

推薦服務開發了Debug工具，輸入支援城市、展位、UUID、經緯度等引數，輸出展示了POI/Deal的頭圖、標題、和使用者的距離、召回排序策略與得分等。方便PM和RD測試、定位追查Case。

應用場景

推薦系統支援了美團/點評共20個應用場景，主要場景是周邊遊頻道首頁猜你喜歡，其召回策略在上文中已有闡述，這裡重點闡述其他幾類推薦場景：

跟團遊推薦

跟團遊Deal一般會繫結多個景點，不適合按POI樣式展現，因此採用Deal形式展現，召回策略跟熱銷POI策略類似，區分本異地，從結果看北京本地人會推薦“古北水鎮一日遊”，外地人瀏覽北京時會推薦“故宮、長城一日遊”。

篩選異地召回

使用者在篩選酒店時會先選擇入住城市再篩選該城市的酒店POI，而周邊遊存在客源地旅遊資源不豐富的問題，篩選時需要突破選擇城市限制，能夠推薦出周邊城市的熱門POI，篩選異地召回上線後增加了一定比例的訂單，是對本地召回的有效補充。

篩選主題標籤挖掘

即為POI打標籤，使用者可以用這些標籤進行篩選，比如：附近熱門、近郊周邊、週末去哪、親子同樂、夜場休閒。每個標籤都可以定義一套挖掘方法，比如：“親子同樂”有以下幾類方法：

• POI下有親子票種
• Deal標題包含“親子”
• 同一POI下同時包含“成人票”和“兒童票”
• 使用者畫像為“親子”的使用者最近一個月購買的POI

上述挖掘方法偏規則，後續希望能通過半/無監督方法，挖掘POI描述和評論，自動為POI打標。

搜尋少/無結果推薦

搜尋少結果推薦是指當搜尋結果POI類聚結果數=1時，為豐富頁面內容給使用者提供推薦資訊。這裡重點利用搜索的POI結果根據POI CF觸發推薦，以及利用搜索POI的品類進行同城市同品類推薦。

搜尋無結果推薦可以直接統計搜尋Query後一定時間內使用者瀏覽的POI做推薦，但這個策略的覆蓋面有限，進一步可以計算一段時間內的Query CF，然後做協同推薦；另一方面可以通過意圖識別判斷Query中是否有品類詞，觸發同品類推薦。

酒旅交叉推薦

目前只實現了酒店和旅遊之間的交叉推薦，當用戶在酒店頻道搜尋時先判斷Query是否旅遊意圖，其中重點分析兩類意圖：一是景點POI意圖，推薦該景點幾公里範圍內的POI；二是品類意圖，比如：溫泉、滑雪，會推薦使用者定位附近該品類的熱銷POI。

在酒店POI詳情頁會獲取酒店POI的地理位置，推薦酒店附近的景點。對於異地使用者瀏覽酒店時都會觸發景點推薦，對於本地使用者只有在瀏覽郊區酒店時會觸發旅遊推薦，這是假設本地使用者在瀏覽市區酒店時旅遊度假的意圖可能不明顯。

除了在各類推薦場景的應用，這些策略在運營上也有應用嘗試，比如：使用者瀏覽或購買過POI後根據POI CF給使用者PUSH相似的POI，實驗證明推薦策略的PUSH點選率要高於平均水平。

未來的挑戰

經過一年多的迭代優化，周邊遊頻道內相當比例的訂單來自推薦，線上支援了20個左右的推薦場景，很多推薦策略被作為特徵加入搜尋、篩選Rerank，有明顯正向效果，在使用者運營上也有了初步的探索。基於目前的推薦系統本身還有不少優化點：

• 召回策略：策略的廣度和深度都有不少提升空間，廣度方面可以繼續探索矩陣分解FFM、User CF、基於使用者畫像的推薦、圖挖掘；深度方面嘗試LLR等多種相似度計算方法、以及多時間/多使用者維度改進召回策略。資料上可以擴大到酒店甚至美團全平臺的使用者資料，另外對策略的離線實現還要更模組化、抽象化，比如：相似度改進演算法在一處場景驗證有效，可快速推廣上線到其他場景
• 排序策略：特徵工程方面可以增加User個性化特徵、天氣/Listwise上下文特徵等，模型上可以嘗試DNN等方法，評估指標可以從訪購率改進成訪消率（消費UV/訪問UV），另外對美團/點評雙平臺可以定製不同的特徵資料和排序策略
• 工程架構：搜尋少/無結果推薦從搜尋工程遷移到推薦工程，另外對核心資料層儲存方式的邊界劃分，線上服務層的快取、Selector/Rerank降級、Filter/Merge邏輯梳理等需要做“輕量重構”
• 應用場景：除了在酒店購買前的交叉推薦外還可以增加購買後的推薦，以及和機票、火車票大交通相關的交叉推薦，在旅遊內部可以探索更多的場景化建設，比如：親子游、情侶遊

跳出目前單一的以POI/Deal列表為主體的推薦形態看，可以從使用者、場景、內容、觸達方式四個方面看如何做好旅遊推薦：

使用者需求

首先考慮使用者是誰？要滿足使用者的什麼需求？這裡可以利用美團/點評的數億使用者，打“人群標籤”，是一二線城市高階品質女使用者、勤儉住宿的中年大叔還是三線城市實惠型年輕媽媽。然後分析這些人群背後的需求，是本地休閒使用者、差旅使用者還是高頻度假使用者，不同使用者的需求是不一樣的。

場景劃分

當知道使用者後需要知道使用者的場景是什麼？可以從四個維度定義場景：時間、位置、行為、渠道。

時間很好理解，當用戶在週四週五搜尋“滑雪場”，會被認為是休閒度假週末使用者，可以協同推薦北京郊區的滑雪場。

地理位置是核心要素，要根據使用者的常駐城市和客戶端選擇城市來判斷是本地還是異地需求，對於異地的差旅使用者可以推薦商務型的酒店。

行為是使用者需求最直接的反應，比如：使用者搜尋“古北水鎮”，不管使用者後續是否有瀏覽行為，都可以推薦古北水鎮相關的酒店和景點門票。

渠道包括美團/點評雙平臺App、i版、PC等多個終端，以美團App為例，周邊遊、酒店、機票/火車票頻道的使用者特徵都不一樣，比如：大交通頻道最常見的是差旅使用者、周邊遊頻道更多是本地度假休閒的人群。

內容形態

知道了使用者是誰以及處於什麼場景，要考慮提供什麼樣的內容產品？對於美團來說核心是交易，內容不是最核心的目標，但內容是一個非常好的引流措施。以本地場景為例，可以加強場景建設，比如：親子、團建、溫泉等；異地行前場景可以加強目的地、點評遊記攻略、酒店交通行程安排等內容建設。

觸達方式

除了目前的搜尋推薦外，還可以增加定向投放、內容引導、廣告植入、活動運營等多種觸達方式。

總之旅遊推薦問題複雜多樣，需要從度假出行六要素：吃、住、行、遊、購、娛綜合考慮和規劃，對產品形態、業務策略、技術架構都還有很大的挑戰和機遇。

作者簡介

鄭剛，美團點評高階技術專家。2010年畢業於中科院計算所，2011年加入美團，參與美團早期資料平臺搭建，先後負責平臺、酒旅資料倉庫和資料產品建設，目前在酒旅事業群資料研發中心，重點負責酒店旅遊場景下的搜尋排序推薦、資料探勘工作，致力於用大資料和機器學習技術解決業務痛點，提升使用者體驗。