清澈如初|个性化推荐算法(推荐系统)概要(13)


  1. 推荐算法工程落地是否一定需要排序模块
工业上的推荐算法一般分为召回和排序模块 , 召回的作用是从全量标的物集合(几万甚至上亿)中将用户可能喜欢的标的物取出来(几百个) , 排序阶段将召回的标的物集按照用户点击的可能性再做一次排序 。 但是排序阶段不是必须的 , 特别是对于标的物池不大的产品及团队资源较少的情形 , 没必要一开始就开发出排序框架 。 召回算法一般也会对标的物做排序(如果是评分预测模型 , 如矩阵分解 , 可以按照评分大小排序 , 如果是概率模型 , 可以按照对标的物的偏好概率大小排序) 。 缺失了排序模块的推荐系统可能精准度没有那么高 , 但是工程实现上相对更加简单 , 可以快速落地上线 。 特别对于刚做推荐系统的团队 , 可以让系统快速上线 , 后面再逐步迭代 , 补全缺失模块 。
  1. 推荐算法服务于用户的两种形式
推荐算法计算出的推荐结果可以直接插入数据库(如Redis等) , 直接为用户提供服务 , 另外一种方式是将核心特征计算好存储下来 , 当用户请求推荐业务时 , 推荐web服务通过简单计算将特征转化为最终给用户的推荐结果返回给用户 。 这两种方式一个是事先计算好 , 拿来就用 , 另外一种是准备好核心数据 , 在请求时实时计算最终结果 。
我拿餐厅服务外卖来类比说明 , 第一种方式是将餐厅有的菜先做好很多份 , 如果有外卖单过来 , 直接将做好的送出 。 第二种是将所有的配菜都准备好 , 接到外卖单立马将配菜加上调料炒熟再送出去 , 只要配菜准备足够好 , 炒菜的时间不太长并且可控 , 也是可以很好的服务用户的 。 第一种方式是事先做好的 , 无法满足用户个性化需求 , 同时如果做好了没人点的话就浪费了 , 第二种可以更好满足用户个性化需求 , 比如用户说不要香菜多放辣椒就可以在现做的时候满足 。
第二种方式对整个推荐系统要求更高 , 服务更加精细 , 但是第一种方案更加简单 , 不过也需要更多的存储资源(将所有用户的推荐结果事先存下来) 。 在推荐系统构建的初级阶段建议采用方案一 。
某些推荐业务用方案一是不可行的 , 比如上面的笛卡尔积范式的推荐系统 , 因为用户数乘以标的物数是一个巨大的天文数字 , 公司不可能有这么多的资源将每个用户关联的每个标的物的推荐结果事先计算好存储下来 。
  1. 推荐系统评估
推荐系统是服务于公司商业目标的(盈利目标 , 提升用户体验、使用时长、DAU等 , 最终也是为了盈利) , 所以推荐系统落地到真实业务场景中一定要定义推荐系统的优化目标 , 只有目标具体而清晰 , 并可量化 , 才能更好的通过不断迭代优化推荐效果 。 大家可以参考《推荐系统的商业价值》 , 了解怎么定义推荐系统的商业指标 。
参考文献: