粗排架构初步调研

粗排架构初步调研

1. 背景简介

搜索和召回的环节主要氛围召回+排序，目前召回逐渐发展成为多路召回模式，每一路召回的侧重点都不相同，随着召回的路数不断增加，召回的结果集不断变大。排序的输入量也越来越大。如果直接用深度模型对大量的召回输入进行排序的话，会导致耗时比较长的问题，无法满足线上的实时性需求。
  粗排的实现方案：粗排的要求是快，精度可以没有精排的高，主要是在保证快的前提下尽量保证排序的准确性。有一种解决方案，是使用比较简单的模型，比如LR，FM等模型。后来yutub提出了一个双塔模型，这个模型是一个深度模型，提出来以后市场反响很不错，目前大部分的大厂的粗排都是使用这个模型来实现的。

2. 双塔模型简介

双塔模型在匹配层之前，user 特诊和item特征之间是不交互的。模型的最后一层是计算两个向量的相似距离（cos，点积等操作），输入层和表示层都是离线训练得到的结果是向量。

双塔的应用：

1. 用来做召回使用
2. 用来做粗排

2.1 召回使用

因为直接通过向量的相似度计算得到k临近，所以也可以用来做召回，百度，和youtube都有使用。使用的模型可能有多种，但是最终都是使用向量来计算相似度。这种架构需要在向量引擎中存储所有的item向量，用户向量实时产生，然后通过user向量去向量引擎中召回满足需求的数据。

2.2 粗排使用

粗排是在召回完成后对召回的数据做排序，数据集的大小一般为1w左右

3. 架构设计

架构设计层面主要会围绕整个推荐搜索的架构，以及粗排的细节架构来展开，讨论粗排的架构可能的实现方案。

1. 搜索推荐的整体架构

这幅图展示了一个搜索推荐架构的主体结构和流程。双塔结构的粗排需要提前加载离线计算的item向量。根据召回结果中的item id list 和user 特征向量计算topK。

2. 通过同事输入总结得到的一种自建粗排架构

这种粗排架构有两个部分：

1. 一部分是proxy, 负责接收recall的结果和user 向量，调用计算引擎产出topK
2. 一部分是计算引擎，负责计算向量的相似度。
     
     这种方案的计算引擎部分属于自建计算引擎，item向量在计算引擎中是使用分片的方式进行存储的，会根据一定的规则存储到不同的节点。由ShardManager根据路由的规则将数据由hdfs推送到不同的shard上面去。同时在使用端proxy发起请求的时候也要根据相同的规则将item id+user向量 路由到不同的shard上面进行计算。

简要概括一下

1. 自建计算引擎
2. Proxy端和shardManager保持相同的路由规则
3. 基于内存做计算
4. 集群的维护有一定成本（扩缩容等）

3. 使用开源作为计算引擎的粗排架构

目前初步调研了开源引擎vearch, milvus两款引擎，目前看这两款引擎也存在一些问题。目前基于对faiss的了解来看，他们支持的数据存储的类型有:

• 基于树的索引
• 基于图的索引
• 基于哈希的索引
• 基于量化的索引
• 全量遍历
  但是这些索引除了全量遍历的类型，其他类型的索引方式都是有召回损失的，会影响召回的准确度。

简要概括

1. 使用开源计算引擎
2. Proxy端和shardManager不再关注路由规则
3. 集群的维护成本相对较低
4. 查询效率依赖于开宇计算引擎的能力
5. 召回存在损失
   进一步考虑
     是否可以使用Elasticsearch来完成这项任务，es基于id的过滤是非常高效的，使用倒排列表可以快速过滤，使用dense_vector存储向量字段，然后使用余弦函数来计算余弦相似度

增量数据处理逻辑：保证近实时性
全量数据加载：
Miss id list