1. 起源

• 啤酒与尿布的故事：年轻爸爸去超市买尿布的时候，通常也会买啤酒犒劳自己，于是在尿布旁边推荐啤酒，是最古早的推荐算法
• 20世纪90年代就有推荐系统了，但是出现在各大互联网公司中流行起来，也不过近几年的时间

2. 推荐系统现状

• 推荐系统本质是一个信息过滤系统，层层过滤后，从庞大的物料库中筛选几个用户可能感兴趣的物品

  
  
• 哪里有海量信息，哪里就有推荐系统，一般分为两类场景：
  （1）基于用户维度的推荐：根据用户的历史行为和兴趣进行推荐，一般放在首页推荐。比如一位年轻的爸爸在浏览商品，可能会推荐尿布
  （2）基于物品维度的推荐：根据用户当前浏览的物品进行推荐，一般放在商品详情页最下面推荐。比如用户正在浏览尿布，可能会推荐啤酒

3. 搜广推的异同

• 搜广推指的是：搜索、广告、推荐
  （1）搜索：有明确的搜索意图，搜索出来的结果和用户的搜索词相关。
  （2）推荐：不具有目的性，依赖用户的历史行为和画像数据进行个性化推荐。
  （3）广告：借助搜索和推荐技术实现广告的精准投放，可以将广告理解成搜索推荐的一种应用场景，技术方案更复杂，涉及到智能预算控制、广告竞价等。

4. 推荐系统架构

（1）数据源：推荐算法所依赖的各种数据源，包括物品数据、用户数据、行为日志、其他可利用的业务数据、甚至公司外部的数据。
（2）计算平台：负责对底层的各种异构数据进行清洗、加工，离线计算和实时计算。
（3）数据存储层：存储计算平台处理后的数据，根据需要可落地到不同的存储系统中，比如 Redis 中可以存储用户特征和用户画像数据，ES 中可以用来索引物品数据，Faiss 中可以存储用户或者物品的 embedding 向量等。
（4）召回层：包括各种推荐策略或者算法，比如经典的协同过滤（Collaborative Filtering，CF），基于内容的召回，基于向量的召回，用于托底的热门推荐等。为了应对线上高并发的流量，召回结果通常会预计算好，建立好倒排索引后存入缓存中。
（5）融合过滤层：触发多路召回，由于召回层的每个召回源都会返回一个候选集，因此这一层需要进行融合和过滤。
（6）排序层：利用机器学习或者深度学习模型，以及更丰富的特征进行重排序，筛选出更小、更精准的推荐集合返回给上层业务。

5. 推荐系统面临的挑战

（1）标准化的数据集可以很容易使得模型收敛，而线上环境的数据是非标准化的，因此涉及到海量数据的收集、清洗和加工，最终构造出模型可使用的数据集。
（2）复杂且繁琐的特征工程，都说算法模型的上限由数据和特征决定。对于线上环境，需要从业务角度选择出可用的特征，然后对数据进行清洗、标准化、归一化、离散化，并通过实验效果进一步验证特征的有效性。
（3）算法复杂度如何降低？比如上面介绍的 Item-CF 算法，时间和空间复杂度都是 O(N×N)，而线上环境的数据都是千万甚至上亿级别的，如果不做算法优化，可能几天都跑不出数据，或者内存中根本放不下如此大的矩阵数据。
（4）实时性如何满足？因为用户的兴趣随着他们最新的行为在实时变化的，如果模型只是基于历史数据进行推荐，可能结果不够精准。
（5）因此，如何满足实时性要求，以及对于新加入的物品或者用户该如何推荐，都是要解决的问题。
（6）算法效果和性能的权衡。从算法角度追求多样性和准确性，从工程角度追求性能，这两者之间必须找到一个平衡点。
（7）推荐系统的稳定性和效果追踪。需要有一套完善的数据监控和应用监控体系，同时有 ABTest 平台进行灰度实验，进行效果对比。

参考

• 搜索推荐技术的过去现在和未来：https://zhuanlan.zhihu.com/p/45878653
• 被“推荐系统”虐的日子，太惨了... https://www.modb.pro/db/33035