https://softwareengineeringdaily.com/podcasts/inside-googles-database-infrastructure-for-the-ai-era/
Sylas Krishnamurthy 是 Google Cloud 負責資料庫的 VP of Engineering。他在 IBM 寫過 DB2，在 UC Berkeley 拿串流資料庫的博士，把博士題目做成公司賣給 Cisco，接著在 AWS 待了五年、帶過 Aurora MySQL 與其他 MySQL 引擎，2019 年進 Google。他說自己其實有兩份工作，一份是 Google Cloud 的交易型資料庫，另一份是進來之後才知道的：整個 Alphabet 的營運資料庫。Gemini、Gmail、YouTube 都跑在同一套系統上，Spanner 與 Bigtable。
主持人 Matt Merrill 是個資料庫愛好者，這一集聊了七十幾分鐘，從資料庫五十年的老契約，一路聊到 AI 把契約撐開之後，Google 內外各自發生了什麼事。Krishnamurthy 的判斷很一致：資料庫過去承諾的精確結果，正在被相關性取代；而工程師得學會活在一個非確定性的世界裡。
五十年的契約：不要弄丟資料，給出精確答案
他常開玩笑說，資料庫只有一份工作：不要弄丟存進來的資料，然後對查詢給出精確的答案。這兩句話撐了五十年。2024 年他在 Berkeley 演講前去查了 SQL 原始論文發表的日期，發現幾乎就是同一天，1974 年，跟他出生的年份一樣。
中間當然出現過各種嘗試，非關聯式系統、各種新型資料庫，繞來繞去。但有一條沒變，他把它叫 database dogma：使用者宣告自己要什麼，怎麼做到是系統的事。你講你要什麼，系統自己想辦法生出來，順便保證資料不掉。
另一條沒變的是效能、可用性、耐久性之間的連動。他說，長時間的效能事件實際上就是一場可用性事件，因為延遲拉長到某個程度，站點就等於掛了；長時間的可用性事件，實際上就是一場耐久性事件。三件事綁在一起。
變的部分有兩層。一層是過去十年企業 IT 的體質：以前企業 IT 是買套裝軟體、順便裝一套資料庫，現在不是了。開源軟體把最佳實務帶進企業，企業 IT 自己就很會做，也會對資料庫要求更多。市場上也分成兩條路線，演化式的 scale up 系統，跟革命式的 scale out 系統；Bigtable 是二十多年前 Google 自己做出來的，Spanner 是另一個。
另一層是最近三、四年 AI 帶來的。結構化與非結構化資料開始被放在一起問，資料庫的工作就開始像搜尋，用學術的話說是資訊檢索（information retrieval）。精確結果不夠了，你要給的是最好的結果，相關性與排名變成第一等公民。他說，這不只是資料庫的事，當系統開始產出非確定的結果，你設計系統的方法就得整套換掉。
取捨也開始分家。掉幾個 click event 跟掉一筆金融交易，代價完全不同；有些系統可以選擇不同的約束，這本質上是成本、效能、延遲的取捨。資料庫不再有一套打天下的答案。五十年的契約沒有被廢掉，是第二句話正在被改寫。
Spanner：為了讓廣告系統離開分片倉鼠輪
Spanner 的起源是廣告系統。它大到必須分片，跑在分片的 MySQL 上；每年都要花大量時間想系統接下來要怎麼長，然後動手分片。到了 2008、2009 年左右，他們得到一個結論：等他們分完片，世界又變了。這是一個跑不完的倉鼠輪。
廣告是典型的企業應用。表有成千上萬張，而且不只一個應用。相對地，跑在 Spanner 上的一些消費性服務，DDL 打開來看，十五張、二十張表，盯著看還能看懂。
所以他們要的東西是三件一起來：企業應用的功能、Google 等級的規模、還有當時沒人解過的全球部署。強一致性、交易語意、次要索引，這些是關聯式資料庫的開發者視為理所當然的東西；把這些跟 scale out 的世界放在一起，之前沒有人解出來。Spanner 在 2012 年於 Google 內部進入正式生產，服務的就是廣告系統。
那一般開發者什麼時候該用 Spanner？他說得很乾脆：如果單節點就跑得動，Postgres 很好；需要一堆 replica，Postgres 也還撐得住。Spanner 給的是組合。同步的多區域配置、能隨時擴張也能隨時縮減的規模，還有多模：同一套系統裡有圖、有全文搜尋、有向量搜尋。
他也補了一句，Postgres 這幾年的演化裡，圖資料庫、全文搜尋也慢慢長進去了，所以這些能力最後可能大家都會有，Google 只是稍微早了一點。真正獨特的還是規模、跨區域，跟擴縮的容易程度。
Spanner Omni：一支 binary，沒有原子鐘的 TrueTime
Spanner Omni 要解的是「客戶不在 Google 機房裡」這件事。
第一個理由是銀行這類高度監理的客戶。他們要業務持續性，或者監理機關直接要求：萬一要「壓力退出」，你得有能力回到自己的資料中心跑。他轉述一位銀行客戶的抱怨：那位客戶要把系統從兩個半九（2.5 個 9）的可用性搬到四到五個九，不管單區域還是多區域都更好，結果監理機關要他解釋為什麼要搬。Krishnamurthy 說他也理解監理機關的立場，資料在多個地方有連續性確實重要；但這個「沒有選項」的缺口，實實在在擋住了客戶上 Spanner。很多人說我想押這個注，問題是我要怎麼拿到選項。
第二個理由跟 AI 有關：客戶在到處搶容量與基礎設施。雲端已經不是單極世界，有好幾家供應商，生態很熱。他也提到，以前的雲廠商連 hybrid 這個詞都不愛講，你在某些公司甚至不能用這個字；但客戶的現實不是那樣。客戶手上有很多基礎設施，有時是為了選項，有時是因為生意做大了就是靠併購與整合長出來的。錄音前幾週他在一場客戶諮詢論壇上，聽到一位客戶很激動地說，他們的皇冠珠寶會留在自己的資料中心。他認為這就是 2025、2026 年的現實：複雜、混亂，你得回應這個混亂。當然也有一種客戶，就是因為全世界找不到第二個像 Spanner 的東西，非要它不可。
工程上的故事更硬。在雲端，Spanner 是一堆 microservices 有機演化出來的，Google 自己知道怎麼操作。要讓別人自己跑，第一件事是把操作簡化：他們把所有東西收成一支 binary，你可以跑在筆電上、跑在某個部署裡、指定幾個節點就開跑。主要是 C++。他說聽起來很簡單，做起來非常難，整個團隊花了兩年，快得驚人。他開玩笑說，也許哪天 AI 會幫忙把它全部改寫成 Rust。
儲存層也得重新想。在 Google 內部，Spanner 站在 Colossus 上面。那是一個分散式儲存系統，分區（zonal）的服務，全世界沒有第二家有。靠著它，Spanner 要 split 或 merge、要擴出去的時候，只需要複製 metadata，不用搬資料；別人得留著資料的副本，於是在有負載的時候把資料搬來搬去。他把這個叫超級能力，也說這是 Spanner 與 Bigtable 比別人強的原因之一。出了 Google，這層就沒了，所以儲存要重新建模，用上一堆聰明的技巧。
再來是時間。要讓全域複製的系統跑分散式交易，你得對時間有辦法推理。Google 的作法是在資料中心放特製的硬體原子鐘，用來壓低他所說的 epsilon，也就是不同參與者時間之間的差。交易的語意取決於這個差：commit 要等多久、各個參與者的時間概念怎麼對齊。差壓得夠低，Spanner 在 Google 內部就跑得像飛。
那出了 Google 呢？他說外面的時間原語（time primitives）比十五年前好太多了，有一部分還是 Spanner 教會大家的；當然比不上 Google 機房裡的硬體鐘，但大概不會比 Google 自己在 2012 年的水準差到哪裡去，而 Spanner 就是為那個世界設計的。所以他們做了 Software TrueTime，可以跑在其他雲、也可以跑在舊的資料中心。有些面向不會跟在 Google 內部一樣好，但他相信對很多使用情境來說，夠用了。他還提到有客戶問：我們能不能在自己資料中心裝一樣的原子鐘？他的回答是「來談」。他說今天資料中心怎麼蓋，很多是來自 Google 過去二十幾年的功課，這些經驗會流到更大的生態裡；撇開他在 Google 的身分，他覺得這對整個產業是好事。
原生圖：在交易資料庫裡跑 PageRank
Spanner 現在可以讓你把資料直接當圖來用，而且不用搬資料。資料留在關聯式 schema 裡，你在上面疊一層：一行 DDL 建立 property graph，接著就能像查圖一樣查它。也可以選擇純圖的介面。查詢還是宣告式的，這點沒丟：幫我找出距離兩跳、三跳、四跳的所有節點。Database dogma 還在。
適合的場景都是關係很多的地方。基礎設施裡的 port 跟網路交換器、安全領域的使用者與帳號、trust graph、customer 360、詐騙偵測。他說最關鍵的好處是不用跑一條麻煩的 ETL，就能對營運資料問更複雜的問題，在原地問完。資料當然可以搬出去、用 pipeline 在某個地方問，但你想要那樣嗎？
圖演算法是後來的事。Google 在內部為了網頁相關的問題，做這些演算法做了幾十年，後來發現它們可以整批轉到客戶的圖問題上。詐騙就是最典型的一個：洗錢或合成身分詐騙，背後常常是一整片共謀的帳號網路。詐騙集團建出複雜的帳號與交易網路來模糊行蹤，而且一直在動。這是貓抓老鼠的軍備競賽。如果你的做法是把營運系統的資料搬到另一個系統再跑，詐騙集團早就移動完了。一筆一筆看交易，也看不到那個協同的全貌。
Spanner Graph 的作法是把帳號當節點、交易當邊，然後在系統裡直接跑社群偵測的演算法：weakly connected components、modularity clustering，找出彼此相關的帳號叢集。找到可疑叢集之後，要再往裡面找誰是關鍵角色，他直接說，這就長得跟 PageRank 一模一樣，實際上就是跑 PageRank。PageRank 當年是給網頁用的，但它在「找出網路裡最有影響力、最核心的節點」這件事上非常好用。於是你不只找到共謀的那一群人，還能看到其中的關鍵人物。
印尼的數位支付公司 DanaPay 就是用 Spanner Graph 做反洗錢。演算法直接在 Spanner 裡跑，不用等 ETL 週期，可以更快找到可疑網路、指認裡面的關鍵角色，而且能即時標記或阻擋交易，避免財務損失與後續的作業負擔。
他的收斂是這樣：一般交易資料庫不見得需要 PageRank，但你真正需要的，是對「新鮮營運資料裡的關係」有快速、可動作的情報。他也提到 SoundCloud，說他們跑圖演算法跑了幾年，都是批次在跑；很多時候大家以為那是唯一的方法。他還說，每次多給開發者一點東西，他們就會找出你沒預期到的用法。
Schema 之外，agent 要的是脈絡
以前專案裡第一個難題是選哪個資料庫、資料怎麼放。現在 LLM 什麼資料都吞，agent 還會自己寫查詢。所以 schema 設計還重要嗎？他很坦白：我們不知道所有會變的東西，這件事變得太快。但有一件事是確定的，為數龐大的既有應用不會一夜消失，而它們有迫切的需要被 agentic 應用用上。在你煩惱 schema 要不要改之前，更急的是怎麼把這些資料庫「點亮」。
他的講法是 agentic data cloud 有三塊。第一塊是 AI 原生的基礎設施：圖、向量搜尋、全文搜尋，因為結構化與非結構化資料正在合流。第二塊是把摩擦拿掉，讓世界沒有邊界：跨雲的 lakehouse、Spanner Omni、給 Postgres 應用用的 AlloyDB Omni。第三塊是信任，而信任的意思是脈絡：你得知道系統裡到底有什麼。
將近三十年前他在 DB2 團隊時，一直不懂 SQL 標準為什麼要讓你能替一個物件加上一段 comment。當時看起來很理論、很累贅。現在這東西有意思了，因為它可以記錄某個東西的意思；但現實一點講，他覺得不會有人真的靠 comment。你要另外想辦法蒐集 schema 的資訊。
他舉了兩個很小的例子。一張表裡有 billing address 跟 shipping address 兩個欄位，如果其中一個是 null，背後有一個沒有寫在 schema 裡的隱含知識：這兩個其實是同一個。那個知識要被抓出來，那才是關鍵脈絡。又或者有個欄位叫 city，值是小寫嗎？是三個字母的機場代碼嗎？一個要生成 SQL 的 agent，得先知道這件事。所以，schema 重要，但脈絡更重要；只有 schema 並不夠。
AI 會不會設計出不同的 schema？他不覺得。AI 會照人類過去設計的方式設計，因為它就是被那些東西訓練出來的，模型會傾向挑同一種結構。他也不太相信「生成者是 AI 還是人」會讓 schema 設計的通則產生根本變化。有人跟他說，他們現在沒那麼在意程式碼的抽象了，反正叫 AI 複製一份改一改就好；他覺得那條路通往更多混亂。
倒是應用的定義在變。今天一個應用有四面牆，有邊界、有 API 介面。新的世界裡，應用會變成免洗的 workflow，那個「應用資產」本身不存在。早上一個知識工作者進辦公室，手上有系統 A 跟系統 B，想湊出一張合併兩邊資訊的採購單。以前的作法可能是跟大型系統整合商簽約、付一大筆錢，半年後才有結果；現在他直接叫 AI 去做。而這些 agent 互動的軌跡得存在某個地方，這就是新的資料問題。系統也得更有彈性：出國前打電話給銀行設個詐騙警示，卡片才不會被擋；那如果你辭掉工作，決定在東南亞每個國家各待一週、三個月後再回來呢？你可能想要越南一週、寮國一週、柬埔寨一週，設二十個不同的警示。銀行系統大概會噎住，因為當初設計的人沒想過這件事。所以 schema 該不該更往前看、更有彈性？他把這當成一個還開著的問題。
寫入先提案，不要直接改
目前整個業界都很保守：大部分只做讀，因為大家都怕。沒有人想在自己家重演 Bobby Tables 那類事故，一句塞進去的查詢就把資料刪光；恐怖故事已經有了，安全與信任沒想清楚，壞事就會發生。
寫入難在哪？agentic 應用、這些免洗 workflow，要怎麼寫入、怎麼改 schema，他說並不清楚。他的提案是：當你要對資料庫做一個變更或修改時，不要真的做那個變更，而是產生一個「變更提案」（proposed change），它不會當場生效，可能要走過一組步驟。他認為資料被改、schema 被改的整套方式，都還會再修。
既有應用不會一夜消失，商業邏輯住在應用裡，所以還是得把它們接上這個新世界。
主持人在這裡補了自己的立場：他願意讓 agent 寫很多應用程式碼，但他在資料模型這條線畫下去。Agent 可以提案、可以試著做，但他會狠狠審一遍，用自己的經驗、對未來的判斷跟創意去壓力測試。Krishnamurthy 說這跟他的看法一致。資料模型這條線，目前還是留給人守。
PGVector 之後：filtered vector search 才是真問題
每個 AI 新創的技術棧看起來都是 Postgres 加 PGVector。Krishnamurthy 自己是 Postgres 的愛好者，當研究生時就寫過 Postgres 的程式；他說 PGVector 很棒，好用，整個 Postgres 的擴充生態讓實驗可以一直長出來，搭上 HNSW 演算法在很多情境下都很好用。
但 Google 做向量搜尋超過十五年了，YouTube 與搜尋的底層都有它。他們的技術叫 ScANN，樹狀結構的演算法，可以撐到一百億顆向量以上，延遲表現比單純的 HNSW 好得多。他們把 ScANN 放進 AlloyDB，並且讓它用起來像 PGVector；同時也保留原版的 PGVector，應用程式不用改，跑在 PGVector 上的東西也能跑在 ScANN 上。
數字是這樣：在他們的測試裡，向量查詢比標準 Postgres 上的 HNSW 快六倍，記憶體少用四倍。記憶體這件事對資料庫特別實在，省下來的會進到 buffer cache，效能又跟著好。他們也支援分散式索引建立，也支援 HNSW，還把一些 ScANN 的改進搬了過去。至於這些有沒有回饋到上游開源專案，他說他不確定，不想講不準確的話。
他把向量搜尋看成一種「ensemble」問題：有些情境 HNSW 就夠，而且更簡單；但最高階、最大規模的工作負載，真的需要 ScANN 這類東西。兩邊都有價值。
真正麻煩的是 filtered vector search。很少有人問一個純向量搜尋的問題，實務上查詢會帶多個條件：一個語意搜尋的條件打在向量索引上，另一個是一般的關聯式條件，例如目錄裡的價格。於是你得決定先探哪一個索引。先探向量索引（後過濾），可能拿到二十筆，套上價格低於五十塊，一筆都不符合；再要下二十筆，還是不符合，只能一直往下撈。改成先探非向量索引（前過濾），可能一次拿到一百萬筆，而一百萬筆根本跑不動最近鄰搜尋，那正是你當初做向量索引的原因。哪一種策略對，取決於選擇性，而你在事前不知道。
AlloyDB 的解法是把兩個索引放在同一個系統裡，所以它可以同時探兩邊，很快判斷哪個順序對，並且在過程中隨時換策略。主持人問這算不算分而治之，他說不算，這是一種自適應的技巧：先試幾種，再依你當下的實際狀況調整。
他也不建議另外外掛一套純向量的系統。如果只是對一批不太變動的文字語料做純向量搜尋，那或許合理；但只要開發者蓋完這種系統，幾毫秒之後查詢就會變複雜。向量系統一旦分家，你就要在應用層把兩個系統縫起來，而前過濾、後過濾要誰來做？他說純向量系統對這件事沒有好答案；多個索引在同一套系統的控制之下，才做得出這種聰明的東西。他們另外也把高速向量檢索跟營運資料上的全文搜尋合在一起，混合搜尋（hybrid search）就變得有意思了。
MCP Toolbox 與 managed MCP：兩條路
Google 釋出了 MCP Toolbox for Databases，開源，本質上是一台架在資料庫上面的 MCP server，AlloyDB、Cloud SQL、Spanner 都能接，開發者不用自己從頭刻。另外也有 managed MCP 服務，企業等級、有治理機制。
他自己的團隊是在做資料庫跟基礎設施的，不太用 MCP；但有個地方會用，就是使用者介面。Google Cloud 的代管資料庫本身也是一個應用，實例與資料庫的資訊存在內部的 Spanner 裡。以前每次做一個新功能，就得做一大堆複雜的 UI；現在他們改成連上 MCP 服務，依使用者問的問題即時生成介面。他說這不只是省時間，還能生出更貼著使用者需求的體驗。他也補充，這個 Generative UI 沒有正式的對外名字，他不小心用了內部的專案代號；類似作法在資料庫 console 的觀測性功能裡已經有了。
機制是這樣：他們的 UI 基礎設施本來就有一堆 widget，於是一邊把底層系統接上 managed MCP，一邊把這些 UI widget 也包成 MCP 工具，模型就能自己決定要怎麼組合。他說任何客戶都可以做一樣的事。真正麻煩的地方，還是回到那個老問題：什麼是讀、什麼是寫，以及你有多準備好讓 agent 寫進營運資料庫。
兩種開發者走兩條路。走在最前線的開發者會用 MCP Toolbox，因為他們需要自訂的身分驗證機制，可能還跑在自己的機房、根本不在 Google Cloud 上。Toolbox 一開始要解的問題就是：不管你人在哪裡，都讓你更容易接到資料庫；開放性是 agentic data cloud 的一部分。在 Google Cloud 裡，managed MCP 是另一條路：控制平面的操作（agent 去建資料庫、跑應用、部署應用）、還有自訂工具（不是下 execute SQL，而是像「查一個航班」這種工具，背後去跑一句特定的查詢）。他也說，他們在 Toolbox 上學到的東西，只要有價值，就會進到 managed MCP。
讓 LLM 接上正式資料庫：PSV、隔離、觀測
主持人開場就說，一個 LLM 接著你的正式資料庫，這是一個等著發生的恐怖故事。Krishnamurthy 的答案從一個對比開始：分析型系統跟營運型系統是兩個世界。
分析型系統裡，進來的人可能是商業分析師或資料科學家，用自己的憑證連線，存取控制長在系統裡，他們通常能看到比較廣的資料，而且 BI 查詢本來就是聚合查詢。營運資料庫不是這樣。1990 年代初期，主從架構的胖客戶端直接連資料庫，終端使用者的憑證真的在裡面；到了 1990 年代後期，網頁與三層式架構把這件事徹底改掉。今天在營運資料庫的 schema 裡，根本沒有終端使用者這回事。資料庫有使用者、角色、群組、權限，但終端使用者不在裡面。原因之一是人數：有了網頁之後，終端使用者從幾百個變成幾千個、幾百萬個、上億個，你沒辦法那樣管。於是應用程式用一個 service principal 連上資料庫，某個登入使用者能看到什麼，是散在應用程式各處 SQL 的 WHERE 子句決定的。
現在你讓一個 agent 用這個看得到全部資料的 service principal，替任何一個使用者問問題，問題就來了。他舉例，一家租車公司如果有兩千個分店，每個店經理應該只能問自己店裡的車。
解法是 parameterized secure views，PSV，建築在 Postgres 的 secure view 上。Postgres 的 secure view 有一個 security barrier 的特性：沒有它的話，你可以用資訊理論的手法把資料挖出來。作法是寫一個會讓系統爆掉的查詢，例如帶 WHERE 子句的除以零；沒擋住的話，查詢優化器會太聰明，把條件推到表裡面去，於是你得到一個錯誤、或得到一個空結果，而那個錯誤本身就洩漏了資訊。security barrier 確保條件不會被推進表裡。
PSV 再往前一步：加上參數。這個參數基本上就是原本散在應用程式 WHERE 子句裡的那道授權檢查，只是現在你把它定義在 schema 旁邊的 DDL 裡。Agent 用的 service principal 只碰得到 PSV，碰不到底層的表；登入使用者的憑證從一條側通道進來，綁到那個參數上。你可以攻擊 LLM、可以騙它、可以讓它生出任何它想生的查詢；查詢送到的時候，它永遠只會看到那個使用者的憑證允許它看的那些列。他說這是關鍵的基礎設施，沒有它，做不出 agentic 應用需要的那種安全。主持人把它翻成一句話：你不需要把角色塞進資料庫，是把原本寫在應用程式裡的查詢，搬進 DDL。
他還把這件事接回 1975 年的一篇經典論文，end-to-end argument in system design。他在 Berkeley 開始讀博士時讀到，論文的意思是：分散式系統要談加密、談安全，你得在系統的兩端解決，不能在管子裡解決。同樣的道理搬到這裡，安全得坐在資料那一層，因為我們活在一個 agent 什麼都做得出來的非確定性世界。
另一半是隔離。分析查詢打交易資料庫本來就會互相傷害，這也是為什麼大家會把資料卸載出去；Google 花了很多年處理這件事。他轉述一位銀行客戶的反應：我們花了好幾年確保批次掃描不能打在營運資料庫上，現在你要我在上面跑 agent？你瘋了嗎？他說這問題問得對。Agent、甚至一整群 agent 在問問題，同一堂課還是要再上一次：agentic 應用要被隔離。而且可能更麻煩，因為 agent 不好控制，它會跑爛查詢，也會跑惡意查詢。
再來是觀測。他說你需要的觀測性要細到這種程度：你能不能對著你的 Postgres 資料庫問，把 agent 來的查詢跟應用程式來的查詢分開列給我。有了這個，才談得上在周圍架護欄。主持人說這幾乎就是對資料的即時威脅偵測。
誰 commit 誰負責，然後接受混亂
主持人提到他先前的說法：Google 的工程師想用多少 AI 都可以，但程式碼是誰 commit 的，責任就歸誰；節目裡也提到，Google 現在大約有四分之三的新程式碼是 AI 生成的。Krishnamurthy 的反應很老實：三個月後會怎樣，他真的不知道。但他確定一件事，六個月前的先驗假設現在該重新檢查一遍，能做的事情比大家想的多。
不過數字要小心，因為變異非常大，取決於你在講哪一種程式碼。他的直覺是：像 Paxos 這種分散式共識協定，也就是 Spanner 的心臟，大概還是很難讓 AI agent 直接大改，他們也會非常小心。而「AI 生成的程式碼」是一個連續光譜：一端是在 IDE 裡做例行重構；另一端是一整個 pull request、一整塊自成一體的程式碼，而寫的人從頭到尾沒有進過 IDE。
他們在團隊裡的做法是因材施教：針對每一群做同一件事的工程師，建對應的 harness 與技能，然後量測。就像 AI 與 agent 世界裡的每一件事，關鍵是 evals：你需要一個客觀的方法知道它到底有沒有在動。他說這對大部分人應該都適用。
還有一件事他特別強調：留空間給實驗。挑一個專案，專門用來推你在 AI 上能推到多遠。撞到瓶頸的時候，工程師的慣性反應是切回原本的做法，把問題解掉，因為我們被要求的本來就是把事情做完；但他認為也需要有一部分努力是這樣：撞到瓶頸就修瓶頸，不要繞過去，並且接受交付會變慢。
最後他給的那個總結是這樣。他們花了二十五年學怎麼蓋確定性、可規模化的系統，確定、可預測幾乎變成信仰。現在是一個不同的時代，資料是亂的、不再確定。他觀察到很多人像在走悲傷的五階段：一開始都在吵怎麼把 AI 弄成確定性的，他覺得那條路不會成功。兩個世代的軟體工程師都照舊方法訓練出來，產業得接受自己身處混亂，然後與它共處。至於怎麼在混亂裡看懂事情，還是回到他前面講的：用 evals 去看品質與商業結果。因為資料庫真正變掉的那件事是結構化與非結構化資料一起進來，而它要交付的東西，已經從精確結果變成最相關的結果。主持人接話說，已經沒有對或錯的答案，只有一片相關性的光譜。Krishnamurthy 說，對，而我們全都還在那片光譜上的某個位置。