推荐系统相关知识

一、推荐系统相关

1、简介

推荐系统是利用电子商务网站向客户提供商品信息和建议，帮助用户决定应该购买什么产品，模拟销售人员帮助客户完成购买过程。个性化推荐是根据用户的兴趣特点和购买行为，向用户推荐用户感兴趣的信息和商品。随着电子商务规模的不断扩大，商品个数和种类快速增长，顾客需要花费大量的时间才能找到自己想买的商品。这种浏览大量无关的信息和产品过程无疑会使淹没在信息过载问题中的消费者不断流失。 为了解决这些问题，个性化推荐系统应运而生。个性化推荐系统是建立在海量数据挖掘基础上的一种高级商务智能平台，以帮助电子商务网站为其顾客购物提供完全个性化的决策支持和信息服务。

2、推荐类型

猜你喜欢

沉溺

搜索推荐

3、推荐系统核心

在合适的场景下给用户匹配最合适的信息

用户角度：用户面对海量的信息，如何选出自己最想要的信息。

信息（物品、视频…）角度：如何把信息精确到匹配到某类用户。

平台角度：如何提高平台的uv、pv、留存、转化等。

推荐系统是一个实现三赢的方法

4、衡量推荐系统的优劣

• 用户满意度

  也就是加完这套推荐系统后用户的的满意度，这个指标可以通过用户调查问卷等形式得到，但值得注意的一点是获得指标的方式方法也有可能降低用户的满意度。

• 预测准确率

  就是我们预测结果的准确度。一般情况下在TopN预测时我们计算召回率和准确率；在评分等预测时用MAE或RMSE

• 覆盖率

  代表推荐的事物对全部事物的覆盖情况，可以用来判断推荐系统是否有马太效应。马太效应是出自《圣经 马太福音》的一个典故， 社会学中的一种强者越强弱者越弱的现象，也就是说推荐系统是否会使被关注的事物更加被关注，被忽视的事物更加被忽视。 常用的协同过滤就有马太效应。比较简单的指标就是信息熵。

• 多样性

  判断推荐结果是否覆盖用户各个兴趣点

• 新颖性

  例如不应该推荐用户已经看过的电影等，应该多推荐给用户用户不知道的商品。比如一个朋友买了5L的洗衣液， 应该几个月都不需要洗衣液了，但如果电子商务平台还是想推荐洗衣液，这就是一个新颖性不够的推荐。假如用户买了 一台电脑，新颖性高的推荐是向他推荐一些外设，而不是另一台电脑。

• 惊喜性

  用户对推荐的商品之前没有兴趣，但用过之后很满意。

• 信任性

  这个是网站运营方面的，推荐是不是受用户信任，例如用户相比百度搜索的推广推荐更信任淘宝网的商品推荐

• 健壮性

  是否能承受住攻击和刷分（就是使用一些手段使自己的商品优先被推荐）等现象

• 商业目标

  该推荐系统上线后商业目标完成情况，如业绩提升、销量增加等等

5、需要推荐系统的场景

中国男足在世界杯预选赛上一路高歌猛进，有杀入世界杯之势。过几天晚上有场关键的比赛，你考虑到要尽情享受足球之夜，看球时嘴不能闲着，还需要买点零食边看球边吃。这里你有三个选择： 1.到楼下的小超市或便利店买零食。你飞快的走到零食货架，从十几种零食中选了一种你爱吃的。 2.去离你最近的大超市家乐福买零食。家乐福有三层，有上千种商品在出售，你蒙了，还好漂亮的店员小姐告诉你，你需要的零食在二楼的零食区的非膨化食品货架有卖。 3.作为一个宅男，你怎么可能下楼去买东西，你机智的拿出手机，打开淘宝，淘宝上有无数的商品出售， 即使在分类的零食区也有数不尽的网页，还好你很机智，在搜索栏输入了你想要的零食，马上你找到你想要的零食。

1）用户面临海量物品不知道该如何选择时。比如淘宝购物、拼多多。

2）海量信息需要用户沉溺进去，欲罢不能。比如：抖音、今日头条、快手

3）搜索关键词，期待平台给出最合理的答案，比如这种搜索，如你要买一个小米手机，你去搜小米会出来的是手机，而不是米

6、推荐系统的演变

1）从物品角度出发

1.平台刚建立起来时：此时可能只有少量的商品进入平台，那此时主要是是要靠一些策略吸引用户，比如满减、免单、热门推荐等，靠吸引眼球来引流。
2.平台运行了一段时间后，此时物品数量越来越多，用户与物品的交互也越来越频繁，那么简单的如热门推荐，并不适合个性化的目标，使得用户体验差。此时可以基于用户行为数据上一些简单的机器学习算法。
3.平台成熟后，海量数据产生，TB、PB的用户行为数据随之而来。可以上一些复杂的机器学习模型如：深度学习、集成学习等。

2）从用户角度出发

1.平台刚建立起来时：只有少量的用户注册，用户面临也是不多的商品，可能需要基于如线上导购，逼入传统的电视购物。
2.平台运行了一段时间后，用户数据量逐渐增大，物品也逐渐增多。用户与用户之间的相似性突出，比如喜欢运动的男生a,男生b，两个人都购买过 蛋白粉、鸡胸肉、鸡蛋，但是a多买了一个哑铃，那么可以推荐给b哑铃。
3.平台成熟后，海量数据产生，TB、PB的用户行为数据随之而来，此时用户的兴趣是多峰的，用户可能既喜欢运动、也喜欢音乐等，此时需要靠一些更加厉害的模型进行挖掘。

7、推荐系统的流程

8、推荐系统开发与传统开发的区别

传统App开发：注重的是构建一个稳定的系统，如处理高并发、负载、功能开发等，保证用户使用流程，不会因为高并发卡主，不会因为功能bug用不成，如王者荣耀、淘宝。

推荐系统的开发：更注重的是用户的使用后的导向，如使用后的留存、转化等，是一种内容上的开发。是一种成长系统的开发。

二、推荐系统架构

1、推荐系统数据源

1）用户画像 u

1.基于固有属性的用户属性：性别、年龄、手机型号、地区。
2.基于用户的兴趣标签：购物、教育、影音。
3.用户的行为标签，近期购买的物品，浏览记录。
4.定制化标签：群体属性（聚类）。

2）物品侧特征 i

1.物品id类特征：物品在数据库中的主键
2.物品的一级、二级、三级品类：衣服、T恤、supremeT恤
3.物品的特征性：产地、店铺、商家信誉、图片

3）上下文信息 c

1.用户购买物品的时间：是否节假日，是否促销日，早、中、晚、深夜
2.用户的购物状态：是否刚还完花呗、是否信用额度提升
3.用户购物的地点：家里、公司、学校等

《

其核心是确定最优的f(u,i,c)

eg：

f(广坤、乡村爱情、在家)=0.8
f(广坤、菊次郎的春天、在电影院)=0.4

》

2、推荐系统架构背景

随着互联网的深入发展和产品布局的多元化，越来越多的企业通过提供快节奏的产品及服务消耗用户的碎片化时间，从而赢得用户的青睐。这类产品通过便捷的UI交互来跟用户进行实时互动，在极短的时间内给用户 “奖赏” （及时反馈），让用户欲罢不能，根本停不下来。这类产品普遍用到的一个技术就是实时个性化推荐技术。 相比于传统的个性化推荐每天更新用户的推荐结果，实时推荐基于用户最近几秒的行为实时调整用户的推荐结果。实时推荐系统让用户当下的兴趣立刻反馈到了推荐结果的变化上，可以给用户所见即所得的视觉体验，它牢牢地抓住了用户的兴趣，让用户沉浸在其中。实时推荐技术大量用于现在的主流产品上，基本上常用的互联网APP的核心推荐算法都已经实时化了，包括头条、淘宝、快手、B站等等，毫不夸张地说实时推荐是推荐系统未来的发展趋势。

3、推荐系统架构

1）召回阶段

从海量物品中筛选出和用户直接相关或间接相关的物品，将原始数据从百万、 亿级别控制在万、千个物品。再召回的算法和策略一般都是比较简单，实时性较强的算法。

2）排序阶段

基于一些复杂的算法将召回阶段筛选出来的万、千个物品继续缩小范围到几百个。

3）重排阶段

过滤掉重复推荐的、已经购买或阅读的、已经下线的物品，当召回和排序结果不足时，需要使用热门物品进行补充，最后合并物品基础信息，将包含完整信息的物品推荐 列表返回给客户端。

4、Lambda架构

目前的主流大数据平台一般将用户行为日志分为离线部分和实时部分-lambda架构。离线部分进入数仓供离线任务进行处理，包括各种按天统计的报表、T+1的推荐业务(非实时推荐，一般每天更新一次)。实时部分一般进入消息队列(如Kafka)，供实时处理程序消费，如各类实时监控、大屏展示报表等

5、Lambda优缺点

Lambda架构历经多年发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体规划。将实时计算和离线计算高峰分开，可以极大化利用服务器资源，减少对用户的影响，这种架构支撑了数据行业的早期发展，但是它也有一些缺点，这些缺点导致 Lambda架构不适应部分数据分析业务的需求。

具体缺点如下：

1.实时与批量计算结果不一致引起的数据口径问题

因为批量和实时计算走的是两套计算框架， 使用的是不同的计算程序，算出的结果往往不同，特别是对于那些累积的指标，时间长了容易产生误差。因此，需要一套完善的机制来保证计算的一致性，纠正数据偏差。

2.批量计算在计算窗口内，存在无法算完的风险

在大数据时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口用于离线计算，已经无法完成白天20多个小时累计的数据计算。 怎么保证早上上班前准时出数据报表已成为大数据团队头疼的问题。集群之间不同作业之间的依赖关系及资源占用等更加剧了这种情况的发生。

3.数据源变化都要重新开发，开发周期长

每次数据源的格式变化，业务的逻辑变化都需要针对 ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。

4.服务器存储大

数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大了服务器存储压力。

6、Kappa架构

Kappa架构通过剔除Lambda架构中的批处理部分简化了Lambda架构。为了取代批量处理， 数据只需通过流式计算系统快速加工处理。Kappa体系结构中的规范数据存储不是使用类似于 SQL的关系数据库存储，而是一个只能追加数据的不可变日志系统。从日志中，数据通过计算系统流式传输，并输入辅助存储器作为字典库供服务使用。

典型的Kappa架构如下图：