如何搭建一個(gè)高效的推薦系統(tǒng)？

簡(jiǎn)單來說，現(xiàn)代推薦系統(tǒng)由訓(xùn)練/推斷流水線（pipeline）組成，涉及數(shù)據(jù)獲取、數(shù)據(jù)預(yù)處理、模型訓(xùn)練和調(diào)整檢索、過濾、排名和評(píng)分相關(guān)的超參數(shù)等多個(gè)階段。走遍這些流程之后，推薦系統(tǒng)能夠給出高度個(gè)性化的推薦結(jié)果，從而提升產(chǎn)品的用戶體驗(yàn)。

為了方便大家對(duì)此進(jìn)行深入了解，我們邀請(qǐng)到 NVIDIA Merlin團(tuán)隊(duì)，他們將詳細(xì)介紹推薦系統(tǒng)的上述多個(gè)階段的工作流程，以及推薦系統(tǒng)在電商、流媒體、社交媒體等多個(gè)行業(yè)領(lǐng)域的實(shí)踐和用例。

NVIDIA Merlin & Milvus

推薦系統(tǒng) pipeline 中至關(guān)重要的一環(huán)便是為用戶檢索并找到最相關(guān)的商品。為了實(shí)現(xiàn)這一目標(biāo)，通常會(huì)使用低維向量（embedding）表示商品，使用數(shù)據(jù)庫存儲(chǔ)及索引數(shù)據(jù)，最終對(duì)數(shù)據(jù)庫中數(shù)據(jù)進(jìn)行近似最近鄰（ANN）搜索。這些向量表示是通過深度學(xué)習(xí)模型獲取的，而這些深度學(xué)習(xí)模型基于用戶和產(chǎn)品或服務(wù)之間的交互進(jìn)行訓(xùn)練。使用計(jì)算機(jī)視覺算法或語言模型，還可以從各種數(shù)據(jù)模態(tài)（例如圖像、視頻或產(chǎn)品與用戶的文本描述）中生成向量表示。獲取向量表示后便迎來關(guān)鍵步驟——對(duì)數(shù)十萬甚至數(shù)百萬/數(shù)十億的向量嵌入數(shù)據(jù)集（例如電商庫存產(chǎn)品 embedding）進(jìn)行高效的 top-k（即 k 個(gè)最相似）搜索。

NVIDIA Merlin 是一個(gè)開源框架，用于訓(xùn)練端到端模型，從而為各類規(guī)模的數(shù)據(jù)生成推薦，輕松集成高效的向量數(shù)據(jù)庫索引和搜索框架。而 Milvus 作為大模型時(shí)代備受關(guān)注的向量數(shù)據(jù)庫可以提供高效索引和查詢功能。

最近，Milvus 新增支持 NVIDIA GPU加速，可提升查詢的并發(fā)和速度，這對(duì)于現(xiàn)代推薦系統(tǒng)十分有用。截至 2023 年 10月，Milvus 獲得了 599 萬次 docker pull 及 2.3 萬顆 GitHub Star，被業(yè)界廣泛應(yīng)用。

接下來，我們將演示 Milvus 是如何與 Merlin RecSys 框架集成、Milvus 如何在項(xiàng)目檢索階段與高效的 top-k 向量搜索技術(shù)相結(jié)合，以及如何在推斷時(shí)使用 NVIDIA Triton Inference Server (TIS)。根據(jù) NVIDIA 性能測(cè)試結(jié)果顯示：使用 Merlin 模型生成向量并使用 GPU 加速版的 Milvus 可以將搜索速度提升 37 至 91 倍。我們使用的 Merlin-Milvus 集成代碼和詳細(xì)性能測(cè)試結(jié)果均可在 https://github.com/bbozkaya/merlin-milvus/tree/main 處獲取。

圖 1. Milvus 框架為多階段推薦系統(tǒng)的

檢索階段做出貢獻(xiàn)

挑戰(zhàn)

由于推薦系統(tǒng)具備多階段的性質(zhì)以及各種組件和庫的可用性問題，其主要挑戰(zhàn)就是在端到端流程中無縫集成所有組件，因此我們的目標(biāo)是在示例 notebook 中盡可能簡(jiǎn)化集成工作。

另一個(gè)挑戰(zhàn)是加速整個(gè)推薦流程。雖然加速在訓(xùn)練大型神經(jīng)網(wǎng)絡(luò)中扮演著重要的角色，但 GPU 是在近期才被添加到向量數(shù)據(jù)庫和 ANN 搜索領(lǐng)域中的。隨著電商庫存產(chǎn)品、流媒體等數(shù)據(jù)規(guī)模爆炸式增長(zhǎng)和用戶數(shù)量的井噴，CPU 從性能上而言已經(jīng)無法滿足服務(wù)數(shù)百萬用戶的推薦系統(tǒng)的需求。為了解決這個(gè)挑戰(zhàn)，需要在流程的其他部分進(jìn)行 GPU 加速。本文提出的解決方案展示了 ANN 搜索時(shí)使用 GPU 加速可以有效解決這一問題。

技術(shù)棧

正式開始前，先介紹一下即將用到的技術(shù)棧。

首先需要一個(gè)推薦系統(tǒng)框架作為基礎(chǔ)，本例中我們使用 NVIDIA Merlin，因?yàn)檫@個(gè)開源庫提供在 NVIDIA GPU 上加速推薦系統(tǒng)的高級(jí) API （high-level API）。Merlin 可以助力數(shù)據(jù)科學(xué)家、機(jī)器學(xué)習(xí)工程師和研究人員構(gòu)建高性能推薦系統(tǒng)。除了 Merlin 以外，本例中還使用了以下開源工具/庫：

• NVTabular：用于預(yù)處理輸入表格數(shù)據(jù)和特征工程。

• Merlin Models：用于訓(xùn)練深度學(xué)習(xí)模型，從用戶交互數(shù)據(jù)中學(xué)習(xí)獲取用戶和商品向量。

• Merlin Systems：用于集成基于 TensorFlow 的推薦模型與其他組件（例如特征存儲(chǔ)、Milvus 的 ANN 搜索功能），以便在 TIS 中提供服務(wù)。

• Triton Inference Server：用于在推斷階段傳遞用戶特征向量并生成產(chǎn)品推薦。

• 容器化：上述所有內(nèi)容都可以在 NVIDIA 提供的 NGC 目錄中獲取。本例使用 Merlin TensorFlow 23.06 容器。

• Milvus 2.3：用于啟用 GPU 加速的向量索引和查詢。

• Milvus 2.2.11：與上述相同，但在 CPU 上執(zhí)行向量索引和查詢。

• pymilvus SDK：用于連接 Milvus 服務(wù)器、創(chuàng)建向量數(shù)據(jù)庫索引并通過 Python 接口運(yùn)行查詢命令。

• Feast：用作端到端 RecSys 流程中保存和檢索用戶、商品向量的（開源）特征存儲(chǔ)。

此外，我們還用到了許多底層庫和框架。例如，Merlin 依賴于 cuDF 和 Dask 等其他 NVIDIA 庫，這兩個(gè)庫均可在 RAPIDS cuDF 中獲取。同樣，Milvus 依賴于 NVIDIA RAFT 實(shí)現(xiàn) GPU 加速，HNSW 和 FAISS 等庫進(jìn)行搜索。

了解向量數(shù)據(jù)庫

ANN 搜索是關(guān)系型數(shù)據(jù)庫無法提供的功能。關(guān)系型數(shù)據(jù)庫只能用于處理具有預(yù)定義結(jié)構(gòu)、可直接比較值的表格型數(shù)據(jù)。因此，關(guān)系數(shù)據(jù)庫索引也是基于這一點(diǎn)來比較數(shù)據(jù)。但是 Embedding 向量無法通過這種方式直接相互比較。因?yàn)槲覀儾恢老蛄恐械拿總€(gè)值代表什么意思，無法使用關(guān)系型數(shù)據(jù)庫來確定一個(gè)向量是否一定小于另一個(gè)向量，唯一能做的就是計(jì)算兩個(gè)向量之間的距離。

如果兩個(gè)向量之間的距離很小，可以假設(shè)它們所代表的特征相似；如果距離很大，可以假設(shè)它們代表的數(shù)據(jù)十分不同。對(duì)我們而言，向量距離及其含義是有用的。我們可以創(chuàng)建索引結(jié)構(gòu)，高效搜索這些數(shù)據(jù)。但是為向量數(shù)據(jù)構(gòu)建索引也有不小挑戰(zhàn)：計(jì)算兩個(gè)向量間距離成本高昂，而且向量索引一旦構(gòu)建完成后，不易于修改。因此，我們無法直接使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫來處理向量數(shù)據(jù)，需要使用專為向量數(shù)據(jù)而打造的向量數(shù)據(jù)庫。

Milvus 是一款專為向量數(shù)據(jù)處理而設(shè)計(jì)的向量數(shù)據(jù)庫，可以解決傳統(tǒng)關(guān)系型數(shù)據(jù)庫無法處理向量的問題，為海量向量數(shù)據(jù)高效構(gòu)建索引。為了滿足云原生的要求，Milvus 將計(jì)算和存儲(chǔ)以及不同的計(jì)算任務(wù)（查詢、數(shù)據(jù)處理和索引）分離開來。用戶可以根據(jù)不同的應(yīng)用靈活擴(kuò)展每個(gè)組件。無論是數(shù)據(jù)插入密集型應(yīng)用還是搜索密集型應(yīng)用，Milvus 都能夠輕松應(yīng)對(duì)。如果有大量插入請(qǐng)求涌入，用戶可以臨時(shí)水平和垂直擴(kuò)展索引節(jié)點(diǎn)以處理數(shù)據(jù)。同樣，如果沒有大量插入數(shù)據(jù)，但有大量搜索操作，用戶可以減少索引節(jié)點(diǎn)的數(shù)量，并提高查詢節(jié)點(diǎn)的吞吐量。Milvus 的系統(tǒng)架構(gòu)設(shè)計(jì)（見圖 2）采用并行計(jì)算的思維方式，助力我們進(jìn)一步優(yōu)化本例中的推薦系統(tǒng)應(yīng)用。

圖 2. Milvus 框架設(shè)計(jì)

此外，Milvus 還整合了許多最先進(jìn)的索引庫，以便為用戶提供盡可能多的系統(tǒng)自定義功能。稍后，我們將討論這些索引的區(qū)別以及各自的優(yōu)缺點(diǎn)。

向量數(shù)據(jù)索引

大多數(shù)向量索引可以分成兩種類型——聚類和圖形。IVF 是聚類類別中的一種算法，它使用 k-means 來計(jì)算最近鄰的聚類。然后，將查詢向量與最近的質(zhì)心聚類進(jìn)行比較，并在搜索時(shí)進(jìn)行搜索。HNSW、DiskANN 和圖形類別中的其他算法主要圍繞著導(dǎo)航擴(kuò)展圖進(jìn)行搜索，這些圖形在 ANN 搜索時(shí)效率更高。但是圖形算法往往也更加復(fù)雜。如果大家對(duì)此感興趣，可以閱讀：https://zilliz.com/learn/hierarchical-navigable-small-worlds-HNSW

除了上述這些算法，還有一類叫做乘積量化 (PQ) 的算法。PQ 是一種將向量數(shù)據(jù)壓縮以減少資源使用并提高性能的方法，但其代價(jià)是降低召回率/準(zhǔn)確性。該領(lǐng)域中的大多數(shù)算法都是量化的變體，以允許降低內(nèi)存使用或提高其方法的性能。

所有這些算法和組合之間的區(qū)別是什么？為什么有這么多算法呢？它們之間的區(qū)別在于性能、召回率和內(nèi)存使用之間的權(quán)衡。例如，IVF_FLAT 索引是一個(gè)平衡了上述 3 個(gè)方面的索引，可以在不過多增加內(nèi)存開銷的情況下以較快的速度獲得良好的結(jié)果?；趬嚎s的索引，如 IVF_SQ8 和 IVF_PQ，在速度和減少內(nèi)存使用方面更強(qiáng)大，但根據(jù)所使用的壓縮級(jí)別，會(huì)降低召回率。HNSW 則以性能和召回率為目標(biāo)，但代價(jià)是內(nèi)存消耗。與其他索引相比，DiskANN 是最獨(dú)特的，因?yàn)樗且环N基于磁盤的索引。前面的索引都完全存儲(chǔ)在內(nèi)存中，需要大量的 RAM。DiskANN 只在內(nèi)存中保存少量索引數(shù)據(jù)，并將大部分?jǐn)?shù)據(jù)保存在磁盤存儲(chǔ)器中，這樣可以大大減少內(nèi)存使用量，同時(shí)仍然保持較高的召回率。但是，使用 DiskANN 會(huì)降低吞吐性能，并且根據(jù)所使用的 SSD 類型，會(huì)影響延遲性能。

如今，并非只有大型用戶/公司才能訪問非常大的數(shù)據(jù)集，小型用戶可能會(huì)從其數(shù)據(jù)中生成數(shù)十億個(gè)向量，并需要以最經(jīng)濟(jì)的方式進(jìn)行搜索。相比之下，大型用戶可能只有幾十萬個(gè)數(shù)據(jù)，每秒需要處理數(shù)萬個(gè)查詢。為了解決這些問題，索引層面提供很多定制化的參數(shù)來支持不同的用例。更多詳情，請(qǐng)?jiān)L問 https://milvus.io/docs/index.md 查看。

GPU vs CPU

對(duì)于大多數(shù)用戶來說，GPU 索引是獲得所需性能的關(guān)鍵。GPU 索引提供了許多用例所需的高吞吐量，同時(shí)從長(zhǎng)期而言可以節(jié)省成本。

構(gòu)建和搜索索引主要依賴向量化計(jì)算，可以在 CPU 上完成，但使用 GPU 效率大大提升。Milvus 將搜索計(jì)算遷移到 GPU 后，查詢每秒 (QPS) 的性能提高了 37 至 91 倍，性能提升非常顯著。想要獲得如此大的性能提升的唯一其他途徑就是擴(kuò)展集群規(guī)模。但是這種方式開銷較大。通過使用 GPU，用戶可以在提升性能的同時(shí)簡(jiǎn)化集群，減少額外節(jié)點(diǎn)和調(diào)度開銷。

然而，基于 GPU 的搜索有一個(gè)限制，那就是低并發(fā)情況。當(dāng)并發(fā)較高且在 CPU 和 GPU 內(nèi)存之間傳輸數(shù)據(jù)的減速小于搜索時(shí)間的總節(jié)省時(shí)，GPU 的性能比 CPU 好得多。在低并發(fā)情況下，GPU 的延遲較大，因?yàn)?CPU 可以比將數(shù)據(jù)傳輸?shù)?GPU 再從 GPU 傳回的時(shí)間內(nèi)更快地完成搜索。

示例

我們提供的示例演示了在商品檢索階段如何集成 Milvus 與 Merlin，其中用到了來自 RecSys Challenge 2015 的真實(shí)數(shù)據(jù)集進(jìn)行訓(xùn)練。同時(shí)，我們也訓(xùn)練了一個(gè)雙塔深度學(xué)習(xí)模型，用于學(xué)習(xí)用戶和商品向量。在本章節(jié)的最后，我們還會(huì)提供一些性能測(cè)試相關(guān)的信息，包括在性能測(cè)試過程中觀察的指標(biāo)和使用的參數(shù)范圍。

數(shù)據(jù)集

在集成和性能測(cè)試時(shí)，我們使用了由 YOOCHOOSE GmbH 在 RecSys Challenge 2015 中提供的數(shù)據(jù)集，可在 Kaggle 上下載。這個(gè)數(shù)據(jù)集中包含了歐洲在線零售商提供的用戶點(diǎn)擊/購買事件，其中包括與點(diǎn)擊/購買相關(guān)的會(huì)話 ID、時(shí)間戳、商品 ID 和商品類別等信息。這些內(nèi)容均可在文件 yoochoose-clicks.dat 中獲取。各個(gè)會(huì)話都是獨(dú)立的，不考慮回購用戶的情況。因此我們將每個(gè)會(huì)話視為屬于不同用戶的會(huì)話。該數(shù)據(jù)集包含 9,249,729 個(gè)會(huì)話（用戶）和 52,739 個(gè)商品。

工作流程主要包括：a) 數(shù)據(jù)獲取和預(yù)處理。b) 搭建雙塔深度學(xué)習(xí)模型，訓(xùn)練數(shù)據(jù)。c) 在 Milvus 向量數(shù)據(jù)庫中創(chuàng)建索引。d) 在 Milvus 向量數(shù)據(jù)庫中進(jìn)行向量相似性搜索。接下來，我們會(huì)簡(jiǎn)要描述每個(gè)步驟，如果大家對(duì)每個(gè)步驟的詳情感興趣，請(qǐng)參考：https://github.com/bbozkaya/merlin-milvus/tree/main/notebooks

數(shù)據(jù)獲取和預(yù)處理

用 NVTabular 對(duì)數(shù)據(jù)進(jìn)行預(yù)處理。這個(gè)工具利用了 Merlin 的 GPU 加速能力，是高度可擴(kuò)展的特征提取和預(yù)處理組件，能夠幫助我們輕松處理 T 太字節(jié)級(jí)別的數(shù)據(jù)集、搭建訓(xùn)練基于深度學(xué)習(xí)的推薦系統(tǒng)。

NVTabular 經(jīng)過抽象，提供一套簡(jiǎn)化的代碼，使用 RAPIDS 的 Dask-cuDF 庫在 GPU 上實(shí)現(xiàn)加速計(jì)算。用 NVTabular 將數(shù)據(jù)讀入 GPU 內(nèi)存，并按需重新排列特征，最終導(dǎo)出為 Parquet 文件。最終得到了 7,305,761 個(gè)用戶向量和 49,008 個(gè)商品向量以供后續(xù)訓(xùn)練使用。在預(yù)處理時(shí)，我們還會(huì)將每列數(shù)據(jù)和值進(jìn)行分類，轉(zhuǎn)換為整數(shù)值。

模型訓(xùn)練

用 Two-Tower 深度學(xué)習(xí)模型來生成用戶和商品向量，隨后為這些向量創(chuàng)建索引并查詢向量。我們將用戶屬性（user_id, user_age）和商品屬性（item_id, item_category）輸入到 Two-Tower 模型中。這個(gè)過程中，可以選擇是否要包含一個(gè)目標(biāo)列，只包括具有正交互作用的行。模型訓(xùn)練完成后，提取學(xué)習(xí)到的用戶和商品嵌入向量。

接下來是兩個(gè)可選步驟：

1. 使用 DLRM 模型對(duì)檢索到的商品進(jìn)行排序。

2. 使用特征存儲(chǔ)（在本例中為 Feast）存儲(chǔ)和檢索用戶和商品特征。在本示例中，加入了這兩個(gè)步驟從而更為完整地展示推薦系統(tǒng)的多階段工作流程。

最后，將用戶和商品向量導(dǎo)出為 parquet 文件，稍后可以重新加載并為其在 Milvus 中創(chuàng)建向量索引?，F(xiàn)在，可以啟動(dòng) Milvus 服務(wù)器并上傳商品向量、創(chuàng)建向量索引。然后，在推理時(shí)使用 NVIDIA TIS 和自定義的 Merlin 系統(tǒng) Operator 對(duì)現(xiàn)有用戶和新用戶進(jìn)行相似性搜索查詢。請(qǐng)參見 notebook 中的第二個(gè)示例。

構(gòu)建和查詢 Milvus 索引

Milvus 通過在推理機(jī)上啟動(dòng)一個(gè)“服務(wù)器”來實(shí)現(xiàn)向量索引和相似度搜索。在 notebook 2 中，我們通過 pip 安裝了 milvus 服務(wù)器和 pymilvus，然后使用默認(rèn)的監(jiān)聽端口啟動(dòng)了服務(wù)器。接下來，我們將演示如何使用兩個(gè)函數(shù) setup_milvus 和 query_milvus 來構(gòu)建一個(gè)簡(jiǎn)單的索引（IVF_FLAT）并對(duì)其進(jìn)行查詢。

當(dāng)我們將相同任務(wù)作為 TIS 框架中的多階段推理的一部分完成時(shí)，事情變得更有趣了。Merlin 提供了一個(gè)高級(jí) API，Merlin Systems，允許將推薦系統(tǒng)的不同階段組合成一個(gè)單獨(dú)的鏈?zhǔn)健凹赡Ｐ汀薄Ｒ虼?，上述所有階段都在對(duì) TIS 發(fā)送的單個(gè)請(qǐng)求中執(zhí)行。在這里，我們實(shí)現(xiàn)了一個(gè)自定義的 Merlin Systems 操作符作為集成的一部分，名為 QueryMilvus。

細(xì)心的朋友可能已經(jīng)注意到，pymilvus 庫沒有使用 GPU 加速，而 NVTabular 和 Merlin Models 卻使用了 GPU。這是因?yàn)?Milvus 的 GPU 加速版本需要啟動(dòng)多個(gè)容器，而我們使用的 Merlin 容器不支持這樣做。相反，通過 pymilvus，在 notebook 所在的同一個(gè)容器中將 Milvus 服務(wù)器作為一個(gè)進(jìn)程啟動(dòng)。要在 GPU 上運(yùn)行 Milvus，可以參考最新的 Milvus 發(fā)版說明：https://github.com/milvus-io/milvus/releases/tag/v2.3.1

下面性能測(cè)試是在 GPU 上完成的，使用的是 Milvus 最新版。

基準(zhǔn)測(cè)試

為了證明使用快速高效的向量索引/搜索庫（如 Milvus）的必要性，我們?cè)O(shè)計(jì)了兩組性能測(cè)試。

1. 使用 Milvus 構(gòu)建向量索引，我們生成了兩組向量：1）針對(duì) 730 萬個(gè)用戶向量，按照 85% 的訓(xùn)練集（用于索引）和 15% 的測(cè)試集（用于查詢）進(jìn)行劃分；2）針對(duì) 4.9 萬個(gè)商品向量，按照 50% 的訓(xùn)練集（用于索引）和 50% 的測(cè)試集（用于查詢）進(jìn)行劃分。性能測(cè)試針對(duì)每個(gè)向量數(shù)據(jù)集獨(dú)立進(jìn)行，生成獨(dú)立的結(jié)果。

2. 使用 Milvus 構(gòu)建一個(gè)針對(duì) 4.9 萬個(gè)商品向量數(shù)據(jù)集的索引，并基于該索引使用 730 萬個(gè)用戶向量進(jìn)行相似性搜索。

在性能測(cè)試中，我們使用了 GPU 和 CPU 版的 IVF_PQ 和 HNSW 索引算法，并嘗試了各種參數(shù)組合。詳細(xì)信息請(qǐng)參見：https://github.com/bbozkaya/merlin-milvus/tree/main/results

在生產(chǎn)環(huán)境中，一個(gè)重要的性能考量指標(biāo)是搜索質(zhì)量和吞吐量之間的平衡（tradeoff）。Milvus 允許完全控制索引參數(shù)，以探索這個(gè) tradeoff，以達(dá)到與基準(zhǔn)結(jié)果相關(guān)的更好搜索結(jié)果。這可能意味著減少吞吐率或每秒查詢數(shù)（QPS），增加計(jì)算成本。我們使用召回率指標(biāo)來衡量 ANN 搜索的質(zhì)量，并提供了 QPS -召回率曲線來展示 tradeoff。然后，您可以根據(jù)計(jì)算資源、延遲/吞吐量需求來決定可接受的搜索質(zhì)量水平。

還請(qǐng)注意我們基準(zhǔn)測(cè)試中使用的查詢批處理大小（nq）。這在工作流中非常有用，其中會(huì)同時(shí)向推理發(fā)送多個(gè)請(qǐng)求（例如，將離線推薦請(qǐng)求發(fā)送給一系列電子郵件收件人，或者通過匯集并同時(shí)處理到達(dá)的并發(fā)請(qǐng)求生成在線推薦）。根據(jù)具體情況，TIS 還可以幫助以批處理方式處理這些請(qǐng)求。

結(jié)果

以下展示基于 CPU 和 GPU 的 3 組性能測(cè)試結(jié)果。該測(cè)試使用了 Milvus 的 HNSW（僅 CPU）和 IVF_PQ（CPU 和 GPU）索引類型。

商品向量間相似度搜索

對(duì)于給定的參數(shù)組合，將 50% 的商品向量作為查詢向量，并從剩余的向量中查詢出 top-100 個(gè)相似向量。我們發(fā)現(xiàn)，在測(cè)試的參數(shù)設(shè)置范圍內(nèi)，HNSW 和 IVF_PQ 的召回率很高，分別在 0.958 - 1.0 和 0.665 - 0.997 之間。這表明 HNSW 在召回率方面表現(xiàn)更好，但是 IVF_PQ 在 nlist 較小的情況下也能得到非常高的召回率。此外，召回率的值隨著索引和查詢參數(shù)的變化也會(huì)發(fā)生很大的變化。報(bào)告結(jié)果是在對(duì)一般參數(shù)范圍進(jìn)行初步實(shí)驗(yàn)并進(jìn)一步深入選擇子集之后獲得的。

在給定參數(shù)組合下，使用 HNSW 在 CPU 上執(zhí)行所有查詢的總時(shí)間范圍在 5.22 到 5.33 秒之間（在 ef 不變的情況下，隨著 m 的增大而更快），而使用 IVF_PQ 在 13.67 到 14.67 秒之間（隨著 nlist 和 nprobe 的增大而變慢）。如圖 3 所示，GPU 加速確實(shí)效果更明顯。

圖 3 顯示了在 CPU 和 GPU 上，使用 IVF_PQ 和這個(gè)小數(shù)據(jù)集時(shí)召回率和吞吐量之間的 tradeoff。我們發(fā)現(xiàn)，GPU 在所有測(cè)試的參數(shù)組合下都實(shí)現(xiàn)了 4 到 15 倍的加速（隨著 nprobe 的增大而加速更明顯）。這個(gè)結(jié)果是比較每個(gè)參數(shù)組合下 GPU 的每秒查詢數(shù)與 CPU 的每秒查詢數(shù)得出的?？傮w而言，這個(gè)小數(shù)據(jù)集對(duì)于 CPU 或 GPU 來說都很容易處理，而且不難看出，還有進(jìn)一步加速空間。

圖 3. 在 NVIDIA A100 GPU 上運(yùn)行

Milvus IVF_PQ 算法的GPU 加速

（商品與商品相似性搜索）

用戶向量間相似性搜索

對(duì)于更大的第二個(gè)數(shù)據(jù)集（730 萬個(gè)用戶），我們將 85%（約 620 萬個(gè)）的向量用于“訓(xùn)練”（要建立索引的向量集），剩下的 15%（約 110 萬個(gè)）作為“測(cè)試”或查詢向量集。在這種情況下，HNSW 和 IVF_PQ 表現(xiàn)非常出色，召回率分別為 0.884-1.0 和 0.922-0.999。然而，它們?cè)谟?jì)算上要求更高，尤其是在 CPU 上使用 IVF_PQ 的情況。使用 HNSW 在 CPU 上執(zhí)行所有查詢的總時(shí)間范圍為 279.89 至 295.56 秒，而使用 IVF_PQ 的總時(shí)間范圍為 3082.67 至 10932.33 秒。注意，這些查詢時(shí)間是對(duì) 110 萬個(gè)向量進(jìn)行查詢的累積時(shí)間，因此可以說針對(duì)索引的單個(gè)查詢?nèi)匀环浅？?。然而，如果推理服?wù)器要對(duì)數(shù)百萬個(gè)商品并發(fā)請(qǐng)求運(yùn)行查詢，不推薦使用 CPU 查詢。

使用 IVF_PQ 和 A100 GPU 時(shí)，吞吐量（QPS）提升 37 至 91倍 （平均為 76.1 倍）。這與我們?cè)谛?shù)據(jù)集中觀察到的結(jié)果一致，這表明處理數(shù)百萬向量數(shù)據(jù)時(shí)，Milvus 結(jié)合 GPU 加速可以大幅提升性能。

圖 4. 在 NVIDIA A100 GPU 上運(yùn)行

Milvus IVF_PQ 算法的GPU 加速比

（用戶-用戶相似性搜索）

此外，圖 5 顯示了在 CPU 和 GPU 上使用 IVF_PQ 測(cè)試的所有參數(shù)組合的召回率- QPS tradeoff。該圖中每個(gè)點(diǎn)（上為 GPU，下為 CPU）展示了在改變向量索引/查詢參數(shù)時(shí)召回率和吞吐量的 tradeoff：更高召回率的代價(jià)是較低吞吐量。注意，在使用 GPU 的情況下，提高召回率時(shí)，QPS 會(huì)大幅降低。

圖 5. 在 CPU 和 GPU 上使用 IVF_PQ

進(jìn)行測(cè)試的參數(shù)組合及其召回率-吞吐量

tradeoff（user-use）

用戶與商品向量間相似度搜索

最后，考慮另一個(gè)現(xiàn)實(shí)場(chǎng)景，即將用戶向量與商品向量進(jìn)行比較（如上面的 notebook 1 所示）。在這種情況下，我們?yōu)?49000 個(gè)商品向量創(chuàng)建索引，為每個(gè)用戶向量查詢其 top-100 最相似的商品。

在 CPU 上進(jìn)行向量批量查詢非常耗時(shí)，無論是使用 HNSW 還是 IVF_PQ 索引（請(qǐng)參見圖 6）。而 GPU 在這種情況下表現(xiàn)更好。當(dāng) nlist = 100 時(shí)，IVF_PQ 在 CPU 上平均計(jì)算時(shí)間約為 86 分鐘。但計(jì)算時(shí)間隨著 nprobe 值的增加而變化很大（當(dāng) nprobe = 5 時(shí)為 51 分鐘，而當(dāng) nprobe = 20 時(shí)為 128 分鐘）。NVIDIA A100 GPU 能夠?qū)⑿阅芴嵘?strong>4 至 17 倍（當(dāng) nprobe 較大時(shí)，速度提升更高）。前文也提到，通過其量化技術(shù)，IVF_PQ 算法還可以減少內(nèi)存占用。這樣看來，如果結(jié)合 GPU 加速方案，能夠得到一個(gè)計(jì)算上更可行的 ANN 搜索解決方案。

圖 6. 在 NVIDIA A100 GPU 上運(yùn)行

Milvus IVF_PQ 算法的GPU 加速比

（用戶-商品相似性搜索）

與圖 5 類似，圖 7 顯示了使用 IVF_PQ 測(cè)試的所有參數(shù)組合的召回率-吞吐量間的 tradeoff。我們?nèi)匀豢梢钥吹皆?ANN 搜索中，為了提高吞吐量，可能需要稍微犧牲一些準(zhǔn)確性，尤其是在使用 GPU 的情況下。也就是說，我們可以在 GPU 的計(jì)算性能上保持相當(dāng)高的水平，同時(shí)實(shí)現(xiàn)高召回率。

圖 7. 使用 IVF_PQ 索引在 CPU 和 GPU 上

測(cè)試的所有參數(shù)組合及其對(duì)應(yīng)召回率-吞吐量

tradoff（用戶 vs 商品）

結(jié)論

最后，和大家分享一些思考。

現(xiàn)代推薦系統(tǒng)復(fù)雜和多階段的特質(zhì)對(duì)每個(gè)環(huán)節(jié)的性能和效率都有很高的要求。因此，大家可以考慮在推薦系統(tǒng)流程中使用以下兩個(gè)關(guān)鍵功能：

• NVIDIA Merlin 及其 Merlin Systems 庫：您能夠輕松插入高效的 GPU 加速向量搜索引擎 Milvus。

• 使用 GPU 加速計(jì)算，用諸如 RAPIDS RAFT 等技術(shù)來進(jìn)行向量數(shù)據(jù)庫索引和 ANN 搜索。

上述測(cè)試結(jié)果表明，本文所提出的 Merlin-Milvus 集成方案在訓(xùn)練和推理方面都非常高效且比其他方案更簡(jiǎn)單。而且，這兩個(gè)框架都在積極開發(fā)中，每個(gè)版本都會(huì)添加許多新功能，例如，Milvus 新增了基于 GPU 加速的向量數(shù)據(jù)庫索引。向量相似性搜索是計(jì)算機(jī)視覺、大語言模型系統(tǒng)、推薦系統(tǒng)等工作流程中的關(guān)鍵組成部分，因此十分推薦您嘗試使用 Milvus 向量數(shù)據(jù)庫。

最后，要感謝 Zilliz/Milvus 和 Merlin 以及 RAFT 團(tuán)隊(duì)為完成這個(gè)項(xiàng)目和這篇博客文章所做出的貢獻(xiàn)。當(dāng)然，如果大家在自己的推薦系統(tǒng)或其他工作流程中使用了 Merlin 和 Milvus， 也歡迎和我們分享。

參考文獻(xiàn)和資源鏈接：

• Public repo for this blog：https://github.com/bbozkaya/merlin-milvus

• Yoochoose dataset：https://www.kaggle.com/datasets/chadgostopp/recsys-challenge-2015

• Recommender Systems, Not Just Recommender Models：https://medium.com/nvidia-merlin/recommender-systems-not-just-recommender-models-485c161c755e

• Exploring Production Ready Recommender Systems with Merlin：https://medium.com/nvidia-merlin/exploring-production-ready-recommender-systems-with-merlin-66bba65d18f2

• Scale faster with less code using Two Tower with Merlin：https://medium.com/nvidia-merlin/scale-faster-with-less-code-using-two-tower-with-merlin-c16f32aafa9f

• Transformers4Rec: A flexible library for Sequential and Session-based recommendation：https://medium.com/nvidia-merlin/transformers4rec-4523cc7d8fa8

• NVIDIA Merlin：https://github.com/NVIDIA-Merlin

• Milvus repo：https://github.com/milvus-io/milvus

• Milvus use-cases：https://medium.com/vector-database/tagged/use-cases-of-milvus

• Hierarchical navigable small worlds (HNSW)：https://zilliz.com/blog/hierarchical-navigable-small-worlds-HNSW

• Triton inference server：https://github.com/triton-inference-server

• NVIDIA RAFT：https://github.com/rapidsai/raft

• Vectordb benchmarking library：https://github.com/zilliztech/vectordb-benchmark