AI 資料分析為什麼老是漏數字？柏克萊 DAB 基準測試：現成模型答對率 38%，調校過鷹架的能到 84.5%

你有沒有做過這件事：把 AI 接上資料庫，打一句「幫我把上個月的廣告成效跟訂單對起來」，然後拿到一份看起來乾乾淨淨的報表。

欄位齊全、數字有小數點、還附了洞察摘要。

你會相信它嗎？

柏克萊（UC Berkeley）EPIC Lab 做了一個叫 DAB（Data Agent Benchmark，資料代理基準測試）的東西，專門測 AI agent 回答真實企業數據問題的能力。論文裡最好的那個現成模型，第一次就答對的比例是 38%。

十題答錯六題。

而且它不會告訴你錯的是哪六題。

但這篇真正想跟你講的不是 38%。是同一個題庫的官方排行榜上，調校過的方案已經做到 84.5%。

那份排行榜用新版驗證器把現成模型的基準線重算成 45%，所以在同一把尺上，這場比較是 45% 對 84.5%。

同樣的題目，同樣是前沿模型。差距不在模型，在你給它的鷹架。

這篇的來源是 Hamel Husain 頻道 2026 年 7 月 31 日這一集，來賓是 Shreya Shankar（DocETL 作者，剛從柏克萊取得博士，2027 年將赴 CMU 任教），講的是她與 Ruiying Ma 共同第一作者的論文 DAB。我另外核了論文原文、GitHub repo 跟官方排行榜，下面會告訴你三邊的數字為什麼不一樣。

先講一句該講的：這集在 Hamel 自己的頻道，影片簡介置頂就在賣他 9 月梯次的 AI Evals 課程。所以「企業應該自己做 eval」這個結論，講者跟主持人是有商業利益的。這不代表數據有問題，論文跟 repo 都公開可查。但你讀的時候，心裡要有這條線。

DAB 的分數到底是多少？三套數字要分清楚

這題我查了才發現，網路上引用的數字至少有三套，而且都是真的。

第一套，論文 v1（2026 年 3 月）。 54 道題、12 個資料集、9 個領域、4 種資料庫（PostgreSQL、MongoDB、SQLite、DuckDB）。測了五個模型：Gemini-3-Pro 38%、GPT-5-mini 30%、GPT-5.2 25%、Kimi-K2 23%、Gemini-2.5-Flash 9%。五個模型跑的是同一套 ReAct harness，所以這一組真的可以當模型比較看。

第二套，官方排行榜（2026 年 8 月 5 日更新，同一批題目在 6 月用新版驗證器重新計分）。現成模型的基準線被重算成 Gemini-3-Pro 45%。而榜上第一名，一個叫 Sentinel 的方案，84.5%。

第三套，7 月這場演講。 講者說題庫已經擴充到 104 題、17 個資料集，最強的是 GPT-5.5 搭 Codex，pass@1 57%、pass@5 70%。

第三套要特別註明：論文、README 跟官網到現在都還寫 54 題 / 12 個資料集。我去 repo 逐個目錄數過，main 分支確實已經有 17 個資料集目錄、104 個題目資料夾，只是官方從來沒公告過這件事。所以 57% 這個數字，目前只有演講口述這一個出處。

三件事一定要一起講，不然數字會被誤讀：

pass@1 不是「五次裡至少對一次」。 pass@1 是第一次就答對的比例；「五次裡至少對一次」那個叫 pass@5。演講中講者講到一半自己口誤，中途說了聲 sorry 更正，逐字稿直接抄會抄反。

演講那組不能當模型排行榜。 因為三個模型用的 harness（代理外殼）不一樣：Sonnet 4.6 用 Claude Agent SDK、GPT-5.5 用 Codex、Gemini 3.1 Pro 用開源 ReAct。Opus 因為成本太高根本沒測。你看到的是「模型 × 外殼」的合成成績。論文那組用同一套外殼時是 Gemini 最強，換成各自的外殼就變成 GPT-5.5 最強，這本身就是證據。

這是 2026 年年中的成績。 模型迭代很快，數字會變。

還有一個最狠的數字：論文讓每題跑 50 次，結果最好的 agent pass@50 只有 69%。給它五十次機會，還是有三成的題目從頭到尾沒解出來。其中一個叫 patents 的資料集，五個模型全部掛零。

順帶一提成本：整輪 13,500 次嘗試，論文說總共燒掉約 3,150 美元。演講裡講者的原話是「我們不想為了回答一題花掉 30 美元」。你如果打算把這種 agent 掛在後台讓全公司隨便問，先把這個數字放進預算表。

為什麼會錯？八成五的錯誤，都指向同一件事

論文把失敗拆成五種模式：

1. FM1：連計畫都還沒開始擬就掛了（例如安全機制誤觸，直接說「我不能回答」）
2. FM2：計畫本身就是錯的
3. FM3：計畫對，但撈錯欄位
4. FM4：欄位對，但清理／轉換資料的程式碼寫錯
5. FM5：執行階段的 runtime error

論文對 1,147 條「跑完但答錯」的軌跡做了標註，分佈是這樣：

FM4 實作錯誤 45%，FM2 計畫錯誤 40%，FM3 選錯資料 15%。FM2 加 FM4，佔掉全部錯誤的 85%。

這個分佈值得停下來看一秒。因為第一名跟第二名，其實是同一個病的兩種症狀。

Shreya 給的診斷是這整場演講最值錢的一句：

agent 習慣在還沒看資料之前，就先把計畫寫好。

計畫寫在看資料之前，會發生什麼事？

企業資料預設就是髒的。不一致、有汙染、需要清洗，這是常態不是例外。可是 agent 在還沒看到任何一列真實資料之前就把計畫定好了，那份計畫裡根本不會有清洗這一步。這就是 FM2。

就算你在提示裡明講了「這份資料需要清洗」，它也只會在計畫裡寫一行「進行資料清洗」，不寫清楚要怎麼清。然後它才去看資料。等它真的動手寫清洗程式碼的時候，那條正規表達式只會蓋掉它剛好看到的那幾種髒法，蓋不掉全部。這就是 FM4。

兩個加起來 85% 的錯誤，根源都是同一句話：它沒有認真看你的資料。

更麻煩的是，看完資料之後它還會過度執著於自己剛剛寫好的那份計畫。就算路上發現資料長得不對勁，它也不改。Shreya 說這一段連她自己都想不透為什麼。

這就像你請了一個很會做財報的會計，履歷漂亮、報表格式一流，但他從來不下去倉庫盤點。他不是不會算，他是照著腦袋裡想像的庫存在算。算出來的東西一定漂亮，但不一定是真的。

主持人 Hamel 說他讀論文時最意外的就是這件事：他原本以為規劃是 agent 最不會出錯的環節。

講者給的 TLDR，我直接引用：

做數據問題，不要在看資料之前寫計畫。先看資料，再寫計畫，而且要一直看資料。

這跟我之前寫的 Codex goal 指令怎麼寫 是同一件事的兩面：那篇談你該怎麼把目標寫成可驗證的合約，這篇是拿實測數據告訴你，規劃跟實作那兩層就是 agent 最會出錯的地方。一個是解法，一個是病歷。

那個「格式不一的 join key」，就是你每天在踩的坑

論文的形成性研究訪談了六個產業，歸納出四大企業資料難題，其中一個叫 ill-formatted join keys，格式不一致的關聯鍵。學術語言聽起來很遠，但這件事你天天在踩。

我在雨傘產業做過工廠業務，也站過百貨專櫃。零售現場最怕的從來不是帳算錯，是帳算得很漂亮，但那份漂亮的帳跟倉庫裡實際有幾支傘對不起來。

換到數位這一側，一模一樣，只是換了名字：

• UTM 參數大小寫不一致。utm_source=Facebook 跟 utm_source=facebook，在你眼裡是同一個來源，在 join 的時候是兩個。
• 活動名稱每次都是手打的。「夏季特賣」「夏季特賣_0715」「Summer Sale」，同一檔活動三個名字。
• 幣別混在一起。台幣、美金、港幣同一個欄位，沒有標記。
• 同一個客戶在 CRM 和電商後台的 ID 對不起來。一邊是 C-10023，一邊是 10023。差一個前綴，exact match 直接掛零。
• GA4 的事件命名前後期改過。舊的叫 purchase_complete，新的叫 purchase，中間那三個月變成黑洞。

現在你回頭看那句提示詞：「幫我把上個月的廣告成效跟訂單對起來。」

AI 多半會怎麼做？直接 join。

然後給你一份看起來很完整、實際上漏掉一半訂單的報表。

而且不會告訴你漏了。

它不是報錯，它是報了一個很有自信的錯誤答案。錯誤答案還附上分析摘要，還幫你下了結論，還建議你把預算往某個渠道加。

以前你的風險是「沒有數據可以看」。現在你的風險是「有一份看起來很完整的數據，但你不知道它漏了什麼」。

後面這個風險大得多，因為它不會觸發任何警報。

84.5% 是怎麼來的？四層解法，按投入成本排序

回到開頭那個對照：排行榜上現成模型的基準線 45%，榜首 84.5%。中間那將近 40 個百分點，就是下面這幾層堆出來的。

第一層：改提示詞。最便宜，今天就能做。

在你的提示裡明講：「先檢查資料再擬計畫」「先列出每個欄位的實際值長什麼樣」「join 之前先確認兩邊的鍵值格式一致」。

Shreya 自己也說她不確定要精確到什麼程度，可能得直接告訴它「每張表都要抽幾列出來看」。但方向是明確的：你要用提示詞把「先看資料」這個順序強制寫進去，因為它自己不會。

排行榜上前幾名，那個「調過提示詞」的欄位全部都打勾。

第二層：把資料的地雷寫下來給它。

DAB 裡有個叫 hints file 的東西，明白告訴 agent 這份資料被動了什麼手腳。講者說加上 hints 之後，pass@1 每個 agent 都能提升 10% 以上。

這裡要誠實標一下：論文 v1 並沒有做「有 hints / 沒 hints」的對照實驗，所有主實驗都是帶著 hints 跑的，所以這個 10% 目前只有演講口述當出處。但排行榜上高分方案幾乎清一色都開了 hints，方向是一致的。

也要注意它沒有解決問題。hints 寫了「這個欄位可能有多餘空格」，它照樣可能寫出一條漏掉中間空格的正規表達式。這就是 FM4 為什麼還有 45%。

第三層：建語意層（semantic layer）。中等投入。

語意層講白了就是一份中繼資料檔案，用自然語言描述每張表、每個欄位是什麼、值域多少、有哪些可能的值、分佈長什麼樣。

講者說得很直接：放進語意層的東西越多，agent 表現越好。 但她同時承認，建語意層本身很難，目前沒有人真正解決。

論文裡有個小案例可以佐證這個方向：同樣用 Claude-Opus-4.6，Hasura 的 PromptQL 平台拿 51%，陽春的 ReAct 只有 44%。差七個百分點，模型完全一樣，差的就是外面那層。

對台灣的電商團隊，起手式不用那麼技術。你先把 GA4 的事件命名規則、UTM 命名規則、活動命名規則寫成一份文件，讓每個人照著填，這就是語意層的雛形了。做這件事你不需要工程師，你需要的是有人願意管。

第四層：建記憶。進階。

agent 每次踩到一種髒資料，就寫進一個記憶庫，下次可以查。講者提到在另一個平行研究裡，加了記憶確實提升 text-to-SQL 的準確率，只是還沒在 DAB 上測過。

語意層是事前的索引，記憶是事後的補丁。兩個要一起長。

最重要的一層：用你自己的資料做一個小型 benchmark。

去訪談你自己的分析師。問他們：哪幾種查詢最常出錯？邊界情況在哪裡？哪些欄位是大家心知肚明的地雷？然後拿這些真實問題和你的內部資料，建一組測試集，把正確答案也一起寫下來。

Shreya 說 DAB 最難的部分根本不是訪談，是「要從開源資料生出一個可驗證的公開題庫」，因為他們不能外流客戶資料。你在公司裡沒有這個問題。 你的資料就在那裡，不用公開，想怎麼測就怎麼測。

十題就好。每次換模型、換提示詞、換工具，跑一次這十題。你才會知道你的 AI 到底是變強了還是變弱了。

附帶一提：這個 benchmark 有多難防作弊

DAB 的資料集有不少來自 Kaggle 跟 HuggingFace，團隊刻意把資料弄髒、把答案標籤拿掉。結果只要開著網路存取，agent 會自己上網把原始資料集找出來，直接抄答案。

所以他們把網路關了。關了還是有問題：如果那台機器的 HuggingFace 本機快取裡剛好留著這份資料集，agent 一樣挖得出來。講者說，有人提交了分數非常高的結果，但不少是這樣「不小心作弊」來的。

對你的啟示只有一句：你要怎麼知道你的 AI 是真的會，還是在背答案？

如果你拿去測它的問題，答案早就躺在你給它的某份文件、某張舊報表、某段對話歷史裡，那你測到的不是分析能力，是檢索能力。上線之後，這兩件事差很多。

給台灣電商與行銷團隊的四個行動建議

1. 今天就改你的提示詞。 所有跟數據有關的指令前面加一句：「請先抽樣檢視每張表的實際資料內容，確認欄位格式與值域，再擬定分析計畫。」一句話，零成本，直接打在 85% 錯誤的根源上。
2. 本週建一份命名規範文件。 UTM、活動名稱、GA4 事件名，三件事寫清楚，全團隊照著填。這是你的語意層第一版。真的要把 AI 接上分析數據之前，先看這篇實作：GA4 MCP Server 安裝教學。
3. 本月找你的分析師聊三十分鐘。 問一句話：「你覺得哪幾種查詢最容易被做錯？」把答案寫成十題測試集，連正確答案一起寫。沒有正確答案的題目不算測試題。
4. 做一張 join key 清單。 列出你有哪幾個系統、每個系統的負責人是誰、哪個欄位是真實來源、系統之間靠哪個鍵值對接、已知有哪些格式不一致。一張表就好，這是所有工作的地基。資料散在各處這件事本身就是病根，我在 Google Analytics 跨渠道預算規劃 那篇講過：自動化工具再香，也救不了各自為政的爛資料。

常見問題

Q：AI 到底能不能拿來分析數據？

能，但不能當成一個會自己搞懂你資料的黑盒子。DAB 論文裡現成的前沿模型 pass@1 最高 38%，官方排行榜上調校過的方案可以到 84.5%，差距來自提示詞、資料提示、語意層這些外部鷹架。把它當成一個很聰明但完全不認識你公司資料的新分析師：你會給新人的資料字典、命名規則、地雷清單，一樣都不能少。

Q：為什麼 AI 給的報表數字對不起來？

最常見的原因不是算術錯，是它沒有先看清楚資料就 join。DAB 論文標註了 1,147 條答錯的軌跡，清洗／轉換程式碼寫錯佔 45%、計畫本身就錯佔 40%，兩者合計 85%。實務上就是 ID 前綴、大小寫、多餘空格、命名前後不一致這些問題讓 exact match 掉資料，而且掉得無聲無息。

Q：換更貴、更強的模型有用嗎？

有一點，但沒有你想的多。DAB 論文讓每題跑 50 次，最好的 agent pass@50 只有 69%，代表有三成題目給五十次機會也解不出來。而且分數是「模型 × harness（代理外殼）」的合成結果，同一個模型換個外殼名次就會翻。同樣用 Claude-Opus-4.6，PromptQL 平台是 51%、陽春 ReAct 是 44%。與其換模型，先把提示順序、語意層和內部測試集做起來。

Q：語意層要花多少資源做？

完整的語意層很貴，講者也說目前沒人真正解決。但最低成本的版本不需要工程資源：一份寫清楚每個欄位是什麼、有哪些可能值、值域多少的文件，就已經有效。從你最常被問的那三張表開始寫。

Q：DAB 的數字什麼時候會過期？

論文 v1 發表於 2026 年 3 月，測的是 GPT-5.2、GPT-5-mini、Gemini-3-Pro、Gemini-2.5-Flash、Kimi-K2 五個模型；7 月的演講用的是 Claude Sonnet 4.6、GPT-5.5、Gemini 3.1 Pro。模型換代很快，分數會持續變動，最新排名要看 DAB 官方排行榜。但「agent 傾向先寫計畫再看資料」這個行為模式，在 harness 設計改變之前不會自己消失。

最後

如果你問我，這篇最該帶走的不是任何一個百分比。

是那句「先看資料，再寫計畫」。

因為這句話不只對 AI 成立。你自己做報表的時候，是不是也常常先在腦袋裡想好要證明什麼，才去撈資料？

AI 只是把這個壞習慣，用一百多道題目、幾百個回合，很有效率地放大給我們看。

資料來源

• 影片：How to Build Agents That Answer Data Questions，Hamel Husain 頻道，2026 年 7 月 31 日，來賓 Shreya Shankar
• 論文：Can AI Agents Answer Your Data Questions? A Benchmark for Data Agents（arXiv:2603.20576 v1，2026 年 3 月 21 日），共同第一作者 Ruiying Ma、Shreya Shankar
• 程式碼與排行榜：ucbepic/DataAgentBench、DAB Leaderboard（排行榜數據為 2026 年 8 月 5 日版本）
• 講者網站：Shreya Shankar、Hamel Husain

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。