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

圖片

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

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

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

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

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

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

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

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

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

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

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