推荐系统
2019-11-11 14:06:45 11 举报AI智能生成
产品设计 推荐系统
作者其他创作
大纲/内容
目标
用户满意性：准确率
多样性：权重高低都要兼顾
新颖性：推荐列表去掉用户之前有过行为的那些内容
惊喜度：和新颖性类似，不同点在于用户既没有看过，和他之前的行为也不相关，但用户看到后的确是喜欢的
实时性：用户的兴趣会随着时间而改变
推荐透明度：让用户知道推荐此内容的原因（如"买过这本书的人同时也买过"、"与你购买过的xx商品类似"）
覆盖率：挖掘长尾内容，覆盖到的内容越多越好
方式
热门推荐：即热门排行榜的概念，效果最好，推荐的物品曝光率比较高
人工推荐：一些热点时事，如世界杯、NBA总决赛等，就需要人工加入推荐列表
相关推荐：有点类似于关联规则的个性化推荐（在你阅读一个内容的时候，会提示你阅读与此相关的内容）
个性化推荐：基于用户的历史行为做出的内容推荐
是机器学习应用的一个典型场景，在本质上和搜索引擎是一样的，同样是为了解决信息过载的问题
搜索引擎某种意义上也是一个个性化推荐系统，但是其输入特征是可以从搜索关键字直接可以得到的
一般的推荐系统，输入特征则是需要机器学习才能得到
个性化推荐系统一般由三部分组成
日志系统：推荐系统的输入源，是一个推荐系统所有信息的源头
推荐算法：推荐系统的核心，根据输入数据得出最终的推荐结果的具体过程
基于内容
根据内容本身的属性（特征向量）所作的推荐
缺点：如果只做基于内容的推荐算法，推送的内容就会越来越趋于单一，信息源越来越窄（如今日头条，浏览过几次娱乐新闻之后，再打开今日头条会发现，满屏都是娱乐新闻了，想找科技类文章，会发现无从找起）
基于关联规则
一种动态的推荐，能够实时对用户的行为作出推荐
是基于物品之间的特征关联性所做的推荐，在某种情况下会退化为物品协同过滤推荐
协同过滤推荐
与基于关联规则的推荐相比，是一种静态方式的推荐
是根据用户已有的历史行为作分析的基础上做的推荐
可分为
物品协同过滤
用户协同过滤
基于模型的协同过滤
基于距离的协同过滤
基于矩阵分解的协同过滤，即Latent Factor Model(SVD)
基于图模型协同，即Graph，也叫社会网络图模型
内容展示UI：权衡推荐结果如何展示，以更好地满足推荐系统的目标，并能更好地收集用户地行为信息
典型架构
在线业务系统的日志接入数据高速公路，再由数据高速公路迅速运转到离线数据处理平台和在线流计算平台
离线数据处理平台周期性地以批处理方式加工过去一段时间的数据，得到人群标签和其他模型参数，存放在高速缓存中，供在线业务系统使用
与此同时，在线流计算平台实时对线上的日志数据做处理，对离线计算出的数据进行补充、修正等
；在线业务系统综合离线特征和在线特征使用一定的逻辑得到输出供业务使用，产生的日志流入数据高速公路
典型流程
模块组成
用户行为日志
此部分主要是用户行为日志的存储，属于数据统计的一部分, 存储在hive中
数据ETL-1
将用户日志转换为推荐算法所需要的数据格式
对原始的用户行为等数据进行清洗、加工，如字段、属性、格式化等，作为下一步推荐算法的输入
推荐算法
是个性化推荐系统最主要、最核心的部分，包括通过用户行为计算相关内容以及推荐结果等
流行算法
基于内容和用户画像的推荐
基于矩阵分解的推荐
基于SVD/ALS算法对用户进行内容推荐（相比起SVD，ALS更加适合解决稀疏矩阵的问题）
Spark mlib中已经集成了对als算法的实现，需要做的就是在etl-1中把数据转换为als需要的数据格式以及调整als算法的各种参数
用户&物品协同过滤推荐
包括UserBased CF和ItemBased CF
对于这两者，需要根据业务的不同来选择不同的算法
当用户非常多的时候，考虑到维护用户矩阵的成本，一般是不推荐选择用户协同过滤的
而对于候选item很多的时候，则不推荐使用物品协同过滤
输出结果
一般是一个用户对应一个item列表，或者是一个item对应一个item列表
此部分主要考虑的是算法的时间复杂度，不管是哪一种算法，一旦用户或者内容数据上了百万级别，都需要通过分布式计算如MapReduce、Spark等来进行解决
基本流程
数据ETL-2
将推荐算法得到的结果进一步加工为存储模块的输入数据
具体来说，对推荐算法产生的结果进行清洗、格式化等，作为下一步存储模块的输入
用户画像存储
存储用户的偏好以及行为数据等信息，如对内容关键字的偏好、点击过哪些内容等
对于偏好，采用标签量化来表示，是一种随着时间衰减的值
对于用户画像，是批量写入、实时读取，所以存储要着重考虑读的性能
可使用Redis或Hbase技术
可以选择使用Redis集群作为技术方案，能够最大满足读的性能，缺点是Redis的成本昂贵且不支持auto index
也可使用Hbase作为存储，使用ElasricSearch构建二级索引，以应对根据多种维度聚集用户的需求(比如过滤某一个标签下的所有用户)
推荐结果存储
存储各种推荐算法产生的推荐结果
可以分为两部分
{用户 : itemList}推荐结果，为用户推荐的内容列表
{item : itemList}推荐结果，与item相关的内容列表
存储空间要求大，格式复杂，对于存储的容量和读写性能要求都比较高（可以选择使用Redis集群作为此部分的存储方案）
服务调用模块
整合用户画像和推荐结果两部分数据，向外提供推荐调用的接口（主要是数据库IO调用开销）
步骤
根据用户id，获取推荐的item列表
根据item，获取相关联的item列表
根据item，获取相关联的item列表
该模块需要采取一定的策略聚合多种推荐算法的推荐结果，直接面向业务（策略由于会随着面向的业务不同而不同，需要可配置化）
同时也提供对外暴露用户画像的接口，使得业务方可以使用用户画像做针对性的处理。可以采用RPC机制对外暴露服务接口
需要考虑的问题
实时性问题
由于计算用户、item矩阵或者进行矩阵分解是需要离线进行且比较耗时，因此协同的推荐算法是很难达到实时性的
实时部分的推荐主要依靠基于用户画像的推荐来进行
最终的推荐列表是根据一定的策略对这两部分进行聚合的结果
时效性内容问题
时效性内容指的是那些与时间强相关的内容（如新闻、时事等），如果一条10天前xx球员获得冠军的新闻现在被推荐了出来，可想用户肯定是莫名其妙或者是很失望的
因此，对于时效性内容，需要与普通的待推荐的内容区分开，做单独的推荐或者不走个性化推荐
冷启动问题
当用户是新用户，如何给用户推荐item？
对于新用户，可以采取的一种策略就是采用热门推荐或者人工推荐，把绝大多人关心的内容推荐出来
当内容是新内容，如何推荐给用户？
对于内容，可以将内容分为新内容池和待推荐内容池
新内容产生时，首先进入新内容池
每次推荐的时候，先从新内容池做候选推荐，并给此内容的传播度+1，直到其传播度大于一个阈值的时候，将其移至待推荐内容池
这样既可以解决新内容的冷启动问题，也在一定程度上可以保证新内容的曝光量
多样性问题
在基于用户画像的推荐算法中，取出用户的多个标签，然后根据相关度从不同的标签中取不同数量的内容，这样既兼顾了用户的多种兴趣也能够在一定程度上解决多样性的问题
如：用户具有tag:A B C D,相关度为wA wB wC wD，Total推荐为总共需要推荐的条数，那么
RecommendList(u) = A[Total推荐 * wA] + B[Total推荐 * wB] + C[Total推荐 * wC] + D[Total推荐 * wD]
内容质量&内容排序
当用户对内容的喜好不一样，可以按照兴趣度来排序
但当无法区分兴趣度的时候(如：用户是新用户，内容都是新内容，用户对于某一标签下的内容兴趣度一样)，可以使用内容质量来做排序
click/pv是一种评判内容质量的方式。此外，使用卷积神经网络相关算法也可以构建内容质量模型
惊喜问题
推荐系统的惊喜目标一直是一个难题，被称作EE(Exploit & Explore)问题
bandit算法是解决这个问题的一个派系，就是估计置信区间的做法，然后按照置信区间的上界来进行推荐，以UCB、LinUCB为代表的
简单点说就是先不考虑你喜不喜欢就把质量高的内容推荐给你，后面根据用户的行为反馈对推荐内容作调整
具体的可以参见此篇文章：推荐系统的苟且和远方
总结
实力派的【算法工程师】往往都是ABC[always be coding]，这样的算法工程师才能根据实际问题建立模型或者建立规则库，是真正能解决问题的人。往往是一些有研究背景，经验丰富的研究员，更加重视工程，因为工程架构上一些恰当合理的设计，效果往往就能远远高过于模型算法优化
学院派的【算法工程师】往往是为了算法而算法，而不是为了解决推荐系统的问题去找最适合算法。这也是为什么大公司经常招了一些博士毕业的算法工程师后，不是研究算法而是让他们整天在那看数据报表？【因为发现算法没啥好研究，只能让他们在那看看报表找找规律了】
几乎所有所谓的智能推荐算法都是花拳绣腿
当一个做推荐系统的部门开始重视【数据清理，数据标柱，效果评测，数据统计，数据分析】这些所谓的脏活累活，这样的推荐系统才会有救
基于用户
基于全平台同一属性的相关用户（如A和B都喜欢看经济类新闻，但A除了经济之外，还看政治类新闻，那么是否可以考虑给B也推荐相关的政治新闻呢？）
这种推荐逻辑算法复杂程度远远高于基于内容的推荐，当下大部分的内容型产品，主要使用的还是基于内容推荐的算法逻辑，即使以"智能推荐"标榜的今日头条也不例外
但是有理由相信，基于用户的推荐算法有朝一日必然能够成熟并投入使用，只是时间长短的问题
0 条评论
下一页
