最近和不少國產(chǎn)數(shù)據(jù)庫廠商都探討過DB4AI的問題，前陣子我還梳理了最近一年里Oracle在DB4AI上的發(fā)展路徑，從中體會(huì)DB4AI在傳統(tǒng)關(guān)系型數(shù)據(jù)庫上的發(fā)展路徑。

圖片

Oracle的23AI是從23C改名而來的，這說明Oracle剛開始的時(shí)候?qū)τ贏I的爆發(fā)點(diǎn)也是準(zhǔn)備不足的，在融合數(shù)據(jù)庫剛剛起步的時(shí)候匆匆忙忙轉(zhuǎn)向了AI方向。幸運(yùn)的是，融合和AI的大方向是一致的，所以并沒有走什么彎路。

和絕大多數(shù)其他關(guān)系型數(shù)據(jù)庫類似，Oracle的DB4AI起點(diǎn)也是向量類型的支持，O記采用了先集成數(shù)據(jù)庫的AI應(yīng)用支持能力，再根據(jù)用戶的需求完善相關(guān)能力的發(fā)展模式，通過大量UTL*工具為AI應(yīng)用開發(fā)提供所需的能力。在最新的版本中，O記已經(jīng)發(fā)展到為大規(guī)模 AI應(yīng)用提供強(qiáng)大能力支持支撐的階段，IVF索引在線重定義（解決大量UPDATE后IVF索引失效的問題），外部表支持（降低AI數(shù)據(jù)導(dǎo)入的復(fù)雜性），VECTOR_MEMORY_SIZE（自動(dòng)優(yōu)化性能），HNSW圖的快照更新（針對(duì)修改量極大的表數(shù)據(jù)的HNSW索引的性能優(yōu)化），JSON能力的融合（更方便地構(gòu)建應(yīng)用），向量索引中的覆蓋字段（提高應(yīng)用性能）等都是為了解決AI應(yīng)用開發(fā)中的 難點(diǎn)和痛點(diǎn)的。

我也在感嘆，在DB4AI這條路上，O記又在孤身挺近，也真心希望國產(chǎn)數(shù)據(jù)庫也能盡快趕上來。前幾天VexDB發(fā)布會(huì)，讓我看到了一抹亮色，讓我感受到了國產(chǎn)數(shù)據(jù)庫追趕先進(jìn)技術(shù)的身影。

在發(fā)布會(huì)上，國良老師作為數(shù)智引航的技術(shù)顧問，代表技術(shù)團(tuán)隊(duì)發(fā)布一款為AI而生的向量數(shù)據(jù)庫產(chǎn)品——VexDB。我這兩天也花了點(diǎn)時(shí)間研究了一下這個(gè)數(shù)據(jù)庫，雖然還沒有親力親為去使用VexDB做些小項(xiàng)目來進(jìn)行驗(yàn)證，不過在探索VexDB的時(shí)候我收獲了一絲驚喜。與國內(nèi)的其他DB4AI產(chǎn)品相比，它在技術(shù)理念上有較大的差異，VexDB的產(chǎn)品定位和技術(shù)路線與O記十分相像，而我個(gè)人覺得目前O記的路線應(yīng)該是比較合理的。

DB4AI的起點(diǎn)必然是關(guān)系型數(shù)據(jù)庫中的向量支持或者向量數(shù)據(jù)庫中的OLTP支持，純粹的向量數(shù)據(jù)庫的應(yīng)用場(chǎng)景會(huì)受到很大的限制。雖然DB4AI應(yīng)該從向量入手，但是不能像目前的絕大多數(shù)DB4AI功能那樣圍繞向量來做，而是應(yīng)該圍繞AI應(yīng)用的實(shí)際需求來設(shè)計(jì)。下面我們來看看VexDB在DB4AI方向上的一些值得稱道的點(diǎn)。

首先VexDB在初期版本就構(gòu)建了完善的應(yīng)用生態(tài)，在組件編排上支持了目前最為流行的AI應(yīng)用框架，包括LangChain、Dify、MaxKB、RagFlow、OpenWebUI等。目前大量的AI應(yīng)用都采用了這些框架，因此VexDB很容易將這些框架上開發(fā)的AI應(yīng)用從其他專用向量數(shù)據(jù)庫中平移過來，這為VexDB快速發(fā)展提供了有力的支撐。O記在23AI的第一個(gè)版本中也通過與CoHere等的集成打通了數(shù)據(jù)庫與AI應(yīng)用之間的管道。

既然DB4AI是為AI應(yīng)用而生的，那么數(shù)據(jù)庫廠商就需要了解目前用戶都在開發(fā)什么樣的應(yīng)用。其實(shí)很多企業(yè)的第一個(gè)AI應(yīng)用大多收都是知識(shí)庫、知識(shí)問答之類的系統(tǒng)。圍繞向量數(shù)據(jù)類型來提供知識(shí)庫開發(fā)能力是向量數(shù)據(jù)庫必須具備的能力，不過想要做好這一點(diǎn)并不容易。目前絕大多數(shù)國產(chǎn)數(shù)據(jù)庫具有的向量數(shù)據(jù)庫支持不外乎向量標(biāo)量混合檢索的能力。似乎大家努力方向都差不多，不過如果仔細(xì)看看內(nèi)部細(xì)節(jié)，卻差別很大。

VexDB在這個(gè)方向上做了一些微創(chuàng)新，比如在向量索引上，VexDB 支持多種基于磁盤的向量索引結(jié)構(gòu)，提供了IVFFLAT/IVFPQ/Graph_index/DiskANN索引，其中后三種索引是目前絕大多數(shù)國產(chǎn)數(shù)據(jù)庫沒有涉及的。與傳統(tǒng)的索引不同，向量索引不僅僅是提高檢索速度的需要，更能夠提高向量檢索的能力，支持的索引種類越多，就能支持更多的應(yīng)用場(chǎng)景。

除了向量索引之外，VexDB在索引上還有很多令人驚喜的能力，比如向標(biāo)聯(lián)合索引HybridANN，Oracle在23.6上開始支持向標(biāo)混合索引，當(dāng)時(shí)我看到這個(gè)功能后感覺到這是一個(gè)可以大大簡(jiǎn)化知識(shí)庫多路召回效率的功能，沒想到VexDB現(xiàn)在也提供了類似的解決方案。傳統(tǒng)的向量檢索的召回準(zhǔn)確性不足的問題，其實(shí)是完全可以通過向標(biāo)混合檢索來解決的，不過如果沒有向標(biāo)混合索引的支持，這種檢索就會(huì)被割裂為向量檢索、標(biāo)量檢索和重排三個(gè)工作，把提升準(zhǔn)確性的工作交給了應(yīng)用開發(fā)人員去做，大大增加了知識(shí)庫開發(fā)的難度。

VexDB在索引上的工作還不僅如此，BM25索引的支持讓我感到很貼心，最近我們有一個(gè)項(xiàng)目想通過BM25來提高知識(shí)召回的準(zhǔn)確性，BM25（Best Matching 25）是一種廣泛應(yīng)用于信息檢索領(lǐng)域的概率相關(guān)性模型，用于衡量查詢與文檔之間的匹配程度，正好是對(duì)癥下藥的，但是目前我們使用的數(shù)據(jù)庫中沒有BM25索引的支持，所以做起來很糾結(jié)。

初步研究了一下VexDB的功能，從一些設(shè)計(jì)上可以看出，產(chǎn)品的研發(fā)人員是懂AI應(yīng)用的，并沒有閉門造車，而是真正在做一些幫助AI應(yīng)用開發(fā)者解決一些現(xiàn)實(shí)問題的事情。我覺得在DB4AI的道路上，VexDB走出的第一步似乎是對(duì)的。