聪明实习生测试与实体内核 — 资产侧的第一块地基
这一章讲三件事: 一个思想实验,证明最强的基础模型(在全网文字上练出来的大模型)到了你的数据平台上 和一个聪明的实习生处境完全相同;「实体内核」这个模式怎么给核心业务概念发身份证; 以及一张治理清单——没有它,内核建好也会被日常改动悄悄蚕食。 承上:02 章说资产支柱的入口是实体内核;这一章把它建出来。
1. 顶层全景:从一道测试题到一个模式
聪明实习生测试(它的两项短板) 实体内核(补短板的模式)
┌────────────────────────┐ ┌────────────────────────┐
│ ① 不懂业务词汇 │ → │ 核心档案 + 扩展表 │
│ ② 不懂资产目录 │ → │ 同一永久编号串起全部 │
│ (哪个表可信?谁能问?)│ → │ 治理清单把变更挡在门外 │
└────────────────────────┘ └────────────────────────┘
图说:左边是病,右边是方子。本章 §2 讲病,§3-§4 讲方子,§6 讲防复发。
2. 聪明实习生测试:模型和实习生缺的是同两样
这一节先做一道思想实验。它是全书第二章的发动机,也是「元数据缺口」最直观的呈现。
书请你想象:公司招了一个数据分析师实习生,非常聪明——会一大堆查询语言, 熟悉主流数据库、查询引擎、数据仓库和管道编排(把成百上千个任务 按顺序排好自动跑),可视化也是专家1。 但有两个前提:他不了解你们决策者的业务,也不知道你们有哪些报表、 哪些库、哪些表、怎么拼在一起1。
书问:这个实习生能多大程度上帮上你的决策者?他的答案几乎没有悬念, 因为摆在他面前的是两道过不去的坎2:
- 不懂业务上下文和词汇——公司内部沟通里满是行话,外人听不懂;
- 不懂资产目录——哪些表可信、哪些已经过期没人下架、哪些是某个专家当年 为一次汇报随手搭的(这类低代码小工件从来不受正式的变更管理),没人告诉他3。
没有老手带,实习生的成功率很低——书说得很直白3。
然后是这一章的转折句:这个实习生就是基础模型。大模型读过的语料(拿来喂给机器学的海量文字)是互联网上的公开文字, 不包含你公司内部的数据平台——它对你们的业务行话和数据资产,和实习生一样盲4。 模型写查询语句的能力再强,「查哪张表、那张表的『客户』是什么口径」这件事上, 它和实习生站在同一条起跑线上。
判断(我们的,不是书里的): 这个类比是全书最好用的思考工具—— 后面每个模式都可以拿它验收:「这个做法能让实习生干得更好吗?」能,就对模型也有效, 因为两者缺的是同一类东西:没有写下来的组织内部知识。 如果错,会错在: 如果模型能靠超强的模式匹配从表名和列名里猜出业务含义, 类比就不成立——但 02 章三个「用户」的案例恰好是猜错的实录。
3. 元数据缺口:能当骨架的元数据长什么样
书把实习生缺的第二样东西(资产目录)进一步收窄成一个缺口:元数据缺口5。
这里说的元数据,比「数据库的表结构」「报表的说明文档」大一圈。书给的完整定义是5:
- 在管道里、资产建成的那一刻捕获(不是事后补写);
- 可移植、纯声明式(写成机器可读的规格,不锁死在某一个工具里);
- 每个数据源都有语义(每个字段是什么意思,有据可查);
- 因此是当前的、可信的——实习生(或模型)可以一路追问下去的那种。
「声明式」这个词值得当场说清:声明式是说**「要什么」,不说「怎么一步步做」**—— 菜谱写「一份六成熟的牛排」是声明式,写「开大火、翻面、观察颜色」是过程式。 前者任何人(或机器)拿到都能执行,后者换个人就做不出同一种熟度。
书还交代了这个元数据在微软是怎么被逼出来的:GenAI 热潮之前, 几百个数据专业人员、几千个数据源的平台就靠它过日子——高管仪表盘上的任何一个数 都有多种用途(算销售提成、做功能实验、共享给客户),每个洞察都要能引到源头, 两张仪表盘的任何不一致都要能当场解释6。GenAI 来了之后,同一套元数据 直接变成了数千用户在用的 RAG 应用的底座7。
4. 实体内核模式:给核心概念发身份证
这一节讲资产侧第一个正式模式:内核。它回答「资产目录的第一层该放什么」。
书的出发点是数据建模的老传统:设计数据库时,最重要的就是认出实体(业务里 「存在的东西」,如客户、订单、合同)和它们之间的关系。老做法里这服务于两件事: 让最常用的查询跑得快;让表的增加与退役有意地发生而不炸掉别的表8。 书借的就是这个传统,但用途换了:先认出对决策者最要紧的那几个实体, 让整个平台围着它们转——毕竟决策者聊数据,聊来聊去都是围绕少数关键实体: 商业客户(在微软叫租户)和它们的商业用户;消费者业务里的个人用户9。
(「租户」是云服务的行话:一家公司买了你的云服务,它在系统里就是一个租户—— 隔离出来 的一个客户组织。)
实体内核的具体形态:
- 核心档案:每个实体类型一张核心表,记录「它是谁」——永久标识符 (一旦分配永不改变的编号,是全平台认人的唯一凭据)、名字、变化很慢的基本属性;
- 扩展表:围绕核心档案的补充属性表,全部用同一个永久标识符挂到核心上;
- 权威性:书特别要求,这个实体任何指标、洞察、推荐、推断分数, 都以这套资产为准——它是这个实体的单一事实来源10。
它不必物化成一张大表:因为各数据源到达时间不同、隐私义务不同, 可以是一组表、由不同团队负责的不同管道支撑,对外只暴露一个统一的逻辑视图11, 并且这个视图必须可扩展——新属性加进来,老消费者的用法不能被破坏12。
围绕这套资产,书要求捕获七类元数据13:核心工件与补充工件的关系、 挂接的维度表(放「国家」「行业」这类固定取值清单的表,05 章展开)、 每个属性的书面语义、每个工件上的质量监控(含跨工件的硬性不变式)、 每个工件的来源、以及可以传递计算的隐 私与合规注记。
5. 主走查:一个租户编号,走完五张扩展表
这一节拿书里的真实例子,把「内核+扩展」从头到尾走一遍。
书给了一个租户核心档案 IDEAsTenantProfile 和五张扩展表的定义14。
拿一个编出来的租户走一遍(下面所有具体值都是演示编的,不是真实数据):
问题:「这是一个什么客户?上个月 Teams 用得怎么样?教育版存储池用了多少?
它是政府或教育客户吗?总部是哪家战略大客户?」
第 1 步 核心档案 IDEAsTenantProfile,按永久标识符 TenantId 查:
TenantId = "8f3c…" DisplayName = "北 风贸易" IsTest = false
CustomerSegmentGroupKey → 指向「客户分层」维度的中端市场
第 2 步 扩展表 2 MonthlyActiveUsers,同一个 TenantId 挂上来:
AsOfMonth = "2026-07" TeamsMAU = 4120
PaidTeamsMAU = 3800 / UnpaidTeamsMAU = 320
→ 得到:月活四千出头,九成以上是付费席位
第 3 步 扩展表 3 EduTenantPooledStorage,同一个 TenantId:
TotalPooledStorageGB = 5000 / ConsumedStorageGB = 4310
UtilizationPct = 86% → 存储池快满了
第 4 步 扩展表 4 RegulatoryClassification,同一个 TenantId:
IsGovernment = false / IsEducation = true
ClassificationSource = "Contoso EDU 合同" → 教育客户,出处留了
第 5 步 扩展表 5 TopParentAccountDetails,同一个 TenantId:
TopParentId = "TPID-90210" IsS2200 = true → 挂在某战略大客户名下
汇总:一个查询沿同一个编号串起五张表,得到一句完整的话——
「北风贸易是一家挂在大客户名下的教育客户,月活 4120 且以付费为主,
教育版存储池用量已达 86%。」
每一步的「动作」都一样:拿同一个永久编号去另一张表里对号入座。
这就是内核模式在机器层面的样子——而 RAG 应用取数时走的就是这五步,
因为每张表的每个属性旁边都挂着 §3 说的那七类元数据(什么意思、谁负责、质量如何、
能不能用在这个场景)。书里那套核心档案还有第一张扩展表
IDEAsAvailableUnits(各 SKU 的可用席位数)14,五个扩展共同拼出
「这个租户是谁、买了多少、用了多少、是什么类型、归谁管」五个侧面。
这一步走完,§2 实习生的第二道坎就有了答案:他(或模型)不需要「被告 诉」这些表的关系, 顺着永久编号和挂在上面的元数据,自己就能走通。
6. 治理清单:没有硬执法,内核会被人绕开
这一节回答:模式建好之后,怎么防止它在日常改动中烂掉。
书先给了一条冷冰冰的规律:任何没有硬执法能力兜底的原则或模式, 迟早被绕过——尤其是在它拖慢交付的时候15。有的规则好执法(比如「必须有文档」 这种存在性检查),有的很难(文档写得好不好)——后者过去只能靠专家人肉把关, 书说,直到 LLM 出现才有了新的可能15。
另一个现实约束:治理天然拖慢执行,而执行速度是数据团队的生命线。 所以书的问题不是「要不要治理」,是把有限的治理火力集中到哪两层—— 答案是实体视图和数据契约这两处,因为它们恰恰是 RAG 应用最依赖的16。
实体工件的变更清单分八组17,每组挑两条 最硬的:
| 组 | 检查什么(节选) |
|---|---|
| 资格与意图 | 新增属性有权威定义;语义自明、不和已有属性重叠 |
| 命名与版本 | 符合命名规范;分清增量变更与破坏性变更,后者要升版本 |
| 键与可连接性 | 新实体类型的主键不可变、稳定、覆盖全集,来自最权威的记录系统 |
| 演进与退役 | 不再使用的属性标成弃用(不再使用、即将下线);删除要反映在版本里 |
| 性能与规模 | 新扩展要演示连接性能,不许拖慢实体接口(对外统一的查询入口)的承诺 |
| 隐私安全合规 | 上游源走过合规流程;登记这个扩展允许用在什么用例 |
| 质量与运营就绪 | 有生产数据上的验证证据;有值班与事故升级路径 |
| 元数据完整性 | 定义、含义、允许值齐全;血缘、保留期、敏感度、负责人齐全 |
清单走完的效果,书一句话:实体工件在稳健治理之下, RAG 应用就有了一份可以直接审问和查询的资产清单18。
7. 作者的判断与证据、边界
有案例与制度撑的: 实习生类比背后是微软数百人、数千源平台的真实管理实践—— GenAI 之前「每个洞察引到源头、不一致必须解释」是人肉执行的制度6; TenantProfile 五扩展是书里给出的真实工件形状14。
作为主张提出的: 「七类元数据」「八组检查」是作者从自家实践提炼的清单, 没有给出「清单缺一组会出什么事」的反例证据;「LLM 让高质量文档的执法第一次变得可行」 是作者的前瞻判断,书里没有展开怎么做(按书里的安排,这类内容在未出版的后续章节)。
边界: 内核清单(用户/租户/订阅/合同……)是商业软件公司的形状; 制造业、金融业的「内核实体」会不一样,模式的迁移成本书没有讨论。 另外,「权威性」要求各源数据的隐私义务允许合并——书自己提到不同源义务不同11, 但没讲义务冲突时逻辑视图怎么办。
8. 可带走的
- 先做聪明实习生测试:把你的模型当成那个不懂业务词汇、不懂资产目录的实习生, 列出他过不去的坎——那就是你的元数据缺口;
- 元数据要「在管道里捕获、声明式、每源带语义」,事后补写的元数据会过期失真;
- 实体内核 = 少数核心概念 + 每个概念一份核心档案 + 若干扩展表,永久标识符是串起一切的钥匙;
- 实体资产必须是该实体的单一事实来源——指标、洞察、推断分数都以它为准;
- 统一视图不必是一张物理大表,可以是一组表加一个逻辑视图,但要可扩展;
- 每个实体工件要挂七类元数据,其中每个属性的书面语义是 RAG 能用的前提;
- 治理火力集中在实体视图与数据契约两层;没有硬执法的原则迟早被绕过;
- 验收用实习生测试:模型能顺着编号和元数据自己走通五张表,这一章才算成了。
9. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 聪明实习生实验 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:16(搜「intern」) |
| 两道坎 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:18(搜「two sets of challenges」) |
| 僵尸资产与低代码工件 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:26(搜「stale」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:28(搜「low code」) |
| 实习生=基础模型 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:30(搜「smart intern」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:32(搜「not representative」) |
| 元数据缺口定义 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:36(搜「metadata gap」) |
| 微软规模与 GenAI 前的用法 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:38(搜「hundreds of data professionals」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:40(搜「cited down to its sources」) |
| GenAI 后成为 RAG 底座 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:42(搜「thousands of users」) |
| 数据建模传统与永久标识符 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:48(搜「OLTP」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:54(搜「durable identifier」) |
| 关键实体来自决策者对话 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:56(搜「Tenants」) |
| 权威性与逻辑视图 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:62(搜「authoritative」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:64(搜「logical view」) |
| 可扩展接口 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:66(搜「extensible」) |
| 七类元数据 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:70(搜「core entity grain」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:76(搜「Documented semantics」) |
| 租户核心档案与五个扩展 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:89(搜「CORE PROFILE」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:112(搜「MonthlyActiveUsers」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:143(搜「TopParentAccountDetails」) |
| 元数据与数据同等重要 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:152(搜「as important as the data」) |
| 没有硬执法就被绕过 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:271(搜「hard enforcement」) |
| 文档质量难执法 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:273(搜「documentation」) |
| 治理要平衡、火力集中 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:275(搜「balance」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:277(搜「curation」) |
| 八组治理清单 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:279(搜「Eligibility」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:331(搜「Metadata Completeness」) |
| 清单的成果 | 数据地基:RAG 的语义骨干 | text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:337(搜「interrogated and queried」) |