三根支柱 — 给你的平台做一次 RAG 就绪体检
这一章讲三件事: 作者用来诊断 RAG 就绪度的三支柱框架;每根支柱的 成熟度阶梯(你在第几级);以及三个真实事故案例——它们分别演示三根支柱失守时 事故长什么样。 读完你应该能拿书里的清单给自己家平台打一次分。 承上一章:01 章讲了缺口是什么,这一章讲怎么量缺口。
1. 顶 层全景:三根支柱,三个问题
书给的诊断框架是三根支柱,每根支柱对应一个你能直接问出口的问题1:
| 支柱 | 它问你 | 就绪的样子 | 缺口的样子 |
|---|---|---|---|
| 数据资产 | 能不能把合同、政策、工单跨部门统一地取出来? | 有统一目录,元数据齐全 | 各存各的,元数据薄弱 |
| 基础设施 | 平台能不能服务表格数据和自由文本混着查的查询? | 两条路同时找,管道可扩展 | 只有一种查法,管道一碰就碎 |
| 信任层 | 能不能说清每个事实从哪来,并在检索时执行策略? | 有数据血缘、访问控制、审计轨迹 | 人工审批,导出无据可查 |
(「表格数据」指行列整齐的数据;自由文本——合同原文、聊天记录这类——行话叫非结构化数据。)
查这两类东西要用混合搜索:按关键词精确匹配是一条路,按意思相近程度找是另一条路。
「按意思找」靠嵌入:把一段文字变成一串数,意思相近则数也相近,再用数的距离来比「意思」。
至于「只有一种查法」——只会用 SQL(数据库查询语言,只会查表格)的平台接不住自由文本,管道也一碰就碎。
书自己的判断很直白:大多数组织对完这张表,看到的是一串 ⚠️ 和 ❌——而这正是重点, 缺口是真实且可以诊断的2。本章后面三节,一根支柱一节,每节带一张成熟度表和一桩案例。
2. 支柱一 数据资产:RAG 要的不是表,是连通的知识
这一节回答:为什么「有数据」不等于「数据资产就绪」。
RAG 要的不是行列整齐的表,是连通的知识:模型必须能理解「用户」和「订阅」怎么挂钩、 「合作伙伴」和「合同」怎么挂钩、一张支持工单怎么解释一个产品缺陷、 这些又怎么折算成财务影响3。
而书里的判断毫不客气:大多数企业今天给不出这个视图——几千个系统, 每个系统对同一个概念的定义都不一样:计费的「用户」是一种东西,身份系统的另一种, 人力部门的又一种;合同散落各处,一部分结构化,很多还是扫描件。 没有语义把这一切缝起来,模型就缝不起来——于是它要么开始编造(幻觉), 要么给出浅薄的回答4。
就绪的路线是实体内核:挑出定义你业务的少数核心概念 (书 里的例子:用户、租户、订阅、许可证、产品、SKU、合作伙伴、合同、工单), 把每个概念写明确——标识符是什么、哪些属性变化慢、和其他概念什么关系、 隐私分级、谁负责5。这些定义在三个层上落地6:
源头层 原样捕获,假设最少;ID 是神圣的,谁都不许改
│
统一层 属性对齐、身份去重、时间和币种标准化;语义契约在这里强制形状
│
产品层 同一份真相,按用途投影:分析用的事实表、RAG 接地集、API 载荷
图说:三个层不是三份数据,是同一份实体定义的三道工序;越往下越贴近原始记录。
书特别强调两点纪律:术语表必须绑在内核上——每个业务词都要指到具体的属性和关系; 本体要「轻」——一张实用的关系与同义词对照图就够,不是博士论文练习7。
成熟度分四级8:
| 级别 | 状态 | 风险 |
|---|---|---|
| 1 各自为政 | 每个系统自己定义实体 | 结果互相矛盾 |
| 2 只有术语表 | 业务词记录了,但没人执行 | 检索歧义 |
| 3 联邦内核 | 共享实体模型被采纳 | 执行不彻底 |
| 4 语义织网 | 内核+本体进了检索 | 治理开销 |
书观察到的现状是:多数组织停在第 1 或第 2 级;第 3 级是通往 RAG 就绪的第一个真正的拐点9。
案例走查:三个「用户」
这是全书第一个完整事故案例,也是支柱一的走查。微软开始给智能体(能自己干活、会调工具的 AI 助手)接地时, 第一个撞上的就是不起眼的「用户」一词10:
同一个词「用户」,三个系统三副面孔:
计费系统: 被授权使用某个 SKU 的人(为了开账单) —— 例子:12,000 人
身份系统: 目录里的一个对象(带角色、别名、权限) —— 例子:15,400 个
产品遥测: 真的发过使用事件的人 —— 例子:3,100 人
AI 助手被问:「我们在德国有多少活跃用户?多少有流失风险?」
→ 检索层从三路各取回一片,全塞进上下文窗口(模型一次能读进去的全部文字)
→ 模型老实地把三个数搀在一起作答
→ 答案不连贯:有的分母互相重叠,有的互相打架
图说:三个数是为演示编的,不是书里的真实数值;书里没给数,给的是
「some denominators overlapped, others diverged」这句症状描述。
事故的定性是这一案例最值钱的一句:败的不是大语言模型,是数据资产层—— 企业缺一副能把「用户」跨域统一起来的共享内核11。 02 章前面说过模型会「缝不起来」,这里就是缝不起来的实拍:三个各自正确的定义, 放进同一个上下文窗口(模型一次能读进去的全部文字)里就互相残杀。
3. 支柱二 基础设施:让语义在数据移动时不掉
这一节回答:实体内核给了数据含义之后,谁来保证含义在一路加工中不变质。
答案是:每次转换都可能磨损语义——每一次连接、过滤、加工,都可能悄悄改掉含义或 弄断出处。平台越大,这些断裂越看不见12。
传统平台的做法是把语义藏在代码里,把元数据当副产品:出处事后补录、质量事后监控、 政策靠人执行。做仪表盘勉强够用;RAG 的速度和审视之下就崩了13。 所以支柱二的口号是那四个字:元数据必须能编译——可执行、可自动校验、 对下游(尤其是检索层)可见14。
具体是四条原则15:
- 契约第一——先写声明式契约(YAML/JSON——机器能读的规格文件格式,07 章展开), 把表结构、实体绑定、允许的连接、隐私分级、质量预期全写进去;
- 管道即执法者——提交代码时就校验契约,违规的工件直接拦下,出处和质量指标自动产出;
- 质量即服务——监控持续运行,产出机器可读的信号(新鲜度、覆盖率、异常分、源可信度), 和索引放在一起,让检索随时能查;
- 统一索引——建跨表、文档、事件的混合搜索;切非结构化文本时按语义边界切 (章节、表格、实体),每块绑回出处。
第四条值得停一下。切块这一步在任何 RAG 系统里都要做,主流框架的做法是优先在 人类自然边界(段落、句子)断开——书在这里强调的是切完必须绑回出处, 否则检索命中的每一块都是无主之物(补充(不在书里,依据我们的 frontier 书架): 主流切块器正是按段落>句子>从句>空格的优先级降级切分的。依据: shelf=ai-frontier-reference/llamaindex#02-ingestion-chunking.md 事实=SentenceSplitter 按「人类自然的边界」逐级降级切块,超限才 继续往下切)。
案例走查:昨天的数
支柱二的事故案例很短,但症状人人见过16:
症状:某个智能体要取产品用量统计。明明数据每小时都在刷新,
它给出的却是陈旧数字。
根因:新鲜度只存在于仪表盘上(人看得到「最后更新于 08:00」),
不存在于代码里(检索层查不到「这份数据现在几岁了」)。
修复:把新鲜度时间戳写进数据本身,并在检索时强制阈值——
过期的查询直接丢弃,宁可拒答也不给旧数。
结果:用户信心一夜恢复。
教训:把质量当 API 对待,不是当报表对待。
时间戳:数据里记录「这一刻」的印子。
阈值:一条及格线,越线就触发动作。这两个词后面 07 章的契约里都会变成具体的列。
基础设施同样有四级阶梯:手写脚本 → 有契约的管道 → 元数据被编译 → 自治信任引擎; 书把第 3 级称为「RAG-ready 运营的入场券」17。
4. 支柱三 信任层:把治理从「人的时距」搬到「毫秒的时距」
这一节回答:语义和基础设施都完美,为什么还可能全盘皆输——以及输在哪。
书给的理由是时间差:传统数据治理跑在人的时距上(审批、审计、季度签核), 检索增强生成跑在毫秒的时距上。书说,这个时差搞垮的企业 AI 试点, 比模型性能问题搞垮的还多18。
三种访问控制:RBAC、ABAC、SBAC
信任层的核心模式是 SBAC。要讲清它,先把企业里原有的两种权限模型摆出来:
| 模型 | 全称 | 判断依据 | 一个例子 |
|---|---|---|---|
| RBAC | 基于角色的访问控制 | 你的职位角色 | 销售角色能看客户表 |
| ABAC | 基于属性的访问控制 | 你和数据的属性 | 只有欧盟员工能看欧盟数据 |
| SBAC | 基于场景的访问控制 | 这次访问的业务目的 | 「做流失预测」这个场景才允许把工单和合同连起来查 |
RBAC 和 ABAC 回答的都是「谁能看什么」;SBAC 补的是它们都不问的一个问题: 「为什么要看?」——声明这次访问的业务场景后,系统才决定哪些资产合适、 哪些跨源连接被允许19。场景本身写成一条短的、带签名的策略记录(YAML/JSON); 检索发生的那一刻,系统评估「目的+人+策略」,决定放行、脱敏(把敏感部分遮掉)、还是拒绝19。
质量信号进检索
信任层的另一半是让检索看得见质量:用新鲜度、覆盖率、异常、置信度去过滤、 重排、补充候选结果——优先新且可信 的源,降级陈旧的源,关键问题设最低分门槛, 并且把每次取舍连同出处记录在案20。(重排指第一轮粗筛出候选后,再按更好的标准 给它们重新排队。)
案例走查:一次 PII 泄漏
这是三桩案例里最重的一桩,完整的因果链21:
第 1 步 AI 智能体刚接上 IDEAS,团队想:「反正是内部数据」,给了宽权限
第 2 步 几周内,模型把日志(系统自动记录的事件流水)里含个人信息(PII,
即能识别到具体个人的数据,如邮箱、姓名)的片段翻了出来
第 3 步 事故没出边界,但足够惊醒:一个月内落地 SBAC
第 4 步 每个 Copilot 功能一张「场景卡」;管道给数据打上 PII 标签;
检索时强制脱敏(把敏感部分遮掉或删掉)
第 5 步 下一个季度:隐私事故零发生
图说:每一步都有具体的主体和动作;书的结论一句话——
信任不是合规税,是功能。
信任层也有一张四级表:人工治理 → 自动化策略 → SBAC 运行时 → 自治信任闭环; 书说第 3 级才算真正的生产就绪22。
5. 作者的判断与证据:哪些有案例撑,哪些是主张
这一节把第 2-4 节里「书给的证据」和「书的推断」分开摆。
有案例撑的(书里给了事故经过和修复过程): 三个「用户」的混淆真实发生过, 且定性为资产层失职11;「昨天的数」 有明确根因和「一夜恢复」的结果16; PII 事故有时间线(几周内发生→一个月内落地→下季度零事故)21。
作为框架主张提出的(没给对照实验): 三支柱划分本身、四级成熟度模型、 「多数组织在 1-2 级」「第 3 级是拐点/入场券」这些判断,书没有给跨企业统计数据, 是作者从自家平台经验推演出来的。把它们当有经验依据的判断用,不要当测量结果用。
书里没给量的: 成熟度模型每一级要花多久、多少人力;SBAC 一张场景卡的平均定义成本。 这两类数字对决策很关键,书只字未提。
6. 边界与局限
- 三支柱框架是诊断,不是路线图——它告诉你缺什么,不给你施工顺序; 施工顺序要等后面几章的模式(而 Early Release 只出到了地基部分);
- 成熟度模型没有行业基准数据——「多数组织在 1-2 级」无法核实, 且第 4 级(自治信任引擎)至今更像愿景:书自己只做到第 3 级的实践;
- 案例全部来自一个超大型平台,「数百 PB」的组织形态和百 GB 级团队的问题清单不同, 成熟度门槛可能整体偏高。
7. 可带走的
**全章走查合起来一行:**三个「用户」定义在上下文窗口里互相打架(资产层失守)→ 仪表盘上的新鲜度救不了代码里的陈旧查询(基础设施失守)→ 宽权限几周就漏 PII, 场景卡一个月止血(信任层失守)。
- 自检三问:资产能不能统一取?检索能不能混合查?每个事实能不能溯源+执行策略?
- 数据资产就绪 = 实体内核 + 三层落地 + 术语表绑内核 + 本体从轻;
- 多数组织在 1-2 级,第 3 级是第一个真正的拐点——先别梦想第 4 级;
- 语义会在每次转换中磨损,所以元数据必须能编译,不能只是文档;
- 质量要变成检索时能查到的信号(新鲜度/覆盖率/异常/置信度),「把质量当 API(程序随时能查的服务)」;
- 治理的时距要从「季度+人工」搬到「毫秒+自动」,否则治理就是摆设;
- RBAC 管「谁」,ABAC 管「什么属性」,SBAC 管「为什么」——三者叠加,不是替换;
- 三个案例共同点:问题全都出在平台侧,没有一个出在模型侧。
8. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 三支柱框架与自检表 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:116(搜「three pillars」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:134(搜「Table 1-1」) |
| RAG 要连通的知识 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:171(搜「connected knowledge」) |
| 多数企业给不出视图 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:173(搜「Billing defines」) |
| 实体内核与三层 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:177(搜「entity kernel」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:179(搜「Source layer」) |
| 术语表绑内核、轻本体 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:191(搜「ontology」) |
| 实体成熟度四级 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:235(搜「Maturity Model」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:274(搜「Level 1 or 2」) |
| 三个「用户」案例 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:197(搜「billing system」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:203(搜「denominators overlapped」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:205(搜「data asset layer」) |
| 转换磨损语义 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:278(搜「erode semantics」) |
| 元数据必须编译 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:282(搜「compile」) |
| 基础设施四原则 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:298(搜「first artifact」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:310(搜「Unified indexing」) |
| 昨天的数案例 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:316(搜「Yesterday」) |
| 基础设施成熟度与入场券 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:322(搜「Maturity Ladder」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:361(搜「entry ticket」) |
| 人类时距 vs 毫秒时距 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:367(搜「millisecond timescales」) |
| SBAC 定义 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:96(搜「Scenario-Based Access Control」) |
| 质量信号进检索 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:379(搜「freshness, coverage」) |
| PII 案例与场景卡 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:385(搜「PII」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:387(搜「compliance tax」) |
| 信任成熟度 | RAG 就绪的三根支柱 | text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:391(搜「Trust Maturity Model」) · text/04-ch01-chapter-1-the-pillars-of-rag-readiness.txt:430(搜「production-readiness」) |