“如果今天重新开始，我不确定还会不会建议 18 岁的人去学计算机。”
说这话的人，是数据库领域的图灵奖得主 Mike Stonebraker，中文常译作“石破天”。他是 Ingres 和 Postgres 背后的关键创造者，也是数据库领域最重要的人物之一。在他看来，计算机科学未来很可能不再是一个增长型行业。
这期访谈里，Stonebraker 把半个数据库行业都点名骂了一遍。
他骂 Oracle，直接说 Larry Ellison 当年是在“撒谎”：把还没实现的功能卖给客户，把未来说成现在，然后让第一批客户帮自己 debug。
他骂 Google，说 Google 当年推 MapReduce 和最终一致性，是“愚蠢”的。很多人只是因为“Google 很聪明”，就盲目相信它一定知道自己在干什么。但在 Stonebraker 看来，Hadoop 低效得离谱，最终一致性也只适合极少数场景。等到 Spanner 出来，Google 自己也等于承认了：事务、一致性这些数据库老问题，根本绕不过去。
他也骂 AWS：Amazon 同时维护大概 15 种数据库，而他认为真正需要的可能只有 3 种。图数据库、各种重复功能的数据库，在他看来，很多都没有足够性能和市场理由继续存在。
但更有意思的是，他对今天这波 AI 的看法。
在他看来，现在所谓的 agentic AI，本质上是“大模型 + 一层系统包装”，而且大多数还停在“只读”阶段。一旦进入真正的“读写”世界——比如转账、库存更新——问题立刻回到数据库的老问题：事务、一致性、原子性。这不是 AI 问题，而是分布式数据库问题。
还有一点，是他对大模型写 SQL 的判断。
在公开 benchmark 上，模型已经能做到 80%+ 的准确率，看起来只差一步就能上生产。但在他们用真实数据仓库做的测试里，结果是——0%。即使加上 RAG、甚至把 join 条件直接喂给模型，最多也只能到 35%。而一个熟练的人类工程师，可以做到 90% 以上。所以他直接下了一个结论：这项技术，至少在可见的未来，还不够格进入生产环境。
下面是完整访谈。
主持人：我想先从 Postgres 的起源讲起。不过在那之前，我更想从最开始问：你是怎么进入数据库这个领域的？
Mike Stonebraker：我毕业之后，很幸运被伯克利录用。当时我很清楚，如果继续做我博士期间的方向，是没什么前途的，无论当时还是现在都是如此。最好的路径，是找到一个真正懂行的导师带你入门。
于是 Gene Wong 把我带在身边，说我们一起做点东西吧。那是 1971 年，也就是 Edgar F. Codd 在 CACM 《美国计算机学会通讯》发表开创性论文后的第二年。
Gene 说，不如我们研究一下数据库。当时主要有两个阵营：一个是 Codasyl 提案，你可能没听过，它是一个低层的“意大利面式”网络结构，你需要通过指针去遍历执行查询；另一个是 IBM 的方案，也就是 IMS，是一种层次化的数据结构，本质是树。
其实 IBM 当时也意识到，树结构并不通用，无法解决很多问题，于是他们又加了一些扩展，把它改造成一种受限的网络结构。但那明显是个很糟糕的补丁。
Codasyl 也有很多问题：它非常底层，很难调试，而且一旦你的 schema（当时还不这么叫）发生变化，基本就得全部推倒重来，因为它完全绑定在物理层。
相比之下，Codd 的关系模型非常合理。所以 Gene 说，那我们就来实现这个吧，这是下一步该做的事情。于是我们在 1972 年开始做 Ingres，当时我还是伯克利的助理教授。你也知道，助理教授大概有五年时间证明自己，要么拿 tenure，要么被淘汰。Ingres 就是我拿 tenure 的关键项目，我在 1976 年拿到了终身教职。
事情就是这么开始的。后来又有一些机缘。当时很多人会做原型系统，基本就是学生作业级别的代码——自己能跑，别人用不了。我们先完成了前 90%，能跑起来；然后不知道为什么，又花了额外的“90%”，把它真正打磨成一个可用系统。
伯克利版本的 Ingres 是真正能用的。接下来几年，大概有 100 所大学开始用它，因为 Unix 开始流行。这是一个能跑在 Unix 上的免费数据库系统，在学术界非常受欢迎。于是开始有很多人来伯克利参观，说这东西很酷，你们最大的应用场景是什么？但我们只能说，其实并不大。
这个问题在 Arizona State University 的一个项目中被彻底暴露。他们考虑用 Ingres 管理 4 万名学生的数据。他们可以接受用 Bell Labs 的非官方操作系统，也可以接受用我们这个“非官方”的数据库系统，但最后项目失败了，因为 Unix 上没有 COBOL，而他们是一个 COBOL shop。
不支持的操作系统、不支持的数据库系统，再加上没有 COBOL——直接让我们变得毫无相关性。
唯一的出路就是创业。于是 1980 年，我们拿了当时的风投，成立了 Ingres 公司，把系统迁移到 VMS 这样的“真正操作系统”上，并提供商业支持，这就是商业化的开始。
主持人：我看到 Ingres 当时在和 Oracle Corporation 竞争。技术上你们明显更好，但 Oracle 还是赢了，他们是怎么做到的？
Mike Stonebraker：Larry Ellison 是个非常厉害的销售。他会把“现在”和“未来”讲得毫无区别，本质上就是对客户撒谎。
他会把还不能用的功能卖出去，然后让第一批客户帮他 debug。我认为这是一种很不正当的商业行为，对客户撒谎是不可接受的。
举个例子，有个功能叫“引用完整性”（referential integrity）。比如你开除了一个员工，而他是某个部门最后一个人，那你是删除这个部门，还是保留一个“空部门”？类似这种逻辑。
Ingres 实现了这个功能。而 Oracle 当时的做法是：在手册里写两页文档，解释什么是引用完整性（大家都同意这个定义），但在页面底部写一句——“尚未实现”。
主持人：我采访过 Sun Microsystems 的人，他们对 Ellison 的评价也差不多。还有一个说法是，当 Oracle 收购 MySQL 后，大家转向了 Postgres，这也让 Postgres 成为主流开源数据库。那么，从 Ingres 到 Postgres，最大的变化是什么？
Mike Stonebraker：最核心的变化，其实来自一开始的一个需求。当年我们想支持一个 GIS（地理信息系统），需要处理点、线、多边形等数据类型。但 Ingres 只支持整数、浮点数、字符串这些标准类型，没法高效支持 GIS，所以在这个方向上完全失败。
这件事一直在我脑子里。
后来还有一个例子。大概 1985 年，关系数据库引入了日期时间标准，Ingres 按照标准实现了公历时间。结果有个客户打电话来说，你们实现错了。
我说怎么会，我们完全按公历实现的，日期计算也完全正确。他说，这不是我要的。他做的是债券业务，在他的世界里，每个月的利息是固定的，不管这个月是 28 天还是 31 天。也就是说，他的“日期减法”规则和现实世界不一样。比如 3 月 15 日减 2 月 15 日，他认为是 30 天。但在 Ingres 里，这些逻辑是写死的。他只能把数据取出来，在应用层计算，再写回去，效率直接下降 2 到 3 倍。
他问我，为什么不能自定义减法？这就是问题所在。这是一个你需要“债券时间”的场景，就像你需要点、线、多边形一样。于是 Postgres 被设计成一个可扩展类型系统。你可以定义任意数据类型，而且运行效率很高。这就是 Postgres 最核心的思想。
当然，大多数商业场景用标准类型就够了，但数据库逐渐扩展到更多领域，比如抽象数据类型、存储过程等，这些都需要扩展能力。
此外，Postgres 还支持继承（当时 AI 研究者需要），也支持“时间旅行”（历史数据查询），不过实现得很糟糕，后来被移除了。但总体来说，它包含了大量非常有意思的特性。
主持人：你提到你很擅长招到优秀工程师。你是怎么识别这些“非常厉害的人”的？
Mike Stonebraker：通常一眼就能看出来。我对“难度”是有感觉的。如果一个学生完成的工作量是我认为合理水平的三倍，那他就是非常优秀。
主持人：你还有一句话挺有意思：“我受不了那些不够聪明的人，很难和他们交流。”那你怎么判断一个人不够聪明？
Mike Stonebraker：很简单，跟他聊一会儿就知道了。你问他技术细节，比如他的硕士论文做了什么、具体怎么实现、错误处理怎么做、用了多少进程、为什么不用线程——你问这些深入的问题，很快就能看出来。
主持人：你之前提出过一个观点，叫“One size fits none”，也就是“一套通吃的数据库并不是最优解，实际上谁都不适合”。
Mike Stonebraker：对，通用型数据库系统并不是最优解。所谓 one size fits all，实际上往往是谁都不适配。你真正需要的，是针对具体需求定制的数据库方案。
主持人：那你现在看到的数据库产品里，哪些还属于这种“通用型一把梭”？
Mike Stonebraker：我在 2004 年写那篇论文的时候，我们当时手上正好有一个学术项目，后来变成了 StreamBase。流处理引擎和关系型数据库看起来完全不像一回事。与此同时，我们也已经有了列式存储做数仓的大致思路，后来由 Vertica 把它做火了，而列存和行存看起来也完全不是一类系统。
所以当时其实已经摆在眼前了三种差异极大的实现，它们彼此几乎没有相似性，但在各自场景下，性能都比传统方案高一个数量级。这已经很能说明问题了。只要数据库系统不是为你的场景设计的，你就会直接损失一个数量级的性能。
我觉得今天还是这样。比如 ClickHouse 就是列存。Pinecone 在基于文本的向量处理上，也比那种用用户自定义类型硬塞进去的方案更快。所以这件事到今天依然成立。我也不觉得在多个不同实现之上套一层统一 parser 有什么难度。只是 Postgres 到现在也没这么做，它没有真正实现列存，所以在大型数据仓库场景里并没有竞争力。它也没有多节点支持，而对于大规模数据仓库来说，这已经是最基本的门槛能力了。所以我觉得，这件事今天和当年一样成立。
不过，另一件同样成立的事是，如果你只是想先把事情做起来，手头有个数据库问题，那答案通常还是选 Postgres。它有一个巨大的开发者社区，有各种各样的数据类型实现，是免费的，也很容易招到懂 Postgres 的人，能很快启动。
所以我认为，作为满足最低通用需求的选项，它非常好。只要你不是要做到每秒一百万次事务，也不是要支撑一个 PB 级的数据仓库，它都完全够用。也就是说，在低端场景里，那个“通用解”就是 Postgres，绝对没问题；但到了高端场景，这个结论就不成立了。
主持人：GPU 会不会给数据库优化带来一些新的机会？
Mike Stonebraker：也许会。但我觉得最大的挑战在于，GPU 本质上是 SIMD，也就是 single instruction, multiple data，单指令多数据。而这和索引恰恰是相冲突的。
只要索引是正确答案，GPU 大概率就不是一个好答案。
另外，你还得把整个系统架构好，确保从存储到计算的带宽不会成为瓶颈。如果 GPU 只是挂在 CPU 旁边做个附加件，那很多时候 CPU 和 GPU 之间那条总线本身就成了瓶颈。
主持人：你能解释一下，为什么在 SIMD 这种模式下，索引效果会变差吗？
Mike Stonebraker：比如说，我现在要查 Ryan 的工资，我手上有一棵 B 树。你先访问 B 树根节点，找到那个把 Ryan 分到某一边的分隔键，然后沿着指针往下走，这就是一次确定无疑的内存访问。接着再做一遍，再做一遍，通常要重复三四次。
这种过程是很难并行化的。所以答案就是，索引本身就不适合并行化。
主持人：你刚提到 B 树。那你们最早实现 Ingres 第一版的时候，这些东西都是手写的吗？我猜那时候应该也没有现成的 B 树库可用吧？
Mike Stonebraker：对，Ingres 最早的版本全部都是从零写的。
主持人：那里面最难实现的部分是什么？
Mike Stonebraker：查询优化器。
主持人：为什么它这么难？
Mike Stonebraker：因为它真的难。这东西在算法层面就很复杂。直到今天，如果你去问任何资深数据库程序员，系统里最难的部分是什么，他们大概率还是会说，优化器。
主持人：MapReduce 在 2000 年代初出来之后，几乎一下子席卷了整个数据领域。很多人都非常震撼，觉得 Google 真懂，觉得这就是最先进的东西。但看你当年的论文和观点，你似乎非常不认同。你为什么那么强烈反对 MapReduce？
Mike Stonebraker：因为当时有很多其实并不怎么明白的人，会想当然地觉得，Google 很聪明，他们一定知道自己在干什么，所以我们照着做就行了。于是大家就开始搞 Hadoop，或者往 Hadoop 那套上靠。
但 Hadoop 的效率低得离谱。
当时像 Dave DeWitt，还有参与我们 2011 年那篇论文的其他人，我们都懂分布式数据库，也知道用分布式数据库系统可以把 Hadoop 打得很惨。我们 2011 年那篇论文基本上讲的就是这件事。后来事实也证明，确实如此。
但 Google 做蠢事不止这一件。
他们当时还认为，eventual consistency，也就是最终一致性，是正确的并发控制方式。这在那个时期也是 Google 从上往下灌输的一套东西。但这根本不对。所有数据库领域的人都在说，你们简直疯了，因为它只解决一种非常特定的问题，而且这种问题在真实世界里其实很少见。
主持人：那他们为什么会去追求 eventual consistency（最终一致性）？
Mike Stonebraker：设想一下，你有一个东海岸数据库和一个西海岸数据库，它们互为副本，你希望两边保持一致。
如果我现在要做一个事务，把西海岸仓库里某种商品的库存减一，那在提交事务之前，我就得把这个更新同步到东海岸，再确认那边也更新成功。然后为了确保整个提交真正完成，还要再来一次往返通信，确认两边都正确提交了。分布式提交就是这么贵，到今天也还是贵。
于是就有人想，那我只在西海岸先把库存减一，然后异步发一条消息过去，不把它放在事务里，这样东海岸那边“最终”也会减一。
反过来，如果东海岸那边也卖掉了一件，它也异步发消息过去，最后两边慢慢收敛成一致。
问题在于，如果系统允许库存降到 0 以下，那就会出现一种情况：东海岸和西海岸的人同时卖掉最后一件货。最终系统里的库存就会变成负一。也就是说，有一个人最终拿不到货。
如果你像 Amazon 一样，可以说“通常 24 小时内发货”，那你也许还能接受一定程度的超卖。但大多数企业做不到。所以 eventual consistency 根本行不通。
我们很久以前提到过 referential integrity，参照完整性。其实在销售系统里，也有类似的完整性约束，比如“库存必须大于等于 0”。而 eventual consistency 在这种约束下就是会失效。
后来 Google 的 Jeff Dean 终于也意识到了这个问题。等他们做 Spanner 的时候，Spanner 用的就是传统事务系统。也就是说，Google 后来彻底放弃了 eventual consistency，也彻底放弃了 MapReduce。
主持人：所以本质上的权衡，就是用正确性换性能？
Mike Stonebraker：对，就是性能和数据完整性之间的权衡。如果你根本不在乎你的数据，那你当然可以接受这些糟糕的后果。
主持人：那 Google 当年做这些你认为明显错误的事情时，你有没有和他们团队交流过？
Mike Stonebraker：我们在 2011 年那篇论文之前找他们聊过。我们说，要不要合作做点东西？但他们没兴趣，直接拒绝了。
主持人：除了 Google，你在别的大科技公司身上，也见过类似你明确不认同的数据库方案吗？比如 Amazon 或 Facebook？
Mike Stonebraker：我大概三年前去 Amazon 做过一次演讲，当时我把我认为他们做错的地方全都讲了一遍。
我觉得 Amazon 的问题在于，他们同时支持大概 15 种不同的数据库系统，而这大概多了 12 种。
我觉得这和他们自己的文化有关。我当时就跟他们说，你们支持的数据库种类太多了。但到现在为止，他们也没有决定淘汰任何一种。
主持人：为什么你觉得 15 种应该缩到 3 种？
Mike Stonebraker：因为他们支持图数据库，而大家其实早就知道，图数据库几乎从来都不是性能最优的方案。
如果你喜欢图那种节点和边的用户界面，没问题。你完全可以在关系型数据库上面加一层，把这种用户模型提供给你。
他们现在很多数据库系统，其实都有别的数据库在做同样的事，而且做得更好。所以结论就是，那些性能不够好、市场规模又不足以支撑维护成本的数据库，都应该被淘汰。
主持人：你一直以学术界的身份，对整个行业产生了非常大的影响。我有一个问题一直很好奇：你为什么不直接去工业界工作？比如去 AWS 之类的公司，做一个资深的 distinguished engineer，不是也一样能施加影响吗？为什么你更喜欢待在学术界，用现在这种方式发挥作用？
Mike Stonebraker：因为那样你就会有老板。你会被公司的规则束缚，发表论文会受限制，去会议上演讲会受限制，连去研究竞争对手在做什么也会受限制，因为很多东西公司不会愿意让你对外谈，尤其不会愿意让你去碰竞争对手不想公开的事。
不过更重要的是，我真的很喜欢待在创业公司里。Postgres 的商业版后来被 Informix 收购之后，我曾经在 Informix 兼职工作。那是一家两千人的公司，我完全感觉不到自己能带来什么变化，因为那里充满了官僚气，基本上总裁想怎样就怎样。
所以我觉得我大概不适合那种环境。我不擅长搞办公室政治，也不擅长和那些我觉得不聪明的人打交道。所以归根结底，我和大公司确实有点合不来。
主持人：我想聊聊 DBOS。我觉得这是个很有意思的技术模型。你能不能解释一下，DBOS 到底是什么？
Mike Stonebraker：这个学术项目大概是 2019 年、2020 年左右开始的。它的缘起，和 Matei Zaharia 有很大关系。他当时既是斯坦福的教授，也是 Databricks 的联合创始人，还是 Spark 最早的作者。
他说，Databricks 当时本质上是在云上跑用户的 Spark 作业。任何一个时刻，他们都可能在同时调度上百万个 Spark 任务。所以他们必须写一个能够在百万规模上决定“下一个该跑谁”的调度器。
他说，他们试过操作系统领域的人写的各种调度器，但都扩展不上去。最后他们把所有调度数据都放进了 Postgres 数据库里，本质上是由一个 Postgres 应用来做调度。
这件事一下子就点醒了我们。因为归根结底，操作系统里大多数事情，本质上都是在大规模地管理数据。而这类事情，本来就应该用数据库技术来做。所以我们的想法就变成了：为什么不干脆把 Linux 至少上半部分，用数据库系统替换掉？
这就是那个学术项目最初的核心。我们在 2020 年代初，和伯克利、斯坦福一起做这件事，结果非常成功，清楚地证明了这条路是能走通的。
在这个过程中，斯坦福那边还给 JavaScript 做了一层扩展，因为你总得有一个编程环境，能和底层实现通信。如果你上面跑的是某种编程语言，下面承载它的“操作系统”本质上又是一个数据库，那最自然的做法，就是把所有状态都放进数据库里。他们也正是这么做的。
于是我们手里就同时有了一个新的编程语言模型，和一个新的操作系统模型。接下来很自然的问题就是，能不能把它做成一家公司？后来我们去找风投，几乎所有人的回答都一样：如果你们觉得自己能替代 Linux，那就是在做梦。不过，你们这套编程语言的东西倒是挺有意思。
因为我们实际上做的是一种 JavaScript 扩展，它可以让任意程序天然拥有数据库系统的很多优点。比如状态是持久化的，可以有事务，失败之后可以自动 failover，等等，都是那类非常好用的能力。所以我们在 2023 年拿到了融资，成立了 DBOS 公司。项目一直就叫这个名字，所以公司也沿用了这个名字。不过本质上，我们做的其实已经更接近编程语言业务了。
现在 DBOS 提供了一套 TypeScript、一套 Java、一套 Go 和一套 Python，它们基本是无缝的。你写出来看起来就像普通原生程序一样。
在云时代，几乎所有因素都在推动你把应用组织成 workflow。所以我们决定，直接支持工作流系统。DBOS 在这四种语言里提供的 workflow 模型里，每一步，也就是每个小的 micro app，无论你怎么叫它，都是事务性的。整个 workflow 是持久化的，也就是说一旦某一步完成了，它不会被忘掉。
而且很明显，如果市场有这个需求，我们也可以把整个 workflow 做成原子性的。也就是说，整个流程要么完整执行完，要么看起来就像从来没发生过。所以它有很多非常好的性质，而且速度比现有竞品快得多，用起来也容易得多。公司现在就在这个方向上持续卖产品和做创新。
说白了，就是你要把应用的状态做成持久化，那就把它放进数据库；然后再想办法把它做快。我觉得他们现在的商业模式，和我们前面聊的也很一致，就是先把最底层、最直接使用这些东西的程序员吸引进来。
我们一直在做的事情就是：去问这些一线程序员，你们缺什么，我们还没有什么；然后尽快把这些能力补上，再说服他们来试。我们在创业公司这边已经做得非常成功了，因为这些公司只想选最好的东西。现在我们也开始慢慢打进大公司。
这是一个很有意思的市场。到目前为止，大概三分之二的客户都在做 agentic AI。也就是说，他们有一个大语言模型，外面再包一层各种组件，给它补充更多信号。
而目前大多数 agentic AI，其实还是只读型的。比如你要预测 Ryan 会不会是一个好客户，那么系统只是跑一堆逻辑，最后产出一个结果交给别人。它本质上是 read-only，并不会真的去修改 Ryan 的信用评分之类的东西。
但我觉得很快，整个世界都会转向让 agent 去做 read-write 的应用。一旦到了那一步，这类系统就会变得非常“数据库化”，而 DBOS 恰恰非常擅长处理这种东西。
比如说，你想写一个 agent，或者两个 agent，让它们把我账户里的 100 美元转到你账户里。那它们就必须先扣掉我的余额，再给你的余额加上 100，而且两个 agent 必须就“提交”这件事达成一致，否则就得把一切回滚。
换句话说，这个 workflow 必须是我前面说的 atomic，也就是要么全部发生，要么看起来从未发生。
所以我觉得，这个市场里的需求接下来还会继续升级，大家会越来越希望这些系统不仅能读，还能写。我认为这对整个市场是利好，对 DBOS 也是利好。
主持人：那现在市场上提供给应用开发者的这个产品，和最初那个研究项目已经不太一样了。最初那个项目是真的打算把操作系统内部的核心状态都替换成数据库。我得说，这真的很酷。我以前从来没想过，操作系统所有状态都能放进数据库里。不过这里面总该有些代价吧？
Mike Stonebraker：其实没有什么明显的代价。一个构建在 DBMS 之上的文件系统，比 Linux 文件系统更快。调度引擎的性能，也能和其他调度引擎打平。你还可以让所有东西都具备 failover 能力，也就是说，你几乎不用再额外做什么，就能得到高可用。
所以答案是，基本没什么缺点。
主持人：那 Linux 为什么不把这套东西吸收进去，自己升级掉呢？
Mike Stonebraker：理论上他们应该这么做。换句话说，底下那些设备驱动之类的脏活累活当然还是应该保留，因为那部分东西太多了，也没人想重写。但除此之外，其他部分都应该被数据库式实现替代。
主持人：你跟 Linux 圈子的人提过这件事吗？他们通常是什么反应？
Mike Stonebraker：在当年的学术项目阶段，只要我把这个想法讲给操作系统领域的人听，他们就会非常有威胁感，觉得这是数据库那帮人要来抢地盘了。
编程语言领域的人也差不多。他们也会觉得，怎么，你现在是说编程环境的 runtime 也该用数据库来实现？
主持人：这个很有意思。如果它在技术上真的是对的，那也许迟早会接管掉现有方案。
Mike Stonebraker：Java 花了 10 年才被广泛接受。我只是觉得，这种事情的时间常数本来就很大。
主持人：我们前面聊了很多数据库的过去。我也很好奇，你怎么看数据库领域那些还没解决的问题，以及未来会是什么样子？
Mike Stonebraker：这里我想讲两件事。第一件是，和其他人一样，大概三年前，我们开始研究大语言模型到底适合做什么。
我们一直在尝试把现在所谓的 text-to-SQL 用到真实世界的数据库上，尤其是真实世界的数据仓库。我们已经在四个真实生产环境的数据仓库上测试过这项技术。我们拿到了这些系统里真实的工作负载，也就是实际用户在系统里跑过的查询，然后再反向还原出与这些 SQL 对应的自然语言描述。
所以我们手里现在有四套 benchmark，每套都同时包含文本和 SQL。
主持人：你说的 text-to-SQL，是指人类用自然语言去提示模型吗？比如我直接用英文说一句话？
Mike Stonebraker：对，比如“把所有四岁以上的人找出来”，或者“告诉我 MIT 所有拿过图灵奖的教授”。按这个说法，大语言模型应该很擅长做这种事。
现在公开的 text-to-SQL benchmark 里，有一个叫 Spider，另一个叫 Bird。最好的大语言模型系统在这些 benchmark 上表现其实还不错，准确率大概能到 80% 甚至更高。算不上超人类，但已经相当不错了，已经到了你会认真考虑拿来用的程度。现在排行榜上的成绩差不多是 85% 的准确率。也就是说，你会觉得它可能还没完全 ready for prime time，但看上去已经很接近了。
但在我们的 benchmark 上，大语言模型的准确率是 0%。如果你再给它加上 RAG 之类各种增强技巧，准确率能到 10%。如果你在 prompt 里直接把 from clause 给它，也就是把实际要访问的表、实际要做的 join 条件全都告诉它，那准确率大概能到 35%。
所以，这项技术按“能不能上生产”这个标准来看，还完全不够格，而且短时间内都看不到真正能上生产的可能，甚至可能永远都到不了那一步。
主持人：差别到底出在哪里？
Mike Stonebraker：第一，数据仓库里的数据并不在大模型的训练语料里。大语言模型基本是拿公开语料训练出来的，而数据仓库里的真实业务数据根本不在里面。有一句老话说得很对：如果模型以前没见过这些数据，至少没反复见过几次，那它基本不可能把它正确“吐”出来。这是第一点。
第二，Spider 和 Bird 这类 benchmark 里的查询复杂度，大概也就是 10 到 20 行 SQL。但真实世界的数据仓库里，SQL 往往是 100 行起步，复杂度根本不是一个量级。
第三，Spider 和 Bird 的 schema 很干净。表名都很直观，列名也很直观，没有冗余。但数据仓库不是这样。数据仓库里经常到处都是物化视图，这意味着大量冗余；列名也经常是那种带下划线、缩写一堆、看起来根本猜不出含义的命名方式，完全不直观。
这会让问题变得困难得多。再加上，真实系统里还有大量非常“本地化”的、非常特殊的数据。比如 MIT 有个 “J-term”，指的是一月份一个月的学期。这并不是 MIT 独有，但也绝不是那种足够常见、足够普及、能出现在训练语料里的概念。
所以，数据不在训练集里，查询更复杂，schema 又是一团乱麻，再加上一堆系统特有的数据，这几件事叠在一起，就让这套东西根本跑不起来。而且我知道的每一个数据仓库，基本都符合这些特征。所以我的判断是，这项技术现在不行，短期内也不会行。
主持人：那你们现在怎么做？
Mike Stonebraker：首先，我们把自己的 benchmark 发出来了，叫 Beaver。它是那四个真实数据仓库做过匿名化和抽象化处理之后形成的版本。所以，如果有人真觉得自己特别擅长做 text-to-SQL，那就来跑一个真正像样的 benchmark，不要再拿那些“假的” benchmark 自我感觉良好。
第二，结合我刚才说的这些问题，如果你没有 join 条件，没有 from 子句，那基本就已经没戏了。更进一步，如果你不能把一个复杂查询拆成更简单的几部分，你也还是没戏。
所以这让我觉得，真正合理的做法是，把检索系统拿到的输入先变成更简单的片段，而且这些片段里要明确包含 from 子句和 join 条件。这是第一点。
第二点是，一旦你要同时跟两个不同的结构化数据库打交道，比如一个数据仓库再加一个 CRM 系统，那在我看来，用大模型去做结构化数据之间的 join，就是个馊主意。你最好还是把它们保留成表，用 SQL 去做 join，这样靠谱得多。
所以我们现在的思路是，尽量把一切都变成表。比如我们现在在和德国慕尼黑市交通部门合作，他们有六个全职员工，专门回复市民投诉和咨询。问题五花八门，比如“为什么我家门口那个路口，绿灯时间不够我走过去？”“为什么有轨电车停站时间不够我上车？”“为什么这趟电车一小时才来一班？”全是这种问题。
而他们背后的数据来源非常杂。电车时刻表是 SQL，红绿灯时序是 SQL，路口信息是 CAD，德国联邦层面的交通法规是文本，慕尼黑市自己的法规也是文本。也就是说，你得把 SQL、SQL、CAD、文本、文本，这几类东西做关联。
我们的思路就是，把它们全都转成 SQL，或者说全都转成表，再用一种本质上接近查询优化器的方式去做 join。这就是我们现在在做的事情。我相信别人会有别的思路，但我觉得这个方向非常有潜力，因为大家真的非常想把这件事做成。这是第一件事。
第二件事，是我们前面聊过的 agentic AI。只要它从只读走向可读可写，它立刻就会变成一个分布式数据库问题。你需要原子性、一致性，所有这些老问题都会重新回来。我觉得这也是一个非常有意思的方向。所以现在我主要就在做这些事情。
主持人：在你们这个 benchmark 上，大模型现在是 0%。那人类大概能到多少？比如一个真的懂 SQL 的人，平均能做到什么水平？
Mike Stonebraker：只要你先把自然语言里的歧义消掉，一个熟悉 SQL、也看得懂 schema 的程序员，准确率会非常高。
主持人：比如 90% 以上？
Mike Stonebraker：对，至少是这个量级。
主持人：明白了。老实说，我还是有点惊讶，大模型在这种 benchmark 上居然会低成这样。也许等这期节目播出去之后，会有 Anthropic 那边的人联系你，说我们来试试看之类的。
Mike Stonebraker：我很愿意知道他们能做到什么程度。因为这对那些真想深入理解数据库的人来说，其实是个很好的机会。
主持人：如果有人想系统学习数据库，你会推荐什么技术书或者论文材料？
Mike Stonebraker：我和 Joe Hellerstein 出过一本“红皮书”，名字就叫 Readings in Database Systems。虽然现在已经是八年前的书了，但如果你想看八年前以及更早那些经典材料，我觉得它仍然是一套非常好的阅读入口。再往后的话，就去看数据库领域后来那些比较重要、比较流行的论文。
主持人：如果你能回到刚毕业的时候，带着今天的认知给自己一些建议，你会说什么？
Mike Stonebraker：当年我刚到伯克利任教时，几乎没多想，就说那我们来写一个数据库系统吧。可那时候我们对数据库几乎一无所知，对实现也一无所知，编程能力也不像 Bill Joy 那样强。所以，一上来就做这么疯狂的事，其实本身就非常疯狂。
但人就是这样，先狠狠干，边做边学，边学边把事情做出来。所以我觉得答案就是，要跳出框框去想，要敢想一些疯狂的念头，然后真的去做。
不过对我来说，现在更值得问的问题其实是：如果你今天才刚开始，你会选什么专业？
因为我觉得，计算机科学未来很可能不再是一个增长型行业。我不确定我今天还会不会建议 18 岁的人去学计算机。
医疗保健和各种建筑、维修这类工种，看起来都还是相对安全的选择；其他很多方向，风险都大得多。
当然，如果你已经快拿到 PhD，正在考虑接下来怎么办，那事情就简单多了。去拿你能拿到的最有声望的工作，找一个愿意带你的导师，然后挑一个不是顺着潮流走的方向。比如我们现在做的这个 Rubicon，就绝对不是顺着主流在跑。所以，去找一个不随大流的方向，想办法把它做成。
我和我太太以前都跟孩子说过一句话：“去追随你的热情，钱总会自己解决。”但说实话，我一点都不信这句话。不过我觉得，你还是只能这么跟孩子说，跟孙子也只能这么说。
主持人：如果你自己并不相信这句话，为什么还要这么说？
Mike Stonebraker：我太太就是个很好的例子。她本科是计算机科学，硕士也是计算机科学，但她其实真正想做的是老师，中小学老师。可她父母当时跟她说，这不行，收入太低了。
我觉得她从那以后，一直都对这个决定有遗憾。她并不是真的热爱计算机科学，那对她来说只是个谋生手段。
所以我觉得，还是应该去找一件你真正有热情的事。这样至少你不会挨饿。你可能不会赚很多钱，但大概率会比做一件自己根本没热情的事过得更开心。
因为我认识很多人，他们把工作纯粹当成工作，真正的生活只发生在下午 5 点到第二天早上 8 点之间。我完全不是这种感觉。我是真的很喜欢我在做的事。无论我赚很多钱还是没赚很多钱，这一点都不会变。
原视频链接：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。