Databricks 峰会观察：数据层或成 AI 下一轮被重新定价的环节

在 2026 年 Databricks Data + AI Summit 之后，一个被反复提起的问题浮出水面：当 AI 真正进入生产环境，数据层在整个技术栈中会扮演什么角色？现场一位参会者给出的判断是：模型、算力都已先后被「重新定价」，而数据层是这一轮 AI 周期中定价最慢、也最被低估的部分，这一状况正在开始改变。

模型与算力已被定价，数据层仍欠账

作者回顾了过去几年 AI 栈的演变：算法层面的进步几乎每周可见，资本市场和云厂商也已把算力的价值充分体现在估值与价格上。唯独数据，一直没有完成被重新定价的过程，原因不是它不重要，而是「太难讲清楚，也更难修好」：

• 企业数据普遍存在混乱、分散、重复、过时的问题；
• 权限与业务语义在不同系统间难以对齐；
• 所谓「实时」往往仍是上一晚跑完的定时任务。

这些工作既不性感，也无法靠一场发布会解决。但当 AI 从演示走向生产，问题便再也无法回避。

模型在收敛，护城河回到数据

在与 OpenAI、Anthropic 等团队成员的交流中，作者反复听到一个共识：模型能力正在趋同，算力只要有钱基本可以买到，真正难以复制的层正在变成数据本身——它的质量、新鲜度、权限控制，以及被加工成可用上下文的效率。

这一判断在训练侧和推理侧同时成立。在模型公司内部，一次训练往往需要数天的数据准备，一旦上游字段脏污、批标注错误、过滤规则偏差，数天算力与等待时间会在「损失曲线飘移」被注意到之前就白白消耗。在 Agent 侧，这一问题以更运维化的方式呈现：

• Agent 失败的首要原因往往不是模型能力不足；
• 而是上下文错误：访问不到的记录、过期六小时的文档、静默变更的数据源，或成本过高的检索路径；
• 现场提到的一个案例中，一个团队因「陈旧上下文流水线」损失了近一周时间，模型本身并不差，但系统无法定位错误是哪个环节引入的。

Databricks 的方向：把数据库扩展为事实、状态与治理的底座

在峰会现场，作者认为 Databricks 值得认真看待，原因有两个：

• 工程文化仍在：创始团队仍然站在台上谈执行引擎、事务、实时分析以及产品下层的管道设计，能感受到产品与工程直觉仍处公司核心；
• 客户在谈生产：与会用户讨论的不是把 AI 当作演示层，而是把它推入生产系统——Agent 需要读写业务状态、实时分析不愿再为数据搬运交税、流水线需要更自主、Agent 行为需要运行时治理。

基于这一背景，作者认为 Lakebase、Lakehouse//RT、数据 Agent 与 AI 治理等产品发布的方向比名称本身更重要：把事务能力拉近数据湖，把实时分析拉回统一数据底座，让流水线更自动化，并把治理从「谁能看这份数据」扩展到「这个 Agent 在这一步被允许做什么」。

尚未画完的地图

作者最后指出，数据库的边界正在扩展——它不再只是存储与查询数据的地方，而正在成为事实、状态、语义、治理与行动的统一底座。Databricks 的方向并不算走错，但架构的最终形态仍未确定。原文在讨论以 Postgres 为入口的取舍时中断，遗留了若干未展开的问题，包括：

• 传统关系型内核能否原生承载事务、内存、向量、多模态、追溯、分支、回滚与细粒度租户隔离；
• 把 Postgres 拉近对象存储后，缓存层的激进程度与一致性如何权衡；
• Agent 频繁创建短生命周期数据库、分叉状态、生成 trace 后退出的工作负载，是否能由现有架构直接承接。

这些尚未回答的问题，本身也是数据层「重新定价」过程中必须迈过的关卡。