跳到主要内容

大纲 — rag-ready-patterns-for-data-platforms

原书 Early Release 只有 3 个正文章(~12.7 万字符)。切 8 章,一条推理链一章: 01-02 对应原书 ch1(为什么+怎么诊断),03-05 对应 ch2(资产侧的答案),06-08 对应 ch3(执行侧的答案)。

章切分​

  1. 01-consumer-shift.md 消费者换了:仪表盘喂不饱模型(原书 ch1 前半)
  2. 02-three-pillars.md 三根支柱:给平台做一次 RAG 就绪体检(原书 ch1 后半)
  3. 03-entity-kernel.md 聪明实习生测试与实体内核(原书 ch2 模式一)
  4. 04-semantics-at-source.md 源头语义:把「是什么意思」写进契约(原书 ch2 模式二)
  5. 05-layers-single-truth.md 分层与可移植定义:守住单一事实来源(原书 ch2 模式三~六)
  6. 06-enforcement-gap.md 执法缺口:数据是怎么说谎的(原书 ch3 前半)
  7. 07-pipeline-contract.md 管道契约:五份可执行的保证(原书 ch3 契约四组件)
  8. 08-pipelines-as-code.md 管道即代码、托管平台与活元数据(原书 ch3 后半)

节级大纲(进来时以为 → 出去时知道)​

01 消费者换了​

  • §1 现象:同一个问题,人查得动模型答不动 → 知道:LLM 缺的不是智能是企业上下文
  • §2 消费者换人:平台为谁建的就为谁优化 → 知道:仪表盘时代的成功标准(聚合/预定形问题)与 RAG 时代(检索/开放式问题/可引用)是两套
  • §3 缺口的五个成因 → 知道:不是没数据,是碎片化/浅语义/报表化治理/元数据只当文档/质量在仪表盘不在代码
  • §4 作者是谁、凭什么听他们的 → 知道:四位微软 IDEAS 负责人,数百 PB 平台;data as a service → data as an AI service
  • §5 边界 → 知道:Early Release,书许诺的模式只出了 3 章;不讲 RAG 检索/生成机制本身

02 三根支柱​

  • §1 自检框架:三支柱 → 知道:数据资产/基础设施/信任层,每根问一个问题
  • §2 支柱一 数据资产 → 知道:RAG 要连通的知识;实体内核三层;成熟度 1-4 级,多数在 1-2 级
  • §3 案例:三个「用户」 → 知道:失败不在模型在资产层;分子分母对不上
  • §4 支柱二 基础设施 → 知道:转换会侵蚀语义;契约先行/管道执法/质量即服务/统一索引;案例「昨天的数」
  • §5 支柱三 信任层 → 知道:人类时距 vs 毫秒时距;SBAC=按场景授权;案例 PII 事故→一个月落地
  • §6 可带走的自检清单 → 知道:拿三张表给自己打分

03 实体内核​

  • §1 聪明实习生测试 → 知道:模型和实习生缺的是同两样:业务词汇+资产目录
  • §2 元数据缺口 → 知道:能当骨架的元数据=管道中捕获/声明式/每源有语义/当前可信
  • §3 实体内核模式 → 知道:core + 扩展表,同一 durable ID 串起;五要素
  • §4 走查:一个 TenantId 走完五张扩展表 → 知道:逻辑视图怎么回答「这个租户是谁、用了多少、什么行业」
  • §5 治理清单 → 知道:没有硬执法的模式会被绕过;八组检查火力集中在实体工件

04 源头语义​

  • §1 schema 不是语义 → 知道:结构描述形状,语义描述每行每列该作何理解
  • §2 语义捕获的度 → 知道:不追求穷尽,「刚好够写业务逻辑」
  • §3 走查:CreateCopilot_Intent 事件 → 知道:同一份 schema,语义决定 hover 算不算一次「意图」
  • §4 ESA 模板 → 知道:一份事件源协议该写哪七块(目的/汇点新鲜度/规范事件/版本/可测性/所有权)
  • §5 为什么钉在源头 → 知道:事件含义会随代码演化悄悄改变;契约没写的假设不该进代码

05 分层与可移植定义​

  • §1 无界分层的两种病 → 知道:同指标不同值;循环依赖让解释都难
  • §2 七层与依赖规则 → 知道:Core/Dimensions/MetricBases/Metrics/Segments/EventSinks/References;Metrics 不准依赖 Metrics
  • §3 走查:一个 DAU 指标的 JSON 配方 → 知道:read→join→join→aggregate 每步落什么数;dau 从哪个列来可追溯
  • §4 元数据 API → 知道:七个端点让 RAG 应用能问「这指标怎么定义的、能不能用、上游是谁」
  • §5 与声明式的关系 → 知道:SQL/JSON 语义完备,过程式语言做不到自描述

06 执法缺口​

  • §1 地图不等于路 → 知道:语义模型描述世界,拦不住赶工期的工程师
  • §2 目录为什么救不了 → 知道:事后扫描看不出 partner_segment 列的推导对不对
  • §3 走查:UAU 撒谎全程 → 知道:两个实现→虚高指标→自信叙事→战略 deck;AI 没幻觉,是坏事实
  • §4 元数据优先心态 → 知道:规格先于代码,验证先于写入;与软件左移同构
  • §5 边界 → 知道:执法缺口不能靠更多告警关掉,必须在写入前关

07 管道契约​

  • §1 契约不是 schema → 知道:schema 管形状,契约管身份(意义/行为/来源/治理)
  • §2 组件一 结构+语义 → 知道:semantic_definition 是机器可解释引用;走查 UAU 的 SQL 30 分钟窗口
  • §3 组件二 运营保证 → 知道:新鲜度 4 小时/环比 <20%/保留 180 天都是可验证承诺;健康指标给检索看
  • §4 组件三 治理 → 知道:列级 PII tag/资产级分类/场景 UUID;按意图授权
  • §5 组件四 lineage → 知道:声明式 lineage 被执法:契约外查询写不出来;五个运营能力
  • §6 完整契约 → 知道:五份保证合成一份 YAML

08 管道即代码与活元数据​

  • §1 静态 YAML 的天花板 → 知道:复制即漂移、类型/测试/复用弱
  • §2 Why Code Wins → 知道:类型安全(改名即编译失败)/复用(rule 即函数)/可测试(mock 事件跑断言)
  • §3 走查:一个单测拦下只数登录的实现 → 知道:断言失败→不部署→坏数据到不了 RAG
  • §4 托管平台 → 知道:契约是意图,fabric 负责验证/部署/编排/监控;五步工作流
  • §5 活元数据:更聪明的检索 → 知道:回答前四问(可信/新鲜/解释对/安全);「存在即正确」被废
  • §6 自愈上下文 → 知道:restatement plan+HITL;向量索引跟着重算

自查(两行「出去时知道」不得是同一件事)​

  • 01§3(缺口成因)与 02§2-5(逐支柱)不重叠:01 讲「为什么有缺口」,02 讲「怎么量它」
  • 03§3(实体内核模式)与 05§2(七层)不同物:03 是实体粒度资产怎么建,05 是层间依赖怎么管
  • 04§1(schema≠语义)与 06§2(目录救不了)不同物:前者讲语义要定义,后者讲定义了没人执行也白搭
  • 06§4(心态)与 07§1(契约)递进不重复:06 讲立场翻转,07 讲翻转后的第一个工件
  • 07§2(语义组件)与 03(内核)不同物:03 建权威定义,07 把定义引用进管道
  • 08§5(检索四问)与 02§5(质量信号)不同海拔:02 是支柱描述,08 是运行时机制
  • 主走查分布:01=流失风险问题走一遍旧平台;02=三个用户案例;03=TenantId 串五张表;04=CreateCopilot_Intent;05=DAU JSON 配方;06=UAU 撒谎全程;07=UAU 契约+SQL 修复;08=单测拦截。06 与 07 同用 UAU 是刻意的:06 展示病症,07 展示处方