Databricks 資料與 AI 峰會 2026 後的思考：資料層為何再次重要

在今年的 Databricks 資料與 AI 峰會後，我的思考重點並非某個單一發布，而是一個縈繞已久的問題：當 AI 真正投入生產時，資料層會變成什麼？我的答案是：在這個週期中，資料層是 AI 棧中被重新定價最慢的部分，但這種情況正在改變。

資料層是 AI 棧中市場尚未定價的部分。演算法已經在公開市場上被重新定價，模型改進迅速，計算資源也被輝達、雲服務商和資本市場重新定價。但資料的變化更慢，並非因為它不重要，恰恰相反——資料難以重新定價是因為它難以討論且更難修復。企業資料混亂、分散、重複、過時，且充滿無人完全理解的許可權。業務語義在不同系統間無法對齊，所謂的“即時”往往還是昨晚執行的計劃作業。這些工作痛苦且不光彩，但一旦 AI 從演示進入生產，這種痛苦就無法隱藏。在 OpenAI 和 Anthropic 等模型公司的對話中，討論常回到同一個點：模型正在收斂，計算資源只要有錢就能買到，而可防禦的層逐漸成為資料本身——它的質量、新鮮度、許可權以及轉化為有用上下文的速度。這不僅是應用層的問題，模型質量仍高度依賴資料管道，一次訓練執行可能需要數天準備，上游欄位髒亂或批次標記錯誤可能導致數天的計算付諸東流。

AI 智慧體使資料問題無法隱藏。智慧體以操作化的形式暴露了相同的問題：當 AI 智慧體在生產中失敗時，首要原因往往不是模型能力不足，而是模型基於錯誤上下文行動——無法訪問的記錄、過期的文件、悄然變化的資料來源或過於昂貴的檢索路徑。作者最近看到一個優秀團隊因為陳舊的上下文管道浪費了將近一週時間。智慧體自信地回答了昨天的問題，而系統無法證明錯誤何時進入迴圈。下一個基礎設施瓶頸不僅是更好的推理，而是模型或智慧體決策時擁有新鮮、可信、廉價且可審計的上下文。

Databricks 瞄準了正確的問題。作者對許多自稱“AI 資料平臺”的產品持懷疑態度，但 Databricks 值得認真對待。峰會上兩件事令人印象深刻：首先是工程文化——創始人仍在談論執行引擎、事務、即時分析等底層管道，產品直覺仍為核心；其次是客戶基礎——使用者並非將 AI 視為演示層，而是試圖將其推入生產系統，問題具體：智慧體需要讀寫業務狀態，即時分析無法持續支付資料移動成本，管道需更加自主，智慧體行為需在執行時得到治理。因此，Lakebase、Lakehouse//RT、資料智慧體和 AI 治理等釋出的方向正確：將事務更靠近湖，將即時分析拉回同一資料基礎，自動化更多管道，擴充套件治理範圍。資料庫正在擴充套件，不再僅是儲存和查詢資料的地方，而是成為事實、狀態、語義、治理和行動的基礎。

然而，地圖很好但尚未完成。作者看到三個不完整的領域。首先是湖基礎本身。以 Postgres 為起點是明智的，但 AI 時代的操作型系統需要事務、記憶體、向量、多模態資料、追蹤、分支、回滾和細粒度租戶隔離。經典 Postgres 並非為雲原生分散式規模或智慧體設計，將 Postgres 更靠近物件儲存也不消除延遲問題，快取穩定性是重大挑戰。其次是多模態資料。AI 應用消耗文本、影像、音訊、影片、嵌入、行為日誌和智慧體追蹤，若這些資料仍位於核心地圖之外，最重要的 AI 資料資產就活在邊緣。最後是預設使用者假設。產品表面仍假定人類使用者，但智慧體以不同方式使用資料庫——它在一個迴圈中執行：檢索上下文、做出決策、呼叫工具、寫入狀態、檢查策略並重復。每一步都可能需要審計，這是一個不同的資料庫工作負載。

當資料庫使用者是智慧體時，問題變得更廣泛：智慧體如何在決策時獲得最新鮮、最可信、最低成本且最可審計的上下文？這不僅是查詢最佳化問題，而是跨儲存、索引、治理、血統、重放、成本控制和執行時策略執行的系統問題。資料系統不能再僅是一個智慧系統，它必須更接近 AI 的作業系統。可審計性不能事後新增，除錯和治理成為同一工作流。作者認為這種架構尚未被任何人完全解決。

最後，什麼是“AI 原生”？透過從真實智慧體工作負載逆向推導，AI 原生資料系統必須做到：多模態資料成為一等公民，彈性從工作負載出發，多租戶下沉到智慧體級別，分支和回滾成為核心資料庫功能，追蹤和確定性重放成為強制要求。這些特性將定義下一代資料基礎設施。