數據3.0時代，通過大模型+數據，使得企業/開發者用更少的代碼，或通過自然語言構建應用與交付業務的趨勢已成必然。通過大語言模型的對話能力，直接挖掘、釋放數據的價值，可以極大的降低數據使用者的門檻，爆發出更多的可能。
11 月以《大模型時代下的數據新視界》爲主題的線下社區 meetup，邀請產、學、研的領域專家圍繞大模型和數據衍生出的幾大探索方向：向量數據庫、LLM+Data、LLM+SQL、LLM+Tools 分享各自的技術探索和實踐經驗，共同探討關鍵問題和發展趨勢。接下來的幾期內容將以文字版的形式分享給 DB-GPT 社區的同學，共同學習和探討。
本文主要跟大家分享面向大模型時代的數據庫 Milvus，Milvus 項目從 2019 年開始就開源了，做了四年時間，也分成了兩個階段。從 2021 年開始一直是有個標籤叫 Cloud Native，2022 年開始也有了一個新的標籤 AI Native。
向量數據庫的誕生，其實就是去解決非結構化數據處理困難的一個問題。因爲非結構化數據不僅僅包含今天在聊的一些長文本的信息，還包括視頻、圖片、音頻等多模態信息，多模態大模型現在也是一個很火的話題。
大概從 2019 年開始，向量數據庫第一個切入的場景是圖搜和文圖互搜的場景，所以最開始的 target 就是解決 “非結構化數據如何進行檢索，如何去做語義檢索“ 的一個問題。當然，這裏面其實存在了很多的問題，有模型側的、有 infra 側的。
大家可以看到隨着動態模型的發展，包括大模型發展，問題其實已經有了比較初步的一些解決方案。但在 Infra 側，如果面向非常海量的數據，怎麼能從十億級別、百億級別的這些圖片裏面、文本里面很快地召回所需數據，去給大模型提供更好的能力。無論是做 RAG 或 Agent 裏面所謂的 Long-term memory ，或者說在大模型訓練推理的過程中，其實都有類似的訴求，這也是向量數據庫誕生的最開始的一個初心。
爲什麼向量檢索這件事會跟數據庫結合起來？大家如果提到如何去處理數據，一定會想到用 OB、ODPS 以及各種各樣的數據庫去做。但是在非結構化數據領域，從 AI 開始 popular，或者從 AI 變得 news network popular 開始，大家做的類似是一種煙囪式的應用。就是說一個 AI 的團隊，自己負責上面訓練模型下面洗數據，所有的數據治理，所有的 Infra 這一側，甚至是 pouch 都是算法團隊自己維護。當然可能大廠會好一些，但是我覺得在未來 AI 再往後發展 5 到 10 年的話，一定會有一個分層的過程，所以希望能夠給大家提供的是一個非常好的 AI 數據側的 Infra。
什麼是向量數據庫？簡單來理解向量數據庫就是管理和查詢高維向量的一個系統，它有幾個顯著特點：
第一，既然是一個數據庫，要具備基本的增刪改查的能力。現在很多的向量數據庫，或者說上一代的向量檢索系統，它的更新能力、刪除能力是非常弱的。還是類似傳統搜索的這種離線導入的模式，每天搞一批數據，訓完以後一把導進去。這樣來看，它不是一個向量數據庫，既然是一個數據庫，基本的 CRUD 是要支持的很好的，要有一個基本的schema 的定義，明確支持的數據類型，當然可以是一個 dynamic scheme，但是既然作爲數據庫，它應該符合數據庫的一些基本的要求。
第二，很顯然向量數據庫的一定要具備很強的向量檢索能力。
最後，向量數據庫的語義一定要足夠的豐富，只做 ANN 是不是向量數據庫呢？我認爲是的，向量數據庫最基本的操作就是最近零匹配，但實際上向量數據庫在發展的過程中，演化出了非常多新的語義，其實是一個非常有意思一個 topic 。所有的傳統的數據庫裏面能夠實現的操作，比如說 join、groupby、count，在向量數據庫裏都有對應的實現。
整個向量數據庫使用的過程可以分爲三個階段。第一個階段怎麼搞到向量？搞到向量當然就是靠 embedding 模型，OpenAI 的 Ada，國內也有非常好的開源模型，包括BGE、阿里的GTE，其實都是非常好的 embedding 的模型，embedding 生成以後，插入到向量數據庫當中來。中間會存在一個傳統搜索裏面大家都在做的一個事情，也就是第二階段索引構建。索引它是偏離線的，算力消耗很高，所以向量數據庫的一個核心挑戰就是如何能把索引的開銷給降低。另一個核心開銷就是說怎麼在索引的過程中儘可能的去挖掘數據之內的一些聯繫和語義，來降低 online serving的時候查詢負載。第三階段就是構建好索引後 Query，Query裏面也有很多核心挑戰。比如說如何應對 streaming version，如何應對delete，如何應對各種各樣複雜的語義，性能也是一個很重要的挑戰。
上圖是 Milvus 1.0 的架構圖，是最開始 2019 年的時候，定義向量數據庫應該長的樣子。簡單的理解就是有一個預寫日誌，有一個文件系統去存文件，有一個引擎如向量索引 Faiss/Annoy/HNSW， 有一些 meta 和 schema 的定義，可以去做一些基本的過濾操作，能夠支持簡單的刪除，但是性能不好，能夠支持多元的 SDK。這是最早的關於向量數據庫的一個定義，可以說在全世界也是第一個定義向量數據庫的。我們曾經發過一篇 SIGMOD 21，講的就是向量數據庫究竟是什麼。
由淺入深，向量數據庫的核心是什麼？其實就是向量索引，向量索引也是向量數據庫能夠高性能地進行索引數據、查詢數據的一個關鍵所在。
向量索引有非常多不同種類的實現，上圖列了 4 種比較主流的，比如基於數最典型的是 Annoy，還有基於哈希等。因爲性能、精確度問題，現在已經不是業界非常主流的查詢模式了，最主流的是基於Quantization 的 FAISS 。FAISS 是一個很好的實現，但在 Quantitation 的這條鏈路裏面，現在又有了一個比較有競爭力的 competitor 是 google 的 scan，這也是在開源裏面性能比較好的一個框架。最後一個就是精靈圖，那麼在精靈圖領域最廣爲人知的是 HNSW，它其實是類似於跳錶的一個設計。最底層是一個完整圖，上層建了一些索引圖。這樣子大家在搜索的時候可能跟一個跳錶一樣，先從上面找到一些鄰居節點，一層層往下找，找到最底下最終的一個查詢結果。圖也有非常多的變種，比如說雅虎開源的 NGT、Microsoft 開源的基於磁盤的圖方案。感興趣的話大家可以去讀相關的 paper，基本上每個項目背後都有相應的 paper，也可以看看向量檢索的一個鏈路。
我們需要一個數據庫，也需要向量檢索，那爲什麼不是 PGvector 或者 Elasticsearch 呢？這就是一個特斯拉和老爺車之間的關係，這麼類比，最主要的原因是如同所示的這幾個點：
第一，向量數據和標準數據之間數據的分佈是存在很大的差異的。舉一個例子，所有的傳統數據庫，基本上是基於哈希去做路由，或者說基於 range 去做分片的，這樣在查詢的時候才能比較高效地利用主鍵索引、二級索引。但在向量數據庫中，無法用向量去做分片，這是一個最基本的邏輯，因此對於絕大多數的向量數據庫而言，搜索是需要去查所有分片的，這更像是一個 OLAP 的使用場景。就是有點類似於 MPP 的架構，但是又不完全是 MPP 的架構，所以很多 OLTP 數據庫天然就已經不適合去做向量檢索這些事情了。
第二，Not hundred percent accurate matters。什麼叫不完全正確很重要？是因爲大模型本身就不是一個很鎮定性的一個系統，它並不能給確定性的答案。而大模型的搜索需要的也不是一個百分之百正確的一個答案，它需要的是相似匹配的一個答案，這就是大家所謂的語義。那這種語義帶來的作用是什麼？大家都知道 OB 系統它能應用在 transaction 的用場景裏面，靠的就是穩定性，靠的就是正確性，任何一筆 transaction 都是不能錯的。而在向量檢索領域裏面，約束條件可以把它去掉了，它根本不關鍵，只要能拿到一個相對來講 reasonable 的一個答案就 ok 了。因此背後會有一個非常大的 optimize 的空間。如果所有的數據庫不需要保證百分之百正確，大家可以想象數據庫可以優化 10 倍，可以優化 100 倍，空間是非常大的。過去提的 AI for DB 的概念，在傳統數據庫裏面會發現應用起來會非常難，但是在向量數據庫就可以 work，並且 work 得非常好。用模型去做 Auto Tune，效果非常好，並且損失非常低。
第三，算力的要求。傳統的數據庫瓶頸可能會在 IO 上面，也可能會在網絡上面，部分數據庫可能會在 CPU 上面，絕大多數數據庫，尤其是 OLTP 數據庫，它的瓶頸一般都不會在 CPU 上面。但對於向量數據庫，它的瓶頸就在 CPU 上面，或者更精確一點就在內存帶寬上面，這就意味着其所面臨的挑戰跟傳統的數據庫是完全不一樣的。因此需要嘗試用很多方法，要優化帶寬，要優化 Cache、異構算力，這也是爲什麼向量數據庫可以跟 GPU 很好結合的一個原因。
最後一個點，語義的複雜度會變得越來越高。過去向量數據庫是做 ANN 的，Elasticsearch/PG 也能做 ANN，但是向量數據庫不止於此。
可以看到有很多查詢的 pattern 出現，比如基於聚類去做過濾。舉個例子，現在搜索狗的照片，但是表達爲 “不想要貓的照片”，這類查詢如果如果放在一個 fast 裏面，應該去怎麼做？我覺得很難去做，只能再給貓打個標籤，這又回到了傳統數據庫的老路上面去。但能不能把貓的聚類完全給過濾掉，或者說能不能做一個更有意思，叫做 KNN join 的一個場景。就是給兩個表，一個表裏面放男嘉賓，一個表裏面放女嘉賓，通過向量的近似度的方式去把男嘉賓和女嘉賓 match 在一起去，這些其實是一些非常有意思的一些場景。也就是說傳統數據庫能做的東西，很多事情向量數據庫都可以做，關鍵是怎麼做。
我們爲什麼要做 2.0 產品？對於上面描述的 Milvus 1.0 的產品架構，是一個非常 naive 的一個數據庫實現。從 2021年開始，我們決定要把數據庫重做一遍，一個標籤就是雲原生和 scalability 。
當然要做雲原生的話，肯定有些關鍵點是跑不了的。第一，如何跟雲基礎設施結合？做了存算分離，流式數據是存在一個 distribute WL 裏面的。第二個很重要的點就是隨着數據量的增大，用戶的數據確實放不下了，這也是促使我們必須做分佈式系統的重要原因。第三，如何與公共雲結合。2021年，K8S 已經非常成熟的一個系統了，所以團隊就一直在思考怎麼能用 K8S 更好的去跑一個無狀態的數據庫。最後第四點，對 AIGC 的使用場景中，Serverless 是非常重要的一個點。因爲絕大多數的大模型都是 API 的 service，所以對於廣大的開發者來講，他們不希望自己去維護底層的基礎設施。最後，情懷。拋開商業因素，Zilliz 希望做一款頂尖的數據庫產品，希望可以做成一款分佈式的向量數據庫，結果也確實做出來了。
如上圖，這是 Milvus2.0 爲用戶提供的一些核心的能力。
第一，雲原生分佈式，我們希望能支持百億規模的向量擴展，具備足夠好的彈性存算分離。所有的數據全部都是存在底層的存儲裏面的，對象存儲、消息隊列等。
第二，流批一體，這並不是所謂的這種傳統的 lambda 裏面的流式，而是希望真正在一套系統裏面能夠很好的去解決用戶的流式插入，並且能夠實時查詢的這種能力。
第三，引擎可插拔。大家可以看到整個 record index 有非常多的選擇，不同的選擇之間是有不同 trade-off。有的性能更好，有的內存佔用更低，沒有辦法說出一個完美的索引，滿足所有人的需求。現在來看，可能對於大公司來講，性能是一個很重要的 concern。但對小公司來講，可能成本或者內存的佔用，這些其實變成非常重要的指標，因此希望引擎本身是可以可插拔的。
最後，雲端一體，大家可以非常容易的在自己的筆記本上去做部署，也可以在自己公司的 K8S 裏面去跑，更爲重要的是可以在雲上去跑。
未來在大模型的生態中，API 會成爲最重要的一個武器。大家已經看到了OpenAI 的 assistant，包括它的 GPTS，本質上其實就是 functional call。雖然也提供了很多 retrieve 的能力，但至少 function calling 是最重要的。它可以把所有很多東西串在一起，能夠幫助開發者最快速的去構建。因此API可能會變成未來數據庫產品的一個飛輪。有 SQL 的支持固然很好，但如果沒有 SQL 支持，API 足夠的 popular，大模型學會了如何去寫 API 的話，開發者的門檻一樣是很低的。
如上圖，這是 Milvus2.0 的最終架構，整個的設計理念其實就兩點，第一存算分離，第二所有的計算節點微服務化。所有索引節點，所有的 query 節點，所有的數據節點，包括前面的代理全部都是 K8S 的 pod，全部都是微服務化。所有的數據全部都存在中間這一層，基於 Kafka 和 S3 去存，系統可以跟着 K8S 非常快的去做 scale，只需要去做一些內存的變化，一旦 scale 以後，數據直接從 S3 裏面拉起來。
Milvus 還提供了面向 AIGC 場景的一些豐富能力。這些是在上一代的向量檢索中所缺失的。
Sparse embedding，就是大家非常熟悉的 TF-IDF（Term Frequency-Inverse Document Frequency）和 BM25（Best Match 25）。但今天的稀疏向量有基於 AI 的提取方式，它可以更好地去幫大家做關鍵詞的匹配，標量和向量的混合查詢能力以及豐富的 API 支持。
支持多租戶，如果今天要構建一個 knowledge base，可能有 100萬個用戶，在數據庫裏面它的 schema 到底應該如何設計？如果使用傳統的一個表一個用戶的方式，可能的表的數目會爆炸。如何能在一個向量數據庫裏面很好的去支持多租戶是一個挑戰，不過 Milvus 已經具備了這種能力。
海量數據離線導入的能力，類似於 hbase 裏面的 Bulk Insert、Bulk Load。有這種非常快速可以把億級甚至 10億級別的數據導入到向量數據庫裏面並立即提供查詢的一個能力。
另外，Dynamic Schema；Range search；磁盤索引，基於 MMAP 的把數據放在磁盤上的能力，這是絕大多數向量數據庫不具備的能力。
除此之外還有很多其他能力，比如說 CDC、多向量的支持、標量索引的倒排等，這些都是在的設計的計劃裏，預計會在今年陸續上線。
最後說一下性能。提起向量數據庫，用戶最關心的一定就是性能。如果大家感興趣或者是做向量數據庫，可以跑一下的 VectorDB Benchmark，它是完全開源的，有比較豐富的測試集，包括過濾的測試集、各種各樣不同參數的搜索、不同大小的數據集。
那麼如何去優化數據集呢？其實主要就三件事情。第一是算力，如何找到最便宜最高效的算力，除了 GPU 以外，ARM 是可以去深度挖的一個點，包括所有 Intel CPU 新的指令集，現在用 AVX-512 VNNI 以及最新一代的 amx 指令集，其實對性能有非常好的提升。目前，支持的 ARM SVE 的廠商比較少，我們是在 amx 上面去做的。另外，支持NVIDIA 最新的 GPU 圖索引，我們也把它貢獻給了社區，性能比傳統的 GPU index 要好很多。
第二個其實是算法側，算法包括怎麼去優化圖，怎麼去提升圖的質量，怎麼在搜索的過程中儘可能去剪枝，是優化性能一個很重要的方式。
最後，是查詢的調度，包括 dynamic batching，如何做請求的合併，如何讓集羣的負載變得更加的均衡，回到傳統數據庫的領域。所以向量檢索事情本質上是一個高性能計算加數據庫，這是大家要去做的一個事情。
這些傳統的場景大家可以看下，不再過多去展開了，大家如果是做這些相關業務的話，可以具體去聊。
第一個應用比較多的場景是 RAG ，主要解決了四個問題。第一個是大模型的幻覺問題，第二個是數據的新鮮度問題，第三個是數據的安全問題，最後一個是用大模型去輸出結果如何驗證的一個問題。因爲 RAG 是會給一個 reference link，無論大家用圖數據庫來做，還是向量數據庫來做，兩者之間並不衝突，是一個很好的補充。
第二個有意思的場景叫 Semantic Cache。在 github 上面有一個蠻火項目叫 GPT Cache。最簡單的一個思路是用 redis 去緩存 mysql 的數數據，有沒有可能去緩存一下大模型的輸出的結果，所以就做了這麼一個項目。
其實整個的思路沒有很複雜，用向量數據庫做了語義的檢索，如果問題語義匹配的話，就認爲答案可能是相似的。目前可能還不完全是一個非常 production ready 的場景。但是確實給了很好的思路，並且在大模型的推理階段，大家也會用這種類似的思路，基於召回，再去給大模型做加工，可以省掉很多 token，也是蠻常見的一個思路。
最後給大家分享一個比較新的話題，對於 openapi dev day 怎麼看？大家也都知道 11月6日新開的發佈會，推了幾個比較重要的功能。第一個就是構建自己的 GPT，第二個就是關於 GPT-4 turbo支持非常長的 token，第三就是支持召回，支持function call。比較關注的是多模態 API，我們做了很多測試，結果可以給大家簡單分享一下。我覺得 openapi 做召回還是在處於非常簡單的一個階段，大家解決不好的事情，它也沒有解決的很好，比如說長文本的 summarize，就是給一本書，告訴書是做什麼的，其實用 RAG 來解決是非常難的，包括很具體的問題，比如說有 100個 document，每個 document 有個 ID，問 document 的 ID50 講什麼事情？ChatGPT 會告訴搜不出來。我覺得搜索和大模型之間的深度結合，是一個非常好的 topic，本質上基於概率，因此搜索和和生成這兩個問題一定是要一起去解決的。但是現在其實無論對誰來講，都是非常早期的一個階段。自己更希望大模型的公司，能去構建更好的一個生態，通過這種 function calling，以 agent 作爲一箇中心，所有的周邊廠商提供更好的 API。比如說的圖數據庫可以提供一套 API，向量數據庫提供一套 API，以 agent 爲中心去把業務邏輯給串起來，是對未來的一個期望。
https://github.com/eosphoros-ai/DB-GPT
https://github.com/eosphoros-ai/DB-GPT-Hub
https://github.com/eosphoros-ai/DB-GPT-Web
本文分享自微信公衆號 - ZILLIZ（Zilliztech）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。