本文内容來自于
由阿裡雲開發者社群 x 達摩院領航舉辦的3月20日向量檢索專場Meetup講師演講内容
講師介紹
張吉
愛奇藝深度學習雲研發工程師
一、背景介紹
（一）推薦系統
推薦系統是現在網際網路發展一個比較重要的基石，上圖左邊是愛奇藝手機端的應用，右邊是 PC 端的 Web 頁面。可以看到，很多劇都是通過推薦而來的，随着資料量的發展，使用者的搜尋習慣也改變了。原來使用者有目的性搜尋，如今更希望系統進行主動的智能推薦，提升使用者體驗，目前推薦系統在愛奇藝裡占據重要地位。
（二）推薦系統架構
愛奇藝推薦系統架構分為三段，呈現漏鬥型的結構。所有候選集即愛奇藝視訊庫，先過濾出一些當下熱劇，然後建一個索引。通過召回階段，将資料從百萬量級篩選到千量級的規模，接着經過排序階段，排出十量級的劇最後推送給使用者。
本文主要分享的是基于 ANN 做的召回階段，對于召回的要求是速度快和資料量大。
二、工程實踐
（一）算法選型
算法選型選的是 YouTubeNet，做的是 User-Item 的召回，選取它是因為模型召回效果較好。它下邊是一些使用者的向量，通過拼接使用者向量形成分類網絡，最後分類出來的這一層對應愛奇藝的視訊，最終形成 User-Item 的推薦，在訓練階段就是一個千百萬級别的分類器。
最後的 Serving 階段比較有挑戰，因為召回階段難以線上計算整個神經網絡的推理，是以在Serving 階段用 ANN 的方式，然後近似地把全連接配接之後的資料取 Topk 的過程，用 ANN 做近似。
我們把網絡倒數第二層看做使用者向量，分類裡面矩陣的權重看做視訊向量，
普通召回
把網絡倒數第二層看做使用者向量，分類裡面矩陣的權重看做視訊向量，在計算的時候，假如是一個5維的使用者向量，然後它跟視訊向量做全連接配接乘法，最後得到的視訊向量比如有100萬條，則得出100萬的視訊得分，代表的是100萬個視訊。這時候再取一個 Topk，最後得到的是希望召回的視訊ID，這就是通常情況下召回的推理過程。
*
ANN 方式召回
用 ANN 的方式就比較巧妙，因為向量檢索可以選擇用内積的形式來做距離度量方式，矩陣層其實也是内積，這兩個近似等價。
也就是說 YouTubeNe t在 Serving 的時候，把全連接配接全乘完之後的結果再取 Topk 的過程，轉化成了一個用内積形式做度量，直接做 ANN 近似召回的過程，是以在 Serving 階段就使得千百萬級别的全連接配接的效率是得到了一定保證。
（二）Serving結構
如上圖所示，Serving 結構模型分為三段，第一段是 DNN 使用者銷量的線上推理，第二部分通過使用者向量做 ANN 的召回，然後推送給後邊排序的是每一個視訊的 ID 還有對應的得分。
我們在做的過程中，面臨以下三個問題：
1） 整體模型如何更新
整個模型分為使用者向量生成的 DNN 推理部分，還有 ANN 索引庫部分，這兩個其實是從同一個模型裡拆出來的，是以在真正 Serving，包括更新的時候，一定要保證 DNN 和 ANN 的版本一定要是同一個模型拆出來的，否則在真正計算的時候，它們不在一個向量空間裡，算出來就都是錯誤的資料。
2）Serving 效率
召回對整體性能有一定要求，如果請求端自己先請求 DNN 然後再傳回，接着再去請求一個獨立的 ANN 服務，中間存在一些網絡開銷。
3）接口與 TF Serving 一緻
我們對外提供的是 TF Serving 接口，不改這個接口的話對整體的技術棧沒有影響，上線效率高，不需要額外做接口方面的開發。
基于這三點，我們設計了兩個方案。
方案一：
第一個方案把整個 ANN 的這部分，相當于對前面的請求方給它屏蔽掉。用 DNN 之後，直接拿到使用者向量去 ANN 做向量的檢索。DNN 部分選用 Tensorflow，ANN 部分選用 Milvus，Milvus 的優點有文檔豐富、封裝完善和開箱即用。
上圖為方案一整體結構，Milvus 有 C++ 的 SDK，在用的時候，推薦量大概在百萬到千萬級别，單個容器下面容量可以滿足，是以先都在單個容器裡面。
容器裡包含了兩個程序，一個是 TF Serving，負責 DNN 的編碼，裡邊有 Milvus 的一個裝置，然後 Milvus 請求同一個容器内部的 ANN 服務。對于外部來說，整體的接口還是 TF Serving，并沒有改變接口。容器内部減少了一些網絡上的開銷，整體上性能較為良好。
- Tensorflow Serving 改造
Tensorflow Serving 就是一個 Tensorflow Runtime 的封裝，主要是做 RPC 的請求處理和模型管理方面的工作。
紅框中是整個 Tensorflow Serving 在運作推理時，最核心的函數叫 RunPredict，裡邊包了一層 Tensorflow Runtime，然後把對應的 Return proto 進行解析，最後再統一回傳給請求方。
我們在這個函數裡邊加了一層 Milvus SDK RPC，通過 Tensorflow Runtime 拿出來的使用者向量，直接在這邊就封裝成 Milvus 的請求，然後去請求本地 ANN 服務。然後再傳回 Proto 時候，會傳回對應的 ID 和得分。
- 改造步驟總結如下：
1）檢查簽名
2）解析 proto
3）TF Runtime 計算
4）解封 proto
- 模型更新
如上圖所示，2個Version1 是現在正在服務的一些模型。由于我們這是一個隻讀的場景，相當于線上服務時加載的是已經訓練好的索引，Tensorflow 有這個模型動态加載的能力，但是 Milvus 目前沒有，是以通過整體進行 AB 切換的方式來更新。
更新 Version2 的時候，會先啟動一個 Version2，當 Version2 就緒時，會把 Version1 摘掉，通過 CONSUL 保證服務的發現性。
這裡存在一個缺點，在請求的時候，Version1 和 Version2 會存在一些混亂的情況，混亂程度取決于更新的時間，如果更新得快，可能抖動就不會很大，如果更新得慢就會受到一些影響。
方案優點：開發速度快
方案缺點：不夠靈活、模型版本難以管理。
- Milvus 場景&配置
對于Milvus我們做了一些簡單的配置：
1）隻讀場景
2）資料在百萬級别
3）索引檔案可共享
由于我們是一個隻讀場景，是以希望線上 Serving 時可以直接加載離線訓練好的 Milvus 索引，相當于在真正建索引的時候，是有一個專門建立索引的 Milvus 容器不斷地去建立索引，然後把這些 Milvus 所建立的索引都彙到對應的網絡存儲上，在 Serving 的時候隻需要拉下來，然後做加載就可以了。
- TF serving 與 Milvus 結合
TF serving 靜态編譯 GRPC，Protobuf
Milvus 靜态編譯 GRPC，Protobuf
在做TF Serving 和 Milvus 結合的時候，因為這兩者都是用到了 GRPC，而且都是靜态編譯，如果放到同一個程序裡面，由于兩者的 GRPC 版本不一樣，會導緻一些問題，比如資料格式轉換等。
是以我們将 GRPC 的版本統一為 Tensorflow Serving 的1.19.1版本，之後就可以在 Tensorflow 版本裡面調用 Milvus 的服務。
- 業務需求
結合方案一的優缺點，後續産生了如下業務需求：
需求一：召回後重排序
許多算法人員回報，召回之後如果結合一些業務名額，對召回再進行一次重排序，效果會有所提升。而且對于召回而言，在很多召回引擎中，召回 Top3 版跟 Top5 版所需時間相差無幾。是以可以召回 Top5 版，然後再進行一次重排序，這樣效果會提升很多。
需求二：召回模型帶版本
召回模型帶版本的話，後續可以對模型版本進行管理。
需求三：前置過濾
在愛奇藝視訊中，有的視訊是使用者已經觀看過的，是以在召回時希望過濾掉這一部分視訊，進而不會給使用者進行重複推薦，提升使用者體驗。
結合以上三個需求，我們做了方案二。
方案二
如上圖所示，在原來的基礎上，除了 DNN 部分是原生的 Tensorflow 之外，我們把 ANN 也放到了 Tensorflow 的 Runtime 中。
如果都在計算圖中的話，剩下的一些其他邏輯，例如重排序，對于算法人員而言整體就比較簡單了。除了一些業務名額之外，也可以用簡單的樹模型根據使用者的 Feature 做一次再重排序。而且如果都集中到 Tensorflow 裡邊，對外接口也是一緻的，對于整個技術棧，貼合度也會更高一些。
- 方案二技術選型
基于以上方案，我們需要把 ANN 的這個功能做成一個OP，是以選取了 Hnswlib，它有三個優點：
1）性能好
2）線程模型簡單
3）Head only
- 方案二結構
方案二使用 HNSW OP 建立計算圖，更新部署與純 TF Serving 一緻。
RunPredict有的邏輯都放在了 Tensorflow Runtime 中，這也符合 Tensorflow Serving 設計的初衷，因為它更多的是處理 RPC 請求與模型管理的工作。
優缺點
**優點：可支援更靈活的邏輯，模型版本易于管理
缺點：ANN OP需要開發**
整體的模型更新部分與 Tensorflow 一樣，是熱更新的模式。
比如這個 Tensorflow 有兩個版本 Version1 跟 Version2，然後大家都在請求 Version2。這個時候如果觸發一次更新，容器會分先後，大家都會去加載 Version3，整體都加載完之後，就可以都切到 Version3了。通過熱更新的方式，整個模型易于管理。
- 整體 Serving 工作流
作為一個基礎的 AI 平台，為使用者提供的服務不止是 Serving，也會提供訓練與模型管理方面的工作，整體 Serving 的工作流主要分為4個部分。
首先使用者上傳訓練好的模型，接着觸發建立索引的任務，這個任務基于方案一或方案二會産生不同的索引。如果是 Milvus 則會建立 Milvus 的索引，如果是定制的 OP，會把這個圖轉換成HNSW OP 的圖，然後把建立好的索引或轉換好的圖上傳到網絡存儲上。
在真正 Serving 時，有一個全局唯一的 Version，通過 Version 指定網絡存儲下載下傳對應的模型/索引，下載下傳完之後就可以進行線上 Serving。
HNSW OP 性能測試
HNSW OP 性能測試（純 ANN）
如果是對 YouTubeNet 做 Serving，把前面的 DNN 去掉，就變成一個純召回服務。基于這種情況，我們去測了 sift 模型，測下來準确率為95.35%。
上圖是單次請求的線上 Serving 資料，并發數代表同時請求的 euclidean 數量，Wait time 代表單個請求的時間間隔。可以看到，并發度20與40的測試結果裡，除了 QPS 和 CPU 使用率翻倍以外，延遲分位點等資料大緻相同，Tensorflow 對并發擴充處理優秀。
HNSW OP 性能測試（YoutubeNet）
“ AI 檢索技術部落格” 由阿裡巴巴達摩院系統 AI 實驗室創立，
掃碼關注 “ AI 檢索技術部落格” 公衆号，
擷取更多技術幹貨文章、AI 檢索領域 Meetup 動态。