前言
说到推荐系统和搜索系统大家应该都不陌生,它们几乎是任何一个互联网的标配了。哪里有海量信息,哪里就有推荐算法和搜索算法。比如抖音、b站等娱乐类 APP 的视频推荐;淘宝、京东等电商类 APP 的商品推荐;今日头条、腾讯新闻等资讯类APP的内容推荐,以及 APP 里的搜索框供用户搜索。搜推系统本质上就是一个信息过滤系统,通常分为:召回、排序、重排序3个环节,每个环节逐层过滤,最终从海量的物料库中筛选出几十个或上百个用户感兴趣或者有意向的物料返回给用户。搜索系统与推荐系统唯一的区别在于,搜索较于推荐多了一个 query,这个 query 代表用户的明确的意图,返回给用户的 item 必须与 query 是相关的,并且比推荐系统多了 QP(query processing)环节。推荐不具有目的性,依赖用户的行为和画像数据进行个性化推荐。
推荐系统的召回
以电商为例,推荐系统的召回阶段是指根据用户历史行为和画像数据从千万或亿级别的商品库中挑选出千个或者万个用户可能感兴趣的商品,负责从海量数据中快速筛选出部分数据,供后面排序阶段使用。此阶段使用的模型较为简单,速度快,尽量保证用户兴趣的多路召回。
基于 CF 的召回
CF 算法分为 itemCF、userCF,itemCF 是根据用户曾经有过行为的商品召回这些相似的商品,userCF 是召回和该用户相似的一些用户有过行为的那些商品。
itemCF
公式:
其中, 表示用户有过行为(浏览、点赞、收藏、加购、购买)的商品集合, 表示和物品 j 最相似的 k 个物品集合, 表示物品 j 和物品 i 的相似度, 表示用户对物品 i 的兴趣。
其中物品相似度计算方法有:
- 基于商品的文本信息如商品标题,利用 word2vec 模型,计算 i2i
- 基于用户的行为信息利用 swing 算法,计算 i2i
- 基于 graph embedding,计算 i2i
用户对物品兴趣得分计算方法有,如: 根据行为类型赋予不同权重,加上时间衰减因子,计算一个线性函数分数,归一化后作为兴趣分。
userCF
需要计算的是用户之间的相似度,但用户的体量一般比商品体量大很多,所以一般建议使用 itemCF。
基于 MF 的召回
MF俗称矩阵分解,其用户行为数据可以整理成一个 user-item 矩阵,矩阵中每一行代表一个用户,而每一列则代表一个物品。若用户对物品有过评分,则矩阵中处在用户对应的行与物品对应的列交叉的位置表示用户对物品的评分值。这个 user-item 矩阵被称为评分矩阵。如下图所示:
其中的 表示用户对物品还没有评分,矩阵分解的最终目标是生成一个 user 矩阵和一个 item 矩阵,user 矩阵和 item 矩阵相乘的结果就是用户对物品的评分,以此来得到缺失的 rating。
由于 user-item-rating 矩阵往往是稀疏的,常用的矩阵分解方法如 SVD 无法使用,因此采用 ALS 方法。
ALS
ALS,将原始的大小为 的 rating 矩阵,投射到2个低秩矩阵,分别为 的用户特征矩阵和 的商品特征矩阵。 远小于 和 。
为了使 ,采用交替最小二乘法,最小化平方误差损失函数:
其中, 是 user 对 item 的评分。交替最小二乘法是指,分别对 和 求偏导,使其导数等于 0。
基于向量的召回
模型的输入为有过行为的商品序列,用户属性特征和上下文特征。离散特征乘以嵌入矩阵得到 embedding,商品序列做 avg pooling,和用户属性的 embedding 做拼接输入 DNN。输出层做 softmax,预测哪个商品会被点击。
搜索系统的召回
同样以电商为例,搜索系统的召回较于推荐系统,是从商品文本信息出发,从商品库中召回部分和 query 相关的商品,即考虑的是商品和 query 的相关度。常用的召回方法有:基于词的传统召回和基于向量的语义召回。在做召回之前,搜索系统往往会对输入的 query 进行一系列操作,保证召回的准确性和多样性,这一环节叫做 QP。
Query Processing
QP 俗称 query 理解,是对 query 的处理,在召回前一环节,对后续的召回和排序质量影响非常大。QP 模块一般分为:query 改写和 query 意图识别。
query 改写
- query 归一化:通过简单的字符串处理进行 query 改写,如去空格、大小写转换、特殊字符处理等,提升召回数量和准确性。
- query 纠错:对有拼写错误的 query 进行主动纠错,主要有 HMM、编辑距离等方法,减少误召回,提升召回数量和准确性。
- query 扩展:根据 query 语义或意图进行拓展,并与源 query 一同进行检索,进而丰富搜索召回的结果。
query 意图识别
目的是提升搜索准确性:
-
query 类目预测:提升召回的准确性。通常有基于统计和基于内容的方法:
1.1 基于统计:类似协同过滤中求 i2i 的方法;
1.2 基于内容:无监督方法可以通过贝叶斯统计、互信息等方法,有监督类似文本分类方法;
-
NER 实体识别:识别 query 中如品牌词、产品词、型号词等,提升召回的准确性。
基于词的召回
基于词的召回,底层实现基于倒排索引,当用户输入 query 后,query 经过 QP 模块,再对 query 进行分词,得到分词后的 term 集合,,根据这些 term 的倒排索引中查找 term 所在的文档。如下图所示:
搜索引擎如 ES、Lucene 等,都自带 BM25 算法,来计算 query 和 doc 之间的文本相关度,召回时根据相关分由高到低返回商品。公式如下:
:查询项的逆文档频率,衡量这个词提供了多少信息;
:指 在文档中的词频;
:指文档的平均长度;
:指文档长度;
:为可调节参数;
基于向量的语义召回
基于词的召回的弊端是,无法召回语义相似性的结果。例如有两个 query:“iphone 多少钱”和“苹果手机什么价格”,这两个 query 的意思基本一致,同样想知道 iPhone 手机的价格,但是字面上没有任何的重叠,用传统算法计算相似度非常低。
基于 DSSM 的深度召回模型
具体做法是,通过搜索引擎中 query 和 doc 的点击曝光日志,用 DNN 把 query 和 title 表达为低维语义向量,并通过余弦相识度来计算两个语义向量的距离,最终训练出语义相识度模型。
将训练好的 doc 的向量建索引,存储在如 faiss 等向量数据库中,当有新的 query 输入计算 query 的向量,在 faiss 中查找 topk 的 doc 返回。
基于 Bert 等预训练召回模型
结构与 DSSM 差不多,只不过映射低维语义向量时采用 bert 预训练模型。
基于多模态的召回模型
以 BERT 结构作为 encoder,文本模态为商品标题,Tokenize 后输入到模型。视觉模态为商品图片,先通过 CNN 网络提取成 Patch Embedding 输入到 BERT。文本和视觉特征输入以 [SEP] 分隔。
在检索任务微调之前,FashionBert 先经过了一个 <query, titel, image> 三元组输入的微调,以进一步适应 <query, title+image> 的跨模态匹配任务,训练数据为搜索点击日志构造的 query-item 信息对
跨模态微调任务与经典的 DSSM 架构一致,只是 doc 端的输入升级为图文特征。query、title、image 可以共享同一个BERT模型,以 Segment Id 区分。训练数据同样为搜索点击日志构造的 <query, item>pair 对
搜推系统的排序
搜索系统和推荐系统最重要的环节是排序阶段,因为最终排序的结果影响商品的转化率。
ctr 预估模型的演变路线就是特征组合的演变路线,从最初的线性模型如:LR,基本是人工特征加人工特征组合,到 FM/FFM 的二阶特征组合,再到 DNN 等端到端模型,引入高阶特征非线形组合。
特征的种类大体分为三类,商品侧特征:商品价格、商品类目、发货时间等等;用户类特征:性别、类目偏好等等;上下文特征:访问时间、访问的手机型号等等。
LR
逻辑回归作为工业界最简单有效的线性模型,具有实现简单、推理速度快、鲁棒性好、计算代价小等优点,但缺点也很明显有容易欠拟合、分类精度不高、人工特征处理代价高。
具体函数:
其中 代表特征值, 代表特征权重,损失函数为交叉熵,采用梯度下降法求解特征权重。
FM/FFM
FM 引入特征组合,改写特征交叉公式,提升速度自动实现两两特征组合。缺点在于,还是要做特征工程。
DeepFM
DeepFM 模型包含 FM 和 DNN 两部分,FM 模型可以抽取 low-order 特征,DNN 可以抽取 high-order 特征。由于输入仅为原始特征,而且 FM 和 DNN 共享输入向量特征,DeepFM 模型训练速度很快。
重排序
精排打分完成后,就到了重排阶段,重排离最终的用户展现最近,重排主要解决两大方面的问题:用户体验、流量调控。
用户体验
对最终展示给用户的商品,做同类目、同店铺、相似封面图的 item 进行打散可以有效防止用户疲劳和系统过度个性化,同时有利于探索和捕捉用户的潜在兴趣,对用户体验和长期目标都很关键。
流量调控
流量调控主要有保量类和调权类2种。
- 调权类:一般是业务运营需求,需要快速实时干预。比如三八妇女节需要临时对美妆类 item 做加权,增加其流量。常见方法有,规则引擎:直接在重排结果上,对于命中属性规则的 item,加入一定的分数,使得最后可以透出,增加其流量。样本加权:对于命中调权规则的样本,增加其在 loss 中的权重,迫使模型偏向于对它们精准预估。
- 保量类:通过流量扶持,刺激生态建设。比如对冷启 item,新热 item,大店的新发布 item,均可以给予一定的保量流量,让他们能够顺利透出和正循环。
总结
无论是推荐系统还是搜索系统,整体架构大体如下图所示:
对于召回层和排序层,各模型算法细节下期再介绍!
推荐阅读
招贤纳士
政采云技术团队(Zero),一个富有激情、创造力和执行力的团队,Base 在风景如画的杭州。团队现有 500 多名研发小伙伴,既有来自阿里、华为、网易的“老”兵,也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外,还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践,推动并落地了一系列的内部技术产品,持续探索技术的新边界。此外,团队还纷纷投身社区建设,目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾,希望开始折腾事;如果你想改变一直被告诫需要多些想法,却无从破局;如果你想改变你有能力去做成那个结果,却不需要你;如果你想改变你想做成的事需要一个团队去支撑,但没你带人的位置;如果你想改变本来悟性不错,但总是有那一层窗户纸的模糊……如果你相信相信的力量,相信平凡人能成就非凡事,相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程,亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程,我觉得我们该聊聊。任何时间,等着你写点什么,发给 zcy-tc@cai-inc.com
微信公众号
文章同步发布,政采云技术团队公众号,欢迎关注