OpenAI 發佈 ChatGPT-4o，意味着人機交互進入新的時代。Chat-GPT4o 是一個跨文本、視覺和音頻端到端訓練的新模型，所有輸入和輸出都由同一個神經網絡處理。這也在告訴所有人，GenAI 連接非結構化數據，非結構化數據之間跨模態的交互正在變得越來越容易。
據 IDC 預測，到 2025 年，全球數據總量中將有超過 80% 的數據是非結構化數據，而向量數據庫是處理非結構化數據的重要組件。回顧向量數據庫的歷史，2019 年，Zilliz 首次推出了 Milvus，提出了向量數據庫的概念。2023 大語言模型（LLM）的爆火，將向量數據庫正式從幕後被推到了臺前，也因此趕上了發展的快速列車。
作爲相關技術人員，我從技術發展上能清晰地感覺到向量數據庫前進的速度，見證向量數據庫如何逐漸從簡單的 ANNS（https://zilliz.com.cn/glossary/%E8%BF%91%E4%BC%BC%E6%9C%80%E8%BF%91%E9%82%BB%E6%90%9C%E7%B4%A2%EF%BC%88anns%EF%BC%89） 套殼變得更加多變和複雜。今天，我想從技術的角度探討一下向量數據庫的發展方向。
技術的發展方向一定是跟隨了產品的變化趨勢，而後者則是由需求來決定。因此，順着用戶需求變化的脈絡能幫我們找到技術變化的方向和目的。隨着 AI 技術的日趨成熟，向量數據庫的使用也逐漸從實驗走到生產，從輔助產品走到主力產品，從小規模應用到大面積鋪開。這產生大量不同的場景和問題，也同時推動了解決這些問題的相應技術。下面我們從成本和業務需求兩個方面來展開講述。
01.成本
AIGC 時代對於冷熱儲存的呼喚
成本一直是向量數據庫獲得更廣泛使用的最大阻礙之一，這個成本來自兩點：
-
儲存，絕大多數向量數據庫爲了保證低延遲，需要把數據全量緩存到內存或者本地磁盤。在這個動輒百億量級的AI 時代，意味着幾十上百 TB 的資源消耗。
-
計算，數據需要劃分成許多小片段來滿足工程上分佈式支持大規模數據集的需求。對於每個分片需要單獨檢索再做規避，帶來了較大的查詢計算放大問題。百億級的數據如果按 10G 分片的話，會有一萬個分片，也就意味着計算放大了一萬倍。
主流 LLM 的響應時間，圖源：https://artificialanalysis.ai/models
而在 AIGC 帶來的 RAG 浪潮中，單個 RAG 用戶（或者是 ToC 平臺的單個 tenant）對於延遲的敏感度都極低。原因是相較於向量數據庫幾毫秒到幾百毫秒的延遲，作爲鏈路核心的大模型的延遲普遍超過秒級。加之雲端對象儲存的成本遠遠低於本地磁盤和內存，人們越來越需要一種技術，可以：
-
從儲存上來看，在查詢的時候數據放置在最便宜的雲端對象作爲冷存儲，需要的時候加載到節點，轉化爲熱儲存提供查詢。
-
從計算上來看，把每個查詢需要的數據提前縮小範圍，不用擴大到全局數據，保證熱儲存不會被擊穿。
這種技術可以幫助用戶在可接受的延遲下極大地縮減成本，也是我們 Zilliz Cloud （https://zilliz.com.cn/cloud）最近正準備推出的方案。
硬件迭代帶來的機遇
硬件的是一切的基礎，硬件的發展也直接決定了向量數據庫技術發展的方向。如何去適配和在不同場景下利用這些硬件就成了一個很重要的發展方向。
- 高性價比的 GPU
向量檢索是一個計算密集型的應用，這兩年使用 GPU 進行計算加速的研究也越來越多。與昂貴的刻板印象相反的是，由於算法層面的逐漸成熟，加之向量檢索場景適合內存延遲較低的且價格較爲便宜的推理卡，基於 GPU 的向量檢索展現出了出色的性價比。
CPU: m6id.2xlarge T4: g4dn.2xlarge A10G: g5.2xlarge Top 100 Recall: 98% Dataset: https://github.com/zilliztech/VectorDBBench
我們使用支持了 GPU 索引的 Milvus 進行測試，在僅僅 2-3 倍的成本下，無論是構建索引還是向量檢索，都展現出來了幾倍到數十倍的性能差距。無論是支持高通量的場景，還是用以加速索引的構建，都能極大地降低向量數據庫的使用成本。
- 日新月異的 ARM
各大雲廠商基於ARM架構在不斷地推出自己的 CPU，比如 AWS 的 Graviton，GCP 的 Ampere。我們在 AWS Graviton3 上做了相關測試，觀察到相比 x86，在提供更加低價的硬件的同時還能帶來更好的性能。而且這些 CPU 演進極快，比如在 2022 年推出 Graviton3 後，2023 年 AWS 發佈了 30% 算力提升和 70% 內存帶寬提升的 Graviton4（https://press.aboutamazon.com/2023/11/aws-unveils-next-generation-aws-designed-chips）。
- 強大的磁盤
將大部分數據儲存在磁盤可以幫助向量數據庫極大提高容量的同時達到百毫秒級別的延遲，而這個量級對大部分已經夠用了，同時磁盤的成本是內存的幾十甚至百分之一。
模型端的雙向奔赴
模型產生向量，向量數據庫支持向量的儲存和查詢。作爲一個整體，除了向量數據庫端在追求成本的降低外，模型端也在嘗試降低向量的大小。
比如在向量的維度上，傳統的在向量上引入的降維方案對於查詢的準確度影響都比較大，而 OpenAI 發佈的 ext-embedding-3-large （https://openai.com/index/new-embedding-models-and-api-updates/）模型可以通過參數控制輸出向量的維度，在降低向量維度的同時，對下游任務的效果影響很小。還有在向量的數據類型上，Cohere 近期的博客（https://cohere.com/blog/int8-binary-embeddings）宣佈了對於同時輸出float，int8 和 binary 等數據類型的向量的支持。對於向量數據庫來說，如何去適配這些改變也是需要積極去探索的方向。
02.業務需求
提升向量搜索準確程度
搜索的準確程度一直都是很重要的話題。無論是由於廣泛的生產應用，還是 RAG 應用中對於相關性要求更高，向量數據庫都在努力朝着更高的搜索質量發展。在這個過程中不斷有新的技術湧現，比如爲了解決 chunk 過大導致信息丟失的 ColBERT，還有解決域外信息檢索的 Sparse。下圖爲 BGE 的 M3-Embedding 模型的評估結果，它能支持同時輸出 Sparse、Dense 和 ColBERT 三種向量，表裏爲使用他們做 hybrid search 的搜索質量的對比結果。
對於向量數據庫來說，如何利用這些技術做混合搜索來提高檢索質量也是重要的發展方向。
- ColBERT
ColBERT 是一個檢索模型，爲了解決傳統雙塔模型大 chunk 導致的信息丟失問題，同時規避了常規檢索模型全連接導致的搜索效率問題，ColBert 提出基於 token 向量的遲交互模式。ColBERTv2 中還引入了向量檢索來加速最後的遲交互模式。
- Sparse
傳統的 dense 向量擅長捕捉語義信，但由於模型訓練時只能學習訓練數據中的知識，因此對於訓練數據未覆蓋的新詞彙或專業術語，dense 向量的表達能力有限。而這在實際應用中很常見。一般模型微調能一定程度上解決這個問題，但是成本較高且實時性會面臨挑戰。
此時，基於傳統關鍵詞匹配的 BM25 生成的 sparse 向量反而表現出色。再有 SPLADE、BGE 的 M3-Embedding 等模型在保留 sparse 向量關鍵詞匹配能力的同時，嘗試把更多的信息編碼進去，以進一步提高檢索質量。
其實業界在基於關鍵詞檢索和向量檢索的混合召回體系上已經應用了很久了。在向量數據庫中集成新一代的 sparse 向量，並且支持混合檢索能力也逐漸成爲共識。Milvus 也在 2.4 版本正式支持了 sparse 向量的檢索能力。
爲離線場景進一步優化向量數據庫
目前幾乎所有的向量數據庫都專注於在線的場景，包括 RAG（https://zilliz.com.cn/blog/ragbook-technology-development）、以圖搜圖（https://zilliz.com.cn/use-cases/image-similarity-search）等。
在線場景的特點是少量、高頻，且對延遲有較高的要求。哪怕是成本最敏感，性能最不重要的場景往往也要求秒級別的延遲。
事實上，在許多大規模數據處理的離線場景中,向量檢索扮演着重要角色。比如數據去重、特徵挖掘等批處理任務，或者將向量相似性作爲召回信號之一的搜推系統，通常會將向量檢索作爲離線預計算的環節，定期進行特徵更新。這些離線場景的特點是批量查詢、大量數據等，並且任務的耗時要求可能是分鐘級甚至小時級。
爲了支持好離線場景，向量數據庫需要解決許多新的問題，試着舉幾個例子：
-
計算效率：很多離線場景需要高效地做對大量數據的大批量查詢，比如一些搜推場景的離線計算部分。這種場景不要求單個數據的延遲，但是需要整體比在線場景更加高的計算效率。爲了更好的支持這類問題，像GPU索引等提高計算密度的能力需要被支持。
-
大量返回：數據挖掘經常使用向量檢索來幫助模型找到某一個類型的場景。這通常會需要返回大量數據，如何處理這些返回結果帶來的帶寬問題、大topK搜索的算法效率問題都是支持這類場景的關鍵。
如果能夠解決上述這幾點挑戰，向量數據庫能夠廣泛支持更多場景的應用，而非僅僅滿足在線應用。
更豐富的向量數據庫特性適應更多行業需求
隨着向量數據庫被越來越廣泛地應用在生產端，產生了許多不同的使用方法，也被應用在了不同的行業。這些和行業、具體場景高度相關的需求指導向量數據庫去支持越來越多的features。
-
生物製藥行業：通常用 Binary 向量表達藥物分子式進行檢索。
-
風控行業：需要找到最離羣的向量，而不是最相似的向量。
-
Range Search 功能：允許用戶設定一個相似度閾值,返回相似度高於該閾值的所有結果。它可以在無法預估結果數量的情況下，確保返回的結果都具有較高的相關性。
-
Groupby 和 Aggregation 功能：對於較大對非結構化數據(電影、文章)，我們通常分段生產向量，比如一幀畫面、一段文字。爲了能通過這些分段向量搜到符合要求的結果，向量數據庫需要支持 Groupby 和對結果做 Aggregation 的能力。
-
支持多模態模型：模型向多模態發展的趨勢會產生不同分佈的向量，在現有的算法下難以滿足檢索需求。
上述這些面向各個行業的改進功能更突出了向量數據庫動態發展的特點。向量數據庫將不斷升級優化，推出更豐富的特性以滿足各行各業 AI 應用的複雜需求。
03.總結
向量數據庫在過去的一年經歷了快速成熟的過程，無論從使用場景到向量數據庫自身能力都有了很大的發展。在越來越清晰可見的 AI 時代裏，這個趨勢只會越來越快。希望這些個人的總結和分析能夠拋磚引玉，爲向量數據庫的發展提供一些思路和啓發，一起擁抱未來更加激動人心的變化。