- 登入
- 註冊
資料分析 Agent 像新手？Uber 與 Google 的 2 個設計啟示
內容目錄
顯示
對許多數據人來說，最耗時間的往往不是分析，而是找到可以分析的資料：登入不同系統、確認哪份報表最新，再詢問同事欄位與指標的意思。
Uber 的財務團隊也曾面臨這些困難。為了取得資料，分析師需要跨平台查詢、撰寫 SQL，或等待其他團隊回覆。Uber 因此開發了 Finch，讓使用者直接在 Slack 裡用自然語言提問，由系統協助尋找資料、產生查詢並回傳結果。Uber Finch 官方介紹
但把問題交給 AI，並不代表分析就會正確。
Agent 可能寫出能執行的程式，卻選錯資料、誤解指標，最後交出一份看起來完整、實際上回答錯問題的報告。
這也是為什麼資料分析 Agent 常像剛到職的新同事：工具會用，卻還沒弄懂公司的語言與工作規則。
從 Uber Finch 與 Google DS-STAR 的設計，可以整理出兩個重要提醒：行動前先看懂資料，行動後再檢查與修正。
核心問題
資料分析 Agent 的難點，不只是「能不能寫 SQL 或 Python」，而是：
它知道自己應該分析什麼嗎？做完之後，又能不能發現分析方向有問題？
例如，使用者要求比較兩季的營收，Agent 即使順利產生圖表，也可能忽略幣別、退款排除條件，或兩份資料採用不同的統計口徑。
這些錯誤不一定會讓程式報錯。相反地，程式可能正常執行，結果卻不符合業務需求。
因此，可靠的資料分析流程，需要同時處理兩件事：讓 Agent 取得足夠的資料背景，以及讓它在執行後有機會檢查方案、修正方向。
關鍵洞察
一、行動前先觀察：別讓 Agent 靠猜測理解資料
這裡的「觀察」，指的是先理解資料的結構、內容與業務意義，而不是收到問題就立刻開始寫程式。
Uber Finch 的做法，不只是提供資料庫欄位名稱。它也整理常用資料來源，並透過 OpenSearch 保存欄位、欄位值及其自然語言別名，幫助 Agent 把公司內部的說法，對應到正確的查詢條件。Finch 架構說明
Google DS-STAR 則面對不同格式的資料檔案，由 Data File Analyzer 先整理結構與內容摘要，作為後續規劃的依據。資料量很大時，也能透過檢索模組挑選相關檔案，而不是把所有內容直接塞進模型。DS-STAR 論文
兩者的設計並不相同，但都提醒我們：要讓 Agent 分析得好，先讓它知道資料是什麼，比直接要求它「算出答案」更重要。
實務上，可以先整理指標定義、欄位說明、資料更新時間與常見限制。這些背景，能減少 Agent 在分析起點就走錯方向。
二、行動後再反省：程式跑得動，不代表問題已經解決
Finch 遇到 SQL 執行錯誤時，可以參考錯誤訊息改寫查詢。但修正語法，和確認分析是否合理，是不同層次的工作。
DS-STAR 因此加入「規劃、執行、驗證」的循環：
- Planner 規劃分析步驟。
- Coder 將計畫轉成程式並執行。
- Verifier 根據問題、計畫、程式與執行結果，判斷目前方案是否足以回答問題。
- 如果方案不足，Router 再決定補上步驟，或退回有問題的地方重新規劃。
重點不只是反覆重跑，而是根據回饋，判斷究竟該修正哪裡。Google DS-STAR 官方介紹
在 DABStep 困難任務中，使用 Gemini 2.5 Pro 的官方基線正確率為 12.7%，DS-STAR 配置則達到約 45.2%。不過，這是不同系統流程與運算設定的比較，不能把差距全部歸因於兩項機制，也不能直接當成企業導入後的成功率。研究結果
此外，Verifier 仍依賴語言模型判斷，通過檢查不等於答案一定正確。正式應用仍需要搭配業務規則、已知答案或人工審查。
好的反省機制，不是讓 AI 說「我再想想」，而是讓它有依據地檢查，並知道下一步該改什麼。
行動方案
參考這兩個案例，可以把資料分析 Agent 的核心責任，整理成「規劃、執行、驗證」三個部分。這是簡化的設計思路，不是要求每個團隊都照搬完整架構。
1. Planner：先把問題說清楚
規劃者需要確認分析目標、指標定義、時間範圍與資料來源，再拆解執行步驟。
例如，「最近業績是不是變差了？」並不是完整的分析需求。要先釐清業績指營收、訂單量還是毛利，以及應該和上個月、去年同期，還是預算比較。
遇到會影響結論的模糊條件，應先詢問，而不是自行猜測。
2. Coder：依照計畫執行，留下可核對的紀錄
執行者負責產生 SQL 或 Python，進行查詢、整理資料與視覺化。
除了回傳結果，也應保留使用的資料來源、查詢條件、程式與錯誤訊息，讓後續檢查有依據。
查詢失敗時可以修正，但不能為了讓程式跑通，就默默改掉原本的分析要求。資料存取也應遵守既有權限。
3. Verifier：檢查結果，並把問題退回正確的位置
驗證者不能只確認「有沒有產出」，還要檢查：
- 指標、期間與單位是否符合需求？
- 是否漏掉必要的篩選條件？
- 結果是否合理，且足以支持最後的結論？
如果有問題，就要明確指出應補資料、改計畫，還是重寫程式。也需要設定修正次數與停止條件，避免無限重試；無法確認的結果，應交由人工判斷。
這三類責任不一定要由三個獨立模型承擔，也可以由同一套系統搭配不同步驟與工具完成。重要的是責任、回饋與驗證流程清楚，而不是 Agent 的數量多。
團隊可以先選一小組真實分析問題，建立可核對的答案與檢查條件，再比較每次調整是否改善正確性，以及增加了多少時間與成本。
金句啟發
「好的資料分析 Agent，不只會寫程式，還會先弄懂資料，再檢查自己有沒有回答對問題。」
延伸閱讀
[2] Google DS-STAR：透過迭代規劃與驗證改善資料分析｜DS-STAR: A state-of-the-art versatile data science agent（Google，2025）
以上文章整理自【數創電子報 Vol.17】為什麼你的「數據分析師 Agent」像笨笨的實習生？來看 Uber 與 Google 怎麼做
重點整理
為什麼資料分析 Agent 會寫程式，仍可能做出錯誤分析？
因為程式能執行，不代表資料來源、指標定義與分析條件都正確。如果 Agent 不理解公司的術語、資料限制或統計口徑，就可能用錯誤的方式，回答原本的商業問題。
「觀察」與「反省」機制，分別解決什麼問題？
觀察是在執行前，理解資料結構、業務定義並選出相關內容；反省則是在執行後，根據結果與回饋，檢查方案是否足夠，再決定補步驟或退回修正。兩者讓系統不只會產出，也有機會發現與改善錯誤。
打造可靠的資料分析 Agent，一定要拆成很多個 Agent 嗎？
不一定。Planner、Coder、Verifier 代表三類責任，不是強制的模型數量。團隊應先建立清楚的規劃、執行與驗證流程，再用真實問題確認效果；只有當分工確實帶來改善，才值得增加系統複雜度。
