大模型再強也白搭，企業 AI 最后卡在數據底座上

大家好，我是 Ai 學習的老章

眾所周知，我本職工作是在公司做 AI 基建，所以大家會看到我寫過很多算力、推理引擎、模型部署和評測相關的內容

剛看了 OceanBase AI 數據庫的線上發布會，看過之后收獲很大，回答了我的一個疑惑：當數據庫的主要使用者慢慢從人變成 Agent，企業的數據底座到底該往哪兒長？

我現在越來越認同一個判斷

企業 AI 往前走，卡點已經越來越少出在模型本身，更多會落到數據這一層

上下文夠不夠完整，非結構化數據能不能進治理，搜索結果準不準，Agent 試錯會不會污染生產環境，這些問題如果壓不住，AI 應用就很難真正跑進核心業務

過去我們聊數據庫，最常說的是高并發、事務、容災、成本、性能

到了 Agent 時代，問題突然多了幾層：

• Agent 要理解業務上下文

• Agent 要處理文檔、圖片、語音、視頻這些多模態數據

• Agent 要隨時調用實時業務數據

• Agent 會試錯，會改數據，會搞壞環境

• Agent 數量可能會從幾十個擴到幾百萬、幾千萬個輕應用和小任務

這時候，數據庫如果還只是人類點開后臺查表的地方，就不太夠了

OceanBase 這次給出的主口徑是：

OceanBase AI 數據庫 = 湖庫一體 · 多模態 · AI 原生

OceanBase 想做的，是給企業 Agent 準備一套真正能進生產的數據底座

OceanBase 對 AI 數據庫的定義，核心落在四個詞上：一體化、多模態、Agent 友好、開放

OceanBase AI 數據庫四個關鍵詞 為什么企業 AI 最后會卡在數據上

過去三年，企業 AI 的預算大多花在模型和算力上

買模型、接 API、建知識庫、做智能客服、上 Copilot，這些都很熱鬧

但真正跑進業務流程之后，很多項目會發現一個很尷尬的問題：

大模型越來越強，業務價值卻經?？ㄔ跀祿?/p>

因為大模型本身解決的是通用智能問題，企業要的是業務智能問題

通用智能會說話、會推理、會生成

業務智能還要知道：

• 這個客戶是誰

• 這筆訂單到哪一步了

• 這份合同有沒有風險條款

• 這個規則現在還生不生效

• 這個用戶過去幾次交互留下了什么狀態

• 這次操作能不能寫回生產系統

這些答案都在企業數據里

所以 OceanBase 這次反復強調一個變化：數據庫的使用者正在從人變成 Agent

人用數據庫的時候，大多是明確查詢

查一條訂單
看一張報表
篩一批異常記錄

Agent 用數據庫的時候，動作要復雜得多

先理解上下文
再混合檢索
再調用工具
再寫入狀態
再根據結果繼續下一步
失敗之后還要回滾
成功之后還要沉淀經驗

這就把數據庫從后臺系統，推到了 Agent 工作流的正中央

OceanBase 這次真正想解決的三個問題

第一，企業的數據形態已經變了

過去數據庫主要管結構化數據，表、行、列、字段

現在 Agent 要吃的上下文里，有合同 PDF、客服錄音、會議紀要、體檢報告、商品圖片、行車視頻、風控規則、知識庫片段、對話記憶、向量、JSON

這些東西如果還散落在對象存儲、文件系統、搜索引擎、向量庫、業務庫之間，Agent 每做一步都要跨系統拼上下文

拼一次，就多一次延遲

搬一次，就多一份冗余

同步一次，就多一個一致性風險

第二，企業的數據流動方式也變了

傳統鏈路經常長這樣：

交易庫 → ETL → 數倉 / 數據湖 → 搜索引擎 / 向量庫 → RAG / Agent

這條鏈路能跑，但它很慢，也很重

Agent 產生 bad case、用戶反饋、執行軌跡之后，如果要等幾天才被離線分析挖出來，再回到線上驗證，這個飛輪就轉不快

OceanBase 的說法是數據飛輪：Agent 產生數據，數據回流優化模型和知識，優化后的能力再服務業務

飛輪轉得快，AI 才會越用越準

第三，Agent 會帶來新的風險

人改生產數據之前會猶豫，Agent 很可能直接開干

尤其在企業里，Agent 會越來越多地執行生產任務，寫數據、改流程、調工具、做評測

這時候數據庫要給它準備安全邊界

它可以試錯，但不能污染生產

它可以并行，但不能互相踩腳

它可以失敗，但失敗之后要能快速丟棄、回滾、重來

這也是我覺得 OceanBase 這次最值得關注的地方：它把多模態、混合搜索、數據沙箱、海量邏輯表、開放計算放進一套架構里一起回答，避免把 AI 數據庫收窄成向量檢索

Lakebase：把湖和庫放到同一張底座上

OceanBase Lakebase 是這次發布里的核心引擎

它面向湖庫一體、多模態數據和 Agent 場景，目標是用一套底座統一管理結構化、半結構化、非結構化數據，同時承載 TP、AP 和 AI 工作負載

這句話聽起來有點大，我理解：

企業不想再為了一個 AI 應用，同時維護交易庫、數倉、對象存儲、搜索引擎、向量庫、權限系統、ETL 鏈路、RAG 服務一堆東西

Lakebase 要做的，是把關鍵數據底座和核心治理能力收斂起來

SQL 繼續處理在線事務和查詢

Spark 繼續做批量加工

Ray / Daft 繼續跑 AI 數據鏈路

對象存儲、S3 兼容接口、Iceberg 開放表格式繼續接入現有生態

這條路線我覺得比較現實

企業的數據平臺不會一夜重建

真正可落地的路徑，通常是先減少系統接縫、減少數據搬運、減少權限割裂，再慢慢把高價值場景收斂到統一底座上

多模態數據管理：讓非結構化數據有正式身份

這次我最感覺最神奇的一個設計，是多模表和 AI 列

過去企業里的非結構化數據，很多時候只是附件

合同 PDF 放對象存儲

圖片視頻放文件系統

文本摘要寫業務庫

向量塞進向量庫

權限再單獨做一套

業務上明明是同一個對象，技術上被拆成好幾份

Agent 要理解它，就得從多個系統里把這些碎片拼回來

OceanBase 的多模表想解決這個問題

一張表里可以同時放結構化字段、文本、圖片、音頻、視頻、JSON、LOB、向量

比如一張合同表，可以同時包含：

合同編號
合同 PDF
合同正文
關鍵條款 JSON
摘要向量
風險標簽
審批狀態
權限信息

用戶看到的還是一張表，但這張表背后，非結構化數據已經進入同一套事務、權限、元數據、版本和生命周期管理，因為企業 AI 不缺文件，缺的是能被統一治理、統一檢索、統一計算的數據資產

AI 列也很有意思，它相當于讓數據庫內部長出一條語義加工線，原始數據進來之后，可以在庫內生成摘要、標簽、特征、向量等結果，對一張表里的多行數據做 embedding 或打標，AI 列可以保證使用同一套算法，并且要么都成功，要么都失敗

這句話看著樸素，但懂 RAG 的人應該很有感

向量化任務跑一半掛了，一半舊向量一半新向量，后面的召回質量會變得很玄學，數據庫愿意認真處理這種一致性細節，說明它面對的是生產場景，不只是 Demo 場景

OceanBase 多模表 混合搜索：別把數據庫該干的活全丟給模型

現在做企業 RAG，大家已經越來越清楚一件事：

單純向量檢索很容易翻車：語義相似，不代表業務正確，一個生產級 Agent 查資料的時候，往往要同時滿足很多條件：

• 語義接近

• 關鍵詞命中

• 結構化條件符合

• 權限范圍正確

• 時間、部門、客戶、狀態一起參與過濾

如果把所有候選都丟給大模型，讓模型自己判斷，成本高，速度慢，結果也容易飄

更好的分工應該是：數據庫先做過濾、索引、權限、一致性和粗排，模型再處理真正高價值的候選，OceanBase 對混合搜索的表達挺準確：

一條 SQL 組合執行
多路召回與粗排在引擎內統一完成
模型只處理高價值候選

關系過濾、全文搜索、向量搜索、圖搜索組合在一起，先把全量數據縮成候選集，再交給模型精排

OceanBase 混合搜索

這件事并非為了炫技，解決的是企業 AI 里非常實際的問題：讓上下文更準，讓 token 更省，讓權限更可控

在 VectorDB Benchmark 上，同等召回率下，OceanBase 的向量性能領先于 Milvus、PGVector、Elasticsearch

在 MSMARCO 數據集上，OceanBase 混合搜索性能優于 Elasticsearch30%+

Agent 友好：允許 AI 安全犯錯

我最近寫 Agent 越多，越覺得企業真正擔心的點不在“Agent 會不會干活”

它太敢干活，反而才是風險

人類工程師改庫之前會備份、會評審、會問同事

Agent 很可能一邊推理一邊執行，直接把環境改了

所以 OceanBase 這次提到的 Fork Database、Copy-on-Write、Diff / Merge，我覺得非常關鍵

它本質上是把代碼世界的分支工作流，搬進數據庫世界

Fork：給 Agent 開一個獨立數據沙箱
Diff：看它到底改了什么
Merge：確認沒問題再合并
Rollback：失敗之后快速回到原狀態

比如阿福的案例

螞蟻阿福是服務上億用戶的 AI 健康應用，回答準不準很重要，它要持續發現 bad case、修復問題、重新評估，也就是一套生產級 Agent 評測工程

問題是，評測過程會改流程、改策略、改數據

這些動作不能污染線上生產數據

為了評測穩定，又要克隆線上數據，甚至還要復制 Memory、RAG、行為數據

在 AI coding 加速之后，十幾個 feature 分支以周為單位并行迭代，如果每個分支都完整復制一套環境，成本和管理復雜度都會很高

OceanBase Branch 的解法，是像代碼分支一樣創建數據庫沙箱，它可以毫秒級創建，內部希望 5 分鐘拉齊一個評測環境，用完直接銷毀

Agent 改錯了，就丟掉這個分支，重新從 main 拉一個出來

這才是生產級 Agent 需要的數據訓練場

它的價值，是把犯錯的影響圈住

Fork Database 解決單個 Agent 的安全試錯，邏輯表解決海量 Agent 的低成本并行

OceanBase Agent 友好能力 海量邏輯表：AI 時代的海量，可能是小庫太多

還有個案例挺有意思

螞蟻靈光短短幾個月承載了 3000 多萬個閃應用

妙思這類面向內部員工的平臺，也上線了上萬個應用

這些應用有一個共同點：平均每個應用表里也就百余行數據

這和過去我們理解的海量很不一樣

以前說海量，往往是單庫大、單表大、并發高

Agent 時代還有一種新海量：

庫很多，表很多，應用很多，但每個都很小，絕大部分時間還在睡覺

99% 創建后沉睡，但要保留

少數被喚醒時，又要秒級響應

如果每個 Agent、每個輕應用都建自己的物理表，schema 會爆炸

OceanBase 給出的能力叫邏輯表

每個 Agent 看起來有獨立表和獨立邊界，底層通過邏輯隔離把大量表收斂到共享物理資源里

再配合共享資源池、按需喚醒、閑時資源歸零，才能支撐海量 Agent 低成本并行運行

我覺得這個設計很 To B

因為企業里未來不會只有一個超級 Agent

更可能是客服、財務、銷售、合規、采購、研發、運營，每個部門都有一堆小 Agent、小應用、小流程

它們都需要邊界

但企業不可能按每個小 Agent 一套完整數據庫的成本去買單

真實案例里，靈光為什么需要 JSON Table

靈光這個案例也很適合說明 Agent 時代的數據形態變化

它號稱 30 秒手搓一個 AI 閃應用，但用戶創建出來的應用 schema 完全不固定

一開始可以把數據全序列化成 JSON，塞進 KV 大寬表

問題來了，SUM、SORT 這些數據庫算子基本用不上，只能把數據撈回業務層算，性能很差，多用戶權限也難控

另一種辦法是每個閃應用建一張物理表

但幾千萬張小表會把數據庫控制面和存儲打爆，靈光的方案是 OceanBase JSON Table

閃應用后端接 SDK，用戶照常寫標準 SQL，SDK 自動轉成 JSON 寫入虛擬表

用戶的 SQL 不用改，OceanBase 側繼續提供索引、SUM、SORT 等能力，存儲成本也能降下來，如果某個閃應用真的火了，再把這部分 JSON Table 數據遷到物理表拿更好的性能

DataStudio、DataPilot、PowerMem、PowerRAG：產品家族開始成型

Lakebase 是底座，但 OceanBase 這次發的是一整套產品組合

完整產品體系包括：

• Lakebase ：底層湖庫一體和多模態數據核心引擎

• DataStudio ：面向數據開發、治理、服務發布和資產管理的工作臺

• DataPilot ：面向業務人員的數據智能 Agent

• PowerMem ：Agent 記憶體

• PowerRAG ：企業級知識庫

• OSI 語義層 ：幫助 Agent 理解業務語義、指標口徑和上下文圖譜

這套組合的方向挺清楚

底層解決數據怎么存、怎么算、怎么搜

中間解決數據語義、治理、記憶和知識

上層解決業務人員怎么問數、取數、生成報告和看板

DataPilot 這一塊，我覺得最適合拿給業務團隊理解

業務人員不關心底層表結構，也不想等數據開發排期

他想問的是：

本月經營指標為什么波動
用戶增長下降的主要原因是什么
幫我生成一個銷售分析報告
搭一個經營監控看板

DataPilot 的關鍵遠不止自然語言問數

它背后依賴業務對象、計算口徑、指標定義、上下文圖譜這些東西

也就是 OceanBase OSI 想解決的問題：讓數據庫從記錄事實，往理解業務更進一步

從這張產品家族圖看，OceanBase 這次講的是從數據庫到 AI 湖庫的一整套能力

OceanBase 面向 AI 時代的產品家族 總結

我會把 OceanBase 這次發布看成一個信號：

企業 AI 的競爭，正在從模型調用層，下沉到數據基礎設施層

很多企業前兩年忙著選模型、買算力、做知識庫

下一階段真正拉開差距的，很可能是數據底座

誰的數據更完整，誰的上下文更準，誰的權限更穩，誰的多模態數據更容易被治理，誰的 Agent 更敢進生產流程，誰就更容易做出真正能落地的 AI 應用