圖靈獎得主：勸年輕人別學計算機，行業紅利正在消失

Mike Stonebraker 是 2014 年圖靈獎得主，他對數據庫系統的奠基性貢獻幾乎寫進了所有相關教科書。從 Ingres、Postgres，到 Vertica、VoltDB、SciDB，再到最近的 DBOS，每一個都是真正成就了諸多商業公司的工程系統。

最近他做客 Meta 資深工程師 Ryan Peterman 的播客，與其進行了一個小時的對話。他說話直接，不太客氣。聊到 Larry Ellison 時，他說那人“把現在時和將來時混為一談，本質上是在對客戶撒謊”；聊到 Google 當年力推的 MapReduce 和最終一致性，他說“那不是 Google 唯一一件愚蠢的事”；聊到亞馬遜同時維護著十五個數據庫系統，他說“多了十二個”；

（來源：Youtube）

他也表達了對如今 AI 的看法。在他看來，現在多數 agentic AI 還停在“只讀”，給一個客戶算個分、出個預測，并不真的去改數據庫里的字段。一旦 agent 開始做讀寫，比如兩個 agent 協作完成一筆轉賬，問題就立刻落回數據庫的老地盤：事務、一致性、原子性。

說到大模型寫 SQL，他甩出來幾個數字。在 Spider、Bird 這些公開 text－to－SQL 基準上，最好的模型已經能拿到 85％ 準確率，看起來差一步就能上生產。但 Stonebraker 團隊用四個真實生產數據倉庫做了一個新基準 Beaver，在這個基準上，大模型的準確率是 0；加上 RAG 也只到 10％；把 join 條件直接喂給模型，最多到 35％。同樣的任務，一個懂 schema 的 SQL 工程師能做到 90％ 以上。所以他的結論是：這項技術，至少在可見的未來，還不夠格進生產。

談及對年輕人的建議，他說如今已不太確定是否要推薦十八歲的小孩去主修計算機科學，“醫療和建筑業是穩妥的選擇”。

下面是這次對話的完整內容：

在伯克利，被一個懂門道的人帶進門

Peterman：我第一件想聊的事是 Postgres 是怎么起步的。我想從更早的地方開始，你最初是怎么進入數據庫這個領域的？

Stonebraker：我畢業之后很幸運被伯克利招了進去，但我心里清楚一件事：把博士時候做的東西繼續往下做，不會有什么前途。那時候和今天一樣，能找到一個懂門道的導師把你帶進門，你就比別人快一截。Gene Wong 把我收到他翼下，他現在還在干活。他說，咱倆一起搞點事情吧。

那是 1971 年，Ted Codd（關系數據庫理論奠基人）那篇開創性的論文發表在 CACM（《Communications of the ACM》，計算機領域的頂級刊物）上是 1970 年。Gene Wong 說，我們去研究下數據庫這塊。當時關系模型有兩個對手。一個叫 CODASYL 提案（1960 年代提出的網狀數據庫標準，把數據按“指針網”組織），你大概太年輕沒聽說過。它是個底層的、像意大利面一樣纏繞的網狀結構，要查一條數據得一路追指針。另一個是 IBM 的 IMS（Information Management System，IBM 的層次數據庫系統，今天還在賣），數據是樹形組織的。但 IBM 自己當時就承認樹不夠通用，解決不了很多人的問題，于是又加了一層補丁，把它變成一個受限的網狀結構，一看就是個糟糕的補丁。

CODASYL 那套問題一堆。層級太低，調試起來要命。它還有個性質：一旦你的 schema（數據結構定義）有任何變化，基本就得把所有東西扔了重來，因為它整個根扎在物理層面。而 Codd 那套東西完全說得通。所以 Gene 說，咱們就來造一個這樣的玩意兒吧，下一步顯然該試這個方向。1972 年他開始造 Ingres（INteractive GRaphics REtrieval System）的雛形，那時候我剛到伯克利當助理教授。

Peterman：Ingres 是怎么從一個原型走到真的能用的？

Stonebraker：美國大學里的助理教授一般有五年的考核期，要么熬到終身教職，要么走人。Ingres 就是我拿到終身教職的敲門磚，1976 年我拿到了。

那個年代很多人寫的原型都是“實驗室風”，自己機器上能跑，拿給別人就跑不動了。Ingres 我們先投入了第一個 90％ 讓它能跑起來，然后不知道為什么，又投入了下一個 90％ 讓它真正好用。所以伯克利版的 Ingres 是真能用的。接下來幾年大概有一百所大學開始跑它，因為 Unix 起來了，而 Ingres 是一套免費的、跑在 Unix 上的數據庫。它在學術圈相當流行。

我們在伯克利開始接待大量訪客，他們會說，這東西看起來真不錯，你們最大的 Ingres 應用是什么？我們只能說，其實不太大。

當亞利桑那州立大學考慮用 Ingres 跑他們四萬學生的學籍數據時，這個問題得到了充分的印證。他們要裝一個不被支持的操作系統（貝爾實驗室的 Unix），要跑一個不被支持的數據庫（伯克利這幫人搞的 Ingres），這兩條他們都能接受。但項目最后死在第三條上：Unix 上沒有 COBOL（一種主要用于商業數據處理的老牌編程語言），而他們是個 COBOL 的店。不被支持的操作系統、不被支持的數據庫，再加上沒 COBOL，我們就被判了死刑。

唯一的出路是開公司。1980 年我們拿到了那個年代意義上的風險投資，成立了 Ingres 公司，把 Ingres 移植到 DEC 公司（數字設備公司，當年的小型機巨頭）的 VMS 上，一個真正的操作系統、一家真正能支持產品的公司。這就是商業化旅程的起點。

Larry Ellison 把現在時和將來時混為一談

Peterman：我看到 Ingres 當時是和 Larry Ellison 的 Oracle 在競爭。從能力上看 Ingres 明顯更好，他們怎么還能跟你們爭？

Stonebraker：Larry Ellison 是個一流的銷售。他當時基本上把現在時和將來時混為一談，說白了就是對客戶撒謊。他會發不能用的東西，讓早期客戶幫他 debug。我覺得他做的是非常不光彩的生意，對客戶撒謊在我看來是不可原諒的。

舉個例子，有一個東西叫“參照完整性”（Referential Integrity，關系數據庫里的一種約束：一張表里對另一張表的引用必須真實有效，不能指向不存在的記錄）。比方說你解雇了一個員工，而他正好是某個部門的最后一個人，那你是要把這個部門刪掉，還是留一個空殼部門？諸如此類。Ingres 公司把參照完整性實現了。Oracle 公司寫了兩頁手冊，先把參照完整性的定義寫出來，這部分大家都同意，然后在底下加了一行：尚未實現。

Peterman：有意思。我之前采訪過一個在 Sun Microsystems 干過的人，他對 Larry Ellison 的看法也差不多，覺得這人有點不光彩。看來是個共識。我還在某處看到你說過，Oracle 收購 MySQL 的時候，所有人都怕了，轉去用 Postgres。

Stonebraker：那就是 Postgres 取代 MySQL、成為首選開源關系型數據庫的起點。

一個債券交易員的電話，催生了 Postgres

Peterman：你造了 Ingres，里面有大量技術創新，讓它比對手強。但最后它還是沒了，你做了 Postgres。Ingres 沒做、而 Postgres 做了的那件關鍵的事是什么？

Stonebraker：一開始就有一件事埋在我們腦子里。學術版 Ingres 最早的目標是要支持隔壁那位 Praveen Varah 教授要做的地理信息系統（GIS）。要支持 GIS，你得有點、線、多邊形、線組這些數據類型。但 Ingres 顯然搞不定，我們放進 Ingres 的數據類型是標準那幾樣：整數、浮點、文本字符串。在這之上你不可能高效地支持 GIS 類型。所以作為一個 GIS，學術版 Ingres 是個徹頭徹尾的失敗。這件事一直放在我們腦子后面。

另一件事時間上稍微往后跳一下，但能把這個點說透。大概 1985 年，ANSI（美國國家標準協會）剛提了一個關系數據庫的日期時間標準。商業版 Ingres 把日期時間實現了，用的是標準的格里高利歷。我那時候跟商業版那邊也有聯系，同時還在伯克利當教授。

我接到一個 Ingres 客戶的電話。他說，你們日期時間實現錯了。我說，我們實現的就是格里高利歷啊，你能做減法，月份有 30 天或者 31 天，二月除外、閏年除外，日期減法就是按你期望的方式工作的。

他說不對，那不是我要的。他做的是債券金融工具。出于某種原因，他的債券每個月付的利息一樣，不管這個月有幾天。他有買債券的日期、賣債券的日期，他想直接做減法，乘以票息率，得到付給客戶的利息。但他要的減法是：3 月 15 日減 2 月 15 日等于 30 天，因為他那套日歷就是這么定義的。結果他不得不把兩個日期取出來，在用戶代碼里做減法，再把答案塞回數據庫，效率掉了兩到三倍。

他說，我為什么不能直接重載你定義的減法，換成我要的版本？當然，Ingres 是寫死的。

但他要的東西，本質上跟前面那個“點、線、多邊形”是一回事。他要的是債券時間。Postgres 的設計目標就是有一個可擴展的類型系統，你想要什么數據類型都行，而且都是高效的。這就是 Postgres 的核心，它有這種靈活性。

業務數據處理多數時候用標準類型就夠了，但關系數據庫開始擴散到各種地方，人們想要的是抽象數據類型，或者叫存儲過程，叫法很多。這種可擴展性給了Postgres 巨大的適用面，這是 Postgres 最大的事情。

Postgres 也支持了當時 AI 那幫人想要的繼承機制。我們還做過時間旅行（time travel，讓數據庫能查詢歷史時點狀態），但實現爛得一塌糊涂，過了一陣就被拿掉了。但不管怎么說，Postgres 確實包含很多有意思的東西。

Peterman：你想招的是非常出色的軟件工程師。你之前說過，你找這種人沒什么困難。你怎么識別那種“非凡”的工程師？

Stonebraker：通常很明顯。我對什么事大概有多難，心里有數。如果他們在學校里干完的量是我覺得合理水平的三倍，那他們就是非常出色的人。

Peterman：反過來，你說過一句很有意思的話：“我受不了不那么聰明的人，跟他們說話很費勁。”你又是怎么識別一個人不聰明的？

Stonebraker：這事很容易，你跟他聊幾句，很快就能看出來。你的碩士論文做的是什么？具體怎么工作的？錯誤條件你怎么處理的？用了多少進程？為什么不用線程？就是問深度的技術問題。

一種數據庫不可能解決所有問題

Peterman：你做過一個演講，后面也有篇論文，講的是“一種數據庫通吃所有場景”是錯的，你想要的是針對具體需求的數據庫方案。今天市面上你看到哪些數據庫還在試圖通吃？

Stonebraker：我寫那篇論文是 2004 年。我們當時有一個學術項目，后來變成了 StreamBase（流處理數據庫），流處理引擎跟關系數據庫長得一點都不像。我們還有一個列存（按列存儲數據，更適合分析型查詢）的雛形，做數據倉庫用的，后來 Vertica（基于列存的分析型數據庫）把它推開了，列存跟行存也長得一點都不像。三種完全不同的實現，互相沒有任何相似，每一種都比對手快一個數量級。所以很清楚，你跑一個不是為你這類工作負載設計的數據庫，你就要付一個數量級的代價。

我覺得今天還是這樣。ClickHouse（開源列式分析數據庫）是個列存，Pinecone（向量數據庫）做文本向量處理比“用戶自定義類型”那條路要快。所以這個判斷基本沒變。

技術上沒什么難度把一個統一的解析器架在多種實現之上。Postgres 到現在為止選擇不這么做。它沒有列存實現，所以在大型數據倉庫上它不具備競爭力。它也沒有多節點支持，對大數據倉庫來說這是入場券。所以這個觀點今天和當年一樣成立。

不過另一個角度也對：如果你想快點干起來，有數據庫需求，選 Postgres。社區巨大，各種數據類型實現都有，免費，你能找到 Postgres 直接用。在你撐到每秒百萬級事務之前，它都用得挺好。在你支撐 PB 級數據倉庫之前，它就是那個最優解。低端，Postgres 就是絕對的“一種通吃”。高端，這話就不成立了。

Peterman：GPU 會不會給數據庫優化帶來什么新機會？

Stonebraker：可能。但我覺得最大的挑戰在于，GPU 是 SIMD（Single Instruction Multiple Data，單指令多數據），這跟索引正好是反著來的。所以只要“索引”是正確答案的地方，GPU 大概就不是好主意。另外架構上你得讓從存儲到 GPU 的帶寬不成為瓶頸。如果 GPU 是 CPU 的附加件，那 CPU 到 GPU 的總線很多時候就是瓶頸。

Peterman：你能解釋一下為什么 SIMD 下索引就不那么有效？

Stonebraker：比方說我要找 Ryan 的工資，我有一棵 B 樹（一種平衡樹索引結構）。你先到根節點，找到 Ryan 落在哪一邊的分隔符，順著指針走，那是一次內存訪問；然后再來一遍，這樣跑三四層。這種過程沒法很好地并行。所以答案是：索引并行不起來。

Peterman：你剛才說 B 樹。第一版 Ingres 那會兒，這些都是你們手寫的嗎？那時候應該沒有現成的 B 樹庫。

Stonebraker：對。Ingres 最早的版本完全是從零寫的。

Peterman：那次實現里最難的是哪部分？

Stonebraker：查詢優化器（數據庫里負責把 SQL 查詢翻譯成最優執行計劃的模塊）。

Peterman：為什么這個最難？

Stonebraker：算法上就是難。你今天去問任何一個資深的數據庫工程師，最難的部分是什么，他還是會說優化器。

那不是 Google 唯一一件愚蠢的事

Peterman：MapReduce 在 2000 年代初出來，在數據世界掀起了風暴，大家覺得 Google 真懂行，這是面包發明以來最好的東西。但我看你當時和你后來的論文，你強烈不同意。為什么？

Stonebraker：那時候有一大批不太開竅的人，他們說 Google 這么聰明，他們做的肯定是對的，Google 怎么說我們就怎么做。于是一窩蜂上 Hadoop（MapReduce 的開源實現）。但 Hadoop 的效率低得離譜。當時 Dave DeWitt（數據庫領域元老，威斯康星大學教授）和我們 2011 年那篇論文的幾個作者都懂分布式數據庫，我們清楚分布式數據庫系統能把 Hadoop 按在地上摩擦，那篇論文基本就是這么寫的。事實證明也是如此。

而那不是 Google 唯一一件愚蠢的事。同一時期 Google 還在大力鼓吹“最終一致性”是做并發控制的正確方式，這是他們居高臨下發布的。但所有數據庫圈的人都說，你們腦子壞了，它只解決一小類特殊問題，而那類問題在實際中很少出現。

Peterman：他們為什么追“最終一致性”？

Stonebraker：這個想法是這樣：你東海岸有個數據庫，西海岸有個數據庫，互為副本，你想讓它們保持一致。

如果你說，我做一個事務把西海岸倉庫的小部件數量減一，提交這個事務之前，我要先把消息發到東海岸更新它，再發回來確認，然后還要再來一輪消息確保兩邊都正確提交，那做一個分布式提交是很貴的，今天也還是這樣。

所以那個想法是：你在西海岸做更新、把庫存減一，只是異步發個消息出去、不放進事務里，東海岸最終會被減一。同時如果你在東海岸把另一種貨品減一，你也異步發消息，西海岸最終也會收到，最后一切收斂。

但如果允許庫存跌破零，會發生這種事：東海岸和西海岸的人同時賣掉了最后一個小部件，最后倉庫狀態變成負一，有人拿不到他的貨。

如果你像亞馬遜那樣說“通常 24 小時內發貨”，那也許還能允許超賣。但大多數企業做不到。所以最終一致性就是不工作。我們前面提到過參照完整性，在銷售系統里，參照完整性的約束就是“庫存大于負一”，這個約束在最終一致性下崩了。Google 的 Jeff Dean（Google 首席科學家，MapReduce 和 Spanner 的主要作者之一）后來想清楚了這件事。他們做 Spanner（Google 的全球分布式數據庫）的時候，Spanner 是一個傳統的事務系統，Google 完全放棄了最終一致性，完全放棄了 MapReduce。

Peterman：所以這個權衡基本上是用正確性換性能。

Stonebraker：是性能 vs 數據完整性。如果你不在乎你的數據，那你就愿意接受壞事發生。

Peterman：你當時跟 Google 團隊聊過嗎？

Stonebraker：2011 年那篇論文之前我們找過他們，問要不要合作做點事。他們沒興趣，拒絕了。

Peterman：其他大公司呢？亞馬遜、Facebook，有沒有你強烈不同意他們做法的？

Stonebraker：大概三年前我在亞馬遜做過一次演講，把所有我覺得他們做錯的事都講了。亞馬遜的問題是他們在維護十五個不同的數據庫系統，大概多出了十二個。他們有自己的文化，我說你們維護的數據庫系統太多了。到現在為止他們一個也沒退役。

Peterman：為什么你說十五個應該只留三個？

Stonebraker：比方說他們在維護一個圖數據庫。但大家都清楚，圖數據庫在性能上幾乎從來不是首選。如果你喜歡“節點和邊”那種用戶接口，沒問題，在關系數據庫之上做一層殼，把這個用戶模型給你就行。他們大多數數據庫系統，都有另一個數據庫系統在該做的事上做得更好。所以答案是：任何在足夠大的市場里不具備性能競爭力的數據庫系統，你都該退役它，因為維護要錢。

我跟笨人打交道有困難

Peterman：你從學術界深刻地影響了產業。我有個問題：為什么不直接去工業界？為什么你更愿意留在學術界用這種方式產生影響，而不是去 AWS 之類的地方做個杰出工程師？

Stonebraker：因為那樣你頭上就有個老板，有公司規章，限制你發表論文的自由，限制你去會議講東西的自由，限制你去探查競爭對手在做什么的自由。但更主要的是，我喜歡做創業。

商業版 Postgres 后來被 Informix（1980－1990 年代的關系數據庫巨頭之一）收購，我那時在 Informix 兼職。那是一家兩千人的公司，我感覺做不出什么改變，它官僚，總裁要什么就是什么。我天生不適合搞政治，搞不來。我跟我覺得笨的人打交道有困難。所以我跟大公司有點麻煩。

Peterman：我想聊一下 DBOS，這是個很有意思的技術模型。能解釋一下 DBOS 是什么嗎？

Stonebraker：我們 2019、2020 年左右開始這個學術項目。當時 Matei Zaharia（Spark 的創造者，Databricks 聯合創始人）在斯坦福任教。他說，Databricks 那時候基本上就是在云上跑用戶的 Spark（一種主流的分布式數據處理引擎）任務，任意時刻可能有上百萬個 Spark 任務在調度，得寫一個能在百萬級別工作的調度器。

他說他們試過所有 OS 圈那些人寫的調度器，都不行，扛不住。所以最后他們把所有調度數據放進了一個 Postgres 數據庫，基本就是用一個 Postgres 應用來做調度。

然后我們就意識到：你在操作系統里大部分時間做的事，就是在管理大規模數據。你應該用數據庫技術來做這件事。那干脆把 Linux 的上半部分換成數據庫系統好了。

那就是這個學術項目的主旨。我們在 20 年代初在伯克利和斯坦福做這個，做得相當成功，確實能跑通。過程中斯坦福那邊給 JavaScript 寫了一個擴展，因為你需要某種編程入口跟你的實現對話。

如果你做的是一個跑在數據庫之上的“操作系統”，而你又有一個編程語言運行時，那很自然就是把所有狀態都放到數據庫里，他們就是這么做的。所以我們既有一個創新的編程語言模型，也有一個創新的操作系統模型。

接下來當然是想，能不能做公司？我們跟風投聊，沒有一個人不說“你想取代 Linux 那是做夢”，但他們都說，你這個編程語言部分很有意思。我們的 JavaScript 擴展能讓任何程序都擁有數據庫系統的那些好性質：狀態是持久的，你可以有事務，失敗時可以故障轉移，這些好東西。

2023 年我們拿到融資成立了 DBOS（Database Operating System）公司，這一直是項目的名字。但我們做的實際上是編程語言生意。今天 DBOS 有 TypeScript 版本、Java 版本、Go 版本、Python 版本，都是無縫的，看起來就是普通程序，但跑在云的世界里。

Peterman：這跟最初那個“用數據庫替換操作系統內核”的研究項目相比，是不是收窄了？

Stonebraker：現在每個人都有動機把應用結構組織成“工作流”。所以我們決定就支持工作流系統。DBOS 在那四種語言下支持的工作流，里面的每一步，叫微操作也好叫別的也好，都是事務性的。工作流是持久的，一步走完不會被忘記。如果有人有市場需求，我們可以做到工作流是原子的：整個工作流要么完成，要么看上去從未發生過。它的性質非常好，比競爭對手快很多、用起來也容易很多。公司在這塊賣得很好，也在持續創新。

整個想法是，把應用的狀態放到數據庫里讓它持久化，然后想辦法跑得快。商業模式是先抓底層程序員，跟他們說，你需要什么我們沒有，告訴我們，我們盡快加上，把人拉過來試。

Peterman：今天 DBOS 的客戶主要在哪些場景？

Stonebraker：我們在很多創業公司里很成功，他們想選最好的東西。我們也開始打進大客戶。今天大概三分之二的客戶在做 agentic AI，一個大語言模型，周圍加一堆增強信號的東西。目前為止 agentic AI 大多是只讀的，比如你要給“Ryan 是不是好客戶”產出一個預測，跑一堆東西出一個新結果給某個人。本質上是只讀的，你沒真的去改 Ryan 的信用評級。

我估計很快整個世界就會用 agent 做讀寫應用，那它就會變得非常“數據庫”，而 DBOS 在這塊做得特別好。比方說你寫兩個 agent，把我賬戶里的 100 美元轉到你賬戶：一個 agent 把我賬戶減 100，另一個把你賬戶加 100，這兩個 agent 必須要么都提交、要么全部回滾，也就是說工作流必須是我說的“原子的”，要么發生，要么看起來沒發生過。我覺得這個市場對原子性的需求會越來越高，這對 DBOS 是好事。

Peterman：那今天向應用開發者交付的 DBOS，跟最初那個“把操作系統內核換成數據庫”的研究版本不一樣了。這其實挺酷的，我以前沒想過把操作系統所有狀態都放進數據庫。這里一定有什么權衡吧？

Stonebraker：在 DBMS（Database Management System，數據庫管理系統）之上寫的文件系統比 Linux 文件系統更快。調度引擎跟其他調度引擎相比也有競爭力。所有東西都能故障轉移，你不用做任何額外的事就拿到了高可用。答案是沒什么壞處。

Peterman：那為什么 Linux 不去吸收這個，把自己升級一下？

Stonebraker：你希望他們這么做。意思是，把所有設備驅動那些雜事留在底層，東西多沒人想碰，把上面的東西全部換成數據庫實現。

Peterman：你跟 Linux 圈的人提過嗎？他們的反應通常是什么？

Stonebraker：學術項目階段，我跟操作系統那幫人提的時候，他們會覺得很被冒犯，覺得這是數據庫圈的人在搶他們的地盤。編程語言的人也一樣，他們覺得編程環境的運行時該是他們的，我們說運行時該用數據庫做，他們也不爽。

Peterman：有意思。但如果客觀上是對的，可能它最后會贏。

Stonebraker：Java 也用了 10 年才被廣泛接受，這種事的時間常數我覺得就是大。

在我們的基準上，大語言模型得 0 分

Peterman：咱們聊了很多過去的事，我想知道你怎么看數據庫領域那些沒解決的問題和未來。

Stonebraker：有兩件事我想說。第一件，跟所有人一樣，三年前我們開始看大語言模型能干什么。我們一直在做 text－to－SQL（讓模型把自然語言問題翻譯成 SQL 查詢）。我們想讓它在真實世界的數據庫上工作，尤其是真實世界的數據倉庫。我們在四個生產級的數據倉庫上試，拿到了真實的用戶工作負載、真實運行的查詢，讓真實用戶回過頭給我們提供這些 SQL 對應的自然語言文本。所以我們有四個真實的 text－to－SQL 基準。

Peterman：你說 text－to－SQL，意思是人用自然語言對模型說，比如“四歲以上的所有人”這種？

Stonebraker：比方說“告訴我所有在 MIT 拿過圖靈獎的教授”。LLM 應該擅長這件事。Text－to－SQL 已經有公開基準，一個叫 Spider，一個叫 Bird（兩個學術界主流的 text－to－SQL 基準數據集）。最好的 LLM 系統在這些基準上挺不錯，80％ 準確率以上，當前榜首大概 85％，你會考慮用它，雖然還不到生產級。

但在我們的基準上，大語言模型的準確率是 0％。如果你給它加上 RAG（檢索增強生成）和所有那些花招，能到 10％。如果你在 prompt 里直接告訴它 from 子句，也就是把所有要訪問的表、所有要做的連接條件都喂給它，準確率到 35％ 左右。這東西離生產級很遠，而且短期內大概也到不了，如果它真的能到的話。

那區別在哪？

第一，數據。LLM 是在 The Pile（Eleuther AI 制作的開源大模型訓練語料庫，800GB 文本）上訓練的，數據倉庫里的數據不在 The Pile 里。有句老話，如果你之前沒見過這數據幾次，你沒機會把它復述出來。這是第一。

第二，查詢復雜度。Spider 和 Bird 上的查詢大概十到二十行 SQL，真實世界數據倉庫里是一百行 SQL，復雜度差一個量級。

第三，schema。Spider 和 Bird 里的 schema 是干凈的，表名是助記的，列名是助記的，沒有重復。但真實數據倉庫里，人們到處建物化視圖（materialized view，預先計算好的查詢結果，加速分析），意味著到處有冗余；列名經常是 underscore＿z＿uppers＿andre＿blah 這種，毫無助記性，很難。還有他們有特異數據，比方說 J－term（MIT 等美國大學一月份的一個迷你學期）在 MIT 是個流行詞，一月份的一個一個月學期，這個詞不只 MIT 有，但也不普及，不在 The Pile 里。特異數據、查詢復雜、schema 一團糟，這三件事在我知道的每個數據倉庫里都成立。所以這技術就是不工作，短期內也不會工作。

Peterman：那你們怎么辦？

Stonebraker：第一，我們把基準發表了，叫 Beaver，是這四個數據倉庫的脫敏抽象版本。如果你覺得自己 text－to－SQL 做得很好，來真基準上試，別老在假的上跑。

第二，接著我剛才說的，如果你拿不到 from 子句、拿不到所有連接條件，你就完蛋；如果你不把查詢拆成更簡單的小塊，你也完蛋。這告訴我什么呢？你想給檢索系統更簡單的小塊，小塊里要包含 from 子句、要包含連接條件。這是一。

第二，你一旦想跨兩個不同的結構化數據庫聊，比如你的數據倉庫和你的 CRM 系統，那很顯然，用 LLM 做結構化數據連接是個壞主意。你最好把它們留在表里，做 SQL 連接。所以我們的視角是，把所有東西都變成表。

我們在跟德國慕尼黑交通部合作。他們有六個全職的人在回答市民投訴性的查詢，比方說“為什么我家旁邊的路口綠燈時間不夠我過馬路”、“為什么電車停的時間不夠我上車”、“為什么電車一小時才來一班”。他們的數據庫里有什么？電車時刻表是 SQL，信號燈時序是 SQL，路口圖是 CAD（計算機輔助設計文件），德國聯邦的相關法規是文本，慕尼黑市的相關法規也是文本。所以你要做的是 SQL × SQL × CAD × 文本 × 文本的連接。

我們的視角是把它們全部變成 SQL、變成表，然后用一個相當于查詢優化器的東西做連接。這就是我們現在在做的事。我覺得別人會有別的想法，但這是個非常肥沃的領域，因為人們真的想做這件事。這是一。

第二，前面說的 agentic AI，一旦它變成讀寫，它就是個分布式數據庫問題，你要原子性、要一致性、要那一整套東西。我覺得這是非常有意思的領域。這就是我現在在做的。

Peterman：你剛才說的那個基準，LLM 現在拿 0 分，人能拿多少？如果你找一個真懂 SQL 的人，他能打多少？普通人呢？

Stonebraker：一旦把自然語言部分消歧之后，一個懂 SQL、了解 schema 的程序員，準確率會非常高。

Peterman：90％ 這個量級？

Stonebraker：至少。

Peterman：好。我挺意外大模型在這種基準上得分這么低。也許這期播客出去之后會有 Anthropic 的人聯系你或者怎樣。

Stonebraker：我很想知道，因為這會是個很棒的成功故事。

計算機科學不一定還是個增長行業

Peterman：對那些想深入理解數據庫的人，你會推薦什么材料？有什么頂級的技術書？

Stonebraker：文獻里的論文。我和 Joe Hellerstein（伯克利數據庫教授，與 Stonebraker 長期合作）出過一本叫《Readings in Database Systems》的“紅皮書”，但已經八年了。作為八年前的讀物我覺得它很好。除此之外就是文獻里有名的論文。

Peterman：如果你能回到剛畢業那會兒，以你今天知道的事給自己一個建議，你會說什么？

Stonebraker：我剛到伯克利接那份工作的時候，沒怎么思考過就說，我們來寫一個數據庫系統吧。當時我們對數據庫一無所知，對實現也一無所知，我們也不是 Bill Joy（BSD Unix 主要作者，Sun Microsystems 聯合創始人）那種水平的程序員。開局做這種事，真的相當瘋狂。但你硬著頭皮干，讓它能跑起來，一路上學。所以答案是：跳出框架，想些瘋狂的事，去做。

更好的問題是：如果你今天剛開始，會主修什么？因為我覺得計算機科學未來不一定是一個增長行業。我現在不太確定我會推薦 18 歲的小孩去主修計算機科學。

我覺得醫療和建筑這些行業是穩妥的賭注，其他都看起來風險大不少。如果你即將拿到博士學位、要決定接下來做什么，那其實容易：挑你能拿到的最有聲望的工作，找一個愿意幫你的導師，選一個不隨大流的方向。比方說我們的項目 Rubicon，就是不隨大流的。

我和我太太總跟人說，跟隨你的熱情，錢總會有的。但說實話我一秒鐘都不信這話，我覺得這只是你必須告訴孩子和孫子的話。

Peterman：既然你不信，為什么你必須這么說？

Stonebraker：我太太就是個例子。她有計算機科學的碩士和本科學位，但她想做 K－12 老師。她父母說，你不能這么做，賺不到錢。我覺得從那以后她一直后悔這個決定。她對計算機科學沒什么熱情，只是把它當個手藝干。所以答案是：找你有熱情的事做，你不會餓死，可能賺不到大錢，但你大概率會比做你沒熱情的事更快樂。

我認識很多人把工作僅僅當工作，生活是發生在下午五點到早上八點之間的事。我完全不是這樣，我真的喜歡我做的事，賺多少錢不重要。

參考資料：

1. https://www.youtube.com/watch?v=YPObBOwIrHk

排版：胡巍巍

注：封面/首圖由 AI 輔助生成