作者 | 楊傳輝，OceanBase CTO

我們需要一款怎樣的 AI 數(shù)據(jù)庫(kù)？

基于大模型的 AI 技術(shù)已經(jīng)成為行業(yè)共識(shí)，各個(gè)行業(yè)的企業(yè)都在知識(shí)庫(kù)、AI Coding、智能客服、ChatBI、Agent 開(kāi)發(fā)等場(chǎng)景落地大模型。然而，在真正進(jìn)入企業(yè)業(yè)務(wù)后，會(huì)暴露兩個(gè)問(wèn)題：

• 缺乏企業(yè)的私有數(shù)據(jù)：基礎(chǔ)大模型采用海量公網(wǎng)數(shù)據(jù)做預(yù)訓(xùn)練，雖然具備一定的“智能涌現(xiàn)”，但永遠(yuǎn)不可能理解企業(yè)的私有數(shù)據(jù)。這就像企業(yè)招聘了一位新員工，雖然經(jīng)過(guò)了良好的教育，但還需要通過(guò)一段時(shí)間的新員工培訓(xùn)和動(dòng)手實(shí)踐才能真正勝任企業(yè)的日常工作。

• 缺乏記憶。大模型底層采用 transformer 架構(gòu)，只能批量訓(xùn)練（預(yù)訓(xùn)練 / 后訓(xùn)練），無(wú)法根據(jù)用戶的實(shí)時(shí)行為動(dòng)態(tài)反饋。

因此，為了讓 AI 在企業(yè)落地，需要依賴(lài)數(shù)據(jù)庫(kù)實(shí)時(shí)存儲(chǔ)企業(yè)私有數(shù)據(jù)和用戶的實(shí)時(shí)行為，并通過(guò)智能搜索得到大模型需要的上下文，這個(gè)過(guò)程也被稱(chēng)作上下文工程。對(duì)于企業(yè)來(lái)講，大模型基礎(chǔ)能力是通用的，私有數(shù)據(jù)和用戶行為才是核心資產(chǎn)，如何通過(guò)數(shù)據(jù)庫(kù)把這些核心資產(chǎn)用好，決定了企業(yè)在 AI 時(shí)代的核心競(jìng)爭(zhēng)力。

另外，AI 時(shí)代將會(huì)帶來(lái)技術(shù)平權(quán)，原先只能通過(guò)專(zhuān)業(yè)人士開(kāi)發(fā)的應(yīng)用 /APP 來(lái)讀寫(xiě)數(shù)據(jù)庫(kù)，而在 AI 時(shí)代，每個(gè)不懂技術(shù)的非專(zhuān)業(yè)人士也能利用大模型技術(shù)通過(guò)多輪對(duì)話的方式構(gòu)建自己的 AI Agent，這些海量的 AI Agent 底層都需要用到數(shù)據(jù)庫(kù)，使得數(shù)據(jù)庫(kù)的用戶規(guī)模 / 租戶規(guī)模會(huì)有數(shù)量級(jí)的提升。

基于這些變化，AI 場(chǎng)景正在驅(qū)動(dòng)數(shù)據(jù)庫(kù)出現(xiàn)一個(gè)全新的工作負(fù)載，我把它稱(chēng)為：面向 Agent 的多模混合搜索。首先，數(shù)據(jù)庫(kù)不僅僅需要處理結(jié)構(gòu)化數(shù)據(jù)（關(guān)系），也需要處理半結(jié)構(gòu)化數(shù)據(jù)（JSON），以及無(wú)結(jié)構(gòu)化數(shù)據(jù)，除了支持關(guān)系表的二級(jí)索引，也能支持全文索引，向量語(yǔ)義索引，圖索引等，即具備多模能力。其次，數(shù)據(jù)庫(kù)需要能夠支持結(jié)構(gòu)化、半結(jié)構(gòu)化和無(wú)結(jié)構(gòu)化數(shù)據(jù)的混合搜索。最后，數(shù)據(jù)庫(kù)需要支持海量 Agent 同時(shí)使用，即具備海量多租戶能力。

AI 數(shù)據(jù)庫(kù)的“變與不變”

在 OceanBase 2025 發(fā)布會(huì)上，我們討論過(guò)一個(gè)觀點(diǎn)：AI 時(shí)代，數(shù)據(jù)庫(kù)的變與不變。

數(shù)據(jù)庫(kù)在 AI 時(shí)代雖然新增了“面向 Agent 的多模混合搜索”工作負(fù)載，但是，不管未來(lái) AI 如何發(fā)展，數(shù)據(jù)庫(kù)的核心需求是會(huì)一直存在的，需要通過(guò)行存來(lái)做交易，通過(guò)列存來(lái)做分析，并通過(guò)強(qiáng)大的 SQL 優(yōu)化器來(lái)支持復(fù)雜查詢和 HTAP。數(shù)據(jù)庫(kù)需要確保數(shù)據(jù)不丟，確保穩(wěn)定可靠，支持各種靈活的部署方式。

從實(shí)現(xiàn)路徑來(lái)看，目前有兩種思路實(shí)現(xiàn) AI 數(shù)據(jù)庫(kù)。第一種是從零開(kāi)始構(gòu)建一個(gè)“多?；旌纤阉鳌睌?shù)據(jù)庫(kù)，如向量數(shù)據(jù)庫(kù)、全文搜索數(shù)據(jù)庫(kù)；第二種是在成熟的關(guān)系數(shù)據(jù)庫(kù)基礎(chǔ)之上擴(kuò)展多模混合搜索的功能，PostgreSQL，Oracle 和 OceanBase 都屬于這一方向。關(guān)系數(shù)據(jù)庫(kù)不管是在功能豐富度、易用性、開(kāi)發(fā)者和 DBA 生態(tài)、成熟度和穩(wěn)定性等方面都遠(yuǎn)遠(yuǎn)好于其它非關(guān)系數(shù)據(jù)庫(kù)，且經(jīng)過(guò)了大量企業(yè)的核心業(yè)務(wù)場(chǎng)景打磨驗(yàn)證，技術(shù)壁壘非常高。未來(lái)，兩種方式會(huì)長(zhǎng)期共存，第二種技術(shù)路線很大概率會(huì)占據(jù)主流。

AI 原生混合搜索

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

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

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

現(xiàn)代數(shù)據(jù)架構(gòu)

從一體化架構(gòu)開(kāi)始，OceanBase 一直在思考現(xiàn)代數(shù)據(jù)架構(gòu)。在我們看來(lái)，現(xiàn)代數(shù)據(jù)架構(gòu)可以總結(jié)為三個(gè)特點(diǎn)：

• 易用：現(xiàn)代數(shù)據(jù)架構(gòu)面向開(kāi)發(fā)者做了專(zhuān)門(mén)設(shè)計(jì)，開(kāi)發(fā)者想要什么能力，直接使用現(xiàn)代數(shù)據(jù)架構(gòu)提供的功能或者服務(wù)，而不是根據(jù)不同的功能選擇不同的產(chǎn)品，學(xué)習(xí)不同的技術(shù)棧。這個(gè)設(shè)計(jì)理念也是 OceanBase 一體化架構(gòu)的初衷，通過(guò)在一套引擎中支持 OLTP、OLAP 和 AI 原生搜索來(lái)屏蔽底層數(shù)據(jù)庫(kù)的技術(shù)細(xì)節(jié)。

• 靈活：現(xiàn)代數(shù)據(jù)架構(gòu)必須支持按需使用，能夠支持從“無(wú)限”小到“無(wú)限”大的工作負(fù)載。這是因?yàn)?，AI 場(chǎng)景的工作負(fù)載具有不確定性，大部分 AI Agent 都是默默無(wú)聞的，少部分的 AI Agent 的流量很高，且流量具備突發(fā)性。為了支持“無(wú)限”小，需要能夠支持 Serverless，為了支持“無(wú)限”大，需要底層能夠支持原生分布式架構(gòu)實(shí)現(xiàn)在線擴(kuò)展。

• 面向未來(lái)：擁抱 AI，已經(jīng)不再是前瞻性的選擇，而是面向未來(lái)的必然起點(diǎn)。現(xiàn)代數(shù)據(jù)架構(gòu)需要能夠原生支持 AI 工作負(fù)載，既包括多?；旌纤阉鳎舶êＡ慷嘧鈶舻哪芰?。

數(shù)模融合

OceanBase 的 AI 戰(zhàn)略叫做“Data x AI”，而不是“Data+AI”。從技術(shù)發(fā)展趨勢(shì)來(lái)看，數(shù)據(jù)與模型的深度融合正在成為必然方向。首先，多?；旌纤阉骷纫龆嗄?shù)據(jù)的搜索，也要用模型做 embedding 和 rerank，這本身就是一種數(shù)據(jù)與模型的融合。

其次，業(yè)界開(kāi)始出現(xiàn)一些流行的 AI 原生應(yīng)用，比如飛書(shū)和釘釘?shù)?AI 多維表格，可以直接在表格的每個(gè)數(shù)據(jù)單元執(zhí)行 AI Function，包括大模型總結(jié)、翻譯、打標(biāo)簽、等等，這是一種技術(shù)趨勢(shì)。通過(guò)數(shù)據(jù)和模型的融合（簡(jiǎn)稱(chēng)“數(shù)模融合”），一方面能夠大幅簡(jiǎn)化 AI 應(yīng)用開(kāi)發(fā)，另一方面也能創(chuàng)造一些 AI 特色的功能。舉個(gè)例子，當(dāng)我們想要給所有年齡在 30-35 歲之間所有關(guān)注下一代成長(zhǎng)的媽媽發(fā)一封通過(guò)大語(yǔ)言模型自動(dòng)生成的郵件時(shí)，只需要一條 SQL 語(yǔ)句加上 AI Function 就可以實(shí)現(xiàn)。

除了 AI Function，數(shù)據(jù)庫(kù)也可以通過(guò)一些方式幫助大模型更好地理解數(shù)據(jù)。例如，Oracle 26ai 版本引入的 Annotations（注釋?zhuān)┕δ?，通過(guò)輕量式聲明，幫助大模型理解數(shù)據(jù)，這也是數(shù)據(jù)與模型逐步融合的一種體現(xiàn)。

可以預(yù)見(jiàn)，AI 數(shù)據(jù)庫(kù)將從“AI Ready”逐步演進(jìn)到“AI Native”。數(shù)據(jù)庫(kù)既可以只做數(shù)據(jù)處理，把數(shù)據(jù)準(zhǔn)備好，由應(yīng)用從數(shù)據(jù)中搜索出精準(zhǔn)的上下文作為提示詞調(diào)用模型，也可以直接在數(shù)據(jù)庫(kù)中調(diào)用模型，一條 SQL 語(yǔ)句既操作數(shù)據(jù)也調(diào)用模型，實(shí)現(xiàn)數(shù)據(jù)與模型的深度融合。

小結(jié)

總體來(lái)看，AI 數(shù)據(jù)庫(kù)有三個(gè)核心特點(diǎn)：

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

• 面向 AI 場(chǎng)景的現(xiàn)代數(shù)據(jù)架構(gòu)。通過(guò) Serverless 和分布式架構(gòu)，實(shí)現(xiàn)從“無(wú)限小”到“無(wú)限大”的完全彈性能力，支持海量多租戶與靈活部署。

• 數(shù)據(jù)與模型的深度融合，逐步走向“AI native“，未來(lái)會(huì)有越來(lái)越多在數(shù)據(jù)庫(kù)中直接融合模型能力的 AI 原生數(shù)據(jù)庫(kù)。

基于這些思考，我們?cè)?OceanBase 中逐步增加 AI 數(shù)據(jù)庫(kù)能力，并基于 Apache 2.0 協(xié)議開(kāi)源了 AI 原生數(shù)據(jù)庫(kù) seekdb。接下來(lái)的幾個(gè)部分會(huì)深入探討 AI 數(shù)據(jù)庫(kù)的思考，包括：

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

• <>：介紹現(xiàn)代數(shù)據(jù)架構(gòu)的設(shè)計(jì)邏輯。

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

• < <為什么要做 ai 原生數(shù)據(jù)庫(kù) seekdb> >：介紹 OceanBase seekdb 的初心、定位、現(xiàn)有核心能力與不足。

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

數(shù)據(jù)庫(kù)最早為應(yīng)用服務(wù)，處理結(jié)構(gòu)化數(shù)據(jù)，得到的是確定性的結(jié)果。而在 AI 場(chǎng)景下，數(shù)據(jù)庫(kù)不僅為應(yīng)用服務(wù)，更為智能服務(wù)，需要處理無(wú)結(jié)構(gòu)化數(shù)據(jù)，通過(guò)規(guī)則和模型得到語(yǔ)義近似的結(jié)果，這個(gè)過(guò)程通常稱(chēng)為搜索。由于這個(gè)過(guò)程涉及到結(jié)構(gòu)化數(shù)據(jù)（關(guān)系表）、半結(jié)構(gòu)化數(shù)據(jù)（JSON）以及無(wú)結(jié)構(gòu)化數(shù)據(jù)的各類(lèi)索引（向量索引、全文索引、圖索引），因此可以統(tǒng)稱(chēng)為多?；旌纤阉?，或者 AI 原生混合搜索。

RAG 技術(shù)的出現(xiàn)主要是為了解決大模型的幻覺(jué)和知識(shí)陳舊問(wèn)題。最早的 RAG 一般依賴(lài)向量搜索：應(yīng)用層對(duì)文檔等無(wú)結(jié)構(gòu)化數(shù)據(jù)進(jìn)行 embedding，接著在向量數(shù)據(jù)庫(kù)執(zhí)行向量近似查詢（similarity search），并通過(guò)向量索引來(lái)實(shí)現(xiàn)查詢加速。然而，為了提升搜索效果，僅僅向量搜索是不夠的，還需要融入關(guān)系查詢、JSON 查詢、全文搜索，某些場(chǎng)景甚至還需要基于知識(shí)圖譜的圖搜索，以獲取更全面和準(zhǔn)確的上下文信息。

業(yè)界已有一些流行的向量數(shù)據(jù)庫(kù)，比如 Milvus、Pinecone、Qdrant 等，這些產(chǎn)品在向量搜索方面表現(xiàn)優(yōu)秀，部分產(chǎn)品也在逐步引入全文搜索等功能，但全文搜索能力距離實(shí)際業(yè)務(wù)的需求相比仍有差距。全文搜索數(shù)據(jù)庫(kù)最典型的代表是 Elastic Search（簡(jiǎn)稱(chēng) ES），ES 的全文搜索能力較強(qiáng)，但向量搜索能力還有待提升，且不支持關(guān)系數(shù)據(jù)庫(kù)的多表 Join 操作。另外，不管是向量數(shù)據(jù)庫(kù)還是 ES，往往缺乏數(shù)據(jù)庫(kù)的綜合能力，比如數(shù)據(jù)庫(kù)安全及權(quán)限管理，SQL 優(yōu)化器自動(dòng)選擇執(zhí)行路徑等。

混合搜索提升召回效果

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

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

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

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

• 基于模型的算法：BGE-reranker 是一種常見(jiàn)的排序模型，隨著大模型技術(shù)的發(fā)展，我們發(fā)現(xiàn) Qwen-rerank 等排序模型的效果經(jīng)常更加出色。

關(guān)系數(shù)據(jù)庫(kù)融合混合搜索

業(yè)界的混合搜索系統(tǒng)，比如 Elastic Search，除了支持搜索功能，也能實(shí)現(xiàn)常見(jiàn)的關(guān)系過(guò)濾。那么，在關(guān)系數(shù)據(jù)庫(kù)上構(gòu)建混合搜索有什么優(yōu)勢(shì)呢？我們舉一個(gè)簡(jiǎn)單的例子進(jìn)行說(shuō)明。

文檔知識(shí)庫(kù)是一個(gè)常見(jiàn)的 AI 應(yīng)用場(chǎng)景，將文檔寫(xiě)入到數(shù)據(jù)庫(kù)后執(zhí)行混合搜索，這就可能導(dǎo)致引用了用戶無(wú)權(quán)訪問(wèn)的數(shù)據(jù)，這個(gè)問(wèn)題也被稱(chēng)為隱式越權(quán)。為了避免這樣的問(wèn)題，需要給每個(gè)文檔設(shè)置權(quán)限，比如只允許某些人，或者某些部門(mén)訪問(wèn)。

如果采用 ES 來(lái)實(shí)現(xiàn)文檔搜索，由于 ES 的數(shù)據(jù)模型是大寬表，不支持多表做 Join，因此，只能對(duì)每個(gè)文檔增加一列用來(lái)表示允許訪問(wèn)的用戶以及部門(mén)列表。當(dāng)允許訪問(wèn)的用戶或者部門(mén)越來(lái)越多，或者需要經(jīng)常修改時(shí)，無(wú)論是搜索性能還是更新效率都會(huì)大幅下降。

關(guān)系數(shù)據(jù)庫(kù)支持完整的 SQL 功能，可以單獨(dú)維護(hù)一張文檔權(quán)限表，并在搜索時(shí)根據(jù)文檔的編號(hào)對(duì)文檔權(quán)限表與文檔內(nèi)容表做多表 Join 操作，實(shí)時(shí)性和靈活性大幅提升。一般來(lái)講，企業(yè)剛開(kāi)始構(gòu)建文檔知識(shí)庫(kù)時(shí)往往只考慮搜索的效果，等到搜索效果滿足業(yè)務(wù)需求之后會(huì)逐步引入文檔權(quán)限，文檔共享等多種豐富的功能，而這些功能正是關(guān)系數(shù)據(jù)庫(kù)所擅長(zhǎng)的。

另外，關(guān)系數(shù)據(jù)庫(kù)具備很強(qiáng)的 SQL 優(yōu)化執(zhí)行能力，可以根據(jù)統(tǒng)計(jì)信息自動(dòng)地選擇最優(yōu)的執(zhí)行路徑，例如，先做關(guān)系過(guò)濾還是向量搜索，還是邊過(guò)濾邊搜索，等等。除了關(guān)系數(shù)據(jù)之外，還會(huì)經(jīng)常用到 JSON。這是因?yàn)?，源端往往有多個(gè)不同的數(shù)據(jù)源，數(shù)據(jù)入庫(kù)時(shí)經(jīng)常映射到相同的一張表格，因此，將部分無(wú)法統(tǒng)一的字段用 JSON 來(lái)表示，并且通過(guò)在 JSON 上構(gòu)建 Search Index，支持對(duì)于 JSON 字段的實(shí)時(shí)查詢。

幾個(gè)典型應(yīng)用場(chǎng)景

知識(shí)庫(kù) RAG

知識(shí)庫(kù)天然需要用到混合搜索，業(yè)界有一個(gè)流行的開(kāi)源框架 ragflow，為了更好地支持混合搜索，OceanBase 基于 ragflow 二次開(kāi)發(fā)了企業(yè)級(jí) RAG 解決方案 PowerRAG，已應(yīng)用在螞蟻集團(tuán)并在 github 開(kāi)源。

知識(shí)庫(kù) RAG 分為離線部分和在線部分：

• 離線部分從數(shù)據(jù)入庫(kù) =>文檔解析切片 =>文檔 / 切片入庫(kù)。

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

可以看到，離線部分相當(dāng)于是數(shù)據(jù)庫(kù)的 ETL，在線部分主要是數(shù)據(jù)庫(kù)的混合搜索。

記憶 Mem

大模型缺乏記憶，而記憶又可分為長(zhǎng)記憶與短記憶。由于大模型的上下文窗口有限，一般會(huì)對(duì)長(zhǎng)記憶做概要總結(jié)，把長(zhǎng)記憶的概要數(shù)據(jù)和短記憶一起作為大模型的輸入上下文。

業(yè)界已出現(xiàn)一些流行的大模型記憶解決方案，比如 Mem0，為了更好地支持混合搜索，OceanBase 在 github 開(kāi)源了兼容 Mem0 接口的企業(yè)級(jí) Mem 解決方案 PowerMem，在針對(duì) Mem 場(chǎng)景的 LOCOMO benchmark 上達(dá)到了開(kāi)源 Mem 解決方案的 SOTA 水準(zhǔn)。

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

AI Agent 智能搜索

AI Agent 往往需要同時(shí)查找關(guān)系、JSON、GIS、向量、全文，等。例如，在螞蟻的百寶箱應(yīng)用中，有一個(gè)常見(jiàn)的場(chǎng)景：

“推薦距離五百米以內(nèi)，人均消費(fèi) 25 元以下、評(píng)分 4.5 以上，多數(shù)人喜歡的咖啡廳”。

這個(gè)場(chǎng)景涉及到 GIS（五百米以內(nèi)），也涉及到關(guān)系查找（人均消費(fèi) 25 以下，評(píng)分 4.5 以上），還涉及到語(yǔ)義搜索（多數(shù)人喜歡）。傳統(tǒng)的方案往往是采用多種不同的數(shù)據(jù)庫(kù)，包括關(guān)系數(shù)據(jù)庫(kù)、GIS 數(shù)據(jù)庫(kù)、向量數(shù)據(jù)庫(kù)，并在 AI Agent 應(yīng)用層做拼裝，有了混合搜索數(shù)據(jù)庫(kù)之后，這些繁瑣的業(yè)務(wù)邏輯都可以下沉到數(shù)據(jù)庫(kù)。相比傳統(tǒng)方案，混合搜索數(shù)據(jù)庫(kù)有兩個(gè)優(yōu)勢(shì)：一個(gè)是實(shí)現(xiàn)多合一，統(tǒng)一技術(shù)棧；另外一個(gè)是通過(guò)算子下壓能夠在數(shù)據(jù)庫(kù)層面做優(yōu)化，避免中間結(jié)果過(guò)大等一系列問(wèn)題。

小結(jié)

AI 原生混合搜索在一套引擎完成關(guān)系、JSON、向量、全文的混合搜索，部分場(chǎng)景通過(guò)圖搜索進(jìn)一步提升搜索效果。通過(guò)在關(guān)系數(shù)據(jù)庫(kù)基礎(chǔ)上構(gòu)建混合搜索，能夠復(fù)用關(guān)系數(shù)據(jù)庫(kù)已有的實(shí)時(shí)寫(xiě)入、事務(wù)一致性和 HTAP 關(guān)系查詢的能力，使得混合搜索不僅用于 AI 創(chuàng)新嘗試，也用于嘗試后的實(shí)際生產(chǎn)系統(tǒng)。OceanBase 混合搜索已經(jīng)應(yīng)用到知識(shí)庫(kù) RAG、大模型記憶、智能搜索等多種實(shí)際生產(chǎn)系統(tǒng)中的 AI 場(chǎng)景，實(shí)現(xiàn)了數(shù)據(jù)庫(kù)多合一、統(tǒng)一技術(shù)棧、簡(jiǎn)化業(yè)務(wù)、提升召回效果等業(yè)務(wù)價(jià)值。

AI Ready 的現(xiàn)代數(shù)據(jù)架構(gòu)

AI 時(shí)代帶來(lái)技術(shù)平權(quán)，從數(shù)據(jù)庫(kù)使用方式來(lái)看，主要帶來(lái)兩點(diǎn)變化：一是每個(gè)普通用戶通過(guò) AI Agent 使用數(shù)據(jù)庫(kù)，帶來(lái)海量多租戶需求；二是新增了全新的多?；旌纤阉鞴ぷ髫?fù)載。同時(shí)，原先的 OLTP、OLAP 以及 HTAP 的需求仍然存在。

以螞蟻集團(tuán)在 2025 年 11 月 18 日推出的全模態(tài)通用 AI 助手“靈光”為例，靈光的右上角有一個(gè)用戶喜歡的功能“閃應(yīng)用”，使得每個(gè)即便不懂技術(shù)的普通用戶都能夠創(chuàng)建自己的 AI Agent，每個(gè) AI Agent 相當(dāng)于數(shù)據(jù)庫(kù)的一個(gè)租戶，每個(gè)租戶可以擁有獨(dú)立的表格、索引等 schema。對(duì)于 AI Agent 來(lái)說(shuō)，通常大部分用戶創(chuàng)建的 Agent 都是不太活躍的，只有少量用戶創(chuàng)建的 Agent 流量很高。而且 Agent 的流量具有很強(qiáng)的突發(fā)性，某些默默無(wú)聞的應(yīng)用可能因?yàn)槟承┦录虝r(shí)間內(nèi)成為熱門(mén)應(yīng)用。

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

從集中式到分布式

在設(shè)計(jì)理念上，分布式與集中式最大的區(qū)別在于“Take failure as granted”，把故障當(dāng)成是一種正?，F(xiàn)象，并通過(guò)軟件冗余的方式來(lái)實(shí)現(xiàn)自動(dòng)容錯(cuò)、自動(dòng)恢復(fù)。相比集中式架構(gòu)，分布式架構(gòu)帶來(lái)如下幾點(diǎn)好處：

• 自動(dòng)容錯(cuò)：當(dāng)服務(wù)器、機(jī)房、甚至城市發(fā)生故障時(shí)，能夠自動(dòng)恢復(fù)，完全不丟失數(shù)據(jù)。OceanBase 甚至做到了 RPO=0，RTO<8 秒。

• 自動(dòng)擴(kuò)縮容：系統(tǒng)處理能力不足時(shí)，可以通過(guò)在線增加服務(wù)器來(lái)自動(dòng)提升系統(tǒng)的處理能力。業(yè)務(wù)高峰期過(guò)后，也可以在線刪除服務(wù)器。原生分布式數(shù)據(jù)庫(kù)能夠做到自動(dòng)擴(kuò)縮容對(duì)業(yè)務(wù)無(wú)感。

• 低存儲(chǔ)成本：早期的數(shù)據(jù)庫(kù)采用 B+ 樹(shù)存儲(chǔ)引擎，而以分布式數(shù)據(jù)庫(kù)為代表的新型數(shù)據(jù)庫(kù)，往往采用 LSM-Tree 存儲(chǔ)引擎。B+ 樹(shù)比較適合數(shù)據(jù)量較小，更新比較頻繁的數(shù)據(jù)，而 LSM-Tree 比較適合數(shù)據(jù)量較大的場(chǎng)景，而新型數(shù)據(jù)庫(kù)在設(shè)計(jì)時(shí)往往假設(shè)數(shù)據(jù)量比較大。LSM-Tree 的存儲(chǔ)成本遠(yuǎn)低于 B+ 樹(shù)，OceanBase 在很多場(chǎng)景通過(guò)采用 LSM-Tree 替換傳統(tǒng)數(shù)據(jù)庫(kù)的 B+ 樹(shù)將存儲(chǔ)成本降低了 70%~90%。

分布式數(shù)據(jù)庫(kù)引入了一個(gè)問(wèn)題，那就是分布式架構(gòu)本身帶來(lái)的額外開(kāi)銷(xiāo)。分布式數(shù)據(jù)庫(kù)為了保證高可用和分布式事務(wù)，往往會(huì)對(duì)數(shù)據(jù)進(jìn)行分片 / 分區(qū)，每個(gè)分片 / 分區(qū)需要通過(guò) Paxos 協(xié)議來(lái)實(shí)現(xiàn)自動(dòng)容錯(cuò)，對(duì)于跨分片 / 分區(qū)的操作，即使在一臺(tái)機(jī)器上，也需要通過(guò)兩階段提交協(xié)議（Two Phase Commit）來(lái)保證事務(wù)的一致性。這些開(kāi)銷(xiāo)在集中式數(shù)據(jù)庫(kù)中是不存在的。為了解決這個(gè)問(wèn)題，OceanBase 4.0 版本提出了一種全新的架構(gòu)方案，叫做單機(jī)分布式一體化架構(gòu)，使得分布式數(shù)據(jù)庫(kù)在不涉及跨機(jī)事務(wù)時(shí)沒(méi)有額外的分布式開(kāi)銷(xiāo)。

一體化架構(gòu)

一體化架構(gòu)的核心是：多負(fù)載、多模和混合多云，簡(jiǎn)稱(chēng)“三多”。

首先，一體化架構(gòu)在一套引擎中同時(shí)支持 OLTP、OLAP 和 AI 混合負(fù)載。HTAP 數(shù)據(jù)庫(kù)是一種現(xiàn)代數(shù)據(jù)架構(gòu)，能夠?qū)崿F(xiàn)在線實(shí)時(shí)分析，有兩種典型的實(shí)現(xiàn)方案：

• 多副本：OLTP 采用行存，OLAP 采用列存，行存和列存采用不同的副本，并通過(guò) SQL 優(yōu)化器來(lái)將用戶的請(qǐng)求自動(dòng)路由到不同的副本；

• 單副本：采用行列混合存儲(chǔ)（類(lèi) PAX 方案）在一個(gè)副本上同時(shí)支持 OLTP 和 OLAP 兩種工作負(fù)載。

這兩種方案各有優(yōu)勢(shì)，第一種方案可以更好地支持 OLTP 和 OLAP 兩種工作負(fù)載的隔離，適合 OLAP 工作負(fù)載較重的場(chǎng)景，第二種方案能夠更好地保證在線分析的實(shí)時(shí)性，適合 OLAP 工作負(fù)載較輕的場(chǎng)景，比如簡(jiǎn)單的跑批或者簡(jiǎn)單的在線統(tǒng)計(jì)。OceanBase 同時(shí)支持了這兩種模式，在 OceanBase 4.4 版本中還實(shí)現(xiàn)了一個(gè)增量實(shí)時(shí)物化視圖功能。通過(guò)該功能，數(shù)據(jù)庫(kù)會(huì)自動(dòng)通過(guò)增量刷新的方式維護(hù)一個(gè)實(shí)時(shí)物化視圖，從而支持在同一個(gè)副本中既做交易，也做在線分析，并將在線分析由原始表的批量掃描變成實(shí)時(shí)物化視圖的點(diǎn)查。

其次，一體化架構(gòu)在存儲(chǔ)層支持多模，從而在一套系統(tǒng)中同時(shí)支持結(jié)構(gòu)化、半結(jié)構(gòu)化和無(wú)結(jié)構(gòu)化數(shù)據(jù)。結(jié)構(gòu)化數(shù)據(jù)的底層采用關(guān)系表，半結(jié)構(gòu)化數(shù)據(jù)采用 JSON，無(wú)結(jié)構(gòu)化數(shù)據(jù)一般會(huì)構(gòu)建語(yǔ)義索引，包括向量索引、全文索引，等等。

最后，一體化架構(gòu)支持多云和混合云，簡(jiǎn)稱(chēng)混合多云。為了支持多云，需要采用云中立的架構(gòu)方案。對(duì)象存儲(chǔ)是一種云中立的存儲(chǔ)方案，所有的主流云平臺(tái)都支持兼容 S3 接口的對(duì)象存儲(chǔ)。多云架構(gòu)強(qiáng)依賴(lài) K8s 做調(diào)度，OceanBase 在做多云架構(gòu)時(shí)發(fā)現(xiàn)不同云平臺(tái)的 K8s 實(shí)現(xiàn)不完全相同，例如阿里云 K8s 支持固定 IP 且升級(jí) K8S 時(shí)對(duì)業(yè)務(wù)無(wú)損，而 AWS 的 K8s 無(wú)法支持固定 IP 且升級(jí)對(duì)業(yè)務(wù)有損，因此，為了實(shí)現(xiàn)多云原生架構(gòu)，OceanBase 只能自己實(shí)現(xiàn)云中立的 K8s 方案。多云原生架構(gòu)還需要能夠?qū)崿F(xiàn)跨云容災(zāi)，比如主集群和備集群分別部署在不同的公有云，或者單個(gè)集群支持跨云部署和跨云容災(zāi)。

對(duì)象存儲(chǔ)與 Serverless

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

AI 場(chǎng)景的工作負(fù)載具有很強(qiáng)的不確定性，大部分 AI Agent 都是沒(méi)有多少訪問(wèn)量的，這就要求 AI 數(shù)據(jù)庫(kù)原生支持海量多租戶和 Serverless。Serverless 架構(gòu)有幾個(gè)核心指標(biāo)：當(dāng)某個(gè)租戶訪問(wèn)量為 0 時(shí)占用的最小資源，當(dāng)沒(méi)有訪問(wèn)的冷租戶突然有流量時(shí)需要的加載時(shí)間，以及有突發(fā)流量時(shí)彈性擴(kuò)容需要的時(shí)間。海量多租戶帶來(lái)的核心挑戰(zhàn)包括兩點(diǎn)：一個(gè)是不同租戶之間的資源隔離問(wèn)題，包括 CPU、內(nèi)存、存儲(chǔ) IO、以及網(wǎng)絡(luò)等，另外一個(gè)是海量多租戶帶來(lái)的海量表格 schema 管理的問(wèn)題。OceanBase 廣泛應(yīng)用在 SaaS 行業(yè)，包括用友以及零售 SaaS 等，剛開(kāi)始經(jīng)常遇到表格太多導(dǎo)致資源消耗過(guò)大的問(wèn)題，為了解決這個(gè)問(wèn)題，我們成立了專(zhuān)門(mén)的 schema 優(yōu)化項(xiàng)目組，對(duì)每個(gè)表格 schema 占用的內(nèi)存和 schema 管理后臺(tái)任務(wù)占用的 CPU 資源進(jìn)行了大量的優(yōu)化，最終將單個(gè)集群支持的表格數(shù)提升了一到兩個(gè)數(shù)量級(jí)，滿足了 SaaS 行業(yè)和 AI 場(chǎng)景的海量表格需求。

小結(jié)

為了支持 AI 場(chǎng)景，需要與之匹配的 AI Ready 現(xiàn)代數(shù)據(jù)架構(gòu)。AI Ready 數(shù)據(jù)架構(gòu)是彈性的，支持從“無(wú)限小”的 Serverless 到“無(wú)限大”的全分布式架構(gòu)；AI Ready 數(shù)據(jù)架構(gòu)是易用的，通過(guò)統(tǒng)一的技術(shù)棧支持多種不同的工作負(fù)載，具有很好的實(shí)時(shí)性；AI Ready 數(shù)據(jù)架構(gòu)是面向未來(lái)的，能夠很好地支持 AI 場(chǎng)景需要的海量多租戶和多?；旌纤阉?，等等。

從 AI Ready 到 AI Native 數(shù)據(jù)庫(kù)

數(shù)據(jù)和模型之間的關(guān)系到底是什么？首先，AI 時(shí)代的數(shù)據(jù)庫(kù)需要 AI Ready，即幫助 AI 把大模型需要的上下文準(zhǔn)備好。然而，隨著 AI 應(yīng)用逐步深入，我們發(fā)現(xiàn)越來(lái)越多的 AI 原生應(yīng)用需要同時(shí)操作數(shù)據(jù)和模型，數(shù)據(jù)庫(kù)僅僅 AI Ready 是不夠的，還需要進(jìn)一步融合數(shù)據(jù)和模型的能力，成為 AI Native 數(shù)據(jù)庫(kù)。

數(shù)據(jù)庫(kù)和 AI 融合并不是一個(gè)全新的概念，學(xué)術(shù)界和工業(yè)界一直在探索。難點(diǎn)在于如何定義數(shù)據(jù)庫(kù)和 AI 的邊界，讓數(shù)據(jù)庫(kù)擅長(zhǎng)的歸數(shù)據(jù)庫(kù)，讓 AI 擅長(zhǎng)的歸 AI。過(guò)去，學(xué)術(shù)界曾經(jīng)嘗試用 AI 的方式來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)的內(nèi)核模塊，比如用 AI 寫(xiě)優(yōu)化器，但是在實(shí)際生產(chǎn)系統(tǒng)很難落地，根本原因在于 AI 在寫(xiě)優(yōu)化器處理結(jié)構(gòu)化數(shù)據(jù)這件事情上并不如專(zhuān)業(yè)的程序員。我認(rèn)為，大模型在數(shù)據(jù)領(lǐng)域的優(yōu)勢(shì)主要有兩點(diǎn)：一是具有很強(qiáng)的泛化能力，能夠理解自然語(yǔ)言，簡(jiǎn)化數(shù)據(jù)庫(kù)的使用界面；二是能夠?qū)Ψ墙Y(jié)構(gòu)化數(shù)據(jù)進(jìn)行語(yǔ)義處理。數(shù)據(jù)庫(kù)和 AI 融合的關(guān)鍵在于如何將這兩項(xiàng)能力融入到數(shù)據(jù)庫(kù)中。

業(yè)界越來(lái)越多數(shù)據(jù)庫(kù)產(chǎn)品開(kāi)始將 AI 能力融入內(nèi)核。Snowflake 是一個(gè)典型的代表，通過(guò)集成 Cortex 平臺(tái)和 AISQL 操作符，可以直接將數(shù)據(jù)管理能力擴(kuò)展到非結(jié)構(gòu)化數(shù)據(jù)和 LLM 推理領(lǐng)域；微軟也在最近（2025.11.19）宣布了一個(gè)新產(chǎn)品 Azure HorizonDB，其中一項(xiàng)重要改進(jìn)就是內(nèi)置了模型的能力，包括 Generate、Embedding、Rerank 等各類(lèi)模型。

AI 原生場(chǎng)景

DataAgent

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

知識(shí)庫(kù) RAG

知識(shí)庫(kù) RAG 分為離線部分和在線部分。對(duì)于離線部分，外部的各種數(shù)據(jù)源的不同格式的數(shù)據(jù)往往會(huì)轉(zhuǎn)化為中間格式（PDF/markdown），接著再對(duì)中間格式進(jìn)行文檔解析，包括內(nèi)容理解、領(lǐng)域適配、結(jié)構(gòu)化提取、多模態(tài)理解，等等，解析后的文檔直接寫(xiě)入或者分片后再寫(xiě)入到數(shù)據(jù)庫(kù)；對(duì)于在線部分，會(huì)對(duì)用戶的提問(wèn)進(jìn)行檢索預(yù)處理（意圖理解、查詢擴(kuò)展、領(lǐng)域適配、跨語(yǔ)言翻譯等）、檢索、重排、檢索后處理（結(jié)果裁剪與壓縮、信息匯總），最后通過(guò)提示詞工程調(diào)用 LLM。離線部分相當(dāng)于是數(shù)據(jù)庫(kù)的 ETL，主要涉及各種數(shù)據(jù)處理任務(wù)的調(diào)度和工作流，比較適合放到數(shù)據(jù)庫(kù)的外部，文檔或者分片入庫(kù)以及入庫(kù)之后的檢索涉及的主要操作是標(biāo)準(zhǔn)化的多?；旌纤阉鳎容^適合集成到數(shù)據(jù)庫(kù)內(nèi)部。

多維表格

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

Document In,Data Out

混合搜索的執(zhí)行過(guò)程同時(shí)涉及數(shù)據(jù)處理和模型調(diào)用，執(zhí)行過(guò)程中涉及的模型包括：

• Embedding 模型：MongoDB 收購(gòu)的 VoyageAI 號(hào)稱(chēng)能夠做到 embedding 模型的 SOTA，可惜是閉源的，而開(kāi)源模型比較推薦 qwen3-embedding，bge-m3，bge-large-zh-v1.5 等；

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

• Generate 模型：國(guó)外的推薦 gpt 等模型，國(guó)內(nèi)推薦 deepseek 和 qwen3 系列。

在數(shù)據(jù)庫(kù)內(nèi)部直接集成 embedding 模型有兩個(gè)好處：一是不再需要從數(shù)據(jù)庫(kù)拖數(shù)據(jù)出去調(diào)模型，簡(jiǎn)化業(yè)務(wù)實(shí)現(xiàn)；二是能夠確保文檔入庫(kù)和用戶查詢使用的 embedding 模型總是保持一致，不會(huì)出現(xiàn)二者不一致導(dǎo)致的搜索效果下降問(wèn)題。

“Document In,Data Out”能夠大幅簡(jiǎn)化 AI 應(yīng)用開(kāi)發(fā)。原先開(kāi)發(fā)一個(gè) RAG 應(yīng)用，需要選擇多個(gè)不同的數(shù)據(jù)庫(kù)（關(guān)系數(shù)據(jù)庫(kù)、向量數(shù)據(jù)庫(kù)、全文搜索數(shù)據(jù)庫(kù)等），再根據(jù)不同的場(chǎng)景選擇不同的模型，并在應(yīng)用層對(duì)這些數(shù)據(jù)庫(kù)和模型進(jìn)行組裝并調(diào)試效果。有了基于混合搜索的“Document In,Data Out”之后，只需要把文檔或者切片寫(xiě)入 AI 原生數(shù)據(jù)庫(kù)即可，AI 原生數(shù)據(jù)庫(kù)會(huì)自動(dòng)執(zhí)行多路搜索并選擇合適的模型。如果想要基于業(yè)務(wù)場(chǎng)景對(duì)模型做深度定制或者微調(diào)，也可以通過(guò)簡(jiǎn)單的數(shù)據(jù)庫(kù) DDL 操作來(lái)更換默認(rèn)模型。

AI Function

AI 原生數(shù)據(jù)庫(kù)內(nèi)置 AI Function，將這些 AI Function 融入到數(shù)據(jù)庫(kù)的執(zhí)行算子中。常見(jiàn)的 AI Function 包括：

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

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

• SQL 語(yǔ)義計(jì)算算子（AISQL）：包括語(yǔ)義過(guò)濾算子 ai_filter，語(yǔ)義連接算子 ai_join，語(yǔ)義聚合算子 ai_agg，文本摘要聚合算子 ai_summarize_agg 等。

通過(guò) AI Function，開(kāi)發(fā)者可以在一個(gè) SQL 查詢中完成以下任務(wù)：使用 ai_filter 過(guò)濾出客戶表達(dá)不滿意的工單記錄，使用 ai_join 將這些工單與產(chǎn)品目錄關(guān)聯(lián)，使用 ai_classify 對(duì)問(wèn)題嚴(yán)重性進(jìn)行分類(lèi)，并使用 ai_summarize_agg 按產(chǎn)品分類(lèi)生成聚合摘要。AI Function 使得對(duì)結(jié)構(gòu)化數(shù)據(jù)和無(wú)結(jié)構(gòu)化數(shù)據(jù)的混合分析成為可能。另外，在這種模式下，數(shù)據(jù)庫(kù)可以在底層系統(tǒng)對(duì) AI 調(diào)用進(jìn)行整體優(yōu)化，減少大模型調(diào)用所需的 token。

小結(jié)

AI 時(shí)代的數(shù)據(jù)庫(kù)用戶由原來(lái)的應(yīng)用 /APP 變成大模型生成的 AI Agent。為了支持 AI 場(chǎng)景，首先需要一個(gè)現(xiàn)代化的 AI Ready 數(shù)據(jù)架構(gòu)，這個(gè)架構(gòu)能夠支持 Serverless、彈性擴(kuò)展等能力。AI Ready 只是 AI 數(shù)據(jù)庫(kù)的起點(diǎn)，隨著 AI 應(yīng)用的逐步深入，會(huì)產(chǎn)生新的工作負(fù)載，即多?；旌纤阉?。數(shù)據(jù)和模型也會(huì)深度融合，通過(guò) AI Function 等技術(shù)在系統(tǒng)中直接處理無(wú)結(jié)構(gòu)化數(shù)據(jù)，成為 AI 原生數(shù)據(jù)庫(kù)。

為什么要做 AI 原生數(shù)據(jù)庫(kù) seekdb？

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

為什么要做 seekdb?

回到第一性原理，我認(rèn)為，傳統(tǒng)數(shù)據(jù)庫(kù)主要用來(lái)處理結(jié)構(gòu)化數(shù)據(jù)和半結(jié)構(gòu)化數(shù)據(jù)，而 AI 數(shù)據(jù)庫(kù)除了具備傳統(tǒng)數(shù)據(jù)庫(kù)的能力，還應(yīng)該能夠直接處理無(wú)結(jié)構(gòu)化數(shù)據(jù)，而多?；旌纤阉?/strong>是最終的方向。然而，現(xiàn)有的數(shù)據(jù)庫(kù)產(chǎn)品都無(wú)法很好地支持關(guān)系、JSON、向量和全文的多?；旌纤阉?，向量數(shù)據(jù)庫(kù)做不好全文搜索，全文數(shù)據(jù)庫(kù)做不好向量搜索，向量數(shù)據(jù)庫(kù)和全文數(shù)據(jù)庫(kù)都做不好關(guān)系查詢，也不能很好地支持輕量部署，等等。

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

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

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

那么，seekdb 和 OceanBase 的定位有何不同呢？首先，不管是 seekdb 還是 OceanBase 都是一個(gè)能夠支持 AI 場(chǎng)景的 AI 數(shù)據(jù)庫(kù)，不同點(diǎn)在于，seekdb 只支持單機(jī)（含單機(jī)主備）且專(zhuān)注做好 AI 原生功能，即關(guān)系、JSON、向量和全文的多?；旌纤阉?，而 OceanBase 具備完整的 OLTP、OLAP 和混合搜索能力，支持單機(jī)和分布式等全部部署模式。如果用在 AI 創(chuàng)新場(chǎng)景，數(shù)據(jù)量沒(méi)有那么大，或者想要部署在端側(cè)等資源受限場(chǎng)景，推薦 seekdb；如果想要完整的 OLTP、OLAP 和 AI 功能，或者想要商業(yè)服務(wù)，推薦 OceanBase。

seekdb 對(duì)開(kāi)發(fā)者意味著什么？

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

對(duì)于開(kāi)發(fā)者而言，seekdb 最重要的價(jià)值有兩個(gè)：一個(gè)是實(shí)現(xiàn)了多合一，簡(jiǎn)化應(yīng)用開(kāi)發(fā)，另外一個(gè)是相比原先的向量 / 全文數(shù)據(jù)庫(kù)更加輕量。全文和向量數(shù)據(jù)庫(kù)的最小規(guī)格需要 4GB 甚至 8GB 的內(nèi)存，而 seekdb 的第一個(gè)版本在實(shí)現(xiàn)多合一的前提下只需要 2GB 內(nèi)存，且后續(xù)還會(huì)進(jìn)一步優(yōu)化到 1GB 乃至 500MB。雖然部分向量數(shù)據(jù)庫(kù)單獨(dú)提供了輕量版，但功能往往較為簡(jiǎn)化，seekdb 在同等資源下支持的功能提供更強(qiáng)的能力，達(dá)到甚至超越業(yè)界已有的向量 / 全文數(shù)據(jù)庫(kù)。

在 OceanBase 2025 年度發(fā)布會(huì)，我們展示了 oceanbase.ai 上的一個(gè) demo，通過(guò)三行代碼構(gòu)建一個(gè) AI 知識(shí)庫(kù)。seekdb 在 SQL 的基礎(chǔ)上封裝了單獨(dú)的 Python SDK，同時(shí)支持了嵌入式的部署模式。在 AI 的世界里，Python，Javascript 等才是開(kāi)發(fā)者更加喜歡的語(yǔ)言。當(dāng)然，要構(gòu)建一個(gè)真實(shí)的 AI 應(yīng)用，三行代碼肯定是遠(yuǎn)遠(yuǎn)不夠的，但我們相信，一個(gè)更好的支持多模混合搜索的 SDK 一定能夠簡(jiǎn)化 AI 開(kāi)發(fā)。

開(kāi)源開(kāi)放

在 OceanBase 年度發(fā)布會(huì)現(xiàn)場(chǎng)我見(jiàn)到很多 seekdb 的開(kāi)發(fā)者，大家反饋了很多問(wèn)題，包括 seekdb 編譯很慢，seekdb 不支持 Mac，等等，其中有一位是 langchain 中國(guó)區(qū)的布道師，他基于 seekdb 開(kāi)發(fā)了一些混合搜索的 demo，但沒(méi)有辦法調(diào)出好的搜索效果。我認(rèn)為，全球化和開(kāi)源，以及社區(qū)合作是 AI 數(shù)據(jù)庫(kù)的基因。因此，我們這次把 seekdb 以及基于 seekdb 的 RAG 解決方案 PowerRAG 和 Mem 解決方案 PowerMem 都通過(guò) Apache 2.0 協(xié)議開(kāi)源。

通過(guò)和開(kāi)發(fā)者溝通，我們對(duì) seekdb 的定位越來(lái)越篤定，然而，目前我們發(fā)布的 seekdb 還只是第一個(gè)版本，雖然有 OceanBase 的 code base 作為基礎(chǔ)，但仍然存在不少的問(wèn)題，包括：

• seekdb 的使用姿勢(shì)不夠靈活。如果采用 seekdb 預(yù)設(shè)的使用姿勢(shì)，比如采用 docker 部署，會(huì)比較順暢，但如果想要自己編譯，或者在 Mac 上安裝，seekdb 要么很慢，要么還不支持。后續(xù)我們會(huì)優(yōu)先支持開(kāi)發(fā)者喜歡的 Mac 安裝。

• 文檔和易用性還有待加強(qiáng)。我們支持了混合搜索，但缺乏相關(guān)的文檔和最佳實(shí)踐讓開(kāi)發(fā)者能夠很簡(jiǎn)單地調(diào)出最好的效果；我們也缺乏一些如何使用 seekdb 開(kāi)發(fā)應(yīng)用的文檔和技術(shù)博客。

• 混合搜索的能力還有待提升。多?；旌纤阉魇俏覀兲岢龅囊豁?xiàng)全新的能力，我們目前只實(shí)現(xiàn)了基礎(chǔ)功能，OLTP 和向量搜索的性能較好，但全文搜索、混合搜索以及 JSON 搜索的性能還需要提升，我們的研發(fā)正在快速迭代中。

• seekdb 支持的客戶端還不夠豐富。目前只支持了最簡(jiǎn)單的 Python SDK，且只實(shí)現(xiàn)了有限的接口，后續(xù)需要豐富 Python SDK 并增加Javascript 等更多語(yǔ)言的支持。

• seekdb 還不夠小。我們推薦的配置為 2GB 內(nèi)存，后續(xù)會(huì)盡快優(yōu)化到 1GB。

• 開(kāi)發(fā)者貢獻(xiàn)內(nèi)核代碼還有不小的難度。seekdb 非常歡迎開(kāi)發(fā)者成為內(nèi)核代碼的 contributor，但目前代碼量較大，且代碼編譯需要的時(shí)間較長(zhǎng)。因此，推薦開(kāi)發(fā)者使用配置更好的服務(wù)器并行編譯，同時(shí)，我們后續(xù)也會(huì)撰寫(xiě)更多源碼解析相關(guān)的文檔。

seekdb 仍處于早期階段，但我們相信多模混合搜索是 AI 數(shù)據(jù)庫(kù)的未來(lái)，相信開(kāi)源和社區(qū)的力量——我們希望與 AI 開(kāi)發(fā)者一起，做好開(kāi)源與社區(qū)建設(shè)，把 seekdb 打造成 AI 開(kāi)發(fā)的主流選擇。

誠(chéng)邀開(kāi)發(fā)者和我們一起探索 AI 原生數(shù)據(jù)庫(kù)：

https://github.com/oceanbase/seekdb