同一個「營收」，公司裡可能有三種答案
老闆問「上週營收掉了嗎？」財務看已付款訂單，行銷看廣告歸因，營運可能把退款前金額也算進去。現在再加一位會用自然語言查資料的 AI，如果沒有先說清楚定義，它只會更快交出第四種答案。
Google Cloud 在 2026 年 7 月 29 日整理 Conversational Analytics 的最新狀態：BigQuery 與 Looker 版本已正式推出；AlloyDB、Cloud SQL 與 Spanner 的資料庫版本則處於預覽階段。建立在不同資料來源上的 Conversational Analytics Agent，也可發布到 Gemini Enterprise。
7Pyramid 觀點
真正值得台灣中小企業注意的，不是「終於不用寫 SQL」，而是先把商業定義、資料權限與驗證邏輯整理好。否則自然語言只是讓錯誤定義更容易被查詢。
資料看得到，不代表 AI 知道怎麼算
把 AI 接上資料庫，就像請一位很會算帳的新同事進倉庫。貨架都看得到，不代表他知道「有效訂單」要不要排除取消、測試單與退款，也不代表每個人都應該看到客戶個資。
Google Cloud 表示，Conversational Analytics 可利用 Knowledge Catalog 的詞彙表與資料說明、Looker 語意層，以及 Golden Queries 等已驗證邏輯，降低 Agent 猜測 SQL join 或指標定義的機會。它也支援列與欄層級的存取控管、查詢成本監控，以及 Agent 健康狀態、工具使用、延遲與 token 用量等觀測資訊。
官方 API 文件同時提醒，這仍是早期技術，輸出可能看似合理卻與事實不符，使用前應驗證。因此，「可以聊天問資料」不等於「答案可以直接拿去下決策」。
今天先做一頁六欄 KPI 字典
| 欄位 | 要寫清楚的內容 |
|---|---|
| 指標名稱 | 例如「淨營收」，避免同一指標使用多個稱呼。 |
| 商業定義 | 這個數字代表什麼，也明確寫出不代表什麼。 |
| 計算方式 | 使用哪些欄位、公式與篩選條件。 |
| 排除項目 | 退款、取消、測試資料與內部交易是否排除。 |
| 資料來源與更新頻率 | 來自哪張表或系統，多久更新一次。 |
| 負責人與驗證問題 | 誰核准定義，以及用哪些已知答案核對。 |
例如：「淨營收＝已付款訂單金額－已完成退款；排除取消單與內部測試單；每天上午更新；由財務主管核准。」接著準備三個答案已知的問題，例如某一天、某產品線與某客戶群的淨營收。未來無論使用 BigQuery、Looker、試算表或其他 AI 工具，都先用這三題驗證。
先讓人對答案，再讓 AI 對答案
今天先花 20 分鐘，找財務、行銷或營運的指標負責人，選一個每週真的會影響決策的 KPI，把六欄填完，再寫下三個已知答案的驗證問題。若兩位同事對定義仍有不同解讀，先處理定義，不要急著接 Agent。
之後若採用 Conversational Analytics，再同步設定最小必要權限、查詢成本上限、操作紀錄與人工複核。官方文件說明 API 可用自然語言查詢多種資料來源，用戶端也可記錄回應以形成可稽核的資料對話；成本文件則提供專案、使用者與單次查詢的限制方式。
AI 資料 Agent 最有價值的地方，是縮短「問題到洞察」的距離；但它不會替公司決定什麼叫營收、誰能看客戶資料、哪個答案可以拿去開會。先把 KPI 字典寫清楚，才不會讓每一次自然語言提問，都變成一次自然發生的誤會。
常見問題
已有報表，為什麼還需要 KPI 字典？
報表呈現數字；KPI 字典記錄數字背後的商業定義、計算、排除條件、資料來源與負責人。這些規則才是讓人與 AI 得到一致答案的基礎。
導入資料 Agent 前應先測什麼？
先準備三個已有正確答案的問題，確認日期、產品線與客群等條件下的結果都一致，再逐步開放使用與權限。
自然語言查資料可以直接取代人工分析嗎？
不建議直接取代。官方文件明確提醒輸出需要驗證；重要決策應保留最小必要權限、成本限制、操作紀錄與人工複核。