笔者结合这道面试题，进行了一系列的思考与总结，希望对你有所启发。
怎么应对推荐系统的冷启动？
这是一道很常见的推荐策略产品经理面试题。
这个问题无论是从技术层面、商业层面、还是业务层面，都会有不同的解决方法。
最近，在做一个APP频道内的内容feed流，也遇到了冷启动问题，下面是最近思考得出的一些可行的思路。
推荐系统冷启动阶段其实也可以不那么的“冷”。
先了解一下什么是冷启动？
没有官方的定义。对于推荐系统来讲，因为需要用到用户，物品和事件三种数据，其中任何一种数据的缺失都会导致推荐系统的冷启动。当然一般都是缺用户数据。
所以冷启动最直接的原因就是缺少可用的数据。那么，解决问题的办法也是对症下药。
01
排行榜、热榜等热门效应应对冷启动。
这个是最常见的一种应对冷启思路。推荐系统的本质目的是高效连接用户和平台上的物品，就其能够达成的目标来讲可以分为两种：
为用户发现“好”的东西
为用户发现“喜欢”的东西
那么在不知道用户喜欢什么的时候，最好的办法就是把平台上的“好”东西推给用户。
如何衡量，量化一个东西的好坏。常见的做法就是依据物品的一些单品特征来计算它的热度得分，然后按照这个得分进行排序。
比如对于视频，可以采用视频的完播量/率、转发量/率、点赞量/率、评论量/率等维度的特征进行计算；对于商品，可以采用商品的销量、关注量、收藏量、加购量等维度的特征进行计算。
热门推荐适合大多数的冷启动场景，但是需要注意品类的多样性和差异性。常见的加入随机性、干预穿插、品类配比等等方式来保证最后给用户呈现结果的丰富度。
02
有一些平时看似没有用的数据，实则蕴含很丰富的信息，上下文信息就是这其中的一类。
无论你是否注册、是否登录，在你打开浏览器，或者打开APP的时候，包括你的设备信息、浏览器信息、环境信息、语言信息等等都已经自动上传到应用的数据后台了。
不同的领域对上下文信息的定义不同，但大意都是指和用户当前所处环境，场景相关的数据。
一个人在固定的设备、浏览器、环境、语言信息下的行为可能不能说明什么问题，但是当有几万、几十万甚至上百万的这样的数据的时候，那么它显现出来的一些规律性就有很大的价值了。
比如：有相关数据表明，一般在下午早上8点和下午4点上传的抖音视频会更容易获得传播。
另外，之前国外一家公司做的一个音乐推荐系统就是基于用户的国家信息来推荐不同风格的歌曲，这其实也是一种上下文信息的应用。
这可能就是统计学意义所在。
03
拿来主义在推荐系统的冷启动阶段同样适用，分为对内和对外两种：
对内
一般稍微大点企业都不会只有一条业务线，所以当面临冷启动问题的时候，不妨把眼界拓宽，看看其他业务是否有现成的数据可供对接，尤其是成熟的业务线。
在奉行拿来主义的适合，特别需要注意下面几点：
业务形态是否一致。比如同属电商业务，同属内容社区业务。
用户重合度是否足够高，这样才能保证你拿来的标签是可靠，可用的。尤其是在一个核心业务下面的垂直业务，一般用户重合度都很高。
拿来主义其实就是一种标签对接的思路，用相似的成熟业务标签来支持新业务的冷启动，这在背靠大树的企业是一种很常见的思路。比如淘宝APP、京东APP下的部分垂直频道。
对外
对外的话一般是指标签采买。需要关注两点：
采买标签的渠道需要足够垂直，尽量保证业务范畴一致；
需要验证标签的的准确性。 比如之前我们给租房业务搭建房源推荐系统，需要用户的地理位置和购买力标签，对接了一家专门做租房线上交易企业的标签。在标签验证环节，把地理位置标签与用户常用的收货地址标签进行比对，购买力标签与用户经常购买的品类的价格进行比对，在一定程度上可以剔除脏数据。
04
提升推荐系统的时效性。
这种严格来说不属于解决冷启的一种思路，但是，一定程度上能够缩短冷启的周期。
不知道大家有没有注意到当你从淘宝APP首页猜你喜欢区域点击一个商品，进入该商品的详情页，并且浏览时间比较长的时候，再返回的时候，会有一个与你刚刚浏览商品相似的商品移动上来。
我第一次发现的时候，着实被惊艳到了。
如果能提升推荐系统的时效性，甚至做到实时，那么在用户打开应用，第一次与平台的物品进行 有效交互 的时候，就已经能够产生新的推荐列表了。
这个策略的背后需要考虑的因素很多，比如有效交互的定义、接口的性能、计算的能力。
05
历史数据的复用。
成熟的业务推荐系统一般都会有一个冷启动数据池，会选择过往冷启效果比较好的物品加入到数据池以备下次冷启。
历史数据不能简单的全盘复用，需要考虑一定的过滤策略。比如当下的环境政策、业务规划、平台计划等等，尽量能够保证各方权益的平衡。
以上大概就是最近思考所得一些冷启策略，随便聊聊，希望你能有所获，也欢迎大家补充交流。
