AI 數據分析最危險的情況，通常不是加總失敗，而是用錯分母、時間窗或 JOIN 後仍產生一個「很像答案」的數字。若取數邏輯只藏在聊天過程裡，團隊甚至無法指出錯誤發生在哪一步。
正確運算，也可能回答錯問題
考慮一句常見需求：「比較 6 月和 5 月的付款轉化率。」它至少有五個未決條件：
- 分母： 造訪者、註冊者、建立訂單者，還是進入付款頁的人？
- 時間窗： 依事件發生月，還是依 cohort 的註冊月？
- 粒度： 一人一筆、一個 session 一筆，還是一個訂單一筆？
- JOIN： 訂單接明細後，一筆訂單是否被商品數放大？
- 新鮮度： 6 月資料是否已結算，退款與取消是否已回補？
假設 SQL 把 10,000 筆訂單 JOIN 到 28,000 筆明細，再直接 COUNT(*)，資料庫會精確地回傳 28,000；錯的不是算術，而是分析者把「明細列」當成「訂單」。如果模型接著寫出流暢解讀，錯誤反而更不易察覺。
企業 Text-to-SQL 的原始研究也提醒我們，真實任務遠超過「看 schema 後組 SQL」。Spider 2.0 的 632 個企業工作流程題目常需查找 metadata、方言文件與專案程式；論文最新修訂版摘要中的 o1-preview code agent baseline 解出 21.3%，這個成績只代表該資料集與設定，不能直接當作所有 AI 工具的準確率。Spider 2.0 論文
2026 年提出的 EntSQL 更聚焦內部指標、報表慣例與組織規則：多數題目需要超出問題與 schema 的領域知識。這支持一個務實結論：模型不只要會 SQL，還要取得正確的業務 context，而且這些 context 必須可被查核。EntSQL 原始論文
四層防線：讓錯誤在決策前現形
1. Plan：先把「怎麼算」寫成人話
Plan 至少寫明決策問題、分母、粒度、時間範圍、join key、排除條件與資料截止時間。這不是形式文件，而是讓 PM、財務或營運在不讀 SQL 的情況下，先阻止錯誤口徑進入正式執行。
2. SQL：保留可審閱的取數證據
SQL 應讓審閱者看見 FROM、JOIN、WHERE、GROUP BY 和時間邊界。自然語言適合解釋意圖；SQL 適合回答「到底哪些列被算進來」。即使 SQL 是 AI 起草，也不應只存在模型的隱藏執行環境。
3. Checkpoint：刻意找反證
在正式結論前加入最小驗證：
SELECT
COUNT(*) AS rows_after_join,
COUNT(DISTINCT order_id) AS distinct_orders
FROM joined_orders;
再核對分子與分母、NULL 比例、最大／最小日期，以及抽樣五筆原始紀錄。Checkpoint 的目的不是證明模型一定對，而是讓 fan-out、漏資料或資料尚未結算有機會被看見。
4. Limitations：把不知道的事也交付
Report 應說明資料截止日、未涵蓋欄位、代理指標、樣本偏差與不能推論的因果。美國 NIST 的生成式 AI 風險框架將錯誤或虛構內容列為需要管理的風險，治理行動包含測量、監控與文件化，而不是只要求模型「更小心」。NIST AI 600-1：生成式 AI 風險管理框架
Lantide Data 如何讓過程可查
在 Lantide Data 的 Project Analysis 裡，Agent 先探索資料並草擬 Plan；使用者可在文件上批註分母、時間範圍與 checkpoint，滿意後才按 Execute。執行時的 SQL 分頁、查詢步驟與 Report 共同保留分析證據；產品的 SQL-first 分工可見分析師實務指南，狀態與工具邊界可見Agent 架構說明。
這些機制降低的是「錯誤無法被發現」的風險，不是把 AI 變成永不犯錯的分析師。業務定義、資料品質與最終決策仍由人負責；若來源資料本身缺漏，Plan 和 SQL 只能把限制揭露出來，不能憑空補齊真相。
結語
不要只問「AI 算得準不準」，更該問：「我能不能重建它的分母、資料範圍與每一步取數？」下次把 CSV 或 Excel 交給 AI 前，先要求一份 Plan、一段可見 SQL、一組反證 checkpoint，以及 Report limitations。答案慢一點，但更有資格進入決策。