摘要
建立 Cortex Agent 前，先把 Datamart 的業務邏輯整理成可驗證的問題與 Ground Truth（驗收依據）。本文以我負責的一條 Datamart pipeline 為例，說明如何用公司核准的開發用 AI 助手盤點候選問題，據此設計 Semantic View，再分別驗證 Cortex Analyst 與 Cortex Agent。若需求只有結構化資料問答，流程可以停在 Cortex Analyst；需要跨文件、工具或多步驟協調時，才進一步建立 Cortex Agent。答案穩定之後，再透過 MCP 提供給外部應用。
最近在實作 Snowflake Semantic View、研究 Cortex Agent 與 MCP 的過程中，我原本以為，把資料表接進 Agent，就能讓使用者開始提問。
真正動手後，第一個卡住的卻不是設定，而是問題清單：我們究竟要它回答什麼，又準備用什麼答案驗收？
這篇提到兩種不同角色。下文的「開發用 AI 助手」是協助整理需求與草擬設定的工具；「Cortex Agent」則是部署在 Snowflake、實際回應使用者的正式 Agent。兩者用途不同。
資料表接上 Agent，為什麼還是可能答錯？
我在公司負責一條 Datamart pipeline。因為參與開發與維護，我知道資料從哪裡來、經過哪些轉換，也比較清楚指標如何計算、哪些資料需要排除、狀態如何解讀、應該使用哪個日期欄位，以及哪些表能安全關聯。
這些規則通常不會完整出現在資料表裡。它們散落在 SQL、程式碼、需求單、文件，以及開發者自己的理解中。只把欄位名稱、資料型態與樣本值交給模型，它仍然不知道某個數字為什麼要這樣算。
Semantic View 能把業務概念、資料實體與關係集中定義在 Snowflake 的 schema 層級原生物件中。Cortex Analyst 會讀取這些語意定義，再對實體資料表產生 SQL；Cortex Agent 若要查詢結構化資料，則透過 Cortex Analyst 工具使用它。這也是為什麼我不會讓正式 Agent 直接面對原始資料猜測。Snowflake 對 Semantic View 的說明
不過，建立 Semantic View 前還有一個更早的問題：誰會在什麼決策下使用這份資料？答案出來後，他準備採取什麼行動？
AI 助手產生的是問題假設，不是需求答案
我的第一步是把已整理的 pipeline 邏輯、欄位定義與資料用途交給公司核准的開發用 AI 助手，請它提出候選問題；Cortex Agent 留到語意層通過驗證後再決定是否建立。這一步不會提供憑證、個資、實際資料列或不應離開受控環境的商業資訊。
AI 助手可以把藏在 pipeline 裡的規則轉成問題，但它不知道使用者是否真的在意。它產生的是需求假設，還要再用使用者訪談、既有報表、需求單與查詢紀錄確認。Snowflake 的 Semantic View Autopilot 也會參考 Query History，而不只靠模型推測使用情境。Semantic View Autopilot
我會把確認後的問題整理成問題卡。以下內容只示範格式，不是公司實際資料或 schema。
| 業務問題 | 使用情境 | 需要定義的語意 | 預期行為 |
|---|---|---|---|
| 上個月完成的案件有多少？ | 檢查案件量與處理能力 | 業務日期、完成狀態、去重規則、排除條件 | 回答並交代期間與口徑 |
| 這個月的下降主要集中在哪些地區或產品？ | 縮小異常追查範圍 | 比較期間、分群維度、指標定義 | 指出差異來源，不宣稱已證明因果 |
| 完成案件的定義是什麼？ | 確認跨團隊使用的統計口徑 | 狀態、日期與排除規則的文字說明 | 從語意定義或文件回答 |
| 案件為什麼突然下降？ | 尋找原因 | 目前資料只能分析貢獻來源，無法直接證明因果 | 先澄清問題，或明確說明能力邊界 |
這張表會逼我確認四件事：資料是否足以回答、問題是否有多種解讀、答錯的風險有多高，以及系統應該回答、追問，還是拒答。
首頁範例只是問題清單的一種用途；這批問題更重要的工作，是共同驅動設計與驗收。
如何把問題變成 Semantic View 的驗收標準？
問題確認後，我才開始設計 Semantic View。我會把 Datamart 的資料結構、pipeline 中的業務邏輯，以及問題卡一起交給開發用 AI 助手，請它協助草擬 logical tables、relationships、dimensions、facts、metrics、synonyms 與說明。
這裡要特別區分 fact（事實）與 metric（指標）。Fact 是 logical table 中的 row-level 屬性，通常用來描述「多少」或「幾個」；metric 才是跨列聚合後的業務指標。數值欄位仍要根據粒度與計算方式判斷應放在哪一層。Semantic View 概念定義
AI 產出的定義不能直接視為正確答案，尤其是 metric、relationship 與 filter。模型能讀 SQL、推測欄位用途，卻不一定知道某個普通條件背後的業務規則。以下是簡化示意，欄位名稱與條件並非公司實際 schema：
WHERE status = 'COMPLETED'
AND is_test_data = FALSE
AND effective_date <= CURRENT_DATE
這三個條件可能分別代表只有完成案件才能列入正式統計、測試資料不得進入報表，以及尚未生效的資料不能提前計算。Semantic View 除了保存 SQL，還要留下這些條件的業務含義。
對我來說，Semantic View 是資料團隊與業務之間的語意契約。它集中管理結構化資料的指標、維度與關係，減少模型自行猜測的空間，但不能單獨保證答案正確。底層資料品質、更新時間、權限與測試仍然會影響結果。
還有一個需要留意的產品行為：目前 Cortex Analyst 的 Routing Mode 會優先使用 semantic SQL；若 Semantic View 無法涵蓋問題，可能 fallback 到實體資料表的 standard SQL。這項功能目前是 Preview，因此驗證時還要監控 fallback 查詢，不能假設每一段 SQL 都只使用 Semantic View 中的定義。Routing Mode
Verified Queries 與 Evaluation Dataset 有什麼不同？
同一批業務問題會進入兩套驗收機制，但兩者測的東西不同。
Verified Query 保存自然語言問題與已驗證 SQL，可以放進 Semantic View，協助 Cortex Analyst 處理相似問題。Snowflake 也能直接對 Semantic View 執行 Cortex Analyst Evaluation，以 verified queries 作為驗收依據，檢查 SQL correctness、regression 與 latency。建立 Semantic View 的 verified queries、Cortex Analyst Evaluations
Cortex Agent Evaluation Dataset 則測試完整 Agent：它是否選對工具、是否正確執行工具，以及最終回答是否符合預期。官方資料格式是 input query 與 Ground Truth 兩欄；Ground Truth 是 VARIANT，可包含 ground_truth_output 與 ground_truth_invocations。
以下 JSON 只示範格式。實際的 tool_name 必須使用 Agent 中暴露的工具名稱，不能籠統寫成「Cortex Analyst」。
{
"ground_truth_output": "回答必須使用指定期間、完成狀態與排除條件，並回傳驗收快照中的案件數。",
"ground_truth_invocations": [
{
"tool_name": "case_metrics_analyst",
"tool_input": "上個月完成的案件有多少？",
"tool_output": "應使用完成日期，排除測試資料，並以案件 ID 去重。"
}
]
}
Ground Truth 比「標準答案」更接近驗收依據。它可以保存預期輸出、工具、輸入、輸出條件與容許誤差。對會隨時間變動的營運資料，我會鎖定查詢日期或資料快照，並記錄適用期間；不會把某個數字永久當成正確答案。
每筆核心 Verified Query 與 Ground Truth 也要有負責人、確認日期與適用範圍。重要指標應由資料負責人或業務負責人核准。Semantic View 的 verified query 本身支援 VERIFIED_BY 與 VERIFIED_AT，可以把責任與時間留下來。
測試題不能只有完全相同的原句。我會保留最初的業務意圖與驗收依據，再加入同義改寫、不同日期表達、模糊條件、超出範圍的要求，以及歷次失敗案例。原題防止回歸，改寫題測試泛化與澄清能力。Cortex Agent Evaluations
什麼情況真的需要 Cortex Agent？
Semantic View 與 Cortex Analyst 通過驗證後，我會先問：這個需求真的需要 Cortex Agent 嗎？
如果使用者只需要對結構化資料做自然語言查詢，Cortex Analyst 可能已經足夠。需要跨結構化與非結構化資料、拆解多步驟任務、選擇不同工具或保留對話脈絡時，Cortex Agent 才開始有明顯價值。Snowflake 建議的 Cortex Agents 使用情境
Cortex Agent 適合決定問題該交給 Cortex Analyst、Cortex Search、自訂工具或 MCP connector，並把查詢結果整理成使用者看得懂的回答。營收怎麼算、哪些狀態要排除、哪個日期才是業務日期，仍應由 Datamart、Semantic View 與資料治理流程決定。
更精確地說，Semantic View 約束結構化資料如何被理解；Cortex Agent 負責選擇與協調工具。最後的答案是否正確，仍要靠資料品質與 evaluation 驗證。
回答方式也不會只靠 Semantic View 自動改善。我會在 Agent 的回應指令（response instructions）中要求回答列出期間、主要排除條件與指標口徑，但不直接把整段 SQL 丟給使用者。Cortex Agent 支援分開設定規劃指令與回應指令，前者影響工具選擇，後者控制回答方式。設定 Agent instructions
如何驗證 SQL、工具選擇與最終回答？
驗證時，我會先分辨問題出在語意層還是 Agent 層。
- 問題理解：確認「上個月」對應哪個日期欄位、「完成」對應哪個狀態，以及「案件數」是否需要去重。如果語意就理解錯誤，後面的 SQL 能執行也沒有意義。
- SQL 與結果：檢查 join、filter、聚合層級、重複計算、日期與狀態，再把數值、趨勢、分組結果與明細加總對回人工 SQL 或既有報表。這主要驗證 Semantic View 與 Cortex Analyst。
- 工具選擇與執行：確認 Cortex Agent 是否呼叫正確工具，輸入與輸出是否符合預期。這裡才是 Agent 協調流程的驗收範圍。
- 回答是否可用：數字正確還不夠。回答還要交代期間、必要口徑與排除條件；若資料不足，應要求補充資訊或明確說明無法回答。
Cortex Agent Evaluations 提供 Answer Correctness 與 Logical Consistency；Tool Selection Accuracy 和 Tool Execution Accuracy 目前仍是 Public Preview，可用來檢查工具選擇與執行是否符合預期。它們能把人工檢查逐步轉成可重複執行的 regression test，但不能取代資料 owner 對業務定義的確認。Evaluation metrics
MCP 上線後，如何持續監控與修正？
在我的情境裡，MCP 放在答案穩定之後。Snowflake-managed MCP Server 可以把 Cortex Analyst、Cortex Search、Cortex Agent、SQL，以及 UDF／stored procedure 包裝成 MCP tools，提供外部 MCP client 使用。若外部應用只需要結構化資料問答，也可以直接透過 MCP 使用 Cortex Analyst，不必先建立 Cortex Agent。
MCP connector 的方向相反：它把 Jira、Salesforce 或其他遠端 MCP server 的工具接進 Cortex Agent。
Snowflake-managed MCP Server
Snowflake 能力 → 外部 AI client
MCP connector
外部系統工具 → Snowflake Cortex Agent
MCP 不會修正錯誤的 metric，也不會補上不存在的業務規則。對外開放前，還要確認 OAuth、RBAC 與最小權限。取得 MCP server 的使用權不代表自動取得每個工具的權限；第三方 MCP server 與 tool description 也必須先審查。Snowflake-managed MCP Server、MCP connectors
我最後採用的建置順序是：
- 整理 Datamart 的業務邏輯，確認指標、日期、狀態、排除條件與關係。
- 用 AI 助手產生候選問題，再用使用者訪談、報表與查詢紀錄驗證需求。
- 為核心問題建立 Ground Truth，記錄負責人、確認日期、適用範圍與答錯風險。
- 根據問題設計 Semantic View，建立 verified queries，先驗證 Cortex Analyst。
- 判斷是否真的需要 Cortex Agent；若需要，再設定工具、規劃指令與回應指令。
- 用 Evaluation Dataset 測試原題、同義改寫、邊界案例與失敗案例。
- 納入版本管理與部署流程，確認權限後再透過 MCP 對外整合。
Git 保存的是 Semantic View SQL 或 YAML、Agent specification、建立 Evaluation Dataset 的來源資料表 schema、去識別化測試 seed、DDL、evaluation YAML、測試程式和 MCP 設定。實際的 Evaluation Dataset 是 Snowflake 中的物件，還要在部署紀錄中保存版本與環境，不能只把設定檔提交到 Git 就算完成。
流程上線後也不會結束。正式使用時出現的新問題、失敗案例與使用者回饋，應回到問題卡、verified queries、Semantic View 與 Evaluation Dataset：
業務邏輯 → 問題與驗收依據 → Semantic View
↑ ↓
監控與使用者回饋 ← Evaluation ← Cortex Agent／MCP
Agent 可以加快建置，但無法替資料團隊決定指標口徑。需要持續維護的，是使用者要問什麼、正確答案如何定義，以及資料或規則變更後，誰來確認答案仍然成立。