文章目錄

• • 1. 背景簡介
  • 2. 雙塔模型簡介
  • • 雙塔的應用：
    • • 2.1 召回使用
      • 2.2 粗排使用
  • 3. 架構設計
  • • 1. 搜索推薦的整體架構
    • 2. 通過同事輸入總結得到的一種自建粗排架構
    • • 簡要概括一下
    • 3. 使用開源作為計算引擎的粗排架構
    • • 簡要概括

粗排架構初步調研

1. 背景簡介

搜索和召回的環節主要氛圍召回+排序，目前召回逐漸發展成為多路召回模式，每一路召回的側重點都不相同，隨著召回的路數不斷增加，召回的結果集不斷變大。排序的輸入量也越來越大。如果直接用深度模型對大量的召回輸入進行排序的話，會導致耗時比較長的問題，無法滿足線上的實時性需求。
??粗排的實現方案：粗排的要求是快，精度可以沒有精排的高，主要是在保證快的前提下盡量保證排序的準確性。有一種解決方案，是使用比較簡單的模型，比如LR，FM等模型。后來yutub提出了一個雙塔模型，這個模型是一個深度模型，提出來以后市場反響很不錯，目前大部分的大廠的粗排都是使用這個模型來實現的。

2. 雙塔模型簡介

雙塔模型在匹配層之前，user 特診和item特征之間是不交互的。模型的最后一層是計算兩個向量的相似距離（cos，點積等操作），輸入層和表示層都是離線訓練得到的結果是向量。

雙塔的應用：

用來做召回使用

用來做粗排

2.1 召回使用

因為直接通過向量的相似度計算得到k臨近，所以也可以用來做召回，百度，和youtube都有使用。使用的模型可能有多種，但是最終都是使用向量來計算相似度。這種架構需要在向量引擎中存儲所有的item向量，用戶向量實時產生，然后通過user向量去向量引擎中召回滿足需求的數據。

2.2 粗排使用

粗排是在召回完成后對召回的數據做排序，數據集的大小一般為1w左右

3. 架構設計

架構設計層面主要會圍繞整個推薦搜索的架構，以及粗排的細節架構來展開，討論粗排的架構可能的實現方案。

1. 搜索推薦的整體架構

這幅圖展示了一個搜索推薦架構的主體結構和流程。雙塔結構的粗排需要提前加載離線計算的item向量。根據召回結果中的item id list 和user 特征向量計算topK。

2. 通過同事輸入總結得到的一種自建粗排架構

這種粗排架構有兩個部分：

一部分是proxy, 負責接收recall的結果和user 向量，調用計算引擎產出topK

一部分是計算引擎，負責計算向量的相似度。
??
??這種方案的計算引擎部分屬于自建計算引擎，item向量在計算引擎中是使用分片的方式進行存儲的，會根據一定的規則存儲到不同的節點。由ShardManager根據路由的規則將數據由hdfs推送到不同的shard上面去。同時在使用端proxy發起請求的時候也要根據相同的規則將item id+user向量 路由到不同的shard上面進行計算。

簡要概括一下

自建計算引擎

Proxy端和shardManager保持相同的路由規則

基于內存做計算

集群的維護有一定成本（擴縮容等）

3. 使用開源作為計算引擎的粗排架構

目前初步調研了開源引擎vearch, milvus兩款引擎，目前看這兩款引擎也存在一些問題。目前基于對faiss的了解來看，他們支持的數據存儲的類型有:

• 基于樹的索引
• 基于圖的索引
• 基于哈希的索引
• 基于量化的索引
• 全量遍歷
  但是這些索引除了全量遍歷的類型，其他類型的索引方式都是有召回損失的，會影響召回的準確度。

簡要概括

使用開源計算引擎

Proxy端和shardManager不再關注路由規則

集群的維護成本相對較低

查詢效率依賴于開宇計算引擎的能力

召回存在損失
進一步考慮
??是否可以使用Elasticsearch來完成這項任務，es基于id的過濾是非常高效的，使用倒排列表可以快速過濾，使用dense_vector存儲向量字段，然后使用余弦函數來計算余弦相似度

增量數據處理邏輯：保證近實時性
全量數據加載：
Miss id list

總結

以上是生活随笔為你收集整理的粗排架构初步调研的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。