到家搜索業務具有數據量大、過濾比高等特點，爲了在保證高召回率的同時進一步提高檢索性能，美團到家搜索技術團隊與基礎研發機器學習平臺團隊基於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向量檢索系統，目前已經應用於外賣商品向量檢索，向量召回鏈路的檢索性能、召回率均有顯著的提升，滿足策略對召回擴量和策略迭代的需求，具體提升如下：
1.向量索引召回率由85%提升至99.4%。
2.向量索引檢索時延TP99降低89%，TP999降低88%。
6 展望
- GPU向量檢索系統目前只支持T+1全量構建索引，後續計劃支持實時索引。
- GPU向量檢索當前支持FLAT和IVF檢索算法，後續計劃支持HNSW算法，在過濾比較低的場景下可提供更高的檢索性能。
- 除了GPU，後續還會在NPU等新硬件上做更多的嘗試。
| 在美團公衆號菜單欄對話框回覆【2023年貨】、【2022年貨】、【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
