洞见·Latent space·2026.06.24

Agent Cloud:Databricks 押注 AI 未来 (Matei Zaharia & Reynold Xin)

对话 Databricks 联合创始人 Matei Zaharia 和 Reynold Xin,深度探讨 Databricks 从 Lakehouse 到 Agent Cloud 的战略演进、开源 Agent 托管框架 Omnigent、以及为 AI 代理时代重塑的数据库架构(LTAP)。

Overview 背景概览

本文译自 Latent Space 播客,Shawn Wang 和 Alessio Fanelli 对话 Databricks 联合创始人 Matei Zaharia 和 Reynold Xin。

  • 栏目名称:Latent Space
  • 主持人:肖恩·王 (Shawn Wang / Swyx)、阿莱西奥·法内利 (Alessio Fanelli)
  • 访谈嘉宾:马泰·扎哈里亚 (Matei Zaharia) —— Databricks 联合创始人兼 CTO;辛湜 (Reynold Xin) —— Databricks 联合创始人兼首席架构师
  • 访谈时间:2026 年 6 月 24 日

▍嘉宾:马泰·扎哈里亚 (Matei Zaharia) & 辛湜 (Reynold Xin)

  • Matei Zaharia:Apache Spark 创作者,Databricks 联合创始人兼 CTO,斯坦福大学计算机科学副教授。主导了 Spark、Delta Lake、MLflow、Omnigent 等多个世界级开源项目的开发,是分布式计算和数据系统领域的学术与产业界双料巨头。
  • Reynold Xin (辛湜):Databricks 联合创始人兼首席架构师,Spark 核心团队早期关键成员,主导了 Spark 核心引擎及 Databricks 后续计算基础设施(包括新一代湖仓引擎和 LTAP 架构)的系统设计与落地,以务实的工程实现与敏捷的原型迭代文化著称。

▍关于 Databricks Databricks 成立于 2013 年,由加州大学伯克利分校 AMPLab 的 Spark 团队创立。公司开创了“湖仓一体”(Lakehouse)架构,通过 Delta Lake 统一了海量数据的数据湖存储与数仓的事务能力。在 AI 时代,Databricks 进一步演进为 Data Intelligence Platform(数据智能平台),推出 DBRX 开源大模型和 Genie 智能数据代理,并推出了开源 Agent 托管框架 Omnigent 和面向代理时代的统一湖仓数据库架构 LTAP,从数据底座全面向“Agent Cloud”演进。


内容提要:本期访谈中,Databricks 的两位技术灵魂人物 Matei 和 Reynold 深度拆解了 Databricks 在 AI 代理时代的全新路线图:为什么他们要开源 Agent 托管与治理框架 Omnigent,并构建一套基于有状态/上下文的安全策略;作为计算和存储分离架构的代表,他们如何通过“免费的 CPU”资源在数据湖上直接实现行格式向列格式转码,从而为 AI 时代重塑出免去 CDC 痛苦的统一数据库引擎(LTAP)。此外,他们还分享了 Databricks 务实、敏捷的“原型驱动”创新文化,以及在收购 Mosaic ML 后,Databricks 聚焦“定制化/领域专用模型”而非通用模型前沿竞争的深层商业考量。


辛湜: 我们的一个想法是,一旦数据被妥善存放,AI模型的表现就会相当出色。通用代理的能力已经被阿里(Ali Ghodsi,Databricks 联合创始人兼 CEO)提到过,它们具备相当好的推理能力。我认为,许多传统软件将会在这种新范式下重写,只需将数据放在那里,再加上一些AGI,魔法就会出现。然而,没有正确的数据,这一切都无法实现。

肖恩: 在我们正式开始今天的节目之前,我想对听众说几句话。感谢你们的支持。没有你们的选择和收听,我们无法为大家带来如此受欢迎的AI工程科学和娱乐内容。我们几乎每天都接到赞助商的联系,但幸运的是,足够多的你们订阅了我们,使我们能够在没有广告的情况下继续下去。我们希望保持这种状态。请帮个忙,点击订阅按钮,这是对我们最有力且完全免费的支持。我们每周都努力为你们带来《Latent Space》。如果你们这样做,我保证我们将永不停止努力改进这个节目。现在,让我们欢迎来自Databricks的马泰·扎哈里亚。

马泰: 谢谢你们的邀请。

辛湜: 是的,非常感谢。

肖恩: 感谢你们抽出时间。你们正在举办 Databricks 数据与AI峰会。你刚刚告诉我,你们举办的第一届峰会只有50人。

马泰: 是的,那是在伯克利的一次小型聚会。我们组织了一些教程,主要是教人们使用Spark。

肖恩: 如今,这个社区已经发展到全球有10万人,现场有3万人参与,真是令人惊叹。我刚刚看了主题演讲,阿里是个出色的CEO和演讲者。你们当时是否预料到他会如此出色?

辛湜: 在我们创始团队中,阿里(Databricks CEO 阿里·戈德西,Ali Ghodsi)在这方面显然是最出色的人选。他在公司建设方面视野宽广——无论能否招到某个领域的专家,他都会主动深入研究,与各路专家当面交流,对财务、销售等每个方向都有足够的认知深度。

马泰: 他显然智商和情商都很高,但阿里今天和10年前的阿里是截然不同的(笑)。他为达到今天的成就付出了很多努力。

辛湜: 对我来说,他最吸引人的地方是他的幽默感。关于数据、安全性等严肃话题开玩笑是很难的。

马泰: 确实如此。

肖恩: 你们推出了很多新项目,比如Omnigent、LTAP、梦想引擎等。我们还会讨论Genie、客户联盟、收购Panther、开放共享和Unity AI Gateway。这些都是Databricks的路线图的一部分,但我认为你们正在领导一些最独特和差异化的项目。也许我们可以从Omnigent开始深入探讨。

Tips 知识科普:Omnigent 与 Agent Cloud

Omnigent 是 Databricks 于 2026 年 6 月发布的开源 Agent 托管与编排框架,核心解决企业级 AI 代理落地的两大痛点:

  • 统一 API 层:将 Claude Code、Codex、Phi、OpenAI SDK 等不同编程代理统一映射为同一调用接口,避免厂商锁定;代理会话支持发送消息/文件、接收流式文本或工具调用,以及随时下发「取消/转向」指令。
  • 有状态安全策略引擎:与传统「是/否」静态 ACL 不同,Omnigent 全程跟踪每个代理会话的运行状态(已读取的文件、已安装的包、已花费的 Token),并据此动态决策是否允许某操作,在安全与效率之间实现精细平衡。

项目于周六开源后 48 小时内即收到约 400 个 Pull Request,近半数来自 Databricks 团队外部——包括 Kubernetes 部署支持、多种云沙箱集成,以及与 Cursor、CLI 等工具的对接。

阿莱西奥: 目前很多人都在尝试做 AI 代理编排,是什么让你们决定走这条路?

辛湜: 事实上,有几个因素共同指向了同一个结论:我们需要一种全新的解决方案。一方面,我们的研发基础设施团队构建了一个名为Isaac的系统,它是 Claude Code 和 Codex(OpenAI 旗下编程助手)的统一封装层,让工程师可以在沙箱或开发机器上直接调用两者。我们看到高级工程师们在这些基础上构建自己的工作流和UI。另一方面,我们的研究团队发布了一个名为Genie的数据科学代理,并为各种事情构建了很多内部代理。所有这些都面临着切换模型和管理工具的挑战。我们意识到,编码代理和自定义代理其实是相同的问题,只需构建那些让你能够交付代理的东西,并确保安全性和可移植性。经过实验,我们发现这确实可行,于是开始真正构建它。

阿莱西奥: 这种架构是否与您过去的职业生涯中的任何事情相对应?

马泰: 很多操作系统的概念可以追溯到数据库,或者反过来。

辛湜: 我认为它与网络协议有很大关系,比如互联网协议。我们也做了一些数据共享的事情,可能大多数观众不太了解。

马泰: 是的,开放协议是共享的术语。开放共享。

辛湜: 是的,比如说你有一家公司维护某种表格,比如沃尔玛。他们有库存和销售数据,供应商希望实时访问这些数据以便及时生产和运输。与其通过电子邮件、Excel表格或电话交流,为什么不能实时共享该表格的视图呢?这让我想起了代理之间的对话和用户与代理以及工具之间的对话。

阿莱西奥: 当时有没有一些反对意见,或者不同的解决思路?

辛湜: 我们就这个问题进行了辩论,认为好处很重要。我告诉马泰,“有一个星期,我从醒来到睡觉一直在不停地编码。查看我的云会话和Codex会话时,必须保持笔记本电脑开着特别烦人。”

马泰: 我当时正开车去看医生,记得因为我想确保整个事情继续工作。听你这么说真是太安慰了,因为我不知道我是不是个小丑。我在开车时,把笔记本电脑连接到手机上,每当遇到红灯时,就查看笔记本电脑上发生了什么。我觉得这很荒谬。

辛湜: 感觉就像我们回到了编程的黑暗时代。

马泰: 编码代理带来的生产力确实惊人,但——你们听说过"云"这东西吗?(笑)

辛湜: 这对我来说太疯狂了。

马泰: 我们正在做的事情是关于沙箱的,还是在那之前?

辛湜: 是关于沙箱的。

马泰: 好的。那么,你是从一个非常不同的角度来接近这个问题的。我想说,“嘿,我们将拥有不会关闭的云沙箱。你可以很快得到一个,但不仅仅是用于运行代理会话。实际上也可以用于开发。”所以,那周我亲自构建了这个,通过构建它,我遇到了所有这些问题。然后,我为我的案例写了一份文件,列出了我希望实际环境应该具备的功能。我想他几乎实现了每一个。

马泰: 是的,我记得辛湜说过,因为我的第一个原型只是与他的代理聊天,他说:”我必须能够打开一个像我自己的 shell 那样的 shell,比如列出文件、实时追踪日志(tail)之类的。”

辛湜: 这是SSH进入一个大型机吗?

马泰: 是的,实际上它有(笑)。

辛湜: 记录我的日志。

马泰: 还有,我想我要求的另一件事是,我仍然使用 Cursor 的唯一目的是渲染markdown文件。

辛湜: 嗯,是的。

马泰: 给我一个查看我的markdown文件并正确渲染它们的方法。我不再需要一个单独的工具了。是的,我想你也把这个构建进去了。

辛湜: 我们做到了。是的,我们有很多工程师在构建他们自己的交互式即兴编程设置。但他们都说,“我构建了一些对我来说很棒的东西,但团队中的其他人无法使用,因为我没有服务器来协作。”这就是我们尝试设置Omnigent的原因,以便你可以有一个服务器并在其中设置安全性。这样,你可以用Google登录或其他方式,安全地共享东西。这就是为什么我们看到很多其他代理遇到的问题,比如人们认为他们原型化了一个很棒的代理,但由于安全团队的原因,它不允许连接到一些非常重要的数据。

肖恩: 是的,在这一点上,对于那些在YouTube上观看的人,我们将展示这里的结构图,我们可以稍微讨论一下架构。我想让人们理解,因为当我们谈论软件时,它可能非常抽象。你已经在开源中完成了整个平台,基本上有一个运行组件和服务器组件,带有你已经弄清楚的统一API。任何其他元素,显然你可以插入所有这些持久层和计算层。这是一个完整的云。这是Agent Cloud。

马泰: 是的,它有这些组件来协作。很多操作发生在你部署代理的机器上。所以,无论你在那里有什么,你都可以运行。但我认为这是你想要托管的最小的东西,比如协作代理,并拥有那个服务器。我们开源它的原因之一是,任何构建代理的人,这给了他们一个可以开始并定制的应用程序。我们在Databricks中也看到了这一点,比如有人会制作一个不错的代理应用程序,然后其他团队会问,“哦,我可以用你的代理吗?”

辛湜: 是的,我想我们有五六个不同的Agentic框架由每个不同的团队构建。它们都或多或少做同样的事情。

马泰: 是的,你基本上需要人们想要拿走一些有效的东西并分叉它,你不妨有一些开源的东西。这也是另一个问题,对于Databricks来说,选择开源什么,选择专有什么是有趣的。这可以追溯到Spark,对吧?

马泰: 开源某些东西的原因之一是,如果你认为它是一个层,将会有一些网络效应。它将受益于许多人在其上协作。例如,使用Spark,我不知道你是否知道,当Spark出来时,我们也非常专注于让开发者能在 Spark 之上构建各类库。以前机器学习和图计算各有专属的分布式计算引擎,我们的思路是:这些都应该成为可以自由组合的库,同时让添加各种数据源连接器的过程极为简单。然后我们受益,因为我们没有时间编写像一千个不同的数据库和文件格式的连接器。但我们可以使用人们制作的那些,当然他们也从加入这个东西中受益。这就是其中之一。另一种思考方式是,不妨想象一下:市场上同时存在一个闭源的代理托管平台和一个开放的——你觉得谁会在长期内赢得市场?所以,在这里,因为有这种从人们编写集成中受益的好处,它将是那样的。然后还有其他事情,比如你甚至无法作为开源交付的东西,是公司做的事情。例如,如何确保你的流作业或基于湖的数据库不会在晚上丢失所有数据?这需要一个操作团队坐在那里。没有办法,它必须是一个服务。所以,我们想确保作为一家公司,我们在那些基础设施服务方面真的很出色,然后我们尽可能开放地在你构建的东西上。

Value 价值视角:开源网络效应与云服务护城河的闭环

Databricks 的商业逻辑承袭自 Apache Spark 的成功经验。从巴菲特的“宽护城河”理论来看,软件行业的最大护城河之一是“生态网络效应”与“高转换成本”。Databricks 开源 Omnigent 这样的代理框架,是为了在 AI 代理基础设施层建立行业标准(通用 API),通过全球开发者贡献的集成连接器(如各种云沙箱、MCP 服务)构建巨大的网络效应。而其真正的盈利壁垒(Moat)则留在上游的“安全治理(Unity Catalog)”、“虚拟机编排”和“云安全托管”服务上。正如 Matei 所说,开源解决的是“可移植性与集成生态”,而企业级商业服务解决的是“让流作业在深夜不会丢失数据”的长期运维信任,两者结合形成了极高的商业转化壁垒。

辛湜: 从好处的角度来看,我认为我们已经看到了拉取请求和生态系统集成,即使它只是在周六发布的。

马泰: 是的,周六。是的,所以有人

辛湜: 让我们看看发生了什么。

马泰: 是的,你可以查看合并线。我今天早上实际上问了一些传奇人物关于

辛湜: 已经有400个合并了吗?

马泰: 是的,我想大约一半不是来自我的团队。例如,有人添加了在Kubernetes上运行的支持。人们添加了许多云沙箱。这可以启动一个云沙箱并在其中运行你的代理,这对于共享也很棒,因为它不像在你的笔记本电脑上,有人直接在上面运行原始代码(raw code)。是的,许多初创公司已经把这些放进去了,我们预计会看到更多。我们也已经有更多的代理工具,Cursor、CLI 和 Antigravity。

肖恩: 这都很美。我觉得上次发生这种情况时,现代数据栈崛起了。我不知道它是否那么有用。我实际上有点好奇你的事后分析。我想大多数人会同意它终于死了。但也许这会崛起为一个新的现代AI栈,像做同样的事情。

辛湜: 我不知道。

马泰: 我认为现代数据栈是一个非常有用的东西,可能直到今天。也许对于那些不了解历史的观众来说,我认为现代数据栈实际上分解为你需要一个层来摄取数据。你需要一个层来转换你的数据。然后所有这些都运行,然后你需要一个层来可视化你的数据。所有这些都运行在某种数据仓库上,或者后来我们在做数据仓库时,也是在做湖仓。我认为这些概念都非常强大和有用。它启用了很多工作负载。人们最终遇到的问题是统一和整合的问题。是,“嘿,你真的需要把所有这些切成不同的部分,并与这么多不同的供应商和平台合作,以便完成一个非常简单的可视化吗?”所以,我认为随着时间的推移,每个人都开始意识到客户在推动我们。我们开始意识到这一点,所以我们开始构建越来越多的功能并尝试整合。最终,现在客户不必担心必须连接五个不同的系统才能生成一个图表。但我认为老实说,这种事情可能正在发生,你想要连接多少个不同的框架才能生成一个非常简单的代理。

马泰: 我想先明确一点:这一切的核心是一套覆盖所有工具的统一 API。这套 API 的设计很简洁:你开启一个代理会话,可以向它发送消息或文件;它则以流的形式返回响应——要么是流式文本,要么是工具调用。此外,你还可以随时向会话发送"取消"或"转向"指令,来中止或重定向代理的行为。所以这就是API。现在,我们所做的事情是,我们可以在像Claude代码、在终端中运行、Codex、Phi、OpenAI SDK等之上为你提供这个。我们将它们全部映射到相同的接口。所以,如果你构建了自己的代理编排器,你就必须自己维护这个。然后每当Claude更改其API时,你就得调整你的东西,否则它会丢失一些消息。所以这就是维护的价值所在。在这之上,我们还构建了一些应用层组件,包括一套很酷的 UI 和其他工具,但最让我兴奋的还是安全与控制这一层——这才是核心价值所在。但这是那个通用接口。所以我们不,我们不试图成为一个栈。事实上,你可以在这个服务器之上插入你自己的UI。这是我们非常关心的用例之一,因为我们想在我们自己的产品中使用这个。

辛湜: 是的,它应该无处不在。

肖恩: 我认为其中一件对我来说非常有趣的事情是,首先,我会努力做到一切,不称之为现代AI栈,因为我认为(笑)我们有一个名字。但就像是的,你知道,所以第一个告诉我关于计算沙箱的人是来自Neon的Nikita。因为很多人认为Neon就像是无服务器的Postgres,具有计算和存储的分离,以及即时分支和所有这些东西。但实际上,每个数据库公司也是一个计算公司。

辛湜: 所以他实际上向我展示了他的整个沙箱解决方案。我不认为他曾经发布过它。

马泰: 所以我们的沙箱解决方案,我们能够如此快速构建它的原因是因为我们意识到如果你只是采用实际的湖仓架构并从中移除数据库,顺便说一下,它是从你那里来的。现在有一些差异。例如,在支持这个特定工作负载的那些中,拥有本地持久性是很重要的。因为你希望你的状态持久化,开发依赖也不必每次重新安装。对吧?而Neon架构,由于存储与计算的分离,你不需要持久的本地磁盘。所以有一些差异。但最终,是的,它是

肖恩: 在节目之前,我们讨论了一些可能令人惊讶的采用统计数据。无论是内部的还是外部的,只是为了让人们对这种规模感到印象深刻。

辛湜: 在分析方面,我们每天在三个云平台上启动大约五千万到六千万个虚拟机。因此,我们是最大的计算编排者之一,特别是在CPU计算方面。

马泰: 这些虚拟机处理的数据量达到数艾字节。我常开玩笑说,取决于你所在的时区,通常在你吃早餐之前,Databricks已经处理了当天的数艾字节数据。而在Neon上,每天启动大约一千三百万个数据库,这也是一个非常有趣的现象。

辛湜: 是的,这个数字对我来说非常震撼。

肖恩: 这听起来像是

辛湜: 你指的是什么?

马泰: 很多都是通过代理和分支实验实现的。

辛湜: 因为我们让启动数据库变得如此简单和快速,这要归功于尼基塔的团队。这正在改变人们使用数据库的方式。

Facts 时空复盘:Databricks 的算力规模——事实上的"第四大云"

辛湜在访谈中披露:Databricks 每天在三大云平台上启动约5000 万至 6000 万个虚拟机,处理数据量以艾字节(Exabyte)计;旗下 Neon(存算分离 Postgres 平台)每天启动约 1300 万个数据库实例。以 AWS EC2 作为参照,其全球 VM 总运行量估算在数亿量级,而 Databricks 仅 CPU 编排的日启动量就已接近这一量级的相当比例。这组数字揭示了一个被市场长期忽视的事实:Databricks 早已不是单纯的数据分析平台,而是悄然成长为仅次于三大公有云的最大独立算力调度者之一。AI Agent 时代每次运行代理任务都要启动沙箱 VM,这一基础设施地位将是其 Agent Cloud 战略的核心壁垒,也是其在计算侧与 AWS/Azure/GCP 正面竞争的底气所在。

肖恩: 是的。好的,我们稍后会深入讨论数据库,但我想确保我们先结束关于Omnigent的讨论。你提到你对安全和控制方面感到兴奋。很多公司现在正在解决这个问题,还有开销方面。你在这方面发现了什么?

马泰: 我花了很多时间与内部用户、开发人员、安全团队、经理以及许多客户交谈。首先,关于安全,立刻显而易见的是,存在可用性和安全性之间的紧张关系。很多编程代理使用的都是非常基础的规则,比如哪些工具模式是允许的或不允许的。这是一个是或否的问题,但这让你处于一个非常困难的境地。比如:我的代理是否应该被允许读取机密文件?它是否应该被允许从 NPM 安装新包——而这些包可能已遭投毒?"是"还是"否"?也许在某些情况下我愿意允许。那代理是否应该被允许向公司官网发布内容?如果代理在处理网站相关代码,那是合理的。但它是否应该同时被允许做以上两件事?这样一来,它就可能先抓取机密文件,再被提示词注入攻击利用,最终将内容泄露出去。显然不行。因此,我们需要的是有状态或上下文策略的东西,你可以跟踪会话的状态。不是简单地说它是否被允许推送到营销网站,而是说如果它做了一件有风险的事情,比如从NPM安装了一个一天前的包,或者读取了一千个机密文件,那么不行。否则,也许可以。这是一个例子,说明如何在这个权衡中前进。通过拥有一个更强大的引擎,它既更安全又更有用。这需要跟踪会话。另一个有趣的方面是,它正在执行这些非常低级的事件,你需要一些库来解析它们。比如,我们在Google Drive内部有一个MCP服务器,它有60个API调用。我怎么知道哪些会与互联网共享文档,哪些不会?这很烦人。所以我们设计了Omnigent的策略层,使其成为函数,你可以有库。有人可以制作将低级事件映射到高级事件的东西,然后你可以为出现的高级事件编写策略。这与Panther有关,Panther将在这方面提供帮助。Panther 在事件处理上有类似的设计理念——基于 Python,而非晦涩的自定义 DSL,且更偏向实时处理模式。

Inverse 反向思考:AI 代理自治与安全沙箱的工程代价

尽管 Matei 和 Reynold 强调了通过 Omnigent 的有状态上下文策略可以限制 Agent 的开销(如 5 美元上限),但在企业实际落地中,安全沙箱与上下文策略引擎本身会引入不容忽视的延迟和资源折旧。每次代理执行命令、调用 API、或在 Kubernetes 沙箱中启动新容器来跑一段代码,都会消耗宝贵的冷启动时间和存储开销。此外,过度严苛的有状态安全策略可能导致代理执行任务频繁中断(等待人类审批),从而大幅削弱代理本应带来的“全自动”效率优势。这需要在“绝对安全”与“工程响应时效”之间进行非常微妙的权衡。

辛湜: 这些事情正在发生。是的,但这些是很酷的东西。我认为上下文或有状态的部分以及它可以是库的方式是另一个使其开源的原因,因为其他人会编写库,我们和我们的客户可以使用它们。最后,因为它是有状态的,我们跟踪的状态之一是你在那个会话中花了多少钱。我曾经让一个代理调试一些东西,它花了500美元,因为它决定读取大量日志文件并消耗大量令牌。但我可以明确地说,“好吧,启动一个子代理来做这件事,并将其开销限制在5美元。如果需要更多,请征求我的许可。”因为我们在那个会话中计算,它会弹出并告诉我,“好吧,你花了5美元。你想继续吗?”

肖恩: 给大家补充一点背景。马泰在过去五年里花了大量时间在 Databricks 主导架构 Unity Catalog,也就是数据治理层。

马泰: 是的。

辛湜: 这有点像是将那个层面的专业知识与这里的所有AI治理结合在一起。

马泰: 是的。但我也花了很多时间被编程代理惹得焦头烂额,踩过不少坑。而且作为 CTO,我不想因为安装了一些奇怪的 NPM 包而泄露所有代码然后上头条。所以,我特别谨慎,但我也没有太多时间。我不想坐在那里批准,“你想运行一个20行的bash脚本吗?是或否?”所以,这就是为什么我花了很多时间去弄清楚如何让它尽可能安全而不烦人。

阿莱西奥: 是的。安全性和我们称之为安全性的问题是否比令牌最大化或令牌预算更重要,你知道,哪个更重要?

马泰: 是的,两者都重要。这取决于公司类型——有些公司预算有限,他们非常在意 Token 开销,

辛湜: 而且规模越大越在意。就算是 Uber 这样的大公司,一样会关心这个问题。

马泰: 完全是。(笑)对我们来说,作为云服务提供商,安全性才是重中之重。Token 成本方面我们暂时还不是特别担心,但我接触过一些咨询公司——他们有10万员工都在帮客户写代码,如果每人每月多花1000美元,累计下来就相当可观了。当然,我们自己只有几千名工程师,处境不同。

阿莱西奥: Databricks的政策是什么?是无限的吗?

马泰: 是无限的,但我们确实使用我们自己的产品来分析跟踪和其他东西,我们有一个团队在寻找优化和查看是否有人在做奇怪的事情。我们实际上从分析当前的跟踪中获得了一些非常酷的见解,比如哪些模型在Rust方面更好,比如TypeScript或其他。所以,至少在我们的代码库中。

肖恩: 是的,太棒了。显然,我必须问关于令牌最大化的问题。显然,我认为这是一个关键问题,但安全和控制在这之上,并找出一个合理的层次,你可以有一些自主权,但不能太多。

马泰: 是的。(笑)是的,我们想让它超级简单。作为一名工程师,你应该设置这个东西。所以,在Omnigent中,你可以让你的代理为自己设置一个策略来做这件事。

辛湜: 如果有任何我应该展示的东西,我在GitHub上没有看到,但你知道,这是

马泰: 把它放在文档里。所以,你可以稍后查看。只需查看上下文策略的文档,如果你想了解。

辛湜: 我只是想向人们展示

马泰: 策略。

辛湜: 是的,如果你想跟进这个,这正是要看的地方,对吧?

马泰: 是的。是的。这些的故事是我只是写了一份文档,上面有10个想法,是在你们工作之前的事情。这是人们要求的愿望清单,我告诉团队,“嘿,你能在发布时至少做五个吗?”然后他们就把所有的都做了。

辛湜: 哦,哇。

马泰: 所以,你可以想出更多,但其中一些只是为了作为例子。实际上,你可以拦截

马泰: 代理正在做的任何事件,然后你可以选择阻止或强制它询问用户或允许,并且你可以更新状态以跟踪事情。

肖恩: 是的,因为你知道,最终,我认为你是一个系统设计师,你让人们插入,对吧?这就是你所做的一切的运作方式。

马泰: 是的,我们非常重视可组合性。我们的目标是让其他人能够编写库供他人使用。

肖恩: 这就像是一个包含电池的理念,类似于你在Spark中所做的,你可以直接开始使用。

马泰: 没错。它必须在某些方面开箱即用,然后你可以在此基础上构建自己的东西。在Spark中,如果你只是想读取一个表或进行聚合,它应该在开箱即用时表现出色。

肖恩: 想了解Omnigent的人应该观看你的主题演讲,浏览GitHub和文档。如果他们想要贡献或在这个生态系统中构建,你认为哪些地方最有潜力?

马泰: 加入Discord社区,然后在GitHub上与我们的团队互动。有些需求我们会自己构建,有些则与开发者合作完成。我们希望听到大家的反馈,特别是开发者的意见,因为每个人都希望工具能以自己的方式工作。我们致力于在代理之间建立兼容性层,让你在此基础上进行创新。作为一个创始人,我看到一个机会,想在你面前展示。你对创业公司的要求是什么?

肖恩: 哦,对于创业公司。

马泰: 是的。你有自己的创业公司,并且做得很好,但如果你没有在自己的创业公司工作,你觉得有什么是显而易见的呢?

肖恩: 你显然也为许多创业公司提供建议。

马泰: 作为一个拥有大量工程师的公司,任何能帮助我理解人们如何使用编码代理以及开销的工具都是有帮助的,比如质量、技能添加或任务优化。

肖恩: 我找到的最接近的是Get AI团队。

马泰: 嗯,酷。

肖恩: 他们一开始专注于代码和人类归因,但后来在此基础上构建了分析层。我认为有很多人会从顾问领域转向实际构建软件,比如编码代理的管理平面。

马泰: 是的,我认为那里会有很多见解。

肖恩: 另一个重要话题是你们的 Dream Engine(Databricks 新一代数据库查询引擎,内部代号"梦想引擎")。

阿莱西奥: 如果你想讲述关于OLTP的故事。

马泰: 我们的背景是,我建议大家去听我们与 SingleStore CEO 安库尔·戈亚尔 (Ankur Goyal) 的那集节目,我们深入探讨了 SingleStore 的架构、HTAP 的历史以及相关背景。

辛湜: 是的,OLTP的概念其实很简单。数据库的世界大致分为两类:OLTP数据库,如Postgres、MySQL、Oracle,和分析数据库,有时称为OLAP。OLTP通常处理事务,如查找和更新特定行,而分析则是对数据进行推理和计算。

阿莱西奥: 这成为了一个强迫人们学习数据库的播客(笑)。

辛湜: 数据库是系统技术中最重要的基础之一。OLTP数据库用于事务处理,而分析数据库用于推理和计算。每个应用程序都需要一个数据库来确保数据不丢失并保持事务一致性。但当数据量增大并需要复杂分析时,Postgres可能无法胜任。

阿莱西奥: 于是你将数据复制到分析系统中。

辛湜: 是的,ElasticSearch是一个常见选择。许多客户使用Databricks进行复杂分析。CDC(变更数据捕获)是读取数据库bin log的标准方法,但它非常复杂,常常导致数据工程师在凌晨被叫醒处理问题。

肖恩: 每个人都像是通过CDC成为了一个50亿美元的公司。

辛湜: 是的,CDC 是现代数据架构的基础操作之一,但它极其脆弱。我们开玩笑说它应该叫"持续数据损坏"(Continuous Data Corruption),因为任何一次 Schema 变更都可能让整条管道崩溃。

Facts 时空复盘:CDC “持续数据损坏”的工程现实

变更数据捕获(CDC, Change Data Capture)是过去十年“现代数据栈(Modern Data Stack)”的基石,Debezium、Fivetran 等公司借此获得了巨大的商业成功。然而,在工程实践中,由于上游业务数据库(OLTP)频繁发生模式变更(Schema Drift)或者网络波动,CDC 管道极易崩溃,常常导致下游数仓数据缺失,被数据工程师戏称为“Continuous Data Corruption”(持续数据损坏)。Databricks 推动 LTAP 架构,其商业本质就是通过湖仓底座的一体化,帮助企业彻底砍掉脆弱 CDC 数据同步链路。

阿莱西奥: 你可以添加版本控制等技巧,但总体来说很复杂。

辛湜: 是的,我在主题演讲中问观众是否喜欢他们的CDC管道,只有两个人举手。SingleStore十年前提出了构建一个能处理两种工作负载的单一数据库的想法。

阿莱西奥: 每个数据库人员都曾梦想过这个。

辛湜: 是的,这是数据库工程的圣杯。我们的L-TAP想法是对HTAP的改进,通过统一存储层来满足大部分需求。这样,数据可以立即用于分析,没有延迟。

Tips 知识科普:从 HTAP 到 LTAP
  • HTAP (Hybrid Transactional/Analytical Processing):混合事务分析处理,由 Gartner 提出,指在同一个数据库系统上同时处理高并发的交易(OLTP)和复杂的分析(OLAP)查询,旨在消除数据从交易库同步到分析库的延迟。代表系统如 SingleStore、TiDB。
  • LTAP (Lakehouse Transactional Analytical Processing / 日志结构化湖仓事务分析处理):Databricks 提出的新范式。传统的 HTAP 试图用一个统一的“查询层”和计算引擎去兼容两种截然不同的工作负载,这往往会导致系统极其臃肿且主备节点开销巨大。LTAP 的核心思想是**“统一存储层,分离计算层”**。它将交易数据以行格式直接写入数据湖,并在后台利用“空闲的 CPU 资源”自动转码压缩成列导向格式(如 Parquet)。这样,分析引擎可以直接读取这些湖上的列存数据进行极速分析,既实现了“零延迟分析”的圣杯,又避免了复杂的 CDC(数据变更捕获)数据同步管道。

马泰: 这让你几乎获得了HTAP圣杯的所有好处,即数据立即可用于推理分析。

肖恩: 人们希望能够查询任何东西,即使在工作时也需要历史和上下文。这是分析工作负载的需求。

马泰: 完全正确。

肖恩: 当我们与数据库发生事故时,工程师不能运行大查询查看问题,因为这会导致数据库崩溃。通过启动独立的机器进行分析,你不会超载主数据库。

阿莱西奥: 这个梦想已经存在一段时间了。为了实现今天的成果,需要完成哪些步骤?我记得你们宣布过几个变体,但它不像L-TAP那样明确。

辛湜: 我认为L-TAP就像是一个标志,表示我们已经成功了。

辛湜: 我和Meta的一位同事交流时,他问我有哪些潜在的陷阱,为什么现在才能实现。我认为我们在湖仓架构上投入了大量时间,这一点很关键。显然,很多灵感来自 Neon 团队,也就是存储与计算的分离。我们从 Neon 架构和湖仓架构出发,将数据以行格式写入开放数据湖,但底层以 Postgres 页面的形式存储。阿里和我花了很多时间讨论能否改为列格式。我们一直在争论,直到有一天,一位聪明的工程师说他做了一个原型,而且成功了。

阿莱西奥: 原型是什么?

辛湜: 原型是在数据湖中不以行导向格式存储数据。

阿莱西奥: 就像把Postgres页面写成Parquet格式。

辛湜: 是的,他发现我们的存储队列有很多空闲的CPU资源,可以用来将行格式转码为列格式。行格式适合OLTP,而列格式适合分析。转码后,数据压缩效果更好,写入S3或其他数据湖对象存储时速度更快,因为数据体积变小了。

阿莱西奥: 所以没有额外的开销,也没有性能上的妥协。

辛湜: 是的,因为我们本来就有多余的CPU资源。

辛湜: 争论就此结束。这是技术问题中的经典案例,经过多次争论后,终于有人去尝试原型化,并成功了。

肖恩: 对于公司战略和重要事项,我本以为会有一个启动的计划,比如设计文档,难道没有这样的东西吗?

辛湜: 没有。我们在许多会议中争论,然后从基本原理上探讨其可行性,最终有人去实现了。

马泰: 是的,如果你能让人们去尝试,那就太好了。这在 Omnigent 项目中也有类似的情况。如果我只是写一个文档,大家可能会有各种疑问,但尝试一下会有所帮助。如果有真实用户的反馈,即便有批评,但仍然有效,或者在这种情况下,如果你知道工作负载的样子,可以测试相同的模式。这种技术创新文化非常重要,你不需要我的许可,也不需要完整的正式流程,只需去做。

Value 价值视角:原型优于文档——以快速试错终结官僚争论

Matei 和 Reynold 在描述 LTAP 行转列优化和 Omnigent 的诞生时,都提到同一个模式:多轮会议争论无法解决问题,一个工作原型能在一周内终结争论。这与巴菲特在伯克希尔推崇的去中心化管理哲学高度契合——"雇最好的人,给他们充分授权,最小化审批层级"。在软件公司,这种文化的价值在 AI 时代被进一步放大:Claude Code、Codex 等编程代理的普及,使"从零构建端到端可验证原型"的门槛大幅降低,曾经需要数月设计文档讨论的架构决策,如今往往几周内就能用原型验证。原型迭代文化 × AI 编程加速,正在成为新一代技术公司的核心生产力飞轮——也是 Databricks 在 12 年内从 8 个学术创始人成长为年营收数十亿美元企业的文化密码。

肖恩: 尤其是在如今的AI时代,这种方式更容易实现。

马泰: 你说得很对。我见过很多大公司的高管,事情在规模上会变慢,但你们的团队是个例外。

辛湜: 我们是如何做到的?我们雇佣并与优秀的人合作,赋予他们权力,同时我们也花了很多时间在前线。

马泰: 是的,我们希望确保人们知道他们可以尝试解决争论,并有很多成功的例子。我们作为公司,尽管规模很大,但并没有推出太多产品,我们试图保持连贯性。这是公司的整体理论,不像亚马逊那样有20个服务,而是提供一个统一的API、语义和数据副本。我们逐步添加功能,比如Delta Lake的存储、SQL和机器学习平台,这样可以保持可管理性。

辛湜: 我们鼓励逐步实现和快速实现,而不是为一切建造。我们的许多产品在几周内建成,然后我们会问团队,目标客户是谁?你和他们有直接联系吗?这种紧密的反馈循环非常重要。

阿莱西奥: 你能再举一个发布的例子吗?我想了解更多背景。

马泰: 这更多是内部使用,我们的AI团队可以访问并使用它,我们确保它从一开始就与我们的内部代码库兼容。我们为开发者提供基础设施和资源。

辛湜: 我们最初为两个客户成功实现了清洁室功能,允许在不共享底层数据的情况下共享数据。虽然过度适应一两个客户可能有风险,但其优点远大于缺点。尝试过于雄心勃勃反而可能导致没有客户。

马泰: 因为你可能最终没有客户。

辛湜: 是的,这更可能发生。我们确实认为有些客户需要放弃。

马泰: 有时客户可能会阻碍进展。科技公司与传统企业非常不同,如果只为科技公司优化,扩展到其他领域时可能会遇到挑战。

阿莱西奥: 你认为三大差异是什么?

马泰: 治理是一个大问题。安全、数据隐私、治理等都是大问题。通常B2B或开发者工具的最大市场是企业,但这与已有30年的公司非常不同。他们有很多遗留系统,或者在受监管的环境中运作。而初创公司或新兴科技公司则不同,一切都是新的、干净的。如果你从未与企业合作过,你就不会知道。

辛湜: 采购过程也可能非常不同,涉及更多的利益相关者。

马泰: 另一个有趣的现象是,一些科技公司的人常常认为他们可以自己构建所需的技术。但实际上,很多企业并不想自己动手。他们不希望因为某个技术问题而导致业务中断,比如流媒体管道无法正常工作。

辛湜: 是的,这使得他们成为很好的客户,老实说。

马泰: 但如果你没有在企业环境中工作过,你可能很难理解这一点。

辛湜: 我认为科技公司和传统企业各有其独特的挑战。很多科技公司更倾向于自己动手,但企业客户则更愿意依赖现成的解决方案。

马泰: 另一方面,一些专业领域的公司,比如制造飞机或设计药物的企业,他们只想要一个能帮助他们获取知识的工具,而不想学习数据库或其他技术。他们只关心如何处理自己的数据,比如对临床数据进行聚类分析。

Inverse 反向思考:企业客户是稳定的现金流,也是创新的锚点

Matei 将传统大型企业(银行、药企、制造商)描述为理想客户——他们不想自建、乐于付费、有刚性需求。这固然是商业软件公司的现金奶牛,但也隐藏着战略风险:大型企业客户的需求往往是"定制化的过去",而非"通用化的未来"。他们的安全合规约束、监管环境与遗留系统,会将产品路线图持续拉向服务特定行业的定制方向,而非构建下一代平台架构。Snowflake 早年爆发式增长,恰恰来自对 BI 查询这一极为标准化需求的专注,而非服务"每个企业的特殊需求"。Databricks 在 Agent Cloud 时代同样面临这一张力:如何在"向制药和制造企业销售 Genie 智能代理"与"保持 Omnigent 作为通用 Agent 基础设施开放标准"之间不相互拖累,将是其下一个十年的核心管理挑战。

阿莱西奥: 是的,没错。那么,关于构建一个理想的引擎,你有什么愿景?

马泰: 我们意识到,许多数据库引擎,尤其是分析引擎,基本上都有十年的历史。它们最初是为特定的用例设计的,随着时间的推移,变得越来越复杂,支持的用例也越来越多。然而,这种演变往往是通过一些权宜之计实现的,导致系统变得混乱。很少有公司有勇气从头开始设计一个新的系统。我们决定尝试这样做,但这无疑是一个雄心勃勃的项目。

辛湜: 每个开发者都应该了解第二系统效应。你以为自己知道一切,然后想设计一个完美的系统,但结果往往不如预期。

马泰: 是的,很多时候,第二个系统因为过于雄心勃勃而失败。我们的工程团队非常优秀,他们不是第一次构建这样的系统。他们改变了数据库引擎的构建方式,利用我们十年的数据来创建一个数据库构建工厂。这个工厂可以快速评估算法和数据结构的表现,从而选择最合适的方案。

阿莱西奥: 听起来你们在尝试根据不同的数据结构进行路由。

马泰: 是的,一个数据库需要确保所有组件协同工作,并为每个操作选择最佳实现。我们在吞吐量和延迟之间做了很多权衡。

阿莱西奥: 关键的维度是什么,比如规模、吞吐量、延迟,还有其他因素吗?

马泰: 数据的分布和稀疏程度也很重要。不同值的数量会影响内存消耗和哈希表的性能。

阿莱西奥: 我会在我的写作中尝试列出所有这些因素,因为分类法对我来说非常有帮助。

马泰: 如果你真的尝试列出,可能会有一百万个不同的特征。

辛湜: 以前有人做过类似的事情,比如Oracle在40年前列出的分布式系统的八大谬误,这种分类非常有用。

马泰: 是的,正是如此。

辛湜: 这让我想到一个有趣的例子,虽然看似简单,但对性能有深远影响,比如字符串是ASCII还是Unicode?如何编码?

阿莱西奥: 字符串确实是最复杂的数据类型之一。

马泰: 如果字符串非常密集,你可以将每个字符串转换为一个数组,而不是使用哈希表。因为如果字符串足够密集,比如只有256个选项,你就不需要哈希表,只需使用数组即可。

辛湜: 这样查找会快得多。

阿莱西奥: 就像国家代码这样的例子。

马泰: 在这种模型中可能有数百万个特征,但通过使用这些特征,可以优先选择那些在实践中真正有效的算法。很多时候,这些选择是反直觉的。实际上,很多你认为有效的东西在实践中并不理想。更重要的是,在运行时,你可以调度正确的算法和结构。

阿莱西奥: 听起来像是一个理想的愿景。我觉得Databricks在渐进式演变方面做得非常出色。你们是否需要在某个时候强制切换到新系统?

辛湜: 我们的设计是渐进式的。首先,我们推出了一个新的端点,目标是让新引擎能够执行我们以前能做的一切,并且更好,尤其是在低延迟工作负载方面。我们希望逐步推出这些能力,而不是花费五年时间才能看到成果。

阿莱西奥: 这是一个艰巨的任务。我对任何新工作负载和数据库都很感兴趣,比如事务型数据库TigerBeetles。你们了解这些吗?

辛湜: 他们是做什么的?

阿莱西奥: 这是一个双重记账数据库,专为金融账户和信用系统建模而设计。

辛湜: 听起来非常具体。

阿莱西奥: 是的,具有非常高的吞吐量。当你谈到如何从一个东西开始,然后扩展并附加其他功能时,这正是我最近采访的TurboFifo的Simon和Chroma的情况。2023年的所有向量数据库公司突然都变成了通用存储或Blob存储。

辛湜: 数据库不应该是一个单独的类别。

阿莱西奥: 这曾经是一个热门观点,但现在已经成为常识。什么应该是一个单独的类别?如果一切都变成ELT,那会是什么?

辛湜: ELT的论点是我们并没有在查询层面合并数据库,只是合并了存储层。我认为这很重要。我们不认为将查询层合并到一个单一的HTAP风格数据库中是有意义的。很多人可能会想,如果只有一种查询语言就好了,但我不认为这对代理来说是个问题。代理在Postgres SQL或Spark SQL中都很流畅。只要数据可访问,代理就能很好地处理。

马泰: 是的,并且

辛湜: 这可能是五年前人们面临的问题。

马泰: 这可能会随着时间的推移而改变,但这也引出了如何逐步做事的讨论。我们意识到现在不需要解决这个问题,我们可以从当前的Delta应用中获得很多价值。

阿莱西奥: 好的。我将以一些更刺激的内容结束这个播客。

肖恩: 每个人都经历过存储和计算分离,并试图构建云。我从Snowflake那里听到了同样的说辞。你们是如何在他们失败的地方取得成功的?

辛湜: 这很艰难。

肖恩: 嗯,我的意思是,尊重他们是一个竞争对手。客观上,你们已经超越了他们。

肖恩: 从你们的角度来看,核心的洞察是什么,让你们走了一条不同的路?

辛湜: 可能最大的根本区别在于,两家公司几乎同时成立,都转向云端,专注于存储和计算架构。但最大的区别是一个是开放的。Databricks从未采用专有格式,我们从开放的生态系统开始,使用Parquet,然后发展到Delta和Iceberg等。这是一个重要的因素。另一个是AI。

辛湜: 在2022年10月ChatGPT出现之前,我们一直将Databricks定位为"机器学习 + 数据"平台。很多平台都是以机器学习用例为基础构建的。显然,AI浪潮有些不同。这块马泰花的时间比我多得多。但我们从未觉得自己只是一个纯粹的数据基础设施平台。

马泰: 对,Snowflake 一开始只盯着一件事。

马泰: 他们的核心想法是:只管理最有价值的那部分数据,并让访问速度极快。为此,Snowflake 采用了自有存储与引擎深度协同优化的封闭架构,专门面向经理和财务人员等商业用户所查看的少量核心数据,把查询速度做到极致。那是一条完全不同的赛道。而我们一开始就想,我们会做大规模处理和摄取。比如你有一堆JSON日志文件,我们做那些非常大规模的东西,因为那是Spark的用途,大规模批处理之类的东西。然后,我们将数据保持在一个开放格式中。可能会更慢,但它已经在那里,你可以在下游消费它。结果证明,从那个在规模和摄取方面非常出色且成本极低的批处理开始,并在其中创建具有速度和功能的版本,比起为商业用户提供的小数据更容易使用。

辛湜: 然后进行优化。

马泰: 是的,从开放和大规模开始。在某种意义上,我们从他们的上游开始。实际上有一段时间我们都把对方列为合作伙伴,因为你说如果你同时使用这两种解决方案,使用Databricks进行摄取和计算,然后从Snowflake中提供表格,你会得到所有的可视化,所有快速的东西。那很棒。然后,我们都意识到客户告诉我们:“为什么我需要这个其他东西?为什么我不能直接查询你的表?”我们说:“不,我们在这方面很糟糕。请使用我们的合作伙伴进行SQL仓库的工作。”然后他们意识到:“等等,很多计算正在向上游移动到这个其他东西中。”

肖恩: 你必须进入彼此的领域,是的。

马泰: 我们确实从更广泛和开放的视角出发,这一点非常重要。就像一个传统老牌企业,如果你的公司已经存在了30年,经历过被锁定在Oracle等系统中的困境,作为CTO,你会希望为公司选择一个开放的架构基础。理想情况下,你只需要一种方式来管理公司中的数据,而不是依赖七个不同的系统。

辛湜: 我认为数据格式的开放性已经取得了胜利。现在每个企业都希望将数据存储在开放的数据格式中。然而,这在当时是非常有争议的。大约五、六年前,Snowflake的一位联合创始人甚至写了一篇博客,题为《明智地选择开放》,基本上是反对开放格式的。

Value 价值视角:开放数据格式的终局胜利

在数据仓库/湖仓领域,Snowflake 早期依靠极为易用的全托管闭源体验(专有数据格式)实现了爆发式增长。而 Databricks 则始终坚守开放格式(Delta Lake, Parquet),允许客户直接使用其他计算引擎(如 Presto, Flink)处理存储在 S3 上的数据。短期内,闭源锁定的格式(如早期 Snowflake)能带来更高的商业毛利和用户粘性;但长期来看,由于企业对被单一厂商绑定(Vendor Lock-in)的恐惧,以及大数据/机器学习生态的极速演进,开放格式(Delta Lake 和 Apache Iceberg)最终在主流企业级架构中胜出。这也逼迫 Snowflake 后来不得不紧急转向支持 Iceberg 开放格式,印证了 Databricks 战略的前瞻性。

马泰: 是的,我记得。

辛湜: 我想他们可能已经撤下了那篇文章。你现在得去找存档。

肖恩: 哦,我的意思是,它永远不会真正消失。它还在那里。我欣赏你们的视角,因为你们经营着公司,这种视角非常宝贵。

阿莱西奥: 也许最后一个问题。当你们谈论时,我想我必须给阿里很多赞誉。

辛湜: 他是一个了不起的CEO,完美结合了IQ、EQ、技术痴迷、执行力和商业头脑。

马泰: 他也是创始人之一,这让他更容易动员和执行。

辛湜: 是的,我觉得这确实是...

马泰: 是的,就是这样。有阿里在,有些决策在公司内部确实遇到了阻力,但他力排众议推进了下来。

辛湜: 当然还有很多其他因素,但我认为阿里在这个过程中扮演了举足轻重的角色。

马泰: 他在关键的技术路线选择上也有实质性贡献。

马泰: 他推动了很多事情。在关键时刻,他会力推某一个方向,事后来看,那往往就是正确的方向。

肖恩: 我想需要写一本书来讲述你们八个人如何一起工作。已经有人做过一些人物特写。第二个问题,关于Mosaic。我们社区里很多人都对Databricks的模型故事感兴趣。当你们收购Mosaic时,大家都在想,“好吧,我们可以进行微调。我们要做内部模型。”因为他们有Mosaic模型。但看起来你们并没有这样做,而是更倾向于Alt App和Harness的东西。那里的故事是什么?

马泰: 是的,Mosaic以发布开源LLM而闻名,或者说很快就变得非常有名,它们是通用模型。实际上在那之前,他们主要专注于优化训练系统,拥有世界上最快的图像模型训练堆栈。然后他们决定做LLM,这是明智的。他们在ChatGPT之前就进入了这个领域,有一些最早的开源LLM。

阿莱西奥: 是的。我们采访了 Jonathan Frankle 和 Abhinav 关于 MPT-7B 的那期节目。

马泰: 是的,非常酷。所以我们决定,即使我们确实推出了一个开源模型DBRX,达到像Llama 3规模以上的水平,我们更想专注于会有很多人发布模型,而不是做通用模型。因为配方的一大部分只是投入大量计算和规模,我们想专注于下一步,比如说你有一个非常聪明的模型,如何让它有用?这对我们来说,很大程度上是关于自动化,比如如何让它非常擅长查询数据。这是我们称为Genie的第一方代理。就像一个虚拟的数据科学家,了解你公司内部的所有东西,所有的机器学习库,所有的数据库,所有的网络上的东西,你可以问他们问题。这是我们首先想做的。所以这意味着我们不要过多关注于训练某种前沿模型,而是使用外部模型或微调的定制组件来构建系统。我们仍然在做相当多的模型训练,事实上,我们一直在采购大量GPU和其他资源来做这件事。有几个地方我们在这样做。一个是,有很多高容量的用例,如果你有一个专门的模型,它比任何通用模型都要好得多。一个很好的例子是理解文档,比如PDF、Word文档之类的,解析它们。如果你曾经尝试过这样做,会很沮丧,因为你把它发送给像Claude Fable之类的东西,它几乎能做到,但有些地方出错了。而且超级昂贵。你只是烧掉了大量的代币,把一个图像放进去。所以,我们的团队构建了这个文档视觉模型,它接收一个页面并返回一个漂亮的JSON,包含所有组件。它非常有竞争力。它可能比那些前沿模型便宜100倍,而且更好。这实际上是由一位来自DeepMind的研究人员完成的,他是Adapt的联合创始人,早期的LLM扩展人员,但专注于此。同样,我们也有,

Facts 时空复盘:前沿模型商品化与 Databricks 的战略转向

2023年 Databricks 以 13 亿美元高调收购 MosaicML 时,市场普遍预期其将全力投入大语言模型(LLM)的军备竞赛。然而到了 2026 年,前沿基础模型(从 GPT-4o 到 Claude Fable 5)的 API 价格大幅下滑且能力趋向商品化,正如微软 CEO 纳德拉所言,”前沿模型正在迅速商品化”。Databricks 敏锐地调整了战略,不再试图烧数亿美元去与 OpenAI/Anthropic 争夺万亿参数通用模型的顶峰,而是转向构建 Genie 等“第一方数据代理”和开发 Omnigent 等 Agent 托管底座,让模型作为即插即用的组件去解决具体的企业数据查询和工作流问题。这一转向在商业上被证明是极其务实的。

马泰: 我们正在为编码代理的一部分做专门的子代理。如果你看过 Harvey(面向法律行业的 AI 助手公司)在专家顾问模型上所做的工作,还有

阿莱西奥: 还有Anthropic,Commission也是。

马泰: 还有UC Berkeley,实际上,我在那里的一个研究生写了一篇关于顾问模型的论文。我想在那些出来之前。我相信其他人也同时有这个想法,但这确实帮助很大。所以,是的,我们今天在主题演讲中展示了一些东西,

阿莱西奥: 是Parf吗?哦,你知道Parf吗?

马泰: Parf,是的,是的,Parf是

阿莱西奥: 在我的活动上发言。他在Continual Learning Bench上发言。

马泰: 是的,是的,我是他在Adapt的顾问之一。

阿莱西奥: 采访了他的兄弟Chai,因为他也在Adapt。

马泰: 是的,是的,是的。

阿莱西奥: 那个家族非常聪明。

马泰: 是的,是的,是的。(笑)他们很棒,是的。所以,是的,我们正在做一些这样的事情,并且随着我们在第一方代理中获得经验,我们也在与客户一起做这些事情。所以,我的感觉是,定制模型实际上会随着时间的推移变得更容易。这是我们发现的,因为基础模型更聪明,所以它们在RL中已经生成了更好的轨迹,然后RL是关于从你自己的过去轨迹中学习。然后合成数据生成现在要好得多,容易得多。我们有使用开源模型的管道。就像同一个模型生成训练环境并自我训练,在任务上击败像Opus和GPT 5.5这样的东西。所以,我确实认为它会加速。你知道,问题是训练算法的难易程度只会随着时间的推移而增加。问题是它何时会进入主流。比如,不仅仅是我们做的专门的文档解析的东西,你需要一个硬核的LLM研究人员,

马泰: 什么时候它会变得足够简单,以至于任何人都可以放入一些东西并描述一个任务。

辛湜: 你知道是什么让它变得容易吗?接口和统一的API。因为显然如果它不互操作,你就无法切换。

马泰: 这就是我们在Omnigent和可组合代理中看到的。你可以有带有专门模型的子代理,然后你可以训练整个系统。我认为这也会有很大帮助。是的。

肖恩: 最后我要说的,其实,我在安排这个,所以我对自己感到有点自豪。Satya,他在谈论这个。我几周前在Microsoft Build采访了他。然后他写了这篇文章,我相信你们已经看过,就是前沿模型的商品化(commoditization of the frontier)。当我和他谈话时,他听起来更像是Databricks的CEO。

辛湜: 嗯。

肖恩: 嗯,这个东西在我的圈子里可能已经疯传了。我不知道它在你们的圈子里是否也是如此。你们怎么看他的核心论点?他谈到了 Token 作为知识产权、构建上下文等等,基本上什么都说到了——唯独没有说那句老话"数据是新石油"。但本质上是你们熟悉的那个逻辑。

马泰: 是的,我同意。我认为你拥有的数据,随着你在这方面获得更好的技术,你可以在你的领域中做更多的事情。这不仅仅是关于AI。即使当人们开始实时收集东西时,比如我记得所有电力公司都安装了智能电表,所有汽车制造商都开始安装传感器和摄像头。任何技术都使数据更有价值,并能给你一些优势。任何帮助你用它做某事并做出一些决定的东西。AI也是一样的。你有所有这些东西只是坐在那里。现在你可以有一个代理自动告诉你。比如说,我发现我的产品中的一个功能坏了,因为客户投诉,代理告诉我,“我注意到没有人再上传文件了,因为他们遇到了错误或其他。”正如辛湜(Reynold)刚才所说的那样,作为一家数据库公司,因为我们有所有这些查询的历史记录和所有表格布局以及它们的工作方式,我们可以非常快速地构建一个新的引擎,它实际上是好的,我们有信心它会很好。所以,我认为这是对的。我认为问题是它将如何落地,但我确实认为像萨提亚(Satya)谈到的定制模型将变得更容易。

阿莱西奥: 这就是为什么我提到模型的事情,因为他们有他们的MEI,而你们没有。这是一个心理问题。

马泰: 是的(笑),我们确实有。我们正在与一些客户进行RL微调服务。我们没有像他们那样的产品,但我们有一个叫做AI runtime的通用平台,它提供按需的GPU集群和软件堆栈,简化训练过程。虽然我们没有完全相同的产品,但我们已经有一段时间在提供GPU计算,这也是Mosaic堆栈的一个重要扩展方向。

辛湜: 是的,我们发现有两种类型的客户。一些客户只需要GPU和库来获取数据和监控,这就是AI runtime的作用。还有一些客户希望我们与他们合作,构建评估和合成数据。

马泰: 是的,这需要更多的前沿部署解决方案架构师。

辛湜: 这正是我们正在做的。随着更多的东西从定制过渡到非定制,这就是目前的情况。

马泰: 回到最初的问题,我认为我们有一个观点是,一旦你能把数据放在正确的位置,AI模型就会变得相当出色。通用代理已经具备了相当好的推理能力。实际上,我认为许多传统软件将会以这种新范式重写,只需让数据在那里,然后在上面加一个代理,魔法就会出现。这实际上是我们进入安全领域和客户数据平台领域的方法。

辛湜: 我们在数据与AI峰会上推出了两个产品,一个是针对安全团队的,另一个是针对营销团队的。这些领域都有很多现有的技术,而我们的做法是,一旦你把数据导入,所有事情在代理的帮助下都会变得容易得多。

肖恩: 是的,你们真是太棒的嘉宾了。我非常喜欢这次讨论,能够深入探讨技术,同时也涉及文化和战略。我希望这不是我们最后一次聊天。恭喜你们取得的所有成功。

马泰: 谢谢,也祝贺你们的成功。

肖恩: 是的,其实 Databricks 正在赞助我的一个活动,我举办一个会议。我一直是数据与AI峰会的参与者。我注意到在2022年时,会议内容大约90%是数据,10%是AI。我就想,我们需要一个社区活动,90%是AI。这并不是每个人都能做到的。

辛湜: 是的,这很有效。

肖恩: 所以,Databricks会参加这个会议。我觉得看到你们构建出如此有趣的云服务真是太棒了,除了三大云巨头(AWS、Azure、GCP)之外,这是我见过的最有趣的云服务。你们的发展令人惊叹。就像我不是风险投资家,但我在电视上扮演一个。比如本·霍洛维茨 (Ben Horowitz) 当年跟你们谈公司未来时,说的大意是:不到千亿美元不要出手,对吗?

辛湜: 他说这家公司应该值一万亿美元——你们当初以百亿美元估值出售,是严重低估了。

肖恩: 他并不是对每个人都这样说的。

马泰: 出于某种原因,我想他看到了愿景,也看到了你们拥有的无限发展空间。

辛湜: 我们很幸运有本的支持。他是个大支持者。

肖恩: 是的,太棒了。好的,非常感谢你们。

马泰: 好的,非常感谢你,肖恩。

辛湜: (音乐)


Takeaway 行动指南
  1. 数据决定 AI 终局:不要迷信前沿通用大模型能解决一切问题。企业 AI 的效果 80% 取决于数据资产的质量与安全治理。将数据妥善存放在湖仓一体的开放底座上,是构建一切智能代理的先决条件。
  2. 拥抱敏捷的原型迭代文化:在 AI 时代,与其花数月时间编写繁复的系统设计文档并反复开会争论可行性,不如鼓励技术团队在数周内构建出端到端的工作原型。真实用户的反馈和实际工作负载的压测,是解决技术争议、推动底层创新(如行转列优化)的唯一标准。
  3. 为 Agent 重塑安全与治理边界:传统的“是或否”单点安全策略(如 IP 白名单、单一 API 权限)在具备推理和代码执行能力的智能代理面前已经失效。企业在托管 Agent 时,必须采用如 Omnigent 般“有状态且具备上下文感知”的安全策略引擎,在计算沙箱与动态预算(如 Token 熔断机制)的保护下释放 AI 生产力。
  4. 计算与存储分离的系统重构:构建面向未来的技术架构时,应充分利用多余的计算资源(如存储队列中空余的 CPU)在后台隐式地进行数据格式转码(行存转列存),实现零开销的 HTAP/LTAP。这能极大简化系统链路,消除脆弱的 CDC 数据同步管道,降低运维灾难。