> ## Content Index
> Fetch the complete content index at: https://growthhackers.tw/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI 資料分析為什麼老是漏數字？柏克萊 DAB 基準測試：現成模型答對率 38%，調校過鷹架的能到 84.5%
- URL: https://growthhackers.tw/blog/ai-data-agent-dab-benchmark/
- Published: 2026-08-10T13:00:00.000Z
- Updated: 2026-08-10T13:00:00.000Z
- Description: 你把 AI 接上資料庫問一句話，拿到一份很完整的報表。柏克萊 DAB 基準測試說：現成的前沿模型第一次答對率只有 38%，而調校過鷹架的方案能到 84.5%。差距不在模型，在你給它的東西。
- Author: Lewis wang
- Tags: AI agent, 趨勢解碼, 第一方資料, Google Analytics, 電商經營

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

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

你會相信它嗎？

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

十題答錯六題。

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

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

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

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

這篇的來源是 [Hamel Husain 頻道 2026 年 7 月 31 日這一集](https://www.youtube.com/watch?v=ubk57rW%5FKUo&ref=growthhackers.tw)，來賓是 [Shreya Shankar](https://www.sh-reya.com/?ref=growthhackers.tw)（DocETL 作者，剛從柏克萊取得博士，2027 年將赴 CMU 任教），講的是她與 Ruiying Ma 共同第一作者的論文 [DAB](https://arxiv.org/abs/2603.20576?ref=growthhackers.tw)。我另外核了論文原文、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 掛在後台讓全公司隨便問，先把這個數字放進預算表。

![](https://growthhackers.tw/content/images/2026/08/inline-38-vs-84-v1.png)

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

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

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 指令怎麼寫](https://growthhackers.tw/blog/codex-goal-command-verifiable-contract/) 是同一件事的兩面：那篇談你該怎麼把目標寫成可驗證的合約，這篇是拿實測數據告訴你，**規劃跟實作那兩層就是 agent 最會出錯的地方**。一個是解法，一個是病歷。

![](https://growthhackers.tw/content/images/2026/08/inline-failure-modes-v1.png)

## 那個「格式不一的 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。

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

**而且不會告訴你漏了。**

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

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

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

![](https://growthhackers.tw/content/images/2026/08/inline-dirty-join-keys-v1.png)

## 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 安裝教學](https://growthhackers.tw/blog/ga4-mcp-server-install-tutorial-2026/)。
3. **本月找你的分析師聊三十分鐘。** 問一句話：「你覺得哪幾種查詢最容易被做錯？」把答案寫成十題測試集，連正確答案一起寫。沒有正確答案的題目不算測試題。
4. **做一張 join key 清單。** 列出你有哪幾個系統、每個系統的負責人是誰、哪個欄位是真實來源、系統之間靠哪個鍵值對接、已知有哪些格式不一致。一張表就好，這是所有工作的地基。資料散在各處這件事本身就是病根，我在 [Google Analytics 跨渠道預算規劃](https://growthhackers.tw/blog/google-analytics-cross-channel-budgeting/) 那篇講過：自動化工具再香，也救不了各自為政的爛資料。

## 常見問題

**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 官方排行榜](https://ucbepic.github.io/DataAgentBench/?ref=growthhackers.tw)。但「agent 傾向先寫計畫再看資料」這個行為模式，在 harness 設計改變之前不會自己消失。

## 最後

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

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

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

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

## 資料來源

- 影片：[How to Build Agents That Answer Data Questions](https://www.youtube.com/watch?v=ubk57rW%5FKUo&ref=growthhackers.tw)，Hamel Husain 頻道，2026 年 7 月 31 日，來賓 Shreya Shankar
- 論文：[Can AI Agents Answer Your Data Questions? A Benchmark for Data Agents](https://arxiv.org/abs/2603.20576?ref=growthhackers.tw)（arXiv:2603.20576 v1，2026 年 3 月 21 日），共同第一作者 Ruiying Ma、Shreya Shankar
- 程式碼與排行榜：[ucbepic/DataAgentBench](https://github.com/ucbepic/DataAgentBench?ref=growthhackers.tw)、[DAB Leaderboard](https://ucbepic.github.io/DataAgentBench/?ref=growthhackers.tw)（排行榜數據為 2026 年 8 月 5 日版本）
- 講者網站：[Shreya Shankar](https://www.sh-reya.com/?ref=growthhackers.tw)、[Hamel Husain](https://hamel.dev/?ref=growthhackers.tw)

**協作聲明與免責**

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

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