这个系列文章将介绍推荐系统，主要内容包括什么是推荐系统、推荐系统的架构、几个经典的推荐算法。本章会从实战的角度介绍如何从0到1打造一个离线的推荐系统、如何从0到1搭建一个实时的推荐系统。通过推荐系统可以让你更清楚什么是数据智能。
1、什么是推荐系统
推荐系统的价值是解决人货匹配的问题。以电商平台为例，作为一个电商平台，主要目的就是在线上销售商品，最需要解决的问题是把合适的商品卖给合适的用户。当电商平台的规模还很小（比如只有10个用户和50件商品）的时候，如果平台有一个运营人员就能解决所有的人货匹配问题，运营人员可以和平台的10个用户一一沟通，问清楚这10个用户到底想要哪些商品，然后在这50件单品中找到合适的商品，推荐给平台的这10个用户。当电商平台发展到一定的规模（比如1万用户，5千件商品）时，运营人员的做法就是给用户打上各种各样的标签，通过标签形成用户画像，再基于用户画像做用户分群。每个用户群都是一类人，对于高价值的用户群，一定需要特殊对待，倾斜更多的资源，甚至为这些高价值用户提供一对一的服务，这样运营效率才会最高。
当电商平台的用户数量已经突破1亿人、商品的件数突破10万件时，电商平台又该如何解决人货匹配的问题呢？解决该问题的关键还是要了解平台的每个用户究竟喜欢哪些商品。如果我们知道每个用户需要什么样的商品，就能把电商平台的10万件商品卖出去。推荐系统就是用数学的方法计算并预测用户到底需要什么商品。通过数据可以计算出用户到底会喜欢哪些商品，虽然计算结果只是一个概率，但如果我们把这个概率提高到了一定的水平，再把这些商品推荐给用户，用户就很可能购买推荐的商品。
那么，推荐系统如何计算用户到底喜欢哪些商品呢？答案就是通过用户数据。用户的数据其实分为隐性数据和显性数据两种。
隐性数据是通过埋点收集的用户行为数据。通过埋点，用户的每次浏览、点击行为都会保留大量信息：这个用户是谁、在什么时候、在什么地点、用什么设备、看了哪个商品、看了多久。这些数据对于判断用户是否对该件商品感兴趣是十分有价值的。比如一个用户连续3天都在浏览同一个商品，而且每次都浏览很久，另外一个用户则始终没有浏览这个商品，那么相比第2个用户来说，第1个用户显然对这件商品更感兴趣。
显性数据包括用户下单数据，加购数据、收藏数据等业务数据，还包括用户填的一些资料（比如用户的性别、所在地区等数据），这些数据同样可以让我们挖掘到用户的特征。对用户越了解，我们就越能精确地判断出用户会喜欢哪些商品。
对于现在的电商产品来说，推荐模块基本是标准配置，比如你在一个知名电商平台上浏览了一款苹果手机的页面，那么在该平台的“猜你喜欢”模块里，你一定能看到这款手机被排在了最前面，如图11-1所示。
图11-1 “猜你喜欢”功能
如果你之前购买过这款手机，那么这个“猜你喜欢”模块就可能向你推荐与苹果手机相关的商品，比如向你推荐一个 iPad，如图11-2所示，这会促使你继续下单。
图11-2 推荐与已购商品相关的商品
2、推荐系统架构
接下来我们从功能架构和技术架构的角度讲解推荐系统。
2.1 推荐系统功能架构
如图11-3所示，这是一个典型的推荐系统功能架构图。一个常规的推荐系统主要分为三大模块，分别为召回（也就是图上多个推荐引擎组成的部分）、过滤、排序。
图11-3 推荐系统功能架构图
1.召回
召回就是通过一定的方式找到用户可能感兴趣的商品。召回的方式有3种：①与用户喜欢的物品相似的物品；②与用户有相似兴趣的用户喜欢的物品；③基于用户的标签（用户年龄、性别等）推荐物品。
这三种方式都可以召回一定数量的商品，形成用户可能感兴趣的商品候选集。每种召回方式需要相互独立，这样当其中的一种召回方式的效果不好时，可以快速切换而相互不受影响。特别是在推荐系统上线的前期，可以让每种召回方式定义的召回算法单独运行，然后通过A/B测试的方式找到最好的推荐引擎。
2.过滤
整理候选集内的商品，通过一定的规则，过滤掉其中有问题的商品，比如用户曾经买过的商品、质量很差的商品等。
3.排序
每种召回算法都会给出一个推荐结果。推荐结果的形式基本上都是“某个用户喜欢某个商品的概率是多少”。这就会产生一个问题，比如召回算法A推荐商品a，认为用户喜欢a的概率是90%，召回算法B推荐商品b，认为用户喜欢b的概率也是90%。那么我们应该将a、b哪个商品推荐给用户呢？因为a、b是在不同的标准下推荐出来的，所以没有可比性。这就好比每个省都有一个高考状元，因为他们考试时使用的试卷是不同的，所以没办法直接评估这两个省的高考状元哪个更厉害一点，如果硬要比较，就需要再进行一个统一入学考试，看哪个状元分数更高。排序层就是为了解决这个问题，把候选集中所有的商品经过排序算法统一进行一次用户感兴趣程度的排序。
排序完成后，由数据中台的后端工程师通过接口的方式将推荐结果推送给产品线的推荐模块，由产品线的推荐模块负责推荐结果的显示。
3、推荐系统技术架构
如图11-5所示，这是一个典型的推荐平台技术架构，包含了实时推荐和非实时推荐的技术实现。
图11-5 推荐系统技术架构
（1）收集产品线的用户产生的数据，包括用户行为数据、用户业务数据，这些数据都可以作为实时推荐、离线推荐的数据源。用户行为数据通过消息队列传输到日志文件或者直接供实时推荐引擎使用。用户业务数据存储在业务数据库中，由数据中台同步到数据中台的数据仓库。
（2）执行实时层、离线层的计算任务。实时层采用流式计算框架（如Flink等）获取用户近一段时间或者近几次行为可能偏好的商品，再通过偏好的商品，从商品库中计算用户可能感兴趣的商品，形成商品候选集。离线层的计算任务一般执行一些离线算法，如基于用户的协同过滤算法、基于商品的协同过滤算法、排序算法等，离线层的计算任务偏重于根据用户的长期兴趣找到用户感兴趣的商品。
（3）整合实时推荐结果和离线推荐结果。实时推荐结果一般存储在内存数据库（如Redis）中，离线推荐结果一般存储在MySQL中。实时推荐结果和离线推荐结果会通过一定的规则整合起来，形成推送给用户的最终推荐结果。
（4）展示推荐结果。当系统前端发起请求查询用户的推荐结果（比如用户进入了“猜你喜欢”模块）时，产品线将通过接口的方式请求推荐系统，由推荐系统返回上一步整合出来的推荐结果。
4、推荐平台项目实施流程
推荐系统在数据中台中属于比较大的模块，刚开始接触时可能会觉得无从下手。推荐系统属于AI系统范畴，需要有大量的算法支撑。AI 系统需要灵活地支持各类 AI 任务，解决各类任务敏捷化过程中的需求与痛点。当前企业智能化需求各不相同，导致相应的 AI 任务种类繁多。我们可以把AI系统的任务分为两种：面向业务的AI任务和非面向业务的AI任务，如图11-6所示。
图12-6 AI任务的划分
非面向业务的AI任务是针对某个业务领域内特定的类型数据，提供对此类数据的基础 AI 学习、预测、分析能力的计算任务，例如计算机视觉、自然语言处理任务等。这种任务常常不直接解决业务需求，仅仅作为基础模型对数据进行初步加工，再由一些面向业务的任务来对接需求。这也给算法实施团队充足的时间对横向任务模型进行充分雕琢，对其敏捷性进行完善。这部分内容属于AI系统底层通用能力，笔者不再过多讨论。
面向业务的AI任务是针对业务具体需求的，比如电商领域的推荐系统以及比较常见的用户画像构建、智能问答等功能。AI项目实施的整个流程如图11-7所示。
图11-7 AI项目实施流程
首先定义需求，比如我们的推荐系统要解决人货匹配的问题；接着需要准备数据、处理数据，这个工作可以由数据中台的数据开发工程师完成；最后需要来算法工程师、标注工程师等角色共同参与开发与特征工程、模型建立及模型的效果评估等算法相关的模块。也就是说，数据中台只需增加算法团队，就可以完成AI项目的实施。
如此一来，数据中台和AI系统的关系就比较清晰了，只要补充了算法团队，推荐系统就可以成为数据中台的一部分。
