説明：

1. 本文只是關於數據庫發展趨勢的個人見解，沒有特別深入的向量和混合檢索的實現原理，屬於很淺顯易懂的科普類文章，幾乎不需要任何背景知識，大家可以放心閲讀。
2. 關於混合檢索的原理和最佳實踐類文章，有緣再更，歡迎感興趣的朋友們關注【老紀的技術嘮嗑局】微信公眾號。

背景

數據的分類

我一般會把數據庫中的數據類型，簡單分為三類：

1. 結構化數據：我們可以把傳統數據庫的基礎數據類型，都看成結構化數據，每個數據可以堪稱一個 “原子” 數據，例如 int、double、char、varchar。
2. 半結構化數據：就是 Json / GIS / XML 這些。一個半結構化對象嵌套組織了很多基礎數據類（半結構化數據類似一個 “分子”，是由一些 “原子” 以及相應的 “鏈接結構” 嵌套組成），我們稱之為半結構化數據。
3. 非結構化數據：簡單説就是 “圖、文、音、視” 這類東西。這些數據有一個特點 —— 大，這個特點導致這類數據的排序沒啥意義，也沒法兒做計算。

數據庫的能力邊界：

• 關係型數據庫能處理好結構化數據，因為對結構化數據進行數據壓縮存儲非常容易（比如除了通用的壓縮算法，還可以基於每一個類型數據的特徵，可針對性地進行多種編碼壓縮），以及很好的做數據計算，比如做一些基礎的比較、排序、聚合、掃描、表達式計算等。
• 半結構化數據，在實際應用中一直是基於專用數據庫，大部分也是存儲在 NoSQL 數據庫中。例如，Mongo 的基本組成是 Document，Redis 有各種各樣的複雜數據結構 List / Hash / Set 等等，GIS 一般會使用 PostGis 等專用數據庫。

其實，關係數據庫也能比較好處理半結構化數據，比如 Json，可以基於 Path 來訪問具體的數據，Json Path 就有點類似於我們關係數據表的列的概念。而且，半結構化數據，是可以拆解成結構化數據的，基於關係數據庫的能力，我們是可以對半結構化數據做存儲和計算的。

除了上面提到的結構化數據和半結構化數據，還有一類，叫做 “非結構化數據”：

• 非結構化數據在 AI 時代來臨之前，對於數據庫而言，只能存儲，不能計算。對於存儲來説，非結構化數據很大，基本上都需要用大對象進行存儲（例如 blob），在存儲上，相比其他類型，也是不優的（而且很貴）。
• 非結構化數據在現實世界，絕大部分是存儲在本地文件系統，例如：對象存儲，塊存儲。這些存儲一個典型的特點就是便宜。
• 通用意義上的非結構化數據，目前只有向量數據庫能夠通用處理。如果單獨把文本拎出來，除了向量，還可以進行全文文本處理。關於全文檢索的更多內容，詳見：《全文索引能力簡介》。

AI 時代，數據庫發生了什麼變化？

在現實世界中，非結構化數據佔比 80% 以上。但這些數據，絕大多數都只是存儲，沒有計算。

而在 AI 時代，數據只有能被計算，才能產生價值。

大模型

GenAI 帶來了通用大模型。

在數據處理上，總結下來，大模型有兩類能力：

1. 直接處理非結構化數據。比如，輸入一個文本，讓大模型對文本進行總結。
2. 提取非結構化數據的結構化特徵，然後存儲在關係數據庫中做計算。舉個例子，一張圖片，我通過提示詞，讓大模型提取這張圖片的 tag，比如提取 “穿裙子”、“長髮”、“女士”、“湖邊” 等等。提取了 tag 之後，數據庫就可以做分析計算了。

在 GenAI 時代之前，非結構化數據是不是能被處理？其實也是可以的，只不過非常 “複雜”，需要進行 “定製”。

之前核心技術就是機器學習，在 GenAI 時代，這種技術門檻更低、更通用，也更便宜。

嵌入模型

大模型的維度都是以 B（Billon）為單位，嵌入模型一般都在 1K 維左右。

嵌入模型能捕獲非結構化數據的 “隱形” 特徵，然後將這些特性用高緯向量來表示，通過計算 2 個高緯向量的距離（比如 Cosin / IP 距離）等，來近似代替 2 個非結構化數據的相似度。相關內容詳見：《淺入瞭解向量數據庫》。

向量其實是一個半結構化數據（前面講過，數據庫只能高效處理結構化 / 半結構化數據），比如一個 1024 維度的向量，其實是一個 1024 個元素的 Array，每個 Array 都是一個 Float 類型。

在傳統數據庫中，非結構化數據是不可比較的，比如 2 張照片通過二進制比較完全沒有意義。通過嵌入模型，2 個非結構化數據，就可以比較了（不過傳統關係數據庫的大小比較有些不同，這裏是 “相似度” 比較），也就是這個 “可以比較了”，打開了非結構化處理的大門。

説明：

傳統的關係數據庫，最基礎的數據處理其實也是比較，排序、過濾，甚至於掃描，都是基於比較的能力。

下圖是個很常見的二維空間的例子。財富和相貌，是向量的 2 個維度。向量的每一個維度，就是非結構化數據 “隱形” 的一個特徵。可以看到，在空間座標系裏，距離越近的 2 種生物，就越相似（這個也是最簡單向量數據庫的原理）。

有了大模型，為什麼還需要向量數據庫？

大家可以用反證法，先想象一下，在 AI 時代，如果只有大模型而沒有向量數據庫，會出現什麼樣的場景？

拿以圖搜圖為例

假設我有 100w 張圖片，每次找相似的圖片的時候，都繞過向量數據庫，直接透傳給大模型來處理。然後你就會發現：大模型超級慢，即使是不帶推理的 Deepseek R1，也只能秒級出結果。（傳統關係數據庫的數據處理可是毫秒級，直接相差了 3 個數量級）。所以，在整個 AI 應用的數據鏈中，向量數據庫不是瓶頸，大模型才是。

• 大模型：哪怕是 10 億參數的輕量模型，每生成一個 token（單詞/字）都要遍歷全部參數做矩陣運算，生成一段話要重複幾十次這種運算——相當於“僱 10 億個會計，每人算一步，才能得出一個句子”，硬件和算法優化空間遠小於數據檢索。
• 向量數據庫：哪怕處理 10 億級向量，通過數據庫中最常見的 “索引 + 並行”，能把檢索延遲壓到百毫秒內。

所以，大模型不適合大量的數據實時處理，向量數據庫更合適。在處理海量數據的時候，正常思路只能是：向量數據庫做初篩，大模型做總結 / 二次加工。

拿知識庫為例

大模型有幻覺，這個是大家公認的。大模型可以回答很多，但是有可能很多是“胡説八道”。主要原因是大模型的知識是靠訓練數據集來的，但是很多企業內的數據是不公開的。

大模型處理數據的上下文是有 “窗口大小” 的，比如 GPT-4 是 8K。一方面沒有辦法一下子給大模型塞整個企業的數據進去處理，另外大模型在處理特定問題的時候，也需要更加 “專注”，也就是説：少量非常相關的信息就可以了，不需要大量無關的信息。

在這個過程中，就不得不請出向量數據庫，讓它用最快的速度，過濾出和用户問題最相近的知識，然後交給大模型做總結。

總結

綜上，AI 時代最常見的一個需求就是海量非結構化數據的近實時檢索，現在，只有向量數據庫能幹。一般的 AI 解決方案，就是 “向量數據庫 + 大模型” 相互配合，向量數據庫的 “近實時檢索” + 大模型的 “通用智能”。

所以毋庸置疑，向量數據庫這個玩意兒，已經是 AI 時代數據庫進化路線的重要一環。

最近一段時間，除了專業向量數據庫，其他關係型數據庫、noSQL 數據庫、各種搜索引擎，也都開始逐步支持向量存儲和檢索的能力。

目前，不同數據庫的向量能力演進路線可能會略有不同。但在不久的未來，大概率會殊途同歸，即：向量（vector）會成為數據庫中，和數字類型（number）、字符串類型（string）一樣的基礎數據類型。

這裏多解釋一句，上圖中把向量索引單獨從普通二級索引中抽離出來，主要是因為向量類型的檢索開銷較大，而且檢索結果只要求近似而非絕對，所以會有一種獨特的索引形式 —— 向量索引。

同理，全文索引、空間索引等，大致也是類似的原因。

什麼是混合檢索？

最近一段時間，數據庫行業裏的很多公司和大佬，都在紛紛發佈一些混合檢索的原理和實踐類文章。Why？因為支持混合檢索的數據庫已經逐步成為了 AI 時代的剛需。

1. 在生產環境中使用數據庫，往往都會考慮權限問題。權限問題主要的解法，就是把文檔表、員工權限表以及各種各樣的表去做 Join。我目前幾乎沒有看到過有用户和業務使用很 “純粹” 的向量檢索，一般都會有標量 & 向量混合檢索。這個標量，靠的就是傳統數據庫的檢索能力。
2. 為了讓檢索更準確，對於 RAG 方案，目前業界比較共識的方案是：全文 + 向量混合檢索。未來，沒有全文檢索能力的數據庫廠商，很難滿足 RAG 方面的需求。
3. 其他類似於 GraphRag 的方案，在學術界以及工業界也比較活躍。所以，向量 + 圖混合檢索的需求，也變的越來越常見。

那什麼是混合檢索？與其給出定義，不如直接舉個例子來的方便。

比如基於螞蟻百寶箱搭建的一個餐飲推薦 AI Agent 系統，會把用户的自然語言提問，轉換成對知識庫的搜索。

在上圖的這個提問中：

• 距離五百米以內，是基於空間位置（GIS）的查詢。
• 人均消費 25 元，評價 4.5 分以上，是基於傳統標量的查詢。
• 不用排隊，是基於用户對店鋪的評價，基於向量的語意檢索。

混合檢索 —— AI 應用的發動機

AI 應用，強依賴知識庫

上圖是某知名保險行業 ISV 的智能體整體架構圖。

各個 Level 的依賴可以簡化如下：

絕大多數 AI 應用的架構都可以簡化為上述架構圖，例如：通用的知識庫平台（各類問答助手）、智能體推薦系統（飛豬的旅遊推薦）、類似於 Cursor 的智能編碼助手、行業 AI 助手（數據庫運維監控智能體）……

接下來，再針對上面這張圖多説兩句：

• 智能體的效果依託於 “知識庫”、“模型”、“業務邏輯”。在特定的智能體應用中，業務邏輯是固定的，模型只能在通用的模型矩陣中做選擇，知識庫成為智能體效果的重中之重。
• 知識庫的效果依賴很多方面：
  • 數據是否高質量，數據的清洗、打標、提取的程度，好的數據是好的效果的開端。
  • 查詢語句是否高質量，查詢語句是否經過充分的改寫（比如改錯別字 / 近義詞替換），擴寫（多維度問問題），語義/上下文填充。
  • 數據檢索是否準確，在業界已經形成了共識，即混合多種檢索方式（向量檢索、關鍵詞檢索等）是提升最終效果行之有效的方式。
  • 數據檢索是否高效，多種檢索方式的引入，會引入更大量的計算，如何在保證準確的情況下更快給應用返回，縮短檢索時延也是應用體驗的重要一環。

基於上述討論，我們可以基本達成一個共識，就是：知識庫是影響 AI 應用效果非常重要的一環，而知識庫的效果，強依賴於數據檢索的質量和效率。所以，對於 AI 時代的數據庫來説，就必須要為用户提供 —— 準確 & 高效的實時混合檢索以及數據處理能力。

知識庫，強依賴混合檢索

知識庫（RAG，檢索增強生成）的最終目標還是模型生成的效果，各個語言大模型類請求上下文窗口一般在 128K 以下，而且餵給模型的請求包含很多信息，比如提示詞、記憶、從知識庫中檢索的信息。

大模型擁有比較強大的泛化能力，但是最終效果還是需要依賴整個請求中的上下文信息。理想情況下，我們希望把更多的信息塞給大模型（如果可以的話，最好能直接整個知識庫都填鴨式地塞給大模型），這樣能取得最好的效果。

但是實際情況是，大模型的上下文窗口比較小，而且塞的越滿，模型效果就可能越差。受限於大模型的上下文窗口大小，每個 token 都珍貴，最終塞給大模型的數據要儘量有相關性、精煉、準確。

下面是 Chroma 的創始人 Jeff Huber 在分享 Context Engineering 的概念時，報告裏的一張折線圖。可以很直觀地看出，隨着上下文長度不斷增加，模型的效果會有明顯的衰減。

雖然最近 DeepSeek-OCR 模型重新定義了 AI 的輸入和輸出（從文本到像素），能夠在一定程度上對數據進行壓縮（詳見：《用最純粹的語言，解析 DeepSeek OCR》）。然而，知識庫一般都非常龐大，如何高效地從一個超大數據集找到大模型強依賴的信息，依然尤為重要。

如上圖，從全量數據到模型窗口之間，形成了一個大漏斗。這裏有幾個概念需要再多解釋一下：

• 圈數據：基於用户明確的要求（“比如人均消費 25 元，評價 4.5 分以上，距離我 500 米以內”），把不滿足要求的數據快速篩掉，這部分強依賴傳統關係型數據庫的基礎能力。
• 粗排：在得到滿足基本要求的數據集後，需要基於和查詢請求的相關性，對候選數據集做排序。這部分重點在通過數據庫的手段來找到最相關的數據，使用數據庫的非常重要的原因是快，基本能夠保證百毫秒內的時延，這個特點對於在線查詢非常重要。
• 精排：粗排階段的快，犧牲了一定的準確度（比如向量這一路，因為是雙塔模型，請求和候選數據集之間的相關性不夠強。 全文這一路，依賴的是關鍵字的匹配，語義相關性弱），粗排的思路是快速召回一堆結果，認為需要的結果大概率就在這一堆數據裏面。在對精度要求比較高的場景，往往需要一些重排模型，來交叉獲取查詢請求和數據之間的深層次關係，從而對數據集做更精準的定序。以 Reranker 模型為例，需要對每個 “查詢 - 文檔” 對進行實時推理，這會顯著增加系統的響應時間（從毫秒級可能升至幾百毫秒甚至秒級）和每次查詢的計算成本，所以依賴待精排的數據量進一步的小。

圈數據

圈數據很重要，很多數據庫都會支持，比如 ES / Mongo / 關係數據庫，每種數據庫適用的場景也不盡相同。

對於 ES 等 NoSQL 數據庫，一般只支持單表操作，設計上往往是反範式，會把一個業務場景的所有數據字段都放到一張表中，經常會形成一張大寬表。

對於一些依賴範式的 “一對多” 的能力，比如一個人有多個電話號碼，ES 往往使用嵌套結構來實現。但是反範式的大寬表 + 嵌套結構的方式，往往會帶來更新代價大，數據一致性等問題。所以一般是在一致性 / 實時性要求不高的邊緣系統中出現，核心系統一般還是會選擇關係型數據庫。

關係型數據庫基於關係範式，一個業務場景，往往會有多張表，每張表各司其職，多張表間有外鍵等關聯。關係數據庫優化器比較重要的能力是在各張表中選代價最低的索引以及在多張表間選擇最優的 Join 順序以及算法，整體擴展性和靈活性更好。

粗排

單一的粗排手段，往往有很多不容易被覆蓋到的場景。比如召回一堆基於模版生成的數據，使用單一向量數據庫不能很好的區分；比如需要召回多語言、有同義 / 近義語意的數據，只是基於關鍵字的搜索引擎也不能很好地解決。所以在實際工程中，往往會把多種召回方式（稠密向量、稀疏向量、搜索引擎、圖等）混合使用。

基於多路檢索的粗排，會帶來如下幾個問題：

• 粗排精度問題：排序最終是對數據行做排序，排序分數一般是基於數據行中各個算分列的分數之和，可以看作是全局排序。“煙囱” 式的多路檢索，一般是每一路取 TopK，然後再做融合（多路歸併），可以看作是每一路單獨局部排序再融合，相比全局排序，會損失精度，大大影響 AI 應用的效果。
• 易用性問題：需要 AI 應用自己處理多路檢索以及結果的融合，整個流程比較繁瑣。
• 一致性問題：如果是多個數據庫承載多路檢索，多個系統之間數據的一致性就需要進行額外處理。
• 效率 & 成本問題：多路檢索，需要維護多份數據，多份數據獨立檢索，消耗的計算資源也是成倍增加。

因此，混合檢索在粗排階段的優勢也非常明顯。也就是説，如果一款數據庫可以支持多模數據類型，那就可以基於同一份數據，同時支持向量、全文等排序方式，並且是將多路檢索融合到一個算分排序框架中，在給粗排帶來更高精度的同時，也避免了數據一致性 / 成本 / 易用性等問題。

精排

在多路檢索中涉及到向量以及重排（精篩）時，因為向量依賴嵌入模型，精篩依賴重排模型，而目前的向量 / 關係數據庫都不支持在 DB 內調用模型，所以會導致整個流程十分複雜，涉及到應用和 DB 的多次交互。如下圖所示：

因此，未來數據庫的混搜框架中，需要內置 AI Function 的能力，支持嵌入模型、重排模型、大模型的調用。

無論是數據寫入觸發的索引構建流程中的向量 Embedding 生成，還是查詢時候查詢語句的向量 Embedding生成，都應該讓數據庫自動觸發。在集成 Embedding 的 AI Function 能力後，用户可以不感知向量的存在，向量隱藏在數據庫自身的索引表中。

數據庫需要集成 Embedding 的原因是：

• 嵌入模型同時要被應用於查詢以及待檢索的數據集，如果這兩者用的模型類型 / 版本不一致，會導致向量檢索空間不一致，召回的數據就會有問題。數據庫系統往往都抱着事不關己高高掛起的態度，把這個問題拋給用户來保證，雖説這種做法也理所應當，但如果 Embedding 能被數據庫託管，模型信息成為數據的元數據，元數據版本被數據庫管理，數據一致性就能在內部得到更好的保障。
• 模型發展很快，當在做模型嘗試或者更強能力的新模型發佈的時候，經常會有換模型的訴求。之前的解決方案，都需要用户刪掉所有的舊向量，掃描存儲在數據庫中的 Chunk，生成新向量，插入數據庫，整個流程非常繁瑣，而且新舊索引的交替，也會影響業務的使用。現在 Embedding 被數據庫託管，換模型就是一個 Rebuild Index 的 DDL 命令，向量索引切換以及舊索引的回收，數據庫都會內部包掉，對業務無感知，最重要的是整個過程幾乎不影響業務的訪問。

除此以外，用户還可以考慮顯示調用 Rerank 模型的能力，在粗排之後，調用 Reranker 的 AI Function 即可。

至此，正文結束。這篇文章沒有涉及過多的混合檢索底層實現原理和使用上的最佳實踐，後面再繼續更新吧。

對混合檢索實現原理感興趣的老師們，歡迎繼續觀看下面這個視頻（如果能點贊、收藏、留言就更好了）。

最後，這篇文章可能會有很多疏漏以及表述不當的地方，希望各位老師多多在留言區批評和指導。

接下來，就是大家期待已久的廣告時間了~

Commercial Break

0x00. OceanBase 在混合檢索方面的表現

因為在最前面説了在正文部分不會包含和數據庫廠商相關的內容，所以數據庫廠商在混合檢索方面的能力、性能對比，就不得已放到了最後的這個 “廣告時間” 中。

粗排階段

• OceanBase 支持多模數據類型，基於同一份數據，同時支持向量、全文等排序方式，並且是將多路檢索融合到一個算分排序框架中，在給粗排帶來更高精度的同時，也避免了數據一致性 / 成本 / 易用性的問題。
• OceanBase 的粗排能力在性能上，一直在向業界最優秀的幾款有相關能力的數據庫產品看齊（這裏不多評判各類數據庫產品，性能數據參考下圖）。

• 在相關功能上：
  • OceanBase 的向量能力，目前也可以對標目前最流行的向量數據庫前輩 Milvus 的各種算法和功能。
  • OceanBase 在全文上支持 RAG 場景下對 BM25、Multi Match、稀疏減枝算法、RankFeature 等功能，知識庫場景基本上可以平替另一位老前輩 ElasticSearch。

精排階段

OceanBase 內置了 AI Function 的能力，支持嵌入模型、重排模型、大模型的調用。

目前 OceanBase 已經把 AI Function 的能力融入到整個混搜的框架中。

整個混合檢索過程中的圈數、粗排、精排，都可以完全融入到 OceanBase內核，用户可以直接向 OceanBase 中插入文本 Chunk，查詢的時候直接使用原始自然語言字符串做查詢，實現真正意義上的 Data In，Data Out，讓整個 AI 多路檢索更加簡單和高效。

0x01. OceanBase 4.4.1 CE 正式發佈！

OceanBase 4.4.1 社區版已經在 10 月 24 日正式發佈，混合檢索的能力得到了進一步的提升，歡迎大家來下載和試用。

以下內容摘自 OceanBase V4.4.1 CE 版本的 release notes^[1]：

• V4.4.1 版本對向量檢索能力進行了升級，支持 Hybrid Search 混合檢索，提升召回效果。
• 新增 AI function 能力，支持 SQL 訪問大模型。
• 此外通過適配 ARM 架構、無主鍵表優化、IVF 索引優化等手段進一步提高向量檢索的性能。
• 新增視圖展示向量索引內存佔用和異步任務狀態，提升易用性。
• ……

文檔詳見：OceanBase 官方文檔《向量索引混合檢索》^[2]。

下載地址：OceanBase 軟件下載中心^[3]。

0x10. AI Native 數據庫產品即將發佈！！

To be continue.（這款產品會在 OceanBase 2025 年度發佈會^[4]上的 “開源之夜” 環節中正式亮相，歡迎大家關注）

參考資料

[1]

OceanBase V4.4.1 CE 版本的 release notes: https://www.oceanbase.com/product/oceanbase-database-community-rn/releaseNote_#V4__.4.1_

[2]

OceanBase 官方文檔《向量索引混合檢索》: https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000004020382_#3__-title-%E6%99%AE%E9%80%9A%E6%A0%87%E9%87%8F%E6%A3%80%E7%B4%A2_

[3]

OceanBase 軟件下載中心: https://www.oceanbase.com/softwarecenter

[4]

OceanBase 2025 年度發佈會: https://www.oceanbase.com/conference2025