83岁图灵奖得主炮轰科技巨头：大模型真实测试零分，MapReduce是场灾难

近年来数据库领域盛行的几大主流观点，在迈克·斯通布雷克面前总会遭遇强力阻击。

当你宣称大模型将颠覆一切时，他会反驳说团队已在四个真实企业数据仓库中验证，当前最热门的Text-to-SQL技术在他们设定的基准测试中得分为零。若提及Hadoop与MapReduce曾开创纪元，他会直言不讳地指出这只是谷歌犯下的低级错误。即便你将他缔造的Postgres描绘为无所不能的万能方案，他也绝不会附和这种行业共识。

这绝非一场温和的数据库历史回顾。

Ryan Peterman的播客节目迎来了图灵奖得主、Postgres之父Mike Stonebraker。两人从1970年代Ingres的诞生谈起，聊到Oracle当年的销售策略，Postgres为何设计可扩展类型系统，查询优化器为何至今仍是数据库最难攻克的堡垒，也谈到他当下最关心的两大命题：

大语言模型能否真正将自然语言转化为生产级SQL？

当智能体开始读写真实世界，数据库系统是否会重返舞台中心？

这位年过八旬的数据库老兵，他批判的许多事物正以新面貌重现江湖。人们重新迷恋通用平台，迷信单一系统通吃所有场景，相信只要模型足够强大就能抹平结构化数据的复杂度，宁可牺牲正确性也要先跑出速度和规模。Stonebraker几乎将这些流行信条逐一拆解，强调数据库世界从未如此运作。

“甲骨文靠欺骗客户赢得市场”

主持人：今天我们邀请到迈克·斯通布雷克（Mike Stonebraker）。作为图灵奖得主，他因对Postgres等数据库系统的开创性贡献而享誉业界。首先想请教Postgres的起源故事。您是如何踏入数据库系统构建这个领域的？

Mike Stonebraker：博士毕业那年，我很幸运地获得了伯克利大学的教职。当时我很清楚必须开辟新的研究方向——我博士期间的研究课题，无论在当时还是现在，都看不到什么前景。若能被一位高明的导师收入麾下，便能占得先机。幸运的是，至今仍健在且精神矍铄的尤金·王（Gene Wong）收我为徒，他说：“我们一起做点有意思的事吧。”

那是1971年，恰是泰德·科德（Ted Codd）在《美国计算机学会通讯》发表开创性论文的次年。尤金·王说：“我们来研究数据库领域吧。”当时市面上的竞争者是一个叫CODASYL的方案，你可能太年轻都没听说过。那是个底层、如意大利面般纠缠的网络模型，查询需顺着指针路径摸索前行。另一替代方案是IBM提出的IMS层次模型，这东西现在还在用。它将数据组织成树状结构。

即便在当时，IBM也意识到树形结构不够通用，无法满足多数人的需求。于是他们东拼西凑，硬是将其改造成受限的网络结构。明眼人一看便知这是个拙劣的补丁。

而CODASYL提案也存在致命缺陷。除过于底层且极难调试外，还有个毛病：一旦所谓的“数据模式”发生任何变动，你基本得推倒重来，因为它完全焊死在物理层。相比之下，泰德·科德的理论简直无懈可击。

因此尤金说：“我们也来构建这样的系统。这显然是下一步该尝试的方向。”于是1972年，当我还是伯克利助理教授时，我们启动了Ingres项目。如你所知，助理教授有五年时间证明实力，要么被解雇，要么获终身教职。Ingres就是我拿到终身教职的敲门砖，这在1976年如愿以偿。这就是一切的开端。

后续发展又属机缘巧合。当时许多人构建的原型系统都带有“学生气”，即代码虽能跑，但交给他人根本无法运行。所以我们花费前一半精力做出可运行的雏形，又不知为何投入另一半精力将其打磨至真正稳定。因此加州大学版的Ingres具备真实可用性。随后几年，约一百多所大学开始使用它，因为Unix当时正在崛起，而这是一个能在Unix上运行的免费数据库系统。它在学术界极受欢迎。

我们开始频繁接待来自伯克利的访客，他们会问：“哇，这系统看起来很酷。你们运行过的最大Ingres应用是什么？”我们不得不尴尬地回答：“规模不大。”这一点在亚利桑那州立大学考虑用Ingres管理4万名学生学籍数据时暴露无遗。他们可以克服从贝尔实验室获取无支持操作系统的困难，也能克服运行我们这群伯克利家伙搞出来的无支持数据库系统的困难。但当发现Unix上没有COBOL语言支持时，项目彻底泡汤，因为他们完全依赖COBOL。无支持操作系统、无支持数据库系统，再加上没有COBOL，注定了我们的边缘化命运。

显然，摆脱困境的唯一出路就是创办公司。因此1980年，我们拿到了当时那种形式的风投，创立Ingres公司，将Ingres移植到DEC的VMS上——那是个真正的操作系统。我们拥有了一家能为Ingres提供支持的真正公司，这也是我们商业征程的起点。

主持人：我了解到Ingres当时在与拉里·埃里森（Larry Ellison）的Oracle竞争。显然你们的产品更优秀，但你们仍在某些层面展开竞争。他们是如何竞争的？

Mike Stonebraker：拉里·埃里森是个顶级推销员。当时他能将“现在时”与“将来时”混为一谈，说白了就是向客户撒谎。他会将根本不能用的东西发货，让首批客户帮他调试。我认为他使用了一些极其见不得光的商业手段。对客户撒谎，我认为是违背良知的。

举个例子，数据库里有个功能叫“参照完整性”，意思是若你解雇某部门的最后一名员工，是否要连带删除该部门，还是留下幽灵部门？就是这类问题。Ingres公司实现了参照完整性。而Oracle公司只是印了两页手册，列着大家都认可的“参照完整性定义”，然后在底部用小字标注：“尚未实现”。

主持人：很有意思。我曾采访过一位在Sun Microsystems工作过的人，他对拉里·埃里森也有类似评价，觉得他行事不太光彩。看来这是共识。我还看到你在其他地方提到，当Oracle收购MySQL时，大家都感到恐慌，纷纷转向Postgres。这也是Postgres取代MySQL成为首选开源关系型数据库的契机。

您创造了Ingres，其中包含许多技术创新，使其优于当时的产品，但最终它仍退出历史舞台，您又开发了Postgres。Ingres做不到什么，而Postgres做到了？

Mike Stonebraker：最初指导我们的大方向，源于学术版Ingres的初衷：我们要为隔壁的Pravin Varaiya教授想要的地理信息系统（GIS）提供支持。为支持GIS系统，你需要点、线、多边形、线组这类数据。显然Ingres做不到，因为我们内置的数据类型都是标准类型：整数、浮点数、文本、字符串。你无法在这些基础之上高效支持GIS数据类型。因此作为GIS系统的底层，学术版Ingres是彻底失败的。这件事一直留在我们脑海里。

另一件事虽在时间顺序上有些错位，但能很好说明问题。约在1985年，ANSI刚提出关系型数据库的日期和时间标准。商业版Ingres使用标准公历实现了日期和时间。当时我既参与商业版Ingres工作，同时也是加州大学教授。我接到一位Ingres客户的电话，他说：“你们把日期和时间实现错了。”我困惑不解：“啊？我们实现了公历，可以做减法。除二月和闰年外，每月30或31天。日期减法完全符合预期啊。”

但他告诉我，在他的专业领域，他要的根本不是这个。他在处理债券金融工具，无论一个月多长，债券每月产生的利息都相同。他有买入和卖出债券的日期。他想做减法，乘以票面利率，然后说：“这就是我们付给你的利息。”但当然，在他那里的减法定义是：3月15日减2月15日等于30天，因为这就是他那个日历的定义。

所以他不得不把两个日期提取到用户代码中，在代码里做减法，再把结果放回去，这让他的效率降低了两到三倍。他问：“为什么我不能直接用我想要的逻辑，重载你们的减法定义呢？”当然，在Ingres里，这都是写死在底层代码里的。

问题在于，这是一个你需要“债券时间”的场景，就像你需要点、线和多边形一样。Postgres在架构之初就设计了可扩展的类型系统。你可以拥有任何想要的数据类型，而且效率极高。这就是Postgres的核心要义：它具备极高的灵活性。在商业数据处理中，大多数人对标准数据类型很满意，但关系型数据库开始渗透到各种其他领域。所谓的抽象数据类型或存储过程具有极大适用性，所以这成了Postgres最大的杀手锏。

我们还支持了当时人工智能领域研究者想要的“继承”功能。我们甚至支持了“时间旅行（历史数据查询）”。不过那部分的实现简直烂透了，后来就被移除了。总之，Postgres里有大量非常巧妙的设计。

“我受不了平庸之辈”

主持人：你提到想招募卓越的软件工程师，而且我记得你以前说过，找这样的人毫不费力。在招聘时，你是如何识别这些顶尖人才的？

Mike Stonebraker：通常这很明显。我对事情的难度有很好的直觉。如果他们在学校里完成的工作量，是我认为合理预期工作量的三倍，那他们就是不可思议的天才。

主持人：反过来说，你有一句很有意思的话，我记下来了。你说：“我受不了那些不够聪明的人。和他们交流太费劲了。”你是如何识别那些平庸之辈的？

Mike Stonebraker：这其实非常简单。你和他们聊一聊，很快就能试探出他们到底聪不聪明。“你的硕士论文写的是什么？你具体做了什么？它是怎么运作的？你是如何处理错误情况的？你开了多少个进程？你为什么不用线程？”你只需要问他们深度的技术问题。

主持人：你曾做过一次演讲，好像还有一篇论文，提出这样一个观点：万金油式（one-size-fits-all）的数据库系统并不是最优解，试图适应一切的系统实际上什么都适应不好。你真正需要的是针对特定需求量身定制的数据库解决方案。你认为当今市面上有哪些数据库产品属于这种“万金油”？

Mike Stonebraker：在2004年我写那篇论文时，我们有个学术项目后来演变成了Streambase。一个流处理引擎看起来和关系型数据库毫无相似之处。我们还有了用于数据仓库的列式存储的初步构想，后来被Vertica发扬光大，它看起来和行式存储也完全不同。所以这里有三个截然不同的实现，它们彼此毫无相似之处，而且在各自的领域，它们都比其他系统快上一个数量级。很明显，通过这三个例子可以看出，当你运行一个并非为你特定场景架构的数据库系统时，你就要牺牲一个数量级的性能。

我认为这在今天依然成立。ClickHouse是个列存数据库。Pinecone在基于文本的向量处理上，比用户自定义类型要快得多。我认为情况依然如此，而且在多个底层实现之上套用一个通用的解析器，并没有什么难度。只是Postgres至今选择不这么做。他们没有实现列式存储，所以我认为他们在大型数据仓库领域缺乏竞争力。他们也没有多节点支持。同样，对于拥有大型数据仓库的人来说，这是入场券。所以我认为这个观点今天依然像过去一样正确。

不过有一点也是事实：如果你想快速起步，你遇到了一个数据库问题，答案就是选择Postgres。它有庞大的编程社区，各种数据类型的实现，它是免费的，而且你很容易招到懂Postgres的人来推进工作。作为满足最低通用需求的选项，它是极好的。只要你不是想实现每秒一百万次的事务，它就完全没问题。只要你不是想支撑一个PB级的数据仓库，它就能运转良好。在低端场景，它绝对是正确的“万金油”。但在高端场景，这套就行不通了。

主持人：GPU会为数据库优化提供新的机遇吗？

Mike Stonebraker：也许会，但我认为巨大的挑战在于GPU是SIMD（单指令多数据流）架构，而这简直是索引的死穴。只要索引是正确的解决方案，GPU可能就不是个好主意。此外，你必须在架构上确保来自存储的带宽不会成为瓶颈。如果GPU只是CPU的一个附加组件，那么连接GPU和CPU的总线往往就会成为瓶颈。

主持人：你能解释一下为什么在使用SIMD时，索引的效果会大打折扣吗？

Mike Stonebraker：假设我在查找瑞恩的薪水，而且我有一个B树索引。你走到B树的根节点，找到包含瑞恩所在区间的分割点。你顺着指针往下走。这绝对是一次内存访问。然后你再重复这个过程，大概要重复三四次。这个过程是无法很好地并行化的。所以答案是：索引无法很好地并行化。

“谷歌当年干的蠢事，不止MapReduce一件”

主持人：你提到了B树。当你们最初实现第一版Ingres时，所有这些都是你们手写的吗？因为我想象当时大概没有什么现成的B树代码库之类的东西。

Mike Stonebraker：是的，最初版本的Ingres全都是从零开始手写的。

主持人：那个实现过程中最难的部分是什么？

Mike Stonebraker：查询优化器。

主持人：为什么它那么难？

Mike Stonebraker：它非常棘手。它在算法上实在太难了。如果你去问任何一位资深的数据库程序员最难的部分是什么，他们至今依然会说是优化器。

主持人：MapReduce大概在2000年代初问世，它席卷了整个数据领域。人们对它印象深刻，觉得谷歌真的知道自己在干什么，这是有史以来最棒的发明。但当我查阅文献以及你当时的看法时，似乎你非常不认同。你为什么如此不看好MapReduce？

Mike Stonebraker：我认为当时有很多不太懂行的人说：“谷歌真的很聪明。他们肯定知道自己在干什么，所以他们说什么我们就做什么。”

于是他们开始搞Hadoop。但是Hadoop的效率低得令人发指。当时，大卫·德威特（David DeWitt）和其他参与了我们2011年论文的人，我们非常了解分布式数据库，并且明白用一个分布式数据库系统就能把Hadoop打得落花流水，这基本上就是那篇2011年论文的核心观点。当然，事实也确实如此。

但谷歌干的蠢事可不止这一件。谷歌当时还认为，“最终一致性（eventual consistency）”是处理并发控制的正确方式。在那个时期，这是谷歌高层定下的基调。而所有的数据库专家都说：“你们简直疯了。”因为它只能解决一种非常特定类型的问题，而那种问题在实际应用中极少出现。

主持人：他们为什么要追求最终一致性？

Mike Stonebraker：他们的设想是，你在东海岸有一个数据库，在西海岸也有一个数据库，它们互为副本。你希望它们保持一致。如果你说：“我要执行一个事务，我要把西海岸仓库里的小商品数量减一”，那么在提交这个事务之前，你需要去更新东海岸的仓库。这需要花费一次消息往返的代价来更新它。然后为了确保万无一失，还需要另一次往返消息来确认两边都正确地提交了。执行分布式提交是非常昂贵的，现在依然如此。

所以他们的想法是，你在西海岸执行更新，把小商品减一，然后你只是异步发送一条消息，且不放在事务里，这样“最终”东海岸的仓库也会减一。与此同时，如果你在东海岸，你把食品减一。你发送一条异步消息。最终，西海岸会收到它，最终一切都会尘埃落定。

如果你的系统允许库存出现负数，那么当东海岸和西海岸的人同时卖出最后一件商品时，最终仓库的状态就会变成负一，然后就会有人收不到他们的商品。如果你像亚马逊那样，允许标明“通常在24小时内发货”，那也许你可以超卖，但大多数企业做不到这一点。所以最终一致性根本行不通。

我们刚才花了很长时间聊参照完整性。在销售系统中，参照完整性就是一个完整性约束：库存必须大于负一。而最终一致性在这里就行不通了。谷歌的杰夫·迪恩（Jeff Dean）最终想明白了这一点，所以当他们开发Spanner时，Spanner用回了传统的事务系统，谷歌也彻底放弃了最终一致性，彻底放弃了MapReduce。

主持人：所以这本质上是用正确性来换取性能。也就是性能与数据完整性之间的权衡。如果你不在乎你的数据，那你才愿意承受糟糕的结果。在谷歌做这些你认为错得离谱的事情时，你和他们的团队交流过吗？

Mike Stonebraker：在2011年那篇论文发表之前，我们和他们谈过，提议说：“我们为什么不合作搞点东西呢？”但他们不感兴趣。所以他们拒绝了。

主持人：你有没有看到其他大型科技公司的数据库或数据库解决方案中，也有你强烈不认同的例子？比如亚马逊或Facebook。

Mike Stonebraker：大概三年前我在亚马逊做过一次演讲，我告诉了他们所有我认为他们做错的地方。我认为亚马逊的问题在于他们同时在支持15种不同的数据库系统，这大概多出了12种。他们有自己的企业文化，我说：“你们支持的数据库系统太多了。”但到目前为止，他们还没有选择淘汰其中的任何一个。

主持人：为什么你觉得15种应该缩减到3种？

Mike Stonebraker：他们在支持一个基于图的数据库系统，而业界早就达成共识，图数据库系统几乎从来都不是性能最优的选择。如果你喜欢那种处理节点和边缘的用户界面，没问题。你可以在关系型数据库系统之上加一层，给你提供那种用户模型。

他们的大多数数据库系统，总能找到另一个在特定领域做得比它更好的系统。我的答案是，如果一个数据库系统在一个足够大的市场里没有性能优势，无法证明其维护成本的合理性，你就应该把它淘汰掉。

主持人：你从学术界对工业界产生了深远的影响，我有一个想法：为什么不直接在工业界工作呢？为什么你更倾向于留在学术界，以你现在的方式施加影响，而不是直接去AWS之类的公司谋个差事，做个极其杰出的工程师？

Mike Stonebraker：因为那意味着你会有个老板。会有公司规章制度，限制你发表论文，限制你去参加会议发表演讲，限制你去刺探竞争对手那些他们不愿向同行透露的底牌。但最主要的是，我真的非常喜欢置身于初创公司中。在商业版的Postgres被Informix收购后，我曾在Informix兼职工作过，那是一家有2000人的公司，我感觉自己根本发挥不了什么作用，因为那里官僚主义严重，总裁想要什么，他就能得到什么。我觉得我天生不适合搞办公室政治。我做不好那个，而且我很难跟那些我认为愚蠢的人打交道。所以在大公司里，我会遇到很多麻烦。

对标Linux的DBOS

主持人：我想聊聊DBOS。我觉得这是一个非常有趣的技术模型。你能解释一下DBOS是什么吗？

Mike Stonebraker：我们大概在2019年、2020年左右启动了这个学术项目。当时的核心背景是，斯坦福大学的教职员工、也是Databricks的创始人之一，同时也是Spark最初创造者的马泰·扎哈里亚（Matei Zaharia）提出了一些痛点。他说，当时Databricks基本上是在云端运行人们的Spark任务。他说在任何给定时间，他们可能要调度一百万个Spark任务。所以必须编写一个调度器，来决定接下来运行谁，而且要达到百万级的规模。他说他们尝试了操作系统专家编写的所有调度器，但都无法支撑这种规模。

于是，我们把所有的调度数据都放进了一个Postgres数据库里，基本上就是用一个Postgres应用程序来做调度。然后我们突然恍然大悟：操作系统里绝大多数的工作，本质上都是在大规模地管理数据，而你本就应该用数据库技术来做这件事。那么，我们为什么不干脆用一个数据库系统来替换掉Linux至少上半部分的功能呢？

这就是那个学术项目的核心思想。我们在2020年代初在伯克利和斯坦福研究了这个项目，而且非常成功。它显然是行得通的。在这个过程中，斯坦福的团队为JavaScript编写了一个扩展程序，因为你需要一个编程环境来与你的底层实现进行交互。如果你在做一种编程语言，并且运行在一个本质上是数据库的操作系统之上，那么最显而易见的做法，就是把所有的状态都存在数据库里。他们正是这么做的。所以我们拥有了创新的编程语言模型，以及创新的操作系统模型。

当然，接下来的想法就是，我们能创办一家公司吗？我们去和风险投资人谈，他们异口同声地说：“想取代Linux，你是在做梦。不过，你们那个编程语言的东西倒是很巧妙。”我们拥有的，相当于JavaScript的扩展，它能让任何程序都具备数据库系统的所有优秀特性。数据是持久化的。你可以使用事务。如果系统崩溃了，它会自动故障转移。全都是这些绝妙的特性。

所以我们在2023年拿到了融资，成立了公司，这就是DBOS公司。我们决定用这个名字，因为它一直都是这个项目的名字，但我们实际上做的是编程语言的生意。目前，DBOS拥有TypeScript版本、Java版本、Go版本和Python版本，它们几乎是无缝对接的。它跑起来就像是普通的程序一样。

在云端世界里，把你的应用程序构建成工作流是绝对的大势所趋。所以我们决定，我们要支持一个工作流系统，就这么简单。DBOS在这四种语言中支持的工作流，其各个步骤、各个微应用（不管你怎么称呼它们），都是具备事务性的。工作流是持久化的，所以一旦你完成了一个步骤，它就不会被遗忘。很明显，如果有市场需求，我们可以让工作流具备原子性，这意味着整个工作流要么全部完成，要么就像从未发生过一样。它拥有非常棒的特性，而且比竞争对手快得多，也容易使用得多。

公司目前正在这个领域进行销售和创新。核心理念是，当你把应用程序的状态放入数据库时，你想让它持久化，然后你再想办法让它跑得快。正像我们之前聊到的，他们的商业模式非常明确，就是去吸引基层程序员的兴趣。所以我们的策略一直是：“告诉我们，基层程序员们，你们需要什么我们还没有的东西，快速把它做出来，然后说服人们去尝试。”我们在吸引那些想要选择最佳方案的其他初创公司方面非常成功，而且我们也开始在大型企业中取得突破。

这是一个非常有趣的市场，我认为目前最关键的一点是，大概有三分之二的客户在做智能体AI（agentic AI），这意味着他们有一个大语言模型，周围环绕着一堆提供更多信号的组件。到目前为止，绝大多数的智能体AI都是只读的，意思是你想预测一下瑞恩会不会成为一个好客户。它只是运行一些数据，然后生成一个新结果交给某人。基本上是只读的，这意味着你并没有真正去更新瑞恩的信用评分。

我认为这个领域很快就会演变为：使用智能体来执行读写应用程序，而这将使它们变得非常“数据库化”。DBOS非常擅长处理这类事情。举个例子，如果你想写一个智能体，或者两个智能体，把100美元从我的账户转到你的账户。你需要从我的账户扣款，在你的账户加钱，这两个智能体必须同意提交，否则你就得把一切回滚。也就是说，工作流需要具备我所说的原子性，要么全部发生，要么就像从未发生过。我认为这个市场的需求会随着人们对读写操作的渴望而不断攀升。我认为这对市场是个好兆头，对DBOS也是个好兆头。

主持人：所以现在市场上提供给应用程序开发者的东西，和最初那个把操作系统内核替换成数据库的研究项目是不一样的。我明白了。这真的很酷。我从未想象过用一个数据库来替换操作系统的所有状态。这其中的权衡是什么？

Mike Stonebraker：写在数据库管理系统（DBMS）之上的文件系统，比Linux文件系统还要快。调度引擎与其他调度引擎相比也毫不逊色。你可以让一切都具备故障转移能力，所以你不需要做任何额外的工作就能获得高可用性。答案是，真的没有任何缺点。

主持人：那为什么Linux不吸收这项技术，用它来升级自己呢？

Mike Stonebraker：你当然希望他们会这么做。换句话说，你应该把所有那些设备驱动之类的杂七杂八的东西留在最底层，因为这类东西很多，也没人愿意去碰它们，然后用数据库实现来替换掉其他所有的东西。

主持人：你向Linux社区的人提过这件事吗？他们通常是什么反应？

Mike Stonebraker：当年做学术项目的时候，如果我向操作系统专家提到这个，他们会感到极大的威胁，他们的反应是：“这是搞数据库的家伙想来抢地盘。”我觉得编程语言领域的人也是一样的反应：“实现编程环境运行时的最佳方式，竟然是使用数据库。”

主持人：这很有意思。我是说，如果它客观上是正确的，那它也许终将接管一切。

Mike Stonebraker：毕竟，Java也花了10年时间才被广泛接受。我认为这需要一个漫长的时间周期。

大模型得分0%？

主持人：我们聊了很多数据库的过去，我很好奇你对数据库领域未解之谜的看法，以及你认为未来会是什么样。

Mike Stonebraker：好的。我想谈两件不同的事情。第一件事是，和所有人一样，三年前我们开始研究大语言模型到底能干什么。我们一直试图让现在所谓的Text-to-SQL（自然语言转SQL）在真实的数据库中发挥作用，特别是在真实的生产级数据仓库中。

我们在四个不同的生产级数据仓库上测试了这项技术，我们获取了实际用户在系统中运行的真实工作负载，并让他们逆向工程出与该查询序列对应的自然语言文本。所以我们拥有了四个基准测试的文本和SQL对照数据。

主持人：当你说Text-to-SQL时，是指像人类用英语向模型发出提示词那样吗？

Mike Stonebraker：那些文本可能是：“告诉我麻省理工学院所有年龄超过四岁且获得过图灵奖的教授。”大语言模型据说很擅长这个。现有的Text-to-SQL基准测试，有一个叫Spider，另一个叫BIRD，最顶尖的LLM系统在这些基准测试上表现相当不错。准确率能达到80%甚至更高。虽然还没达到超人类的水平，但也相当不错了。你是会考虑使用它们的。目前的排行榜上大概有85%的准确率，已经很接近实用了。

主持人：你说它也许还没完全准备好投入实际应用，但看起来确实相当不错了。

Mike Stonebraker：然而，在我们的基准测试里，大语言模型的得分是0%。如果你用RAG（检索增强生成）和各种技巧来强化它们，准确率能提升到10%。如果你在提示词中直接给出FROM子句——换句话说，告诉它所有需要访问的实际表名，以及所有需要连接的JOIN条件——准确率能上升到大概35%。所以，这项技术的现状就是，它根本没有准备好投入实际应用，而且在很长一段时间内都不会，甚至可能永远都不会。

主持人：区别到底在哪儿？

Mike Stonebraker：第一，LLM是在公共语料库（the pile）上训练出来的。而数据仓库的数据并不在那个语料库里。有一句老话：如果你以前没有见过这些数据几次，你根本不可能把它吐出来。这是第一点。

第二，Spider和BIRD测试里的查询复杂度，大概也就是10到20行SQL代码。但在真实世界的数据仓库里，那是100行SQL代码。复杂度完全不在一个量级。

第三，Spider和BIRD里的数据模式（Schema）非常干净。表名是见名知意的。列名是见名知意的，而且没有重复。但在数据仓库里，人们到处都在用物化视图。这意味着存在数据冗余，而且列名经常是下划线、Z、大写字母等等乱七八糟的东西。它们根本不能见名知意。这让难度大大增加。

最后，他们还有各种极其特殊的数据。比如“J-term”在麻省理工学院是个很常见的词。它是指一月份的一个为期一个月的学期。这并非麻省理工独有，但也不是很普及。所以，它不在训练语料库里，包含极其特殊的数据，查询并不简单，而且数据模式一团糟。这些因素加在一起，让它根本无法工作。而我所知道的每一个数据仓库都是这副德行。我认为这项技术目前根本行不通，而且在短期内也别指望它能行得通。

主持人：那你该怎么办？

Mike Stonebraker：首先，我们发布了我们的基准测试。它叫Beaver，是这四个真实数据仓库的匿名化和抽象化版本。如果你觉得自己做Text-to-SQL真的很牛，那就来试试真实的基准测试，别玩那些假的。

第二，借用我刚才说的，如果你没有所有的JOIN条件，没有FROM子句，你就彻底完蛋了。更重要的是，如果你不把查询拆解成更简单的部分，你也会完蛋。这对我来说意味着，你需要给你的检索系统提供更简单的组件，其中包括FROM子句和JOIN条件。这是第一点。

第二，一旦你想同时与两个不同的结构化数据库对话，比如你的数据仓库和你的CRM系统，那在我看来，用LLM来做结构化数据的JOIN绝对是个馊主意。你最好还是让它们保持表的形式，然后在SQL里做JOIN。

我们的观点是，我们正在尝试把一切都变成表。我们正在和德国慕尼黑市的交通部合作，他们有六个全职人员专门回答市民的投诉和质询，问题大概是这种：“为什么我家旁边的十字路口，绿灯时间短得不够我走过去？”各种各样的问题。“为什么电车停靠的时间不够我上车？”“为什么电车一小时才来一趟？”

他们的数据库里，电车时刻表是SQL。红绿灯时序是SQL。十字路口的地图是CAD。德国联邦关于这些东西的法规是文本。慕尼黑市的法规也是文本。所以你得把SQL、SQL、CAD、文本和文本连接（JOIN）在一起。我们的观点是，把它们全都转换成SQL，全变成表，然后用一个类似查询优化器的东西来做JOIN。这就是我们正在研究的方向。我想其他人会有其他的思路，但我认为这是一个极其肥沃的领域，因为人们真的非常需要解决这个问题。这是第一件事。

第二件事，我们之前聊到了智能体AI（agentic AI）。一旦它涉及到读写操作，它就变成了一个分布式数据库问题，你会需要原子性、一致性等等所有这些特性。我认为这是一个非常有趣的领域。所以这基本上就是我现在正在研究的东西。

主持人：在那个目前得分是0%的基准测试上，人类能拿多少分？比如你找一个真正懂SQL的人，普通人类能得多少分？

Mike Stonebraker：一旦你消除了文本中的歧义，一个熟悉数据模式的资深SQL程序员能达到极高的准确率。

主持人：好的。大概至少能到90%之类的。哇，我真惊讶LLM在这种基准测试上得分这么低。也许这期节目播出去之后，某个在Anthropic工作的人会联系你，说：“咱们来试试……”

Mike Stonebraker：我很乐意看看结果，因为如果成了，那将是一个了不起的成功故事。

大模型得分0%？

主持人：对于那些想要深入理解数据库，并且正在寻找学习资料的人来说，有没有哪本书是你推荐的顶尖技术书籍，或者是文献中的经典论文？

Mike Stonebraker：乔·海勒斯坦（Joe Hellerstein）和我出版过一本被称为“红皮书”的书，叫《数据库系统读本》（Readings in Database Systems）。它现在已经出版八年了。我觉得它作为八年前的阅读材料是非常棒的，除此之外，可以去读读文献中那些广受欢迎的论文。

主持人：如果你能回到刚毕业的时候，带着你今天所知道的一切，你会给自己什么建议？

Mike Stonebraker：当年我刚在伯克利接下那份工作时，我们连想都没怎么想，就说：“咱们写个数据库系统吧。”我们对数据库一无所知，对底层实现一窍不通。我们也不像比尔·乔伊（Bill Joy，Sun的联合创始人）那样是编程高手。所以，一开始就去做那么疯狂的事情，真的是挺疯狂的。但你投入了精力，你让东西运转起来，你在这个过程中不断学习。所以答案是：跳出框架思考。敢于有疯狂的想法，并努力去实现它们。

对我来说，这根本不是什么显而易见的事。更好的问题是，如果你今天才刚起步，你会选择什么专业？因为我认为计算机科学在未来可能不再是一个朝阳产业了。我不太确定我还会不会建议18岁的年轻人们去主修计算机科学。我认为医疗保健和建筑行业是安稳的选择，而其他一切看起来风险都要大得多。

如果你即将拿到博士学位，正在犹豫该做什么，我觉得事情很简单。接受你能拿到的最有名望的工作，找一位愿意帮你的导师，然后选一个不随波逐流的领域。就像我们做的那个叫Rubicon的项目，绝对是不随波逐流的。选一个逆流而上的方向，然后努力让它大放异彩。

我和我妻子都曾说过：“追随你的热情。钱的问题总会迎刃而解的。”其实我骨子里根本不相信这句话，但我觉得你必须这么告诉你的孩子和孙子们。

主持人：如果你不相信这句话，那你为什么还要这么告诉他们？

Mike Stonebraker：我妻子就是个很好的例子。她有计算机科学的本科学位和硕士学位，但她真正想做的是一名中小学教师。她的父母说：“你不能去教书，那赚不到足够的钱。”我觉得从那以后，她一直都在后悔那个决定。她对搞计算机科学并没有什么热情；那对她来说只是个谋生的手艺。

所以我认为，找到你热爱的事业，你大概率不会饿死——你可能赚不到大钱，但我认为你会有很大的机会，比做一份你不热爱的工作要快乐得多。因为我认识的很多人，他们仅仅把工作看作是一份工作，认为真正的生活是下午5点下班后到第二天早上8点上班前的那段时间。我完全不这么想。我真的热爱我所做的一切。无论我赚不赚钱，这都无所谓。