你的护城河是你的数据模型——Mike Phipps(盖茨基金会)

Mike Phipps · AI Engineer

AI 产品 Agent 工程投资

视频 20:29 原文约 1.9 万字预计阅读 11 分钟来源视频 ↗ 中英对照全文

原平台热度 YouTube ↗

8,108观看

187赞

2.3%点赞率

7评论

62.7万频道订阅

数据截至 8 月 27 日

双人对谈 · 本期速读电台 00:00 / 12:09

TL;DR · 三句话

一讲者 Mike Phipps（Gates Foundation） 的核心论断：AI 前沿跑得越快，模型、chat 界面、agent 框架就越会被商品化，唯一持久、有防御力的 moat（护城河，能长期挡住对手的东西），是你对内部流程的理解——即"一个问题该按什么口径回答"的 tacit knowledge（隐性知识，写不进文档、只在老手脑子里的经验），连同承载它的 data model（数据模型，即业务对象及其关系的组织方式）。→ 详细
二在 Gates Foundation，他把 25 年、每年 超 70 亿美元 拨款、约 2000 笔资助（grant）、覆盖 100 多个国家、涉及 4000 名员工 的 grantmaking，全部建模进一张 Neo4j knowledge graph（知识图谱，把实体和它们的关系连成一张网），构成上月刚上线、供全基金会使用的企业级"战略情报平台"（SIP）。→ 详细
三这张图谱是"为 agent 而非仪表盘"而建：四个孤立源系统被共同实体缝合成一张图、一层语义层，通过 单个 MCP server（让 Claude 调用外部数据/工具的标准接口） 暴露给 Claude，agent 在查询时自行遍历、推理作答，而 eval（评测）又反向暴露数据模型的缺口、形成闭环。→ 详细

护城河是什么：不可防御的 vs 可持久的（益项 · 写厚）

开场框架：AI 在前沿跑得极快，用 Claude Code 几下就能把东西搭起来；但一旦推到生产环境，约束就冒出来——监控、维护、还有别人基于你技术栈建的依赖都得接住。真正该问的是："这套已部署的技术栈，你到底想真正拥有其中多少？" → 详细
与 SaaS 的差异化：用户入口是又一个 chat 应用吗？是 Claude、ChatGPT 还是别的？相比这些 SaaS 你的差异化在哪？团队据此反问自己的技能与竞争优势，得出结论——我们的护城河来自对内部流程的理解。 → 详细
什么才 durable：那份"成功跑起 AI 所必需"的隐性知识，无论模型多强、无论出什么新版本（Mythos 发布也好、Claude 出新应用也好）都动摇不了。讲者原话："我不担心，因为我们构建的这一部分才是有防御力、能长久持续的。" → 详细

SIP 平台与 Gates Foundation 的规模（紧凑 · 保数字）

SIP：把这些流程与隐性知识建模进"战略情报平台"（Strategic Intelligence Platform，SIP），上月刚上线生产，供整个 Gates Foundation 约 4000 人 使用。 → 详细
基金会背景：做了 25 年多，范围极广——儿童死亡率、营养、农业、教育等；工作分四类（创造市场激励 / 激发创新 / 公私协作 / 用高质量数据从投资中提炼洞见），最后一类正是此次建模的视角。 → 详细
一年量级：>2000 笔 grant（很多单笔 500 万美元以上）、覆盖 100+ 国家、4000 名员工、几乎覆盖全美各州、每年总拨款 >70 亿美元；25 年沉淀海量数据，"大规模提炼洞见很难"正是要解决的问题。 → 详细
部门：资金通过不同 division 发放——global development（全球发展）、global health（全球健康）、gender equality（性别平等）、USP 等只是示例。 → 详细

端到端架构：把运营数据结构化，供 agent 检索（益项 · 写厚）

一句话定义 SIP：把运营数据结构化以支持 agentic retrieval（面向 agent 的检索——让 AI 自己进图里查、去推理，而不是人盯仪表盘），核心理念是"把 agent 当数据消费者"来建知识图谱；源头是各类 systems of record（记录系统，即 HR / 财务等数据原本各自存放的源系统），结构化与非结构化都有，传统上彼此孤立。 → 详细
数据湖仓：先把所有东西汇到一处，建成 data lakehouse（数据湖仓）——含企业内部全域数据与各投资产出的项目性数据。 → 详细
加工到交付：一个 data curation（数据治理/加工） 层做处理，末端是 SIP，以 agentic chat / workflow 为 UX；整体是"一个跨系统的语义图层，agent 在其上推理"。 → 详细

真正的护城河：隐性知识在 data owner 那里（益项 · 写厚）

engagement（沟通协作）是关键：处理极复杂的记录系统时，必须反复找 data owner（数据负责人） 沟通，才能建模隐性知识——字段的完整含义、数据集结构、各部分怎么 join、数据的局限与系统性偏差、安全权限过滤、报告惯例。 → 详细
关键金句："仅仅用某种方式把问题答出来是不够的，你必须按过去一贯的方式来回答它。"（you have to answer it the way that it's been answered in the past.）这份流程化的理解与口径，正是 AI 需要、且属于他们自己的护城河。 → 详细

数据 curation pipeline 的三类考量（紧凑）

预处理：结构化/非结构化各有预处理、过滤、去重（deduplication）；文档间有先后、也可能互相矛盾，须前期就处理好。 → 详细
抽取：结构化字段抽取、对非结构化文档做 semantic chunking（语义分块，把长文切成有意义的小段）、图表转文本以便检索、各种打标签（在图里形成连接）、pipeline 生成的 metadata 会变成图里的属性。 → 详细
治理（governance）：AI 让原本能取到的数据"更易取到"，风险面变大——PII（个人身份信息） 要脱敏、敏感数据重新分类、每个用户要有恰当权限（entitlement）。 → 详细

知识图谱数据模型：层级、rollup 与多视角（益项 · 写厚）

图为何灵活：graph 是对物理模型很实用灵活的表示。入口是 80 多个战略团队，它们每年做年度评审、由此定预算，这一过程被建模进图；会议是非结构化文档进入系统的入口，同时与其它记录系统保持结构化连接。展示的是概念模型（扁平），真实图有海量 node（节点）、基数一对多（one-to-n），复杂得多。 → 详细
层级一 = 可累加 DAG：这是个 DAG（有向无环图），五层从上到下全都有意义、须一起考量；可用不同 rollup（汇总，把下层往上聚合） 贯穿，还有一条 in-path 快捷连接把资金路径连起来，funds-to-BoW 存放各资金团队预算。 → 详细
funding（资金）视角：资金团队各有 portfolio（投资组合），portfolio 流向不同 investment（投资），多团队共资一笔投资（多对多）——"投资才是我们真正的产品、我们的业务"；可细到 transaction（交易）、也可年度聚合；从投资还能映射到各类 organization（组织），此处仍有大片"待填空白"，投资产出的报告/产品等成果也结构化挂回组织全景。 → 详细
层级二 = 管理视角：每层各自独立有意义、不一定是 DAG；可预计算快捷边——第二层团队直接管理某投资是 direct，其子级的东西仍归属到第二层团队则是 indirect；rollup-manages 是在 contains 与 manages 边之后派生的边。于是同一笔投资有了 funding 与 management 两个 lens（视角）。 → 详细
层级三 = 人：owner、参会者、director 等角色、汇报关系、团队结构，都是可跨系统连接的结构化数据——传统只躺在 HR 一个源系统，如今对"理解完整故事"很关键；要让 agent 跨结构正确理解全貌，就得找共同的 entity（实体，如某笔投资 / 某团队 / 某人） 把孤立源系统缝合（stitch）起来。 → 详细
文档的魔力：会议→文档→语义段落 / chunk，之上建全文索引辅助检索、也支持纯 graph 检索，全用 Neo4j（主流图数据库） 建模并连回主组织结构——"把非结构化与结构化结合正是这里的魔力"（目前只接入一个文档源，仍有很多可做）。 → 详细

整张图 +"为 agent 而非仪表盘"而建（益项 · 半厚）

整体形态：四个不同系统、一张图、一层语义层，通过一个 MCP 暴露给 agent——这就是整个 data model 的样子。 → 详细
两种受益：站 agent 视角，这是它在 query time（查询时）能动态发现并推理的结构；站开发者视角，它把"你其实并不了解自己建模对象的地方"暴露出来——你很快发现理解有缺口、有数据集没纳全，"这个过程本身就极有价值"。 → 详细

通过 MCP 交付：到用户所在处 + 受约束工作流（紧凑）

不可防御的是 UI：讲者重申 chat 界面、UI、甚至通用 agent 交互都不是护城河；要"到用户所在处服务他们"（他们可能已在用 ChatGPT），现通过 MCP 提供。Neo4j 有现成 MCP server，团队 fork 后大改、更新 schema，还改工具把状态（对话 id、消息编号）传回自家系统。 → 详细
受约束工作流：更 constrained（受约束）的体验可通过 co-work、Claude chat 提供——让 MCP app 成为标准入口、把 UI 移植进 chat、用基于 sandbox 的 agent 跑工作流；它约束了体验，但仍从同一个知识图谱后端取数。 → 详细

Eval 与 data model 的闭环（略相关）

eval 暴露缺口：做 eval 会发现 data model 的缺口、歧义、"不符合报告标准（reporting standard）"的答案；于是与 data owner 合作，构建匹配报告标准、分 complexity tier（复杂度层级）的针对性 eval 问题。因结构化数据不断变，团队为每题写好 graph query、运行时从 live（实时）图拉数再与 agent 输出对比。 → 详细
反馈闭环 + 指标：用 LLM as a judge（用大模型当裁判打分） 衡量 pass@1（一次就答对的比例） 与 stability（稳定性，同题问多遍答案是否一致），据此回头更新 data model、领域规则、schema 描述来补缺口。 → 详细
结果：pass@1 与稳定性已做得非常强；剩下答错的多是"有歧义"的题——不算错，只是"对但不是用户想要的那个"。 → 详细

SIP 路线图与收尾（紧凑）

接下来：补全符合当前模型的记录系统数据；把主图扩展到更多全公司数据集；应对对 federated graph（联邦图，多团队各自的图联合起来查） 的大量需求（团队想把自有数据链上来）；推进前述各种 agentic 体验。 → 详细

闪电问答 / 收尾

本场为单人主题演讲，无独立的 lightning round / 闪电问答环节。收尾即上文的 SIP 路线图（补全记录系统数据、扩展主图、联邦图、更多 agentic 体验），讲者随后邀请听众会后当面交流或在 LinkedIn 上继续讨论。 → 详细

联系方式

Mike Phipps（Gates Foundation，战略情报平台 SIP 团队）——会后在场外面对面交流，或在 LinkedIn 上添加他继续讨论。 → 详细

接着读

NO.91 · Agent 工程我们为什么砍掉了自己的多 agent 流水线——ZS Associates Subbiah Sethuraman · 10 分钟 NO.90 · 产品 AI 时代 Netflix 为什么押注系统思考者而不是专才——Elizabeth Stone(CPTO) Elizabeth Stone · 33 分钟