度假業務在整個在線旅游市場中占據著非常重要的位置 ， 如何做好做大這塊蛋糕是行業內的焦點 。與美食或酒店的用戶興趣點明確（比如找某個確定的餐廳或者找某個目的地附近的酒店）不同，旅游場景中的用戶興趣點（比如周末去哪兒好玩）很難確定，而且會隨著季節、天氣、用戶屬性等變化而變化 。這些特點導致傳統的信息檢索并不能很好的滿足用戶需求 ， 我們迫切需要建設旅游推薦系統（本文中度假=旅游） 。
旅游推薦系統主要面臨以下幾點挑戰：
本異地差異大 。在本地生活場景中用戶需求絕大部分集中在本地，而在旅游場景中超過30%的訂單來自于異地請求，即常駐城市為A的用戶購買了城市B的旅游訂單 。外地人瀏覽北京時推薦故宮、長城沒有問題，北京人瀏覽時推薦北京歡樂谷、野生動物園更為合適 。
推薦形式多樣 。除了景點推薦外，還有跟團游、景酒套餐的推薦 。景點下有大量重復相似的門票，不適合按Deal（團購單）樣式展示；跟團游、景酒套餐一般會綁定多個景點，又不適合按POI（門店）樣式展現 。
季節性明顯 。比如 ， 冬季溫泉、滑雪比較熱銷，夏季更多人選擇水上樂園 。
需求個性化 。比如，親子類用戶和情侶類用戶的需求會不太一樣，進一步細分，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化而下線了 。
這一階段的策略主要有兩個創新點：
基于用戶常駐城市統計熱銷，突破了Deal所在城市的限制 ， 在本地能推薦出周邊城市的旅游產品 。
通過銷量衰減，基本解決了季節性問題 。
推薦POI化
每個景點下通常會有多個票種，每個票種下通常會有多個Deal，比如：故宮門票的票種有成人票、學生票和老人票，成人票下由于Deal供應商不同會有多個Deal ， 這些Deal的價格、購買限制可能會有所區別 。如果按Deal樣式展示，可能故宮成人票、學生票都會被推薦出來，一方面大量重復相似Deal占據了推薦展位，另一方面Deal摘要信息較長 ， 不利于用戶決策 。因此2016年初啟動了推薦POI化，第一版的POI化方案基于Deal關聯的POI做推薦，即故宮成人票是熱銷單，實際推薦展示的故宮POI 。這個方案有兩個問題：
推薦的Deal有可能來自同一個POI ， POI化需要去重 。如果推薦展位有30個，候選推薦Deal的數量肯定要>=30，但也可能出現POI化后不足30個情況 。
由Deal反推的POI銷量并不準確，POI實際銷量需要更精確的統計方法 。
因此在2016年Q2上線了基于F值的POI熱銷策略 ， F值是美團點評內部的一種埋點追蹤方法，可以簡單理解為：用戶在瀏覽POI詳情頁時會在埋點日志的F值記錄POI ID，然后這個標記會一直帶到訂單中 ， 這樣就能相對準確計算每個訂單的POI歸屬 。
熱銷策略2.0
【旅游推薦系統的演進】1.0版熱銷策略的主要問題是只考慮常駐城市的用戶在當地的購買偏好 ， 簡而言之，只解決了上海人在瀏覽上海時的推薦問題，北京人在瀏覽上海時推薦的結果跟上海人推薦的一樣 。放大看是本異地場景的問題 ， 本異地場景的定義見下表 。2.0版熱銷策略對本異地訂單分別統計，當某個用戶訪問美團時先判斷該用戶是本地還是異地用戶，再分別召回對應的POI，對于取不到常駐城市的用戶默認看做是本地請求 。從推薦結果看北京本地人愛去歡樂谷，外地人到北京更愛去長城、故宮 。
分類場景召回策略
本地需求瀏覽城市＝常駐城市（示例：北京人瀏覽北京）當地用戶購買的熱銷POI（POI所在城市不一定等于瀏覽城市）
異地需求瀏覽城市!＝常駐城市（示例：重慶人瀏覽北京）異地用戶購買的熱銷POI（所有非北京人購買的熱銷POI）
這一版本中繼續嘗試了分時間上下文的細分推薦，統計一段時間內每天各小時的訂單分布，其中有3個鞍點，對應將一天分為早、中、晚3個時間段，分時間段統計POI熱銷 。從召回層面看POI排序對比之前變化比較大，但由于下文中Rerank的作用，對推薦整體的影響并不大 。
用戶歷史行為強相關策略
熱銷策略雖然能區分本異地用戶的差異，但對具體單個用戶缺少個性化推薦，因此引入用戶歷史行為強相關的推薦策略 。取用戶最近一個月內瀏覽、收藏未購買的POI ， 按城市分組，按POI ID去重，越實時權重越高 。
基于地理位置的推薦策略
上文的策略要么是有大量POI數據，要么是有用戶數據，如果用戶或POI沒有歷史行為數據或比較稀疏，上述策略就不能奏效，即所謂的“冷啟動”問題 。在移動場景下通過設備能實時獲取到用戶的地理位置，然后根據地理位置做推薦 。具體推薦策略分為兩類：
查找用戶實時位置幾公里范圍內的POI按近期銷量衰減排序 ， 取Top POI列表 。
查找用戶實時位置幾公里范圍內的用戶群 ， 基于其近期發生的購買行為推薦Top POI 。比如用戶定位在回龍觀，回龍觀附近沒有POI，但回龍觀的用戶會購買一些應季熱門POI 。
地理位置推薦策略需要過濾用戶定位城市跟客戶端選擇城市不一致的情況，比如：定位北京的用戶在瀏覽上海時推薦北京周邊POI不太合適 。
協同過濾策略
協同過濾是推薦系統中最經典的算法 ， 相對于歷史行為強相關策略 ， 對用戶興趣、POI屬性相當于是做了抽象和泛化 。協同過濾算法主要分為ItemCF和UserCF兩類，我們首先實現了ItemCF，主要原因是：
性能：美團旅游POI數量遠小于用戶數，協同過濾算法核心的地方是需要維護一個相似度矩陣（Item/User相似度），維護POI相似度矩陣比維護用戶相似度矩陣代價小得多；
實時性：用戶有新行為，一定會導致推薦結果的實時變化；
冷啟動：新用戶只要對一個POI產生行為，就可以給他推薦和該POI相關的其他POI；
可解釋性：利用用戶的歷史行為給用戶做推薦解釋 ， 可以令用戶比較信服 。
