推荐系统整体架构与算法流程详解

推荐算法的理解如果说互联网的目标就是连接一切,那么推荐系统的作用就是建立更加有效率的连接,推荐系统可以更有效率的连接用户与内容和服务,节约了大量的时间和成本 。如果把推荐系统简单拆开来看,推荐系统主要是由数据、算法、架构三个方面组成 。

  • 数据提供了信息 。数据储存了信息,包括用户与内容的属性,用户的行为偏好例如对新闻的点击、玩过的英雄、购买的物品等等 。这些数据特征非常关键,甚至可以说它们决定了一个算法的上限 。
  • 算法提供了逻辑 。数据通过不断的积累,存储了巨量的信息 。在巨大的数据量与数据维度下,人已经无法通过人工策略进行分析干预,因此需要基于一套复杂的信息处理逻辑,基于逻辑返回推荐的内容或服务 。
  • 架构解放了双手 。架构保证整个推荐自动化、实时性的运行 。架构包含了接收用户请求,收集、处理,存储用户数据,推荐算法计算,返回推荐结果等 。有了架构之后算法不再依赖于手动计算,可以进行实时化、自动化的运行 。例如在淘宝推荐中,对于数据实时性的处理,就保证了用户在点击一个物品后,后续返回的推荐结果就可以立刻根据该点击而改变 。一个推荐系统的实时性要求越高、访问量越大那么这个推荐系统的架构就会越复杂 。
推荐系统的整体框架
推荐系统整体架构与算法流程详解

文章插图
 
推荐的框架主要有以下几个模块
  • 协议调度:请求的发送和结果的回传 。在请求中,用户会发送自己的 ID,地理位置等信息 。结果回传中会返回推荐系统给用户推荐的结果 。
  • 推荐算法:算法按照一定的逻辑为用户产生最终的推荐结果 。不同的推荐算法基于不同的逻辑与数据运算过程 。
  • 消息队列:数据的上报与处理 。根据用户的 ID,拉取例如用户的性别、之前的点击、收藏等用户信息 。而用户在 App 中产生的新行为,例如新的点击会储存在存储单元里面 。
  • 存储单元:不同的数据类型和用途会储存在不同的存储单元中,例如内容标签与内容的索引存储在 MySQL 里,实时性数据存储在 redis 里,需要进行数据统计的数据存储在 TDW 里 。
用户画像用户标签标签是我们对多维事物的降维理解,抽象出事物更具有代表性的特点 。我们永远无法完全的了解一个人,所以我们只能够通过一个一个标签的来刻画他,所有的标签最终会构建为一个立体的画像,一个详尽的用户画像可以帮助我们更加好的理解用户 。
用户画像的分类
推荐系统整体架构与算法流程详解

文章插图
 
原始数据原始数据一共包含四个方面
  • 用户数据: 例如用户的性别、年龄、渠道、注册时间、手机机型等 。
  • 内容数据: 例如游戏的品类,对游戏描述、评论的爬虫之后得到的关键词、标签等 。
  • 用户与内容的交互: 基于用户的行为,了解了什么样的用户喜欢什么样的游戏品类、关键词、标签等 。
  • 外部数据: 单一的产品只能描述用户的某一类喜好,例如游戏的喜好、视频的喜好,外部数据标签可以让用户更加的立体 。
事实标签事实标签可以分为静态画像和动态画像 。
  • 静态画像: 用户独立于产品场景之外的属性,例如用户的自然属性,这类信息比较稳定,具有统计性意义 。
  • 动态画像: 用户在场景中所产生的显示行为或隐式行为 。
  • 显示行为:用户明确的表达了自己的喜好,例如点赞、分享、关注、评分等 。(评论的处理更加复杂,需要通过 NLP 的方式来判断用户的感情是正向、负向、中性) 。
  • 隐式行为:用户没有明确表达自己的喜好,但“口嫌体正直”,用户会用实际行动,例如点击、停留时长等隐性的行为表达自己的喜好 。
隐式行为的权重往往不会有显示行为大,但是在实际业务中,用户的显示行为都是比较稀疏的,所以需要依赖大量的隐式行为 。
模型标签模型标签是由事实标签通过加权计算或是聚类分析所得 。通过一层加工处理后,标签所包含的信息量得到提升,在推荐过程中效果更好 。