AI原生數據庫的思考

作者 | 楊傳輝，OceanBase CTO

我們需要一款怎樣的 AI 數據庫？

基于大模型的 AI 技術已經成為行業共識，各個行業的企業都在知識庫、AI Coding、智能客服、ChatBI、Agent 開發等場景落地大模型。然而，在真正進入企業業務后，會暴露兩個問題：

• 缺乏企業的私有數據：基礎大模型采用海量公網數據做預訓練，雖然具備一定的“智能涌現”，但永遠不可能理解企業的私有數據。這就像企業招聘了一位新員工，雖然經過了良好的教育，但還需要通過一段時間的新員工培訓和動手實踐才能真正勝任企業的日常工作。

• 缺乏記憶。大模型底層采用 transformer 架構，只能批量訓練（預訓練 / 后訓練），無法根據用戶的實時行為動態反饋。

因此，為了讓 AI 在企業落地，需要依賴數據庫實時存儲企業私有數據和用戶的實時行為，并通過智能搜索得到大模型需要的上下文，這個過程也被稱作上下文工程。對于企業來講，大模型基礎能力是通用的，私有數據和用戶行為才是核心資產，如何通過數據庫把這些核心資產用好，決定了企業在 AI 時代的核心競爭力。

另外，AI 時代將會帶來技術平權，原先只能通過專業人士開發的應用 /APP 來讀寫數據庫，而在 AI 時代，每個不懂技術的非專業人士也能利用大模型技術通過多輪對話的方式構建自己的 AI Agent，這些海量的 AI Agent 底層都需要用到數據庫，使得數據庫的用戶規模 / 租戶規模會有數量級的提升。

基于這些變化，AI 場景正在驅動數據庫出現一個全新的工作負載，我把它稱為：面向 Agent 的多?；旌纤阉?/strong>。首先，數據庫不僅僅需要處理結構化數據（關系），也需要處理半結構化數據（JSON），以及無結構化數據，除了支持關系表的二級索引，也能支持全文索引，向量語義索引，圖索引等，即具備多模能力。其次，數據庫需要能夠支持結構化、半結構化和無結構化數據的混合搜索。最后，數據庫需要支持海量 Agent 同時使用，即具備海量多租戶能力。

AI 數據庫的“變與不變”

在 OceanBase 2025 發布會上，我們討論過一個觀點：AI 時代，數據庫的變與不變。

數據庫在 AI 時代雖然新增了“面向 Agent 的多模混合搜索”工作負載，但是，不管未來 AI 如何發展，數據庫的核心需求是會一直存在的，需要通過行存來做交易，通過列存來做分析，并通過強大的 SQL 優化器來支持復雜查詢和 HTAP。數據庫需要確保數據不丟，確保穩定可靠，支持各種靈活的部署方式。

從實現路徑來看，目前有兩種思路實現 AI 數據庫。第一種是從零開始構建一個“多?；旌纤阉鳌睌祿欤缦蛄繑祿?、全文搜索數據庫；第二種是在成熟的關系數據庫基礎之上擴展多?；旌纤阉鞯墓δ?，PostgreSQL，Oracle 和 OceanBase 都屬于這一方向。關系數據庫不管是在功能豐富度、易用性、開發者和 DBA 生態、成熟度和穩定性等方面都遠遠好于其它非關系數據庫，且經過了大量企業的核心業務場景打磨驗證，技術壁壘非常高。未來，兩種方式會長期共存，第二種技術路線很大概率會占據主流。

AI 原生混合搜索

提到 AI 原生搜索，很多人首先會想到向量搜索。向量搜索確實是當前主流的 AI 語義搜索方式，通過向量 embedding 可以搜索文本、圖片甚至視頻等多模態數據。然而，向量搜索只是 AI 數據庫的初級階段，隨著 AI 應用的逐步深入，搜索需求必然會從“向量單一路徑”走向“多?；旌纤阉鳌薄?/p>

為了讓大模型拿到更精準的上下文，需要用到向量搜索解決“找相似”的問題。然而，除了找相似之外，還需要通過全文搜索“找相同“，部分場景甚至需要通過基于知識圖譜的圖搜索在全局范圍內“找相關”。AI 數據庫不僅要管理多模數據，還需要管理這些多模數據對應的元數據，例如文檔的權限，權重等等。因此，還需要通過關系模型管理這些元數據，提供實時寫入和一致性事務。每一種搜索方式都可能找到部分結果，將這些結果融合之后通過多輪排序（粗排 =>精排）才能得到最后的結果。每一輪排序可能基于規則，也可能直接用模型。

因此，AI 時代的搜索不再是單一向量搜索，而是多種搜索方式、數據與模型（embedding/rerank 等）深度融合的整體過程。為了更準確描述這一能力，我們把它稱為 AI 原生混合搜索（AI native search）。

現代數據架構

從一體化架構開始，OceanBase 一直在思考現代數據架構。在我們看來，現代數據架構可以總結為三個特點：

• 易用：現代數據架構面向開發者做了專門設計，開發者想要什么能力，直接使用現代數據架構提供的功能或者服務，而不是根據不同的功能選擇不同的產品，學習不同的技術棧。這個設計理念也是 OceanBase 一體化架構的初衷，通過在一套引擎中支持 OLTP、OLAP 和 AI 原生搜索來屏蔽底層數據庫的技術細節。

• 靈活：現代數據架構必須支持按需使用，能夠支持從“無限”小到“無限”大的工作負載。這是因為，AI 場景的工作負載具有不確定性，大部分 AI Agent 都是默默無聞的，少部分的 AI Agent 的流量很高，且流量具備突發性。為了支持“無限”小，需要能夠支持 Serverless，為了支持“無限”大，需要底層能夠支持原生分布式架構實現在線擴展。

• 面向未來：擁抱 AI，已經不再是前瞻性的選擇，而是面向未來的必然起點?，F代數據架構需要能夠原生支持 AI 工作負載，既包括多模混合搜索，也包括海量多租戶的能力。

數模融合

OceanBase 的 AI 戰略叫做“Data x AI”，而不是“Data+AI”。從技術發展趨勢來看，數據與模型的深度融合正在成為必然方向。首先，多?；旌纤阉骷纫龆嗄祿乃阉?，也要用模型做 embedding 和 rerank，這本身就是一種數據與模型的融合。

其次，業界開始出現一些流行的 AI 原生應用，比如飛書和釘釘的 AI 多維表格，可以直接在表格的每個數據單元執行 AI Function，包括大模型總結、翻譯、打標簽、等等，這是一種技術趨勢。通過數據和模型的融合（簡稱“數模融合”），一方面能夠大幅簡化 AI 應用開發，另一方面也能創造一些 AI 特色的功能。舉個例子，當我們想要給所有年齡在 30-35 歲之間所有關注下一代成長的媽媽發一封通過大語言模型自動生成的郵件時，只需要一條 SQL 語句加上 AI Function 就可以實現。

除了 AI Function，數據庫也可以通過一些方式幫助大模型更好地理解數據。例如，Oracle 26ai 版本引入的 Annotations（注釋）功能，通過輕量式聲明，幫助大模型理解數據，這也是數據與模型逐步融合的一種體現。

可以預見，AI 數據庫將從“AI Ready”逐步演進到“AI Native”。數據庫既可以只做數據處理，把數據準備好，由應用從數據中搜索出精準的上下文作為提示詞調用模型，也可以直接在數據庫中調用模型，一條 SQL 語句既操作數據也調用模型，實現數據與模型的深度融合。

小結

總體來看，AI 數據庫有三個核心特點：

• 從“為應用服務”到“為智能服務”。既能處理傳統的 OLTP、OLAP，也能夠支持一種新的工作負載，既多?；旌纤阉?。

• 面向 AI 場景的現代數據架構。通過 Serverless 和分布式架構，實現從“無限小”到“無限大”的完全彈性能力，支持海量多租戶與靈活部署。

• 數據與模型的深度融合，逐步走向“AI native“，未來會有越來越多在數據庫中直接融合模型能力的 AI 原生數據庫。

基于這些思考，我們在 OceanBase 中逐步增加 AI 數據庫能力，并基于 Apache 2.0 協議開源了 AI 原生數據庫 seekdb。接下來的幾個部分會深入探討 AI 數據庫的思考，包括：

• < <從向量搜索到 ai 原生混合搜索> >：介紹 AI native search 背后的思考。
  

• <>：介紹現代數據架構的設計邏輯。

• < <從 ai ready 到 native> >：介紹數據和模型融合背后的思考。

• < <為什么要做 ai 原生數據庫 seekdb> >：介紹 OceanBase seekdb 的初心、定位、現有核心能力與不足。

從向量搜索到 AI 原生混合搜索

數據庫最早為應用服務，處理結構化數據，得到的是確定性的結果。而在 AI 場景下，數據庫不僅為應用服務，更為智能服務，需要處理無結構化數據，通過規則和模型得到語義近似的結果，這個過程通常稱為搜索。由于這個過程涉及到結構化數據（關系表）、半結構化數據（JSON）以及無結構化數據的各類索引（向量索引、全文索引、圖索引），因此可以統稱為多模混合搜索，或者 AI 原生混合搜索。

RAG 技術的出現主要是為了解決大模型的幻覺和知識陳舊問題。最早的 RAG 一般依賴向量搜索：應用層對文檔等無結構化數據進行 embedding，接著在向量數據庫執行向量近似查詢（similarity search），并通過向量索引來實現查詢加速。然而，為了提升搜索效果，僅僅向量搜索是不夠的，還需要融入關系查詢、JSON 查詢、全文搜索，某些場景甚至還需要基于知識圖譜的圖搜索，以獲取更全面和準確的上下文信息。

業界已有一些流行的向量數據庫，比如 Milvus、Pinecone、Qdrant 等，這些產品在向量搜索方面表現優秀，部分產品也在逐步引入全文搜索等功能，但全文搜索能力距離實際業務的需求相比仍有差距。全文搜索數據庫最典型的代表是 Elastic Search（簡稱 ES），ES 的全文搜索能力較強，但向量搜索能力還有待提升，且不支持關系數據庫的多表 Join 操作。另外，不管是向量數據庫還是 ES，往往缺乏數據庫的綜合能力，比如數據庫安全及權限管理，SQL 優化器自動選擇執行路徑等。

混合搜索提升召回效果

相比單一路徑的向量搜索，混合搜索能夠大幅提高召回效果。實驗和實踐表明，如果只采用單一路徑搜索——無論是全文、稀疏還是稠密向量，都難以達到最優結果；只有將全文、稀疏和稠密向量結合起來執行混合搜索，才能最大化召回效果。理論上，只要重排序（rerank）算法足夠出色，搜索方式越多，效果越好。當然，實際生產系統中往往是搜索效果和執行效率的一個平衡。一般來講，向量和全文的混合搜索就能達到不錯的效果，少部分場景會引入知識圖譜來獲取全局信息。知識圖譜的難點并不在算法本身，而在于很難自動構建一個準確率比較高的知識圖譜，因此，往往應用在一些特定領域，比如用于表示醫療、法律等行業的特定術語和這些術語之間的關聯關系。

多路搜索得到的數據最終需要融合在一起，進行重排序后才能返回客戶。常見的重排序算法包括：

• Reciprocal Rank Fusion(RRF)：RRF 為每路召回的結果列表中的每個文檔都根據其排序位置分配一個分數，通常，得分是其排名的倒數。例如，排名第一的文檔得分為 1，排名第二的得分為 0.5，排名第三的得分為 0.33，以此類推。那么最終文檔的得分就是各路召回結果的累加。

• 加權權重融合：RRF 的魯棒性較好，但它完全按照各路召回的排名進行打分，丟失了每一路召回結果的相似度和權重信息。加權權重融合算法簡單地讓用戶配置每一路搜索召回結果的權重，并基于權重做加權平均。

• 基于模型的算法：BGE-reranker 是一種常見的排序模型，隨著大模型技術的發展，我們發現 Qwen-rerank 等排序模型的效果經常更加出色。

關系數據庫融合混合搜索

業界的混合搜索系統，比如 Elastic Search，除了支持搜索功能，也能實現常見的關系過濾。那么，在關系數據庫上構建混合搜索有什么優勢呢？我們舉一個簡單的例子進行說明。

文檔知識庫是一個常見的 AI 應用場景，將文檔寫入到數據庫后執行混合搜索，這就可能導致引用了用戶無權訪問的數據，這個問題也被稱為隱式越權。為了避免這樣的問題，需要給每個文檔設置權限，比如只允許某些人，或者某些部門訪問。

如果采用 ES 來實現文檔搜索，由于 ES 的數據模型是大寬表，不支持多表做 Join，因此，只能對每個文檔增加一列用來表示允許訪問的用戶以及部門列表。當允許訪問的用戶或者部門越來越多，或者需要經常修改時，無論是搜索性能還是更新效率都會大幅下降。

關系數據庫支持完整的 SQL 功能，可以單獨維護一張文檔權限表，并在搜索時根據文檔的編號對文檔權限表與文檔內容表做多表 Join 操作，實時性和靈活性大幅提升。一般來講，企業剛開始構建文檔知識庫時往往只考慮搜索的效果，等到搜索效果滿足業務需求之后會逐步引入文檔權限，文檔共享等多種豐富的功能，而這些功能正是關系數據庫所擅長的。

另外，關系數據庫具備很強的 SQL 優化執行能力，可以根據統計信息自動地選擇最優的執行路徑，例如，先做關系過濾還是向量搜索，還是邊過濾邊搜索，等等。除了關系數據之外，還會經常用到 JSON。這是因為，源端往往有多個不同的數據源，數據入庫時經常映射到相同的一張表格，因此，將部分無法統一的字段用 JSON 來表示，并且通過在 JSON 上構建 Search Index，支持對于 JSON 字段的實時查詢。

幾個典型應用場景

知識庫 RAG

知識庫天然需要用到混合搜索，業界有一個流行的開源框架 ragflow，為了更好地支持混合搜索，OceanBase 基于 ragflow 二次開發了企業級 RAG 解決方案 PowerRAG，已應用在螞蟻集團并在 github 開源。

知識庫 RAG 分為離線部分和在線部分：

• 離線部分從數據入庫 =>文檔解析切片 =>文檔 / 切片入庫。

• 在線部分從查詢意圖理解 =>混合搜索（多路搜索、粗排、精排）=>生成提示詞調用 LLM。

可以看到，離線部分相當于是數據庫的 ETL，在線部分主要是數據庫的混合搜索。

記憶 Mem

大模型缺乏記憶，而記憶又可分為長記憶與短記憶。由于大模型的上下文窗口有限，一般會對長記憶做概要總結，把長記憶的概要數據和短記憶一起作為大模型的輸入上下文。

業界已出現一些流行的大模型記憶解決方案，比如 Mem0，為了更好地支持混合搜索，OceanBase 在 github 開源了兼容 Mem0 接口的企業級 Mem 解決方案 PowerMem，在針對 Mem 場景的 LOCOMO benchmark 上達到了開源 Mem 解決方案的 SOTA 水準。

長記憶的數據量很大，需要低成本存儲，短記憶和概要數據的數據量較小，需要保證搜索性能。為了從長短記憶中查找精確的上下文，需要關系 +JSON+ 向量 + 全文的混合搜索，底層需要基于對象存儲 + 本地緩存的冷熱分離解決方案。

AI Agent 智能搜索

AI Agent 往往需要同時查找關系、JSON、GIS、向量、全文，等。例如，在螞蟻的百寶箱應用中，有一個常見的場景：

“推薦距離五百米以內，人均消費 25 元以下、評分 4.5 以上，多數人喜歡的咖啡廳”。

這個場景涉及到 GIS（五百米以內），也涉及到關系查找（人均消費 25 以下，評分 4.5 以上），還涉及到語義搜索（多數人喜歡）。傳統的方案往往是采用多種不同的數據庫，包括關系數據庫、GIS 數據庫、向量數據庫，并在 AI Agent 應用層做拼裝，有了混合搜索數據庫之后，這些繁瑣的業務邏輯都可以下沉到數據庫。相比傳統方案，混合搜索數據庫有兩個優勢：一個是實現多合一，統一技術棧；另外一個是通過算子下壓能夠在數據庫層面做優化，避免中間結果過大等一系列問題。

小結

AI 原生混合搜索在一套引擎完成關系、JSON、向量、全文的混合搜索，部分場景通過圖搜索進一步提升搜索效果。通過在關系數據庫基礎上構建混合搜索，能夠復用關系數據庫已有的實時寫入、事務一致性和 HTAP 關系查詢的能力，使得混合搜索不僅用于 AI 創新嘗試，也用于嘗試后的實際生產系統。OceanBase 混合搜索已經應用到知識庫 RAG、大模型記憶、智能搜索等多種實際生產系統中的 AI 場景，實現了數據庫多合一、統一技術棧、簡化業務、提升召回效果等業務價值。

AI Ready 的現代數據架構

AI 時代帶來技術平權，從數據庫使用方式來看，主要帶來兩點變化：一是每個普通用戶通過 AI Agent 使用數據庫，帶來海量多租戶需求；二是新增了全新的多?；旌纤阉鞴ぷ髫撦d。同時，原先的 OLTP、OLAP 以及 HTAP 的需求仍然存在。

以螞蟻集團在 2025 年 11 月 18 日推出的全模態通用 AI 助手“靈光”為例，靈光的右上角有一個用戶喜歡的功能“閃應用”，使得每個即便不懂技術的普通用戶都能夠創建自己的 AI Agent，每個 AI Agent 相當于數據庫的一個租戶，每個租戶可以擁有獨立的表格、索引等 schema。對于 AI Agent 來說，通常大部分用戶創建的 Agent 都是不太活躍的，只有少量用戶創建的 Agent 流量很高。而且 Agent 的流量具有很強的突發性，某些默默無聞的應用可能因為某些事件短時間內成為熱門應用。

現代數據架構是隨著業務需求逐步發展起來的。數據庫最早采用 IOE 集中式架構（IBM 大型機 / 小型機 +Oracle+EMC 存儲），數字化進程到來之后集中式架構的并發能力不足，開始轉向分布式架構。云計算通過集約化管理能夠大幅提升效率，這就產生了云原生架構，且隨著云計算的不斷演進，很多企業發現某些云的成本很高且每年都會出現某個公有云整體故障的系統性風險，因此逐步走向云中立和混合云，產生了混合多云架構；AI 時代來臨之后，由于 AI Agent 的使用方式和工作負載的特點，需要支持極致的彈性，從“無限小”的 Serverless 到“無限大”的全分布式架構。

從集中式到分布式

在設計理念上，分布式與集中式最大的區別在于“Take failure as granted”，把故障當成是一種正?，F象，并通過軟件冗余的方式來實現自動容錯、自動恢復。相比集中式架構，分布式架構帶來如下幾點好處：

• 自動容錯：當服務器、機房、甚至城市發生故障時，能夠自動恢復，完全不丟失數據。OceanBase 甚至做到了 RPO=0，RTO<8 秒。

• 自動擴縮容：系統處理能力不足時，可以通過在線增加服務器來自動提升系統的處理能力。業務高峰期過后，也可以在線刪除服務器。原生分布式數據庫能夠做到自動擴縮容對業務無感。

• 低存儲成本：早期的數據庫采用 B+ 樹存儲引擎，而以分布式數據庫為代表的新型數據庫，往往采用 LSM-Tree 存儲引擎。B+ 樹比較適合數據量較小，更新比較頻繁的數據，而 LSM-Tree 比較適合數據量較大的場景，而新型數據庫在設計時往往假設數據量比較大。LSM-Tree 的存儲成本遠低于 B+ 樹，OceanBase 在很多場景通過采用 LSM-Tree 替換傳統數據庫的 B+ 樹將存儲成本降低了 70%~90%。

分布式數據庫引入了一個問題，那就是分布式架構本身帶來的額外開銷。分布式數據庫為了保證高可用和分布式事務，往往會對數據進行分片 / 分區，每個分片 / 分區需要通過 Paxos 協議來實現自動容錯，對于跨分片 / 分區的操作，即使在一臺機器上，也需要通過兩階段提交協議（Two Phase Commit）來保證事務的一致性。這些開銷在集中式數據庫中是不存在的。為了解決這個問題，OceanBase 4.0 版本提出了一種全新的架構方案，叫做單機分布式一體化架構，使得分布式數據庫在不涉及跨機事務時沒有額外的分布式開銷。

一體化架構

一體化架構的核心是：多負載、多模和混合多云，簡稱“三多”。

首先，一體化架構在一套引擎中同時支持 OLTP、OLAP 和 AI 混合負載。HTAP 數據庫是一種現代數據架構，能夠實現在線實時分析，有兩種典型的實現方案：

• 多副本：OLTP 采用行存，OLAP 采用列存，行存和列存采用不同的副本，并通過 SQL 優化器來將用戶的請求自動路由到不同的副本；

• 單副本：采用行列混合存儲（類 PAX 方案）在一個副本上同時支持 OLTP 和 OLAP 兩種工作負載。

這兩種方案各有優勢，第一種方案可以更好地支持 OLTP 和 OLAP 兩種工作負載的隔離，適合 OLAP 工作負載較重的場景，第二種方案能夠更好地保證在線分析的實時性，適合 OLAP 工作負載較輕的場景，比如簡單的跑批或者簡單的在線統計。OceanBase 同時支持了這兩種模式，在 OceanBase 4.4 版本中還實現了一個增量實時物化視圖功能。通過該功能，數據庫會自動通過增量刷新的方式維護一個實時物化視圖，從而支持在同一個副本中既做交易，也做在線分析，并將在線分析由原始表的批量掃描變成實時物化視圖的點查。

其次，一體化架構在存儲層支持多模，從而在一套系統中同時支持結構化、半結構化和無結構化數據。結構化數據的底層采用關系表，半結構化數據采用 JSON，無結構化數據一般會構建語義索引，包括向量索引、全文索引，等等。

最后，一體化架構支持多云和混合云，簡稱混合多云。為了支持多云，需要采用云中立的架構方案。對象存儲是一種云中立的存儲方案，所有的主流云平臺都支持兼容 S3 接口的對象存儲。多云架構強依賴 K8s 做調度，OceanBase 在做多云架構時發現不同云平臺的 K8s 實現不完全相同，例如阿里云 K8s 支持固定 IP 且升級 K8S 時對業務無損，而 AWS 的 K8s 無法支持固定 IP 且升級對業務有損，因此，為了實現多云原生架構，OceanBase 只能自己實現云中立的 K8s 方案。多云原生架構還需要能夠實現跨云容災，比如主集群和備集群分別部署在不同的公有云，或者單個集群支持跨云部署和跨云容災。

對象存儲與 Serverless

業界很多數據庫開始支持對象存儲。對象存儲是每個公有云的標配，優勢在于存儲無限擴展且有極低的存儲成本，劣勢在于讀寫延遲較高。AI 時代的數據量變得越來越大，且大部分數據為冷數據，少部分數據為熱數據，對象存儲天然適應這種業務訪問模式。為了減少對象存儲的延遲，需要支持自動緩存熱點數據，從而實現自動的冷熱分離。LSM-Tree 存儲引擎分為基線數據（基線 SSTable）、增量數據（增量 SSTable）以及重做日志（redo 日志），基線數據和增量數據通過 major compaction 和 minor compaction 操作批量寫入，寫入延遲不是核心問題，優化的關鍵在于讀取延遲，因此，OceanBase 會在數據庫服務器上緩存熱點數據，當數據庫故障或者需要彈性擴容的時候，也需要通過預熱緩存來優化讀取延遲。重做日志的寫入延遲在事務的主路徑上，為了優化該性能，OceanBase 抽象了獨立的 log service 服務，log service 服務采用了高性能的本地盤 / 云盤，只需要將重做日志在 log service 寫入成功即可，由 log service 在后臺將重做日志批量同步到對象存儲。

AI 場景的工作負載具有很強的不確定性，大部分 AI Agent 都是沒有多少訪問量的，這就要求 AI 數據庫原生支持海量多租戶和 Serverless。Serverless 架構有幾個核心指標：當某個租戶訪問量為 0 時占用的最小資源，當沒有訪問的冷租戶突然有流量時需要的加載時間，以及有突發流量時彈性擴容需要的時間。海量多租戶帶來的核心挑戰包括兩點：一個是不同租戶之間的資源隔離問題，包括 CPU、內存、存儲 IO、以及網絡等，另外一個是海量多租戶帶來的海量表格 schema 管理的問題。OceanBase 廣泛應用在 SaaS 行業，包括用友以及零售 SaaS 等，剛開始經常遇到表格太多導致資源消耗過大的問題，為了解決這個問題，我們成立了專門的 schema 優化項目組，對每個表格 schema 占用的內存和 schema 管理后臺任務占用的 CPU 資源進行了大量的優化，最終將單個集群支持的表格數提升了一到兩個數量級，滿足了 SaaS 行業和 AI 場景的海量表格需求。

小結

為了支持 AI 場景，需要與之匹配的 AI Ready 現代數據架構。AI Ready 數據架構是彈性的，支持從“無限小”的 Serverless 到“無限大”的全分布式架構；AI Ready 數據架構是易用的，通過統一的技術棧支持多種不同的工作負載，具有很好的實時性；AI Ready 數據架構是面向未來的，能夠很好地支持 AI 場景需要的海量多租戶和多?；旌纤阉?，等等。

從 AI Ready 到 AI Native 數據庫

數據和模型之間的關系到底是什么？首先，AI 時代的數據庫需要 AI Ready，即幫助 AI 把大模型需要的上下文準備好。然而，隨著 AI 應用逐步深入，我們發現越來越多的 AI 原生應用需要同時操作數據和模型，數據庫僅僅 AI Ready 是不夠的，還需要進一步融合數據和模型的能力，成為 AI Native 數據庫。

數據庫和 AI 融合并不是一個全新的概念，學術界和工業界一直在探索。難點在于如何定義數據庫和 AI 的邊界，讓數據庫擅長的歸數據庫，讓 AI 擅長的歸 AI。過去，學術界曾經嘗試用 AI 的方式來實現數據庫的內核模塊，比如用 AI 寫優化器，但是在實際生產系統很難落地，根本原因在于 AI 在寫優化器處理結構化數據這件事情上并不如專業的程序員。我認為，大模型在數據領域的優勢主要有兩點：一是具有很強的泛化能力，能夠理解自然語言，簡化數據庫的使用界面；二是能夠對非結構化數據進行語義處理。數據庫和 AI 融合的關鍵在于如何將這兩項能力融入到數據庫中。

業界越來越多數據庫產品開始將 AI 能力融入內核。Snowflake 是一個典型的代表，通過集成 Cortex 平臺和 AISQL 操作符，可以直接將數據管理能力擴展到非結構化數據和 LLM 推理領域；微軟也在最近（2025.11.19）宣布了一個新產品 Azure HorizonDB，其中一項重要改進就是內置了模型的能力，包括 Generate、Embedding、Rerank 等各類模型。

AI 原生場景

DataAgent

DataAgent 的一個核心目標是通過自然語言的交互方式直接操作數據庫，這里面涉及到一項重要能力：Text2SQL/NL2SQL。Text2SQL 的難點在于準確率，業界有一些針對 Text2SQL 的 benchmark，包括 BIRD-bench，然而，不管是直接采用大模型，還是基于大模型做通用的 DataAgent，BIRD-bench 準確率達到 80% 左右就很難再往上提升，無法滿足業務對 Text2SQL 的準確率要求。因此，需要提供一些方式讓大模型能夠理解行業或者業務本身的信息。有兩種做法，一種是向內看，在數據庫內核通過語義打標讓大模型理解數據庫的 schema，比如 Oracle 26ai 中的注釋（Annotations）功能，又如 Snowflake 中的 Tags 功能；另外一種是向外看，在 DataAgent 中引入指標層，統一業務術語，通過指標約束生成范圍，從而提高準確率。OceanBase 的 DataAgent 叫做 ODC DataPilot，通過引入指標層的 Text2Metrics 的做法，將準確率提升到 90% 以上。Text2Metrics 這種做法的好處在于可以通過專家介入的方式不斷提升準確率，直到最終達到業務要求。

知識庫 RAG

知識庫 RAG 分為離線部分和在線部分。對于離線部分，外部的各種數據源的不同格式的數據往往會轉化為中間格式（PDF/markdown），接著再對中間格式進行文檔解析，包括內容理解、領域適配、結構化提取、多模態理解，等等，解析后的文檔直接寫入或者分片后再寫入到數據庫；對于在線部分，會對用戶的提問進行檢索預處理（意圖理解、查詢擴展、領域適配、跨語言翻譯等）、檢索、重排、檢索后處理（結果裁剪與壓縮、信息匯總），最后通過提示詞工程調用 LLM。離線部分相當于是數據庫的 ETL，主要涉及各種數據處理任務的調度和工作流，比較適合放到數據庫的外部，文檔或者分片入庫以及入庫之后的檢索涉及的主要操作是標準化的多?；旌纤阉?，比較適合集成到數據庫內部。

多維表格

飛書和釘釘新增了一項很受用戶歡迎的功能，叫做多維表格。在多維表格中，每個單元格都可以調用 AI 功能：信息提取，從一段文本中提取關鍵信息，如從店鋪名稱中提取城市；數據生成，為每個店鋪生成隨機銷售數據；格式轉換，將雜亂的數據自動整理為標準格式；內容翻譯，一鍵將單元格內容翻譯成多種語言。這些操作不再需要復雜的公式或腳本，只需簡單的自然語言指令即可完成。多維表格可以同時調用多個 AI 模型（DeepSeek、Qwen 等）為表格服務，每一列數據都可以使用不同的 AI 進行處理，支持展示 AI 的完整思維鏈與輸出結果，以分列形式呈現。多維表格的底層可以采用 AI 原生數據庫來實現，每個列都可以支持 AI Function 調用，并且還能使用數據庫觸發器等機制在每個列發生變化的時候自動調用 AI Function。

Document In,Data Out

混合搜索的執行過程同時涉及數據處理和模型調用，執行過程中涉及的模型包括：

• Embedding 模型：MongoDB 收購的 VoyageAI 號稱能夠做到 embedding 模型的 SOTA，可惜是閉源的，而開源模型比較推薦 qwen3-embedding，bge-m3，bge-large-zh-v1.5 等；

• Rerank 模型：之前使用 bge-rerank 居多，隨著大模型的發展，qwen3-rerank 的效果經常更好；

• Generate 模型：國外的推薦 gpt 等模型，國內推薦 deepseek 和 qwen3 系列。

在數據庫內部直接集成 embedding 模型有兩個好處：一是不再需要從數據庫拖數據出去調模型，簡化業務實現；二是能夠確保文檔入庫和用戶查詢使用的 embedding 模型總是保持一致，不會出現二者不一致導致的搜索效果下降問題。

“Document In,Data Out”能夠大幅簡化 AI 應用開發。原先開發一個 RAG 應用，需要選擇多個不同的數據庫（關系數據庫、向量數據庫、全文搜索數據庫等），再根據不同的場景選擇不同的模型，并在應用層對這些數據庫和模型進行組裝并調試效果。有了基于混合搜索的“Document In,Data Out”之后，只需要把文檔或者切片寫入 AI 原生數據庫即可，AI 原生數據庫會自動執行多路搜索并選擇合適的模型。如果想要基于業務場景對模型做深度定制或者微調，也可以通過簡單的數據庫 DDL 操作來更換默認模型。

AI Function

AI 原生數據庫內置 AI Function，將這些 AI Function 融入到數據庫的執行算子中。常見的 AI Function 包括：

• 混合搜索算子：包括 embedding 算子 ai_embed，rerank 算子 ai_rerank，LLM 生成算子 ai_complete 等；

• 文檔處理算子（document ai）：包括文檔解析算子 ai_parse_document，文檔分類算子 ai_classify，文檔提取算子 ai_extract 等，翻譯算子 ai_translate，情緒分析算子 ai_sentiment，相似度分析算子 ai_similarity 等；

• SQL 語義計算算子（AISQL）：包括語義過濾算子 ai_filter，語義連接算子 ai_join，語義聚合算子 ai_agg，文本摘要聚合算子 ai_summarize_agg 等。

通過 AI Function，開發者可以在一個 SQL 查詢中完成以下任務：使用 ai_filter 過濾出客戶表達不滿意的工單記錄，使用 ai_join 將這些工單與產品目錄關聯，使用 ai_classify 對問題嚴重性進行分類，并使用 ai_summarize_agg 按產品分類生成聚合摘要。AI Function 使得對結構化數據和無結構化數據的混合分析成為可能。另外，在這種模式下，數據庫可以在底層系統對 AI 調用進行整體優化，減少大模型調用所需的 token。

小結

AI 時代的數據庫用戶由原來的應用 /APP 變成大模型生成的 AI Agent。為了支持 AI 場景，首先需要一個現代化的 AI Ready 數據架構，這個架構能夠支持 Serverless、彈性擴展等能力。AI Ready 只是 AI 數據庫的起點，隨著 AI 應用的逐步深入，會產生新的工作負載，即多?；旌纤阉?。數據和模型也會深度融合，通過 AI Function 等技術在系統中直接處理無結構化數據，成為 AI 原生數據庫。

為什么要做 AI 原生數據庫 seekdb？

2025 年 11 月 18 日，我們在 OceanBase 年度發布會正式發布并開源了 AI 原生數據庫 seekdb(官網：https://www.oceanbase.ai/）。從官網可以看到，seekdb 在一個數據庫中支持關系、JSON、向量和全文的混合搜索，支持 AI Function，繼承了 OceanBase 原有的 MySQL 兼容性和 HTAP 能力，起步配置為 1C2G。

為什么要做 seekdb?

回到第一性原理，我認為，傳統數據庫主要用來處理結構化數據和半結構化數據，而 AI 數據庫除了具備傳統數據庫的能力，還應該能夠直接處理無結構化數據，而多模混合搜索是最終的方向。然而，現有的數據庫產品都無法很好地支持關系、JSON、向量和全文的多模混合搜索，向量數據庫做不好全文搜索，全文數據庫做不好向量搜索，向量數據庫和全文數據庫都做不好關系查詢，也不能很好地支持輕量部署，等等。

OceanBase 采用一體化架構，4.4 版本已經支持了 OLTP、OLAP 和向量搜索的能力，并計劃在 4.5 版本中全面增強全文搜索、混合搜索和 JSON 的能力。既然這樣，能否讓 OceanBase 直接支持輕量部署，來滿足開發者對于 AI 原生數據庫的需求？很可惜，OceanBase 輕量版只能做到 2C8G 或者 2C6G，再往下則會遇到越來越多的工程化的挑戰。而我始終堅信，AI 會改變整個軟件行業，隨著 AI 應用的逐步深入，每個開發者都會有自己的 AI 原生數據庫，這個數據庫既要有強大的多?；旌纤阉鞴δ?，也要像開源關系數據庫（比如 MySQL/PostgreSQL）一樣小，可以部署在筆記本甚至是嵌入式設備上。因此，我們決定拋開歷史包袱，正式立項 AI 原生數據庫。

首先，需要給我們的 AI 原生數據庫一個正式的名字。我們內部做了很多次討論，有各種提議但很難達成一致，既有直給型的，比如 searchdb，aidb，aisearch，也有隱喻型的，比如 venusdb,orca，等等。直到某一天研發負責人羨林突然提議 seekdb 并立即獲得所有人的一致認同。seekdb 這個名字既是我們在 AI 原生數據庫上的探索，也是向 DeepSeek 致敬；既有強大的能力，也有極低的使用門檻，并對全球開源開放。

seekdb 的定位是面向開發者的 AI 原生數據庫，我們做的第一件事情是基于 OceanBase 的代碼做輕量化改造，刪除了部分不必要的代碼，包括分布式和 Oracle 兼容功能。seekdb 只提供面向開發者的線下部署版本，如果想要在公有云上使用或者想要購買商業化版本，怎么辦？我給的答案是直接使用 OceanBase。為此，我們做了一個設計約束：seekdb 的功能是 OceanBase 功能的子集。seekdb 面向開發者，與社區共建，且專注于開發者在 AI 場景的需求，因此，產品迭代速度會更快，而 OceanBase 會持續 follow seekdb 的功能并融入到 OceanBase。從使用者的角度看，基于 seekdb 開發的應用可以無需改造直接遷移到 OceanBase 商業版。

那么，seekdb 和 OceanBase 的定位有何不同呢？首先，不管是 seekdb 還是 OceanBase 都是一個能夠支持 AI 場景的 AI 數據庫，不同點在于，seekdb 只支持單機（含單機主備）且專注做好 AI 原生功能，即關系、JSON、向量和全文的多?；旌纤阉鳎?OceanBase 具備完整的 OLTP、OLAP 和混合搜索能力，支持單機和分布式等全部部署模式。如果用在 AI 創新場景，數據量沒有那么大，或者想要部署在端側等資源受限場景，推薦 seekdb；如果想要完整的 OLTP、OLAP 和 AI 功能，或者想要商業服務，推薦 OceanBase。

seekdb 對開發者意味著什么？

自從有了 seekdb 的想法之后，我和很多 AI 應用的開發者做了溝通，大家對 seekdb 的定位還是非常認同的。很多開發者都在開發自己的知識庫 RAG，我們之所以會提出 AI 原生混合搜索，正是看到了知識庫 RAG 需要拼裝各種不同的數據庫且經常遇到文檔的權限管理和共享問題。除了 RAG 以外，seekdb 也適合用在記憶管理和 AI Agent 開發。原先 AI Agent 開發需要多種不同的數據庫并在應用層做拼裝，有了 seekdb 之后，直接在數據庫層面通過一條 SQL 執行混合搜索即可。

對于開發者而言，seekdb 最重要的價值有兩個：一個是實現了多合一，簡化應用開發，另外一個是相比原先的向量 / 全文數據庫更加輕量。全文和向量數據庫的最小規格需要 4GB 甚至 8GB 的內存，而 seekdb 的第一個版本在實現多合一的前提下只需要 2GB 內存，且后續還會進一步優化到 1GB 乃至 500MB。雖然部分向量數據庫單獨提供了輕量版，但功能往往較為簡化，seekdb 在同等資源下支持的功能提供更強的能力，達到甚至超越業界已有的向量 / 全文數據庫。

在 OceanBase 2025 年度發布會，我們展示了 oceanbase.ai 上的一個 demo，通過三行代碼構建一個 AI 知識庫。seekdb 在 SQL 的基礎上封裝了單獨的 Python SDK，同時支持了嵌入式的部署模式。在 AI 的世界里，Python，Javascript 等才是開發者更加喜歡的語言。當然，要構建一個真實的 AI 應用，三行代碼肯定是遠遠不夠的，但我們相信，一個更好的支持多模混合搜索的 SDK 一定能夠簡化 AI 開發。

開源開放

在 OceanBase 年度發布會現場我見到很多 seekdb 的開發者，大家反饋了很多問題，包括 seekdb 編譯很慢，seekdb 不支持 Mac，等等，其中有一位是 langchain 中國區的布道師，他基于 seekdb 開發了一些混合搜索的 demo，但沒有辦法調出好的搜索效果。我認為，全球化和開源，以及社區合作是 AI 數據庫的基因。因此，我們這次把 seekdb 以及基于 seekdb 的 RAG 解決方案 PowerRAG 和 Mem 解決方案 PowerMem 都通過 Apache 2.0 協議開源。

通過和開發者溝通，我們對 seekdb 的定位越來越篤定，然而，目前我們發布的 seekdb 還只是第一個版本，雖然有 OceanBase 的 code base 作為基礎，但仍然存在不少的問題，包括：

• seekdb 的使用姿勢不夠靈活。如果采用 seekdb 預設的使用姿勢，比如采用 docker 部署，會比較順暢，但如果想要自己編譯，或者在 Mac 上安裝，seekdb 要么很慢，要么還不支持。后續我們會優先支持開發者喜歡的 Mac 安裝。

• 文檔和易用性還有待加強。我們支持了混合搜索，但缺乏相關的文檔和最佳實踐讓開發者能夠很簡單地調出最好的效果；我們也缺乏一些如何使用 seekdb 開發應用的文檔和技術博客。

• 混合搜索的能力還有待提升。多?；旌纤阉魇俏覀兲岢龅囊豁椚碌哪芰?，我們目前只實現了基礎功能，OLTP 和向量搜索的性能較好，但全文搜索、混合搜索以及 JSON 搜索的性能還需要提升，我們的研發正在快速迭代中。

• seekdb 支持的客戶端還不夠豐富。目前只支持了最簡單的 Python SDK，且只實現了有限的接口，后續需要豐富 Python SDK 并增加Javascript 等更多語言的支持。

• seekdb 還不夠小。我們推薦的配置為 2GB 內存，后續會盡快優化到 1GB。

• 開發者貢獻內核代碼還有不小的難度。seekdb 非常歡迎開發者成為內核代碼的 contributor，但目前代碼量較大，且代碼編譯需要的時間較長。因此，推薦開發者使用配置更好的服務器并行編譯，同時，我們后續也會撰寫更多源碼解析相關的文檔。

seekdb 仍處于早期階段，但我們相信多?；旌纤阉魇?AI 數據庫的未來，相信開源和社區的力量——我們希望與 AI 開發者一起，做好開源與社區建設，把 seekdb 打造成 AI 開發的主流選擇。

誠邀開發者和我們一起探索 AI 原生數據庫：

https://github.com/oceanbase/seekdb