美團外賣基於GPU的向量檢索系統實踐

　　到家搜尋業務具有資料量大、過濾比高等特點，為了在保證高召回率的同時進一步提高檢索效能，到家搜尋技術團隊與美團基礎研發機器學習平臺團隊基於GPU實現了支援向量+標量混合檢索的通用檢索系統，召回率與檢索效能均有較大提升。本文將介紹我們在GPU向量檢索系統建設中遇到的挑戰及解決思路，希望對大家有所幫助或啟發。

　　 1 背景

　　隨著大資料和人工智慧時代的到來，向量檢索的應用場景越來越廣泛。在資訊檢索領域，向量檢索可以用於檢索系統、推薦系統、問答系統等，透過計算文件和查詢向量之間的相似度，快速地找到與使用者需求相關的資訊。此外，在大語言模型和生成式AI場景，向量索引做為向量資料的底層儲存，也得到了廣泛的應用。

　　如下圖所示，向量檢索主要分為三個步驟：（1）將文字、影像、語音等原始資料經過特徵抽取，模型預估，最終表徵為向量集合；（2）對輸入Query採用類似的方式表徵為向量；（3）在向量索引中找到與查詢向量最相似的K個結果。一種簡單直接的檢索方式是與向量集合進行逐一比較，找到與查詢向量最相似的向量。這種方法也被稱為暴力檢索。在大資料量或者高維度場景中，暴力檢索的耗時和計算資源消耗巨大，無法在現實場景中直接使用。　　

　　為了解決上述問題，業界提出ANN（Approximate Nearest Neighbor）近鄰檢索方案：透過構建有效索引，減少向量計算量，犧牲一定的召回精度以換取更高的檢索速率。另一方面，研究如何透過GPU的平行計算能力，加速向量相似計算，也是一個比較熱門的發展方向之一。Facebook開源的向量檢索庫Faiss在GPU上實現了多種索引方式，與CPU版效能相比，檢索速率提升5到10倍。開源的向量檢索引擎Milvus基於GPU加速的方案使得檢索提高10+倍。

　　目前，向量檢索已經廣泛應用在美團外賣搜推業務各場景中。相較於其他業務場景，美團外賣業務特點具有較強的Location Based Service（LBS）依賴，即商家的配送範圍，決定了使用者所能點餐的商家列表。以商品向量檢索場景為例：向量檢索結果集需要經過“可配送商家列表”過濾。

　　此外，在不同的業務場景使用過程中，還需要根據商家商品的品類、標籤等標量屬性進行過濾。當前，美團外賣向量檢索基於Elasticsearch+FAISS進行搭建，實現了10億級別+高維向量集的標量+向量混合檢索的能力。為了在保證業務高召回率的同時進一步減少檢索時間，我們探索基於GPU的向量檢索，並實現了一套通用的檢索系統。

　　 2 美團外賣向量索引的發展歷程

　　在美團外賣向量檢索系統的建設過程中，我們相繼使用了HNSW（Hierarchical Navigable Small World），IVF（Inverted File），IVF-PQ（Inverted File with Product Quantization）以及IVF-PQ+Refine等演算法，基於CPU實現了向量檢索能力。在過去的幾年間，我們對Elasticsearch進行定製，實現了相關的向量檢索演算法，在複用Elasticsearch檢索能力的情況下支援了標量-向量混合檢索。下面是這四種技術的簡介及演進歷程。

　　| 2.1 HNSW（Hierarchical Navigable Small World）

　　HNSW是一種用於大規模高維資料近似最近鄰搜尋的演算法，它的基本思想是使用一種層次化的圖結構，每一層都是一個導航小世界圖，從而實現了在高維空間中的高效搜尋。導航小世界圖是一種有著特殊拓撲結構的圖，它的特點是任意兩點之間的路徑長度都很短，而且可以快速找到。

　　在HNSW演算法中，這種導航小世界圖的層次結構使得搜尋過程可以從圖的高層開始，快速定位到目標點的大致位置，然後逐層向下精細化搜尋，最終在底層找到最近鄰，在通用檢索場景上有顯著的優勢。然而該演算法在高過濾比下效能會有折損，從而導致在到家搜推這種強LBS過濾場景下會暴露其效能的劣勢。業界有較多相關的benchmark可以參考，以Yahoo的向量檢索系統Vespa相關部落格為例，效能與召回率的趨勢如下：　　

　　| 2.2 IVF （Inverted File）

　　IVF是一種基於倒排索引的方法，它將高維向量空間分為多個簇（Cluster），每個簇對應一個倒排列表，儲存了屬於該簇的向量索引。這種方法大大減少了搜尋時需要比較的向量數量，從而提高了檢索速度。它的缺點是需要儲存原始的向量資料，同時為了保證檢索效能需要將其全量載入到記憶體中，從而佔用了大量的記憶體空間，容易造成記憶體資源瓶頸。

　　| 2.3 IVF-PQ（Inverted File with Product Quantization）

　　在候選集數量巨大的場景下，比如商品向量檢索場景下，IVF帶來的記憶體空間大的問題很快就顯現出來，為了解決記憶體空間的問題，開始嘗試使用了IVF-PQ方法。該方法在IVF的基礎上，使用了乘積量化（Product Quantization，PQ）的方法來壓縮向量資料。PQ將高維向量分為多個子向量，然後對每個子向量進行量化，從而大大減少了對記憶體空間的需求。

　　然而，由於量化過程會引入誤差，因此IVF-PQ的檢索精度會低於IVF，從而導致召回率無法滿足線上要求，對召回率要求相對較低的場景可以使用IVF-PQ，對召回率有一定要求的場景需要其他解決方案。

　　| 2.4 IVF-PQ+Refine

　　為了提高IVF-PQ的檢索精度，進一步採用了IVF-PQ+Refine的方案，在IVF-PQ的基礎上，在SSD磁碟上儲存了未經壓縮的原始向量資料。檢索時，透過IVF-PQ召回數量更大的候選向量集合，然後獲取對應的原始向量資料進行精確計算，從而提高檢索精度。這種方法既保留了IVF-PQ的儲存優勢，解決了記憶體資源瓶頸，又保證了召回率，因此在實際應用中得到了廣泛的使用。

　　| 2.5 基於地理位置的向量檢索

　　美團外賣業務有一個區別於普通電商的明顯特徵——LBS特徵，使用者和商家的距離在很大程度上影響著使用者的最終選擇。因此可以考慮在向量檢索過程中增加地理位置因素，使距離使用者更近的商品可以優先被檢索到。透過將經緯度編碼為向量，最佳化具體做法是將使用者或商家的經緯度以加權的方式加入查詢Query和候選向量中，在計算Query和候選向量的相似度時，距離因素就可以在不同程度上影響最終的檢索結果，從而達到讓向量索引具備LBS屬性的目標。在加入地理位置資訊後，向量檢索的召回率有較大提升。

　　除了以上幾種檢索方式，常見的向量檢索方式還有Flat（即暴力計算），可以實現100%的召回率，但是由於計算量大，其效能較差，一般僅用於小規模的資料場景。

　　 3 目標與挑戰

　　| 3.1 目標

　　在以上幾個方案落地後，向量+標量混合檢索、前置過濾、支援海量資料檢索幾個挑戰都得到了解決，但是檢索效能及召回率與理想目標仍有一定差距，需要探索其他可能的解決方案。考慮到美團外賣的業務場景，目標方案應該滿足以下要求：

　　支援向量+標量混合檢索：在向量檢索的基礎上，支援複雜的標量過濾條件。

　　高過濾比：標量作為過濾條件，有較高的過濾比（大於99%），過濾後候選集大（以外賣商品為例，符合LBS過濾的商品向量候選集仍然超過百萬）。

　　高召回率：召回率需要在95%+水平。

　　高效能：在滿足高召回率的前提下，檢索耗時Tp99控制在20ms以內。

　　資料量：需要支援上億級別的候選集規模。

　　在調研業界向量檢索方案後，我們考慮利用GPU的強大算力來實現高效能檢索的目標。當前業界大部分基於GPU的向量檢索方案的目標都是為了追求極致的效能，使用GPU來加速向量檢索，如Faiss、Raft、Milvus等，然而它們都是面向全庫檢索，不直接提供向量+標量混合檢索的能力，需要在已有方案的基礎上進行改造。

　　| 3.2 解決方案探索

　　實現向量+標量混合檢索，一般有兩種方式：前置過濾（pre-filter）和後置過濾（post-filter）。前置過濾指先對全體資料進行標量過濾，得到候選結果集，然後在候選結果集中進行向量檢索，得到TopK結果。後置過濾指先進行向量檢索，得到TopK*N個檢索結果，再對這些結果進行標量過濾，得到最終的TopK結果。其中N為擴召回倍數，主要是為了緩解向量檢索結果被標量檢索條件過濾，導致最終結果數不足K個的問題。

　　業界已有較多的成熟的全庫檢索的方案，後置過濾方案可以儘量複用現有框架，開發量小、風險低，因此我們優先考慮後置過濾方案。我們基於GPU的後置過濾方案快速實現了一版向量檢索引擎，並驗證其召回率與檢索效能。GPU中成熟的檢索演算法有Flat、IVFFlat和IVFPQ等，在不做擴召回的情況下，召回率偏低，因此我們在benchmark上選擇了較大的擴召回倍數以提高召回率。

　　測試資料集選取了線上真實的商品資料，據統計，符合標量過濾條件的候選向量數量平均為250萬，在單GPU上驗證後置過濾檢索效能與召回率如下：　　

　　測試結果表面，以上三種演算法均無法同時滿足我們對檢索效能和召回率的需求。其中IVF與IVFPQ召回率較低，Flat演算法雖然召回率較高，但是與全體候選集計算向量相似度導致其效能較差。

　　舉個例子，候選向量資料規模為1000萬，向量維度為D。

　　（1）Flat是純暴力計算的演算法，精度最高，但需要在全體候選集上計算相似度，單條查詢向量的計算量為1000萬*D次浮點運算。

　　（2）IVF在Flat的基礎上透過IVF倒排索引，將候選集劃分成多個簇（Cluster），然後選取部分離查詢向量較近的簇計算相似度，這樣可以按比例降低計算量，如果將候選集分成n_list=1024個簇，每次查詢只選取n_probe=64個簇，則單條向量的計算量為Flat的1/16，即62.5萬*D次浮點運算。

　　（3）IVFPQ對比IVF演算法，使用了乘積量化，將D維向量切分成M組子向量，每組子向量訓練出K個聚類中心，如果M=8，K=256，則單條查詢的計算量為8*256*D次浮點計算+1000萬*8次查表+1000萬*8次加法運算。

　　在Flat演算法的基礎上，我們考慮透過向量子空間劃分的方式，將全量候選集劃分為多個向量子空間，每次檢索時選取其中的一部分向量子空間，從而減少不必要的計算量，提高檢索效能。

　　考慮到外賣搜尋的強LBS屬性，可以基於GeoHash來進行向量子空間劃分。構建索引時，根據商家的地理位置（經緯度）計算GeoHash值，將全量商品資料劃分為多個向量子空間。檢索時，根據使用者的地理位置資訊計算其GeoHash值，並擴充套件至附近9個或25個GeoHash塊，在這些GeoHash塊內採用Flat演算法進行向量檢索，可以有效減少計算量。這種向量子空間劃分方式有效地提高了檢索效能，但是存在某些距離稍遠的商家無法被召回的情況，最終測得的召回率只有80%左右，無法滿足要求。

　　綜上，後置過濾方案無法同時滿足檢索效能和召回率的需求，而GPU版本的Faiss無法實現前置過濾功能，考慮到美團外賣的業務場景，向量+標量混合檢索能力是最基本的要求，因此我們決定自研GPU向量檢索引擎。

　　 4 GPU向量檢索系統

　　| 4.1 前置過濾實現方案選擇

　　基於GPU的向量檢索，要想實現前置過濾，一般有三種實現方案：

　　所有原始資料都儲存在GPU視訊記憶體中，由GPU完成前置過濾，再進行向量計算。

　　所有原始資料都儲存在CPU記憶體中，在CPU記憶體中完成前置過濾，將過濾後的原始向量資料傳給GPU進行向量計算。

　　原始向量資料儲存在GPU視訊記憶體中，其他標量資料儲存在CPU記憶體中，在CPU記憶體完成標量過濾後，將過濾結果的下標傳給GPU，GPU根據下標從視訊記憶體中獲取向量資料進行計算。

　　由於GPU與CPU結構與功能上的差異性，使用GPU完成前置過濾，視訊記憶體資源佔用量更大，過濾效能較差，且無法充分利用過濾比大的業務特點，因此不考慮方案1。

　　方案2與方案3效能對比與各自的優點如下所示：　　

　　實驗結果表明，方案2在資料複製階段耗時嚴重，時延無法達到要求。因為在美團外賣的場景下，過濾後的資料集仍然很大，這對CPU到GPU之間的資料傳輸頻寬（A30顯示卡頻寬資料如下 CPU-GPU：PCIe Gen4: 64GB/s；GPU-GPU：933GB/s）提出了很高的要求，因此我們最終選擇了方案3。

　　| 4.2 GPU向量檢索引擎

　　4.2.1 資料結構

　　考慮到視訊記憶體的價格遠高於記憶體，因此我們在設計方案的過程中，儘可能將資料儲存在記憶體當中，僅將需要GPU計算的資料儲存在視訊記憶體當中。

　　記憶體中儲存了所有的標量資料，資料按列儲存，透過位置索引可以快速找到某條資料的所有欄位資訊，資料按列儲存具備較高的靈活性和可擴充套件性，同時也更容易進行資料壓縮和計算加速。針對需要用於過濾的標量欄位，在記憶體中構造了倒排索引，倒排鏈中儲存了對應的原始資料位置索引資訊，記憶體資料結構如下圖所示：　　

　　視訊記憶體中儲存了所有的向量資料，資料位置索引與記憶體中的資料一一對應，可以透過位置索引快速獲取某條資料的向量資訊，如下圖所示：　　

　　4.2.2 檢索流程

　　Flat暴力檢索

　　初始化階段，在記憶體中構建用於標量過濾的倒排索引，同時，將向量資料從CPU記憶體複製到GPU視訊記憶體，透過位置索引進行關聯。

　　1. 標量過濾

　　標量過濾過程在CPU記憶體中進行，透過記憶體中的倒排索引，可以快速得到符合某個標量過濾條件的原始資料位置索引列表，透過倒排索引的求交、求並等邏輯，可以支援多個標量過濾條件的與、或關係組合，最終，得到所有符合條件的位置索引列表。

　　2. 相似度計算

　　相似度計算在GPU中進行，透過上一步標量過濾得到的位置索引列表，從GPU視訊記憶體中讀取符合條件的候選向量資料，然後使用常見的向量距離演算法計算最相似的TopK個向量，將檢索結果下表列表回傳給CPU。

　　3. 檢索結果生成

　　透過上一步的檢索結果下表列表，在CPU記憶體中獲取對應record記錄並返回。

　　整體檢索流程如下：　　

　　IVF近似檢索

　　在某些場景下，我們對檢索效能有更高的要求，同時對召回率的要求可以適當放寬，因此我們在GPU向量檢索引擎上支援了IVF近似檢索。

　　在初始化階段，使用向量資料訓練出P個聚類中心，並針對每個聚類中心構建區域性的倒排索引，倒排索引結構與Flat方案類似，區別在於位置索引資訊只儲存在最近的聚類中心下。

　　1. 標量過濾

　　標量過濾過程在CPU記憶體中進行，先找到與query向量最近的N個聚類中心點，在這些聚類中心點下進行標量過濾，得到N個候選位置索引列表，再merge 成最終的候選位置索引列表。與Flat方案相比，IVF近似檢索減少了計算量，因此能獲得更好的檢索效能。

　　2. 相似度計算

　　相似度計算階段與Flat方案相同。

　　3. 檢索結果生成

　　檢索結果生成階段也與Flat方案相同。

　　整體檢索流程如下：　　

　　在單GPU上驗證檢索效能與召回率如下（測試資料集同後置過濾）：　　

　　可見，無論是Flat還是IVF，在相同的召回率下，使用前置過濾的效能都要明顯好於後置過濾。

　　4.2.3 效能最佳化

　　完成前置過濾的向量檢索功能之後，我們對向量檢索引擎做了一系列最佳化。

　　1. 單GPU效能最佳化

　　高併發支援，透過Cuda Stream，GPU可以並行處理多個查詢請求，高併發壓測下，GPU利用率可以達到100%。

　　透過GPU實現部分標量過濾功能，支援在GPU上實現部分標量過濾功能，向量計算與標量過濾同處一個Kernel，充分利用GPU平行計算能力（標量過濾本身是一個無狀態操作，天然支援並行處理，CPU併發能力受限於CPU核數，但GPU可以支援上千個執行緒的併發，所以在效能上體現出明顯優勢）。

　　資源管理最佳化，支援控制代碼機制，資源預先分配，重複利用。每個控制代碼持有一部分私有資源，包含儲存向量檢索中間計算結果的可讀寫記憶體、視訊記憶體，以及單獨的Cuda Stream執行流；共享一份全域性只讀公有資源。在初始化階段，建立控制代碼物件池，可以透過控制控制代碼數量，來調整服務端併發能力，避免服務被打爆。在檢索階段，每次向量檢索需從控制代碼物件池中申請一個空閒的控制代碼，然後進行後續的計算流程，並在執行完後釋放響應的控制代碼，達到資源回收和重複利用的目的。

　　在單GPU上效能最佳化後的檢索效能與召回率如下（測試資料集同後置過濾）：　　

　　2. 多GPU並行檢索

　　除了以上最佳化方案，還可以考慮將資料分片，透過多GPU並行檢索，減少單卡計算量來提升檢索效能；同時，多卡架構也能支援更大規模的向量資料檢索。

　　相比多機多卡的分shard架構，單機多卡可以有效減少網路傳輸開銷，並且具有較低的索引載入複雜度，因此我們最終選擇了單機多卡的資料分片方案，單臺伺服器部署多張GPU，檢索時並行從本地多張GPU中檢索資料，在CPU記憶體中進行資料合併。

　　3. FP16精度支援

　　為了支援更大規模的向量資料檢索，我們還在GPU檢索引擎上支援了半精度計算，使用FP16替換原來的FP32進行計算，可以節省一半的GPU視訊記憶體佔用，經驗證Flat召回率由100%下降到99.4%，依然滿足需求。使用半精度之後，單機可以載入近10億資料，足夠支撐較長時間的業務資料增長。

　　| 4.3 向量檢索系統工程實現

　　向量檢索系統的工程化實現包括線上服務和離線資料流兩部分，總體架構圖如下：　　

　　GPU 檢索系統上線後實際效能資料如下（資料量1億+）：　　

　　 5 收益

　　到家搜尋團隊面向線上服務場景實現的GPU向量檢索系統，目前已經應用於外賣商品向量檢索，向量召回鏈路的檢索效能、召回率均有顯著的提升，滿足策略對召回擴量和策略迭代的需求，具體提升如下：

　　向量索引召回率由85%提升至99.4%。

　　向量索引檢索時延TP99降低89%，TP999降低88%。

　　 6 展望

　　GPU向量檢索系統目前只支援T+1全量構建索引，後續計劃支援實時索引。

　　GPU向量檢索當前支援FLAT和IVF檢索演算法，後續計劃支援HNSW演算法，在過濾比較低的場景下可提供更高的檢索效能。

　　除了GPU，後續還會在NPU等新硬體上做更多的嘗試。