为什么需要推荐系统
“啤酒与尿布” 的故事相信很多人都听过，年轻爸爸去超市购买尿布时，经常会买点啤酒犒劳自己。因此，沃尔玛将这两种商品进行了捆绑销售，最终获得了更好的销量。
这个故事背后的理论依据就是 “推荐算法”，因为尿布和啤酒经常出现在同一个购物车中，那么向购买尿布的年轻爸爸推荐啤酒确实有一定道理。
随着移动互联网的发展，越来越多的信息开始在互联网上传播，产生了严重的信息过载。因此，如何从众多信息中找到用户感兴趣的信息，这个便是推荐系统的价值。精准推荐解决了用户痛点，提升了用户体验，最终便能留住用户。
推荐系统本质上就是一个信息过滤系统，标签系统属于一种最简单的推荐系统，在冷启动场景应用也会有不错的效果。现代化推荐系统，可以简单分为：召回、排序、精排3个环节，每个环节逐层过滤，最终从海量的物料库中筛选出用户可能感兴趣的物品。
我们常见的APP都涉及到推荐功能：
- 资讯类：今日头条、腾讯新闻等
- 电商类：淘宝、京东、拼多多、亚马逊等
- 娱乐类：抖音、快手、爱奇艺等
- 生活服务类：美团、大众点评、携程等
- 社交类：微信、陌陌等
更多有关通用推荐系统的信息可以阅读另一篇文章： 什么是推荐系统
陌生人社交场景里的推荐系统
推荐系统在社交领域更多的还是基于陌生人交友的推荐场景中，很快你会发现和资讯类、电商类、娱乐类推荐系统不同的是，基于陌生人社交的推荐系统中推荐的物料和用户画像是重合的，我们要做的是把用户画像中的人推荐给用户，实现用户之间的匹配。
于是陌生人社交的重点就是在构建用户画像了，用户画像的粒度越细，在推荐算法的匹配的效果就会越好。所以在产品的设计中，不断的去完善推荐中所需要的重要特征数据。这些用户画像中的特征，都将会用在召回、排序的模型中。
从过往的产品发展历史来看，很多陌生人社交产品最后会发展成约炮、恶意骚扰的工具。我们也需要针对这一问题，提出并整理避免陌生人社交产品发展跑偏的措施，并整合到推荐系统中，实现社区的净化避开陌生人社交的雷区。
如何构建用户画像
构建用户画像的主要工作其实就是给用户贴上各种“标签”，推荐算法就是通过各种标签来实现推荐能力的。用户画像我们可以从3个方向进行思考与构建：
-
一是用户主动提交的信息。
- 年龄、星座、身高、体重、籍贯、常住地、地理位置定位
- 学历状况、婚姻状况、工作、收入水平、资产情况
- 生活习惯、消费偏好、品牌偏好、使用频率
-
二是用户在平台的行为属性。
- 历史付费能力
- 回复率
- 活跃程度
- 登录频率等等
-
三是分析建模、聚合归纳。我们可以尽可能多的收集用户信息，并进行总结归纳：
- 用户的动作：需要深入用户群体，去了解用户在做哪些事情
- 留下的信息：用户只要做了事情，就肯定会有痕迹，不管是浏览、关注、点赞还是评论都属于用户信息。
- 总结特征：对用户的动作、线索进行总结归纳，通过特征工程等方式可以得出用户的各种特征。例如一线城市的人群消费能力比较强、三线城市的人群相亲需求更强烈等等。
算法引擎中的召回排序
推荐系统的算法引擎如何根据已有的用户画像去推荐，涉及到两个关键问题：召回 和 排序。
- “召回（match）” 指从全量信息集合中触发尽可能多的正确结果，并将结果返回给“排序”。
- 而“排序（rank）”则是对所有召回的内容进行打分排序，选出得分最高的几个结果推荐给用户。数据量大的情况下会先进行一次粗排再进行一次精排，数据量小的情况可以直接进入精排。
社交系统的常见召回策略一般有以下几种方式：
- 基于高质量用户的召回
- 基于用户画像兴趣、标签的召回
- 基于同城同省、距离的召回
- 基于User的协同过滤召回
- 基于Item的协同过滤召回
在排序方式上常见的一般有以下几种方式：
- 对高颜值用户提权
- 对实名认证的用户提权
- 对高回复率用户提权
- 对高付费率用户提权
- 对附近的用户提权
- 对vip用户提权
- 对实时在线用户提权
当然除了上文的提权策略，还会有降权策略，包括但不限于：
- 基于日匹配数量上限进行降权
- 根据实时用户在线状态进行降权（例如正在聊天、正在视频电话）
- 对低质量用户、脚本机器人、黑产行为降权
召回与排序策略中除了会用到标签系统、用户画像等信息，根据实际应用场景还会涉及特征工程、机器学习、深度学习等技术的融合。这一阶段还需要考虑用户冷启动问题、推荐实时性问题、个性化推荐问题、流量均衡问题、推荐效率问题以及用户隐私问题等等。
推荐系统在整个召回排序过程中做了很多的干预，但是对于用户相对来说，其实还是一个黑盒子，虽然提供了一些匹配推荐过程可解释的特征，但是社交始终是一个主动的过程，主要还是看当事人的心情与状态，推荐算法的只是尽最大可能把两人引向能够产生交集的点，双方都有话可说，有事可做，迈出了第一步就是一个好的开始。
核心模块与架构设计
架构设计要求架构师具备软件和硬件的功能和性能的过硬知识，实际生产开发中，架构设计其实需要根据当前实际情况作出的妥协与优化，一个推荐系统在不同的时期、不同的数据环境、不同的应用场景下会有不同的架构设计。
这里介绍一下通用的推荐系统架构设计，如下图所示
在线服务：
在线服务需要统筹整个推荐流程的调度与组合，包括算法的触发、频率控制、用户画像数据整合、上下文关联、业务逻辑干预、召回与排序、信息的拼接展示和AB实验。各种算法的结果、用户画像的结果、用户兴趣模型的结果等在这里都会被串联起来。在线服务层的逻辑会稍显复杂，建议配合一个流程引擎来实现梳理的功能。
数据平台：
数据平台主要是对用户数据和算法模型数据进行整合与存储，并提供高性能的api查询能力，计算平台统计的特征数据根都会沉淀到数据平台。特征数据根据实时性分成两种类型：离线特征和实时特征，特征数据具有数据量大的特点，基于此特点，需要选择合理的数据处理技术和存储介质。
- 针对离线数据，主要需要结合大数据技术，通过一些分布式数据库来实现数据的部署，对于初级的推荐服务建议直接使用业内比较成熟的MongoDB或者Elasticsearch来作为数据存储介质。两者都具有比较弹性的数据存储扩展性。
- 针对实时数据，例如用户的实时行为，主要需要结合流式计算相关技术，例如通过Kafka的流平台，使用Spark Streaming、Flink或者Storm等来进行流式计算，考虑到实时性和数据的吞吐量，存储的方式可以直接使用Reedis这类缓存存储来实现，根据不同阶段使用的特征，进行了不同的处理，如用户偏好反馈、实时用户特征数据等。
业内基于数据平台的发展，数据管理工具也得到了飞速的发展，从数据库、数据仓库、数据集市与数据湖，再到大数据平台与如今的数据中台。不同的时期、不同的场景推荐系统的架构设计会有不同的组合与形式。
写在最后
本文主要从推荐系统的工程架构方面和大家分享了一些较基础的技术方案，当然详细的推荐系统远不止文章中这近千个文字可以表述完整的，这里也只是抛砖引玉，各位看官如果有问题、建议或者新的看法，欢迎留言一起探讨。
