哪个女装网站做的好,allintitle:湛江网站建设 seo,威海信息网,qq注册账号免费申请度假业务在整个在线旅游市场中占据着非常重要的位置#xff0c;如何做好做大这块蛋糕是行业内的焦点。与美食或酒店的用户兴趣点明确#xff08;比如找某个确定的餐厅或者找某个目的地附近的酒店#xff09;不同#xff0c;旅游场景中的用户兴趣点#xff08;比如周末去哪… 度假业务在整个在线旅游市场中占据着非常重要的位置如何做好做大这块蛋糕是行业内的焦点。与美食或酒店的用户兴趣点明确比如找某个确定的餐厅或者找某个目的地附近的酒店不同旅游场景中的用户兴趣点比如周末去哪儿好玩很难确定而且会随着季节、天气、用户属性等变化而变化。这些特点导致传统的信息检索并不能很好的满足用户需求我们迫切需要建设旅游推荐系统本文中度假旅游。 旅游推荐系统主要面临以下几点挑战 本异地差异大。在本地生活场景中用户需求绝大部分集中在本地而在旅游场景中超过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有可能来自同一个POIPOI化需要去重。如果推荐展位有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对于取不到常驻城市的用户默认看做是本地请求。从推荐结果看北京本地人爱去欢乐谷外地人到北京更爱去长城、故宫。 分类场景召回策略本地需求浏览城市常驻城市示例北京人浏览北京当地用户购买的热销POIPOI所在城市不一定等于浏览城市异地需求浏览城市!常驻城市示例重庆人浏览北京异地用户购买的热销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可解释性利用用户的历史行为给用户做推荐解释可以令用户比较信服。基于POI浏览行为的协同过滤 根据UUID维度的浏览数据来计算POI之间的相似度浏览行为比下单、支付行为更为稠密。时间窗口取一个月的数据理论上只要计算计算能力不是瓶颈时间窗口应该尽可能的长。相似度公式定义如下 $$ w_{i,j}\frac{|N(i)\bigcap N(j)|}{\sqrt{|N(i)||N(j)|}} $$ 分母\( |N(i)| \)是浏览POI i的用户数分子\( |N(i)\bigcap N(j)| \)是一个月内同时浏览过POI i和j的用户数。在计算完POI相似度后再通过如下公式计算用户u对POI j的兴趣 $$ p_{uj}\sum_{i\in N(u)\bigcap S(j,K)}w_{ji}r_{ui} $$ 这里\( N(u) \)是用户浏览或购买过的POI的集合\( S(j,K) \)是和POI j最相似的K个POI的集合\( w_{ji} \)是POI j和i的相似度\( r_{ui} \)是用户u对POI i的兴趣。协同过滤可以看做是用户历史行为强相关策略的泛化最终的推荐结果示例用户浏览了“北京欢乐谷”推荐出“北京海洋馆”、“香山公园”。 用户对POI的行为表每天离线生产好后更新相当于只有当天之前的数据缺少对用户当天实时行为的反馈因此增加基于用户实时POI行为的协同过滤推荐复用上文中的POI相似度计算结果。 基于用户搜索行为的协同过滤 搜索行为是一种强意图行为旅游较多订单来源于搜索入口相当比例的搜索用户没有点击任何POI基于用户搜索行为的推荐可以作为POI浏览推荐的一种补充。首先构造Query和POI的相似度矩阵利用用户搜索Query后10分钟内浏览的POI构造 对相似度算法跟POI相似度公式一致。 , 具体实现时以QueryCity为Key原因是旅游场景中存在部分全国连锁POI如欢乐谷、方特如果只以Query为Key则跟“欢乐谷”Query最相关的POI可能是“北京欢乐谷”那用户在深圳搜索“欢乐谷”后会推荐出北京欢乐谷不符合用户需求。 相似度改进 上述相似度计算公式有两个改进点一是未考虑用户行为的先后顺序比如用户先后浏览了POI 之前会两两计算相似度实际只用计算A和 以及B和C的相似度即可因为用户是先浏览了A再浏览了B所以浏览A时可以推荐B但浏览B时推荐A不一定合适。二是未考虑POI之间的时间序列跨度理论上A和B的相似度应该高于A和C的相似度。 c bc 改进后的相似度公式如下其中\( l \)表示POI i和j的序列跨度长度\( N_{ijl} \)是POI i和j序列长度为的次数\( \alpha \)是序列跨度的衰减系数(1) $$ w_{ij}\frac{\sum_{l}N_{ijl}*\alpha ^{l}}{\sqrt{|N(i)||N(j)|}}(ij) $$ 召回策略全景视图 经过一年的迭代目前线上在线的召回策略如下图此外还尝试了基于ALS的矩阵分解但推荐的结果比较冷门可解释性较差另外启动了基于用户标签的推荐对用户和POI都打上相应的属性标签可以直接单维度标签进行推荐比如给亲子类用户推荐亲子类POI也可以把标签当做维度多维度计算用户和POI的相关性。 每类召回策略的结果都需要做过滤过滤策略主要有几类 黑名单过滤。如源头有脏数据或需要人工干预的Case。无售卖POI过滤。即过滤没有售卖Deal的POI。POI距离过滤。过滤据当前浏览城市几百公里外的POI。非当前城市过滤。过滤非当前浏览城市的POI。已购买POI过滤。其中前2类过滤策略对所有召回策略是通用的都需要做黑名单过滤考虑到数据更新的实时性在线上处理其他过滤策略可以在离线数据层统一处理。后3类只有特定召回策略需要因为依赖用户请求只能在线上处理具体规则如下 召回策略过滤规则热销策略POI距离过滤历史行为强相关已购买POI过滤非当前城市过滤Location-Based非当前城市过滤ItemCF已购买POI过滤非当前城市过滤排序策略迭代 每类召回策略都会召回一定的结果这些结果去重后需要统一做排序。在早期只有热销策略一个时不需要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客户端选择城市idDISTANCE用户和POI的距离POIREC_POI_CTR_DAY7...POI 7天的点击率POI_ALLCATE_PAY_F_CNT_DAY7...POI 7天的支付数据POI_COMMENT_CNT_DAY7...POI 7天的评分数从上表看在销量和评价基础上主要新增了上下文特征、距离特征和访购相关特征注意到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越小越是开站较早的城市也是更热门的城市。 模型上取最后一个点击前的样本为候选样本集以支付为正样本其他为负样本正负样本采样比为110。如果不做样本采样假设每100人访问只有1个支付每次访问列表页假设用户平均能看到10个POI即正负样本比例大约为11000样本分布极不均衡容易导致过拟合。模型训练上采用XGBoost算法上线后点击率和访购率均明显正向证明了Rerank的有效性。 在上述基础上后续又逐步丰富了上下文特征比如召回可能触发周边城市圈的POI因此增加POI是否本城市的特征另外热销召回策略拆分了本异地Rerank也对应增加了用户请求是否本异地特征增加了User-POI组合特征User 7天内是否浏览/收藏过POI、实时特征、基于协同过滤的User-POI相关性等跟历史行为强相关、协同过滤的召回策略能相呼应增加了POI静态属性特征如星级另外把POI的销量也按本异地进行了拆分。这些特征上线后效果基本都正向符合预期。 特征维度特征名称说明上下文SCENE_LRIS_POI_LOCAL是本地OR异地用户POI是否本城市User-POIPOI_VIEWED_DAY7...POI 7天内是否被浏览过POI_RT_VIEWED...实时特征用户最近是否浏览过REC_POI_CF_SCORE...通过POI CF计算出的User和POI的语义相关性POIPLACE_STAR...景区星级POI_SCENE_PAY_F_CNT_DAY7...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的数据直接从旅游产品中心去取通过定时全量拉取并辅以消息队列实时更新。应用数据按生产方式又可以分为三类 Hive ETL生产的数据比如POI过滤需要用到的离线表主门店等逻辑另一大类是统计数据比如城市POI热销、线路游热销、用户对POI的浏览/购买行为。Spark生产的数据比如User CF、POI CF、矩阵分解算法等这类数据生产逻辑复杂不好直接通过ETL计算完成。Storm生产的数据用户实时行为在召回、排序都需要用到目前公司提供统一的实时用户行为数据流user__action_basic包括浏览/收藏 POI/Deal、下单、支付、消费、退款从中过滤出旅游POI/Deal的行为即可。核心数据层 抽象出核心数据层的一个重要原因是需要离线计算工程和线上服务工程复用DataSet从供线上使用的存储方式看可以分为三类 存储在ElasticSearch以下简称ES中的数据。主要是POI/Deal索引比如POI的地理位置、所在城市当线上需要根据地理位置过滤时可使用ES查询比如城市圈的距离限制Location-Based策略一定距离内的召回。另外对于多维查询场景ES也比KV存储更为合适。这类数据通过公司统一的任务调度系统来定时调度通常几小时更新一次。这里为ES索引建立一个别名离线更新索引切别名的指向保证操作的原子性。存储在DataHub中的数据。DataHub是酒旅搜索团队开发的一套数据管理系统集数据存储、管理、使用于一体。目前支持将Hive表的数据定期导入DataHub内部主要使用Tair作为存储对客户端使用透明客户端接口支持一维和二维的Key接口对应用方基本是一致的另外应用方也不需要自行维护Tair集群配置管理了。DataHub自带调度功能通过扫描HDFS分区生成后自动写入Tair。直接存储在Tair中的数据。主要面向DataHub还不支持的两类场景一是实时数据的存储落地二是value直接存储对象存储为对象的好处是从Tair读取出来的对象可直接供线上使用无需自行序列化和赋值。实时数据无需定时调度通过Spark直接写入Tair的数据通常需要依赖上游Hive表先Ready才能执行所以通过公司统一的数据协同平台调度。推荐服务层 服务上下游 推荐上下游的架构图如下图客户端向API发起调用API调用推荐服务拿到推荐的ID再添加供App展示用的相关字段传会给App。推荐和搜索没有整合成一个服务的重要原因是推荐的召回策略复杂多样每次请求可能命中多个召回策略而搜索单次请求的意图一般比较单一通常只有一个召回策略。另外推荐服务重点在召回和过滤Rerank调用独立的rank服务原因是推荐Rerank和搜索筛选Rerank在特征上有很多是可以复用的比如用户特征、POI特征等。 整体流程 推荐服务向下从数十个数据源中获取数据经过业务逻辑处理后向上支持数十个应用场景整个调用流程如下 RecommendServicePublisher作为服务的入口从Client接到Request请求后首先验证请求是否合法比如请求参数中场景Booth和UUID不能为空。构造请求上下文Context其中会生成唯一的global ID标识一次请求根据UUID查询用户画像服务获取常驻城市根据定位的经纬度查询定位城市以及根据ABTest分流配置获取处理请求的召回排序Strategy。根据请求场景的Booth获取对应的Handler默认使用统一的AbstractHandler即可包括召回、过滤、rerank、post rerank。对Handler返回的结果做包装增加召回和排序策略名称、得分等最终返回给Client。核心流程与模型 Handler是整个流程的核心其调用流程如下 Handler根据不同的Strategy获取对应的SelectRule集合一个场景Booth可能对应多个Strategy跟ABTest对应比如Baseline就是一个Strategy。每个Strategy可能有多个SelectRule比如Baseline策略由历史行为强相关SelectRule、Location-Based SelectRule、热销Rule等组成。召回每个SelectRule又对应多个Selector多个Selector通过线程池并发获取结果比如Location-Based Rule可以细分为基于周边热销POI召回和基于周边用户购买POI召回。Selector可再做抽象比如分本异地场景的城市热销策略美团和点评双平台都需要只是数据源稍有不同另外对于从ES和DataHub获取的数据可以加Cache。Merge去重多个召回策略的结果需要Merge去重比如早期没有Rerank时Location-Based策略固定在2、4、6位。过滤具体有两级过滤一级是针对SelectRule的比如针对历史行为强相关策略中基于浏览行为和收藏行为召回的结果都需要过滤用户已购买过的POI另一级是针对所有策略通过的过滤比如黑名单、旅行社代理商。重排序对于POI列表调用POI Rerank服务对于Deal列表调用Deal Rerank服务。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年加入美团参与美团早期数据平台搭建先后负责平台、酒旅数据仓库和数据产品建设目前在酒旅事业群数据研发中心重点负责酒店旅游场景下的搜索排序推荐、数据挖掘工作致力于用大数据和机器学习技术解决业务痛点提升用户体验。
