資料 Agent 算錯了誰會發現？Hex 的 6 個驗證做法

你把資料 Agent 接上公司的業務績效儀表板，問它：「這一季表現最好的業務，現在怎麼樣？」它回答：每位業務的配額達成率都超過 900%，有人到 1,200%，跟上一季比是階梯式的成長，生意正旺。

這個畫面來自 Hex 的 AI 工程師 Izzy Miller 自己做的測試。Hex 是做資料分析筆記本與資料 Agent 的公司。Izzy 拿公司內部真實的達成率儀表板，刻意埋進一個資料展開（fan-out，一對多的 join 讓同一筆資料被重複計算，總和因此膨脹）的錯誤。在 900% 這個量級，他測過的模型沒有一個自己發現；他只要說一句「這看起來不對」，它們大約十秒就找到錯誤。

快速回答 資料 Agent 的答案不像程式碼那樣有現成的自動驗證，依 Izzy Miller 在 LangChain 2026 年 4 月 9 日上傳的訪談，可以整理成六個做法：語意模型（先定義好指標的一層）與背書（標記受信任資料）、看得見的步驟、資料團隊的回饋迴路、記憶與治理分層、陷阱式評測、90 天模擬。其中記憶分層還在測試，90 天模擬只測過模型、沒跑過 Hex 的 Agent。Izzy 說資料答案該怎麼驗證，他們還沒有太多答案；語意模型只在問題落進已定義的指標時才有用。我判斷，記錄「公司怎麼定義正確」的機制比較可能長期留下。

資料 Agent 為什麼比 coding agent 難驗證？

資料分析的完成條件常常得先釐清：指標怎麼定義、資料管線有沒有改，都會影響答案對不對，因此比程式碼更難直接用成功或失敗來驗證。

Izzy 拿寫程式對比。他說現在寫程式多半是先講好規格、讓 agent 做完，最後只問成功或失敗；程式碼愈來愈像可驗證的任務，模型因此能用「可驗證的獎勵」（verifiable reward）訓練變強。要求「做一個有五顆按鈕的儀表板」，五顆按鈕在、按得動，任務就算完成，背後的程式碼寫得多亂都不影響這個判斷。

資料分析則在過程中有許多決策點：看到中間結果，要不要換個角度看、要不要拆開再看。Izzy 說這些決策點的結果都很難驗證，而且「真相」本身常常模糊，因為兩個團隊對同一個指標可能有不同定義，資料管線的更新也會讓數字在你腳下改變。Hex 在 2025 年 8 月 27 日發表 Notebook Agent 的官方文章，已經寫過「Data analysis is not a verifiable task」。

開頭那份儀表板就是這種情況：Izzy 說每個 agent 看到的都是「最好的一季」，還拿它跟上一季比較，說是階梯式的跳升，沒有一個停下來問這些數字合不合理。下面的圖把 Hex 的六個機制放在一個答案的路徑上，紅框就是這個 900% 的答案。

圖上的 ①–④ 是答案產生前後的機制，⑤⑥ 是評測做法；其中 90 天模擬目前只測模型，尚未跑過 Hex 的 Agent。下一節用一張表整理各自解決的問題。

六個機制各解決哪一種驗證問題？

六個機制各對應一種驗證問題：誰定義指標、讓人跟著檢查、答錯後有人知道、錯的定義不被記住、測 Agent 抓不抓得到錯、測它會不會越用越準。

Izzy 是 Hex 員工，談的內容包含產品設計與他自行做的評測實驗；主持人 Harrison Chase 是 LangChain 執行長，節目由 LangChain 製作。下面逐項看他們各自怎麼說。

語意模型和背書，擋得住 900% 的錯誤嗎？

只有問題落在語意模型已定義的指標內才擋得住：Izzy 說模型定義得好、使用者也在範圍內使用時，答案大致可以確定正確，但任務常常需要超出模型。

語意模型（semantic model）是先定義好指標、維度與資料表關係的一層。Izzy 的說法是，有了它，Agent 就能依資料團隊確認過的指標定義與資料表關係作答。這些提供給 Agent 參考的資訊叫做 context；他認為這樣就不必另外設計一套聰明的驗證迴圈。他也直說：人總會找到辦法踩雷，他自己在 Looker 用完美的語意模型時也這樣；而且模型很愛寫 SQL 和程式碼，有些任務的重點就是要跳出語意模型。

Hex 文件把這一層分成幾塊。背書（endorsement）用來標記受信任的資料資產，文件寫「Endorsed assets are prioritized when agents answer questions」；至於沒背書的資產怎麼處理，那一頁沒有說明。語意模型與指南（guides）也一樣：只有 Admin 與 Manager 能建立、編輯和發布，Editor 與 Explorer 只能檢視分頁，三項都在 Team 與 Enterprise 方案提供。指南分兩種：一份 hex.md 每次對話都會讀；其餘放在指南庫，「retrieved dynamically when relevant」。Izzy 說，指南參考 skills 這類任務指引的載入方式：Agent 先看清單，需要時才讀內容，像先看目錄、再翻需要的章節。他稱這種設計為漸進揭露（progressive disclosure）；文件描述的是依相關性取用，沒有用這個詞。

Hex 2025 年 10 月 1 日的 Threads 發表文章（Threads 是對話式介面，主要對象包含非技術使用者）說得更具體：資料團隊決定 Threads 能碰哪些資料，可以只限語意模型，也可以放寬到有背書的資料表；Agent「heavily prioritizes governed data」，有背書的專案被「treated as authoritative」。

工程上的意思。 會被拿去開會的指標，例如配額達成率，要先進語意模型並背書。背書只有 Admin 與 Manager 能設定，所以「哪個定義算數」這個決定被收在 Admin 與 Manager 手上；要由資料團隊把關，得把這兩種角色交給負責指標定義的人。我的推論，訪談沒有說明：如果錯誤埋在使用者自己寫的分析裡，沒有經過語意模型定義的指標，背書就擋不到，要靠後面的機制接手。

Agent 該把查詢步驟秀給使用者看嗎？

Hex 2025 年的官方文章強調，步驟可見方便使用者審核；Izzy 在訪談裡補充，對不懂 SQL 與 Python 的商務使用者，「秀出步驟」撐不起可驗證性，還需要更強的驗證或信心指標。

2025 年的 Notebook Agent 文章說，Agent 改的程式碼會以差異檢視呈現，使用者可以逐個 cell（筆記本中的一格程式碼或文字）接受或拒絕，並寫下「Every line the agent produces is reviewable」。Threads 文章說使用者可以跟著 Agent 一步步推理，「easier to audit」；資料團隊看得到 SQL，商務使用者看到的是說明、表格與圖。

Izzy 在 2026 年的訪談裡補上另一面。他說對不懂 SQL 與 Python 的商務使用者，「秀出工作過程」這個概念放在引用與可驗證性上並不適用；他自己用 Codex 時把輸出關掉，Agent 跑出的 Perl 指令他也跟不上。更好的驗證是什麼，他說他們還在研究，沒有太多答案。Harrison 在這段問的是：Agent 秀出自己的工作過程重要嗎？

Hex 的 Notebook Agent 幾乎只在 notebook 裡工作，唯一的例外是可以跑不會出現在 notebook 的暫存 SQL。Izzy 說原因是，先用幾個小查詢摸清資料表有沒有想要的資訊、欄位格式是什麼，再一次寫對主查詢，對使用者比反覆修改出錯的查詢好。副作用是：使用者問了簡單問題，Agent 靠暫存查詢直接報答案，使用者就會問「圖呢？證據呢？」，Agent 等於回「請相信我」。他還說，GPT-5.4 遇到問錯的複雜問題，可能先跑五十個左右的暫存查詢才開始做正事。

至於介面，Hex 現在是 Agent 工作時展開步驟、做完後收合。Izzy 預期這個設計撐不久：新的快速模型（他舉 OpenAI 的 GPT-5.3 Codex Spark）快到來不及顯示，幾個月後團隊可能得想辦法拆掉「讓使用者跟著看」這個行為。

工程上的意思。 Agent 的結論如果來自暫存查詢，證據就不在使用者看得到的產物裡。Izzy 的取捨是不給通用的 Python 工具，改用專用工具並附上何時該用的行為指引。本站推論，訪談沒有說：如果開頭的 900% 是 Agent 用暫存 SQL 算出來的，使用者連那個 join 都看不到，只會看到結論。

答錯之後，誰會知道？

在 Hex，答錯主要由資料團隊事後從 Context Studio 的紀錄發現，再回頭修改指南或語意模型。

Izzy 說，Context Studio 給資料團隊的管理者一個鳥瞰：大家問了什麼、得到什麼答案。另外有一個獨立的 LLM 評審（LLM as a judge）把可能出錯的案例標出來，包括 Agent 可能困惑，或有警告與語意模型衝突的情形。這些目前都在答案送出之後才執行，讓管理者有機會補強 context，所以是一套有人在迴圈裡的系統。下一步是自動化：他們在內部做原型，讓 context agent 自己更新 context。他不確定資料團隊想不想把工作變成逐筆翻對話紀錄，那在他看來是 Agent 的工作；觀察工具應該呈現失敗的群集，以及群集隨時間怎麼變。Izzy 提到 Anthropic 有一篇文章講這種做法，Harrison 說 LangChain 也把同類功能做進了 LangSmith。

比訪談更新的資料點在 2026 年 9 月 29 日的 Hex 更新紀錄：Context Studio 把管理者看到的 Agent 活動，從「Threads」與「Notebook agent」兩類，改成依用途分成分析、建 App、建模三類。這與 Izzy 在訪談裡說的兩個 Agent 趨同的方向一致。更新說明只提到 Manager 與 Admin 能看到工作區怎麼使用 Agent，沒有說這個分類會不會標出答錯的案例。

回饋迴路有一端是記憶。Izzy 說使用者層級的記憶在消費者產品裡是「記得你的狗叫 Rover」，放進資料場景卻可能很可怕：使用者說「這個指標是這樣定義的」，可能說錯或已過時，存進記憶後就和資料團隊定的指南、語意模型衝突。他們內部用 Claude Sonnet 4.6 測過衝突的 context（與既有資訊矛盾的內容）：注入一段與既有資訊矛盾的內容後，它會花 30 分鐘反覆思考，陷入他稱為崩潰的模式。這項測試看的是思考時間，沒有看答案正確率。所以 Hex 目前把記憶和資料團隊主導的指南、模型分開，Izzy 說還有更多測試要做。

工程上的意思。 回饋迴路要有人收：被標記的案例進哪個佇列、誰改指南，都要有負責的人。Izzy 的描述是資料團隊管理者負責，同時在試著讓 context agent 接手。本站推論，訪談沒有說：開頭那個 900% 的答案會不會被 LLM 評審標出來，訪談沒交代；能確定的是，資料團隊最早也要等答案送出之後才看得到。

怎麼測 Agent 抓不抓得到這種錯？

Izzy 的做法是維護一小組他熟悉每個失敗原因的陷阱題，每題重跑多次；Hex 的困難題集約 30 到 50 題。

他說大部分資料評測集都不好，除非有人持續維護。他看過的問題有標準答案錯誤、評分有問題，例如用程式做確定性評分，卻沒處理百分比寫成小數的情形。他舉一個很流行、Hex 也用其修改版的基準：幾百題裡，很多題都取決於 Agent 有沒有把空陣列當成 null，這是手冊裡一條冷僻的規則，他說這題考的是在長文件裡找一條規則，類似大海撈針式的檢索；他認為許多基準把這種檢索和分析推理混在一起。Izzy 也說，現在許多公開的資料評測像單次的酒吧猜謎問答，例如「2019 年 4 月 16 日我們有幾位使用者？」；Harrison 的比喻是，這等於用 tab complete 評寫程式的模型，而大家其實要它寫出完整的東西。

所以 Izzy 認為好的評測集小到你能記在腦裡。他的困難題集約 30 到 50 題，每題都是他手工做的陷阱，並重跑多次。這組題目連目前的模型都答得很差；他說，Opus 4.6 max 在最難那組約得 20%。另外還有一組一般題集，有標準答案、資料倉儲也刻意弄亂，用來防止退步並評估新功能。他們內部評測系統要回答兩個問題：這次改動有沒有達到預期的效果？有沒有造成不想要的效果？

最有代表性的是從 notebook 中間開始的題目：notebook 已經蓋得很複雜，使用者說「這不是我預期的數字」，題目裡藏著連環三個錯誤，眼前的 notebook 狀態只露出第一個，反而遮住第二、三個。開頭的達成率測試是 Izzy 自己最喜歡的例子，所有他測過的模型都沒過。他說他把數字灌到上千個百分點，才有模型開始懷疑資料管線出錯；真正自己抓到 join 錯誤的，沒有。

工程上的意思。 陷阱題可以分成兩個版本測：Agent 自己看，與使用者說了「這看起來不對」之後再看。後者是 Izzy 說的十秒，兩者的差距就是缺少的那個人。這是我的建議，訪談沒有這樣做。

單次評測看不到什麼？90 天模擬在量什麼？

單次評測量的是第一次答題的表現，看不到 Hex 這類產品靠使用累積 context 而變準的部分；Izzy 為此做了 90 天模擬，他取名 Metric City。

他的想法是：大部分評測只讓 Agent 答一次，答錯就算了，沒有重來的機會，也沒有任何價值留下。如果只這樣評估，就評不到會越用越好的整個飛輪。他用 Snowflake 建了一間虛構公司 Shoreline Commerce 的資料倉儲，並手工注入各種資料品質問題：空值、錯亂的欄位、不太對得上的 join。模擬開始後，時鐘每天走一格，代表模擬中的一天。dbt（資料轉換工具）會執行一次轉換模型，更新資料倉儲；期間會有新資料進來、資料出錯、新產品上線，也會發生詐欺。利害關係人以電子郵件工單的形式提問，也順便告訴它一些資訊。

回覆工單之後對話不結束，Agent 會被告知可以多做一點主動的知識工作：追蹤沒完成的線索、記錄發現、整理 wiki，想結束再結束。這樣連續 90 天。題目是照理想的 Agent 在第 90 天應該全部答對來設計的。Claude Sonnet 4.6 第 90 天得 24%，第 0 天約 4%，他說第 0 天的成績對他不是有用的數字，因為那不是真實世界評估產品的方式。

這個結果有範圍。它跑在 Izzy 自建的測試框架（harness）上，工具很簡單，評的是模型本身，還沒有評 Hex 的 Agent；他說這還是「瘋狂科學家實驗室」的階段，跑一次很貴，希望之後開源（本篇查證時沒有找到公開版本）。Harrison 問 Hex 的 Agent 有沒有跑過這個基準，Izzy 說還不知道怎麼跑，但打算跑。他說這個模擬受 Andon Labs 的 Vending-Bench 啟發，並說就他所知，做有意思的長時程評測的只有 Anthropic 與 Andon Labs。本站推論，訪談沒有說：這類模擬想量的是，Agent 第二次遇到同類 fan-out 時，能不能靠自己留下的筆記懷疑那個數字。

哪些機制會被下一代模型拆掉？

依 Hex 執行長 Barry McCardel 常問的「沙還是石頭」，Izzy 說領域意見與使用累積的 context 會留下；他在訪談前段講的 ID 對照系統，我把它對應成沙的例子。

Barry 的問題是：如果模型的能力是現在的兩倍，哪些東西會被沖走，哪些會留下。訪談前段 Izzy 提過一套 ID 對照系統，正好可以當沙的例子。早期模型在 notebook 超過 50 或 60 個 cell 後，會開始瞎編或調換那些很長的靜態 ID，Hex 就做了短代號與 ID 的對應表，這是 Agent 的核心部分。他說就在訪談的那一週，有人跑評測發現新模型已經不需要它，這套系統變成技術債，而技術債一旦存在就很難清掉。Hex 目前仍有迭代次數的硬上限，Izzy 說他希望沒有「最後一輪」；讓使用者跟著看的步驟，他預期也會被拆掉。

他認為留下的是兩樣東西。一是領域專家的意見被編進工具，例如視覺化專家直接把看法寫進 Agent。二是他稱為 context exhaust 的使用副產物：使用者在 Hex 裡做出的成果與答案，變成可能經過驗證、可以引導 Agent 後續工作的資訊，他說領域意見只占一小塊，剩下的大部分價值來自這個副產物。他的一個直白判斷：第 0 天，裝了 Snowflake 連接器的 Claude 大概一樣好；價值是隨時間累積的，到了第 90 天，已經是不同層級的比賽。這同時是 Hex 的產品定位，讀的時候要記得 Izzy 是賣這個產品的人。

我把六個機制丟進 Barry 的問題。語意模型、背書、回饋迴路都在記錄「我們公司怎麼定義正確」，模型再強也補不出這份定義，我判斷它們留下的機會最大。「讓使用者跟著看」的介面與 Izzy 自己的預期一致，模型變快後就可能拆掉。這個分法是我依 Izzy 的兩個例子推的，他沒有逐項講過。如果只能先做一件事，我會先做陷阱題，成本最低，也不必等其他機制到位；如果下一代模型開始主動質疑 900% 這種數字，最先告訴你的會是陷阱題。

那份 900% 的儀表板，現在怎麼辦？

回到開頭那份儀表板。Izzy 的測試裡，模型缺的是有人說出的那一句「這看起來不對」，補上之後十秒就找到錯誤。你的資料 Agent 回答大家都超標時，先替它補上這一句，再決定要不要拿去開會。

常見問題

Hex 的語意模型、背書和指南，誰有權設定？

依 Hex 文件，只有 Admin 與 Manager 能建立、編輯並發布指南與語意模型，背書也只有他們能設定；Editor 與 Explorer 只能檢視分頁。三項都在 Team 與 Enterprise 方案提供。這幾頁文件沒有標更新日期，內容以 2026-10-23 讀取的版本為準。

90 天模擬的 24% 是 Hex Agent 的成績嗎？

否。24% 是 Hex 工程師 Izzy Miller 以虛構公司的資料模擬 90 天工作後，Claude Sonnet 4.6 的得分；第 0 天約 4%。模型要處理工單、追蹤線索並整理筆記。測試用的是他自建的測試框架，尚未測過 Hex 的 Agent，不能用來判斷 Hex 產品答對幾成。

30 到 50 題的陷阱題集夠用嗎？

Hex 工程師 Izzy Miller 在 LangChain《Max Agency》訪談裡沒有提出通用題數。他的困難題集約 30 到 50 題，每題重跑多次，希望每個失敗原因都能記在腦裡；另有一組具標準答案的一般題集，用來防止退步並評估新功能。

Izzy 為什麼不把使用者記憶直接放進 Agent 的 context？

Hex 工程師 Izzy Miller 擔心，使用者把說錯或過時的定義存進記憶，會與資料團隊提供的指南、語意模型等參考資訊（context）衝突。內部測試中，Claude Sonnet 4.6 曾反覆思考 30 分鐘；測試看的是思考時間，沒有評估答案正確率。Hex 目前將兩者分開，他說還要更多測試。

延伸閱讀

• LLM Judge 的 Yes/No 清單在成對比較最有證據，直接打分未必
• AI Demo 很成功，為什麼一上線就出事？五條失敗路徑一次看懂（2026）

參考資料

• Izzy Miller、Harrison Chase, How Hex builds AI agents that reason like human data analysts, LangChain《Max Agency》第 1 集，2026-04-09 發布（YouTube 上傳日與 Apple Podcasts 單集日期皆為 4 月 9 日；錄音日期未公開）。逐字稿取自影片字幕，查證日 2026-10-23。 https://www.youtube.com/watch?v=Xyh1EqcjGME
• LangChain, Max Agency（節目頁，主持人 Harrison Chase，LangChain CEO），Apple Podcasts。 https://podcasts.apple.com/us/podcast/max-agency/id1891551672
• Hex, Introducing the Notebook Agent, 2025-08-27。 https://hex.tech/blog/introducing-notebook-agent/
• Carlos Aguilar（Hex Product）, Introducing Threads, 2025-10-01。 https://hex.tech/blog/introducing-threads/
• Hex Docs, Context management（無更新日期，2026-10-23 讀取）。 https://learn.hex.tech/docs/agent-management/context-management
• Hex Docs, Guides（同上）。 https://learn.hex.tech/docs/agent-management/context-management/guides
• Hex Docs, Endorsements in Context Studio（同上）。 https://learn.hex.tech/docs/agent-management/context-management/endorsements-in-context-studio
• Hex Docs, Models（同上）。 https://learn.hex.tech/docs/agent-management/context-management/models
• Hex Changelog, See how your team uses the agent, 2026-09-29。 https://learn.hex.tech/changelog/2026-09-29