AI Engineer onepage / Gates Foundation
速讀 · 資料模型 · 實務檢查
Mike Phipps, Gates Foundation · 20:29
這支影片在講：AI 時代真正的護城河，是你的資料模型
模型、前端與 agent framework 都會商品化；能長期累積的，是組織如何把資料、階層與隱性知識整理成「正確回答問題」的共同語言。
Published: 2026-07-22 · Video ID: jt1Pbr_n6oU
01 / 問題
工具會變便宜，答案不會自動變可信
跨系統問題卡在資料定義不同、階層不同，以及只有資料 owner 知道「組織實際怎麼報告」。
02 / 反轉
知識圖譜不是 dashboard 的附屬品
把 hierarchy 變成可 traversal 的路徑，讓 agent 能用一個 query 橫跨 funding、組織與文件脈絡。
03 / 解法
先建回答問題的資料層
在 ingestion 時完成 chunk、tag 與實體映射；再用 MCP 提供給 Claude，並以 retrieval evals 關住品質迴圈。
Signals
四個讓這套方法不只是「再建一個 RAG」的訊號
History
25 年
把長期 grantmaking 的脈絡留在同一份可查詢模型裡。
Annual scale
$7B / 年
資料模型要能承受真實營運規模，不只支援 demo。
Graph scope
2,000 grants
資助、組織、人員與文件之間的關係是回答問題的證據。
Access layer
1 MCP
用單一受控入口把知識圖譜服務給 Claude，而非把上下文散落各處。
Core story
資料護城河由三件難以複製的事組成
01
把「資料存在」升級成「資料能回答」
一個問題常同時牽涉 grant、受資助單位、人員、預算與文件。資料模型要先定義實體與關係，agent 才能把模糊問題翻譯成有邊界、有來源的圖譜查詢。
02
把隱性知識拉進資料治理
欄位名稱與 schema 本身不會告訴模型報表口徑、例外規則或誰有最終解釋權。持續邀請資料 owner 校正模型，才會把這些 tacit knowledge 變成可重用的組織資產。
03
讓非結構化內容落在結構化座標上
文件不是孤立 chunk：在 ingestion 時切分、標記並連到 grant、計畫或人員等實體，agent 才能同時取得敘事證據與可計算的營運資料。
Architecture
影片拆出的 agentic retrieval 工作流
1. 對齊問題與報告口徑
先找出組織真正會問的跨系統問題；定義實體、hierarchy 與關係，而非從 embedding 或 UI 開始。
2. 在 ingestion 建立連結
將 unstructured documents chunk、tag，再對映到結構化實體；這是之後可追溯回答的前提。
3. 以 graph query 取回答案
agent 透過 MCP 存取一份可 traversal 的 shared state，將原本要人工拼湊的問題化為一次受約束的查詢。
4. 用 evals 校準「有沒有答對」
retrieval evals 不只看回傳內容；也要檢驗結果是否符合組織實際的報告方式與資料定義。
Use this
做企業 agent 前，先用這五題檢查資料層
你的核心問題能否說清楚實體、關係與口徑？若不能，先不要急著挑模型或 framework；答案邊界還沒有被定義。
資料 owner 是否能參與標註與例外規則的校正？這些隱性知識正是競爭者最難從公開資料複製的部分。
文件能否回連到具名的業務實體？單純 chunk retrieval 容易失去上下文；把文件掛到 graph 才能同時查關係與證據。
MCP 是否是受控、可觀測的資料入口？讓 agent 走一條可治理的 access layer，而不是每個 workflow 各自拼 context。
eval 能否抓到「口徑正確」而不是只抓到「看起來合理」？把真實任務、資料 lineage 與人工回饋放回 retrieval 的品質迴圈。
Source video