“我可能不再建議學計算機”！圖靈獎得主炮轟半個行業，并斷言：AI Agent最后全是數據庫問題

編譯 | Tina

“如果今天重新開始，我不確定還會不會建議 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% 以上。所以他直接下了一個結論：這項技術，至少在可見的未來，還不夠格進入生產環境。

下面是完整訪談。

1 Postgres：最好用的起點，不是終點

主持人：我想先從 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，絕對沒問題；但到了高端場景，這個結論就不成立了。

2 索引一出現，GPU 就很難發揮作用

主持人：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：因為它真的難。這東西在算法層面就很復雜。直到今天，如果你去問任何資深數據庫程序員，系統里最難的部分是什么，他們大概率還是會說，優化器。

3 Google 是選錯了方向，Amazon 是選太多方向

主持人：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 兼職工作。那是一家兩千人的公司，我完全感覺不到自己能帶來什么變化，因為那里充滿了官僚氣，基本上總裁想怎樣就怎樣。

所以我覺得我大概不適合那種環境。我不擅長搞辦公室政治，也不擅長和那些我覺得不聰明的人打交道。所以歸根結底，我和大公司確實有點合不來。

4 把 Linux 上半部分，換成數據庫

主持人：我想聊聊 Deboss。我覺得這是個很有意思的技術模型。你能不能解釋一下，Deboss 到底是什么？

Mike Stonebraker：這個學術項目大概是 2019 年、2020 年左右開始的。它的緣起，和 Matei Zaharia 有很大關系。他當時既是斯坦福的教授，也是 Databricks 的聯合創始人，還是 Spark 最早的作者。

他說，Databricks 當時本質上是在云上跑用戶的 Spark 作業。任何一個時刻，他們都可能在同時調度上百萬個 Spark 任務。所以他們必須寫一個能夠在百萬規模上決定“下一個該跑誰”的調度器。

他說，他們試過操作系統領域的人寫的各種調度器，但都擴展不上去。最后他們把所有調度數據都放進了 Postgres 數據庫里，本質上是由一個 Postgres 應用來做調度。

這件事一下子就點醒了我們。因為歸根結底，操作系統里大多數事情，本質上都是在大規模地管理數據。而這類事情，本來就應該用數據庫技術來做。所以我們的想法就變成了：為什么不干脆把 Linux 至少上半部分，用數據庫系統替換掉？

這就是那個學術項目最初的核心。我們在 2020 年代初，和伯克利、斯坦福一起做這件事，結果非常成功，清楚地證明了這條路是能走通的。

在這個過程中，斯坦福那邊還給 JavaScript 做了一層擴展，因為你總得有一個編程環境，能和底層實現通信。如果你上面跑的是某種編程語言，下面承載它的“操作系統”本質上又是一個數據庫，那最自然的做法，就是把所有狀態都放進數據庫里。他們也正是這么做的。

于是我們手里就同時有了一個新的編程語言模型，和一個新的操作系統模型。接下來很自然的問題就是，能不能把它做成一家公司？后來我們去找風投，幾乎所有人的回答都一樣：如果你們覺得自己能替代 Linux，那就是在做夢。不過，你們這套編程語言的東西倒是挺有意思。

因為我們實際上做的是一種 JavaScript 擴展，它可以讓任意程序天然擁有數據庫系統的很多優點。比如狀態是持久化的，可以有事務，失敗之后可以自動 failover，等等，都是那類非常好用的能力。所以我們在 2023 年拿到了融資，成立了 Deboss 公司。項目一直就叫這個名字，所以公司也沿用了這個名字。不過本質上，我們做的其實已經更接近編程語言業務了。

現在 Deboss 提供了一套 TypeScript、一套 Java、一套 Go 和一套 Python，它們基本是無縫的。你寫出來看起來就像普通原生程序一樣。

在云時代，幾乎所有因素都在推動你把應用組織成 workflow。所以我們決定，直接支持工作流系統。Deboss 在這四種語言里提供的 workflow 模型里，每一步，也就是每個小的 micro app，無論你怎么叫它，都是事務性的。整個 workflow 是持久化的，也就是說一旦某一步完成了，它不會被忘掉。

而且很明顯，如果市場有這個需求，我們也可以把整個 workflow 做成原子性的。也就是說，整個流程要么完整執行完，要么看起來就像從來沒發生過。所以它有很多非常好的性質，而且速度比現有競品快得多，用起來也容易得多。公司現在就在這個方向上持續賣產品和做創新。

說白了，就是你要把應用的狀態做成持久化，那就把它放進數據庫；然后再想辦法把它做快。我覺得他們現在的商業模式，和我們前面聊的也很一致，就是先把最底層、最直接使用這些東西的程序員吸引進來。

我們一直在做的事情就是：去問這些一線程序員，你們缺什么，我們還沒有什么；然后盡快把這些能力補上，再說服他們來試。我們在創業公司這邊已經做得非常成功了，因為這些公司只想選最好的東西�，F在我們也開始慢慢打進大公司。

這是一個很有意思的市場。到目前為止，大概三分之二的客戶都在做 agentic AI。也就是說，他們有一個大語言模型，外面再包一層各種組件，給它補充更多信號。

而目前大多數 agentic AI，其實還是只讀型的。比如你要預測 Ryan 會不會是一個好客戶，那么系統只是跑一堆邏輯，最后產出一個結果交給別人。它本質上是 read-only，并不會真的去修改 Ryan 的信用評分之類的東西。

但我覺得很快，整個世界都會轉向讓 agent 去做 read-write 的應用。一旦到了那一步，這類系統就會變得非�！皵祿䦷旎�，而 Deboss 恰恰非常擅長處理這種東西。

比如說，你想寫一個 agent，或者兩個 agent，讓它們把我賬戶里的 100 美元轉到你賬戶里。那它們就必須先扣掉我的余額，再給你的余額加上 100，而且兩個 agent 必須就“提交”這件事達成一致，否則就得把一切回滾。

換句話說，這個 workflow 必須是我前面說的 atomic，也就是要么全部發生，要么看起來從未發生。

所以我覺得，這個市場里的需求接下來還會繼續升級，大家會越來越希望這些系統不僅能讀，還能寫。我認為這對整個市場是利好，對 Deboss 也是利好。

主持人：那現在市場上提供給應用開發者的這個產品，和最初那個研究項目已經不太一樣了。最初那個項目是真的打算把操作系統內部的核心狀態都替換成數據庫。我得說，這真的很酷。我以前從來沒想過，操作系統所有狀態都能放進數據庫里。不過這里面總該有些代價吧？

Mike Stonebraker：其實沒有什么明顯的代價。一個構建在 DBMS 之上的文件系統，比 Linux 文件系統更快。調度引擎的性能，也能和其他調度引擎打平。你還可以讓所有東西都具備 failover 能力，也就是說，你幾乎不用再額外做什么，就能得到高可用。

所以答案是，基本沒什么缺點。

主持人：那 Linux 為什么不把這套東西吸收進去，自己升級掉呢？

Mike Stonebraker：理論上他們應該這么做。換句話說，底下那些設備驅動之類的臟活累活當然還是應該保留，因為那部分東西太多了，也沒人想重寫。但除此之外，其他部分都應該被數據庫式實現替代。

主持人：你跟 Linux 圈子的人提過這件事嗎？他們通常是什么反應？

Mike Stonebraker：在當年的學術項目階段，只要我把這個想法講給操作系統領域的人聽，他們就會非常有威脅感，覺得這是數據庫那幫人要來搶地盤了。

編程語言領域的人也差不多。他們也會覺得，怎么，你現在是說編程環境的 runtime 也該用數據庫來實現？

主持人：這個很有意思。如果它在技術上真的是對的，那也許遲早會接管掉現有方案。

Mike Stonebraker：Java 花了 10 年才被廣泛接受。我只是覺得，這種事情的時間常數本來就很大。

5 在真實數據倉庫里，LLM 寫 SQL 的準確率是 0%

主持人：我們前面聊了很多數據庫的過去。我也很好奇，你怎么看數據庫領域那些還沒解決的問題，以及未來會是什么樣子？

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：我很愿意知道他們能做到什么程度。因為這對那些真想深入理解數據庫的人來說，其實是個很好的機會。

6 計算機科學，可能不再是增長型行業

主持人：如果有人想系統學習數據庫，你會推薦什么技術書或者論文材料？

Mike Stonebraker：我和 Joe Hellerstein 出過一本“紅皮書”，名字就叫 Readings in Database Systems。雖然現在已經是八年前的書了，但如果你想看八年前以及更早那些經典材料，我覺得它仍然是一套非常好的閱讀入口。再往后的話，就去看數據庫領域后來那些比較重要、比較流行的論文。

主持人：如果你能回到剛畢業的時候，帶著今天的認知給自己一些建議，你會說什么？

Mike Stonebraker：當年我剛到伯克利任教時，幾乎沒多想，就說那我們來寫一個數據庫系統吧�？赡菚r候我們對數據庫幾乎一無所知，對實現也一無所知，編程能力也不像 Bill Joy 那樣強。所以，一上來就做這么瘋狂的事，其實本身就非常瘋狂。

但人就是這樣，先狠狠干，邊做邊學，邊學邊把事情做出來。所以我覺得答案就是，要跳出框框去想，要敢想一些瘋狂的念頭，然后真的去做。

不過對我來說，現在更值得問的問題其實是：如果你今天才剛開始，你會選什么專業？

因為我覺得，計算機科學未來很可能不再是一個增長型行業。我不確定我今天還會不會建議 18 歲的人去學計算機。

醫療保健和各種建筑、維修這類工種，看起來都還是相對安全的選擇；其他很多方向，風險都大得多。

當然，如果你已經快拿到 PhD，正在考慮接下來怎么辦，那事情就簡單多了。去拿你能拿到的最有聲望的工作，找一個愿意帶你的導師，然后挑一個不是順著潮流走的方向。比如我們現在做的這個 Rubicon，就絕對不是順著主流在跑。所以，去找一個不隨大流的方向，想辦法把它做成。

我和我太太以前都跟孩子說過一句話：“去追隨你的熱情，錢總會自己解決�！钡f實話，我一點都不信這句話。不過我覺得，你還是只能這么跟孩子說，跟孫子也只能這么說。

主持人：如果你自己并不相信這句話，為什么還要這么說？

Mike Stonebraker：我太太就是個很好的例子。她本科是計算機科學，碩士也是計算機科學，但她其實真正想做的是老師，中小學老師�？伤改府敃r跟她說，這不行，收入太低了。

我覺得她從那以后，一直都對這個決定有遺憾。她并不是真的熱愛計算機科學，那對她來說只是個謀生手段。

所以我覺得，還是應該去找一件你真正有熱情的事。這樣至少你不會挨餓。你可能不會賺很多錢，但大概率會比做一件自己根本沒熱情的事過得更開心。

因為我認識很多人，他們把工作純粹當成工作，真正的生活只發生在下午 5 點到第二天早上 8 點之間。我完全不是這種感覺。我是真的很喜歡我在做的事。無論我賺很多錢還是沒賺很多錢，這一點都不會變。

原視頻鏈接：

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

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

「AMD AI 開發者日 2026」定檔，不僅能聽到前沿 AI 技術分享，更能參與專家指導的實戰工作坊，5 月 19 日上海見！