一、業務背景

隨著以OpenAI為代表的AI生成式技術不斷突破，在萬物皆可向量化的時代直接帶動向量計算和存儲需求大幅提升，讓向量存儲和計算技術關注度達到新高，業界涌現出各類向量數據庫。阿里媽媽擁有豐富的AI應用場景，我們基于過去在向量引擎的積累和AI場景下需求，在近五年時間里不斷迭代升級，沉淀出Dolphin VectorDB，具有大規模、高性能、低成本且易開發的優勢，在媽媽內容風控、營銷知識問答、達摩盤人群AI圈人和AI經營分析師等場景中落地應用。尤其在支持內容風控10億級超大規模向量檢索場景中，使用Dolphin VectorDB表現出性能、成本及易用性綜合優勢，獲得顯著收益：

• 索引構建加速：索引構建時間減少71%。
• 檢索速度更快：檢索RT快3倍。
• 資源使用更省：服務資源節省75%。
• 研發效能提升：開發向量召回業務效率從天/小時提升到分鐘級別。

二、行業技術調研

業界主要分為向量數據庫和有向量能力的數據庫兩條技術路線：

1. 向量數據庫 (Specified Vector Database)：提供基于SDK的RPC/HTTP調用，專門用于向量數據的構建、存儲和查詢。
2. 支持向量能力的數據庫：基于已有各類通用數據庫系統，再結合向量庫(Vector Library)實現向量數據的構建、存儲和查詢能力。

2.1 業界現狀

業界向量數據庫百花齊放，但面臨復雜業務場景仍有些不足：

1. 傳統支持向量能力的數據庫主要面向靜態向量數據，不適用于索引數據頻繁更新場景，不支持實時向量寫入及更新。
2. 向量數據庫普遍支持在線計算，但沒有專門針對離線批量計算場景，而真實場景同一業務會有在線和離線批量兩類計算需求，很多情況下在線和離線計算不是一套服務，導致在線和離線因索引不同查詢結果不一致。
3. 現有產品在大規模、高性能和低成本這三個方面很難平衡，既能滿足大規模、高性能，還能保證低成本的挑戰很大。

基于當前現狀，Dolphin VectorDB選擇第二條技術路線（支持向量能力的數據庫），基于Dolphin多年在MPP數據庫方向能力積累，實現高性能向量數據庫能力。

三、技術演進

Dolphin（延展閱讀：??Dolphin：面向營銷場景的超融合多模智能引擎??）自2019年開始探索向量計算，向量引擎底層計算能力經歷從最初版使用Hologres內置向量插件，到基于Faiss自研2.0版，逐步迭代到3.0版基于DFS共享存儲（DFS類似開源的HDFS），最后升級到現在的Dolphin VectorDB，每一次升級背后都是業務規模擴展和新功能需求，推動技術不斷迭代進化。

3.1 向量引擎1.0

為支撐阿里媽媽達摩盤和直通車BP人群Lookalike業務（Lookalike是一種基于種子人群特征放大人群規模的算法技術），Dolphin向量引擎1.0版基于Hologres實現1.0版本向量計算能力（延展閱讀：??阿里媽媽Dolphin智能計算引擎基于Flink+Hologres實踐??），通過計算種子人群中心向量，然后從總體中召回Top K實現人群擴展。整個人群Lookalike擴展過程如下圖所示。

在業務支持中Dolphin初步集成基于Hologres的向量召回能力。

3.2 向量引擎2.0

在1.0版技術方案中，單shard模式有單點瓶頸，集群CPU利用率不高，多shard會構建分布式索引，但性能一般。為解決性能瓶頸，我們基于GreenPlum（下文簡稱“GP”）數據庫和faiss自研實現2.0版（方案已開源，gpdb-faiss-vector 項目地址：https://github.com/AlibabaIncubator/gpdb-faiss-vector），延展閱讀：??Dolphin：面向營銷場景的超融合多模智能引擎??），基于UDF實現索引構建和查詢能力，并采用共享緩存方案減少索引切換開銷，性能上實現支持總向量百萬規模，單類目幾十萬規模的向量召回計算。

基于GP的方案，對于小規模索引我們采用復制表可大幅提升QPS；對于帶類目(cate_id)的場景我們使用分布式表方案，其中對于復制表場景壓測QPS（800CU資源）可以達到5000+qps。

此外還做了復制表和分布式表測試，其中復制表是把索引復制到每一個計算節點；分布式表是按cate把索引劃分到不同節點，對每個cate_id構建一份索引。

此外為支持Lazada算法千萬級大規模批量向量召回需求，我們基于GP實現離線批量計算方案，雖然自研方案性能有較大提升，但是索引構建是在數據庫進行，會受限于數據庫存儲限制，最大構建的索引限制為1G，導致更大規模的索引無法使用數據庫構建，于是我們又進行新一輪升級。

3.3 向量引擎3.0

從系統架構上來看，Dolphin向量引擎2.0本質上是基于數據庫的插件實現，其索引構建與召回流程完全依賴于數據庫系統內核和執行器調度，存在諸多限制，比如索引大小不能超過1G的數據庫字段限制，單個集群構建的索引只能自用無法共享等。

為支持構建億級向量索引，我們設計3.0方案，在數據庫segment節點實現外置獨立向量服務，只依賴于數據庫的數據分發與SQL化接口能力，理論上可以實現任意大小索引構建存儲和查詢。

從執行流程上看，通過對索引構建和向量召回的流程進行拆分，并將構建好的索引導入DFS存儲，實現了一次索引構建可供在線、批量甚至多個集群讀取使用，并以本地磁盤、內存實現索引多級緩存，極大提升了召回流程效率，同時也保障了在線向量召回集群不會受索引構建任務影響。

Dolphin向量引擎3.0可以很好支持超大規模向量索引構建和在離線一致性查詢能力，但面對大模型實時寫入更新場景還無法支持。

3.4 Dolphin VectorDB

Dolphin VectorDB源于跟內容風控團隊合作共建，??內容風控業務涉及圖文、視頻內容的安全底線??，過去在很多重要風控事件中發揮重要作用，對向量召回能力要求低延遲、高吞吐、一致性和易用性。過去內容風控主要使用集團內DII、BE和Proxima CE 三套檢索引擎來實現業務需求，但是仍面臨巨大挑戰：

• 低延遲：在線審核鏈路要求低延遲、實時增量更新黑圖、文相似樣本庫，同時因為對廣告主審核有體感，需要非常高的穩定性保障要求。
• 高吞吐：離線會面臨百億級別歷史全量廣告送審內容的高吞吐壓力，例如敏感圖文問題，此外還必須按照監管要求時間內完成全量圖文內容清理。
• 一致性：在線和離線因為使用不同架構引擎導致索引召回不一致，可能有在線或離線風險外露風險。
• 易用性：內容風控一共20+檢索業務，使用了DII、BE和Proxima 3套方案，每一種方案針對特定的問題都能很好的解決，但會出現在離線不一致和維護成本高的問題。

面對風控復雜的場景需求和大模型場景新需求，我們基于向量引擎3.0版本進一步升級為Dolphin VectorDB，實現體系化的數據接入、查詢和索引構建等標準向量數據庫能力，實現一套引擎高效支持在線和離線業務需求。

四、技術架構

Dolphin VectorDB整體技術架構分為五個模塊，包括數據接入、查詢、執行、存儲及元數據管理。

4.1 模塊介紹

4.1.1 數據接入模塊

數據接入模塊是整個VectorDB的向量數據入口，負責外部實時及批量數據接入，元數據記錄以及調用執行模塊構建向量索引。數據接入分為兩個鏈路：

1. 實時鏈路：業務方通過SDK的請求經過消息隊列Kafka，然后實時更新到在線集群向量數據表中。
2. 離線鏈路：負責將odps數據表批量導入到在線集群，同時控制執行模塊對向量數據使用離線集群構建索引，導入存儲模塊DFS提供給不同集群使用。

4.1.2 查詢模塊

查詢模塊負責接收HTTP/RPC/SDK請求，先查詢元數據并對請求進行轉譯，再經過負載均衡路由到執行模塊。

1. HTTP/RPC：用戶輸入向量查詢SQL，直接轉譯、路由、執行
2. SDK：先對用戶輸入參數組裝為查詢SQL，然后走轉譯、路由、執行流程

4.1.3 執行模塊

執行模塊是與向量索引數據的計算直接相關的模塊，它的基本功能包括：

1. 接收數據接入模塊索引構建請求，從存儲模塊讀取原始的向量數據，構建向量索引文件存回遠端存儲
2. 將索引加載到不同的線上任務集群
3. 執行在線向量檢索服務和離線批量向量召回任務計算。

因此執行層是溝通其他各層的橋梁，接收數據接入層和查詢層的訪問。

執行模塊由多個負責在線、離線、索引構建任務的GP分布式數據庫集群組成，每個GP集群獨立負責對應的工作，互相之間共享一份向量索引。集群中的每個計算節點執行獨立或分布式并行計算。計算節點由GP數據庫進程和基于Faiss的向量引擎RPC服務進程構成，GP負責數據表存儲、SQL執行與任務分發，與向量引擎進程溝通。而向量引擎會實際執行從與存儲模塊溝通的數據讀寫，Faiss向量索引構建，執行單條或批量的向量召回計算。

4.1.4 存儲模塊

負責存儲原始向量數據和構建好的向量索引。

1. 負責原始向量和構建好的向量索引存儲 

2. 執行層需要數據可以直接從存儲層讀取。

4.1.5 元數據模塊

負責存儲索引構建的參數和表名信息，包括在線和離線場景數據，在線元數據用于查詢轉譯使用。

五、核心能力

5.1 在離線一致性

向量召回在線場景和離線場景往往是不同引擎，即使相同參數也大概率會有召回不一致，這對很多場景其實影響不大，但對于風控這類底線安全的場景，結果不一致會導致清理不完全風險外露，過去風控場景使用BE作為在線引擎，Proxima CE作為離線計算引擎，對在離線一致性的需求非常大。Dolphin VectorDB設計索引構建存儲和計算分離方案，構建好的索引存儲在共享存儲DFS，分別提供給在線計算服務和離線計算服務，這樣實現索引一次構建多場景使用，不僅減少構建成本，還保證在離線查詢結果一致。

5.2 實時更新

實時索引更新是在大模型場景和風控場景下強訴求，在線索引數據需要實時更新寫入到索引庫。我們基于數據庫表模型特點，實現基于數據庫實現的高性能實時更新能力，通過離線構建和實時寫入數據兩條鏈路，支持實時更新QPS可以達到萬級別。

實時更新設計架構

5.3 多模式查詢

針對索引的規模大小，分為兩種查詢模式，一種是針對大規模索引的分布式查詢；第二種是面向小規模索引的segment直查模式。

• 分布式查詢：對于大規模向量（一般千萬級以上），會把向量拆分存儲到不同segment，查詢的時候會從每一個segment查詢top k，然后master對segment結果匯總取最終topk。
• 直連查詢：對于小規模索引，會只構建一份索引，然后根據需求復制到多個節點，每一個節點都可以獨立直接提供查詢，避免master轉發請求，可以顯著提升集群QPS。

六、業務支撐

6.1 內容風控

內容風控業務主要包括阿里媽媽廣告場景下文字、圖片及視頻內容的風險識別及控制，沉淀基于音視圖文模型的風險識別能力，先把內容轉換為向量，然后基于向量識別風險，其中很重要的是向量相似計算。

通過共建合作，Dolphin VectorDB在2023雙十一期間支撐了風控場景face人臉檢索、risk free等重要業務，在升級使用Dolphin VectorDB后，風控檢索服務在離線一致性、服務器成本、性能和易用性有顯著優化提升，其中對于10億級超大規模向量檢索業務，索引構建時間減少71%，檢索RT快3倍，服務資源節省75%，開發效率從天/小時提升到分鐘級別。

6.2 營銷助手

在萬堂AI講師、媽媽有料問答助手和內部知識庫通過提供營銷知識問答，解決廣告主對知識和答案"找得到"的訴求。我們把語雀和萬堂書院等私域數據進行段落切分、知識點抽取、向量轉換處理后存儲在Dolphin VectorDB，然后提供在線文本向量查詢，對結果使用LLM做歸納總結。

6.3 人群AI圈選

在達摩盤圈人場景，過去是廣告主手動圈人，而達摩盤有上千標簽數百萬選項值，對幾十萬的中長尾客戶來講學習和使用門檻極高，而通過自然語言到人群標簽組合的方式極大降低圈人成本，降低理解和使用標簽組合圈人成本。在該場景下，我們會根據用戶輸入自然語言，通過向量召回相似標簽，然后組合標簽得到圈人組合。

七、未來展望

向量計算能力是生成式AI場景下必備基礎能力，在搜索、推薦、廣告和大模型場景下都是重要能力依賴，其能力scope決定上層業務規模和性能，未來我們主要有兩個發展方向：

• 向量計算能力持續升級：業界對向量計算和存儲能力的需求會繼續提升，向量數據庫在超大規模場景下的計算性能、計算成本和易用性方面仍有較大發展空間，未來可拓展到百億規模計算。
• 多模計算能力融合：向量計算只是場景需求中的一個環節，真實場景中向量計算會跟很多其他計算結合，Dolphin本身定位多模態融合引擎，未來會由點到面，解決多模態復雜計算中的性能問題。

本文轉載自?? 阿里媽媽技術??，作者： 陌奈、赫琦