丨汀、的博客

博文介绍了几种主流ANN近似算法，实际应用上，也同样会遇到很多工程上的挑战从单机性能这个角度，资源限制的主要是 CPU + 内存。不同的ANN算法，在索引构建和查询的时间复杂度各不相同，但基本上符合 “召回率越高，qps越低”。单机内存资源上限也制约着整体向量的规模，目前常规的服务器大部分都是 128G/256G左右的内存。举个例子，1亿个256维度的向量，整体的存储大小为 1^9 * 256 * 4B = 100G，算上服务系统资源消耗，索引切换等，一个大内存的机器顶多也就加载1个向量索引。

如何表达一个物品/元素?在现实世界中，我们认识和理解一个事物，总是会想办法捕捉它的一些特质或者属性。比如路边一朵红色的野花，那么仅从颜色这个维度，我们可以使用离散的0，1来表达。如 【1，0，0】但仅从颜色描述是不够的，还有花的种类，气味，高度，用途等等。把所有的属性枚举出来，排列好位置，元素对应属性的位置点亮，那么一朵沁人心脾的红色梅花 = 【1，0，0，1，0，0，1，0】上面分别就是 one-hot 与multi-hot的编码标识，在传统机器学习中比较常见。但这样会遇到几个问题:embedding

在 pooling 方法上，我们也尝试过不同层 pooling，或者在多层上增加 attention 聚合 BERT 多层结果，效果和最后一层所有 token 做 average pooling 相当。损失函数方面，在排序阶段使用pairwise比 pointwise 损失函数的效果会更好。

索引，初衷都是为了快速检索到你要的数据。），在信息检索领域使用比较广泛。核心的需求是:如何从超大规模的内容库中召回匹配关键字的结果。在mysql的索引，如果对某一个字段加了索引，一般来说查询该字段速度是可以有显著的提升。每种数据库都有自己要解决的问题（或者说擅长的领域），对应的就有自己的数据结构，而不同的使用场景和数据结构，需要用不同的索引，才能起到最大化加快查询的目的。对 Mysql 来说，是 B+ 树，对 Elasticsearch/Lucene 来说，是倒排索引。

与粗排/精排相比，混排对频道差异性和上下文信息差异性会更加敏感。下图我们展示了三种不同类型卡片在首页信息流的不同坑位上的点击率变化趋势（数据从50个分页的流量桶收集）。(1). 三种不同类型的卡片的CTR在同页的50个坑位上都呈现随坑位次序靠后逐步递减的趋势；(2). 类型A和类型B的CTR在每次重新请求后会变得更高，而类型C呈现单调递减趋势；(3). 不同类型卡片的CTR随坑位次序递减速度不尽相同。这些特点说明，

快手推荐系统包括了传统的召回、粗排、精排、Learning To Rank 的多目标排序、多目标预估等技术环节。而在这些模块之后的技术环节就属于重排序，主要包括手机端和服务端两部分。服务端通过传统服务器部署重排服务，包括序列重排、多源内容混排、多样性模块。端上部分包括端上重排模型和端上重排策略两部分。重排技术是快手十分重要的技术环节，它的发展速度远快于其他排序环节，属于较新的技术范畴。整个序列的价值并非单 item 效果的累计，如何使得序列价值最大化；

京东主站推荐的主要业务场景覆盖APP中用户购买前、购买中和购买后的全流程，日均千万级DAU。不同业务场景下用户需求不同，我们相应的优化目标也不同。首页feeds和“我的京东”就是典型的购买前的场景，我们主要去优化点击以及浏览深度；购物车和商品详情页是购买中的场景，主要优化点击率以及转化率；而订单页就是用户购买后的主要场景，会重点优化跨品点击和转化。

召回解决的是从海量候选item中召回千级别的item问题：模型类的模式是将用户和item分别映射到一个向量空间，然后用向量召回，这类有itemcf，usercf，embedding（word2vec），Graph embedding（node2vec等），DNN（如DSSM双塔召回，YouTubeDNN等），RNN（预测下一个点击的item得到用户emb和item emb）；向量检索可以用Annoy（基于LSH），Faiss（基于矢量量化）。

内容化这几年越来越成为电商的重点，用户来到网购的时候越来越不局限在只有明确需求的时候，而更多的是没有明确需求的时候，就像是逛街一样。逛逛就是在这样的背景下诞生的内容化产品，打造出有用、有趣、潮流、奇妙、新鲜的内容，为消费者提供全新的内容消费体验。强时效性：内容推荐场景下的内容新旧汰换非常快，新内容的用户行为少，很难用用户历史行为去描述新内容，而用户行为正是老内容投放主要的依赖。所以当不能依靠用户行为数据来建模内容之间关系的时候，我们必须要找到其他可以表征内容的方法。多兴趣表征。

推荐系统是一个比较复杂的系统，包括推荐算法，架构和数据，在线离线等非常多的方面，面临的挑战不仅仅是推荐算法的准确度的问题，推荐算法只是整个推荐系统中的一个方面，其实就真实的业务场景看，还有很多方面都会影响推荐效果的好坏，其中就包括数据的实时完备和准确性以及在线性能等很多方面，有说法数据和特征决定了上限，而算法只是在无限逼近上限而已，还是有一定的道理的。这里总结了一些在推荐系统中常常会面临的一些问题，其中的一些问题需要做非常多的工作去缓解问题带来的影响，还有一些问题可能根本就不是技术上的问题。

这三层分别做自己的事情，配合组合一起完成系统的运行所谓打点日志，是指用于数据统计的日志，一般前端会有打点的方法，而后端也会有类似需求。按理说，后端的一般的日志也可以做到打点的效果，但是因为一般的日志离散，风格不统一，得到的日志格式不好，不容易切分统计，所以就会想要一个独立的打点日志来实现打点。一般是天粒度或者小时粒度进行计算。

混排是指将多个不同的推荐结果混合在一起，以提供更多样化的选择和更全面的覆盖。混排的目的是为了避免推荐系统出现过度偏向某些内容或类型的情况，从而提高推荐的多样性和准确性。混排的实现方式通常是基于多种推荐算法和数据源，通过加权和组合的方式来生成最终的推荐结果。信息流推荐算法的核心是理解用户兴趣，捕捉用户逛买意图，并据此做到高效的人货匹配。

重排是指根据用户的喜好和需求，重新排列推荐结果的顺序，以提高用户满意度和点击率。重排的目的是为了让用户更快地找到自己感兴趣的内容，提高用户体验和转化率。重排的实现方式通常是基于用户反馈和行为数据，通过机器学习和算法优化来调整推荐结果的排列顺序。解决展示列表总体最优与资源位置平衡的问题。上面的图展示了策略可能在模型附近出现的环节，其中黄色标出来的部分都是策略部分。可以看到，策略本身就可以成为一路召回，比如前面讲的按照热度或者精品池召回。

推荐系统[4.1]：Ranking Loss 函数：度量学习、Siamese 和 triplet 网络、RankNet、pair-wise、List-wise loss以及在深度学习框架中loss设计

Learning to Rank (LTR)是一类技术方法，主要利用机器学习算法解决实际中的排序问题。传统的机器学习主要解决的问题是一个分类或者回归问题，比如对一个样本数据预测对应的类别或者预测一个数值分值。而LTR解决的是一个排序问题，对一个list的item进行一个排序，所以LTR并不太关注这个list的每个item具体得多少分值，更关注所有item的相对顺序。排序通常是信息检索的核心成分，所以LTR最常见的应用是搜索场景，对召回的document进行排序。

第一代粗排是统计模型，第二代为LR模型，目前业界使用较多的是第三代双塔模型结构，这些模型结构简单，能很好的适配时延要求，而且随着模型复杂度提升，准确率也不断提高，但双塔模型依然存在很多问题。于是有了第四代COLD、FSCD。双塔的特点特点：双塔分离：训练分离（性能制约）、部署分离（优点）信息塔内杂糅：噪声信息涌入tower-SENet解决；信息损失-ResNet；DNN信息拟合依赖-多塔并联；交叉太晚：美团增强双塔拆分user item，用tower去换取计算消耗。效果。

召回区分主路和旁路，主路的作用是个性化+向上管理，而旁路的作用是查缺补漏推荐系统的前几个操作可能就决定了整个系统的走向，在初期一定要三思而后行做自媒体，打广告，漏斗的入口有多大很重要。召回这里稍微有些复杂，因为召回是多路的。首先我们要解释主路和旁路的差别，主路的意义和粗排类似，可以看作是一个入口更大，但模型更加简单的粗排。主路的意义是为粗排分担压力。但是旁路却不是这样的，旁路出现的时机往往是当主路存在某种机制上的问题，而单靠现在的这个模型很难解决的时候。

推荐算法其实本质上是一种信息处理逻辑，当获取了用户与内容的信息之后，按照一定的逻辑处理信息后，产生推荐结果。热度排行榜就是最简单的一种推荐方法，它依赖的逻辑就是当一个内容被大多数用户喜欢，那大概率其他用户也会喜欢。但是基于粗放的推荐往往会不够精确，想要挖掘用户个性化的，小众化的兴趣，需要制定复杂的规则运算逻辑，并由机器完成。召回：当用户以及内容量比较大的时候，往往先通过召回策略，将百万量级的内容先缩小到百量级。