度假业务在整个在线旅游市场中占据着非常重要的位置，如何做好做大这块蛋糕是行业内的焦点。与美食或酒店的用户兴趣点明确（比如找某个确定的餐厅或者找某个目的地附近的酒店）不同，旅游场景中的用户兴趣点（比如周末去哪儿好玩）很难确定，而且会随着季节、天气、用户属性等变化而变化。这些特点导致传统的信息检索并不能很好的满足用户需求，我们迫切需要建设旅游推荐系统（本文中度假=旅游）。
旅游推荐系统主要面临以下几点挑战：
本异地差异大。在本地生活场景中用户需求绝大部分集中在本地，而在旅游场景中超过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；
可解释性：利用用户的历史行为给用户做推荐解释，可以令用户比较信服。
