AI原生資料庫Infinity正式開源

        經過長時間緊鑼密鼓的開發，AI 原生資料庫 Infinity 已於2023年12月21日正式開源了。AI 原生資料庫，定義為專門服務大模型的資料庫，其具體場景即為 RAG（Retrieval Augmented Generation）。未來企業大模型應用架構的基礎設施層面，將只需要一個 AI 原生資料庫配合一個大模型（當下是 LLM 大語言模型，未來還會有多模態模型），就可以完全滿足企業對於 AI 場景的主要需求，包括 Copilot、搜尋、推薦、對話機器人等。來自企業內部的各種資料，比如文件、普通資料庫（包括 OLTP 和 OLAP 等）、API、日誌，還有非結構化資料，都可以整合進一個 AI 原生資料庫；AI 原生資料庫將業務查詢得到的資料交給大模型，再由大模型生成最終結果返回給具體應用。

向量無法單獨解決企業 AI 應用的落地

      也許你會有這樣的疑問：AI 原生資料庫究竟是什麼？它不過是向量資料庫的新瓶裝舊酒嗎？當然不是！AI 原生資料庫不同於向量資料庫，向量只是大模型配套基礎設施的必要而非充分條件。這是因為向量只能提供語義召回能力，無法提供精確查詢能力，而後者恰恰是企業 AI 應用的核心需求。

      舉例來說，根據許可權表過濾出具備相應訪問許可權的內容，這樣一個簡單卻常見的需求，就無法單獨靠向量實現。當然，當下流行的向量資料庫已經具備了簡單的過濾功能，似乎也可以服務這樣的場景。但這就需要透過 ETL（Extract-Transform-Load）工作，把許可權欄位寫到向量資料庫的標量欄位來提供過濾，這意味著三件事：

1. 需要為簡單的需求引入高成本的 ETL。

2. 原始資料的更新不能及時體現到業務。

3. 引入不必要的資料膨脹。許可權過濾僅僅是一個例子。如果完全依賴 ETL 解決來自不同資料來源的其他各種查詢，那相當於在向量資料庫內儲存一張帶有全部過濾欄位的寬表。除了上述的系統維護和資料更新問題之外，這也是一種不必要的資料膨脹。在大多數情況下，企業數字化系統架構內只有離線場景的資料倉儲才有引入寬表的必要。

       再比如，基於 RAG 的應用大多數都需要具備精確召回能力。舉例來講，當使用者針對 PDF 文件內某張表格內的內容進行提問時，僅僅依賴向量是無法提供準確回答的，這就會導致由 LLM 返回的答案包含幻覺。所以，只有依靠搜尋引擎才能實現精確召回。

      因此，配套 AI 的基礎設施，其實是伴隨了三代的演進：

• 第一代，以統計模型和資料探勘為基礎，基礎設施的配套代表就是搜尋引擎。因此配套的企業 AI 應用架構，往往是以

  Elasticsearch，再加上 MySQL 等資料庫共同支撐業務體系。

• 第二代，深度學習催生了向量搜尋的需求，也催生了向量資料庫這個品類。由於向量資料庫僅僅提供單一的向量搜尋能力，在構建企業資訊系統時，還需要搭配各類資料庫、資料倉儲等，形成所謂的 AI 中臺。

• 第三代，AI 進化到大模型之後解鎖了更多場景。因此，它需要的不再是一款單純的向量資料庫，而是能夠同時提供向量

  搜尋、全文搜尋和結構化資料檢索，可以支撐大模型對於複雜資料的獲取需求，能夠配合大模型共同支撐起企業門戶業務需求的基礎軟體產品。

傳統資料庫/湖倉加向量外掛？

        比如，傳統的關係型資料庫 PostgreSQL 就提供了 pgvector 外掛，可以輕輕鬆鬆具備向量能力。但是，AI 原生資料庫

並不能透過傳統資料庫增加向量搜尋能力來得到。下面，我們就先來看看 PostgreSQL 能否解決 AI 的 RAG 場景下的幾個基本問題，相信讀者很快也可以自行得出答案：

• 如何實現精確召回所需的全文搜尋能力？ 

        PostgreSQL 是一款 OLTP 資料庫，OLTP 的核心設計目標是確保資料寫入的 ACID，而這跟向量和全文搜尋都不相關。儘管 PostgreSQL 有全文搜尋的功能，而且已經存在十多年了，為何至今企業仍然採用 Elasticsearch 而不是 PostgreSQL 進行全文搜尋呢？這是因為 PostgreSQL 的全文搜尋只適合小資料規模的簡易搜尋。一款搭配 RAG 的 AI 原生資料庫需要勝任各種資料規模，進行可定製的相關度排序，尤其還需要與向量進行多路召回的融合排序，這些都是PostgreSQL沒有辦法勝任的。

• 如何兼顧伸縮性、成本等因素？

        PostgreSQL 是個單機資料庫，要提供分散式場景下的各種一致性約束，目前主流是採取 Share-nothing 方式的分庫

分表來解決伸縮性問題。而向量搜尋和全文搜尋，則是完全不同的約束條件和效能最佳化目標，完全沒有必要採用這些複雜的

技術來解決伸縮性問題。因此，讓一款 OLTP 資料庫順道做一些事情，並非不可以，但兼職做，就一定沒有專職做得好，當前

的大模型時代需要的是一款專業資料庫，而非傳統資料庫加外掛的縫縫補補。

        另一類工作是在數倉上為新增向量搜尋能力。這類工作具備一定的合理性，但設計目標依然是有衝突的。資料倉儲，

傳統上來說，是服務離線場景的，例如執行一個複雜的 SQL，跑幾十分鐘，乃至幾個小時之後，給出報表，然後給公司內部看。儘管資料倉儲從技術路線上有實時數倉的概念，但它們從使用場景上來講，並非線上場景，因此並不強調併發。可是向量搜尋，它所服務的搜尋，推薦，對話機器人，都是高併發的線上業務場景，因此把強調高併發的向量，跟強調高吞吐卻低併發的數倉結合在一起，這在場景上是割裂的。

        因此，正如下面這個圖的藍色框內所示，Infinity 是一款結合 AI 基礎設施和 Data 基礎設施的產品，它面向的是線上場景，滿足未來大模型對企業內部資料基礎設施的一切需求：

Infinity 的系統架構

如上圖所示，Infinity 包含儲存層和計算層兩大模組：

• 儲存層：

• 列存（columnar storage）：Infinity 的預設儲存是一個列存引擎，主要服務於結構化資料檢索，且它可以保證資料儲存的 ACID。

• ANN 索引（Approximate Nearest Neighbor Index）：即向量索引，用於服務向量搜尋。Infinity 目前提供 IVF 和記憶體最佳化的HNSW 兩類索引：前者服務記憶體受限場景，後者服務高效能場景。Infinity 的 HNSW 索引採用了區域性量化技術，可以在記憶體佔用相較標準HNSW演算法小的多情況下，提供遠高於其他向量索引的搜尋效能。此外，ANN 索引僅僅是針對 Infinity 表的一個向量型別列構建的索引，因此 從設計機理上Infinity 可以包含任意多的向量列，而非普通向量資料庫只能提供單一向量列的能力，因此 Infinity可以很容易支援多向量查詢。

• 倒排索引（Inverted Index）：用於服務全文檢索以及結構化資料檢索。倒排索引包含兩部分：一部分是針對文字型別的全文索引，預設提供基於 BM25 的相關度排序功能，也提供短語查詢等常見的精確召回能力；另一部分是針對結構化資料的次級索引，提供高效能過濾能力。

• 計算層：

• Parser：為了方便 AI 開發者，Infinity 主要對外提供的是 Pythonic API。此外，Infininty還提供相容 PostgreSQL 協議的 SQL 方言。因此，Infinity 使用全新實現的 Parser 來提供對這兩種方言的支援。

• 執行器：Infinity 針對不同型別的資料，不同的資料分佈，提供了多種多樣的索引。它能夠根據查詢需求動態的決定分配哪些資源哪種儲存提供哪些查詢。例如，對於結構化查詢能力來說，可以選擇列存，也可以選擇倒排索引。如果使用者對延遲敏感，則可以使用多個計算單元，採用並行查詢的執行邏輯；如果使用者對併發敏感，就只採用單個計算單元，採用基於倒排索引的方式來執行，Infinity 的執行器會根據需要動態作出最優選擇。具體來說，Infinity 採用了基於 Push 的流水線執行計劃，但更進一步地改進使之同時能適應大吞吐查詢和大併發查詢的工作負載。除此之外，Infinity 還實現了一些重要的運算元，例如 Fusion 融合運算元，它負責多路召回——採用向量搜尋返回的資料，跟採用全文搜尋返回的資料，還有結構化過濾的資料，它們之間如何選擇，如何排序，在 Infinity 內部處理完畢這個運算元，既高效又便捷，避免了在多個資料庫之間進行聯邦搜尋（Federated Search）造成的低效甚至結果錯誤。

Infinity 提供業界最優的向量搜尋效能

        Infinity 採用 C++ 20 標準開發，確保了最優的執行路徑，在各種創新演算法的共同加持下，Infinity 在向量搜尋效能上超越了所有已知向量資料庫，在八核的機器和百萬 SIFT 向量資料集上，高併發場景下 Infinity  可以輕鬆達到 1 萬QPS，單個客戶端場景下查詢響應延遲則是 0.1 毫秒級，且記憶體佔用小。

        此外，Infinity 還引入了 C++ Modules 提高開發效率，這或許是第一個採用 C++ Modules 的大型開源專案。這使得在普通個人筆記本上編譯 Infinity 二十萬行程式碼及其依賴的上百萬行 C++ 程式碼的時間減少到數分鐘。極大節約了傳統 C++ 程式設計師因修改一行標頭檔案，動輒要重新編譯數百個檔案，耗時十幾分鐘的痛點。最後，歡迎大家一起加入 Infinity 開源社群貢獻程式碼，為 Infinity 早日 GA 添磚加瓦。

專案地址：